こんにちは、Azure Identity サポート チームの 夏木 です。
本記事は、2024 年 6 月 11 日に米国の Microsoft Entra (Azure AD) Blog で公開された Effective strategies for conducting Mass Password Resets during cybersecurity incidents の抄訳です。ご不明点等ございましたらサポート チームまでお問い合わせください。
サイバー セキュリティのインシデントが起こり、特定のアカウントが侵害されたことが分かっているが、攻撃者による影響の全貌は把握できていないという状況を想定してみましょう。Microsoft インシデント レスポンス が推奨する方法の一つとして、パスワードの一括リセットがあります。これにより、ID を再度コントロール下に置くとともに、他のアクセス経路を遮断して、攻撃者が環境内で継続して活動できないようにします。しかし、特に大規模な組織においては、パスワードの一括リセットを実行することは複雑な作業となります。このブログ記事では、パスワードの一括リセットを実行する際の実践的な課題、実行のための準備方法、およびベスト プラクティスについて説明します。
パスワードの一括リセットが必要かの判断
パスワードの一括リセットは常に必要とは限りませんが、それが必要な状況がいつかを理解しておくことが重要です。以下のような状況では、パスワードの一括リセットが最良の選択となります:
- Active Directory データベースの流出: 攻撃者により Active Directory Domain Services (AD DS) データベースの流出の形跡がある場合。
- Active Directory データベースの流出に向けた準備段階: 攻撃者が AD DS データベースを流出させようと準備している形跡がある場合。
- 特権 ID の侵害: 攻撃者がドメイン管理者、エンタープライズ管理者、組み込みの管理者などの特権 グループ をもつ資格情報を侵害した場合。
- 中間者攻撃: 中間者攻撃 (Attacker-in-the-Middle: AiTM) や、攻撃者によりその他の中継サービスが仕込まれており、ユーザーの資格情報が収集された形跡がある場合。
- クラウドまたはサードパーティ ID プラットフォームの侵害: Microsoft Entra Connect 、AD FS、RADIUS (Remote Authentication Dial In User Service) サーバー、またはサードパーティの ID ソリューションなどのコアとなる ID プラットフォームの侵害の形跡がある場合。
- ランサムウェアの展開: 特権を持つ AD グループのメンバーであるアカウントを攻撃者が侵害してランサムウェアを展開した場合。
- ビジネス E メール詐欺 (BEC) による特権資格情報の漏洩: BEC により特権資格情報が E メールで漏洩された場合。
- 流出したデータ内の特権資格情報の漏洩: OneDrive や SharePoint などのコラボレーション ツールから流出したデータ内に特権資格情報が含まれている場合。
- コード内の特権資格情報の漏洩: オンライン上のコードやソース管理リポジトリで特権資格情報が公開された場合。
- 国家や高度標的型攻撃 (APT) による攻撃: 攻撃が APT や国家に起因すると判断された場合。
組織的な課題とシナリオ
ほとんどの組織にはリモート ユーザーがいます。多くの組織にはハイブリッド ユーザーもおり、完全にリモートワークの組織もあります。これにより、組織ごとにパスワードの一括リセットが必要となる状況や考慮事項が異なります。このセクションでは、これらの要件について考察し、必要に応じて組織がどのように準備し対応すべきかを検討します。考慮すべきシナリオは以下のとおりです:
- ローカル ユーザー: 主にドメイン コントローラーに直接通信できる場所にいるユーザー。
- リモート ユーザー: VPN (仮想プライベート ネットワーク) を主に使用するユーザー、またはハイブリッド ID を持つユーザー。
- 管理者による制御: パスワード リセットを管理者が行うか、エンドユーザーが行うか。
- サービス アカウントの管理: パスワードが期限切れにならないサービス アカウントに関する考慮事項。
- 特権 ID: クラウドおよびオンプレミスの特権アカウント管理に関する特別な考慮事項。
ドメイン コントローラーに直接アクセスできるオンサイトのユーザー
このシナリオは最もシンプルです。すべてのユーザーが主にオンサイトでドメイン コントローラーと直接通信できる場所にいる場合、ユーザー アカウントに「次回ログオン時にパスワードを変更する」というフラグを設定するだけでパスワード変更を強制できます。ユーザーに期限を設け、その期限までにパスワードを変更するよう通知し、変更しない場合はアカウントが無効化されることを通知します。特定の組織単位 (OU) のユーザーを列挙し、「次回ログオン時にパスワードを変更する」フラグを操作するための PowerShell スクリプトがオンラインで提供されており、組織のヘルプデスクが混乱しないように段階的にパスワード リセットの展開が可能です。ユーザーがオフィスに到着しログオンを試みると、パスワード変更を促すメッセージが表示されます。
Fine Grained Password Policies (FGPP) を使用してパスワードの有効期限を段階的に短縮することや、ドメイン ポリシーの変更を通じてパスワードの有効期限を短縮することによる段階的かつ迅速なパスワード リセットも代替方法として検討できます。ただし、このアプローチの大きな欠点は、パスワード リセットがログオン イベントをトリガーするまで、攻撃者が認証済みセッションを引き続き悪用できる可能性があることです。この方法を検討する際には、資格情報の変更の緊急性とユーザーに猶予期間を与える必要性のバランスを取ることが重要です。多くの組織では従業員の一部がリモートで業務を行っているため、さまざまなシナリオですべてのユーザー アカウントを保護するための手順の一部として、こういった方法も採用を検討ください。
環境にアクセスするために VPN を使用するリモート ユーザー
このシナリオは、ユーザーが主にリモートであるか、リモートとオンサイトのユーザーが混在している場合によくみられます。このシナリオでは、ユーザーはドメイン パスワードとは別の認証メカニズム (例: 証明書ベースの認証) に依存しています。ユーザーが VPN ソリューションを使用して認証されると、ドメイン コントローラーと通信が可能になるため、前述のシナリオと同様に扱うことができます。
リモート ユーザーに対する重要な考慮事項は、管理者主体のパスワード リセットを実行する (管理者がユーザーの資格情報をリセットし、ユーザーは セルフサービス パスワード リセット (SSPR) を使用する) か、ユーザーに自分で資格情報を変更させるかです。
VPN ソリューションがドメイン パスワードを認証の主な要素として使用し、サインイン フロー中のパスワード リセットをサポートしていない場合、このシナリオは実現が困難になります。このようなシナリオでは、インシデント発生前に組織が SSPR を設定 していれば、パスワード リセットの手順ははるかに容易になります。SSPR の機能を持たない組織では、パスワードの一括リセットには手動での対応が必要です。この場合は、ユーザーがヘルプデスクに電話するか、特定の場所に出向いて音声やビデオ、または対面で本人確認を行い、その後パスワードを手動でリセットするという形を取ります。
また、VPN ソリューションがサインイン フロー中のパスワード リセットをサポートしていない場合は、VPN ソリューションの認証元を一時的に Microsoft Entra ID に移行してパスワード リセットでセッションを中断するようにするか、永続的に Microsoft Entra ID に移行して条件付きアクセス ポリシーなどの恩恵を得ることもご検討ください。
主にリモートでハイブリッド (オンプレミス) ID を持つユーザー
ハイブリッド ID を持つ場合、組織の ID (ユーザーおよびコンピューター) は既に Microsoft Entra ID と同期されています。このシナリオでは、パスワードの一括リセットを行うためにドメイン コントローラーに直接通信できる必要はありません。Microsoft Entra ID は、オンプレミスの Active Directory と同様に、ユーザーが次回サインイン時に資格情報をリセットするようにフラグを立てられます。
管理者は Microsoft Graph を使用してユーザー属性を「forceChangePasswordNextSignIn」または「forceChangePasswordNextSignInWithMfa」に設定し、次回サインイン時にユーザーのパスワードをスムーズに変更できるようにすることができます。パスワード ライトバック機能が Microsoft Entra ID で有効になっており、組織のユーザーが SSPR を利用可能な状況の場合、MyAccount ポータルまたは SSPR ポータルを介してパスワードをリセットすることで、新しくリセットされたパスワードがオンプレミスに同期されます。パスワード ライトバックおよび SSPR が既に有効になっていれば、攻撃者を最も早く、最小限の作業で排除できるシナリオになります。ただし、組織によっては SSPR を使用したくない場合もあり、これについては後述します。
サービス アカウントの考慮事項
サービス アカウントはパスワードが無期限であり、過剰に権限を持つ性質があるため、Active Directory 管理者にとって頭痛の種となりがちです。特に問題となるのが、パスワードの一括リセットを実行しなければならない場合に、サービス アカウントに関連するサービスやアプリケーションをマッピングする情報がほとんどない場合です。このため、すべてのサービス アカウントとそれに関連するサービスやアプリケーションを棚卸して整理する必要があります。可能な場合は、サービス アカウントを グループで管理されたサービス アカウント (gMSA) に移行することを検討ください。これにより、サービス アカウントの管理が容易になり、手動で行う負担が削減されます。また、サービス アカウントの特権を「適正化」する絶好の機会でもあります。
特権 ID の考慮事項
すべての特権クラウド アカウントには、フィッシング耐性のある MFA (多要素認証) を導入すべきです。また、Just in Time (JIT) による管理（例: Microsoft Entra ID の 特権 ID 管理 (PIM)）を使用することを強く推奨します。さらに、オンプレミスとクラウドの管理を明確に分離し、各領域に対して別々の ID を使用する必要があります。特権を持つオンプレミスの AD DS グループに属する ID は、Microsoft Entra ID と同期しないようにする必要があります。逆に、すべてのクラウドの特権ロールはクラウド上にだけ存在する ID によって保持し、AD DS から同期されないようにする必要があります。ほとんどの組織では、より高いセキュリティを実現するため、特権資格情報を手動でリセットすることが一般的です。パスワードのリセットがいつ行われたかを PowerShell や Microsoft Graph で確認することが重要です。このようにして確認しない場合は、一部のアカウントが見落とされる可能性が非常に高くなります。
パスワードの一括リセットにおける保証 (Assurance) と制御 (Control) の考慮事項
これまでの説明のように、パスワードの一括リセットを必要とするシナリオは複数あります。これは、組織がパスワードの一括リセットを実行する際に必要な保証 (Assurance) と制御 (Control) のレベルが異なることを意味します。SSPR の仕組みを活用することで必要な保証レベルを確保できる場合、その機能を使用してパスワードの一括リセットを迅速に行うことができます。
一方で、組織が既存の SSPR ソリューションを使用したくない状況もあります。たとえば、高度な攻撃者が組織の SSPR システムを悪用した場合や、AD DS データベースの流出の証拠がある場合です。このようなシナリオでは、攻撃者が SSPR を介して初回アクセスを実現したり、環境に持続的にアクセスしたりする可能性があるため、組織は SSPR を使用してパスワードの一括リセットを強制するということは行わないでしょう。
組織がパスワードの一括リセットに対して高度なレベルの保証と制御を求める場合、残念ながら手動の介入が不可避となります。しかし、事前の準備を行うことで、Microsoft Entra ID の一時アクセス パスなどの機能を条件付きアクセス ポリシーと組み合わせることで、保証と制御の一部を自動化することが可能です。いずれにせよ、高度な保証と制御が必要な場合、ユーザーの物理的な ID を確認して一時アクセス パスを発行するというようなある程度の手動の介入は避けられません。このブログ記事の続編では、これを実現するために使用できる Microsoft Entra ID のさまざまな機能について検討してまいります。
結論と次のステップ
パスワードの一括リセットにはいくつか変わりやすい点や考慮事項があり、万能の解決策はありません。しかし、十分な準備を行うことで、このプロセスを組織にとってより負担が少なく、管理しやすいものにすることができます。
インシデントの対応能力を向上させるための専門的なガイダンスやカスタマイズされたソリューションについては、Microsoft インシデント レスポンスの他のブログを参照することをおすすめします。さらに、高度な ID およびアクセス管理を提供する Microsoft Entra ID の機能を検討し、ID 関連の侵害に対する防御を強化ください。
※本情報の内容（添付文書、リンク先などを含む）は、作成日時点でのものであり、予告なく変更される場合があります。