4.4 Configuring Data Security for Exadata Storage Servers
Data security for Oracle Exadata Storage Servers 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 grid disks on the storage servers. The storage for each database is provided by Oracle ASM. You can have multiple clustered or unclustered databases running in your Oracle Exadata Database Machine. You can also have more than one Oracle ASM cluster. An Oracle ASM cluster is a collection of interconnected nodes, each with an Oracle ASM instance, operating as a unified cluster. An Oracle ASM cluster presents a shared pool of storage to one or more Oracle Database instances that are also operating on the nodes.
- About Exadata Storage Server Security Modes
Oracle Exadata System Software security allows open security, ASM-scoped security, or DB-scoped security. - Best Practices for ASM-Scoped Security and DB-Scoped Security
While setting up security, it is imperative that the configuration is the same across all the storage servers. - About Security Keys
Oracle Exadata System Software uses keys to identify clients and determine access rights to the grid disks. - Setting Up ASM-Scoped Security on Oracle Exadata Storage Servers
Configuring ASM-scoped security requires actions to be performed on both the database servers and storage servers. - Setting Up DB-Scoped Security on Oracle Exadata Database Machine
When configuring DB-scoped security, you perform actions on both the database and storage servers. - Changing Security Keys for ASM-Scoped Security or DB-Scoped Security
You can change the keys used with ASM-scoped security or DB-scoped security. - Enabling Cell-to-Cell Operations
If you have configured ASM-scoped security or DB-scoped security for your Oracle Exadata Database Machine, then you must configure access control to ensure direct cell-to-cell operations are not restricted. - Removing ASM-Scoped Security or DB-Scoped Security
If you want to revert to an open security model, you must remove DB-scoped security for grid disks before removing ASM-scoped security.
Parent topic: Keeping the Oracle Exadata Secure
4.4.1 About Exadata Storage Server Security Modes
Oracle Exadata System Software security allows open security, ASM-scoped security, or DB-scoped security.
Open Security
The default security mode is open security, where any database client has access to all the grid disks. Open security mode is useful for test or development databases where there are no security requirements. This is the default security mode after creating a new storage cell.
ASM-Scoped Security
Using ASM-scoped security you can restrict access to only the grid disks used by the Oracle ASM disk groups associated with a Oracle ASM cluster. All Oracle Database instances associated with that Oracle ASM cluster have access to the disk groups and underlying grid disks. Grid disks used in disk groups belonging to a different Oracle ASM cluster are not be accessible to these instances.
Use ASM-scoped security when you want all databases and Oracle ASM instances in a cluster to have access to the grid disks that comprise the Oracle ASM disk groups used by the cluster. This includes the case when there is only one database in an Oracle ASM cluster.
DB-Scoped Security
Using DB-scoped security, you can restrict access for an Oracle Database instance to a specific set of grid disks. The database instance must have access to all the grid disks used by the Oracle ASM disk groups for the database. The grid disks used by these Oracle ASM disk groups cannot be used by any other Oracle ASM disk group.
DB-scoped security mode is appropriate when multiple databases are accessing the grid disks. DB-scoped security allows you to limit database access to only the grid disks that are used by the Oracle ASM disk groups associated with the database.
![Description of sagug_031-db-scoped-security.eps follows Description of sagug_031-db-scoped-security.eps follows](img/sagug_031-db-scoped-security.png)
Description of the illustration sagug_031-db-scoped-security.eps
Parent topic: Configuring Data Security for Exadata Storage Servers
4.4.2 Best Practices for ASM-Scoped Security and DB-Scoped Security
While setting up security, it is imperative that the configuration is the same across all the storage servers.
To have consistent Oracle Exadata System Software security, ensure the following:
- Configure the same cell-side grid disk security for all grid disks that belong to the same Oracle ASM disk group to avoid confusion and errors.
- Ensure that all Oracle Real Application Clusters (Oracle RAC) servers in an Oracle ASM cluster have the same content, ownership, and security for the Oracle ASM
cellkey.ora
file. - Ensure that all Oracle RAC servers in a database 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 for any grid disks.
- Use the
dcli
utility to make configuration changes to ensure consistency and eliminate potential user errors.
Related Topics
Parent topic: Configuring Data Security for Exadata Storage Servers
4.4.3 About Security Keys
Oracle Exadata System Software uses keys to identify clients and determine access rights to the grid disks.
To determine which clients have access to a grid disk, a key is generated using CellCLI and stored in a read-only file that is accessible only by the clients. The CellCLI CREATE KEY
command generates a random hexadecimal string for use as a security key. This key is stored in a cellkey.ora
file on the client side, and assigned to the targets on the storage servers using the ASSIGN KEY
command.
Note:
The client name or Oracle ASM cluster name not case-sensitive. For example,ASM1
and asm1
are treated as the same value.
The CREATE KEY
command can be run on any cell. You should only run this command when you need to create a new unique key. If you are configuring ASM-scoped security, then only a single security key is needed for each Oracle ASM cluster. If you are configuring DB-scoped security, then one key is needed for each Oracle ASM cluster and an additional security key is needed for each database client.
For ASM-scoped security, the cellkey.ora
file is only accessible by the Oracle ASM cluster and its database clients. For DB-scoped security multiple security keys are used. One key is assigned to the Oracle ASM cluster, and one key is assigned to each database client. These security keys are stored in separate cellkey.ora
files, and each file is accessible only by the client.
The cellkey.ora
file contains entries that configure security among Oracle ASM, database clients and cells. The key
and asm
values in the cellkey.ora
files on the Oracle ASM and database host computers must match the values assigned to the clients on the cells.
The cellkey.ora
file contains the following fields:
-
key
— This field is required.-
For ASM-scoped security, this key must match the value of the key assigned to the Oracle ASM cluster with the CellCLI
ASSIGN KEY
command. -
For DB-scoped security, this key must match the value of the key assigned to the database client with the CellCLI
ASSIGN KEY
command.
-
-
asm
— This field is required.This field contains a unique identifier for each Oracle ASM cluster. This value must be unique among all the clusters that access the storage servers in the storage grid. This value is used in the
ASSIGN KEY
command run on each cell, and theALTER GRIDDISK
andCREATE GRIDDISK
commands used to configure grid disks to allow access from only a specific Oracle ASM cluster.Note:
Theasm
field is used when configuring both ASM-scoped security and DB-scoped security.
Access to the cellkey.ora
file is controlled by operating system privileges.
-
For Oracle ASM clients, the file is stored in the
/etc/oracle/cell/network-config
directory, and is readable by the Oracle Grid Infrastructure software owner and the group to which the user belongs. -
For DB-scoped security, there is a
cellkey.ora
for Oracle ASM, readable only by the Oracle Grid Infrastructure software owner, and additionalcellkey.ora
files for each database client. For the database clients, the file is stored in thepfile
directory of the Oracle home directory for each database. Thecellkey.ora
file for a database is readable only by the operating system user that owns the Oracle Database software installation.Note:
The Oracle Grid Infrastructure and Oracle Database software must by owned by different operating system users to implement DB-scoped security.
Figure 4-2 Security Keys and cellkey.ora Files
![Description of Figure 4-2 follows Description of Figure 4-2 follows](img/sagug_032-cellkey-file.png)
Description of "Figure 4-2 Security Keys and cellkey.ora Files"
On the storage servers, you use the ASSIGN KEY
command to store the security keys in an access control list (ACL) for the cells. You use the ALTER GRIDDISK
command to set the access rights for individual grid disks with the AvailableTo
attribute. In order to access a grid disk, the security key of the cell ACL must match the security key of the client and the unique name of the client must be included in the AvailableTo
attribute of the grid disk.
The identifying names used for the Oracle ASM and database must be unique. However, in some environments, there is more than one database with the same value for the DB_UNIQUE_ID
. Each database uses a different Oracle ASM cluster for storage. Starting with Oracle Exadata System Software release 12.2.1.1.0, you can define ASM-scoped security based on Oracle ASM clusters. You use the ASMCLUSTER
keyword with the ASSIGN KEY
command. When you use the ASMCLUSTER
keyword, the database name is qualified by the Oracle ASM unique identifier, creating a unique ID for each database, even if they have the same DB_UNIQUE_ID
. Within each Oracle ASM cluster, the database names still have to be unique.
If you configure ASM-scoped security or DB-scoped security, then you also need to configure security keys to enable cell-to-cell operations. You create a key for each storage server, or cell, and assign that key as a local key for the cell using the ASSIGN KEY FOR LOCAL CELL
command. You then assign the keys for the other cells that perform cell-to-cell operations with the current cell using the ASSIGN KEY FOR REMOTE CELL
command.
Example 4-5 Creating a Security Key for Exadata Storage Security
Use the following command on any storage server to generate a unique security key. This key will be used to configure ASM-scoped security or DB-scoped security.
CellCLI> CREATE KEY
66e12adb996805358bf82258587f5050
Example 4-6 cellkey.ora File Entries
This example shows the entries for the cellkey.ora
file.
key=66e12adb996805358bf82258587f5050
asm=cluster1
Related Topics
Parent topic: Configuring Data Security for Exadata Storage Servers
4.4.4 Setting Up ASM-Scoped Security on Oracle Exadata Storage Servers
Configuring ASM-scoped security requires actions to be performed on both the database servers and storage servers.
grid
.
Related Topics
Parent topic: Configuring Data Security for Exadata Storage Servers
4.4.5 Setting Up DB-Scoped Security on Oracle Exadata Database Machine
When configuring DB-scoped security, you perform actions on both the database and storage servers.
These steps are for configuring DB-scoped security for a single Oracle ASM cluster and the databases that are clients of that Oracle ASM cluster. The examples in these steps assume that the Oracle ASM software owner is the user grid
and each Oracle Database home is owned by a different operating system user.
- The combination of the Oracle Database client unique name and the Oracle ASM Cluster used by the database client must be unique in your environment.
- The Oracle Grid Infrastructure software installation and each Oracle Database software installation must be owned by different operating system users.
- Each database client must have distinct Oracle ASM disk groups. The grid disks used by Oracle ASM disk groups can only be assigned to one Oracle ASM disk group.
Related Topics
Parent topic: Configuring Data Security for Exadata Storage Servers
4.4.6 Changing Security Keys for ASM-Scoped Security or DB-Scoped Security
You can change the keys used with ASM-scoped security or DB-scoped security.
- Upgrading ASM-Scoped Security Key for ASMCLUSTER
Starting with Oracle Exadata System Software release 12.2.1.1.0, you can define ASM-scoped security based on Oracle ASM clusters. - Changing the Assigned Key Value for ASM-Scoped Security
You can change the key value used for an Oracle ASM client configured to use ASM-scoped security. - Changing the Assigned Key Value for DB-Scoped Security
You can change the key value used by an Oracle Database client configured to use DB-scoped security.
Parent topic: Configuring Data Security for Exadata Storage Servers
4.4.6.1 Upgrading ASM-Scoped Security Key for ASMCLUSTER
Starting with Oracle Exadata System Software release 12.2.1.1.0, you can define ASM-scoped security based on Oracle ASM clusters.
The identifying names used for the Oracle ASM and database instances must be unique. However, in some environments, there is more than one database with the same value for the DB_UNIQUE_ID
. If each database uses a different Oracle ASM cluster for storage, then you can use the ASMCLUSTER
keyword when assigning the security key to specify that access should be limited to the specified Oracle ASM cluster.
When you use the ASMCLUSTER
keyword, the database name is qualified by the Oracle ASM unique identifier, creating a unique ID for each database, even if they have the same DB_UNIQUE_ID
. Within each Oracle ASM cluster, the database names still have to be unique.
Note:
Do not use theASMCLUSTER
keyword when assigning keys if you are using DB-scoped security. Only use the ASMCLUSTER
keyword for ASM-scoped security.
If you have ASM-scoped security configured, but want to change the keys to be ASMCLUSTER
keys, perform the following steps:
4.4.6.2 Changing the Assigned Key Value for ASM-Scoped Security
You can change the key value used for an Oracle ASM client configured to use ASM-scoped security.
Related Topics
4.4.7 Enabling Cell-to-Cell Operations
If you have configured ASM-scoped security or DB-scoped security for your Oracle Exadata Database Machine, then you must configure access control to ensure direct cell-to-cell operations are not restricted.
To ensure cells have access to other cells when they need to communicate directly with one another, for example for offload operations, you need to set up cell keys for each cell.
- Configuring Simple Cell Access
You can use a single key for both inbound and outbound cell-to-cell traffic. - Configuring LOCAL and REMOTE Cell Keys
You can configure each cell to have a unique key and to accept multiple remote cell keys for granting access. - Changing Between Simple Cell Keys and LOCAL and REMOTE Keys
You must remove the existing cell keys before assigning any new keys with a different format. This protects you from inadvertently breaking your configuration by having different remote and local keys on the storage servers.
Parent topic: Configuring Data Security for Exadata Storage Servers
4.4.7.1 Configuring Simple Cell Access
You can use a single key for both inbound and outbound cell-to-cell traffic.
To ensure cells have access to other cells when they need to communicate directly with one another, for offload operations for example, you can create a single key. Assign that key to all cells using the simple version of the ASSIGN KEY
command.
It is not necessary to use the ALTER GRIDDISK
command to update the availableTo
attribute for the cell key. The cells use the existing access control policy by making sure the originating client is identified at the remote target cell.
Parent topic: Enabling Cell-to-Cell Operations
4.4.7.2 Configuring LOCAL and REMOTE Cell Keys
You can configure each cell to have a unique key and to accept multiple remote cell keys for granting access.
To ensure cells have access to other cells when they need to communicate directly with one another, for offload operations for example, you create cell keys. You can create a single key used by all cells, or you can assign a unique key to individual cells using the LOCAL
and REMOTE
keywords.
You might want to use multiple cell keys temporarily during rekeying, or if you want to limit access to specific cells. In this case, you need to specify LOCAL
or REMOTE
in the ASSIGN KEY
command.
Parent topic: Enabling Cell-to-Cell Operations
4.4.7.3 Changing Between Simple Cell Keys and LOCAL and REMOTE Keys
You must remove the existing cell keys before assigning any new keys with a different format. This protects you from inadvertently breaking your configuration by having different remote and local keys on the storage servers.
If you attempt to assign a LOCAL
or REMOTE
key to an existing cell key (that is, you have run the simple ASSIGN KEY FOR CELL
command, and you want to switch to the explicit LOCAL
or REMOTE
keys), you will get the following error:
CELL-02911: Remove existing CELL key before assigning LOCAL CELL key
Similarly, if you attempt run ASSIGN KEY FOR CELL
when local or remote cell keys already exist, you will get the following error:
CELL-02912: Remove all existing LOCAL and REMOTE CELL keys before assigning a CELL key.
Use LIST KEY FOR CELL to show all LOCAL and REMOTE CELL keys, then use ASSIGN KEY to assign an
empty value to each.
You must remove all existing LOCAL
and REMOTE
cell keys before assigning a simple cell key.
- View the configured keys on each storage server.
- Remove the existing cell keys.
- Recreate the keys in the desired format.
- To change simple cell keys to local and remote keys, follow the steps in Configuring LOCAL and REMOTE Cell Keys
- To change local and remote cell keys to a simple cell key, follow the steps in Configuring Simple Cell Access.
Parent topic: Enabling Cell-to-Cell Operations
4.4.8 Removing ASM-Scoped Security or DB-Scoped Security
If you want to revert to an open security model, you must remove DB-scoped security for grid disks before removing ASM-scoped security.
Before making updates to the security on cells, you must shut down the Oracle Database and Oracle ASM instances. After all of the changes to security configuration are complete, start the Oracle Database and Oracle ASM instances.
- Removing DB-Scoped Security
- Removing ASM-Scoped Security
After you have removed DB-scoped security, you can remove ASM-scoped security if you want open security for the grid disks on the storage servers.
Parent topic: Configuring Data Security for Exadata Storage Servers
4.4.8.1 Removing DB-Scoped Security
To remove DB-scoped security on grid disks, perform the following procedure:
Example 4-7 Removing Database Clients from Grid Disks
The following command removes all database clients from a group of grid disks:
CellCLI> ALTER GRIDDISK DATA1_CD_00_cell01, DATA1_CD_01_cell01, -
DATA1_CD_02_cell01, RECO1_CD_00_cell01, RECO1_CD_01_cell01, -
RECO1_CD_02_cell01 -
availableTo='asm1'
If there are multiple database clients configured for DB-scoped security, for example db1
, db2
, and db3
, and you only want to remove security for one client (db1
), you can use a command similar to the following for a group of grid disks:
CellCLI> ALTER GRIDDISK sales_CD_04_cell01, sales_CD_05_cell01, -
sales_CD_06_cell01, sales_CD_07_cell01, sales_CD_08_cell01, -
sales_CD_09_cell01, -
availableTo='+asm,db2,db3'
The following example removes all database clients from all grid disks:
ALTER GRIDDISK ALL availableTo='+asm'
Note:
If you want open security for the grid disks and storage servers, then you must remove ASM-scoped security after removing DB-scoped security.Related Topics
Parent topic: Removing ASM-Scoped Security or DB-Scoped Security
4.4.8.2 Removing ASM-Scoped Security
After you have removed DB-scoped security, you can remove ASM-scoped security if you want open security for the grid disks on the storage servers.
Example 4-8 Removing the Oracle ASM Client from Grid Disks
The following command removes the Oracle ASM client from all grid disks on a cell:
CellCLI> ALTER GRIDDISK ALL availableTo=''
The following command removes the Oracle ASM client from all grid disks on a group of cells:
dcli -g cell_group -l celladmin "cellcli -e \"ALTER GRIDDISK ALL availableTo=''\""
The following command removes the Oracle ASM client from a group of grid disks on a cell:
CellCLI> ALTER GRIDDISK sales_CD_01_cell01, sales_CD_02_cell01, -
sales_CD_03_cell01, sales_CD_04_cell01, sales_CD_05_cell01, -
sales_CD_06_cell01
availableTo=''
Related Topics
Parent topic: Removing ASM-Scoped Security or DB-Scoped Security