Langlebige Zugangsschlüssel
Ein statischer Zugangsschlüssel hat kein Ablaufdatum, kann also durchsickern und bleibt gültig.
Was ist Langlebige Zugangsschlüssel?
Ein statischer Zugangsschlüssel läuft nie ab, und diese einzelne Eigenschaft ist die Schwachstelle. Niemand überwacht Zugangsdaten, die ein Jahr lang problemlos funktioniert haben, und der in eine Build-Pipeline eingebundene Schlüssel ist meist derjenige, der durchsickert. Sie nehmen einen Schlüssel aus einem öffentlichen Build-Protokoll, bestätigen, dass er Monate später noch authentifiziert wird, und lesen ein Geheimnis der Produktionsdatenbank. Der Widerruf allein ist nicht die Lösung: Eine unterbrochene Pipeline erhält sonst wieder einen Ersatzschlüssel. Daher schreiben Sie die Vertrauensrichtlinie für kurzlebige, pro Lauf föderierte Zugangsdaten.
Was Sie lernen in Langlebige Zugangsschlüssel
- Ein statischer Schlüssel hat kein Ablaufdatum, daher ist die Zeitspanne zwischen Offenlegung und Missbrauch nur dadurch begrenzt, dass es jemandem auffällt.
- Der in eine Pipeline eingebundene Schlüssel ist derjenige, der durchsickert, und er bleibt meist länger gültig als die Person, die ihn erstellt hat, im Unternehmen tätig ist.
- Die Föderation vergibt pro Lauf kurzlebige Zugangsdaten, sodass kein dauerhaftes Geheimnis gestohlen werden kann.
- Rotation besteht aus zwei Schritten: die offengelegten Zugangsdaten widerrufen und einen funktionierenden Ersatz bereitstellen. Ein Widerruf allein unterbricht die Pipeline und wird zurückgenommen.
Langlebige Zugangsschlüssel — Trainingsschritte
-
Ein Schlüssel, den jemand zufällig veröffentlicht hat
Bob bricht nicht in Unternehmen ein. Er sammelt Zugangsdaten, die Unternehmen bereits versehentlich veröffentlicht haben, und probiert sie später aus, da die meisten davon noch funktionieren. Marnvex betreibt Datenplattformen für klinische Studien für pharmazeutische Auftraggeber. Sein Build-System veröffentlicht Konsolenprotokolle und Bob liest sie.
-
In ein Profil eintragen
Ein Schlüssel ist erst dann nützlich, wenn er mit einem Client verbunden ist. Bob fügt das Paar in ein benanntes lokales Profil ein, so wie jeder Entwickler ein zweites Konto konfiguriert.
-
Funktionsfähigkeit prüfen
Die erste Frage ist, ob der Schlüssel überhaupt noch authentifiziert. Er fragt nach dem Einfachsten, was es gibt.
-
Was es freischaltet
Eine CI-Identität ist nichts Besonderes, aber sie dient der Bereitstellung und kann daher lesen, was die Anwendung zum Ausführen benötigt. Bob fragt nach den gespeicherten Zugangsdaten der Produktionsdatenbank. Bob hat Zugangsdaten der Produktionsdatenbank aus einem Schlüssel, der vor einigen Monaten geleakt wurde.
-
Die Zeit als Schwachstelle
-
API-Aufrufe von unbekannter Quelle
Die Überwachung von Marnvex meldet API-Aufrufe des CI-Benutzers von einer bislang unbekannten Adresse.
-
Den Schlüssel finden
Der Ausgangspunkt ist der Schlüssel selbst: sein Alter, seine letzte Nutzung und die Frage, ob er jemals ein Ablaufdatum hatte.
-
Alter des Schlüssels
Der CI-Schlüssel ist der markierte.
-
Kein Ablaufdatum, 241 Tage alt
Die Details zum Schlüssel erklären, warum ein Leck im April Ende August immer noch ein Vorfall ist.
-
Den Schlüssel widerrufen
Eindämmung steht an erster Stelle. Der Widerruf des Schlüssels stoppt Bob mitten im Vorfall und führt zu einer kurzzeitigen Unterbrechung von CI, was der richtige Kompromiss gegenüber laufendem Missbrauch ist. Als Nächstes kommt der Ersatz.
Abdeckung der Sicherheits-Frameworks
CWE
- CWE-798 Use of Hard-coded Credentials
- CWE-522 Insufficiently Protected Credentials
- CWE-324 Use of a Key Past its Expiration Date
MITRE ATT&CK
- T1552.001 Unsecured Credentials: Credentials In Files
- T1078.004 Valid Accounts: Cloud Accounts
CIS Controls
- CIS 5 Account Management
- CIS 6 Access Control Management
NIST CSF
- PR.AT-02 Individuals in specialized roles are provided with awareness and training so that they possess the knowledge and skills to perform relevant tasks with cybersecurity risks in mind
- PR.AA Identity Management, Authentication, and Access Control