Oracle Exadata System Software security allows open security, ASM-scoped security, or DB-scoped security.

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.

Figure 4-1 ASM-Scoped Security

Description of "Figure 4-1 ASM-Scoped Security"

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 the illustration sagug_031-db-scoped-security.eps

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.

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.

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 the ALTER GRIDDISK and CREATE GRIDDISK commands used to configure grid disks to allow access from only a specific Oracle ASM cluster.

  Note:

  The asm 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 additional cellkey.ora files for each database client. For the database clients, the file is stored in the pfile directory of the Oracle home directory for each database. The cellkey.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 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.

CellCLI> CREATE KEY
         66e12adb996805358bf82258587f5050

key=66e12adb996805358bf82258587f5050
asm=cluster1

Configuring ASM-scoped security requires actions to be performed on both the database servers and storage servers.

1. Shut down the Oracle Database and Oracle ASM instances.
2. On one of the storage servers, use the CellCLI CREATE KEY command to generate a random hexadecimal string. The command can be run on any storage server.

   CellCLI> CREATE KEY
   
   66e12adb996805358bf82258587f5050
   

3. Copy the key to the cellkey.ora file on one of the database servers.
   1. Create a cellkey.ora in the home directory of the software owner, for example, /home/grid/cellkey.ora.
   2. Using the format shown below, where cluster1 is an alias for the Oracle ASM cluster, add the key to the cellkey.ora file.

      The alias must be unique among all the clusters that access the storage servers. The Oracle Clusterware cluster name can be used if the clusters have unique names.

      key=66e12adb996805358bf82258587f5050
      asm=cluster1

4. Use the ASSIGN KEY command to assign the security key to the Oracle ASM cluster client on all the storage servers that you want the Oracle ASM cluster to access, for example:

   CellCLI> ASSIGN KEY FOR ASMCLUSTER 'cluster1'='66e12adb996805358bf82258587f5050'

   The above command must be repeated on all storage servers that you want the Oracle ASM cluster to access, or you can use a dcli command, as shown here:

   dcli -g cell_group -l celladmin "cellcli -e \"ASSIGN KEY FOR ASMCLUSTER 'cluster1'=
   '66e12adb996805358bf82258587f5050'\""

5. Configure security on the grid disks on all the storage servers that you want the Oracle ASM cluster to access.
   You can configure the security key either when creating grid disks, or with the ALTER GRIDDISK command.

   • To create new grid disks with security configured, use a command similar to the following where cluster1 is the unique name for the Oracle ASM client:

     CellCLI> CREATE GRIDDISK ALL PREFIX=sales, size=75G, -
              availableTo='cluster1'
     

   • To change security on existing grid disks, use a command similar to the following on every storage server. In the following example, cluster1 is the unique name for the Oracle ASM client. The grid disks specified in this command must include all the grid disks used by the Oracle ASM disk groups.

     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='cluster1'
     

   In the preceding commands, the alias used, for example, cluster1, is a unique and consistent value on all the storage servers and among all the clusters. When you specify a value for availableTo, then only the clients configured with the same alias in the cellkey.ora file have access to the grid disks.

6. Verify the key assignment on the storage servers.

   CellCLI> LIST KEY

   CellCLI> LIST GRIDDISK ATTRIBUTES name,availableTo

7. Copy the cellkey.ora file created in Step 3 to the /etc/oracle/cell/network-config directory on each database server.

   In the following command, dbs_group is a file that contains the names of the database servers that are clients of the Oracle ASM cluster.

   dcli -g dbs_group -l grid -f /home/grid/cellkey.ora -d /etc/oracle/cell/
   network-config/cellkey.ora

8. On each database server, configure the permissions for the cellkey.ora.

   • If you use role-separated management for all Oracle software, then set the permissions on the file to be read-only by the owner and the group. Change the group ownership for the file to the oinstall group that contains the installation users for both Oracle Grid Infrastructure (grid) and Oracle Database (oracle).

     You can use dcli to configure the file on multiple servers with a single command.

     dcli -g dbs_group -l root chown grid:oinstall /etc/oracle/cell/
     network-config/cellkey.ora 
     
     dcli -g dbs_group -l grid chmod 440 /etc/oracle/cell/network-config/cellkey.ora

   • If you use a single installation user for all Oracle software, then set the permissions on the file to be read-only by the software owner (for example, oracle).

     chown oracle:oinstall /etc/oracle/cell/network-config/cellkey.ora
     chmod 400 /etc/oracle/cell/network-config/cellkey.ora

9. On the database servers, restart Oracle Clusterware, the Oracle ASM instances, and the Oracle Database instances.

   The commands to stop and start Oracle Clusterware are:

   # crsctl stop crs
   # crsctl start crs

   Then restart the Oracle ASM and Oracle Database instances if they are not started automatically.

10. Remove the temporary cellkey.ora file created in Step 3.

When configuring DB-scoped security, you perform actions on both the database and storage servers.

1. Get the DB_UNIQUE_NAME for each database. Names are case-sensitive.

   SQL> SELECT db_unique_name FROM V$DATABASE;

2. Shut down the databases and Oracle ASM instances for the Oracle ASM cluster.
3. On one of the storage servers, use the CellCLI CREATE KEY command to generate a key for Oracle ASM and a key for each Oracle Database client.

   The command can be run on any storage server.

   CellCLI> CREATE KEY
           66e12adb996805358bf82258587f5050
   
   CellCLI> CREATE KEY
           f3f21c625ff41ef479a1bb033e0839e5
   
   CellCLI> CREATE KEY
           cf03b74de32a67a6c1ec87b9da72bd47
   

4. Copy the key for Oracle ASM to the cellkey.ora file on one of the database servers.
   1. Create a cellkey.ora in the home directory of the Oracle Grid Infrastructure software owner, for example, /home/grid/cellkey.ora.
   2. Using the format shown below, where asm1 is an alias for the Oracle ASM cluster, add the key to the cellkey.ora file.

      The alias must be unique among all the clusters that access the storage servers. The Oracle Clusterware cluster name can be used if the clusters have unique names.

      key=66e12adb996805358bf82258587f5050
      asm=asm1

5. Copy the key for each Oracle Database client to a cellkey.ora file in the user directory of the Oracle home software owner on one of the database servers.
   1. Create a cellkey.ora in the home directory of each Oracle Database software owner, for example, /home/db1user/cellkey.ora and /home/db2user/cellkey.ora.
   2. Add the security key for each database client to the cellkey.ora file.

      Using the format shown here, where asm1 is an alias for the Oracle ASM cluster used by the database client. In this example, each database client uses the same Oracle ASM cluster.

      $ cat /home/db1user/cellkey.ora
      key=f3f21c625ff41ef479a1bb033e0839e5
      asm=asm1
      $ cat /home/db2user/cellkey.ora
      key=cf03b74de32a67a6c1ec87b9da72bd47
      asm=asm1

   Note:

   The asm field is used for both ASM-scoped security and DB-scoped security.
6. Use the ASSIGN KEY command to assign the security key for the Oracle ASM client on all the storage servers that you want the Oracle ASM cluster to access, for example:

   CellCLI> ASSIGN KEY FOR 'asm1'='66e12adb996805358bf82258587f5050'

   The above command must be repeated on all storage servers, or you can use a dcli command, as shown here:

   dcli -g cell_group -l root "cellcli -e \"ASSIGN KEY FOR 'asm1'=
   '66e12adb996805358bf82258587f5050'\""

7. Use the ASSIGN KEY command to assign the security key for each Oracle Database client on all the storage servers that contain grid disks used by the Oracle ASM disk groups of that database, for example:

   CellCLI> ASSIGN KEY FOR 'db1'='f3f21c625ff41ef479a1bb033e0839e5'
   
   CellCLI> ASSIGN KEY FOR 'db2'='cf03b74de32a67a6c1ec87b9da72bd47'

   The above command must be repeated on all storage servers, or you can use a dcli command, as shown here, where cell_group_db1 contains a list of the storage servers used by the first database and cell_group_db2 contains the list of storage servers used by the second database:

   dcli -g cell_group_db1 -l root "cellcli -e \"ASSIGN KEY FOR 'db1'=
   'f3f21c625ff41ef479a1bb033e0839e5'\""
   
   dcli -g cell_group_db2 -l root "cellcli -e \"ASSIGN KEY FOR 'db2'=
   'cf03b74de32a67a6c1ec87b9da72bd47'\""

8. Configure security on the grid disks on all the storage servers that you want the database clients to access.
   You can configure the security key either when creating grid disks, or with the ALTER GRIDDISK command.

   • To create new grid disks with security configured, use a command similar to the following where asm1 is the unique name for the Oracle ASM client, and db1 and db2 are the unique names for the database clients:

     CellCLI> CREATE GRIDDISK data1_CD_00_cell01,data1_CD_01_cell01, -
     data1_CD_02_cell01 size=75G, availableTo='asm1,db1'
     
     CellCLI> CREATE GRIDDISK reco1_CD_00_cell01,reco1_CD_01_cell01, -
     reco1_CD_02_cell01 size=75G, availableTo='asm1,db1'
     
     CellCLI> CREATE GRIDDISK data2_CD_00_cell01,data2_CD_01_cell01, -
     data2_CD_02_cell01 size=75G, availableTo='asm1,db2'
     
     CellCLI> CREATE GRIDDISK reco2_CD_00_cell01,reco2_CD_01_cell01, -
     reco2_CD_02_cell01 size=75G, availableTo='asm1,db2'

   • To change security on existing grid disks, use a command similar to the following on every storage server. In the following example, asm1 is the unique name for the Oracle ASM client, and db1 and db2 are the unique names for the database clients. The grid disks specified in this command must include all the grid disks used by the Oracle ASM disk groups for each database client.

     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,db1'
     
     CellCLI> ALTER GRIDDISK data2_CD_00_cell01, data2_CD_01_cell02, -
     data2_CD_02_cell01, reco2_CD_00_cell01, reco2_CD_01_cell01, reco2_CD_02_cell01, -
     availableTo='asm1,db2'
     

   When you specify a value for availableTo, then only the clients configured with the same key assigned to that alias in their cellkey.ora file have access to the grid disks.

9. Verify the key assignment on the storage servers.

   CellCLI> LIST KEY
           asm1    66e12adb996805358bf82258587f5050
           db1     f3f21c625ff41ef479a1bb033e0839e5
           db2     cf03b74de32a67a6c1ec87b9da72bd47

   CellCLI> LIST GRIDDISK ATTRIBUTES name,availableTo WHERE availableTo=!''
            DATA1_CD_00_cell01     asm1,db1
            DATA1_CD_01_cell01     asm1,db1
            DATA1_CD_02_cell01     asm1,db1
            DATA2_CD_00_cell01     asm1,db2
            DATA2_CD_01_cell01     asm1,db2
            DATA2_CD_02_cell01     asm1,db2
   ...

10. Copy the cellkey.ora file created in step 4 to the /etc/oracle/cell/network-config directory on each database server.

    In the following command, dbs_group is a file that contains the names of the database servers that are clients of the Oracle ASM cluster.

    dcli -g dbs_group -l grid -f /home/grid/cellkey.ora -d /etc/oracle/cell/
    network-config/cellkey.ora

11. On each database server, set the permissions for the cellkey.ora file for Oracle ASM to be read-only by the file owner and the group.

    You can use dcli to configure the file permissions multiple servers with a single command. In the following example, dbs_group is a file that contains a list of all the database servers that are clients of the Oracle ASM cluster.

    dcli -g dbs_group -l grid chmod 640 /etc/oracle/cell/network-config/
    cellkey.ora

12. Copy each cellkey.ora file created in step 5 to its $ORACLE_HOME/admin/db_unique_name/pfile directory on each database server.

    In the following command, db1_group is a file that contains the names of the database servers that host the database instances for the db1 database, and dbuser1 is the operating system user that owns the $ORACLE_HOME/admin/db1 directory.

    dcli -g db1_group -l dbuser1 -f /home/dbuser1/cellkey.ora 
    -d $ORACLE_HOME/admin/db1/pfile/cellkey.ora

    In this example, db2_group is a file that contains the names of the database servers that host the database instances for the database with the unique database name of db2, and dbuser2 is the operating system user that owns the $ORACLE_HOME/admin/db2 directory.

    dcli -g db2_group -l dbuser2 -f /home/dbuser2/cellkey.ora 
    -d $ORACLE_HOME/admin/db2/pfile/cellkey.ora

13. On each database server, set the permissions the permissions for the cellkey.ora file in each Oracle database home to be accessible by only the file owner.

    You can use dcli to configure the file permissions multiple servers with a single command. In the following example, db1_group is a file that contains the names of the database servers that host the database instances for the database with the unique database name of db1, and dbuser1 is the operating system user that owns the $ORACLE_HOME/admin/db1 directory.

    dcli -g db1_group -l dbuser1 chmod 600 $ORACLE_HOME/admin/
    db1/pfile/cellkey.ora

    In this example, db2_group is a file that contains the names of the database servers that host the database instances for the database with the unique database name of db2, and dbuser2 is the operating system user that owns the $ORACLE_HOME/admin/db2 directory.

    dcli -g db2_group -l dbuser2 chmod 600 $ORACLE_HOME/admin/db2/pfile/
    cellkey.ora

14. On the database servers, restart Oracle Clusterware, the Oracle ASM instances, and the Oracle Database instances.

    The commands to stop and start Oracle Clusterware are:

    # crsctl stop crs
    # crsctl start crs

    Then restart the Oracle ASM and Oracle Database instances if they are not started automatically by Oracle Clusterware.

15. Remove the temporary cellkey.ora files created in step 4 and step 5.

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.

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.