Unternehmen wollen ihre Daten in der Cloud gesichert und geschützt wissen. Dazu brauchen sie Regeln, die festlegen, wer die Cloud-Ressourcen wie nutzen darf. Diese Cloud Governance muss vorliegen, noch bevor die erste virtuelle Maschine (VM) erstellt wird. Neben Namenskonvention und rollenbasierter Zugriffskontrolle sollten mindestens auch Struktur und Kostenverrechnung geregelt werden.

In Microsoft Azure beispielsweise können Unternehmen die Struktur für die Cloud festlegen. Sie unterteilt sich in virtuelle Rechenzentren, sogenannte Subscriptions, in denen Nutzer Ressourcen erstellen können. Von diesen in sich geschlossenen, logischen Einheiten, lassen sich auch mehrere anlegen. Der Vorteil dabei ist: Virtuelle Netze und VMs in verschiedenen Subscriptions können standardmäßig nicht miteinander kommunizieren. Geht ein Test in einem virtuellen Rechenzentrum schief, hat das keinen Einfluss auf den produktiven Betrieb einer Fachabteilung in einem anderen.

Die Anforderungen der Abteilungen an Infrastruktur und Schutzstandard unterscheiden sich häufig. Um ihnen die jeweils benötigten Dienste zur Verfügung zu stellen, ist eine übergeordnete Struktur erforderlich. Solch eine Hierarchie können Firmen innerhalb eines Azure-Enterprise-Vertrages festlegen. Mit dem Vertragswerk können Abteilungen, Konten und Subscriptions gesteuert werden. Die Hierarchie lehnt sich an der Abteilungsstruktur, dem globalen Aufbau oder der Verteilung von Verantwortlichkeiten in der Organisation an.

Mithilfe mehrerer Subscriptions lassen sich auch Zuständigkeiten trennen und Rechte vergeben. Ein internationaler Konzern baut so für jedes Land eine eigene Abteilung auf. In jeder Abteilung können dann Accounts definiert werden, die befugt sind, Subscriptions anzulegen. Darauf dürfen dann aber nur die Mitarbeiter des entsprechenden Landes zugreifen. Die rollenbasierte Zugriffskontrolle ist dafür das richtige Mittel. Sie trägt zudem zum einfacheren Aufbau innerhalb der virtuellen Rechenzentren bei.

Ressourcen zusammenhängend benennen

Steht die Struktur der Cloud fest und sind Berechtigungen verteilt, gilt es, Regeln für die Benennung der gebuchten Cloud-Services festzulegen. Ein solches Namenskonzept ist wichtig, um zusammengehörige Ressourcen zu erkennen, etwa um sie zu löschen, oder beim Ersteller abzurechnen. Hintergrund ist, dass eine einzige VM meist die Erstellung weiterer Komponenten wie Netzwerk, Subnetz, Netzwerkkarte, Storage-Account, öffentliche IP-Adresse und eine Firewall mit sich bringt. Eine solche Namenskonvention ist besonders dann von Vorteil, wenn Unternehmen produktive Systeme mittels Templates oder Skripten wie PowerShell anlegen. Namen, die nicht richtig an das Skript weitergereicht werden, erstellt das System automatisch. Das zugehörige virtuelle System zu einer Netzwerkkarte "NIC2345" lässt sich dann nur noch schwer finden, was die interne Abrechnung und Verwaltung der gebuchten Dienste verkompliziert.

Jede Ressource muss in Azure einer Ressourcengruppe zugeordnet sein. Auch dort findet das Namenskonzept Anwendung. Die Systeme werden meist entsprechend des traditionellen IT-Ansatzes zusammengefasst. Das heißt, Komponenten mit dem gleichen Lebenszyklus werden gruppiert. Eine Anwendung ist jedoch mehrschichtig und agile Programmierung zieht unterschiedliche Lebenszyklen nach sich. In diesem Fall wird nach Web-, Applikations-, Datenbank- und Deployment-Schicht getrennt und dafür jeweils eine eigene Ressourcengruppe angelegt.

Für Ressourcen und Ressourcengruppen können Anwender zudem Tags vergeben. Auch hier gilt die Namenskonvention. So lassen sich Storage-Account, Netze, VMs oder anderes schnell wiederfinden und zuordnen. Die Tags können Unternehmen in Templates hinterlegen und abfragen. Microsoft empfiehlt grundsätzlich mindestens drei Tags pro Ressourcengruppe: Besitzer, Abteilung und Umgebung. Bei Ressourcen ist es sinnvoll, einen Tag für den Administrator anzulegen, der die Datenbank verantwortet. Solch ein als Schlüssel-Wert-Paar angelegter Tag für eine Komponente lässt sich auch in die Abrechnung übertragen. Angefallene Kosten können so zugeordnet werden.

Laufende Systeme schützen

Resource Manager Policies legen auf der Ressourcengruppen- oder Subscription-Ebene fest, welche VM-Größen dort erlaubt sind. Über Auditierungslogs lassen sich damit auch andere Zugriffe regeln, sie stoßen automatisierte Freigabeprozesse an. Eine solche Policy dient auch dazu, Nutzer zu zwingen, beim Buchen eines Dienstes den Verantwortlichen und die Kostenstelle zu taggen. Mithilfe von Resource Manager Policies können Organisationen also regeln, wer, welche Cloud-Komponenten anlegt.

Schützen lassen sich die gebuchten Dienste mit Resource Locks. Sie regeln, wer eine Komponente löschen darf. Ein System, ein Netzwerk oder einen gebuchten Dienst kann niemand außer dem Ersteller löschen, wenn der Wert auf "cannot delete" steht. Um den Resource Lock abzuschalten wird eine Berechtigung benötigt. Diese liegt im Normalfall beim Besitzer der Ressource. Die Rolle User-Access-Administrator ermöglicht aber zum Beispiel auch der IT-Leitung Systeme zu sperren und freizugeben. Die Einstellung "read only" verhindert Änderungen an einem System.

Automatisiert Regeln durchsetzen

Durch Automatisierung können Unternehmen sicherstellen, dass die Mitarbeiter sich an die Regeln im Cloud-Governance-Konzept halten. Die Namenskonvention lässt sich etwa mit PowerShell-Funktionen oder Templates durchsetzen, die nur erlaubte Benennungen zulassen. Mit Templates definieren Firmen außerdem wie eine VM zu erstellen ist, und welche Komponenten Nutzer in welchen Regionen erzeugen dürfen. Organisationen haben auch die Möglichkeit die Ressourcenverwaltung in das IT-Service-Management zu integrieren. Dann beantragen die Anwender Ressourcen über ein Service-Management-Werkzeug wie ServiceNow oder Microsoft Service Manager. Das Werkzeug setzt regelkonforme Skripte oder Templates zur Verarbeitung der Anfragen ein.

Die Vorbereitung für ein Cloud-Governance-Konzept klingt nach viel Arbeit. Wer sich jedoch davor drückt, verliert schnell die Kontrolle über die Cloud. Die nachträglichen Aufräumarbeiten bedeuten jedoch noch größeren Aufwand. (hal)