Почему плохая практика разрешать всем использовать логин sa?

Даже Microsoft не рекомендует использовать режим аутентификации SQL Server , но наши приложения требуют этого.

Я читал, что лучше не разрешать пользователям использовать saлогин напрямую, а использовать аутентификацию Windows и разрешать этим учетным записям (или группам учетных записей) привилегии sysadmin.

• Разве это не одно и то же? Каковы преимущества / недостатки?
• Как наилучшая практика повышает безопасность моих экземпляров SQL Server?
• Это относится только к производственным экземплярам или к нашим внутренним экземплярам разработки?

У вас есть несколько разных вопросов, поэтому я постучу по ним индивидуально:

«Я читал, что лучше не разрешать пользователям использовать логин sa напрямую, а использовать аутентификацию Windows»

Здесь вы смешиваете две вещи: концепцию SA и концепцию аутентификации SQL и аутентификации Windows.

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

Если вы решите использовать аутентификацию SQL, тогда SA - это всего лишь один логин аутентификации SQL. Это имя пользователя по умолчанию для администратора, так же как Администратор в аутентификации Windows. В этом одном экземпляре есть локальные суперсилы, но не глобальные суперсилы во всех экземплярах.

«... и разрешить этим учетным записям (или группам учетных записей) привилегии sysadmin».

Какой бы метод аутентификации вы ни выбрали, в идеале вы хотите следовать принципу наименьших привилегий: предоставить людям минимальные права, необходимые им для выполнения своей работы, и не более.

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

«Как наилучшая практика повышает безопасность моих экземпляров SQL Server?»

Вы хотите сделать две вещи:

1. Не дать людям взломать сервер
2. Когда они сломают сервер, смогут точно определить, кто это сделал

Первый выполняется по принципу наименьших привилегий: предоставление людям только тех разрешений, которые им необходимы, и ничего более.

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

Я знаю, что вы думаете: «Но мы кодируем приложения, и приложение требует входа в систему». Да, дайте приложению свой логин, и разработчики должны знать этот пароль, но этот логин должен быть настолько лишен разрешений, что никто в здравом уме не захочет его использовать. Например, он может быть только в ролях db_datareader и db_datawriter, и ничего больше. Таким образом, он может вставлять, обновлять, удалять и выбирать данные, но не обязательно изменять схемы, добавлять индексы, изменять хранимые процедуры и т. Д.

«Это относится только к производственным экземплярам или к нашим внутренним экземплярам разработки?»

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

На самом деле, если вы читаете этот технический документ: документ об отделении обязанностей SQL Server

Он скажет вам, что НИ ОДИН не должен использовать привилегии sysadmin для своей учетной записи. Ваша учетная запись для ежедневного доступа должна иметь минимальный доступ, а не явные права системного администратора. Учитывая их, CONTROL SERVER фактически близок к тому, чем является системный администратор, и затем позволяет вам по-прежнему отказывать в доступе / отменять доступ там, где он им не нужен. Предоставление прав sysadmin кому-либо становится проблемой, если вы обязаны соблюдать какие-либо стандарты соответствия ИТ. Большинство стандартов требуют минимального использования роли системного администратора.

Я отключаю и переименовываю учетную запись «sa», как вы это делаете со встроенной учетной записью администратора в ОС. Только для использования в чрезвычайных ситуациях.

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

Если вы подчиняетесь внешнему регулятивному контролю или стандартам (SOX, PCI и т. Д.), То вы

• провалит аудит
• терпят неудачу на ваших ежемесячных проверках PCI

Разработчики должны иметь db_owner на сетевом SQL Server только для разработки.

Если все ваши SQL-серверы находятся в сети со стандартной сборкой (то есть с одной и той же учетной записью службы), то sa in one предоставляет права на них всех.

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

Там нет плюсов.

sa = сисадмин

Вход в систему с sa дает пользователю возможность выполнять все следующие действия: - удалять и создавать базы данных - изменять объекты в базе данных - удалять и создавать логины - изменять пароли - удалять все данные

Предоставление учетной записи Windows привилегий sysadmin выполняет то же самое.

Этот список можно продолжить, но это должно дать вам несколько веских причин, чтобы НИКОГДА не позволять не администратору использовать sa.

Вы должны создать учетную запись Windows или SQL с минимальными правами, необходимыми для работы приложений. (т.е. вход в систему, доступ к хранимым процедурам и представлениям)

Лучше всего установить надежный пароль и забыть его.

У меня сейчас есть два варианта, почему не следует иметь слабую учетную запись SA. Если у вас слабый / пустой пароль для SA, один злой человек (переведите это «дружественный коллега») может:

• включите системную процедуру xp_cmdshell и, используя привилегии учетной записи службы Sql Server, нанесите ущерб вашему локальному ящику (создайте / удалите файлы ..). Низкий уровень безопасности для SA на самом деле мало говорит о настройках экземпляра, но может означать, что пользователь сервиса может следовать плохим практикам (например, быть администратором :-));

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

Я не буду указывать на очевидные факты, что он может отбрасывать базы данных, логины ... и т. Д.

• Разве это не одно и то же? Каковы преимущества / недостатки?

• Не обязательно: например, - на экземпляре SQL Server с вашего ноутбука разница между аутентификацией Windows и аутентификацией SQL означает, что теоретически внешний злоумышленник может использовать только учетную запись SQL, поскольку аутентификация Windows не может использоваться за пределами вашего собственного домена Счет. Пользователь может сканировать соседние ноутбуки из торгового центра, в котором вы пьете кофе, и может увидеть, что у вас установлен и запущен экземпляр SQL, и может попытаться развлечься бесплатно. Не то, чтобы это могло случаться часто ... но это возможно :-).

• Как наилучшая практика повышает безопасность моих экземпляров SQL Server?

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

• Это относится только к производственным экземплярам или к нашим внутренним экземплярам разработки?

• Допустим, я бы предложил внедрить лучшие практики безопасности (протестированные и модифицированные в соответствии с потребностями вашей среды), по крайней мере, на производстве. Но если в процессе разработки вы также используете производственные данные (чувствительные ... и т. Д.), Это убедительно свидетельствует о том, что вам также необходимо изменить свои методы разработки.

Чтобы ответить на ваш последний вопрос, мы используем учетные записи SA во всех наших базах данных для разработки (с паролем «sa»!)

Однако важно отметить, что мы не храним данные и не генерируем их. Наши базы данных используются исключительно для хранилища данных для приложения C / C ++. Эти базы данных разработки содержат только тестовые данные и часто создаются, удаляются, модифицируются и т. Д. \

Кроме того, что не менее важно, все базы данных разработки устанавливаются на компьютерах разработчиков. (По крайней мере, одна копия на разработчика!) Так что, если кто-то испортит всю установку, он испортит только себя, и больше никого.

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

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

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

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