注
パスワードレス接続は、複数の 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 Spring Apps、Azure App Service、Azure Container Apps などのアプリ ホスティング サービスでマネージド ID を使用できます。 また、Service Connector は、マネージド ID と Azure RBAC を使用したパスワードレス接続でバックエンド サービスを構成し、必要な接続情報でアプリケーションをハイドレートします。
パスワードレス接続用に構成されたアプリケーションの実行環境を検査すると、完全な接続文字列を確認できます。 接続文字列には、データベース サーバーのアドレス、データベース名、Azure 認証プラグインに認証を委任する命令などが含まれますが、パスワードやシークレットは含まれていません。
次のビデオでは、Java アプリケーションを例に、アプリから Azure サービスへのパスワードレス接続を示しています。 他の言語についても同様の対応が近日中に開始されます。
DefaultAzureCredential の概要
Microsoft Entra ID とロールベースのアクセス制御 (RBAC) を使用した Azure サービスへのパスワードレス接続は、Azure Identity クライアント ライブラリの DefaultAzureCredential を使用して実装できます。
Von Bedeutung
言語によっては、コード内で DefaultAzureCredential を明示的に実装する必要があります。一方、下層のプラグインまたはドライバーを介して内部的に DefaultAzureCredential が利用される言語もあります。
DefaultAzureCredential は複数の認証方法をサポートしており、どの方法が使用されるかは実行時に決定されます。 このアプローチを採用すると、環境固有のコードを実装することなく、異なる環境 (ローカル開発環境と運用環境) で異なる認証方法をアプリに使用できます。
DefaultAzureCredential が資格情報を検索する順序と場所は、言語によって異なります。
たとえば、ローカルで .NET を使用して作業している場合、DefaultAzureCredential による認証には、通常、開発者が Visual Studio、Azure CLI、または Azure PowerShell へのサインインに使用したアカウントが使用されます。 アプリが Azure にデプロイされると、DefaultAzureCredential によって、関連するホスティング サービス (Azure App Service など) のマネージド ID が自動的に検出され、使用されます。 この移行のためにコードを変更する必要はありません。
注
マネージド ID は、アプリまたはサービスを表すセキュリティ ID を提供します。 ID は Azure プラットフォームによって管理され、シークレットのプロビジョニングやローテーションを行う必要はありません。 マネージド ID の詳細については、概要ドキュメントを参照してください。
以下のコード例は、パスワードレス接続を使用して Service Bus に接続する方法を示しています。 他のドキュメントでは、特定のサービスについてこのセットアップに移行する方法について詳しく説明します。 .NET アプリは、 DefaultAzureCredential のインスタンスをサービス クライアント クラスのコンストラクタに渡すことができます。 その環境で利用できる資格情報が DefaultAzureCredential によって自動的に検出されます。
ServiceBusClient serviceBusClient = new(
new Uri("https://<your-service-bus-namespace>.blob.core.windows.net"),
new DefaultAzureCredential());
こちらも参照ください
パスワードレス接続の詳細については、開発者ガイドの「 複数の Azure アプリとサービス間のパスワードレス接続の構成」を参照してください。