Maschinenidentitäten: Wer handelt ohne Benutzerkonto?
Ein Deployment verwendet keine Benutzerkonten, besitzt aber dieselbe produktive Identität wie ein frei änderbarer Test-Runner.
Der Prüfauftrag
Für einen abgegrenzten Dienst mit CI/CD, Cloud-Ressourcen und maschinellen API-Zugriffen. Richtwert: 90 Minuten für einen vorhandenen Dienstpfad; Migrationen und vollständige Inventarisierung zusätzlich. Entra-Begriffe sind Beispiele und müssen auf die eingesetzte Plattform übertragen werden.
Am Ende hast du:Für einen Dienst ist belegbar, wer seine Maschinenrechte ausüben kann, welche Ressourcen erreichbar sind und wie der Zugriff endet.
Beweisen statt vermuten.
In der eigenen Testumgebung mit der tatsächlichen Test-Workload-Identität genau einen Lesezugriff auf eine benannte Dummy-Ressource außerhalb ihres erlaubten Bereichs versuchen. Bestehen: Die Ressource verweigert die Autorisierung und protokolliert die richtige Identität; ein Fehler durch DNS, fehlendes Objekt oder abgelaufenes Token genügt nicht.
Status, Prüfbereich und Notizen bleiben in diesem Browser. Keine Übertragung an MauriSec. Ohne Speicherung geht der Stand beim Verlassen verloren; gespeicherte Daten bleiben bis zu deiner Löschung. Keine Geheimnisse, Zugangsdaten oder fremden personenbezogenen Daten eintragen.
Identität, technische Instanz, aufrufenden Workload und fachlichen Eigentümer verbinden; App-ID und tenantlokale Objekt-ID nicht verwechseln.
So belegst du es: Inventar mit Zweck, Umgebung, Ressourcen, letzter belegter Nutzung und zuständiger Vertretung.
Nachweis und nächsten Schritt notieren
Authentifizierung ohne selbst verwaltetes dauerhaftes Geheimnis für unterstützte Pfade bevorzugen; verbleibende Ausnahmen begründen.
So belegst du es: Entscheidung zwischen Managed Identity, Workload-Föderation, Zertifikat und Secret einschließlich Betriebsabhängigkeiten.
Nachweis und nächsten Schritt notieren
Bei föderierten Workloads den zulässigen Aussteller, Subject und Audience exakt an den freigegebenen Workflow binden.
So belegst du es: Vertrauenskonfiguration und tatsächlich verwendete Claims; keine unbewertete Erweiterung auf andere Repositories oder Umgebungen.
Nachweis und nächsten Schritt notieren
Effektive Rechte auf Kontroll- und Datenebene prüfen; zusätzliche Gruppen, Rollen und direkte Ressourcenfreigaben einbeziehen.
So belegst du es: Aufgaben-Rechte-Matrix mit erfolgreichem Sollzugriff und verweigertem Zugriff außerhalb des Zwecks.
Nachweis und nächsten Schritt notieren
Produktions- und Testidentitäten trennen und Wiederverwendung über unabhängige Anwendungen nur begründet zulassen.
So belegst du es: Zuordnung der ausführenden Ressourcen zu Identitäten und geprüfte Trennung der erreichbaren Daten.
Nachweis und nächsten Schritt notieren
Wer Credentials, Föderationsregeln oder ausführbaren Workload ändern darf, als möglichen Nutzer der Maschinenidentität bewerten.
So belegst du es: Berechtigungsprüfung der App-Eigentümer, Deployment-Pipeline und verbundenen Rechenressourcen.
Nachweis und nächsten Schritt notieren
Nutzung und Vertrauensänderungen überwachen; Token, private Schlüssel und Secrets aus Logs und Prüfbelegen heraushalten.
So belegst du es: Zuordenbare Anfrage mit Identitäts-ID und Ergebnis sowie Alarm für eine freigegebene Teständerung.
Nachweis und nächsten Schritt notieren
Stilllegung und Notfallsperre mit abhängigen Diensten erproben; Rechteänderungen nicht mit sofortigem Tokenverlust gleichsetzen.
So belegst du es: Entzugsablauf, gemessene Wirklatenz, Restzugänge und Abschlussprüfung nach dem dokumentierten Cache- beziehungsweise Tokenfenster.
Nachweis und nächsten Schritt notieren
Deine nächste Arbeit.
Beginne mit den vorrangigen Punkten. Markierte Lücken erscheinen hier mit deinen nächsten Schritten.
Grenzen und Primärquellen
Managed Identities entfernen die Secret-Verwaltung, nicht die Folgen eines kompromittierten Workloads. Benutzer-MFA schützt keine App-only-Anmeldung. Bei Managed Identities können Gruppen- oder Rollenänderungen wegen Caches erst nach Stunden wirksam werden. Plattform, Ressource und Tokentyp bestimmen die tatsächliche Entzugswirkung.
Microsoft Learn: Securing service principals ↗Microsoft Learn: Workload identity federation ↗Microsoft Learn: Federated identity credential considerations ↗Microsoft Learn: Managed identity best practice recommendations ↗OWASP: Non-Human Identities Top 10 ↗Prüfbericht / Selbsteinschätzung
Maschinenidentitäten: Wer handelt ohne Benutzerkonto? · v2026.11 · 10.11.2026 ·
0/8 bearbeitet · 0 Lücken. Keine unabhängige Prüfung oder Zertifizierung.
1. Identität, technische Instanz, aufrufenden Workload und fachlichen Eigentümer verbinden; App-ID und tenantlokale Objekt-ID nicht verwechseln.
Status: Offen
Erwarteter Nachweis: Inventar mit Zweck, Umgebung, Ressourcen, letzter belegter Nutzung und zuständiger Vertretung.
Eigene Referenz: Nicht hinterlegt
Nächster Schritt: Nicht hinterlegt
2. Authentifizierung ohne selbst verwaltetes dauerhaftes Geheimnis für unterstützte Pfade bevorzugen; verbleibende Ausnahmen begründen.
Status: Offen
Erwarteter Nachweis: Entscheidung zwischen Managed Identity, Workload-Föderation, Zertifikat und Secret einschließlich Betriebsabhängigkeiten.
Eigene Referenz: Nicht hinterlegt
Nächster Schritt: Nicht hinterlegt
3. Bei föderierten Workloads den zulässigen Aussteller, Subject und Audience exakt an den freigegebenen Workflow binden.
Status: Offen
Erwarteter Nachweis: Vertrauenskonfiguration und tatsächlich verwendete Claims; keine unbewertete Erweiterung auf andere Repositories oder Umgebungen.
Eigene Referenz: Nicht hinterlegt
Nächster Schritt: Nicht hinterlegt
4. Effektive Rechte auf Kontroll- und Datenebene prüfen; zusätzliche Gruppen, Rollen und direkte Ressourcenfreigaben einbeziehen.
Status: Offen
Erwarteter Nachweis: Aufgaben-Rechte-Matrix mit erfolgreichem Sollzugriff und verweigertem Zugriff außerhalb des Zwecks.
Eigene Referenz: Nicht hinterlegt
Nächster Schritt: Nicht hinterlegt
5. Produktions- und Testidentitäten trennen und Wiederverwendung über unabhängige Anwendungen nur begründet zulassen.
Status: Offen
Erwarteter Nachweis: Zuordnung der ausführenden Ressourcen zu Identitäten und geprüfte Trennung der erreichbaren Daten.
Eigene Referenz: Nicht hinterlegt
Nächster Schritt: Nicht hinterlegt
6. Wer Credentials, Föderationsregeln oder ausführbaren Workload ändern darf, als möglichen Nutzer der Maschinenidentität bewerten.
Status: Offen
Erwarteter Nachweis: Berechtigungsprüfung der App-Eigentümer, Deployment-Pipeline und verbundenen Rechenressourcen.
Eigene Referenz: Nicht hinterlegt
Nächster Schritt: Nicht hinterlegt
7. Nutzung und Vertrauensänderungen überwachen; Token, private Schlüssel und Secrets aus Logs und Prüfbelegen heraushalten.
Status: Offen
Erwarteter Nachweis: Zuordenbare Anfrage mit Identitäts-ID und Ergebnis sowie Alarm für eine freigegebene Teständerung.
Eigene Referenz: Nicht hinterlegt
Nächster Schritt: Nicht hinterlegt
8. Stilllegung und Notfallsperre mit abhängigen Diensten erproben; Rechteänderungen nicht mit sofortigem Tokenverlust gleichsetzen.
Status: Offen
Erwarteter Nachweis: Entzugsablauf, gemessene Wirklatenz, Restzugänge und Abschlussprüfung nach dem dokumentierten Cache- beziehungsweise Tokenfenster.
Eigene Referenz: Nicht hinterlegt
Nächster Schritt: Nicht hinterlegt
Managed Identities entfernen die Secret-Verwaltung, nicht die Folgen eines kompromittierten Workloads. Benutzer-MFA schützt keine App-only-Anmeldung. Bei Managed Identities können Gruppen- oder Rollenänderungen wegen Caches erst nach Stunden wirksam werden. Plattform, Ressource und Tokentyp bestimmen die tatsächliche Entzugswirkung.