Auspacken von Access-Paketen

Einführung in Azure AD Access Packages und wie wir sie in einem realen Kundenszenario eingesetzt haben

Einführung

Wie großartig wäre es, wenn Benutzer sich selbst für eine Reihe von Azure AD-Gruppen, Anwendungen oder SharePoint-Sites anmelden könnten , anstatt durch alle möglichen bürokratischen Hürden zu springen, bevor der Zugriff gewährt wird und der Benutzer seine eigentliche Arbeit erledigen kann?

Das wäre nicht nur für den Endbenutzer toll, sondern auch aus Sicht des Administrators das ideale Szenario. Anstatt einen benutzerdefinierten Registrierungsprozess mit vielen manuellen Schritten zu pflegen, verlagert dieser Prozess die Aktion auf die Endbenutzer selbst. So kann sich der Administrator auf die Pflege eines sicheren und konformen Systems konzentrieren, anstatt sich mit einfachen, sich wiederholenden Aufgaben zu beschäftigen.

Wie ich Ihnen in diesem Artikel zeigen werde, sind die Zugangspakete genau dazu da! Ich werde näher darauf eingehen, was es mit diesen Paketen auf sich hat. Zunächst werde ich erklären, was diese Pakete sind, welche Möglichkeiten Sie bei der Einrichtung haben und wie ein grundlegender Nutzungsablauf aussieht.

Nachdem die Grundlagen geklärt sind, werde ich anhand eines realen Kundenbeispiels zeigen, wie wir bei Xpirit Managed Service Access Packages genutzt haben, um einen hochautomatisierten Registrierungsprozess für ein komplexes Identitäts- und Zugriffsmanagement-Szenario zu erstellen.

Was sind Access-Pakete?

Im Wesentlichen sind Zugriffspakete eine Möglichkeit, den Zugriff auf Azure-Ressourcen auf rationale und effiziente Weise zu verwalten. Mit diesen Paketen können Sie eine Reihe von Azure-Ressourcen zusammenfassen, die in der Regel von demselben Team oder derselben Benutzergruppe genutzt werden, und diesem Paket bestimmte Zugriffsrechte zuweisen.

Sie vereinfachen nicht nur die Zugriffsverwaltung, sondern bieten auch Selbstbedienungsfunktionen für Endbenutzer. Das bedeutet, dass Benutzer den Zugriff auf bestimmte Pakete selbst beantragen können, anstatt den Weg über einen IT-Administrator oder eine Abteilung gehen zu müssen. Wenn ein Benutzer den Zugriff auf ein Paket beantragt, kann ein Genehmiger den Antrag überprüfen. Dies bietet eine zusätzliche Kontrollebene und stellt sicher, dass der Zugriff auf Ressourcen immer mit den Sicherheits- und Compliance-Anforderungen des Unternehmens übereinstimmt.

Um die Zugriffspakete nutzen zu können, benötigen Sie eine Azure AD P2 oder Enterprise Mobility + Security (EMS) E5 Lizenz.

Konfiguration eines Access-Pakets

Die Pakete befinden sich in Katalogen, die Container für ein oder mehrere Pakete sind. Nachdem Sie dem Paket einen Namen und eine Beschreibung gegeben haben, fügen Sie die Ressourcen hinzu, für die sich die Benutzer registrieren sollen. Dies können Azure AD-Gruppen, Unternehmensanwendungen und/oder SharePoint-Sites sein.

Der nächste Schritt ist die Entscheidung, wer sich für das Paket anmelden kann. Es gibt 3 Hauptoptionen.

Benutzer in Ihrem Verzeichnis

Mit dieser Option können Sie festlegen, ob alle Mitglieder oder bestimmte Benutzer Zugriff auf dieses Paket beantragen können. Außerdem können Sie entscheiden, ob eine manuelle Genehmigung erforderlich ist. Wenn ja, können Sie festlegen, ob die Benutzer eine Begründung schreiben müssen, ob der Vorgesetzte des Benutzers oder ein bestimmter anderer Benutzer (oder Benutzer) als Genehmigender fungieren soll und in welchem Zeitraum die Entscheidung getroffen werden muss. Es ist sogar möglich, eine zweite Reihe von Genehmigenden zu erstellen, wenn der erste Genehmigende nicht innerhalb der vorgegebenen Zeitspanne entschieden hat.

Kurz gesagt, mit dieser Option ist es möglich, eine granulare Least Privilege-Struktur für Ihre Zugriffspakete zu erstellen. Auf diese Weise können Sie die Unternehmensrichtlinien und die Governance in Bezug auf die Benutzerzugriffsverwaltung leicht anpassen.

Benutzer, die sich nicht in Ihrem Verzeichnis befinden

Mit dieser Option können Sie bestimmte externe Organisationen angeben, die Registrierung für alle angeschlossenen Organisationen öffnen oder alle Benutzer auswählen, d.h. alle angeschlossenen Benutzer und alle neuen externen Benutzer. Mit dieser Option können Sie den Genehmigungsprozess hinzufügen oder auslassen.

Keine (nur direkte Zuweisung durch den Administrator)

Diese letzte Option bedeutet, dass nur Administratoren Personen zu dem Zugangspaket hinzufügen können. Dies ist die beste Option, wenn es keinen Genehmigungsfluss gibt und die Benutzer sich nicht selbst in die Pakete eintragen können sollen.

Bei Bedarf können Sie Benutzer mit Hilfe von benutzerdefinierten Parameterfeldern nach zusätzlichen Informationen fragen, wenn sie Zugang beantragen. Sie können einen Lebenszyklus für die Zuweisung des Zugangspakets festlegen. Und schließlich können Sie festlegen, ob eine Zugangsprüfung erforderlich ist. Die Idee hinter diesen Zugangsprüfungen ist es, zu überprüfen, ob alle Paketanmeldungen rechtmäßig und aktuell sind.

Selbstbedienung Onboarding

Nachdem Sie den Katalog eingerichtet und ein oder mehrere Zugangspakete erstellt haben, sieht ein typisches Happy Flow Self-Service-Szenario etwa so aus:

Der Endbenutzer geht zu Myaccess.microsoft.com und nach der Anmeldung mit seinen Azure AD-Anmeldedaten wird die Landing Page mit allen verfügbaren Paketen angezeigt. Der Benutzer kann den Zugriff auf die gewünschten Pakete beantragen, woraufhin ein Genehmiger eine E-Mail mit der anstehenden Genehmigung erhält. Nach der Genehmigung erhält der Benutzer eine Rückmeldung per E-Mail und bekommt die Ressourcenrollen, die dem Zugriffspaket zugewiesen sind.

Kunden-Anwendungsfall: Automatisiertes Benutzer-Onboarding in einer Webanwendung mit komplexer Rollen- und Rechtestruktur.

Bisher haben wir uns das recht einfache Self-Service-Szenario angesehen, in dem Zugangspakete eine sehr nützliche Rolle spielen können. Aber es gibt noch mehr Anwendungsfälle für Zugangspakete. Bei Xpirit Managed Services (XMS) haben wir sie auf eine etwas andere Weise eingesetzt. Wir erhielten von unserem Kunden die Anfrage, einen automatisierten Onboarding-Prozess für seine Azure AD-Benutzer zu erstellen. Der Benutzer sollte sich über SSO bei der Webanwendung anmelden können und automatisch den richtigen Rollen und Projekten zugewiesen werden.

Die Herausforderung besteht darin, dass diese Anwendung eine komplexe Rollen- und Rechtestruktur hat. Sie besteht aus mehr als 20 separaten Projekten, die alle drei oder mehr separate Rollen pro Projekt haben. Eine schnelle Berechnung zeigt, dass es sich um mehr als 60 Projekt-/Rollenkombinationen handelt. Mehrere hundert Benutzer sollten in der Lage sein, sich für mehrere Projekte anzumelden und innerhalb dieser Projekte möglicherweise mehrere Rollen zu übernehmen.

Dann gibt es spezielle Schlüsselbenutzer, die in mehreren Projekten erweiterte Rechte haben sollten, und Benutzer, die in allen Projekten nur Leserechte haben müssen. Um die Sache noch komplizierter zu machen, sind die Benutzer alle aus verschiedenen Unternehmen, die in diesem Projekt zusammenarbeiten.

Im nächsten Teil werde ich Ihnen erklären, was wir uns ausgedacht haben, um diese Herausforderung zu lösen.

SSO und Rollenzuordnung

Um SSO zu ermöglichen, war bereits eine App-Registrierung + Unternehmensanwendung vorhanden. Der erste Schritt bestand darin, alle Rollen aus der Anwendung den App-Rollen in der App-Registrierung zuzuordnen. Im JSON-Manifest sieht das folgendermaßen aus:

"appRoles": [
{
"allowedMemberTypes": [
"User"
],
"description": "ProjectX_RoleY",
"displayName": "Project X Role Y",
"id": "8e9bd73b-e64f-46e5-b4b6-481234",
"isEnabled": true,
"lang": null,
"origin": "Application",
"value": " ProjectX_RoleY "
}
]

Der nächste Schritt ist die Zuordnung von Azure AD (AAD) Gruppen zu diesen App-Rollen. Es gibt eine 1:1-Zuordnung zwischen den App-Rollen und den AAD-Gruppen. Die Zuordnung muss in der Unternehmensanwendung vorgenommen werden. Um dies starrer und wartbarer zu machen, haben wir das App-Registrierungs-JSON-Manifest in ein Git-Repository gestellt und ein Azure CLI-Skript erstellt, um dieses Manifest mit dem Cmdlet az ad app update zu aktualisieren.

Um schließlich die Zuordnung zwischen den App-Rollen und den AAD-Gruppen vorzunehmen, durchläuft ein PowerShell-Skript alle AD-Gruppen wie folgt:

foreach ($group in $aadGroups) {
  $role = $roles | Where-Object -Property value -eq 
  $group.Displayname

  $params = @{
  PrincipalId = "$($group.Id)"
  ResourceId  = "[Resource-Id]"
  AppRoleId   = "$($role.Id)"
  }

 New-MgGroupAppRoleAssignment -GroupId $group.Id -BodyParameter $params
}

Mit diesem Mechanismus ist der erste Teil des Rätsels gelöst. Jetzt müssen die Benutzer in die AAD-Gruppen aufgenommen werden. Es ist an der Zeit, dass die Zugangspakete ihren Auftritt haben.

Zugang Pakete

Für jedes Projekt wurden 3 separate Pakete erstellt, die den Rollen (und den AAD-Gruppen) in der Anwendung entsprechen: Approver, Contributor und Manager. In diesen Paketen werden die entsprechenden AAD-Gruppen ausgewählt und außerdem eine AD-Gruppe Default Users hinzugefügt, die der globalen Leserrolle in der Anwendung zugeordnet wird.

Außerdem wurden für die Key-User und Reader-Only-Benutzer separate Pakete mit allen entsprechenden AD-Gruppen erstellt. Für diesen Anwendungsfall eignet sich diese Funktion hervorragend, denn mit einer einzigen Registrierung wird der Benutzer zu all diesen AD-Gruppen auf einmal hinzugefügt.

Da die Endbenutzer in diesem Szenario nicht wissen, zu welchen Zugangspaketen sie gehören (zumindest im Moment), wurden die Optionen für die Selbstregistrierung deaktiviert und stattdessen die Zuweisung nur durch den Administrator gewählt. Da die Verwaltung und Genehmigung der Benutzerzuweisung im Voraus erfolgt, konnte auch der Genehmigungsfluss deaktiviert werden. Ein Enddatum für die Registrierung war nicht erforderlich, da Benutzer, die nicht mehr für ein Zugangspaket in Frage kommen, automatisch entfernt werden (ich werde später mehr dazu sagen).

Die Zugangspakete werden nicht automatisch erstellt, da dies eine einmalige Aufgabe war und ziemlich einfach über das Azure-Portal erledigt werden kann.

Nachdem die Zugangspakete eingerichtet waren, kamen wir zu unserem letzten Schritt: der Registrierung der Benutzer in den Paketen.

Benutzerregistrierung

Für die Benutzerregistrierung war es das Ziel, eine Lösung zu schaffen, die zur Arbeitsweise von XMS passt. Bei XMS sind wir immer bestrebt, mit unseren Kunden zusammenzuarbeiten und ihnen dadurch zu ermöglichen, auf DevOps-Art zu arbeiten. Und zwar auf diese Weise. Es ist wichtig, dass wir keine Grenzen zwischen verschiedenen Interessengruppen oder zwischen dem Unternehmen und der IT schaffen, sondern zusammenarbeiten und intelligente Prozesse aufbauen, bei denen wiederkehrende Aufgaben so weit wie möglich automatisiert werden.

In diesem Fall, wo ein herkömmlicher Dienstleister ein Ticket-System einrichten würde, in dem der Kunde die Registrierung neuer Benutzer beantragen kann, wollten wir dies zu einem kollaborativen und reibungslosen Prozess machen. Dieser Prozess besteht nun aus 3 Schritten:

1. Für jedes Zugangspaket wurde eine einfache .CSV-Datei erstellt, in der der Kunde nach Belieben Benutzer hinzufügen oder löschen kann:

Displayname;Email;AccessPackage
User Z;userz@example.com;Project X | Role Y

2. Diese .CSV-Dateien sind Teil eines Repositorys und der Kunde kann einen PR mit den neuen Änderungen erstellen. Diese PRs werden von dem XMS-Team validiert.
3. Nachdem der PR zusammengeführt wurde, wird eine Azure DevOps-Pipeline ausgelöst, die ein Skript ausführt, um die Benutzer aus den CSVs zu registrieren. Außerdem wird ein neuer AD-Gastbenutzer erstellt, wenn der Benutzer nicht in unserem Tenant vorhanden ist. Schließlich wird geprüft, ob Benutzer aus der CSV-Datei entfernt wurden. Diese werden ebenfalls aus den Paketen entfernt.

Einige Codeschnipsel aus diesem Skript:

# Invite user if not yet exists
New-MgInvitation -InvitedUserEmailAddress "$($user.Email.Trim())" -InviteRedirectUrl "https://example.com/invite -SendInvitationMessage:$true

# We check if the user already is member of the package and if not, the user is added.
$check = Compare-Object -DifferenceObject $assignments.Target.ObjectId -ReferenceObject

$AADuser.Id -ExcludeDifferent

if ($null -eq $check) {
  $policy = $accessPackage.AccessPackageAssignmentPolicies[0]

  New-MgEntitlementManagementAccessPackageAssignmentRequest -AccessPackageId $accessPackage.Id - AssignmentPolicyId $policy.Id -TargetId $AADuser.Id

  Write-Host "User $($user.Displayname) is added to Access Package"

#We check if there are differences between the CSV and the assignments and if yes, we remove the users.
$check = Compare-Object -DifferenceObject $assignments2.TargetId -ReferenceObject $userid

Write-Host "Differences in IDs: $($check2.InputObject)"

if ($null -ne $check2) {
  foreach ($assignment in $check2.InputObject) {
  #Get AssignmentId for user that has to be removed
  $assignmentId = ($assignments2 | Where-Object { 
  $_.TargetId -eq $assignment }).Id

  New-MgEntitlementManagementAccessPackageAssignmentRequest -AccessPackageAssignmentId $assignmentId -RequestType "AdminRemove"
  Write-Host "Removed $assignment"
  }
}
 {
  Write-Host 'No users removed'
}

 

Künftige Verbesserungen

Dieser Prozess läuft nun schon seit einigen Monaten und wir sind sehr zufrieden damit. Außerdem ist es wichtig zu erwähnen, dass wir diese Art von Herausforderungen iterativ angehen. Was damit begann, dass der Kunde uns Excel-Tabellen schickte und wir die Benutzer manuell in die Zugangspakete eintrugen (und damit bereits einen Mehrwert für unseren Kunden schufen, da die Benutzer mit den richtigen Rollen auf die Anwendung zugreifen konnten), entwickelte sich zu dem Prozess, der jetzt läuft.

Das bedeutet nicht, dass es sich um eine perfekte Lösung handelt und dass es noch Raum für weitere Verbesserungen gibt. Der nächste Schritt wäre die Umstellung auf Selbstbedienung. Wir müssen dafür sorgen, dass die Zugangspakete dem entsprechen, was die Endbenutzer verstehen. Wir können in jedem einzelnen Unternehmen Genehmiger benennen. Damit sollten wir in der Lage sein, die CSV-Dateien (und vor allem die Pflege dieser CSV-Dateien) vollständig zu entfernen. Dies wird zu einem einfacheren, schlankeren Prozess führen.

Zum Schluss

Dieser Artikel hat gezeigt, was Zugangspakete sind, welches Potenzial sie haben und wie sie in Selbstbedienungsszenarien nützlich sein können.

In unserem Kundenanwendungsfall habe ich gezeigt, dass diese Pakete ein wertvolles Puzzlestück sein können, wenn es darum geht, eine wartbare Lösung für ein komplexes Identitäts- und Zugriffsmanagement-Szenario zu schaffen. Wenn Sie Fragen zu diesem Thema haben oder wissen möchten, wie Sie Zugriffspakete in Ihrer Umgebung einsetzen können, zögern Sie nicht, uns zu kontaktieren!