脆弱性に対しセキュリティ強化を一気に進めると「認証拒否」が発生し、結果、情報システムの利用不可といった障害につながる場合があります。そのため、セキュリティ強化を複数のフェーズに分けて、段階的に進めることが重要になります。本稿では、複数のフェーズを持つActive Directoryの脆弱性対策を紹介します。
この記事は会員限定です。会員登録(無料)すると全てご覧いただけます。
Microsoftの「Active Directory」に関して、複数のフェーズを持つ脆弱(ぜいじゃく)性対策(もしくは更新プログラムの適用)は大きく分けて3種類に分類できます。
本稿では日本マイクロソフトの公式ブログ「Microsoft Japan Windows Technology Support Blog」を出典元として、特に認証に影響があり、かつ複数の適用フェーズを持つ更新プログラムの有無を確認してまとめました。また、個々のKB(Knowledge Base)番号や脆弱性番号も出典元にリンクしてあります。
なお、上記の公式ブログでは、脆弱性が複数のKB番号の場合と、単一のKB番号に集約できる場合の説明パターンがあります。そのため、本稿では、脆弱性番号とKB番号を織り交ぜて表記することになり、分かりにくい部分が出てくることがあることをご了承ください。
KerberosのPACフィールドに影響する脆弱性は、Kerberos認証で使われる「Ticket Granting Ticket」(TGT)や「サービスチケット」に含まれる「PACフィールド」を悪用するものです。
Kerberosのチケットはおおよそ7日間使えることから、このような複数フェーズの対策を採っていると考えられます。
この種類の脆弱性は、3種類あります。新しい順に紹介します。
この2つの脆弱性の詳細については、KB5037754に記載があります。これを示したのが以下の図になります。
上図を踏まえ、各フェーズを要約します。
互換フェーズでは、脆弱性である「特権の昇格」を防ぐ準備として、更新されていないデバイスを識別するために監査イベントがイベントログに出力されます。
ただし、この動作を有効化するには、Active Directoryドメインコントローラー、クライアントとしてのWindowsおよびWindows Serverに更新プログラムを適用する必要があります。
強制フェーズでは、特権の昇格を防ぐ動作が強制されるようになります。ただし、管理者がレジストリを変更することで「互換フェーズ」に戻せます。
完全強制フェーズでは、特権の昇格を防ぐ動作が完全に強制されます。
対象の脆弱性は3つありますが、複数フェーズを持つ脆弱性はCVE-2022-37967です。これを示したのが以下の図になります。
上図を踏まえ、各フェーズを要約します。
初期展開フェーズでは、KerberosのPACフィールドに「PAC署名」を追加します。監査イベントは出力しません。
第2展開フェーズでは、監査イベントをイベントログに出力します。補足すると、この更新プログラムを適用するのではなく、2023年1月10日にCVE-2022-37966の問題を修正した更新プログラムを適用することを推奨します。
第3展開フェーズまでで認証の互換を取りますが、PAC署名の追加が既定になります。
初期適用(強制)フェーズ以降では「認証拒否」となる動きです。ここではまだ監査イベントをイベントログに出力します。
完全強制フェーズで監査イベントの出力を終了します。
この脆弱性の詳細は、CVE-2021-42287に記載があります。これを示したのが以下の図になります。
こちらは当初3段階のフェーズでしたが、初期展開の更新プログラムが提供終了となり、2段階のフェーズになりました。こちらを踏まえ、各フェーズを要約します。
初期展開フェーズでは、PACに要求元が追加されます。PACに要求元が存在しないTGTであっても認証されるので、認証に失敗することはありません。認証に失敗しない代わりに、Active Directoryドメインコントローラー(以下、AD DC)のシステムイベントログにイベントID「35」「36」「37」「38」のメッセージが出力されます。このイベントログが出力されなくなるまで、7日間以上間隔を空けます。
第2展開フェーズでも認証は失敗しませんが、PACに要求元を追加することが必須となります。引き続きイベントログも出力されます。
現在は、この更新プログラムから適用します。よってイベントログが出力されなくなるように、次の更新プログラム適用までおおよそ7日間以上間隔を空けます。
強制フェーズでは、PACに要求元が存在しないTGTで認証が失敗します。引き続きイベントログも出力されます。ただし第2展開フェーズから7日間以上空いていれば、認証失敗となる可能性は最小化できます。
Netlogonプロトコルに影響する脆弱性の詳細については、CVE-2022-38023に記載があります。これを示したのが以下の図になります。
上図を踏まえ、各フェーズを要約します。
初期展開フェーズでは、以下の対策が講じられます。
初期適用フェーズで、RPCシールの利用は無効化できなくなります。つまり、初期展開フェーズへロールバックできなくなるということです。
初期値変更の強制フェーズでは、RPCシールの利用を強制するようになります。ただし、この時点では管理者が互換モードになるように明示的にレジストリを構成することが可能です。
完全強制フェーズでRPCシールの利用が完全に強制されます。レジストリを構成してもその設定は無視されます。
「証明書認証」は、VDI(Virtual Desktop Infrastructure)などで利用される認証です。証明書認証に影響する脆弱性の詳細については、KB5014754に記載があります。これを示したのが以下の図になります。
フェーズの要約へ入る前に、「証明書マッピングの強弱」について日本マイクロソフトのブログから引用します。
上記を踏まえて、各フェーズの要約をまとめます。
互換フェーズでは、デバイスが「互換モード」になります。認証およびイベントログへの出力は下記の通りです。
もし、1カ月以上経過しても警告メッセージが表示されない場合は、レジストリキーを変更して完全強制フェーズに移行できます。
無効フェーズでは、弱いマッピングに依存している場合、レジストリキー設定でAD DCを「無効モード」、すなわち証明書マッピングを「互換」から「無効」にできます。ただし、この操作は非推奨になっています。
既定変更フェーズでは、Windows更新プログラムを「Windows Server 2019」以降にインストールし、RSAT(Windows用リモートサーバ管理ツール)オプション機能が有効なWindowsクライアントでは「Active Directoryユーザーとコンピューター」管理ツールの「証明書マッピング」で、X509IssuerSubjectを使用した弱いマッピングではなく、X509IssuerSerialNumberを使用して強いマッピングを既定で選択します。設定は必要に応じて変更できます。
完全強制フェーズでは、全てのデバイスを「完全適用モード」に更新します。証明書を弱くマップする場合、認証は拒否されます。
ただし、「互換モード」に戻すオプションは「2025年9月10日」まで利用可能です(2025年9月10日に追加フェーズがリリースされる可能性もあります)。
もし、定期的に更新プログラムを適用していない場合は、本記事を留意して適用を進めていただけると幸いです。
Copyright © ITmedia, Inc. All Rights Reserved.