Информационная безопасность — это комплекс мер, направленных на защиту данных от несанкционированного доступа, утечек, повреждений и других угроз. Ее основная задача — обеспечить конфиденциальность (доступ к информации только для авторизованных лиц), целостность (защиту от несанкционированных изменений) и доступность (бесперебойную работу систем и данных). Для обеспечения защиты информации применяется комплекс мер, включающих в себя технические, организационные и правовые методы. Часть мер по организации контроля доступа к информации осуществляется "1С:Предприятием", однако клиент-серверная архитектура подразумевает хранение данных в СУБД, что создаёт дополнительные риски для информационной безопасности. Таким образом, помимо защиты в 1С, необходимо обеспечивать безопасность на уровне сервера базы данных.

Защита данных на уровне СУБД

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

Некоторые ключевые компоненты, которые должна включать такая система:

• Контроль физического доступа к серверу баз данных: размещение сервера в защищенном ЦОДе; использование аппаратных средств защиты; другие меры защиты.
• Контроль доступа на уровне операционной системы сервера баз данных.
• Контроль доступа на этапе подключения к СУБД: из каких сетей разрешено подключение (диапазон IP, порты, таймауты, SSL); таймауты сессий; различные методы аутентификации; другие меры защиты.
• Реализация принципа наименьших достаточных привилегий, т.е. пользователи должны обладать только теми привилегиями и иметь доступ только к тем данным, которые необходимы для выполнения его рабочих задач.
• Настроенная система аудита – отслеживание подключений, изменений данных, назначения прав и т.д.
• Маскирование данных -всегда ли пользователю необходимо отдавать данные в неизменном виде или их необходимо маскировать.
• Шифрование на уровне операционной системы и/или на уровне СУБД.
• Другие дополнительные меры защиты.

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

Далее в нашей статье мы рассмотрим реализацию принципа наименьших достаточных привилегий и аудита на основе специализированных решений компании PostgresPro.

Принцип наименьших достаточных привилегий

Для реализации этого подхода в ванильной версии PostgreSQL применяется ролевая модель управления привилегиями, а также механизм защиты на уровне строк (Row-Level Security, RLS). При этом разделение привилегий на уровне бизнес-пользователей в СУБД не требуется, так как решения на базе 1С подключаются к базе данных под единой учётной записью. Все вопросы авторизации и разграничения прав пользователей берёт на себя сама 1С, а не СУБД.

Почему же недостаточно организаций привилегии среди бизнес-пользователей?

Разграничение доступа для администраторов PostgreSQL

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

Проблема неограниченных привилегий суперпользователя в PostgreSQL.

В PostgreSQL суперпользователь — это роль с неограниченными правами, позволяющими выполнять любые операции в системе. По уровню доступа она аналогична:

• пользователю root в Linux,
• учетной записи sa в MS SQL Server.

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

На следующем рисунке представлена возможная схема распределения ролей на кластере Postgres: 

1. Отзыв привилегий SUPERUSER у учетной записи 1С

Основные причины:

• Привилегия SUPERUSER требуется только на этапе создания информационной базы
• Постоянное наличие SUPERUSER создает неоправданные риски безопасности
• Нарушается принцип минимальных необходимых привилегий

Например, для пользователя onesuser команда будет выглядеть следующим образом: ALTER USER onesuser WITH NOSUPERUSER;

2. Разделения обязанностей суперпользователя между дополнительными административными ролям:

- Администратор кластера PostgreSQL

функции:

• управление сервером и репликацией
• физическое резервное копирование
• регламентное обслуживание 

ограничения:

• нет доступа к бизнес-данным 1С

функции:

• логическое резервное копирование (pg_dump)
• восстановление данных из логических копий
• ограниченное администрирование

ограничения:

• минимально необходимые права (на выгрузку таблиц необходимо только право на чтение)
• обязательный аудит всех действий

3. Создание зоны повышенной безопасности

Для обеспечения безопасности конфиденциальных данных важно контролировать доступ к этим данным. 

По умолчанию права на доступ к объектам базы данных могут выдавать:

• владелец объекта
• суперпользователь
• роли с правом передачи привилегий (WITH GRANT OPTION

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

Это создаёт необоснованные риски предоставления прав доступа к объектам базы данных ролям, которые не должны обладать такими полномочиями.

Для устранения этих рисков создается защищенная схема.

Шаги по созданию защищенной схемы:

CREATE USER ones_security_officer WITH LOGIN;
GRANT CONNECT ON DATABASE database_name TO ones_security_officer;

2. Создание защищённой схемы

По умолчанию база данных 1С создаётся в схеме public, поэтому именно её необходимо защитить.

ALTER SCHEMA public SECURITY OFFICER TO ones_security_officer;

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

3. Блокировка доступа для суперпользователя

После настройки ролей и создания защищенной схемы необходимо ограничить использование стандартной учетной записи postgres:

• После создания необходимых административных ролей, необходимо запретить соединение для суперпользователя, внесением изменений в pg_hba.conf

        TYPE    DATABASE      USER                    ADDRESS         METHOD
        local      all                    postgres                                            reject                    
        host       all                    postgres             127.0.0.1/32           reject            
        host       all                    postgres                 ::1/128                reject         

• Администратор инфраструктуры root запрещает пользователю postgres изменять файл pg_hba.conf

              # chown root pg_hba.conf
               # chmod 640 pg_hba.conf

• Чтобы новые ограничения вступили в силу, требуется перезапуск сервера СУБД

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

На следующем рисунке представлена возможная схема распределения ролей на кластере Postgres Pro при отказе от использования роли postgres, а также с внедрением защищенной схемы:

Аудит

Современные системы защиты информации невозможно представить без полноценного механизма аудита. 

Ключевые возможности системы аудита:

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

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

https://postgrespro.ru/docs/enterprise/17/sod-separation-of-duties
https://postgrespro.ru/docs/enterprise/17/restrict-dbms-admin-data-access

Далее мы рассмотрим возможности аудирования на примере расширения pgpro_audit. 

Ключевые особенности расширения pgpro_audit:

1. Высокая производительность - параллельная обработка событий минимизирует нагрузку на СУБД

2. Классификация событий:

• события группируются по классам (DML, DDL, аутентификация и др.)
• можно включать аудит для всего класса или только конкретных операций

3. Гибкая система фильтрации событий

Аудит можно настроить с высокой точностью, комбинируя параметры:

• имя базы данных
• тип события (можно указать как конкретные команды, так и классы событий)
• тип объекта
• имя объекта
• имя роли (можно указать как конкретного пользователя, так и групповую роль)

4. Удобное хранение и анализ логов

• журналы сохраняются в файлы ОС, с возможностью настройки ротации этих файлов
• интеграция через file_fdw – позволяет читать логи напрямую через SQL-запросы

5. Широкий набор информации о произошедших событиях:

• дата и время события
• имя пользователя (current_user)
• имя базы данных
• идентификатор серверного процесса (PID)
• имя оператора
• тип объекта
• текст SQL-команды
• идентификатор транзакции (XID)
• и другие

Расширение pgpro_audit предоставляет удобный SQL-интерфейс для гибкой настройки правил аудита: 

• функции управления аудитом
• представление pg_proaudit_settings для просмотра текущих настроек

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

GRANT EXECUTE ON FUNCTION pg_proaudit_set_rule(...) TO ones_security_officer;

Ниже представлен пример конфигурации набора правил для аудита кластера PostgreSQL, работающего с базой данных 1С в защищенной зоне.

Примечание: Пользователь 1С не входит в групповую роль ONES_AUDIT, т.к. он совершает тысячи и десятки тысяч операций, логирование которых привело бы к быстрому разрастанию журнала аудита, а также снижению производительности кластера Postgres. Групповая роль ONES_AUDIT создана для централизованного управления аудитом в кластере. В неё включены все пользовательские роли за исключением роли 1С, что позволяет применять единые правила аудита без необходимости настройки для каждого пользователя отдельно.

Данная конфигурация позволяет ответить на следующие вопросы:

Кто подключается к системе?

Меняется ли системная конфигурация?

Происходят ли изменения в структуре данных?

Как изменяются чувствительные данные?

• Пытается ли кто-то посторонний вносить правки в защищенных таблицах?

Здесь важно отметить, что аудит можно настроить не только на всю базу данных или схему, но и на отдельные таблицы.

Меняется ли ролевая модель?

Что делают привилегированные пользователи?

• Какие команды выполняют эти пользователи?
• Нет ли злоупотреблений привилегиями, которыми они обладают (например, отключение аудита)?

Более подробная информация:

https://postgrespro.ru/docs/postgrespro/16/pg-proaudit#PG-PROAUDIT-FUNCTIONS-TO-CONFIGURE-SECURITY-EVENT-LOGGING

Заключение

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

Эксперты компании «1С-Премиум» готовы оказать профессиональную поддержку по широкому кругу направлений: от проектирования архитектуры и оптимизации производительности до реализации сложных интеграций и решения других технических задач. Мы всегда на связи, чтобы помочь вам в достижении поставленных целей.