Ende statischer Zugangsdaten Moderne Identity-Praktiken für Cloud-Anwendungen und Zero-Trust-Sicherheit


In der Vergangenheit bauten Organisationen Anwendungen meist On-Premises oder teilweise in der Public Cloud. Eine gängige Methode zur Authentifizierung zwischen Services bestand darin, ein Servicekonto auch Anwendungskonto genannt zu erstellen und dessen Zugangsdaten direkt im Code oder in Konfigurationsdateien zu hinterlegen.

Eine weitere verbreitete Methode war die Nutzung statischer Zugangsdaten wie Schlüssel. Beispiele sind AWS IAM User Access Keys, Azure Shared Access Signature SAS Tokens, oder Google Service Account Keys.

In diesem Artikel werden die Risiken statischer Zugangsdaten erläutert und Empfehlungen für die Entwicklung moderner Cloud-Anwendungen gegeben.

Einführung in statische Zugangsdaten Grundlagen und Einsatzszenarien

Bevor über statische Zugangsdaten gesprochen wird, ist es wichtig zu verstehen, warum sie überhaupt eingesetzt werden.

Es ist nicht sinnvoll menschliche Zugangsdaten etwa von Entwicklern DevOps oder DBAs in Code oder Konfigurationsdateien zu verwenden um Anwendungskomponenten wie API Endpunkte oder Frontend Webanwendungen gegenüber Backend Services wie Datenbanken Storage oder Message Queues zu authentifizieren.

Über viele Jahre hinweg war es daher üblich Service- oder Anwendungskonten für nicht interaktive Logins zu erstellen insbesondere in On-Premises Legacy-Systemen.

Diese Identitäten werden heute als NHI Non Human Identity bezeichnet. Da sie Teil von Anwendungen und nicht von interaktiven Benutzeranmeldungen waren nutzten sie statische Zugangsdaten meist lange und komplexe Passwörter. In vielen Fällen blieben diese Zugangsdaten dauerhaft bestehen und wurden nie erneuert also langfristig gültige Credentials.

Risiken statischer Zugangsdaten Sicherheitslücken in Cloud-Umgebungen

Statische Zugangsdaten erzeugen dauerhafte und oft unsichtbare Schwachstellen in Cloud-Umgebungen. Sie bieten Angreifern einfache Einstiegspunkte und erschweren gleichzeitig die Erkennung von Missbrauch die Durchsetzung von Sicherheitsrichtlinien und die effektive Eindämmung von Sicherheitsvorfällen.

Wesentliche Risiken beim Einsatz statischer Zugangsdaten:
  • Hoher Blast Radius - Breiter dauerhafter Zugriff macht Kompromittierungen sofort kritisch
  • Anfälligkeit für unbeabsichtigte Offenlegung - Häufige Leaks über Code Repositories Logs und CI Artefakte
  • Keine automatische kurzfristige - Ablaufzeit Schlüssel bleiben lange gültig und ermöglichen langfristigen Missbrauch
  • Schwierige Rotation und schlechte Key Hygiene - Operativer Aufwand führt zu selten erneuerten Zugangsdaten
  • Keine starke Bindung an Workloads Gestohlene - Zugangsdaten können von jeder Infrastruktur aus verwendet werden
  • Wiederverwendung über Umgebungen hinweg - Kompromittierung breitet sich lateral aus und erhöht den Schaden
  • Eingeschränkte Sichtbarkeit und Durchsetzung - Schwache Kontextsignale erschweren Detection und Access Control
  • Ziel automatisierter Reconnaissance - Angreifer sammeln systematisch exponierte Schlüssel
  • Schlechte Ausrichtung auf Zero Trust - Führt zu strukturellen Sicherheitslücken
  • Operative Belastung bei Incident Response - Verlängert die Eindämmung von Sicherheitsvorfällen

Vault als Übergangslösung Secret Management für statische Credentials

Früher setzten Organisationen Lösungen wie CyberArk Privileged Access Manager, oder BeyondTrust Password Safe ein.

Mit der zunehmenden Nutzung der Public Cloud wurden Managed Secrets Manager eingesetzt etwa AWS Secrets Manager, Azure Key Vault, Google Secret Manager, oder HashiCorp Vault als vendorunabhängige Lösung.

Diese Lösungen unterstützen den gesamten Lebenszyklus statischer Zugangsdaten von Generierung Speicherung Abruf bis Widerruf. Dennoch bleibt das Grundproblem bestehen dass weiterhin statische Zugangsdaten verwendet werden.

Langfristige Strategie Verzicht auf langfristige Credentials in modernen Cloud-Architekturen

Die empfohlene Strategie besteht darin beim Aufbau moderner Cloud-Anwendungen auf langfristige Zugangsdaten zu verzichten.

Die Alternative ist der Einsatz kurzfristiger temporärer Credentials abhängig vom jeweiligen Anwendungsfall.

Allgemeine Cloud-Workloads Best Practices für temporäre Identitäten

Für typische Cloud-Workloads etwa Compute Storage Datenbanken Messaging Integration APIs sollten folgende Lösungen verwendet werden.

  • AWS IAM Role - Temporäre Berechtigungsidentität die Workloads oder Benutzer übernehmen können um ohne langfristige Zugangsdaten auf AWS Ressourcen zuzugreifen.
  • Managed Identities - Von Azure bereitgestellte Workload-Identitäten mit tokenbasierter Authentifizierung ohne Erstellung Speicherung oder Rotation von Credentials.
  • Entra Workload Identities - Kategorie nicht menschlicher Identitäten etwa Service Principals App Registrations und federierte Identitäten für Authentifizierung gegenüber Microsoft Entra ID auch außerhalb von Azure.
  • Google Managed Workload Identities - Kurzlebige automatisch verwaltete Identitäten für sichere Authentifizierung ohne langfristige Service Account Keys.

Managed Kubernetes Zugriff von Pods auf Cloud-Services sicher gestalten

Für Pods in Managed Kubernetes-Umgebungen sollten folgende Lösungen verwendet werden:

Externe und föderierte Identitäten Zugriff über OIDC mit kurzfristigen Credentials

Wenn externen oder föderierten Identitäten über OIDC temporärer Zugriff auf Cloud-Ressourcen gewährt werden soll eignen sich folgende Lösungen:

AI Agents Sichere Identitätsmodelle für agentenbasierte Cloud-Systeme

Für Szenarien in denen AI Agents Zugriff auf Cloud-Ressourcen benötigen eignen sich folgende Lösungen:
  • Amazon Bedrock AgentCore Identity - Spezieller IAM Service für Bedrock Agents mit zentralem Identitätsverzeichnis Authorisierung und Credential Provider
  • Microsoft Entra Agent ID (Preview) - Erweiterung der Entra Sicherheit für AI Agents mit Conditional Access Identity Protection Governance und Lifecycle Management
  • Vertex AI IAM Role - Standard GCP IAM Rollen/Service Accounts für Vertex AI Workloads zum Zugriff auf Ressourcen wie Storage oder BigQuery

Fazit Moderne Identity Strategien ohne statische Zugangsdaten

Beim Management nicht menschlicher Identitäten sollten immer temporäre Identitäten etwa Rollen oder Managed Identities gegenüber statischen oder langfristigen Zugangsdaten bevorzugt werden

Unterstützt ein Zielservice keine temporären Credentials sollten zumindest kurzfristige Zugangsdaten verwendet und regelmäßig rotiert werden

Zugangsdaten dürfen niemals im Code in Konfigurationsdateien oder in Git Repositories gespeichert werden

Dieser Artikel konzentriert sich auf Lösungen der großen Hyperscale Cloud Provider. Darüber hinaus existieren kommerzielle Plattformen mit ähnlichen Funktionen einschließlich zentraler Managementlösungen für nicht menschliche Identitäten über Multi-Cloud-Umgebungen hinweg