1. Exadata Database Machineセキュリティ・ガイド
  2. Oracle Exadata Database Machineの保護

4 Oracle Exadata Database Machineの保護

この章では、Oracle Exadata Database Machineをセキュアに保つためのポリシーと手順について説明します。

  • ハードウェアの保護
    Oracle Exadata Database Machineのインストール後、ハードウェアを保護する必要があります。
  • ソフトウェアの保護
    多くの場合、ハードウェアのセキュリティは、ソフトウェアを通じて実装されます。
  • Exadata Storage Serverのデータ・セキュリティの構成
    Oracle Exadata Storage Serverのデータ・セキュリティは、ストレージ・セル上の特定のグリッド・ディスクにアクセスできるOracle Automatic Storage Management (Oracle ASM)クラスタおよびOracle Databaseクライアントを制御することにより実装されます。
  • セキュアな環境の維持
    セキュリティ措置を実装した後、それらを維持してシステムをセキュアに保つ必要があります。

4.1 ハードウェアの保護

Oracle Exadata Database Machineのインストール後、ハードウェアを保護する必要があります。

ハードウェアは、ハードウェアへのアクセスを制限し、シリアル番号を記録することによって保護できます。アクセスを制限する措置として、次のことをお薦めします。

  • Oracle Exadata Database Machineと関連装置は、アクセスが制限された鍵の掛かった部屋に設置します。

  • ラック内のコンポーネントでサービスが必要でない場合は、ラックのドアに鍵を掛けます。

  • コンポーネントは設計によって容易に削除できるため、ホットプラガブル対応またはホットスワップ対応デバイスへのアクセスを制限します。参照

  • 予備の現場交換可能ユニット(FRU)または顧客交換可能ユニット(CRU)は鍵の掛かったキャビネットに保管します。鍵の掛かったキャビネットへは、認可された人のみがアクセスできるように制限します。

  • SSHリスナー・ポートを管理ネットワークおよびプライベート・ネットワークに制限します。

  • SSHプロトコル2 (SSH-2)およびFIPS 140-2承認暗号を使用します。

  • SSHが許可される認証メカニズムを制限します。本質的にセキュアでない方法は無効化されます。

  • すべての主要なコンピュータ・ハードウェア項目(FRUなど)にマークを付けます。

  • ハードウェアのアクティベーション・キーとライセンスは、システム緊急時にシステム・マネージャが簡単に取り出せる安全な場所に保管します。

  • Oracle Exadata Database Machineのコンポーネントのシリアル番号を記録し、安全な場所に保管します。Oracle Exadata Database Machineのすべてのコンポーネントにシリアル番号があります。

関連項目

親トピック: Oracle Exadata Database Machineの保護

4.2 ソフトウェアの保護

多くの場合、ハードウェアのセキュリティは、ソフトウェアを通じて実装されます。

ソフトウェアとハードウェアを保護するには、次のガイドラインを実施します。

  • サイトでシステムをインストールしたときに、すべてのデフォルトのパスワードを変更してください。Oracle Exadata Database Machineでは、初期インストールおよびデプロイメントに、よく知られたデフォルトのパスワードが使用されます。デフォルトのパスワードでは、装置に不正にアクセスできる可能性があります。ネットワーク・スイッチなどのデバイスには、複数のユーザー・アカウントが設定されています。必ずラック内のコンポーネントのすべてのアカウント・パスワードを変更します。

  • rootスーパーユーザー・アカウントの使用を制限します。Integrated Lights Out Manager (ILOM)ユーザー・アカウントを各ユーザーに作成および使用して、監査証跡での積極的な識別を可能にし、管理者がチームまたは会社を離れた場合のメンテナンスを軽減します。

  • Oracle Exadata Database Machineが、Oracle Grid InfrastructureとOracle Databaseソフトウェアのインストールに個別のソフトウェア所有者アカウントを使用してデプロイされるようにします。

    注意:

    DBを有効範囲にしたセキュリティを有効にするには、Oracle Grid InfrastructureとOracle Databaseソフトウェアのインストール用に個別のソフトウェア所有者アカウントが必要です。

  • 不要なプロトコルおよびモジュールをオペレーティング・システムで無効化します。

  • USBポート、ネットワーク・ポートおよびシステム・コンソールへの物理的なアクセスを制限します。サーバーおよびネットワーク・スイッチには、システムに直接アクセスできるポートおよびコンソール接続があります。

  • ネットワークを介してシステムを再起動する機能を制限します。

  • ドキュメントを参照し、使用可能なセキュリティ機能を有効化します。

Oracle Exadata Database Machineは、レガシー・プラットフォームにインストールされたOracle Databaseリリースで使用できるすべてのセキュリティ機能を活用できます。Oracle Databaseのセキュリティ製品および機能には次のものがあります。

  • Oracle Advanced Security

  • Oracle Audit Vault

  • データ・マスキング

  • Oracle Database Firewall

  • Oracle Database Vault

  • Oracle Label Security

  • Oracle Secure Backup

  • Oracle Total Recall

Oracle特権ユーザーおよび多元的なアクセス制御、データ分類、透過的データ暗号化、監査、監視およびデータ・マスキングを使用して、顧客は既存のアプリケーションに対する変更を必要としない信頼性の高いデータ・セキュリティ・ソリューションをデプロイできます。

関連項目

親トピック: Oracle Exadata Database Machineの保護

4.3 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インスタンスに共有ストレージ・プールを提供します。

親トピック: Oracle Exadata Database Machineの保護

4.3.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の説明は図の下のリンクをクリックしてください。
「図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.3.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ユーティリティを使用して構成を変更し、一貫性を確保してユーザー・エラーの可能性を排除します。

関連項目

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

4.3.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の説明は図の下のリンクをクリックしてください。
「図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-1 Exadata Storage Securityのセキュリティ・キーの作成

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

CellCLI> CREATE KEY
         66e12adb996805358bf82258587f5050

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

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

key=66e12adb996805358bf82258587f5050
asm=cluster1

関連項目

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

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

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

次の手順では、単一のOracle ASMクラスタと、そのOracle ASMクラスタのクライアントであるデータベースに対して、ASMを有効範囲にしたセキュリティを構成します。これらの手順の例では、Oracle ASMソフトウェア所有者がユーザーgridであることを前提としています。
  1. Oracle DatabaseおよびOracle ASMインスタンスをシャットダウンします。
  2. ストレージ・サーバーの1つで、CellCLIのCREATE KEYコマンドを使用してランダムな16進文字列を生成します。このコマンドは、任意のストレージ・サーバーで実行できます。
    CellCLI> CREATE KEY

66e12adb996805358bf82258587f5050
  3. データベース・サーバーの1つで、cellkey.oraファイルにキーをコピーします。
    1. ソフトウェア所有者のホーム・ディレクトリにcellkey.oraを作成します(たとえば、/home/grid/cellkey.ora)。
    2. 次に示す形式(cluster1はOracle ASMクラスタの別名)を使用して、cellkey.oraファイルにキーを追加します。

      別名は、ストレージ・サーバーにアクセスするすべてのクラスタ間で一意である必要があります。Oracle Clusterwareのクラスタ名は、クラスタが一意名を持つ場合に使用できます。 

      key=66e12adb996805358bf82258587f5050
asm=cluster1
  4. 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'\""
  5. 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属性に値がない場合、クライアントはそれらのグリッド・ディスクにアクセスできます。

  6. ストレージ・サーバーでキー割当てを検証します。
    CellCLI> LIST KEY
    CellCLI> LIST GRIDDISK ATTRIBUTES name,availableTo
  7. 手順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
  8. 各データベース・サーバーで、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 600 /etc/oracle/cell/network-config/cellkey.ora

    • すべてのOracleソフトウェアで単一のインストール・ユーザーを使用する場合は、ファイルの権限をソフトウェア所有者の読取り専用に設定します(たとえば、oracle)。 

      chown oracle:oinstall /etc/oracle/cell/network-config/cellkey.ora
chmod 600 /etc/oracle/cell/network-config/cellkey.ora
  9. データベース・サーバーで、Oracle Clusterware、Oracle ASMインスタンスおよびOracle Databaseインスタンスを再起動します。

    Oracle Clusterwareを停止および起動するコマンドは次のとおりです。 

    # crsctl stop crs
# crsctl start crs

    次に、Oracle ASMおよびOracle Databaseインスタンスが自動的に起動していない場合は再起動します。

  10. 手順3で作成した一時cellkey.oraファイルを削除します。

関連項目

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

4.3.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ディスク・グループにのみ割り当てることができます。
  1. 各データベースのDB_UNIQUE_NAMEを取得します。名前は、大文字と小文字が区別されます。
    SQL> SELECT db_unique_name FROM V$DATABASE;
  2. Oracle ASMクラスタのデータベースおよびOracle ASMインスタンスを停止します。
  3. ストレージ・サーバーの1つで、CellCLIのCREATE KEYコマンドを使用してOracle ASMのキーと、Oracle Databaseクライアントのキーを生成します。

    このコマンドは、任意のストレージ・サーバーで実行できます。

    CellCLI> CREATE KEY
        66e12adb996805358bf82258587f5050

CellCLI> CREATE KEY
        f3f21c625ff41ef479a1bb033e0839e5

CellCLI> CREATE KEY
        cf03b74de32a67a6c1ec87b9da72bd47
  4. 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
  5. 各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を有効範囲にしたセキュリティの両方で使用されます。
  6. 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'\""
  7. 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'\""
  8. データベース・クライアントがアクセスするすべてのストレージ・サーバーでグリッド・ディスクにセキュリティを構成します。
    セキュリティ・キーは、グリッド・ディスクの作成時に、または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属性の値がない場合は、どのクライアントもグリッド・ディスクにアクセスできます。

  9. ストレージ・サーバーでキー割当てを検証します。
    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. 手順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
  11. 各データベース・サーバーで、Oracle ASMのcellkey.oraファイルに対する権限をファイルの所有者およびグループによる読取り専用に設定します。

    dcliを使用すると、単一のコマンドで複数のサーバーにファイル権限を構成できます。次の例では、dbs_groupは、Oracle ASMクラスタのクライアントであるデータベース・サーバーのリストを含むファイルです。 

    dcli -g dbs_group -l grid chmod 640 /etc/oracle/cell/network-config/
cellkey.ora
  12. 手順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
  13. 各データベース・サーバーで、各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
  14. データベース・サーバーで、Oracle Clusterware、Oracle ASMインスタンスおよびOracle Databaseインスタンスを再起動します。

    Oracle Clusterwareを停止および起動するコマンドは次のとおりです。 

    # crsctl stop crs
# crsctl start crs

    次に、Oracle ASMおよびOracle DatabaseインスタンスがOracle Clusterwareによって自動的に起動していない場合は、再起動します。

  15. 手順4および手順5で作成した一時cellkey.oraファイルを削除します。

関連項目

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

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

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

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

4.3.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キーに変更する場合は、次の手順を実行します。

  1. ASMCLUSTERキーにアップグレードするキー値を取得します。
    $ dcli -c dm01cel01,dm01cel02,dm01cel03 cellcli -e list key
dm01cel01:      asm1   118af47c57ab8da650ab67d5587fe728
dm01cel02:      asm1   118af47c57ab8da650ab67d5587fe728
dm01cel03:      asm1   118af47c57ab8da650ab67d5587fe728
  2. 同じキー値を使用し、ただしASMCLUSTERキーワードを追加して、ASSIGN KEYコマンドを再発行します。
    $ dcli -c dm01cel01,dm01cel02,dm01cel03 "cellcli -e assign key for ASMCLUSTER
 \'asm1\'=\'118af47c57ab8da650ab67d5587fe728\'"

    名前およびキーは、ASMを有効範囲にしたセキュリティ・リストから削除され、Oracle ASMクラスタ・クライアントとして追加されます。ACLのこのOracle ASMクライアントを含むグリッド・ディスクは、この操作に対してオンラインのままにできます。

  3. キーがASMCLUSTERキーにアップグレードされていることを確認してください。
    $ dcli -c dm01cel01,dm01cel02,dm01cel03 cellcli -e list key
dm01cel01:      asm1   118af47c57ab8da650ab67d5587fe728      ASMCLUSTER
dm01cel02:      asm1   118af47c57ab8da650ab67d5587fe728      ASMCLUSTER
dm01cel03:      asm1   118af47c57ab8da650ab67d5587fe728      ASMCLUSTER
4.3.6.2 ASMを有効範囲にしたセキュリティに割り当てられたキー値の変更

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

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

          f3d15c0c5e854345bcb3c2b678b1de45
  3. cellkey.oraファイルを更新します。
    1. データベース・サーバーの1つで、/etc/oracle/cell/network-config/cellkey.oraファイルをグリッド所有者のホーム・ディレクトリ(たとえば、/home/grid/cellkey.ora)にコピーします。
    2. Oracle ASMクライアントに新しいキーを使用するようにファイルを更新します。
      key=f3d15c0c5e854345bcb3c2b678b1de45
asm=asm1
  4. 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
  5. 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
  6. 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キーワードを追加しないでください。
  7. データベース・サーバーで、Oracle Clusterware、Oracle ASMインスタンスおよびOracle Databaseインスタンスを再起動します。

    Oracle Clusterwareを停止および起動するコマンドは次のとおりです。 

    # crsctl stop crs
# crsctl start crs

    次に、Oracle ASMおよびOracle DatabaseインスタンスがOracle Clusterwareによって自動的に起動していない場合は、再起動します。

  8. 手順3で作成した一時cellkey.oraファイルを削除します。
4.3.6.3 DBを有効範囲にしたセキュリティの割当てキー値の変更

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

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

          fa292e11b31b210c4b7a24c5f1bb4d32
  3. データベース・クライアントのcellkey.oraファイルを更新します。
    1. データベース・サーバーの1つで、$ORACLE_HOME/admin/db_unique_name/pfile/cellkey.oraファイルを、Oracleソフトウェア所有者のユーザー・ディレクトリ(たとえば、/home/oradba1/cellkey.ora)にコピーします。
    2. データベース・クライアントに新しいキーを使用するようにファイルを更新します。
      key=fa292e11b31b210c4b7a24c5f1bb4d32
asm=asm1
  4. 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
  5. 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
  6. ASSIGN KEYコマンドを使用して、データベースで使用されるグリッド・ディスクを含むすべてのセルのOracle Databaseクライアントに割り当てられたセキュリティ・キーを更新します。

    データベースにDB_UNIQUE_NAME、データベース・クライアントに新しいキー値を使用します。 

    dcli -g cell_group -l celladmin "cellcli -e \"ASSIGN KEY FOR 'db_unique_name'=
'fa292e11b31b210c4b7a24c5f1bb4d32'
  7. データベース・サーバーで、Oracle Databaseインスタンスを再起動します。
  8. 手順3で作成した一時cellkey.oraファイルを削除します。

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

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

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

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

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

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

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

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

この手順は、ASMを有効範囲にしたセキュリティまたはDBを有効範囲にしたセキュリティをすでに構成している場合にのみ実行してください。
  1. ランダムの16進文字列を生成します。
    このコマンドは任意のセルで実行できます。
    CellCLI> CREATE KEY
      fa292e11b31b210c4b7a24c5f1bb4d32
  2. 各セルにキーを割り当てます。
    CellCLI> ASSIGN KEY FOR CELL 'fa292e11b31b210c4b7a24c5f1bb4d32'

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

    dcli -g mycells -l celladmin "cellcli -e assign key for cell \'fa292e11b31b210c4b7a24c5f1bb4d32\'"
4.3.7.2 LOCALおよびREMOTEのセル・キーの構成

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

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

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

この手順は、ASMを有効範囲にしたセキュリティまたはDBを有効範囲にしたセキュリティをすでに構成している場合にのみ実行してください。
  1. セルごとにランダムな16進文字列を生成します。
    これらのコマンドは任意のセルで実行できます。
    Cellcli> CREATE KEY
      fa292e11b31b210c4b7a24c5f1bb4d3

Cellcli> CREATE KEY
      b67d5587fe728118af47c57ab8da650a

Cellcli> CREATE KEY
      118af47c57ab8da650ab67d5587fe728
  2. 各セルで、ローカル・セルのキーを設定します。
    セルごとに一意の識別子を指定します(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'
  3. ローカル・セルが受け入れるセル・キーを設定します。
    ローカル・セルへのアクセス権を付与するセルごとに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'
  4. ストレージ・サーバーごとにキーが設定されていることを確認します。
    CellCLI> LIST KEY
       db1        c25a62472a160e28bf15a29c162f1d74
       asm1       118af47c57ab8da650ab67d5587fe728      ASMCLUSTER
       cell01     fa292e11b31b210c4b7a24c5f1bb4d32      LOCAL-CELL
       rcell02    b67d5587fe728118af47c57ab8da650a      REMOTE-CELL
       rcell03    118af47c57ab8da650ab67d5587fe728      REMOTE-CELL
4.3.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のセル・キーをすべて削除する必要があります。

  1. 各ストレージ・サーバーの構成済キーを表示します。
    1. 単純セル・キーの場合、次のような結果が表示されます。
      CellCLI> LIST KEY
       db1        c25a62472a160e28bf15a29c162f1d74
       asm1       b4095e91d67bbf68d2e2fbe1fc50530f      ASMCLUSTER
       cellkey    fa292e11b31b210c4b7a24c5f1bb4d32      CELL
    2. ローカルおよびリモートのセル・キーの場合、次のような結果が表示されます。
      CellCLI> LIST KEY
       db1        c25a62472a160e28bf15a29c162f1d74
       asm1       b4095e91d67bbf68d2e2fbe1fc50530f      ASMCLUSTER
       cell01     fa292e11b31b210c4b7a24c5f1bb4d32      LOCAL-CELL
       rcell02    b67d5587fe728118af47c57ab8da650a      REMOTE-CELL
       rcell03    118af47c57ab8da650ab67d5587fe728      REMOTE-CELL
  2. 既存のセル・キーを削除します。
    1. 単純セル・キーの場合は、次のようなコマンドを使用します。
      dcli -g mycells -l celladmin "cellcli -e assign key for cell 'cell01'=''"
    2. ローカルおよびリモートのセル・キーの場合:
      各セルのローカル・キーを削除します。
      [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'=''"
  3. 必要な形式でキーを再作成します。
    1. 単純セル・キーをローカルおよびリモート・キーに変更するには、「LOCALおよびREMOTEのセル・キーの構成」の手順に従います。
    2. ローカルおよびリモート・セル・キーを単純セル・キーに変更するには、「単純セル・アクセスの構成」の手順に従います。

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

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

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

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

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

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

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

    注意:

    データベース・クライアントのDBを有効範囲にしたセキュリティを、一部のグリッド・ディスクについてのみではなく、すべて削除する場合は、これ以上の手順を実行しないでください。
  3. データベース・クライアントで他のグリッド・ディスクのセキュリティが設定されていない場合は、ストレージ・サーバーでデータベース・クライアントに割り当てられているキーを削除できます。CellCLIのASSIGN KEYコマンドを使用します。

    次のコマンドで、db_clientはデータベース・クライアントの名前です。等号の右側には、間にスペースのない2つの一重引用符文字があります。 

    CellCLI> ASSIGN KEY FOR 'db_client'=''

    データベース・クライアントでDBを有効範囲にしたセキュリティが不要になった各ストレージ・サーバー(セル)でこの手順を繰り返します。

  4. 各データベース・サーバーで、データベース・クライアントの$ORACLE_HOME/admin/db_unique_name/pfile/ディレクトリにあるcellkey.oraファイルを削除します。
  5. ストレージ・サーバーでキー割当てが更新されたことを検証します。
    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
...
  6. Oracle DatabaseおよびOracle ASMインスタンスを再起動します。

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

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

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を有効範囲にしたセキュリティを削除する必要があります。
4.3.8.2 ASMを有効範囲にしたセキュリティの削除

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

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

    手順2から別名を使用します。例4-4に、これを実行する方法を示します。

  4. 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'=''\""
  5. 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クライアントをリストするすべてのサーバーについて、このファイルをそれらのサーバーにコピーするか、それらのサーバー上のファイルを更新します。
  6. ストレージ・サーバーでキー割当てが更新されたことを検証します。
    CellCLI> LIST KEY
    CellCLI> LIST GRIDDISK ATTRIBUTES name,availableTo WHERE availableTo=!''
  7. Oracle DatabaseおよびOracle ASMインスタンスを再起動します。

例4-4 グリッド・ディスクからの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=''

4.4 セキュアな環境の維持

セキュリティ措置を実装した後、それらを維持してシステムをセキュアに保つ必要があります。

ソフトウェア、ハードウェアおよびユーザー・アクセスを定期的に更新およびレビューする必要があります。たとえば、組織はOracle Exadata Database Machineにアクセスできるユーザーと管理者、およびそのデプロイされたサービスをレビューし、アクセスおよび権限のレベルが適切であるかどうかを確認する必要があります。レビューしない場合、ロールの変更やデフォルト設定の変更によって、個人に付与されたアクセス・レベルが意図せず高くなることがあります。操作および管理タスクのアクセス権をレビューして、各ユーザーのアクセス・レベルがロールおよび職責に合わせて調整されていることを確認してください。

組織で未認可の変更や構成のずれを検出するツールを活用し、セキュリティ・アップデートの準備を整えることをお薦めします。Oracle Enterprise Managerは、ハードウェア、デプロイされたアプリケーションおよびサービスの操作の問題に対処する統合されたソリューションを提供します。

関連項目

親トピック: Oracle Exadata Database Machineの保護

4.4.1 ネットワーク・セキュリティの維持

セキュリティ・ガイドラインに基づいてネットワークを構成した後は、定期的なレビューおよびメンテナンスが必要です。

管理ネットワーク・スイッチの構成ファイルはオフラインで管理し、構成ファイルへのアクセスは認可された管理者のみに制限する必要があります。構成ファイルには各設定の説明がコメントとして含まれています。構成ファイルの静的コピーをソース・コード制御システムに保持することを検討してください。セキュアなホスト設定およびIntegrated Lights Out Manager (ILOM)設定を変更せず、有効なままにしておくには、クライアント・アクセス・ネットワークの定期的なレビューが必要です。さらに、設定の定期的なレビューによって、それらが変更されておらず、有効であることが確認されます。

システムへのローカル・アクセスとリモート・アクセスのセキュリティを確保するために、次のガイドラインに従ってください。

  • 未認可アクセスを禁止することを明記したログイン・バナーを作成します。

  • 必要に応じて、アクセス制御リストを使用して制限を適用します。

  • 拡張セッションのタイムアウトを設定し、特権レベルを設定します。

  • スイッチへのローカル・アクセスとリモート・アクセスには、認証、認可、アカウンティング(AAA)機能を使用します。

  • 侵入検知システム(IDS)のアクセスには、スイッチのポートのミラー化機能を使用します。

  • MACアドレスに基づいてアクセスを制限するには、ポート・セキュリティを実装します。Oracle Exadata Database Machineに接続されたスイッチのすべてのポートで自動トランキングを無効化します。

  • リモート構成を特定のIPアドレスに制限するときは、SSHを使用します。

  • 最小限のパスワードの複雑度ルールとパスワードの有効期限ポリシーを設定することによって、ユーザーに強力なパスワードを使用することを要求します。

  • ロギングを有効にし、専用のセキュアなログ・ホストにログを送信します。

  • NTPおよびタイムスタンプを使用して正確な時間情報を含めるようにロギングを構成します。

  • 可能性があるインシデントをログで確認し、組織のセキュリティ・ポリシーに従ってそれらをアーカイブします。

標準のFIPS 140 (連邦情報処理標準)はセキュリティと暗号化に関連しています。FIPS 140は、米国商務省の米国標準技術局(National Institute of Standards and Technology: NIST)によって発行されている一連の標準です。FIPS 140は遷移中のデータおよび保存データを保護します。コンピューティング環境内における暗号化コンポーネントのセキュリティ標準を規定します。FIPS 140は、コンピューティング環境が公開されたセキュリティ・レベルに準拠していることを文書化する必要のある組織にとって役立ちます。多数の政府機関や金融機関でFIPS 140認定システムが使用されています。

Oracle DatabaseレベルでFIPS 140を構成すると、Secure Sockets Layer (SSL)、透過的データ暗号化(TDE)、DBMS_CRYPTO PL/SQLパッケージおよびExadata Smart ScanでFIPS 140暗号モジュールを使用できるようになります。これにより、Smart Scanのオフロード操作の処理中にデータが保護されます。

関連項目

親トピック: セキュアな環境の維持

4.4.2 未認可のオペレーティング・システム・アクセスに対するガード

AIDEは、システム上にファイルのデータベースを作成し、そのデータベースを使用してファイルの整合性を確認して、システム侵入を検出するユーティリティです。

親トピック: セキュアな環境の維持

4.4.2.1 Advanced Intrusion Detection Environment (AIDE)について

AIDEは、システムが侵害された場合に影響を受けるファイルを追跡するのに役立ちます。

AIDEは、特定のディレクトリのファイルに対する変更についてシステムをモニターするdaily cronジョブを実行します。構成ファイルで指定されたルールによって定義されているシステム内のすべてのファイルのスナップショットを取得します。AIDEは、現在のファイルと、以前に取得されたファイルのスナップショットを比較します。スナップショット・ファイルのコンテンツが変更されると、AIDEは自動的にCRITICALソフトウェア・アラートを生成します。AIDEでは、デフォルトのアラート宛先電子メールが使用され、構成されたSMTP電子メール・アドレスにアラート電子メールが送信されます。日次のAIDEスキャンの結果は、/var/log/aide/aide.logに書き込まれます。

AIDEで作成されたファイル・スナップショット・データベースは、/var/lib/aide/aide.db.gzに格納されます。特定のシステムで行われる処理を毎日監査する場合は、このファイルを毎日バックアップできます。

4.4.2.2 AIDEコンポーネントの管理

AIDEを管理するには、exadataAIDEユーティリティを使用できます。

AIDEは、Exadata System Softwareリリース19.1では事前構成されています。この機能を使用するのに、設定タスクを実行する必要はありません。

exadataAIDEの構文

このユーティリティは/opt/oracle.SupportTools/exadataAIDEにあります。 

exadataAIDE [-s|-status] [-e|enable] [-d|disable] [-u|-update] [-h|help]

構文オプションの説明:

  • -s[tatus]: AIDE daily cronジョブの現在のステータスを出力します
  • -e[nable]: AIDE daily cronジョブを有効にします
  • -d[isable]: AIDE daily cronジョブを無効にします
  • -u[pdate]: AIDEデータベース・メタデータを更新し、日次スキャンを実行します
  • -h[elp]: コマンド構文とヘルプ情報を出力します
  • aide cronジョブの現在のステータスを取得します。
    exadataAIDE –status
  • 日次AIDEスキャンを無効にします。
    exadataAIDE –disable
  • 日次AIDEスキャンを有効にします。
    exadataAIDE –enable
  • システムの変更後にAIDEデータベースを更新します。
    exadataAIDE –update
4.4.2.3 カスタムAIDEルールの追加

AIDEのメタデータの初期化ステップおよび日次cronチェック中に特定のディレクトリの変更をチェックしないように、AIDEに指示できます。

  1. サーバーまたは仮想マシンにrootユーザーとしてログインします。
  2. ファイル/etc/aide.confを編集します。
    AIDEがスキャン中にスキップするディレクトリを追加します。ディレクトリ・パスに感嘆符で接頭辞を付けます。
    # Ignore /opt/myapp directory content
!/opt/myapp
  3. AIDEデータベース・メタデータを更新します。
    # /opt/oracle.SupportTools/exadataAIDE -u
AIDEでは、先行する/opt/myappディレクトリの内容の変更に関するアラートは発生しません。
4.4.2.4 Exadataソフトウェア更新時のAIDEアラートの管理

ソフトウェアおよびハードウェアの更新とインストールは、オペレーティング・システム・ファイルのサイズおよび性質を変更する傾向があります。したがって、変更後にはAIDEデータベースを再生成する必要があります。

ソフトウェアの更新時に偽のアラームを削減するには、次の手順を実行します。

注意:

Oracle Exadata Deployment Assistant(OEDA)には、ソフトウェアのインストールまたは更新時に誤ったアラートを回避するためのインテリジェンスが組み込まれています。
  1. AIDEモニタリングを無効にします。
    exadataAIDE –disable
  2. システム上のソフトウェアを更新します。
  3. AIDEモニタリングを再度有効にします。
    exadataAIDE –enable
  4. 最近のファイル変更でAIDEデータベースを更新します。
    exadataAIDE –update

4.4.3 ソフトウェアおよびファームウェアの更新

効果的でプロアクティブなソフトウェア管理はシステム・セキュリティの重要な部分です。

新しいリリースとソフトウェア・アップデートを介して、セキュリティの強化が導入されます。ソフトウェアの最新のリリース、およびすべての必要なセキュリティ・アップデートを装置にインストールすることをお薦めします。Oracle推奨パッチおよびセキュリティ・アップデートを適用することは、ベースライン・セキュリティを確立するためのベスト・プラクティスです。

Oracle Exadata Storage Serverオペレーティング・システムおよびカーネルの更新は、Oracle Exadata System Softwareの更新によって行われます。Oracle Exadata Database Machineデータベース・サーバーは、yum機能を使用して更新されます。配電ユニット(PDU)ファームウェアの更新は、ソフトウェアおよび他のファームウェアの更新とは別に処理されます。PDUでOracle Exadata Database Machineの最新の承認済ファームウェアが動作していることを確認してください。PDUファームウェアの更新は頻繁には発行されないため、通常は、Oracle Exadata System Softwareのアップグレード時にPDUファームウェア・リリースをチェックすれば十分です。

注意:

ネットワーク・スイッチなどのデバイスに搭載されたファームウェアには、パッチやファームウェア更新が必要なものもあります。

関連項目

親トピック: セキュアな環境の維持

4.4.4 Oracle Exadata Database Machine外部のデータ・セキュリティの確保

Oracle Exadata Database Machineの外部に格納されているデータは、バックアップまたは取外し可能なハード・ドライブで保護することが重要です。

Oracle Exadata Database Machineの外部にあるデータは、重要なデータをバックアップすることによって保護できます。その後、データをオフサイトの安全な場所に保管する必要があります。組織のポリシーおよび要件に従ってバックアップを保持します。

古いハード・ドライブを廃棄するときは、ドライブを物理的に破壊するか、ドライブ上のすべてのデータを完全に消去してください。ファイルを削除したり、ドライブを再フォーマットしても、ドライブ上のアドレス・テーブルのみが削除されます。ファイルが削除されたり、ドライブが再フォーマットされた後でも、情報はドライブから回復できます。Oracle Exadata Database Machineのディスク保存サポート・オプションを使用すると、置き換えたすべてのハード・ドライブとフラッシュ・ドライブをオラクル社に返却しないで保存できます。

CellCLIのDROP CELLDISKコマンドには、データを上書きすることによってデータをセキュアに消去するオプションが含まれています。Oracle Exadata Storage Serverドライブに再デプロイメントまたは別の目的で消去する必要がある機密データが含まれている場合は、ストレージ・セルでセキュアな消去機能を使用する必要があります。ERASEオプションによって、すべてのデータがランダム・データで上書きされ、最大7回消去されます。これにより、確実にデータが回復できなくなり、データは完全に消去されます。

Oracle Exadata System Softwareリリース19.1.0以降では、DROP CELLDISKを使用し、1パス、3パスまたは7パス方式を使用してディスクを消去する場合、基礎となるハードウェアでサポートされていれば、Oracle Exadata System Softwareが、より適切で高速なSecure Eraserを使用します。

親トピック: セキュアな環境の維持