Windows Serverでファイル共有が遅いとき、SMB署名を疑うのは自然です。実際、SMB署名は転送データの整合性を検証するため、CPU余力が少ない環境やRDMA/SMB Directを使う高スループット環境では速度低下の一因になりえます。ただし、影響は一律ではありません。Microsoftも、性能低下の大きさはハードウェア性能、CPUコア数、ほかの負荷状況で大きく変わると案内しており、Windows Server 2022とWindows 11ではAES-128-GMACによる署名高速化も導入されています。最近のWindowsでは署名要件の既定も強化されているため、安易に無効化するより、まず「本当に署名が原因か」を切り分ける方が安全です。(Microsoft Learn)
この記事では、Windows ServerでSMB署名が速度に与える影響を、RDMA・小ファイル・一般的なファイルサーバー運用に分けて整理し、実際の確認コマンド、見直しの判断基準、無効化以外の代替策までまとめます。読み終わるころには、「その環境で本当に見直すべきか」と「次に打つ手」が判断できる状態になります。
SMB署名が速度に影響しやすい場面
SMB署名は、セッションキーと暗号スイートを使って各メッセージに署名を付ける仕組みです。目的は改ざん検知とリレー攻撃・スプーフィング対策であり、速度よりも安全性を優先する機能です。そのため、CPU処理の余力が少ない構成や、高速ネットワークを使って大量に流す構成ほど影響が見えやすくなります。(Microsoft Learn)
| 状況 | 影響の出やすさ | まず疑うべきこと |
|---|---|---|
| RDMA/SMB Direct を使う Hyper-V、SQL Server、S2D、CSV | 高い | 署名必須化でRDMAの利点を失っていないか |
| 10GbE以上の高速回線でCPUも忙しい汎用ファイルサーバー | 中〜高 | CPU飽和、offload無効、Multichannel未活用 |
| 数万〜数百万の小ファイルを Explorer でコピー | 中 | 署名より、ツールと小ファイル処理のオーバーヘッド |
| 1GbE中心の一般的な部署共有 | 低〜中 | 署名よりストレージやコピー方法の影響 |
特に要注意なのは、Windows Server 2016/2019でRDMAを使う高性能構成です。Microsoftは、RDMA有効なNICでSMB署名またはSMB暗号化を有効にすると、SMB Directの性能が大きく低下する場合があると案内しています。一方で、Windows Server 2022以降はSMB Directでの暗号化サポートが改善され、Windows Server 2022/Windows 11ではAES-128-GMACによる署名高速化も入っています。つまり、同じ「SMB署名の影響」でも、OS世代で体感はかなり変わります。(Microsoft Learn)
Windows Serverでまず確認すること
SMB署名の見直しで失敗しやすいのは、設定値だけ見て終わることです。RequireSecuritySignature は「その端点で署名を必須にしているか」を確認する値で、実際にそのセッションが署名済みかどうかは、接続状態も別に見る必要があります。しかも、SMB2以降では EnableSecuritySignature をいじっても意味がなく、実質的には RequireSecuritySignature を見るのが先です。(Microsoft Learn)
以下のコマンドを先に押さえておくと、切り分けがかなり速くなります。これらはMicrosoftの公式ドキュメントで案内されている確認系コマンドを中心に整理したものです。(Microsoft Learn)
| 確認したい項目 | コマンド | 見るポイント |
|---|---|---|
| 署名の必須化 | Get-SmbClientConfiguration | FL RequireSecuritySignatureGet-SmbServerConfiguration | FL RequireSecuritySignature | True ならその端点で必須 |
| 実際の接続状態 | Get-SmbConnection | Select-Object ServerName,ShareName,Dialect,Signed,Encrypted | Dialect、Signed、Encrypted |
| サーバー側のセッション | Get-SmbSession | FL | Dialect、接続元の把握 |
| RDMA対応NIC | Get-SmbServerNetworkInterfaceGet-SmbClientNetworkInterface | RDMA Capable、RSS Capable、Speed |
| SMB Multichannel | Get-SmbMultichannelConnection | Selected、CurrentChannels |
署名が必須になっているかを確認する
まずは、クライアント側とサーバー側の両方で RequireSecuritySignature を見ます。
Get-SmbClientConfiguration | FL RequireSecuritySignature
Get-SmbServerConfiguration | FL RequireSecuritySignatureMicrosoftの現行ドキュメントでは、ここが True ならその端点でSMB署名を有効化・必須化している状態として扱います。ただし、SMB2以降では EnableSecuritySignature は無視され、署名の有無は RequireSecuritySignature の組み合わせで決まるため、レジストリの EnableSecuritySignature だけを見て判断しない方が安全です。(Microsoft Learn)
実際のSMB接続がどう張られているかを確認する
設定値が分かったら、次は実セッションを見ます。クライアント側では Get-SmbConnection、サーバー側では Get-SmbSession が分かりやすい入口です。Microsoftのパフォーマンスチューニング文書でも、クライアントで Get-SmbConnection、サーバーで Get-SmbSession | FL を使ってSMBのバージョン確認を行うよう案内しています。(Microsoft Learn)
Get-SmbConnection | Select-Object ServerName,ShareName,Dialect,Signed,Encrypted
Get-SmbSession | FLここで見落としやすいのが、Encrypted=True の接続です。MicrosoftのWMIクラス定義では、暗号化されたSMB接続では Signed プロパティが False と表示されることがあります。しかし、暗号化された共有は整合性検証も同時に提供するため、Signed=False だけを見て「無署名で危険」と誤解してはいけません。(Microsoft Learn)
RDMA/SMB Direct と SMB Multichannel が生きているかを確認する
高スループット環境では、署名の見直しより先に、RDMAとSMB Multichannelが正しく機能しているかを確認すべきです。SMB Multichannel は複数のネットワーク経路を同時利用してスループットと耐障害性を高める機能で、既定で有効です。RDMAは低CPU・低遅延・高帯域の要です。(Microsoft Learn)
Get-SmbServerNetworkInterface
Get-SmbClientNetworkInterface
Get-SmbMultichannelConnectionRDMA Capable や Selected が期待どおりになっていない場合、署名を疑う前に、NIC設定・ドライバー・RSS/RDMAの有効状態を見直した方が早いことがあります。なお、RDMA環境でSMB署名やSMB暗号化が使われている場合、Microsoft-Windows-SMBClient/Operational に 30909 や 30910 のイベントが出ることがあります。深掘りするときの手掛かりになります。(Microsoft Learn)
コピー手段・ストレージ・CPUがボトルネックではないかを確認する
実務では、SMB署名より先に「コピー方法」が原因なことが少なくありません。Microsoftは、File Explorer は単一スレッドかつバッファードI/Oで動き、robocopy の方が高性能なコピーに向いていると明記しています。大きなファイルは robocopy /J、小ファイル大量転送は robocopy /MT が有効です。さらに、コンソール出力を減らすために /LOG も勧めています。(Microsoft Learn)
# 大きなファイルの比較
robocopy D:\Test \\FS01\Data bigfile.vhdx /J /R:0 /W:0 /LOG:NUL
# 小ファイル大量の比較
robocopy D:\Src \\FS01\Data /E /MT:32 /R:0 /W:0 /LOG:NUL可圧縮データなら、SMB圧縮も候補です。Microsoftは、.vhd .vhdx .iso .dmp などには効きやすく、.zip .7z .rar .mp4 .mkv .mp3 のような非圧縮向きでないデータには大きな改善が出にくいと案内しています。(Microsoft Learn)
さらに、ストレージ性能が足りなければ、署名の有無に関係なく頭打ちになります。Microsoftのトラブルシュート文書では、SMBで現実的に必要な持続ストレージ性能の目安として、1Gbpsで約110MB/s、10Gbpsで約1.1GB/s、100Gbpsで約11GB/sを示しています。10GbEなのにストレージが600MB/sしか出ないなら、そこがボトルネックです。(Microsoft Learn)
比較テストをするなら、同じデータセット・同じ経路・同じツールで揃え、1回目をウォームアップ、2回目を計測対象にするのが無難です。SMB Directの検証では、Microsoftは両端を再起動して条件を揃えることも案内しています。純粋にネットワークの地力を見たいなら NTttcp.exe や ctsTraffic.exe を使い、逆にスループット試験中のパケットキャプチャは結果を歪めるので避けます。(Microsoft Learn)
SMB署名を見直す判断基準
原則として維持した方がよいケース
ドメインコントローラー、SYSVOL や NETLOGON を含むAD系の共有、一般的な部門ファイルサーバー、信頼しきれないネットワーク区間では、SMB署名を原則維持した方が安全です。SMB署名は改ざん検知とリレー攻撃対策を担い、Microsoftも最近のWindowsで既定の署名要件を強化しつつ、無効化は推奨しない立場を示しています。Kerberosを使うためにIPアドレスやCNAMEで共有に接続しないことも、同じくらい重要です。(Microsoft Learn)
見直し候補になりやすいケース
見直しが現実的になるのは、Hyper-V over SMB、SQL Server over SMB、Storage Spaces Direct、CSV など、RDMA/SMB Directを前提に高スループットを狙う環境です。Windows Server 2016/2019系では、署名や暗号化によりRDMAのダイレクトデータ配置が使えず、性能低下が大きく出ることがあります。この種の環境では、「一般論としてのセキュリティ設定」より「そのワークロードでどの保護方式が最も損失が少ないか」を設計として判断した方が失敗しません。(Microsoft Learn)
例外的に無効化を検討できるケース
例外的に無効化が候補になるのは、サードパーティ製NASや古いSMBサーバーが署名をサポートしない、あるいはゲストアクセス前提でしか動かない、といった互換性問題がある場合です。Microsoftも、そのようなケースでは無効化が必要になる場面を認めていますが、同時に推奨はしていません。どうしても必要なら、全体ではなく対象サーバー・対象VLAN・対象期間に限定し、信頼できるプライベートネットワークと厳格なアクセス制御を前提に例外化するのが現実的です。(Microsoft Learn)
無効化以外で改善できること
Windows Server 2022以降へ寄せる
OS世代が古いまま「SMB署名は遅い」と結論づけるのは早計です。Windows Server 2022 と Windows 11 では AES-128-GMAC による署名高速化が入り、SMB Direct と暗号化の組み合わせも以前より改善されています。サーバー更改のタイミングなら、署名を切るより先に、OSとNICまわりを現行に寄せた方が、性能と安全性を両立しやすいです。(Microsoft Learn)
共有単位でSMB暗号化を使う
「整合性だけでなく秘匿性も必要」という共有は、SMB署名よりSMB暗号化を共有単位で使う方が整理しやすいことがあります。SMB暗号化は暗号化された共有に対して整合性検証も提供するため、署名設定とは別に保護を成立させられます。Windows Server 2016/2019 の SMB 3.1 世代では、Microsoftは高セキュリティ環境で SMB暗号化が SMB署名より有利な場面もあると説明しています。(Microsoft Learn)
# 共有単位で暗号化
Set-SmbShare -Name Data -EncryptData $true
# サーバー全体で暗号化
Set-SmbServerConfiguration -EncryptData $trueただし、SMB暗号化を有効にした共有やサーバーは、既定では SMB 3.x を話せるクライアントしか接続できません。古いクライアントや一部のサードパーティ実装が混じる環境では、互換性確認を先にやるべきです。(Microsoft Learn)
Kerberos・監査・名前解決を整える
SMB署名の見直しは、設定値だけの話ではありません。Microsoftは、Kerberos を使うために IP アドレス接続や CNAME 接続を避けること、NTLMv2より Kerberos を優先することを勧めています。名前解決の設計が悪いまま署名だけ調整しても、期待した安全性は得られません。(Microsoft Learn)
最近のWindowsでは、署名や暗号化をサポートしない相手機器を監査する機能もあります。いきなり必須化や無効化を行う前に、まず監査を有効にして「どの相手が問題なのか」を洗い出すと、例外範囲を最小化できます。監査ログは Applications and Services Logs\Microsoft\Windows\SMBClient\Audit と ...\SMBServer\Audit に記録されます。(Microsoft Learn)
Set-SmbServerConfiguration -AuditClientDoesNotSupportSigning $true
Set-SmbClientConfiguration -AuditServerDoesNotSupportSigning $trueRDMA・Multichannel・Compression を正しく使い分ける
署名を切るより、RDMA・SMB Multichannel・SMB圧縮を正しく使った方が成果が出ることは多いです。SMB Multichannel は既定で有効で、複数経路を使って帯域を束ねられます。RDMAは高帯域・低CPUに効きます。SMB圧縮は可圧縮な大きいファイルや、遅い・混雑した回線で効きやすいです。どれも「署名の代替」ではありませんが、署名を維持したまま性能差を埋める有力な手段です。(Microsoft Learn)
SMB署名を変更する手順
PowerShellで変更するなら、実際に触るのは RequireSecuritySignature です。グループポリシーで行う場合も、基本は「Microsoft network client: Digitally sign communications (always)」と「Microsoft network server: Digitally sign communications (always)」を使います。ドメイン参加環境では、ローカル変更よりGPMCでの管理を優先した方が整合が取りやすいです。(Microsoft Learn)
# 署名を必須にする
Set-SmbClientConfiguration -RequireSecuritySignature $true
Set-SmbServerConfiguration -RequireSecuritySignature $true
# 署名の必須を外す
Set-SmbClientConfiguration -RequireSecuritySignature $false
Set-SmbServerConfiguration -RequireSecuritySignature $falseポリシーの場所は次のとおりです。
Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options
無効化を試験的に行うなら、次の順番を守ると事故を減らせます。
- 監査を先に有効にして、問題のある接続先を特定する。(Microsoft Learn)
- robocopy で同じデータセットを使って基準値を取る。Explorer だけで判断しない。(Microsoft Learn)
- RDMA、Multichannel、CPU、ストレージ性能を確認する。(Microsoft Learn)
- 1項目ずつ変更して再計測する。ベンチ中のパケットキャプチャは避ける。(Microsoft Learn)
失敗しやすいポイント
- File Explorer の転送速度だけ見て「SMB署名が遅い」と決めつけること。大量の小ファイルでは、単一スレッドのコピー方法そのものが大きなボトルネックになります。(Microsoft Learn)
Get-SmbClientConfigurationの値だけ見て、実セッションのSignedやEncryptedを確認しないこと。設定と実接続は別です。(Microsoft Learn)EnableSecuritySignatureのレジストリだけを触ること。SMB2以降ではこの値は無視されます。(Microsoft Learn)- Windows Server 2016/2019 のRDMA環境と、Windows Server 2022以降の改善済み環境を同じ前提で語ること。OS世代で挙動がかなり違います。(Microsoft Learn)
- 一台の古いNASのために、全社一律でSMB署名を無効化すること。まず監査で対象を絞るべきです。(Microsoft Learn)
- ベンチマーク中にネットワークキャプチャを取り、その結果を本番性能だと思い込むこと。TCPスループット試験では測定自体が性能を落としえます。(Microsoft Learn)
まとめ
Windows ServerにおけるSMB署名の速度影響は、確かに存在します。ただし、効き方は「Windows Serverの版」「RDMAの有無」「ファイルサイズ」「コピー手段」「CPUとストレージの余力」で大きく変わります。特に、RDMAを使う高性能構成や、Windows Server 2016/2019系の古めの構成では差が出やすく、逆に一般的なファイル共有では署名より別要因が支配的なことも多いです。(Microsoft Learn)
次に取るべき行動は明確です。まず RequireSecuritySignature と Get-SmbConnection で設定値と実接続を確認し、次に robocopy で同条件の比較を行い、RDMA・Multichannel・CPU・ストレージを点検します。そのうえで、原則はSMB署名を維持し、必要なら Windows Server 2022以降への更新、共有単位のSMB暗号化、監査による例外管理に寄せる。無効化は、互換性や実測で正当化できる範囲に限って行うのが、安全で失敗しにくい見直し方です。(Microsoft Learn)
コメント