Rechte über Rollen, Konten getrennt, Stand geprüft
Jedes System hat ein anderes Rollenmodell und andere Voreinstellungen, die stillschweigend Rechte vergeben. Beides entscheidet darüber, ob das Konzept nach zwei Jahren noch stimmt.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Gewachsene Rechte kennt nach zwei Jahren niemand mehr
Der Anfang ist meist ordentlich. Es gibt eine Liste, ein paar Rollen und eine Vorstellung davon, wer was darf. Dann kommt der Betrieb: Ein Auswertungsprojekt braucht kurzfristig Lesezugriff, ein Dienstleister bekommt für die Migration mehr Rechte, ein Entwickler analysiert einen Fehler direkt auf dem Produktivsystem. Jede dieser Vergaben ist einzeln begründet, keine wird zurückgenommen, und keine steht in der Liste.
Sichtbar wird das erst bei einer Prüfung oder einem Vorfall, und dann fällt die Antwort schwer. Wer darf die Gehaltstabelle lesen? Die ehrliche Auskunft lautet oft: Das müssen wir erst zusammensuchen, denn ein Teil der Rechte hängt an Rollen, ein Teil direkt am Konto, ein Teil an einer Voreinstellung, die niemand angefasst hat, und ein Teil an einem Dienstkonto, dessen Kennwort in drei Verbindungszeichenfolgen steht.
Teuer ist daran weniger die Prüfung als das, was die fehlende Übersicht im Alltag verhindert. Ohne belastbaren Stand traut sich niemand, Rechte zurückzunehmen, weil unklar ist, was dann stehen bleibt. Also wächst der Bestand weiter, und der Abgleich beim Ausscheiden von Personen findet nicht statt, weil er nicht durchführbar ist.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Wer entscheidet, wer setzt um
Die meisten Berechtigungskonzepte scheitern nicht an der Technik, sondern daran, dass Entscheidung und Umsetzung in derselben Hand liegen. Die Tabelle trennt beides für die fünf Themen, an denen es im Alltag hakt.
| Thema | Wer entscheidet | Wer setzt um | Stolperfalle |
|---|---|---|---|
| Welche Daten überhaupt schützenswert sind | Der Fachbereich als Eigentümer der Daten, bei personenbezogenen Beständen gemeinsam mit dem Datenschutz | Das Datenbankteam übersetzt die Einstufung in Rollen und Rechte auf Schema-, Tabellen- und wo nötig Spaltenebene | Ohne benannten Eigentümer entscheidet am Ende die Administration nach Gefühl, und dieser Entscheidung widerspricht später niemand, weil niemand sie kennt. |
| Wer produktive Daten lesen darf | Die Führungskraft des Fachbereichs, für übergreifende Auswertungen die Stelle, der die Kennzahl gehört | Das Datenbankteam über eine Leserolle je Datenbereich, nicht über Einzelrechte am Konto | Auswertungswerkzeuge melden sich oft mit einem gemeinsamen technischen Konto an. Damit sieht die Datenbank nur dieses Konto, und wer welche Zeile gelesen hat, muss das Werkzeug protokollieren. |
| Rechte für Anwendungen und Dienstkonten | Die für die Anwendung verantwortliche Stelle, gemeinsam mit dem Betrieb | Die Entwicklung liefert die benötigten Rechte je Umgebung, der Betrieb legt Konto und Rolle an und hinterlegt das Geheimnis in der Kennwortverwaltung | Das Anwendungskonto bekommt Rechte zum Ändern des Schemas, weil die Migration beim Start läuft. Danach kann die Anwendung im laufenden Betrieb Tabellen löschen, und niemand nimmt das Recht wieder weg. |
| Notfallzugriff mit erhöhten Rechten | Die Betriebsleitung nach festgelegtem Verfahren, im Störungsfall mit Freigabe im Nachgang | Der Betrieb über ein benanntes persönliches Konto, das die erhöhte Rolle zeitlich befristet erhält, mit eingeschalteter Protokollierung | Ein gemeinsames Administratorkonto, dessen Kennwort mehrere kennen, macht jede Protokollierung wertlos, weil sich Handlungen niemandem mehr zuordnen lassen. |
| Die wiederkehrende Rechteprüfung | Die Fachbereiche bestätigen die Liste für ihre Leute, die Revision oder der Datenschutz setzt den Abstand | Das Datenbankteam erzeugt den aktuellen Stand aus dem Katalog und stellt ihn dem Sollstand aus der Versionsverwaltung gegenüber | Die Prüfung sieht nur Rollen an und übersieht direkt vergebene Rechte. Genau dort sitzen die Ausnahmen aus Projekten, die niemand zurückgenommen hat. |
Welche Daten überhaupt schützenswert sind
- Wer entscheidet
- Der Fachbereich als Eigentümer der Daten, bei personenbezogenen Beständen gemeinsam mit dem Datenschutz
- Wer setzt um
- Das Datenbankteam übersetzt die Einstufung in Rollen und Rechte auf Schema-, Tabellen- und wo nötig Spaltenebene
- Stolperfalle
- Ohne benannten Eigentümer entscheidet am Ende die Administration nach Gefühl, und dieser Entscheidung widerspricht später niemand, weil niemand sie kennt.
Wer produktive Daten lesen darf
- Wer entscheidet
- Die Führungskraft des Fachbereichs, für übergreifende Auswertungen die Stelle, der die Kennzahl gehört
- Wer setzt um
- Das Datenbankteam über eine Leserolle je Datenbereich, nicht über Einzelrechte am Konto
- Stolperfalle
- Auswertungswerkzeuge melden sich oft mit einem gemeinsamen technischen Konto an. Damit sieht die Datenbank nur dieses Konto, und wer welche Zeile gelesen hat, muss das Werkzeug protokollieren.
Rechte für Anwendungen und Dienstkonten
- Wer entscheidet
- Die für die Anwendung verantwortliche Stelle, gemeinsam mit dem Betrieb
- Wer setzt um
- Die Entwicklung liefert die benötigten Rechte je Umgebung, der Betrieb legt Konto und Rolle an und hinterlegt das Geheimnis in der Kennwortverwaltung
- Stolperfalle
- Das Anwendungskonto bekommt Rechte zum Ändern des Schemas, weil die Migration beim Start läuft. Danach kann die Anwendung im laufenden Betrieb Tabellen löschen, und niemand nimmt das Recht wieder weg.
Notfallzugriff mit erhöhten Rechten
- Wer entscheidet
- Die Betriebsleitung nach festgelegtem Verfahren, im Störungsfall mit Freigabe im Nachgang
- Wer setzt um
- Der Betrieb über ein benanntes persönliches Konto, das die erhöhte Rolle zeitlich befristet erhält, mit eingeschalteter Protokollierung
- Stolperfalle
- Ein gemeinsames Administratorkonto, dessen Kennwort mehrere kennen, macht jede Protokollierung wertlos, weil sich Handlungen niemandem mehr zuordnen lassen.
Die wiederkehrende Rechteprüfung
- Wer entscheidet
- Die Fachbereiche bestätigen die Liste für ihre Leute, die Revision oder der Datenschutz setzt den Abstand
- Wer setzt um
- Das Datenbankteam erzeugt den aktuellen Stand aus dem Katalog und stellt ihn dem Sollstand aus der Versionsverwaltung gegenüber
- Stolperfalle
- Die Prüfung sieht nur Rollen an und übersieht direkt vergebene Rechte. Genau dort sitzen die Ausnahmen aus Projekten, die niemand zurückgenommen hat.
Fünf Fragen, die ein Berechtigungskonzept beantworten muss
- 01 Welche Daten sind schützenswert, und wer im Fachbereich entscheidet das?
- 02 Über welche Rollen läuft die Vergabe, und welche Ausnahmen sind erlaubt?
- 03 Welches Konto gehört zu welcher Anwendung, und wer verwahrt das Geheimnis?
- 04 Wie kommt jemand im Notfall an erhöhte Rechte, und wie wird das sichtbar?
- 05 Wer prüft in welchem Abstand, und was passiert mit unbestätigten Rechten?
Was ein Konzept leisten muss, damit es hält
Ein Berechtigungskonzept ist kein Dokument, sondern ein Zustand, der sich prüfen lässt. Dafür braucht es vier Dinge: ein Rollenmodell, das zum jeweiligen System passt, eine saubere Trennung zwischen Konten für Anwendungen und für Menschen, einen dokumentierten Stand als Quelltext und eine wiederkehrende Prüfung mit klarer Zuständigkeit.
Rechte nur an Rollen vergeben
Konten bekommen Rollen, Rollen bekommen Rechte. Jede direkte Vergabe an ein Konto ist eine Ausnahme, die begründet und befristet sein muss, sonst umgeht sie das ganze Modell.
Voreinstellungen bewusst abräumen
PostgreSQL gibt jedem das Verbindungsrecht, Oracle hat Rechte an PUBLIC vergeben, im SQL Server gibt es die Rolle public und den Gastbenutzer. Was du nicht wegnimmst, gilt weiter.
Dienstkonten von Personen trennen
Eine Anwendung bekommt ihr eigenes Konto je Umgebung, mit genau den Rechten, die sie im Betrieb braucht. Umgekehrt gehört kein persönliches Konto in eine Verbindungszeichenfolge.
Erhöhte Rechte befristen
Zugriff auf Produktivdaten für die Fehlersuche wird nach Freigabe erteilt, protokolliert und läuft von selbst wieder ab. Ein dauerhafter Vollzugriff ist keine Fehlersuche, sondern eine Gewohnheit.
Den Sollstand versionieren
Rollen und Rechte gehören als Skript neben das Schema in die Versionsverwaltung. Was von Hand im Produktivsystem vergeben wurde, taucht dann im Vergleich als Abweichung auf.
Die Prüfung an den Fachbereich geben
Ob jemand die Umsatztabelle lesen darf, entscheidet nicht die Administration. Die Liste geht an die verantwortliche Stelle im Fachbereich, und was niemand bestätigt, wird entzogen.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Rollen heißen überall Rollen und bedeuten überall etwas anderes
PostgreSQL kennt nur einen Begriff. Ein Benutzer ist eine Rolle mit Anmelderecht, eine Gruppe ist eine Rolle ohne, und Mitgliedschaft wird mit GRANT rolle TO konto vergeben. Achte auf INHERIT: Eine Rolle mit NOINHERIT gibt ihre Rechte erst nach einem ausdrücklichen SET ROLE her, was für kontrollierte Sonderrechte nützlich und für Alltagsrollen eine Fehlerquelle ist.
Oracle trennt Rollen und Benutzer, und dort lauert eine Falle, die viele Stunden kostet: In einer gespeicherten Prozedur mit den Rechten des Erstellers sind Rollen nicht aktiv. Was über eine Rolle vergeben wurde, steht dem Code nicht zur Verfügung, für ihn muss das Recht direkt am Eigentümer hängen. Dazu kommt, dass eine zugewiesene Rolle nur wirkt, wenn sie zu den Standardrollen des Kontos gehört oder mit SET ROLE eingeschaltet wird.
Der SQL Server unterscheidet zwei Ebenen. Auf Serverebene gibt es Anmeldungen und feste Serverrollen, auf Datenbankebene Benutzer und Datenbankrollen wie db_datareader oder eigene. Beide sind über die Sicherheitskennung verbunden, und genau diese Verbindung zerreißt beim Zurückspielen auf eine andere Instanz, sobald es sich um SQL-Anmeldungen handelt: Der Benutzer bleibt in der Datenbank stehen, seine Anmeldung existiert dort nicht, und die Anwendung kommt nicht herein. Windows-Anmeldungen aus derselben Domäne bringen ihre Kennung mit und sind von dem Problem nicht betroffen. MySQL wiederum hat Rollen erst mit Version 8.0 bekommen, davor gab es nur Rechte je Konto. Dort ist ein Konto immer ein Paar aus Name und Herkunft, derselbe Name von einem anderen Rechner ist also ein anderes Konto mit eigenen Rechten, und zugewiesene Rollen sind nach der Anmeldung nicht automatisch aktiv.
Die Voreinstellungen sind der blinde Fleck
Rechte, die niemand vergeben hat, sind die unangenehmste Sorte, weil sie in keiner Liste stehen. In PostgreSQL ist die Sammelrolle PUBLIC der Klassiker: Sie darf sich standardmäßig mit jeder neuen Datenbank verbinden und angelegte Funktionen ausführen. Bis Version 14 durfte sie zusätzlich im Schema public Objekte anlegen, seit Version 15 ist das abgeschaltet. Ein zweiter Punkt betrifft die Zukunft: Ein GRANT wirkt nur auf vorhandene Tabellen. Damit später angelegte Tabellen automatisch abgedeckt sind, braucht es ALTER DEFAULT PRIVILEGES, sonst fällt die nächste Tabelle aus dem Konzept heraus.
In Oracle sind Rechte an PUBLIC vergeben, unter anderem auf Pakete, mit denen sich Netzwerkverbindungen aufbauen oder Dateien lesen lassen. Diese Vergaben stammen aus der Installation und gelten für jeden angelegten Benutzer, seit Version 12c ist der tatsächliche Zugriff allerdings zusätzlich über Netzwerk-ACLs und Verzeichnisobjekte abgesichert. Prüf deshalb beides, die Vergabe und den ACL-Eintrag. Im SQL Server spielt die Rolle public dieselbe Rolle, dazu kommt der Gastbenutzer, der in neuen Benutzerdatenbanken zwar abgeschaltet ist, in älteren und migrierten Beständen aber regelmäßig aktiviert wurde. In MySQL sind es alte anonyme Konten und Rechte, die versehentlich global auf *.* statt auf eine einzelne Datenbank vergeben wurden.
Eine dritte Quelle ist der Eigentümer. Wem ein Objekt gehört, der hat darauf alle Rechte, unabhängig von jeder Rolle, und er kann sie weitergeben. Wenn Tabellen dem Konto der Anwendung gehören, hat dieses Konto damit dauerhaft Vollzugriff einschließlich Löschen. Ein eigener Eigentümer ohne Anmelderecht, dem die Objekte gehören, trennt das sauber und kostet einmalig zehn Minuten.
Dienstkonten trennen, und zwar in beide Richtungen
Für Anwendungen gilt: ein eigenes Konto je Anwendung und Umgebung, damit sich Zugriffe zuordnen lassen und ein kompromittiertes Testsystem nicht auf die Produktion zeigt. Die Rechte beschränken sich auf das, was im laufenden Betrieb gebraucht wird, also Lesen und Schreiben in den eigenen Tabellen. Schemaänderungen laufen über ein getrenntes Konto, das nur während der Auslieferung verwendet wird. Andernfalls kann die Anwendung jederzeit Tabellen löschen, und ein Fehler im Migrationsteil tut das dann auch.
In die andere Richtung gilt dasselbe: Kein persönliches Konto gehört in eine Verbindungszeichenfolge. Sobald die Person das Unternehmen verlässt und ihr Konto gesperrt wird, steht der Dienst. Das ist ein Ausfall, der sich sauber vermeiden lässt, und er tritt regelmäßig genau am Tag nach dem letzten Arbeitstag ein.
Kennwörter für Dienstkonten gehören in eine Kennwortverwaltung mit festgelegtem Wechsel, nicht in eine Datei im Anwendungsverzeichnis. Wo die Umgebung es hergibt, ist eine Anmeldung ohne Kennwort der bessere Weg: der SQL Server über integrierte Windows-Authentifizierung mit einem verwalteten Dienstkonto, PostgreSQL über Zertifikate oder ein externes Verfahren, Oracle über die Wallet-Anmeldung. Bleibt der Nebeneffekt der Verbindungspools: Die Datenbank sieht nur das technische Konto und nicht die Person dahinter. Wer nachvollziehen muss, wer welchen Datensatz geändert hat, braucht das in der Anwendung, etwa über ein Feld mit dem ändernden Konto oder über eine Sitzungsvariable, die die Anwendung setzt und ein Auslöser mitschreibt.
Nachvollziehbar heißt: der Stand steht geschrieben
Der Sollstand gehört als Skript in dieselbe Versionsverwaltung wie das Schema. Damit ist jede Änderung nachvollziehbar, sie durchläuft dieselbe Prüfung wie Code, und sie lässt sich auf eine neue Umgebung anwenden, ohne dass jemand aus dem Gedächtnis nachbaut. Manuelle Vergaben auf dem Produktivsystem bleiben möglich, aber sie tauchen im nächsten Abgleich als Abweichung auf und müssen entweder aufgenommen oder zurückgenommen werden.
Den Iststand liefert jedes System aus dem Katalog. In PostgreSQL sind das information_schema.role_table_grants und pg_roles, ergänzt um die Ausgabe von \dp im Kommandozeilenwerkzeug. Im SQL Server verbindest du sys.database_permissions mit sys.database_principals, in Oracle fragst du DBA_ROLE_PRIVS, DBA_SYS_PRIVS und DBA_TAB_PRIVS ab, in MySQL SHOW GRANTS je Konto und die Tabelle mit den Rollenzuordnungen. Ein kleines Skript, das diesen Stand exportiert, ist die halbe Prüfung.
Für die Frage, wer tatsächlich zugegriffen hat, braucht es eine Aufzeichnung. Oracle bietet Unified Auditing, der SQL Server SQL Server Audit, PostgreSQL die Erweiterung pgaudit, MySQL in der Enterprise-Ausgabe ein Audit-Plugin. Wichtig ist, den Umfang eng zu fassen: Wer alles aufzeichnet, erzeugt eine Datenmenge, die niemand auswertet, und verstößt bei personenbezogenen Zugriffen schnell gegen die eigenen Vorgaben. Sinnvoll sind Anmeldungen, Rechteänderungen und Zugriffe auf die als schützenswert eingestuften Tabellen.
Die Rechteprüfung, die nicht im Sand verläuft
Eine Prüfung funktioniert, wenn drei Bedingungen erfüllt sind. Erstens geht die Liste an die Person, die fachlich entscheiden kann, und nicht an die IT, die nur ausführt. Zweitens ist die Liste lesbar, also nach Person und Datenbereich sortiert und nicht als Auszug aus dem Systemkatalog. Drittens gibt es eine Vorgabe für den Fall, dass niemand antwortet, und die lautet: entziehen. Ohne diese Vorgabe endet jede Prüfung in einer offenen Rückfrage.
Der größte Einzelposten ist der Austritt. Er wird meist über den Verzeichnisdienst abgebildet, was für Anmeldungen reicht, aber nicht für alles: lokale Datenbankkonten ohne Verzeichnisanbindung, Konten in Testsystemen, geteilte Zugänge zu Auswertungswerkzeugen. Diese Fälle gehören ausdrücklich in die Austrittsliste, sonst bleiben sie bestehen, und niemand merkt es.
Zum Schluss der Punkt, der bei fast jeder Prüfung nachträglich auffällt: Rechte reisen mit den Daten. Wird eine Produktivdatenbank auf ein Testsystem zurückgespielt, kommen die Rechte des Produktivsystems mit, in Oracle vollständig, im SQL Server als Benutzer ohne passende Anmeldung, in PostgreSQL als Verweis auf Rollen, die auf dem Ziel möglicherweise anders belegt sind. Wer regelmäßig Kopien zieht, braucht deshalb einen festen Schritt, der die Rechte auf dem Ziel neu setzt.
Dazu passende Kurse
Weil jedes System sein eigenes Rollenmodell mitbringt, lohnt sich der geführte Durchgang, und dafür gibt es bei cmt Kurse zu Rechtevergabe und Datenbanksicherheit .
Wer mit Standardrollen, Rechten an PUBLIC und Unified Auditing arbeitet, findet den passenden Einstieg in die Oracle-Kurse rund um Absicherung und Auditing .
Wie sicher bist du beim Thema wirklich?
Lesen fühlt sich schnell nach Können an. Ein kurzer Test zeigt dir, was davon schon sitzt und wo sich ein Kurs lohnt. Kostenlos, ohne Anmeldung, mit einer Erklärung zu jeder Antwort.
Wo du genau das übst
Super Schulung, in der der Trainer auch auf eigene Fragestellungen eingegangen ist.
Super Grundlagenschulung mit allen wichtigen Punkten und hilfreichen Tipps!
Schön, sich 5 Tage ungestört mit Postgres beschäftigen zu können.
Häufige Fragen
Reicht es nicht, alles über ein Konto für die Anwendung zu regeln?
Wie regeln wir Entwicklerzugriffe auf Produktivsysteme?
Was passiert mit Rechten beim Zurückspielen einer Sicherung?
Brauchen wir eine Rechteprüfung, wenn ohnehin alles protokolliert wird?
Passt thematisch dazu
Wie weit dasselbe Wort Rolle in einem anderen System trägt, zeigt der Aufbau aus Rolle, Profil und Berechtigungsobjekt in SAP , wo eine Transaktion trotz vorhandenem Startrecht mitten in der Verarbeitung abbrechen kann.
Deine Ansprechpartner
Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.
Yves Hoppe
Weiterbildung & Beratung
Hilft dir, aus dem Datenbanken-Programm den passenden Kurs für deinen Stand zu finden.
Norbert Jansen
Beratung & Inhouse
Plant mit dir Inhouse-Trainings, die auf eure Abläufe und euren Datenbestand zugeschnitten sind.
Vom gewachsenen Bestand zu einem Stand, der sich prüfen lässt
Rollenmodelle, Voreinstellungen und der Abgleich zwischen Soll und Ist lassen sich an einem echten System durchgehen, und genau so ist es bei cmt aufgebaut.