第13章 ネットワーク環境におけるセキュリティ

13.1.1 セキュリティ確保のための要件

ネットワーク環境におけるセキュリティを確保するには，3 つの重要な要件があります。

図 13-1 ネットワークにおける参照モニタ

13.1.2 ネットワークにおける監査

セキュリティ管理者は，SET AUDIT コマンドを使用して特定のイベント・クラスを有効にすることで，ネットワークの状態を監査することができます。 監査できる内容は次のとおりです。

13.2.1 明示的アクセス制御の使用

ユーザは，明示的アクセス制御情報を指定することにより，リモート・ノード上で DCL コマンドおよび NCP コマンドを実行できます。 明示的アクセス制御情報は，ユーザ名とパスワードが含まれており，リモート・システムの特定のアカウントへのアクセスを可能にします。 明示的アクセス制御情報を指定するには，標準的な OpenVMS ノード指定を使用する方法と，NCP コマンドを使用する方法があります。

13.2.2 代理ログインの使用

代理ログインを使用すると，リモート・ノードにログインしたユーザが，アクセス制御情報を指定せずにローカル・ノードの特定のアカウントに自動的にログインできるようになります。 代理ログインは，会話型ログインとは異なります。 代理ログインの場合，コピー操作など，特定のネットワーク・アクセス操作を実行できます。 一方，会話型ログインの場合，ユーザが会話型の操作を実行するには，ユーザ名とパスワードを入力する必要があります。

ローカル・ノードに代理ログインを設定するには，リモート・ユーザは，ローカルのユーザ名にマッピングされるデフォルトの代理アカウントをローカル・ノード上に持っている必要があります。 代理ログインしたリモート・ユーザは，ローカル・ユーザ名と同じファイル・アクセス権，ライト，特権を継承します。 代理ログインのケーパビリティを利用して，セキュリティを高めることができます。 なぜなら，代理ログインでは，ネットワーク経由で送信されるノード指定，および，コマンド・プロシージャに格納されるノード指定に，明示的アクセス制御情報を指定する必要性を最小限に抑えることができるためです。

ネットワーク・アプリケーションにも代理ログイン・アクセスを割り当てることができます。

評価済みの構成でアクセス制御文字列を使用することは許可されていません。 評価済み構成では，代理ログイン・アカウントを使用してください。

13.2.3 デフォルト・アプリケーション・アカウントの使用

ネットワーク・アプリケーション専用のアクセス制御のもう 1 つの形態に，アクセス制御情報を送信しないリモート・ノードからの着信接続で使用されるデフォルト・アカウント情報があります。 リモート・ノードがアクセス制御情報を指定しないため，ローカル・ノードは，アプリケーションについて指定した接続用のデフォルト情報を使用します。

次のコマンドを使用して，アプリケーションに使用するデフォルトのアクセス制御情報をネットワーク構成データベースに格納できます。

NCP> SET OBJECT FAL USER JILL

13.3.1 代理アクセスに関する特別なセキュリティ対策

代理アクセスは，関係するシステムの登録データベースどうしの選択的なマージです。 そのため，そのセキュリティは，最もセキュリティの弱いノードと同じ水準です。

代理アクセスでは，ネットワーク経由でパスワードを送信せずに済みますが，パーソナル・コンピュータが，許可されているノードのいずれかになりすまして代理ログインを迂回することは可能です。 このため，次の手続きを実施します。

13.3.2 代理データベースの設定

リモート・ユーザからの接続要求にアクセス制御情報が含まれていない場合，代理アクセスを認めるには次の条件を満たす必要があります。

代理ログインの使用の制御は，ローカル・ノードでできます。 AUTHORIZE を使用して，パーマネント代理データベースの作成，変更を行います。

デフォルトのネットワーク代理登録ファイルは，NET$PROXY.DAT です。 ただし，AUTHORIZE は，互換性，多くのレイヤード・プロダクトのサポート，および DECnet for OpenVMS (Phase IV) ノード名の変換に使用するために NETPROXY.DAT ファイルも維持しています。

それぞれのネットワーク代理エントリでは，1 つのリモート・ユーザをローカル・ノード上の複数の代理ユーザ名 (1 つのデフォルト代理ユーザ名と最大 15 の追加代理ユーザ名) にマッピングできます。 1 つのノードとログイン名から複数の代理アカウントにアクセスする予定の場合は，どの代理アカウントをデフォルトにするかを指定します。 代理データベースのエントリは，nodename::username または nodename::[group,member] という形式でユーザを表します。

たとえば，ローカル・ノードに代理ファイルを作成し，Boston というリモート・ノード上の Martin というユーザをローカル・ノードの Allen というユーザにマッピングする，デフォルト代理エントリを追加するには，次のコマンドを入力します。

$ SET DEFAULT SYS$SYSTEM
$ RUN AUTHORIZE
UAF> CREATE/PROXY
UAF> ADD/PROXY BOSTON::MARTIN ALLEN/DEFAULT
UAF> EXIT

同様に，リモート・ノードのシステム管理者は，そのノードの特定のアカウントに対する代理アクセスが可能なネットワーク・ユーザの代理データベースを作成し，管理することができます。 表 13-1 「ネットワーク代理アクセスの管理に使用する AUTHORIZE コマンド」は，代理データベースの管理に使用する AUTHORIZE コマンドをまとめたものです。

13.3.2.1 着信代理アクセスの有効化および無効化

ローカル・ノードに対する代理アクセスおよび特定のアプリケーションに対する代理アクセスは制御できます。

ノードへの代理アクセスの制御

ローカル・ノードへの代理接続を認めるには，次に示すコマンドを使用して，エグゼキュータ・データベースに格納されている着信代理属性を設定します。

NCP> SET EXECUTOR INCOMING PROXY ENABLE

ローカル・ノードへの代理接続を拒否するには，次のコマンドを使用して，発信代理属性を設定します。

NCP> SET EXECUTOR INCOMING PROXY DISABLE

ノードへの代理アクセスが無効になっている場合，システムはすべての代理接続要求を無視します。

発信ノードについても，接続要求メッセージで代理データが伝送されるように，同様の手順を実行する必要があります。 ノード，および代理を使用する予定のあるすべてのアプリケーションの両方について，代理属性を設定します。 たとえば，次のようにして設定します。

NCP> SET EXECUTOR OUTGOING PROXY ENABLE NCP> SET OBJECT MAIL PROXY BOTH NCP> SET OBJECT MAIL PROXY INCOMING NCP> SET OBJECT MAIL PROXY OUTGOING

一般に，発信代理接続を有効にする方法は，接続メッセージに開始ユーザ名が挿入されるため，よい方法といえます。 これは，ターゲット・ノードがオブジェクトに対して代理アクセスを有効にしていない場合であっても同様です。 そうしておけば，ユーザ名がターゲット・ノードの会計情報ログおよび監査ログに記録されます。 ただし，ごく一部の DECnet アプリケーションは，接続メッセージのための領域をユーザ名でなくアプリケーション情報に使用するなど，非代理形式の接続メッセージを使用するため，発信代理接続が有効になっていると機能しないことがあります。

アプリケーションへの代理アクセスの制御

特定のアプリケーションへの代理アクセスを許可するには，ノードとアプリケーションの両方について代理アクセスを有効にする必要があります。 加えて，アプリケーションの名前を SET OBJECT コマンドを使用して指定します。 たとえば，NML というアプリケーションへの代理アクセスを有効にするには，次のコマンドを実行します。

NCP> SET EXECUTOR INCOMING PROXY ENABLE NCP> SET OBJECT NML INCOMING PROXY ENABLE

アプリケーションへの代理アクセスを無効にするには，SET OBJECT コマンドを使用してアプリケーションを指定し，着信代理属性を無効に設定します。 たとえば，FAL というアプリケーションへの代理アクセスを無効にするには，次のコマンドを実行します。

NCP> SET OBJECT FAL INCOMING PROXY DISABLE

アプリケーションへの着信代理アクセスが有効になっていて，ノードへの代理アクセスが無効に設定されている場合，当該システムはそのアプリケーションへのすべての代理アクセスを無視します。

13.3.2.2 代理アクセスの削除

システムへの代理アクセスは，不要になったら削除します。 代理アクセスを削除するには，AUTHORIZE を起動し，次のコマンドを入力します。

UAF> REMOVE/PROXY BOSTON::MARTIN

13.3.3 代理アカウントの例

例 13-1 「代理アカウントの例」は，WALNUT という名前のノードのセキュリティ管理者が，GENACCESS という名称の汎用アクセス・アカウントを作成する場合の例です。 同時に，この管理者は，BIRCH というノードの KMahogany，PSumac，および WPine という 3 人のユーザと，WILLOW というノード RDogwood と WCherry という 2 人のユーザに対して，代理ログインを許可する手順を実行します。 この時点では，ネットワーク代理登録ファイルは存在していないものとします。

例 13-1 代理アカウントの例

$ SET DEFAULT SYS$SYSTEM $ RUN AUTHORIZE UAF> ADD GENACCESS /PASSWORD=WHYNADGUM/UIC=[236,043] - _UAF> /DEVICE=STAFFDEV/DIRECTORY=[GENACCESS] - _UAF> /OWNER="Security Mgmt"/ACCOUNT=SEC - _UAF> /FLAGS=(DISWELCOME,DISNEWMAIL,GENPWD,DISMAIL) - _UAF> /NOBATCH/NOINTERACTIVE/MAXDETACH=8 - _UAF> /LGICMD=LOGIN/MAXACCTJOBS=10 %UAF-I-ADDMSG, user record successfully added %UAF-I-RDBADDMSGU, identifier GENACCESS value [000236,000043] added to rights database %UAF-I-RDBADDMSGU, identifier SEC value [000236,177777] added to rights database UAF> CREATE/PROXY UAF> ADD/PROXY BIRCH::KMAHOGANY GENACCESS/DEFAULT %UAF-I-NAFADDMSG, proxy from OMNI:.BOSTON.BIRCH::KMAHOGANY to GENACCESS added UAF> ADD/PROXY BIRCH::PSUMAC GENACCESS/DEFAULT %UAF-I-NAFADDMSG, proxy from OMNI:.BOSTON.BIRCH::PSUMAC to GENACCESS added UAF> ADD/PROXY BIRCH::WPINE GENACCESS/DEFAULT %UAF-I-NAFADDMSG, proxy from OMNI:.BOSTON.BIRCH::WPINE to GENACCESS added UAF> ADD/PROXY WILLOW::RDOGWOOD GENACCESS/DEFAULT %UAF-I-NAFADDMSG, proxy from OMNI:.BOSTON.WILLOW::RDOGWOOD to GENACCESS added UAF> ADD/PROXY WILLOW::WCHERRY GENACCESS/DEFAULT %UAF-I-NAFADDMSG, proxy from OMNI:.BOSTON.WILLOW::WCHERRY to GENACCESS added UAF> SHOW/PROXY *::* Default proxies are flagged with a (D) OMNI:.BOSTON.BIRCH::KMAHOGANY GENACCESS (D) OMNI:.BOSTON.BIRCH ::PSUMAC GENACCESS (D) OMNI:.BOSTON.BIRCH ::WPINE GENACCESS (D) OMNI:.BOSTON.WILLOW ::RDOGWOOD GENACCESS (D) OMNI:.BOSTON.WILLOW ::WCHERRY GENACCESS (D) UAF> EXIT {messages} $ DIRECTORY/SECURITY SYS$STAFF:[000000]GENACCESS.DIR . . . $ DIRECTORY/SECURITY SYS$STAFF:[GENACCESS]LOGIN.COM . . .

13.4.1 ネットワーク・オブジェクトのまとめ

ネットワーク・オブジェクトに適用するアクセス制御を決める前に，OpenVMS オペレーティング・システムが提供するネットワーク・オブジェクトの機能を理解する必要があります。 この節では，最も一般的なネットワーク・オブジェクトについて説明します。

FAL

ファイル・アクセス・リスナ (FAL) とは，リモート・ファイル・アクセス機能のことです。 具体的には，ローカル・ノードのファイルに対するリモート・ファイル・アクセス要求を受け取って処理するイメージのことを指します。

一般 FAL アクセスは，よほどの理由がない限り使用しないでください。 無制限アクセスでは，ワールド・アクセス許可が設定されているすべてのファイルに対する一般ネットワーク・アクセスが可能になります。 また，ワールド・ライト・アクセスが設定されているディレクトリでのリモート・ユーザによるファイルの作成が可能になります。

セキュリティ要件が高いサイト，またはアクセスが想定されるすべてのユーザを認知することが困難なサイトでは，FAL アカウントを作成するべきではありません。 このようなサイトでは，ユーザのアクセスを制御するために，特定の目的のための代理アカウントを設定することができます ( 13.3 項 「代理アクセス制御」参照)。

MAIL

MAIL は，OpenVMS システムにおいてパーソナル・メール・サービスを提供するイメージです。 一部の例外を除いて，MAIL オブジェクトにはシステムへの一般アクセスを許可します。

MIRROR

MIRROR は，特定の形式のループバック・テストに使用するイメージです。 たとえば，MIRROR は，UETP テスト・パッケージの DECnet フェーズで実行されます。

MOM

MOM とは，保守操作モジュール (Maintenance Operations Module) のことです。 MOM イメージは，無人システムをダウンライン・ロードし，OpenVMS ノードからターゲット・ノードにオペレーティング・システム・ファイル・イメージのコピーを転送します。 MOM オブジェクトは，システム・インストール時に設定されます。

NML

NML とは，ネットワーク管理リスナ (Network Management Listener) のことです。 NML へのアクセスが可能なリモート・ユーザは，NCP TELL コマンドを使用して，DECnet データベースからネットワーク情報を収集して報告することができます。

PHONE

PHONE とは，リモート OpenVMS システム上のユーザとの間でオンラインの会話を可能にするイメージです。 PHONE に対してデフォルトの DECnet アクセスを許可する場合，ネットワーク内の誰もが現在ローカル・システムにログインしているユーザの一覧を取得でき，そのユーザ名の一覧を使用してログインを試みる可能性もあるので注意が必要です。

TASK

TASK オブジェクトでは，デフォルトの DECnet アカウントを介した任意のコマンド・プロシージャ (侵入の際に使用される恐れのあるものも含まれます) のシステム上での実行が許可されます。

システムに対するデフォルトの DECnet アクセスを許可しない場合，または TASK オブジェクトへのデフォルトの DECnet アクセスを無効にしている場合は，アクセス制御文字列または代理アクセスを使用することで，リモート・ユーザが作成したコマンド・プロシージャ (タスク) をシステム上で実行させることが可能です。

VPM

VPM とは，仮想性能モニタ・サーバ (Virtual Performance Monitor Server) のことです。 VPM へのアクセスは，モニタ・ユーティリティ (MONITOR) のクラスタ監視機能を使用する場合に必要です。

13.4.2 手作業でのネットワーク・オブジェクトの設定

NETCONFIG.COM コマンド・プロシージャは，システム上のネットワーク・オブジェクトを自動的に設定します。 また，NETCONFIG_UPDATE.COM コマンド・プロシージャは，ネットワーク・オブジェクトを自動的に更新します。

これらのコマンド・プロシージャを使用しない場合は，次の手順を実行することで，特定のオブジェクトに対するネットワーク・アクセスを許可することができます。

表 13-2 「ネットワーク・オブジェクトのデフォルト設定」 は，ネットワーク・オブジェクトのデフォルト設定です。

例 13-2 MAIL$SERVER アカウントの UAF レコード

Username: MAIL$SERVER Owner: MAIL$SERVER Account: MAIL$SERVER DEFAULT UIC: [376,374] ([DECNET,MAIL$SERVER]) CLI: DCL Tables: Default: SYS$SPECIFIC:[MAIL$SERVER] LGICMD: Login Flags: Restricted Primary days: Mon Tue Wed Thu Fri Sat Sun Secondary days: Primary 000000000011111111112222 Secondary 000000000011111111112222 Day Hours 012345678901234567890123 Day Hours 012345678901234567890123 Network: ##### Full access ###### ##### Full access ###### Batch: ----- No access ------ ----- No access ------ Local: ----- No access ------ ----- No access ------ Dialup: ----- No access ------ ----- No access ------ Remote: ----- No access ------ ----- No access ------ Expiration: (none) Pwdminimum: 6 Login Fails: 0 Pwdlifetime: (none) Pwdchange: (none) Last Login: (none) (interactive), (none) (non-interactive) Maxjobs: 0 Fillm: 16 Bytlm: 12480 Maxacctjobs: 0 Shrfillm: 0 Pbytlm: 0 Maxdetach: 0 BIOlm: 12 JTquota: 1024 Prclm: 0 DIOlm: 6 WSdef: 180 Prio: 4 ASTlm: 16 WSquo: 200 Queprio: 0 TQElm: 10 WSextent: 0 CPU: (none) Enqlm: 20 Pgflquo: 25600 Authorized Privileges: TMPMBX NETMBX Default Privileges: TMPMBX NETMBX

13.4.3 システムへのデフォルトの DECnet アクセスの削除

デフォルトの DECnet アカウントは，厳しいセキュリティ要件を必要としないシステムに適しています ( 13.4 項 「DECnet アプリケーション (オブジェクト) アカウントの使用」参照)。 中～高レベルのセキュリティ要件を必要とするサイトでは，個々のネットワーク・オブジェクトについてアカウントの設定が完了したら，システムへのデフォルトの DECnet アクセスを削除してください。

	注意: この節で説明したようにデフォルトの DECNET アカウントの削除を実行する前に，NCP の SHOW KNOWN OBJECTS コマンドと登録ユーティリティ (AUTHORIZE) を使用して，すべてのネットワーク・オブジェクトのネットワーク・アカウント，およびネットワーク・オブジェクトを使用するレイヤード・プロダクトのネットワーク・アカウントが，システム・ユーザ登録ファイル (SYSUAF.DAT) に設定されていることを確認します。 設定されていない場合，ネットワーク・オブジェクト，およびネットワーク・オブジェクトを使用するレイヤード・プロダクトが想定どおりに動作しない場合があります。

デフォルトの DECnet アクセスを削除するには，ネットワーク構成データベース内の DECNET アカウントへのアクセスを削除し，SYSUAF から DECNET アカウントを削除します。

デフォルトの DECnet アクセスの削除

次の NCP コマンドを実行して，ネットワーク・エグゼキュータ・データベースからデフォルトの DECnet アクセスを削除します。

NCP> DEFINE EXECUTOR NONPRIVILEGED USER DEFAULT_DECNET
NCP> PURGE EXECUTOR NONPRIVILEGED PASSWORD

最初のコマンドに含まれている DEFAULT_DECNET というユーザは，監査のためにのみ指定する，存在しないユーザ・アカウントです。 (存在しない DEFAULT_DECNET アカウントを使用してシステムへのアクセスが試みられるたびに，ネットワーク・ログイン失敗のメッセージがセキュリティ監査ログ・ファイルに書き込まれます。 )

DECNET アカウントの削除

AUTHORIZE を使用して，次に示すように，SYSUAF から DECNET アカウントを削除します。

$ SET DEFAULT SYS$SYSTEM
$ RUN AUTHORIZE
UAF> REMOVE DECNET
UAF> EXIT

[DECNET] ディレクトリ構造内に存在するすべてのファイルを削除します。

運用時構成データベースの変更

変更をすぐに反映するには，次に示す NCP コマンドを使用して運用時データベースを変更します。

NCP> SET EXECUTOR NONPRIVILEGED USER DEFAULT_DECNET
NCP> CLEAR EXECUTOR NONPRIVILEGED PASSWORD

13.4.4 リモート・オブジェクト接続の特権要件の設定

特定の特権を選択することで，ネットワーク設定時に指定した DECnet オブジェクトの使用を制御できます。 この場合，特権 DECnet オブジェクトへ接続する操作，および発信 DECnet オブジェクトを使用する操作は特権操作となります。

たとえば，次のコマンドを実行すると，リモート・オブジェクトである MAIL への DECnet 接続を開始するユーザは，OPER 特権と SYSNAM 特権を持っていなければならないという要件が設定されます。

NCP> DEFINE OBJECT MAIL OUTGOING CONNECT PRIVILEGES OPER,SYSNAM

この仕組みは，特定の DECnet アプリケーションへのアクセスを特権ユーザまたは特権プログラムに限定する便利な方法です。 ただし，これが有効性を発揮するには，特権の要件をネットワーク内のすべてのノードに一貫して適用する必要があります。

13.5.1 動的非同期接続の確立

動的非同期 DECnet 接続は，2 つのノードを結ぶ一時的な接続のことで，通常，モデムを利用して，電話回線経由で行われます。 接続の両端の回線は，ターミナル回線から動的非同期 DECnet 回線に切り換えることができます。 動的非同期回線の設定は，動的接続の確立時に DECnet によって自動的に行われます。 動的非同期接続は通常，電話による通話が行われている間のみ維持されます。

	注意: OpenVMS ノードに対する動的非同期接続は，DECnet 非同期 DDCMP プロトコルをサポートする任意のノードから開始できます。

OpenVMS ノードでは，ローカル・ノードにおいてネットワークを有効にする (手順 3) 前に，動的非同期接続プロセスの手順 1 および手順 2 を実行できます。 以後の手順 (手順 4 以降) は，必ず回線が DECnet に切り替わっているときに実行する必要があります。

以下に示す手順に従って，動的非同期 DECnet 接続を確立します。 この手順では，ローカルの OpenVMS ノードが接続を開始し，DECnet 用にターミナル回線を有効にします。 接続は，NETMBX 特権を持つアカウントのある OpenVMS に対して行う必要があります。 また，この手順は，動的非同期 DECnet 接続を正常に確立するために，リモートの OpenVMS ノードのシステム管理者が実行しなければならない処理も示しています。

図 13-2 「典型的な動的非同期接続」は，動的非同期接続が確立する様子を示したものです。 接続の両端で入力する必要のあるコマンドは， 例 13-3 「動的非同期接続のコマンドの例」のとおりです。

図 13-2 典型的な動的非同期接続

例 13-3 動的非同期接続のコマンドの例

ローカル OpenVMS ノード (LOCALA) とリモート OpenVMS ノード (REMOTC) の 両方で実行するコマンド：

$ RUN SYS$SYSTEM:SYSGEN SYSGEN> CONNECT NOA0/NOADAPTER SYSGEN> EXIT $ INSTALL:=$SYS$SYSTEM:INSTALL $ INSTALL/COMMAND INSTALL> CREATE SYS$LIBRARY:DYNSWITCH/SHARE/PROTECT/HEADER/OPEN INSTALL> EXIT

リモート・ノード (REMOTC) で実行するコマンド：

$ RUN SYS$SYSTEM:SYSGEN SYSGEN> CONNECT VTA0/NOADAPTER/DRIVER=TTDRIVER SYSGEN> EXIT $ SET TERMINAL/EIGHT_BIT/PERMANENT/MODEM/DIALUP/DISCONNECT TTB0: $ RUN SYS$SYSTEM:NCP NCP> DEFINE NODE LOCALA RECEIVE PASSWORD PASSA INBOUND ENDNODE NCP> SET NODE LOCALA ALL NCP> EXIT

ローカル・ノード (LOCALA) で実行するコマンド：

$ RUN SYS$SYSTEM:NCP NCP> DEFINE NODE REMOTC TRANSMIT PASSWORD PASSA NCP> SET NODE REMOTC ALL NCP> EXIT $ SET HOST/DTE/DIAL=8556543 TTA0:

! REMOTC に自動的にダイアルアップした後， ! REMOTC の自分のアカウントにログインする。

$ SET TERMINAL/PROTOCOL=DDCMP/SWITCH=DECNET %REM-S-END - control returned to LOCALA: $

13.6.1 メール・ユーティリティの使用

ユーザがテキスト・ファイルを別のユーザに転送する最も簡単な方法は，メール・ユーティリティ (MAIL) を実行し，相手ユーザにファイルを送信することです。 この方法は，パスワードを明かす必要がなく，ファイルの保護も変更されないため，比較的安全です。 受信側のユーザは，MAIL の EXCTRACT/NOHEADER コマンドに新しいファイル名を指定するだけで，自分のディレクトリにファイルのコピーを作成できます。 コピーしたファイルには，受信ユーザのデフォルトの保護が自動的に設定されます。 続いて，受信ユーザは，MAIL の DELETE コマンドを使用して，メール・ファイルからファイルを削除します。

13.6.2 ローカル・ユーザおよびリモート・ユーザのアカウントの設定

ネットワーク管理者は，特定の作業のために，ローカル・ノード上のディレクトリに対するアクセスを外部ノードの何人かのユーザに許可する必要が生じることがあります。 そのため，代理アカウントを作成し，その 1 つの代理アカウントに対して外部ユーザのアクセスを許可する代理アクセスを追加します ( 13.3.2.3 項 「代理アカウントの作成手順」参照)。 このアカウントのディレクトリに置かれているファイルを共用する必要のあるローカル・ユーザがいる場合は，それらのユーザに必要なアクセス権を与え，部外者によるアクセスから守るために，ディレクトリとファイルに ACL を適用します。

ある企業が，全従業員がアクセス可能な，営業の最新情報を蓄積した集中リポジトリを必要としているとします。

13.6.3 複数アカウントに対するリモート・ユーザの許可

少数の外部ユーザが，それぞれ異なる理由から，特別な保護が設定されているファイルへのアクセスを必要とする場合は，複数の代理アカウントへのアクセスを設定し，広範な ACL を適用します。

たとえば，数多くの支社を持つ大規模な企業の場合，個別のファイル共用目的のために複数の代理アカウントを作成することが考えられます。 中央の本社で，東部地域の 2 つのノードの 2 名の主要ユーザに対し，LEVIGRAY というプロジェクト・コード名のプロジェクト・ファイルに対する読み込みアクセス権と書き込みアクセス権，そして BETSEYHARLOW というプロジェクトのファイルへの読み込み専用アクセス権を与えることを考えているとします。 同時に，西部地域のユーザで，LEVIGRAY ファイルへの読み込みアクセス権と，BETSEYHARLOW ファイルへの読み込みおよび書き込みアクセス権が必要な 3 名のユーザも存在するとします。 中央本社の 2 名のユーザだけが，LEVIGRAY ファイルへの完全なアクセス権を持ち，そして本部の別の 2 名のユーザが BETSEYHARLOW ファイルへの完全なアクセス権を持ちます。 作業のために，この状況を表形式でまとめると， 例 13-4 「保護ファイルのネットワークにおける共用」のようになります。

例 13-4 保護ファイルのネットワークにおける共用

CENTRL::PROJ:[DESGN_PROJECTS] へのアクセス要件 所有者は [DESIGNERS,MGR] ユーザとノード サブディレクトリ LEVI サブディレクトリ BETSEY プロジェクト・ファイル プロジェクト・ファイル LEVIGRAY*.* BETSEYHARLOW*.* FRISCO::ALBION R RW FRISCO::ELTON R RW LA::IRVING R RW CENTRL::DIANTHA RWED NONE CENTRL::BRITTANIA RWED NONE CENTRL::ALBERT NONE RWED CENTRL::DELIA NONE RWED BOS::AYLMER RW R WASH::LAVINA RW R

次に示す解決方法では，CENTRL というノード上の 4 つのローカル・アカウントに加え，5 つの代理アカウントを使用し，ディレクトリ，サブディレクトリ，およびファイルに対して ACL を使用します。

ここまでで，すべての基本作業は完了です。 時間の経過とともに，サブディレクトリにファイルが追加されていきます。 そのため，Washington にいるユーザ Lavina が次の DCL コマンドを入力すると，ファイル LEVIGRAYMEM3.MEM は WASH というノードで印刷されます。

$ COPY CENTRL::LEVIGRAYMEM3.MEM LP:

しかし，ユーザ Lavina がこのファイルを編集しようとすると，このユーザは ACL によって書き込みアクセスを拒否されるため，編集操作は失敗します。

この構想に多数のユーザが関わっていた場合は，ユーザに追加の識別子を付与するのが有効です。 たとえば，LEVI サブディレクトリのファイルに対する読み込みアクセスを許可するユーザに，LEVI_READER という識別子を与えます。 識別子を追加することで，ACL を短縮できます。