4 Configuring Security for Oracle Exadata System Software
This chapter explains how to configure security for Oracle Exadata System Software.
This chapter contains the following topics:
4.1 Understanding Operating System Security of Oracle Exadata Storage Servers
The security of the operating system on Oracle Exadata Storage Servers consists of the following:
-
Enforcing security policies
-
Protecting network access paths to the cells
-
Monitoring operating system-level activities
Oracle Exadata System Software includes security features to ensure the operating system and network access to the Oracle Exadata Storage Servers are secure.
4.1.1 Security Policies for Oracle Exadata Storage Servers
User access to the operating system can be secured by the use of secure, hardened passwords.
The passwords for operating system users who administer Oracle Exadata System Software adhere to the security guidelines enacted by Oracle Exadata Deployment Assistant (OEDA). See Default Security Setting Enacted by OEDA for more information.
4.1.1.1 Changing a Password
Users are notified of the need to change their passwords 7 days before the expiration date. To change a password, use the following command:
passwd username
In the preceding command, username is the user name. The following is an example of the command:
passwd celladmin
4.1.1.2 Enabling the Security Policies
The /opt/oracle.cellos/RESECURED_NODE
file enables the security policies.
If the file does not exist, then you can reset the security policies for all operating system users by performing the following steps:
4.1.1.3 Viewing Failed Password Attempts
Use the pam_tally2
operating system utility to view login attempts with incorrect passwords.
View failed password attempts using the /sbin/pam_tally2
utility.
# /sbin/pam_tally2
Login Failures Latest failure From
celladmin 1 09/18/18 11:17:18 dhcp-10-154-xxx-xxx.example.com
4.1.1.4 Resetting a Locked User Account
If a user account has 5 failed login attempts, then the account is locked.
To reset an account, use the following command:
/sbin/pam_tally2 --user username --reset
In the preceding command, username is the name of the user that has the locked account.
4.1.2 Network Access to Oracle Exadata Storage Servers
Oracle Exadata System Software includes the cellwall service that implements a firewall on each cell. The service is located in the /etc/init.d/cellwall
directory, and implements iptables firewall on the cell. In addition, the SSH server is configured to respond to connection requests only on the management network (NET0), and the InfiniBand network (BONDIB0).
To review the firewall rules, run the following command as the root
user:
iptables --list
Note:
There is no firewall automatically configured for the database servers. Implement a set of iptables on the database servers to meet your network requirements for Oracle Exadata Database Machine.
4.1.3 Operating System Activity Monitoring on Oracle Exadata Storage Servers
Each Oracle Exadata Storage Server is configured with auditd
to audit system-level activity.
To manage audits and generate reports use the auditctl
command. The audit rules are in the /etc/audit/audit.rules
file. Any changes are not preserved when applying a patch set.
Starting with Oracle Exadata System Software release 19.1.0 and Oracle Linux 7, the audit rules specific to Oracle Exadata Database Machine are stored in the /etc/audit/rules.d/01-exadata_audit.rules
file.
When the auditd
service starts, it runs the augenrules
utility. This utility merges all component audit rules files found in the audit rules directory, /etc/audit/rules.d
, and places the merged results in the /etc/audit/audit.rules
file. Component audit rule files, must end in .rules
to be processed by augenrules
. All other files in the /etc/audit/rules.d
directory are ignored. The files are concatenated in order, based on their natural sort order and stripped of empty lines and comment (#) lines. Auditing rules not specific to Oracle Exadata Database Machine should be placed in a separate audit rules file in the /etc/audit/rules.d
directory, such as /etc/audit/rules.d/20-customer_audit.rules
.
As in previous releases of Oracle Exadata System Software, the audit rules are immutable. A reboot is needed to effect changes to audit rules.
4.2 Creating Exadata Software Users and Roles
You can control which Oracle Exadata System Software commands users can run by granting privileges to roles, and granting roles to users.
For example, you can specify that a user can run the LIST GRIDDISK
command but not ALTER GRIDDISK
. This level of control is useful in Cloud environments, where you might want to allow full access to the system to only a few users.
Oracle Exadata System Software users are required when running ExaCLI in on-premise or Oracle Cloud environments. ExaCLI enables you to manage cells remotely from compute nodes. When you run ExaCLI on a compute node, you need to specify a user name to use to connect to the cell node. The Management Server (MS) authenticates the user credentials, then performs authorization checks on the commands issued by the user. If the user does not have the proper privileges to run a command, MS returns an error.
The password security key is encrypted using Password-Based Key Derivation Function 2 (PBKDF2) with HMAC-SHA1.
To set up users and roles, you would perform these steps:
- Create roles using the CREATE ROLE command.
- Grant privileges to roles using the GRANT PRIVILEGE command.
- Create users using the CREATE USER command.
- Grant roles to users using the GRANT ROLE command.
You can also revoke privileges from roles using the REVOKE PRIVILEGE command. To revoke roles from users, use the REVOKE ROLE command.
Related Topics
4.2.1 Creating Roles and Getting Information about Roles
Use the CREATE ROLE
command to create roles for Oracle Exadata System Software users.
For example, to create a ADMIN role, you would use the following command:
CellCLI> CREATE ROLE admin
To get detailed information about a role, use the LIST ROLE
command. The following command returns all the attributes for the admin
role.
CellCLI> LIST ROLE admin ALL DETAIL
Related Topics
4.2.2 Granting and Revoking Privileges
Use the GRANT PRIVILEGE
command to grant privileges to roles for Oracle Exadata System Software users.
Related Topics
4.2.3 Creating Users
Use the CREATE USER
command to create Oracle Exadata System Software users.
A newly created user does not have any privileges. The Oracle Exadata System Softwareuser is granted privileges through roles granted to the user.
Related Topics
4.2.4 Configuring Password Expiration for Users Accessing the Server Remotely
You can configure CELL
attributes to expire user passwords.
In Oracle Exadata System Software release 19.1.0, there are new CELL
attributes for configuring password security for users that access Oracle Exadata System Software servers remotely, such as with REST API or ExaCLI. These attributes determine if the user is able to change the password remotely, the amount of time before a user password expires, and the number of days prior to password expiration that the user receives warning messages. In the default configuration, user passwords do not expire.
Note:
The CELL attributes for password expiration apply only to users created with Oracle Exadata System Software. Password expiration applies only to users that are displayed with theLIST USER
command and does not apply to operating system users like celladmin
or oracle
.
4.2.5 Granting and Revoking Roles
Use the GRANT ROLE
command to create roles to Oracle Exadata System Software users.
Related Topics
4.3 Disabling SSH on Storage Servers
By default, SSH is enabled on storage servers. If required, you can "lock" the storage servers to block SSH access. You can still perform operations on the cell using exacli, which runs on compute nodes and communicates using https and REST APIs to a web service running on the cell.
When you need to perform operations that require you to log in to the cell, you can temporarily unlock the cell. After the operation is complete, you can relock the cell.
Two new cell attributes control cell locking:
-
accessLevelPerm
: This attribute specifies the access level at which the cell runs by default. It is eitherremoteLoginEnabled
orremoteLoginDisabled
.-
remoteLoginEnabled
: SSH service is enabled. You can access the cell using ssh or exacli. This is the default value foraccessLevelPerm
. -
remoteLoginDisabled
: SSH service is disabled. You can access the cell only through exacli.
-
-
accessLevelTemp
: The access level can be changed temporarily for a specified duration. Once the duration has expired, the access level reverts back to the accessLevelPerm value. You typically change the cell's access level when the cell needs a software update.
The access level persists across cell reboots.
4.3.1 Locking a Cell
You lock a cell by setting its accessLevelPerm
attribute to remoteLoginDisabled
.
You must use a user that has the privilege to alter the accessLevelPerm
attribute.
4.3.2 Unlocking a Cell Temporarily
You can unlock a locked cell for a short period of time to perform operations such as maintenance or upgrades that require SSH login to the cell. You can specify the start time of this "temporary access window" and how long it should last by setting the cell's accessLevelTemp
attribute. This attribute has the following properties:
Table 4-1 Properties of accessLevelTemp
Property | Description |
---|---|
|
Specifies whether SSH is enabled ( This value needs to be specified. There is no default value. |
|
Specifies when the specified access level starts. The time is specified in the ISO 8601 format: "yyyy-MM-ddTHH:mm:ssZ". You can also specify the keyword " Default value: |
|
Specifies how long the access level should last. The duration is specified in the following format: [any number of digits, followed by [any number of digits followed by [any number of digits followed by Examples: To specify 1 hour: To specify 90 minutes: To specify 1 day: To specify 1 day and 12 hours: Default value: |
|
Specifies a reason for changing the access level, for example: performing an upgrade. Default value: "none" |
Examples:
1. The following example creates a two-hour temporary access window that will begin on June 20, 2015, at 1:01 AM.
exacli> alter cell accessLevelTemp=((accessLevel="remoteLoginEnabled", - startTime="2015-06-20T01:01:00-07:00", - duration="2h", - reason="Quarterly maintenance"))
2. The following example creates a two-hour temporary access window that starts immediately. The command uses the default values for start time and duration.
exacli> alter cell accessLevelTemp=((accessLevel="remoteLoginEnabled", - reason="Quarterly maintenance"))
3. The following example creates a 30-minute temporary access window that starts immediately
exacli> alter cell accessLevelTemp=((accessLevel="remoteLoginEnabled", - startTime="now", - duration="30m", - reason="Quarterly maintenance"))
4. The following example creates a two-hour temporary access window that will begin on June 20, 2015, at 1:01 AM. The command uses the default duration value.
exacli> alter cell accessLevelTemp=((accessLevel="remoteLoginEnabled", - startTime="2015-06-20T01:01:00-07:00", - reason="Quarterly maintenance"))
5. The following example extends the temporary access window created in example 4 above to 5 hours. Note that the start time has to match the window that is being adjusted.
exacli> alter cell accessLevelTemp=((accessLevel="remoteLoginEnabled", - startTime="2015-06-20T01:01:00-07:00", - duration="5h", - reason="Quarterly maintenance window extended to 5 hrs - Joe"))
6. The following example deletes the temporary access window. If the temporary access window is currently active, it is closed immediately and the access level will be set back to the permanent access level. If the temporary access window is in the future and not yet active, it is cancelled.
exacli> alter cell accessLevelTemp=''
Note the following:
-
Only one temporary access window is allowed at any time. You will get an error message if you try to create a new temporary access window when one is already in effect.
If the temporary access window is not yet active and is in the future, the newly created temporary access window will replace the one that is in the future.
-
To modify a temporary access window that is in the future and not yet active, simply run the "alter cell" command again with the new values.
-
To modify a temporary access window that is already in progress (for example, to extend the duration or to change the reason), run the "alter cell" command again with the updated duration and/or reason. The command must provide the exact start time of the existing temporary access window to modify. The (start time + duration) must be in the future.
4.3.3 Checking the Current Access Level
To see what the current access level is, run the following command:
exacli> list cell detail
Look at the values for the accessLevelPerm
and accessLevelTemp
attributes.
You can also run the following commands:
exacli> list cell attributes accessLevelPerm exacli> list cell attributes accessLevelTemp
4.3.4 Alerts from the Management Server
A stateless alert is generated when the accessLevelPerm
attribute is modified.
A stateful alert is generated when the accessLevelTemp
window is created. An alert email is sent out when the accessLevelTemp
window is activated. The alert is cleared when the window expires.
4.4 Configuring Data Security for Oracle Exadata Storage Servers
Oracle Exadata System Software data security is implemented by controlling which Oracle Automatic Storage Management (Oracle ASM) clusters and Oracle Database clients can access specific grid disks on storage cells. By default, all Oracle Database and Oracle ASM instances have access to all storage cell grid disks.
-
To set up security so that all database clients of an Oracle ASM cluster have access to specific grid disks, configure ASM-scoped security.
-
To set up security so that specific database clients of an Oracle ASM cluster have access to specific grid disks, configure DB-scoped security.
To have consistent security, ensure the following:
-
All grid disks that belong to the same Oracle ASM disk group have the same cell-side grid disk security defined to avoid confusion and errors.
-
All Oracle Real Application Clusters (Oracle RAC) servers in an Oracle ASM cluster have the same content, ownership, and security for theOracle ASM
cellkey.ora
file. -
All database servers in an Oracle RAC cluster have the same content, ownership, and security for the database
cellkey.ora
file. -
If DB-scoped security is implemented, then ensure it is implemented for all databases accessing the grid disks.
-
Do not mix ASM-scoped security and DB-scoped security.
While setting up security, it is imperative that the configuration is the same across cells. Using the dcli
utility to make configuration changes ensures consistency by eliminating the potential of user errors.
For more information, see Configuring Data Security for Exadata Storage Servers in the Oracle Exadata Database Machine Security Guide.