Oracle Database Common User in Multitenant Datenbanken für Backup und Recovery - Teil 2
Warum Rechte entziehen manchmal schwieriger ist, als es auf den ersten Blick aussieht!
Im ersten Teil der Fun mit Common User-Reihe stand das Thema "Warum richtiges Rechte und Privilegien granten richtig wichtig ist!" im Mittelpunkt.
Kurz zusammengefasst, es war wichtig, dass der container=all clause beim Granten des SysBackup-Privilegs verwendet wird, da es ansonsten nur für den aktuellen Container gilt.
Das macht beim Backup über CDB$ROOT keinen Unterschied, beim Restore kann man damit aber ganz böse Scheitern. Also gerade in der Situation, in der der Stresspegel sowieso extrem hoch ist.
Doch genug der Zusammenfassung, beschäftigen wir uns nun mit dem Entziehen der SysBackup-Privilegien.
Stellen wir uns vor, wir haben in unserer Multitenant-Datenbank einen C##BACKUP_ADMIN1 Benutzer, der für einen Kollegen eingerichtet wurde, der zukünftig mit dem Backup über den Recovery Manager nichts mehr zu tun haben wird.
Mit diesem Common User konnten ohne Probleme alle Backup und Recovery Operationen auf dem Root Container (CDB$ROOT) und den Pluggable Databases durchgeführt werden.
Rein zum Test, um zu zeigen, dass das auch wirklich funktioniert (siehe Teil 1 der Reihe), schließen wir die PDB19_1 und öffnen sie im Anschluss gleich wieder.
Nun entziehen wir dem Benutzer C##BACKUP_ADMIN1 die SysBackup-Privilegien. Dies natürlich unbedingt mit dem container=all clause.
Nach der erfolgreichen Ausführung sollte es nun nicht mehr möglich sein, sich am Recovery Manager zu connecten und ein Backup oder Restore auszuführen.
Wie jetzt, wir hatten doch dem User gerade die SysBackup-Privilegien entzogen, wieso kann sich dieser denn noch connecten und ein Backup durchführen? Wie ist das möglich, trotz container=all clause?
Erinnern wir uns an den ersten Teil dieser Serie. Dort wurde einmal mit container=all und einmal ohne container clause (entspricht container=current) SysBackup als Privileg an den Benutzer gegranted. Entziehen wir also dem Benutzer C##BACKUP_ADMIN1 im CDB$ROOT ein zweites Mal die SysBackup-Privilegien, dieses mal ohne den container=all clause.
Und, klappt es nun und der C##BACKUP_ADMIN1 Benutzer hat alle Rechte verloren? Prüfen wir das mal besser.
Gut, die Rechte sind weg. Damit dürfte sich der C##BACKUP_ADMIN1 Benutzer sowohl am Root Container, als auch an der PDB19_1 nicht mehr connecten dürfen.
Was passiert also, wenn man sich gegen die PDB19_1 connected?
Man kann sich immer noch connecten. Aber warum?
Die Antwort ist relativ simpel. Offensichtlich hat es jemand zu gut gemeint und eventuell auch dem container PDB19_1 das SysBackup-Privileg gegranted. Um das zu Entziehen, melden wir uns an der PDB19_1 an bzw. ändern unsere Session. Ein container=<pdb> clause existiert übrigens nicht. Nun entziehen wir innerhalb des Containers PDB19_1 das SysBackup-Privileg.
Nun kann man sich endlich auch nicht mehr als SysBackup-Benutzer an der Pluggable Database PDB19_1 anmelden.
Wahrscheinlich stellt sich der ein oder andere nun die Frage, was genau ist da passiert?
Um zu erklären und zu zeigen, was da wirklich so vor sich ging, machen wir noch einmal einen Schritt zurück. Betrachten wir die Privilegien des C##BACKUP_ADMIN1 Benutzers in der v$pwfile_users View.
Unschwer ist zu erkennen, dass dem Benutzer für drei verschiedene Container das SysBackup-Privileg gegranted wurde. Genauer gesagt für Container '0', '1' und '3'.
Schauen wir also mal in v$containers, welche Container das sind.
Wir finden im Container mit der ID '1' unseren Root Container und mit der ID '3' unsere pluggable Database PDB19_1. Einen Container mit der ID '0', wie in der v$pwfile_users gesehen, gibt es allerdings nicht.
Das ist nämlich der Eintrag für einen Grant oder Revoke mit dem container=all clause.
Prüfen wir, ob das stimmt:
Tatsächlich, ein revoke mit container=all clause entfernt NICHT die Privilegien für alle container, sondern tatsächlich nur den Eintrag für den virtuellen Container mit der ID '0'.
Revoken wir als nächstes im CDB$ROOT die SysBackup-Privilegien "lokal":
Es fehlt immer noch der Revoke des SysBackup-Privilegs in der PDB19_1. Also wechseln wir in den Container und entziehen das Privileg lokal.
Nachdem wir also nun in allen betroffenen Containern ein Revoke durchgeführt haben, hat der Benutzer wirklich keine Rechte mehr.
Natürlich hätte man für den Benutzer C##BACKUP_ADMIN1 auch einfach den Account locken oder ihn gleich ganz droppen können. Aber vielleicht wird dieser Common-User auch zukünftig noch für andere Dinge, z.B. Clonen von PDBs von Produktion nach Test oder Datapump-Exporten und -Importen benutzt. Dann ist es eben nicht möglich, diesen einfach komplett still zu legen.
Wichtig - und das zeigt dieses Beispiel hervorragend - ist es, zu prüfen, welche Rechte/Privilegien wirklich für einen Benutzer vorhanden sind, damit alle entzogen werden können. Das kann recht umständlich und aufwändig werden, es bleibt einem aber, nimmt man Security ernst, leider nichts anderes übrig.
Kommentare
|
Hallo Herr Sieber.
Danke für das Feedback, es freut uns immer sehr, Anmerkungen zu unseren Blogeinträgen zu erhalten.
Viele Grüsse
Jörg Sobottka
|
Hallo H. Sobottka,
vielen Dank für das extrem wichtige und hilfreiche Beispiel.
Hilft sehr!
Viele Grüße