Gewährt diese selbstgehostete Anwendung Menschen nur den Zugriff, den sie benötigen? Eine Checkliste zur RBAC-Bewertung
Nutzen Sie diese praxisnahe Checkliste, um Rollen, Berechtigungen, Administratorgrenzen, API-Zugriff und Prozesse für den Benutzerlebenszyklus zu bewerten, bevor Sie Benutzer und Daten in eine selbstgehostete Anwendung überführen.
Warum das Zugriffskontrolldesign vor dem Deployment gehört
Eine Migration kann eine Anwendung technisch verfügbar machen, während sie für die tatsächliche Arbeitsteilung in der Organisation ungeeignet bleibt. Wenn Finanzwesen, Vertrieb, Betrieb, Kundenservice und Auftragnehmer unterschiedliche Aktionen an unterschiedlichen Datensätzen benötigen, sollten Sie dieses Modell validieren, bevor Sie Produktivdaten importieren oder Benutzer einladen.
Rollenbasierte Zugriffskontrolle (RBAC) beruht darauf, die für bestimmte Aufgaben erforderlichen Vorgänge zu identifizieren, Personen Rollen zuzuweisen und diesen Rollen Berechtigungen zuzuweisen. Die wichtige Frage für Käufer lautet daher nicht: „Steht dort RBAC?“, sondern: „Können wir unsere erforderlichen Zugriffsentscheidungen in dieser Anwendung abbilden und betreiben?“
Betrachten Sie das Prinzip der minimalen Rechtevergabe als Gestaltungskriterium: Jede Person sollte nur die für ihre Aufgabe notwendigen Mindestberechtigungen erhalten. Personen mit ähnlicher Hierarchiestufe können dennoch sehr unterschiedliche Zugriffe benötigen, weil ihre Aufgaben unterschiedlich sind. OWASP empfiehlt außerdem eine standardmäßige Verweigerung von Berechtigungen: Zugriff sollte ausdrücklich erlaubt werden, statt als gegeben angenommen zu werden.
- Bewerten Sie Berechtigungen während der Auswahl, nicht erst nachdem ein Produktiv-Rollout weitreichende Zugriffe schwer rückgängig gemacht hat.
- Setzen Sie die Verwendung des Begriffs „RBAC“ durch eine Anwendung nicht mit erweiterten Funktionen gleich. NIST unterscheidet die grundlegende Rollenzuweisung von optionalen Rollenhierarchien und Funktionen zur Funktionstrennung.
- Machen Sie die Eignung des Zugriffsmodells neben Datenimport, Integrationen, Authentifizierung und Backup-Anforderungen zu einem Migrationskriterium.
Beginnen Sie mit realen Benutzergruppen und den Aktionen, die jede Gruppe ausführen muss
Beginnen Sie mit der Arbeit, nicht mit den Standardrollennamen der Anwendung. Befragen Sie die für jeden Geschäftsprozess verantwortlichen Personen und erfassen Sie die kleinste praktikable Menge an Aktionen, die sie ausführen müssen. Beziehen Sie reguläre Arbeit, Ausnahmen, Genehmigungen, Exporte, Löschungen, Benutzerverwaltung und Konfigurationsänderungen ein.
Vermeiden Sie Rollenbezeichnungen, die weitreichende Berechtigungen verschleiern. „Manager“, „Redakteur“ oder „Mitglied“ ist keine Berechtigungsanforderung. Eine nützliche Anforderung nennt ein Verb, ein Objekt und einen Geltungsbereich, etwa: „Datensätze im zugewiesenen Arbeitsbereich erstellen“, „Projekte des eigenen Kunden einsehen“ oder „nur aggregierte Berichte exportieren“.
Beziehen Sie negative Anforderungen ein. Das sind Aktionen oder Daten, auf die eine Gruppe nicht zugreifen, die sie nicht verändern, offenlegen oder genehmigen darf. Sie decken häufig Lücken auf, die eine Liste erlaubter Aktionen übersieht.
- Listen Sie Benutzergruppen auf: Mitarbeitende, Teamleitungen, Führungskräfte, befristet Beschäftigte, Auftragnehmer, Kunden, Partner, Prüfer und technische Administratoren.
- Listen Sie für jede Gruppe Aktionen auf: ansehen, erstellen, bearbeiten, kommentieren, zuweisen, genehmigen, löschen, exportieren, teilen, konfigurieren und administrieren.
- Definieren Sie den Geltungsbereich für jede Aktion: eigene Datensätze, zugewiesene Datensätze, Teamdatensätze, ein Arbeitsbereich, ein Kundenkonto, alle Datensätze oder keine Datensätze.
- Identifizieren Sie sensible Felder und Aktionen mit hoher Auswirkung getrennt vom gewöhnlichen Zugriff auf Inhalte.
Identifizieren Sie das Zugriffsmodell der Anwendung: Rollen, Gruppen, Objekte und Grenzen
Bitten Sie den Anbieter oder die Projektdokumentation, das genaue Zugriffsmodell für die Version zu zeigen, die Sie bereitstellen möchten. Halten Sie fest, was dokumentiert ist, was in einer Testinstanz demonstriert werden kann und was unklar bleibt. Schließen Sie Lücken nicht mit Annahmen, die auf einer anderen Anwendung oder einer vertrauten Rollenbezeichnung beruhen.
Bestimmen Sie mindestens, ob Berechtigungen über feste Rollen, benutzerdefinierte Rollen, Gruppen, direkte Benutzerberechtigungen oder eine Mischung daraus vergeben werden. Bestimmen Sie dann, auf welcher Ebene diese Berechtigungen gelten: für die gesamte Instanz, eine Organisation, ein Team, einen Arbeitsbereich, ein Projekt, eine Sammlung, einen Datensatz oder ein Feld.
Eine Arbeitsbereichsgrenze kann nur dann nützlich sein, wenn sie den Zugriff tatsächlich auf die von Ihnen benötigte Weise beschränkt. Testen Sie, ob Personen bereichsübergreifend suchen, Links zu anderen Objekten folgen, Benachrichtigungen mit eingeschränkten Informationen erhalten, bereichsübergreifende Daten exportieren oder durch geerbte Mitgliedschaften Zugriff erhalten können.
- Können Sie eine Rolle erstellen, die jeder Anforderung entspricht, ohne nicht zusammenhängende Berechtigungen zu vergeben?
- Sind Rollen global, oder können sie je Arbeitsbereich, Projekt, Kunde oder anderer Geschäftsgrenze unterschiedlich sein?
- Können Berechtigungen auf Objekt- oder Feldebene festgelegt werden, wo Ihr Risiko dies erfordert?
- Werden Rollenhierarchien unterstützt, und bleiben geerbte Berechtigungen dabei verständlich und überprüfbar?
- Können direkte Berechtigungen das übliche Rollenmodell umgehen, und wie werden diese Ausnahmen bei einer Überprüfung gefunden?
- Was geschieht mit dem Zugriff, wenn ein Objekt, Arbeitsbereich oder Benutzer verschoben oder kopiert wird?
Testen Sie die Trennung von Administration und Zugriff auf sensible Geschäftsdaten
Operative Administration und Zugriff auf Geschäftsdaten sind unterschiedliche Verantwortlichkeiten. Ein Team benötigt möglicherweise jemanden, der Benutzer, Routing, Backups oder die Verfügbarkeit der Anwendung verwaltet, ohne routinemäßig vertrauliche Kunden-, Mitarbeiter- oder Finanzinformationen einzusehen. Stellen Sie fest, ob die Anwendung diese Unterscheidung unterstützt, statt anzunehmen, ein Administrator könne angemessen eingeschränkt werden.
Funktionstrennung befasst sich damit, ob eine Person allein über genügend Rechte verfügt, um ein System zu missbrauchen. Sie kann durch im Voraus zugewiesene, miteinander unvereinbare Rollen oder durch Kontrollen umgesetzt werden, die eine widersprüchliche Aktion zum Zeitpunkt des Zugriffs beschränken. Ob einer der beiden Ansätze erforderlich ist, hängt von Ihrem Prozess und Risiko ab, doch bei Aktionen mit hoher Auswirkung sollte die Frage ausdrücklich gestellt werden.
Ordnen Sie auch die Infrastrukturgrenze zu. Docker warnt, dass die Kontrolle über einen Docker-Daemon hochprivilegiert ist und Root-Zugriff auf den Host ermöglichen kann. Ebenso müssen unterstützende Administrationsoberflächen überprüft werden: Traefik weist darauf hin, dass eine API oder ein Dashboard in Produktion Konfigurationselemente, einschließlich sensibler Daten, offenlegen kann und mit Authentifizierung und Autorisierung geschützt werden sollte.
- Kann ein Benutzeradministrator Konten erstellen und Zugriffe zurücksetzen, ohne gewöhnliche Geschäftsdatensätze zu lesen?
- Kann ein Inhalts- oder Arbeitsbereichsadministrator Mitgliedschaften verwalten, ohne uneingeschränkte Export- oder Konfigurationsrechte zu erhalten?
- Wer kann Rollen ändern, privilegierte Konten erstellen, Authentifizierungseinstellungen ändern, auf Backups zugreifen oder das Deployment verwalten?
- Werden sensible Aktionen so protokolliert, dass die Organisation sie überprüfen kann?
- Sollten bei risikoreichen Vorgängen zwei verschiedene Personen für Antrag und Genehmigung erforderlich sein?
Prüfen Sie externe Mitarbeitende, Auftragnehmer und Kundenbenutzer
Externe Benutzer zeigen oft den Unterschied zwischen einer allgemeinen Kollaborationsrolle und einem sicheren Modell für Kundenzugriff. Ihr Zugriff benötigt möglicherweise ein kurzes Ablaufdatum, eine begrenzte Projektmenge, keine Sichtbarkeit von Verzeichnissen, keine Exportrechte und keine Möglichkeit, andere einzuladen. Testen Sie diese Anforderungen mit den tatsächlichen Freigabe- und Mitgliedschaftsfunktionen der Anwendung.
Gehen Sie nicht davon aus, dass eine eingeschränkte Oberfläche auch eingeschränkte Daten bedeutet. Prüfen Sie, worauf das externe Konto über Suche, direkte URLs, Benachrichtigungen, Dateianhänge, Kommentare, Exporte und APIs zugreifen kann. Testen Sie einen Kundenbenutzer anhand repräsentativer Datensätze eines anderen Kunden, nicht nur in einer leeren Umgebung.
Wenn die Anwendung die erforderliche Grenze nicht ausdrücken kann, sind eine separate Instanz, ein separater Arbeitsbereich mit sorgfältig validierten Kontrollen, ein anderer Freigabeprozess oder eine andere Anwendung möglicherweise sicherer. Die richtige Antwort hängt von der Sensibilität der Daten und den Folgen eines Fehlers ab.
- Kann externer Zugriff auf namentlich bekannte Benutzer und definierte Geschäftsbereiche beschränkt werden?
- Können Einladungen ablaufen, und kann Zugriff zeitnah entfernt werden?
- Können externe Benutzer andere Benutzer, Teams, Kunden oder Datensätze auffinden?
- Können sie Informationen herunterladen, exportieren, kopieren oder erneut teilen?
- Können sie Benutzer erstellen, Mitwirkende einladen oder Mitgliedschaften ändern?
- Kann die Organisation alle aktiven externen Konten und deren Zugriffe überprüfen?
Bewerten Sie API-Tokens, Servicekonten und Integrationen separat
Berechtigungen in der Benutzeroberfläche belegen nicht, dass Integrationen sicher sind. APIs können administrative oder sensible Funktionen offenlegen, wenn die Autorisierung auf Endpunktebene fehlt oder zu weit gefasst ist. OWASP benennt insbesondere fehlerhafte Autorisierung auf Funktionsebene als Risiko, wenn administrative Endpunkte ohne geeignete Prüfungen zugänglich sind.
Erfassen Sie jede nicht menschliche Identität: API-Tokens, Integrationszugangsdaten, Automatisierungsbenutzer, Servicekonten und gegebenenfalls Webhooks. Bestimmen Sie für jede Identität Eigentümer, Zweck, Berechtigungen, Geltungsbereich, Speicherort, Rotationsprozess und Widerrufsmethode. Ein Token sollte nicht die allmächtigen Zugriffe eines menschlichen Administrators erben, nur weil es bequem war, ihn so anzulegen.
Testen Sie Integrationen mit denselben repräsentativen Geltungsbereichen wie Personen. Eine Reporting-Integration, die aggregierte Daten benötigt, sollte nicht automatisch Datensätze ändern oder Benutzer administrieren dürfen. Halten Sie Zugangsdaten für Entwicklung, Test und Produktion getrennt, sofern Ihr Betriebsmodell diese Trennung unterstützt.
- Unterstützt die Anwendung bereichsbezogene Zugangsdaten, oder bedeutet jedes Token faktisch Vollzugriff auf das Konto?
- Können Tokens einem einzelnen Eigentümer oder einem benannten Servicezweck zugeordnet werden?
- Können Berechtigungen nach Aktion, Ressourcenumfang oder Ablaufzeit begrenzt werden?
- Kann ein Token widerrufen werden, ohne nicht zusammenhängende Integrationen zu deaktivieren?
- Beachten API-Antworten dieselben vorgesehenen Grenzen wie die Benutzeroberfläche?
- Werden administrative Endpunkte und Funktionen ausdrücklich getestet, statt sie aus Einschränkungen der Oberfläche abzuleiten?
Erstellen Sie eine Berechtigungstestmatrix mit repräsentativen Datensätzen und Nicht-Produktivkonten
Eine Berechtigungstestmatrix verwandelt Zugriffsanforderungen in Nachweise. Erstellen Sie repräsentative Testbenutzer für jede Rolle, einschließlich eines bewusst mit minimalen Rechten ausgestatteten Kontos und eines externen Kontos. Erstellen Sie repräsentative Datensätze für gewöhnliche, vertrauliche, teamübergreifende, kundenübergreifende, archivierte und für Ihre Organisation relevante Szenarien der Eigentumsübertragung.
Legen Sie für jede Rolle und Aktion das erwartete Ergebnis fest: erlaubt, verweigert oder nur innerhalb eines benannten Geltungsbereichs erlaubt. Testen Sie über alle verfügbaren Wege, einschließlich Benutzeroberfläche, direkter Links, Suche, Exporte, Massenaktionen, mobiler Clients, sofern genutzt, Benachrichtigungen und APIs. Autorisierungstests sollten neben erfolgreichen Benutzerabläufen auch verweigerte Wege abdecken.
Testen Sie erneut, wenn sich Rollen, Integrationen, wichtige Workflows oder Anwendungsfunktionen ändern. OWASP weist darauf hin, dass Autorisierungsprobleme häufig entstehen, wenn Funktionen hinzugefügt oder geändert werden, ohne das Autorisierungsverhalten erneut zu bewerten.
- Verwenden Sie Zeilen für repräsentative Rollen und Spalten für Aktionen und Datenbereiche.
- Dokumentieren Sie sowohl erwartete als auch beobachtete Ergebnisse sowie Nachweise wie Testdatum, Kontoname und Ergebnisreferenz.
- Testen Sie, soweit relevant, Aktionen zum Lesen, Erstellen, Bearbeiten, Löschen, Teilen, Exportieren, Einladen, Ändern von Rollen und Konfigurieren.
- Beziehen Sie Versuche ein, auf Daten eines anderen Teams, Kunden oder Arbeitsbereichs zuzugreifen.
- Fügen Sie Regressionstests für die Autorisierungsregeln mit dem höchsten Risiko hinzu, sofern Ihr Team dazu in der Lage ist.
Planen Sie Prozesse für Eintritt, Wechsel und Austritt
Selbst ein gut gestaltetes Rollenmodell scheitert, wenn Konten und Mitgliedschaften nicht aktuell gehalten werden. Definieren Sie, wie eine Person Zugriff erhält, wie sich ihr Zugriff bei einem Rollenwechsel oder einer geänderten Kundenzuordnung ändert und wie sie den Zugriff verliert, wenn ein Arbeitsverhältnis, Vertrag oder Projekt endet. Weisen Sie jedem Schritt einen namentlich benannten Verantwortlichen zu und legen Sie einen dem Risiko angemessenen operativen Überprüfungsrhythmus fest.
Wenn die Anwendung SCIM unterstützt, stellt das Protokoll Operationen für User- und Group-Ressourcen bereit, einschließlich deren Erstellung, Abruf, Änderung und Löschung. Das kann Provisionierungsworkflows unterstützen, entscheidet aber nicht über Ihre Auslöser im Benutzerlebenszyklus, Rollengestaltung, Regeln zur Eigentumsübertragung oder Ausnahmebehandlung. Diese bleiben organisatorische Verantwortlichkeiten.
Achten Sie besonders auf Eigentümerschaft. Bestimmen Sie vor der Deaktivierung eines Kontos, wer Eigentümer aktiver Datensätze, Projekte, Warteschlangen, Dateien, Automatisierungen, Berichte und Integrationszugangsdaten dieses Benutzers wird. Bestätigen Sie, dass die Übertragung die Zugriffe des Empfängers nicht unbeabsichtigt erweitert.
- Eintritt: Identität prüfen, die genehmigte Rolle auswählen, den richtigen Geltungsbereich festlegen und die genehmigende Führungskraft oder verantwortliche Person dokumentieren.
- Wechsel: Veraltete Zugriffe entfernen, bevor oder gleichzeitig mit neuen Zugriffen; direkte Berechtigungen und externe Mitgliedschaften überprüfen.
- Austritt: Zugriff deaktivieren oder entfernen, Tokens widerrufen, Eigentümerschaft übertragen und geteilte Ressourcen überprüfen.
- Enddatum für Auftragnehmer oder Kunden: eine geplante Überprüfung nutzen und die Entfernung bestätigen, statt sich auf eine erinnerte manuelle Aufgabe zu verlassen.
- Privilegierte, externe, inaktive und Ausnahme-Konten regelmäßig überprüfen.
Häufige Fragen
Was sollte eine RBAC-Checkliste für selbstgehostete Anwendungen enthalten?
Beziehen Sie reale Benutzergruppen, erforderliche und verbotene Aktionen, Datenumfang, Rollen und Gruppen, Grenzen für Arbeitsbereiche oder Objekte, die Trennung von Administratorrechten, Kontrollen für externe Benutzer, Berechtigungen für APIs und Servicekonten, eine Berechtigungstestmatrix sowie Prozesse für Eintritt, Wechsel und Austritt ein. Dokumentieren Sie, was nachgewiesen wurde und was nur angenommen wird.
Bietet Managed Hosting Anwendungs-RBAC?
Verwaltete Infrastruktur und Anwendungsautorisierung lösen unterschiedliche Probleme. Airbip verwaltet die Cloud-Infrastruktur rund um Docker-basierte Anwendungsdeployments, einschließlich Routing, TLS-Zertifikaten, Lifecycle-Management und konfigurierbaren Backups. Der Kunde muss dennoch eine Anwendung auswählen, deren Berechtigungsmodell zur Organisation passt, Rollen und Zugriffsbereiche definieren und die Zugriffsgovernance angemessen betreiben.
Ist eine Rolle namens Administrator immer zu mächtig?
Nicht unbedingt, aber sie muss getestet werden. Bestimmen Sie genau, was der Administrator ansehen, ändern, exportieren und delegieren kann und ob operative Administration vom Zugriff auf sensible Geschäftsdaten getrennt werden kann. Überprüfen Sie auch die unterstützende Infrastrukturadministration, da diese Berechtigungen hochsensibel sein können.
Warum API-Berechtigungen testen, wenn die Benutzeroberfläche eingeschränkt wirkt?
Einschränkungen der Benutzeroberfläche belegen nicht, dass API-Endpunkte dieselben Autorisierungsregeln durchsetzen. Testen Sie API-Funktionen separat, insbesondere administrative Funktionen, Exporte und bereichsübergreifende Zugriffe. Erfassen und beschränken Sie Tokens und Servicekonten entsprechend ihrem jeweiligen Zweck.
Wann ist eine selbstgehostete Anwendung für das erforderliche Zugriffsmodell nicht geeignet?
Wählen Sie eine andere Anwendung oder einen anderen Bereitstellungsansatz, wenn die erforderlichen Grenzen nicht ohne weitreichende Ausnahmen abgebildet und überprüft werden können; wenn externe Benutzer nicht ausreichend sicher isoliert werden können; wenn sensible Aktionen eine Trennung erfordern, die das System nicht unterstützen kann; oder wenn das Team die notwendigen Zugriffsüberprüfungen, Tests und Lifecycle-Prozesse nicht betreiben kann. Verwaltete Infrastruktur gleicht ein ungeeignetes Autorisierungsmodell auf Anwendungsebene nicht aus.
Quellen und weiterführende Literatur
- Role Based Access Control FAQs — National Institute of Standards and Technology
- Authorization Cheat Sheet — OWASP Foundation
- Authorization Testing Automation Cheat Sheet — OWASP Foundation
- API5:2023 Broken Function Level Authorization — OWASP Foundation
- Separation of Duty glossary entry — National Institute of Standards and Technology
- SP 800-53 Rev. 5 controls download page — National Institute of Standards and Technology
- RFC 7644: System for Cross-domain Identity Management Protocol — IETF
- Docker Engine security — Docker
- Protect the Docker daemon socket — Docker
- API & Dashboard — Traefik Labs