Um desenvolvedor de SQL em um projeto em que estou trabalhando perguntou se seria possível habilitar xp_cmdshell no banco de dados de produção, pois é mais fácil exportar arquivos CSV usando xp_cmdshell do que gravar um pacote do SSIS para fazer o mesmo.
Ativar o xp_cmdshell parece um pesadelo de segurança e algo que definitivamente não deve ser feito.
Quais são as recomendações / melhores práticas em torno disso?
Desativar o xp_CmdShell é como colocar um véu sobre a carne podre. Traz uma falsa sensação de segurança para a mesa e as moscas ainda podem chegar à carne. Permita-me explicar.
Quem pode usar o xp_CmdShell? Está certo. Somente logins de pessoas / aplicativos com "SA" privs ou pessoas com as quais você cometeu o erro horrível de conceder um proxy para usá-lo.
Próxima pergunta. Se você tiver o xp_CmdShell desativado, quem são as únicas pessoas que podem ativá-lo novamente? Corrija novamente! Somente pessoas / apps com "SA" privs podem ativá-lo novamente.
Então, qual é o problema real com o xp_CmdShell sendo um risco de segurança? A resposta é xp_CmdShell NÃO é um risco de segurança. A falta de segurança é o único risco de segurança. Se um hacker ou um usuário interno mal-intencionado entrar no sistema com "SA" privs, eles poderão ativar o xp_CmdShell nos momentos. Sim, essa ação é registrada, mas isso apenas fornece um testemunho documentado de que a segurança era escassamente deficiente para começar.
A conversão de xp_CmdShell não é mais uma segurança, exceto para oferecer uma chance de que a parte de um código de hackers seja ativada novamente.
Eu vou dizer de novo. xp_CmdShell não é um risco de segurança. Apenas uma má segurança é um risco de segurança. Corrija sua segurança e, em seguida, ative xp_CmdShell. É uma ferramenta maravilhosa e você está perdendo isso por causa das más práticas de segurança e do mito.
Contanto que você tenha higienizado adequadamente as áreas em que o código entra no SQL Server e ninguém tenha permissões, elas não precisam que seu risco seja mínimo. Ainda há um risco claro, então eu só o habilitaria se fosse necessário ou melhoraria muito o processo atual. Se não é muita dor de cabeça para escrever os pacotes do SSIS, é melhor ir sem o xp_cmdshell.
Só porque é "mais fácil" não significa que seja a coisa certa a fazer.
Gostaria de retroceder e fazer com que o desenvolvedor usasse um pacote do SSIS.
No entanto, examine o quão seguro seu sistema precisa ser. Você é um banco? Então xp_cmdshell é um não não.
Se o seu sistema de produção for um produto interno e seus usuários forem geralmente confiáveis, você poderá ativar isso.
Eu recomendaria não ativá-lo, mas se ele se tornar um problema crítico para os negócios e for acionado por você, configurarei o processo para que você ative o xp_cmdshell apenas pelo breve período necessário para a importação. Isso pode ser roteirizado usando sp_configure e ativado e desativado em etapas de trabalho ou em um procedimento T-SQL.
Não faça isso. O xp_cmdshell é a ferramenta de escolha do hacker para elevar um ataque do SQL Injection até 'Eu possuo sua rede e posso ler o correio do seu CEO'. Uma vez ativado, os desenvolvedores continuarão abusando dele para usá-lo para todos os tipos de casos estranhos quando houver alternativas melhores.
Além disso, para exportar o CSV, há muitas alternativas mais seguras, seguras e fáceis de implementar:
E por último, mas não menos importante, como é mais fácil exportar o CSV usando o xp_cmdshell do que usando o SSIS ??
Eu apenas perguntei ao meu DBA sobre isso porque ele desativou uma função extremamente útil que eu uso para solução de problemas. Depois de fazer muitas pesquisas e analisar as respostas de pessoas significativamente mais experientes do que eu, tenho a tendência de me inclinar para o meio na questão da desativação do xp_cmdshell.
Por um lado, é ridículo ser absoluto sobre a ideia de desabilitar o shell de comando como se fosse um bastão de dinamite. No entanto, por outro lado, acho que seria completamente imprudente não respeitar os riscos de segurança do uso do xp_cmdshell.
Dito isto, eu vejo o xp_cmdshell como uma arma carregada. Se você souber o perigo, prossiga com cautela e, se não souber, seja educado ANTES de usá-lo em um ambiente de produção, especialmente se for parte de um aplicativo. Na maior parte, usar xp_cmdshell em um aplicativo "provavelmente" deve ser uma opção de último recurso.
No entanto, para mim, pessoalmente, usá-lo para solucionar problemas de produção (em uma base adHoc) em um ambiente de desenvolvimento seguro, simplesmente não vejo o "risco de segurança". O código não está sendo armazenado. Minha conta é uma conta pessoal e não é usada em nenhum aplicativo público ou privado. São meus dois centavos ...
Tags security sql-server