Демонстрационные примеры#
Общие сведения#
Контрольный пример разработан в целях демонстрации общих принципов построения и функционирования прикладного программного обеспечения (ПО) в трехзвенной клиент-серверной архитектуре информационной системы (ИС) в среде Astra Linux Special Edition (далее ОС СН).
В рассматриваемом примере трехзвенная клиент-серверная архитектура содержит программные компоненты, функционирующие под управлением ОС СН:
клиентскую часть на основе веб-браузера Firefox в качестве компонента представления данных;
веб-сервер (сервер приложений) под управлением веб-сервера Apache2 в качестве прикладного компонента, реализующего бизнес-логику автоматизированных систем (АС);
сервер базы данных под управлением СУБД PostgreSQL в качестве компонента управления ресурсами.
Все базовые технологии контрольного примера (веб-браузер Firefox, веб- сервер Apache2, СУБД PostgreSQL 11) являются средствами защищенной обработки информации из состава ОС СН.
Рисунок 1.1 - Схема построения прикладного ПО в трехзвенной клиент-серверной архитектуре ИС с использованием интегрированных механизмов безопасности ОС СН#
Взаимодействие компонентов ИС (рисунок 1.1) происходит с использованием встроенных в ОС СН механизмов разграничения доступа («Рекомендации по построению прикладного программного обеспечения для интеграции с механизмами идентификации, аутентификации, авторизации и разграничения доступа операционной системы специального назначения «Astra Linux Special Edition»). Указанные компоненты функционируют в составе многопользовательской информационной системы на базе локальной или глобальной вычислительной сети с единым пространством пользователей (ЕПП). ЕПП обеспечивает сквозную аутентификацию пользователей по сети и централизованное хранение информации об учетных записях пользователей и группах.
Каждой сессии пользователя после входа в систему присваивается мандатный контекст безопасности, определяемый его меткой безопасности и назначенными привилегиями (подробнее см. «Руководство по КСЗ. Часть 1», п. 4 «Мандатное управление доступом и мандатный контроль целостности»).
Метка безопасности состоит из:
классификационной метки, включающей иерархический уровень конфиденциальности и неиерархические категории конфиденциальности;
метки целостности, включающей иерархический (линейный) уровень целостности (зарезервирован) и неиерархические категории целостности.
Классификационная метка и дополнительные мандатные атрибуты управления доступом используются в механизмах контроля мандатного разграничения доступа (МРД) и представляют мандатный контекст безопасности (подробнее см. «Руководство по КСЗ. Часть 1», п. 4.2 «Мандатное управление доступом»).
Значения метки целостности и дополнительных атрибутов мандатного контроля целостности учитываются при реализации политики мандатного контроля целостности субъекта и сущности (МКЦ) (подробнее см. «Руководство по КСЗ. Часть 1», п. 4.3 «Мандатный контроль целостности»).
Запускаемые пользователем процессы наследуют мандатный контекст безопасности сессии, который передается и при сетевом взаимодействии.
Запрос к серверу приложений (на базе веб-сервера Apache2) и от него к серверу базы данных (БД) (на базе СУБД PostgreSQL) осуществляется из веб- браузера, который наследует контекст безопасности запустившего его пользователя, и между браузером и веб-сервером устанавливается защищённое сетевое соединение.
Для управления авторизацией пользователей и обеспечения работы средств разграничения доступа в веб-сервере Apache2 используется параметр AstraMode. («Руководство администратора. Часть 1. РУСБ.10015-01 95 01-1», п. 10.2 «Режим работы AstraMode»). Этот параметр может быть задан глобально в конфигурационном файле /etc/apache2/apache2.conf. По умолчанию режим включен, что соответствует значению AstraMode on. Следовательно, на серверной машине работает механизм мандатного управления доступа.
При сетевом взаимодействии передача контекста безопасности между клиентской и серверной частью включает:
передачу в запросе браузера билета Kerberos для последующей аутентификации пользователя веб-сервером путем обращения к контроллеру домена безопасности;
передачу метки безопасности в сетевых пакетах протокола IPv4 (IPv6) в соответствии с национальным стандартом ГОСТ Р 58256-2018.
На серверной стороне осуществляется Kerberos аутентификация пользователя и извлечение из соединения его мандатного контекста, получая в результате контекст безопасности сеанса пользователя, приславшего запрос.
Получив контекст безопасности, веб-сервер создаёт в этом контексте дочерний процесс для дальнейшей обработки информации (рисунок 1.2). Данный процесс обладает тем же набором прав, привилегий и мандатных атрибутов, что и учётная запись пользователя, запросившего доступ.
Рисунок 1.2 - Запуск исполнительного процесса в контексте пользователя в Apache2#
Прикладное ПО из состава сервера приложений формирует средствами языка манипулирования данными запрос к СУБД. Обращение прикладного ПО к СУБД инициирует установку защищённого сетевого соединения. На основании полученного из соединения мандатного контекста безопасности, а также полученных у контроллера домена в процессе аутентификации параметрах пользователя, в контексте которого запущен процесс, пытающийся подключиться к базе данных, СУБД осуществляет проверку прав доступа к запрашиваемым ресурсам. Таким образом, обработка базы данных в дальнейшем выполняется в соответствии с контекстом безопасности пользователя, инициировавшего первоначальный запрос.
Подробное описание взаимодействия компонентов трехзвенной клиент- серверной архитектуры ИС в среде ОС СН можно найти в документе «Рекомендации по построению прикладного программного обеспечения для интеграции с механизмами идентификации, аутентификации, авторизации и разграничения доступа ОС СН».
Разграничение прав доступа в СУБД#
Контрольный пример демонстрирует разграничение прав доступа в СУБД PostgreSQL. СУБД использует механизмы безопасности ОС СН для получения контекста безопасности пользователя ОС, запросившего доступ к данным БД. Проверка доступа осуществляется на основе контекста и разрешённых для этого контекста операций.
С каждым типом объектов БД ассоциируется определенный набор типов доступа (возможных операций). Для каждого объекта явно задается список разрешенных для каждого из поименованных субъектов БД (пользователей, групп или ролей) типов доступа (ACL). И в дальнейшем при разборе запроса к БД осуществляется проверка возможности предоставления доступа субъекта к объекту типа, соответствующего запросу.
В дополнение к стандартной системе прав, управляемой командой GRANT, для ограничения набора данных, выдаваемых пользователю, можно применять входящую в PostgreSQL систему фильтрации строк (POLICY) под названием ROW LEVEL SECURITY (RLS). Такая политика защиты строк ограничивает для пользователей наборы строк, которые могут быть возвращены обычными запросами или добавлены, изменены и удалены командами, изменяющими данные. Подробное описание стандартной системы прав СУБД PostgreSQL и системы фильтрации строк можно найти по ссылке https://postgrespro.ru/docs/postgrespro/11/ddl-priv в разделах 5.6 и 5.7 соответственно.
Также в СУБД PostgreSQL реализован механизм мандатного управления доступом. Разграничение доступа к защищаемым ресурсам БД осуществляется на основе иерархических и неиерархических меток доступа. СУБД PostgreSQL извлекает мандатную метку пользователя из контекста входящего соединения и для назначения, хранения и модификации меток использует механизмы ОС СН. Проверка мандатных прав доступа к объектам БД осуществляется одновременно с проверкой дискреционных прав доступа к ним.
Управление защищенными ресурсами БД при включенном механизме мандатного управления доступом основывается на иерархических уровнях и неиерархических категориях доступа.
Для хранения классификационной метки объекта БД введено служебное поле maclabel. При создании любого объекта БД, ему присваивается метка безопасности пользователя, установившего соединение с БД. В дальнейшем, в соответствии с этой меткой производится разграничение доступа к созданному объекту БД.
Согласно ДП-модели в части реализации мандатного управления доступом, дополнительно к классификационной метке вводится понятие сущностей- контейнеров (сущностей, которые могут содержать другие сущности).
В качестве сущностей-контейнеров в СУБД PostgreSQL рассматривают:
кластер (объект, содержащий базы данных);
базу данных (объект, содержащий схемы);
схему (объект, содержащий таблицы);
таблицу (объект, содержащий записи).
Для задания способа доступа к сущностям внутри контейнеров используется мандатный признак CCR (Container Clearance Required). В случае когда он установлен (имеет значение CCR=On), доступ к контейнеру и его содержимому разрешен только для пользователей, иерархический уровень конфиденциальности которых не ниже уровня конфиденциальности контейнера.
Например, если таблица БД с CCR=On имеет уровень конфиденциальности 2, то доступ к ней и к ее записям будет разрешен для пользователей в сеансах с уровнями конфиденциальности 2 (на чтение и изменение данных) и выше (только на чтение).
Если требуется, чтобы в таблице БД допускалось хранение записей с различными уровнями конфиденциальности, то для этой таблицы и для всех контейнеров, содержащих эту таблицу (кластера, базы данных, схемы) признак CCR должен быть отключен (иметь значение CCR=Off).
В этом случае, доступ к таблице из предыдущего примера и к ее записям будет разрешен для пользователей в сеансах с различными уровнями конфиденциальности, в том числе и ниже 2. Правила доступа к данным при этом будут определяться в соответствии с правилами ДП-модели (рис. 2.1).
Рисунок 2.1 — Правила доступа к данным в мандатном контексте#
В демонстрационном примере доступ к базе данных осуществляется в режиме CCR=Off, чтобы пользователи с различными метками безопасности (различными уровнями конфиденциальности) могли читать и изменять данные в таблицах. Следует отметить, что при создании БД для всех сущностей-контейнеров должны быть указаны (рис. 2.2):
диапазон допустимых иерархических уровней конфиденциальности;
перечень допустимых неиерархических категорий конфиденциальности;
значение признака CCR (On или Off).
Рисунок 2.2 - Пример реализации мандатного разграничения доступа к базе данных#
Состав демонстрационного примера#
Контрольный пример включает в свой состав следующие файлы для создания веб-сервера (расположены в каталоге /var/www/html/demoprimer/):
папка demoprimer_flask — содержит WSGI-приложение написанное с помощью фреймворка Flask;
папка demoprimer_django — содержит WSGI-приложение написанное с помощью фреймворка Django;
папка templates — содержит шаблоны разных форматов, не используется в данном проекте;
demoprimer.html — веб-страница на языках html и javascript для предоставления графического интерфейса пользователя и взаимодействия с веб-сервером;
demoprimer.php — CGI-скрипт на языке PHP 7.3 для обработки запросов к веб-серверу и взаимодействия с СУБД;
demoprimer.py — CGI-скрипт на языке python3 для обработки запросов к веб-серверу и взаимодействия с СУБД;
environ.json — файл настроек переменных окружения для корректной работы приложений, написанных на языке Python.
Состав файлов контрольного примера может дополняться для демонстрации работы на других языках программирования.
База данных контрольного примера создается из следующих файлов (расположены в каталоге /usr/share/demoprimer/):
demoprimer.sql, demoprimer_0.sql, demoprimer_1.sql, demoprimer_2.sql, demoprimer_3.sql - скрипты на языке PL/pgSQL. Скрипты предлагают различные варианты демонстрации разграничения доступа к данным БД. Генерация базы данных каким-либо из этих скриптов позволяет экспериментировать с различными комбинациями механизмов разграничения доступа.
Далее приведены описания предлагаемых вариантов разграничения доступа.
demoprimer_0.sql
Данный вариант демонстрирует только мандатное разграничение доступа к базе данных. Дискреционное разграничение доступа и политика защиты на уровне строк (записей) не применяется.
demoprimer_1.sql
В данном варианте помимо мандатного разграничения доступа используется политика защиты на уровне строк (RLS).
Этот вариант демонстрирует такую политику, при которой изменение прав доступа к записям осуществляется в зависимости от времени создания записи и текущего времени выполнения запросов.
При создании записи в поле insert_date записывается время создания записи.
При выполнении запроса на чтение, изменение или удаление записи происходит сравнение значения секунд времени создания записи со значением секунд в текущем времени выполнения запроса. Доступ к записи предоставляется только к записям, созданным в первой или второй половине минуты соответственно текущему времени запроса.
demoprimer_2.sql
В этот вариант помимо мандатного разграничения доступа и политики защиты на уровне записей (RLS) включено разграничение доступа к полям определенных столбцов таблицы с использованием стандартной системы прав, управляемой командой GRANT.
Пользователи, имеющие права роли «Администратор_БД», имеют доступ на чтение ко всем записям, а также могут создавать, удалять и классифицировать записи.
Пользователи, имеющие права роли «Пользователь», могут изменять поля столбцов update_user, update_date и имеют доступ на чтение только к записям в соответствии со следующей иерархической классификацией подразделений:
Организация
Департамент_1
Отдел_11
Отдел_12
Департамент_2
Отдел_21
Отдел_22
По умолчанию участником роли доступа «Администратор_БД» является роль входа user3, участниками роли доступа «Пользователь» являются user0, user1, user2. При этом user0 является участником роли «Отдел_12», user1 является участником роли «Департамент_1», user2 является участником роли «Организация».
Включая или исключая с помощью средств администрирования БД пользователей из ролей «Пользователь» или «Администратор_БД», а также включая или исключая их из ролей в иерархической классификации подразделений, можно управлять их доступом к данным.
demoprimer_3.sql
В данном варианте кроме мандатного разграничения доступа, применяется следующая комбинация политики защиты на уровне записей (RLS) и дискреционного разграничения доступа (стандартной системы прав, управляемой командой GRANT).
При создании каждой записи с помощью триггера выполняется:
создается роль с именем, равным уникальному идентификатору (uid) записи;
пользователю, создавшему запись, даются права этой созданной роли.
В результате каждый пользователь имеет доступ только к созданным им записям.
Пользователи, включенные в роль «Администратор_БД» (по умолчанию user3) имеют доступ ко всем записям.
Включая с помощью средств администрирования пользователей в те или иные роли можно изменять их права доступа к записям БД.
demoprimer.sql
Данный вариант содержит 3 варианта таблиц, настроенных в соответствии с примерами demoprimer_0.sql, demoprimer_1.sql и demoprimer_2.sql для таблиц t1, t2 и t3 соответственно. Скрипт выполняется при развертывании серверного приложения и предоставляет удобный интерфейс для демонстрации работы с данными при разных настройках правил доступа (переключаясь между таблицами от разных пользователей).
Стенд на базе виртуальных машин#
Виртуальные машины контроллера домена и сервера представлены в формате ova и могут быть запущены через приложение VirtualBox.
Архив с файлами виртуальных машин контрольного примера (Astra_Domain.ova и Astra_Server.ova) доступен для скачивания по ссылке:
https://disk.astralinux.ru/s/NmkptbgbxAFSMyW.
Стенд представляет собой локальную трехзвенную информационную систему (ИС) В качестве ЕПП используется служба FreeIPA, для совместной работы с ЕПП веб-сервера Apache2 и СУБД PostgreSQL, в ОС СН виртуальной машины уже произведены необходимые настройки.
Параметры конфигурации ЕПП#
Перед использованием контрольного примера необходимо выполнить проверку конфигураций сервисов, обеспечивающих работу ЕПП. Для этого предлагается осуществить вход на рабочий стол ОС СН локальным администратором. Аутентификационные данные локального администратора, а также сведения о заведенных в системе доменных пользователях представлены в таблице «Сведения о заведенных в системе пользователях».
№ |
Имя пользователя |
Пароль |
Описание |
Уровень и категория |
|---|---|---|---|---|
1 |
astra |
0123456789 |
Локальный администратор |
{0,0} |
2 |
admin |
0123456789 |
Доменный администратор |
{0,0} |
3 |
user0 |
12345678 |
Доменный пользователь |
{0,0} |
4 |
user1 |
12345678 |
Доменный пользователь |
{1,0} |
5 |
user2 |
12345678 |
Доменный пользователь |
{2,0} |
6 |
user3 |
12345678 |
Доменный пользователь |
{3,0} |
Сведения о конфигурации сети представлены в таблице.
№ |
Описание |
Параметр |
|---|---|---|
1 |
Имя домена |
.astra.domain |
2 |
Полное имя серверного компьютера FreeIPA (FQDN) |
freeipa.astra.domain |
3 |
IP4.ADDRESS |
192.168.60.100 |
4 |
Полное имя серверного компьютера Apache2/PostgreSQL (FQDN) |
client.astra.domain |
5 |
IP4.ADDRESS |
192.168.60.103 |
Конфигурации контрольного примера#
Файлы веб-сервера контрольного примера (demoprimer.php, demoprimer.html, demoprimer.py, каталог demoprimer_django, каталог demoprimer_flask) располагаются в каталоге /var/www/html/demoprimer. Выбор скрипта запуска сервера осуществляется на стартовой странице работы примера (рисунок 4.2) по адресу client.astra.domain (по умолчанию запускается скрипт demoprimer.py).
Рисунок 4.2 — Выбор скрипта запуска серверного приложения#
Файлы-скрипты для создания базы данных контрольного примера (demoprimer.sql, demoprimer_0.sql, demoprimer_1.sql, demoprimer_2.sql, demoprimer_3.sql) располагаются в каталоге /user/share/demoprimer.
В файлах веб-сервера строка подключения к базе данных берется из переменной окружения DEMOPRIMER_DB_CONNECT и содержит имя хоста, на котором располагается база данных:
DEMOPRIMER_DB_CONNECT= 'dbname=demoprimer host=client.astra.domain port=5440'.
Данная переменная задается в файле envvars настроек Apache2, расположенному в каталоге /etc/apache2.
В СУБД PostgreSQL созданы одноименные доменным пользователи, а также база данных demoprimer.
Демонстрация работы разных правил разграничения доступа для разных таблиц представлена в скрипте demoprimer.sql (задан на исполнение по умолчанию) или осуществляется при использовании одного из четырех вариантов, представленных в файлах скриптов demoprimer_0.sql, demoprimer_1.sql, demoprimer_2.sql, demoprimer_3.sql.
Для использования sql-скрипта следует от пользователя admin перейти в каталог /usr/share/demoprimer:
cd /usr/share/demoprimer
и выполнить команду:
sudo -su postgres psql -d demoprimer -p 5440 -f demoprimer_0.sql
с указанием имени соответствующего скрипта в качестве последнего параметра, выбранного в соответствии с одним из четырех вариантов демонстрации разграничения доступа. Описание вариантов генерации базы данных с использованием различных скриптов представлено в п. 3.
Следует отметить, что выполнение какого-либо скрипта генерации БД приведет к удалению предыдущей базы данных.
Запуск контрольного примера осуществляется по инструкции, приведенной в п. 5. Для его корректной работы после изменения базы данных скриптами demoprimer_0.sql, demoprimer_1.sql, demoprimer_2.sql, demoprimer_3.sql необходимо выполнение скрипта demoprimer.sql.
Запуск контрольного примера#
Запуск контрольного примера осуществляется путем открытия веб-страницы контрольного примера, которая предоставляет графический интерфейс пользователя и обеспечивает взаимодействие с веб-сервером. Для этого необходимо зайти в систему одним из доменных пользователей через графическую оболочку и запустить браузер Mozilla Firefox. При старте в адресной строке браузера будет указан адрес сервера http://client.astra.domain (рисунок 5.1).
Рисунок 5.1 - Окно вывода контрольного примера#
При успешной авторизации доступа пользователя к ресурсам управляемых узлов в таблице «Пользователь» будут отображены параметры реального контекста работы пользователя, полученные из служб контрольного примера (Apache, PostgreSQL): имя пользователя, осуществившего вход в домен (например, user1@ASTRA.DOMAIN, user1), его мандатный уровень и мандатная категория. Ниже будет отображено содержимое базы данных контрольного примера. Для выполнения тестовых операций над данными предлагается использовать кнопки запросов.
При входе в систему другими пользователями домена результат вывода контекста пользователя и содержимого базы данных будет различным и соответствовать параметрам вошедшего с систему пользователя и его правам на доступ к данным, хранящимся в БД.
Дополнение#
Все упомянутые в тексте дополнительные материалы доступны по ссылкам: