Microsoft Entra ID は、Azure Key Vault と共に使用される場合、アクセス キーまたは資格情報を必要とする Azure サービスとサードパーティプラットフォームの両方に対してアプリケーションを認証するための堅牢で安全なアプローチを提供します。 この組み合わせにより、マネージド ID、ロールベースのアクセス制御 (RBAC)、Key Vault による一元化されたシークレット管理に依存する代わりに、アプリケーション コードでシークレットをハードコーディングする必要がなくなります。 このアプローチにより、ID 管理が合理化され、クラウド環境でのセキュリティ体制が強化されます。
このチュートリアルでは、GitHub リポジトリで提供されている実際の例 ( github.com/Azure-Samples/python-integrated-authentication) を使用して、これらの認証メカニズムについて説明します。
このサンプルでは、Python アプリケーションで次の操作を行う方法を示します。
DefaultAzureCredential を使用して Azure で認証する
資格情報を格納せずに Azure Key Vault シークレットにアクセスする
Azure Storage、Cosmos DB などの他の Azure サービスと安全に通信する
この記事は、Azure Python SDK azure-identity ライブラリを使用して、Microsoft Entra ID、Azure Key Vault、および Azure Queue Storage を使用して Python アプリを認証する方法の詳細なチュートリアルを提供するシリーズの一部です。
パート 1: 背景
多くの Azure サービスはロールベースのアクセス制御 (RBAC) のみに依存していますが、シークレットまたはキーを介したアクセスが必要なサービスもあります。 このようなサービスには、Azure Storage、データベース、Azure AI サービス、Key Vault、Event Hubs が含まれます。
これらのサービスと対話するクラウド アプリケーションを構築する場合、開発者は Azure portal、CLI、または PowerShell を使用して、サービス固有のアクセス キーを生成および構成できます。 これらのキーは、承認されていないアクセスを防ぐために、特定のアクセス ポリシーに関連付けられています。 ただし、このモデルでは、アプリケーションでキーを明示的に管理し、サービスごとに個別に認証する必要があります。これは、面倒でエラーが発生しやすいプロセスです。
シークレットをコードに直接埋め込むか、開発者のマシンに格納すると、次の場合に公開されるリスクがあります。
- ソース管理
- 安全でないローカル環境
- 意図しないログまたは構成のエクスポート
Azure には、セキュリティを向上させ、認証を簡素化するための 2 つの主要なサービスが用意されています。
- Azure Key Vault Azure Key Vault は、アクセス キー、接続文字列、証明書など、シークレット用のセキュリティで保護されたクラウドベースのストアを提供します。 実行時にのみ Key Vault からシークレットを取得することで、アプリケーションはソース コードまたは構成ファイル内の機密データを公開しないようにします。
- Microsoft Entra マネージド ID を使用すると、アプリケーションは Microsoft Entra ID で 1 回認証できます。 そこから、資格情報を直接管理することなく、Key Vault を含む他の Azure サービスにアクセスできます。
このアプローチでは、次の機能が提供されます。
- 資格情報のないコード (ソース管理にシークレットなし)
- Azure サービスとのシームレスな統合
- 環境の一貫性: 同じコードが、最小限の構成でローカルおよびクラウドで実行されます
このチュートリアルでは、Microsoft Entra マネージド ID と Key Vault を同じアプリで一緒に使用する方法について説明します。 Microsoft Entra ID と Key Vault を組み合わせて使用することで、アプリは個々の Azure サービスで自身を認証する必要がなく、サード パーティのサービスに必要なキーに簡単かつ安全にアクセスできます。
Von Bedeutung
この記事では、一般的な一般的な用語 "キー" を使用して、REST API のアクセス キーなど、Azure Key Vault に "シークレット" として格納されているものを参照します。 この使用方法は、Key Vault のシークレットとは別の機能である Key Vault による暗号化キーの管理と混同しないでください。
クラウド アプリのシナリオの例
Azure の認証プロセスをより深く理解するには、Flask Web アプリケーションが Azure App Service にデプロイされるというシナリオを検討してください。 HTTP 要求に応答して JSON データを返す、認証されていないパブリック API エンドポイントを公開します。
応答を生成するために、API はアクセス キーを必要とするサードパーティの API を呼び出します。 このキーは、コードまたは構成ファイルに格納する代わりに、Microsoft Entra マネージド ID を使用して、実行時に Azure Key Vault から安全に取得されます。
クライアントに応答を返す前に、アプリは非同期処理のために Azure Storage キューにメッセージを書き込みます。 メッセージはタスク、ログ、またはシグナルを表す場合がありますが、ダウンストリーム処理はこのシナリオの焦点ではありません。
注
パブリック API エンドポイントは通常、独自のアクセス キーまたは認証メカニズムによって保護されますが、このチュートリアルでは、エンドポイントが開いて認証されていないことを前提としています。
この簡素化により、外部クライアントに関連する認証上の問題から、アプリの内部認証要件 (Azure Key Vault や Azure Storage へのアクセスなど) を分離できます。
このシナリオはアプリの動作のみに焦点を当てており、エンドポイントによる外部呼び出し元の認証のデモンストレーションや関与はしません。