読メモ：Microsoft Incident Response lessons on preventing cloud identity compromise - Part 2 -

2024年12月20日 11:21

Part 1 ではありがちな設定不備について言及していますので、Part 2 では引き続きそれに対する対策（設定）をまとめていきます。狙われる可能性がある項目が多くてしんどくなってくると思いますので、お探しの情報のみ確認いただくのがよろしいかと思います。時間があれば AzureHound の使い方を記事にできればと考えています。

１．ハイブリッドIDが正しく構成されていない場合

侵害された Active Directory フェデレーションサービスまたは同等のフェデレーション ID システム

Microsoft の推奨は、AD FS その他のフェデレーション ID プロバイダーの利用を停止すること。引き続き利用が必要な場合は以下のような点を考慮する。
・Microsoft Entra Connect health がインストールされていること。このクライアントは、AD FS からの複数のイベントを関連付け、その情報を使用した Microsoft Entra ID サインインデータを提供する。これは、検出ルールと脅威ハンティングルールの作成に役立ち、侵害が発生した場合のフォレンジックデータの貴重なソースとして有用。AD FS に適切なログが出力されること、またそれらのログが SIEM へ連携され、検出ルールを作成できること。攻撃者が AD FS からトークン署名証明書を盗むことができる場合、攻撃者は独自のトークンを偽造して Entra ID に認証でき、さらに、偽造トークンを使用してサインインすると、リスクイベントが発生する可能性がある。現在の MFA ソリューションが AD FS に統合されている場合は、Entra ID で使用できるネイティブの統合 MFA (特にフィッシングに強い) オプションを使用する。
・Microsoft Defender for Identity および Microsoft Defender for Endpoint を有効化している場合は、エージェントが AD FS にデプロイされていること。いずれもサーバー攻撃の検知に役立つ。
・他のフェデレーション ID プロバイダーの場合は、それらのサービスがベストプラクティスに沿って構成されていること、およびユーザーログオンテレメトリとシステムレベルの監査イベントの両方が中央の SIEM に送信されることを確認する。

複雑なIDシステム

IDプレーンを形成するすべてのシステムと、それらの間で認証と承認がどのように流れるかを理解すること。どのシステムが ID トラストチェーン内のどのワークロードを担当しているかを理解する。
認証システム全体を階層 0 として扱う。
ID プレーンを形成するすべてのシステムについて、十分なログ記録が利用可能であり、データが長期間 (できれば 2 年以上) 保持されていること。ログには、ユーザーログオンイベント、管理アクティビティ、および構成の変更を含める。十分なログ記録を持つことは、潜在的なサイバー攻撃を検出するのに役立つだけでなく、全体的なセキュリティ体制を低下させる可能性のある個々のシステムへの変更を警告することもでき、インシデントが発生した場合にはフォレンジック情報のソースとして利用できる。
可能な場合は、環境内の認証および承認メカニズムをシンプルにする。これにより、ID 侵害の攻撃対象領域を減らすことができます。システムが追加されるたびに、それらのシステムを保護するためのオーバーヘッドが増加し、そのうちの 1 つの構成ミスや侵害の可能性が高くなる。

侵害された同期アカウント

Microsoft Entra ID の管理に使用するアカウントは、マネージド認証を使用した Microsoft Entra ID にネイティブなアカウントを推奨、オンプレミスの Active Directory から同期しないこと。脅威アクターが同じ資格情報を利用してMicrosoft Entra IDを侵害するのを防げるため、Active Directory が侵害された場合の侵害の範囲が縮小される。オンプレミスのサイバー攻撃からMicrosoft 365を保護するための具体的なガイダンスについては、https://aka.ms/protectm365 と https://aka.ms/securitysteps を参照。
オンプレミスの Active Directory で特権を持つアカウント (ドメイン管理者やドメイン管理者などのそれぞれのグループなど) は、Microsoft Entra ID への同期から完全に除外する。
Microsoft Entra ID および Active Directory とやり取りするサービスアカウントの資格情報を安全に保管する。
特権アカウントは、ネットワークの場所に関係なく、Microsoft Entra 条件付きアクセスポリシーから除外しないこと。これらのアカウントは、常に最高水準のセキュリティ、特に Privileged Identity Management と FIDO2 などのフィッシングに強い資格情報 (非常用アカウントを含む) を使用することを推奨。
オンプレミスの Active Directory と Microsoft Entra ID の両方に対する特権を必要とするサービスアカウントには、承認されていない場所や IP アドレスからのアクセスをブロックする条件付きアクセス、特定の検出ルール、これらのアカウントでの異常なアクティビティを警告する監視などが必須。

２．高い特権を持つ管理者トークンの保護

FIDO2キーや証明書ベースの認証など、フィッシングに強い MFA 方法を使用すること。認証強度を検討する。
直接的なフィッシングの攻撃可能性を排除するために、Microsoft Entra ID で特権を保持しているユーザーに、メールボックスを割り当てない。
Microsoft Entra ID にアクセスして管理タスクを完了する場合は、オンプレミスの Active Directory から同期されたアカウントではなく、ネイティブの Microsoft Entra アカウントを使用してアクセスを許可する。
Microsoft Entra ID ポータルやその他の同様の管理インターフェイスへのアクセスも、特権アクセスワークステーションと呼ばれる強化されたワークステーションのみに制限する。これらのワークステーションは、Microsoft Entra ID のみを管理するように設計されており、エンドポイント侵害の攻撃対象領域を減らすために他のサイトへのアクセスが制限されている。
Microsoft が公開している、クラウドトークンの盗難に関する特定のインシデント対応プレイブックを理解しておく。
トークンの盗難をより広範に防止するため、条件付きアクセスのトークン保護 (より一般的にはトークンバインディングとも呼ばれます)を検討する。トークン保護は、発行されたトークンを特定のデバイスにバインドすることで、プライマリ更新トークンの盗難のリプレイを防止する。

３．過剰な特権を持つアカウントの保護

現在のロールの割り当てを監査して、特権ユーザーに必要なアクセス権のみが付与されていることを確認すること。Microsoft が特権と見なすロールは、ドキュメントと Microsoft Entra ポータル上で強調表示され、これらのロールでユーザーを管理することの重要性が強調されています。
テナントレベルの侵害につながる可能性のあるすべてのロール (グローバル管理者だけでなく) が保護されていることを確認する。
BloodHound のクラウド兄弟である AzureHound は、Microsoft Entra ID を介して攻撃パスを視覚的にマッピングするために使用可能。このツールを使用して認可された監査を実行し、攻撃パスを削除または軽減することを推奨。
Microsoft Entra PIM で、ユーザーが Just-In-Time で高度なアクセス権限を利用できるようにすることで、これらのロールをさらに保護できます。

４．ワークロードIDに付与された過剰な特権の見直し

アプリケーションとサービスプリンシパルには、最小特権の原則を使用してアクセス権を付与する必要がある。多くの場合、内部の開発チームや外部のサードパーティベンダーは、必要な権限以上の権限を要求するが、これには重大なリスクがあるため、必要最低限の権限の付与にとどめること。
クライアントシークレットではなく、証明書などの強力な資格情報をアプリケーションに使用することを推奨。アプリケーションが Microsoft Azure またはその他の Microsoft サービスと対話している場合は、Entra ID マネージド ID を使用すること。マネージド ID を使用することで、組織がこれらのワークロードの資格情報を管理する必要がなくなる。
Microsoft Graph へのアクセスを提供する場合は、さまざまなエンドポイントに対して非常に詳細なアクセス権限が提供されているので、権限のリファレンスページにはを参考に、権限を計画すること。
Active Directory に精通し、Microsoft Entra ID にはあまり詳しくないセキュリティチームと管理者でも、Microsoft Entra ID と Microsoft Graph のアクセス許可構造の仕組みを理解すること。そうすることで、過剰な特権の要求を棄却することができる。
ワークロード ID の条件付きアクセスは、Microsoft Entra ワークロード ID の機能として使用可能。前述のように、これらの ID の性質上、MFA や同様の制御を適用することはできませんが、特定の IP の場所からのアクセスを許可したり、Microsoft によって検出されたリスクの高いパターンに基づいてアクセスをブロックすることが可能。
新しい資格情報、既存のアプリケーションに追加される追加の特権、および異常なサインインアクティビティを検出するアラートを構成すること。ユーザーと同様に、サービスプリンシパルはログインデータを生成し、新しい IP アドレスまたは場所の検出を作成すること。脅威アクターによって、高い権限を持つ既存のアプリケーションで新しい資格情報を生成するためのアクセス権を持つアカウントを侵害し、テナントを乗っ取る試みを阻止する。

５．デバイスのアクセス制御の問題

エンドユーザーが自分のデバイスを Microsoft Entra テナントに登録または参加できるようにする場合、条件付きアクセスを組み合わせて登録を完了するように計画すること。
条件付きアクセスを使用すると、デバイスの参加時または登録時に MFA を要求するポリシーを作成することで、テナントにセキュリティを追加できる。ビジネスの要件に応じて、特定のユーザーや信頼できない場所などの場所に限定して MFA 要件を適用することもできる。
監査とアラートの機能で、ユーザーが複数のデバイスを登録している、疑わしいデバイス名、異常な時間などの異常な動作を検出するために、デバイス参加イベントに対して構成する。ユーザー自身は、デバイスがアカウントを介して登録されるたびに、Intune 経由で通知できます。アクションが開始されていない場合は、不審なアクションとして報告できます。
Intune 管理者ロールのメンバーを、グローバル管理者などのよく知られた特権ロールと同じセキュリティ標準に構成する。

６．アプリケーションのアクセス制御の問題

ビジネスアプリケーションへのアクセスは、それを必要とするユーザーだけに制限されること。Microsoft Entra ID には、アプリケーションへのアクセスを制限する機能と、MyApps ポータルでのアプリケーションの表示を非表示にする機能の両方が用意されている。アプリケーションへのアクセスは、常にセキュリティグループによって管理され、ユーザーには作業に必要なアクセス権のみが付与されるようにする。

Entra ID のアクセスレビューとエンタイトルメント管理機能は、組織がアクセスとエンタイトルメントのライフサイクルの継続的なガバナンスを大規模に管理するのに有効。これらのツールが連携して、ユーザーが必要なアプリケーションやデータに簡単にアクセスできるようにし、セキュリティチームに必要に応じて情報を提供する。

７．委任された管理特権のアクセス許可の問題

テナント内の委任された管理特権の一覧を定期的に確認し、ビジネスでパートナーがテナントの特権を保持する必要があるかどうかを再評価する。
特権が必要な場合は、詳細な委任された管理者特権 (GDAP) の利用を推奨。
パートナー関係の性質によっては、委任されたパートナー構成を完全に削除し、代わりにテナントにネイティブなオンボードアカウントを作成し、テナントへのアクセスを必要とする任意のリソースに資格情報を安全に提供できる場合がある。

８．条件付きアクセスポリシーの見直し

多くの場合、条件付きアクセスの除外を適用する必要がある場合はあるが、特権アカウントとTier 0アカウントの保護は継続的な監視が必要。
アラートは、条件付きアクセスに対する変更、追加、または削除に対して構成すること。ポリシーに対する偶発的な変更と悪意のある変更の両方を検出する。
ポリシーの除外グループとして構成されているグループについては、変更の継続的な監視が必要。Microsoft Entra ID アクセスレビューを使用することで、これらのグループのメンバーの継続的なガバナンスを確保可能。
企業ネットワーク経由で接続する場合でも、場所に関係なくユーザーに強力な認証を適用することを推奨。
条件付きアクセスポリシーを定期的に確認し、想定される制御が適用されていることを継続的に確認すること。これを支援するために、「What If」ツールを使用してサインインイベントをシミュレートできます。また、条件付きアクセスには分析情報とレポートが組み込まれており、これを利用したポリシーのギャップの特定と対処も継続的に実施すること。

９．OAuth と同意フィッシングの対策

Microsoft Entra ID は、同意フィッシングやその他の悪意のあるアプリケーションの同意から組織を保護するため「ユーザーの同意の構成」という機能を提供しており、Microsoft では、1 番目または 2 番目のオプションを選択することを推奨している。組織のすべてのアプリケーション同意要求に効果的に対応できる場合は、最初のオプションである [ユーザーの同意を許可しない] が最も安全。
多くの組織には、すべてのリクエストを管理するリソースがありません。このような場合、2 番目のオプションは、セキュリティとユーザーエクスペリエンスの最適な組み合わせを考慮し、スタッフは、検証済みの発行元からのアプリケーション、または要求されたアクセス許可の点で影響が少ないと見なされるアプリケーションに同意することになる。
危険な OAuth アプリがある場合は。Microsoft Defender for Cloud Apps を使用して調査して修復できます。
前述のように、特権ユーザーにはメールボックスを割り当てないこと。

１０．セルフパスワードリセットとMFAソーシャルエンジニアリング

SSPR は資格情報のリセットに推奨される方法であり、資格情報をクリアテキストで電子メールで送信するなどの他の方法よりも安全ですが、それでもソーシャルエンジニアリングの影響を受けやすい。
SSPRとMFAの詳細の更新リクエストは、電話でユーザーと会話したり、脅威アクターが持っていない他の詳細(従業員ID番号など)を確認させたりするなどして、それらが正当であることを確認するために検証する必要があり、さらに、ビデオ通話を通じて、ユーザーが本人であることを視覚的に確認することも、強力な手助けとなる。
MFA登録は、一時アクセスパス(TAP)を使用してさらに保護できます。TAPは、ユーザー向けに生成できる期間限定のパスコードです。より成熟した組織は、MFA登録プロセスを保護するためにこれらを使用し始めています。ユーザーはヘルプデスクに電話して、身元を確認します。その後、TAPが付与され、MFA登録ポータルに短時間アクセスでき、その後、自分のMFAデバイスを登録できるようになります。
他の特権ユーザーのパスワードや MFA の詳細を更新する権限を持つ IT 管理者スタッフが、フィッシングに強い MFA などの高いセキュリティ基準を守っていることを確認します。
検出は、SSPR と MFA の潜在的なソーシャルエンジニアリングの試行に対して作成する必要があります。これには、SSPR の詳細の更新とそれに続く危険なサインインなどの検出が含まれる場合があります。アカウントを制御している脅威アクターは、そのアカウントにサインインしようとする可能性が高く、別の場所からのものである場合や、その他のなじみのない機能がある場合は、追加のリスクを引き起こす可能性があります。

参照元：クラウド ID の侵害を防ぐための Microsoft インシデント対応のレッスン |Microsoft セキュリティブログ