Offengelegte Zugangsdaten: Meldungen sicher abschließen

Sie können eine Meldung zu offengelegten Zugangsdaten abschließen, wenn Sie erklären können, was die Offenlegung beendet hat, wodurch das alte Secret ungültig wurde, was eine Wiederholung verhindert und wie Sie möglichen Missbrauch geprüft haben. Halten Sie die Nachweise und noch offene Arbeiten getrennt fest. Eine nicht mehr öffentlich zugängliche Downloadseite oder eine erfolgreiche Bereitstellung beantwortet nur einen Teil dieser Fragen.

Dafür brauchen Sie keine große Abteilung zur Bearbeitung von Sicherheitsvorfällen. Sie brauchen eine verantwortliche Person, die eine ausgeführte Maßnahme von einem überprüften Ergebnis unterscheidet, und einen Abschlussvermerk, den die nächste Person versteht, ohne fünf Gesprächsverläufe zusammensuchen zu müssen.

Was zeigt die Baseten-Offenlegung über den Abschluss einer Meldung?

Den öffentlichen Zugriff zu sperren und Zugangsdaten ungültig zu machen, sind zwei verschiedene Maßnahmen. Eine aktuelle Diskussion auf Hacker News liefert dafür ein konkretes Beispiel, obwohl der Vorfall selbst schon länger zurückliegt.

In einem am 1. September veröffentlichten Bericht beschrieb Strix, im Juli einen funktionsfähigen GitHub-Token in einem Container-Image von Baseten gefunden zu haben. Laut dem dort dokumentierten Ablauf ging die Meldung am 13. Juli ein. Am folgenden Morgen schränkte Baseten den Zugriff auf das Registry-Projekt ein; Strix meldete jedoch, dass der Token weiterhin funktionierte. Am Nachmittag bestätigte Basetens Sicherheitsteam den Austausch des Tokens. Der Bericht lobt die Reaktion des Teams und hält fest, dass die übrigen Befunde am 17. Juli abgeschlossen wurden. Einen unabhängigen Test des alten Tokens nach dem Austausch beschreibt er nicht. Zum Bericht von Strix.

Die Diskussion auf HN rückte diesen Bericht erneut in den Blick. Es geht um eine Lehre aus einem offengelegten Vorfall vom Juli, nicht um die Behauptung eines neuen Einbruchs.

Die entscheidende Frage für die Verantwortlichen lautet: Was genau bedeutet „behoben“ bei Ihrer Meldung? Die für die Infrastruktur zuständige Person meint vielleicht, dass der Download gesperrt ist. Die für Identitäten zuständige Person meint, dass die Zugangsdaten ungültig sind. Die Einsatzleitung untersucht womöglich noch, was vor diesen beiden Änderungen geschah.

Weisen Sie jede Abschlussfrage einer verantwortlichen Person zu

Prüfen Sie bei einer Meldung zu offengelegten Zugangsdaten vier Fragen getrennt. Das ist unsere Empfehlung für die Praxis, kein formaler Standard und keine Zusicherung, dass jeder Vorfall nach demselben Ablauf bearbeitet werden kann.

Eindämmung und Untersuchung können parallel erfolgen. Warten Sie mit dringenden Maßnahmen nicht auf einen fertig formulierten Bericht. Die Tabelle hilft, die laufenden Arbeiten nachvollziehbar zu dokumentieren. Sie ist keine Warteschlange, in der eine Person auf die andere warten muss.

In einem kleinen Startup kann eine Person mehrere dieser Rollen übernehmen. Tragen Sie ihren Namen trotzdem bei jeder Antwort ein. So bleibt eine Übergabe möglich, wenn der Vorfall über einen Schichtwechsel, einen Urlaub oder den letzten Arbeitstag einer externen Fachkraft hinaus andauert.

Legen Sie fest, wer über den Abschluss entscheidet. Die für die Meldung verantwortliche Person sollte die Antworten zusammentragen. Sie sollte nicht stillschweigend anstelle eines Administrators entscheiden, der die Änderung an den Zugangsdaten noch nicht bestätigt hat.

Beenden Sie die Offenlegung, ohne Bereinigung mit Widerruf gleichzusetzen

Beschreiben Sie die beseitigte Offenlegung als klar abgegrenztes Ergebnis: Eine bestimmte Datei, ein Image, ein Protokoll oder ein Endpunkt ist für den Personenkreis, der zuvor darauf zugreifen konnte, nicht mehr verfügbar. Halten Sie fest, welchen Zugangsweg Sie geprüft haben und welches Artefakt darüber erreichbar war.

Notieren Sie bei einem Container-Image neben einem lesbaren Tag auch eine eindeutige, beständige Artefaktkennung. Bei einem veröffentlichten Protokoll nennen Sie den Lauf und den Zugangsweg. Das ist unsere Empfehlung für die Dokumentation: Mit „die Registry ist privat“ kann die nächste prüfende Person weniger anfangen als mit einem konkret benannten Artefakt und einer beschriebenen Zugriffsprüfung.

GitHubs Anleitung zum Entfernen sensibler Daten stellt den Widerruf oder Austausch eines Secrets vor die Bereinigung der Repository-Historie. Sie erläutert auch, dass das Umschreiben der Historie Aufwand und Risiken mit sich bringt und nach Beseitigung des Zugriffsrisikos möglicherweise nicht mehr nötig ist. Die Anleitung bezieht sich auf Git-Repositories. Die grundsätzliche Unterscheidung zwischen dem Ungültigmachen von Zugangsdaten und dem Entfernen von Kopien hilft aber auch bei anderen Artefakten. GitHubs Anleitung zur Entfernung sensibler Daten.

Machen Sie den Abschluss nicht von der unmöglichen Bedingung abhängig, dass nachweislich jede Kopie im Internet verschwunden ist. Dokumentieren Sie stattdessen die Entscheidung zur Bereinigung. Kann eine verbliebene Kopie noch Quellcode, Kundendaten oder ein anderes Secret offenlegen? Dann sind diese gesonderten Offenlegungen durch den Widerruf der betreffenden Zugangsdaten nicht behoben.

Bewahren Sie notwendige Untersuchungsnachweise an einem zugriffsbeschränkten Ort auf, während Sie unnötige Kopien entfernen. Die öffentliche Meldung, der Austausch mit der Forscherin oder dem Forscher und die interne Vorfalldokumentation müssen nicht dieselben Inhalte enthalten. Bezeichnen Sie die Zugangsdaten mit einer internen Kennung; fügen Sie nicht ihren vollständigen Wert in jede Nachricht ein.

Bleiben Sie bei Ihren Prüfungen innerhalb Ihrer Befugnisse. Eine Meldung zu Ihrem Dienst berechtigt Sie nicht automatisch dazu, Systeme eines Lieferanten zu testen. Unser Leitfaden zum Geltungsbereich von Sicherheitsscans beschreibt, wie Sie diese Grenze vor Beginn der Prüfungen klären.

Weisen Sie nach, dass die alten Zugangsdaten ungültig sind

Fragen Sie vor dem Abschluss gezielt nach den Zugangsdaten, die offengelegt wurden. „Wir haben einen neuen Token erstellt“ und „der alte Token ermöglicht keine Authentifizierung mehr“ sind unterschiedliche Aussagen.

GitHub dokumentiert, dass widerrufene oder abgelaufene Tokens nicht mehr zur Authentifizierung von Git- und API-Anfragen verwendet werden können. Laut der Dokumentation kann außerdem ein Ereignis zur Aufhebung der Autorisierung im Sicherheitsprotokoll erscheinen. Der Anbieternachweis ist damit nützlich; die Dokumentation verspricht jedoch nicht, dass in jeder Situation dasselbe Ereignis sichtbar wird. Ablauf und Widerruf von GitHub-Tokens.

Bitten Sie die für die Zugangsdaten verantwortliche Person, den Anbieter, die Kennung, den Zeitpunkt des Widerrufs und die Art der Bestätigung festzuhalten. Wo es sinnvoll ist, kann eine dazu befugte Person über einen freigegebenen Ablauf eine begrenzte Prüfung vornehmen. Entscheidend ist, zwischen einer Anbieterbestätigung, einem beobachteten Authentifizierungsergebnis und der Annahme eines Teammitglieds zu unterscheiden.

Verlangen Sie nicht pauschal einen erneuten Test durch externe Personen. Eine Forscherin oder ein Forscher ist möglicherweise nicht verfügbar oder darf keine weiteren Anfragen stellen. Ihr Team bleibt dafür verantwortlich, über die eigenen Administratoren und Systeme ausreichende Nachweise zu beschaffen.

OWASPs Anleitung zur Verwaltung von Secrets behandelt Widerruf, Ersatz und Löschung als getrennte Maßnahmen bei einem Vorfall. Sie fordert eine schnelle Eindämmung und die Möglichkeit, den Widerrufsstatus festzustellen. Berücksichtigen Sie diese Trennung bei der Planung: Einen abhängigen Dienst wiederherzustellen, ist eine betriebliche Aufgabe; die offengelegten Zugangsdaten unbrauchbar zu machen, ist das sicherheitsrelevante Ergebnis. OWASP Secrets Management Cheat Sheet.

Benennen Sie ausdrücklich jeden Übergangszeitraum, in dem beide Zugangsdaten funktionieren. Legen Sie fest, wer dafür verantwortlich ist und unter welcher Bedingung dieser Zeitraum endet. Eine erfolgreiche Funktionsprüfung der Anwendung ersetzt nicht die Bestätigung, dass die bisherigen Zugangsdaten ungültig geworden sind.

Ändern Sie den Prozess, der die Offenlegung verursacht hat

Die neuen Zugangsdaten müssen auf sichererem Weg in die Anwendung oder den Build gelangen. Sonst kann die nächste erfolgreiche Veröffentlichung dieselbe Meldung mit einem neuen Secret auslösen.

Docker warnt davor, Build-Secrets über Dockerfile-Argumente oder Umgebungsvariablen zu übergeben, weil sie im fertigen Image verbleiben können. Die empfohlenen Secret-Mounts stellen Zugangsdaten einer Build-Anweisung nur vorübergehend zur Verfügung. Docker-Anleitung zu Build-Secrets.

Auch die Build-Prüfung SecretsUsedInArgOrEnv weist darauf hin, dass Secrets in den Image-Metadaten verbleiben können. Das ist ein guter Grund, das erzeugte Artefakt zu prüfen, statt nur die geänderte Quellcodezeile anzusehen. Dockers Referenz zur Build-Prüfung.

Unser empfohlener Abnahmevermerk besteht aus zwei Teilen: Was wurde an der Handhabung von Secrets geändert, und was wurde am neu erzeugten Ergebnis geprüft? Eine Codeprüfung kann zeigen, dass eine Änderung plausibel ist. An einem neu erzeugten Artefakt prüfen Sie, ob es den Fehler noch enthält, den Sie beseitigen wollten.

Richten Sie die Prüfung auf die konkrete Offenlegung aus. Hat ein Build URLs mit Zugangsdaten in eine Konfiguration geschrieben, prüfen Sie diese Ausgabe. Hat ein Veröffentlichungsjob seine Umgebungsvariablen offengelegt, prüfen Sie das entstandene Protokoll und dessen Zugriffsrechte. Vermeiden Sie einen pauschalen Vermerk wie „Scanner ohne Befund“, der weder den Prüfumfang noch das untersuchte Artefakt nennt.

Überdenken Sie auch, welche Rechte der Ersatz tatsächlich benötigt. GitHub empfiehlt GitHub Apps für Zugriffe im Namen einer Organisation oder für langfristige Integrationen. Wenn Sie weiterhin einen persönlichen Zugriffstoken verwenden, wählen Sie dessen Berechtigungen und Gültigkeitsdauer bewusst. Ein anderer Typ von Zugangsdaten belegt allein noch nicht, dass die Rechte angemessen sind. GitHubs Anleitung zu persönlichen Zugriffstokens.

Nach der Korrektur des unmittelbaren Fehlers können weitere Härtungsmaßnahmen anstehen. Trennen Sie diese Arbeiten von der Aussage, mit der Sie die Meldung abschließen. „Der betroffene Build ist korrigiert; Maya prüft bis Freitag die übrigen Build-Pipelines“ ist eine nachvollziehbare Entscheidung. „Die gesamte Handhabung von Secrets ist jetzt sicher“ lässt sich daraus nicht ableiten.

Untersuchen Sie die Auswirkungen und benennen Sie die Grenzen

Ein Widerruf beantwortet die Frage, ob die betreffenden Zugangsdaten weiterhin Zugriff ermöglichen. Er sagt nichts darüber aus, was geschehen ist, solange sie gültig waren.

GitHubs Anleitung zur Untersuchung von Sicherheitsvorfällen empfiehlt, Audit-Protokolle auf Aktivitäten des kompromittierten Tokens und unerwarteter Akteure zu prüfen sowie relevante Befunde zu offengelegten Daten auszuwerten. Sie weist außerdem darauf hin, dass sich ein Vorfall über mehrere Angriffswege entwickeln kann. Ein Fund von Zugangsdaten kann deshalb weitere Untersuchungen erfordern. GitHubs Untersuchungsbereiche.

Für Ihren Abschlussvermerk empfehlen wir eine kurze Beschreibung des Prüfumfangs. Nennen Sie die untersuchten Systeme, den verfügbaren Zeitraum, die prüfende Person und das Ergebnis. Ergänzen Sie, was sich nicht feststellen ließ. Leser sollten nicht erraten müssen, ob sich „nichts Auffälliges“ auf eine Woche vollständiger Aufzeichnungen oder wenige Stunden lückenhafter Protokolle bezieht.

Trennen Sie Beobachtung und Schlussfolgerung. Sie können in den verfügbaren Aufzeichnungen keine unerwartete Aktivität finden und trotzdem nicht den gesamten Offenlegungszeitraum abdecken. Schreiben Sie beides auf. Eine offen benannte Grenze hilft der Einsatzleitung zu entscheiden, ob weitere Arbeiten nötig sind.

Berücksichtigen Sie bei der Auswahl der Untersuchungsbereiche die damaligen Berechtigungen. Zugriff auf eine Deployment-Konfiguration wirft andere Fragen auf als reiner Lesezugriff auf ein einzelnes Paket. Halten Sie die Begründung für den Untersuchungsumfang fest, damit eine später prüfende Person ihn hinterfragen kann, ohne die gesamte Untersuchung zu wiederholen.

Zeigt die Untersuchung ein neues Problem, weisen Sie ihm eine eigene verantwortliche Person und eine Referenz zu. Der Abschluss der ursprünglichen Offenlegungsmeldung darf einen andernorts noch offenen Vorfall nicht aus der Dokumentation verschwinden lassen. Halten Sie umgekehrt eine im engeren Umfang gelöste Forschermeldung nicht auf unbestimmte Zeit offen, ohne zu erklären, auf welche gesonderte Entscheidung Sie noch warten.

Schreiben Sie einen Abschlussvermerk, den andere prüfen können

Ein guter Abschlussvermerk nennt das Ergebnis, die Nachweise und die offenen Arbeiten. Er sollte kurz genug für eine Übergabe und konkret genug für kritische Rückfragen sein.

GitHub macht diese Unterscheidung im eigenen Warnmeldungsablauf sichtbar: Das Entfernen eines Tokens aus einem Repository schließt die zugehörige Secret-Scanning-Warnung nicht automatisch. Die Anleitung sieht außerdem einen Abschlusskommentar vor, der in den Verlauf der Warnmeldung aufgenommen wird. Secret-Scanning-Warnungen abschließen.

Das folgende fiktive Beispiel zeigt das Format. Organisation, Kennungen, Zeitangaben und Befunde sind erfunden; sie beschreiben weder Baseten noch einen Kunden von Kit.

Meldung: Offengelegte Build-Zugangsdaten im Artefakt release-184.

Offenlegung: Lena hat den Zugriff auf das betroffene Artefakt um 10:15 UTC eingeschränkt. Eine autorisierte Zugriffsprüfung bestätigte, dass es über den gemeldeten öffentlichen Zugangsweg nicht mehr abrufbar war. Weitere Artefakte wurden im Rahmen der verknüpften Bestandsaufnahme geprüft.

Alte Zugangsdaten: Arun hat die Zugangsdaten mit der Kennung build-reader-previous um 10:18 UTC widerrufen. Der Anbieternachweis und das Ergebnis der freigegebenen Prüfung liegen im zugriffsbeschränkten Vorfallsordner. Abhängige Dienste verwenden inzwischen den Ersatz.

Wiederholung verhindern: Lena hat die Handhabung von Secrets im Build geändert. Das Ersatzartefakt und seine Metadaten wurden auf die gemeldete Art der Offenlegung geprüft. Die Nachweise nennen das neue Artefakt und den Prüfzeitpunkt.

Auswirkungen: Jo hat die verfügbaren Identitäts- und Repository-Aufzeichnungen für den angegebenen Offenlegungszeitraum geprüft. Darin wurde keine unerwartete Nutzung festgestellt. Frühere Download-Protokolle der Registry waren nicht verfügbar. Deshalb lässt sich nicht feststellen, wer ältere Kopien abgerufen hat.

Entscheidung: Jo hat den Abschluss dieser Meldung freigegeben. Die verknüpfte Aufgabe zur Verbesserung der Protokollierung bleibt Arun zugewiesen. Die Nachricht an die meldende Person beschreibt die abgeschlossene Behebung und die Grenze der Untersuchung, ohne Zugangsdaten zu enthalten.

Beachten Sie, was dieser Vermerk nicht behauptet: dass sämtliche Kopien verschwunden seien, dass der Forscher jede Maßnahme persönlich bestätigt habe oder dass eine Protokollsuche ohne Befund beweise, niemand habe auf das System zugegriffen.

Sie können dieselben Überschriften als leere Vorlage verwenden. Akzeptieren Sie „nicht zutreffend“ nur mit einer Begründung der zuständigen Person. Waren die gemeldeten Zugangsdaten beispielsweise schon ungültig, halten Sie fest, wie Sie das festgestellt haben und ob das offengelegte Artefakt weitere schützenswerte Inhalte enthält.

Lassen Sie den Vermerk vor der Abschlussfreigabe von einer zweiten Person lesen, wenn Ihr Team das leisten kann. Bitten Sie sie, einen Satz zu nennen, dessen Belege unklar sind. Diese kurze Gegenprüfung ist unser praktischer Vorschlag gegen missverständliche Übergaben, kein verpflichtender Zertifizierungsschritt.

Halten Sie Abschlussentscheidung und Austausch in Kit zusammen

Bewahren Sie die Zusammenfassung der Nachweise bei der Meldung auf, damit der Status eine nachvollziehbare Begründung hat. Ein später hinzukommendes Teammitglied sollte erkennen können, wer die Behebung als überprüft eingestuft hat und was diese Entscheidung umfasste.

Kit protokolliert Statuswechsel im Lebenszyklus einer Meldung mit handelnder Person, Zeitstempel und optionalem Kommentar. Ein berechtigtes Teammitglied kann die Behebung als überprüft markieren und eine Notiz ergänzen. Die Dokumentation zur Sichtung erläutert den Ablauf.

Diese Aktion hält eine menschliche Entscheidung fest. Kit widerruft die offengelegten Zugangsdaten nicht, erzwingt die vier obigen Prüfungen nicht und verlangt vor diesem Statuswechsel keine Bestätigung durch den Forscher. Ihr Team muss die Nachweise beschaffen und entscheiden, was ausreicht. Fassen Sie das Ergebnis in der Notiz zusammen und verweisen Sie auf zugriffsbeschränkte Unterlagen, in denen die Einzelheiten aufbewahrt werden.

Die Unterhaltung zur Meldung unterstützt sowohl interne Diskussionen als auch Nachrichten an Forscherinnen und Forscher. Halten Sie technische Untersuchungsdetails im dafür geeigneten Kanal fest. Teilen Sie der meldenden Person anschließend mit, welche Behebung abgeschlossen ist und ob angefragte weitere Schritte innerhalb des vereinbarten Geltungsbereichs liegen. Der Leitfaden zur Kommunikation mit Forschern beschreibt diese Sichtbarkeitseinstellungen.

Beginnen Sie bei der nächsten Meldung zu offengelegten Zugangsdaten mit vier Überschriften: Offenlegung, alte Zugangsdaten, Wiederholung verhindern, Auswirkungen. Weisen Sie die Zuständigkeiten schon während der Bearbeitung zu. Beim Abschluss sollte der Vermerk erklären, was Sie wissen, ohne dass jemand erraten muss, was „behoben“ bedeutete.