Grundlagen der Azure-Ressourcenverwaltung

Es ist wichtig, die Struktur und Begriffe zu verstehen, die für Azure-Ressourcen spezifisch sind. Die folgende Abbildung zeigt ein Beispiel für die vier Ebenen des Bereichs, die von Azure bereitgestellt werden:

Begriff

Im Folgenden sind einige der Begriffe aufgeführt, mit denen Sie vertraut sein sollten:

Ressource: Verwaltbares Element, das über Azure verfügbar ist. Virtuelle Computer, Speicherkonten, Web-Apps, Datenbanken und virtuelle Netzwerke sind Beispiele für Ressourcen.

Ressourcengruppe: Ein Container, der verwandte Ressourcen für eine Azure-Lösung enthält, z. B. eine Sammlung von VMs, zugehörige VNets und Lastenausgleichsgeräte, die die Verwaltung durch bestimmte Teams erfordern. Die Ressourcengruppe enthält die Ressourcen, die Sie als Gruppe verwalten möchten. Sie entscheiden in Abhängigkeit davon, was für Ihre Organisation am sinnvollsten ist, welche Ressourcen in eine Ressourcengruppen gehören. Ressourcengruppen können auch verwendet werden, um die Lebenszyklusverwaltung zu unterstützen, indem alle Ressourcen mit gleichzeitiger Lebensdauer gelöscht werden. Dieser Ansatz bietet auch einen Sicherheitsvorteil, da keine Fragmente zurückbleiben, die ausgenutzt werden könnten.

Abonnement: Aus Sicht der Organisationshierarchie ist ein Abonnement ein Abrechnungs- und Verwaltungscontainer von Ressourcen und Ressourcengruppen. Ein Azure-Abonnement hat eine Vertrauensbeziehung zu Microsoft Entra ID. Ein Abonnement vertraut Microsoft Entra ID bei der Authentifizierung von Benutzer*innen, Diensten und Geräten.

Verwaltungsgruppe: Azure-Verwaltungsgruppen bieten eine hierarchische Methode zum Anwenden von Richtlinien und Compliance in verschiedenen den Abonnements übergeordneten Bereichen. Dies kann auf der Ebene der Stammverwaltungsgruppe des Mandanten (höchster Bereich) oder auf niedrigeren Ebenen in der Hierarchie sein. Sie organisieren Abonnements in Containern, die als „Verwaltungsgruppen“ bezeichnet werden, und wenden Ihre Governancebedingungen auf die Verwaltungsgruppen an. Alle Abonnements in einer Verwaltungsgruppe erben automatisch die auf die Verwaltungsgruppe angewendeten Bedingungen. Beachten Sie, dass Richtliniendefinitionen auf eine Verwaltungsgruppe oder ein Abonnement angewendet werden können.

Ressourcenanbieter: Ein Dienst, der Azure-Ressourcen bereitstellt. Ein gängiger Ressourcenanbieter ist beispielsweise Microsoft. Compute, das die VM-Ressource bereitstellt. Microsoft. Storage ist ein weiterer gängiger Ressourcenanbieter.

Resource Manager-Vorlage: Eine JSON-Datei (JavaScript Object Notation), mit der eine oder mehrere Ressourcen zum Bereitstellen einer Ressourcengruppe, eines Abonnements, eines Mandanten oder einer Verwaltungsgruppe definiert werden. Die Vorlage kann zum konsistenten und wiederholten Bereitstellen der Ressourcen verwendet werden. Weitere Informationen finden Sie in der Übersicht über die Vorlagenbereitstellung. Darüber hinaus kann die Bicep-Sprache anstelle von JSON verwendet werden.

Azure-Ressourcenverwaltungsmodell

Jedes Azure-Abonnement ist mit Kontrollen verbunden, die von Azure Resource Manager genutzt werden. Resource Manager ist der Bereitstellungs- und Verwaltungsdienst für Azure. Er hat eine Vertrauensbeziehung mit Microsoft Entra ID für die Identitätsverwaltung für Organisationen und das Microsoft-Konto (Microsoft Account, MSA) für Einzelpersonen. Resource Manager bietet eine Verwaltungsebene, die das Erstellen, Aktualisieren und Löschen von Ressourcen in Ihrem Azure-Abonnement ermöglicht. Mithilfe von Verwaltungsfeatures wie Zugriffssteuerung, Sperren und Tags können Sie Ihre Ressourcen nach der Bereitstellung schützen und organisieren.

Azure Resource Manager ist der Front-End-Dienst, der die REST-APIs hostet, die von PowerShell, dem Azure-Portal oder anderen Clients zum Verwalten von Ressourcen verwendet werden. Wenn ein Client eine Anforderung zur Verwaltung einer bestimmten Ressource sendet, leitet Resource Manager die Anforderung per Proxy an den Ressourcenanbieter weiter, damit sie abgeschlossen werden kann. Wenn ein Client beispielsweise eine Anforderung zur Verwaltung einer VM-Ressource sendet, leitet Resource Manager die Anforderung per Proxy an den Ressourcenanbieter Microsoft.Compute weiter. Resource Manager setzt voraus, dass der Client einen Bezeichner für das Abonnement und für die Ressourcengruppe angibt, um die VM-Ressource zu verwalten.

Bevor eine Anforderung zur Durchführung der Ressourcenverwaltung von Resource Manager ausgeführt werden kann, werden einige Kontrollmechanismen überprüft.

• Überprüfung gültiger Benutzer*innen: Benutzer*innen, die eine Ressource verwalten, müssen über ein Konto in dem Microsoft Entra-Mandanten verfügen, der dem Abonnement der verwalteten Ressource zugeordnet ist.

• Überprüfung der Benutzerberechtigungen: Berechtigungen werden Benutzern über die rollenbasierte Zugriffssteuerung (RBAC) zugewiesen. Mit einer RBAC-Rolle wird ein Satz mit Berechtigungen angegeben, die einem Benutzer für eine bestimmte Ressource zur Verfügung stehen. Mit RBAC können Sie verwalten, welche Benutzer Zugriff auf Azure-Ressourcen haben, welche Aktionen Benutzer für diese Ressourcen ausführen können und auf welche Bereiche sie zugreifen können.

• Azure-Richtlinienüberprüfung: Azure-Richtlinien geben die erlaubten oder explizit verweigerten Vorgänge für eine bestimmte Ressource an. Mithilfe einer Richtlinie kann beispielsweise angegeben werden, dass Benutzer nur einen bestimmten Typ einer VM bereitstellen dürfen (oder nicht).

Im folgenden Diagramm wird das soeben beschriebene Ressourcenmodell zusammengefasst.

Azure Lighthouse: Azure Lighthouse ermöglicht mandantenübergreifende Ressourcenverwaltung. Organisationen können Rollen auf Abonnement- oder Ressourcengruppenebene an Identitäten in einem anderen Mandanten delegieren.

Abonnements, die die delegierte Ressourcenverwaltung mit Azure Lighthouse ermöglichen, verfügen über Attribute, welche die Mandanten-IDs, die Abonnements oder Ressourcengruppen verwalten können, und die Zuordnung zwischen der integrierten RBAC-Rolle im Ressourcenmandanten zu Identitäten im Dienstanbietermandanten angeben. Zur Laufzeit verwendet Azure Resource Manager diese Attribute, um Token zu autorisieren, die vom Mandanten des Dienstanbieters stammen.

Dabei sollte beachtet werden, dass Azure Lighthouse selbst als Azure-Ressourcenanbieter modelliert wird, was bedeutet, dass Aspekte der mandantenübergreifenden Delegierung über Azure-Richtlinien anvisiert werden können.

Microsoft 365 Lighthouse: Microsoft 365 Lighthouse ist ein Administratorportal, mit dessen Hilfe MSPs Geräte, Daten und Benutzer im gewünschten Umfang für kleine und mittlere Geschäftskunden, die Microsoft 365 Business Premium, Microsoft 365 E3 oder Windows 365 Business nutzen, sichern und verwalten können.

Azure-Ressourcenverwaltung mit Microsoft Entra ID

Nachdem Sie das Ressourcenverwaltungsmodell in Azure kennen, gehen wir jetzt kurz auf einige der Funktionen von Microsoft Entra ID ein, die Identitäts- und Zugriffsverwaltung für Azure-Ressourcen bereitstellen können.

Abrechnung

Die Abrechnung ist wichtig für die Ressourcenverwaltung, da einige Abrechnungsrollen mit Ressourcen interagieren bzw. Ressourcen verwalten können. Die Abrechnung funktioniert je nach Art der Vereinbarung mit Microsoft unterschiedlich.

Azure Enterprise Agreements

Azure Enterprise Agreement-Kunden (Azure EA) werden nach Ausführung ihrer kommerziellen Vereinbarung mit Microsoft in das Azure EA Portal eingebunden. Beim Onboarding wird eine Identität einer „Stamm“-Enterprise-Administrator-Abrechnungsrolle zugeordnet. Das Portal stellt eine Hierarchie von Verwaltungsfunktionen bereit:

• Mithilfe von Abteilungen können Sie Kosten in logische Gruppen aufteilen und anschließend auf Abteilungsebene ein Budget oder ein Kontingent festlegen.

• Konten werden zur weiteren Segmentierung von Abteilungen verwendet. Anhand von Konten können Sie Abonnements verwalten und auf Berichte zugreifen. Das EA-Portal kann Microsoft-Konten (MSA) oder Microsoft Entra-Konten (im Portal als „Geschäfts-, Schul- oder Unikonten“ bezeichnet) autorisieren. Identitäten mit der Rolle „Kontobesitzer“ im EA-Portal können Azure-Abonnements erstellen.

Unternehmensabrechnung und Microsoft Entra-Mandanten

Wenn ein Kontobesitzer ein Azure-Abonnement innerhalb eines Konzernvertrags erstellt, wird die Identitäts- und Zugriffsverwaltung des Abonnements wie folgt konfiguriert:

• Das Azure-Abonnement ist dem Microsoft Entra-Mandanten des Kontobesitzers bzw. der Kontobesitzerin zugeordnet.

• Dem Kontobesitzer, der das Abonnement erstellt hat, werden die Rollen „Dienstadministrator“ und „Kontoadministrator“ zugewiesen. (Das Azure EA Portal weist Azure Service Manager (ASM) oder „klassische“ Rollen zum Verwalten von Abonnements zu. Weitere Informationen finden Sie unter Azure Resource Manager und klassische Bereitstellung: Grundlegendes zu Bereitstellungsmodellen und zum Status von Ressourcen.)

Ein Konzernvertrag bzw. Enterprise Agreement kann für die Unterstützung mehrerer Mandanten konfiguriert werden, indem der Authentifizierungstyp „Geschäfts-, Schul- oder Unikonto mandantenübergreifend“ im Azure EA Portal festgelegt wird. Angesichts der obigen Informationen können Organisationen mehrere Konten für jeden Mandanten und mehrere Abonnements für jedes Konto festlegen, wie im folgenden Diagramm dargestellt.

Es sollte unbedingt beachtet werden, dass die oben beschriebene Standardkonfiguration dem Azure EA-Kontobesitzer Berechtigungen gewährt, um die Ressourcen in allen Abonnements zu verwalten, die er erstellt hat. Bei Abonnements mit Produktionsworkloads sollten Sie erwägen, die Abrechnung und Ressourcenverwaltung zu entkoppeln, indem Sie den Dienstadministrator des Abonnements direkt nach der Erstellung ändern.

Zur weiteren Entkopplung und um zu vermeiden, dass der Kontobesitzer erneut Dienstadministratorzugriff auf das Abonnement erhält, kann der Mandant des Abonnements nach der Erstellung geändert werden. Wenn Kontobesitzer*innen nicht über entsprechende Benutzerobjekte in dem Microsoft Entra-Mandanten verfügen, in den das Abonnement verschoben wird, können sie die Rolle „Dienstbesitzer“ nicht wieder erhalten.

Weitere Informationen finden Sie unter Azure-Rollen, Microsoft Entra-Rollen und Administratorrollen für klassische Abonnements.

Microsoft-Kundenvereinbarung

Kunden, die mit einer Microsoft-Kundenvereinbarung (MCA) registriert sind, verfügen über ein anderes Abrechnungsverwaltungssystem mit eigenen Rollen.

Ein Abrechnungskonto für die Microsoft-Kundenvereinbarung enthält ein oder mehrere Abrechnungsprofile zur Verwaltung von Rechnungen und Zahlungsmethoden. Jedes Abrechnungsprofil enthält einen oder mehrere Rechnungsabschnitte, mit denen die Kosten auf der Rechnung des Abrechnungsprofils organisiert werden können.

In einer Microsoft-Kundenvereinbarung gehören Abrechnungsrollen zu einem einzelnen Microsoft Entra-Mandanten. Um Abonnements für mehrere Mandanten bereitzustellen, müssen die Abonnements zunächst in dem Microsoft Entra-Mandanten erstellt werden, der zur MCA gehört. Dann können sie geändert werden. Im folgenden Diagramm wurden die Abonnements für die Vorproduktionsumgebung der Unternehmens-IT nach der Erstellung in den ContosoSandbox-Mandanten verschoben.

RBAC und Rollenzuweisungen in Azure

Im Abschnitt zu den Grundlagen von Microsoft Entra-Grundlagen haben Sie erfahren, dass Azure RBAC das Autorisierungssystem ist, das eine differenzierte Zugriffsverwaltung für Azure-Ressourcen ermöglicht und viele integrierte Rollen umfasst. Sie können benutzerdefinierte Rollen erstellen und Rollen in verschiedenen Bereichen zuweisen. Berechtigungen werden erzwungen, indem Sie RBAC-Rollen Objekten zuweisen, die Zugriff auf Azure-Ressourcen anfordern.

Microsoft Entra-Rollen funktionieren auf ähnliche Weise wie die rollenbasierte Zugriffssteuerung in Azure. Der Unterschied zwischen diesen beiden rollenbasierten Zugriffssteuerungssystemen besteht darin, dass Azure RBAC zur Steuerung des Zugriffs auf Azure-Ressourcen oder VMs die Azure-Ressourcenverwaltung verwendet, Microsoft Entra-Rollen dagegen den Zugriff auf Microsoft Entra ID, Anwendungen und Microsoft-Dienste wie Office 365 steuern.

Sowohl Microsoft Entra-Rollen als auch Azure RBAC-Rollen werden in Microsoft Entra Privileged Identity Management integriert, um Richtlinien für Just-in-Time-Aktivierungen wie z. B. Genehmigungsworkflows und MFA-Vorgänge zu aktivieren.

ABAC und Rollenzuweisungen in Azure

Die attributbasierte Zugriffssteuerung (Attribute-Based Access Control, ABAC) ist ein Autorisierungssystem, bei dem der Zugriff auf der Grundlage von Attributen definiert wird, die Sicherheitsprinzipalen, Ressourcen und der Umgebung zugeordnet sind. Mit ABAC können Sie einem Sicherheitsprinzipal basierend auf Attributen Zugriff auf eine Ressource gewähren. Bei Azure ABAC handelt es sich um die Implementierung von ABAC für Azure.

Azure ABAC baut auf Azure RBAC auf und fügt Rollenzuweisungsbedingungen auf der Grundlage von Attributen im Kontext bestimmter Aktionen hinzu. Eine Rollenzuweisungsbedingung ist eine zusätzliche Überprüfung, die Sie Ihrer Rollenzuweisung optional hinzufügen können, um eine präzisere Zugriffssteuerung zu ermöglichen. Eine Bedingung dient zum Filtern von Berechtigungen, die im Rahmen der Rollendefinition und Rollenzuweisung gewährt wurden. So können Sie beispielsweise eine Bedingung hinzufügen, die festgelegt, dass ein Objekt über ein bestimmtes Tag verfügen muss, damit das Objekt gelesen werden kann. Bedingungen können nicht dazu verwendet werden, den Zugriff auf bestimmte Ressourcen explizit zu verweigern.

Bedingter Zugriff

Der bedingte Zugriff in Microsoft Entra kann verwendet werden, um den Zugriff auf Azure-Verwaltungsendpunkte zu verwalten. Richtlinien für bedingten Zugriff können auf die Windows Azure Dienstverwaltungs-API Cloud-App angewendet werden, um u. a. folgende Azure-Ressourcenverwaltungsendpunkte zu schützen:

• Azure Resource Manager-Anbieter (Dienste)

• Azure Resource Manager-APIs

• Azure PowerShell

• Azure CLI

• Azure-Portal

Administrator*innen können z. B. eine Richtlinie für bedingten Zugriff konfigurieren, die dafür sorgt, dass Benutzer*innen sich nur von genehmigten Standorten aus beim Azure-Portal anmelden können, und die zudem entweder eine Multi-Faktor-Authentifizierung (MFA) oder ein in die Microsoft Entra-Domäne eingebundenes hybrides Gerät erfordert.

Von Azure verwaltete Identitäten

Eine gängige Herausforderung beim Erstellen von Cloudanwendungen ist die Verwaltung der Anmeldeinformationen im Code, die für die Authentifizierung bei Clouddiensten erforderlich sind. Der Schutz dieser Anmeldeinformationen ist eine wichtige Aufgabe. Im Idealfall werden die Anmeldeinformationen nie auf Entwicklerarbeitsstationen angezeigt und auch nicht in die Quellcodeverwaltung eingecheckt. Verwaltete Identitäten für Azure-Ressourcen stellen für Azure-Dienste eine automatisch verwaltete Identität in Microsoft Entra ID bereit. Sie können diese Identität für die Authentifizierung bei jedem Dienst verwenden, der die Microsoft Entra-Authentifizierung unterstützt. Hierfür müssen keine Anmeldeinformationen im Code enthalten sein.

Es gibt zwei Arten von verwalteten Identitäten:

• Eine vom System zugewiesene verwaltete Identität wird direkt für eine Azure-Ressource aktiviert. Wenn die Ressource aktiviert ist, erstellt Azure eine Identität für die Ressource im vertrauenswürdigen Microsoft Entra-Mandanten des zugehörigen Abonnements. Nach dem Erstellen der Identität werden die Anmeldeinformationen in der Ressource bereitgestellt. Der Lebenszyklus einer systemseitig zugewiesenen Identität ist direkt an die Azure-Ressource gebunden. Wenn die Ressource gelöscht wird, bereinigt Azure automatisch die Anmeldeinformationen und die Identität in Microsoft Entra ID.

• Eine vom Benutzer zugewiesene verwaltete Identität wird als eigenständige Azure-Ressource erstellt. Azure erstellt im Microsoft Entra-Mandanten eine Identität, der das Abonnement, dem die Ressource zugeordnet ist, vertraut. Nachdem die Identität erstellt wurde, kann sie einer oder mehreren Azure-Ressourcen zugewiesen werden. Der Lebenszyklus einer vom Benutzer zugewiesenen Identität wird getrennt vom Lebenszyklus der Azure-Ressourcen verwaltet, denen sie zugewiesen ist.

Intern sind verwaltete Identitäten eine Sonderform von Dienstprinzipalen, die nur von bestimmten Azure-Ressourcen verwendet werden können. Wenn die verwaltete Identität gelöscht wird, wird automatisch auch der entsprechende Dienstprinzipal entfernt. Beachten Sie, dass die Autorisierung von Graph-API-Berechtigungen nur über PowerShell erfolgen kann. Es sind also nicht alle Features der verwalteten Identität über die Portal-UI zugänglich.

Microsoft Entra Domain Services

Microsoft Entra Domain Services stellt eine verwaltete Domäne bereit, um die Authentifizierung für Azure-Workloads über Legacyprotokolle zu ermöglichen. Unterstützte Server werden aus einer lokalen AD DS-Gesamtstruktur verschoben und in eine verwaltete Microsoft Entra Domain Services-Domäne eingebunden. Sie verwenden weiterhin Legacyprotokolle für die Authentifizierung (z. B. Kerberos-Authentifizierung).

Azure AD B2C-Verzeichnisse und Azure

Ein Azure AD B2C-Mandant ist mit einem Azure-Abonnement für Abrechnungs- und Kommunikationszwecke verknüpft. Azure AD B2C-Mandanten verfügen über eine eigenständige Rollenstruktur im Verzeichnis, die von den privilegierten Azure RBAC-Rollen des Azure-Abonnements unabhängig ist.

Wenn der Azure AD B2C-Mandant erstmals bereitgestellt wird, muss der Benutzer, der den B2C-Mandanten erstellt, über Mitwirkende- oder Besitzerberechtigungen im Abonnement verfügen. Später können andere Konten erstellt und Verzeichnisrollen zugewiesen werden. Weitere Informationen finden Sie unter Übersicht über die rollenbasierte Zugriffssteuerung in Microsoft Entra ID.

Beachten Sie unbedingt, dass die Besitzer*innen und Mitwirkenden des verknüpften Microsoft Entra-Abonnements die Verknüpfung zwischen dem Abonnement und dem Verzeichnis entfernen können, was sich auf die laufende Abrechnung der Azure AD B2C-Nutzung auswirkt.

Identitätsbezogene Überlegungen für IaaS-Lösungen in Azure

In diesem Szenario werden Identitätsisolationsanforderungen von Organisationen für IaaS-Arbeitslasten (Infrastructure-as-a-Service) behandelt.

Es gibt drei wichtige Optionen für die Isolationsverwaltung von IaaS-Workloads:

• Mit eigenständigen Active Directory Domain Services (AD DS) verknüpfte VMs

• In Microsoft Entra Domain Services eingebundene VMs

• Anmelden bei VMs in Azure mithilfe der Microsoft Entra-Authentifizierung

Ein wichtiges Konzept, das mit den ersten beiden Optionen adressiert werden soll, besteht darin, dass es zwei Identitätsbereiche gibt, die an diesen Szenarien beteiligt sind.

• Wenn Sie sich über das Remotedesktopprotokoll (RDP) bei einer Azure-VM mit Windows Server anmelden, verwenden Sie dazu in der Regel Ihre Domänenanmeldeinformationen. Dabei wird eine Kerberos-Authentifizierung bei einem lokalen AD DS-Domänencontroller oder Microsoft Entra Domain Services ausgeführt. Wenn der Server nicht in die Domäne eingebunden ist, kann ein lokales Konto für die Anmeldung bei den VMs verwendet werden.

• Wenn Sie sich beim Azure-Portal anmelden, um eine VM zu erstellen oder zu verwalten, authentifizieren Sie sich bei Microsoft Entra ID (möglicherweise mit den gleichen Anmeldeinformationen, sofern Sie die richtigen Konten synchronisiert haben). Dies kann zu einer Authentifizierung bei Ihren Domänencontrollern führen, falls Sie Active Directory-Verbunddienste (AD FS) oder Passthrough-Authentifizierung verwenden.

Mit eigenständigen Active Directory Domain Services verknüpfte VMs

AD DS ist der Windows Server-basierte Verzeichnisdienst, den Organisationen größtenteils für lokale Identitätsdienste übernommen haben. AD DS kann bereitgestellt werden, wenn eine Anforderung zum Bereitstellen von IaaS-Workloads in Azure vorhanden ist, die die Identitätsisolation von AD DS-Administratoren und Benutzern in einer anderen Gesamtstruktur erfordern.

In diesem Szenario müssen die folgenden Überlegungen angestellt werden:

AD DS-Domänencontroller: Mindestens zwei AD DS-Domänencontroller müssen bereitgestellt werden, um sicherzustellen, dass Authentifizierungsdienste hoch verfügbar sind und ausgeführt werden können. Weitere Informationen finden Sie unter AD DS-Entwurf und -Planung.

AD DS-Entwurf und -Planung: Eine neue AD DS-Gesamtstruktur muss mit den folgenden ordnungsgemäß konfigurierten Diensten erstellt werden:

• AD DS Domain Name Services (DNS) – AD DS DNS muss für die relevanten Zonen innerhalb von AD DS konfiguriert werden, um sicherzustellen, dass die Namensauflösung für Server und Anwendungen ordnungsgemäß funktioniert.

• AD DS-Websites und -Dienste: Diese Dienste müssen konfiguriert werden, um sicherzustellen, dass Anwendungen eine geringe Latenz aufweisen und auf Domänencontroller zugreifen können. Die relevanten virtuellen Netzwerke, Subnetze und Rechenzentren, in denen sich Server befinden, sollten in Sites und Diensten konfiguriert werden.

• AD DS FSMOs: Die erforderlichen FSMO-Rollen (Flexible Single Master Operation) sollten überprüft und den entsprechenden AD DS-Domänencontrollern zugewiesen werden.

• AD DS-Domänenbeitritt: Alle Server (ausgenommen „Jumpboxes“), die AD DS zur Authentifizierung, Konfiguration und Verwaltung erfordern, müssen in die isolierte Gesamtstruktur eingebunden werden.

• AD DS Gruppenrichtlinie (GPO) : AD DS-GPOs müssen konfiguriert werden, um sicherzustellen, dass die Konfiguration die Sicherheitsanforderungen erfüllt und auf allen in die Gesamtstruktur und in Domänen eingebundenen Computern standardisiert wird.

• AD DS-Organisationseinheiten (OU): AD DS-OUs müssen definiert werden, um die Gruppierung von AD DS-Ressourcen in logische Verwaltungs- und Konfigurationssilos für Zwecke der Konfigurationsverwaltung und -anwendung sicherzustellen.

• Rollenbasierte Zugriffssteuerung: RBAC muss für die Verwaltung und den Zugriff auf Ressourcen definiert werden, die in diese Gesamtstruktur eingebunden sind. Dies umfasst u. a.:

  • AD DS-Gruppen: Gruppen müssen erstellt werden, um geeignete Berechtigungen für Benutzer auf AD DS-Ressourcen anzuwenden.

  • Verwaltungskonten: Wie zu Beginn dieses Abschnitts erwähnt, sind für die Verwaltung dieser Lösung zwei Verwaltungskonten erforderlich.

    • Ein AD DS-Verwaltungskonto mit den geringsten erforderlichen Berechtigungen zum Ausführen der Verwaltung, die in AD DS und auf in Domänen eingebundenen Servern erforderlich ist.

    • Ein Microsoft Entra-Verwaltungskonto für Azure-Portalzugriff zum Verbinden, Verwalten und Konfigurieren von VMs, VNets, Netzwerksicherheitsgruppen und anderen erforderlichen Azure-Ressourcen.

  • AD DS-Benutzerkonten: Relevante Benutzerkonten müssen bereitgestellt und den korrekten Gruppen hinzugefügt werden, um Benutzern den Zugriff auf Anwendungen zu ermöglichen, die von dieser Lösung gehostet werden.

Virtuelle Netzwerke (VNets): Konfigurationsleitfaden

• IP-Adresse des AD DS-Domänencontrollers: Die Domänencontroller sollten innerhalb des Betriebssystems nicht mit statischen IP-Adressen konfiguriert werden. Die IP-Adressen sollten im Azure-VNet reserviert werden, um sicherzustellen, dass sie immer gleich bleiben, und Domänencontroller sollten für die Verwendung von DHCP konfiguriert werden.

• VNet-DNS-Server: DNS-Server müssen in VNets konfiguriert werden, die Teil dieser isolierten Lösung sind, um auf die Domänencontroller zu verweisen. Dies ist erforderlich, um sicherzustellen, dass Anwendungen und Server die erforderlichen AD DS-Dienste oder andere Dienste, die in die AD DS-Gesamtstruktur eingebunden sind, auflösen können.

• Netzwerksicherheitsgruppen (NSGs): Die Domänencontroller sollten sich in ihrem eigenen VNet oder Subnetz befinden, deren NSGs so definiert sind, dass sie nur Zugriff auf Domänencontroller von erforderlichen Servern zulassen (z. B. in Domänen eingebundene Computer oder Jumpboxes). Jumpboxes sollten einer Anwendungssicherheitsgruppe (ASG) hinzugefügt werden, um die Erstellung und Verwaltung von NSG zu vereinfachen.

Herausforderungen: In der folgenden Liste werden wichtige Herausforderungen bei der Verwendung dieser Option für die Identitätsisolation hervorgehoben:

• Eine zusätzliche AD DS-Gesamtstruktur zum Verwalten und Überwachen, was zu mehr Arbeit für das IT-Team führt.

• Weitere Infrastruktur kann für die Verwaltung von Patching- und Softwarebereitstellungen erforderlich sein. Organisationen sollten die Bereitstellung von Azure-Updateverwaltung, Gruppenrichtlinie (GPO) oder System Center Configuration Manager (SCCM) in Betracht ziehen, um diese Server zu verwalten.

• Zusätzliche Anmeldeinformationen, die sich Benutzer merken und für den Zugriff auf Ressourcen verwenden sollten.

In Microsoft Entra Domain Services eingebundene VMs

Wenn IaaS-Workloads in Azure bereitgestellt werden müssen, für die eine Identitätsisolierung von AD DS-Administrator*innen und -Benutzer*innen in einer anderen Gesamtstruktur erforderlich ist, kann eine verwaltete Microsoft Entra Domain Services-Domäne bereitgestellt werden. Microsoft Entra Domain Services ist ein Dienst, der eine verwaltete Domäne bereitstellt, um die Authentifizierung für Azure-Workloads über Legacyprotokolle zu ermöglichen. Dadurch wird eine isolierte Domäne ohne die technische Komplexität des Erstellens und Verwaltens Ihres eigenen AD DS bereitgestellt. Es müssen folgende Überlegungen angestellt werden.

Verwaltete Microsoft Entra Domain Services-Domäne: Für jeden Microsoft Entra-Mandanten kann nur eine verwaltete Microsoft Entra Domain Services-Domäne bereitgestellt werden, die an ein einzelnes VNet gebunden ist. Dieses VNet sollte den Hub für die Microsoft Entra Domain Services-Authentifizierung bilden. Aus dieser Nabe können „Speichen“ erstellt und verknüpft werden, um die Legacy-Authentifizierung für Server und Anwendungen zu ermöglichen. Die Spokes sind zusätzliche VNets, in denen sich in Microsoft Entra Domain Services eingebundene Server befinden und die über Azure-Netzwerkgateways oder VNet-Peering mit dem Hub verbunden sind.

Standort für die verwaltete Domäne: Beim Bereitstellen einer verwalteten Microsoft Entra Domain Services-Domäne muss ein Standort festgelegt werden. Der Speicherort ist eine physische Region (Rechenzentrum), in der die verwaltete Domäne bereitgestellt wird. Folgendes wird empfohlen:

• Verwenden Sie nach Möglichkeit einen Standort, der sich in geografischer Nähe zu den Servern und Anwendungen befindet, die Microsoft Entra Domain Services-Dienste erfordern.

• Erwägen Sie Regionen, die Verfügbarkeitszonen für hohe Verfügbarkeitsanforderungen bereitstellen. Weitere Informationen finden Sie unter Regionen und Verfügbarkeitszonen in Azure.

Objektbereitstellung: Microsoft Entra Domain Services synchronisiert Identitäten aus der Microsoft Entra ID-Instanz, die dem Abonnement zugeordnet ist, in dem Microsoft Entra Domain Services bereitgestellt ist. Beachten Sie zudem, dass der Lebenszyklus dieser Identitäten sich ebenfalls in Microsoft Entra Domain Services widerspiegeln kann, sofern für die zugehörige Microsoft Entra ID-Instanz eine Synchronisierung mit Microsoft Entra Connect (Szenario mit Benutzergesamtstruktur) eingerichtet ist. Dieser Dienst verfügt über zwei Modi, die für die Bereitstellung von Benutzer- und Gruppenobjekten aus Microsoft Entra ID verwendet werden können.

• Alle: Alle Benutzer*innen und Gruppen werden von Microsoft Entra ID mit Microsoft Entra Domain Services synchronisiert.

• Bereichsbezogen: Nur Benutzer*innen im Bereich einer Gruppe werden von Microsoft Entra ID mit Microsoft Entra Domain Services synchronisiert.

Bei der ersten Bereitstellung von Microsoft Entra Domain Services wird eine automatische unidirektionale Synchronisierung konfiguriert, um die Objekte aus Microsoft Entra ID zu replizieren. Diese unidirektionale Synchronisierung wird weiterhin im Hintergrund ausgeführt, um die verwaltete Microsoft Entra Domain Services-Domäne mit allen Änderungen aus Microsoft Entra ID auf dem neuesten Stand zu halten. Es erfolgt keine Synchronisierung von Microsoft Entra Domain Services zurück zu Microsoft Entra ID. Weitere Informationen finden Sie unter Synchronisieren von Objekten und Anmeldeinformationen in einer von Microsoft Entra Domain Services verwalteten Domäne.

Beachten Sie auch, dass die verwaltete Microsoft Entra Domain Services-Domäne gelöscht, neu erstellt und konfiguriert werden muss, wenn Sie den Typ der Synchronisierung von „Alle“ in „Bereichsbezogen“ (oder umgekehrt) ändern müssen. Darüber hinaus sollten Organisationen als Best Practice die Verwendung der „bereichsbezogenen“ Bereitstellung in Erwägung ziehen, um die Identitäten auf nur diejenigen zu reduzieren, die Zugriff auf Microsoft Entra Domain Services-Ressourcen benötigen.

Gruppenrichtlinienobjekte (GPOs): Um GPOs in einer verwalteten Microsoft Entra Domain Services-Domäne zu konfigurieren, müssen Sie Tools für die Gruppenrichtlinienverwaltung auf einem Server verwenden, der in die verwaltete Microsoft Entra Domain Services-Domäne eingebunden wurde. Weitere Informationen finden Sie unter Verwalten von Gruppenrichtlinien in einer von Microsoft Entra Domain Services verwalteten Domäne.

Secure LDAP: Microsoft Entra Domain Services stellt einen Secure LDAP-Dienst bereit, der von Anwendungen verwendet werden kann, die ihn benötigen. Diese Einstellung ist standardmäßig deaktiviert. Zum Aktivieren von Secure LDAP muss ein Zertifikat hochgeladen werden. Außerdem muss die Netzwerksicherheitsgruppe, die das VNet schützt, in dem Microsoft Entra Domain Services bereitgestellt wurde, Verbindungen mit den verwalteten Microsoft Entra Domain Services-Domänen über Port 636 zulassen. Weitere Informationen finden Sie unter Konfigurieren von Secure LDAP für eine von Microsoft Entra Domain Services verwaltete Domäne.

Verwaltung: Zum Ausführen von Verwaltungsaufgaben für Microsoft Entra Domain Services (z. B. das Einbinden von Computern in Domänen oder das Bearbeiten von GPOs) muss das für diese Aufgabe verwendete Konto Teil der Microsoft Entra DC-Administratorengruppe sein. Konten, die Mitglieder dieser Gruppe sind, können sich nicht direkt bei Domänencontrollern anmelden, um Verwaltungsaufgaben auszuführen. Stattdessen erstellen Sie eine Verwaltungs-VM, die in die verwaltete Microsoft Entra Domain Services-Domäne eingebunden wird, und installieren dann die regulären AD DS-Verwaltungstools. Weitere Informationen finden Sie unter Verwaltungskonzepte für Benutzerkonten, Kennwörter und die Verwaltung in Microsoft Entra Domain Services.

Kennworthashes: Für die Authentifizierung mit Microsoft Entra Domain Services müssen die Kennworthashes für alle Benutzer*innen in einem Format vorliegen, das für die Authentifizierung über NTLM (NT LAN Manager) und Kerberos geeignet ist. Um sicherzustellen, dass die Authentifizierung mit Microsoft Entra Domain Services wie erwartet funktioniert, müssen die folgenden Voraussetzungen erfüllt sein.

• Mit Microsoft Entra Connect (über AD DS) synchronisierte Benutzer*innen: Die Legacy-Kennworthashes müssen von der lokalen AD DS-Instanz mit Microsoft Entra ID synchronisiert werden.

• In Microsoft Entra ID erstellte Benutzer*innen: Die Kennwörter dieser Benutzer*innen müssen zurückgesetzt werden, damit die richtigen Hashes für die Verwendung mit Microsoft Entra Domain Services generiert werden. Weitere Informationen finden Sie unter Aktivieren der Synchronisierung von Kennworthashes.

Netzwerk: Da Microsoft Entra Domain Services in einem Azure-VNet bereitgestellt wird, müssen Sie überlegen, wie Sie sicherstellen können, dass Server und Anwendungen geschützt sind und ordnungsgemäß auf die verwaltete Domäne zugreifen können. Weitere Informationen finden Sie unter Überlegungen zum Entwurf virtueller Netzwerke und Konfigurationsoptionen für Microsoft Entra Domain Services.

• Microsoft Entra Domain Services muss in einem eigenen Subnetz bereitgestellt werden – verwenden Sie kein vorhandenes Subnetz oder Gatewaysubnetz.

• Netzwerksicherheitsgruppe (NSG): Während der Bereitstellung einer verwalteten Microsoft Entra Domain Services-Domäne wird eine Netzwerksicherheitsgruppe erstellt. Diese Netzwerksicherheitsgruppe enthält die erforderlichen Regeln für eine korrekte Dienstkommunikation. Erstellen oder verwenden Sie keine bestehende Netzwerksicherheitsgruppe mit Ihren eigenen benutzerdefinierten Regeln.

• Microsoft Entra Domain Services erfordert drei bis fünf IP-Adressen: Stellen Sie sicher, dass Ihr Subnetz-IP-Adressbereich diese Anzahl von Adressen bereitstellen kann. Eine Einschränkung der verfügbaren IP-Adressen kann verhindern, dass Microsoft Entra Domain Services zwei Domänencontroller verwaltet.

• VNet-DNS-Server: Wie zuvor im Modell mit Hub und Spokes beschrieben, ist es wichtig, dass das DNS in den VNets ordnungsgemäß konfiguriert ist. So wird sichergestellt, dass Server, die in die verwaltete Microsoft Entra Domain Services-Domäne eingebunden werden, über die richtigen DNS-Einstellungen verfügen, um die verwaltete Microsoft Entra Domain Services-Domäne aufzulösen. Jedes VNet verfügt über einen DNS-Servereintrag, der während des Abrufen einer IP-Adresse an Server übergeben wird. Bei diesen DNS-Einträgen muss es sich um die IP-Adressen der verwalteten Microsoft Entra Domain Services-Domäne handeln. Weitere Informationen finden Sie unter Aktualisieren der DNS-Einstellungen für das virtuelle Azure-Netzwerk.

Herausforderungen: In der folgenden Liste werden wichtige Herausforderungen bei der Verwendung dieser Option für die Identitätsisolation hervorgehoben.

• Einige Microsoft Entra Domain Services-Konfigurationen können nur von einem in Microsoft Entra Domain Services eingebundenen Server verwaltet werden.

• Für jeden Microsoft Entra-Mandanten kann nur eine verwaltete Microsoft Entra Domain Services-Domäne bereitgestellt werden. Wie in diesem Abschnitt beschrieben, empfiehlt sich das Modell mit Hub und Spokes zur Bereitstellung der Microsoft Entra Domain Services-Authentifizierung bei Diensten in anderen VNets.

• Weitere Infrastruktur kann für die Verwaltung von Patching- und Softwarebereitstellungen erforderlich sein. Organisationen sollten die Bereitstellung von Azure-Updateverwaltung, Gruppenrichtlinie (GPO) oder System Center Configuration Manager (SCCM) in Betracht ziehen, um diese Server zu verwalten.

Bei diesem isolierten Modell wird davon ausgegangen, dass keine Verbindung mit dem VNet besteht, in dem die verwaltete Microsoft Entra Domain Services-Domäne im Unternehmensnetzwerk von Kund*innen gehostet wird, und dass keine Vertrauensstellungen mit anderen Gesamtstrukturen konfiguriert sind. Es sollte ein Jumpbox- oder Verwaltungsserver erstellt werden, um einen Punkt zu schaffen, an dem Microsoft Entra Domain Services verwaltet werden kann.

Anmelden bei VMs in Azure mithilfe der Microsoft Entra-Authentifizierung

Wenn IaaS-Workloads in Azure bereitgestellt werden müssen, für die eine Identitätsisolierung erforderlich ist, besteht die letzte Option in diesem Szenario darin, für die Anmeldung bei Servern Microsoft Entra ID zu verwenden. Dies bietet die Möglichkeit, Microsoft Entra ID zum Identitätsbereich für Authentifizierungszwecke zu machen. Die Isolierung der Identitäten lässt sich durch Bereitstellung der Server im relevanten Abonnement erreichen, das mit dem erforderlichen Microsoft Entra-Mandanten verknüpft ist. Es müssen folgende Überlegungen angestellt werden.

Unterstützte Betriebssysteme: Die Anmeldung bei VMs in Azure über die Microsoft Entra-Authentifizierung wird derzeit unter Windows und Linux unterstützt. Weitere Einzelheiten zu unterstützten Betriebssystemen finden Sie in der Dokumentation für Windows und Linux.

Anmeldeinformationen: Einer der wichtigsten Vorteile der Anmeldung bei VMs in Azure über die Microsoft Entra-Authentifizierung ist die Möglichkeit, dieselben verbundbezogenen oder verwalteten Microsoft Entra-Anmeldeinformationen zu verwenden, die Sie normalerweise für den Zugriff auf Microsoft Entra-Dienste zum Anmelden bei der VM verwenden.

Netzwerkanforderungen: Diese VMs müssen für die Authentifizierung auf Microsoft Entra ID zugreifen. Daher müssen Sie sicherstellen, dass die Netzwerkkonfiguration der VMs ausgehenden Zugriff auf Microsoft Entra-Endpunkte an Port 443 zulassen. Weitere Informationen finden Sie in der Dokumentation für Windows und Linux.

Rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC): Es stehen zwei RBAC-Rollen zur Verfügung, um den entsprechenden Zugriff auf diese VMs bereitzustellen. Diese RBAC-Rollen können über das Azure-Portal oder über die Azure Cloud Shell konfiguriert werden. Weitere Informationen finden Sie unter Konfigurieren von Rollenzuweisungen für die VM.

• Anmeldung als VM-Administrator: Benutzer, denen diese Rolle zugewiesen ist, können sich mit Administratorberechtigungen bei einer Azure-VM anmelden.

• Anmeldung als VM-Benutzer: Benutzer, denen diese Rolle zugewiesen ist, können sich mit regulären Benutzerberechtigungen bei einer Azure-VM anmelden.

Bedingter Zugriff: Ein wichtiger Vorteil der Verwendung von Microsoft Entra ID für die Anmeldung bei Azure-VMs ist die Möglichkeit, bedingten Zugriff als Teil des Anmeldeprozesses zu erzwingen. Dadurch können Organisationen die Erfüllung von Bedingungen verlangen, bevor sie den Zugriff auf die VM zulassen, und Multi-Faktor-Authentifizierung verwenden, um eine starke Authentifizierung bereitzustellen. Weitere Informationen finden Sie unter Verwenden von bedingtem Zugriff.

Herausforderungen: In der folgenden Liste werden wichtige Herausforderungen bei der Verwendung dieser Option für die Identitätsisolation hervorgehoben.

• Keine zentrale Verwaltung oder Konfiguration von Servern. Beispielsweise gibt es keine Gruppenrichtlinie, die auf eine Gruppe von Servern angewendet werden kann. Organisationen sollten die Bereitstellung der Updateverwaltung in Azure in Betracht ziehen, um Patching und Updates dieser Server zu verwalten.

• Nicht geeignet für Anwendungen mit mehreren Ebenen, die eine Authentifizierung mit lokalen Mechanismen wie der integrierten Windows-Authentifizierung auf diesen Servern oder Diensten erfordern. Wenn dies eine Anforderung für die Organisation ist, empfiehlt es sich, das Szenarien mit eigenständigen Active Directory Domain Services oder das in diesem Abschnitt beschriebenen Microsoft Entra Domain Services-Szenario zu erkunden.

Für dieses isolierte Modell wird davon ausgegangen, dass keine Verbindung mit dem VNet besteht, das die VMs über das Unternehmensnetzwerk des Kunden hosten. Es sollte ein Jumpbox- oder Verwaltungsserver erstellt werden, um einen Punkt zu schaffen, von dem aus diese Server verwaltet werden können.

Nächste Schritte

• Einführung in die delegierte Verwaltung und isolierte Umgebungen

• Grundlagen von Microsoft Entra

• Ressourcenisolation in einem einzelnen Mandanten

• Ressourcenisolation mit mehreren Mandanten

• bewährten Methoden