签名与加密各管一段
签名给每个报文附加完整性校验，防止中间人篡改；加密则把整个 SMB 载荷加密，防止被抓包读走内容。签名在部分场景中由系统强制（例如域环境中的策略共享目录），加密则需要双方都支持 SMB3 并在共享或服务端显式开启。已加密的连接不需要再额外签名，所以开了加密之后再用抓包判断是否启用签名，得到的是加密本身的结果。
基本信息
| 适用平台 | Windows Server/客户端，Samba 4 与支持的第三方存储 |
|---|---|
| 签名字段 | Get-SmbConnection 的 Signing 列 |
| 加密字段 | Get-SmbConnection 的 Encrypted 列 |
| 共享级开启 | New-SmbShare/Set-SmbShare 的 EncryptData 参数 |
| 性能影响 | 签名与加密都消耗 CPU，加密对吞吐影响通常更明显 |
两种机制对照
| 维度 | SMB 签名 | SMB 加密 |
|---|---|---|
| 保护目标 | 完整性，防篡改 | 机密性，防窃听 |
| 协议要求 | SMB2 起可用 | SMB3 起可用 |
| 开启位置 | 客户端与服务端策略 | 共享属性或服务端设置 |
| 性能代价 | 每报文校验，CPU 开销随吞吐线性增长 | 加解密开销更大，单核性能影响明显 |
| 兼容性 | 老客户端多数可用 | 老客户端可能完全无法访问被要求加密的共享 |
查看与开启
查看与开启
# Windows：查看当前连接的签名与加密状态
Get-SmbConnection | Select-Object ServerName,Dialect,Signing,Encrypted
# Windows：查看共享是否要求加密
Get-SmbShare | Select-Object Name,EncryptData
# Windows：把已有共享改为要求加密（会中断不支持加密的客户端）
Set-SmbShare -Name data -EncryptData $true -Force
# Linux 客户端：显式要求加密需协商到 SMB3，参数以自身版本为准
mount -t cifs -o vers=3.1.1,seal,username=svc //10.0.0.20/data /mnt/data加密与多通道、RDMA 等能力存在配合关系：开启加密后部分加速特性可能不可用或需要硬件支持，吞吐预期要相应下调。评估时应在真实负载下测量，而不是按未加密的基准线性外推。
给共享开启「要求加密」会立刻切断所有不支持 SMB3 的老客户端与部分嵌入式设备（老扫描仪、备份一体机常见）。这类设备往往只提示连接失败，不会说明原因，容易被误判为账号或权限问题。
该在哪一层加固
如果只有个别目录涉及敏感数据，最划算的做法是只对该共享开启加密，其余共享维持原状；如果整个网络不可信（例如跨办公区），才考虑服务端全局要求加密。无论哪种方式，CPU 余量都要提前测算：加密开销集中在单连接的处理路径上，少量大吞吐客户端就可能把某个核心打满。