Wofür braucht man den SYS-User im Alltag?
Vor einigen Tagen erreichte mich eine Frage einer Blog-Leserin: „wir haben eine Anwendung eines Software-Herstellers, der bei einem Release-Wechsel den User SYS verwendet. Der Hersteller meint, ganz ohne SYS geht es nicht. Unser Oracle-Team sieht das als ein „no-go“ an“. Grund genug, sich einmal der Frage zu widmen: Wofür braucht man den SYS-User im Alltag?
Was sagt die Oracle-Dokumentation?
Oracle Database 21c – Administrators Guide – 1.6.2.1 About Administrative User Accounts:
„Administrative user accounts have special privileges required to administer areas of the database, such as the CREATE ANY TABLE or ALTER SESSION privilege, or EXECUTE privilege on packages owned by the SYS schema.
The following administrative user accounts are automatically created when Oracle Database is installed:
- SYS
- SYSTEM
- SYSBACKUP
- SYSDG
- SYSKM
- SYSRAC
Oracle recommends that you create at least one additional administrative user and grant it appropriate privileges for performing daily administrative tasks. Do not use SYS and SYSTEM for these purposes.
[…]
1.6.2.2 SYS
When you create an Oracle database, the user SYS is automatically created with all the privileges.
All of the base tables and views for the database data dictionary are stored in the schema SYS. These base tables and views are critical for the operation of Oracle Database. To maintain the integrity of the data dictionary, tables in the SYS schema are manipulated only by the database. They should never be modified by any user or database administrator, and no one should create any tables in the schema of user SYS. (However, you can change the storage parameters of the data dictionary settings if necessary.)
1.6.2.3 SYSTEM
When you create an Oracle database, the user SYSTEM is also automatically created and granted the DBA role.
The SYSTEM user name is used to create additional tables and views that display administrative information, and internal tables and views used by various Oracle Database options and tools. Never use the SYSTEM schema to store tables of interest to non-administrative users.”
Die Dokumentation sagt also ganz klar „Do not use SYS and SYSTEM for (daily administrative tasks)“. Soweit die Theorie. Die Realität sieht natürlich anders aus. Meist wird aus Bequemlichkeit – und da schließe ich mich nicht aus – von Datenbankadministratoren der User SYS genutzt. Er kann und darf alles in der Datenbank und – wenn man als oracle-User auf dem Server angemeldet ist – geht ein „sqlplus / as sysdba“ meist schneller von der Hand als ein „sqlplus adminuser“ und die anschließende Password-Eingabe.
Wofür braucht man also den SYS-User im Alltag?
Fangen wir erstmal andersherum an und fragen: wofür brauchen wir den SYS-User nicht zwingend?
Und da kommen wir dann z.B. zu den Betriebssystemgruppen OPER, BACKUPDBA, DGDBA:
Wenn der Betriebssystemuser mit dem ich angemeldet bin, der Gruppe OPER zugeordnet ist, dann kann ich mich mit „sqlplus / as sysoper“ anmelden. Wenn ich mich von Remote als SYSOPER anmelden will, dann muss der Benutzer mit dem ich arbeite, das SYSOPER-Recht bekommen („GRANT SYSOPER to benutzer“) und dann kann ich mich mit „sqlplus benutzer/password@datenbank as SYSOPER“ anmelden.
Als SYSOPER kann ich z.B. die Datenbank starten und stoppen oder ein vollständiges Recovery machen.
==> Für das Starten und Stoppen der Datenbank brauchen wir den User SYS also nicht zwingend.
Die Gruppen „BACKUPDBA“ ist analog mit dem Recht „SYSBACKUP“ verbunden, das alle Backup- und Recovery-Aufgaben (z.B. regelmäßiger Backup mit rman) machen kann. Dazu gibt es auch noch einen vordefinierten User SYSBACKUP (der ebenfalls das Recht „SYSBACKUP“ hat).
==> Für das Backup und Recovery brauchen wir den User SYS also nicht zwingend.
Gleiches gilt für das Thema „DataGuard“. Da gibt es die Betriebssystemgruppe „DGDBA“ sowie das Recht „SYSDG“ und den User „SYSDG“. Damit kann man alle Arbeiten rund um DataGuard machen.
==> Für die DataGuard-Administration brauchen wir den User SYS also nicht zwingend.
Eine komplette Übersicht, was man mit diesen administrativen Privilegien kann und darf – und welche weiteren Privilegien es gibt, findet sich im “Oracle Database 21c – Administrators Guide – 1.7.2 Administrative Privileges”. Wichtig ist: mit diesen Rechten SYSDG, SYSBACKUP und SYSOPER kann ich zwar administrative Aufgaben machen, aber ich habe keinen Zugriff auf Objekte in der Datenbank.
Was bleibt also für den User SYS?
Wenn ich mich als User SYS anmelde, dann geht das nur als „SYSOPER“ (siehe oben) oder als „SYSDBA“. Ersteres wird aber praktisch nie genutzt. Und als SYSDBA kann man ziemlich viel (aus dem Administrators Guide):
„
- Perform STARTUP and SHUTDOWN operations
- ALTER DATABASE: open, mount, back up, or change character set
- CREATE DATABASE
- DROP DATABASE
- CREATE SPFILE
- ALTER DATABASE ARCHIVELOG
- ALTER DATABASE RECOVER
- Includes the RESTRICTED SESSION privilege
This administrative privilege allows most operations, including the ability to view user data. It is the most powerful administrative privilege.“
Für den Fall eines Applikationsupgrades ist da nicht wirklich etwas zwingend Erforderliches dabei. Und der einzige Fall, der mir einfällt, für den man den User SYS braucht ist die Vergabe von Rechten auf SYS-Objekte. Wenn z.B. ein Benutzer Rechte auf DBMS_*-PL/SQL-Pakete benötigt oder direkte GRANTS auf Dictionary-Views (z.B. ALL_TAB_COLUMNS), dann geht es nicht als SYSTEM (oder anderer Admin-User):
SQL> show user
USER is "SYSTEM"
SQL> grant execute on DBMS_OUTPUT to SCOTT;
grant execute on DBMS_OUTPUT to SCOTT
*
ERROR at line 1:
ORA-01031: insufficient privileges
SQL> grant select on ALL_TABLES to SCOTT;
grant select on ALL_TABLES to SCOTT
*
ERROR at line 1:
ORA-01031: insufficient privileges
SQL> connect / as sysdba
Connected.
SQL> show user
USER is "SYS"
SQL> grant execute on DBMS_OUTPUT to SCOTT;
Grant succeeded.
SQL> grant select on ALL_TABLES to SCOTT;
Grant succeeded.
Was heißt das dann für die Ausgangsfrage? Wie geht man damit um, wenn ein Applikationshersteller SYSDBA-Rechte oder DBA-Rechte für Installationen oder Upgrades fordert?
Als Datenbank-Administrator schrillen bei mir auch immer die Alarm-Glocken, wenn ich Installationsskripte sehe, die mit SYSDBA-Rechten laufen sollen oder bei denen eine der ersten Zeilen ist:
CREATE USER APPLIKATIONSUSER … GRANT DBA TO APPLIKATIONSUSER; ...
Denn ich solchen Fällen gibt der DBA die Verantwortung für das System zumindest ein Stück weit aus der Hand und öffnet eine Sicherheitslücke.
- Meine Frage an den Hersteller war und ist in solchen Fällen immer: Wofür genau brauchen Sie SYSDBA-Rechte bzw. die DBA-Rolle?
Intention dahinter ist: Die Aktionen, für die wirklich SYSDBA-Rechte nötig waren (Rechtevergabe auf SYS-Objekte, siehe oben) aus dem Installationsskript rauszulösen, diese Befehle zu prüfen und selbst auszuführen. Das Installationsskript kann dann anschließend mit geringeren Rechten ausgeführt werden. Und anstelle der DBA-Rolle konnten dann Rechte einzeln vergeben werden.
2. Für den Fall dass sich der Applikationshersteller nicht kooperativ gezeigt hat oder schlichtweg gesagt hat „wissen wir nicht“ oder „können wir nicht ändern“, dann war meine Entscheidung als DBA immer die Mitteilung an meinen Vorgesetzten: „Applikation X möchte diese und jene Rechte haben. Ich sehe da aus folgenden Gründen ein mögliches Sicherheitsproblem … – bitte entscheide du“. Und dann trägt er/sie die Verantwortung.
3. Wenn ein Applikationshersteller für einen Benutzer die DBA-Rolle benötigt, dann kann man ihn inzwischen (seit Oracle 12c) bitten, eine „Privilege Analysis“ zu machen, um festzustellen, welche Rechte der Benutzer wirklich braucht. Zum Thema „Privilege Analysis“ habe ich schon mehrere einführende Vorträge gehalten.
Last but not least …
Gemäß dem „Gesetz des geringsten Aufwandes“ neigen alle Lebewesen dazu, den einfachsten Weg zu nehmen, um ein Ziel zu erreichen. Und so ist es meist Bequemlichkeit, die DBAs dazu bringt mit „sqlplus / as sysdba“ zu arbeiten (obwohl meist nicht notwendig) oder die Applikationshersteller dazu bringt, auf eine entsprechende Analyse zu verzichten und pauschal „SYSDBA“- oder „DBA“-Rechte für die Installation ihrer Produkte oder für ihre Benutzer zu fordern. Zeitgemäß ist das in Zeiten steigender Sicherheitsanforderungen beides nicht.
Anmerkungen:
1. Die oben genannten Gruppen OPER, BACKUPDBA und DGDBA sind die „Quasi-Standard-Gruppen“. Man kann auch andere Gruppen verwenden und muss das dann nur bei der Installation angeben:
Wie man die Gruppen nachträglich ändert, habe ich in einem anderen Blog-Post geschrieben
- Wenn ich oben geschrieben habe „SYSTEM kann keine GRANTs auf SYS-Objekte“ vergeben, dann ist das der Normalfall; die Standard-Konfiguration. Man kann es natürlich mit der „GRANT OPTION“ ermöglichen:
SQL> show user USER is "SYS" SQL> grant execute on DBMS_OUTPUT to SYSTEM with grant option; Grant succeeded. SQL> connect system/manager Connected. SQL> grant execute on DBMS_OUTPUT to SCOTT; Grant succeeded.
3. [Ergänzung 05.12.2021] Johannes Ahrends erklärt in seinem Blog-Post “Wer ist eigentlich SYSTEM?” auch sehr gut, dass man den User SYSTEM im Alltag auch nicht verwenden sollte.
