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

В рамках данной статьи мы не будем концентрироваться на какой‑то конкретной СУБД, а рассмотрим те советы, которые подойдут любой базе данных.

Очевидные вещи, о которых часто забывают

Прежде всего, при размещении сервера важно помнить о физической безопасности. Сервер должен размещаться в серверной, куда ограничен доступ посторонним, в запирающемся серверном шкафу.

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

Прежде всего, версия используемой ОС должна быть стабильной; не стоит экспериментировать с тестовыми релизами. При установке ОС нужно выбирать только те компоненты, которые действительно нужны для работы СУБД. Вряд ли для работы СУБД вам понадобится docker или microk8s на том же сервере, соответственно, не нужно их указывать при установке системы. После установки ОС не забудьте проверить обновления.

При построении архитектуры приложения помним правило: один сервер — одна роль. В нашем случае это означает, что на наш сервер с базой данных нельзя устанавливать что‑либо другое. Например, очень плохая идея ставить на один узел веб сервер и СУБД. В случае компрометации веб сервера злоумышленник сможет быстро захватить базу данных. Конечно, если мы говорим про среду разработки, там подобные компромиссы допустимы, но в продуктиве, даже если это веб ресурс для внутренней сети, такое делать не нужно.

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

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

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

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

Убираем лишнее

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

Так, для MS SQL Server необходимо отключить xp_cmdshell, xp_dirtree и другие встроенные процедуры, которые нам не требуются для работы нашего приложения. Также отключаем Common Language Runtime (CLR), SQL Browser service и смешанную аутентификацию, так как этот механизм не считается безопасным. Также в продуктивной среде необходимо удалить учебные базы Northwind и AdventureWorks.

Для MySQL и MariaDB после установки необходимо выполнить скрипт mysql_secure_installation, чтобы удалить установленные по умолчанию базы и учетные записи. Отключите привилегию FILE для того, чтобы запретить пользователям читать и изменять файлы.

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

Учетки для доступа

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

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

Если к СУБД имеют доступа несколько пользователей, например, несколько разработчиков, то важно следить за тем, чтобы эти аккаунты использовались только мере необходимости, а затем блокировались. Дело в том, что утечка привилегий является достаточно распространенной проблемой в системах баз данных, где дополнительные привилегии предоставляются по мере необходимости и не отменяются. Например, разработчику был предоставлен временный доступ для создания нужных таблиц в базе. Затем разработчик закончил свои работы, но доступ по его учетной записи остался. Это не очень хорошо. После окончания работ доступ для учетки должен быть заблокирован.

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

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

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

Защищаем трафик

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

Настройте взаимодействие с базой данных таким образом, чтобы разрешать только зашифрованные соединения, не допуская передачу трафика в открытом виде. Установите на сервер доверенный цифровой сертификат. Клиентское приложение для подключения с использованием TLSv1.2+ с современными шифрами (например, AES‑GCM). На стороне клиента также должна быть проверка правильности цифрового сертификата, используемого для подключения.

Мониторинг всего

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

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

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

Заключение

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

Все актуальные методы и инструменты обеспечения информационной безопасности можно освоить на онлайн-курсах OTUS: в каталоге можно посмотреть список всех программ, а в календаре — записаться на открытые уроки.