pixel
Seite wählen

NETWAYS Blog

Announcing NETWAYS Managed Database

Today is the day! Proudly and full of joy, I can announce our new Managed Database service offering for MySQL compatible databases!
The requests for us adding databases to our portfolio, piled up the last couple of months. We’re always trying to take our customers’ feedback into consideration, so here we are now! Besides our existing services like Managed Kubernetes and Infrastructure as a Service, this is the next consequent enhancement of our portfolio that enables our customers at NETWAYS Web Services even more now!

 

Why our Managed Database is so Special

You may be wondering, why I am so excited about this new release?
First of all, all of our services are made with love & passion by our great and clever team of engineers! Just like this. Lots of appreciation goes out to the whole team!
On the other hand, our new Managed Database service is built with Vitess, and it may not sound that spectacular to you – but it is the first service of this  kind, hosted and operated in Germany! Vitess is a CNCF graduated project and defines itself as a database clustering system for horizontal scaling of MySQL. Don’t worry: you’ll be hearing more about Vitess and how it’s benefiting your NETWAYS Managed Database!

With that being said, let’s continue with the many core features available and benefits that come with them – just to name a few:

 

Highly Available

All Managed Database clusters consist of multiple components and at least two database instances of MySQL running and holding your data. One primary and one replica. In case of a sudden and unexpected failure of the primary database instance, the replica gets promoted and will take over. Traffic will be redirected automatically by the gateway servers. Failed instances will self-heal and repaired or restored automatically.

 

Two Locations

As mentioned above, the data gets replicated to at least one replica. We also make sure that the data is always replicated across our availability zones in our two independent and ISO-27001 certified data centers. This means that the data is even resilient against a loss of complete failure domain like a data center location.

 

Disaster Recovery Backups

Operating databases means running backups is a crucial part of protecting your data. We run daily backups, which can be kept as long as you wish. The backups are stored on our separate s3 based storage, which also is distributed and replicated three times across our locations. Failed replicas then can be restored from those backups to catch up the primary state as quick as possible!

 

Non-Blocking Schema Migrations

Schema migrations on production are no longer frightening! With traditional databases, depending on your operation and your data, there might be some blocked tables for a period of time. This can range from minutes to hours. With Vitess, this issue is solved! Even rollbacks of the migration can be instantiated, if necessary.

 

Scale Out

Vertical scaling can be done by just choosing the next available size of our plans. This is just a click and done in minutes. Read traffic can be accelerated by adding more replicas to the cluster. If you need even more and vertical scaling is no more an option, it’s possible to scale horizontally. This process can be infinitely, so to say. It can be done through sharding and partitioning your data into smaller pieces, which are stored on multiple database instances grouped to single, logical database without reengineering your application. This advanced feature will be explained in our tutorials soon!

We have more features that can be found on the NWS Managed Database website! 

 

Perfectly Matching & Managing

Along with those core features comes the more convenient and easy way of using our products through our NWS Web Interface, which makes great technology accessible and usable for our customers with no contract periods! For even more special setups our MyEngineers are there and happy to help!

 

Thanks Again – It Takes A Village

I’m really thankful to everyone at NETWAYS, who was involved in making this product ready and who helped us getting started! This kind of roll out of an enhancement like this is only possible with a team!
Of course a big shout out and thanks to the developers of Vitess: without them, we wouldn’t be able to offer such a blast of a product!

 

Stay tuned for our next releases, since we’re definitely not done yet and there is more to come!

Sebastian Saemann
Sebastian Saemann
Head of Managed Services

Sebastian kam von einem großen deutschen Hostingprovider zu NETWAYS, weil ihm dort zu langweilig war. Bei uns kann er sich nun besser verwirklichen, denn er leitet das Managed Services Team. Wenn er nicht gerade Cloud-Komponenten patched, versucht er mit seinem Motorrad einen neuen Rundenrekord aufzustellen.

DockerCon 2022: Wie geht Containersecurity?

Buzzwords wie Software Supply Chain, Container Security Scanning oder Software Bill of Materials (SBOM) sind in den vergangenen zwei Jahren vermehrt in aller Munde, nicht zuletzt aufgrund des anhaltenden Trends zur Containerisierung vormals monolithischer Anwendungen und deren Betrieb als sog. Microservices. Allerdings kann nach wie vor nicht jeder, der auf die ein oder andere Weise mit Docker oder Containern im Allgemeinen zu tun hat, etwas mit diesen Begriffen anfangen. Aus diesem Grund habe ich den Fokus meines virtuellen Besuchs der diesjährigen DockerCon auf genau diesen Themebereich – Containersecurity – gelegt und möglichst viele Best Practices für Dich zusammengefasst.

 

Die Ausgangslage

Die großen Sicherheitslücken der vergangenen zwei Jahre, sei es der Solarwinds-Breach oder die Log4J/Log4Shell-Exploits haben einmal mehr schmerzlich bewusst gemacht: In fast jedem Softwareprodukt, egal ob proprietär oder Open Source, befinden sich zahlreiche mehr oder weniger gut gepflegte Abhängigkeiten verschiedenster Maintainer – in vielen Applikationen stecken bis zu 80% Open Source Code, die es “auf dem Schirm” zu behalten gilt. Dies gilt natürlich auch für Container(-images), die letzten Endes nichts anderes tun, als die Applikation zu bündeln und (weitestgehend) losgelöst vom ausführenden Hostsystem ausführbar zu machen.

Dennoch gelten Container paradoxerweise oft als besonders sicher, sei es aufgrund der von außen wahrgenommenen “Kapselung” oder der geringen Größe – soviel potentiell vulnerable oder bösartige Software kann da doch gar nicht drinstecken, oder? Mögen diese Wahrnehmungen in der Theorie und im Bestfall auch stimmen, sieht die Praxis in den allermeisten Fällen anders aus, wie die ein oder andere Keynote im Rahmen der DockerCon gezeigt hat.

Laut SysDig, einem Spezialisten für Cloudsecurity, laufen 58% der in den einschlägigen Containerregistries (DockerHub, Google, Github, etc.) verfügbaren Containerimages als root, anstatt einen geeigneteren, unprivilegierten Nutzer zu verwenden. Außerdem beinhalten selbst die offiziellen, von den Registries kuratierten Containerimages beliebter Frameworks oder Distributionen dutzende detektierbare Schwachstellen.

Offensichtlich gibt es also zum Einen ein falsches Gefühl von Sicherheit innerhalb der Nutzergemeinschaft von Containern, zum Anderen aber schlichtweg keine Blaupause oder “OneFitsAll”-Lösung, die für beliebige Container(-images) absolute Sicherheit verspricht. Nur eine Sache ist klar: “Hinten” anzufangen, ist nicht rentabel – Container einfach zu deployen und dann im Betrieb nach Sicherheitslücken zu suchen, ist teuer, erzeugt vermeidbaren zusätzlichen Aufwand und nimmt Flexibilität. Die Absicherung der Container muss “nach links” geschoben werden, möglichst an den Beginn der Containerisierung. Doch wo ansetzen?

 

Die Möglichkeiten

Um den Ursprung für Schwachstellen in Container(-images) und damit einhergehend mögliche Ansatzpunkte zur Absicherung zu identifizieren, muss man die “Lebensphasen” eines Container(-images) verstehen. Diese lassen sich kurz und bündig wie folgt darstellen:

 

  • Bau des Images (lokal oder via CI/CD)
  • Distribution des Images – Push in eine Registry (Self-hosted oder bei einem Anbieter), Pull von Usern/Programmen
  • Deployment des Images (Openshift, (Managed) Kubernetes, etc.) und Betrieb des Containers

 

An dieser Stelle wird hoffentlich klar, warum ich permanent “Container(-image)” schreibe – abhängig von der betrachteten Lebensphase haben wir es beim Thema Containersicherheit entweder mit einem erstellten Image oder mit einem laufenden Container, quasi einer Instanziierung dieses Images zu tun. Mit dieser Aufschlüsselung in verschiedene Abschnitte können wir uns nun mögliche Schritte zur Absicherung unserer Container anschauen.

Containerimages werden entweder lokal von Entwickler:innen, DevOps-Engineers, etc. auf Grundlage eines sog. Dockerfiles gebaut – alternativ lässt sich dieser Vorgang aber auch von CI/CD Pipelines umsetzen, wenn man den Dockerfile und andere benötigten Ressourcen bspw. in GitLab eincheckt. Die meisten Möglichkeiten zur Absicherung des späteren Container(-images) ergeben sich bereits in diesem ersten Schritt – der Quellcode der zu containerisierenden Applikation liegt vor, ebenso die Definition des Containers selbst, und auch möglicherweise vulnerable oder bösartige Abhängigkeiten wurden noch nicht in das spätere Containerimage eingebettet.

Ist das Containerimage lokal oder in einer Pipeline gebaut worden, muss man es zur späteren Nutzung in Produktion in eine Containerregistry übertragen. Diese kann entweder selbst gehosted werden, als private, aber gemanagte Instanz in der Cloud laufen oder öffentlich von jedem beliebigen Nutzer einsehbar sein. Auch bei diesem Vorgang gibt es Möglichkeiten, die Supply Chain zwischen Entwickler und Endnutzer abzusichern.

Auch wenn im Dockerfile gewisse Best Practices befolgt werden, kann der Container diese in vielen Fällen beim Deployment überschreiben – das letzte Wort haben hierbei immer Kubernetes, Openshift, Docker Desktop und Konsorten. Aus diesem Grund müssen einige der Überlegungen, die in der Build-Phase des Containerimages stattgefunden haben, auch hier noch einmal herangezogen, betrachtet und evaluiert werden, um die für die konkrete Nutzung besten Einstellungen und Kompromisse zu finden.

Ist der Container erst einmal deployed, gibt es nicht mehr viele Möglichkeiten, ihn “von innen” weiter abzusichern. Dennoch kann und sollte man sich fortlaufend Gedanken bspw. um die Erreichbarkeit innerhalb des Clusters, des Netzwerkes, der Cloud etc. machen, Regeln nachziehen wo nötig und natürlich auch Update- und Backupstrategien im Hinterkopf behalten. Am Ende des Tages merkt man spätestens jetzt: Nach dem Deployment eines Containers seine Sicherheit zu überprüfen und zu garantieren, ist nicht sinnvoll – wir brauchen einen Left Shift.

 

Die Umsetzung

Buildphase

Nach viel Theorie und Konjunktiv können wir uns jetzt konkrete Umsetzungsmöglichkeiten der besprochenen Ansätze anschauen. Beginnen werden wir “ganz links” beim Bau der Containerimages. Vieles lässt sich hier über verschiedene Direktiven im genutzten Dockerfile festlegen – Docker listet alle möglichen Direktiven sowie sinnvolle Best Practices und Caveats in der Docker Dokumentation auf. Für uns besonders interessant sind die Direktiven ADD, COPY und USER. Wie eingangs erwähnt, nutzen mehr als die Hälfte aller Containerimages per Default den root Nutzer innerhalb des Containers, obwohl das in vielen Fällen gar nicht notwendig wäre – auf einem klassischen Server läuft ein Apache2 Webserver schließlich auch als User apache, warum sollte/müsste das innerhalb eines Containers bspw. auf Debian-Basis anders sein?

Die anderen beiden erwähnten Direktiven beziehen sich auf die Abwägung, ob man gewisse Verzeichnisse und Dateien aus seiner Entwicklungsumgebung denn tatsächlich im endgültigen Container braucht – oder ob man die Applikation direkt lokal baut, und lediglich die fertige Binary via COPY in das Containerimage überträgt. In diesem Fall muss man natürlich darauf achten, dass etwaige zur Laufzeit benötigte Tools (ich meine dich, curl) und Bibliotheken sich auch im endgültigen Containerimage befinden. Alternativ kann man innerhalb eines Dockerfiles eine build und eine run Umgebung schaffen – auf diese Weise kann man die Applikation innerhalb des Containers bauen und im Anschluss lediglich die benötigten binären Artefakte und andere benötigten Ressourcen in das Lauzeitimage kopieren. Für diese Vorgehensweise würde es sich anbieten, das Entwicklungsrepository via ADD in die build Umgebung des Containerimages zu übertragen.

Diese Vorgehensweise bringt uns direkt zur nächsten “beliebten” Unsicherheit in Container(-images): Lokal hinterlegte Credentials, Entwicklertokens, Cloudzugänge etc. Es gibt vermutlich keine Art von geheimen Daten, die nicht bereits versehentlich in Containerimages “vergessen” wurde. Das kann schnell passieren – ein Entwickler nutzt ein Shellscript mit Zugangsdaten, um von seiner Entwicklungsumgebung in ein Testcluster zu deployen, eine .yaml-Datei, um Daten aus einer Entwicklerdatenbank zu lesen etc. Im “schlimmsten Fall” überträgt er wissentlich eine Datei mit Zugangsdaten, die die containerisierte Applikation später in Produktion nutzen soll, oder hinterlegt sensible Daten im Containerimage als Umgebungsvariable mittels ENV.

Zur Bewältigung dieser Problematik gibt es die Möglichkeit, ähnlich wie eine .gitignore Datei für Git-Repositories eine .dockerignore Datei für den Buildvorgang eines Containerimages zu hinterlegen. Alle in dieser Datei aufgeführten Dateien und Verzeichnisse werden vom Dockerdaemon bei der Verarbeitung des Build-Contexts, von ADD und von COPY Direktiven ignoriert und finden sich somit zu keinem Zeitpunkt im Containerimage wieder. Dringend benötigte Umgebungsvariablen zur Konfiguration der containerisierten Applikation können auch zum Zeitpunkt des Deployments noch übergeben werden, bspw. mittels des Parameters -e via Docker-CLI oder dem Einlesen von Secrets als Umgebungsvariablen in Kubernetes.

Grundlegende Maßnahmen wie die Nutzung eines passenden Base-Images in der FROM Direktive (es muss nicht immer debian:buster oder ubuntu:20.04 sein), das Vermeiden der Öffnung unbenötigter Ports via EXPOSE sowie der Nutzung sog. Kannibalen-Tags (latest zeigt nach jedem Imageupdate auf eine neue Version) sollten darüber hinaus natürlich immer befolgt und beachtet werden.

Distributionsphase

Haben wir nun lokal oder in der Pipeline ein in sich möglichst sicheres Containerimage gebaut, muss es auf die eine oder andere Art und Weise seinen Weg in eine Containerregistry finden, um von anderen Nutzern heruntergeladen und deployed werden zu können. Für diese Vorgänge werden einem von den meisten Containerregistries Werkzeuge an die Hand gegeben, mit deren Hilfe wir den Prozess des Up-/Downloads von Containerimages absichern können.

Letzten Endes sind Containerregistries nichts anderes als APIs mit der Fähigkeit, Nutzer zu authentifizieren und zu authorisieren, Containerimages in Empfang zu nehmen, zu speichern und deren Versionierung im Blick zu behalten. Wie immer, wenn man über das Internet mit einer API spricht, gilt: HTTPS ist Pflicht! Darüber hinaus bieten Registries verschiedene Möglichkeiten, zusätzliche Maßnahmen gegen die Verbreitung unsicherer Images oder die Manipulation vorhandener Containerimages zu treffen. So können Imageregistries oftmals alle verwalteten Containerimages auf bekannte Schwachstellen scannen und den Download solcher Images durch Endnutzer untersagen. Auch die digitale Signierung von verwalteten Containerimages ist oftmals möglich, z.B. mittels sigstore und cosign.

Deploymentphase

Wird unser Containerimage nun im Rahmen eines Kubernetes-Deployments oder Docker-CLI-Befehls aus der Registry gepulled und deployed, haben wir einmal mehr die Möglichkeit, Sicherheit zu forcieren: Wie bereits erwähnt, können wir zum Einen die Voreinstellungen in Hinblick auf Umgebungsvariablen, User- und Gruppenkontext uvm. überschreiben, zum Anderen bietet natürlich auch die Absicherung der ausführenden Infrastruktur selbst die Möglichkeit, dass Deployment so sicher wie möglich zu gestalten.

Hierzu zählen z.B. die Nutzung sog. rootless Container, die von einem Container Runtime Interface (CRI) wie Docker oder containerd ausgeführt werden, die selbst nicht im root Kontext laufen. Auch die Nutzung restriktiver Netzwerk- und Firewallpolicies kann dabei helfen, die Risiken durch möglicherweise vulnerable oder bösartige Container zu minimieren. Konfiguration und Forcierung dieser Maßnahmen innerhalb eines Clusters können schnell zur Sisyphusarbeit werden – hier kann ein gemanagtes Kubernetes-Cluster von Vorteil sein, bspw. Managed Kubernetes von NETWAYS Web Services. Darüber hinaus sollte man eine nachhaltige Update-Strategie für seine Containerimages verfolgen: Es gilt, einen guten Kompromiss zwischen regelmäßigen Updates zu finden, aber nicht sofort jede neue Version (und deren evtl. neu eingeführte Schwachstellen) in Produktion zu deployen.

 

Das Fazit

Container(-images) sicher zu erstellen, zu verwalten und zu deployen ist ein langer Weg voller Stolpersteine. Wie so oft beim Thema Sicherheit wird man die 100% aller Voraussicht nach nicht erreichen – Nichtexistenz von Sicherheitslücken lässt sich nun einmal nicht beweisen. Dennoch habe ich Dich hoffentlich für das Thema und die teils falschen, gängigen Annahmen und Praktiken sensibilisieren können und nebenbei einige Best Practices an die Hand gegeben, die das Risiko durch vulnerable Container deutlich verringern.

Solltest Du nun mehr über den Vorgang des Imagebaus, den Betrieb von Containern in Kubernetes oder Containerisierung im Allgemeinen erfahren wollen, schau Dir doch einmal unser Kubernetes Schulungsangebot von NETWAYS an. In diesem eintägigen Workshop vermittle ich Dir praxisnah und einsteigerfreundlich alles, was Du für die ersten eigenen Schritte mit Docker und Kubernetes wissen musst. Ich freue mich auf Dich!

Daniel Bodky
Daniel Bodky
Consultant

Daniel kam nach Abschluss seines Studiums im Oktober 2021 zu NETWAYS und berät nun Kunden zu den Themen Icinga2 und Kubernetes. Nebenher schreibt er in seiner Freizeit kleinere Tools für verschiedenste Einsatzgebiete, nimmt öfters mal ein Buch in die Hand oder widmet sich seinem viel zu großen Berg Lego. In der wärmeren Jahreszeit findet man ihn außerdem oft auf dem Fahrrad oder beim Wandern.

Network Links between OpenStack and Kubernetes Projects

We are happy to introduce cross-project network links between OpenStack and Kubernetes!
This feature provides an easy and free solution for our customers to share one or multiple networks between their OpenStack and Kubernetes projects.
We employ the native OpenStack RBAC feature to make this possible.
As a result, our customers can now establish local connections between their OpenStack servers and Kubernetes clusters.

 

How you can use it

You will need to have at least one OpenStack project and one Kubernetes project with at least one cluster. Alternatively, two OpenStack projects or two Kubernetes projects with different subnets will also work.

Once you are logged in to your NWS account, just navigate to either one of your OpenStack projects or one of your Kubernetes projects.
Next, click on “Networks” – this is a new section we added to the menu of the projects.
A list with all of the networks of the project will show up. Next to each of the networks you will find an action called “Manage network links“.
If you click on “Manage network links”, a popup window will show up containing a list of all the other networks that you have in your other Kubernetes and OpenStack projects.

 

The networks are grouped by the projects they belong to. For each network you now have an option to create a link, as seen in the screenshot. If you have chosen a network, which you would like to link to the current network, you just have to click on the “Create Link” button next to it.

 

Doing so will trigger a job which will be processed in the background. As one of the first steps, the job will check, if the selected networks are compatible with each other. Two networks are compatible, if they contain subnets with different subnet addresses. Furthermore, there must be a router in each of the projects, which has an interface on each of the networks.

 

Only, if both of those requirements are met, it will be possible to route between the networks and the job will start. Once it’s finished, you’ll get notified.

 

In case the requirements are not met you will get a notification telling you that the subnets are incompatible.

 

By default, our OpenStack and Kubernetes networks are compatible with each other. If you want to link Kubernetes with Kubernetes, then the only way to ensure compatibility is to supply a custom subnet address on creation to one of the clusters. For OpenStack to OpenStack you do not have the option (yet) to supply a custom subnet address to your default network on creation of the project. However, you can create your own custom networks with any subnet addresses and ensure compatibility that way.

 

Why should you use it?

Some might ask, why should one want to use this feature? Here is an example:
Let’s say, you have your application running on your Kubernetes cluster and you need to connect it to a database, which is running on a server in your OpenStack project. In that case you want to have a secure connection – a VPN comes to mind. Another approach would be a Database with a floating IP and security group rules.
But both of those options come with some tradeoffs: in case of the VPN, you have another point of failure and additional network overhead. And with a floating IP on your database you might not sleep so well, because of security concerns.
This new feature comes in handy, as the connections are not leaving our internal network infrastructure and traffic can flow locally between the projects and networks without additional overhead!

We already had some customers who were using this feature before the launch of the integration into NWS. In those cases one of our MyEngineers would configure the cross-connection manually for the customer.
But now it comes at no additional costs, because it does not require any action of one of our MyEngineers. Feel free to try it. Should you have any questions, don’t hesitate to send us a message or use our LiveChat on our website, which can be found in the bottom right corner.

 

Gabriel Hartmann
Gabriel Hartmann
Systems Engineer

Gabriel hat 2016 als Auszubildender Fachinformatiker für Systemintegrator bei NETWAYS angefangen und 2019 die Ausbildung abgeschlossen. Als Mitglied des Web Services Teams kümmert er sich seither um viele technische Themen, die mit den NETWAYS Web Services und der Weiterentwicklung der Plattform zu tun haben. Aber auch im Support engagiert er sich, um den Kunden von NWS bei Fragen und Problemen zur Seite zu stehen.

Rocket.Chat: Was die Messenger-App genial macht

Spätestens mit Beginn der Corona-Pandemie befinden sich die meisten Unternehmen in der Situation, dass ihre Mitarbeiter nicht mehr alle zentral an einem Ort zusammenarbeiten und jederzeit mal schnell über den Gang huschen können, wenn noch eine Info benötigt oder eine Entscheidung abgestimmt werden muss.
Der neue Arbeitsalltag funktioniert dezentral – Du kannst Deine Arbeit von überall aus erledigen. Alles, was Du brauchst, sind ein Laptop und eine Internetanbindung.
Damit die Zusammenarbeit mit Deinen Kollegen aber weiterhin reibungslos funktioniert, ist natürlich ein zuverlässiges Kommunikationstool unabdingbar.
Für all diejenigen, denen darüber hinaus auch noch die Themen Sicherheit und Datenschutz eine Herzensangelegenheit sind, haben wir genau den richtigen Dienst auf unserer NWS-Plattform im Angebot!

Unsere NWS-Plattform

Mit der Rocket.Chat App bekommst Du einen sicheren und performanten Dienst, der einen unkomplizierten Austausch mit den Kollegen, Kunden oder anderen Unternehmen ermöglicht.
Die Messanger-App ist als Self-Service Dienst konzipiert. Du kannst die App also zu jeder Tages- & Nachtzeit selbst starten und direkt loslegen.
Alles, was Du hierfür tun musst, ist Folgendes:
1. Erstelle Deinen Nutzeraccount
2. Wähle das Rocket.Chat Paket Deiner Wahl aus.

Bei all unseren Apps sind die ersten 30 Tage kostenlos! So kannst Du Dir ein ausführliches Bild vom jeweiligen Dienst machen und ausprobieren, ob das jeweilige Tool Deinen Vorstellungen entspricht.
Sobald Du Dein Wunsch-Paket gewählt hast, wird Deine Rocket.Chat Instanz in einem Container gestartet und alles automatisch installiert. Nach drei bis vier Minuten ist die App einsatzbereit und Du kannst loslegen.
Grundsätzlich gilt es zu erwähnen, dass die App als Full-Service-Dienst konzipiert ist. Das heißt, dass Du Dir keine Sorgen um Updates, Backup und Co. machen musst! Wir kümmern uns im Hintergrund automatisch um alles – Du nutzt einfach die App.

Sicherheit und Datenschutz

Für die Sicherheit Deiner Chats kann unter anderem zwischen einer Ende-zu-Ende Verschlüsselung, einer LDAP-Schnittstelle oder der Zwei-Faktor-Authentifizierung (2FA) gewählt werden. Darüber hinaus gibt es ein umfangreiches Rollenmanagement für alle User und speziell bei Moderatoren und Administratoren können erweiterte Rechten bestimmt werden.
Neben der zuverlässigen und sicheren Handhabung eines Kommunikationsdienstes ist heutzutage aber vor allem auch das Thema Datenschutz ein absolutes K.O-Kriterium für viele Unternehmen. Auch hier können wir mit der NWS Rocket.Chat App punkten!
Die Umgebung, auf der der Dienst betrieben wird, ist auf zwei DIN ISO 27001 zertifizierte Rechenzentren in Nürnberg verteilt – alle Daten liegen somit in Deutschland. Damit der Dienst DSGVO-konform betrieben werden kann, haben wir per Default alle Push-Notifications deaktiviert. So bleibt gewährleistet, dass alle Nutzerdaten auch innerhalb der EU verbleiben.
Falls gewünscht, können wir Dir auch gerne unseren AV-Vertrag samt unseren TOMS und der Liste unserer Subunternehmer zukommen lassen. Hierfür bitte einfach unter sales @netways.de melden.

Special Features

Ab dem Advanced Paket sind bei der Rocket.Chat App sogar Videoconferencing und der Helpdesk Chat mit im Preis inbegriffen!
Wenn Du im Chatverlauf mit Deinem Kollegen merkst, dass sich das Anliegen in einem Gespräch leichter klären lässt, könnt Ihr einfach zum Videocall auf dem integrierten Jitsi übergehen. Dort kannst Du Deinem Gesprächspartner mittels Screensharing auch ganz einfach zeigen, woran Du gerade arbeitest.
Mit dem sogenannten Omnichannel kannst Du auf Deiner Homepage einen Helpdesk-Chat für Kundenanfragen einrichten.
Hiermit können potentielle Kunden direkt in einen Livechat mit Dir gehen, wenn sie gerade auf Deiner Webseite unterwegs sind und sich Fragen zu Deinen Produkten und Dienstleistungen ergeben (Siehe hierzu beispielhaft den Omnichannel auf unserer NWS Homepage).

               

Du siehst also: mit der Rocket.Chat App bekommst Du ein multifunktionales Tool für die interne und externe Unternehmenskommunikation!

 

Abschließend sei noch erwähnt, dass wir Rocket.Chat nicht nur unseren Kunden anbieten, sondern es selber in der NETWAYS Unternehmensgruppe mit insgesamt 100 Mitarbeitern zum Einsatz kommt! Wir sind hier rundum zufrieden und können den Einsatz daher besten Gewissens empfehlen.
Aber mach’ Dir doch einfach selbst ein Bild: Wir haben alle Infos zu Rocket.Chat auf unserer Website für Dich festgehalten.

Und wenn Du nun noch wissen möchtest, was die NETWAYS Web Services noch alles zu bieten haben, dann schau Dich doch einfach mal hier um: OpenStack, Kubernetes, SaaS-Apps und MyEngineer-Support-Service.
Für alle Fragen kannst Du Dich telefonisch unter der 0911-9288566, per Mail unter sales@netways.de oder über den Omnichannel auf unserer Homepage bei uns melden!

Stefan Schneider
Stefan Schneider
Account Manager

Vor seiner Zeit bei NETWAYS hat Stefan als Projektmanager in einer Nürnberger Agentur dabei geholfen, Werbeprojekte auf die Straße zu bringen. Seit Juni 2017 ist er nun stolzes Mitglied der NETWAYS-Crew. Hier war er zuerst der Ansprechpartner für unserer Schulungen und kümmert sich aktuell um alle Anfragen rund um unser Hostingangebot. Die Freizeit vertreibt sich Stefan am liebsten mit Sport. Vom Joggen über Slacklining bis zum PennyBoard fahren ist er für alles zu haben.

What is the Icinga Master App?

Du hast eine kritische Infrastruktur, die sich bei Ausfällen auch auf Deinen Gewinn auswirken kann? Dann ist die Icinga Master App genau das richtige für Dich und Dein Unternehmen!

 

Und was ist die Icinga Master App jetzt eigentlich?

= Kurz gesagt, ist es ein Tool zur Überwachung Deiner IT-Infrastruktur auf Basis von Open Source.

Auch wir intern, verwenden die Icinga Master App, um die Infrastruktur unserer Kunden überwachen zu können. Beim Ausfall eines Dienstes, beispielsweise, lassen wir uns alarmieren und bekommen entweder einen Anruf, eine SMS oder eine E-Mail. So können unsere MyEngineers schnell reagieren und an der Behebung des Problems arbeiten.

 

4 Gründe, weshalb Du die Icinga Master App benötigst

1. Icinga Web

Dort kannst Du Dir den Gesundheitszustand Deiner Hosts und Dienste anzeigen lassen und Dir einen Überblick über Deine Infrastruktur machen.

2. Einbindungen

Wir bieten Integrationen für Windows und die gängigsten Linux-Distributionen an.

3. Konfiguration

Du kannst selbst Deine Hosts und Dienste ganz einfach mit dem Icinga Master konfigurieren. Aber auch wir bieten Dir eine Reihe von vorkonfigurierten Prüfungen an, wie z. B. grafische Metriken aus Grafana anzeigen lassen, um Lastspitzen zu erkennen.

4. Wartungen und Updates

Wie bei allen anderen Apps auch, übernehmen wir alle Wartungen und Updates Deiner App. Sodass Du Dir überhaupt keine Gedanken um den aktuellen Stand Deiner App machen brauchst. Aber keine Sorge: natürlich wir informieren Dich, sobald wir loslegen!

Falls Du Dir nicht ganz sicher bist, kannst Du gerne unsere App ausgiebig testen. Alle Apps stehen Dir 30 Tage lang kostenlos zur Verfügung. Du musst in diesem Zeitraum auch kein Zahlungsmittel hinterlegen – weil Abofallen gibt es bei uns nicht 😉 Wenn Du interessiert bist und die App kostenlos testen möchtest und Hilfe bei der Registrierung brauchst, kannst Du Dir auch gerne meinen BlogPost How to NWS: Von der Anmeldung bis zum Starten Deiner Anwendung anschauen.

 

Hast Du Fragen?

Wenn Du irgendwelche Fragen hast, kannst Du Dich natürlich immer bei uns melden – Du hast die Möglichkeit, unser Kontaktformular zu verwenden, uns eine E-Mail zu schreiben oder uns in den Geschäftszeiten anzurufen (+49 911 92885-0).

Leonie Pehle
Leonie Pehle
Junior Sales Manager

Leonie ist seit September 2019 bei NETWAYS und macht eine Ausbildung zur Kauffrau für Büromanagement. In ihrer Freizeit ist sie aktive Hobbyfotografin, immer auf der Suche nach dem perfekten Schnappschuss. Darüber hinaus ist sie immer im Stadion zu finden,  wenn der 1.FC Nürnberg spielt.