|

Como Executar um Comando do Sistema Operacional no SQL Server

PorRenato Sanches
Compartilhe :

Em alguns cenários bem específicos, como automatizar uma tarefa de manutenção ou chamar um utilitário externo, pode ser necessário executar um comando do sistema operacional diretamente a partir de uma query no SQL Server. Isso é possível através da stored procedure xp_cmdshell, presente no banco master.

Antes de usar, vale entender também os riscos envolvidos e as alternativas mais seguras disponíveis hoje.

Habilitando o xp_cmdshell

Desde o SQL Server 2005, o xp_cmdshell vem desabilitado por padrão por motivos de segurança. Antes de poder usá-lo, é preciso habilitá-lo explicitamente:

EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;

EXEC sp_configure 'xp_cmdshell', 1;
RECONFIGURE;

Executando um comando

Com o recurso habilitado, basta chamar a procedure informando o comando do sistema operacional que deseja executar:

EXEC master..xp_cmdshell 'dir c:\';

O resultado é devolvido como um conjunto de linhas de texto, uma para cada linha da saída do comando:

output
--------------------------------------------------------------
 Volume in drive C is Sistema
 Volume Serial Number is 28C4-ET4

 Directory of c:\

06/14/2024  05:57 AM                 0 AUTOEXEC.BAT
11/01/2024  03:18 PM     <DIR>          WebMundi
02/06/2025  08:19 AM     <DIR>          Windows
               1 File(s)        279.971.630 bytes
               2 Dir(s)   638.599.168.000 bytes free

Por que ter cuidado com o xp_cmdshell

O xp_cmdshell executa comandos com os privilégios da conta de serviço do SQL Server. Isso significa que qualquer usuário com permissão para executá-lo pode, na prática, rodar comandos no sistema operacional do servidor, não só dentro do banco de dados. Por esse motivo:

  • Ele vem desabilitado por padrão desde o SQL Server 2005, justamente para evitar esse tipo de exposição
  • É um dos primeiros alvos em testes de invasão e auditorias de segurança, já que permite escalar de um acesso ao banco para um acesso ao servidor inteiro
  • Deve ser habilitado apenas quando estritamente necessário, e restrito a um grupo bem pequeno de usuários

Se você habilitou o xp_cmdshell só para uma tarefa pontual, é uma boa prática desabilitá-lo novamente depois:

EXEC sp_configure 'xp_cmdshell', 0;
RECONFIGURE;

Também é possível restringir quem pode executar a procedure, mesmo com o recurso habilitado, usando permissões específicas em vez de depender apenas do cargo de sysadmin:

GRANT EXECUTE ON xp_cmdshell TO [usuario_especifico];

Alternativas mais seguras

Para boa parte dos cenários em que se pensa em usar xp_cmdshell, existem alternativas que reduzem a superfície de risco:

  • PowerShell dentro de um SQL Server Agent Job: permite automatizar tarefas do sistema operacional a partir de um job agendado, com controle de permissões próprio do Agent, sem depender do xp_cmdshell na sessão de query.
  • SSIS (SQL Server Integration Services): para rotinas mais elaboradas de automação e integração com o sistema de arquivos ou outros sistemas.
  • Procedures CLR (SQL Server 2005 em diante): permitem estender o SQL Server com código .NET de forma mais controlada, quando a necessidade é mais específica do que simplesmente rodar um comando de shell.

Conclusão

O xp_cmdshell é um recurso legítimo e útil em cenários pontuais de automação, mas carrega um risco de segurança real, por isso vem desabilitado por padrão. Se optar por usá-lo, habilite apenas quando necessário, restrinja o acesso a poucos usuários e desabilite novamente depois. Para automações recorrentes, vale considerar alternativas como PowerShell em um Job do SQL Server Agent, que oferecem mais controle sobre permissões e execução.

Posts Similares