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

4 Oracle Exadataの保護

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

  • ハードウェアの保護
    Oracle Exadata Database Machineのインストール後、ハードウェアを保護する必要があります。
  • ソフトウェアの保護
    多くの場合、ハードウェアのセキュリティは、ソフトウェアを通じて実装されます。
  • ストレージ・サーバーでのSSHの無効化
    必要に応じて、SSHアクセスをブロックするようにストレージ・サーバーをロックできます。デフォルトでは、ストレージ・サーバーでSSHが有効化されています。
  • 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の保護

4.1.1 ラックのシリアル番号の取得

ラックのシリアル番号を取得するには、ipmitoolユーティリティを使用します。

Oracleサポート・サービスとやり取りする場合、ラックのCSI番号はラックのシリアル番号に基づきます。

  1. rootユーザーとしてラック内のいずれかのサーバーにログインします。
  2. ipmitoolを使用して、ラックのシリアル番号を取得します。
    # ipmitool sunoem cli "show /SP system_identifier"
Connected. Use ^D to exit.
-> show /SP system_identifier

 /SP
    Properties:
        system_identifier = Exadata Database Machine X2-8xxxxAKyyyy


-> Session closed
Disconnected

親トピック: ハードウェアの保護

4.1.2 ラック・コンポーネントのシリアル番号の取得

CheckHWnFWProfileコマンドを使用すると、ほとんどのシステム・コンポーネントのシリアル番号を表示できます。

  1. rootユーザーとしてラック内のいずれかのサーバーにログインします。
  2. ラック内の各サーバーで、-Sオプションを指定したCheckHWnFWProfileを使用し、そのサーバーのコンポーネントのシリアル番号を表示します。
    # /opt/oracle.SupportTools/CheckHWnFWProfile -S > /tmp/CheckHWnFWProfile_hostname.txt

    結果は各サーバーに固有であるため、このコマンドをすべてのノードで実行する必要があります。出力の部分的な例を次に示します。

    Server_Model=ORACLE_SERVER_X8-2L
====START SERIAL NUMBERS====
==Motherboard, from dmidecode==
--System serial--
1904XCA000
--Motherboard serial--
469996N+0000RD01RN
--Chassis serial--
1900XCA000
--Rack serial--
AK00400000
==Infiniband HCA==
ID:      CX354A - ConnectX-3 QSFP
PN:      7046442
EC:      XX
SN:      465000K-1800000000
V0:      PCIe Gen3 x8
==Motherboard, RAM etc from ipmitool==
FRU Device Description : Builtin FRU Device (LUN 0 ID 0)
...
 Product Name          : ILOM
 Product Version       : 4.0.4.38.a

FRU Device Description : BMC
...
 Product Name          : ILOM
  Product Version       : 4.0.4.38.a

FRU Device Description : /SYS (LUN 0 ID 3)
...
 Product Part Number   : 8200669
 Product Serial        : 1900XCA000

FRU Device Description : DBP (LUN 0 ID 210)
 
 Board Part Number     : 7341141
 Board Extra           : Rev 09

FRU Device Description : HDD0 (LUN 0 ID 47)
 Device not present (Requested sensor, data, or record not found)

FRU Device Description : HDD1 (LUN 0 ID 48)
 Device not present (Requested sensor, data, or record not found)

...

FRU Device Description : MB (LUN 0 ID 4)
 Board Mfg Date        : Sun Jan 20 16:57:00 2019
 Board Mfg             : Oracle Corporation
...

FRU Device Description : MB/BIOS (LUN 0 ID 5)
...

FRU Device Description : MB/CPLD (LUN 0 ID 8)
 Product Manufacturer  : Oracle Corporation
 Product Name          : Power Control FPGA
 Product Version       : FW:3.9

FRU Device Description : M2R0/SSD0 (LUN 0 ID 211)
 Device not present (Requested sensor, data, or record not found)

FRU Device Description : M2R1/SSD0 (LUN 0 ID 212)
 Device not present (Requested sensor, data, or record not found)

FRU Device Description : MB/NET0 (LUN 0 ID 43)
 Product Manufacturer  : INTEL
 Product Name          : 1G Ethernet Controller
...

FRU Device Description : MB/P0 (LUN 0 ID 16)
 Product Manufacturer  : Intel
 Product Name          : Intel(R) Xeon(R) Gold 5218 CPU @ 2.30GHz
...

FRU Device Description : MB/P0/D0 (LUN 0 ID 24)
 Product Manufacturer  : Samsung
 Product Name          : 16384MB DDR4 SDRAM DIMM
...

FRU Device Description : MB/P0/D1 (LUN 0 ID 25)
 Device not present (Requested sensor, data, or record not found)

FRU Device Description : MB/P0/D2 (LUN 0 ID 26)
 Product Manufacturer  : Samsung
 Product Name          : 16384MB DDR4 SDRAM DIMM
...


FRU Device Description : MB/P1 (LUN 0 ID 17)
 Product Manufacturer  : Intel
 Product Name          : Intel(R) Xeon(R) Gold 5218 CPU @ 2.30GHz
...

FRU Device Description : MB/P1/D0 (LUN 0 ID 36)
 Product Manufacturer  : Samsung
 Product Name          : 16384MB DDR4 SDRAM DIMM
...
FRU Device Description : PS0 (LUN 0 ID 63)
...
FRU Device Description : PS1 (LUN 0 ID 64)
...
FRU Device Description : SP/NET0 (LUN 0 ID 1)
...
FRU Device Description : SP/NET1 (LUN 0 ID 2)
...
FRU Device Description : /UUID (LUN 0 ID 6)
...
FRU Device Description : TOP_LEVEL_CH (LUN 0 ID 251)
 Chassis Type          : Rack Mount Chassis
 Chassis Part Number   : 8200669
 Chassis Serial        : 1900XCA0000
 Chassis Extra         : chassis_name:ORACLE SERVER X8-2L

FRU Device Description : TOP_LEVEL_PROD (LUN 0 ID 250)
 Product Manufacturer  : Oracle Corporation
 Product Name          : Exadata X8-2
 Product Part Number   : Exadata X8-2
 Product Serial        : AK00430000

====END SERIAL NUMBERS====

親トピック: ハードウェアの保護

4.1.3 Cisco 9336Cまたは9348スイッチのラックのシリアル番号の取得

シリアル番号を取得するには、スイッチでshow license host-idコマンドを使用します。

  1. SSH等価が構成されたサーバーからスイッチに接続するか、adminユーザーとしてログインします。
  2. show license host-idコマンドを入力して、スイッチのシリアル番号を取得します。

    ホストIDはデバイス・シリアル番号とも呼ばれます。

    # switch# show license host-id
License hostid: VDH=FLA12345678

    等号(=)の後に表示されるID全体を使用します。この例では、ホストIDはFLA12345678です。

親トピック: ハードウェアの保護

4.1.4 Sun Datacenter InfiniBand Switch 36のラックのシリアル番号の取得

シリアル番号を取得するには、スイッチでshowfruinfoコマンドを使用します。

  1. rootとしてスイッチにログインします。
    $ ssh root@switch_name
  2. showfruinfoコマンドを使用して、スイッチのシリアル番号を表示します。
    root@ib-switch-> showfruinfo 
Sun_Man1R:
UNIX_Timestamp32 : Fri Mar 19 16:29:59 2010
Sun_Fru_Description : ASSY,NM2-GW
Vendor_ID_Code : 11 E1
Vendor_ID_Code_Source : 01
Vendor_Name_And_Site_Location : 4577 CELESTICA CORP. SAN JOSE CA US
Sun_Part_Number : 5111402
Sun_Serial_Number : 0110SJC-1010NG0040
Serial_Number_Format : 4V3F1-2Y2W2X4S
Initial_HW_Dash_Level : 03
Initial_HW_Rev_Level : 50
Sun_Fru_Shortname : NM2 gateway
Sun_Hazard_Class_Code : Y
Sun_SpecPartNo : 885-1655-01 
Sun_FRU_LabelR:
Sun_Serial_Number : AK000XXXX2
FRU_Part_Dash_Number : 541-4188-01

親トピック: ハードウェアの保護

4.1.5 Cisco 4948イーサネット・スイッチのシリアル番号の取得

シリアル番号を取得するには、スイッチでsh inventoryコマンドを使用します。

  1. Ciscoイーサネット・スイッチにログインします。
  2. sh inventoryコマンドを入力して、スイッチおよびそのコンポーネントのシリアル番号を取得します。
    # Switch# sh inventory
NAME: "Switch System", DESCR: "Cisco Systems, Inc. WS-C4948 1 slot switch "
PID:                   , VID:      , SN: FOX0000G0B6
NAME:  "Linecard(slot 1)", DESCR: "10/100/1000BaseT (RJ45), 1000BaseX (SFP) 
 Supervisor with 48 10/100/1000BASE-T ports and 4 1000BASE-"
PID: WS-C4948          , VID: V09  , SN: FOX0000G0B6
NAME: "Power Supply 1", DESCR: "Power Supply ( AC 300W )"
PID: PWR-C49-300AC     , VID:      , SN: QCS0000B1XR
NAME: "Power Supply 2", DESCR: "Power Supply ( AC 300W )"
PID: PWR-C49-300AC     , VID:      , SN: QCS0000B1X5

親トピック: ハードウェアの保護

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の保護

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

必要に応じて、SSHアクセスをブロックするためにストレージ・サーバーをロックできます。デフォルトでは、ストレージ・サーバーでSSHが有効化されています。

SSHアクセスがブロックされる場合、データベース・サーバー上で実行されている、HTTPSおよびREST APIの使用によりストレージ・サーバー上で実行されているWebサービスと通信するExaCLIを使用して、ストレージ・サーバーでの操作は実行できます。

ストレージ・サーバーへのログインを必要とする操作を実行する必要がある場合は、ストレージ・サーバーを一時的にロック解除できます。操作が完了したら、ストレージ・サーバーを再度ロックできます。

次の2つのCELL属性でストレージ・サーバーのロックを制御します。

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

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

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

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

アクセス・レベルは、ストレージ・サーバーの再起動後も維持されます。

親トピック: Oracle Exadataの保護

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

親トピック: ストレージ・サーバーでのSSHの無効化

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

ストレージ・サーバーへのSSHログインを必要とするメンテナンス、アップグレードなどの操作を実行するために、ロックされたストレージ・サーバーまたはセルを短時間ロック解除できます。

一時的なアクセス・ウィンドウの開始時間と継続時間を指定するには、ALTER CELLコマンドを使用してセルのaccessLevelTemp属性を変更します。

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

  • いつの時点でも、一時的なアクセス・ウィンドウは、1つのみ許可されます。すでに1つが有効であるときに、新しい一時的なアクセス・ウィンドウを作成しようとすると、エラー・メッセージが表示されます。一時的なアクセス・ウィンドウがまだアクティブではなく、予定されている場合は、予定されているものが新しく作成された一時的なアクセス・ウィンドウで置き換えられます。
  • 予定されていて、まだアクティブではない一時的なアクセス・ウィンドウを変更するには、単に新しい値で再びALTER CELLコマンドを実行します。
  • すでに進行中の一時的なアクセス・ウィンドウを変更(たとえば、継続時間の延長や理由の変更)するには、更新した継続時間または理由で、再びALTER CELLコマンドを実行します。このコマンドでは、変更する既存の一時的なアクセス・ウィンドウの正確な開始時間を指定する必要があります。(開始時間 + 継続時間)は、将来の時刻にする必要があります。

accessLevelTemp属性には、次のプロパティがあります。

  • accessLevel: (必須) SSHが有効(remoteLoginEnabled)であるか、無効(remoteLoginDisabled)であるかを指定します。この属性には値を指定する必要があります。デフォルト値はありません。

  • startTime: 指定されたアクセス・レベルの開始時間を指定します。この時間は、ISO 8601形式の"yyyy-MM-ddTHH:mm:ssZ"で指定します。また、指定のアクセス・レベルをすぐに開始することを示すため、キーワードnowを指定することもできます。この属性のデフォルト値はnowです。

  • duration: アクセス・レベルの継続時間を指定します。デフォルト値は2h (2時間)です。継続時間は、次の形式で指定します。

    • [任意の桁数の数字、それに続くd (日数)]1日を指定するには、1dを使用します。
    • [任意の桁数の数字、それに続くh (時間数)]1時間を指定するには、1hを使用します。
    • [任意の桁数の数字、それに続くm (分数)]90分を指定するには、90mを使用します。

    期間値の組合せを使用できます。たとえば、1日と12時間を指定するには、1d12hを使用します。

  • reason: アクセス・レベルを変更する理由を指定します(たとえば、アップグレードを実行する)。デフォルト値は指定なしです。

例4-1 一時的なアクセス・ウィンドウの作成

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

exacli> ALTER CELL accessLevelTemp=((accessLevel="remoteLoginEnabled", -
        reason="Quarterly maintenance"))

例4-2 将来の一時的なアクセス・ウィンドウの作成

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

exacli> ALTER CELL accessLevelTemp=((accessLevel="remoteLoginEnabled", -
        startTime="2023-06-20T01:01:00-07:00",                         -
        duration="30m",                                                -
        reason="Quarterly maintenance"))

例4-3 一時的なアクセス・ウィンドウの拡張

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

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

例4-4 一時的なアクセス・ウィンドウの削除

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

exacli> ALTER CELL accessLevelTemp=''

親トピック: ストレージ・サーバーでのSSHの無効化

4.3.3 セルの永続的なロック解除

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

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

  1. accessLevelPerm属性を変更する権限を持つユーザーとしてExaCLIを起動します。

    たとえば:

    $ exacli -l celladministrator -c exam08cel01
Password=********

exacli>
  2. ALTER CELLコマンドを実行して、accessLevelPerm属性をremoteLoginEnabledに設定します。

    たとえば:

    exacli> alter cell accessLevelPerm=remoteLoginEnabled
Cell exam08cel01 successfully altered

親トピック: ストレージ・サーバーでのSSHの無効化

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

現在のアクセス・レベルを判別するには、セルのaccessLevelPerm属性およびaccessLevelTemp属性を表示します。

  • 現在のアクセス・レベルが何かを確認するには、LIST CELLコマンドを使用します。
    exacli> LIST CELL ATTRIBUTES name,accessLevelPerm,accessLevelTemp

親トピック: ストレージ・サーバーでのSSHの無効化

4.3.5 管理サーバーからのアクセス・レベルのアラート

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

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

親トピック: ストレージ・サーバーでのSSHの無効化

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

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

関連項目

親トピック: 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の説明は図の下のリンクをクリックしてください。
「図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

関連項目

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

4.4.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 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
  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.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ディスク・グループにのみ割り当てることができます。
  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.4.6 ASMを有効範囲にしたセキュリティまたはDBを有効範囲にしたセキュリティのセキュリティ・キーの変更

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

親トピック: 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キーに変更する場合は、次のステップを実行します。

  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.4.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.4.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.4.7 Cell-to-Cell操作の有効化

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

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

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

4.4.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.4.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.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のセル・キーをすべて削除する必要があります。

  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.4.8 ASMを有効範囲にしたセキュリティまたはDBを有効範囲にしたセキュリティの削除

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

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

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

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

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

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

    ノート:

    データベース・クライアントの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-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を有効範囲にしたセキュリティを削除する必要があります。
4.4.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-8に、これを実行する方法を示します。

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

4.5 セキュアな環境の維持

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

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

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

関連項目

親トピック: Oracle Exadataの保護

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

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

  • ネットワーク・スイッチの構成ファイルはオフラインで管理し、構成ファイルへのアクセスは認可された管理者のみに制限する必要があります。構成ファイルには各設定の説明がコメントとして含まれています。構成ファイルの静的コピーをソース・コード制御システムに保持することを検討してください。

    ネットワーク・スイッチの構成の詳細は、ネットワーク・スイッチのベンダーのドキュメントを参照してください。

  • クライアント・アクセス・ネットワークを確認して、セキュアなホストおよびIntegrated Lights Out Manager (ILOM)設定が有効であることを確認します。設定を定期的に確認して、変更されていないことを確認します。

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

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

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

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

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

  • MACアドレス(MAC ACL)に基づいてアクセスを制限するには、ポート・セキュリティを実装します。

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

  • Oracle Exadata Database Machineに接続されたスイッチのすべてのポートで自動トランキングを無効化します。

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

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

  • 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.5.2 システム・ログ情報の暗号化

データベース・サーバーおよびストレージ・サーバー上の管理サーバー(MS)は、syslogconf属性をサポートします。Oracle Exadata System Softwareリリース19.3.0以降では、ログの転送を暗号化できます。

次のトピックでは、syslogとrsyslogが同じ意味で使用されます。これらはどちらもメッセージ・ロガーを参照します。

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

4.5.2.1 syslogファイルの暗号化の概要

syslog情報の暗号化を構成するには、証明書とsyslogconf属性を使用します。

syslogconf属性によってデータベース・サーバーのsyslogルールが拡張されます。この属性を使用すると、特定のリモートsyslogdサービスに対象のsyslogメッセージが転送されるように指定できます。MSでは、MSのsyslog構成に応じて、転送されたメッセージがファイル、コンソールまたは管理アプリケーションに渡されます。これにより、セキュリティ監査、データ・マイニングなどのために、様々なサーバーからのシステム・ログを集約し、集中化されたロギング・サーバーで調べることができます。

rsyslog暗号化を有効にするために必要なステップの概要は次のとおりです。

  1. 認証局(CA)を設定します。これには、certtoolコマンドがある任意のノードを使用できます。Exadata以外のサーバーを使用することをお薦めします。CAが自己署名証明書を作成します。証明書の暗号化キーは、安全な場所に格納する必要があります。この証明書は、他の証明書に署名するために使用されます。

  2. 参加する各ノードの証明書を生成します。中央CAがない場合、Exadata管理者はCAで秘密キーと公開キーの両方を生成し、そのコピーを信頼できる各サーバーに配布できます。中央CAがある場合は、Exadata管理者が各サーバーの秘密キーを生成します。

  3. 中央CAを使用している場合は、Exadata管理者が証明書リクエストを作成します。次に、このリクエストはCA管理者に送信され、CA管理者は証明書(公開キーを含む)を生成します。その後、CA管理者は、署名付き証明書をExadata管理者に返送します。

  4. 各参加ノードに署名付き証明書をインストールします。中央CAを使用している場合は、Exadata管理者がCAによって署名された証明書をインストールします。中央CAを使用していない場合、Exadata管理者はCAで生成された秘密キーと公開キーのコピーをインストールします。

  5. syslog中央サーバーを設定します。中央サーバーにはsyslog.conf設定が必要です。署名付き証明書も必要です。

  6. CellCLIまたはDBMCLIを使用して、各クライアントでsyslogの暗号化を有効または無効にします。

これらのステップが完了すると、転送するsyslogが暗号化されます。

4.5.2.2 CAサーバーおよび中央rsyslogdサーバーの構成

syslogの転送を暗号化する前に、証明書を生成し、認証局(CA)として機能するホストがそれらに署名する必要があります。この手順を実行する必要があるのは1回のみです。

  1. CAサーバーで、秘密キーと証明書を作成します。
    rsyslogドキュメントの「CAの設定」のステップに従います。rsyslogのドキュメントは、https://www.rsyslog.com/doc/v8-stable/tutorials/tls_cert_summary.htmlにあります。
    1. 秘密キーを生成します。
      # certtool--generate-privkey--outfile ca-key.pem --sec-param high
Generating a 3072 bit RSA private key...
    2. 自己署名付き証明書を作成します

      プロンプトが表示されたら、証明書の組織に関する要求された情報を指定します。各証明書は指定した期間有効ですが、その後はすべての証明書を再作成する必要があります。このため、たとえば3650日(10年)のように長い期間を使用できます。

      この証明書を使用して他の証明書に署名する場合、この証明書が認証局に属しているかどうかを尋ねられたときに、Yを指定する必要があります。次の場合もYで応答します。

      • この証明書はTLS Webクライアント(またはサーバー)証明書ですか。
      • 証明書を署名(DHEおよびRSA-EXPORT暗号スイート)に使用しますか。
      • 証明書は暗号化(RSA暗号スイート)に使用されますか。
      • 証明書は他の証明書の署名に使用されますか。
      # certtool--generate-self-signed --load-privkey ca-key.pem --outfile ca.pem
Generating a self signed certificate...
Please enter the details of the certificate's distinguished name. Just press enter to ignore a field.
Common name: common_name_for_CA
UID:
Organizational unit name: Org_unit_name
Organization name: Org_name
Locality name: CountyName_or_Locale
State or province name: state_prov
Country name (2 chars): Country_code
Enter the subject's domain component (DC):
This field should not be used in new certificates.
E-mail: CA_user_email_address
Enter the certificate's serial number in decimal (default: 6722248921586908930):

Activation/Expiration time.
The certificate will expire in (days): 3650
Extensions.Does the certificate belong to an authority? (y/N): Y
Path length constraint (decimal, -1 for no constraint):
Is this a TLS web client certificate? (y/N): Y
Will the certificate be used for IPsec IKE operations? (y/N):
Is this a TLS web server certificate? (y/N): Y
Enter a dnsName of the subject of the certificate: CA_hostname
Enter a dnsName of the subject of the certificate:
Enter a URI of the subject of the certificate:
Enter the IP address of the subject of the certificate: CA_IP_Address
Will the certificate be used for signing (DHE and RSA-EXPORT ciphersuites)? (Y/n):  Y
Will the certificate be used for encryption (RSA ciphersuites)? (Y/n): Y
Will the certificate be used to sign OCSP requests? (y/N):
Will the certificate be used to sign code? (y/N):
Will the certificate be used for time stamping? (y/N):
Will the certificate be used to sign other certificates? (y/N): Y
Will the certificate be used to sign CRLs? (y/N):
Enter the URI of the CRL distribution point:
X.509 Certificate Information:
        Version: 3
        Serial Number (hex): 5d4a39c736f0bf02
        Validity:
                Not Before: Wed Aug 07 02:39:03 UTC 2019
                Not After: Sat Aug 04 02:39:03 UTC 2029
        Subject: CN=common_name_for_CA,OU=Org_unit_name,O=Org_name,L=CountyName_or_Locale,ST=state_prov,C=Country_code,CA_user_email_address
        Subject Public Key Algorithm: RSA
        Algorithm Security Level: High (3072 bits)
                Modulus (bits 3072):
                               00:a5:b2:d6:5d:33:2c:79:2d:9c:79:f4:7b:0b:27:ef
                               20:29:ff:21:0c:19:11:22:c1:17:26:fc:46:5c:bb:c0
                               f6:9d:d0:ff:0d:4d:9e:25:18:62:53:8b:c6:4e:8b:05
...
                               03:21:7d:87:af:2b:a2:0b:42:ee:45:36:d7:14:aa:e8
                               6e:c1:25:4d:5d:66:db:fc:82:0c:92:69:66:04:70:a7
                               5b
                Exponent (bits 24):
                        01:00:01
        Extensions:
                Basic Constraints (critical):
                        Certificate Authority (CA): TRUE
                Key Purpose (not critical):
                        TLS WWW Client.
                        TLS WWW Server.
                Subject Alternative Name (not critical):
                        DNSname: CA_host_name
                        IPAddress: CA_IP_Address
                Key Usage (critical):
                        Digital signature.
                        Key encipherment.
                        Certificate signing.
                Subject Key Identifier (not critical):
                               2b3c1e34e5a0347b6e62fd893430fa0b20d2d0a3
Other Information:
        Public Key ID:
                2b3c1e34e5a0347b6e62fd893430fa0b20d2d0a3
        Public key's random art:
                +--[ RSA 3072]----+
                |                 |
                | .               |
                |. o o . .        |
                | + o + +         |
                |E . = + S        |
                |o. . O . .       |
                |  o o @ .        |
                |   + = B .       |
                |    o.o o        |
                +-----------------+

Is the above information ok? (y/N): y
Signing certificate...
#
    3. ca-key.pemファイルを保護します。
      ファイルを安全な場所に配置します。root以外のユーザーが、(読取り権限でも)証明書にアクセスできないことを確認します。 
      # chmod 600 ca-key.pem
  2. マシン証明書を生成します。

    rsyslogドキュメントの「マシン証明書の生成」のステップに従います。

    # certtool --generate-privkey --outfile machine-key.pem --sec-param high
Generating a 3072 bit RSA private key...

    このコマンドはExadataの管理者が実行できます。出力ファイルはCAに送信されます。

    # certtool --generate-request --load-privkey machine-key.pem --outfile request.pem
Generating a PKCS #10 certificate request...
Common name: Trusted_server
Organizational unit name: Org_unit_name
Organization name: Org_name
Locality name: CountryName_or_Locale
State or province name: state_prov
Country name (2 chars): Country_code
Enter the subject's domain component (DC):
UID:
Enter a dnsName of the subject of the certificate: Trusted_server_hostname
Enter a dnsName of the subject of the certificate:
Enter a URI of the subject of the certificate:
Enter the IP address of the subject of the certificate: Trusted_server_IP
Enter the e-mail of the subject of the certificate:
Enter a challenge password:
Does the certificate belong to an authority? (y/N):
Will the certificate be used for signing (DHE and RSA-EXPORT ciphersuites)? (Y/n): Y
Will the certificate be used for encryption (RSA ciphersuites)? (Y/n): Y
Will the certificate be used to sign code? (y/N):
Will the certificate be used for time stamping? (y/N):
Will the certificate be used for IPsec IKE operations? (y/N):
Will the certificate be used to sign OCSP requests? (y/N):
Is this a TLS web client certificate? (y/N): Y
Is this a TLS web server certificate? (y/N): Y

    このコマンドは、前述のコマンドで生成されたリクエストを使用して、CA管理者が実行します。この例での各プロンプトへの応答を確認します。

    #certtool --generate-certificate --load-request request.pem --outfile machine-cert.pem 
 --load-ca-certificate ca.pem --load-ca-privkey ca-key.pem
Generating a signed certificate...
Enter the certificate's serial number in decimal (default: 6722252284267403216):

Activation/Expiration time.
The certificate will expire in (days): 3650

Extensions.
Do you want to honour the extensions from the request? (y/N):
Does the certificate belong to an authority? (y/N):
Is this a TLS web client certificate? (y/N): y
Will the certificate be used for IPsec IKE operations? (y/N):
Is this a TLS web server certificate? (y/N): y
Enter a dnsName of the subject of the certificate: Trusted_server
Enter a dnsName of the subject of the certificate:
Enter a URI of the subject of the certificate:
Enter the IP address of the subject of the certificate: Trusted_server_IP_addr
Will the certificate be used for signing (DHE and RSA-EXPORT ciphersuites)? (Y/n): y
Will the certificate be used for encryption (RSA ciphersuites)? (Y/n): y
Will the certificate be used to sign OCSP requests? (y/N):
Will the certificate be used to sign code? (y/N):
Will the certificate be used for time stamping? (y/N):
X.509 Certificate Information:
        Version: 3
        Serial Number (hex): 5d4a3cd6265117d0
        Validity:
                Not Before: Wed Aug 07 02:52:06 UTC 2019
                Not After: Sat Aug 04 02:52:06 UTC 2029
        Subject: OU=Org_unit_name,O=Org_name,L=CountryName_or_Locale,ST=state_prov,C=Country_code
        Subject Public Key Algorithm: RSA
        Algorithm Security Level: High (3072 bits)
                Modulus (bits 3072):
                               00:cf:f6:44:d4:e0:a8:b5:e6:48:8b:26:cb:59:c4:47
                               c5:f7:03:5f:99:88:ac:ed:94:d4:90:92:e4:61:75:4c
                               67:c4:16:c2:bf:31:40:f4:92:1e:94:73:08:d1:d5:3a
...
                               14:2f:08:02:74:f2:43:40:37:29:bd:6e:92:a6:07:6e
                               99:1e:e5:67:b8:0c:eb:a7:3d:9b:a5:35:46:8c:d3:e4
                               f7
                Exponent (bits 24):
                        01:00:01
        Extensions:
                Basic Constraints (critical):
                        Certificate Authority (CA): FALSE
                Key Purpose (not critical):
                        TLS WWW Client.
                        TLS WWW Server.
                Subject Alternative Name (not critical):
                        DNSname: Trusted_server
                        IPAddress: Trusted_server_IP_addr
                Key Usage (critical):
                        Digital signature.
                        Key encipherment.
                Subject Key Identifier (not critical):
                               7c343773a33cdbc6113fd05b3418ad129e9c4a64
                Authority Key Identifier (not critical):
                               2b3c1e34e5a0347b6e62fd893430fa0b20d2d0a3
Other Information:
        Public Key ID:
                7c343773a33cdbc6113fd05b3418ad129e9c4a64
        Public key's random art:
                +--[ RSA 3072]----+
                |             .+..|
                |         E . ..o.|
                |        o = B.=..|
                |       . o X *.+o|
                |        S o = .o.|
                |         o   = ..|
                |            . +  |
                |             .   |
                |                 |
                +-----------------+

Is the above information ok? (y/N): y
Signing certificate...
  3. rsyslogdサーバーを構成します。

    指定されたrsyslogdサーバーに証明書をインストールします。サーバーには、machine-cert.pem、machine-key.pemおよびca.pemのコピーが必要です。これらの証明書を/etc/pki/rsyslog/rsyslog.confファイルに追加します。

    root以外のユーザーが、(読取り権限でも)証明書にアクセスできないことを確認します。 

    # chmod 600 cert_name.pem

    CAからの証明書を持つドメインのすべてのマシンからのメッセージを受け入れるように、サーバーを構成します。この設定では、ワイルドカードを使用して、新しいシステムを簡単に追加できます。ワイルドカードを使用すると、*.domainと一致する名前を持つシステムからのメッセージをサーバーが受け入れることができます。たとえば、ドメインがexample.netの場合、異なるドメイン・ツリーの許可されたピアを受け入れるには、次の構成を使用します。 

    $InputTCPServerStreamDriverPermittedPeer "*.example.net","*.example.com"

    次の例は、rsyslogd中央サーバーのサンプルの/etc/pki/rsyslog/rsyslog.confファイルを示しています。この例では、rsyslogdサーバーを構成して、任意のサーバーからのメッセージをポート10514で受け入れます。 

    $ModLoad imtcp
# make gtls driver the default and set certificate files
$DefaultNetstreamDriver="gtls"
$DefaultNetstreamDriverCAFile="/etc/pki/rsyslog/ca.pem"
$DefaultNetstreamDriverCertFile="/etc/pki/rsyslog/machine-cert.pem"
$DefaultNetstreamDriverKeyFile="/etc/pki/rsyslog/machine-key.pem")

$InputTCPServerStreamDriverAuthMode x509/name 
$InputTCPServerStreamDriverPermittedPeer * 
$InputTCPServerStreamDriverMode 1 # run driver in TLS-only mode 
$InputTCPServerRun 10514 # start up listener at port 10514
  4. rsyslogdプロセスを再開します。
    #service rsyslog stop

#service rsyslog start
4.5.2.3 SYSLOG暗号化のためのクライアントの構成

サーバーIDが既知の場合にのみサーバーIDをチェックしてメッセージを送信するように、クライアントを構成します。

この構成により、悪意のある実行者がsyslogデータにアクセスできなくなります。これらのステップは、syslogクライアントを実行している各サーバーで実行する必要があります。

このタスクを開始する前に、CAサーバーおよび中央rsyslogdサーバーの構成のステップを完了しておく必要があります。この手順では、rsyslogd中央サーバーのIPアドレスとポート番号が必要になります。

  1. ca.pem、machine-key.pemおよびmachine-cert.pem証明書を中央rsyslogdサーバーからクライアント・サーバーの/etc/pki/rsyslog/ディレクトリにコピーします。
  2. CellCLIまたはDBMCLIを使用して、クライアント・サーバーのsyslogconf属性を変更します。
    CellCLIまたはDBMCLIコマンドは、syslogconfに指定した値をrsyslog.confファイルに追加し、syslogdプロセスを再起動します。

    ストレージ・サーバー・クライアントの場合は、次のようなコマンドを使用します。

    ALTER CELL syslogconf=('$DefaultNetstreamDrivergtls',\
'$DefaultNetstreamDriverCAFile /etc/pki/rsyslog/ca.pem',\
'$DefaultNetstreamDriverCertFile /etc/pki/rsyslog/machine-cert.pem',\
'$DefaultNetstreamDriverKeyFile /etc/pki/rsyslog/machine-key.pem',\
'$ActionSendStreamDriverAuthMode x509/name',\
'$ActionSendStreamDriverPermittedPeer *',\
'$ActionSendStreamDriverMode 1','user.* @@rsyslogd_server_IP_address:port')

    データベース・サーバーにsyslog暗号化を構成する場合は、DBMCLIを使用し、前述のコマンドのALTER CELLをALTER DBSERVERに置き換えます。

  3. syslogconf属性が正しく更新されたことを確認します。
    CellCLI> LIST CELL ATTRIBUTES syslogconf
      $DefaultNetstreamDriver               gtls
      $DefaultNetstreamDriverCAFile         /etc/pki/rsyslog/ca.pem
      $DefaultNetstreamDriverCertFile       /etc/pki/rsyslog/machine-cert.pem
      $DefaultNetstreamDriverKeyFile        /etc/pki/rsyslog/machine-key.pem
      $ActionSendStreamDriverAuthMode       x509/name
      $ActionSendStreamDriverPermittedPeer  * 
      $ActionSendStreamDriverMode           1  
      user.*                                @@rsyslogd_server_IP_address:port

    データベース・サーバーにsyslog暗号化を構成する場合は、DBMCLIを使用し、前述のコマンドのLIST CELLをLIST DBSERVERに置き換えます。

  4. syslog情報を暗号化する必要がある各クライアント・サーバーで、これらのステップを繰り返します。
4.5.2.4 syslogの暗号化が有効であることの確認

rsyslogの暗号化の構成後、基本的なチェックを実行して暗号化が機能していることを検証できます。

  1. Syslog構成を検証します。

    データベース・サーバーでは、次のコマンドを使用します。

    DBMCLI> ALTER DBSERVER VALIDATE SYSLOGCONF 'kern.info'

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

    CellCLI> ALTER CELL VALIDATE SYSLOGCONF 'kern.info'
  2. /var/log/messagesでメッセージを確認します。
  3. /var/log/messagesでrsyslogのエラー・メッセージを確認します。
  4. メッセージが暗号化された形式で送信されることを検証するには、tcpdumpユーティリティを使用します。

    ターゲット・サーバーで次のコマンドを使用します。

    % tcpdump -A src source-server-IP-address

    tcpdumpコマンドからの出力は、読取り可能なテキストではない必要があります。

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

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

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

4.5.3.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.5.3.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.5.3.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.5.3.4 Exadataソフトウェア更新時のAIDEアラートの管理

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

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

ノート:

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

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

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

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

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

ノート:

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

関連項目

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

4.5.4.1 ILOMバージョン5のSSHキーの再生成

ILOMバージョン5を搭載したシステムでは、キー・サイズが3072ビットSSHキーを作成できます。

以前のバージョンのIntegrated Lights Out Manager (ILOM)は1024ビットのSSHキーをサポートしていますが、ILOMバージョン5は3072ビットのSSHキーをサポートしています。

既存のExadataシステムをILOMバージョン5にアップグレードする場合、アップグレードされたシステムでは元の1024ビットSSHキーが保持されます。3072ビットSSHキーを使用するには、次のコマンドを使用して、ILOMサービス・プロセッサでSSHキーを手動で再生成する必要があります。 

-> set /SP/services/ssh generate_new_key_type=rsa generate_new_key_action=true

SSHキーを再生成した後、ILOMに問い合せて公開キーの値を報告できます。

-> show /SP/services/ssh/keys/rsa

/SP/services/ssh/keys/rsa 
          Targets: 
 
          Properties:     
            fingerprint = hex-id     
            fingerprint_algorithm = SHA1     
            length = 3072     
            privatekey = (Cannot show property)
            publickey = public-key-value

ノート:

ILOMバージョン5で最初にデプロイされたシステムは、デフォルトで3072ビット・キーを使用します。

4.5.5 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を使用します。

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