Remote First aus Infrastruktur-Perspektive

Die Corona-Pandemie stellt viele Unternehmen vor völlig neue organisatorische, technologische und kulturelle Herausforderungen. In diesem Artikel geben wir einen Einblick, wie wir für inovex eine Infrastruktur geschaffen haben, mit der wir im Geschäftsbetrieb von nahezu überall arbeitsfähig sind.

Durch unser Projektgeschäft ergaben sich Anforderungen, denen wir uns bereits vor vielen Jahren stellen mussten, und die maßgeblich Einfluß auf die heutige Infrastruktur von inovex hatten.

Remote first, Home Office second

Unsere Mitarbeiter:innen arbeiten nicht nur bundesweit an unseren Standorten, sondern auch beim Kunden vor Ort in den jeweiligen Projekten. Für uns stand früh fest, dass wir einen umfassenden, effizienten und standortunabhängigen Zugriff auf unsere IT-Services gewährleisten möchten.

Der Zugriff umfasst Zeiterfassungssystem und Projekttools genauso wie unser inovex-weites Slack, das es ermöglicht, aus der Ferne am inovex-Alltag teilzuhaben und auf das Wissen der gesamten Firma zurückzugreifen. Darüber hinaus gibt es eine Vielzahl weiterer Fälle, bei denen eine möglichst uneingeschränkte Nutzung der inovex-Services aus der Ferne für die Mitarbeiter:innen wichtig ist.

Schnell wurde klar, dass diese Anforderungen verteilter Standorte zu einem großen Teil deckungsgleich mit den Anforderungen im Home Office sind. Aus diesem Grund haben wir uns dazu entschlossen, nicht weiter zu unterscheiden und eine Lösung zu schaffen, die einen sicheren, skalierbaren Zugriff auf alle inovex-IT-Services bietet – völlig unabhängig davon, ob man sich beim Kunden, im Home Office oder auf Geschäftsreise befindet.

Schlanke IT an den Standorten

Wir haben uns dazu entschlossen, an den Standorten möglichst wenig Infrastruktur und Services zu betreiben, da diese dort teilweise schwer zu betreuen sind und die Standorte keine ausreichende Hosting-Infrastruktur bieten. Stattdessen legen wir Wert auf eine skalierbare, hochverfügbare, zentrale Infrastruktur in unserem Rechenzentrum. Das Rechenzentrum ist so konzipiert, dass wir alle Aufgaben aus der Ferne erledigen können. Arbeiten, wie z.B. der Tausch einer Festplatte, werden von Techniker:innen vor Ort durchgeführt (Remote Hands & Eyes). Neben den Services in unserem Rechenzentrum nutzen wir, wie viele andere Unternehmen, eine Reihe von SaaS-Diensten für unsere alltägliche Arbeit.

VPN first, besonders für Admins

Wir unterscheiden beim Zugriff auf unsere Systeme nicht zwischen einem Zugriff via VPN und einem Zugriff über die Netzwerke an unseren Standorten. Ein:e inovex-Mitarbeiter:in kann über das inovex-VPN die gleichen Services erreichen, die sie/er aus jedem Standortnetz erreichen kann. Das VPN stellt quasi einen virtuellen Standort bereit. Grundsätzlich basiert die Anbindung der Standorte auf der gleichen Technologie wie die Anbindung der VPN Clients. Alle VPN Clients können ausschließlich auf ausgewählte Frontend-Service-Endpunkte zugreifen, die alle nochmal extra über personalisierte Accounts abgesichert sind.

Generell haben wir uns dazu entschlossen, den Zugriff auf administrative Schnittstellen – egal ob von den Standorten oder remote – ausschließlich über personalisierte Admin-VPN-Clients zu erlauben. Ein Vorteil ist hierbei, dass der Zugriff auf die sensiblen Systeme immer mehrfach abgesichert ist, da Clients sich zuerst am Admin-VPN-Server authentisieren müssen, bevor Schnittstellen über verschlüsselte Verbindungen erreicht werden können. Zusätzlich muss sich der Admin nochmal an der jeweiligen Schnittstelle anmelden.

VPN als SPOC oder Bottleneck

Bei einer derart intensiven VPN Nutzung ist es wichtig, dass die VPN-Infrastruktur entsprechend skalierbar und ausfallsicher ist. Wir haben uns dazu entschlossen, mehrere VPN Server in unsere Infrastruktur zu integrieren, die sowohl für die Skalierbarkeit als auch für die Ausfallsicherheit sorgen. Fällt ein VPN Server aus, verbinden sich die Clients mit den verbleibenden Servern erneut. Jeder Server hat darüber hinaus seinen eigenen Client-Address-Pool, damit immer ausreichend IP-Adressen für alle VPN User zur Verfügung stehen.

Silver Bullet VPN?

Unser VPN Ansatz löst leider nur einen Teil der Probleme und schafft natürlich auch neue – so muss der VPN Client eingerichtet und gestartet sein und natürlich müssen die VPN Clients Zugriff auf unsere VPN Endpunkte haben, was in sehr restriktiven Kundenumgebungen ggf. problematisch ist. Da man Cloud Services in der Regel über das Internet erreichen kann, muss der Zugriff auch mit eingeschränktem Internetzugang funktionieren – hier kann das inovex Client VPN helfen. Die öffentlich zugänglichen Cloud Services selbst kann man natürlich durch ein VPN nicht absichern und muss daher für den sicheren Zugriff andere Maßnahmen ergreifen.

SSO, IdM und 2FA

Bei diesen Abkürzungen handelt es sich nicht um einen neuen Song der fantastischen Vier, sondern um einen Weg, der eine nahtlose und sichere Integration von verschiedenen Services – egal ob im eigenen RZ oder in der Public Cloud – ermöglicht.

SSO steht für Single Sign On und ermöglicht einen einheitlichen, Service-übergreifenden Login. User müssen nicht in jedem Service einzeln angelegt werden, sie werden zentral über einen sogenannten Identity Provider bereitgestellt. Der Identity Provider wiederum greift auf die Datenbasis eines Identity Management Systems zurück. In diesem werden alle User einer Organisation verwaltet. Möchte man einen Service (in SSO-Sprache Service Provider) anbinden, so muss dieser entsprechend Zugriff auf den Identity Provider erhalten.

Über das SAML-Protokoll kann der Identity Provider (z.B. Keycloak oder Microsoft ADFS) dem Service Provider zusätzlich Information (Attributes) wie z.B. Name, Vorname oder Gruppenzugehörigkeit, zur Verfügung stellen. Ist die Einrichtung erfolgt, kann sich ein User der Organisation zukünftig mit seinem Organisationskonto bei dem Service anmelden. Nutzer:innen werden dabei vom Service zuerst an den eigenen Identity Provider weitergeleitet und dort authentisiert. Ist der Login erfolgreich, werden Nutzer:innen an den Service zurückgeleitet und sind direkt angemeldet. Das System hat mehrere Vorteile: Das Passwort wird nur an die organisationsinternen Login-Seiten übermittelt und ist dem Service Provider nicht bekannt. Außerdem entfällt die Login-Prozedur wenn User bereits in ihrem Browser über eine gültige Identity Provider Session verfügen – der Service kann direkt und ohne Umwege genutzt werden.

Da der Login-Prozess nur durchlaufen werden muss, wenn keine Session existiert, müssen User ihre Login-Daten deutlich seltener eingeben. Dadurch steigt auch die Akzeptanz für eine 2-Faktor-Authentifizierung erheblich. Bei einer mehrstufigen Authentifizierung werden neben dem Passwort weitere Faktoren für eine erfolgreiche Authentifizierung abgefragt. Sind diese Faktoren dynamisch und werden unabhängig vom Passwort vorgehalten, nützt es Angreifern nichts, das Passwort abzugreifen, da dann der 2. Faktor zwingend erforderlich ist. Der gängigste 2. Faktor ist ein zeitbasierter Token nach dem TOTP-Verfahren, der z.B. mit einer App wie dem Google Authenticator berechnet werden kann und während des Logins vom Server gegengeprüft wird.

Sicherheit

Um Sicherheit gewährleisten zu können und Services vor ungewollten Zugriffen zu schützen, reicht natürlich ein SSO, auch mit 2. Faktor, alleine nicht aus. Genauso wichtig wie der Login-Mechanismus ist die Absicherung und regelmässige Aktualisierung der Systeme sowie deren Überwachung durch Monitoring-Systeme. Gerade bei der Bewertung der Angebote von kleineren Cloud-Service-Anbietern empfiehlt es sich, hier ein besonderes Augenmerk auf das Thema Patch Management und Security zu legen. Die großen Anbieter haben diese Themen durch weitestgehend vollständig automatisierte Prozesse und eigene Security Response Teams mittlerweile recht gut im Griff. Selbstverständlich muss man das auch für die Services im eigenen RZ gewährleisten können. Der konsequente Einsatz von SSL- bzw. TLS-Verbindungen ist natürlich auch hier immer zwingend erforderlich, um die übertragenen Daten vor den Augen Dritter zu schützen und sollte heutzutage überall Standard sein.

Reproduzierbarkeit durch Infrastructure as Code

Ein wichtiger Schritt in Richtung sichere Infrastruktur ist die Abbildung der Systeme und Services mit Hilfe von Tools wie Terraform und Ansible, so dass möglichst keine manuellen Schritte für Provisionierung und Updates notwendig sind. Mit Terraform kann man eine Infrastruktur deklarativ beschreiben. Anschließend erstellt Terraform diese Infrastruktur, z. B. über die Schnittstellen einer Cloud-Plattform wie OpenStack oder Public Clouds wie AWS, Azure oder Google Cloud. Mit Ansible kann man neben den System-Tools und Monitoring-Agenten auch die Anwendungen auf den neuen Systemen ausrollen.

Administrative Abläufe, wie die Durchführung von Applikations-Updates oder das Patchen des Betriebssystems, werden in sogenannten Ansible Playbooks abgebildet und dadurch nachvollziehbar und reproduzierbar. Anschließend kann man den Terraform- und Ansible-Code in CI Pipelines integrieren und so die Abläufe noch stärker automatisieren.

Bei inovex nutzen wir Terraform um damit Umgebungen und Systeme in unserer OpenStack Cloud zu erzeugen. Mit Ansible verteilen wir die Anwendungen auf die Linux-Systeme, indem wir dort systemd Units anlegen, über die in der Regel Docker Container gestartet werden, die die Anwendungen beinhalten. Sowohl Terraform als auch Docker werden aus der Gitlab CI Pipeline gestartet. Für ein Versions-Update muss meist nur die Versionsnummer in den Ansible-Variablen angepasst werden und die neue Version wird automatisch nach einem git commit in der Infrastruktur ausgerollt. Auf diesem Weg können wir unsere Anwendungen jederzeit reproduzierbar aktualisieren – was z.B. im Falle von Gitlab bedeutet, dass wir wichtige Updates im Schnitt einmal pro Woche direkt nach der Veröffentlichung durchführen.

Reverse Proxies: die wahren Silver Bullets

Nicht alle Anwendungen können von Haus aus in eine SSO-Infrastruktur integriert werden. Um auch Anwendungen ohne direkte SSO-Unterstützung absichern zu können, kann man für diese Anwendungen einen Reverse Proxy nutzen, der für die Anwendung die SSO-Absicherung übernimmt und nach erfolgreicher Anmeldung am Identity Provider die Anfragen an die Anwendung weiter leitet. Durch name based virtual host kann ein Pärchen Reverse Proxy eine Vielzahl von nachgelagerten Hosts durch SSO absichern. Dieser gebündelte Eingangskanal bietet aus der Sicherheitsperspektive die Möglichkeit, extrem schnell auf sicherheitsrelevante Ereignisse reagieren zu können, selbst wenn ein Fehler in der eigentlichen Anwendung vielleicht noch gar nicht durch einen Patch behoben werden konnte.

Bei inovex nutzen wir meist Apache als Reverse Proxy in Kombination mit mod_security, mod_rewrite und mod_auth_mellon.

Die Zukunft ist VPNless

Hat man diese Themen im Griff, können die Enduser ohne VPN auf alle relevanten Services zugreifen, was die User Experience deutlich verbessert.

Für besonders schützenswerte Umgebungen und administrative Schnittstellen empfiehlt sich auch weiterhin die Nutzung eines VPNs, bei inovex ist das VPN heutzutage neben der Administration aber nur für sehr wenige interne Systeme notwendig und betrifft nur wenige Teams. Für die meisten Kolle:ginnen übernimmt das VPN mittlerweile eher die Aufgabe, für einen sicheren Zugang zum Internet zu sorgen, gerade wenn man mit fremden Netzen oder öffentlichen Hotspots verbunden ist.

Google verfolgt ebenfalls diesen Ansatz und hat hierfür den Begriff BeyondCorp geprägt – die Zukunft ist also VPNless und ermöglicht uns dadurch ein deutlich vereinfachtes, sicheres und standortunabhängiges Arbeiten. Dies nimmt durch die aktuellen Entwicklungen einen immer stärkeren strategischen Stellenwert ein. Bei der Einführung von neuen Technologien, Services und Prozessen achten wir darauf, dass wir uns diese Möglichkeit nicht wieder verbauen sondern sie immer weiterentwickeln. Mobiles Arbeiten ist ein zentraler Bestandteil unseres Business Continuity Plannings und aus dem normalen inovex-Alltag nicht mehr wegzudenken. Das sorgt neben einer großen Flexibilität letzten Endes auch für eine hohe Mitarbeiterzufriedenheit.

Übersicht über unsere Services

Join us!

Willst du diese Infrastruktur gemeinsam mit uns weiterentwickeln? Willst du bei verschiedensten Kunden Netzwerk- und Cloud-Strukturen umsetzen? Dann haben wir den passenden Job für dich!