このシナリオ例では、メイン アプリケーションには 3 つの異なる認証要件があります。
Azure Key Vault
サードパーティのサービスを呼び出すために必要な安全に保存された API キーを取得するには、アプリケーションが Azure Key Vault で認証される必要があります。
サードパーティ API
API キーが取得されると、アプリケーションはそれを使用して外部のサードパーティ API で認証されます。
Azure Queue Storage（アジュール キュー ストレージ）
要求の処理後、アプリケーションは Azure Queue Storage で認証を行い、非同期処理または遅延処理のためにメッセージをエンキューする必要があります。
これらのタスクでは、アプリで 3 セットの資格情報を管理する必要があります。
Azure リソース用の 2 つ (Key Vault とストレージ)
外部サービス用の 1 つ (サード パーティ製 API)
主要な認証の課題
セキュリティで保護されたクラウド アプリケーションを構築するには、特に複数のサービスが関係する場合に、資格情報を慎重に処理する必要があります。 このシナリオ例では、いくつかの重要な課題が示されています。
Key Vault への循環依存関係
アプリケーションでは、Azure Key Vault を使用して、サードパーティの API キーや Azure Storage 資格情報などのシークレットを安全に格納します。 ただし、これらのシークレットを取得するには、アプリが最初に Key Vault で認証を行う必要があります。 これにより、循環的な問題が発生します。アプリには Key Vault にアクセスするための資格情報が必要ですが、それらの資格情報自体を安全に格納する必要があります。 セキュリティで保護されたソリューションがないと、開発環境で資格情報がハードコーディングされたり、セキュリティで保護されていない構成が発生したりする可能性があります。
サード パーティ製 API キーの安全な処理
Key Vault から API キーを取得した後、アプリケーションはそれを使用して外部のサードパーティ サービスを呼び出す必要があります。 このキーは細心の注意を払って処理する必要があります。
- ソース コードまたは構成ファイルでハードコーディングしない
- stdout、stderr、またはアプリケーション ログに記録されることはない。
- メモリ内でのみ保持され、実行時に使用直前にアクセスされる
- 要求が完了した後、すぐに破棄される
これらのプラクティスに従わないと、資格情報の漏えいや不正使用のリスクが高まります。
Azure Queue Storage 資格情報のセキュリティ保護
Azure Queue Storage にメッセージを書き込むには、通常、アプリには接続文字列または共有アクセス トークンが必要です。 これらの資格情報:
- Key Vault などのセキュリティで保護された場所に格納する必要があります
- ログ、スタック トレース、または開発者ツールには表示しないでください
- セキュリティで保護されたランタイム メカニズムを介してのみアクセスする必要がある
- マネージド ID を使用する場合は、適切な RBAC 構成を要求する
環境の柔軟性
アプリは、同じコードベースと最小限の条件付きロジックを使用して、ローカル開発環境とクラウド運用環境の両方で確実に実行する必要があります。
これは、以下のようなことを意味します。
- コードに環境固有のシークレットは埋め込まれていない
- 資格情報またはロジック パスを手動で切り替える必要はありません
- 複数の環境で ID ベースの認証を一貫して使用する
Azure-First Microsoft Entra ID を使用した認証
クラウド アプリケーションが複雑にスケーリングされ、より多くのサービスと統合されるにつれて、セキュリティで保護された合理化された認証が不可欠になります。 Azure では、Microsoft Entra ID を使用した "Azure 優先" ID モデルが提供され、統合された ID 管理と Azure サービスとのシームレスな統合が可能になり、資格情報のない安全な認証が可能になります。
シークレットを手動で管理したり、アプリケーション コードに資格情報を埋め込んだりするのではなく、セキュリティ上のリスクが生じやすいプラクティスです。Microsoft Entra ID を使用すると、アプリはマネージド ID を使用して安全に認証できます。
Microsoft Entra マネージド ID の主な利点は次のとおりです。
コードにシークレットがない
アプリケーションでは、ハードコーディングされた接続文字列、クライアント シークレット、またはキーは不要になりました。
アプリの組み込み ID
Azure では、マネージド ID をアプリに自動的に割り当てることで、Key Vault、Storage、SQL などのサービスへのセキュリティで保護されたアクセスを追加の資格情報なしで許可できます。
環境の整合性
同じコードと ID モデルは、Azure SDK の DefaultAzureCredential を使用して、ローカル開発環境と Azure ホスト環境の両方で機能します。
環境に特化したアイデンティティフロー
認証に Microsoft Entra ID を使用するアプリケーションは、Azure でホストされる開発環境とローカル開発環境の両方でシームレスに動作する柔軟な ID モデルを利用できます。 この一貫性は、環境に基づいて適切な ID メソッドを自動的に選択する Azure SDK の DefaultAzureCredentialを使用して実現されます。
Azure 環境
アプリケーションを Azure にデプロイする場合:
- マネージド ID は、アプリケーションに自動的に割り当てられます。
- Azure はトークンの発行と資格情報のライフサイクルを内部的に処理します。手動のシークレットは必要ありません。
- アプリケーションは、Role-Based アクセス制御 (RBAC) または Key Vault アクセス ポリシーを使用してサービスにアクセスします
ローカル開発環境
ローカル環境での開発中
- サービス プリンシパルは、アプリの ID として機能します。
- 開発者は、Azure CLI (az login)、環境変数、または Visual Studio/VS Code 統合を使用して認証を行います。
- 同じアプリケーション コードは変更なしで実行され、ID ソースの変更のみが行われます。
どちらの環境でも、Azure SDK は DefaultAzureCredentialを使用します。この場合、ID ソースが抽象化され、適切な方法が自動的に選択されます。
セキュリティで保護された開発のベスト プラクティス
シークレットを環境変数として設定することは可能ですが (たとえば、Azure App Settings を使用して)、このアプローチには欠点があります。
- ローカル環境でシークレットを手動でレプリケートする必要があります。
- シークレットがソース管理に漏洩するリスクがあります。
- 環境を区別するために追加のロジックが必要になる場合があります。
代わりに、次の方法をお勧めします。
- Key Vault を使用して、サードパーティの API キーやその他のシークレットを格納します。
- デプロイされたアプリにマネージド ID を割り当てます。
- ローカル開発にサービス プリンシパルを使用し、同じアクセス権を割り当てます。
- コードで
DefaultAzureCredentialを使用して、認証ロジックを抽象化します。 - 資格情報の保存やログ記録は避けてください。
実際の認証フロー
実行時の認証のしくみを次に示します。
- コードによって、
DefaultAzureCredentialインスタンスが作成されます。 - この資格情報を使用して、クライアント (SecretClient、QueueServiceClient など) をインスタンス化します。
- アプリがメソッド (
get_secret()など) を呼び出すと、クライアントは資格情報を使用して要求を認証します。 - Azure は ID を検証し、操作を実行するための正しいロールまたはポリシーがあるかどうかを確認します。
このフローにより、コードまたは構成ファイルにシークレットを埋め込むことなく、アプリが Azure サービスに安全にアクセスできるようになります。 また、認証ロジックを変更することなく、ローカル開発とクラウドデプロイをシームレスに切り替えることもできます。