Salesforce machte die OAuth-Token-Verwahrung von Heroku zu einem Rechenschaftstest für Entwicklerplattformen

Zusammenfassung

• Der GitHub-Integrationsvorfall von Heroku im Jahr 2022 ist wichtig, weil OAuth-Token keine gewöhnlichen Passwörter sind; sie sind delegierte Autorität, die Quellcode-Repositories, Bereitstellungspipelines, Build-Systeme, Kundenanwendungen und nachgelagerte Softwarenutzer verbinden können.
• GitHub warnte öffentlich, dass ein Angreifer gestohlene OAuth-Benutzertoken verwendet hatte, die für Heroku und Travis CI ausgestellt wurden, während die Kommunikation von Heroku zu dem Vorfall von Kunden verlangte, die Drehrichtung zu befolgen, während sich Untersuchung, Widerruf und Zurücksetzung von Anmeldeinformationen entwickelten.
• Die Frage der Rechenschaftspflicht ist nicht nur, ob Heroku schließlich Schlüssel rotiert oder Integrationen wiederhergestellt hat. Es geht darum, wer die Token-Verwahrung, die Kundenbenachrichtigung, das Verhalten der GitHub-Anwendung, den Zugriff auf Quellcode, die CI/CD-Vertrauensgrenzen und die Nachweise nach dem Vorfall kontrollierte.
• Dieser Artikel behandelt Heroku, GitHub, Travis CI, Salesforce, IETF, NIST, CISA und MITRE als separate Beweisquellen; keine öffentliche Quelle wird als vollständiger interner forensischer Datensatz behandelt.
• Die dauerhafte Lehre ist, dass der Komfort von Entwicklerplattformen ein Verwahrungsprotokoll mit sich führen muss: Welches Integrationstoken existiert, warum es existiert, welchen Umfang es hat, wo es gespeichert ist, wer es widerrufen kann und welche Beweise Kunden erhalten, wenn das Token verdächtig wird.

Warum dieser Fall in eine Risiko- und Rechenschaftsakte gehört

Salesforce machte die Heroku-OAuth-Token-Verwahrung zu einem Test für die Rechenschaftspflicht von Entwicklerplattformen, weil Heroku eine verwaltete Entwicklerplattform ist, deren Wert auf Vertrauen an der Grenze zwischen Code, Bereitstellung, Identität und Betrieb beruht. Kunden nutzen Heroku, um Anwendungen mit Quellcode-Repositories zu verbinden, Code bereitzustellen, Build-Abläufe zu automatisieren, Teams zu verwalten, Add-ons auszuführen, Datendienste anzubinden und Produktionsworkloads zu betreiben. Eine Heroku-zu-GitHub-Integration ist daher keine kosmetische Annehmlichkeit.

Sie kann zu einer Brücke vom Quellcode-System eines Kunden zu einer Bereitstellungsplattform und von einer Bereitstellungsplattform zurück zum operativen Risiko des Kunden werden.

Der öffentliche Auslöser von 2022 war sichtbar, weil GitHub eine Sicherheitswarnung unterhttps://github.blog/news-insights/company-news/security-alert-stolen-oauth-user-tokens/veröffentlichte, die gestohlene OAuth-Benutzertoken beschrieb, die für Heroku und Travis CI ausgestellt wurden. Herokus eigene Statusvorfallseite unterhttps://status.heroku.com/incidents/2413und Herokus öffentliche Vorfallüberprüfung vom April 2022 unterhttps://blog.heroku.com/april-2022-incident-reviewstellen die Angelegenheit aus Sicht der Plattform dar. Travis CIs Sicherheitsbulletin unterhttps://www.travis-ci.com/blog/2022-04-15-security-bulletin/liefert eine weitere betroffene Integrationsspur. Diese Quellen legen die öffentlichen Konturen fest: OAuth-Token, die mit Entwicklerworkflows verbunden sind, Kundenbenachrichtigung, Untersuchungsaktualisierungen und eine Abfolge von Schutzmaßnahmen.

Der Fall ist wichtig, weil OAuth die Form der Rechenschaftspflicht verändert. Ein gestohlenes Passwort kann oft über ein einzelnes Benutzerkonto erklärt werden. Ein gestohlenes OAuth-Token kann delegierte Autorität darstellen, die über den Moment hinaus Bestand hatte, in dem der Benutzer zuletzt über die Zustimmung nachgedacht hat. Es kann Repository-Zugriff, automatisierten Workflow-Zugriff, API-Umfang, Metadatenzugriff, Organisationsmitgliedschaft oder Bereitstellungsautorität mit sich bringen. IETF OAuth 2.0-Material unterhttps://datatracker.ietf.org/doc/html/rfc6749und die OAuth-Sicherheits-Best-Practice-Aufzeichnung unterhttps://datatracker.ietf.org/doc/html/rfc9700sind keine Vorfallberichte über Heroku, aber sie helfen zu definieren, warum Token-Ausstellung, Umfang, Speicherung, Rotation, Widerruf, Replay-Resistenz und Client-Vertrauen wichtig sind.

Die Rechenschaftsakte sollte Heroku, Salesforce, GitHub, Travis CI und Kunden nicht zu einem Akteur vereinheitlichen. Salesforce besaß Heroku als Geschäft und Marke. Heroku kontrollierte das Plattformintegrationsdesign, die Kundenkommunikation, die Handhabung von Anmeldeinformationen auf seiner Plattform und die Beweise, die es veröffentlichen konnte. GitHub kontrollierte seine eigene Untersuchung, den Token-Widerruf, die Quellhost-Beweise, die OAuth-Anwendungssteuerungen und die kundenorientierte Sicherheitswarnung. Travis CI kontrollierte seinen betroffenen Integrationskanal und die Kundenkommunikation.

Kunden kontrollierten ihre eigenen Repository-Berechtigungen, Bereitstellungsentscheidungen, geheime Rotation, Audit-Überprüfung und Reaktion auf Anweisungen. Nachgelagerte Softwarenutzer trugen Risiken, wenn Quellcode-Zugriff oder Bereitstellungsvertrauen zu späteren Expositionen führte.

Diese Rollenverteilung ist wichtig, weil Entwicklerplattformen geteilte Verantwortung schaffen, ohne immer geteilte Beweise zu liefern. Heroku-Kunden konnte gesagt werden, sie sollen Anmeldeinformationen rotieren oder Repositories überprüfen, aber sie konnten nicht unabhängig jeden Heroku-seitigen Token-Speicherpfad oder GitHub-seitigen Angreiferpfad rekonstruieren. GitHub-Benutzer konnten eine OAuth-Anwendung widerrufen, aber sie wussten möglicherweise nicht, welche Heroku-Bereitstellungspipeline, -Anwendung oder -Team Ersatzzugriff benötigte.

Ein Beschaffungsbeauftragter konnte fragen, ob die Plattform akzeptabel blieb, aber die Entscheidung hing von technischen Details ab, die nicht alle öffentlich waren. Die rechenschaftspflichtige Frage ist daher die Beweiszuweisung: Was wusste jeder Akteur, was konnte jeder Akteur beweisen und was mussten Kunden tun, während Unsicherheit bestand?

Der öffentliche Datensatz zeigt auch, warum Entwicklertools-Vorfälle zur Rechenschaftspflicht der Softwarelieferkette gehören, nicht nur zur Rechenschaftspflicht der Kontosicherheit. Der Zugriff auf Quellcode ist der Anwendungssicherheit, Geheimnissen, CI/CD-Jobs, Build-Artefakten, Bereitstellungsanmeldeinformationen und Produktveröffentlichungen vorgelagert. Die Technik der Anwendungszugriffstoken von MITRE ATT&CK unterhttps://attack.mitre.org/techniques/T1528/und die Technik der alternativen Authentifizierungsmaterialien unterhttps://attack.mitre.org/techniques/T1550/sind nützliche Vokabeln, da sie Token-Missbrauch von gewöhnlichem Credential-Raten unterscheiden. CISAs Materialien zur sicheren Entwicklung (Secure by Design) unterhttps://www.cisa.gov/securebydesignund das NIST-Secure-Software-Development-Framework unterhttps://csrc.nist.gov/pubs/sp/800/218/finalhelfen zu erklären, warum Quellcode-Verwahrung und Build-System-Vertrauen als Produktionskontrollen behandelt werden müssen.

Dieser Artikel beansprucht keinen Zugriff auf private Heroku-Protokolle, GitHub-Privat-Repository-Auditdaten, interne Aufzeichnungen von Travis CI, kundenbezogene Mitteilungen, Strafverfolgungskommunikation oder Salesforce-Vorstandsmaterialien. Er verwendet die öffentliche Akte, um zu fragen, ob die Beweise praktische Kontrolle sichtbar machten.

Ein starker Rechenschaftsnachweis würde nicht nur zeigen, dass Token widerrufen wurden, sondern auch, wann die verdächtige Aktivität erkannt wurde, welche Bereiche betroffen waren, welche Kunden handeln mussten, welcher Repository-Zugriff bestätigt oder ausgeschlossen wurde, welche Geheimnisse möglicherweise offengelegt wurden, wann Anmeldeinformationen rotiert wurden und was sich geändert hat, damit derselbe Token-Verwahrungspfad nicht stillschweigend wiederholt werden konnte.

OAuth-Zustimmung wird nach dem ersten Klick zur Verwahrung

Der erste betriebliche Fehler in vielen OAuth-Überprüfungen besteht darin, die Zustimmung als einmalige Benutzerentscheidung zu betrachten. In einer Entwicklerplattform wird aus Zustimmung Verwahrung. Sobald ein Benutzer einer Anwendung den Zugriff auf ein Repository autorisiert, übernehmen die Plattform, der Identitätsanbieter, der Quellcode-Host und der Kundenadministrator fortlaufende Verpflichtungen. Das Token hat einen Lebenszyklus. Es wird ausgestellt, gespeichert, aktualisiert, verwendet, protokolliert, eingeschränkt, widerrufen, ersetzt und schließlich vergessen oder zurückgezogen.

Der Heroku-Vorfall ist wichtig, weil der öffentliche Datensatz die Kunden zwang, über diesen Lebenszyklus nachzudenken, nachdem die Vertrauensentscheidung bereits in die Entwicklungsabläufe eingebettet war.

Githubs aktuelle OAuth-Dokumentation unterhttps://docs.github.com/en/apps/oauth-appsund die Anleitung zur Pflege von OAuth-Apps unterhttps://docs.github.com/en/apps/oauth-apps/maintaining-oauth-appssind nützlich, weil sie das Kontrollvokabular rund um OAuth-Anwendungen, Client-Geheimnisse, Callback-URLs, Eigentum und Anwendungsmanagement zeigen. Githubls Leitfaden für Enterprise-Audit-Protokolle unterhttps://docs.github.com/en/enterprise-cloud@latest/admin/monitoring-activity-in-your-enterprise/reviewing-audit-logs-for-your-enterprise/about-the-audit-log-for-your-enterprisezeigt, warum Organisationen Aktivitätsnachweise nach einem vermuteten Integrationsereignis benötigen. Herokus GitHub-Integrationsdokumentation unterhttps://devcenter.heroku.com/articles/github-integrationzeigt die kundensichtbare Funktionsoberfläche. Keines dieser Dokumente beweist genau, was 2022 geschah. Sie legen die Betriebsoberfläche fest, die Kunden sichern mussten.

Verwahrung bedeutet, dass die Plattform eine andere Reihe von Fragen beantworten muss als die gewöhnliche Betriebszeit. Wo wurden OAuth-Token gespeichert? Waren Refresh-Token oder Access-Token betroffen? Waren sie verschlüsselt, segmentiert oder nach Mandanten isoliert? Welcher Dienst oder welche Datenbank konnte sie lesen? Welche Überwachung würde eine ungewöhnliche Nutzung anzeigen? Wer konnte sie widerrufen? Welche Kundenaktion war nach dem Widerruf erforderlich? Konnte Heroku ohne erneute Zustimmung des Kunden von GitHub aus bereitstellen?

Waren Build-Time-Geheimnisse, Konfigurationsvariablen, Repository-Inhalte oder Bereitstellungsschlüssel gefährdet? Welche dieser Antworten waren bei der ersten Benachrichtigung bekannt und welche wurden noch untersucht?

Diese Fragen sind nicht feindselig. Sie sind die Grundlage des Vertrauens. Eine Entwicklerplattform kann einen gültigen Grund haben, Token zu speichern, aber der Grund muss mit Schutznachweisen gepaart sein. Eine Plattform kann Token schnell widerrufen, aber der Widerrufsnachweis muss mit Kundenanweisungen gepaart sein. Eine Plattform kann die Rotation von Heroku-Benutzerpasswörtern oder API-Schlüsseln verlangen, aber Kunden müssen wissen, warum diese Rotation notwendig ist und ob auch eine Repository-Überprüfung erforderlich ist.

Eine Plattform kann sagen, dass für eine Teilmenge von Benutzern keine Kundenaktion erforderlich ist, aber diese Aussage sollte an eine technische Grenze gebunden sein.

Der öffentliche Datensatz von Heroku enthielt sich entwickelnde Kundenanweisungen. Diese Entwicklung ist nicht automatisch ein Fehler. Die Reaktion auf Vorfälle bewegt sich oft durch Phasen von Verdacht zu Bestätigung. Das Rechenschaftsproblem ist, ob die Phasen sichtbar genug sind, dass Kunden folgen können, ohne zu raten. Wenn die erste Nachricht eines Kunden eine Sache sagt und eine spätere Nachricht breitere Maßnahmen erfordert, sollte die Plattform erklären, welche Beweise sich geändert haben.

Wenn einem Kunden gesagt wird, er solle Anmeldeinformationen rotieren, sollte die Anweisung angeben, welche Anmeldeinformationen, welche Frist, welche Anwendungskontexte und welche Protokolle der Kunde überprüfen soll.

Die wirtschaftliche Dimension ist real. Entwicklerteams optimieren auf schnelle Integration, da manuelle Bereitstellung und Verwaltung von Anmeldeinformationen teuer sind. OAuth-Apps reduzieren Reibung. Aber wenn der Verwahrungspfad auf Anbieterseite versagt, erscheinen die Kosten des Komforts als Notfallarbeit: Überprüfung von Repositories, Rotation von Geheimnissen, Neuaufbau von Integrationen, Durchsuchen von Protokollen, Erklärung der Exposition gegenüber Kunden und Beantwortung von Prüfern. Die Ökonomie von Entwicklertools gehört daher in die Themenliste des Artikels.

Die Plattform, die von einfacher Integration profitiert, muss in Verwahrung, Widerruf und Beweise investieren.

Quellcode-Zugriff ist nicht dasselbe wie Produktionskompromittierung, aber er ist nicht harmlos

Der öffentliche Datensatz muss zwei schlechten Vereinfachungen widerstehen. Die erste ist zu sagen, dass gestohlene OAuth-Token automatisch bedeuten, dass Produktionsanwendungen kompromittiert wurden. Die zweite ist zu sagen, dass Quellcode-Zugriff harmlos ist, wenn keine Produktionsunterbrechung auftrat. Beide Aussagen sind schwach. Quellcode kann Anwendungslogik, Abhängigkeitsinformationen, interne Endpunkte, Bereitstellungsskripte, Konfigurationsmuster, Test-Fixtures, Kommentare, alte Geheimnisse, Infrastrukturnamen und Sicherheitsannahmen enthalten.

Gleichzeitig beweist Quellcode-Zugriff allein keinen Laufzeitzugriff, Datenraub oder Bereitstellungsmanipulation.

Githubs Warnung und Herokus Vorfallkommunikation sind wichtig, weil sie das Risiko des Quellcode-Zugriffs in die öffentliche Akte setzen. Ein Kunde mit verbundenen Repositories musste wissen, ob ein Angreifer private Repositories lesen konnte, ob Repositories gespeicherte Geheimnisse enthielten, ob Bereitstellungsanmeldeinformationen außerhalb von GitHub existierten, ob GitHub Actions, Heroku-Pipelines, Review-Apps oder CI-Jobs zusätzliche Materialien offenlegten und ob Repository-Level-Audit-Protokolle ungewöhnlichen Zugriff zeigten.

Wenn der Kunde Travis CI nutzte, konnten sich dieselben Fragen auf CI-Umgebungsvariablen und Build-Protokolle erstrecken.

NIST SP 800-218 unterhttps://csrc.nist.gov/pubs/sp/800/218/finalist nützlich, weil es sichere Softwareentwicklung als Lebenszyklus behandelt, nicht nur als Code-Schreiben. NIST SP 800-204D unterhttps://csrc.nist.gov/pubs/sp/800/204/d/finalhilft, Fragen zur Sicherheit von Cloud-nativen Anwendungen und Dienstidentität einzuordnen. NIST SP 800-53 Rev. 5 unterhttps://csrc.nist.gov/pubs/sp/800/53/r5/upd1/finalliefert Kontrollvokabular für Zugriffskontrolle, Prüfung, Konfiguration, Reaktion auf Vorfälle und Systemintegrität. Diese Materialien sind keine Heroku-spezifischen Ergebnisse. Sie sind Maßstäbe, um zu entscheiden, ob ein Vorfall auf einer Entwicklerplattform als Software-Lieferkettenereignis überprüft werden sollte.

Die entscheidende Grenze ist der Beweis. Wenn eine Plattform feststellen kann, dass ein OAuth-Token nur für ein bestimmtes Repository oder einen bestimmten Kundensatz verwendet wurde, sollte sie die Grundlage dieser Feststellung erläutern. Wenn sie aufgrund von Protokollierungsbeschränkungen nicht bestimmen kann, wer auf die Daten zugegriffen hat, sollte sie dies sagen. Wenn GitHub betroffene Benutzer basierend auf Token-Nutzung oder Repository-Zugriff benachrichtigen kann, sollte der öffentliche Datensatz identifizieren, was die Benachrichtigung bedeutet und was nicht.

Wenn Kunden ihre eigenen Protokolle überprüfen müssen, sollte der Anbieter angeben, welche Protokollquellen relevant sind.

Das öffentliche Risiko unterscheidet sich auch nach der Reife des Kunden. Ein großes Unternehmen verfügt möglicherweise über GitHub Enterprise-Audit-Protokolle, zentralisierte Geheimnisprüfung, Software-Kompositionsanalyse, CI/CD-Trennung und Incident-Response-Mitarbeiter. Ein kleinerer Heroku-Kunde hat möglicherweise eine einfache GitHub-Verbindung, ein oder zwei Betreuer und eine begrenzte Protokollaufbewahrung. Dasselbe Token-Ereignis schafft daher unterschiedliche Belastungen. Ein ausgereifter Rechenschaftsdatensatz geht nicht davon aus, dass jeder Kunde unabhängig Lücken in den Anbieternachweisen füllen kann.

Er gibt kleinen Teams praktische Schritte und großen Teams genügend technische Details, um die Überprüfung zu automatisieren.

Das nachgelagerte Publikum ist breiter als Heroku-Kontoinhaber. Wenn Quellcode-Zugriff Schwachstellen oder Geheimnisse offenlegt, können nachgelagerte Benutzer der Software des Kunden später betroffen sein, selbst wenn der ursprüngliche Plattformvorfall keine sofortige Ausfallzeit verursachte. Das bedeutet nicht, dass jeder nachgelagerte Benutzer geschädigt wurde. Es bedeutet, dass die Rechenschaftsanalyse den Risikopfad nachverfolgen muss: Token-Diebstahl, möglicher Repository-Zugriff, mögliche Quell- oder Geheimnisoffenlegung, möglicher CI/CD-Missbrauch, möglicher Produktionszugriff und möglicher nachgelagerter Schaden.

Jeder Schritt benötigt Beweise, bevor er zu einer Behauptung wird.

Benachrichtigungszeitpunkt ist Teil der Kontrolloberfläche

Die Kommunikation bei Vorfällen wird oft als Rechts- oder PR-Funktion behandelt, aber für Entwicklerplattformen ist sie betriebliche Kontrolle. Kunden können Token nicht widerrufen, Geheimnisse rotieren, Integrationen neu aufbauen oder Repositories überprüfen, bis sie wissen, was zu tun ist. Eine verzögerte, vage oder sich ändernde Mitteilung kann den Zeitraum verlängern, in dem Kunden exponiert oder unsicher sind. Eine schnelle, aber unvollständige Mitteilung kann unnötige Arbeit verursachen. Der Rechenschaftsmaßstab ist daher nicht einfach Geschwindigkeit. Es ist der Entscheidungsnutzen in jeder Phase.

Herokus Vorfallsseite unterhttps://status.heroku.com/incidents/2413ist nützlich, weil Statusaktualisierungen eine Abfolge zeigen und nicht nur eine einzige endgültige Aussage. Githubs Sicherheitswarnung liefert eine weitere Zeitlinie. Travis CIs Bulletin liefert eine dritte. Ein sorgfältiger Leser sollte diese Zeitlinien nicht zu einer perfekten Chronologie zusammenfassen, es sei denn, die Quellen unterstützen dies. Die nützliche Frage ist, wie sich die Mitteilung jedes Akteurs auf das Kundenhandeln auswirkte. Mussten Kunden die App-Autorisierung widerrufen? Mussten sie Heroku-API-Schlüssel rotieren? Mussten sie Heroku-Benutzerpasswörter rotieren? Mussten sie GitHub-Repositories überprüfen? Mussten sie CI-Umgebungsvariablen überprüfen? Mussten sie Bereitstellungs-Hooks neu aufbauen?

Die Antwort kann sich geändert haben, als Fakten auftauchten. Das ist akzeptabel, wenn die Änderungen erklärt werden.

Eine Mitteilung kann sagen: „Wir untersuchen einen möglichen Zugriff und werden zusätzliche Anweisungen geben.“ Sie kann sagen: „Wir haben Token widerrufen und Kunden müssen neu autorisieren.“ Sie kann sagen: „Wir setzen eine Passwortzurücksetzung voraus, da wir den Zugriff auf gehashte Anmeldeinformationen nicht ausschließen können.“ Sie kann sagen: „Wir haben keine Beweise für eine Kategorie gefunden, aber Kunden sollten ihre eigenen Protokolle auf diese Indikatoren überprüfen.“ Was die Rechenschaftspflicht schwächt, ist nicht die Unsicherheit. Was die Rechenschaftspflicht schwächt, ist die als Abschluss präsentierte Unsicherheit.

Die Kundenbenachrichtigung hat auch eine Segmentierungspflicht. Nicht jeder Heroku-Kunde nutzte die GitHub-Integration. Nicht jeder GitHub-Benutzer autorisierte Heroku. Nicht jeder Travis-CI-Benutzer hatte denselben Umfang. Nicht jedes Repository enthält sensibles Material. Eine nützliche Mitteilung unterscheidet zwischen betroffenen, möglicherweise betroffenen, nicht betroffenen und unbekannten Gruppen. Wenn eine genaue Segmentierung nicht möglich ist, sollte der Anbieter erklären, warum. Kunden sollten nicht aus Überschriften schließen müssen, ob eine Nachricht für sie gilt.

Die Kommunikationsqualität kann gemessen werden. Hat der Anbieter dauerhafte Vorfallsseiten veröffentlicht? Enthielten die Nachrichten Daten und Zeitstempel? Haben sie betroffene Dienste identifiziert? Haben sie konkrete Kundenaktionen bereitgestellt? Haben sie frühere Anleitungen aktualisiert, wenn sie sich änderten? Haben sie direkte Kunden- und öffentliche Datensätze konsistent gehalten? Haben sie eine Überprüfung nach dem Vorfall veröffentlicht, die Kontrollverbesserungen nannte, ohne ausbeutbare private Details preiszugeben? Dies sind ebenso Rechenschaftsfragen wie Kommunikationsfragen.

In der Ökonomie von Entwicklertools überträgt unklare Kommunikation die Kosten auf die Kunden. Jeder vage Satz wird im Nachgang zu einem Meeting, einem Ticket, einer Protokollsuche, einer Kunden-E-Mail oder einer Prüfungsausnahme. Eine Plattform mag rechtlich vorsichtig sein, aber eine Plattform, die Entwicklervertrauen verkauft, sollte die entscheidungsnützliche Mitteilung als Teil des Produkts behandeln. Der Heroku-Vorfall zeigt, warum die Kommunikation bei Vorfällen Produktentwicklungsdisziplin benötigt: versionierte Anweisungen, zielgruppenspezifische Zielgruppen, nachvollziehbare Korrekturen und Nachweise über die Erledigung.

Erzwungene Rotation ist nur dann eine Abhilfe, wenn Kunden wissen, was sich geändert hat

Erzwungene Rotation von Anmeldeinformationen kann notwendig und dennoch als Vertrauensreparatur unvollständig sein. Ein Kunde kann einen API-Schlüssel rotieren, ein Passwort zurücksetzen oder eine OAuth-App neu autorisieren, aber der Kunde muss auch verstehen, was sich im Verwahrungsmodell der Plattform geändert hat. Wenn derselbe Speicherpfad, dasselbe Bereichsdesign, dieselbe Überwachungslücke oder dieselbe Kundenbeweislicke bestehen bleibt, kann die Rotation das Vertrauen wiederherstellen, ohne das Vertrauen wiederherzustellen.

Der öffentliche Datensatz rund um Herokus Vorfall von 2022 stellte Rotation und Neuauthorisierung in den Mittelpunkt der Kundenaktion. Die Rechenschaftsfrage ist, ob diese Maßnahmen durch dauerhafte Kontrollnachweise untermauert wurden.

Herokus Dev-Center-Seiten wiehttps://devcenter.heroku.com/articles/oauth,https://devcenter.heroku.com/articles/platform-api-reference,https://devcenter.heroku.com/articles/heroku-cliundhttps://devcenter.heroku.com/articles/account-securityzeigen die breitere Zugriffsverwaltungsumgebung rund um die Nutzung der Heroku-Plattform. Die Heroku-Seite zur Zwei-Faktor-Authentifizierung unterhttps://devcenter.heroku.com/articles/heroku-2fabietet kundenseitigen Kontext zur Kontohärtung. Auch hier ist die aktuelle Dokumentation kein Beweis für den internen Zustand im Jahr 2022. Sie hilft den Lesern zu verstehen, welche Arten von Anmeldeinformationen und Benutzeraktionen ein Heroku-Konto umgeben können.

Rotation hat drei verschiedene Ebenen. Erstens gibt es den Widerruf kompromittierter OAuth-Token, sodass der Angreifer die delegierte Autorisierung nicht weiter nutzen kann. Zweitens gibt es den kundenseitigen Ersatz oder die Neuauthorisierung, damit legitime Arbeitsabläufe mit neuen Token fortgesetzt werden können. Drittens gibt es die Überprüfung angrenzender Anmeldeinformationen, einschließlich API-Schlüssel, Passwörter, Bereitstellungsschlüssel, CI-Variablen, Repository-Geheimnisse, persönliche Zugriffstoken und Cloud-Anmeldeinformationen. Eine Plattformmitteilung sollte klarstellen, welche Ebene erforderlich ist und warum.

Die schwierigste Ebene ist die Offenlegung von Geheimnissen im Quellcode. Wenn ein Angreifer Repositories lesen konnte, reicht die alleinige Rotation des OAuth-Tokens möglicherweise nicht aus. Kunden müssen möglicherweise Repositories auf festgeschriebene Geheimnisse durchsuchen und jeden offengelegten Wert rotieren. Githubls Dokumentation zur Geheimnisprüfung unterhttps://docs.github.com/en/code-security/secret-scanning/about-secret-scanningliefert das heutige Vokabular für diese kundenseitige Überprüfung. CISAs Leitfaden zur Lieferkettensicherheit unterhttps://www.cisa.gov/resources-tools/resources/software-supply-chain-risk-management-sscrmund Materialien zur sicheren Entwicklung helfen zu erklären, warum Geheimnisse im Code ein Repository-Ereignis in ein breiteres Betriebsrisiko verwandeln können.

Erzwungene Rotation benötigt auch ein Abschlusssignal. Kunden sollten wissen, ob alte Token ungültig sind, ob eine Neuauthorisierung erforderlich ist, ob deaktivierte Integrationen bis zur Aktion deaktiviert bleiben, ob der Abschluss der Passwortzurücksetzung verfolgt wird und ob veraltete Anmeldeinformationen noch irgendwo akzeptiert werden. Ohne ein Abschlusssignal muss jeder Kunde seinen eigenen Abgleich durchführen. Das ist teuer und fehleranfällig.

Die Plattform benötigt auch interne Abschlussnachweise. Welche Kundenkonten haben die erforderlichen Schritte abgeschlossen? Welche Konten befinden sich noch im Ausnahmezustand? Welche Kunden waren nicht erreichbar? Welche Integrationen wurden aufgegeben? Welche Token konnten keinem aktuellen Eigentümer zugeordnet werden? Welche Kontrollen wurden hinzugefügt, um die stille Aufbewahrung langlebiger Token zu verhindern? Ein öffentlicher Post-Mortem kann keine Kundennamen preisgeben, aber er kann die Form der Bereinigung preisgeben. Das ist der Unterschied zwischen „Wir haben rotiert“ und „Der riskante Zustand existiert nicht mehr.“

GitHub, Heroku, Travis CI, Salesforce und Kunden besaßen jeweils unterschiedliche Beweise

Die Rechenschaftskarte des Vorfalls ist mehrseitig. GitHub besaß Quellhost-Beweise, OAuth-Anwendungssichtbarkeit und die von ihm veröffentlichte Sicherheitswarnung. Heroku besaß seine Plattformintegration, Kundenkommunikation, Token-Verwahrung und das erzwungene Anmeldeinformationsprogramm. Travis CI besaß seinen betroffenen CI/CD-Integrationskanal und die Kundenberatung. Salesforce besaß die Heroku-Governance, Ressourcenzuweisung, Risikoeskalation und die Pflicht, die Reparatur der Plattform glaubwürdig zu machen.

Kunden besaßen die Repository-Hygiene, die Geheimnisrotation, die organisatorischen OAuth-Genehmigungen und die Bereitstellungsüberprüfung. Keine dieser Rollen hebt die anderen auf.

Dies ist wichtig, weil Kundenschäden aus Lücken zwischen den Rollen resultieren können. Wenn GitHub weiß, dass ein Token verwendet wurde, aber der Kunde nicht weiß, welche Heroku-Anwendung ihm zugeordnet war, ist die Reaktion des Kunden langsamer. Wenn Heroku weiß, welche Konten die GitHub-Integration genutzt haben, aber nicht sagen kann, ob auf Repository-Inhalte zugegriffen wurde, müssen Kunden breiter überprüfen. Wenn Travis CI und Heroku eine GitHub-Warnung teilen, aber unterschiedliche Kundenanweisungen haben, müssen Organisationen, die beide verwenden, widersprüchliche oder überlappende Aktionen in Einklang bringen.

Wenn Salesforce Heroku als Tochtermarke behandelt, während Kunden Heroku als Produktionsplattform behandeln, muss die Governance die Markengrenze überbrücken.

Dokumente zur gemeinsamen Verantwortung von Cloud und SaaS sagen oft, dass sich die Pflichten von Anbieter und Kunde unterscheiden. Der Heroku-Vorfall zeigt, dass gemeinsame Verantwortung auch gemeinsame Beweise erfordert. Ein Kunde kann die Zusicherung eines Anbieters nicht verantwortungsvoll akzeptieren, wenn der Anbieter nicht offenlegt, welchen Teil der Kette die Zusicherung abdeckt. Ein Anbieter kann nicht verantwortungsvoll alle Maßnahmen auf Kunden verlagern, wenn den Kunden die für das Handeln erforderlichen Protokolle oder Produktfunktionen fehlen.

Ein Quellhost kann nicht davon ausgehen, dass nachgelagerte Tools seine Warnung perfekt übersetzen. Jeder Akteur muss seine Beweise für den nächsten Akteur in der Kette nutzbar machen.

Die Quellen von IETF, NIST, MITRE, CISA, GitHub, Heroku und Travis CI bilden zusammen eine begrenzte öffentliche Akte. Sie offenbaren nicht jede private Tatsache, erlauben aber ein klares Rechenschaftsmodell. OAuth-Token sollten eng eingegrenzt, verteidigungsfähig gespeichert, schnell widerrufbar, kontinuierlich überwacht und dem aktuellen Geschäftszweck zugeordnet werden. Entwicklerplattformen sollten Vorfälle mit ausreichender Spezifität kommunizieren, damit Kunden handeln können. Kunden sollten Integrationen regelmäßig überprüfen, anstatt die Autorisierung als dauerhaft zu behandeln.

Quellhosts sollten Audits evidern, sodass Kunden mögliche Exposition von bestätigtem Zugriff unterscheiden können.

Die Rollenkarte warnt auch vor vereinfachender Schuldzuweisung. Wenn ein Angreifer ein Token stiehlt, ist der Angreifer für den Missbrauch verantwortlich. Aber die Rechenschaftspflicht fragt, wer die Gelegenheit, den Schadensradius und die Unsicherheit verringern könnte. Das Design der Token-Speicherung kann die Gelegenheit verringern. Die Minimierung des Umfangs kann den Schadensradius verringern. Schneller Widerruf kann die Dauer verkürzen. Gute Protokolle können Unsicherheit reduzieren. Klare Kundenanweisungen können vergeudete Arbeit reduzieren. Kontrollnachweise nach dem Vorfall können Wiederholungen reduzieren.

Dies sind Designentscheidungen, nicht nur nachträgliche Aussagen.

Vom Kunden überprüfbare Beweise sind die fehlende Hälfte der gemeinsamen Verantwortung

Der Heroku-Vorfall zeigt auch die Grenze der Sprache der gemeinsamen Verantwortung, wenn Beweise asymmetrisch sind. Eine Plattform kann Kunden sagen, dass sie für Repository-Hygiene, Geheimnisrotation und OAuth-App-Überprüfung verantwortlich sind, aber der Kunde ist dennoch auf Anbieternachweise angewiesen, um zu entscheiden, wo gesucht werden soll. Wenn der Anbieter nicht sagen kann, ob ein Token Repository-Leseumfang hatte, ob es nach einem bestimmten Datum verwendet wurde, ob es an eine bestimmte Anwendung gebunden war oder ob kundenspezifische Protokolle existieren, wird die Kundenverantwortung zu einem Ratespiel.

Ein faires Modell der gemeinsamen Verantwortung gibt Kunden sowohl Pflichten als auch nutzbare Beweise.

Vom Kunden überprüfbare Beweise beginnen mit einem Inventar. Jeder Kunde sollte sehen können, welche Heroku-Anwendungen mit welchen GitHub-Organisationen, Repositories, Benutzern und Bereitstellungsabläufen verbunden waren. Das Inventar sollte den aktuellen Status, die letzte Autorisierung, den Umfang, den Eigentümer, die Neuauthorisierungsanforderung und anzeigen, ob die Verbindung vom Anbieter deaktiviert wurde. Ohne diese Karte muss ein Sicherheitsteam die Integration aus alten Tickets, Repository-Webhooks, Bereitstellungsverlauf und persönlichen Entwicklerkonten rekonstruieren.

Das ist genau die Art von Notfallarbeit, die eine Plattform nach einem anbieterseitigen Token-Ereignis reduzieren sollte.

Die zweite Beweisschicht ist die Aktivität. Kunden müssen wissen, welche Protokolle Repository-Zugriff, OAuth-Autorisierungsnutzung, API-Schlüsselverwendung, Heroku-Kontoaktivität, Bereitstellungsereignisse, Build-Ereignisse und Konfigurationsänderungen zeigen können. Wenn die relevanten Beweise nur auf GitHub existieren, sollte der Anbieter Kunden an GitHub-Aufzeichnungen verweisen. Wenn relevante Beweise nur auf Heroku existieren, sollte der Anbieter eine kundenspezifische Ansicht oder einen Supportpfad bereitstellen.

Wenn einige Beweise nicht verfügbar sind, weil die Protokollierung nicht aufbewahrt oder nicht erfasst wurde, sollte der Anbieter dies klar sagen. „Keine Beweise für Missbrauch“ ist nur dann entscheidungsnützlich, wenn Kunden wissen, welche Beweise überprüft wurden.

Die dritte Schicht ist die Offenlegung von Geheimnissen. Das Risiko des Repository-Zugriffs beschränkt sich nicht auf Quellcode als geistiges Eigentum. Es umfasst auch festgeschriebene Geheimnisse, historische Konfiguration, Testanmeldeinformationen, Bereitstellungstoken, Cloud-Schlüssel, Datenbankverbindungszeichenfolgen und Kommentare, die die Architektur offenbaren. Kunden benötigen eine Anleitung, die das Token-Ereignis mit Geheimnisprüfung und -rotation verknüpft. Eine starke Plattformreaktion würde sagen, welche Kategorien wahrscheinlich, welche möglich und welche außerhalb des bekannten Pfades sind.

Sie würde auch vermeiden, zu implizieren, dass ein alleiniger Token-Widerruf das Repository-Inhaltsrisiko beseitigt.

Die vierte Schicht ist die Sicherstellung der Softwarefreigabe. Wenn ein Kunde Heroku für automatische Bereitstellungen von GitHub verwendet, muss der Kunde wissen, ob ein unbefugter Repository-Zugriff bereitgestellten Code, Build-Artefakte, Review-Apps, Pipelines oder den Release-Verlauf beeinflusst haben könnte. Das bedeutet nicht, dass ein solcher Einfluss stattgefunden hat. Es bedeutet, dass der Kunde genügend Informationen erhalten sollte, um dies zu beweisen oder zu widerlegen.

Release-Verlauf, Build-Herkunft, Bereitstellungszeitstempel, Repository-Commit-Signaturen, Branchenschutz und CI-Protokolle werden alle Teil der Rechenschaftsakte.

Die fünfte Schicht ist die dauerhafte Bereinigung. Ein Kunde sollte erkennen können, wann der verdächtige Zustand endete. Wurden alte OAuth-Token widerrufen? Wurden Integrationen mit neuen Token neu autorisiert? Wurden Passwort- oder API-Schlüsselrotationen abgeschlossen? Wurden aufgegebene Anwendungen deaktiviert? Wurden verwaiste persönliche Autorisierungen entfernt? Hat die Plattform verhindert, dass die alte Token-Klasse in einem Hintergrundjob oder Legacy-Pfad aktiv bleibt? Die Zusicherung des Anbieters ist am stärksten, wenn Kunden ihren eigenen Mandantenstatus mit den Abschlussnachweisen des Anbieters abgleichen können.

Dieses Kundenbeweismodell erfordert nicht, dass ein Anbieter sensible private Protokolle im offenen Web veröffentlicht. Es kann über Kontodashboards, direkte Mitteilungen, Support-Exporte, Unternehmensvorfall-Briefings oder vertragliche Beweispakete bereitgestellt werden. Die Form kann je nach Kundentier und Sensitivität variieren. Der Grundsatz sollte nicht variieren: Wenn ein Anbieter Kunden zum Handeln auffordert, sollte er auch die Beweise liefern, die Kunden für ein verhältnismäßiges Handeln benötigen.

Beschaffung und Governance sollten Integrationen als dauerhaften Zugang behandeln

Die Beschaffungslektion ist, dass OAuth-Integrationen dauerhafter Zugang sind, keine einmaligen Einrichtungsaufgaben. Ein Fragebogen zum Anbieterrisiko, der nur fragt, ob der Anbieter Verschlüsselung, Multi-Faktor-Authentifizierung oder Betriebszeitziele unterstützt, wird die Heroku-Lektion übersehen. Die schärferen Fragen betreffen das Integrationsinventar, die Token-Speicherung, die Umfangsminimierung, Kundenprotokolle, Notfallwiderruf, mandantenbezogene Benachrichtigungen, Build-Systemisolierung und Nachweise nach dem Vorfall.

Entwicklerplattformen sollten diese Fragen erwarten, da ihre Produkte absichtlich nahe an der Softwareauslieferung sind.

Die Vertragssprache sollte auch vage Verantwortungsübertragungen vermeiden. Ein Anbieter kann von Kunden verlangen, ihre Repositories und Anmeldeinformationen zu schützen, aber er sollte angeben, wie anbieterseitige Integrationsvorfälle behandelt werden. Wird der Anbieter jeden Kunden benachrichtigen, der die betroffene Integration nutzt? Wird er betroffene Zeitfenster angeben? Wird er feststellen, ob der Quellcode-Zugriff bestätigt, möglich oder nicht beobachtet wurde? Wird er eine Neuauthorisierung verlangen? Wird er Audit-Ereignisse offenlegen? Wird er eine Zusammenfassung nach dem Vorfall bereitstellen?

Wird er regulierte Kunden unterstützen, die ihre eigenen Benachrichtigungen benötigen? Dies sind keine Luxusbedingungen für große Unternehmen. Sie sind grundlegende betriebliche Fragen für jeden Kunden, dessen Softwarelieferkette von der Plattform abhängt.

Die Governance innerhalb von Salesforce und Heroku ist ebenfalls wichtig. Die Öffentlichkeit sollte nicht davon ausgehen, dass eine Tochtermarke weniger Rechenschaftspflicht trägt, weil sie entwicklerorientiert ist. Heroku-Anwendungen können Produktionsanwendungen, interne Tools, öffentliche APIs, Prototypen, die kritisch wurden, oder Back-Office-Systeme sein, die sensible Arbeitsabläufe verarbeiten. Die Eigentümerstruktur ist wichtig, weil die Governance die Investitionen in Protokollierung, Token-Verwahrung, Reaktion auf Vorfälle, Kundenunterstützung und Sicherheitstechnik bestimmt.

Eine Muttergesellschaft muss nicht jede Vorstandsdiskussion offenlegen, um zu zeigen, dass ein Vorfall auf einer Entwicklerplattform ernsthafte Kontrollaufmerksamkeit erhalten hat.

Dieselbe Governance-Frage gilt für das Produktmanagement. Ein Produktteam möchte möglicherweise eine nahtlose GitHub-Integration, da sie Reibung reduziert und Kunden hilft, schnell bereitzustellen. Ein Sicherheitsteam möchte möglicherweise kurzlebige Token, enge Bereiche, kundensichtbare Protokolle und regelmäßige Neuauthorisierung. Ein Support-Team möchte möglicherweise Nachrichten, die einfach genug für kleine Kunden sind. Ein Enterprise-Vertriebsteam möchte möglicherweise Vertragsnachweise. Rechenschaftspflicht zeigt sich dort, wo diese Anreize vor einem Vorfall abgestimmt werden, nicht erst danach.

Wenn die Plattform nicht erklären kann, wer das Token-Verwahrungsrisiko im Normalbetrieb trägt, wird sie Schwierigkeiten haben zu erklären, wer es in einer Krise trägt.

Für Kunden besteht die praktische Governance-Reaktion darin, Integrationen nach ihrer Konsequenz zu klassifizieren. Eine persönliche Produktivitätsintegration unterscheidet sich von einer Bereitstellungsintegration, die Produktionsquellcode lesen kann. Eine schreibgeschützte Repository-App unterscheidet sich von einer App, die Bereitstellungen erstellen oder Webhooks verwalten kann. Eine Test-Heroku-App unterscheidet sich von einer kundenorientierten Produktionsanwendung. Organisationen sollten Integrationen, die Produktionscode oder Geheimnisse beeinflussen können, stärker prüfen, protokollieren und rezertifizieren.

Der Heroku-Vorfall ist eine Erinnerung daran, dass „verbundene App“ ein Governance-Objekt ist, nicht nur eine Komfortfunktion.

Das Ergebnis ist ein ausgereifterer Rechenschaftsstandard. Entwicklerplattformen sollten genügend Vorfallbeweise veröffentlichen, damit Kunden ihre eigenen Risikoentscheidungen treffen können. Kunden sollten ein ausreichendes Integrationsinventar führen, damit Anbieternachweise schnell umgesetzt werden können. Quellcode-Hosts sollten OAuth- und Audit-Kontrollen nutzbar halten. CI/CD-Anbieter sollten Build-Geheimnisse von breitem Repository-Vertrauen trennen. Muttergesellschaften sollten Entwicklervertrauen als Produktionsvertrauen behandeln.

Der Heroku-Vorfall von 2022 wird mehr als eine historische Sicherheitswarnung, wenn er auf diese Weise gelesen wird. Er wird zu einem Test, ob die Softwareauslieferungskette dauerhaften Zugang identifizieren kann, bevor Angreifer alle zum Hinsehen zwingen.

Wie eine dauerhafte Reparatur nach einem OAuth-Verwahrungsvorfall aussehen sollte

Der dauerhafte Reparaturstandard für einen OAuth-Vorfall auf einer Entwicklerplattform hat mindestens acht Teile. Erstens sollte der Anbieter eine klare Zeitlinie veröffentlichen: Erkennung, GitHub-Benachrichtigung, Heroku-Untersuchung, Kundenbenachrichtigung, Token-Widerruf, Anmeldedatenrotation, Verfügbarkeit der Neuauthorisierung und Post-Mortem. Zweitens sollte er die betroffene Integrationsoberfläche identifizieren, ohne zu implizieren, dass jeder Kunde oder jedes Repository gleichermaßen betroffen war.

Drittens sollte er den Unterschied zwischen gestohlenen OAuth-Token, Kundenpasswörtern, API-Schlüsseln, Bereitstellungsschlüsseln, Repository-Geheimnissen und CI-Variablen erklären.

Viertens sollte der Anbieter Kundenaktionen in einer Checkliste veröffentlichen, die zwischen erforderlichen, empfohlenen und optionalen Schritten unterscheidet. Fünftens sollte er angeben, welche Beweise der Kunde sehen kann und welche nur der Anbieter oder Quellhost sehen kann. Sechstens sollte er identifizieren, welche Kontrollen geändert wurden: Token-Speicherung, Verschlüsselung, Geheimnisverwaltung, Bereichsüberprüfung, Überwachung, Anomalieerkennung, Kunden-Audit-Zugriff oder Integrationsstilllegung. Siebtens sollte er ein Abschlusssignal bereitstellen, z. B.

Abschluss der erzwungenen Zurücksetzung, Abschluss des Token-Widerrufs oder Durchsetzung der Neuauthorisierung. Achtens sollte er verbleibende Unbekannte klar benennen.

Die öffentliche Heroku-Akte enthält aussagekräftige Beweise, aber die Rechenschaftslektion ist größer als ein einzelner Vorfall. Entwicklerplattformen sollten für verdächtige Token-Tage ausgelegt sein, bevor sie eintreten. Das bedeutet OAuth-Anwendungsinventar, Eigentümerzuordnung, Umfangsminimierung, Token-Alterungsverfolgung, automatisierte Widerrufsabläufe, Kundenbenachrichtigungsvorlagen, kundenspezifische Aktionsseiten, Audit-Protokoll-Export und regelmäßige Integrationsrezertifizierung. Es bedeutet auch, die Kundenerfahrung einer erzwungenen Neuauthorisierung vor einer Krise zu testen.

Wenn Kunden den Reparaturpfad an einem ruhigen Tag nicht verstehen, werden sie ihn während eines Vorfalls nicht verstehen.

Kunden benötigen auch dauerhafte Gewohnheiten. Sie sollten OAuth-Apps inventarisieren, ungenutzte Integrationen entfernen, die organisationsweite Genehmigung einschränken, eine Überprüfung für Apps mit hohem Umfang verlangen, Geheimnisprüfung verwenden, das Festschreiben von Anmeldeinformationen vermeiden, langlebige Geheimnisse rotieren, Audit-Protokolle aufbewahren und Bereitstellungsabläufe abbilden. Die Dokumentation von GitHub und Heroku bietet viele Bausteine, aber die Governance-Arbeit gehört jeder Organisation.

Ein Anbietervorfall wird leichter handhabbar, wenn Kunden bereits wissen, welche Apps mit welchen Repositories und Produktionssystemen verbunden sind.

Der letzte Rechenschaftstest ist nicht, ob die Plattform sagen kann, dass der Vorfall abgeschlossen ist. Es ist, ob der Abschluss auf Beweise zurückgeführt werden kann. Wurden verdächtige Token ungültig gemacht? Wurden betroffene Kunden benachrichtigt? Wurden erforderliche Zurücksetzungen abgeschlossen? Wurden Fragen zum Quellcode-Zugriff auf dem Niveau beantwortet, das die Beweise zuließen? Wurden Geheimnisse und Bereitstellungsanmeldeinformationen überprüft? Wurden Produktkontrollen geändert? Wurden verbleibende Unbekannte bewahrt?

Ein „Ja“ auf diese Fragen ist stärker als eine allgemeine Vertrauensaussage, weil es den Kunden sagt, was sich geändert hat.

Herokus OAuth-Vorfall von 2022 gehört daher in Daniel Kades Risiko- und Rechenschaftsserie, weil er das Vertrauen von Entwicklern sichtbar macht. Der Vorfall verwandelt einen vertrauten Integrationsbutton in eine Verwahrungsfrage. Er zeigt, dass Quellcode-Plattformen, Bereitstellungsplattformen, CI/CD-Anbieter und Kunden durch delegierte Autorität verbunden sind, die über den Benutzerklick hinaus Bestand hat.

Wenn diese Autorität gestohlen wird, folgt die Rechenschaftspflicht dem Token: Wer hat es ausgestellt, wer hat es gespeichert, wer konnte es sehen, wer hat es widerrufen, wer hat Benutzer gewarnt, wer hat die Reparatur bewiesen und wer hat die Kosten getragen, während die Beweise noch unvollständig waren.