Zugriffsverwaltung

01

Wer bist du, und was darfst du? Authentifizierung und Autorisierung

Denk an ein Bürogebäude. Am Eingang beweist dein Firmenausweis, dass du wirklich du bist. Auf jeder Etage wird derselbe Ausweis dann noch einmal geprüft: Darfst du hier überhaupt rein? Die erste Prüfung ist die Authentifizierung (festzustellen, wer du bist), die zweite die Autorisierung (zu entscheiden, ob du das tun darfst). In der Cloud läuft es genauso, in denselben zwei Schritten.

Wer eine Anfrage schickt, heißt Sicherheitsprinzipal oder kurz Prinzipal. Prinzipale sind nicht nur Menschen. Ein Programm, das jede Nacht Backups macht, oder ein Server, der Bestellungen verarbeitet, ruft ebenfalls Speicher und Datenbanken der Cloud auf – also sind auch das Prinzipale. Menschen weisen sich mit Passwort und zweitem Faktor aus, Programme mit Schlüsseln oder temporären Anmeldeinformationen (Kapitel 4). Probier in der Szene unten die verschiedenen Situationen aus.

Im HTTP-Standard steht 401 für einen Authentifizierungsfehler (sag mir noch einmal, wer du bist) und 403 für einen Autorisierungsfehler (ich weiß, wer du bist, aber du darfst das nicht). Cloud-APIs halten sich aber nicht immer an diese Trennung. Manche liefern für beides 403, andere für beides 401. Schau deshalb nicht auf die Statusnummer, sondern auf Fehlercode und Meldung, um zu erkennen, an welcher Tür du hängen geblieben bist.

Das mächtigste Konto ist das, das du nicht benutzt

Das oberste Konto, das beim ersten Anlegen eines Cloud-Kontos entsteht (Root- oder Hauptkonto, oberster Admin), darf alles – bis hin zum Ändern der Zahlungsdaten oder zum Kündigen des Kontos. Deshalb sicherst du es mit MFA, schließt es weg und erledigst die tägliche Arbeit mit eigenen Konten, die nur die Berechtigungen haben, die sie brauchen. Wird dieses Konto gekapert, hilft dir keine Berechtigungseinstellung der Welt mehr.

Die Tür, die prüft, wer du bist, kennst du jetzt. Aber wenn deine Leute Dutzende Apps nutzen – musst du diese Tür dann für jede App einzeln bauen?

02

Eine Identität für alles: SSO, Verbund, MFA und bedingter Zugriff

Hat jede App ihre eigenen Konten und Passwörter, haben die Leute irgendwann mehr Passwörter, als sie sich merken können – und nehmen überall dasselbe. Verlässt jemand das Unternehmen, musst du in jeder App sein Konto löschen, und vergisst du auch nur eins, bleibt diese Tür offen. Deshalb hält man Identitäten an einer Stelle: bei einem Identitätsanbieter (IdP). Du meldest dich einmal beim IdP an, und die Apps lassen dich rein, weil sie dem Nachweis (einem Token) vertrauen, den der IdP ausstellt. Das ist SSO (Single Sign-On, einmaliges Anmelden).

Hat dein Unternehmen schon ein Unternehmensverzeichnis, musst du die Leute in der Cloud nicht noch einmal anlegen. Du kannst die Cloud stattdessen diesem Verzeichnis vertrauen lassen. Wenn man so der Identitätsprüfung einer anderen Organisation vertraut, heißt das Verbund (Föderation), und die Standards, mit denen dieser Nachweis hin- und hergeschickt wird, sind SAML 2.0 und OIDC (OpenID Connect).

Ein Passwort reicht nicht: MFA

Passwörter gehen leicht verloren – durch Phishing oder weil dasselbe Passwort auf einer anderen Website geleakt wurde. MFA (Multi-Faktor-Authentifizierung) legt zum Passwort eine zweite Prüfung obendrauf: etwas, das du besitzt (eine App auf dem Handy, einen Sicherheitsschlüssel), oder etwas, das du bist (dein Fingerabdruck). Und hier stolpern viele: MFA ist nicht gleich MFA. Einen Code per SMS oder die sechsstellige Zahl aus einer Authenticator-App kann man auf einer gefälschten Website eintippen, und sie wird einfach weitergereicht. Sicherheitsschlüssel und Passkeys (FIDO2) funktionieren dagegen nur auf der echten Website und sind deshalb phishingresistent.

Nach der Situation entscheiden: bedingter Zugriff

Nicht jede Anmeldung muss gleich streng geprüft werden. Wer mit dem Firmenlaptop im Büro sitzt, kommt einfach durch; bei einer Anmeldung aus einem Land und von einem Gerät, die du noch nie gesehen hast, kannst du MFA verlangen oder sie blockieren. Anhand von Signalen wie Benutzer, Ort, Gerät und Risiko zwischen „zulassen / nach zusätzlicher Prüfung zulassen / blockieren“ zu entscheiden, heißt bedingter Zugriff. Solche Bedingungen kannst du nur an einer Stelle festlegen, wenn die Identitäten auch an einer Stelle liegen (beim IdP).

Jetzt wissen wir sicher, wer du bist. Als Nächstes kommt die zweite Tür – „Darfst du das?“ Lesen wir die Richtlinien, die darüber entscheiden.

03

Richtlinien lesen: wer, was, wo und unter welchen Bedingungen

Berechtigungen vergibst du mit Richtlinien. Bei jedem Anbieter sehen sie anders aus, aber sie haben fast dieselben Felder: wer (der Prinzipal), was (die Aktion), wo (die Ressource), unter welchen Bedingungen (die Bedingung) und ob erlaubt oder verweigert wird.

Erlauben | Wer: Entwicklergruppe
         | Was: Objekte lesen, Objekte schreiben
         | Wo: alle Objekte im Dev-Bucket
         | Bedingung: nur bei Anmeldung mit MFA

Kommt eine Anfrage herein, sammelt das System alle Richtlinien, die auf sie zutreffen, und gleicht sie ab. Die Regeln für das Urteil passen in drei Zeilen.

Häng in der Szene unten die Allow-Richtlinie und die Deny-Richtlinie an und wieder ab.

Zwei Stellen für Richtlinien: Identitätsseite und Ressourcenseite

Eine Richtlinie kannst du an eine Identität wie eine Person, Gruppe oder Rolle hängen („diese Person darf Folgendes“) oder an eine Ressource wie einen Bucket („diese Prinzipale dürfen in diesen Bucket“). Eine Richtlinie auf Ressourcenseite hat immer ein „Wer“-Feld. Besonders wichtig werden Richtlinien auf Ressourcenseite, wenn du Prinzipale aus anderen Konten oder Organisationen hereinlässt – deshalb bekommen sie in Kapitel 5 einen eigenen Abschnitt.

Nicht pro Person vergeben, sondern bündeln: Gruppen und Rollen

Hängst du Richtlinien an jede Person einzeln, wird das mit jedem neuen Teammitglied unübersichtlicher. Stattdessen steckst du Leute mit derselben Aufgabe in eine Gruppe und hängst die Richtlinie an die Gruppe, und Berechtigungsbündel wie „Nur lesen“ oder „Datenbankbetrieb“ baust du als Rollen. Das heißt rollenbasierte Zugriffssteuerung (RBAC). Nutzt du zusätzlich Attribute wie Tags als Bedingung – „nur Ressourcen mit demselben Projekt-Tag“ –, heißt das attributbasierte Zugriffssteuerung (ABAC).

Richtlinien gibt es nicht nur für Menschen. Wie gibst du also einem Programm Berechtigungen, das die ganze Nacht läuft, ohne dass jemand dabei ist?