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