Exadata: Implementing Cell Security

Security for Exadata Cell is enforced by identifying which clients can access cells and grid disks. Clients include Oracle ASM instances, database instances, and clusters. By default Exadata allows all ASM clusters and databases in the system access to all grid disks. You can implement cell security control access to grid disks at two levels, by ASM cluster and by database


Implement ASM-Scoped Security:
With ASM-scoped security, the ASM cluster is authenticated to the storage cell by its DB_UNIQUE_NAME and a security key.

1- Shut down all databases and ASM instances in the ASM cluster.

2- Create security key using cellcli utility. Use create key command only once on any of your cell. We will assign the created key to ASM cluster later.

Remember this key not stored anywhere automatically.

3- create the cellkey.ora on the location (/etc/oracle/cell/network-config) of each DB server on which ASM cluster is configured. Set the ownership of the file to the user and group specified during the ASM (grid) installation.

Note: you can change the realm as below:
CellCLI> alter cell realmName=exainam_realm
4- Assign the security key to ASM cluster being configured by running assign command on each cell for which you want to have the access from ASM cluster.

5- Change the grid disk "availableTo" attribute

6- Restart the DB and ASM instances

Implement Database-Scoped Security
This security implementation locks down database access to specific grid disks with in an ASM cluster and useful for controlling access to grid disks when multiple databases share the same ASM cluster. You will use one cellkey.ora per database.

1- Shutdown all DB and ASM instances
2- Create the key for each database in ASM cluster only once and assign to database later
3- For each database create cellkey.ora (same contents as in ASM-scoped above) file using newly key created in step 2 on the location ORAHOME/admin/db_unique_name/pfile. Change ownership also.
4- Retrieve DB_UNIQUE_NAME for database being configured and assign security key. Then change the grid disk attribute "availableTo"

Removing  Security:
1- Shutdown ASM and DB instances
2- List the attribute assigned

3- Remove the databases from the availableTo attribute of grid disks
CellCLI> alter griddisk griddiskName availableTo='+ASM'
4- Security key may be removed from ACL on storage as follows
CellCLI> assign key for exadb=''
Key for exadb successfully dropped
5- remove the cellkey.ora from ORAHOME/admin/db_unique_name/pfile
6- verify exadb is not assigned any grid disks

7- Once the DB-scoped security is removed, you can remove the ASM-scoped security returning the system to open security mode. Remove the ASM unique name from the availableTo attribute of all grid disks.
CellCLI> alter griddisk all availableTo=''
CellCLI> alter griddisk griddiskName availableTo=''
CellCLI> assign key for +ASM=''  -- removing assigned key

8- Remove the cellkey.ora file now from /etc/oracle/cell/network-config

Related Posts:

Exadata: Monitoring Performance (Using Metrics)

Exadata: Monitoring Active Requests, Alerts and Wait Events
Exadata: Replacing damaged disk is really plugNplay activity
Exadata: Get Cell statistics quickly
Exadata: What differentiates GI on Exadata with GI on non-Exadata?
Exadata: Understanding key OS Processes for a cell
Exadata: Health Checking Exadata
Exadata: Diagnostics using sundiag/deaddisk
Exadata: Knowing a bit Exadata administrative utilities