Managing Default Users- Users and Basic Security
When you create a database, there are default users such as SYS and SYSTEM, and the passwords are set when the database is created. The passwords can be changed and managed with security policies.
Here is the list of the administrative user accounts:
• SYS
• SYSTEM
• SYSBACKUP
• SYSDG
• SYSKM
• SYSRAC
Administrative accounts have special permissions required to administer different areas of the database. These accounts also have privileges of CREATE ANY TABLE or ALTER SESSION and EXECUTE privileges on SYS schema. It is recommended to create a different account and grant the proper roles and privileges for daily tasks and the administrator so that the SYS and SYSTEM accounts are not used.
SYSBACKUP is for Oracle Recovery Manager (RMAN) backup and recovery operations. SYSDG is for Data Guard operations with the Data Guard Broker or DGMGRL. SYSKM performs the keystore operations for Transparent Data Encryption.
Oracle Real Application Clusters, connecting the database to the clusterware using SRVCTL. SYSRAC is not available to grant to a database user and is only for the Oracle agent. The DBA role is automatically created with the database.
This role should be granted only to database administrators. In 23c, the DB_DEVELOPER_ROLE role is the new role also created with the database to grant the permissions for a developer to connect and create objects in the application schema.
Default Accounts as Schema-Only
There are several predefined schema accounts that are created automatically when the database is created. Most of these accounts in 23c are now defined as schema-only accounts, except for the sample accounts.
The accounts are locked and expired during the installation, and it is recommended to keep these accounts as schema-only accounts. Schema-only accounts cannot log into the database.
They can have objects and be granted system privileges to create objects such as tables and procedures. These schemas can be configured to be used as client users in proxy authentication. To see if an
account is schema-only, query the DBA_USERS view, and AUTHENTICATION_TYPE will show NONE if the account is schema only.
SYS vs. SYSTEM
Oracle novices sometimes ask, “What’s the difference between the SYS and SYSTEM schemas?” The SYS schema is the superuser of the database, owns all internal data dictionary objects, and is used for tasks such as creating a database, starting or stopping the instance, backing up and recovering, and adding or moving data files.
These types of tasks typically require the SYSDBA or SYSOPER role. Security for these roles is often controlled through access to the OS account owner of the Oracle software. Additionally, security for these roles can be administered via a password file, which allows remote client/server access.
The SYS account can be locked, which prevents unauthorized access from the server and another OS account, but the SYSDBA role will need to be granted to an authorized user first. Even though locking the SYS account will prevent a shared default account from being used, there are some options or systems that might require SYS to remain unlocked. The password should be managed appropriately and locked down, as with other highly privileged accounts.
In contrast, the SYSTEM account is not very special. It is just an account that has been granted the DBA role. Many companies lock the SYSTEM schema after database creation and never use it because it is often the first schema a hacker will try to access when attempting to break into a database.
Rather than risking an easily guessable entry point to the database, privileged users should be granted the role directly or as part of their security group.
Another account might be used for automated jobs and granted the DBA role for administrative tasks.
Tasks such as creating users, changing passwords, and granting database privileges are available through other APIs to manage privileges instead of having these highly privileged accounts in the database. It is normally a requirement that auditing shows which DBA logged on and when and then creates a separate privileged account for each DBA on the team (and, in turn, on database auditing).
I have normally had one account for regular use and a separate privileged account that was granted the privileges needed to perform tasks as the DBA.
