Безопасность PostgreSQL для ГИС, ИСПДн и КИИ по своей сути состоит в связывании четырёх уровней – организационных процессов, укрепления операционной системы, настройки СУБД и аудиторских доказательств, а не в опоре исключительно на параметры аутентификации самой базы данных. В российской регуляторной практике методология оценки угроз ФСТЭК требует, чтобы каждая мера защиты соответствовала проверяемому сценарию и цепочке доказательств; один лишь перечень настроек не проходит проверку. Ниже материал организован по типовым задачам безопасности с разграничением функций СУБД, обязанностей операционной системы и организационных контролей, а также с указанием видов доказательств, которые обычно требует внутренний аудит.
Аутентификация и управление ролями: реализация минимальных привилегий в PostgreSQL
Аутентификация и управление ролями в PostgreSQL должны контролироваться на двух уровнях – «кто может подключиться» и «что можно делать после подключения»; типичными уязвимыми местами являются права по умолчанию на схему public и широкие разрешения CONNECT. Проектирование ролей должно следовать принципу разделения обязанностей и не допускать, чтобы учётная запись приложения обладала правами, превышающими необходимые для её бизнес-функции.
На уровне аутентификации pg_hba.conf задаёт метод аутентификации по адресу источника, базе данных и пользователю; в промышленной среде метод trust должен быть запрещён, предпочтительны scram-sha-256 или интеграция с внешней аутентификацией. В управлении ролями следует установить соглашение об именовании, чётко разграничивающее администратора, оператора, разработчика, аудитора, службу поддержки и учётные записи приложений, причём каждой группе ролей предоставляются только те права на объекты, которые необходимы для её функции. Учётная запись приложения не должна обладать правами OWNER на таблицы и тем более правом CREATE, чтобы атака через инъекцию не могла расширить права за счёт учётной записи приложения. Роль аудитора должна иметь возможность читать журналы аудита и ключевые конфигурации, но не должна обладать правом изменять данные или права. Для сценариев разработки и анализа, где требуется доступ к чувствительным данным без раскрытия открытого текста, видимость следует ограничивать с помощью представлений, политик безопасности на уровне строк или функций маскирования, а не прямым предоставлением прав на базовые таблицы.
Настройка аудита: границы применимости pgaudit и типичные ошибки конфигурации
Штатного журналирования PostgreSQL недостаточно для комплаенс-аудита; расширение pgaudit обеспечивает аудит с разбивкой по типам событий, но требует корректной настройки, чтобы не записывать пароли и не пропускать ключевые операции. Ядро настройки аудита – выбор категорий инструкций для записи и гарантия того, что вывод аудита нельзя обойти.
pgaudit поддерживает настройку типов аудируемых событий на уровне сессии, пользователя или базы данных, включая READ, WRITE, DDL, ROLE, FUNCTION. Для систем ГИС и ИСПДн следует как минимум записывать изменения DDL, изменения ролей и прав, а также чтение и запись по чувствительным таблицам. Одна из ключевых ошибок – использование штатного параметра PostgreSQL log_statement = ‘ddl’: при выполнении CREATE ROLE… WITH PASSWORD или ALTER ROLE… пароль попадает в серверный журнал в открытом виде, что создаёт прямую угрозу безопасности. Тип события ROLE в pgaudit записывает изменения ролей, но не записывает пароль в журнал, а тип DDL вообще не записывает инструкции ролей, поэтому корректная настройка должна покрывать аудит управления ролями средствами pgaudit, а не штатного журнала.
Расположение вывода аудита и стратегия хранения не менее важны. Журналы следует направлять в централизованное хранилище, отдельное от сервера базы данных, чтобы атакующий, получивший доступ к базе, не мог очистить локальные журналы. Права роли аудитора должны быть независимы от DBA, чтобы записи аудита нельзя было изменить со стороны лиц, обладающих правом модификации данных. Внутренний аудит обычно требует следующих доказательств: снимки параметров настройки аудита, выборки журналов аудита (охватывающие DDL, изменения прав, доступ к чувствительным данным), а также письменное положение о передаче и хранении журналов.
Защита данных: шифрование, маскирование и безопасность резервных копий
Защита данных на уровне PostgreSQL требует различать три разных механизма – шифрование передачи, шифрование хранения и маскирование статических данных; сама СУБД обычно предоставляет только шифрование передачи и функции шифрования на уровне столбцов, а прозрачное шифрование на уровне файлов зависит от операционной системы или специализированных расширений. Российские сборки PostgreSQL предлагают на этом уровне возможности сверх версии сообщества.
Шифрование передачи включается параметром ssl = on и требует от клиента использования sslmode=verify-full для проверки серверного сертификата, что предотвращает атаки типа «человек посередине». Прозрачное шифрование на уровне хранения в сообществе PostgreSQL нативно не поддерживается и требует шифрования на уровне операционной системы (например, LUKS) или расширений, предоставляемых сборкой. Например, «РЕД База Данных» реализует постраничное прозрачное шифрование, шифруя только страницы пользовательских данных, индексные страницы и страницы больших объектов; шифрование выполняется в фоновом асинхронном режиме, не прерывая работу базы данных, управление ключами возлагается на администратора, поддерживаются ротация ключей и повторное шифрование. Для обеспечения тестовых сред и сред разработки данными следует использовать статическое маскирование или представления динамического обезличивания, а не передавать разработчикам необезличенные копии промышленных данных.
Безопасность резервных копий часто недооценивается. Вывод pg_dump и файлы базовых резервных копий должны храниться в зашифрованном виде, а права доступа к носителям резервных копий должны быть независимы от сервера базы данных. Записи о тестировании восстановления – ключевое доказательство для аудита: недостаточно журнала успешного создания резервной копии, требуется подтверждение того, что процесс восстановления фактически выполнялся в изолированной среде с фиксацией времени восстановления, согласованности данных и результатов проверки приложения.
Управление уязвимостями и процесс установки обновлений: от перечня версий до подтверждения изменений
Управление уязвимостями PostgreSQL должно охватывать три уровня – двоичные файлы СУБД, расширения и зависимые библиотеки; отслеживание только мажорной версии PostgreSQL недостаточно для выявления проблем, вносимых такими расширениями, как pgaudit или pgvector. Процесс должен включать инвентаризацию активов, оценку CVE, проверку в тестовой среде, выполнение в окне изменений и подтверждение после установки.
Инвентаризация активов должна фиксировать версию PostgreSQL каждого экземпляра, установленные расширения и их версии, операционную систему и зависимые библиотеки. Оценка CVE требует оценки фактического риска с учётом зоны атаки базы данных: уязвимость, затрагивающая только COPY… FROM PROGRAM, в среде, где учётная запись приложения не обладает правами суперпользователя и эта функция не включена, имеет более низкую фактическую эксплуатируемость, чем подразумевает общая оценка. Обновления следует проверять в тестовой среде, соответствующей промышленной конфигурации, с особым вниманием к совместимости расширений, поскольку некоторые расширения при мажорном обновлении PostgreSQL могут требовать перекомпиляции или обновления версии; pgaudit в среде Azure при мажорном обновлении автоматически удаляется и пересоздаётся, причём пользовательские настройки не сохраняются автоматически.
После выполнения в окне изменений необходимо подтвердить результат установки. Подтверждение включает: возврат ожидаемой версии в SELECT version(), корректный вывод \dx по ключевым расширениям, прохождение теста подключения приложения, непрерывность записей аудита до и после обновления. Для систем КИИ недавние регуляторные требования дополнительно ужесточили сроки: критические уязвимости должны закрываться в течение 24 часов, уязвимости высокой критичности – в течение 7 календарных дней, а обновления перед вводом в промышленную эксплуатацию должны проверяться в изолированном тестовом сегменте. Доказательства внутреннего аудита включают: перечень версий, записи оценки CVE, отчёт о проверке в тестовой среде, заявку на изменение, снимки подтверждения после установки.
Пример модели ролей и сопоставление с аудиторскими доказательствами
Аудируемая модель ролей должна явно связывать границы прав каждой роли с соответствующим видом доказательств, чтобы внутренний аудит мог проследить путь от «кто чем обладает» к «кто утвердил изменение» и «кто выполнил операцию». Приведённое ниже разделение ролей охватывает типовые сценарии эксплуатации; конкретный объём прав корректируется в зависимости от категории системы.
Администратор обладает правами на настройку уровня экземпляра и управление ролями, но не должен иметь прямых прав DML на бизнес-таблицы; все его операции должны аудироваться, а создание ролей и предоставление прав требуют утверждения в рамках управления изменениями. Оператор отвечает за повседневное резервное копирование, мониторинг и управление сессиями; его права ограничены ролями pg_monitor, pg_backup и ограниченной возможностью pg_terminate_backend, права DDL отсутствуют. Разработчик обладает правами DDL в пределах своей схемы в среде разработки, в промышленной среде вносит изменения только через контролируемый процесс развёртывания и не подключается к промышленной базе напрямую. Аудитор обладает правами только на чтение журналов аудита и конфигурационных файлов и подчиняется независимо от линии отчётности DBA. Учётная запись службы поддержки при обработке инцидентов временно получает ограниченные права, предоставляемые через роли с ограниченным сроком действия и автоматически отзываемые по истечении срока. Каждая учётная запись приложения независима, обладает правами SELECT, INSERT, UPDATE, DELETE только на определённые таблицы в своей схеме и не имеет прав CREATE или OWNER.
Соответствующие доказательства включают: заявки на утверждение создания и авторизации ролей, периодические снимки pg_roles и pg_auth_members, версионируемые записи pg_hba.conf, выборки событий изменения ролей в журналах аудита, а также записи о пересмотре прав. Проверка внутренним аудитом «общих учётных записей» и «избыточных прав учётных записей приложений» опирается на перекрёстное сопоставление указанных снимков и заявок, а не только на просмотр текущей конфигурации.
Типичные ошибки и направления исправления
Наиболее частые находки аудита сосредоточены в пяти областях – общие учётные записи, избыточное расширение прав приложений, отсутствие аудита привилегированных действий, незащищённость резервных копий и отставание с обновлениями; для каждой существует практически применимая корректирующая мера. Общие учётные записи следует заменить персональными именованными учётными записями или как минимум предоставить каждому оператору отдельные учётные данные, чтобы журналы аудита можно было отнести к конкретному лицу. Избыточное расширение прав приложений обычно возникает из-за временных разрешений «чтобы приложение заработало», которые не были отозваны; периодический пересмотр прав позволяет сузить учётные записи приложений до необходимых таблиц и операций. Отсутствие аудита привилегированных действий чаще всего объясняется тем, что pgaudit не включён или записывает только DDL; следует дополнить типы событий ROLE и WRITE и подтвердить направление журналов аудита в централизованное хранилище. Исправление незащищённости резервных копий включает шифрование файлов резервных копий, ограничение политики доступа к бакетам или каталогам хранения и применение к носителям резервных копий тех же мер контроля доступа, что и к серверу базы данных. Исправление отставания с обновлениями состоит не в простом «своевременном применении обновлений», а в создании отслеживаемого перечня версий и процесса оценки CVE, чтобы каждое решение об обновлении имело документированное обоснование.
Методология оценки угроз ФСТЭК подчёркивает, что признание угрозы определяется наличием реально осуществимого сценария атаки, а не теоретической вероятностью. Аналогично эффективность меры безопасности зависит от того, правильно ли она реализована и порождает ли проверяемые доказательства. Для развёртываний PostgreSQL на объектах ГИС, ИСПДн или КИИ подготовка к внутреннему аудиту должна смещаться от вопроса «что мы настроили» к вопросу «как мы доказываем, что настройка остаётся действенной»; такой сдвиг требует привязки каждой технической меры к организационному процессу, хранению доказательств и периодическому пересмотру.
