Проблема:
В монолите один скомпрометированный компонент (RCE/SQLi/LFI) даёт доступ ко всем данным и функциям. Эксплуатация одной уязвимости — компрометация всего сервиса.

Причины:
1. Общее адресное пространство — злоумышленник, получив shell на одном поде/контейнере, видит все процессы и память соседних модулей (если нет изоляции cgroups/namespaces).
2. Единая БД — инъекция в модуль каталога (например, `1' OR '1'='1`) позволяет читать таблицы аутентификации и платёжных данных.
3. Единый API-ключ/токен — утечка одного ключа (через SSRF, debug-лог) даёт доступ ко всем эндпоинтам.

Решение:
Микросервисы с жёсткой изоляцией:
- Разные БД под каждый сервис (database-per-service). Каждый сервис хранит только свои таблицы и соединяется с ними через отдельного пользователя с минимальными привилегиями (GRANT SELECT, INSERT ON schema.table TO user_service).
- Сетевые политики (Kubernetes NetworkPolicy / iptables / AWS Security Group): запретить прямой трафик между сервисами без API-шлюза; только HTTPS через service mesh (istio/linkerd) с mTLS.
- Разные токены доступа (JWT с разными aud/scope claims). Пример: сервис A получает токен только для `GET /api/v1/orders`, сервис B — только для `POST /api/v1/payments`.
- Изоляция на уровне ОС — запуск каждого сервиса в отдельном контейнере (user namespace: `--userns=host:1000:1000`) или VM (Firecracker/Kata Containers).

Пример сетевой политики (K8s):
yaml
apiVersion: networking.k8s.io/v1

kind: NetworkPolicy

metadata:

  name: deny-all-except-gateway

spec:

  podSelector: {}

  policyTypes:

  - Ingress

  ingress:

  - from:

    - podSelector:

        matchLabels:

          app: api-gateway

    ports:

    - protocol: TCP

      port: 8443


Итог: Микросервисы не «лучше» — они снижают радиус взрыва (blast radius). Один сломанный сервис не даёт доступа к остальным. Без них вы получаете одну точку отказа для атаки.