СУБД#

Начиная с очередного обновления ОС СН Astra Linux Special Edition х.8 в качестве защищенной СУБД в составе ОС используется СУБД Tantor (в исполнении Basic), доработанной в соответствии с требованием интеграции с ОС в части защиты информации, в том числе мандатного управления доступом. В предыдущих очередных обновлениях до х.7 включительно, в качестве основы для защищенной СУБД использовалась СУБД PostgreSQL.

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

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

Дискреционное управление доступом в СУБД#

Дискреционное управление доступом в СУБД аналогично дискреционному управлению доступом в СУБД Tantor.

СУБД является объектно-реляционной.

Сущности (данные) хранятся в отношениях (таблицах), состоящих из строк и столбцов.

При этом единицей хранения и доступа к данным является строка, состоящая из полей, идентифицируемых именами столбцов.

Кроме таблиц также существуют другие объекты БД (виды, процедуры и т. п.), которые предоставляют доступ к данным, хранящимся в таблицах.

C каждым типом объектов БД ассоциируется определенный набор типов доступа (возможных операций).

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

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

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

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

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

Мандатное управление доступом в СУБД#

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

Это позволяет реализовать многоуровневую защиту с обеспечением разграничения доступа пользователей к защищаемым ресурсам БД и управление потоками информации.

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

Примечание

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

Для хранения меток объектов БД введено служебное поле maclabel.

Объекту БД при его создании задается метка безопасности, равная текущей метке безопасности создавшего его пользователя. В дальнейшем по этой метке производится разграничение доступа к созданному объекту.

Согласно МРОСЛ ДП-модели в части реализации мандатного управления доступом дополнительно к метке доступа вводится понятие сущностей-контейнеров (сущностей, которые могут содержать другие сущности).

Можно привести следующие примеры сущностей-контейнеров в СУБД:

  • кластер баз данных является контейнером для входящих в него баз данных;

  • база данных является контейнером для входящих в нее схем;

  • схема является контейнером для входящих в нее таблиц;

  • таблица является контейнером для входящих в нее записей.

Для задания способа доступа к сущностям внутри контейнеров используется мандатный признак CCR (Container Clearance Required).

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

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

Ниже приведен пример создания сущностей-контейнеров и задания им меток и мандатного признака CCR:

-- СОЗДАНИЕ НОВОЙ БАЗЫ ДАННЫХ
-- Подключение к системной БД
\connect postgres
-- Задание правил мандатного доступа доступа к кластеру
MAC CCR ON CLUSTER IS OFF;
MAC LABEL ON CLUSTER IS '{3,0}';
-- Удаление БД демонстрационного примера
DROP DATABASE IF EXISTS contrprimer;
-- Создание пустой БД демонстрационного примера
CREATE DATABASE contrprimer;

-- СОЗДАНИЕ ОБЪЕКТОВ БАЗЫ ДАННЫХ
-- Подключение к БД демонстрационного примера
\connect contrprimer
-- Задание правил мандатного доступа доступа к базе занных
MAC CCR ON DATABASE contrprimer IS OFF;
MAC LABEL ON DATABASE contrprimer IS '{3,0}';
-- Создание схемы
CREATE SCHEMA s1;
-- Задание правил мандатного доступа доступа к схеме
MAC CCR ON SCHEMA s1 IS OFF;
MAC LABEL ON SCHEMA s1 IS '{3,0}';
-- Задание правил ролевого доступа к схеме
GRANT USAGE ON SCHEMA s1 TO PUBLIC;
-- Задание расширения для работы с уникальными идентификаторами
CREATE EXTENSION IF NOT EXISTS "uuid-ossp" WITH SCHEMA s1;

-- Создание таблицы 1
CREATE TABLE s1.t1 (
id uuid DEFAULT s1.uuid_generate_v4() NOT NULL,
insert_user name,
insert_date timestamp,
update_user name,
update_date timestamp,
classificator name
) WITH (
MACS=TRUE -- Создание классификационных меток для записей
);
-- Задание правил мандатного доступа доступа к таблице
MAC CCR ON TABLE s1.t1 IS OFF;
MAC LABEL ON TABLE s1.t1 IS '{3,0}';

-- Дискреционный доступ разрешен всем
GRANT ALL PRIVILEGES ON s1.t1 TO PUBLIC;

Ролевое управление доступом в СУБД#

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

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

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

  • администратора СУБД;

  • администратора БД;

  • пользователя БД.

Роль администратора СУБД позволяет создавать и подключать кластеры баз данных, создавать и управлять учетными записями пользователей СУБД, управлять конфигурацией СУБД, управлять параметрами подключения пользователей СУБД к базам данных. Пользователю СУБД с данной ролью необходимо назначить высокий уровень целостности и включить его в группы astra-admin и astra-audit.

Роль администратора БД позволяет создавать и управлять учетными записями пользователей кластеров баз данных, управлять конфигурацией БД, назначать права доступа пользователям кластера (пользователей информационной системы) к объектам доступа БД (базам данных, схемам, таблицам, записям, столбцам, представлениям и иным объектам доступа), создавать резервные копии БД и восстанавливать БД из резервной копии, создавать, модифицировать и удалять процедуры (программный код), хранимые в БД. Пользователю СУБД с данной ролью необходимо назначить групповую роль pg_database_admin и включить его в группу astra-audit. В СУБД по умолчанию для роли администратора БД используется учетная запись pg_astra_db_admin.

Роль пользователя БД (пользователя информационной системы) позволяет создавать и манипулировать объектами доступа БД (таблица, запись или столбец, поле, представление и иные объекты доступа) и выполнять процедуры (программный код), хранимые в БД. Пользователю СУБД с данной ролью запрещено создание процедур (программного кода), хранимых в базах данных. Пользователю СУБД с данной ролью необходимо назначить групповую роль pg_database_user.

Идентификация и аутентификация пользователей в СУБД#

Идентификация и аутентификация пользователей в СУБД осуществляется с учетом требований ГОСТ Р 5 8833-2020.

В соответствии с вышеописанной ролевой моделью заведение учетных записей администраторов СУБД и администраторов БД (администраторов информационной системы) осуществляется администратором СУБД, а учетных записей пользователей БД — администратором БД.

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

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

Для настройки PAM в СУБД необходимо создать локальные учетные записи пользователей и назначить им минимальные и максимальные уровни конфиденциальности и категории конфиденциальности. В конфигурационном файле контроля доступа сервера СУБД /etc/postgreslq/<версия>/main/pg_hba.conf для параметра host указать требуемый метод аутентификации.

Для обеспечения сквозной аутентификации пользователей ЕПП (в домене безопасности) в СУБД необходимо в качестве метода аутентификации указать gss и провести соответствующую настройку сервера и клиента СУБД.

Схема функционирования защищенной СУБД в трехзвенной клент-серверной архитектуре со сквозной аутентификацией в рамках ЕПП в режиме SSO (Single Sign-On) приведена на рисунке 1.

../../../_images/link3.jpg

Рисунок 1 - функционирование защищенной СУБД в трехзвенном клиент-серверном приложении#

Совет

Подробнее о настройках и функционировании СУБД из состава ОС СН Astra Linux Special Edition можно узнать в Эксплуатационной документации в Руководстве администратора и в Руководстве по КСЗ.