1. ダイナミックアクセス制御とは
Dynamic Access Control（DAC）
2013年03月29日
Version 2.0

2. “データガバナンス” へのニーズ
正しいコンプライアンスが必要
自分のデータが適切に保護されて CIO
いるかどうやって監査すればよい
のだろう？
コンテンツオーナー インフラサポート
コンプライアンスに違反しているかどう どのデータに責任があって、どう
か心配せずに必要なデータを使用したい やって制御すればよいかわからない
Information Worker

3. そうは言っても、複雑な ”データガバナンス”
• ファイル単位のアクセス権 • グループメンバーシップの管理
• 増え続けるファイル アクセス ID管理 • 増え続けるグループとメンバー
• 管理の分散（コンプライア 増減への対応
ンス測定不能）
ポリシー • 複雑なメンバーシップルール
• 暗号化すべきデータの識別
• 監査対象データの識別
• 膨大なデータ 暗号化 監査

4. User and Device Claims
Pre-2012: Security Principals Only
• Restricted to making policy decisions based on the user’s group memberships
• Shadow groups are often created to reflect existing attributes as groups
• Groups have rules around who can be members of which types of groups
• No way to transform groups across AD trust boundaries
• No way to control access based on characteristics of user’s device
Windows Server 2012: Security Principals, User Claims, Device Claims
• Selected AD user/computer attributes are included in the security token
• Claims can be used directly in file server permissions
• Claims are consistently issued to all users in a forest
• Claims can be transformed across trust boundaries
• Enables newer types of policies that weren’t possible before:
• Example: Allow Write if User.MemberOf(Finance) and User.EmployeeType=FullTime and
Device.Managed=True

5. Expression-Based ACEs
Pre-2012: ’OR’ of groups only
• Led to group bloat
• Consider 500 projects, 100 countries, 10 divisions
• 500,000 total groups to represent every combination:
• ProjectZ UK Engineering Users
• ProjectZ Canada Engineering Users [etc…]
Windows Server 2012: ‘AND’ in expressions
• ACE conditions allow multiple groups with Boolean logic
• Example: Allow modify IF MemberOf(ProjectZ) AND MemberOf(UK) AND MemberOf(Engineering)
• 610 groups instead of 500,000
Windows Server 2012: with Central Access Policies & Classification
• 3 User Claims & Resource Properties

6. アクセスコントロール
• アクセスコントロール（アクセス制御）とは...
... ユーザーがアクセスしてもよいかどうかを評価するためのプロセス
• Windows の場合以下の 2 種類
• ACL ベースのアクセスコントロール
• Expression ベースのアクセスコントロール
ID
アクセス権 アクセス 情報

7. ACL（Access Control List）ベースのアクセスコントロール
• リソースにアクセスコントロールエントリ（ACE）を静的に割り当てる
• 各 ACE は「OR」で接続される
ユーザー
ACL ACE
ACE
Read/Write
ACE
Resource
グループ
ACE ACE
ACE A
Read Only

8. AGDLP
A :Account
G : Global Group
DL : Domain Local Group ユーザー
P : Permission
組織や役割ごと
ACL のグループ
グローバル
ACE
グループ
“アクセス権”に
ACE 合わせて作成さ
Resource れたグループ
ACE ドメイン ローカル グローバル
グループ
グループ
ACE
Read Only

9. 静的なACLを動的に管理するための Id プロビジョニングシステム
• 「静的」な ACE を「動的」に割り当てる仕組みも存在する
• Forefront Identity Manager のダイナミックグループ機能
グループ
メタデータ
グループ
A
workflow

10. Expression-Based グループ
通常のグループ Expression-Based グループ

11. RBAC（Role-Based Access Control）
ユーザーやグループ単位ではなく”役割”単位でアクセス制御すること
....とはいえ、Windows の場合「役割」を「グループ」として表現するしかない....
役割（Role：ロール） グループ 権限
公共事業部 マーケティング部所属 PubSec-Marketing 読み取り
公共事業部 営業部 所属 PubSec-Sales 読み取り
公共事業部 課長 PubSec-Managers 読み取り
公共事業部 部長 PubSec-SrManagers 読み取り
・・・・・

12. グループベース RBAC の限界
• リソースの増加とグループの増加
• 複雑なメンバーシップ管理（1グループ1人 !?）
• イレギュラーでダイナミックな組織構造
• リソース管理者 ≠ ID 管理者
アクセス管理
連携が必要 ID 管理（ID 管理者）
（リソース管理者）
ACL
A A
Resource ACE
ACE
A A A
ACL A
Resource ACE A A
ACE
A
A A
A

13. Expression-Based Access Control
• ユーザー側の属性とリソース側で定義した属性の条件によってアクセスを制御
条件が合致すればアクセス可能
アクセスルール
ユーザーCountry = リソース Country
ユーザー Department = リソース Department
デバイス Owner = “Microsoft”
ユーザー属性 リソース属性
デバイス属性

14. Dynamic Access Control
• Expression-Based Access Control...
...利用者のキャラクター（属性）によって動的にアクセスを制御する
• リソース管理者（リソースオーナー）は条件（Condition）を管理するだけ
• ID 管理者は ID のプロビジョニングに対して責任を持つ
アクセス管理 互いに素 ID 管理（ID 管理者）
（リソース管理者）
condition
営業部 IT部 A 人事部 A
Read
condition
IT部 経理部 A
Resource
Backup
condition
営業部 A 企画部 A
経理部
R/W

15. Windows Server 2012 ダイナミックアクセス制御（DAC）
DAC によってそれぞれのテクノロジーを結びつける
アクセス
• アクセスポリシーの ID管理
ポリシー • クレームベースのアクセス制御
集中管理
• 自動識別と自動暗号化 • 監査ポリシーの集中管理
暗号化 監査

16. DAC の想定シナリオ
リソースごとに行っていたアクセス制御をエンタープライズレベルで統制
• アクセスポリシー（Central Access Policy）の集中管理
 全社コンプライアンスポリシー
 組織の認可ポリシー
• ファイルアクセス監査ポリシー（Central Audit Policy）の集中管理
• File Classification Infrastructure（FCI）と連携したファイルの自動分類
 データの自動分類
 社外秘データの自動暗号化
 法廷保存期間に沿ったファイルサーバー上のデータの保管

17. 「クレームベースのアクセス制御」とは
• 「クレーム」とは「要求」のこと
• 「要求」を出すのは「リソース（例：ファイルサーバー）側」
• ユーザーはリソース側のクレームに合致した属性情報を「トークン」として提示
• リソースは受け取ったトークンを解析してアクセス認可を判断
トークンを解析して
アクセス認可を判断
Name = Junichi Anno
ユーザー Company = MSKK リソース
Department = Evangelism
Title = Evangelist

18. DAC でのアクセス制御プロセス
DAC においては
• クレーム = 「分類属性」として定義
• トークン = Kerberos チケットとして AD DS から発行される
Windows Server 2012 必須
※Kerberosに属性を含める機構が必要
AD DS
ファイルサーバー
ログオン
属性情報を含んだ Windows
Kerberos チケット Server 2012 必須
※属性を受信して解
析する機能が必要
ユーザー Name = Junichi Anno チケットとクレームを
on Windows 8 Company = MSKK
照合

19. （参考）クライアントが Pre-Windows 8 の場合
Windows 7 以前のクライアントの場合、属性が格納されたKerberosチケットを要求することが
できないため、ファイルサーバーがAD DSから属性情報を受け取る
Windows Server 2003 以上のドメインレベル
※Service-for-User-to-Self（S4U2Self）機構が必要
AD DS
ファイルサーバー
ログオン 属性情報を含んだ
Kerberos チケット
Windows
従来の Kerberos
Server 2012 必須
チケット
※属性を受信して解
析する機能が必要
ユーザー 属性は含まれない チケットとクレームを
on Pre-Windows 8 照合

20. 分類属性（Classification Attributes）
• ファイルシステムが持つ標準的な属性情報を拡張するための「属性リスト」
• 属性を編集するにはファイル サーバー リソース マネージャーのインストールが必須
• AD DS 側で属性リストを集中管理し、グループポリシーとして配布可能
AD DS
ファイルサーバー
＋ ファイルサーバーリソースマネージャー

21. DAC に必要なすべての情報が DC で集中管理される
DAC に必要な情報は3つ
• ユーザーの属性情報
• リソースの属性情報（分類属性）
• アクセスルール
Active Directory
Domain Service
アクセスルール
ユーザー Country = フォルダ R_Country
ユーザー Department = フォルダ R_Department
条件が合致すればアクセス可能

22. DAC によるアクセスポリシー管理の全体像
「Active Directory 管理センター」で作成した「集約型アクセスポリシー」をグループポリ
シーオブジェクト（GPO）に結合することでファイルサーバーに適用する
リソース
集約型アクセスポリシー
集約型アクセス規則
アクセス元の条件と条件を満
たした時のアクセス権 ターゲットとなるリソースの条件
クレームタイプ グローバル
（要求の種類） リソース プロパティ リスト 分類属性とリソー
スの条件が合致す
Country リソース プロパティ ればアクセス権が
結合 与えられる
R_Country
Department
ソース
（ユーザー） R_Department
GPO
適用
Active Directory

23. アクセス権適用の優先順位
集約型アクセスポリシーが最優先される
共有のアクセス権 Access
NTFS アクセス権 Control
集約型アクセスポリシー Decision

24. アクセス拒否発生時の速やかな対応
ユーザーがファイル共有にアクセスして”アクセス拒否”が発生した際に、
速やかな問題解決を図るために以下の対応が可能。
• メッセージの送信
 to システム管理者
 to 共有フォルダーの所有者
• アクセス権取得の要求
グループポリシーおよびファイルサー
バーリソースマネジャーで設定

25. DAC に求められる条件
管理者の管理範囲は狭くなるが、管理の精密性が求められる
リソース管理者の責任
• コンプライアンスに沿った条件設定
• 状況に応じたダイナミックな設定変更
IT（ID）管理者の責任
• ID 情報の精密性
• 迅速な ID 情報の反映