Архитектура программного обеспечения AIINS

ОГЛАВЛЕНИЕ

1. Архитектурный стиль и общие принципы

• 1.1. Назначение и концепция ИТ-контура Системы
• 1.2. Описание трехзвенной клиент-серверной архитектуры 
• 1.3. Принципы внутренней организации и модульного монолита 
• 1.4. Обеспечение технологического суверенитета и импортонезависимости

2. Уровни архитектуры и технологический стек 

• 2.1. Уровень представления (Front-end)
• • 2.1.1. Используемые языки программирования, библиотеки и фреймворки
  • 2.1.2. Механизмы клиентской валидации и рендеринга данных
• 2.2. Уровень бизнес-логики (Back-end)
• • 2.2.1. Ядро Системы и серверные веб-фреймворки
  • 2.2.2. Обратный прокси-сервер и диспетчеризация процессов
  • 2.2.3. Подсистема очередей и фоновой обработки тяжелых задач
• 2.3. Уровень хранения данных 
• • 2.3.1. Реляционная система управления базами данных (СУБД)
  • 2.3.2. Объектное хранилище неструктурированных данных (S3)

3. Среда функционирования и системные требования к инфраструктуре  

• 3.1. Поддерживаемые серверные операционные системы (семейство Linux / российские ОС)
• 3.2. Среда контейнеризации и виртуализации компонентов Системы
• 3.3. Минимальные и рекомендуемые требования к аппаратному обеспечению серверов
• 3.4. Требования к рабочему месту конечного пользователя и каналам связи

4. Схема интеграции и программные интерфейсы  

• 4.1. Архитектурный стиль REST API и стандарты сериализации (JSON / XML)
• 4.2. Безопасность, аутентификация и авторизация межсистемных соединений (OAuth 2.0, JWT)
• 4.3. Направления синхронизации данных с ERP-системами на платформе «1С:Предприятие»
• • 4.3.1. Входящие потоки нормативно-справочной информации (НСИ)
  • 4.3.2. Исходящие потоки страховых и финансовых метрик

5. Безопасность и отказоустойчивость архитектуры

• 5.1. Резервное копирование и обеспечение целостности данных (Backup & Recovery)
• 5.2. Отказоустойчивость, высокая доступность и горизонтальное масштабирование (High Availability)
• • 5.2.1. Балансировка нагрузки прикладного уровня
  • 5.2.2. Отказоустойчивость и целостность данных уровня хранения
• 5.3. Сетевая безопасность, защита прикладного уровня (OWASP Top 10) и шифрование трафика (TLS)

6. Логическая структура данных и функциональные модули

• 6.1. Модуль электронных тендерных процедур  
• 6.2. Модуль учета и верификации объектов страхования  
• 6.3. Модуль администрирования договоров и полисов  
• 6.4. Модуль автоматизированного урегулирования убытков  
• 6.5. Аналитическое ядро и подсистема бизнес-анализа  

1. Архитектурный стиль и общие принципы

Программное обеспечение «Платформа управления корпоративным страхованием AIINS» (далее - Система) спроектировано и реализовано на базе трехзвенной клиент-серверной архитектуры. Архитектурный стек Системы предусматривает жесткое логическое и физическое разделение на три независимых функциональных слоя (уровня):

1. Уровень представления (клиентское веб-приложение / Front-end);
2. Уровень бизнес-логики (сервер приложений / Back-end);
3. Уровень хранения данных (система управления базами данных и объектное хранилище / Data Tier).

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

Принципы внутренней организации и межмодульного взаимодействия:

• Модульно-блочная структура: Внутренняя логика серверной части Системы построена по принципу модульного монолита с высокой степенью автономности бизнес-компонентов. Каждый функциональный модуль (включая модули «Тендеры», «Полисы», «Урегулирование убытков») инкапсулирует в себе собственную изолированную бизнес-логику и осуществляет доступ к слою СУБД через выделенные абстракции.
• Связность и взаимодействие компонентов: Межмодульное взаимодействие внутри серверной части Системы реализуется посредством строго типизированных внутренних программных интерфейсов и синхронных вызовов функций на уровне программного кода, что минимизирует сетевые задержки. Для обработки асинхронных процессов и распределенных задач применяется встроенная шина обмена сообщениями, функционирующая на базе брокера сообщений Apache Kafka (соединения защищены TLS). Магистральный межмодульный трафик внутри изолированного виртуального контура (сети) Системы подлежит обязательному логическому журналированию.
• Технологическая независимость: Архитектура Системы исключает использование проприетарных технологий, библиотек или платформенных зависимостей, контролируемых зарубежными вендорами. Все компоненты архитектуры адаптированы для нативного развертывания в изолированных программных средах на базе свободно распространяемого ПО (Open Source) и российских операционных систем, что гарантирует непрерывность функционирования Системы при любых внешних инфраструктурных ограничениях.

2. Уровни архитектуры и технологический стек 

Система построена исключительно на базе свободного программного обеспечения (Open Source) со свободными лицензиями (MIT, Apache 2.0, BSD, PostgreSQL License, GPL/AGPL) и проприетарных компонентов собственной разработки ООО «Адепт», что полностью исключает санкционные риски.

2.1. Уровень представления (Front-end)

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

• Среда выполнения: Любой современный веб-браузер с поддержкой стандартов HTML5/CSS3 (включая российские браузеры «Яндекс.Браузер»).
• Технологический стек: HTML5, CSS3, язык программирования JavaScript / TypeScript.
• Фреймворки: Angular и Angular Material (используются исключительно открытые библиотеки, развернутые локально внутри контура Системы; загрузка компонентов из зарубежных CDN-сетей заблокирована).

2.2. Уровень бизнес-логики (Back-end)

Уровень отвечает за выполнение основных вычислительных алгоритмов, обработку бизнес-правил страхования, управление сессиями, разграничение прав доступа и взаимодействие с СУБД и внешними ИТ-системами.

• Язык программирования: Java (версия 17 и выше).
• Базовый веб-фреймворк: Spring Boot (Spring MVC, Spring Security, Spring Data JPA; управление изменениями схемы БД — Flyway).
• Менеджер процессов и веб-сервер: Nginx (в качестве обратного прокси-сервера / Reverse Proxy) и встроенный сервер приложений Apache Tomcat в составе Spring Boot.
• Сервер очередей и фоновых задач: планировщик регламентных задач Spring Scheduler и брокер сообщений Apache Kafka (тяжелые фоновые задачи: генерация больших Excel-отчетов, пакетный импорт объектов, массовые email-рассылки); Redis используется как подсистема кэширования.

2.3. Уровень хранения данных 

Уровень обеспечивает надежное, транзакционное и безопасное хранение структурированных и неструктурированных данных Системы.

• Основная СУБД: Реляционная система управления базами данных PostgreSQL (версия 15 и выше). Обеспечивает поддержку ACID-транзакций при проведении тендеров и фиксации полисов.
• Хранилище неструктурированных данных (Файловый менеджер): Объектное хранилище, совместимое с протоколом S3 (объектное хранилище MinIO, размещенное в контуре Системы на территории Российской Федерации). Используется для безопасного хранения скан-копий документов, актов и фотографий убытков.

3. Среда функционирования и системные требования к инфраструктуре 

Система спроектирована как кроссплатформенное решение, контейнеризированное с помощью Docker. Она независима от аппаратного обеспечения серверной инфраструктуры и может быть развернута как по модели SaaS в сертифицированном ЦОД (класса Tier III в РФ), так и локально на серверах заказчика.

3.1. Поддерживаемые операционные системы (ОС сервера)

В рамках импортозамещения серверная часть Системы валидирована и полностью совместима со следующими операционными системами:

• Российские ОС: Astra Linux SE (модификация «Смоленск» / «Воронеж»), РЕД ОС, Alt Linux.
• Свободные ОС: Ubuntu Server / Debian / Rocky Linux.

3.2. Минимальные системные требования к серверу (для базового развертывания)

• Процессор: Архитектура x86-64, не менее 4 ядер (2.4 ГГц).
• Оперативная память: Не менее 16 ГБ.
• Дисковая подсистема: Не менее 100 ГБ свободного пространства на массиве SSD/NVMe (с поддержкой RAID для отказоустойчивости).
• Сетевой интерфейс: Пропускная способность от 100 Мбит/с.

4. Схема интеграции и программные интерфейсы  

Для сопряжения с внешними информационными системами и интеграции в существующий ИТ-контур предприятий (включая корпоративные ERP-системы и конфигурации на платформе «1С:Предприятие») Программное обеспечение предоставляет открытый программный интерфейс REST API (Representational State Transfer Application Programming Interface). Межсистемное взаимодействие строится на принципах архитектурного стиля REST и обеспечивает бесшовный обмен данными в гетерогенных информационных средах.

4.1. Технические регламенты и стандарты обмена данными

• Форматы сериализации данных: Сетевой обмен и передача метаданных между Системой и интегрируемыми информационными системами осуществляются с использованием стандартизированного текстового формата JSON (JavaScript Object Notation).
• Безопасность и валидация API-соединений: Защита транспортного уровня и верификация сетевых запросов реализованы на базе комплексного стека протоколов безопасности:
• • Шифрование трафика: Принудительное использование протоколов криптографической защиты TLS версии 1.2 и выше.
  • Протокол авторизации: Делегирование доступа на основе открытого стандарта OAuth 2.0.
  • Аутентификация запросов: Проверка подлинности сессий с помощью криптографически подписанных токенов JWT (JSON Web Token), передаваемых в заголовках HTTP-запросов (Authorization: Bearer).
  • Машинная авторизация интеграционных вызовов: доступ к служебным конечным точкам (endpoints) API защищается предразделяемым секретным ключом, передаваемым в служебном HTTP-заголовке; дополнительно применяется ограничение частоты запросов (rate limiting) по IP-адресу источника.

4.2. Архитектура и направления интеграции с платформой «1С:Предприятие»

Интеграция реализована через фирменное расширение конфигураций на платформе «1С:Предприятие» (включая «1С:Зарплата и управление персоналом КОРП») и открытый REST API Системы. Поддерживаются следующие сценарии:

1. Получение из 1С перечня тендерных процедур организации по идентификатору налогоплательщика (ИНН) — витрина тендеров в интерфейсе 1С;

• Сквозной переход (бесшовный вход) из интерфейса 1С в Личный кабинет Системы по защищенной ссылке;
• Автоматизированная регистрация организации (онбординг) и привязка учетных записей 1С к учетным записям Системы.
• Пакетная загрузка реестров объектов страхования (транспортные средства, спецтехника, недвижимое имущество, персонал) выполняется через веб-интерфейс Системы из файлов формата XLSX по готовым шаблонам.

2. Выгрузка данных из Системы:

1. Реестры (бордеро), графики платежей и статистика урегулированных убытков выгружаются в машиночитаемых форматах XLSX/CSV, пригодных для загрузки в финансовый и бухгалтерский контуры внешних учетных систем (включая конфигурации «1С:Предприятие»).

5. Безопасность и отказоустойчивость архитектуры

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

5.1. Резервное копирование и обеспечение целостности данных 

Архитектура Системы включает автоматизированную подсистему создания резервных копий, функционирующую по расписанию без прерывания доступности сервисов для конечных пользователей:

• Резервное копирование СУБД: Программные скрипты автоматизации обеспечивают ежесуточное создание полных логических и физических дампов (копий) реляционной базы данных.
• Резервное копирование объектного хранилища: Для неструктурированных данных (электронных копий документов, актов, медиафайлов в S3-хранилище) применяется алгоритм непрерывного инкрементального копирования (синхронизации изменений).
• Изоляция и криптографическая защита: Все сформированные файлы резервных копий в автоматическом режиме шифруются с применением средств криптографической защиты (GPG) и архивируются. Хранение бэкапов осуществляется на выделенном, логически и физически изолированном сервере хранения в пределах защищенного периметра ЦОД. Регламентный срок хранения архивов определяется политикой безопасности эксплуатирующей организации.

5.2. Отказоустойчивость и высокая доступность 

Вычислительный контур Системы спроектирован с исключением единых точек отказа (SPOF) и рассчитан на динамическое масштабирование при пиковых нагрузках:

• Балансировка прикладного уровня: Распределение входящего пользовательского и интеграционного трафика (HTTP/HTTPS) между узлами (нодами) сервера приложений (Back-end) осуществляется прокси-сервером Nginx с непрерывным мониторингом доступности целевых сервисов.
• Отказоустойчивость уровня хранения: СУБД PostgreSQL функционирует в выделенном изолированном контуре; сохранность данных обеспечивается транзакционным режимом обработки (ACID) и регулярным автоматическим резервным копированием с контролем восстановимости. Архитектура Системы предусматривает переход на схему потоковой репликации Primary-Replica при росте нагрузки.

5.3. Сетевая безопасность и защита прикладного уровня

Защита информационного периметра Системы от несанкционированного доступа и деструктивных воздействий реализуется комплексными мерами:

• Предотвращение уязвимостей: На уровне программного кода и используемых веб-фреймворков внедрены встроенные механизмы валидации, экранирования параметров и фильтрации входящих запросов. Это обеспечивает нативную защиту от критических веб-атак из списка OWASP Top 10, включая SQL-инъекции (SQLi), межсайтовый скриптинг (XSS) и подделку межсайтовых запросов (CSRF).
• Межсетевое экранирование: На входе в сетевой периметр применяются средства сетевой защиты: ограничение частоты запросов (rate limiting), автоматическая блокировка источников подозрительной активности и фильтрация служебных путей на уровне прокси-сервера Nginx.
• Криптографическая защита каналов связи: Передача любого трафика между клиентом и сервером принудительно инкапсулируется в защищенный протокол HTTPS с использованием криптографических стандартов TLS 1.2 и TLS 1.3. Безопасность соединений обеспечивается установкой доверенных цифровых сертификатов общепризнанных удостоверяющих центров, поддерживаемых всеми современными веб-браузерами, включая отечественные.

6. Логическая структура данных и функциональные модули

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

6.1. Модуль электронных тендерных процедур 

Модуль предназначен для алгоритмической организации, проведения и анализа результатов конкурентных закупных процедур на корпоративное страхование.

• Логическая структура данных: Оперирует сущностями Tender (Запрос котировок/Тендер), TenderSpecification (Техническое задание/Спецификация рисков) и TenderOffer (Коммерческое предложение/Оферта страховщика). Сущность Tender имеет связи типа «один ко многим» (1:M) к сущностям спецификаций и поступивших оферт.
• Системные функции и алгоритмы:
• • Генерация уникального ID процедуры, фиксация временных меток (timestamps) начала и окончания приема котировок.
  • Автоматическая валидация типов данных при вводе тарифов страховщиками в личном кабинете.
  • Математический алгоритм параметрического сопоставления: модуль производит декомпозицию TenderOffer по заданным векторам (размер премии, франшиза, лимиты ответственности) и осуществляет ранжирование строк по правилам многокритериального выбора, исключая необходимость использования внешних табличных процессоров.

6.2. Модуль учета и верификации объектов страхования

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

• Логическая структура данных: Базируется на сущности InsuredAsset (Объект страхования), которая содержит полиморфные наборы атрибутов в зависимости от категории актива (транспорт, спецтехника, недвижимость, персонал). Сущность InsuredAsset связана отношением «многие ко многим» (M:N) с сущностью страховых полисов через промежуточную таблицу связей.
• Системные функции и алгоритмы:
• • Пакетная обработка и валидация входящих массивов данных (через REST API или файлы обмена) с проверкой уникальности идентификаторов (VIN, кадастровые номера, СНИЛС).
  • Алгоритм кросс-верификации покрытия: фоновый планировщик задач производит логическое сопоставление временных интервалов действия полисов с метаданными объекта. При обнаружении разрывов в хронологии защиты объект динамически помечается флагом is_uninsured = True, что инициирует триггер вывода предупреждения в графический интерфейс.

6.3. Модуль администрирования договоров и полисов 

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

• Логическая структура данных: Ключевой сущностью является Страховой полис/Договор, содержащий метаданные о страховщике, страхователе, периоде ответственности и общей страховой сумме. Связан отношением (1:M) с сущностью График платежей и сущностью Дополнительные соглашения.
• Системные функции и алгоритмы:
• • Автоматический парсинг дат и расчет временных интервалов до наступления дедлайнов.
  • Триггерная система уведомлений: компонент осуществляет предиктивный анализ поля end_date и при приближении контрольной точки (30 календарных дней) генерирует системное событие пролонгации.
  • Финансовый контроль: алгоритм сопоставляет текущую системную дату с плановыми траншами в PaymentSchedule, вычисляя остаток дней до оплаты и отправляя управляющие сигналы в модуль уведомлений для предотвращения дефолта по полису.

6.4. Модуль автоматизированного урегулирования убытков 

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

• Логическая структура данных: Основная сущность — InsuranceClaim (Заявка об убытке), которая жестко линкуется на уровне базы данных с конкретным InsurancePolicy (ID договора) и InsuredAsset (ID пострадавшего объекта) с помощью внешних ключей. Имеет связь (1:M) с сущностью ClaimDocument (Электронный архив документов по убытку).
• Системные функции и алгоритмы:
• • Управление состояниями (State Machine): переход заявки по технологической цепочке статусов («Зарегистрировано» -> «В работе» -> «Урегулировано» / «Отказ») выполняется как изолированная транзакция. Любое изменение статуса сопровождается автоматической записью в системный неизменяемый лог аудита (ClaimAuditLog).
  • Безопасная обработка бинарных данных (файлов): прикладные скрипты модуля осуществляют очистку метаданных загружаемых фото-, видеоматериалов и документов, проверяют их соответствие разрешенным MIME-типам и организуют структурированное хранение в объектном S3-архиве с привязкой к ID убытка.

6.5. Аналитическое ядро и подсистема бизнес-анализа 

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

• Логическая структура данных: Функционирует на базе специализированных агрегированных представлений в СУБД, которые оптимизированы для чтения и изолированы от транзакционной нагрузки основных модулей Системы, что предотвращает снижение производительности GUI при построении тяжелых отчетов.
• Системные функции и алгоритмы:
• • Алгоритмы группировки и консолидации: модуль производит автоматическую сборку финансовых потоков в разрезе иерархической структуры холдинга (сущность CompanyBranch), вычисляя совокупные затраты на страхование по дочерним обществам.
  • Генератор бордеро: компонент выполняет динамические SQL-запросы для выгрузки структурированных реестров в утвержденных форматах (XLSX, CSV) для интеграции с внешним бухгалтерским контуром («1С»).
  • Расчет метрик эффективности: математическое ядро производит компаративный анализ начальных ценовых предложений и финальных тарифов, зафиксированных в TenderEngine, вычисляя экономический эффект (процент снижения затрат от 15% до 40%) по формулам взвешенного среднего.