Häufig gestellte Fragen zur Azure-Zielzone (HÄUFIG gestellte Fragen)

Dieser Artikel beantwortet häufig gestellte Fragen zur Azure-Zielzonenarchitektur.

Häufig gestellte Fragen zur Implementieren der Azure Landing Zone-Architektur finden Sie in den Häufig gestellte Fragen zur Implementierung auf Unternehmensebene.

Was ist der Azure-Zielzonenbeschleuniger?

Der Azure-Zielzonenbeschleuniger ist eine Bereitstellungsumgebung, die auf dem Azure-Portal basiert. Es stellt eine dogmatische Implementierung basierend auf der konzeptionellen Architektur der Azure-Zielzone bereit.

Welche Accelerators und Implementierungen werden für Azure-Zielzonen empfohlen?

Accelerators und Implementierungen für Plattformen und Anwendungen werden von Microsoft aktiv und im Einklang mit den Entwurfsprinzipien für Azure-Zielzonen und dem Leitfaden für den Entwurfsbereich entwickelt und verwaltet.

Weitere Informationen zu den empfohlenen Plattform- und Anwendungszielzonen finden Sie im Leitfaden Bereitstellen von Azure-Zielzonen.

Informationen zum Anpassen der Azure-Zielzonenbereitstellung an Ihre Anforderungen finden Sie unter Anpassen der Architektur der Azure-Zielzonen an die Anforderungen.

Was ist die konzeptionelle Architektur der Azure-Zielzone?

Die konzeptionelle Architektur der Azure-Zielzone stellt Skalierungs- und Entwicklungsentscheidungen dar. Sie basiert auf den gesammelten Erfahrungen und dem Feedback von Kunden, die Azure als Teil ihres digitalen Bestands eingeführt haben. Diese konzeptionelle Architektur kann Ihrer Organisation helfen, die Richtung für Entwurf und Implementierung einer Zielzone festzulegen.

Was wird einer Landing Zone in Azure im Kontext der Azure Landing Zone-Architektur zugeordnet?

Aus Sicht der Azure-Zielzone sind Zielzonen einzelne Azure-Abonnements.

Was bedeutet richtliniengesteuerte Governance und wie funktioniert sie?

Die richtliniengesteuerte Governance ist eines der wesentlichen Entwurfsprinzipien einer Unternehmensarchitektur.

Richtliniengesteuerte Governance heißt, dass Azure Policy verwendet wird, um den Zeitaufwand zu verringern, den Sie für allgemeine und wiederholte operative Aufgaben in Ihrem Azure-Mandanten benötigen. Durch Verwendung vieler Azure Policy-Auswirkungen, z. B. Append, Deny, DeployIfNotExists und Modify, können Sie Nichtkonformität vermeiden, indem Sie die Erstellung oder Aktualisierung nicht konformer Ressourcen (gemäß Richtliniendefinition) einschränken oder Ressourcen so bereitstellen bzw. die Einstellungen einer Erstellungs- oder Aktualisierungsanforderung für eine Ressource so ändern, dass die Ressource richtlinienkonform ist. Von einigen Auswirkungen wie Audit, Disabled und AuditIfNotExists werden keine Aktionen verhindert oder durchgeführt. Sie überwachen und melden lediglich Nichtkonformitäten.

Einige Beispiele für richtliniengesteuerte Governance sind:

• Deny-Auswirkung: Verhindert die Erstellung und Aktualisierung von Subnetzen, ohne dass ihnen Netzwerksicherheitsgruppen zugeordnet sind.

• DeployIfNotExists-Auswirkung: Ein neues Abonnement (Zielzone) wird erstellt und in einer Verwaltungsgruppe innerhalb Ihrer Azure-Zielzonenbereitstellung platziert. Azure Policy stellt sicher, dass Microsoft Defender für Cloud (früher als Azure Security Center bezeichnet) für das Abonnement aktiviert ist. Außerdem werden die Diagnoseeinstellungen für das Aktivitätsprotokoll so konfiguriert, dass Protokolle an den Log Analytics-Arbeitsbereich im Verwaltungsabonnement gesendet werden.

  Anstelle von Codewiederholungen oder manuellen Aktivitäten beim Erstellen eines neues Abonnements sorgt die DeployIfNotExists-Richtliniendefinition dafür, dass sie automatisch bereitgestellt und konfiguriert werden.

Was geschieht, wenn wir DeployIfNotExists-Richtlinien (DINE) nicht verwenden können oder noch nicht dazu bereit sind?

Auf einer speziellen Seite werden die verschiedenen Phasen und Optionen erläutert, die Ihnen zur Verfügung stehen, um DINE-Richtlinien entweder zu „deaktivieren“ oder sie mithilfe unseres dreistufigen Ansatzes nach und nach in Ihrer Umgebung einzuführen.

Anleitungen dazu finden Sie unter Einführung von richtliniengesteuerten Schutzmaßnahmen.

Sollten wir Azure Policy für die Bereitstellung von Workloads verwenden?

Kurz gesagt: Nein. Verwenden Sie Azure Policy, um Ihre Workloads und Zielzonen zu steuern, zu verwalten und konform zu halten. Azure Policy ist nicht für die Bereitstellung ganzer Workloads und anderer Tools konzipiert. Verwenden Sie das Azure-Portal oder Infrastructure-as-Code-Angebote (ARM-Vorlagen, Bicep, Terraform), um Ihre Workload bereitzustellen sowie zu verwalten und die benötigte Eigenständigkeit zu erhalten.

Was ist Cloud Adoption Framework Zielzonen für Terraform (aztfmod)?

Das Open-Source-Projekt (OSS) für Cloud Adoption Framework-Zielzonen (auch aztfmod genannt) ist ein communitybasiertes Projekt, das außerhalb des Kernteams für Azure-Zielzonen und außerhalb der Azure GitHub-Organisation verwaltet wird. Wenn Sich Ihre Organisation für die Verwendung dieses OSS-Projekts entscheidet, sollten Sie den verfügbaren Support berücksichtigen, da dies auf die Bemühungen der Community über GitHub basiert.

Was geschieht, wenn bereits Ressourcen in unseren Zielzonen vorhanden sind und später eine Azure Policy-Definition zugewiesen wird, die sie in ihren Bereich einschließt?

Lesen Sie die folgenden Abschnitte der Dokumentation:

• Durchführen des Wechsels von vorhandenen Azure-Umgebungen zur konzeptionellen Architektur der Azure-Zielzone
• Schnellstart: Erstellen einer Richtlinienzuweisung zum Identifizieren von nicht konformen Ressourcen mit einer Bicep-Datei – Abschnitt „Identifizieren nicht konformer Ressourcen“

Wie gehen wir mit „dev/test/production“-Workload-Zielzonen in der Azure-Zielzonenarchitektur um?

Weitere Informationen finden Sie unter Verwalten von Anwendungsentwicklungsumgebungen in Azure-Zielzonen.

Warum werden wir aufgefordert, bei der Bereitstellung des Azure-Zielzonenbeschleunigers Azure-Regionen anzugeben, und wofür werden sie verwendet?

Wenn Sie die Architektur der Azure-Landing Zone mithilfe der auf dem Azure-Landing Zone Accelerator-Portal basierenden Erfahrung bereitstellen, wählen Sie eine Azure-Region für die Bereitstellung aus. Die erste Registerkarte, Bereitstellungsspeicherort, bestimmt, wo die Bereitstellungsdaten gespeichert werden. Weitere Informationen finden Sie im Artikel zur Bereitstellung von Mandanten mit ARM-Vorlagen. Einige Teile einer Zielzone werden global bereitgestellt, aber ihre Bereitstellungsmetadaten werden in einem regionalen Metadatenspeicher nachverfolgt. Sie Metadaten für die Bereitstellung werden in der Region gespeichert, die auf der Registerkarte Bereitstellungsspeicherort ausgewählt wurde.

Die Regionsauswahl auf der Registerkarte Bereitstellungsstandort wird auch verwendet, um auszuwählen, in welcher Azure-Region regionsspezifische Ressourcen gespeichert werden sollen, z. B. ein Log Analytics-Arbeitsbereich und ein Automatisierungskonto, falls erforderlich.

Wenn Sie eine Netzwerktopologie auf der Registerkarte Netzwerktopologie und -konnektivität angeben, müssen Sie eine Azure-Region auswählen, in der die Netzwerkressourcen bereitgestellt werden sollen. Diese Region kann sich von der auf der Registerkarte Bereitstellungsstandort ausgewählten Region unterscheiden.

Weitere Informationen zu den Regionen, die von Zielzonenressourcen verwendet werden, finden Sie unter Zielzonenregionen.

Wie aktivieren wir mehr Azure-Regionen, wenn wir die Azure-Zielzonenarchitektur verwenden?

Um zu verstehen, wie Sie einer Zielzone eine neue Region hinzufügen können, oder wie Sie Zielzonenressourcen in eine andere Region verschieben, lesen Sie Zielzonenregionen.

Sollten wir jedes Mal ein neues Azure-Abonnement erstellen, oder sollten wir Azure-Abonnements wiederverwenden?

Was ist die Wiederverwendung von Abonnements?

Unter Wiederverwendung von Abonnements versteht man die Neuausstellung eines bestehenden Abonnements für einen neuen Besitzer. Es sollte ein Verfahren geben, mit dem das Abonnement auf einen bekanntermaßen sauberen Zustand zurückgesetzt und dann einem neuen Besitzer zugewiesen wird.

Warum sollte ich Abonnements wiederverwenden?

Im Allgemeinen wird empfohlen, dass Kunden das Entwurfsprinzip für die Demokratisierung von Abonnements übernehmen. Es gibt jedoch bestimmte Umstände, in denen die Wiederverwendung von Abonnements nicht möglich ist oder empfohlen wird.

Sie sollten die Wiederverwendung von Abonnements in Betracht ziehen, wenn einer der folgenden Umstände zutrifft:

• Sie verfügen über ein Enterprise Agreement (EA) und planen, mehr als 5.000 Abonnements für ein einzelnes Konto eines EA-Kontobesitzers (Abrechnungskonto) zu erstellen, einschließlich gelöschter Abonnements.
• Sie verfügen über eine Microsoft-Kundenvereinbarung (MCA) oder eine Microsoft Partner-Vereinbarung (MPA) und planen mehr als 5.000 aktive Abonnements. Weitere Informationen zu Grenzwerten für Abonnements finden Sie unter Abrechnungskonten und -bereichen im Azure-Portal.
• Sie sind Kunde mit nutzungsbasierter Bezahlung.
• Sie verwenden eine Microsoft Azure Sponsorship-Instanz.
• Sie erstellen in der Regel Folgendes:
  1. Kurzlebige Lab- oder Sandboxumgebungen
  2. Demoumgebungen für POCs (Proofs-of-Concept) oder Minimum Viable Products (MVP), einschließlich unabhängiger Softwareanbieter (Independent Software Vendors, ISVs) für Demo-/Testzugriff für Kunden
  3. Trainingsumgebungen, z. B. Lernumgebungen für MSPs/Kursleiter

Wie kann ich Abonnements wiederverwenden?

Wenn eins der oben genannten Szenarien oder eine der oben genannten Überlegungen auf Sie zutrifft, sollten Sie die Wiederverwendung vorhandener außer Betrieb genommener oder ungenutzter Abonnements in Betracht ziehen und diese einem neuen Besitzer und Zweck zuweisen.

Bereinigen des alten Abonnements

Sie müssen zunächst das alte Abonnement zur Wiederverwendung bereinigen. Sie müssen die folgenden Aktionen für ein Abonnement ausführen, bevor es wiederverwendet werden kann:

• Entfernen von Ressourcengruppen und enthaltenen Ressourcen
• Entfernen von Rollenzuweisungen, einschließlich Privileged Identity Management-Rollenzuweisungen (PIM), im Abonnementbereich
• Entfernen von benutzerdefinierten RBAC-Definitionen (Role-Based Access Control, rollenbasierte Zugriffssteuerung) im Abonnementbereich
• Entfernen von Richtliniendefinitionen, Initiativen, Zuweisungen und Ausnahmen im Abonnementbereich.
• Entfernen von Bereitstellungen im Abonnementbereich
• Entfernen von Tags im Abonnementbereich
• Entfernen von Ressourcensperren im Abonnementbereich
• Entfernen Sie alle Microsoft Cost Management-Budgets im Abonnementbereich.
• Zurücksetzen von Microsoft Defender for Cloud-Plänen auf Free-Tarife, es sei denn, diese Protokolle müssen gemäß Organisationsanforderungen auf die kostenpflichtigen Tarife festgelegt sein. Sie erzwingen diese Anforderungen normalerweise über Azure Policy.
• Entfernen der Weiterleitung von Abonnementaktivitätsprotokollen (Diagnoseeinstellungen) an Log Analytics-Arbeitsbereiche, Event Hubs, Speicherkonten oder andere unterstützte Ziele, es sei denn, diese Protokolle müssen gemäß Organisationsanforderungen weitergeleitet werden, während ein Abonnement aktiv ist
• Entfernen von Azure Lighthouse-Delegierungen im Abonnementbereich
• Entfernen von ausgeblendeten Ressourcen aus dem Abonnement

Erneutes Zuweisen des Abonnements

Sie können das Abonnement neu zuweisen, nachdem Sie es bereinigt haben. Im Anschluss finden Sie einige allgemeine Aktivitäten, die Sie im Rahmen des Neuzuweisungsprozesses ausführen sollten:

• Hinzufügen neuer Tags und Festlegen von Werten für diese im Abonnement
• Hinzufügen neuer Rollenzuweisungen oder Privileged Identity Management-Rollenzuweisungen (PIM), im Abonnementbereich für die neuen Besitzer. In der Regel werden diese Zuweisungen für Microsoft Entra-Gruppen anstelle von Einzelpersonen verwendet.
• Platzieren des Abonnements in der gewünschten Verwaltungsgruppe basierend auf den Governanceanforderungen
• Erstellen Sie neue Microsoft Cost Management-Budgets und legen Sie Warnungen für neue Besitzer fest, wenn Schwellenwerte erreicht werden.
• Festlegen von Microsoft Defender for Cloud-Plänen auf die gewünschten Tarife. Sie müssen diese Einstellung über Azure Policy erzwingen, sobald die Platzierung in der richtigen Verwaltungsgruppe erfolgt ist.
• Konfigurieren der Weiterleitung von Abonnementaktivitätsprotokollen (Diagnoseeinstellungen) an Log Analytics-Arbeitsbereiche, Event Hubs, Speicherkonten oder andere unterstützte Ziele. Sie müssen diese Einstellung über Azure Policy erzwingen, sobald die Platzierung in der richtigen Verwaltungsgruppe erfolgt ist.

Was ist eine souveräne Zielzone und wie hängt sie mit der Azure-Zielzonenarchitektur zusammen?

Die souveräne Zielzone ist eine Komponente der Microsoft Cloud für Souveränität, die für Kunden des öffentlichen Sektors vorgesehen ist, die erweiterte Souveränitätskontrollen benötigen. Als maßgeschneiderte Version der konzeptionellen Architektur der Azure-Zielzone vereint die souveräne Zielzone Azure-Funktionen wie Dienstresidenz, kundenseitig verwaltete Schlüssel, Azure Private Link und vertrauliches Computing. Durch diese Ausrichtung erstellt die souveräne Zielzone eine Cloudarchitektur, in der Daten und Workloads standardmäßig Verschlüsselung und Schutz vor Bedrohungen bieten.

Weitere Informationen zur souveränen Zielzone finden Sie in den Überlegungen zur Souveränität für Azure-Zielzonen.