この記事では、ゼロ トラスト原則に従う条件付きアクセスのアーキテクチャについて説明します。 このアーキテクチャは、ペルソナ ベースのアプローチを使って、構造化された条件付きアクセス フレームワークを形成します。
条件付きアクセスのゼロ トラスト アーキテクチャ
最初に、アーキテクチャを選ぶ必要があります。 対象指定またはゼロ トラストのどちらかの条件付きアクセス アーキテクチャを検討することをお勧めします。 次の図は、対応する設定を示したものです。
ゼロ トラスト条件付きアクセス アーキテクチャは、ゼロ トラストの原則に最も適したものです。 条件付きアクセス ポリシーで [すべてのクラウド アプリ] オプションを選んだ場合、すべてのエンドポイントが、既知のユーザーや既知のデバイスまたは準拠デバイスなど、指定した付与の制御によって保護されます。 ただし、ポリシーは、条件付きアクセスをサポートするエンドポイントとアプリにだけ適用されるのではありません。 これは、ユーザーが対話するすべてのエンドポイントに適用されます。
さまざまな新しい PowerShell および Microsoft Graph ツールで使用されるデバイス ログイン フロー エンドポイントはその例です。 デバイス ログイン フローは、IoT デバイスのような、サインイン画面を表示できないデバイスからのサインインを許可する方法を提供します。
デバイス ベースのサインイン コマンドが指定されたデバイスで実行され、ユーザーにコードが表示されます。 このコードは、別のデバイスで使用されます。 ユーザーは https://aka.ms/devicelogin にアクセスして、ユーザー名とパスワードを指定します。 他のデバイスからサインインした後は、そのユーザー コンテキスト内の IoT デバイスでサインインが成功します。
このサインインに関する課題は、デバイス ベースの条件付きアクセスがサポートされないことです。 つまり、すべてのクラウド アプリに既知のユーザーと既知のデバイスを必要とするベースライン ポリシーを適用すると、誰もツールやコマンドを使用できません。 デバイス ベースの条件付きアクセスに関する同じ問題が発生するアプリケーションが他にもあります。
もう 1 つのアーキテクチャである対象指定のものは、個々のアプリのみを条件付きアクセス ポリシーの保護対象とする原則に基づいて構築されています。 この場合、Microsoft Entra ID に対するグラフ呼び出しなどのすべてのクラウド アプリがこれまで対応してきた、エンドポイントに対するデバイス ログインは、条件付きアクセス ポリシーによって保護されないため、引き続き機能します。
2 つのアーキテクチャを区別する例としてデバイス ログインを使用する場合は、デバイス ログインを使用して認証できます。 デバイス ログインは、各アプリケーションが対象指定可能であり、それによってデバイスベースのログインを必要とする条件付きアクセス ポリシーで除外できる場合、1 つまたは複数の個々のアプリケーションで許可される可能性があります。
対象指定のアーキテクチャの課題は、すべてのクラウド アプリを保護するのを忘れる場合があることです。 それでも、条件付きアクセス ポリシーで選択可能なすべてのアプリケーションを選択します。 選択できないアプリケーションへのアクセスは、保護されていない状態のままにしておきます。 たとえば、Office ポータル、Azure EA (Enterprise Agreement) ポータル、セキュリティ情報ポータルへのアクセスなどです。これらはすべて非常に機密性の高いポータルです。
別の考慮事項として、Microsoft とパートナーが新機能をリリースし、IT 管理者がさまざまなアプリケーションを Microsoft Entra ID と統合するにつれて、Office 365 と Microsoft Entra のアプリの数が時間とともに増加するという点があります。 そのようなすべてのアプリケーションへのアクセスは、条件付きアクセスをサポートする新しいアプリを検出し、それにポリシーを自動的に適用するメカニズムがある場合にのみ保護されます。 このようなスクリプトの作成と保守は困難な場合があります。
また、1 つの条件付きアクセス ポリシーでサポートされるアプリの最大数は約 250 です。 ペイロードの超過に関するエラーが発生する前に、最大 600 個のアプリを追加できる場合がありますが、その数はサポートされていません。
条件付きアクセスのペルソナ
条件付きアクセス ポリシーを構成する方法は多数あります。 1 つの方法は、アクセス対象のリソースの秘密度に基づいてポリシーを構成する方法です。 実際には、このアプローチは、さまざまなユーザーのリソースへのアクセスを保護するように実装するのが困難な場合があります。
たとえば、ゲストと従業員の両方がアクセスする必要がある機密リソースにアクセスするために、既知のユーザーと既知のデバイスを必要とする条件付きアクセス ポリシーを定義できます。 ゲストがマネージド デバイスからアクセスを試みると、アクセス要求は機能しません。 両方の要件を満たすように条件付きアクセス ポリシーを調整する必要がありますが、通常、安全性の低い要件を満たすポリシーになってしまいます。
もう 1 つの方法は、組織内でユーザーがいる場所に基づいてアクセス ポリシーを定義する方法です。 この方法では、条件付きアクセス ポリシーの数が増えて、管理できなくなる可能性があります。
より優れたアプローチは、一般的なアクセス ニーズに関連するポリシーを構成し、同じニーズを持つユーザーのグループのペルソナに一連のアクセス ニーズをバンドルする方法です。 ペルソナは、共通のエンタープライズ属性、責任、エクスペリエンス、目的、アクセスを共有する ID の種類です。
企業の資産やリソースがさまざまなペルソナによってどのようにアクセスされるのかを理解することは、包括的なゼロ トラスト戦略を開発するのに不可欠です。
Microsoft が推奨する条件付きアクセスのペルソナを次に示します。
Microsoft は、他のペルソナ グループに含まれない ID に対して独立したペルソナを定義することも推奨します。 これは Global ペルソナと呼ばれます。 Global は、ペルソナ グループに含まれない ID に対するポリシーと、すべてのペルソナに適用する必要があるポリシーを、適用するためのものです。
以下のセクションでは、推奨されるいくつかのペルソナについて説明します。
グローバル
Global は、一般的な性質を持つポリシーに対するペルソナつまりプレースホルダーです。 これは、すべてのペルソナに適用されるポリシー、または 1 つの特定のペルソナに適用されないポリシーを定義するために使われます。 他のペルソナによってカバーされないポリシーに使います。 関連するすべてのシナリオを保護するには、このペルソナが必要です。
たとえば、1 つのポリシーを使って、すべてのユーザーのレガシ認証をブロックするとします。 さまざまなペルソナに対して異なる可能性があるレガシ ポリシーのグループを使う代わりに、グローバル ポリシーにすることができます。
もう 1 つの例は、特定のアカウントまたはユーザーを特定のアプリケーションからブロックする必要があり、そのユーザーまたはアカウントがペルソナの一部ではない場合です。 たとえば、Microsoft Entra テナントでクラウド ID を作成した場合、この ID には Microsoft Entra ロールが割り当てられていないため、他のどのペルソナにも含まれません。 そのような場合でも、ID が Office 365 サービスにアクセスするのをブロックすることができます。
どのペルソナ グループにも含まれない ID によるすべてのアクセスをブロックすることができます。 または、多要素認証だけを適用することができます。
管理者
このコンテキストでは、管理者は、Microsoft Entra ID またはその他の Microsoft 365 の任意の管理者ロール (Microsoft Defender for Cloud Apps、Exchange、Defender for Endpoint、コンプライアンス マネージャーなど) を持つ、ゲスト以外の ID (クラウドまたは同期) です。 これらのロールを持つゲストは別のペルソナでカバーされるため、ゲストはこのペルソナから除外されます。
一部の企業では、このペルソナが基づく機密管理者ロール用に個別のアカウントを使用しています。 最善なのは、管理者が特権アクセス ワークステーション (PAW) からこれらの機密アカウントを使う場合です。 しかし、多くの場合、管理者アカウントは標準のワークステーションで使用され、ユーザーは 1 つのデバイスでアカウントを切り替えるだけであることが分かっています。
クラウド管理者ロールの機密性に基づいて区別し、個別のアカウントを使用するのではなく、機密性の低い Azure ロールは Internals ペルソナに割り当てることができます。 その後、代わりに Just-In-Time (JIT) 昇格を使用できます。 この場合、ユーザーは 2 つの条件付きアクセス ポリシーのセット (ペルソナごとに 1 つ) の対象になります。 PAW を使用する場合は、条件付きアクセスでデバイス フィルターを使用するポリシーを導入し、管理者が PAW でのみ許可されるようにアクセスを制限することもできます。
開発者
Developers ペルソナには、固有のニーズを持つユーザーが含まれます。 それらは、Microsoft Entra ID に同期される Active Directory アカウントに基づきますが、Azure DevOps、CI/CD パイプライン、デバイス コード フロー、GitHub などのサービスへの特別なアクセス権を必要とします。 Developers ペルソナには、内部と見なされるユーザーや外部と見なされるユーザーを含めることができますが、1 人のユーザーは 1 つのペルソナにのみ含まれる必要があります。
内部構造
Internals には、Microsoft Entra ID に同期されている Active Directory アカウントを持つか、会社の従業員であるか、標準のエンド ユーザー ロールで作業するすべてのユーザーが含まれます。 開発者である内部ユーザーは Developers ペルソナに追加することをお勧めします。
外部
このペルソナには、Microsoft Entra ID に同期された Active Directory アカウントを持つすべての外部コンサルタントが含まれます。 開発者である外部ユーザーは Developers ペルソナに追加することをお勧めします。
ゲスト
Guests には、顧客テナントに招待された Microsoft Entra ゲスト アカウントを持つすべてのユーザーが含まれます。
GuestAdmins
GuestAdmins ペルソナには、前に説明した管理者ロールのいずれかを割り当てられた Microsoft Entra ゲスト アカウントを持つすべてのユーザーが含まれます。
Microsoft365ServiceAccounts
このペルソナには、他のソリューションがニーズを満たさないとき (マネージド サービス ID の使用など) に、Microsoft 365 サービスへのアクセスに使用されるクラウド (Microsoft Entra ID) ユーザーベースのサービス アカウントが含まれます。
AzureServiceAccounts
このペルソナには、他のソリューションがニーズを満たさないとき (マネージド サービス ID の使用など) に、Azure (IaaS/PaaS) サービスへのアクセスに使用されるクラウド (Microsoft Entra ID) ユーザーベースのサービス アカウントが含まれます。
CorpServiceAccounts
このペルソナには、次のすべての特性を持つユーザー ベースのサービス アカウントが含まれます。
- オンプレミスの Active Directory が元になっている。
- オンプレミスから、または Azure のような別の (クラウド) データセンター内の IaaS ベースの仮想マシンから使用される。
- 任意の Azure または Microsoft 365 サービスにアクセスする Microsoft Entra インスタンスと同期されている。
このシナリオは避ける必要があります。
WorkloadIdentities
このペルソナには、Microsoft Entra サービス プリンシパルやマネージド ID などのマシン ID が含まれます。 条件付きアクセスで、これらのアカウントからのリソースへのアクセスが保護されるようになりました。使用可能な条件と付与の制御に関してはいくつかの制限があります。
アクセス テンプレート カード
アクセス テンプレート カードを使って、各ペルシャの特性を定義することをお勧めします。 次に例を示します。
各ペルソナのテンプレート カードには、ペルソナごとに固有の条件付きアクセス ポリシーを作成するための入力があります。
条件付きアクセスのガイダンス
作成したペルソナに基づいてポリシーをグループ化するための構造化されたアプローチが含まれる条件付きアクセス フレームワークを確認してください。
共同作成者
この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。
プリンシパル作成者:
- Claus Jespersen | プリンシパル コンサルタント ID と Sec
パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。