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

Опубликовано:
30 января в 13:52
  • 4

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

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

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

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

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

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

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

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

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

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

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

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

При установке 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.

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

19
Подписаться

Комментарии

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

Андрей, разве использование доменной служебной учетной записи не проводит к зависаниям workflow при даже невысокой нагрузки на службу? 

Тимур, подобная ситуация возникала в ряде случаев из-за задержек при обращении к Active Directory.

Такое поведение не является нормальным и по данным ситуациям оформлены соответствующие замечания.

Использование аутентификации с помощью логинов SQL, подвергает систему опасности и это стоит использовать, только в случае, если Windows-аутентификация не позволяет корректно работать.

Андрей Ардашев: обновлено 30.01.2018 в 15:28
Андрей Ардашев: обновлено 30.01.2018 в 15:30

Раздел "Безопасность файлов БД и резервных копий" я бы дополнил ещё и стандартным механизмом Transparent Data Encryption, который позволяет защитить резервные копии и сами файлы баз данных от случайного изъятия или кражи. В случае кражи, без ключей - резервная копия не может быть восстановлена, а файлы базы данных просто смонтированы на сервер, который не был подготовлен должным образом.

При использовании механизма, стоит помнить, что он не защищает от злоумышленников с правами администратора сервера MS SQL и увеличивает потребление ресурсов процессора. 

Данный механизм работает и с DIRECTUM 5.

Антон Гончаров: обновлено 05.02.2018 в 18:59

Антон, благодарю за дополнение!

Авторизуйтесь, чтобы написать комментарий