Oracle Database Common User in Multitenant Datenbanken für Backup und Recovery

Backup, Restore/Recover und Sicherheit gehören immer zu den wichtigsten Themen für einen Datenbankadministrator. Daten müssen sicher gehalten werden und es ist kritisch, dass die Daten dem Business wieder zur Verfügung gestellt werden können, wenn etwas passiert - sei es mit dem Server, einem applikatorischen Datenverlust oder z.B. durch eine Security-Problematik wie einem Ransomware-Angriff.

Zur Verbesserung der Sicherheit (Least Privilege Principle) bei Backups hat Oracle deshalb vor einigen Jahren neue Privilegien und Benutzer eingeführt. Für Backup und Recovery Operationen ist neu „SYSBACKUP“ hinzugekommen. „SYSBACKUP“ gibt es als vordefinierten Benutzer und als vordefinierte Sammlung von Privilegien.

Aber macht es Sinn, einen Benutzer zu verwenden, dessen Name z.B. ein Hacker einfach so kennt? Wäre es nicht besser, einen eigenen Benutzer zu haben, dem wir das SysBackup Privileg granten?

Connecten wir uns also mal an eine 19c Datenbank an den Root Container und erstellen einen neuen Benutzer. Diesen Benutzer nennen wir nun c##backup_problem und geben ihm ein Passwort mit. Danach granten wir diesem Benutzer die SysBackup Privilegien.

Zwei einfache Befehle und wir haben unseren Benutzer erstellt und die erforderlichen Rechte gegranted. Dieser User benötigt weder Tablespace Quota noch sonstige Rechte/Rollen, also lassen wir das alles weg. Schliesslich wollen wir nur ein Mimimum an erforderlichen Rechten mitgeben.

Nun versuchen wir als erstes ein Backup durchzuführen und benutzen dazu den Recovery Manager. Wichtig ist, dass beim target connect die Phrase „as sysbackup“ für diesen Benutzer explizit angegeben werden muss.

Jetzt sollte es einfach sein, die Datenbank mit allen ihren Containern zu backupen (CDB$ROOT, PDB$SEED und PDB19_1).

Wie man unschwer am Screenshot erkennen kann - das hat funktioniert. Damit wären wir eigentlich fertig, unser Benutzer funktioniert tadellos, oder doch nicht?

Machen wir einen einfachen Test. Wir simulieren den Verlust eines Datafiles in unserer pluggable database PDB19_1 und löschen einfach ein Datafile weg. 

Um schnell einen Fehler zu erhalten, starten wir die Datenbank neu und sehen, unsere PDB ist nun nur noch gemountet. Beim Versuch, diese zu öffnen, erhält man eine Fehlermeldung.

Zum Glück haben wir ein funktionierendes Backup und den Data Recovery Advisor der Oracle Datenbank. So können wir sehr schnell und einfach die Datenbank wiederherstellen und die Benutzer können mit den Applikationen weiterarbeiten. Wir müssen uns lediglich als c##backup_problem Benutzer anmelden und schon können wir „List failure;“, „Advise failure;“ und „Repair failure;“ im Recovery Manager verwenden. Starten wir also den Recovery Manager und schauen, was bei List failure und Advise failure passiert. 

Alles ok, nichts unerwartetes. Nachdem List und Advise failure den gewünschten Output gebracht haben, lassen wir den Fehler reparieren. Das „Repair failure;“ ist in Sekundenbruchteilen ausgeführt.

Hoppla, damit haben wir nicht gerechnet. Ein Ora-01031: nicht ausreichende Berechtigungen beim Befehl „alter session set container“? Aber wir haben doch einen Common User angelegt und diesem SysBackup Rechte gegranted? Wie kann das denn passieren?

Zuerst werfen wir einen Blick in das Repair Script, welches die Datenbank ausführen möchte.

Wie unschwer zu erkennen ist, möchte der Data Recovery Advisor das gelöschte Datafile in der pluggable database offline setzen, restore und recovern und dann wieder online setzen. Implizit findet bei beiden SQLs ein „alter session set container“ statt und genau dieses schlägt fehl. Was also tun? Klar, man kann sich jetzt als SYS oder "/" an die Datenbank anmelden, aber dafür hat der DBA, der sich um die Backups kümmert, vielleicht keine Rechte und bis die Passwörter von den Kollegen bekannt sind, das dauert ggfs. Stunden. Deshalb lassen wir es doch lieber nicht erst zu so einer Situation kommen. 

Versuchen wir also herauszufinden, wo dieser Fehler herkommt und wie man ihn von vornherein verhindern kann. Wie bereits beschrieben, scheinen dem c##backup_problem Benutzer Rechte für die PDB zu fehlen. Dieses scheint in der PDB zu fehlen, obwohl wir doch SYSBACKUP als Privileg an unseren Benutzer gegranted haben.

Sowohl die Dokumentation als auch der Support (einziger Eintrag, der in die Richtung geht ist Oracle Support Document 2140670.1 (How to take RMAN Full DB backup using SYSBACKUP) https://support.oracle.com/epmos/faces/DocumentDisplay?id=2140670.1) schweigen sich zu dieser Problematik aus.

Legen wir also noch einmal einen neuen Benutzer an und granten diesem wieder die SysBackup Privilegien. Dieses Mal allerdings mit „container=all“ clause.

Nun connecten wir mit rman und dem neuen Benutzer als sysbackup analog wie vorher an unsere Datenbank und lassen den Data Repair Advisor noch einmal laufen. (Den Output vom list failure und advise failure skippen wir, das hat sowieso funktioniert).

Und siehe da, da die Datendatei nun richtig hergestellt wurde, können wir die PDB19_1 auch wieder öffnen.

Es ist also zweifelsfrei nachgewiesen, dass der fehlende „container=all“ clause für den grant des SysBackup Privileges an den Benutzer c##backup_problem verantwortlich ist.

Was lernen wir daraus?

Natürlich wie immer zuerst – die Hälfte der Arbeit ist nicht die ganze Arbeit. Hätten wir das Restore nicht ausprobiert (oder ein anderes Restore Szenario getestet), wäre uns dieser Fehler nie aufgefallen, denn das Backup über den Root Container hat ohne weitere Probleme funktioniert. Aber kann man immer alle Szenarios testen, um feststellen zu können, ob ein solches Privileg richtig vergeben wurde? Natürlich nicht.

Und man solle keiner Doku trauen, auch das ist wieder Teil des Lernprozesses - denn weder in der Dokumentation noch im Support findet man den kleinsten Hinweis darauf, dass man container=all für den SYSBACKUP grant nutzen soll.

Zumindest für das SYSBACKUP Privileg gibt es allerdings einen kleinen „Shortcut“ als Test. Man kann einfach die PDB(s) über den Recovery Manager öffnen oder schliessen. Schlägt der Versuch fehl, ist der jeweiligen PDB das Privileg nicht gegranted worden.