Azureでマネージド ID を使ってハードコードされたパスワードを排除する方法

By Mirko Peters · 2026-08-13

ポッドキャストのコンパニオンブログへようこそ。アプリケーションを開発してきた方なら、コードをデータベース、API、クラウド ストレージ アカウントに接続する際の古くからの問題に、きっと遭遇したことがあるはずです。

Automatically translated with AI from the original post. Read the English original

ポッドキャストのコンパニオンブログへようこそ。ある程度の期間アプリケーションを開発してきた方なら、コードをデータベース、API、クラウド ストレージ アカウントに接続する際の古くからの問題に、きっと遭遇したことがあるでしょう。従来は、接続文字列、データベース パスワード、クライアント シークレットを構成ファイルや環境変数に直接記述するか、さらにまずいことに、ソース コード リポジトリにハードコードして解決するのが一般的でした。アプリケーションがそのシークレットを読み取れる限り、認証に成功し、処理を実行できます。しかし、そのコードが誤って公開 GitHub リポジトリにプッシュされたらどうなるでしょうか。不満を抱えた従業員が退職したら、あるいは攻撃者がアプリケーション設定を読み取れてしまったらどうなるでしょうか。インフラストラクチャ全体が一瞬で侵害されてしまいます。現代のクラウド アーキテクチャにおいて、これは受け入れられないリスクです。本日は、Microsoft Azure のマネージド ID が、静的なシークレットを動的で有効期間の短いアクセス トークンに置き換えることで、ハードコードされたパスワードの必要性をどのように完全になくすのかを詳しく解説します。

クラウド セキュリティとハードコードされたシークレットの概要

従来の境界型セキュリティモデルは、いったん社内ネットワーク内に入れば信頼できる、という考え方に大きく依存していました。その境界の内側では、アプリケーションは静的なサービス アカウント、ハードコードされたパスワード、そしてほとんど期限切れにならない長期間有効なトークンを使って通信していました。悪意ある攻撃者が境界を突破すると、そこには何度でも再利用できる静的な資格情報の宝庫が待っていたのです。

クラウド コンピューティングは、この境界を完全に打ち砕きました。ワークロードは現在、マルチクラウド環境、オンプレミスのデータセンター、SaaS プラットフォーム、分散型のサーバーレス関数にまたがっています。この新しい世界では、セキュリティはワークロード自体の ID に従う必要があります。ハードコードされたシークレットは時限爆弾です。自動的にローテーションされず、監査も非常に困難で、漏えいした場合に許容できる余地はほとんどありません。真のゼロトラスト セキュリティを実現するには、資格情報をソース コードから完全に切り離す必要があります。アプリケーションがパスワードを知ったり保存したりすることなく、自身が何者であるかを証明できる認証の仕組みが必要なのです。

Entra ID におけるユーザー ID とワークロード ID の違い

クラウド セキュリティがどのように進化してきたかを理解するには、まず Microsoft Entra ID が、システムにアクセスするエンティティをどのように管理しているかを見る必要があります。大まかに言うと、Microsoft Entra ID は ID を、ユーザー ID とワークロード ID の 2 つの大きなカテゴリに分類します。

ユーザー ID は、従業員、パートナー、委託業者、顧客などの人間を表します。人間はシステムと動的にやり取りし、パスワード、Windows Hello for Business、FIDO2 セキュリティ キー、多要素認証など、人間向けに設計された方法で認証します。人はパスワードを忘れ、フィッシング攻撃の被害に遭い、管理者によるパスワードのリセットを必要とします。

一方、ワークロード ID はソフトウェアを表します。これには、アプリケーション、バックグラウンド サービス、自動化スクリプト、Azure Functions、Logic Apps、DevOps のデプロイ パイプライン、AI エージェントが含まれます。ワークロードはコーヒーを飲みませんし、フィッシング メールをクリックすることもなく、スマートフォンでの対話型の多要素認証プロンプトを完了することもできません。ワークロードは、対話なしで、プログラムによって、そして継続的に認証を行う必要があります。ワークロード ID をユーザー ID と同じように扱い、静的なパスワードを割り当ててしまうことは、クラウド アーキテクチャでもっとも多い落とし穴の 1 つです。ワークロード ID には、専用のガバナンス モデル、ライフサイクル管理、自動化された認証フローが必要です。

App 登録、サービス プリンシパル、マネージド ID を理解する

Microsoft Entra ID でアプリケーションを構成したことがあれば、混乱の原因となりがちな 3 つの用語に必ず出会ったことがあるでしょう。アプリの登録、サービス プリンシパル、マネージド ID です。ここでは、それぞれを簡単に説明します。

アプリケーション登録は、アプリケーションのグローバルな定義、いわば設計図です。Microsoft Entra ID にアプリケーションを登録すると、マルチテナントのエコシステム全体で通用するグローバルな ID が作成されます。ここで、アプリケーションに必要になる可能性のあるアクセス許可、使用する認証エンドポイント、関連付ける URI を定義します。アプリケーション登録は、パスポートの雛形のようなものだと考えてください。

サービス プリンシパルは、特定のテナント内におけるそのアプリケーションのローカルなインスタンスです。アプリケーションがマルチテナントの場合、発行元のテナントに 1 つのアプリケーション登録が存在しますが、デプロイされて同意が与えられた顧客テナントごとに、個別のサービス プリンシパルが作成されます。管理者が実際にアクセス許可を割り当て、条件付きアクセス ポリシーを適用し、そのアプリケーションに誰がローカルでアクセスできるかを制御するのが、サービス プリンシパルです。サービス プリンシパルは、特定の国に入国するときに実際に押印されたパスポートのようなものだと考えてください。

マネージド ID は、この考え方をさらに一歩進め、Microsoft Azure 内で実行されるリソース向けに特化したものです。開発者がアプリケーション登録を手動で作成し、クライアント シークレットを生成して、そのシークレットを環境変数に保存し、認証のライフサイクルを処理するコードを書く必要はありません。Azure が、その全工程を裏側で処理します。基盤となる資格情報の作成、管理、自動ローテーションを Azure が代わりに行います。開発者は Azure リソースにマネージド ID を使うよう指定するだけで、残りは Azure が担当します。

マネージド ID がパスワードとハードコードされた資格情報を不要にする仕組み

マネージド ID の利点は、認証の仕組みそのものを根本から変える点にあります。App Service、仮想マシン、Azure Functions などの Azure リソースでマネージド ID を使用する場合、コードや構成設定にパスワード、シークレット、証明書が保存されることは一切ありません。

アプリケーションが、データベースや API などの保護されたリソースにアクセスする必要がある場合も、保存されたパスワードを参照することはありません。代わりに、アプリケーションは Azure Instance Metadata Service (IMDS) エンドポイントへローカルに呼び出しを行います。このエンドポイントは、該当する Azure リソース内からのみ安全にアクセスできます。Azure リソースの基盤プラットフォームが、アプリケーションに代わって、Microsoft Entra ID から短期間有効な JSON Web Token (JWT) を直接取得します。

Microsoft Entra ID は Azure リソースの ID を検証し、有効期間が非常に短い（通常は約 1 時間）暗号署名付きのアクセス トークンを発行して、アプリケーションに返します。アプリケーションはこのトークンを使用して、対象のサービスに認証します。トークンの有効期限が短いため、攻撃者が仮にトークンを傍受できたとしても、悪用できる期間は極めて限られます。さらに、コードに固定のパスワードを書き込まないため、開発者が誤って公開リポジトリに漏えいさせてしまうようなものも存在しません。

Azure Key Vault と短期間有効なアクセス トークンの統合

マネージド ID を使えばアプリケーションのパスワードは不要になりますが、Microsoft Entra 認証に対応していないサードパーティ サービスの API キーのように、本当に外部にあるシークレットはどう扱えばよいのか、疑問に思われるかもしれません。ここで登場するのが Azure Key Vault です。Key Vault はマネージド ID と連携して機能します。

サードパーティの API キーをソース コードにハードコードする代わりに、そのシークレットを Azure Key Vault に安全に保存します。次に、Azure ロールベースのアクセス制御 (RBAC) または Key Vault のアクセス ポリシーを使用して、Azure リソースのマネージド ID に、その Key Vault からシークレットを読み取るアクセス許可を付与します。

アプリケーションは起動時に、マネージド ID を使って Azure Key Vault に認証し、必要なサードパーティ API キーを動的にメモリ上へ取得して使用します。資格情報がソース コードに露出する場面は一切ありません。アプリケーションは、構成ファイルに埋め込まれた固定の文字列に頼るのではなく、ID ベースの安全な仕組みでシークレットを取得します。

最小特権と統制によるワークロード ID の保護

ハードコードされたパスワードを排除することは、セキュリティ上の大きな前進です。ただし、マネージド ID を導入すれば後は放置してよい、という運用モデルではありません。ワークロード ID も、人間のユーザー アカウントと同様に、堅牢な統制が必要です。

まず何よりも、最小特権の原則を厳格に守る必要があります。作業を早く進めるためだけに、ワークロード ID に広範な共同作成者ロールや過剰な Microsoft Graph のアクセス許可を割り当ててはいけません。バックグラウンドの自動化スクリプトが特定の Azure Storage コンテナーから項目を読み取るだけであれば、そのコンテナーに対してのみ Storage Blob Data Reader の権限を付与してください。それ以上は必要ありません。万が一そのワークロード ID が侵害されても、影響範囲を最小限に抑えられます。

次に、ワークロード ID を継続的に監視し、監査する必要があります。組織では、概念実証のプロジェクト、自動化スクリプト、一時的な連携のためにサービス プリンシパルやマネージド ID を作成したまま、高い権限を持たせて無期限に放置することがよくあります。定期的なセキュリティ レビューを実施し、使われなくなったサービス プリンシパル、利用されていない自動化アカウント、古くなった資格情報を特定してください。Microsoft Entra ID Protection などの機能を活用し、Azure Monitor で堅牢なログ記録を設定すれば、ワークロード ID がいつ、どのように環境にアクセスしているかを完全に把握できます。

すべてのクラウド ワークロードに適した ID 戦略の選び方

Microsoft の ID エコシステムには多くの選択肢がありますが、特定のワークロードに適した認証戦略はどのように選べばよいのでしょうか。その判断は、一般的に、アプリケーションがどこで実行されるか、そしてどのようにアーキテクチャされているかによって決まります。

コードが Microsoft Azure 内で実行される場合、つまり Azure App Service、Azure Functions、Virtual Machines、Container Instances、Azure Kubernetes Service のいずれで実行される場合でも、最初の選択肢は常にマネージド IDにしてください。システム割り当てマネージド ID(Azure リソースとライフサイクルが 1:1 で結び付いたもの)と、ユーザー割り当てマネージド ID(独立して作成し、複数の Azure リソースに割り当てて管理を容易にできるもの)から選択できます。

アプリケーションがオンプレミス サーバー、AWS、GitHub Actions の CI/CD パイプラインなど、Azure の外で実行される場合、Azure インフラストラクチャでホストされるマネージド ID は選択肢になりません。このような場合は、ワークロード ID フェデレーションを利用してください。これにより、外部プラットフォームが OpenID Connect(OIDC)の信頼関係を使って Microsoft Entra ID と直接トークンを交換できます。長期間有効なクライアント シークレットを管理、ローテーション、保存する必要が完全になくなります。

最後に、マネージド ID もフェデレーションも実現できない従来型のカスタム エンタープライズ アプリケーションでクライアント認証が必要な場合は、長期間有効なクライアント シークレットよりも、適切に管理された証明書を優先すべきです。Microsoft Entra ワークロード ID、Azure Key Vault、ゼロトラストの原則、最小特権アクセスを組み合わせれば、組織はハードコードされたパスワードを完全に排除し、非常に回復力の高いクラウド アーキテクチャを構築できます。

最新のクラウド セキュリティに向けた結論と次のステップ

ハードコードされたパスワードや固定の接続文字列は、IT セキュリティにおける時代遅れの遺物です。Microsoft Entra ワークロード ID と Azure マネージド ID を取り入れることで、埋め込まれた資格情報に伴うリスクを完全に取り除き、ソース コード リポジトリの不用意な漏えいを防ぎ、すべてのクラウド ネイティブ アプリケーションで厳格な最小特権アクセスを徹底できます。短期間有効なアクセス トークンを使えば、仮にトークンが傍受されても有効期間が短いため、長期的な被害には至りません。セキュリティの姿勢を、事後対応型の防御から先回りの保護へと根本的に転換できるのです。

このテーマをさらに深く掘り下げ、現場での実装のヒントを知りたい方は、関連するポッドキャスト エピソード Entra Workload Identities - Simply Explained もぜひご覧ください。これらの概念をさらに詳しく解説していますので、ぜひお聴きいただき、Azure および Microsoft 365 の環境をプロのように保護してください。