Статья по безопасности баз данных (Database Security Cheat Sheet)

Введение

Эта статья описывает безопасную настройку SQL-баз данных: MySQL, PostgreSQL, MariaDB и Microsoft SQL Server.

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

Защита от инъекций на уровне приложения — в SQL Injection Prevention Cheat Sheet.

Нереляционные системы (MongoDB, Redis, Cassandra, DynamoDB и др.) — в NoSQL Security Cheat Sheet.

Защита серверной базы данных

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

Отключить сетевой (TCP) доступ и требовать доступ только через локальный сокет или именованный канал.
Настроить привязку СУБД только к localhost.
Ограничить доступ к порту БД правилами фаервола для явно перечисленных хостов.
Разместить сервер БД в отдельной DMZ, изолированной от прикладного сервера.
Веб-инструменты администрирования (phpMyAdmin, pgAdmin и т.п.) защищать аутентификацией, HTTPS и сетевыми ограничениями.

Если приложение выполняется на недоверенной системе (например толстый клиент), оно должно обращаться к бэкенду только через API, где можно применить контроль доступа и ограничения. Прямые подключения толстого клиента к серверной БД допускать нельзя.

Защита на транспортном уровне

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

Разрешить только зашифрованные соединения к БД.
Установить на сервер доверенный цифровой сертификат.
Подключать клиент по TLS 1.2+ с современными шифрами (например AES-GCM или ChaCha20).
Проверять на клиенте корректность сертификата сервера.

Дополнительно — Transport Layer Security Cheat Sheet.

Настройка безопасной аутентификации

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

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

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

Проверка актуальности учётных записей.
Проверка назначенных прав.
Удаление учётных записей при выводе приложения из эксплуатации.
Смена паролей при уходе сотрудников или подозрении на компрометацию.

Для Microsoft SQL Server рассмотрите Windows или интегрированную аутентификацию: используются учётные записи Windows, отдельные учётные записи SQL Server не нужны, а учётные данные приложения в конфиге не хранятся — соединение идёт от имени пользователя Windows, под которым запущено приложение. Для MySQL схожий подход дают плагины Windows Native Authentication.

Безопасное хранение учётных данных БД

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

Лежит вне корня веб-сервера.
Имеет права доступа так, что читать его могут только нужные пользователи.
Не попадает в системы контроля версий.

По возможности дополнительно шифруйте или защищайте встроенными средствами, например шифрованием секций web.config в ASP.NET.

Настройка безопасных прав доступа

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

Не используйте встроенные учётные записи root, sa или SYS.
Не выдавайте учётной записи административные права на экземпляр СУБД.
Разрешайте подключение только с разрешённых хостов — часто это localhost или адрес прикладного сервера.
Учётная запись должна иметь доступ только к нужным базам. Для разработки, UAT и продакшена — отдельные базы и отдельные учётные записи.
Выдавайте только необходимые права на объекты. Большинству приложений достаточно SELECT, UPDATE и DELETE. Учётная запись не должна быть владельцем базы — это снижает риск эскалации привилегий.
По возможности избегайте database links и linked servers; если они нужны — отдельная учётная запись с минимальным набором прав на базы, таблицы и системные привилегии.

В критичных по безопасности системах права задают ещё точнее:

На уровне таблиц.
На уровне столбцов.
На уровне строк.
Запрет прямого доступа к базовым таблицам и работа только через ограниченные представления (views).

Конфигурация и укрепление СУБД

Операционную систему сервера БД нужно укреплять по проверенным базовым профилям, например CIS Benchmarks или Microsoft Security Baselines.

Саму СУБД также следует правильно настроить и ужесточить. Универсальные принципы:

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

Ниже — дополнительные рекомендации по отдельным продуктам.

Укрепление Microsoft SQL Server

Отключите xp_cmdshell, xp_dirtree и другие хранимые процедуры, если они не нужны.
Отключите выполнение Common Language Runtime (CLR).
Отключите службу SQL Browser.
Отключите смешанную аутентификацию (Mixed Mode), если она не обязательна.
Убедитесь, что демонстрационные базы Northwind и AdventureWorks удалены.
См. материалы Microsoft по защите SQL Server.

Укрепление MySQL или MariaDB

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

© Перевод на русский язык. Оригинальные материалы: OWASP Cheat Sheet Series.
Этот проект использует материалы OWASP, распространяемые по лицензии CC BY-SA 4.0.

Безопасность баз данных