Stell dir vor, deine Daten sind eine Festung, und jeder Bewohner der Festung hat seine eigenen Rechte: Manche dürfen nur im Hof spazieren, andere haben die Schlüssel zur Schatzkammer, und wieder andere sitzen im Thronsaal und regeln alles. In unserer Datenbank übernehmen die Befehle GRANT und REVOKE genau diese Rolle. Sie entscheiden, wer, wohin und warum gehen darf.
Der GRANT-Befehl, wie ein normaler Grant eben, erlaubt es, bestimmten Rollen Zugriff auf Ressourcen (z.B. Datenbanken, Tabellen, Schemas) zu geben. Das ist wie eine "Party-Einladung", bei der du entscheidest, wer lesen, schreiben oder die Möbel zerlegen darf.
Der REVOKE-Befehl nimmt dagegen vorher vergebene Rechte wieder weg. Das ist wie zu sagen: "Hey, die Party ist für dich vorbei, gib den Schlüssel am Ausgang ab".
Rechte vergeben mit GRANT
Fangen wir ganz oben an – bei der Datenbank. Damit ein User sich mit der DB verbinden kann, braucht er das CONNECT-Recht. Dafür nutzt man:
GRANT CONNECT ON DATABASE database_name TO role_name;
Zum Beispiel, wenn wir die Datenbank university und die Rolle student haben, können wir den Studenten erlauben, sich zu verbinden, mit folgendem Befehl:
GRANT CONNECT ON DATABASE university TO student;
Aber nur verbinden heißt noch lange nicht, dass man alles machen darf. Damit ein User Objekte in der DB anlegen kann, braucht er noch das CREATE-Recht:
GRANT CREATE ON DATABASE university TO student;
Die Rechte auf der Datenbank kannst du mit folgendem Befehl checken:
\l+ university
Rechte entziehen mit REVOKE
Wenn der Student plötzlich verdächtig wird (z.B. mehr Tabellen anlegt als erwartet), kannst du ihm das CREATE-Recht wieder wegnehmen:
REVOKE CREATE ON DATABASE university FROM student;
Danach kann der Student sich nur noch verbinden, aber keine "kreativen Freiheiten" mehr ausleben.
Zugriffsrechte auf Schema-Ebene einstellen
Ein Schema ist im Prinzip ein "Raum" in der Datenbank, in dem Tabellen, Views und andere Objekte liegen. Damit ein User mit Objekten im Schema arbeiten kann, kannst du Rechte für Lesen, Schreiben oder Erstellen vergeben.
Rechte auf ein Schema vergeben
Angenommen, wir haben das Schema public (das wird standardmäßig in jeder DB angelegt). Wir können einem User erlauben, den Inhalt des Schemas zu sehen:
GRANT USAGE ON SCHEMA public TO student;
Aber nur USAGE reicht nicht, um mit Tabellen zu arbeiten. Damit der User neue Objekte anlegen kann, kommt noch dazu:
GRANT CREATE ON SCHEMA public TO student;
So kann der Student nicht nur lesen, sondern auch Tabellen im public-Schema anlegen.
Rechte auf ein Schema entziehen
Wenn der Student plötzlich das Schema mit komischen Tabellen wie bad_idea_01 zumüllt, kannst du seine Rechte einschränken:
REVOKE CREATE ON SCHEMA public FROM student;
Jetzt kann der Student keine neuen Tabellen mehr hinzufügen. Ordnung wiederhergestellt!
Zugriffsrechte auf Tabellen-Ebene einstellen
Die Tabelle ist wahrscheinlich das beliebteste DB-Objekt. Schauen wir uns an, wie man den Zugriff auf Tabellen einstellt. Es gibt drei Hauptkategorien: Lesen, Schreiben und Ändern.
Leserechte
Um einem User das Lesen einer Tabelle zu erlauben, nutzt man:
GRANT SELECT ON TABLE table_name TO role_name;
Zum Beispiel, damit Studenten die Tabelle courses lesen können:
GRANT SELECT ON TABLE courses TO student;
Jetzt kann der student SELECT-Queries auf courses ausführen.
Schreibrechte
Wenn du willst, dass ein User neue Zeilen in eine Tabelle einfügen kann, geht das so:
GRANT INSERT ON TABLE table_name TO role_name;
Beispiel:
GRANT INSERT ON TABLE courses TO student;
Jetzt können Studenten neue Kurse in die Tabelle eintragen. Aber warte... Ist das wirklich eine gute Idee?
Rechte zum Ändern und Löschen
Wenn ein User bestehende Zeilen updaten oder löschen können soll, braucht er UPDATE- und DELETE-Rechte.
GRANT UPDATE ON TABLE courses TO student;
GRANT DELETE ON TABLE courses TO student;
Tipp: Übertreib es nicht mit diesen Rechten. Wenn Studenten DELETE-Rechte bekommen, können sie aus Versehen (oder absichtlich) alles kaputtmachen.
Beispiel: Rolle mit eingeschränkten Rechten anlegen
Stell dir vor, wir legen eine Rolle für Lehrkräfte an, die Leserechte für Studenten- und Kursdaten brauchen, aber keine Daten löschen dürfen. So geht's:
- Rolle anlegen:
CREATE ROLE teacher;
- Leserechte für die Tabellen
studentsundcoursesvergeben:
GRANT SELECT ON TABLE students, courses TO teacher;
- Löschrechte entziehen:
REVOKE DELETE ON TABLE students, courses FROM teacher;
Jetzt haben unsere Lehrkräfte nur die nötigen Rechte – und nicht mehr.
Wie man GRANT und REVOKE flexibel kombiniert
Angenommen, wir haben die Rolle intern, die wir einschränken wollen. Sie soll nur Zugriff auf Kursdaten haben, aber auf keinen Fall auf Studentendaten. So sieht das aus:
- Zugriff nur auf die Tabelle
courseserlauben:
GRANT SELECT, INSERT ON TABLE courses TO intern;
- Sicherstellen, dass
internkeine Rechte aufstudentshat:
REVOKE ALL ON TABLE students FROM intern;
Mit dieser Kombi kannst du die Rechte ganz genau einstellen.
Beispiele aus echten Projekten
Dieses Zugriffsmanagement wird oft in echten Projekten genutzt. Zum Beispiel:
- In Online-Shops werden Rechte auf User- und Bestelltabelle zwischen den Rollen "admin", "operator" und "gast" verteilt.
- In Uni-Systemen dürfen Admins Kurse hinzufügen und ändern, Studenten sie aber nur ansehen.
- In Banksystemen ist der Zugriff auf Kundenkonten zwischen Mitarbeitern verschiedener Abteilungen aufgeteilt.
GO TO FULL VERSION