CC BY
22постоянное изменение вводной информации оказывает большое влияние на сложность данной задачи.
Предложенный алгоритм
автоматизированного составления расписания позволяет сократить трудозатраты на составление расписания смен сотрудников, работающих на объектах компании.
Жадный алгоритм, лежащий в основе автоматизированной части алгоритма составления расписания, позволяет получать первоначальную версию расписания, которая будет близка к оптимальному. При этом данный алгоритм обладает высокой производительностью, что позволяет получить первоначальную версию расписания в короткие сроки.
Список литературы
1. Самсонова Н. В., Симонов А. Б. Составление расписания в высшем учебном
УДК 004.421
заведении: математические методы и программные продукты // E-Management. 2018. №1.
2. Галаванова Ю. И. Обзор современных методов в автоматизации составления расписания в организациях общего образования // Достижения науки и образования. 2018. №3 (25).
3. Игошин В. И. Математическая логика и теория алгоритмов: учеб. Пособие для студ. высш. учеб. Заведений. -2-е изд., стер. -М.: Издательский центр «Академия», 2008. -448 с
4. Чеботарев В.Е., Косенко В.Е. Проектирование информационных систем: учебное пособие. К.: СГАКУ, 2015. —448 с.
5. Кормен, Т., Лейзерсон, Ч., Ривест, Р., Штайн, К. Алгоритмы: построение и анализ — 2-е изд. — М.: Вильямс, 2005. — 1296 с.
6. Маркелов, М. М. Управление нагрузкой на операторов в системах массового обслуживания с использованием интеллектуального анализа данных// Восточно-Европейский научный журнал. - 2021. - № 1-4(65). - С. 54-57.
Плетнев Андрей Владимирович
Независимый исследователь, Директор ТОО «SimCo Soft», Руководитель группы разработки ТОО «OneBill», Республика Казахстан, г. Алматы Поляков Сергей Владимирович кандидат технических наук, бизнес-коуч, инвестор.
Российская Федерация, г. Москва.
ОРГАНИЗАЦИЯ РАЗГРАНИЧЕНИЯ ДОСТУПА ПОЛЬЗОВАТЕЛЕЙ К ФУНКЦИОНАЛУ
ИНФОРМАЦИОННОЙ СИСТЕМЫ.
Pletnev Andrey Vladimirovich
Independent researcher, CEO «SimCo Soft» LLP, Team lead «OneBill» LLP, Republic of Kazakhstan, Almaty city.
Polyakov Sergey Vladimirovich PhD, business coach, investor.
Russian Federation, Moscow
ORGANIZATION OF USER ACCESS DIFFERENTIATION TO INFORMATION
SYSTEM FUNCTIONALITY.
DOI: 10.31618/ESSA.2782-1994.2022.1.77.232
Аннотация. Данная статья предлагает практическое руководство по организации разграничения доступа пользователей к функционалу информационной системы на основе усовершенствованной автором классической схемы Ролевой Модели управления доступом пользователей. Даются рекомендации по внедрению предлагаемой системы разграничения доступа в информационную систему. Кратко затрагивается особенность построения механизма аутентификации пользователей с использованием web-токенов в контексте предлагаемой системы.
Abstract. This article offers practical guide on how to organize user access differentiation to information system functionality on the basis of the author's improvement of the classical scheme of the Role Model of user access control. Recommendations on the implementation of the proposed system of access differentiation in the information system are given. The peculiarities of the construction of the mechanism of user authentication using web-tokens in the context of the proposed system are briefly touched upon.
Ключевые слова: ролевая модель доступа, информационные системы, web-технологии, web-токен, backend, frontend.
Keywords: role model access, information systems, web-technologies, web-token, backend, frontend.
Введение
При проектировании информационной системы (ИС) перед системными архитекторами и разработчиками программного обеспечения, наряду с задачами по реализации основного бизнес-функционала ИС, также стоит задача по обеспечению информационной безопасности [5] разрабатываемой ИС. Одним из методов обеспечения информационной безопасности является ограничение доступа к информации, которое включает применение Механизмов Аутентификации Пользователей (МАП) и Систем Разграничения Доступа Пользователей (СРДП) к функционалу и ресурсам ИС. МАП позволяет ограничить круг пользователей ИС - в систему сможет войти только тот пользователь, учетная запись для которого существуют в базе данных ИС и эта запись имеет разрешение на вход пользователя. СРДП определяет права зарегистрированных пользователей на доступ к той или иной информации внутри ИС, а также права на создание и изменение этой информации. В настоящее время для программной реализации этих механизмов для всех популярных языков программирования существует множество готовых библиотек и модулей, каждые из которых решают узкий круг задач. Одна библиотека реализует МАП, другая - механизмы СРДП. Одна предназначена для работы в составе серверного backend, другая -на клиентском frontend. При этом, комплексного решения не существует и каждый разработчик ИС использует свой набор библиотек и модулей, а также способы их связывания между собой для реализации поставленных задач по аутентификации пользователей и разграничения их доступа к ресурсам внутри ИС. К основным недостаткам практики использования множества сторонних библиотек и модулей в большинстве случаев можно отнести:
- слабую связанность подключаемых библиотек и модулей между собой;
- избыточную или недостаточную функциональность;
- отсутствие каких-либо гарантий дальнейшей поддержки библиотеки или модуля и их совместимости с используемым окружением в будущем с развитием языка программирования и\или технологий.
В данной статье я хочу представить свое решение данной задачи с использованием всего одной подключаемой сторонней библиотеки на стороне серверного backend и реализующей функционал МАП. Для реализации механизмов СРДП никакие дополнительные библиотеки не потребуются. Данное решение я неоднократно и успешно применял при разработке клиент-серверных [3] ИС самого разного назначения: от простых CRM до Систем корпоративного документооборота и Панелей Управления Платежными Системами. Это означает, что описанные методы реализации СРДП применимы к
любому типу ИС, разрабатываемых с применением любого технологического стека [2].
Организация СРДП
Для организации СРДП к функционалу ИС я в своих проектах использую классическую схему Ролевой Модели (РМ) с небольшими, но функционально существенными доработками.
Итак, классическая схема РМ предполагает, что СРДП в ходе своей работы оперирует тремя сущностями данных: Пользователь, Роль и Ресурс. Понятие «Ресурс» в данном случае следует трактовать как совокупность локального бизнес-функционала ИС, относящегося к управлению данными одной бизнес-сущности внутри этой ИС, например: «Справочник контрагентов», «Справочник Терминалов», «Управление пользователями», «Отчеты», «Просмотр статистики» и т.п. Каждому Пользователю ИС может быть назначена одна или несколько Ролей, а каждая Роль может включать один или несколько Ресурсов ИС. Одновременно с этим: одна Роль может быть назначена нескольким Пользователям, а один Ресурс может принадлежать нескольким Ролям. Таким образом каждый Пользователь обеспечивается определенным набором Ресурсов, доступных ему внутри ИС. Теоретическую базу по теме РМ в СРДП можно изучить в [4], [6] и [8].
Основным недостатком классической РМ можно считать ее недостаточную гибкость в некоторых ситуациях, когда, например, для одной Роли нужно дать полный доступ к определенному Ресурсу, а для другой Роли - доступ только на просмотр данных этого же Ресурса и т.п.
Предлагаемые мной доработки классической схемы РМ включают следующее:
1. Иерархическая организация Ресурсов. Данная практика позволит выполнять группировку Ресурсов ИС по функциональным разделам. Например: «Справочники», «Отчеты», «Документы», «Статистика» и т.п. Практическим применением данного решения является возможность автоматической генерации содержимого главного меню ИС с учетом имеющихся у текущего пользователя прав доступа к Ресурсам ИС и выдача его во йшШеМ для отображения этому пользователю. При этом разработчику йшШеМ нет необходимости вести в проекте разработку главного меню ИС, вместо этого он будет получать готовое содержимое этого меню с сервера;
2. Добавление дополнительной сущности «Действия» в структуру данных механизма СРДП. Сущность «Действия» определяет набор атрибутов доступа к Ресурсам ИС, например: «чтение\просмотр данных», «добавление записей», «изменение записей», «удаление записей» и «восстановление записей». Эти атрибуты ассоциируются с Ресурсом, а их значения определяются при установлении связи Ресурса и Роли. Таким образом, мы получаем следующую схему взаимосвязи сущностей в СРДП: Пользователь - Роль - Ресурс - Действия, в
которой каждый Ресурс может наделяться собственным набором Действий;
3. Внести небольшие доработки в код backend и frontend ИС с целью обеспечения полного функционирования предлагаемой СРДП (см. далее).
На основании требований, предъявляемых к реализации классической РМ и
усовершенствований, введенных в нее, можно построить схему данных, представленную на Рисунке 1.
Рисунок 1. Схема данных для СРДП
Данная схема демонстрирует сущности доработанной РМ, задействованные в предлагаемой СРДП и связи между ними, а также пример их реализации на реляционной базе данных [1]. По структуре данных представленной на Рисунке 1 видно, что список Действий может свободно дополняться разработчиком ИС новыми элементами, потребность в которых может возникнуть с учетом всего огромного разнообразия функционала разрабатываемой ИС, а не только обычные «чтение», «запись» и «удаление». Теперь давайте разберем назначение каждой из представленных таблиц и полей в них.
User - имплементирует сущность «Пользователь». Хранит учетные записи Пользователей ИС и используется в МАП ИС. Назначение полей таблицы User:
— id - Идентификатор пользователя. Автоинкрементное поле;
— name - ФИО пользователя;
— email - Адрес электронной почты пользователя;
— login - Логин пользователя;
— passwd - Хэш пароля пользователя;
— salt - Зашифрованный Секретный ключ для подписи токена (см. раздел «Аутентификация пользователя ИС»);
— disabled - Блокировка пользователя;
— blocked_until - Блокировка пользователя до указанной даты и времени;
— created_at - Дата и время создания записи;
— deleted_at - Дата и время удаления записи.
Role - имплементирует сущность «Роль». Хранит список Ролей Пользователей ИС. Назначение полей таблицы Role:
— id - Идентификатор роли. Автоинкрементное поле;
— name - Имя роли;
— disabled - Блокировка роли;
— created_at - Дата и время создания записи;
— deleted_at - Дата и время удаления записи. Resource - имплементирует сущность
«Ресурс». Хранит упорядоченный иерархический список Ресурсов ИС, доступ к которым нужно предоставлять\ограничивать Пользователям ИС. Кроме этого, на основании данных этой таблицы, как упоминалось выше, серверный backend ИС выдает список пунктов главного меню, доступных Пользователю, для отображения на frontend ИС. Доступ на внесение и правку данных этой таблицы должен быть только у разработчика ИС. Данные, внесенные в эту таблицу, должны быть согласованы с разработчиком frontend ИС. Назначение полей таблицы Resource:
- id - Идентификатор Ресурса. Автоинкрементное поле;
- parent_id - Идентификатор родительского Ресурса;
- name - Наименование Ресурса;
- internal_name - Внутреннее служебное имя Ресурса. Уникальный строковый идентификатор Ресурса. Используется механизмами СРДП на backend (см. раздел «Механизмы проверки действий Пользователя на сервере»). Может использоваться как идентификатор строкового ресурса в модуле интернационализации на frontend - в данном случае Значение этого параметра обязательно должно быть согласовано с разработчиком и\или специалистом по интернационализации frontend ИС;
- sort_order - Порядок сортировки при отображении в меню на frontend;
- router_path - Путь к пользовательскому интерфейсу Ресурса в локальном роутере frontend. Значение данного параметра обязательно должно быть согласовано с разработчиком frontend ИС;
- icon - Иконка, отображаемая для пункта меню на frontend;
- created_at - Дата и время создания записи;
- deleted_at - Дата и время удаления записи.
Action - имплементирует сущность
«Действие». Хранит стандартные и определяемые разработчиком ИС дополнительные Действия. Доступ на внесение и правку данных этой таблицы должен быть только у разработчика ИС. Данные, внесенные в эту таблицу, должны быть согласованы между разработчиками ИС. Назначение полей таблицы Action:
- id - Идентификатор Действия. Автоинкрементное поле;
- name - Наименование Действия (Например: чтение, запись, удаление, восстановление, просмотр информации о записи);
- internal_name - Внутреннее служебное имя Действия. Уникальный строковый идентификатор Действия, соответствующий по смыслу его Наименованию (например: read, write, delete, restore, info). Используется механизмами СРДП на backend и frontend. Кроме этого, может использоваться как идентификатор строкового ресурса в модуле интернационализации на frontend. Значение этого параметра обязательно должно быть согласовано с разработчиком backend и с разработчиком и\или специалистом по интернационализации frontend ИС;
- sort_order - Порядок сортировки при отображении на frontend.
UserRoles - имплементирует связь сущностей «Пользователь» и «Роль» в отношении многие-ко-многим: одна Роль может быть назначена одному или нескольким Пользователям, а Пользователь может иметь одну или несколько Ролей. Все разрешенные Действия на связанных с Ролью Ресурсах будут доступны Пользователю, которому
назначена эта Роль. Добавление записи в таблицу UserRoles устанавливает связь Пользователя и Роли, идентификаторы которых были использованы для добавления записи. Для прекращения действия установленной связи необходимо просто удалить нужную запись из таблицы. Назначение полей таблицы UserRoles:
- user_id - Идентификатор Пользователя. Внешний ключ к таблице User;
- role_id - Идентификатор Роли. Внешний ключ к таблице Role.
ResourceActions - имплементирует связь сущностей «Ресурс» и «Действие» в отношении многие-ко-многим: одно Действие может быть назначено одному или нескольким Ресурсам, а Ресурс может иметь одно или несколько Действий. Добавление записи в таблицу ResourceActions устанавливает связь Действия и Ресурса, идентификаторы которых были использованы для добавления записи. Установленные связи будут определять, какие Действия будут доступны на Ресурсе при установке связей Роль-Ресурс (см. RoleResourceActions ниже). Для прекращения действия установленной связи необходимо просто удалить нужную запись из таблицы. Назначение полей таблицы ResourceActions:
- resource_id - Идентификатор Ресурса. Внешний ключ к таблице Resource;
- action_id - Идентификатор Действия. Внешний ключ к таблице Action.
RoleResourceActions - имплементирует связь сущностей «Роль» и «Ресурс» в отношении многие-ко-многим: один Ресурс может быть назначен одной или нескольким Ролям, а Роль может включать доступ к одному или нескольким Ресурсам. Кроме этого, данная таблица имплементирует определение разрешенного Действия для установленной связи Роль-Ресурс. Для определения нескольких Действий для установленной связи Роль-Ресурс необходимо добавить соответствующее количество записей с нужными идентификаторами Роли, Ресурса и Действия. Для отмены разрешенного Действия для установленной связи Роль-Ресурс, необходимо просто удалить нужную запись из таблицы. Назначение полей таблицы RoleResourceActions:
- role_id - Идентификатор Роли. Внешний ключ к таблице Role;
- resource_id - Идентификатор Ресурса. Внешний ключ к таблице Resource;
- action_id - Идентификатор Действия. Внешний ключ к таблице Action. Определяет разрешенное Действие для Роли на указанном Ресурсе.
Управление доступом пользователей внутри ИС
Всей структурой данных, описанной выше для использования в предлагаемой СРДП, теперь нужно как-то управлять. Для этого в ИС выделяют специальный раздел для Администратора Системы и создают в нем все необходимые формы и прочие элементы пользовательского интерфейса,
предназначенные для управления системными параметрами и свойствами ИС, в том числе и для управления Пользователями, а также их доступом к Ресурсам ИС. Такой раздел ИС принято называть Панелью Администратора. При этом следует понимать, что «Администратор Системы» - это такой же пользователь ИС, как и все остальные, но наделенный правами доступа в Панель Администратора. Таким образом, исходя из предлагаемой СРДП, любой пользователь может стать Администратором Системы, а у любого такого Администратора может быть разный уровень доступа к элементам Панели Администратора.
Для обеспечения управления описанной структурой данных в Панели Администратора Вашей ИС необходимо выполнить следующее:
1. Создать справочник «Действия»;
2. Создать справочник «Ресурсы». Ресурсы в справочнике отображать в виде отсортированного иерархического списка, согласно тому, как они записаны в таблице Resource базы данных. Для удобства желательно обеспечить перемещение элементов для изменения порядка их сортировки, а также по уровням иерархии путем перетаскивания мышью. Если на frontend Вашей ИС используется модуль интернационализации, задействуйте поле internal_name, возвращаемое сервером из таблицы Resource в качестве идентификатора строки для получения перевода наименований Ресурсов из словарей модуля интернационализации;
3. Создать раздел «Роли пользователей», в котором реализовать:
- создание новой Роли;
- изменение наименования существующей Роли;
- выбор Действий у необходимых Ресурсов для включения соответствующих доступов в выбранную Роль. Пример реализации пользовательского интерфейса для определения доступов Роли к Действиям на Ресурсе представлен на Рисунке 2. В данном интерфейсе необходимо реализовать отображение Действий слева направо в порядке возрастания значения поля sort_order, возвращаемое из таблицы Action. Если на frontend Вашей ИС используется модуль интернационализации, задействуйте поле internal_name, возвращаемое сервером из таблицы Action в качестве идентификатора строки для получения перевода наименований Действий из словарей модуля интернационализации;
4. В разделе управления пользователями:
- на стороне backend, при создании нового пользователя, обеспечить генерацию секретного ключа, его шифрование и сохранение полученного значения в поле salt таблицы User (см. Рисунок 1);
- на форме создания\редактирования Пользователя добавить вкладку, где Администратор ИС будет назначать Роли для Пользователя путем выбора одной или нескольких Ролей из списка;
Statistics 0 view
Actual Statistics 0 view
Sales □ view
Directories 0 view
Partners 0 view 0 add 0 edil 0 delete 0 restore
Customers □ view 0 add 0 edil 0 delete 0 restore
Branches 0 view 0 add 0 edil 0 delete 0 restore
Products 0 view 0 add 0 edil 0 delete 0 restore
Reports □ view
Proceeds 0 view 0 print 0 export
Branch turnovers □ view □f □ export
Orders 0 view 0 print 0 export
Taxes 0 view 0 print □ export
Administering 0 view
System status 0 view
Mailing list settings 0 view 0 edil
User management 0 view
Users 0 view 0 add 0 edil 0 delele 0 restore 0 sei roles
User roles 0 view 0 add 0 edü 0 delete □ restore
Resources view add 0 edil □ delete restore
Actions 0 view LId edil □ delete □ restore
Рисунок 2. Пример реализации пользовательского интерфейса для конфигурирования доступов Роли к Действиям на Ресурсах в Панели Администратора ИС
Аутентификация пользователя ИС
В последнее время широкое распространение получил способ аутентификации пользователя с использованием токенов доступа, называемых также web-токенами. Токены создаются сервером, подписываются секретным ключом и передаются клиенту, который в дальнейшем использует данный токен для подтверждения своей личности. Наиболее популярным в данной сфере является стандарт JSON Web Token (JWT) [9]. Его я и рекомендую использовать для реализации МАП в Вашей ИС. На странице jwt.io/libraries вы сможете подобрать наиболее подходящую библиотеку для работы с JWT для используемого Вами языка программирования на стороне backend. К слову, эта та самая библиотека, которая упоминалась в начале статьи, как единственная сторонняя библиотека, подключаемая в проект ИС для реализации МАП. Также на сайте проекта jwt.io вы сможете найти всю необходимую документацию, описание стандарта и примеры использования подключаемых библиотек.
Основным преимуществом использования web-токенов в контексте рассматриваемой темы является возможность включения в тело создаваемого токена полезной нагрузки (payload), скрытой от посторонних глаз применяемыми стандартом JWT алгоритмами шифрования. Используем эту возможность.
В проекте backend Вашей ИС сделайте следующее:
1. Добавляйте идентификатор авторизовавшегося пользователя в структуру payload при создании токена - этот идентификатор потребуется в работе механизмов СРДП (см. раздел «Механизмы проверки Действий Пользователя на стороне сервера»);
2. В качестве секретного ключа для подписи создаваемого токена используйте предварительно расшифрованное значение поля salt учетной записи авторизовавшегося пользователя (см. Рисунок 1).
В проекте frontend Вашей ИС необходимо выполнить следующие работы:
1. Добавьте в проект страницу с формой авторизации Пользователя и создайте маршрут к ней в локальном роутере;
2. Организуйте отправку данных с формы авторизации Пользователя на сервер, а также обработку и отображение ошибок процесса аутентификации;
3. В случае успешной аутентификации Пользователя сохраняйте полученный токен и, если есть, по необходимости, другие данные из ответа сервера в локальное хранилище браузера (local storage) и перенаправьте Пользователя на главную страницу ИС;
4. Добавьте в проект страницу «В доступе отказано» и создайте маршрут к ней в локальном роутере;
5. Используйте сохраненный в локальном хранилище браузера токен при отправке каждого запроса к Ресурсам ИС, требующим авторизованного доступа. В случае, когда на такой
запрос от сервера получен ответ с кодом состояния HTTP* 401, перенаправьте Пользователя на страницу с формой авторизации. В случае, когда на такой запрос от сервера получен ответ с кодом состояния HTTP 403, перенаправляйте Пользователя на страницу «В доступе отказано», либо отображайте всплывающее сообщение об отсутствии прав доступа.
* Список всех кодов состояния HTTP можно изучить на страничке Википедии [7];
Механизмы ограничения действий Пользователя на клиенте
Первую линию обороны от
несанкционированных действий Пользователя в контексте СРДП представляют правильно реализованные механизмы ограничения таких действий на frontend (клиентской стороне) ИС. Их всего три, а именно:
1. После успешного выполнения авторизации Пользователя и перехода на главную страницу ИС в Вашем frontend необходимо выполнить запрос содержимого главного меню с сервера и отобразить его пользователю. Сервер возвратит только те пункты меню, Ресурсы которых входят в ассоциированные и не заблокированные Роли Пользователя, у которых в списке разрешенных Действий есть, как минимум, разрешение на просмотр данных. Сохраните полученные данные с содержимым главного меню в хранилище состояний (Store) Вашего frontend. Если на frontend Вашей ИС используется модуль интернационализации, задействуйте поле internal_name, возвращаемое сервером из таблицы Resource в качестве идентификатора строки для получения перевода наименований Ресурсов (пунктов меню) из словарей модуля интернационализации;
2. При переходе в один из пунктов меню frontend, согласно инструкции локального роутера, выполняет переход на страницу, где, как правило, реализован функционал по управлению данными одной из множества бизнес-сущностей (Ресурсов) ИС. Данный функционал, как правило, реализован в виде табличного представления данных Ресурса и несколько кнопок для управления этими данными: чаще всего «Добавить», «Изменить» и «Удалить». При переходе на такую страницу frontend запрашивает с сервера ИС и получает в ответе данные Ресурса для отображения их в табличном виде. Кроме этих данных сервер возвращает список разрешенных для этого Ресурса Действий, определенных для текущего Пользователя через его не заблокированные Роли. На основании полученного списка разрешений frontend отображает, либо скрывает кнопки управления данными Ресурса, идентифицируя их по значению поля internal_name, передаваемого сервером из таблицы Action через установленные связи между сущностями СРДП в базе данных (см. Рисунок 1);
3. Добавьте в локальный роутер функцию-обработчик события, срабатывающего непосредственно перед переходом по локальному
маршруту. В этой функции выполните проверку наличия целевого маршрута в хранилище состояний (Store), где ранее были сохранены данные с содержимым меню. В случае отсутствия целевого маршрута среди данных в хранилище состояний следует прервать переход по такому маршруту и повторно запросить с сервера и отобразить содержимое главного меню.
Механизмы проверки действий
Пользователя на сервере
Вторую линию обороны от
несанкционированных действий Пользователя в контексте СРДП занимают механизмы проверки его действий, реализованные на стороне сервера ИС. Данные механизмы необходимы для соблюдения строгих норм информационной безопасности в части ограничения доступа к информации, например:
- в случаях, когда Администратор ИС в одной из Ролей удалил разрешение на какое-то Действие или вовсе заблокировал одну из Ролей или заблокировал учетную запись Пользователя, а Пользователю на frontend об этом еще «не известно» (Пользователь перешел на страницу Ресурса до отмены Администратором разрешений и не обновлял страницу);
- в случаях, когда не в меру любознательный Пользователь или злоумышленник, используя инструменты разработчика, встроенные в браузер, разобрался с тем, как frontend работает с API backend^ и пытается слать беспорядочные запросы на сервер;
- в случаях, когда злоумышленник, используя инструменты разработчика, встроенные в браузер, смог вмешаться в код Вашего frontend и изменить состояния элементов управления или смог изменить значения переменных в хранилище состояний, позволившие ему выполнить некоторые действия, которые ему до этого были недоступны в силу отсутствия необходимых доступов.
Всех этих ситуаций можно избежать, реализовав в коде backend пару простых функций, образующих вместе надежный механизм проверки действий Пользователя:
1. Реализуйте функцию для извлечения идентификатора Пользователя из секции payload передаваемого frontend'ом токена. Назовем эту функцию ExtractUID. В качестве параметра функция будет принимать строку токена Пользователя, а в качестве результата возвращать извлеченный идентификатор этого Пользователя;
2. Реализуйте функцию для проверки наличия у Пользователя разрешения на выполнения Действия для указанного Ресурса. Назовем эту функцию UserPermissionCheck. В качестве параметров функция будет принимать три параметра: идентификатор пользователя, строковый идентификатор Ресурса (значение поля internal_name из таблицы Resource) и строковый идентификатор Действия (значение поля internal_name из таблицы Action). Используя полученные значения входных параметров,
функция UserPermissionCheck выполняет запрос к базе данных, который проверяет наличие соответствующих записей в таблицах RoleResourceActions и UserRoles, а также не заблокирована ли учетная запись Пользователя и его Роль\Роли (см. Рисунок 1). В случае наличия нужных записей в указанных таблицах и отсутствии блокировок, функция
UserPermissionCheck возвратит true, иначе - false;
3. Поместите вызов ExtractUID в самом начале каждого обработчика запроса к методам всех Ресурсов. В случае ошибки следует прервать дальнейшую обработку запроса и вернуть во frontend ответ с кодом статуса HTTP 401. В случае успешного извлечения идентификатора пользователя, следует сохранить результат выполнения функции ExtractUID в переменную, например - uid;
4. Сразу после этого вызывайте функцию UserPermissionCheck, передав в нее значение переменной uid, строковый идентификатор Ресурса и строковый идентификатор Действия, соответствующие вызываемому методу. Например: UserPermissionCheck(uid, 'branches', 'view'). Если функция вернет false, следует прервать дальнейшую обработку запроса и вернуть во frontend ответ с кодом статуса HTTP 403.
Заключение
Предложенная в этой статье методика позволит реализовать СРДП к Ресурсам Вашей ИС с максимальной детализацией прав доступа, вплоть до каждой отдельной кнопки на интерфейсе пользователя ИС. Представленные доработки классической РМ, а также механизмы ограничения и проверки действий Пользователя, позволят получить разработчикам и архитекторам ИС основу для разработки собственной СРДП и ее дальнейшего совершенствования под свои нужды.
Список литературы
1. Кириллов В. В., Громов Г. Ю. Введение в реляционные базы данных. - СПб.: БХВ-Петербург, 2009.
2. Плетнев А.В. Выбор технологического стека для it-проекта / Интернаука: электрон. научн. журн. 2021. № 36(212). / [Электронный ресурс]. URL:
https://intemauka.org/joumal/science/intemauka/212 (дата обращения: 11.11.2021).
3. Клиент-сервер. / [Электронный ресурс]. URL: https://ru.wikipedia.org/wiki/Клиент_— _сервер (дата обращения: 02.09.2021).
4. Курс лекций Защита Информации/Ролевая модель. / [Электронный ресурс]. URL: https://ru.wikibooks.org/wiki/Курс_лекций_Защита_ Информации/Ролевая_модель (дата обращения: 12.11.2021).
5. Белов Максим. Основы и способы информационной безопасности в 2017 году / [Электронный ресурс]. URL: https://habr.com/ru/post/344294/ (дата обращения: 07.11.2021).
6. Севастьянова Людмила. Строим ролевую модель управления доступом. / [Электронный ресурс]. URL: https ://habr. com/ru/company/solarsecurity/blog/50999 8/ (дата обращения: 10.11.2021).
7. Список кодов состояния HTTP. / [Электронный ресурс]. https://ru.wikipedia.org/wiki/Список_кодов_состоян ия_НТТР (дата обращения: 03.11.2021).
8. Управление доступом на основе ролей. / [Электронный ресурс]. URL: https://ru.wikipedia.org/wiki/Управление_доступом_ на_основе_ролей (дата обращения: 02.11.2021).
9. JSON Web Token. / [Электронный ресурс]. URL:
https://ru.wikipedia.org/wiki/JSON_Web_Token (дата обращения: 12.11.2021).
УДК 685.34.03
Shestov A.V.
Candidate of Economic Sciences, Associate Professor of the Department of Road Economy Moscow Automobile and Road Сonstruction State Technical University
TECHNOLOGY FOR OBTAINING SPECIAL LEATHERS WITH IMPROVED PERFORMANCE CHARACTERISTICS, RESISTANT TO OIL AND PETROLEUM PRODUCTS
Шестов Андрей Владимирович
кандидат экономических наук, доцент кафедры «Экономика дорожного хозяйства» Московский автомобильно-дорожный государственный технический университет
ТЕХНОЛОГИЯ ПОЛУЧЕНИЯ СПЕЦИАЛЬНЫХ КОЖ С УЛУЧШЕННЫМИ ЭКСПЛУАТАЦИОННЫМИ ХАРАКТЕРИСТИКАМИ, УСТОЙЧИВЫХ К ВОЗДЕЙСТВИЮ
НЕФТИ И НЕФТЕПРОДУКТОВ
DOI: 10.31618/ESSA.2782-1994.2022.1.77.233 Summary. A technology is proposed for obtaining leathers for the uppers of special footwear intended for employees of oil-producing enterprises. Leathers for uppers made from cattle skins produced by this technology are distinguished by a combination of high strength, hygienic and protective characteristics, including resistance to oil and oil products, as well as to biodegradation. The technology for obtaining special shoe leathers includes a through complex processing of semi-finished leather products with non-equilibrium low-temperature plasma and a solution of silver nanoparticles .
Аннотация. Предложена технология получения кож для верха специальной обуви, предназначенной для сотрудников нефтедобывающих предприятий. Кожи для верха обуви, из шкур крупного рогатого скота (КРС), выработанные по данной технологии отличаются сочетанием высоких прочностных, гигиенических и защитных характеристик, в том числе, устойчивостью к нефти и нефтепродуктам, а так же к биодеструкции. Технология получения специальных обувных кож включает сквозную комплексную обработку кожевенных полуфабрикатов неравновесной низкотемпературной плазмой (ННТП) и раствором наночастиц серебра (НЧС).
Key words: non-equilibrium low-temperature plasma, silver nanoparticles, natural leather technology, special footwear, resistance to oil and oil products
Ключевые слова: неравновесная низкотемпературная плазма, наночастицы серебра, технология получения натуральных кож, специальная обувь, устойчивость к нефти и нефтепродуктам
Введение
В реализации процесса нефтедобычи участвуют более сорока различных профессий, осуществляющие ведение технологического процесса бурения, добычи нефти и газа, поддержания пластового давления, обезвоживания и обессоливания, контролирующие параметры оборудования, устраняющие неисправности в его работе, производящие пуско-наладочные и профилактические работы. В зависимости от выполняемой деятельности, труд работников нефтяных приисков может быть связан с динамическими нагрузками, связанными с поднятием и перемещением тяжелых предметов,
статическими нагрузками вынужденной рабочей позы при управлении оборудованием, длительным нахождением (до 80% времени рабочей смены) в положении стоя. Таким образом, условия труда работников, занятых добычей нефти, могут стать причиной профессионально-обусловленной
патологии здоровья, в связи с чем, особую роль в сохранении их здоровья имеют средства индивидуальной защиты, специальная одежда и специальная обувь.
При этом, как одежда, так и обувь работников, кроме обеспечения непосредственных защитных функций, прежде всего, не должны сковывать движение и причинять дискомфорт, а значит
