Merge pull request #933 from jennie7pm/main

reviewed and merged by chkoide

articles/azure-active-directory/effective-strategies-for-conducting-mass-password-resets-during-cybersecurity-incidents.md

@@ -0,0 +1,86 @@
+---
+title: "サイバーセキュリティ インシデント発生時にパスワードの一括リセットを実施するための効果的な戦略"
+date: 2024-07-12 09:00
+tags:
+    - Microsoft Entra
+    - US Identity Blog
+---
+
+# サイバーセキュリティ インシデント発生時にパスワードの一括リセットを実施するための効果的な戦略
+
+こんにちは、Azure Identity サポート チームの 夏木 です。
+
+本記事は、2024 年 6 月 11 日に米国の Microsoft Entra (Azure AD) Blog で公開された [Effective strategies for conducting Mass Password Resets during cybersecurity incidents](https://techcommunity.microsoft.com/t5/microsoft-security-experts-blog/effective-strategies-for-conducting-mass-password-resets-during/ba-p/4159408) の抄訳です。ご不明点等ございましたらサポート チームまでお問い合わせください。
+
+----
+
+サイバー インシデントの最中で、特定のアカウントが侵害されたことが分かっているが、脅威アクターによる影響の全貌は把握できていないという状況を想定してみましょう。[Microsoft インシデント応答](https://www.microsoft.com/ja-jp/security/business/microsoft-incident-response) が推奨する方法の一つとして、パスワードの一括リセットがあります。これにより、ID プレーンを再び制御し、他のアクセス経路を遮断し、攻撃者が環境内に確立した持続性を妨害することができます。しかし、特に大規模な組織においては、パスワードの一括リセットを実行することは複雑な作業となります。このブログ記事では、パスワードの一括リセットを実行する際の実践的な課題、実行のための準備方法、およびベストプラクティスについて説明します。
+
+## パスワードの一括リセットの必要性の識別
+
+パスワードの一括リセットは常に必要とは限りませんが、必要な状況を識別することが重要です。以下のような状況では、パスワードの一括リセットが最良の選択となります:
+
+- **Active Directory データベースの流出**: 脅威アクターによる Active Directory Domain Services (AD DS) データベースの流出の形跡がある場合。
+- **Active Directory データベースのステージング**: 脅威アクターが AD DS データベースを流出させる意図でステージングしている形跡がある場合。
+- **特権 ID の侵害**: 脅威アクターがドメイン管理者、エンタープライズ管理者、組み込みの管理者などの特権 [グループ](https://learn.microsoft.com/ja-jp/windows-server/identity/ad-ds/plan/security-best-practices/appendix-b--privileged-accounts-and-groups-in-active-directory#built-in-privileged-accounts-and-groups) に属する資格情報を侵害した場合。
+- **中間者攻撃**: 中間者攻撃 (Attacker-in-the-Middle: AiTM) やその他の脅威アクターによるプロキシ サービスの導入があり、ユーザーの資格情報が収集された形跡がある場合。
+- **クラウドまたはサードパーティ ID プラットフォームの侵害**: [Microsoft Entra Connect](https://learn.microsoft.com/ja-jp/entra/identity/hybrid/connect/whatis-azure-ad-connect) 、AD FS、RADIUS (Remote Authentication Dial In User Service) サーバー、またはサードパーティの ID ソリューションなどの権威ある ID プラットフォームの侵害の形跡がある場合。
+- **ランサムウェアの展開**: 脅威アクターが特権を持つ AD グループに属するアカウントを侵害してランサムウェアを展開した場合。
+- **ビジネスメール詐欺 (BEC) による特権資格情報の暴露**: BEC により特権資格情報がメールで暴露された場合。
+- **流出したデータ内の特権資格情報の暴露**: OneDrive や SharePoint などのコラボレーションツールから流出したデータ内に特権資格情報が含まれている場合。
+- **コード内の特権資格情報の暴露**: オンライン コードやソース管理リポジトリで特権資格情報が公開された場合。
+- **国家や高度標的型攻撃 (APT) による攻撃**: 攻撃が APT や国家に起因すると判断された場合。
+
+## 組織的な課題とシナリオ
+
+ほとんどの組織にはリモート ユーザーがいます。多くの組織にはハイブリッド ユーザーがおり、完全にリモートワークの組織もあります。これにより、組織ごとにパスワードの一括リセットが必要となる状況や考慮事項が異なります。このセクションでは、これらの要件について考察し、必要に応じて組織がどのように準備し対応すべきかを検討します。考慮すべきシナリオは以下のとおりです:
+
+- **ローカル ユーザー**: 主にドメイン コントローラーを見渡せる場所にいるユーザー。
+- **リモート ユーザー**: VPN (仮想プライベート ネットワーク) を主に使用するユーザー、またはハイブリッド ID を持つユーザー。
+- **管理コントロール**: パスワード リセットを管理者が行うか、エンドユーザーが行うか。
+- **サービス アカウント管理**: パスワードが期限切れにならないサービス アカウントに関する考慮事項。
+- **特権 ID**: クラウドおよびオンプレミスの特権アカウント管理に関する特別な考慮事項。
+
+### ドメイン コントローラーに直接アクセスできるオンサイト ユーザー
+
+このシナリオは最もシンプルです。すべてのユーザーが主にオンサイトでドメイン コントローラーを見渡せる場所にいる場合、ユーザー アカウントに「次回ログオン時にパスワードを変更する」というフラグを設定するだけでパスワード変更を強制できます。ユーザーに期限を設け、その期限までにパスワードを変更するよう通知し、変更しない場合はアカウントが無効化されることを通知します。特定の組織単位 (OUs) のユーザーを列挙し、「次回ログオン時にパスワードを変更する」フラグを操作するための PowerShell スクリプトがオンラインで提供されており、組織のヘルプデスクが混乱しないように段階的なパスワード リセットの展開を支援します。ユーザーがオフィスに到着しログオンを試みると、パスワード変更を促すメッセージが表示されます。
+
+Fine Grained Password Policies (FGPP) を使用してパスワードの有効期限を段階的に短縮することや、ドメイン ポリシーの変更を通じてパスワードの有効期限を短縮することによる段階的かつ迅速なパスワード リセットも代替方法として検討できます。ただし、このアプローチの大きな欠点は、パスワード リセットがログオン イベントをトリガーするまで、脅威アクターが認証済みセッション内に留まる可能性があることです。この方法を検討する際には、資格情報の変更の緊急性とユーザーに猶予期間を与える必要性のバランスを取ることが重要です。多くの組織では従業員の一部がリモートで業務を行っているため、この方法は通常、さまざまなシナリオですべてのユーザー アカウントを保護するための広範な一連の手順の一部として採用されます。
+
+### 環境にアクセスするために VPN を使用するリモート ユーザー
+
+このシナリオは、ユーザーが主にリモートであるか、リモートとオンサイトのユーザーが混在している場合によくみられます。このシナリオでは、ユーザーはドメイン パスワードとは別の認証メカニズム (例: 証明書ベースの認証) に依存しています。ユーザーが VPN ソリューションを使用して認証されると、ドメイン コントローラーを見渡せるため、前述のシナリオと同様に扱うことができます。
+
+リモート ユーザーに対する重要な考慮事項は、管理者がユーザーの資格情報をリセットし、ユーザーが [セルフサービス パスワード リセット](https://learn.microsoft.com/ja-jp/entra/identity/authentication/concept-sspr-howitworks) (SSPR) を使用してアクセスを再取得することによる、管理されたパスワード リセットを実行するか、ユーザーが自分でスムーズに資格情報を変更することを許可するかです。
+
+VPN ソリューションがドメイン パスワードを認証の主な要素として使用し、サインイン フロー中のパスワード リセットをサポートしていない場合、このシナリオはより困難になります。このようなシナリオでは、インシデント発生前に組織が [SSPR を設定](https://learn.microsoft.com/ja-jp/entra/identity/authentication/concept-sspr-deploy) していれば、パスワード リセットの手順ははるかに容易になります。SSPR の機能を持たない組織では、パスワードの一括リセットには手動の介入が必要です。この場合は、ユーザーがヘルプデスクに電話するか、このために設定された一元化された場所に出向いて音声やビデオ、または対面で本人確認を行い、その後パスワードを手動でリセットするという形を取ることを検討できます。
+
+また、VPN ソリューションがサインイン フロー中のパスワード リセットをサポートしていない場合は、VPN ソリューションの認証ソースを [Microsoft Entra ID](https://www.microsoft.com/ja-jp/security/business/microsoft-entra) に移行してパスワード リセットでセッションを一時的に中断できるようにするか、条件付きアクセス ポリシーなどの付加的な恩恵を受けるために永続的に Microsoft Entra ID に移行することをご検討ください。
+
+### 主にリモートでハイブリッド (オンプレミス) ID を持つユーザー
+
+ハイブリッド ID を持つ場合、組織の ID (ユーザーおよびコンピューター) は既に [Microsoft Entra ID](https://www.microsoft.com/ja-jp/security/business/identity-access/microsoft-entra-id) と同期されています。このシナリオでは、パスワードの一括リセットを調整するためにドメイン コントローラーを見渡す必要はありません。[Microsoft Entra ID](https://www.microsoft.com/ja-jp/security/business/identity-access/microsoft-entra-id) は、オンプレミスの Active Directory と同様に、ユーザーが次回サインイン時に資格情報をリセットするようにフラグを立てることをサポートしています。
+
+管理者は Microsoft Graph を使用してユーザー属性を「forceChangePasswordNextSignIn」または「forceChangePasswordNextSignInWithMfa」に設定し、次回サインイン時にユーザーのパスワードをスムーズに変更できるようにすることができます。パスワード ライトバック機能が Microsoft Entra ID で有効になっており、組織のユーザーが SSPR を有効にしている場合、MyAccount ポータルまたは SSPR ポータルを介してパスワードをリセットすることで、新しくリセットされたパスワードがオンプレミスに同期されます。パスワード ライトバックおよび SSPR が既に有効になっている場合、これは脅威アクターの排除を最速で実現し、手動作業を最も少なくするシナリオです。ただし、組織によっては SSPR を使用したくない場合もあり、これについては後述します。
+
+### サービス アカウントの考慮事項
+
+サービス アカウントは、期限が切れないパスワードと過剰に特権を持つ性質のため、Active Directory 管理者にとって頭痛の種となります。特に、パスワードの一括リセットを実行しなければならない場合、サービス アカウントに関連するサービスやアプリケーションをマッピングする目録がほとんどない場合は特に問題です。すべてのサービス アカウントとそれに関連するサービスやアプリケーションを目録として整理する必要があります。可能な場合は、サービス アカウントを [グループの管理されたサービス アカウント (gMSA)](https://learn.microsoft.com/ja-jp/windows-server/security/group-managed-service-accounts/group-managed-service-accounts-overview) に移行することを検討してください。これにより、サービス アカウントの管理が容易になり、手動のオーバーヘッドが削減されます。また、サービス アカウントの特権を「適正化」する絶好の機会でもあります。
+
+### 特権 ID の考慮事項
+
+すべての特権クラウド アカウントには、フィッシング耐性のある MFA (多要素認証) を導入すべきです。また、Just in Time (JIT) による管理（例: [Microsoft Entra ID](https://www.microsoft.com/ja-jp/security/business/identity-access/microsoft-entra-id) の [特権 ID 管理 (PIM)](https://learn.microsoft.com/ja-jp/entra/id-governance/privileged-identity-management/pim-configure)）を使用することを強く推奨します。さらに、オンプレミスとクラウドの管理を明確に分離し、各領域に対して別々の ID を使用する必要があります。特権を持つオンプレミスの AD DS グループに属する ID は、[Microsoft Entra ID](https://www.microsoft.com/ja-jp/security/business/identity-access/microsoft-entra-id) と同期しないようにする必要があります。逆に、すべてのクラウドの特権ロールはクラウド ネイティブ ID によって保持され、AD DS から同期されないようにする必要があります。ほとんどの組織では、高度な保証と制御のために、特権資格情報を手動でリセットすることを選択します。パスワードのリセットがいつ行われたかを PowerShell や Microsoft Graph で確認することが重要です。そうしなければ、一部のアカウントが見落とされる可能性が非常に高くなります。
+
+## パスワードの一括リセットの保証と制御に関する考慮事項
+
+これまでの説明のように、パスワードの一括リセットを必要とするシナリオは複数あります。これは、組織がパスワードの一括リセットを実行する際に必要な制御や保証のレベルが異なることを意味します。[SSPR](https://learn.microsoft.com/ja-jp/entra/identity/authentication/tutorial-enable-sspr) メカニズムが信頼性を持って保証を提供できる場合、組織はその機能を使用してパスワードの一括リセットを加速することができます。
+
+一方で、組織が既存の SSPR ソリューションを使用したくない状況もあります。たとえば、高度な脅威アクターが組織の SSPR システムを悪用した場合や、AD DS データベースの流出の実証がある場合です。そのようなシナリオでは、脅威アクターが SSPR を介して初期アクセスや持続性を再確立する可能性があるため、組織はそのメカニズムを使用してパスワードの一括リセットを強制することを選択しないでしょう。
+
+組織がパスワードの一括リセットに対して高度な保証と制御を求める場合、残念ながら手動の介入が不可避となります。しかし、事前の準備を行うことで、[Microsoft Entra ID](https://www.microsoft.com/ja-jp/security/business/identity-access/microsoft-entra-id) の一時アクセス パスなどの機能を条件付きアクセス ポリシーと組み合わせることで、保証と制御の一部を自動化することが可能です。いずれにせよ、高度な保証と制御が必要な場合、ユーザーの物理的な ID を確認し、そのような一時アクセス パスを発行するためのある程度の手動の介入は避けられません。このブログ記事の続編では、これを実現するために使用できる [Microsoft Entra ID](https://www.microsoft.com/ja-jp/security/business/identity-access/microsoft-entra-id) のさまざまな機能について検討します。
+
+## 結論と次のステップ
+
+パスワードの一括リセットにはいくつか変わりやすい点や考慮事項があり、万能の解決策はありません。しかし、十分な準備を行うことで、このプロセスを組織にとってより負担が少なく、管理しやすいものにすることができます。
+
+インシデント対応能力を向上させるための専門的なガイダンスやカスタマイズされたソリューションについては、Microsoft インシデント応答の他のブログを参照することをおすすめします。さらに、高度な ID およびアクセス管理を提供する [Microsoft Entra ID](https://www.microsoft.com/ja-jp/security/business/identity-access/microsoft-entra-id) の利点を検討し、ID 関連の侵害に対する防御を強化してください。