プライマリ・コンテンツに移動
Oracle® Exadata System Softwareユーザーズ・ガイド
18.1.0
E84909-07
目次へ移動
目次

前
次

4 Oracle Exadata System Softwareのセキュリティ構成

この章は、Oracle Exadata System Softwareのセキュリティを構成する方法について説明します。

この章のトピックは、次のとおりです:

4.1 Oracle Exadata System Softwareのデータ・セキュリティの理解

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

  • Oracle ASMクラスタのすべてのデータベース・クライアントで特定のグリッド・ディスクにアクセスできるようにセキュリティを設定するには、Oracle ASMを有効範囲にしたセキュリティを構成します。

  • Oracle ASMクラスタの特定のデータベース・クライアントで特定のグリッド・ディスクにアクセスできるようにセキュリティを設定するには、データベースを有効範囲にしたセキュリティを構成します。

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

  • 混乱やエラーを回避するために、同じOracle ASMディスク・グループに属するすべてのグリッド・ディスクに、同じセル側のグリッド・ディスク・セキュリティが定義されていること。

  • Oracle ASMクラスタ内のOracle Real Application Clusters(Oracle RAC)のすべてのサーバーに、Oracle ASMのcellkey.oraファイルの同じ内容、所有権およびセキュリティがあること。

  • データベース・クラスタのすべてのRACサーバーに、データベースのcellkey.oraファイルの同じ内容、所有権およびセキュリティがあること。

  • データベースを有効範囲にしたセキュリティが実装されている場合は、グリッド・ディスクにアクセスするすべてのデータベースに実装されていることを確認します。Oracle ASMを有効範囲にしたセキュリティとデータベースを有効範囲にしたセキュリティを混在しないようにしてください。

セキュリティを設定する場合は、セル間で同じ構成にする必要があります。dcliユーティリティを使用することにより、構成を変更した場合でもユーザーによるエラーの可能性を排除できるため、一貫性が確保されます。

Oracle Exadata System Softwareのセキュリティは、オープン・セキュリティ、Oracle ASMを有効範囲にしたセキュリティまたはデータベース・セキュリティに対応しています。以降の項では、それぞれのモードについて説明します。

セキュリティを実装するには、セキュリティ・キーを設定する必要があります。

4.1.1 オープン・セキュリティ・モードについて

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

このセキュリティ・モードを使用するには、Oracle ASMクラスタまたはデータベース・クライアントのグリッド・ディスクにセキュリティ機能を設定しないようにします。セキュリティ・キー・ファイルも設定しないようにします。

4.1.2 Oracle ASMを有効範囲にしたセキュリティ・モードについて

Oracle ASMを有効範囲にしたセキュリティ・モードでは、Oracle ASMクラスタのすべてのデータベース・クライアントでセル上のグリッド・ディスクにアクセスできます。

Oracle ASMを有効範囲にしたセキュリティは、Oracle ASMクラスタで管理されるOracle ASMディスク・グループのセルのグリッド・ディスクに、ホスト・クラスタ上のすべてのデータベースでアクセスできるようにする場合に適しています。これは、Oracle ASMクラスタにデータベースが1つしかない場合にも適用されます。

Oracle ASMを有効範囲にしたセキュリティをOracle ASMクラスタまたはグリッド・ディスクに設定すると、グリッド・ディスクはOracle ASMクラスタ上のデータベースでのみ使用可能になります。

Oracle Exadata 12.2.1.1.0以降では、ASMクラスタに基づいてOracle ASMを有効範囲にしたセキュリティを定義できます。ASMクラスタを設定すると、1つ以上のクラスタで同じデータベース一意名を使用できます。各ASMクラスタ内では、データベース名は一意である必要があります。ASMクラスタ名は、データベースの一意の名前を修飾するために使用されます。

4.1.3 データベースを有効範囲にしたセキュリティ・モードについて

データベースを有効範囲にしたセキュリティ・モードでは、Oracle ASMクラスタの特定のデータベース・クライアントでセル上の特定のグリッド・ディスクにアクセスできるように構成します。

データベースを有効範囲にしたセキュリティ・モードは、複数のデータベースがセルにアクセスする場合で、Oracle ASMディスク・グループを構成する特定のグリッド・ディスクにアクセスできるデータベースを制御する場合に適しています。Oracle ASMを有効範囲にしたセキュリティを初期のセキュリティ・モードに設定し、次に、データベースを有効範囲にしたセキュリティを特定のデータベース・クライアントおよびグリッド・ディスクに設定します。データベースを有効範囲にしたセキュリティをデータベース・クライアントとグリッド・ディスク間に設定した場合は、指定したデータベース・クライアントで特定のグリッド・ディスクしか使用できなくなります。

データベースを有効範囲にしたセキュリティを使用する場合は、各ホストのデータベースごとにキー・ファイルが1つずつ設定され、各セルのデータベースごとにアクセス制御リスト(ACL)が1つずつ設定されます。

4.2 Oracle Exadata Storage Serverのオペレーティング・システムのセキュリティの理解

Oracle Exadata Storage Server上のオペレーティング・システムのセキュリティは次のとおりです。

  • セキュリティ・ポリシーの強制

  • セルへのネットワーク・アクセス・パスの保護

  • オペレーティング・システム・レベルのアクティビティの監視

Oracle Exadata System Softwareには、オペレーティング・システムやOracle Exadata Storage Serverへのネットワーク・アクセスを安全にするための機能が含まれています。

4.2.1 Oracle Exadata Storage Serverのセキュリティ・ポリシー

オペレーティング・システムへのユーザー・アクセスは、安全で固定化されたパスワードの使用により安全を保証できます。Oracle Exadata System Softwareを管理するユーザーのパスワードは、次のセキュリティ・ガイドラインに従います。

  • パスワードは90日ごとに変更する必要があります。

  • パスワードは最後に変更してから24時間以内は変更できません。

  • パスワードには少なくとも3つの文字クラスを使用する必要があります。パスワードの文字クラスとは、桁、小文字の文字、大文字の文字、その他の文字です。

  • 3つの文字クラスを使用する場合の、最小パスワード長は12文字です。4つの文字クラスを使用する場合の、最小パスワード長は8文字です。

    注意:

    文字クラス数を計算する際、パスワードの最初の大文字とパスワードの最後の桁はカウントされません。

  • パスフレーズを使用できます。パスフレーズの条件は、少なくとも3つの単語が含まれていること、16文字から40文字までの長さであること、および異なる文字クラスが含まれていることです。

  • 最大パスワード長は40文字です。

  • 新しいパスワードは既存のパスワードに類似したものにすることはできません。

  • ユーザー・アカウントは、ログイン試行に1回失敗するたびに10分間一時的にロックされます。

  • ユーザー・アカウントは、ログイン試行に5回失敗するとロックされます。

  • ログイン・セッションは、14400秒間入力がなければ終了します。

  • SSHセッションは、7200秒間アクティビティがなければ終了します。

4.2.1.1 パスワードの変更

パスワードの期限が切れる7日前に、ユーザーにはパスワードを変更する必要があることが通知されます。パスワードを変更するには、次のコマンドを使用します。

passwd username

このコマンドのusernameはユーザー名です。このコマンドの例を次に示します。

passwd celladmin

4.2.1.2 セキュリティ・ポリシーの有効化

/opt/oracle.cellos/RESECURED_NODEファイルによって、セキュリティ・ポリシーが有効化されます。ファイルが存在しない場合は、次のようにします。

  1. すべてのデータベース・サーバー上のOracle Grid Infrastructureサービスをシャットダウンします。
  2. 次のコマンド使用して、セル・サービスをシャットダウンします。
    cellcli -e alter cell shutdown services all
    
  3. 次のスクリプトを実行し、セキュリティ・ポリシーを設定します。
    /opt/oracle.SupportTools/harden_passwords_reset_root_ssh
    

    このコマンドはセルを再起動します。セルが立ち上がったら、新しいパスワードを設定する必要があります。

  4. 新しいパスワードを設定します。

4.2.1.3 失敗したパスワード試行の表示

失敗したパスワード試行を表示するには、次のコマンドを使用します。

/sbin/pam_tally2

4.2.1.4 ロックされたユーザー・アカウントのリセット

ログイン試行に5回失敗したユーザー・アカウントはロックされます。

アカウントをリセットするには、次のコマンドを使用します。

/sbin/pam_tally2 --user username --reset

このコマンドでは、usernameはアカウントをロックしたユーザー名です。

4.2.1.5 データベース・サーバーのパスワード・ポリシーの変更

パスワード・ポリシーは、Oracle Exadata Storage Serverに対しては変更できません。データベース・サーバーに対して変更できます。次の手順では、データベース・サーバーのパスワード・ポリシーを変更する方法について説明します。

  1. /etc/login.defsファイルの設定を変更して、経過ポリシーを変更します。ポリシーの例を次に示します。
    PASS_MAX_DAYS 90
    PASS_MIN_DAYS 1
    PASS_MIN_LEN 8
    PASS_WARN_AGE 7
    
  2. /etc/pam.d/system-authファイルのminパラメータの値を変更することにより、文字クラスの制限を変更します。現在のminの値はmin=disabled,disabled,16,12,8です。これらの値は、/opt/oracle.SupportTools/harden_passwords_reset_root_sshスクリプトを実行した後に適用されます。5,5,5,5,5と設定すると、パスワードの最小文字数を5文字にすることができ、文字クラスの制限が削除されます。
  3. データベース・サーバーを再起動します。

関連項目:

詳細は、login.defsおよびpasswdqc.confマニュアル・ページを参照してください。

4.2.2 Oracle Exadata Storage Serverへのネットワーク・アクセス

Oracle Exadata System Softwareには、各セルにファイアウォールを実装するセルウォール・サービスが含まれています。このサービスは/etc/init.d/cellwallディレクトリにあり、セル上にiptablesファイアウォールを実装します。さらに、SSHサーバーは管理ネットワーク(NET0)およびInfiniBandネットワーク(BONDIB0)上のみでの接続リクエストに応答するよう構成されています。

ファイアウォール・ルールを確認するには、次のコマンドをrootユーザーとして実行します。

iptables --list

注意:

データベース・サーバーに自動的に構成されるファイアウォールはありません。Oracle Exadata Database Machineの現在のネットワーク要件を満たすように、データベース・サーバー上にiptablesのセットを実装します。

4.2.3 Oracle Exadata Storage Server上でのオペレーティング・システム・アクティビティの監視

各Oracle Exadata Storage Serverは、システム・レベルのアクティビティを監査するようにauditidで構成されています。監査を管理してレポートを生成するには、auditctlコマンドを使用します。監査ルールは/etc/audit/audit.rulesファイルにあります。パッチ・セットを適用すると、変更は保持されません。

4.3 cellkey.oraファイルの理解

Oracle Exadata Storage Serverにアクセスするクライアントを含むホスト・コンピュータにセキュリティを設定するには、cellkey.oraファイルを設定し、そのファイルをすべてのコンピュータに配置する必要があります。

Oracle ASMを有効範囲にしたセキュリティにはcellkey.oraファイルが1つ必要で、データベースを有効範囲にしたセキュリティを使用している各データベース・クライアントに別のcellkey.oraファイルが1つずつ必要です。Oracle ASMを有効範囲にしたセキュリティのキー・ファイルの内容は、すべてのデータベース・サーバーで同じです。これに対し、データベースを有効範囲にしたセキュリティのキー・ファイルの内容は、データベース・クライアントごとに異なります。

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

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

  • key — このフィールドは必須です。

    • Oracle ASMを有効範囲にしたセキュリティの場合は、CellCLIのASSIGN KEYコマンドでOracle ASMクラスタに割り当てられたキーの値に、このキーを一致させる必要があります。

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

  • asm — このフィールドは必須です。

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

    注意:

    asmフィールドは、Oracle ASMを有効範囲にしたセキュリティと、データベースを有効範囲にしたセキュリティの両方で使用されます。

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

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

key=66e12adb996805358bf82258587f5050
asm=cluster1

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

セキュリティ・キーは、セルとセルのクライアント間のメッセージの認証および保護に使用されます。CellCLIのCREATE KEYコマンドでは、セキュリティ・キーとして使用するランダムの16進文字列が生成されます。

CREATE KEYコマンドは任意のセルで実行できますが、実行する必要があるのは、新規の一意キーを作成する必要がある場合のみです。

  • Oracle ASMを有効範囲にしたセキュリティの場合は、CREATE KEYを1回のみ実行し、指定したセキュリティ・モードで必要なキーを1つ作成します。

  • データベースを有効範囲にしたセキュリティの場合は、Oracle ASMにセキュリティ・キーを1つ作成し、データベースを有効範囲にしたセキュリティを使用する各データベースにセキュリティ・キーを1つずつ作成します。

例4-2 Oracle ASMを有効範囲にしたセキュリティのセキュリティ・キーの作成

CellCLI> CREATE KEY

         66e12adb996805358bf82258587f5050

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

Oracle ASMを有効範囲にしたセキュリティをOracle Exadata Storage Serverのグリッド・ディスクに構成できます。

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

    このキーは、Oracle ASMクラスタのクライアントおよびcellkey.oraファイルのキー・エントリに使用されます。

  3. 例4-1に示す書式を使用して、キーをcellkey.oraファイルにコピーします。
  4. ASSIGN KEYコマンドを使用して、Oracle ASMクラスタでアクセスするすべてのセルのOracle ASMクラスタ・クライアントに、セキュリティ・キーを割り当てます。このコマンドの例を次に示します。
    CellCLI> ASSIGN KEY FOR 'unique_name_across_all_clusters' -
             ='66e12adb996805358bf82258587f5050'
    

    前のコマンドにおいて、unique_name_across_all_clustersは、セルとクラスタに関して一意で一貫性のある値です。Oracle Clusterwareのクラスタ名は、クラスタが一意名を持つ場合に使用できます。一意名は、キーの割当て時に使用する必要があります。

    Oracle ASMクラスタに基づいてOracle ASMを有効範囲にしたセキュリティを使用している場合は、ASMCLUSTERキーワードを追加します。この場合、unique nameパラメータにOracle ASMクラスタ名を指定します。次に例を示します。

    CellCLI> ASSIGN KEY FOR ASMCLUSTER 'Oracle_ASM_cluster_name' -
             ='66e12adb996805358bf82258587f5050'
    
  5. CREATE GRIDDISKコマンドまたはALTER GRIDDISKコマンドを使用して、手順4と同じ名前をavailableTo属性に入力し、Oracle ASMクラスタでアクセスするすべてのセルのグリッド・ディスクにセキュリティを構成します。次のコマンドは、新規のグリッド・ディスクを作成してセキュリティを設定する例と既存のグリッド・ディスクのセキュリティを変更する例です。
    • 新規のグリッド・ディスクを作成してセキュリティを設定する場合:

      CellCLI> CREATE GRIDDISK ALL PREFIX=sales, size=75G, -
               availableTo='unique_name_across_all_clusters'
      
    • 既存のグリッド・ディスクのセキュリティを変更する場合:

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

    前のコマンドにおいて、unique_name_across_all_clustersは、セルとクラスタに関して一意で一貫性のある値です。availableToに値が入力されている場合、グリッド・ディスクにアクセスできるのは指定したクライアントのみです。値が入力されていない場合は、どのクライアントもアクセスできます。

  6. 各ASMクラスタのcellkey.oraファイルを各データベース・ホストの/etc/oracle/cell/network-configにコピーします。
  7. cellkey.oraの権限を/etc/oracle/cell/network-configに設定します。
    chown grid:oinstall /etc/oracle/cell/network-config/cellkey.ora 
    chmod 600 /etc/oracle/cell/network-config/cellkey.ora
  8. 次のものを再起動します。
    • データベースおよびOracle ASMインスタンス

    • クラスタウェア。クラスタウェアを停止および起動するコマンドは次のとおりです。

      • crsctl stop crs

      • crsctl start crs

4.5 Oracle Exadata Storage Serverのデータベースを有効範囲にしたセキュリティの設定

この項では、Oracle Exadata Storage Serverに必要なデータベースを有効範囲にしたセキュリティ構成について説明します。

セルのセキュリティ設定を更新する前に、データベースおよびOracle ASMインスタンスをシャットダウンする必要があります。この項の手順を完了したら、「cellkey.oraファイルの理解」の手順に従ってキーを正しく書式設定する必要があります。cellkey.oraファイルの構成が完了したら、データベースおよびOracle ASMインスタンスを起動します。

データベースを有効範囲にしたセキュリティを設定するには、次の手順を実行します。

注意:

データベースを有効範囲にしたセキュリティの設定は、Oracle ASMを有効範囲にしたセキュリティを構成およびテストしてから行ってください。

Oracle ASMクラスタが1つしかない場合は、availableTo=+asmを使用できます。複数のクラスタがある場合は、一意のクラスタの設定方法を「Oracle Exadata Storage ServerのOracle ASMを有効範囲にしたセキュリティの設定」で確認してください。

  1. 各データベースの一意のデータベース名(DB_UNIQUE_NAME)を取得します。この名前では大/小文字が区別されます。
  2. セキュリティ構成を変更するデータベースおよびOracle ASMインスタンスをシャットダウンします。
  3. CellCLIのCREATE KEYコマンドを使用して、特定のグリッド・ディスクにアクセスするデータベース・クライアントにセキュリティ・キーを作成します。このコマンドは任意のセルで実行できます。このコマンドを実行すると、システムによって新規のキーが表示されます。
    CellCLI> CREATE KEY
    
    66e12adb996805358bf82258587f5050
    
  4. 例4-1に示す書式を使用して、キーをcellkey.oraファイルにコピーします。
  5. 例4-3に示すように、ASSIGN KEYコマンドを使用して、グリッド・ディスクを含むセルのデータベース・クライアントにキーを割り当てます。
  6. CREATE GRIDDISKコマンドまたはALTER GRIDIDISKコマンドのavailableTo属性を使用し、グリッド・ディスクにセキュリティを構成します。availableTo属性の値を設定する場合は、データベース・クライアント名にOracle ASMクラスタ名を含める必要があります。名前は一意で一貫性のあるものにする必要がありますが、通常はOracle Clusterwareのクラスタ名です。

    例4-4では、availableTo属性を使用してグリッド・ディスクが作成されるときに、データベースを有効範囲にしたセキュリティが構成されます。この属性では、グリッド・ディスクにアクセスするように構成される特定のクライアントが決定されます。

    例4-5に示すように、ALTER GRIDDISKコマンドを使用すると、既存のグリッド・ディスクのセキュリティを変更できます。

    注意:

    availableTo='+asm'引数は必須です。

  7. すべてのコンピュータのcellkey.oraファイルの構成が完了したら、データベースおよびOracle ASMインスタンスを再起動します。

    クライアント・コンピュータでのcellkey.oraファイルの構成の詳細は、「クライアント・コンピュータのcellkey.oraファイルの設定」を参照してください。

例4-3 データベース・クライアントへのキーの割当て

CellCLI> ASSIGN KEY FOR  'db1'='51a826646ebe1f29e33c6ed7c4965c9a',
                         'db2'='bd0843beeed5e18e6664576cf9805b69',
                         'db3'='6679ef9ec02fa664582c3464d4b0191f'

例4-4 データベースを有効範囲にしたセキュリティを使用したグリッド・ディスクの作成

CellCLI> CREATE GRIDDISK sales_CD_00_cell01, sales_CD_01_cell01 size=75G, -
         availableTo='+asm,db1'

CellCLI> CREATE GRIDDISK sales_CD_02_cell01, sales_CD_03_cell01 size=75G, -
         availableTo='+asm,db2'

CellCLI> CREATE GRIDDISK sales_CD_04_cell01, sales_CD_05_cell01 size=75G, -
         availableTo='+asm,db3'

例4-5 データベースを有効範囲にしたセキュリティへのグリッド・ディスクのセキュリティ構成の変更

CellCLI> ALTER GRIDDISK sales_CD_01_cell01, sales_CD_02_cell01 -
         availableTo='+asm,db1'

CellCLI> ALTER GRIDDISK sales_CD_03_cell01, sales_CD_04_cell01 -
         availableTo='+asm,db2'

CellCLI> ALTER GRIDDISK sales_CD_05_cell01, sales_CD_06_cell01 -
         availableTo='+asm,db3'

関連項目:

4.6 クライアント・コンピュータのcellkey.oraファイルの設定

クライアント・コンピュータにcellkey.oraファイルを構成できます。

注意:

cellkey.oraファイルに権限が正しく設定されていないと、ファイルへのアクセスが解放され、誰でも読み取ることできます。

  1. ASMを有効範囲にしたセキュリティ用に、Oracle ASMクラスタ上でcellkey.oraファイルを設定します。
    1. cellkey.oraファイルを/etc/oracle/cell/network-config/ディレクトリに配置します。
    2. ファイルの権限を所有者の読取り専用に設定します。
      • すべてのOracleソフトウェアで単一のインストール・ユーザーを使用する場合は、ファイルの権限を所有者の読取り専用に設定します。

      • ロール別管理を使用する場合は、フェイルの権限を、Oracle Grid Infrastructure (grid)およびOracle Database (oracle)の両方のインストール・ユーザーを含むoinstallグループの読取り専用に設定します。

      chmod 600 /etc/oracle/cell/network-config/cellkey.ora
      
    3. グループをOracle ASM管理グループに設定します。
      chown grid:oinstall /etc/oracle/cell/network-config/cellkey.ora
      
  2. データベースを有効範囲にしたセキュリティ用に、cellkey.oraファイルを設定します。

    cellkey.oraファイルはデータベースごとに必要であり、データベースごとに異なります。たとえば、データベースが3つあり、異なるcellkey.oraファイルが4つある場合は、各データベース用に1つと、ASM用に1つとなります。

    1. cellkey.oraファイルを$ORACLE_HOME/admin/db_unique_name/pfileディレクトリに配置します。
    2. cellkey.oraファイルの所有権を、そのデータベースのOracleホームを所有する同じユーザーに変更します。oinstallグループやその他のグローバル・オペレーティング・システム・グループはファイルを所有できません。
  3. データベースまたはOracle ASMインスタンスが起動されている場合は、停止してから続行します。
  4. クライアント・コンピュータにcellkey.oraファイルを作成します。

    データベース・クライアントのcellkey.oraは、アクセスを制限するデータベース・クライアントの$ORACLE_HOME/admin/db_unique_name/pfile/ディレクトリに配置する必要があります。

    このファイルのキー値は、データベース・クライアントに割り当てられるキーの値と一致する必要があります。ファイルの内容の例は、例4-1を参照してください。

    cellkey.oraキー・ファイルは、Oracleホームを所有するデータベース・クライアントでのみ読取り可能にする必要があります。

  5. cellkey.oraファイルを作成して編集したら、インスタンスを再起動します。

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

Exadata環境で、Oracle ASMを有効範囲にしたセキュリティまたはデータベースを有効範囲にしたセキュリティを構成した場合、アクセス制御の制限により、直接的なCell-to-Cell操作が実行されないことがあります。セルが直接相互に通信する必要がある場合に、他のセルにアクセスできるようにするには、各セルにセル・キーを設定する必要があります(たとえば、オフロード操作の場合)。

次の手順は、セル・キーを作成して、セルにこのキーを割り当てる方法を示しています。

  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\'"

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

前述の手順では、インバウンドとアウトバウンドの両方のCell-to-Cellトラフィックで使用される単一キーを使用しています。ASSIGN KEYコマンドの簡易版が使用されています。

複数のリモート・セル・キーを受け入れるようにセルを構成できます。これを行うのは、鍵を変更中など一時的な場合であり、各セルには一意キーを割り当てます。この場合、ASSIGN KEYコマンドでLOCALまたはREMOTEを指定する必要があります。

次のコマンドは、ローカル・セルのセル・キーを設定します。

CellCLI> ASSIGN KEY FOR LOCAL CELL mykey='fa292e11b31b210c4b7a24c5f1bb4d32'

次のコマンドは、ローカル・セルが受け入れるセル・キーを設定します。

CellCLI> ASSIGN KEY FOR REMOTE CELL -
          'cellkey1'='b67d5587fe728118af47c57ab8da650a', -
          'cellkey2'='118af47c57ab8da650ab67d5587fe728'

nameパラメータは、cellkey1cellkey2またはmykeyにする必要はありません。nameパラメータには、クライアントのcellkey.oraファイル内の名前と一致していれば、どのような値でも指定できます。

単純形式とLOCAL/REMOTE形式との切替え

LOCALキーまたはREMOTEキーを既存のセル・キーに割り当てようとすると(つまり、単純なASSIGN KEY FOR CELL形式を実行して、明示的なLOCAL形式またはREMOTE形式に切り替える)、CELL-02911: LOCAL CELLキーを割り当てる前に既存のCELLキーを削除してください。というエラーが発生します。明示的なLOCAL形式またはREMOTE形式で新しいキーを割り当てる前に、セル・キーを削除する必要があります。これは、リモート・キーとローカル・キーが異なることにより、構成が誤って破損しないようにするためです。

既存のリモート・セル・キーが複数ある場合に、これを行わないでASSIGN KEY FOR CELLを実行しようとすると、CELL-02912: CELLキーを割り当てる前に既存のすべてのLOCALおよびREMOTE CELLキーを削除してください。LIST KEY FOR CELLを使用してすべてのLOCALおよびREMOTE CELLキーを表示してから、ASSIGN KEYを使用してそれぞれに空の値を割り当てます。というエラーが発生します。単純なセル・キーを割り当てる前に、既存のすべてのLOCALおよびREMOTEのセル・キーを削除する必要があります。

また、LOCALとして指定されているキーは、使いやすくするためおよび構成をより簡単にするために、REMOTEセルから暗黙的に受け入れられます。

セルのセル・キーの表示

セルに割り当てられているすべてのキーを表示するには、LIST KEYコマンドを使用します。

CellCLI> LIST KEY
         db1    b67d5587fe728118af47c57ab8da650a
         asm1   118af47c57ab8da650ab67d5587fe728    ASMCLUSTER
         cell   fa292e11b31b210c4b7a24c5f1bb4d32    CELL

セル・キーのみを表示するには、LIST KEYコマンドでFOR CELLを指定します。

CellCLI> LIST KEY FOR CELL DETAIL
         key:       fa292e11b31b210c4b7a24c5f1bb4d32
         type:      CELL

セルにLOCALセル・キーとREMOTEセル・キーの両方が割り当てられている場合、コマンド出力には両方のタイプが表示されます。

CellCLI> LIST KEY FOR CELL
       mykey     fa292e11b31b210c4b7a24c5f1bb4d32    LOCAL-CELL
       cellkey1  b67d5587fe728118af47c57ab8da650a    REMOTE-CELL
       cellkey2  118af47c57ab8da650ab67d5587fe728    REMOTE-CELL

4.8 セキュリティの削除

この項では、Oracle Exadata Storage Serveからセキュリティを削除する方法について説明します。

注意:

Oracle ASMを有効範囲にしたセキュリティを削除する前に、グリッド・ディスクでデータベースを有効範囲にしたセキュリティを削除する必要があります。

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

4.8.1 データベースを有効範囲にしたセキュリティの削除

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

  1. データベースおよびOracle ASMインスタンスをシャットダウンします。
  2. データベースを有効範囲にしたセキュリティを削除するグリッド・ディスクのavailableTo属性に名前が指定されているデータベース・クライアントを削除します。例4-6は、グリッド・ディスクのグループでこの操作を行う方法を示しています。
  3. データベース・クライアントで他のグリッド・ディスクのセキュリティが設定されていない場合は、次のようにCellCLIのASSIGN KEYコマンドでデータベース・クライアントに割り当てられているキーを削除できます。
    CellCLI> ASSIGN KEY FOR 'db_client'=''
    

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

  4. データベース・クライアントの$ORACLE_HOME/admin/db_unique_name/pfile/ディレクトリにあるcellkey.oraファイルを削除します。
  5. 次のコマンドを使用して、availableTo属性からデータベースを削除します。
    ALTER GRIDDISK ALL availableTo='+asm'
    
  6. データベースおよびOracle ASMインスタンスを再起動します。

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

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

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

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

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'

注意:

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

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

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

  1. データベースおよびOracle ASMインスタンスをシャットダウンします。
  2. 例4-7に示すように、セルのグリッド・ディスクのavailableTo属性に名前が指定されているOracle ASMクラスタ・クライアントを削除します。
  3. Oracle ASMクラスタ・クライアントで他のグリッド・ディスクのセキュリティが設定されていない場合は、次のようにCellCLIのASSIGN KEYコマンドでOracle ASMクラスタ・クライアントに割り当てられているキーを削除できます。
    CellCLI> ASSIGN KEY FOR 'asm_cluster'=''
    

    このコマンドのasm_clusterは、Oracle ASMクラスタ・クライアントの名前です。

  4. Oracle ASMクラスタの各コンピュータ・ホストの/etc/oracle/cell/network-config/ディレクトリにあるcellkey.oraファイルを削除します。
  5. 次のコマンドを使用して、availableTo属性からOracle ASMを削除します。
    ALTER GRIDDISK ALL availableTo=''
    
  6. データベースおよびOracle ASMインスタンスを再起動します。

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

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

CellCLI> ALTER GRIDDISK ALL availableTo=''

次のコマンドでは、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.9 ユーザーおよびロールの作成

ロールに権限を付与し、ユーザーにロールを付与することで、ユーザーが実行できるコマンドを制御できます。

たとえば、ユーザーがlist griddiskコマンドを実行でき、alter griddiskコマンドは実行できないように指定できます。このレベルの制御は、システムへの完全なアクセスをごく少数のユーザーにのみ許可するクラウド環境で役立ちます。

クラウド環境では、ExaCLIを実行するため、ユーザーはユーザー名とパスワードでログインする必要があります。Exadataの管理システム(MS)により、ユーザーの資格証明が認証され、そのユーザーによって発行されるコマンドの許可チェックが実行されます。そのユーザーがコマンドを実行する適切な権限を持っていない場合、MSによりエラーが返されます。

ユーザーは、ExaCLIを実行するときに必要です。ExaCLIでは、計算ノードからリモートでセルを管理できます。計算ノード上でExaCLIを実行するときに、セル・ノードへの接続に使用するユーザー名を指定する必要があります。

パスワードのセキュリティ・キーは、HMAC-SHA1とパスワード・ベース鍵導出関数2(PBKDF2)を使用して暗号化されています。

ユーザーおよびロールを設定するには、次の手順を実行します。

  1. CREATE ROLEコマンドを使用してロールを作成します。

  2. GRANT PRIVILEGEコマンドを使用してロールに権限を付与します。

  3. CREATE USERコマンドを使用してユーザーを作成します。

  4. GRANT ROLEコマンドを使用してユーザーにロールを付与します。

REVOKE PRIVILEGEコマンドを使用して、ロールから権限を取り消すこともできます。ユーザーからロールを取り消すには、REVOKE ROLEコマンドを使用します。

関連項目

  • ExaCLIユーティリティの使用

4.9.1 ロールの作成およびロールに関する情報の取得

ロールを作成するには、CREATE ROLEコマンドを使用します。次に例を示します。

CellCLI> CREATE ROLE admin

ロールに関する詳細情報を取得するには、LIST ROLEコマンドを使用します。たとえば、次のコマンドはadminロールのすべての属性を返します。

CellCLI> LIST ROLE admin ALL DETAIL

関連項目

4.9.2 権限の付与および取消し

  • ロールに権限を付与するには、GRANT PRIVILEGEコマンドを使用します。

    次の例は、adminロールを持つユーザーにすべての権限を付与しています。

    CellCLI> GRANT PRIVILEGE ALL ACTIONS ON ALL OBJECTS TO ROLE admin
    
  • REVOKE PRIVILEGEコマンドを使用して、ロールから権限を取り消すことができます。

4.9.3 ユーザーの作成

ユーザーを作成するには、CREATE USERコマンドを使用します。

次のコマンドは、パスワード「changeME123」で「fred」というユーザーを作成します。

CellCLI> CREATE USER fred PASSWORD = "changeME123"

新しく作成したユーザーは、何も権限を持っていません。任意の権限を持つようにユーザーにロールを付与する必要があります。

関連項目

4.9.4 ロールの付与と取消し

  • ユーザーにロールを付与するには、GRANT ROLEコマンドを使用します。

    次の例は、ユーザーfredadminロールを付与しています。

    CellCLI> GRANT ROLE admin TO USER fred
    
  • REVOKE ROLEコマンドを使用して、ユーザーからロールを取り消すことができます。

関連項目

4.10 ストレージ・サーバーでのSSHの無効化

デフォルトでは、ストレージ・サーバーでSSHが有効化されています。必要に応じて、SSHアクセスをブロックするためにストレージ・サーバーを「lock」できます。その場合でも、計算ノード上で実行され、httpsおよびREST APIを使用してセル上で実行されているWebサービスと通信するexacliを使用して、セルの操作は実行できます。

セルへのログインを必要とする操作を実行するときは、一時的にセルのロックを解除できます。操作が完了したら、再びセルをロックできます。

次の2つの新しいセル属性によりセルのロックを制御します。

  • accessLevelPerm : この属性は、セルがデフォルトで実行されるアクセス・レベルを指定します。それは、remoteLoginEnabledまたはremoteLoginDisabledのいずれかです。

    • remoteLoginEnabled: SSHサービスは有効です。sshまたはexacliを使用してセルにアクセスできます。これが、accessLevelPermのデフォルト値です。

    • remoteLoginDisabled: SSHサービスは無効です。exacliを介してのみ、セルにアクセスできます。

  • accessLevelTemp: 指定された期間、一時的にアクセス・レベルを変更できます。期限が切れると、アクセス・レベルはaccessLevelPermの値に戻ります。通常、セルでソフトウェアの更新を必要とするときに、セルのアクセス・レベルを変更します。

このアクセス・レベルは、セルの再起動後も維持されます。

4.10.1 セルのロック

セルをロックするには、そのaccessLevelPerm属性をremoteLoginDisabledに設定します。

accessLevelPerm属性を変更する権限を持つユーザーを使用する必要があります。

  1. 必要な権限をユーザーに付与します。

    ストレージ・サーバーで、次のコマンドを実行します。

    cellcli> create role administrator
    cellcli> grant privilege all actions on all objects all attributes with all options to role administrator
    cellcli> create user celladministrator password=*
    cellcli> grant role administrator to user celladministrator
    
  2. celladministratorユーザーとしてExaCLIを実行し、ALTER CELLコマンドを実行します。
    $ exacli -l celladministrator -c exam08cel01
    Password=********
    
    exacli> alter cell accessLevelPerm = remoteLoginDisabled
    

4.10.2 セルの一時的なロック解除

セルへのSSHログインを必要とするメンテナンスやアップグレードなどの操作を実行するため、短時間、ロックされたセルのロックを解除できます。この「一時的なアクセス・ウィンドウ」の開始時間および持続時間は、セルのaccessLevelTemp属性を設定することで指定できます。この属性には、次のプロパティがあります。

表4-1 accessLevelTempのプロパティ

プロパティ 説明

accessLevel

SSHの有効(remoteLoginEnabled)または無効(remoteLoginDisabled)のいずれかを指定します。

この値は、指定する必要があります。デフォルト値はありません。

startTime

指定されたアクセス・レベルの開始時間を指定します。この時間は、ISO 8601形式の「yyyy-MM-ddTHH:mm:ssZ」で指定します。

また、指定のアクセス・レベルをすぐに開始することを示すため、キーワード「now」を指定することもできます。

デフォルト値: now

duration

アクセス・レベルの継続時間を指定します。継続時間は、次の形式で指定します。

[任意の桁数の数字、それに続くd (日数)]

[任意の桁数の数字、それに続くh (時間数)]

[任意の桁数の数字、それに続くm (分数)]

例:

1時間を指定: 1h

90分を指定: 90m

1日を指定: 1d

1日と12時間を指定: 1d12h

デフォルト値: 2h (2時間)

reason

アクセス・レベルを変更する理由を指定します(たとえば、アップグレードを実行する)。

デフォルト値: "none"

例:

1. 次の例では、2015年6月20日午前1:01に開始される、2時間の一時的なアクセス・ウィンドウを作成します。

exacli> alter cell accessLevelTemp=((accessLevel="remoteLoginEnabled", -
        startTime="2015-06-20T01:01:00-07:00",                         -
        duration="2h",                                                 -
        reason="Quarterly maintenance"))

2. 次の例では、即時に開始される、2時間の一時的なアクセス・ウィンドウを作成します。このコマンドは、開始時間および継続時間のデフォルト値を使用します。

exacli> alter cell accessLevelTemp=((accessLevel="remoteLoginEnabled", -
        reason="Quarterly maintenance"))

3. 次の例では、即時に開始される、30分間の一時的なアクセス・ウィンドウを作成します

exacli> alter cell accessLevelTemp=((accessLevel="remoteLoginEnabled", -
        startTime="now",                                               -
        duration="30m",                                                -
        reason="Quarterly maintenance"))

4. 次の例では、2015年6月20日午前1:01に開始される、2時間の一時的なアクセス・ウィンドウを作成します。このコマンドは、継続時間のデフォルト値を使用します。

exacli> alter cell accessLevelTemp=((accessLevel="remoteLoginEnabled", -
        startTime="2015-06-20T01:01:00-07:00",                         -
        reason="Quarterly maintenance"))

5. 次の例では、前述の例4で作成した一時的なアクセス・ウィンドウを5時間に拡張します。調整するウィンドウと開始時間が一致しなければならないことに注意してください。

exacli> alter cell accessLevelTemp=((accessLevel="remoteLoginEnabled", -
        startTime="2015-06-20T01:01:00-07:00",                         -
        duration="5h",                                                 -
        reason="Quarterly maintenance window extended to 5 hrs - Joe"))

6. 次の例では、一時的なアクセス・ウィンドウを削除します。一時的なアクセス・ウィンドウが現在アクティブである場合は、ただちにそれが閉じられ、アクセス・レベルが永続的なアクセス・レベルに戻されます。一時的なアクセス・ウィンドウが予定されていて、まだアクティブでない場合は、キャンセルされます。

exacli> alter cell accessLevelTemp=''

 

次の点に注意してください。

  • いつの時点でも、一時的なアクセス・ウィンドウは、1つのみ許可されます。すでに1つが有効であるときに、新しい一時的なアクセス・ウィンドウを作成しようとすると、エラー・メッセージが表示されます。

    一時的なアクセス・ウィンドウがまだアクティブではなく、予定されている場合は、予定されているものが新しく作成された一時的なアクセス・ウィンドウで置き換えられます。

  • 予定されていて、まだアクティブではない一時的なアクセス・ウィンドウを変更するには、単に新しい値で再び「alter cell」コマンドを実行します。

  • すでに進行中の一時的なアクセス・ウィンドウを変更(たとえば、継続時間の延長や理由の変更)するには、更新した継続時間または理由(あるいはその両方)で、再び「alter cell」コマンドを実行します。このコマンドでは、変更する既存の一時的なアクセス・ウィンドウの正確な開始時間を指定する必要があります。(開始時間 + 継続時間)は、将来の時刻にする必要があります。

4.10.3 現在のアクセス・レベルのチェック

現在のアクセス・レベルが何かを確認するには、次のコマンドを実行します。

exacli> list cell detail

accessLevelPermおよびaccessLevelTemp属性の値を確認します。

また、次のコマンドを実行できます。

exacli> list cell attributes accessLevelPerm

exacli> list cell attributes accessLevelTemp

4.10.4 管理サーバーからのアラート

accessLevelPerm属性が変更されたときに、ステートレス・アラートが生成されます。

accessLevelTempウィンドウが作成されたときに、ステートフル・アラートが生成されます。accessLevelTempウィンドウがアクティブになったときに、アラート電子メールが送信されます。ウィンドウの有効期限が切れたときに、アラートがクリアされます。