Разработчик SQL в проекте, над которым я работаю, спросил, можно ли включить xp_cmdshell в производственной базе данных, поскольку легче экспортировать файлы CSV с помощью xp_cmdshell, чем писать пакет SSIS, чтобы сделать то же самое.
Включение xp_cmdshell звучит как кошмар безопасности, и этого делать определенно не следует.
Каковы рекомендации / лучшие практики по этому поводу?
Я бы не стал этого делать. Особенно, если вы планируете получить какой-либо брендинг от Microsoft как партнера-разработчика. Наши продукты сертифицированы Microsoft, и их инструменты проверки приложений будут проверять, включен ли xp_cmdshell или нет.
Если вы должным образом продезинфицируете все области, где код входит в SQL Server, и ни у кого нет разрешений, которые им не нужны, ваш риск должен быть минимальным. Конечно, все еще есть риск, поэтому я бы включил его только в том случае, если это было необходимо или значительно улучшило текущий процесс. Если писать пакеты SSIS не слишком сложно, лучше обойтись без xp_cmdshell.
Отключение xp_CmdShell немного похоже на накрывание вуалью гниющего мяса. Это создает ложное ощущение безопасности на столе, и мухи все еще могут добраться до мяса. Позвольте мне объяснить.
Кто может использовать xp_CmdShell? Это правильно. Только люди / логины приложений с привилегиями «SA» или люди, которым вы сделали ужасную ошибку, предоставив прокси, могут использовать его.
Следующий вопрос. Если у вас выключен xp_CmdShell, кто единственный, кто может включить его снова? И снова правильно! Только люди / приложения с привилегиями "SA" могут снова включить его.
Итак, в чем реальная проблема с xp_CmdShell, представляющим угрозу безопасности? Ответ: xp_CmdShell НЕ представляет угрозы безопасности. Плохая безопасность - единственный риск для безопасности. Если хакер или злонамеренный внутренний пользователь попадает в систему с правами «SA», они могут мгновенно включить xp_CmdShell. Да, это действие регистрируется, но это лишь документальное свидетельство того, что с самого начала безопасности явно не хватало.
Включение xp_CmdShell ничего не делает для безопасности, кроме как дает шанс этой части хакерского кода снова включить ее для запуска.
Я скажу это еще раз. xp_CmdShell не представляет угрозы безопасности. Только плохая безопасность представляет собой угрозу безопасности. Исправьте вашу безопасность, а затем включите xp_CmdShell. Это замечательный инструмент, и вы упускаете его из-за плохих методов безопасности и мифов.
Просто потому, что это «легче», не означает, что это правильно.
Я бы отказался и заставил разработчика использовать пакет SSIS.
Однако проверьте, насколько защищенной должна быть ваша система. Вы банк? Тогда xp_cmdshell - нет.
Если ваша производственная система является продуктом собственной разработки и ваши пользователи в целом заслуживают доверия, вы можете включить это.
Я бы порекомендовал не включать это, но если это станет критической для бизнеса проблемой и возникнет у вас, я бы настроил процесс так, чтобы вы включали xp_cmdshell только на тот короткий период, когда он вам нужен для импорта. Это можно создать в сценарии с помощью процедуры sp_configure, а также включать и выключать на этапах задания или с помощью процедуры T-SQL.
Не делай этого. xp_cmdshell - это любимый хакерский инструмент для повышения уровня атаки с SQL-инъекции до «Я владею вашей сетью и могу читать почту вашего генерального директора». После включения разработчики будут продолжать злоупотреблять им, чтобы использовать во всевозможных странных случаях, когда есть лучшие альтернативы.
И, кроме того, для экспорта CSV есть множество альтернатив, которые более безопасны, надежнее и проще в реализации:
И последнее, но не менее важное: как, черт возьми, легче экспортировать CSV с помощью xp_cmdshell, чем с помощью SSIS ??
Я просто спросил об этом своего администратора базы данных, потому что он отключил чрезвычайно полезную функцию, которую я использую для устранения неполадок. Проведя много исследований и просмотрев ответы людей, значительно более опытных, чем я, я склоняюсь к середине в вопросе отключения xp_cmdshell.
С одной стороны, смешно быть абсолютно уверенным в том, что отключить командную оболочку, как если бы это была зажженная динамитная шашка. Однако, с другой стороны, я думаю, что было бы совершенно безрассудно не уважать риски безопасности, связанные с использованием xp_cmdshell.
При этом я смотрю на xp_cmdshell как на заряженное оружие. Если вы знаете об опасности, действуйте осторожно, а если нет, то получите образование, прежде чем использовать его в производственной среде, особенно если он является частью приложения. По большей части использование xp_cmdshell в приложении «должно быть» последним вариантом.
Однако лично для меня, используя его для устранения неполадок производственных заданий (на специальной основе) в безопасной среде разработки, я просто не вижу «риска для безопасности». Код не сохраняется. Моя учетная запись - это личная учетная запись, и она не используется ни в каких публичных или частных приложениях. Это мои два цента ...