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