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

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

第13章 保護サブシステムの使用

≫ 

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

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

OpenVMS オペレーティング・システムでは,セキュリティ制御の大部分はユーザ ID に基づいています。ファイルやデバイスなどの保護オブジェクトは,ユーザ単位または複数のユーザからなるグループ単位でアクセスできます。オブジェクトの ACL または保護コードが,必要なアクセス権限をユーザに与えている場合,そのユーザは利用可能な任意のソフトウェアを使用してそのオブジェクトを使用できます。OpenVMS のオブジェクト保護の説明については, 第4章 「データの保護」 を参照してください。

保護サブシステムでは,通常のアクセス制御で保護されたアプリケーションが,当該サブシステムに属するオブジェクトの門番の役割を果たします。ユーザは,門番として機能するアプリケーションを実行しない限り,サブシステムのオブジェクトにはアクセスできません。ユーザがアプリケーションを実行すると,ユーザのプロセス・ライト・リストが識別子を取得し,サブシステムが所有するオブジェクトへのアクセスが許可されます。ユーザがアプリケーションを終了すると,これらの識別子と,それらによってユーザが得たオブジェクトへのアクセス権が直ちに失われます。

この章では,保護サブシステムの詳細と,その構築方法を説明します。

13.1 保護サブシステムの利点

保護サブシステムの利用には,次のような利点があります。

  • 保護サブシステムでは,OpenVMS の従来のアクセス制御にない,条件に基づくデータへのアクセス制御が可能な仕組みを利用できます。従来は,ユーザに特権を付与することで,保護コードやアクセス制御リスト (ACL) の適用を回避していました。しかし,このような特権を与えることは,ユーザに幅広いアクセス権限を与えることになります。さまざまな特権に設定されている権限の詳細については, 付録 A 「特権の割り当て」 を参照してください。保護サブシステムによって,個々のユーザが広範囲に特権を使用することを回避できます。

  • 保護サブシステムは,特権付きでイメージをインストールする代わりの手段となります。特権付きの安全なイメージを作成するには一定の技術が必要です。不適切なイメージを作成してしまうと,システムのセキュリティが損なわれる恐れがあります。

  • 保護サブシステムは,保護された共用可能イメージ (ユーザ記述のシステム・サービス) の作成に代わる手段を提供します。

  • 保護サブシステムでは,非特権ユーザがセキュリティ管理者の支援をそれほど受けずに保護サブシステムを管理できるため,システム管理の負担が軽減されます。システム管理要件の詳細については, 13.5 項 「システム管理の要件」を参照してください。

13.2 保護サブシステムの適用範囲

保護サブシステムには,データベースから一般的なシステム管理に至るまで,さまざまな適用対象があります。

たとえば,グループのメンバ全員が利用できる,グループ・メンバ・リストなどが考えられます。このリストには,グループ・メンバの名前,住所,管理番号,関心事項が記載されています。メンバ・リストを保護サブシステムとして設定すると,グループのすべてのメンバが,特定の情報を参照したり,特定の種類の情報を更新したりできます。

また保護サブシステムによって,共用の場所にあるプリンタに機密情報が送信される危険性の問題なども解決できます。たとえば,データに機密情報が含まれていないかをチェックするアプリケーションを作成できます。機密ファイルは制限された場所のプリンタに送信し,共用のファイルは利用可能な任意のプリンタに送信することなどが可能になります。アプリケーションの実行アクセス権を持っているユーザであれば,制限されているプリンタを使用できますが,保護サブシステムを通じてのみとなります。

13.3 保護サブシステムの仕組み

保護サブシステムは,アプリケーションであり,そのアプリケーションを実行するプロセスに 1 つ以上の識別子を割り当てます。ユーザがサブシステムを実行している間は,ユーザのプロセス・ライト・リストにこれらの識別子が維持されます。 図 13-1 「通常のアクセス制御と保護サブシステムとの違い」は,保護サブシステムが従来のアクセス制御にどのようにアクセス制御の層を付け加えるかを示します。

図 13-1 通常のアクセス制御と保護サブシステムとの違い

通常のアクセス制御と保護サブシステムとの違い

アプリケーションに対する実行アクセス権を持つユーザは,サブシステムにアクセスできます。サブシステムにアクセスすると,ユーザはデータ・ファイルやサブシステムの他の資源を使用して作業ができます。

サブシステムが消費する資源 (ファイルやプリンタなど) はそれぞれ異なる方法で保護できるため,サブシステムは複数の識別子を持つことができます。

サブシステム識別子の保有は,ユーザがアプリケーションを実行している間に限定されています。ユーザがアプリケーションを終了すると,識別子はプロセス・ライト・リストから削除されます。サブシステム識別子は,ユーザが Ctrl/Y を入力するか,DCL コマンドの SPAWN を使用してサブプロセスを作成しようとした場合にも,ライト・リストから削除されます。この点では,サブシステム識別子の使用は,特権付きでインストールされているイメージの操作と同じと言えます。

次の識別子は,セキュリティ・サブシステム用に予約されているため,ユーザには割り当てないでください。

  • SECSRV$CLIENT

  • SECSRV$COMMUNICATION

  • SECSRV$OBJECT

13.4 設計に関する検討事項

保護サブシステム用のアプリケーションを開発する場合は,/DEBUG 識別子および /TRACEBACK 識別子を付けずにアプリケーション・イメージをリンクしなければなりません。

この種のサブシステムは多くの場合,特権の必要性があらかじめ排除されていますが,アプリケーションを特権付きでインストールすることは可能です。たとえば,パーマネント・グローバル・セクションを作成するために PRMGBL 特権を必要とするアプリケーションや,セキュリティ監査レコードをシステムのセキュリティ監査ログ・ファイルに送るために AUDIT 特権が必要なアプリケーションがあります。よほどの理由がない限り,ALL カテゴリに属する特権付きで保護サブシステム・アプリケーションをインストールすることは避けてください。このカテゴリには,BYPASS,CMKRNL,SYSPRV など,OpenVMS のアクセス制御をユーザが無効にできる特権が含まれています。OpenVMS の特権の一覧については 表 8-2 「OpenVMS の特権」 を,特権の説明については 付録 A 「特権の割り当て」 を参照してください。

サブシステム設計者は,サブシステムが意図どおりに動作するのに必要な識別子のリストを作成する必要があります。次にサブシステム設計者は,セキュリティ管理者に 13.5 項 「システム管理の要件」に示す準備をするよう依頼します。

13.5 システム管理の要件

非特権ユーザでも保護サブシステムを作成し,管理することはできますが,サブシステム用に必要な識別子を作成する最初の段階と,保護システムが格納されているボリュームをマウントする最終段階は,セキュリティ管理者が担当する必要があります。

セキュリティ管理者は,次の作業を行う必要があります。

  1. サブシステム用の識別子を作成し,それぞれに Subsystem 属性を設定します。Subsystem 属性は,識別子の保持者にサブシステムを管理する権限を与える属性です。

  2. Subsystem 属性を持つサブシステム識別子を,サブシステムの管理者の役割を果たす人物に付与します。これによりサブシステム管理者は,サブシステム識別子を,サブシステムを構成するイメージに割り当てることができるようになります。

  3. サブシステム管理者に,アプリケーション・イメージへの制御アクセス権を与えます。サブシステム管理者は,サブシステム ACE をイメージ ACL に追加するために制御アクセス権が必要です。

  4. 保護サブシステムの管理対象となる既存の資源に対する制御アクセス権をサブシステム管理者に割り当てます。

    サブシステム管理者には,主要なシステム資源に対する制御アクセス権が必要になることがありますが,オブジェクトを対象とした ACL により,サブシステム管理者のアクセス権がこれらの資源のみに制限されます。この方法は,SYSPRV 特権付きでイメージをインストールするよりは危険性が低いと言えます。

次に示すのは,ユーザがメンバ・リストを管理できるように,識別子と必要なアプリケーション・アクセス権を設定する方法の例です。

例 13-1 メンバ・リスト管理用の識別子とアプリケーション・アクセス権の設定

$ SET DEFAULT SYS$SYSTEM
$ RUN AUTHORIZE
UAF> ADD/IDENTIFIER MEMBERS_SUBSYSTEM-       1
_UAF> /ATTRIBUTES=(SUBSYSTEM,RESOURCE)
UAF> GRANT/IDENTIFIER MEMBERS_SUBSYSTEM -    2
_UAF> /ATTRIBUTES=(SUBSYSTEM,RESOURCE) LOUIS
UAF> GRANT/IDENTIFIER MEMBERS_SUBSYSTEM -
_UAF> /ATTRIBUTES=(SUBSYSTEM,RESOURCE) WU
$ SET SECURITY/ACL=(IDENTIFIER=MEMBERS_SUBSYSTEM,-   3
_$ ACCESS=CONTROL) MEMBER_LIST.EXE
1

AUTHORIZE を使用して,MEMBERS_SUBSYSTEM というサブシステム識別子を作成します。 この識別子には Subsystem 属性が設定されています。

2

Louis と Wu を識別子の保持者に設定し,この 2 名がサブシステムを管理できるようにします。

3

Louis と Wu に対して MEMBER_LIST.EXE への制御アクセス権を割り当てます。

MEMBERS_SUBSYSTEM というサブシステム識別子を作成し,Resource 属性を設定します。これにより,サブシステムにアクセスする個々人ではなく,MEMBERS_SUBSYSTEM 識別子にディスク領域を割り当てることができます。(Resource 属性を使用するときは,ディレクトリに対して適切な ACL を設定するよう注意してください [ 8.8.1.2.3 項 「ACL の設定」参照]。)

13.6 サブシステムの構築

サブシステム管理者は, 13.5 項 「システム管理の要件」の手順に従って,必要な識別子とアクセス権を設定された後は,サブシステム・イメージに対して必要な ACE を追加することができます。サブシステム・イメージを構築するには,アプリケーション・イメージに適用されるサブシステム ACE と,サブシステムが管理するオブジェクトに適用される識別子 ACE の 2 種類の ACE が必要です。そのため,サブシステムを構築するには,次の手順を実行する必要があります。

  1. アプリケーション・イメージの ACL 内にサブシステム識別子を含むサブシステム ACE を作成します。サブシステム ACE の形式は, 次のとおりです。

    (SUBSYSTEM,{IDENTIFIER=identifier[,ATTRIBUTES=attributes]})

  2. サブシステムが管理するオブジェクトに対するアクセス権を付与します。サブシステムに帰属するさまざまなオブジェクトの ACL に識別子 ACL を追加する必要があります。それぞれの識別子 ACE には,次の形式で記述されたサブシステム識別子の 1 つが含まれています。

    (IDENTIFIER=identifier, ACCESS=access-type[+...])

次の例では,サブシステム管理者が,DCL の SET SECURITY コマンドを使用して,サブシステムを構成するイメージにサブシステム識別子を関連付けています。まず,サブシステム管理者は, MEMBERS_SUBSYSTEM 識別子を持つサブシステム ACE を,MEMBER_LIST.EXE アプリケーション・イメージの ACL に追加します。

$ SET SECURITY/ACL=(SUBSYSTEM,IDENTIFIER=MEMBERS_SUBSYSTEM,-
_$ ATTRIBUTES=RESOURCE) MEMBER_LIST.EXE

次に,MEMBERS_SUBSYSTEM サブシステム識別子を持つ識別子 ACE を,サブシステムが管理するデータ・ファイルに追加します。

$ SET SECURITY/ACL=(IDENTIFIER=MEMBERS_SUBSYSTEM,-
_$ ACCESS=READ+WRITE) MEMBER_DATA*.DAT

DCL の SHOW SECURITY コマンドを使用して,ファイルのセキュリティ属性を表示できます。次に例を示します。

$ SHOW SECURITY MEMBER_LIST.EXE

MEMBER_LIST.EXE object of class FILE
     Owner: [STAFF]
     Protection: (System: RWED, Owner: RWED, Group, World: RE)
     Access Control List: (SUBSYSTEM,IDENTIFIER=MEMBERS_SUBSYSTEM,ATTRIBUTES=RESOURCE)
$ SHOW SECURITY MEMBER_DATA*.DAT
MEMBER_DATA_1.DAT object of class FILE
     Owner: MEMBERS_SUBSYSTEM
     Protection: (System: RWED, Owner: RWED, Group, World)
     Access Control List: (IDENTIFIER=MEMBERS_SUBSYSTEM,ACCESS=READ+WRITE)

MEMBER_DATA_2.DAT object of class FILE
     Owner: MEMBERS_SUBSYSTEM
     Protection: (System: RWED, Owner: RWED, Group, World)
     Access Control List: (IDENTIFIER=MEMBERS_SUBSYSTEM,
            ACCESS=READ+WRITE)

13.7 トラステッド・ボリュームにおける保護サブシステムの有効化

SECURITY 特権を持つユーザは,MOUNT コマンドに /SUBSYSTEM 修飾子を指定することにより,ボリュームにおけるサブシステムを有効にすることができます。デフォルトでは,サブシステムはシステム・ディスクについてのみ有効になっています。その他のディスクについては,ボリュームをマウントするたびにサブシステムを有効にする必要があります。

次の例では,セキュリティ管理者が,MOUNT コマンドに /SUBSYSTEM 修飾子を指定して,DUA0 というデバイスにおけるサブシステム ACE の処理を有効にしています。このディスクには,MEMBERS_SUBSYSTEM 識別子が設定されたサブシステムが含まれているものと仮定します。

$ MOUNT /SUBSYSTEM /SYSTEM DUA0: DOC WORK8

サブシステム ACE の処理は, DCL の SET VOLUME /SUBSYSTEM コマンドを使用することで,動的に有効/無効を切り換えることができます。このコマンドは,MOUNT コマンドを使用してマウントされないシステム・ディスクの場合に特に有用です。

サブシステムをマウントするユーザは,マウントするボリュームに何が含まれているかを把握している必要があります。把握していない場合,そのオペレータまたはシステム管理者は,システム・セキュリティを不用意に無効にしてしまう可能性があります。たとえば,あるクラスタにおいて特権を持つユーザが,サブシステム識別子を有するアプリケーションをボリュームに置き,別のクラスタの無警戒のオペレータにそのボリュームをマウントするよう要請することが簡単にできてしまいます。アプリケーションは,適切なサブシステム識別子を有しているため,権限のないサブシステムでメンバを装うことができます。このため,信用できるユーザのボリュームのみマウントするか,またはサブシステムを有効にしてボリュームをマウントする前に,サブシステム ACE が含まれているかどうかボリュームを徹底的に検索します。

13.8 ユーザへのアクセス権の付与

サブシステムのメイン・アプリケーション・イメージに対する実行アクセス権を持つユーザはすべて,サブシステムがアクセスを許可している場合に,サブシステムの管理下にあるデータ・ファイルやその他のオブジェクトを利用できます。ただし,サブシステムの管理者は,次の方法でサブシステムのオブジェクトへのアクセスを禁止できます。

  • サブシステム管理者は,サブシステムに帰属する資源のうち,すべてのメンバにはアクセスを許可したくない資源について特別な識別子を作成し,これらの資源に ACE を追加することができます。

  • ACE の中で表現を組み合わせることで,条件に応じてアクセス権を指定できます。たとえば,次に示す ACE は,MEMBERS_SUBSYSTEM を実行している MEMBERS_ADMIN にアクセスを許可しますが,MEMBERS_ADMIN のみ,および MEMBERS_SUBSYSTEM 識別子を有する他のユーザに対してはアクセスを許可しません。

    (ID=MEMBERS_SUBSYSTEM+MEMBERS_ADMIN, ACCESS=READ+WRITE)

ユーザがサブシステムのアプリケーション・イメージを実行している間は,そのユーザのプロセス・ライト・リストに,そのユーザの通常の識別子だけでなく,サブシステム識別子も含まれていることを忘れないでください。ただし,ユーザがアプリケーションに対して割り込み操作を行うか,または終了すると,そのユーザのプロセス・ライト・リストに含まれるサブシステム識別子は直ちに消滅し,サブシステム内のオブジェクトへのアクセス権を失います。サブシステム識別子は,デフォルトでは,サブプロセスが生成されたときに継承されません。

13.9 保護サブシステムの例

R. D. Taylor Inc. というサプライ品製造の会社が,購買部門と仕入先勘定部門のために保護サブシステムを設定することにしたとします。これらの部門は,別々に分かれていますが,サプライヤからの購買状況を記録する共通のデータベースを共用しています。

同社の在庫が,設定した数量を下回ると,購買部門は必要なサプライ品の注文するよう指示されます。購買担当者は,(必要であれば) サプライヤを探し,注文番号を割り当て,注文を出します。

商品が到着すると,受領と品質管理を担当する部門が,到着したものと注文内容とをつき合わせて確認し,品質基準を満たしているかどうかを調べ,合格したものを在庫に加えます。入庫処理が済むと,その情報が仕入先勘定部門に送られ,そこで請求書の処理が行われます。

仕入先勘定部門の管理者は,請求書と注文書とをつき合わせて確認し,サプライヤへの毎週の支払金額を計算するために支払いプログラムを実行します。支払い情報はデータベースに記録され,小切手は会社の小切手用紙をセットしたプリンタで印刷されます。

サブシステムを使用することで,同社は 2 つの目的をかなえることができます。

  • 購買担当者に,社のデータベースに記録されている注文の参照およびデータベースへの注文の記録を行うライトを与え,仕入先勘定部門の担当者にはサプライヤの請求書を調べるライトを与えます。これらの作業を行う購買担当者は,SUPPLIERS_ORDERS 識別子を有します。仕入先勘定部門の担当者は,ACCOUNTS_PAYABLE 識別子を有します。

    これらの従業員は,ORDERS.EXE を実行して,サプライヤの情報を更新します。このプログラムは,ORDERS.DAT にデータを格納します。

  • プログラムは,仕入先勘定部門の信頼できる管理者に,データベースの更新,支払金額の計算,および小切手の印刷を行うライトを与えます。(小切手の印刷には,同社の小切手用紙をセットした 1 台のプリンタを使用します。) 仕入先勘定部門の管理者は,ACCOUNTS_PAYABLE 識別子を有します。

    仕入先勘定部門の管理者は,PAYMENTS.EXE を実行して上記の作業を行います。このプログラムは,完了した支払いを PAYMENTS.DAT データ・ファイルに記録します。

同社は,McGrey をサブシステムの設計および管理の担当者に任命しました。 図 13-2 「Taylor 社のサブシステムのディレクトリ構造」は,Taylor 社のサブシステムのディレクトリ構造です。 例 13-6 「サブシステム・コマンド・プロシージャ」は,このサブシステムを実装するため,McGrey が作成したコマンド・プロシージャです。

図 13-2 Taylor 社のサブシステムのディレクトリ構造

Taylor 社のサブシステムのディレクトリ構造

13.9.1 最上位ディレクトリの保護

McGrey は,ユーザが,必要な識別子を有している場合にのみサブシステムにアクセスできるようなディレクトリ構造を実装しました。具体的には,購買担当者 は SUPPLIERS_ORDERS 識別子を,仕入先勘定部門の管理者は ACCOUNTS_PAYABLE 識別子を有します。サブシステム管理者として,McGrey は SUPPLIERS_SUBSYSTEM 識別子を有します。

最上位ディレクトリの SUPPLIERS_SUBSYSTEM.DIR には,次の例に示す保護が設定されています。

例 13-2 SUPPLIERS_SUBSYSTEM.DIR の保護

$ DIRECTORY/SECURITY SYS$SYSDEVICE:[000000]SUPPLIERS_SUBSYSTEM.DIR

Directory SYS$SYSDEVICE:[000000]

SUPPLIERS_SUBSYSTEM.DIR;1
SUPPLIERS_SUBSYSTEM   (RWE,RWE,,)     1
          (CREATOR,ACCESS=NONE) 2
          (DEFAULT_PROTECTION,SYSTEM:RWED,OWNER:RWED,GROUP:,WORLD:) 3
          (IDENTIFIER=SUPPLIERS_SUBSYSTEM,ACCESS=READ+WRITE+CONTROL) 4
          (IDENTIFIER=SUPPLIERS_ORDERS,ACCESS=EXECUTE) 5
          (IDENTIFIER=ACCOUNTS_PAYABLE,ACCESS=EXECUTE) 6
          (IDENTIFIER=*,ACCESS=NONE) 7
          (IDENTIFIER=SUPPLIERS_SUBSYSTEM,
           OPTIONS=DEFAULT,ACCESS=READ+WRITE+CONTROL) 8
          (IDENTIFIER=SUPPLIERS_ORDERS,OPTIONS=DEFAULT,ACCESS=EXECUTE)
          (IDENTIFIER=ACCOUNTS_PAYABLE,OPTIONS=DEFAULT,ACCESS=EXECUTE)    
          (IDENTIFIER=*,OPTIONS=DEFAULT,ACCESS=NONE)

Total of 1 file.
1

このディレクトリ保護コードは,システム・カテゴリと所有者カテゴリに属するユーザに対して,読み込み,書き込み,および実行のアクセス権を与えますが, グループおよびワールド・ユーザに対してはアクセス権を与えません。そのため,グループとワールド・ユーザは,ACL をとおしてアクセス権を得なければなりません。

2

作成者 ACE により,このディレクトリにファイルを作成するユーザが,作成したファイルへの特別なアクセス権を持たないことが保証されます。 作成者 ACE の詳細については, 8.8.1.2 項 「資源識別子により所有されるディレクトリのデフォルトの設定」を参照してください。

3

デフォルト保護 ACE は,ディレクトリに作成されたファイルへの,グループおよびワールド・ユーザによるアクセスを拒否します。

4

McGrey は SUPPLIERS_SUBSYSTEM というサブシステム識別子を有します。 この ACE は,McGrey に読み込み,書き込み,および制御のアクセス権を与えます。これにより,McGrey はサブシステムのディレクトリとイメージを管理できます。

5

SUPPIERS_ORDERS 識別子の保有者は,実行アクセス権を持っているため,サブディレクトリに置かれているファイルにアクセスできます。

6

ACCOUNTS_PAYABLE 識別子の保有者は,実行アクセス権を持っているため,サブディレクトリに置かれているファイルにアクセスできます。

7

他の識別子を有するユーザには,アクセス権が与えられません。

8

McGrey は Default 属性をすべての識別子 ACE に追加し,ここでそれらを記述しています。そのため,すべての識別子 ACE がサブディレクトリの ACL に継承されます。

13.9.2 サブシステムのディレクトリの保護

サブシステムのユーザは,サブシステム・イメージである ORDERS.EXE と PAYMENTS.EXE にアクセスする必要があるため,EXE.DIR ディレクトリには最上位ディレクトリと同じ保護が設定されています。もう 1 つのディレクトリである LIB.DIR にアクセスする必要があるのは,サブシステム・イメージと McGrey だけであるため,このディレクトリにはより厳しい保護が設定されています。

例 13-3 SYS$SYSDEVICE:[SUPPLIERS_SUBSYSTEM] の保護

$ DIRECTORY/SECURITY SYS$SYSDEVICE:[SUPPLIERS_SUBSYSTEM...]

Directory SYS$SYSDEVICE:[SUPPLIERS_SUBSYSTEM]

EXE.DIR;1        SUPPLIERS_SUBSYSTEM   (RWE,RWE,,)   1 
(CREATOR,ACCESS=NONE)
(DEFAULT_PROTECTION,SYSTEM:RWED,OWNER:RWED,GROUP:,WORLD:)
(IDENTIFIER=SUPPLIERS_SUBSYSTEM,ACCESS=READ+WRITE+CONTROL)
(IDENTIFIER=SUPPLIERS_ORDERS,ACCESS=EXECUTE)
(IDENTIFIER=ACCOUNTS_PAYABLE,ACCESS=EXECUTE)
(IDENTIFIER=*,ACCESS=NONE)
(IDENTIFIER=SUPPLIERS_SUBSYSTEM,OPTIONS=DEFAULT,ACCESS=READ+WRITE+CONTROL)
(IDENTIFIER=SUPPLIERS_ORDERS,OPTIONS=DEFAULT,ACCESS=EXECUTE)
(IDENTIFIER=ACCOUNTS_PAYABLE,OPTIONS=DEFAULT,ACCESS=EXECUTE)
(IDENTIFIER=*,OPTIONS=DEFAULT,ACCESS=NONE)

LIB.DIR;1       SUPPLIERS_SUBSYSTEM   (RWE,RWE,,)  2
(CREATOR,ACCESS=NONE)
(DEFAULT_PROTECTION,SYSTEM:RWED,OWNER:RWED,GROUP:,WORLD:)
(IDENTIFIER=SUPPLIERS_SUBSYSTEM,ACCESS=READ+WRITE+CONTROL)
(IDENTIFIER=*,ACCESS=NONE)
(IDENTIFIER=SUPPLIERS_SUBSYSTEM,OPTIONS=DEFAULT,ACCESS=READ+WRITE+CONTROL)
(IDENTIFIER=*,OPTIONS=DEFAULT,ACCESS=NONE)

Total of 2 files.
.
.
.
1

[SUPPLIERS_SUBSYSTEM.EXE] には, 13.9.1 項 「最上位ディレクトリの保護」 に示した親ディレクトリと同じ保護コードと ACL が設定されています。サブシステムのユーザは,このディレクトリに格納されているプログラムを実行する必要があります。

2

[SUPPLIERS_SUBSYSTEM.LIB] には,同じ保護コードが設定されていますが,サブシステム管理者とサブシステム・イメージだけがアクセスを必要とするため,ACL はより厳しいものになっています。

13.9.3 イメージおよびデータ・ファイルの保護

次の例に示すように,アクセスが必要な同社の担当者は,サブシステムのイメージである ORDERS.EXE と PAYMENTS.EXE にアクセスできます。ただし,データ・ファイルを更新できるのはそれらのイメージだけです。

例 13-4 サブシステムの ORDERS.EXE イメージおよび PAYMENTS.EXE イメージへのアクセス

Directory SYS$SYSDEVICE:[SUPPLIERS_SUBSYSTEM.EXE]

ORDERS.EXE;1   SUPPLIERS_SUBSYSTEM  (RWED,RWED,,)  1
(SUBSYSTEM,IDENTIFIER=SUPPLIERS_SUBSYSTEM,ATTRIBUTES=RESOURCE)
(IDENTIFIER=SUPPLIERS_SUBSYSTEM,ACCESS=READ+WRITE+CONTROL)
(IDENTIFIER=ACCOUNTS_PAYABLE,ACCESS=EXECUTE)
(IDENTIFIER=*,ACCESS=NONE)

PAYMENTS.EXE;1  SUPPLIERS_SUBSYSTEM  (RWED,RWED,,)  2
SUBSYSTEM,IDENTIFIER=SUPPLIERS_SUBSYSTEM,ATTRIBUTES=RESOURCE)
(IDENTIFIER=SUPPLIERS_SUBSYSTEM,ACCESS=READ+WRITE+CONTROL)
(IDENTIFIER=ACCOUNTS_PAYABLE,ACCESS=EXECUTE)
(IDENTIFIER=*,ACCESS=NONE)

Total of 2 files.

Directory SYS$SYSDEVICE:[SUPPLIERS_SUBSYSTEM.LIB]  3

ORDERS.DAT;1     SUPPLIERS_SUBSYSTEM  (RWED,RWED,,)
(IDENTIFIER=SUPPLIERS_SUBSYSTEM,ACCESS=READ+WRITE)
(IDENTIFIER=*,ACCESS=NONE)

PAYMENTS.DAT;1   SUPPLIERS_SUBSYSTEM  (RWED,RWED,,)
(IDENTIFIER=SUPPLIERS_SUBSYSTEM,ACCESS=READ+WRITE)
(IDENTIFIER=*,ACCESS=NONE)

Total of 2 files.

Grand total of 3 directories, 6 files.
1

SUPPLIERS_ORDERS 識別子または ACCOUNTS_PAYABLE 識別子を有するすべてのサブシステム・ユーザが ORDERS.EXE を実行できます。

2

サブシステム・イメージ,および ACCOUNTS_PAYABLE 識別子の保有者のみが PAYMENTS.EXE を実行できます。

3

サブシステム用のデータ・ファイルは [SUPPLIERS_SUBSYSTEM.LIB] にあります。 ここに配置されているファイルには,サブシステム・イメージと McGrey のみがアクセスできます。

13.9.4 プリンタの保護

小切手用のプリント・キューにもディレクトリやイメージと同等の保護が必要です。小切手用プリンタへのアクセスは,サブシステムおよび ACCOUNTS_PAYABLE 識別子の両方を有する唯一の人物である,信頼できる管理者に限定されます。 例 13-5 「キューの保護」は,信頼できる管理者だけがプリント・キューへジョブを送信できるようにプリント・キューが保護されていることを示します。

例 13-5 キューの保護

$ SHOW SECURITY/CLASS=QUEUE TTA1
TTA1 object of class QUEUE
     Owner: [SYSTEM]
     Protection: (System: M, Owner: D, Group, World)
     Access Control List:
          (IDENTIFIER=SUPPLIERS_SUBSYSTEM+ACCOUNTS_PAYABLE,-
           ACCESS=READ+SUBMIT+MANAGE+DELETE)
          (IDENTIFIER=*,ACCESS=NONE)

13.9.5 サブシステム構築のためのコマンド・プロシージャ

例 13-6 「サブシステム・コマンド・プロシージャ」は,R. D. Taylor 社のサブシステムの作成に使用したコマンド・プロシージャです。

例 13-6 サブシステム・コマンド・プロシージャ

$   SET NOON
$   OLD_PRIV = F$SETPRV("NOALL,SYSPRV,CMKRNL,OPER")
$   OLD_DEFAULT = F$ENVIRONMENT("DEFAULT")
$
$   ON CONTROL_Y THEN GOTO LEAVE
$
$   IF P1 .EQS. "REMOVE" THEN GOTO CLEANUP
$   IF P1 .EQS. "VERIFY" THEN SET VERIFY
$!
$! サブシステム識別子と,2 つの異なる作業を行う担当者のための
$! 識別子を作成する。
$!
$ SET DEFAULT SYS$SYSTEM
$ RUN AUTHORIZE
ADD/IDENTIFIER SUPPLIERS_SUBSYSTEM/ATTRIBUTES=(RESOURCE,SUBSYSTEM)
ADD/IDENTIFIER SUPPLIERS_ORDERS
ADD/IDENTIFIER ACCOUNTS_PAYABLE
!
! サブシステム管理者の McGrey にサブシステム識別子を 付与する。
!
GRANT/IDENTIFIER SUPPLIERS_SUBSYSTEM MCGREY/ATTRIBUTE=(RESOURCE,SUBSYSTEM)
$!
$! プリント・キューを設定する。

$!
$   INITIALIZE/QUEUE/START TTA1
$   SET SECURITY/ACL=(-
      (ID=SUPPLIERS_SUBSYSTEM+ACCOUNTS_PAYABLE,ACCESS=READ+SUBMIT+MANAGE+DELETE), -
      (ID=*,ACCESS=NONE) )/PROTECTION=(G,W)/CLASS=QUEUE TTA1:

$!
$! サブシステムを格納するルートのディレクトリを作成する。
$!
$!
$! McGrey としてログインしているものとする。
$!
$   SET RIGHTS_LIST/ENABLE SUPPLIERS_SUBSYSTEM/ATTRIBUTE=(RESOURCE,SUBSYSTEM)
$   SET DEFAULT SYS$SYSDEVICE:[SUPPLIERS_SUBSYSTEM]
$!
$! イメージとデータ・ファイルのためのディレクトリを作成する。
$!
$   CREATE/DIR [SUPPLIERS_SUBSYSTEM.EXE]/PROTECTION=(G,W)
$   CREATE/DIR [SUPPLIERS_SUBSYSTEM.LIB]/PROTECTION=(G,W)
$   SET SECURITY/ACL=( (ID=SUPPLIERS_ORDERS,ACCESS=EXECUTE), -
		      (ID=ACCOUNTS_PAYABLE,ACCESS=EXECUTE), -
		      (ID=SUPPLIERS_ORDERS,OPTIONS=DEFAULT,ACCESS=EXECUTE), -
		      (ID=ACCOUNTS_PAYABLE,OPTIONS=DEFAULT,ACCESS=EXECUTE) )/DELETE -
                      [SUPPLIERS_SUBSYSTEM]LIB.DIR
$!
$! サブシステム・イメージの作成をエミュレートする。
$!
$   SET DEFAULT [.EXE]
$   CREATE ORDERS.MAR
        .ENTRY	START,0
        $setpri_s pri=#0
10$:	BRB	10$
        ret
        .END  START
$   MACRO ORDERS
$   LINK ORDERS
$   SET SECURITY/PROTECTION=(W:RWED) ORDERS.MAR;*,.OBJ;*
$   DELETE ORDERS.MAR;*,.OBJ;*
$   COPY ORDERS.EXE PAYMENTS.EXE
$!
$! イメージに適切な保護を適用する。
$!
$   SET SECURITY/ACL=(ID=SUPPLIERS_ORDERS,ACCESS=EXECUTE)/DELETE PAYMENTS.EXE
$   SET SECURITY/ACL=(SUBSYSTEM,ID=SUPPLIERS_SUBSYSTEM,ATTRIBUTES=RESOURCE) ORDERS.EXE
$   SET SECURITY/ACL=(SUBSYSTEM,ID=SUPPLIERS_SUBSYSTEM,ATTRIBUTES=RESOURCE) PAYMENTS.EXE
$!
$! アプリケーションによって使用されるデータ・ファイルを作成して保護する。
$!
$   SET DEFAULT [-.LIB]
$   CREATE ORDERS.DAT
$   CREATE PAYMENTS.DAT
$   SET SECURITY/ACL=( (ID=SUPPLIERS_SUBSYSTEM,ACCESS=READ+WRITE), -
		      (ID=*,ACCESS=NONE) ) ORDERS.DAT
$   SET SECURITY/LIKE=(NAME=ORDERS.DAT) PAYMENTS.DAT
$!
$! ディレクトリ構造とキューの保護を表示する。
$!
$   SET DEFAULT 'OLD_DEFAULT'
$   DEFINE SYS$OUTPUT SUBSYS.LIS
$   DIRECTORY/SECURITY SYS$SYSDEVICE:[000000]SUPPLIERS_SUBSYSTEM.DIR
$   DIRECTORY/SECURITY SYS$SYSDEVICE:[SUPPLIERS_SUBSYSTEM...]

$   SHOW SECURITY/CLASS=QUEUE TTA1

$   DEASSIGN SYS$OUTPUT
$
$ LEAVE:
$   IF P1 .EQS. "VERIFY" THEN SET NOVERIFY
$   SET DEFAULT 'OLD_DEFAULT'
$   SET PROC/PRIV=('OLD_PRIV')
$   EXIT
$
$ CLEANUP:
$   SET PROC/PRIV=BYPASS
$   SET DEFAULT SYS$SYSDEVICE:[000000]
$   DELETE [SUPPLIERS_SUBSYSTEM...]*.*.*
$   DELETE [SUPPLIERS_SUBSYSTEM]EXE.DIR;
$   DELETE [SUPPLIERS_SUBSYSTEM]LIB.DIR;
$   DELETE SUPPLIERS_SUBSYSTEM.DIR;
$   STOP/QUE/NEXT TTA1
$   DELETE/QUEUE TTA1
$   GOTO LEAVE

印刷用画面へ
プライバシー 本サイト利用時の合意事項
© 2009 Hewlett-Packard Development Company, L.P.