4 Oracle Exadata Database Machineの保護
この章では、Oracle Exadata Database Machineをセキュアに保つためのポリシーと手順について説明します。
- ハードウェアの保護
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のすべてのコンポーネントにシリアル番号があります。
- ラックのシリアル番号の取得
ラックのシリアル番号を取得するには、ipmitoolユーティリティを使用します。 - ラック・コンポーネントのシリアル番号の取得
CheckHWnFWProfileコマンドを使用すると、ほとんどのシステム・コンポーネントのシリアル番号を表示できます。 - Cisco 9336Cまたは9348スイッチのラックのシリアル番号の取得
シリアル番号を取得するには、スイッチでshow license host-id
コマンドを使用します。 - Sun Datacenter InfiniBand Switch 36のラックのシリアル番号の取得
シリアル番号を取得するには、スイッチでshowfruinfo
コマンドを使用します。 - Cisco 4948イーサネット・スイッチのシリアル番号の取得
シリアル番号を取得するには、スイッチでsh inventory
コマンドを使用します。
関連項目
4.1.1 ラックのシリアル番号の取得
ラックのシリアル番号を取得するには、ipmitoolユーティリティを使用します。
Oracleサポート・サービスとやり取りする場合、ラックのCSI番号はラックのシリアル番号に基づきます。
親トピック: ハードウェアの保護
4.1.2 ラック・コンポーネントのシリアル番号の取得
CheckHWnFWProfileコマンドを使用すると、ほとんどのシステム・コンポーネントのシリアル番号を表示できます。
親トピック: ハードウェアの保護
4.1.3 Cisco 9336Cまたは9348スイッチのラックのシリアル番号の取得
シリアル番号を取得するには、スイッチでshow license host-id
コマンドを使用します。
親トピック: ハードウェアの保護
4.1.4 Sun Datacenter InfiniBand Switch 36のラックのシリアル番号の取得
シリアル番号を取得するには、スイッチでshowfruinfo
コマンドを使用します。
親トピック: ハードウェアの保護
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特権ユーザーおよび多元的なアクセス制御、データ分類、透過的データ暗号化、監査、監視およびデータ・マスキングを使用して、顧客は既存のアプリケーションに対する変更を必要としない信頼性の高いデータ・セキュリティ・ソリューションをデプロイできます。
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
の値に戻ります。通常、セルでソフトウェアの更新を必要とするときに、セルのアクセス・レベルを変更します。
アクセス・レベルは、ストレージ・サーバーの再起動後も維持されます。
- セルのロック
セルをロックするには、そのaccessLevelPerm
属性をremoteLoginDisabled
に設定します。 - セルの一時的なロック解除
ストレージ・サーバーへのSSHログインを必要とするメンテナンス、アップグレードなどの操作を実行するために、ロックされたストレージ・サーバーまたはセルを短時間ロック解除できます。 - セルの現在のアクセス・レベルの確認
現在のアクセス・レベルを判別するには、セルのaccessLevelPerm
属性およびaccessLevelTemp
属性を表示します。 - 管理サーバーからのアクセス・レベルのアラート
accessLevelPerm
属性が変更されたときに、ステートレス・アラートが生成されます。
4.3.1 セルのロック
セルをロックするには、そのaccessLevelPerm
属性をremoteLoginDisabled
に設定します。
accessLevelPerm
属性を変更する権限を持つユーザーを使用する必要があります。
親トピック: ストレージ・サーバーでの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
属性およびaccessLevelTemp
属性を表示します。
親トピック: ストレージ・サーバーでのSSHの無効化
4.3.4 管理サーバーからのアクセス・レベルのアラート
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インスタンスに共有ストレージ・プールを提供します。
- Exadata Storage Serverのセキュリティ・モードについて
Oracle Exadata System Softwareのセキュリティは、オープン・セキュリティ、ASMを有効範囲にしたセキュリティ、またはDBを有効範囲にしたセキュリティに対応しています。 - ASMを有効範囲にしたセキュリティとDBを有効範囲にしたセキュリティのベスト・プラクティス
セキュリティを設定する際には、すべてのストレージ・サーバーで構成が同じであることが重要です。 - セキュリティ・キーについて
Oracle Exadata System Softwareでは、キーを使用してクライアントを識別し、グリッド・ディスクへのアクセス権を決定します。 - Oracle Exadata Storage ServerのASMを有効範囲にしたセキュリティの設定
ASMを有効範囲にしたセキュリティを構成するには、データベース・サーバーとストレージ・サーバーの両方でアクションを実行する必要があります。 - Oracle Exadata Database MachineでのDBを有効範囲にしたセキュリティの設定
DBを有効範囲にしたセキュリティを構成する際には、データベースおよびストレージ・サーバーの両方でアクションを実行します。 - ASMを有効範囲にしたセキュリティまたはDBを有効範囲にしたセキュリティのセキュリティ・キーの変更
ASMを有効範囲にしたセキュリティまたはDBを有効範囲にしたセキュリティで使用されるキーを変更できます。 - Cell-to-Cell操作の有効化
Oracle Exadata Database Machineに対して、ASMを有効範囲にしたセキュリテまたはDBを有効範囲にしたセキュリティを構成した場合は、Cell-to-Cell操作が制限されないようにアクセス制御を構成する必要があります。 - ASMを有効範囲にしたセキュリティまたはDBを有効範囲にしたセキュリティの削除
オープン・セキュリティ・モデルに戻す場合は、ASMを有効範囲にしたセキュリティを削除する前に、グリッド・ディスクのDBを有効範囲にしたセキュリティを削除する必要があります。
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つしかない場合にも適用されます。
DBを有効範囲にしたセキュリティ
DBを有効範囲にしたセキュリティを使用すると、Oracle Databaseインスタンスのアクセスを特定のグリッド・ディスクのセットのみに制限できます。データベース・インスタンスは、データベースのOracle ASMディスク・グループによって使用されるすべてのグリッド・ディスクにアクセスできる必要があります。これらのOracle ASMディスク・グループによって使用されるグリッド・ディスクは、他のOracle ASMディスク・グループでは使用できません。
DBを有効範囲にしたセキュリティ・モードは、複数のデータベースがグリッド・ディスクにアクセスする場合に適しています。DBを有効範囲にしたセキュリティを使用すると、データベースに関連付けられたOracle ASMディスク・グループによって使用されるグリッド・ディスクのみにデータベース・アクセスを制限できます。
図sagug_031-db-scoped-security.epsの説明
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
ユーティリティを使用して構成を変更し、一貫性を確保してユーザー・エラーの可能性を排除します。
関連項目
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ソフトウェアを、異なるオペレーティング・システム・ユーザーが所有する必要があります。
ストレージ・サーバーで、セルのアクセス制御リスト(ACL)にセキュリティ・キーを格納するには、ASSIGN KEY
コマンドを使用します。ALTER GRIDDISK
コマンドは、AvailableTo
属性で個々のグリッド・ディスクのアクセス権を設定する際に使用します。グリッド・ディスクにアクセスするには、セルACLのセキュリティ・キーがクライアントのセキュリティ・キーと一致しており、クライアントの一意の名前がグリッド・ディスクのAvailableTo
属性に含まれている必要があります。
Oracle ASMおよびデータベースに使用される識別名は一意にする必要があります。ただし、一部の環境では、DB_UNIQUE_ID
に同じ値を持つデータベースが複数存在します。各データベースは、記憶域に異なるOracle ASMクラスタを使用します。Oracle Exadata System Softwareリリース12.2.1.1.0以降では、Oracle ASMクラスタに基づいて、ASMを有効範囲にしたセキュリティを定義できます。ASSIGN KEY
コマンドでは、ASMCLUSTER
キーワードを使用します。ASMCLUSTER
キーワードを使用すると、データベース名はOracle ASMの一意識別子で修飾され、同じDB_UNIQUE_ID
を持つ場合でも、データベースごとに一意のIDが作成されます。各Oracle ASMクラスタ内では、データベース名は一意である必要があります。
ASMを有効範囲にしたセキュリティまたはDBを有効範囲にしたセキュリティを構成する場合は、Cell-to-Cell操作を有効にするためにセキュリティ・キーを構成する必要があります。ストレージ・サーバーまたはセルごとにキーを作成し、ASSIGN KEY FOR LOCAL CELL
コマンドを使用してセルのローカル・キーとしてそのキーを割り当てます。次に、ASSIGN KEY FOR REMOTE CELL
コマンドを使用して現在のセルでCell-to-Cell操作を実行する他のセルのキーを割り当てます。
例4-5 Exadata Storage Securityのセキュリティ・キーの作成
任意のストレージ・サーバーで次のコマンドを使用して、一意のセキュリティ・キーを生成します。このキーは、ASMを有効範囲にしたセキュリティまたはDBを有効範囲にしたセキュリティの構成に使用されます。
CellCLI> CREATE KEY
66e12adb996805358bf82258587f5050
例4-6 cellkey.oraファイルのエントリ
この例では、cellkey.ora
ファイルのエントリを示しています。
key=66e12adb996805358bf82258587f5050
asm=cluster1
関連項目
4.4.4 Oracle Exadata Storage ServerのASMを有効範囲にしたセキュリティの設定
ASMを有効範囲にしたセキュリティを構成するには、データベース・サーバーとストレージ・サーバーの両方でアクションを実行する必要があります。
grid
であることを前提としています。
4.4.5Oracle Exadata Database MachineのDBを有効範囲にしたセキュリティの設定
DBを有効範囲にしたセキュリティを構成する際には、データベースおよびストレージ・サーバーの両方でアクションを実行します。
これらのステップでは、単一のOracle ASMクラスタと、そのOracle ASMクラスタのクライアントであるデータベースに対して、DBを有効範囲にしたセキュリティを構成します。これらのステップの例では、Oracle ASMソフトウェア所有者がユーザーgrid
で、各Oracle Databaseホームが別々のオペレーティング・システム・ユーザーによって所有されていることを前提としています。
- データベース・クライアントで使用されるOracle Databaseクライアントの一意の名前とOracle ASMクラスタとの組合せは、環境内で一意である必要があります。
- Oracle Grid Infrastructureソフトウェアのインストールおよび各Oracle Databaseソフトウェアのインストールは、異なるオペレーティング・システム・ユーザーが所有する必要があります。
- 各データベース・クライアントには、個別のOracle ASMディスク・グループが必要です。Oracle ASMディスク・グループによって使用されるグリッド・ディスクは、1つのOracle ASMディスク・グループにのみ割り当てることができます。
4.4.6 ASMを有効範囲にしたセキュリティまたはDBを有効範囲にしたセキュリティのセキュリティ・キーの変更
ASMを有効範囲にしたセキュリティまたはDBを有効範囲にしたセキュリティで使用されるキーを変更できます。
- ASMCLUSTERのASMを有効範囲にしたセキュリティ・キーのアップグレード
Oracle Exadata System Softwareリリース12.2.1.1.0以降では、Oracle ASMクラスタに基づいて、ASMを有効範囲にしたセキュリティを定義できます。 - ASMを有効範囲にしたセキュリティに割り当てられたキー値の変更
ASMを有効範囲にしたセキュリティを使用するように構成されたOracle ASMクライアントに使用するキー値を変更できます。 - DBを有効範囲にしたセキュリティに割り当てられたキー値の変更
DBを有効範囲にしたセキュリティを使用するように構成されたOracle ASMクライアントによって使用されるキー値を変更できます。
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
キーに変更する場合は、次のステップを実行します。
4.4.6.2 ASMを有効範囲にしたセキュリティに割り当てられたキー値の変更
ASMを有効範囲にしたセキュリティを使用するように構成されたOracle ASMクライアントに使用するキー値を変更できます。
4.4.7 Cell-to-Cell操作の有効化
Oracle Exadata Database Machineに対して、ASMを有効範囲にしたセキュリティまたはDBを有効範囲にしたセキュリティを構成した場合は、Cell-to-Cell操作が制限されないようにアクセス制御を構成する必要があります。
セルが直接相互に通信する必要がある場合に、他のセルにアクセスできるようにするには、各セルにセル・キーを設定する必要があります(たとえば、オフロード操作の場合)。
- 単純セル・アクセスの構成
インバウンドとアウトバウンド両方のCell-to-Cellトラフィックに単一のキーを使用できます。 - LOCALおよびREMOTEのセル・キーの構成
一意のキーを持つように各セルを設定すると、アクセス権を付与する複数のリモート・セル・キーを許容できます。 - 単純セル・キー、LOCALキーおよびREMOTEキー間の変更
新しいキーを別のフォーマットで割り当てる前に、既存のセル・キーを削除する必要があります。これにより、ストレージ・サーバーでリモート・キーとローカル・キーが異なるために誤って構成が中断されるのを防ぎます。
4.4.7.1 単純セル・アクセスの構成
インバウンドとアウトバウンド両方のCell-to-Cellトラフィックに単一のキーを使用できます。
セルが直接相互に通信する必要がある場合に、他のセルにアクセスできるようにするには、単一のキーを作成できます(たとえば、オフロード操作の場合)。ASSIGN KEY
コマンドの単純なバージョンを使用して、すべてのセルにそのキーを割り当てます。
セル・キーのavailableTo
属性の更新にALTER GRIDDISK
コマンドを使用する必要はありません。セルで既存のアクセス制御ポリシーを使用するには、リモート・ターゲット・セルで元のクライアントが識別されるようにします。
親トピック: Cell-to-Cell操作の有効化
4.4.7.2 LOCALおよびREMOTEのセル・キーの構成
一意のキーを持つように各セルを設定すると、アクセス権を付与する複数のリモート・セル・キーを許容できます。
セルが直接相互に通信する必要がある場合に、他のセルにアクセスできるようにするには、セル・キーを作成できます(たとえば、オフロード操作の場合)。すべてのセルで使用される単一のキーを作成するか、LOCAL
キーワードおよびREMOTE
キーワードを使用して個々のセルに一意のキーを割り当てることができます。
キー更新中に一時的に複数のセル・キーを使用したり、特定のセルへのアクセスを制限する場合があります。この場合、ASSIGN KEY
コマンドでLOCAL
またはREMOTE
を指定する必要があります。
親トピック: Cell-to-Cell操作の有効化
4.4.7.3 単純セル・キー、LOCALキーおよびREMOTEキー間の変更
新しいキーを別のフォーマットで割り当てる前に、既存のセル・キーを削除する必要があります。これにより、ストレージ・サーバーでリモート・キーとローカル・キーが異なるために誤って構成が中断されるのを防ぎます。
LOCAL
またはREMOTE
キーをセル・キーに割り当てようとすると(つまり、すでにASSIGN KEY FOR CELL
コマンドを実行しており、明示的にLOCAL
またはREMOTE
キーに切り替えようとすると)、次のエラーが発生します。
CELL-02911: Remove existing CELL key before assigning LOCAL CELL key
同様に、ローカルまたはリモートのセル・キーがすでに存在する場合にASSIGN KEY FOR CELL
を実行すると、次のエラーが表示されます。
CELL-02912: Remove all existing LOCAL and REMOTE CELL keys before assigning a CELL key.
Use LIST KEY FOR CELL to show all LOCAL and REMOTE CELL keys, then use ASSIGN KEY to assign an
empty value to each.
単純セル・キーを割り当てる前に、既存のLOCAL
およびREMOTE
のセル・キーをすべて削除する必要があります。
- 各ストレージ・サーバーの構成済キーを表示します。
- 既存のセル・キーを削除します。
- 必要な形式でキーを再作成します。
- 単純セル・キーをローカルおよびリモート・キーに変更するには、「LOCALおよびREMOTEのセル・キーの構成」のステップに従います。
- ローカルおよびリモート・セル・キーを単純セル・キーに変更するには、「単純セル・アクセスの構成」のステップに従います。
親トピック: Cell-to-Cell操作の有効化
4.4.8 ASMを有効範囲にしたセキュリティまたはDBを有効範囲にしたセキュリティの削除
オープン・セキュリティ・モデルに戻す場合は、ASMを有効範囲にしたセキュリティを削除する前に、グリッド・ディスクのDBを有効範囲にしたセキュリティを削除する必要があります。
セルのセキュリティを更新する前に、Oracle DatabaseおよびOracle ASMインスタンスをシャットダウンする必要があります。セキュリティ構成のすべての変更が完了したら、Oracle DatabaseおよびOracle ASMインスタンスを起動します。
- DBを有効範囲にしたセキュリティの削除
- ASMを有効範囲にしたセキュリティの削除
ストレージ・サーバー上のグリッド・ディスクにオープン・セキュリティを設定する場合は、DBを有効範囲にしたセキュリティを削除してから、ASMを有効範囲にしたセキュリティを削除できます。
4.4.8.1 DBを有効範囲にしたセキュリティの削除
グリッド・ディスクでDBを有効範囲にしたセキュリティを削除するには、次の手順を実行します。
例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
、db
3など)が構成されており、そのうち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を有効範囲にしたセキュリティを削除できます。
例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は、ハードウェア、デプロイされたアプリケーションおよびサービスの操作の問題に対処する統合されたソリューションを提供します。
- ネットワーク・セキュリティの維持
セキュリティ・ガイドラインに基づいてネットワークを構成した後は、定期的なレビューおよびメンテナンスが必要です。 - システム・ログ情報の暗号化
データベース・サーバーおよびストレージ・サーバー上の管理サーバー(MS)は、syslogconf
属性をサポートします。Oracle Exadata System Softwareリリース19.3.0以降では、ログの転送を暗号化できます。 - 未認可のオペレーティング・システム・アクセスに対するガード
AIDEは、システム上にファイルのデータベースを作成し、そのデータベースを使用してファイルの整合性を確認して、システム侵入を検出するユーティリティです。 - ソフトウェアおよびファームウェアの更新
効果的でプロアクティブなソフトウェア管理はシステム・セキュリティの重要な部分です。 - Oracle Exadata Database Machine外部のデータ・セキュリティの確保
Oracle Exadata Database Machineの外部に格納されているデータは、バックアップまたは取外し可能なハード・ドライブで保護することが重要です。
関連項目
4.5.1 ネットワーク・セキュリティの維持
セキュリティ・ガイドラインに基づいてネットワークを構成した後は、定期的なレビューおよびメンテナンスが必要です。
管理ネットワーク・スイッチの構成ファイルはオフラインで管理し、構成ファイルへのアクセスは認可された管理者のみに制限する必要があります。構成ファイルには各設定の説明がコメントとして含まれています。構成ファイルの静的コピーをソース・コード制御システムに保持することを検討してください。セキュアなホスト設定およびIntegrated Lights Out Manager (ILOM)設定を変更せず、有効なままにしておくには、クライアント・アクセス・ネットワークの定期的なレビューが必要です。さらに、設定の定期的なレビューによって、それらが変更されておらず、有効であることが確認されます。
システムへのローカル・アクセスとリモート・アクセスのセキュリティを確保するために、次のガイドラインに従ってください。
-
未認可アクセスを禁止することを明記したログイン・バナーを作成します。
-
必要に応じて、アクセス制御リストを使用して制限を適用します。
-
拡張セッションのタイムアウトを設定し、特権レベルを設定します。
-
スイッチへのローカル・アクセスとリモート・アクセスには、認証、認可、アカウンティング(AAA)機能を使用します。
-
侵入検知システム(IDS)のアクセスには、スイッチのポートのミラー化機能を使用します。
-
MACアドレスに基づいてアクセスを制限するには、ポート・セキュリティを実装します。Oracle Exadata Database Machineに接続されたスイッチのすべてのポートで自動トランキングを無効化します。
-
リモート構成を特定のIPアドレスに制限するときは、SSHを使用します。
-
最小限のパスワードの複雑度ルールとパスワードの有効期限ポリシーを設定することによって、ユーザーに強力なパスワードを使用することを要求します。
-
ロギングを有効にし、専用のセキュアなログ・ホストにログを送信します。
-
NTPおよびタイムスタンプを使用して正確な時間情報を含めるようにロギングを構成します。
-
可能性があるインシデントをログで確認し、組織のセキュリティ・ポリシーに従ってそれらをアーカイブします。
標準のFIPS 140 (連邦情報処理標準)はセキュリティと暗号化に関連しています。FIPS 140は、米国商務省の米国標準技術局(National Institute of Standards and Technology: NIST)によって発行されている一連の標準です。FIPS 140は遷移中のデータおよび保存データを保護します。コンピューティング環境内における暗号化コンポーネントのセキュリティ標準を規定します。FIPS 140は、コンピューティング環境が公開されたセキュリティ・レベルに準拠していることを文書化する必要のある組織にとって役立ちます。多数の政府機関や金融機関でFIPS 140認定システムが使用されています。
Oracle DatabaseレベルでFIPS 140を構成すると、Secure Sockets Layer (SSL)、透過的データ暗号化(TDE)、DBMS_CRYPTO PL/SQLパッケージおよびExadata Smart ScanでFIPS 140暗号モジュールを使用できるようになります。これにより、Smart Scanのオフロード操作の処理中にデータが保護されます。
4.5.2 システム・ログ情報の暗号化
データベース・サーバーおよびストレージ・サーバー上の管理サーバー(MS)は、syslogconf
属性をサポートします。Oracle Exadata System Softwareリリース19.3.0以降では、ログの転送を暗号化できます。
次のトピックでは、syslogとrsyslogが同じ意味で使用されます。これらはどちらもメッセージ・ロガーを参照します。
- syslogファイルの暗号化の概要
syslog情報の暗号化を構成するには、証明書とsyslogconf
属性を使用します。 - CAサーバーおよび中央rsyslogdサーバーの構成
syslogの転送を暗号化する前に、証明書を生成し、認証局(CA)として機能するホストがそれらに署名する必要があります。この手順を実行する必要があるのは1回のみです。 - SYSLOGの暗号化のためのクライアントの構成
サーバーIDが既知の場合にのみサーバーIDをチェックしてメッセージを送信するように、クライアントを構成します。 - syslogの暗号化が有効であることの確認
rsyslogの暗号化の構成後、基本的なチェックを実行して暗号化が機能していることを検証できます。
親トピック: セキュアな環境の維持
4.5.2.1 syslogファイルの暗号化の概要
syslog情報の暗号化を構成するには、証明書とsyslogconf
属性を使用します。
syslogconf
属性によってデータベース・サーバーのsyslogルールが拡張されます。この属性を使用すると、特定のリモートsyslogdサービスに対象のsyslogメッセージが転送されるように指定できます。MSでは、MSのsyslog構成に応じて、転送されたメッセージがファイル、コンソールまたは管理アプリケーションに渡されます。これにより、セキュリティ監査、データ・マイニングなどのために、様々なサーバーからのシステム・ログを集約し、集中化されたロギング・サーバーで調べることができます。
rsyslog暗号化を有効にするために必要なステップの概要は次のとおりです。
- 認証局(CA)を設定します。これには、
certtool
コマンドがある任意のノードを使用できます。Exadata以外のサーバーを使用することをお薦めします。CAが自己署名証明書を作成します。証明書の暗号化キーは、安全な場所に格納する必要があります。この証明書は、他の証明書に署名するために使用されます。 -
参加する各ノードの証明書を生成します。中央CAがない場合、Exadata管理者はCAで秘密キーと公開キーの両方を生成し、そのコピーを信頼できる各サーバーに配布できます。中央CAがある場合は、Exadata管理者が各サーバーの秘密キーを生成します。
-
中央CAを使用している場合は、Exadata管理者が証明書リクエストを作成します。次に、このリクエストはCA管理者に送信され、CA管理者は証明書(公開キーを含む)を生成します。その後、CA管理者は、署名付き証明書をExadata管理者に返送します。
-
各参加ノードに署名付き証明書をインストールします。中央CAを使用している場合は、Exadata管理者がCAによって署名された証明書をインストールします。中央CAを使用していない場合、Exadata管理者はCAで生成された秘密キーと公開キーのコピーをインストールします。
-
syslog中央サーバーを設定します。中央サーバーには
syslog.conf
設定が必要です。署名付き証明書も必要です。 -
CellCLIまたはDBMCLIを使用して、各クライアントでsyslogの暗号化を有効または無効にします。
これらのステップが完了すると、転送するsyslogが暗号化されます。
親トピック: システム・ログ情報の暗号化
4.5.2.2 CAサーバーおよび中央rsyslogdサーバーの構成
syslogの転送を暗号化する前に、証明書を生成し、認証局(CA)として機能するホストがそれらに署名する必要があります。この手順を実行する必要があるのは1回のみです。
親トピック: システム・ログ情報の暗号化
4.5.2.3 SYSLOG暗号化のためのクライアントの構成
サーバーIDが既知の場合にのみサーバーIDをチェックしてメッセージを送信するように、クライアントを構成します。
この構成は、中間者攻撃または単純な悪意のあるサーバーがsyslogデータにアクセスすることを防止します。これらのステップは、各クライアント・サーバーで実行する必要があります。
このタスクを開始する前に、CAサーバーおよび中央rsyslogdサーバーの構成のステップを完了しておく必要があります。この手順では、rsyslogd中央サーバーのIPアドレスとポート番号が必要になります。
親トピック: システム・ログ情報の暗号化
4.5.2.4 syslogの暗号化が有効であることの確認
rsyslogの暗号化の構成後、基本的なチェックを実行して暗号化が機能していることを検証できます。
親トピック: システム・ログ情報の暗号化
4.5.3 未認可のオペレーティング・システム・アクセスに対するガード
AIDEは、システム上にファイルのデータベースを作成し、そのデータベースを使用してファイルの整合性を確認して、システム侵入を検出するユーティリティです。
- Advanced Intrusion Detection Environment (AIDE)について
AIDEは、システムが侵害された場合に影響を受けるファイルを追跡するのに役立ちます。 - AIDEコンポーネントの管理
AIDEを管理するには、exadataAIDE
ユーティリティを使用できます。 - カスタムAIDEルールの追加
AIDEのメタデータの初期化ステップおよび日次cron
チェック中に特定のディレクトリの変更をチェックしないように、AIDEに指示できます。 - Exadataソフトウェア更新時のAIDEアラートの管理
ソフトウェアおよびハードウェアの更新とインストールは、オペレーティング・システム・ファイルのサイズおよび性質を変更する傾向があります。したがって、変更後には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]
: コマンド構文とヘルプ情報を出力します
4.5.3.3 カスタムAIDEルールの追加
AIDEのメタデータの初期化ステップおよび日次cron
チェック中に特定のディレクトリの変更をチェックしないように、AIDEに指示できます。
/opt/myapp
ディレクトリの内容の変更に関するアラートは発生しません。
4.5.4 ソフトウェアおよびファームウェアの更新
効果的でプロアクティブなソフトウェア管理はシステム・セキュリティの重要な部分です。
新しいリリースとソフトウェア・アップデートを介して、セキュリティの強化が導入されます。ソフトウェアの最新のリリース、およびすべての必要なセキュリティ・アップデートを装置にインストールすることをお薦めします。Oracle推奨パッチおよびセキュリティ・アップデートを適用することは、ベースライン・セキュリティを確立するためのベスト・プラクティスです。
Oracle Exadata Database Machineデータベース・サーバーおよびストレージ・サーバーのオペレーティング・システムとカーネルのアップデートは、Oracle Exadata System Softwareのアップデートで配信されます。配電ユニット(PDU)ファームウェアの更新は、ソフトウェアおよび他のファームウェアの更新とは別に処理されます。PDUでOracle Exadata Database Machineの最新の承認済ファームウェアが動作していることを確認してください。PDUファームウェアの更新は頻繁には発行されないため、通常は、Oracle Exadata System Softwareのアップグレード時にPDUファームウェア・リリースをチェックすれば十分です。
注意:
ネットワーク・スイッチなどのデバイスに搭載されたファームウェアには、パッチやファームウェア更新が必要なものもあります。関連項目
親トピック: セキュアな環境の維持
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を使用します。
親トピック: セキュアな環境の維持