Grauzone der Cloud : Wer trägt das Risiko von verwalteten Identitäten?
Unzählige Stunden können damit verbracht werden, MFA zu erzwingen und Berechtigungen zu sperren. Aber was ist mit den Identitäten, die Sie nicht selbst verwalten? Denen, die Ihr cloud für Sie erstellt und verwaltet?
Diese "CSP-verwalteten nicht-menschlichen Identitäten" sind die automatisierten Roboter, die Dienste im Hintergrund ausführen. Sie sind zwar unverzichtbar, aber die Art und Weise, wie AWS, Google Cloud und Microsoft sie eingerichtet haben, schafft einzigartige, nicht offensichtliche Sicherheitsrisiken. Wenn Sie denken, dass eine sichere Einrichtung in AWS auch in Azure sicher ist, werden Sie vielleicht überrascht sein.
Nehmen wir uns einen Moment Zeit, um die einzigartigen Risiken der einzelnen cloud aufzuschlüsseln.
AWS: Das Problem des "verwirrten Abgeordneten" (Sie sind schuld)
In AWS sind die Dienste global und werden von allen gemeinsam genutzt. Dadurch entsteht ein klassisches Multi-Tenant-"verwirrter Stellvertreter"-Risiko. Ein Angreifer in seinem eigenen Konto kann einen AWS-Service möglicherweise so austricksen, dass er seine Berechtigungen für den Zugriff auf die Ressourcen Ihres Kontos verwendet.
- Der Haken an der Sache: Das einzige, was dies verhindert, ist eine spezielle Einstellung in Ihren IAM-Ressourcenrichtlinien, die als Bedingungsschlüssel bezeichnet wird (z. B. aws:SourceArn).
- Die Realität: Es kann sehr schwierig sein, Konditionsschlüssel richtig zu verwenden. Dies hinterlässt eine große, oft übersehene Lücke, die die Last der Prävention direkt auf Ihre Schultern legt.
Google Cloud: Das "Black Box"-Problem (Es liegt an ihnen)
Google wählt den entgegengesetzten Ansatz. Die von den CSPs verwalteten nicht-menschlichen Identitäten (Service-Agenten) sind mandantenfähig und in von Google kontrollierten Projekten eingeschlossen. Sie sind unantastbar, was den in anderen Clouds beobachteten Missbrauch von Anmeldeinformationen verhindert.
- Der Haken an der Sache: Dies führt zu einem anderen Problem: dem Missbrauch des transitiven Zugriffs. Ein Dienst kann von Natur aus so mächtig sein, dass er ein attraktives Ziel darstellt. Ein Angreifer kann ihn dazu bringen, in seinem Namen zu handeln, indem er eine Überprüfung seiner eigenen Berechtigungen umgeht.
- Die Realität: Genau das ist mit dem Document AI-Dienst passiert. Google hat es zwar behoben, aber Sie haben hier keine direkte Kontrolle. Sie müssen darauf vertrauen, dass der Anbieter alle seine Dienste sicher gestaltet hat.
Microsoft Entra ID: "Service Principal Hijacking" (ein Risiko der Gegenwart)
Microsoft verwendet ein hybrides Modell, bei dem ein lokales Principal für die Microsoft-eigene Erstanbieteranwendung in Ihrem Tenant lebt. In der Vergangenheit hatte dieses Design einen entscheidenden Fehler: Ein Administrator (z. B. der Anwendungsadministrator) konnte seine eigenen Anmeldeinformationen zum Dienstprinzipal hinzufügen und seine Berechtigungen erweitern.
- Der Haken an der Sache: Microsoft hat einen Fix namens appInstancePropertyLock. Wenn sie aktiviert ist, verhindert sie diese Art des Hijackings.
- Die Realität: Die Korrektur ist nicht rückwirkend. Microsoft muss die mehr als 300 Standardanwendungen, die in Kundenmietverträgen installiert sind, manuell aktualisieren. Zwar wurden viele von ihnen mit dieser Eigenschaft versehen, doch wie Forscher kürzlich zeigten, sind kritische Anwendungen wie Office 365 Exchange Online weiterhin ungeschützt, was dieses Risiko zum unmittelbarsten und folgenreichsten der drei Risiken macht.
Das Ergebnis?
Sicherheit ist in der cloud kein Einheitsmodell. Die Bedrohung, über die Sie sich bei AWS Gedanken machen müssen, ist bei Google kein Thema, und das größte Risiko bei Entra ID hat eine ganz andere Ursache.
- In AWS? Überprüfen Sie Ihre IAM-Richtlinien auf fehlende Zustandsschlüssel. Verwirrte Stellvertreter-Probleme können Sie verhindern.
- In der Google Cloud? Die Sicherheit der Service-Agenten liegt allein in den Händen von Google. Halten Sie sich über Schwachstellen auf dem Laufenden, aktivieren Sie nur die minimal erforderlichen Dienste und achten Sie auf ungewöhnliche Aktivitäten.
- In Microsoft Entra ID? Überwachen Sie, ob Anmeldeinformationen zu lokalen Service Principals hinzugefügt werden. Bleiben Sie auf dem Laufenden über Service Principal Hijacking, das in freier Wildbahn gemeldet wird
Die Bedrohungen sind nicht einheitlich. Die kritischste Bedrohung in einer cloud kann in einer anderen kein Problem darstellen. Verteidiger und Forscher müssen ihre Strategien anpassen und erkennen, dass es in einer cloud keinen 1:1-Ansatz für Sicherheitskontrollen gibt.
Weitere Informationen zu den Forschungsergebnissen, die hinter diesen Bedrohungsmodellen und unterschiedlichen Architekturen stehen, finden Sie in dem begleitenden Whitepaper "A Comparative Threat Model of CSP-Managed Machine Identities".