ID 管理

ID 管理では、どのユーザー (ユーザー、アプリケーション、サービス) がどの条件でどのリソースにアクセスできるかを制御することで、クラウド セキュリティの基盤が確立されます。 ネットワーク境界と静的資格情報に依存する従来の境界ベースのセキュリティとは異なり、最新のクラウド環境では、分散されたマルチテナント アーキテクチャ全体で、動的な ID 検証、継続的認証、コンテキストに対応したアクセスの決定が必要です。 包括的な ID ガバナンスを実装する組織は、資格情報ベースの攻撃、未承認のアクセス、特権エスカレーションを防ぎますが、ID 制御を無視する組織はアカウントの侵害、横移動、脆弱な認証や過剰なアクセス許可を悪用する永続的な脅威に直面します。

Identity Management セキュリティ ドメインの 3 つの主要な柱を次に示します。

ユーザーの ID を保護する: 一元化された ID 管理、強力な多要素認証、完全なライフサイクル管理、特権 アクセス ワークステーション (PAW) や 緊急アクセス (中断) アカウントなどのセキュリティで保護されたアクセス方法を使用して、すべてのユーザー アカウント (特に特権ユーザー) のセキュリティを確立して維持します。

関連するコントロール:

• IM-1: 分離を確保しながら ID と認証を一元化する
• IM-2: ID と認証システムを保護する
• IM-5: アプリケーション アクセスにシングル サインオン (SSO) を使用する
• IM-6: 強力な認証コントロールを使用する
• IM-7: 条件に基づいてリソース アクセスを制限する

アプリケーションとシークレットを保護する: 自動化された ID 管理、適切なサーバーとサービスの認証、資格情報の公開を防ぐためのセキュリティで保護されたシークレット管理によって、人間以外の ID (アプリケーション、サービス) を安全に管理します。

関連するコントロール:

• IM-3: アプリケーション ID を安全かつ自動的に管理する
• IM-4: サーバーとサービスを認証する
• IM-8: 資格情報とシークレットの公開を制限する

セキュリティで保護されたアクセス: 最小限の特権の原則を使用して ID に適切なリソース アクセスを確保し、永続的な特権を回避し、リアルタイムのリスク評価に基づくコンテキスト対応のアクセス制御を利用します。

関連するコントロール:

• IM-7: 条件に基づいてリソース アクセスを制限する

IM-1: 分離を確保しながら ID と認証を一元化する

Azure Policy:Azure の組み込みポリシー定義 IM-1 を参照してください。

セキュリティの原則

一元化された ID と認証システムを使用して、クラウド リソースと非クラウド リソースに対する組織の ID と認証を管理します。

ID と認証を一元化する一方で、企業全体の戦略に基づいて ID を分離して分離する必要もあります。 目標は、日常のアクセスに使用されるものとは別の資格情報と ID を使用して、運用環境を確実に管理することです。 アイデンティティを分離および孤立させるための戦略には、次のようなものがあります。

• ID に対して最小限の特権アクセスを適用する
• 管理 ID と非管理 ID を分離する
• 環境間で ID を分離する
• ワークロード ID の分離を実装する
• テナント間で ID 境界の分離を適用する

軽減すべきリスク

• 未承認のアクセス: 分散化された認証システムまたはローカル認証システムは、セキュリティ ポリシーの一貫性、脆弱なパスワード プラクティス、監視されていないアカウントにつながることがよくあります。これにより、攻撃者は誤って構成された資格情報や古い資格情報を悪用して、機密性の高いリソース (ブルート フォースや盗まれた資格情報など) にアクセスできるようになります。
• 資格情報の盗難と再利用: 断片化された ID システムでは、資格情報が安全に保存されない (プレーンテキストや弱いハッシュなど) か、システム間で再利用されるリスクが高まるので、攻撃者は侵害された 1 つのシステムから資格情報を取得し、別の場所 (フィッシングや資格情報のダンプなど) を使用できるようになります。
• 一貫性のないアクセス制御: 一元化されたガバナンスがなければ、さまざまなアクセス ポリシーを持つさまざまなシステムが存在する可能性があり、攻撃者が特権をエスカレートしたり、承認されていないリソースにアクセスしたりするために悪用される可能性のある特権を超えるアカウントや孤立したアカウントが発生する可能性があります。
• 可視性と監視の欠如: 分散型認証には統合されたログと監視がないため、不正なログイン試行や異常なユーザー動作などの疑わしいアクティビティの検出が困難になり、検出されない侵害のリスクが高まります。

MITRE ATT&CK

• 初期アクセス (TA0001): 脆弱または分散型の認証メカニズム (既定の資格情報を持つローカル アカウントや古いプロトコルなど) の悪用により、攻撃者は未承認のエントリ (T1078 - 有効なアカウントなど) を取得できます。
• 資格情報アクセス (TA0006): 断片化された ID システムからの資格情報の盗難、安全でないストレージ (ローカル システムのプレーンテキスト パスワードなど) または脆弱な認証方法の悪用、資格情報のダンプや再利用 (T1003 - OS 資格情報のダンプなど) の促進。
• 特権エスカレーション (TA0004): 一元化されていないシステムで一貫性のないアクセス制御を利用して、過剰な特権または孤立したアカウントを悪用し、攻撃者が機密性の高いリソース (T1078 - 有効なアカウントなど) へのアクセスを昇格できるようにします。
• 防御回避 (TA0005): 一元的な監視がないために検出をバイパスし、攻撃者がアラートをトリガーせずに未承認のアクションを実行できるようにします (例: T1562 - 防御の損ない)。

IM-1.1: ID と認証を一元化する

一元化された ID 管理では、一貫したポリシーの適用、統合された監視、およびすべてのリソースに対する合理化されたアクセス制御を提供することで、断片化された認証システムのセキュリティ リスクを排除します。 最新のクラウド環境には、強力な認証方法、条件付きアクセス ポリシー、包括的な監査ログをサポートする単一の信頼できる ID ソースが必要です。 一元化された ID システムを採用している組織は、ハイブリッドおよびマルチクラウド アーキテクチャの柔軟性を維持しながら、資格情報の拡散を減らし、セキュリティ体制の可視性を向上させ、コンプライアンスを簡素化します。

次のアプローチを使用して、一元化された ID 管理を実装します。

• クラウド ID プラットフォームの導入: Microsoft Entra ID は、Entra ID をサポートする Microsoft および Microsoft 以外の環境の認証、承認、ガバナンスを一元化する 、マルチテナントのクラウドベースの ID およびアクセス管理サービスです。 標準化 すべてのリソースの ID を管理するための Microsoft Entra ID。

• クラウド リソース ID の管理: シークレットを排除し、分離を確保するには、Azure Storage、Azure 仮想マシン (Linux および Windows)、Azure Key Vault、PaaS、SaaS アプリケーションなどの Microsoft クラウド リソースのマネージド ID とワークロード ID フェデレーションを使用します。

• 組織のリソース認証を一元化する: Azure でホストされているアプリケーション、企業ネットワーク上のサード パーティ製アプリケーション、サードパーティの SaaS アプリケーションなどの組織リソースに対してシングル サインオン (SSO) と条件付きアクセスを活用して、セキュリティで保護されたコンテキスト対応のアクセスを提供します。

• ハイブリッド ID を同期する: オンプレミスの Active Directory を Microsoft Entra Connect Sync 経由で Microsoft Entra ID と同期して、エンタープライズ ID の一貫性のある一元的に管理されたハイブリッド ID 戦略を維持します。

• Azure サービスのローカル認証を排除する: Azure サービスのローカル認証方法を回避し、Microsoft Entra ID を使用して認証を一元化し、パスワードなしの方法 ( Windows Hello、FIDO2 キーなど) と多要素認証 (MFA) を使用してセキュリティを強化します。

注: Active Directory ソリューションと比較すると、Microsoft Entraは強力な認証や条件付きアクセス ポリシーなどの利点を提供します。技術的に実現可能になった時点で、内部ユーザー向けの現場用アプリケーションをMicrosoft Entra IDに移行してください。例えば、社内ユーザー向けのテナントや、パートナー協力用のMicrosoft Entra B2B、消費者向けアプリ用のMicrosoft Entra 外部 IDなどの構成を使用します。 カスタム属性を必要とするレガシ アプリに Microsoft Entra Domain Services を利用することもできます。

実装例

シナリオ： 金融サービス組織は、規制に準拠し、横移動を防ぐために、運用、開発、およびパートナー環境の間で厳密に分離された一元化された ID 管理を必要とします。

実装手順:

1. Microsoft Entra ID を一元化された ID プロバイダーとして展開します。

   • 企業 ID のプライマリ テナント (contoso.onmicrosoft.com) を作成する
   • オンプレミスの AD ユーザーを同期するように Microsoft Entra Connect Sync を構成する
   • リスクベースのポリシーと管理者に MFA を要求する条件付きアクセスに対して Entra ID 保護を有効にする
   • SaaS アプリの SSO の構成 (Salesforce、ServiceNow、GitHub)
   • Azure リソースのマネージド ID をデプロイし、Azure SQL/Storage でのローカル認証を排除する
   • FIDO2 キーと Windows Hello を使用してパスワードレス認証を有効にする

2. 分離のために管理グループ階層を設計する:

Tenant Root Group
├── Corporate Production (finance-prod-sub, hr-prod-sub)
├── Corporate Non-Production (dev-sub, test-sub)
├── Partner Integration (partner-sub)
└── Customer-Facing Tenant (customer-prod-sub, customer-staging-sub)

3. ID 分離を実装する:

   • 運用 ID: PAW を持つ専用管理者アカウントで、開発やテストのアクセスは不可
   • 開発 ID: 開発時にのみ昇格されたアクセス許可を持つ標準アカウント
   • パートナー ID:時間制限付きアクセス権を持つ Microsoft Entra B2B
   • 顧客 ID:Microsoft Entra 外部 ID を使用してテナントを分離する

4. サブスクリプション レベルの分離を適用する:

   • サブスクリプション スコープで Azure RBAC を割り当てる (prod-admin-group: finance-prod-sub の所有者のみ)
   • 運用環境へのアクセスには、準拠デバイスを要求する条件付きアクセスを適用する
   • セキュリティ ベースラインの管理グループ レベルで Azure Policy を構成する
   • 環境ごとに個別の Log Analytics ワークスペースを有効にする

5. セキュリティコントロールを実装する:

   • サブスクリプションの境界を使用して課金、リソース、アクセス許可を分離する
   • Azure Firewall をデプロイして環境間トラフィックを制限する
   • 統合されたセキュリティ監視 のために Defender for Cloud を有効にする
   • Entra ID 監査ログを Azure Monitor にストリーミングし、環境間のアクセス試行に関するアラートを生成する
   • Entra ID ガバナンスを使用して四半期ごとのアクセス レビューを実施する

結果：

組織は、すべての認証を管理する単一の一元化された ID プラットフォームを確立し、断片化された ID サイロを排除しました。 運用環境の資格情報は、厳密な環境分離によって開発者アクセスから完全に分離されるため、開発資格情報の侵害が運用環境のワークロードに影響を与える可能性はありません。 一貫性のある MFA ポリシーと条件付きアクセス ポリシーはすべての環境に適用されますが、規制コンプライアンスは包括的な監査証跡と職務の分離によって維持されます。

リファレンス:Microsoft Entra ID 初心者向けチュートリアル

重要度レベル

持っている必要があります。

コントロール マッピング

• NIST SP 800-53 Rev.5: AC-2、AC-3、AC-4、AC-6、SC-2、SC-7
• PCI-DSS v4: 1.4.2、7.2.1、7.2.2、8.2.1
• CIS コントロール v8.1: 6.7、12.5、16.1
• NIST CSF v2.0: PR。AA-1、PR。AC-1、PR。AC-7
• ISO 27001:2022: A.5.15、A.5.16、A.8.2
• SOC 2: CC6.1、CC6.2、CC6.6

IM-2: ID と認証システムを保護する

Azure Policy:Azure の組み込みポリシー定義 IM-2 を参照してください。

セキュリティの原則

組織のクラウド セキュリティプラクティスにおいて、ID と認証システムを優先度の高いものとしてセキュリティで保護します。 一般的なセキュリティ制御は次のとおりです。

• 特権ロールとアカウントを制限する
• すべての特権アクセスに強力な認証を要求する
• 高リスクアクティビティの監視と監査

軽減すべきリスク

• Credential-Based 攻撃: 非連携認証、レガシープロトコル (POP3、IMAP など)、安全ではない OAuth 2.0 の同意フローによって悪用可能なアクセス ポイントが作成され、攻撃者はクレデンシャルやトークン (ブルート フォース、フィッシング、OAuth の同意の悪用など) を侵害してシステムに侵入できます。
• 特権の昇格: 過剰にプロビジョニングされた RBAC ロール、永続的な特権アクセス、および過剰なグローバル管理者の割り当てにより、アカウントの引き継ぎまたは特権属性証明書 (PAC) の悪用によって攻撃者によって悪用され、アクセスをエスカレートする未承認のアクセス許可の取得が可能になります。
• リソース境界違反: サブスクリプションのガバナンスに一貫性がなく、環境分離の欠如により、開発、テスト、またはプローブの境界を侵害するために、攻撃者が横移動 (正しく構成されていないサービス プリンシパルを悪用するなど) を介して悪用される、リソース間アクセスが許可されます。
• テナント間 ID の誤用: 脆弱なクロステナント認証と未確認のフェデレーション ID では、マルチテナント環境が公開され、攻撃者はトークンリプレイまたは未承認の ID フェデレーションによって悪用され、外部テナントにアクセスします。
• アクセスの永続化: ID ライフサイクル管理が不十分で、監視されていないアクセス レビューにより、古いまたは過剰なアクセス許可が生じます。攻撃者は、休止中のアカウントの再アクティブ化や孤立したサービス プリンシパルの悪用を利用して、長期アクセスを維持します。
• 脅威検出回避: クラウドおよびオンプレミス環境全体の断片化された監視と未構成のリアルタイム アラートは、Kerberos 攻撃 (パス チケットなど) を介して攻撃者によって悪用された悪意のあるアクティビティや、検出を回避するための異常なトークンの使用を隠します。
• ポリシーの構成の誤り: 強制されていないガバナンス ポリシーと一元化された管理グループ制御の欠如により、セキュリティ設定の一貫性が失われ、条件付きアクセスまたはロールの割り当てが正しく構成されていない攻撃者によって悪用され、制限がバイパスされます。

MITRE ATT&CK

• 初期アクセス (TA0001): 未検証の ID プロトコルの悪用または OAuth 2.0 アプリケーションの同意の誤った構成により、敵対者が不正なエントリ (T1078 - 有効なアカウントなど) を取得できるようにします。
• 資格情報アクセス (TA0006): セキュリティで保護されていない ID 構成からの認証トークンまたはサービス プリンシパル シークレットの盗難、脆弱なストレージまたはレガシ認証方法の悪用、資格情報の侵害の促進 (T1110 - ブルート フォースなど)。
• 特権エスカレーション (TA0004): ID システムで過剰な特権 RBAC 割り当てまたは正しく構成されていない特権属性証明書 (PAC) を利用して、敵対者が機密性の高いリソース (T1134 - アクセス トークン操作など) へのアクセスを昇格できるようにします。
• 横移動 (TA0008): 分離されていないサブスクリプションまたはクロステナント ID 構成の悪用。敵対者が環境またはテナントの境界 (T1578 - クラウド コンピューティング インフラストラクチャの変更など) を通過できるようにします。
• 永続化 (TA0003): 監視対象外の ID ライフサイクルまたは孤立したサービス プリンシパルの操作。敵対者は古い資格情報 (T1098 - アカウント操作など) を通じて長時間のアクセスを維持できます。
• 防御回避 (TA0005): 監視対象外の ID アクティビティまたは Kerberos チケット操作の悪用により、敵対者は異常なトークンの使用 (T1550 - 代替認証マテリアルの使用など) などの悪意のあるアクションを隠すことができます。

IM-2.1: ID のセキュリティ スコアを評価する

ID セキュリティ体制では、構成のギャップとセキュリティの弱点を識別する測定可能なメトリックを通じて継続的な評価と改善が必要です。 Identity Secure Score には、認証制御の強化、特権アクセスの露出の軽減、資格情報ベースの攻撃を防ぐ最新のセキュリティ機能の実装に関する実用的な推奨事項が用意されています。 セキュリティ スコアを定期的に確認している組織は、影響の大きい改善を特定し、修復作業に優先順位を付け、業界のフレームワークへのコンプライアンスを維持しながら、利害関係者にセキュリティの成熟度を示します。

次のプラクティスを使用して、ID セキュリティ体制を評価して改善します。

• ID セキュリティ スコアの評価:ID セキュリティ スコアを使用して、ID セキュリティ体制を評価し、構成のギャップに対処し、管理ロールの割り当て、MFA の適用、レガシ認証の状態、同意ポリシーを評価します。

• 制限付き管理者ロールを割り当てます。 制限付き管理ロールを割り当て、冗長性を確保するために 2 ~ 4 人のグローバル管理者を指定し、過剰なプロビジョニングを回避することで、最小限の特権を適用します。

• ID 保護ポリシーを有効にする: Microsoft Entra ID 保護 を使用してユーザーとサインインのリスク ポリシーを有効にし、セキュリティで保護されていないアクセスを防ぐためにレガシ認証プロトコルをブロックします。

• 多要素認証を適用する: パスワードなしの方法 (FIDO2、Windows Hello など) をサポートするすべてのユーザーに MFA を要求し、特権アクセスをセキュリティで保護するために管理者ロールに MFA を要求します。

• セルフサービス機能を有効にする: セキュリティで保護されたユーザー主導の回復のためにセルフサービス パスワード リセット (SSPR) を有効にし、セキュリティと使いやすさのバランスを取るリスクの高いアカウント (特権ロールなど) のパスワードの有効期限を設定します。

• アプリケーションの同意を制御する: 未承認のアクセスを防ぐために、ユーザーがアンマネージド アプリケーションに同意することを制限します。

• ID の脅威検出をデプロイします。 Microsoft Entra ID 保護 を利用して、ID ベースのリスクを検出、調査、修復します。 オンプレミスの Active Directory の場合は、Microsoft 365 Defender と統合された Microsoft Defender for Identity を使用して、ハイブリッド環境を監視および保護します。

注: オンプレミスの Active Directory、サード パーティの機能、ホスティング インフラストラクチャ (オペレーティング システム、ネットワーク、データベース) など、他のすべての ID コンポーネントに対する Microsoft のベスト プラクティスに従って、ID とアクセスのセキュリティを確保します。

実装例

シナリオ： 金融サービス組織は、継続的な監視とリスクベースの保護を使用して、5,000 人のユーザーと 200 以上のアプリケーションにわたって ID セキュリティ体制を改善する必要があります。

実装手順:

1. ID セキュリティ スコアを使用してベースラインを確立する:

   • Microsoft Entra ID のアクセス ID セキュリティ スコア ダッシュボード (現在のスコア: 62/100)
   • 優先順位付けされた推奨事項を確認する: グローバル管理者 (8→3) を減らす、特権アカウントに MFA を適用する、レガシ認証を無効にする、アプリケーションの同意を制限する
   • 目標スコアの設定: 90 日以内の 85/100

2. Microsoft Entra ID 保護 を展開して、リスク検出を自動化します。

   • リスクベースのポリシーを有効にする: リスクの高いユーザーにはパスワードの変更を要求し、中/高リスクのサインインには MFA を必要とする
   • 漏洩した資格情報、異常なアクティビティ、特権エスカレーションの試行に対するアラートを構成する
   • Microsoft 365 Defender と統合して、関連する脅威インテリジェンスを得る

3. 継続的な監視を実装します。

   • 毎週のセキュリティ スコア レビューと毎日のリスク検出の監視を確立する
   • 自動修復の構成: リスクの高い IP の自動ブロック、侵害された資格情報のパスワード リセットのトリガー、異常な動作のセッションの取り消し
   • 古い特権の割り当てを削除するための四半期ごとのアクセス レビューを実施する

結果：

組織は、継続的な監視とリスクベースの保護を通じて、ID のセキュリティ体制を大幅に改善しました。 ID セキュア スコアはターゲット期間内に大幅に増加し、グローバル管理者アカウントは最小特権のベスト プラクティスに合わせて削減されました。 MFA カバレッジは、すべての特権アカウントの完全なデプロイに達し、レガシ認証プロトコルが無効になり、攻撃対象領域が大幅に減少しました。 リスク検出と対応の自動化機能により応答時間が大幅に短縮され、資格情報ベースの攻撃はプロアクティブな監視と自動修復によって完全に排除されました。

参照:

• 一般提供における新しい ID セキュリティ スコアの推奨事項
• Microsoft Entra ID 保護 を使用したリスクの監視と評価

重要度レベル

持っている必要があります。

コントロール マッピング

• NIST SP 800-53 Rev.5: AC-2、AC-3、IA-2、IA-4、IA-5、IA-8、SI-4
• PCI-DSS v4: 7.2.1、8.2.1、8.3.1、8.3.2、10.2.1
• CIS コントロール v8.1: 5.4、6.3、6.5、8.2
• NIST CSF v2.0: PR。AA-1、PR。AC-1、DE。CM-1
• ISO 27001:2022: A.5.15、A.5.16、A.5.17、A.8.5
• SOC 2: CC6.1、CC6.2、CC6.6、CC7.2

IM-3: アプリケーション ID を安全かつ自動的に管理する

Azure Policy:Azure の組み込みポリシー定義 IM-3 を参照してください。

セキュリティの原則

リソースにアクセスしてコードを実行するアプリケーションのヒューマン アカウントを作成する代わりに、マネージド アプリケーション ID を使用します。 マネージド アプリケーション ID は、資格情報の公開を減らすなどの利点を提供します。 資格情報のローテーションを自動化して、ID のセキュリティを確保します。

軽減すべきリスク

• コードまたは構成での Hard-Coded 資格情報の公開: ソース コード、ビルド 成果物、または構成ファイル (.env、YAML など) に埋め込まれた静的資格情報 (API キー、クライアント シークレットなど) は、正しく構成されていない SCM リポジトリ (パブリック Git リポジトリなど) または CI/CD パイプラインを介して公開されるため、敵対者はトークン エンドポイントへの HTTP POST 要求を介してクラウド API に対して認証を行うことができます。
• フィッシングまたは傍受による資格情報の盗難: 敵対者は、スピアフィッシュ キャンペーン (OAuth 同意フィッシングなど) または MitM 攻撃によって有効期間の長い資格情報または API キーをキャプチャし、暗号化されていない HTTP/HTTPS トラフィックを傍受し、脆弱な TLS 構成を利用してクラウド サービス認証用のトークンを取得します。
• 脆弱な資格情報または再利用された資格情報からの不正アクセス: セキュリティで保護されていない構成された資格情報 (低エントロピ パスワード、再利用された API キーなど) は、ブルートフォース列挙 (REST API 呼び出しによるパスワード スプレーなど) や、侵害されたデータセットを利用する資格情報詰め込み攻撃に対して脆弱であり、クラウド管理 API へのアクセスを許可します。
• 不正なアカウントまたは孤立したアカウントを介した永続的なアクセス: 敵対者は、許可されていないアカウントを作成するか、使用停止されたリソースから未削除の資格情報を悪用し、クラウド オーケストレーション テンプレート (IaC ファイルなど) に静的キーを埋め込み、OAuth 2.0 トークン交換を繰り返して永続的なアクセスを維持します。
• Over-Privileged 資格情報からの特権エスカレーション: オーバースコープの資格情報 (管理者レベルの IAM ロールを持つ API キーなど) を使用すると、敵対者は高い特権の API 操作 (リソースの作成、ポリシーの変更など) を呼び出し、正しく構成されていない RBAC アクセス許可を利用して特権をエスカレートできます。
• 侵害されたシステムからの資格情報の収集: 敵対者は、侵害されたクラウド インスタンス (メモリ スクレーピングなど) またはセキュリティで保護されていないストレージ (S3 バケット、構成ストアなど) からプレーンテキストの資格情報、API キー、または OAuth トークンを抽出します。収集されたデータを使用して、横移動のために追加のクラウド API に対する認証を行います。
• 監視対象外の資格情報の使用による検出回避: 敵対者は、盗まれた静的な資格情報を利用して、正当なトラフィックを模倣する API 要求を生成し、無効な監査ログを利用して検出を回避したり、クラウド テレメトリの異常検出の欠如を回避したり、承認されていないアクセスの識別を遅らせたりします。

MITRE ATT&CK

• 初期アクセス (TA0001): クラウド アプリケーション コードまたは構成ファイルに埋め込まれたハードコーディングされた資格情報または侵害されたユーザー アカウントを悪用し、フィッシング (T1566.001) を利用してパスワードを盗んだり、誤って構成された公開 API (T1190) を悪用して OAuth 2.0 または API キーベースのエンドポイントを介して認証したりします。
• 資格情報アクセス (TA0006): ソース コード リポジトリまたはセキュリティで保護されていないストレージ (T1003) で公開された資格情報をターゲットにし、脆弱なユーザー パスワード (T1110.001) に対するブルートフォース攻撃を使用するか、クラウド サービス認証フロー中に API キーとセッション トークン (T1539) を傍受します。
• 永続化 (TA0003): 不正なユーザーアカウント (T1136.003) を作成するか、クラウドアプリケーション構成を変更して永続的な資格情報を組み込むこと (T1098.001) でアクセスを維持し、検出されることなくクラウドリソースに繰り返し認証できるようにします。
• 特権エスカレーション (TA0004): 侵害されたユーザー アカウントまたは過剰なアクセス許可を持つ公開された API キーは、管理アクセス権を取得するために悪用され、誤って構成されたロールベースのアクセス制御 (T1548.004) を悪用してクラウド リソースまたは管理 API を操作します。
• 防御回避 (TA0005): 攻撃者は、盗まれた API キーまたはセッション トークン (T1606.002) を偽造して正当なクラウド トラフィックを模倣したり、監査ログ (T1562.001) を無効にしたりして検出を回避し、監視を回避するために承認されたユーザー (T1036) として偽装します。
• コレクション (TA0009): セキュリティが侵害されたクラウド インスタンスまたはストレージ (T1213.002) からハードコーディングされた資格情報、API キー、またはユーザー セッション データを収集し、構成ファイルまたはメモリ ダンプ (T1005) をターゲットにして、横移動用の機密データを収集します。

IM-3.1: サポートされている Azure リソースでマネージド ID を使用する

マネージド ID は、Microsoft Entra ID 認証をサポートするサービスに対して認証するための自動的にマネージド ID を Azure リソースに提供することで、資格情報の公開を排除します。 これらのプラットフォームで管理される資格情報は、ソース コードまたは構成ファイルにハードコーディングされたシークレットを必要とせずに、完全にローテーションおよび保護され、攻撃対象領域と運用上のオーバーヘッドが軽減されます。 マネージド ID を採用している組織は、資格情報の盗難を防ぎ、シークレット管理を簡素化し、セキュリティ コンプライアンスを維持しながら、Azure リソース全体でシームレスなサービス間認証を有効にします。

次の手順を使用してマネージド ID を実装します。

• マネージド ID を選択して有効にします。 ユース ケースに基づいて、システム割り当て (1 つのリソースに関連付けられ、リソースで自動的に削除される) か、ユーザー割り当て (スタンドアロンで複数のリソース間で再利用可能) を決定します。 リソースの作成時にマネージド ID を有効にします (たとえば、Azure App Service のシステム割り当て ID が Key Vault にアクセスできるようにします)。

• 最小特権のアクセス許可を割り当てます。 Azure Role-Based アクセス制御 (RBAC) を使用して、ターゲット Azure サービスのマネージド ID 固有のロール (Key Vault シークレット ユーザーやストレージ BLOB データ閲覧者など) を付与します。

• アプリケーション コードに認証を統合する: Azure SDK (.NET の Azure.Identity、Python の azure-identity など) を DefaultAzureCredential と共に使用して、資格情報を埋め込まずに Key Vault、SQL Database、Storage などのサービスに対して認証します。 たとえば、C# では、var credential = new DefaultAzureCredential(); を使用します。Key Vault からシークレットにアクセスするためのトークンをフェッチします。

• トークンの自動更新を有効にする: アプリケーションがトークンの更新を自動的に処理することを確認します (通常、トークンは 24 時間後に期限切れになります)。

IM-3.2: マネージド ID が適用されない場合はサービス プリンシパルを使用する

サービス プリンシパルは、マネージド ID を使用できないサービスとアプリケーションに対してセキュリティで保護された認証を提供し、強化されたセキュリティ制御を使用して資格情報ベースのアクセスを実装します。 組織は、最小限の特権の RBAC 割り当てを通じて厳密なアクセス許可の境界を維持しながら、公開リスクを軽減するために、クライアント シークレットよりも証明書資格情報の優先順位を付ける必要があります。 適切に構成されたサービス プリンシパルにより、セキュリティで保護された自動化と統合のシナリオが可能になり、シークレット ローテーション ポリシーとセキュリティで保護されたコンテナー ストレージによって資格情報の盗難リスクが最小限に抑えられます。

次の方法を使用してサービス プリンシパルを実装します。

• Microsoft Entra ID でサービス プリンシパルを作成します。 Microsoft Entra ID を使用して、マネージド ID をサポートしていないサービスのサービス プリンシパルを作成し、それがアプリケーションまたはサービスを表していることを確認します (たとえば、Azure Storage へのアクセスを必要とするレガシ サービスにアプリを登録します)。

• 制限付きアクセス許可を構成する: リソース レベル (特定のストレージ アカウントのストレージ BLOB データ共同作成者など) で Azure Role-Based アクセス制御 (RBAC) を使用して、サービス プリンシパルに最小特権のアクセス許可を割り当てます。

• 証明書ベースの資格情報を使用する: セキュリティを強化するために、クライアント シークレットよりも証明書資格情報を優先します。 自己署名証明書または CA によって発行された証明書を生成し、Entra ID でサービス プリンシパルにアップロードします。

• 必要に応じて、クライアント シークレットにフォールバックします。 証明書が実現できない場合は、定義された有効期限 (例: 1 年) を使用して Entra ID にクライアント シークレットを作成します。 シークレットを Azure Key Vault に安全に格納し、プログラムで取得することで、ソース コードまたは構成ファイルでのハードコーディングを回避します。 有効期限が切れる前にシークレットをローテーションし、未使用のシークレットを削除してリスクを最小限に抑えます。

• アプリケーション コードに認証を統合する: Azure SDK (Azure.Identity の ClientCertificateCredential や ClientSecretCredential など) を使用して、アプリケーション コードでサービス プリンシパルの資格情報を使用して認証します。

実装例

シナリオ： 50 以上のアプリケーションを持つ医療組織では、HIPAA コンプライアンスのためのセキュリティで保護された認証が必要であり、コードと構成ファイルから資格情報が削除されます。

実装手順:

1. Azure サービス のマネージド ID をデプロイします 。

   • SharePoint と Azure SQL にアクセスする 30 App Services のシステム割り当て ID を有効にする
   • Key Vault と Service Bus にアクセスする 15 個の Azure Functions のユーザー割り当て ID を構成する
   • バックグラウンド処理ジョブ用に VM にマネージド ID をデプロイする
   • Azure.Identity SDK を使用してアプリケーション コードをリファクタリングする (DefaultAzureCredential)

2. レガシ システム のサービス プリンシパルを 構成します。

   • 証明書ベースの認証を使用して 5 つのサービス プリンシパルを作成する (組織 PKI の X.509)
   • 自動ローテーションを使用して Azure Key Vault に証明書を格納する
   • 特定のリソースグループにスコープを限定して最小特権のRBACロールを割り当てる
   • CI/CD パイプラインの場合: 6 か月の有効期限と自動ローテーションでクライアント シークレットを使用する

3. 監視とガバナンスを実装する:

   • マネージド ID を使用せずにリソースを監査する Azure Policy をデプロイする
   • 資格情報の公開を検出するように Defender for Cloud を構成する
   • サービス プリンシパルのアクセス許可の四半期ごとのアクセス レビューを確立する
   • 異常なサービス プリンシパル アクティビティのサインイン ログを監視する

結果：

組織は、大部分のアプリケーションをマネージド ID に正常に移行し、最新のクラウドネイティブ サービスでの資格情報管理の必要性を排除しました。 マネージド ID を採用できないレガシ システムは、自動ローテーション機能を備えた証明書ベースのサービス プリンシパルを使用してセキュリティ保護されていました。 ハードコーディングされたすべての資格情報がアプリケーション コードと構成ファイルから削除され、サービス プリンシパルの資格情報ローテーションが完全に自動化されました。 この包括的な変換により、以前に特定された資格情報管理に関連するすべてのコンプライアンス監査結果が排除されました。

参照:

• マネージド ID を使用して SharePoint Online サイトへのアクセス権を Azure リソースに付与する
• Azure サービス プリンシパル アカウントの操作

重要度レベル

持っている必要があります。

コントロール マッピング

• NIST SP 800-53 Rev.5: AC-2、AC-3、IA-2、IA-4、IA-5、IA-9、SC-12、SC-13
• PCI-DSS v4: 8.2.1、8.2.2、8.3.1、8.5.1
• CIS コントロール v8.1: 6.7、12.5、16.1、16.9
• NIST CSF v2.0: PR。AA-1、PR。AC-1、PR。DS-1
• ISO 27001:2022: A.5.15、A.8.3、A.8.5
• SOC 2: CC6.1、CC6.2

IM-4: サーバーとサービスを認証する

Azure Policy:Azure の組み込みポリシー定義 IM-4 を参照してください。

セキュリティの原則

信頼されたサーバーとサービスに接続していることを確認するために、クライアント側からリモート サーバーとサービスを認証します。 最も一般的なサーバー認証プロトコルはトランスポート層セキュリティ (TLS) です。クライアント側 (多くの場合、ブラウザーまたはクライアント デバイス) は、サーバーの証明書が信頼された証明機関によって発行されたことを確認してサーバーを検証します。

注: 相互認証は、サーバーとクライアントの両方が相互に認証するときに使用できます。

軽減すべきリスク

• 不正アクセス: 攻撃者は、サービスまたはクライアントを偽装し、API、ストレージ、またはコンピューティング リソースにアクセスするために、認証の欠落または欠陥を悪用します。 これにより、データ流出、ペイロードの挿入、またはシステムの引き継ぎが可能になります。 たとえば、認証されていないサービス間要求では、Azure Storage から機密性の高い BLOB を抽出できます。一方、検証をバイパスするクライアントはバックエンド API を直接操作する可能性があります。
• 資格情報の盗難または漏洩: コード、構成、またはログの資格情報 (クライアント シークレット、トークンなど) をハードコーディングまたは公開すると、攻撃者によって収集され、永続的なリソース アクセスが許可されます。 盗まれた AAD アプリ シークレットを使用すると、信頼できるサービスの無期限の偽装が可能になり、取り消されるまでスコープが設定されたすべてのエンドポイントにアクセスできます。 弱いシークレットローテーションまたは暗号化されていないストレージは、露出を増幅します。
• 中間者 (MITM) 攻撃: 敵対者は、セキュリティで保護されていない通信を傍受し、トークンを盗んだり、要求を変更したりします。 相互認証がないと、攻撃者は ID のスプーフィングを行い、データの整合性を損なう可能性があります。 たとえば、暗号化されていないサービス間呼び出しによって JWT がリークし、偽造された API 要求が有効になる可能性があります。 脆弱な TLS 暗号または証明書の検証がない場合は、脆弱性が高まります。
• 特権エスカレーション: ID が過度に制限されているか、スコープが正しく構成されていないと、攻撃者は未承認のリソースにアクセスしたり、特権アクションを実行したりできます。 過剰な RBAC ロール ("所有者" など) を持つサービス プリンシパルは悪意のあるリソースをデプロイする可能性があり、広範なユーザーアクセス許可を持つクライアントは重要な構成を変更し、制限から完全な制御にエスカレートする可能性があります。

MITRE ATT&CK

• 初期アクセス (TA0001): 攻撃者は、盗まれたクライアント資格情報 (T1078.004) またはユーザー トークン (T1566.002) のフィッシングを使用して、サービス間またはクライアント間フローで脆弱な認証を悪用して環境に侵入します。 たとえば、OAuth 2.0 アプリの登録が正しく構成されていないと、偽造されたトークンを介した未承認の API アクセス (T1133) が許可され、ストレージまたはコンピューティング リソースへのエントリが許可されます。
• 資格情報アクセス (TA0006): 敵対者は、コード リポジトリ、ログ、またはセキュリティで保護されていないコンテナー (T1552.001) で公開されているクライアント シークレット、証明書、または JWT を対象としています。 手法には、CI/CD パイプラインからのサービス プリンシパル資格情報の取得 (T1552.004) やクライアント認証時の更新トークンのインターセプト (T1539) が含まれます。これにより、保護された API への永続的なアクセスが可能になります。
• コレクション (TA0009): 攻撃者は、侵害されたリソースからアクセス トークンやセッション データなどの認証成果物を収集します (T1213.002)。 これには、アプリケーション構成 (T1552.001) からハードコーディングされたシークレットを抽出したり、セキュリティで保護されていないサービス間呼び出し (T1040) で MITM を介して転送中トークンをキャプチャしたりして、さらなる攻撃を促進することが含まれます。
• 特権エスカレーション (TA0004): 過剰なロールベースのアクセス許可を持つ侵害されたサービス プリンシパルまたはユーザー アカウントは、昇格されたアクセス権を取得するために悪用されます (T1078.004)。 攻撃者は、誤って構成されたアプリのアクセス許可 (T1548.004) を悪用してリソース構成を変更したり、管理者ロールを割り当てたりして、システムまたはテナントの制御をエスカレートします。
• 防御回避 (TA0005): 攻撃者は盗まれたトークン (T1606.002) を偽造して、正当なトラフィックを模倣したり、API 検証をバイパスするように要求を操作したりします (T1036.008)。 監査ログ (T1562.001) を無効にするか、マネージド ID を使用して通常の操作 (T1078) とブレンドすると、システムの監視による検出を回避できます。

IM-4.1: サーバーとサービスを認証する

サーバーとサービスの認証は、分散コンポーネント間の信頼関係を確立し、中間者攻撃やサービス偽装の脅威を防ぎます。 トランスポート層セキュリティ (TLS) は、セキュリティで保護された通信を確立する前に、信頼された証明機関によって発行されたサーバー証明書をクライアントが検証する、サーバー認証の標準的なメカニズムを提供します。 すべてのサービス通信で TLS 認証を適用する組織は、転送中のデータを保護し、資格情報の傍受を防ぎ、ゼロトラスト アーキテクチャに不可欠なセキュリティで保護されたサービス間対話を維持します。

次のプラクティスを使用して、サーバーとサービスの認証を実装します。

• すべてのサービスに対して TLS 認証を有効にします。 多くの Azure サービスでは、既定で TLS 認証がサポートされています。 既定で TLS 認証をサポートしていないサービス、または TLS の無効化をサポートしているサービスの場合は、サーバー/クライアント認証をサポートするために常に有効になっていることを確認します。

• クライアント アプリケーションでの証明書の信頼を確認します。 クライアント アプリケーションは、ハンドシェイク ステージ中にサーバーの証明書が信頼された証明機関によって発行されたことを確認することによって、サーバー/クライアント ID を確認するように設計する必要があります。

• 必要に応じて相互 TLS を実装します。 API Management や API Gateway などのサービスでは、サーバーとクライアントの両方が相互に認証されるセキュリティ強化のための TLS 相互認証がサポートされています。

実装例

シナリオ： 支払処理会社は、モバイル アプリケーション、バックエンド サービス、および支払いゲートウェイ間の API 通信をセキュリティで保護して、PCI-DSS コンプライアンスを満たす必要があります。 相互認証による中間者攻撃を防ぐ必要があります。

実装手順:

1. すべてのサービスに TLS 1.2 以降を適用します。

   • すべての Azure アプリ Services と API Management で最小 TLS バージョン (1.2 以降) を構成する
   • すべてのカスタム ドメインに対して DigiCert から信頼された SSL/TLS 証明書をデプロイする
   • HTTPS 専用モードを有効にして HTTP 要求をリダイレクトする
   • "Encrypt=True" と "TrustServerCertificate=False" を使用して Azure SQL Database を構成する

2. 重要な API の相互 TLS (mTLS) を実装します。

   • App Service 構成でクライアント証明書認証を有効にする
   • 信頼されたクライアント証明書 CA を App Service にアップロードする
   • クライアント証明書 (拇印、有効期限、発行者) を検証するように API Management を構成する
   • パートナー/モバイル アプリのバージョンごとに一意のクライアント証明書を発行する
   • 適切なアクセス制御を使用して Azure Key Vault に証明書を格納する

3. 証明書のライフサイクル管理:

   • Azure で管理される証明書の証明書の自動ローテーションを有効にする
   • 60 日以内に期限切れになる証明書のアラートを設定する
   • OCSP (オンライン証明書ステータス プロトコル) チェックを実装する
   • 四半期ごとの証明書失効テストを構成する

4. クライアント アプリケーション証明書の検証:

   • モバイル バンキング アプリの 証明書のピン留めを 実装する (iOS/Android)
   • アプリケーション コードでサーバー証明書チェーンを検証する
   • デバイスのセキュリティで保護されたエンクレーブ/キーチェーンにクライアント証明書を格納する

結果：

組織は、最新の TLS 標準を使用してすべての API 通信の完全な暗号化を実現し、セキュリティ強化を必要とする価値の高い API エンドポイントに相互 TLS を実装しました。 中間者攻撃は実装後に完全に排除されましたが、サービスの停止を引き起こす証明書管理の問題は自動化によって解決されました。 すべての要件で完全な PCI-DSS コンプライアンスが実現され、証明書のライフサイクル管理が自動化され、運用上のオーバーヘッドなしで継続的なセキュリティが確保されました。

参照:

• Azure App Service で TLS 相互認証を構成する

重要度レベル

持っている必要があります。

コントロール マッピング

• NIST SP 800-53 Rev.5: IA-9、SC-8、SC-13、SC-23
• PCI-DSS v4: 4.2.1、6.2.4、8.2.1
• CIS コントロール v8.1: 3.10、9.2、13.3
• NIST CSF v2.0: PR。DS-2、PR。DS-5
• ISO 27001:2022: A.5.14、A.8.24
• SOC 2: CC6.6、CC6.7

IM-5: アプリケーション アクセスにシングル サインオン (SSO) を使用する

セキュリティの原則

シングル サインオン (SSO) を実装して、クラウド サービス、SaaS アプリケーション、オンプレミス環境全体でのユーザー認証を効率化し、ユーザー エクスペリエンスとセキュリティを強化します。 SSO を使用すると、ユーザーは信頼できる ID プロバイダー経由で 1 回ログインし、ログインを繰り返さずにすべての承認されたリソースにアクセスできます。 これにより、一元化された MFA、一貫性のある TLS、統合された監視を適用して、セキュリティで保護された効率的なアクセス管理を確保することで、パスワードの疲労を軽減し、資格情報の拡散を最小限に抑え、フィッシング、ブルート フォース攻撃、公開された資格情報などのリスクを軽減します。

軽減すべきリスク

• コードまたは構成での Application-Specific 資格情報の公開: ソース コードまたは構成ファイル (.env、JSON など) に埋め込まれたプレーンテキスト資格情報 (API キー、パスワードなど) は、誤って構成されたリポジトリまたは CI/CD パイプラインを介して公開されるため、敵対者は API エンドポイントを介してクラウドまたはオンプレミスのサービスに対して認証を行うことができます。
• 複数のログイン インターフェイス間でのフィッシングによる資格情報の盗難: 敵対者はスピア フィッシング (偽のアプリ固有のログイン ページなど) を介して資格情報をキャプチャするか、暗号化されていないトラフィックをさまざまなログイン エンドポイントに傍受し、一貫性のない TLS 構成を利用して複数のシステムの資格情報を取得します。
• 弱い資格情報または再利用された資格情報からの未承認アクセス: さまざまなアプリ間で低エントロピーまたは再利用された資格情報は、ブルートフォース攻撃 (アプリ ログイン API を使用したパスワード スプレーなど) や資格情報の詰め込み、クラウド サービス、SaaS、またはオンプレミスリソースへのアクセスを許可する脆弱性があります。
• 追跡されていないアプリケーション アカウントを使用した永続的なアクセス: 敵対者は、個々のアプリ データベースのアンマネージド アカウントを悪用し、資格情報を構成に埋め込み、一元化された失効なしでサイロ化されたシステムへの繰り返し認証によるアクセスを維持します。
• 監視されていない資格情報の使用による検出回避: 敵対者は、盗まれた資格情報を使用して、調整されていないシステム全体の正当なトラフィックを模倣し、断片化された監査ログまたは一元化されていないテレメトリによる検出を回避し、未承認のアクセス ID を遅延させます。

MITRE ATT&CK

• 資格情報アクセス (TA0006) - フィッシング: スピアフィッシング リンク (T1566.001): 偽のログイン ページは、アプリ エンドポイントを模倣して資格情報をキャプチャし、非 SSO システムで一貫性のない TLS を悪用します。
• 資格情報アクセス (TA0006) - セキュリティで保護されていない資格情報: ファイル内の資格情報 (T1552.001): 正しく構成されていない Git リポジトリまたは CI/CD アーティファクト内のプレーンテキスト API キーまたはパスワードが抽出されます。
• 初期アクセス (TA0001) - 有効なアカウント (T1078): 盗まれた資格情報が Azure、SaaS、またはオンプレミス のアプリに対して認証され、非 SSO セットアップで MFA がバイパスされます。
• 永続化 (TA0003) - アカウント操作 (T1098): アンマネージド アプリ アカウントまたは埋め込み資格情報により、取り消しなしでアクセスが繰り返されます。
• 防御回避 (TA0005) - マスカレード (T1036): 盗まれた資格情報は、サイロ化されたシステムでの検出を回避するために正当な API トラフィックを模倣します。

IM-5.1: アプリケーション アクセスにシングル サインオン (SSO) を使用する

シングル サインオンを使用すると、ログインを繰り返すことなく、ユーザーが 1 回認証し、承認されたすべてのリソースにアクセスできるため、パスワードの疲労と資格情報のスプロールが解消されます。 一元化された ID プロバイダーを介した SSO では、多要素認証、条件付きアクセス、統合監査ログなど、一貫したセキュリティ ポリシーがすべてのアプリケーションに適用されます。 SSO を実装する組織は、フィッシングの脆弱性を軽減し、ユーザー エクスペリエンスを簡素化し、アクセス パターンの包括的な可視性を維持しながら、従業員、パートナー、顧客などの多様なユーザー集団をサポートします。

次の方法を使用して、環境全体に SSO を実装します。

• SSO の実装を計画する: SSO を必要とするアプリケーション (クラウド、オンプレミス、顧客向け) と Azure リソースを特定します。 ユーザーをエンタープライズ (従業員)、外部の信頼できる (パートナー)、またはパブリック (顧客) として分類します。 アプリの互換性に基づいてプロトコル (OpenID Connect、SAML 2.0、OAuth 2.0 など) を決定します。

• Microsoft Entra ID で SSO を構成します。 Microsoft Entra ID を活用して 、シングル サインオン (SSO) を使用して顧客向けのワークロード アプリケーションへのアクセスを合理化し、重複するユーザー アカウントを必要としません。 Entra App Registration モジュールにアプリケーションを登録し、必要に応じて SAML メタデータまたは OIDC クライアント ID/シークレットを使用して SSO 設定を構成します。 管理プレーン アクセス用に Azure RBAC ロール (共同作成者など) を割り当てます。

• エンタープライズ ユーザーの SSO を有効にする: Entra Connect を使用してオンプレミスの Active Directory と Entra ID を同期し、企業の資格情報でシームレスな SSO を有効にします。

• 外部パートナーの SSO を構成します。 分散資格情報の検証のために、ID プロバイダーまたは Microsoft Entra 検証済み ID を使用して SSO をサポートするパートナーの外部 ID を構成します。

• パブリック ユーザーに SSO を実装する: 顧客向けアプリには Entra ID B2C を使用し、ユーザーの外部 ID (ソーシャル ネットワーク ID など) に SSO 用のユーザー フローを設定します。

• 条件付きアクセスを使用してアクセスをセキュリティで保護する: 条件付きアクセス ポリシーを作成して、MFA、デバイス コンプライアンス、または場所ベースの規則を適用します。 リスクの高いユーザーに MFA を適用し、Entra ID ガバナンスを使用してアクセスのプロビジョニング/プロビジョニング解除 (請負業者の アクセス パッケージ など) を自動化します。

実装例

シナリオ： 12,000 人の従業員、500 社のパートナー、50,000 人の顧客を持つグローバル製造会社では、セキュリティを強化しながら、75 のアプリケーションにわたって認証を統合し、パスワードの疲労を解消し、ヘルプ デスク チケットを削減する必要があります。

実装手順:

1. エンタープライズ アプリケーションの SAML SSO を構成します。

   • インベントリ 75 のアプリケーション: 45 個の SaaS アプリ (Salesforce、ServiceNow)、20 個のオンプレミス アプリ、10 個のカスタム Azure アプリ
   • Salesforce の SAML 2.0 統合を構成する (Entra ID 属性をマップし、 JIT プロビジョニングを有効にする)
   • Microsoft.Identity.Web SDK を使用してカスタム Azure Web Apps 用に OpenID Connect を設定する
   • Kerberos の制約付き委任を使用して、オンプレミス環境の20個のレガシーアプリケーションにMicrosoft Entra アプリケーション プロキシをデプロイします。

2. パートナー (B2B) の外部 ID を構成します。

   • プロジェクト管理ツールの B2B コラボレーションを介して 500 人のパートナー ユーザーを招待する
   • パートナーが独自の組織の資格情報を使用するためのフェデレーション SSO を有効にする
   • 期限付きプロジェクトへのアクセスを使用してアクセスパッケージを実装する（自動的に期限切れ）
   • テナント間アクセス設定を使用して 5 つの主要なパートナーとテナント間の信頼を確立する

3. 顧客向けに Microsoft Entra 外部 ID を展開する:

   • サポート ポータルにアクセスする 50,000 人の顧客向けに B2C テナントを設定する
   • ソーシャル ID プロバイダー (Microsoft、Google、Facebook) を構成する
   • B2C によって発行されたトークンで OAuth 2.0 を使用して顧客 API を保護する
   • 会社のロゴを含むブランド認証ページ

4. 条件付きアクセスとガバナンスを実装します。

   • リスクベースのポリシーを構成する (リスクの高いユーザーはパスワードの変更と MFA を必要とし、レガシ認証をブロックする)
   • Salesforce、ServiceNow、Workday に対 して SCIM ベースのユーザー プロビジョニングを 有効にする
   • 人事主導のライフサイクルの実装: 4 時間以内の自動プロビジョニング、1 時間以内の自動取り消し
   • パートナーの四半期ごとのアクセス レビューと、機密性の高いアプリの年次認定を確立する

結果：

組織は、従業員、パートナー、顧客にサービスを提供する大規模なアプリケーション ポートフォリオ全体で SSO を正常に有効にし、セキュリティとユーザー エクスペリエンスの両方を大幅に改善しました。 パスワード リセット チケットは大幅に減少し、ユーザーはログイン プロンプトの繰り返しを排除して大幅な生産性を得ました。 資格情報の露出ポイントが減少したため、フィッシングの被害の可能性が大幅に低下しました。 パートナーのオンボーディング時間は、自動アクセス パッケージによって大幅に短縮され、顧客満足は、シームレスなソーシャル ログイン統合によって顕著に増加しました。 最も重要なのは、脆弱なパスワードに関連するセキュリティ インシデントが完全に排除されました。

参照:

• エンタープライズ アプリケーションで SAML シングル サインオンを有効にする - Microsoft Entra ID

重要度レベル

持っている必要があります。

コントロール マッピング

• NIST SP 800-53 Rev.5: IA-2、IA-4、IA-8、AC-2
• PCI-DSS v4: 8.2.1、8.2.2、8.3.1
• CIS コントロール v8.1: 6.3、6.5、12.5
• NIST CSF v2.0: PR。AA-1、PR。AC-1
• ISO 27001:2022: A.5.15、A.5.16
• SOC 2: CC6.1、CC6.2

IM-6: 強力な認証コントロールを使用する

Azure Policy:Azure の組み込みポリシー定義 IM-6 を参照してください。

セキュリティの原則

リソースへのすべてのアクセスに対して、一元化された ID および認証管理システムを使用して、強力でフィッシングに強い認証制御 (強力なパスワードレス認証または多要素認証) を適用します。 パスワード資格情報だけに基づく認証は、安全性が低く、一般的な攻撃方法に耐えないため、レガシと見なされます。

強力な認証を展開する場合は、最初に管理者と特権ユーザーを構成して、強力な認証方法の最高レベルを確保し、その後すぐに適切な強力な認証ポリシーをすべてのユーザーにロールアウトします。

注: レガシ アプリケーションとシナリオに従来のパスワード ベースの認証が必要な場合は、複雑さの要件などのパスワード セキュリティのベスト プラクティスに従ってください。

軽減すべきリスク

• フィッシングまたは傍受による資格情報の侵害: 攻撃者は、フィッシングまたはネットワーク スニッフィングを通じて資格情報をキャプチャし、OAuth フィッシングまたはセッション ハイジャックを悪用してアプリケーションやリソースにアクセスします。
• 脆弱な資格情報または再利用された資格情報: 予測可能なパスワードまたは再利用されたパスワードにより、侵害されたデータベースからのブルート フォース攻撃または資格情報の詰め込みが可能になります。
• コードまたは構成での資格情報の公開: ソース コードまたは構成ファイル内のハードコーディングされた資格情報は、誤った構成または内部エラーによって公開されます。
• 侵害されたアカウントからの不正アクセス: 侵害されたアカウントは、動作の監視が不十分なため、攻撃者にアプリケーションとリソースへの広範なアクセスを提供します。
• アカウントの増殖と孤立したアカウント: 重複もしくは放置されたアカウント (例: 元従業員用のもの) は、攻撃者によって不正利用される可能性があります。
• アプリケーション間で一貫性のないセキュリティ ポリシー: アプリ間でセキュリティ制御 (MFA の欠如など) が異なると、悪用可能な脆弱性が生じます。
• 中間者 (MitM) 攻撃: 攻撃者は認証セッションを傍受して資格情報またはトークンを盗みます。
• Over-Privileged アカウントからの Insider の脅威: 過剰なアクセス許可により、従業員やパートナーによる意図的または偶発的な誤用が許可されます。
• 複数のログイン ポイントを介したソーシャル エンジニアリング: 多数のログイン インターフェイスによって、ユーザーをだまして資格情報を明らかにするための攻撃対象領域が広がります。
• 承認されていない外部アクセス: 管理が不十分な外部 ID (パートナー、顧客など) は、機密性の高いシステムに意図しないアクセス権を取得します。

MITRE ATT&CK

• 資格情報アクセス (TA0006): 正しく構成されていないリポジトリまたは CI/CD パイプラインからソース コードまたは構成ファイル (.env、JSON など) に埋め込まれたプレーンテキスト資格情報 (API キー、パスワードなど) を抽出し、収集された資格情報を使用してクラウドまたはオンプレミスのサービス API に対して認証します。
• 初期アクセス (TA0001): スピア フィッシング (偽のアプリ固有のログイン ページ、T1566.001 など) を介して資格情報をキャプチャしたり、暗号化されていないトラフィックをさまざまなログイン エンドポイントに傍受したりして、一貫性のない TLS 構成を利用して複数のシステムの資格情報を取得します。
• 初期アクセス (TA0001): 調整されていないアプリ全体で脆弱な資格情報または再利用された資格情報を悪用し、ブルート フォース攻撃 (アプリ ログイン API によるパスワード スプレー、T1110.001 など) や資格情報の詰め込みを利用して、クラウド サービス、SaaS、またはオンプレミスのリソースへの不正アクセスを取得します。
• 永続化 (TA0003): 個々のアプリ データベースのアンマネージド アカウントを悪用してアクセスを維持し、構成 (T1098.001) に資格情報を埋め込み、一元化された失効なしでサイロ化されたシステムに対して繰り返し認証します。
• 防御回避 (TA0005): 盗まれた資格情報を使用して、異なるシステム間で正当なトラフィックを模倣する API またはアプリ要求を生成し、断片化された監査ログや一元化されたテレメトリがないために検出 (T1036) を回避します。

IM-6.1: 強力な認証制御を使用する

強力な認証は、フィッシングやブルートフォース攻撃、データベース侵害に対する脆弱性があるパスワードへの依存を排除することで、資格情報ベースの攻撃を防ぎます。 パスワードレス オプション (生体認証、セキュリティ キー、証明書ベースの認証) や多要素認証などの最新の認証方法により、アカウント侵害のリスクが大幅に軽減され、ユーザー エクスペリエンスが向上します。 強力な認証を展開する組織では、高価値のアカウントを保護するために最初に管理者と特権ユーザーに優先順位を付け、その後、強化されたセキュリティ ポリシーを通じてパスワードを必要とする従来のシナリオのサポートを維持しながら、すべてのユーザーに体系的にカバレッジを拡張する必要があります。

次の方法を使用して、強力な認証制御を実装します。

• パスワードレス認証をデプロイする: Windows Hello for Business、Microsoft Authenticator アプリの電話サインイン、passkeys(FIDO2)、証明書ベースの認証の 4 つのオプションを使用して、既定の方法としてパスワードレス認証を使用します。 Microsoft Entra ID では、パスワードレス認証がネイティブにサポートされています。 さらに、お客様はスマート カードなどのオンプレミスの認証方法を使用できます。

• 多要素認証を適用する: サインイン条件とリスク要因に基づいて、すべてのユーザー、ユーザーの選択、またはユーザーごとのレベルで適用できる Azure MFA を 有効にします。 MFA のセットアップに関する Microsoft Defender for Cloud ID とアクセス管理の推奨事項に従います。

• 従来のシナリオでパスワードのセキュリティを維持する: 従来のパスワードベースの認証が Microsoft Entra ID 認証に引き続き使用されている場合は、クラウド専用アカウント (Azure で直接作成されたユーザー アカウント) に既定のベースライン パスワード ポリシーがあり、ハイブリッド アカウント (オンプレミスの Active Directory のユーザー アカウント) がオンプレミスのパスワード ポリシーに従っていることに注意してください。 既定の ID とパスワードを持つサード パーティ製のアプリケーションとサービスの場合は、初期サービスのセットアップ時に無効にするか、変更します。

実装例

シナリオ： 従業員数が 8,000 人のテクノロジ企業は、フィッシングに強いパスワードレス認証を展開することで、パスワードベースの攻撃を排除し、ユーザー エクスペリエンスを向上させる必要があります。

実装手順:

1. Microsoft Entra ID で認証方法を有効にする:

   • Microsoft Entra 管理センター > Protection > 認証方法に移動します
   • すべてのユーザーに対して Windows Hello for Business を有効にする (既定の Windows 10/11 デバイス認証)
   • Passkeys (FIDO2) を有効にし、構成証明の強制を はい に設定します (これにより FIDO Alliance MDS からの検証済みセキュリティキーのみが保証されます)
   • 構成証明を強制して Microsoft Authenticator (プレビュー) でパスキーを有効にする
   • Certificate-Based 認証 (CBA) を有効にして、信頼された証明機関を構成する
   • フォールバック MFA メソッドの構成: Microsoft Authenticator プッシュ通知、OATH トークン (特権ユーザーの SMS/音声を避ける)

2. 認証強度ポリシーを定義します。

   • FIDO2 セキュリティ キーまたは Windows Hello for Business OR Platform SSO または証明書ベースの認証 (多要素) を必要とするカスタム認証強度 "Admin Phishing-Resistant" を作成する
   • 組み込みの "パスワードレス MFA 強度" を標準ユーザーに使用する (Windows Hello、FIDO2、Authenticator パスキー、CBA を含む)
   • レガシ アプリケーション アクセスのフォールバックとして組み込みの "多要素認証強度" を使用する

3. 特権ユーザー (150 管理者) に対してフィッシングに対する耐性のある認証を展開します。

   • クロスプラットフォーム互換性のために、USB-A/C および NFC サポート (YubiKey 5 シリーズ) を使用して FIDO2 セキュリティ キーを購入する
   • すべての管理者にキーを配布し、Microsoft Entra の [セキュリティ情報] ページで登録を通じてそれらをガイドする
   • TPM 2.0 と PIN の複雑さの要件を使用して 100 個の Windows PAW で Windows Hello for Business を構成する
   • 管理者ロール (グローバル管理者、セキュリティ管理者など) を対象とする条件付きアクセス ポリシーを作成する: すべての Azure portal と管理者アプリのアクセスに対して "Admin Phishing-Resistant" 認証強度が必要です
   • 結果: 100% の管理者サインインで、ハードウェアに基づくフィッシングに対する耐性のある方法が使用され、構成証明によって不正なデバイスの登録が防止される

4. エンド ユーザー (7,850 ユーザー) のパスワードレス認証をロールアウトします。

   • Windows ユーザー (6,500): TPM 2.0 または生体認証センサー (指紋、顔認識) を使用して Intune 経由で Windows Hello for Business を展開する
   • モバイル ユーザー (1,200): iOS/Android 用 の Microsoft Authenticator (プレビュー) でパスキー を有効にする
     • iOS: FaceID/TouchID と連携してセキュアエンクレーブを使用するデバイスに紐付けられたパスキー
     • Android: 生体認証で Secure Element または Trusted Execution Environment (TEE) を使用するデバイス バインド パスキー
     • App Attest (iOS) と Play Integrity API (Android) を使用して証明を有効にし、正当な Authenticator アプリを検証する
   • 500 人の IT 部門および財務部門の早期導入者を対象にしたパイロットテスト
   • [ 構成証明の強制] を [はい ] に設定して、デバイス バインドのパスキーのみが登録されるようにします (準拠していないパスキー プロバイダーをブロックします)
   • 標準ユーザーの条件付きアクセス ポリシーを作成する: 企業アプリケーションにアクセスするには"パスワードレス MFA 強度" 認証が必要
   • エッジ ケースへの対処: 生体認証対応デバイスを持たないユーザーが FIDO2 セキュリティ キーを受け取る

5. 特殊なシナリオ用に証明書ベースの認証 (CBA) をデプロイします。

   • PKI 統合を必要とする 100 人の外部請負業者に対して Microsoft Entra 証明書ベースの認証 を構成する
   • 2 年間の有効期間で組織 CA から X.509 証明書を発行する
   • 多要素認証用に CBA 認証バインド ポリシーを構成する: certificatePolicyOid + ユーザー名バインド (強力な MFA) が必要
   • ハードウェア セキュリティ モジュール (スマート カード) またはデバイスのセキュリティで保護されたストレージ (TPM、セキュリティで保護されたエンクレーブ) に証明書を格納する
   • 管理者アクセス権を持つ請負業者の "Admin Phishing-Resistant" 認証強度ポリシーに CBA を含める

6. 認証強度を使用して条件付きアクセス ポリシーを構成します。

   • ポリシー 1 - 管理者保護: Azure portal、Microsoft 365 管理センターに適用→、"Admin Phishing-Resistant" の強度が必要→、すべての管理者ロールを対象にする
   • ポリシー 2 - 標準ユーザー: [すべてのクラウド アプリに適用する] → [パスワードレス MFA 強度] が必要→、すべてのユーザー (管理者を除く) を対象にする
   • ポリシー 3 - レガシ アプリ: パスワードレスをサポートできない特定のレガシ アプリケーションをターゲットにする→ "多要素認証の強度" が必要 (パスワード + Authenticator プッシュ/OTP を許可)
   • ポリシー 4 - 外部アクセス: ターゲット ゲスト/外部ユーザー→ "多要素認証の強度" を最小にする必要があります
   • 条件付きアクセスの分析情報を監視して、認証強度のコンプライアンスとポリシーの有効性を確認する

7. レガシ アプリケーションのサポートとパスワード セキュリティ (15 アプリ):

   • 先進認証をサポートできないアプリケーションを特定する (SAP GUI、パスワードが必要なレガシ VPN)
   • これらのアプリでは、条件付きアクセス (パスワード + Authenticator プッシュ通知/OTP を許可) を介して "多要素認証強度" が必要です。
   • Microsoft 365 の条件付きアクセスを使用してレガシ認証プロトコル (POP3、IMAP、SMTP AUTH) をブロックする
   • 残りのパスワード ユーザーに対してカスタム禁止パスワード リストを使用して Microsoft Entra Password Protection を有効にする
   • 先進認証プロトコル (OAuth 2.0、SAML 2.0) をサポートするレガシ アプリケーションの移行パスを計画する

8. パスワードの削除と回復のメカニズム:

   • 最新のアプリケーションにパスワードレス認証の強度を必要とする条件付きアクセス ポリシーを適用する
   • パスワードレス資格情報を登録したユーザーの 95% のパスワード認証を無効にする
   • アカウントの回復と初期パスワードレス資格情報の登録用に 一時アクセス パス (TAP) を構成する
   • レガシ アプリへのアクセスを必要とするユーザーの 5% のパスワード機能を維持する

9. 監視と継続的な改善:

   • Microsoft Entra 管理センターで認証方法ダッシュボードを監視する
   • メトリックの追跡: 方法別のパスワードレス導入率 (Windows Hello: 81%、Authenticator passkeys: 15%、FIDO2: 2%、CBA: 1%、プラットフォーム SSO: 1%)
   • 条件付きアクセスの分析情報で認証強度コンプライアンスを確認する
   • 使用された認証方法、認証強度の評価、および従来の認証試行のブロックに関するサインイン レポートを監視する
   • 非準拠デバイスを登録しようとするユーザーを特定するために、アテステーション失敗を監査する
   • ベースライン: パスワードレス導入前は月に15件の認証情報侵害アラート
   • ターゲット：パスワードレス化後<2件のアラート/月

結果：

組織は、フィッシングに強い認証方法を使用して、すべての主要プラットフォームで包括的なパスワードレス導入を実現しました。 ハードウェアベースの資格情報 (FIDO2、Windows Hello、Platform SSO、CBA) を使用して特権アカウントの完全なカバレッジを実現し、価値の高いターゲットに対するパスワード ベースのリスクを排除しました。 パスワードレス認証の導入は、プラットフォームネイティブ ソリューション (Windows Hello 81%、Authenticator passkeys 15%、FIDO2 2%、CBA 1%、プラットフォーム SSO 1%) を通じて従業員全体で 95% に達しました。 パスワードベースのセキュリティ インシデントは完全に排除されましたが、フィッシング シミュレーションの失敗率はデプロイ後に 18% から <2% に減少しました。 ヘルプ デスクのパスワード リセット チケットが 87%減少し、認証サポートの年間コストが 340,000 ドル削減されました。 ユーザーは、生体認証方法を使用して 40% 高速認証を行い、合理化されたアクセスによって生産性を向上しました。 認証強度ポリシーにより、細かい適用が保証され、認証方法のダウングレード攻撃が防止され、すべての管理者アクセス シナリオで一貫したフィッシングに対する耐性の要件が維持されます。

参照:

• Microsoft Authenticator でパスキーを有効にする (プレビュー)
• Microsoft Entra 証明書ベースの認証
• 条件付きアクセスでの認証の強度

重要度レベル

持っている必要があります。

コントロール マッピング

• NIST SP 800-53 Rev.5: AC-2、AC-3、IA-2、IA-5、IA-8、IA-11
• PCI-DSS v4: 7.2.1、8.2.1、8.3.1、8.3.2、8.4.2
• CIS コントロール v8.1: 6.3、6.4、6.5
• NIST CSF v2.0: PR。AA-1、PR。AC-1
• ISO 27001:2022: A.5.15、A.5.17、A.5.18
• SOC 2: CC6.1、CC6.2

IM-7: 条件に基づいてリソースへのアクセスを制限する

セキュリティの原則

ゼロ トラスト アクセス モデルの一部として、信頼されたシグナルを明示的に検証して、リソースへのユーザー アクセスを許可または拒否します。 検証するシグナルには、ユーザー アカウントの強力な認証、ユーザー アカウントの行動分析、デバイスの信頼性、ユーザーまたはグループのメンバーシップ、場所などが含まれている必要があります。

軽減すべきリスク

• 過剰な特権を持つ資格情報またはアカウントの特権昇格: 敵対者は、たとえば包括的な管理者アクセス権を持つ共有資格情報またはユーザーアカウントを悪用して、管理エンドポイント（例：REST APIs）へのHTTPリクエストを介し、リソースの作成、削除、ポリシーの変更などの高レベルのクラウドAPI操作を実行します。
• 盗まれた Broad-Scope 資格情報による未承認のアクセス: 敵対者は、管理が不十分なアクセス システムから盗まれた資格情報を使用し、スピアフィッシングまたは誤って構成された公開エンドポイントを通じて取得し、細かいリソース固有の制限がない API キーまたはパスワードを介してクラウド サービスに対する認証を行います。
• 管理されていないアカウントまたは過剰なアカウントを使用した永続的なアクセス: 敵対者は、広範なアクセス許可を持つアンマネージド アカウントを作成または変更し、クラウド構成 (IaC テンプレートなど) に静的な資格情報を埋め込み、一元化されたアクセス許可の失効なしに API 認証を繰り返し使用して永続的なアクセスを維持します。
• 広範な範囲の資格情報の使用による検出回避: 敵対者は、広範なスコープの資格情報を利用して、正当なクラウド トラフィックを模倣する API 要求を生成し、ロール固有の監査証跡が存在しないことや、粗いアクセス制御システムでの詳細な監視のために検出を回避します。
• アクセスが過剰なリソースからの未承認のデータまたは資格情報の収集: 敵対者は、ストレージ バケットや仮想マシンなどのクラウド リソースから機密データまたは資格情報 (API キー、ユーザー データなど) を抽出し、ロールベースの境界がないために制限のない API クエリやファイル アクセスを許可する制限のないアクセス制御を利用します。

MITRE ATT&CK

• 特権エスカレーション (TA0004): 広範なアクセス スコープを持つ特権を超える共有資格情報またはユーザー アカウントを悪用し、制限の緩やかなアクセス制御を悪用して、サービス間で高い特権を持つクラウド API 操作 (リソースの作成、ポリシー変更など) を呼び出します。
• 初期アクセス (TA0001): 粗い管理されたアクセス システムから盗まれた資格情報を利用し、スピア フィッシングまたは誤って構成された公開エンドポイントを使用して、細かい制限がない API キーまたはパスワードを使用して認証します。
• 永続化 (TA0003): 過剰なアクセス許可を持つアンマネージド アカウントを作成または変更してアクセスを維持し、ロールベースの失効なしで繰り返し認証するようにクラウド構成に資格情報を埋め込みます。
• 防御回避 (TA0005): 広範なスコープの資格情報を使用して正当なクラウド API トラフィック (T1036) を模倣し、ロール固有の監査証跡の欠如や監視による検出を回避し、粗いアクセス ログメカニズムをバイパスします。
• コレクション (TA0009): ロールベースのアクセス境界がないため、ストレージまたはインスタンスから API キーまたはユーザー データを抽出するアクセスが過度に制限されているクラウド リソースから機密データまたは資格情報を収集します。

IM-7.1: 条件に基づいてリソース アクセスを制限する

条件付きアクセス ポリシーでは、リソース アクセスを許可する前に複数のシグナルを動的に評価し、静的アクセス許可を超えてコンテキスト対応のアクセス制御に移行することで、ゼロトラスト セキュリティを有効にします。 組織は、条件付きアクセスを実装して、管理アクションの MFA の要求、レガシ認証プロトコルのブロック、機密性の高いアプリケーションの準拠デバイスの管理など、アダプティブ セキュリティ要件を適用します。 これらのポリシーは、セキュリティ要件とユーザーの生産性のバランスを取りながら、認証セッションをきめ細かく制御し、リアルタイムのリスク評価に基づいて適切な保護レベルを確保します。

次の方法を使用して、条件付きアクセス制御を実装します。

• Microsoft Entra 条件付きアクセスを展開する: 特定の IP 範囲 (またはデバイス) からのユーザー ログインに MFA の使用を要求するなど、ユーザー定義の条件に基づいてきめ細かいアクセス制御を行うには、Microsoft Entra 条件付きアクセスを使用します。 Microsoft Entra 条件付きアクセスを使用すると、特定の条件に基づいて組織のアプリにアクセス制御を適用できます。

• 適用可能な条件と条件を定義します。 ワークロードで Microsoft Entra 条件付きアクセスに適用できる条件と条件を定義する場合は、次の一般的なユース ケースを検討してください。

• 管理者ロールに MFA を要求する: 管理ロールを持つユーザーに多要素認証を要求する。

• 管理タスクに MFA を要求する: Azure 管理タスクに多要素認証を要求する。

• レガシ認証プロトコルをブロックする: レガシ認証プロトコルを使用しようとしているユーザーのサインインをブロックします。

• 信頼できる場所を適用する: 多要素認証の登録に信頼できる場所を要求し、特定の場所からのアクセスをブロックまたは許可します。

• 危険なサインイン動作をブロックする: 危険なサインイン動作をブロックします。

• マネージド デバイスが必要です。 特定のアプリケーションに対して組織が管理するデバイスが必要です。

• セッション管理コントロールを実装します。 詳細な認証セッション管理制御は、サインイン頻度や永続的なブラウザー セッションなど、Microsoft Entra 条件付きアクセス ポリシーを使用して実装することもできます。

実装例

シナリオ： 3,500 人の従業員を持つ医療組織では、HIPAA コンプライアンスを確保しながら、150 個の Azure リソースと 45 個のアプリケーションに対するゼロトラスト アクセス制御が必要です。 Role-Based アクセス制御 (RBAC) の基礎を理解することが不可欠です。

実装手順:

1. RBAC ベースラインを確立します。

   • ロール階層の定義: グローバル管理者 (3)、セキュリティ管理者 (8)、アプリケーション管理者 (25)、標準ユーザー (3,464)
   • 医療シナリオ用のカスタム Azure ロールを作成する (PHI データ 閲覧者、臨床アプリケーション管理者、監査レビュー担当者)
   • 適切なスコープでロールを割り当てる (インフラストラクチャのサブスクリプション レベル、アプリケーションのリソース グループ レベル)
   • コンプライアンス追跡のために Microsoft Intune に 4,200 台のデバイスを登録する

2. 8 つの条件付きアクセス ポリシーを展開します。

   • ポリシー 1 - MFA ベースライン: すべてのユーザー、すべてのクラウド アプリに MFA が必要 (サインイン頻度: 8 時間)
   • ポリシー 2 - 特権ロール保護: 管理者には、MFA + 準拠デバイス + 承認済みクライアント アプリ (4 時間セッション) が必要です
   • Policy 3 - Azure Management: portal.azure.com へのアクセスには、MFA + 準拠デバイス + Microsoft Entra ハイブリッド参加が必要です。
   • ポリシー 4 - レガシ認証ブロック: POP3、IMAP、SMTP AUTH をブロックする (6 か月のサンセット プランでは 15 個の一時的な例外)
   • ポリシー 5 - 信頼できる場所: 信頼されていない場所からの PHI アクセスに MFA を要求する。Tor/匿名プロキシをブロックする
   • ポリシー 6 - Risk-Based コントロール: 中/高のサインイン リスクに対して MFA + パスワードの変更を要求する (Entra ID Protection 統合)
   • Policy 7 - マネージド デバイス: SharePoint/Azure Web Apps に準拠またはMicrosoft Entraハイブリッド参加済みデバイスが必要
   • ポリシー 8 - アプリケーション特有のセッション: 金融システムには30分間のセッションが設定され、PHIのダウンロード、コピー、および貼り付けはブロックされます。

3. 継続的アクセス評価 (CAE) を有効にする:

   • ユーザーの無効化、パスワードの変更、または危険度の高い場所への移動時の即時トークン失効
   • 重要なイベントに対して、トークンは 15 分以内に取り消されます。

4. 監視と最適化:

   • 条件付きアクセスの分析情報を毎週確認する (ポリシーへの影響、ユーザー エクスペリエンスのメトリック)
   • 四半期ごとのレビューで 45 個の例外 (緊急時アカウント、レガシシステム) を管理する
   • 利害関係者との月単位のポリシー レビュー会議

結果：

組織は、完全な MFA カバレッジと高度なマネージド デバイス導入を持つすべてのユーザーを対象とした包括的な条件付きアクセス ポリシーを展開しました。 レガシ認証は、ほぼすべての要求に対してブロックされました。ただし、特定のビジネス ニーズに対する例外は限られています。 すべての管理者アカウントで、準拠しているデバイスと組み合わせてフィッシングに強い MFA が必要になりました。 保護された正常性情報への不正アクセスが大幅に減少し、場所ベースの異常が自動的にブロックされ、以前に発生した侵害を防ぐことができます。 組織の HIPAA コンプライアンス スコアは大幅に改善され、セキュリティの成熟度が大幅に向上しました。

参照:

• Azure におけるロールベースアクセス制御の初心者向けガイド

重要度レベル

持っている必要があります。

コントロール マッピング

• NIST SP 800-53 Rev.5: AC-2、AC-3、AC-6、AC-16
• PCI-DSS v4: 7.2.1、7.2.2、7.2.3
• CIS コントロール v8.1: 3.3、6.4、6.8、13.5
• NIST CSF v2.0: PR。AC-1、PR。AC-4、PR。AA-1
• ISO 27001:2022: A.5.15、A.5.18、A.8.2、A.8.3
• SOC 2: CC6.1、CC6.3、CC6.6

IM-8: 資格情報とシークレットの公開を制限する

Azure Policy:Azure の組み込みポリシー定義 IM-8 を参照してください。

セキュリティの原則

アプリケーション開発者が資格情報とシークレットを安全に処理することを確認します。

• コードファイルと構成ファイルに資格情報とシークレットを埋め込むのを避ける
• キー コンテナーまたはセキュリティで保護されたキー ストア サービスを使用して資格情報とシークレットを格納する
• ソース コードで資格情報をスキャンします。

注: これは、多くの場合、セキュリティで保護されたソフトウェア開発ライフサイクル (SDLC) と DevOps セキュリティ プロセスを通じて管理および適用されます。

軽減すべきリスク

• 不正アクセス: プレーンテキスト、コード リポジトリ、またはログの資格情報 (API キー、パスワードなど) を公開すると、攻撃者が機密性の高いシステムやデータにアクセスするために悪用される可能性があります。 たとえば、Azure サービス プリンシパル キーが漏洩すると、攻撃者がストレージ アカウントや仮想マシンにアクセスする可能性があります。
• 特権エスカレーション: 過剰な特権を持つサービス アカウント トークンなどの侵害されたシークレットを使用すると、攻撃者はクラウド環境内でアクセスを昇格し、サブスクリプション全体または重要なリソース (盗まれた Key Vault シークレットを使用して管理機能にアクセスするなど) を制御できる可能性があります。
• データ侵害: データベース接続文字列またはストレージ アカウント キーが公開されると、承認されていないデータ抽出が発生し、顧客レコードや知的財産などの機密情報が公開される可能性があります。多くの場合、公開されている構成ミス (開いている Azure BLOB コンテナーなど) を介して公開されます。
• 横移動: 盗まれた資格情報を使用すると、攻撃者はクラウド リソース間をピボットし、信頼関係や共有シークレットを利用して、侵害された VM から再利用されたトークンを使用して Kubernetes クラスターに移動するなど、追加のシステムにアクセスできます。

MITRE ATT&CK

• 初期アクセス (TA0001): 公開された資格情報 (パブリック リポジトリ内の API キーやサービス プリンシパル トークン、正しく構成されていないストレージなど) の悪用により、攻撃者はクラウド リソース (T1078 - 有効なアカウントなど) への未承認のエントリを取得できます。
• 特権エスカレーション (TA0004): 盗まれた特権を超えるシークレットを使用してアクセスを昇格させ、攻撃者が追加のリソースまたはサブスクリプション (T1078 - 有効なアカウントなど) を制御できるようにします。
• 収集 (TA0009): 公開されているデータベース接続文字列またはストレージ キーを利用して機密データを収集し、クラウド リソース (T1530 - Cloud Storage からのデータなど) からの未承認のデータ抽出を行います。
• 横移動 (TA0008): 再利用されたトークンやサービス アカウントなどの侵害された資格情報を使用してクラウド リソース間でピボットし、相互接続されたシステムまたは仮想ネットワーク (T1021 - リモート サービスなど) にアクセスします。

IM-8.1: ライブ シークレットと資格情報を検出する

プロアクティブ シークレット検出では、攻撃者が検出する前に、ソース コード、構成ファイル、通信ツール、アーカイブされた資料に埋め込まれたライブ シークレットを識別することで、資格情報の公開を防ぎます。 開発パイプライン、インフラストラクチャのデプロイ、ストレージ システム間で継続的なシークレット スキャンを実装している組織は、API キー、接続文字列、認証トークンなどの公開された資格情報を検出して修復します。 CI/CD ワークフローに統合された自動検出により、資格情報の漏洩に迅速に対応でき、公開期間が短縮され、クラウド リソースやサービスへの不正アクセスが防止されます。

次のプラクティスを使用してシークレット検出を実装します。

• Azure DevOps シークレット スキャンを有効にします。 コード管理に Azure DevOps を使用する場合は、コード リポジトリ内の資格情報を識別するために Azure DevOps 資格情報スキャナー を実装します。

• GitHub シークレット スキャンを有効にします。 GitHub リポジトリの場合は、 ネイティブ シークレット スキャン機能を 使用して、コード内の資格情報またはその他の形式のシークレットを識別します。

• エージェントレス シークレットスキャンをデプロイします。 VM、ストレージ、およびマルチクラウド インスタンスでスキャンするエージェントレス シークレットに対して Microsoft Defender for Cloud を有効にして、構成ファイルやソース コード リポジトリ内の接続文字列などのシークレットを検出します。

IM-8.2: シークレットと資格情報を保護する

セキュリティで保護されたシークレット管理は、集中型コンテナー、自動ローテーション、およびアクセス制御を通じて認証情報を保護し、資格情報の盗難や無許可のサービスアクセスを防止します。 Azure Key Vault は、サポートされているサービス、ハードウェア セキュリティ モジュール (HSM) バッキング、および包括的な監査ログに対して、組み込みのローテーション機能を備えたエンタープライズ レベルのシークレット ストレージを提供します。 マネージド ID を介してアクセスされる Key Vault にシークレットを格納する組織は、ハードコーディングされた資格情報を排除し、自動ローテーション ポリシーを実装し、セキュリティ フレームワークへのコンプライアンスを維持しながら、クラウドとハイブリッド環境全体で安全なサービス間認証を有効にします。

次のプラクティスを使用してシークレットと資格情報を保護します。

• Azure Key Vault にシークレットを格納する: マネージド ID がオプションでない場合は、シークレットと資格情報をコードファイルや構成ファイルに埋め込むのではなく、Azure Key Vault などのセキュリティで保護された場所に格納してください。

• シークレットの自動ローテーションを実装します。 Azure Key Vault では、サポートされているサービスの自動ローテーションが提供されます。 自動的にローテーションできないシークレットの場合は、手動で定期的にローテーションされ、使用されなくなったら消去されるようにします。

• マネージド ID を使用して Key Vault にアクセスする: Azure Functions、Azure Apps サービス、VM などのクライアントは、追加の資格情報を格納することなく、マネージド ID を使用して Azure Key Vault に安全にアクセスできます。

実装例

シナリオ： 複数のチームにまたがる開発者が参加する fintech スタートアップでは、パブリック GitHub リポジトリにコミットされた API キーによって顧客データが公開され、規制上の罰金が発生すると、セキュリティ インシデントが発生します。 将来の資格情報の漏洩を防ぐために、包括的なシークレット検出と保護が必要です。

フェーズ 1: シークレット検出 - 資格情報の漏洩を防ぐ (IM-8.1)

1. セキュリティで保護されたアプリケーション ライフサイクルに CredScan を実装します。

   • CredScan を Azure DevOps パイプラインに統合して、一般的なシークレット パターンをスキャンする
   • 重大度の高いシークレットが検出され、運用環境のデプロイがブロックされた場合に失敗するようにパイプラインを構成する
   • 初期スキャンでは、リポジトリ間で公開されているシークレットを識別します (ストレージ キー、SQL 接続文字列、API キー、JWT 署名シークレット)

2. GitHub Advanced Security シークレットのスキャン:

   • すべてのリポジトリで GitHub Advanced Security を有効にする
   • ネイティブ シークレット スキャンを構成して、一般的なトークンの種類とカスタム パターンを検出する
   • プッシュ保護を有効にして、プッシュが完了する前にシークレットを含むコミットをブロックする
   • インシデント対応ワークフローをトリガーするようにアラートを設定する

3. Microsoft Defender for Cloud エージェントレス スキャン:

   • Defender for Cloud for Azure VM、ストレージ アカウント、コンテナー レジストリを有効にする
   • 構成ファイル、コンテナー イメージ、BLOB ストレージをスキャンするエージェントレス シークレットを構成する
   • 実行中の VM、ストレージ アカウント、コンテナー イメージで検出されたシークレットの自動アラートを設定する

4. 履歴リポジトリのスキャン (修復):

   • Gitleaks や TruffleHog などのツールを使用して、公開されているシークレットについて Git 履歴全体をスキャンする
   • 時間の経過と同時にコミット間で公開される資格情報を識別する
   • 修復を実装する: 識別されたすべての資格情報をローテーションし、Git 履歴からシークレットを削除し、開発者を教育する

フェーズ 2: シークレット保護 - 一元化されたボールトとローテーション (IM-8.2)

1. Azure Key Vault のデプロイ:

   • 環境別に 3 つの Key Vault を作成する (運用、ステージング、開発)
   • シークレットの移行: データベース接続文字列、サードパーティの API キー、Azure サービス資格情報、OAuth シークレット、暗号化キー
   • Azure SDK を使用してシークレットを取得するようにマイクロサービスを更新する (.NET 用 Azure.Security.KeyVault.Secrets、Node.jsの @azure/keyvault-secrets 、Python 用 azure-keyvault-secrets)
   • コード、構成ファイル、および CI/CD パイプラインからハードコーディングされたすべてのシークレットを削除する

2. シークレットの自動ローテーション:

   • Azure Storage キー、SQL パスワード、サービス プリンシパル シークレットの自動ローテーションを有効にする
   • サードパーティの API キーとデータベース資格情報のカスタム ローテーションを実装する
   • アプリケーションとオペレーターの最小特権アクセスを使用して Key Vault RBAC を構成する
   • 異常なアクセス パターンの監査ログとアラートを有効にする

3. 開発者ワークフローとインシデント対応:

   • トレーニングの更新、コード テンプレートの提供、シークレット検出のための事前コミット フックの適用
   • パイプライン シークレットを Key Vault 参照に置き換え、サービス接続にマネージド ID を使用する
   • 明確なエスカレーション パスとローテーション手順を使用してインシデント対応プレイブックを定義する

4. 継続的な監視:

   • Key Vault の外部にシークレットが存在しないことを確認するための通常のシークレット スプロール スキャン
   • シークレット情報の有効期限とローテーションコンプライアンスのダッシュボード追跡
   • 定期的な侵入テストとセキュリティ監査

結果：

組織は、公開されているすべての資格情報をコードベースとインフラストラクチャ全体で正常に識別し、修復しました。 ハードコーディングされたシークレットは、Azure Key Vault への包括的な移行により、運用コードから完全に削除されました。 シークレットの自動ローテーションにより、手動によるオーバーヘッドと人的エラーが大幅に削減され、潜在的な資格情報リークに対する検出と応答が大幅に高速化されました。 この実装により、資格情報の公開によるセキュリティ インシデントがゼロになり、合理化されたシークレット管理ワークフローによる開発者の生産性が向上し、SOC 2 や PCI-DSS 標準を含むすべてのセキュリティ監査要件への完全なコンプライアンスが実現しました。

参照:

• セキュリティで保護されたアプリケーション ライフサイクル - パート 1 - CredScan の使用
• Azure Key Vault を使用してシークレットを管理する
• Key Vault でのシークレットローテーションの自動化

重要度レベル

持っている必要があります。

コントロール マッピング

• NIST SP 800-53 Rev.5: IA-5、SI-4、RA-5、SC-12、SC-13、SC-28
• PCI-DSS v4: 3.5.1、6.3.2、8.2.1、8.3.2
• CIS コントロール v8.1: 16.9、16.10、16.12
• NIST CSF v2.0: DE。CM-8、PR。DS-1、PR。AC-1
• ISO 27001:2022: A.5.15、A.8.3、A.8.24
• SOC 2: CC6.1、CC6.6、CC7.2