Latest / M365.FM – Microsoft 365, Copilot & KI Podcast auf Deutsch / Azure Policy vs. RBAC: Wer darf was – und welche Konfigurationen sind erlaubt? Leitplanken für Azure einfach erklärt (KI-Synchronfassung)

Transcript

Azure Policy vs. RBAC: Wer darf was – und welche Konfigurationen sind erlaubt? Leitplanken für Azure einfach erklärt (KI-Synchronfassung) · M365.FM – Microsoft 365, Copilot & KI Podcast auf Deutsch

• 0:03
  Heute sprechen wir über ein Azure Feature, von dem Sie sicher schon gehört haben, das Sie aber vielleicht noch nicht ganz verstehen.
• 0:07
  Azure Policy ist eines der mächtigsten Governance-Tools der gesamten Plattform.
• 0:11
  Doch die meisten ignorieren es oder halten es nur für IT-Administratoren für relevant.
• 0:15
  Am Ende dieser Folge werden Sie wissen, was Azure Policy eigentlich ist, wie es wie ein unsichtbares Regelwerk funktioniert
• 0:21
  und warum es für eine sichere Azure-Umgebung unverzichtbar ist.
• 0:25
  Wir unterteilen es in klare Bausteine, angefangen bei dem Problem, das es löst.
• 0:28
  Schnappen Sie sich Ihren Kaffee und legen wir los.
• 0:30
  Das Problem, warum die Cloud Light Planken braucht.
• 0:33
  Denken Sie an die alte Vorgehensweise.
• 0:36
  On-Premises mussten Sie eine Anfrage an das Betriebsteam stellen, wenn Sie einen Server benötigten.
• 0:40
  Die prüften die Regeln, Unternehmensrichtlinien, Sicherheitsstandards und vielleicht regulatorische Vorgaben
• 0:45
  und stellten dann den Server für Sie bereit.
• 0:47
  Ein menschlicher Wächter stand zwischen Ihnen und der Infrastruktur.
• 0:50
  Diese Person kannte die Regeln und stellte sicher, dass nichts durchs Wasser fiel.
• 0:53
  Die Cloud stellt das komplett auf den Kopf.
• 0:54
  Jetzt hat der App-Besitzer direkten Zugriff, ohne dass ein Mensch dazwischen steht.
• 0:57
  Klicken Sie im Azure-Portal auf Erstellen und es passiert sofort.
• 1:01
  Sie können auch die Befehlszeile einer API oder Infrastructure-as-Code-Tools wie Terraform nutzen.
• 1:06
  Der Punkt ist, niemand prüft Ihre Arbeit, bevor die Ressource erstellt wird.
• 1:09
  Und genau da beginnt das Problem.
• 1:10
  Die meisten App-Besitzer kennen nicht alle Regeln.
• 1:12
  Vielleicht ist Ihnen nicht klar, dass die Unternehmensrichtlinie vorschreibt, dass alle Daten in Europa bleiben müssen.
• 1:16
  Oder dass Storage-Accounts den öffentlichen Zugriff blockieren müssen.
• 1:18
  Oder dass bestimmte VM-Größen teuer sind und nur in der Produktion verwendet werden sollten.
• 1:22
  Sie erstellen also Ressourcen und manchmal passieren Fehler.
• 1:24
  Eine virtuelle Maschine wird mit einer öffentlichen IP und offenen Ports zum Internet bereitgestellt.
• 1:29
  Ein Storage-Account wird mit öffentlichem Block-Zugriff erstellt, wodurch sensible Daten exponiert werden.
• 1:33
  Jemand startet eine teure GPU-Instanz für einen kurzen Test und vergisst sie zu löschen.
• 1:37
  So etwas passiert ständig.
• 1:39
  Was wir brauchen ist ein automatisches Durchsetzungssystem, das jedes Mal funktioniert, egal wer die Ressource erstellt oder wie er es tut.
• 1:45
  Egal ob über das Portal, das CLI, eine API-Aufruf oder eine Terraform-Bereitstellung.
• 1:48
  Die Regeln sollten automatisch geprüft werden.
• 1:51
  Und genau das bietet Azure Policy.
• 1:54
  Was ist Azure Policy, das unsichtbare Regelwerk?
• 1:56
  Was also ist Azure Policy?
• 1:58
  Ist die einfachste Definition.
• 1:59
  Azure Policy ist ein Dienst, mit dem Sie Regeln für Ihre Azure-Ressourcen festlegen und diese automatisch durchsetzen können.
• 2:04
  Stellen Sie es sich wie das Regelbuch für ein Brettspiel vor.
• 2:06
  Das Spiel bietet viele mögliche Spielzüge, aber das Regelbuch legt fest, welche davon tatsächlich erlaubt sind.
• 2:10
  Sie können Ihre Spielfigur nicht einfach beliebig bewegen.
• 2:12
  Die Regeln sagen dir, was erlaubt ist und was nicht.
• 2:15
  Hier ist nun ein entscheidender Unterschied.
• 2:16
  Azure Policy ist nicht dasselbe wie eine rollenbasierte Zugriffskontrolle oder RBC.
• 2:19
  RBC steuert, wer etwas tun darf.
• 2:21
  Es beantwortet die Frage, wer darf Ressourcen in diesem Abonnement erstellen.
• 2:25
  Azure Policy steuert, was getan werden kann.
• 2:27
  Oder genauer gesagt, welche Konfigurationen zulässig sind.
• 2:29
  Es beantwortet die Frage, welche Art von Ressourcen dürfen erstellt werden und wie müssen sie konfiguriert sein.
• 2:34
  Also RBC sagt, Mirko darf Speicherkonten erstellen.
• 2:36
  Und Azure Policy sagt, Speicherkonten müssen HTTPS aktiviert haben.
• 2:40
  Zwei verschiedene Dinge und du brauchst beides.
• 2:41
  Hier ist der entscheidende Punkt.
• 2:43
  Azure Policy ist immer aktiv und wird immer durchgesetzt.
• 2:45
  Jede einzelne Anfrage zum Erstellen, Aktualisieren oder Löschen eine Ressource durchläuft Azure Policy und es gibt keinen Weg, dies zu umgehen.
• 2:51
  Es steht zwischen dir und dem Azure Resource Manager, der Steuerungsebene von Azure.
• 2:55
  Stell sie wie einen automatischen Filter vor.
• 2:57
  Jede Anfrage geht durch diesen Filter, entspricht sie nicht den Regeln, wird die Anfrage blockiert oder markiert.
• 3:01
  Und das gilt nicht nur für neue Ressourcen.
• 3:03
  Azure Policy bewertet auch vorhandene Ressourcen und erkennt so Konfigurationsabweichungen im Laufe der Zeit.
• 3:08
  Wenn jemand eine Einstellung an einer bereits bereitgestellten Ressource ändert und diese Änderung gegen eine Richtlinie verstößt, markiert Azure Policy dies.
• 3:15
  Wie schreibt man also eigentlich diese Regeln?
• 3:17
  Hier kommen Richtliniendefinitionen ins Spiel.
• 3:20
  Richtliniendefinitionen, das Schreiben der Regeln.
• 3:22
  Wie schreibt man also eigentlich diese Regeln?
• 3:23
  Hier kommen Richtliniendefinitionen ins Spiel.
• 3:25
  Eine Richtliniendefinition ist die Regel selbst und sie ist als JSON-Dokument geschrieben.
• 3:29
  JSON mag technisch klingen, aber die Struktur ist eigentlich ziemlich einfach.
• 3:32
  Sie folgt einem Grundlängenmuster.
• 3:33
  Wenn diese Bedingung wahr ist, dann wende diesen Effekt.
• 3:36
  Ich gebe dir ein praktisches Beispiel.
• 3:38
  Es gibt eine integrierte Richtlinie, die besagt, wenn dein Speicherkonto kein HTTPS aktiviert hat, verweigere es.
• 3:43
  Das ist alles.
• 3:43
  Wenn die Bedingung wahr ist, greift der Effekt und blockiert die Bereitstellung.
• 3:47
  Jede Richtliniendefinition hat drei wichtige Teile.
• 3:49
  Erstens die Bedingungen.
• 3:50
  Das ist der Wenn-Teil.
• 3:51
  Worauf prüfst du?
• 3:52
  Auf den Ressourcentyp, den Standort, eine bestimmte Einstellung?
• 3:55
  Zweitens die Effekte.
• 3:56
  Das ist der Dann-Teil.
• 3:57
  Was passiert, wenn die Bedingung erfüllt ist?
• 3:59
  Blockierst du die Bereitstellung oder markierst du sie nur?
• 4:01
  Drittens Parameter.
• 4:02
  Das sind die Lückenfüller, die die Richtlinie wiederverwendbar machen.
• 4:05
  Parameter sind der Punkt, an dem die wahre Stärke liegt.
• 4:08
  Stell dir vor, du möchtest eine Richtlinie schreiben, die nur Ressourcen in bestimmten Regionen zulässt.
• 4:12
  Du möchtest nicht für jede mögliche Kombination von Regionen eine eigene Richtlinie schreiben.
• 4:16
  Stattdessen schreibst du eine Definition namens zulässige Standorte.
• 4:19
  Und sie fügen ein Parameter für die zulässigen Regionen.
• 4:21
  Wenn sie die Richtlinie zuweisen, füllen sie die Lücke.
• 4:23
  Vielleicht wählen sie für eine Subscription West Europe und North Europe und für eine andere East US und West US.
• 4:28
  Gleiche Definition, andere Parameter.
• 4:30
  So halten sie alles überschaubar.
• 4:31
  Ist die gute Nachricht.
• 4:32
  Sie müssen nicht alles von Grund auf neu schreiben.
• 4:34
  Microsoft stellt hunderte von integrierten Richtliniendefinitionen bereit, die sie sofort nutzen können.
• 4:39
  Sie decken Kategorien wie Compute, Storage, Netzwerk, Security Center, Tagging, Kostenmanagement und mehr ab.
• 4:44
  Sie finden sie im Azure Portal, können nach dem Gewünschten suchen und es sofort zuweisen.
• 4:48
  Sie benötigen kein JSON, wenn sie es nicht selbst schreiben möchten.
• 4:50
  Aber eine Definition, die nur in einer Datei liegt, bewirbt nicht.
• 4:52
  Sie müssen sie zuweisen, damit sie funktioniert.
• 4:55
  Richtlinienzuweisung regeln die Praxis umsetzt.
• 4:56
  Bei einer Richtlinienzuweisung nehmen sie ihre Definition und weisen sie einem bestimmten Bereich zu.
• 5:01
  Ein Bereich ist einfach die Grenze, innerhalb derer die Regel gilt.
• 5:03
  Sie haben drei Möglichkeiten vom weitesten bis zum engsten Bereich.
• 5:06
  Weisen sie auf Managementgruppenebene zu, deckt sie eine ganze Reihe von Subscriptions ab.
• 5:09
  Weisen sie auf Subscription-Ebene zu, gilt sie für alles innerhalb dieser Subscription.
• 5:13
  Oder weisen sie sie auf Ressourcengruppenebene zu, dann gilt sie nur für die Ressourcen innerhalb dieser Gruppe.
• 5:17
  Lassen Sie uns nun über Färbung sprechen.
• 5:19
  Dies ist ein Schlüsselkonzept.
• 5:20
  Wenn Sie eine Richtlinie auf Managementgruppenebene zuweisen, wird sie automatisch auf alle darunterliegenden Subscriptions und Ressourcengruppen übertragen.
• 5:26
  Sie müssen sie nicht immer wieder neu zuweisen.
• 5:28
  Es ist wie ein Aushang am Hauptbrett am Eingang eines Bürogebäudes.
• 5:32
  Jeder, der dort vorbeikommt, muss sich daran halten.
• 5:34
  Sie würden die gleiche Regel nicht auf jeder Etage aushängen.
• 5:36
  Das wäre verschwendete Mühe.
• 5:38
  Die Regel wird einfach nach unten fangen.
• 5:39
  Aber was passiert, wenn Sie eine Ausnahme benötigen?
• 5:41
  Vielleicht schreibt Ihr Unternehmen vor, dass alle Daten in Europa bleiben müssen,
• 5:43
  aber ein Projekt hat einen triftigen Grund, ein Rechenzentrum in Asien zu nutzen.
• 5:46
  Sie möchten nicht die gesamte Richtlinie entfernen, da dies alles ungeschützt ließen.
• 5:50
  Also erstellen Sie eine Ausnahme.
• 5:51
  Ausnahmen ermöglichen es Ihnen, bestimmte Ressourcen oder Ressourcengruppen auszunehmen,
• 5:55
  ohne die Richtlinie überall sonst aufzuheben.
• 5:57
  Das ist eine saubere Methode, um Sonderfälle zu behalten.
• 5:58
  Hier sind praktische Empfehlungen.
• 6:01
  Weisen Sie Ihre umfassenden Basisrichtlinien auf Managementgruppenebene zu.
• 6:04
  Dinge wie zulässige Standorte oder erforderliche Tags sollten für alles gelten.
• 6:08
  Weisen Sie dann spezifischere Richtlinien auf Subscription- oder Ressourcengruppenebene zu.
• 6:11
  Vielleicht hat Ihre Entwicklungssubscription lockere Regeln als Ihre Produktionssubscription.
• 6:15
  Das ist vollkommen in Ordnung.
• 6:16
  Die spezifischen Richtlinien ergänzen die allgemeinen Richtlinien.
• 6:18
  Lassen Sie uns jetzt darüber sprechen, was tatsächlich passiert und jemand gegen eine Regel verstößt.
• 6:21
  Wir kommen Effekte ins Spiel.
• 6:23
  Effekte, was passiert, wenn Regeln gebrochen werden.
• 6:26
  Der Mäuse eine Regel erstellt und zugewiesen.
• 6:28
  Was passiert, wenn jemand dagegen verstößt?
• 6:29
  Wir kommen Effekte ins Spiel.
• 6:30
  Effekte sind dann Teil einer Richtlinie.
• 6:33
  Sie bestimmen, was passiert, wenn eine Ressource nicht der Regel entspricht.
• 6:36
  Es gibt vier Hauptdaten, die Sie kennen sollen.
• 6:38
  Erstens, ablehnen den DINI.
• 6:39
  Dies ist der häufigste Effekt für kritische Regeln.
• 6:41
  Wenn eine DINI-Richtlinie ausgelöst wird, wird die Bereitstellung vollständig blockiert.
• 6:45
  Der Benutzer erhält eine klare Fehlermeldung, dass die Validierung fehlgeschlagen ist und welche Richtlinie ihn gestoppt hat.
• 6:50
  Es wird keine Ressource erstellt, es entsteht kein Schaden.
• 6:53
  Verwenden Sie dies für Regeln, die niemals gebrochen werden dürfen.
• 6:55
  Zum Beispiel kein öffentlicher Blobzugriff auf Speicherkonten oder keine Bereitstellungen außerhalb genehmigter Regionen.
• 7:01
  Zweitens, überprüfen.
• 7:02
  Dies funktioniert anders.
• 7:03
  Die Bereitstellung wird durchgeführt, aber die Ressource wird im Compliance-Dashboard als nicht konform markiert.
• 7:07
  Audit ist unglaublich nützlich, wenn Sie sich nicht sicher sind, wie sich eine neue Regel auf Ihre Umgebung auswirbt.
• 7:12
  Sie können sehen, was passiert, ohne etwas zu beschädigen.
• 7:14
  Es ist, als würde man eine Messung durchführen, bevor man eine Änderung ist.
• 7:17
  Drittens, modifizieren und anhängen.
• 7:19
  Diese Effekte beheben das Problem automatisch, anstatt es zu blockieren.
• 7:22
  Modify ändert bestehende Einstellungen während der Bereitstellung.
• 7:25
  Append fügt einen bestehenden Filteres hinzu.
• 7:27
  Sie können zum Beispiel eine Richtlinie erstellen, die automatisch ein erforderliches Tag mit einem Standardwert hinzufügt.
• 7:31
  Wenn jemand vergisst, einen Kostenstellentag hinzuzufügen, ergänzt die Richtlinie es,
• 7:35
  die Bereitstellung erfolgt und die Ressource ist ohne Zusatzaufwand konform.
• 7:39
  Viertens, bereitstellen, wenn nicht vorhanden existen.
• 7:41
  Dies behandelt Situationen, in denen eine unterstützende Ressource fehlt.
• 7:44
  Angenommen, Sie möchten, dass die Diagnoseprotokollierung für jedes Speicherkonto aktiviert ist.
• 7:47
  Wenn jemand ein Speicherkonto ohne Diagnoseeinstellungen erstellt,
• 7:50
  greift DeployIfNotExists ein und stellt die fehlende Konfiguration automatisch bereit.
• 7:54
  Es ist, als hätte man einen Helfer dahinter am Aufräumen.
• 7:56
  Hier ist die bewährte Vorgehensweise.
• 7:57
  Beginnen Sie mit Audit.
• 7:58
  Sehen Sie sich zuerst an, was in Ihrer Umgebung tatsächlich passiert.
• 8:00
  Finden Sie heraus, wie viele Ressourcen von einer neuen Regel betroffen wären.
• 8:03
  Wechseln Sie dann zu den EI, sobald Sie sicher sind, dass die Regel korrekt ist
• 8:06
  und keine legitimen Bereitstellungen stört.
• 8:07
  Die Verwaltung einer einzelnen Richtlinie ist ab.
• 8:09
  Aber was ist, wenn Sie 50 davon benötigen, alle mit Bezug auf Sicherheit oder Compliance?
• 8:13
  Wir kommen Initiativen ins Spiel.
• 8:15
  Initiativen, bündeln, regeln.
• 8:17
  Was ist also eine Initiative?
• 8:18
  Betrachten Sie sie als eine Sammlung von Richtlinien, die alle um ein gemeinsames Ziel gruppiert sind.
• 8:21
  Anstatt 50 einzelne Richtlinien nacheinander zuzuweisen,
• 8:24
  weisen Sie eine einzige Initiative zu, die alle enthält.
• 8:27
  Es ist wie ein vorgepackter Werkzeugkasten für eine bestimmte Aufgabe.
• 8:30
  Sie nehmen nicht einzeln einen Hammer, einen Schraubendreher und einen Raubenschlüssel zu haben.
• 8:33
  Sie schnappen sich ein mit den ganzen Leckerkasten.
• 8:34
  Alles, was Sie brauchen, ist an einem Ort.
• 8:36
  Der eigentliche Vorteil hier ist die Compliance-Berichterstattung.
• 8:38
  Wenn Sie eine Initiative zuweisen, erhalten Sie eine einzige Compliance-Ansicht für die gesamte Gruppe.
• 8:42
  Sie sehen auf einen Blick, ob Ihre Umgebung den allgemeinen Standard erfüllt.
• 8:45
  Und wenn etwas nicht konform ist, können Sie direkt in die spezifische Richtlinie eintauchen, die nicht erfüllt ist.
• 8:49
  Das ist wesentlich übersichtlicher als 50 einzelne Richtlinien nachzuverfahren.
• 8:52
  Microsoft stellt integrierte Initiativen bereit, die die wichtigsten Compliance-Frameworks abdecken.
• 8:56
  Dinge wie den Azure Security Benchmark, CIS, NIST, PCI, DSS, HIPA, ISO, 27, KULDA1 und mehr und mehr.
• 9:03
  Diese sind bereits erstellt und bereit zu zuweisen.
• 9:05
  Sie müssen nicht herausfinden, welche Richtlinien zu welcher Compliance-Anforderung gehören.
• 9:09
  Microsoft hat diese Arbeit bereits, wie Sie erledigt.
• 9:11
  Einige dieser Initiativen enthalten hunderte von einzelnen Richtlinien.
• 9:14
  Stellen Sie sich vor, Sie müssten all diese einzeln zuweisen.
• 9:16
  Das würden Sie nicht tun.
• 9:16
  Sie würden die Initiative verwenden.
• 9:18
  Sie können auch benutzerdefinierte Initiativen für Ihre eigenen Standards stellen.
• 9:20
  Vielleicht haben Sie eine Produktions-Baseline, die Richtlinien für Verschlüsselung, Protokollierung und Netzwerksicherheit enthält.
• 9:26
  Oder eine Initiative für Kostenkontrollstandards, die VM-Größen begrenzt und Kostenstellen tags erfordert.
• 9:30
  Gleiches Prinzip.
• 9:31
  Bündeln Sie die Richtlinien, weisen Sie das Bündel zu und verfolgen Sie die Compliance als eine Einheit.
• 9:35
  Lassen Sie uns dies mit realen Beispielen konkretisieren, wie Leute Azure Policy tatsächlich nutzen.
• 9:40
  Reale Beispiele, Richtlinien der Praxis.
• 9:42
  Lassen Sie uns dies konkret machen.
• 9:43
  Hier sind fünf gängige Szenarien, in denen Azure Policy echte Probleme löst.
• 9:47
  Erstens regionale Einschränkungen für Datencompliance.
• 9:49
  Stellen Sie sich vor, Ihr Unternehmen hat die Richtlinie, dass alle Kundendaten in Europa bleiben müssen, müssen.
• 9:54
  Sie können die integrierte Richtlinie für zulässige Standorte auf der Ebene der Stammverwaltungsgruppe zuweisen
• 9:58
  und nur EU-Regionen wie Westeuropa und Nordeuropa erlauben.
• 10:02
  Wenn nun jemand ein neues Abonnement erstellt, erbt es automatisch diese Regel.
• 10:05
  Sie können keine Ressourcen in den USA oder Asien bereitstellen, selbst wenn Sie es versuchen.
• 10:08
  Die Richtlinie blockiert dies.
• 10:10
  Keine manuellen Prüfungen, kein Einholen von Genehmigungen.
• 10:12
  Die Regel wird einfach durchgesetzt.
• 10:13
  Zweitens Tagdurchsetzung für die Kostenaufteilung.
• 10:15
  Ihr Finanzteam muss die Ausgaben nach Abteilungen verfolgen.
• 10:18
  Was jedoch nicht möglich ist, wenn Ressourcen nicht die richtigen Tags haben.
• 10:21
  Also erstellen Sie eine Richtlinie, die für jede Ressource einen Kostenstellentag und einen Umgebungstag erfordert.
• 10:27
  Willkommt der intelligente Tag.
• 10:28
  Sie verwenden den Modify-Effekt.
• 10:29
  Wenn jemand vergisst, das Tag hinzuzufügen, fügt die Richtlinie es automatisch mit einem Standardwert hinzu.
• 10:33
  Die Bereitstellung wird durchgeführt und die Ressource ist konform.
• 10:36
  Die Finanzabteilung erhält genaue Kostendaten und Entwickler werden nicht durch ein fehlendes Tag blockiert.
• 10:40
  Drittens Kostenkontrolle in der Entwicklung.
• 10:41
  Entwicklungsteams experimentieren gerne, doch Experimente können schnell teuer werden.
• 10:45
  Jemand könnte eine GPU-Instanz mit 24 Kernen starten, nur um ein einfaches Skript zu testen.
• 10:49
  Also erstellen Sie eine Richtlinie, die VM-Größen in Entwicklungsabonnements auf kleinere SKUs beschränkt.
• 10:53
  Zum Beispiel B-Serien oder D-Serien mit begrenzten Kernen.
• 10:56
  Wenn jemand versucht, eine teure GPU oder eine VM mit viel Arbeitsspeicher bereitzustellen, greift der Denier-Effekt und blockiert dies.
• 11:02
  Entwickler können weiterhin experimentieren, aber das Budget nicht sprengen.
• 11:05
  Viertens Sicherheitsgrundlage für Speichern.
• 11:06
  Speicherkonten sind einer der häufigsten Orte für Sicherheitsfehler.
• 11:11
  Jemand erstellt ein Speicherkonto mit öffentlichem Blob-Zugriff und plötzlich sind sensible Daten im Internet verfügbar.
• 11:16
  Sie erstellen also eine Richtlinie, die nur HTTPS-Verkehr zulässt und den öffentlichen Blob-Zugriff blockiert.
• 11:21
  Und Sie nutzen Deploy-If-Not-Exist, um automatisch die Diagnose-Protokollierung für jedes Speicherkonto zu aktivieren, das diese noch nicht hat.
• 11:27
  Die Richtlinie löst das Problem, bevor es zu einem wird.
• 11:30
  Fünftens Namenskonventionen.
• 11:31
  Ihr Team möchte, dass alle Ressourcen mit POT oder DEV beginnen, um die Umgebung leicht zuordnen zu können.
• 11:39
  Sie erstellen eine Richtlinie, die den Ressourcenamen prüft, aber statt die Bereitstellung zu blockieren, nutzen Sie den Audit-Effekt.
• 11:44
  Nutzen Sie den Audit-Effekt.
• 11:45
  Die Ressource wird erstellt, aber ist nicht konform markiert.
• 11:47
  Dann erstellen Sie einen monatlichen Compliance-Bericht und bitten das Team, die Benennung zu korrigieren.
• 11:51
  Das ist eine sanfte Methode, Standards durchzusetzen, ohne Arbeitsabläufe zu unterbrechen.
• 11:54
  Jedes dieser Beispiele folgt demselben Muster.
• 11:56
  Problem identifizieren, Richtlinie wählen oder erstellen, Effekt festlegen, Bereich zuweisen, Compliance überwachen.
• 12:03
  Das ist Regelwerk.
• 12:04
  Lassen Sie uns nun herauszoomen und sehen, wie diese Teile in das größere Azure-Governance-Bild passen.
• 12:09
  Das große Ganze, wie alles zusammenhängt.
• 12:11
  Wo passt Azure Policy also in das Gesamtbild?
• 12:14
  Trachten wir es einmal so.
• 12:15
  Azure Policy arbeitet auf der Ebene der Steuerungsebene direkt über dem Azure-Resource-Manager und bewertet jede eingehende Anfrage.
• 12:21
  Jedes Mal, wenn jemand eine Ressource erstellt, aktualisiert oder löscht, prüft Azure Policy die Regeln.
• 12:27
  Es fungiert als Türsteher am Eingang.
• 12:29
  Es ist jedoch nicht das einzige Werkzeug im Governance-Werkzeugkasten.
• 12:32
  Azure Policy ist nur ein Teil eines größeren Systems.
• 12:35
  Verwaltungsgruppen bilden die Hierarchie, um Abonnements zu organisieren und Regeln skaliert anzuwenden.
• 12:39
  Die rollenbasierte Zugriffssteuerung entscheidet, wer Zugriff worauf hat,
• 12:42
  während Azure Policy steuert, welche Konfigurationen zulässig sind.
• 12:45
  Zusammen bilden sie das Fundament der Cloud-Governance.
• 12:48
  Nun, hier ist der entscheidende Punkt.
• 12:48
  Azure Policy ist auch die Engine hinter anderen Diensten, die sie möglicherweise bereits nutzen.
• 12:52
  Microsoft Defender for Cloud verwendet Azure Policy, um seine Compliance-Empfehlungen zu generieren.
• 12:57
  Wenn Defender Ihnen meldet, dass ein Speicherkonto nicht konform ist, führt es eigentlich eine Richtlinienbewertung durch.
• 13:02
  Azure Advisor bezieht viele seiner Empfehlungen zu Kosten und Zuverlässigkeit aus denselben Richtlinienbewertungen.
• 13:07
  Äh.
• 13:07
  Und das Compliance-Dashboard im Azure-Portal basiert vollständig auf Richtliniendaten.
• 13:11
  Auch wenn Sie selbst noch nie eine Richtlinie erstellt haben, haben Sie diese wahrscheinlich unwissentlich bereits genutzt.
• 13:15
  Es gibt eine weitere Praxis namens Policy as Code.
• 13:18
  Anstatt Richtlinien über das Portal zu erstellen, speichern Sie diese als JSON-Dateien in einem Git-Repository
• 13:22
  und stellen sie über CI-CCD-Pipelines bereit, genau wie Anwendungscode.
• 13:26
  Das ermöglicht Inversionskontrolle, Code-Reviews und automatisierte Tests für Ihre Governance-Regeln.
• 13:30
  Es ist eine besser skalierbare Methode zur Verwaltung von Richtlinien in großen Unternehmen.
• 13:34
  Hier ist das Wichtigste, das Sie mitnehmen sollten.
• 13:36
  Sobald Sie Azure Policy richtig eingerichtet haben, läuft es unbemerkt im Hintergrund.
• 13:40
  Es ist die automatische Leitplanke, die Probleme verhindert, bevor sie entstehen.
• 13:43
  Benutzer merken vielleicht gar nicht, dass es da ist, aber Sie profitieren bei jeder Ressourcenbereitstellung davon.
• 13:48
  Sie erhalten jedes Mal eine konsistente Durchsetzung, ohne manuelle Prüfungen, Genehmigungstickets oder menschliche Fehler.
• 13:53
  Dass es also Azure Policy einfach erklärt, es ist ein unsichtbares Regelwerk,
• 13:57
  das die Standards Ihres Unternehmens für jede Ressource jederzeit durchsetzt.
• 14:01
  Wenn Sie eine einzige Handlung aus dieser Folge mitnehmen möchten, dann diese.
• 14:04
  Gehen Sie in das Azure-Portal, suchen Sie nach Policy und weisen Sie die integrierte Richtlinie für erlaubte Standorte einer Testsubscription zu.
• 14:11
  Beginnen Sie mit der Überwachung und sehen Sie, was passiert.
• 14:12
  Das ist der schnellste Weg, um zu verstehen, wie das funktioniert.
• 14:15
  Abonnieren Sie für weitere Microsoft-Wissens-Häppchen und teilen Sie dies mit jemandem, der seine Azure-Reise beginnt.
• 14:19
  Hinterlassen Sie einen Kommentar mit dem, was Sie als nächstes erklären sollen.