このシナリオ例では、メイン アプリケーションには 3 つの異なる認証要件があります。
Azure Key Vault
アプリケーションは、サードパーティのサービスを呼び出すために必要な安全に保存された API キーを取得するために、Azure Key Vaultで認証する必要があります。
サードパーティ API
アプリケーションは、API キーを取得すると、そのキーを使用して外部のサードパーティ API で認証します。
Azure Queue Storage
要求の処理後、アプリケーションは Azure Queue Storage で認証を行い、非同期処理または遅延処理のためにメッセージをエンキューする必要があります。
これらのタスクでは、アプリで 3 セットの資格情報を管理する必要があります。
Azure リソース (Key Vault とストレージ) の 2 つのセット
外部サービス用の 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 ベースの認証を使用する
Microsoft Entra IDを使用したAzure優先認証
クラウド アプリケーションが複雑にスケーリングされ、より多くのサービスと統合されるにつれて、セキュリティで保護された合理化された認証が不可欠になります。 Azureでは、Microsoft Entra IDを通じてAzure優先の ID モデルを提供し、セキュリティで保護された資格情報のない認証のために、統合された ID 管理とAzure サービスとのシームレスな統合を実現します。
シークレットを手動で管理したり、アプリケーション コードに資格情報を埋め込んだりするのではなく、セキュリティリスクが発生しやすいプラクティスMicrosoft Entra ID、アプリはマネージド ID を使用して安全に認証できます。
Microsoft Entra マネージド ID の主な利点は次のとおりです。
コードにシークレットがない
アプリケーションでは、ハードコーディングされた接続文字列、クライアント シークレット、またはキーは不要になりました。
アプリの組み込み ID
Azureは、マネージド ID をアプリに自動的に割り当てることができるため、Key Vault、ストレージ、SQL などのサービスに追加の資格情報なしで安全にアクセスできます。
環境の整合性
同じコードと ID モデルは、Azure SDKの
DefaultAzureCredentialを使用して、ローカル開発環境とAzureホスト環境の両方で機能します。
環境に特化したアイデンティティフロー
認証に Microsoft Entra ID を使用するアプリケーションは、Azure でホストされる開発環境とローカル開発環境の両方でシームレスに動作する柔軟な ID モデルを利用できます。 Azure SDKのDefaultAzureCredentialは、環境に基づいて適切な ID メソッドを自動的に選択することで、この一貫性を提供します。
Azure 環境
アプリケーションをAzureにデプロイする場合:
- アプリケーションは自動的にマネージド ID を取得します。
- Azureはトークンの発行と資格情報のライフサイクルを内部的に管理するため、シークレットを処理する必要はありません。
- アプリケーションは、ロールベースのアクセス制御 (RBAC) または Key Vault のアクセス ポリシーを使用してサービスにアクセスします。
ローカル開発環境
ローカル環境での開発中
- サービス プリンシパルは、アプリの ID として機能します。
- 開発者は、Azure CLI (
az login)、環境変数、または Visual Studio/VS Code の統合を使用して認証を行います。 - 同じアプリケーション コードは変更なしで実行され、ID ソースの変更のみが行われます。
どちらの環境でも、Azure SDK は、ID ソースを抽象化し、適切なメソッドを自動的に自動選択する DefaultAzureCredential を使用します。
セキュリティで保護された開発のベスト プラクティス
シークレットは環境変数として設定できますが (たとえば、Azure アプリ設定を使用して)、このアプローチには欠点があります。
- ローカル環境でシークレットを手動でレプリケートする必要があります。
- シークレットがソース管理に漏洩するリスクがあります。
- 環境を区別するために追加のロジックが必要になる場合があります。
代わりに、次の方法を使用します。
- Key Vault を使用して、サードパーティの API キーやその他のシークレットを格納します。
- デプロイされたアプリにマネージド ID を割り当てます。
- ローカル開発にサービス プリンシパルを使用し、同じアクセス権を割り当てます。
- コードで
DefaultAzureCredentialを使用して、認証ロジックを抽象化します。 - 資格情報の保存やログ記録は避けてください。
実際の認証フロー
実行時の認証のしくみを次に示します。
- コードによって、
DefaultAzureCredentialインスタンスが作成されます。 - この資格情報を使用して、クライアントをインスタンス化します (たとえば、
SecretClient、QueueServiceClient)。 - アプリがメソッド (
get_secret()など) を呼び出すと、クライアントは資格情報を使用して要求を認証します。 - Azure は ID を検証し、操作を実行するための正しいロールまたはポリシーがあるかどうかを確認します。
このフローにより、コードまたは構成ファイルにシークレットを埋め込むことなく、アプリが Azure サービスに安全にアクセスできるようになります。 また、認証ロジックを変更することなく、ローカル開発とクラウドデプロイをシームレスに切り替えることもできます。