注
パスワードレス接続は、複数の Azure サービスにまたがる言語に依存しない機能です。 現在のドキュメントはいくつかの言語とサービスに焦点を当てていますが、現在、他の言語とサービスに関する追加のドキュメントを作成中です。
この記事では、パスワードに関するセキュリティ上の課題について説明し、Azure サービスのパスワードレス接続について紹介します。
パスワードとシークレットに関するセキュリティの課題
パスワードと秘密鍵を処理するときは注意が必要です。 安全でない場所に配置しないでください。 多くのアプリは、ユーザー名、パスワード、アクセス キーを使用して、バックエンド データベース、キャッシュ、メッセージング、イベント サービスに接続します。 公開された場合、不適切なアクターはこれらの資格情報を使用して、今後のキャンペーン用に作成した販売カタログや、プライベートである必要がある顧客データなどの機密情報への不正アクセスを取得できます。
アプリケーション自体にパスワードを埋め込むと、コード リポジトリを介した検出など、さまざまな理由で大きなセキュリティ リスクが発生します。 多くの開発者は、アプリケーションが異なる環境からパスワードを読み込むことができるように、環境変数を使用してこのようなパスワードを外部化します。 ただし、この方法では、リスクをコード自体から実行環境に移行するだけです。 環境にアクセスできるユーザーは誰でもパスワードを盗むことができるため、データ流出のリスクが高まります。
次のコード例では、ストレージ アカウント キーを使用してAzure Storageに接続する方法を示します。 多くの開発者がこのソリューションに引き寄せられるのは、理想的なソリューションではないにもかかわらず、過去に使用したオプションに馴染みがあると感じるからです。 アプリケーションで現在アクセス キーを使用している場合は、パスワードレス接続への移行を検討してください。
// Connection using secret access keys
BlobServiceClient blobServiceClient = new(
new Uri("https://<storage-account-name>.blob.core.windows.net"),
new StorageSharedKeyCredential("<storage-account-name>", "<your-access-key>"));
開発者は、これらの種類のキーやシークレットをセキュリティで保護されていない場所に公開しないように注意する必要があります。 多くの企業では、開発者、オペレーター、その他のユーザーにパスワードを公開せずに Azure サービスに接続するための厳格なセキュリティ要件があります。 多くの場合、ボールトを使用してパスワードを保存したり、アプリケーションにロードしたりします。また、パスワードのローテーション要件や手順を追加することで、リスクをさらに軽減します。 このアプローチでは、運用の複雑さが増し、場合によってはアプリケーション接続の停止につながることがあります。
パスワードレス接続とゼロトラスト
アプリでパスワードレス接続を使用して、パスワードをローテーションすることなく Azure ベースのサービスに接続できるようになりました。 場合によっては、設定だけが必要で、新しいコードは必要ありません。 ゼロトラストは、「決して信頼せず、常に検証し、クレデンシャルフリー」の原則を採用しています。 この原則は、ID を確認した後、バックエンド サービスへのアクセスを許可する前に、マシンまたはユーザーを信頼することによってすべての通信をセキュリティで保護することを意味します。
セキュリティで保護されたパスワードレス接続に推奨される認証オプションは、マネージド ID と Azure ロールベースのアクセス制御 (RBAC) を組み合わせて使用することです。 この方法を使用すると、マネージド ID の多くの異なるシークレットを手動で追跡および管理する必要はありません。これらのタスクAzure内部で安全に処理されるためです。
Service Connector を使用して、Azure サービスへのパスワードレス接続を構成することも、手動で構成することもできます。 Service Connector を使用すると、Azure App ServiceやAzure Container Appsなどのサービスをホストするアプリでマネージド ID を使用できます。 Service Connector では、マネージド ID と Azure RBAC を使用してパスワードなしの接続を使用してバックエンド サービスを構成し、必要な接続情報でアプリケーションをハイドレートします。
パスワードレス接続用に構成されたアプリケーションの実行環境を検査すると、完全な接続文字列を確認できます。 接続文字列には、データベース サーバーのアドレス、データベース名、Azure 認証プラグインに認証を委任する命令などが含まれますが、パスワードやシークレットは含まれていません。
次のビデオでは、Java アプリケーションを例に、アプリから Azure サービスへのパスワードレス接続を示しています。 他の言語についても同様の対応が近日中に開始されます。
DefaultAzureCredential の概要
Azure ID クライアント ライブラリのDefaultAzureCredentialを使用して、Microsoft Entra IDとロール ベースのアクセス制御 (RBAC) を介してAzure サービスへのパスワードレス接続を実装できます。
Von Bedeutung
一部の言語では、コードに DefaultAzureCredential を明示的に実装する必要があります。また、基になるプラグインまたはドライバーを介して内部的に DefaultAzureCredential を使用する言語もあります。
DefaultAzureCredential では、複数の認証方法がサポートされ、実行時に使用する方法が自動的に決定されます。 このアプローチを採用すると、環境固有のコードを実装することなく、異なる環境 (ローカル開発環境と運用環境) で異なる認証方法をアプリに使用できます。
DefaultAzureCredentialが資格情報を検索する順序と場所は、言語によって異なります。
たとえば、.NETをローカルで操作する場合、DefaultAzureCredentialは通常、Visual Studio、Azure CLI、またはAzure PowerShellにサインインするために使用したアカウントを使用して認証されます。 アプリをAzureにデプロイすると、DefaultAzureCredentialは関連付けられているホスティング サービスのマネージド ID (Azure App Service など) を自動的に検出して使用します。 この遷移に対してコードを変更する必要はありません。
注
マネージド ID は、アプリまたはサービスを表すセキュリティ ID を提供します。 Azure プラットフォームは ID を管理するため、シークレットをプロビジョニングまたはローテーションする必要はありません。 詳細については、 概要 ドキュメントを参照してください。
次のコード例は、パスワードレス接続を使用してService Busに接続する方法を示しています。 他のドキュメントでは、特定のサービスについてこのセットアップに移行する方法について詳しく説明します。 .NET アプリは、 DefaultAzureCredential のインスタンスをサービス クライアント クラスのコンストラクタに渡すことができます。
DefaultAzureCredential は、その環境で使用可能な資格情報を自動的に検出します。
ServiceBusClient serviceBusClient = new(
new Uri("https://<your-service-bus-namespace>.servicebus.windows.net"),
new DefaultAzureCredential());
こちらも参照ください
パスワードレス接続の詳細については、開発者ガイドの「 複数の Azure アプリとサービス間のパスワードレス接続の構成」を参照してください。