Внутренний API защищён взаимным TLS, но любой клиент с доверенным сертификатом может вызвать операцию удаления. Какой вывод о роли TLS следует сделать?
Взаимный TLS аутентифицирует сервис, но сам по себе не авторизует операцию. Он подтверждает, что соединение установлено с клиентом, владеющим закрытым ключом сертификата из доверенной инфраструктуры. Право на удаление нужно проверять отдельной политикой доступа, связанной с подтверждённой идентичностью клиента.
Обычный TLS первоначально решал прежде всего задачу защиты канала и аутентификации сервера: клиент мог убедиться, что подключился к нужному узлу, а данные нельзя прочитать или незаметно изменить в пути. Для межсервисного взаимодействия этого недостаточно, поскольку серверу также требуется проверять вызывающую сторону.
Взаимный TLS, или mTLS, добавляет аутентификацию клиента с помощью сертификата. Подход особенно полезен там, где сервисы взаимодействуют без пользовательской сессии и должны подтверждать свою машинную идентичность.
Доверенный сертификат доказывает принадлежность клиента к определённой идентичности, но не означает, что клиенту разрешены все действия API. Если сервер принимает сам факт успешного TLS-сеанса за разрешение операции, компрометация одного сервиса превращается в возможность выполнять привилегированные действия от его имени.
Дополнительный риск возникает при слишком широком доверии к центру сертификации. Любой клиент, которому выдан сертификат этим центром, может пройти транспортную аутентификацию, хотя его полномочия должны быть ограничены конкретными ресурсами и операциями.
При установлении mTLS сервер проверяет цепочку сертификата клиента, срок действия, назначение сертификата, соответствие имени ожидаемой идентичности и подтверждение владения закрытым ключом. Последний шаг важен: одного перехваченного сертификата недостаточно без соответствующего закрытого ключа.
После этого сервер должен извлечь нормализованную идентичность клиента из проверенного сертификата, например имя workload или URI в поле Subject Alternative Name, и передать её в авторизационную политику. Политика отдельно решает, может ли данный сервис выполнять конкретное действие над конкретным ресурсом.
Нужно разделять два решения:
mTLS также не подтверждает конечного пользователя, от имени которого действует сервис. Если операция требует пользовательского контекста, его следует передавать через отдельный защищённый механизм делегирования идентичности, не подменяя его сертификатом сервиса.
Критичны управление жизненным циклом сертификатов, отзыв или короткий срок их действия, защита закрытых ключей, ограничение доверенных центров сертификации, аудит выдачи сертификатов и явное сопоставление идентичностей с политиками. Проверка только факта наличия сертификата создаёт чрезмерно широкую границу доверия.
Платёжный сервис принимает запросы от сервисов заказов, поддержки и аналитики. Все они используют mTLS, однако только сервис заказов должен создавать платёж, а поддержка может лишь инициировать возврат по ограниченному набору условий.
Вариант с единым правилом разрешить все операции любому клиенту с сертификатом прост в эксплуатации, но нарушает принцип наименьших привилегий. Вариант с отдельными сертификатами для каждой операции точнее, однако усложняет выпуск, ротацию и отзыв сертификатов.
Выбранное решение использует сертификат для аутентификации сервиса, а централизованную политику — для проверки операции, ресурса и контекста запроса. В результате компрометация сервиса аналитики не даёт ему права создавать платежи, а смена полномочий выполняется изменением политики без перевыпуска всех сертификатов.
Вопрос: Может ли mTLS защитить от вызова операции скомпрометированным доверенным сервисом?
Ответ: Нет. Если злоумышленник получил контроль над сервисом или его закрытым ключом, он может пройти транспортную аутентификацию как легитимный клиент. mTLS снижает риск подмены сервиса на сетевой границе, но не ограничивает автоматически действия уже скомпрометированной идентичности. Для снижения ущерба нужны наименьшие привилегии, изоляция ключей, короткоживущие сертификаты, аудит и отдельная авторизация.
Вопрос: Почему недостаточно проверять только издателя сертификата клиента?
Ответ: Доверенный издатель может выпускать сертификаты множеству сервисов с разными полномочиями. Проверка только цепочки доверия подтверждает принадлежность сертификата инфраструктуре, но не определяет конкретную идентичность и её права. Сервер должен проверять назначение сертификата, ожидаемое имя клиента и затем применять политику доступа к извлечённой идентичности.
Вопрос: Что произойдёт, если сертификат сервиса аутентифицируется корректно, но его полномочия отозваны?
Ответ: При проверке только TLS соединение может продолжить считаться допустимым, хотя бизнес-доступ уже запрещён. Поэтому отзыв полномочий должен учитываться в авторизационной политике, а не только в инфраструктуре сертификатов. Кэш решений авторизации должен иметь контролируемый срок действия или механизм немедленной инвалидизации, иначе после отзыва сервис ещё некоторое время сохранит доступ.