Managed Identity statt Secrets

Geheimnisse im Code sind eine Wette gegen die Zeit. Jeder Connection-String, jeder API-Key, der irgendwo in einer Konfiguration liegt, ist ein Kandidat für das nächste Leak. Die gute Nachricht: In Azure brauchst du sie für die meisten Dienste gar nicht.

Das Prinzip

Eine Managed Identity gibt deiner Ressource — App Service, Function, Container, VM — eine eigene Identität in Microsoft Entra ID. Statt eines Secrets fordert die App zur Laufzeit ein kurzlebiges Token an. Azure rotiert und verwaltet alles im Hintergrund; du hast nie ein Geheimnis in der Hand.

Es gibt zwei Varianten:

• System-assigned: an die Lebensdauer einer Ressource gekoppelt, 1:1.
• User-assigned: eigenständig, an mehrere Ressourcen anhängbar.

In der Praxis

Der Zugriff etwa auf einen Key Vault oder Storage Account läuft dann ganz ohne Connection-String:

var client = new SecretClient(
    new Uri("https://kv-wolkenkunde.vault.azure.net/"),
    new DefaultAzureCredential());

KeyVaultSecret secret = await client.GetSecretAsync("Db--Password");

DefaultAzureCredential nutzt lokal deine Entwickler-Anmeldung und in Azure automatisch die Managed Identity — derselbe Code, keine Fallunterscheidung.

Worauf achten

Vergib die Rollen nach dem Prinzip der minimalen Rechte (z. B. Key Vault Secrets User statt Contributor). Und denk daran: Die Identität braucht eine Rollenzuweisung am Ziel, sonst gibt es trotz gültigem Token ein sauberes 403.

Weniger Geheimnisse heißt weniger Angriffsfläche — und deutlich ruhigere Audits.