Банк данных ПРОДУКЦИЯ РОССИИ

Система разграничения доступа

Озниев Н.К. ктн

Дата публикации: 07.01.2018 г.

Введение

Система разграничения доступа была введена в Банк данных ПРОДУКЦИЯ РОССИИ (БДПР) главным образом для обеспечения целостности данных региональных баз данных Центров стандартизации и метрологии (ЦСМ) при их одновременной работе на портале. Требовалось сделать так, чтобы каждый владелец базы данных был надежно огражден от возможного случайного или намеренного воздействия со стороны владельцев других баз данных.

Так как на портале БДПР данные хранятся в едином хранилище, то необходимость в подобной защите очевидна.

Все остальные попутные бонусы системы разграничения доступа, вообще говоря, носят второстепенный характер. Но это так только до начала внедрения системы разграничения доступа (СРД). Как только СРД начинает функционировать – она становится востребованной для множества других задач, появляются законным образом ряд режимов работы портала, для которых нужны те или иные защитные механизмы. СРД в этом случае – незаменимый инструмент.

В силу сказанного, СРД – одна из ключевых в архитектуре БДПР. В ней принципиально нового с точки зрения самой структуры и программной реализации нет, - новым ее качеством является лишь то, как она адаптирована для данного портала. Она построена на базе формирования набора разрешений для объектов и операций базы данных и/или элементов web-страниц, включая и сами web-страницы, и последующей организации пользовательских ролей.

Разрешения инициализируются (проверяются) в момент инициализации объектов базы данных и/или web-страниц и их элементов, тем самым составляя уровень реализации программного кода.

Например, если обратиться к модулю управления веб-страницей ввода каталожного листа (КЛП), к которому должны иметь доступ только сотрудники ЦСМ, то механизм управления доступом выглядит следующим образом. Он запускается при обращении к веб-странице, когда делается попытка открыть ее по ссылке или через какой-нибудь другой элемент управления портала, скажем кнопкой.

При этом, до начала открытия веб-страницы, контроллер (это и есть фактически модуль управления веб-страницей) производит следующие операции:

1.    Проверяет пользователя, определяя, зарегистрирован ли он. Если это гость, то сразу же следует отказ в открытии веб-страницы.

2.    Если пользователь зарегистрирован, значит он уже залогинился. Проверяются полномочия в списке его ролей. Если среди разрешений имеется разрешение на ввод КЛП в базу данных – страница может открываться. В противном случае следует отказ.

3.    Далее идет стадия формирования органов управления. Их может быть несколько, каждый из которых предназначен для той или иной операции, и эти операции могут быть с ограничениями. Например, для сотрудников Центра сбора и обработки информации могут потребоваться дополнительные возможности, которых нет у рядовых ЦСМ. Все они включаются (становятся доступными) в соответствии с разрешениями, которые должны присутствовать в списке ролей пользователя.

4.    Когда все проверки прошли, вызываемая веб-страница открывается в полном соответствии с ролями пользователя.

Ясно, что проверка по пункту 1 – это перестраховка на случай отказа других уровней защиты, которые тут напрашиваются. В частности, для гостей на портале вообще могут отсутствовать органы управления для открытия таких важных страниц, как веб-страница ввода критической информации. Они по логике работы СРД должны быть недоступны для гостей.

Но в типовом сценарии открытия любой веб-страницы пункт первый должен присутствовать, т.к. это - своего рода шаблон для любой страницы портала, который всегда присутствует, если только данная страница не является публичной.

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

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

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

Реализация СРД

В СРД участвует специальный набор таблиц базы данных портала. Их состав и взаимосвязи между ними показаны на следующей схеме.

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

 

№№

Наименование таблицы

Назначение таблицы

1.     

permissions

Перечень разрешений системы

2.     

roles

Перечень ролей

3.     

role_perm

Матрица назначений разрешений ролям

4.     

users

Перечень пользователей

5.     

user_role

Матрица назначений ролей пользователям

Как все это работает

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

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

Очевидно, вход на портал требует создания базы пользователей, и, как следствие, наличия функций регистрации пользователей (наполнение таблицы users).

Администратор портала согласно политике безопасности и условиям пользования ресурсами портала, создает необходимые роли. В частности, в БДПР самой широко распространенной ролью является роль «Сотрудник ЦСМ». Для каждой роли в системе появляется соответствующая запись в таблице roles.

Затем идет процесс выбора списка разрешений для конкретных ролей из заранее созданной базы этих разрешений (таблицы permissions). Так, роль «Сотрудник ЦСМ» на данный момент включается в себя следующие разрешения:

·                Запись КЛП в БД,

·                Редактирование КЛП,

·                Запрос полной информации КЛП,

·                Просмотр списка КЛП,

·                Печать КЛП,

·                Ввод в БД нового КЛП,

·                Обработка заявок,

·                Изменение КЛП,

·                Просмотр справочника предприятий,

·                Просмотр КЛП,

·                Просмотр аннулированных КЛП,

·                Активация аннулированных КЛП,

·                Аннулирование КЛП,

·                Скачивание региональной БД,

·                Просмотр данных предприятия,

·                Выбор предприятия из списка для КЛП.

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

Не все из перечисленных разрешений равнозначны по сложности реализации. Так, разрешение «Ввод в БД нового КЛП» обеспечивает доступ к довольно сложной по структуре и функциональности веб-странице ввода КЛП, имеющей множество сервисов по контролю за вводом, а также доступ к классификаторам и операциям ввода адресных данных на базе классификатора адресов (КЛАДР). А вот разрешение «Печать КЛП», при его наличии, просто реализует доступ к одноименной кнопке, по которой пользователь может перейти на форму печати КЛП. Если этого разрешения нет – кнопка не показывается.

Для каждого из перечисленного набора разрешений для роли «Сотрудник ЦСМ» в матрице role_perm создается запись из пары ключей (идентификатор роли – идентификатор разрешения). Одновременно в таблице user_role создается запись из пары ключей (идентификатор пользователя – идентификатор роли).

Если окажется, что заданный объект (веб-страница, форма или что-либо еще) находятся в пределах какой-то веб-страницы, а сама веб-страница открывается из конкретного меню портала, то потребуется иметь доступ к соответствующему пункту главного меню. В БДПР большинство операций с КЛП сосредоточены в веб-страницах, доступ к которым открывается только после входа в главное меню «Регистрация КЛП». Соответственно, этот пункт главного меню открывается только при наличии у пользователя какой-либо роли (неважно какой). Это – особенность именно БДПР, не входящая в стандартную схему системы разграничения доступа.  При этом состав веб-страниц, к которым пользователь может получить доступ, определяется набором предоставленных разрешений (во всех предоставленных ролях).

Другой специфической для БДПР особенностью, также выходящей за рамки стандартной системы разграничения доступа, является разграничение доступа к списку КЛП региональной базы данных. В системе имеется единый набор базовых таблиц, в которых хранятся все КЛП. Но каждый ЦСМ с ролью «Сотрудник ЦСМ», имеет доступ к операциям ведения только своей региональной базы. Обеспечивается это тем, что в таблице users содержится специальное поле, в которое заносится код ЦСМ, который одновременно является ключом для каждой записи КЛП в главной таблице clp_main. Если, например, сотрудник ЦСМ ищет КЛП, который ему нужно отредактировать, то он в списке выбора видит только те КЛП, у которых код ЦСМ содержится в его записи в таблице users.

Все описанное создает несколько барьеров на пути несанкционированного доступа. Во-первых, если пользователь даже зарегистрировался на портале, и залогинился (вошел в систему) – он все равно не получает доступ к основному пункту главного меню («Регистрация КЛП») до тех пор, пока не получит роль «Сотрудник ЦСМ».

Во-вторых, даже если он получит роль «Сотрудник ЦСМ», но ему не будет назначен код ЦСМ, он не получит доступ к списку КЛП региональной базы данных. По тому же самому признаку он не сможет записывать в БД КЛП после заполнения формы КЛП.

Наконец, если в результате какого-либо сбоя, просчета во время усовершенствования кода портала, или несанкционированных действий по злому умыслу, будет получен доступ к списку региональной базы, то, например, в операции сохранения КЛП в БД будет сделана дополнительная проверка на наличие соответствующего разрешения. Это – уже стандартный контроль доступа. Заполнив форму КЛП, или произведя редактирование КЛП, который удалось открыть, пользователь, не имеющий разрешения на запись, будет оповещен о том, что не обладает необходимыми полномочиями, а КЛП не будет записан в БД.

Таким образом, в рассматриваемом примере, для ввода в БД нового КЛП необходимо наличие сразу нескольких разрешений:

- наличие доступа к меню «Регистрация КЛП»,

- наличие доступа к региональной базе по коду ЦСМ,

- наличие доступа к операции «Ввод в БД нового КЛП»,

- наличие доступа к операции «Запись КЛП в БД».

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