次の方法で共有

自動化シナリオにおける Azure CLI での多要素認証の影響

この記事では、Microsoft Entra ユーザー ID を使用する自動化タスクに多要素認証 (MFA) がどのように影響するかについて説明し、中断されない自動化の代替アプローチに関するガイダンスを提供します。

Von Bedeutung

自動化に Microsoft Entra ユーザー ID を使用している場合は、アクションが必要です。 MFA の要件により、自動化シナリオで認証に Microsoft Entra ユーザー ID を使用できなくなります。 組織は、非対話型オートメーションのユース ケースをサポートするマネージド ID やサービス プリンシパルなど、自動化用に設計された認証方法に切り替える必要があります。

自動化での MFA を使用したユーザー ID の制限事項

注

自動化でユーザー ID を使用する場合は、対話型認証が 必要です。というエラー メッセージが表示されることがあります。

  • 対話型認証: Microsoft Entra ユーザー ID を使用すると、対話型サインイン中に MFA がトリガーされます。 ユーザー ID に依存する自動化スクリプトの場合、MFA は追加の検証手順を必要とするため、プロセスを中断します。 たとえば、自動化できない認証アプリ、電話呼び出しなどです。 この検証により、マネージド ID やサービス プリンシパルなど、非対話型の方法で認証が処理されない限り、自動化が実行されなくなります。

  • スクリプト化されたログイン エラー: Azure CLI スクリプトを無人で実行するなどの自動化シナリオでは、MFA が有効なユーザー ID によって、認証しようとするとスクリプトが失敗します。 MFA はユーザーの操作を必要とするため、非対話型スクリプトと互換性がありません。 つまり、非対話型認証を使用するマネージド ID またはサービス プリンシパルに切り替える必要があります。

  • セキュリティに関する考慮事項: MFA によってセキュリティの層が追加されますが、自動化の柔軟性が制限される可能性があります。特に、手動による介入なしで自動化を実行する必要がある運用環境では、自動化の柔軟性が制限されます。 自動化のために設計され、MFA を必要としないマネージド ID、サービス プリンシパル、またはフェデレーション ID への移行は、このような環境ではより実用的で安全です。

更新が必要なシナリオ

次の一覧では、お客様が Azure CLI を使用して自動化するために Microsoft Entra ユーザー ID を使用するシナリオの例を示します。 この一覧は、すべてのシナリオを網羅しているわけではありません。

Warnung

Microsoft Entra ユーザー ID を使用する自動化シナリオでは、更新が必要です。

  • 個人用または特定のアクセス許可: 個人のロールまたは特定の Microsoft Entra ID 属性に関連付けられたアクションなど、ユーザー固有のアクセス許可を必要とするオートメーション タスク。

  • OAuth 2.0 ROPC フロー: OAuth 2.0 リソース所有者パスワード資格情報 (ROPC) トークン付与フローは MFA と互換性がありません。 MFA を非対話型フローで完了できないため、認証に ROPC を使用する自動化シナリオは、MFA が必要な場合に失敗します。

  • Azure外部のリソースへのアクセス: Microsoft 365 リソースへのアクセスを必要とする自動化シナリオ。 たとえば、個々のユーザーの Microsoft アカウントに関連付けられている SharePoint、Exchange、その他のクラウド サービスなどです。

  • Active Directory から Microsoft Entra ID に同期されたサービス アカウント: Active Directory (AD) から Microsoft Entra ID に同期されたサービス アカウントを使用している組織。 これらのアカウントも MFA 要件の対象となり、他のユーザー ID と同じ問題を引き起こすことに注意することが重要です。

  • 監査またはコンプライアンスののユーザー コンテキスト: コンプライアンス上の理由から、個々のユーザー レベルでアクションを監査可能にする必要がある場合。

  • 小規模または低リスクの自動化のシンプルな構成: 小規模または低リスクの自動化タスクに使用します。 たとえば、いくつかのリソースを管理するスクリプトなどです。

  • 非運用環境でのユーザー主導の自動化: 自動化が個人または非運用環境を対象としている場合、個々のユーザーがタスクを担当します。

  • ユーザー自身の Azure サブスクリプション内での Automation: ユーザーが既に十分なアクセス許可を持っている Azure サブスクリプション内でタスクを自動化する必要がある場合。

Microsoft Entra ユーザー ID に対する MFA の強制が必須であるため、自動化シナリオではマネージド ID またはサービス プリンシパルに切り替える必要があります。

開始する方法

Azure CLI スクリプトを Microsoft Entra ID ユーザー アカウントとパスワードを使用して移行するには、次の手順に従います。

  1. 最適なワークロードアイデンティティを決定します。

    • サービス プリンシパル
    • マネージド ID
    • フェデレーテッドアイデンティティ

  2. 新しいワークロード ID を作成するために必要なアクセス許可を取得するか、Azure 管理者に問い合わせてください。

  3. ワークロード ID を作成します。

  4. 新しい ID にロールを割り当てます。 Azure ロールの割り当ての詳細については、「Azure ロールを割り当てる手順」を参照してください。 Azure CLI を使用してロールを割り当てるには、Azure CLI を使用して Azure ロールを割り当てるを参照してください。

  5. Azure CLI スクリプトを更新して、サービス プリンシパルまたはマネージド ID でサインインします。

サービス プリンシパルの主要概念

  • 複数の Azure リソースにアクセスできる非人間 ID。 サービス プリンシパルは多くの Azure リソースで使用され、1 つの Azure リソースに関連付けられません。
  • 必要に応じて、サービス プリンシパルのプロパティと資格情報を変更できます。
  • 異なるサブスクリプション間で複数の Azure リソースにアクセスする必要があるアプリケーションに最適です。
  • マネージド ID よりも柔軟性が高いと見なされますが、安全性は低いと見なされます。
  • Azure テナントまたは Microsoft Entra ID ディレクトリでは、"アプリケーション オブジェクト" と呼ばれることがよくあります。

サービス プリンシパルの詳細については、以下を参照してください。

Azure CLI とサービス プリンシパルを使用して Azure にサインインする方法については、Azure CLI を使用してサービス プリンシパルで Azure にサインインする を参照してください。

マネージド ID キーの概念

  • 特定の Azure リソースに関連付けられ、その 1 つのリソースが他の Azure アプリケーションにアクセスできるようにします。
  • あなたには資格情報が表示されません。 Azure では、シークレット、資格情報、証明書、およびキーが処理されます。
  • 1 つのサブスクリプション内の他の Azure リソースにアクセスする必要がある Azure リソースに最適です。
  • サービス プリンシパルよりも柔軟性が低いと見なされますが、セキュリティが強化されています。
  • マネージド ID には、次の 2 種類があります。
    • システム割り当て: この種類は、2 つの Azure リソース間の 1 対 1 のアクセス リンクです。
    • ユーザー割り当て: この種類には、マネージド ID が複数の Azure リソースにアクセスできる 1 対多のリレーションシップがあります。

マネージド ID の詳細については、Azure リソース用マネージド ID に関する記事を参照してください。

Azure CLI とマネージド ID で Azure にサインインする方法については、Azure CLI を使用してマネージド ID で Azure にサインインする を参照してください。

フェデレーション ID キーの概念

  • フェデレーション ID を使用すると、サービス プリンシパル (アプリの登録) とユーザー割り当てマネージド ID が、GitHub や Google などの外部 ID プロバイダー (IdP) からのトークンを信頼できます。
  • 信頼関係が作成されると、外部ソフトウェア ワークロードは、外部 IdP の信頼されたトークンを Microsoft ID プラットフォームからのアクセス トークンと交換します。
  • ソフトウェア ワークロードでは、そのアクセス トークンを使用して、ワークロードにアクセス権が付与されている Microsoft Entra で保護されたリソースにアクセスします。
  • フェデレーション ID は、多くの場合、次のシナリオに最適なソリューションです。
    • 任意の Kubernetes クラスターで実行されているワークロード
    • GitHub のアクション
    • アプリケーション ID を使用して Azure コンピューティング プラットフォームで実行されているワークロード
    • Google Cloud
    • アマゾン ウェブ サービス (AWS)
    • Azure の外部のコンピューティング プラットフォームで実行されているワークロード

フェデレーション ID の詳細については、以下を参照してください。

トラブルシューティング

ROPC エラー: 管理者によって行われた構成の変更が原因で

パスワードを使用して Azure にサインインしようとすると、これは ROPC フロー (リソース所有者パスワード資格情報) と呼ばれます。 この認証方法は、MFA ではサポートされていません。 次に例を示します。

az login --username $username –password $password

ユーザーに MFA が必要な場合、上記のコマンドは失敗し、次のエラー メッセージが表示されます。

AADSTS50076: Due to a configuration change made by your administrator, or because you moved to a new ___location, you must use multi-factor authentication to access ‘’. Trace ID Correlation ID: Timestamp:

解決策: MFAと互換性のある認証方法に切り替えます。

テナント間の警告: テナントに対する認証が失敗しました

複数のテナントにアクセスでき、そのうちの 1 つに MFA が必要な場合、Azure CLI で次のような警告メッセージが表示されることがあります。

Authentication failed against tenant 00000000-0000-0000-0000-000000000000 'Tenant Name': AADSTSXXXXX: Due to a configuration change made by your administrator, or because you moved to a new ___location, you must use multi-factor authentication to access '00000000-0000-0000-0000-000000000000'. Trace ID: 00000000-0000-0000-0000-000000000000 Correlation ID: 00000000-0000-0000-0000-000000000000 Timestamp: yyyy-mm-dd hh:mm:ss.

ログイン フェーズ中に、Azure CLI は、最初に見つかったテナントでサインインを試みます。 私たちはこの問題の解決に向けて取り組んでいますが、パラメーター --tenant で使用するテナントを指定してください。

az login --tenant 00000000-0000-0000-0000-000000000000

多要素認証の詳細

Microsoft Entra ID ドキュメント サイトでは、MFA について詳しく説明しています。

こちらも参照ください