У вас есть несколько разных вопросов, поэтому я постучу по ним индивидуально:
«Я читал, что лучше не разрешать пользователям использовать логин sa напрямую, а использовать аутентификацию Windows»
Здесь вы смешиваете две вещи: концепцию SA и концепцию аутентификации SQL и аутентификации Windows.
Аутентификация SQL - это список имен пользователей и паролей, которые хранятся в каждом SQL Server. Тот факт, что он хранится в SQL, является первой проблемой. Если вам нужно изменить пароль для входа в систему, вы должны изменить его на каждом сервере (или поддерживать разные пароли на разных серверах). С помощью аутентификации Windows вы можете централизованно отключать входы в систему, изменять пароли, устанавливать политики и т. Д.
Если вы решите использовать аутентификацию SQL, тогда SA - это всего лишь один логин аутентификации SQL. Это имя пользователя по умолчанию для администратора, так же как Администратор в аутентификации Windows. В этом одном экземпляре есть локальные суперсилы, но не глобальные суперсилы во всех экземплярах.
«... и разрешить этим учетным записям (или группам учетных записей) привилегии sysadmin».
Какой бы метод аутентификации вы ни выбрали, в идеале вы хотите следовать принципу наименьших привилегий: предоставить людям минимальные права, необходимые им для выполнения своей работы, и не более.
Не думайте о них как о логинах - это люди, которые могут вас уволить. Если они удалят базу данных или случайно отключат ваши задания резервного копирования, их не уволят, потому что по умолчанию SQL не отслеживает, кто что сделал. Вы будете уволены, потому что это случится, и вы не сможете сказать, кто это сделал.
«Как наилучшая практика повышает безопасность моих экземпляров SQL Server?»
Вы хотите сделать две вещи:
- Не дать людям взломать сервер
- Когда они сломают сервер, смогут точно определить, кто это сделал
Первый выполняется по принципу наименьших привилегий: предоставление людям только тех разрешений, которые им необходимы, и ничего более.
Второй способ достигается путем предоставления каждому человеку своего логина, недопущения совместного входа в систему (например, позволяя всем использовать одно и то же имя пользователя / пароль) и, в идеале, аудита входа в систему. Вы, вероятно, не сделаете эту последнюю часть сразу, потому что это немного болезненно, но давайте сначала разберемся с этими частями, чтобы вы могли добавить аудит позже, когда кто-то отбросит базу данных, и ваш босс захочет узнать почему.
Я знаю, что вы думаете: «Но мы кодируем приложения, и приложение требует входа в систему». Да, дайте приложению свой логин, и разработчики должны знать этот пароль, но этот логин должен быть настолько лишен разрешений, что никто в здравом уме не захочет его использовать. Например, он может быть только в ролях db_datareader и db_datawriter, и ничего больше. Таким образом, он может вставлять, обновлять, удалять и выбирать данные, но не обязательно изменять схемы, добавлять индексы, изменять хранимые процедуры и т. Д.
«Это относится только к производственным экземплярам или к нашим внутренним экземплярам разработки?»
Я думаю, что это в равной степени относится и к случаям разработки, потому что я обычно беспокоюсь о том, что люди что-то сломают. Люди просто любят ломать серверы в процессе разработки. И, конечно же, когда пришло время объединить список изменений для перехода на рабочую среду, мне нужно знать, действительно ли конкретный индекс жизненно важен для приложения или какой-то тупоголовый просто запустил помощник по настройке базы данных и сказал ему применить все изменения , Правильные разрешения помогают уменьшить эту боль.