Windows Server 2025 / Verificar assinatura SMB e criptografar um compartilhamento de teste

A assinatura SMB protege a integridade das mensagens; a criptografia SMB protege o conteúdo durante o transporte. Se a conexão falhar, verifique o nome do servidor, a autenticação, os recursos dos dois dispositivos e a sessão negociada antes de mudar essas proteções.

Diferencie assinatura, criptografia e autorização

Uma conexão assinada não é necessariamente criptografada, e criptografar o tráfego não corrige permissões de arquivo amplas demais. Examine as configurações do servidor, do cliente e da sessão realmente negociada. A documentação da Microsoft sobre assinatura SMB distingue os requisitos de saída do Windows Server 2025 das configurações do serviço de entrada. Funções de domínio e objetos de Política de Grupo (GPO) podem mudar a configuração efetiva.

Consulte os requisitos antes de alterá-los

No FS1, examine separadamente o cliente SMB, que acessa outros servidores, e o servidor SMB, que disponibiliza seus próprios arquivos:

Get-SmbClientConfiguration | Select-Object RequireSecuritySignature
Get-SmbServerConfiguration | Select-Object RequireSecuritySignature,EncryptData,RejectUnencryptedAccess
Get-SmbShare -Name 'LabRead' | Select-Object Name,Path,EncryptData

RequireSecuritySignature indica se a assinatura é exigida; esse valor sozinho não descreve uma conexão ativa. A criptografia também depende das configurações do compartilhamento, do servidor e do cliente. Consulte a documentação da Microsoft sobre fortalecimento da segurança SMB para as condições de cada versão.

Habilite a criptografia apenas no compartilhamento de teste

Use o compartilhamento LabRead já funcional com uma conta de domínio. Feche os arquivos abertos e guarde o valor inicial na mesma sessão do PowerShell no FS1:

$previousEncryption = (Get-SmbShare -Name 'LabRead').EncryptData
Set-SmbShare -Name 'LabRead' -EncryptData $true
Get-SmbShare -Name 'LabRead' | Select-Object Name,EncryptData

A criptografia SMB exige dispositivos compatíveis com SMB 3.x e políticas adequadas. Um dispositivo que anuncia SMB 3 pode não oferecer criptografia. Depois de salvar o trabalho, feche apenas a conexão do cliente envolvida e reconecte pelo nome habitual do servidor.

No CLIENT1, abra \\fs1.ad.example.test\LabRead e confira a conexão efetivamente estabelecida:

Get-SmbConnection | Where-Object ShareName -eq 'LabRead' | Select-Object ServerName,ShareName,Dialect,Encrypted

Localize a linha do compartilhamento, o dialeto SMB negociado e Encrypted=True. Se não houver linha, abra primeiro um arquivo para estabelecer a conexão. O direito de somente leitura continua igual quando a criptografia funciona.

Separe falhas de compatibilidade e autenticação

Prefira nomes de domínio e Kerberos quando apropriado, em vez de contornar problemas de identidade por meio de IPs ou aliases arbitrários. Para um NAS mais antigo, verifique atualizações, capacidade de assinatura, substituição ou isolamento, em vez de desativar globalmente a assinatura, habilitar o uso inseguro de convidados ou ativar o SMB1.

Examine os logs de eventos SMBClient e SMBServer e anote o horário, o compartilhamento e a conta envolvidos. Uma negação de acesso exige diagnóstico diferente de uma falha na negociação de segurança.

Restaure apenas a configuração modificada no teste

Na mesma sessão do PowerShell no FS1, restaure o valor guardado em vez de desativar a criptografia indiscriminadamente:

Set-SmbShare -Name 'LabRead' -EncryptData $previousEncryption

Reconecte e confira o acesso aos arquivos e a proteção negociada. Políticas mais abrangentes ainda podem exigir criptografia depois que o valor do compartilhamento for restaurado. Em produção, avalie em conjunto a sensibilidade dos dados, a compatibilidade, o desempenho medido e o acesso em caso de falha.