|
|
日本−日本語 | |
|
|
 |
|
HP OpenVMS: システム・セキュリティ・ガイド > パート III システム管理者のためのセキュリティ
第10章 セキュリティ監査の実施 |
|
|
目次 この章では，OpenVMS の監査システムを使用および管理する方法を説明します。 システムで発生するイベントを記録し，後でその監査ログを分析することにより，システムのセキュリティに関わる活動を監視する方法について説明します。 監査とは，システムで発生するセキュリティに関わる活動を記録し，後でこの監査ログを分析することを指します。 監査により，システム上でのユーザの活動を監視し，必要に応じて，システムのセキュリティを危険にさらす試みに至るまでの一連のイベントを再現できます。 したがって，システムとそのデータを保護する手法というよりも，むしろシステムの使用状況を分析および記録する手法です。 システムまたはシステム内の保護オブジェクトへのユーザ・アクセスに関係することはすべて，セキュリティに関わる活動と見なされます。 このような活動は，イベントと呼ばれます。 一般的なイベントには，次のものが含まれます。
オペレーティング・システムは，成功と失敗の両方のイベントを記録できます。 場合によっては，失敗の方が大きな意味を持つことがあります。 たとえば，プログラマがアクセス権を持っているファイルを表示したことを記録するよりも，同じプログラマが保護ファイルを表示しようとして阻止されたことを記録する方が重要です。 イベント・メッセージ自体は，監査ログ・ファイルと，セキュリティ・クラス・メッセージの受信が可能になっているオペレータ・ターミナルの，2 つの場所に書き込むことができます。 例 10-1 「アラーム・メッセージのサンプル」 に示すように，メッセージには次のデータが含まれています。
監査メッセージのそれ以外の情報は，そのイベントのタイプに固有の情報です。 メッセージのさまざまな例については， 付録 C 「アラーム・メッセージ」 を参照してください。 例 10-1 アラーム・メッセージのサンプル
デフォルトで決まっている報告内容 ( 表 10-1 「デフォルトで監査されるイベント・クラス」 を参照) 以外にセキュリティ管理者が受け取るセキュリティ・イベント情報の種類は，発生しうるイベントの長いリストからセキュリティ管理者が選択した情報の種類によって決まります。 この節では，セキュリティ・イベント情報の報告を有効にする方法を説明します。 具体的には，次のトピックについて説明します。
システムのインストールまたはアップグレード時には，OpenVMS オペレーティング・システムによって少数のイベントが自動的に監査されます。 表 10-1 「デフォルトで監査されるイベント・クラス」 に示すこれらのイベントのカテゴリは，システムのセキュリティの大幅な変更を意味します。 サイトの要件に応じて，他の形式の報告を有効にすることができます。 セキュリティに関わる活動に関してオペレーティング・システムに報告させる方法は 3 つあります。
セキュリティ関連イベントは，イベント・クラスと呼ばれるいくつかのカテゴリに分けられています。 オペレーティング・システムは，いくつかのイベント・クラスをデフォルトで監査します ( 表 10-1 「デフォルトで監査されるイベント・クラス」 を参照)。 サイトのセキュリティ要件により追加の監視が必要である場合は，DCL の SET AUDIT コマンドを使用して，追加のイベント・クラスに関するセキュリティ監査を有効にします。 各種イベント・クラスの監査を有効にするには，次のコマンド形式を使用します。 SET AUDIT /ENABLE=event-class[,...] {/ALARM | /AUDIT} イベントを有効にするには，コマンドには次の 2 つの修飾子が必要です。
新しいイベントを有効にすると，オペレーティング・システムは直ちにクラスタの全ノードで新しいイベントの監査を開始します。 監査は，/DISABLE 修飾子を使用して明示的にクラスを無効にするまで継続されます。 現在の監査設定は SYS$MANAGER:VMS$AUDIT_SERVER.DAT に記録されるため，システムのブートをまたいで設定が維持されます。 SET AUDIT コマンドの詳細については，『OpenVMS DCL ディクショナリ』を参照してください。 表 10-1 デフォルトで監査されるイベント・クラス
サイトで現在監査対象になっているイベント・クラスを表示するには，DCL の SHOW AUDIT コマンドを入力します。 例 10-3 「セキュリティ要件が中程度であるサイトの イベントの監査」 に，セキュリティ要件が中程度であるサイトの監査設定を示します。 イベント・クラスの有効化の例セキュリティに関わる活動の全クラスの監査を有効にすることは可能ですが (/ENABLE=ALL)，このような方法では大量の監査メッセージが発生し，あまりに多くの情報が生成されるため，有効な分析ができなくなります。 そのため， 10.3.1 項 「監査要件の評価」で説明しているように必要性を評価し，システムの活動を選択的に監査することをお勧めします。 イベント・クラスの監査は，さまざまなレベルの精度で行えます。 次のような方法があります。
例 10-2 オブジェクト・アクセス・イベントにより作成される監査
10.2.1.1 項 「活動の監査のカテゴリ」の説明にあるように，保護オブジェクトへのアクセスに関するイベントは頻繁に発生するため，その監査については慎重に検討する必要があります。 イベント・メッセージが多すぎると，その量に圧倒され，実際に調査を必要とする異常イベントが見失われる可能性があります。 保護オブジェクトより細かく監査する方法としては，オブジェクトのアクセス制御リスト (ACL) に監査 ACE を追加し，ACL イベント・クラスを有効にするという方法があります。 このアプローチでは，クラスに属する全オブジェクトではなく，セキュリティ監査 ACE を持つオブジェクトへのアクセスのみがイベント・メッセージを生成します。 イベントの報告先に応じて，2 種類の監査 ACE を使用できます。 アラーム ACE は，イベント・メッセージをオペレータ・ターミナルに出力し，監査 ACE は，イベント・メッセージを監査ログ・ファイルに出力します。 表 10-2 「セキュリティ監査用のアクセス制御エントリ (ACE)」 に，監査 ACE の概要を示します。 また『OpenVMS システム管理ユーティリティ・リファレンス・マニュアル』では，監査 ACE の詳細を説明しています。 監査 ACE の対象になっているシステム・ファイルの一覧については， 表 11-1 「ACL ベースの監査が有効なシステム・ファイル」 を参照してください。 表 10-2 セキュリティ監査用のアクセス制御エントリ (ACE)
保護したいオブジェクトに 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 を設定するには，次のコマンドを入力します。
ACL イベント・クラスはデフォルトで有効になっていますが，サイトで無効になっている場合は，次のコマンドを入力して，監査 ACE の使用を再度有効にする必要があります。
時として，不審な行動をするユーザが見つかることがあります。 たとえば，複数のターミナルからログインしていたり，例外的な時間帯や曜日にログインしていたりします。 ユーザの行動を監視するには，ユーザ登録レコードの監査属性を変更します。 AUTHORIZE ユーティリティを実行し，Audit フラグを設定します。 AUDIT フラグを設定すると，極めて多数の監査メッセージが生成されることに注意してください。 次のコマンド・シーケンスは，ユーザ Robin のアカウントを変更します。
Audit フラグが設定してあると，オペレーティング・システムはそのユーザのプロセスを監査します。 監査ログ・ファイルには，オペレーティング・システムによる監査が可能な，ユーザの任意の行動が含まれます ( 10.2.2 項 「オペレーティング・システムが報告できるシステム活動の種類」を参照)。 監査分析ユーティリティを使用して，ユーザの行動を確認できます。 たとえば，ユーザ Robin の行動に関する報告を入手するには，次のコマンドを入力します。
監査分析ユーティリティの詳細な説明については， 10.5 項 「ログ・ファイルの分析」を参照してください。 DCL の SET AUDIT コマンドを使用すれば， 表 10-3 「システムが報告できるセキュリティ・イベントの種類」 に示すイベント・クラスの 1 つまたは複数に対する監査を有効にできます。 多くのイベント・クラスには，イベント・クラスのサブセットの定義を可能にするキーワードがあります[3]。 表 10-3 システムが報告できるセキュリティ・イベントの種類
サイトで特権イベント・クラスを有効にしても，オペレーティング・システムは当該クラスのあらゆるイベントを報告するわけではありません。 オペレーティング・システムは次のタイプの監査を抑制します。
サイトでプロセス・イベント・クラスを有効にしても，オペレーティング・システムは当該クラスのあらゆるイベントを報告するわけではありません。 オペレーティング・システムは次のタイプの監査を抑制します。
アプリケーションとシステム・プログラムは，次のシステム・サービスを呼び出すことにより，セキュリティ・イベント情報を提供できます。
イベント監査 ($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 同じ方法でオブジェクト・アクセス監査を実行します。 システム管理者またはサイトのセキュリティ管理者が監査対象にするセキュリティ・イベントを把握するには，サイトで必要なセキュリティのレベルを決める必要があります。 監査要件の評価は，次の 2 つのステップからなるプロセスです。
サイトの要件の全般的な方向性を決めたら，セキュリティ報告の現実的な量を検討する必要があります。 表 10-4 「サイトのセキュリティ要件に応じて監視すべきイベント」 の推奨事項と，次に示すサイトの要素とのバランスを考慮します。
表 10-4 サイトのセキュリティ要件に応じて監視すべきイベント
表 10-4 「サイトのセキュリティ要件に応じて監視すべきイベント」 において，セキュリティ要件が低いサイトに推奨されているイベント・クラスは，オペレーティング・システムのデフォルト設定になっています。 これらのクラスがシステムで現在のデフォルトになっていない場合は，次のコマンドを使用して有効にします。
セキュリティ要件が中程度であるサイトでは，システムを再定義するようなイベントを監査する必要があります。 システム・ファイル，システム時刻，またはシステム・パラメータに対する変更が監視対象です。 また，イメージのインストールと，特権の使用も監視します。 例 10-3 「セキュリティ要件が中程度であるサイトの イベントの監査」 に，セキュリティ要件が中程度であるサイトの監査設定を示します。 例 10-3 セキュリティ要件が中程度であるサイトの イベントの監査
中程度のレベルの監査の設定を有効にするには，デフォルトのイベントがすでに有効であるという前提で，次のコマンドのセットを入力します。
セキュリティ要件が高いサイトでは，ネットワークの活動を含むように監査の範囲を拡張します。 ネットワーク・データベースに対する変更，ネットワーク接続 (VAX のみ)，特権としての識別子の使用，および特権ファイル・アクセスを監視する必要があります。 SYSPRV，BYPASS，または READALL 特権を介したすべてのファイル・アクセスを監視し，また GRPPRV 特権を介したファイル・アクセスの成功と失敗の両方を監視します。 高レベルの監査の設定を有効にするには，中レベルがすでに有効であるという前提で，次のコマンドのセットを入力します。
有効にすべき他の推奨イベント・クラスについては， 11.3.2 項 「セキュリティ監査の実施」を参照してください。 オペレーティング・システムは，セキュリティ・イベントを，アラームと監査のどちらの形式でも報告できます ( 10.2.1.1 項 「活動の監査のカテゴリ」を参照)。 どちらの形式を選択するかは，イベントの性質によります。 侵入行為や，システム・ユーザ登録ファイル (SYSUAF.DAT) への変更など，リアルタイムのイベントや直ちに対処しなければならないイベントは，アラームと監査の両方として有効にすべきクラスです。 これらよりも重要性の低いイベントについては，監査のみ有効にするということができます。 ハードコピー・オペレータ・ターミナルを使用する場合を除き，アラーム・レコードはすぐに他のシステム・メッセージに置き換わってしまいます。 システム・セキュリティ監査ログに書き込まれる監査イベント・レコードは，まとめて調査できるように保存されます。 イベント・メッセージの調査には，メリットがあります。 多くの場合，単独の監査メッセージから得られる情報はわずかですが，大量の監査レコードがあれば，セキュリティ違反を示す可能性のある活動パターンが明らかになります。 たとえば，オブジェクトのアクセスを監査することで，セキュリティ管理者は時刻のパターン，アクセスされているオブジェクトのタイプ，およびその他のシステム情報を把握し，これらを総合することで，システム活動の全体像を描くことができます。 10.5 項 「ログ・ファイルの分析」では，監査ログ・ファイルからレポートを作成する方法を説明します。 オペレーティング・システムにより実行されるデフォルトの監査は，主に登録データベースへの変更を追跡します。 システム・ユーザ登録ファイル (SYSUAF.DAT) に対する変更やイメージのインストールなどのシステム・イベントは，それほど頻繁には発生しないため，システムの資源を大量に消費することはありません。 システムの使われ方を把握せずに，また監査情報の価値を評価することなく，サイトで追加イベント・クラスを有効にして，特にアクセス・イベントや特権イベントなどの追加のイベント・クラスを監査すると，大量のシステム資源が消費される可能性があります。 この点では，監査報告システムの実装は，システムのチューニングに似ています。 つまり，不要な詳細データが含まれていない，適切な報告のレベルを実現するには，少し時間がかかります。 このため，一度にすべてではなく，段階的に監査を有効にして，適切なバランスに到達するまで徐々にイベント・クラスの追加/削除を行うことをお勧めします。 次のガイドラインに従います。
特に次の 2 つのコマンドは，大量の監査メッセージを生成します。
オペレーティング・システムは，監査ログ・ファイルおよびオペレータ・ターミナルにイベント・メッセージを送信できます。 サイトで追加のコピーが必要な場合，オペレーティング・システムはリモートのログ・ファイルやアプリケーション・リスナ・メールボックスにメッセージのコピーを送信できます。 オペレーティング・システムは，最新バージョンのセキュリティ監査ログ・ファイルに，すべてのセキュリティ・イベント・メッセージを書き込みます。 このログ・ファイルは，デフォルトではシステム・スタートアップ時に SYS$COMMON:[SYSMGR] ディレクトリに作成され，SECURITY.AUDIT$JOURNAL という名前が付けられています。 表 10-5 「監査ログ・ファイルの特徴」 に，このファイルの最も顕著な特徴を示します。 表 10-5 監査ログ・ファイルの特徴
通常，すべてのクラスタ・イベントが単独の監査ログ・ファイルに書き込まれます。 クラスタで 1 つのセキュリティ監査ログ・ファイルを使用することで，システム上の全セキュリティ関連イベントの記録が一本化されます。 このため，ノード固有の複数の監査ログよりも，1 つのクラスタ・ワイド・ログ・ファイルの方が優れています。 ノード固有の監査ログでは，クラスタ全体のイベントの相互関係が失われ，セキュリティ・イベントの分析が不完全になってしまうためです。 必要であればノード固有の監査ログを作成できますが ( 10.4.1.1 項 「ファイルの保守」を参照)，お勧めしません。 セキュリティ監査ログ・ファイルの有用性は，どのような手順を採用するかによって決まります。
セキュリティ監査ログ・ファイルは，何らかの対応を取るまで増大し続けるため，このファイルの保守計画を考えておく必要があります。 一般的には，サイトがログ・ファイルの名前を毎日変更し，新しいログ・ファイルを作成します。 新しい，クラスタ・ワイドのセキュリティ監査ログ・ファイルを開くには，次のコマンドを使用します。
ノード固有の新しいログを作成するには，SET AUDIT/SERVER=NEW_LOG コマンドの前に SET AUDIT/DESTINATION=filespec コマンドを実行します。 filespec は，ノード固有のファイルに解決される論理名 (SYS$SPECIFIC:[SYSMGR]SECURITY など) が含まれるファイル指定です。 新しいログを開いたら，古いバージョンの名前を，データの開始日または終了日を含む名前に変更します。 システム・ディスクの領域を節約するために，ファイルを別のディスクにコピーして，システム・ディスクからそのログを削除できます。 セキュリティ要件が高い環境では一般的な，専用の監査ディスクが装備されているサイトであっても，今後のメッセージ用に領域を空けるため，古いバージョンを移動させる場合があります。 ファイルをアーカイブしたら，古いログを対象に監査分析ユーティリティを実行します ( 10.5.2 項 「監査分析ユーティリティの起動」を参照)。 このファイルをアーカイブすることにより，監査メッセージについてクラスタ・ワイドの履歴を維持管理します。 万一システム上にセキュリティ上の危険が見つかった場合は，アーカイブされたログ・ファイルを分析して，指定した期間におけるユーザの疑わしい処理の形跡を調べることができます。 SYS$COMMON:[SYSMGR] ディレクトリからファイルを移動するには，コマンド・プロシージャ SYSECURITY.COM を編集します。 このプロシージャは，システムのリブートのたびに監査サーバが起動する前に実行されます。
オペレーティング・システムは，セキュリティ・クラス・メッセージが有効になっているターミナルに対して，アラーム・メッセージを送信します。 ほとんどの場合，これらのセキュリティ・アラームはデフォルトでシステム・コンソールに表示されます。 メッセージはすぐにスクロールして画面から消えてしまうため，セキュリティ・クラス・メッセージ用に独立したターミナルを有効にして，システム・コンソールへのメッセージ配信を無効にすることをお勧めします。 安全な場所でハードコピー出力を行うターミナルを用意するか，専任スタッフにセキュリティ・オペレータ・ターミナルを監視させます。 セキュリティ・オペレータとして有効にできるターミナルの数に制限はありません。 セキュリティ・クラス・アラームを受信するようターミナルを設定するには，使用するターミナルから次の DCL コマンドを入力します。
特定のターミナルを長期間使用する場合は，サイト固有のスタートアップ・コマンド・プロシージャを変更して，そのターミナルを自動的に有効にすることができます。 たとえば，スタートアップ・コマンド・プロシージャに次のコマンド行を含めると，システム・コンソールへのセキュリティ・アラームの配信が無効になり，ターミナル TTA3 でアラームが有効になります。
登録イベント・クラスと SYSGEN イベント・クラスは，非常に長いアラーム・メッセージを生成することがあるため，メッセージが切り詰められることがあります。 このため，これらのクラスではアラームと監査の両方を有効にすることをお勧めします。 アラーム・メッセージが切り詰められると，そのテキストはアラーム・メッセージが不完全であることを示します。 対象クラスの監査メッセージ出力を有効にしている限り，ANALYZE/AUDIT を使用して完全なメッセージを表示することができます。 オペレータ・ターミナルと監査ログ・ファイルは，セキュリティ・イベント・メッセージの第 1 の出力先です。 サイトでは，(アーカイブ・ファイルと呼ばれる) リモート・ログ・ファイルまたはリスナ・メールボックスに，監査メッセージのコピーを送信することを選択できます。 このオペレーティング・システムでは，管理能力が限定されているワークステーションやユーザが，別のノードに監査ログ・ファイルを複製することができます。 セキュリティ・アーカイブ・ファイルと呼ばれるこの第 2 ログは，リモート・ノードに置かれ，それを分析する能力を持つセキュリティ管理者が利用できるようになります。 場合によっては，アーカイブ・ファイルが，ローカルの監査ログ・ファイルが何らかの方法で改ざんされた場合の保険にもなります。 ノード単位で監査メッセージをアーカイブ・ファイルに出力できます。 有効にすると，監査サーバは各監査メッセージのコピーを，セキュリティ監査ログ・ファイルだけでなくセキュリティ・アーカイブ・ファイルにも書き込みます。
セキュリティ監査メッセージをリモート・セキュリティ・アーカイブ・ファイルに書き込むには，次の手順を実行します。
新しいアーカイブ・ファイルを作成するには，現在のファイルの名前を変更します。 システムの次回起動時に，システムによって新しいファイルが作成されます。 ネットワークが停止すると，セキュリティ・アーカイブ・ファイル用のメッセージは失われます。 セキュリティ・オペレータ・ターミナルは，接続が失われたという通知と，失われたメッセージの数を受信します。 ネットワークが回復すれば，監査サーバは元のアーカイブ・ファイルへの接続を再度確立し，イベント・メッセージの書き込みを継続します。 セキュリティ・アーカイブ・ファイルの分析は，多くの点でセキュリティ監査ログ・ファイルの分析と同じです。 ファイルが開いている状態でも，リモート・セキュリティ・アーカイブ・ファイルはいつでも分析できます。 詳細については 10.5 項 「ログ・ファイルの分析」を参照してください。 セキュリティ監査機能の追加機能として，リスナ・デバイスを作成してセキュリティ監査メッセージのバイナリ・コピーを受信するようにできます。 リスナ・デバイスとは，メールボックス作成 [$CREMBX] システム・サービスを使用して作成する，パーマネント・メールボックスまたは一時的メールボックスです。 アプリケーションを設定して監査情報を受信および処理し，システム上でイベントが発生した時点でイベントに対応するようにできます。 システムごとに 1 つのリスナ・デバイスを持つことができ，そのリスナ・デバイスはローカル・ノード上で発生するイベントのみを受け取れます。 リスナ・デバイスを有効にしてセキュリティ監査メッセージを受信するには，次の形式で SET AUDIT/LISTENER コマンドを実行します。 SET AUDIT/LISTENER=device-name device-name パラメータとして，メールボックスの作成時に指定した論理名を使用するか，"MBAn" の形式でメールボックスの等価名を使用します (n はメールボックスのユニット番号を表します)。 デバイスを一時的メールボックスとして作成する場合は，メールボックス・デバイス名を返すには，デバイスおよびボリューム情報取得 ($GETDVI) システム・サービスを使用する必要があります。 監査リスナ・デバイスを無効にするには，次のコマンドを入力します。
VAX システムの場合，DECtalk デバイス上のリスナ・メールボックスに送信される監査イベント・メッセージを処理するプログラムの例については，SYS$EXAMPLES ディレクトリにある，AUDSRV_LISTENER.B32 ファイル (VAX BLISS プログラム) および AUDSRV_LISTENER.MAR ファイル (VAX MACRO プログラム) を参照してください。 セキュリティ監査ログ・ファイルでセキュリティ監査メッセージを収集しても，そのファイルを確認して疑わしい活動を調べなければ意味がありません。 監査分析ユーティリティ (ANALYZE/AUDIT) を使用して，セキュリティ監査ログ・ファイルのデータを調べます。 システム上の通常の活動を把握し，例外的な活動を簡単に見つけられるように，ANALYZE/AUDIT はログ・ファイルからレポートを作成します。 ANALYZE/AUDIT はイベントを要約し，クラスタ上で活動が行われている場所を示します。 このユーティリティは，監査レポートから情報のサブセットを選択し，分析用により詳細な情報を提供できるため，例外的な処理の分析にも役立ちます。 1 つの監査ログ・ファイルを分析してもあまり意味がない可能性はありますが，監査レコードが長期に渡れば，セキュリティ違反を示す活動パターンを明らかになることがあります。 この節では，システムの監査ログ・ファイルを分析する方法を説明します。 ANALYZE/AUDIT の使用方法はサイトのセキュリティ要件に依存しますが，ユーティリティの使用範囲に関係なく，従うべき共通の手順がいくつか存在します。 潜在的なセキュリティ問題を認識できるようになる前には，システムの通常の運用を把握する必要があります。 定期的に監査レポートを作成および確認する手順を策定できるのは，その後です。 監査ログ・ファイルの定期的な分析の中でセキュリティ問題の疑いが見つかった場合は，選択したセキュリティ・イベントの詳細な調査を実行する必要があります。 手順 1 : 通常の状態の把握セキュリティ管理者は，監査ログ・ファイルを分析するためには，次の質問に答えられる必要があります。
以上の質問に対する答えを知っておけば，セキュリティ問題を誤って疑う原因となるアラームの誤報をなくすことができます。 手順 2 : 監査レポートの定期的な分析最も一般的に作成するレポートのタイプは，簡潔な毎日のイベントのリストです。 コマンド・プロシージャを作成し，毎晩，夜半前にバッチ・ジョブとして実行して，その日のセキュリティ・イベント・メッセージのレポートを生成するようにできます。 同じプロシージャで，監査ログの新しいバージョンを作成するようにもできます ( 10.4.1.1 項 「ファイルの保守」を参照)。 次の例は，このレポートを生成するための ANALYZE/AUDIT コマンド行を示します。
システム上で監査しているセキュリティ・イベントの数によっては，監査ログ・ファイルに書き込まれるすべての監査レコードを確認する作業は現実的ではない場合があります。 このような場合，登録データベースの変更や侵入行為に関連するすべての監査レコードや，通常の業務時間外に発生したすべてのイベントなど，ログ・ファイルから特定のセットのレコードを選択することができます。 (DCL の PIPE コマンドにより作成される) PIPE サブプロセスが監査を生成できることを念頭において，サブプロセス関連の監査を分析します。 PIPE コマンドは，1 つの PIPE コマンドを実行するために多数のサブプロセスを作成することがあります。 このことは，サブプロセスの活動 (プロセスの作成，プロセスの削除，ログイン，ログイン失敗，ログアウトなど) に関連する監査イベントが増大する可能性があることを意味します。 監査レポートの確認は，できる限りすみやかに行うことが重要です。 レポートの検査が早いほど，システムに対するセキュリティ侵害の可能性の検出と，問題の程度の判断が早くできるようになります。 前日の監査レポートの検査を朝の定期的な作業の一部にしたり，レポートを確認し，疑わしいイベントが発生した場合に Mail ユーティリティ (MAIL) を使用して通知するプログラムを作成することもできます。 手順 3 : 疑わしい活動の調査レポートの確認時に，通常の業務時間外のログインの試みなど，疑わしい，または不適切と思われるセキュリティ・イベントが見つかった場合は，監査分析ユーティリティを使用して，セキュリティ監査ログ・ファイルを詳細に調べます。 完全なレポートを見ることで，監査ログ・ファイルに記録されているどのセキュリティ・イベントをより徹底的な調査するべきかを判断できます。 次のコマンドを使用して，選択したセキュリティ監査レコードの完全なレポートを生成できます。
2000 年 12 月 31 日の監査レポートには，すべての侵入行為と，システム・ユーザ登録ファイル (SYSUAF.DAT) およびライト・データベース (RIGHTSLIST.DAT) へのすべての変更に関する情報が含まれています。 監査分析ユーティリティは，バイナリ・ログ・ファイルから，意味のあるレポートを作成するために使用するツールです。 この節と以降の節では，このユーティリティの使用方法を説明しますが，ユーティリティのコマンドと修飾子の完全な説明については，『OpenVMS システム管理ユーティリティ・リファレンス・マニュアル』を参照してください。 監査分析ユーティリティを起動するには，次の DCL コマンドを使用します。 ANALYZE/AUDIT file-name file-name パラメータの部分には，監査レポートの元となるファイルの名前を使用します。 セキュリティ監査ログ・ファイルのデフォルトの名前は，SECURITY.AUDIT$JOURNAL です。 ディレクトリ SYS$MANAGER を指定する必要があります。 監査分析ユーティリティを使用して，1 つの監査ログからセキュリティ・イベント・メッセージの一部または全部を抽出し，さまざまなレベルの詳細を含んだレポートを作成できます。 監査レポートには，サイトで有効になっているイベント・クラスのセットに含まれているイベントが反映されます ( 10.2 項 「セキュリティ関連イベントの報告」を参照)。 イベントの一部のみが抽出されるように，レポートを調整することができます。 時間，イベント・クラス，またはイベント・メッセージ内のデータのフィールドに基づいて選択基準を設定できます。 『OpenVMS システム管理ユーティリティ・リファレンス・マニュアル』の /SELECT 修飾子の解説を参照してください。 レポートの内容を決定する修飾子の要約を， 表 10-6 「監査分析ユーティリティの修飾子」 に示します。 表 10-6 監査分析ユーティリティの修飾子
ANALYZE/AUDIT は，さまざまな形式で監査レポートを作成します ( 表 10-6 「監査分析ユーティリティの修飾子」 を参照)。 デフォルトでは，このユーティリティはログ・ファイルのレコードごとに 1 行の要約を作成します。 簡潔な 1 行のレポートは，ログ・ファイルの定期的な分析には最も便利です。 より詳細な完全レポートは，疑わしいレコードの分析に必要な詳細情報を提供します。 ログ・ファイルの一部をアーカイブしたい場合は，バイナリ出力により監査ログ・ファイルのサブセットを保存することができます。 要約レポートによって，セキュリティ問題の可能性を素早く特定することができます。 要約レポートは，セキュリティ・イベントのクラスごとに，分析対象のセキュリティ監査ログ・ファイルから抽出された監査メッセージの合計数を列挙することができます。 また要約レポートは，イベント・メッセージを生成したシステム，イベントの発生時刻，および確認されたイベントの合計数に基づいて，監査活動の一覧表を表示することもできます。 例 10-4 「簡略監査レポート」 に，システム・セキュリティ監査ログ・ファイルに記録された，全セキュリティ監査イベントの簡略レポートを示します。 レポートを生成する ANALYZE/AUDIT コマンドでは，使用する監査ログ・ファイルの名前に置き換えます。 例 10-4 簡略監査レポート
例 10-5 「完全な監査レポートの 1 つのレコード」 に，完全な形式の監査レポートから 1 行のレコードを抜き出して示します。 レポートを生成する ANALYZE/AUDIT コマンドでは，使用する監査ログ・ファイルの名前に置き換えます。 例 10-5 完全な監査レポートの 1 つのレコード
例 10-6 「監査ログ・ファイルのイベントの要約」 に，要約レポートを示します。 レポートを作成する ANALYZE/AUDIT コマンドでは，使用する監査ログ・ファイルの名前に置き換えます。 例 10-6 監査ログ・ファイルのイベントの要約
ターミナルに出力を送信する場合は，監査ログ・ファイルを会話形式で分析できます。 リスト表示中の任意の時点で Ctrl/C を押すことにより，表示されているレポートを中断できます。 これにより，自動的に完全なリスト表示が開始され，Command> プロンプトが表示されます。 コマンド・モードでは，レポート内で先に進んだり前のレコードに戻って，レコードを詳細に調べることができます。 Command> プロンプトでは，『OpenVMS システム管理ユーティリティ・リファレンス・マニュアル』の任意の ANALYZE/AUDIT コマンドを入力して，分析基準の変更，監査レポート内での位置の変更，または完全な表示と簡略表示の切り替えを行うことができます。 監査レポートの表示に戻るには，CONTINUE コマンドを入力します。 監査ログ・ファイルの定期的な分析で，(実際の侵入，侵入の試み，ログイン失敗の繰り返しなどの疑わしいセキュリティ・イベントにより) システムのセキュリティが危険にさらされている疑いが見つかった場合には，セキュリティ監査ログ・ファイルをより詳しく調査することによって，セキュリティ・イベントの発生源を調査できます。 たとえば，前日の監査レポートの定期的な調査中に， 例 10-7 「監査レポートにある疑わしい活動の 特定」 に示すセキュリティ・イベントが確認されたとします。 例 10-7 監査レポートにある疑わしい活動の 特定
例 10-7 「監査レポートにある疑わしい活動の 特定」 のレポートに表示されているセキュリティ・イベントは，ユーザ Kovacs が，ログインに 4 回失敗した後でシステムにログインしたことを示しています。 ユーザ Kovacs はログインしてすぐに，システム・ユーザ登録ファイル (SYSUAF.DAT) に新しいアカウントを作成しています。 この時点で，この行動が正常か異常かを判断する必要があります。 そのためには，システムに新しいユーザ・アカウントを追加する権限がユーザ Kovacs にあるかどうかを考慮します。 システムのセキュリティが危険にさらされていると考えられる場合は，次のコマンドを使用してセキュリティ監査ログ・ファイルからより詳細なレポートを生成し，システムが損害を受けているかどうかを判断します。
この例のコマンドは，ユーザ Kovacs が最初にシステムへのログインを試みた時点から監査ログ・ファイルに書き込まれたすべてのセキュリティ監査イベントの完全なレポートを生成します。 完全な形式のレポートでは，監査ログ・ファイルにある各レコードの全データが表示されます。 完全なレポートを使用することで， 例 10-8 「疑わしいレコードの調査」 に示すように，ローカルの KOVACS のアカウントにログインしたリモート・ユーザの名前と，ログイン元のノードを判定することができます。 例 10-8 疑わしいレコードの調査
例 10-8 「疑わしいレコードの調査」 に表示されている情報は，ログインの失敗とその後のログイン成功が，リモート・ノード NACHWA からユーザ Follen により行われたことを示しています。 次のステップは，セキュリティ・イベントがユーザ Follen に起因するものか，FOLLEN のアカウントを利用してリモート・ノード NACHWA に侵入した誰かに起因するものかを判断します。 この節では，監査システムの管理方法を説明します。 管理タスクには，次の作業が含まれます。
オペレーティング・システムは，システム・スタートアップ時に独立プロセスとして監査サーバを作成し，次のタスクを実行します。
監査サーバは，オペレータ通信マネージャ (OPCOM) に情報メッセージとエラー・メッセージを送信します。 OPCOM はこれらのメッセージをオペレータ・ターミナルにブロードキャストし，メッセージをオペレータ・ログ・ファイルに書き込みます。 例 10-9 「監査サーバのデフォルトの特性」 に，監査サーバの初期の動作値を示します。 これらの設定は，監査サーバ・データベースである，SYS$COMMON:[SYSMGR] の VMS$AUDIT_SERVER.DAT に保存されます。 DCL の SET AUDIT コマンドを使用してセキュリティ監査の特性を変更するたびに，監査サーバ・データベースが更新されます。 また，システムのリブートのたびに，システムはこのデータベースから監査の値を取得します。 例 10-9 監査サーバのデフォルトの特性
オペレーティング・システムはすべてデフォルトで監査サーバ・プロセスと OPCOM を起動します。 システムの物理メモリまたはディスク・ストレージ領域が特に限定されていて，かつセキュリティ関連イベントのログ記録が重要でない場合は，システム・スタートアップ・プロシージャから監査サーバと OPCOM のプロセスを削除できます。 ただし，削除の前に，クラスタ・オブジェクトのサポートには監査サーバが必要である点に注意してください ( 第12章 「クラスタのセキュリティ保護」を参照)。 次の例に，システム管理ユーティリティ (SYSMAN) を使用して，これらのプロセスを削除する方法を示します。
監査サーバ・プロセスを削除し，システム上のセキュリティ監査をシャット・ダウンするには，クラスタの各ノードで次のコマンドを入力します。
システム上のセキュリティ監査と OPCOM を再起動するには，次の DCL コマンド行を入力します。
以降のすべてのシステムのブート時に OPCOM と監査サーバ・プロセスを起動するには，システム・スタートアップ・プロシージャに加えた編集をすべて元に戻します。 次の SYSMAN コマンドを使用します。
SYSMAN の詳細については，『OpenVMS システム管理ユーティリティ・リファレンス・マニュアル』を参照してください。 通常，オペレーティング・システムは SYSTARTUP_VMS.COM の実行の直前に，監査イベント・メッセージの送信を開始します。 しかし，スタートアップ時に監査イベント・メッセージの受信を必要としていないサイトでは，論理名 SYS$AUDIT_SERVER_INHIBIT を再定義することにより，この動作を変更できます。 オペレーティング・システムによるセキュリティ・イベント・メッセージの配信開始ポイントを変更するには，SYS$MANAGER:SYLOGICALS.COM コマンド・プロシージャに，次の行を追加します。
システム管理者は，SYSTARTUP_VMS 終了時点など，システム・スタートアップの別の段階を選択して監査を開始することができます。 ただし，システムへの一般のログインを許可する前 (つまり，すべての SET LOGINS/INTERACTIVE コマンドの前) には，必ず監査を開始してください。 監査メッセージの配信を開始するには，適切なコマンド・ファイルに次の行を追加します。
監査サーバがメッセージの流入を制御している場合を除き，ある条件下では，メモリ不足になる可能性があります。 非常に遅い入出力デバイス，ディスク領域の問題，または突然のメッセージの大量発生により，メッセージをディスクに書き込むサーバの能力が対応できなくなることがあります。 メモリの枯渇を防ぐために，監査サーバは未処理メッセージの総数を常時監視し，アクティブな各プロセスにより生成されるメッセージの数を数えます。 サーバは，ディスクに記録可能な量を超えるイベントを受信した場合，監査イベントを生成しているプロセスに対して，フロー制御の適用を開始します。 メッセージの量は，プロセス単位で制御されます。 表 10-7 「監査イベント・メッセージのフロー制御」 に，フロー制御の 3 つの段階を示します。
SET AUDIT コマンドに /BACKLOG 修飾子を指定することで，メッセージを制御するためのサイト固有の値を設定することができます。 たとえば，次のコマンドを使用すると，キュー内に 125 個の未処理メッセージがあり，かつ生成側プロセスに 8 個の未処理メッセージが発生した時点で，オペレーティング・システムがメッセージ流入の制御を開始するように，アクションしきい値を引き上げます。
当然ながら，オペレーティング・システムはいくつかの重要なプロセスは一時中断しません。 リアルタイム・プロセスと，次のプロセスはすべて一時中断を免除されています。
プロセスを一時中断の対象から除外するには，プロセス識別子 (PID) をプロセス除外リストに追加します。 次の形式の SET AUDIT コマンドを使用します。 SET AUDIT/EXCLUDE=process-id プロセスがシステムからログアウトしても，プロセス (PID) はプロセス除外リストから自動的には削除されない点に注意してください。 除外リストからプロセスを削除するには，SET AUDIT/NOEXCLUDE コマンドを使用します。 オペレーティング・システムによって除外されているプロセスは削除できません。 除外リスト上のプロセス ( 10.6.4.2 項 「プロセスの一時中断の防止」を参照) があまりに多くの監査メッセージを生成するために監査サーバがメモリ不足になった場合，監査サーバはデフォルトの動作として，メモリが使用できるようになるまで古いイベント・メッセージを削除します。 これにより，最新のメッセージが保存されます。 監査サーバには，メモリ不足に陥った場合に使用できる次の代替策もあります。
監査サーバのデフォルトの動作を変更し，古いメッセージをパージするのではなく，新しい監査メッセージをすべて無視するよう監査サーバに指示するには，次のコマンドを入力します。
監査サーバは，仮想メモリの上限 (PGFLQUOTA) が 20,480 ページに制限された状態で動作します。 これは，システムにインストールされているページ・ファイルのサイズによりさらに制限される場合があります。 AUTOGEN を実行することで，ページ・ファイルのサイズを調整できます。 AUTOGEN は，ページ・ファイルの問題を検出すると，必ず自動的にサイズをリセットして，問題を解消します。 発生順序が重要であるセキュリティ・イベントのセットを監査している場合，クラスタ内のすべての時計が同期している必要があります。 これにより，クラスタにおける全ノードのメッセージのタイムスタンプが，イベントの発生順序を厳密に反映するようになります。 クラスタ構成内の各ノードは独立して時刻を維持するため，時間の経過とともにクラスタの時刻にずれが生じる可能性があります。 時刻のずれを防止するには，定期的に SYSMAN コマンドの CONFIGURATION SET TIME を使用します。 『OpenVMS システム管理ユーティリティ・リファレンス・マニュアル』に，時計の同期を 1 秒以内に保つために 1 時間ごとに実行可能なコマンド・プロシージャの例を示します。 監査サーバはメモリ内にセキュリティ・イベント・メッセージを保存し，メッセージのグループを，バッファからディスク上の監査ログ・ファイルに定期的に転送します。 通常，監査サーバは監査メッセージを 5 分ごとに転送し，アーカイブされたメッセージ ( 10.4.3.1 項 「リモート・ログ・ファイルの使用」を参照) を毎分 1 回転送します。 高いセキュリティが必要とされる一部の環境と，システム上で大量の監査メッセージが生成される場合を除いて，このデフォルトで十分なはずです。 高いセキュリティが必要なサイトでは，ログ転送操作の間隔を変更することにより，通常よりも高い頻度でディスクにイベント・メッセージを転送できます。 たとえば，次のコマンドを使用して，監査サーバが 2 分ごとに監査ログ・ファイルにイベント・メッセージを書き込むように，監査サーバの特性を変更します。
ただし，メッセージの転送が頻繁に行われれると，監査サーバ・プロセスに関連付けられているシステム・バッファへのメッセージの保存よりも，入出力操作の方が多くなるため，システム性能が影響を受けます。 直ちにすべての監査メッセージを強制的にログ・ファイルに書き込むには，次のコマンドを入力します。
監査サーバは，セキュリティ監査ログ・ファイルに割り当てられているディスク領域を常時監視して，イベント・メッセージ用に十分な領域があることを確認します。 使用可能なブロックが不足してくると，監査サーバは監査ログ・ファイルを拡張します。 ディスク資源の制約により，サーバがログ・ファイルに対して，これ以上ブロックを割り当てることができない場合，サーバは次のいずれかの措置を取ります。
しきい値は，ブロックまたはデルタ時間として表現します。 デルタ時間に平均の領域消費速度をかけることで，ブロックの数が算出されます。 ブロックと時間のしきい値の最大値が，アクティブなしきい値として使用されます。 OpenVMS のセキュリティ監査機能により消費される資源は，記録されるシステム・イベントの数とタイプによって異なります。 監査機能に関連して，次の 3 つの異なるエラー状態が発生し得ます。
この節では，ディスク領域を監視し，アーカイブ・ファイルにログを記録する際の，監査システムのデフォルトの動作を説明します。 監視サーバは監査ログ・ファイルを監視し，着信イベント・メッセージ用に十分な領域を確保するために，定期的にディスク・ブロック割り当てを事前に拡張します。 ディスク領域が不足すると，サーバはまずオペレータ・メッセージによって警告を発してから，一部の生成側プロセスを一時中断する措置を取ります ( 10.6.8 項 「監査ログ・ファイル用のディスク領域の割り当て」を参照)。 明確な理由なく多数のプロセスが中断されている場合は，おそらく監査ディスクがいっぱいであることが原因です。 ディスク領域の問題を是正したら，SET AUDIT/SERVER=RESUME コマンドを使用して，(次回の資源のスキャンを待たずに) 中断されていたプロセスを再開できます。 次のコマンドを入力すると，資源の監視を完全に無効にすることができます。
ただし，ディスク資源の監視を無効にすると，手遅れになるまで，警告メッセージを受信する機会がなくなります。 10.6.4 項 「プロセス中断のきっかけとなる未処理メッセージの数の指定」で説明しているように，監査サーバは生成する監査が多すぎるプロセスの一時中断を開始します。 また，メモリ不足になった場合は， 10.6.5 項 「メモリ不足への対応」で説明しているように，メッセージの無視，古いメッセージのパージ，また場合によってはシステムをクラッシュさせるという措置を取ります。 ディスク領域が再び使用可能になると，監査サーバはログ・ファイルを拡張し，中断されていたプロセスを再開します。 リモート・ログ・ファイルに監査メッセージを書き込む場合， 10.4.3.1 項 「リモート・ログ・ファイルの使用」で説明しているように，ローカル・ノードとリモート・ノードの間のリンクに障害が発生する場合があります。 この障害が発生すると，監査サーバは全オペレータ・ターミナルに警告メッセージをブロードキャストし，接続されるまで 1 分ごとにリンクの再確立を試みます。 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||
|
|||||||||||||||
