Azure ADのセキュリティのベストプラクティス:アクセス、制御、ロール

Figure 3: Trustee scoping in Azure AD

図3:Azure ADにおける保管者絞り込み

Randy:オブジェクトのスコープ割り当てについてお話ししましょう。これは、あなたが権限を持っているオブジェクトです。あとで実際にお見せしたいのは、我々が米国管轄内のすべての従業員のユーザアカウントに対するパスワードリセットの権限を、米国のヘルプデスクにどう与えるかということです。この場合、保管者をヘルプデスクで働くBarryとしましょう。そして、Tom、Dick、Harryは米国管轄内を拠点とする単なるエンドユーザで、Barryは彼らに対してパスワードリセットの権限を持っています。でも、保管者スコープ割り当てとオブジェクトスコープ割り当てによって、これを管理可能な方法で行なうことができるのです。これをご覧ください。次はロールについてお話ししましょう。

Figure 4: Object scoping in Azure AD

図4:Azure ADにおけるオブジェクト絞り込み

保管者絞り込みは主に、グループとActive Directoryで完了します。もしBarryがヘルプデスクにいれば、Tom、Dick、Harryに対するパスワードリセットの権限を彼に持たせるのです。これは、オンプレミスのADであれ、それ以前に使っていたものであれ、今までに皆さんが学んできた他のことと同じです。個人ユーザにパーミッションやエンタイトルメントを与えず、グループを介して行うのです。理由はさまざまですが、ここでは詳しく述べません。私の話で皆さんの考えが変わってくれていればいいのですが。これがいわゆる保管者絞り込みです。主にグループとAzure Active Directoryで完了します。ユーザをグループに入れた後、Azure、Exchange、Teamsなどでの権限を、または管理者であればAzure Active Directory内の他のユーザやグループに対する権限を、そのグループに付与するのです。

Tim:Randy、今おっしゃったのはクラウド特有の言葉ですよね。常々疑問に思っていたのですが、「パーミッション(許可)」と「エンタイトルメント(権限付与)」の違いは何でしょう? 理論的には同じだと考えられますが、エンタイトルメントは、それぞれの作業でできることをごく小さくするクラウド方式です。だから、エンタイトルメントという言葉を、パーミッションと言い換えてもいいですか?

Randy:はい、いいと思います。つまり、言葉の問題ですよね。「エンタイトルメント」と言えば、「エンタイトルメント管理」も思い浮かびます。オンプレミス環境であっても、誰かのエンタイトルメントを観察しています。私は、技術寄りの言葉というよりも、ビジネス上の言葉だと思っています。グループのメンバーシップによるものであれ、ADでのパーミッションによるものであれ、ロールの割り当てにはさまざまな基本的な実践方法があります。いずれにしろ、それをここでエンタイトルメントと言っているのです。しかし最終的には、パーミッションという言葉がおそらく最も明確で直接的な言い換えかもしれませんね。

では先に進めましょう。他に、このようなアプリケーションで、ユーザや保管者を絞り込む方法があるでしょうか? たとえば、MicrosoftのDynamics 365やCRMなどですね。 それがロールと呼ばれているのかグループなのか思い出せませんが、ユーザをそこに入れることができます。それにSharePointという良い例があります。SharePointにはSharePointグループがあり、そこに直接ユーザを入れることもできるし、まずAzure ADグループに入れてから、このAzure ADグループをSharePointグループに入れることもできます。

このように、他のアプリケーションで保管者絞り込みを一体化したり追加したりする方法はいくつかあります。でも敢えて言いますが、こうしたすべてをAzure ADにまとめたほうがいいと思うのには、もっともな理由がたくさんあるのです。私にとっては、Windowsのローカルグループに非常に近く思えるのです。オンプレミスではWindows とActive Directoryのドメインしかありません。私たちにはWindows Serverも、おそらくSharePointやSQL Serverもあります。だからWindows Serverレベルのローカルグループができるのです。このグループに当たるものをSQL Serverでも作り、SharePointの中にグループを作ることもできます。いつも言っていることですが、こうしたグループを全部Active Directoryにまとめたほうが、効率がいいと思いませんか?

Tim:そうですね。

Randy:そうすれば、ユーザに対して、そのユーザが持っているものをすべて見せるように言えるし、Active Directoryを離れる必要がありません。

Tim:はい、そのほうが効率がいいですね。SharePointグループやSQLグループを使わなければならない場面があるのもわかりますが、セキュリティをシンプルにするには、グループにして、オンプレミスのパーミッション管理をグループで行ない、グループとアプリケーションに対してのみパーミッションを行なって、個々の人はそのグループに出入りさせるという方法が現実的です。シンプルだし、簡単に監視できますから。私たちがやっているのはそれです。クラウドでもそれに近いことが行なわれつつあります。

Randy:そして、私の基本的な信条であり、あなたも経験則や直感でおわかりだと思いますが、これをAzure ADのグループで行なうのです。でもまたここで、Exchangeの管理者ユーザが「自分はAzure ADでの権限を持っていない」「Azure ADの管理者ユーザではない」というかもしれませんが、解決法はオンプレミスのADの時代と変わりません。組織単位(OU, Organizational Unit)を作り、その単位の中でグループを作って管理する権限を委譲して、そのアプリケーションを使えるようにするのです。 Azure ADでも同じことができます。単に言葉が違うだけです。

Tim:わかりました。

Randy:言葉と言えば、私は今「組織単位」と言いましたね。まず、主な使い方として……組織単位はオンプレミスのADでは多目的に使えるのですよ。ですが、オンプレミスADでの主な使い方の1つは、多くのユーザをひとつにまとめ、このユーザに対する権限をサブの管理者ユーザに委譲することです。Azure ADにあるのは組織単位ではなく、管理単位です。Azureにあるのはこのどちらでもなく、リソースグループです。

では、このような言葉【単位またはグループという言葉?】に的を絞って見てみましょう。ユーザのリストではないので、そのように使われていないことを望みます。リソースグループというのはフォルダのようなものです。ファイルサーバを考えてみてください。ファイルを異なるフォルダに振り分け、フォルダレベルでパーミッションを割り当てます。Azureでは、仮想マシンとストレージアカウントを取得し、こうした他のリソースは……ええと、フォルダではなくリソースグループにまとめます。基本的には非常に高度なレベルで、Active Directoryの組織単位(OU)は、Azure Active Directoryの管理単位(AU)やAzureのリソースグループと非常に似通ったものです。

Tim:そのファイルの用語はいいですね。これから使うことにします。

Randy:ええ。それにリストに加えるだけでいいのです。ファイルサーバ上のフォルダと同じ目的ですよ。

そして、このフォルダすべてに名前がついているとします。Microsoft Cloudでは、これが1つのフォルダまたは管理単位といったものになります。ところで、ここで1つ興味深いことがあります。管理単位の利用はAzure AD の他のものにまで拡張されているのです。たとえばExchange Onlineでは、Exchange、特にメールボックスや、あなたが受信者であるという事実などに対して、権限を委譲するためのサポートが管理単位に追加されました。 だから、管理単位は……個別にAzure ADの外で開始されます。Teams、Power BIまたはMicrosoftのその他の製品でも同様のことがなされているかどうかはわかりません。Exchangeでは、ADのユーザアカウントに多くの内容が保管されているという単なる事実に過ぎません。

Tim:はい。それにADとユーザアカウントを見れば、Exchangeの属性があるのがわかります。それに、あなたはこう思うかもしれません。「私はExchange Onlineを持っている。これを全部クラウドにアップすべきだ」と。

Randy:そうです。それが管理単位とリソースグループです。こうしてオブジェクト絞り込みを行なうのです。それから、いわゆるロールがあります。これはAzure ADなのでAzure ADロールです。当然、AzureならAzureロールになります。言葉について説明すると、Azure ADロールは、Azureロールとは違う別物です。Exchangeには監督者ロールがあり、これをさらに細分化して管理者ロール、ユーザロールなどとすることができるでしょう。
他のMicrosoft Cloud製品では、ロールの種類も異なります。

Tim:Randy、そのあたりはちょっとみんなが混乱するかもしれません。なぜなら、当然Azure ADの管理グループと、それに関連づけられたパーミッションがあります。その後でOffice 365に行くと、そこにもあるレベルの管理者がいます。 Microsoft 365 Teamsのあるコンポーネントに行けば、そこにも管理者グループがあって、管理者権限を考慮しなければなりません。こうしたことが幾重にも重なって、あっという間に鳥の巣のように複雑になります。

Randy:まったくその通りです。いくつか改善もされました。ありがたいことに、別の機会に、かつて管理者モデルと呼ばれていたテーマについてお話ししたときのロールは、削除することができました。でもそのままにしておけば、Azure ADでもAzureにも、Exchangeにも、あるいは他にCRMのようなものにもロールがついてきます。ただ、コンセプト全体には共通の属性が少なからずあります。ただ、ロールというのは限定されて……ロールという言葉を使うときは、そのロールが与えてくれる一連のパーミッションという意味になることが多いのです。たとえばユーザ管理というロールがあります。それによって、Azure ADのすべてに対して全部の管理者権限が与えられるわけではありませんが、特定のユーザに対しては完全な制御を行うことができます。また別のロールであるパスワードリセッター。これは一目瞭然ですよね。そのオブジェクトタイプのユーザに適用されるのはたった1つのパーミッションで、そのパーミッションはパスワードのリセットです。

このように、あるロールについて語るときは、単にロールだけのことが多いのです。ではパーミッションは? ロールは必ずしも、パーミッションを与えようとしているというセキュリティの原則や、そのパーミッションを与える範囲を指定しません。それはロールの割り当て以上のもの、Timが言ったようにエンタイトルメントというものです。エンタイトルメントとは、一連のパーミッションであることもあれば、そのパーミッションを持つ人、そのパーミッションが適用されるオブジェクトの範囲を示すこともあります。

いくつか例を挙げましょう。Barryは米国側のヘルプデスクにいます。この場合、一連のパーミッションは非常にシンプルで、パスワードのリセットのみです。だからロール名もそれに応じて、「パスワードリセッター」となります。これをロールの割り当てまたはエンタイトルメントに置き換えると、今度はBarryは保管者、すなわちセキュリティ主導者となるのです。そしてその範囲を米国内のユーザのみに限定したければ、そのユーザを入れた管理ユニットを作る必要があります。ただし、ディレクトリレベルでロールを割り当てることもできるし、Azureでのロールもあるのでグローバルと呼ぶことにしますが、その場合はサブスクリプションレベルで割り当てることもできます。Azure ADでは、グローバルレベルはディレクトリレベルとなるでしょう。Exchangeなら組織レベルです。他に何かありますか?

参考 BeyondTrustとソリューションの紹介

シェアする

  • このエントリーをはてなブックマークに追加

フォローする