Tim：Randy、ひとつつけ加えると、これは非常に重要なコンセプトです。RBAC、すなわち「ロールベースのアクセス制御」のことを考え、私たちはこれに長年携わってきたと思うでしょう、けれどMicrosoftが created Azure ADとこのロールの構成を作成したとき、制御の定義と、ユーザやデータに対する管理者としての承認には、たいへんな努力が必要でした。形になるまで何度も何度もやり直し、それでもまだ修正が必要です。範囲を変更したり、新しいオブジェクトを追加したり。あなた方が私たちにこれを見せようとしてくれているのはわかります。だからそれを妨げるような真似はしたくありませんが、これだけは言わせてください。 [crosstalk 00:29:06]は、Azure ADでは非常に重要です。
Randy：もちろんそうです。ではそろそろ実際の技術に話を進め、何を話しているのかお見せしましょう。今、私たちはAzure ADを使っていて、そのロールを見ています。これらはすべて、Azureにもともと備わっていた所定のロールです。Microsoftはこれをビルトインと呼んでいます。 独自のロールを作ることも可能で、単純に名前をつけてパーミッションを選べばいいだけの話です。Azure ADだけでどれだけ多くのパーミッションがあるか見てください。私たちがしたことについても。このロールにメンバーを割り当てたのでしょうか? いえ、違います。それに、このロールに範囲を割り当てることもしていません。それは単なる定義であり、つまり、ここにあるのは、名前をつけて再利用できる一連のパーミッションだからです。Tim が先ほど言ったように、重要なポイントですが、これは再利用できるのです。ただ、こうしたロールはそのまま使えます。その1つがパスワードと呼ばれるものです。パスワード管理者です。簡単に言うと……。
図5: Azure ADのロール
Tim：定義を探しているのですね?
Randy：そうです。特定の割り当てを示すだけではなく、つまり、割り当てではないということです。示しているのは……。
Tim：それですか。
Randy：これです。ロールのパーミッションです。
Tim：なるほど。
Randy：読み込まなければならないものがあるので、これを行なうには多くのロールのパーミッションが必要です。ここでも、実際に動作を行なうまでは割り当てはありません。ちょっとお見せしましょう。これがAzure ADの中のロールです。多くの時間は割きませんが、Azureでのロールをほんの少しお見せします。ここに置かれるのが仮想マシンのようなものです。そしてリソースグループへ行って、中から1つ選びます。すると、そのリソースグループでのロールの割り当てが見られます。次に追加する、あるいは見ることができるのは、……。ええと、これがAzureでのすべてのロールです。Azure ADのロールとは関係ありません。ここが肝心なところです。Exchangeでも同じことが言えます。Exchangeでは管理者のロールがあり、今思い出せないものもありますが、受信者、管理ユーザ、それから……
Tim：管理者のリストですね。
Randy：その通りです。
Tim：それで、このパーミッションあるいはエンタイトルメントのリストを辿っていくと、Microsoft Arcなどもありますね。どちらかと言えば新しいサービスです。Microsoftがサービスを追加するたびに、パーミッションがここに表示されます。ややこしいのは、デフォルトで割り当てられることです。だから、懸念を感じ、悩む人が多いのもわかります。特に、たとえばIAM Active Directoryを使っている人で、Azure Active Directoryもわかると思ってしまう人はそうです。Active Directoryがわかっているから、Azure Active Directoryもわかるだろうと思うのです。同じものではないのに。
Randy：そうです。それと関係するのですが、「仮想マシン共同作成者(virtual machine contributor)」というのもあります。「共同作成者」とはおかしな名前ですよね。
Tim：本当ですね。
Randy：それで仮想マシンを管理することはできても、VMやそれがつながっている仮想ネットワークの中にあるものの管理はできないのです。それからもう1つ、これはビルトインロールです。でもこれは、Azure本体の中にあるすべてです。では、スライドに戻りましょう。先ほど、Azure AD内のロールと、Azure内のロールについて少しだけ触れましたね。時間があれば、ExchangeとDynamic CRMについてもお話しできるのですが。そうすれば、そこにも多くのロールがあることがわかるでしょう。でも基本的に、ロールとは一連のパーミッションです。ですから、ロールを割り当てるときは、その資格を誰に、どれだけの範囲で与えるかを選んでいることになります。
では具体的に、Azure ADロールについてお話ししましょう。これは主として、Azure ADの主な対象であるユーザやグループに対してのパーミッションや動作になります。セキュリティの原則も、社内であるか社外であるかを問わず、ロールを直接与えた特定のユーザにすることもできるし、あるいはこちらのほうが望ましいのですが、グループにすることもできます。Azure ADの中でグループを作成し、これに対してセキュリティを有効にすれば、そのグループにロールを割り当てることができます。これがAzure ADの2つの領域で、1つはディレクトリ全体、つまりオンプレミスADならドメイン全体で、もう1つは管理単位（AU）、すなわちADの言葉で言えば組織単位（OU）となります。
Tim：そうすると、選択肢はあまり多くないのですね。つまり、トップレベルか、管理単位を定義するか。
Randy：そうですね。大きな違いは何か? AUとOUの大きな違いの1つは? OUはフォルダのような階層です。OUにはサブOUを作ることができ、下にどんどん付け足すことができますが、管理単位は並列です。入れ子構造にはなっていません。親AUはないのです。
Tim：ADからAzure ADへ移行するときに、私がとてもわかりにくいのは、Azure ADの比較的平坦な構造です。だから、「ちょっと待って、親子関係を作成したいんだけど」と思ってしまいます。管理単位ではそれができませんね。
Randy：そうです。そうした階層はありません。Azureでもそれはないでしょう? やはり並列のリソースグループがあるだけです。では、Azure ADで小さなかたまりの管理者資格を委譲する方法をお見せしましょう。繰り返しますが、目的は米国側のヘルプデスクに、米国拠点のエンドユーザに対するパスワードリセットの権限を与えることです。
これが、私たちのしようとしていることです。全部、Azure ADの中で行ないます。米国のヘルプデスクのグループを作成しようとしています。そのグループにメンバーを指名します。ここでは一人だけにしましょう。Barryです。Barryはヘルプデスクで作業を行ないます。次に、管理単位を作成して、米国拠点のエンドユーザを全員、そこに含めます。これをUSと呼ぶことにし、そこに他の人も追加します。それから、パスワードリセットのロールを割り当てると、このUSヘルプデスクグループとUS管理単位とが連結し、使っているロールに応じて特定のパーミッションが与えられます。そして、このアクセスは複数の観測地点から見ることができます。つまり、これが有利なのは、ええと……。