11 User Security on Recovery Appliance
Increase the security of your data and system by limiting user access and developing strong password security policies.
Default User Accounts for Oracle Zero Data Loss Recovery Appliance
The following table lists the default users and passwords for the Oracle Zero Data Loss Recovery Appliance components. All default passwords should be changed after installation of the Recovery Appliance.
Table 11-1 Default Users and Passwords for Oracle Zero Data Loss Recovery Appliance
Component | User Name and Password |
---|---|
Compute servers |
Operating system users:
Database users: Note: Only local connections are allowed for externally authenticated users.
OSB tape backup application users:
|
Storage servers |
|
RoCE Network Fabric |
|
InfiniBand Network Fabric switches |
|
Ethernet switches |
Note: Secure the |
Power distribution units (PDUs) |
|
Compute server ILOMs |
|
Storage server ILOMs |
|
InfiniBand Network Fabric ILOMs |
|
Note:
After the Recovery Appliance has been deployed, the installation process disables all root SSH keys and expires all user passwords as a security measure for your system. If you do not want the SSH keys disabled or the passwords expired, advise the installation engineer before the deployment.See Also:
"Changing Component Passwords" to learn how to change the passwords for the Recovery Appliance components.User Roles for the Recovery Appliance
The Recovery Appliance introduces roles for named user accounts and limits operations available to those roles to improve security and logging.
The Recovery Appliance has the following security roles that have changed or are new in software release 21.1, and provide more options to meet audit and security requirements.
-
The
rasys
account is the original administrator, root-level account formerly needed to perform operations on the Recovery Appliance. Named usersdb_user
with roles and responsibilities replace the usage ofrasys
for day-to-day operations.The
rasys
account is now an internal user account. It remains the owner of the RMAN catalog, the Recovery Appliance metadata schema, and all user-facing views. It is used during deployment, patch, and upgrade by Oracle Support. The usage ofrasys
is restricted and available only for approved tasks and for break-glass operations.Note:
"Break glass" is any time where the API's do not allow access to the data needed. This might be:- If we need to set a config parameter which is an underscore.
- If we need access to a trace file that is not accessible.
- If we need to run an internal API (dbms_ra_int.delete_backup_piece).
-
The
db_user
is a role for new named user who can perform limited operations depending on user types.-
admin
: thisdb_user
user type replaces the usage ofrasys
for configuration and day-to-day Recovery Appliance management operations. This account can manipulate the database and issue SQL Plus commands. -
vpc
: thisdb_user
user type is for Virtual Private Catalog (VPC) user activities on the Recovery Appliance. It is required to be in the wallet client side to allow access for backing up and restoring. -
monitor
: thisdb_user
user type is intended for OEM applications like Enterprise Manager and job functions that are read-only for monitoring incidents and the status of the Recovery Appliance.
-
-
The
admin_user
account is a role for new named users who manage the Recovery Appliance from an operation's perspective. It permits operating system level operations on the Recovery Appliance that previously requiredroot
access. Howeveradmin_user
is notroot
. -
The
sys
account is the super user for Oracle databases, and can change any schema in the database. Remotesys
access is now disabled and can be selectively enabled for approved tasks and for break-glass operations.
RACLI Non-Root User
Allows a non-privileged user to execute RACLI commands.
The Recovery Appliance in release 21.1 has become more secure by limiting root
access to the Recovery Appliance. It introduces the raadmin
group, whose members can execute RACLI commands and thus perform system management that previously required root
access.
This change aligns the Recovery Appliance with LDAP and Name Services Requests and improves auditing. At the same time, privileged remote access (root SSH
) is removed for better security.
Most Recovery Appliance management tasks can be performed through non-privileged access to RACLI.
Creating an admin_user
Issue the following command from the compute server by providing an appropriate system user name for <user_name>
.
racli add admin_user --user_name=<user_name>
This adds an admin user to the raadmin
group. This admin user is created if it is not found in the passwd
database. The logic prompts you to enter a user password.
-
racli list admin_user
Lists all of the users who are in the
raadmin
group and can execute RACLI commands. -
racli alter admin_user --user_name=<user_name>
Changes the password for the provided
<user_name>
. The logic prompts you to enter a user password. -
racli remove admin_user --user_name=<user_name>
Removes the provided
<user_name>
from thepasswd
database. The<user_name>
has to be a member of theraadmin
group.
Securing the Operations of the Recovery Appliance
The following steps harden the Recovery Appliance by reducing exposure to powerful users, like root
and rasys
and allowing improved auditing of maintenance actions. Although this procedure is optional for many installations and applications, establishing and using secure users is required for operations to be compliant with various regulatory mandates.
For purposes of example, the sample commands have three fictive users: bob
, sue
, and jim
.
-
Create named users and assign them
db_user
with user typeadmin
with administration rights.The
db_user
user typeadmin
replaces the usage ofrasys
for configuration and day-to-day Recovery Appliance management operations. This account can issue certain SQLPlus commands within its assigned privileges.racli add db_user --user_type=admin --user_name=bob racli add db_user --user_type=admin --user_name=sue
In this example,
bob
andsue
are given--user_type=admin
for administration rights.Note:
Thedb_user
user typeadmin
has limits of privileges, and cannot be used assysdba
in SQLPlus. -
Create
ssh
users for the Recovery Appliance.The
admin_user
account is a role for new named users who manage the Recovery Appliance from an operation's perspective. It permits operating system level operations on the Recovery Appliance that previously requiredroot
access, howeveradmin_user
is notroot
.racli add admin_user --user_name=bob racli add admin_user --user_name=jim racli add admin_user --user_name=sue
In this example,
bob
,sue
andjim
are givenadmin_user
with administration rights. -
Disable
ssh
access forroot
andoracle
.racli disable ssh
-
Disable
root
access forroot
,oracle
, andraadmin
.racli disable root_access
-
Disable
rasys
access.Note:
Make sure that you have thedb_user
user typeadmin
accounts andadmin_user
accounts before disablingrasys
access.racli disable rasys_user
-
Disable
sys
remote access.racli disable sys_remote_access
-
Validate the time service.
Refer to Changing the CHRONY Servers.
-
Validate that the Recovery Appliance is in compliance.
racli run check --check_name=check_ra_compliance
The above should return
TRUE
. Thecheck_ra_compliance
validates:-
ssh
access forroot
andoracle
is disabled on all nodes. -
rasys
access is disabled. -
sys
remote access is disabled. -
Time service is enabled.
-
Two or more
admin_users
for the Recovery Appliance have been established. -
Two or more
db_users
who areadmin
have been established.
If any of the above items are not completed,
check_ra_compliance
fails, because one or more security gaps still exist on the Recovery Appliance. -
At the completion of the above steps:
- The initial set of administrative users have been configured.
- An audit trail of actions by administrative users is now possible.
- Various commands are restricted to users with the proper permissions.
- Certain commands are restricted to quorum operations requiring approval of others to finally be run.
Quorum
This chapter describes how quorum works when compliance is in operation on the Oracle Zero Data Loss Recovery Appliance.
When compliance is in effect, certain RACLI commands are not just restricted to privileged users but also can be subject to a quorum operation that requires two approvals and no denials from the set of other privileged users. The two tests for validating quorum are:
-
Test 1:
TRUE
if there are backups under compliance, legal hold, or other keep control. -
Test 2:
TRUE
if the compliance mode has been enabled.
If Test 1 or Test 2 are TRUE
, quorum is required. If both tests are FALSE
, quorum isn't required.
The quorum scenario given below assumes:
-
bob
,sue
, andjim
aredb_user
s of the system. -
bob
andsue
are givendb_user --user_type=admin
for administration rights. -
bob
,sue
andjim
are givenadmin_user
with administration rights.
The scenario below illustrates quorum operations.
-
Administrator
bob
is working. He uses hisdb_user --user_type=admin
with hisssh_user
account. He's been adding protected database and trouble shooting incidents. -
An issue arises with the Recovery Appliance.
-
The action plan from Oracle Support/Development includes tasks that require
rasys
to run. -
User
bob
issues the RACLI command to enable therasys
login for 6 hours.racli enable rasys_user --expire=6
This returns a request identifier that is associated with the user and an increment, such as
bob.1
. -
User
bob
can monitor that status of his request.racli status request --request_id=bob.1
-
At least two users who are
admin_user
must approve the request. Userssue
andjim
use the request identifier and approve the request.(sue) racli approve request --request_id=bob.1 (jim) racli approve request --request_id=bob.1 (bob) racli status request --request_id=bob.1
If one
admin_user
denies the request, then the operation (with that request identifier) will not be processed. -
When the request is approved, user
bob
can proceed with his task of enablingrasys
, but this time with the request identifier.racli enable rasys_user --request_id=bob.1
This particular operation may prompt
bob
for the password to be used forrasys
whilerasys
is enabled. -
User
bob
performs the action plan from Oracle Support/Development, logging in asrasys
with the password specified bybob
in the command. -
User
bob
disablesrasys
.racli disable rasys_user
This returns a request identifier that is associated with the user and an increment, such as
bob.2
. -
User
bob
can monitor that status of his request.racli status request --request_id=bob.2
-
At least users who are
admin_user
must approve the request. Userssue
andjim
use the request identifier and approve the request.(sue) racli approve request --request_id=bob.2 (jim) racli approve request --request_id=bob.2 (bob) racli status request --request_id=bob.2
If one
admin_user
denies the request, then the operation (with that request identifier) will not be processed. -
When the request is approved, user
bob
can proceed with his task of disablingrasys
, but this time with the request identifier.racli disable rasys_user --request_id=bob.2
Default Password Requirements
Oracle Exadata Deployment Assistant (OEDA) implements a default password policy on Oracle Exadata Database Machine.
The last step of OEDA, "Secure Oracle Exadata Database Machine", implements the following password requirements:
- Dictionary words are not valid or accepted.
- Character classes for passwords are uppercase letters, lowercase letters, digits, and special characters.
- Passwords must contain characters from all four character classes. Passwords using only one, two, or three character classes are not allowed.
- The minimum length of a password is eight characters.
- Pass-phrases are allowed. A pass-phrase should contain at least three words, be 16 to 40 characters in length, and contain different character classes.
- A new password cannot be similar to old passwords. There must be at least eight characters in the new password that were not present in the old password.
- A maximum of three consecutive characters of the same value can be used in a password.
- A maximum of four consecutive characters of the same character class can be used in a password. For example,
abcde1#6B
cannot be used as a password because it uses five consecutive lower case letters.
Default Security Settings Implemented by OEDA
Oracle Exadata Deployment Assistant (OEDA) includes a step to implement default security settings on Recovery Appliance.
The last OEDA configuration step implements the following security settings:
-
The following password rules apply by default for all operating system users on the compute servers and storage servers:
-
Non-root users must change their password during first login.
-
The password complexity rules depend on the Oracle Linux version in use.
For systems with Oracle Linux 7 or later:
-
The minimum password length is 8 characters,
-
The password must contain at least one digit, one uppercase character, one lowercase character, and one other character.
-
The password must not contain the same character consecutively more than 3 times.
-
The password must not contain more than 4 consecutive characters from the same class (digits, lowercase letters, uppercase letters, or other characters).
-
For password changes, the new password must contain a minimum of 8 character changes.
For systems with Oracle Linux 6 or earlier, the minimum password length is 5 characters with no additional complexity requirements.
-
-
The maximum password age is 60 days.
-
The minimum amount of time between password changes is 1 day.
-
Warning alerts are generated 7 days before password expiry.
-
When changing a user password, the new password cannot match any of the 10 previous passwords.
-
-
An operating system user account is locked for 15 minutes after three failed login attempts within a 15-minute period.
-
For the
root
user, SSH equivalency is removed for all compute servers and storage servers.