Лабораторная работа V. Анализ архитектуры и безопасности толстого клиента при микросервисной архитектуре

Лабораторная работа V. Анализ архитектуры и безопасности толстого клиента при микросервисной архитектуре

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

Порядок выполнения работы

Задание 1. Архитектурный аудит и оптимизация («утолщение») клиента . Для разработанного в предыдущей лабораторной работе «толстого» клиента необходимо провести ревизию архитектуры и выполнить одно из следующих действий:

• Либо аргументированно обосновать, почему текущая реализация является достаточной для классификации клиента как «толстого».

• Либо выполнить доработку («утолщение»): добавить в локальную базу данных клиента достаточное количество таблиц (сущностей), аналогичных таблицам бэкенда. Доработка должна обеспечивать существенное и обоснованное снижение нагрузки на серверную базу данных.

Задание 2. Анализ распределения нагрузки на уровне БД. Провести сопоставительный анализ SQL-запросов локальной БД клиента и серверной БД бэкенда. Необходимо явно сопоставить и указать, выполнение каких именно локальных SQL-запросов освобождает бэкенд от необходимости выполнения аналогичных или ресурсоемких серверных запросов.

Задание 3. Анализ защищенности и проектирование безопасной схемы данных. Обосновать принципы именования и структуру таблиц локальной БД клиента с точки зрения информационной безопасности. В отчете необходимо ответить на следующие вопросы:

• Целесообразно ли сохранять идентичность названий таблиц и полей локальной БД по отношению к БД бэкенда? Если требуется переименование (обфускация), то по каким правилам его проводить?

• Стоит ли изменять структуру и связи локальных таблиц относительно серверных?

• Какие существуют подходы к проектированию локальных схем данных в толстых клиентах, каковы их плюсы и минусы?

• Какое архитектурное решение оптимально применить в вашей проектируемой системе?

• . Проанализировать и задокументировать новые проблемы безопасности, возникающие при внедрении толстого клиента. 

• Оценить риски: может ли злоумышленник, проведя анализ (реверс-инжиниринг, дамп) локальной базы данных клиента, извлечь избыточную информацию о структуре серверной базы данных или алгоритмах работы бэкенда? 

• Предложить способы защиты системы от данных угроз. 

• Разработать и привести диаграммы (например, UML-диаграммы последовательности или графы атак на plantUML или Mermaid) возможных векторов атак на информационную систему с толстым клиентом, а также графически отобразить применяемые способы защиты.

Задание 4. Проектирование спецификации API-взаимодействия. Спроектировать список API-методов для взаимодействия клиентского приложения (фронтенда) с бэкендом для двух архитектурных вариантов:

• А) Для системы на базе «тонкого» клиента (основная логика и хранение данных сосредоточены на сервере).

• Б) Аналогичный список API-методов для работы с «толстым» клиентом. 

• В) Привести сравнительный анализ API: составить отдельный перечень API-запросов к бэкенду, от выполнения которых удалось отказаться в архитектуре с «толстым» клиентом благодаря использованию локальной базы данных и переносу части бизнес-логики на сторону пользователя.

Задание 5. Проанализировать и отобразить на диаграммах  (на plantUML, Mermaid или других подобных) , как микросервисная архитектура дает дополнительную защиту от атак за счет дополнительной изоляции локальных баз данных микросервисов в отличии от монолита, где база данных одна на всю систему.