ユーザーがいない場合にアプリケーション ID 資格情報を提供する
開発者として非ユーザー アプリケーションを構築する場合、ユーザー名とパスワード、または多要素認証 (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 でサービスを構築する場合は、Azure リソース用マネージド ID がベスト プラクティスです。
次のステップ
- 「シングルテナントとマルチテナントのアプリでサポートされる ID とアカウントの種類」では、アプリで Microsoft Entra テナント、任意の Microsoft Entra テナントのユーザー、または個人の Microsoft アカウントを持つユーザーのみを許可するかどうかを選択する方法について説明します。
- 「アプリケーションのアクセス許可戦略を開発する」は、資格情報管理に対するアプリケーションのアクセス許可のアプローチを決定するのに役立ちます。
- 「ユーザーがいない場合にアプリケーション ID 資格情報を提供する」では、Azure リソース用マネージド ID が Azure 上のサービス (非ユーザー アプリケーション) に対するクライアント資格情報のベスト プラクティスである理由について説明します。
- 承認のベスト プラクティスは、アプリケーションに最適な承認、アクセス許可、および同意モデルを実装するのに役立ちます。
- 「ゼロ トラスト ID およびアクセス管理の開発のベスト プラクティス」をアプリケーション開発ライフサイクルで使用して、セキュリティで保護されたアプリケーションを作成します。
- 「ID に対するゼロ トラストアプローチを使用したアプリの構築」では、アクセス許可とアクセスのベスト プラクティスの概要について説明しています。