Аудирование в микросервисной архитектуре

Пролог

Этот пост продолжает тему проблем^ возникающих при применении архитектурных паттернов начатую в статье https://habr.com/ru/post/707582/

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

НФТ, которые в терминах микросервисной архитектуре называется Observability and Monitoring реализуются сервисами  Журналирование, Аудит и Мониторинг. Журналирование и Мониторинг не являются темой этой статьи, темой является Аудит.

Delloitte дает следующее определение IT Аудита: «Независимая, объективная деятельность по предоставлению гарантий и консультированию для повышения ценности и улучшения деятельности организации.  Цель этой деятельности — улучшить эффективность процессов контроля деятельности и управления рисками».

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

Наша команда занимается миграцией Legacy монолитного вендорского приложения на целевую микросервисную архитектуру. 

Как было

Как выглядит процесс аудирования в монолитном приложении: 

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

Реализация журналов Аудита заключается в написании SQL запросов к БД и защите таких представлений через встроенную ролевую модель.

Все довольны: бизнес, разработчики, безопасность и сопровождение.

Как стало

В микросервисной архитектуре активно используются паттерны:

• слоеная архитектура, об этом упоминается в моей статье на Хабре.

• Одна БД на сервис — database-per-service

• архитектура микросервисов microservices

• декомпозиция по поддоменам decompose-by-subdomain

Как они влияют на Журнал Аудита:

• на каждом слое реализуется свое приложение и своя модель данных

• дробление модели данных на поддомены согласно SOLID

•  дробление операции на шаги саги saga

Требования к регистрации событий событий Аудита

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

• Событие должно содержать не ключи, а значения ключей сущностей, не идентификатор клиента, но его ФИО

• Событие, если оно регистрирует изменение должно содержать два значения на каждый атрибут: было и стало

• События должны фиксироваться в каждой автоматизированной системе

Следствия

• С учетом деления системы на слои сервисов, каждая команда разрабатывая сервиса на своем слое должна записывать событие в журнал Аудита.В результате при чтении в журнал Аудита запишут события: Приложение PL слоя, Приложение слоя Бизнес-Логики, Приложение слоя Доступа к данным

• С учетом декомпозиции приложения на поддомены, и принципу DDD для поддержки требования полноты атрибутивного события,микросервису не хватает атрибутного состава сущностей для выполнения требования по регистрации значений ключей

• С учетом паттерна саги каждый из микросервисов — участников саги запишет свою часть распределенной транзакции в Журнал Аудита

Исполнения требований в лоб

• В Журнале Аудита одна бизнес операция будет представлена записями как минимум 3-х приложений с каждого слоя

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

• Если событие является распределенной транзакцией каждый участник саги добавит запись в журнал Аудита

• Потребуются дополнительные ресурсы для соблюдения SLA участвующих сервисов c учетом выполнения требования полноты.

Эпилог

Цель данного поста не публикация готового решения, а скорее рассуждения на тему проблем которые приносят архитектурные паттерны в устоявшиеся порядки и регламенты.

В то время как приложения пытаются декомпозировать, разбить на домены и поддомены, сделать слабосвязанными и автономными Принцип Наблюдаемости ведет потоки событий, порождаемых в декомпозированных сервисах обратно к композиции.

Требования, предъявляемые к системе Аудита возвращают микросервисную архитектуру обратно к монолитной.