【IAM】 DAC その 2 ～ なぜ企業のアクセス管理に DAC が必要なのか

  • Article

前回の投稿は以下の通りです。

【IAM】 DAC その１ ～ グループベース RBAC の破たん?
https://blogs.technet.com/b/junichia/archive/2013/03/29/3561744.aspx

この投稿では、前回の投稿をふまえ、「なぜ企業のアクセス管理にDACが必要なのか」という点について書きたいと思います。

DAC が「Expression（式）ベースのルールによるアクセス管理」であることは前回の投稿で書いた通りです。

ここで疑問を持つ方がいらっしゃると思います。

「アクセスルールを管理するのは誰なのよ？」

当然の疑問です。

IDの属性を管理するのは「ID管理者」。リソースの属性を管理するのは「リソース管理者」です。両者を結び付ける「アクセスルール」を誰が管理するのか?

image

従来の ACL ベースのアクセス管理では、ルールを管理していたのは「リソース管理者（またはリソースのオーナー）」です。それが最も合理的であると考えられてきました。しかし、「社内統制」という観点では、しばしば不合理な問題が発生しうるのもこの方式です。

各所に IT が浸透し多く部門間でデータを共有するようになると、その取扱いが極めて煩雑になります。リソースの提供者の多くは「アクセス権の管理手法」を正確に理解していませんから、しばしば設定ミスや怠慢等によってセキュリティ上重大なリスクが発生してしまうことがあります。

こうした問題を軽減するために「企業レベルのアクセスルール管理」へのニーズが高まっています。企業内の専門部隊が、社内リソースのアクセスルールを集中的に管理するという考え方です。

もちろん、すべてのリソースがその対象となるわけではないでしょう。しかし、確実に社内統制が必要なリソースは存在します。そうしたリソースに対しては、統制されたアクセスルールを適用することで、これまでよりも安全にリソースを管理できるようになります。

ということで、冒頭の疑問への回答は以下の通りです。

「アクセスルールを管理するのは、社内のセキュリティチームである」

セキュリティチームがリソースのアクセス権に関して行う作業は以下の通りです。

1. 重要な社内リソースへのアクセス権に関してセキュリティポリシーを策定する

  • 対象リソース：どのサーバーの、どういう属性を持ったリソースを対象にするのか
  • 対象ユーザー：どういう属性を持ったユーザーを対象にするのか
  • アクセスルール：対象リソースに対して対象ユーザーがどのようなアクセス権を持つの

ここで注意していただきたいのは、対象リソースを明に（C:\Data とか）指定するわけではないということです。あくまでも対象となるリソースの「条件」を定義するのだという点に注意してください。

条件には、所属以外にも、担当プロジェクトや役職などが考えられますし、単純なところではデータの重要性（外部公開、社外秘、社員のみ など）を定義する必要もあるでしょう。また、より厳密に管理するのであれば「データがどういったコンプライアンスフレームワークに属するか」といった定義も必要になるでしょう。例えば以下のようなフレームワークが考えられます（日本にとっては重要でないものもあったりなかったりですが。。。）。

2. 策定したセキュリティポリシーをリソース管理者に通達する

リソースにどのような属性が用意され、それがどのように設定されていると、どのような属性を持ったユーザーに、どのようなアクセス権が与えられるのかという内容を通達します。通達されたポリシーをどのリソースに適用するかはリソース管理者の裁量となりますが、少なくともリソース管理者は公開するデータがどのような種類のデータであるかを把握しておく必要があります。社外秘なのか部門限定情報なのかなどです。逆に、それが判断できない人はリソース管理者であってはなりません。。。。つまりリソース管理者にもそれなりのリテラシーが要求されるわけです。

。。。と書くとかなり敷居が高いように思えますが、リソース管理者自身が「社外秘情報の判別と、そのアクセス権まで管理していた」ACLベースのアクセス管理手法と比較すれば、はるかに容易ですし、安全性は高まります。

3. 策定したセキュリティポリシーを ID 管理者に通達する

アクセスルールはユーザーの属性をベースに判定されるので、ID 管理者には常に最新の ID 情報を保持してもらう必要があります。重要なデータであればあるほど迅速性が求められるため、それなりの ID管理基盤（ユーザープロビジョニングシステム等）が必要となる場合もあるでしょう。もしかするとアクセスポリシーを適用するために最適な属性が存在せず、Active Directory のスキーマに手を入れざるをえない可能性もあります。

ただし、あまりに複雑なルールは運用に破たんを招きますので、極力既存のID管理手法を維持しつつ、アクセスルール側で複雑な設定は吸収したほうがよいでしょう。

各種法令は無駄に複雑なプロセスを求めるものではありません。

基本は、中央のセキュリティポリシーがリソースに対して強制力もち、参照や編集できる権限を持った人が限定的でありかつ明確であること。そしてそれがトラッキング（監査）できることです。権限を持たない人間が絶対にアクセスできないようになっていることが重要です。

4. セキュリティポリシーをシステムに反映する

システムに反映するには DAC のお作法にのっとって作業する必要があります。これについては次回詳しく解説しますが、「セキュリティポリシーの集中管理」と聞けば何を使うかはだいたいわかりますよね？そう、グループポリシーです。作成したアクセスルールをグループポリシーにのせて、社内のリソースに配信するわけです。

このように、DAC は ACL ベースのアクセス管理では行えなかった「ID 管理」「リソース管理」「全社アクセスルールの管理」の 3 者を分離し、それぞれの専門部隊の相互連携によって最大限の効果を発揮できるようにするための仕組みです。

DAC にはアクセス権を管理する以外にも、監査ルールを集中管理したり、FCI（File Classification Infrastructure）との連携による自動分類が可能です。FCI と連携することで、社外秘データを暗号化したり、法廷保存期間に沿って特定フォルダに保管したりといった作業を自動化することもできます。これらについて詳しくは別投稿で。

image

 

＜その１     その３＞