Почему приложение не должно использовать учетную запись sa

Мой первый вопрос, пожалуйста, будьте нежны. Я понимаю, что учетная запись sa обеспечивает полный контроль над SQL Server и всеми базами данных, пользователями, разрешениями и т. Д.

У меня есть абсолютное убеждение, что приложения не должны использовать пароль sa без совершенной причины, нацеленной на деловых людей. Ответы на этот вопрос включают в себя множество моих рассуждений для обсуждения, ориентированного на ИТ

Я вынужден принять новую систему управления услугами, которая НЕ БУДЕТ работать, если она не использует пароль sa. У меня никогда не было времени выяснить, почему при настройке оценки серверная команда пыталась установить ее для использования фиксированной роли, которую я настроил, включая db_creater и другие разрешения, которые, по моему мнению, потребуются. который не удался. Затем я позволил команде сервера установить с учетной записью sa, но запустить под учетной записью в роли dbo для своей базы данных, но это тоже не удалось. Я старательно пытался заставить его работать с учетной записью в роли sysadmin, но даже это не удалось, а не с полезными сообщениями об ошибках, которые позволили мне разобраться в происходящем, не тратя больше времени, чем у меня было доступно. Он будет работать только с учетной записью sa и паролем, хранящимся в открытом тексте в файле конфигурации.

Когда я спросил об этом, и команда сервера поговорила с продавцом, они получили тревожный ответ: «В чем проблема?» а затем "ну, мы можем посмотреть на взлом пароля"

Я знаю, что есть способы и средства ограничения доступа к файлу, но это, на мой взгляд, еще одна слабость в безопасности

В любом случае, мой вопрос, может ли кто-нибудь указать мне какую-то документацию, которую я могу использовать, чтобы объяснить бизнесу причину, по которой это плохо и должно быть большим, нет, нет. Я работаю в области, которая означает, что мне нужно серьезно относиться к безопасности, и я изо всех сил стараюсь понять бизнес, и в конечном итоге, в любом случае, меня могут опередить, но мне нужно попробовать.

Это зависит от вашего бизнеса, но главное в большинстве случаев - убедиться, что это не рассматривается как проблема ИТ. Это проблема безопасности, и в то время как обе компании в значительной степени пересекаются, деловые люди с большей вероятностью выслушают, если вы скажете «безопасность», чем если вы просто «стонете по поводу общих ИТ-вещей».

Работаете ли вы с клиентами, у которых есть требования безопасности? Это хорошее место для начала. Если мы запустили приложение с доступом на уровне sa или просто приложение, которое должным образом не защитило свои учетные данные, даже если не использовал привилегированный доступ (мы настоятельно предпочитаем Windows Integrated, а не сохраненного пользователя / прохода, где это возможно), и мы подвергались безопасности аудит, этот аудит потерпит неудачу, и мы рискуем потерять клиентов и / или придется вернуть деньги клиентам наших групп (банковские организации в случае продукта, над которым я работаю в основном, другие части группы имеют дело с полицией и здравоохранением власти и т. д.) безопасность является частью нашего предложения, пригодного для данной цели. Деловые люди не понимают серьезность этой потенциальной угрозы , даже если они обычно платят не больше , чем на словах ИТ - рекомендации.

Даже игнорируя навязанные клиентом требования, если вы будете стремиться соответствовать различным стандартам безопасности отраслевого стандарта, подобный тип проверки подлинности приложений снова подведет вас перед аудитом, поскольку он настолько далек от передовой практики, что обычно считается чем-то, что считается в списке "просто не должно быть сделано". Дайте понять своим лицам, принимающим решения в бизнесе, что безопасность является важной частью приложения, и тот факт, что этот поставщик, похоже, не знает (или, по крайней мере, не обеспокоен), заставляет вас сомневаться в том, на что еще они не способны. иметь дело с: знание о наилучшей практике безопасности БД является (ну, должно быть) частью их работы, и реализовать ее несложно.

Также отметьте, что вы (покупатель) должны диктовать поставщику разумные требования безопасности, а не наоборот. Это ваши данные, поэтому они не могут утверждать, что считается достаточно безопасным.

Ни одно приложение не должно иметь доступа SA - никогда. (Если его единственной целью не является администрирование базы данных какого-либо рода.)

Это общее правило - никогда не предоставлять больше прав на любой логин (прикладной или персональный), чем это требуется для бизнеса.

Ни одно приложение не является полностью безопасным. У большинства есть какая-то уязвимость в SQL-инъекциях или XSS. Если злоумышленник выполнит заявление по своему выбору и получит доступ «SA», с вашими данными может произойти множество вещей, которые могут мгновенно убить бизнес. (Особенно, если данным нужно доверять, потому что они используются правоохранительными органами.) Спросите заинтересованных лиц, что им нужно делать, если кто-то смог преднамеренно изменить хотя бы одну запись, и эта информация была утечка.

Теперь, имея доступ «SA», можно изменять не только базу данных приложения, но и любую другую базу данных в системе. Итак, спросите ваших заинтересованных сторон, что они будут делать, если вы сделаете копию ВСЕХ своих баз данных и отправите ее в газету. Потому что это может произойти, если недовольный сотрудник обнаружит, что эта дыра в безопасности существует.

Продавец сказал, что они могут взломать пароль. Это BS. Приложению требуется доступ к паролю в открытом тексте, чтобы использовать его, поэтому ключ для его расшифровки будет храниться в незашифрованном виде рядом с ним. Также, как упоминалось ранее, настоящая проблема не в том, что кто-то находит этот пароль; люди, которые используют эту систему через уязвимость, получат полный доступ ко всем вашим базам данных, даже не увидев пароль.

Наиболее вероятная причина необходимости SA заключается в том, что приложение должно взаимодействовать с агентом SQL. По крайней мере, это одна из самых сложных функций для правильной реализации, и большинство людей просто выбирают маршрут «использовать SA», чтобы обойти его. Сам запрос «SA» может быть вызван тем, что поставщик не знает, как проверять разрешения sysadmin.

Есть два решения, которые вы можете попробовать:

1. Переименуйте SA (во всяком случае, в целях безопасности) и создайте новую учетную запись с именем «SA» с ограниченными правами. (Никогда не пробовал это, но это должно работать)

2. Не устанавливайте программное обеспечение. Вы, как профессионал, не можете нести ответственность за это действие, поэтому вам не следует устанавливать его. Чтобы дать вам сравнение, попросите сантехника провести газовую линию прямо через камин, а не вокруг него, чтобы сэкономить деньги. Вы можете смеяться над этим изображением, но я считаю, что это подходящее сравнение - это программное обеспечение взорвется рано или поздно, возможно, рано. И когда это произойдет, это может разрушить и бизнес.

Если все это не мешает «им» требовать этого программного обеспечения, последняя рекомендация, которую я могу вам дать, - запустить. Если что-то случится с данными, вы будете первыми, кто будет нести ответственность. Итак, с этим приложением у вас, вероятно, нет никакой гарантии занятости, поэтому найдите работодателя, который даст вам хотя бы немного.

Я вижу две линии атаки на это.

• Соответствие . Есть ли в вашем магазине обязательные критерии соответствия? Внимательно изучите его формулировку и посмотрите, найдете ли вы что-либо, что не соответствует «требованию» приложения. Если вы найдете что-нибудь, что мешаетsa использованию приложением, у вас есть пуленепробиваемый водонепроницаемый чехол, так как приложение сделает ваш бизнес ответственным и т. Д. И т. Д.

• Пользователь Admin Доступ . Убедитесь, что вы четко представляете себе случай, когда приложение, для которого требуется saдоступ, фактически предоставляет saдоступ всем корпоративным пользователям, имеющим права администратора на рабочих станциях, на которых установлено приложение. Невозможно спрятать saпароль от локальных администраторов, на которых запущено приложение, это факт, и никакое «шифрование» не может этого предотвратить. Не существует локального корня доверия, к которому локальный администратор не может добраться, если захочет. Разъясните, что наличие приложения, которое требует, saравнозначно предоставлению saпривилегий всем пользователям, запускающим приложение. Объясните, что это значит, что эффективно могут делать пользователи:

  • умение читать любые данные на сервере, не только из этого приложения, но и из любой другой базы данных, размещенной на этом сервере
  • возможность изменять любые данные на сервере, опять же из любой другой базы данных на том же сервере
  • возможность стереть любые следы его действий после внесения изменений
  • возможность изменять любой аудит и историю, чтобы казалось, что определенные действия были выполнены другим пользователем
  • возможность использовать учетные данные SQL Server для эскалации атаки на любой другой ресурс, который доверяет этому серверу. Это может подразумевать любой другой SQL Server, но также и другие ресурсы, включая, но не ограничиваясь, общие файловые ресурсы, серверы Exchange и т. Д., Поскольку SQL Server можно использовать просто в качестве отправной точки.

Дайте понять лицам, принимающим решения, что принятие этого приложения подразумевает доведение каждого сотрудника, имеющего доступ администратора, к рабочим станциям, на которых запущено приложение, со всеми перечисленными выше привилегиями. Поставщик попытается защитить свою позицию, используя тот или иной метод «шифрования» saпароля для приложения. Это не держит воду. Не существует схемы шифрования, способной противостоять атаке администратора. И проясните, что количество технических навыков, необходимых для поиска локально «скрытого» пароля, совершенно не имеет значения. Сотрудники не собираются делать это сами, один из них найдет для них Google и найдет простой в использовании скрипт, который это делает.

Во-первых, пароль хранится в виде открытого текста? Вы должны голосовать со своим кошельком. Тот, кто считает это приемлемым, должен быть разорен.

Вот анология, которая может помочь вам объяснить проблему: сотруднику Алисе нужен доступ на первый этаж. Вы даете ей главный ключ от всего здания или только ключ от первого этажа? Ответ: Вы даете ей только ключи от первого этажа. Зачем? Потому что это уменьшает вероятность случайного или преднамеренного повреждения. Если Алиса не сможет добраться до серверной комнаты на втором этаже, то она никогда не сделает там ничего плохого.

Это принцип наименьших привилегий.

Относительно того, почему приложению необходимо использовать учетную запись sa, на этот вопрос PerfMon или Extended Events должны иметь возможность ответить. Создайте трассировку PerfMon, используя шаблон T-SQL, возможно, отфильтрованный по имени приложения.

Сверх того, вот еще один аргумент против использования sa: использование учетной записи sa требует, чтобы служба SQL Server находилась в смешанном режиме аутентификации. Лучше использовать аутентификацию только в Windows, потому что мы можем использовать все безопасные функции Kerberos.

С технической точки зрения нет причин, по которым приложению потребуются разрешения SA. Вероятно, произошло то, что разработчики приложения, вероятно, проверили, имеет ли их логин разрешения sysadmin, и если нет, то просто выдает сообщение об ошибке. Таким образом, они могут утверждать, что приложение требует прав SA.

Если вам нужно это приложение, я бы запустил его в отдельном экземпляре, в котором больше ничего нет.

Возможно, ваш поставщик запрашивает / запрашивает "sa", потому что где-то в своем приложении они используют XP_CMDSHELL. (Не заставляйте меня начинать с возможного ущерба при неограниченном доступе к XP_CMDSHELL. Достаточно сказать, что это потенциально открывает не только ваши данные, но и хост-компьютер и, возможно, что-нибудь еще в вашей сети для доступа, подобного администратору)

Если есть законная необходимость, вы можете предоставить ограниченный доступ через учетную запись прокси. См., Например, BOL: http://msdn.microsoft.com/en-us/library/ms175046.aspx

Ни одно приложение не должно требовать учетной записи SA и пароля для работы.

Однако я установил продукт управления ИТ-услугами, и в процессе установки у вас есть возможность предоставить учетные данные учетной записи SA, чтобы позволить установщику создать БД и присоединить учетную запись к БД для использования программным обеспечением. Учетные данные учетной записи SA нигде не сохраняются в журналах приложения или установщика. Это программное обеспечение также предоставляет возможность использовать предварительно созданную базу данных во время установки.

Поэтому я бы просто подтвердил, требуется ли для установки учетная запись SA или для работы этого программного обеспечения для управления ИТ-услугами.

Если установка: создайте временную учетную запись 'sa' - выполните установку - и удалите учетную запись.

Если операция: Избегайте этого программного обеспечения, как чума. (или установите автономный сервер SQL, на котором будет размещаться только эта база данных.)

Любой предоставленный по умолчанию параметр безопасности системы SQL Server должен быть изменен. Рекомендуется не использовать смешанный режим (включает аутентификацию Windows и SQL Server) для аутентификации. Вместо этого переключитесь только на проверку подлинности Windows - что обеспечит применение политики паролей Windows - проверку длины пароля, срока его службы и истории. Особенностью политики паролей Windows, которая отличает ее от аутентификации SQL Server, является блокировка входа в систему - после нескольких неудачных попыток входа в систему вход в систему блокируется и становится непригодным для дальнейшего использования.

С другой стороны, аутентификация SQL Server не предоставляет каких-либо методов для обнаружения попыток атаки методом перебора, и, что еще хуже, SQL Server даже оптимизирован для обработки большого количества попыток быстрого входа в систему. Таким образом, если аутентификация SQL Server является обязательной в определенной системе SQL Server, настоятельно рекомендуется отключить вход в систему SA