Freigeben über

Bewährte Methoden für alle Isolationsarchitekturen

  • Artikel

Im Folgenden werden Entwurfsüberlegungen zu allen Isolationskonfigurationen dargelegt. Der Text enthält zahlreiche Links. Über diese Links haben Sie stets Zugriff auf die neuesten Informationen, ohne dass wir die relevanten Inhalte hier duplizieren müssen.

Allgemeine Anleitungen zum Konfigurieren von Microsoft Entra-Mandanten (isoliert oder nicht) finden Sie im Microsoft Entra-Featurebereitstellungshandbuch.

Hinweis

Für alle isolierten Mandanten wird empfohlen, klare und differenzierte Brandings zu verwenden, um zu vermeiden, um menschliche Fehler zu vermeiden, die zur Folge haben, dass im falschen Mandanten gearbeitet wird.

Prinzipien der Isolationssicherheit

Beim Entwerfen isolierter Umgebungen ist es wichtig, die folgenden Prinzipien zu berücksichtigen:

  • Verwendung moderner Authentifizierung – Anwendungen, die in isolierten Umgebungen bereitgestellt werden, müssen anspruchsbasierte moderne Authentifizierung (z. B. SAML, * Auth, OAuth2 und OpenID Connect) verwenden, um Funktionen wie Verbund, Microsoft Entra B2B Collaboration, Delegierung und das Zustimmungsframework zu verwenden. Auf diese Weise werden ältere Anwendungen, die von Legacy-Authentifizierungsmethoden wie NT LAN Manager (NTLM) abhängig sind, nicht in isolierte Umgebungen übernommen.

  • Erzwingung strenger Authentifizierung – Beim Zugriff auf die Dienste und die Infrastruktur der isolierten Umgebung muss immer strenge Authentifizierung verwendet werden. Wenn möglich, sollte kennwortlose Authentifizierung wie Windows Hello for Business oder ein FIDO2-Sicherheitsschlüssel verwendet werden.

  • Bereitstellung sicherer Arbeitsstationen - Sichere Arbeitsstationen bieten den erforderlichen Mechanismus, um sicherzustellen, dass die Plattform und die von ihr dargestellte Identität ordnungsgemäß bestätigt und gegen die Ausbeutung gesichert wird. Dabei sind zwei weitere Ansätze in Erwägung zu ziehen:

    • Verwendung von Windows 365 Cloud-PCs (Cloud-PC) mit der Microsoft Graph-API.

    • Verwendung von bedingtem Zugriff und Filter für Geräte als Bedingung.

  • Entfernen von Legacy-Vertrauensmechanismen – Isolierte Verzeichnisse und Dienste sollten keine Vertrauensbeziehungen mit anderen Umgebungen über Legacy-Mechanismen wie Active Directory-Vertrauensstellungen herstellen. Alle Vertrauensstellungen zwischen Umgebungen sollten mit modernen Konstrukten wie Verbund und anspruchsbasierter Identität hergestellt werden.

  • Isolierung von Diensten – Minimieren Sie die Angriffsfläche, indem Sie zugrunde liegende Identitäten und Dienstinfrastruktur vor Gefahrenpotenzialen schützen. Ermöglichen Sie den Zugriff auf die Infrastruktur für Dienste und sicheren Remotezugriff (auch durch moderne Authentifizierung geschützt) nur über moderne Authentifizierung.

  • Rollenzuweisungen auf Verzeichnisebene – Vermeiden oder reduzieren Sie die Anzahl von Rollenzuweisungen auf Verzeichnisebene (Benutzeradministrator im Verzeichnisbereich anstelle von AU-Bereichsdefinition) oder dienstspezifischen Verzeichnisrollen mit Aktionen auf Steuerungsebene (Wissensadministrator mit Berechtigungen zum Verwalten von Mitgliedschaften in Sicherheitsgruppen).

Zusätzlich zu den Anleitungen im allgemeinen Betriebsleitfaden für Microsoft Entra wird empfohlen, für isolierte Umgebungen auch die folgenden Ausführungen zu berücksichtigen.

Bereitstellen von menschlichen Identitäten

Privilegierte Konten

Stellen Sie in der isolierten Umgebung Konten für Verwaltungspersonal und IT-Teams bereit, die die Umgebung betreiben. Dadurch können Sie stärkere Sicherheitsrichtlinien wie gerätebasierte Zugriffssteuerung für sichere Arbeitsstationen hinzufügen. Wie in vorherigen Abschnitten beschrieben, können Nicht-Produktionsumgebungen Microsoft Entra B2B Collaboration potenziell für das Onboarding privilegierter Konten in die Nicht-Produktionsmandanten nutzen, und zwar mit demselben Status und denselben Sicherheitskontrollen wie beim privilegierten Zugriff in der entsprechenden Produktionsumgebung.

Reine Cloudkonten stellen die einfachste Möglichkeit dar, menschliche Identitäten in einem Microsoft Entra-Mandanten bereitzustellen, und eignen sich gut für Greenfield-Umgebungen. Wenn jedoch eine lokale Infrastruktur vorhanden ist, die der isolierten Umgebung entspricht (z. B. Active Directory-Vorproduktions- oder Verwaltungsgesamtstruktur), könnten Sie in Erwägung ziehen, Identitäten von dort aus zu synchronisieren. Dies gilt insbesondere, wenn die hier beschriebene lokale Infrastruktur auch für IaaS-Lösungen verwendet wird, die Serverzugriff für die Verwaltung der Lösungsdatenebene erfordern. Weitere Informationen zu diesem Szenario finden Sie unter Schützen von Microsoft 365 vor Angriffen auf die lokale Umgebung. Die Synchronisierung von isolierten lokalen Umgebungen kann auch erforderlich sein, wenn bestimmte gesetzliche Complianceanforderungen bestehen, wie reine Smartcardauthentifizierung.

Hinweis

Für Microsoft Entra B2B-Konten gibt es keine technischen Kontrollen für die Identitätsprüfung. Für externe Identitäten, die mit Microsoft Entra B2B bereitgestellt werden, wird ein einstufiger Bootstrap ausgeführt. Daher sollte die Organisation einen Prozess einrichten, um die erforderlichen Identitäten zu überprüfen, bevor eine B2B-Einladung ausgestellt wird, und regelmäßige Zugriffsüberprüfungen auszuführen, um den Lebenszyklus zu verwalten. Überlegen Sie, eine Richtlinie für bedingten Zugriff zu aktivieren, um die MFA-Registrierung zu steuern.

Auslagern von Rollen mit hohem Risiko

Um interne Bedrohungen zu mindern, ist es möglich, den Zugriff an den globalen Administrator auszulagern und privilegierte Rollenadministratorrollen vom Dienstanbieter verwalten zu lassen, und zwar entweder über Azure B2B Collaboration oder durch Delegieren des Zugriffs über einen CSP-Partner oder Lighthouse. Dieser Zugriff kann durch interne Mitarbeiter über Genehmigungsflüsse in Azure Privileged Identity Management (PIM) kontrolliert werden. Dieser Ansatz kann interne Bedrohungen erheblich reduzieren. Mit diesem Ansatz können Sie die Complianceanforderungen für Kunden erfüllen, die Bedenken haben.

Bereitstellen von nicht menschlichen Identitäten

Konten für den Notfallzugriff

Microsoft empfiehlt Organisationen, zwei Nur-Cloud-Notfallzugriffskonten dauerhaft der Rolle Globaler Administrator zugewiesen zu haben. Diese Konten verfügen über hohe Zugriffsrechte und sind keinen bestimmten Einzelpersonen zugewiesen. Die Konten sind auf Notfall- oder Unterbrechungsglasszenarien beschränkt, in denen normale Konten nicht verwendet werden können oder alle anderen Administratoren versehentlich gesperrt sind. Diese Konten sollten nach den Empfehlungen für das Notfallzugriffskonto erstellt werden.

Von Azure verwaltete Identitäten

Verwenden Sie Azure-verwaltete Identitäten für Azure-Ressourcen, die eine Dienstidentität erfordern. Überprüfen Sie die Liste der Dienste, die verwaltete Identitäten unterstützen, wenn Sie Ihre Azure-Lösungen entwerfen.

Wenn verwaltete Identitäten nicht unterstützt werden oder nicht möglich sind, ziehen Sie die Bereitstellung von Dienstprinzipalobjekten in Erwägung.

Hybriddienstkonten

Einige Hybridlösungen erfordern möglicherweise Zugriff auf lokale und Cloudressourcen. Ein Beispiel für einen Anwendungsfall wäre eine Anwendung, die ein Dienstkonto in AD DS für den Zugriff auf lokale in Domänen eingebundene Server verwendet und außerdem über ein Konto in Microsoft Entra ID verfügt, da der Zugriff auf Microsoft Online Services erforderlich ist.

Lokale Dienstkonten verfügen in der Regel nicht über die Möglichkeit, sich interaktiv anzumelden, was bedeutet, dass sie in Cloudszenarien keine strengen Anmeldeanforderungen wie Multi-Faktor-Authentifizierung erfüllen können. Verwenden Sie in diesem Szenario kein Dienstkonto, das lokal synchronisiert wurde, sondern eine verwaltete Identität bzw. einen verwalteten Dienstprinzipal. Verwenden Sie für den Dienstprinzipal (SP) ein Zertifikat als Anmeldeinformation, oder schützen Sie den SP mit bedingtem Zugriff.

Wenn es technische Einschränkungen gibt, die dies unmöglich machen, und dasselbe Konto sowohl lokal als auch für die Cloud verwendet werden muss, implementieren Sie kompensierende Kontrollen wie bedingten Zugriff, sodass das Hybridkonto nur von einem bestimmten Netzwerkspeicherort stammen darf.

Ressourcenzuweisung

Eine Unternehmenslösung kann aus mehreren Azure-Ressourcen bestehen, und der Zugriff sollte als logische Zuweisungseinheit (eine Ressourcengruppe) verwaltet und gesteuert werden. In diesem Szenario können Microsoft Entra-Sicherheitsgruppen erstellt und in allen Lösungsressourcen mit den richtigen Berechtigungen und Rollenzuweisungen verknüpft werden, sodass das Hinzufügen oder Entfernen von Benutzern aus diesen Gruppen dazu führt, dass der Zugriff auf die gesamte Lösung erlaubt oder verweigert wird.

Es wird empfohlen, gruppenbasierte Lizenzierungs- und Sicherheitsgruppen für Microsoft-Dienste zu verwenden, die auf einem Benutzer mit einer Lizenzplatzzuweisung als Voraussetzung angewiesen sind, bevor Sie Zugriff bereitstellen (z. B. Dynamics 365, Power BI).

Cloudnative Microsoft Entra-Gruppen können in Kombination mit Microsoft Entra-Zugriffsüberprüfungen und Microsoft Entra-Berechtigungsverwaltung nativ von der Cloud aus gesteuert werden.

Microsoft Entra ID unterstützt auch direkte Benutzerzuweisungen zu SaaS-Diensten von Drittanbietern (z. B. Salesforce, Service Now) und lokale Anwendungen für einmaliges Anmelden und Identitätsbereitstellung. Direkte Zuweisungen an Ressourcen können in Kombination mit Microsoft Entra-Zugriffsüberprüfungen und Microsoft Entra-Berechtigungsverwaltung nativ von der Cloud aus gesteuert werden. Direktzuweisung ist möglicherweise eine gute Lösung für endbenutzerseitige Zuweisungen.

Einige Szenarien erfordern möglicherweise den Zugriff auf lokale Ressourcen über lokale Active Directory-Sicherheitsgruppen. Ziehen Sie bei der Ausarbeitung von Prozess-SLA für diese Fälle den Synchronisierungszyklus mit Microsoft Entra in Erwägung.

Authentifizierungsverwaltung

In diesem Abschnitt werden die Überprüfungen beschrieben, die je nach Sicherheitsstatus Ihrer Organisation für die Verwaltung von Anmeldeinformationen und Zugriffsrichtlinien durchgeführt werden sollen.

Verwaltung von Anmeldeinformationen

Sichere Anmeldeinformationen

Alle menschlichen Identitäten (lokale Konten und externe über B2B Collaboration bereitgestellte Identitäten) in der isolierten Umgebung müssen mit sicheren Authentifizierungsinformationen wie Multi-Faktor-Authentifizierung oder einem FIDO-Schlüssel bereitgestellt werden. Umgebungen mit einer zugrunde liegenden lokalen Infrastruktur mit strenger Authentifizierung wie Smartcardauthentifizierung können diese in der Cloud weiter verwenden.

Kennwortlose Anmeldeinformationen

Eine kennwortlose Methode ist die beste Lösung, um eine praktische und sichere Authentifizierung zu gewährleisten. Kennwortlose Anmeldeinformationen wie FIDO-Sicherheitsschlüssel und Windows Hello for Business werden für menschliche Identitäten mit privilegierten Rollen empfohlen.

Kennwortschutz

Wenn die Umgebung von einer lokalen Active Directory Gesamtstruktur aus synchronisiert wird, sollten Sie Microsoft Entra-Kennwortschutz bereitstellen, um schwache Kennwörter in Ihrer Organisation zu beseitigen. Microsoft Entra Smart Lockout sollte auch in Hybrid- oder reinen Cloudumgebungen verwendet werden, um schlechte Akteure zu sperren, die versuchen, die Kennwörter Ihrer Benutzer zu erraten oder sich mit Brute-Force-Methoden Zugang zu verschaffen.

Self-service password management (Self-Service-Kennwortverwaltung)

Benutzer, die ihre Kennwörter ändern oder zurücksetzen müssen, sind eine der größten Quellen für Helpdesk-Anrufe. Neben den Kosten, ist die Kennwortänderung ein Tool zum Mindern des Benutzerrisikos und ein wichtiger Schritt zur Verbesserung des Sicherheitsstatus Ihrer Organisation. Stellen Sie mindestens Self-Service-Kennwortverwaltung für menschliche und Testkonten mit Kennwörtern bereit, um Helpdeskanrufe abzulenken.

Kennwörter für externe Identitäten

Mithilfe von Microsoft Entra B2B Collaboration, einem Einladungs- und Einlösungsprozess, können externe Benutzer wie Partner, Entwickler und Subunternehmer ihre eigenen Anmeldeinformationen verwenden, um auf die Ressourcen Ihres Unternehmens zuzugreifen. Dadurch entfällt die Notwendigkeit, mehr Kennwörter in die isolierten Mandanten einzuführen.

Hinweis

Einige Anwendungen, Infrastrukturen oder Workflows erfordern möglicherweise lokale Anmeldeinformationen. Beurteilen Sie dies je nach Fall.

Anmeldeinformationen für Dienstprinzipale

Für Szenarien, in denen Dienstprinzipale benötigt werden, verwenden Sie Zertifikatanmeldeinformationen für Dienstprinzipale oder bedingten Zugriff für Workloadidentitäten. Verwenden Sie ggf. Clientschlüssel als Ausnahme von der Organisationsrichtlinie.

In beiden Fällen kann Azure Key Vault mit verwalteten Azure-Identitäten verwendet werden, damit die Laufzeitumgebung (z. B. eine Azure-Funktion) die Anmeldeinformationen aus dem Schlüsseltresor abrufen kann.

Sehen Sie sich dieses Beispiel zum Erstellen von Dienstprinzipalen mit selbst signiertem Zertifikat für die Authentifizierung von Dienstprinzipalen mit Zertifikatanmeldeinformationen an.

Zugriffsrichtlinien

In den folgenden Abschnitten finden Sie Empfehlungen für Azure-Lösungen. Einen allgemeinen Leitfaden zu Richtlinien für bedingtem Zugriff für einzelne Umgebungen finden Sie unter Bewährte Methoden für bedingten Zugriff, im Microsoft Entra-Betriebshandbuch und unter Bedingter Zugriff für Zero Trust:

  • Definieren Sie Richtlinien für bedingten Zugriff für die Windows Azure Dienstverwaltungs-API-Cloud-App, um den Identitätssicherheitsstatus beim Zugriff auf Azure Resource Manager zu erzwingen. Dies sollte Kontrollen für MFA und gerätebasierte Kontrollen einschließen, damit der Zugriff nur über sichere Arbeitsstationen möglich ist (mehr dazu im Abschnitt „Privilegierte Rollen“ unter „Identitätsgovernance“). Verwenden Sie außerdem bedingten Zugriff, um nach Geräten zu filtern.

  • Alle Anwendungen, die per Onboarding in isolierte Umgebungen integriert werden, müssen explizite Richtlinien für bedingten Zugriff haben, die im Rahmen des Onboardingprozesses angewendet werden.

  • Definieren Sie Richtlinien für bedingten Zugriff für die Registrierung von Sicherheitsinformationen, die einen sicheren Stamm des lokalen Vertrauensprozesses widerspiegeln (z. B. dass Arbeitsstationen an physischen Standorten, die durch IP-Adressen identifizierbar sind, zur Überprüfung von Mitarbeitern persönlich besucht werden müssen).

  • Erwägen Sie die Verwendung von bedingtem Zugriff, um Workloadidentitäten einzuschränken. Erstellen Sie eine Richtlinie, um den Zugriff basierend auf dem Standort oder anderen relevanten Umständen einzuschränken oder besser zu kontrollieren.

Herausforderungen der Authentifizierung

  • Externe Identitäten, die mit Microsoft Entra B2B bereitgestellt werden, müssen möglicherweise Anmeldeinformation für Multi-Faktor-Authentifizierung im Ressourcenmandanten neu bereitstellen. Dies kann erforderlich sein, wenn eine mandantenübergreifende Zugriffsrichtlinie nicht mit dem Ressourcenmandanten eingerichtet wurde. Dies bedeutet, dass das Onboarding im System mit einem einzelnen Faktor gestartet wird. Bei diesem Ansatz mindert die Organisation das Risiko mithilfe eines Prozesses, bei dem das Risikoprofil von Benutzer und Anmeldeinformationen geprüft wird, bevor eine B2B-Einladung erfolgt. Definieren Sie außerdem wie zuvor beschrieben bedingten Zugriff auf den Registrierungsvorgang.

  • Verwenden Sie mandantenübergreifende External Identities-Zugriffseinstellungen verwenden, um die Zusammenarbeit mit anderen Microsoft Entra-Organisationen und anderen Microsoft Azure-Clouds über B2B-Zusammenarbeit und eine direkte B2B-Verbindung zu verwalten.

  • Für bestimmte Gerätekonfiguration und -steuerung können Sie Gerätefilter in Richtlinien für bedingten Zugriff verwenden, um bestimmte Geräte als Ziel festzulegen oder auszuschließen. Auf diese Weise können Sie den Zugriff auf Azure-Verwaltungstools von einer festgelegten sicheren Administratorarbeitsstation (SAW) aus einschränken. Weitere mögliche Ansätze sind Azure Virtual Desktop, Azure Bastion oder Cloud PC.

  • Abrechnungsverwaltungsanwendungen wie Azure EA Portal oder MCA-Abrechnungskonten werden nicht als Cloudanwendungen für die Zielbestimmung für bedingten Zugriff dargestellt. Als ausgleichende Kontrolle können Sie separate Verwaltungskonten definieren und mit dem Zustand „Alle Apps“ Richtlinien für bedingten Zugriff als Ziel für diese Konten festlegen.

Identity Governance

Privilegierte Zeit

Im Folgenden finden Sie einige Identitätsgovernanceprinzipien, die in allen Mandantenkonfigurationen für die Isolation berücksichtigt werden sollen.

  • Kein ständiger Zugriff – Keine menschlichen Identitäten sollten ständigen Zugriff haben, um privilegierte Vorgänge in isolierten Umgebungen auszuführen. Azure RBAC (Rollenbasierte Zugriffssteuerung) ist in Microsoft Entra Privileged Identity Management (PIM) integriert. PIM bietet Just-In-Time-Aktivierung, die von Sicherheitsgates bestimmt wird, z. B. Multi-Faktor-Authentifizierung, Genehmigungsworkflow und begrenzte Dauer.

  • Anzahl der Administratoren – Organisationen sollten die minimale und maximale Anzahl von Menschen mit privilegierten Rollen definieren, um Risiken für die Geschäftskontinuität zu verringern. Bei einer zu geringen Anzahl von privilegierten Rollen gibt es möglicherweise nicht genügend Zeitzonenabdeckung. Mindern Sie Sicherheitsrisiken, indem Sie so wenige Administratoren wie möglich haben, wobei Sie nach dem Prinzip der „geringsten Berechtigung“ vorgehen.

  • Einschränken des privilegierten Zugriffs – Erstellen Sie für umfangreiche oder vertrauliche Berechtigungen reine Cloud- und rollenzuweisungsfähige Gruppen. Dies bietet Schutz für die zugewiesenen Benutzer und das Gruppenobjekt.

  • Geringstprivilegierter Zugriff – Identitäten sollten nur die Berechtigungen erteilt werden, die zum Ausführen der privilegierten Vorgänge erforderlich sind, die ihrer Rolle in der Organisation entsprechen.

    • Benutzerdefinierte Azure RBAC-Rollen ermöglichen das Entwerfen geringstprivilegierter Rollen basierend auf den Anforderungen der Organisation. Es wird empfohlen, benutzerdefinierte Rollendefinitionen, die Risiken unbeabsichtigter übermäßiger Berechtigungen mindern, von spezialisierten Sicherheitsteams erstellen oder überprüfen zu lassen. Das Erstellen benutzerdefinierter Rollen kann über Azure Policy überwacht werden.

    • Zur Vermeidung einer versehentlichen Verwendung von Rollen, die nicht für eine breitere Verwendung in der Organisation vorgesehen sind, definieren Sie mit Azure Policy explizit, welche Rollendefinitionen zum Zuweisen des Zugriffs verwendet werden können. Erfahren Sie mehr anhand dieses GitHub-Beispiels.

  • Privilegierter Zugriff über sichere Arbeitsstationen – Jeder privilegierte Zugriff sollten von sicheren, gesperrten Geräten aus erfolgen. Die Trennung dieser vertraulichen Aufgaben und Konten von Arbeitsstationen und Geräten für den täglichen Gebrauch schützt privilegierte Konten vor Phishingangriffen, vor Sicherheitsrisiken für das Betriebssystem und die Anwendungen, vor verschiedenen Identitätswechselangriffen und vor dem Diebstahl von Anmeldeinformationen (beispielsweise mithilfe von Keyloggern, Pass-the-Hash und Pass-the-Ticket).

Zu einigen Ansätzen, die es Ihnen ermöglichen, sichere Geräte als Teil Ihres privilegierten Zugriffskonzepts zu verwenden, gehört u. a., mithilfe von Richtlinien für bedingten Zugriff bestimmte Geräte als Ziel festzulegen oder auszuschließen, Azure Virtual Desktop, Azure Bastion oder Cloud-PC zu verwenden oder Azure-verwaltete Arbeitsstationen oder Arbeitsstationen mit privilegiertem Zugriff zu erstellen.

  • Prozessguardrails für privilegierte Rollen – Organisationen müssen Prozesse und technische Guardrails definieren, um sicherzustellen, dass privilegierte Vorgänge bei Bedarf ausgeführt werden können, während die gesetzlichen Anforderungen eingehalten werden. Beispiele für Guardrailkriterien:

    • Qualifikation von Menschen mit privilegierten Rollen (z. B. Vollzeitmitarbeiter/Anbieter, Freigabestufe, Staatsbürgerschaft)

    • Explizite Inkompatibilität von Rollen (auch bekannt als Aufgabentrennung). Beispiele sind Teams mit Microsoft Entra-Verzeichnisrollen, die nicht für die Verwaltung von privilegierten Azure Resource Manager-Rollen usw. verantwortlich sein sollten.

    • Bevorzugung von direkten Benutzer- oder Gruppenzuweisungen für welche Rollen.

  • Das Überwachen von IAM-Zuweisungen außerhalb von Microsoft Entra PIM wird nicht über Azure-Richtlinien automatisiert. Weisen Sie Entwicklungsteams daher nicht die Rollen „Abonnementbesitzer“ oder „Benutzerzugriffsadministrator“ zu. Erstellen Sie stattdessen Gruppen, die geringstprivilegierten Rollen zugewiesen sind (z. B. „Mitwirkender“) und delegieren Sie die Verwaltung dieser Gruppen an Entwicklungsteams.

Zugriff auf Ressourcen

  • Nachweis – Identitäten mit privilegierten Rollen sollten regelmäßig überprüft werden, um die Mitgliedschaft auf dem neuesten Stand und ihre Angebrachtheit zu bestätigen. Microsoft Entra-Zugriffsüberprüfungen werden in Azure RBAC-Rollen, Gruppenmitgliedschaften und externe Microsoft Entra B2B-Identitäten integriert.

  • Lebenszyklus – Privilegierte Vorgänge erfordern möglicherweise Zugriff auf mehrere Ressourcen wie Branchenanwendungen, SaaS-Anwendungen sowie Azure-Ressourcengruppen und Abonnements. Microsoft Entra-Berechtigungsverwaltung ermöglicht das Definieren von Zugriffspaketen, die einer festgelegten Ressource entsprechen, welche Benutzern als Einheit zugewiesen wird, sowie das Einrichten von Gültigkeitszeiträumen, Genehmigungsworkflows usw.

Lebenszyklusverwaltung für Mandanten und Abonnements

Mandantenlebenszyklus

  • Es wird empfohlen, einen Prozess zum Anfordern eines neuen Microsoft Entra-Unternehmensmandanten zu implementieren. Dabei ist Folgendes zu berücksichtigen:

    • Geschäftliche Begründung für die Erstellung. Das Erstellen eines neuen Microsoft Entra-Mandanten erhöht die Komplexität erheblich. Daher ist es wichtig, festzustellen, ob ein neuer Mandant erforderlich ist.

    • Die Azure-Cloud, in der er erstellt werden soll (z. B. Commercial, Government usw.).

    • Ob es ein Produktionsmandant oder ein Nicht-Produktionsmandant ist

    • Anforderungen an die Verzeichnisdatenresidenz

    • Wer wird es verwalten

    • Schulung und Verständnis gemeinsamer Sicherheitsanforderungen

  • Nach der Genehmigung wird der Microsoft Entra-Mandant erstellt, mit erforderlichen Basiskontrollen konfiguriert und per Onboarding in die Abrechnungsebene, die Überwachung usw. integriert.

  • Regelmäßige Überprüfung der Microsoft Entra-Mandanten auf Abrechnungsebene muss implementiert werden, um die Erstellung von Mandanten außerhalb des geregelten Prozesses zu erkennen und zu ermitteln. Weitere Details finden Sie im Abschnitt Bestand und Transparenz dieses Dokuments.

  • Die Azure AD B2C-Mandantenerstellung kann mithilfe von Azure Policy kontrolliert werden. Die Richtlinie wird ausgeführt, wenn dem B2C-Mandanten ein Azure-Abonnement zugeordnet ist (eine Voraussetzung für die Abrechnung). Kunden können die Erstellung von Azure AD B2C-Mandanten auf bestimmte Verwaltungsgruppen beschränken.

  • Es gibt keine technischen Kontrollen, um die Erstellung von Mandanten einer Organisation zu unterzuordnen. Die Aktivität wird jedoch im Überwachungsprotokoll aufgezeichnet. Das Onboarding in das Abrechnungsflugzeug ist eine ausgleichende Kontrolle am Gate. Dies muss stattdessen durch Überwachung und Warnung ergänzt werden.

Abonnementlebenszyklus

Im Folgenden finden Sie einige Überlegungen für den Entwurf eines geregelten Abonnementlebenszyklus-Prozesses:

  • Definieren Sie eine Taxonomie von Anwendungen und Lösungen, die Azure-Ressourcen erfordern. Alle Teams, die Abonnements anfordern, sollten beim Anfordern von Abonnements ihren „Produktbezeichner“ angeben. Diese Informationstaxonomie bestimmt Folgendes:

    • Microsoft Entra-Mandant, um das Abonnement bereitzustellen

    • Azure EA-Konto für das Erstellen von Abonnements

    • Benennungskonvention

    • Verwaltungsgruppenzuweisung

    • Andere Aspekte wie Tagging, interne Verrechnung, Produktansichtsnutzung usw.

  • Lassen Sie die Erstellung von Ad-hoc-Abonnements nicht über die Portale oder auf andere Weise zu. Erwägen Sie stattdessen, Abonnements programmgesteuert mithilfe von Azure Resource Manager zu verwalten und Verbrauchs- und Abrechnungsberichte programmgesteuert abzurufen. Dadurch können Sie Abonnements auf autorisierte Benutzer beschränken und Ihre Richtlinien- und Taxonomieziele erzwingen. Mithilfe des Leitfadens zu den folgenden AZOps-Prinzipalen können Sie praktische Lösung erstellen.

  • Wenn ein Abonnement bereitgestellt wird, erstellen Sie Microsoft Entra-Cloudgruppen mit standardmäßigen Azure Resource Manager-Rollen, die von Anwendungsteams wie „Mitwirkender“, „Leser“ und genehmigten benutzerdefinierten Rollen benötigt werden. Auf diese Weise können Sie Azure RBAC-Rollenzuweisungen mit geregeltem privilegiertem Zugriff im großen Stil verwalten.

    1. Konfigurieren Sie die Gruppen als für Azure RBAC-Rollen berechtigt, indem Sie Microsoft Entra PIM mit den entsprechenden Kontrollen verwenden (Aktivierungsrichtlinie, Zugriffsüberprüfungen, genehmigende Personen usw.).

    2. Anschließend delegieren Sie die Verwaltung der Gruppen an Lösungsbesitzer.

    3. Weisen Sie den Rollen „Benutzerzugriffsadministrator“ oder „Besitzer“ keine Produktbesitzer als Guardrail zu, um eine versehentliche direkte Zuweisung von Rollen außerhalb von Microsoft Entra PIM zu vermeiden oder das Abonnement möglicherweise in einen völlig anderen Mandanten zu ändern.

    4. Stellen Sie für Kunden, die die mandantenübergreifende Abonnementverwaltung in Nicht-Produktionsmandanten über Azure Lighthouse aktivieren möchten, sicher, dass bei der Authentifizierung für die Verwaltung der Abonnements dieselben Zugriffsrichtlinien des privilegierten Produktionskontos erzwungen werden (z. B. privilegierter Zugriff nur von gesicherten Arbeitsstationen aus).

  • Wenn Ihre Organisation über vorab genehmigte Referenzarchitekturen verfügt, kann die Abonnementbereitstellung mit Ressourcenbereitstellungstools wie Azure Blueprints oder Terraform integriert werden.

  • Angesichts der Mandantenaffinität zu Azure-Abonnements sollte die Abonnementbereitstellung gewahr sein, dass auf mehreren Mandanten mehrere Identitäten für denselben menschlichen Akteur (Mitarbeiter, Partner, Anbieter usw.) vorhanden sind und entsprechend Zugriff zuweisen.

EA- und MCA-Rollen

  • Das Azure Enterprise Agreement-Portal (Azure EA) lässt sich nicht in Azure RBAC oder bedingten Zugriff integrieren. Verwenden Sie daher dedizierte Verwaltungskonten, für die gezielt Richtlinien und zusätzliche Überwachung festgelegt werden können.

  • Im Azure EA Enterprise-Portal wird kein Überwachungsprotokoll bereitgestellt. Ziehen Sie daher einen automatisierten geregelten Prozess in Erwägung, um Abonnements unter Berücksichtigung der oben stehenden Überlegungen bereitzustellen, dedizierte EA-Konten zu verwenden und die Authentifizierungsprotokolle zu überwachen.

  • Microsoft-Kundenvereinbarung-Rollen (MCA) lassen sich nicht nativ mit PIM integrieren. Verwenden Sie daher dedizierte MCA-Konten, und überwachen Sie deren Verwendung.

Azure AD B2C-Mandanten

  • In einem Azure AD B2C-Mandanten wird PIM von den integrierten Rollen nicht unterstützt. Zur Erhöhung der Sicherheit empfehlen wir die Verwendung von Microsoft Entra B2B Collaboration, um das Onboarding der Entwicklungsteams durchzuführen, die die Verwaltung von Customer Identity Access Management (CIAM) über Ihren Azure-Mandanten verwalten, ihnen privilegierte Microsoft Entra B2C-Rollen zuzuweisen und Richtlinien für den bedingten Zugriff auf diese dedizierten Administrationskonten anzuwenden.

  • Privilegierte Azure AD B2C-Mandantenrollen sind nicht in Microsoft Entra-Zugriffsüberprüfungen integriert. Erstellen Sie daher dedizierte Konten im Microsoft Entra-Mandanten der Organisation, fügen Sie diese Konten einer Gruppe hinzu, und führen Sie regelmäßige Zugriffsüberprüfungen für diese Gruppe aus.

  • Nach den oben beschriebenen Notfallzugriffs-Richtlinien für Microsoft Entra ID sollten Sie erwägen, zusätzlich zu den oben beschriebenen externen Administratoren äquivalente Notfallzugriffskonten zu erstellen.

  • Es wird empfohlen, den logischen Besitz des zugrunde liegenden Microsoft Entra-Abonnements des B2C-Mandanten genauso auf die CIAM-Engineering-Teams auszurichten wie die Verwendung der übrigen Azure-Abonnements für die B2C-Lösungen.

Vorgänge

Nachfolgend finden Sie zusätzliche betriebliche Überlegungen für Microsoft Entra ID, die für mehrere isolierte Umgebungen spezifisch sind. Einen detaillierten Leitfaden zum Betrieb einzelner Umgebungen finden Sie unter Azure Cloud Adoption Framework, in der Microsoft-Benchmark für Cloudsicherheit und im Microsoft Entra Operations-Handbuch.

Umgebungsübergreifende Rollen und Zuständigkeiten

Unternehmensweite SecOps-Architektur – Mitglieder von Betriebs- und Sicherheitsteams aus allen Umgebungen in der Organisation sollten gemeinsam Folgendes definieren:

  • Prinzipien zum Definieren, wann Umgebungen erstellt, konsolidiert oder als veraltet markiert werden müssen.

  • Prinzipien zum Definieren der Verwaltungsgruppenhierarchie für jede Umgebung.

  • Abrechnungsebene (EA Portal/MCA) Sicherheitsstatus, Betriebsstatus und Delegierungsansatz.

  • Prozess für die Mandantenerstellung.

  • Unternehmensanwendungstaxonomie.

  • Prozess für die Bereitstellung von Azure-Abonnements.

  • Team- und umgebungsübergreifende Isolations- und Verwaltungsautonomiegrenzen.

  • Allgemeine Baselinekonfiguration und Sicherheitskontrollen (technisch und kompensierend) sowie in allen Umgebungen zu verwendende Betriebsbaselines.

  • Allgemeine Standardbetriebsverfahren und Tools für mehrere Umgebungen (z. B. Überwachung, Bereitstellung).

  • Vereinbarte Delegierung von Rollen in mehreren Umgebungen.

  • Trennung der Pflicht zwischen Umgebungen.

  • Allgemeines Supply Chain Management für privilegierte Arbeitsstationen.

  • Benennungskonventionen

  • Umgebungsübergreifende Korrelationsmechanismen.

Mandantenerstellung – Ein bestimmtes Team sollte für das Erstellen des Mandanten nach standardisierten Verfahren zuständig sein, die durch die unternehmensweiten SecOps-Architektur definiert sind. Dies umfasst u. a.:

  • Zugrunde liegende Lizenzbereitstellung (z. B. Microsoft 365).

  • Onboarding in den Abrechnungsplan des Unternehmens (z. B. Azure EA oder MCA).

  • Erstellen der Azure-Verwaltungsgruppenhierarchie.

  • Konfiguration von Verwaltungsrichtlinien für verschiedene Perimeter, einschließlich Identität, Datenschutz, Azure usw.

  • Bereitstellung des Sicherheitsstapels gemäß vereinbarter Cybersicherheitsarchitektur, einschließlich Diagnoseeinstellungen, SIEM-Onboarding, CASB-Onboarding, PIM-Onboarding usw.

  • Konfiguration von Microsoft Entra-Rollen basierend auf vereinbarter Delegierung.

  • Konfiguration und Verteilung der ersten privilegierten Arbeitsstationen.

  • Bereitstellung von Notfallzugriffskonten.

  • Konfiguration des Identitätsbereitstellungsstapels.

Umgebungsübergreifende Toolarchitektur – Einige Tools wie Identitätsbereitstellung und Quellcodeverwaltungspipeline müssen möglicherweise in mehreren Umgebungen funktionieren. Diese Tools sollten als kritisch für die Infrastruktur betrachtet werden und müssen dementsprechend entworfen, entworfen, implementiert und verwaltet werden. Daher sollten immer Architekten aus allen Umgebungen einbezogen werden, wenn umgebungsübergreifende Tools definiert werden müssen.

Bestand und Transparenz

Azure-Abonnementermittlung – Für jeden ermittelten Mandanten kann ein globaler Microsoft Entra-Administrator die Zugriffsrechte erhöhen, um alle Abonnements in der Umgebung zu sehen. Diese Rechteerweiterung weist ihnen die integrierte Benutzerzugriffsadministrator-Rolle in der Stammverwaltungsgruppe zu.

Hinweis

Diese Aktion ist mit umfangreichen Berechtigungen versehen und kann dem Administrator Zugriff auf Abonnements gewähren, die äußerst vertrauliche Informationen enthalten, wenn diese Daten nicht ordnungsgemäß isoliert wurden.

Aktivieren des Lesezugriffs auf zum Ermitteln von Ressourcen – Verwaltungsgruppen ermöglichen die abonnementübergreifende RBAC-Zuordnung im großen Stil. Kunden können einem zentralen IT-Team eine „Leser“-Rolle erteilen, indem sie eine Rollenzuweisung in der Stammverwaltungsgruppe konfigurieren, die an alle Abonnements in der Umgebung verteilt wird.

Ressourcenermittlung – Nach dem Abrufen des Lesezugriffs für Ressourcen in der Umgebung können Ressourcen in der Umgebung mithilfe von Azure Resource Graph abgefragt werden.

Protokollierung und Überwachung

Zentrale Sicherheitsprotokollverwaltung – Erfassen Sie Protokolle von jeder Umgebung zentral unter Verwendung konsistenter, umgebungsübergreifender bewährter Methoden (z. B. Diagnoseeinstellungen, Protokollaufbewahrung, SIEM-Erfassung usw.). Mit Azure Monitor können Protokolle aus verschiedenen Quellen (z. B. Endpunktgeräte, Netzwerk, Sicherheitsprotokolle von Betriebssystemen usw.) erfasst werden.

Detaillierte Informationen zur Verwendung automatisierter oder manueller Prozesse und Tools zur Überwachung von Protokollen im Rahmen Ihrer Sicherheitsvorgänge finden Sie im Handbuch zu Microsoft Entra-Sicherheitsvorgängen.

Einige Umgebungen haben möglicherweise gesetzliche Anforderungen, die einschränken, welche Daten (sofern vorhanden) eine bestimmte Umgebung verlassen können. Wenn eine zentrale Überwachung der Umgebungen nicht möglich ist, sollten Teams über Betriebsverfahren verfügen, um die Aktivitäten von Identitäten in den Umgebungen für Überwachungs- und Forensikzwecke wie umgebungsübergreifende Lateral-Movement-Versuche zu korrelieren. Es wird empfohlen, dass die zur selben Person gehörigen menschlichen Identitäten (eindeutige Objektbezeichner) erkannt werden können, möglicherweise als Teil der Identitätsbereitstellungssysteme.

Die Protokollstrategie muss die folgenden Microsoft Entra-Protokolle für jeden in der Organisation verwendeten Mandanten enthalten:

  • Anmeldeaktivität

  • Überwachungsprotokolle

  • Risikoereignisse

Microsoft Entra ID bietet Azure Monitor-Integration für die Protokolle zu Anmeldeaktivitäten und Überwachungsprotokolle. Risikoereignisse können mithilfe der Microsoft Graph-API erfasst werden.

Das folgende Diagramm zeigt die verschiedenen Datenquellen, die als Teil der Überwachungsstrategie integriert werden müssen:

Azure AD B2C-Mandanten können in Azure Monitor integriert werden. Wir empfehlen, Azure AD B2C unter Verwendung derselben Kriterien zu überwachen, die oben für Microsoft Entra ID beschrieben wurden.

Abonnements, für die mandantenübergreifende Verwaltung mit Azure Lighthouse aktiviert ist, können mandantenübergreifende Überwachung aktivieren, wenn die Protokolle von Azure Monitor gesammelt werden. Die entsprechenden Log Analytics-Arbeitsbereiche können sich im Ressourcenmandanten befinden und zentral im verwaltenden Mandanten mithilfe von Azure Monitor-Arbeitsmappen analysiert werden. Weitere Informationen finden Sie unter Überwachen von delegierten Ressourcen in beliebigem Umfang – Azure Lighthouse.

Sicherheitsprotokolle des Betriebssystems bei Hybridinfrastrukturen

Bei einer Hybrididentitätsinfrastruktur sollten angesichts der Auswirkungen auf die Oberfläche alle Betriebssystemprotokolle archiviert und sorgfältig als System der Ebene 0 überwacht werden. Dies umfasst u. a.:

  • AD FS-Server und Webanwendungsproxy

  • Microsoft Entra Connect

  • Anwendungsproxy-Agents

  • Kennwortrückschreibe-Agents

  • Kennwortschutzgateway-Computer

  • NPS mit der RADIUS-Erweiterung für die Multi-Faktor-Authentifizierung in Microsoft Entra

Microsoft Entra Connect Health muss bereitgestellt werden, um die Identitätssynchronisierung und den Verbund (sofern zutreffend) für alle Umgebungen zu überwachen.

Aufbewahrung von Protokollspeichern – Strategie, Entwurf und Implementierung der Aufbewahrung von Protokollspeichern sollte für alle Umgebungen einheitlich sein, um ein konsistentes Toolset (z. B. SIEM-Systeme wie Azure Sentinel), allgemeine Abfragen, Untersuchungen und forensische Playbooks zu unterstützen. Azure Policy kann zum Einrichten von Diagnoseeinstellungen verwendet werden.

Überwachung und Protokollüberprüfung – Die Betriebsaufgaben in Bezug auf die Identitätsüberwachung sollten konsistent sein und in jeder Umgebung Besitzer haben. Versuchen Sie wie oben beschrieben, diese Verantwortlichkeiten umgebungsübergreifend zu konsolidieren, soweit gesetzliche Compliance- und Isolationsanforderungen dies erlauben.

Die folgenden Szenarien müssen explizit überwacht und untersucht werden:

  • Verdächtige Aktivitäten: Alle Microsoft Entra-Risikoereignisse sollten auf verdächtige Aktivitäten überwacht werden. Definieren Sie die benannten Standorte im Netzwerk, um gestörte Erkennungen anhand von standortbasierten Signalen zu vermeiden. Microsoft Entra ID Protection ist nativ in das Azure Security Center integriert. Es wird empfohlen, dass jede Risikoerkennungsuntersuchung alle Umgebungen enthält, in denen die Identität bereitgestellt wurde (wenn eine menschliche Identität z. B. über eine aktive Risikoerkennung im Unternehmensmandanten verfügt, sollte das Team, das dem Kunden gegenübersteht, auch die Aktivität des entsprechenden Kontos in dieser Umgebung untersuchen).

  • UEBA-Warnungen (User Entity Behavior Analytics) – UEBA sollte verwendet werden, um erkenntnisreiche Informationen basierend auf der Anomalieerkennung zu erhalten. Microsoft 365 Defender for Cloud Apps bietet UEBA in der Cloud. Kunden können lokale UEBA von Microsoft 365 Defender for Identity integrieren. MCAS liest Signale von Microsoft Entra ID Protection.

  • Aktivität bei Konten für den Notfallzugriff: Jeder Zugriff, der mithilfe von Konten für den Notfallzugriff erfolgt, sollte überwacht werden, und es sollten Benachrichtigungen für Untersuchungen erstellt werden. Diese Überwachung muss Folgendes umfassen:

    • Anmeldungen

    • Verwaltung von Anmeldeinformationen

    • Alle Aktualisierungen von Gruppenmitgliedschaften

    • Anwendungszuweisungen

  • Abrechnungsverwaltungskonten – Angesichts der Vertraulichkeit von Konten mit Abrechnungsverwaltungsrollen in Azure EA oder MCA und ihren bedeutenden Berechtigungen empfiehlt es sich, Folgendes zu überwachen und zu melden:

    • Anmeldeversuche von Konten mit Abrechnungsrollen.

    • Versuche, sich bei anderen Anwendungen als dem EA Portal zu authentifizieren.

    • Versuche, sich bei anderen Anwendungen als Azure Resource Management zu authentifizieren, wenn dedizierte Konten für MCA-Abrechnungsaufgaben verwendet werden.

    • Zuweisung zu Azure-Ressourcen mithilfe dedizierter Konten für MCA-Abrechnungsaufgaben.

  • Aktivität bei privilegierten Rollen: Konfigurieren und überprüfen Sie die von Microsoft Entra PIM generierten Sicherheitswarnungen. Wenn das Sperren von direkten RBAC-Zuweisungen nicht vollständig mit technischen Kontrollen erzwingbar ist (z. B. Zuweisung der Rolle „Besitzer“ zu Produktteams zur Erledigung ihrer Aufgaben), überwachen Sie die direkte Zuweisung von privilegierten Rollen außerhalb von PIM, indem Sie Warnungen generieren, wenn ein Benutzer direkt auf das Abonnement mit Azure RBAC zugreifen kann.

  • Klassische Rollenzuweisungen – Organisationen sollten die moderne Azure RBAC-Rolleninfrastruktur anstelle der klassischen Rollen verwenden. Folglich sollten die folgenden Ereignisse überwacht werden:

    • Zuweisung zu klassischen Rollen auf Abonnementebene

  • Mandantenweite Konfigurationen – Für jede Änderung an mandantenweiten Konfigurationen sollten Warnungen im System generiert werden.

    • Aktualisieren von benutzerdefinierten Domänen

    • Aktualisieren des Brandings

    • Microsoft Entra B2B-Zulassungs-/Sperrliste

    • Von Microsoft Entra B2B zugelassene Identitätsanbieter (SAML-IDPs über direkte Verbundanmeldungen oder Anmeldungen in sozialen Netzwerken)

    • Änderungen an Richtlinien für bedingten Zugriff

  • Anwendungs- und Dienstprinzipalobjekte in Azure Active Directory (Azure AD)

    • Neue Anwendungen/Dienstprinzipale, die möglicherweise Richtlinien für bedingten Zugriff erfordern

    • Anwendungszustimmungsaktivitäten

  • Verwaltungsgruppenaktivität – Die folgenden Identitätsaspekte von Verwaltungsgruppen sollten überwacht werden:

    • RBAC-Rollenzuweisungen in der Verwaltungsgruppe

    • Auf die Verwaltungsgruppe angewendete Azure-Richtlinien

    • Zwischen Verwaltungsgruppen verschobene Abonnements

    • Alle Änderungen an Sicherheitsrichtlinien für die Stammverwaltungsgruppe

  • Benutzerdefinierte Rollen

    • Aktualisierungen der benutzerdefinierten Rollendefinitionen

    • Neu erstellte benutzerdefinierte Rollen

  • Benutzerdefinierte Regeln für die Aufgabentrennung – Wenn Ihre Organisationen eine Trennung von Aufgabenregeln eingerichtet haben, verwenden Sie Microsoft Entra-Berechtigungsverwaltung, um eine Trennung von Aufgaben zu erzwingen, und erstellen Sie Warnungen oder konfigurieren regelmäßige Überprüfungen, um Verstöße durch Administratoren zu erkennen.

Weitere Überlegungen zur Überwachung – Azure-Abonnements, die Ressourcen enthalten, welche für die Protokollverwaltung verwendet werden, sollten als kritische Infrastruktur (Stufe 0) betrachtet und auf das Security Operations-Team der entsprechenden Umgebung festgelegt werden. Erwägen Sie die Verwendung von Tools wie Azure Policy, um zusätzliche Kontrollen für diese Abonnements zu erzwingen.

Betriebstools

Überlegungen zum Entwurf von umgebungsübergreifenden Tools:

  • Sofern möglich, sollten Betriebstools, die mandantenübergreifend verwendet werden, als mehrinstanzenfähige Microsoft Entra-Anwendung ausgeführt werden, um die erneute Bereitstellung mehrerer Instanzen für jeden Mandanten zu vermeiden und betriebliche Ineffizienzen zu vermeiden. Die Implementierung sollte Autorisierungslogik enthalten, um sicherzustellen, dass die Isolation zwischen Benutzern und Daten beibehalten wird.

  • Fügen Sie Warnungen und Erkennungen hinzu, um alle Umgebungsautomatisierungen (z. B. Identitätsbereitstellung) und Schwellenwerte für Sicherheitsmaßnahmen zu überwachen. Vielleicht wünschen Sie z. B. eine Warnung, wenn die Aufhebung der Bereitstellung von Benutzerkonten eine bestimmte Ebene erreicht, da dies u. U. auf einen Fehler oder einen betriebstechnischen Fehler hinweist, der weitreichende Auswirkungen haben könnte.

  • Jede Automatisierung, die umgebungsübergreifende Aufgaben koordiniert, sollte als System mit umfangreichen Berechtigungen betrieben werden. Dieses System sollte auf der Umgebung mit der höchsten Sicherheit verwaltet und einen Pull aus externen Quellen ausführen, wenn Daten aus anderen Umgebungen erforderlich sind. Datenüberprüfung und Schwellenwerte müssen angewendet werden, um die Systemintegrität beizubehalten. Eine gängige umgebungsübergreifende Aufgabe ist Identity Lifecycle Management zum Entfernen von Identitäten aus allen Umgebungen für einen Mitarbeiter mit beendetem Arbeitsverhältnis.

IT-Dienstverwaltungstools – Organisationen, die IT Service Management-Systeme (ITSM) wie ServiceNow verwenden, sollten Microsoft Entra PIM-Rollenaktivierungseinstellungen konfigurieren, um im Rahmen der Aktivierungszwecke eine Ticketnummer anzufordern.

Ebenso kann Azure Monitor über den ITSM-Connector in ITSM-Systeme integriert werden.

Betriebspraktiken – Minimieren Sie operative Aktivitäten, die direkten Zugriff auf die Umgebung für menschliche Identitäten erfordern. Modellieren Sie sie stattdessen als Azure-Pipelines, die allgemeine Vorgänge ausführen (z. B. Hinzufügen von Kapazität zu einer PaaS-Lösung, Ausführen einer Diagnose usw.) und direkten Zugriff auf die Azure Resource Manager-Schnittstellen zu Notfallszenarien modellieren.

Herausforderungen von Vorgängen

  • Für einige Szenarien ist die Aktivität der Dienstprinzipalüberwachung eingeschränkt.

  • Für Microsoft Entra PIM-Warnungen ist keine API vorhanden. Daher sollten diese PIM-Warnungen regelmäßig überprüft werden.

  • Azure EA Portal bietet keine Überwachungsfunktionen. Daher ist es ratsam, dedizierte Verwaltungskonten zu haben und die Kontoaktivität zu überwachen.

  • MCA bietet keine Überwachungsprotokolle für Abrechnungsaufgaben. Daher ist es ratsam, dedizierte Verwaltungskonten zu haben und die Kontoaktivität zu überwachen.

  • Einige Dienste in Azure, die für den Betrieb der Umgebung erforderlich sind, müssen neu bereitgestellt und in allen Umgebungen neu konfiguriert werden, da sie weder mehrere Mandanten noch mehrere Clouds unterstützen.

  • Es gibt keine vollständige API-Abdeckung für Microsoft Online Services, um Infrastructure-as-Code vollständig zu realisieren. Daher sollten in erster Linie APIs und in ansonsten Portale verwendet werden. Mithilfe dieser Open-Source-Initiative können Sie einen Ansatz ermitteln, der für Ihre Umgebung funktionieren könnte.

  • Es gibt keine programmgesteuerte Funktion zum Ermitteln von Ressourcenmandanten, die über delegierten Abonnementzugriff auf Identitäten in einem verwalteten Mandanten verfügen. Wenn beispielsweise eine E-Mail-Adresse eine Sicherheitsgruppe im contoso.com-Mandanten zum Verwalten von Abonnements im fabrikam.com-Mandanten aktiviert hat, verfügen Administratoren im contoso.com nicht über eine API, um zu ermitteln, ob diese Delegierung stattfand.

  • Die Überwachung bestimmter Kontoaktivitäten (z. B. Notfallkonto, Abrechnungsverwaltungskonto) wird nicht vorkonfiguriert bereitgestellt. Daher sollten Kunden eigene Warnungsregeln erstellen.

  • Die mandantenweite Konfigurationsüberwachung wird nicht vorkonfiguriert bereitgestellt. Daher sollten Kunden eigene Warnungsregeln erstellen.

Nächste Schritte