この章では,オペレーティング・システムに組み込まれたセキュリティの機能やメカニズムを設計および実装する際の指針となった概念を示します。ここでの目的は,システム・セキュリティの全体像を考える際の枠組みを提供することです。後の各章では,セキュリティ機能とその使用方法について詳しく説明します。
2.1 安全なオペレーティング・システムの構造
1960 年代後半,マルチユーザのコンピュータ・システムでどのようにセキュリティを実現するかという問題に対する研究開発が数多く行われました。開発作業の多くは,システムのセキュリティを損なうおそれのある要素をすべて洗い出し,それらの不具合を 1 つ 1 つ修正していくことに充てられました。やがて研究者は,このプロセスが無駄であり,有効なシステム・セキュリティは安全なコンピュータ・システムの構造に関する基本モデルからしか生まれないことに気づきました。リファレンス・モニタの概念は,このようなモデルとして提案され,広く受け入れられました。
2.1.1 リファレンス・モニタの概念
リファレンス・モニタの概念によれば,図 2-1
のように,コンピュータ・システムはサブジェクト,オブジェクト,登録データベース,監査証跡,およびリファレンス・モニタによって表現されます。リファレンス・モニタは,サブジェクトを認証し,サブジェクトによるオブジェクトへのあらゆるアクセスに関してセキュリティ・ポリシーを実装および実施する管理センターです。
図 2-1: リファレンス・モニタ
次の表は,図 2-1 に示した各要素の説明です。
| 項番 | 要素 | 説明 |
1 |
サブジェクト |
人間のために情報にアクセスする能動的なエンティティ (ユーザ・プロセスなど)。 |
2 |
オブジェクト |
保護すべき情報の受動的な格納場所 (ファイルなど)。 |
3 |
登録データベース |
サブジェクトとオブジェクトのセキュリティ属性の格納場所。リファレンス・モニタは,これらの属性に基づいて,許可されたアクセスの種類を (もしあれば) 特定します。 |
4 |
監査証跡 |
すべてのセキュリティ関連イベント (成功または失敗したアクセス操作など) のレコード。 |
2.1.2 リファレンス・モニタによるセキュリティ規則の実施
リファレンス・モニタは,サブジェクトの作成を許可し,サブジェクトによるオブジェクトへのアクセスを認め,必要に応じて監査証跡にイベントを記録することによって,セキュリティ・ポリシーを実施します。理想のシステムでは,リファレンス・モニタが以下の 3 つの要件を満たす必要があります。
サブジェクトがオブジェクトへのアクセスを得ようとする操作をすべて仲介する。
許可されない参照や変更から完全に保護された,不正操作に強いデータベースと監査証跡を提供する。
セキュリティ要件を効果的に適用できるように,ソフトウェアを小規模で単純な合理化されたものにする。
上記は,侵入行為があっても安全が確保できるシステムに関して提案される要件です。このようなシステムでは,オペレーティング・システムのセキュリティ関連サブセット (セキュリティ・カーネル) によってリファレンス・モニタが実装されます。
2.2 リファレンス・モニタの実装
OpenVMS オペレーティング・システムでは,リファレンス・モニタがセキュリティ関連サブセット (セキュリティ・カーネル) として実装されませんが,リファレンス・モニタの概念で要求されている基本構造は,ユーザやシステム管理者に対するインタフェースに反映されています。これまでの経験から,詮索行為やほとんどの侵入行為に対抗できるシステムを構築するには,このような構造を組み込むことが最善の方法であることがわかっています。
以下の各セクションでは,OpenVMS オペレーティング・システムにおけるリファレンス・モニタ・モデルの実装について説明します。
2.2.1 サブジェクト
サブジェクトは,情報にアクセスする (場合によっては情報へのアクセスを禁止される) ユーザまたはユーザ・エージェント (ユーザ・プロセス) です。サブジェクトは会話形式のプロセス,ネットワーク・プロセス,またはバッチ・ジョブであり,次の特徴を持っています。
以下の時点でセキュリティ制御を通過する必要があります。
以下の識別が必要です。
ユーザがオペレーティング・システムを会話形式で使用するためのログインした時点,またはバッチ・ジョブやネットワーク・ジョブが開始した時点で,オペレーティング・システムはそのユーザの識別情報を含むプロセスを作成します。作成されたプロセスは,第 4 章で説明するように,ユーザのエージェントとして情報にアクセスします。
作成中のプロセスや情報にアクセスしているプロセスは,セキュリティ侵害に対して脆弱です。システムは,登録データと内部のメカニズム (ハードウェア制御など) を使用して,プロセスによる情報へのアクセスを処理します。プロセスの作成にはさまざまな分野でセキュリティの脆弱性があるため,オペレーティング・システムのセキュリティ機能の多くはプロセス (またはサブジェクト) 作成の分野に集中しています。
ユーザは,システムにログインしようとするときに, ユーザ名 (作成されるプロセスに与えられる名前) とパスワードを入力します。 パスワードは,ユーザとオペレーティング・システムだけが知っている認証情報としての役割を果たします。
短いパスワードや自明のパスワードではこの要件を満たせない可能性があるため,システムにはさまざまなパスワード保護メカニズムが組み込まれており,それらをユーザが呼び出したり,セキュリティ管理者が要求したりできるようになっています (第 7 章を参照)。オペレーティング・システムには,侵入者がパスワードを推測するために行う操作の回数を制限する機能もあります。
ユーザ・パスワードのファイルは,セキュリティ・データベースの一部であり,許可されない参照や変更から保護する必要があります。この要件を満たすために,システムでは一般のアクセスから保護されたファイルにパスワードが保存されます。このファイルをシステム・ユーザ登録ファイル (SYSUAF.DAT) と呼びます。 また,追加的な予防措置として, パスワードが盗まれても簡単には使用できないように,エンコードされた形式でパスワードが保存されます。
オペレーティング・システムは,ユーザのプロセスを作成すると,ユーザ登録レコードに基づいてユーザ識別コード
(UIC) をそのプロセスに割り当てます。UIC は,
プロセスを作成したユーザの名前 (ユーザのパスワードによって認証されたもの) に対応します。また,UIC はユーザが自分の部署,プロジェクト,または職務に対応するグループのメンバであることも示します。プロセスの作成やプロセス所有者の他のグループとの関係に関する追加情報をプロセスに関連付けることもできます。これらの追加情報は,登録データベースを適用するときに一定の役割を果たします。UIC については,第 4 章と第 8 章で説明します。
2.2.2 オブジェクト
リファレンス・モニタの概念では,オブジェクトは情報の受動的な格納場所です。表 2-1に示すように,OpenVMS にはファイルやデバイスなどのさまざまなオブジェクトがあり,保護の対象になっています。オペレーティング・システムは,不正なアクセスからオブジェクトを保護し,(第 4 章および第 5 章で説明するように) それらを制御された方法で共用するための各種のメカニズムを提供します。これらのメカニズムは,システム資源へのアクセスを制御するときにも使用されます。
表 2-1: セキュリティ制御によって保護されるオブジェクト
| クラス名 | 定義 |
ケーパビリティ |
システムによってアクセスが制御される資源。現時点で定義されているケーパビリティは,ベクタ・プロセッサだけです。 |
コモン・イベント・フラグ・クラスタ |
連携するプロセス同士がイベント通知を相互に提示できるようにするために,32 個のイベント・フラグをセットにしたもの。 |
デバイス |
プロセッサに接続された周辺機器のクラスの 1 つで,データを受信,保存,または伝送する機能をもつもの。 |
ファイル |
Files-11 オン・ディスク構造レベル 2 または 5 のファイルおよびディレクトリ。 |
グループ・グローバル・セクション |
同じグループ内のすべてのプロセスが使用できる共用可能なメモリ・セクション。 |
論理名テーブル |
システムまたは特定のグループに関する論理名とその等価名を格納した共用可能なテーブル。 |
キュー |
バッチ,ターミナル,サーバ,またはプリント・ジョブ・キューで処理される一連のジョブ。 |
資源ドメイン |
ロック・マネージャの資源へのアクセスを制御するネームスペース。 |
セキュリティ・クラス |
セキュリティ・クラスのすべてのメンバに関する要素と管理ルーチンを格納するデータ構造。 |
システム・グローバル・セクション |
システム内のすべてのプロセスが使用できる共用可能なメモリ・セクション。 |
ボリューム |
ディスクやテープなどの,ODS-2 形式または ODS-5 形式の大容量ストレージ媒体。ボリュームは,ファイルを格納するもので,デバイスにマウントすることができます。 |
リファレンス・モニタの概念では,各サブジェクトがオブジェクトへのアクセスを得るための認証は,抽象的な登録データベースに基づいて行われます。このデータベースは,サブジェクトによるオブジェクトへのアクセスを常に統御する動的なセキュリティ属性を集めたものです。OpenVMS システムでは,このデータベースは保護するオブジェクトとの関連に基づいて分散して保存されます。たとえば,ファイルやディレクトリの登録データはそのファイルまたはディレクトリのヘッダに保存されます。次の表は,登録データベースに保存される情報についてまとめたものです。
| ファイル | 内容 | 解釈に使用されるデータ |
#SYSUAF.DAT |
ユーザ名 |
ログイン |
パスワード |
ログイン |
|
UIC |
アクセス制御のチェック |
|
#NETPROXY.DAT |
ユーザ名 |
ログイン |
#NET$PROXY.DAT |
ユーザ名 |
ログイン |
#RIGHTSLIST.DAT |
ライト識別子 |
アクセス制御のチェック |
#VMS$OBJECTS.DAT |
UIC |
アクセス制御のチェック |
保護コード |
アクセス制御のチェック |
|
アクセス制御リスト |
アクセス制御のチェック |
|
#VMS$AUDIT_ #SERVER.DAT |
監査可能イベント |
イベントの報告 |
2.2.2 項からわかるように,OpenVMS システムの各オブジェクトには,共用時の柔軟性にいくつかのレベルがあります。保護オブジェクトは,保護コードに従っています。 このコードは,システム・ユーザ,オブジェクトの所有者であるユーザ,所有者が属する UIC グループの他のメンバ,およびその他すべてのユーザのために実行されるプロセスに対して,アクセスを許可 (または拒否) するかどうかを指定します。
保護コードに加えて,アクセス制御リスト (ACL)
の制御に基づいてオブジェクトを共用することもできます。ACL は,特にユーザ・グループやそのサブセットに対して,UIC に基づく保護よりも細かいアクセス制御を提供します。ACL には,オブジェクトに対する特定のタイプのアクセスを許可または拒否するユーザまたはユーザ・グループが記述されます。ACL では,UIC の識別情報だけでなく,プロセスに関連付けることができる他のグループ分類や識別子に基づいて共用を指定できます。たとえば,ダイアルアップ回線でターミナルに接続されたプロセスによってファイルが読み込まれないように指定することができます。2.2.6 項では,アクセス・マトリックスを使用して ACL の概念を説明します。4.4 節では ACL と識別子に関する一般的な説明を示し,第 8 章ではセキュリティ管理者が識別子を作成してシステム資源の ACL を構築する方法について説明します。
2.2.4 監査証跡
すべてのセキュリティ関連イベントは,監査ログ・ファイルに記録されるか,オペレータ・ターミナルに送信されるか,またはその両方が行われます。ターミナルをセキュリティ・オペレータ・ターミナルに指定すると,すべての監査可能イベントがそのターミナルに表示されます。監査ログ・ファイルには,セキュリティ・イベントが永続的に記録されます。システム管理者は,ログ・ファイルを調べることで処理のパターンを見つけることができます。このパターンを監査証跡と呼びます。
オペレーティング・システムは,表 2-2
に示すセキュリティ・イベントのクラスをデフォルトで監査します。他のイベント (ボリュームのマウントやシステム時刻の変更など) を監査対象として選択することもできます。
表 2-2: セキュリティ監査機能の概要
| 出力先 | デフォルトで監査されるイベント |
ログ・ファイルまたはターミナルのディスプレイ |
登録データベースの変更 |
侵入行為 |
|
ログインの失敗 |
|
|
DCL の SET AUDIT コマンドの使用 |
|
監査用 ACE またはアラーム用 ACE によって起動するイベント |
ユーザとセキュリティ管理者は,監査ログにさまざまなイベントを記録できます。すべてのイベントを調べるのは時間がかかり過ぎるので,セキュリティ状況の把握に役立つ情報を豊富に含むイベントだけを監査するのが最も効率的です。セキュリティ監査機能の詳細については,第 9 章を参照してください。
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 つの構造を使用します。
ライト・リスト (RIGHTSLIST.DAT) は,アクセス・マトリックスの行を表し,ケーパビリティ・ベースのモデルに対応します。図 2-3 のマトリックスの場合は,次のライト・リストが必要になります。
B: Q C: Q D: P, Q E: P
保護オブジェクトの ACL は,アクセス・マトリックスの列を表します。上記の例では,次の ACL が必要になります。
V: P W: A, Q X: Q Y: Q Z: A
アクセス・マトリックスを表すのに必要なシステム構造は,従来のケーパビリティ・ベースのモデルや権限ベースのモデルより簡単で,全体としてはより少ない字数で表すことができます。この例ではわずかな違いしかありませんが,アクセス・マトリックスの複雑さは規模の 2 乗に比例して増大します。
2.3 要約 : システム・セキュリティ設計
システム全体のセキュリティ計画を設計するときは,以下の質問に回答してください。
ユーザはサブジェクトとどのように関連付けられていますか。認証メカニズムにはどの程度の信頼性がありますか。
このシステムまたはアプリケーションでは,どのオブジェクトに機密情報が含まれていますか。それらのオブジェクトに対するアクセスは制御されていますか。
登録データベースにはサイトのセキュリティ・ポリシーが反映されていますか。機密オブジェクトへのアクセスは誰に許可されていますか。制限が十分に行われていますか。
監査証跡に記録される情報は十分ですか。または,多過ぎませんか。監査証跡は誰が監視しますか。監査証跡をどの程度の頻度でチェックしますか。
リファレンス・モニタの構成要素として機能するのはどのプログラムですか。セキュリティ・ポリシーと登録データベースを変更できるのはどのユーザですか。それは,望ましい構成ですか。
これらの考慮事項は,土台となるリファレンス・モニタの設計と同じように,ファイルやデータベースのレコードへのアクセスを許可するシステム上のタイムシェアリング・システム,広範囲のネットワーク,または個々のアプリケーションに等しく適用されます。オペレーティング・システムは,ユーザとセキュリティ管理者がシステム・セキュリティを実現するために適用すべき一般的なメカニズムを提供します。セキュリティ・ポリシーの設計と実装の詳細については,第 6 章を参照してください。