|
|
日本−日本語 | |
|
|
 |
|
HP OpenVMS: システム・セキュリティ・ガイド > パート II 一般ユーザのためのセキュリティ
第4章 データの保護 |
|
|
目次 この章では， 第2章 「OpenVMS のセキュリティ・モデル」で紹介したセキュリティ設計について，さらに詳しく説明します。 OpenVMS オペレーティング・システムがユーザ・プロセスおよびアプリケーションによる保護オブジェクトへのアクセスをどのように制御するかを説明します。 簡単に言うと，Open VMS オペレーティング・システムは，共用可能な情報を含むすべてのオブジェクトへのアクセスを制御します。 これらのオブジェクトを保護オブジェクトと呼びます。 デバイス，ボリューム，論理名テーブル，ファイル，コモン・イベント・ フラグ・クラスタ，グループ・グローバル・セクション，システム・グローバル・セクション，資源ドメイン，キュー，ケーパビリティ，およびセキュリティ・クラスがこのカテゴリに入ります。 アクセスするプロセスは，アクセス資格情報をライト識別子という形で持っています。 一方，保護オブジェクトはすべて，当該オブジェクトに指定の方法でアクセスする権限を持つユーザを指定する一連のアクセス要件が設定されています。 この章では，次の内容を説明します。
第5章 「オブジェクト・クラスの詳細」では，保護オブジェクトのクラスごとの特徴を説明します。 ユーザ・プロセスまたはアプリケーションのプロファイルには，以下の要素が含まれています。
OpenVMS Alpha バージョン 7.2 には，スレッド・レベルのセキュリティが実装されています。 この機能はスレッド別セキュリティと呼ばれ，これによって，マルチスレッド・プロセスの実行スレッドごとに，プロセス内の他のスレッドのセキュリティ・プロファイルに影響を与えることなく，独立したセキュリティ・プロファイルを使用できます。 セキュリティ・プロファイルの情報は，以前はプロセス・レベルの各種データ構造体やデータ・セルに分散していましたが，現在は PSB (ペルソナ・セキュリティ・ブロック) と呼ばれる単一のデータ構造体に格納されており，それが個々の実行スレッドにバインドされています。 これに合わせて，OpenVMS 内の関連する参照も参照先が変更されています。 システム内のあらゆるプロセスに，プロセスのナチュラル・ペルソナとなる PSB が少なくとも 1 つあります。 ナチュラル・ペルソナは，プロセスの作成時に作成されます。 スレッド・マネージャ (たとえば，HP POSIX Threads Library に組み込まれているスレッド・マネージャ) とセキュリティ・サブシステムのやり取りにより，スレッドの実行がスケジューリングされている間にプロファイルが自動的に切り替えられます。 ユーザのセキュリティ・プロファイル (特権，権限，および識別情報) は，プロセス・レベルからユーザ・スレッド・レベルに移行しています。 これまで複数のデータ構造体 (アクセス・ライト・ブロック (ARB)，プロセス制御ブロック (PCB)，プロセス・ヘッダ・ディスクリプタ (PHD)，ジョブ情報ブロック (JIB)，制御 (CTL) リージョン・フィールド) に格納されていたセキュリティ情報は，ペルソナ・セキュリティ・ブロック (PSB) という新しいデータ構造体に移され，これに合わせて参照先がすべて変更されています。 これらのデータ構造体に含まれるフィールドの一部は，現在の OpenVMS では使用されていません。 該当するフィールドは，使用廃止されたものと見なされています。 『OpenVMS リリース・ノート』の「廃止されたデータ・セルとセキュリティ情報の新しい場所」という表を参照してください。 それぞれのプロセスに，そのプロセスに割り当てられているすべてのペルソナ・ブロックのアドレスを格納したペルソナ配列があります。 新しいペルソナ・ブロック (PSB) には，以下の情報が格納されています。
カーネル・スレッド・ブロック (KTB) は，現在アクティブなスレッドのペルソナ・ブロックを指します。 OpenVMS の以前のバージョンでは，ユーザのセキュリティ・プロファイルを構成する情報がプロセス・レベルでバインドされ，プロセス内のすべての実行スレッドで共用されていました。 この関係を 図 4-1 「以前のスレッド別セキュリティのモデル」 に示します。 スレッド間でどのようにプロファイルの管理を行うかによって，あるスレッドがセキュリティ・プロファイルに加えた変更が他のスレッドから見える可能性があります。 OpenVMS バージョン 7.2 では，各実行スレッドが他のスレッドとセキュリティ・プロファイルを共用することもできますが，そのスレッド専用のセキュリティ・プロファイルを持つこともできます。 これらの関係を 図 4-2 「スレッド別セキュリティ・プロファイルのモデル」 に示します。 以前のモデルと同じように，共用のプロファイルに加えた変更はプロファイルを共用するすべてのスレッドから見える可能性があります。 一方，スレッド専用のセキュリティ・プロファイルに加えた変更は，特定のスレッドにのみ適用されます。 サブジェクトのセキュリティ・プロファイルの最初の要素は，ユーザ識別コード (UIC) です。 UIC から，ユーザが属するシステム・グループと，そのグループ内でユーザを一意に識別するための情報が得られます。 UIC を指定するときは必ず大括弧で囲みますが，形式にはいくつかの種類があります。 有効な形式を以下に示します。 次の表に，適切な形式で指定した UIC の例を示します。
JONES というメンバ名を持てるユーザは 1 人だけなので，JONES は EXEC グループに属する必要があります。 UIC を恣意的に割り当てることはできません。 UIC を作成するセキュリティ管理者は，以下のガイドラインを守る必要があります。
以下のガイドラインは，システムが UIC をグループ番号とメンバ番号を表す 32 ビットの値に変換するので必要となります。 32 ビットのうち，上位 16 ビットがグループ番号，下位 16 ビットがメンバ番号になります。 オペレーティング・システムは，[J_JONES] のような英数字形式の UIC を変換するとき，英数字形式の UIC のメンバの部分を数値形式の UIC のグループとメンバの部分の両方に等しいものと見なします。 この結果得られる 32 ビットの数値形式の UIC は，ライト・データベース (識別子，識別子の属性，および識別子の保持者を格納するファイル) に保存されます。 たとえば，JONES というメンバに対応する数値形式の UIC は 1 つしか存在し得ないので，同じシステム上で [GROUP1,JONES] という UIC と [GROUP2,JONES] という UIC を作成することはできません。 通常，英数字形式の UIC のメンバ名は，それに対応するログイン・ユーザ名と同じです。 ユーザがシステムにログインすると，システム・ユーザ登録ファイル (SYSUAF.DAT) のユーザ登録 (UAF) レコードからユーザの UIC がコピーされ，ユーザのプロセスに割り当てられます。 これは，そのプロセスが存続する間の識別情報になります。 デフォルトでは，独立プロセス (DCL の SUBMIT コマンドまたは RUN コマンドで作成されたもの) とサブプロセス (DCL の SPAWN コマンドで作成されたもの) の UIC は，プロセスの作成者と同じ UIC になります。 IMPERSONATE 特権を持つユーザは，(RUN コマンドに /UIC 修飾子を指定することにより) 異なる UIC を持つ独立プロセスを作成できます。 サブジェクトのセキュリティ・プロファイルの 2 番目の要素は，一連のライト識別子です。 ライト識別子は，個々のユーザまたはユーザ・グループを表します。 セキュリティ管理者は，登録ユーティリティ (AUTHORIZE) を使用して識別子の作成と削除，およびこれらの識別子のユーザへの割り当てを行えます。 ユーザは必要な期間のみ特定の識別子を保持するので，ライト識別子によるユーザ・グループの識別は一時的な方法です。 OpenVMS オペレーティング・システムでは，複数のライト識別子のタイプをサポートしています。 アクセス制御に最も一般的な使用される識別子を 表 4-1 「主なライト識別子のタイプ」 に示します。 表 4-1 主なライト識別子のタイプ
表 4-1 「主なライト識別子のタイプ」 に挙げた識別子の他に，SYS$SYSTEM の STARTUP.COM システム・スタートアップ・プロシージャが SYS$NODE_ノード名という形式のシステム・ノード識別子を作成します。 ユーザのプロセスには，そのプロセスに割り当てられたすべての識別子を含んだライト・リストが関連付けられています。 また，システムのすべてのユーザが共用するシステム・ライト・リストもあります。 システム管理者またはシステム・ソフトウェアが，システムに現在ログインしているすべてのユーザに割り当てられる識別子をシステム・ライト・リストに割り当てます。 現在のプロセスに割り当てられている識別子は，次のように SHOW PROCESS コマンドを使用して表示できます。
上記の SHOW PROCESS コマンドの出力には，次の 3 種類の識別子が表示されています。 プロセスのライト識別子は，監査レコードにも現れます。 セキュリティ管理者がオブジェクトへのアクセスを監査するようにオペレーティング・システムを設定すると，オブジェクトにアクセスしたユーザとそのアクセスの日時を記録したレコードが生成されます。 単独の監査レコードから十分な情報が得られることはまれですが，長期にわたって蓄積されたレコードを追跡すると，何らかの活動のパターンが浮かび上がることがあります。 次の監査レコードは，Greg がファイルの削除を試みたが，MINDCRIME 識別子を持っているために失敗したことを示しています。 93_FORECAST.DAT ファイルには，MINDCRIME 識別子を有するプロセスによるアクセスを禁止する ACE が設定されています。 これを示すのが，"Event information"，"Matching ACE"，および "Status" の各行です。
サブジェクトのセキュリティ・プロファイルの 3 番目の (省略可能な) 要素は，一連の特権です。 特権を持つことにより，通常は拒否されるシステム機能を使用または実行できるようになります。 セキュリティ管理者は，特別な事情で既存の保護登録情報を変更せずにユーザに必要なタスクを実行させたいときに，そのユーザに特権を与えることができます。 特権のタイプによって，実行できるタスクは異なります。 たとえば，ネットワーク経由のメール送受信を可能にする NETMBX と TMPMBX のように，通常のネットワーク操作を実行するための特権もあります。 しかし，SYSNAM のように，システムの動作を左右する能力を与える特権もあります。 SYSNAM 特権を有するユーザは，システム論理名テーブルを変更できます。 ユーザの特権は，ユーザの UAF レコードに 64 ビットの特権マスクとして記録されます。 ユーザがシステムにログインすると，ユーザの特権ベクタがサブジェクト (プロセス) のセキュリティ・プロファイルに保存されます。 ユーザに許可された特権を，DCL の SET PROCESS/PRIVILEGES コマンドを使用して有効または無効にすることにより，ユーザが実行するイメージに適用可能な特権を制御できます。 例 4-1 「プロセスの許可された特権とデフォルト特権」 は，Puterman というユーザに多くの特権が与えられており，必要に応じてそれらを使用できるけれども，Puterman のプロセスがデフォルトでは NETMBX と TMPMBX の 2 つの特権のみが有効な状態で実行されることを示しています。 例 4-1 プロセスの許可された特権とデフォルト特権
Puterman は，必要に応じて許可された特定の特権を有効にできます。 たとえば，スプールされたデバイスを割り当てるには ALLSPOOL 特権が必要であり，論理入出力操作を実行するには LOG_IO 特権が必要です。 OpenVMS オペレーティング・システムで保護が必要となるオブジェクトは，いずれも情報の格納や受け取りに使用される受動的な格納場所です。 これらのオブジェクトを保護するのは，オブジェクトにアクセスが可能になったユーザはそのオブジェクト内の情報にもアクセスできるためです。 保護オブジェクトには，次のようなものがあります。
OpenVMS で保護されるオブジェクトのクラスの一覧は， 4.2.5 項 「オブジェクトのクラスの指定」にあります。 各クラスの詳細については， 第5章 「オブジェクト・クラスの詳細」を参照してください。 オブジェクトのセキュリティ要素が，オブジェクトのセキュリティ・プロファイルを構成します。 オブジェクトのセキュリティ・プロファイルには，以下の情報が格納されています。
ファイル以外の新しいオブジェクトは，システムによって提供されるテンプレート・プロファイルのセキュリティ要素を継承します。 サイトのセキュリティ管理者は，これらのセキュリティ要素を変更できます。 ファイルにはさらに複雑な継承メカニズムがあり，新しいオブジェクトのセキュリティ要素をさらに細かく制御できます。 いずれの場合も，オブジェクトの作成時にセキュリティ要素を割り当てることにより，オペレーティング・システムのデフォルト設定の使用を避けることができます。 この節では，保護コードと ACL の概要を示します。 4.4 項 「ACL によるアクセスの制御」と 4.5 項 「保護コードによるアクセスの制御」では，これらの保護メカニズムについてさらに詳しく説明します。 個々のオブジェクト・クラスの詳細については， 第5章 「オブジェクト・クラスの詳細」を参照してください。 オブジェクトのセキュリティ・プロファイルの最初の要素は，オブジェクト所有者の UIC です。 ほとんどの場合，オブジェクトを作成したユーザがそのオブジェクトの所有者になります。 オブジェクトの所有者は，所有するオブジェクトのセキュリティ・プロファイルを変更できます。 システムはユーザの UIC をオブジェクトに自動的に割り当て，それに基づいてアクセスを制御します。 所有権に関する規則には，いくつかの例外があります。 資源識別子によって所有されるファイルには，UIC がありません。 資源識別子が所有するディレクトリにユーザがファイルを作成すると，そのファイルは (ファイルを作成したユーザではなく) 資源識別子によって所有されます ( 5.4.5 項 「プロファイルの割り当て」を参照)。 各オブジェクト・クラスの所有権規則については， 第5章 「オブジェクト・クラスの詳細」を参照してください。 ファイルを除くオブジェクトの所有者は， 4.2.4 項 「セキュリティ・プロファイルの変更」で説明するように，SET SECURITY/OWNER コマンドを使用して所有権を他のユーザに再割り当てできます。 ファイルの所有者を変更するには，通常，特権が必要です ( 5.4.2 項 「アクセスのタイプ」を参照)。 オブジェクトのセキュリティ・プロファイルの 2 番目の要素は，オブジェクトの保護コードです。 システムは個々の新しいオブジェクトに保護コードを自動的に割り当てます。 オブジェクトに関連付けられた保護コードは，ユーザの UIC と所有者の UIC の関係に基づいて，ユーザに許可するアクセスのタイプを決定します。 ファイルと擬似ターミナル (FT) デバイスを除き，保護オブジェクトに割り当てられるコードは，そのクラスのテンプレート・プロファイルに基づきます。 ファイルの保護コードは， 5.4 項 「ファイル」で説明するように，別のソースに基づきます。 通常，オブジェクトが (a) 所有者のみ，(b) システム上のすべてのユーザ，または (c) 特定の UIC ベースのユーザ・グループによってアクセスされる場合は，保護コードに基づいてオブジェクトが保護されます。 UIC グループ外の特定のユーザ・グループにアクセス権を付与したいけれども，システム上のすべてのユーザには付与したくない場合には，ACL を追加する必要があります ( 4.2.2.3 項 「アクセス制御リスト (ACL)」を参照)。 保護コードでは，(a) 所有者，(b) 所有者と同じグループ UIC を共用するユーザ (グループ・カテゴリ)，(c) システム上のすべてのユーザ (ワールド・カテゴリ)，(d) システム特権またはシステム権限を持つユーザ (システム・カテゴリ) の，計 4 種類のユーザに対してアクセス権が定義されます。 保護コードには，必ずシステム・カテゴリ (S)，所有者 (O)，グループ (G)，ワールド (W) の順でアクセス権が記述されます。 構文は次のとおりです。 [ユーザ・カテゴリ: 許可されるアクセス (,ユーザ・カテゴリ: 許可されるアクセス,...)] オペレーティング・システムは，保護オブジェクトの使用に対する要求を処理するときに，ユーザの UIC とオブジェクトの所有者の UIC を比較します。 ユーザの UIC がオブジェクトの所有者の UIC と同じ場合は，所有者保護フィールドのアクセス権がユーザに与えられます。 UIC が一致しない場合は，他のユーザ・カテゴリとの比較が行われます。 グループ・フィールドを比較して，同じグループのメンバかどうかを判定します。 また，UIC のグループ番号を調べて，ユーザがシステム・カテゴリに属するかどうかを判定します。 ワールド・カテゴリはすべてのユーザに適用されます。 たとえば， [14,1] という UIC を持つ Jones というユーザが，UIC [14,5] によって所有されているファイルを読み込むとします。 Jones は同じグループ (14) に属するので，このファイルに対するアクセス権が与えられる可能性があります。 最終的な決定は，保護コードに指定されているアクセス権によります。 保護コードの解釈方法と作成方法の詳細については， 4.5 項 「保護コードによるアクセスの制御」を参照してください。 オブジェクトのセキュリティ・プロファイルの 3 番目の (省略可能な) 要素は，オブジェクトのアクセス制御リストです。 アクセス制御リスト (ACL) は，ユーザまたはユーザ・グループが特定の保護オブジェクト (ファイル，ディレクトリ，デバイスなど) に対して持つアクセス権を定義するエントリの集合です。 ACL は，オブジェクトの作成と同時に作成される場合 (デフォルト) と，セキュリティ管理者が作成する場合と，(ユーザが制御アクセス権を持つオブジェクトに関して) ユーザが作成する場合があります ( 4.6.2 項 「制御アクセスによるオブジェクトのプロファイルの変更」を参照)。 セキュリティ管理者はデフォルトの ACL を設定できるので，ユーザによっては自分のオブジェクトに ACL があることに気づかず，ACL をまったく変更しない場合があります。 自分のファイルに ACL があるかどうかは，DCL の DIRECTORY/SECURITY コマンドまたは SHOW SECURITY コマンドを使用して確認できます。 ユーザが自分の ACL の作成や管理に積極的に関わる場合もあります。 ACL を必ずしも使用する必要はありません。 ACL を使用することで，アクセスを許可する対象となるユーザとアクセスの種類を細かく定義できるので，どのようなシステムでもオブジェクトのセキュリティを強化できますが，そのためにはユーザが ACL の作成と管理に時間をかけなければなりません。 ACL の作成および表示には DCL の SET SECURITY コマンドと SHOW SECURITY コマンドを使用しますが， より広範な作業については，アクセス制御リスト・エディタ (ACL エディタ) を使用します。 4.4 項 「ACL によるアクセスの制御」では，ACL とその使用方法についてさらに説明を加えます。 保護オブジェクトのセキュリティ・プロファイルを表示するには，DCL の SHOW SECURITY コマンドを使用します。 たとえば，次のコマンドは 93_FORECAST.TXT というファイルのセキュリティ情報を要求します。
表示結果から，93_FORECAST.TXT が Greg というユーザによって所有されていることがわかります。 また，このファイルの保護コードも表示されています。 保護コードにより，システム・ユーザと所有者に対して読み込み，書き込み，実行，削除の各アクセス権が与えられています。 また，グループ・ユーザに対しては読み込みと実行のアクセス権が与えられ，ワールド・ユーザに対してはアクセス権が与えられていません。 詳細については， 4.5 項 「保護コードによるアクセスの制御」を参照してください。 このファイルには，ACL はまだ設定されていません。 SET SECURITY コマンドを使用して，保護オブジェクトの所有者，保護コード，ACL に対して新しい値を指定したり，オブジェクト間でプロファイルをコピーしたりできます。 たとえば， 4.2.3 項 「セキュリティ・プロファイルの表示」に示した SHOW SECURITY の表示結果から，93_FORECAST.TXT が Greg というユーザによって所有されていることがわかります。 このユーザは，所有者としてこのファイルの保護コードを変更できます。 変更前の保護コードでは，ワールド・ユーザに対してアクセス権が与えられていません。 ここでは，Greg が次のように保護コードを変更して，ワールド・ユーザに読み込みと書き込みの各アクセスを許可します。
このファイルの新しい保護コードを確認するには，次のように SHOW SECURITY コマンドを使用します。
プロファイル内の他の要素の変更方法については， 4.2.5 項 「オブジェクトのクラスの指定」で説明します。 保護コードと ACL の詳細については， 4.4 項 「ACL によるアクセスの制御」と 4.5 項 「保護コードによるアクセスの制御」で説明します。 SET SECURITY コマンドと SHOW SECURITY コマンドの詳細については，『OpenVMS DCL ディクショナリ』を参照してください。 特定の動作を行い，共通の属性のセットを持つオブジェクトのグループは，クラスに分けられます。 ファイル，キュー，およびボリュームがその代表的な例です。 表 4-2 「保護オブジェクトのクラス」 に示すように，OpenVMS オペレーティング・システムでは 11 の保護オブジェクトのクラスがサポートされています。 オブジェクトのプロファイルを変更するときは，SET SECURITY コマンドにオブジェクトのクラスを指定する必要があります。 指定しなかった場合，オブジェクトがファイルであると見なされます。 たとえば，次のコマンド・シーケンスはオブジェクトのプロファイルを変更しますが，/CLASS 修飾子によって LNM$GROUP オブジェクトを論理名テーブルとして識別しています。
この SET SECURITY コマンドによって，Accounting グループを論理名テーブルの所有者に設定しています。 また，保護コードを変更して，所有者とシステム・ユーザに対して読み込み，書き込み，作成，および削除のアクセス権を許可し，グループ・ユーザとワールド・ユーザに許可するアクセス権を読み込みに限定しています。 最後に，ACL を作成して，Chekov というユーザに制御アクセスを許可し，Wu というユーザに読み込みと書き込みのアクセスを許可しています。 変更結果を表示するには，次のように SHOW SECURITY コマンドを使用します。
表 4-2 保護オブジェクトのクラス
個々のクラスの詳細については， 第5章 「オブジェクト・クラスの詳細」を参照してください。 セキュリティ・プロファイルを変更するには，オブジェクトに対する制御アクセス権が必要です。 制御アクセス権は，ACL では明示的に与えられるの対し，保護コードでは所有者カテゴリまたはシステム・カテゴリに属するユーザに対して暗黙のうちに与えられます。 制御アクセス権の獲得方法の詳細については， 4.6.2 項 「制御アクセスによるオブジェクトのプロファイルの変更」を参照してください。 ユーザが保護オブジェクトにアクセスしようとすると，OpenVMS オペレーティング・システムは保護チェック ($CHKPRO) システム・サービスを呼び出して，ユーザ・プロセスのセキュリティ・プロファイルとオブジェクトのセキュリティ・プロファイルを比較します。 保護チェックでは，$CHKPRO がユーザのセキュリティ・プロファイルと保護オブジェクトのプロファイルを以下の順序で比較します。
図 4-3 「アクセス要求評価のフローチャート」 は，OpenVMS オペレーティング・システムがアクセス要求を評価する手順と，アクセスを制御する要素 (ACL，保護コード，特権，およびアクセス権の変更) の相互関係を示した図です。 4.2.2.3 項 「アクセス制御リスト (ACL)」では，オブジェクトのセキュリティ・プロファイルを構成する要素の 1 つとしてアクセス制御リスト (ACL) を紹介しました。 この節では，この保護メカニズムをさらに詳しく説明し，ACL を使ってオブジェクトを効果的に保護する方法の例を示します。 ほとんどの場合，オペレーティング・システムがオブジェクトに自動的に割り当てる保護コードで十分なため，多くのユーザは ACL について気にする必要がありません。 しかし，特定のユーザに自分のファイルへのアクセスを許可する必要が生じることがあります。 たとえば，同じプロジェクトで作業をしている場合などです。 ACL は，重要なシステム・ファイル，デバイス，ボリューム，その他の保護オブジェクトを保護するための効果的なメカニズムなので，システム管理者やセキュリティ管理者は，一般ユーザよりも頻繁に ACL を使用します。 アクセス制御リスト (ACL) 内のエントリは，アクセス制御エントリ (ACE) と呼ばれます。 ACL は多数のエントリを持つことができ，個々のエントリはオブジェクトの何らかの属性を定義します。 ACE には数多くの種類があります。 詳細については，『OpenVMS システム管理ユーティリティ・リファレンス・マニュアル』を参照してください。 ここでは，オブジェクトへのアクセスを制御する識別子用 ACE について説明します。 識別子用 ACE には，1 つまたは複数のライト識別子と，その識別子を保持するユーザが行使を許可されているアクセスのタイプを示すリストが含まれています。 システムは，オブジェクトに対するユーザの権限を評価するとき，アクセスするユーザが保持する 1 つまたは複数のライト識別子と一致する識別子用 ACE が見つかるまでオブジェクトの ACL を検索し，[2]見つかったエントリに基づいてアクセスを許可または拒否します。 ACE に応じて許可 (または拒否) するアクセスのタイプは，保護の対象となるオブジェクトによって異なります。 たとえば，ファイルに対しては読み込み，書き込み，実行，および削除を実行でき，デバイスに対しては読み込みと書き込みの他に物理的操作と論理的操作を実行できます。 したがって，ファイルは読み込み，書き込み，実行，および削除の各アクセスをサポートし，デバイスは読み込み，書き込み，物理，および論理の各アクセスをサポートします。 他のオブジェクト・クラスがサポートするアクセスのタイプについては， 第5章 「オブジェクト・クラスの詳細」を参照してください。 識別子用 ACE を含む ACL を作成するには，DCL の SET SECURITY コマンドを次の形式で使用します。 SET SECURITY/ACL=(IDENTIFIER=識別子,ACCESS=アクセスのタイプ) たとえば，Fred というユーザが PROJECT-DATA.TXT というファイルを読めるようにするには，次のコマンドを入力します。
"FRED" はユーザ識別コード (UIC) のメンバ名です。 したがって，Fred に PROJECT-DATA.TXT ファイルへの読み込みアクセスを許可するエントリの UIC 識別子として機能します。 個々のユーザまたはユーザ・グループの権限は識別子によって定義される ( 4.1.6.1 項 「識別子のタイプ」を参照) ので，それらを識別子用 ACE に指定することによって，それらを保持するユーザに許可 (または拒否) するアクセスを定義します。 システム上の個々のユーザまたはユーザ・グループは，UIC 識別子によって簡単に識別できます。 それぞれが異なる機能グループ (つまり，さまざまな UIC グループ) に属するユーザのグループの全員が，ある保護オブジェクトへのアクセス権を必要とする場合，セキュリティ管理者は汎用識別子を作成し，アクセス権を必要としているすべてのユーザにその識別子を付与します。 たとえば，次のコマンドは UIC 識別子 [PAT] によって識別される Pat というユーザに，DISK1 上の ROBERTS ディレクトリ内のファイルに対する読み込み，書き込み，および実行アクセスを許可します。 この ACL では，アクセス・ステートメントから削除アクセスと制御アクセスが除外されているため，Pat によるこれらのアクセスは拒否されます。
セキュリティ管理者は，登録ユーティリティを使用して汎用識別子を作成し，これを使用するすべてのユーザに与えます。 たとえば，セキュリティ管理者が PAYROLL という識別子を作成し，それを給与計算ファイルにアクセスする必要がある従業員に割り当てたとします。 この識別子の保持者が実際に給与計算ファイルにアクセスするには，管理者がそのファイルに識別子用 ACE を追加する必要があります。 たとえば，次のコマンドは PAYROLL ファイルの ACL を作成し，PAYROLL 識別子の保持者にこのファイルへの読み込みアクセス権を与えます。
ACL 内の ACE の順序は，オペレーティング・システムによる処理の規則に関わるので重要です。 ACE の順序については， 4.4.6 項 「リスト内の ACE の順序」を参照してください。 識別子用 ACE は，オブジェクトへのアクセスを許可する場合だけでなく，オブジェクトへの特定のユーザのアクセスを拒否する場合にも頻繁に使用されます。 サイトによっては，モデムやネットワークを介してログインするユーザを制限するために ACL を使用する場合があります。 また，高価な装置や機密ファイルの入ったボリュームに ACE を設定して，それらへのアクセスを制限する場合もあります。 特定の識別子の保持者に対してすべてのアクセスを拒否するには，アクセス・タイプ名として NONE キーワードを指定します。 たとえば，次のコマンドは環境識別子 DIALUP の保持者に対して，PROJECT-ACCOUNTS ディレクトリ内のファイルへのあらゆるアクセスを拒否します。
NONE キーワードを使ってアクセスを拒否する場合は，他にもいくつか考慮すべきことがあります。 4.4.6 項 「リスト内の ACE の順序」で説明するように，OpenVMS オペレーティング・システムでは最初に一致する ACE に基づいてアクセスが許可または拒否されるため，ACL 内に ACE を正しく配置する必要があります。 または，保護コードのグループ・カテゴリまたはワールド・カテゴリによって許可されるアクセスをすべて除外する方法もあります (具体的には 4.3 項 「システムによる保護オブジェクトへのユーザのアクセス可否の判定」と 4.5.5 項 「機密オブジェクトに対する保護の強化」を参照)。 セキュリティ管理者は，一致する ACE を変更できる特権を無効にすることもできます。 セキュリティ管理者は，たとえば 4.4.2 項 「特定ユーザへのアクセスの許可」に示したように給与計算ファイルなどの共通ファイルへのアクセスを許可する一方で，小切手印刷用の高品質プリンタを使用できるユーザの数を限定したい場合があります。 限定しなければ，PAYROLL 識別子を保持するすべてのユーザが TTA8 プリンタに常時セットされている小切手フォームにアクセスできることになります。 この例では，小切手用プリンタがログインに使用されたり，キューの出力先に指定されることはないので，セキュリティ管理者はプリンタに ACL を追加して，McGrey というユーザにのみ読み込みアクセスと書き込みアクセスを許可するように設定できます。 同時に，セキュリティ管理者は他の識別子の保持者によるプリンタへのアクセスを禁止する必要があります。 次のコマンド・シーケンスを使用して，このような ACL を作成できます。
McGrey には読み込みアクセスと書き込みアクセスが許可されますが，他のユーザは， 4.4.3 項 「オブジェクトへのユーザのアクセスの禁止」で説明したように，NONE キーワードによってアクセスを拒否されます。 ただし，セキュリティ管理者がプリンタの保護コードを変更するまでは，TTA8 プリンタの ACL は意図したとおりに機能しない場合もあります。 詳細については， 4.5.5 項 「機密オブジェクトに対する保護の強化」を参照してください。 識別子用 ACE を使用し，特定の種類の識別子を組み合わせることによって条件付きのアクセスを提供できます。 たとえば，代表的な例としては，BATCH や INTERACTIVE のような環境識別子とともに UIC 識別子を使用する方法があります (環境識別子の一覧については， 4.1.6.1 項 「識別子のタイプ」を参照してください)。 この場合，ユーザはバッチ・モードまたは会話形式で実行されている場合にのみ保護オブジェクトにアクセスすることができ，ダイアルアップ回線経由ではアクセスできません。 たとえば，次のコマンドは Fred というユーザにプリント・キューへの登録アクセスと管理アクセスを許可しますが，許可するのは Fred がバッチ・ジョブを実行している場合のみです。
ACL には，1 つまたは複数のエントリを含めることができます。 ACL に複数の ACE がある場合，最初に一致する ACE に基づいてアクセス権が決定されるため，エントリの順序が重要な意味を持ちます。 オペレーティング・システムは ACL を先頭から順に検索し，最初に一致した ACE に指定されているアクセス権をユーザに付与します。 それ以降のエントリはすべて無視されます。 評価のプロセスについては， 4.3 項 「システムによる保護オブジェクトへのユーザのアクセス可否の判定」を参照してください。 ACL を作成するときは，以下の原則に従います。
PROJECT-ACCOUNTS.DIR ディレクトリ・ファイルに対する次の ACL を例に，ACL 内のエントリの順序の決め方を示します。 この ACL では，重要なユーザ (Jones と Fred) にアクセス権を付与する ACE をリストの先頭に置き，その後に一般の ACE を置いています。 アクセスを拒否する ACE はリストの末尾に置いています。
プロジェクト・アカウントのディレクトリに設定されたこの ACL では，読み込み，書き込み，実行の各アクセスを Jones に対して常に許可し，Fred に対してはバッチ・ジョブの実行時にのみ許可しています。 また，PAYROLL 識別子を保持するユーザには読み込みアクセス権を与えています。 モデムからログインしたユーザについては，上位に置いた ACE によってアクセス権を付与しない限り，アクセスを拒否します。 たとえば，Jones，Fred，または PAYROLL 識別子の保持者がダイアルアップした場合，これらのユーザに対する ACE を DIALUP の ACE の前に置いているため，アクセスが許可されます。 次の例は，STAFFING.DAT というデータ・ファイルの ACL です。 この例では，最も多くのファイル・アクセス権を与えるエントリを ACL の先頭に置いています。
この ACL では，SECURITY 識別子を保持するユーザが最初の ACE によって最大限のアクセス権を取得し，PERSONNEL 識別子を保持するユーザがそれに次ぐアクセス権を取得します。 Jones は，汎用識別子のいずれかを保持していない限り，ファイルへのあらゆるアクセスを禁止されます。 これは，ACL の作成者のミスである可能性があります。 Jones がファイルへのアクセス権を確実に獲得できないようにしたい場合は，このエントリを ACL の末尾から先頭に移動します。 ディレクトリ内またはディレクトリ構造内にあるファイルへのアクセスを制御するための計画を立て，各ファイル用の適切な ACL を作成したら，新しいファイルにこの ACL を自動的に割り当てるようにオペレーティング・システムに指示できます。 このためには，Default 属性を持つ識別子用 ACE を作成し，対象となるファイルが登録されるディレクトリ・ファイルにその ACE を追加します。 Default 属性を設定するには，OPTIONS キーワードを使用します。 たとえば，[MALCOLM] ディレクトリ内のすべての新しいファイルに対して，PERSONNEL 識別子を持つユーザに読み込みアクセスと書き込みアクセスを許可する ACL エントリを割り当てるには，MALCOLM.DIR ファイルに次の ACE を追加します。
この ACE を追加すると，[MALCOLM] ディレクトリ内に作成されたファイルには次の ACL が割り当てられます。
Default 属性は，新しいファイルの ACL には含まれず，ディレクトリ・ファイルの ACL にのみ含まれます。 ただし，MALCOLM ディレクトリ内に作成されるサブディレクトリの ACL には，このエントリ (IDENTIFIER=PERSONNEL,OPTIONS=DEFAULT,ACCESS=READ+WRITE) が自動的に追加されます。 このようにして，この ACE はディレクトリ木構造の全体に適用されます。 この ACE は，MALCOLM.DIR 内の既存のファイルに遡って適用されません。 既存のファイルに ACE を追加するには， 4.5.7 項 「ファイルのデフォルト・セキュリティ・プロファイルの復元」で説明するように /DEFAULT 修飾子を使用するか，次のコマンドを使用します。
Default 属性を持つ ACE は，その ACE の適用方法を制御するだけで，アクセス制御に対して影響を与えません。 ファイルとディレクトリの両方へのアクセスを制御するには，次のように，ディレクトリの ACL に 2 つの ACE を追加します。
DCL の SHOW SECURITY コマンドを使用して，オブジェクトの ACL を表示できます。 ファイル以外のオブジェクトが対象の場合には，オブジェクト名とともにクラス名も指定する必要があります。 たとえば，次のコマンドは PPA0 という名前のデバイスのセキュリティ属性を表示します。 このデバイスはオペレーティング・システムによって所有されており，保護コードによってシステム・カテゴリと所有者カテゴリのユーザにフル・アクセス (読み込み，書き込み，物理，および論理アクセス) が許可されていますが，グループ・ユーザとワールド・ユーザにはアクセスが許可されていません。 また ACL によって Svensen というユーザに制御アクセス権が付与されています。
ACL を表示する方法は，他にもいろいろあります。 アクセス制御リスト・エディタ (ACL エディタ) は，ACL に関するさまざまな作業を実行するときに便利なツールです。 『OpenVMS システム管理ユーティリティ・リファレンス・マニュアル』の ACL エディタに関する記述を参照してください。 一方，以下の DCL コマンドでも ACL を表示できます。
アプリケーションが ACE に Hidden 属性を追加して，ACE を変更できるのはその ACE を追加したアプリケーションだけであることを示す場合があります。 隠された ACE は，ユーザが SECURITY 特権を持っていない限り，DCL コマンドでは表示されません。 ACL エディタでは Hidden 属性を持つ ACE も表示されますが，ACL 内での相対的な位置を示すことが目的であり，権限のないユーザはそれらの ACE を編集できません。 ACL 内には，アクセス制御とは関係のない別の種類の ACE が設定されている場合があります。 たとえば，セキュリティ管理者が LN03$PRINT キューにセキュリティ監査用 ACE を設定した場合は，(AUDIT=SECURITY,ACCESS=アクセス・タイプ) という形式の ACE がリストの先頭に表示されます。 このような ACE はセキュリティ監査システムの構成要素であり，アクセス制御には影響しないため，無視して構いません。 4.4.2 項 「特定ユーザへのアクセスの許可」～ 4.4.5 項 「環境へのアクセスの制限」では，DCL の SET SECURITY コマンドを使って空の ACL にエントリを追加する方法を説明しています。 ACL を広範に変更するには ACL エディタを使用しますが，多くの場合，SET SECURITY コマンドを使用する方が適切です。 この節以降では，SET SECURITY を使用して ACL を変更する方法について説明します。
ACL にエントリを追加するには，SET SECURITY コマンドに /ACL 修飾子を加え，新しい ACE を指定します。 たとえば，文書作成者 (WRITERS) に LN03$PRINT プリント・キューへのアクセス権を付与するには，次のコマンドを使用します。 次の SHOW SECURITY の表示結果からわかるように，新しい ACE はデフォルトで ACL の先頭に置かれます。
SET SECURITY のデフォルトの動作では新しい ACE が ACL の先頭に置かれるため，ACE を別の位置に入れたい場合は /AFTER 修飾子を使用する必要があります。 たとえば，キューの ACL 内で TRADERS の ACE を WRITERS の ACE の後に置くには，次のコマンドを使用します。
表示結果から，/AFTER 修飾子の効果を確認できます。 新しい ACE がリストの 2 番目の位置に置かれています。
SET SECURITY コマンドに /DELETE 修飾子を加えると，ACL を削除できます。 この修飾子の使い方次第で，ACL の全体または一部を削除できます。 たとえば，次のコマンドはディスクの ACL を削除します。
Protected 属性が割り当てられている ACE は，不注意による削除から保護されます。 保護されている ACE を削除するには，その ACE を明示的に削除するか，SET SECURITY/ACL コマンドに /DELETE=ALL 修飾子を指定する必要があります。 ACL を部分的に削除するには，/ACL 修飾子を使って不要な ACE を指定した上で，/DELETE 修飾子を使用します。 たとえば，次のコマンドは TRADERS 識別子と NETWORK 識別子の保持者に DBA0 ボリュームへの書き込みアクセス権を付与する ACE を削除します。
ACL 内の一定範囲の ACE を別の ACE にまとめて置き換えるには，次のように /REPLACE 修飾子を使って新しい ACE を指定し，/ACL 修飾子を使って削除する ACE を指定します。
まず，/ACL で指定している TRADERS の ACE が削除されます。 次に，/REPLACE 修飾子で指定している ACE (RESEARCH，STATE_DEPARTMENT，ENERGY_DEPARTMENT) が，削除された ACE の位置に挿入されます。 ファイルのデフォルト ACL を復元するには，SET SECURITY コマンドで /DEFAULT 修飾子を使用します。 この修飾子を指定すると，ファイルの完全なセキュリティ・プロファイルが再生成されます。 詳細については， 4.5.7 項 「ファイルのデフォルト・セキュリティ・プロファイルの復元」を参照してください。 あるオブジェクトのセキュリティ・プロファイルを別のオブジェクトにコピーするには，SET SECURITY コマンドで /LIKE 修飾子を使用します。 たとえば，論理名テーブルのような永続的でないオブジェクトに複雑な ACL を設定した場合でも，ファイルなどの永続的なオブジェクトにコピーすることによってその ACL を保存できます。 管理者がコピー操作のテンプレートとして使用できるファイルを作成する場合もあります。 これにより，管理者はオブジェクト間で ACL を簡単に転送することができます。 たとえば，次のコマンドは ACL_TEMPLATE.TXT ファイルから LNM$GROUP 論理名テーブルに ACL をコピーします。
/LIKE 修飾子に /COPY_ATTRIBUTE 修飾子を追加すると，完全なプロファイルではなく 1 ～ 2 個の要素をコピーできます。 たとえば，KITE_FLYING ディレクトリに次のような ACL があるとします。
次のコマンドは，上記の ACL を KITE_FLYING ディレクトリから KITE_DESIGNS ディレクトリにコピーします。
SET SECURITY/LIKE コマンドによって，必ずしもコピー元オブジェクトの ACL 全体が複製されるとは限りません。 たとえば，Nopropagate 属性を持つ ACE はコピー元の ACL からコピーされません。 また，保護されている ACE も上書きされません。 コピー先オブジェクトの保護されている ACE は維持され，コピーされた ACL に追加されます。 たとえば，アプリケーションの多くはファイル・データの正しい表示方法を示すために特殊なタイプの保護されている ACE を使用しますが，これらの ACE はそのまま維持する必要があります。 ACE に設定できる属性の種類については，『OpenVMS システム管理ユーティリティ・リファレンス・マニュアル』の ACL エディタに関する記述を参照してください。 ACE のタイプについては，『HP OpenVMS Programming Concepts Manual』を参照してください。 保護コードは，特定のユーザまたはユーザのグループに対して許可 (または拒否) するアクセスのタイプを制御します。 アクセス・タイプは，保護オブジェクトに対する操作を実行するのに必要な権限を示します。 OpenVMS オペレーティング・システムでは，1 つの操作を完了するのに複数のアクセス権が必要となる場合があります ( 4.7.2 項 「オブジェクトのクラスに対する監査の有効化」を参照)。 保護コード内にユーザが属するカテゴリが見つかり，要求されたアクセスが (ACL で拒否されておらず) そのカテゴリで許可されていれば，ただちにユーザにオブジェクトへのアクセス権が付与されます。 保護コードの形式は，次のとおりです。 [ユーザ・カテゴリ: 許可されるアクセスのリスト (, ユーザ・カテゴリ: 許可されるアクセスのリスト,...)] ユーザ・カテゴリ ユーザ・カテゴリには，システム (S)，所有者 (O)，グループ (G)，およびワールド (W) があります。 各カテゴリは，対応する英単語の先頭 1 文字で表すことができます。 各カテゴリは次のように定義されます。 複数のユーザ・カテゴリを指定する場合は，各カテゴリをコンマで区切り，コード全体を括弧で囲みます。 ユーザ・カテゴリとアクセス・タイプは，任意の順序で指定できます。 ただし，表示されるときは常にシステム，所有者，グループ，ワールドの順になります。 特定のユーザ・グループによるアクセスをすべて拒否するには，アクセス・タイプを指定せずにユーザ・カテゴリだけを指定します。 ユーザ・カテゴリの後のコロンを省略することで，特定のユーザ・カテゴリによるアクセスを拒否できます。 特定のカテゴリ全体を省略すると，そのカテゴリに対するアクセス権は未指定となります。 この場合，そのユーザ・カテゴリに現在許可されているアクセス権がそのまま適用されます。 作成されたオブジェクトに (たとえば COPY/PROTECTION コマンドによって) 保護コードが適用される場合，省略されたカテゴリにはデフォルト値が割り当てられます。 アクセス・タイプはオブジェクトによって決まります。 アクセス・タイプについては 第5章 「オブジェクト・クラスの詳細」で説明します。 ファイルに関するアクセス・タイプには，読み込み (R)，書き込み (W)，実行 (E)，および削除 (D) があります。 アクセス・タイプはユーザ・カテゴリごとに割り当て，アクセス・タイプとユーザ・カテゴリはコロン (:) で区切ります。 たとえば，SET SECURITY/PROTECTION=(S:RWE,O:RWE,G:RE,W) のようにします。 個々のユーザ・カテゴリに対して，異なるタイプのアクセスを許可または拒否できます。 正確なタイプは，保護対象オブジェクトによって異なります。 各オブジェクト・クラスには，そのクラスに対応するアクセス・タイプが定義されています。 これらのアクセス・タイプは，ユーザがそのデータに対して実行する操作の典型を示しています。 たとえば，ファイル・オブジェクトは読み込み，書き込み，実行，および削除の各アクセスをサポートするのに対して，デバイス (ターミナル，プリンタ，ディスクなど) は読み込み，書き込み，物理入出力，および論理入出力の各アクセスをサポートします。 各オブジェクト・クラスがサポートするアクセス・タイプについては， 第5章 「オブジェクト・クラスの詳細」を参照してください。 すべての保護オブジェクトは，制御アクセスをサポートします。 制御アクセスにより，ユーザはオブジェクトのセキュリティ要素 (ACL，保護コード，UIC) と，場合によってはその他の属性を参照および変更できます。 制御アクセス権は，ACL では明示的に記述されますが，UIC ベースの保護コードには現れません。 保護コードのシステム・カテゴリまたは所有者カテゴリに属するユーザはすべて制御アクセス権を持っています。 グループ・カテゴリとワールド・カテゴリのユーザは，保護コードによる制御アクセス権を獲得することはありませんが，ACL で獲得することは可能です。 詳細については， 4.6.2 項 「制御アクセスによるオブジェクトのプロファイルの変更」を参照してください。 読み込み，書き込み，実行，削除，および制御の各アクセス・タイプによって指定される機能は，適用される状況によって異なります。 たとえば，実行アクセスで許可される操作は，ファイル・アクセスとディレクトリ・アクセスのどちらに対して許可されるかによって異なります。 各アクセス・タイプが保護オブジェクトの各タイプに対して許可する機能については， 第5章 「オブジェクト・クラスの詳細」で説明します。 システムによる保護コードの評価は，所有者フィールド，ワールド・フィールド，グループ・フィールド，システム・フィールドの順に行われます。 ユーザがあるカテゴリのメンバとしての条件を満たし，そのカテゴリによって必要なアクセス権が付与されると，保護コードの処理はそこで終了します ( 図 4-3 「アクセス要求評価のフローチャート」を参照)。 次の保護コードは，システム・カテゴリと所有者カテゴリのユーザが読み込み (R)，書き込み (W)，実行 (E)，および削除 (D) のアクセス権を持ち，グループ・カテゴリとワールド・カテゴリのユーザが読み込みと実行のアクセス権のみを持つことを指定します。
特定のユーザ・カテゴリに対してアクセスを拒否する場合は，それより範囲の広いすべてのカテゴリに対してアクセスを拒否する必要があります。 4.5.1 項 「保護コードの形式」で説明したように，ユーザ・プロセスおよびアプリケーションはすべてワールド・カテゴリのアクセスを認められます。 グループ・カテゴリのアクセスは，ワールド・カテゴリよりも制限されていますが，所有者カテゴリおよびシステム・カテゴリほど制限が厳しくありません。 たとえば，次の保護コードは所有者カテゴリに対して削除アクセスを拒否しているように見えます。
しかし，このファイルの所有者は依然としてこのファイルを削除できます。 所有者カテゴリでは削除アクセスを許可していませんが，アクセスが許可されているかどうかのチェックは他のカテゴリについても行われます。 所有者はワールド・カテゴリ (すべてのユーザに適用されるカテゴリ) にも属しており，ワールド・カテゴリでは削除アクセスが許可されているので，所有者にも削除アクセスが許可されます。 SET SECURITY コマンドを使用して，既存オブジェクトの UIC ベースの保護を変更できます。 次のコマンドは，SURVEY.DIR ファイルの保護コードを変更して，システム・カテゴリと所有者カテゴリのユーザに読み込み，書き込み，実行，および削除の各アクセス権を与え，グループ・カテゴリとワールド・カテゴリのメンバに読み込みと実行のアクセス権を与えます。
保護コードからカテゴリを省略すると，現在のアクセス権がそのまま適用されます。 たとえば，RECORDS_91.DAT というファイルの保護コードを考えます。
現在の RECORDS_91 ファイルでは，システム，所有者，グループの各カテゴリのユーザに対して読み込み，書き込み，実行，および削除の各アクセスが許可され，ワールド・カテゴリのユーザに対して読み込みアクセスと実行アクセスが許可されています。 次の DCL コマンドは，RECORDS_91.DAT の保護コードを再設定して，グループ・カテゴリに対して書き込みアクセスと削除アクセスを拒否し，ワールド・カテゴリに対してすべてのアクセスを拒否します。
次のコマンドは，変更した保護コードを確認します。 システム・カテゴリと所有者カテゴリのユーザには依然として読み込み，書き込み，実行，および削除の各アクセス権が与えられているのに対して，グループ・ユーザには読み込みアクセス権と実行アクセス権のみが与えられ，ワールド・ユーザにはアクセス権がまったく与えられていません。
4.4.4 項 「デバイスへのアクセスの制限」では，重要なプリンタに ACL を設定して，プリンタへのアクセス権を 1 人のユーザに限定する方法を説明しています。 しかし，この ACL を有効にするには，セキュリティ管理者が次のコマンドを使用して，プリンタの保護コードによって許可されるすべてのアクセスを排除する必要があります。
次に，セキュリティ管理者は ACL を使用してアクセス権を明示的に割り当てます。 たとえば，キューへのアクセスを制限するには，ワールド・カテゴリのキュー登録アクセス権を削除します。 次に，ACL を設定して，(ワールド・カテゴリの) どのユーザにキューへのジョブ登録を許可するかを指定します。 次のコマンドは，PROJECTX 識別子の保持者にのみ LN03$PRINT キューへのジョブ登録を許可します。
重要なファイルは多くの場合，特別な保護を必要とします。 ディレクトリの内容を参照できないようにするには，ユーザによる読み込みアクセスを拒否します。 ファイルの保護を強化するには， 4.5.6 項 「ディレクトリ構造に対するデフォルトの保護コードの提供」に示すように，ディレクトリ・ファイルにデフォルトの保護用 ACE を追加します。 特定のディレクトリ内の新しいファイルに対してデフォルトの保護を指定するには，ディレクトリ・ファイルの ACL にデフォルトの保護用 ACE を含めます。 デフォルトの保護用 ACE は，以降そのディレクトリおよびその下のサブディレクトリに作成されるファイルに適用されます。 ただし，ファイルに個別の保護が指定された場合は除きます。 この ACE の形式は，次のとおりです。 (DEFAULT_PROTECTION[,オプション],保護コード) たとえば，次の ACE は，システム・カテゴリと所有者カテゴリのユーザに，このディレクトリ内で新たに作成されるファイルに対する読み込み，書き込み，実行，および削除の各アクセス権を与え，グループ・カテゴリとワールド・カテゴリのユーザにアクセス権をまったく与えないことを指定します。
デフォルトの保護は新たに作成されるファイルにのみ適用される点に注意してください。 現在のディレクトリとそのサブディレクトリに既に存在するファイルには適用されません。 ディレクトリ・ファイルにデフォルトの保護用 ACE を追加し，既存のファイルにも同じ保護を適用したい場合は，次のコマンドを使用して明示的に保護を変更する必要があります。
SET SECURITY コマンドに /DEFAULT 修飾子を加えると，ファイルのセキュリティ・プロファイルが再生成されます。 /DEFAULT 修飾子は，ファイルの保護コード，ACL，および所有者要素を，ファイルの親ディレクトリに指定されているデフォルト (つまり，ディレクトリのデフォルト ACL，(もしあれば) デフォルトの保護用 ACE，および所有者 UIC) に再設定します。 セキュリティ・プロファイルは次の規則に従って再生成されます。
サブディレクトリ・ファイルの場合は，SET SECURITY によって親ディレクトリの所有者，保護，および ACL の各要素が割り当てられます。 SET SECURITY は，設定元のオブジェクトの ACE に Nopropagate 属性がある場合は，その ACE をコピーしません。 また，設定先のオブジェクトの ACE に Protected 属性がある場合は，その ACE を変更しません。 ファイルのすべてのバージョンに新しい要素を適用するには，オブジェクト名として ;* を指定します。 継承規則の詳細については， 5.4.5 項 「プロファイルの割り当て」を参照してください。 オブジェクトは ACL と保護コードによって入念に保護できますが，ユーザは依然として特権および制御アクセスを利用することでアクセス権を獲得することができます。 セキュリティ管理者は，ユーザ・アカウントを作成または変更するときに，ユーザに特権を割り当てることができます。 システム特権の READALL と BYPASS は，オブジェクトの ACL およびセキュリティ・プロファイルの他の要素によって指定されるアクセス権に関係なく，ユーザ・アクセスに影響を与えます。 SYSPRV 特権と GRPPRV 特権は，保護コードのシステム・カテゴリで制御します。 これらの特権の意味を次に示します。
オブジェクトに対して ACL や保護コードを定義するときは，強力な特権を有するユーザにはシステム全体のオブジェクトに対する特別なアクセス権を付与されることを忘れないでください。 たとえば，BYPASS 特権を有するユーザによる特定のファイルへのアクセスを防ぐ方法はありません。 GRPPRV 特権を有するユーザは，自分の UIC グループに属する他のメンバのためにさまざまなシステム管理機能を実行する権限を持っています。 オブジェクトの保護は，これらの特権の付与に関するセキュリティ管理者の判断に左右されます。 オブジェクトに対する制御アクセス権を持つユーザは，オブジェクトの保護コードと ACL を変更することにより，オブジェクトへのアクセス権を獲得できます。 ファイル以外のオブジェクト・クラスについては，制御アクセス権を持つユーザがオブジェクトの所有者を変更することもできます。 ファイルの所有者の変更には，通常，特権が必要です ( 5.4.2 項 「アクセスのタイプ」を参照)。
オブジェクト・クラスによっては，制御アクセスが他の手段で許可される場合もあります。 これに該当する特別な状況については， 4.6.3 項 「アクセスに関するオブジェクト固有の考慮事項」および 第5章 「オブジェクト・クラスの詳細」の各クラスの説明を参照してください。 オブジェクトによっては，( 4.6.1 項 「保護メカニズムに対する特権の影響」に示した以外の) 特別な特権や包括的なタイプのアクセス権によってアクセスが許可される場合があります。 特に，キューがこれに該当します。 オペレータ (OPER) 特権を持つユーザには，キューに対するすべてのタイプのアクセスが許可されます。 管理アクセス権を持つユーザは，キューに対する他のタイプのアクセス権 (読み込み，登録，および削除) を暗黙に保持しています。 第5章 「オブジェクト・クラスの詳細」に，各オブジェクト・クラスのアクセス・タイプ，意味，および特別な特権を示します。 プロセスがオブジェクトを使用するか，オブジェクトのセキュリティ・プロファイルを変更する ( 4.2.4 項 「セキュリティ・プロファイルの変更」を参照) たびに，オペレータ・ターミナルにアラームを送信するか，監査ログ・ファイルにメッセージが記録するようにできます。 セキュリティ管理者は，ログ・ファイルを参照することにより，システムの動作を調べ，保護オブジェクトをいつ，誰が，どのように使用したかを確認できます。 監査システムによってどのような情報が報告されるかは，セキュリティ管理者がサイトの要件をどのように定義するかによります。 オブジェクトの使用状況を監査する場合，システム管理者は適切なカテゴリのイベントに対する監査機能を有効にできます。 OpenVMS オペレーティング・システムでは，セキュリティ関連イベントにフィルタを適用して，オブジェクトが特定の方法でアクセスされたときにだけシステム管理者にメッセージを送信するようにできます。 多くのサイトでは，すべてのファイル・アクセスではなく，特権を利用したファイルの使用やファイルへのアクセスの失敗が関心の対象になります。 このようなサイトでは，プロセスがファイルへのアクセスに成功した場合ではなく，失敗した場合の監査メッセージを要求できます。 システムは，プロセスがオブジェクトにアクセスする権利をそもそもどのように (保護コード，ACE，または特権を介して) 行使したか (または行使できなかったか) を報告します。 オブジェクト・クラスはそれぞれに固有の監査プロファイルがあるため ( 第5章 「オブジェクト・クラスの詳細」を参照)，オブジェクトのクラスによっては他のクラスよりも詳細な情報を得ることができます。 どのオブジェクトについても，ユーザまたはアプリケーションがオブジェクトにアクセスするか，セキュリティ要素を変更したときに，必ず監査メッセージが送信されるようにできます。 場合によっては，プロセスがオブジェクトを作成したとき，オブジェクトの使用を止めた (アクセスを解除した) とき，またはオブジェクトを削除したときに通知を送信することもできます。 オブジェクト・アクセス・イベントを監査するときは，1 つの操作の間に，オブジェクトに対するユーザの権利がオペレーティング・システムによって複数回チェックされる場合があることに注意してください。 たとえば，ファイル操作ではディレクトリ・アクセスに関するチェックとファイル・アクセスに関するチェックの両方が行われます。 ユーザがファイルを削除する前には，そのファイルに対する削除アクセス権のチェックと，ディレクトリに対する書き込みアクセス権のチェックが行われます。 このため，セキュリティ管理者は，すべてのタイプのオブジェクト・アクセス・イベントについて監査機能を有効にするのが最善策です。 たとえば，ユーザがファイルにアクセスしようとして失敗した場合をすべて追跡するには，セキュリティ管理者が SET AUDIT コマンドに /ENABLE=ACCESS=FAILURE=ALL 修飾子を指定します。 アクセス解除の監査をサポートするオブジェクト・クラス (ファイル・クラスなど) では，プロセスがオブジェクトへのアクセス権を獲得すると，そのプロセスがすでに許可されているアクセス・モードに適合しない操作を行わない限り，システムはそのオブジェクトに対する以降のアクセス操作を監査しません。 この状況が発生すると，システムは監査対象となる追加的な保護チェックを実行します。 このアクセス・ウィンドウは，オブジェクトのアクセスが解除される (たとえば，ファイルが閉じられる) まで継続します。 セキュリティ管理者とオブジェクトに対する制御アクセス権を持つユーザは，アラーム用 ACE または監査用 ACE をオブジェクトに追加することにより，オブジェクトのクラス全体を監査するのではなく，特定のオブジェクトに監査対象を絞ることができます ( 3.10.2 項 「重要ファイルへのアクセス制御エントリ (ACE) の追加」を参照)。 ユーザは監査用 ACE を自分が所有するファイルまたは制御アクセス権を持つファイルに追加できますが，事前にセキュリティ管理者に相談することをお勧めします。 オブジェクト・クラスの場合と同じように，監査メッセージを生成させるには，セキュリティ管理者が ACL の監査カテゴリを有効にする必要があります。 [1] オブジェクトの所有者 UIC がゼロの場合は，保護コードがチェックされません。 ACL に識別子用 ACE がない場合に限り，ユーザはオブジェクトに対する制御アクセス権以外のすべてを許可されます。 識別子用 ACE がある場合は，ACL または特権によって明示的にアクセス権を与える必要があります。 [2] 識別子用 ACE に Default 属性があると，その ACE はアクセス評価時に無視されます。 4.4.7 項 「ファイルの継承方式の設定」を参照してください。 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||
|
|||||||||||||||
