【IAM】DAC その3～Dynamic Access Control のアーキテクチャ(1)
以前の投稿につづき、今回は Windows Servevr 2012 が提供する DAC のアーキテクチャについて解説します。この辺をご理解いただくと、多くのエンジニアの方に「おぉ、やってみたい」と思っていただけるかと。
- 【IAM】ダイナミックアクセス制御（DAC）を理解するための解説&演習手順書
https://blogs.technet.com/b/junichia/archive/2012/12/17/3541225.aspx
- 【IAM】 DAC その１ ～ グループベース RBAC の破たん?
https://blogs.technet.com/b/junichia/archive/2013/03/29/3561744.aspx - 【IAM】 DAC その 2 ～ なぜ企業のアクセス管理に DAC が必要なのか
https://blogs.technet.com/b/junichia/archive/2013/04/01/3562095.aspx
まずは以前の投稿でも使用した以下の図をご覧ください。DAC では「リソース側の属性」と「ID 側の属性」のマッチングを行い、条件が合致したときにアクセス権が適用されます。
ちょっと運用イメージが想像しずらいでしょうか？
現実の世界にもこのような仕組みは存在しています。例えば"ある種の結婚相談所"を思い浮かべてみてください。
あくまでも私の想像ですが、結婚相談所の場合、女性は出会いたい男性の属性を事前に定義しておく必要があるのでしょう（たぶん）。結構相談所側は、女性の要求と、条件に合致した男性から女性へのコンタクト権限（アクセスルール）を定義しておきます。もちろん、このときアクセスルールにはある程度女性側のニーズを反映させる必要があるので、複数のルールを作成しておく必要があるかもしれません。男性はどういった女性が登録されているかは把握可能ではあるものの、アクセスルールに合致しなければインスタントメッセージさえも送ることは不可能です。
このモデルでは、結婚相談所が両者のニーズの中間地点でアクセス管理を行っています。もし結婚相談所によるアクセス管理が無かったとしたら、一切のアクセス制御は女性自身が行う必要があります。これはとても面倒です。
えっと何の話でしたっけ？あ、DACですね。DAC に話を戻しましょう。
DAC によるアクセス管理の全体像をざくっと図にすると以下の通りです。
ここで3人の主要な登場人物について理解しておきましょう。
- ソース
- アクセスポリシー
- リソース
ソースとは、リソースにアクセスする主体を指します。つまり、ユーザーやデバイスのことです。ソースは Active Directory ドメインに定義されたオブジェクトであり、ldap 属性を持っています。
リソースとはファイルサーバー上の”フォルダ”や”ファイル”のことです。リソースには「分類属性」と呼ばれる特別な属性を定義することができ、これを使用してアクセス可能なソースを制限することができます。
アクセスポリシーとは、その名の通りアクセスを制御するためのポリシーです。正式日本語名称「集約型アクセスポリシー（Central Access Policy）」と呼ばれ、その名称から”集中管理された”アクセスポリシーであることがわかります。「集中管理」が何を意味するかといえば、もちろん「Active Directory ドメイン による集中管理」のことです。
上の図を、さらに詳しく書いたのが以下の図です。
アクセスポリシーにはアクセスルール（正式日本語名称：集約型アクセス規則）が格納されています。アクセスルールによって「ソース側の属性」とリソース側の「分類属性」が比較されるとともに、条件が合致した場合のアクセス権限（ReadとかWriteとか）が与えられます。
ちょっと面倒な話なのですが、ソース側の属性は、アクセスルール内では「クレームタイプ（要求の種類）」と呼ばれます。AD FS（Active Directory Federation Service）に慣れた方であれば違和感がないかと思います。アクセスポリシーを策定する管理者は、ソースが持つldap属性の中からアクセス制御に使用するものを選定し、クレームタイプとして定義します。
さらに、クレームタイプと比較したいリソース側の属性（分類属性）を「リソースプロパティ」として定義します。言い方を変えれば、リソースプロパティがアクセス制御の対象となるリソース側の条件となります。つまり、ここで定義したリソースプロパティを持たないリソースは、このアクセスルールによるアクセス制御の対象とはなりません。
リソースプロパティが1つであるとは限らないので、アクセスルール内では「リソースプロパティ リスト」として定義されることになります。
用語が大量に登場して頭が混乱しますよね。わかります。私も最初は相当混乱しました。今は我慢のときです。あきらめずに読み進めてください。
アクセスポリシーの定義は、Active Directory 管理センターから行います。Active Directory 管理センターの「ダイナミック アクセス制御」を開くと、上で説明した各項目の定義画面が用意されています。それぞれが英語表記になってしまっているのがアレなのですが。。。
この画面で最初に行うのは「Claim Types（クレームタイプ、要求の種類）」の定義です。以下の例では、ldap属性の department をクレームタイプとして定義しています。これにより、アクセス権判定の際には、ユーザーのdepartment 属性が参照されます。
次に、「Resource Properties（リソースプロパティ）」を定義します。以下の例では、クレームタイプ同様、Department というプロパティを定義しています。なお、ここで定義するプロパティは、現時点でファイルサーバー上のリソースに存在している必要はありません。ここで定義したプロパティが、ファイルサーバー上のリソースに追加されます。
作成した Resource Properties は、Resource Propertiy Lists（リソースプロパティ リスト）に追加しておく必要があります。
復習しておきましょう。ここまでの作業で、以下が作成されました。
- クレームタイプ
- リソースプロパティ
- リソースプロパティ リスト（リソースプロパティが含まれる）
今度は、クレームタイプとリソースプロパティを関連付けて、アクセス権を定義します。これが「 Central Access Rules（集約型アクセスルール」です。以下の画面ショットを穴が開くほど眺めてください。「ターゲット リソース」については説明するまでもないでしょう。わかりずらいのが「現在のアクセス許可」として定義されている項目です。
「現在のアクセス許可」の設定画面を開いたものが以下です。Domain Users の中で Department 属性が「IT」または「SALES」のユーザーに対して「読み取りと実行」権限を与える。。。という意味になります。
どうでしょう？理解できたでしょうか。
ここで定義したアクセスルールは、Central Access Policy（集約型アクセスポリシー）に格納します。
これで、ひととおりの定義は完了です。
さて、ここで疑問が出てきます。
- アクセスポリシーって、どうやってファイルサーバーに伝達するの？
- もしかして、個々のファイルサーバーに個別に定義するの！？
- やってられーん！
安心してください。上の図に書かれている通り、答えはグループポリシーです（素敵！）。グループポリシーの中には、「集約型アクセスポリシー」と呼ばれる定義が用意されています。ここに、作成したアクセスポリシーを定義します。
なお、このポリシーはコンピューターに対して適用する必要があります。したがって、Default Domain Policy のような汎用ポリシーに定義してしまうよりは、「DAC Policy」などの独立したGPO を作成しましょう。そして、以下のように適用先のフィルタ設定を必ず行ってください。既定では、Authenticated Users に適用されてしまいます。
ポリシーが正しく適用されると、ファイルサーバー上のフォルダやファイルには、以下のように分類属性が追加されます。なお、分類属性タブが表示されない。。。。という方は「ファイルサーバーリソースマネージャー」をファイルサーバーにインストールしてください。「役割と機能の追加」から追加することができます。
いかがでしょう？
なんとなーく、全体の動きが見えたでしょうか？
次回は、分類属性についてもう少し詳しく解説します。