Zugriffskontrolle verstehen: Authentifizierung, Autorisierung und Ressourcenverwaltung

Zugriffskontrolle ist eines dieser Themen, die auf den ersten Blick selbstverständlich erscheinen, bis man genauer hinsieht. Sie ist Jahr für Jahr die häufigste Kategorie in den OWASP Top 10 (Fehlerhafte Zugriffskontrolle) und mit Abstand die häufigste Schwachstelle, die wir sowohl branchenweit als auch in unseren eigenen Analysen feststellen. Die gute Nachricht: Sobald man die richtigen Fragen formuliert hat, wird das Thema deutlich einfacher.

Was genau ist Zugriffskontrolle?

Die Zugriffskontrolle legt fest, wer welche Aktionen auf welchen Ressourcen ausführen darf. Wenn eine Anwendung eine Anfrage erhält, muss sie drei Fragen beantworten, und alle drei sind relevant.

1. Weiß ich, wer der Nutzer ist? (Authentifizierung)

Dies ist der Identitätsschritt: Ist der Nutzer wirklich der, für den er sich ausgibt? Passwörter, MFA, SSO – all dies beantwortet diese erste Frage.

2. Darf dieser Nutzer diese Aktion ausführen? (Autorisierung)

Die Kenntnis der Nutzeridentität sagt nichts darüber aus, welche Berechtigungen der Nutzer hat. Ein authentifizierter Nutzer ist nicht zwangsläufig berechtigt, Dateien zu löschen, zu bearbeiten oder zu verwalten.

3. Hat er die Berechtigung für diese spezielle Ressource? (objektbezogene Autorisierung)

Dies ist die am häufigsten vergessene Frage. Das Recht, einen „einzelnen“ Eintrag einzusehen, bedeutet nicht automatisch das Recht, „alle“ Einträge einzusehen. Fehlt diese Prüfung, spricht man von IDOR (Insecure Direct Object Reference): Es genügt, eine Kennung in der Anfrage zu ändern, um an die Daten einer anderen Person zu gelangen.

Man sollte sich merken: Schon das Vergessen einer einzigen dieser drei Fragen genügt, um eine Sicherheitslücke zu schaffen. Die drei bilden ein Ganzes.

Die oft vergessene Frage: Wo findet die Prüfung statt?

Es reicht nicht aus, diese drei Fragen richtig zu beantworten. Man muss auch fragen, wo diese Prüfungen durchgeführt werden. Und genau hier liegt der Unterschied zwischen einer echten Sicherheitsmaßnahme und einer bloßen Konvention in der Nutzeroberfläche.

Clientseitig

Clientseitige Kontrollmechanismen werden durch die Nutzeroberfläche umgesetzt: eine ausgeblendete „Löschen“-Schaltfläche, eine ausgegraute Option, ein nicht angezeigtes Menü. Das ist sinnvoll und völlig normal. Es trägt zur Nutzerfreundlichkeit bei und hält Nutzer von Optionen fern, die ohnehin abgelehnt würden. Es verhindert die Aktion jedoch nicht: Bei korrekter Zugriffskontrolle verweigert der Server die Operation unabhängig von den Darstellungen der Nutzeroberfläche.

Diese Kontrollmechanismen befinden sich auf der Seite des Nutzers und können von jedem, der die Anfrage direkt manipuliert, umgangen werden, da die Schnittstelle nur eine von mehreren Möglichkeiten ist, an die Daten zu gelangen.

Serverseitig

Serverseitige Kontrollen werden von der Anwendung selbst durchgesetzt, wo die Daten gespeichert sind. Sie sind nicht von der verwendeten Schnittstelle abhängig und können nicht durch manipulierte Anfragen umgangen werden.

Diese Ebene – und nur diese – schützt sensible Daten wie das Anzeigen, Bearbeiten, Löschen, die Offenlegung von Passwörtern, den Zugriff auf Anhänge usw.

Eine clientseitige Prüfung ist eine Konvention zur Verbesserung der Nutzerfreundlichkeit, keine Sicherheitsmaßnahme. Die Regel ist einfach: Jede Berechtigung, die sensible Daten oder einen kritischen Datenfluss schützt, muss serverseitig durchgesetzt werden. Eine clientseitige Prüfung kann dies ergänzen, aber niemals ersetzen.

Was das konkret für Ihre Daten bedeutet

Nehmen wir beispielsweise Remote Desktop Manager (RDM), unsere Desktop-Anwendung zur Verwaltung von Remote-Verbindungen und Anmeldedaten. RDM bietet vielfältige Funktionen: Berechtigungen, Rollen und Optionen werden je nach Nutzer ein- oder ausgeblendet. Doch wo werden diese Berechtigungen tatsächlich durchgesetzt? Die Antwort hängt vollständig von der Architektur des Arbeitsbereichs ab, mit dem die Anwendung verbunden ist.

• Ein SQL-Server-Arbeitsbereich (eine direkte Datenbankverbindung). In diesem Fall befindet sich kein Anwendungsserver zwischen RDM und der Datenbank. RDM kommuniziert direkt mit dem SQL-Server. Die Berechtigungen sind vorhanden, werden jedoch vom Client durchgesetzt. Anders ausgedrückt: Sie befinden sich alle auf Seite des Clients. Die serverseitige Ebene, die einer direkten Manipulation widersteht, ist schlichtweg nicht vorhanden.
• Ein empfohlener Arbeitsbereich, der von einem Anwendungsserver unterstützt wird. Es gibt ihn in zwei Varianten: Devolutions Server (DVLS), der selbst-gehostete Arbeitsbereich, den Sie auf Ihrer eigenen Infrastruktur bereitstellen, und Devolutions Cloud, der vollständig verwaltete, Cloud-gehostete Arbeitsbereich. In beiden Fällen ist RDM zwar weiterhin der Client, doch es ist der Server, der bei jedem Zugriff überprüft, wer Sie sind, was Sie tun und auf welche konkreten Ressourcen Sie zugreifen dürfen. Die Antworten auf diese drei Fragen werden dort gefunden, wo es wirklich darauf ankommt: serverseitig.

Dies ist keine Frage guter Absichten oder sorgfältiger Konfiguration. Es ist eine Frage der Architektur. Ohne Anwendungsserver gibt es keinen physischen Ort, um serverseitige Kontrollen durchzusetzen. Aus diesem Grund empfehlen wir die Kombination von RDM mit einem Devolutions-Arbeitsbereich – nicht aus Produktpräferenz, sondern weil die Architektur es erfordert.

Zusammenfassung

• Eine gute Zugriffskontrolle beantwortet drei Fragen: wer (Authentifizierung), was (Autorisierung) und auf welche Ressource (objektbezogene Autorisierung).
• Eine clientseitige Prüfung verbessert zwar die Nutzerfreundlichkeit, bietet aber allein keinen Schutz, da sie umgangen werden kann.
• Nur eine serverseitige Prüfung schützt sensible Daten wirklich.
• Damit diese serverseitige Ebene existieren kann, benötigen Sie einen Devolutions-Arbeitsbereich hinter RDM: Devolutions Server (DVLS), wenn Sie ihn selbst hosten möchten, oder Devolutions Cloud, wenn Sie einen vollständig verwalteten Dienst bevorzugen.

Wenn RDM derzeit direkt mit einer SQL-Server-Datenbank verbunden ist, sollte man sich fragen: Wo werden meine Zugangskontrollen tatsächlich durchgesetzt? Die Architektur, nicht die Konfiguration, liefert Ihnen die ehrliche Antwort. Sie können die verfügbaren Arbeitsbereiche erkunden, um herauszufinden, welcher am besten zu Ihrer Umgebung passt.

Und anders als viele vermuten würden, sind die Kosten kein Hindernis: Devolutions Server und Devolutions Cloud bieten zum Einstieg eine kostenlose Version an. Um Devolutions Server als Ihr Backend zu verwenden, benötigen Sie lediglich eine aktive Unternehmenslizenz von Remote Desktop Manager. Und da die Verbindung von RDM mit einer SQL-Server-Datenbank bereits die gleiche Unternehmenslizenz erfordert, verfügen Sie höchstwahrscheinlich bereits über alles, was Sie für den Wechsel brauchen. (Für den Zugriff auf den Arbeitsbereich über einen Webbrowser ohne RDM bedarf es einer separaten Clientzugriffslizenz.)