Identitäts- und Zugriffsverwaltung mit Azure Arc-fähigen Servern

Die Verwaltung der Identität für Server dreht sich traditionell um Active Directory: Server sind domänenverbunden, Administratoren erhalten Domänenkonten, die über Domänengruppen zu lokalen Administratoren hinzugefügt werden, und Windows-Einstellungen werden mithilfe von Gruppenrichtlinien verwaltet. Im Cloudverwaltungsmodell wird Microsoft Entra zum Eckpfeiler der Identität und des Zugriffs, während Active Directory (AD) weiterhin für die App-Authentifizierung und ältere Protokolle auf lokalen Windows-Computern verwendet werden kann.

Cloud-native Identität in der Serververwaltung wird mithilfe von Microsoft Entra für die Authentifizierung von Administratoren und den Servern selbst erreicht. Auf lokale AD-domänenverbundene Server kann weiterhin über cloudeigene Windows-Geräte (Arbeitsstation) oder Benutzer auf diesen Geräten zugegriffen werden. Über Microsoft Entra erhalten Sie einheitliche Anmeldeinformationen, da Microsoft Entra-ID virtuelle Computer (VMs), Arc-fähige Server, Office 365 und mehr verwalten kann. Features wie mehrstufige Authentifizierung (MFA) und bedingter Zugriff verbessern die Sicherheit. Server in Ihrer Hybridumgebung können das Identitätssystem von Azure verwenden, um sicher auf Ressourcen zuzugreifen. Mit diesen Vorteilen können Sie den Zeitaufwand für die Wartung von Dienstkonten reduzieren oder lokale Administratorrechte pro Computer gewähren. Es ist ein Übergang im Denken, aber einer, der sich an einem vollständig cloudverwalteten Ökosystem richtet.

Sehen wir uns an, wie sich die Welt eines Systemadministrators mit den Vorteilen von Microsoft Entra ändert.

Microsoft Entra-Integration

Microsoft Entra ID ist ein cloudbasierter Identitätsdienst. Im Gegensatz zu Active Directory Domain Services (AD DS) ist Die Microsoft Entra-ID nicht in Organisationseinheiten strukturiert und konzentriert sich nicht auf die Kerberos-Authentifizierung. Stattdessen verwaltet Microsoft Entra ID Benutzeridentitäten, Apps und Zugriff auf Microsoft-Ressourcen, einschließlich Azure, Microsoft 365 und andere Anwendungen und Betriebssysteme, die Microsoft Entra ID unterstützen.

Server selbst "beitreten" die Microsoft Entra-ID nicht so, wie sie einer Domäne beitreten. Stattdessen wird ein Arc-fähiger Server mit einem Azure-Mandanten verknüpft, der von microsoft Entra-ID gesteuert wird, wenn er zuerst eine Verbindung mit Azure herstellt. Mit Der Microsoft Entra-ID können Benutzern Rollen einem bestimmten Bereich (oder einer Gruppe mit diesen Berechtigungen) mithilfe der rollenbasierten Zugriffssteuerung (Azure RBAC) zugewiesen werden. Anschließend können Benutzer mit den entsprechenden Berechtigungen eine Remotedesktopverbindung verwenden, um auf Windows Server-Computer zuzugreifen, oder SSH für den Zugriff auf Linux verwenden.

Ihr "Administratorkonto" ist Ihre Microsoft Entra ID-Identität (oder ein synchronisiertes AD-Konto) mit entsprechenden Rollen in Azure. Um z. B. Arc-fähige Server zu verwalten, verfügt ein Microsoft Entra-ID-Benutzer möglicherweise über die azure integrierte Rolle " Administratoranmeldung für virtuelle Computer" oder eine benutzerdefinierte Rollenzuweisung, die Sie mit entsprechenden Berechtigungen erstellen. Anstatt über ein Administratorkonto zu verfügen, das vollzugriff auf jeden Server ermöglicht, können Sie mit der Microsoft Entra-ID Rollen auf eine bestimmte Gruppe von Azure-Workloads festlegen und nur die erforderlichen Berechtigungen erteilen, um die erforderlichen Aufgaben auf Arc-fähigen Servern und systemeigenen Azure-Ressourcen auszuführen.

Vom System zugewiesene verwaltete Identität

Arc-fähige Server erfordern eine vom System zugewiesene verwaltete Identität. Dies ist eine Art von Unternehmensanwendung, die die Identität einer Computerressource in Azure darstellt. Anstatt Anmeldeinformationen zu speichern, können anwendungen, die auf dem Server ausgeführt werden, die verwaltete Identität des Servers verwenden, um sich bei Azure zu authentifizieren. Der Azure Arc Connected-Computer-Agent macht einen Endpunkt verfügbar, den die App zum Anfordern eines Tokens verwenden kann. Die App muss sich nicht bei dem nicht routingfähigen Webdienst authentifizieren, der andere Token bereitstellt als die ordnungsgemäße Formatierung der Anforderung (einschließlich eines Metadatenheaders), sodass die erwartete Sicherheitsgrenze der virtuelle Computer ist. Ihr lokaler Server kann direkt auf Azure-Dienste zugreifen, ohne hartcodierte Anmeldeinformationen zu benötigen, da Azure weiß, dass die Anforderung von diesem Server stammt, und autorisiert sie nur basierend auf den von Ihnen festgelegten Rollenzuweisungen.

Bei einem Systemadministrator kann ein gängiges Szenario einen Azure CLI-Befehl auf dem Server (auf dem Azure CLI installiert ist) ausgeführt werden, der in Azure Storage aufruft, um ein Artefakt abzurufen, das von einem Automatisierungsskript verwendet wird. Da der Server über einen identitätsautorisierten Zugriff auf dieses Speicherkonto verfügt, wird die Anforderung ohne ein Dienstkonto oder ein persönliches Zugriffstoken (PAT) abgeschlossen.

Rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC)

Das Modell von Azure fördert granulares RBAC. Da unterschiedliche integrierte Rollen unterschiedliche Zugriffstypen ermöglichen, können Sie Rollen mit sehr eingeschränkten Berechtigungen zuweisen. Beispielsweise könnte ein Benutzer über eine Rolle verfügen, die nur die Möglichkeit bietet, "Befehl ausführen" auf Arc-fähigen Servern zu verwenden, oder schreibgeschützten Zugriff auf eine Konfiguration und nichts mehr zulässt.

Eine gängige integrierte Rolle, die in Azure Arc verwendet wird, ist die Rolle "Azure Connected Machine Onboarding". Benutzer mit dieser Rolle können Server in Azure Arc integrieren, die meisten anderen Verwaltungsaufgaben jedoch nur ausführen, wenn zusätzliche Rollen erteilt werden. Ebenso können Sie Anwendungsbesitzerrollen zuweisen, die es ihnen ermöglichen, Patches auf ihren Servern über Azure Automation bereitzustellen, ohne ihnen tatsächlichen Zugriff auf die Betriebssystemanmeldung zu gewähren. Diese Feinabstimmung unterstützt "just-enough" Verwaltungsprinzipien.

Just-in-Time-Zugriff

Um den erweiterten Zugriff auf Ihre Arc-fähigen Server und andere Azure-Ressourcen weiter zu steuern, können Sie Microsoft Entra Privileged Identity Management (PIM) aktivieren. PIM kann für den Just-in-Time-Zugriff (JIT) verwendet werden, sodass Sie verlangen können, dass jemand explizit eine bestimmte Rolle erhöht, um Aufgaben auszuführen, die größere Zugriffsebenen erfordern. Sie können einen Administrator zum Genehmigen dieses Zugriffs anfordern und automatische Ablaufzeiten für die Rolle mit erhöhten Rechten festlegen. PIM enthält auch einen Überwachungsverlauf, um alle Rollenzuweisungen und Aktivierungen für alle privilegierten Rollen innerhalb der letzten 30 Tage anzuzeigen (oder einen längeren Zeitraum, den Sie konfigurieren).

Die Verwendung von PIM trägt dazu bei, den laufenden Administratorzugriff zu reduzieren und das Prinzip der geringsten Rechte zu unterstützen. Sie können beispielsweise PIM verwenden, um bestimmten Benutzern die Möglichkeit zu gewähren, ihre Rolle zum Azure Connected Machine Resource Administrator zu erhöhen, sodass sie erweiterte Verwaltungsaufgaben auf Arc-fähigen Servern ausführen können.

Hybrididentitätskonfigurationen

In der Praxis führen viele Unternehmen Arc-fähige Server aus, die auch mit AD verbunden sind. Diese schließen sich nicht gegenseitig aus; sie ergänzen sich gegenseitig. Möglicherweise melden Sie sich bei Bedarf über AD beim Server an, führen aber Verwaltungsaufgaben in Azure aus.

Auf einzelnen Servern können Sie lokale Konten weiterhin über AD verwalten, z. B. die Lokale Administratorkennwortlösung (LAPS), um das lokale Administratorkennwort zu drehen. Da Azure Arc keine lokalen Konten verwaltet, sollten Sie diesen Prozess weiterhin verwenden. Sie könnten sogar Azure-Richtlinie verwenden, um sicherzustellen, dass LAPS aktiviert und Kennwörter in Microsoft Entra gespeichert wird.

Es gibt viele Flexibilität, die Funktionen von Microsoft Entra und Azure zu nutzen, während weiterhin lokale Identitätslösungen verwaltet werden, die für Sie funktionieren. Im Laufe der Zeit müssen Sie weniger mit der Wartung von Dienstkonten interagieren oder lokale Administratorrechte gewähren, da Sie Optionen zum Verwalten von Identitäten in der Cloud haben können.