脆弱性診断で「SMB Signing not required（SMB 署名が必須ではない）」がドメイン参加サーバーだけに出て、ドメインコントローラー（AD DS）には出ない——この差は、SMB 署名の既定値とGPO適用範囲の違いが原因であることがほとんどです。本記事では“誰が設定を決めているのか”まで含めて、確認方法と安全な是正手順を整理します。
現象の整理：「SMB Signing not required」が出る・出ないの違い
脆弱性診断ツールのレポートで「SMB Signing not required（SMB 署名が必須ではない）」が検出されると、多くの場合は「そのサーバーが“署名なしのSMB通信”を受け入れてしまう（＝署名を要求していない）」状態を意味します。ところが、同じドメイン内でもドメイン参加（メンバー）サーバーには指摘が出るのに、AD DS（ドメインコントローラー／DC）には出ないケースがあります。
この差は「診断ツールの気まぐれ」ではなく、Windowsの設計として役割（DCか、メンバーか）によってSMB署名の既定値・適用ポリシーが違うことが主因です。まずはSMB署名が何を守る仕組みなのかを押さえたうえで、設定の決定者（ローカル設定／GPO／セキュリティベースライン）を切り分けていきましょう。
SMB署名（SMB Signing）とは：何が「必須ではない」と問題なのか
SMB（Server Message Block）は、Windowsのファイル共有（\\server\\share）や管理用途で広く使われるプロトコルです。SMB署名（Signing）は、通信の各メッセージに改ざん検出用の署名を付け、途中でデータが書き換えられていないことを確認する仕組みです。
- 署名が「有効（Enabled）」：相手が署名できるなら署名する（ただし、相手が署名しない場合は“署名なし”でも成立し得る）
- 署名が「必須（Required / Always）」：署名のないSMB通信は拒否する（“署名なし”では成立しない）
診断ツールが問題視するのは後者の観点で、「署名が有効でも、必須でなければ中間者攻撃やリレー攻撃の余地が残る」と評価されるためです。特にドメイン環境では、認証（NTLM/Kerberos）と組み合わさって横展開の踏み台になり得るため、ベストプラクティスとして「署名を必須」に寄せる運用が一般的です。
結論：DCとメンバーサーバーで“既定値”が違う
質問の核心はここです。ドメインコントローラーは既定でSMB署名を“必須”寄りにしている一方、メンバーサーバーは互換性を優先し、既定では“必須ではない（署名は状況次第）”になりやすい、という差があります。
| 役割 | サーバー側：常に署名（Always） | サーバー側：署名（相手が同意する場合） | クライアント側：常に署名（Always） | クライアント側：署名（相手が同意する場合） | 診断での見え方 |
|---|---|---|---|---|---|
| ドメインコントローラー（AD DS） | 有効になっていることが多い | 有効 | 有効になっていることが多い | 有効 | 「not required」になりにくい |
| ドメイン参加（メンバー）サーバー | 無効（＝必須ではない）になりやすい | 有効 | 無効（＝必須ではない）になりやすい | 有効 | 「not required」として検出されやすい |
ポイントは、「署名が有効か」ではなく「署名が必須か」です。メンバーサーバーは「相手が署名できるなら署名する（Enabled）」状態になっていても、相手が署名しない場合に拒否しない（Requiredではない）ため、診断ツールが「署名必須ではない」と判断します。
“誰が／何が設定を決めているのか”を分解する
SMB署名の最終的な有効／必須は、次の要素の組み合わせで決まります。ここを理解すると、DCとメンバーサーバーで結果が違う理由がクリアになります。
OSの役割（DC）によるローカルセキュリティ既定値の差
Windows Serverは、ドメインコントローラーとして構成されたときに、単体サーバーやメンバーサーバーより厳しめのセキュリティ既定値になります。つまり「誰かが手でいじった」というより、“DCという役割の安全側の既定値”として設定されているケースが多いです。
GPOの適用範囲（OU）が違う：DCはDomain Controllers OUに入る
Active Directoryでは、DCは通常「Domain Controllers」OUに格納され、そこにリンクされたGPO（代表例：Default Domain Controllers Policyや組織独自のDC向けベースライン）が優先的に適用されます。一方、メンバーサーバーは別OU（あるいは既定のComputersコンテナ）に置かれ、DC向けの厳格なGPOが当たっていないことがよくあります。
その結果、DCは「署名必須」なのに、メンバーサーバーは「署名は有効だが必須ではない」という差が生まれます。
脆弱性診断ツールの判定は「サーバーが署名を要求するか」に寄りがち
多くの診断ツールは、対象ホストの445/TCP（SMB）に対して交渉（ネゴシエーション）を行い、“署名が必須かどうか（Required）”を見ています。したがって、クライアント側設定だけを強化しても、サーバー側が必須になっていなければ指摘が残ることがあります。対処ではサーバー側の「常に署名」を中心に考えるのが近道です。
まずは確認：そのサーバーの“実効値”を短時間で掴む
ポリシーは「設定したつもり」と「効いている」がズレやすい領域です。まずは診断で指摘されたメンバーサーバーと、指摘の出ないDCそれぞれで、実効値を確認してください。
PowerShellでの確認（最短・再現性が高い）
Windows Server 2012以降であれば、SMBクライアント／サーバー設定をPowerShellで確認できます。
# サーバー側（受け口）の署名設定
Get-SmbServerConfiguration | Select EnableSecuritySignature, RequireSecuritySignature
# クライアント側（接続しに行く側）の署名設定
Get-SmbClientConfiguration | Select EnableSecuritySignature, RequireSecuritySignature診断で問われることが多いのは、サーバー側のRequireSecuritySignatureがTrue（＝必須）かどうかです。EnableがTrueでもRequireがFalseなら、ツールによっては「not required」扱いになります。
GUIでの確認（ローカルセキュリティポリシー／GPO）
該当サーバーで次の場所を確認します。
- ローカル：secpol.msc → 「ローカル ポリシー」→「セキュリティ オプション」
- ドメイン：gpmc.msc（グループ ポリシーの管理）で、該当OUにリンクされたGPOと優先度を確認
| ポリシー名（セキュリティ オプション） | 対象 | 推奨（まずはここ） | 意味 |
|---|---|---|---|
| Microsoft ネットワーク サーバー: 常に通信にデジタル署名を行う | 受け口（SMBサーバー） | 有効 | 署名なしのSMB接続を拒否（“必須”） |
| Microsoft ネットワーク サーバー: 通信にデジタル署名を行う（クライアントが同意する場合） | 受け口（SMBサーバー） | 有効 | 署名可能な相手とは署名を使う（“有効”） |
| Microsoft ネットワーク クライアント: 常に通信にデジタル署名を行う | 接続側（SMBクライアント） | 有効（環境次第） | 署名できない相手への接続を拒否 |
| Microsoft ネットワーク クライアント: 通信にデジタル署名を行う（サーバーが同意する場合） | 接続側（SMBクライアント） | 有効 | 署名可能な相手とは署名を使う |
レジストリでの確認（運用で詰まったときの最終手段）
ポリシー画面が参照できない場合や、ツールでの自動監査に組み込みたい場合は、レジストリの実値を見ます。代表的な場所は次のとおりです。
| コンポーネント | キー | 値 | 意味 |
|---|---|---|---|
| SMBサーバー | HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters | RequireSecuritySignature / EnableSecuritySignature | 必須（Require）／有効（Enable）の実体 |
| SMBクライアント | HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters | RequireSecuritySignature / EnableSecuritySignature | 必須（Require）／有効（Enable）の実体 |
ただし、レジストリは“結果”であり、原因はGPOの適用やローカルポリシーの競合であることがほとんどです。先にGPOの実効値（gpresult / rsop）を確認する方が、安全で後戻りしやすいです。
対処の基本：GPOでSMB署名を必須化（Always）する
是正の基本方針はシンプルです。ドメインメンバー（必要ならDCも含め）に対して、SMB署名を「常に（Always）」へ寄せる。そのための手段として、GPO（グループポリシー）で統制するのが最も確実です。
推奨アプローチ：既定GPOを直接編集せず、専用GPOを作る
「Default Domain Policy」「Default Domain Controllers Policy」をそのまま編集すると、将来のトラブルシュートやベースライン適用の妨げになります。現場では次の流れが安全です。
- メンバーサーバー向け：サーバーOUにリンクする専用GPOを新規作成
- DC向け：既に満たしていることが多いので、まずは実効値を確認して必要な場合のみ追加
GPO設定手順（管理者が迷わない最短手順）
- グループ ポリシーの管理（gpmc.msc）を開き、対象OUを決めます（例：Servers/FileServers/TerminalServersなど）。
- 新しいGPOを作成し、分かりやすい名前を付けます（例：SEC – SMB Signing Required）。
- GPOの編集 → 「コンピューターの構成」→「ポリシー」→「Windows の設定」→「セキュリティの設定」→「ローカル ポリシー」→「セキュリティ オプション」へ進みます。
- 次の2つを有効にします。
- Microsoft ネットワーク クライアント: 常に通信にデジタル署名を行う
- Microsoft ネットワーク サーバー: 常に通信にデジタル署名を行う
- 加えて、互換性と分かりやすさのために次の2つも有効のまま（または有効に）しておくことが多いです。
- Microsoft ネットワーク クライアント: 通信にデジタル署名を行う（サーバーが同意する場合）
- Microsoft ネットワーク サーバー: 通信にデジタル署名を行う（クライアントが同意する場合）
- まずは検証用OU（パイロット）にリンクし、影響確認後に本番OUへ展開します。
段階適用のコツ：影響を小さくして“戻せる”設計にする
SMB署名の必須化は効果が大きい一方で、相手が署名できない場合は接続が失敗します。いきなり全台に適用せず、次のように段階化すると事故が起きにくいです。
- 対象を分ける：まずはファイルサーバー、次にアプリサーバー、最後に特殊用途サーバー（古い機器連携など）
- 例外を明確化：古いNASや複合機など、SMB署名非対応が疑われる機器は“例外OU”へ隔離し、別ポリシーで管理
- 影響確認の観点：バックアップ、監視エージェント、バッチ、EDI連携など“夜間にだけ動く”通信に注意
運用上の注意：互換性・性能・例外パターン
古いSMBクライアント／機器が接続できなくなる可能性
SMB署名を必須にすると、署名できない相手は接続できません。現場で多いのは、古いNAS、複合機、組み込み機器、古いLinuxディストリビューション（または古いSamba）などです。診断で指摘が出たサーバーが“提供する共有”に、そうした機器がぶら下がっていないかを先に棚卸しするとスムーズです。
性能影響は一般に小さいが、転送量が大きいサーバーは要測定
署名は暗号化（SMB Encryption）より軽いとはいえ、ファイルサーバーのように大容量転送が常態化している環境では、CPU負荷やスループットに影響が出ることがあります。特にピーク帯の転送や、仮想化基盤上の共有（CSVやバックアップ領域など）を扱う場合は、パイロット適用 → 実測（CPU/待ち時間/転送量）を推奨します。
DCで検出されない別の理由：スキャン条件で“評価できていない”ケースもある
質問のケースは「既定値の差」が主因になりやすい一方、次のような理由でDCが“検出されない”こともあります。
- SMB（445/TCP）がネットワーク的に到達できず、ツールが評価をスキップしている
- 認証付きスキャン／認証なしスキャンの差で、検査項目が変わっている
- ツールのポリシーやプラグイン設定で、DC向けの判定が別扱いになっている
この場合は、診断結果の“未評価”や“情報”欄も併せて確認し、PowerShellでの実効値確認を優先してください。
よくある落とし穴：設定したのに指摘が消えない
GPOを入れたのに診断結果が改善しない場合、原因はだいたい次のどれかです。
| よくある状況 | 原因の例 | 確認・対処 |
|---|---|---|
| クライアント側だけ「常に署名」を有効にした | 診断はサーバー側（受け口）のRequireを見ている | Microsoft ネットワーク サーバー: 常に通信にデジタル署名を行うを有効にする |
| GPOは作ったが、対象OUにリンクしていない／別OUに置いている | そもそも適用されていない | gpmcでリンク先と優先度を確認、gpresult /hで実効を確認 |
| OUにリンクしたのに一部サーバーだけ変わらない | セキュリティ フィルタ／WMIフィルタ／GPO継承ブロックの影響 | GPOのスコープと「結果のセット（RSOP）」を確認 |
| 実効値は変わったのに、診断が古い結果のまま | ツール側のキャッシュ、再スキャン範囲の違い | 同条件で再スキャン、または“最新の検査日時”を確認 |
| ポリシー適用後もRequireがTrueにならない | ポリシー更新が未反映、サービスの状態、設定競合 | gpupdate /force後に再確認。必要なら再起動も検討 |
適用後の確認：再スキャン前に押さえるチェックポイント
診断ツールの再実行に入る前に、サーバー側で次の3点を押さえておくと手戻りが減ります。
- 実効値：Get-SmbServerConfigurationでRequireSecuritySignatureがTrueになっている
- ポリシー適用：gpresultで該当GPOが「適用されたGPO」に載っている
- 通信確認：主要なクライアント（業務端末／アプリサーバー／バックアップ等）から共有アクセスが正常
この状態を作ってから再スキャンすれば、「診断が正しいのか」「設定が効いていないのか」の切り分けが一気に楽になります。
補足：SMB署名とセットで考えたい周辺のハードニング
SMB署名は“やる価値が高い対策”ですが、単体で万能ではありません。AD環境の攻撃経路は複合的なので、余力があれば次も同時に見直すと防御の層が厚くなります。
- SMBv1の無効化：古いプロトコルは攻撃面が広く、互換性要件がなければ無効化が推奨されます。
- NTLMの利用範囲の縮小：可能な範囲でKerberosへ寄せ、不要なNTLMを減らす。
- 管理共有（C$など）の扱い：不要な共有の棚卸し、管理者権限の最小化、監査の強化。
- 重要サーバーは“接続元を絞る”：ファイアウォールやセグメント分離で、そもそも445/TCPを誰が叩けるかを制御。
まとめ：DCに出なくてメンバーに出るのは“自然”、だからこそGPOで統制する
「DCには出ないのにメンバーサーバーに出る」現象は、Windows/ADの設計として起きやすい差分です。重要なのは、その差分を“放置する”のではなく、組織のセキュリティ基準としてGPOで揃えることです。まずは実効値を確認し、影響を見ながら段階適用すれば、脆弱性診断の指摘を消すだけでなく、SMBを起点としたリスクを現実的に下げられます。
コメント