Um Berechtigungen für die Verwaltung von Servern oder der Azure-Cloud samt Diensten und Ressourcen zu vergeben, lassen sich je nach Unternehmensanforderungen unterschiedliche Delegationsmodelle entwickeln. Während größere Organisationen nach Diensten segregieren – das eine Team betreut die Dateidienste, das andere das Active Directory –, tendieren kleinere Betriebe dazu, Berechtigungen über alle Server und Dienste hinweg zu delegieren.

Der Querschnitt über die zu delegierenden Berechtigungen sieht dann jeweils anders aus und lässt sich über Sicherheitsgrenzen (Tiers), Funktionsgruppen, Abteilungen oder dem Erfahrungsschatz der einzelnen IT-Mitarbeiter bestimmen.

Wir ignorieren hier bewusst den Aspekt, dass es noch immer Unternehmen gibt, die generell den Domänen-Administrator für die Verwaltung verwenden – hier ist weitaus mehr als nur ein Delegationskonzept notwendig, sondern vielmehr die Entwicklung des Verständnisses von grundlegender IT-Sicherheit.

Divide et impera
Microsoft stellt Admins für lokale Windows Server, hybride Infrastrukturen oder die Verwaltung von Azure-VMs das Windows Admin Center (WAC) bereit. Damit sind Sie in der Lage, die Verwaltung einer Gruppe von Servern einfacher, automatisiert und in delegierter Form zu gestalten.

Da Windows Server für die Administration der Serverdienste meist kein ausgeprägtes Rollenmodell kennt und nicht gut zwischen "Administrator des Servers" und "Rollenadministrator" unterscheiden kann, dient das WAC auch als Werkzeug zur Fernadministration, ohne jemandem Berechtigungen auf den eigentlichen Server geben zu müssen. Für den Fall, dass die Administration überwiegend über das WAC geschieht, besteht die Möglichkeit und auch die Pflicht, ein stabiles und flexibles Administrationsmodell auf die Beine zu stellen.

Ein Ansatz für das Erstellen des Konzepts kann "divide et impera" sein, also "teile und herrsche", um das Problem in mehrere, besser verdauliche Stücke zu sortieren. Gerade in größeren Unternehmen besteht die Chance, dass eine Unterteilung der Gewalten Sinn ergibt, sodass nicht alle Administratoren und Operatoren dieselben Ressourcen in WAC sehen und verwalten müssen. Oftmals wird diese Trennung von Rollen und Gewalten auch durch rechtliche Organe gefordert.

Microsoft nutzt dieses Konzept in Empfehlungen für sichere Konfigurationen. Dort teilt das Tier-Modell verschiedene Dienste im Unternehmen in Schichten ein – sortiert nach Wichtigkeit und Sicherheit. In Tier 0 befinden sich Domänencontroller, PKI- und Zertifikatsdienste und andere kritische Anmeldedienste wie etwa ADFS oder AADConnect, deren Kompromittierung das Ende des Vertrauens in die Infrastruktur bedeutet. In Tier 1 liegt der Rest der Infrastruktur, als Tier 2 gelten umliegende Systeme, die weniger kritisch und weniger vertrauenswürdig sind, etwa Clients und Mobilgeräte.

Die Administration in den Schichten ist entsprechend ebenfalls unterteilt: Administratoren für Tier 0 erhalten spezielle administrative Konten und müssen sich an Domänencontrollern mit Smartcards anmelden und extra zur Verfügung gestellte, saubere und spezifisch für diesen Verwendungszweck abgesicherte Workstations benutzen. In den anderen Schichten sind die Anforderungen an Anmeldung und Administration etwas lockerer.

Das Modell ließe sich durchaus auch mit WAC anwenden, wobei für die verschiedenen Schichten dann mehrere WAC-Implementierungen erforderlich werden: eine WAC-Instanz für Tier 0, wo Administratoren Domänencontroller, andere Anmeldedienste wie Identity Provider und die Zertifikatsinfrastruktur verwalten. Gerade für Tier 0 werden Sie aber nicht in vertraute und weniger vertraute Admins aufteilen – wer in Tier 0 arbeitet, sollte in jedem Fall höchst vertrauenswürdig sein.

Für den Rest der Infrastruktur gibt es – thematisch gruppiert – weitere WAC-Instanzen. Der Vorteil: So lassen sich unterschiedliche Sicherheitsanforderungen abbilden, jede WAC-Implementierung wird nicht unendlich groß und unübersichtlich und die Anpassung der Konfiguration für jedes WAC lässt sich flexibler anpassen als in einer großen, für das ganze Unternehmen geltenden WAC-Instanz.

So viel wie nötig: PowerShell JEA
Mit der Aufteilung in verschiedene Sicherheitszonen ist das Rollenkonzept noch nicht fertig. Zwar sind jetzt potenzielle Domänenadministratoren auf einem anderen WAC, die restlichen Server aber weiterhin über alle Workloads und Dienste hinweg für Administratoren und Operatoren zugänglich.

Um überhaupt auf die einzelnen im WAC befindlichen Server zugreifen zu können, müssen diese Administratoren und Operations-Engineers auf den Zielmaschinen lokale Administratorenrechte besitzen. Das erlaubt das Lesen und Verändern der Konfiguration aus der Ferne, unterstützt vom WAC. Im WAC selbst genügen "Gateway User"-Berechtigungen.

Um eine granulare Verwaltung auf einzelnen Servern oder über Server und Dienste hinweg zu erzielen, ist Zusatzkonfiguration erforderlich: WAC nutzt das PowerShellFramework Just Enough Admin (JEA) auf Zielservern, um punktgenaue Delegation von Berechtigungen zu modellieren und zu erzwingen. Mit JEA erstellen Sie einen Endpunkt auf dem Zielserver, der Fernadministration erlaubt, dabei für verbundene Benutzer aber nur das erlaubte Berechtigungslevel zugesteht.

Dem Endpunkt, der über PowerShell Remoting angesteuert wird, sind Funktionen sowie berechtigte Rollen zugewiesen. Die Steuerung der für selbst erstellte Rollen definierten Funktionen erfolgt über "Role Capabilities" und eine Feineinstellung der Berechtigungen über PowerShell-Konfigurationsdateien. Die Feinsteuerung kann dann auch funktionieren, wenn die delegierten Administratoren keine lokalen Administratorrechte auf den Zielmaschinen besitzen – was ja eigentlich die Grundvoraussetzung ist.

Für das PowerShell-Remoting, die Verbindung zum Webservice und das Herunterladen der JEA-Skripte von anderen Maschinen lohnt es sich, dem WAC-Server ein eigenes, vertrautes Zertifikat aus der Unternehmens-PKI zu spendieren. Selbst in Testumgebungen ist das Selfsigned-Zertifikat, das bei der Installation von WAC angeboten wird und nur 60 Tage gültig ist, ein wenig umständlich.

ln/jp/Frank Tess

Im zweiten Teil der Workshopserie zeigen wir, wie Sie Standardrollen anpassen, lokale Gruppen in AD-Gruppen umwandeln und JEA auf mehreren Servern ausrollen. Im dritten und letzten Teil beschäftigen wir uns damit, wie Sie VMs in Azure verwalten und was bei der Authentifizierung via Entra ID zu beachten ist.