編集

Share via

AWS に対する Microsoft Entra の ID 管理とアクセス管理

Azure
Microsoft Entra ID

この記事では、AWS ID のアーキテクト、管理者、セキュリティ アナリストに対し、AWS 用の Microsoft Entra ID とアクセス ソリューションをデプロイするためのすぐに役立つ分析情報と、詳細なガイダンスを提供します。 切り替える準備ができるまで、既存の ID プロバイダーや AWS アカウント ユーザーに影響を与えることなく、このような Microsoft のセキュリティ ソリューションを構成してテストできます。

アーキテクチャ

AWS により、作成されるアカウントごとに個別の "ID およびアクセス管理 (IAM) ストア" が作成されます。 次の図は、1 つの AWS アカウントを使用する AWS 環境の標準的な設定を示しています。

Diagram showing a single-account AWS environment.

"ルート ユーザー" は AWS アカウントを完全に制御し、アクセスを他の ID に委任します。 AWS IAM の "プリンシパル" は、AWS アカウントにアクセスする必要がある個々のロールとユーザーに、一意の ID を提供します。 AWS IAM では、複雑なパスワードと基本的な MFA を使用して、各ルート、プリンシパル、およびユーザー アカウントを保護できます。

多くの組織には複数の AWS アカウントが必要であるため、管理が複雑な "ID のサイロ" が発生します。

Diagram showing a multiple-account AWS environment.

一元化された ID 管理を可能にし、複数の ID とパスワードを管理する必要をなくすために、ほとんどの組織はプラットフォーム リソースにシングル サインオンを使用したいと考えています。 一部の AWS のお客様は、SSO 統合のためにサーバーベースの Microsoft Active Directory を利用しています。 また、サードパーティのソリューションに投資し、ID を同期またはフェデレーションし、SSO を実現しているお客様もいます。

Microsoft Entra ID には、強力な SSO 認証を使って一元化された ID 管理が用意されています。 AWS を始めとして、一般的な Web 認証標準に準拠しているほぼすべてのアプリまたはプラットフォームには、ID およびアクセス管理に Microsoft Entra ID を使用できます。

多くの組織は、既に Microsoft Entra ID を使って、Microsoft 365 またはハイブリッド クラウド ID を割り当て、保護しています。 従業員は、Microsoft Entra ID を使って、メール、ファイル、インスタント メッセージング、クラウド アプリケーション、オンプレミス リソースにアクセスします。 Microsoft Entra ID を AWS アカウントとすばやく簡単に統合し、管理者と開発者は、既存の ID を使って AWS 環境にサインインできるようにすることができます。

次の図は、Microsoft Entra ID を複数の AWS アカウントと統合して、一元化された ID とアクセス管理を実現する方法を示しています。

Diagram showing AWS and Microsoft Entra integration.

Microsoft Entra ID には、AWS と直接統合するための機能がいくつか用意されています。

  • レガシ式、従来式、および最新式の認証ソリューションを対象とする SSO。
  • MFA。Microsoft Intelligent Security Association (MISA) パートナーのいくつかのサードパーティ ソリューションとの統合が含まれています。
  • 強力な認証と厳格なガバナンスのための強力な "条件付きアクセス" 機能。 Microsoft Entra ID では、条件付きアクセス ポリシーとリスク ベースの評価を使って、AWS 管理コンソールと AWS リソースへのユーザー アクセスを認証および認可します。
  • 大規模な脅威の検出と自動応答。 Microsoft Entra ID により、1 日あたり 300 億件を超える認証要求と、世界中の脅威に関する何兆件ものシグナルが処理されています。
  • Privileged Access Management (PAM) 。特定のリソースへの "Just-In-Time (JIT) プロビジョニング" が可能になります。

AWS アカウントを使った高度な Microsoft Entra ID 管理

その他の高度な Microsoft Entra 機能を使うと、機密性が最高レベルの AWS アカウントに追加のコントロール レイヤーを用意できます。 Microsoft Entra ID P2 ライセンスには、次の高度な機能が含まれています。

  • Privileged Identity Management (PIM) 。Azure および Microsoft 365 内のすべての委任されたロールに対する高度な制御を実現します。 たとえば、管理者が常に全体管理者ロールを使用するのではなく、オンデマンドでロールをアクティブにするアクセス許可を持っています。 このアクセス許可は、1 時間などの設定された制限時間を過ぎると無効になります。 PIM により、すべてのアクティブ化がログに記録されます。また、アクティブ化機能をさらに制限できる他のコントロールが用意されています。 管理者が変更を加える前に、PIM によってガバナンスと保護の追加レイヤーを確保することにより、ID アーキテクチャをさらに保護します。

    AWS ロールにアクセスするために作成したものなど、カスタム グループへのアクセスを制御すると、PIM を任意の委任されたアクセス許可に拡張できます。 PIM のデプロイの詳細については、Microsoft Entra Privileged Identity Management のデプロイに関するページを参照してください。

  • Advanced Identity Protection を使用すると、ユーザーまたはセッションのリスクを監視することにより、Microsoft Entra のサインインのセキュリティを強化できます。 ユーザーのリスクには、一般公開されている違反一覧に掲載されているユーザー ID やパスワードなど、資格情報が侵害される可能性が定義されています。 セッション リスクにより、危険な場所、IP アドレス、またはその他の侵害の兆候を示すものからサインイン アクティビティが行われたかどうかを判断します。 どちらの検出の種類も、Microsoft の包括的な脅威インテリジェンス機能を基にしています。

    Advanced Identity Protection の詳細については、Microsoft Entra ID Protection のセキュリティの概要に関するページを参照してください。

  • Microsoft Defender for Identity を使用すると、すべてのアクティビティと脅威の信号を監視することで、Active Directory ドメイン コントローラーで実行されている ID とサービスを保護することができます。 お客様の侵害の調査から得られた実際の経験に基づいて、Defender for Identity によって脅威が特定されます。 Defender for Identity によってユーザーの行動が監視され、攻撃対象領域を減らして偵察、横移動、ドメイン支配などの高度な攻撃を防ぐことが推奨されます。

    Defender for Identity の詳細については、「Microsoft Defender for Identity の概要」を参照してください。

シナリオの詳細

重要なワークロードと機密性の高い情報をサポートするアマゾン ウェブ サービス (AWS) アカウントには、強力な ID 保護とアクセス制御が必要です。 AWS ID 管理は、Microsoft Entra ID と組み合わせると強化されます。 Microsoft Entra ID AD は、クラウドベースの包括的で一元的な ID およびアクセス管理ソリューションであり、AWS アカウントと環境のセキュリティと保護に役立ちます。 Microsoft Entra ID を使うと、"多要素認証 (MFA)" と "条件付きアクセス" のポリシーにより、一元化された "シングル サインオン (SSO)" と強力な認証が実現します。 Microsoft Entra ID では、AWS の ID 管理、ロールベースの ID、アクセス制御などがサポートされています。

AWS を使う多くの組織は、Microsoft Entra ID for Microsoft 365 またはハイブリッド クラウドの ID 管理とアクセス保護を既に利用しています。 このような組織は、AWS アカウント用に Microsoft Entra ID をすばやく簡単に使用できます。多くの場合、追加コストはかかりません。 Privileged Identity Management (PIM) や高度な ID 保護など、その他の高度な Microsoft Entra 機能は、機密性が最高レベルの AWS アカウントの保護に役立ちます。

Microsoft Entra ID は、Microsoft Defender for Cloud Apps や Microsoft Sentinel などの他の Microsoft セキュリティ ソリューションと簡単に統合できます。 詳細については、AWS 向けの Defender for Cloud Apps と Microsoft Sentinel に関するページを参照してください。 Microsoft セキュリティ ソリューションは拡張可能であり、複数レベルの保護を備えています。 組織は、これらのソリューションの 1 つ以上を、他の種類の保護と共に実装することで、現在および将来の AWS デプロイを保護する完全なセキュリティ アーキテクチャを実現できます。

推奨事項

Security

すべてのクラウド セキュリティ ソリューションには、以下の原則とガイドラインが重要です。

  • クラウド環境へのユーザーおよびプログラムによるアクセスを、組織で監視して検出し、自動的に保護できるようにします。

  • 現在のアカウントを継続的に確認して、ID とアクセス許可のガバナンスと制御を確保します。

  • 最小限の特権とゼロ トラストの原則に従います。 各ユーザーが、信頼されたデバイスと既知の場所から、必要な特定のリソースのみにアクセスできることを確認します。 すべての管理者と開発者のアクセス許可を減らして、実行している役割に必要な権限のみを提供します。 定期的にレビューを行います。

  • プラットフォームの構成の変更を継続的に監視します (特に、それによって特権の昇格や攻撃の永続化の機会が提供される場合)。

  • コンテンツを積極的に検査および制御することにより、不正なデータ流出を防止します。

  • 既に所有している可能性のある、Microsoft Entra ID Premium P2 のような追加費用なしでセキュリティを強化できるソリューションを利用します。

AWS アカウントの基本的なセキュリティ

AWS のアカウントとリソースに対して基本的なセキュリティの検疫を確実に行うには:

  • AWS のアカウントとリソースをセキュリティ保護するためのベスト プラクティスに関するページで、AWS のセキュリティ ガイダンスを確認します。

  • AWS マネジメント コンソールを使用してすべてのデータ転送を積極的に検査することで、マルウェアやその他の悪意のあるコンテンツをアップロードおよびダウンロードするリスクを軽減します。 Web サーバーやデータベースなど、AWS プラットフォーム内のリソースで直接アップロードまたはダウンロードされるコンテンツには、追加の保護が必要になる場合があります。

  • 次のような他のリソースへのアクセスを保護することを検討します。

    • AWS アカウント内に作成されたリソース。
    • Windows Server、Linux Server、コンテナーなどの特定のワークロード プラットフォーム。
    • 管理者および開発者が AWS マネジメント コンソールにアクセスするために使用するデバイス。

AWS IAM のセキュリティ

AWS マネジメント コンソールをセキュリティで保護するための重要な側面は、機密性の高い構成を変更できるユーザーを制御することです。 AWS アカウントのルート ユーザーには無制限のアクセス権があります。 セキュリティ チームは、ルート ユーザー アカウントを完全に制御し、AWS マネジメント コンソールにサインインすることや、AWS リソースを使用することをできないようにする必要があります。

ルート ユーザー アカウントを制御するには:

  • ルート ユーザーのサインイン資格情報を、個人のメール アドレスからセキュリティ チームが管理するサービス アカウントに変更することを検討します。
  • ルート ユーザー アカウントのパスワードは必ず複雑にし、ルート ユーザーに MFA を適用します。
  • サインインに使用されているルート ユーザー アカウントのインスタンスのログを監視します。
  • ルート ユーザー アカウントは緊急時にのみ使用します。
  • 管理タスクにルート ユーザーを使うのではなく、Microsoft Entra ID を使って、委任された管理アクセスを実装します。

適切なマッピングと割り当てについて、他の AWS IAM アカウント コンポーネントをよく理解し、確認します。

  • 既定では、アクセスを委任する 1 つ以上の ID をルート ユーザーが作成するまで、AWS アカウントには "IAM ユーザー" がありません。 Microsoft Active Directory などの別の ID システムの既存のユーザーを同期するソリューションでは、IAM ユーザーを自動的にプロビジョニングすることもできます。

  • "IAM ポリシー" により、AWS アカウント リソースへの委任されたアクセス権が付与されます。 AWS には、750 を超える固有の IAM ポリシーが用意されています。また、お客様がカスタム ポリシーを定義することもできます。

  • "IAM ロール" により、特定のポリシーが ID にアタッチされます。 ロールは、"ロールベースのアクセス制御 (RBAC) " を管理する方法です。 現在のソリューションでは、外部 ID を使い、IAM ロールを想定して Microsoft Entra ID を実装しています。

  • "IAM グループ" は、RBAC を管理する方法でもあります。 IAM ポリシーを個々の IAM ユーザーに直接割り当てるのではなく、IAM グループを作成し、1 つ以上の IAM ポリシーをアタッチしてアクセス許可を割り当て、IAM ユーザーをグループに追加して、リソースへの適切なアクセス権を継承します。

一部の "IAM サービス アカウント" は、プログラムによるアクセスを提供するために AWS IAM で引き続き実行する必要があります。 このようなアカウントは見直し、そのセキュリティ資格情報を安全の格納し、アクセスを制限し、資格情報を定期的にローテーションする必要があります。

このシナリオのデプロイ

この次のセクションでは、個々の AWS アカウントにシングル サインオンするために Microsoft Entra ID をデプロイする方法について説明します。

計画と準備

Azure セキュリティ ソリューションのデプロイを準備するには、現在の AWS アカウントと Microsoft Entra の情報を確認して記録します。 複数の AWS アカウントがデプロイされている場合は、アカウントごとにこれらの手順を繰り返します。

  1. AWS Billing Management Console で、現在の AWS アカウントの次の情報を記録します。

    • [AWS Account Id](AWS アカウント ID) 。一意の識別子。
    • [Account Name](アカウント名) またはルート ユーザー。
    • [Payment method](支払い方法) 。クレジット カードまたは会社の請求契約に割り当てられているかどうか。
    • AWS アカウント情報へのアクセス権を持つ [Alternate contacts](代わりの連絡先) 。
    • 緊急アクセスのために安全に更新および記録されている [Security questions](セキュリティの質問) 。
    • データ セキュリティ ポリシーに準拠するために有効または無効にされている [AWS regions](AWS リージョン) 。

  2. AWS IAM Management Console で、次の AWS IAM コンポーネントを確認して記録します。

    • 作成された [Groups](グループ) 。アタッチされている詳細なメンバーシップとロールベースのマッピング ポリシーが含まれます。
    • 作成された [Users](ユーザー) 。ユーザー アカウントの [Password age](パスワードの有効期間) 、サービス アカウントの [Access key age](アクセス キーの有効期間) が含まれます。 また、各ユーザーに対して MFA が有効になっていることを確認します。
    • [Roles](ロール) 。 2 つの既定のサービスにリンクされたロールである AWSServiceRoleForSupport と AWSServiceRoleForTrustedAdvisor があります。 カスタムである他のロールを記録します。 これらのロールは、Microsoft Entra ID でロールをマップするために使う、アクセス許可ポリシーにリンクされています。
    • ポリシー。 すぐに使用できるポリシーには、 [Type](種類) 列に [AWS managed](AWS マネージド) 、 [Job function](ジョブ関数) 、または [Customer managed](カスタマー マネージド) があります。 カスタムであるその他のすべてのポリシーを記録します。 また、 [Used as](次として使用) 列のエントリから、各ポリシーが割り当てられている場所も記録します。
    • [Identity providers](ID プロバイダー) 。既存の Security Assertion Markup Language (SAML) ID プロバイダーを把握できます。 既存の複数の ID プロバイダーを 1 つの Microsoft Entra ID プロバイダーに置き換える方法を計画します。

  3. Azure portal で Microsoft Entra テナントを確認します。

    • テナントの情報を評価して、テナントに Microsoft Entra ID P1 または P2 のライセンスがあるかどうかを確認します。 P2 ライセンスでは、高度な Microsoft Entra ID 管理の機能が提供されます。
    • エンタープライズ アプリケーションを評価して、AWS アプリケーションの種類を使用している既存のアプリケーションがあるかどうかを確認します ( [ホームページ URL] 列の http://aws.amazon.com/)。

Microsoft Entra のデプロイを計画する

Microsoft Entra のデプロイ手順では、Microsoft 365 の実装など、組織に対して Microsoft Entra ID が既に構成されていることを前提としています。 アカウントは、Active Directory ドメインから同期するか、Microsoft Entra ID で直接作成されたクラウド アカウントにすることができます。

RBAC を計画する

AWS のインストールで IAM グループと RBAC のロールが使われている場合は、その既存の RBAC 構造を新しい Microsoft Entra ユーザー アカウントとセキュリティ グループにマップできます。

AWS アカウントに強力な RBAC 実装がない場合は、最も機密性の高いアクセスから取り組みます。

  1. AWS アカウントのルート ユーザーを更新します。

  2. IAM ポリシー AdministratorAccess にアタッチされている AWS IAM ユーザー、グループ、およびロールを確認します。

  3. リソースやその他の構成項目を変更、作成、または削除できるポリシーから始めて、他の割り当てられた IAM ポリシーを処理します。 [Used as](次として使用) 列を確認すると、使用中のポリシーを特定できます。

プランの移行

Microsoft Entra ID により、すべての認証と認可が一元化されます。 新しい方法を適用する準備ができるまで、管理者や開発者に影響を与えることなく、ユーザー マッピングと RBAC を計画し、構成することができます。

AWS IAM アカウントから Microsoft Entra ID に移行するプロセスの概要は次のとおりです。 詳細な手順については、デプロイに関するセクションを参照してください。

  1. IAM ポリシーを Microsoft Entra のロールにマップし、RBAC を使ってロールをセキュリティ グループにマップします。

  2. 各 IAM ユーザーを適切なセキュリティ グループのメンバーである Microsoft Entra ユーザーに置き換えてサインインし、適切なアクセス許可を取得します。

  3. Microsoft Entra アカウントを使って AWS にサインインするように各ユーザーに依頼することでテストし、適切なアクセス レベルが付与されていることを確認します。

  4. ユーザーが Microsoft Entra ID のアクセスを確認したら、AWS IAM ユーザー アカウントを削除します。 すべてのユーザーが移行されるまで、ユーザーごとにこのプロセスを繰り返します。

サービス アカウントとプログラムによるアクセスについて、同じアプローチを使用します。 そのアカウントを使う各アプリケーションを更新して、代わりに同等の Microsoft Entra ユーザー アカウントを使うようにします。

その他の AWS IAM ユーザーには、MFA を有効にした複雑なパスワード、または定期的に置換されるアクセス キーを使用するようにします。

次の図は、Microsoft Entra ID と AWS IAM 全体の構成手順と、最終的なポリシーとロール マッピングの例を示しています。

Diagram showing configuration steps and final role mapping from AWS IAM to Azure AD.

シングル サインオンの統合

Microsoft Entra ID は、AWS SSO とのシングル サインオンの統合をサポートしています。 1 つの場所で Microsoft Entra ID を AWS に接続し、数百のアカウントと AWS SSO が統合されたアプリケーションでアクセスを一元的に管理できます。 この機能により、ユーザーが AWS CLI を使うためのシームレスな Microsoft Entra サインイン エクスペリエンスを実現できます。

次の Microsoft セキュリティ ソリューションの手順では、ロール AWS Administrators および AWS Developers の例に SSO を実装します。 その他に必要なロールについても、このプロセスを繰り返します。

この手続きには、次の手順があります。

  1. 新しい Microsoft Entra エンタープライズ アプリケーションを作成します。
  2. AWS に対する Microsoft Entra SSO を構成します。
  3. ロール マッピングを更新します。
  4. AWS Management Console に対する Microsoft Entra SSO をテストします。

次のリンクでは、詳細な実装手順とトラブルシューティングが説明されています。

Microsoft Entra エンタープライズ アプリケーションに AWS アプリを追加する

AWS 管理者と開発者は、エンタープライズ アプリケーションを使って認証のために Microsoft Entra ID にサインインし、認可と AWS リソースへのアクセスのために AWS にリダイレクトします。 アプリケーションを表示する最も簡単な方法は、https://myapps.microsoft.com にサインインすることですが、簡単にアクセスできる任意の場所に一意の URL を公開することもできます。

ギャラリーからのアマゾン ウェブ サービス (AWS) の追加に関するページに記載されている手順に従って、エンタープライズ アプリケーションを設定します。 これらの手順により、Microsoft Entra エンタープライズ アプリケーションに追加する AWS アプリを把握できます。

DevTest や Production など、管理する AWS アカウントが複数ある場合は、会社の識別子と特定の AWS アカウントを含むエンタープライズ アプリケーションの一意の名前を使用します。

Screenshot that shows creating the enterprise application in Azure AD.

AWS に対して Microsoft Entra SSO を構成する

AWS に対して Microsoft Entra SSO を構成するには、次の手順を実行します。

  1. Azure Portal で、Microsoft Entra SSO の構成の手順に従って、作成したエンタープライズ アプリケーションを AWS へのシングル サインオン用に構成します。

  2. AWS コンソールで、AWS SSO の構成に関するページの手順に従って、シングル サインオン用に AWS アカウントを構成します。 この構成の一環として、Microsoft Entra プロビジョニング エージェントの代替として機能する新しい IAM ユーザーを作成して、使用できるすべての AWS IAM ロールを Microsoft Entra ID に同期できるようにします。 AWS マネジメント コンソールにサインインできるようになるには、AWS 側でユーザーをロールにマップするためにこの IAM ユーザーが必要です。

  • この統合をサポートするために、作成するコンポーネントを簡単に識別できるようにします。 たとえば、"Svc-" のような標準の名前付け規則を使ってサービス アカウントに名前を付けます。
  • 必ずすべての新しい項目を文書化してください。
  • 新しい資格情報には必ず複雑なパスワードを含めて、安全なライフサイクル管理のために一元的に格納します。

このような構成手順に基づいて、次のような相互作用の図にすることができます。

Diagram of the configuration interactions.

AWS コンソールで、下の手順に従って追加のロールを作成します。

  1. AWS IAM で、[Role](ロール) -> [Create Role](ロールの作成) を選択します。

  2. [Create Role](ロールの作成) ページで、以下の手順を実行します。

    1. [信頼されたエンティティの種類を選択] で、 [SAML 2.0 フェデレーション] を選択します。
    2. [Choose a SAML 2.0 Provider](SAML 2.0 プロバイダーを選択) で、先ほどの手順で作成した SAML プロバイダーを選択します。
    3. [Allow programmatic and AWS Management Console access] を選択します。
    4. Permissions(次へ: アクセス許可) をクリックします。

  3. [Attach permissions policies](アクセス許可ポリシーのアタッチ) ダイアログ ボックスで、 [AdministratorAccess] を選択します。 次に、次のステップ: タグを選択します。

  4. [Add Tags](タグの追加) ダイアログ ボックスを空白のままにして、 [Next: Review](次へ: 確認) を選択します。

  5. [Review](確認) ダイアログ ボックスで、次の手順を行います。

    1. [Role Name](ロール名) に、使用するロール名 (Administrator) を入力します。
    2. [Role Description](ロールの説明) に説明を入力します。
    3. [Create Role](ロールの作成) を選択します。

  6. 上記の手順に従って、追加のロールを作成します。 ロールに Developer という名前を付け、選択したいくつかのアクセス許可 (AmazonS3FullAccess など) をそれに付与します。

    AWS で Administrator と Developer の各ロールが正常に作成されました。

  7. Microsoft Entra ID で次のユーザーとグループを作成します。

    • User 1: Test-AWSAdmin
    • User 2: Test-AWSDeveloper
    • Group 1: AWS-Account1-Administrators
    • Group 2: AWS-Account1-Developers
    • Test-AWSAdmin を AWS-account1-Administrators のメンバーとして追加する
    • Test-AWSDeveloper を AWS-Account1-Developers のメンバーとして追加する

  8. AWS Single-Account Access でロール プロビジョニングを構成する方法に関するページの手順に従って、自動化されたロール プロビジョニングを構成します。 最初のプロビジョニング サイクルが完了するまで最大 1 時間かかる場合があります。

ロール マッピングの更新方法

2 つのロールを使用しているため、こちらの追加の手順を実行します。

  1. プロビジョニング エージェントから少なくとも 2 つのロールを認識できることを確認します。

    Screenshot of the two roles in Azure AD.

  2. [ユーザーとグループ] に移動し、 [ユーザーの追加] を選択します。

  3. AWS-Account1-Administrators を選択します。

  4. 関連付けられているロールを選択します。

    Screenshot of selecting an associated role.

  5. グループロールのマッピングごとに、上記の手順を繰り返します。 完了すると、2 つの Microsoft Entra グループが AWS IAM ロールに正しくマップされます。

    Screenshot showing Groups mapped to correct Roles.

ロールを表示または選択できない場合は、[プロビジョニング] ページに戻り、Microsoft Entra プロビジョニング エージェントでのプロビジョニングが成功したことを確認し、IAM ユーザー アカウントに正しいアクセス許可が付与されていることを確認します。 また、プロビジョニング エンジンを再起動して、インポートを再試行することもできます。

Screenshot of Restart provisioning in the menu bar.

AWS Management Console に対する Microsoft Entra SSO をテストする

各テスト ユーザーとしてサインインをテストし、SSO が機能することを確認します。

  1. 新しいプライベート ブラウザー セッションを起動して、保存されている他の資格情報がテストと競合しないようにします。

  2. 先ほど作成した Test-AWSAdmin または Test-AWSDeveloper Microsoft Entra ユーザー アカウントの資格情報を使って、https://myapps.microsoft.com に移動します。

  3. AWS コンソール アプリの新しいアイコンが表示されます。 アイコンを選択し、認証のプロンプトに従います。

    Screenshot of the AWS Console app icon.

  4. AWS コンソールにサインインしたら、機能を使用して、このアカウントに適切な委任アクセス権があることを確認します。

  5. ユーザー サインイン セッションの名前付け形式に注意してください。

    ロール / UPN / AWS アカウント番号

    このユーザー サインイン セッション情報を使用して、Defender for Cloud Apps または Microsoft Sentinel でのユーザー サインイン アクティビティを追跡できます。

    Screenshot of sign-in session information.

  6. サインアウトし、他のテスト ユーザー アカウントに対してこのプロセスを繰り返して、ロールのマッピングとアクセス許可の違いを確認します。

条件付きアクセスを有効にする

MFA を要求する条件付きアクセス ポリシーを作成するには:

  1. Azure portal で [Microsoft Entra ID]>[セキュリティ] に移動し、[条件付きアクセス] を選びます。

  2. 左側のナビゲーションで、 [ポリシー] を選択します。

    Screenshot of the Microsoft Entra Conditional Access screen with Policies selected.

  3. [新しいポリシー] を選択し、次のようにフォームに入力します。

    • [名前] : 「AWS Console - MFA」と入力します
    • ユーザーとグループ: 先ほど作成した 2 つのロール グループを選びます。
      • AWS-Account1-Administrators
      • AWS-Account1-Developers
    • [許可] : [多要素認証が必要です] を選択します

  4. [ポリシーの有効化] を [オン] に設定します。

    Screenshot of the filled-out new policy form.

  5. ［作成］ を選択します ポリシーはすぐに有効になります。

  6. 条件付きアクセス ポリシーをテストするには、テスト アカウントからサインアウトし、新しいプライベート ブラウジング セッションを開いて、ロール グループ アカウントのいずれかを使用してサインインします。 MFA プロンプトが表示されます。

    Screenshot of MFA sign-in prompt.

  7. MFA の設定プロセスを完了します。 認証には、SMS を利用するのではなく、モバイル アプリを使用することをお勧めします。

    Screenshot of mobile app MFA configuration screen.

強力な認証のビジネス ニーズを満たすには、必要に応じていくつかの条件付きアクセス ポリシーを作成します。 識別と継続的なメンテナンスを容易になるように、ポリシーを作成するときに使用する名前付け規則を考慮します。 また、MFA が既に広く展開されている場合を除き、対象のユーザーのみに影響するようにポリシーの範囲を設定してください。 その他のポリシーを使用して、他のユーザー グループのニーズに対応する必要があります。

条件付きアクセスを有効にすると、PAM や Just-In-Time (JIT) プロビジョニングなどの追加のコントロールを課すことができます。 詳細については、「Microsoft Entra ID での SaaS アプリ ユーザー プロビジョニングの自動化とは」を参照してください。

Defender for Cloud Apps がある場合は、条件付きアクセスを使用して Defender for Cloud Apps セッション ポリシーを構成することができます。 詳細については、「AWS アクティビティに関する Microsoft Entra セッション ポリシーを構成する」を参照してください。

次のステップ