BLOGAzureブログ

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

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

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

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

• 目次
• １.Azure ADとは？
• ２.Azure ADとオンプレミスADとの違い
• ３.Azure ADが注目される背景
• 4.Azure AD導入のメリット
• 5.Azure ADの機能
• ６.まとめ

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リソースに対してアクセスしたい（させたい）場合も多々あるのです。

ロール（役割）

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

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

Azure ADとオンプレミスADとの違い

オンプレミスで使う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が注目される背景

コロナ禍の影響や働き方改革の推進を受け、リモートワークやテレワークが急速に浸透しました。これまでは社内のローカルネットワークを構築し、オンプレミスADだけで管理が可能でした。しかし、新しい働き方の浸透により、オンプレミスADだけでは管理が難しくなったのです。また、企業におけるSaaSをはじめとしたクラウドサービス利用により、企業の重要なデータや基幹システムも、社外のネットワークで管理されるようになっています。
このような現状において、データやシステムへのアクセスを行うときの保護や認証などの情報セキュリティ対策が重視されるようになりました。またIDやデバイス管理が複雑になっています。このような背景から、クラウドやオンプレミスも包括して一元管理できる Azure ADが注目されているのです。

Azure AD導入のメリット

Azure ADを導入するメリットは何でしょうか。例として3つのメリットを紹介します。

統合認証基盤としての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の機能

組織においてセキュリティを担う担当者の方にはぜひとも活用を検討いただきたい機能を3つ紹介します。

1. Identity Protection ( ID Protection )

Azure ADテナントのID（アカウント）に対する脅威対策ソリューション（機能）です。マイクロソフト社のデータセンターに蓄積された膨大なデータを基に、リスクを検出しそれを自動修復することや必要に応じてレポートを使った調査を行うことができます。

検出されるリスクは、サインインに関連するリスクとユーザーに関連するリスクがあり、レポートにて確認できます。
サインインに関連するリスクは、テナントに対する普段と異なる怪しいサインインを検出します。例えば、パスワードスプレー攻撃や過去にアクセスしてきたことがない国からの認証要求などです。

ユーザーに関連するリスクは、アカウント侵害の疑いを検出します。例えば、アカウント情報の闇サイトへの漏洩や特定の攻撃パターンに一致するユーザーの行動などです。

ちなみに、より詳細に分析するために検出データをSIEMツールなどにエクスポートすることもできます。

検出された後については、Azure ADロールとしてセキュリティに関するロールが割り当てられているユーザーがID Protectionからのアラートを受け取り、リスク検出の結果を確認し対応のフェーズに移ります。もちろん一つ一つ手動で対処することもできますが、リスクが検出された場合、対処完了までの時間というのが重要になるためポリシーを使用して対応を自動化することができます。これによりそもそもアクセスをブロックすることや、許可するにしてもユーザーが自己修復した上でアクセスさせるといった制御を行うことができます。
ちなみに、このポリシーは既定では三つ存在し、さらにこの後紹介する条件付きアクセスと関連させるものもあります。

2. 条件付きアクセス

アプリケーションに対してきめ細かくアクセスを制御できる機能であり、ゼロトラストに関わるとても重要なセキュリティ対策となります。
まず第一段階として正当なユーザーかどうかの認証（判断）が完了した後に、事前に設定した特定の条件（条件付きアクセスポリシー）に基づいてアプリへのアクセスを許可するか否かを判別します。このポリシーは大きく分けて「割り当て」と「アクセス制御」という二つの項目で構成されており、ポリシーを実行するトリガーとなる情報とそれに対するアクションを定義します。

割り当てでは、「誰が何に対してアクセスしてきたとき」を必須項目として定義しオプションで「どのようにアクセスしてきたとき（条件）」も定義します。例えば、ユーザーAがAzure portalに対して日本からアクセスしてきたとき、といった具合です。条件についてはさまざまな要素を組み合わせて構成することができます。
ちなみに、この条件の部分で前述したID Protectionのリスク（ユーザー/サインイン）レベルを条件として設定することもできるというわけです。

アクセス制御では、割り当ての定義通りのアクセスであった場合に「ブロックする」もしくは「どのような要件であればアクセス権を付与する」を定義します。アクセス権を付与する場合には少なくとも一つの追加要件を指定しなければなりません。例えば、多要素認証を要求することや、Microsoft IntuneというMAM/MDMサービスで設定したポリシーに準拠するデバイスかどうかなどです。
ちなみにオプションとして、アクセス後のセッションを監視し続け、そのセッションの中でユーザーが怪しい行動を行うと自動検出して対応してくれる機能を設定することもできます。

いずれの項目についても言えることは、「どのように（な）」の部分を組織のセキュリティ要件に合うように適切に設定することが重要です。

3. Privileged Identity Management ( PIM )

いわゆる特権アクセス管理の機能です。権限の強いAzureリソースもしくはAzure ADロールを必要な時にだけユーザーに付与したり、申請/承認を経てから付与するといったことなどができます。強い権限を持つロールほど、誤用・濫用・本人以外による不正利用の際に被害が大きくなります。
ロール割り当ての権限を持つ管理者とコミュニケーションをとって割り当て/はく奪を手運用で都度行う、といったことももちろん可能ですがミスが発生するし何より大変ですよね。そこで有用なのがこの機能なのです。

対象となるロールを割り当てる際には、「アクティブ化」と「期間」に注意します。
まずアクティブ化についてですが、これはそのロールを使用できる状態にするということです。つまり、単純にロールを割り当てられただけだと使う資格はあるが実際に使えないということなのです。割り当ての際には即使用できる状態にするかアクティブ化の操作を経て使用できる状態にするか選択できます。なお、アクティブ化する際には、MFAを要求したり理由の記入や管理者などの承認を必須とすることなども設定できます。

期間についても適切に設定しましょう。これについては、ロールが割り当てられている期間とアクティブ化されている期間があります。前者は1カ月や1年といったある程度まとまった期間であり（最大は永続）、後者は24時間が最大（管理者が30分～24時間の間で任意の値を設定）です。例えば、2カ月間続くプロジェクトがあるのでその期間をアクティブ化可能な期間として設定し、その期間内でその（特権）ロールを使って作業を行う時間帯は都度アクティブ化して使用するといった感じです。

ちなみに、ロール割り当てを定期的にレビューして適切なユーザーのみがロールを持っていることを確認することができる、アクセスレビュー機能もあります。

まとめ

いかがだったでしょうか？まだまだ奥が深くご紹介しきれていない部分もたくさんありますが、全体像としてはある程度イメージできたのではないでしょうか。

Azureを使い始める場合、単純にアーキテクチャ設計だけでなく、今回ご紹介したようなIDアクセス管理やセキュリティなどの設計も必要です。
これからAzureをはじめるのにさらにこんな奥の深いAzure ADについても学ぶ必要があるのか・・・設計が大変だ・・・と少々憂鬱になったかもしれませんが、そんなときにはまずは法人でのAzure導入前の相談窓口であるAzure相談センターまでぜひお気軽にお問い合わせください。さまざまなサポートメニューやソリューションでご支援させていただきます。