Die wenigsten Administratoren würden sich freiwillig mit dem Thema Compliance beschäftigen. Kein Wunder: Wer gerne mit aufregender, neuer Technik arbeitet, tut sich mit spröder Bürokratie und dem Abarbeiten von Checklisten, wie sie im Compliance-Kontext oftmals vorkommen, eher schwer. Kaum ein Administrator stellt allerdings in Frage, dass dieses Thema für Unternehmen wichtig ist und gerade in größeren Firmen sogar essenziell. Dank DSGVO und Co. beäugen die Aufsichtsbehörden Unternehmen heute viel kritischer, als es noch vor ein paar Jahren der Fall war.

Ein Super-GAU in Sachen Security lässt sich heute praktisch nicht mehr verheimlichen und kommt Firmen im blödesten Fall teuer zu stehen. Für Administratoren ist das alles allerdings eher abstrakt – sie sind mit der Herausforderung konfrontiert, Compliance ganz konkret zu implementieren. Ihnen fällt also die Aufgabe zu, das Regelwerk, das sich Anwälte, Datenschutzbeauftragte und angrenzende Berufe ausgedacht haben, auf den eigenen Systemen in konkrete Technik zu transformieren.

Auf dem eigenen Terrain stellt Compliance für den Admin nur selten ein Problem dar. Oftmals existiert auch bereits ein entsprechendes Regelwerk im Unternehmen. Die Benutzerverwaltung geschieht zum Beispiel zentral per LDAP oder Active Directory. Sollte ein Mitarbeiter das Unternehmen verlassen, wird sein Benutzerkonto automatisch entfernt – ohne die mit dem Account verbundenen Daten gleich zu löschen, was gerade dann von Bedeutung ist, wenn gesetzliche Aufbewahrungsfristen das nicht explizit verbieten. Software-Deployments? Zugriff auf die Firmeninfrastruktur? Die Nutzung bestimmter Dienste?

All diese Details sind heute in vielen Firmen zentral auf der bürokratischen wie auf der technischen Seite implementiert. Der große gemeinsame Nenner ist dabei, dass sich Aktivität stets auf der Ebene der Infrastruktur abspielt, die dem Unternehmen unmittelbar gehört und diesem in den eigenen Räumlichkeiten exklusiv zur Verfügung steht.

Und dann kam die Cloud: Firmen möchten sich nicht mehr ausschließlich auf die eigene Infrastruktur im eigenen Rechenzentrum verlassen. Zu bequem ist die Möglichkeit, bei den Hyperscalern billige Instanzen ad hoc zu starten und zu benutzen – nur so lange wie benötigt. Dabei spielt der Preis noch nicht mal die zentrale Rolle. Compute & Co. bei AWS, Azure oder Google sind per se nicht billiger als eigene Infrastruktur. Der Gamechanger ist die Dynamik und Flexibilität, mit der Admins bei den Hyperscalern Ressourcen beschaffen können. Regelmäßig finden sich in modernen IT-Firmen heute hybride Workloads: Den Großteil der Aufgaben erledigt darin weiterhin die lokale Infrastruktur. Compute-intensive Aufgaben wie Numbercrunching lagern die jeweiligen Firmen hingegen aus.

IT-Verantwortlichen fährt eingedenk hybrider Umgebungen regelmäßig der Schreck in die Glieder, denn Compliance ist dann ein viel komplexeres Thema als auf lokaler Infrastruktur. Administratoren stellen sich diesbezüglich vielleicht folgende Fragen:

- Wie lässt sich das Accountmanagement einer Firma auf die Cloud ausdehnen?

- Wie ist sichergestellt, dass nicht Daten auf Servern von Amazon landen, die dort keinesfalls hingehören?

- Wie verhindert eine Firma, dass ein Administrator versehentlich mehrere große Compute-Instanzen unbemerkt startet und so eine gigantische Rechnung produziert?

Um Compliance in hybriden Umgebungen erfolgreich umzusetzen, benötigen IT-Verantwortliche die richtigen Regeln und die entsprechenden Werkzeuge.

Stellt man sich die AWS- oder Azure-Accounts von Unternehmen als verlängerte Werkbank des eigenen Unternehmens vor, wird schnell klar: Das Benutzerregime, das auf der eigenen Infrastruktur läuft, muss in irgendeiner Weise auch in der Cloud implementiert sein. Das hat einerseits praktische Gründe. Wenn der Kollege Niemeyer sich namens und im Auftrag einer Firma mal eben einen AWS-Account anlegt und darin virtuelle Instanzen betreibt, ist das für den Augenblick in Ordnung. Doch wer kümmert sich um den Workload, wenn Herr Niemeyer das Unternehmen verlässt? Erfolgt die Trennung nicht im Guten, nimmt Niemeyer das Passwort für den Account schlechtenfalls mit und versperrt den ehemaligen Kollegen so den Zugang. Parallel zur praktischen Sicht kommt hier auch eine rechtliche Komponente ins Spiel: Gerade bei einer ungütlichen Trennung hat das Unternehmen schließlich ein Interesse daran, den Zugriff Niemeyers auf die Daten in der Public Cloud schnell und zuverlässig zu unterbinden.

Daraus ergibt sich zwangsläufig die Notwendigkeit, die eigenen Benutzerkonten auch in die Cloud zu bringen. Die gute Nachricht ist: Alle Hyperscaler bieten hierfür Möglichkeiten, manche sogar mehrere verschiedene Wege zum Ziel. Weil in einigen Unternehmen das Active Directory als zentrales Benutzerverzeichnis zum Einsatz kommt, liegt es nahe, sich zunächst mit diesem zu beschäftigen und mit dessen Integration in Microsofts Clouddienst Azure.

Das Active Directory steht in Microsofts Cloudumgebung gleich in mehreren Varianten zur Verfügung. Azure Active Directory (Azure AD) hat mit dem klassischen Active Directory allerdings nur wenig zu tun. Letzteres ist ein vollständiger Verzeichnisdienst, der neben der Verwaltung von Benutzerzugängen mitsamt ihren Passwörtern auch ein rollenbasiertes Zugriffsmodell (RBAC) und vollständige Organizational Units bietet. Azure AD hingegen fungiert mit einer REST-Schnittstelle eher als Passworttresor in der Wolke. Allerdings lässt sich eine Azure-AD-Instanz problemlos an ein On-Premises-Active-Directory koppeln. Ob das sinnvoll ist, hängt vom konkreten Einsatzszenario ab: Anwendungen, die das von Azure-AD feilgebotene SSO-Feature nutzen können, profitieren von der Lösung natürlich immens. Für Legacy-Anwendungen, die nicht über eine entsprechende Anbindung verfügen, bietet Microsoft immerhin eine Art Kompatibilitätsgateway mittels HTTP-Basis-Authentifizierung. All diese Dienste zu nutzen, lohnt sich allerdings nur, wenn ein Unternehmen tatsächlich Anwendungen in der Cloud betreibt und dort nicht nur Compute "hinter den Kulissen" konsumiert.

Etwas anders sieht es aus, wenn Unternehmen ihre Accounts in AWS selbst aus einer externen Datenquelle wie Active Directory oder LDAP beziehen. Die Hyperscaler bieten diese Funktion allesamt an, wenn zum Teil auch hinter nicht ganz leicht zu durchdringenden Frontends. Am elegantesten geht Microsoft vor: Hier ist es wieder Azure Active Directory, das die Integration mit Azure übernimmt. Das Unternehmen wird an dieser Stelle indirekt gezwungen, eine Azure-AD-Instanz aufzusetzen und diese mit der On-Premises-Installation der Active Directory Domain Services (ADDS) zu verbinden. Praktisch: Meldet sich ein Nutzer am Active Directory des eigenen Unternehmens an, greift die SSO-Funktion, die ihn zugleich auch in der Cloud authentifiziert. Auf demselben Weg kann er im Anschluss Funktionen in Azure aufrufen.

Komplizierter liegen die Dinge bei AWS. Der Anbieter hat wie Microsoft auch eine Active-Directory-Integration im Portfolio. Hier stehen dem Admin aber mehrere Optionen zur Verfügung. Variante 1 ist "Active Directory Connect": Das ist ein spezieller AWS-Dienst, der sich unmittelbar mit einem On-Premises-AD verbindet und die Anmeldung und Authentifizierung von Nutzern darüber erledigt. Wie Microsoft bietet auch Amazon alternativ eine eigene AD-Instanz namens "AWS Directory Service". Diese fußt im Kern ebenfalls auf Microsoft Active Directory und verfügt über ähnliche SSO-Fähigkeiten wie das Pendant bei Microsoft selbst. Sowohl bei Azure als auch bei AWS findet übrigens keine Synchronisation von Daten in die Cloud statt – für viele Firmen ein wichtiger Faktor: Sinn und Zweck von Compliance in der Cloud ist es ja gerade, den Abfluss von Daten in die Hände (unberechtigter) Dritter zu unterbinden. Wer hybride Setups nutzt und die eigene Benutzerverwaltung auf solide Füße stellen will, sollte früh mit den Planungen beginnen, das eigene AD (oder äquivalent LDAP) direkt mit der jeweiligen Schnittstelle des Hyperscalers zu verbinden.

Eine fortwährende Gefahr beim Nutzen hybrider Setups ist das versehentliche Hochladen von Daten zu AWS & Co., die dort nichts zu suchen haben. Zur Erinnerung: Nach aktueller Rechtslage gelten die europäische Datenschutzgrundverordnung (DSGVO) und der CLOUD Act der USA bis heute als inkompatibel. Unter Juristen ist insofern strittig, ob es selbst mit bestehendem Auftrag zur Datenverarbeitung legitim ist, Daten auf den Servern eines Unternehmens zu parken, das unter der Jurisdiktion der USA steht und letztlich auf Zuruf der US-Regierung auskunftspflichtig ist. Wer keine eigene Infrastruktur betreibt und sich nur auf die Hyperscaler verlässt, dem stellt sich die Frage freilich nicht.

Wer hingegen nur Teile seines Workloads in die Cloud packt oder sporadisch in der Cloud Compute-Ressourcen bucht, findet hier einen potenziellen Stolperstein. Und der ist alles andere als einfach zu beseitigen. Die schlechte Nachricht ist: Software mit eingebauer Logik, um "gute Daten" und "schlechte Daten" voneinander zu unterscheiden und nur die guten in die Welt zu versenden, existiert ab Werk praktisch nicht. Freilich kann der Admin sich passende Funktionalität auf verschiedenen Wegen nachrüsten. Am Ende ist die zentrale Frage allerdings, ob ein Deployment-Werkzeug für hybride Workloads zum Einsatz kommt, was dieses leistet und ob es entsprechende Funktionen vorhält.

Die Kostenvermeidung ist durchaus ein Faktor von Compliance – ebenso wie etwa die Frage, ob der Admin Daten, die er in eine Public Cloud geladen hat, unfreiwillig wegen einer Fehlkonfiguration mit der Welt teilt. Um allzu große Probleme zu vermeiden, bieten Amazon wie Microsoft Werkzeuge, um Nutzern die Daumenschrauben anzulegen. Die bereits beschriebene Integration mit einem lokalen Benutzerverzeichnis spielt dabei erneut eine zentrale Rolle. Denn über die zentrale Benutzerverwaltung haben Administratoren die Option, für bestimmte Benutzerzugänge Gruppen festzulegen und Berechtigungen zu erteilen, von denen bestimmte Features in den Hyperscaler-Umgebungen sich in einem weiteren Schritt abhängig machen lassen. Anders formuliert: Wer im heimischen AD Mitglied der richtigen Rollen ist, darf bei entsprechender Konfiguration auch in der Cloud bestimmte Dinge oder eben nicht. Ein zentrales Werkzeug für die Umsetzung etwaiger Compliance-Vorschriften ist dabei in AWS der Control Tower und in Azure das Azure Security Center.

Wie üblich im Kontext der Hyperscaler hat Amazon einen gewissen Vorsprung: Den AWS Control Tower gibt es bereits seit einiger Zeit, er hat sich also über die Zeit entwickelt und ist älteren Datums als das Azure Security Center. Das muss aber nicht zwingend ein Vorteil sein – denn wie so häufig bei AWS-Funktionen ist auch beim Control Tower das Featureset mittlerweile so groß, dass Admins die Komplexität des Produkts schnell über den Kopf wächst. Die Idee hinter dem Control Tower ist ungefähr jene: Jeder einzelne Arbeitsschritt eines Anwenders soll durch verschiedene Kategorien von Maßnahmen steuer-, kontrollier- und am Ende auch sanktionierbar sein. Ein paar Beispiele aus der Praxis verdeutlichen dies.

Anhand der Zugehörigkeit zu einer bestimmten Gruppe lässt sich im Control Tower für Nutzer etwa festlegen, ob sie Dateien im REST-Speicher S3 von AWS auf "public" stellen dürfen. Dateien in diesem Modus erlauben den Zugriff ohne jeden Schutz etwa durch ein Passwort. Den Abfluss der Daten in Richtung AWS vermeiden Admins so also nicht. Wohl aber, dass sich durch allzu großzügige Rechtevergabe Daten durch unbefugte Dritte per HTTPS herunterladen lassen. Die Liste der Beispiele lässt sich hier beinahe beliebig fortsetzen, denn AWS Control Tower bietet unzählige Stellschrauben. Zum Beispiel für den Fall, dass einzelne Nutzer oder Gruppen spezifische AWS-Dienste oder AWS-Ressourcen nicht verwenden sollen. Oder wenn spezifische Quotas bis auf die Ebene einzelner Benutzerzugänge gelten sollen. Wer es gewohnt ist, die eigenen Ressourcen und gerade die eigenen Benutzer zentral zu verwalten, sollte in hybriden Setups unbedingt auf einen zentralen Steuermechanismus zurückgreifen.

In Azure gibt es keinen Control Tower, sondern das Azure Security Center. Dass Microsoft sich vom Produkt der Konkurrenz hat zumindest beeinflussen lassen, liegt klar auf der Hand, auch wenn sich im Detail Unterschiede ergeben. Die Stoßrichtung ist indes dieselbe: Per Azure Security Center soll der Admin in Azure seinen Nutzern ebenso auf die Finger schauen können, wie es in AWS der Fall ist. Azure akzentuiert das Thema Sicherheit derzeit allerdings stärker, indem es mehr Hebel und Knöpfe dafür bereitstellt als etwa für die Kontrolle von ausufernden Kosten – die bei AWS Tower wiederum ebenfalls eine große Rolle spielt.

Vor die größte Herausforderung stellt Admins in hybriden Umgebungen regelmäßig die Anforderung, VMs in den Hyperscalern mit denselben Sicherheitseinstellungen zu betanken, wie es auf der eigenen Infrastruktur etwa bei echtem Blech der Fall ist. Das ergibt sich aus der Natur der Dinge: Lokale Compliance-Kataloge sind oft das Ergebnis eines jahrelangen Prozesses. Sie sind außerdem in aller Regel an spezifische Vorgaben vor Ort angepasst.

Bei einer AWS-Instanz, die der Admin sich mal eben erstellt, ist das naturgemäß anders. Sie kommt aus einem generischen Abbild – Ubuntu, Red Hat, CentOS oder Ähnliches – und gleicht wie ein Ei dem andern. Rollt der Admin in einer solchen Cloudinstanz nur die Software aus, die er braucht, bleibt ein großer Teil der Vorgaben der Compliance-Abteilung mit hoher Wahrscheinlichkeit auf der Strecke. Hier rächt sich, dass viele Unternehmen heute noch immer nicht gnadenlos auf Automation mit entsprechenden Werkzeugen setzen, sondern Golden Images verwenden, die sie dann über Jahre für die Grundinstallation neuer Systeme verwenden. Will der Admin hier verhindern, dass in Sachen Compliance ein Chaos ausbricht, muss er mehrere Werkzeuge und Prinzipien miteinander verbinden. Das Um und Auf in entsprechenden Situationen ist Automation.

Admins sollten sich die Relevanz von Automation in hybriden Umgebungen immer wieder vor Augen führen. Nur sinnvolle Automation ermächtigt, virtuelle Instanzen in öffentlichen Clouds exakt so wie on-premises zu gestalten. Gute Automatisierer bieten die Möglichkeit, spezifische Anpassungen in VMs je nach Plattform zu installieren, in der das Deployment geschieht. Viele Automatisierer sind heute sogar selbst in der Lage, Ressourcen in Clouds anzulegen. Das ist besonders praktisch: Nutzt der Admin für seine On-Premises-Infrastruktur Ansible, kann er aus Ansible heraus auch gleich VMs in Azure oder AWS ausrollen und dieselben Playbooks und Einstellungen für diese verwenden.

Ein paar Besonderheiten sind dabei freilich zu beachten – und eine betrifft wieder das lästige Thema Benutzer- und Rechteverwaltung. Denn direkter Zugriff aus der Cloud heraus auf ein On-Premises-Benutzerverzeichnis wird nur in den seltensten Fällen funktionieren. Undenkbar ist es zwar nicht, denn Azure und AWS bieten etwa auch VPN-Verbindungen direkt in den eigenen Account innerhalb der Wolke an – die meisten Unternehmen werden diese technische Mühe allerdings nicht auf sich nehmen. Verbindet eine Firma allerdings den AWS Directory Service oder Azure AD mit dem eigenen Benutzerverzeichnis, wird dieses aus der Cloud heraus verfügbar. Es lässt sich dann auch mit der Kerberos-Integration in Linux verbinden. Microsoft beschreibt diesen Vorgang unter [1] sehr detailliert. So gelingt ein durchgreifendes Compliance-Regime auf der Benutzerebene.

Schließlich empfiehlt es sich aus Sicht des Admins, ein Werkzeug einzusetzen, das die lokalen Instanzen so wie jene in der Cloud regelmäßig überwacht und bei Problemen Alarm schlägt. Dazu bietet sich beispielsweise InSpec von Chef an. In der Ausgabe 09/2020 des IT-Administrator [2] haben wir gezeigt, wie sich Compliance mit Chef InSpec automatisieren lässt. InSpec bietet einen großen Vorteil: Die Compliance-Regeln, die es auf Systemen überwachen soll, lassen sich in einer eigenen deklarativen Skriptsprache definieren.

Einerseits finden sich für InSpec im Netz diverse Verzeichnisse fertiger Regelwerke, die sich zum Teil an den großen Zertifizierungen orientieren (etwa ISO27001 oder BSI-Grundschutz). Andererseits hat der Admin natürlich die Möglichkeit, eigene Compliance-Regeln in InSpecs DSL zu definieren und automatisch auf den eigenen Systemen prüfen zu lassen. Das Tool bietet sich damit auf der Ebene einzelner Instanzen als Gegenpart zu Ansible Tower oder Azure Security Center an, deren Schwerpunkt eher auf den Ressourcen der jeweiligen Plattform selbst liegt.

Compliance in hybriden Umgebungen ist ein komplexes Thema. Sinnvoll geht der Admin vor, wenn er drei Ebenen miteinander kombiniert. Zunächst sollte die Benutzerverwaltung mit der Cloud verbunden sein, damit bei der Login- und Gruppenverwaltung kein Chaos ausbricht. In Bezug auf virtuelle Instanzen in der Cloud muss der Fokus des Admins schließlich auf Werkzeugen wie InSpec liegen, in aller Regel mit einem selbstverfassten Regelwerk. Wichtig ist außerdem, so viel wie möglich in hybriden Umgebungen zu automatisieren. Automatisierung erleichtert die Einhaltung von Compliance-Regeln einerseits schon durch eine geringere Fehleranfälligkeit auf den einzelnen Systemen – sie verhindert aber vor allem, dass einzelne Systeme "vergessen" werden. Eine CI/CD-Toolchain, die neue Instanzen in Clouds automatisiert ausrollt, kann diese mit dem passenden Compliance-Schutz versehen.