脆弱性診断で「SMB Signing not required（SMB署名が必須でない）」が検出されると、GPOで“署名を必須化”する手順と、SMB1/SMB2を無効化する手順が並んで見えて混乱しがちです。両者は目的が違い、推奨される対処の筋も異なります。業務影響を最小化しながら安全性を上げるための判断軸と実務手順を整理します。
「SMB Signing not required」とは何を指しているのか
「SMB Signing not required」は、多くの場合 対象ホスト（主にSMBサーバー側）が“SMB署名なし通信を許容している”ことを示します。つまり、クライアントが署名せずにSMB接続してもサーバーが拒否しない状態です。
SMB署名は、SMB通信の各メッセージに検証用の情報を付与し、改ざん（整合性の破壊）や中間者攻撃リスクを下げるための仕組みです。署名が必須でないと、同一ネットワーク内など一定条件下で、通信が差し替えられるリスクが高まります（“暗号化されていないから盗み見できる”という話とは別軸で、改ざんされにくくするのが主目的です）。
ここで重要なのは、診断結果が言っているのは「SMBというサービスが動いている/いない」ではなく、「署名が必須かどうか」だという点です。サービスを止めれば検出は消えますが、それは“署名必須化で安全になった”のとは意味が異なります。
結論：A案とB案は「同じゴール」に見えて、実は目的が違う
質問で挙げられているA案（署名必須化）とB案（SMBの有効/無効切替）は、脆弱性診断の表示上はどちらも“検出が消える”ことがあります。しかし、実務上は次のように整理すると迷いません。
| 観点 | A案：SMB署名を必須化（GPO/ローカルポリシー） | B案：SMB1/SMB2/SMB3を無効化（PowerShell/機能/レジストリ） |
|---|---|---|
| 主目的 | 署名なし通信を拒否して「Signing not required」を直接解消 | SMB自体（または特定バージョン）を止める／別軸のセキュリティ強化 |
| 診断が消える理由 | SMBが動いたままでも署名が必須になったため | SMBが応答しない／対象プロトコルが無効で診断が成立しないため |
| 業務影響 | 基本は軽微〜中（古い端末・古いNAS等が接続できなくなる可能性） | 中〜致命的（ファイル共有・認証連携・アプリ動作に広範囲の影響） |
| 推奨度 | 推奨（本命） | SMB1のみは推奨（使っていないなら無効化/削除） SMB2/SMB3まで無効化は原則非推奨（切り分け用途に限定） |
| 運用の位置づけ | セキュリティ標準としてGPOで統制しやすい | “不要なサービスは止める”判断が前提。止めるなら影響評価が必須 |
イメージとしては、A案は「鍵を強化して玄関は使い続ける」で、B案は「玄関そのものを封鎖する（または古い鍵穴だけ塞ぐ）」に近いです。封鎖すれば確かに侵入されにくくなりますが、玄関が必要な業務も止まります。
SMB署名とSMB暗号化は別物：できること・できないこと
「署名」と聞くと暗号化（盗み見防止）を想像しやすいのですが、SMB署名は主に改ざん検知（整合性）のための仕組みです。混同すると設計判断を誤りやすいので、違いを整理します。
| 項目 | SMB署名（SMB Signing） | SMB暗号化（SMB Encryption） |
|---|---|---|
| 主目的 | 通信の改ざん防止（整合性） | 通信内容の盗み見防止（機密性） |
| 「Signing not required」に効くか | 直接効く（署名必須化で解消） | 診断項目次第。署名必須が問われる場合は署名設定が必要なことが多い |
| 互換性リスク | 古いクライアントが署名できず接続不可になる可能性 | 暗号化非対応クライアントは接続不可になる可能性 |
| 使いどころ | まずは標準として必須化（特にサーバー側） | 機密データ、ゼロトラスト寄り設計、拠点間などで検討 |
ポイント：今回の検出名が「SMB Signing not required」である以上、対処の主戦場は“署名必須化”です。暗号化は別の強化策として有効ですが、診断項目をピンポイントで落とす解ではありません（もちろん環境によっては併用が理想です）。
A案（推奨）：SMB署名を必須化する考え方
A案は「SMBを止めずに、署名なし通信を許さない」方向の対処です。脆弱性診断の指摘に対して真正面から効くため、基本はA案をベースに設計します。
「always」と「if client agrees」の違い
SMB署名に関連する設定は、名前が似ていて紛らわしいのですが、意味が違います。
| 設定（代表例） | 意味 | セキュリティ | 互換性 |
|---|---|---|---|
| Microsoft network server: Digitally sign communications (if client agrees) | クライアントが署名できるなら署名する（できなくても拒否しない） | 中 | 高 |
| Microsoft network server: Digitally sign communications (always) | 署名できないクライアントは接続不可（署名を必須化） | 高 | 中〜低（古い端末があると影響） |
| Microsoft network client: Digitally sign communications (if server agrees) | 相手が署名対応なら署名する（相手が非対応でも接続し得る） | 中 | 高 |
| Microsoft network client: Digitally sign communications (always) | 署名できないサーバーへは接続しない（クライアント側の必須化） | 高 | 中〜低（古いNAS等へ繋がらない） |
「SMB Signing not required」を主に指摘されるのはサーバー側が“always”になっていないケースが多いです。まずはサーバー側の必須化を軸に、必要に応じてクライアント側も検討します。
サーバー側だけで良い？クライアント側も必須化する？
判断のコツは「その端末が何として振る舞うか」です。
| 対象 | よくある役割 | まず優先する設定 | 補足 |
|---|---|---|---|
| ファイルサーバー | SMBサーバー | Server: (always) を有効 | 診断対象がサーバーなら最優先。影響が出るのは古いクライアントのみ |
| 一般クライアントPC | SMBクライアント | Client: (if server agrees) を維持＋必要に応じて( always ) | 古いNASや古い共有先があると( always )で業務影響が出ることがある |
| アプリサーバー | サーバー兼クライアント | サーバーとして不要なら“共有を提供しない”設計も検討 | ただし「SMB2/3無効化」は最後の手段。不要ならポート制御や共有無効化が現実的 |
実務では、まず「SMBサーバーとして提供しているサーバー」から署名必須化し、クライアント必須化は影響範囲（古いNAS・装置）を洗い出してから段階的に行うのが安全です。
A案の実装：GPO（推奨）とローカルポリシー
GPOで適用する（組織での統制に最適）
ドメイン環境であれば、再現性・監査性・継続運用の観点からGPOが基本です。ローカル変更は端末ごとのばらつきが出やすく、後から追跡しづらくなります。
設定パス（代表例）：
- コンピューターの構成
- Windows の設定
- セキュリティの設定
- ローカル ポリシー
- セキュリティ オプション
推奨の最小セット（まずはサーバー側を固める）：
| 項目名 | 推奨値 | 狙い |
|---|---|---|
| Microsoft network server: Digitally sign communications (always) | 有効 | 署名なしSMBを拒否（「Signing not required」を直接解消） |
| Microsoft network server: Digitally sign communications (if client agrees) | 有効（既定のままでも可） | 署名可能な相手とは署名を使う。alwaysと併用されても矛盾しない |
クライアント側の必須化（Microsoft network client: … (always)）は、環境内に古い共有先が残っていると影響が出ることがあるため、影響評価後に段階導入が無難です。
運用上のコツ：
- OU分割＋段階適用（検証用OU → 一部本番OU → 全体）にして、問題が出たら戻せるようにする
- サーバーGPOはファイルサーバー/共有提供サーバーに絞る（全サーバー一括は想定外の影響が出やすい）
- セキュリティ監査の観点で、GPO名に「SMB署名必須化」など目的を明記する
ローカルセキュリティポリシーで適用する（単体サーバー・小規模向け）
ドメインに参加していないサーバーや検証環境では、ローカルポリシー（例：secpol.msc）で同じ項目を設定できます。
- ローカル セキュリティ ポリシーを開く
- セキュリティの設定 → ローカル ポリシー → セキュリティ オプション
- 「Microsoft network server: Digitally sign communications (always)」を有効
ただし、後から構成管理が必要になったときに追跡しづらいので、可能ならGPOまたは構成管理ツール（Intune/DSC等）で統制するのが理想です。
A案の確認：設定できたか・署名されているかを見える化する
「検出が消えた」だけでも一定の確認にはなりますが、運用では設定値と実際の通信状態の両方を押さえておくとトラブルが減ります。
PowerShellでサーバー側設定を確認
サーバー側では、署名を“必須化しているか（Require）”と“署名機能が有効か（Enable）”を確認します。
Get-SmbServerConfiguration | Select-Object EnableSecuritySignature, RequireSecuritySignature, EnableSMB1Protocol, EnableSMB2Protocol期待するイメージは次の通りです。
- RequireSecuritySignature : True（署名必須）
- EnableSecuritySignature : True（署名機能有効）
必要に応じて、設定変更（例：サーバー側の署名必須化）は次のような形になります。
Set-SmbServerConfiguration -RequireSecuritySignature $true -Force注意：環境・OSバージョン・役割により反映タイミングが異なることがあります。変更後にSMB関連サービスの再起動、またはサーバー再起動が必要になる場合があります。業務時間外の適用、段階展開、ロールバック手順の準備を前提にしてください。
クライアント/サーバーから「実際に署名されている接続」を確認
実際のSMB接続が署名されているかは、接続情報から確認できることがあります（項目名は環境差があるため、出力を見て「Signed」「Encrypted」などの列を確認します）。
Get-SmbConnectionファイルサーバーへの接続を張った状態で実行し、Signed が True になっているか（または同等の情報）を確認すると、設定と実通信が一致しているかを把握できます。
B案：SMB1/SMB2/SMB3を無効化する意味を正しく理解する
B案は「SMBプロトコルの有効/無効」を切り替える手順であり、署名必須化とは別の話です。脆弱性診断の見え方としては、SMBを無効化すれば「SMB Signing not required」も消えることがありますが、それは“診断対象のサービスが応答しない”だけであり、根本対策とは限りません。
SMB1は無効化/削除が基本（別軸のセキュリティ強化）
SMB1は古い設計で、現代の運用では不要なケースが多く、使っていないなら無効化/削除が推奨です。これは「Signing not required」対策とは別軸ですが、攻撃面を減らす意味で非常に効果があります。
| やり方 | 例 | メリット | 注意点 |
|---|---|---|---|
| Windows機能（GUI） | 「SMB 1.0/CIFS ファイル共有のサポート」を無効 | 分かりやすい | サーバー/クライアントで項目名が異なる場合がある |
| PowerShell（サーバー側） | Set-SmbServerConfiguration -EnableSMB1Protocol $false -Force | 自動化しやすい | 共有提供の有無、依存機器の有無を確認する |
| PowerShell（機能無効化/削除系） | Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol -NoRestart | OS標準機能として外しやすい | サーバーOSでは別の機能名/手段になることがある |
| レジストリ（最終手段） | LanmanServer / LanmanWorkstation のParameters配下で制御 | 細かい制御が可能 | 推奨度は低め（誤設定・反映不一致・保守性低下のリスク） |
SMB1を止めても、多くの環境ではSMB2/SMB3でファイル共有が継続できるため、業務影響は限定的です（ただし、古い複合機、古いNAS、古い組み込み機器などがSMB1依存の場合は例外になります）。
SMB2/SMB3まで無効化は、通常運用で推奨されない
PowerShell等でSMB2を無効化する例を見かけますが、Windowsの世界ではSMB2系の無効化がSMB3も含めて止まる扱いになることがあります（環境により表現が異なる場合がありますが、実務的には「SMB2を止める＝現代SMBの大半を止める」と考えるのが安全です）。
SMB2/SMB3まで無効化すると、次のような影響が現実的に起きます。
| 影響 | 具体例 | 現場での症状 |
|---|---|---|
| ファイル共有が使えない | 共有フォルダ、部署共有、配布用共有 | エクスプローラーで共有が開けない、アプリがファイルを読めない |
| 認証/運用の前提が崩れる | ドメイン環境の運用要素（例：共有を前提とした配布） | ログオン後のスクリプトや配布が失敗するなど、原因特定が難しい障害に見える |
| バックアップ/連携が止まる | バックアップ先がSMB共有、ログ保存先がSMB共有 | 夜間ジョブが失敗、ログ欠損、復旧が遅れる |
| 影響範囲が読みにくい | アプリが内部でSMBを使っているケース | 「突然動かなくなった」に見えやすく、影響調査が長期化 |
したがって、B案のうちSMB2/SMB3を止めて検出を消すのは、セキュリティ対策としては過剰で、業務影響が大きく、再現性の高い運用にも向きません。切り分け・一時回避として限定的に使う位置づけに留めるのが現実的です。
「GPO / PowerShell / レジストリ」は全部やる必要がない理由
同じ設定項目でも、変更手段が複数あります。ここでハマりやすいのが、GPOで設定した上でレジストリも手で触り、さらにPowerShellでも変更してしまい、“何が効いているのか分からない状態”になることです。
| 変更手段 | 向いている場面 | 強み | 落とし穴 |
|---|---|---|---|
| GPO | ドメイン環境、複数台を標準化 | 一括統制、監査性、再現性が高い | OU設計や継承、優先順位を理解していないと意図せず上書き |
| PowerShell | 自動化、検証、構成確認 | スクリプト化しやすい、状態確認が容易 | GPOと競合した場合、意図せず戻る/上書きされる |
| レジストリ | 例外的にGUI/コマンドが使えない、最終手段 | 低レイヤーで制御できる | 誤設定リスク、保守性低下、反映条件が分かりづらい |
基本方針：組織で配布・統制するならGPOを正とし、PowerShellは確認と補助、レジストリは極力避ける——この役割分担にすると事故が減ります。
レジストリ値が見当たらない場合に焦らないための考え方
「SMB1/SMB2の値がレジストリに無い」「署名関連の値が見当たらない」などは珍しくありません。多くの設定は値が無い＝既定動作に従うという設計で、必ずしも“無い＝無効”ではありません。
- 既定値で有効/無効が決まっている（値が作られていない）
- GPOが適用されると一時的/動的に反映され、手で探すと見つけにくい
- OSバージョンや役割で制御キーが異なる場合がある
「どうしても固定したい」気持ちは分かりますが、運用面ではGPOまたはPowerShellで“状態を確認できる形”で管理する方が安全です。レジストリ直書きは、変更履歴が残りづらく、監査・引き継ぎで詰まりやすいのが実情です。
実務での推奨アプローチ：脆弱性を消すだけでなく“運用に耐える”形にする
「SMB Signing not required」への対処を、単発の設定変更で終わらせず、継続運用できる形に落とす手順例を示します。
| ステップ | やること | 目的 | ポイント |
|---|---|---|---|
| 対象の整理 | 診断対象がサーバーかクライアントか、役割を確認 | 対処の打ち手を誤らない | 「共有提供しているか」「445/TCPが必要か」をまず確認 |
| 影響調査 | 古いNAS/装置/端末がSMB署名非対応でないか洗い出し | 必須化で接続不可になる端末を把握 | “古い複合機のスキャン保存先が共有”は典型的な落とし穴 |
| パイロット適用 | 限定OU/限定サーバーで署名必須化（A案） | 安全に導入 | 問題が出たら即ロールバックできる単位で |
| 本番展開 | ファイルサーバー群へ段階適用 | 標準化 | 変更管理と周知（いつ・どこに・何を）を徹底 |
| 追加強化 | SMB1を無効化/削除（B案のうちSMB1のみ） | 攻撃面の削減 | SMB1依存がないと分かってから実施 |
| 継続監視 | 定期診断・設定逸脱の検知 | “戻ってしまう”を防ぐ | GPOが正であれば、逸脱は検知しやすい |
トラブルシュート：署名必須化後に起きやすい症状と対処
署名必須化は筋の良い対策ですが、導入時に起きがちな“現場のつまずき”もあります。よくある症状を先回りで整理します。
| 症状 | 可能性の高い原因 | 対処の方向性 |
|---|---|---|
| 一部端末だけ共有に接続できない | 端末/装置がSMB署名非対応、または古いSMBしか話せない | 対象端末の更新、装置設定変更、別経路（SFTP等）検討、例外設計（ネットワーク分離した専用共有） |
| 脆弱性診断の検出が消えない | 診断対象が別ホスト/別ポート、署名必須がサーバーでなくクライアント側を見ている、反映前スキャン | 対象ホストと診断条件の再確認、反映タイミング（再起動/サービス再起動）確認、PowerShellでRequireを確認 |
| 設定したはずが戻る/揺れる | 別GPOが上書き、ローカル変更とGPOが競合 | GPOの優先順位・継承・セキュリティフィルタを見直し、管理手段を一本化 |
| 性能が落ちた気がする | 高負荷環境で署名のオーバーヘッドが顕在化 | まずは計測（CPU/IO/SMB統計）。必要なら暗号化やストレージ設計、スケールアウトなど別の最適化へ |
よくある質問
「署名必須化」と「SMBを止める」、両方やるべき？
基本は両方やる必要はありません。目的が違うためです。「Signing not required」を直す本筋は署名必須化（A案）で、追加強化としてSMB1を無効化/削除するのは有効です。一方、SMB2/SMB3まで無効化してしまうのは業務影響が大きく、通常運用では推奨されません。
SMBを提供していないサーバーでも検出される。どうする？
「共有フォルダを作っていない」＝「SMBサーバーが無効」とは限りません。445/TCPでSMBが待ち受けているだけで診断に引っかかることがあります。そのサーバーがSMBサーバーとして不要なら、署名必須化に加えて、Windowsファイアウォールで受信445を制限する、不要な共有提供を停止するなど、設計として“提供しない”方向に寄せるのが現実的です（ただし、サーバーが他の共有へアクセスする必要がある場合は、送信/受信の設計を分けて考えます）。
署名必須化で古いNASや複合機がつながらなくなったら？
“署名できない相手”は、必須化により接続できなくなります。解決策は大きく3つです。
- 更新：NAS/装置のファーム更新、機器更改（最も推奨）
- 経路変更：SMB以外（SFTP/HTTPSアップロード等）へ移行
- 例外設計：どうしても残る場合、ネットワーク分離した専用の共有先を用意し、被害の波及を抑える（“全体を緩める”のではなく“隔離して限定する”）
SMB1を無効化しただけで「Signing not required」が消えた。これでOK？
消えた理由が「署名が必須になった」ではなく、「診断対象のSMB応答が変わって検出できなくなった」可能性があります。SMB1の無効化は良い強化策ですが、診断項目が署名必須を見ているなら、サーバー側の署名必須化が入っているか（RequireSecuritySignature）を確認しておくのが安全です。
GPOとPowerShell、どちらで設定するのが正解？
ドメイン環境で標準化するならGPOが正解です。PowerShellは、状態確認やスポット適用、構成管理の自動化に向きます。両方で同じ項目を触ると競合しやすいので、「正（あるべき状態）をどこに置くか」を先に決めて一本化してください。
署名必須化で“どの端末が拒否されたか”を把握したい
導入期は「どこが影響を受けたか」を把握できると復旧が速くなります。ファイルサーバー側で、SMB関連のイベントログ（SMBServer系）やセキュリティログ、端末側のイベントログを含めて、失敗の痕跡を追える状態にしてから段階適用するのがおすすめです。まずはパイロットで“想定外の相手”がいないかを炙り出し、本番適用時の手戻りを減らします。
まとめ：迷ったら「署名必須化（A案）＋SMB1無効化（別軸）」が現実解
「SMB Signing not required」を解消するうえで、最初に選ぶべきはSMB署名の必須化（A案）です。SMBを止めて検出だけ消すのは、業務影響が大きく、運用でも再現性が低くなりがちです。
- 本命：サーバー側の「Digitally sign communications (always)」を有効化して署名なし通信を拒否
- 追加強化：使っていないならSMB1を無効化/削除
- 原則避ける：SMB2/SMB3を無効化してしまう（切り分け用途を除く）
この整理で進めれば、診断結果を落とすだけでなく、現場の運用とセキュリティ標準が両立しやすくなります。
コメント