Архитектура и внедрение
Модуль недостатков — часть единой платформы «Ланселот», а не отдельное приложение со своей базой правил. Общее ядро безопасности, общий движок представлений и общая индикативная модель данных — значит, один периметр развёртывания, одна модель прав и один архитектурный разговор с вашей ИТ-службой на все модули сразу.
Общая архитектура
ISM зарегистрирован в платформе как модуль управления недостатками — 181 класс серверной логики, 56 экранов интерфейса, 141 файл миграций базы данных. Технологический стек не завязан на внешние облачные сервисы: Java-сервис поверх PostgreSQL, очереди RabbitMQ для интеграции и объектное хранилище MinIO для файлов — всё разворачивается в периметре заказчика вместе с ядром платформы.
Статусные модели, движок представлений, разграничение доступа и индикативное хранение данных — общие компоненты ядра платформы, а не изобретённые заново под один модуль. Это значит, что стандарты безопасности и администрирования, принятые для других модулей платформы, действуют и здесь без исключений.
Что это даёт ИТ-директору
Границы модуля чёткие: 181 класс и 56 экранов зарегистрированы под собственным идентификатором в общей конфигурации безопасности платформы, а зависимости от общего ядра — это переиспользование проверенной инфраструктуры (аутентификация, журнал переходов, представления), а не бесконтрольное расползание кода. Собственная схема данных ism и собственная схема прав securityism не пересекаются с другими модулями напрямую — обновление ISM не требует пересборки всей платформы целиком.
Интеграция с внешней системой-источником через RabbitMQ
С внешней системой-источником недостатков модуль обменивается сообщениями по очередям RabbitMQ в обе стороны: внешняя система создаёт и обновляет недостатки в ISM, ISM отправляет обратно результаты обработки. Интеграция включается только тогда, когда в окружении настроено подключение к брокеру сообщений — без него модуль работает как обычно, просто без этого канала.
- Создание недостаткаВходящее сообщение создаёт карточку Issue с заранее определёнными значениями по умолчанию
- Обновление рискаИзменение оценки риска и обновление ключа источника без дублирования записи
- Запрос атрибутовISM отвечает актуальным состоянием карточки по запросу внешней системы
Дублей не будет, даже если сообщение придёт дважды
Каждый недостаток из внешнего источника хранит уникальный ключ записи. Повторное сообщение по той же записи не создаёт вторую карточку — интеграция идемпотентна по построению, а не по соглашению на бумаге.
Если приёмник сообщений не может подняться из-за ошибки окружения, модуль не роняет весь сервис целиком: слушатель деактивируется, а остальная система продолжает работать без интеграционного канала.
Хранение файлов
Вложения к недостаткам, планам и исключениям, а также сами шаблоны отчётов хранятся в объектном хранилище MinIO — не в базе данных и не на диске сервера приложений. Один и тот же компонент хранения переиспользуют и другие модули платформы: это типовой инфраструктурный сервис, а не разовое решение под один модуль.
База данных
Схема данных модуля — 114 таблиц в собственной схеме ism, плюс отдельная схема прав securityism. Все изменения структуры версионируются миграциями Liquibase — 141 файл на четыре поставленных релиза, применяются последовательно и воспроизводимо на любом новом окружении.
- 114таблиц в схеме
ism - 141файл миграций Liquibase
- 7представлений для отчётности
ism.reported_*
В поставленном коде миграции написаны для диалекта PostgreSQL.
Зависимости от ядра платформы
Модуль не дублирует общую инфраструктуру платформы — он на неё опирается. Больше всего связей у индикативной модели данных, ядра безопасности и движка представлений: это значит, что при развитии ядра (например, при обновлении механизма аутентификации) модулю не нужна отдельная доработка того же самого.
| Компонент ядра | Что переиспользует ISM |
|---|---|
| Индикативная модель | Хранение и чтение значений полей карточек — общий движок данных платформы |
| Ядро безопасности | Роли, права, текущий пользователь, менеджер безопасности |
| Движок представлений | Настраиваемые списки, фильтры и конструктор отчётов |
| Общий журнал переходов | История смены статусов — тот же механизм, что и в других модулях платформы |
| Уведомления и сотрудники | Рассылка push и e-mail, справочник сотрудников |
Требования к развёртыванию
Часть параметров модуль подстраивает под организацию заказчика без изменения кода:
- Роли и оргструктура18 ролей раскладываются на подразделения заказчика — состав и назначение настраиваются на внедрении
- Расписание пересчётаПериодичность фоновых задач и нерабочие дни задаются в интерфейсе, отдельно от кода
- Отчётные шаблоныСостав шаблонов и представлений отчётности можно расширять поверх поставленных шести
- Справочник источниковИерархия источников недостатков и линий защиты настраивается под структуру линий защиты заказчика
Что фиксируется на проекте внедрения: поддерживаемые версии СУБД, операционных систем и браузеров клиентского места, срок типового внедрения и состав пилота, параметры технической поддержки и модель лицензирования — это условия конкретного проекта, они закрепляются в техническом задании и договоре на внедрение.
Глубокая техническая документация — по запросу после заключения соглашения о конфиденциальности
Продукт поставляется с семью руководствами для разных ролей — от администратора до участника проверки качества данных. Карта интеграций, словарь данных и руководство администратора безопасности — материалы для службы безопасности заказчика: передаются по запросу и после заключения соглашения о конфиденциальности, через форму на странице контактов.
Обсудить схему развёртывания под вашу инфраструктуру
Периметр развёртывания, интеграция с внешними источниками, состав базы данных и зависимости от ядра платформы — обсудим предметно на звонке с вашей ИТ-службой, с конкретными ответами, а не общими словами.