Jump to content 日本-日本語
≫ お問い合わせ

OpenVMS: システム・セキュリティ・ガイド > パート III  システム管理者のためのセキュリティ

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

≫ 

OpenVMSドキュメント・ライブラリ

タイトル/目次
まえがき
Part 1:セキュリティの概要
第1章:システムセキュリティ
第2章:OpenVMSのセキュリティモデル
Part 2:一般ユーザのためのセキュリティ
第3章:システムの安全な使用
第4章:データの保護
第5章:オブジェクトクラスの詳細
Part 3:システム管理者のためのセキュリティ
第6章:システムとデータの管理
第7章:システムアクセスの管理
第8章:システムのデータと資源へのアクセス制御
第9章:暗号化機能の使用
第10章:セキュリティ監査の実施
第11章:システムのセキュリティ侵害
第12章:クラスタのセキュリティ保護
第13章:ネットワーク環境におけるセキュリティ
第14章:保護サブシステムの使用
付録A:特権の割り当て
付録B:システムファイルの保護
付録C:アラーム・メッセージ
用語集
索引
PDF
OpenVMS ホーム
ここから本文が始まります

ネットワーク環境におけるセキュリティは,単一のシステムからなる環境でのセキュリティと比較して,求められる慎重さの度合いは高くなります。 また,ネットワーク環境に共通して存在する運用上の複雑さや制御の分散化が理由で,セキュリティの確立が非常に困難です。 ネットワークの規模が大きくなればなるほど,多数のノードのセキュリティ管理者間における調整やコミュニケーションの問題もそれだけ難しくなります。

現在のネットワーク技術の制限が原因で,ネットワーク・サイトにおいて達成可能であると見込めるセキュリティのレベルには限度があります。 発生しうる問題に注意を払うことは,ネットワーク内のセキュリティの弱点を拡大しかねない運用を避けることにつながります。 この章では,ネットワークにおけるセキュリティ問題が生じる領域を明らかにし,適切な運用の実現に役立つ情報を紹介します。

次に示すものも含め,OpenVMS システムのネットワーク・ソフトウェア・オプションの詳細については,『OpenVMS システム管理者マニュアル』を参照してください。

  • HPE TCP/IP Services for OpenVMS

  • DECnet-Plus for OpenVMS (DECnet Phase V)

  • DECnet for OpenVMS (DECnet Phase IV)

13.1 ネットワーク・セキュリティの管理

ネットワーク・ソフトウェアは,次に示すように,さまざまなレベルでネットワークへのアクセスを規制します。

  • ネットワークへアクセスするための特権

    何らかのネットワーク処理を実行するネットワーク・ユーザはすべて TMPMBX 特権と NETMBX 特権を持っていなければなりません。 特権ユーザは,TMPMBX と NETMBX の他に,さまざまな特権を持っています。

  • アクセス制御

    ネットワークに属しているノードへ接続するには,ユーザには明示的なアクセス情報,代理アカウント,アプリケーション・アカウント,およびデフォルトの DECnet アカウントが必要です。 ( 13.2 項 「アクセス制御の階層」参照)

  • 同期回線または非同期回線を経由してローカル・ノードをリモート・ノードに接続するために必要なルーティング初期化パスワード ( 13.5 項 「ルーティング初期化パスワードの指定」参照)

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

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

  • 共通のセキュリティ・ポリシー

    ソース・マシン上の開始側プロセスと,開始側プロセスに代わってターゲット・マシン上で処理を行うプロセスが対応している必要があります ( 図 13-1 「ネットワークにおける参照モニタ」参照)。 この対応関係は,2 つのリファレンス・モニタで管理し,ターゲット・マシン (最終的にオブジェクトを保護するマシン) のセキュリティ・ポリシーと整合していなければなりません 。 リファレンス・モニタの説明については, 第2章 「OpenVMS のセキュリティ・モデル」  を参照してください。

  • 共用アクセス制御情報

    ターゲット・マシン上の登録データベースには,ソース・マシン上の開始側プロセスに対応する何らかのアクセス許可 (アカウントや代理など) を設定する必要があります。

  • 保護されている回線,通信線,ターミナル,およびプロセッサ

    ローカルとリモートのサブジェクトとの間の対応関係を確実に確立して認証できるように,2 つのリファレンス・モニタ (ソースとターゲット) を結ぶ保護された通信手段が必要です。

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

ネットワークにおける参照モニタ

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

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

  • NCP コマンドの使用。 各 NCP コマンド行を,実行完了時の状態も含め,監査できます。

  • 特権の使用。 ネットワーク環境の場合,特権の使用の大半は,運用時ネットワーク・データベースの変更にともなう OPER 特権の使用に関連しています。

  • 接続の開始と終了

    DECnet for OpenVMS を実行する VAX システムでは,各ネットワーク接続について,4 種類の監査が行われます。

    1. 接続を開始するソース・ノードは,最初のイベント・メッセージを記録します。

    2. 着信開始メッセージを受信するターゲット・ノードは,2 つ目のイベントを記録します。

    3. 3 つ目のイベント・メッセージは,接続を終了した側のノードが記録します。

    4. 最後のイベント・メッセージは,接続を切断された側のノードが記録します。

    着信ネットワーク接続の場合,監査メッセージには,接続を開始したユーザを示すリモート・ユーザ名が含まれています。 発信論理リンク接続の場合,リモート論理リンク識別子は常に 0 となります。

13.2 アクセス制御の階層

DECnet ノードは,リモート DECnet ノードへの接続を試みる時,リモート DECnet ノードに対してアクセス制御情報を送信します。 アクセス制御情報は,いくつかの情報源から取得できます。 次のリストは,優先順位の高いものから順に示した,アクセス制御の階層です。

  1. ローカル・ノード上のネットワーク・ユーザは,明示的にアクセス制御情報を提供できます。 ローカル・ノード上のユーザがアクセス情報を提供する場合,リモート・ノードはこのアクセス制御情報を使用します。 明示的なアクセス制御については, 13.2.1 項 「明示的アクセス制御の使用」を参照してください。

  2. ローカル・ノードは, ローカル・ノードまたはアプリケーションについて発信代理アクセスが有効になっているかどうかを調べます。 代理が有効になっていれば,ローカル・ノードは,接続要求の中に開始ユーザ名を含めて送信します。 代理がリモート・ノードでも有効になっている場合,開始ユーザが代理アクセスの権限を持っているかどうかを DECnet ソフトウェアが判断します。 代理アクセス制御については, 13.2.2 項 「代理ログインの使用」および 13.3 項 「代理アクセス制御」を参照してください。

  3. リモート・ノードは,アクセス制御が指定されておらず,代理も有効になっていないと判断した場合,構成データベースを調べます。 構成データベースにアプリケーション・ユーザ名が含まれていれば,その名前が使用されます。 デフォルト・アプリケーション・アカウントについては, 13.2.3 項 「デフォルト・アプリケーション・アカウントの使用」および 13.4 項 「DECnet アプリケーション (オブジェクト) アカウントの使用」を参照してください。

  4. 構成データベースにデフォルト・アプリケーション・ユーザ名がない場合,リモート・ノードは,デフォルトの非特権 DECnet ユーザ名情報が含まれていないかどうか構成データベースを調べます。 含まれていれば,リモート・ノードは,そのデフォルトの非特権 DECnet ユーザ名を使用します。 デフォルトの DECnet アカウントについては, 13.4 項 「DECnet アプリケーション (オブジェクト) アカウントの使用」を参照してください。

最終的に上記の情報源から情報が得られない場合,接続は失敗します。

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

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

  • OpenVMS ノード指定の場合,アクセス制御文字列は,次に示すように,リモート・アカウントのユーザ名とユーザのパスワードを二重引用符で囲んで指定します。

    NODE"username password"::disk:[directory]file.typ

    次の例では,Puterman というユーザがアクセス制御文字列を使用して,BIONEWS.MEM というファイルをコピーしています。

    $ COPY WALNUT"PUTERMAN A25D3255"::BIONEWS.MEM  BIONEWS.MEM
    

  • リモート・ノード上で NCP コマンドを実行するには,ユーザ名とパスワードを指定することでコマンドを実行できます。

    次の例では,TORONTO というリモート・ノードの MAIL アプリケーションに関するすべての特性情報を表示しています。

    NCP> TELL TORONTO USER A_JOHNSTON PASSWORD XZZOQ87 SHOW OBJECT-
    _NCP> MAIL CHARACTERISTICS
    

13.2.2 代理ログインの使用

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

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

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

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

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

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

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

NCP> SET OBJECT FAL USER JILL

13.3 代理アクセス制御

13.2.2 項 「代理ログインの使用」では,代理ログインの概念について説明しました。 代理アクセスの許可は,異なるノードまたはグループに属するユーザがシステム上のファイルを共用したいけれども,パスワードの発行や,ディレクトリとファイルの保護を W:RWE に設定するのを控えたい場合に与えることができます。 代理ログインでは,ネットワーク経由でファイルをコピーするときに,パスワードをコマンドに含める必要がありません。 また,ファイル転送のためにファイルにワールド読み込みアクセスを許可する必要もありません。 ユーザは,次に示す形式で DCL の COPY コマンドをデフォルトの代理アカウントに対して入力します。

COPY remotenode::file-spec file-spec

デフォルト以外のアカウントから代理アクセスを使用して,ネットワーク経由でファイルをコピーするには,次に示すように,DCL コマンドのアクセス制御文字列の中に代理アカウントの名前を記述します。

COPY remotenode"proxyacct"::file-spec file-spec

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

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

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

  • 機密性の高いデータに対する着信代理アクセスは有効にしないようにします。

  • 非特権代理アカウントを設定します。 アカウントに特権が必要な場合は,その特権でシステムに損害を与えられないことを確認します。 この手法は,あるノードが侵入を許した場合でも,システム間の防御壁として機能します。 代理ログインは,他のノードの非特権アカウントに対してのみ許可を与えるため,ネットワーク内のあるシステムが侵入を許しても,その損害が広がるのを抑えるのに役立つ場合があります。 サイトに高いセキュリティ要件が設定されている場合は,特権ユーザ名に対してネットワーク・アクセスやリモート・アクセスを許可しないようにしてください。

  • 代理アクセスを,ネットワーク上に常に,またはほぼ常に存在しているノードに対してのみ許可するようにします。 侵入者にとっては,ネットワークから切断されているノードになりすます方が簡単なためです。 代理アクセスの使用と,アクセス制御文字列 (パスワードを含む) がネットワークを流れる状態とのバランスをとる必要があります。 ノードになりすますことが可能なネットワーク上のワークステーションまたはパーソナル・コンピュータは,ネットワーク・メッセージを監視して,パスワードを盗むことも可能です。 最終的には,ローカル・ネットワークに接続されるすべてのノードに一定レベルの信頼性が備わるようにする必要があります。

  • ユーザの登録は慎重に行います。 ユーザの登録については,リモート・サイトのセキュリティ管理者から正式な登録要求を受け取るのが理想的です。

  • 代理アカウント用のログイン・コマンド・プロシージャを調べます。 キャプティブ・アカウントのログイン・コマンド・プロシージャについては, 7.2.4.2 項 「キャプティブ・コマンド・プロシージャのガイドライン」に示した推奨事項に必ず従うようにします。 ログイン・コマンド・プロシージャは,代理アカウントの所有者以外のユーザが所有する,確実に保護されているディレクトリに配置するようにします。 その代理アカウントを使用するユーザには,書き込みアクセスを禁止します。

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

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

  • ターゲット・ノード上の代理データベースには,リモート・ソース・ノードのノード同義語とソース・ユーザ名に一致する,ソース・ノードのノード同義語とソース・ユーザ名の組み合わせが格納されていなければなりません。 たとえば, 例 13-1 「代理アカウントの例」では,セキュリティ管理者は KMahogany の代理を追加しています。 KMahogany は Birch というノードから代理アカウントにアクセスしなければなりません。

  • ターゲット・ノードのユーザ登録ファイルには,代理データベースに格納されているターゲット・ソース・ユーザ名に一致するソース・ユーザ名が格納されていなければなりません。 例 13-1 「代理アカウントの例」では,ノード Birch の SYSUAF.DAT ファイルに KMahogany のユーザ登録レコードが含まれていると仮定しています。

  • 着信代理アクセスは,構成データベースの中でターゲット・ノードについて有効にしなければなりません。 ( 13.3.2.1 項 「着信代理アクセスの有効化および無効化」参照。 )

  • 着信代理アクセスは,構成データベースの中でターゲット・アプリケーションについて有効にしなければなりません ( 13.3.2.1 項 「着信代理アクセスの有効化および無効化」参照)。

  • 発信代理アクセスは,発信元のノード上で,そのノード自体と,代理アクセスを使用する予定のアプリケーションすべてについて有効にしなければなりません。

代理ログインの使用の制御は,ローカル・ノードでできます。 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-1 ネットワーク代理アクセスの管理に使用する AUTHORIZE コマンド

コマンド 引数説明

ADD/PROXY

node::remoteuser localuser[,...]

指定したユーザについて代理アクセスを可能にします。

CREATE/PROXY

 

ネットワーク代理登録ファイルを作成します。

LIST/PROXY

 

すべての代理アカウントとそれらのアカウントへの代理アクセスが可能なすべてのリモート・ユーザを一覧にしたリスト・ファイルを作成します。

MODIFY/PROXY

node::remoteuser

指定したユーザの代理アクセスの設定を変更します。

REMOVE/PROXY

 

指定したユーザの代理アクセスを削除します。

SHOW/PROXY

* node::remoteuser

指定したユーザについて許可されている代理アクセスを表示します。

 

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.2.3 代理アカウントの作成手順

他のノードの 1 人以上のユーザが使用する代理アカウントをローカル・ノード上に設定するには,次の手順を実行する必要があります。 アカウントを作成するときは, 13.3.1 項 「代理アクセスに関する特別なセキュリティ対策」に示したセキュリティ・ガイドラインを参照してください。

  1. アカウントの目的,名前,アクセスを許可するネットワーク・ユーザを指定します。

  2. 必要な場合は,AUTHORIZE を使用してローカル・アカウントを作成します。 アカウントが既にある場合は,/NOINTERACTIVE,/NOBATCH,および /NETWORK の制限と指定が済んでいることを確認します。

  3. アカウントの特権を確認します。 通常,代理ログイン・アカウントには特権を与えないようにします。

  4. 必要な場合は,ネットワーク代理登録ファイルを AUTHORIZE ユーティリティの CREATE/PROXY コマンドを使用して作成します。 (通常はシステムによって自動的に作成されます。 )

  5. AUTHORIZE の ADD/PROXY コマンドを使用して,代理アカウントへのアクセスが必要なすべてのリモート・ユーザを指定します。

  6. ディレクトリのデフォルトの保護設定を確認し,必要に応じてカスタマイズします。

  7. ADD コマンドの /LGICMD 修飾子に指定されているログイン・コマンド・プロシージャがあれば,それらを確認します。 キャプティブ・アカウントの場合,該当するログイン・コマンド・プロシージャが 7.2.4.2 項 「キャプティブ・コマンド・プロシージャのガイドライン」に示した推奨事項に従っていることを確認してください。 ログイン・コマンド・プロシージャは,代理アカウントの所有者以外のユーザが所有する,確実に保護されているディレクトリに配置するようにします。 その代理アカウントを使用するユーザによる書き込みアクセスを禁止するようにします。

  8. リモート・ノードのセキュリティ管理者に対し,そのリモート・ノードのどのユーザにローカル・ノードへのアクセスを許可したかを通知します。

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 DECnet アプリケーション (オブジェクト) アカウントの使用

ネットワーク・オブジェクトとは,DECnet ネットワーク内のノード間の通信が可能なシステム・プログラムおよびユーザの作成したアプリケーションのことです。 システムへのアクセスが許可されているネットワーク・オブジェクトのセットを特定し,各オブジェクトに対して適切なアクセス制御を設定する必要があります。 次の機能を使用できます。

  • DECnet オブジェクト・アカウント

    このアカウントは,システムに自動的に設定される特定のネットワーク・オブジェクト (MAIL など) 専用のアカウントです。 デフォルトの DECnet アカウントと比較して,オブジェクトへのリモート・アクセスに対するより詳細な管理が可能です。 (たとえば,リモート・ノード名またはユーザ名に応じて,オブジェクトへのアクセスを許可または拒否するログイン・コマンド・プロシージャを使用するキャプティブ・アカウントをオブジェクトに設定できます。 )

  • デフォルトの DECnet アカウント

    このアカウントは,すべてのネットワーク・オブジェクトに対してシステムへの汎用アクセスを許可します。 外部との接続やダイアルアップ回線がないサイト内に配置されているシステムで構成される LAN など,セキュリティ要件が高くないシステムに適したアカウントです。

    デフォルトの DECnet ユーザ名を使用する場合,ユーザはユーザ名とパスワードを入力しなくても,特定のネットワーク操作 (別々のノードのユーザ同士の電子メール交換など) を実行できます。 デフォルトの DECnet ユーザ名は,アクセス制御情報が指定されていない場合のファイル操作にも使用されます。 たとえば,デフォルトの DECnet ユーザ名を使用することで,ファイル保護がワールド・アクセスに設定されているローカル・ファイルにリモート・ユーザがアクセスすることができます。 リモート・ユーザによるローカル・ノードへのアクセスを望まない場合は,デフォルトの DECnet ユーザ名を作成しないようにします。 デフォルトの DECnet アカウントの削除については, 13.4.3 項 「システムへのデフォルトの DECnet アクセスの削除」を参照してください。

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 コマンド・プロシージャは,ネットワーク・オブジェクトを自動的に更新します。

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

  1. 各ネットワーク・オブジェクトについて,最上位のディレクトリを作成し,一意の所有者 UIC とグループ UIC を指定します。 たとえば,次のコマンド・シーケンスは,MAIL オブジェクトのための最上位ディレクトリをシステム・ディスク上に作成します。

    $ SET DEFAULT SYS$SPECIFIC:[000000]
    $ CREATE/DIRECTORY [MAIL$SERVER]/OWNER_UIC=[376,374]
    

    表 13-2 「ネットワーク・オブジェクトのデフォルト設定」 は,コマンド・プロシージャの NETCONFIG.COM および NETCONFIG_UPDATE.COM が,個々のネットワーク・オブジェクトのためのアカウントを作成するために使用する,ディレクトリ名,ユーザ名,および UIC の一覧です。 一貫性を保つために,手作業でネットワーク・オブジェクト・アカウントを作成するときも同じ情報を使用してください。

    MOM オブジェクトは,インストール時にオペレーティング・システムによって作成されます。

  2. AUTHORIZE を使用して,オブジェクト用のアカウントを作成し,自動生成されたパスワードを使用します。 (指定するユーザ名とパスワードは,ネットワーク・データベースのオブジェクトに指定するパスワード (手順 3) と同じものにする必要があります。 )

    たとえば,次のコマンド・シーケンスは MAIL オブジェクト用のアカウントを設定します。

    $ RUN SYS$SYSTEM:AUTHORIZE
    UAF> ADD MAIL$SERVER/OWNER=MAIL$SERVER DEFAULT -
    _UAF> /PASSWORD=MDU1294B/UIC=[376,374]/ACCOUNT=DECNET -
    _UAF> /DEVICE=SYS$SPECIFIC: /DIRECTORY=[MAIL$SERVER] -
    _UAF> /PRIVILEGE=(TMPMBX,NETMBX) /DEFPRIVILEGE=(TMPMBX,NETMBX) -
    _UAF> /FLAGS=(RESTRICTED,NODISUSER,NOCAPTIVE) /LGICMD=NL: -
    _UAF> /NOBATCH /NOINTERACTIVE
    

    AUTHORIZE ユーティリティの SHOW MAIL$SERVER コマンドを実行すると, 例 13-2 「MAIL$SERVER アカウントの UAF レコード」に示すように,MAIL オブジェクトのネットワーク・アカウント設定が表示されます。

  3. NCP の DEFINE コマンドを使用して,アカウントのユーザ名とパスワードを,ネットワーク・データベース内の指定したオブジェクトに関連付けます。 次のように指定します。

    $ RUN SYS$SYSTEM:NCP
    NCP> DEFINE OBJECT MAIL USER MAIL$SERVER PASSWORD MDU1294B
    NCP> EXIT
    

  4. 各ネットワーク・オブジェクトごとに,手順 1 から手順 3 を繰り返します。

  5. ネットワーク・オブジェクトの設定が終わったら,エグゼキュータ・データベースからデフォルトの DECnet アクセスを削除し,SYSUAF からデフォルトの DECnet アカウントを削除します ( 13.4.3 項 「システムへのデフォルトの DECnet アクセスの削除」参照)。

  6. 最後にシステムをリブートして,パーマネント・エグゼキュータとオブジェクト・データベースに加えた変更を,実行中のシステムに反映させます。

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

表 13-2 ネットワーク・オブジェクトのデフォルト設定

オブジェクト名ディレクトリおよびユーザ (アカウント) 名 UIC

FAL

FAL$SERVER

[376,373]

MAIL

MAIL$SERVER

[376,374]

MIRROR

MIRRO$SERVER[1]

[376,367]

$MOM

VMS$COMMON:[MOM$SYSTEM][2]

[376,375]

NML

NML$SERVER

[376,371]

PHONE

PHONE$SERVER

[376,372]

VPM

VPM$SERVER

[376,370]

[1] AUTHORIZE では,ユーザ名が 12 文字以下という制限があるため,MIRRO$SERVER への MIRROR オブジェクト・アカウントのユーザ名 (およびディレクトリ名) を縮める必要があります。

[2] MOM には,関連付けられているユーザ名はありません。

 

例 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 ルーティング初期化パスワードの指定

ポイント・ツー・ポイント接続は,同期回線および非同期回線を経由する接続のことです。 ポイント・ツー・ポイント接続では,特にダイアルアップ回線経由の場合,ルーティング初期化パスワードを使用することで,開始ノードがローカル・ノードへの接続を許可されているかどうかを確かめることができます。 ポイント・ツー・ポイント・サーキットのそれぞれの側で,他方のノードに送信するベリファイアを設定するとともに,他方のノードから受け取るべきベリファイアを指定できます。 接続確立の前に,それぞれのノードで,指定したベリファイアが相手側のノードから受け取ったかどうかを確認します。

パスワードの使用は,ポイント・ツー・ポイント接続では任意ですが,動的非同期接続では必須です。 リモート・ノードが動的非同期接続 (通常,電話による通話の間のみ維持される接続) を要求してきたときにセキュリティを高めるために,動的非同期接続を要求する側のノードはパスワードを送信しますが,ログイン要求を受信する側のノードは,接続を要求するノードに対してはパスワードを明らかにできないようになっています。 接続を要求する側のノードのネットワーク・アドレス,ノード名,およびパスワードは,ローカル・システムのルーティング登録データと一致していなければなりません。

13.5.1 動的非同期接続の確立

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

注意:

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

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

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

  1. SYSTEM アカウントにログインし,次のコマンドを会話形式で入力します。 または,システムをブートする前に SYS$MANAGER:SYSTARTUP_VMS.COM コマンド・プロシージャの中で指定します。 これらのコマンドは,非同期ドライバの NODRIVER (NOA0) をロードし, DYNSWITCH ソフトウェアをインストールします。

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

    リモートの OpenVMS ノードのシステム管理者も上記のコマンドを入力する必要があります。

    また,リモートの OpenVMS ノードのシステム管理者は,以下に示すコマンドも入力する必要があります。 これらのコマンドを実行すると,切り換え対象のターミナル回線の仮想ターミナルが使用できるようになり,ターミナル回線に DISCONNECT 特性が設定されます。 (仮想ターミナル機能により,使用している物理ターミナルが切断された場合でも,プロセスが継続して実行されます。 )

    $ RUN SYS$SYSTEM:SYSGEN
    SYSGEN> CONNECT VTA0/NOADAPTER/DRIVER=TTDRIVER
    SYSGEN> EXIT
    $ SET TERMINAL/EIGHT_BIT/PERMANENT/MODEM/DIALUP -
    _$ /DISCONNECT device-name:
    

    Device-name は,動的非同期接続の接続先ターミナル・ポートの名前です。

  2. 動的非同期ダイアルアップ接続の発信側で,必要な送信パスワードを指定します。 送信パスワードは,接続開始時にリモート・ノードに送信されるパスワードのことです。 NCP を使用して,リモート・ノードの送信パスワードを指定するコマンドを入力します。 パスワードには,1 ~ 8 文字の英数字を使用できます。 スペースは使用できません。 次のようにコマンドを指定します。

    $ RUN SYS$SYSTEM:NCP
    NCP> DEFINE NODE node-id TRANSMIT PASSWORD password
    NCP> EXIT
    

    Node-id は,ローカル・ノードが接続を確立しようとしている相手先のリモート・ノードの名前です。

    次の例では,ローカル・ノードのノード名は LOCALA,送信パスワードは PASSA です。 そして動的非同期ダイアルアップ接続を確立しようとしている接続先のリモート・ノードの名前は REMOTC です。

    $ RUN SYS$SYSTEM:NCP
    NCP> DEFINE NODE REMOTC TRANSMIT PASSWORD PASSA
    NCP> EXIT
    

    動的非同期 DECnet ダイアルアップ接続を作成する相手となるリモート・ノードごとに,コマンドを個別に使用して送信パスワードを指定する必要があります。

    接続先の相手側ノードのシステム管理者は,接続元であるローカル・ノードが受信するパスワード (受信パスワード) として同じパスワードを指定する必要があります。 リモート側のシステム管理者は, INBOUND ROUTER パラメータまたは INBOUND ENDNODE パラメータを指定して,動的接続を開始するノードのタイプ (ルータまたはエンド・ノード) を指定する必要があります。 次は,リモート・ノード側の管理者が入力するコマンドです。

    $ RUN SYS$SYSTEM:NCP
    NCP> DEFINE NODE node-id -
    _NCP> RECEIVE PASSWORD password INBOUND node-type
    NCP> EXIT
    

    たとえば,ローカル・ノードである LOCALA がエンド・ノードで,送信パスワードが PASSA の場合,REMOTC の管理者は次のコマンドを実行します。

    $ RUN SYS$SYSTEM:NCP
    NCP> DEFINE NODE LOCALA RECEIVE PASSWORD PASSA INBOUND ENDNODE
    NCP> EXIT
    

  3. 以下の手順は,必ず両方のノードで DECnet が実行されている状態で行います。 まだその状態になっていない場合は,次のコマンドを入力して,ネットワークを有効にします。 また,リモートのシステム管理者にも同じ準備をしてもらうよう依頼します。

    $ @SYS$MANAGER:STARTNET
    

    動的非同期接続の手順を開始する前に,すでにネットワークが動作していた場合は,次のコマンドを入力して,パーマネント・データベースのエントリを運用時データベースに入力します。

    $ RUN SYS$SYSTEM:NCP
    NCP> SET NODE node-id ALL
    NCP> EXIT
    

  4. 以降の手順は,NETMBX 特権を持つ OpenVMS ユーザであれば実行できます。 ローカルの OpenVMS システムにログインし,ローカルのターミナルに次の DCL コマンドを入力して,プロセスをターミナル・エミュレータ (リモート・ターミナルをローカル・ターミナル接続のように見せる機能) として機能させます。

    SET HOST/DTE device-name:

    device-name は,モデムが接続されているローカル・ターミナル・ポートの名前です。 両方のシステムで,自動ダイアル機能が備わっているモデムを使用する場合は,必要に応じて SET HOST/DTE コマンドに /DIAL 修飾子を追加し,リモート・ノードのモデムに自動でダイアルすることができます。 次のように指定します。

    SET HOST/DTE/DIAL=number device-name:

  5. 自動ダイアル機能を使用しない場合は,リモート・ノードに手動でダイアルアップします。

  6. ダイアルアップ接続が確立し,リモートの OpenVMS システムのウェルカム・メッセージを受信したら,リモート・ノードの自分のアカウントにログインします。

  7. リモート・ノードの自分のアカウントにログインしている状態で, 次のコマンドを入力し,回線が自動的に DECnet 回線に切り替わるようにします。

    $ SET TERMINAL/PROTOCOL=DDCMP/SWITCH=DECNET
    

    次のメッセージは,DECnet 接続が確立された状態であることを示すメッセージです。

    %REM-S-END - control returned to local-nodename::
    $
    

    通信リンクを確立できたかどうかを調べるには,ローカル・システムで次のコマンドを入力します。

    $ RUN SYS$SYSTEM:NCP
    NCP> SHOW KNOWN CIRCUITS
    NCP> EXIT
    

    コマンドの実行結果には,回線に接続されている非同期デバイスに応じて,TT または TX というニーモニックで示されるサーキットの一覧が表示され,ON の状態であることを示されます。

    ローカル・ターミナルの画面に DCL プロンプトが表示されたら,非同期 DECnet 接続経由でリモート・ノードとの間のやり取りを開始できます。

  8. ターミナル回線を DECnet 回線に自動的に切り換える方法 (前述の手順 7 の方法) の代わりに,手動で回線を切り換えることもできます。 OpenVMS ソフトウェアを実行していないノードから OpenVMS ノードに対して動的接続を開始する場合は,手動による切り換えが必要です。 OpenVMS システムから開始する場合,手動による切り換えは任意です。 OpenVMS ソフトウェアを実行していないノードから接続を開始するときは,システム固有の手順に従って,ターミナル・エミュレーション機能を使用してリモートの OpenVMS ノードにログインします。

    リモート・ノードへログインしたら,手動による切り換えを行うには 2 つの手順が必要です。

    1. リモートの OpenVMS ノード上の自分のアカウントを使用して,手順 7 で説明した SET TERMINAL コマンドを指定します。 ただし,ここでは /MANUAL 修飾子を追加します。

      $ SET TERMINAL/PROTOCOL=DDCMP/SWITCH=DECNET/MANUAL
      

      リモートのシステムが回線を DECnet の回線に切り換わることを示す,次のメッセージをリモート・ノードから受信します。

      %SET-I-SWINPRG The line you are currently logged over is becoming
                     a DECnet line
      

    2. ターミナル・エミュレータを終了して,手動で DECnet 回線に切り換えます。 切り換えの手順は,ログインしているオペレーティング・システムによって異なります。

      次の例は,動的接続を開始する OpenVMS ユーザの場合の切り換え手順です。

      • ターミナル・エミュレータを終了するには,OpenVMS システム上で,バックスラッシュ (\) キーと Ctrl キーを同時に押します。

      • 次のコマンドを入力して,ターミナル回線を手動で DECnet 回線に切り換えます。

        $ SET TERMINAL/PROTOCOL=DDCMP TTA0:
        

        TTA0 は,ローカル・ノード上のターミナル・ポートの名前です。

      • NCP コマンドを入力して,ターミナル・ポートの TTA0 に接続されている回線とサーキットを手動で有効にします (次の例を参照)。

        $ RUN SYS$SYSTEM:NCP
        NCP> SET LINE TT-0-0 RECEIVE BUFFERS 4 -
        _NCP>  LINE SPEED 2400 STATE ON
        NCP> EXIT
        

        これで,ローカルの OpenVMS ノード上で非同期 DECnet が開始します。

  9. 動的非同期接続は,次のいずれかの方法で終了できます。

    • 電話回線の接続を切断します。

    • NCP を実行し,非同期の回線またはサーキットのいずれかを無効にします。 接続の終了に使用できる 2 つのコマンド (回線とサーキット) は次のとおりです。

      $ RUN SYS$SYSTEM:NCP
      NCP> SET LINE dev-c-u STATE OFF
      NCP> SET CIRCUIT dev-c-u STATE OFF
      NCP> EXIT
      

      リモート・ノードで上記のいずれかの NCP コマンドが入力されると,回線はただちにターミナル・モードに戻ります。 ローカルの OpenVMS ノード (接続を開始した側) でコマンドが入力されると,リモート側の回線とサーキットは有効な状態がおよそ 4 分間継続し,その後回線はターミナル・モードに戻ります。

図 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 ネットワークにおけるファイルの共用

ユーザが,パスワードを共用したり,ファイルやディレクトリの保護コードを変更してワールド・カテゴリに対する読み込みアクセス権または実行アクセス権を付与したりしないようにします。 BYPASS 特権または READALL 特権の付与は慎重に行います。

ネットワーク環境において,ファイルを臨時に共用する場合は,メール・ユーティリティを使用するのが最も簡単です。 この場合,共用相手にファイルをメールで送信するため,パスワードを知らせる必要がなく,その相手以外のユーザはファイルにアクセスできません。 ただし,共用対象のファイルにアクセスしたいときに,ファイルの所有者に依頼し,応答を待たなければならないという短所があります。 共用ファイルへのアクセスが頻繁に発生する状態が継続する場合は,ディレクトリとファイルに対して,代理アカウントや ACL を設定する方が効率的です。

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

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

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

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

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

  1. ファイルを格納するノード (BNORD) のセキュリティ管理者が,SALES_READER という特別なアカウントを作成します。 SALES_READER アカウントは,メール機能が無効になっているキャプティブ・アカウントとして設定されます。 デフォルトのディレクトリは,[SALESINFO] で,次に示す保護コードがデフォルトで設定されています。

    (S:RWED,O:RWED,G:R,W)

    この保護コードにより,ホーム・ノードである BNORD 上の SALES_READER と同じグループに属するユーザは,ファイルの読み込みが可能になります。 さらに,システム・カテゴリまたは所有者カテゴリに属しているユーザのみ,または同等のアクセスを認める特権を持つユーザのみが,当該ディレクトリ内のファイルを更新できます。 ACL を使用して,アクセスをさらに詳細に定義します (手順 3 参照)。

  2. セキュリティ管理者は,AUTHORIZE の ADD/PROXY コマンドを使用して,外部ユーザのための代理アクセスを追加します。 たとえば,代理アクセスを,DEXTER というノードの Jackson というユーザと,BANGOR というノードの Goodwin というユーザにまで拡張するには,次のコマンドを使用します。

    UAF> ADD/PROXY DEXTER::JACKSON  SALES_READER/DEFAULT
    UAF> ADD/PROXY BANGOR::GOODWIN  SALES_READER/DEFAULT
    

  3. 後になってホーム・ノード BNORD の他のユーザもアクセスの必要があり,当該ユーザが SALES_READER と同じグループに属していないことがわかった場合は,[SALESINFO] ディレクトリ内のファイルに ACL を追加できます。 たとえば,R. Grant がすべてのファイルに対する制御アクセス,J. Martinez はすべてのファイルに対する読み込みアクセスを必要としているとします。 次の 2 つの DCL コマンドを実行することで,ディレクトリに対する ACL を定義した後,その ACL を既存のすべてのファイルに継承させることができます。

    $ SET SECURITY/ACL=-
    _$ ((IDENTIFIER=R_GRANT,ACCESS=CONTROL),-
    _$ (IDENTIFIER=J_MARTINEZ,ACCESS=READ))-
    _$ ((IDENTIFIER=R_GRANT,OPTIONS=DEFAULT,ACCESS=CONTROL),-
    _$ (IDENTIFIER=J_MARTINEZ,OPTIONS=DEFAULT,ACCESS=READ))-
    _$ [000000]SALESINFO.DIR
    $ SET SECURITY/DEFAULT *.*;*
    

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 を使用します。

  1. 本部のセキュリティ管理者は,AUTHORIZE を使用して,リモート・ユーザの Albion,Elton,Irving,Aylmer,Lavina の 5 名に対して CENTRL ノード上に新規の代理アカウントを作成します。 これらのアカウントは,キャプティブ・アカウントとし,メールは使用不可,そしてネットワーク・アクセスのみに限定します。 また,これらのアカウントは,CLI テーブルを使用して DCL のサブセットに限定します。 各ユーザのデフォルトのディレクトリは,[DESGN_PROJECTS] とします。 セキュリティ管理者は,ファイルの想定用途に合わせて DESIGNERS グループにこれらのアカウントを入れることにします。

    Diantha,Brittania,Albert,および Delia というユーザについてはすでにアカウントが存在しています。 これらのアカウントは必ずしも同じグループには属する必要はありません。 これらのユーザには,作業に使用するデバイスとディレクトリを通知します。

  2. 次に,代理レコードをネットワーク代理登録ファイルに追加します。 次の AUTHORIZE コマンドを使用します。

    UAF> ADD/PROXY FRISCO::ALBION ALBION/DEFAULT
    UAF> ADD/PROXY FRISCO::ELTON ELTON/DEFAULT
    UAF> ADD/PROXY LA::IRVING IRVING/DEFAULT
    UAF> ADD/PROXY BOS::AYLMER AYLMER/DEFAULT
    UAF> ADD/PROXY WASH::LAVINA LAVINA/DEFAULT
    

  3. CENTRL ノードのセキュリティ管理者は,[DESGN_PROJECTS] の最上位ディレクトリに ACL を適用します。 次の DCL コマンドを使用します。

    $ SET SECURITY/ACL=(DEFAULT_PROTECTION,S:RWED,O,G,W) -
    _$ [000000]DESGN_PROJECTS.DIR
    

    この ACL を適用することにより,システム・カテゴリに属さないユーザは,当該ディレクトリとそのサブディレクトリに格納されているファイルに対して,BYPASS 特権を持っている場合を除き,UIC ベースのアクセスはできなくなります。 実のところ,この制限は DESIGNERS グループの 5 名のユーザにも適用されます。 目標は,特定のユーザのグループにのみアクセスを許可する ACL をすべてのファイルに適用することです。 この保護コードが,当該ディレクトリとそのサブディレクトリに格納されるすべてのファイルに継承されるのが理想的です。 (さらなる保護のためファイルに対して設定される ACL は,実際にいずれかのユーザがファイルへのアクセスを要求する場合に優先して適用されます。 )

  4. [DESGN_PROJECTS] の下に,次の 2 つのサブディレクトリが作成されます。

    • [DESGN_PROJECTS.LEVI]

    • [DESGN_PROJECTS.BETSEY]

  5. セキュリティ管理者は,ACL エディタを使用して,最上位ディレクトリの ACL に次の ACE を追加します。

    DESGN_PROJECTS.DIR
    
    (IDENTIFIER=DIANTHA,OPTIONS=PROTECTED,ACCESS=EXECUTE)
    (IDENTIFIER=BRITTANIA,OPTIONS=PROTECTED,ACCESS=EXECUTE)
    (IDENTIFIER=ALBERT,OPTIONS=PROTECTED,ACCESS=EXECUTE)
    (IDENTIFIER=DELIA,OPTIONS=PROTECTED,ACCESS=EXECUTE)
    (IDENTIFIER=AYLMER,OPTIONS=PROTECTED,ACESS=EXECUTE)
    (IDENTIFIER=LAVINA,OPTIONS=PROTECTED,ACCESS=EXECUTE)
    (IDENTIFIER=ALBION,OPTIONS=PROTECTED,ACCESS=EXECUTE)
    (IDENTIFIER=ELTON,OPTIONS=PROTECTED,ACCESS=EXECUTE)
    (IDENTIFIER=IRVING,OPTIONS=PROTECTED,ACCESS=EXECUTE)
    

    これらの保護 ACE により,選択した 9 名のユーザのみが最上位ディレクトリにアクセス可能となります。 ACL によって最上位ディレクトリへの書き込みまたは削除のアクセスを許可されているユーザはいないため,最上位ディレクトリとそのサブディレクトリは,ファイルの削除と名前変更からは基本的に保護されます。 (もちろん,システム・カテゴリのユーザは,UIC ベースの保護機能を通じて,読み込みと削除のアクセスが可能です。 )

  6. 次に,セキュリティ管理者は,サブディレクトリに対する ACL を作成します。 それぞれのサブディレクトリに必要な ACE は次のとおりです。

    [DESGN_PROJECTS]LEVI.DIR
    
    (IDENTIFIER=DIANTHA,OPTIONS=PROTECTED,ACCESS=READ+WRITE+EXECUTE+CONTROL)
    (IDENTIFIER=DIANTHA,OPTIONS=DEFAULT+PROTECTED,ACCESS=READ+WRITE+EXECUTE+DELETE+CONTROL)
    (IDENTIFIER=BRITTANIA,OPTIONS=PROTECTED,ACCESS=READ+WRITE+EXECUTE+CONTROL)
    (IDENTIFIER=BRITTANIA,OPTIONS=DEFAULT+PROTECTED,ACCESS=READ+WRITE+EXECUTE+DELETE+CONTROL)
    (IDENTIFIER=AYLMER,OPTIONS=PROTECTED,ACCESS=READ+WRITE)
    (IDENTIFIER=AYLMER,OPTIONS=DEFAULT+PROTECTED,ACCESS=READ+WRITE)
    (IDENTIFIER=LAVINA,OPTIONS=PROTECTED,ACCESS=READ+WRITE)
    (IDENTIFIER=LAVINA,OPTIONS=DEFAULT+PROTECTED,ACCESS=READ+WRITE)
    (IDENTIFIER=ALBION,OPTIONS=PROTECTED,ACCESS=READ)
    (IDENTIFIER=ALBION,OPTIONS=DEFAULT+PROTECTED,ACCESS=READ)
    (IDENTIFIER=ELTON,OPTIONS=PROTECTED,ACCESS=READ)
    (IDENTIFIER=ELTON,OPTIONS=DEFAULT+PROTECTED,ACCESS=READ)
    (IDENTIFIER=IRVING,OPTIONS=PROTECTED,ACCESS=READ)
    (IDENTIFIER=IRVING,OPTIONS=DEFAULT+PROTECTED,ACCESS=READ)
    
    
    
    [DESGN_PROJECTS]BETSEY.DIR
    
    (IDENTIFIER=ALBERT,OPTIONS=PROTECTED,ACCESS=READ+WRITE+EXECUTE+CONTROL)
    (IDENTIFIER=ALBERT,OPTIONS=DEFAULT+PROTECTED,ACCESS=READ+WRITE+EXECUTE+DELETE+CONTROL)
    (IDENTIFIER=DELIA,OPTIONS=PROTECTED,ACCESS=READ+WRITE+EXECUTE+CONTROL)
    (IDENTIFIER=DELIA,OPTIONS=DEFAULT+PROTECTED,ACCESS=READ+WRITE+EXECUTE+DELETE+CONTROL)
    (IDENTIFIER=ALBION,OPTIONS=PROTECTED,ACCESS=READ+WRITE)
    (IDENTIFIER=ALBION,OPTIONS=DEFAULT+PROTECTED,ACCESS=READ+WRITE)
    (IDENTIFIER=ELTON,OPTIONS=PROTECTED,ACCESS=READ+WRITE)
    (IDENTIFIER=ELTON,OPTIONS=DEFAULT+PROTECTED,ACCESS=READ+WRITE)
    (IDENTIFIER=IRVING,OPTIONS=PROTECTED,ACCESS=READ+WRITE)
    (IDENTIFIER=IRVING,OPTIONS=DEFAULT+PROTECTED,ACCESS=READ+WRITE)
    (IDENTIFIER=AYLMER,OPTIONS=PROTECTED,ACCESS=READ)
    (IDENTIFIER=AYLMER,OPTIONS=DEFAULT+PROTECTED,ACCESS=READ)
    (IDENTIFIER=LAVINA,OPTIONS=PROTECTED,ACCESS=READ)
    (IDENTIFIER=LAVINA,OPTIONS=DEFAULT+PROTECTED,ACCESS=READ)
    

    上記のどちらの ACL にも,識別子ごとに 2 つの ACE が指定されています。 最初の ACE は,サブディレクトリへのアクセスを制御するためのものです。 この ACE は,サブディレクトリ保護のために削除アクセスを拒否するもので,サブディレクトリ内に作成されるどのファイルにも継承されません。 それぞれの識別子の 2 つめの ACE は,Default 属性が含まれているため,サブディレクトリに追加されたすべてのファイルに自動的に継承されます。 さらには,Protected 属性により,すべての ACE が,一部の処理によるものを除いて,削除から保護されます。

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

$ COPY CENTRL::LEVIGRAYMEM3.MEM LP:

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

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

印刷用画面へ
プライバシー 本サイト利用時の合意事項
© 2011 Hewlett Packard Enterprise Development LP