使って理解しよう！Windows Server 8の姿 第3回

新たに追加された強制アクセス制御「Central Access Policy」

ACLから20年！Windows Server 8で追加の新アクセス制御とは？

　Windowsには、ファイルやシステムへのアクセスを制御する仕組みとして「ACL（Access Control List）」という機能が搭載されている。ACLは20年近く使われているWindowsの基本機能の1つなのだが、より高度なセキュリティが一般的な用途にも必要とされてきた現状に合わせ、Windows Server 8^※には新しいアクセス制御機能が搭載されている。これがどのようなものなのか、アクセス制御の仕組みから見ていこう。

^{※本連載では「Windows Server "8" ベータ版」を扱っていくが、名称が冗長なため本文では「Windows Server 8」と表記する。また、あくまでベータ版であり、最終的な製品版では内容が異なる可能性が高いことを了承していただきたい}

Windows標準「随意アクセス制御」の歴史と限界

　Windowsのセキュリティモデルは「随意アクセス制御（Discretionary Access Control：DAC）」に基づいている。これは「自分が所有権を持つオブジェクトや自分がアクセス許可変更の権利を持っているオブジェクトについては、自由にアクセス許可を変更できる」というものだ。平たくいうと「自分のものは自分で管理する」ことである。

　Windowsで随意アクセス制御を実現したのが冒頭で触れたACLで、これは「随意アクセス制御リスト（DACL：Discretionary Access Control List）」とも呼ぶ。DACLは「誰に」「どのような権利」を与えたのかを示す情報を持ち、フォルダやプリンターなどのオブジェクト属性として保存される（図1）。

図1　随意アクセス制御

　米の情報機関である「国家安全保障局（NSA：National Security Agency）」の下部組織「NCSC（National Computer Security Center）」が発行したセキュリティ評価基準ガイドライン「TCSEC（Trusted Computer System Evaluation Criteria）」では、OSのセキュリティレベルをクラスD、C1、C2、B1、B2、B3、A（クラスAが最高、Dが最低レベルのセキュリティ）に分けていた。

　その後、TCSECは同様のヨーロッパ規格やカナダの規格と統合され、現在では「Common Criteria for Information Technology Security Evaluation」、通称「コモンクライテリア（CC）」として標準化された（ISO/IEC 15408）。米国政府基準もCCに移行済みである。ただし、ここでは分かりやすいTCSECの用語で解説する。

　TCSECには細かな規定が存在するが、筆者が新人研修時代（四半世紀も前の話だ）に習ったのは以下のような分類である。技術的には正確ではないが、単純でわかりやすいので紹介しておこう（繰り返すが、これは不正確な表現であり、一種の「たとえ」として読んでほしい）。

• クラスD…セキュリティなし
• クラスC…一般商用
• クラスB…軍事用
• クラスA…国家安全保障上の最高機密などを扱うシステム用

　クラスCを満たすための条件の1つが「随意アクセス制御」である。これは個人やグループに対して個別のファイルアクセス許可を設定する機能だ。古いUNIXには「所有者」と「所有グループ」の概念しかなく、クラスCを満たさなかった。

　これに対し、現在のWindowsの前身であるWindows NT（1993年）は最初からACLを実装しており、「UNIXよりもセキュア（安全）である」と宣伝されたものだ。もっとも、当時標準的なUNIXにACLはなかったが、実際にはSolarisなどの商用UNIXで早くから実装されていたようである。なお、LinuxのカーネルにACLが標準搭載されたのは、2003年のKernel 2.6からだ。

　ただし、セキュアであるとの宣伝に使われた随意アクセス制御だが、問題点は早くから知られていた。それは「ファイルの所有者が、勝手にファイルのアクセス許可を変更してしまう」というものだ。

　一般に「所有者」は「所有物」を自由に処分する権利を持つ。情報についても同じで、自分の氏名を公開するか、非公開にするかは自分で決める権利がある、というのが随意アクセス制御の考え方だ。

　しかし、コンピュータシステムに保存されている情報は自分の所有物ではない。会社の経営上の機密や顧客から預かった情報は、担当者の一存で公開・非公開を決めることはできない。特に個人情報は、法的な規制があり個人情報保護管理ポリシーに従った運用が強制される。

　そこで登場したのが「強制アクセス制御（Mandatory Access Control：MAC）」で、TCSECのクラスBのための必要条件である。以前は「軍事用」とされていたが、最近では一般企業でも要求されることが増えてきたのだ。

強制アクセス制御（MAC）とは？

　強制アクセス制御は、セキュリティ管理者が定義したポリシーに基づいて、自動的にアクセス許可が設定（強制）され、たとえファイルの所有者であっても変更ができないシステムだ（図2）。

図2　強制アクセス制御の仕組み

　たとえば個人情報の場合は、「個人情報保護規定」というポリシーを顧客に提示し、顧客がそのポリシーに同意した場合に個人情報を提供する。会社は「個人情報保護規定」に添った運用を行なう義務があり、違反した場合には行政指導や罰則がある。担当者の判断で勝手に運用規則を変更することはできない。こうした「ポリシー」を実装するのが強制アクセス制御の目的である。

　強制アクセス制御は、組織運営の理念に添ったものであるが、実際に運用すると「ファイル保護ポリシーの定義が恐ろしく面倒」という運用上の問題が発生する。そのため、以前は情報漏えいが重大な問題となる軍事用途に限って利用されてきた。実際、1980年代にはクラスBを標準機能として実装したOSはなく、オプションとして提供されていたはずである（と筆者は習った）。

　ところが、最近では一般企業でも高いセキュリティが求められるようになってきた。理由は大きく2つある。1つはコンピュータで扱う情報の範囲が拡大したことだ。個人情報はその代表である。もう1つは、ネットワーク、特にインターネットの発達である。以前は大量の情報をコピーする方法が少なかったが、現在ではインターネットに情報を流すことで、大量のデータが簡単に漏えいする。

　Linuxでは、NSAが開発した「SELinux」やNTTデータの「TOMOYO Linux」といったセキュリティモジュールがいち早く実装され、強制アクセス制御を実現している。ところで、筆者の世代では「トモヨ」といえば原田知世に決まっているのだが、TOMOYO Linuxは「カードキャプターさくら」の主人公（木之本桜）の友人「大道寺知世」に由来するらしい（NHKエンタープライズ「カードキャプターさくら 人物紹介」）。「カードキャプターさくら」には「ケルベロス」も登場する。ケルベロスといえばActive Directoryにも使われる認証方式「Kerberos認証」ということで、セキュリティ管理システムの名前としては案外ふさわしいのかもしれない。

　さて、強制アクセス制御を導入する場合にもっとも重要なことは「どのような運用を行なうのか」という計画である。運用ポリシーなしに強制アクセス制御を導入しても、無駄にシステムを複雑化し、面倒になるだけである。多くのLinuxではSELinuxが標準でインストールされるが、（大抵の企業では運用ポリシーがないので）SELinuxを無効にするのがLinux管理者の最初の仕事だ、という冗談があるくらいだ。

　このように強制アクセス制御の利用には準備が重要なため、Windows Server 8でも標準では利用できず、管理者が明示的に追加する必要がある。

試すに試せないWindows Server 8の強制アクセス制御「Central Access Policy」

　さて、本来ならここでWindows Server 8 での実装を紹介するところだ。ところが、実装を試すことはできなかった。マイクロソフトから提供されているデモシナリオが正常に動作しないからだ。

　2月29日のWindows Server 8およびWindows 8のベータ版（CP版）公開と同時に、マイクロソフトの管理者向け情報サイト「TechNet」などでは大量の情報が公開された（一部は日本語化済み）。強制アクセス制御に関する情報は、以下で扱っている（現時点では英語のみ）。

Deploy a Central Access Policy (Demonstration Steps)

　マイクロソフトは「強制アクセス制御」とは呼ばず「Central Access Policy」と呼ぶが、シナリオを見ると明らかに強制アクセス制御の実装だ。ここによると、Central Access Policyを構成するための大ざっぱな手順は以下の通りである。

1. 計画…どのようなセキュリティポリシーが必要かを計画
2. 実装…セキュリティポリシーを定義
3. 展開…セキュリティポリシーをサーバーに適用
4. 保守…セキュリティポリシーの変更などの保守作業

　なお、「Central Access Policy」は、ファイル監査や分類の拡張機能を含む「Dynamic Access Control」の一部と考えられている。

　手順のうちの実装では、

1. 「クレーム（要求）タイプ」の定義（たとえば部署や国といったタイプ）
2. 定義したクレームを有効化
3. 集中アクセスルール（Central Access Rule：CAR）を構成（次の「集中アクセスポリシー」の入れ物となる）
4. 集中アクセスポリシー（Central Access Policy ： CAP）を構成。具体的なアクセス規定を定義する（図3）


図3　集中アクセスポリシーを構成

5. CAPを公開
6. Kerberos認証システムに対して、要求を認識させる（図4）


図4　Kerberos認証システムに対して、要求を認識させる

という作業を行なう。ほとんどの操作はPowerShellで行ない、GUIは用意されていないようだ。

　実際に試してみたところ、多くのステップでエラーが発生し、残念ながら試用は断念することとなった。マイクロソフトの公開情報では、一部の手順が抜けているようである。他にも誤記らしきものも見られた。

　続く展開は、個々のファイルサーバーにCAPを適用する作業で、グループポリシーを利用する。最後の保守は、GUIまたはPowerShellを使って行なうようだ。

アクセス許可申請

　SharePoint ServerやActive Directory RMS（Rights Management Service）では、アクセス許可のないファイルにアクセスした場合、ダイアログボックスにメールアドレスやURLを表示して、アクセス許可申請を出せるようになっている（リンク先をどのように使うかは管理者が決める）。

　しかし、一般のファイルアクセスについてはこうした配慮はまったく存在せず、アクセスできない場合は単に拒否されるだけである。例外的に、Windows Server 2003 R2から追加された「ファイルサーバーリソースマネージャ（FSRM）」では、ファイルの利用ルールに違反した場合、ユーザーに電子メールを送信できるが、その場でメッセージが表示されるわけではない（コマンド実行は可能だが、Windows Vista以降ではサービスがログオン中の画面にメッセージを出すことはできない）。

　Windows Server 8では、こうした問題点が解消され、アクセスが拒否された場合の問い合わせ先を構成できる。ファイルアクセスに失敗した場合に表示されるダイアログボックスを拡張し、わかりやすいメッセージや電子メールの送信窓口を表示することが可能なのだ。

　ただし、TechNetの資料を読む限り、これは「Dynamic Access Control」の一部であり、「Central Access Policy」を前提とするようだ。そのため、動作確認はできなかった。

　グループポリシーの構成画面（図5）を見ると、ファイルにアクセスできない場合と、ファイルが存在しない場合の両方でエラーメッセージをカスタマイズできることがわかる。

図5　アクセス拒否ポリシー。左がファイルアクセスが拒否された場合、右がファイルが存在していない場合だ

　●

　ファイル共有という、古くからある基本的なサービスだが、最近はWebインターフェイスに押され気味のようで、人気が下がっているらしい。しかし、Windows Serverのファイル共有プロトコルSMBは、Windows Server 2008 R2/Windows 7で大きく進化し、効率もよくなった。これを機会にぜひ見直してほしいものである。