強制的アクセス制御に基づくWebサーバーに関する … › security › fy16 › reports › mandatory...5.4 SELinux SPM.....94 5.4.1 ポリシー・モデルの概要.....94

2005 年 3 月

強制的アクセス制御に基づく Web サーバーに関する

調査･設計に関する調査報告書

‐i‐

目次

1 はじめに .........................................................................................................................1

1.1 背景.....................................................................................................................1

1.2 本調査の目的 ......................................................................................................4

1.3 調査方法 .............................................................................................................4

1.4 本調査報告書の想定される利用者 ........................................................................5

1.5 本報告の構成 ......................................................................................................5

2 Webサーバー･システムのモデリング................................................................................8

2.1 Web コンテンツの分類 ..........................................................................................9

2.2 ユーザ ...............................................................................................................10

2.2.1 Web クライアント･ユーザ.................................................................................. 11

2.2.2 Web コンテンツ管理者 .................................................................................... 11

2.2.3 Webシステム管理者 ....................................................................................... 11

2.3 オペレーティング･システムとの対応 .....................................................................12

2.3.1 Web コンテンツ ...............................................................................................12

2.3.2 ユーザ............................................................................................................13

2.4 Webサーバーの内部モジュール.........................................................................15

2.4.1 Webサーバーの内部モジュール .....................................................................15

2.4.2 Webサーバーが利用するオペレーティング･システムの機能 .............................19

2.5 Webサーバー内の処理フロー ............................................................................22

3 Webサーバー･システムの脆弱性分析 ...........................................................................28

3.1 脅威の対象 ........................................................................................................28

3.1.1 コンテンツ .......................................................................................................29

3.1.2 ネットワークを流れるデータ ..............................................................................30

3.1.3 Webサーバー ................................................................................................32

3.1.4 Web クライアント..............................................................................................33

3.2 Webサーバーに対する攻撃手段の分析..............................................................34

3.2.1 攻撃の種類 ....................................................................................................34

3.2.2 なりすまし .......................................................................................................35

3.2.3 バグの利用 .....................................................................................................38

3.2.4 設定ミスの利用 ...............................................................................................39

‐ii‐

3.2.5 仕様上の問題の利用 ......................................................................................41

3.2.6 バックドアの利用 .............................................................................................42

3.2.7 DoS ...............................................................................................................44

3.2.8 クロスサイト・スクリプティング.............................................................................46

3.2.9 盗聴 ...............................................................................................................47

3.3 脆弱性対策の方針 .............................................................................................49

3.4 脅威に対する対策 ..............................................................................................51

3.4.1 なりすましに対する対策 ...................................................................................52

3.4.2 バグの利用に対する対策 ................................................................................53

3.4.3 設定ミスの利用に対する対策 ...........................................................................54

3.4.4 仕様上の問題に対する対策 ............................................................................54

3.4.5 バックドアの利用に対する対策.........................................................................55

3.4.6 DoS攻撃に対する対策...................................................................................55

3.4.7 クロスサイト・スクリプティングに対する対策 ........................................................56

3.4.8 盗聴に対する対策 ..........................................................................................56

3.5 脆弱性分析のまとめ............................................................................................56

4 アクセス制御に対する要件.............................................................................................58

4.1 強制的アクセス制御実現のための要件 ................................................................58

4.2 Webサーバー･システムのための要件 .................................................................60

5 関連セキュリティ･ポリシー・モデルの分析........................................................................62

5.1 Hoffman’s RBAC..............................................................................................65

5.1.1 RBAC と TEを組み合わせる利点 ...................................................................65

5.1.2 ポリシー・モデルの概要 ...................................................................................66

5.1.3 ポリシー・モデルの特徴 ...................................................................................68

5.1.4 Webサーバーへの適応性分析 .......................................................................69

5.2 DAFMAT..........................................................................................................70

5.2.1 RBAC と DTEを組み合わせる利点 ................................................................71

5.2.2 ポリシー・モデルの概要 ...................................................................................71

5.2.3 ポリシー・モデルの特徴 ...................................................................................77

5.2.4 Webサーバーへの適応性分析 .......................................................................79

5.3 PARBAC...........................................................................................................80

5.3.1 RBAC と DTEを組み合わせる利点 ................................................................80

5.3.2 ポリシー・モデルの特徴 ...................................................................................91

‐iii‐

5.3.3 Webサーバーへの適応性分析 .......................................................................92

5.4 SELinux SPM ..................................................................................................94

5.4.1 ポリシー・モデルの概要 ...................................................................................94

5.4.2 ポリシー・モデルの特徴 ...................................................................................95

5.4.3 Webサーバーへの適応性分析 .......................................................................99

5.5 Trusted Solaris SPM ..................................................................................... 100

5.5.1 ポリシー・モデルの概要 ................................................................................. 101

5.5.2 ポリシー・モデルの特徴 ................................................................................. 101

5.5.3 Webサーバーへの適応性分析 ..................................................................... 106

5.6 各モデルの比較 ............................................................................................... 108

5.6.1 サブジェクトに付与されるラベルの決定因子 ................................................... 108

5.6.2 アクセス制御の特徴 ...................................................................................... 108

5.6.3 異なるアクセス制御を行う仕組み.................................................................... 109

5.6.4 ドメイン（機密ラベル）の追加に影響される要素................................................ 111

5.6.5 被害範囲 ...................................................................................................... 112

6 実装システムの調査 .................................................................................................... 116

6.1 RBAC/Web ..................................................................................................... 116

6.2 PDRBAC ........................................................................................................124

6.3 SELinux .........................................................................................................128

6.3.1 オブジェクト･タイプの付与 ............................................................................. 128

6.3.2 ドメインの付与 ............................................................................................... 128

6.3.3 アクセス制御 ................................................................................................. 129

6.3.4 ユーザとロール、ロールとドメイン .................................................................... 130

6.3.5 オブジェクト･クラスとアクセス･ベクターの一覧 ................................................. 131

6.3.6 ドメイン遷移の動的な選択 ............................................................................. 150

6.4 Trusted Solaris .............................................................................................. 151

6.4.1 格付けとコンパートメントの設定 ...................................................................... 151

6.4.2 特権 ............................................................................................................. 154

6.5 Apache............................................................................................................159

6.5.1 認証（Authentication）................................................................................. 159

6.5.2 認可（Authorization） .................................................................................. 161

6.6 IIS................................................................................................................... 168

6.6.1 認証（Authentication）................................................................................. 168

‐iv‐

6.6.2 認可（Authorization） .................................................................................. 170

7 おわりに...................................................................................................................... 175

‐v‐

図目次

図 1-1 WEBサーバーのアクセス制御 .............................................................................................. 3

図 1-2 調査方法 ............................................................................................................................ 5

図 2-1 WEBサーバー･システム...................................................................................................... 8

図 2-2 オペレーティング･システムアクセス制御を考慮したサブジェクト分類 .................................. 10

図 2-3 WEBクライアントとオペレーティング･システムにおけるアカウントの対応............................. 13

図 2-4 WEBサーバー･システムの内部モジュール・モデル .......................................................... 15

図 2-5 設定時における処理フロー................................................................................................ 23

図 2-6 基本サービス・フロー・モデル ............................................................................................ 24

図 2-7 認証サービス・フロー・モデル ............................................................................................ 25

図 2-8 セッション・サービス・フロー・モデル ................................................................................... 27

図 3-1 WEBサーバー・システムにおける脅威の対象 .................................................................... 29

図 3-2 なりすまし：ユーザ名とパスワードの利用............................................................................. 37

図 3-3 なりすまし：セッション情報の利用 ....................................................................................... 37

図 3-4 バグの利用 ....................................................................................................................... 39

図 3-5 設定ミスの利用 ................................................................................................................. 41

図 3-6 仕様上の問題 ................................................................................................................... 42

図 3-7 バックドアの利用 ............................................................................................................... 44

図 3-8 DOS攻撃 ......................................................................................................................... 46

図 3-9 クロスサイト・スクリプティング .............................................................................................. 47

図 3-10 盗聴 ............................................................................................................................... 48

図 5-1 RBACの基本モデルとWEBサーバーへの適応例............................................................ 63

図 5-2 HOFFMANによる RBAC と TEの混合モデル概要 ............................................................ 67

図 5-3 HOFFMANによる RBAC と TEのモデル構造 ................................................................... 67

図 5-4 DAFMATにおける承認エンティティ相関図 ...................................................................... 76

図 5-5 パーパス・ヒエラルキー例 .................................................................................................. 82

図 5-6 PARBACモデル構造 ..................................................................................................... 87

図 5-7 PARBACの承認プロセス ................................................................................................. 91

図 5-8 DAC と SELINUXモジュールの関係................................................................................. 95

図 5-9 SELINUXのセキュリティ･ポリシー･モデルの構造............................................................... 98

図 5-10 サブジェクトのドメインが決まる過程 .................................................................................. 99

‐vi‐

図 5-11 DAC とMAC................................................................................................................ 101

図 5-12 格付けとアクセス可能範囲............................................................................................. 103

図 5-13 TRUSTED SOLARISのセキュリティ･ポリシー･モデルの構造............................................. 106

図 6-1 RBAC/WEB ADMIN TOOLでのロール・ヒエラルキーの表示例 ......................................... 122

図 6-2 RBAC/WEB エンド・ユーザの視点 ................................................................................. 124

図 6-3 CDSA（COMMON DATA SECURITY ARCHITECTURE）...................................................... 125

図 6-4 PLのポリシー強制.......................................................................................................... 126

図 6-5 PDRBACによって拡張した CDSA................................................................................. 127

図 6-6 SETEXECCONとドメイン遷移........................................................................................... 151

‐vii‐

表目次

表 2-1 WEBサーバーの各モジュールが必要なオペレーティング･システム機能 ........................... 22

表 3-1 攻撃の種類と対策の有効性 .............................................................................................. 57

表 5-1 DAFMATにおける承認エンティティのマッピング .............................................................. 75

表 5-2 RERBACにおけるエンティティのマッピング ...................................................................... 87

表 5-3 機密ラベルの例 .............................................................................................................. 103

表 5-4 サブジェクトに付与されるラベルの決定因子..................................................................... 108

表 5-5 アクセス制御の特徴 ........................................................................................................ 109

表 5-6 異なるアクセス制御を行う仕組み ..................................................................................... 110

表 5-7 ドメイン（機密ラベル）の追加に影響される要素 ................................................................. 112

表 5-8 WEBサーバーの改竄による被害範囲 ............................................................................. 113

表 5-9 動的コンテンツの改竄による被害範囲 ............................................................................. 114

表 6-1 RBAC/WEBのコンポーネント.......................................................................................... 117

表 6-2 オブジェクト・クラス .......................................................................................................... 132

表 6-3 ユーザスペース・オブジェクトクラス................................................................................... 134

表 6-4 ファイル関連共通アクセス・ベクター ................................................................................. 135

表 6-5 ソケット関連で共通のアクセス・ベクター ........................................................................... 136

表 6-6 プロセス間通信関連共通アクセス・ベクター...................................................................... 136

表 6-7 FILESYSTEMのアクセス・ベクター .................................................................................. 137

表 6-8 DIRのアクセス・ベクター .................................................................................................. 137

表 6-9 FILEのアクセス･ベクター ................................................................................................ 137

表 6-10 CHR_FILEのアクセス・ベクター ...................................................................................... 138

表 6-11 FDのアクセス・ベクター ................................................................................................. 138

表 6-12 TCP_SOCKETのアクセス・ベクター................................................................................ 139

表 6-13 UDP_SOCKETのアクセス･ベクター................................................................................. 139

表 6-14 RAWIP_SOCKETのアクセス・ベクター ............................................................................. 139

表 6-15 NODEのアクセス･ベクター............................................................................................. 140

表 6-16 NETIFのアクセス･ベクター ............................................................................................ 140

表 6-17 UNIX_STREAM_SOCKETのアクセス･ベクター ................................................................. 141

表 6-18 PROCESSのアクセス･ベクター........................................................................................ 142

‐viii‐

表 6-19 MSGQのアクセス･ベクター............................................................................................. 142

表 6-20 MSGのアクセス･ベクター............................................................................................... 142

表 6-21 SHMのアクセス･ベクター............................................................................................... 143

表 6-22 SECURITYのアクセス･ベクター ...................................................................................... 143

表 6-23 SYSTEMのアクセス･ベクター ......................................................................................... 144

表 6-24 CAPABILITYのアクセス･ベクター ................................................................................... 145

表 6-25 PASSWDのアクセス･ベクター ......................................................................................... 145

表 6-26 その他オブジェクト・クラスのアクセス・ベクター................................................................ 150

表 6-27 格付けの設定時に使用できるタグ.................................................................................. 152

表 6-28 コンパートメントの設定時に使用できるタグ ..................................................................... 153

表 6-29 格付けとコンパートメントの組み合わせを制約するためのタグ .......................................... 154

表 6-30 ファイルシステム関連の特権.......................................................................................... 155

表 6-31 SYSTEMV IPC関連の特権 ......................................................................................... 155

表 6-32 ネットワーク関連の特権 ................................................................................................. 156

表 6-33 プロセス関連の特権 ...................................................................................................... 157

表 6-34 システム関連の特権 ...................................................................................................... 158

表 6-35 ウィンドウ関連の特権..................................................................................................... 159

表 6-36 APACHEの認証方式..................................................................................................... 161

表 6-37 APACHEの実装するアクセス制御 .................................................................................. 163

表 6-38 POSIX準拠のファイルシステムのアクセス権限................................................................ 163

表 6-39 NTFSのアクセス権限と論理グループ ........................................................................... 167

表 6-40 APACHEの認可の対象の種類....................................................................................... 167

表 6-41 IISの認証方式 ............................................................................................................ 170

表 6-42 IISの実装するアクセス制御.......................................................................................... 171

表 6-43 NTFSのアクセス権限と論理グループ ........................................................................... 174

表 6-44 IISの認可の対象の種類 .............................................................................................. 174

‐1‐

1 はじめに

本報告書は、「強制的アクセス制御に基づく We b サーバーに関する

調査・設計」に関する調査報告書である。本調査報告書は、「強制的

アクセス制御に関するセキュリティ・ポリシー・モデルの We b サーバーへの

適用性の調査編」、および「既存 We b サーバー・システムにおけるアクセ

ス制御の調査編」の 2 部から構成される。

1 .1 背景

中央省庁のインターネット We b サーバー・システムのように、データのイ

ンテグリティが強く求められているシステムの開発・構築においては、総

合的なセキュリティ設計に基づくことが望まれている。このような中で、近

年、セキュアシステム構築のための基盤ソフトウェアとして、セキュアオペ

レーティング・システムに代表される強制的アクセス制御機能を有するオ

ペレーティング・システムが注目されている。オペレーティング・システムに

よる強制的アクセス制御は、オペレーティング・システム上のすべてのリソ

ースおよびアプリケーションに対してセキュリティ・ポリシーに沿ったアクセ

ス制御を強制することができるため、インターネット We b サーバー・システ

ムにおける効果的な改ざん防止対策としての活用が望まれている。

We b サーバー・システムのように、あらゆる攻撃に晒され易いシステムに

おいては、 1 0 0 %安全なシステムを構築することは現実的に不可能であ

る。そのため、We b サーバーが仮に悪意ある者により攻撃された場合で

も、その被害の範囲を予測可能な限定的なものにすることが必要となる。

被害の範囲を予測可能な限定的なものにするには、We b サーバーに与

えられる権限の細分化と最少化、および、そのセキュリティ・ポリシーの強

制的な適用が必要となる。つまり、アプリケーションの任意性に依存せず、

セキュリティ管理者により設定されたセキュリティ・ポリシーを、強制的に

‐2‐

適用する強制的アクセス制御が必要となる。

強制的アクセス制御の導入により、セキュリティ管理者の定めたセキュ

リティ・ポリシーが回避されることを避け、必ずセキュリティ・ポリシーに沿っ

た運用を保障するものである。これを We b サーバーに適用することにより、

We b サーバーがアクセス制御の主体を担うのではなく、オペレーティン

グ・システムがアクセス制御の主体を担うことで、オペレーティング・システ

ムのセキュリティ管理者が We b サーバーのアクセス制御についても管理

することが可能になる。また、アクセス権を設定するセキュリティ管理者と、

サービスを実行する We b サーバーの権限が分離される。これは、セキュリ

ティにおいての権限の細分化になり、We b サーバーの安全性を高めるた

めに有効となる。

しかし、従来の We b サーバーは、オペレーティング・システム上で動作

する 1 つのアプリケーションとして実現されていた (図 1 - 1 )。汎用オペレ

ーティング・システムの一般的な機能のみに依存し、特定のプラットフォ

ームに依存しない形で実現される We b サーバーは、ポータビリティが高

い、というメリットがある。特定のプラットフォームに依存しないため、任意

のハードウェアとソフトウェアの組み合わせで運用できるため、運用コスト

を低くすることが可能である。しかし、この汎用性というメリットは、セキュリ

ティを考えた場合、メリットが低い。

We b サーバーは、オペレーティング・システム上の特定の権限で動作

し、We b サーバーが稼動している間は、常に同じ権限で We b クライアン

トの要求に応える。We b クライアントからのリクエストは、We b サーバーが

承認し、リクエストに応えるため、オペレーティング・システムのアクセス制

御が介在することは基本的に無い。特にプラットフォーム非依存に設計

されているため、この特徴は顕著に現れる、つまり、アクセス制御が、オペ

レーティング・システムの持つセキュリティ・ポリシーに関わらず、任意に行

われる可能性を意味する。これにより、結果として、アクセス制御を行う

主体と、実際に権限を行使する主体が同じになる。このため、We b サー

‐3‐

バーがリクエストに応えるために必要な権限の全てが、常に We b サーバ

ーには与えられている。一般的に、We b サーバーが悪意のある利用者

に乗っ取られると、危険に晒される範囲が非常に広くなる。本来であれ

ば、利用者が得るべき権限は、非常に少なくあるべきではあるが、We b

サーバーが持つ権限が、全てのアクセス可能なコンテンツから We b サー

バーの設定ファイルにまで、多岐に渡るため、従来のシステムでは被害

の範囲が広くなる傾向にあった。

セキュリティ･ポリシー・モデル

Webクライアントインターネット

アクセス制御アクセス制御

アクセス制御

OS

Webサーバー

Webサーバーにおけるリソース管理（仮想ドメイン、Webコンテンツ等）

OSにおけるリソース管理

（ファイル等）

セキュリティ･ポリシー・モデル

Webクライアントインターネット

アクセス制御アクセス制御アクセス制御アクセス制御

アクセス制御

OS

Webサーバー

Webサーバーにおけるリソース管理（仮想ドメイン、Webコンテンツ等）

OSにおけるリソース管理

（ファイル等）

図 1 - 1 We b サーバーのアクセス制御

‐4‐

1 .2 本調査の目的

インターネット環境で運用される We b サーバー・システムにおいて、オペ

レーティング・システムによる強制的アクセス制御を有効活用するために

は、オペレーティング・システムと調和的にアクセス制御を実現する We b

サーバーの実現が不可欠である。本プロジェクトは、中央省庁等で利用

されるインターネット We b サーバー・システムを想定し、オペレーティング・

システムによる強制的アクセス制御機構を有する We b サーバー・システ

ムの実現を目指す。本調査の目的は、We b サーバーに適したセキュリテ

ィ・ポリシー・モデルを明らかにすることである。

1 .3 調査方法

本調査作業は、下図に示す手順で進める。

ポリシー適応性の分析ポリシー適応性の分析

Webサーバー・システムにおけるリソース管理とアクセス制御のモデリング（要求仕様の定義）


強制的アクセス制御に関するセキュリティ・ポリシー・モデルの調査


既存Webサーバー･システム（OS, Webサーバ）の調査


調査報告書「既存Webサーバー・システムにおけるアクセス制御の調査編」

調査報告書「強制的アクセス制御に関するセキュリティ・ポリシー・モデルのWebサーバーへの適用性の調

査編」

既存の問題を分析


ポリシー適応性の分析ポリシー適応性の分析ポリシー適応性の分析ポリシー適応性の分析
















査編」


査編」



‐5‐

図 1 - 2 調査方法

本調査では、まず、リソース管理やアクセス制御に関する We b サーバ

ー・システムのモデリングを行いアクセス制御に関する要求仕様を定義

する。次に、強制的アクセス制御に関するセキュリティ・ポリシー・モデル

が We b サーバーシステム・モデルの要求仕様をどの程度満たすことがで

きるかを分析する。この分析結果は、調査報告書「強制的アクセス制御

に関するセキュリティ・ポリシー・モデルの We b サーバーへの適用性の調

査編」としてとりまとめる。

また、既存のオペレーティング・システムと既存 We b サーバーから構成さ

れる既存 We b サーバー・システムのアクセス制御機能、およびこれらのシ

ステムに対する攻撃や脆弱性に関する調査を行い、先に定義した We b

サーバー・システム・モデルと比較することで、既存システムの問題点を

抽出する。この調査結果は、調査報告書「既存 We b サーバー・システ

ムにおけるアクセス制御の調査編」としてとりまとめる。

1 .4 本調査報告書の想定される利用者

本調査報告書は、個人情報を扱う企業や電子政府等において、高い

情報セキュリティ管理が要求される部署で利用される We b サーバー・シ

ステムの導入担当者、および、これらの環境への導入をターゲットとした

We b サーバーおよびオペレーティング・システムの開発に携わる者を主な

読者に想定する。

1 .5 本報告の構成

本調査報告書の第 1 部「強制的アクセス制御に関するセキュリティ・

ポリシー・モデルの We b サーバーへの適用性の調査編」では、強制的ア

クセス制御を採用するセキュリティ・ポリシー・モデルを調査し、その We b

‐6‐

サーバーへの適用性を検証する。この検証にあたり、始めに We b サーバ

ーをモデル化すると共に、We b サーバーの脆弱性を検証する。そして、

アクセス制御の要件定義を行う。この結果を元に、既存のセキュリティ・

ポリシー・モデルの適用性を検証する。

続く第 2 部の「既存 We b サーバー・システムにおけるアクセス制御の

調査編」では、強制的アクセス制御を実現する既存 We b サーバーにお

いて、どのようなアクセス制御が行われているかを調査し、その問題点を

検証する。

本調査報告書の構成は、本章以降、次の通りである。 2 章では、

We b サーバーが、どのようにオペレーティング・システムのサービスを利用

し、利用者へのサービスを行うのか、という視点から We b サーバー・シス

テムのモデリングを行う。3 章では、We b サーバー・システムのセキュリティ

分析を行い、どのような脆弱性が起こりえるかを論ずる。4 章では、2 章と

3 章の議論を踏まえ、We b サーバー・システムに求められるアクセス制御

の要件を論ずる。5 章では、R o l e B a s e d A c c e s s C o n t r o l ( R B A C )と

Ty p e E n f o r c e m e n t ( T E )に関連した 3 つのモデルと 2 つのオペレーティ

ング・システムの計 5 種類の既存のセキュリティ・ポリシー・モデルについ

て述べる。6 章では、既存の We b サーバー・システムが、どのようなアクセ

ス制御機構を整理する。最後に、7 章で、本報告書を総じて論ずる。

‐7‐

強制的アクセス制御に関するセキュリティ

ポリシー・モデルの Web サーバーへの

適応性の調査編

‐8‐

2 Web サーバー･システムのモデリング

図 2 - 1 We b サーバー･システム

We b サーバー･システムは、We b コンテンツ管理者が作成した We b コ

ンテンツを We b サーバーが管理し、We b クライアントからの要求に応じて

We b コンテンツが We b サーバーから We b クライアントへと転送されるシス

テムである（図 2 - 1 参照）。We b サーバーでは、We b クライアントと We b

コンテンツに関するアクセス制御を行い、その設定は We b サーバー管理

者もしくは We b コンテンツ管理者によって行われる。

現在、インターネット環境や組織内のイントラネット環境において、多

くの We b サーバー･システムが構築・運用されているが、これら We b サー

バー･システムの構成や機能は、採用するソフトウェアの種類や設定によ

り様々である。本章では、We b サーバー･システムの分析にあたり、多くの

We b サーバー･システムが持つ標準的な機能および構成をモデリングす

ることにより、分析のためのリファレンス・プラットフォームを定義する。

ネットワーク

Webクライアント Webコンテンツ

Webクライアントユーザ

インターネット

Webコンテンツ管理者

Webサーバー

ネットワーク



Webサーバー


Webシステム管理者


ネットワーク





Webサーバー

ネットワーク



Webサーバー




‐9‐

本モデリングは、アクセス制御の対象となる We b コンテンツ、We b クラ

イアントや We b コンテンツ管理者等のユーザ、We b サーバーについて行

う。コンテンツのモデリングにより、本調査の対象となっているアクセス制

御機能が管理対象とするコンテンツの特徴をまとめる。ユーザのモデリン

グにより、アクセス制御におけるサブジェクトの種類とそれぞれの目的およ

びアクセスの特徴を整理する。We b サーバーのモデリングは、システム内

のモジュールを機能別に分類し、各機能がタスク遂行に必要とする権

限、モジュール間の処理フローと関係についてまとめる。

2 .1 Web コンテンツの分類

We b コンテンツは、We b サーバー･システムのアクセス制御における（ア

クセス対象）オブジェクトである。We b コンテンツの特徴を調査することに

より、アクセス制御におけるアクセスの種類と権限を定義することができ

る。

We b コンテンツは、その特徴により、静的 We b コンテンツと動的 We b

コンテンツの２種類に分類することができる。以下に、それぞれの We b コ

ンテンツの特徴、および、これらに分類される代表的な We b コンテンツに

ついて述べる。

• 静的 We b コンテンツ

静的 We b コンテンツは、コンテンツ･アクセスに際して新たなプログラム

実行を伴わないコンテンツである。We b クライアントからのリクエストに応じ

て返送される We b コンテンツの内容は、We b コンテンツ自体がコンテン

ツ管理者によって変更されない限り、常に同じである。アスキーテキスト、

X H T M L 等のドキュメントや J P E G 等の画像ファイルが、静的 We b コン

テンツに分類できる。

‐10‐

• 動的 We b コンテンツ

動的 We b コンテンツは、あらかじめコンテンツの内容が定まっておらず、

We b クライアントからのアクセス要求に応じて、動的に内容が生成される

We b コンテンツである。We b クライアントからのリクエストに引数を伴うよう

なインタラクティブな We b コンテンツ、時刻等の外部事象により変化する

内容を含む We b コンテンツ、We b サーバーを経由した外部アクセスを実

現する等の目的で動的 We b コンテンツが用いられる。C G I や S S I と呼

ばれる We b コンテンツが、動的 We b コンテンツに分類できる。コンテンツ

内容の生成方法は、動的 We b コンテンツに関連づけられたプログラムの

実行による。

2 .2 ユーザ

図 2 - 2 オペレーティング･システムアクセス制御を考慮したサブジェ

クト分類

We b サーバーにアクセスする主なユーザは、ネットワーク経由で We b コ

ンテンツへのアクセスをリクエストする We b クライアント･ユーザである。

We b クライアント･ユーザ以外に We b サーバー･システムへアクセスを行う

ユーザには、We b コンテンツを作成・管理する We b コンテンツ管理者と

システムの管理を行う We b システム管理者がいる。以下に、それぞれの

特徴をまとめる。

WebクライアントユーザWebクライアントユーザ


Webアカウントユーザ


匿名(anonymous)Webクライアントユーザ








‐11‐

2 .2 .1 We b クライアント･ユーザ

We b サーバーに対して We b コンテンツへのアクセスをリクエストするユ

ーザが We b クライアント･ユーザである。We b クライアント･ユーザは、認証

等による素性の特定の有無によって、匿名（a n o n y m o u s）We b クライア

ント･ユーザと We b アカウント･ユーザの２種類存在する。匿名 We b クライ

アント･ユーザは、ユーザの素性にかかわらず、We b サーバーにおけるリク

エスト処理が行われる。We b アカウント･ユーザは、送信したリクエスト処

理に先立って、あらかじめ We b サーバーに登録されたアカウント情報を

使って素性を特定する。

2 .2 .2 We b コンテンツ管理者

We b コンテンツ管理者は、We b コンテンツの作成および管理を担うユ

ーザである。多くの We b サーバー･システムでは、We b サーバーに対して

We b コンテンツの更新をリクエストするより、We b サーバーが稼動する計

算機上、もしくは、ファイルシステムを共有する計算機上にアカウントを

持ち、直接的もしくは F T P 等 We b サーバー以外のシステムサービスを

経由してコンテンツの更新を行う。

また、We b コンテンツ管理者は、自らが管理するコンテンツに対するア

クセス制御の設定権限を持つことができる。システム設定によっては、後

述のシステム管理者が設定したアクセス制御設定をオーバーライドする

ような設定変更の権限を与えることが可能である。

2 .2 .3 We b システム管理者

We b システム管理者は、We b サーバー･システムの管理を担うユーザ

である。上述の We b コンテンツ管理者と同様に、We b サーバーに対して

管理のためのリクエストを送信するわけではなく、We b サーバーの動作設

‐12‐

定、We b コンテンツに対するアクセス制御設定、監査ログ･ファイルの閲

覧、We b サーバーの起動・終了を行う権限を持つ。

また、We b サーバーの管理方針によっては、特定の We b コンテンツ管

理者に属さない We b コンテンツの管理を We b システム管理者が担う場

合がある。

2 .3 オペレーティング･システムとの対応

前節では、We b サーバー･システムとして場合の We b コンテンツ、We b

クライアントの分類を行った。現存の We b サーバー･システムのほとんどは、

オペレーティング･システムが稼動する計算機上に We b サーバー・ソフト

ウェアをインストールすることでシステムを構築する。オペレーティング･シス

テムは、We b サーバーを含む計算機上で稼動するソフトウェアおよび計

算機上のリソースを低レベルで管理する。本節では、We b サーバーの各

エンティティが、オペレーティング･システム上でどのプロパティにマッピン

グされ、管理されているかについて分析する。

2 .3 .1 We b コンテンツ

オペレーティング･システムにおいて、静的および動的にかかわらず、We b

コンテンツはファイルに格納され、扱われる。静的 We b コンテンツは、ひと

つのコンテンツが１ファイルと対応する。We b サーバーが受理した静的

We b コンテンツへのアクセスは、コンテンツに対応するファイルのオープン

（o p e n）と内容読み出し（ r e a d）アクセスの組み合わせで実現される。

動的 We b コンテンツは、コンテンツ内容を生成するプログラムファイル、

あるいは、プログラムファイルとデータファイルの集合と対応づけされる。

We b サーバーが受理する動的 We b コンテンツへのアクセスは、静的

We b コンテンツと同じく、コンテンツに対する「閲覧」アクセスとして扱う。し

かし、オペレーティング･システムでは、上述の「閲覧」アクセスが、プロセ

‐13‐

スの生成（ f o r k ）、プログラムファイルの実行（ e x e c）、実行したプログラム

が行うさまざまなアクセス（o p e n , r e a d , w r i t e , e x e c 等）の組み合わせ

により実現される。

図 2 - 3 We b クライアントとオペレーティング･システムにおけるアカウン

トの対応

2 .3 .2 ユーザ

We b クライアントから送信された We b コンテンツへのアクセス・リクエスト

は、We b サーバーにより処理される。オペレーティング･システムが管理す

る範囲が稼動する計算機内のみであるため、ネットワーク上に存在する

We b クライアントを意識することができない。We b クライアントから We b コ

ンテンツへのアクセスは、We b サーバーが図 2 - 3 We b クライアントとオ

ペレーティング･システムにおけるアカウントの対応 We b クライアントの代

理として We b コンテンツのファイルへアクセスするように扱われる。しかし、

Webサーバー






オペレーティングシステムユーザアカウントユーザアカウント

Webサーバーアカウント


システムアカウント

(root)


(root)

Webコンテンツ管理者Web

サーバー






オペレーティングシステムユーザアカウントユーザアカウント




(root)


(root)


‐14‐

We b クライアントの素性をオペレーティング･システムから知ることができな

いため、匿名もしくはアカウント･ユーザの種別にかかわらず、We b サーバ

ーに対して割り当てられた単一のアカウントからのアクセスに変換される。

ただし、一部の We b サーバー実装では、We b アカウント･ユーザをオペレ

ーティング･システム上のアカウントに割り当てることができる機能を持つも

のがある。この機能を持つ We b サーバーでは、We b アカウント･ユーザの

代理として、割り当てられたアカウントの権限でコンテンツ･アクセスのため

のプロセスが生成され、コンテンツ･アクセスが行われる。

We b コンテンツ管理者は、オペレーティング･システム上のアカウントに

一意的に割り当てられていることが多い。We b コンテンツ管理者が行う

We b コンテンツの更新は、オペレーティング･システムのアクセス制御にお

いて、書き込みが許可されている We b コンテンツ格納領域の一部（コン

テンツ格納ディレクトリ内のあるサブディレクトリ下など）に対してのみ実行

可能である。所有する We b コンテンツに対するアクセス制御設定は、

We b サーバーの機能の一部としてコンテンツ管理者が任意に設定可能

である。

オペレーティング･システム上では、We b クライアントのリクエスト処理以

外の目的で We b サーバーが行うリソースへのアクセスもリクエスト処理と

同様に管理される。リクエスト処理以外の We b サーバーの処理は、We b

サーバーの設定ファイルへのアクセス、監査ログの書き込み、ネットワー

ク･アクセス等が含まれる。We b サーバーは、システム･アカウント（ r o o t）も

しくは専用のアカウント等の単一アカウントを用意して動作させることが

多い。We b サーバーが行うさまざまなアクセスは、リクエスト処理やログ書

き込み等の処理内容にかかわらず、この割り当てられたアカウントの権限

で行われるものとして扱われる。

‐15‐

2 .4 Web サーバーの内部モジュール

前節で述べたとおり、We b サーバー･システムにおける We b クライアント

から We b コンテンツへのアクセス・リクエスト処理は、We b サーバー内で

処理され、オペレーティング･システム･レベルのファイル･アクセスに分解

され、実現される。本節では、We b サーバー内およびオペレーティング･

システム内の処理内容の詳細を分析することにより、各処理の詳細、お

よび、各処理モジュールが必要とする権限を明確にする。本分析結果

は、次章におけるセキュリティ分析において、脆弱箇所および危険箇所

の抽出に用いる。図 2 - 4 は、We b サーバー･システムの内部の処理を

目的別に分類した内部モジュール・モデルである。各モジュールの処理

内容を説明する。

図 2 - 4 We b サーバー･システムの内部モジュール・モデル

2 .4 .1 We b サーバーの内部モジュール

• リクエスト受信

We b クライアントからのリクエストを受信するモジュールである。従って、

WebサーバーWebサーバーリクエスト

受信

リクエスト

受信

OSOSアクセス制御機能アクセス制御機能

プログラム実行機能プログラム実行機能

リクエスト

解析

リクエスト

解析

認証認証

チェック

アクセス

チェック

アクセス

コンテンツ

アクセス

コンテンツ

アクセス

レスポンス

作成

レスポンス

作成

レスポンス

送信

レスポンス

送信

ログ記録

ログ記録

Web設定ファイル


Web設定情報Web設定情報

静的コンテンツ静的

コンテンツ動的


コンテンツ実行

プログラム実行

プログラム外部ファイルログログ

システム管理者

コンテンツ管理者

Webクライアント

ファイル・アクセス機能

セッション情報

ネットワーク・アクセス機能


受信

リクエスト

受信



リクエスト

解析

リクエスト

解析

認証認証

チェック

アクセス

チェック

アクセス

コンテンツ

アクセス

コンテンツ

アクセス

レスポンス

作成

レスポンス

作成

レスポンス

送信

レスポンス

送信

ログ記録

ログ記録




静的コンテンツ静的



コンテンツ実行


プログラム外部ファイルログログ




ファイル・アクセス機能


ネットワーク・アクセス機能

‐16‐

ネットワークからの T C P コネクション要求を待ちうけ、接続要求があっ

た場合に受理してコネクションを確立する権限を必要とする。加えて、

確立したコネクションから送られてきたリクエストを読む権限を必要とす

る。

• リクエスト解析

リクエスト受信モジュールが受信したリクエストデータを解析して、ア

クセスの種類（メソッド）およびアクセスの対象（コンテンツ）を特定する

モジュールである。認証情報が付与されていたる場合には、認証モ

ジュールにデータ認証情報を渡す。このモジュールは、メモリ内上で

のみの作業で、ネットワーク･アクセスやファイル･アクセスなどの権限を

必要としない。

• 認証

このモジュールの目的は、We b コンテンツにアクセスをしようと試み

ている We b クライアントを特定することである。リクエスト解析モジュー

ルが特定した認証情報を基に正規のユーザであるか否かを判断す

る。

メソッドとコンテンツに対して認証が必要かどうかを We b 設定情報

から読み出し、決定するモジュールである。また、リクエスト解析モジュ

ールより渡された解析結果に認証情報が含まれている場合は、認証

情報を利用しの確認を行い We b クライアントの素性を特定をする。

なお、認証が必要ないと判断した場合は、匿名ユーザとして、特定さ

れる。本モジュールが処理遂行に必要とする権限は、We b 設定情

報へのアクセス権限である。

• アクセス･チェック

リクエスト解析モジュールが特定したメソッドとコンテンツ、および認

‐17‐

証モジュールが特定したユーザに従い、アクセスが不許可になってい

ないかを確認するモジュールである。認証が必要と判断された場合

には、コンテンツ･アクセスのモジュールをスキップして、認証情報を求

めるレスポンスを後述するレスポンス作成すモジュールで作成する。

We b 設定情報を読み出すことで、指定されたコンテンツに対して、指

定されたメソッドが許可されるか否かを決定する。本モジュールが処

理遂行に必要とする権限は、We b 設定情報に含まれるアクセス制

御情報へのアクセス権限である。

• コンテンツ･アクセス

リクエスト解析モジュールによりが特定したメソッドとコンテンツに従

い、実際にコンテンツにアクセスするモジュールである。適切なオペレ

ーティング･システムオペレーティング･システムのアクセス命令（システ

ムコール）を呼び出し、コンテンツにメソッドを実行アクセスする。コンテ

ンツがファイルに格納されている場合は、ファイル･アクセスの権限を

行使する必要がある。

• レスポンス作成

レスポンス作成モジュールは、コンテンツ･アクセス・モジュールの取

得したコンテンツを受け取り、H T T P の仕様にしたがって整形し、レス

ポンスを作成する。このモジュールは、メモリ内でのみの作業で、ネット

ワーク･アクセスやファイル･アクセスの権限を必要としない。

• レスポンス送信

レスポンス作成モジュールが作成した We b クライアントからのリクエ

ストに対するレスポンスを返送する。レスポンス作成モジュールは、リク

エスト受信モジュールが確立したコネクションに対して、レスポンス作

成モジュールが生成したレスポンスを送信する。確立されたコネクショ

‐18‐

ンに対するネットワーク･アクセス送信権限が必要となる。

‐19‐

• ログ記録

レスポンス作成モジュールが作成したレスポンスの内容からログ情

報を作成して、ログ･ファイルに記録する。このモジュールは、ログ･ファ

イルへの書き込みを行うため、ファイル･アクセス権限を必要とする。

• We b 設定情報

We b サーバーの動作、および、We b サーバーにおけるアクセス制御

の振る舞いを決定する認証情報やアクセス制御設定情報を含む。ア

クセス制御設定の項目および方法は、We b サーバーの実装により異

なるが、ほとんどすべての We b サーバーにおいて、We b コンテンツ全体

に対するデフォルト設定および、サブコンテンツ領域毎のアクセス制御

を設定できる。既存 We b サーバー・ソフトウェアのデフォルトのアクセス

制御設定は、すべての We b クライアントに対して閲覧を許可する

a l l - a l l o w a n c e 原則に基づいていることが多い。

本設定情報は、We b サーバー内の認証モジュールおよびアクセス･

チェック･モジュールから必要に応じてアクセスされる。

2 .4 .2 We b サーバーが利用するオペレーティング･システムの機能

前述のように内部モジュールがモデル化される We b サーバーは、オペ

レーティング･システム上で動作する 1 アプリケーションである。そのため、

We b サーバーがサービスを提供するためには、オペレーティング･システム

の機能を利用する。ここで We b サーバーが必要とするオペレーティング･

システムの機能は、アクセス制御機能、プログラム実行機能、ファイル･ア

クセス機能、ネットワーク･アクセス機能の 4 つである。以下に、それぞれ

の機能と各機能を利用する We b サーバー内のモジュールについて整理

する。

‐20‐

• アクセス制御機能

オペレーティング･システムにおけるアクセスをチェックするオペレーテ

ィング･システム機能である。ファイルやネットワーク等のリソースに対す

るすべてのアクセスは、本機能によりチェックされる。絶対権限を持つ

システム･アカウント（ r o o t）によるアクセスに対しては、本機能によるアク

セス･チェックが無効化される。

• プログラム実行機能

プロセスを生成して、プログラムファイルからコードを読み出し、実行

するオペレーティング･システム機能である。We b サーバーの動作や、リ

クエスト処理に応じて必要となる処理プロセスの生成には、本機能が

用いられる。動的 We b コンテンツは、本機能により実行されたプログラ

ムにより内容が生成される。

• ファイル･アクセス機能

ファイルにアクセスするオペレーティング･システム機能である。We b コ

ンテンツに対するアクセスは、本ファイル･アクセス機能により、コンテン

ツを保存するファイルを読み出すことにより実現される。また、We b サー

バーのシステム処理としての、設定情報の読み出しや監査ログへの書

き込みも、本機能を用いる。

• ネットワーク･アクセス機能

ネットワークにアクセスするためのオペレーティング･システム機能であ

る。We b サーバー内のリクエスト受信モジュールによる We b クライアント

からの接続要求待ちと We b コンテンツに対するアクセス・リクエスト受

信、レスポンス返信モジュールによるレスポンス返信に本機能が用いら

れる。

‐21‐

We b サーバーの各モジュールに必要なオペレーティング･システム機

能をまとめると、以下のようになる。

モジュー

ル

機能ファイル･

アクセス

権限

ネットワ

ーク･アク

セス機能

プログラ

ム実行

機能

アクセス

制御機能

リクエスト

受信

リクエスト

の受付

○

リクエスト

解析

リクエストメ

ッセージの

構文解析

認証認証情報

に基づく

We b クライ

アントの認

証

○ （アカウ

ント情報

の読み出

し）

アクセス･

チェック

We b コン

テンツに

対するアク

セス権確

認

○ （アクセ

ス制御設

定の読み

出し）

コンテン

ツ･アクセ

ス

We b コン

テンツへの

アクセス

○ ○ （動的

We b コン

テンツの

実行）

○

‐22‐

表 2 - 1 We b サーバーの各モジュールが必要なオペレーティング･シス

テム機能

2 .5 Web サーバー内の処理フロー

前節の内部モデルを使って、コンテンツ･アクセス・リクエストの処理フロ

ーをモデル化する。We b サーバー･システムにおける処理は、We b サーバ

ーの設定、および We b コンテンツへのアクセス・サービスの 2 種類に分類

することができる。

We b コンテンツへのアクセスは、更に次の様に分類できる :

• 基本アクセス

• 認証アクセス

• セッションアクセス

以下、ここではそれぞれのフローがどのように発生し、We b サーバーと

オペレーティング･システムのアクセス制御機構が、どのように連携するか

について述べる。

レスポンス

作成

レスポンス

メッセージ

の作成

レスポンス

送信

レスポンス

メッセージ

の送信

○

ログ記録リクエスト

処理の記

録

○

‐23‐

2 . 5 . 1 . 1 設定時における処理フロー

図 2 - 5 設定時における処理フロー

We b サーバーの設定時における処理の流れは図 2 - 5 のようになる。

システム管理者は、We b 設定ファイルを編集して、We b の認証情報や

アクセス管理等を設定する。コンテンツ管理者は、静的もしくは動的コン

テンツや関連ファイルを更新する。また、コンテンツ管理者も、所有する

We b コンテンツに対するアクセス制御設定を行うことができる。これらの

設定は、We b サーバー稼動前に行うため、オペレーティング･システムの

アクセス制御下でのみ設定権限を管理する。

OS

アクセス制御機能アクセス制御機能

プログラム実行機能プログラム実行機能ファイル・アクセス機能ネットワーク・アクセス機能


受信

リクエスト

受信

リクエスト

解析

リクエスト

解析

認証認証

チェック

アクセス

チェック

アクセス

コンテンツ

アクセス

コンテンツ

アクセス

レスポンス

作成

レスポンス

作成

レスポンス

送信

レスポンス

送信

ログ記録

ログ記録




静的静的コンテンツ

動的コンテンツ


実行プログラム


外部ファイル

ログログ






ネットワーク・アクセスファイル・アクセスプログラム実行


外部ファイル

OS


プログラム実行機能プログラム実行機能ファイル・アクセス機能ネットワーク・アクセス機能


受信

リクエスト

受信

リクエスト

解析

リクエスト

解析

認証認証

チェック

アクセス

チェック

アクセス

コンテンツ

アクセス

コンテンツ

アクセス

レスポンス

作成

レスポンス

作成

レスポンス

送信

レスポンス

送信

ログ記録

ログ記録




静的静的コンテンツ





外部ファイル

ログログ








外部ファイル

‐24‐

2 . 5 . 1 . 2 基本サービス時の処理フロー

図 2 - 6 基本サービス・フロー・モデル

サービス時における処理は、We b コンテンツのアクセス管理設定によ

って、 2 つのフローモデルに分類できる。基本モデルは、最も一般的な

We b サーバー･システムのサービス・フロー・モデルである（図 2 - 6 参照）。

We b クライアントからのリクエストは、We b サーバー内のリクエスト解析モ

ジュールで解析され、アクセス･チェック･モジュールによりアクセスの許可

／不許可が判定される。アクセス許可された後、コンテンツ･アクセス・モ

ジュールによりオペレーティング･システムに対して We b コンテンツへのア

クセスが要求される。

この後のフローは、アクセス対象が静的コンテンツか、動的コンテンツ

かにより異なる。アクセス対象が静的コンテンツの場合、オペレーティン

グ･システムのアクセス制御機能により、対象とする静的コンテンツが格

納されたファイルに対する読み込む権限があるか否かが確認される。こ

のアクセス制御の際のサブジェクトは、We b サーバーである。ファイル･ア

クセスが許可されると、オペレーティング･システムのファイル･アクセス機


受信

リクエスト

受信

OSOS



リクエスト

解析

リクエスト

解析

チェック

アクセス

チェック

アクセス

コンテンツ

アクセス

コンテンツ

アクセス

レスポンス

作成

レスポンス

作成

レスポンス

送信

レスポンス

送信

ログ記録

ログ記録

設定Web設定ファイル


静的コンテンツ





外部ファイルログログ




ネットワーク・アクセスファイル・アクセス




ファイル・アクセス機能ネットワーク・アクセス機能


受信

リクエスト

受信

OSOS



リクエスト

解析

リクエスト

解析

チェック

アクセス

チェック

アクセス

コンテンツ

アクセス

コンテンツ

アクセス

レスポンス

作成

レスポンス

作成

レスポンス

送信

レスポンス

送信

ログ記録

ログ記録

















‐25‐

能を使い、We b コンテンツであるファイルの取得を行い、レスポンス作成

モジュール、およびレスポンス送信モジュールを通り、We b クライアントに

レスポンスが返される。

一方で、動的コンテンツの場合、アクセス対象である動的コンテンツに

対する実行権限を持つかどうかが、オペレーティング･システムのアクセス

制御機能によって検査される。このアクセス制御の際のサブジェクトは、

静的コンテンツの場合同様に We b サーバーとなる。動的コンテンツが実

行されると、さらに実行プログラムを起動したり、外部ファイルへアクセスし

たりする場合がある。これらのプログラム実行やファイル･アクセスも、すべ

てオペレーティング･システムのアクセス制御機能によるアクセス制御され

る。なお、このアクセス制御の際のサブジェクトは、実行プログラムが

s e t u i d 等により明示的にサブジェクト変更が指定されていない限り、

We b サーバーと同じである。

2 . 5 . 1 . 3 認証サービス時の処理フロー

図 2 - 7 認証サービス・フロー・モデル


受信

リクエスト

受信

OSOS



チェック

アクセス

チェック

アクセス

コンテンツ

アクセス

コンテンツ

アクセス

レスポンス

作成

レスポンス

作成

レスポンス

送信

レスポンス

送信

ログ記録

ログ記録








外部ファイル

ログログ




ネットワーク・アクセス

ファイル・アクセス






リクエスト

解析

認証


受信

リクエスト

受信

OSOS



チェック

アクセス

チェック

アクセス

コンテンツ

アクセス

コンテンツ

アクセス

レスポンス

作成

レスポンス

作成

レスポンス

送信

レスポンス

送信

ログ記録

ログ記録








外部ファイル

ログログ











リクエスト

解析

認証

‐26‐

We b コンテンツへのアクセスが、特定のユーザもしくはユーザ集合に対

してのみ許可される場合には、アクセス･チェック時のサブジェクトを変更

する必要がある。このような場合、どのユーザが、We b コンテンツへのアク

セスを試みているか、認証する必要がある。図 2 - 7 は、認証を必要とす

る場合の、処理フローを示したものである。We b サーバー内でのアクセ

ス･チェックに先立ち、認証モジュールは、We b クライアントのリクエストに

添付された認証情報の確認を行い、We b クライアントの素性を特定する。

その結果、We b サーバーでのアクセス･チェック･モジュールにおけるサブ

ジェクトは、認証された We b クライアントとなる。そうして、アクセスが許可

された場合に、コンテンツ･アクセス・モジュールにより、オペレーティング･

システムの機能を用いて、We b コンテンツへのアクセスが実行される。

オペレーティング･システムのアクセス制御機能におけるアクセス制御

では、We b サーバーの実装方法により、サブジェクトが異なる。We b サー

バーが認証するユーザが、オペレーティング･システムとは独立して、We b

サーバーにより管理されている場合、オペレーティング･システムのアクセ

ス制御機能では、We b サーバーが認証した結果を利用することが出来

ない。つまり、オペレーティング･システムのアクセス制御機能におけるアク

セス制御のサブジェクトは、基本モデルの場合と同様に、We b サーバー

となる。一方で、We b サーバーの認証するユーザが、オペレーティング･シ

ステムにより管理されている場合、オペレーティング･システムのアクセス

制御機能におけるアクセス制御のサブジェクトは、We b サーバーが認証

したユーザとなる。

‐27‐

2 . 5 . 1 . 4 セッション・サービス時の処理フロー

図 2 - 8 セッション・サービス・フロー・モデル

We b コンテンツのアクセス制御がセッションに基づいて行われる場合

には、一部のアクセス･チェックが前述とは異なる基準で行われる（図

2 - 8 参照）。We b サーバーの処理モデルがセッションレスであるため、

We b サーバー･システムでセッションを実現する場合は、動的コンテンツ

内でセッションを実現する方法が用いられる。セッション管理は動的コン

テンツで行われるため、We b サーバーのアクセス･チェック、および、動的

コンテンツ･アクセス時のオペレーティング･システムアクセス制御機能によ

るアクセス･チェックでは、セッションが考慮されない。動的コンテンツ内で

は、送られてきたセッション情報を認証して、動的コンテンツの振る舞い

を自ら制御する。


受信

リクエスト

受信

OSOS



チェック

アクセス

チェック

アクセス

コンテンツ

アクセス

コンテンツ

アクセス

レスポンス

作成

レスポンス

作成

レスポンス

送信

レスポンス

送信

ログ記録

ログ記録








外部ファイル

ログログ









リクエスト

解析



受信

リクエスト

受信

OSOS



チェック

アクセス

チェック

アクセス

コンテンツ

アクセス

コンテンツ

アクセス

レスポンス

作成

レスポンス

作成

レスポンス

送信

レスポンス

送信

ログ記録

ログ記録








外部ファイル

ログログ









リクエスト

解析


‐28‐

3 Web サーバー･システムの脆弱性分析

本章では、We b サーバー・システムにおいてリスクに晒される可能性の

ある対象とその脆弱性を検証する。これによって、最初に We b サーバ

ー・システムにおいて守るべき対象とその性質を明確にする。続いて、そ

れらの対象が持つ脆弱性を基に、どのような攻撃が考えられるのかを検

討する。この目的は、攻撃の種類による対処方法を検討することである。

ここで重要なことは、具体的な攻撃手段に対する対策を個別に講じる

対処療法的な対応を検討することではない。特に、We b サーバーに焦

点をあて、攻撃手段が本質的に We b サーバーのどのような脆弱性を利

用した攻撃なのかを理解した上で、We b サーバーの弱点を無くす方法

も視野に入れた対処方法を検討することである。

We b サーバーの提供するサービスは多種多様であり、利用環境も多

種多様である。サービス内容や利用環境によっては、無視しうる脆弱性

もある。しかし、We b サーバーの持つ脆弱性は、今日、一般的に実装さ

れている We b サーバーの実装方法や、仕様に拠るものも少なくない。こ

こでは、そのような本質的な脆弱性に対する対処方法を検討する。

3 .1 脅威の対象

図 3 - 1 は、We b サーバー・システムにおける脅威の対象となる点を図

示したものである。We b サーバー・システムにおいて、脅威の対象となる

要点は大きく分けて、次の 4 つである :

• コンテンツ

We b サーバーが提供するデータである。

• ネットワークを流れるデータ

We b サーバーと We b クライアント間の通信内容である。

‐29‐

• We b サーバー

We b クライアントの要求に応じて、We b サーバー・システムを提供する

主体である。

• We b クライアント

利用者が操作し、We b サーバーに対して、コンテンツの要求を行う

主体である。

本節では、 3 . 2 . 1 節において攻撃の種類を検証するに辺り、We b サ

ーバー・システムのそれぞれの構成要素がどのような性質を持ち、どのよ

うな脆弱性があるのかを検証する。

ネットワークネットワーク

ネットワークを流れるコンテンツやパスワードなど

Webサーバーのリソース

コンテンツWebクライアント Webサーバー

Webクライアントのリソース

図 3 - 1 We b サーバー・システムにおける脅威の対象

3 .1 .1 コンテンツ

コンテンツは、We b サーバーが提供する情報を示す。コンテンツ管理

者によって作成され、We b クライアントの要求に応じて、We b サーバーに

よって配信される。

コンテンツには、静的コンテンツと動的コンテンツがある。静的コンテン

ツは、コンテンツ管理者が作成した時点で内容が固定され、We b クライ

アントから要求されると、常に同じ内容が We b サーバーによって返される。

‐30‐

通常の X H T M L のみで記述されたコンテンツが、これにあたる。一方で、

動的コンテンツは、コンテンツ管理者が作成した時点では内容が固定さ

れず、We b クライアントからの要求に応じて、内容が変化する性質を持

つ。通常、動的コンテンツでは、We b クライアントから与えられた情報を

基にコンテンツが自動生成される。P H P や P e r l などのスクリプト言語に

よって記述されたコンテンツが、これにあたる。

いずれのコンテンツであっても、コンテンツ管理者の想定した利用者に

対して、コンテンツ管理者が作成した内容で提供されなければならない。

コンテンツ管理者は、作成したコンテンツがオリジナルのまま、自身の意

図とは異なる内容に改変されずにコンテンツ管理者が認める利用者に

配信されることを期待する。したがって、コンテンツが、コンテンツ管理者

の意図しない形に改竄されることや、コンテンツ管理者の意図しない利

用者に取得されることを避けなければならない。改竄には、静的コンテン

ツの内容を改変する場合から、動的コンテンツが本来想定していない動

作をさせ、コンテンツ管理者が意図しなかった内容を返してしまう場合ま

でが想定される。後者の例として、動的コンテンツの実装上のミスから、

想定外の入力が動的コンテンツに与えられることで、本来の意図とは異

なる動作をし、We b サーバー上に蓄えられた個人情報などを取得された、

という事例がある。

3 .1 .2 ネットワークを流れるデータ

We b サーバー・システムは、ネットワークを介して、We b クライアントと

We b サーバーが通信を行うことで成立する。従って、この過程では、

様々な情報がネットワーク上を流れるため、漏洩や改竄のリスクを負う。

ネットワーク上を流れる情報で、重要なものが 2 つある。1 つは、We b サ

ーバーが利用者を特定するための認証情報である。そして、 2 つめは、

We b サーバーによって提供されるコンテンツである。これらの情報は、第

‐31‐

3 者に漏れることや、改竄されることが避けられなければならない。

まず、漏洩の問題について、認証情報とコンテンツについて検証する。

認証情報は、We b サーバーが利用者を特定する唯一の手段である。

認証情報には、We b サーバー・システムを利用するためのユーザ・アカウ

ントとパスワードの他、認証完了後に We b サーバーが、認証済みの

We b クライアントを識別するために発行するセッション識別子も含まれる。

認証は、ある利用者と We b サーバーのみが知っている情報 (鍵 )があると

仮定し、その 2 者のみが知る情報を照合することによって成立する。その

利用者と We b サーバー以外の第 3 者に鍵を知られた場合であっても、

We b サーバーは、正規の利用者のみが鍵を知っていると仮定するため、

正規の利用者と偽の利用者の識別ができない。そのため、このような情

報が漏洩することは避けなければならない。

コンテンツは、コンテンツ管理者が想定する利用者にのみ提供される

べき性質のものである。例えば、企業や自治体などで、個人情報などの

取り扱いに注意が必要なコンテンツや、その組織の機密情報にあたるコ

ンテンツを閲覧できる We b サーバー・システムにおいては、第 3 者にコン

テンツの内容が漏れることを避けなければならない。一方、企業や自治

体が一般向けの広報に使用する We b サーバー・システムにおけるコンテ

ンツは、万人向けの内容であるため、一般論として情報の機密性が無く、

内容自体は、利用者以外の第 3 者に知られても問題が無い。しかし、

どの利用者が、どのようなコンテンツを利用しているかは、プライバシーの

問題であり、個人情報にあたるものである。従って、どの利用者が、どの

ようなコンテンツを要求しているかは、第 3 者に知られても良い内容では

ない。

また、改竄の問題であるが、通信が暗号化されていない環境では、通

信の相手が、本当に自分が通信しようとしている相手か、保証できない

場合がある。暗号化や署名されていないデータは、容易に偽造が出来

る。これを利用し、利用者が要求したコンテンツを改竄することで、偽の

‐32‐

情報を利用者に渡すことや、利用者が望まないコンテンツに改変するこ

とが可能となる。しかし、S S L などで暗号化を行っている場合でも、正し

く設定されていない場合には、M a n - I n - T h e - M i d d l e 攻撃に代表され

るような方法などで、ユーザ名やパスワードなどの認証情報漏洩や改竄

が容易に発生しうる。また、通信時のソース I P アドレスを偽造し、通信

相手を誤認させることで、同様の漏洩や改竄が行われる場合もありうる。

3 .1 .3 We b サーバー

We b サーバーは、ネットワーク上に配され、想定される利用者に応じて

決められたネットワークの範囲内からであれば、通常、どこからでもアクセ

スができる。We b クライアントを限定できない場合は、インターネット上の

あらゆる場所から、アクセスができるようになる。利用者にとって、このこと

は多くの利便性をもたらすが、同時に、悪意のある者に対しても、多くの

利便性を与える。

一般的に、We b サーバーは、汎用のオペレーティング・システム上で動

作するプログラムの 1 つとして運用される。多くの場合、 L i n u x や

S o l a r i s などの U N I X 系オペレーティング・システムや Wi n d o w s オペレ

ーティング・システム上で運用される。汎用のオペレーティング・システム

であるため、We b サーバー以外のプログラムを実行することも可能になっ

ており、場合によっては、We b サーバー以外に、メール・サーバーなどの

プログラムも多数動作していることがある。つまり、We b サーバーには、大

きく分けて 3 つの脅威の対象が考えられる。We b サーバー・システム自

体、We b サーバーのリソース、そして、We b サーバー・システム以外のリソ

ースである。ここでリソースとは、We b コンテンツ、プログラム・ファイルおよ

び設定ファイルなどのファイル、および、メモリなどのオペレーティング・シ

ステムが管理する資源を意味するものである。

このような環境においては、We b サーバーの動作するシステム上のあら

‐33‐

ゆるプログラムが、脅威の対象となる。しかし、We b サーバーは、システム

管理者が We b サーバー・システムを提供するために運用するものである。

従って、システム管理者の意図しない形で We b サーバーが利用されるこ

とや、We b サーバーのサービス自体が停止することは避けなければならな

い。そのためには、We b サーバーが動作する計算機上のオペレーティン

グ・システムを含む、あらゆるプログラムの脆弱性について考慮する必要

がある。

3 .1 .4 We b クライアント

We b クライアントは、ネットワークを利用して、We b サーバーに対してコ

ンテンツを要求し、得られたコンテンツを表示する。We b クライアント自体

の脆弱性は、We b サーバーの保護という観点からは影響しないが、We b

サーバー・システムというエコシステムにおける重要な役割を担う We b クラ

イアントも、守られなければならない対象である。

We b クライアントは、通常、Wi n d o w s などのオペレーティング・システム

上で動作する We b ブラウザ・アプリケーションとして実現される。悪意の

ある者は、仕掛けを施した We b サーバーを用いて、We b クライアント上で

任意のプログラムが実行することがある。例えば、利便性のために

A c t i v e X のような We b サーバーよりダウンロードしたプログラムを We b ク

ライアント上で実行する仕組みを利用すると、悪意のある者により、想定

していないプログラムが実行されることがある。

利用者は、コンテンツ管理者の提供するコンテンツを安心して閲覧す

ることのみを期待する。つまり、We b サーバーが提供するコンテンツの信

頼性や安全性が保証されることを、利用者は期待する。

‐34‐

3 .2 Web サーバーに対する攻撃手段の分析

3 . 1 節において、We b サーバー・システムには、どのような脆弱性が潜

みうるのかを検証した。本節では、その検証に基づき、特に We b サーバ

ーにおける脅威の対象の脆弱性に対して、悪意を持つ者によって、どの

ような攻撃が考えられるかを検証する。ここでは、攻撃の種類を検証する

上で、2 章で紹介した We b サーバーのモデルを利用する。We b サーバ

ーのモデルを活用することで、We b サーバーの、どの部分に脆弱性が具

体的に潜むのかを分析する。

3 .2 .1 攻撃の種類

We b サーバーに対する攻撃は、大きく分けて 2 種類に分類される。攻

撃を積極的に仕掛けるアクティブ攻撃と、仕掛けを施しておいて、その

仕掛けに引っかかるのを待つパッシブ攻撃である。

アクティブ攻撃には、大きく分けて侵入攻撃と

D e n i a l - o f - S e r v i c e ( D o S )攻撃の 2 種類がある。侵入攻撃とは、We b

サーバーに侵入し、コンテンツやＷe b サーバーの様々なリソースに対して

不正にアクセスを行う攻撃である。D o S 攻撃とは、We b サーバーを機能

不全の状態にし、サービスを継続できなくする攻撃である。侵入攻撃に

は、次のような種類がある :

• なりすまし

• ソフトウェアのバグの利用

• 設定ミスの利用

• 仕様上の問題を利用

• バックドアの利用

‐35‐

また、D o S 攻撃には、次のような種類がある :

• ソフトウェアのバグの利用

• 過負荷

最後に、パッシブ攻撃には、次のような攻撃がある :

• クロスサイト・スクリプティング

• 盗聴

3 .2 .2 なりすまし

なりすましとは、正規の利用者になりすまして、不正にサービスを利用

する攻撃である。この攻撃は、認証の仕組みが単純であればあるほど行

いやすい。We b サーバーから見たとき、なりすましによる侵入は、正規の

アクセスに見えるため、防御が困難であるという特徴を持つ。

なりすましには、2 種類の攻撃が考えられる。1 つは、正規のユーザ名

とパスワードを利用し、不正アクセスを行う方法である。悪意のある者は、

ユーザ名とパスワードを様々な方法によって入手し利用する。例えば、

H T T P の B a s i c 認証を使う場合、基本的にパスワードは B a s e 6 4 符号

化されるが、暗号化されていないため、元のユーザ名とパスワードを容易

に取り出すことが出来る。そのため、H T T P のやり取りを盗聴されると、容

易にユーザ名とパスワードが入手される。これ以外にも、容易に推測され

るユーザ名やパスワードを利用している場合、辞書や推論によってユー

ザ名やパスワードの組み合わせを試され、解析されるブルート・フォース

攻撃と呼ばれる方法もある。

もう一つのなりすましによる攻撃は、We b サーバーから返されるクッキー

に埋め込まれたセッション情報を不正利用する方法である。H T T P は、

基本的に 1 つの H T T P リクエストに対して、1 つの H T T P レスポンスで

成立するセッションレスのプロトコルである。しかし、実際の We b サーバー

‐36‐

を利用した We b アプリケーションでは、複数のこうしたやり取りを組み合

わせてセッション指向のサービスを提供することが多い。そのため、We b

サーバーは、We b クライアントと、そのセッションを識別するため、セッショ

ン識別子を生成し、We b クライアントにクッキーや U R I に埋め込んだ形

式で渡す。そうして、We b クライアントが We b サーバーに対してリクエスト

を送信するたびに、セッション識別子を送ることを要求する。悪意あるも

のは、このセッション識別子を入手することで、セッションを確立した We b

クライアントになりすまし、We b サーバーに不正アクセする。セッション識

別子の生成方法が単純であればあるほど、このなりすましを見抜ける可

能性が低くなる。

なりすましは、パッシブ攻撃の盗聴と組み合わせて行われることが多い。

盗聴によって入手した情報を利用し、なりすましによる攻撃が仕掛けら

れる。

図 3 - 2 と図 3 - 3 は、なりますしによる攻撃が対象とする We b サーバ

ーの脆弱部分を図示したものである。図中の星印が付けられた部分が、

この攻撃が狙う脆弱部分である。正規のユーザ名とパスワードを利用し

たなりすましの場合、利用者である We b クライアントの使用するユーザ名

やパスワードが容易に推測可能なものであることが考えられる (図 3 - 2 )。

利用者が簡単なユーザ名やパスワードを選択した場合、この部分は非

常に脆弱となる。結果として、We b サーバーの認証モジュールが騙され、

正規利用者が利用していると誤認するようになる。

‐37‐

WebサーバWebサーバリクエスト

受信

リクエスト

受信



リクエスト

解析

リクエスト

解析

認証認証

チェック

アクセス

チェック

アクセス

コンテンツ

アクセス

コンテンツ

アクセス

レスポンス

作成

レスポンス

作成

レスポンス

送信

レスポンス

送信

ログ記録

ログ記録










外部ファイル





ファイル・アクセス機能ファイル・アクセス機能





図 3 - 2 なりすまし：ユーザ名とパスワードの利用

セッション情報を横取りしたなりすましの場合、セッション情報が正規の

利用者によって使用されているか否かを判断するロジックが単純であれ

ばあるだけ、不正アクセスに利用される可能性が高くなる。この場合、動

的コンテンツが利用するセッション情報が脆弱部分となる (図 3 - 3 )。


受信

リクエスト

受信



リクエスト

解析

リクエスト

解析

認証認証

チェック

アクセス

チェック

アクセス

コンテンツ

アクセス

コンテンツ

アクセス

レスポンス

作成

レスポンス

作成

レスポンス

送信

レスポンス

送信

ログ記録

ログ記録










外部ファイル










図 3 - 3 なりすまし：セッション情報の利用

‐38‐

3 .2 .3 バグの利用

We b サーバーは、様々なソフトウェアを組み合わせて実現・運用される。

そのため、ソフトウェアにバグが含まれる可能性は、決してゼロにはならな

い。We b サーバーを含め、あらゆるソフトウェアには、必ずバグが潜む可

能性があり、バグが存在する可能性を前提とする必要がある。

バグを利用した攻撃の代表的なものには、バッファ・オーバフロー攻撃

やストリング・フォーマット攻撃がある。バッファ・オーバフロー攻撃は、プロ

グラムが使用するメモリ上のバッファに、プログラムが想定した以上のデー

タを入力することで、設計意図と異なる動作をプログラムにさせる攻撃で

ある。プログラムのバグを利用した攻撃としては、最も良く使われる攻撃

方法である。We b サーバーのようなシステム開発に良く使用されるプログ

ラミング言語 ( C 言語など )では、静的に確保された配列に対して、確保

した以上のサイズのデータを配列などに代入することができる。また、プロ

グラミング言語として、バッファ・オーバフローを検知する仕組みを持たな

いため、プログラマの責任で確認を行うことが求められている。そのため、

バッファ・オーバフロー攻撃の原因となる脆弱部分が出来やすい。

ストリング・フォーマット攻撃は、C 言語の標準関数 p r i n t f ( )に対して、

本来静的な文字列を渡すストリング・フォーマットに、動的に入力された

データを渡してしまうバグを利用する攻撃である。この場合、関数

p r i n t f ( )に渡ると予想される入力データに、p r i n t f ( )が解釈するストリン

グ・フォーマットを基にした悪意のあるコードを渡すことで、バッファ・オー

バフロー攻撃と同じ効果を得ることが可能となる。

利用者がフォームに入力した値を元に S Q L 文を発行しデータベース

から結果を取得し、レスポンスを返す動的コンテンツでは、利用者が入

力した値に S Q L 文が含まれると、それによって任意の S Q L 文を実行さ

れる可能性がある。この脆弱性は、入力値に想定外の文字列が入って

いないことを確認していない場合に発生する。

‐39‐

いずれの攻撃も、基本的には、プログラマが安易に「これ以上のサイズ

の入力データは来ないはず」や「このような入力データは来ないはず」とい

う想定の元に、例外を考慮せずに実装していることが原因である。

この脆弱性が潜む可能性がある部分は多岐に渡る (図 3 - 4 )。この脆

弱性は、全てのプログラムに潜む可能性があるため、全ての実行可能な

プログラム (図中の We b サーバー、O S、実行プログラム、および、動的コ

ンテンツ )が脆弱部分となりうる。


受信

リクエスト

受信



リクエスト

解析

リクエスト

解析

認証認証

チェック

アクセス

チェック

アクセス

コンテンツ

アクセス

コンテンツ

アクセス

レスポンス

作成

レスポンス

作成

レスポンス

送信

レスポンス

送信

ログ記録

ログ記録










外部ファイル










図 3 - 4 バグの利用

3 .2 .4 設定ミスの利用

システム管理者やコンテンツ管理者は、We b サーバーの挙動を設定

ファイルに定義することで、目的に応じた We b サーバーのサービス内容

を設定する。しかし、この設定に間違いがあると、その設定ミスをついた

攻撃の対象となる可能性がある。

例えば、特定のユーザやネットワークの範囲外からのアクセスを許可し

‐40‐

ない設定をしている場合を考える。この時、入力ミスにより、ユーザ名や

ネットワークの範囲指定を誤ると、本来の想定外の利用者にアクセスを

許す可能性がある。具体的には、社外と社内向けのコンテンツを同じ

We b サーバー上で公開しているとする。この時、社内向けのコンテンツは、

社内のイントラネットからのアクセスのみを許可するために、社内 L A N の

I P アドレス範囲からのみアクセスできるように設定したとする。この設定は、

システム管理者およびコンテンツ管理者によって行われる。しかし、この

範囲指定に誤りがあると、場合によっては、社内向けのコンテンツが社

外からもアクセスできる可能性がある。これにより、設定ミスによって、不

正アクセスが引き起こされる。

通常、We b サーバーを導入すると、最初にデフォルトの We b サーバー

設定ファイルが用意される。We b サーバー設定ファイルは、We b サーバ

ーの動作確認を行うため、一般的な設定項目が予め記述されている

(デフォルトの We b サーバー設定ファイル )。しかし、一部のデフォルトの

We b サーバー設定ファイルには、不必要な設定が記載されているため

に、システム管理者らの気がつかないうちに脆弱性を持つ場合がある。

古い A p a c h e や N C S A h t t p d では、p h f と呼ばれるサンプルの C G I ス

クリプトが自動的に C G I スクリプトとしてインストールされ、かつ、C G I スク

リプトが使える設定がデフォルトで行われる。この p h f を使用することで、

任意のコマンドを We b サーバー上で実行できるという脆弱性ができ、パ

スワード・ファイルを盗まれるなどの攻撃を受ける結果となった。

基本的に、設定ミスの脆弱性は、We b サーバーの設定を行うシステム

管理者やコンテンツ管理者によって引き起こされる (図 3 - 5 )。We b サー

バーを導入し、サービスを開始する際に使用する初期の We b サーバー

設定ファイルのチェックが不十分である場合や、設定変更後の確認が

不十分な場合に、意図しない設定がされる可能性が高い。通常、We b

サーバーのデフォルト設定では、原則公開 ( A l l - a l l o w a n c e )とすること

が多い。そのため、意図しないコンテンツが、意図しない範囲に公開され

‐41‐

てしまう事態が発生し易い。また、その結果として、コンテンツのみならず

We b サーバー全体が攻撃の対象となる場合もある。


受信

リクエスト

受信



リクエスト

解析

リクエスト

解析

認証認証

チェック

アクセス

チェック

アクセス

コンテンツ

アクセス

コンテンツ

アクセス

レスポンス

作成

レスポンス

作成

レスポンス

送信

レスポンス

送信

ログ記録

ログ記録










外部ファイル










図 3 - 5 設定ミスの利用

3 .2 .5 仕様上の問題の利用

仕様上の問題には、2 種類ある。1 つは、各ソフトウェアやプロトコルの

仕様そのものに脆弱性がある場合である。この問題では、動的コンテン

ツや実行プログラムの仕様、O S や We b サーバーなどのソフトウェア仕様、

および H T T P などの通信プロトコルの仕様などの問題点を利用して攻

撃される。この攻撃の特徴は、仕様上の問題であるため、プログラムは、

仕様に基づく正しい動作を行っているにも関わらず、不正アクセスなどの

攻撃に晒されることである (図 3 - 6 )。

もう 1 つの問題は、複数のソフトウェアやプロトコルを組み合わせて利

用する場合に、互いの仕様の違いから生まれる脆弱性である。この問題

は、通常、オペレーティング・システムとその上で動作する We b サーバー

‐42‐

などのアプリケーションが、互いに独立して設計されるために発生する。

汎用のオペレーティング・システムを利用することのメリットは、アプリケー

ションを、プラットフォーム非依存にした設計がができることである。しかし、

その一方で、システムを全体としてみたときに、セキュリティ・ポリシーに一

貫性が無いなどの問題が発生することもある。目的が明確になっており、

かつ、高いセキュリティが求められる場合は、システム全体として、仕様が

統一される必要がある。


受信

リクエスト

受信



リクエスト

解析

リクエスト

解析

認証認証

チェック

アクセス

チェック

アクセス

コンテンツ

アクセス

コンテンツ

アクセス

レスポンス

作成

レスポンス

作成

レスポンス

送信

レスポンス

送信

ログ記録

ログ記録










外部ファイル










図 3 - 6 仕様上の問題

3 .2 .6 バックドアの利用

バックドアとは、正規の認証手続きを回避し、システムにアクセスするた

めの手段である。本来、We b サーバーへのコンテンツ要求は、全て We b

サーバーの正規の通信ポートに対して発行される。保護が必要なコンテ

ンツに対するアクセスの場合、認証機構などによって、あらゆる不正アク

‐43‐

セスから堅牢に守られるように設計される。そのため、利便性が低くなる

場合や、デバッグなどの試験が行い難くなる場合がある。そこで、システ

ム管理者やコンテンツ管理者が運用上の利便性などから、正規の方法

以外でも We b サーバーにアクセスできる仕組みであるバックドアを用意す

ることがある。また、悪意のある者が、システムに侵入し、後から再度侵

入できるようにするために、バックドアを設置する場合もある。

前者の例としては、あるコンテンツにアクセスするためにユーザ名とパス

ワードが必要だとする。しかし、コンテンツ管理者やシステム管理者が、

管理のためにアクセスする際に自分もパスワードを入力するのは面倒で、

自分自身が使用する We b クライアントの I P アドレスが常に一定だと考え、

特定の I P アドレスからの H T T P リクエストには無条件に受け付けるよう

な設定を行うと仮定する。こうすると、悪意ある者は、 I P アドレスを偽造し

たり、その I P アドレスを奪うことで、正規のユーザ名やパスワードを使用

せずに、コンテンツにアクセスできるようになる。このように、通常のアクセス

経路よりも、守りが弱くなるケースが往々にして、バックドアの場合起こりう

る。

後者の例では、悪意ある者がバッファ・オーバフロー攻撃などによって、

We b サーバーに侵入し、システム管理者などの権限を奪い、バックドア

の設置を行う。これにより、悪意ある者は、いつでも We b サーバーに容易

に再侵入することが可能になる。

この脆弱性は、システム管理者やコンテンツ管理者が意図したか、し

ないかに関わらず、認証機構を回避される問題である (図 3 - 7 )。従って、

脆弱部分は、管理者自身と、そのようなバックドアを持つ可能性がある

部分である。

‐44‐


受信

リクエスト

受信

OSOS



リクエスト

解析

リクエスト

解析

認証認証

チェック

アクセス

チェック

アクセス

コンテンツ

アクセス

コンテンツ

アクセス

レスポンス

作成

レスポンス

作成

レスポンス

送信

レスポンス

送信

ログ記録

ログ記録










外部ファイル










図 3 - 7 バックドアの利用

3 .2 .7 D o S

D o S 攻撃の目的は、We b サーバーを機能停止状態に陥らせることで

ある。この攻撃自体によって、コンテンツなどが不正にアクセスされること

はない。しかし、We b サーバーが機能停止させられることにより、We b サ

ーバーの本来の目的が達成されなくなる。この攻撃の特徴は、基本的

にシステムを過負荷の状態に陥らせることである。その方法としては、主

に、O S や We b サーバーのバグを利用するものと、単純に大量のリクエス

トなどを We b サーバーに対して発行することで機能不全に陥らせる 2 通

りの方法がある。

前者の例としては、ネットワークから不正なパケットが送られてきた際に、

パケット解析部分にバグがあり、パケットの処理が完了できなくなるという

脆弱性を持つ場合がある。例えば、Wi n d o w s 2 0 0 0 は、デフォルトで起

動される M i c r o s o f t L A N M a n a g e r ( L A N M A N )は、カーネル・メモリを

確保しパケットを受信する。不正なパケットを受信すると正しくパケットを

‐45‐

処理できず、更にメモリを確保する。最終的には、メモリを 1 0 0 %使い切

るまでカーネル内でメモリを確保するため、システム全体が機能不全に

追い込まれる。また、We b サーバーの A p a c h e も一部のバージョンで、ロ

グ・ファイルを書き込むディスクがあふれた場合の処理が正しく出来ない

ため、大量のリクエストを送り、ログ・ファイルを書き込むディスクを溢れさ

せることで、サービスを停止させることが可能である。

後者の例としては、We b サーバーの処理能力以上のリクエストを大量

に送信することで、機能不全に陥らせるものである。O S レベルで機能不

全に陥らせる攻撃としては、T C P F l o o d と呼ばれる S Y N / A C K / R S T フ

ラグを不正に設定した大量のパケットを送信するものや、P i n g F l o o d の

ような I C M P E c h o R e q u e s t / R e p l y パケットを大量に送信するものなど

がある。これらの特徴は、プロトコルの仕様の裏をつき、ネットワーク・プロ

トコル・スタックが正規の処理を行おうとして、大量の処理によって機能

不全に陥ることを利用する。また、We b サーバー・レベルでは、正しく同

時リクエスト数などの制限が行われていない We b サーバーにおいて、

We b サーバーの処理能力以上の H T T P リクエストを送信することで機

能不全に陥らせる攻撃もある。

この脆弱性は、基本的に仕様やソフトウェアのバグに起因する。そのた

め、脆弱部分は、図 3 - 8 に示すように We b サーバー、O S、実行プログ

ラムや動的コンテンツになる。

‐46‐


受信

リクエスト

受信



リクエスト

解析

リクエスト

解析

認証認証

チェック

アクセス

チェック

アクセス

コンテンツ

アクセス

コンテンツ

アクセス

レスポンス

作成

レスポンス

作成

レスポンス

送信

レスポンス

送信

ログ記録

ログ記録










外部ファイル










図 3 - 8 D o S 攻撃

3 .2 .8 クロスサイト・スクリプティング

クロスサイト・スクリプティングは、厳密には、We b サーバーに対する攻

撃ではない。We b クライアントへの攻撃である。しかし、この攻撃は、We b

サーバーの動的コンテンツの脆弱性を利用したものであるため、We b サ

ーバーが悪意のある者に利用されないように、脆弱性を無くす必要があ

る。

クロスサイト・スクリプティングは、We b クライアントが、悪意のある者によ

って仕掛けられたリンクに埋め込まれたスクリプトを、脆弱性のある We b

サーバーを経由することで、利用者の気がつかないうちに We b クライアン

ト上で実行する攻撃である。

悪意のある者は、利用者がリンクをクリックするか、フォームの送信ボタ

ンをクリックすると、利用者が信用する他のサイトへ H T T P リクエストを送

信するように仕掛ける。このリクエストには、< S C R I P T >エレメントなどで、

任意のコードを埋め込んでおく。リクエストを受け取った We b サーバーが、

‐47‐

何も考慮せずに受け取ったリクエストを動的コンテンツによって生成され

る H T M L に埋め込むとする。すると、これを受け取った We b クライアント

は、悪意のあるものが埋め込んだスクリプトを気がつかないうちに実行す

ることになる。この脆弱性は、動的コンテンツが受け取ったリクエストを、そ

のまま H T M L の一部に再利用することにある (図 3 - 9 )。

この脆弱性を利用されると、We b サーバーやコンテンツ自体に被害は

無い。しかしながら、このような攻撃に利用される足がかりとして、We b サ

イトとしての評価を下げることを避けられない。


受信

リクエスト

受信

OSOS



リクエスト

解析

リクエスト

解析

認証認証

チェック

アクセス

チェック

アクセス

コンテンツ

アクセス

コンテンツ

アクセス

レスポンス

作成

レスポンス

作成

レスポンス

送信

レスポンス

送信

ログ記録

ログ記録










外部ファイル










図 3 - 9 クロスサイト・スクリプティング

3 .2 .9 盗聴

この攻撃は、We b クライアントや We b サーバーの送受信する通信を傍

受することで、様々な情報を盗み取るものである。S S L などの暗号化通

信を利用していない通信は、この攻撃の格好の標的となる。コンテンツ

が公のものであれば問題ないが、公で無く、コンテンツ自体が保護されな

‐48‐

ければならない場合、この攻撃に晒される、情報の漏洩に繋がる。また、

H T T P の B a s i c 認証を用いている場合は、容易に悪意ある者にユーザ

名とパスワードを盗られる事になる。

盗聴は、ネットワークだけで無く、同じ O S 上の別の悪意ある利用者に

よって行われる可能性もある。例えば、パスワードを変更するプログラムを

管理者権限によって置き換え、パスワードを盗み取る機能が混入される

と、パスワード変更を行うたびに、新しいパスワードを悪意のある利用者

に盗られることになる。

図 3 - 1 0 は、この攻撃に対する脆弱部分を示したものである。この攻

撃は、外部とのネットワーク部分、および、O S が脆弱部分となりうる。


受信

リクエスト

受信



リクエスト

解析

リクエスト

解析

認証認証

チェック

アクセス

チェック

アクセス

コンテンツ

アクセス

コンテンツ

アクセス

レスポンス

作成

レスポンス

作成

レスポンス

送信

レスポンス

送信

ログ記録

ログ記録










外部ファイル










図 3 - 1 0 盗聴

‐49‐

3 .3 脆弱性対策の方針

3 . 2 節で検証してきたように、We b サーバーには、様々な脆弱性が潜

む。We b サーバーが、本来の目的を達成するためには、それぞれの脆

弱性に対する対策を講じるにあたり、その方針を議論する。脆弱性に対

する対策には、様々な方針が考えられるが、ここでは、T h e O p e n We b

A p p l i c a t i o n S e c u r i t y P r o j e c t の示す We b アプリケーションにおける

セキュリティの指針を元に脆弱性対策の方向性を示す 1。

• 入出力をチェックすること

We b サーバーの受け取る全てのデータの入出力は、それ自体に問

題が無いか確認される必要がある。バッファ・オーバフロー攻撃やクロ

スサイト・スクリプティング攻撃などは、このチェックによって、十二分に

防ぐことが可能である。

• 安全にフェイルすること

認証で本人確認に失敗するなどして、セキュリティ・チェックに失敗し

た場合、安全に終了する必要がある。例えば、認証に失敗した場合

は、その後、そのセッションの全てのリクエストを受け付けないようにし

なければならない。これによって、セッション識別子を利用したなりすま

しを防ぐこともできる。

• シンプルにしておくこと

セキュリティは、可能な限りシンプルであるべきである。複雑なシステム

であればあるほど、利用者は、そのセキュリティ対策を全く使わないか、

1

h t t p : / / w w w. o w a s p . o r g / d o c u m e n t a t i o n / g u i d e / g u i d e _ a b o u t . h tm l

‐50‐

迂回しようとする。結果として、バックドアを設置し、容易に認証系を

回避する仕組みを作ろうとする。このような管理者の意識の問題に

起因する脆弱性の対策は、このような考え方によって、ある程度抑え

ることができる。

• 信用できる機構を利用すること

脆弱性の問題は、多くの管理者が同じ問題に直面し、様々な対策

を採ってきている。多くの場合、既に脆弱性を解決する方法が示さ

れている。特に、バグを利用した脆弱性を解決するには、既知の対

策を採ることで、バグ対策が新たなバグを生み出す可能性を軽減す

ることが出来る。

• 防御の層化をすること

全ての防御を 1 つの機構で行うのは、現実的ではない。全ての例外

を想定し、その全てに対策を講じることは困難だからである。防御を

何層にも分けることで、1 つの機構で取りこぼしたセキュリティ上の問

題を、別の機構で守るような方法を考慮すべきである。例えば、We b

サーバーのアクセス制御で取りこぼしたセキュリティ上の例外は、O S

のアクセス制御機構によって保護できるようにするべきである。

• We b サーバーのセキュリティ・レベルは最も脆弱な部分と同レベル

We b サーバーが幾ら強固なセキュリティ対策が施されていても、バッ

クドアが設置されていれば、セキュリティ対策は無いに等しい。例えば、

1 2 8 b i t S S L などを使って通信部分のみを保護しても、We b サーバ

ーへの侵入が容易であれば、このような対策は意味が無い。コンテン

ツなどを容易に別の方法で盗み取れるからである。セキュリティ対策

は、全体のバランスを見て、決定される必要がある。

‐51‐

• 隠蔽によるセキュリティは無意味

情報の存在を知らせないことが、最も安全であると言う考えは成り立

たない。この仮定は、誰もその存在を知らないことを前提としているが、

長期的に見れば、隠蔽をしても、必ず発見される。事実、多くのセキ

ュリティ・ホールが十分な対策が採られないがために、攻撃に利用さ

れている。

• 最少権限を与えること

全てのシステム管理者を含む利用者に対して、その利用者が本当

に必要な権限以外を与えないことが重要である。例えば、We b サー

バーは、O S 上の特定のユーザ権限のプログラムとして動作する。そ

のため、どのような We b クライアントがコンテンツを要求しても、同じユ

ーザ権限で、あらゆるコンテンツにアクセスする。これは、不必要に

We b クライアントの権限を広げることに繋がりかねない問題を持つ。

最少権限のみを与えることで、仮に悪意ある者に権限を奪われたと

しても、その被害の範囲を最小限に抑えることが可能になる。

• 権限を分離すること

権限を細かく分離し１人の管理者があらゆる権限を持たないようにす

ることも、We b サーバーの脆弱性を防ぐ重要な手段である。例えば、

システム管理者とコンテンツ管理者の権限を完全に分離し、同じ人

間が両方の権限を持たないようにすることで、設定ミスや意図的なバ

ックドアの設置などによる不正アクセスなどを防ぐことが可能になる。

3 .4 脅威に対する対策

ここでは、前節の脆弱性対策の方針に基づき、We b サーバーの脆弱

性に対して、どのような対策を講じるべきか検証する。 3 . 2 節で検討した

‐52‐

We b サーバーの脆弱性を元に検証することで、本質的な対処方法を考

察する。

3 .4 .1 なりすましに対する対策

なりすましは、正規の利用者と偽の利用者の判別が出来ない場合に

悪用される。例えば、容易に推測可能なユーザ名とパスワードを使用し

たり、H T T P B a s i c 認証を S S L などの暗号化を行わない環境で使用す

ると、容易に漏洩する可能性がある。

しかし、現在の所、なりすましに対して 1 0 0 %完全に安全な方法は無

い。対策の基本は、パスワードを推測され難くする方法である。文字、数

字や記号を組み合わせた長いパスワードを使用することで、辞書を使っ

たブルート・フォース攻撃によるパスワード解析に対しては、ある程度の

耐性を持つことになる。しかし、解析が不可能ではないため、長期に渡り

同じパスワードを使用している場合、幾ら複雑なパスワードを使用してい

ても解析される可能性が高くなる。そこでパスワードに有効期限を設定

したり、過去に使用されたパスワードを再利用できないようにするなどの

対策が有効となる。

認証機構が返すチャレンジを使用してワンタイム・パスワードを用いる

方法や、時間でハッシュ値を生成するデバイスを使用する方法などでは、

パスワードを盗まれても再利用できない。しかし、ある時点で使用するべ

きパスワードは、特定のアルゴリズムによって決まるため、そのアルゴリズム

とパラメータが洩れると、容易にパスワードが生成される可能性がある。

利用者が、どのネットワークから、どの時間帯に接続するか、といった

情報を活用し、アクセスしてきた利用者が本人であるかを検証する方法

も有効である。例えば、本来イントラネットからしか接続し得ない利用者

が、インターネット経由で接続してきた場合、その接続は不正アクセスで

ある可能性が高くなる。イントラネットからであっても、館内に誰も居ない

‐53‐

時間帯にアクセスしてきた場合、不正アクセスである可能性が非常に高

くなる。このような、利用者がアクセスしてきた状況 (アクセス・コンテキスト )

を利用することで、利用者が本人である可能性を認証のパラメータとし

て考慮することも、なりすましによる被害の範囲を限定的にする上では有

効である。

セッション識別子を悪用するなりすましについては、セッション識別子を

使い捨てとし、偽造され難いものを使用することや、セッション識別子に

期限を設けるなどして、リクエスト毎にセッション識別子を生成することで、

多くの場合、脆弱性を軽減することが可能である。また、S S L / T L S を使

用することで、We b サーバーと We b クライアントの間のセッションを保護

することが可能になる。ただし、この場合でも、良く知られた R o o t C A に

よるサーバー証明書を使わない場合で、独自 R o o t C A の証明書を

We b クライアントにインストールしていない場合、容易に

M a n - I n - T h e - M i d d l e 攻撃の対象となる。

いずれの場合であっても、なりすましによる攻撃を察知した時点で、即

座に該当するアカウントやセッションを停止する措置を講じられるようにす

ることが肝要である。

3 .4 .2 バグの利用に対する対策

プログラムのバグを利用した攻撃に対する対策は、基本的に、プログラ

ムに目的外の動作を出来ないようにすること以外に無い。バッファ・オー

バフロー攻撃や S Q L 文を直接実行できる脆弱性を利用した攻撃は、コ

ンテンツ管理者の想定外の入力によって引き起こされる。基本的には、

プログラムが想定外の入力に対して堅牢であるべきだが、 1 0 0 %それが

保証できない場合、プログラムの実行権限が奪われたとしても、プログラ

ムが必要の無いリソースにアクセスできないようにする必要がある。

例えば、We b サーバーが、コンテンツ以外にアクセスできなければ、バッ

‐54‐

ファ・オーバフロー攻撃によって制御が奪われ、システムのパスワード・フ

ァイルを取得されようとしても、O S のアクセス・コントロールによってアクセ

スが許可されない。このように、防御を多層化すること、および、仮に想

定外の結果になっても、被害の範囲を予想可能な最小限に留められる

ように、権限の細分化と最少化が肝要となる。

3 .4 .3 設定ミスの利用に対する対策

設定ミスを利用した攻撃の対策も、基本的には、権限の細分化と最

少化が根本的な対策となる。設定ミスも、プログラムのバグ同様に、

1 0 0 %無くすことは現実的に難しい。通常は、設定を複数の人間によっ

て見直したり、検証ツールを用いて、脆弱性が無いかを検証する。しか

し、これでも全ての問題が発見されない場合がある。

まず、We b サーバーの動作を設定するシステム管理者の権限と、コン

テンツ管理者の権限を分離することで、コンテンツ管理者によって、間

違った設定が行われることを回避する必要がある。また、管理主体が異

なるコンテンツがある場合、いずれかのコンテンツ管理者の設定ミスによ

って、他のコンテンツ管理者のコンテンツに被害が及ばないようにするに

は、設定権限の細分化が必要となる。

設定ミスが仮に発生したとしても、プログラムのバグ同様に、アクセス・コ

ントロールの設定を細かくし、権限の細分化と最少化を実践することに

よって、被害の範囲を予想可能な範囲に収めることが出来る。

3 .4 .4 仕様上の問題に対する対策

仕様の脆弱性を利用した攻撃に対して、本質的には、仕様を変更す

ることでしか対応できない。しかし、プログラムのバグなどと同様に、アクセ

ス・コントロールの設定を細かくし、権限の細分化と最少化を実践するこ

とによって、被害の範囲を予想可能な範囲に収めることが出来る。

‐55‐

3 .4 .5 バックドアの利用に対する対策

バックドアを利用した攻撃に対しては、基本的にバックドアを作らせな

いことが第一である。これは、バックドアを作るのに必要な権限を We b サ

ーバーに容易に持たせないようにすることで対応する必要がある。また、

バックドアが仮に作られたとしても、バックドアを動作する権限が最少限

であれば、これも被害の範囲を想定内の最少範囲に収めることが出来

る。

この攻撃に対しても、権限の細分化と最少化が最も有効な対抗手段

となる。

3 .4 .6 D o S 攻撃に対する対策

D o S 攻撃を利用した攻撃に対しては、基本的に、We b サーバーが処

理可能な量にリクエスト数を制限したり、不正なパケットなどが We b サー

バーに到達しないようにすることでしか対応できない。ファイアウォールや

ロード・バランサなどで、ある程度の対策を講じることは出来る。しかし、

残念ながら、例えば、ファイアウォールを導入しても、一部のファイアウォ

ールにあった正しくパケットをフィルタリングできないバグにより、正しく機

能しない場合や、正しく機能している場合にも、必ずしも全ての不正な

パケットなどに対して対応できないことが考えられる。We b サーバー側で

も、O S や We b サーバーを修正するなどして、D o S 攻撃の足がかりを作ら

せない必要がある。

D o S 攻撃に対しては、ネットワークおよび We b サーバーにおける多層

的な防御手段を講じる必要がある。

‐56‐

3 .4 .7 クロスサイト・スクリプティングに対する対策

クロスサイト・スクリプティングは、動的コンテンツが正しく入力された値

を確認し、危険なスクリプトをクライアントに対して返さないようにすること

で回避できる。基本的には、動的コンテンツの実装方法の問題であるた

め、コンテンツ管理者の意識の問題と言える。

3 .4 .8 盗聴に対する対策

ネットワーク上の盗聴に対しては、 I P s e c や S S L / T L S を使用した通信

の暗号化などによっての対策が効果的である。しかしながら、S S L / T L S

を使う場合であっても、R o o t C A がクライアントに正しく登録されていない

と M a n - I n - T h e - M i d d l e 攻撃の対象になりうるため、対策としては不十

分となる。

システム内の盗聴については、やはり、権限の細分化と最少化が最も

有効な手段となる。これによって、不要に重要な管理用コマンドが書き

換えられたり、盗聴する手段を与えないようにすることができる。

3 .5 脆弱性分析のまとめ

本章では、We b サーバー・システムの脆弱性、特に We b サーバーの

持つ脆弱性について論じてきた。We b サーバー・システムは、情報を共

有する手段として、非常に高い価値を持つ。ネットワークを介することで、

地理的に分散した多くの利用者に対して、様々な情報を提供する手段

となる。その一方で、この利便性が We b サーバーの脆弱性に直結する。

3 . 4 節で論じた We b サーバーの脆弱性に対する対策を表 3 - 1 に纏

める。この表は、対策とそれによって防ぐことが可能な攻撃を示したもの

である。◎は最も有効な対策を示し、○は比較的有効な対策を示す。

基本的に、脆弱性を防ぐには、バグの改修やパスワードなどを複雑に

‐57‐

するなどの対策が必要になる。しかし、どのようなシステムであっても、全

ての攻撃に対して 1 0 0 %安全な対策が取れるわけではない。結果として、

対策は脆弱性が発見された後に講じられるため、被害が広がることが多

い。これは現実的ではない。むしろ、攻撃され、防御が破られた場合でも、

その被害の範囲を予想の範囲内に収められるようにすることが重要であ

る。そのためにも、権限の細分化と最少化が重要になる。

表 3 - 1 攻撃の種類と対策の有効性

対策の種類

権

限

の細

分

化

権

限

の最

少

化

アクセス・コン

テキスト

ファイアウォ

ールなどによ

る保

護

高

度

な認

証

通

信

の暗

号

化

バグの改

修

なりすまし ○ ○ ◎ ◎ ◎

バグの利用 ◎ ◎ ◎

設定ミスの利

用

◎ ◎

仕様上の問

題の利用

◎ ◎

バックドアの利

用

◎ ◎ ○ ○

D o S 攻撃 ○ ○

クロスサイト・ス

クリプティング

◎

攻

撃

の種

類

盗聴 ◎ ◎ ◎

‐58‐

4 アクセス制御に対する要件

前章では、We b サーバー･システムの内部モジュール・モデルを使って

We b サーバー･システムに潜む脆弱性の分析とその対策方法について

検討した。本章では、前章の分析結果および対策方法にしたがって、

We b サーバー･システムのアクセス制御に必要とされる要件をまとめる。

4 .1 強制的アクセス制御実現のための要件

We b サーバー･システムにおいて強制的アクセス制御を実現するため

に必要な要件を整理する。

• 不可避なアクセス制御

現実装方式における We b サーバーのアクセス制御機能は、様々な

方法によりアクセス･チェックを回避させてしまうことが可能である。アク

セス･チェック･モジュールは、ハードウェアやオペレーティング･システム

により保護されていないためユーザ･プログラム内に存在するため、

We b サーバーを奪取することにより、モジュール内コードを改ざんされ

る可能性がある。モジュールによるアクセス･チェック処理は、リクエスト

解析モジュールがコンテンツ･アクセス・モジュールへリクエストを渡す

まえにアクセス･チェック･モジュールを呼び出すことにより実現されて

いるため、リクエスト解析モジュールの不都合や改ざんにより、アクセ

ス･チェック･モジュールの呼び出しをスキップすることでアクセス･チェッ

クを無効化できる。

オペレーティング･システムのアクセス制御機能は、リソースに対するす

べてのアクセスをチェックすることを保証する。しかし、現在のオペレー

ティング･システムの多くでは、絶対権限を持つシステム･アカウント

（ r o o t）によるアクセスに対してアクセス･チェック機能が無効となる。

強制的アクセス制御を実現するためには、アクセス･チェック･モジュー

‐59‐

ルが改ざんされないこと、および、アクセス･チェックが不可避であるこ

とが求められる。

• A l l - d e n i a l の原則によるアクセス制御設定

現状の We b サーバー･システムにおけるアクセス制御設定は、

a l l - a l l o w a n c e 原則に基づいている。つまり、特にアクセス制御設定

を行わないすべての We b コンテンツは、匿名 We b クライアント･ユーザ

からのアクセスを許可するということである。ユーザの数やコンテンツの

数が増えシステムの規模が大きくなるほど、アクセス制御設定作業は

煩雑になり、設定ミスや設定漏れの可能性が高くなる。設定漏れの

際に、本意でない公開を防ぐために、a l l - d e n i a l 原則に基づくアク

セス制御設定が必要である。

• システム管理者とセキュリティ管理者の分離

現在のオペレーティング･システムの多くは、アクセス制御設定の権限

は、リソースの所有者とシステム管理者に与えられる。強制的アクセス

制御では、アクセス制御ポリシーを決定するセキュリティ管理者をシス

テム管理者から独立し、 r o o t のような絶対権限を持つシステム管理

者のアクセスに対してもアクセス制御が有効になるようにすべきであ

る。

• セキュリティ･ポリシーの強制

多くの We b サーバー･システムでは、We b コンテンツ管理者に対して

所有するコンテンツのアクセス制御設定権限を与えている。We b コン

テンツによる任意のアクセス制御設定では、設定漏れによる漏洩、改

ざんの危険を生む可能性がある。強制的アクセス制御を実現するた

めに、セキュリティ管理者が設定したセキュリティ･ポリシーをシステム

全体に対して強制する仕組みが必要である。

‐60‐

4 .2 Web サーバー･システムのための要件

2 章で整理した We b サーバー･システムの内部構成および特徴から、

We b サーバー･システムのアクセス制御として特に考慮しなければならな

い要件について以下にまとめる。

• アクセス・コンテキストを考慮したアクセス制御

現在の We b サーバー･システムでは、ユーザ以外のサブジェクト特定

方法として、ユーザが利用している計算機およびソフトウェアのネット

ワーク上の位置（ I P アドレスやドメイン）を用いることができる。このよう

なアクセス要求発行の際の状況を客観的に特定するアクセス・コンテ

キストをアクセス制御に適用する必要がある。

• 動的 We b コンテンツへの最少権限付与

多くのシステム権限を持つ We b サーバーの権限を用いて動的コンテ

ンツを実行することは、不正な権限行使の脅威につながる。動的コン

テンツの実行に必要な権限を最少化し、強制する仕組みが必要で

ある。

• We b サーバーが持つ権限の細分化

多機能な We b サーバーに付与される権限は多岐にわたり、We b サ

ーバーが奪取されたときの危険性が大きい。We b サーバー内部を解

析して、権限が及ぶ範囲を細分化すべきである。

• 一貫性のあるアクセス制御

オペレーティング･システムによるアクセス制御を We b サーバーに対し

ても適用するために、We b サーバーのアカウント管理とオペレーティン

‐61‐

グ･システムのアカウント管理を統合する必要がある。また、オペレーテ

ィング･システムにより、We b サーバーで行われる認証のサポートを行

うべきである。

• 設定ミスの予防

不特定多数のユーザからアクセスされる We b サーバー・システムのア

クセス制御は、設定が膨大かつ煩雑なものとなる可能性がある。設

定ミスを防ぐためには、ポリシー設定の視認性を向上し、一貫性のあ

る設定を強制することが重要である。

‐62‐

5 関連セキュリティ･ポリシー・モデルの分析

本章では、幾つかのセキュリティ･ポリシー･モデルを取り上げ、We b サ

ーバーへの適応性分析を行う。本章で取り上げるセキュリティ･ポリシー･

モデルは Tr u s t e d S o l a r i s を除き R B A C と T E の組み合わせである。

そこで、各モデルの分析を行う前に、最も基本的な R B A C＋T E モデル

に We b サーバーを適応した例を説明する。

まず、幾つかの用語を定義する。R B A C＋T E のモデルにおけるユー

ザ（U S E R ）は、システムに存在するユーザ･アカウントを示し、ロール

（R O L E ）はユーザの役割を示す。サブジェクト（ S U B J E C T ）は行為の

主体を指し、オブジェクト（O B J E C T ）は行為の対象を指す。ドメイン

（ D O M A I N ）はサブジェクトに対して割り当てられるラベルを、タイプ

（T Y P E ）はオブジェクトに対して割り当てられるラベルを示す。また、ドメ

イン･タイプ･ペア（ D O M A I N - T Y P E P E A R ）では、アクセス･モード

（A C C E S S M O D E ）と呼ばれるサブジェクトのオブジェクトに対して許可

された操作が定義されている。R B A C＋T E の基本的なモデルの例を図

5 - 1 に示す。この例では、各要素の間に図で示された関係がある。

「N : 1 」とは、N 個の要素に対して 1 つの対応が存在することを示し、

「M : N」は、M 個の要素に対して N 個の対応が存在することを示す。

上記のモデルを We b サーバーに適応する場合、We b サーバーはサブ

ジェクトに相当し、We b コンテンツはオブジェクトに相当する。We b サーバ

ーは、そのドメインにアクセスを許可されたオブジェクトファイルに対しての

み、参照や実行といった操作が許可される。

静的コンテンツと動的コンテンツが We b サーバーによって処理される

場合、通常は、それぞれの処理に必要となる権限は異なっている。その

ため、We b サーバーをセキュアに動作させるためには、静的コンテンツと

‐63‐

動的コンテンツの処理に応じて、それぞれ異なったアクセス制御を強制

する仕組みが必要になる。

図 5 - 1 に示した R B A C＋T E の基本的なモデル例では、ロールに対

して 1 つのドメインしか付与できない。このため、We b サーバーは動的コン

テンツと静的コンテンツに対して、同一のドメインで処理を行わなければ

ならない。また、同一のドメイン内で異なるアクセス制御を実現する仕組

みも定義されていないため、結果として、動的コンテンツと静的コンテンツ

に対して、異なるアクセス制御を強制する仕組みを持たないことになる。

本章で説明する各モデルは、それぞれ独自の方法により、We b サー

バーが、動的コンテンツと静的コンテンツに対してアクセスする際に、それ

ぞれ異なるアクセス制御が行われる仕組みを実現している。

図 5 - 1 R B A C の基本モデルと We b サーバーへの適応例

USER

ACCESSMODE

ROLE DOMAIN

SUBJECT OBJECT

DOMAIN-TYPE PAIR

OBJECT-TYPE

N:M N:1

N:1

M:N

N:1

コンテンツに相当Webサーバに相当

USER

ACCESSMODE

ROLE DOMAIN

SUBJECT OBJECT

DOMAIN-TYPE PAIR

OBJECT-TYPE

N:M N:1

N:1

M:N

N:1

コンテンツに相当Webサーバに相当

‐64‐

各モデルの We b サーバーへの適応性分析では、以下の項目につい

て分析を行う。

• 動的コンテンツと静的コンテンツのそれぞれで、異なるアクセス制御を

行う仕組みについて

サブジェクトに対してドメイン（Tr u s t e d S o l a r i s では機密ラベル）を

割り当てる仕組みや、同一のラベルを持つサブジェクトに異なるアクセ

ス制御を強制する仕組みについて分析する。

• ドメイン（機密ラベル）を追加した際に、影響される要素の数について

ドメイン（機密ラベル）を追加するというということは、異なるアクセス制

御を行う領域（例えば、C G I や S S I といった動的コンテンツに対して

アクセス制御を行う領域）を新たに追加するということである。影響の

受ける要素数が多くなれば、設定変更が必要となる箇所も多くなる。

つまり、要素数を調べることで、各モデルが本質的に持つ管理の煩

雑さを分析する事ができる。ただし、これらの煩雑さと、実際の煩雑さ

は必ずしも一致しない。管理ツールや実装によっては、影響される要

素数の多いモデルでも、容易に管理しうる場合がある。

• We b サーバー及び、動的コンテンツが改竄された場合の被害範囲

について

攻撃者により、We b サーバーや動的コンテンツが改竄された場合に、

被害が及ぶ範囲を分析する。

‐65‐

5 .1 Hof fman ’s RBAC

H o f f m a n は、これまでデータベースや We b サーバーにおいて応用さ

れてきた R B A C ポリシーを、汎用オペレーティング･システム上（論文中

では S e c u r e C o m p u t i n g C o r p o r a t i o n が開発した L O C K 6 を例にし

ている）で実装する方法について論じた。H o f f m a n は論文の中で、

R B A C K と T E を組み合わせた新しいポリシー・モデルを提唱している。

5 .1 .1 R B A C と T E を組み合わせる利点

H o f f m a n は、セキュアなシステム実現のためには、R B A C のみでは不

十分で、Ty p e E n f o r c e m e n t（以下、「T E」という）のような低いレベルの

メカニズムが必要であると述べている。

R B A C ポリシーを採用したシステム上で、信頼性の低いソフトウェア

（サブジェクト）を起動させている場合を例に取る。信頼性の低いサブジ

ェクトは、ロールに与えられている特権やパーミッションの不正利用や乱

用を引き起こす可能性がある。R B A C ポリシーのみでは、サブジェクトの

オブジェクトに対するアクセスは単純にロールだけに依存する。従って、

サブジェクト自体の信頼性の低さを何ら考慮することなくアクセスが実行

されることになり、パーミッションの不正利用、乱用の危険を減じ得るもの

ではない。この不正利用、乱用の危険を減少させるためには、ロールを

細分化し、タスクを実行するために必要なオブジェクトのみにアクセス権

を制限する、つまり最少権限の原理を満たす必要が生じる。しかし、ロ

ールを細分化することは、ロールが持つ直感的で分かりやすいアクセス

制御といった性質を失わせ、ユーザに対して多数のロールとそのパーミッ

ションを把握することを強制するため、システムの利用が非常に複雑化

することになる。

そこで、R B A C ポリシーに加えて T E ポリシーのドメイン -ラベルの概念

‐66‐

を採用すると、サブジェクトのオブジェクトに対するアクセスは、サブジェク

トのドメインとオブジェクトのラベルによって決定されるため、信頼性の低

いサブジェクトには特定のタイプを持つオブジェクトのみにアクセス権を与

えるようにドメインを記述するだけで簡単にアクセス制御を実現することが

できる。つまり、R B A C と T E の組み合わせは、ロールの直感的で分かり

やすいという性質を保ちながら、サブジェクトの信頼性を考慮したアクセ

ス制御を可能にすることができる。

5 .1 .2 ポリシー・モデルの概要

H o f f m a n の提唱した R B A C および T E を使ったポリシーの概要は以

下の通りである。

各サブジェクトに、ロールおよびユーザを 1 つずつ関連付ける。さらに、

各ユーザには複数のロールを関連付ける。この時、サブジェクトに関連

付けられるロールは、そのユーザに対して割り当てられているロールに限

る。さらに、各サブジェクトに 1 つのドメインを、さらに各ロールに複数のド

メインを関連付ける。この時、サブジェクトに関連付けられるドメインは、そ

のロールに対して許可されたドメインに限る。

典型的な R B A C ポリシーではロールとオペレーションを直接関連付け

るが、H o f f m a n は T E ポリシーを利用することにより、ロールとオペレーシ

ョンの間にドメインというレイヤを新たに導入して、ドメインを介してロール

とオペレーションを関連付けた。

‐67‐

図 5 - 2 H o f f m a n による R B A C と T E の混合モデル概要

図 5 - 3 H o f f m a n による R B A C と T E のモデル構造

D1

D2

D4

D3

D5

SUBJECTSUBJECT

OBJECTOBJECT

Security Database

T1

※ U … USER R … ROLE D … DOMAIN T ･･･ TYPE

D1 D2 D3

Type Enforcement Database

D2

U1

U2

U1

R4

R3

R2

R1

R1

read

T1 r, w r,wT2 r,w,d r,w r

D1

D2

D4

D3

D5

SUBJECTSUBJECT

OBJECTOBJECT

Security Database

T1

※ U … USER R … ROLE D … DOMAIN T ･･･ TYPE

D1 D2 D3

Type Enforcement Database

D2

U1

U2

U1

R4

R3

R2

R1

R1

read

T1 r, w r,wT2 r,w,d r,w r

USER

ACCESSMODE

ROLE DOMAIN

SUBJECT OBJECT

DOMAIN-TYPE PAIR

OBJECT-TYPE

N:M N:M

N:1

M:N

N:1

USER

ACCESSMODE

ROLE DOMAIN

SUBJECT OBJECT

DOMAIN-TYPE PAIR

OBJECT-TYPE

N:M N:M

N:1

M:N

N:1

‐68‐

サブジェクトのユーザ、ロールおよびドメインの関係性は、セキュリティ・

データベース内に格納する。セキュリティ・データベースによって、どのユ

ーザに対してどのロールが許可されているか、どのロールがどのドメインを

実行することができるかを特定する。

さらに、T E ポリシーに則り、オブジェクトには 1 つのタイプを関連付ける。

サブジェクトのオブジェクトに対するアクセス（ r e a d , w r i t e , d e l e t e など）

は、サブジェクトのドメインとオブジェクトのタイプの組み合わせによって決

定される。この組み合わせを Ty p e E n f o r c e m e n t D a t a b a s e に格納す

る。

サブジェクトによるオブジェクトへのアクセスは、この S e c u r i t y

D a t a b a s e および Ty p e E n f o r c e m e n t D a t a b e s e に基づいてスタティ

ックに制御される。

5 .1 .3 ポリシー・モデルの特徴

他の R B A C ポリシーと同様に、H o f f m a n の R B A C ポリシーにおいて

も、ロール毎に細かくアクセス権を制限し、必要以上の権限がユーザに

与えられることを避けることができる、つまりユーザの最少権限の原則を

遵守することができる。この最少権限の原理は、不正アクセスなどの危

険性を軽減し、人為的ミスを削減するために効果的である。

H o f f m a n は、わずかなトレーニングしか受けていないユーザでも容易

に管理可能なシステムを目指していたため、システムおよびその概念を

できるだけ単純化した。そのため明瞭性に優れた分かりやすいポリシーと

なっている。

H o f f m a n の R B A C ポリシーでは、一度に 1 つのロールでのみ、サブジ

ェクトがオペレーションを実行できる。これは、N I S T ポリシー（同時に複

数のロールでサブジェクトがオペレーションを実行可能）などとは異なる。

サブジェクトの動作が複数のロールに依存すると、どのロールでどのサブ

‐69‐

ジェクトが動作しているのかが複雑化し、システムのユーザはその複雑な

ロールとパーミッションの関係性を把握するという不必要な負担を強いら

れることになる。一度に 1 つのロールのみを有効にすれば、ロール、サブ

ジェクトおよびパーミッションの関係性は非常に単純で分かりやすい。

また、H o f f m a n の R B A C ポリシーでは、あるドメインがどのタイプにアク

セスする必要があるかは、操作時のロールによってではなく、サブジェクト

が実行しなければならない個々の責務によって決定される。従って、ロー

ルとそれに関連する責務が判明すれば、その責務を遂行するために必

要なサブジェクトとドメインを容易に導き出すことができる。

5 .1 .4 We b サーバーへの適応性分析

H o f f m a n のモデルの特徴は、ロールとドメインが N : M で割り当てられ

ることである。１つのロールに複数のドメインを割り当てることで、静的コン

テンツと動的コンテンツを処理する際に、異なるドメインで We b サーバー

を動作させることが可能となる。

また、新たなドメインを追加し、そのドメインで We b サーバーを動作させ

る為には、ドメイン、タイプとドメイン -タイプ･アクセス･マトリックスの 3 つの

ポリシー･ファイルを修正すれば良い。

H o f f m a n のモデルでは、静的コンテンツと動的コンテンツに対して、

異なるドメインで We b サーバーを動作させるため、C G I、S S I といった一

般ユーザによって作成された信頼できないプログラムが実行される場合

に、そのプログラムに最少権限を付与することが可能である。しかし、この

利点はプログラムが設定されたドメインで動作する場合に限られる。

H o f f m a n のモデルでは、動的コンテンツを攻撃者に改竄された場合に

は、その動的コンテンツのアクセス可能な範囲、及び、その動的コンテン

ツから実行が許可されているプログラムのドメインからアクセス可能な範

囲に被害が及ぶ。同様に、We b サーバーを改竄された場合には、We b

‐70‐

サーバーのアクセス可能な範囲、及び、We b サーバーから実行が許可さ

れているプログラムのドメインからアクセス可能な範囲に被害が及ぶ。

5 .2 DAFMAT

D A F M AT （D y n a m i c A u t o r i z a t i o n F r a m e w o r k f o r M u l t i p l e

A u t h o r i z a t i o n Ty p e s）とは、R . C h a n d r a m o u l i が提唱したセキュリテ

ィ･ポリシーであり、医療アプリケーション・システムを想定している。

C h a n d r a m o u l i が D A F M AT を提唱した 2 0 0 1 年当時、患者の個

人情報を扱う医療アプリケーション・システムは H I PA A 2セキュリティ標準

への準拠が必須となると見られていた。H I PA A では、H I PA A 準拠の企

業体のいずれかと取引提携または信頼の環契約を結んでいるヘルスケ

ア・プロバイダ、医療保険機関、およびその他の団体に対し、アクセス制

御、データの整合性、認証、監査制御、暗号化などの技術的セーフガ

ードの規定が義務付けられている。この標準は、医療アプリケーション･

システムに、ユーザ・ベース、ロール･ベースおよびコンテキスト・ベースの

承認に加え、非常時の承認も可能とするよう要求するものである。

当時のアプリケーション・システムで利用されているセキュリティ･ポリシ

ーは、A C L エントリやシステム・テーブルといったスタティック・データベー

スを用いて決定されていた。C h a n d r a m o u l i は、これらのスタティックな

ポリシーでは、非常時の承認やコンテキスト･ベースの承認といった複数

のタイプの承認をサポートすることはできないと考え、複数の承認タイプを

サポートするダイナミックなセキュリティ･ポリシー、D A F M AT を提唱した。

2 アメリカ合衆国で 1 9 9 6 年に制定された法律。H I PA A とは、

H e a l t h I n s u r a n c e P o r t a b i l i t y a n d A c c o u n t a b i l i t y A c t の略称。日本語では「医療保険の携行性と責任に関する法律」などと呼ばれ

る。

‐71‐

5 .2 .1 R B A C と D T E を組み合わせる利点

D A F M AT におけるアクセス制御・モデルは、R B A C ポリシーと D T E ポ

リシーの組み合わせであるといえる。C h a n d r a m o u l i は、R B A C と D T E

を組み合わせることにより、プラットフォーム上のパーミッション領域におい

て、D A F M AT の構成要素であるサブジェクト、オブジェクトおよびオペレ

ーションを体系化することができると述べている。

例えば、U N I X で D T E を考えた場合、ドメインとなるのはデーモン、フ

ァイル･システム、アドミニストレーション・ユーティリティである。これに

R B A C を組み合わせて、１つのドメインに対して 1 つ以上のロールを割り

当てる。任意のビジネス・プロセスは、膨大な量のトランザクションと呼ば

れる実行コードによって実行されおり、これらのトランザクションは、ユーザ

が呼び出すことができるサブジェクトと呼ばれるプログラム内に組み込まれ

ている。サブジェクトの動作は、サブジェクトを呼び出したロールに依存す

ることになる。このように、サブジェクトの実行ロジックとドメインの割り当て

はロールの動作と結びついている。従って、サブジェクトの実行ロジックと

ロール、ドメインの割り当てとロールの関係性により、サブジェクトへのドメ

インの割り当てを制限し、サブジェクトに対するロールの任意割り当てを

防止することが可能となる。


D A F M AT は、以下のコンポーネントから成る。

1 . 複合 R B A C - D T E アクセス制御・モデル

2 . 論理駆動承認エンジン

1 . 複合 R B A C - D T E アクセス制御・モデル

複合 R B A C - D T E アクセス制御・モデルは以下のコンポーネントで

構成される。

‐72‐

A . 承認エンティティ

B . 承認エンティティ間の関係

C . 承認エンティティ間の関係に関する制約

A . 承認エンティティ

i . ユーザ（U S E R）

例）「佐藤」ユーザ、「田中」ユーザ

i i . ロール（R O L E）

職位を表す。

例）「医者」ロール、「看護師」ロール

i i i . サブジェクト（S U B J E C T）

職位が要求するビジネス・プロセス機能を実行するためのト

ランザクションを内包するプログラムまたは実行ファイルを表

す。

i v . ドメイン（D O M A I N）

ロールが機能することができる企業の高レベルな機能領域

を表す。

例）「医者」ロールや「看護師」ロールは、「患者治療」ドメイ

ン内で機能する。

v . オブジェクト・タイプ（O B J E C T- T Y P E）

アプリケーション・システムや医療機能などに関する関連情

報を扱うオブジェクトの分類を表す。

例）「患者登録」タイプには、患者の保険やアレルギーなど

に関連する患者の記録が含まれる。

B . 承認エンティティ間の関係

ソース承認エンティティとターゲット承認エンティティの組み合わ

せからマッピングする。マッピングには以下の 2 つのタイプがある。

‐73‐

承認エンジンが利用するロジック・データベースでは、2 つタイプ

はいずれもプレディケートを表し、イタリック・フォントかつ丸かっこ

で表示する。

• 「N : 1」

ソース・エンティティの複数（2 つ以上）の事例が、ターゲット・

エンティティの 1 つの事例にマッピングされている場合は、そ

のマッピングを「N : 1 」と表現し、マッピング機能は> > _ >という

記号で表す。

• 「M : N」

ソース・エンティティの複数（2 つ以上）の事例が、ターゲット・

エンティティの複数（2 つ以上）の事例にマッピングされている

場合は、そのマッピングを「M : N 」と表現し、マッピング機能は

> > _ > >という記号で表す。

‐74‐

各承認エンティティ間のマッピングについては、以下の通りであ

る。

1 . ユーザ - ロール

医療関連企業を想定した場合、ロールは職位を表す。各

ユーザには必ずユニークなロールが 1 つ割り当てられる。また、

複数のユーザに同じロールを割り当てることもできる。従って、

マッピング・タイプは「N : 1」となる。

2 . ロール -ドメイン

医療関連企業を想定した場合、ある職位（ロール）にある

人物は、たいてい自分の職域の範囲内で仕事をする。各ロ

ールには必ずユニークなドメインが 1 つ割り当てられる。また、

複数のロールに同じドメインを割り当てることもできる。従って、

マッピング・タイプは「N : 1」となる。

3 . サブジェクト -ロール

サブジェクトとは、ユーザに代わって 1 つ以上のトランザクショ

ンを実行するプログラム・エンティティまたはユーザ・エージェ

ントである。サブジェクトが複数のロールによって呼び出され

ることもあり、1 つのロールが複数のサブジェクトを呼び出すこ

ともある。従って、マッピング・タイプは「M : N」となる。

4 . サブジェクト -ドメイン

サブジェクトのオブジェクトに対するアクセスは、ドメインの仲

介によって実施される。各サブジェクトは必ずユニークなドメ

インを 1 つ持つ。また、複数のサブジェクトが同じドメインを持

つこともできる。従って、マッピング・タイプは「N :１」となる。

‐75‐

5 . オブジェクト -オブジェクト･タイプ

オブジェクト・タイプとは、関連情報を扱うオブジェクトの集合

を現す。各オブジェクトは必ずユニークなオブジェクト・タイプ

を 1 つ持つ。また、複数のオブジェクトが同じオブジェクト・タ

イプを持つこともできる。従って、マッピング・タイプは「N : 1」と

なる。

6 . ドメイン -オブジェクト･タイプ - アクセス･モード

各オブジェクト（即ちオブジェクト・タイプ）には、有効なアクセ

ス･モード（C r e a t e、U p d a t e、D e l e t e、Vi e w など）のセット

が関連付けられる。D T E では、サブジェクトのオブジェクトに

対するアクセスは、サブジェクトのドメインとオブジェクトのタイ

プに依存する。どのアクセス･モードが許可されるかは、行に

ドメイン、列にオブジェクト・タイプ、セルにアクセス･モードを

配した D o m a i n - Ty p e A c c e s s M a t r i x によって表される。

従って、マッピング・タイプは「M : N」となる。

ソース・エンティティ : ターゲット・エンティティマッピング・タイプ

ユーザ : ロール N : 1

ロール : ドメイン N : 1

サブジェクト : ロール M : N

サブジェクト : ドメイン N : 1

オブジェクト : オブジェクト･タイプ N : 1

ドメイン -オブジェクト･タイプ : アクセス･モード M : N

表 5 - 1 D A F M AT における承認エンティティのマッピング

‐76‐

図 5 - 4 D A F M AT における承認エンティティ相関図

C . 承認エンティティ間の関係に関する制約

D A F M AT では、任意のエンティティのペアにおいて、そのペアに

課されるマッピングの制約に加え、ペアとなっている各エンティテ

ィと第 3 エンティティとのマッピングの制約が課される。サブジェク

トとロールのペアを例に挙げる。サブジェクトとロールのペアのマッ

ピング・タイプは「M : N 」である。さらに、サブジェクトとドメインおよ

びロールとドメインは、「N : 1」というマッピング・タイプを持つ。従っ

て、サブジェクトとロールのマッピングには「サブジェクトを呼び出

すことのできる全てのロールは、そのサブジェクトに関連付けられ

ているユニークなドメインと関連付けられていなければならない」と

いう制約が課されることになる。

2 . 論理駆動承認エンジン

論理駆動承認エンジンは、複数の承認タイプをサポートするために

使用する。論理駆動承認エンジンは、P r o l o g に似たルールを処理

することができる 1 階述語論理ベースのプロセッサから成る。

論理駆動承認エンジンは、以下の 2 つの機能を有している。

USER

ACCESSMODE

ROLE DOMAIN

SUBJECT OBJECT

DOMAIN-TYPE PAIR

OBJECT-TYPE

N:1 N:1

N:1M:N

M:N

N:1

USER

ACCESSMODE

ROLE DOMAIN

SUBJECT OBJECT

DOMAIN-TYPE PAIR

OBJECT-TYPE

N:1 N:1

N:1M:N

M:N

N:1

‐77‐

1 . ユーザ･アクション（例えば、アプリケーションでメニューオプション

を選択するなど）から、セッション関連機能を利用して承認リクエ

スト・プレディケート（A u t h o r i z a t i o n r e q u e s t p r e d i c a t e）を定

式化する。プライオリティ・コードの値と承認リクエスト・プレディケ

ート内で変化するコンテキストに基づき、リクエストは以下の 3 タ

イプに指定される。

• 正常承認リクエスト

• 緊急承認リクエスト

• コンテキスト・ベース承認リクエスト

2 . 各承認タイプに対してヴァリデーション・コンディション

（ v a l i d a t i o n c o n d i t i o n ）を利用し、現在の承認要求が正当

かどうかを決定する。

論理駆動承認エンジンによって、承認リクエストが正当であると決定さ

れた場合、呼び出されたサブジェクトに該当する適切なドメインが、サブ

ジェクト -ドメインがマッピングされたテーブル通りに、そのユーザのセッショ

ンに割り当てられる。ユーザ・セッションにおいて動作するドメインに基づ

き、実際のオブジェクト・レベルのパーミッションが、ドメイン -タイプ･アクセ

ス･マトリックスから読み取られることになる。


C h a n d r a m o u l i は、自身が提唱する D A F M AT を他の研究者のポリ

シーと比較している。

1 . H o f f m a n のポリシー・モデル

‐78‐

R B A C が様々なタイプのポリシー（最少権限の原則や興味の衝突

など）を表現するために適した高レベルの抽象メカニズムであることを

利用し、さらに、セキュアオペレーティング･システム上の D T E の管

理メカニズムを用いて、これらのポリシーの実装方法について論じた。

しかし、H o f f m a n の実装はユーザ、ロール、サブジェクトおよびドメイ

ン間のスタティックな割り当てに基づいており、オペレーティング･シス

テムの観点からは関連がないという理由で一時情報を組み込むメカ

ニズムを提供していない。

2 . Ti d s w e l l と P o t t e r のアプローチ

ダイナミックに D T E モデルのコンフィギュレーションを変更する方法

を提唱した。ドメイン -タイプ･アクセス･マトリックスを変更し（新たなド

メインおよびタイプを追加、削除、またはドメイン -タイプの組み合わせ

に対するパーミッションを変更する）、その変更は現在のコンフィギュ

レーションのセキュリティ･レベルを維持するという P r o l o g ルールを考

案した。Ti d s w e l l と P o t t e r が考案した方法は、オペレーティング･

システム（特に U N I X）に関連しているため、P r o l o g ルールにコンテ

キスト・ベースの情報を組み込み、ランタイム中にユーザ･パーミッショ

ンに影響を与える必要性がない。

C h a n d r a m o u l i が提唱した D A F M AT は、2 つの点において、上記

のポリシーとは異なる。

1 つ目は、D A F M AT がオペレーティング･システムではなく、アプリケー

ション･システムと深く関連しているという点である。2 つ目は、あらゆる承

認リクエストを 3 つのタイプに分類し、そのタイプに応じて承認 /否認が決

定されるという点である。D A F M AT では、コンテキスト上の情報を含めて、

承認リクエストにはそれぞれ 1 つのタイプが割り当てられ、その承認タイプ

の要件を満たすのに必要な条件がダイナミックにチェックされる。例えば、

‐79‐

ユーザへの仕事の割り当てなどのコンテキスト上の情報を利用して、一

度条件がチェックされると、D T E のサブジェクト -ドメイン・テーブルが、ユ

ーザ・セッションに対して正しいドメインを割り当てるために読み込まれる。

サブジェクトが意図したオペレーションを実行するために必要な実際のパ

ーミッションは、ドメイン -タイプ･アクセス･マトリックスから読み取る。


D A F M AT の特徴は、ユーザとロール、ロールとドメインの関係が

「N : 1 」で定義されることと、論理駆動承認エンジンによりコンテキストが

扱えることである。ユーザとロール、ロールとドメインの関係は「N : 1 」で定

義されるので、ユーザが決まれば、そのドメインも一意に決定される。これ

は、ユーザに実行可能なドメインは 1 つしか存在しないことを示しており、

例外的な処理を行わない限り、静的コンテンツと動的コンテンツを同一

のドメインで処理することを示す。論理駆動承認エンジンとは、上記の

「例外的な処理」を承認する仕組みである。特定の条件が満たされた場

合、論理駆動承認エンジンにより、ロールに割り当てられていないドメイ

ンの付与されたプログラムの実行が許可される。このプログラムは付与さ

れたドメインで動作するため、論理駆動承認エンジンに承認されることで、

本来は実行できないドメインのプログラムを動作させることができる。この

仕組みにより、動的コンテンツと静的コンテンツを、異なるドメインで We b

サーバーに処理させることが可能となる。


る為には、ユーザ、ロール、ドメイン、ドメイン -タイプ･アクセス･マトリックス

の 5 つのポリシー･ファイルを修正する必要がある。D A F M AT では、ユー

ザとロール、ロールとドメインの関係は「N : 1」で定義されるため、ドメインの

追加は、ユーザやロールの要素にも影響を与えることになる。

D A F M AT では、静的コンテンツと動的コンテンツに応じて、異なるドメ

‐80‐

インで We b サーバーを動作させることができる。そのため、C G I、S S I とい

った一般ユーザによって作成された信頼できないプログラムが実行される

場合に、そのプログラムに最少権限を付与することが可能である。しかし、

この利点はプログラムが設定されたドメインで動作する場合に限られる。

D A F M AT には論理駆動承認エンジンの仕組みがあるため、動的コンテ

ンツを攻撃者に改竄された場合には、その動的コンテンツのアクセス可

能な範囲、及び、その動的コンテンツから論理駆動承認エンジンにより

実行が許可されるドメインのアクセス可能な範囲に被害が及ぶ。同様に、

We b サーバーを改竄された場合には、We b サーバーのアクセス可能な

範囲、及び、We b サーバーから論理駆動承認エンジンにより実行が許

可されるドメインのアクセス可能な範囲に被害が及ぶ。

5 .3 PARBAC

A . H e はプライバシー保護の観点から、組織内でプライバシー･ポリシ

ーを強制するためのセキュリティ･ポリシー・モデル、 PA R B A C

（ P r i v a c y - Aw a r e R o l e - B a s e d A c c e s s C o n t r o l ）を提唱した。

PA R B A C は、R B A C の拡張であり、R B A C、D T E およびプライバシー保

護を連結させたモデルである。

5 .3 .1 R B A C と D T E を組み合わせる利点

R B A C は、多種多様な商用セキュリティ要件を満たすことができる柔

軟性を持ち、従来のセキュリティ・モデルと比較してアクセス制御の管理

が容易であり、システムの複雑性、諸経費および人的エラーの削減に有

効である。しかし、R B A C は、プライバシー強制（E n f o r c e m e n t ）におけ

る重要要素であるパーパスなどをモデリングするように設計されていない

ため、プライバシー･ポリシーの強制に直接的に利用することはできない。

R B A C を用いて、プライバシー強制メカニズムを持つコンテキスト・ベー

‐81‐

スのアクセス制御を実現するためには、D T E との組み合わせが必要であ

る。

C h a n d r a m o u l i によって提唱されている D A F M AT は、R B A C と

D T E を組み合わせており、コンテキスト・ベースの承認を利用してプライ

バシー･ポリシーを強制するための基礎構造と言える。しかし D A F M AT

は、パーパスおよびデータ・ポリシーをモデリングしていないため、プライバ

シー･ポリシーを十分に強制できるとは言い難い。そこで、H e が提唱した

のが PA R B A C である。PA R B A C は、C h a n d r a m o u l i の D A F M AT に

おけるアクセス制御構造と K a r j o t h らの研究および P o w e r s らの研究に

おけるプライバシー強制 /管理のアイディアを結合させた拡張 R B A C モ

デルである。

5 . 3 . 1 . 1 ポリシー・モデルの概要

H e が提唱する PA R B A C は、アクセス制御にプライバシー強制 /管理

のアイディアを組み合わせたモデルである。以下では、PA R B A C の概要

を、セキュリティ･ポリシーとプライバシー･ポリシーに分けて解説する。

5 . 3 . 1 . 2 セキュリティ･ポリシー

基本的な構造は D A F M AT を参考にしているが、承認エンティティの

定義や承認エンティティ間のマッピングの関係などが一部異なっている。

PA R A B C の主要承認エンティティは、以下の 7 つである。

1 . ユーザ（U S E R）

2 . ロール（R O L E）

ロールは、組織内の職務権限を表す。

3 . サブジェクト（S U B J E C T）

ビジネス・プロセス機能を実行するために、ユーザが特定のロー

‐82‐

ルで呼び出すプログラム、ユーザ・エージェントまたは実行ファイ

ルを表す。

4 . ドメイン（D O M A I N）

ロールが機能する企業の高レベルな機能領域を表す。

5 . パーパス（P U R P O S E）

オペレーションを実行する目的を表す。パーパス同士は、ロール

のヒエラルキー関係のような、半順序の関係を持つ。半順序の

関係とは、再帰的、推移的かつ半対称的な関係である。

図 5 - 5 パーパス・ヒエラルキー例

任意のパーパスに対するオペレーションが許可されると、そのパ

ーパスのサブ・パーパスに対するオペレーションも許可される。上

図では、E m a i l M a r k e t i n g、p o s t a l M a r k e t i n g、P h o n e / F a x

M a r k e t i n g は、 D i r e c t M a r k e t i n g および 3 r d P a r t y

M a r k e t i n g のサブ・パーパスである。

例えば、顧客が E m a i l M a r k e t i n g に対してのみ個人情報を利

用することを承諾した場合、 E m a i l M a r k e t i n g が D i r e c t

M a r k e t i n g と 3 r d P a r t y M a r k e t i n g の両方に属しているため、

｛Φ｝

Marketing

3rd partyMarketing

DirectMarketing

EmailMarketing

PostalMarketing

Phone/FaxMarketing

｛Φ｝

Marketing

3rd partyMarketing

DirectMarketing

EmailMarketing

PostalMarketing

Phone/FaxMarketing

‐83‐

システムは E m a i l M a r k e t i n g が属する一意の親パーパスを決

定することができない。このような両義的なパーパス参照を避ける

ために、PA R B A C モデルのサブジェクトは、パーパス・ヒエラルキ

ーの低いレベルにマッピングする必要がある。

さらに、H e はタスク（Ta s k）というエンティティを導入した。タスクは、

ロールとパーミッションの間を仲介する役割を持つエンティティで、

パーパス・ヒエラルキーに類似したタスク・ネットワークというヒエラ

ルキーを持つ。仮にタスクを使わず、パーパスとロール -パーミッシ

ョンのペアとに直接的な関連性を持たせた場合、一意に正しい

パーパスを決定できない可能性がある。例えば、配送部門のロ

ール A とマーケティング部門のロール B が、それぞれ別の目的で

顧客連絡先情報にアクセスするパーミッションを持っていた場合

を例に挙げる。あるユーザがロール A とロール B に任命され、顧

客連絡先情報にアクセスすると、システムはこのオペレーションが

配送部門のパーパスに対するものなのか、マーケティング部門の

パーパスに対するものなのかを判断することができない。これを避

けるために導入されたのがタスクであり、パーパス・ヒエラルキーの

場合と同じ理由から、サブジェクトはタスク・ネットワークの低いレ

ベルにマッピングする必要がある。

6 . オブジェクト･タイプ（O B J E C T- T Y P E）

関連する情報を扱い、類似した手法で処理され得るオブジェク

トのグループを表す。

7 . オブジェクト・ポリシー（O B J E C T- P O L I C Y）

実際のデータ利用ポリシーを表す。

‐84‐

エンティティ間の関係は、ソース・エンティティからターゲット･エンティテ

ィへの「多対多（M : N ）」、「多対一（N : 1）」、「一対多（1 : N ）」、「一対一

（1 : 1）」の関係のいずれかに分類される。

1 . ユーザロール

1 つのユーザに複数のロールを割り当てることができ、1 つのロー

ルに複数のユーザを割り当てることができる。従って、ユーザとロ

ールは「M : N」の関係にある。

2 . ロール -ドメイン

1 つのロールは必ず 1 つのユニークなドメインと関連付けられる。

1 つのドメインに複数のロールを関連付けることができる。従って、

ロールとドメインは「N : 1」の関係にある。

3 . ロール -タスク

1 つのタスクは必ず 1 つのユニークなロールに割り当てられる。1

つのロールは複数のタスクを実行することができる。従って、ロー

ルとタスクは「1 : N」の関係にある。

4 . サブジェクト -ロール

サブジェクトは、あるタスクを実行するために 1 つ以上のロールに

よって呼び出される。ロールは指定されたタスクを実行するため

に複数のサブジェクトを呼び出す必要がある。従って、サブジェ

クトとロールは「M : N」の関係にある。

5 . サブジェクト -ドメイン

サブジェクトの実行動作は、割り当てられているドメインに基づい

て規定されるため、1 つのサブジェクトは必ず 1 つのユニークなド

メインと関連付けられる。複数のサブジェクトが同じドメインを持

つこともできる。従って、サブジェクトとドメインは「N : 1 」の関係に

ある。

‐85‐

6 . サブジェクト -タスク

1 つのサブジェクトは複数のタスクと関連付けることができる。

PA R B A C モデルでは、サブジェクトは、常にタスク・ネットワークの

最低レベルのタスクと関連付ける必要があるので、1 つのタスクを

実行するために、複数のサブジェクトを呼び出す場合もある。従

って、サブジェクトとタスクは「N : 1」の関係にある。

7 . タスク -パーパス

通常、1 つのタスクは複数のパーパスと関連付けることができる。

しかし、PA R B A C モデルでは、タスクは、常にパーパス・ヒエラル

キーの最低レベルのパーパスと関連付ける必要があるので、複

数のタスクが 1 つのパーパスに関連付けられる場合もある。従っ

てタスクとパーパスは「N : 1」の関係にある。

8 . オブジェクト -オブジェクト･タイプ

1 つのオブジェクトは必ず 1 つのユニークなオブジェクト・タイプを

持ち、複数のオブジェクトが同じオブジェクト・タイプを持つことも

できる。従って、オブジェクトとオブジェクト・タイプは「N : 1 」の関

係にある。

9 . オブジェクト -オブジェクト・ポリシー

1 つのオブジェクトは必ず 1 つのユニークなオブジェクト・ポリシー

を持つ。1 つのオブジェクト・ポリシーは必ず１つのユニークなオブ

ジェクトを持つ。従って、オブジェクトとオブジェクト・ポリシーは

「1 : 1」の関係にある。

1 0 . D T E エントリ（ドメイン、オブジェクト・タイプ、アクセス・モード）

ドメインとオブジェクト・タイプのペアは、D o m a i n Ty p e A c c e s s

M a t r i x と呼ばれるテーブルに保存される。ドメインとオブジェク

ト・タイプの 1 ペアは、アクセス・モードの集合と関連付けられてい

る。従って、ドメイン -オブジェクト・タイプのペアとアクセス・モード

は「M : N」の関係にある。

‐86‐

1 1 . ロール -ロール

ロール・ヒエラルキー内のロール同士は半順序の関係にあり、例

えばロール 1 とロール 2 があった場合、ロール 1 はロール 2 のス

ーパー・ロールとなる。ロール同士は「M : N 」の関係にある。

1 2 . タスク -タスク

タスク・ネットワーク内のタスク同士は半順序の関係にあり、例え

ばタスク 1 とタスク 2 があった場合、タスク 1 はタスク 2 のスーパ

ー・ロールとなる。タスク同士は「M : N」の関係にある。

1 3 . パーパス -パーパス

パーパス・ヒエラルキー内のパーパス同士は半順序の関係にあ

り、例えばパーパス 1 とパーパス 2 があった場合、パーパス 1 は

パーパス 2 のスーパー・ロールとなる。パーパス同士は「M : N」の

関係にある。

ソース・エンティティ : ターゲット・エンティティマッピング・タイプ

ユーザ : ロール M : N

ロール : ドメイン N : 1

ロール : タスク 1 : N

サブジェクト : ロール M : N

サブジェクト : ドメイン N : 1

サブジェクト : タスク N : 1

タスク : パーパス N : 1

オブジェクト : オブジェクト･タイプ N : 1

ドメイン -オブジェクト･タイプ : アクセス･モー

ド

M : N

ロール : ロール M : N

‐87‐

タスク : タスク M : N

パーパス : パーパス M : N

表 5 - 2 R E R B A C におけるエンティティのマッピング

図 5 - 6 PA R B A C モデル構造

さらに、これらのエンティティの関係は、以下の 3 つの制約によって制

限されている。

• 制約 1 :

あるサブジェクトを呼び出すことができる全てのロールには、サブジ

ェクトと関連付けられているユニークかつ同じドメインが割り当てら

れていなければならない。

• 制約 2 :

2 つのタスクを実行するために、同じサブジェクトを呼び出す必要

がある場合、 2 つのタスクは同じパーパスにマッピングされなけれ

USER

ACCESSMODE

ROLE DOMAIN

SUBJECT OBJECT

DOMAIN-TYPE PAIR

OBJECT-TYPE

M:N N:1

N:1M:N

M:N

N:1

TASK

PURPOSE OBJECTPOLICY

1:1

N:1

1：N

N:1

M:N

M:N

※ 網掛け部は、PARBACにおいて新たに導入されたエンティティを表す。

USER

ACCESSMODE

ROLE DOMAIN

SUBJECT OBJECT

DOMAIN-TYPE PAIR

OBJECT-TYPE

M:N N:1

N:1M:N

M:N

N:1

TASK

PURPOSE OBJECTPOLICY

1:1

N:1

1：N

N:1

M:N

M:N

※ 網掛け部は、PARBACにおいて新たに導入されたエンティティを表す。

‐88‐

ばならない。

• 制約 3 :

ロールがあるタスクの実行を許可されており、そのタスクを完遂す

るためにサブジェクトを呼び出す必要がある場合に限り、ロールを

サブジェクトと関連付けることができる。

PA R B A C においてデータ・アクセスの目的（パーパス）は、各承認エン

ティティから推測することが可能である。例えば、あるビジネス・プロセスを

実行するためにユーザがサブジェクトを呼び出した場合、まずサブジェク

トはタスク･ネットワーク内の最低レベルにある 1 つのユニークなタスクにマ

ッピングされる。次にそのタスクがパーパス・ヒエラルキー内の最低レベル

にある 1 つのユニークなパーパスにマッピングされる。このようなプロセスに

より、パーパスが特定される。

5 . 3 . 1 . 3 プライバシー･ポリシー

H e が提唱する PA R B A C では、K a r j o t h らが提唱した t h e P l a t f o r m

f o r E n t e r p r i s e P r v a c y P r a c t i c e s 3 (以下 E - P 3 P とする )および

P o w e r s らが発表した論文「P r i v a c y P r o m i s e s , A c c e s s C o n t r o l ,

a n d P r i v e c y M a n a g e m e t」に見られる基礎的なプライバシー強制やプ

ライバシー管理のアイディアを採用している。

E - P 3 P では、プライバシー･ポリシーの強制方法としてメタデータに基

づくアプローチ法 4を採用している。E - P 3 P には、（1 ）アクセス制御上に

3 顧客のプライバシーを保護しながら、顧客データを管理・交換する

ための技術。プライバシー・オフィサー、セキュリティ・オフィサー、カスタマ

の 3 つのロールによってシステム内の責務を分離し、アクセス制御とプライバシー制御の両方に基づく承認付与を実行する。

4 プライバシー・ポリシの強制方法の 1 つ。メタデータに基づくアプローチ法では、まずデータの利用法に関するタグなどのメタデータを各データ

‐89‐

プライバシー強制が構築されているので、企業のレガシー・アプリケーショ

ンに適応可能、（2）プライバシー制御とアクセス制御を分離しているので、

フレキシビリティが向上、（3）3 つのロールに責務を分離したことで、大企

業での容易なプライバシー管理が可能、といった利点がある。H e は、

E - P 3 P の利点を評価しながらも、システムのプライバシー･ポリシーの強

制方法は、そのシステムが採用するアクセス制御モデルの影響を受ける

ため、プライバシー制御はアクセス制御と共に考えなければならないと主

張している。そこで、PA R B A C では詳細なアクセス制御モデルをベースと

してプライバシー強制を実現した。

P o w e r s らによる論文「P r i v a c y P r o m i s e s , A c c e s s C o n t r o l , a n d

P r i v e c y M a n a g e m e n t 」において一般的なプライバシーポリシー・ルー

ルは以下のように解説されている。

ALLOW [Data User]

to perform [Operation] on [Data Type]

for [Purpose] provided [Condition]

Carry out [Obligation]

[ ] 内の各要素については以下の通りである。

• D a t a Ty p e

プライバシー･ポリシーでは、顧客データを、連絡先や購入履歴

のように、性質に応じて分類されたデータ集合として扱うことが多

い。その分類ラベルがデータ・タイプである。

• P u r p o s e

パーパスとはデータを利用する目的である。

集合に関連付け、サブジェクトがあるデータへのアクセス要求をした場合、

メタデータをチェックし、オペレーション実行の許可を決定する。

‐90‐

• C o n d i t i o n

プライバシー･ポリシーでは、特定の条件が満たされなければデー

タにアクセスできない場合がある。この場合の「特定の条件」がコ

ンディションである。例えば、プライバシー･ポリシーが「私の連絡

先情報はトランザクションの完了のために利用できるが、情報の

利用期限は 3 0 日である」という場合、「情報の利用期限は 3 0

日である」がコンディションである。

• O b l i g a t i o n

プライバシー･ポリシーでは、あるアクセスが許可された場合に、別

のオペレーションを実行しなければならない場合がある。この場合

の「別のオペレーションの実行」がオブリゲーションである。例えば、

プライバシー･ポリシーが「私の連絡先情報はトランザクションの完

了のために利用できるが、3 0 日以内に削除しなければならない」

である場合、「3 0 日以内に顧客の連絡先情報を削除する」がオ

ブリゲーションである。

H e は、このプライバシー･ポリシー・ルールの考え方を参考にし、

PA R B A C において以下のようなプライバシー強制の承認プロセスを構

築した。

1 . ユーザがプライバシー保護されたデータにアクセスした場合に、

アクセス制御チェックおよび該当データ・ポリシーの読み出しが

実行される。

2 . データ･ポリシーから読み出されたパーパスがチェックされる。

3 . コンディションが設定されている場合は、コンディションのチェック

を実行する。

4 . オブリゲーションが設定されている場合は、オブリゲーション実行

モジュールによりオブリゲーションを実行する。

‐91‐

5 . アクセスを監査ログに書込む。

図 5 - 7 PA R B A C の承認プロセス


組織の視点に立ったシステムセキュリティに加え、消費者の視点に立

った顧客のプライバシー強制 /管理機能を組み込んだ点が PA R B A C の

最大の特徴と言うことができる。より具体的には、それまでの R B A C には

なかったパーパス、タスク、オブジェクト・ポリシーというエンティティを導入

したことが特徴的である。

しかしながら、メタデータに基づくアプローチ法を採用しており、トラステ

ユーザ・リクエスト

ロール/パーミッションのチェック

パーパスのチェック

コンディションのチェック

オブリゲーションの実行

アクセス許可

アクセス拒否

オブリゲーションのチェック

監査ログへ書込み

終了

データポリシの読み出し許可

No

No

No

No

Yes

Yes

Yes

Yes

ユーザ・リクエスト

ロール/パーミッションのチェック

パーパスのチェック

コンディションのチェック

オブリゲーションの実行

アクセス許可

アクセス拒否

オブリゲーションのチェック

監査ログへ書込み

終了

データポリシの読み出し許可

No

No

No

No

Yes

Yes

Yes

Yes

‐92‐

ッド・システム上に構築することを前提としているので、プライバシー・コン

プライアンスを保障する事ができない。オブジェクトの利用制御に使用す

るオブジェクト・ポリシーを、悪意あるアプリケーションまたはユーザが変更

してしまった場合には、プライバシー強制を保障することは不可能である。

さらに、PA R B A C では全てのプライバシー問題に対処できるわけではな

い。対象にしているのは、収集された顧客データのプライバシー保護であ

り、データ･マイニングによるプライバシー侵害や匿名性の問題を解決す

ることはできない。


PA R B A C の特徴は、タスク、パーパスとオブジェクト･ポリシーの要素が

追加されていることである。ロールとドメインの関係は「N : 1 」で定義される

ので、ロールによってドメインが一意に決定される。つまり、ロールの実行

可能なドメインは 1 つしか存在しないので、静的コンテンツと動的コンテ

ンツを同一のドメインで処理しなければならない。しかし、PA R B A C では、

タスク、パーパス、オブジェクト･ポリシーによって同一ドメイン内で異なる

オブジェクトの使われ方を定義することができる。そのため、静的コンテン

ツと動的コンテンツは、同一のドメインで動作しながらも、異なるアクセス

制御を受けることになる。

タスク、パーパス、オブジェクト･ポリシーを使い、同一ドメイン内に異な

るアクセス制御を導入する場合、タスク、パーパス、オブジェクト･ポリシー

とドメイン -タイプ･アクセス･マトリックスの 4 つのポリシー･ファイルを修正す

る必要がある。PA R B A C では、タスク、パーパス、オブジェクト･ポリシーと

いった新しい要素が追加されたため、ドメインやタイプの修正は必要ない

ものの、それらの新しい要素に対する設定が必要となる。

PA R B A C では、タスク、パーパス、オブジェクト･ポリシーを使い、同一

ドメイン内で異なるアクセス制御を実現できる。そのため、C G I、S S I とい

‐93‐

った一般ユーザによって作成された信頼できないプログラムが実行される

場合に、そのプログラムに最少権限を付与することが可能である。動的

コンテンツが攻撃者により改竄された場合にも、動的コンテンツのタスクと

パーパスでアクセス可能なオブジェクト、及び、その動的コンテンツから外

部実行可能なプログラムのタスクとパーパスでアクセス可能なオブジェクト

が攻撃範囲となる。同様に、We b サーバーが改竄された場合には、

We b サーバーのタスクとパーパスでアクセス可能なオブジェクト、及び、

We b サーバーから外部実行可能なプログラムのタスクとパーパスでアクセ

ス可能なオブジェクトが攻撃範囲となる。

ところで、PA R B A C はデータのプライバシーの保護を目的とした機能

も持つ。これらは、「C o n d i t i o n 」や「O b l i g a t i o n 」といった機能を使い

実現される。例えば、PA R B A C が実装されたシステムでは、3 日間だけ

閲覧できるデータを作成することができる。PA R B A C は、R B A C と T E で

実現されるセキュリティ保護機能に加え、これらのプライバシーの保護機

能を持っている。

このようなプライバシー保護の機能を We b サーバーに適応させる場合

を考える。We b のようなシステムでは、サーバーのデータをクライアントに

対して開示するため、PA R B A C の管理外にデータを送信することになる。

そのため、サーバー内で 3 日間だけ閲覧できる We b ページを作成するこ

とはできても、クライアントのキャッシュに残る We b ページを 3 日後に閲覧

不能にすることはできない。クライアントを含めて PA R B A C の実装がなさ

れた場合には、クライアントに残されるキャッシュやクッキーを含めた、非

常に厳格なデータの管理が可能になるが、We b のようなシステムでは、

悪意のあるクライアントの想定が当然であるため、そもそも、PA R B A C に

よって実現されるプライバシー保護の側面は、We b システムには適応し

ない。

‐94‐

5 .4 SELinux SPM

S E L i n u x はオープンソースで開発されているセキュアオペレーティン

グ･システムである。

高度なアクセス制御機能を備え、他のセキュアオペレーティング･シス

テムと比べてもきめ細かい設定が行える。また、L i n u x カーネル 2 . 6 より、

カーネルそのものに組み込まれているため、導入時のコストが軽減され

る。

S E L i n u x の大きな特徴として、S E L i n u x はカーネル 2 . 6 より実装さ

れた L S M ( L i n u x S e c u r i t y M o d u l e s）の仕組みを使って実装されるカ

ーネルモジュールであることが挙げられる。L S M とは、カーネルよりアクセ

ス制御に関する処理をモジュールに任せる仕組みであり、L S M を使うこ

とで、複数の異なるセキュアオペレーティング･システム（モジュール）を自

在に組み込むことが可能となる。また、モジュールを組み込むだけで、従

来の L i n u x 環境より、セキュアな環境に移行できるメリットがある。


S E L i n u x に実装されているアクセス制御の基本的な仕組みは、以

下のモデルで説明される。

あるプロセスがリソースに対してアクセスをする場合、図 5 - 8 のように、

まずは従来の L i n u x が持つ D A C（D i s c r e t i o n a r y A c c e s s C o n t r o l ）

と呼ばれるアクセス制御が行なわれる。D A C とは、U N I X に標準で実装

されている仕組みで、パーミッションビットを使用することによりアクセス制

御が実現される。D A C では、ユーザ自身が所有するファイルやディレクト

リは、ユーザ自身、ユーザの所属するグループ、他人に対して、それぞれ

の読み取り、書き込み、実行権限が設定される。このチェックをパスする

と、S E L i n u x モジュールに処理が移り、S E L i n u x 独自のアクセス制御

が行なわれる。

‐95‐

図 5 - 8 D A C と S E L i n u x モジュールの関係


S E L i n u x は、 R o l e - B a s e d A c c e s s C o n t r o l ( R B A C ) と Ty p e

E n f o r c e m e n t ( T E )を組み合わせたセキュリティ･ポリシー･モデルを採用

する。R B A C は、ユーザに与えられた権限を役割に応じて分割し、必要

最小限の権限行使を強制する。T E は、プロセスの粒度でアクセス権限

を厳格に管理することができる。セキュリティ･ポリシー･モデルを図 5 - 9

に示す。

ユーザは、U N I X におけるユーザ･アカウントにマッピングされる。ロール

は、ユーザに付与する属性で、各ユーザには、複数のロールを割り当て

ることができる。各ロールには、アクセス権限範囲を示すドメインを割り当

てる。サブジェクトは、U N I X におけるプロセスを指し、各プロセスは、プロ

セスを起動したユーザのロールにより決定されるドメインが付与される。ア

プロセスプロセス

DAC（従来のパーミッション

チェック）


チェック）

リソースリソース

SELinuxモジュールSELinuxモジュール



チェック）


チェック）


SELinuxモジュールSELinuxモジュール

‐96‐

クセス対象となるオブジェクトは、U N I X におけるプログラムファイル、デー

タファイル、ディレクトリやデバイス等の特殊ファイルを含む。各オブジェク

トは、アクセスを許可する権限範囲を示すオブジェクト・タイプを付与する。

アクセス・ベクターは、アクセスの種類を示し、単純なファイル I / O やプロ

グラムの実行からデバイスへの特殊アクセス等、様々なアクセス形態を示

すことが可能である。アクセス制御設定は、アクセス主体の権限範囲を

示すドメイン、アクセス対象の種類を示すオブジェクト・クラス、アクセス対

象の権限範囲を示すオブジェクト・タイプの組み合わせにより記述する。

プログラム起動時におけるプロセスの既定のドメインは、プログラムを起

動したプロセスのドメインが継承される。ただし、プログラムを起動したプロ

セスのドメインとプログラムファイル（エントリーポイント）に付与されたオブ

ジェクト・タイプの組み合わせにより記述されたポリシーにより、既定のドメ

イン以外のドメインを付与すること（ドメイン遷移）を強制することができる。

図 5 - 1 0 にドメイン遷移の流れを示す。U N I X では、プログラム起動プロ

セスを f o r k と e x e c の 2 つのシステムコールにより実現している。 f o r k シ

ステムコールは、プロセスの複製を作成する機能を持ち、複製されたプロ

セスは、複製元と同じドメインが付与される。e x e c システムコールはプログ

ラムファイルを実行する機能を持ち、目的のプログラムを複製されたプロ

セスで実行する。ドメイン遷移は「遷移元のドメイン』、「プログラムファイル

（エントリーポイント）のオブジェクト・タイプ』、「遷移後のドメイン』で規定さ

れ、特定の組み合わせでプログラムが実行されると、e x e c システムコール

が実行される際にドメインが強制的に遷移させられる。

ドメイン遷移の具体例として、ユーザがシェルよりコマンドを実行する

場合を考える。ユーザはログインする際に割り当てられるロールか、または

明示的にロールを指定することで、操作に必要な最小の権限を持つロ

ールがアクティブにされている。また、ユーザのシェルプロセスはロールに

割り当てられたドメインで起動される。ここで、ユーザがドメイン遷移を起こ

すようなプログラムファイルを実行した場合、まず f o r k によって同じドメイ

‐97‐

ンで動作するプロセスが複製される。そして、 e x e c 命令により複製された

プロセス内で指定されたプログラムファイルが実行される。この際、プログ

ラムファイル（エントリーポイント）のオブジェクト･タイプとプロセスのドメイン

の組み合わせがドメイン遷移のポリシー･ファイルに記述されていると、複

製されたプロセスは記述されたドメインに強制的に遷移させられる。

例として、専用のエディタを使って顧客データを編集する場合を想定

して、アクセス制御の仕組みを説明する。ユーザは、ログイン時もしくは、

顧客データの編集作業に先だって、適切なアクセス権限を持つロール

を選択する。ロールを選択することにより、ユーザ･プロセスのドメインがロ

ールに割り当てられたドメインに変更される。ユーザがエディタを起動する

と、ドメイン遷移が起きなければ、ロールと同じドメインでエディタは起動さ

れる。このドメインで起動したエディタは、顧客データに対して、ポリシー･

ファイルによって許可された操作（読み込み、書き込み等）を実行でき

る。

S E L i n u x の S P M の特徴としては、“ドメイン遷移 ”と、“ロールとドメイ

ンの対応関係 ”の 2 つが挙げられる。

ドメイン遷移は、「遷移元のドメイン」、「実行ファイル（エントリーポイン

ト）のオブジェクト･タイプ」、「遷移後のドメイン」によって遷移後のドメイン

が決定される。全てのプロセスには、セキュリティ･コンテキストと呼ばれる

「ユーザ」、「ロール」、「ドメイン」の情報が付加されているが、そのプロセ

スがどのドメインに遷移するかは、「ロール」や「ユーザ」に影響されない。

そのため、ユーザが使用可能なドメインの範囲が分かり難い。また、遷移

する可能性のあるドメインを特定するには、遷移元のドメインとプログラム

中で実行される外部コマンドをキーにして、ドメイン遷移の設定ファイル

を調べていく必要がある。

ロールとドメインの N 対 1 の対応関係も重要な特徴に挙げられる。

H o f f m a n の S P M のように、ロールとドメインが N 対 M の関係にあり、プ

ログラムファイル（サブジェクト）とドメインが N 対 1 の関係にある場合、プ

‐98‐

ログラムファイル（サブジェクト）は、1 つのドメインしか付与されない。この

ため、プログラムが多くの機能を持っている場合には、それら全ての機能

で必要な権限をドメインに与えなければならない。対して、ロールとドメイ

ンが N 対 1 の関係にあり、サブジェクトのドメインはドメイン遷移によって

決まる S E L i n u x の S P M は、プログラムを呼び出すプロセスのドメインに

応じて、遷移後のドメインは変更される。これにより、汎用的なプログラム

に対して、より柔軟なアクセス制限を設定する事が可能になる。

図 5 - 9 S E L i n u x のセキュリティ･ポリシー･モデルの構造

• S U B J E C T の D O M A I N が決まる過程

（ドメイン D 1 を割り振られたロールで作業するユーザが、タイプ T 1 を

割り当てられたファイルを実行し、新たなプロセスを起動する場合）

USER

ACCESSVECTOR

ROLE DOMAIN

D-T-C

OBJECT-CLASS

M:N N:1

M:N:O

N:1N:1

OBJECT-TYPE

OBJECTSUBJECT

USER

ACCESSVECTOR

ROLE DOMAIN

D-T-C

OBJECT-CLASS

M:N N:1

M:N:O

N:1N:1

OBJECT-TYPE

OBJECTSUBJECT

‐99‐

図 5 - 1 0 サブジェクトのドメインが決まる過程


S E L i n u x のセキュリティ･ポリシー・モデルの特徴は、ドメイン遷移の機

能を持つことである。ドメイン遷移は、サブジェクトのドメインを決定する仕

組みであり、「 5 . 4 . 2 ポリシー・モデルの特徴」で説明したような機能を持

つ。例えば、ファイルの中身を表示するプログラムは、遷移元のドメインに

よってプロセスのドメインが変化する。これにより、遷移元のドメイン毎に

異なったアクセス制御を設定できる。例えば、ファイルの中身を表示する

プログラムを使い、一般のユーザがパブリックなファイルにアクセスする場

合と、管理者がシステムファイル･アクセスする場合では、プログラムの目

的が異なっている。ドメイン遷移の仕組みは、このような目的に応じたア

クセス制御の変更を実現する。また、ユーザとロールの関係が「M : N 」で、

ロールとドメインの関係が「N : 1」で定義されるため、ユーザは複数のドメイ

ンを使用することができる。


SUBJECT

ドメイン D1

OBJECTタイプ T1

ドメイン遷移

プロセスを複製する

fork() SUBJECT

ドメイン D1

SUBJECT

ドメイン Dx

プログラムを実行する

exec()

SUBJECT

ドメイン D1

OBJECTタイプ T1

ドメイン遷移

プロセスを複製する

fork() SUBJECT

ドメイン D1

SUBJECT

ドメイン Dx

プログラムを実行する

exec()

‐100‐

る為には、ドメイン、ドメイン遷移、オブジェクト･タイプとドメイン -タイプ･ア

クセス･マトリックスの 4 つのポリシー･ファイルを修正する必要がある。

S E L i n u x のセキュリティ･ポリシー･モデルでは、ドメインを追加することで、

ドメイン遷移の設定も追加する必要がある。

S E L i n u x のセキュリティ･ポリシー･モデルでは、静的コンテンツと動的

コンテンツに応じて、異なるドメインで We b サーバーを動作させることがで

きる。そのため、C G I、S S I といった一般ユーザによって作成された信頼

できないプログラムが実行される場合に、そのプログラムに最少権限を付

与することが可能である。しかし、この利点はプログラムが設定されたドメ

インで動作する場合に限られる。S E L i n u x のセキュリティ･ポリシー･モデ

ルではドメイン遷移の仕組みがあるため、動的コンテンツを攻撃者に改

竄された場合には、その動的コンテンツのアクセス可能な範囲、及び、そ

の動的コンテンツからドメイン遷移可能なドメインのアクセス可能な範囲

に被害が及ぶ。同様に、We b サーバーを改竄された場合には、We b サ

ーバーのアクセス可能な範囲、及び、We b サーバーからドメイン遷移可

能なドメインのアクセス可能な範囲に被害が及ぶ。

ドメイン遷移の欠点は、ドメインとサブジェクトのマッピングが静的に表

せないことである。一見しただけでは、プログラムが遷移する可能性のあ

るドメインは判別できない。ドメイン遷移の設定に間違いがあれば、思わ

ぬドメインに遷移可能な動的コンテンツがユーザによって作成されてしま

う。

5 .5 Trusted So lar i s SPM

Tr u s t e d S o l a r i s は、サン・マイクロシステムズ社によって開発されて

いるセキュリティ機能が強化されたオペレーティング･システムである。

S o l a r i s に比べ、ユーザの階層ごとに参照できるデータが異なる組織

や、重要なデータを扱う場合に適している。

‐101‐


Tr u s t e d S o l a r i s に実装されているアクセス制御の基本的な仕組み

を説明する。

Tr u s t e d S o l a r i s では、D A C と M A C を組み合わせたアクセス制御

が行われる。例えば、あるユーザがファイルを参照するには、 D A C と

M A C のそれぞれに反していないことが条件となる。

図 5 - 11 D A C と M A C


Tr u s t e d S o l a r i s は M u l t i - l e v e l S e c u r i t y（M L S )と R o l e - B a s e d

A c c e s s C o n t r o l ( R B A C )を組み合わせたセキュリティ･ポリシー･モデル

を採用する。M L S は全てのサブジェクトとオブジェクトに機密ラベル



チェック）


チェック）


MAC（ラベルに基づくアク

セス制御）


セス制御）



チェック）


チェック）



セス制御）


セス制御）

‐102‐

（S E N S I T I V I T Y- L A B E L ）を付与し、機密ラベルを比較することでアク

セス制御を行う。Tr u s t e d S o l a r i s の R B A C は従来の L i n u x の管理

者（ r o o t ）の持つ権限を、幾つかのロールに分散させる。 Tr u s t e d

S o l a r i s のセキュリティ･ポリシー･モデルを図 5 - 1 3 に示す。

ユーザは、U N I X におけるユーザ･アカウントにマッピングされる。ロール

は、特殊なユーザ･アカウントであり、ユーザはシステムにログイン後、所定

の手続きを経ることでロールを有効にすることの認証を受けられる。サブ

ジェクトは U N I X におけるプロセスを指し、オブジェクトはアクセス対象の

ファイルを指している。特権は M A C に制限されない例外的なアクセス許

可を示し、セキュリティ･ポリシーを編集可能な特別なプログラムファイル

などに付与される。

Tr u s t e d S o l a r i s の機密ラベル（S E N S I T I V I T Y- L A B E L ）は、階

層的な格付け（ C L A S S F I C AT I O N ）と平行的なコンパートメント

（ C O M PA R T M E N T ）の 2 つで表される。コンパートメント

（C O M PA R T M E N T ）とは区画を示しており、リソースを幾つかの分類に

分けるために使用される。対して、格付け（C L A S S F I C AT I O N ）は階層

を示しており、リソースの保護のレベルを設定するために使用される。

コンパートメントとして「コンパートメント A」、「コンパートメント B」を設定

し、格付けとして「 T O P S E C R E T 」、「 S E C R E T 」、

「C O N F I D E N T I A L 」、「U N C L A S S F I E D 」と設定した場合、機密ラベ

ルは、以下のように「格付け＋コンパートメント」で表記される。

‐103‐

コンパートメント A コンパートメント B

TO P S E C R E T TO P S E C R E T A TO P S E C R E T B

S E C R E T S E C R E T A S E C R E T B

C O N F I D E N T I A L C O N F I D E N T I A L A C O N F I D E N T I A L B

U N C L A S S F I E D U N C L A S S F I E D A U N C L A S S F I E D B

表 5 - 3 機密ラベルの例

機密ラベルには複数のコンパートメントの記述することができ、「T O P

S E C R E T A B」という表記が許される。この例では、「T O P S E C R E T」

は格付けを示し、「A」と「B」は 2 つのコンパートメントが付与されているこ

とを示す。

アクセス制御が行われる際、サブジェクトとオブジェクトの機密ラベルが

比較される。例として、「 S E C R E T A 」のサブジェクトが、

「C O N F I D E N T I A L A 」のオブジェクトにアクセスする場合考える。この

際、サブジェクトの格付けはオブジェクトのそれより優位にあるため、アク

セスが許可される。

図 5 - 1 2 格付けとアクセス可能範囲

TOP SECRETTOP SECRET

SECRETSECRET

CONFIDENTIALCONFIDENTIAL

UNCLASSIFIEDUNCLASSIFIED

High

Low

SECRETの格付けのサブジェクト

SECRETの格付けの

サブジェクト

×TOP SECRETTOP SECRET

SECRETSECRET

CONFIDENTIALCONFIDENTIAL

UNCLASSIFIEDUNCLASSIFIED

High

Low

SECRETの格付けのサブジェクト

SECRETの格付けの

サブジェクト

×

‐104‐

次に「C O N F I D E N T I A L B 」のオブジェクトにアクセスする場合を考

える。この場合も、サブジェクトの格付けは優位であるが、コンパートメント

が異なるためアクセスは許可されない。しかし、「S E C R E T A B 」のラベ

ルを持つサブジェクトは「C O N F I D E N T I A L B 」のラベルを持つオブジ

ェクトを参照することが許可される。コンパートメントに関しては、オブジェ

クトのコンパートメントがサブジェクトのコンパートメントに含まれている場合

に上位の機密ラベルであると考えられる。

以上のような規則によって、サブジェクトとオブジェクトに付与される機

密ラベルは比較され、以下のような操作が許可される。

• 参照

あるサブジェクトが参照できるオブジェクトは、そのサブジェクトと同等

か下位のラベルを持ったオブジェクトである。

• 書き込み

あるサブジェクトが書き込みできるオブジェクトは、そのサブジェクトと同

等のラベルを持ったオブジェクトである。下位のラベルを持つオブジェ

クトに対して書き込みは許可されない。

• 追記

あるサブジェクトが追記できるオブジェクトは、そのサブジェクトと同等

か上位のラベルを持ったオブジェクトである。

ユーザは、システムにログインした際に、そのセッションで使用する認可

上限が設定される。認可上限とは、ユーザの使用するラベルのうち最優

位のもので、指定した認可上限内の操作がユーザに許可される。セキュ

リティ･ポリシー･ファイルを編集する場合、特殊なアカウントであるロール

が使用される。この際、特権を割り当てられたプログラムファイルを起動

‐105‐

するために、ロールは承認をされていなければならない。特権を付与され

たすべてのプログラムファイルは、承認されたユーザ、または、ロールから

のみ実行される。このような承認は管理者によって、あらかじめ付与され

る。

Tr u s t e d S o l a r i s のセキュリティ･ポリシー･モデルの特徴は、特権付

きプログラムを実行する必要のない一般ユーザのアクセス可能なファイル

が、一見して分かるということが挙げられる。S E L i n u x のドメイン遷移と

異なり、ユーザは特権付きプログラムを実行する以外は、認可上限を超

えて操作を行なうことは許されない。同時に、特権と認証さえ与えられて

いれば、あらゆる機密ラベルに横断的にアクセスすることが許可される。

また、どのようなアクセスが許可されているかを把握するためには、ポリシ

ー･ファイルを参照する必要がある。

‐106‐

図 5 - 1 3 Tr u s t e d S o l a r i s のセキュリティ･ポリシー･モデルの構造


Tr u s t e d S o l a r i s のセキュリティ･ポリシー･モデルの特徴は、ユーザと

ロールの関係、機密ラベル、特権と承認にある。Tr u s t e d S o l a r i s にお

けるロールとは、特殊な作業をする際に利用するユーザ･アカウントである。

機密ラベルは、T E のラベルと異なり、優劣の概念を持つ。T E はドメイン

とタイプにより許可される操作が決定されるが、機密ラベルは、「 5 . 5 . 2 ポ

リシー・モデルの特徴」で説明したように、その優劣により可能な操作が

決定される。つまり、T E と異なり、ドメインとタイプによって許可される操

SUBJECT

ACCESSMODE

N:1

N:1

M:N

M:N

OBJECT

USER

N:1N:1

1:1

ACCESS MATRIX

ROLE

1:N1:N

1:N 1:N

SENSITIVITYLABEL

SENSITIVITYLABEL

M:N

M:N特権

PRIVILEGE

COMPARTMENT

CLASSIFICATION

SUBJECT

ACCESSMODE

N:1

N:1

M:N

M:N

OBJECT

USER

N:1N:1

1:1

ACCESS MATRIX

ROLE

1:N1:N

1:N 1:N

SENSITIVITYLABEL

SENSITIVITYLABEL

M:N

M:N特権

PRIVILEGE

COMPARTMENT

CLASSIFICATION

‐107‐

作を設定する必要はない。特権は、プログラムに様々な例外処理を付

与する。We b サーバーに関連する特権には、予め設定された機密ラベ

ルでサブジェクトを起動する特権や、動作中の機密ラベルより劣位の機

密ラベルに遷移することを許可する特権が存在する。また、特権はプロ

グラムに付与され、その特権付きプログラムの実行を承認されたユーザ

やロールからのみ実行できる。このような特権と承認により、We b サーバ

ーは、静的コンテンツと動的コンテンツを異なる機密ラベルで動作させる

事が可能となる。

また、新たな機密ラベルで We b サーバーを動作させる為には、ユーザ、

ロール、機密ラベル、特権と承認の 5 つの設定を修正する必要がある。

Tr u s t e d S o l a r i s では、静的コンテンツと動的コンテンツに応じて、異

なる機密ラベルで We b サーバーを動作させることができる。そのため、

C G I、S S I といった一般ユーザによって作成された信頼できないプログラ

ムが実行される場合に、そのプログラムに最少権限を付与することが可

能である。しかし、この利点はプログラムが設定された機密ラベルで動作

する場合に限られる。Tr u s t e d S o l a r i s では特権と承認の仕組みがあ

るため、動的コンテンツを攻撃者に改竄された場合には、その動的コン

テンツのアクセス可能なオブジェクト、及び、その動的コンテンツから特権

と承認によりアクセス可能なオブジェクトに被害が及ぶ。同様に、We b サ

ーバーを改竄された場合には、We b サーバーのアクセス可能なオブジェ

クト、及び、We b サーバーから特権と承認によりアクセス可能なオブジェ

クトに被害が及ぶ。

特権や承認の欠点は、特権や承認の設定された対象の数が増える

につれ、どのようなアクセスが許可されているのかを管理することが難しく

なることである。

‐108‐

5 .6 各モデルの比較

本章で説明した各モデルの比較を行う。

5 .6 .1 サブジェクトに付与されるラベルの決定因子

各モデルにおいてサブジェクトに対して付与されるラベル（ドメイン、機

密ラベル）の決定因子を比較する。以下に示されるように、サブジェクト

に対して付与されるラベルの決定方法は、次の 2 つのタイプに分ける事

ができる。１つは、H o f f m a n のモデルと PA R B A C に見られるような、各因

子によってサブジェクトに付与されるラベルが静的に決定されるタイプで

あり、もう 1 つは D A F M AT、S E L i n u x、Tr u s t e d S o l a r i s のように動的

に付与されるラベルが決定するタイプである。

モデル決定因子

H o f f m a n ’s

R B A C

サブジェクト、ロール、ユーザ

D A F M AT ユーザ、コンテキスト

PA R B A C ユーザ、ロール、タスク

S E L i n u x ロール、もしくは、ドメインと実行中オブジェクトのタイプ

Tr u s t e d

S o l a r i s

ユーザ、セッション

表 5 - 4 サブジェクトに付与されるラベルの決定因子

5 .6 .2 アクセス制御の特徴

各モデルで行われるアクセス特徴の特徴を比較する。これらの特徴は、

We b サーバーで静的コンテンツと動的コンテンツを処理する際に、アクセ

ス制御を変更する仕組みを示している。

‐109‐

モデルアクセス制御の特徴

H o f f m a n ’s

R B A C

ロールに複数のドメインを割り当てる事ができる。

D A F M AT 論理駆動承認エンジンによって、サブジェクトに対する

ドメインの割り当てを変更できる。

PA R B A C プライバシ・エンフォースメントによってオブジェクトの利

用目的を限定させることができる。

S E L i n u x ドメイン遷移の機能を持つ。

Tr u s t e d

S o l a r i s

セキュリティ管理者によって与えられた特権と承認によ

り、アクセス制御の例外を作ることができる。

表 5 - 5 アクセス制御の特徴

5 .6 .3 異なるアクセス制御を行う仕組み

各モデルにおいて、静的コンテンツと動的コンテンツに対して異なるア

クセス制御を行う仕組みを比較する。以下に示すように、D A F M AT 、

S E L i n u x、Tr s u t e d S o l a r i s は、特別な仕組みを使い、サブジェクトと

ラベルの対応関係を変更する。これにより静的コンテンツと動的コンテン

ツに対して異なるアクセス制御を行う。H o f f m a n と PA R B A C は、特別な

仕組みは使わず、各モデルから導かれる機能として、静的コンテンツと

動的コンテンツに対して異なるアクセス制御を実現している。

‐110‐

モデル異なるアクセス制御を行う仕組み

H o f f m a n ’s

R B A C

ロールとドメインは N : M で割り当てられる。

D A F M AT ロールとドメインは N : 1 で割り当てられるが、論理駆動

承認エンジンによって、サブジェクト -ドメインのマッピン

グがコンテキストによって変更できる。

どのようなコンテキストを使用するかは強制できない。

PA R B A C ロールとドメインは N : 1 で割り当てられるが、タスク、パー

パス、オブジェクト・ポリシーによって、同一ドメイン内で

異なるアクセス制御を実現できる。

サブジェクトの使用するタスクとパーパス、及び、オブジ

ェクトに付与されるオブジェクト・ポリシーは強制できる。

S E L i n u x ロールとドメインは N : 1 で割り当てられるが、特定のポリ

シーを満たせば、ドメイン遷移することができる。ドメイン

の遷移は強制できる。

Tr u s t e d

S o l a r i s

ユーザとドメインは N : 1 で割り当てられるが、プログラム

ファイルと実行ユーザに特権と承認を与えることで、機

密ラベルを遷移させることができる。

機密ラベルの遷移は特権と承認の内容で制限される

（劣位の機密ラベルへの遷移しか認めないなど）。ただ

し、ラベルの遷移はサブジェクトによって実行されるた

め、強制的に遷移させられるわけではない。

表 5 - 6 異なるアクセス制御を行う仕組み

‐111‐

5 .6 .4 ドメイン（機密ラベル）の追加に影響される要素

各モデルにおいて、異なるアクセス制御を行う範囲（C G I を実行する

際に追加する C G I 用のドメインなど）を、新たに追加した場合に、影響

を受ける要素を比較する。PA R B A C では、ドメインを追加する必要はな

く、タスク、パーパス、オブジェクト･ポリシーの追加により、異なるアクセス

制御をかける範囲を作成することができる。以下に示すように、サブジェ

クトやオブジェクトに関係する要素が多いモデルほど、影響される要素が

多くなる。

モデルドメイン（機密ラベル）の追加に影響

される要素

要素数

H o f f m a n ’s

R B A C

ドメイン

タイプ

ドメイン -タイプ･アクセス･マトリックス

3

D A F M AT ユーザ

ロール

ドメイン

タイプ


5

PA R B A C タスク

パーパス

オブジェクト・ポリシー


4

S E L i n u x ドメイン

ドメイン遷移

オブジェクト･タイプ


4

‐112‐

Tr u s t e d

S o l a r i s

ユーザ

ロール

機密ラベル

特権

承認

5

表 5 - 7 ドメイン（機密ラベル）の追加に影響される要素

5 .6 .5 被害範囲

各モデルでおいて、攻撃者によって We b サーバーを改竄された場合

と、動的コンテンツを改竄された場合の被害範囲を比較する。各モデル

の被害範囲は、2 つのタイプに分ける事ができる。1 つは D A F M AT と

Tr u s t e d S o l a r r i s のように、改竄者によって不特定のラベルに遷移さ

れる可能のあるタイプである。 D A F M AT の論理承認エンジンや

Tr u s t e d S o l a r i s の特権は、改竄者により能動的に実行されてしまう。

つまり、改竄者によって任意のラベルへ遷移される可能性が存在する。

対して、H o f f m a n では、改竄されたプログラムに対しても、ドメインアクセ

ス･マトリックスによるアクセス制御が強制される。また、PA R B A C ではタス

ク、パーパス、オブジェクト･ポリシーによって改竄されたプログラムに対し

てアクセス制御が強制される。S E L i n u x では、改竄されたプログラムに

対して、ドメイン遷移のポリシーによって認められた遷移しか起こらないた

め、改竄者は任意のドメインに遷移できるわけではない。

‐113‐

モデル We b サーバーの改竄による被害範囲

H o f f m a n ’s

R B A C

ドメイン -タイプ･アクセス･マトリックスによ

り、W e b サーバーに対して実行の許可されたサ

ブジェクトのドメインでアクセス可能なオブジ

ェクト

D A F M AT 論理駆動承認エンジンで、We b サーバーにマッピング

される可能性のある全てのドメインでアクセス可能なオ

ブジェクト

PA R B A C We b サーバーのタスクとパーパスでアクセス可能なオブ

ジェクト、及び、We b サーバーから外部実行の許されて

いるプログラムファイルのタスクとパーパスでアクセス可

能なオブジェクト

S E L i n u x We b サーバーのドメインから遷移可能な全てのドメイン

でアクセスできるオブジェクト

Tr u s t e d

S o l a r i s

We b サーバーの機密ラベルでアクセス可能なオブジェ

クト、及び、We b サーバーに設定された特権でアクセス

可能なオブジェクト

表 5 - 8 We b サーバーの改竄による被害範囲

‐114‐

動的コンテンツの改竄による被害範囲

H o f f m a n ’s

R B A C

ドメイン -タイプ･アクセス･マトリックスによ

り、動的コンテンツに対して実行の許可された

サブジェクトのドメインでアクセス可能なオブ

ジェクト

D A F M AT 論理駆動承認エンジンで、動的コンテンツにマ

ッピングされる可能性のある全てのドメインで

アクセス可能なオブジェクト

PA R B A C 動的コンテンツのタスクとパーパスでアクセス

可能なオブジェクト、及び、動的コンテンツか

ら外部実行の許されているプログラムファイル

のタスクとパーパスでアクセス可能なオブジェ

クト

S E L i n u x 動的コンテンツのドメインから遷移可能な全て

のドメインでアクセスできるオブジェクト

Tr u s t e d

S o l a r i s

動的コンテンツの機密ラベルでアクセス可能な

オブジェクト、及び、動的コンテンツに設定さ

れた特権でアクセス可能なオブジェクト

表 5 - 9 動的コンテンツの改竄による被害範囲

‐115‐

既存 Web サーバー･システムにおける

アクセス制御の調査編

‐116‐

6 実装システムの調査

6 .1 RBAC/Web

R B A C / We b は、N I S T （ t h e N a t i o n a l I n s t i t u t e o f S t a n d a r d s

a n d Te c h n o l o g y）の R B A C モデルの W W W イントラネット・アプリケーシ

ョンへの参考実装例である。

管理者の作業負担が大きい、サブジェクト・ベースのセキュリティ･ポリ

シーが強制できないなどの理由から、A C L によるアクセス管理は We b サ

ーバーには不向きである。そこで、A C L に代わって R B A C を採用するこ

とにより、より安全に We b サーバー上に情報を公開し、企業の生産性

向上を図ることができる。R B A C を We b サーバー・アプリケーションに実

装した場合、低レベルのアクセス制御メカニズムの承認データとその他の

R B A C 関連データを 1 つの R B A C 承認データベースの中で管理するた

め、管理上の利便性が良いという利点がある。

管理者の視点から見ると、R B A C / We b は、企業のイントラネット・アク

セス制御ポリシーの視覚化および管理ツールとして機能している。

R B A C の実装に当たっては、管理ツールの設計とロールを有効にす

るために使うプロセスを考慮しなければならない。R B A C / We b では非任

意のアクセス制御メソッドとして R B A C をとらえており、管理者ロールとユ

ーザロールとは明確に区別されている。R B A C / We では、管理ツールや

R B A C データベースにアクセスするための管理者ロールを 1 つのみ設定

しており、管理者ロールを割り当てられていないユーザは、管理者によっ

て割り当てられたロールの領域内でのみ動作することができる。

‐117‐

表 6 - 1 R B A C / We b のコンポーネント

コンポーネント解説

データベースユーザロール間の関係、ロール・ヒエラルキー、ユ

ーザロール間の関係にかかる制約、現在のアクテ

ィブ・ロール、ロール -オペレーションの関係を特定

するファイル

A P I ライブラリ We b サーバーや C G I が R B A C / We b にアクセス

するために利用する仕様。 A P I （ A p p l i c a t i o n

P r o g r a m I n t e r f a c e ）によって R B A C を We b サ

ーバーに実装することが可能になる。A P I ライブラ

リは R B A C / We b を実装する C および P e r l のライ

ブラリである。

C G I サーバーに変更を加えずに既存の We b サーバー

を利用するために、C G I として R B A C を実装し

た。R B A C / We b の C G I は R B A C / We b の A P I

を使用している。

セッション・マネジャ

ー

R B A C / We b のセッション・マネジャーは、ユーザの

現在のアクティブ・ロール・セットを作成し、ロール

を有効にする。

A d m i n To o l A d m i n To o l を利用することによって、サーバー

管理者はユーザおよびロールの作成、ユーザロー

ルおよびロール -オペレーションの関連付け、ユー

ザロール関係にかかる制約の指定、R B A C デー

タベースの管理を行なうことができる。管理者は

We b ブラウザから A d m i n To o l にアクセスする。

‐118‐

R B A C / We b のコンポーネントの 1 つである A d m i n To o l では、ロール

の割り当てとロールの承認の概念を区別している。ユーザがロール r 0 に

対して承認されており、 r 0 がロール r 1 を継承する場合、自動的にユー

ザは r 0 に加えて r 1 に対しても承認されたことになる。ここで、ユーザへの

r 0 に対する承認が削除されると、 r 1 に対する承認も削除される。

R B A C の実装時には、実装環境の中でのサブジェクトの概念を規定

しておく必要がある。U n i x システムなどのシングル・コンピュータ・システム

環境において、サブジェクトはユーザ･プロセスのプロセス I D として規定

することができる。W W W 環境において、例えばハイパーリンクをクリックす

るなどの各アクセスは、そのアクセスを実行するためのユーザ･プロセスを

We b サーバー上に作成することと類似しており、アクセスが完了すると、

ユーザ･プロセスは削除される。このように We b サーバー環境ではユー

ザ･プロセスの寿命が短く、サブジェクトをプロセス I D として規定すること

は非効率であるため、R B A C / We b ではサブジェクトを We b サーバー上の

ユーザのログイン名として規定している。We b サーバー上のログイン名は

1 ユーザにつき 1 つなので、ユーザが複数のブラウザを開いていようとも、

1 つの We b サーバーにつき 1 人のユーザ、1 人のユーザにつき 1 つのア

クティブ・ロール・セットという関係が成り立つ。

R B A C / We b は、ユーザのアクティブ・ロール・セットを We b サーバー上

の 1 つのファイルに保持しており、このファイルに基づいてユーザのアクセ

スを決定している。このユーザのアクティブ・ロール・セットの内容を管理

するのが、R B A C / We b セッション・マネジャーである。ダイナミックな責務

の分離（D y n a m i c S e p a r a t i o n o f D u t y）の関係にあるロールのペアは、

アクティブ・ロール・セットになることはできない。さらに、R B A C / We b では、

R B A C データベース内で 2 つのロールが階層的な関係と同時にダイナミ

ックな責務の分離の関係にあることはできない。

R B A C / We b では、既存の W W W 認証であるユーザ名 /パスワードと

S S L を併用することができる。ユーザの識別情報は We b サーバーによっ

‐119‐

て R B A C / We b に渡される。We b サーバーは、We b サーバー管理者の

設定に基づいて、ユーザの識別情報を認証し、機密データを伝送する。

ブラウザに関しては特に要件を規定していない。

R B A C / We b は以下の 2 つの環境で実装されている。 ( 1 ) U N I X（例 :

N e t s c a p e 、 A p a c h e サーバー）、 ( 2 ) Wi n d o w s N T （例 : I n t e r n e t

I n f o r m a t i o n S e r v e r、We b s i t e、P u r v e y o r）

1 . R B A C / We b f o r U N I X

R B A C 承認データベース・モデルと R B A C 起動モデル、すなわちヒエ

ラルキー、カルディナリティ 5、スタティックな責務の分離、ダイナミックな責

務の分離といったロールのプロパティを実装した。U N I X の実装では表

6 - 1 R B A C / We b のコンポーネントで示した全てのコンポーネントを利用

している。

U N I X の We b サーバーで R B A C / We b を実装するには 2 つの方法が

ある。

1 つは R B A C / We b の C G I を用いる方法で、C G I はサーバーのソー

ス・コードを変更せずに既存の U N I X で利用することが可能である。

R B A C の U R L は We b サーバーを経て C G I によって処理される。

R B A C / We b のコンフィギュレーション・ファイルは、ユーザのロールに基づ

くアクセス制御を実行しながら、U R L をファイル名にマッピングする。

R B A C / We b の C G I は比較的簡単にインストールおよび利用することが

できるが、We b サーバー上で直接アクセス制御を実行するには不十分

である。

2 つ目は、U N I X の We b サーバーを R B A C / We b の A P I を呼び出す

ように修正する方法である。U R L は、We b サーバーのコンフィギュレーシ

5 ロールに対して許可されているユーザの数を指す。例えば、部長の

ロールは１ユーザにのみ割り当てることが可能で、そのユーザ数を超えて

部長のロールを割り当てることはできない。

‐120‐

ョン・ファイルにより、R B A C によって制御される。N e t s c a p e や A p a c h e

などのような U N I X 環境向けの We b サーバーは、オペレーションをいく

つかのステップに分割し、コンフィギュレーション・パラメータを使って強化

もしくは置換できる機能を各ステップに提供している。これを利用して、サ

ーバーのソース･コードを変更することなく We b サーバーのオペレーション

を修正することができる。つまり、R B A C / We b の A P I は、適切な呼び出

しシーケンスを提供し、コンフィギュレーション・パラメータを変更すること

によって、We b サーバーと統合することが可能である。

2 . R B A C / We b f o r Wi n d o w s N T

R B A C 承認データベース・モデル、すなわちヒエラルキー、カルディナリ

ティ、スタシックな責務の分離といったロールのスタティックなプロパティの

みを実装した。Wi n d o w s N T 環境でダイナミックな責務の分離を実装

するためには、Wi n d o w s N T のセッション確立メカニズムを変更しなけれ

ばならず非効率である。Wi n d o w s N T のビルトインのセキュリティ･メカニ

ズムは R B A C と互換性があることから、R B A C / We b のデータベースと

A d m i n To o l のみを実装した。R B A C / We b の A d m i n To o l はユーザロ

ールおよびロール -ロールの関係のみを管理するものである。そこで、ロー

ル -パーミッションの関係を管理するために R G P - A d m i n 6というツールも

実装した。

実装においては We b サーバーの内部修正やソース･コードへのアクセ

スは必要ない。Wi n d o w s N T のセキュリティ・メカニズムは、Wi n d o w s

N T 自体と Wi n d o w s N T 上で動作する We b サーバーとの間で同一で

あるため、We b リソースだけでなく Wi n d o w s N T のファイル･システムへの

アクセスも管理することが可能である。

6 J . B a r k l e y らが開発した、Wi n d o w s N T 環境で利用することができる O b j e c t A c c e s s Ty p e を利用した R B A C 管理用ツール。O b j e c t A c c e s s Ty p e Vi e w、O b j e c t A c c e s s Ty p e E d i t o r、R o l e P e r m i s s i o n Vi e w という 3 つのコンポーネントで構成されている。

‐121‐

R B A C / We b におけるパーミッションは、エンド・ユーザが R B A C / We b

よって制御された U R L 上で実行できる H T T P メソッドである。

R B A C / We b によって課される制約によって、機密を管理することができ、

ネットワーク内で重大なセキュリティ･ポリシーが常に一律に強制される。

R B A C / We b によって管理されているオブジェクトは、各 We b サーバーの

A C L と関連している。U n i x 向けの実装では、A C L はロールのリストとし

て体系付けられている。A C L には各ロールについて H T T P メソッドのリス

トがあり、そのリストに基づきユーザは関連 U R L へのアクセスを許可され

る。Wi n d o w s N T 向けの実装では、Wi n d o w s N T のビルトイン A C L を

利用しており、ロールは Wi n d o w s N T のドメインもしくはローカル・グルー

プにマッピングされる。また、A C L はロール -特権の関係の集合として編

成、管理されている。R B A C / We b においては、各サブジェクトは１つ以上

のロールを有効にしているユーザを表す。ユーザの承認は、ユーザが特

権を実行する許可を得るための必要条件ではあるが、必要十分条件で

はない。R B A C / We b では、ユーザはオペレーションの実行または U R L へ

のアクセス許可を得る前に、まず１つのロールを有効にする承認を得なけ

ればならない。

以下では、管理者およびエンド・ユーザの視点から R B A C / We b の動

作について解説する。

1 . 管理者の視点

R B A C / We b の A d m i n To o l は、ユーザロールおよびロール -ロールの

関係、ユーザロールの割り当て、ロール・ヒエラルキー、スタティックな責

務の分離、ダイナミックな責務の分離およびロールのカルディナリティを

管理する。

エラーを削減するために、A d m i n To o l はロールの割り当てとロールの

承認の概念を区別している。管理者は、A d m i n To o l によってロールを

ユーザに割り当てる。ロールが承認されるのは、ユーザにそのロールが割

り当てられている、もしくはユーザに割り当てられている別のロールがその

‐122‐

ロールを継承している場合である。管理者はデータベース上で実行でき

るオペレーションを予め決定しておき、A d m i n To o l を使ってそのオペレ

ーションを実行することにより R B A C データベースを管理する。

R B A C / We b では、A d m i n To o l および R B A C データベースにアクセス

することができる唯一の管理者ロールを設定している。

A d m i n To o l では、ポリシーはグラフィカルに表示される。図 6 - 1 に、

ロール・ヒエラルキーの表示例を示す。現在選択しているロールは、図形

表示されない。現在選択しているロールとスタティックな責務の分離関

係にあるロールは五角形の図形で表示され、それ以外のロールは楕円

の図形で表示される。図形内に（n / m）で表示されている数字は、（現在

ロールを割り当てられているユーザ数 / ロールに割り当てられる最大ユ

ーザ数、つまりロールのカルディナリティ）を示している。（）内の“U ”はロ

ールに割り当てられる最大ユーザ数に制限がないことを表す。

図 6 - 1 R B A C / We b A d m i n To o l でのロール・ヒエラルキーの表示例

売掛管理者（1/1）

売掛管理係（2/5）

請求管理者（1/1）

現金出納管理者（1/1）

現金出納係（1/12）

請求係（1/21）

売掛管理（4/U）

経理（4/U）

スタッフ（4/U）

売掛管理者（1/1）

売掛管理係（2/5）

請求管理者（1/1）

現金出納管理者（1/1）

現金出納係（1/12）

請求係（1/21）

売掛管理（4/U）

経理（4/U）

スタッフ（4/U）

‐123‐

2 . エンド・ユーザの視点

エンド・ユーザの視点から見ると、Wi n d o w s N T 向けの R B A C / We b

が実装された We b サーバーとの対話は、R B A C / We b が実装されていな

い We b サーバーとの対話と全く同じである。その理由は、Wi n d o w s N T

向けの R B A C / We b がダイナミックな責務の分離をサポートしていないこと

である。しかし、U N I X 向けの R B A C / We b では、R B A C によって制御さ

れた U R L へのアクセスが許可される前に、エンド・ユーザはアクティブ・ロ

ール・セットを確立しなければならない。まずエンド・ユーザは、現在のアク

ティブ・ロール・セットを選択する、または割り当てられる。アクティブ・ロー

ル・セットは、R B A C によって制御された U R L 上でエンド・ユーザが実行

することができる H T T P メソッドを決定する。アクティブ・ロール・セットは、

エンド・ユーザが新しいアクティブ・ロール・セットを確立するまで有効であ

り、アクティブ・ロール・セットの変更には R B A C / We b のセッション・マネジ

ャーを利用する。セッション・マネジャーの利用により、ダイナミックな責務

の分離関係に違反しないサブセットのリストがユーザに提示され、選択を

促される。選択肢を最小限にするために、ユーザが割り当てられている

全ロールのサブセットの中から、ダイナミックな責務の分離関係に違反し

ない最大のサブセットがリストに表示される。ユーザがサブセットを選択す

ると、そのサブセットに含まれるロールおよびそれらのロールが継承したロ

ールがアクティブ・ロール・セットとなる。ユーザに割り当てられているロー

ル間にダイナミックな責務の分離関係がない場合、アクティブ・ロール・セ

ットは自動的に確立される。この場合のアクティブ・ロール・セットは、ユー

ザに対して承認された全てのロールとなる。R B A C / We b は 1 台のサーバ

ーのみに適用しているため、ダイナミックな責務の分離に関して、1 台の

We b サーバー上のユーザを想定した実装がなされており、複数のサーバ

ーにまたがるユーザを考慮していない。

‐124‐

図 6 - 2 R B A C / We b エンド・ユーザの視点

6 .2 PDRBAC

A . L i n は、 P D R B A C （ P o l i c y - D r i v e n R o l e - a s e d A c c e s s

C o n t r o l ）の技術を C D S A （ C o m m o n D a t a S e c u r i t y

A r c h i t e c t u r e）の拡張に応用する研究を実施した。

C D S A は、下図のように 4 つのレイヤで構成されており、そのうちの T P

モジュールにセキュリティ･ポリシーが実装されている。そのため、T P モジ

ュールをつけなければ、トラスト・ポリシー･サービスを利用することができな

い。さらに、そのポリシーはモジュールの開発者によってスタティックに規

定されており、ユーザがポリシーの追加・変更を行なうことはできない。

ブラウザ

ユーザ

Webサーバ

RBACデータベース

アクティブ・ロール・セット確立要求

アクティブ・ロール・セットの選択肢提示

アクティブ・ロール・セットの選択

アクティブ・ロール・セットの確立

URL

リスポンス

ブラウザ

ユーザ

Webサーバ

RBACデータベース

アクティブ・ロール・セット確立要求

アクティブ・ロール・セットの選択肢提示

アクティブ・ロール・セットの選択

アクティブ・ロール・セットの確立

URL

リスポンス

‐125‐

図 6 - 3 C D S A（C o m m o n D a t a S e c u r i t y A r c h i t e c t u r e）

L i n は、C D S A でユーザがダイナミックにポリシーを追加・変更すること

ができるアーキテクチャを実装した。さらに、P R O L O G ベースのポリシー

記述言語を設計した。

P D R B A C は、以下の 4 つの点で C D S A の拡張に適していると主張し

ている。（1 ）膨大な数にのぼるユーザとリソースのマッピングをダイナミック

に行なうことができる、（2 ）組織内のユーザは組織のビジネス・プロセスに

合わせた、比較的不変のロールに分類されることが多く、R B A C のロー

ルの考え方と一致する、（3）柔軟かつダイナミックにセキュリティ･ポリシー

を配置することができる、（ 4 ）ロールのヒエラルキー構造において、ロール

の特権を他のロールに継承することができるという R B A C の特徴が、実

際のビジネス要件をセキュリティ・メカニズムにマッピングする際に有効で

ある。

具体的な L i n の実装については、以下に記述する。

C D S A でユーザがダイナミックにポリシーを追加・変更することができる

アプリケーション

階層化されたサービス、ミドルウェア、言語インタフェース・アダプタ、ツール

CSSMセキュリティAPI

IntegrityServices

CSPManager

TPManager

CLManager

DLManager

ManagementContextSecurity

SPI TPI CLI DLI

CSP TP CL DLデータ保存

SystemSecurityServices

CommonSecurityServicesManager

SecurityAdd-in

Modules

※CSSM: Common Security Services Manger, CSP: Cryptographic Service ProviderTP: Trust Policy Module CL: Certificate LibraryDL: Data Storage Library SPI: Service Provider Interface




IntegrityServices

CSPManager

TPManager

CLManager

DLManager


SPI TPI CLI DLI

CSP TP CL DLデータ保存



SecurityAdd-in

Modules

※CSSM: Common Security Services Manger, CSP: Cryptographic Service ProviderTP: Trust Policy Module CL: Certificate LibraryDL: Data Storage Library SPI: Service Provider Interface

‐126‐

アーキテクチャを実現するために、L i n は 2 つのアプローチを考案し、そ

れらを統合した拡張を実施した。1 つ目のアプローチは、ポリシー・ライブ

ラリ（P L）という新たなモジュールの開発である。P L は、C D S A の T P モジ

ュールと置換可能であり、ユーザが規定したポリシーを強制することがで

きる。さらに、標準的な T P サービスを提供しながら、各ポリシーは外部の

P D F（P o l i c y D e s c r i p t i o n F i l e ）またはポリシー・データベースによって

規定される。P D R B A C と C D S A を統合するために、セキュリティ管理者

はまず組織のロールと特権をモデル化し、P D F にアクセス制御ポリシー

を書き込む必要がある。P L のポリシー強制メカニズムは下図の通りであ

る。

図 6 - 4 P L のポリシー強制

2 つ目のアプローチは、ポリシー・インタープリタを直接呼び出すことに

より、C S S M およびアドイン・モジュールがそれぞれ別のポリシーを強制す

ることを可能にする D L L もしくは共有ライブラリの実装である。この方法

を採用すればトラスト・ポリシー強制メカニズムが C S S M に組み込まれる

ユーザ

ポリシ/モデル編集ツール

モデルベースPDF

ポリシ・インタープリタ

データ・ストレージ

PLモジュール・ファンクション

CSSM Security API


Request Result

Result

Query

ポリシ

ポリシ

モデル

モデル

セキュリティ・オブジェクト

※ 実線: 制御フロー破線: データ・フロー

CSSM Dispatcher

ユーザ

ポリシ/モデル編集ツール

モデルベースPDF

ポリシ・インタープリタ

データ・ストレージ

PLモジュール・ファンクション

CSSM Security API


Request Result

Result

Query

ポリシ

ポリシ

モデル

モデル

セキュリティ・オブジェクト

※ 実線: 制御フロー破線: データ・フロー

CSSM Dispatcher

‐127‐

ため、P L モジュールは必要ない。しかし、L i n はレガシーC D S A アプリケ

ーションやインタフェースとの互換性を持たせることを重視し、共有ライブ

ラリと P L の重要要素である P D F の両方を組み込んだ拡張を行なった。

L i n の拡張モデルでは、T P モジュールをつけずに、デフォルトのトラスト・

ポリシー･サービスを利用することも可能であり、簡単かつ柔軟性に富ん

だセキュリティ管理を実現できる。

図 6 - 5 P D R B A C によって拡張した C D S A

最後に、例としてインターネットを経由して実績評価データベースにア

クセスする場合を想定した際の一連の流れについて解説する。

1 . ユーザはウェブ・ブラウザを起動し、ある U R L にリクエストを送信

する。

2 . サーバーはユーザからのリクエストを受け取り、ユーザのロールと

要求に基づいてクエリを作成する。

3 . C G I - b i n または J a v a サーブレットがクエリに基づいてデータベ

ースにアクセスする。




TP PDFManager

CSPManager

CLManager

DLManager


SPI CLI DLI

CSP CL DL

データ保存



SecurityAdd-in

Modules

ポリシ・インタープリタ Integrity Services トラスト・ポリシ・サービス

TPPDFI

CSP PDFCSP PDF CL PDFCL PDF DL PDFDL PDF

TrustPolicyPDF

ユーザ定義アプリケーション固有の

PDF

※PDF: Policy Description File破線で囲まれているのはアドイン・モジュールの開発者がオプションで提供しており、ユーザからは隠されている。




TP PDFManager

CSPManager

CLManager

DLManager


SPI CLI DLI

CSP CL DL

データ保存



SecurityAdd-in

Modules

ポリシ・インタープリタ Integrity Services トラスト・ポリシ・サービス

TPPDFI

CSP PDFCSP PDF CL PDFCL PDF DL PDFDL PDF

TrustPolicyPDF

ユーザ定義アプリケーション固有の

PDF

※PDF: Policy Description File破線で囲まれているのはアドイン・モジュールの開発者がオプションで提供しており、ユーザからは隠されている。

‐128‐

4 . 各レコードを処理している間に、プログラムがクエリで C M M S P L

A P I を呼び出し、さらに P D F を呼び出して t r u e または f a l s e

を返す。

5 . 返ってきた結果に基づいて、プログラムがユーザのオペレーショ

ンの実行を許可するかを判断する。

6 .3 SELinux

6 .3 .1 オブジェクト･タイプの付与

オブジェクトに対してオブジェクト･タイプを付与する設定は、以下のよ

うに記述される。

/var/www/html/.*

system_u:object_r:httpd_contents_t

/var/www/cgi-bin/.*

system_u:object_r:httpd_scripts_t

1 行目： “ / v a r / w w w / h t m l ” 配下のリソース

は、 ” h t t p d _ c o n t e n t s _ t ”というタイプを付与される。

2 行目： ” / v a r / w w w / c g i - b i n / ” 配下のリソース

は、 ” h t t p d _ s c r i p t s _ t ”というタイプを付与される。

6 .3 .2 ドメインの付与

ドメイン遷移を起きない場合、子プロセスには親プロセスと同じドメイン

が付与される。ドメイン遷移が行われる為には、ポリシー･ファイルに「遷

移元のドメイン」、「プログラムファイル（エントリーポイント）のオブジェクト･

タイプ」、「遷移後のドメイン」を記述する。

‐129‐

以下は、 i n i t r c によって、h t t p d が h t t p d _ t ドメインとして起動される

設定は、以下のように記述される。

/usr/sbin/httpd

system_u:object_r:httpd_exec_t

domain_auto_trans(initrc_t, httpd_exec_t,

httpd_t)

1 行目： “ / u s r / s b i n / h t t p d ”は、 ” h t t p d _ e x e c _ t ”というタイプを付与

される。

2 行目： “ i n i t r c _ t ” ドメインにより、 ” h t t p d _ e x e c _ t ”が実行される

と、 ” h t t p d _ t ”にドメイン遷移される。

6 .3 .3 アクセス制御

ドメインがアクセスできるリソースは、以下のように記述される。

（下記のようにオブジェクト･タイプの設定がされているとする）

/var/www/html/.*

system_u:object_r:httpd_contents_t

/var/www/cgi-bin/.*

system_u:object_r:httpd_scripts_t

allow httpd_t httpd_contents_t: {dir file}

{read};

allow httpd_t httpd_scripts_t: {dir file}

{read execute}

1 行目： “ h t t p d _ t ”というドメインは、 ” h t t p d _ c o n t e n t s _ t ”というタイ

‐130‐

プの、 ” d i r ” と ” f i l e ” オブジェクト・クラスに対して、 ” r e a d ” ( 参照 )

を ” a l l o w ” (許可 )される。

2 行目： “ h t t p d _ t ”というドメインは、 ” h t t p d _ s c r i p t s _ t ”というタイプ

の、 ” d i r ” と ” f i l e ” オブジェクト・クラスに対して、 ” r e a d ” ( 参照 )

と ” e x e c u t e ” (実行 )を ” a l l o w ” (許可 )される。

6 .3 .4 ユーザとロール、ロールとドメイン

「ユーザ」に割り当てられた「ロール」の一覧と、その「ロール」が使用で

きる「ドメイン」の一覧は、以下のように記述される。

user hogehoge roles { users_r sysadm_r

httpdadmin_r}

role users_r types { users_t editor_t }

role sysadm_r types { sysadm_t }

role httpdadmin_r types { httpdadmin_t }

1 行目： “ h o g e h o g e ”というユーザは、 ” u s e r s _ r ”、 ” s y s a d m _ r ”、及

び ” h t t p d a d m i n _ r ”というロールが利用できる。

2 行目： “ u s e r s _ r ”というロールは、 ” u s e r s _ t ”と ” e d i t o r _ t ”というタイ

プのリソースが利用できる。

3 行目： ” s y s a d m _ r ”というロールは、 ” s y s a d m _ t ”というタイプのリソ

ースが利用できる。

4 行目： ” h t t p d _ a d m i n _ r ”というロールは、 ” h t t p d a d m i n _ t ”という

タイプのリソースが利用できる。

‐131‐

6 .3 .5 オブジェクト･クラスとアクセス･ベクターの一覧

6 . 3 . 5 . 1 オブジェクト・クラス（O B J E C T- C L A S S）

アクセス制御の対象となるリソースは、オブジェクト・クラスと呼ばれる。

オブジェクト・クラスには、ファイル、ディレクトリ、T C P ソケットなど、 5 0

種類以上ものリソースが存在する。

以下に代表的なオブジェクト・クラスの概要を示す。

種別オブジェクト・クラス名概要

S e c u r i t y S E L i n u x 独自の処理

P r o c e s s プロセス処理

S y s t e m システム処理

システム

C a pa b i l i t y 特権

F i l e s y s t e m ファイルシステム

F i l e 通常のファイル

D i r ディレクトリ

F d ファイル識別子

l n k _ f i l e シンボリックリンク

c h r _ f i l e キャラクタ型デバイス

b i k _ f i l e ブロック型デバイス

s o c k _ f i l e ソケット

ファイル

f i f o _ f i l e F I F O

S o c k e t ソケット

t c p _ s o c k e t T C P ソケット

u dp _ s o c k e t U D P ソケット

r a w i p _ s o c k e t R a w ソケット

N o d e ネットワークアドレス

セキュリティ･

オブジェクト

ネットワーク

N e t i f ネットワークインターフェース

‐132‐

n e t l i n k _ s o c k e t n e t l i n k ソケット

pa c k e t _ s o c k e t pa c k e t ソケット

k e y _ s o c k e t I P S E C 用ソケット

u n i x _ s t r e a m _ s o c k e

t

ストリーム型ソケット

u n i x _ d i a g r a m _ s o c k

e t

データグラム型ソケット

S e m セマフォ

M s g キュー内のメッセージ

M s g q メッセージキュー

S h m 共有メモリ

プロセス間

通

信

I p c 未使用

ユーザスペース･オブジェク

パスワード

P a s s w d パスワード変更

表 6 - 2 オブジェクト・クラス

‐133‐

上記以外のユーザスペース・オブジェクトクラスを以下に示す。

種別オブジェクト・クラス名

D r a w a b l e

W i n d o w

G c

F o n t

C o l o r m a p

P r o p e r t y

C u r s o r

X c l i e n t

X i n p u t

X s e r v e r

X ウィンドウ

X e x t e n s i o n

P a X P a x

n e t l i n k _ r o u t e _ s o c k e t

n e t l i n k _ f i r e w a l l _ s o c k e t

n e t l i n k _ t c p d i a g _ s o c k e t

n e t l i n k _ n f l o g _ s o c k e t

n e t l i n k _ x f r m _ s o c k e t

n e t l i n k _ s e l i n u x _ s o c k e t

n e t l l i n k _ a u d i t _ s o c k e t

n e t l i n k _ i p 6 f w _ s o c k e t

カーネル・ユーザ間通信

n e t l i n k _ d n r t _ s o c k e t

D - B U S D b u s

ユーザスペース･オブジェクト

N S C D N s c d

‐134‐

I P S e c A s s o c i a t i o n

表 6 - 3 ユーザスペース・オブジェクトクラス

6 . 3 . 5 . 2 アクセス・ベクター（A C C E S S - V E C T O R）

オブジェクト･クラスに対するアクセス形態は、アクセス・ベクターと呼ば

れる。

例えば、ファイルというオブジェクト・クラスに対しては、読み込み、書き

込み、実行といったアクセス･ベクターが存在する。

以下に、代表的なオブジェクト･クラスのアクセス・ベクターを示す。

• ファイル関連で共通のアクセス・ベクター

アクセス・ベクター概要

i o c t l i o c t l システムコール

r e a d 読み込み

w r i t e 書き込み

c r e a t e 作成

g e t a t t r 属性を取得

s e t a t t r 属性の設定

l o c k ロック

r e l a b e l f r o m タイプの変更

r e l a b e l t o タイプの変更

a p p e n d 追加

u n l i n k 削除

l i n k リンク

r e n a m e 名前の変更

e x e c u t e 実行

‐135‐

s w a p o n スワップを有効に設定

q u o t a o n クウォータを有効に設定

m o u n t o n マウントポイントに指定

表 6 - 4 ファイル関連共通アクセス・ベクター

• ソケット関連で共通のアクセス・ベクター

アクセス･ベクター概要

i o c t l i o c t l システムコール



c r e a t e 作成



l o c k ロック



a p p e n d 追加

b i n d 初期化

c o n n e c t 通信の開始

l i s t e n 接続待ち

a c c e p t 接続待ち

g e t o p t オプションの取得

s e t o p t オプションの設定

s h u t d o w n 通信の終了

r e c v f r o m 受信

s e n d t o 送信

r e c v _ m s g 送信先ポートに基づく仲介

‐136‐

s e n d _ m s g 送信先ポートに基づく仲介

n a m e _ b i n d ポートの使用

表 6 - 5 ソケット関連で共通のアクセス・ベクター

• プロセス間通信関連で共通のアクセス・ベクター


c r e a t e 作成

d e s t r o y 削除





a s s o c i a t e プロセス間通信の I D 付与

u n i x _ r e a d I P C の処理で利用される読み込み

u n i x _ w r i t e I P C の処理で利用される書き込み

表 6 - 6 プロセス間通信関連共通アクセス・ベクター

• f i l e s y s t e m


m o u n t マウント

r e m o u n t マウントのオプション変更

u n m o u n t アンマウント




t r a n s i t i o n タイプの変更

a s s o c i a t i o n ファイルシステムにファイルを紐付け

‐137‐

q u o t a m o d クウォータを有効に設定

q u o t a g e t クウォータの設定を取得

表 6 - 7 f i l e s y s t e m のアクセス・ベクター

• d i r

ファイル関連で共通のアクセス･ベクターに付け加え、以下のアクセ

ス･ベクター。


a d d _ n a m e ディレクトリに、ファイルやディレクトリを追加

r e m o v e _ n a m e ディレクトリから、ファイルやディレクトリを削除

r e p a r e n t 親ディレクトリの変更

s e a r c h 検索

r m d i r 削除

表 6 - 8 d i r のアクセス・ベクター

• f i l e




e x e c u t e _ n o _ t r a n s ドメイン遷移なしの実行

e n t r y _ p o i n t ドメイン遷移のエントリーポイント

e x e c m o d キャラクタ型デバイスファイル用のパーミッションチ

ェック

表 6 - 9 f i l e のアクセス･ベクター

‐138‐

• l n k _ f i l e / b l k _ f i l e / s o c k _ f i l e / f i f o _ f i l e

ファイル関連で共通のアクセス･ベクターと同様。

• c h r _ f i l e




e x e c u t e _ n o _ t r a n s ドメイン遷移なしの実行

e n t r y _ p o i n t ドメイン遷移のエントリーポイント

e x e c m o d キャラクタ型デバイスファイル用のパーミッションチ

ェック

表 6 - 1 0 c h r _ f i l e のアクセス・ベクター

• f d


U s e ファイル識別子の継承

表 6 - 11 f d のアクセス・ベクター

• s o c k e t / n e t l i n k _ s o c k e t / p a c k e t _ s o c k e t / k e y _ s o c k e t /

u n i x _ d i a g r a m _ s o c k e t

ファイル関連で共通のアクセス･ベクターと同様。

‐139‐

• t c p _ s o c k e t

ソケット関連で共通のアクセス･ベクターに付け加え、以下のアクセス･

ベクター。


c o n n e c t t o 接続

n e w c o n 新規ソケットの作成

a c c e p t f r o m 接続待ち

n o d e _ b i n d 特定のタイプのノードにソケットを使用可能に設

定

表 6 - 1 2 t c p _ s o c k e t のアクセス・ベクター

• u d p _ s o c k e t


ベクター。



定

表 6 - 1 3 u d p _ s o c k e t のアクセス･ベクター

• r a w i p _ s o c k e t


ベクター。



定

表 6 - 1 4 r a w i p _ s o c k e t のアクセス・ベクター

‐140‐

• n o d e


Tc p _ r e c v t c p パケットの受信

Tc p _ s e n d t c p パケットの送信

u d p _ r e c v u d p パケットの受信

u d p _ s e n d u d p パケットの送信

r a w i p _ r e c v R a w パケットの受信

r a w i p _ s e n d R a w パケットの送信

e n f o r c e _ d e s t 送受信に使われるソケットの I D のパーミッションチ

ェック

表 6 - 1 5 n o d e のアクセス･ベクター

• n e t i f

アクセス･ベクタ

ー

概要

Tc p _ r e c v t c p パケットの受信

Tc p _ s e n d t c p パケットの送信

u d p _ r e c v u d p パケットの受信

u d p _ s e n d u d p パケットの送信

r a w i p _ r e c v R a w パケットの受信

r a w i p _ s e n d R a w パケットの送信

表 6 - 1 6 n e t i f のアクセス･ベクター

‐141‐

• u n i x _ s t r e a m _ s o c k e t


ベクター。


c o n n e c t t o 接続

n e w c o n n 新規ソケットの作成

a c c e p t f r o m 接続待ち

表 6 - 1 7 u n i x _ s t r e a m _ s o c k e t のアクセス･ベクター

• p r o c e s s


f o r k f o r k システムコール

t r a n s i t i o n ドメイン遷移の許可

s i g c h l d s i g c h l d システムコール

s i g k i l l s i g k i l l システムコール

s i g s t o p s i g s t o p システムコール

s i g n u l l 0 番のシグナル

s i g n a l 0 番以外のシグナル

p t r a c e p t r a c e システムコール

g e t s c h e d スケジュールを取得

s e t s c h e d スケジュールを設定

g e t s e s s i o n セッション I D を取得

g e t p g i d g e t p g i d システムコール

s e t p g i d s e t p g i d システムコール

g e t c a p ケイパビリティを取得

s e t c a p ケイパビリティを設定

s h a r e リソースの共有

‐142‐


s e t e x e c s e t e x e c c o n システムコール

s e t f s c r e a t e s e t f s c r e a t e c o n システムコール

n o a t s e c u r e g l i b c セキュアモード

s i g i n h シグナルの状態を継承

s e t r l i m i t プロセスのハードリミットを変更

r l i m i t i n h リソースのリミットを継承

d y n t r a n s i t i o n 動的なコンテキスト遷移の許可

s e t c u r r e n t T B W

e x e c m e m T B W

表 6 - 1 8 p r o c e s s のアクセス･ベクター

• i p c / s e m

プロセス関連で共通のアクセス･ベクターと同様。

• m s g q

プロセス関連で共通のアクセス･ベクターに付け加え、以下のアクセ



e n q u e u e キューにメッセージを挿入

表 6 - 1 9 m s g q のアクセス･ベクター

• m s g


s e n d 送信

r e c e i v e 受信

表 6 - 2 0 m s g のアクセス･ベクター

‐143‐

• s h m

プロセス関連で共通のアクセス･ベクターに付け加え、以下のアクセ



l o c k ロック

表 6 - 2 1 s h m のアクセス･ベクター

• s e c u r i t y


c o m p u t e _ a v アクセス・ベクターの計算

c o m p u t e _ c r e a t e s e l i n u x f s ファイルシステムに作成情報を設定

c o m p u t e _ m e m b e r s e l i n u x f s ファイルシステムにメンバー情報を設

定

c h e c k _ c o n t e x t s e l i n u x f s ファイルシステムにコンテキストを書き

込み

l o a d _ p o l i c y セキュリティ･ポリシーを読み込み

c o m p u t e _ r e l a b e l s e l i n u x f s ファイルシステムにラベル変更情報を

設定

c o m p u t e _ u s e r s e l i n u x f s ファイルシステムにユーザ情報を設定

s e t e n f o r c e p e r m i s s i v e モードと e n f o r c e i n g モードの切り替

え

s e t b o o l ブーリアン値の設定

s e t s e c p a r a m T B W

表 6 - 2 2 s e c u r i t y のアクセス･ベクター

‐144‐

• s y s t e m


I p c _ i n f o i p c ソケットに関する情報の取得

s y s l o g _ r e a d s y s l o g の読み込み

s y s l o g _ m o d s y s l o g の読み込み、コンソールへの書き出し以外

の操作

s y s l o g _ c o n s o l e s y s l o g のコンソールへの書き出し

表 6 - 2 3 s y s t e m のアクセス･ベクター

• c a p a b i l i t y


c h o w n C h o w n システムコール

D a c _ o v e r r i d e D A C によるアクセス制御の無効化

D a c _ r e a d _ s e a r c h D A C による読み込み権限を無効化

f o w n e r ファイル操作に対するオーナーシップを無効化

f s e t i d S U I D、S G I D フラグを設定する際のチェックを無

効化

k i l l k i l l シグナルの送信

s e t g i d S e t g i d システムコール

s e t u i d S e t u i d システムコール

s e t p c a p ケイパビリティの設定

l i n u x _ i m m u t a b l e S _ I M M U TA B L E、S _ A P P E N D のファイル属性

を無効化

N e t _ b i n d _ s e r v i c e 1 0 2 4 番までのポートの使用

N e t _ b r o a d c a s t ブロードキャストの送受信

N e t _ a d m i n ネットワーク設定の変更

N e t _ r a w r a w ソケットの使用

‐145‐

I p c _ l o c k 共有メモリのロック

I p c _ o w n e r I P C のオーナーシップを無効化

S y s _ m o d u l e カーネルモジュールのインストールと削除

S y s _ r a w i o r a w I / O の実行

S y s _ c h r o o t C h r o o t システムコール

S y s _ p t r a c e プロセスのトレース

S y s _ p a c c t プロセスのアカウンティング情報の変更

S y s _ a d m i n システム管理用の様々なシステムコール

S y s _ b o o t リブート

S y s _ n i c e n i c e システムコール

S y s _ r e s o u r c e リソースに関する様々なシステムコール

S y s _ t i m e 時刻の設定

S y s _ t t y _ c o n f i g 端末の設定の変更

m k n o d M k n o d システムコール

l e a s e l e a s e の許可

a u d i t _ w r i t e 監査ログの書き込み

a u d i t _ c o n t r o l 監査システムの管理や設定変更

表 6 - 2 4 c a p a b i l i t y のアクセス･ベクター

• p a s s w d


p a s s w d パスワードの変更

c h f n アカウント情報の変更

c h s h ログインシェルの変更

r o o t o k ユーザが r o o t の際にパスワードの更新を許可

c r o n t a b T B W

表 6 - 2 5 p a s s w d のアクセス･ベクター

‐146‐

上記以外のオブジェクト・クラスのアクセス・ベクターを以下に示す。

オブジェクト・クラス名アクセスベクター名

C r e a t e

D e s t r o y

D r a w

C o p y

D r a w a b l e

G e t a t t r

C r e a t e

F r e e

G e t a t t r

G c

S e t a t t r

A d d c h i l d

C r e a t e

D e s t r o y

M a p

U n m a p

C h s t a c k

C h p r o p l i s t

C h p r o p

L i s t p r o p

G e t a t t r

S e t a t t r

S e t f o c u s

M o v e

C h s e l e c t i o n

Wi n d o w

C h p a r e n t

‐147‐

C t t l l i f e

E n u m e r a t e

Tr a n s p a r e n t

M o u s e m o t i o n

c l i e n t c o m e v e n t

I n p u t e v e n t

D r a w e v e n t

w i n d o w c h a n g e e v e n t

w i n d o w c h a n g e r e q u e s t

s e r v e r c h a n g e e v e n t

e x t e n s i o n e v e n t

l o a d

f r e e

g e t a t t r

F o n t

u s e

c r e a t e

f r e e

i n s t a l l

u n i n s t a l l

l i s t

r e a d

s t o r e

g e t a t t r

C o l o r m a p

s e t a t t r

c r e a t e

f r e e

P r o p e r t y

r e a d

‐148‐

w r i t e

c r e a t e

c r e a t e g l y p h

f r e e

a s s i n g n

C u r s o r

s e t a t t r

X c l i e n t k i l l

l o o k u p

g e t a t t r

s e t a t t r

s e t f o c u s

w a r p p o i n t e r

p a s s i v e g r a b

a c t i v e g r a b

u n g r a b

b e l l

m o u s e m o t i o n

X i n p u t

r e l a b e l i n p u t

s c r e e n s a v e r

g e t h o s t l i s t

s e t h o s t l i s t

g e t f o n t p a t h

s e t f o n t p a t h

g e t a t t r

g r a b

X s e r v e r

u n g r a b

X e x t e n s i o n q u e r y

‐149‐

u s e

p a g e e x e c

e m u t r a m p

m p r o t e c t

r a n d m m a p

r a n d e x e c

P a x

s e g m e x e c

ソケット関連で共通のアクセス・ベクター

n l m s g _ r e a d

n e t l i n k _ r o u t e _ s o c k e t

n e t l i n k _ f i r e w a l l _ s o c k e t

n e t l i n k _ t c p d i a g _ s o c k e t

n e t l i n k _ x f r m _ s o c k e t

n e t l i n k _ a u d i t _ s o c k e t

n e t l i n k _ i p 6 f w _ s o c k e t n l m s g _ w r i t e

n e t l i n k _ n f l o g _ s o c k e t

n e t l i n k _ s e l i n u x _ s o c k e t

n e t l i n k _ d n r t _ s o c k e t

プロセス関連で共通のアクセス･ベクター

a c q u i r e _ s v c D b u s

s e n d _ m s g

g e t p w d

g e t g r p

g e t h o s t

g e t s t a t

a d m i n

s h m e m p w d

s h m e m g r p

N s c d

S h m e m h o s t

A s s o c i a t i o n S e n d t o

‐150‐

R e c v f r o m

表 6 - 2 6 その他オブジェクト・クラスのアクセス・ベクター

6 .3 .6 ドメイン遷移の動的な選択

ドメイン遷移は、「遷移元のドメイン」と「プログラムファイルのオブジェク

ト・タイプ」の組み合わせに対して「遷移後のドメイン」が決定される。これ

らの遷移はポリシー･ファイルに記述されており、システム稼動中は変更

できない。しかし、幾つかのアプリケーションでは遷移後のドメインを動的

に決定したい場合がある。例えば s s h d では認証されたユーザのシェルを、

そのユーザのドメインで起動するようにしたい場合である。

s e t e x e c c o n は、ドメイン遷移の動的な選択を実現するシステムコー

ルである。プログラム起動に先立って、本システムコールを呼び出すこと

によって e x e c システムコールより起動されたプログラムのドメインが指定し

たドメインになる。

i n t s e t e x e c c o n ( s e c u r i t y _ c o n t e x t _ t c o n t e x t ) ;

先ほどの s s h の例を具体的に説明する。まず、ユーザのリクエストに応

じて s s h d が f o r k され、ユーザの認証が行われる。PA M によってユーザ

が承認されると、承認されたユーザのコンテキスト（ドメイン）が

s e t e x e c c o n により設定される。次にユーザのシェルを e x e c するために

s s h d がさらに f o r k される。複製されたプロセスは、ユーザのシェルを

e x e c する。この際に、ドメイン遷移が行われるが、遷移先のドメインとして

s e t e x e c c o n で設定したユーザのドメインが使用される。これにより、ユー

ザのドメインでシェルが起動されることになる。

‐151‐

図 6 - 6 s e t e x e c c o n とドメイン遷移

6 .4 Trusted So lar i s

6 .4 .1 格付けとコンパートメントの設定

格付けとコンパートメントの定義は l a b e l _ e n c o r d i n g ファイルによって

設定される。

6 . 4 . 1 . 1 格付け

格付けは、機密ラベルの信頼度を階層的に表している。格付けの定

義は l a b e l _ e n c o r d i n g ファイル内の C L A S S F I C AT I O N セクションに

sshdsshd

bashbash

sshdsshd

sshdsshd

fork

fork

access

pam call

setexeccon(userX_t)

exec

granted

denied

exit

process 1sid: sshd_tuid: root



process 3sid: userX_tuid: userX

sshdsshd

bashbash

sshdsshd

sshdsshd

fork

fork

access

pam call

setexeccon(userX_t)

exec

granted

denied

exit




process 3sid: userX_tuid: userX

‐152‐

以下のように記述される。

n a m e = P U B L I C ; s n a m e = P U B ; v a l u e = 5 0 ;

上記の例では、n a m e タグにより、P U B L I C という名称の格付けが定

義される。また、 s n a m e タグにより略称が定義され、v a l u e により格付け

の信頼度が定義される。信頼度は、1～2 5 5 の数字であり、数字が大き

いほど優位の格付けを示す。格付けの設定時に使用できる各タグの概

要を、以下に示す。

タグ概要

n a m e 格付けの名称

s n a m e 略称

a n a m e 代替名称

v a l u e 格付けの値

i n i t i a l

c o m p a r t m e n t

デフォルトで設定されるコンパートメント

表 6 - 2 7 格付けの設定時に使用できるタグ

6 . 4 . 1 . 2 コンパートメント

コンパートメントは、機密ラベルの区分を示している。コンパートメントの

定義は l a b e l _ e n c o r d i n g ファイル内の W O R D S セクションに以下のよう

に記述される。

n a m e = w e b ; s n a m e = w e b ; m a x c l a s s = P U B ;

c o m pa r t m e n ts = 5 0 - 6 0 ;

‐153‐

上記の例では、n a m e タグにより w e b という名称のコンパートメントが

定義される。また、 s n a m e タグより略称が定義され、m a x c l a s s によりコ

ンパートメントの利用可能な格付けの上限が定義される。

c o m p a r t m e n t s タグはコンパートメントのビット列を示し、優位のコンパー

トメントとは劣位のコンパートメントのビット列を全て含むことを指す。コン

パートメントの設定時に使用できる各タグの概要を、以下に示す。

タグ概要

n a m e コンパートメントの名称

s n a m e 略称

p r e f i x 接頭文字

s u f f i x 接尾文字

c o m p a r t m e n t s コンパートメントのビット列

m i n i c l a s s コンパートメントの利用可能な格付けの下限

m a x c l a s s コンパートメントの利用可能な格付けの上限

o m n i c l a s s i n i t i a l c o m p a r t m e n t s から隠蔽する文字

表 6 - 2 8 コンパートメントの設定時に使用できるタグ

6 . 4 . 1 . 3 格付けとコンパートメントの制約

格付けとコンパートメントは、その組み合わせに対して制約をかけること

が出来る。これらの制約の定義は、 l a b e l _ e n c o r d i n g ファイル内の

A C C R E D I TAT I O N R A N G E S セクションに以下のように記述される。

c l a s s i f i c a t i o n = P U B ; a l l c o m pa r t m e n t c o m b i n a t i o n s v a l i d ;

‐154‐

上記の例では、P U B L I C 格付けに対して、全てのコンパートメントの

組み合わせが許可されている。これらのタグの概要を以下に示す。

タグ概要

C l a s s i f i c a t i o n 格付けの名称

o n l y v a l i d c o m p a r t m e n t

c o m b i n a t i o n s

有効なコンパートメントの列挙

a l l c o m p a r t m e n t

c o m b i n a t i o n s v a l i d e x c e p t

有効でないコンパートメントの列挙

a l l c o m p a r t m e n t

c o m b i n a t i o n s v a l i d

全てのコンパートメントは有効

表 6 - 2 9 格付けとコンパートメントの組み合わせを制約するためのタグ

6 .4 .2 特権

プログラムに対して付与することの出来る特権を以下に列挙する。

• ファイルシステム関連の特権

特権概要

F i l e _ a u d i t ファイルやディレクトリの監査事前選択情報の

設定と取得

F i l e _ c h o w n ファイル所有者の変更

F i l e _ d a c _ e x e c u t e D A C に制限されない実行

F i l e _ d a c _ r e a d D A C に制限されない読み込み

F i l e _ d a c _ s e a r c h D A C に制限されない検索

F i l e _ d a c _ w r i t e D A C に制限されない書き込み

F i l e _ d o w n g r a d e _ s l 優位でない機密ラベルの設定

‐155‐

F i l e _ l o c k 保持しないファイルロックのロック情報の取得

f i l e _ m a c _ r e a d M A C に制限されない読み込み

f i l e _ m a c _ s e a r c h M A C に制限されない検索

f i l e _ m a c _ w r i t e M A C に制限されない書き込み

f i l e _ o w n e r 所有しないファイルのアクセス時刻、修正時

刻、監査事前選択属性、特権、機密ラベルの

変更

f i l e _ s e t d a c パーミッションと A C L の属性の変更

f i l e _ s e t i d s e t - u s e r - I D と s e t - g r o u p - I D の設定

f i l e _ s e t p r i v 特権の設定

f i l e _ u p g r a d e _ s l 優位な機密ラベルの設定

表 6 - 3 0 ファイルシステム関連の特権

• S y s t e m V I P C 関連の特権

（ I P C メッセージキュー・セマフォセット・共有メモリセグメントに対する

操作）

特権概要

I p c _ d a c _ r e a d D A C に制限されない読み込み

I p c _ d a c _ w r i t e D A C に制限されない書き込み

I p c _ m a c _ r e a d M A C に制限されない読み込み

I p c _ m a c _ w r i t e M A C に制限されない書き込み

I p c _ o w n e r 削除と、パーミッションと A C L の変更

表 6 - 3 1 S y s t e m V I P C 関連の特権

‐156‐

• ネットワーク関連の特権

特権概要

N e t _ b r o a d c a s t ブロードキャストマルチキャストの送信

N e t _ d o w n g r a d e _ s l 書き込み中のデータか、ネットワークのエンドポイ

ントに優位でない機密ラベルを設定

N e t _ m a c _ r e a d マルチレベルポートのバインドとアクセプト

N e t _ p r i v a d d r 特権ポートのバインド

N e t _ r a w a c c e s s ネットワーク層に対する直接アクセス

N e t _ r e p l y _ e q u a l 受け取った機密ラベルでの返信

N e t _ s e t c l r 書き込み中のデータか、ネットワークのエンドポイ

ントに認可上限を設定

N e t _ s e t i d

N e t _ s e t p r i v 書き込み中のデータか、ネットワークのエンドポイ

ントに特権を設定

N e t _ u p g r a d e _ s l 書き込み中のデータか、ネットワークのエンドポイ

ントに優位な機密ラベルを設定

表 6 - 3 2 ネットワーク関連の特権

• プロセス関連の特権

特権概要

P r o c _ a u d i t _ a p p l T C B イベント番号外の監査イベントに

対する監査ログの作成

P r o c _ a u d i t _ t c b T C B イベント番号外の監査イベントに

対する監査ログの作成

P r o c _ c h r o o t ルートディレクトリの変更

P r o c _ d e b u g _ n o n t r a n q u i t l 機密ラベルを変更する際のプロセスオ

ブジェクトに対する一定の操作

‐157‐

P r o c _ d u m p c o r e s e t - u s e r - I D、 s e t - g r o u p - I D またはパ

ーミッションの付いた T C B プロセスの実

行、または、シグナルを受け取り c o r e フ

ァイルを作成するための特権を付与さ

れたプロセスの実行

P r o c _ m a c _ r e a d 優位な機密ラベルを持つプロセスからの

読み込み

P r o c _ m a c _ w r i t e 優位な機密ラベルを持つプロセスからの

書き込み

P r o c _ n o d e l a y 秘密チャネルと識別される操作が行わ

れる際に、プロセスを遅延させない設定

P r o c _ o w n e r プロセスの所有者以外の読み込みや書

き込み

P r o c _ s e t c l r プロセスの認可上限を設定

P r o c _ s e t i d プロセスに異なる U I G と G I D を設定

P r o c _ s e t s l プロセスに異なる機密ラベルを設定

P r o c _ t r a n q u i l 他のプロセスにプロセスオブジェクトが使

用されている際に、異なる機密ラベルを

設定

表 6 - 3 3 プロセス関連の特権

• システム関連の特権

特権概要

S y s _ a u d i t 監査デーモンの起動

S y s _ b o o t システムの h a l t , r e b o o t , s u s p e n d

S y s _ c o n f i g メモリマップドファイルと共有メモリセグメントのロ

ックとアンロック

‐158‐

S y s _ c o n s o l e コンソール出力を他のデバイスにリダイレクト

S y s _ d e v i c e デバイススペシャルファイルの生成

S y s _ f s _ c o n f i g ファイルシステムロックの操作

S y s _ i p c _ c o n f i g I P C メッセージキューのバッファサイズを拡張

S y s _ m a x p r o c プロセスの最大数を超えて、プロセスを生成

S y s _ m i n f r e e ファイルシステムの空き領域が最低値を越えた

場合の書き込み

S y s _ m o u n t ファイルシステムへのマウント

S y s _ n e t _ c o n f i g インタフェース及びルーティングの設定

S y s _ n f s N F S デーモンの起動

S y s _ s u s e r _ c o m p a t s u s e r システムコール

S y s _ s y s e m _ d o o r 全ての機密ラベルから使用される d o o r の生成

S y s _ t r a n s _ l a b e l 優位でない機密ラベルの「外部文字列形式」

とラベルの変換

表 6 - 3 4 システム関連の特権

• ウィンドウ関連の特権

特権概要

Wi n _ c o l o r m a p カラーマップの制約を越える操作

Wi n _ c o n f i g X サーバーに永続的に維持されるリソースの設

定と削除

Wi n _ d a c _ r e a d 所有者でないウィンドウリソースに対する読み

込み

Wi n _ d a c _ w r i t e 所有者でないウィンドウリソースに対する書き

込み

Wi n _ d e v i c e 入力デバイスの処理の実行

Wi n _ d g a ダイレクトグラフィックアクセス拡張プロトコルの

‐159‐

使用

Wi n _ d o w n g r a d e _ s l ウィンドウの機密ラベルを、優位でない機密ラ

ベルに設定

Wi n _ f o n t p a t h フォントパスの設定

Wi n _ m a c _ r e a d 優位でない機密ラベルのウィンドウからの読み

込み

Wi n _ m a c _ w r i t e 優位でない機密ラベルのウィンドウからの書き

込み

Wi n _ s e l e c t i o n 特別な仲介なしにウィンドウ間でのデータを移

動

Wi n _ u p g r a d e _ s l ウィンドウの機密ラベルを、優位な機密ラベル

に設定

表 6 - 3 5 ウィンドウ関連の特権

6 .5 Apache

6 .5 .1 認証（A u t h e n t i ca t i o n）

認証とは、正規のユーザであることを確認する仕組みを指す。

以下に述べるような様々な認証によって、正規のユーザであることを確

認すると共に、認証後に割り振られるユーザとグループを制御する。

6 . 5 . 1 . 1 認証方式の種類

認証方式は、下表の通りである。

種類解説

匿名認証ユーザ名やパスワードの指定なしに We b サイトにアクセス

する方式。

‐160‐

特定の認証方式を設定しない場合、この匿名認証が

使用される。

認証に成功したユーザに対しては、A p a c h e の実行ユー

ザとグループが割り振られる。

基本認証ユーザ名とパスワードを入力させて認証を行う方式。

ただし、ユーザ名やパスワードは暗号化されずにネットワ

ークを流れるため、セキュリティ上の問題がある。



ダイジェスト

認証

基本認証と同様にユーザ名とパスワードにより認証を行

う方式。

ただし、ユーザ名とパスワードをハッシュ値として送信する

ため、セキュリティの面で優れている。



D B M 認証基本認証と同様の認証方式。A p a c h e にのみ存在。

ユーザ名とパスワードのリストをデータベースとして保持し

ているため、大規模なシステムにおいてパフォーマンスに

優れる。



L D A P 認証ユーザ情報に L D A P を使った認証方式。



証明書認証 S S L のセキュリティ機能を使った認証方式。

サーバー証明書ではユーザによる We b サイトの認証を

行うことができ、クライアント証明書では We b サイトによる

‐161‐

ユーザの認証を行うことができる。

認証に成功したユーザに対しては、予めマップしたユー

ザと、そのユーザの所属するグループが割り振られる。

表 6 - 3 6 A p a c h e の認証方式

6 . 5 . 1 . 2 S u E x e c

通常、A p a c h e では、 c g i の実行権限に We b サーバーの実行ユーザ

とグループが使われる。しかし、このように同一の実行権限で c g i が実行

されてしまうと、アクセス制御を行う事が難しくなり、セキュリティ上の問題

となる。

そこで c g i の実行権限を制御する機能が必要となるが、これを実現す

るのが S u E x e c である。

S u E x e c を使うことで、仮想ホスト内、または、ユーザ管理のディレクト

リ内（p u b l i c _ h t m l など）に存在する c g i に対して、その c g i の実行ユー

ザとグループを制御する事が出来る。

6 .5 .2 認可（A u t h o r i z a t i o n）

認証されたユーザに対して、アクセス権限の制御を行う仕組み。

ユーザの操作対象と、その対象に関するユーザのアクセス権限により

認可を行う。

6 . 5 . 2 . 1 権限の種類

We b サーバーのアクセス制御には、We b サーバー自身が持つアクセ

ス制御の仕組みを利用する場合と、ファイルシステムに実装されたアクセ

ス制御の仕組みを利用する場合がある。ここでは、A p a c h e の実装する

‐162‐

アクセス制御とファイルシステムの実装するアクセス制御について解説す

る。

A . A p a c h e の実装するアクセス制御

A p a c h e の実装するアクセス制御については、下表の通りである。

アクセス制御解説

E x e c C G I C G I の実行を許可する。

I n c l u d e s S S I の実行を許可する。

I n c l u d e s N O E X E C # e x e c , # i n c l u d e の命令を無効にして、

S S I の実行を許可する。

I n d e x e s D i r e c t o r y I n d e x で指定したファイル

（ i n d e x . h t m l など）が存在しない場合、

ディレクトリ内の一覧の参照を許可する。

M u l t i Vi e w s M u l t i v i e w s を許可する。

F l l o w S y m L i n k s シンボリックを辿ることを許可する。

S y m L i n k s I f O w n e r M a t c h シンボリックリンク先のファイルかディレクト

リが、シンボリックリンクの所有者と同じ場

合に限り、リンクを辿ることを許可する。

A l l M u l t i v i e w s を除いた上記全て。

A l l o w リクエスト元の I P アドレスや、ネットワーク

セグメント、環境変数として取得された値

によって、対象にアクセスすることを許可

する。

D e n y リクエスト元の I P アドレスや、ネットワーク

セグメント、環境変数として取得された値

によって、対象にアクセスすることを拒否

‐163‐

する。

O r d e r A l l o w と D e n y の評価される順番を制御

する。

表 6 - 3 7 A p a c h e の実装するアクセス制御

B . ファイルシステムの実装するアクセス制御

ファイルシステムの実装するアクセス制御については、P o s i x 準拠のファ

イルシステムと N T F S についてそれぞれ解説する。

1 . P o s i x 準拠のファイルシステム

P o s i x 準拠のファイルシステムは、アクセス制御のために、下表

のようなアクセス権限を持っている。

アクセス権限解説

読み込みファイルに対しては、ファイルを読み込む権限。ディ

レクトリに対しては、ディレクトリに対して、 ” l s ”できる

権限。

書き込みファイルに対しては、ファイルを変更する権限。ディ

レクトリに対しては、ディレクトリの中でファイルを作

成・削除する権限。

実行およびディレ

クトリ内容の一覧

表示

ファイルに対しては、ファイルを実行する権限。ディ

レクトリに対しては、ディレクトリ内のファイルにアクセ

スする権限。

表 6 - 3 8 P o s i x 準拠のファイルシステムのアクセス権限

‐164‐

2 . N T F S

N T F S では、アクセス制御のために、以下のようなアクセス権限

を持っている。

N T F S のアクセス権限には、フルコントロール、変更、読み取りと

実行、フォルダの内容の一覧表示、読み取り、書き込みの 5 つ

が存在する。

それぞれのアクセス権限は、以下の 1 4 の論理グループから構

成されている。

i . フォルダのスキャンとファイルの実行

フォルダに対しては、他のファイルまたはフォルダにアクセス

するために、フォルダ間を移動する権限（フォルダのスキャ

ン）。

ファイルに対しては、プログラムの実行権限（ファイルの実

行）。

i i . フォルダの一覧 /データの読み取り

フォルダに対しては、フォルダ内のファイル名とサブフォルダ

名を表示する権限（フォルダの一覧）。

ファイルに対しては、ファイルのデータを表示する権限（デー

タの読み取り）。

i i i . 属性の読み取り

ファイルシステムによって定義されたファイル、または、フォル

ダの属性を表示する権限。

i v . 拡張属性の読み取り

プログラムによって定義されたファイル、または、フォルダの拡

張属性を表示する権限。

v . ファイルの作成 /データの書き込み

フォルダに対しては、フォルダ内でファイルの作成を許可す

‐165‐

る権限。

ファイルに対しては、ファイルの変更及び内容の上書きを許

可する権限。

v i . フォルダの作成 /データの追加

フォルダに対しては、フォルダ内でフォルダの作成を許可す

る権限。

ファイルに対しては、既存のデータの変更、削除、または、

上書きを伴わないファイル末尾に対する変更を許可する権

限。

v i i . 属性の書き込み


ダの属性を変更する権限。

v i i i . 拡張属性の書き込み


張属性を変更する権限。

i x . サブフォルダとファイルの削除

サブフォルダ、または、ファイルに「削除」権限が付与されて

いない場合にも、それらの削除を許可する権限。

x . 削除

ファイル、または、サブフォルダの削除を許可する権限。

x i . アクセス許可の読み取り

ファイル、または、フォルダのアクセス許可の読み取りを許可

する権限。

x i i . アクセス許可の変更

ファイル、または、フォルダのアクセス許可の変更を許可する

権限。

x i i i . 所有権の取得

ファイル、または、フォルダの所有権の取得を許可する権

‐166‐

限。

x i v . 同期

ファイル、または、フォルダのハンドルに複数のスレッドが動

作し、他のスレッドと同期することを許可する権限。

フ

ル

コ

ン

ト

変

更

読

み

取

り

と

実

フ

ォ

ル

ダ

の

内

読

み

取

り書

き

込

み

フォルダのスキ

ャンとファイル

の実行

○ ○ ○ ○

フォルダの一覧

/データの読み

取り

○ ○ ○ ○ ○

属性の読み取り ○ ○ ○ ○ ○

拡張属性の読み

取り

○ ○ ○ ○ ○

ファイルの作成

/データの書き

込み

○ ○ ○

フォルダの作成

/データの追加

○ ○ ○

属性の書き込み ○ ○ ○

拡張属性の書き

込み

○ ○ ○

サブフォルダと

ファイルの削除

○

削除 ○ ○

‐167‐

アクセス許可の

読み取り

○ ○ ○ ○ ○ ○


変更

○

所有権の取得 ○

同期 ○ ○ ○ ○ ○ ○

表 6 - 3 9 N T F S のアクセス権限と論理グループ

6 . 5 . 2 . 2 認可の対象

A . 対象の種類

認可の対象の種類については、下表の通りである。

認可の対象解説

ファイル個々のファイル

ファイル（正規表現による

マッチ）

ファイル名が、指定された正規表現でマ

ッチしたファイル

ディレクトリ個々のディレクトリ

ディレクトリ（正規表現によ

るマッチ）

ディレクトリ名が、指定された正規表現で

マッチしたディレクトリ

ロケーションドキュメントルートからのパス

We b サイト全体を指定することも可能

ロケーション（正規表現に

よるマッチ）

ドキュメントルートからのパスが、指定され

た正規表現マッチしたパス

表 6 - 4 0 A p a c h e の認可の対象の種類

‐168‐

B . 対象の仮想化

■ ファイル単位の仮想化

A p a c h e では a l i a s ディレクティブを使うことで実現できる。

■ ディレクトリ単位の仮想化

A p a c h e では、a l i a s ディレクトリを使うことで実現できる。

6 .6 I IS

6 .6 .1 認証（A u t h e n t i ca t i o n）

6 . 6 . 1 . 1 認証方式の種類

認証方式は、下表の通りである。

種類解説

匿名認証ユーザ名やパスワードの指定なしに We b サイトにアクセ

スする方式。

特定の認証方式を設定しない場合、この匿名認証が

使用される。

認証に成功したユーザに対しては、

I S U R _ c o m p u t e r n a m e というユーザと G u e s t グルー

プが割り振られる。

基本認証ユーザ名とパスワードを入力させて認証を行う方式。

ただし、ユーザ名やパスワードは暗号化されずにネットワ

ークを流れるため、セキュリティ上の問題がある。

認証に成功したユーザに対しては、認証に成功したユ

ーザと、そのユーザの所属するグループが割り振られ

る。

‐169‐

ダイジェスト

認証

基本認証と同様にユーザ名とパスワードにより認証を

行う方式。

ただし、ユーザ名とパスワードをハッシュ値として送信す

るため、セキュリティの面で優れている。

I I S では We b D AV ディレクトリで使用できる。



る。

高度ダイジ

ェスト認証

ダイジェスト認証よりセキュリティの面で優れた認証方

式。

I I S にのみ存在。

ダイジェスト認証と違い、ドメインコントローラの A c t i v e

D i r e c t o r y でもユーザ情報をハッシュ値として保存して

いる。



る。

統合

Wi n d o w s

認証

ブラウザの動作している Wi n d o w s マシンにログインして

いるユーザ名とパスワードを使う認証方式。 I I S にのみ

存在。

ユーザ名とパスワードはハッシュ値として送信される。



る。

証明書認

証

S S L のセキュリティ機能を使った認証方式。

サーバー証明書ではユーザによる We b サイトの認証を

行うことができ、クライアント証明書では We b サイトによ

‐170‐

るユーザの認証を行うことができる。

認証に成功したユーザに対しては、予めマップしたユー

ザと、そのユーザの所属するグループが割り振られる。

表 6 - 4 1 I I S の認証方式

6 .6 .2 認可（A u t h o r i z a t i o n）

6 . 6 . 2 . 1 権限の種類

ここでは、 I I S の実装するアクセス制御とファイルシステムの実装するア

クセス制御について解説する。

A . I I S の実装するアクセス制御

I I S は、アクセス制御のために、下表のようなアクセス権限を持ってい

る。

アクセス制御解説

読み取りファイル、または、ディレクトリの内容やプロパティ

を参照できる権限

書き込みファイル、または、ディレクトリの内容やプロパティ

を変更できる権限

スクリプトソースアク

セス

スクリプトのソースファイルにアクセスできる権限

ディレクトリの参照ファイルの一覧とコレクションを参照できる権

限

実行アクセス権スクリプトを実行する際の適切なレベルを、以下

より選択する。

1 . なし

2 . スクリプトのみ

‐171‐

3 . スクリプト及び実行可能ファイル

表 6 - 4 2 I I S の実装するアクセス制御

B . ファイルシステムの実装するアクセス制御

1 . N T F S

N T F S では、アクセス制御のために、以下のようなアクセス権限

を持っている。

N T F S のアクセス権限には、フルコントロール、変更、読み取りと

実行、フォルダの内容の一覧表示、読み取り、書き込みの 5 つ

が存在する。

それぞれのアクセス権限は、以下の 1 4 の論理グループから構

成されている。

i . フォルダのスキャンとファイルの実行

フォルダに対しては、他のファイルまたはフォルダにアクセス

するために、フォルダ間を移動する権限（フォルダのスキャ

ン）。

ファイルに対しては、プログラムの実行権限（ファイルの実

行）。

i i . フォルダの一覧 /データの読み取り

フォルダに対しては、フォルダ内のファイル名とサブフォルダ

名を表示する権限（フォルダの一覧）。

ファイルに対しては、ファイルのデータを表示する権限（デー

タの読み取り）。

i i i . 属性の読み取り


ダの属性を表示する権限。

‐172‐

i v . 拡張属性の読み取り


張属性を表示する権限。

v . ファイルの作成 /データの書き込み

フォルダに対しては、フォルダ内でファイルの作成を許可す

る権限。

ファイルに対しては、ファイルの変更及び内容の上書きを許

可する権限。

v i . フォルダの作成 /データの追加

フォルダに対しては、フォルダ内でフォルダの作成を許可す

る権限。

ファイルに対しては、既存のデータの変更、削除、または、

上書きを伴わないファイル末尾に対する変更を許可する権

限。

v i i . 属性の書き込み


ダの属性を変更する権限。

v i i i . 拡張属性の書き込み


張属性を変更する権限。

i x . サブフォルダとファイルの削除

サブフォルダ、または、ファイルに「削除」権限が付与されて

いない場合にも、それらの削除を許可する権限。

x . 削除

ファイル、または、サブフォルダの削除を許可する権限。

x i . アクセス許可の読み取り

ファイル、または、フォルダのアクセス許可の読み取りを許可

する権限。

‐173‐

x i i . アクセス許可の変更

ファイル、または、フォルダのアクセス許可の変更を許可する

権限。

x i i i . 所有権の取得

ファイル、または、フォルダの所有権の取得を許可する権

限。

x i v . 同期

ファイル、または、フォルダのハンドルに複数のスレッドが動

作し、他のスレッドと同期することを許可する権限。

フ

ルコ

ン

ト

変

更

読

み

取

り

と

実

フ

ォ

ル

ダ

の

内

読

み

取

り

書

き

込

み

フォルダのスキ

ャンとファイル

の実行

○ ○ ○ ○

フォルダの一覧 /

データの読み取

り

○ ○ ○ ○ ○

属性の読み取り ○ ○ ○ ○ ○

拡張属性の読み

取り

○ ○ ○ ○ ○

ファイルの作成 /

データの書き込

み

○ ○ ○

フォルダの作成 /

データの追加

○ ○ ○

属性の書き込み ○ ○ ○

‐174‐

拡張属性の書き

込み

○ ○ ○

サブフォルダと

ファイルの削除

○

削除 ○ ○


読み取り

○ ○ ○ ○ ○ ○


変更

○

所有権の取得 ○

同期 ○ ○ ○ ○ ○ ○

表 6 - 4 3 N T F S のアクセス権限と論理グループ

6 . 6 . 2 . 2 認可の対象

A . 対象の種類

認可の対象の種類については、下表の通りである。

認可の対象解説

ファイル個々のファイル

ディレクトリ個々のディレクトリ

表 6 - 4 4 I I S の認可の対象の種類

B . 対象の仮想化

ディレクトリ単位の仮想化

I I S では、仮想ディレクトリを使うことで実現できる。

‐175‐

7 おわりに

本報告書は、「強制的アクセス制御に基づく We b サーバーに関する

調査・設計」に関する調査報告書である。

本調査報告書の第 1 部「強制的アクセス制御に関するセキュリティ・

ポリシー・モデルの We b サーバーへの適用性の調査編」では、強制的ア

クセス制御を採用するセキュリティ・ポリシー・モデルを調査し、その We b

サーバーへの適用性を検証した。この検証にあたり、始めに We b サーバ

ーをモデル化すると共に、We b サーバーの脆弱性を検証し、アクセス制

御の要件定義を行った。この結果を元に、既存のセキュリティ・ポリシー・

モデルの適用性を検証した。

続く第 2 部の「既存 We b サーバー・システムにおけるアクセス制御の

調査編」では、強制的アクセス制御を実現する既存 We b サーバーにお

いて、どのようなアクセス制御が行われているかを調査し、その問題点を

検証した。

本調査報告書では、強制的アクセス制御という、アプリケーションの

任意性に依存せずに、セキュリティ管理者によって設定されたセキュリテ

ィ・ポリシーが強制的に適用されるアクセス制御を利用した We b サーバ

ーについて調査した。従来型の一般的な A p a c h e や I I S などの We b

サーバーは、O S から見た時、1 アプリケーションとして動作する。これらの

We b サーバーが提供するアクセス制御は、アプリケーションが任意に行う

ものである。O S のアクセス制御は、We b サーバーが必要とする権限の総

和に基づくものであり、アプリケーションのアクセス制御の妥当性を保障

する手段は無い。

本調査報告書により、We b サーバーの脆弱性、およびアクセス制御

に対する要件定義がされた。この調査結果に基づき、強制的アクセス

制御に基づく We b サーバーの機能設計を行った。その詳細は、機能設

‐176‐

計書を参考にされたい。

Documents

強制的アクセス制御に基づくWebサーバーに関する … › security › fy16 › reports › mandatory...5.4 SELinux SPM.....94 5.4.1 ポリシー・モデルの概要.....94