Реализация RBAC и ABAC модели авторизации в веб-приложении

1.1. Технико-экономическая характеристика предметной области и предприятия

В этом разделе даётся общая характеристика АО «РБАК АБАК Авторизация»: сфера деятельности, организационная структура, основные процессы, используемые технологии. Описывается предметная область — реализация RBAC и ABAC модели авторизации в веб-приложении, её значение для информационной безопасности.

Пример содержимого: АО «РБАК АБАК Авторизация» занимается разработкой программных решений для контроля доступа в корпоративных системах. Основной процесс — реализация — требует высокой точности и соответствия современным стандартам безопасности. В настоящее время используется упрощённая модель авторизации, что приводит к рискам несанкционированного доступа.

Сложности:

• Получение достоверных данных о предприятии (особенно если оно условное).
• Связь технических характеристик с экономическими показателями.

Время выполнения: 8–10 часов.

1.2. Характеристика комплекса задач и обоснование необходимости автоматизации

Раздел посвящён анализу текущих бизнес-процессов, выявлению узких мест и обоснованию целесообразности автоматизации процесса реализации RBAC и ABAC модели авторизации. Описываются ручные операции, их трудоёмкость и возможные ошибки.

Пример содержимого: На текущий момент управление доступом в веб-приложении осуществляется вручную через админ-панель. Это занимает до 15 часов в неделю и сопряжено с рисками дублирования ролей и ошибок при назначении прав. Автоматизация позволит сократить время на 70% и повысить безопасность.

Сложности:

• Формализация неформальных процессов.
• Обоснование необходимости именно такой модели авторизации.

Время выполнения: 6–8 часов.

1.3. Анализ существующих разработок и выбор стратегии автоматизации

Проводится обзор аналогов: готовые решения RBAC (например, Keycloak), ABAC (например, Open Policy Agent), их функциональность, плюсы и минусы. На основе анализа выбирается стратегия — например, комбинированная модель RBAC + ABAC для гибкости и масштабируемости.

Пример содержимого: Анализ показал, что Keycloak подходит для ролевого контроля, но не поддерживает атрибутную модель. Open Policy Agent — мощный, но требует интеграции. Решение: реализация RBAC и ABAC модели авторизации в веб-приложении на базе Spring Security с кастомной политикой.

Сложности:

• Сравнение технических решений без доступа к исходному коду.
• Обоснование выбора технологии.

Время выполнения: 8–10 часов.

1.4. Обоснование проектных решений

Формулируются архитектурные решения: выбор стека технологий (например, Spring Boot, PostgreSQL, JWT), структура базы данных, модель данных. Обосновывается безопасность, масштабируемость и соответствие требованиям АО «РБАК АБАК Авторизация».

Пример содержимого: Для реализации выбрана архитектура microservices с отдельным сервисом авторизации. Используются JWT-токены с вложенными ролями (RBAC) и политиками на основе атрибутов (ABAC). Это обеспечивает гибкость и централизованный контроль.

Сложности:

• Связь технических решений с бизнес-требованиями.
• Необходимость глубоких знаний в области безопасности.

Время выполнения: 10–12 часов.

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

Время выполнения: 4–6 часов.

2.1. Разработка проекта автоматизации

Описывается архитектура системы, диаграммы (Use Case, ERD, последовательности), логика взаимодействия компонентов. Подробно расписывается реализация RBAC и ABAC модели авторизации в веб-приложении.

Пример содержимого: Диаграмма Use Case показывает взаимодействие пользователей с системой: администратор создаёт роли, пользователь получает доступ на основе атрибутов (отдел, должность, проект). ERD включает таблицы: users, roles, permissions, attributes, policies.

Сложности:

• Построение корректных диаграмм в соответствии с UML.
• Согласование RBAC и ABAC на уровне бизнес-логики.

Время выполнения: 12–15 часов.

2.2. Информационное обеспечение задачи

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

Пример содержимого: Таблица roles содержит поля: id, name, description. Таблица policies — id, subject_attr, resource_attr, action, effect. Пример: {subject_attr: "отдел=IT", resource_attr: "тип=документ", action: "редактировать", effect: "разрешено"}.

Сложности:

• Создание логически непротиворечивой структуры данных.
• Связь с моделью ABAC.

Время выполнения: 8–10 часов.

2.3. Программное обеспечение задачи

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

Пример содержимого: На сервере используется Spring Security с кастомным методом @PreAuthorize, который вызывает ABAC-провайдер. Политики загружаются из базы и кэшируются. При запросе проверяются атрибуты пользователя и ресурса.

Сложности:

• Написание понятного описания кода без перегрузки техническими деталями.
• Соблюдение баланса между теорией и практикой.

Время выполнения: 10–12 часов.

2.4. Контрольный пример реализации проекта и его описание

Приводится сценарий тестирования: пользователь из отдела IT пытается редактировать конфиденциальный документ. Система проверяет роль (RBAC) и атрибуты (ABAC), разрешает доступ. Описывается результат.

Пример содержимого: Пользователь с ролью "Менеджер" и атрибутом "проект=Alpha" пытается открыть документ "Alpha_финансы.xlsx". Политика разрешает доступ. При попытке открыть "Beta_финансы.xlsx" — отказ.

Сложности:

• Построение реалистичного, но простого сценария.
• Описание результата в соответствии с требованиями ГОСТ.

Время выполнения: 8–10 часов.

Выводы по главе 2 — разработана и описана полная архитектура системы, реализованы модели RBAC и ABAC, проведён контрольный пример. Решение соответствует поставленным задачам и требованиям предприятия.

Время выполнения: 4–6 часов.

3.1. Выбор и обоснование методики расчёта экономической эффективности

Обосновывается выбор методики — например, расчёт годового экономического эффекта по методике Минэкономразвития РФ. Описываются допущения: срок службы системы — 5 лет, ставка дисконтирования — 10%.

Пример содержимого: Для оценки эффективности выбрана методика расчёта чистого дисконтированного дохода (ЧДД) и срока окупаемости. Основные статьи расходов — разработка, тестирование, внедрение.

Сложности:

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

Время выполнения: 6–8 часов.

3.2. Расчёт показателей экономической эффективности проекта

Проводятся расчёты: снижение трудозатрат, сокращение простоев, предотвращение утечек данных. Рассчитывается ЧДД, ВНД, срок окупаемости.

Пример содержимого: Годовая экономия за счёт автоматизации — 480 тыс. руб. (сокращение 15 часов/неделя × 50 руб./час × 50 недель). Капитальные затраты — 600 тыс. руб. Срок окупаемости — 1,25 года.

Сложности:

• Корректность расчётов и единиц измерения.
• Связь технических результатов с экономическими показателями.

Время выполнения: 8–10 часов.

Выводы по главе 3 — проект является экономически эффективным: ЧДД положительный, срок окупаемости менее 2 лет. Реализация RBAC и ABAC модели авторизации оправдана с точки зрения затрат и выгод.

Время выполнения: 4–6 часов.