Die Cloud benötigt klare Regeln und Strukturen

Der Trend ist eindeutig – fast alle Unternehmen treibt es in die Cloud. Doch damit die Unternehmen sich auf dem Weg dahin nicht verrennen, sollten sie noch vor dem ersten Schritt ein umfassendes Regelwerk für die virtuelle Welt schaffen.

Mit Cloud-Governance regeln Unternehmen, wer wo in der Cloud welche virtuellen Maschinen (VMs) anlegen und auch wieder löschen darf. Für seinen Cloud-Dienst Azure stellt Microsoft zum Beispiel mit dem Enterprise Scaffold Unternehmenskunden einen Handlungsleitfaden zur Verfügung (https://docs.microsoft.com/en-us/azure/azure-resource-manager/resource-manager-subscription-governance). Mit diesem Leitfaden lässt sich ein richtlinienkonformer Rahmen für den Einsatz von Cloud-Diensten in sogenannten Subscriptions grob abstecken. Eine Subscription ist dabei ein virtuelles Rechenzen­trum – eine in sich geschlossene logische Einheit, in der Anwender ihre Ressourcen erstellen und nutzen.

Um sicherzustellen, dass ein Administrator zum Beispiel nicht unabsichtlich ein SAP-System löscht oder mit einem Testsystem den produktiven Arbeitsbetrieb stört, lassen sich diese virtuellen und skalierbaren Infrastrukturen voneinander trennen und Zugriffsrechte darauf rollenbasiert ver­geben.

Mit Hilfe eines solchen rollenbasierten Zugriffsmodells legen die Unternehmen fest, welche Aufgaben ein Anwender auf seiner Hierarchieebene durchführen darf. Getrennte Anwendungen und Systeme erreichen Firmen, indem sie mehr als eine Subscription anlegen, denn virtuelle Maschinen und Netzwerke in unterschiedlichen Subscriptions können sich standardmäßig nicht miteinander austauschen. Sie sind komplett voneinander getrennt, etwa in ein produktives System für das Customer Relationship Management und ein Testsystem der IT-Abteilung.

Zudem können Unternehmen innerhalb eines Enterprise-Vertrags in Azure eine Hierarchie abbilden. Damit können Abteilungen, Konten und Subscriptions gesteuert werden. Die Cloud-Hierarchie kann sich je nach individuellem Bedarf beispielsweise an der Abteilungsstruktur des Unternehmens, der globalen Aufstellung eines Konzerns oder der Verteilung von Verantwortlichkeiten orientieren.

Die IT-Services, die sich innerhalb einer Subscription anlegen lassen, sind in Azure beschränkt: 200 Storage-Accounts und 50 virtuelle Netze sind möglich. Auch die Anzahl der CPU-Kerne und VPN-Verbindungen ist begrenzt – ein weiterer Grund, warum Unternehmen mit mehreren Subscriptions in der Regel besser fahren. Denn was sich zunächst nach viel anhört, ist für Unternehmen, die weltweit vertreten sind und Netzwerke aufbauen, schnell ausgereizt. Wer die Storage-Accounts pro virtueller Mschine anlegt, um Daten sauber zu trennen, hat auch hier die Grenze des Virtualisierungsspielraums schnell erreicht.

Während Unternehmen eine solche Struktur für die Cloud entwickeln, müssen sie sich gleichzeitig Gedanken über ein Namenskonzept machen. Mit einem solchen Konzept lassen sich später Zusammenhänge zwischen angelegten Komponenten herstellen. Erstellt jemand eine neue virtuelle Maschine, gehören dazu meist auch Netzwerk, Subnetz, Storage-Account, Netzwerkkarte, öffentliche IP-Adresse sowie eine Firewall. Diese müssen ebenfalls angelegt werden und brauchen entsprechende Bezeichnungen. Mit einem stringenten Namenskonzept lassen sich alle Komponenten, die zu einer virtuellen Maschine gehören, schnell zuordnen und, wenn sie nicht mehr gebraucht werden, auch gemeinsam mit ihr wieder löschen.

Ein weiterer Vorteil eines ordentlichen Namenskonzepts ist der Einsatz von Skripts wie PowerShell oder Templates. Firmen erstellen produktive Systeme vorzugsweise mittels dieser Skripts. Wenn die Namen dabei nicht korrekt an das Skript weitergegeben werden, erzeugt das System sie unter Umständen automatisch. Die so automatisch bezeichneten Komponenten lassen sich dann dem zugehörigen virtuellen System nur schwer zuordnen. Das beeinträchtigt nicht nur die Verwaltung der virtuellen IT-Infrastruktur, sondern auch die firmeninterne Abrechnung.

Beim Erstellen der Namenskonvention sind zudem Ressourcengruppen einzuplanen, denn in Azure muss jede Anwendung und jedes System genau einer Ressourcengruppe zugeordnet werden. Unternehmen gruppieren die Systeme meist über den traditionellen IT-Ansatz: Alle Komponenten, die den gemeinsamen Lebenszyklus einer Applikation begleiten, werden zusammengefasst. Mehrschichtige Applikationen und agile Programmierung führen andererseits oft zu unterschiedlichen Lebenszyklen. Beim agilen IT-Fokus wird daher nach Web-, Applikations-, Datenbank- und Deployment-Schicht getrennt, die jeweils als eigene Ressourcengruppe angelegt werden.

Für Ressourcen und Ressourcengruppen empfiehlt es sich zudem, sogenannte Tags zu vergeben. Sie bestehen aus einem klassischen Schlüssel-Wert-Paar. Nutzer finden Storage-Accounts, Netzwerke, virtuelle Maschinen und anderes damit schnell wieder. Tags lassen sich in Templates hinterlegen und abfragen. Microsoft rät zu mindestens drei Tags je Ressourcengruppe: Besitzer, Abteilung und Umgebung. Bei einer einzelnen Anwendung lässt sich etwa der Administrator, der für die Datenbank verantwortlich ist, taggen. Über Tags lassen sich auch die durch die Systeme entstehenden Kosten den Verursachern zuordnen.

Die Resource-Manager-Richtlinien in Azure legen auf Subscription- oder Ressourcengruppen-Ebene fest, welche Systeme dort erlaubt sind, beispielsweise nur virtuelle Maschinen der Größen A und F. Damit bestimmen Cloud-Anwender, in welchen Regionen welche Maschinenklassen oder Storage-Typen möglich sind.

Mit Resource Locks im Azure Resource Manager schützen Unternehmen ihre Cloud-Leistungen. Sie legen darin fest, wer das System, das Netzwerk oder den gebuchten Dienst löschen darf. Wenn der Verantwortliche den Wert einer Ressource auf „cannot delete“ stellt, dann ist niemand außer dem Ersteller berechtigt, die Ressource zu löschen. Um einen solchen Resource Lock aufzuheben, ist ebenfalls eine Befugnis nötig. Diese liegt standardmäßig beim Besitzer des IT-Ser­vices. Über die Rolle des User-Access-Administrators könnte zum Beispiel auch die IT-Leitung Systeme freigeben und sperren.

Ressourcen kann man auch auf „read only“ setzen. Dadurch lassen sich keine Änderungen mehr daran vornehmen. Gleichzeitig akzeptiert die Webschnittstelle dann für dieses System nur Get-Anfragen. Dabei ist jedoch zu beachten, dass einige Aktivitäten bei der Verwaltung von Cloud-Services voraussetzen, dass die Ressource auch andere Abfragen als nur Get-Abfragen akzeptiert.

Durch Automatisierung lässt sich die Cloud-Governance auditieren. Die PowerShell-Funktion kann zum Beispiel alle Namen ausgeben, die man gegen die zuvor festgelegte Namenskonvention laufen lässt.

Eine Firma kann auch in einem Template vorgeben, welche Namensmuster für die Ressourcen gelten. Über Templates lässt sich zudem definieren, wie eine virtuelle Maschine zu erzeugen ist und welche IT-Services in welchen Regionen angelegt werden dürfen.

Noch stärker automatisieren Unternehmen die Cloud-Nutzung, wenn sie die Administration ihrer Cloud-Leistungen in das IT-Service-Management integrieren. Eine Ressource oder eine sie betreffende Änderung beantragen Nutzer dann über ein Service-Management-Tool wie Service Now oder Microsoft Service Manager. Das Tool verarbeitet dann die jeweiligen Anfragen der Nutzer mit richtlinienkonformen Skripts oder Templates.

Diese Vorarbeit für eine Cloud-Struktur ist aufwendig. Will man Chaos in der virtuellen Welt verhindern, ist sie aber unabdingbar. Ein Governance-Konzept selbst zu erstellen, überfordert jedoch schnell die firmeneigene IT-Abteilung. Externe Dienstleister bieten dafür Workshops, helfen, ein Regelwerk festzuschreiben, und unterstützen bei der Einführung von Templates und Automatisierungsskripts.