Урок 6: Безопасность баз данных

1. Введение в базы данных: "Королевские драгоценности"

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

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

Два основных типа баз данных:

Реляционные (SQL): Данные хранятся в строго структурированных таблицах, связанных между собой. Похоже на набор Excel-таблиц с жесткими правилами. Примеры: PostgreSQL, MySQL, Microsoft SQL Server.
Нереляционные (NoSQL): Гибкие хранилища, где данные могут иметь различную структуру. Похоже на шкаф с папками, в каждой из которых лежит документ в своем формате. Примеры: MongoDB (документо-ориентированная), Redis (ключ-значение).

2. Реляционные базы данных и язык запросов SQL

SQL (Structured Query Language) — это стандартный язык для общения с реляционными базами данных. Он делится на несколько подгрупп:

DDL (Data Definition Language): Определение данных. Команды для создания и изменения структуры таблиц (CREATE TABLE, ALTER TABLE).
DML (Data Manipulation Language): Манипуляция данными. Команды для работы с содержимым таблиц (SELECT, INSERT, UPDATE, DELETE).
DCL (Data Control Language): Управление доступом к данным. Это самая важная часть для безопасности. Команды: GRANT (выдать права) и REVOKE (отозвать права).

PostgreSQL — одна из самых мощных, надежных и расширяемых open-source СУБД. Мы будем использовать ее в качестве основного примера для SQL.

-- Пример DML: выбрать всех пользователей из таблицы 'users'
SELECT id, username, email FROM users WHERE is_active = TRUE;

-- Пример DCL: выдать пользователю 'reporter' права только на чтение таблицы 'sales'
GRANT SELECT ON TABLE sales TO reporter;

-- Отозвать у пользователя 'intern' права на удаление данных
REVOKE DELETE ON TABLE customers FROM intern;

3. Эксплуатация: SQL & NoSQL Injection

Это самая известная и до сих пор одна из самых опасных атак на веб-приложения. Она возникает, когда приложение неверно обрабатывает пользовательский ввод и позволяет атакующему "внедрить" свой собственный SQL-код в запрос к базе данных.

Классическая SQL-инъекция

Представьте, что на сайте есть поле для ввода ID пользователя, и код формирует запрос так:

$query = "SELECT * FROM users WHERE id = " + $user_input;

Если честный пользователь введет `123`, запрос будет: SELECT * FROM users WHERE id = 123.

Но что, если атакующий введет 123 OR 1=1? Приложение склеит строку и отправит в базу данных убийственный запрос:

SELECT * FROM users WHERE id = 123 OR 1=1

Условие 1=1 всегда истинно, поэтому оператор OR сделает все выражение истинным, и база данных вернет ВСЕХ пользователей из таблицы, игнорируя ID.

Последствия SQL-инъекции: утечка всех данных, обход аутентификации, изменение и удаление данных, а в некоторых случаях — выполнение команд на сервере и полный захват системы.

NoSQL-инъекция в MongoDB

MongoDB использует для запросов объекты в формате, похожем на JSON. Атака заключается во внедрении операторов MongoDB (таких как $gt - больше чем, $ne - не равно) в пользовательский ввод.

Если код ожидает логин и пароль в виде { "user": "admin", "pass": "123" }, атакующий может подсунуть в поле пароля объект { "$ne": "some_random_string" }. Запрос превратится в "найти пользователя 'admin', у которого пароль НЕ равен 'some_random_string'", что, скорее всего, будет правдой, и аутентификация будет пройдена.

4. Безопасная эксплуатация: Принципы защиты

Защита от инъекций и других атак — это многоуровневый процесс.

Подготовленные выражения (Prepared Statements): Это главный метод защиты от SQL-инъекций. Код и данные передаются в базу данных раздельно. Сначала отправляется шаблон запроса с плейсхолдерами (?), а затем — данные, которые будут вставлены в эти плейсхолдеры. База данных никогда не спутает данные с кодом.
Принцип наименьших привилегий (Principle of Least Privilege): Учетная запись, от имени которой приложение подключается к БД, должна иметь минимально необходимый набор прав. Если веб-приложению нужно только читать данные из таблицы `products`, дайте ему только `GRANT SELECT ON products`. Оно не должно иметь прав на удаление или изменение других таблиц.
Валидация и очистка ввода (Input Validation & Sanitization): Всегда проверяйте данные, приходящие от пользователя. Если ожидается число — убедитесь, что это число. Удаляйте или экранируйте потенциально опасные символы.

5. Технологические решения защиты данных средствами СУБД

Современные СУБД предоставляют мощные встроенные инструменты для обеспечения безопасности.

Управление доступом (Access Control)

Ролевая модель доступа (RBAC - Role-Based Access Control) — это стандарт де-факто. Вместо того чтобы выдавать права каждому пользователю по отдельности, вы создаете роли (например, `read_only_role`, `data_analyst_role`), наделяете их правами, а затем присваиваете эти роли пользователям. Это значительно упрощает управление.

Шифрование (Encryption)

Шифрование данных в БД бывает двух видов:

Шифрование при передаче (Encryption in Transit): Защищает данные во время их путешествия по сети от клиента к серверу БД. Реализуется с помощью SSL/TLS. Вы должны всегда принудительно использовать зашифрованные соединения.
Шифрование при хранении (Encryption at Rest): Защищает файлы самой базы данных на диске. Если злоумышленник физически украдет жесткий диск, он не сможет прочитать данные. Основная технология — TDE (Transparent Data Encryption), которая шифрует данные "на лету" перед записью на диск и расшифровывает при чтении, будучи прозрачной для приложения.

Аудит и логирование (Auditing & Logging)

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

Что нужно логировать?
• Успешные и неудачные попытки входа.
• Все DDL-операции (CREATE, ALTER, DROP).
• Все DCL-операции (GRANT, REVOKE).
• Доступ к критически важным таблицам (например, к таблице с пользователями).

Маскирование и анонимизация данных

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

6. Практическое задание: Настройка безопасного доступа

Вы — администратор базы данных для нового блога. В PostgreSQL у вас есть таблица articles (id, title, content, author_id, published_at). Вам нужно создать двух пользователей с разными уровнями доступа.

Напишите SQL-команды (DCL) для выполнения следующих задач:

Создайте новую роль (пользователя) с именем `content_editor` с возможностью входа в систему и паролем.
Создайте новую роль `guest_reader` (без права входа, это будет роль-шаблон).
Дайте роли `content_editor` полные права на таблицу `articles` (чтение, вставка, обновление, удаление).
Дайте роли `guest_reader` права только на чтение (SELECT) таблицы `articles`.
Представьте, что `content_editor` уволился. Отзовите у него все права на таблицу `articles`.
Объясните одной фразой, почему нельзя давать веб-приложению права суперпользователя `postgres`.

Это задание научит вас главному принципу безопасности БД: выдавать минимально необходимые привилегии и управлять доступом через роли.