Least Privilege in AWS: jedes Programm bekommt nur, was es braucht

Was bedeutet Least Privilege in der Praxis?

Es bedeutet, jedem Nutzer und jedem Programm einen Schlüssel zu geben, der nur die Türen öffnet, die er braucht. Die Buchhaltung sieht Rechnungen, kann aber keinen Server löschen. Das Programm, das E-Mails verschickt, liest die Empfängerliste, berührt aber nie die Zahlungen. Was die Aufgabe nicht braucht, ist schlicht nicht erlaubt.

Das NIST, die US-Behörde für Standards, beschreibt es genauso: Jede Einheit erhält die minimalen Ressourcen und Berechtigungen, die sie für ihre Funktion braucht. Die Idee ist weder neu noch auf die Cloud beschränkt. Es ist dieselbe Logik wie bei den Schlüsseln eines Büros, nur angewendet auf Software.

Neu in der Cloud ist, dass es viele und unsichtbare Schlüssel gibt. Jeder Server, jede Funktion und jeder Mitarbeiter hat Berechtigungen, die als Regeln hinterlegt sind. Schaut niemand hin, wachsen sie mit der Zeit, denn eine Berechtigung hinzuzufügen ist immer leichter, als genau zu klären, welche nötig ist.

Warum sind zu viele Rechte ein Risiko für ein Unternehmen?

Weil der Schaden eines Vorfalls so groß ist wie die Rechte des verlorenen Schlüssels. Stiehlt jemand die Zugangsdaten eines Programms, das alles darf, darf auch der Angreifer alles. Hätte das Programm nur einen Ordner lesen dürfen, wäre nur dieser Ordner betroffen.

Dasselbe gilt für ehrliche Fehler. Ein Dienstleister, der alte Dateien aufräumt, kann versehentlich die Produktionsdatenbank löschen, wenn seine Rechte das zulassen. Mit Least Privilege wird der Befehl einfach abgelehnt, und der Fehler bleibt folgenlos.

Für ein kleines Unternehmen zählt das mehr als für ein großes. Selten gibt es ein Sicherheitsteam, das das Konto rund um die Uhr beobachtet. Der günstigste Schutz ist also, großen Schaden von Anfang an unmöglich zu machen. Dort beginnt Cloud-Sicherheit, noch vor jedem Werkzeug, das Geld kostet.

Derselbe Gedanke steckt hinter meinem System, das Scanner am Verhalten erkennt und blockiert: weniger offene Türen, weniger Angriffsfläche.

Wie funktioniert Least Privilege in AWS?

In AWS stehen Berechtigungen in AWS IAM als Regeln, den sogenannten Policies. Jede Policy legt fest, welche Aktionen erlaubt sind, auf welchen Ressourcen und unter welchen Bedingungen. Programme bekommen keine dauerhaften Passwörter, sondern IAM-Rollen, die temporäre Zugangsdaten nur so lange ausgeben, wie sie gebraucht werden.

Ein einfaches Beispiel: Das Kontaktformular einer Website speichert Nachrichten in einer Tabelle. Die IAM-Rolle des Formulars erlaubt genau eines, nämlich eine Zeile in diese Tabelle zu schreiben. Sie kann weder frühere Nachrichten lesen noch die Tabelle löschen noch eine andere Ressource im Konto berühren.

AWS empfiehlt außerdem temporäre Zugangsdaten auch für Menschen, Multi-Faktor-Authentifizierung (MFA) und Bedingungen in den Policies, etwa dass eine Aktion nur über einen bestimmten Dienst erlaubt ist. All das steht in den Sicherheits-Best-Practices für AWS IAM.

Auf einer Plattform mit vielen Kunden geht derselbe Gedanke einen Schritt weiter: Die Daten jedes Kunden bleiben getrennt, damit ein Problem bei einem nie die anderen erreicht. Das erkläre ich im Artikel über die eigene Datenbank pro Kunde.

Wie setzen Sie Least Privilege Schritt für Schritt um?

Beginnen Sie bei der Arbeit, nicht bei den Rechten. Schreiben Sie auf, was jede Person und jedes Programm tun muss, vergeben Sie genau das, testen Sie es und entfernen Sie danach alles, was ungenutzt bleibt. Fertig ist der Prozess nie endgültig: Er wiederholt sich, sobald sich Anwendung oder Team ändern.

Die Schritte in ihrer Reihenfolge:

1. Root-Benutzer wegschließen. Der Root-Benutzer des Kontos wird nicht für die tägliche Arbeit verwendet; er ist mit MFA geschützt und bleibt außen vor.
2. Aufgaben auflisten. Schreiben Sie für jede Person und jedes Programm in einfachen Worten auf, was sie tun: „lädt Fotos hoch“, „verschickt Rechnungen“, „liest Bestellungen“.
3. Eine Rolle pro Aufgabe. Jedes Programm bekommt eine eigene IAM-Rolle. Zwei Programme teilen sich nie eine Rolle, damit ein Problem im einen nicht auf das andere übergreift.
4. Regeln für konkrete Ressourcen. Nicht „alle Buckets“, sondern „dieser Bucket“. Nicht „jede Aktion“, sondern „lesen“ oder „schreiben“.
5. Vor dem Livegang testen. Fehlt etwas, scheitert das Programm mit einer klaren Zugriffsverweigerung. Dann ergänzen Sie nur das, was fehlt.
6. Nutzung regelmäßig prüfen. Mit IAM Access Analyzer und den Angaben zum letzten Zugriff sehen Sie, welche Rechte nie genutzt wurden, und entfernen sie.

Entscheidend ist die Reihenfolge. Wer mit „erst einmal alles freigeben“ beginnt, kommt selten zurück, denn niemand weiß mehr, was wirklich gebraucht wird. Wer mit der Liste der Aufgaben beginnt, hat für jede Berechtigung einen Grund, den er erklären kann.

Wie finden Sie Rechte, die niemand nutzt?

AWS zeigt, wann ein Nutzer oder eine Rolle einen Dienst zuletzt verwendet hat. Zusätzlich findet IAM Access Analyzer Ressourcen, die außerhalb Ihres Kontos freigegeben sind, und kann aus der tatsächlich aufgezeichneten Aktivität eine Policy erzeugen. Was lange ungenutzt bleibt, ist ein Kandidat zum Entfernen.

Stellen Sie sich ein Programm vor, das in vielen Diensten lesen und schreiben darf, seit Monaten aber nur wenige davon nutzt. Die übrigen Rechte helfen niemandem; sie vergrößern nur den Schaden, wenn etwas schiefgeht. Sie entfernen sie, prüfen, dass alles weiter funktioniert, und das Konto ist sicherer, ohne eine einzige Codeänderung.

Dasselbe Werkzeug prüft auch die Policies, die Sie schreiben, bevor Sie sie anwenden, und warnt vor häufigen Fehlern. Und die Prüfung ist keine einmalige Sache: Die Best Practices für AWS IAM empfehlen, ungenutzte Nutzer, Rollen, Berechtigungen und Zugangsdaten regelmäßig zu prüfen und zu entfernen. Eine wiederkehrende Erinnerung im Kalender genügt, damit die Rechte nicht still wieder wachsen.

Welche Fehler bei Berechtigungen sollten Sie vermeiden?

Der erste Fehler ist Bequemlichkeit: eine Regel mit Platzhalter, die jede Aktion auf jeder Ressource erlaubt, weil etwas nicht lief und schnell live gehen musste. Danach kommen dauerhafte Schlüssel im Code und gemeinsame Konten, die mehrere Personen mit demselben Passwort nutzen.

Jeder davon löst heute ein Problem und schafft morgen ein größeres:

• Platzhalter überall. Eine Regel „alles auf allem“ macht aus minimalen Rechten maximale. Wenn Sie sie wirklich kurz brauchen, bekommt sie ein Ablaufdatum.
• Schlüssel im Code. Ein Zugriffsschlüssel im Code kann in einer Sicherung, einer E-Mail oder einem öffentlichen Repository landen. IAM-Rollen geben temporäre Zugangsdaten aus, damit entfällt das Problem.
• Ein Login für alle. Melden sich mehrere mit demselben Passwort an, wissen Sie nicht, wer was getan hat, und können nicht einer einzelnen Person den Zugang entziehen.
• Alte Nutzer, die bleiben. Ein Dienstleister, der längst gegangen ist, hat weiter Zugang, wenn ihn niemand entfernt.

Nichts davon braucht ein teures Werkzeug. Es braucht die Entscheidung, dass jede Berechtigung einen Grund hat, und jemanden, der das prüft. Wenn Sie eine Frage dazu haben, wie die Rechte in Ihrem eigenen AWS-Konto eingerichtet sind, schreiben Sie mir über das Kontaktformular.