Governance in der Azure Cloud

Einleitung: Was genau ist Cloud Governance und was gilt es zu beachten?

Die Cloud hat im Zusammenhang mit den vom Plattformanbieter (in unserem Fall Microsoft) bereitgestellten Technologien viele Definitionen und Typen gleichzeitig. Das geht los bei der einfachsten Verwendung der Cloud – zum Beispiel der gemeinsamen Nutzung von Ressourcen bis hin zu einer vollautomatischen Umgebung mit einer hohen Standardisierung.

Aber was bedeutet das in der Praxis aus Sicht von Unternehmen und inwiefern kann das relevant für Ihre Organisation sein? Insbesondere dann, wenn Sie in Ihrem Unternehmen viele Auflagen im Hinblick etwa auf Regulatorik und interne Regeln haben?

Die Antwort ist recht einfach: Es gibt gerade in der Cloud viele Technologien, die es Ihrer Organisation ermöglichen, Ihre IT-Ziele und Unternehmensvisionen sicher zu erreichen und zugleich regulatorische Auflagen zu erfüllen.

Zur Erläuterung: Governance-Normen entsprechen üblicherweise den IT-Standards Ihrer Organisation und sollen unter anderem sicherstellen, gesetzliche Auflagen Ihres Unternehmens zu erfüllen. Der Schwerpunkt dieses Artikels liegt auf der Cloud Governance, im besonderen Microsoft Azure als dem Cloud-Plattform-Anbieter Ihrer Wahl.

In diesem Artikel stelle ich Ihnen die Komponenten von Microsoft Azure zur Einhaltung Ihrer Governance vor und erkläre, warum ist es auch für Ihre Organisation von Bedeutung sein.

Eine Sache ist noch wichtig, bevor es richtig losgehen kann: Zwischen der Governance der Cloud-Anbieters (Microsoft) und Ihnen als Kunde der Plattform ist zu differenzieren. In den kommenden Absätzen erläutere ich die Unterschiede genauer.

Cloud Provider Governance (was Microsoft verantwortet)

Cloud-Anbieter wie Microsoft müssen sich an strenge Kontrollen und Prozesse halten, die oftmals sogar viele Industriestandards übertreffen (zu erwähnen sind hierbei zahlreiche Zertifizierungen von Microsoft mit seiner Azure Plattform). Zugleich bekommen die Kunden etwa von Microsoft Azure auch viele Governance-Implementierungen automatisch vererbt – ein großer Vorteil für Sie. Beispielhaft sei hier erwähnt, dass Microsoft es Ihnen als Cloud-Kunde ermöglicht, selbst den Standort des Rechenzentrums für Ihre IT-Infrastruktur auszuwählen. Das hat für Sie den Vorteil, dass Sie sich damit an Datenschutzregelungen sowie die Gesetze der Länder halten können, die für Ihr Unternehmen wichtig oder gar zwingend sind. Möchten Sie etwa sicherstellen, dass Sie sich an die europäische DSGVO halten, können Sie bspw. Amsterdam (bzw. West Europe) als den Standort Ihres Azure Rechenzentrums wählen. Microsoft bietet Ihnen hier eine große Auswahl von Rechenzentren auf der ganzen Welt.

Das Microsoft Trust Center erläutert die wichtigen Bereiche, welche für Ihre Organisation aus Sicht von Microsoft wichtig sind und welche welche Konzepte Microsoft in Microsoft Azure auf Ihr Unternehmen vererben wird. Dies sind konkret:

Cloud Governance für Kunden (was Kunden selbst verantworten)

Cloud-Kunden erben zwar die implementierten Governance-Lösungen der Anbieter, müssen jedoch Ihre spezifischen Regulatorien etwa auf Basis der für sie geltenden Gesetze ebenfalls implementieren. Im Grunde lässt sich das mit dem Einzug in eine Wohngemeinschaft (WG) vergleichen. Natürlich existiert meistens schon ein gewisser Rahmen in einer Wohngemeinschaft und man teilt sich auch viele Aufgaben gerecht auf – andererseits ändert das nichts an der Tatsache, dass auch Sie sich ganz grundsätzlich an Regeln und Gesetze halten müssen. Im Umfeld von Microsoft Azure bedeutet haben Sie selbst also noch folgende Governance-Aufgaben selbst zu verantworten:

Unterteilung Ihrer Fachbereiche (Kostenstellen, Niederlassungen oder sonstige Strukturen Ihrer Organisation)
Auflagen bei der eigenen Architektur (bspw. von Ihren IT- oder Softwarearchitekten)
Technologische Regeln (bspw. Standardisierungen, Einsatz von Programmiersprachen)
Konzept und Überwachung über Rechte- und Rollen (im englischen auch als RBAC abgekürzt - siehe unten)
Business Continuity (Notfallpläne, Disaster-Revovery, Wiederherstellung eines IT-Betriebes)
Teile der Security (bspw. Antivirus auf Ihren Clients in der Cloud)
Monitoring und IT Auditing (etwa der Einsatz von SIEM-Lösungen für die Auswertung der Logdaten)

Azure Governance Begiffsdefinitionen

Folgenden Bausteine des „Azure Governance Frameworks“ sind für Sie entscheidend. Weiterhin wichtig sind die Beziehungen und Abhängigkeiten, die Sie bei der Implementierung einplanen müssen. Die wesentlichen Bausteine Ihrer Microsoft Azure Governance sind:

Tenants
Subscriptions
Resource groups
Resources
Management groups
Management groups
Initiatives
Blueprints
Role-based access control (RBAC)

Im folgenden sind diese Bausteine beschrieben und erläutert.

Tenants

Ein Tenant ist die höchste Ebene Ihrer Microsoft Azure-Umgebung. Wenn Sie sich zum ersten Mal für einen Azure-Dienst anmelden, wird ein Tenant für Sie erstellt. Jeder Tenant in Azure ist einzigartig und repräsentiert Ihre Organisation (das kann auch eine Einzelperson sein oder Ihr gesamtes Unternehmen). Ihre Organisation kann also durchaus als „Tenant“ bezeichnet werden. Viele Unternehmen haben auch mehr als nur einen Tenant in Microsoft Azure. Jeder Tenant ist zunächst einmal komplett eigenständig. Das grundlegende Element eines Tenant ist das sogenannte „Azure Active Directory“ (kurz Azure AD). Ein Tenant kann zugleich viele Active Directories vorhalten, man spricht oftmals auch von einem kompletten Active Directory „Forest“.

Subscriptions

Die Erstellung und Nutzung eines Azure Tenant ist kostenlos und wird mit einigen grundlegenden Funktionen bereitgestellt, die allen registrierten Azure-Kunden zur Verfügung stehen. Die Möglichkeit, Services zu nutzen, wird durch die Verwendung von sogenannten Subscriptions (deutsch: Abonnements) ermöglicht. Eine Subscription ist erforderlich, wenn Sie die drei wesentlichen Kategorien von Cloud-Services nutzen möchten:

Infrastructure as a Service (IaaS): Das Erstellen und Ausführen virtueller Maschinen, einschließlich traditioneller Infrastrukturkomponenten wie Domänensteuerung oder Datenbankserver, ist ein Beispiel für IaaS.
Platform as a Service (PaaS): Database as a Service ist ein Beispiel für PaaS (u.a. Azure SQL, Cosmos DB).
Software as a Service (SaaS): Office 365 ist ein Beispiel für SaaS in Azure.

Im Wesentlichen benötigen Sie eine Subscription in Azure, um SaaS-, PaaS- und IaaS-Funktionen in Azure zu aktivieren und zu nutzen. Ein Unternehmen kann eine oder mehrere Subscriptions haben, die an einen einzigen Tenant gebunden sind.

Management groups

Management groups werden verwendet, um beispielsweise viele Subscriptions, die mit einem Azure AD bzw. Azure Tenant verbunden sind, zu gruppieren. Management groups in Azure ermöglichen es etwa Ihrer Organisation, eine logische Hierarchie für Subscriptions zu erstellen. Jeder Tenant bzw. jedes Azure AD hat eine Root-Management Group. Die Root-Management-Gruppe ist die oberste Ebene und kann nicht gelöscht werden, kann aber den Anzeigenamen ändern lassen, etwa um die Organisation widerzuspiegeln (z.B. lässt sich der Name des Management Group in den Name Ihres Unternehmens ändern). Mit Hilfe von Management Groups gruppieren Sie Ihre Subscriptions und ihre jeweiligen Ressourcen. Sobald sie erstellt und organisiert sind, werden Management Groups verwendet, um Ihre Governance Policies- und Initiativen zu implementieren. Die auf der Ebene der Managementgruppe angewandten Richtlinien werden auf die dieser Managementgruppe und ihren Untergruppen, Ressourcengruppen und Ressourcen zugeordneten Subscriptions vererbt. Sie erstellen Managementgruppen, um die Struktur Ihrer Organisation zu repräsentieren. Die Struktur kann auf „Life cycle“-Umgebungen (Entwicklungsumgebungen, Testumgebungen, Produktivumgebungen), Fachbereiche oder eine andere logische Darstellung ausgerichtet werden.

Resources

Der Begriff Ressource steht für die in Azure verwalteten Entitäten oder Objekte. Dazu gehören unter anderem virtuelle Maschinen, Storage-Accounts, virtuelle Netzwerke, Subnetze oder alle anderen buchbaren Ressourcen in Microsoft Azure.

Resource groups

Resource groups sind eine logische Möglichkeit, eine oder mehrere Azure-Ressourcen zu gruppieren. Gruppierte Ressourcen in einer Resource group können als eine einzige Einheit verwaltet werden, und sie alle erben Eigenschaften und Zugriffe wie z.B. rollenbasierte Zugriffskontrollen (in englisch auch als RBAC abgekürzt – siehe unten), Ressourcen-Tagging und „Life cycle“-Attribute.

Azure Policies

Azure Policy ist ein Service, den Sie nutzen, um Richtlinien und Normen Ihrer Organisation für die in Microsoft Azure verwendeten Ressourcen zu überprüfen Regeln anzuwenden und durchzusetzen.

Sie können z.B. sicherstellen, dass alle Ressourcen mit einer Kostenstelle versehen werden oder dass Ressourcen für die europäische Niederlassung nur an europäischen Azure-Standorten angelegt werden, etwa um die Einhaltung der Datenschutzbestimmungen zu gewährleisten. Azure hat eine Reihe von vorgefertigten Richtlinien, die jedes Unternehmen mit seinem Tenant nutzen kann. Diese eingebauten Richtlinien decken Regeln ab, die für die meisten Unternehmen typisch sind. Sie können diese eingebauten Policies über das Azure-Portal oder programmgesteuert anzeigen und zuordnen.

Richtlinien werden auf mehreren Ebenen, den so genannten Scopes, zugewiesen. Ein Geltungsbereich kann eine Management group, ein Subscription oder eine Resource group sein.

Initiativen

Initiativen sind eine Gruppe von einer oder mehreren Policies, die zur Prüfung und/oder Durchsetzung der Governance-Regeln einer Organisation verwendet werden. Ähnlich wie Policies bietet Azure vorgefertigte Initiativen. Typischerweise stellen vorgefertigte Policies und Initiativen eine Vorlage zur Verfügung, die Sie duplizieren und an Ihre spezifischen Bedürfnisse anpassen können, oder Sie können bei Bedarf die Standardeinstellungen übernehmen.

Role-Based Access Control (auch als RBAC abgekürzt - rollenbasierte Zugriffskontrolle)

Die rollenbasierte Zugangskontrolle (RBAC) ist eine Komponente des Governance-Frameworks für Organisationen. Durch Policies und Initiativen wird definiert und durchgesetzt, wie Ressourcen bereitgestellt werden sollten, etwa um Compliance-Regeln Ihrer Organisation einzuhalten. RBAC stellt sicher, dass nur autorisierte und zugelassene Benutzer einen Zugriff auf Ressourcen erhalten. In Microsoft Azure verfügt RBAC über vordefinierte Rollen, mit denen Sie den Zugriff auf der Ebene von Subscriptions, Resource Groups oder Ressourcen gewähren können. Sie haben die Möglichkeit, benutzerdefinierte Rollen zu erstellen, um die Standardberechtigungen der Rollen zu erweitern und an spezifische Anforderungen oder Ihre Organisation anzupassen.

Blueprints

Die Einführung der Azure Cloud verläuft für die meisten Kunden nach folgendem Muster:

Case Study
Proof of Concept (PoC)
Eingeschränkte Nutzung des PoC
Vollständige Cloud-Migration

Zunächst einmal führen Organisationen bei der Evaluation von Cloud-Anbietern wie Microsoft Azure oft zunächst einmal eine Case Study für Projekte durch, im nächsten Schritt in Form eines Proof of Concept (PoC) dann oft eine Machbarkeitsstudie und nutzen die Ergebnisse aus dem PoC in einem eingeschränkten und definierten Rahmen – etwa indem kleine und definierte Anwender die Ergebnisse testen. Danach werden wird sich dann Schritt für Schritt hin zu einer vollwertigen Cloud-Migration hingearbeitet. Dieser Ansatz hat jedoch eine wichtige Kehrseite: Die frühen Aktivitäten im PoC orientierten sich nicht immer an den Regeln der Organisation bzw. Richtlinien des Unternehmens. Infolgedessen gibt es eine Reihe von Brownfield-Ansätzen, die im Betrieb nicht der vollen Governance oder den empfohlenen Praktiken und Zielen entsprechen. Azure Policy und Initiativen bieten eine Möglichkeit, Verstöße nachträglich zu prüfen und im Laufe der Zeit zu korrigieren und somit Abweichungen zur Compliance im Nachgang über die Empfehlungen zu korrigieren. Azure Blueprints wurden eingeführt um Sie dabei zu unterstützen, gleich zu Beginn eines Cloud-Projektes einen Rahmen aus Templates zu erstellen, welche alle Governance-Artefakte (und vieles mehr) enthalten. Sie erstellen und konfigurieren also einen Blueprint, der die Policy-Zuweisungen, Rollenzuweisungen, Resource Groups und Azure Resource Manager (ARM)-Vorlagen enthalten soll. Sobald ein Blueprint erstellt und veröffentlicht ist, erbt der Deployment-Engineer oder Entwickler das Governance-Framework durch eine Zuweisung an die Subscriptions. Im Wesentlichen ermöglichen Blueprints es Ihnen somit, Deployments ganz früh richtig und regelkonform zu erstellen.

Planung der Azure Governance

„Measure Twice, cut once“ (zweimal messen, einmal schneiden) ist eine gebräuchliche anglikanische Redewendung aus der Tischlereibranche. Die Prämisse ist, dass man z.B. bei der Herstellung eines guten Tisches vor dem Zuschnitt des Holzes unbedingt die richtigen Maße bestimmen sollte. Ist das Holz erst einmal zu kurz geschnitten, müssen Tischler zwei oder mehr Teile aufwändig wieder zusammenfügen und bringen damit eine „Schwäche“ in die Beschaffenheit des Tisches. Dies ist bei der Umsetzung von Azure Governance ebenfalls sehr gut vergleichbar. In den folgenden Absätzen beschreibe ich die empfohlenen Planungsaktivitäten, die Sie als Voraussetzung für die Konfiguration und Zuweisung Ihres Governance-Frameworks berücksichtigen sollten. Die Aktivitäten gliedern sich in

Azure Basis-Framework

Der Implementierungsprozess einer Azure Governance erfordert, dass der verantwortliche Security-Engineer Ihres Unternehmens für die Azure-Cloud mit den folgenden Aspekten vertraut ist und diese hinreichend planen kann:

Planung für Tenants

Die Planung und Festlegung eine oder vieler Tenants für Ihre Cloud-Umgebung ist der entscheidende erste Schritt. Der Tenant ist von zentraler Bedeutung, da er nicht nur die Grundlage des gesamten Governance-Frameworks darstellt, sondern auch die Basis für die weitere, gesamte Sicherheit der Azure-Umgebung ist.

Keine Schatten-IT erzeugen

Stellen Sie sicher, dass die Registrierung der Tenants mit der Organisation verknüpft ist und von dieser auch verwaltet wird. Es ist nicht unüblich, dass die Azure-Registrierung mit der Kreditkarte bspw. eines Vertriebsleiters oder der von Microsoft bereitgestellten Standard-Domäne verknüpft ist und auch so belassen wird – und somit eine Art Schatten-IT entsteht.

Rechte und Rollen

Weisen Sie geeignete Rechte und administrative Rollen im Tenant zu. Die Tenant-Rollen und Rechte wirken sich auf Subscriptions und die untergeordneten Resource Groups aus.

Planung einer Isolation

In Fällen, in denen eine vollständige Isolierung von Umgebungen erforderlich ist empfiehlt es sich, einen separaten Tenant einzurichten. Beachten Sie jedoch, dass nur ein Tenant mit Ihrem On-Premise Active Directory Forest verbunden werden kann. Wenn Sie planen, das Azure AD mit einem On-Premise AD zu verbinden sollte also klar sein, mit welchem Tenant die Konnektivität hergestellt werden soll.

DNS-Eintrag für den Tenant

Bestimmen Sie, welchen externen DNS-Name (Domain Name Service) Sie dem Tenant zuweisen wollen. Weisen Sie dem Tenant einen geeigneten DNS-Name zu noch bevor Sie die ersten Benutzer erstellen.

Premium-Funktionen für Azure Governance

Ein Tenant ist zwar kostenfrei in der Erstellung und auch der Verwendung, bestimmte Premium-Dienste, insbesondere viele Azure Governance-Funktionen sind jedoch kostenpflichtig (etwa Azure Active Directory Premium). Besprechen Sie die in Azure verfügbaren Dienste mit allen relevanten Interessengruppen Ihres Unternehmens und planen Sie ein angemessenes Budget für die Bereitstellung dieser Dienste ein.

Planung für Subscriptions

Die Planung von Subscriptions ist der nächste Schritt nach der Festlegung des/der Tenants Ihrer Organisation. Möglicherweise entscheiden Sie sich für einen einzigen Tenant – in einigen Fällen ist auch ein separater Tenant notwendig etwa zur Trennung von Life-Cycle-Umgebungen (Testumgebung, Produktivumgebung). Subscriptions sind die von Ihnen mit Microsoft abgeschlossenen Verträge über die Bezahlung des Verbrauchs von Cloud Services. Es gibt zwei Kategorien von Subscriptions, die mit den drei Kernkategorien von Cloud-Diensten übereinstimmen. Das sind

Microsoft Software as a Service (SaaS)-Subscriptions

Diese Subscriptions sind mit den Cloud-Angeboten wie Office 365, Intune/EMS oder auch Dynamics 365 verknüpft. Diese Art von Subscriptions ist in das SaaS-Angebot integriert. Die Hauptplanungsaktivität besteht darin eine Verbindung zu dem für Ihre Organisation maßgeblichen Tenant herstellen. Der maßgebliche Tenant fungiert als Ihre Identitäts- und Security-Ebene.

Microsoft Platform as a Service (PaaS) und Microsoft Infrastructure as a Service (IaaS)-Subscriptions.

Im Gegensatz zu SaaS-Diensten, die auf bestimmten Benutzerkonten (welche das Angebot nutzen) basieren, sind PaaS- und IaaS-Kosten meistens an den Verbrauch von Ressourcen gebunden. Mit PaaS oder IaaS erstellen und verwalten Sie im Rahmen der Subscription alle für Ihre Organisation erforderlichen Artefakte.

Planung von Aktivitäten bei SaaS-Umgebungen

Lizenzverwaltung

Die für den Lizenzeinkauf zuständige(n) Abteilung(en); in der Regel die Einkaufsabteilung. Diese Abteilung muss die rechtlichen Aspekte der Vereinbarung verstehen. Das ist wichtig, damit Ihre Organisation die Bestimmungen und Regelungen gemäßt dem Vertrag einhält.

Identitätsverwaltung (bspw. Active Directory)

SaaS-Angebote erfordern einen Link zu einem Tenant, um eine vertrauenswürdige Identitätsquelle bereitzustellen. Wenn Sie sich für Microsoft Azure SaaS-Dienste registrieren, wird Ihnen ein allgemeiner Azure AD-Tenant angeboten; wenn Sie einen bestehenden Tenant haben können Sie auch eine Verbindung zu diesem bestehenden Tenant aufbauen. Wenn Sie lokal bereits ein Active Directory haben, können Sie optional auch eine Synchronisierung einrichten. Durch die Synchronisierung Ihrer On-Premise-Identitäten mit dem Azure Active Directory wird sichergestellt, dass Sie nur eine Identität verwalten und Ihren Anwendern ein Single Sign-On-Erlebnis bieten.

Planung von Aktivitäten bei PaaS und IaaS-Umgebungen

Lizenzverwaltung

Richtlinien und Sicherheit

Anders als bei SaaS-Angeboten sind Sie für die vollständigen Richtlinien und das Sicherheits-Framework verantwortlich, die Sie für die Subscription festlegen. SaaS-Lösungen von Cloud-Providern haben vererbte Policies und Security Frameworks, die vom Provider verwaltet werden. PaaS- und IaaS-Angebote bieten Ihnen volle Flexibilität bei der Erstellung, Implementierung und Verwaltung der Richtlinien und des Sicherheits-Frameworks für die vom Endbenutzer konsumierten Anwendungen und Dienste, die Sie in diesen Subscriptions erstellen.

Cloud-Strategie nicht vergessen - Vorteile der Cloud Services nutzen (CI/CD)

Planen Sie die Einführung von Diensten und die kontinuierliche Bereitstellung von Funktionen. Ein Beispiel: Bei IaaS ändern sich die SKUs virtueller Maschinen, während neue SKUs eingeführt und alte SKUs vom Markt genommen werden. Sie müssen ein Team haben, das für die Überprüfung dieser Änderungen verantwortlich ist. Einer der Grundwerte von Cloud Services ist der Faktor Elastizität; wenn die Elastizität nicht eingeplant wird, verringert sich der Nutzen, den Sie aus Ihrer Cloud-Strategie ziehen.

Planung für Resource Groups

Die Ebenen unterhalb von Subscriptions sind Resource Groups und Ressourcen. Die Planung und Lokalisierung von Ressourcengruppen ist erforderlich, um sicherzustellen, dass die von Ihnen erstellten Ressourcen am richtigen geografischen Ort platziert und so organisiert sind, dass die von Ihnen erstellten Policies für die Standardisierung leicht anzuwenden sind.

Planung für Management Groups

Der Bereich „Management Groups“ dieses Artikels stellte bereits vor, was Management-Gruppen sind und wie Sie diese typischerweise in einer Azure-Umgebung einsetzen. Management Groups in Azure bieten zwei zentrale Organisations- und Management-Optionen: An welchem Ort Sie Ihre Governance-Bestandteile speichern und wie Sie diese Bestandteile dann anwenden.

Planung des Scope

Wenn Sie Ihre Azure-Artefakte, wie z.B. Policies, Initiativen und Blueprints erstellen, werden Sie aufgefordert, einen sog. „Scope“ auszuwählen. Diese Auswahl hat einen erheblichen Einfluss auf die Ihnen zur Verfügung stehenden Optionen in Zukunft. Die Zuweisung kann nur bis zur Storage-Ebene und darunter eingeordnet werden. Auf der höchsten Ebene übernehmen Sie jedoch stets die volle Kontrolle über das Sicherheits-Framework (über die untergeordnete Management Groups der Root Management Group).

Zuweisung von Governance-Richtlinien

Die zweite Kategorie ist die Art der Zuweisung der Richtlinien, Initiativen und Blueprints. Die Zuweisungen werden im Managementbaum nach unten vererbt. Es wird empfohlen, relevante Security-Artefakte auf der höchsten Ebene (also der Root-Management-Group) zuzuweisen. Die größte Flexibilität und geringste Komplexität erhalten Sie, wenn Sie die Management Groups in einer logischen Struktur anordnen (siehe oben). Ein wichtiger Bereich, den Sie ebenfalls einplanen sollten, ist die Verwendung von sogenannten Exclusions. Exclusions (Ausnahmen) sind sehr mächtig, können aber auch zu Konflikten und unerwünschten Auswirkungen führen, wenn sie nicht entsprechend geplant werden. Planen Sie idealerweise eine Strukturierung der Management Groups so ein, damit Sie die Notwendigkeit von Exclusions reduzieren.

Planung des Azure Governance-Frameworks

Die wichtigsten Azure Governance-Artefakte, die eingeplant werden müssen, sind zusammengefasst

Die bei der Planung ebenfalls zu berücksichtigenden gemeinsamen Bereiche sind Namenskonventionen, Tests und das Life-cycle Management.

Namenskonventionen

Planen Sie eine Namenskonvention für alle relevanten Artefakte in in Microsoft Azure. Diese sollte dokumentiert und kommuniziert werden. Es sollte sichergestellt sein, dass alle Ressourcen hier den gleichen Standards folgen.

Durchführung von Tests

Eine Durchsetzung der Azure Governance, welche nicht angemessen getestet wird, kann erhebliche negative Auswirkungen haben und zu Ausfallzeiten und gar Imageschäden führen. Ein Beispiel ist die Verwendung von sogenannten „Deny Policies“ ohne entsprechende Tests. Es lässt sich bspw. eine Policy implementieren um die Erstellung einer bestimmten Ressource zu verweigern, aber wenn dieser Ressourcentyp Teil eines Self-Service-Angebots ist, dann müssen Sie sicherstellen, dass die für den Self-Service verfügbaren Optionen ebenfalls der Deny-Policy unterliegen.

Governance ist ein laufender Prozess

Wie heißt es so schön? Die einzige Konstante im Leben ist die Veränderung. Auch das Governance-Framework muss ebenfalls regelmäßig angepasst und verändert werden. Verändert sich etwa eine Compliance-Regel oder Ziele der Organisation, sind oftmals auch Governance-Regeln anzupassen. Möglicherweise müssen Sie eine Form der Versionierung für die Azure Governance einplanen um Veränderungen auch laufend durchführen zu können ohne den Überblick zu verlieren.

Governance in der Azure Cloud – alles was Sie darüber wissen sollten