Аудит прав доступа в микрофронтендах: как не утонуть в цифровом бардаке

Вы запустили систему на микрофронтендах. Команды работают быстрее, релизы идут независимо. Но спустя полгода вы ловите себя на мысли: кто и к чему имеет доступ сейчас? Старый модуль, который написал уволившийся разработчик, все еще имеет доступ к API личного кабинета. Компонент из одного приложения может менять глобальное состояние другого. Проблема не в архитектуре, а в управлении правами. Если вы не можете за час получить полную матрицу “кто что может”, у вас уже есть уязвимость. В этой статье я покажу вам не теорию, а конкретную методику аудита прав доступа в микрофронтендах. Вы получите пошаговый план для проверки и четкую схему, как навести порядок, не замедляя разработку.

Содержание

Почему управление доступом в микрофронтендах сложнее, чем вы думаете

В монолите права доступа часто централизованы. Один роутер, один стор, один механизм проверки ролей. В мире микрофронтендов каждый модуль — это потенциально независимое приложение со своей логикой рендеринга, своим состоянием и своими вызовами API. Сложность растет нелинейно. Вы имеете дело не с одной системой прав, а с десятком, которые должны работать согласованно. Здесь кроется главный риск: распыленная ответственность. Когда каждая команда реализует защиту по-своему, в системе неизбежно появляются щели. Устаревшие токены, хардкодные проверки, отсутствие единого источника истины для ролей пользователя — все это накапливается как технический долг, который однажды обернется инцидентом.

Собираем пазл: что именно нужно аудировать

Аудит — это не просто проверка кода. Это системный взгляд на все уровни взаимодействия. Сфокусируйтесь на четырех ключевых областях.

Уровень изоляции и рендеринга

Как микрофронтенды загружаются и кто решает, какой из них показать пользователю? Проверьте:

Манифесты и конфигурации загрузки: Кто может изменить список разрешенных хостов или версий в вашем Module Federation Webpack или в системе доставки (например, single-spa parcels)?
Логику роутинга: Проверяются ли права на уровне shell-приложения перед загрузкой бандла микрофронтенда? Или проверка происходит уже внутри него, когда код уже исполняется у клиента?
Shadow DOM и CSS-инкапсуляцию: Может ли один микрофронтенд случайно или намеренно изменить DOM-элемент критического компонента другого?

Уровень данных и состояния

Это самая опасная зона. Аудит должен ответить на вопрос: могут ли микрофронтенды читать или изменять данные, к которым у них нет прав.

Общее состояние (например, в Redux или Pinia): Какие модули имеют доступ к какому разделу стора? Используются ли четкие пространства имен (namespaces) для каждого микрофронта?
Работа с API: Где хранятся и как обновляются токены доступа? Может ли модуль “Б” делать запросы от имени модуля “А”? Проверьте CORS-политики на бэкенде — они ваша последняя линия обороны.
Локальное хранилище (LocalStorage, SessionStorage): Не используют ли разные команды один и тот же ключ для хранения критичных данных, перезаписывая друг друга?

Note: Самый разрушительный паттерн — это когда права проверяются только на UI-уровне. Например, кнопка скрыта, но вызов API, который она инициировала, все еще доступен и может быть выполнен через инструменты разработчика. Права должны дублироваться на бэкенде для каждого endpoint.

Уровень коммуникации между микрофронтендами

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

Глобальная шина событий (window.addEventListener). Кто какие события публикует и кто на них подписан?
Пользовательские события (CustomEvent). Как именуются их типы? Есть ли реестр, чтобы избежать коллизий?
Прямой вызов методов через window.*. Этот подход должен быть исключением и строго документирован.

Пошаговый план проведения аудита

Не пытайтесь охватить все сразу. Двигайтесь системно, от высокоуровневой карты до глубокого анализа кода.

Шаг 1. Составление карты зависимостей. Создайте диаграмму всех микрофронтендов. Для каждого запишите: ответственная команда, точка входа (URL, бандл), от кого он принимает данные (родитель, стор, события), кому передает данные, какие бэкенд-сервисы вызывает.

Шаг 2. Ревизия механизмов авторизации. Проверьте, как в каждый микрофронтенд попадает информация о роли и правах пользователя. Есть ли единый сервис-провайдер или каждый запрашивает сам? Это критически важный момент.

Шаг 3. Анализ кода ключевых модулей. Выберите два-три модуля с наиболее чувствительными данными (например, платежи, персональные настройки). Проведите ручной код-ревью, сосредоточившись на:

Прямым вызовам protected API.
Обработке глобальных событий.
Манипуляциям с общим состоянием.

Шаг 4. Моделирование угроз (Threat Modeling). Соберите архитектора и тимлидов. Задайте сценарии: “Что, если злонамеренный код попадет в микрофронтенд Х благодаря уязвимости в цепочке поставок (supply chain attack)?” “Может ли он из данных модуля “А” скомпрометировать модуль “Б”?” Ответы дадут вам roadmap для улучшений.

Разбор реального кейса: утечка данных через общее хранилище

Рассмотрим распространенную ситуацию. У вас есть микрофронтенд “Личный кабинет” (MFE_A) и “Админ-панель” (MFE_B). Оба используют общий модуль состояния (скажем, Vuex) для хранения токена доступа. Разработчик MFE_A для удобства сохраняет объект с полным профилем пользователя (включая sensitive data) в раздел стора под названием “user”. Разработчик MFE_B, не глядя в документации (которой нет), предполагает, что в “user” лежит только имя для приветствия, и выводит это значение в интерфейс. Позже в MFE_B добавляется функционал отправки диагностических логов, куда для отладки пакуется все содержимое “user”. Внезапно sensitive data из личного кабинета начинает утекать во внешнюю систему, доступную админам. Аудит, проведенный по нашему плану, выявил бы эту проблему на шаге 1 (карта зависимостей показала бы общий стор) и шаге 3 (код MFE_B содержал бы логирование стейта). Решение: строгий контракт для общего состояния, где каждый микрофронтенд имеет свой изолированный namespace, и централизованный сервис для работы с пользовательскими данными.

Ошибка новичков и как ее исправить

Самая частая и опасная ошибка: дублирование логики проверки прав внутри каждого микрофронтенда. Команда копирует функцию `checkPermission(role)` из соседнего репозитория, немного меняет ее под свои нужды и забывает обновить, когда на бэкенде меняется модель ролей. Через год у вас 8 разных реализаций одной проверки, 3 из которых устарели.

Исправление: Вынесите саму логику проверки прав в отдельный versioned package (npm-пакет) или в единый backend BFF-слой (Backend for Frontend). Микрофронтенды должны лишь запрашивать у этого сервиса: “Может ли пользователь с таким токеном выполнить действие Х?” и получать простой ответ `true/false`. Сам пакет или BFF обновляется централизованно, и все приложения мгновенно получают актуальные правила. Это превращает права из бизнес-логики в инфраструктурный сервис.

Вопросы и ответы по теме аудита

Вопрос: Как часто нужно проводить такой аудит в условиях быстрого развития продукта?

Ответ: Полный, глубокий аудит — раз в полгода. Однако вы должны автоматизировать его базовую часть. Внедрите статический анализ кода (ESLint с кастомными правилами), который будет отлавливать прямые вызовы protected API без использования обертки-сервиса и использование неразрешенных глобальных событий. Интегрируйте эту проверку в CI/CD pipeline. Так вы получите непрерывный профилактический контроль и сможете сосредоточиться на стратегических рисках во время ручного аудита.

Что делать прямо сейчас

Не откладывайте. Начните с малого, но начните сегодня. Выделите два часа в конце недели. Возьмите самый “старый” или самый критичный с точки зрения данных микрофронтенд в вашей системе. Пройдитесь по нему, отвечая на три вопроса из нашего плана: 1) Какие бэкенд-сервисы он вызывает и где проверяются права на эти вызовы? 2) Какие данные из глобального состояния он читает и меняет? 3) На какие глобальные события он подписан? Зафиксируйте ответы. Скорее всего, вы уже найдете одну-две точки для немедленного улучшения. Затем покажите эту выжимку архитектору и договоритесь о следующем шаге — составлении общей карты зависимостей. Системный подход к правам доступа не роскошь, а обязательное условие для безопасного масштабирования микрофронтендов. Начните с одного модуля, и процесс запустится.