ここでのトピック
Oracle Audit Vault and Database Firewallの安全なインストールを学習します。
Oracle Audit Vault Serverは、デフォルトで安全な状態でインストールされます。このため、デフォルト設定を変更する場合は注意して行うことが重要です。その変更によって設定のセキュリティが侵害される可能性があるためです。
関連項目:
インストールの詳細は、『Oracle Audit Vault and Database Firewallインストレーション・ガイド』を参照してください。
Oracle AVDFを使用したデータの保護を強化するには、アカウントの命名、パスワードの使用およびその他のガイドラインを考慮してください。
データを保護するために次のガイドラインに従うことを検討してください。
アカウント名とパスワード: Oracle Audit Vault ServerコンソールUI、およびroot
、support
、sys
アカウントにセキュアなパスワードを使用し、これらのパスワードを安全に保持します。
管理者アカウント: Oracle Audit Vault and Database Firewallの管理者アカウントを共有しないでください。
強力なパスワード・ポリシー: パスワード・ポリシーを作成してユーザーに強力なパスワードを使用するように強制します。
インストール済のアカウント: Oracle Audit Vault and Database Firewallには、オペレーティング・システム・アカウントおよびデータベース・アカウントが組み込まれています。このタイプの新規アカウントを追加しないでください。既存のアカウントはロック解除しないでください。それを行うと、Oracle Audit Vault and Database Firewallシステムのセキュリティが損なわれる場合があります。
セキュアなアーカイブ: Oracle Audit Vault and Database Firewallは、ネットワーク経由でアーカイブ・データを送信します。アーカイブ先と中間のネットワーク・インフラストラクチャの両方を保護します。
リモート・アクセスを付与するときは、次のガイドラインに従います。
特定のタスクに必要である場合にのみアクセス権を付与し、その後、そのタスクが完了したらアクセス権を取り消します。
IPアドレスによりアクセスを制限します。これはシステムのインストール後すぐに実行します。
ターミナル(シェル)アクセス権は、パッチ更新の実行時、またはマニュアルもしくはOracleサポートによって求められた場合にのみ付与します。
セキュリティについては、次の推奨事項に従うことをお薦めします。
Database Firewallを使用して不要なトラフィックをブロックしている場合は、データベース・クライアントとデータベースの間のすべてのデータ・フローがDatabase Firewallを経由するようにします。これには、リクエストとレスポンスの両方が含まれます。
サイトに適切なセキュリティ対策を使用してAudit Vault ServerおよびDatabase Firewallアプライアンスを実行しているコンピュータへのアクセスを制御します。アクセス権を特定のユーザーにのみ付与します。
パスワードがベスト・プラクティスに準拠していることを確認します。
管理者と監査者のロールをそれぞれ別のユーザーに割り当て、管理者と監査者の業務を分離します。
Audit Vault Serverのユーザーに適切な管理者ロール、スーパー管理者ロール、監査者ロールおよびスーパー監査者ロールを割り当てます。
デフォルトでは、Oracle AVDFに関連するアカウント(Oracle OSユーザー・アカウント、Oracle Gridアカウント、任意のOracle Database Vaultアカウント(たとえば、DV_OWNER
ロールとDV_ACCTMGR
ロールが付与されたユーザー)がロックされます。)これらのアカウントがロックされたままになっていることを確認します。
外部ネットワークの重要な依存関係を考慮して、Oracle AVDF構成のセキュリティを確保します。
Audit Vault ServerまたはDatabase Firewallに外部ネットワーク・サービスを追加する場合は、それらのサービスをデプロイメントの信頼モデルに含めます。
たとえば、DNSサーバーをアプライアンスに追加する場合は、DNSサーバーを信頼して、検索するホスト名に関する正しい情報を提供します。何者かがDNSサーバーを侵害している場合、そのホスト名を使用してAudit Vault ServerまたはDatabase Firewallがアクセスするネットワーク・エンドポイントを制御できます。
NFSやNTPなどの他のサービスにも類似する信頼関係があります。
このため、次のものが適切に保護されている場合にのみ、Audit Vault ServerまたはDatabase Firewallにネットワーク・サービスを追加します。
Database Firewallのネットワーク暗号化の処理について学習します。
Database Firewallは、データベース層とアプリケーション層の間にデプロイします。Oracle Native Network Encryptionの使用時は、Database FirewallでOracleデータベースとの間のトラフィックを復号化できます。Oracle以外のデータベースの場合、およびTLSネットワーク暗号化を使用するOracleデータベースの場合は、データベース層とアプリケーション層の間のSQLトラフィックが暗号化されていると、Database Firewallで、このSQLトラフィックに対する保護ポリシーを解釈できず、強制できません。
SSLまたはTLS終了ソリューションを使用して、SQLトラフィックがDatabase Firewallに届く直前にそのトラフィックを終了できます。
この項は、Database Firewallに関係があります。
Database Firewallポリシー強制は、データベース・クライアントとサーバー間のSQLトラフィックを取得して理解することに依存しています。Database Firewallではアプリケーション層とデータベース・サーバー間のネットワーク・トラフィックのみを分析するため、データベース・サーバー自体から直接起動されるSQLは確認できないことに注意してください。Database Firewallが確認できないSQL文の一般的なタイプには、ストアド・プロシージャやコールアウトから実行されるシステム付属のSQLやユーザー定義のSQL、Oracleデータベース内のDBMS_JOB
またはDBMS_SCHEDULER
PL/SQLパッケージによって作成されたSQLなどのバックグラウンド・ジョブから実行されるSQL、DDLや他のSQL文から間接的に実行されるSQLなどがあります。これらのタイプのSQL文はOracle AVDFの監査機能を使用して捕捉できます。
Database Firewallは、その実行コンテキスト全体をネットワーク・トラフィックから取得した情報を使用して作成します。ただし、強制は、サーバー上のコンテキスト情報に基づています。このコンテキストの欠落は、ノベルティ・ポリシーで使用する識別子の解決方法に影響を与えます。
次のタイプのデータベース・アクセス・パスでのOracle AVDFの動作に注意してください。
SQL以外のプロトコルのアクセス。データベース・プラットフォームでは、データベースSQLベースのプロトコルの他に様々なネットワーク・プロトコルをサポートしています。たとえば、Oracle Databaseでは、データベースに格納されているデータに対してHTTP、FTP、アドバンスト・キューイング、ダイレクト・パスおよびNFSアクセスがサポートされています。Database Firewallでポリシー強制が適用されるのは、データベースへのSQLベースのアクセスに対してのみです。Database Firewallで理解可能なプロトコルは、Oracle TTC/Net、Microsoft SQL ServerやSybase ASEに使用されるTabular Data Stream (TDS)、およびIBM Distributed Relational Database Architecture (DRDA)です。
IPv6接続。Oracle AVDFでは、IPv6デプロイメントをサポートしていません。Database Firewallでは、IPv6接続からのすべてのトラフィックは自動的にブロックされます。
非TCPベースの接続。Database Firewallでは、TCPベースによるデータベース・サーバーへのネットワーク接続のみをサポートしています。Systems Network Architecture (SNA)、Internetwork Packet Exchange/Sequenced Packet Exchange (IPX/SPX)など、TCPでないプロトコルを使用したデータベース・サーバーへの接続は監視できません。
ここでのトピック
Database Firewallの共有サーバー構成の管理について学習します。
共有サーバー・アーキテクチャにより、ユーザー・プロセスがサーバー・プロセスを共有することをデータベースで許可できます。ディスパッチャ・プロセスは、受信した複数のネットワーク・セッション・リクエストを共通キューに送信し、次に、これらのセッション・リクエストを共有サーバーで使用可能な次のプロセスにリダイレクトします。デフォルトでは、Oracle DatabaseでTCPプロトコルに対するディスパッチャ・サービスが1つ作成されます。init.ora
ファイルでは、この設定は次のようにDISPATCHERS
パラメータによって制御されます。
dispatchers="(PROTOCOL=tcp)"
デフォルトの構成では、動的ポートは、TCPプロトコルを使用して受信接続をリスニングします。共有サーバー構成では、多数のユーザー・プロセスがこの動的ポートでディスパッチャに接続します。このポートでの接続を監視するようにDatabase Firewallが構成されていない場合は、これらの接続にポリシーを強制することはできません。Database Firewallの接続を簡単に構成するには、DISPATCHERSパラメータにポート番号を明示的に指定してください。次に例を示します。
dispatchers="(PROTOCOL=tcp)(PORT=
nnnn)"
nnnnの値を選択し、そのアドレスを通常のリスナー・アドレスとともに保護するようにDatabase Firewallを構成します。
関連項目:
共有サーバーの管理の詳細は、『Oracle Database管理者ガイド』を参照してください
DISPATCHERS
パラメータの詳細は、『Oracle Databaseリファレンス』を参照してください
Database Firewallがデータベース・ポリシー強制(DPE)モードの場合、セキュア・ターゲット・データベースは、Database FirewallのIPアドレス、つまりDatabase Firewallブリッジに割り当てられているIPアドレスのみを認識します。保護対象データベースのクライアントのIPアドレスは認識されないため、結果的に、ユーザーはこのデータベースに接続できません。
この問題は、sqlnet.ora
ファイルのTTC/NetパラメータTCP.INVITED_NODES
の設定に、Database FirewallブリッジIPアドレスを指定することで修正できます。データベースへのアクセスが許可されているクライアントのノードは、TCP.INVITED_NODES
パラメータで指定します。Database Firewallをデプロイする場合は、ポリシー・プロファイル機能を使用して、TCP.INVITED_NODES
によって提供されるネットワーク・アクセス制限と類似したアクセス制限を実装してください。Database Firewallのポリシー・プロファイル機能では、IPアドレス・セット、時刻、ユーザーなどの追加の要因をサポートしています。
この項に説明されているように、データベース・サーバーが認識するクライアントIPアドレスは、Database Firewallのブリッジに割り当てられているアドレスです。この機能は、元のクライアントIPアドレスに依存しているデータベース・サーバーの機能に影響を与える可能性があります。クライアントIPアドレスに依存している可能性があるこの機能には、ログオン・トリガー、監査データの分析およびOracle Database Vaultファクタがあります。
関連項目:
Database FirewallのIPアドレスの詳細は、「Database Firewallでのブリッジの構成」を参照してください。
プロファイルの詳細は、『Oracle Audit Vault and Database Firewall監査者ガイド』を参照してください。
クライアント側のコンテキスト。Database Firewallのポリシーは、クライアント・プログラム名、クライアントOSユーザー名など、クライアント側のコンテキスト情報を使用するように構成できます。クライアントがこの情報をデータベース・サーバーに送信すると、Database Firewallはその情報をネットワークから取得します。Database Firewallでは、クライアント側またはネットワークの整合性が制御または強制されないため、この情報を使用してセキュリティ・ポリシーを定義する場合は、事前に情報の整合性を考慮する必要があります。
複数のデータベースと共有リスナーでのサービス。Database Firewallでは、Oracle Databaseサービス名に基づいたポリシーがサポートされます。Oracle以外のデータベースの場合は、IPアドレスとポート番号に基づいたポリシーが強制されます。単一のリスナー・エンドポイント(IP_address
:
port
)が複数のデータベースで共有されている構成では、個々の各データベースに対するトラフィックをDatabase Firewallで区別できません。
カスタム・コレクタの開発について学習します。
カスタム・コレクタを開発する場合は、次のことに注意してください。
.jar
ファイルに追加します。ノート:
収集フレームワークにより、監査データがコレクタからOracle Audit Vault Serverに安全に転送されます。Transport Layer Security (TLS)レベルの設定について学習します。
このトピックでは、Oracle Audit Vault and Database Firewallアプライアンスにデプロイされる様々なレベルの接続暗号化について説明します。Oracle Audit Vault and Database Firewallでは、コンポーネント間通信にTLSが使用されます。
次の接続などに関して、TLSレベルおよび暗号化スイートを変更できます。
Oracle Audit Vault Serverとエージェントまたはホスト監視との接続(リリース12.2.0.9.0
以降)
ホスト監視とOracle Database Firewallとの接続(リリース12.2.0.9.0
以降)
Oracle Audit Vault ServerとDatabase Firewallとの接続
Oracle Audit Vault Server and Database FirewallのGUI
ノート:
ホスト・マシンにOracle Audit Vault Agent用またはホスト監視用にOpenSSL 1.0.1
(またはそれ以降)がインストールされていることを確認してください。
エージェントでJava 1.6
が使用されている場合は、Java
バージョンを1.8
にアップグレードしてください。
Oracle Audit Vault And Database Firewallアプライアンスで使用される接続暗号化強度
TLSレベル | TLSのバージョン | 説明 |
---|---|---|
レベル4 (新規インストール時のデフォルト) |
TLSv1.2 |
このレベルは最も強力であり、Oracle Audit Vault and Database Firewall内のすべてのコンポーネント間の通信に対してTLSをバージョン1.2に制限します。 ノート: Audit Vault AgentをIBM AIXにデプロイする必要がある場合は、TLSレベルをレベル3以下に設定してください。 |
レベル3 |
TLSv1.2 |
このレベルでは、Level-4で実行されるすべての処理がサポートされます。 |
レベル2 (アップグレード時のデフォルト) |
TLSv1.2 TLSv1.1 |
このレベルでは、レガシーの暗号化および非推奨の暗号化に対するサポートが追加されます。 ノート:
|
レベル1 (カスタム) |
TLSv1.2 |
これは、デフォルトではレベル4の強度で構成された、カスタマイズ可能な暗号セットです。 |
TLSレベルおよびその他のタスクを変更する方法
タスク | コマンド | 詳細情報 |
---|---|---|
Audit Vault ServerおよびDatabase Firewallの既存のTLSレベルを確認する |
cat /usr/local/dbfw/etc/dbfw.conf | grep CIPHER_LEVEL |
Audit Vault ServerとDatabase Firewallの実際の構成を確認するには、このコマンドを使用します。 |
TLSレベルを設定し、オプションをさらに見つける |
/usr/local/dbfw/bin/priv/configure-networking --help |
新規インストール時には、デフォルトではTLSレベルはレベル4に設定されます。 アップグレード時には、デフォルトではレベル2に設定されます。これは、ほとんどの状況に適しています。 設定されたレベルは変更可能です。使用可能なオプションを見つけるには、このコマンドを使用します。 |
AVS GUIのTLSレベルを設定する |
/usr/local/dbfw/bin/priv/configure-networking --wui-tls-cipher-level [LEVEL] |
このコマンドは、AVS GUIへのWebブラウザ接続のTLSレベルを設定します。このレベルは |
Audit Vault ServerとDatabase Firewallとの通信のTLSレベルを設定する |
/usr/local/dbfw/bin/priv/configure-networking --internal-tls-cipher-level [LEVEL] |
このコマンドは、目的のTLSレベルを設定し、内部サービスを再起動します。このレベルは |
Audit Vault AgentとAudit Vault Serverとの通信、およびホスト監視とDatabase Firewallとの通信のTLSレベルを設定する |
/usr/local/dbfw/bin/priv/configure-networking --agent-tls-cipher-level [LEVEL] |
このコマンドは、Audit Vault AgentとAudit Vault Serverとの通信、およびホスト監視とDatabase Firewallとの通信のためのTLSレベルを設定します。このレベルは ノート:
1. Audit Vault Serverコンソールにrootユーザーとしてログインします。 2. 次のコマンドを使用してディレクトリを変更します。
3. 次のコマンドを使用してスクリプトを実行します。
このコマンドは、1時間以内に複数回実行できません。 |
カスタマイズした暗号セットを適用する |
/usr/local/dbfw/bin/priv/configure-networking --wui-tls-cipher-level 1 --internal-tls-cipher-level 1 --agent-tls-cipher-level 1 |
新規インストール時には、デフォルトでは製品はレベル4に設定されます。アップグレード時には、レベル2に設定されます。これは、ほとんどの状況に適しています。これはカスタマイズできます。 作成したファイルからカスタム定義レベルを適用するには、このコマンドを使用します。これらのコマンドは、Webブラウザ接続のTLSレベルを設定し、内部サービスおよびAudit Vault Serverを再起動します。 ノート: このコマンドを実行する前に、 |
カスタム・レベル構成ファイルを編集する |
|
カスタマイズ可能な暗号スイート・セットは、このファイルで定義されます。新規インストール時には、デフォルトでは製品はレベル4に設定されます。このファイルを、暗号スイートをさらに制限して、製品で使用可能な暗号を含むように変更できます。 |
使用可能な暗号スイートをすべて示すリストを表示する |
openssl ciphers -v |
現在使用可能な一連の暗号スイートを表示するには、このコマンドを使用します。 |
TLSレベルの変更が必要な状況
内部TLSレベルはレベル4のままにすることをお薦めします。TLSレベルの変更が必要な状況について、詳細を次に示します。
コンポーネント | 状況 |
---|---|
内部通信 |
セキュリティを強化するには、レベル4に設定することをお薦めします。 |
Audit Vault Server GUI |
古いブラウザをサポートするには、ブラウザと一致するようにTLSレベルを設定します。 |
Audit Vault Agent / ホスト監視 / Audit Vault Server |
セキュリティを強化するには、レベル4に設定することをお薦めします。 |
IBM AIXでデプロイされたAudit Vault Agent |
リリース |
カスタムの暗号セットの設定
カスタムの暗号セットを設定するには、次の手順を使用します。これを行うには、TLSレベルを定義するカスタム・ファイルを作成してから、そのファイルを適用します。