In vielen Tenants, die ich mir anschaue, sollen Applikationen, Benutzer oder Dienstkonten feiner klassifiziert werden, als es die klassischen Felder in Entra ID hergeben. Für diesen Zweck haben sich benutzerdefinierte Sicherheitsattribute in letzter Zeit als sehr nützliches Werkzeug erwiesen. Sie helfen bei Conditional Access, bei Azure Storage und ganz allgemein dabei, im Admin-Alltag den Überblick zu behalten. Werden die Attribute sauber gepflegt, wird Governance merklich einfacher und lässt sich besser nachvollziehen. Mir gefällt vor allem, dass man die Attribute frei definieren kann und die Rechte zum Zuweisen und Ändern trotzdem klar voneinander getrennt sind.

Attributsätze bündeln die Attribute, zugewiesen wird pro Objekt

Die meisten Admins steigen über das Portal ein (Microsoft Entra Admin Center → Schutz → Benutzerdefinierte Sicherheitsattribute). Dort legt man zuerst Attributsätze (Attribute Sets) an, in denen thematisch verwandte Attribute zusammengefasst werden, etwa „AppClassification“ für interne Applikationen. Innerhalb eines Satzes entstehen dann die eigentlichen Attribute, beispielsweise „Sensitivity“ oder „OwnerDepartment“. Wer klassische IAM-Systeme kennt, fühlt sich an Claims erinnert. Gedacht sind die Attribute aber ausdrücklich für Security und Governance.

Zugewiesen werden sie für jedes Objekt einzeln, also etwa für einen Serviceprinzipal oder eine User-ID. In der Oberfläche fehlt eine Massenbearbeitung, mit PowerShell oder der REST-API lässt sich das (bei etwas Geduld) aber automatisieren. Beachten sollte man, dass der Zugriff auf die Attribute von Haus aus restriktiv geregelt ist. Selbst ein Globaler Administrator braucht ausdrücklich Zuweisungsrechte. Versehentliche Massenänderungen werden so verhindert, und das Modell fügt sich gut in den Zero-Trust-Gedanken ein. Die einzelnen Schritte und weitere Details hat Microsoft hier dokumentiert: Benutzerdefinierte Sicherheitsattribute – Überblick und Attribute hinzufügen.

Ohne die passende Attributrolle bleibt selbst der Globale Administrator außen vor

Oft übersehen wird, dass es für die Verwaltung und Zuweisung benutzerdefinierter Sicherheitsattribute eigene Rollen gibt. Der „Attributdefinitionsadministrator“ legt Sets und Felder an und ändert sie, der „Attributzuweisungsadministrator“ setzt und ändert die Werte am Zielobjekt. Wer nur Globaler Administrator ist und keine dieser Rollen hat, kommt an die Attribute nicht heran. Das ist ziemlich konsequent und sorgt dafür, dass nicht jeder an denselben Daten herumschraubt. Auch Serviceprinzipale und Automatisierungen brauchen die passende Rolle. Ich rate in der Praxis dazu, diese Rollen sehr sparsam zu vergeben und nur an fest definierte Betriebsprozesse zu knüpfen.

Praktisch ist, dass sich Berechtigungen auf Ebene der Attributsätze vergeben lassen. So kann man bestimmte Attribute (etwa zur App-Klassifikation) gezielt delegieren, ohne dass andere (etwa die Abteilungszuordnung) davon berührt werden. In größeren Umgebungen, in denen mehrere Teams sich die Zuständigkeiten teilen, hilft das enorm.

Conditional Access und Azure ABAC nutzen die Attribute direkt

Am spannendsten finde ich die Anbindung an Conditional Access. Mit dem Filter „Für Apps“ (siehe Microsoft-Dokumentation) lassen sich Applikationen inzwischen gezielt über ihre benutzerdefinierten Sicherheitsattribute auswählen. So kann man etwa alle Apps mit „Sensitivity: High“ einer besonders strengen MFA-Policy unterwerfen oder den Zugriff von bestimmten Standorten aus einschränken. Die Bedingung gibt es ab Entra ID P1. Klassische Gruppen werden dadurch oft überflüssig, besonders wenn sich die Attribute gleich bei der App-Zuordnung pflegen lassen.

Wer mit Azure Storage arbeitet, sollte zusätzlich einen Blick auf Azure ABAC (attributbasierte Zugriffssteuerung) werfen. Damit hängt man Zugriffsregeln für Blob Storage direkt an Attributwerte aus Entra ID. Identitäten und Ressourcen sind dann unmittelbar miteinander verknüpft, ohne dass man zusätzliche Gruppen verwalten muss – sehr angenehm, wenn komplexe Zugriffsmatrizen abzubilden sind.

Das folgende Mermaid-Diagramm zeigt vereinfacht, wie Attributsätze, Attribute und die Zuweisung an Objekte zusammenhängen:

flowchart TD
  Set["Attributsatz"] --> Def["Attributdefinition"]
  Def --> Obj["Zielobjekt (Benutzer/App)"]
  Admin["Zuweisungsadministrator"] --> Obj
  AdminDef["Definitionsadministrator"] --> Set

Abbildung: Beziehung zwischen Attributsätzen, Attributdefinitionen, Zuweisung und Rollen

Am Objekt hinterlegte Attribute erleichtern Klassifizierung und Audit

In meinen Projekten klassifiziere ich Applikationen häufig über benutzerdefinierte Sicherheitsattribute, etwa nach Sensitivität, Compliance-Bedarf oder Betreiberbereich. Weil diese Metadaten direkt am Objekt hängen, kann ich sie für Conditional Access ebenso verwenden wie für Auswertungen. Wenn Microsoft 365 Copilot oder automatisierte Prozesse eingeführt werden (siehe Copilot-Readiness), zahlt sich eine saubere Einordnung der Apps besonders aus. Schatten-IT fällt schneller auf, und sensible Apps lassen sich gezielt schützen.

Für die Administration ist außerdem interessant, dass Änderungen an Attributen gesondert protokolliert werden. Sie tauchen im Audit-Log von Entra ID in einer eigenen Kategorie auf. Damit lässt sich jederzeit nachvollziehen, wer wann was geändert hat, was Compliance und Betrieb gleichermaßen hilft.

Tipp aus der Praxis: Conditional-Access-Regeln, die auf benutzerdefinierte Sicherheitsattribute abzielen, teste ich immer zuerst mit dem What-If-Testmodus im Conditional-Access-Bereich. Danach prüfe ich die Auswirkungen mit Report-Only. Fehlauslöser fallen so auf, bevor eine Policy live geht.

Die Attribute an Apps oder Benutzer weise ich meist mit Microsoft Graph PowerShell zu. Das geht schneller als die Klickerei im Portal, und es schleichen sich weniger Fehler ein.

Kleine Felder entfalten im Tenant eine große Wirkung

Anfangs sah das Ganze nach einem weiteren Metadaten-Feature aus. Heute sind benutzerdefinierte Sicherheitsattribute ein wichtiger Baustein, wenn Sicherheit und Governance an Identitäten ausgerichtet werden. Weil Definition, Zuweisung und Auswertung getrennt sind, wird das Setup sicherer und zugleich transparenter. Den größten Nutzen haben Umgebungen mit vielen Custom-Apps, geteilten Zuständigkeiten oder hohen Compliance-Anforderungen. Wer Conditional Access wirklich flexibel und dynamisch aufbauen möchte, kommt an diesen Attributen kaum noch vorbei. Bei mir gehören sie mittlerweile zu jedem neuen Tenant-Setup dazu.