Модуль платформы, а не отдельное приложение поверх неё

Точки входа модуля

У модуля — разные точки входа для рабочего контура и для контура администрирования, а маршрутизация после входа зависит от набора ролей пользователя: сотрудник с рабочими ролями попадает в реестры планов и тестирований, а «ИБ-администратор» — в собственный контур настройки ролей и прав, недоступный остальным ролям вообще.

Навигатор модуля

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

Зависимости от платформы

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

• Веб-интерфейсобщий с платформой
• Модель безопасностиобщий движок платформы + собственная схема ролей модуля
• Уведомленияобщие платформенные обработчики рассылки
• Построение представлений и отчётовобщий индикативный движок платформы

Интеграция с СУОН

Модуль не ведёт собственный справочник критических процессов, офисов, поставщиков, систем и оргструктуры — он опирается на общие справочники смежного модуля операционной надёжности и достраивает над ними свою предметную область: план восстановления, годовую аттестацию и тестирования. Карточка поставщика внутри модуля способна перевести статус согласования поставщика в общем справочнике и открыть переход в его исходную карточку — без повторного ввода тех же данных в двух местах.

Интеграция с ISM

Недостаток, выявленный при тестировании, не остаётся записью внутри одной карточки: тест можно связать с конкретным Issue модуля управления недостатками (ISM) и с его корректирующим планом (CAP), а Issue ID автоматически подтягивается в раздел годовой аттестации и в отчёты по тестированию — устранение недостатка ведётся там, где для этого есть весь процесс, а не дублируется внутри модуля непрерывности.

Собственная схема данных

У модуля — две собственные схемы: рабочие данные (планы, тесты, справочники) и отдельная схема контура прав и аудита, физически отделённая от рабочих данных. Миграции ведутся тем же Liquibase-конвейером, что и у остальной платформы, — по слоям: сначала базовая структура и метаданные, затем последовательные версии доработок.

• 2собственные схемы: рабочие данные и контур прав/аудита
• ~25таблиц предметной области в рабочей схеме
• 3представления, агрегирующие данные планов и сотрудников
• 13типов объектов защиты в собственной модели прав

Требования к развёртыванию

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