クラウド内のサービス プロバイダーの信頼チェーンを調査する方法

news

最近のMicrosoft ブログの投稿で、ダウンストリームの顧客テナントへのアクセスを取得する方法として、ダウンストリームの顧客テナントで特権を持つテクノロジ サービス プロバイダーを標的とすることが判明した最新の NOBELIUM 活動から組織を保護するための技術ガイダンスを文書化しました。トラスト チェーン内の他の組織。

Microsoft Detection and Response Team (DART) は、世界中の複数の組織が NOBELIUM の活動の影響を調査するのを支援してきました。 NOBELIUM の最近の活動に関連するインシデントへの対応を支援するために、影響を受けたお客様とはすでに直接やり取りを行っていますが、このブログの目的は、一般的で基本的な質問に答えるのに役立つことです。私が被害者の場合、攻撃者は何をしたのでしょうか?自分の環境の制御を取り戻し、この脅威アクターが自分の環境へのアクセスを取り戻すのをより困難にするにはどうすればよいですか?

このブログでは、脅威アクターとは関係なく、インシデント対応者がこれらの委任された管理者権限の潜在的な悪用を調査するために実行できる手順について概説します。このブログでは、次の内容について説明します。

  • Microsoft 365 と Microsoft Azure での信頼チェーンの識別。
  • トラスト チェーンの調査。
  • 悪意のあるアクティビティの軽減。
  • 推奨事項: 検出して保護します。

Microsoft 365 と Microsoft Azure での信頼チェーンの特定

Microsoft 365 と Microsoft Azure には、委任管理特権 (DAP)、Azure 管理者代理 (AOBO)、Microsoft Azure Active Directory (Azure AD) 企業間 (B2B) など、いくつかの種類の信頼チェーンが存在します。 、マルチテナント Azure AD アプリケーション、およびゲスト ユーザー。これらの信頼チェーンの多くは、Azure リソースと Microsoft 365 への高レベルのアクセスを許可できるため、綿密な監視が必要です。

委任された管理権限

DAP は、ローカル ID を維持する必要なく、サービス プロバイダーが Microsoft 365 環境を管理できる方法です。 DAP は、サービス プロバイダーが独自の ID とセキュリティ ポリシーを使用してダウンストリーム テナントを管理できるため、サービス プロバイダーとエンド カスタマーの両方にとって有益です。委任された管理権限およびその他の代理管理者のシナリオに関する詳細については、次のリソースを参照してください。

DAP を使用するサービス プロバイダーは、 Microsoft 365 管理センター[設定]に移動し、[パートナー関係] に移動して特定できます。 [パートナー関係] ウィンドウでは、テナントとの請求関係を確立したすべてのサービス プロバイダーの一覧と、サービス プロバイダーに役割が割り当てられているかどうかを表示できます (図 1 を参照)。

Microsoft 365 管理センターのパートナー関係ページ。

図 1. DAP をダウンストリーム カスタマーとして識別する。

エンド カスタマーは、エンド カスタマー テナントに管理上の変更を加えることができるサービス プロバイダーのテナント内のすべてのユーザーのリストを表示することはできませんが、 Azure Active Directory サインイン ログを表示することで、サービス プロバイダーによるログインを表示できます (図 2 を参照)。サービス プロバイダークロス テナント アクセス タイプのフィルタリング。 [ダウンロード] をクリックして結果をエクスポートし、Azure と Microsoft 365 全体でトリアージをさらに対象にするために活用できます。

Azure Active Directory のサービス プロバイダー別に並べ替えられたサインオン ログ

図 2. サービス プロバイダーによるサインイン。

Azure AOBO

Azure AOBO は本質的に DAP に似ていますが、アクセスの範囲は、個々の Azure サブスクリプションとリソースに対する Azure Resource Manager (ARM) ロールの割り当て、および Azure Key Vault アクセス ポリシーに限定されます。 Azure AOBO は、DAP と同様の管理上の利点をもたらします。

注: サブスクリプションの AOBO 権限を完全に評価するには、各テナントのすべてのサブスクリプションへのサービス プロバイダー アクセスを評価するグローバル管理者にアクセス権を付与していることを確認してください。テナント ルート グループでユーザー アクセス管理者に昇格する方法の詳細については、ドキュメントを参照してください。

Azure AOBO アクセスは、サブスクリプションの作成時に追加され、特定の Azure サブスクリプションの [アクセス制御 (IAM)]の下に表示されます (図 3 を参照)。

Azure サブスクリプションの [ロールの割り当て] タブで選択された外部プリンシパル。

図 3. サブスクリプションで所有者ロールを持つ外部プリンシパル。

複数のサブスクリプションがある場合は、次のコマンドを実行して、サービス プロバイダーがリソースにアクセスできるサブスクリプションを特定することを検討してください。

Get-AzSubscription % { Set-AzContext -Subscription $_; Get-AzRoleAssignment -Scope "/subscriptions/$($_.Id)" Where-Object {$_.DisplayName -like "Foreign Principal for * in Role 'TenantAdmins' (*)"} Select DisplayName, Scope Format-Table}

CSP に Key Vault への直接アクセスを許可することもできます。次の PowerShell コマンドを使用して、AOBO 経由のアクセスを許可するアクセス ポリシーで Key Vault を識別できます。

Get-AzKeyVault % { $vault = Get-AzKeyVault -VaultName $_.VaultName; if ($vault.AccessPolicies Where-Object {$_.DisplayName -like "Foreign Principal for '*' in role 'TenantAdmins' (*)"}) { $vault |select VaultName,ResourceId Format-Table}}

大規模な環境では、上記のコマンドに加えて、 Azure Red Team ツールの Stormspotterも使用できます。

前の手順で収集された情報は、トリアージ中にログ レビューのスコープを設定するために使用されます。

Azure AD B2B

Azure AD B2B アカウント (ゲスト) を使用して、Azure および Microsoft 365 リソースを管理できます。この管理アクセスの方法は、別のテナントの個々の既存の ID を活用しますが、ID の制御に制限があるため、Microsoft では通常推奨されていません。調査担当者は、ゲストが Microsoft 365 のリソースへのアクセスを許可される多くの方法に注意する必要があります。これには、Exchange Online の役割や SharePoint Online の役割が含まれる場合があります。この種類の ID のガイダンスは網羅的ではなく、特に Azure AD と Azure に焦点を当てていると見なす必要があります。詳細については、 Azure AD B2B のベスト プラクティスに関するドキュメントを参照してください。

Azure サブスクリプション

サブスクリプションの B2B アクセス許可を完全に評価するには、次のガイダンスに従って、各テナントのすべてのサブスクリプションへのサービス プロバイダー アクセスを評価するユーザーにアクセス権を付与していることを確認してください: すべての Azure サブスクリプションと管理グループを管理するためのアクセスを昇格します。

Azure ロールが付与された Azure AD B2B ID は、Azure Portal の [アクセス制御] ブレードに(Guest)と共に表示されます (図 4 を参照)。

Azure サブスクリプションの [ロールの割り当て] タブで、Joe Fabrikam という名前がゲスト ユーザーとして選択されています。

図 4. サブスクリプションで所有者ロールを持つゲスト ユーザー。

Azure AD B2B ID は、次のコマンドを使用して体系的に識別できます。これにより、最初のトリアージを対象とするために使用できる ID とリソースのリストが生成されます。

Get-AzSubscription % { Set-AzContext -Subscription $_; Get-AzRoleAssignment -Scope "/subscriptions/$($_.Id)" Where-Object {$_.SignInName -like "*#EXT#@*"} Select DisplayName, SignInName, Scope Format-Table}

Microsoft 365 (Azure AD)

Azure AD でロールが付与された Azure AD B2B ID は、Azure AD Privileged Identity Management ブレードの割り当てブレードで表示できます。 「#EXT#」でフィルタリングすると、管理ロールに割り当てられたすべてのゲスト ユーザーを表示できます (図 5 を参照)。

Joe Fabrikam という名前が、Azure AD Privileged Identity Management ブレードのすべてのアクティブな割り当ての下にリストされているゲスト ユーザーとして選択されています。

図 5. ゲスト ユーザーのフィルタリング。

次の PowerShell を使用して、管理者ロールを持つゲスト アカウントを識別することもできます。この識別情報は、ターゲットのトリアージを支援するために使用されます。

Get-AzureADDirectoryRole Get-AzureADDirectoryRoleMember Where-Object {$_.UserPrincipalName -like "*#EXT#@*"}

トラストチェーンの調査

Microsoft 365 と Microsoft Azure には、Azure AD 監査ログ、Azure アクティビティ ログ、Intune 監査ログ、統合監査ログなど、信頼チェーンを介したアクティビティを確認できる観測点が複数あります。 「識別」フェーズで収集されたデータを使用して、ログの対象を絞ったレビューを実行し、トラスト チェーンの悪用を特定できます。各ログは、トラスト チェーンに由来するアクティビティを確認する必要があります。特に、永続性、データ収集、および偵察を容易にするアクティビティに焦点を当てています。

テナント侵害の 12 の指標: メールボックス通知、トランスポート ルール/電子メール転送、管理者の昇格/サインイン、ユーザー/グループ/ゲストの変更、リスク イベント アクティビティ、対象ユーザーの特性、新規/異常な IP アドレス、ドメインの変更/追加、アラート閉鎖、アプリケーションの変更、e Discovery アクティビティ、およびファイル/アクセス アクティビティ。

図 6. テナント侵害の兆候。

アズール AD

多くの場合、攻撃者は、新しいサービス プリンシパルの作成、既存のアプリケーション登録への新しいシークレットの追加、サービス プリンシパル、新しい特権ユーザーの作成、既存の特権アカウントの乗っ取りなど、さまざまな方法を使用して永続性を確立します。 Azure AD 監査ログを確認し、”識別” フェーズで最近サインインしたと識別されたユーザーをフィルター処理することで、信頼チェーンを介して Azure AD に加えられた変更を識別することができます。関心のある特定の活動:

  • パスワードがリセットされます。
  • サービス プリンシパルの変更。
  • 特権ロールへのユーザーの追加。
  • 多要素認証 (MFA) への変更。
  • 新しいユーザーの作成。

統合監査ログ

統合監査ログを使用して、SharePoint Online、Exchange Online、Azure AD、およびその他の Microsoft 365 製品で信頼チェーンを介して実行されたアクティビティを特定できます。

統合監査ログは、Azure AD と Office 365 全体からデータを取り込み、このデータを少なくとも 90 日間保持することに注意してください。これにより、通常、ソース (たとえば、Azure AD最大 30 日間のデータのみが保持されます)。 E5 ライセンスが適用されている場合、このデータは 1 年間保持され、 Advanced Auditを使用して構成可能な最大保持期間は 10 年間です。

Search-UnifiedAuditLogコマンドレットを使用して、「識別」フェーズで識別されたユーザーによって実行されたアクションを検索できます。または、 Microsoft 365 Defenderポータルの GUI を使用してログを検索することもできます。

紺碧の活動

悪意のあるアクターが Azure リソースにアクセスすると、データを盗み出し、標的の Azure 環境に接続されている他の環境に横方向に移動できます。サブスクリプションにアクセスできるアクターは、新しいリソースをデプロイしたり、仮想マシン拡張機能を介して既存のリソースにアクセスしたり、Azure サブスクリプションから直接データやキーを盗んだりすることができます。 Azure リソースのアクセスと操作は、各サブスクリプションに存在する Azure アクティビティ ログを確認することで監査できます。 Microsoft Sentinel クエリを使用して関心のある領域を特定する方法については、ブログ投稿Microsoft Sentinel を使用した Azure アクティビティの調査を参照してください。

Microsoft エンドポイント マネージャー

悪意のあるアクターがさまざまな信頼チェーンを介して Microsoft エンドポイント マネージャーにアクセスする可能性があります。Microsoft エンドポイント マネージャーはデバイスの構成を管理するため、これも重要な監査ログです。 Microsoft エンドポイント マネージャーの監査ログには、Microsoft エンドポイント マネージャー ポータルの [テナント管理]ブレードからアクセスできます。監査ログでは、開始者である「パートナー」を使用して、パートナーによって開始されたアクションをフィルタリングできます。 「識別」フェーズで特権を持っていると識別されたゲスト ユーザーが実行するアクションは、ユーザー プリンシパル名で検索する必要があります。これらのログ イベントを確認して、特定された信頼チェーンを介して悪意のあるアクティビティが発生していないことを確認する必要があります。

Microsoft エンドポイント マネージャー管理センターの監査ログのパートナーの種類に関連付けられている詳細。

図 7. パートナーによって開始されたアクション。

悪意のある活動の軽減

調査中に悪意のあるアクティビティが発見されて確認された場合、または不要で過度に寛容な信頼チェーンが発見された場合は、アクセスをブロックまたは最小限に抑えるための断固たる措置を講じる必要があります。信頼チェーンの種類によっては、アクセスをブロックするためにさまざまな手順を実行する必要がある場合があります。進行中の調査が終了するまでアーティファクトを完全に削除することはお勧めしません。特定のアーティファクトを削除すると、調査の完了が遅れたり、困難になったりする可能性があります。お客様は、サービス プロバイダーと話し合って、どのような保護が実施されているかを理解する必要があります。潜在的な悪意のあるアクティビティが発生した場合は、サービス プロバイダーに通知して、アクティビティの検証に関する支援を受けてください。

委任された管理者権限

サービス プロバイダーによるテナントのアクティブな日常管理に DAP が必要ない場合は、DAP を削除する必要があります。場合によっては、サービス プロバイダーによる管理を容易にするためにアクセス許可が必要になります。このような場合、Microsoft はきめ細かな委任管理者特権 (GDAP) を導入します。これにより、パートナーは顧客のワークロードへのアクセスをよりきめ細かく期限付きで制御できるようになります。

サービス プロバイダーは、顧客テナントの名前付きアカウントを活用して、爆発の範囲とリスクを軽減することをお勧めします。サービス プロバイダーとの関係に起因する侵害の証拠がある場合は、少なくとも調査が終了するまで、関係から委任された管理者権限を削除することをお勧めします。

委任された管理者特権を削除するには、 Microsoft 365 管理センター[設定]に移動してから、[パートナー関係] に移動します。 [パートナー関係] ウィンドウで関係をクリックし、詳細ウィンドウで [ロールの削除] を選択します。このアクションを実行すると、サービス プロバイダーはグローバル管理者またはヘルプデスク管理者としてテナントにアクセスできなくなります。このアクセス権を削除しても、サービス プロバイダーを通じて現在購入されている請求関係やライセンスは変更されません。

Azure AOBO

Azure サブスクリプションのアクティブな日常管理に必要ない場合は、Azure AOBO アクセスを削除する必要があります。サービス プロバイダーが Azure サブスクリプションへのアクセスを必要とする場合は、適切なロールとアクセス許可を持つ外部プリンシパルを追加して、最小限の特権を適用する必要があります。サービス プロバイダーに起因する侵害の証拠がある場合は、すべての Azure サブスクリプションから外部グループ プリンシパルを削除する必要があります。

AOBO を介して付与されたアクセス許可は、 Azure Policyを利用して監視できます。外部プリンシパルに Azure のリソースへのアクセス許可が割り当てられている場合、コンプライアンス違反をスローする Azure Policy をテナント ルート グループにデプロイできます。 Azure Policy は、外部プリンシパルを使用したサブスクリプションの作成をブロックすることはできませんが、それらの存在に関するレポートを簡素化し、必要に応じてそれらの削除または作成の防止を自動化できます。

影響を受けるサブスクリプションの [アクセス制御 (IAM)]ブレードに移動し、サービス プロバイダーの外部プリンシパルを選択して、[削除] を押すと、Azure AOBO のアクセス許可を削除できます。

Azure サブスクリプションの [アクセス制御] セクションで Azure A O B O アクセス許可を削除するために [削除] ボタンで選択された外部プリンシパル。

図 8. 外部プリンシパルに対する Azure AOBO 権限の削除。

外部プリンシパルは、必要に応じて、最小限の特権のベスト プラクティスに従って、より具体的なアクセス許可を追加して戻すことができます。

推奨事項

探知

ロギングを一元的に利用できることは、潜在的なインシデントに対応して調査するために重要であり、この種の DART 調査の最大の障害となっています。組織が特権アクセスと管理上の変更についてクラウド環境を監視している場合、委任された管理者特権の悪用を伴う悪意のある活動を発見して警告する必要があります。

クラウド アクティビティ ログは、セキュリティ情報およびイベント マネージャー (SIEM) に取り込み、分析のために保持する必要があります。これには以下を含める必要があります。

  • Office 365 統合監査ログ。
  • Azure AD 管理者の監査ログとサインイン ログ。
  • Microsoft エンドポイント マネージャーの監査ログ。
  • Azure アクティビティ ログと特定のデータ プレーン ログ (Azure Key Vault や Storage Azure Policy など) を活用して、一貫したログ標準を適用できます。

インシデント レスポンダーとしての DART は、量と質の両方が豊富なデータが利用可能な場合に最も効果を発揮します。関心のあるログの種類の 1 つは、サインイン ログです。 ID イベントは、アクターの活動について多くのことを教えてくれます。多くの場合、これらのログでパターンを特定して、攻撃者の活動の分析に自信を持たせることができます。これらのパターンは、IP アドレスの一致のように単純なものから、UserAgent 文字列、時刻、およびアプリケーション ID の一致のように複雑なものまであります。

そうは言っても、最も重要なログは管理アクティビティのログです。管理アカウントの使用または実行されるアクションは非常に重要であり、監視して競合を解消する必要があります。エンタープライズ環境では、ほとんどの変更は通常、承認された変更期間中に行われます。これ以外の変更は、その有効性と整合性について評価する必要があります。

ログ自体も便利ですが、異常なアクティビティや悪意のあるアクティビティをタイムリーに発見するにはアラートが不可欠です。 Microsoft 365 Defender ポータルには、疑わしいアクティビティを特定するための便利なアラートが組み込まれています。これらのいくつかの例は次のとおりです。

  • Exchange 管理者特権の昇格。
  • 電子情報開示検索が開始またはエクスポートされました。
  • 転送ルールまたはリダイレクト ルールの作成。

カスタム アラートを作成して、他の種類のアクティビティを警告することもできます。アラート用のもう 1 つの優れたツールは、Microsoft Defender for Cloud Apps (以前の Microsoft Cloud App Security) です。このツールは、Azure AD、Office 365、Azure、Defender for Endpoint、Defender for Identity、および多くのサードパーティ サービスからデータを取り込むことができます。ポリシー エンジンを使用して、組み込みのテンプレートまたはカスタム定義に基づいてアラート ポリシーを作成できます。テンプレート化されたポリシーの例を次に示します。

  • 企業以外の IP アドレスからの管理活動。
  • 異常な管理活動 (ユーザーによる)。
  • OAuth アプリケーションへの異常な資格情報の追加。
  • 疑わしい OAuth アプリケーション ファイルのダウンロード アクティビティ。
  • 複数の仮想マシン作成アクティビティ。

守る

お客様には、定期的にサービス プロバイダーと対話して、テナントへのアクセスのために実施されているセキュリティ制御を理解することをお勧めします。サービス プロバイダーによるリソースへのアクセスは綿密に監視する必要があり、一定期間使用されていない場合は、強力な最小限の特権プロセスに従って削除する必要があります。

Microsoft 365 Security Center の Microsoft Secure Score および Microsoft Defender for Cloudの Secure Score と組み合わせてセキュリティ体制を改善するためのガイダンスについては、 Microsoft Security Best PracticesAzure Security Benchmarkを確認してください。

管理アクセスを保護するための具体的な例には、 Privileged Identity Managementなどのジャストインタイムの管理ソリューションの使用が含まれます。これには、アクセスが引き続き必要であることを確認するための管理者の定期的なレビューが含まれます。 MFA も重要であり、MFA を有効にするだけでなく、すべての管理者が MFA メソッドを登録していることを確認することも重要です。 DART は、脅威アクターが、MFA が有効になっているが登録されていないアカウントを見つけたことを確認しました。これにより、脅威アクターは自身の MFA の詳細を登録できるようになり、環境に対する信頼のレベルが上がります。

もっと詳しく知る

Microsoft セキュリティ ソリューションの詳細については、 当社の Web サイト を参照してくださいセキュリティ ブログをブックマークして、セキュリティに関する専門家の記事を入手してください。また、 @MSFTSecurityをフォローして、サイバーセキュリティに関する最新ニュースと更新情報を入手してください。

参照: https://www.microsoft.com/en-us/security/blog/2021/11/22/how-to-investigate-service-provider-trust-chains-in-the-cloud/

Comments

タイトルとURLをコピーしました