Latest / M365.FM – Microsoft 365, Copilot & KI Podcast auf Deutsch / Was ist eine Azure Landing Zone? Die 8 Designbereiche einfach erklärt – Governance statt Cloud-Chaos (KI-Synchronfassung)

Transcript

Was ist eine Azure Landing Zone? Die 8 Designbereiche einfach erklärt – Governance statt Cloud-Chaos (KI-Synchronfassung) · M365.FM – Microsoft 365, Copilot & KI Podcast auf Deutsch

0:00
Willkommen zu einer weiteren Episode der Microsoft Knowledge Nuggets hier auf M365FM.
0:04
Ich bin der Gastgeber Mirko Peters.
0:05
In dieser Serie nehmen wir uns eine Microsoft-Technologie vor und erklären sie in einfacher Sprache.
0:09
Das heutige Thema ist etwas, von dem fast jeder schon gehört hat, aber die meisten nicht wirklich erklären können.
0:13
Azure Landing Zones, denn sie folgen.
0:15
Stellen Sie sich vor, Sie übernehmen einen Azure-Tenant, in dem jedes Team sein eigenes Ding gemacht hat.
0:19
Keine Namenskonvention, keine Richtlinien, kein Netzwerkplan, Abonnements, überall.
0:23
Einiges produktiv, anderes zum Testen und man kann nicht unterscheiden, was es ist.
0:25
Niemand weiß, wer was besitzt, die Abrechnung ist ein Rätsel.
0:28
Und wenn etwas ausfällt, dauert die Fehlersuche Stunden.
0:30
Das ist das Problem des Cloud-Chaos und es kommt überraschend häufig vor.
0:34
Häufiger, als Sie denken.
0:35
Azure Landing Zones verhindern dieses Chaos, bevor es überhaupt entsteht.
0:38
Am Ende dieser Folge werden Sie verstehen, was eine Landing Zone eigentlich ist,
0:41
warum die acht Designbereiche wichtig sind und wie man die häufigsten Fehler vermeidet.
0:46
Schnappen Sie sich Ihren Kaffee und legen wir los.
0:48
Was ist eigentlich eine Azure Landing Zone?
0:50
Die meisten Leute denken, eine Azure Landing Zone sei ein Produkt, das man per Klick bereitstellt, aber das ist es nicht.
0:54
Es gibt im Portal, kein Button auf dem Landing Zone erstellen steht.
0:57
So funktioniert das nicht.
0:59
Eine Landing Zone ist eine vorkonfigurierte Umgebung, in der bereits Leitplanken fahren.
1:02
Netzwerk, Identität, Monitoring, Richtlinien, alles ist verkabelt, bevor Workloads ankommen.
1:07
Denken Sie daran, wie ein Kauf eines Hauses, das bereits über Strom, Wasserleitungen und ein Sicherheitssystem verfügt.
1:11
Sie ziehen einfach ein und fangen an zu arbeiten, ohne die Leitungen selbst verlegen zu machen.
1:15
Die Hauptidee ist, dass das Abonnement die Einheit der Isolierung ist, nicht die Ressourcengruppe, nicht die Ressourcen.
1:19
Ein Abonnement ist Ihre Grenze für den Schadensrallyen.
1:21
Sie geben einem Team ein Abonnement, weil Abonnements Ihre eigenen Kontingentgrenzen, Richtlinienzuweisungen und Abrechnungen mitbringen.
1:27
Die Landing Zone umschließt dieses Abonnement mit allem, was zentral festgelegt wurde.
1:31
Welche Regionen erlaubt sind, mit welchem Netzwerk eine Verbindung besteht, welche tagszwingend erforderlich sind und was verboten ist.
1:37
Was setzt die Regeln also tatsächlich durch?
1:38
Azure Policy, nicht Dokumentation, nicht gute Vorsätze.
1:41
Es wird auf Managementgruppenebene zugewiesen und erfüllt drei Aufgaben.
1:44
Der New blockiert Dinge wie nicht zulässige Regionen oder öffentliche IP-Adressen.
1:47
Audit kennzeichnet nicht konforme Ressourcen, ohne sie zu blockieren.
1:50
Deploy of Not Exist sorgt für automatische Abhilfe, in denen Dinge wie Diagnoseeinstellungen für Log Analytics oder Microsoft Defender Pläne bereitgestellt werden.
1:57
Das ist der Unterschied zwischen Governance, die nur eine Wiki-Seite ist, und Governance, die Code ist.
2:01
Teams bewegen sich schnell innerhalb ihrer Box, aber das Plattform-Team kontrolliert die Box, nicht den Inhalt.
2:05
Der große Wandel besteht darin, Teams ihre eigenen Abonnements zu lassen, während das zentrale Team die Regeln festlegt.
2:10
Identität und Governance, die Eingangstür in das Regelbuch.
2:12
Es ist so, eine Landingzone besteht nicht nur aus einer einzigen Sache, sie baut auf acht Entwurfsbereichen auf.
2:18
Schauen wir uns die ersten drei an.
2:20
An erster Stelle stehen die ASIO-Abrechnung und der Entramandant.
2:22
Dabei geht es darum, den Mandanten und das Abonnement von Anfang an richtig einzurichten.
2:26
Klingt einfach, aber Sie werden überrascht, wie viele Organisationen das falsch machen.
2:29
Sie müssen sich Gedanken über Ihre Abrechnungsstruktur, Ihre Registrierung und die Anbindung an den Entramandanten machen, bevor Sie irgendetwas bereitstellen.
2:36
Ihre primäre Sicherheitsgrenze ist das Identitäts- und Zugriffsmennen.
2:39
Stellen Sie sich Entra-ID, wie den Empfang, in einem Bürogebäude vor.
2:41
Es entscheidet, wer hinein darf und was die Person tun darf.
2:44
Sie sollten Privileged Identity Management, kurz PIM, nutzen und ABLC-Rollen mit den geringsten Rechten durchsetzen.
2:50
Geben Sie nicht jedem Besitzer Zugriff, das ist ein Rezept für ein Desaster.
2:53
Nutzen Sie stattdessen PIM für temporären Just-in-Time-Zugriff bei Bedarf und richten Sie regelmäßige Zugriffsüberprüfungen ein, um nicht mehr benötigte Berechtigungen zu bereinigen.
3:00
Der dritte Entwurfsbereich ist die Ressourcenorganisation.
3:03
Verwaltungsgruppen, Abonnements und Ressourcengruppen.
3:07
Verwaltungsgruppen stehen über Abonnements.
3:09
Richtlinien und Rollenzuweisungen werden im Baum nach unten vererbt.
3:12
Die Referenzhierarchie des Cloud Adoption Framework beginnt an der Mandantenwurzel, gefolgt von einer Zwischengruppe für Ihre Organisation.
3:18
Darunter finden Sie Plattformen, Landingzones, Außerbetriebnahme und Sandbox.
3:21
Die Plattform enthält Ihre gemeinsam genutzten Abonnements, Identitätsverwaltung und Konnektivität.
3:27
Landingzones unterteilen sich in Korb für Workloads mit On-Premises-Anbindung und online für internetseitige Apps.
3:33
Warum ist diese Struktur wichtig?
3:34
Sie weisen eine Richtlinie einmal weit oben im Baum zu und alles darunter erfüllt diese automatisch.
3:38
Ein Praxisbeispiel.
3:39
Eine DENI-Richtlinie ganz oben blockiert nicht zugelassene Regionen für jedes untergeordnete Abonnement.
3:44
Sie müssen dies nicht 50 Mal konfigurieren.
3:46
Einmal einstellen und es wird vererbt.
3:47
Das ist die wahre Stärke der Verwaltungsgruppen-Hierarchie.
3:49
Netzwerk und Sicherheit, die Mauern und die Schlösser.
3:53
Identität und Governance legen die Regeln fest.
3:55
Aber nichts davon funktioniert, wenn das Netzwerk ein Chaos ist.
3:57
Netzwerk, Topologie und Konnektivität bilden den Wurfsbereich 4.
4:00
Wie sind Ihre virtuellen Netzwerke strukturiert?
4:02
Es gibt zwei Hauptmuster, Hub und Spoke, bei dem Sie ein zentrales virtuelles Netzwerk als Hub haben
4:06
und mehrere Spoke-Netzwerke daran anbinden.
4:08
Oder Azure Virtual VARN, Microsofts verwaltete Version dieses Konzepts für größere Skalierungen.
4:14
Der Hauptbeherbergt all Ihre gemeinsamen genutzten Dienste.
4:15
Azure Firewall zur Verkehrsinspektion, Express-Route oder VPN-Gateways für On-Premises-Verbindungen,
4:21
DNS-Auflösungen, Dinge, die jeder Workload benötigt.
4:23
In den Spokes laufen Ihre eigentlichen Workloads.
4:26
Sie sind per Peering mit dem Hub verbunden, sodass der Datenverkehr durch zentrale Dienste fließt,
4:29
jeder Spoke aber von den anderen isoliert bleibt.
4:31
Hier ist ein häufiger Fehler.
4:33
Teams erstellen ein riesiges Peering-Netz, anstatt einen Hub zu nutzen
4:36
und verbinden jedes virtuelle Netzwerk direkt mit jedem anderen.
4:38
Das funktioniert eine Weile, wird aber schnell unübersichtlich.
4:41
Am Ende haben Sie ein Netz aus Verbindungen, das niemand mehr nacherfolgen kann.
4:44
Ein Hub vereinfacht alles.
4:46
Ein Ort zur Verwaltung, ein Ort zur Absicherung.
4:49
Planen Sie Ihre IP-Adressbereiche im Voraus.
4:51
Das ist wichtiger, als Sie denken.
4:53
Sobald Spokes mit einem Hub verbunden sind, sind überlappende Adressbereiche mühsam zu beheben.
4:56
Man kann sie nicht einfach hin.
4:58
Sie müssen das Peering aufheben, den Bereich aktualisieren und neu verbinden.
5:02
Wenn Produktionsworkloads laufen, bedeutet das Ausfallzeit.
5:04
Wählen Sie Ihre CADR-Bereiche also frühzeitig und stellen Sie sicher, dass Sie sich nicht überschneiden.
5:07
Design-Bereich 5 umfasst Sicherheitsempfehlungen für Verschlüsselung, Identität, Schutz, Bedrohungserkennung und Schwachstellenmanagement.
5:14
Aktivieren Sie Microsoft Defender für Cloud als Basis für alle Abonnements.
5:18
Es bietet Ihnen Empfehlungen zur Zustandsverwaltung, Warnungen und Anleitungen zur Behebung für Ihre gesamte Umgebung, für Ihre Gebung.
5:24
Verwenden Sie private Endpunkte, um Dienste vom öffentlichen Internet fernzuhalten.
5:27
Anstatt auf ein Speicherkonto über eine öffentliche IP zuzugreifen, geben Sie ihm eine private IP innerhalb Ihres virtuellen Netzwerks.
5:32
Der Datenverkehr verlässt nie den Microsoft-Backbone.
5:34
Es ist sicherer und einfacher zu verwalten.
5:37
Platzieren Sie Netzwerksicherheitsgruppen in jedem Subnetz und blockieren Sie eingehendes RDP aus dem Internet standardmäßig.
5:41
Das sollte Standard sein.
5:43
Wenn jemand Fernzugriff benötigt, verwendet er Azure Bastion oder eine Jumpbox, keine direkte RDP-Regel.
5:48
Ein Praxisbeispiel, eine Verweigerungsrichtlinie, die öffentliche IP-Adressen für Speicherkonten blockiert.
5:52
Sie weisen die Richtlinie auf Managementgruppenebene zu und sobald jemand ein Speicherkonto mit einem öffentlichen Endpunkt bereitstellen will, schlägt die Bereitstellung fehl.
5:58
Die Fehlermeldung erklärt den Grund und der Benutzer muss stattdessen einen privaten Endpunkt verwenden.
6:02
Keine Ausnahmen.
6:03
Das ist Governance, die wirklich funktioniert und nicht nur eine Empfehlung in einem Dokument.
6:07
Verwaltung, Governance und Automatisierung sorgen für den laufenden Betrieb.
6:10
Sie haben also Ihr Gebäude mit Mauern und Schlössern.
6:12
Aber was passiert eigentlich darin?
6:13
Sie müssen alles im Blick haben.
6:15
Design-Bereich 6 ist das Management.
6:16
Das umfasst Überwachung, Backup-Protokollierung und den operativen Bereich.
6:20
Sie benötigen einen zentralen Log-Analytics-Arbeitsbereich, an dem jedes Abonnement seine Protokolle sind.
6:24
Ein Ort, um alles abzufragen, Warnungen einzurichten und Fehler zu beheben.
6:27
Das ist das Ziel.
6:28
Wir stellen Sie nun sicher, dass jede einzelne Ressource Ihre Diagnose-Protokolle dorthin sind.
6:31
Das machen Sie nicht manuell.
6:32
Sie erstellen eine Richtlinie, die besagt, jede Ressource muss Ihre Diagnose-Protokolle an diesen Log-Analytics-Arbeitsbereich senden.
6:38
Und Sie stellen diese Richtlinie so ein, dass Sie Ihren Modus bereits jedenfalls nicht vorhanden ausgefügt.
6:41
Das Ergebnis, jede neue Ressource wird automatisch konfiguriert.
6:44
Niemand muss daran denken.
6:45
Es passiert einfach.
6:45
Design-Bereich 7 ist Governance, weil der Azure Policy zur Durchsetzung der Compliance eingesetzt wird.
6:49
Sie bündeln zugehörige Regeln in einer sogenannten Richtlinieninitiative oder einem Richtlinienseite.
6:53
Eine Initiative für Sicherheit, eine andere für Kostenmanagement.
6:57
Jede davon enthält mehrere Richtlinien, die zusammenwirken.
6:59
Hier ein Beispiel.
7:01
Ein Richtliniensatz der Verschlüsselung, Tagging und zugelassene VM-Größen erzwingt.
7:06
Sie wenden dies auf der Ebene der Management-Gruppe an.
7:08
Jedes untergeordnete Abonnement erbt diese Regel.
7:10
Wenn ein Entwickler versucht, eine VM bereitzustellen, prüft die Richtlinie, ob eine genehmigte Größe verwendet wird,
7:15
die erforderlichen Tags vorhanden sind und die Festplatten verschlüsselt sind.
7:18
Wenn eine Prüfung fehlschlägt, wird die Bereitstellung direkt blockiert oder markiert.
7:21
Lassen Sie uns den Unterschied verdeutlichen zwischen Governance auf einer Wiki-Seite und Governance als tatsächlicher Code.
7:26
Eine Wiki-Seite sagt, bitte taggen Sie Ihre Ressourcen.
7:29
Eine Richtlinie sagt, Sie können keine Ressource ohne die erforderlichen Tags bereitstellen.
7:33
Das eine ist eine Empfehlung, das andere wird automatisch durchgesetzt.
7:36
Designbereich 8 ist Plattformautomatisierung und DevOps.
7:39
Infrastruktur als Code und CI-CD Pipelines.
7:42
Betrachten Sie die Landing-Zone selbst als Code?
7:44
Das bedeutet BICEP, ARM-Templates oder Terraform, gespeichert in der Quellcode-Verwaltung.
7:48
Jede Änderung erfolgt über einen Pull-Request.
7:50
Jede Bereitstellung läuft durch eine Pipeline.
7:51
Kein Herumklicken im Azure-Portal.
7:53
Hier kommt das Subscription-Vending ins Spiel.
7:55
Eine wiederholbare Pipeline, die bei Bedarf neue Abonnements erstellt.
7:58
Ein Team sendet eine Anfrage mit Parametern wie Kostenstelle, Netzwerkgröße und Umgebungstyp.
8:03
Die Pipeline erstellt das Abonnement, ordnet es der richtigen Managementgruppe zu, weist Budgets zu,
8:07
konfiguriert das Spoke-Netzwerk und verbindet es mit dem Hub.
8:10
Alles automatisiert.
8:12
Warum ist das wichtig?
8:13
Weil das neue Abonnement von dem Moment an konform ist, in dem es existiert?
8:17
Die Richtlinien sind bereits auf der Managementgruppe aktiv und das Abonnement erbt alles automatisch.
8:21
Es gibt kein Zeitfenster, in dem es nicht reguliert ist.
8:23
Niemand muss daran denken, die Regeln manuell anzuwenden.
8:25
Sie sind bereits vorhanden.
8:26
Dadurch kann ein Plattform-Team hunderte von Abonnements unterstützen, ohne zum Flaschenhals zu werden.
8:31
Die Automatisierung erledigt die Schwerstarbeit und das Team konzentriert sich auf die Verbesserung der Plattform,
8:35
anstatt für jede einzelne Anfrage durch das Portal zu klicken.
8:37
Die Trennung von Plattformen und Anwendungen, das häufigste Missverständnis.
8:41
Das waren also die acht Designbereiche, aber hier machen die meisten Leute Fehler.
8:45
Es gibt zwei Arten von Landingzones.
8:47
Und diese zu verwechseln ist der häufigste Fehler, die ich sehe.
8:49
Plattform-Landingzones und Anwendungs-Landingzones.
8:51
Sie dienen völlig unterschiedlichen Zwecken.
8:53
Plattform-Landingzones sind das gemeinsame Fundament, das dem Plattform-Team gehört.
8:56
Sie haben ein Identitätsabonnement für Ihre Domänen-Dienste, ein Verwaltungsabonnement mit Log-Analytics und Automatisierungskonten
9:02
sowie ein Konnektivitätsabonnement für das virtuelle Hub-Netzwerk, die Azure Firewall und ExpressRawall und ExpressRoute oder VPN-Gateways.
9:09
Dies sind die gemeinsam genutzten Dienste, von denen jede Workload abhängig ist.
9:11
Anwendungs-Landingzones sind der Ort, an dem Workloads tatsächlich ausgeführt wird.
9:14
Dies sind die Abonnements, die Anwendungsteams erhalten.
9:17
Es gibt viele davon.
9:18
Sie sind wegwerfbar.
9:19
Und sie folgen jedes Mal demselben Muster.
9:20
Ein Team erhält ein Abonnement.
9:22
Es wird in die richtige Verwaltungsgruppe eingeordnet, erbt die Richtlinien, stellt ein Peering zum Hub-Netzwerk her und beginnt mit der Bereitstellung.
9:28
Der Unterschied in der Eigentumerschaft ist wichtig.
9:30
Plattform-Zonen sind rar.
9:31
Vielleicht insgesamt drei bis fünf Abonnements.
9:33
Sie sind langlebig und werden zentral vom Plattform-Team verwaltet.
9:36
Anwendungs-Landingz-Viele.
9:37
Sie könnten Dutzende oder Hunderte haben.
9:39
Sie sind temporär.
9:40
Eine Workload wird bereitgestellt, läuft eine Zeit lang und wird dann stillgelegt.
9:43
Das Abonnement wird bereinigt und das Muster wiederholt sich.
9:45
Hier ist das klassische Anti-Pattern.
9:47
Jemand platziert eine gemeinsame Firewall in einem Anwendungsabonnement.
9:50
Oder stellt das Express-Route-Gateway in einem Workload-Abonnement anstatt im Konnektivitätsabonnement bereit.
9:55
Jetzt sind gemeinsame Dienste in der gesamten Umgebung verstreut.
9:58
Niemand weiß, wo sich was befindet.
9:59
Das Plattform-Team kann die Firewall nicht verwalten, da sie sich in einem fremden Abonnement befindet.
10:03
Und das Anwendungsteam möchte sie nicht warten.
10:05
Es ist ein Chaos.
10:06
Behalten Sie gemeinsame Dienste in der Plattform eben.
10:08
Das Konnektivitätsabonnement enthält das virtuelle Hub-Netzwerk, die Azure Firewall und das Express-Route-Gateway.
10:14
Anwendungsabonnements führen ein Peering damit durch.
10:15
Sie besitzen nichts davon.
10:17
Sie nutzen es lediglich.
10:17
Was dies für Sie bedeutet, ist eine klare Trennung der Verantwortlichkeiten.
10:21
Das Plattform-Team kontrolliert den Rahmen, die Leitplanken, die gemeinsamen Dienste und die Richtlinien.
10:25
Ah, Anwendungsteams bewegen sich darin schnell.
10:28
Sie erhalten ein Abonnement, das bereits konform, verbunden und überwacht ist.
10:31
Sie müssen nicht über das Fundament nachdenken.
10:33
Sie bauen einfach darauf auf, wie die Teile zusammenpassen.
10:36
Der Aha-Moment.
10:37
Sie kennen nun die einzelnen Bausteine, aber hier ist das, was wirklich zählt.
10:40
Sie funktionieren nicht isoliert.
10:42
Sie arbeiten als ein verbundenes System zusammen.
10:44
Und genau dann ergibt alles einen Sinn.
10:45
Denken Sie einmal so darüber nach.
10:47
Die Identität entscheidet, wer durch die Vordertür eintreten darf.
10:49
Die Governance legt dann fest, in welche Räume Sie nach dem Eintritt gehen dürfen.
10:53
Das Netzwerk steuert, wie Sie sich zwischen diesen Räumen bewegen.
10:56
Die Sicherheit überwacht Bedrohungen an jeder Ecke.
10:58
Das Management sorgt für einen reibungslosen Betrieb des gesamten Gebäudes.
11:01
Und die Automatisierung macht jeden einzelnen Schritt wiederholbar, damit nichts vergessen wird.
11:04
Jeder Teil hängt von den anderen ab.
11:06
Und gemeinsam schaffen Sie etwas, das weit über die einzelnen Teile hinausgeht.
11:09
Lassen Sie mich Ihnen ein konkretes Beispiel dafür geben, wie diese Interaktion tatsächlich funktioniert.
11:12
Denn Sie sich vor ein neues Team muss eine Workload bereitstellen.
11:14
Sie stellen eine Anfrage über die Subscription Vending Pipeline und diese Pipeline erstellt automatisch ein brandneues Abonnement.
11:21
Sie ordnet das Abonnement der richtigen Verwaltungsgruppe zu, wodurch das Abonnement sofort alle Richtlinien dieser Gruppe erbt.
11:26
Verschlüsselungsanforderungen, zugelassene Regionen, obligatorische Tags, Protokollierungskonfigurationen, alles, was benötigt wird.
11:34
Die Pipeline konfiguriert außerdem das Spoke-Netzwerk und verbindet es Bepeering.
11:38
Diagnoseeinstellungen senden Protokolle direkt an den zentralen Log Analytics Arbeitsbereich, während Defender for Cloud den Schutz aktiviert.
11:44
Das gesamte Abonnement ist innerhalb weniger Minuten konform, verbunden und überwacht, ganz ohne menschliches Eingreifen.
11:50
Das ist der wahre Unterschied zwischen Cloud-Cares und Cloud-Kontrolle.
11:52
In der unübersichtlichen Umgebung, die ich anfangs beschrieben habe, hängt jeder einzelne dieser Schritte davon ab, dass jemand daran denkt und Menschen vergessen Dinge.
12:00
Oder sie machen es jedes Mal anders oder sie tun es überhaupt nicht.
12:02
Doch mit einer richtigen Landingzone läuft es automatisch.
12:05
Das System erzwingt die Einhaltung selbst und das Team kann schnell agieren, ohne Dinge zu beschädigen.
12:09
Hier stolpern die meisten Organisationen.
12:11
Sie behandeln die Landingzone wie ein einmaliges Projekt.
12:13
Bereitstellen, abhaken, weitermachen.
12:16
Aber eine Landingzone ist eine lebendige Plattform.
12:18
Azure veröffentlicht jenlich neue Funktionen.
12:19
Ihre Compliance-Anforderungen ändern sich im Laufe der Zeit.
12:21
Ihr Unternehmen wächst.
12:22
Die Landingzone muss mitwachsen, sonst arbeitet sie gegen sie.
12:25
Das Betriebsmodell ist tatsächlich wichtiger als die technischen Vorlagen.
12:28
Es wird die Landingzone verantwortlich.
12:29
Wie entwickelt sie sich weiter?
12:30
Wie werden Ausnahmen gehandhabt?
12:32
Wenn ihre einzige Antwort lautet, das Plattform-Team verwaltet das U, dann reicht es nicht aus.
12:35
Sie benötigen echte Prozesse.
12:36
Sie benötigen ein ordentliches Backlog.
12:38
Sie müssen die Landingzone wie ein Produkt behandeln, nicht wie ein Projekt.
12:40
Hier ist ein Beispiel aus der Praxis.
12:42
Ein Plattform-Team betreut 200 Abonnements, ohne zum Flaschenhals zu werden.
12:45
Das Geheimnis ist Subscription-Landing in Kombination mit Richtlinienvererbung.
12:48
Das Team klickt sich nicht durch das Portal, um jedes Abonnement manuell zu erstellen.
12:52
Die Pipeline erledigt es automatisch.
12:54
Sie konfigurieren nicht manuell die Protokollierung für jede Work.
12:56
Richtlinien erzwingen dies konsequent.
12:58
Sie überprüfen nicht jede Bereitstellung auf Compliance.
13:00
Das Compliance-Desport zeigt Ihnen lediglich die Ausnahmen ab.
13:02
Sie konzentrieren sich auf die Abweichler statt auf die Routinearbeit.
13:05
Und genau das ist der Unterschied zwischen einer Plattform, die skaliert und einer, die das Geschäft ausbremst.
13:09
Praktische Erkenntnisse.
13:11
Klein anfangen, klug wachsen.
13:13
Was machen Sie also konkret am Montagmorgen?
13:15
Hier ist die ehrliche Antwort.
13:16
Versuchen Sie nicht am ersten Tag die vollständige Enterprise-Scale-Hierarchie aufzubauen.
13:20
Das ist eine Falle, die Sie vermeiden sollen.
13:22
Sie werden Monate damit verbringen, Szenarien zu entwerfen, die vielleicht nie eintreten.
13:25
Und Sie werden nie wirklich etwas veröffentlichen.
13:26
Starten Sie stattdessen mit einer Minimum Viable Landing Zone, kurz MVLZ.
13:30
Die Kernkomponenten sind simpel.
13:33
Eine Verwaltungsgruppen-Hierarchie, einige Kernrichtlinien wie Regionenbeschränkungen, Verschlüsselung und Pflichttags,
13:38
grundlegendes Networking mit einem Hub-Finet und einem Spoke,
13:41
sowie eine zentralisierte Protokollierung in einem Log Analytics Workspace.
13:44
Das reicht aus.
13:45
Sie brauchen am ersten Tag kein Azure Virtual Warn und keine komplexe Richtlinieninitiative mit 200 Regeln.
13:51
Sie benötigen lediglich genügend Leitplanken für die Sicherheit nicht mehr.
13:54
Bringen Sie dann Ihre erste echte Workload in diese MVLZ, keine Test-VM,
13:57
sondern eine tatsächliche Arbeitslast, die für Ihr Team wichtig ist.
14:00
Beobachten Sie, wie sich die Richtlinien verhalten, was nicht funktioniert.
14:03
Lernen Sie aus den Reibungspunkten mit, iterieren Sie von dort aus.
14:05
Fügen Sie bei Bedarf weitere Richtlinien hinzu, erweitern Sie das Netzwerk bei Bedarf
14:09
und lassen Sie die Landing Zone organisch mit Ihrem Unternehmen wachsen.
14:12
Lassen Sie mich Ihnen drei konkrete Punkte nennen, die Sie sofort umsetzen können.
14:15
Erster Punkt.
14:16
Bereitstellen Sie den Azure Landing Zones Accelerator aus dem Portal in einem Testmandanten.
14:20
Es kostet nichts, dauert etwa eine Stunde
14:22
und der zieht mehr über die Funktionsweise von Verwaltungsgruppen, Richtlinien und Vererbung
14:26
als jedes Diagramm oder Dokumentation.
14:28
Sie können die Hierarchie sehen, die Anwendung der Richtlinien in Echtzeit verfolgen
14:32
und experimentieren, ohne etwas Wichtiges zu beschädigen.
14:36
Zweiter Punkt.
14:36
Aktivieren Sie Richtlinien zunächst im Audit-Modus, nicht im Modus ablehnen.
14:40
Der Audit-Modus zeigt Ihnen genau, was in Ihrer Umgebung nicht konform ist,
14:43
ohne jemanden zu blockieren.
14:44
Beobachten Sie das Compliance-Dashboard und ich verspreche Ihnen, Sie werden überrascht
14:47
sein, wie viele Ressourcen stillschweigend gegen Regeln verstoßen, die Sie für offensichtlich
14:50
hielten.
14:50
Sobald Sie Ihre Landschaft verstehen, können Sie die wichtigen Richtlinien auf den Modus
14:53
ablehnen und umstellen.
14:55
Aber beginnen Sie mit Audit, damit Sie Ihre eigenen Teams nicht ausschließen, bevor
14:58
Sie wissen, womit Sie es zu tun haben.
15:00
Dritter Punkt.
15:00
Planen Sie Ihre IP-Adressbereiche und die Hierarchie der Verwaltungsgruppen, bevor Sie irgendetwas
15:04
bereitstellen.
15:05
Ich weiß, das klingt langweilig, aber eine spätere Änderung ist wirklich schmerzhaft.
15:09
Überlappende IP-Bereiche bedeuten, Netzwerk-Peerings abzuweisen und die Umstrukturierung von Verwaltungsgruppen
15:13
erfordert das Verschieben von Abonnements und die Neubewertung von richtigen Zuweisungen.
15:16
Wenn Sie diese beiden Dinge von Anfang an richtig machen, sparen Sie sie später wochenlange
15:19
Nacharbeit.
15:20
Die üblichen Fallstricke sind ziemlich offensichtlich.
15:22
Übertechnisierung führt zu einer Analyse-Paralyse, die verhindert, dass Sie jemals etwas bereitstellen.
15:27
Untertechnisierung lässt Sie ohne Leitplanken zurück, was nur Cloud-Chaos unter einem anderen
15:30
Namen ist.
15:31
Und die Landingzone als einmaliges Projekt, anstatt als lebendige Plattform zu betrachten, führt garantiert
15:34
dazu, dass Sie den Anschluss verlieren.
15:35
Vermeiden Sie diese drei Fallen.
15:36
Und Sie sind den meisten Unternehmen bereits voraus.
15:39
Denken Sie daran, das Ziel ist nicht die perfekte Landingzone.
15:41
Das Ziel ist ein kontrolliertes Fundament, mit dem Teams schnell arbeiten können, ohne
15:44
Chaos zu stiften.
15:45
Fangen Sie klein an, iterieren Sie und lassen Sie Richtlinien die Hauptarbeit für Sie
15:47
erledigen.
15:49
Das sind also Azure Landingzones, einfach erklärt.
15:51
Es ist kein kompliziertes Unternehmenskonzept, stellen Sie es sich als ein verwaltetes Abonnement
15:55
mit integrierten Leitplanken vor.
15:56
Die acht Designbereiche sind einfach nur Fragen, die Sie vor dem Deployment beantworten müssen.
16:01
Identität, Netzwerk, Sicherheit, Verwaltung, Governance, Automatisierung.
16:04
Einmal beantworten, ins Fundament einbauen und jede weitere Workload profitiert davon.
16:09
Hier ist das Beste, was Sie jetzt tun können.
16:11
Stellen Sie den Accelerator in einem Testtenant bereit und beobachten Sie die Vererbung der
16:14
Richtlinie.
16:14
Diese eine Stunde lehrt Sie mehr als jedes Diagramm, das Sie im Auskennen.
16:17
Abonnieren Sie für weitere Erklärungen in einfacher Sprache und hinterlassen Sie einen
16:20
Kommentar, falls Sie es klick gemacht haben.
16:21
Ich lese Sie den Anweser.