bewährte Methoden für Azure Enklave

In diesem Artikel werden die wichtigsten Konzepte und bewährten Methoden für Azure Enklave beschrieben.

Azure Enklave beschleunigt und optimiert die Bereitstellung und Verwaltung sicherer, isolierter und konformer Cloudumgebungen. Diese Umgebungen sind darauf ausgelegt, die vertraulichsten Missionen und Workloads in kommerziellen Umgebungen und in Umgebungen mit Air Gap zu verarbeiten.

Das Erfolgreiche Erstellen und Ausführen von Workloads in Azure Enclave erfordert Verständnis und Implementierung einiger wichtiger Konzepte, darunter:

Die Azure Enklave Produktgruppe, Engineering-Teams und Feldteams entwickelten die folgenden bewährten Methoden und konzeptionellen Artikel. Die Artikel wurden erstellt, um Community- und Enklavenbesitzern und Entwicklern zu helfen, wichtige Konzepte besser zu verstehen und die entsprechenden Features zu implementieren.

Azure-Einrichtung

Lesen Sie diese Setupschritte, um zu ermitteln, ob diese Konfigurationsschritte ihren Azure Enklaven-Anwendungsfällen entsprechen.

Konfigurieren von Network Watcher Ressourcengruppen

Um potenzielle Probleme mit der Erstellung des virtuellen Netzwerkflussprotokolls zu vermeiden, richten Sie die NetworkWatcherRG Ressourcengruppe manuell ein, und weisen Sie der Mission Enclave App die Owner Rolle für diese Ressourcengruppe zu, oder überprüfen Sie, ob die Einrichtung und Rollenzuweisung automatisch erfolgt ist, bevor Sie Ihre erste Enklave im Abonnement erstellen.

Um dieses potenzielle Problem abzumildern, erstellen Sie für jedes Abonnement manuell die NetworkWatcher-Ressourcengruppe mit dem Namen NetworkWatcherRG in neuen Abonnements und gewähren Sie dann der Mission Enclave Azure Enclave-App Owner für die NetworkWatcherRG:

  1. Wählen Sie die NetworkWatcherRG Ressourcengruppe aus, wählen Sie Access control (IAM) und dann Add und Add role assignment aus.

Screenshot, der die Rollenauswahl der Ressourcengruppe im Portal anzeigt.

  1. Wählen Sie Privileged administrator roles aus, wählen Sie owner aus, und wählen Sie dann Next aus.

Screenshot mit der Auswahlansicht für die Rolle „Besitzer hinzufügen“ im Portal.

  1. Wählen Sie Select members aus, geben Sie Mission Enclave in die Suche ein, und wählen Sie die App Mission Enclave aus, wählen Sie Select und dann Next.

Screenshot, der zeigt, wie die Mission Enklave-App im Portal ausgewählt wird.

  1. Falls für Ihr Abonnement eine Bedingung erforderlich ist, wählen Sie Allow user to assign all roles except privileged administrator roles Owner, UAA, RBAC (Recommended), und dann Review + assign.

Screenshot der Ansicht

  1. Sobald das Update abgeschlossen ist, können Sie mit der Bereitstellung Azure Enklave-Ressourcen beginnen.

Wenn eine Community oder Enklave erstellt wird, versucht Azure Enklave die folgenden Schritte:

  1. Überprüfen Sie, ob NetworkWatcherRG vorhanden ist. Wenn nicht, versuchen Sie, diese Ressourcengruppe zu erstellen.
  2. Überprüfen Sie, ob die Mission Enclave App eine dauerhafte Owner Zuweisung auf NetworkWatcherRG hat. Wenn nicht, versuchen Sie, die Mission Enclave App als dauerhafte Owner Zuweisung auf NetworkWatcherRG zuzuweisen. Auch wenn eine geerbte Owner Berechtigung vorhanden ist, wird versucht, eine dauerhafte Owner Zuweisung zu erstellen.
  3. Wenn ein Schritt fehlschlägt, können Enklavenbereitstellungen fehlschlagen, wenn Sie versuchen, virtuelle Netzwerkflussprotokolle zu erstellen.

Netzwerk- und Organisationsdesignmuster für Azure Enclave

Mehrinstanzenfähigkeit

Netzwerkdesign

Azure Enklave vereint die Funktionen und Flexibilität mehrerer Azure Netzwerkprodukte in einer vereinfachten Benutzeroberfläche, darunter:

  • Azure Virtual WAN
  • Azure Firewall
  • Virtuelles Azure-Netzwerk
  • Netzwerksicherheitsgruppen

Azure Enklave macht die folgenden allgemeinen Empfehlungen:

  • Communities sollten bereitgestellt werden, wenn Sie Netzwerkanforderungen haben, die den Einsatz einer Azure Firewall erfordern, einem intelligenten Firewall-Sicherheitsdienst (Platform-as-a-Service) von Azure.
  • Communities sollten bereitgestellt werden, wenn organisatorische oder datenschutzbezogene Anforderungen bestehen, um ein Hub-and-Spoke-Virtual-WAN von einem anderen Hub-and-Spoke-Virtual-WAN zu trennen.
  • Communitys sollten bereitgestellt werden, wenn Sie Netzwerkanforderungen haben, um Systeme zu unterstützen, die mehrere Azure Regionen umfassen, in denen jede Region eigene Azure Firewall erfordert. Erfahren Sie mehr über Multi-Hub-Azure Firewall Anwendungsfälle.
  • Communities sollten bereitgestellt werden, wenn Netzwerkanforderungen zur Unterstützung einer großen Anzahl von Systemen in einem verteilten Wide Area Network mit Hub-and-Spoke-Topologie bestehen. Erfahren Sie mehr über Azure Virtual WAN.
  • Enklaven sollten bereitgestellt werden, wenn Sie Netzwerkanforderungen haben, um ähnliche Workloads als Teil desselben privaten Netzwerks bereitzustellen.
  • Enklaven sollten bereitgestellt werden, wenn Sie über Workloadanforderungen verfügen, die ein virtuelles Netzwerk benötigen und sich innerhalb derselben Virtual WAN wie eine vorhandene Community befinden.

Überlegungen zum Entwurf von Communitynetzwerken

Sie sollten bei der Planung Ihrer Communitynetzwerke nach Möglichkeit die Best-Practices-Dokumentation für die zugrunde liegenden Azure-Dienste befolgen. Einschließen der folgenden bewährten Methoden:

Überlegungen zum Enklave-Netzwerkentwurf

Sie sollten bei der Planung Ihrer Enklavennetzwerke nach Möglichkeit die Best-Practices-Dokumentation der zugrunde liegenden Azure-Dienste befolgen. Einschließen der folgenden bewährten Methoden:

Erfahren Sie mehr über die allgemeinen Azure bewährten Methoden für Netzwerke.

Workloadbereitstellung

  • Workloads sind mit einer verwalteten Ressourcengruppe verknüpft, in der Enklavenmitwirkende Azure Ressourcen bereitstellen können.
  • Standardmäßig werden alle Azure Enklavenworkloads durch integrierte Azure Policy Initiativen gesteuert.
  • Workloads, die einer Community zugeordnet sind, die über ein benutzerdefiniertes Governance-Setup verfügt, verwenden diese eindeutige Konfiguration anstelle der standardmäßigen Azure Enklave Governance-Konfiguration.
  • Überlegungen zum Benennen Azure Ressourcen

Sicherheitsentwurfsmuster für Azure Enklave

Berücksichtigen Sie diese Sicherheitsdesignmuster beim Entwerfen Ihrer Azure Enklave-Umgebungen.

Sicherheitsgrenzen

Azure Enklave setzt einen umfassenden Verteidigungsansatz ein, wenn es um Cybersicherheit geht. Wenn Sie eine Community und Enklaven bereitstellen, stellt Azure Enklave mehrere Ebenen der Netzwerkisolation, Sicherheit, Zugriffskontrollen und Protokollierung und Überwachung her.

Gemeinsame Sicherheitsaufgaben

Als Dienst auf Azure setzt sich Azure Enklave auch dafür ein, das Modell der gemeinsamen Verantwortung in der Cloud aufrechtzuerhalten. Für Azure Enclave im Besonderen liegen Workloads in Ihrer Verantwortung. Das Azure-Modell der geteilten Verantwortung gilt auch für Workloads, wenn Sie darin PaaS-Dienste bereitstellen.

Ihre Gemeinschaften und Enklaven stellen eine gemeinsame Verantwortung dar. Communitys und Enklaven verwenden ein Modell für gemeinsame Verantwortung, bei dem der Azure Enklave Resource Provider Ihre gesicherte, vorkonfigurierte Hub-and-Spoke-Netzwerkumgebung erstellt. Sie verwalten diese Netzwerkumgebung, indem Sie Enklavenendpunkte, Communityendpunkte, Transithubs oder Enklavenverbindungen erstellen. Mit bestimmten Vorschauversionen von Azure Enclave können Sie auch manuell Änderungen am Netzwerk über zugrunde liegende Steuerelemente vornehmen, die von Azure Virtual WAN, Azure Virtual Network und anderen zugrunde liegenden Azure Netzwerkdiensten bereitgestellt werden.

Azure Enclave-Steuerung ist ebenfalls eine gemeinsame Verantwortung. Der Azure Enklave-Ressourcenanbieter erstellt eine gesicherte, vorkonfigurierte Liste der Azure Policy Initiativen pro Workloadbereitstellung. Communities können jetzt jedoch die Azure Policy-Initiativen der Community anpassen, wodurch die vorkonfigurierte Liste für den Workload außer Kraft gesetzt wird. Trotz der Richtlinienanforderungen behalten Sie die Möglichkeit, manuelle Ausnahmen für diese Azure Policy Initiative-Zuweisungen abhängig von ihren Compliance- oder Governanceanforderungen vorzunehmen.

bewährte Methoden für Azure Sicherheit

Azure Enclave empfiehlt, bei der Bereitstellung von Azure-Ressourcen und der Implementierung von Workloads die Sicherheitsbest Practices und -muster von Microsoft Azure zu befolgen.

Sie sollten die Azure bewährten Methoden für die Sicherheit befolgen – Cloud Adoption Framework für die Organisation Ihrer Systeme, Cloudinfrastruktur, IT-Mitarbeiter und Teamingstrukturen sowie Schulungen zur Sensibilisierung für die Cybersicherheit im Unternehmen.

Datenexfiltration über das Domain Name System

Datenexfiltration über Domain Name System (DNS) stellt eine erhebliche Sicherheitssorge für Organisationen dar, da es ein Protokoll verwendet, das in der Regel durch Firewalls zulässig ist und selten auf böswillige Aktivitäten überwacht wird. Angreifer können DNS-Abfragen nutzen, um vertrauliche Daten verdeckt aus kompromittierten Systemen zu extrahieren, indem Sie Informationen innerhalb von Domänennamen codieren oder DNS-Tunnelingtechniken verwenden. Diese Methode ist beängstigend, da DNS-Datenverkehr legitim erscheint und häufig herkömmliche Sicherheitsüberwachungstools umgangen wird.

Bei DNS-basierten Datenexfiltrationsangriffen codieren böswillige Akteure gestohlene Daten in DNS-Abfragen, häufig mit Techniken wie Subdomänenbezeichnungen oder TXT-Eintragsabfragen. Ein Angreifer kann z. B. vertrauliche Daten in Blöcke unterteilen und jeden Block als Unterdomäne in DNS-Abfragen in angreifergesteuerte Domänen einbetten. Die Daten können aus DNS-Protokollen auf dem DNS-Server des Angreifers extrahiert werden. Dieser Ansatz ermöglicht die graduelle Exfiltration großer Datasets bei gleichzeitiger Aufrechterhaltung eines niedrigen Profils, da die DNS-Abfragen als normale Namensauflösungsanforderungen angezeigt werden.

Adressieren von Datenexfiltration mit Azure DNS Sicherheitsrichtlinie

Azure DNS Sicherheitsrichtlinie bietet umfassenden Schutz vor DNS-basierten Datenexfiltrationsangriffen, indem sie eine präzise Kontrolle über DEN DNS-Datenverkehr innerhalb Azure virtual Networks bietet. Dieser Dienst ermöglicht Es Organisationen, proaktive Sicherheitsmaßnahmen zu implementieren, die verdächtige DNS-Aktivitäten erkennen, warnen und blockieren können, bevor Daten erfolgreich exfiltriert werden können.

Die Azure DNS-Sicherheitsrichtlinie wirkt DNS-Datenexfiltration durch mehrere zentrale Mechanismen entgegen. Erstens bietet es die Möglichkeit, DNS-Datenverkehrsregeln zu erstellen, die Abfragen an bekannte schädliche Domänen oder verdächtige Domänenmuster blockieren können, die häufig in Exfiltrationsversuchen verwendet werden. Organisationen können Blocklisten von Domänen verwalten, die mit Befehls- und Steuerungsinfrastruktur oder Datenexfiltrationsdiensten verknüpft sind. Zweitens bietet der Dienst umfassende DNS-Protokollierungsfunktionen, die alle DNS-Abfragen und -Antworten in geschützten virtuellen Netzwerken erfassen. Mit dieser Protokollierung können Sicherheitsteams DNS-Datenverkehrsmuster analysieren und potenzielle Exfiltrationsversuche identifizieren. Drittens unterstützt das Richtlinienmodul Platzhalterdomänenfilter, sodass Organisationen ganze Kategorien verdächtiger Domänen blockieren oder Zulassungslisten für genehmigte DNS-Ziele implementieren können.

Die Implementierung der Azure DNS-Sicherheitsrichtlinie erstellt mehrere Schutzebenen gegen DNS-Datenexfiltration. Datenverkehrsregeln können mit unterschiedlichen Prioritätsstufen konfiguriert werden, was komplexe Sicherheitsrichtlinien ermöglicht, die Sicherheit mit betrieblichen Anforderungen in Einklang bringen. Der Dienst unterstützt das Blockieren bösartiger Abfragen in Echtzeit und bietet detaillierte Protokolle für die forensische Analyse und Bedrohungssuche. Darüber hinaus stellen virtuelle Netzwerkverbindungen sicher, dass DNS-Sicherheitsrichtlinien konsistent auf alle Ressourcen innerhalb geschützter Netzwerksegmente angewendet werden, wodurch ein umfassender Sicherheitsperimeter entsteht, der für Angreifer schwierig zu umgehen ist.

Für Azure Bereitstellungen von Enklaven sollte Azure DNS Sicherheitsrichtlinie als Teil der allgemeinen Sicherheitsarchitektur integriert werden. Organisationen sollten DNS-Sicherheitsrichtlinien konfigurieren, um DNS-Datenverkehr von Enklavenworkloads zu überwachen und zu steuern, um sicherzustellen, dass vertrauliche Daten geschützt bleiben, auch wenn einzelne Workloads kompromittiert werden. Regelmäßige Überprüfung und Aktualisierung von DNS-Domänenlisten, kombiniert mit kontinuierlicher Überwachung von DNS-Protokollen, bietet kontinuierlichen Schutz vor sich entwickelnden DNS-basierten Bedrohungen und trägt zur Aufrechterhaltung der Sicherheitsintegrität der Azure Enklave-Umgebung bei.

Weitere Informationen finden Sie in der DOKUMENTATION zur DNS-Sicherheitsrichtlinie.

Implementierung von DNS-Sicherheitsrichtlinien nach dem Prinzip „standardmäßig verweigern“

Für maximale Sicherheit in Azure Enklave-Umgebungen sollten Organisationen einen Ansatz "Standardmäßig verweigern, ausnahmeweise zulassen" für die DNS-Filterung implementieren. Dieses Sicherheitsmodell stellt sicher, dass alle DNS-Abfragen blockiert werden, es sei denn, dies ist explizit zulässig, und bietet den stärksten Schutz vor DNS-basierter Datenexfiltration und Befehls- und Steuerungskommunikation.

Der Deny-by-Default-Ansatz wird mithilfe einer zweistufigen DNS-Regelstruktur innerhalb der Azure DNS Security Policy implementiert:

Schritt 1: Erstellen der Standardverweigerungsregel Erstellen Sie eine DNS-Domänenliste, die nur die Stammdomäne . (Dot) enthält. Diese Wildcarddomäne stimmt mit allen möglichen DNS-Abfragen überein. Ordnen Sie diese Domänenliste einer DNS-Datenverkehrsregel zu, die konfiguriert ist:

  • Priorität: 65000 (niedrigste Priorität)
  • Aktion: Blockieren
  • Domänenliste: Stammdomäne (.)

Diese Regel dient als Catch-All-Element, das alle DNS-Abfragen blockiert, die nicht explizit durch Regeln mit höherer Priorität zulässig sind.

Schritt 2: Erstellen von Zulassungslistenregeln Erstellen Sie separate DNS-Domänenlisten, die bestimmte Domänen enthalten, die für legitime Geschäftsvorgänge erforderlich sind. Dazu kann Folgendes gehören:

  • Wesentliche Azure-Dienste (z. B. *.azure.com, *.microsoft.com)
  • Unternehmensdomänen und vertrauenswürdige Nicht-Microsoft-Dienste
  • Betriebssystemupdatedienste
  • Domänen der Zertifizierungsstelle

Ordnen Sie die Zulassungslisten den DNS-Datenverkehrsregeln zu, die konfiguriert sind mit:

  • Priorität: 500-1000 (höhere Priorität als die Standardverweigerung)
  • Aktion: Zulassen
  • Domänenlisten: Bestimmte genehmigte Domänen

Prioritätsbasierte Regelverarbeitung Die Azure DNS-Sicherheitsrichtlinie verarbeitet Regeln in der Reihenfolge ihrer Priorität (niedrigere Zahlen = höhere Priorität). Wenn eine DNS-Abfrage durchgeführt wird:

  1. Das System bewertet zuerst Zulassungsregeln mit hoher Priorität (Priorität 500-1000)
  2. Wenn die Domäne mit einer Zulassungsliste übereinstimmt, ist die Abfrage zulässig.
  3. Wenn keine allow Regeln übereinstimmen, fällt die Abfrage in die Standardverweigerungsregel (Priorität 65000) und der Datenverkehr wird blockiert.

Dieser Ansatz bietet mehrere Sicherheitsvorteile:

  • Zero-Trust-Modell: Es sind keine DNS-Abfragen zulässig, sofern sie nicht ausdrücklich autorisiert sind.
  • Granulare Kontrolle: Organisationen können genau steuern, auf welche Domänen zugegriffen werden kann
  • Überwachungspfad: Alle blockierten Abfragen werden protokolliert und bieten Einblicke in potenzielle Bedrohungen.
  • Inkrementelle Updates: Neue genehmigte Domänen können zu Zulassungslisten hinzugefügt werden, ohne die Standardregel deny zu ändern.

Beispielimplementierung:

Priority 500: Allow rule for Azure services
- Domain List: azure-services (contains azure.com., microsoft.com.)
- Action: Allow

Priority 600: Allow rule for business applications
- Domain List: business-domains (contains company.com., partner1.com., partner2.com.)
- Action: Allow

Priority 65000: Default deny rule
- Domain List: deny-all (contains .)
- Action: Block

Organisationen, die diesen Ansatz implementieren, sollten mit einem umfassenden Inventar der erforderlichen Domänen beginnen und die Liste der zulässigen Domänen basierend auf betrieblichen Anforderungen und Sicherheitsprotokollen schrittweise verfeinern. Die regelmäßige Überprüfung blockierter Abfragen hilft dabei, legitime Domänen zu identifizieren, die möglicherweise den Zulassungslisten hinzugefügt werden müssen, während ein starker Sicherheitsstatus beibehalten wird.

Implementierung von Deny-by-default-DNS-Richtlinien mit Windows DNS-Server

Für Umgebungen, die die Azure DNS-Sicherheitsrichtlinie nicht nutzen können oder eine lokale DNS-Steuerung erfordern, kann eine ähnliche Sicherheit nach dem Prinzip „standardmäßig verweigern“ mithilfe des Windows DNS-Servers mit DNS-Richtlinienfunktionen implementiert werden. Dieser Ansatz bietet einen vergleichbaren Schutz vor DNS-basierter Datenexfiltration und gleichzeitiger Beibehaltung der Kompatibilität mit bestehender Windows-Infrastruktur.

Windows DNS-Server (Windows Server 2016 und höher) unterstützt DNS-Richtlinienfunktionen, mit denen Organisationen anspruchsvolle DNS-Filterregeln implementieren können. Das Deny-by-Default-Modell kann durch eine Kombination aus DNS-Richtlinienregeln und Zonenkonfigurationen erreicht werden.

Verwaltete Ressourcengruppen in Azure Enklave

Die Ressourcengruppen, die ressourcen enthalten, die von Azure Enklave verwaltet werden.

Von der Community verwaltete Ressourcengruppe

Die Von der Community verwaltete Ressourcengruppe enthält die Infrastrukturressourcen, die unter "Was ist eine Community" beschrieben sind.

Der Name der von der Community verwalteten Ressourcengruppe folgt dieser Benennungskonvention: myCommunityName-HostedResources-<GUID>. Jede Community-Bereitstellung erstellt diese Ressourcengruppe und stellt die Community-Infrastruktur darin bereit. Wenn Sie Ihre Community löschen, löscht der Azure Enklave-Ressourcenanbieter automatisch die von der Community verwaltete Ressourcengruppe.

Screenshot eines Beispiels für die von Azure Enklave verwalteten Communityressourcen.

Die von der Community verwaltete Ressourcengruppe hat die folgenden Einschränkungen:

  • Sie können keine vorhandene Ressourcengruppe für die von der Community verwaltete Ressourcengruppe angeben.
  • Sie können kein anderes Abonnement für die von der Community verwaltete Ressourcengruppe angeben.
  • Sie können den Namen der von der Community verwalteten Ressourcengruppe nicht ändern, nachdem die Community erstellt wurde.
  • Sie können keine Namen für die verwalteten Ressourcen innerhalb der von der Community verwalteten Ressourcengruppe angeben.
  • Sie können die von Azure erstellten Tags verwalteter Ressourcen innerhalb der von der Community verwalteten Ressourcengruppe nicht ändern oder löschen.

Wenn Sie von Azure erstellte Tags, Ressourcen und andere Ressourceneigenschaften in der von der Community verwalteten Ressourcengruppe ändern oder löschen, kann es zu unerwarteten Ergebnissen kommen. Da Azure Enclave den Lebenszyklus der Infrastruktur in der von der Community verwalteten Ressourcengruppe verwaltet, könnten alle Änderungen Ihre Enklave potenziell in einen nicht unterstützten Zustand verschieben.

Ein gängiges Szenario, in dem Sie Ressourcen ändern möchten, besteht aus Tags. Azure Enclave ermöglicht Ihnen, Tags zu erstellen und zu ändern, die an Ressourcen in der von der Community verwalteten Ressourcengruppe übertragen werden. Sie können benutzerdefinierte Tags erstellen oder ändern, um beispielsweise eine Geschäftseinheit oder eine Kostenstelle zuzuweisen. Dies kann auch erreicht werden, indem Azure-Richtlinien mit einem Geltungsbereich für die von der Community verwaltete Ressourcengruppe erstellt werden.

Note

Wenn die Sperre für die von der Community verwaltete Ressourcengruppe nicht aktiviert ist, können Sie jede Ressource in der von der Community verwalteten Ressourcengruppe direkt bearbeiten. Das direkte Ändern von Ressourcen in der von der Community verwalteten Ressourcengruppe kann dazu führen, dass Ihre Enklave instabil oder nicht reagiert.

Verwaltete Ressourcengruppe für Enklaven

Die von Enclave verwaltete Ressourcengruppe enthält die Infrastrukturressourcen, die in Was ist eine Enklave? beschrieben werden.

Der Name der von der Enklave verwalteten Ressourcengruppe folgt dieser Benennungskonvention: myEnclaveName-HostedResources-<GUID>. Jede Enklavenbereitstellung erstellt diese Ressourcengruppe und platziert die Enklaveninfrastruktur darin. Wenn Sie Ihre Enklave löschen, löscht der Azure Enklave-Ressourcenanbieter automatisch die verwaltete Enklave-Ressourcengruppe.

Screenshot eines Beispiels für die Enklavenressourcen, die von Azure Enklave verwaltet werden.

Die verwaltete Ressourcengruppe der Enklave hat die folgenden Einschränkungen:

  • Sie können keine vorhandene Ressourcengruppe für die verwaltete Ressourcengruppe der Enklave angeben.
  • Sie können kein anderes Abonnement für die verwaltete Ressourcengruppe der Enklave angeben.
  • Sie können den Namen der verwalteten Ressourcengruppe nicht ändern, nachdem die Enklave erstellt wurde.
  • Sie können keine Namen für die verwalteten Ressourcen innerhalb der verwalteten Ressourcengruppe der Enklave angeben.
  • Sie können von Azure erstellte Tags verwalteter Ressourcen innerhalb der verwalteten Ressourcengruppe der Enklave nicht ändern oder löschen.

Wenn Sie von Azure erstellte Tags, Ressourcen und andere Ressourceneigenschaften in der vom Enclave verwalteten Ressourcengruppe ändern oder löschen, kann dies zu unerwarteten Ergebnissen führen, etwa zu Netzwerk-, Zugriffs- und Überwachungsfehlern. Da Azure Enclave den Lebenszyklus der Infrastruktur in der verwalteten Ressourcengruppe der Enklave verwaltet, könnten alle Änderungen Ihre Enklave potenziell in einen nicht unterstützten Zustand verschieben.

Ein gängiges Szenario, in dem Sie Ressourcen ändern möchten, besteht aus Tags. Azure Enklave ermöglicht ihnen das Erstellen und Ändern von Tags, die an Ressourcen in der verwalteten Ressourcengruppe der Enklave weitergegeben werden. Sie können benutzerdefinierte Tags erstellen oder ändern, um beispielsweise eine Geschäftseinheit oder eine Kostenstelle zuzuweisen. Die Ressourcenmarkierung kann auch durch das Erstellen von Azure-Richtlinien mit einem auf die verwaltete Ressourcengruppe der Enklave festgelegten Geltungsbereich erfolgen.

Warning

Das Ändern von Ressourcen in der verwalteten Ressourcengruppe der Enklave kann dazu führen, dass Ihre Enklave instabil oder nicht reagiert.

Workload-Ressourcengruppe

Die Arbeitsauslastung ist mit einer oder mehreren Ressourcengruppen verknüpft, in denen Sie Ihre Azure Ressourcen erstellen und organisieren können.

Hinzufügen einer Ressourcengruppe zu einer Workload

Das Hinzufügen einer neuen Ressourcengruppe erfordert normalerweise, dass der Benutzer über Berechtigungen zum Erstellen einer neuen Ressourcengruppe verfügt. Die Rollen Owner oder Contributor auf Abonnementebene verfügen über diese Berechtigung, aber die Person, die die Workload-Ressourcengruppe erstellt, verfügt möglicherweise nicht über diese erhöhte Berechtigung oder benötigt sie nicht. Azure Enklave versucht drei Möglichkeiten, die neue Ressourcengruppe zu erstellen, die von den höchsten bis zu den niedrigsten Benutzerberechtigungsanforderungen reicht und flexibilität für den Benutzer bietet:

  • Option 1: Erfordert für die Person, die die Workload erstellt oder aktualisiert, die weitreichendsten Berechtigungen und bietet vollständige Kontrolle, setzt jedoch erhöhte Zugriffsrechte voraus.
  • Option 2: Umfasst die manuelle Einrichtung durch den Benutzer, um unseren Mission Enclave Anwendungsbesitz auf Abonnementebene zu gewähren, was möglicherweise nicht ihren Präferenzen entspricht.
  • Option 3: Erfordert keine Berechtigungen für den Benutzer oder die Mission Enclave Anwendung, wodurch sie die einfachste Methode ist, sondern eine strenge 1:1-Beziehung zwischen der Ressourcengruppe und der Arbeitsauslastung auferlegt wird.

Jede Option verfügt über Vorteile und Einschränkungen, Ausgleichssteuerung, Komfort und Flexibilität, um unterschiedlichen Anforderungen gerecht zu werden. Diese Optionen werden ab Option 1 ausgewertet, und die erste zu erfolgreiche Option wird verwendet, um die neue Ressourcengruppe zu erstellen.

Nachdem Sie eine Arbeitsauslastungsressourcengruppe mithilfe von Option 3 erstellt haben, wird eine Warnung angezeigt, dass Option 3 für die nächsten Workload-Ressourcengruppen für diese Workload nicht verwendet werden kann. Sie können auch eine neue Workload erstellen und dann eine neue Workload-Ressourcengruppe erstellen, indem Sie Option 3 erneut verwenden.

Fügen Sie Ihrer Enklave eine Ressourcengruppe hinzu:

  1. Öffnen Sie die Azure Portalseite für die Workload.
  2. Wählen Sie Manage und dann Resource Groups aus.
  3. Wähle Add a resource group aus.
  4. Wählen Sie im daraufhin geöffneten Seitenfenster den Create new Namen der neuen leeren Ressourcengruppe aus, oder wählen Sie die Resource Group Dropdownliste aus, um eine vorhandene Ressourcengruppe auszuwählen.
  5. Wählen Sie OK und dann Save aus.

Wie unterscheidet sich eine Workloadressourcengruppe von anderen Azure Ressourcengruppen?

Eine Workload-Ressourcengruppe ist ein entscheidender Bestandteil der Sicherheit und Compliance von Azure Enclave, denn dort werden Ihre wichtigen Ressourcen erstellt. Da diese Workload-Ressourcengruppen mit einer Workload verknüpft sind und die Workload mit einer Enklave verknüpft ist, verwaltet Azure Enklave das Löschen verwalteter Workload-Ressourcengruppen.

Darüber hinaus wird die Richtlinie auf die Workload-Ressourcengruppen angewendet. Ähnlich wie die Richtlinien der Gemeinschaft bis zur Enklave fließen, fließen die Enklavenrichtlinien nach unten zu den Arbeitsauslastungsressourcen und Arbeitsauslastungsressourcengruppen. Wenn Sie eine neue Workload-Ressourcengruppe erstellen, werden die Rollen auf Enklaveebene festgelegt und vom Abonnement geerbt. Einige dieser Richtlinien stammen aus der Community, und Sie können auch auf der Enklave Richtlinien erstellen, die an Workloads und Workload-Ressourcengruppen weitergegeben werden.

Ressourcen in Workload-Ressourcengruppen organisieren

Wenn Sie Ihre Ressourcen in zwei Ressourcengruppen aufteilen möchten, können Sie eine der folgenden Optionen auswählen:

  • Aufteilen dieser Ressourcen zwischen zwei Ressourcengruppen, die mit einer Workload verknüpft sind
  • Teilen sie diese Ressourcen zwischen zwei Arbeitslasten auf, die jeweils über eine oder mehrere Ressourcengruppen verfügen

Löschen der Workload

Wenn eine Workloadlöschung angefordert wird, werden die Workloadressourcengruppen überprüft, um sicherzustellen, dass sie leer sind. Wenn Workload-Ressourcengruppen Ressourcen enthalten, schlägt das angeforderte Löschen der Workload fehl, und es wird eine Fehlermeldung angezeigt. Um die Workload und die Workload-Ressourcengruppen zu löschen, leeren Sie zuerst die Workload-Ressourcengruppen. Leere Workload-Ressourcengruppen vermeiden versehentliches Löschen wichtiger Ressourcen.

Das Löschen einer Ressource, die mit der Workload verknüpft ist, folgt demselben Verhalten. Wenn beispielsweise das Löschen einer Community angefordert wird, aber nicht alle Workload-Ressourcengruppen leer sind, wird bei dem Vorgang ein Fehler angezeigt. Leeren Sie die Workload-Ressourcengruppen und versuchen Sie es erneut.

Die Vom Workload verwaltete Ressourcengruppe weist die folgenden Einschränkungen auf:

  • Sie können keine vorhandene Ressourcengruppe für die vom Workload verwaltete Ressourcengruppe angeben.
  • Sie können kein anderes Abonnement für die Vom Workload verwaltete Ressourcengruppe angeben.
  • Sie können den Namen der vom Workload verwalteten Ressourcengruppe nicht ändern, nachdem die Workload erstellt wurde.
  • Sie können die von Azure erstellten Tags von verwalteten Ressourcen innerhalb der vom Workload verwalteten Ressourcengruppe nicht ändern oder löschen.

Ein gängiges Szenario, in dem Sie Ressourcen ändern möchten, besteht aus Tags. Azure Enklave ermöglicht ihnen das Erstellen und Ändern von Tags, die an Ressourcen in der vom Workload verwalteten Ressourcengruppe weitergegeben werden. Sie können benutzerdefinierte Tags erstellen oder ändern, um beispielsweise eine Geschäftseinheit oder eine Kostenstelle zuzuweisen. Die Kennzeichnung kann auch durch das Erstellen von Azure-Richtlinien mit Geltungsbereich für die vom Workload verwaltete Ressourcengruppe umgesetzt werden.

Weitere Azure bewährte Methoden

Wenn Sie Ihre Communitys, Enklaven und Workloads in Azure erstellen, ist es wichtig, die folgenden universellen Designprinzipien zu berücksichtigen:

  • Last updated on