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

HP OpenVMS: システム・セキュリティ・ガイド > パート II 一般ユーザのためのセキュリティ

第4章 データの保護

≫ 

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 ホーム
ここから本文が始まります

目次

4.1 ユーザのセキュリティ・プロファイルの内容
4.1.1 スレッド別セキュリティ
4.1.2 ペルソナ・セキュリティ・ブロック (PSB) データ構造体
4.1.3 以前のセキュリティ・モデル
4.1.4 スレッド別セキュリティのモデル
4.1.5 ユーザ識別コード (UIC)
4.1.6 ライト識別子
4.1.7 特権
4.2 オブジェクトのセキュリティ・プロファイル
4.2.1 保護オブジェクトの定義
4.2.2 オブジェクトのプロファイルの内容
4.2.3 セキュリティ・プロファイルの表示
4.2.4 セキュリティ・プロファイルの変更
4.2.5 オブジェクトのクラスの指定
4.2.6 プロファイルの変更に必要なアクセス権
4.3 システムによる保護オブジェクトへのユーザのアクセス可否の判定
4.4 ACL によるアクセスの制御
4.4.1 識別子用アクセス制御エントリ (ACE) の使用
4.4.2 特定ユーザへのアクセスの許可
4.4.3 オブジェクトへのユーザのアクセスの禁止
4.4.4 デバイスへのアクセスの制限
4.4.5 環境へのアクセスの制限
4.4.6 リスト内の ACE の順序
4.4.7 ファイルの継承方式の設定
4.4.8 ACL の表示
4.4.9 既存の ACL への ACE の追加
4.4.10 ACL の削除
4.4.11 ACL からの ACE の削除
4.4.12 ACL の部分的な置き換え
4.4.13 ファイルのデフォルト ACL の復元
4.4.14 ACL のコピー
4.5 保護コードによるアクセスの制御
4.5.1 保護コードの形式
4.5.2 保護コード内のアクセスのタイプ
4.5.3 保護コードの処理
4.5.4 保護コードの変更
4.5.5 機密オブジェクトに対する保護の強化
4.5.6 ディレクトリ構造に対するデフォルトの保護コードの提供
4.5.7 ファイルのデフォルト・セキュリティ・プロファイルの復元
4.6 特権と制御アクセス
4.6.1 保護メカニズムに対する特権の影響
4.6.2 制御アクセスによるオブジェクトのプロファイルの変更
4.6.3 アクセスに関するオブジェクト固有の考慮事項
4.7 保護オブジェクトの監査
4.7.1 システムが監査するイベントの種類
4.7.2 オブジェクトのクラスに対する監査の有効化
4.7.3 セキュリティ監査用 ACE の追加

この章では, 第2章 「OpenVMS のセキュリティ・モデル」で紹介したセキュリティ設計について,さらに詳しく説明します。OpenVMS オペレーティング・システムがユーザ・プロセスおよびアプリケーションによる保護オブジェクトへのアクセスをどのように制御するかを説明します。

簡単に言うと,Open VMS オペレーティング・システムは,共用可能な情報を含むすべてのオブジェクトへのアクセスを制御します。これらのオブジェクトを保護オブジェクトと呼びます。デバイス,ボリューム,論理名テーブル,ファイル,コモン・イベント・ フラグ・クラスタ,グループ・グローバル・セクション,システム・グローバル・セクション,資源ドメイン,キュー,ケーパビリティ,およびセキュリティ・クラスがこのカテゴリに入ります。アクセスするプロセスは,アクセス資格情報をライト識別子という形で持っています。一方,保護オブジェクトはすべて,当該オブジェクトに指定の方法でアクセスする権限を持つユーザを指定する一連のアクセス要件が設定されています。

この章では,次の内容を説明します。

第5章 「オブジェクト・クラスの詳細」では,保護オブジェクトのクラスごとの特徴を説明します。

4.1 ユーザのセキュリティ・プロファイルの内容

ユーザ・プロセスまたはアプリケーションのプロファイルには,以下の要素が含まれています。

  • ユーザを識別するためのユーザ識別コード (UIC)

  • プロセスが保持するライト識別子

  • (あれば) 特権

4.1.1 スレッド別セキュリティ

OpenVMS Alpha バージョン 7.2 には,スレッド・レベルのセキュリティが実装されています。この機能はスレッド別セキュリティと呼ばれ,これによって,マルチスレッド・プロセスの実行スレッドごとに,プロセス内の他のスレッドのセキュリティ・プロファイルに影響を与えることなく,独立したセキュリティ・プロファイルを使用できます。

セキュリティ・プロファイルの情報は,以前はプロセス・レベルの各種データ構造体やデータ・セルに分散していましたが,現在は PSB (ペルソナ・セキュリティ・ブロック) と呼ばれる単一のデータ構造体に格納されており,それが個々の実行スレッドにバインドされています。これに合わせて,OpenVMS 内の関連する参照も参照先が変更されています。システム内のあらゆるプロセスに,プロセスのナチュラル・ペルソナとなる PSB が少なくとも 1 つあります。ナチュラル・ペルソナは,プロセスの作成時に作成されます。

スレッド・マネージャ (たとえば,HP POSIX Threads Library に組み込まれているスレッド・マネージャ) とセキュリティ・サブシステムのやり取りにより,スレッドの実行がスケジューリングされている間にプロファイルが自動的に切り替えられます。

4.1.2 ペルソナ・セキュリティ・ブロック (PSB) データ構造体

ユーザのセキュリティ・プロファイル (特権,権限,および識別情報) は,プロセス・レベルからユーザ・スレッド・レベルに移行しています。これまで複数のデータ構造体 (アクセス・ライト・ブロック (ARB),プロセス制御ブロック (PCB),プロセス・ヘッダ・ディスクリプタ (PHD),ジョブ情報ブロック (JIB),制御 (CTL) リージョン・フィールド) に格納されていたセキュリティ情報は,ペルソナ・セキュリティ・ブロック (PSB) という新しいデータ構造体に移され,これに合わせて参照先がすべて変更されています。これらのデータ構造体に含まれるフィールドの一部は,現在の OpenVMS では使用されていません。該当するフィールドは,使用廃止されたものと見なされています。『OpenVMS リリース・ノート』の「廃止されたデータ・セルとセキュリティ情報の新しい場所」という表を参照してください。

それぞれのプロセスに,そのプロセスに割り当てられているすべてのペルソナ・ブロックのアドレスを格納したペルソナ配列があります。

新しいペルソナ・ブロック (PSB) には,以下の情報が格納されています。

  • UIC

  • ペルソナ,およびシステム・ライト・チェーン

  • 永続的な,許可された,有効な特権

  • アカウント名

  • ユーザ名

  • 監査フラグとカウンタ

カーネル・スレッド・ブロック (KTB) は,現在アクティブなスレッドのペルソナ・ブロックを指します。

4.1.3 以前のセキュリティ・モデル

OpenVMS の以前のバージョンでは,ユーザのセキュリティ・プロファイルを構成する情報がプロセス・レベルでバインドされ,プロセス内のすべての実行スレッドで共用されていました。この関係を 図 4-1 「以前のスレッド別セキュリティのモデル」 に示します。

図 4-1 以前のスレッド別セキュリティのモデル

以前のスレッド別セキュリティのモデル

スレッド間でどのようにプロファイルの管理を行うかによって,あるスレッドがセキュリティ・プロファイルに加えた変更が他のスレッドから見える可能性があります。

4.1.4 スレッド別セキュリティのモデル

OpenVMS バージョン 7.2 では,各実行スレッドが他のスレッドとセキュリティ・プロファイルを共用することもできますが,そのスレッド専用のセキュリティ・プロファイルを持つこともできます。これらの関係を 図 4-2 「スレッド別セキュリティ・プロファイルのモデル」 に示します。

図 4-2 スレッド別セキュリティ・プロファイルのモデル

スレッド別セキュリティ・プロファイルのモデル

以前のモデルと同じように,共用のプロファイルに加えた変更はプロファイルを共用するすべてのスレッドから見える可能性があります。一方,スレッド専用のセキュリティ・プロファイルに加えた変更は,特定のスレッドにのみ適用されます。

4.1.5 ユーザ識別コード (UIC)

サブジェクトのセキュリティ・プロファイルの最初の要素は,ユーザ識別コード (UIC) です。UIC から,ユーザが属するシステム・グループと,そのグループ内でユーザを一意に識別するための情報が得られます。

4.1.5.1 UIC の形式

UIC を指定するときは必ず大括弧で囲みますが,形式にはいくつかの種類があります。有効な形式を以下に示します。

  • 英数字形式の UIC は,メンバ名と (必要に応じて) グループ名で構成されます。

    [メンバ]

    または

    [グループ,メンバ]

    グループ名とメンバ名には,それぞれ最大 31 文字の英数字 (そのうち少なくとも 1 文字は英字) で構成することができます。これらの名前には,大文字と小文字の A ~ Z,ドル記号 ($),アンダースコア (_),および数字の 0 ~ 9 で構成できます。

  • 数値形式の UIC は,グループ番号とメンバ番号で構成されます。

    [グループ,メンバ]

    グループ番号には 1 ~ 37776 の 8 進数を指定し,メンバ番号には 0 ~ 177776 の 8 進数を指定します。グループ番号とメンバ番号を指定するときは,先頭のゼロを省略できます。 グループ 1 とグループ 300 ~ 377 は,HP によって予約されています。

次の表に,適切な形式で指定した UIC の例を示します。

UIC のタイプ意味

英数字形式

[USER,FRED]

グループ名が USER で,メンバ名が FRED。

 

[EXEC,JONES]

グループ名が EXEC で,メンバ名が JONES。

 

[JONES]

グループ名が EXEC で,メンバ名が JONES。

数値形式

[200,10]

グループ番号が 200 で,メンバ番号が 10。

 

[3777,3777]

グループ番号が 3777 で,メンバ番号が 3777。

JONES というメンバ名を持てるユーザは 1 人だけなので,JONES は EXEC グループに属する必要があります。

4.1.5.2 UIC 作成に関するガイドライン

UIC を恣意的に割り当てることはできません。UIC を作成するセキュリティ管理者は,以下のガイドラインを守る必要があります。

  • メンバ名は,システムの各メンバに固有のものでなければなりません。

  • 1 人のメンバが複数の UIC グループに属することはできません。

以下のガイドラインは,システムが UIC をグループ番号とメンバ番号を表す 32 ビットの値に変換するので必要となります。32 ビットのうち,上位 16 ビットがグループ番号,下位 16 ビットがメンバ番号になります。オペレーティング・システムは,[J_JONES] のような英数字形式の UIC を変換するとき,英数字形式の UIC のメンバの部分を数値形式の UIC のグループとメンバの部分の両方に等しいものと見なします。この結果得られる 32 ビットの数値形式の UIC は,ライト・データベース (識別子,識別子の属性,および識別子の保持者を格納するファイル) に保存されます。たとえば,JONES というメンバに対応する数値形式の UIC は 1 つしか存在し得ないので,同じシステム上で [GROUP1,JONES] という UIC と [GROUP2,JONES] という UIC を作成することはできません。通常,英数字形式の UIC のメンバ名は,それに対応するログイン・ユーザ名と同じです。

4.1.5.3 プロセスによる UIC の取得

ユーザがシステムにログインすると,システム・ユーザ登録ファイル (SYSUAF.DAT) のユーザ登録 (UAF) レコードからユーザの UIC がコピーされ,ユーザのプロセスに割り当てられます。これは,そのプロセスが存続する間の識別情報になります。

デフォルトでは,独立プロセス (DCL の SUBMIT コマンドまたは RUN コマンドで作成されたもの) とサブプロセス (DCL の SPAWN コマンドで作成されたもの) の UIC は,プロセスの作成者と同じ UIC になります。IMPERSONATE 特権を持つユーザは,(RUN コマンドに /UIC 修飾子を指定することにより) 異なる UIC を持つ独立プロセスを作成できます。

4.1.6 ライト識別子

サブジェクトのセキュリティ・プロファイルの 2 番目の要素は,一連のライト識別子です。

ライト識別子は,個々のユーザまたはユーザ・グループを表します。セキュリティ管理者は,登録ユーティリティ (AUTHORIZE) を使用して識別子の作成と削除,およびこれらの識別子のユーザへの割り当てを行えます。ユーザは必要な期間のみ特定の識別子を保持するので,ライト識別子によるユーザ・グループの識別は一時的な方法です。

4.1.6.1 識別子のタイプ

OpenVMS オペレーティング・システムでは,複数のライト識別子のタイプをサポートしています。アクセス制御に最も一般的な使用される識別子を 表 4-1 「主なライト識別子のタイプ」 に示します。

表 4-1 主なライト識別子のタイプ

タイプ説明形式

環境識別子

ユーザが最初にシステムにログインしたときの情報に基づいてユーザを分類します。

システムによって自動的に生成される英数字文字列です。詳細については, 3.4 項 「ログインのタイプとログイン・クラス」を参照してください。

BATCH,NETWORK,INTERACTIVE,LOCAL,DIALUP,REMOTE

汎用識別子

セキュリティ管理者が定義します。

1 ~ 31 文字の英数字文字列 (そのうち少なくとも 1 文字は英字) です。有効な文字は,数字の 0 ~ 9,大文字と小文字の A ~ Z,ドル記号 ($),およびアンダースコア (_) です。

SALES,PERSONNEL,DATA_ENTRY,RESERVE_DESK

UIC 識別子

システムのユーザを一意に識別し,そのユーザが属するグループを定義するユーザ識別コード (UIC) に基づきます。

英数字形式の UIC を使用します。大括弧は付けなくても構いません。有効な文字は,汎用識別子と同じです。

[GROUP1,JONES],[JONES],GROUP1,JONES

機能識別子

アプリケーションが定義します。

汎用識別子と同じです。詳細については,『HP OpenVMS Programming Concepts Manual』を参照してください。

DBM$MOD_SCHEMA

 

表 4-1 「主なライト識別子のタイプ」 に挙げた識別子の他に,SYS$SYSTEM の STARTUP.COM システム・スタートアップ・プロシージャが SYS$NODE_ノード名という形式のシステム・ノード識別子を作成します。

4.1.6.2 プロセス・ライト・リストとシステム・ライト・リスト

ユーザのプロセスには,そのプロセスに割り当てられたすべての識別子を含んだライト・リストが関連付けられています。また,システムのすべてのユーザが共用するシステム・ライト・リストもあります。システム管理者またはシステム・ソフトウェアが,システムに現在ログインしているすべてのユーザに割り当てられる識別子をシステム・ライト・リストに割り当てます。

4.1.6.3 プロセスのライト識別子の表示

現在のプロセスに割り当てられている識別子は,次のように SHOW PROCESS コマンドを使用して表示できます。

$ SHOW PROCESS/ALL
25-JUN-2001 15:23:18.08   User: GREG            Process ID:   34200094
                          Node: ACCOUNTS        Process name: "_TWA2:"

Terminal:           TWA2:
User Identifier:    [DOC,GREG]      1
Base priority:      4
Default file spec:  WORK1:[GREG.FISCAL_91]

Devices allocated:  ACCOUNTS$TWA2:

Process Quotas:
.
.
. Process rights:   INTERACTIVE     2   LOCAL           3  SALES           4   MINDCRIME            resource    5 System rights: SYS$NODE_ACCOUNTS 6

上記の SHOW PROCESS コマンドの出力には,次の 3 種類の識別子が表示されています。

1

Greg というユーザが DOC グループのメンバであることを示す UIC 識別子

2

Greg が会話型ユーザであることを示す環境識別子

3

Greg がローカルでログインしていることを示す環境識別子

4

Greg が SALES グループのメンバでもあることを示す汎用識別子

5

Greg が Resource 属性を含む MINDCRIME 識別子を持っていて,この識別子にディスク容量を割り当てることができることを示す汎用識別子

6

Greg が ACCOUNTS ノードから作業していることを示す環境識別子

4.1.6.4 監査証跡に現れるライト識別子

プロセスのライト識別子は,監査レコードにも現れます。セキュリティ管理者がオブジェクトへのアクセスを監査するようにオペレーティング・システムを設定すると,オブジェクトにアクセスしたユーザとそのアクセスの日時を記録したレコードが生成されます。単独の監査レコードから十分な情報が得られることはまれですが,長期にわたって蓄積されたレコードを追跡すると,何らかの活動のパターンが浮かび上がることがあります。

次の監査レコードは,Greg がファイルの削除を試みたが,MINDCRIME 識別子を持っているために失敗したことを示しています。93_FORECAST.DAT ファイルには,MINDCRIME 識別子を有するプロセスによるアクセスを禁止する ACE が設定されています。これを示すのが,"Event information","Matching ACE",および "Status" の各行です。

Message from user AUDIT$SERVER on FNORD
Security alarm (SECURITY) and security audit (SECURITY) on ACCOUNTS, system id: 19662
Auditable event:     Object deletion
Event information:   file deletion request (IO$_DELETE)
Event time:          24-APR-2001 13:17:24.59
PID:                 34200094
Process name:        _TWA2:
Username:            GREG
Process owner:       [DOC,GREG]
Terminal name:       TWA2:
Image name:          DSA2264:[SYS51.SYSCOMMON.][SYSEXE]DELETE.EXE
Object class name:   FILE
Object owner:        [SYSTEM]
Object protection:   SYSTEM:RWEDC, OWNER:RWEDC, GROUP:RE, WORLD:RE
File name:           _DSA2200:[GREG]93_FORECAST.DAT;1
File ID:             (17481,6299,1)
Access requested:    DELETE
Matching ACE:        (IDENTIFIER=MINDCRIME,ACCESS=NONE)
Sequence key:        00008A41
Status:              %SYSTEM-F-NOPRIV, no privilege for attempted operation

4.1.7 特権

サブジェクトのセキュリティ・プロファイルの 3 番目の (省略可能な) 要素は,一連の特権です。

特権を持つことにより,通常は拒否されるシステム機能を使用または実行できるようになります。セキュリティ管理者は,特別な事情で既存の保護登録情報を変更せずにユーザに必要なタスクを実行させたいときに,そのユーザに特権を与えることができます。

特権のタイプによって,実行できるタスクは異なります。たとえば,ネットワーク経由のメール送受信を可能にする NETMBX と TMPMBX のように,通常のネットワーク操作を実行するための特権もあります。しかし,SYSNAM のように,システムの動作を左右する能力を与える特権もあります。SYSNAM 特権を有するユーザは,システム論理名テーブルを変更できます。

ユーザの特権は,ユーザの UAF レコードに 64 ビットの特権マスクとして記録されます。ユーザがシステムにログインすると,ユーザの特権ベクタがサブジェクト (プロセス) のセキュリティ・プロファイルに保存されます。

ユーザに許可された特権を,DCL の SET PROCESS/PRIVILEGES コマンドを使用して有効または無効にすることにより,ユーザが実行するイメージに適用可能な特権を制御できます。 例 4-1 「プロセスの許可された特権とデフォルト特権」 は,Puterman というユーザに多くの特権が与えられており,必要に応じてそれらを使用できるけれども,Puterman のプロセスがデフォルトでは NETMBX と TMPMBX の 2 つの特権のみが有効な状態で実行されることを示しています。

例 4-1 プロセスの許可された特権とデフォルト特権

$ SHOW PROCESS/PRIVILEGE

 8-OCT-2001 16:58:58.77	 User: PUTERMAN    	Process ID:   27E00496
			 Node: FNORD     	Process name: "Hobbit"

Authorized privileges:
 ACNT     ALLSPOOL  ALTPRI   AUDIT    BUGCHK   BYPASS  CMEXEC    CMKRNL
 DIAGNOSE DOWNGRADE EXQUOTA  GROUP    GRPNAM   GRPPRV  IMPERSONATE IMPORT
 LOG_IO   MOUNT     NETMBX   OPER     PFNMAP   PHY_IO  PRMCEB    PRMGBL
 PRMMBX   PSWAPM    READALL  SECURITY SETPRV   SHARE   SHMEM     SYSGBL
 SYSLCK   SYSNAM    SYSPRV   TMPMBX   UPGRADE  VOLPRO  WORLD

Process privileges:
 NETMBX               may create network device
 TMPMBX               may create temporary mailbox

Puterman は,必要に応じて許可された特定の特権を有効にできます。たとえば,スプールされたデバイスを割り当てるには ALLSPOOL 特権が必要であり,論理入出力操作を実行するには LOG_IO 特権が必要です。

4.2 オブジェクトのセキュリティ・プロファイル

4.2.1 保護オブジェクトの定義

OpenVMS オペレーティング・システムで保護が必要となるオブジェクトは,いずれも情報の格納や受け取りに使用される受動的な格納場所です。これらのオブジェクトを保護するのは,オブジェクトにアクセスが可能になったユーザはそのオブジェクト内の情報にもアクセスできるためです。保護オブジェクトには,次のようなものがあります。

  • メモリやストレージ・デバイス上のファイル

  • ハードウェア・デバイスや仮想デバイス

  • コモン・イベント・フラグ・クラスタや論理名テーブルなどのデータ構造

OpenVMS で保護されるオブジェクトのクラスの一覧は, 4.2.5 項 「オブジェクトのクラスの指定」にあります。各クラスの詳細については, 第5章 「オブジェクト・クラスの詳細」を参照してください。

4.2.2 オブジェクトのプロファイルの内容

オブジェクトのセキュリティ要素が,オブジェクトのセキュリティ・プロファイルを構成します。オブジェクトのセキュリティ・プロファイルには,以下の情報が格納されています。

  • オブジェクトの所有者。システムが保護コードを解釈するときに,この要素が使用されます。

  • システム,所有者,グループ,ワールドの各カテゴリに基づいてオブジェクトへのアクセスを定義する保護コード。この保護コードによって,さまざまなカテゴリのユーザが制御されます。

  • 個々のユーザまたはユーザ・グループごとにオブジェクトへのアクセスを制御するアクセス制御リスト (ACL)

ファイル以外の新しいオブジェクトは,システムによって提供されるテンプレート・プロファイルのセキュリティ要素を継承します。サイトのセキュリティ管理者は,これらのセキュリティ要素を変更できます。ファイルにはさらに複雑な継承メカニズムがあり,新しいオブジェクトのセキュリティ要素をさらに細かく制御できます。いずれの場合も,オブジェクトの作成時にセキュリティ要素を割り当てることにより,オペレーティング・システムのデフォルト設定の使用を避けることができます。

この節では,保護コードと ACL の概要を示します。 4.4 項 「ACL によるアクセスの制御」4.5 項 「保護コードによるアクセスの制御」では,これらの保護メカニズムについてさらに詳しく説明します。個々のオブジェクト・クラスの詳細については, 第5章 「オブジェクト・クラスの詳細」を参照してください。

4.2.2.1 所有者

オブジェクトのセキュリティ・プロファイルの最初の要素は,オブジェクト所有者の UIC です。

ほとんどの場合,オブジェクトを作成したユーザがそのオブジェクトの所有者になります。オブジェクトの所有者は,所有するオブジェクトのセキュリティ・プロファイルを変更できます。システムはユーザの UIC をオブジェクトに自動的に割り当て,それに基づいてアクセスを制御します。

所有権に関する規則には,いくつかの例外があります。資源識別子によって所有されるファイルには,UIC がありません。資源識別子が所有するディレクトリにユーザがファイルを作成すると,そのファイルは (ファイルを作成したユーザではなく) 資源識別子によって所有されます ( 5.4.5 項 「プロファイルの割り当て」を参照)。各オブジェクト・クラスの所有権規則については, 第5章 「オブジェクト・クラスの詳細」を参照してください。

ファイルを除くオブジェクトの所有者は, 4.2.4 項 「セキュリティ・プロファイルの変更」で説明するように,SET SECURITY/OWNER コマンドを使用して所有権を他のユーザに再割り当てできます。ファイルの所有者を変更するには,通常,特権が必要です ( 5.4.2 項 「アクセスのタイプ」を参照)。

4.2.2.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 項 「保護コードによるアクセスの制御」を参照してください。

4.2.2.3 アクセス制御リスト (ACL)

オブジェクトのセキュリティ・プロファイルの 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 とその使用方法についてさらに説明を加えます。

4.2.3 セキュリティ・プロファイルの表示

保護オブジェクトのセキュリティ・プロファイルを表示するには,DCL の SHOW SECURITY コマンドを使用します。たとえば,次のコマンドは 93_FORECAST.TXT というファイルのセキュリティ情報を要求します。

$ SHOW SECURITY 93_FORECAST.TXT

WORK_DISK$:[GREG]93_FORECAST.TXT;1 object of class FILE
      Owner: [ACCOUNTING,GREG]
      Protection: (System: RWED, Owner: RWED, Group: RE, World)
      Access Control List: <empty>

表示結果から,93_FORECAST.TXT が Greg というユーザによって所有されていることがわかります。また,このファイルの保護コードも表示されています。保護コードにより,システム・ユーザと所有者に対して読み込み,書き込み,実行,削除の各アクセス権が与えられています。また,グループ・ユーザに対しては読み込みと実行のアクセス権が与えられ,ワールド・ユーザに対してはアクセス権が与えられていません。詳細については, 4.5 項 「保護コードによるアクセスの制御」を参照してください。このファイルには,ACL はまだ設定されていません。

4.2.4 セキュリティ・プロファイルの変更

SET SECURITY コマンドを使用して,保護オブジェクトの所有者,保護コード,ACL に対して新しい値を指定したり,オブジェクト間でプロファイルをコピーしたりできます。

たとえば, 4.2.3 項 「セキュリティ・プロファイルの表示」に示した SHOW SECURITY の表示結果から,93_FORECAST.TXT が Greg というユーザによって所有されていることがわかります。このユーザは,所有者としてこのファイルの保護コードを変更できます。変更前の保護コードでは,ワールド・ユーザに対してアクセス権が与えられていません。ここでは,Greg が次のように保護コードを変更して,ワールド・ユーザに読み込みと書き込みの各アクセスを許可します。

$ SET SECURITY/PROTECTION=(W:RW) 93_FORECAST.TXT

このファイルの新しい保護コードを確認するには,次のように SHOW SECURITY コマンドを使用します。

$ SHOW SECURITY 93_FORECAST.TXT

93_FORECAST.TXT object of class FILE

     Owner: [GREG]
     Protection: (System: RWED, Owner: RWED, Group: RE, World: RW)
     Access Control List: <empty>

プロファイル内の他の要素の変更方法については, 4.2.5 項 「オブジェクトのクラスの指定」で説明します。保護コードと ACL の詳細については, 4.4 項 「ACL によるアクセスの制御」4.5 項 「保護コードによるアクセスの制御」で説明します。SET SECURITY コマンドと SHOW SECURITY コマンドの詳細については,『OpenVMS DCL ディクショナリ』を参照してください。

4.2.5 オブジェクトのクラスの指定

特定の動作を行い,共通の属性のセットを持つオブジェクトのグループは,クラスに分けられます。ファイル,キュー,およびボリュームがその代表的な例です。 表 4-2 「保護オブジェクトのクラス」 に示すように,OpenVMS オペレーティング・システムでは 11 の保護オブジェクトのクラスがサポートされています。

オブジェクトのプロファイルを変更するときは,SET SECURITY コマンドにオブジェクトのクラスを指定する必要があります。指定しなかった場合,オブジェクトがファイルであると見なされます。

たとえば,次のコマンド・シーケンスはオブジェクトのプロファイルを変更しますが,/CLASS 修飾子によって LNM$GROUP オブジェクトを論理名テーブルとして識別しています。

$ SET SECURITY /CLASS=LOGICAL_NAME_TABLE-
_$ /OWNER=ACCOUNTING /PROTECTION=(S:RWCD, O:RWCD, G:R, W:R)-
_$ /ACL=((IDENTIFIER=CHEKOV,ACCESS=CONTROL),-
_$  (IDENTIFIER=WU,ACCESS=READ+WRITE)) LNM$GROUP

この SET SECURITY コマンドによって,Accounting グループを論理名テーブルの所有者に設定しています。また,保護コードを変更して,所有者とシステム・ユーザに対して読み込み,書き込み,作成,および削除のアクセス権を許可し,グループ・ユーザとワールド・ユーザに許可するアクセス権を読み込みに限定しています。最後に,ACL を作成して,Chekov というユーザに制御アクセスを許可し,Wu というユーザに読み込みと書き込みのアクセスを許可しています。

変更結果を表示するには,次のように SHOW SECURITY コマンドを使用します。

$  SHOW SECURITY LNM$GROUP /CLASS=LOGICAL_NAME_TABLE

LNM$GROUP object of class LOGICAL_NAME_TABLE

     Owner: [ACCOUNTING]
     Protection: (System: RWCD, Owner: RWCD, Group: R, World: R)
     Access Control List:
          (IDENTIFIER=[USER,CHEKOV],ACCESS=CONTROL) 
          (IDENTIFIER=[USER,WU],ACCESS=READ+WRITE) 

表 4-2 保護オブジェクトのクラス

クラス名定義

ケーパビリティ

システムによってアクセスが制御される資源。現時点で定義されているケーパビリティは,ベクタ・プロセッサだけです。

コモン・イベント・フラグ・クラスタ

プロセス同士が連携してイベント通知を相互に通知できるようにするために,32 個のイベント・フラグをセットにしたもの。

デバイス

プロセッサに接続された周辺機器のクラスの 1 つで,データの受信,格納,または伝送が可能なもの。

ファイル

Files-11 オン・ディスク構造レベル 2 または 5 のファイルおよびディレクトリ。

グループ・グローバル・セクション

同じグループ内のすべてのプロセスが使用できる共用可能なメモリ・セクション。

論理名テーブル

システムまたは特定のグループに関する論理名とその等価名を格納した共用可能なテーブル。

キュー

バッチ,ターミナル,サーバ,またはプリント・ジョブ・キューで処理される一連のジョブ。

資源ドメイン

ロック・マネージャの資源へのアクセスを制御するネームスペース。

セキュリティ・クラス

セキュリティ・クラスのすべてのメンバに関する要素と管理ルーチンを格納するデータ構造。

システム・グローバル・セクション

システム内のすべてのプロセスが使用できる共用可能なメモリ・セクション。

ボリューム

ディスクやテープなどの,ODS-2 形式または ODS-5 形式の大容量ストレージ媒体。ボリュームは,ファイルを格納するもので,デバイスにマウントすることができます。

 

個々のクラスの詳細については, 第5章 「オブジェクト・クラスの詳細」を参照してください。

4.2.6 プロファイルの変更に必要なアクセス権

セキュリティ・プロファイルを変更するには,オブジェクトに対する制御アクセス権が必要です。制御アクセス権は,ACL では明示的に与えられるの対し,保護コードでは所有者カテゴリまたはシステム・カテゴリに属するユーザに対して暗黙のうちに与えられます。制御アクセス権の獲得方法の詳細については, 4.6.2 項 「制御アクセスによるオブジェクトのプロファイルの変更」を参照してください。

4.3 システムによる保護オブジェクトへのユーザのアクセス可否の判定

ユーザが保護オブジェクトにアクセスしようとすると,OpenVMS オペレーティング・システムは保護チェック ($CHKPRO) システム・サービスを呼び出して,ユーザ・プロセスのセキュリティ・プロファイルとオブジェクトのセキュリティ・プロファイルを比較します。保護チェックでは,$CHKPRO がユーザのセキュリティ・プロファイルと保護オブジェクトのプロファイルを以下の順序で比較します。

  1. アクセス制御リスト (ACL) を評価します。

    オブジェクトに ACL がある場合,システムはユーザのライト識別子のいずれかと一致するエントリがないかどうか ACL を検索します。一致するアクセス制御エントリ (ACE) が見つかった場合,システムはアクセスを許可または拒否し,ACL のチェックをそこで終了します。

    一致する ACE でアクセスが拒否されている場合でも,ユーザは保護コードのシステム・フィールドと所有者フィールド,または特権によってアクセス権を取得できます。ACL に一致する ACE がない場合,システムは保護コードのすべてのフィールドをチェックします。

  2. 保護コードを評価します。

    ACL でアクセスが許可されず,オブジェクトの所有者の UIC がゼロでない場合 [1] ,オペレーティング・システムは保護コードを評価します。 OpenVMS オペレーティング・システムは,ユーザ識別コード (UIC) とオブジェクトの保護コードの関係に基づいてアクセスを許可または拒否します。

    ACL によってアクセスが拒否されている場合,システムは保護コード内の 2 つのフィールド (システム・フィールドと所有者フィールド) を調べて,ユーザにアクセスが許可されているかどうかを判定します。ユーザは,システム・カテゴリまたは所有者カテゴリに属するか,特権を与えられることにより,アクセス権を獲得できます。(同じグループ UIC の) GRPPRV または SYSPRV を持っているユーザは,保護コードのシステム・カテゴリに指定されているアクセス権を与えられます。

  3. 特別な特権を確認します。

    ACL または保護コードによってアクセスが許可されない場合は,特権が評価されます。

    特定のシステム特権を持つユーザには,ACL または保護コードによる保護に関係なくアクセス権が与えらる場合があります。バイパス特権 (BYPASS), グループ特権 (GRPPRV), 全読み込み特権 (READALL), およびシステム特権 (SYSPRV) は, その特権保持者がオブジェクトに対して持っているアクセス権を強化します。特権によるアクセス権への影響の詳細については, 4.6.1 項 「保護メカニズムに対する特権の影響」を参照してください。

  4. アクセス権に対する変更を評価します。

    一部のオブジェクト・クラスでは,代替特権に基づいてアクセスが許可されることがあります。たとえば,キュー・オブジェクトでは,オペレータ特権 (OPER) を持つユーザに対してすべてのキューへのフル・アクセスが許可されます。また,論理名テーブル・オブジェクトでは,システム名特権 (SYSNAM) を持つユーザに対してシステム・テーブルへのアクセスが許可されます。

図 4-3 「アクセス要求評価のフローチャート」 は,OpenVMS オペレーティング・システムがアクセス要求を評価する手順と,アクセスを制御する要素 (ACL,保護コード,特権,およびアクセス権の変更) の相互関係を示した図です。

図 4-3 アクセス要求評価のフローチャート

アクセス要求評価のフローチャート

図 4-4 アクセス要求評価のフローチャート (続き)

アクセス要求評価のフローチャート (続き)

図 4-5 アクセス要求評価のフローチャート (続き)

アクセス要求評価のフローチャート (続き)

図 4-6 アクセス要求評価のフローチャート (続き)

アクセス要求評価のフローチャート (続き)

図 4-7 アクセス要求評価のフローチャート (続き)

アクセス要求評価のフローチャート (続き)

4.4 ACL によるアクセスの制御

4.2.2.3 項 「アクセス制御リスト (ACL)」では,オブジェクトのセキュリティ・プロファイルを構成する要素の 1 つとしてアクセス制御リスト (ACL) を紹介しました。この節では,この保護メカニズムをさらに詳しく説明し,ACL を使ってオブジェクトを効果的に保護する方法の例を示します。

ほとんどの場合,オペレーティング・システムがオブジェクトに自動的に割り当てる保護コードで十分なため,多くのユーザは ACL について気にする必要がありません。しかし,特定のユーザに自分のファイルへのアクセスを許可する必要が生じることがあります。たとえば,同じプロジェクトで作業をしている場合などです。ACL は,重要なシステム・ファイル,デバイス,ボリューム,その他の保護オブジェクトを保護するための効果的なメカニズムなので,システム管理者やセキュリティ管理者は,一般ユーザよりも頻繁に ACL を使用します。

4.4.1 識別子用アクセス制御エントリ (ACE) の使用

アクセス制御リスト (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 というファイルを読めるようにするには,次のコマンドを入力します。

$ SET SECURITY/ACL=(IDENTIFIER=FRED,ACCESS=READ) PROJECT-DATA.TXT

"FRED" はユーザ識別コード (UIC) のメンバ名です。したがって,Fred に PROJECT-DATA.TXT ファイルへの読み込みアクセスを許可するエントリの UIC 識別子として機能します。

4.4.2 特定ユーザへのアクセスの許可

個々のユーザまたはユーザ・グループの権限は識別子によって定義される ( 4.1.6.1 項 「識別子のタイプ」を参照) ので,それらを識別子用 ACE に指定することによって,それらを保持するユーザに許可 (または拒否) するアクセスを定義します。システム上の個々のユーザまたはユーザ・グループは,UIC 識別子によって簡単に識別できます。それぞれが異なる機能グループ (つまり,さまざまな UIC グループ) に属するユーザのグループの全員が,ある保護オブジェクトへのアクセス権を必要とする場合,セキュリティ管理者は汎用識別子を作成し,アクセス権を必要としているすべてのユーザにその識別子を付与します。

たとえば,次のコマンドは UIC 識別子 [PAT] によって識別される Pat というユーザに,DISK1 上の ROBERTS ディレクトリ内のファイルに対する読み込み,書き込み,および実行アクセスを許可します。この ACL では,アクセス・ステートメントから削除アクセスと制御アクセスが除外されているため,Pat によるこれらのアクセスは拒否されます。

$ SET SECURITY/ACL=(IDENTIFIER=[PAT],ACCESS=READ+WRITE+EXECUTE)-
_$ DISK1:[ROBERTS]JULY-SALES.TXT

セキュリティ管理者は,登録ユーティリティを使用して汎用識別子を作成し,これを使用するすべてのユーザに与えます。たとえば,セキュリティ管理者が PAYROLL という識別子を作成し,それを給与計算ファイルにアクセスする必要がある従業員に割り当てたとします。この識別子の保持者が実際に給与計算ファイルにアクセスするには,管理者がそのファイルに識別子用 ACE を追加する必要があります。たとえば,次のコマンドは PAYROLL ファイルの ACL を作成し,PAYROLL 識別子の保持者にこのファイルへの読み込みアクセス権を与えます。

$ SET SECURITY/ACL=(IDENTIFIER=PAYROLL,ACCESS=READ) PAYROLL.DAT

ACL 内の ACE の順序は,オペレーティング・システムによる処理の規則に関わるので重要です。ACE の順序については, 4.4.6 項 「リスト内の ACE の順序」を参照してください。

4.4.3 オブジェクトへのユーザのアクセスの禁止

識別子用 ACE は,オブジェクトへのアクセスを許可する場合だけでなく,オブジェクトへの特定のユーザのアクセスを拒否する場合にも頻繁に使用されます。サイトによっては,モデムやネットワークを介してログインするユーザを制限するために ACL を使用する場合があります。また,高価な装置や機密ファイルの入ったボリュームに ACE を設定して,それらへのアクセスを制限する場合もあります。

特定の識別子の保持者に対してすべてのアクセスを拒否するには,アクセス・タイプ名として NONE キーワードを指定します。たとえば,次のコマンドは環境識別子 DIALUP の保持者に対して,PROJECT-ACCOUNTS ディレクトリ内のファイルへのあらゆるアクセスを拒否します。

$ SET SECURITY/ACL=(IDENTIFIER=DIALUP,ACCESS=NONE)-
_$ /CLASS=FILE PROJECT-ACCOUNTS.DIR

NONE キーワードを使ってアクセスを拒否する場合は,他にもいくつか考慮すべきことがあります。 4.4.6 項 「リスト内の ACE の順序」で説明するように,OpenVMS オペレーティング・システムでは最初に一致する ACE に基づいてアクセスが許可または拒否されるため,ACL 内に ACE を正しく配置する必要があります。または,保護コードのグループ・カテゴリまたはワールド・カテゴリによって許可されるアクセスをすべて除外する方法もあります (具体的には 4.3 項 「システムによる保護オブジェクトへのユーザのアクセス可否の判定」4.5.5 項 「機密オブジェクトに対する保護の強化」を参照)。セキュリティ管理者は,一致する ACE を変更できる特権を無効にすることもできます。

4.4.4 デバイスへのアクセスの制限

セキュリティ管理者は,たとえば 4.4.2 項 「特定ユーザへのアクセスの許可」に示したように給与計算ファイルなどの共通ファイルへのアクセスを許可する一方で,小切手印刷用の高品質プリンタを使用できるユーザの数を限定したい場合があります。限定しなければ,PAYROLL 識別子を保持するすべてのユーザが TTA8 プリンタに常時セットされている小切手フォームにアクセスできることになります。

この例では,小切手用プリンタがログインに使用されたり,キューの出力先に指定されることはないので,セキュリティ管理者はプリンタに ACL を追加して,McGrey というユーザにのみ読み込みアクセスと書き込みアクセスを許可するように設定できます。同時に,セキュリティ管理者は他の識別子の保持者によるプリンタへのアクセスを禁止する必要があります。次のコマンド・シーケンスを使用して,このような ACL を作成できます。

$ SET SECURITY/ACL=((IDENTIFIER=MCGREY,ACCESS=READ+WRITE)-
_$ (IDENTIFIER=*,ACCESS=NONE))/CLASS=DEVICE TTA8

McGrey には読み込みアクセスと書き込みアクセスが許可されますが,他のユーザは, 4.4.3 項 「オブジェクトへのユーザのアクセスの禁止」で説明したように,NONE キーワードによってアクセスを拒否されます。ただし,セキュリティ管理者がプリンタの保護コードを変更するまでは,TTA8 プリンタの ACL は意図したとおりに機能しない場合もあります。詳細については, 4.5.5 項 「機密オブジェクトに対する保護の強化」を参照してください。

4.4.5 環境へのアクセスの制限

識別子用 ACE を使用し,特定の種類の識別子を組み合わせることによって条件付きのアクセスを提供できます。たとえば,代表的な例としては,BATCH や INTERACTIVE のような環境識別子とともに UIC 識別子を使用する方法があります (環境識別子の一覧については, 4.1.6.1 項 「識別子のタイプ」を参照してください)。この場合,ユーザはバッチ・モードまたは会話形式で実行されている場合にのみ保護オブジェクトにアクセスすることができ,ダイアルアップ回線経由ではアクセスできません。たとえば,次のコマンドは Fred というユーザにプリント・キューへの登録アクセスと管理アクセスを許可しますが,許可するのは Fred がバッチ・ジョブを実行している場合のみです。

$ SET SECURITY/ACL=(IDENTIFIER=[FRED]+BATCH,ACCESS=SUBMIT+MANAGE)-
_$ /CLASS=QUEUE SYSTEM6$LPA0

4.4.6 リスト内の ACE の順序

ACL には,1 つまたは複数のエントリを含めることができます。ACL に複数の ACE がある場合,最初に一致する ACE に基づいてアクセス権が決定されるため,エントリの順序が重要な意味を持ちます。オペレーティング・システムは ACL を先頭から順に検索し,最初に一致した ACE に指定されているアクセス権をユーザに付与します。それ以降のエントリはすべて無視されます。評価のプロセスについては, 4.3 項 「システムによる保護オブジェクトへのユーザのアクセス可否の判定」を参照してください。

ACL を作成するときは,以下の原則に従います。

  • 重要なユーザにアクセス権を付与する ACE をリストの先頭に置く。

  • アクセス権の付与対象となるグループの規模が小さい ACE ほどリストの上位に置く。

  • 選択的にアクセスを拒否する場合を除き,付与するアクセス権の数が多い ACE ほどリストの上位に置く。

PROJECT-ACCOUNTS.DIR ディレクトリ・ファイルに対する次の ACL を例に,ACL 内のエントリの順序の決め方を示します。この ACL では,重要なユーザ (Jones と Fred) にアクセス権を付与する ACE をリストの先頭に置き,その後に一般の ACE を置いています。アクセスを拒否する ACE はリストの末尾に置いています。

$ SET SECURITY/ACL=( -
_$  (IDENTIFIER=[ACCOUNTING,JONES],ACCESS=READ+WRITE+EXECUTE),-
_$  (IDENTIFIER=[FRED]+BATCH,ACCESS=READ+WRITE+EXECUTE),-
_$  (IDENTIFIER=PAYROLL,ACCESS=READ),-
_$  (IDENTIFIER=DIALUP,ACCESS=NONE)) PROJECT-ACCOUNTS.DIR  

プロジェクト・アカウントのディレクトリに設定されたこの ACL では,読み込み,書き込み,実行の各アクセスを Jones に対して常に許可し,Fred に対してはバッチ・ジョブの実行時にのみ許可しています。また,PAYROLL 識別子を保持するユーザには読み込みアクセス権を与えています。モデムからログインしたユーザについては,上位に置いた ACE によってアクセス権を付与しない限り,アクセスを拒否します。たとえば,Jones,Fred,または PAYROLL 識別子の保持者がダイアルアップした場合,これらのユーザに対する ACE を DIALUP の ACE の前に置いているため,アクセスが許可されます。

次の例は,STAFFING.DAT というデータ・ファイルの ACL です。この例では,最も多くのファイル・アクセス権を与えるエントリを ACL の先頭に置いています。

$ SET SECURITY/ACL=( -
_$ (IDENTIFIER=SECURITY,OPTIONS=PROTECTED,-
_$  ACCESS=READ+WRITE+EXECUTE+DELETE+CONTROL),-
_$ (IDENTIFIER=PERSONNEL,ACCESS=READ+WRITE+EXECUTE+DELETE),-
_$ (IDENTIFIER=SECRETARIES,ACCESS=READ+WRITE)-
_$ (IDENTIFIER=[PUB,*],ACCESS=READ),-
_$ (IDENTIFIER=NETWORK,ACCESS=NONE),-
_$ (IDENTIFIER=[SALES,JONES],ACCESS=NONE)) STAFFING.DAT

この ACL では,SECURITY 識別子を保持するユーザが最初の ACE によって最大限のアクセス権を取得し,PERSONNEL 識別子を保持するユーザがそれに次ぐアクセス権を取得します。Jones は,汎用識別子のいずれかを保持していない限り,ファイルへのあらゆるアクセスを禁止されます。これは,ACL の作成者のミスである可能性があります。Jones がファイルへのアクセス権を確実に獲得できないようにしたい場合は,このエントリを ACL の末尾から先頭に移動します。

4.4.7 ファイルの継承方式の設定

ディレクトリ内またはディレクトリ構造内にあるファイルへのアクセスを制御するための計画を立て,各ファイル用の適切な ACL を作成したら,新しいファイルにこの ACL を自動的に割り当てるようにオペレーティング・システムに指示できます。このためには,Default 属性を持つ識別子用 ACE を作成し,対象となるファイルが登録されるディレクトリ・ファイルにその ACE を追加します。Default 属性を設定するには,OPTIONS キーワードを使用します。

たとえば,[MALCOLM] ディレクトリ内のすべての新しいファイルに対して,PERSONNEL 識別子を持つユーザに読み込みアクセスと書き込みアクセスを許可する ACL エントリを割り当てるには,MALCOLM.DIR ファイルに次の ACE を追加します。

$ SET SECURITY/ACL=(IDENTIFIER=PERSONNEL,OPTIONS=DEFAULT,-
_$ ACCESS=READ+WRITE)  [000000]MALCOLM.DIR

この ACE を追加すると,[MALCOLM] ディレクトリ内に作成されたファイルには次の ACL が割り当てられます。

$ SHOW SECURITY APRIL_INTERVIEWS.TXT

WORK_DISK$:[MALCOLM]APRIL_INTERVIEWS.TXT;1 object of class FILE

     Owner: [SALES,MALCOLM]
     Protection: ...
     Access Control List:
          (IDENTIFIER=PERSONNEL,ACCESS=READ+WRITE) 
.
.
.

Default 属性は,新しいファイルの ACL には含まれず,ディレクトリ・ファイルの ACL にのみ含まれます。ただし,MALCOLM ディレクトリ内に作成されるサブディレクトリの ACL には,このエントリ (IDENTIFIER=PERSONNEL,OPTIONS=DEFAULT,ACCESS=READ+WRITE) が自動的に追加されます。このようにして,この ACE はディレクトリ木構造の全体に適用されます。

この ACE は,MALCOLM.DIR 内の既存のファイルに遡って適用されません。既存のファイルに ACE を追加するには, 4.5.7 項 「ファイルのデフォルト・セキュリティ・プロファイルの復元」で説明するように /DEFAULT 修飾子を使用するか,次のコマンドを使用します。

$ SET SECURITY/ACL=(IDENTIFIER=PERSONNEL,ACCESS=READ+WRITE)-
_$ [MALCOLM]*.*;*

Default 属性を持つ ACE は,その ACE の適用方法を制御するだけで,アクセス制御に対して影響を与えません。ファイルとディレクトリの両方へのアクセスを制御するには,次のように,ディレクトリの ACL に 2 つの ACE を追加します。

$ SET SECURITY/ACL=-
_$ ((IDENTIFIER=PERSONNEL,ACCESS=READ+WRITE),-
_$ (IDENTIFIER=PERSONNEL,OPTIONS=DEFAULT,ACCESS=READ+WRITE))-
_$ [000000]MALCOLM.DIR

4.4.8 ACL の表示

DCL の SHOW SECURITY コマンドを使用して,オブジェクトの ACL を表示できます。ファイル以外のオブジェクトが対象の場合には,オブジェクト名とともにクラス名も指定する必要があります。たとえば,次のコマンドは PPA0 という名前のデバイスのセキュリティ属性を表示します。このデバイスはオペレーティング・システムによって所有されており,保護コードによってシステム・カテゴリと所有者カテゴリのユーザにフル・アクセス (読み込み,書き込み,物理,および論理アクセス) が許可されていますが,グループ・ユーザとワールド・ユーザにはアクセスが許可されていません。また ACL によって Svensen というユーザに制御アクセス権が付与されています。

$ SHOW SECURITY /CLASS=DEVICE PPA0:

_ACCOUNTS$PPA0: object of class DEVICE

     Owner: [SYSTEM]
     Protection: (System: RWPL, Owner: RWPL, Group, World)
     Access Control List:
         (IDENTIFIER=[ADMIN,SVENSEN],ACCESS=CONTROL) 

ACL を表示する方法は,他にもいろいろあります。アクセス制御リスト・エディタ (ACL エディタ) は,ACL に関するさまざまな作業を実行するときに便利なツールです。『OpenVMS システム管理ユーティリティ・リファレンス・マニュアル』の ACL エディタに関する記述を参照してください。一方,以下の DCL コマンドでも ACL を表示できます。

SHOW SECURITY

DIRECTORY/ACL

DIRECTORY/SECURITY

DIRECTORY/FULL

SHOW LOGICAL/FULL/STRUCTURE

SHOW DEVICE/FULL

SHOW QUEUE/FULL

アプリケーションが ACE に Hidden 属性を追加して,ACE を変更できるのはその ACE を追加したアプリケーションだけであることを示す場合があります。隠された ACE は,ユーザが SECURITY 特権を持っていない限り,DCL コマンドでは表示されません。ACL エディタでは Hidden 属性を持つ ACE も表示されますが,ACL 内での相対的な位置を示すことが目的であり,権限のないユーザはそれらの ACE を編集できません。

ACL 内には,アクセス制御とは関係のない別の種類の ACE が設定されている場合があります。たとえば,セキュリティ管理者が LN03$PRINT キューにセキュリティ監査用 ACE を設定した場合は,(AUDIT=SECURITY,ACCESS=アクセス・タイプ) という形式の ACE がリストの先頭に表示されます。このような ACE はセキュリティ監査システムの構成要素であり,アクセス制御には影響しないため,無視して構いません。

4.4.9 既存の ACL への ACE の追加

4.4.2 項 「特定ユーザへのアクセスの許可」4.4.5 項 「環境へのアクセスの制限」では,DCL の SET SECURITY コマンドを使って空の ACL にエントリを追加する方法を説明しています。ACL を広範に変更するには ACL エディタを使用しますが,多くの場合,SET SECURITY コマンドを使用する方が適切です。この節以降では,SET SECURITY を使用して ACL を変更する方法について説明します。

$ SET SECURITY/CLASS=QUEUE/ACL=(IDENTIFIER=WRITERS,-
_$ ACCESS=READ+WRITE)  LN03$PRINT

ACL にエントリを追加するには,SET SECURITY コマンドに /ACL 修飾子を加え,新しい ACE を指定します。たとえば,文書作成者 (WRITERS) に LN03$PRINT プリント・キューへのアクセス権を付与するには,次のコマンドを使用します。

次の SHOW SECURITY の表示結果からわかるように,新しい ACE はデフォルトで ACL の先頭に置かれます。

$  SHOW SECURITY /CLASS=QUEUE LN03$PRINT

_LN03$PRINT: object of class QUEUE

     Owner: [SYSTEM]
     Protection: (System: RWPL, Owner: RWPL, Group, World)
     Access Control List:
          (IDENTIFIER=WRITERS,ACCESS=READ+WRITE) 
          (IDENTIFIER=[PUB,*],ACCESS=READ) 
          (IDENTIFIER=NETWORK,ACCESS=NONE) 

SET SECURITY のデフォルトの動作では新しい ACE が ACL の先頭に置かれるため,ACE を別の位置に入れたい場合は /AFTER 修飾子を使用する必要があります。たとえば,キューの ACL 内で TRADERS の ACE を WRITERS の ACE の後に置くには,次のコマンドを使用します。

$ SET SECURITY/CLASS=QUEUE/ACL=(IDENTIFIER=TRADERS,ACCESS=WRITE)-
_$ /AFTER=(IDENTIFIER=WRITERS,ACCESS=READ+WRITE) LN03$PRINT

表示結果から,/AFTER 修飾子の効果を確認できます。新しい ACE がリストの 2 番目の位置に置かれています。

$  SHOW SECURITY /CLASS=QUEUE LN03$PRINT

_LN03$PRINT: object of class QUEUE

     Owner: [SYSTEM]
     Protection: (System: RWPL, Owner: RWPL, Group, World)
     Access Control List:
          (IDENTIFIER=WRITERS,ACCESS=READ+WRITE) 
          (IDENTIFIER=TRADERS,ACCESS=WRITE) 
          (IDENTIFIER=[PUB,*],ACCESS=READ) 
          (IDENTIFIER=NETWORK,ACCESS=NONE) 

4.4.10 ACL の削除

SET SECURITY コマンドに /DELETE 修飾子を加えると,ACL を削除できます。この修飾子の使い方次第で,ACL の全体または一部を削除できます。たとえば,次のコマンドはディスクの ACL を削除します。

$ SET SECURITY/CLASS=DEVICE/ACL/DELETE DUA0

Protected 属性が割り当てられている ACE は,不注意による削除から保護されます。保護されている ACE を削除するには,その ACE を明示的に削除するか,SET SECURITY/ACL コマンドに /DELETE=ALL 修飾子を指定する必要があります。

4.4.11 ACL からの ACE の削除

ACL を部分的に削除するには,/ACL 修飾子を使って不要な ACE を指定した上で,/DELETE 修飾子を使用します。たとえば,次のコマンドは TRADERS 識別子と NETWORK 識別子の保持者に DBA0 ボリュームへの書き込みアクセス権を付与する ACE を削除します。

$ SET SECURITY/CLASS=VOLUME/ACL=-
_$  (IDENTIFIER=TRADERS,ACCESS=WRITE),-
_$  (IDENTIFIER=NETWORK,ACCESS=WRITE)/DELETE DBA0:

4.4.12 ACL の部分的な置き換え

ACL 内の一定範囲の ACE を別の ACE にまとめて置き換えるには,次のように /REPLACE 修飾子を使って新しい ACE を指定し,/ACL 修飾子を使って削除する ACE を指定します。

$ SET SECURITY/CLASS=VOLUME/ACL=(IDENTIFIER=TRADERS,ACCESS=WRITE)-
_$ /REPLACE=((IDENTIFIER=RESEARCH,ACCESS=WRITE)-
_$  (IDENTIFIER=STATE_DEPARTMENT,ACCESS=READ+WRITE),-
_$  (IDENTIFIER=ENERGY_DEPARTMENT,ACCESS=READ+WRITE)-
_$ DBA0:

まず,/ACL で指定している TRADERS の ACE が削除されます。次に,/REPLACE 修飾子で指定している ACE (RESEARCH,STATE_DEPARTMENT,ENERGY_DEPARTMENT) が,削除された ACE の位置に挿入されます。

4.4.13 ファイルのデフォルト ACL の復元

ファイルのデフォルト ACL を復元するには,SET SECURITY コマンドで /DEFAULT 修飾子を使用します。この修飾子を指定すると,ファイルの完全なセキュリティ・プロファイルが再生成されます。詳細については, 4.5.7 項 「ファイルのデフォルト・セキュリティ・プロファイルの復元」を参照してください。

4.4.14 ACL のコピー

あるオブジェクトのセキュリティ・プロファイルを別のオブジェクトにコピーするには,SET SECURITY コマンドで /LIKE 修飾子を使用します。たとえば,論理名テーブルのような永続的でないオブジェクトに複雑な ACL を設定した場合でも,ファイルなどの永続的なオブジェクトにコピーすることによってその ACL を保存できます。管理者がコピー操作のテンプレートとして使用できるファイルを作成する場合もあります。これにより,管理者はオブジェクト間で ACL を簡単に転送することができます。たとえば,次のコマンドは ACL_TEMPLATE.TXT ファイルから LNM$GROUP 論理名テーブルに ACL をコピーします。

$ SET SECURITY/LIKE=NAME=ACL_TEMPLATE.TXT-
_$ /COPY_ATTRIBUTE=ACL/CLASS=LOGICAL_NAME_TABLE LNM$GROUP 

/LIKE 修飾子に /COPY_ATTRIBUTE 修飾子を追加すると,完全なプロファイルではなく 1 ~ 2 個の要素をコピーできます。たとえば,KITE_FLYING ディレクトリに次のような ACL があるとします。

$ SHOW SECURITY [000000]KITE_FLYING.DIR;1 -

WORK_DISK$:[000000]KITE_FLYING.DIR;1 object of class FILE

     Owner: [PROJECTX]
     Protection: (System: RWED, Owner: RWED, Group:, World)
     Access Control List:
          IDENTIFIER=PROJECTX,ACCESS=READ+WRITE+EXECUTE
          IDENTIFIER=PROJECTX,OPTIONS=DEFAULT,ACCESS=READ+WRITE+EXECUTE

次のコマンドは,上記の ACL を KITE_FLYING ディレクトリから KITE_DESIGNS ディレクトリにコピーします。

$ SET SECURITY/LIKE=KITE_FLYING.DIR;1 -
_$ /COPY_ATTRIBUTE=ACL KITE_DESIGNS.DIR;1

$ SHOW SECURITY [000000]KITE_DESIGNS.DIR;1 -

WORK_DISK$:[000000]KITE_DESIGNS.DIR;1 object of class FILE

     Owner: [ENGINEERING]
     Protection: (System: RWED, Owner: RWED, Group:R, World:R)
     Access Control List:
          IDENTIFIER=PROJECTX,ACCESS=READ+WRITE+EXECUTE
          IDENTIFIER=PROJECTX,OPTIONS=DEFAULT,ACCESS=READ+WRITE+EXECUTE

SET SECURITY/LIKE コマンドによって,必ずしもコピー元オブジェクトの ACL 全体が複製されるとは限りません。たとえば,Nopropagate 属性を持つ ACE はコピー元の ACL からコピーされません。また,保護されている ACE も上書きされません。コピー先オブジェクトの保護されている ACE は維持され,コピーされた ACL に追加されます。たとえば,アプリケーションの多くはファイル・データの正しい表示方法を示すために特殊なタイプの保護されている ACE を使用しますが,これらの ACE はそのまま維持する必要があります。

ACE に設定できる属性の種類については,『OpenVMS システム管理ユーティリティ・リファレンス・マニュアル』の ACL エディタに関する記述を参照してください。ACE のタイプについては,『HP OpenVMS Programming Concepts Manual』を参照してください。

4.5 保護コードによるアクセスの制御

保護コードは,特定のユーザまたはユーザのグループに対して許可 (または拒否) するアクセスのタイプを制御します。アクセス・タイプは,保護オブジェクトに対する操作を実行するのに必要な権限を示します。OpenVMS オペレーティング・システムでは,1 つの操作を完了するのに複数のアクセス権が必要となる場合があります ( 4.7.2 項 「オブジェクトのクラスに対する監査の有効化」を参照)。保護コード内にユーザが属するカテゴリが見つかり,要求されたアクセスが (ACL で拒否されておらず) そのカテゴリで許可されていれば,ただちにユーザにオブジェクトへのアクセス権が付与されます。

4.5.1 保護コードの形式

保護コードの形式は,次のとおりです。

[ユーザ・カテゴリ: 許可されるアクセスのリスト (, ユーザ・カテゴリ: 許可されるアクセスのリスト,...)]

ユーザ・カテゴリ

ユーザ・カテゴリには,システム (S),所有者 (O),グループ (G),およびワールド (W) があります。各カテゴリは,対応する英単語の先頭 1 文字で表すことができます。各カテゴリは次のように定義されます。

  • システム: このカテゴリのメンバは,次のいずれかです。

    • 小さなグループ番号 (通常は 8 進数の 1 ~ 10) を持つユーザ。一般的に,これらのグループ番号はシステム管理者,セキュリティ管理者,およびシステム・プログラマに割り当てられます。システム・グループ番号の正確な範囲は,セキュリティ管理者が MAXSYSGROUP システム・パラメータを設定することによって決まります。有効な範囲は 8 進数の 37776 までです。

    • SYSPRV 特権を持つユーザ。

    • オブジェクトの所有者と同じ UIC グループの GRPPRV 特権を持つユーザ。

    • ボリュームの所有者と同じ UIC を持つユーザ (ディスク・ボリューム上のファイルに対するアクセス要求の場合)。

  • 所有者: オブジェクトを現在所有しているユーザと同じ UIC を持つユーザ。一般的に,オブジェクトの作成者によるアクセスからオブジェクトを保護するための明示的な措置を取らない限り,オブジェクトに対する所有者アクセス権はその作成者に付与されます。

  • グループ: オブジェクトの所有者と同じ UIC グループに属するすべてのユーザ。

  • ワールド: 上記 3 つのカテゴリに属するユーザを含むすべてのユーザ。

複数のユーザ・カテゴリを指定する場合は,各カテゴリをコンマで区切り,コード全体を括弧で囲みます。ユーザ・カテゴリとアクセス・タイプは,任意の順序で指定できます。ただし,表示されるときは常にシステム,所有者,グループ,ワールドの順になります。

特定のユーザ・グループによるアクセスをすべて拒否するには,アクセス・タイプを指定せずにユーザ・カテゴリだけを指定します。ユーザ・カテゴリの後のコロンを省略することで,特定のユーザ・カテゴリによるアクセスを拒否できます。

特定のカテゴリ全体を省略すると,そのカテゴリに対するアクセス権は未指定となります。この場合,そのユーザ・カテゴリに現在許可されているアクセス権がそのまま適用されます。作成されたオブジェクトに (たとえば COPY/PROTECTION コマンドによって) 保護コードが適用される場合,省略されたカテゴリにはデフォルト値が割り当てられます。

アクセス・リスト

アクセス・タイプはオブジェクトによって決まります。アクセス・タイプについては 第5章 「オブジェクト・クラスの詳細」で説明します。ファイルに関するアクセス・タイプには,読み込み (R),書き込み (W),実行 (E),および削除 (D) があります。アクセス・タイプはユーザ・カテゴリごとに割り当て,アクセス・タイプとユーザ・カテゴリはコロン (:) で区切ります。たとえば,SET SECURITY/PROTECTION=(S:RWE,O:RWE,G:RE,W) のようにします。

4.5.2 保護コード内のアクセスのタイプ

個々のユーザ・カテゴリに対して,異なるタイプのアクセスを許可または拒否できます。正確なタイプは,保護対象オブジェクトによって異なります。各オブジェクト・クラスには,そのクラスに対応するアクセス・タイプが定義されています。これらのアクセス・タイプは,ユーザがそのデータに対して実行する操作の典型を示しています。たとえば,ファイル・オブジェクトは読み込み,書き込み,実行,および削除の各アクセスをサポートするのに対して,デバイス (ターミナル,プリンタ,ディスクなど) は読み込み,書き込み,物理入出力,および論理入出力の各アクセスをサポートします。各オブジェクト・クラスがサポートするアクセス・タイプについては, 第5章 「オブジェクト・クラスの詳細」を参照してください。

すべての保護オブジェクトは,制御アクセスをサポートします。制御アクセスにより,ユーザはオブジェクトのセキュリティ要素 (ACL,保護コード,UIC) と,場合によってはその他の属性を参照および変更できます。制御アクセス権は,ACL では明示的に記述されますが,UIC ベースの保護コードには現れません。保護コードのシステム・カテゴリまたは所有者カテゴリに属するユーザはすべて制御アクセス権を持っています。グループ・カテゴリとワールド・カテゴリのユーザは,保護コードによる制御アクセス権を獲得することはありませんが,ACL で獲得することは可能です。詳細については, 4.6.2 項 「制御アクセスによるオブジェクトのプロファイルの変更」を参照してください。

読み込み,書き込み,実行,削除,および制御の各アクセス・タイプによって指定される機能は,適用される状況によって異なります。たとえば,実行アクセスで許可される操作は,ファイル・アクセスとディレクトリ・アクセスのどちらに対して許可されるかによって異なります。各アクセス・タイプが保護オブジェクトの各タイプに対して許可する機能については, 第5章 「オブジェクト・クラスの詳細」で説明します。

4.5.3 保護コードの処理

システムによる保護コードの評価は,所有者フィールド,ワールド・フィールド,グループ・フィールド,システム・フィールドの順に行われます。ユーザがあるカテゴリのメンバとしての条件を満たし,そのカテゴリによって必要なアクセス権が付与されると,保護コードの処理はそこで終了します ( 図 4-3 「アクセス要求評価のフローチャート」を参照)。

次の保護コードは,システム・カテゴリと所有者カテゴリのユーザが読み込み (R),書き込み (W),実行 (E),および削除 (D) のアクセス権を持ち,グループ・カテゴリとワールド・カテゴリのユーザが読み込みと実行のアクセス権のみを持つことを指定します。

$ SET SECURITY/PROTECTION=(SYSTEM:RWED, OWNER:RWED, GROUP:RE, WORLD:RE)-
_$ TAXES_91.DAT

特定のユーザ・カテゴリに対してアクセスを拒否する場合は,それより範囲の広いすべてのカテゴリに対してアクセスを拒否する必要があります。 4.5.1 項 「保護コードの形式」で説明したように,ユーザ・プロセスおよびアプリケーションはすべてワールド・カテゴリのアクセスを認められます。グループ・カテゴリのアクセスは,ワールド・カテゴリよりも制限されていますが,所有者カテゴリおよびシステム・カテゴリほど制限が厳しくありません。

たとえば,次の保護コードは所有者カテゴリに対して削除アクセスを拒否しているように見えます。

$ SHOW SECURITY TAXES_91.DAT
WORK_DISK$:[GREG]TAXES_91.DAT;1 object of class FILE

   Owner: [FINANCE,GREG]
   Protection: (System: RWED, Owner: RW, Group:RW, World:RWED)
   Access Control List: ...

しかし,このファイルの所有者は依然としてこのファイルを削除できます。所有者カテゴリでは削除アクセスを許可していませんが,アクセスが許可されているかどうかのチェックは他のカテゴリについても行われます。所有者はワールド・カテゴリ (すべてのユーザに適用されるカテゴリ) にも属しており,ワールド・カテゴリでは削除アクセスが許可されているので,所有者にも削除アクセスが許可されます。

4.5.4 保護コードの変更

SET SECURITY コマンドを使用して,既存オブジェクトの UIC ベースの保護を変更できます。次のコマンドは,SURVEY.DIR ファイルの保護コードを変更して,システム・カテゴリと所有者カテゴリのユーザに読み込み,書き込み,実行,および削除の各アクセス権を与え,グループ・カテゴリとワールド・カテゴリのメンバに読み込みと実行のアクセス権を与えます。

$ SET SECURITY/PROTECTION=(SYSTEM:RWED,OWNER:RWED, -
_$ GROUP:RE,WORLD:RE)  SURVEY.DIR

保護コードからカテゴリを省略すると,現在のアクセス権がそのまま適用されます。たとえば,RECORDS_91.DAT というファイルの保護コードを考えます。

$ SHOW SECURITY RECORDS_91.DAT

WORK_DISK$:[GREG]RECORDS_91.DAT object of class FILE
     Owner: [VMS,GREG]
     Protection: (System: RWED, Owner: RWED, Group: RWED, World: RE)

現在の RECORDS_91 ファイルでは,システム,所有者,グループの各カテゴリのユーザに対して読み込み,書き込み,実行,および削除の各アクセスが許可され,ワールド・カテゴリのユーザに対して読み込みアクセスと実行アクセスが許可されています。次の DCL コマンドは,RECORDS_91.DAT の保護コードを再設定して,グループ・カテゴリに対して書き込みアクセスと削除アクセスを拒否し,ワールド・カテゴリに対してすべてのアクセスを拒否します。

$ SET SECURITY/PROTECTION=(G:RE,W) RECORDS_91.DAT

次のコマンドは,変更した保護コードを確認します。システム・カテゴリと所有者カテゴリのユーザには依然として読み込み,書き込み,実行,および削除の各アクセス権が与えられているのに対して,グループ・ユーザには読み込みアクセス権と実行アクセス権のみが与えられ,ワールド・ユーザにはアクセス権がまったく与えられていません。

$ SHOW SECURITY RECORDS_91.DAT

WORK_DISK$:[GREG]RECORDS_91.DAT object of class FILE
     Owner: [VMS,GREG]
     Protection: (System: RWED, Owner: RWED, Group: RE, World:)

4.5.5 機密オブジェクトに対する保護の強化

4.4.4 項 「デバイスへのアクセスの制限」では,重要なプリンタに ACL を設定して,プリンタへのアクセス権を 1 人のユーザに限定する方法を説明しています。しかし,この ACL を有効にするには,セキュリティ管理者が次のコマンドを使用して,プリンタの保護コードによって許可されるすべてのアクセスを排除する必要があります。

$ SET SECURITY/PROTECTION=(S,O,G,W)/CLASS=DEVICE TTA8:

次に,セキュリティ管理者は ACL を使用してアクセス権を明示的に割り当てます。

たとえば,キューへのアクセスを制限するには,ワールド・カテゴリのキュー登録アクセス権を削除します。次に,ACL を設定して,(ワールド・カテゴリの) どのユーザにキューへのジョブ登録を許可するかを指定します。次のコマンドは,PROJECTX 識別子の保持者にのみ LN03$PRINT キューへのジョブ登録を許可します。

$ SET SECURITY/CLASS=QUEUE/PROTECTION=(W) -
_$ /ACL=(IDENTIFIER=PROJECTX,ACCESS=SUBMIT) -
_$ LN03$PRINT

重要なファイルは多くの場合,特別な保護を必要とします。ディレクトリの内容を参照できないようにするには,ユーザによる読み込みアクセスを拒否します。ファイルの保護を強化するには, 4.5.6 項 「ディレクトリ構造に対するデフォルトの保護コードの提供」に示すように,ディレクトリ・ファイルにデフォルトの保護用 ACE を追加します。

4.5.6 ディレクトリ構造に対するデフォルトの保護コードの提供

特定のディレクトリ内の新しいファイルに対してデフォルトの保護を指定するには,ディレクトリ・ファイルの ACL にデフォルトの保護用 ACE を含めます。デフォルトの保護用 ACE は,以降そのディレクトリおよびその下のサブディレクトリに作成されるファイルに適用されます。ただし,ファイルに個別の保護が指定された場合は除きます。この ACE の形式は,次のとおりです。

(DEFAULT_PROTECTION[,オプション],保護コード)

たとえば,次の ACE は,システム・カテゴリと所有者カテゴリのユーザに,このディレクトリ内で新たに作成されるファイルに対する読み込み,書き込み,実行,および削除の各アクセス権を与え,グループ・カテゴリとワールド・カテゴリのユーザにアクセス権をまったく与えないことを指定します。

$ SET SECURITY/ACL=(DEFAULT_PROTECTION,S:RWED,O:RWED,G,W) ARCHIVE.DIR

デフォルトの保護は新たに作成されるファイルにのみ適用される点に注意してください。現在のディレクトリとそのサブディレクトリに既に存在するファイルには適用されません。ディレクトリ・ファイルにデフォルトの保護用 ACE を追加し,既存のファイルにも同じ保護を適用したい場合は,次のコマンドを使用して明示的に保護を変更する必要があります。

$ SET DEFAULT [ARCHIVE]
$ SET SECURITY/PROTECTION=(S:RWED,O:RWED,G,W) [...]*.*;*

4.5.7 ファイルのデフォルト・セキュリティ・プロファイルの復元

SET SECURITY コマンドに /DEFAULT 修飾子を加えると,ファイルのセキュリティ・プロファイルが再生成されます。/DEFAULT 修飾子は,ファイルの保護コード,ACL,および所有者要素を,ファイルの親ディレクトリに指定されているデフォルト (つまり,ディレクトリのデフォルト ACL,(もしあれば) デフォルトの保護用 ACE,および所有者 UIC) に再設定します。

セキュリティ・プロファイルは次の規則に従って再生成されます。

  • 保護コードは,(もしあれば) ディレクトリのデフォルトの保護用 ACE から継承されます。ない場合は,プロセスのデフォルトから継承されます。

  • ACL については,親ディレクトリの Default 属性を持つ ACE から継承されます。

  • 所有者については,親ディレクトリの所有者が設定されます。ファイルの所有者を変更するには,通常,特権が必要です ( 5.4.2 項 「アクセスのタイプ」を参照)。

サブディレクトリ・ファイルの場合は,SET SECURITY によって親ディレクトリの所有者,保護,および ACL の各要素が割り当てられます。

SET SECURITY は,設定元のオブジェクトの ACE に Nopropagate 属性がある場合は,その ACE をコピーしません。また,設定先のオブジェクトの ACE に Protected 属性がある場合は,その ACE を変更しません。ファイルのすべてのバージョンに新しい要素を適用するには,オブジェクト名として ;* を指定します。

継承規則の詳細については, 5.4.5 項 「プロファイルの割り当て」を参照してください。

4.6 特権と制御アクセス

オブジェクトは ACL と保護コードによって入念に保護できますが,ユーザは依然として特権および制御アクセスを利用することでアクセス権を獲得することができます。

4.6.1 保護メカニズムに対する特権の影響

セキュリティ管理者は,ユーザ・アカウントを作成または変更するときに,ユーザに特権を割り当てることができます。システム特権の READALL と BYPASS は,オブジェクトの ACL およびセキュリティ・プロファイルの他の要素によって指定されるアクセス権に関係なく,ユーザ・アクセスに影響を与えます。SYSPRV 特権と GRPPRV 特権は,保護コードのシステム・カテゴリで制御します。これらの特権の意味を次に示します。

BYPASS

BYPASS 特権を有するユーザは,オブジェクトの保護に関係なく,オブジェクトに対するあらゆるタイプのアクセス権を獲得します。

GRPPRV

GRPPRV 特権を有し,UIC グループがオブジェクトの所有者のグループと一致するユーザは,システム・カテゴリのユーザと同じアクセス権を獲得します。したがって,GRPPRV 特権を有するユーザは該当グループのすべてのオブジェクトを管理できます。

READALL

READALL 特権を有するユーザは,オブジェクトに対する読み込みアクセス権を獲得します。これは,ACL および保護コードによってそのアクセスが拒否される場合も含みます。さらに,ユーザは保護コードによって付与される他のアクセス権もすべて獲得します。

SYSPRV

SYSPRV 特権を有するユーザは,システム・カテゴリのユーザに付与されるアクセス権を獲得します。

オブジェクトに対して ACL や保護コードを定義するときは,強力な特権を有するユーザにはシステム全体のオブジェクトに対する特別なアクセス権を付与されることを忘れないでください。たとえば,BYPASS 特権を有するユーザによる特定のファイルへのアクセスを防ぐ方法はありません。 GRPPRV 特権を有するユーザは,自分の UIC グループに属する他のメンバのためにさまざまなシステム管理機能を実行する権限を持っています。 オブジェクトの保護は,これらの特権の付与に関するセキュリティ管理者の判断に左右されます。

4.6.2 制御アクセスによるオブジェクトのプロファイルの変更

オブジェクトに対する制御アクセス権を持つユーザは,オブジェクトの保護コードと ACL を変更することにより,オブジェクトへのアクセス権を獲得できます。ファイル以外のオブジェクト・クラスについては,制御アクセス権を持つユーザがオブジェクトの所有者を変更することもできます。ファイルの所有者の変更には,通常,特権が必要です ( 5.4.2 項 「アクセスのタイプ」を参照)。

制御アクセス権は,次のいずれかの方法で獲得できます。

  • オブジェクトの ACL によって制御アクセス権が付与される識別子を持っている。

  • オブジェクトの所有者と同じ UIC を持っている。

  • システム・ユーザ・カテゴリのメンバとしての条件を満たし,ゼロ以外の UIC を持つユーザがオブジェクトの所有者になっている。たとえば,(同じグループ UIC に属していて) GRPPRV 特権を持っているか SYSPRV 特権を持っている。システム・ユーザの詳細については, 4.5 項 「保護コードによるアクセスの制御」を参照してください。

  • BYPASS 特権を持っている。

オブジェクト・クラスによっては,制御アクセスが他の手段で許可される場合もあります。これに該当する特別な状況については, 4.6.3 項 「アクセスに関するオブジェクト固有の考慮事項」および 第5章 「オブジェクト・クラスの詳細」の各クラスの説明を参照してください。

4.6.3 アクセスに関するオブジェクト固有の考慮事項

オブジェクトによっては,( 4.6.1 項 「保護メカニズムに対する特権の影響」に示した以外の) 特別な特権や包括的なタイプのアクセス権によってアクセスが許可される場合があります。特に,キューがこれに該当します。オペレータ (OPER) 特権を持つユーザには,キューに対するすべてのタイプのアクセスが許可されます。管理アクセス権を持つユーザは,キューに対する他のタイプのアクセス権 (読み込み,登録,および削除) を暗黙に保持しています。 第5章 「オブジェクト・クラスの詳細」に,各オブジェクト・クラスのアクセス・タイプ,意味,および特別な特権を示します。

4.7 保護オブジェクトの監査

プロセスがオブジェクトを使用するか,オブジェクトのセキュリティ・プロファイルを変更する ( 4.2.4 項 「セキュリティ・プロファイルの変更」を参照) たびに,オペレータ・ターミナルにアラームを送信するか,監査ログ・ファイルにメッセージが記録するようにできます。セキュリティ管理者は,ログ・ファイルを参照することにより,システムの動作を調べ,保護オブジェクトをいつ,誰が,どのように使用したかを確認できます。

監査システムによってどのような情報が報告されるかは,セキュリティ管理者がサイトの要件をどのように定義するかによります。オブジェクトの使用状況を監査する場合,システム管理者は適切なカテゴリのイベントに対する監査機能を有効にできます。

OpenVMS オペレーティング・システムでは,セキュリティ関連イベントにフィルタを適用して,オブジェクトが特定の方法でアクセスされたときにだけシステム管理者にメッセージを送信するようにできます。多くのサイトでは,すべてのファイル・アクセスではなく,特権を利用したファイルの使用やファイルへのアクセスの失敗が関心の対象になります。このようなサイトでは,プロセスがファイルへのアクセスに成功した場合ではなく,失敗した場合の監査メッセージを要求できます。システムは,プロセスがオブジェクトにアクセスする権利をそもそもどのように (保護コード,ACE,または特権を介して) 行使したか (または行使できなかったか) を報告します。

4.7.1 システムが監査するイベントの種類

オブジェクト・クラスはそれぞれに固有の監査プロファイルがあるため ( 第5章 「オブジェクト・クラスの詳細」を参照),オブジェクトのクラスによっては他のクラスよりも詳細な情報を得ることができます。どのオブジェクトについても,ユーザまたはアプリケーションがオブジェクトにアクセスするか,セキュリティ要素を変更したときに,必ず監査メッセージが送信されるようにできます。場合によっては,プロセスがオブジェクトを作成したとき,オブジェクトの使用を止めた (アクセスを解除した) とき,またはオブジェクトを削除したときに通知を送信することもできます。

4.7.2 オブジェクトのクラスに対する監査の有効化

オブジェクト・アクセス・イベントを監査するときは,1 つの操作の間に,オブジェクトに対するユーザの権利がオペレーティング・システムによって複数回チェックされる場合があることに注意してください。たとえば,ファイル操作ではディレクトリ・アクセスに関するチェックとファイル・アクセスに関するチェックの両方が行われます。ユーザがファイルを削除する前には,そのファイルに対する削除アクセス権のチェックと,ディレクトリに対する書き込みアクセス権のチェックが行われます。

このため,セキュリティ管理者は,すべてのタイプのオブジェクト・アクセス・イベントについて監査機能を有効にするのが最善策です。たとえば,ユーザがファイルにアクセスしようとして失敗した場合をすべて追跡するには,セキュリティ管理者が SET AUDIT コマンドに /ENABLE=ACCESS=FAILURE=ALL 修飾子を指定します。

アクセス解除の監査をサポートするオブジェクト・クラス (ファイル・クラスなど) では,プロセスがオブジェクトへのアクセス権を獲得すると,そのプロセスがすでに許可されているアクセス・モードに適合しない操作を行わない限り,システムはそのオブジェクトに対する以降のアクセス操作を監査しません。この状況が発生すると,システムは監査対象となる追加的な保護チェックを実行します。このアクセス・ウィンドウは,オブジェクトのアクセスが解除される (たとえば,ファイルが閉じられる) まで継続します。

4.7.3 セキュリティ監査用 ACE の追加

セキュリティ管理者とオブジェクトに対する制御アクセス権を持つユーザは,アラーム用 ACE または監査用 ACE をオブジェクトに追加することにより,オブジェクトのクラス全体を監査するのではなく,特定のオブジェクトに監査対象を絞ることができます ( 3.10.2 項 「重要ファイルへのアクセス制御エントリ (ACE) の追加」を参照)。ユーザは監査用 ACE を自分が所有するファイルまたは制御アクセス権を持つファイルに追加できますが,事前にセキュリティ管理者に相談することをお勧めします。オブジェクト・クラスの場合と同じように,監査メッセージを生成させるには,セキュリティ管理者が ACL の監査カテゴリを有効にする必要があります。



[1] オブジェクトの所有者 UIC がゼロの場合は,保護コードがチェックされません。ACL に識別子用 ACE がない場合に限り,ユーザはオブジェクトに対する制御アクセス権以外のすべてを許可されます。識別子用 ACE がある場合は,ACL または特権によって明示的にアクセス権を与える必要があります。

[2] 識別子用 ACE に Default 属性があると,その ACE はアクセス評価時に無視されます。 4.4.7 項 「ファイルの継承方式の設定」を参照してください。

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