| 前へ | 次へ | 目次 | 索引 |
この項では，ACL (アクセス制御リスト) を使用して，プロジェクト・アカウントを設定する方法について説明します。アクセス制御リストを使用することによって，プロジェクト・グループのメンバが共用するファイルのアクセスを制御します。 ACL を用いたアカウントの設定についての詳細は，『OpenVMS Guide to System Security』を参照してください。
まず，このプロジェクト・アカウント用ライト・データベースに識別子を追加します。ライト・データベースに識別子を追加するためには， AUTHORIZE の ADD/IDENTIFIER コマンドを使用します。次に，AUTHORIZE の GRANT/IDENTIFIER コマンドを使用して，ユーザを既存の ACL 識別子の所有者として関連付けます。こうして，このプロジェクトの識別子を持つすべてのユーザはこのプロジェクトのディスク空間を使用できます。
また，プロジェクト識別子に Resource 属性を割り当てることによって，個々のユーザではなく，プロジェクトにディスク空間を割り当てるように，プロジェクト・アカウントを設定することもことができます。
次は，プロジェクト・アカウントを設定する手順を次に示します。
$ RUN SYS$SYSTEM:AUTHORIZE
UAF> ADD/IDENTIFIER KITE_FLYING/ATTRIBUTES=RESOURCE
{message}
UAF> GRANT/IDENTIFIER KITE_FLYING GEORGE/ATTRIBUTES=RESOURCE
{message}
UAF> GRANT/IDENTIFIER KITE_FLYING LINDORF/ATTRIBUTES=RESOURCE
{message}
UAF> EXIT
|
$ RUN SYS$SYSTEM:SYSMAN SYSMAN> DISKQUOTA ADD KITE_FLYING/PERMQUOTA=2000/OVERDRAFT=200 SYSMAN> EXIT |
$ CREATE/DIRECTORY [KITE_FLYING]/BY_OWNER=[KITE_FLYING] |
$ SET SECURITY [000000]KITE_FLYING.DIR;1 - _$ /ACL=((DEFAULT_PROTECTION,S:RWED,O:RWED,G,W) - _$ (IDENTIFIER=KITE_FLYING, ACCESS=READ+WRITE+EXECUTE), - _$ (IDENTIFIER=KITE_FLYING,OPTIONS=DEFAULT,ACCESS=READ+WRITE+EXECUTE)) |
ディレクトリとファイル (KITE_FLYING) の所有者識別子がプロジェクト・メンバの UIC と一致することはないため，アクセス権は ACL エントリを介して付与する必要があります。つまり，通常のユーザからのアクセスは，UIC に基づく保護マスクを介してしか行えません。指定された ACL の最初の ACE は，プロジェクト・メンバ全員にディレクトリに対する読み込み，書き込み，および実行権を付与しています。そして 2 番目の ACE は，ディレクトリに作成されたすべてのファイルに対する読み込み，書き込み，および実行権を同じプロジェクト・メンバの全員に付与しています。
プロジェクト・メンバは，他のメンバの作成したファイルを削除したり，制御したりすることはできません。ただし，ファイル・システムは， UIC に基づく保護マスクの OWNER フィールドに指定されたアクセス権の他に，作成者制御アクセス権を付与する省略時の ACL エントリも提供するため，各メンバがそのディレクトリに作成したファイルに対してすべてのアクセス権を持ちます。この ACE が生じるのは，作成したファイルの所有者が作成者の UIC と一致しない場合だけです。
たとえば，LINDORF というユーザが [KITE_FLYING]THURSDAY.TXT というファイルを作成した場合，そのファイルは省略時の設定では次の内容のアクセス制御リストを受け取ります。
(IDENTIFIER=LINDORF,OPTIONS=NOPROPAGATE, ACCESS=READ+WRITE+EXECUTE+CONTROL) (IDENTIFIER=KITE_FLYING,ACCESS=READ+WRITE+EXECUTE) |
ACL エディタの Creator ACE コマンドを使って， Creator ACE を割り当てたディレクトリ内に作成したファイルの ACL に， ACE を追加することができます。 Creator ACE は，次の条件が成立するときだけ適用されます。
Creator ACE についての詳細は，『Compaq OpenVMS システム管理ユーティリティ・リファレンス・マニュアル』と『OpenVMS VAX Guide to System Security』を参照してください。
7.9.3 ネットワーク代理アカウント
ネットワーク代理アカウントとは，ネットワーク上の遠隔ノードのユーザが別のノードのローカル・アカウントを介してデータにアクセスすることを可能にするアカウントです。代理アカウントは，遠隔ノードの 1 人または複数のユーザに特定のファイルに対するアクセス権を付与したいが，私用アカウントを与える必要まではないといった場合に有効です。通常，代理アカウントは制約付きアカウントとして設定します。また代理アカウントの登録と制御は， AUTHORIZE ユーティリティを使って行います。
代理アカウントを使用すれば，遠隔ノード上の 1 人または複数のユーザに対して，ローカルのシステム上の特定のアカウントからデータをアクセスする DCL コマンドの入力を許可できます。代理アカウントは，ローカルのシステムにログインしなくても，あるいは，アクセス制御文字列を使用しなくても，特定のローカルのデータなら遠隔ノード上のユーザでもアクセスできます。遠隔ユーザはローカルのアカウントと同じファイル・アクセス権を持ち，さらには，ローカル・アカウントの省略時の特権も持つと想定されます。以降の項では，代理アカウントを設定する手順を説明します。
複数のバージョンが混在した OpenVAX Cluster システムで，すべての代理データベースの一貫性を保つには，次のいずれかのシステムからすべての代理データベース変更を実行する必要があります。
この制限を守ると，NET$PROXY.DAT データベースが正しい代理情報で更新されます。
代理アカウントのさらに詳しい内容については，『OpenVMS Guide to System Security』を参照してください。
7.9.4 ネットワーク代理登録ファイルの作成
この節は，DECnet フェーズ IV と DECnet-Plus におけるネットワーク・プロキシについて説明します。 TCP/IP サービスを使用する場合のプロキシとユーザ認証の詳細については， 『Compaq TCP/IP Services for OpenVMS Management』 を参照してください。 |
代理アカウントは，遠隔ノードのユーザがローカル・ノードにアカウントを持っているかのように，ローカル・ノードにログインすることを可能にするアカウントです。代理アカウントは，AUTHORIZE ユーティリティを使って作成および保守します。 AUTHORIZE ユーティリティについての詳細は，『Compaq OpenVMS システム管理ユーティリティ・リファレンス・マニュアル』を参照してください。
OpenVMS システムの場合，次の情報が 2 つの代理登録ファイル NETPROXY.DAT および NET$PROXY.DAT に格納されています。
NETPROXY.DAT または NET$PROXY.DAT のいずれかを削除すると， DECnet for OpenVMS Phase IV が稼動しているシステム上での代理アクセスの機能が正常に働かなくなります。また，ALL-IN-1 など，多くのアプリケーションの動作に NETPROXY.DAT が必要です。 |
ローカル・システムの SYSUAF.DATA ファイルは，代理アカウントをユーザ・アカウントに関連付ける必要があります。したがって，UAF には，代理アカウント用に「標準アクセス」アカウントを登録しておきます。たとえば，他のシステムのユーザからの入力を利用して，マーケティングの報告書を作成するユーザ・グループがあるとします。そこで，REMOTE_MKT という名前で，ローカル・システムのいくつかのデータ・ファイルに対するアクセスのみ許可するアカウントを登録します。
この場合，SYSUAF.DAT の REMOTE_MKT アカウントには，マーケティング・グループに割り当てたのと同じグループ番号と省略時の特権を割り当てます。こうすれば，遠隔側の寄稿者はマーケティング・グループのユーザが「所有」していて，グループ・アクセスが禁止されていない任意のデータ・ファイルにアクセスすることができます。
AUTHORIZE コマンド CREATE/PROXY を使用して，次のようにネットワーク代理登録ファイルを作成および初期化します。
UAF> CREATE/PROXY |
代理アカウントは，ネットワーク代理登録ファイルにエントリを追加することによって作成します。エントリを作成することによって，遠隔ノードのユーザはローカル・ノードのユーザと等価になります。
代理アカウントを追加するコマンド構文は次のとおりです。
ADD/PROXY ノード名::遠隔ユーザ名 ローカル・ユーザ名 /DEFAULT [,...] |
遠隔ユーザには，省略時の代理アカウント 1 つと代替代理アカウント 15 個の，合計 16 個までのローカル・アカウントへのアクセスを許可することができます。省略時の代理アカウントを指定する場合は，/DEFAULT 修飾子を使用してください。
UAF> ADD/PROXY HAL::WALTER REMOTE_MKT/DEFAULT,PROXY2,PROXY3 |
ローカル・ノードに REMOTE_MKT，PROXY2，PROXY3 という 3 つのアカウントがすでに作成されていると仮定する。この例では，HAL という遠隔ノードの WALTER というユーザが，ローカル・ノードの REMOTE_MKT アカウントを介してデータにアクセスする権限を取得している。つまり，ユーザ WALTER は，REMOTE_MKT がローカルにアクセス可能なデータであれば，自分のノードからアクセスすることがでる。PROXY2 または PROXY3 を介してデータにアクセスする場合，WALTER はネットワーク・ファイル操作に使用する DCL コマンドのアクセス制御文字列に目的の代理アカウントを指定する必要がある。
遠隔ユーザはローカル・ユーザと同じ特権を受け取るため，特殊な特権を持つローカル・アカウントに代理アカウントを関連付けないでください。遠隔ユーザに特別なアクセス権を付与することは，システムの機密保護から見て脅威になります。 |
UAF> ADD/PROXY RSTS32::[360,54] GENERIC/DEFAULT |
UAF> ADD/PROXY HAL::* */DEFAULT |
このコマンドによって，HAL という遠隔ノード上のすべてのユーザが，ユーザのローカル・システムで，遠隔と同じ名前のアカウントにアクセスできる。
同様に，1 人のユーザにのみ，このようなアクセスを許可することもできる。
UAF> ADD/PROXY HAL::BARBARA */DEFAULT |
UAF> ADD/PROXY RUBY::DELAPORT DELAPORT/DEFAULT,SYSTEM %UAF-I-NAFADDMSG, proxy from OMNI:.US.RUBY::DELAPORT to DELAPORT added %UAF-I-NAFADDMSG, proxy from OMNI:.US.RUBY::DELAPORT to SYSTEM added |
この例は，RUBY::DELAPORT からの代理アクセスを，ローカル・アカウント DELAPORT (省略時の値) および SYSTEM に追加している。
システムはノード同義語を，DECnet for OpenVMS で使用したり，レイヤード製品の下位互換性を保つために NETPROXY.DAT に追加格納している。
代理アカウントを削除するには，AUTHORIZE コマンド REMOVE/PROXY を使用します。
UAF> REMOVE/PROXY RUBY::DELAPORT SYSTEM |
このコマンドは，RUBY::DELAPORT からローカル SYSTEM アカウントへの代理アクセスを削除します。
7.9.7 代理アカウントの表示
代理アカウントは，AUTHORIZE コマンド SHOW/PROXY を使用して表示できます。このコマンドでは最高 1024 文字までを処理することができますが，表示するのはノード名の最初の255 文字だけです。
次の例は，RUBY::DELAPORT からローカル・アカウント DELAPORT への代理アクセスが，ネットワーク代理登録ファイルに省略時の設定として追加されていることを仮定しています。 2 番目の例では，DECnet-Plus を使用した場合の RUBY::DELAPORT と同等の内容を示しています。
UAF> SHOW/PROXY *::* |
RUBY::DELAPORT
DELAPORT (D)
|
(D) は DELAPORT が省略時の値であることを示している。
UAF> SHOW/PROXY *::* |
OMNI:.US.RUBY::DELAPORT
DELAPORT (D)
|
(D) は DELAPORT が省略時の値であることを示す。
SHOW/PROXY コマンドで /OLD 修飾子を使用すると，情報を旧フォーマットの NETPROXY.DAT データベースで表示できる。
UAF> SHOW/PROXY/OLD *::* |
代理ログイン要求が起こると，システムは必ず関連ノードの代理アクセスが有効になっているかチェックします。省略時の設定では，すべてのノードが両方向とも有効です。
DECnet for OpenVMS が稼働しているシステムの場合，ネットワーク制御プログラム (NCP) を使用して代理アクセスを変更または削除することができます。 NCP を使用して代理アクセスを制御する方法についての詳細は，『DECnet for OpenVMS Networking Manual』を参照してください。
DECnet-Plus ソフトウェアが稼動しているシステムの場合，ネットワーク制御言語ユーティリティ (NCL) を使用して代理アクセスを変更できます。 NCL の使用方法については， 『DECnet-Plus Network Control Language Reference』 を参照してください。
| 前へ | 次へ | 目次 | 索引 |