| Oracle® Audit Vault and Database Firewall概要ガイド リリース12.2 E70386-13 |
|
 前 |
 次 |
ここでのトピック
1つ以上のAudit Vault Agentをデプロイすることによって、様々なシステム(セキュア・ターゲット)から監査データを収集し、統合します。
通常、Audit Vault Agentはセキュア・ターゲットと同じホスト上にデプロイしますが、ホストの場所によっては別のホスト上にデプロイすることも可能です。セキュア・ターゲットは、Oracle Audit Vault and Database Firewallがサポートするデータベースまたはその他のシステムです。
Audit Vault Agentには、特定のセキュア・ターゲットから監査データを収集する収集プラグインが含まれています。サポートされている各セキュア・ターゲットに対応する収集プラグインがAudit Vault Agentにあります。Oracle Audit Vault and Database Firewall SDKを使用してカスタム・プラグインを開発し、デフォルトではまだサポートされていないソースから監査データを収集することもできます。
次の図に、Oracle Audit Vault Serverと、データベースおよびデータベース以外のシステムにデプロイされたAudit Vault Agentを示します。エージェントは、これらのシステムから監査データを収集し、そのデータをOracle Audit Vault Serverに送信します。
データが収集されたら、Oracle Audit Vault and Database Firewall監査者は、このデータを統合して事前構成済のカスタマイズ可能な多数のレポートを生成したり、特定の条件を満たしたときにトリガーされるルールベースのアラートや通知を構成することもできます。
図3-1 Oracle Audit Vault ServerとAudit Vault Agentのデプロイ
1つのOracle Audit Vault Serverのホスト上にインストールできるAudit Vault Agentは1つのみです。1つのAudit Vault Agentを使用して、複数の監査証跡収集を開始できます。
エージェントから監査ログにアクセスできる場合、1つのAudit Vault Agentで複数のセキュア・ターゲットから監査データを収集できます。たとえば、データベースにはデータベース接続文字列を使用してアクセスでき、ファイル(ファイル・パス)にはファイルのホストからアクセスできます。そのため、場合によってセキュア・ターゲットが同一ホスト上にないことがあります。同一ホスト上に複数のデータベースがある場合でも、エージェントは複数のセキュア・ターゲットから収集できます。各セキュア・ターゲットに対して、Oracle Audit Vault and Database Firewallで1つ以上の監査証跡を構成します。たとえば、エージェントがデータベースとオペレーティング・システムから監査データを収集している場合があります。このエージェントはホストにデプロイされ、3つの監査証跡が構成されていることがあります。たとえば、データベースの2つの異なる監査データ・ソース(たとえば、REDOログとSYS.AUD$ディクショナリ)からデータを収集するために2つの監査証跡を構成し、オペレーティング・システム(たとえば、Linuxシステムのaudit.log)用に1つの監査証跡を構成することができます。
関連項目:
サポートされるセキュア・ターゲットの詳細は、『Oracle Audit Vault and Database Firewallインストレーション・ガイド』を参照してください。
カスタム・プラグインの開発方法の詳細は、『Oracle Audit Vault and Database Firewall開発者ガイド』を参照してください。
監査データ収集および監査ポリシーについて学習します。
「信頼するが検証もする(trust but verify)」の原則を適用するには、システム固有の監査機能を理解し、その監査機能を適切に設定する必要があります。
監査対象がOracle Databaseか他の種類のデータベースかにかかわらず、特権ユーザーはシステム侵入のターゲットになりやすいことに注意してください。システムの監査機能を理解した上で、Oracle Audit Vault and Database Firewallをデプロイし、監視対象の様々なシステムから監査情報を収集して統合できます。
このような異機種システムから監査データを統合するだけでなく、Oracle Audit Vault and Database Firewallでは、Oracle Database監査ポリシーを取得し、Oracle Audit Vault Serverから直接変更して、更新済のポリシーをOracle Databaseにプロビジョニングすることもできます。
Oracle Database 12c以上を使用する場合は、Oracle Database 12c以降のリリースに関して記載されている事前定義済の統合監査ポリシーを活用できます。
監査は比較的低コストですが、監査するイベントの数は必要なもののみに制限する必要があります。
この制限によって、監査対象の文を実行したときのパフォーマンスへの影響が最小限に抑えられ、監査証跡のサイズが最小限になるため、分析と理解が容易になります。最も大きな影響を受けるのは、Audit Vault Serverの記憶域要件です(特にアーカイブ期間が長い場合)。
監査方針を企画する際は、次のガイドラインに従ってください。
監査の目的を評価して、特定のアクティビティに絞り込む。監査の目的を明確にしておくと、適切な監査方針を企画でき、不要な監査を回避できます。
たとえば、監査の重要な目的は特権ユーザーのアクティビティを監視することです。データベース・アクティビティを監査する場合、データベースに直接アクセスできるユーザー(特にDBAなどの管理ユーザー)のアクティビティを監査することをお薦めします。
DBAの場合は、すべてのアクティビティを監視します。他のユーザーについては、特定の種類の疑わしいアクティビティに絞り込むことができます。たとえば、データベース内の表から無許可にデータが削除されていないかを監査するというような、監査方針を立てます。これにより、監査の対象となるアクションの種類や、疑わしいアクティビティによって影響を受けるオブジェクトの種類を限定できます。
監査機能を効率的に使用する。目標とする情報の取得に必要な最小限の文、ユーザーまたはオブジェクトを監査します。これにより、不要な監査情報が散乱して重要な情報の識別が困難になることを防ぐことができます。収集が必要なセキュリティ情報の量と、その情報を格納して処理する能力とのバランスを保つ必要があります。
関連トピック
データベースの監査を初めて構成する際は、データベースのデフォルトの監査設定を使用して始めることをお薦めします。
それ以降は、次のガイドラインを使用できます。
一般的な疑わしいアクティビティを監査する。
次の一般的なアクティビティを監査すると、疑わしいアクティビティの特定に役立ちます。
SYSなどの特権ユーザー、SYSOPERまたはSYSDBA管理権限を付与されたユーザー、またはDBAロールを付与されたユーザーのアクティビティ
たとえば、統合監査に移行していないOracle Databaseの場合は、AUDIT_SYS_OPERATIONS初期化パラメータをTRUEに設定します。
データベースに直接アクセスするユーザー。次のようなアクティビティが見つかることがあります。
通常以外の時間中にデータベースにアクセスするユーザー
複数回失敗したログイン試行
存在しないユーザーによるログイン試行(侵入者がアクセスの取得を試みる場合に発生する可能性があります)
表または列にある重要なビジネス情報へのアクセス試行。たとえば、異なるIPアドレスから同一ユーザー名によるアクセスが確認される場合、複数の人物が同じアカウントを共有している可能性が示唆されます。
さらに、アカウントを共有しているユーザー、または同じIPアドレスからログインしている複数のユーザーを監視します。たとえば、データベース・アクティビティに関する情報を収集するために監査する場合は、追跡するアクティビティの種類を正確に判断した上で、必要な情報を収集するために必要な期間内で、目的のアクティビティのみを監査します。別の例として、各セッションの論理I/O情報のみを収集する場合は、オブジェクト(表やビューなど)を監査しないでください。
関連するアクションのみを監査する。
少なくとも、ユーザー・アクセスとシステム権限の使用は監査します。また、データベース・スキーマ構造の変更も監査します。これには、Oracle DatabaseのCREATE TABLEやDROP TABLE SQL文などのDDL変更が含まれます。関連のない監査レコードのために重要な情報が識別できない事態を避け、監査証跡管理の量を削減するために、目的のデータベース・アクティビティのみを監査してください。
監査対象が多すぎるとデータベースのパフォーマンスに影響する可能性があることにも注意してください。たとえば、データベースのすべての表に対するDML変更を監査すると、監査証跡レコードが多くなりすぎてデータベースのパフォーマンスが低下する可能性があります。ただし、DDL変更はすべて、または機密列を持つ表は選択して監査することを強くお薦めします。
機密情報を監査する場合には注意する。
SQLテキストなど、SQL問合せで使用すると、クレジット・カード番号などの機密データが監査証跡の列に表示される可能性があることに注意してください。監査対象の機密データがある場合は、監査証跡でのSQLテキストの収集は有効にしないでください。
組織のプライバシに関する考慮事項を検討する。
プライバシに関する法規によって、追加のビジネス・プライバシ・ポリシーが必要となる場合があります。プライバシに関するほとんどの法規では、個人を特定できる情報(PII)へのアクセスをビジネスで監視する必要があり、このような監視は監査によって実施されます。ビジネス・レベルのプライバシ・ポリシーでは、技術的、法的および企業ポリシーの問題など、データ・アクセスおよびユーザー・アカウンタビリティに関するすべての事項を処理する必要があります。
監査に役立つ可能性のあるその他の情報をデータベースのログ・ファイルでチェックする。
データベースによって生成されたログ・ファイルには、データベースの監査時に使用できる有益な情報が含まれている場合があります。たとえばOracle Databaseでは、REDOログを監査して特定のデータベース・オブジェクトの変更前および変更後の値を確認できます。Oracle DatabaseでREDOログを有効にし、Oracle Audit Vault and Database Firewallで監査証跡を作成してredoログからイベントを収集することで、この情報をOracle Audit Vault and Database Firewallレポート(データ変更前後の値レポート)で確認できます。
監査レコードをアーカイブし、監査証跡を削除する。
必要な情報を収集した後は、目的の監査レコードをアーカイブし、この情報の監査証跡を削除します。具体的な手順は、ご使用のデータベースのドキュメントを参照してください。
関連項目:
Oracle Database 12cの機密情報を非表示にするには、Oracle Databaseセキュリティ・ガイドを参照してください。
Oracle Database 11gの機密情報を非表示にするには、Oracle Databaseセキュリティ・ガイドを参照してください。
監査証跡レコードのパージの詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。
redoログの詳細は、『Oracle Database管理者ガイド』を参照してください。
Oracle Database 12c以降を使用し、統合監査に移行済の場合は、6つの事前定義の統合監査ポリシーを活用できます。
Oracle Database 12c以降のリリースの統合監査証跡に適用される6つの事前定義の監査ポリシーを有効にできます。これらの監査証跡では、複数の監査コンポーネントから監査データが取得され、データは1つの場所に1つの形式で配置されます。
次に示す事前定義の統合監査ポリシーは、よく使用されるセキュリティ関連の監査設定を対象としています。
ログオン失敗 - 失敗したログオンを追跡します
セキュア・オプション - セキュアな構成監査オプションがすべて用意されています。たとえば、ANY権限(CREATE ANY JOBなど)の監査や、広範囲に影響を与える可能性のあるアクション(ユーザーの変更、ロールの作成、プロファイルの削除など)の監査などです。
Oracle Databaseパラメータ変更 - Oracle Databaseのパラメータ設定(ALTER DATABASE、ALTER SYSTEMおよびCREATE SPFILE)を監査します。
ユーザー・アカウントおよび権限管理 - よく使用されるユーザー・アカウントおよび権限の設定(CREATE USER、ALTER ROLE、GRANT、REVOKEなど)を監査します。
Center for Internet Securityの推奨 - Center for Internet Security (CIS)で推奨される監査を実行します
Oracle Database Vault - Oracle Database VaultのDVSYSおよびDVFスキーマ・オブジェクトと、Oracle Label SecurityのLBACSYSスキーマ・オブジェクトに対して実行されるすべてのアクションを監査します
1つのデータベースで複数のポリシーを有効にできます。統合監査を有効にしていない場合、または使用中のOracle Databaseのバージョンがリリース12cよりも前の場合は、これらのポリシーをモデルに、ポリシーを作成することをお薦めします。このようなポリシーの統合監査ポリシー作成文は、Oracle Databaseセキュリティ・ガイドを参照してください。
関連項目:
ポリシーの詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。
Audit Vault Agentがデプロイされ、セキュア・ターゲットがOracle Database 11g、10gまたは12cである場合は、監査データの収集以外に、データベースの監査ポリシーの取得、変更およびプロビジョニングを行うこともできます。
新しい監査ポリシーを追加するだけでなく、次の監査設定を変更することもできます。
関連項目:
Oracle Database 11gの監査の詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。
Oracle Databaseエンタイトルメントとは、ユーザー・アカウントがOracle Databaseで特定のタスクを実行できるようにするロール、権限またはグループ・メンバーシップのことです。
Oracle Databaseリリースのエンタイトルメントのセットは一定期間に変更される場合があるため、監査者がこれらの変更を追跡して、未許可のエンタイトルメントが付与されないように徹底できるようにしておくことが重要です。たとえば、監査者はDBAロールの付与や新しいユーザー・アカウントおよび権限のチェックを行う必要があります。
Audit Vault Agentがデプロイされている場合、Oracle Audit Vault and Database FirewallではOracle Databaseエンタイトルメントのスナップショットを経時的に取得し、各種レポートでスナップショット同士を比較したり、全体的なOracle Databaseエンタイトルメント情報を確認したりできます。
関連項目:
詳細は、『Oracle Audit Vault and Database Firewall監査者ガイド』を参照してください。
Oracle Audit Vault and Database FirewallのAudit Vault Agentコンポーネントを計画および公開する方法を学習します。
Audit Vault Agentをデプロイする前に、次の質問について考える必要があります。
どのシステムから監査データを収集する必要があるか。
監査データを収集する対象のシステムごとに、セキュア・ターゲットをOracle Audit Vault Serverに登録する必要があります。
Audit Vault Agentがいくつ必要で、どこにデプロイするか。
Oracle Audit Vault Serverに登録できるようにするため、Audit Vault Agentのデプロイ先のホスト(通常はセキュア・ターゲット・ホスト)を特定し、それぞれのホスト名またはIPアドレスあるいはその両方を取得します。
どのタイプの監査証跡、監査ログおよびREDOログを収集する必要があり、それぞれどこに格納されているか。
セキュア・ターゲットのタイプによって、生成される監査データのタイプおよびデータの格納場所は異なります。たとえば、Microsoft SQL Serverデータベースの場合は、C2監査ログ、サーバー側のトレース・ログおよびsqlauditログ・ファイルから監査データを収集できます。また、Oracle Database監査レコードは、Linuxプラットフォームのsyslogファイルから収集できます。さらに、この2つのデータベースに関するMicrosoft Windowsイベント・ログから、あるいはMicrosoft Windowsオペレーティング・システムおよびMicrosoft Active Directoryからデータを収集することもできます。
どのような監査設定がセキュア・ターゲットに必要か。
対象のセキュア・ターゲットのタイプに対応した監査機能を把握し、それぞれの監査方針を用意しておくことが重要です。対象のセキュア・ターゲット(Oracle Database、Microsoft SQL Serverなど)固有のドキュメントを参照してください。
1つのエージェントでいくつの監査証跡を収集するか。
特定のエージェントに関連付ける監査証跡の数を見積もっておくと、パフォーマンスの最適化に役立ちます。
関連項目:
『Oracle Audit Vault and Database Firewall管理者ガイド』
