Пролог
Этот пост продолжает тему проблем возникающих при применении архитектурных паттернов начатую в статье Моделирование данных в слоеной архитектуре.
В Enterprise архитектуре следует серьезно относиться к требованиям информационной безопасности. В данной статье хотелось бы поднять проблемы возникающие вследствие реализации нефункциональных требований по фиксации событий, классифицированных как заслуживающие того, чтобы быть зафиксированными в специальном журнале.
НФТ, которые в терминах микросервисной архитектуре называется Observability and Monitoring реализуются сервисами Журналирование, Аудит и Мониторинг. Журналирование и Мониторинг не являются темой этой статьи, темой является Аудит.
ГОСТ Р ИСО/МЭК ТО 18044-2007 дает следующее определение события информационной безопасности, которые должны попадать в журнал Аудита: «Идентифицированное появление определенного состояния системы, сервиса или сети, указывающего на возможное нарушение политики ИБ или отказ защитных мер, или возникновение неизвестной ранее ситуации, которая может иметь отношение к безопасности».
На практике это сводится к тому, что надо классифицировать события несущие риск и записать их в журнал. Анализ на регулярной основе этого журнала и поиск по нему в случае инцидента и является тем самым улучшением эффективности.
Наша команда занимается миграцией Legacy монолитного вендорского приложения на целевую микросервисную архитектуру.
Как было
Как выглядит процесс аудирования в монолитном приложении:
У разработки всегда есть полная база данных с полным набором сущностей и исчерпывающим атрибутивным набором у этих сущностей.
Реализация журналов Аудита заключается в написании SQL запросов к БД и защите таких представлений через встроенную ролевую модель.
Все довольны: бизнес, разработчики, безопасность и сопровождение.
Как стало
В микросервисной архитектуре активно используются паттерны:
слоеная архитектура, об этом упоминается в моей статье на Хабре;
Одна БД на сервис — database‑per‑service;
архитектура микросервисов microservices;
декомпозиция по поддоменам decompose‑by‑subdomain.
Как они влияют на Журнал Аудита:
на каждом слое реализуется свое приложение и своя модель данных;
дробление модели данных на поддомены согласно SOLID;
дробление операции на шаги саги saga.
Требования к регистрации событий событий Аудита
Событие должно быть читаемым на русском языке, без использования языковых конструкций языков программирования и наименований объектов атрибутов и сущностей физической модели данных;
Событие должно содержать не ключи, а значения ключей сущностей, не идентификатор клиента, но его ФИО;
Событие, если оно регистрирует изменение должно содержать два значения на каждый атрибут: было и стало;
События должны фиксироваться в каждой автоматизированной системе.
Следствия
С учетом деления системы на слои сервисов, каждая команда разрабатывая сервиса на своем слое должна записывать событие в журнал Аудита.В результате при чтении в журнал Аудита запишут события: Приложение PL слоя, Приложение слоя Бизнес‑Логики, Приложение слоя Доступа к данным.
С учетом декомпозиции приложения на поддомены, и принципу DDD для поддержки требования полноты атрибутивного события,микросервису не хватает атрибутного состава сущностей для выполнения требования по регистрации значений ключей.
С учетом паттерна саги каждый из микросервисов — участников саги запишет свою часть распределенной транзакции в Журнал Аудита.
Исполнения требований в лоб
В Журнале Аудита одна бизнес операция будет представлена записями как минимум 3-х приложений с каждого слоя.
Реализация модели данных события будет зависеть от команды ответственной за слой и может расходится по неймингу атрибутов, а в каких‑то случаях и по значению.
Если событие является распределенной транзакцией каждый участник саги добавит запись в журнал Аудита.
Потребуются дополнительные ресурсы для соблюдения SLA участвующих сервисов c учетом выполнения требования полноты.
Эпилог
Цель данного поста не публикация готового решения, а скорее рассуждения на тему проблем которые приносят архитектурные паттерны в устоявшиеся порядки и регламенты.
В то время как приложения пытаются декомпозировать, разбить на домены и поддомены, сделать слабосвязанными и автономными Принцип Наблюдаемости ведет потоки событий, порождаемых в декомпозированных сервисах обратно к композиции.
Требования, предъявляемые к системе Аудита возвращают микросервисную архитектуру обратно к монолитной.
