Esto se desactivó de fábrica a partir de SQL Server 2005, cuando introdujeron Herramienta de configuración de área de superficie
, en un esfuerzo por hacer que SQL Server sea más seguro de forma predeterminada. Esa herramienta se retiró desde entonces, pero aún puede controlar el comportamiento usando sp_configure
. Se muestra un ejemplo en MSDN
:
-- To allow advanced options to be changed.
EXEC sp_configure 'show advanced options', 1
GO
-- To update the currently configured value for advanced options.
RECONFIGURE
GO
-- To enable the feature.
EXEC sp_configure 'xp_cmdshell', 1
GO
-- To update the currently configured value for this feature.
RECONFIGURE
GO
(También blogueé sobre esto hace muchos años .)
La razón es que se trata de un agujero de seguridad potencial. Si permite que SQL Server ejecute xp_cmdshell
, entonces teóricamente pueden enviar cualquier comando del sistema operativo allí, pasando por alto cualquier y toda la seguridad que pensaba que tenía. Esto es especialmente problemático cuando la cuenta de servicio de SQL Server y/o la cuenta de proxy se han elevado a sysadmin u otros niveles porque es más fácil que definir explícitamente solo las cosas exactas que deberían poder hacer.
En lugar de habilitarlo y deshabilitarlo para admitir la interacción de la línea de comandos, una forma popular de exponer la funcionalidad del sistema operativo sin dejar de tener cierto control sobre la seguridad es implementar la funcionalidad a nivel del sistema operativo que necesita mediante SQL-CLR. Este es un buen punto de partida para acceder a la sistema de archivos con CLR (sin embargo, si busca, encontrará enfoques mucho más modernos y exhaustivos).
