BLOGAzureブログ

皆さまこんにちは、SB C&Sの八釼です。
突然ですが、Azure Active Directory ( Azure AD ) をご存じですか？
Azureに関わったことがない方でも名前ぐらいは聞いたことがあり、「なんかユーザー認証してくれるサービス」くらいの理解はあるかもしれません。

さまざまな観点から少々ややこしいサービスであり、あまり関わったことがない方には全体像が掴みにくいのです。ざっくりと言ってしまうと、アプリケーションに対する統合認証基盤であり、そして重要なセキュリティ基盤でもあります。

そこで、Azure ADについて根本から整理して全体像を暴いていこうと思います。
Azure ADの役割や魅力について、基本的な内容をご紹介し、セキュリティ機能を中心に深堀した内容をご紹介したいと思います。

本サービスはAzureのためだけに使用するものではありませんが、本ブログの性質上、基本的にはAzureの視点で解説します。Azureを使う、Azureに関わるなら前提となる重要なサービスですので、しっかり押さえていきましょう。

• 目次
• 1.そもそもAzure ADとは？
• 2.紛らわしい製品・サービス
• 3.最後に

そもそもAzure ADとは？

Identity Management as a Service ( IDaaS )であり、セキュリティ基盤です。クラウドベースのIDを一元管理し、アプリケーションへのアクセス要求に対して認証と認可を行います。クラウドサービスとして提供されるものなので、当然ながらドメインコントローラーのようなサーバーの展開やメンテナンスは必要ありません。

「Azure」と冠していてAzure portalからも操作ができるのですが、後述するとおり課金体系が異なっており、また単純にAzure専用の認証基盤というわけではないので、Azureとは別サービスと考えていただいて差し支えありません。

ゼロトラストとAzure AD

現在の主流となったセキュリティの概念であるゼロトラストを前提とするとき、セキュリティ境界は「ID」であり、これを正当なユーザー以外に不正に使用させないことは極めて重要です。つまり、ゼロトラスト時代においては「認証」と「認可」はセキュリティ対策の根幹をなし、Azure ADはセキュリティ基盤と言えるのです。

ゼロトラストについて詳しく知りたい方はこちらをご覧ください。

前提として押さえておくべき用語や概念

テナントとディレクトリ

Azure ADが認証基盤として絶対的に必要となるMicrosoft 365やAzureといったマイクロソフトクラウドサービスをサインアップすると、Azure AD環境（テナント）を取得することになります。もちろんその後、任意で新規作成することも可能です。いずれにせよ作成した（された）テナントには必ず1つのディレクトリが構成されます。そのため、テナントとディレクトリはほぼ同じ意味合いで使用されます。

なお、Azureサブスクリプションとテナント（ディレクトリ）は信頼関係を結びますが包含関係ではありません。

また、サブスクリプションは必ず一つのテナントに紐づきますが、1対1の関係ではありません。一つのテナントに複数のサブスクリプションを紐づけることも可能です。例えば、本番環境と開発環境をサブスクリプションで分けて管理していくこともできます。

プリンシパル

Azure ADの世界ではテナント毎にアカウントを作成することになり、もちろんそれぞれのアカウントは一意のIDを持つことになります。
なお、アカウント（ID）が付与されるのは人間に対してだけとは限りません。アプリケーションの場合もあります。例えば、アプリケーションがAzureリソースに対してアクセスしたい（させたい）場合も多々あるのです。

ここで、アクセス制御（認証/認可）の対象となるオブジェクトのことを「プリンシパル」と呼び、ユーザープリンシパル（人間用）とサービスプリンシパル（アプリケーション用）に大別されます。

ロール（役割）

関連するタスクのアクセス権限をまとめた単位です。プリンシパルに対して各種ロールを割り当てることでさまざまな権限を付与し、「できること」を管理します。

なお、あらかじめ用意されている組み込みロールと独自に作成するカスタムロールが存在します。このロールの割り当てについては若干複雑なのですが、ひとまずはプリンシパルに対して何かしらロールを割り当てる必要があるという理解で問題ありません。

基本的な役割やメリット

統合認証基盤としての2つの機能（ID管理とSSO）

多様化している私たちの業務環境では、ユーザーにとっても管理者にとっても頭が痛い問題として「増え続けるID・パスワード問題」があります。便利なSaaSアプリがどんどんと導入される一方、それぞれにIDやパスワード（認証情報）が必要でポリシーもバラバラである場合も多いため管理工数は増える一方です。結果としてパスワードの使いまわしが横行しますが、セキュリティの観点からは良いことではありません。またパスワードがわからなくなる場合も多くお互いに負担がかかります。

そのためID管理は重要です。
Azure ADによりユーザーIDやパスワードなどの情報を一元的に管理し、それを社内のさまざまなシステムに対して同期させて管理業務を効率化できます。
この認証機能をさまざまなアプリケーションに対して担ってくれるのがAzure ADなのです。なお、セキュリティの低い単純なID・パスワードの二要素による認証だけでなく、それよりも利便性や安全性に優れる認証方法や手段を用いることもできます。

そしてSSO（シングルサインオン）が可能です。
利用者が認証情報を入力しAzure ADへのサインインが成功すれば、その認証によってさまざまなアプリケーションやシステムへアクセスできます。職場で使用するさまざまなアプリケーションの認証をAzure ADで統合すればログインの際にこれらの認証情報をそれぞれ入力する必要がなくなります。つまり、Azure ADに対する認証情報だけを覚えておけば済みます。
ちなみに、「Azure」と冠するのでAzure（サブスクリプション）のためだけに存在する気がしてしまいますが、Azureを含むMicrosoftのクラウドサービス、そして皆さんが良く知っているものも含めた世界中の膨大な種類のSaaSアプリケーションや、独自に開発したアプリにだってSSOでアクセスできます。

権限管理

ここまでは、主に認証に焦点を当てて解説してきましたが、今度は「何ができるのか（権限）」に相当する認可についても解説します。認証はそのIDがその組織のユーザー本人であること、つまりなりすましされていないかを確かめる行為です。では認証が正当に行えればそれでよいのでしょうか？そんなはずはありません。それぞれのアカウント（プリンシパル）には、やれるべきこととやれるべきでないことが決まっているはずです。

そこでプリンシパルに対して適切なロール（権限）を割り当てて管理します。少々地味に聞こえるかもしれませんが、Azureに関するすべての動作に絡む上セキュリティの観点からもかなり重要な管理と言えます。特に、強い権限の取り扱いには注意が必要ですが、これに対する管理を考慮できる仕組みも有しています。

アクセス制御

また、認証が正当に完了すればそれで何でもかんでもアクセスさせて良いわけではありません。
例えば、従業員が全員日本に住み働いている企業において、突如海外からAzure portalへアクセスが来るのは不自然ですよね？もしかしたら何か事情があるかもしれませんし、アカウントを乗っ取られた可能性も濃厚です。認証が通ったからといってそのままアクセスさせるのは少々考え物です。
そのため、あらかじめ設定した条件に基づいてアクセスの可否を下せる機能があります。

課金について

Azure ADを使うには課金が必要かというと実は必ずしもそうではありません、基本的な機能に限定されますが無償でも使えます。通常は法人が利用する場合には有償版が推奨ですが、もし要件的に問題なければ無償版での運用も可能です。
詳細については以下の公式サイトの情報をご確認いただければと思いますが、「Free」が無償版です。4つのエディションが用意されていますが、基本的にビジネスユースの場合にはPremium P1もしくはP2をご選択ください。

公式サイト |  Azure Active Directory の価格

ここで重要なことは、有償版については「ユーザー単位課金」なのです。つまりAzure AD（有償版）を使うためには（ユーザー単位で）ライセンスを調達することになります。調達したライセンスはユーザーまたはグループに割り当てます。
Azureサブスクリプションは皆さまご存じの通り従量課金ですので、完全に異なる契約形態であり請求書も別々に発行されます。

紛らわしい製品・サービス

オンプレミスで使うActive Directory Domain Services ( ADDS )

オンプレミスで使うActive Directory Domain Services ( ADDS )は、Azure ADとは完全に別のものです。サポートしているプロトコルも、提供される機能も概念もまったく異なります。

例えば、ADDSの認証プロトコルはKerberosが基本になりますが、Azure ADはインターネットで使用するIDを管理対象とするため、主にOpenID
ConnectやSAMLが使用されます。ドメインについても、ADDSの場合フォレストに対してドメインが複数作成できそれらの間で信頼関係を結べますが、Azure
ADは違います。それぞれのドメインは完全に個別管理で分離されていて信頼関係は結べません。

このように、ADDSの知見が大いに活きるというわけではないので注意が必要です。

Azure Active Directory Domain Services ( Azure AD DS )

また非常にややこしい名称のサービスが出てきてなんだか頭がこんがらがってきましたね。これはAzureで提供されるマネージドドメインサービスです。単純にオンプレミスで使うADDSドメイン環境を置き換えられるわけではありませんが、互換性がありADDSの知見も基本的に活かせます。

ADDSやAzure ADDSについて詳しく知りたい方はこちらをご覧ください。

　　

最後に

今回は前編として、まずは基本的な内容をご紹介しました。
しかしここまでだと、ゼロトラスト・アーキテクチャ構築の基礎となるAzure ADの実力がまだそこまで見えてきませんね。

後編では、より踏み込んでその辺り解説しますのでぜひお見逃しのないようお願いします。