DeployBot erhält ein langlebiges Token, um Artefakte aus der Build-Pipeline zu veröffentlichen. Ein Job gibt das Token in den CI-Logs aus, ein Angreifer ruft die Log-Ausgabe ab, und dasselbe Token wird genutzt, um erfolgreich ein internes Paket von einer neuen IP-Adresse aus zu veröffentlichen. Der Angreifer benötigte weder das Passwort eines Mitarbeiters noch eine Phishing-Seite oder eine Benutzersitzung. Er brauchte lediglich einen Berechtigungsnachweis (Credential), der eine automatisierte Identität (Principal) repräsentierte.
Eine nicht-menschliche Identität ist die Identität hinter einer automatisierten Workload, einem Dienst, einer Pipeline, einem Gerät oder einem Agenten. In dieser Umgebung verfügt DeployBot über Berechtigungen, weil nachgelagerte Dienste sein Token akzeptieren – und nicht, weil ein Mensch bei jeder Anfrage eine Multi-Faktor-Authentifizierung (MFA) durchführt. Für die Verteidiger stellt sich daher eine operative Frage: Wie vergeben wir Berechtigungen mit eng gefasstem Geltungsbereich, wie rotieren wir diese, ohne den Produktionsbetrieb zu stören, und wie erkennen wir Missbrauch, wenn das Token seinen vorgesehenen Ausführungskontext verlässt?
Das einfachste Fehlerszenario besteht aus einer Eingabe und einem Ergebnis. DeployBot legt der Artefakt-Registry ein kopiertes Bearer-Token vor, und die Registry veröffentlicht ein Artefakt, da das Token weiterhin gültig ist und die erforderliche Berechtigung enthält. Ein Token beweist den Besitz, nicht jedoch den legitimen Ort oder Prozess, durch den es erlangt wurde – es sei denn, das zugrundeliegende Identitätsdesign sieht entsprechende Überprüfungen vor.
Regel für Sicherheitsgrenzen Ein Berechtigungsnachweis für nicht-menschliche Identitäten muss die Identität (den Principal) eindeutig bestimmen, deren Befugnisse einschränken und auch nach der Ausstellung überwachbar bleiben.
Das Leck beim Token ist deshalb von Bedeutung, weil DeployBot nur einen von mehreren Identitätspfaden in prod-gke-1 darstellt. Im Kubernetes-Cluster laufen die Orders API, die Billing API und die Inventory API. Neben diesen Diensten ruft SupportAgent zugelassene Support-Tools auf, ETLBot importiert Daten, und DeployBot erstellt und veröffentlicht Artefakte. Jede dieser Identitäten erzeugt Autorisierungsentscheidungen, einen Lebenszyklus für Berechtigungsnachweise sowie Nachweise, die von den Verteidigern aufbewahrt werden müssen.
Die Angriffsfläche beschränkt sich nicht auf den Cluster allein. Anfragen überschreiten die Cluster-Grenze sowie die Service-Mesh-Grenzen zwischen Workloads und interagieren mit der Artefakt-Registry, dem Secrets-Speicher, dem Identitätsanbieter und Autorisierungsserver sowie den APIs externer SaaS-Anbieter. Ein an einer Grenze kopierter Berechtigungsnachweis kann an einer anderen akzeptiert werden, wenn Richtlinien ihn als hinreichenden Nachweis anerkennen, ohne Aussteller, Zielgruppe, Workload, Herkunft oder zulässige Aktion zu berücksichtigen. Die nachfolgend beschriebene Umgebung bietet einen einheitlichen Ansatzpunkt für die späteren Kontrollmechanismen.
Verfolgen wir nun, an welchen Stellen Berechtigungsnachweise und Token diese Grenzen überschreiten:
Dieses Diagramm veranschaulicht, wie sich Berechtigungen mittels Tokens über mehrere Systeme hinweg bewegen, wobei jedes System nur einen Teil des Anforderungspfads protokolliert.
Da das Inventar jeden Berechtigungspfad auflistet, können wir das Fehlerszenario modellieren, bevor wir eine Schutzmaßnahme auswählen. Ein aus einem Repository oder CI-Protokoll durchgesickerter API-Schlüssel ermöglicht es einem Angreifer, die Identität des berechtigten Subjekts (Principal) bis zum Widerruf des Schlüssels zu übernehmen. Ein gestohlenes OAuth-Client-Secret kann zur Erstellung neuer Zugriffstokens (Access Tokens) verwendet werden. Ein wiederverwendetes (Replay-)Token könnte von einem unerwarteten Netzwerk oder einer unerwarteten Laufzeitumgebung aus funktionieren. Dies sind unterschiedliche Diebstahlpfade, doch alle überschreiten dieselbe Grenze: Ein externer Akteur präsentiert Anmeldeinformationen, die eigentlich für eine kontrollierte Workload vorgesehen sind.
Ein zu weit gefasster Geltungsbereich (Scope) verändert die Auswirkungen im Falle eines Diebstahls. Wenn ein SupportAgent aufgrund einer umfassenden Berechtigung sowohl Abrechnungsdaten lesen als auch ein Tool für Rückerstattungen aufrufen kann, könnte eine durch eine Eingabe (Prompt) ausgelöste Tool-Anforderung oder eine kompromittierte Agentenkomponente eine Aktion bewirken, die über die eigentlich für den Anforderer vorgesehene Befugnis hinausgeht. Hierbei handelt es sich um das Problem des Confused Deputy (irrtümlich handelnden Stellvertreters): Ein Dienst mit legitimen Befugnissen führt eine Aktion für einen nicht vertrauenswürdigen oder unzureichend autorisierten Aufrufer aus. Die Lösung besteht nicht bloß in einer stärkeren Authentifizierung. Der Tool-Aufruf erfordert eine explizite Richtlinie, die das anfordernde Subjekt, die Zielressource und den zulässigen Vorgang miteinander verknüpft.
Der Rotationsprozess birgt das Risiko eines weniger offensichtlichen Fehlers. Ein Secrets-Speicher könnte bereits die neue Anmeldeinformation enthalten, während ETLBot weiterhin ein zwischengespeichertes (gecachedes) altes Secret verwendet; alternativ könnte ein nachgelagerter SaaS-Anbieter beide Versionen länger akzeptieren als geplant. Die Rotation ist erst dann abgeschlossen, wenn die alte Anmeldeinformation keine Anforderungen mehr autorisieren kann und die Workload nachgewiesen hat, dass sie die neue Information nutzen kann.
Die folgende Übersicht ordnet jeder Bedrohung entsprechende Präventionsmaßnahmen und Nachweisquellen zu:
Der nachstehende Vergleich ordnet jedem Fehlerfall im Zusammenhang mit Anmeldeinformationen die jeweilige Grenze, die Präventionsmaßnahme und die Nachweisquelle zu.