TOP ＞ 監査

監査

監査とは

Oracleデータベースは、内部で発生したすべてのアクションを監査するための機能を備えています。監査レコードは、SYS.AUD$またはオペレーティングシステムの監査証跡に書き込むことができます。
ただし、オペレーティングシステムの監査証跡を使用できるかどうかは、オペレーティングシステムによって異なります。

監査の対象とする事ができるアクションには、ログイン、データベースに対するアクション、及びオブジェクトに対するアクセスという3種類のものがあります。これらの各タイプのアクションについては、後で詳しく説明します。
Oracleデータベースはデフォルト時、監査を実行する際に、成功したコマンドも失敗したコマンドも記録します。この記録処理は、各タイプの監査処理を設定する際に変更できます。

データベース内で監査処理を有効にするには、データベースのinit.oraファイルのなかでAUDIT_TRAILパラメータによってエントリを指定しなければなりません。
AUDIT_TRAILの値は、次のとおりです。

1.AUDIT_TRAIL値

NONE 監査処理を無効にする。
DB 監査処理を有効にし、表SYS.AUD$に書き込む。
OS 監査処理を有効にし、オペレーティングシステムの監査証跡に書き込む（オペレーティングシステムによって異なる）。

AUDIT_TRAIL のTRUEおよびFALSEという値は、以前のバージョンのOracleとの下位互換性のためにサポートされているものです。TRUEはDBと等価であり、FALSEはNONEと等価です。後で説明するauditコマンドは、AUDIT_TRAILパラメータの設定値とは無関係に発行できます。

ただし、監査処理を有効にするような値がデータベースの起動時にinit.oraファイルの AUDIT_TRAILパラメータに設定されていないと、auditコマンドは起動されません。

監査レコードを表SYS.AUD$に格納する場合、その表内のレコードは定期的にアーカイブする必要があります。そして、アーカイブした後は、その表に対してtruncateコマンドを実行してください。表は、データディクショナリに格納されている為、SYSTEM表領域に格納されています。表の中のレコードを定期的に消去しないと、領域に関する問題が発生するおそれがあります。

DELETE_CATALOG_ROLEをユーザーに付与しておけば、表SYS.AUD$の中のレコードをユーザーに削除させることができます。

ログインに対する監査

データベースに接続しようとする試みは、すべて監査対象にすることができます。ログイン操作に関する監査情報の収集を開始する際は、次のコマンドを実行します。

成功した試みと失敗した試みのいずれか一方だけ収集する場合は、次のいずれかのコマンドを実行します。

表SYS.AUD$に格納されている監査レコードは、その表のDBA_AUDIT_SESSIONというデータディクショナリビューを使用すれば、出力することができます。
下記の問い合わせでは、DBA_AUDIT_SESSIONビューから、ログインに関する監査レコードを取りだしています。そして、使用したオペレーティングシステムのアカウント（OS_Username）、Oracleのアカウント名（Username）、および使用した端末のID（Terminal）を出力しています。
列Returncodeは０の場合、接続に成功したことを示しています。そうでない場合は、一般的な２つのエラー番号のいずれかと等しいかどうかをチェックし、エラーの原因を調べています。
また、ログイン時刻とログオフ時刻も出力しています。

select
    OS_Username,　　　/*使用したオペレーティングシステムのユーザー名*/
    Username,　　　　　/*使用したアカウントのOracleのユーザー名*/
    Terminal,　　　　　　/*使用した端末のID*/
    DECODE（Returncode,'0','Connected',
    　　　　　　'1005','FailedNull',
    　　　　　　'1017','Failed',Returncode）,　/*エラーのチェック*/
    TO_CHAR（Timestamp,'DD−MON−YY　HH24：MI：SS'）,/*ログイン時刻*/
    TO_CHAR（Logoff_Time,'DD−MON−YY　HH24：MI：SS'）,/*ログオフ時刻*/
From　DBA_AUDIT_SESSION;

チェックしているエラー番号は、ORA-1005とORA-1017です。これらの２つのエラーｺｰﾄﾞをチェックしておけば、ログイン時に発生するエラーのほとんどをカバーできます。
ユーザーがパスワードなしでユーザー名だけ入力すると、ORA-1005が返されます。
また、ユーザーが不正なパスワードを入力すると、ORA-1017が返されます。
セッションの監査処理を無効にするには、次のようなnoauditコマンドを実行します。

アクションに対する監査

データベースオブジェクト（表、データベースリンク、表領域、シノニム、ロールバックセグメント、ユーザー、索引など）に影響を与えるアクションも、すべて監査対象にできます。これらのオブジェクトに影響を与えるアクション（create、alter、dropなど）は、監査処理の際、グループにまとめることができます。

一連のコマンドをグループ化すれば、監査に関する設定値の設定や保守に必要な管理作業をへらすことができます。
システムレベルのコマンドは、すべての監査の対象にできます。また、コマンドのグループも指定できます。たとえば、ロールに影響を与えるコマンドを全て収集するには、次のようなコマンドを実行します。

この設定を無効にするには、次のコマンドを実行します。

監査対象のSQLコマンドをグループ化するためのオプションを、表１にしめします。それぞれのグループを指定すれば、オブジェクトに影響を与えるSQLコマンドをすべて監査対象にすることができます。
たとえば、先ほど紹介したaudit　roleコマンドの場合は、create　role、alter　role、drop　role、およびset　roleというコマンドが収集されます。表１で示した監査オプション以外に、そこに掲載した各コマンドを文指定で収集することもできます。
また、次のような文グループも使用できます。

CONNECT Oracleに対するログオン及びログオフを収集する。
DBA DBAの権限を必要とするようなコマンド（grant tablespace,revoke tablespace,audit tablespce , noaudit tablespce,create tablespace,alter tablespace,create public synonym,drop public synonymなど）を収集する。
RESOURCE 表、クラスタ、ビュー、索引、表領域、タイプ、およびシノニムに対するcreateとdropを収集する。
ALL 上記のコマンドをすべて収集する。

2.オブジェクトに対する監査でのオプション

オプション 監査の対象となるアクション。
CLUSTER クラスタの作成、変更、削除、切り捨て
DATABASE　LINK データベースリンクの作成、削除
DIRECTORY ディレクトリの作成、削除
EXISTS オブジェクトがすでに存在しているために異常終了するSQL文（Trusted　Oracle）
INDEX 索引の作成、変更、削除
NOT　EXISTS オブジェクトが存在しない為に異常終了するSQL文
PROCEDURE プロシジャ、関数、またはパッケージの作成、変更削除、およびパッケージの本体
PROFILE プロファイルの作成、変更、削除
PUBLIC　DATABASE　LINK パブリックデータベースリンクの作成、削除
PUBLIC　SYNONYM パブリックシノニムの作成、削除
ROLE ロールの作成、変更、削除、設定
ROLLBACK　SEGMENT ロールバックセグメントの作成、変更、削除
SEQUENCE 順序の作成、変更、削除
SESSION ログオンの試行
SYNONYM シノニムの作成、削除
SYSTEM　AUDIT SQL文に対する監査処理の有効化、無効化
SYSTEM　GRANT システム権限およびロールに対する監査処理の有効化、無効化
TABLE 表の作成、変更、削除、切り捨て
TABLESPACE 表領域の作成、変更、削除
TRIGGER トリガーの作成、変更、削除、および全トリガーの有効化／無効化を指定した表の変更
TYPE タイプまたはタイプ本体の作成、変更、削除
USER ユーザーの作成、変更、削除
VIEW ビューの作成、削除

▲表1

監査の対象にできるどのアクションにも、データベース内で数値コードが割り当てられています。これらの数値コードには、AUDIT_ACTIONSビューからアクセスできます。
次の問合せを実行すれば、データベース内で使用可能なアクションコードが出力されます。

select
    Action　/*アクションコード*/
    Name　/*アクションの名前（ALTER　USERなど）*/
from　AUDIT_ACTIONS;

アクションコードが判明したら、DBA_AUDIT_OBJECTビューを使用すれば、アクションからオブジェクトがどのような影響を受けたのかがわかります。次の問合せでは、DBA_AUDIT_OBJECTビューからログインに関する監査レコードを取り出しています。そして、使用したオペレーティングシステムのアカウント（OS_Username）、Oracleのアカウント名（Username）、および使用した端末のID（Terminal）を出力しています。
また、オブジェクトの所有者（Owner）とオブジェクトの名前（Obj_Name）の他に、実行したアクションのアクションコード（Action_Name）も選択しています。列Returncodeは、０の場合、接続に成功したことを示しています。そうでない場合は、エラー番号を出力しています。また、ログイン時刻とログオフ時刻も出力しています。

select
    OS_Username,　　　/*使用したオペレーティングシステムのユーザー名*/
    Username,　　　　　/*使用したアカウントのOracleのユーザー名*/
    Terminal,　　　　　　/*使用した端末のID*/
    Owner,　　　　/*影響を受けたオブジェクトの所有者*/
    Obj_Name,　　/*影響を受けたオブジェクト*/
    Action_Name,　/*アクションの数値コード*/
    DECODE（Returncode,'0','Success',Returncode）, /*エラーのチェック*/
    TO_CHAR（Timestamp,'DD-MON-YY HH24:MI:SS'）/*タイムスタンプ*/
from DBA_AUDIT_OBJECT;

また、次のようにauditコマンドでby　username句を指定すれば、特定のユーザーを指定して監査を実行することもできます。次の場合は、ユーザーMCGREGORによるupdateアクションをすべて収集しています。

◆ audit　update　table　by　MCGREGOR

オブジェクトに対する監査

オブジェクトに関しては、システムレベルのアクションだけでなく、データ操作アクションも収集することが出来ます。つまり、表に対するselect、insert、update、deleteなどの操作も、監査対象にすることができます。この種のアクションに対する監査処理の実行方法は、すぐ前の項で紹介したアクションの監査によく似ています。違いは、auditコマンドで新しい句を指定する点だけです。

オブジェクトに対して監査を実行する場合は、by　session句またはby　access句を指定します。これらの句では、監査レコードをセッションごと（by　session）に記録するのか、あるいはオブジェクトがアクセスされるたび（by　access）に記録するのかを指定します。
たとえば、同一の表に対してユーザーが４つの別々のupdate文を実行したとしましょう。by　accessを指定して監査処理を実行していた場合は、監査レコードが4件（表へのアクセスごとに1件）記録されます。

一方、by　sessionを指定して監査処理を実行していた場合は、監査レコードが1件だけ記録されます。そのため、by　accessを指定して監査処理を実行すると、記録される監査レコードの件数が非常に多くなります。by　accessを指定して監査処理を実行するのは一般に、一定期間で発生する別々のアクションの個数を数えるような特殊な場合です。そのようなテストが終わったら、by　sessionにもどします。

これらのオプションの使用方法を、次のリストに示します。先頭のコマンドでは、表EMPLOYEEに対して実行されるinsertコマンドをすべて監査対象にしています。2番目のコマンドでは、表TIME_CARDSに影響を与えるコマンドを全て監査対象にしています。また、3番目のコマンドでは、表DEPARTMENTに対して実行されるdeleteコマンドをすべて監査対象とし、情報をセッション単位で収集しています。

収集した監査レコードは、すぐ前の項で紹介したDBA_AUDIT_OBJECTビューに対して問合せを実行すれば、出力されます。

監査証跡の保護

データベースの監査証跡表であるSYS.AUD$は、データベースの中に格納されています。そのため、その表に記録されている監査レコードは、すべて保護する必要があります。そうしないと、データベース内で不正なアクションを実行した後、ユーザーが自分の監査証跡レコードを抹消しようとする可能性があります。

監査レコードをオペレーティングシステムの監査証跡に書き込むことができれば、監査レコードをデータベースの外部に格納することができるため、このような問題を解決できます。しかし、それができないオペレーティングシステムもあります。監査証跡情報をSYS.AUD$に格納しなければならない場合は、その表を保護しなければなりません。その際はまず、次のコマンドを実行して、該当する表に対して実行されるアクションを監査の対象とします。


表SYS.AUD$に対して実行されたアクション（他の表の監査に関して生成されたinsertは、カウントされない）はすべて、その監査証跡に記録されます。次に、SYS.AUD$に対して実行されたアクションは、CONNECT　INTERNALの権限を持つユーザー（つまり、DBAグループ内のユーザー）しか削除できないようにします。INTERNALとして接続している間に実行したアクションはすべて、監査証跡に自動的にかきこまれます。

可能な場合はデータベースに関する監査処理とオペレーティングシステムにおける監査処理を協調させるようにします。そうすれば、それらの２つの環境において、問題点の追跡やセキュリティポリシーの調整が簡単に行えるようになります。

システムマネージャはおそらく、個々の監査証跡を見たがりません。そのため、監査対象として重要性が一番高いアクションは、DBAが正常に解析する必要があります。そうでない場合は、この章で紹介したコマンドを利用して監査処理を変更し、目的とする処理を実現してください。

分散環境におけるセキュリティ

データベースを開放して他のサーバーからでもアクセスできるようにすると、それらのサーバーからセキュリティ面で脅威を受けることにもなります。
ただし、それらのアクセスはNet8（およびSQL*Net）を経由してやってきます。そのため、Net8のパラメータ値をうまく変更すれば、リモートサイトからの不正なアクセスにはほとんど対処できます。

１つの指針として、全てのデータには「知る必要がある」という基本姿勢でアクセスすべきです。これを拡張すると、サーバー、オペレーティングシステム、およびネットワークに対しても、「知る必要がある」という態度でアクセスすべきです。
データベースおよびオペレーティングシステムにおける現在のアクセス権は、定期的に見直す必要があります。
また、ネットワークにおける現在のアクセス権は、システム管理チームといっしょに評価する必要がある。

TOP ＞ 監査
2001/07/25　担当：Y.H