Autorisierung und Berechtigungen – Best Practices-Grundlagen

Authentifizierung bedeutet zu wissen, „wer Sie sind“. Autorisierung bedeutet zu wissen, „was Sie tun können“.

Viele Entwickler verwechseln die beiden. Sie haben sich am System angemeldet (Authentifizierung ok), aber können Sie die Datenbank löschen? Oder das Gehalt des CEO sehen? Das ist Autorisierung.

Die Verwaltung von Berechtigungen ist der kritischste Teil der Sicherheit einer Anwendung. Ein Schwachpunkt hier (Broken Access Control) ist die Schwachstelle Nummer 1 im OWASP-Ranking.

In diesem Artikel behandeln wir die Grundlagen und Best Practices für die Implementierung eines robusten Berechtigungssystems.

Zugangskontrollmodelle

Es gibt mehrere Möglichkeiten, einem Benutzer „Ja“ oder „Nein“ zu sagen.

1. RBAC (Rollenbasierte Zugriffskontrolle)

Am häufigsten. Sie erstellen „Rollen“.

Admin: Sie können alles tun.
Editor: Kann Beiträge erstellen und bearbeiten.
Leser: Sie können einfach lesen. Sie weisen dem Benutzer die Rolle zu (user.role = 'editor'). Der Code prüft: if (user.role == 'admin').
Vorteile: Einfach zu verstehen und umzusetzen.
Nachteile: Es ist starr. Was ist, wenn ich möchte, dass ein bestimmter Redakteur Beiträge löschen kann, aber nur seine eigenen?

2. ABAC (Attributbasierte Zugriffskontrolle)

Detaillierter und kraftvoller. Es basiert auf Attributen.

„Bearbeiten zulassen, WENN (user.id == post.author_id) UND (Zeit < 18:00)“.
Vorteile: Unendliche Flexibilität.
Nachteile: Komplexität der Implementierung.

3. PBAC (Policy-Based Access Control)

Definiert Richtlinien in natürlicher Sprache oder separatem Code.

Beispiel: AWS IAM-Richtlinien.

Prinzip der geringsten Privilegien

Dies ist die goldene Regel: Erteilen Sie dem Benutzer nur die Mindestberechtigung, die er für die Ausführung seiner Arbeit benötigt. Nicht mehr und nicht weniger.

Wenn ein Dienst nur Daten lesen muss, erteilen Sie ihm keine Schreibberechtigung.
Wenn ein Entwickler nur die Protokolle sehen muss, gewähren Sie keinen Zugriff auf die Produktionsdatenbank.

Dadurch verringert sich die „Angriffsfläche“. Wenn das Konto dieses Benutzers gehackt wird, ist der Schaden begrenzt.

Wo kann die Autorisierung überprüft werden?

IMMER IM BACKEND. Viele moderne Apps verbergen die Schaltfläche „Löschen“ im Frontend, wenn der Benutzer kein Administrator ist. Dies ist nur UX, keine Sicherheit. Ein Angreifer kann API DELETE /users/1 direkt aufrufen. Das Backend muss die Berechtigung bei jeder Anfrage überprüfen.

IDOR (Unsichere direkte Objektreferenzen)

Ein klassischer Fehlschlag. Die URL ist site.com/fatura/100. Ich sehe meine Rechnung. Ich ändere die URL auf site.com/fatura/101. Ich sehe die Rechnung des Nachbarn. Das ist IDOR. Korrektur: Das Backend sollte prüfen: „Ist der angemeldete Benutzer der EIGENTÜMER der Rechnung 101?“. Wenn nicht, geben Sie 403 Forbidden zurück.

Fazit

Die Autorisierung wird nicht am Ende hinzugefügt. Es muss in der Architektur der Datenbank und der API gestaltet sein. Verwenden Sie ausgereifte Bibliotheken (wie CASL in JS oder Pundit), anstatt Ihren Code mit verstreuten if/else zu überladen. Sicherheit ist Kontrolle.