開発者がユーザー以外のアプリケーションをビルドする場合、ユーザー名とパスワードまたは多要素認証 (MFA) の入力を求めることができるユーザーはいません。 アプリケーションの ID を単独で指定する必要があります。 この記事では、Azure 上のサービス (非ユーザー アプリケーション) に最適なゼロ トラスト クライアント資格情報プラクティスが Azure リソースのマネージド ID である理由について説明します。
サービス アカウントに関する問題
サービス アカウントの使用 (サービスのユーザー アカウントの使用) は、適切なソリューションではありません。 Microsoft Entra ID には、サービス アカウントの概念はありません。 管理者がサービスのユーザー アカウントを作成し、パスワードを開発者と共有すると、セキュリティで保護されません。 パスワードレスにしたり、MFA を使用したりすることはできません。 サービス アカウントとしてユーザー アカウントを使用する代わりに、次のいずれかのクライアント資格情報オプションを使用することをお勧めします。
クライアント資格情報オプション
アプリケーションを識別できるクライアント資格情報には、4 種類があります。
- 秘密鍵
- 証書
- Azure リソースのマネージド ID
- フェデレーション資格情報
秘密鍵または証明書
シークレット キーは、高度なシークレット管理インフラストラクチャ ( Azure Key Vault など) で許容されます。 ただし、IT 担当者が秘密鍵を生成し、それを開発者に電子メールで送信するシナリオでは、秘密鍵を適切に保護することはできません。
証明書ベースのクライアント資格情報は、秘密鍵よりも安全です。 証明書はシークレット自体ではないので、より適切に管理できます。 シークレットは転送の一部ではありません。 秘密鍵を使用すると、クライアントは秘密鍵の実際の値を Microsoft Entra ID に送信します。 証明書を使用する場合、証明書の秘密キーがデバイスから離れることはありません。 誰かが転送を傍受、デコード、および暗号化解除した場合でも、傍受側には秘密キーがないため、シークレットは安全です。
ベスト プラクティス: Azure リソースにマネージド ID を使用する
Azure でサービス (非ユーザー アプリケーション) を開発する場合、Azure リソースのマネージド ID は、Microsoft Entra ID で自動的に管理される ID を提供します。 アプリは、資格情報を管理することなく、Microsoft Entra 認証をサポートする任意のサービスに対して認証できます。 シークレットを管理する必要はありません。 それらを失ったり、誤って処理したりする可能性に対処する必要はありません。 悪意のあるアクターは、ネットワークを介して移動しないシークレットを傍受できません。 Azure リソースのマネージド ID は、Azure でサービスを構築する際のベスト プラクティスです。
次のステップ
- シングルテナント アプリとマルチテナント アプリでサポートされている ID とアカウントの種類 では、Microsoft Entra テナントのユーザー、Microsoft Entra テナントのユーザー、または個人用 Microsoft アカウントを持つユーザーのみをアプリで許可するかどうかを選択する方法について説明します。
- 「アプリケーションのアクセス許可戦略の策定」は、資格情報管理に対するアプリケーションのアクセス許可のアプローチを決定するのに役立ちます。
- Azure リソースのマネージド ID が Azure 上のサービス (非ユーザー アプリケーション) に最適なクライアント資格情報プラクティスである理由を説明するユーザーがいない場合は、アプリケーション ID 資格情報を指定します。
- 承認のベスト プラクティスは 、アプリケーションに最適な承認、アクセス許可、および同意モデルを実装するのに役立ちます。
- 「ゼロ トラスト ID およびアクセス管理の開発のベスト プラクティス」をアプリケーション開発ライフサイクルで使用して、セキュリティで保護されたアプリケーションを作成します。
- ID に対するゼロ トラスト アプローチを使用してアプリを構築すると 、アクセス許可とアクセスのベスト プラクティスの概要が提供されます。