Wie ich über sichere Backend-Integrationen denke

Sicherheit in Backend-Integrationen scheitert oft an den langweiligen Rändern: ein Token, das nie rotiert, eine Protokollzeile, die einen Header ausgibt, eine IAM-Rolle, die "vorübergehend" war.

Mein mentales Modell

Ich betrachte jede Integration als drei konzentrische Ringe:

1. Das Geheimnis selbst — API-Schlüssel, privater Schlüssel, DB-Passwort.
2. Die Identität, die das Geheimnis beweist — welche Rolle/Prinzipal/Dienst.
3. Der Geltungsbereich, an den die Identität gebunden ist — welche Ressourcen, welche Aktionen, für wie lange.

Jedes Ereignis, das ich gesehen habe, war ein Zusammenbruch von Ring 2 oder Ring 3, nicht von Ring 1. Das Geheimnis ist nicht durchgesickert; der Geltungsbereich war zu weit.

Standardhaltung

• Jedes Geheimnis stammt aus einem Tresor (Secrets Manager, Parameter Store, Vault). Keine .env-Dateien im Commit, keine Geheimnisse in CI-Protokollen.
• Jede Identität ist auf die engste Ressource + Aktion beschränkt, die das Feature zum Laufen bringt. Wenn ich den Geltungsbereich nicht in einem Satz formulieren kann, ist er zu breit.
• Jedes Token rotiert. Wenn die Rotation "schwierig" ist, ist das ein Designfehler, kein Betriebsfehler.

Die Zeile, die dich rettet

Die am meisten unterschätzte Sicherheitspraktik ist: Protokolliere Identitäten, nicht Geheimnisse, und protokolliere Entscheidungen zum Geltungsbereich an dem Punkt, an dem sie getroffen werden.

logger.info(
    "crm.lookup autorisiert",
    extra={
        "principal": principal.id,
        "scope": ["crm:read:customer"],
        "resource": f"customer:{customer_id}",
        "reason": "fulfillment handler",
    },
)

Wenn um 2 Uhr morgens etwas schiefgeht, möchtest du wissen, welche Identität was getan hat. Du wirst niemals das Geheimnis im Protokoll haben wollen.