Autorisierung und Berechtigungen: Best Practices, die unbefugten Zugriff verhindern

Die meisten Menschen verwechseln Authentifizierung mit Autorisierung, und diese Verwechslung ist kostspielig. Bei der Authentifizierung handelt es sich um den Nachweis, wer Sie sind: Login, Passwort, Token, Biometrie. Bei der Autorisierung handelt es sich um die Entscheidung, wozu Sie, bereits identifiziert, berechtigt sind. Dabei handelt es sich um verschiedene Probleme, und beim zweiten Problem kommt es zu den meisten internen Lecks und Betrügereien.

Es ist üblich, Systeme mit einwandfreier Anmeldung und laxer Autorisierung zu sehen. Die Vordertür verfügt über ein biometrisches Schloss, aber sobald man drinnen ist, kann jeder jede Schublade öffnen. Der Angreifer muss Ihre Authentifizierung nicht knacken, wenn er nach der Anmeldung mit einem regulären Konto auf Daten zugreifen kann, die er nicht haben sollte.

Dieser Text fasst die wesentlichen Schritte und besten Autorisierungspraktiken zusammen. Das Ziel ist praktisch: sicherzustellen, dass jeder Benutzer, jedes System oder jeder Dienst genau auf das zugreift, was er benötigt, nicht mehr und nicht weniger.

Das Prinzip, das allem zugrunde liegt: geringste Privilegien

Wenn Sie nur eine Idee aus diesem Text übernehmen, nehmen Sie diese: Gewähren Sie jedem Benutzer den minimalen Zugriff, der für die Erledigung seiner Arbeit erforderlich ist, und nicht mehr. Es handelt sich um das Prinzip der geringsten Rechte und löst in der Praxis die meisten Autorisierungsprobleme.

Die gegenteilige Versuchung ist groß. Es sei einfacher, einen breiten Zugang zu gewähren, „um niemanden aufzuhalten“ und sich später mit den Konsequenzen auseinanderzusetzen. Aber jede zusätzliche Erlaubnis ist eine weitere Tür. Wenn ein Konto kompromittiert wird, ist der Schaden proportional zu dem, was dieses Konto anrichten könnte. Konten mit zu viel Macht machen aus einem kleinen Vorfall eine Katastrophe.

Geringeres Privileg ist kein Misstrauen gegenüber Menschen. Es geht darum zu erkennen, dass Konten kompromittiert werden, Fehler passieren und der Schaden durch Design eingedämmt werden muss.

Schritt 1: Modellieren Sie Rollen, bevor Sie Berechtigungen verteilen

Die Verteilung der Berechtigungen von Benutzer zu Benutzer lässt sich nicht skalieren und wird in kurzer Zeit zu einem Chaos. Eine ausgereifte Praxis besteht darin, den Zugriff nach Rollen zu organisieren, das als RBAC (role-based access control) bekannte Modell.

Anstatt zu sagen „John kann Finanzberichte sehen“, definieren Sie die Rolle „Finanzanalyst“ mit einer Reihe von Berechtigungen und weisen John diese Rolle zu. Wenn John geht und Mary hinzukommt, tauschen Sie einfach die Rolle aus. Berechtigungen werden an einem Ort beschrieben, sind überprüfbar und konsistent.

Für komplexere Szenarien gibt es die attributbasierte Steuerung (ABAC), bei der die Entscheidung Kontext, Zeit, Ort und Datensensibilität berücksichtigt. Aber fangen Sie einfach an. Eine gut durchgeführte RBAC löst die überwiegende Mehrheit der Fälle, und vorzeitige Komplexität führt hier nur zu Fehlern.

Schritt 2: Zentralisieren Sie die Autorisierungsentscheidung

Ein häufiger Architekturfehler besteht darin, Berechtigungsregeln über den gesamten Code zu verteilen, hier ein „Wenn“, dort ein Häkchen. Im Laufe der Zeit weiß niemand mehr genau, wer was tun kann, und die Regeln unterscheiden sich zwischen den Teilen des Systems.

Eine bewährte Vorgehensweise besteht darin, die Autorisierung als zentrale Verantwortung zu behandeln und einen klaren Punkt festzulegen, an dem Entscheidungen getroffen werden. Egal ob es sich um eine Bibliothek, einen Dienst oder ein Modul handelt, wichtig ist die Frage „Kann dieser Benutzer das tun?“ konsistent und an einem Ort beantwortet werden, der überprüft und geändert werden kann.

Dies erleichtert auch den Nachweis der Compliance. Wenn ein Prüfer oder im Falle personenbezogener Daten das LGPD](/post/lgpd-startups-compliance-protecao-dados) selbst fragt, wer Zugriff auf was hat, können Sie antworten, indem Sie an einer Stelle nachsehen und nicht den gesamten Code durchsuchen.

Schritt 3: Vertrauen Sie niemals nur dem, was der Kunde sagt

Hier liegt einer der gefährlichsten und häufigsten Fehler. Das Frontend verbirgt eine Schaltfläche, die der Benutzer nicht sehen sollte, und das Team betrachtet das Problem als gelöst. Das ist es nicht. Das Verstecken der Schaltfläche ist Erfahrung, keine Sicherheit.

Die Autorisierung muss im Backend bei jeder Anfrage und zu jedem Zeitpunkt überprüft werden. Ein Angreifer nutzt nicht Ihre Schnittstelle, sondern ruft die API direkt auf. Wenn die einzige Barriere visuell ist, gibt es keine Barriere. Die Regel ist einfach und nicht verhandelbar: Der Client kann Vorschläge machen, der Server entscheidet.

Das Gleiche gilt für Identifikatoren. Wenn das System dem Benutzer Zugriff auf eine Ressource gewährt, indem es einfach die Nummer in der URL ändert, ohne zu prüfen, ob diese Ressource ihm gehört, liegt eine der am häufigsten ausgenutzten Schwachstellen überhaupt vor: der unzulässige Zugriff auf ein Objekt durch direkte Referenz, das seit Jahren von OWASP katalogisiert wird. Überprüfen Sie den Besitz, nicht nur die Existenz.

Schritt 4: Machen Sie den Zugriff widerrufbar und überprüfbar

Der gewährte Zugang muss schnell wieder entzogen werden können. Wenn jemand die Organisation verlässt, die Rolle wechselt oder sein Konto kompromittiert wird, müssen Sie den Zugriff sofort sperren, nicht erst im nächsten Sprint.

Dies setzt zwei Dinge voraus. Erstens: Wissen, wer Zugriff auf was hat, was bis hin zur Zentralisierung und Vorbildfunktion führt. Zweitens: Erfassen Sie, wer wann auf was zugegriffen hat. Die Zugriffsprotokollierung verhindert das Problem nicht, aber sie ermöglicht es Ihnen, nach einem Vorfall zu untersuchen, darauf zu reagieren und daraus zu lernen. Ein System ohne Prüfpfad ist ein System, das nicht weiß, was mit ihm passiert ist.

Kritische Reflexion: Die stille Anhäufung von Privilegien

Es gibt ein Problem, das wächst, ohne dass es jemand merkt: die Anhäufung von Berechtigungen im Laufe der Zeit. Die Person wechselt Bereiche, erhält neue Zugänge und behält die alten. Jahre später sammelt sie Berechtigungen aus drei Rollen, die sie einst innehatte. Niemand hat es rezensiert, denn Rezensieren ist Arbeit und bringt keine Trophäe ein.

Diese Anhäufung ist eine Zeitbombe. Wenn eines dieser Konten kompromittiert wird, ist der Zugriff unverhältnismäßig. Verteidigung ist unbequem, aber notwendig: regelmäßige Überprüfung des Zugangs. Schauen Sie von Zeit zu Zeit hin und fragen Sie: „Braucht diese Person das noch?“ Bei einigen Berechtigungen lautet die Antwort fast immer „Nein“.

Die andere Herausforderung ist kultureller Natur. Eine restriktive Autorisierung erzeugt Reibung, und Reibung erzeugt Beschwerden. Der Benutzer möchte umfassenden Zugriff, der Manager möchte Agilität und die Sicherheit wird zum Bösewicht, der alle aufhält. Um die geringsten Privilegien aufrechtzuerhalten, bedarf es der Überzeugung der Führung und der Klarheit, dass die Spannungen von heute billiger sind als die Lecks von morgen.

Was bleibt

Eine gut durchgeführte Autorisierung ist unsichtbar, wenn sie funktioniert, und verheerend, wenn sie fehlschlägt. Es taucht nicht in einer Produktdemonstration auf, es beeindruckt nicht in einer Besprechung und dennoch ist es eine der folgenreichsten Entscheidungen eines jeden Systems, das mit sensiblen Daten umgeht.

Die Schritte sind klar: Geringste Privilegien als Prinzip, Rollen statt lockerer Berechtigungen, zentralisierte Entscheidungsfindung, serverseitige Überprüfung sowie widerruflicher und überprüfbarer Zugriff. Keiner von ihnen ist anspruchsvoll. Alle werden oft ignoriert.

Wenn Ihre Organisation vertrauliche Daten verarbeitet und Sie nicht sicher sind, wer auf welche Daten zugreifen kann, ist jetzt ein guter Zeitpunkt für eine Überprüfung. Auf dem Blog gibt es weitere Texte zum Thema Sicherheit, Zugangskontrolle und Compliance, die tiefer in die Thematik eintauchen.