DAC と書くと「 discretionary access control(随意アクセス制御)」を思い浮かべてしまう方も多いと思いますが、ここでは「Dynamic Access Control(ダイナミックアクセス制御)」を指しています。

※ちなみに RBAC とは Role-Based Access Control の略ですが、詳しくは本文中で。

Windows Server 2012 から実装された新しい機能「ダイナミックアクセス制御」。みなさんご利用でしょうか?以前以下の投稿をしましたが、あまり見られていないですね(笑)。なんか、あのころの AD FS を見るようだなぁと。。。

【IAM】ダイナミックアクセス制御(DAC)を理解するための解説&演習手順書
http://blogs.technet.com/b/junichia/archive/2012/12/17/3541225.aspx

そこで、なぜ DAC なるものが必要なのか?という点についてまとめておきたいと思います。

ACL ベースのアクセス制御

「アクセス制御」という言葉があります。アクセス制御については説明するまでもありませんが、「ユーザーがアクセスしてもよいかどうかを評価するプロセス」のことです。

image

ご存知の通り、従来マイクロソフトが採用しているアクセス制御方式は、「ACL 方式」です。

image

ACL とは Access Control List の略で、中には 「ACE(Access Control Entory)」と呼ばれるエントリーが格納されています。ACE にはユーザーやグループを識別するための SID(Security ID)とアクセス権が格納されており、これによってユーザーのアクセス権が識別されます。ACL に複数のACEが格納されている場合、これらは基本的に「OR」で評価されます(ただし、同じSIDが複数のACEに格納されている場合には、その中の一番厳しいアクセス権が採用されるという大原則があります)。

ACL は「静的」です。つまり、誰かが手で設定しなければ変わることはありません。つまり一度アクセス権が与えられたら、ACL から ACE を削除するか、ACE を変更するまで永遠に現在のアクセス権が与えられ続けます。そこで、組織間で人材が移動してもリソース側に直接手を入れる必要が無いようにするため、マイクロソフトでは「グループにアクセス権を与える」方法を推奨しています。グループにアクセス権を与えることで、アクセス権の制御を「グループのメンバーシップの変更」で置き換えようという考え方です。こうすれば、リソース側のアクセス権を直接操作する必要はなくなります。こうしたアクセス権管理の方式を AGDLP と呼んでいます。

  • A :Account
  • G : Global Group
  • DL : Domain Local Group
  • P : Permission

image

ただ、これで何も問題がないわけではなく別の問題が浮上することになります。「グループ管理の煩雑さ」です。

組織が「静的」であれば問題はありませんが、そんなはずはありません。人材の流動化が進むにつれ組織は日々変化します。つまり、組織は「動的」なのです。それでも、年に1回であれば担当者ががんばってバッチ処理を回せばなんとかなるかもしれません。しかし人の出入りが短いスパンで発生するマイクロソフトのような企業では、バッチ処理では「迅速で正確な」対応が難しくなります。これは安全性を維持するための「アクセス制御」にとって致命的です。

ユーザー プロビジョニング システムによる管理

そこで、これを解決するために採用されているのが「メタデータをベースにしたユーザープロビジョニング」システムです。論理的に中央に置かれたメタデータベースにはすべてのユーザーや組織情報が集中管理されています。マイクロソフトでいえば、Forefront Identity Manager(FIM)が該当します。

こうしたシステムを使用すると、静的な ACL を「動的」に管理することができるようになります。たとえば、ユーザーの属性が「営業部」から「マーケティング部」に変更されたとします。これにともない、内部のワークフローエンジンは、「営業部グループ」に所属していた当該ユーザーを「マーケティンググループ」に自動的に移動します。

image

ここで使用されるのが「Expression-Based グループ」と呼ばれるものです。Expression とは「式」のことで、グループのメンバーであるための条件を「式」で表現しておくことができるのです。たとえば「所属が営業部」かつ「役職がManager」と設定しておけば、所属と役職が合致したユーザーが、自動的にメンバーとして追加されます。

image

こうした仕組みによって、アクセス権の管理をある程度自動化できます。

グループを使用した RBAC の破たん ?

役割によってアクセス権を管理することを一般的に RBAC(Role-Based Access Control)と呼びます。

企業内でアクセス権を管理する場合、グループには「役割」という意味付けがなされます。つまり、適切な役割を持ったユーザーに対してリソースへのアクセス権を与えるという考え方です。それを既存のシステムに反映しようとすれば、必然的に「役割=グループ」となります。

roles

RBAC 自体合理的な考え方ではありますが、この「役割」というのが案外曲者です。部署ごとや役職ごとにグループを作成している分にはさほど面倒ではありません。しかし、グループの設計につきものなのが「グループ数の膨張」です。

リソースの管理者からすれば、「厳密にアクセス権を管理したい」と考えるのは当然ですが、残念ながらグループには汎用性がありません。メンバーが一人でも異なれば(つまり役割が異なれば)別のグループ(役割)を作成する必要があります。中にはメンバーが一人しかいないグループが多数存在することにもなります。

そうなると ID 管理側は超大変です。リソースの管理者がグループを作成する権限を持っていない場合、要求に応じて次々とグループを作成しなければなりません。それでも作成までは何とかなるかもしれませんが、「棚卸」となるともうお手上げです。どのグループが使われていて、どのグループを削除してもよいのか、設計したリソース管理者でさえもわけがわからなくなっているはずです。これでは、合理的にセキュリティを維持するはずの RBAC の思想が完全に破たんします。不必要なグループを(念のため~とか言いながら)残しておくほど安全性を脅かすものはありません。

image

Expression-Based アクセス制御

そうした問題を軽減するため、マイクロソフトは Windows Server 2012 に「ダイナミックアクセス制御」と呼ばれる機能を実装しました。このベースとなっているのが、Expression-Based Access Control です。

Expression-Based については先に書いた通り「式」によって表現する方式ですが、ダイナミックアクセス制御の場合には「式」によってアクセスルールを定義します。

例えば、ユーザーが Country 属性とDepartment 属性を持っているとします。そして、リソース側にも同じ属性が用意されているとします。アクセスルールとして「(user:country = resource:country) and (user: department = resource: department)」と定義しておけば、ユーザーは自分と同じ属性の値を持ったリソースに対してアクセス権を持つことができます。

image

もちろんこれは単純な例ですが、もっと複雑に記述することも可能です。

ACL ベースでは「OR」評価のみでしたが、DAC の場合には「OR」も「AND」も思いのままです。もちろん、MemberOf を使用して「グループのメンバーだったら」といった表現も可能なので、ACLベースのアクセス制御で蓄積してきたグループを引き継ぐこともできます。

さらに言えば、アクセス制御にはデバイスを含めることもできます。

image

この方式の利点は柔軟性だけではありません。ID管理側とリソース管理側で分業が行えます。リソース側は「使わせたい人やデバイスの条件(要求)」をリソースのプロパティとして定義しておけばよく、ID管理側はユーザーやデバイスの属性を正確に管理しておけばよいのです。もちろん、こうなると両者にスピードと品質が求められることは言うまでもありません。

。。。。ここで AD FS を使用したクレームベースのアクセス制御を思い浮かべた人は「非常に正しい」です。実は、DAC で使用しているテクノロジーというのは、AD FS 2.1 で新たに実装されたテクノロジーと密接に関係しているのです。

【IDM】Active Directory Federation Service 2.1 の新機能
http://blogs.technet.com/b/junichia/archive/2012/12/10/3539674.aspx

以上のように、非常に柔軟な「ダイナミックアクセス制御」なのですが、いかんせん実装にたどり着くまでの「理解」が難しい!!!!AD FSと初めて対峙したときのような難解さです。

次回の投稿では、DAC がなぜ企業のアクセスコントロールにおいて重要であるのか。。について解説します。

その2 へ