Jump to content 日本-日本語
≫ お問い合わせ

HP OpenVMS: システム・セキュリティ・ガイド > パート III  システム管理者のためのセキュリティ

第9章 セキュリティ監査の実施

≫ 

OpenVMSドキュメント・ライブラリ

目次
まえがき
Part 1:セキュリティの概要
第1章:システムセキュリティ
第2章:OpenVMSのセキュリティモデル
Part 2:一般ユーザのためのセキュリティ
第3章:システムの安全な使用
第4章:データの保護
第5章:オブジェクトクラスの詳細
Part 3:システム管理者のためのセキュリティ
第6章:システムとデータの管理
第7章:システムアクセスの管理
第8章:システムのデータと資源へのアクセス制御
第9章:セキュリティ監査の実施
第10章:システムのセキュリティ侵害
第11章:クラスタのセキュリティ保護
第12章:ネットワーク環境におけるセキュリティ
第13章:保護サブシステムの使用
付録A:特権の割り当て
付録B:システムファイルの保護
付録C:C2環境におけるシステムの運用
用語集
索引
PDF
OpenVMS ホーム
ここから本文が始まります

この章では,OpenVMS の監査システムを使用および管理する方法を説明します。システムで発生するイベントを記録し,後でその監査ログを分析することにより,システムのセキュリティに関わる活動を監視する方法について説明します。

9.1 監査プロセスの概要

監査とは,システムで発生するセキュリティに関わる活動を記録し,後でこの監査ログを分析することを指します。監査により,システム上でのユーザの活動を監視し,必要に応じて,システムのセキュリティを危険にさらす試みに至るまでの一連のイベントを再現できます。したがって,システムとそのデータを保護する手法というよりも,むしろシステムの使用状況を分析および記録する手法です。

システムまたはシステム内の保護オブジェクトへのユーザ・アクセスに関係することはすべて,セキュリティに関わる活動と見なされます。このような活動は,イベントと呼ばれます。一般的なイベントには,次のものが含まれます。

  • ログイン,ログアウト,またはログインの失敗

  • 登録データベースにおける変更

  • ファイル,デバイス,グローバル・セクションなどの保護オブジェクトへのアクセス

  • 保護オブジェクトの特権またはセキュリティ属性における変更

オペレーティング・システムは,成功と失敗の両方のイベントを記録できます。場合によっては,失敗の方が大きな意味を持つことがあります。たとえば,プログラマがアクセス権を持っているファイルを表示したことを記録するよりも,同じプログラマが保護ファイルを表示しようとして阻止されたことを記録する方が重要です。

イベント・メッセージ自体は,監査ログ・ファイルと,セキュリティ・クラス・メッセージの受信が可能になっているオペレータ・ターミナルの,2 つの場所に書き込むことができます。 例 9-1 「アラーム・メッセージのサンプル」 に示すように,メッセージには次のデータが含まれています。

  1. メッセージの日付と時刻

  2. イベントのタイプ

  3. イベントが発生した日付と時刻

  4. イベントを引き起こしたユーザのプロセス識別番号 (PID)

監査メッセージのそれ以外の情報は,そのイベントのタイプに固有の情報です。メッセージのさまざまな例については, 付録 D 「アラーム・メッセージ」 を参照してください。

例 9-1 アラーム・メッセージのサンプル

%%%%%%%%%%%  OPCOM  25-JUL-2001 16:07:09.20  %%%%%%%%%%%     
Message from user AUDIT$SERVER on GILMORE
Security alarm (SECURITY) on GILMORE, system id: 20300
Auditable event:          Process suspended ($SUSPND)        
Event time:               25-JUL-2001 16:07:08.77            
PID:                      30C00119                           
Process name:             Hobbit
Username:                 HUBERT
Process owner:            [LEGAL,HUBERT]
Terminal name:            RTA1:
Image name:               $99$DUA0:[SYS0.SYSCOMMON.][SYSEXE]SET.EXE
Status:                   %SYSTEM-S-NORMAL, normal successful completion
Target PID:               30C00126
Target process name:      SMISERVER
Target username:          SYSTEM
Target process owner:     [SYSTEM]

9.2 セキュリティ関連イベントの報告

デフォルトで決まっている報告内容 ( 表 9-1 「デフォルトで監査されるイベント・クラス」 を参照) 以外にセキュリティ管理者が受け取るセキュリティ・イベント情報の種類は,発生しうるイベントの長いリストからセキュリティ管理者が選択した情報の種類によって決まります。この節では,セキュリティ・イベント情報の報告を有効にする方法を説明します。具体的には,次のトピックについて説明します。

  • イベント・メッセージの生成方法

  • システムが報告できるイベントのタイプ

  • イベント情報のソース

9.2.1 監査情報の生成方法

システムのインストールまたはアップグレード時には,OpenVMS オペレーティング・システムによって少数のイベントが自動的に監査されます。 表 9-1 「デフォルトで監査されるイベント・クラス」 に示すこれらのイベントのカテゴリは,システムのセキュリティの大幅な変更を意味します。サイトの要件に応じて,他の形式の報告を有効にすることができます。

セキュリティに関わる活動に関してオペレーティング・システムに報告させる方法は 3 つあります。

  • 監査のためのイベントのカテゴリを有効にする方法。たとえば,すべてのログイン失敗や,システム・パラメータに対するすべての変更を報告できます。

  • 保護オブジェクトにアクセス制御エントリ (ACE) を関連付ける方法。たとえば,特定のファイルがユーザによって変更されるたびにメッセージが生成されるようにできます。

  • ユーザの登録レコードを変更して,当該アカウントから実行されるすべての操作をシステムが監査するようにする方法。

9.2.1.1 活動の監査のカテゴリ

セキュリティ関連イベントは,イベント・クラスと呼ばれるいくつかのカテゴリに分けられています。オペレーティング・システムは,いくつかのイベント・クラスをデフォルトで監査します ( 表 9-1 「デフォルトで監査されるイベント・クラス」 を参照)。 サイトのセキュリティ要件により追加の監視が必要である場合は,DCL の SET AUDIT コマンドを使用して,追加のイベント・クラスに関するセキュリティ監査を有効にします。

各種イベント・クラスの監査を有効にするには,次のコマンド形式を使用します。

SET AUDIT /ENABLE=event-class[,...] {/ALARM | /AUDIT}

イベントを有効にするには,コマンドには次の 2 つの修飾子が必要です。

  • /ENABLE 修飾子は,監査対象のイベント・クラスを定義します。イベント・クラスの一覧については, 表 9-3 「システムが報告できるセキュリティ・イベントの種類」 を参照してください。

  • /AUDIT 修飾子または /ALARM 修飾子は,イベント・メッセージの出力先を定義します。

    /AUDIT 修飾子は監査ログ・ファイルにメッセージを出力するように指示します。また /ALARM 修飾子は,セキュリティ・イベント・メッセージの受信が可能になっているオペレータ・ターミナルに,メッセージを出力するように指示します。重大なイベントは,監査とアラームの両方として報告する必要がありますが,重要度の低いイベントは,後で調査できるようにログ・ファイルに書き込むことができます。 表 9-1 「デフォルトで監査されるイベント・クラス」 に示すデフォルトのイベント・クラスは,アラームと監査の両方として監査が実施されます。

新しいイベントを有効にすると,オペレーティング・システムは直ちにクラスタの全ノードで新しいイベントの監査を開始します。監査は,/DISABLE 修飾子を使用して明示的にクラスを無効にするまで継続されます。現在の監査設定は SYS$MANAGER:VMS$AUDIT_SERVER.DAT に記録されるため,システムのブートをまたいで設定が維持されます。

SET AUDIT コマンドの詳細については,『OpenVMS DCL ディクショナリ』を参照してください。

表 9-1 デフォルトで監査されるイベント・クラス

クラス説明

ACL

セキュリティ監査 ACE を保持する任意のオブジェクトへのアクセス

Audit

SET AUDIT コマンドのすべての使用。このカテゴリは無効にできません。

Authorization

次の登録データベースに対するすべての変更。

  • システム・ユーザ登録ファイル (SYSUAF.DAT)

  • ネットワーク代理登録ファイル (NETPROXY.DAT または NET$PROXY.DAT)

  • ライト・データベース (RIGHTSLIST.DAT)

Break-in

すべての侵入行為 (バッチ,独立,ダイアルアップ,ローカル,ネットワーク,遠隔)。

Logfailure

すべてのログイン失敗 (バッチ,ダイアルアップ,ローカル,遠隔,ネットワーク,サブプロセス,独立,サーバ)。

 

サイトで現在監査対象になっているイベント・クラスを表示するには,DCL の SHOW AUDIT コマンドを入力します。 例 9-3 「セキュリティ要件が中程度であるサイトの イベントの監査」 に,セキュリティ要件が中程度であるサイトの監査設定を示します。

イベント・クラスの有効化の例

セキュリティに関わる活動の全クラスの監査を有効にすることは可能ですが (/ENABLE=ALL),このような方法では大量の監査メッセージが発生し,あまりに多くの情報が生成されるため,有効な分析ができなくなります。そのため, 9.3.1 項 「監査要件の評価」で説明しているように必要性を評価し,システムの活動を選択的に監査することをお勧めします。

イベント・クラスの監査は,さまざまなレベルの精度で行えます。次のような方法があります。

  • クラスの有効化

    たとえば,すべてのログイン失敗の監査を有効にするには,次のコマンドを入力して,logfailure クラスを有効にします。

    $ SET AUDIT/AUDIT/ENABLE=LOGFAILURE=ALL
    

    このコマンドの結果,監査サーバはすべてのログイン失敗をセキュリティ監査ログ・ファイルに報告します。

  • クラスのサブセットの有効化

    一部のイベントについて,有効にする報告の種類をより細かく選択できます。たとえば,すべてのログイン・イベントを有効にするよりも,ネットワーク・ログイン・イベントと遠隔ログイン・イベントを有効にする方が合理的です。

    ネットワーク・ログインと遠隔ログインのみの監査を有効にするには,次のコマンドを入力します。

    $ SET AUDIT/AUDIT/ENABLE=LOGIN=(NETWORK,REMOTE)
    
  • 成功イベント,失敗イベント,または特権イベントの有効化

    失敗イベントのレポート,または特定の特権のもとで行われた活動の報告のみを有効にすることで,システムの通常の使用を報告するイベント・メッセージを簡単に除外できます。

    特に,保護オブジェクトに対するアクセス・イベントを監査する場合は,ログインやインストール・ユーティリティの使用などのイベント・クラスの場合よりも,情報の要件をより細かく定義する必要があります。ファイルや,その他一部の保護オブジェクトは頻繁にアクセスされるため,関連するアクセス・イベント・クラスをすべて有効にすると,膨大な数のイベント・メッセージが生成され,実際に調査を必要とする異常イベントが見失われる可能性があります。このため,失敗イベントや特権アクセス・イベントなどの例外的な状況についてのみアクセス監査を有効にすることをお勧めします。

    ファイル・アクセス失敗イベントの監査を有効にするには,次のコマンドを入力します。

    $ SET AUDIT/AUDIT/ENABLE=ACCESS=FAILURE/CLASS=FILE
    

    このコマンドは,読み込みアクセスまたは書き込みアクセスの失敗だけでなく,すべてのファイル・アクセスの失敗の監査を有効にすることに注意してください。単純な書き込み操作と思われる操作も,複数のタイプのアクセスが関与するなど(たとえばファイルへの書き込みの前に,ディレクトリ内のファイルへのアクセス権だけでなく,ボリュームへのアクセス権と,ディレクトリへの読み込みアクセス権が必要であるなど),アクセス操作はかなり複雑な場合があるため,このような設定をお勧めします。

    例 9-2 「オブジェクト・アクセス・イベントにより作成される監査」 に,ファイル・アクセスの失敗によるイベント・メッセージを示します。ユーザ Robinson がファイル FOO.BAR を削除しようとしましたが,そのファイルの ACE により阻止されました。メッセージから,Robinson が識別子 MINDCRIME を保持しており,FOO.BAR の識別子用 ACE が,当該識別子を保持する人物にアクセスを許可していないことがわかります。さらに,システムがこのファイルを所有しているため,Robinson は保護コードによりこのファイルの削除アクセス権も取得できません。

例 9-2 オブジェクト・アクセス・イベントにより作成される監査

Message from user AUDIT$SERVER on BILBO
Security alarm (SECURITY) and security audit (SECURITY) on BILBO,
                       system id: 19662
Auditable event:       Object deletion
Event information:     file deletion request (IO$_DELETE)
Event time:            24-APR-2001 13:17:24.59
PID:                   47400085
Process name:          Hobbit
Username:              ROBINSON
Process owner:         [ACCOUNTING,ROBINSON]
Terminal name:         OPA0:
Image name:            DSA2264:[SYS51.SYSCOMMON.][SYSEXE]DELETE.EXE
Object class name:     FILE
Object owner:          [SYSTEM]
Object protection:     SYSTEM:RWED, OWNER:RWED, GROUP:RE, WORLD:RE
File name:             _DSA2200:[ROBINSON]FOO.BAR;1
File ID:               (17481,6299,1)
Access requested:      DELETE
Matching ACE:          (IDENTIFIER=MINDCRIME,ACCESS=NONE)
Sequence key:          00008A41
Status:                %SYSTEM-F-NOPRIV, no privilege for attempted operation

9.2.1.2 セキュリティ監査 ACE の関連付け

9.2.1.1 項 「活動の監査のカテゴリ」の説明にあるように,保護オブジェクトへのアクセスに関するイベントは頻繁に発生するため,その監査については慎重に検討する必要があります。イベント・メッセージが多すぎると,その量に圧倒され,実際に調査を必要とする異常イベントが見失われる可能性があります。

保護オブジェクトより細かく監査する方法としては,オブジェクトのアクセス制御リスト (ACL) に監査 ACE を追加し,ACL イベント・クラスを有効にするという方法があります。このアプローチでは,クラスに属する全オブジェクトではなく,セキュリティ監査 ACE を持つオブジェクトへのアクセスのみがイベント・メッセージを生成します。

イベントの報告先に応じて,2 種類の監査 ACE を使用できます。アラーム ACE は,イベント・メッセージをオペレータ・ターミナルに出力し,監査 ACE は,イベント・メッセージを監査ログ・ファイルに出力します。 表 9-2 「セキュリティ監査用のアクセス制御エントリ (ACE)」 に,監査 ACE の概要を示します。また『OpenVMS システム管理ユーティリティ・リファレンス・マニュアル』では,監査 ACE の詳細を説明しています。 監査 ACE の対象になっているシステム・ファイルの一覧については, 表 10-1 「ACL ベースの監査が有効なシステム・ファイル」 を参照してください。

表 9-2 セキュリティ監査用のアクセス制御エントリ (ACE)

ACE のタイプ説明

アラーム ACE

指定の方法でオブジェクトがアクセスされるたびに,オペレータ・ターミナルにイベント・メッセージを書き込みます。構文は次のとおりです。

(ALARM=SECURITY[,OPTIONS=options],ACCESS=access-type[+access-type...])

監査 ACE

指定の方法でオブジェクトがアクセスされるたびに,セキュリティ監査ログ・ファイルにイベント・メッセージを書き込みます。構文は次のとおりです。

(AUDIT=SECURITY [,OPTIONS=options],ACCESS=access-type[+access-type...])

 

保護したいオブジェクトに ACE を関連付けるには,DCL の SET SECURITY/ACL コマンドを使用するか,アクセス制御リスト・エディタ (ACL エディタ) を使用します。監査 ACE の ACCESS 文には,必ず SUCCESSキーワード と FAILURE キーワードの一方 (または両方) を追加します。

自動ログイン・ファイルの SYSALF.DAT,オペレータ・ログ・ファイルの OPERATOR.LOG,システム会計ファイルの ACCOUNTING.DAT など,自動では監査されない重要なシステム・ファイルに対しては,監査 ACE を定義することをお勧めします。ただし,大部分が有用でない大量のメッセージが生成されるため,アクセスのすべての状況の監視は行わないでください。たとえば,OPERATOR.LOG への正常な書き込み操作を追跡しても,重要な情報は得られませんが,書き込みの試みの失敗を追跡すれば,重要な情報が得られる可能性があります。

監査対象のオブジェクトとしてはファイルが最も一般的ですが,任意のオブジェクトに監査 ACE を追加できます。機密文書を扱うプリント・キューや,パスワード・グラバの試みを検出するためにターミナルに,監査 ACE を追加できます。 3.8 項 「パスワードの保護に関するガイドライン」「パスワードの保護に関するガイドライン」を参照してください。

監査 ACE の追加例

ACCOUNTING.DAT ファイルのアラーム ACE を設定するには,次のコマンドを入力します。

$ SET SECURITY/ACL=(ALARM=SECURITY,ACCESS=DELETE+CONTROL+SUCCESS+FAILURE)-
_$  SYS$MANAGER:ACCOUNTING.DAT

ACL イベント・クラスはデフォルトで有効になっていますが,サイトで無効になっている場合は,次のコマンドを入力して,監査 ACE の使用を再度有効にする必要があります。

$ SET AUDIT/ALARM/AUDIT/ENABLE=ACL

9.2.1.3 ユーザ登録レコードの変更

時として,不審な行動をするユーザが見つかることがあります。たとえば,複数のターミナルからログインしていたり,例外的な時間帯や曜日にログインしていたりします。ユーザの行動を監視するには,ユーザ登録レコードの監査属性を変更します。AUTHORIZE ユーティリティを実行し,Audit フラグを設定します。

AUDIT フラグを設定すると,極めて多数の監査メッセージが生成されることに注意してください。次のコマンド・シーケンスは,ユーザ Robin のアカウントを変更します。

$ RUN SYS$SYSTEM:AUTHORIZE
UAF> MODIFY ROBIN/FLAGS=AUDIT

%UAF-I-MDFYMSG, user record(s) updated

Audit フラグが設定してあると,オペレーティング・システムはそのユーザのプロセスを監査します。監査ログ・ファイルには,オペレーティング・システムによる監査が可能な,ユーザの任意の行動が含まれます ( 9.2.2 項 「オペレーティング・システムが報告できるシステム活動の種類」を参照)。監査分析ユーティリティを使用して,ユーザの行動を確認できます。たとえば,ユーザ Robin の行動に関する報告を入手するには,次のコマンドを入力します。

$ ANALYZE/AUDIT/SELECT=(FLAGS=MANDATORY,USERNAME=ROBIN) -
_$ SECURITY.AUDIT$JOURNAL

監査分析ユーティリティの詳細な説明については, 9.5 項 「ログ・ファイルの分析」を参照してください。

9.2.2 オペレーティング・システムが報告できるシステム活動の種類

DCL の SET AUDIT コマンドを使用すれば, 表 9-3 「システムが報告できるセキュリティ・イベントの種類」 に示すイベント・クラスの 1 つまたは複数に対する監査を有効にできます。 多くのイベント・クラスには,イベント・クラスのサブセットの定義を可能にするキーワードがあります[3]

表 9-3 システムが報告できるセキュリティ・イベントの種類

イベント・クラス説明

Access

クラス内の全オブジェクトに対するアクセス要求。特定のクラスの全保護オブジェクトに対する (特権と非特権の両方の),選択したタイプのアクセスを監査できます。

ACL

あるオブジェクトの ACL にあるセキュリティ監査 ACE またはアラーム ACE により要求されるイベント。

Authorization

SYSUAF.DAT,NETPROXY.DAT,NET$PROXY.DAT,または RIGHTSLIST.DAT の任意部分の変更。

Breakin

侵入行為。

Connection

SYSMAN,DECnet Phase IV,HP DECwindows Motif for OpenVMS, またはプロセス間通信 (IPC) 呼び出しを介した論理リンクの接続または切断。

Create

保護オブジェクトの作成。

Deaccess

保護オブジェクトからのアクセス解除。

Delete

保護オブジェクトの削除。

Identifier

特権としての識別子の使用。

Install

インストール・ユーティリティによる既知ファイル・リストへの変更。

Logfailure

ログインの失敗。

Login

ログインの成功。

Logout

ログアウト。

Mount

ボリュームのマウントおよびディスマウント。

NCP

ネットワーク制御プログラム (NCP) を使用したネットワーク構成データベースへの変更。

Privilege

特権の使用の成功または失敗。

Process

1 つまたは複数のプロセス制御システム・サービスの使用。

SYSGEN

System Generation ユーティリティ (SYSGEN) または AUTOGEN を使用した,システム・パラメータの変更。

Time

システム時刻の変更。

 

9.2.2.1 一部の特権監査の抑制

サイトで特権イベント・クラスを有効にしても,オペレーティング・システムは当該クラスのあらゆるイベントを報告するわけではありません。オペレーティング・システムは次のタイプの監査を抑制します。

  • インストールされているイメージが有する特権の使用の成功

    たとえば,イメージ SHOW.EXE は,WORLD 特権を有するようにインストールされます。非特権ユーザが SHOW SYSTEM コマンドを入力すると,SHOW.EXE は WORLD 特権を使用して,ワイルドカードの $GETJPI システム・サービス呼び出しを実行します。WORLD 特権のこのような使用は監査されません。ただし,同じ非特権ユーザが SHOW PROCESS コマンドを使用して,アクセスを許可されていないプロセスのプロセス属性を表示しようとすると,その操作は失敗します。SHOW.EXE が WORLD 特権を有するようにインストールされていても,この WORLD 特権の欠如は監査されます。

  • インストールされているイメージが有する特権よりも下位の特権の使用の成功

    イメージが,使用される特権よりも上位の特権を有するようにインストールされている場合,要求が成功したときには,下位の特権は監査されません。たとえば,CMKRNL 特権を有するようにインストールされたイメージが,$CMEXEC システム・サービス呼び出しの実行に成功した場合,CMEXEC 特権は監査されません。特権には次のような関係が存在します。

    上位の特権下位の特権

    PRMMBX

    TMPMBX

    CMKRNL

    CMEXEC

    SYSNAM

    GRPNAM

    WORLD

    GROUP

    SYSPRV

    GRPPRV

    BYPASS

    SYSPRV,GRPPRV,READALL,DOWNGRADE,UPGRADE

  • SETPRV を有するようにインストールされたイメージによる,SETPRV 特権の使用

    オペレーティング・システムは,SETPRV の使用を監査しませんが,SETPRV を使用して有効にされた特権の使用はすべて監査します。イメージをインストールする時は実際に必要な特権を与えるようにして,SETPRV 特権を与えてイメージをインストールすることは避けることをお勧めします。

  • 保護サブシステムにおいて,サブシステム識別子を使用した正常アクセス

9.2.2.2 一部のプロセス制御監査の抑制

サイトでプロセス・イベント・クラスを有効にしても,オペレーティング・システムは当該クラスのあらゆるイベントを報告するわけではありません。オペレーティング・システムは次のタイプの監査を抑制します。

  • DCL の RUN/TRUSTED コマンド,または PRC$M_TCB フラグを設定した Create Process システム・サービス ($CREPRC) を使用して作成されたサーバ・プロセス

    クライアントに関する情報を監査する必要があるサーバ・アプリケーションは,監査対象の呼び出しの間だけプロセスの非監査設定をオーバーライドする監査フラグ NSA$M_SERVER または CHP$M_SERVER を設定できます。

  • 要求側と同じ UIC を持つ,プロセスのジョブ・ツリー内のプロセス制御イベント

    自分のプロセスを対象に識別子の付与または削除を行っても,プロセス制御監査は発生しません。ただし,$CREPRC と $DELPRC の使用に関連するイベントは,常に監査されます。

9.2.3 イベント情報のソース

アプリケーションとシステム・プログラムは,次のシステム・サービスを呼び出すことにより,セキュリティ・イベント情報を提供できます。

  • $AUDIT_EVENT

  • $CHECK_PRIVILEGE

  • $CHKPRO および $CHECK_ACCESS

イベント監査 ($AUDIT_EVENT) システム・サービス

オペレーティング・システムは,システムでセキュリティに関わるイベントが発生するたびに,$AUDIT_EVENT システム・サービスを呼び出します。システム・サービスは,SET AUDIT 設定を参照して,当該イベントの監査が有効になっているかどうかを判定します。イベントのアラームまたは監査が有効である場合,$AUDIT_EVENT は監査レコードを作成します。この監査レコードは,関係したプロセス (サブジェクト) を示し,呼び出し元により提供されたイベント情報を列挙します。

特権チェック ($CHECK_PRIVILEGE) システム・サービス

オペレーティング・システムは,ユーザが特権機能を実行しようとするたびに $CHECK_PRIVILEGE システム・サービスを呼び出します。OpenVMS 特権の現在のセットは, 付録 A 「特権の割り当て」 に示します。このシステム・サービスは特権チェックを実行し,SET AUDIT 設定を参照して,特権の監査が有効になっているかどうかを判定します。特権の監査が有効であれば,$CHECK_PRIVILEGE は監査レコードを作成します。監査レコードは,関係したプロセス (サブジェクト) と特権を示し,特権チェックの結果を提供し,その呼び出し元より提供された補足イベント情報を列挙します。通常,特権監査レコードには,特権チェックに対応する DCL コマンド行またはシステム・サービス名が含まれています。

保護チェック ($CHKPRO) およびアクセス・チェック ($CHECK_ACCESS) システム・サービス

オペレーティング・システムは,プロセス (サブジェクト) が保護オブジェクトにアクセスしようとするたびに $CHKPRO システム・サービスを呼び出します。システム・サービスは, 4.3 項 「システムによる保護オブジェクトへのユーザのアクセス可否の判定」「システムによる保護オブジェクトへのユーザのアクセス可否の判定」で説明している規則に従って,アクセス・アービトレーションを実行します。このシステム・サービスは,対応するオブジェクト・クラスの SET AUDIT 設定を参照することで,対応するオブジェクト・アクセス・イベントの監査を有効にしたかどうかも判定します。アラームまたは監査が必要である場合,$CHKPRO は監査レコードを作成します。この監査レコードは,関係したプロセス (サブジェクト) とオブジェクトを示し,チェックの最終的な結果と,呼び出し元による補足イベント情報を含みます。

特権サーバ・プロセスは,$CHECK_ACCESS システム・サービスを使用して,サービス対象の保護オブジェクトへのアクセス権をクライアントに与えるべきかどうかを判定します。$CHECK_ACCESS システム・サービスは,サーバに適した呼び出しインタフェースを提供し,$CHKPRO サービスの上位の層に配置されます。そのため,$CHKPRO 同じ方法でオブジェクト・アクセス監査を実行します。

9.3 監査計画の策定

システム管理者またはサイトのセキュリティ管理者が監査対象にするセキュリティ・イベントを把握するには,サイトで必要なセキュリティのレベルを決める必要があります。

9.3.1 監査要件の評価

監査要件の評価は,次の 2 つのステップからなるプロセスです。

  1. サイトの全般的なセキュリティ要件が,高,中,低のいずれであるかを判定します。 表 1-1 「セキュリティ要件の基準となるイベント許容度」 に,セキュリティ上のニーズを判定するためのガイダンスを示します。

  2. サイトのニーズが判明したら,有効にすべきイベント・クラスの推奨リストについて, 表 9-4 「サイトのセキュリティ要件に応じて監視すべきイベント」 を参照します。

サイトの要件の全般的な方向性を決めたら,セキュリティ報告の現実的な量を検討する必要があります。 表 9-4 「サイトのセキュリティ要件に応じて監視すべきイベント」 の推奨事項と,次に示すサイトの要素とのバランスを考慮します。

  • サイトのデータの機密保護の重要性

  • ログ・ファイルの分析に費やせる時間

  • 使用可能なディスク容量

  • セキュリティの脅威に関する知識 (発生源,または発生源の可能性が高い場所)

  • システムのチューニング要件 (性能への影響の詳細ついては, 9.3.3 項 「性能への影響の考慮」を参照)

表 9-4 サイトのセキュリティ要件に応じて監視すべきイベント

 

目標

影響の大きいローカル・イベントの監視

システム定義に対する変更の追跡

データベースへの変更の監視,プロセス制御システム・サービスの使用の追跡,DECnet Phase IV を介したネットワーク接続の監視 (VAX のみ)

アラームとして有効にすべきクラス

ACL,登録,侵入 (全タイプ),ログイン失敗 (全タイプ)

「低」カテゴリと同じ内容に加え,SECURITY 特権の使用

「中」カテゴリと同じ内容に加え,INSTALL,時刻,SYSGEN,特権使用の失敗

監査として有効にすべきクラス

ACL,登録,侵入 (全タイプ),ログイン失敗 (全タイプ)

「低」カテゴリのすべてに加え,INSTALL,時刻,SYSGEN,特権,ログイン (全タイプ),ログアウト (全タイプ),(BYPASS,SYSPRV,および READALL 特権を介した) ファイルのアクセス,ファイル,デバイス,およびボリュームへのアクセス失敗

「中」カテゴリのすべてに加え,識別子,プロセス,保護オブジェクトへのアクセス失敗,NCP,接続 (VAX のみ)

 

表 9-4 「サイトのセキュリティ要件に応じて監視すべきイベント」 において,セキュリティ要件が低いサイトに推奨されているイベント・クラスは,オペレーティング・システムのデフォルト設定になっています。 これらのクラスがシステムで現在のデフォルトになっていない場合は,次のコマンドを使用して有効にします。

$ SET AUDIT/ALARM/AUDIT -
_$ /ENABLE=(ACL,AUTHORIZATION,BREAKIN:ALL,LOGFAILURE:ALL)

セキュリティ要件が中程度であるサイトでは,システムを再定義するようなイベントを監査する必要があります。システム・ファイル,システム時刻,またはシステム・パラメータに対する変更が監視対象です。また,イメージのインストールと,特権の使用も監視します。 例 9-3 「セキュリティ要件が中程度であるサイトの イベントの監査」 に,セキュリティ要件が中程度であるサイトの監査設定を示します。

例 9-3 セキュリティ要件が中程度であるサイトの イベントの監査

System security alarms currently enabled for:
  Authorization
  Breakin:       dialup,local,remote,network,detached
System security audits currently enabled for:
  ACL
  Authorization
  INSTALL
  Time
  SYSGEN
  Breakin:       dialup,local,remote,network,detached
  Login:         batch,dialup,local,remote,network,subprocess,detached,server
  Logfailure:    batch,dialup,local,remote,network,subprocess,detached,server
  Logout:        batch,dialup,local,remote,network,subprocess,detached,server
  Privilege use:
    ACNT      ALLSPOOL  ALTPRI    AUDIT     BUG       BYPASS    CMEXEC    CMKRNL
    DIAGNOSE  DOWNGRADE EXQUOTA   GROUP     GRPNAM    GRPPRV    IMPORT    IMPERSONATE
    LOG_IO    MOUNT     NETMBX    OPER      PFNMAP    PHY_IO    PRMCEB    PRMGBL
    PRMMBX    PSWAPM    READALL   SECURITY  SETPRV    SHARE     SHMEM     SYSGBL
    SYSLCK    SYSNAM    SYSPRV    TMPMBX    UPGRADE   VOLPRO    WORLD
  Privilege failure:
    ACNT      ALLSPOOL  ALTPRI    AUDIT     BUGCHK    BYPASS    CMEXEC    CMKRNL
    DIAGNOSE  DOWNGRADE EXQUOTA   GROUP     GRPNAM    GRPPRV    IMPORT    IMPERSONATE
    LOG_IO    MOUNT     NETMBX    OPER      PFNMAP    PHY_IO    PRMCEB    PRMGBL
    PRMMBX    PSWAPM    READALL   SECURITY  SETPRV    SHARE     SHMEM     SYSGBL
    SYSLCK    SYSNAM    SYSPRV    TMPMBX    UPGRADE   VOLPRO    WORLD
  FILE access:
    SYSPRV:      read,write,execute,delete,control
    BYPASS:      read,write,execute,delete,control
    READALL:     read,write,execute,delete,control

中程度のレベルの監査の設定を有効にするには,デフォルトのイベントがすでに有効であるという前提で,次のコマンドのセットを入力します。

$ SET AUDIT/ALARM/AUDIT/ENABLE=PRIVILEGE=(SUCCESS:SECURITY,FAILURE:SECURITY)
$ SET AUDIT/AUDIT/ENABLE=(INSTALL,SYSGEN,TIME,PRIVILEGE=(SUCCESS,FAILURE))
$ SET AUDIT/AUDIT/ENABLE=ACCESS=(BYPASS,SYSPRV,READALL)/CLASS=FILE
$ SET AUDIT/AUDIT/ENABLE=ACCESS=FAILURE/CLASS=(FILE,DEVICE,VOLUME)

セキュリティ要件が高いサイトでは,ネットワークの活動を含むように監査の範囲を拡張します。ネットワーク・データベースに対する変更,ネットワーク接続 (VAX のみ),特権としての識別子の使用,および特権ファイル・アクセスを監視する必要があります。SYSPRV,BYPASS,または READALL 特権を介したすべてのファイル・アクセスを監視し,また GRPPRV 特権を介したファイル・アクセスの成功と失敗の両方を監視します。高レベルの監査の設定を有効にするには,中レベルがすでに有効であるという前提で,次のコマンドのセットを入力します。

$ SET AUDIT/ALARM/ENABLE=(INSTALL,SYSGEN,TIME,PRIVILEGE=(FAILURE:ALL) )
$ SET AUDIT/AUDIT/ENABLE=(CONNECTION,IDENTIFIER,NCP,PROCESS:ALL)
$ SET AUDIT/AUDIT/ENABLE=ACCESS=FAILURE/CLASS=*

すべての監査を有効にするには,次のコマンドを入力します。

$ SET AUDIT/AUDIT/ENABLE=ALL/CLASS=*

すべての監査を無効にするには,次のコマンドを入力します。

$ SET AUDIT/AUDIT/DISABLE=ALL/CLASS=*

有効にすべき他の推奨イベント・クラスについては, 10.3.2 項 「セキュリティ監査の実施」を参照してください。

9.3.2 イベント・メッセージの出力先の選択

オペレーティング・システムは,セキュリティ・イベントを,アラームと監査のどちらの形式でも報告できます ( 9.2.1.1 項 「活動の監査のカテゴリ」を参照)。どちらの形式を選択するかは,イベントの性質によります。侵入行為や,システム・ユーザ登録ファイル (SYSUAF.DAT) への変更など,リアルタイムのイベントや直ちに対処しなければならないイベントは,アラームと監査の両方として有効にすべきクラスです。これらよりも重要性の低いイベントについては,監査のみ有効にするということができます。ハードコピー・オペレータ・ターミナルを使用する場合を除き,アラーム・レコードはすぐに他のシステム・メッセージに置き換わってしまいます。システム・セキュリティ監査ログに書き込まれる監査イベント・レコードは,まとめて調査できるように保存されます。

イベント・メッセージの調査には,メリットがあります。多くの場合,単独の監査メッセージから得られる情報はわずかですが,大量の監査レコードがあれば,セキュリティ違反を示す可能性のある活動パターンが明らかになります。たとえば,オブジェクトのアクセスを監査することで,セキュリティ管理者は時刻のパターン,アクセスされているオブジェクトのタイプ,およびその他のシステム情報を把握し,これらを総合することで,システム活動の全体像を描くことができます。 9.5 項 「ログ・ファイルの分析」では,監査ログ・ファイルからレポートを作成する方法を説明します。

9.3.3 性能への影響の考慮

オペレーティング・システムにより実行されるデフォルトの監査は,主に登録データベースへの変更を追跡します。システム・ユーザ登録ファイル (SYSUAF.DAT) に対する変更やイメージのインストールなどのシステム・イベントは,それほど頻繁には発生しないため,システムの資源を大量に消費することはありません。

システムの使われ方を把握せずに,また監査情報の価値を評価することなく,サイトで追加イベント・クラスを有効にして,特にアクセス・イベントや特権イベントなどの追加のイベント・クラスを監査すると,大量のシステム資源が消費される可能性があります。この点では,監査報告システムの実装は,システムのチューニングに似ています。つまり,不要な詳細データが含まれていない,適切な報告のレベルを実現するには,少し時間がかかります。このため,一度にすべてではなく,段階的に監査を有効にして,適切なバランスに到達するまで徐々にイベント・クラスの追加/削除を行うことをお勧めします。次のガイドラインに従います。

  • 9.3.1 項 「監査要件の評価」 で説明している方法で,監査の要件を評価します。

  • オブジェクト・アクセス・イベントは選択して監査します。オブジェクト・アクセス・イベントは常時発生するため,システムの性能に最大の影響を与えます。通常は,ファイル・アクセスの成功ではなくファイル・アクセスの失敗を監査し,またファイル・クラス全体の監査を有効にするのではなく,重要なファイルに監査 ACE を適用します。

  • 実行しているレイヤード・プロダクトを調査して,どの特権が使用される可能性があるかを把握します。また,バックアップ操作時の READALL 特権の使用など,サイト固有のプロシージャを把握しておきます。特権イベントは頻繁に発生するため,システム性能に大きな影響を与えます。

  • 一度に有効にするイベント・クラスは少数にして,十分なイベント情報が得られるようになるまで,必要に応じて追加/削除します。有効にするクラスが多いほど,オーバーヘッドが大きくなり,システム上の有用な作業に使用できる資源が少なくなります。

特に次の 2 つのコマンドは,大量の監査メッセージを生成します。

  • DCL の PIPE コマンドは,1 つの PIPE コマンドを実行するために多数のサブプロセスを作成することがあります。このことは,サブプロセスの活動に関連するイベント (プロセスの作成,プロセスの削除,ログイン,ログイン失敗,ログアウトなど) の監査が増大する可能性があることを意味します。

  • UAF の MODIFY USER/FLAG=AUDIT コマンドは,非常に多くの監査メッセージを生成します。通常はこのフラグを設定する必要はありません。つまり,特定の AUDIT が有効である場合,ユーザ・フラグを設定する必要はありません。

9.4 イベント・メッセージの取得方法

オペレーティング・システムは,監査ログ・ファイルおよびオペレータ・ターミナルにイベント・メッセージを送信できます。サイトで追加のコピーが必要な場合,オペレーティング・システムは遠隔のログ・ファイルやアプリケーション・リスナ・メールボックスにメッセージのコピーを送信できます。

9.4.1 監査ログ・ファイルの使用

オペレーティング・システムは,最新バージョンのセキュリティ監査ログ・ファイルに,すべてのセキュリティ・イベント・メッセージを書き込みます。このログ・ファイルは,デフォルトではシステム・スタートアップ時に SYS$COMMON:[SYSMGR] ディレクトリに作成され,SECURITY.AUDIT$JOURNAL という名前が付けられています。 表 9-5 「監査ログ・ファイルの特徴」 に,このファイルの最も顕著な特徴を示します。

表 9-5 監査ログ・ファイルの特徴

特徴メリット

バイナリ

バイナリ・ファイルが必要とするディスク領域は最少です。

クラスタ・ワイド

クラスタ・ワイド・ファイルを監査分析ユーティリティで処理すると,クラスタ内のセキュリティ関連イベントについて単独のレポートが生成されます。

順次レコード形式

順次レコード形式は,ユーザが記述するプログラムで分析するのが簡単です。セキュリティ監査ログ・ファイルのメッセージ形式の説明については,『OpenVMS システム管理ユーティリティ・リファレンス・マニュアル』を参照してください。

 

通常,すべてのクラスタ・イベントが単独の監査ログ・ファイルに書き込まれます。クラスタで 1 つのセキュリティ監査ログ・ファイルを使用することで,システム上の全セキュリティ関連イベントの記録が一本化されます。このため,ノード固有の複数の監査ログよりも,1 つのクラスタ・ワイド・ログ・ファイルの方が優れています。ノード固有の監査ログでは,クラスタ全体のイベントの相互関係が失われ,セキュリティ・イベントの分析が不完全になってしまうためです。必要であればノード固有の監査ログを作成できますが ( 9.4.1.1 項 「ファイルの保守」を参照),お勧めしません。

セキュリティ監査ログ・ファイルの有用性は,どのような手順を採用するかによって決まります。

9.4.1.1 ファイルの保守

セキュリティ監査ログ・ファイルは,何らかの対応を取るまで増大し続けるため,このファイルの保守計画を考えておく必要があります。

一般的には,サイトがログ・ファイルの名前を毎日変更し,新しいログ・ファイルを作成します。新しい,クラスタ・ワイドのセキュリティ監査ログ・ファイルを開くには,次のコマンドを使用します。

$ SET AUDIT/SERVER=NEW_LOG

ノード固有の新しいログを作成するには,SET AUDIT/SERVER=NEW_LOG コマンドの前に SET AUDIT/DESTINATION=filespec コマンドを実行します。filespec は,ノード固有のファイルに解決される論理名 (SYS$SPECIFIC:[SYSMGR]SECURITY など) が含まれるファイル指定です。

新しいログを開いたら,古いバージョンの名前を,データの開始日または終了日を含む名前に変更します。

システム・ディスクの領域を節約するために,ファイルを別のディスクにコピーして,システム・ディスクからそのログを削除できます。セキュリティ要件が高い環境では一般的な,専用の監査ディスクが装備されているサイトであっても,今後のメッセージ用に領域を空けるため,古いバージョンを移動させる場合があります。

ファイルをアーカイブしたら,古いログを対象に監査分析ユーティリティを実行します ( 9.5.2 項 「監査分析ユーティリティの起動」を参照)。このファイルをアーカイブすることにより,監査メッセージについてクラスタ・ワイドの履歴を維持管理します。万一システム上にセキュリティ上の危険が見つかった場合は,アーカイブされたログ・ファイルを分析して,指定した期間におけるユーザの疑わしい処理の形跡を調べることができます。

9.4.1.2 システム・ディスクからのファイルの移動

SYS$COMMON:[SYSMGR] ディレクトリからファイルを移動するには,コマンド・プロシージャ SYSECURITY.COM を編集します。このプロシージャは,システムのリブートのたびに監査サーバが起動する前に実行されます。

ファイルを移動するには,次の手順を実行します。

  1. 監査サーバ・プロセスの起動後ではなく起動前に指定の監査ディスクをマウントするよう,オペレーティング・システムに指示するため,SYSECURITY.COM に 1 行を追加することで,スタートアップ・シーケンスを変更します。次に例を示します。

    $ IF .NOT. F$GETDVI("$1$DUA2","MNT") -
    _$ THEN MOUNT/SYSTEM $1$DUA2 AUDIT AUDIT$ /NOREBUILD
    

    この例のコマンドは,$1$DUA2 上にある AUDIT というラベルのボリュームをマウントし,システム全体でそのボリュームを使用できるようにします。また,MOUNT により,論理名 AUDIT$ も割り当てられます。

  2. 必要であれば,監査サーバ・データベースを監査ディスクに移動します。データベースのサイズは小さく,比較的変化が少ないため,この手順はあまり重要ではありません。

    データベースを移動するには,SYSECURITY.COM に 2 行目を追加し,システム論理名 VMS$AUDIT_SERVER を定義します。2 行目は,監査ディスクをマウントする行の次の行にします。コマンドを使用してシステム論理名を定義し,論理名 AUDIT$ を持つディスク上の VMS$AUDIT_SERVER データ・ファイルに,そのシステム論理名を割り当てます。次に例を示します。

    $ DEFINE/SYSTEM/EXEC VMS$AUDIT_SERVER AUDIT$:[AUDIT]VMS$AUDIT_SERVER.DAT
    

    このコマンドは,手順 1 でマウントした $1$DUA2 上のボリュームに,監査サーバ・データベースをリダイレクトします。

  3. DCL レベルから,SYSECURITY.COM でマウントされたボリュームに,セキュリティ監査ログ・ファイルをリダイレクトします (手順 1 を参照)。SET AUDIT コマンドを使用して,セキュリティ監査ログ・ファイルの新しい位置を監査サーバ・データベースに反映し,クラスタ内の各ノード上の監査サーバ・プロセスに対して,そのファイルの使用を開始するよう通知します。次に例を示します。

    $ SET AUDIT/JOURNAL=SECURITY -
    _$ /DESTINATION=AUDIT$:[AUDIT]SECURITY
    

    システムの再起動のたびにこのコマンドを繰り返す必要はありません。

    セキュリティ監査ログ・ファイルの指定で論理名を使用する場合,その論理名は,SYSECURITY.COM の /SYSTEM 論理名として定義する必要があります。

9.4.2 ターミナルのアラーム受信の有効化

オペレーティング・システムは,セキュリティ・クラス・メッセージが有効になっているターミナルに対して,アラーム・メッセージを送信します。ほとんどの場合,これらのセキュリティ・アラームはデフォルトでシステム・コンソールに表示されます。メッセージはすぐにスクロールして画面から消えてしまうため,セキュリティ・クラス・メッセージ用に独立したターミナルを有効にして,システム・コンソールへのメッセージ配信を無効にすることをお勧めします。安全な場所でハードコピー出力を行うターミナルを用意するか,専任スタッフにセキュリティ・オペレータ・ターミナルを監視させます。セキュリティ・オペレータとして有効にできるターミナルの数に制限はありません。

セキュリティ・クラス・アラームを受信するようターミナルを設定するには,使用するターミナルから次の DCL コマンドを入力します。

$ REPLY/ENABLE=SECURITY

特定のターミナルを長期間使用する場合は,サイト固有のスタートアップ・コマンド・プロシージャを変更して,そのターミナルを自動的に有効にすることができます。たとえば,スタートアップ・コマンド・プロシージャに次のコマンド行を含めると,システム・コンソールへのセキュリティ・アラームの配信が無効になり,ターミナル TTA3 でアラームが有効になります。

$ DEFINE/USER SYS$COMMAND OPA0:
$ REPLY/DISABLE=SECURITY
$ DEFINE/USER SYS$COMMAND TTA3:
$ REPLY/ENABLE=SECURITY

登録イベント・クラスと SYSGEN イベント・クラスは,非常に長いアラーム・メッセージを生成することがあるため,メッセージが切り詰められることがあります。このため,これらのクラスではアラームと監査の両方を有効にすることをお勧めします。アラーム・メッセージが切り詰められると,そのテキストはアラーム・メッセージが不完全であることを示します。対象クラスの監査メッセージ出力を有効にしている限り,ANALYZE/AUDIT を使用して完全なメッセージを表示することができます。

9.4.3 イベント・メッセージの第 2 の出力先

オペレータ・ターミナルと監査ログ・ファイルは,セキュリティ・イベント・メッセージの第 1 の出力先です。サイトでは,(アーカイブ・ファイルと呼ばれる) 遠隔ログ・ファイルまたはリスナ・メールボックスに,監査メッセージのコピーを送信することを選択できます。

9.4.3.1 遠隔ログ・ファイルの使用

このオペレーティング・システムでは,管理能力が限定されているワークステーションやユーザが,別のノードに監査ログ・ファイルを複製することができます。セキュリティ・アーカイブ・ファイルと呼ばれるこの第 2 ログは,遠隔ノードに置かれ,それを分析する能力を持つセキュリティ管理者が利用できるようになります。場合によっては,アーカイブ・ファイルが,ローカルの監査ログ・ファイルが何らかの方法で改ざんされた場合の保険にもなります。ノード単位で監査メッセージをアーカイブ・ファイルに出力できます。有効にすると,監査サーバは各監査メッセージのコピーを,セキュリティ監査ログ・ファイルだけでなくセキュリティ・アーカイブ・ファイルにも書き込みます。

注意:

クラスタ内の各ノードは,それぞれ専用のアーカイブ・ファイルが必要です。アーカイブ・ファイルは,クラスタ内の複数のノードでは共用できません。

セキュリティ監査メッセージを遠隔セキュリティ・アーカイブ・ファイルに書き込むには,次の手順を実行します。

  1. アーカイブ・ファイルが存在するノードにログインし,監査サーバのアカウントを作成します。そのアカウントに,AUDIT_ARCHIVE のようなユーザ名を割り当てます。アカウントを非特権にし,ネットワーク・アクセスのみを残します。アカウントが,セキュリティ・アーカイブ・ファイルが格納されているデバイスとディレクトリにアクセスできることを確認します。

    $ SET DEFAULT SYS$SYSTEM
    $ RUN AUTHORIZE
    UAF> ADD AUDIT_ARCHIVE /ACCESS=NETWORK /DEVICE=WORK2-
    _UAF> /DIRECTORY=[AUDIT_ARCHIVE]
    
  2. AUDIT$SERVER に対する代理アカウントを遠隔ノードに追加します。これにより,監査サーバ・プロセスは,遠隔ノード上のアカウントにデータを書き込めるようになります。たとえば次のコマンドは,ノード SMLNOD 上の監査サーバ・プロセスに,ノード BIGNOD 上の AUDIT_ARCHIVE アカウントへの代理アクセスを許可します。

    UAF> ADD/PROXY SMLNOD::AUDIT$SERVER AUDIT_ARCHIVE/DEFAULT
    UAF> EXIT
    

    代理アカウントの設定の詳細については, 12.3.2 項 「代理データベースの設定」を参照してください。

  3. 遠隔ノードからログアウトします。ローカル・ノード上で次のコマンドを入力して,ノードへのログ・ファイルのアーカイブ作成を有効にします。

    $ SET AUDIT/ARCHIVE=ALL/DESTINATION=BIGNOD::WORK2:-
    _$ [AUDIT_ARCHIVE]SMLNOD_MAY_93.AUDIT$JOURNAL
    

    ディレクトリの指定は完全な形式で行う必要があります。論理名を含める場合は,ローカルの監査サーバ・プロセスが論理名を変換できることを確認します。

新しいアーカイブ・ファイルを作成するには,現在のファイルの名前を変更します。システムの次回起動時に,システムによって新しいファイルが作成されます。

ネットワークが停止すると,セキュリティ・アーカイブ・ファイル用のメッセージは失われます。セキュリティ・オペレータ・ターミナルは,接続が失われたという通知と,失われたメッセージの数を受信します。ネットワークが回復すれば,監査サーバは元のアーカイブ・ファイルへの接続を再度確立し,イベント・メッセージの書き込みを継続します。

セキュリティ・アーカイブ・ファイルの分析は,多くの点でセキュリティ監査ログ・ファイルの分析と同じです。ファイルが開いている状態でも,遠隔セキュリティ・アーカイブ・ファイルはいつでも分析できます。詳細については 9.5 項 「ログ・ファイルの分析」を参照してください。

9.4.3.2 リスナ・メールボックスの使用

セキュリティ監査機能の追加機能として,リスナ・デバイスを作成してセキュリティ監査メッセージのバイナリ・コピーを受信するようにできます。リスナ・デバイスとは,メールボックス作成 [$CREMBX] システム・サービスを使用して作成する,パーマネント・メールボックスまたは一時的メールボックスです。アプリケーションを設定して監査情報を受信および処理し,システム上でイベントが発生した時点でイベントに対応するようにできます。システムごとに 1 つのリスナ・デバイスを持つことができ,そのリスナ・デバイスはローカル・ノード上で発生するイベントのみを受け取れます。

リスナ・デバイスを有効にしてセキュリティ監査メッセージを受信するには,次の形式で SET AUDIT/LISTENER コマンドを実行します。

SET AUDIT/LISTENER=device-name

device-name パラメータとして,メールボックスの作成時に指定した論理名を使用するか,"MBAn" の形式でメールボックスの等価名を使用します (n はメールボックスのユニット番号を表します)。デバイスを一時的メールボックスとして作成する場合は,メールボックス・デバイス名を返すには,デバイスおよびボリューム情報取得 ($GETDVI) システム・サービスを使用する必要があります。

監査リスナ・デバイスを無効にするには,次のコマンドを入力します。

$ SET AUDIT/NOLISTENER

VAX システムの場合,DECtalk デバイス上のリスナ・メールボックスに送信される監査イベント・メッセージを処理するプログラムの例については,SYS$EXAMPLES ディレクトリにある,AUDSRV_LISTENER.B32 ファイル (VAX BLISS プログラム) および AUDSRV_LISTENER.MAR ファイル (VAX MACRO プログラム) を参照してください。

9.5 ログ・ファイルの分析

セキュリティ監査ログ・ファイルでセキュリティ監査メッセージを収集しても,そのファイルを確認して疑わしい活動を調べなければ意味がありません。監査分析ユーティリティ (ANALYZE/AUDIT) を使用して,セキュリティ監査ログ・ファイルのデータを調べます。

システム上の通常の活動を把握し,例外的な活動を簡単に見つけられるように,ANALYZE/AUDIT はログ・ファイルからレポートを作成します。ANALYZE/AUDIT はイベントを要約し,クラスタ上で活動が行われている場所を示します。このユーティリティは,監査レポートから情報のサブセットを選択し,分析用により詳細な情報を提供できるため,例外的な処理の分析にも役立ちます。1 つの監査ログ・ファイルを分析してもあまり意味がない可能性はありますが,監査レコードが長期に渡れば,セキュリティ違反を示す活動パターンを明らかになることがあります。

9.5.1 推奨される手順

この節では,システムの監査ログ・ファイルを分析する方法を説明します。ANALYZE/AUDIT の使用方法はサイトのセキュリティ要件に依存しますが,ユーティリティの使用範囲に関係なく,従うべき共通の手順がいくつか存在します。潜在的なセキュリティ問題を認識できるようになる前には,システムの通常の運用を把握する必要があります。定期的に監査レポートを作成および確認する手順を策定できるのは,その後です。監査ログ・ファイルの定期的な分析の中でセキュリティ問題の疑いが見つかった場合は,選択したセキュリティ・イベントの詳細な調査を実行する必要があります。

手順 1 : 通常の状態の把握

セキュリティ管理者は,監査ログ・ファイルを分析するためには,次の質問に答えられる必要があります。

  • システムの大部分のユーザが作業を行う一般的な時間帯。

  • 通常時に高度な特権を使用して処理を行う特定のユーザが存在するかどうか。

  • どのイメージが他のアプリケーションの一部としてシステム・セキュリティ・イベントを作成するか。

  • 特定の時間帯に実行される定期的なバッチ・ジョブまたはネットワーク・ジョブが存在するかどうか。

以上の質問に対する答えを知っておけば,セキュリティ問題を誤って疑う原因となるアラームの誤報をなくすことができます。

手順 2 : 監査レポートの定期的な分析

最も一般的に作成するレポートのタイプは,簡潔な毎日のイベントのリストです。コマンド・プロシージャを作成し,毎晩,夜半前にバッチ・ジョブとして実行して,その日のセキュリティ・イベント・メッセージのレポートを生成するようにできます。同じプロシージャで,監査ログの新しいバージョンを作成するようにもできます ( 9.4.1.1 項 「ファイルの保守」を参照)。

次の例は,このレポートを生成するための ANALYZE/AUDIT コマンド行を示します。

$ ANALYZE/AUDIT/SINCE=TODAY/OUTPUT=31DEC2000.AUDIT -   1
_$ SYS$MANAGER:SECURITY.AUDIT$JOURNAL
$ MAIL/SUBJECT="Security Events" 31DEC2000.AUDIT SYSTEM   2

1

このプロシージャ例の最初のコマンドでは,31DEC2000.AUDIT という名前の監査レポートを生成しています。これには,当日生成された全セキュリティ・イベント・メッセージの情報が 1 行ずつ含まれています。

2

2 番目のコマンドでは,調査のために,ファイルをセキュリティ管理者にメールで送信しています。

システム上で監査しているセキュリティ・イベントの数によっては,監査ログ・ファイルに書き込まれるすべての監査レコードを確認する作業は現実的ではない場合があります。このような場合,登録データベースの変更や侵入行為に関連するすべての監査レコードや,通常の業務時間外に発生したすべてのイベントなど,ログ・ファイルから特定のセットのレコードを選択することができます。

(DCL の PIPE コマンドにより作成される) PIPE サブプロセスが監査を生成できることを念頭において,サブプロセス関連の監査を分析します。PIPE コマンドは,1 つの PIPE コマンドを実行するために多数のサブプロセスを作成することがあります。このことは,サブプロセスの活動 (プロセスの作成,プロセスの削除,ログイン,ログイン失敗,ログアウトなど) に関連する監査イベントが増大する可能性があることを意味します。

監査レポートの確認は,できる限りすみやかに行うことが重要です。レポートの検査が早いほど,システムに対するセキュリティ侵害の可能性の検出と,問題の程度の判断が早くできるようになります。前日の監査レポートの検査を朝の定期的な作業の一部にしたり,レポートを確認し,疑わしいイベントが発生した場合に Mail ユーティリティ (MAIL) を使用して通知するプログラムを作成することもできます。

手順 3 : 疑わしい活動の調査

レポートの確認時に,通常の業務時間外のログインの試みなど,疑わしい,または不適切と思われるセキュリティ・イベントが見つかった場合は,監査分析ユーティリティを使用して,セキュリティ監査ログ・ファイルを詳細に調べます。完全なレポートを見ることで,監査ログ・ファイルに記録されているどのセキュリティ・イベントをより徹底的な調査するべきかを判断できます。

次のコマンドを使用して,選択したセキュリティ監査レコードの完全なレポートを生成できます。

$ ANALYZE/AUDIT/FULL/SINCE=TODAY/OUTPUT=31DEC2000.AUDIT -
_$ /EVENT_TYPE=(BREAKIN,RIGHTSDB,SYSUAF)
$ MAIL/SUBJECT="Security Events" 31DEC2000.AUDIT SYSTEM

2000 年 12 月 31 日の監査レポートには,すべての侵入行為と,システム・ユーザ登録ファイル (SYSUAF.DAT) およびライト・データベース (RIGHTSLIST.DAT) へのすべての変更に関する情報が含まれています。

9.5.2 監査分析ユーティリティの起動

監査分析ユーティリティは,バイナリ・ログ・ファイルから,意味のあるレポートを作成するために使用するツールです。この節と以降の節では,このユーティリティの使用方法を説明しますが,ユーティリティのコマンドと修飾子の完全な説明については,『OpenVMS システム管理ユーティリティ・リファレンス・マニュアル』を参照してください。

監査分析ユーティリティを起動するには,次の DCL コマンドを使用します。

ANALYZE/AUDIT file-name

file-name パラメータの部分には,監査レポートの元となるファイルの名前を使用します。セキュリティ監査ログ・ファイルのデフォルトの名前は,SECURITY.AUDIT$JOURNAL です。ディレクトリ SYS$MANAGER を指定する必要があります。

9.5.3 レポートの指定

監査分析ユーティリティを使用して,1 つの監査ログからセキュリティ・イベント・メッセージの一部または全部を抽出し,さまざまなレベルの詳細を含んだレポートを作成できます。

監査レポートには,サイトで有効になっているイベント・クラスのセットに含まれているイベントが反映されます ( 9.2 項 「セキュリティ関連イベントの報告」を参照)。イベントの一部のみが抽出されるように,レポートを調整することができます。時間,イベント・クラス,またはイベント・メッセージ内のデータのフィールドに基づいて選択基準を設定できます。『OpenVMS システム管理ユーティリティ・リファレンス・マニュアル』の /SELECT 修飾子の解説を参照してください。レポートの内容を決定する修飾子の要約を, 表 9-6 「監査分析ユーティリティの修飾子」 に示します。

表 9-6 監査分析ユーティリティの修飾子

タイプ修飾子説明

内容

/BEFORE

指定時間の前に記録されたイベント・メッセージを抽出します。

 

/SINCE

指定時間の後に記録されたイベント・メッセージを抽出します。

 

/EVENT_TYPE

特定のイベント・クラスのイベント・メッセージを抽出します ( 表 9-3 「システムが報告できるセキュリティ・イベントの種類」 を参照)。

 

/SELECT

メッセージ内のデータに基づいてイベント・メッセージを抽出します。たとえば,/SELECT=USERNAME=JSNOOP と指定すると,ユーザ JSNOOP により作成されたセキュリティ・イベント・メッセージのみを列挙します。

/IGNORE

メッセージ内のデータに基づいて,レポートからイベント・メッセージを除外します。

形式

/BRIEF

監査ログ・ファイル内のレコードごとに,イベントのタイプ,イベントが発生した日時,イベントの発生源であるターミナルなどの情報で構成される 1 行の情報を含むレポートを作成します ( 例 9-4 「簡略監査レポート」 を参照)。これがデフォルトです。

 

/FULL

処理される監査ログ・ファイル内のレコードごとに,可能なすべてのデータを提供します ( 例 9-5 「完全な監査レポートの 1 つのレコード」 を参照)。 付録 D 「アラーム・メッセージ」 に,各イベント・クラスのアラーム・メッセージの例を示します。

 

/SUMMARY

分析対象ログ・ファイル内のイベント・クラスごとの監査メッセージの合計数を列挙します ( 例 9-6 「監査ログ・ファイルのイベントの要約」 を参照)。また,各ノード上の 1 時間ごとのイベントの集計も出力できます。

 

/BINARY

独自に用意するデータ削減ツールを使用してさらに詳細な分析を行うためのレコードを抽出できるよう,バイナリ・ファイルを作成します。監査メッセージのレコードの形式については,『OpenVMS システム管理ユーティリティ・リファレンス・マニュアル』を参照してください。

出力先

/OUTPUT

レポートの出力先を指定します。デフォルトでは SYS$OUTPUT に出力されます。

 

ANALYZE/AUDIT は,さまざまな形式で監査レポートを作成します ( 表 9-6 「監査分析ユーティリティの修飾子」 を参照)。デフォルトでは,このユーティリティはログ・ファイルのレコードごとに 1 行の要約を作成します。簡潔な 1 行のレポートは,ログ・ファイルの定期的な分析には最も便利です。より詳細な完全レポートは,疑わしいレコードの分析に必要な詳細情報を提供します。ログ・ファイルの一部をアーカイブしたい場合は,バイナリ出力により監査ログ・ファイルのサブセットを保存することができます。

要約レポートによって,セキュリティ問題の可能性を素早く特定することができます。要約レポートは,セキュリティ・イベントのクラスごとに,分析対象のセキュリティ監査ログ・ファイルから抽出された監査メッセージの合計数を列挙することができます。また要約レポートは,イベント・メッセージを生成したシステム,イベントの発生時刻,および確認されたイベントの合計数に基づいて,監査活動の一覧表を表示することもできます。

例 9-4 「簡略監査レポート」 に,システム・セキュリティ監査ログ・ファイルに記録された,全セキュリティ監査イベントの簡略レポートを示します。レポートを生成する ANALYZE/AUDIT コマンドでは,使用する監査ログ・ファイルの名前に置き換えます。

例 9-4 簡略監査レポート

$ ANALYZE/AUDIT/BRIEF SYS$MANAGER:SECURITY.AUDIT$JOURNAL
      Date / Time       Type    Subtype     Node  Username  ID    Term
--------------------------------------------------------------------------
 1-NOV-2000 16:00:03.37 ACCESS  FILE_ACCESS HERE  SYSTEM   5B600AE4
 1-NOV-2000 16:00:59.66 LOGIN   SUBPROCESS  GONE  ROBINSON 3BA011D4
 1-NOV-2000 16:02:37.31 LOGIN   SUBPROCESS  GONE  MILANT   000000D5
 1-NOV-2000 16:06:36.40 LOGFAIL LOCAL       SUPER MBILLS   000000E5 _TTA1:
.
.
.

例 9-5 「完全な監査レポートの 1 つのレコード」 に,完全な形式の監査レポートから 1 行のレコードを抜き出して示します。レポートを生成する ANALYZE/AUDIT コマンドでは,使用する監査ログ・ファイルの名前に置き換えます。

例 9-5 完全な監査レポートの 1 つのレコード

$ ANALYZE/AUDIT/FULL SYS$MANAGER:SECURITY.AUDIT$JOURNAL
Security audit (SECURITY) on FNORD, system id: 19728
Auditable event:          Object access
Event time:               6-AUG-2000 11:54:16.21
PID:                      3D200117
Process name:             Hobbit
Username:                 PATTERSON
Process owner:            [ACCOUNTING,PATTERSON]
Terminal name:            RTA1:
Object class name:        LOGICAL_NAME_TABLE
Object name:              LNM$SYSTEM_DIRECTORY
Access requested:         WRITE
Status:                   %SYSTEM-S-NORMAL, normal successful completion
Privileges used:          SYSPRV

例 9-6 「監査ログ・ファイルのイベントの要約」 に,要約レポートを示します。レポートを作成する ANALYZE/AUDIT コマンドでは,使用する監査ログ・ファイルの名前に置き換えます。

例 9-6 監査ログ・ファイルのイベントの要約

$ ANALYZE/AUDIT/SUMMARY SYS$MANAGER:SECURITY.AUDIT$JOURNAL
Total records read:        9701          Records selected:       9701
Record buffer size:        1031
Successful logins:          542          Object creates:         1278
Successful logouts:         531          Object accesses:        3761
Login failures:              35          Object deaccesses:      2901
Breakin attempts:             2          Object deletes:          301
System UAF changes:          10          Volume (dis)mounts:       50
Rights db changes:            8          System time changes:       0
Netproxy changes:             5          Server messages:           0
Audit changes:                7          Connections:               0
Installed db changes:        50          Process control audits:    0
Sysgen changes:               9          Privilege audits:         91
NCP command lines:          120

9.5.4 会話形式での監査分析ユーティリティの使用

ターミナルに出力を送信する場合は,監査ログ・ファイルを会話形式で分析できます。リスト表示中の任意の時点で Ctrl/C を押すことにより,表示されているレポートを中断できます。これにより,自動的に完全なリスト表示が開始され,Command> プロンプトが表示されます。コマンド・モードでは,レポート内で先に進んだり前のレコードに戻って,レコードを詳細に調べることができます。

Command> プロンプトでは,『OpenVMS システム管理ユーティリティ・リファレンス・マニュアル』の任意の ANALYZE/AUDIT コマンドを入力して,分析基準の変更,監査レポート内での位置の変更,または完全な表示と簡略表示の切り替えを行うことができます。監査レポートの表示に戻るには,CONTINUE コマンドを入力します。

9.5.5 レポートの調査

監査ログ・ファイルの定期的な分析で,(実際の侵入,侵入の試み,ログイン失敗の繰り返しなどの疑わしいセキュリティ・イベントにより) システムのセキュリティが危険にさらされている疑いが見つかった場合には,セキュリティ監査ログ・ファイルをより詳しく調査することによって,セキュリティ・イベントの発生源を調査できます。

たとえば,前日の監査レポートの定期的な調査中に, 例 9-7 「監査レポートにある疑わしい活動の 特定」 に示すセキュリティ・イベントが確認されたとします。

例 9-7 監査レポートにある疑わしい活動の 特定

      Date / Time        Type    Subtype    Node   Username  ID       Term
-----------------------------------------------------------------------------
.
.
. 26-OCT-2000 16:06:09.17 LOGFAIL REMOTE BOSTON KOVACS 5BC002EA _RTA14: 26-OCT-2000 16:06:220.01 LOGFAIL REMOTE BOSTON KOVACS 5BC002EA _RTA14: 26-OCT-2000 16:06:34.17 LOGFAIL REMOTE BOSTON KOVACS 5BC002EA _RTA14: 26-OCT-2000 16:06:450.50 LOGFAIL REMOTE BOSTON KOVACS 5BC002EA _RTA14: 26-OCT-2000 16:07:12.39 LOGIN REMOTE BOSTON KOVACS 5BC002EA _RTA14: 26-OCT-2000 16:23:42.45 SYSUAF SYSUAF_ADD BOSTON KOVACS 5BC002EA _RTA14: .
.
.

例 9-7 「監査レポートにある疑わしい活動の 特定」 のレポートに表示されているセキュリティ・イベントは,ユーザ Kovacs が,ログインに 4 回失敗した後でシステムにログインしたことを示しています。ユーザ Kovacs はログインしてすぐに,システム・ユーザ登録ファイル (SYSUAF.DAT) に新しいアカウントを作成しています。

この時点で,この行動が正常か異常かを判断する必要があります。そのためには,システムに新しいユーザ・アカウントを追加する権限がユーザ Kovacs にあるかどうかを考慮します。システムのセキュリティが危険にさらされていると考えられる場合は,次のコマンドを使用してセキュリティ監査ログ・ファイルからより詳細なレポートを生成し,システムが損害を受けているかどうかを判断します。

$ ANALYZE/AUDIT/FULL/SINCE=01-JUN-2003:16:06

この例のコマンドは,ユーザ Kovacs が最初にシステムへのログインを試みた時点から監査ログ・ファイルに書き込まれたすべてのセキュリティ監査イベントの完全なレポートを生成します。完全な形式のレポートでは,監査ログ・ファイルにある各レコードの全データが表示されます。完全なレポートを使用することで, 例 9-8 「疑わしいレコードの調査」 に示すように,ローカルの KOVACS のアカウントにログインした遠隔ユーザの名前と,ログイン元のノードを判定することができます。

例 9-8 疑わしいレコードの調査

   .
   .
   .
Security alarm (SECURITY) and security audit (SECURITY) on BOSTON,
                        system id: 20011
Auditable event:        Remote interactive login failure
Event time:             01-JUN-2003 16:06:09.17
PID:                    5BC002EA
Username:               KOVACS
Terminal name:          _RTA14:
Remote nodename:        NACHWA         Remote node id:      7300
Remote username:        FOLLEN
Status:                 %LOGIN-F-INVPWD, invalid password
   .
   .
   .
Security alarm (SECURITY) and security audit (SECURITY) on BOSTON,
                        system id: 20011
Auditable event:        Remote interactive login
Event time:             01-JUN-2003 16:07:120.39
PID:                    5BC002EA
Username:               KOVACS
Terminal name:          _RTA14:
Remote nodename:        NACHWA         Remote node id:      7300
Remote username:         FOLLEN

例 9-8 「疑わしいレコードの調査」 に表示されている情報は,ログインの失敗とその後のログイン成功が,遠隔ノード NACHWA からユーザ Follen により行われたことを示しています。次のステップは,セキュリティ・イベントがユーザ Follen に起因するものか,FOLLEN のアカウントを利用して遠隔ノード NACHWA に侵入した誰かに起因するものかを判断します。

9.6 監査サブシステムの管理

この節では,監査システムの管理方法を説明します。管理タスクには,次の作業が含まれます。

  • 監査サーバ・プロセスのスタートアップの有効化および無効化

  • スタートアップにおける,オペレーティング・システムが監査を開始するポイントの変更

  • プロセス中断のきっかけとなる未処理メッセージの数の指定

  • メモリの枯渇に対する監査サーバの対応の指定

  • メッセージの正確なタイムスタンプ設定の維持

  • システム監査バッファからディスクへのメッセージ転送の調整

  • システム監査ログに定期的に割り当てられるディスク容量の指定

9.6.1 監査サーバにより実行されるタスク

オペレーティング・システムは,システム・スタートアップ時に独立プロセスとして監査サーバを作成し,次のタスクを実行します。

  • SYS$COMMON:[SYS$MGR] での,クラスタ・ワイド・セキュリティ監査ログ・ファイル (SECURITY.AUDIT$JOURNAL) の作成

  • ログ・ファイルへのセキュリティ・イベントの記録と,セキュリティ・クラス・メッセージの受信が有効になっている任意のオペレータ・ターミナルへのアラーム配信の制御

  • サイト定義のセキュリティ・イベント・セットの監査の有効化

  • ディスクとメモリの資源の監視

  • セキュリティ監査特性のデータベースの維持

監査サーバは,オペレータ通信マネージャ (OPCOM) に情報メッセージとエラー・メッセージを送信します。OPCOM はこれらのメッセージをオペレータ・ターミナルにブロードキャストし,メッセージをオペレータ・ログ・ファイルに書き込みます。

例 9-9 「監査サーバのデフォルトの特性」 に,監査サーバの初期の動作値を示します。これらの設定は,監査サーバ・データベースである,SYS$COMMON:[SYSMGR] の VMS$AUDIT_SERVER.DAT に保存されます。DCL の SET AUDIT コマンドを使用してセキュリティ監査の特性を変更するたびに,監査サーバ・データベースが更新されます。また,システムのリブートのたびに,システムはこのデータベースから監査の値を取得します。

例 9-9 監査サーバのデフォルトの特性

$ SHOW AUDIT/ALL
List of audit journals:
  Journal name:           SECURITY
  Journal owner:          (system audit journal)
  Destination:            SYS$COMMON:[SYSMGR]SECURITY.AUDIT$JOURNAL
  Monitoring:             enabled
    Warning thresholds,   Block count:    100   Duration:  2 00:00:00.0
    Action thresholds,    Block count:     25   Duration:  0 00:30:00.0

Security auditing server characteristics:
  Database version:       4.4
  Backlog (total):        100, 200, 300
  Backlog (process):      5, 2
  Server processing intervals:
    Archive flush:        0 00:01:00.00
    Journal flush:        0 00:05:00.00
    Resource scan:        0 00:05:00.00
  Final resource action:  purge oldest audit events

Security archiving information:
  Archiving events:       none
  Archive destination:

System security alarms currently enabled for:
  ACL
  Authorization
  Breakin:     dialup,local,remote,network,detached
  Logfailure:  batch,dialup,local,remote,network,subprocess,detached,server

System security audits currently enabled for:
  ACL
  Authorization
  Breakin:     dialup,local,remote,network,detached
  Logfailure:  batch,dialup,local,remote,network,subprocess,detached,server

9.6.2 監査サーバのスタートアップの無効化と再有効化

オペレーティング・システムはすべてデフォルトで監査サーバ・プロセスと OPCOM を起動します。

システムの物理メモリまたはディスク・ストレージ領域が特に限定されていて,かつセキュリティ関連イベントのログ記録が重要でない場合は,システム・スタートアップ・プロシージャから監査サーバと OPCOM のプロセスを削除できます。ただし,削除の前に,クラスタ・オブジェクトのサポートには監査サーバが必要である点に注意してください ( 第11章 「クラスタのセキュリティ保護」を参照)。次の例に,システム管理ユーティリティ (SYSMAN) を使用して,これらのプロセスを削除する方法を示します。

$ SET PROCESS/PRIVILEGES=(OPER,BYPASS)
$ RUN SYS$SYSTEM:SYSMAN
SYSMAN> STARTUP SET DATABASE STARTUP$STARTUP_VMS
SYSMAN> STARTUP DISABLE FILE VMS$CONFIG-050_OPCOM.COM/NODE=*
SYSMAN> STARTUP DISABLE FILE VMS$CONFIG-050_AUDIT_SERVER.COM /NODE=*
SYSMAN> EXIT

$ SET PROCESS/PRIVILEGES=(NOOPER,NOBYPASS)

監査サーバ・プロセスを削除し,システム上のセキュリティ監査をシャット・ダウンするには,クラスタの各ノードで次のコマンドを入力します。

$ SET AUDIT/ALARM/AUDIT/DISABLE=ALL/CLASS=*
$ SET AUDIT/SERVER=EXIT

システム上のセキュリティ監査と OPCOM を再起動するには,次の DCL コマンド行を入力します。

$ @SYS$SYSTEM:STARTUP OPCOM
$ @SYS$SYSTEM:STARTUP AUDIT_SERVER

以降のすべてのシステムのブート時に OPCOM と監査サーバ・プロセスを起動するには,システム・スタートアップ・プロシージャに加えた編集をすべて元に戻します。次の SYSMAN コマンドを使用します。

$ SET PROCESS/PRIVILEGES=(OPER,BYPASS)
$ RUN SYS$SYSTEM:SYSMAN
SYSMAN> STARTUP SET DATABASE STARTUP$STARTUP_VMS
SYSMAN> STARTUP ENABLE FILE VMS$CONFIG-050_OPCOM.COM/NODE=*
SYSMAN> STARTUP ENABLE FILE VMS$CONFIG-050_AUDIT_SERVER.COM -
_SYSMAN> /NODE=*

SYSMAN> EXIT

$ SET PROCESS/PRIVILEGES=(NOOPER,NOBYPASS)

SYSMAN の詳細については,『OpenVMS システム管理ユーティリティ・リファレンス・マニュアル』を参照してください。

9.6.3 スタートアップにおける,オペレーティング・システムが監査を開始するポイントの変更

通常,オペレーティング・システムは SYSTARTUP_VMS.COM の実行の直前に,監査イベント・メッセージの送信を開始します。しかし,スタートアップ時に監査イベント・メッセージの受信を必要としていないサイトでは,論理名 SYS$AUDIT_SERVER_INHIBIT を再定義することにより,この動作を変更できます。

オペレーティング・システムによるセキュリティ・イベント・メッセージの配信開始ポイントを変更するには,SYS$MANAGER:SYLOGICALS.COM コマンド・プロシージャに,次の行を追加します。

$ !
$ DEFINE /SYSTEM /EXECUTIVE SYS$AUDIT_SERVER_INHIBIT yes
$ ! 

システム管理者は,SYSTARTUP_VMS 終了時点など,システム・スタートアップの別の段階を選択して監査を開始することができます。ただし,システムへの一般のログインを許可する前 (つまり,すべての SET LOGINS/INTERACTIVE コマンドの前) には,必ず監査を開始してください。監査メッセージの配信を開始するには,適切なコマンド・ファイルに次の行を追加します。

$ !
$ SET AUDIT/SERVER=INITIATE
$ ! 

9.6.4 プロセス中断のきっかけとなる未処理メッセージの数の指定

監査サーバがメッセージの流入を制御している場合を除き,ある条件下では,メモリ不足になる可能性があります。非常に遅い入出力デバイス,ディスク領域の問題,または突然のメッセージの大量発生により,メッセージをディスクに書き込むサーバの能力が対応できなくなることがあります。メモリの枯渇を防ぐために,監査サーバは未処理メッセージの総数を常時監視し,アクティブな各プロセスにより生成されるメッセージの数を数えます。サーバは,ディスクに記録可能な量を超えるイベントを受信した場合,監査イベントを生成しているプロセスに対して,フロー制御の適用を開始します。

9.6.4.1 メッセージのフロー制御

メッセージの量は,プロセス単位で制御されます。 表 9-7 「監査イベント・メッセージのフロー制御」 に,フロー制御の 3 つの段階を示します。

表 9-7 監査イベント・メッセージのフロー制御

制御の段階メッセージの合計バックログ (デフォルト)プロセス・バックログの上限 (デフォルト)

1

100

5

2

200

2

3

300

なし

 

  1. メモリ内に 100 個のメッセージがある場合は,オペレーティング・システムは 5 つ以上の未処理メッセージを持つプロセスをすべて一時中断します。プロセスの全メッセージがログ・ファイルに書き込まれれば,プロセスは処理を再開できます。

  2. メモリ内に 200 個のメッセージがある場合は,全メッセージがディスクに書き込まれるまで,オペレーティング・システムは 2 つ以上のメッセージを送信したプロセスをすべて一時中断します。

  3. メモリ内に 300 個のメッセージがある場合は,全メッセージがディスクに書き込まれるまで,メモリ内にメッセージを持つすべてのプロセスが一時中断されます。

SET AUDIT コマンドに /BACKLOG 修飾子を指定することで,メッセージを制御するためのサイト固有の値を設定することができます。たとえば,次のコマンドを使用すると,キュー内に 125 個の未処理メッセージがあり,かつ生成側プロセスに 8 個の未処理メッセージが発生した時点で,オペレーティング・システムがメッセージ流入の制御を開始するように,アクションしきい値を引き上げます。

$ SET AUDIT/BACKLOG=(TOTAL=(125,250,350),PROCESS=(8,4) )

9.6.4.2 プロセスの一時中断の防止

当然ながら,オペレーティング・システムはいくつかの重要なプロセスは一時中断しません。リアルタイム・プロセスと,次のプロセスはすべて一時中断を免除されています。

CACHE_SERVER

CLUSTER_SERVER

CONFIGURE

DFS$COM_ACP

DNS$ADVER

IPCACP

JOB_CONTROL

NETACP

NET$ACP

OPCOM

REMACP

SHADOW_SERVER

SMISERVER

SWAPPER

TP_SERVER

VWS$DISPLAYMGR

VWS$EMULATORS

 

プロセスを一時中断の対象から除外するには,プロセス識別子 (PID) をプロセス除外リストに追加します。次の形式の SET AUDIT コマンドを使用します。

SET AUDIT/EXCLUDE=process-id

プロセスがシステムからログアウトしても,プロセス (PID) はプロセス除外リストから自動的には削除されない点に注意してください。除外リストからプロセスを削除するには,SET AUDIT/NOEXCLUDE コマンドを使用します。オペレーティング・システムによって除外されているプロセスは削除できません。

9.6.5 メモリ不足への対応

除外リスト上のプロセス ( 9.6.4.2 項 「プロセスの一時中断の防止」を参照) があまりに多くの監査メッセージを生成するために監査サーバがメモリ不足になった場合,監査サーバはデフォルトの動作として,メモリが使用できるようになるまで古いイベント・メッセージを削除します。これにより,最新のメッセージが保存されます。

監査サーバには,メモリ不足に陥った場合に使用できる次の代替策もあります。

オプション説明

Crash

監査サーバがメモリ不足になった場合,システムをクラッシュさせます。

Ignore_New

メモリが使用できるようになるまで,新しいイベント・メッセージを無視します。新しいイベント・メッセージは失われますが,メモリ内のイベント・メッセージは保存されます。

Purge_Old (デフォルト)

最新メッセージのために,メモリが使用できるようになるまで,古いイベント・メッセージを削除します。

監査サーバのデフォルトの動作を変更し,古いメッセージをパージするのではなく,新しい監査メッセージをすべて無視するよう監査サーバに指示するには,次のコマンドを入力します。

$ SET AUDIT/SERVER=FINAL_ACTION=IGNORE_NEW

監査サーバは,仮想メモリの上限 (PGFLQUOTA) が 20,480 ページに制限された状態で動作します。これは,システムにインストールされているページ・ファイルのサイズによりさらに制限される場合があります。AUTOGEN を実行することで,ページ・ファイルのサイズを調整できます。AUTOGEN は,ページ・ファイルの問題を検出すると,必ず自動的にサイズをリセットして,問題を解消します。

9.6.6 メッセージの正確なタイムスタンプ設定の維持

発生順序が重要であるセキュリティ・イベントのセットを監査している場合,クラスタ内のすべての時計が同期している必要があります。これにより,クラスタにおける全ノードのメッセージのタイムスタンプが,イベントの発生順序を厳密に反映するようになります。

クラスタ構成内の各ノードは独立して時刻を維持するため,時間の経過とともにクラスタの時刻にずれが生じる可能性があります。時刻のずれを防止するには,定期的に SYSMAN コマンドの CONFIGURATION SET TIME を使用します。『OpenVMS システム管理ユーティリティ・リファレンス・マニュアル』に,時計の同期を 1 秒以内に保つために 1 時間ごとに実行可能なコマンド・プロシージャの例を示します。

9.6.7 ディスクへのメッセージ転送の調整

監査サーバはメモリ内にセキュリティ・イベント・メッセージを保存し,メッセージのグループを,バッファからディスク上の監査ログ・ファイルに定期的に転送します。通常,監査サーバは監査メッセージを 5 分ごとに転送し,アーカイブされたメッセージ ( 9.4.3.1 項 「遠隔ログ・ファイルの使用」を参照) を毎分 1 回転送します。高いセキュリティが必要とされる一部の環境と,システム上で大量の監査メッセージが生成される場合を除いて,このデフォルトで十分なはずです。

高いセキュリティが必要なサイトでは,ログ転送操作の間隔を変更することにより,通常よりも高い頻度でディスクにイベント・メッセージを転送できます。たとえば,次のコマンドを使用して,監査サーバが 2 分ごとに監査ログ・ファイルにイベント・メッセージを書き込むように,監査サーバの特性を変更します。

$ SET AUDIT/INTERVAL=JOURNAL_FLUSH=00:02

ただし,メッセージの転送が頻繁に行われれると,監査サーバ・プロセスに関連付けられているシステム・バッファへのメッセージの保存よりも,入出力操作の方が多くなるため,システム性能が影響を受けます。

直ちにすべての監査メッセージを強制的にログ・ファイルに書き込むには,次のコマンドを入力します。

$ SET AUDIT/SERVER=FLUSH

9.6.8 監査ログ・ファイル用のディスク領域の割り当て

監査サーバは,セキュリティ監査ログ・ファイルに割り当てられているディスク領域を常時監視して,イベント・メッセージ用に十分な領域があることを確認します。使用可能なブロックが不足してくると,監査サーバは監査ログ・ファイルを拡張します。ディスク資源の制約により,サーバがログ・ファイルに対して,これ以上ブロックを割り当てることができない場合,サーバは次のいずれかの措置を取ります。

  • オペレータ・ターミナルに警告メッセージを送信することによって警告を発します。これは,使用できるディスク・ブロックが 100 以下の場合にデフォルトで行われます。

    次のコマンドは,使用できるブロックが 150 個になった時点で警告が出るように,デフォルトを変更します。

    $ SET AUDIT /JOURNAL=SECURITY /THRESHOLD=WARNING=150
    
  • 監査レコードを生成しているプロセスを一時中断する措置を取ります。一部のプロセスはこの措置の対象外です ( 9.6.4.2 項 「プロセスの一時中断の防止」を参照)。ログ・ファイルに対する資源の監視が有効になっている場合,プロセスが一時中断されるのは,使用できるディスク・ブロックが 25 以下の場合です。

    アクションしきい値を 50 ブロックに変更するには,次のコマンドを入力します。

    $ SET AUDIT /JOURNAL=SECURITY /THRESHOLD=ACTION=50
    

しきい値は,ブロックまたはデルタ時間として表現します。デルタ時間に平均の領域消費速度をかけることで,ブロックの数が算出されます。ブロックと時間のしきい値の最大値が,アクティブなしきい値として使用されます。

9.6.9 監査機能におけるエラー処理

OpenVMS のセキュリティ監査機能により消費される資源は,記録されるシステム・イベントの数とタイプによって異なります。監査機能に関連して,次の 3 つの異なるエラー状態が発生し得ます。

  • 監査サーバのメモリ不足。 9.6.5 項 「メモリ不足への対応」に,この状況に対応するためのさまざまな方法を説明しています。

  • 監査ログ・ファイルを保存するディスクの領域不足。

  • 遠隔ログ・ファイル (アーカイブ・ファイル) 用のネットワーク接続の切断。

この節では,ディスク領域を監視し,アーカイブ・ファイルにログを記録する際の,監査システムのデフォルトの動作を説明します。

9.6.9.1 ディスク監視の無効化

監視サーバは監査ログ・ファイルを監視し,着信イベント・メッセージ用に十分な領域を確保するために,定期的にディスク・ブロック割り当てを事前に拡張します。ディスク領域が不足すると,サーバはまずオペレータ・メッセージによって警告を発してから,一部の生成側プロセスを一時中断する措置を取ります ( 9.6.8 項 「監査ログ・ファイル用のディスク領域の割り当て」を参照)。明確な理由なく多数のプロセスが中断されている場合は,おそらく監査ディスクがいっぱいであることが原因です。ディスク領域の問題を是正したら,SET AUDIT/SERVER=RESUME コマンドを使用して,(次回の資源のスキャンを待たずに) 中断されていたプロセスを再開できます。

次のコマンドを入力すると,資源の監視を完全に無効にすることができます。

$ SET AUDIT/JOURNAL=SECURITY/RESOURCE=DISABLE

ただし,ディスク資源の監視を無効にすると,手遅れになるまで,警告メッセージを受信する機会がなくなります。 9.6.4 項 「プロセス中断のきっかけとなる未処理メッセージの数の指定」で説明しているように,監査サーバは生成する監査が多すぎるプロセスの一時中断を開始します。また,メモリ不足になった場合は, 9.6.5 項 「メモリ不足への対応」で説明しているように,メッセージの無視,古いメッセージのパージ,また場合によってはシステムをクラッシュさせるという措置を取ります。

ディスク領域が再び使用可能になると,監査サーバはログ・ファイルを拡張し,中断されていたプロセスを再開します。

9.6.9.2 遠隔ログ・ファイルへのリンクの喪失

遠隔ログ・ファイルに監査メッセージを書き込む場合, 9.4.3.1 項 「遠隔ログ・ファイルの使用」で説明しているように,ローカル・ノードと遠隔ノードの間のリンクに障害が発生する場合があります。この障害が発生すると,監査サーバは全オペレータ・ターミナルに警告メッセージをブロードキャストし,接続されるまで 1 分ごとにリンクの再確立を試みます。



[3] VAX 固有

印刷用画面へ
プライバシー 本サイト利用時の合意事項
© 2009 Hewlett-Packard Development Company, L.P.