Exadata Storage Serverのデータ・セキュリティの構成

4.4 Exadata Storage Serverのデータ・セキュリティの構成

Oracle Exadata Storage Serverのデータ・セキュリティは、ストレージ・セル上の特定のグリッド・ディスクにアクセスできるOracle Automatic Storage Management (Oracle ASM)クラスタおよびOracle Databaseクライアントを制御することにより実装されます。

デフォルトでは、Oracle DatabaseとOracle ASMのすべてのインスタンスが、ストレージ・サーバーのすべてのグリッド・ディスクにアクセスできます。各データベースの記憶域は、Oracle ASMによって提供されます。Oracle Exadata Database Machineでは、クラスタ化された、またはクラスタ化されていない複数のデータベースを実行できます。複数のOracle ASMクラスタを含めることもできます。Oracle ASMクラスタとは、インターコネクトされたノードの集合で、各ノードにはOracle ASMインスタンスが存在し、統合クラスタとして機能します。Oracle ASMクラスタは、ノード上でも機能する1つ以上のOracle Databaseインスタンスに共有ストレージ・プールを提供します。

Exadata Storage Serverのセキュリティ・モードについて
Oracle Exadata System Softwareのセキュリティは、オープン・セキュリティ、ASMを有効範囲にしたセキュリティ、またはDBを有効範囲にしたセキュリティに対応しています。
ASMを有効範囲にしたセキュリティとDBを有効範囲にしたセキュリティのベスト・プラクティス
セキュリティを設定する際には、すべてのストレージ・サーバーで構成が同じであることが重要です。
セキュリティ・キーについて
Oracle Exadata System Softwareでは、キーを使用してクライアントを識別し、グリッド・ディスクへのアクセス権を決定します。
Oracle Exadata Storage ServerのASMを有効範囲にしたセキュリティの設定
ASMを有効範囲にしたセキュリティを構成するには、データベース・サーバーとストレージ・サーバーの両方でアクションを実行する必要があります。
Oracle Exadata Database MachineでのDBを有効範囲にしたセキュリティの設定
DBを有効範囲にしたセキュリティを構成する際には、データベースおよびストレージ・サーバーの両方でアクションを実行します。
ASMを有効範囲にしたセキュリティまたはDBを有効範囲にしたセキュリティのセキュリティ・キーの変更
ASMを有効範囲にしたセキュリティまたはDBを有効範囲にしたセキュリティで使用されるキーを変更できます。
Cell-to-Cell操作の有効化
Oracle Exadata Database Machineに対して、ASMを有効範囲にしたセキュリテまたはDBを有効範囲にしたセキュリティを構成した場合は、Cell-to-Cell操作が制限されないようにアクセス制御を構成する必要があります。
ASMを有効範囲にしたセキュリティまたはDBを有効範囲にしたセキュリティの削除
オープン・セキュリティ・モデルに戻す場合は、ASMを有効範囲にしたセキュリティを削除する前に、グリッド・ディスクのDBを有効範囲にしたセキュリティを削除する必要があります。

親トピック: Oracle Exadataの保護

4.4.1 Exadata Storage Serverのセキュリティ・モードについて

Oracle Exadata System Softwareのセキュリティは、オープン・セキュリティ、ASMを有効範囲にしたセキュリティ、またはDBを有効範囲にしたセキュリティに対応しています。

オープン・セキュリティ

デフォルトのセキュリティ・モードはオープン・セキュリティで、すべてのデータベース・クライアントがすべてのグリッド・ディスクにアクセスできます。オープン・セキュリティ・モードは、セキュリティ要件がないテスト用または開発用のデータベースで便利です。このモードは、新規のストレージ・セルを作成した後のデフォルトのセキュリティ・モードです。

ASMを有効範囲にしたセキュリティ

ASMを有効範囲にしたセキュリティを使用すると、Oracle ASMクラスタに関連付けられたOracle ASMディスク・グループによって使用されるグリッド・ディスクにのみアクセスを制限できます。Oracle ASMクラスタに関連付けられているすべてのOracle Databaseインスタンスが、ディスク・グループおよび基礎となるグリッド・ディスクにアクセスできます。異なるOracle ASMクラスタに属するディスク・グループで使用されるグリッド・ディスクには、これらのインスタンスからアクセスできません。

クラスタ内のすべてのデータベースおよびOracle ASMインスタンスが、そのクラスタによって使用されるOracle ASMディスク・グループを構成するグリッド・ディスクにアクセスできるようにする場合は、ASMを有効範囲にしたセキュリティを使用します。これは、Oracle ASMクラスタにデータベースが1つしかない場合にも適用されます。

図4-1 ASMを有効範囲にしたセキュリティ

「図4-1 ASMを有効範囲にしたセキュリティ」の説明

DBを有効範囲にしたセキュリティ

DBを有効範囲にしたセキュリティを使用すると、Oracle Databaseインスタンスのアクセスを特定のグリッド・ディスクのセットのみに制限できます。データベース・インスタンスは、データベースのOracle ASMディスク・グループによって使用されるすべてのグリッド・ディスクにアクセスできる必要があります。これらのOracle ASMディスク・グループによって使用されるグリッド・ディスクは、他のOracle ASMディスク・グループでは使用できません。

DBを有効範囲にしたセキュリティ・モードは、複数のデータベースがグリッド・ディスクにアクセスする場合に適しています。DBを有効範囲にしたセキュリティを使用すると、データベースに関連付けられたOracle ASMディスク・グループによって使用されるグリッド・ディスクのみにデータベース・アクセスを制限できます。

sagug_031-db-scoped-security.epsの説明が続きます

図sagug_031-db-scoped-security.epsの説明

親トピック: Exadata Storage Serverのデータ・セキュリティの構成

4.4.2 ASMを有効範囲にしたセキュリティとDBを有効範囲にしたセキュリティのベスト・プラクティス

セキュリティを設定する際には、すべてのストレージ・サーバーで構成が同じであることが重要です。

Oracle Exadata System Softwareで一貫性のあるセキュリティを設定するには、次の点を確認します。

混乱やエラーを避けるために、同じOracle ASMディスク・グループに属するすべてのグリッド・ディスクに対して、セル側に同じグリッド・ディスク・セキュリティを構成します。
Oracle ASMクラスタ内のOracle Real Application Clusters (Oracle RAC)のすべてのサーバーに、Oracle ASMのcellkey.oraファイルの同じ内容、所有権およびセキュリティがあることを確認します。
データベース・クラスタのすべてのOracle RACサーバーに、データベースのcellkey.oraファイルの同じ内容、所有権およびセキュリティがあることを確認します。
DBを有効範囲にしたセキュリティを実装する場合は、グリッド・ディスクにアクセスするすべてのデータベースに実装されていることを確認します。グリッド・ディスクに、ASMを有効範囲にしたセキュリティとDBを有効範囲にしたセキュリティを混在させないでください。
dcliユーティリティを使用して構成を変更し、一貫性を確保してユーザー・エラーの可能性を排除します。

関連トピック

dcliユーティリティの使用

親トピック: Exadata Storage Serverのデータ・セキュリティの構成

4.4.3 セキュリティ・キーについて

Oracle Exadata System Softwareでは、キーを使用してクライアントを識別し、グリッド・ディスクへのアクセス権を決定します。

グリッド・ディスクにアクセスできるクライアントを決定するには、CellCLIを使用してキーを生成し、クライアントによってのみアクセス可能な読取り専用ファイルに格納します。CellCLIのCREATE KEYコマンドでは、セキュリティ・キーとして使用するランダムの16進文字列が生成されます。このキーは、クライアント側のcellkey.oraファイルに格納され、ASSIGN KEYコマンドを使用してストレージ・サーバー上のターゲットに割り当てられます。

ノート:

クライアント名またはOracle ASMクラスタ名では、大/小文字が区別されません。たとえば、ASM1とasm1は同じ値として扱われます。

CREATE KEYコマンドは任意のセルで実行できます。このコマンドは、新しい一意キーを作成する必要がある場合にのみ実行する必要があります。ASMを有効範囲にしたセキュリティを構成する場合は、Oracle ASMクラスタごとに1つのセキュリティ・キーしか必要ありません。DBを有効範囲にしたセキュリティを構成する場合は、Oracle ASMクラスタごとに1つのキーが必要であり、データベース・クライアントごとに追加のセキュリティ・キーが必要です。

ASMスコープのセキュリティの場合、cellkey.oraファイルには、Oracle ASMクラスタおよびそのデータベース・クライアントのみがアクセスできます。DBを有効範囲にしたセキュリティの場合、複数のセキュリティ・キーが使用されます。Oracle ASMクラスタに1つのキーが割り当てられ、データベース・クライアントごとに1つのキーが割り当てられます。これらのセキュリティ・キーは別々のcellkey.oraファイルに格納され、各ファイルにはクライアントからのみアクセスできます。

cellkey.oraファイルには、Oracle ASM、データベース・クライアントおよびセル間のセキュリティを構成するエントリが含まれます。Oracle ASMおよびデータベースのホスト・コンピュータ上のcellkey.oraファイルのkeyおよびasmの値は、セル上のクライアントに割り当てられた値に一致する必要があります。

cellkey.oraファイルには次のフィールドがあります。

key — このフィールドは必須です。
- ASMを有効範囲にしたセキュリティの場合は、CellCLIのASSIGN KEYコマンドでOracle ASMクラスタに割り当てられたキーの値に、このキーを一致させる必要があります。
- DBを有効範囲にしたセキュリティの場合は、CellCLIのASSIGN KEYコマンドでデータベース・クライアントに割り当てられたキーの値に、このキーを一致させる必要があります。
asm — このフィールドは必須です。

このフィールドには、各Oracle ASMクラスタの一意の識別子が含まれます。この値は、ストレージ・グリッドのストレージ・サーバーにアクセスするすべてのクラスタで一意である必要があります。この値は、各セルで実行されるASSIGN KEYコマンドで使用されます。また、特定のOracle ASMクラスタのみからアクセスを許可するようにグリッド・ディスクを構成するために、ALTER GRIDDISKおよびCREATE GRIDDISKコマンドで使用されます。

ノート:
asmフィールドは、ASMを有効範囲にしたセキュリティとDBを有効範囲にしたセキュリティの両方を構成する場合に使用されます。

cellkey.oraファイルへのアクセスは、オペレーティング・システム権限によって制御されます。

Oracle ASMクライアントの場合、ファイルは/etc/oracle/cell/network-configディレクトリに格納され、Oracle Grid Infrastructureソフトウェア所有者とユーザーが属するグループによって読み取ることができます。
DBを有効範囲にしたセキュリティの場合、Oracle ASMにはOracle Grid Infrastructureソフトウェア所有者のみが読み取れる1つのcellkey.oraと、データベース・クライアントごとに追加のcellkey.oraファイルがあります。データベース・クライアントの場合、ファイルは各データベースのOracleホーム・ディレクトリのpfileディレクトリに格納されます。データベースのcellkey.oraファイルは、Oracle Databaseソフトウェアのインストールを所有するオペレーティング・システム・ユーザーのみが読み取ることができます。

ノート:
DBを有効範囲にしたセキュリティを実装するには、Oracle Grid InfrastructureおよびOracle Databaseソフトウェアを、異なるオペレーティング・システム・ユーザーが所有する必要があります。

図4-2 セキュリティ・キーとcellkey.oraファイル

「図4-2 セキュリティ・キーとcellkey.oraファイル」の説明

ストレージ・サーバーで、セルのアクセス制御リスト(ACL)にセキュリティ・キーを格納するには、ASSIGN KEYコマンドを使用します。ALTER GRIDDISKコマンドは、AvailableTo属性で個々のグリッド・ディスクのアクセス権を設定する際に使用します。グリッド・ディスクにアクセスするには、セルACLのセキュリティ・キーがクライアントのセキュリティ・キーと一致しており、クライアントの一意の名前がグリッド・ディスクのAvailableTo属性に含まれている必要があります。

Oracle ASMおよびデータベースに使用される識別名は一意にする必要があります。ただし、一部の環境では、DB_UNIQUE_IDに同じ値を持つデータベースが複数存在します。各データベースは、記憶域に異なるOracle ASMクラスタを使用します。Oracle Exadata System Softwareリリース12.2.1.1.0以降では、Oracle ASMクラスタに基づいて、ASMを有効範囲にしたセキュリティを定義できます。ASSIGN KEYコマンドでは、ASMCLUSTERキーワードを使用します。ASMCLUSTERキーワードを使用すると、データベース名はOracle ASMの一意識別子で修飾され、同じDB_UNIQUE_IDを持つ場合でも、データベースごとに一意のIDが作成されます。各Oracle ASMクラスタ内では、データベース名は一意である必要があります。

ASMを有効範囲にしたセキュリティまたはDBを有効範囲にしたセキュリティを構成する場合は、Cell-to-Cell操作を有効にするためにセキュリティ・キーを構成する必要があります。ストレージ・サーバーまたはセルごとにキーを作成し、ASSIGN KEY FOR LOCAL CELLコマンドを使用してセルのローカル・キーとしてそのキーを割り当てます。次に、ASSIGN KEY FOR REMOTE CELLコマンドを使用して現在のセルでCell-to-Cell操作を実行する他のセルのキーを割り当てます。

例4-5 Exadata Storage Securityのセキュリティ・キーの作成

任意のストレージ・サーバーで次のコマンドを使用して、一意のセキュリティ・キーを生成します。このキーは、ASMを有効範囲にしたセキュリティまたはDBを有効範囲にしたセキュリティの構成に使用されます。

CellCLI> CREATE KEY
         66e12adb996805358bf82258587f5050

例4-6 cellkey.oraファイルのエントリ

この例では、cellkey.oraファイルのエントリを示しています。

key=66e12adb996805358bf82258587f5050
asm=cluster1

4.4.4 Oracle Exadata Storage ServerのASMを有効範囲にしたセキュリティの設定

ASMを有効範囲にしたセキュリティを構成するには、データベース・サーバーとストレージ・サーバーの両方でアクションを実行する必要があります。

次のステップでは、単一のOracle ASMクラスタと、そのOracle ASMクラスタのクライアントであるデータベースに対して、ASMを有効範囲にしたセキュリティを構成します。これらのステップの例では、Oracle ASMソフトウェア所有者がユーザーgridであることを前提としています。

Oracle DatabaseおよびOracle ASMインスタンスをシャットダウンします。
ストレージ・サーバーの1つで、CellCLIのCREATE KEYコマンドを使用してランダムな16進文字列を生成します。このコマンドは、任意のストレージ・サーバーで実行できます。
```
CellCLI> CREATE KEY

66e12adb996805358bf82258587f5050
```
データベース・サーバーの1つで、cellkey.oraファイルにキーをコピーします。
1. ソフトウェア所有者のホーム・ディレクトリにcellkey.oraを作成します(たとえば、/home/grid/cellkey.ora)。
2. 次に示す形式(cluster1はOracle ASMクラスタの別名)を使用して、cellkey.oraファイルにキーを追加します。
  別名は、ストレージ・サーバーにアクセスするすべてのクラスタ間で一意である必要があります。Oracle Clusterwareのクラスタ名は、クラスタが一意名を持つ場合に使用できます。
```
key=66e12adb996805358bf82258587f5050
asm=cluster1
```
ASSIGN KEYコマンドを使用して、Oracle ASMクラスタでアクセスするすべてのストレージ・サーバーのOracle ASMクラスタ・クライアントに、セキュリティ・キーを割り当てます。たとえば:
```
CellCLI> ASSIGN KEY FOR ASMCLUSTER 'cluster1'='66e12adb996805358bf82258587f5050'
```
前述のコマンドは、Oracle ASMクラスタでアクセスするすべてのストレージ・サーバーで繰り返す必要があります。または、dcliコマンドを次のように使用することもできます。
```
dcli -g cell_group -l celladmin "cellcli -e \"ASSIGN KEY FOR ASMCLUSTER 'cluster1'=
'66e12adb996805358bf82258587f5050'\""
```
Oracle ASMクラスタがアクセスするすべてのストレージ・サーバーでグリッド・ディスクにセキュリティを構成します。
セキュリティ・キーは、グリッド・ディスクの作成時に、またはALTER GRIDDISKコマンドを使用して構成できます。
- セキュリティが構成されている新しいグリッド・ディスクを作成するには、次のようなコマンドを使用します。cluster1は、Oracle ASMクライアントの一意の名前です。
```
CellCLI> CREATE GRIDDISK ALL PREFIX=sales, size=75G, -
         availableTo='cluster1'
```
- 既存のグリッド・ディスクのセキュリティを変更するには、すべてのストレージ・サーバーで次のようなコマンドを使用します。次の例で、cluster1はOracle ASMクライアントの一意の名前です。このコマンドで指定するグリッド・ディスクには、Oracle ASMディスク・グループによって使用されるすべてのグリッド・ディスクが含まれている必要があります。
```
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'
```
前述のコマンドで、別名、たとえばcluster1は、すべてのストレージ・サーバーおよびすべてのクラスタで一意かつ一貫性のある値です。availableToの値を指定すると、cellkey.oraファイルで同じ別名で構成されたクライアントのみがグリッド・ディスクにアクセスできます。availableTo属性に値がない場合、クライアントはそれらのグリッド・ディスクにアクセスできます。
ストレージ・サーバーでキー割当てを検証します。
```
CellCLI> LIST KEY
```
```
CellCLI> LIST GRIDDISK ATTRIBUTES name,availableTo
```
ステップ3で作成したcellkey.oraファイルを、各データベース・サーバーの/etc/oracle/cell/network-configディレクトリにコピーします。
次のコマンドで、dbs_groupは、Oracle ASMクラスタのクライアントであるデータベース・サーバーの名前を含むファイルです。
```
dcli -g dbs_group -l grid -f /home/grid/cellkey.ora -d /etc/oracle/cell/
network-config/cellkey.ora
```
各データベース・サーバーで、cellkey.oraの権限を構成します。
- すべてのOracleソフトウェアでロール区切りの管理を使用する場合は、ファイルに対する権限を所有者およびグループによる読取り専用に設定します。ファイルのグループ所有権を、Oracle Grid Infrastructure (grid)とOracle Database (oracle)の両方のインストール・ユーザーを含むoinstallグループに変更します。
  
  dcliを使用すると、単一のコマンドで複数のサーバーにファイルを構成できます。
```
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
```
- すべてのOracleソフトウェアで単一のインストール・ユーザーを使用する場合は、ファイルの権限をソフトウェア所有者の読取り専用に設定します(たとえば、oracle)。
```
chown oracle:oinstall /etc/oracle/cell/network-config/cellkey.ora
chmod 400 /etc/oracle/cell/network-config/cellkey.ora
```
データベース・サーバーで、Oracle Clusterware、Oracle ASMインスタンスおよびOracle Databaseインスタンスを再起動します。
Oracle Clusterwareを停止および起動するコマンドは次のとおりです。
```
# crsctl stop crs
# crsctl start crs
```
次に、Oracle ASMおよびOracle Databaseインスタンスが自動的に起動していない場合は再起動します。
ステップ3で作成した一時cellkey.oraファイルを削除します。

4.4.5Oracle Exadata Database MachineのDBを有効範囲にしたセキュリティの設定

DBを有効範囲にしたセキュリティを構成する際には、データベースおよびストレージ・サーバーの両方でアクションを実行します。

これらのステップでは、単一のOracle ASMクラスタと、そのOracle ASMクラスタのクライアントであるデータベースに対して、DBを有効範囲にしたセキュリティを構成します。これらのステップの例では、Oracle ASMソフトウェア所有者がユーザーgridで、各Oracle Databaseホームが別々のオペレーティング・システム・ユーザーによって所有されていることを前提としています。

DBを有効範囲にしたセキュリティを構成するには、次の条件が存在する必要があります。

データベース・クライアントで使用されるOracle Databaseクライアントの一意の名前とOracle ASMクラスタとの組合せは、環境内で一意である必要があります。
Oracle Grid Infrastructureソフトウェアのインストールおよび各Oracle Databaseソフトウェアのインストールは、異なるオペレーティング・システム・ユーザーが所有する必要があります。
各データベース・クライアントには、個別のOracle ASMディスク・グループが必要です。Oracle ASMディスク・グループによって使用されるグリッド・ディスクは、1つのOracle ASMディスク・グループにのみ割り当てることができます。

各データベースのDB_UNIQUE_NAMEを取得します。名前は、大文字と小文字が区別されます。
```
SQL> SELECT db_unique_name FROM V$DATABASE;
```
Oracle ASMクラスタのデータベースおよびOracle ASMインスタンスを停止します。
ストレージ・サーバーの1つで、CellCLIのCREATE KEYコマンドを使用してOracle ASMのキーと、Oracle Databaseクライアントのキーを生成します。
このコマンドは、任意のストレージ・サーバーで実行できます。
```
CellCLI> CREATE KEY
        66e12adb996805358bf82258587f5050

CellCLI> CREATE KEY
        f3f21c625ff41ef479a1bb033e0839e5

CellCLI> CREATE KEY
        cf03b74de32a67a6c1ec87b9da72bd47
```
Oracle ASMのキーを、データベース・サーバーのcellkey.oraファイルにコピーします。
1. Oracle Grid Infrastructureソフトウェア所有者のホーム・ディレクトリ(たとえば、/home/grid/cellkey.ora)にcellkey.oraを作成します。
2. 次に示す形式(asm1はOracle ASMクラスタの別名)を使用して、cellkey.oraファイルにキーを追加します。
  別名は、ストレージ・サーバーにアクセスするすべてのクラスタ間で一意である必要があります。Oracle Clusterwareのクラスタ名は、クラスタが一意名を持つ場合に使用できます。
```
key=66e12adb996805358bf82258587f5050
asm=asm1
```
各Oracle Databaseクライアントのキーを、データベース・サーバーの1つのOracleホーム・ソフトウェア所有者のユーザー・ディレクトリにあるcellkey.oraファイルにコピーします。
1. 各Oracle Databaseソフトウェア所有者のホーム・ディレクトリ(たとえば、/home/db1user/cellkey.oraと/home/db2user/cellkey.ora)にcellkey.oraを作成します。
2. 各データベース・クライアントのセキュリティ・キーをcellkey.oraファイルに追加します。
  ここに示す形式を使用します。asm1は、データベース・クライアントによって使用されるOracle ASMクラスタの別名です。この例では、各データベース・クライアントが同じOracle ASMクラスタを使用します。
```
$ cat /home/db1user/cellkey.ora
key=f3f21c625ff41ef479a1bb033e0839e5
asm=asm1
$ cat /home/db2user/cellkey.ora
key=cf03b74de32a67a6c1ec87b9da72bd47
asm=asm1
```
ノート:
asmフィールドは、ASMを有効範囲にしたセキュリティと、DBを有効範囲にしたセキュリティの両方で使用されます。
ASSIGN KEYコマンドを使用して、Oracle ASMクラスタでアクセスするすべてのストレージ・サーバーのOracle ASMクライアントに、セキュリティ・キーを割り当てます。たとえば:
```
CellCLI> ASSIGN KEY FOR 'asm1'='66e12adb996805358bf82258587f5050'
```
前述のコマンドは、すべてのストレージ・サーバーで繰り返す必要があります。または、次に示すようにdcliコマンドを使用することもできます。
```
dcli -g cell_group -l root "cellcli -e \"ASSIGN KEY FOR 'asm1'=
'66e12adb996805358bf82258587f5050'\""
```
ASSIGN KEYコマンドを使用して、そのデータベースのOracle ASMディスク・グループによって使用されるグリッド・ディスクを含むすべてのストレージ・サーバー上の各Oracle Databaseクライアントに、セキュリティ・キーを割り当てます。たとえば:
```
CellCLI> ASSIGN KEY FOR 'db1'='f3f21c625ff41ef479a1bb033e0839e5'

CellCLI> ASSIGN KEY FOR 'db2'='cf03b74de32a67a6c1ec87b9da72bd47'
```
前述のコマンドは、すべてのストレージ・サーバーで繰り返す必要があります。また、ここに示すようにdcliコマンドを使用することもできます。cell_group_db1には、最初のデータベースによって使用されるストレージ・サーバーのリストが含まれ、cell_group_db2には、2番目のデータベースで使用されるストレージ・サーバーのリストが含まれます。
```
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'\""
```
データベース・クライアントがアクセスするすべてのストレージ・サーバーでグリッド・ディスクにセキュリティを構成します。
セキュリティ・キーは、グリッド・ディスクの作成時に、またはALTER GRIDDISKコマンドを使用して構成できます。
- セキュリティが構成されている新しいグリッド・ディスクを作成するには、次のようなコマンドを使用します。asm1はOracle ASMクライアントの一意の名前、db1およびdb2はデータベース・クライアントの一意の名前です。
```
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'
```
- 既存のグリッド・ディスクのセキュリティを変更するには、すべてのストレージ・サーバーで次のようなコマンドを使用します。次の例では、asm1はOracle ASMクライアントの一意の名前、db1およびdb2はデータベース・クライアントの一意の名前です。このコマンドで指定するグリッド・ディスクには、各データベース・クライアントのOracle ASMディスク・グループによって使用されるすべてのグリッド・ディスクが含まれている必要があります。
```
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'
```
availableToの値を指定すると、cellkey.oraファイルでその別名に同じキーを割り当てて構成されたクライアントのみがグリッド・ディスクにアクセスできます。availableTo属性の値がない場合は、どのクライアントもグリッド・ディスクにアクセスできます。

ストレージ・サーバーでキー割当てを検証します。

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
...

ステップ4で作成したcellkey.oraファイルを、各データベース・サーバーの/etc/oracle/cell/network-configディレクトリにコピーします。
次のコマンドで、dbs_groupは、Oracle ASMクラスタのクライアントであるデータベース・サーバーの名前を含むファイルです。
```
dcli -g dbs_group -l grid -f /home/grid/cellkey.ora -d /etc/oracle/cell/
network-config/cellkey.ora
```
各データベース・サーバーで、Oracle ASMのcellkey.oraファイルに対する権限をファイルの所有者およびグループによる読取り専用に設定します。
dcliを使用すると、単一のコマンドで複数のサーバーにファイル権限を構成できます。次の例では、dbs_groupは、Oracle ASMクラスタのクライアントであるデータベース・サーバーのリストを含むファイルです。
```
dcli -g dbs_group -l grid chmod 640 /etc/oracle/cell/network-config/
cellkey.ora
```
ステップ5で作成した各cellkey.oraファイルを、各データベース・サーバーの$ORACLE_HOME/admin/db_unique_name/pfileディレクトリにコピーします。
次のコマンドで、db1_groupはdb1データベースのデータベース・インスタンスをホストするデータベース・サーバーの名前を含むファイルであり、dbuser1は$ORACLE_HOME/admin/db1ディレクトリを所有するオペレーティング・システム・ユーザーです。
```
dcli -g db1_group -l dbuser1 -f /home/dbuser1/cellkey.ora 
-d $ORACLE_HOME/admin/db1/pfile/cellkey.ora
```
この例では、db2_groupは、一意のデータベース名db2を持つデータベースのデータベース・インスタンスをホストするデータベース・サーバーの名前を含むファイルであり、dbuser2は$ORACLE_HOME/admin/db2ディレクトリを所有するオペレーティング・システム・ユーザーです。
```
dcli -g db2_group -l dbuser2 -f /home/dbuser2/cellkey.ora 
-d $ORACLE_HOME/admin/db2/pfile/cellkey.ora
```
各データベース・サーバーで、各Oracleデータベース・ホームのcellkey.oraファイルの権限をファイル所有者のみアクセスできるように設定します。
dcliを使用すると、単一のコマンドで複数のサーバーにファイル権限を構成できます。次の例で、db1_groupは、一意のデータベース名db1を持つデータベースのデータベース・インスタンスをホストするデータベース・サーバーの名前を含むファイルであり、dbuser1は$ORACLE_HOME/admin/db1ディレクトリを所有するオペレーティング・システム・ユーザーです。
```
dcli -g db1_group -l dbuser1 chmod 600 $ORACLE_HOME/admin/
db1/pfile/cellkey.ora
```
この例では、db2_groupは、一意のデータベース名db2を持つデータベースのデータベース・インスタンスをホストするデータベース・サーバーの名前を含むファイルであり、dbuser2は$ORACLE_HOME/admin/db2ディレクトリを所有するオペレーティング・システム・ユーザーです。
```
dcli -g db2_group -l dbuser2 chmod 600 $ORACLE_HOME/admin/db2/pfile/
cellkey.ora
```
データベース・サーバーで、Oracle Clusterware、Oracle ASMインスタンスおよびOracle Databaseインスタンスを再起動します。
Oracle Clusterwareを停止および起動するコマンドは次のとおりです。
```
# crsctl stop crs
# crsctl start crs
```
次に、Oracle ASMおよびOracle DatabaseインスタンスがOracle Clusterwareによって自動的に起動していない場合は、再起動します。
ステップ4およびステップ5で作成した一時cellkey.oraファイルを削除します。

4.4.6 ASMを有効範囲にしたセキュリティまたはDBを有効範囲にしたセキュリティのセキュリティ・キーの変更

ASMを有効範囲にしたセキュリティまたはDBを有効範囲にしたセキュリティで使用されるキーを変更できます。

ASMCLUSTERのASMを有効範囲にしたセキュリティ・キーのアップグレード
Oracle Exadata System Softwareリリース12.2.1.1.0以降では、Oracle ASMクラスタに基づいて、ASMを有効範囲にしたセキュリティを定義できます。
ASMを有効範囲にしたセキュリティに割り当てられたキー値の変更
ASMを有効範囲にしたセキュリティを使用するように構成されたOracle ASMクライアントに使用するキー値を変更できます。
DBを有効範囲にしたセキュリティに割り当てられたキー値の変更
DBを有効範囲にしたセキュリティを使用するように構成されたOracle ASMクライアントによって使用されるキー値を変更できます。

親トピック: Exadata Storage Serverのデータ・セキュリティの構成

4.4.6.1 ASMCLUSTERのASMを有効範囲にしたセキュリティ・キーのアップグレード

Oracle Exadata System Softwareリリース12.2.1.1.0以降では、Oracle ASMクラスタに基づいて、ASMを有効範囲にしたセキュリティを定義できます。

Oracle ASMおよびデータベース・インスタンスに使用される識別名は一意にする必要があります。ただし、一部の環境では、DB_UNIQUE_IDに同じ値を持つデータベースが複数存在します。各データベースが異なるOracle ASMクラスタを記憶域に使用する場合、セキュリティ・キーを割り当てる際にASMCLUSTERキーワードを使用して、指定したOracle ASMクラスタへのアクセスを制限するよう指定することができます。

ASMCLUSTERキーワードを使用すると、データベース名はOracle ASMの一意識別子で修飾され、同じDB_UNIQUE_IDを持つ場合でも、データベースごとに一意のIDが作成されます。各Oracle ASMクラスタ内では、データベース名は一意である必要があります。

ノート:

DBを有効範囲にしたセキュリティを使用している場合は、キーを割り当てるときにASMCLUSTERキーワードを使用しないでください。ASMを有効範囲にしたセキュリティには、ASMCLUSTERキーワードのみを使用します。

ASMを有効範囲にしたセキュリティは構成されているが、キーをASMCLUSTERキーに変更する場合は、次のステップを実行します。

ASMCLUSTERキーにアップグレードするキー値を取得します。

$ dcli -c dm01cel01,dm01cel02,dm01cel03 cellcli -e list key
dm01cel01:      asm1   118af47c57ab8da650ab67d5587fe728
dm01cel02:      asm1   118af47c57ab8da650ab67d5587fe728
dm01cel03:      asm1   118af47c57ab8da650ab67d5587fe728

同じキー値を使用し、ただしASMCLUSTERキーワードを追加して、ASSIGN KEYコマンドを再発行します。
```
$ dcli -c dm01cel01,dm01cel02,dm01cel03 "cellcli -e assign key for ASMCLUSTER
 \'asm1\'=\'118af47c57ab8da650ab67d5587fe728\'"
```
名前およびキーは、ASMを有効範囲にしたセキュリティ・リストから削除され、Oracle ASMクラスタ・クライアントとして追加されます。ACLのこのOracle ASMクライアントを含むグリッド・ディスクは、この操作に対してオンラインのままにできます。

キーがASMCLUSTERキーにアップグレードされていることを確認してください。

$ dcli -c dm01cel01,dm01cel02,dm01cel03 cellcli -e list key
dm01cel01:      asm1   118af47c57ab8da650ab67d5587fe728      ASMCLUSTER
dm01cel02:      asm1   118af47c57ab8da650ab67d5587fe728      ASMCLUSTER
dm01cel03:      asm1   118af47c57ab8da650ab67d5587fe728      ASMCLUSTER

親トピック: ASMを有効範囲にしたセキュリティまたはDBを有効範囲にしたセキュリティのセキュリティ・キーの変更

4.4.6.2 ASMを有効範囲にしたセキュリティに割り当てられたキー値の変更

ASMを有効範囲にしたセキュリティを使用するように構成されたOracle ASMクライアントに使用するキー値を変更できます。

セキュリティ構成を変更するOracle DatabaseおよびOracle ASMインスタンスを停止します。
CellCLIのCREATE KEYコマンドを使用して、ランダムの16進文字列を生成します。このコマンドは任意のセルで実行できます。
```
CellCLI> CREATE KEY

          f3d15c0c5e854345bcb3c2b678b1de45
```
cellkey.oraファイルを更新します。
1. データベース・サーバーの1つで、/etc/oracle/cell/network-config/cellkey.oraファイルをグリッド所有者のホーム・ディレクトリ(たとえば、/home/grid/cellkey.ora)にコピーします。
2. Oracle ASMクライアントに新しいキーを使用するようにファイルを更新します。
```
key=f3d15c0c5e854345bcb3c2b678b1de45
asm=asm1
```
cellkey.oraファイルを各データベース・サーバーの/etc/oracle/cell/network-configにコピーし、既存のファイルを上書きします。
次のコマンドで、dbs_groupはOracle ASMクラスタのクライアントであるデータベース・サーバーの名前を含むファイル、gridはOracle ASMインストールのソフトウェア所有者です。
```
dcli -g dbs_group -l grid -f /home/grid/cellkey.ora -d /etc/oracle/cell/
network-config/cellkey.ora
```
Oracle Grid Infrastructureソフトウェア所有者のみがファイルにアクセスできるように、/etc/oracle/cell/network-configでcellkey.oraの権限が構成されていることを確認します。
ファイルの所有者がOracle Grid Infrastructureソフトウェア所有者であることを確認します。現在のファイル権限がrw------- (600)でない場合は、次のコマンドに示すように権限を変更します。
```
dcli -g dbs_group -l grid chmod 600 /etc/oracle/cell/network-config/cellkey.ora
```
ASSIGN KEYコマンドを使用して、Oracle ASMクラスタによって使用されるグリッド・ディスクを含むすべてのセルのOracle ASMクラスタ・クライアントに割り当てられたセキュリティ・キーを更新します。
データベース・サーバーのcellkey.oraファイルで使用されるOracle ASMクライアントに同じ識別子およびキー値を使用します。
```
dcli -g cell_group -l root "cellcli -e \"ASSIGN KEY FOR 'asm1'='f3d15c0c5e8543
45bcb3c2b678b1de45'
```
Oracle Exadata System Softwareリリース12.2.1.1.0以降、セキュリティがOracle ASMクラスタのみに基づいている場合は、ASSIGN KEYコマンドにASMCLUSTERキーワードを追加します。キーの一意の名前にOracle ASMクラスタ名を指定します。次に例を示します:
```
CellCLI> ASSIGN KEY FOR ASMCLUSTER '+asm1' -
         ='f3d15c0c5e854345bcb3c2b678b1de45
```
ノート:
DBを有効範囲にしたセキュリティを使用する場合は、ASSIGN KEYコマンドにASMCLUSTERキーワードを追加しないでください。
データベース・サーバーで、Oracle Clusterware、Oracle ASMインスタンスおよびOracle Databaseインスタンスを再起動します。
Oracle Clusterwareを停止および起動するコマンドは次のとおりです。
```
# crsctl stop crs
# crsctl start crs
```
次に、Oracle ASMおよびOracle DatabaseインスタンスがOracle Clusterwareによって自動的に起動していない場合は、再起動します。
ステップ3で作成した一時cellkey.oraファイルを削除します。

関連トピック

ASMCLUSTERのASMを有効範囲にしたセキュリティ・キーのアップグレード

親トピック: ASMを有効範囲にしたセキュリティまたはDBを有効範囲にしたセキュリティのセキュリティ・キーの変更

4.4.6.3 DBを有効範囲にしたセキュリティの割当てキー値の変更

DBを有効範囲にしたセキュリティを使用するように構成されたOracle Databaseクライアントによって使用するキー値を変更できます。

セキュリティ構成を変更するOracle Databaseインスタンスを停止します。
CellCLIのCREATE KEYコマンドを使用して、ランダムの16進文字列を生成します。
このコマンドは任意のセルで実行できます。
```
CellCLI> CREATE KEY

          fa292e11b31b210c4b7a24c5f1bb4d32
```
データベース・クライアントのcellkey.oraファイルを更新します。
1. データベース・サーバーの1つで、$ORACLE_HOME/admin/db_unique_name/pfile/cellkey.oraファイルを、Oracleソフトウェア所有者のユーザー・ディレクトリ(たとえば、/home/oradba1/cellkey.ora)にコピーします。
2. データベース・クライアントに新しいキーを使用するようにファイルを更新します。
```
key=fa292e11b31b210c4b7a24c5f1bb4d32
asm=asm1
```
cellkey.oraファイルを各データベース・サーバーの$ORACLE_HOME/admin/db_unique_name/pfileにコピーし、既存のファイルを上書きします。
次のコマンドで、dba1_groupはデータベース・クライアントのインスタンスをホストするデータベース・サーバーの名前を含むファイル、oradba1はOracle Databaseインストールのソフトウェア所有者です。
```
dcli -g dba1_group -l oradba1 -f /home/oradba1/cellkey.ora -d $ORACLE_HOME/admin/
db_unique_name/pfile/cellkey.ora
```
OracleDatabaseソフトウェア所有者のみがファイルにアクセスできるように、$ORACLE_HOME/admin/db_unique_name/pfileでcellkey.oraの権限が構成されていることを確認します。
ファイルの所有者がOracle Databaseソフトウェア所有者であることを確認します。現在のファイル権限がrw------- (600)でない場合は、次のコマンドに示すように権限を変更します。
```
dcli -g dba1_group -l oradba1 chmod 600 $ORACLE_HOME/admin/db_unique_name/
pfile/cellkey.ora
```
ASSIGN KEYコマンドを使用して、データベースで使用されるグリッド・ディスクを含むすべてのセルのOracle Databaseクライアントに割り当てられたセキュリティ・キーを更新します。
データベースにDB_UNIQUE_NAME、データベース・クライアントに新しいキー値を使用します。
```
dcli -g cell_group -l celladmin "cellcli -e \"ASSIGN KEY FOR 'db_unique_name'=
'fa292e11b31b210c4b7a24c5f1bb4d32'
```
データベース・サーバーで、Oracle Databaseインスタンスを再起動します。
ステップ3で作成した一時cellkey.oraファイルを削除します。

4.4.7 Cell-to-Cell操作の有効化

Oracle Exadata Database Machineに対して、ASMを有効範囲にしたセキュリティまたはDBを有効範囲にしたセキュリティを構成した場合は、Cell-to-Cell操作が制限されないようにアクセス制御を構成する必要があります。

セルが直接相互に通信する必要がある場合に、他のセルにアクセスできるようにするには、各セルにセル・キーを設定する必要があります(たとえば、オフロード操作の場合)。

単純セル・アクセスの構成
インバウンドとアウトバウンド両方のCell-to-Cellトラフィックに単一のキーを使用できます。
LOCALおよびREMOTEのセル・キーの構成
一意のキーを持つように各セルを設定すると、アクセス権を付与する複数のリモート・セル・キーを許容できます。
単純セル・キー、LOCALキーおよびREMOTEキー間の変更
新しいキーを別のフォーマットで割り当てる前に、既存のセル・キーを削除する必要があります。これにより、ストレージ・サーバーでリモート・キーとローカル・キーが異なるために誤って構成が中断されるのを防ぎます。

親トピック: Exadata Storage Serverのデータ・セキュリティの構成

4.4.7.1 単純セル・アクセスの構成

インバウンドとアウトバウンド両方のCell-to-Cellトラフィックに単一のキーを使用できます。

セルが直接相互に通信する必要がある場合に、他のセルにアクセスできるようにするには、単一のキーを作成できます(たとえば、オフロード操作の場合)。ASSIGN KEYコマンドの単純なバージョンを使用して、すべてのセルにそのキーを割り当てます。

セル・キーのavailableTo属性の更新にALTER GRIDDISKコマンドを使用する必要はありません。セルで既存のアクセス制御ポリシーを使用するには、リモート・ターゲット・セルで元のクライアントが識別されるようにします。

このステップは、ASMを有効範囲にしたセキュリティまたはDBを有効範囲にしたセキュリティをすでに構成している場合にのみ実行してください。

ランダムの16進文字列を生成します。
このコマンドは任意のセルで実行できます。
```
CellCLI> CREATE KEY
      fa292e11b31b210c4b7a24c5f1bb4d32
```

各セルにキーを割り当てます。

CellCLI> ASSIGN KEY FOR CELL 'fa292e11b31b210c4b7a24c5f1bb4d32'

単一コマンドですべてのセルを更新するには、dcliを使用します。

dcli -g mycells -l celladmin "cellcli -e assign key for cell \'fa292e11b31b210c4b7a24c5f1bb4d32\'"

親トピック: Cell-to-Cell操作の有効化

4.4.7.2 LOCALおよびREMOTEのセル・キーの構成

一意のキーを持つように各セルを設定すると、アクセス権を付与する複数のリモート・セル・キーを許容できます。

セルが直接相互に通信する必要がある場合に、他のセルにアクセスできるようにするには、セル・キーを作成できます(たとえば、オフロード操作の場合)。すべてのセルで使用される単一のキーを作成するか、LOCALキーワードおよびREMOTEキーワードを使用して個々のセルに一意のキーを割り当てることができます。

キー更新中に一時的に複数のセル・キーを使用したり、特定のセルへのアクセスを制限する場合があります。この場合、ASSIGN KEYコマンドでLOCALまたはREMOTEを指定する必要があります。

このステップは、ASMを有効範囲にしたセキュリティまたはDBを有効範囲にしたセキュリティをすでに構成している場合にのみ実行してください。

セルごとにランダムな16進文字列を生成します。

これらのコマンドは任意のセルで実行できます。

Cellcli> CREATE KEY
      fa292e11b31b210c4b7a24c5f1bb4d3

Cellcli> CREATE KEY
      b67d5587fe728118af47c57ab8da650a

Cellcli> CREATE KEY
      118af47c57ab8da650ab67d5587fe728

各セルで、ローカル・セルのキーを設定します。

セルごとに一意の識別子を指定します(cell01、cell02など)。


[celladmin@dm01cel01 ~]$ cellcli -e assign key for local cell -
'cell01'='fa292e11b31b210c4b7a24c5f1bb4d3'
[celladmin@dm01cel02 ~]$ cellcli -e assign key for local cell -
'cell02'='b67d5587fe728118af47c57ab8da650a'
[celladmin@dm01cel03 ~]$ cellcli -e assign key for local cell -
'cell03'='118af47c57ab8da650ab67d5587fe728'

ローカル・セルが受け入れるセル・キーを設定します。

ローカル・セルへのアクセス権を付与するセルごとにASSIGN KEY FOR REMOTE CELLコマンドを使用して、そのセルのローカル・キーを指定します。リモート・キーに任意の名前を指定できます。

[celladmin@dm01cel01 ~]$ cellcli -e assign key for remote cell -
'rcell02'='b67d5587fe728118af47c57ab8da650a', -
'rcell03'='118af47c57ab8da650ab67d5587fe728'

[celladmin@dm01cel02 ~]$ cellcli -e assign key for remote cell -
'rcell01'='fa292e11b31b210c4b7a24c5f1bb4d3', -
'rcell03'='118af47c57ab8da650ab67d5587fe728'


[celladmin@dm01cel03 ~]$ cellcli -e assign key for remote cell -
'rcell01'='fa292e11b31b210c4b7a24c5f1bb4d3', -
'rcell02'='b67d5587fe728118af47c57ab8da650a'

ストレージ・サーバーごとにキーが設定されていることを確認します。

CellCLI> LIST KEY
       db1        c25a62472a160e28bf15a29c162f1d74
       asm1       118af47c57ab8da650ab67d5587fe728      ASMCLUSTER
       cell01     fa292e11b31b210c4b7a24c5f1bb4d32      LOCAL-CELL
       rcell02    b67d5587fe728118af47c57ab8da650a      REMOTE-CELL
       rcell03    118af47c57ab8da650ab67d5587fe728      REMOTE-CELL

親トピック: Cell-to-Cell操作の有効化

4.4.7.3 単純セル・キー、LOCALキーおよびREMOTEキー間の変更

新しいキーを別のフォーマットで割り当てる前に、既存のセル・キーを削除する必要があります。これにより、ストレージ・サーバーでリモート・キーとローカル・キーが異なるために誤って構成が中断されるのを防ぎます。

LOCALまたはREMOTEキーをセル・キーに割り当てようとすると(つまり、すでにASSIGN KEY FOR CELLコマンドを実行しており、明示的にLOCALまたはREMOTEキーに切り替えようとすると)、次のエラーが発生します。

CELL-02911: Remove existing CELL key before assigning LOCAL CELL key

同様に、ローカルまたはリモートのセル・キーがすでに存在する場合にASSIGN KEY FOR CELLを実行すると、次のエラーが表示されます。

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.

単純セル・キーを割り当てる前に、既存のLOCALおよびREMOTEのセル・キーをすべて削除する必要があります。

各ストレージ・サーバーの構成済キーを表示します。

単純セル・キーの場合、次のような結果が表示されます。

CellCLI> LIST KEY
       db1        c25a62472a160e28bf15a29c162f1d74
       asm1       b4095e91d67bbf68d2e2fbe1fc50530f      ASMCLUSTER
       cellkey    fa292e11b31b210c4b7a24c5f1bb4d32      CELL

ローカルおよびリモートのセル・キーの場合、次のような結果が表示されます。

CellCLI> LIST KEY
       db1        c25a62472a160e28bf15a29c162f1d74
       asm1       b4095e91d67bbf68d2e2fbe1fc50530f      ASMCLUSTER
       cell01     fa292e11b31b210c4b7a24c5f1bb4d32      LOCAL-CELL
       rcell02    b67d5587fe728118af47c57ab8da650a      REMOTE-CELL
       rcell03    118af47c57ab8da650ab67d5587fe728      REMOTE-CELL

既存のセル・キーを削除します。

単純セル・キーの場合は、次のようなコマンドを使用します。
```
dcli -g mycells -l celladmin "cellcli -e assign key for cell 'cell01'=''" 
```

ローカルおよびリモートのセル・キーの場合:

各セルのローカル・キーを削除します。

[celladmin@dm01cel01 ~]$ cellcli -e assign key for local cell 'cell01'=''
[celladmin@dm01cel02 ~]$ cellcli -e assign key for local cell 'cell02'=''
[celladmin@dm01cel03 ~]$ cellcli -e assign key for local cell 'cell03'=''

任意のサーバーから次のコマンドを実行して、各セルのリモート・キーを削除します。

dcli -g mycells -l celladmin "cellcli -e assign key for remote cell 'rcell01'=''" 
dcli -g mycells -l celladmin "cellcli -e assign key for remote cell 'rcell02'=''"
dcli -g mycells -l celladmin "cellcli -e assign key for remote cell 'rcell03'=''"

必要な形式でキーを再作成します。
1. 単純セル・キーをローカルおよびリモート・キーに変更するには、「LOCALおよびREMOTEのセル・キーの構成」のステップに従います。
2. ローカルおよびリモート・セル・キーを単純セル・キーに変更するには、「単純セル・アクセスの構成」のステップに従います。

親トピック: Cell-to-Cell操作の有効化

4.4.8 ASMを有効範囲にしたセキュリティまたはDBを有効範囲にしたセキュリティの削除

オープン・セキュリティ・モデルに戻す場合は、ASMを有効範囲にしたセキュリティを削除する前に、グリッド・ディスクのDBを有効範囲にしたセキュリティを削除する必要があります。

セルのセキュリティを更新する前に、Oracle DatabaseおよびOracle ASMインスタンスをシャットダウンする必要があります。セキュリティ構成のすべての変更が完了したら、Oracle DatabaseおよびOracle ASMインスタンスを起動します。

DBを有効範囲にしたセキュリティの削除
ASMを有効範囲にしたセキュリティの削除
ストレージ・サーバー上のグリッド・ディスクにオープン・セキュリティを設定する場合は、DBを有効範囲にしたセキュリティを削除してから、ASMを有効範囲にしたセキュリティを削除できます。

親トピック: Exadata Storage Serverのデータ・セキュリティの構成

4.4.8.1 DBを有効範囲にしたセキュリティの削除

グリッド・ディスクでDBを有効範囲にしたセキュリティを削除するには、次の手順を実行します。

Oracle DatabaseおよびOracle ASMインスタンスをシャットダウンします。
DBを有効範囲にしたセキュリティを削除するグリッド・ディスクのavailableTo属性に名前が指定されているデータベース・クライアントを削除します。例4-7に、これを実行する方法を示します。

ノート:
データベース・クライアントのDBを有効範囲にしたセキュリティを、一部のグリッド・ディスクについてのみではなく、すべて削除する場合は、これ以上のステップを実行しないでください。
データベース・クライアントで他のグリッド・ディスクのセキュリティが設定されていない場合は、ストレージ・サーバーでデータベース・クライアントに割り当てられているキーを削除できます。CellCLIのASSIGN KEYコマンドを使用します。
次のコマンドで、db_clientはデータベース・クライアントの名前です。等号の右側には、間にスペースのない2つの一重引用符文字があります。
```
CellCLI> ASSIGN KEY FOR 'db_client'=''
```
データベース・クライアントでDBを有効範囲にしたセキュリティが不要になった各ストレージ・サーバー(セル)でこのステップを繰り返します。
各データベース・サーバーで、データベース・クライアントの$ORACLE_HOME/admin/db_unique_name/pfile/ディレクトリにあるcellkey.oraファイルを削除します。

ストレージ・サーバーでキー割当てが更新されたことを検証します。

CellCLI> LIST KEY
        asm1    66e12adb996805358bf82258587f5050
        db2     cf03b74de32a67a6c1ec87b9da72bd47

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

Oracle DatabaseおよびOracle ASMインスタンスを再起動します。

例4-7 グリッド・ディスクからのデータベース・クライアントの削除

次のコマンドでは、すべてのデータベース・クライアントをグリッド・ディスクのグループから削除します。

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'

DBを有効範囲にしたセキュリティ用に複数のデータベース・クライアント(db1、db2、db3など)が構成されており、そのうち1つのクライアント(たとえば、db1)のセキュリティのみを削除する場合、グリッド・ディスクのグループに対して次のようなコマンドを使用できます。

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'

次の例では、すべてのグリッド・ディスクからすべてのデータベース・クライアントを削除します。

ALTER GRIDDISK ALL availableTo='+asm'

ノート:

グリッド・ディスクとストレージ・サーバーにオープン・セキュリティを設定する場合は、DBを有効範囲にしたセキュリティを削除してから、ASMを有効範囲にしたセキュリティを削除する必要があります。

関連トピック

ASMを有効範囲にしたセキュリティの削除

親トピック :ASMを有効範囲にしたセキュリティまたはDBを有効範囲にしたセキュリティの削除

4.4.8.2 ASMを有効範囲にしたセキュリティの削除

ストレージ・サーバー上のグリッド・ディスクにオープン・セキュリティを設定する場合は、DBを有効範囲にしたセキュリティを削除してから、ASMを有効範囲にしたセキュリティを削除できます。

Oracle DatabaseおよびOracle ASMインスタンスをシャットダウンします。
LIST KEYコマンドを使用して、Oracle ASMクライアントに使用される一意の別名を表示します。
このコマンドは、Oracle ASMクライアントにASMを有効範囲にしたセキュリティが構成されている任意のストレージ・サーバーで実行します。
```
CellCLI> LIST KEY
        asm1    66e12adb996805358bf82258587f5050
        db2     cf03b74de32a67a6c1ec87b9da72bd47
```
ASMを有効範囲にしたセキュリティを削除するグリッド・ディスクのavailableTo属性に名前が指定されているOracle ASMクライアントを削除します。

ステップ2から別名を使用します。例4-8に、これを実行する方法を示します。
Oracle ASMクライアントで他のグリッド・ディスクのセキュリティが設定されていない場合は、ストレージ・サーバーでOracle ASMクライアントに割り当てられているキーを削除できます。CellCLIのASSIGN KEYコマンドを使用します。
1. ステップ2のOracle ASMクライアントが、キー値の右側にASMCLUSTER指定を示すかどうかを決定します。
2. ASSIGN KEYコマンドのASMCLUSTERキーワードは、Oracle ASMクライアントがASMCLUSTERとしてリストされている場合にのみ使用します。
次のコマンドでは、asm_clusterはステップ2の別名です。等号の右側には、間にスペースのない2つの一重引用符文字があります。
```
CellCLI> ASSIGN KEY FOR ASMCLUSTER 'asm_cluster'=''
```
このコマンドは、Oracle ASMクライアントにキーが割り当てられたすべてのストレージ・サーバーで実行してください。かわりに、次のようなコマンドを使用することもできます。
```
dcli -g cell_group -l celladmin "cellcli -e \"ASSIGN KEY FOR ASMCLUSTER 'asm_cluster'=''\""
```
cellkey.oraファイルを更新または削除します。

各データベース・サーバーの/etc/oracle/cell/network-config/ディレクトリにあるcellkey.oraファイルを表示します。

ASMを有効範囲にしたセキュリティを削除するOracle ASMクライアントがファイルにリストされている唯一のクライアントである場合は、すべてのサーバー上で、同じファイルの内容を持つcellkey.oraファイルを削除します。

cellkey.oraファイルにOracle ASMクライアントが複数リストされている場合は、次のステップを実行します。
1. ASMを有効範囲にしたセキュリティを削除するOracle ASMクライアントのエントリを削除します。
2. cellkey.oraファイルにOracle ASMクライアントをリストするすべてのサーバーについて、このファイルをそれらのサーバーにコピーするか、それらのサーバー上のファイルを更新します。
ストレージ・サーバーでキー割当てが更新されたことを検証します。
```
CellCLI> LIST KEY
```
```
CellCLI> LIST GRIDDISK ATTRIBUTES name,availableTo WHERE availableTo != ''
```
Oracle DatabaseおよびOracle ASMインスタンスを再起動します。

例4-8 グリッド・ディスクからのOracle ASMクライアントの削除

次のコマンドでは、Oracle ASMクライアントをセルのすべてのグリッド・ディスクから削除します。

CellCLI> ALTER GRIDDISK ALL availableTo=''

次のコマンドでは、Oracle ASMクライアントをセルのグループのすべてのグリッド・ディスクから削除します。

dcli -g cell_group -l celladmin "cellcli -e \"ALTER GRIDDISK ALL availableTo=''\""

次のコマンドでは、Oracle ASMクライアントをセルのグリッド・ディスクのグループから削除します。

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