パスワードとセキュリティ キーは何十年もの間、デジタル セキュリティの基盤でしたが、最新の脅威に対応することはできなくなりました。 ゼロ トラスト モデルに合わせたシークレットレス認証は、アクセス制御とユーザー検証を資格情報なしのアプローチに移行します。 シークレットレス認証では、パスワード、証明書、シークレット、セキュリティ キーなどの従来の共有資格情報に依存することなく、クラウドでセキュリティで保護されたアプリケーションを設計する必要があります。 シークレットレス認証には、次の利点があります。
- 資格情報のリスクの軽減: パスワードを排除することで、シークレットレス認証によって、資格情報の盗難、フィッシング攻撃、ブルート フォース攻撃に関連するリスクが軽減されます。 このアプローチでは、生体認証、デジタル証明書、ハードウェア トークンなどの検証可能な ID 要素を使用します。
- アクセス制御の合理化: 共有シークレットではなく、真の ID を検証するメカニズムに依存することで、セキュリティが強化され、ユーザー エクスペリエンスが合理化されます。 これは、真の ID に基づいてすべてのアクセス要求を検証することで、ゼロ トラストの原則と一致します。
- エンド ユーザー エクスペリエンスの向上: ユーザーは、よりシームレスで安全な認証プロセスを利用できます。これにより、パスワードリセットの必要性が軽減され、全体的なユーザー満足度が向上します。
この記事では、Azure でのシークレットレス認証とその利点、およびクライアント アプリケーション、Azure サービス間通信、外部ワークロードなど、さまざまなシナリオにわたってそれを実装する方法について説明します。
パスワードとシークレットのセキュリティの課題
パスワードやその他のシークレットは慎重に使用する必要があり、開発者は安全でない場所にパスワードを配置しないでください。 多くのアプリは、ユーザー名、パスワード、アクセス キーを使用して、バックエンド データベース、キャッシュ、メッセージング、イベント サービスに接続します。 公開された場合、これらの資格情報を使用して、今後のキャンペーン用に作成した販売カタログや、非公開にする必要がある顧客データなどの機密情報への不正アクセスを取得できます。
アプリケーション自体にパスワードを埋め込むと、コード リポジトリを介した検出など、さまざまな理由で大きなセキュリティ リスクが発生します。 多くの開発者は、アプリケーションが異なる環境からパスワードを読み込むことができるように、環境変数を使用してこのようなパスワードを外部化します。 ただし、これにより、リスクがコード自体から実行環境に移行されるだけです。 環境にアクセスできるユーザーは誰でもパスワードを盗むことができるため、データ流出のリスクが高まります。
キーのセキュリティの課題
Azure アプリケーション開発で暗号化キーを使用すると、セキュリティと運用効率の両方を複雑にする可能性のあるいくつかの課題が発生します。 主な問題の 1 つは、キー管理の複雑さです。これには、さまざまなサービスや環境にキーをローテーション、配布、安全に格納する面倒なタスクが含まれます。 この継続的なプロセスには専用のリソースが必要であり、定期的なメンテナンスと監視が必要なため、運用コストが大幅に増加する可能性があります。 また、キーの漏洩による不正アクセスは機密データを侵害する可能性があるため、キーの漏洩や悪用に関連する大きなセキュリティ リスクがあります。 さらに、キーベースの認証方法では、多くの場合、動的環境に必要なスケーラビリティと柔軟性が欠け、変化する要件に適応し、運用を効果的にスケーリングすることが困難になります。 これらの課題は、リスクを軽減し、運用を合理化するために、マネージド ID などのより安全で効率的な認証方法を採用することの重要性を強調しています。
クライアント アプリケーション (ユーザー向け) が Microsoft Entra で保護されたリソースにアクセスする
多要素認証 (MFA) などの機能は、organizationをセキュリティで保護するための優れた方法ですが、多くの場合、ユーザーはパスワードを覚えておく必要がある上に、追加のセキュリティ 層に不満を感じます。 パスワードレス認証方法は、パスワードが削除され、自分が持っているものや知っているものに置き換えられるため、より便利です。
認証に関しては、組織ごとに異なるニーズがあります。 Microsoft Entra ID と Azure Government には、次のパスワードレス認証オプションが統合されています。
- Windows Hello for Business
- macOS のプラットフォーム資格情報
- スマート カード認証を使用した macOS 用プラットフォーム シングル サインオン (PSSO)
- Microsoft Authenticator
- パスキー (FIDO2)
- 証明書ベースの認証
詳細については、 Microsoft Entra パスワードレス サインインに関するページを参照してください。
Azure サービスから Azure へのサービス (Azure 内)
Azure リソース間の認証 (サービス間認証) の場合、Azure リソースのマネージド ID を使用することをお勧めします。 ただし、テナント間でリソースを認証してアクセスする場合は、アプリケーションでフェデレーション ID 資格情報としてマネージド ID を設定する必要があります。
Microsoft Entra で保護されたリソースにアクセスする (同じテナント)
Azure リソースとリソースの間でサービス間認証が必要なシナリオでは、マネージド ID と Azure ID クライアント ライブラリの DefaultAzureCredential クラスが推奨されるオプションです。
マネージド ID は、Azure コンピューティング リソース (Azure Virtual Machines、Azure Functions、Azure Kubernetes など) または マネージド ID をサポートする任意の Azure サービスに割り当てることができる ID です。 マネージド ID がコンピューティング リソースに割り当てられると、ストレージ アカウント、SQL データベース、Cosmos DB などのダウンストリーム依存関係リソースへのアクセスを承認できます。 マネージド ID は、アクセス キー、パスワード、証明書などのシークレット、またはサービス間の依存関係に対する他の形式の認証を置き換えます。
詳細については、「 Azure リソースのマネージド ID とは」を参照してください。
アプリケーションに DefaultAzureCredential とマネージド ID を実装し、Microsoft Entra ID とロール ベースのアクセス制御 (RBAC) を使用して Azure サービスへのパスワードなしの接続を作成します。
DefaultAzureCredential は複数の認証方法をサポートしており、どの方法が使用されるかは実行時に決定されます。 このアプローチを採用すると、環境固有のコードを実装することなく、異なる環境 (ローカル開発環境と運用環境) で異なる認証方法をアプリに使用できます。
アプリケーションで DefaultAzureCredential とマネージド ID を使用する方法の詳細については、「 Azure アプリとサービス間のシークレットレス接続の構成」を参照してください。
Microsoft Entra で保護されたリソースにアクセスする (テナント間)
Azure リソース間でサービス間認証が必要なシナリオでは、マネージド ID をお勧めします。 ただし、テナント (マルチテナント アプリ) 間でリソースにアクセスする場合は、マネージド ID はサポートされません。 以前は、クライアント シークレットまたは証明書を資格情報として使用してマルチテナント アプリケーションを作成し、複数のテナントのリソースを認証してアクセスしました。 これにより、シークレットの公開に関する重大なリスクが残り、証明書のライフサイクルを格納、ローテーション、および維持する負担が増えます。
Azure ワークロードでは、マネージド ID をフェデレーション ID 資格情報として使用して、シークレットや証明書に依存することなく、テナント間で Microsoft Entra で保護されたリソースに安全にアクセスできるようになりました。
詳細については、「 マネージド ID を信頼するようにアプリケーションを構成する」を参照してください。
Azure サービスが外部または Microsoft Entra 以外の保護されたリソースにアクセスする
Microsoft Entra またはアクセスにパスワード、シークレット、キー、または証明書を必要とする Azure サービスによって保護されていないリソースを認証してアクセスする Azure ワークロードの場合、マネージド ID を直接使用することはできません。 この場合は、Azure Key Vault を使用して、ターゲット リソースの資格情報を格納します。 ワークロードのマネージド ID を使用して、キー コンテナーから資格情報を取得し、資格情報を使用してターゲット リソースにアクセスします。
詳細については、「 コードで Key Vault に対する認証」を参照してください。
外部ワークロード (Azure の外部) が Microsoft Entra で保護されたリソースにアクセスする
ソフトウェア ワークロードが Azure の外部 (たとえば、オンプレミスのデータセンター、開発者のマシン、または別のクラウド) で実行されていて、Azure リソースにアクセスする必要がある場合、Azure マネージド ID を直接使用することはできません。 以前は、Microsoft ID プラットフォームにアプリケーションを登録し、外部アプリのクライアント シークレットまたは証明書を使用してサインインしていました。 これらの資格情報はセキュリティ上のリスクをもたらすため、安全に保管し、定期的にローテーションする必要があります。 また、資格情報の有効期限が切れると、サービスのダウンタイムのリスクも発生します。
ワークロード ID フェデレーションを使用して、GitHub や Google などの外部 ID プロバイダー (IdP) からのトークンを信頼するように、Microsoft Entra ID でユーザー割り当てマネージド ID またはアプリ登録を構成します。 その信頼関係が作成されると、外部のソフトウェア ワークロードは、外部 IdP からの信頼されたトークンを Microsoft ID プラットフォームからのアクセス トークンと交換します。 ソフトウェア ワークロードは、そのアクセス トークンを使用して、ワークロードにアクセス権が付与されている Microsoft Entra で保護されたリソースにアクセスします。 資格情報を手動で管理するメンテナンスの負担がなくなり、シークレットが漏洩するリスクや、証明書の有効期限が切れるリスクが排除されます。
詳細については、 ワークロード ID のフェデレーションに関するページを参照してください。