11g リリース1（11.1）
E05781-03
 目次 |
 索引 |
| Oracle Database 2日でセキュリティ・ガイド 11g リリース1（11.1） E05781-03 |
|
この章の内容は次のとおりです。
監査は選択したユーザーのデータベース・アクションの監視と記録です。標準監査を使用して、SQL文、権限、スキーマ、オブジェクト、ネットワークおよび複数階層アクティビティの監査を行います。標準監査では、初期化パラメータおよびSQL文AUDITとNOAUDITを使用して、SQL文、権限、スキーマ・オブジェクト、およびネットワーク・アクティビティと複数階層アクティビティの監査を行います。
監査が有効かどうかにかかわらず、Oracle Databaseが常に監査するアクティビティもあります。これらのアクティビティには、管理者権限の接続、データベースの起動、データベースの停止などが含まれます。詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。
監査の別タイプとして、ファイングレイン監査もあります。ファイングレイン監査により、データ・アクセスを、内容に基づき、value > 1000などのBoolean測定を使用して、最も密なレベルで監査できます。ファイングレイン監査では、列へのアクセス、または列内での変更に基づいて、アクティビティを監査できます。Oracle Databaseにある指定した要素（特定のオブジェクトのコンテンツなど）へのアクセスまたは変更があると監査がトリガーされるようにセキュリティ・ポリシーを作成できます。監査を行う必要がある特定の条件を定義したポリシーを作成できます。たとえば、特定の表の列を監査し、一定期間中のどのタイミングで、誰がアクセスしようとしたかを調べることができます。また、ポリシー違反があった場合にトリガーされるアラートも作成でき、このデータを別の監査ファイルに書き込むことができます。ファイングレイン監査の実行方法は、『Oracle Databaseセキュリティ・ガイド』を参照してください。
監査は、通常次のような目的で使用されます。
特定のスキーマ、表、行または影響を受けるコンテンツに対して実行されたアクションも含まれます。
たとえば、ユーザーが表からデータを削除しようとした場合、セキュリティ管理者は、そのデータベースへのすべての接続と、そのデータベースにあるすべての表からの行の削除（成功および失敗）をすべて監査できます。
たとえば、認可されていないユーザーがデータを変更または削除を実行できるなど、予期した以上の権限を持っている場合に、ユーザー認可を再評価できます。
たとえば、データベース管理者は、更新された表、実行された論理I/O操作の回数、ピーク時に接続していた同時実行ユーザーの数などに関する統計を収集できます。
たとえば、別の方法で保護されているデータを監査するポリシーを作成します。この場合、データは保護されているため、通常は監査レコードは生成されません。これらのポリシーにより監査レコードが生成された場合は、このデータを保護している別のセキュリティ・コントロールが適切に実装されていないことになります。
次のような規制には監査に関連する共通の要件があります。
Oracle Databaseは、監査アクティビティを監査レコードに記録します。監査レコードには、監査された操作、操作を実行したユーザー、操作が実行された日時が記録されます。監査レコードは、データベース監査証跡と呼ばれるデータ・ディクショナリ表またはオペレーティング・システム監査証跡と呼ばれるオペレーティング・システム・ファイルに格納できます。Oracle Databaseでは、不審なアクティビティを追跡するために使用できる一連のデータ・ディクショナリ・ビューも提供されます。これらのビューの詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。
標準監査を使用する場合、Oracle Databaseでは、監査レコードがDBA_AUDIT_TRAIL（sys.aud$表）、オペレーティング・システム監査証跡、または標準監査のログ・レコードとファイングレイン監査のログ・レコードを組み合せるDBA_COMMON_AUDIT_TRAILビューに書き込まれます。
さらに、管理者が実行したアクションは、syslog監査証跡に記録されます。
ここでは、標準監査を使用してSQL文、権限、スキーマ・オブジェクト、ネットワーク・アクティビティまたは多層アクティビティに対して実行されたアクティビティを監査する方法を説明します。
この項の内容は次のとおりです。
標準監査では、SQL文、権限、スキーマ・オブジェクトや、ネットワーク・アクティビティまたは多層アクティビティの監査を有効にできます。必要に応じて、特定のスキーマ表に対して監査を実行できます。このタイプの監査を実行するには、Database Controlを使用します。
標準監査レコードは、DBA_AUDIT_TRAIL（sys.aud$ 表）、オペレーティング・システム監査証跡、または標準監査のログ・レコードとファイングレイン監査のログ・レコードを組み合せるDBA_COMMON_AUDIT_TRAILビューのいずれかに書き込むことができます。
この項で説明している標準監査を実行する前に、標準監査を有効にする必要があります。標準監査を有効にするときに、データベース監査証跡に監査証跡を作成するか、オペレーティング・システム・ファイルに監査アクティビティを書き込むことができます。オペレーティング・システム・ファイルに書き込む場合は、テキスト形式またはXML形式で監査レコードを作成します。
SYSとしてログインし、SYSDBA権限で接続します。
「初期化パラメータ」ページが表示されます。
インストールの「SPFile」タブが表示されない場合は、サーバー・パラメータ・ファイルを使用してOracle Databaseをインストールしなかったということです。次の手順に進みます。
audit_trailを入力してAUDIT_TRAILパラメータを検索し、「実行」をクリックします。AUDIT_のように、パラメータの最初の数文字を入力できます。または、パラメータのリストをスクロールして、AUDIT_TRAILパラメータを検索できます。
DB: データベース監査を有効にし、すべての監査レコードをデータベース監査証跡（SYS.AUD$）に記録します。ただし、常にオペレーティング・システム監査証跡に書き込まれるレコードは除きます。（この値は、データベースの作成にDatabase Configuration Assistantを使用した場合のデフォルトです。それ以外の場合のデフォルトは、NONEです。）
OS: データベース監査を有効にして、すべての監査レコードをオペレーティング・システム・ファイルに書き込みます。非常に安全なデータベース構成を使用している場合、DoS（サービス拒否）攻撃の可能性を低減できることから、この設定を使用することをお薦めします。また、この設定では、監査証跡の保護も容易になります。監査を行うユーザーがデータベース管理者とは異なる場合は、operating system設定を使用する必要があります。データベースに格納されたすべての監査情報は、データベース管理者により参照および変更が可能です。オペレーティング・システム監査レコード・ファイルの場所を指定するには、AUDIT_FILE_DEST初期パラメータを設定します。デフォルトのディレクトリは$ORACLE_HOME/rdbms/auditです。
NONE: 標準監査を無効にします。（この値は、データベースの作成にDatabase Configuration Assistant以外の方法を使用した場合のデフォルトです。Database Configuration Assistantを使用した場合のデフォルトは、DBです。）
DB, EXTENDED: AUDIT_TRAIL=DB設定のすべてのアクションを実行し、可能な場合は、SYS.AUD$表のSQLバインドおよびSQLテキストのCLOB型の列にデータを移入します（これら2つの列は、このパラメータが指定されたときにのみデータが移入されます）。
XML: オペレーティング・システム監査レコード・ファイルにXML形式で書き込みます。AuditRecordノードの、Sql_TextとSql_Bind以外のすべての要素をオペレーティング・システムXML監査ファイルに書き込みます。
EXTENDED: XMLのすべてのアクションを実行し、可能な場合はSYS.AUD$表のSQLバインドおよびSQLテキストのCLOB型の列にデータを移入するXML, EXTENDEDを指定します（これらの列は、このパラメータが指定されたときにのみデータが移入されます）。
次の点に注意してください。
SYS監査を有効にする場合、AUDIT_TRAILを設定する必要はありません（SYS監査ではシステム管理者のアクティビティが監視されます。詳細は『Oracle Databaseセキュリティ・ガイド』を参照してください）。ファイングレイン監査の場合は、必要に応じてファイングレイン監査ポリシーを追加および削除し、監視する特定の操作またはオブジェクトに適用します。AUDIT_SYS_OPERATIONSパラメータを使用すると、SYS監査を有効または無効にできます。
ここでは、Oracle推奨の監査パラメータを有効にする方法を説明します。内容は次のとおりです。
新しいデータベースを作成した場合や、既存のデータベースを変更した場合、Database Configuration Assistant（DBCA）の「セキュリティ設定」ウィンドウを使用して、デフォルトのセキュリティ設定を有効または無効にできます。ここでは、DBCAの起動方法およびデフォルトのセキュリティ設定を有効にする方法を説明しています。これらの設定を有効にすると、Oracle Databaseはセキュリティに関連するいくつかのSQL文と権限を監査します。また、AUDIT_TRAIL初期化パラメータがDBに設定されます。別の監査オプション（オペレーティング・システム・ファイルに監査証跡レコードを記述する場合はOSなど）に設定することもできます。この場合も、Oracle Databaseは、デフォルトで監査対象となっている権限を監査します。AUDIT_TRAILパラメータをNONEに設定して監査を無効にすると、監査は行われません。
Oracle Databaseは、AUDIT ROLE SQL文をデフォルトで監査します。デフォルトで監査される権限は、次のとおりです。
また、Oracle Databaseは、BY ACCESS句を持つすべての権限と文を監査します。
これらの文および権限の監査がアプリケーションに悪影響を与える可能性がある場合は、Database Configuration Assistant（DBCA）を使用して、この監査を無効にできます。監査を使用するようにアプリケーションを変更したら、これらの文および権限のデフォルト監査を再度有効にできます。
デフォルトで監査を有効にすることをお薦めします。監査は、米国企業改革法（Sarbanes-Oxley Act）で定義されているコンプライアンス要件を満たし、内部からのアクセスを確実に制御できる有効な方法です。監査を実行することでビジネス活動を監視でき、企業のポリシーに反するアクティビティを発見できます。この結果、データベースおよびアプリケーション・ソフトウェアへのアクセスが厳しく制御され、定期的にパッチが確実に適用でき、その場かぎりの変更を防止できます。デフォルトで監査を有効にすると、監査および個人のコンプライアンスに関する監査レコードを生成できます。ただし、監査はデータベースのパフォーマンスに影響する可能性があります。
ここでは、Database Configuration Assistantを使用してデフォルト監査を有効にする方法を説明します。
dbca
一般的に、dbcaは$ORACLE_HOME/binディレクトリにあります。
または、次のコマンド・プロンプトでDatabase Configuration Assistantを起動できます。
dbca
Windowsでは一般的に、dbcaはORACLE_BASE¥ORACLE_HOME¥binディレクトリにあります。
「操作」ウィンドウが表示されます。
「データベース」ウィンドウが表示されます。
「管理オプション」ウィンドウが表示されます。
「セキュリティ設定」ページが表示されます。
このリリースの拡張セキュリティ設定を利用することをお薦めします。
「データベース・コンポーネント」ページが表示されます。
「接続モード」ページが表示されます。
監査できるSQL文は、次のカテゴリに含まれます。
AUDIT TABLE）の監査を有効にすると、すべてのCREATEおよびDROP TABLE文が監査されます。DML文。たとえば、SELECT TABLEの監査を有効にすると、表またはビューにかかわらず、すべてのSELECT ... FROM TABLE/VIEW文が監査されます。
文の監査の対象範囲は変更できます。たとえば、すべてのデータベース・ユーザーのアクティビティを監査したり、ユーザーの選択リストのみを監査できます。
権限の監査では、SELECT ANY TABLEなど、システム権限を使用する文を監査します。すべてのシステム権限の使用を監査できます。権限の監査では文の監査と同様に、すべてのデータベース・ユーザーのアクティビティを監査することも、指定したリストのアクティビティのみを監査することもできます。SQL文の監査と同様に、AUDIT文およびNOAUDIT文を使用することで、権限の監査を有効または無効にできます。また、監査を有効にするには、AUDIT SYSTEMシステム権限が必要です。
権限の監査オプションは、対応するシステム権限に一致します。たとえば、DELETE ANY TABLE権限の使用を監査するオプションは、DELETE ANY TABLEです。次に例を示します。
AUDIT DELETE ANY TABLE BY ACCESS WHENEVER NOT SUCCESSFUL;
DELETE ANY TABLE権限の使用の成功および失敗をすべて監査するには、次の文を入力します。
AUDIT DELETE ANY TABLE;
すべてのデータベース・ユーザーおよび監査対象の個々の文による、すべての表でのSELECT、INSERT、DELETE文の失敗、およびEXECUTE PROCEDUREシステム権限の使用の失敗をすべて監査するには、次の文を実行します。
AUDIT SELECT TABLE, INSERT TABLE, DELETE TABLE, EXECUTE PROCEDURE BY ACCESS WHENEVER NOT SUCCESSFUL;
Database Controlの「監査文の追加」ページまたは「監査権限の追加」ページでプロキシを指定すると、多層環境のクライアントのアクティビティを監査できます。多層環境では、Oracle Databaseはすべての層でクライアントのアイデンティティを保持します。これにより、クライアントのかわりに、中間層アプリケーションにより実行されたアクションを監査できます。
中間層でも、データベース・セッションでユーザーのクライアントIDを設定でき、中間層アプリケーションからユーザー・アクションの監査を有効にできます。ユーザーのクライアントIDは、監査証跡に表示されます。
SQL AUDIT文を使用して多層環境のクライアントのアクティビティを監査できます。そのためには、AUDIT文でBY PROXY句を使用します。
たとえば、クライアントjacksonのかわりにプロキシ・アプリケーション・サーバーappserveによって実行されたSELECT TABLE文を監査するには、次のようにします。
AUDIT SELECT TABLE BY jackson ON BEHALF OF appserve;
ユーザーjacksonは、次のようにappserveプロキシ・ユーザーを使用して接続できます。
CONNECT appserve[jackson] Enter password: password
スキーマ・オブジェクトの監査では、特定の表のSELECT文またはDELETE文など、スキーマ・オブジェクト権限により許可されたすべてのSELECT文およびDML文が監査されます。これらの権限を制御するGRANT文およびREVOKE文も監査されます。
AUDIT文を使用して、ネットワーク・プロトコルの予期しないエラーやネットワーク層で発生した内部エラーを監査できます。ネットワーク監査の対象とならないエラーのタイプは、接続の問題ではなく、複数の原因で発生した可能性があります。考えられる原因として、データベース・エンジニアが単にテスト目的で内部イベントを設定した、などがあげられます。他にも、ネットワークが暗号化の作成または処理に必要な情報を見つけられないなど、暗号化の構成設定の競合などが原因として考えられます。
SYSTEMなどの管理者権限で、またはセキュリティ管理者としてログオンします。次に例を示します。
SQLPLUS SYSTEM Enter password: password
SQL*Plusが起動し、デフォルトのデータベースに接続してから、プロンプトが表示されます。
SQL*Plusの起動の詳細は、『Oracle Database 2日でデータベース管理者』を参照してください。
AUDIT NETWORK;
ネットワークの監査を無効にするには、次の文を入力します。
NOAUDIT NETWORK;
EXIT
OE.CUSTOMERS表のSELECT文を監査する場合を想定します。このチュートリアルでは、標準監査を有効にし、SELECT SQL文を有効にし、OE.CUSTOMERS表でSELECT SQL文を実行してから、その監査ファイルをチェックします。
このチュートリアルでは、次の手順を実行します。
最初に、ログインして必要ならば標準監査を有効にします。
SYSとしてログインし、SYSDBA権限で接続します。
「初期化パラメータ」ページが表示されます。
インストールの「SPFile」タブが表示されない場合は、サーバー・パラメータ・ファイルを使用してOracle Databaseをインストールしなかったということです。次の手順に進みます。
AUDIT_TRAILを入力してAUDIT_TRAILパラメータを検索し、「実行」をクリックします。AUDITのように、パラメータの最初の数文字を入力できます。または、パラメータのリストをスクロールして、AUDIT_TRAILパラメータを検索できます。
「DB」（データベース）オプションを選択します。DBオプションでは、データベース監査を有効にし、すべての監査レコードをデータベース監査証跡（SYS.AUD$）に記録します。ただし、常にオペレーティング・システム監査証跡に書き込まれるレコードは除きます。
次に、OE.CUSTOMERS表のSELECT文に対する監査を有効にします。
sec_adminが存在することを確認します。SYSTEMとしてログオンし、Database Controlのホームページから、「サーバー」をクリックすると、「サーバー」サブページが表示されます。「セキュリティ」の下の「ユーザー」を選択し、アカウントのリストでsec_adminをチェックします。sec_adminセキュリティ管理者アカウントを作成する方法は、「手順1: セキュリティ管理者アカウントを作成する」を参照してください。
OE.CUSTOMERS表でのsec_admin SELECT権限を付与します。
sec_adminとしてDatabase Controlにログインします。
監査設定ページが表示されます。
「監査オブジェクトの追加」ページが表示されます。
この段階では、監査が有効で、OE.CUSTOMERS表で実行されたすべてのSELECT文がDBA_AUDIT_TRAILビューに書き込まれます。次に、監査設定をテストします。
sec_adminとして接続します。
SQLPLUS sec_admin Enter password: password
SELECT文を入力して監査証跡のアラートを作成します。
SELECT COUNT(*) FROM oe.customers;
DBA_AUDIT_TRAILビューを表示します。
SELECT USERNAME, TIMESTAMP FROM DBA_AUDIT_TRAIL;
次のような出力が表示されます。
USERNAME TIMESTAMP --------------------------- SEC_ADMIN 07-MAY-08
EXIT
オプションで、以前に作成した監査設定を削除します。
監査設定ページが表示されます。
OEと入力します。
CUSTOMERSと入力します。
OE.CUSTOMERSスキーマの横のボックスを選択し、「削除」をクリックします。「確認」ダイアログ・ボックスが表示されます。
AUDIT_TRAILパラメータを元の値に設定します。次に、データベースを停止してから再起動します。
この例は、このガイドの最後の例です。sec_admin管理者アカウントが不要になった場合は、このアカウントを削除する必要があります。
「ユーザー」ページが表示されます。
sec_adminを入力します。
sec_adminユーザー・アカウントの横のボックスを選択し、「削除」をクリックします。「確認」ダイアログ・ボックスが表示されます。
この項の内容は次のとおりです。
新しくデータベースを作成すると、選択した一連のSQL文および権限の監査を有効にすることができます。デフォルト監査を有効にすることを、強くお薦めします。監査は、米国企業改革法（Sarbanes-Oxley Act）で定義されているコンプライアンス要件を満たし、内部からのアクセスを確実に制御できる有効な方法です。デフォルト監査の詳細は、「セキュリティ関連のSQL文および権限に対するデフォルト監査の使用」を参照してください。
監査はデータベース・パフォーマンスにあまり影響しませんが、監査するイベントの数はできるだけ制限する必要があります。この制限によって、監査対象の文を実行したときにパフォーマンスの影響が最小限に抑えられ、監査証跡のサイズが最小限になるため、分析と理解が容易になります。
監査方針を立てる際は、次のガイドラインに従います。
監査の目的を理解すると、適切な監査方針を立てることができ、不要な監査を行わずにすみます。
たとえば、不審なデータベース・アクティビティの調査のために監査を行うと仮定します。この情報のみでは、十分に明確であるとはいえません。どのデータベース・アクティビティが疑わしい、または注意を要するといった具体的な情報が必要です。そのために、たとえば、データベース内の表から許可なくデータが削除されていないかを監査するというように、監査目的を絞り込みます。このような目的を設定すれば、監査の対象となるアクションの種類や、疑わしいアクティビティによって影響を受けるオブジェクトの種類を限定できます。
目標とする情報の取得に必要な最小限の文、ユーザーまたはオブジェクトを監査します。これによって、不要な監査情報のために重要な情報の識別が困難になることや、SYSTEM表領域内の貴重な領域が無駄に消費されることがなくなります。収集が必要なセキュリティ情報の量と、その情報を格納して処理する能力とのバランスを保つ必要があります。
たとえば、データベース・アクティビティに関する情報を収集するために監査する場合は、追跡するアクティビティの種類を正確に判断した上で、必要な情報を収集するために必要な期間内で、目的のアクティビティのみを監査します。別の例として、各セッションの論理I/O情報のみを収集する場合は、オブジェクトを監査しないでください。
監査目的が、特定のデータベース・アクティビティに関する履歴情報を収集することである場合は、次のガイドラインに従ってください。
不要な監査情報によって重要な情報の識別が困難になることを防ぎ、監査証跡管理の量を削減するために、対象となるデータベース・アクティビティのみ監査します。ファイングレイン監査を使用して特定のアクションを監査できます。『Oracle Databaseセキュリティ・ガイド』では、ファイングレイン監査が詳細に説明されています。
必要な情報を収集した後は、目的の監査レコードをアーカイブし、この情報の監査証跡を削除します。
監査レコードをアーカイブするために、たとえば標準監査証跡ではINSERT INTO table SELECT ... FROM SYS.AUD$ ...を使用して、通常のデータベース表に関連レコードをコピーできます（ファイングレイン監査レコードは、SYS.FGA_LOG$表にあります）。または、監査証跡表をオペレーティング・システム・ファイルにエクスポートできます。『Oracle Databaseユーティリティ』では、Oracle Data Pumpを使用して表をエクスポートする方法が説明されています。
監査レコードをパージするには、標準監査レコードをSYS.AUD$表から削除し、ファイングレイン監査レコードをSYS.FGA_LOG$表から削除します。たとえば、すべての監査レコードを標準監査証跡から削除するには、次の文を入力します。
DELETE FROM SYS.AUD$;
また、emp表の監査の結果として生成された標準監査証跡からすべての監査レコードを削除するには、次の文を入力します。
DELETE FROM SYS.AUD$ WHERE obj$name='EMP';
プライバシに関する法規によって、追加のビジネス・プライバシ・ポリシーが必要となる場合があります。プライバシに関する多くの法規では、個人を特定できる情報（PII）へのアクセスを企業で監視する必要があり、このような監視は監査によって実施されます。ビジネス・レベルのプライバシ・ポリシーでは、技術的、法的および企業ポリシーの問題など、データ・アクセスおよびユーザー・アカウンタビリティに関するすべての事項を満たす必要があります。
監査の目的が疑わしいデータベース・アクティビティを監視することである場合は、次のガイドラインに従います。
疑わしいデータベース・アクティビティの監査を開始する場合、対象となる特定のユーザーまたはスキーマ・オブジェクトについて入手できる情報量が多くないことがあります。したがって、最初は監査オプションをより一般的に設定します。つまり、「標準監査による一般的なアクティビティの監査」で説明している標準監査オプションを使用して設定します。
基本的な監査情報を記録および分析した後で、一般的な監査を無効にし、特定のアクションを監査します。『Oracle Databaseセキュリティ・ガイド』で説明されているファイングレイン監査を使用して、特定のアクションを監査できます。疑わしいデータベース・アクティビティの発生源に関する結論を引き出すのに十分な証拠を収集するまで、このプロセスを継続します。
疑わしいデータベース・アクティビティを監査する場合は、監査情報が監査されずに追加、変更または削除されることのないように、監査証跡を保護します。AUDIT SQL文を使用して、標準監査証跡を監査します。次に例を示します。
SQLPLUS "SYS/AS SYSDBA" Enter password: password SQL> AUDIT SELECT ON SYS.AUD$ BY ACCESS;
表7-1には監査を保護するために使用する初期化パラメータがリストされています。
| 初期化パラメータ | デフォルト設定 | 説明 |
|---|---|---|
|
|
|
監査を有効または無効にします。詳細は、「標準監査証跡の有効化または無効化」を参照してください。 |
|
AUDIT_FILE_DEST |
|
Oracle Databaseでは、必須の監査情報もこの場所に書き込まれ、 |
|
AUDIT_SYS_OPERATIONS |
|
ユーザー
UNIXシステムでは、 |
|
AUDIT_SYSLOG_LEVEL |
デフォルト設定なし |
UNIXシステムでは、 |
初期化パラメータを変更するには、「初期化パラメータ値の変更」を参照してください。初期化パラメータの詳細は、『Oracle Databaseリファレンス』および『Oracle Database管理者ガイド』を参照してください。
|
 Copyright © 2007, 2008 Oracle Corporation. All Rights Reserved. |
|