第2章 OpenVMS のセキュリティ・モデル

2.1.1 リファレンス・モニタの概念

リファレンス・モニタの概念によれば，図 2-1 「リファレンス・モニタ」 のように，コンピュータ・システムはサブジェクト，オブジェクト，登録データベース，監査証跡，およびリファレンス・モニタによって表現されます。 リファレンス・モニタは，サブジェクトを認証し，サブジェクトによるオブジェクトへのあらゆるアクセスに関してセキュリティ・ポリシーを実装および実施する管理センターです。

図 2-1 リファレンス・モニタ

次の表は，図 2-1 「リファレンス・モニタ」 に示した各要素の説明です。

2.1.2 リファレンス・モニタによるセキュリティ規則の実施

リファレンス・モニタは，サブジェクトの作成を許可し，サブジェクトによるオブジェクトへのアクセスを認め，必要に応じて監査証跡にイベントを記録することによって，セキュリティ・ポリシーを実施します。 理想のシステムでは，リファレンス・モニタが以下の 3 つの要件を満たす必要があります。

上記は，侵入行為があっても安全が確保できるシステムに関して提案される要件です。 このようなシステムでは，オペレーティング・システムのセキュリティ関連サブセット (セキュリティ・カーネル) によってリファレンス・モニタが実装されます。

2.2.1 サブジェクト

サブジェクトは，情報にアクセスする (場合によっては情報へのアクセスを禁止される) ユーザまたはユーザ・エージェント (ユーザ・プロセス) です。 サブジェクトは会話形式のプロセス，ネットワーク・プロセス，またはバッチ・ジョブであり，次の特徴を持っています。

ユーザがオペレーティング・システムを会話形式で使用するためのログインした時点，またはバッチ・ジョブやネットワーク・ジョブが開始した時点で，オペレーティング・システムはそのユーザの識別情報を含むプロセスを作成します。 作成されたプロセスは，第4章 「データの保護」で説明するように，ユーザのエージェントとして情報にアクセスします。

作成中のプロセスや情報にアクセスしているプロセスは，セキュリティ侵害に対して脆弱です。 システムは，登録データと内部のメカニズム (ハードウェア制御など) を使用して，プロセスによる情報へのアクセスを処理します。 プロセスの作成にはさまざまな分野でセキュリティの脆弱性があるため，オペレーティング・システムのセキュリティ機能の多くはプロセス (またはサブジェクト) 作成の分野に集中しています。

ユーザは，システムにログインしようとするときに， ユーザ名 (作成されるプロセスに与えられる名前) とパスワードを入力します。 パスワードは，ユーザとオペレーティング・システムだけが知っている認証情報としての役割を果たします。

短いパスワードや自明のパスワードではこの要件を満たせない可能性があるため，システムにはさまざまなパスワード保護メカニズムが組み込まれており，それらをユーザが呼び出したり，セキュリティ管理者が要求したりできるようになっています (第7章 「システム・アクセスの管理」を参照)。 オペレーティング・システムには，侵入者がパスワードを推測するために行う操作の回数を制限する機能もあります。

ユーザ・パスワードのファイルは，セキュリティ・データベースの一部であり，許可されない参照や変更から保護する必要があります。 この要件を満たすために，システムでは一般のアクセスから保護されたファイルにパスワードが保存されます。 このファイルをシステム・ユーザ登録ファイル (SYSUAF.DAT) と呼びます。 また，追加的な予防措置として， パスワードが盗まれても簡単には使用できないように，エンコードされた形式でパスワードが保存されます。

オペレーティング・システムは，ユーザのプロセスを作成すると，ユーザ登録レコードに基づいてユーザ識別コード (UIC) をそのプロセスに割り当てます。 UIC は， プロセスを作成したユーザの名前 (ユーザのパスワードによって認証されたもの) に対応します。 また，UIC はユーザが自分の部署，プロジェクト，または職務に対応するグループのメンバであることも示します。 プロセスの作成やプロセス所有者の他のグループとの関係に関する追加情報をプロセスに関連付けることもできます。 これらの追加情報は，登録データベースを適用するときに一定の役割を果たします。 UIC については，第4章 「データの保護」と第8章 「システムのデータと資源へのアクセスの制御」で説明します。

2.2.2 オブジェクト

リファレンス・モニタの概念では，オブジェクトは情報の受動的な格納場所です。 表 2-1 「セキュリティ制御によって保護されるオブジェクト」に示すように，OpenVMS にはファイルやデバイスなどのさまざまなオブジェクトがあり，保護の対象になっています。 オペレーティング・システムは，不正なアクセスからオブジェクトを保護し，(第4章 「データの保護」および第5章 「オブジェクト・クラスの詳細」で説明するように) それらを制御された方法で共用するための各種のメカニズムを提供します。 これらのメカニズムは，システム資源へのアクセスを制御するときにも使用されます。

2.2.3 登録データベース

リファレンス・モニタの概念では，各サブジェクトがオブジェクトへのアクセスを得るための認証は，抽象的な登録データベースに基づいて行われます。 このデータベースは，サブジェクトによるオブジェクトへのアクセスを常に統御する動的なセキュリティ属性を集めたものです。 OpenVMS システムでは，このデータベースは保護するオブジェクトとの関連に基づいて分散して保存されます。 たとえば，ファイルやディレクトリの登録データはそのファイルまたはディレクトリのヘッダに保存されます。 次の表は，登録データベースに保存される情報についてまとめたものです。

2.2.2 項 「オブジェクト」からわかるように，OpenVMS システムの各オブジェクトには，共用時の柔軟性にいくつかのレベルがあります。 保護オブジェクトは，保護コードに従っています。 このコードは，システム・ユーザ，オブジェクトの所有者であるユーザ，所有者が属する UIC グループの他のメンバ，およびその他すべてのユーザのために実行されるプロセスに対して，アクセスを許可 (または拒否) するかどうかを指定します。

保護コードに加えて，アクセス制御リスト (ACL) の制御に基づいてオブジェクトを共用することもできます。 ACL は，特にユーザ・グループやそのサブセットに対して，UIC に基づく保護よりも細かいアクセス制御を提供します。 ACL には，オブジェクトに対する特定のタイプのアクセスを許可または拒否するユーザまたはユーザ・グループが記述されます。 ACL では，UIC の識別情報だけでなく，プロセスに関連付けることができる他のグループ分類や識別子に基づいて共用を指定できます。 たとえば，ダイアルアップ回線でターミナルに接続されたプロセスによってファイルが読み込まれないように指定することができます。 2.2.6 項 「アクセス・マトリックスで表した登録データベース」では，アクセス・マトリックスを使用して ACL の概念を説明します。 4.4 項 「ACL によるアクセスの制御」では ACL と識別子に関する一般的な説明を示し，第8章 「システムのデータと資源へのアクセスの制御」ではセキュリティ管理者が識別子を作成してシステム資源の ACL を構築する方法について説明します。

2.2.4 監査証跡

すべてのセキュリティ関連イベントは，監査ログ・ファイルに記録されるか，オペレータ・ターミナルに送信されるか，またはその両方が行われます。 ターミナルをセキュリティ・オペレータ・ターミナルに指定すると，すべての監査可能イベントがそのターミナルに表示されます。 監査ログ・ファイルには，セキュリティ・イベントが永続的に記録されます。 システム管理者は，ログ・ファイルを調べることで処理のパターンを見つけることができます。 このパターンを監査証跡と呼びます。

オペレーティング・システムは，表 2-2 「セキュリティ監査機能の概要」 に示すセキュリティ・イベントのクラスをデフォルトで監査します。 他のイベント (ボリュームのマウントやシステム時刻の変更など) を監査対象として選択することもできます。

ユーザとセキュリティ管理者は，監査ログにさまざまなイベントを記録できます。 すべてのイベントを調べるのは時間がかかり過ぎるので，セキュリティ状況の把握に役立つ情報を豊富に含むイベントだけを監査するのが最も効率的です。 セキュリティ監査機能の詳細については，第10章 「セキュリティ監査の実施」を参照してください。

2.2.5 リファレンス・モニタ

OpenVMS オペレーティング・システムでは，エグゼクティブがリファレンス・モニタの役割を実行します。 カーネル・モードとエグゼクティブ・モードで実行されるすべてのシステム・プログラムが，コマンド行インタプリタや特権で実行される特定のユーザ・モード・イメージとともに，リファレンス・モニタの実装に一役買っています。 エグゼクティブを構成するコードの量は膨大ですが，それらのコードがシステム・セキュリティの適用を回避する手段にならないようにするための努力が払われています。

特権の中には，リファレンス・モニタを変更または無効化する権限をユーザに与えるものがあります。 たとえば，CMKRNL 特権を持つプロセスは，自身のコードをシステム・カーネル内で実行することにより，リファレンス・モニタの内部データや保護オブジェクトの内部表現にアクセスできます。 当然ながら，このような重要な特権は厳しく制限する必要があります。

同じように，SYSPRV や SECURITY などの特権は，リファレンス・モニタや登録データベースの維持に役立つプロセスのユーザのみに付与します。

2.2.6 アクセス・マトリックスで表した登録データベース

リファレンス・モニタのモデルには，登録データベースが規定されています。 登録データベースには，すべてのサブジェクトとすべてのオブジェクトに関するシステム内のすべてのアクセス登録情報が記述されます。 このデータベースは，多くの場合，一方の軸にサブジェクトを並べ，もう一方の軸にオブジェクトを並べたアクセス・マトリックスで表現されます (図 2-2 「登録アクセス・マトリックス」 を参照)。 マトリックス内の交点は，それぞれ，あるサブジェクトがあるオブジェクトに関して許可されているアクセスを表します。

図 2-2 登録アクセス・マトリックス

このアクセス・マトリックスでは，該当するサブジェクトが該当するオブジェクトへのアクセスを許可されている場合にアスタリスク (*) が付いています。 説明を簡単にするため，この例ではアクセスのタイプ (読み込みや書き込みなど) は省略しています。 たとえば，サブジェクト B，C，および D は，すべてオブジェクト W，X，および Y へのアクセスを許可されています。 さらに，サブジェクト A はオブジェクト W および Z へのアクセスを，サブジェクト D はオブジェクト V へのアクセスを，サブジェクト E はオブジェクト V へのアクセスを，それぞれ許可されています。

アクセス・マトリックスを行単位で分割すると，ケーパビリティ・ベースのモデルになります。 ケーパビリティ・ベースのモデルでは，アクセスできるオブジェクトのリストがサブジェクトごとに保持されます。 たとえば，このアクセス・マトリックスをケーパビリティに基づいて表現すると，次のようになります。

A: W, Z B: W, X, Y C: W, X, Y D: V, W, X, Y E: V

一方，アクセス・マトリックスを列単位で分割して，アクセスが許可されているサブジェクトをオブジェクトごとに列挙することもできます。 この場合は，権限ベースのモデルになり，OpenVMS では ACL によって実装されています (第4章 「データの保護」を参照)。 ACL での表現は，次のようになります。

V: D, E W: A, B, C, D X: B, C, D Y: B, C, D Z: A

オペレーティング・システムで使用される ACL と識別子による制御は，ケーパビリティ・ベースのシステムと権限ベースのシステムの両方の性質を兼ね備えています。 OpenVMS システムでは，サブジェクトとオブジェクトの両方が識別子を保持します。 サブジェクトは，一致する識別子をオブジェクトが持っている場合と，要求したアクセスがオブジェクトのアクセス・ステートメントによって許可される場合に，そのオブジェクトにアクセスできます。

ケーパビリティ・ベースのシステムと権限ベースのシステムの両方の性質を兼ね備えた結果，複雑なアクセス・マトリックスを簡潔かつ手頃な方法で表現できる，きわめて強力で柔軟性に富んだシステムになっています。 上記のアクセス・マトリックスの例について，図 2-3 「交点にラベルを付けた登録アクセス・マトリックス」 のように一部の交点にラベルを付けた場合を考えてみましょう。

図 2-3 交点にラベルを付けた登録アクセス・マトリックス

同じラベルを付けた複数の交点は，1 つのエンティティとしてグループ化して扱うことができます。 たとえば，図 2-3 「交点にラベルを付けた登録アクセス・マトリックス」 で Q というラベルの付いた交点は，サブジェクト B，C，および D がオブジェクト W，X，および Y に関して許可されているアクセスを表します。 Q という交点は，すべて 1 つの関心領域として考えることができます。 識別子の概念は，このような関心領域のグループ化の利点を実用化するために提供されています。

図 2-3 「交点にラベルを付けた登録アクセス・マトリックス」 では，P と Q という 2 つのアクセス・グループを表す識別子をそれぞれ定義できます。 マトリックスにはラベルの付いていない交点が 2 つ残っていることに注意してください。 識別子は個々のサブジェクトを表すこともできるので，従来の ACL の機能も使用できます。

OpenVMS オペレーティング・システムでは，アクセス・マトリックスの 2 つの次元を表すために以下の 2 つの構造を使用します。

アクセス・マトリックスを表すのに必要なシステム構造は，従来のケーパビリティ・ベースのモデルや権限ベースのモデルより簡単で，全体としてはより少ない字数で表すことができます。 この例ではわずかな違いしかありませんが，アクセス・マトリックスの複雑さは規模の 2 乗に比例して増大します。