Железный RX. Обеспечиваем безопасность СУБД

Продолжаем серию статей посвящённых настройкам безопасности DirectumRX. В этот раз пройдёмся по ошибкам безопасности MSSQL Server. В настоящее время из разных источников звучит мысль, что теперь в эпоху новой индустриальной революции, построения информационного общества, основным средством становится не оборудование и сооружения, а информация и интеллектуальная собственность.

Дисклеймер 

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

Физическая безопасность

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

Крайний случай физической незащищенности - рабочая система на ноутбуке руководителя, а ноутбуки, как известно, часто являются целью кражи.

Доступ к серверу или носителю, где располагается БД системы документооборота должен быть ограничен и регламентирован:

• необходимо размещать сервер с СУБД в серверной комнате с контролем доступа и видео-наблюдением
• использовать облачный сервис документооборота

Один сервис - один сервер

Довольно часто в практике встречаются ситуации, когда системные инженеры размещают СУБД на одном сервере с множеством других не связанных сервисов. Как известно, безопасность на столько крепка, на сколько крепко самое слабое звено, таким образом уязвимость любого имеющегося сервиса, может открыть доступ к получению злоумышленником данных из БД системы.

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

Безопасность доступа к БД

Когда говорим о безопасном доступе к БД , необходимо иметь ввиду два способа доступа:

• пользовательский и административный доступ к среде управления СУБД
• к среде запуска процесса СУБД и его окружению и файлам БД

При установке MSSQL пользователю предлагается выбрать учетные записи под которыми будут работать сервисы MSSQL:

• Local System - неограниченный доступ к системным ресурсам конкретного сервера
• Local service - права доступа обычного пользователя системы, но с ограничением работы с сетевыми ресурсами
• Network Service - аналогично Local Service, предоставляет права обычного пользователя к ресурсам локальной системы, но также предоставляет возможность работы с сетевыми ресурсами

Какую учетную запись стоит выбрать?

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

Ключевое слово - индивидуальную.Что же будет, если мы создадим доменную учетную запись для всех сервисов СУБД в вашей локальной сети? Верно, вирус-шифровальщик будет рад зашифровать все ваши БД разом.

Аналогично поступаем для всех сервисов СУБД и агентов, выдаём ограниченные индивидуальные доменные учетные записи. Исключением из правил является использование отказоустойчивого кластера MSSQL, в данном случае потребуется использовать идентичные учетные записи для сервисов СУБД в рамках кластера.

Доступ к СУБД

Пора забыть о парольной аутентификации, да здравствует доменная аутентификация!

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

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

Минимальный набор действий для обеспечения безопасного доступа:

• перевести MSSQL Server в режим работы только с windows-учетными записями
• отключаем логин SA
• права sysadmin выдать только двум учетным записям: локальные администраторы и у сервиса агентов MSSQL Server 
• в группе "Локальные администраторы" не должно быть учетной записи из под которой выполняется MSSQL Server 

Сетевая безопасность СУБД

В случае, если сервер СУБД располагается в сети небольшого предприятия, велика вероятность, что для серверов не выделена серверная подсеть, ограниченная от общей сети предприятия брандмауэром. В таком случае потребуется дополнительное повышение безопасности:

• использовать другой порт для подключения к SQL, отличный от стандартного – с использованием многочисленных сканирующих утилит, можно легко  определить все MSSQL серверы организации, чтобы усложнить задачу злоумышленнику можно изменить порт для подключения к СУБД на любой другой, не используемый на сервере СУБД
• отключить SQLServer Browser – таким образом исключается возможность определения списка sql сервером с использованием management studio
• отключить Net.Pipe – это довольно старый протокол, который уже много времени не обновлялся и вероятно содержит уязвимости
• отключить все дополнительные сервисы, если они сознательно не используется, т.к. они фактически образуют ещё одну брешь в безопасности системы

Безопасность файлов БД и резервных копий

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

• необходимо ограничить доступ к файлам БД с помощью доменных политик. К данным должен иметь доступ только администратор домена, администратор баз данных, а также индивидуальная учетная запись СУБД
• всегда использовать антивирусыне средства защиты (с агентами, либо безагентные), в случае использования антивируса с агентом, чтобы не снижалась производительность СУБД, добавьте в исключения антивируса директории, где располагаются исполняетесь файлы СУБД, папки резервных копий и все файлы данных БД
• в случае, если резервные копии планируется передавать через сеть, либо могут храниться на недостаточно безопасных носителях, выполняйте архивирование резервных копий с шифрованием. Внимание, используйте только необходимые и достаточные алгоритмы сжатия и шифрования, т.к. при необходимости восстановления или проверки резервных копий может потребоваться в короткий срок расшифровать данные

SQL Server Audit

SQL Server Audit - это мощное средство, предназначенное для отслеживания всех событий и запросов к серверу. Данный инструмент можно найти в SQL Management Studio, его область применения широка — от профилирования использования, как средство отслеживания изменений и активности пользователей в целях обеспечения информационной безопасности. Подробнее о данном инструменте можно почитать на официальном сайте MSDN.

SQL Server Audit довольно ресурсоемкий инструмент и применять постоянно обычно не требуется. Данный инструмент можно применять в случае анализ возможных угроз либо для проверки применённых настроек безопасности.

Вместо заключения

В данной статье мы рассмотрели базовые настройки обеспечения безопасности СУБД, как основного элемента системы документооборота. В случае модификации или вывода из строя файлов сервисных служб, клиентских приложений, ощутимых проблем это не понесёт, подобные ситуации довольно быстро исправить с использованием инсталлятора системы DirectumRX, в случае модификации или повреждения файлов данных и резервных копий, есть риск потерять существенное количество ресурсов для восстановления утраченных данных.

Поэтому безопасность СУБД должна рассматриваться в высоком приоритете, а предоставленные рекомендации можно рассматривать в качестве чек-листа перед планирование инфраструктуры и окружения системы DirectumRX.

Продолжение следует.