[ 前のページ ]
[ 次のページ ]
[ 目次 ]
[ 索引 ]
[ DOC Home ]
本章では,OpenVMSがシステム・リソースを保護し,監査する方法について説明します。 特に次のことについて説明します。
セキュリティについての補足説明は,以下の資料を参照してください。
たとえば,次の操作を通じてこれらの機能を理解することができます。
ライト識別子の表示についての説明は第19.1節を参照。
セキュリティ・プロファイルについての説明は第19.2節を参照。
リモート・ファイルへのアクセスについての説明は,第19.5節を参照。
アカウントとファイルへのアクセスの監査についての説明は第19.6節を参照。
保護されたオブジェクトにアクセスしようとするプロセスはすべて,ライト識別子と呼ぶ保護機能を実行します。 保護されたオブジェクトはすべて, 特定の方法でそのオブジェクトに誰がアクセスできるかを指定できるアクセス条件を指定しています。 アクセスするプロセスのライト識別子がオブジェクトのライト識別子と一致しない場合には, アクセスは拒否されます。
次の例では,SHOW PROCESSコマンドを使用して,現在のプロセスの識別子を表示する方法を示しています。
$ SHOW PROCESS/ALL 25-JUN-1998 15:23:18.08 User: GREG Process ID: 34200094 Node: ACCOUNTS Process name: "_TWA2:" Terminal: TWA2: User Identifier: [DOC,GREG] 【1】 Base priority: 4 Default file spec: WORK1:[GREG.FISCAL_96] Devices allocated: ACCOUNTS$TWA2: Process Quotas: . . . Process rights: INTERACTIVE 【2】 LOCAL 【3】 SALES 【4】 MINDCRIME resource 【5】 System rights: SYS$NODE_ACCOUNTS 【6】
ライト識別子には,UIC,環境,汎用の3種類があります。SHOW PROCESS コマンドからの出力はこの3種類の識別子をすべて示しています。
オペレーティング・システムは多くのユーザを同時にサポートするため, 1人のユーザの操作が別のユーザによって妨害されないように保護するためのセキュリティ・ メカニズムが組み込まれています。保護コード,アクセス制御, ハードウェア設計の組み合わせにより,多くのユーザがシステムを共用できるように, メモリ,共用可能装置,データの使用が保護されます。 オブジェクトのセキュリティ・プロファイルは利用者識別コード(UIC) ,ACL,そのオブジェクトに割り当てられた保護コードで構成されます。 自分で所有しているオブジェクトのセキュリティ・プロファイルは表示したり, 変更することができます。
保護されたオブジェクトのセキュリティ・プロファイルを表示するには, DCLのSHOW SECURITYコマンドを使用します。たとえば,次のコマンドは95_FORECAST.TXT ファイルに関するセキュリティ情報を要求しています。
$ SHOW SECURITY 95_FORECAST.TXT WORK_DISK$:[GREG]95_FORECAST.TXT;1 object of class FILE Owner: [ACCOUNTING,GREG] Protection: (System: RWED, Owner: RWED, Group: RE, World) Access Control List: <empty>
このコマンドからの表示を見ると,95_FORECAST.TXTファイルがGregというユーザによって所有されていることがわかります。 また,ファイルの保護コードも示されます。 保護コードはシステム・ユーザと所有者に対して読み込み, 書き込み,実行,削除アクセス権を与えています。また, グループ・ユーザに対して読み込みアクセス権と実行アクセス権を与え, ワールド・ユーザに対してはアクセス権を与えていません(詳細は第19.3節を参照してください)。 このファイルに対してACL は設定されていません。
保護されたオブジェクトの所有者,保護コード,ACLに対して新しい値を指定でき, また,SET SECURITYコマンドを使用して1つのオブジェクトから別のオブジェクトにプロファイルをコピーすることもできます。
たとえば,第19.2節に示したSHOW SECURITY の表示結果では, 95_FORECAST.TXTファイルがGregというユーザによって所有されていることがわかります。 このユーザは所有者として,ファイルの保護コードを変更できます。 もともと,この保護コードでは,ワールド・ユーザに対してアクセス権が与えられていませんでした。 ここでGregは保護コードを変更し, ワールド・ユーザに対して読み込みアクセス権と書き込みアクセス権を許可します。
$ SET SECURITY/PROTECTION=(W:RW) 95_FORECAST.TXT
SHOW SECURITYコマンドはファイルの新しい保護コードを確認します。
$ SHOW SECURITY 95_FORECAST.TXT 95_FORECAST.TXT object of class FILE Owner: [GREG] Protection: (System: RWED, Owner: RWED, Group: RE, World: RW) Access Control List: <empty>
保護コードは,特定のユーザまたはユーザ・グループに対して許可(または禁止) されるアクセス・タイプを制御します。保護コードの形式は次のとおりです。
[カテゴリ:許可されるアクセスのリスト(,カテゴリ:許可されるアクセスのリスト,...)]
カテゴリは,system (S),owner (O),group (G),world (W)のいずれかです。 各カテゴリは最初の1文字に短縮できる。各カテゴリの定義は次のとおりです。
System | UICが1〜10 (8進数)であるか,SYSPRV 特権を持つか,または所有者と同じグループに属し,GRPPRVを保有するユーザ・ プロセスまたはアプリケーション。 |
Owner | オブジェクトのUICと等しいUICを持つユーザ・ プロセスまたはアプリケーション。 |
Group | オブジェクトのグループUICと等しいグループUIC を持つユーザ・プロセスまたはアプリケーション。 |
World | システムの任意のユーザ・プロセスまたはアプリケーション。 |
複数のユーザ・カテゴリを指定するときは,各カテゴリをコンマで区切り, コード全体を括弧で囲みます。ユーザ・カテゴリとアクセス・タイプはどの順序で指定してもかまいません。
アクセス指定としてヌルを指定した場合には,アクセスを許可しないことを示します。 したがって,ユーザ・カテゴリに対してアクセス・タイプを省略すると, そのユーザ・カテゴリはそのタイプのアクセスを実行できません。 ユーザ・カテゴリに対してすべてのアクセスを禁止するには,ユーザ・ カテゴリだけを指定し,アクセス・タイプを省略します。ユーザ・カテゴリに対してアクセスを禁止するときは, ユーザ・カテゴリの後のコロンを省略します。
ファイルに対して,read (R),write (W),execute (E),delete (D)を指定する。 アクセス・タイプは各カテゴリに割り当てられます。カテゴリとアクセス・ タイプの間はコロン(:)で区切ります。ファイル・アクセス・ タイプの意味は次のとおりです。
Read | ディスク・ファイルの読み込み,印刷, コピーを許可する。ディレクトリ・ファイルに対して読み込みアクセス権がある場合には, ファイルを読み込むか,またはファイル・リストを表示でき, ワイルドカード文字を含むファイル名を使用してファイルを検索できる。 読み込みアクセス権があるときは,実行アクセス権も与えられる。 |
Write | ファイルに書き込むか, またはファイルの内容を変更することはできるが,ファイルを削除することはできない。 書き込みアクセス権がある場合には,ファイルの内容を記述するファイル属性を変更できる。 ディレクトリ・ファイルに対する書き込みアクセス権がある場合には, ファイル・カタログにエントリを作成したり, エントリを削除することができる。 |
Execute | 実行可能プログラム・イメージまたはDCL コマンド・プロシージャを格納したファイルを実行することができる。 ディレクトリ・ファイルに対して実行アクセス権が割り当てられている場合には, 名前がわかっているファイルを検索できる。 |
Delete | ファイルを削除することができる。 ファイルを削除するには,ファイルへの削除アクセス権と,そのファイルが格納されているディレクトリへの書き込みアクセス権が必要である。 |
新しいファイルには省略時のUICベースの保護が与えられ,その親ディレクトリの省略時のアクセス制御リスト(ACL) が与えられます。ACLは,ユーザまたはユーザ・ グループがファイルやディレクトリ,装置などの特定の保護されたオブジェクトに対して実行できるアクセス権を定義したエントリの集合です。
新しいファイルに割り当てられる省略時のUICベースの保護を変更するには, 次のいずれかの操作を実行します。
オペレーティング・システムは各プロセスに対して次のUICベースの保護を割り当てます。
(S:RWED, O:RWED, G:RE, W)
省略時の設定では,システムUICを持つユーザとオブジェクトの所有者は, そのオブジェクトに対して完全なアクセスを実行でき,オブジェクト所有者と同じUIC グループに属すユーザは,そのオブジェクトに対して読み込みアクセスと実行アクセスを実行でき, 他のすべてのユーザはオブジェクトにアクセスできません。 作成するファイルの省略時の保護を変更するには,SET PROTECTION コマンドと/DEFAULT修飾子を使用します。たとえば, ログイン・コマンド・プロシージャに次のコマンドを登録しておけば, すべてのプロセスに対して作成するファイルへの読み込みアクセス権と実行アクセス権を割り当てることができます( このコマンドを実行するには, ログイン・コマンド・プロシージャを実行しなければなりません) 。
$ SET PROTECTION = (S:RWED,O:RWED,G:RE,W:RE)/DEFAULT
適切なディレクトリ・ファイルのACLに省略時の保護ACEを指定すれば,指定したディレクトリまたはサブディレクトリに対する省略時のUIC 保護を変更できます。ACE に指定する省略時の保護は,指定したディレクトリまたはディレクトリのサブディレクトリに作成される新しいファイルにすべて適用されます。 後続のACE (ディレクトリ・ファイルのACL内に指定しなければならない) は,そのディレクトリおよびディレクトリのサブディレクトリの省略時の保護により, システムおよび所有者プロセスに対して完全なアクセス権を割り当て, グループ・プロセスに対して読み込みアクセス権と実行アクセス権を割り当て, ワールド・ユーザに対してアクセス権を割り当てないことを指定します。
$ SET SECURITY/ACL = (DEFAULT_PROTECTION,S:RWED,O:RWED,G:RE,W:) [JONES]PERSONAL.DIR
ディレクトリにこの後作成されるファイルのACLにコピーする省略時の識別子ACE を指定するには,ディレクトリ・ファイルの識別子ACLにDEFAULT オプションを指定します。
たとえば,次のACEはディレクトリ・ファイルに適用され,ネットワーク・ ユーザが,ディレクトリに作成されたすべてのファイルにアクセスすることを禁止します。
$ SET SECURITY/ACL = (IDENTIFIER=NETWORK,OPTIONS=DEFAULT,ACCESS=NONE) - _$ [JONES]PERSONAL.DIR
ファイル名を変更しても,そのファイルの保護は変更されません。既存のファイルの新しいバージョンには, 前のバージョンと同じACLおよびUICベースの保護が割り当てられます( 省略時のUICベースの保護を変更するには,BACKUP ,COPY,CREATE,SET FILEコマンドの/PROTECTION修飾子を使用します) 。
/PROTECTION修飾子を使用すれば(この修飾子はBACKUP,COPY,CREATEコマンドで使用可能) ,新しいファイルに対してUICベースの保護を明示的に指定できます。
既存のファイルに対するUICベースの保護を変更するときは,SET SECURITY/PROTECTIONコマンドを使用します。
ファイルを作成し,そのファイルのACLを作成した後,ACLを変更し,必要な数だけACL にエントリを追加できます。ACLによって指定される保護は, ファイルのユーザ識別コード保護より優先します。
次の例では,UICベースの保護を指定しています。
$ CREATE MAST12.TXT/PROTECTION=(S:RWED,O:RWED,G,W)
次の例では,ファイルMAST12.TXTでUICベースの保護を変更しています。
$ SET SECURITY/PROTECTION=(S:RWED,O:RWED,G:RE,W) MAST12.TXT
これ以降の節では,ネットワークを介してのファイルへのアクセスについて説明します。
DECnet for OpenVMSネットワークで使用できるDCLコマンドのファイル指定に, ネットワーク・アクセス制御文字列を取り込むことができます。アクセス制御文字列を使用すると, ローカル・ノードのユーザがリモート・ ノード上のファイルにアクセスすることができます。
アクセス制御文字列では,次に示すように,リモート・アカウントのユーザ名とそのパスワードが二重引用符で囲まれています。
NODE"ユーザ名パスワード"::ディスク:[ディレクトリ]ファイル・タイプ
アクセス制御文字列の情報を保護するには,次のようにします。
ハードコピー・ターミナルを使用する場合は,ハードコピー出力を正しく処置する。 ビデオ・ターミナルを使用する場合は,ネットワーク・ ジョブが完了したら画面を消去し,DCLのRECALL/ERASEコマンドによって再呼バッファを空にする。 こうしておけば,別のユーザがCtrl/B によってコマンド行を表示したり DCLのRECALL/ALLコマンドを使用してもパスワードを見ることはできない。
アクセス制御文字列を使用しなくてもすむように,代理ログイン・アカウントを使用するとよいでしょう。 代理ログインを使用すると,アクセス制御文字列にユーザ名やパスワードを指定しないでも, ネットワーク内でファイルをアクセスできます。 代理ログインには,次のようなセキュリティ上の利点があります。
ユーザが代理ログインを開始するには,リモート・ノードのシステムまたはセキュリティ管理者が代理アカウントを作成していなければなりません。 代理アカウントは,通常のアカウントと同様,OpenVMS Authorizeユーティリティ(AUTHORIZE) によって作成されます。通常,特権なしのアカウントです。 ユーザは,1つの省略時の代理アカウントと最大15個の省略時以外の代理アカウントにアクセスできます。 代理ログインを使用すると, システム管理者にとっては設定に手間がかかりますが,より安全なネットワーク・ アクセスができ,ユーザがアクセス制御文字列を入力する手間も省けます。
次の例は,通常のネットワーク・ログイン要求と代理ログイン要求の違いを示しています。 次の条件を想定しています。
次の図は,これらの条件を示しています。
$ COPY WALNUT"KMAHOGANY A25D3255"::BIONEWS.MEM BIONEWS.MEM
A25D3255というパスワードはエコー表示されるので,画面を見ればパスワードが分かります。
$ COPY WALNUT::BIONEWS.MEM BIONEWS.MEM
KMAHOGANYがアクセス制御文字列にパスワードを指定しなくても,システムがBIRCH ノードのアカウントからWALNUTノードのアカウントに代理ログインを行います。 このとき,パスワードの交換は行われません。
セキュリティ管理者が,フォーリン・ノードのユーザのグループに汎用アクセス代理アカウントを共用する権限を付与することもあります。 たとえば,WALNUT ノードのセキュリティ管理者が次の条件で汎用アクセス・アカウントを作成するとします。
セキュリティ管理者がGENACCESSアカウントへのBIRCH::KMAHOGANY代理アクセスを許可すれば,KMAHOGANY ユーザは,次のコマンドによってBIONEWS.MEM ファイルをコピーできます。
$ COPY WALNUT::[KMAHOGANY]BIONEWS.MEM BIONEWS.MEM
BIONEWS.MEMファイルはGENACCESSアカウントの省略時のデバイスとディレクトリ(STAFFDEV:[BIOSTAFF]) にないため,KMAHOGANYは[KMAHOGANY]ディレトクリを指定しなければなりません。 また, BIONEWS.MEMファイルの保護は,GENACCESSアカウントへのアクセスを許可するものでなければなりません。 そうでないと,コマンドは正しく実行されません。
特定のノード上の複数の代理アカウントにアクセスするときに,省略時の代理アカウントを使用したくない場合には, 代理アカウントの名前を指定します。 たとえば,GENACCESSアカウント(省略時の値)の代わりに PROXY2 という代理アカウントを使用するには,次のコマンドを入力します。
$ COPY WALNUT"PROXY2"::[KMAHOGANY]BIONEWS.MEM BIONEWS.MEM
このコマンドは,PROXY2アカウントを使用して, WALNUTノード上の[KMAHOGANY] ディレクトリにある BIONEWS.MEMファイルをコピーします。
侵入の試みがないかどうかシステムを監視するのはセキュリティ管理者の仕事ですが, ユーザがアカウントやファイルへのアクセスの監査を手伝うこともできます。
OpenVMSシステムは,ユーザが最後にアカウントにログインした時間についての情報をUAF レコードに保管します。ログイン時にこの情報を表示するかどうかは, セキュリティ管理者が決定します。中程度から高水準のセキュリティ要件を持つシステムでは, 頻繁にこの情報を表示して,異常な成功ログインや説明のつかない成功ログインがないかどうか, 説明のつかない障害ログインがないかどうかをユーザがチェックします。
ユーザがログインしなかったのに会話型または非会話型ログインの報告があれば, ただちにセキュリティ管理者に知らせるとともに,パスワードを変更します。 セキュリティ管理者は,システム・アカウント・ログと監査ログを使用して詳しく調査します。
ログイン障害メッセージを受け取ったが,障害が生じたとは考えられない場合には, 誰か他のユーザがアカウントにアクセスしようとして, 失敗したのかもしれません。パスワードをチェックして,第2.8節に説明するパスワード保護のガイドラインに準拠しているかどうかを調べます。 ガイドラインに反することがあれば, ただちにパスワードを変更します。
ログイン障害メッセージが表示されるはずなのに,表示されなかったり, 障害数が少なすぎる場合には,パスワードを変更し,ログイン障害の問題がありそうなことをセキュリティ管理者に報告します。
セキュリティ管理者が,発生した場合には特別な注意を払う必要のあるイベント・ タイプを指定していることがあります。このようなイベントが検出された場合には, セキュリティ管理者は,システム・セキュリティ監査ログ・ ファイルに監査結果を送信するか,セキュリティ・オペレータ・ターミナルとして使用可能なターミナルにアラームを送信するようにシステムに指示します。 たとえば,セキュリティ管理者が書き込みアクセスが禁止されている 1 つ以上のファイルを指定している場合に,監査機能を使用可能にするか, アラームを設定しておけば,このようなファイルへのアクセスが発生したことが分かります。
アカウントへの侵入があると考えられる場合には,パスワードを変更します。 重要なファイルに監査機能を適用するように,セキュリティ管理者に要求してもよいでしょう。
監査機能やアラームを起動するイベントには,次のものがあります。
セキュリティ監査またはアラームを開始するイベント | |
---|---|
イメージのインストールファイル・ アクセスのタイプボリュームのマウントとディスマウント | システム・パスワードとユーザ・ パスワード,システム登録ファイル,ネットワーク代理ファイル, または権利データベースの変更 |
ACLファイルまたはグローバル・セクションが要求したアクセス・イベント | ログイン,ログアウト,ログイン障害,侵入の試み |
たとえば,CONFIDREVIEW.MEMというファイルを監査するとします。 ABADGUYというユーザがCONFIDREVIEW.MEMというファイルをアクセスするときに削除アクセス権を持っていると, 次のような監査レコードがシステム・ セキュリティ監査ログ・ファイルに書き込まれます。
%%%%%%%%%%% OPCOM 11-DEC-1998 09:21:11.10 %%%%%%%%%%% Message from user AUDIT$SERVER on BOSTON Security audit (SECURITY) on BOSTON, system id: 19424 Auditable event: Attempted file access Event time: 11-DEC-1998 09:21:10.84 PID: 23E00231 Username: ABADGUY Image name: BOSTON$DUA0:[SYS0.SYSCOMMON.][SYSEXE]DELETE.EXE Object name: _BOSTON$DUA1:[RWOODS]CONFIDREVIEW.MEM;1 Object type: file Access requested: DELETE Status: %SYSTEM-S-NORMAL, normal successful completion Privileges used: SYSPRV
監査メッセージには,不法アクセス者の名前,アクセス方法([SYSEXE]DELETE.EXE プログラムを使用して行われた削除操作),アクセス時間(9:21 A.M) ,ファイルにアクセスするのに使用した特権(SYSPRV) が示されています。セキュリティ管理者は,これらの情報に基づいて処置をします。
いずれかのファイルがアクセスされ,そのファイルのACLの監査エントリ( 第19.6.4項を参照)に指定された条件が満たされるたびに, セキュリティ監査メッセージが監査ログ・ファイルに書き込まれます。CONFIDREVIEW.MEM ファイルにアクセスがあると,セキュリティ監査機能によって保護されているシステム上のファイルにアクセスがあった場合と同様, 監査レコードをセキュリティ監査ログ・ファイルに書き込むようにプロンプトが出されます。
監査機能を導入したら,セキュリティ管理者とともに,別の侵入が生じていないかどうかを定期的にチェックします。
不正にアクセスされた重要ファイルがあれば,セキュリティ管理者に相談して, それらのファイルへのアクセスを監査する戦略を立てるとよいでしょう。
状況を調べて,標準保護コードや汎用ACL (『OpenVMS Guide to System Security 』を参照)を使用してファイルを保護するためのすべての手段を実行しつくした場合には, セキュリティ監査が必要であると判断してよいでしょう。
セキュリティ監査機能を指定するには,所有しているファイルまたはアクセス制御権を持つファイルに特別なアクセス制御リスト・ エントリ(ACE) を追加します。ただし,監査ログ・ファイルはシステム全般に適用されるので, システムごとのセキュリティ管理者がファイル監査の使い方を制御することをおすすめします。 制御権を持つファイルにはユーザでも監査ACE を追加できますが,セキュリティ管理者の場合は,システム・レベルでファイルの監査機能を使用可能にしなければなりません。
アカウントに侵入の試みがあったと考えられる場合には,セキュリティ管理者は, すべてのファイル・アクセスの監査機能を一時的に使用可能にすることができます。 また,監査機能を使用可能にすれば,ファイルに対する読み込みアクセスを監視して, ファイルにアクセスして内容を閲覧したユーザを見つけることもできます。
1つのファイルにアクセス違反があると,他のファイルにもアクセス上の問題が存在することがよくあります。 したがって,セキュリティ管理者は, セキュリティ監査ACLを持つすべての重要ファイルに対するアクセスを監視した方よいでしょう。 重要ファイルに望ましくないアクセスがあった場合には, ただちに処置を講じなければなりません。
たとえば,ユーザRWOODSとセキュリティ管理者が,極秘ファイルであるCONFIDREVIEW.MEM をいつアクセスしたらよいかを知らなければならないと同意した場合には, ユーザRWOODSは,次のようにしてCONFIDREVIEW.MEMファイルの既存のACL にエントリを追加します。
$ SET SECURITY/ACL=(ALARM=SECURITY,ACCESS=READ+WRITE- _$ +DELETE+CONTROL+FAILURE+SUCCESS) CONFIDREVIEW.MEM
[ 前のページ ]
[ 次のページ ]
[ 目次 ]
[ 索引 ]
[ DOC Home ]