Identität ist der neue Perimeter

Die vorige Lektion zog eine Linie zwischen dem, was ein Cloud-Anbieter absichert, und dem, was der Kunde muss. Auf der Kundenseite leistet ein Punkt mehr als jeder andere: Identität — wer sich anmelden darf und was diese Person dann tun kann. Ein klassisches Büronetzwerk hatte eine Wand und eine verschlossene Tür; ein Cloud-Konto hat ein Anmeldeformular, erreichbar von überall auf der Welt, zu jeder Stunde. Dieses Anmeldeformular abzusichern ist in der Praxis das Meiste dessen, was „Sicherheit in der Cloud“ bedeutet.

Wie Konten tatsächlich übernommen werden

Eine Kontoübernahme erfordert selten, dass ein Angreifer die Systeme eines Cloud-Anbieters durchbricht. Meist folgt sie dem Muster des Zugangsdatendiebstahls aus dem Kurs zur Bedrohungsmodellierung dieser Universität: ein Passwort, das aus einem gehackten, unabhängigen Dienst wiederverwendet wurde, oder eine überzeugende Phishing-Seite, die einfach direkt nach dem Login fragt. Sobald ein Angreifer gültige Zugangsdaten besitzt, können die meisten Cloud-Dienste sie nicht vom echten Kontoinhaber unterscheiden — genau deshalb hebt CISA über alle anderen Maßnahmen hinweg die Mehr-Faktor-Authentifizierung (MFA) als die eine entscheidende Kontrolle hervor.

MFA, und warum nicht alle Formen gleichwertig sind

CISA erklärt unmissverständlich, dass „Nutzer, die MFA aktivieren, deutlich seltener gehackt werden“, weil ein gestohlenes Passwort allein nicht mehr ausreicht. CISA ordnet die verfügbaren MFA-Formen aber auch danach, wie gut sie Phishing widerstehen, und diese Reihenfolge ist wichtig: „die einzige weit verfügbare phishing-resistente Authentifizierung ist FIDO/WebAuthn-Authentifizierung“ — der Standard hinter Passkeys und Hardware-Sicherheitsschlüsseln, behandelt im Kryptografie-Kurs. Ein SMS-Code ist, in CISAs eigenen Worten, immer noch weit besser als gar kein zweiter Faktor, kann aber von einem hinreichend entschlossenen Angreifer abgefangen oder umgeleitet werden; app-basierte Push-Benachrichtigungen mit Zahlenabgleich liegen dazwischen. Für ein Cloud-Konto mit sensiblem Inhalt ist das Aktivieren der stärksten von diesem Konto angebotenen MFA-Option der wertvollste einzelne Schritt in dieser Lektion.

OAuth: die Rechte, die Sie anderen Apps gewähren

Jedes Mal, wenn Sie auf „Mit Google fortfahren“ klicken oder ein Terminplanungswerkzeug mit Ihrem Kalender verbinden, verwenden Sie OAuth, laut der eigenen Dokumentation des Standards „das branchenübliche Protokoll für Autorisierung“. Sein nützliches Merkmal: Die Drittanbieter-App sieht Ihr Passwort nie — Sie melden sich direkt bei Ihrem Anbieter an und genehmigen dann eine bestimmte, begrenzte Gruppe von Rechten, sogenannte Scopes, für diese App. Sein Risiko liegt genau in dieser Rechtevergabe: Eine Terminplanungs-App, die nur die Frei/Belegt-Zeiten Ihres Kalenders lesen müsste, kann um Erlaubnis bitten, E-Mails in Ihrem Namen zu lesen und zu senden — und diese routinemäßig erhalten. Jede verbundene App ist eine dauerhafte Zugriffsgewährung, die bestehen bleibt, bis jemand sie widerruft, weshalb die letzte Lektion dieses Kurses das Überprüfen dieser Liste behandelt, nicht nur ihre einmalige korrekte Einrichtung.

Geleakte Schlüssel: OAuths weniger sichtbarer Verwandter

Automatisierte Werkzeuge und Integrationen authentifizieren sich oft mit einem API-Schlüssel statt mit einer menschlichen Anmeldung — einer langen Zeichenkette, die wie ein Passwort funktioniert, aber nicht von einer Person eingegeben und oft überhaupt nicht durch MFA geschützt wird. Diese Schlüssel werden häufiger offengelegt, als die meisten erwarten: eingefügt in ein Support-Ticket, versehentlich in ein Code-Repository übernommen, in einer Konfigurationsdatei belassen, die weiter geteilt wurde als beabsichtigt. Einen API-Schlüssel mit derselben Vorsicht zu behandeln wie ein Passwort — ihn nie im Klartext zu teilen, ihn bei möglicher Offenlegung zu erneuern und einzuschränken, was er tun darf — schließt eine Lücke, die MFA, gebaut für menschliche Anmeldungen, nicht abdeckt.