Сервис расчёта премий принимает данные от кадровой системы. До сих пор ему было достаточно запроса из внутренней сети. Теперь к той же сети подключили тестовые приложения и подрядчика. Адрес отправителя уже плохо объясняет, кто именно прислал сведения и следует ли их принимать.
mTLS позволяет проверять обе стороны соединения с помощью сертификатов. В нашем примере расчётный сервис должен узнавать кадровую систему, а кадровая система — настоящий сервис расчёта. Но между этим узнаванием и разрешением начислить деньги остаётся важная граница. Её нельзя оставлять на усмотрение сетевой настройки.
Сертификат предъявляют, владение ключом доказывают
При обычном HTTPS клиент проверяет сервер. В варианте с взаимной аутентификацией сервер проверяет и клиента. Сертификат связывает открытый ключ с идентичностью, а участник соединения доказывает владение соответствующим закрытым ключом. Просто скопировать чужой публичный сертификат для этого недостаточно. Такая проверка описана в TLS 1.3.
Защищённое соединение уже создаёт TLS. Дополнительный сертификат клиента нужен прежде всего для взаимной проверки, а не для «двойного шифрования». При этом сервер должен действительно требовать аутентифицированного клиента: наличие установленного сертификата само по себе не доказывает, что обращения без него отклоняются.
Действующий сертификат ещё не означает нужного отправителя
Проверяется не только срок действия. Нужны доверенный источник сертификата, допустимое назначение и соответствие ожидаемой стороне. Сертификат другого приложения, выпущенный тем же центром, не должен автоматически давать ему полномочия кадровой системы.
Идентичность сервиса стоит определить независимо от текущей машины. Экземпляры заменяются, а обязанность приложения остаётся прежней. Например, в SPIFFE X.509-SVID предусмотрен идентификатор в поле URI SAN сертификата. Это один способ выразить идентичность, а не требование внедрить SPIFFE ради любой пары сервисов.
Отдельный вопрос — кто вообще может получить такое удостоверение. Если тестовый процесс способен запросить идентичность рабочей кадровой системы, дальнейшая проверка сертификата подтвердит неправильную выдачу. Нужны ограничения регистрации, разделение сред и журнал выдачи. Владелец сервиса должен знать не только список действующих сертификатов, но и основание, по которому они появились.
Дальше применяется отдельное разрешение: кадровая система вправе передавать утверждённые изменения, но не менять банковские реквизиты. Если обращение инициировал сотрудник, его полномочия тоже требуют проверки. Машинный сертификат не заменяет сведения о человеке и конкретной операции.
Если захвачено само приложение с законным ключом, mTLS может успешно подтвердить его личность. Поэтому нужны ограниченные разрешения, защита исполнения и наблюдение за необычными действиями. Сертификат не доказывает, что программа ведёт себя добросовестно.
Где заканчивается защищённое соединение
Проверку можно выполнять в приложении, на шлюзе или в сетевом посреднике. От этого меняется граница доверия. Если mTLS завершается на шлюзе, следующий участок до приложения — уже другое соединение. Приложению нужно достоверно получить сведения о проверенном клиенте.
Иногда их передают в заголовке запроса. Такой заголовок нельзя принимать от любого отправителя: доверенный посредник должен управлять им, а прямой маршрут в обход проверки — быть закрыт. Возможности удаления и формирования X-Forwarded-Client-Cert в Envoy показывают, почему это отдельная настройка, а не свойство названия заголовка.
Service Mesh может автоматизировать выдачу сертификатов и настройку соединений. Но не следует ради одной интеграции обязательно строить большую платформу. Сначала полезно нарисовать фактический путь запроса и отметить, кто на каждом участке подтверждает личность и применяет разрешение.
Первое соединение — только начало эксплуатации
У сертификата есть срок. Значит, потребуются автоматическое обновление, доставка нового значения и проверка, что работающий процесс начал его использовать. Файл на диске может быть новым, пока приложение продолжает держать старый сертификат в памяти. Проверка только существующего соединения этого не покажет.
Смена доверенного центра сложнее обычной замены сертификата приложения. Получателям может понадобиться ограниченный период доверия старому и новому источникам. Порядок перехода надо испытать, включая момент удаления прежнего доверия. Добавлять новые центры навсегда ради отсутствия ошибок — плохая замена завершённой миграции.
Владельцу инфраструктуры нужны показатели успешного обновления и оставшегося срока, а не только уведомление о последнем дне. В Istio выдача и обновление встроены в модель безопасности. Это уменьшает ручную работу, но не отменяет проверки нового запуска, смены доверия и ошибок доставки.
Что именно отключается при компрометации
Заменить сертификат и прекратить прежний доступ — разные действия. Украденный ключ может оставаться применимым, пока принимающая сторона доверяет соответствующему сертификату. Проверка отзыва зависит от инфраструктуры и настроек; нельзя предполагать, что все участники автоматически узнают о решении администратора.
Открытые соединения и возобновляемые сеансы тоже требуют внимания. Новый запрет на установление соединения не обязательно закрывает уже установленное. Для критичной интеграции нужно заранее определить, где отключается идентичность, какие соединения завершаются и как проверить прекращение доступа.
Недоступность выдачи сертификатов может сначала не влиять на работающие экземпляры, но помешать запуску новых или очередному обновлению. Поэтому испытание должно включать эти события. Запас времени до истечения срока не помогает, если никто не замечает, что обновление давно перестало работать.
Принимать работу по отказам, а не только по удачному запросу
Для пары кадровой и расчётной систем проверьте успешную передачу, обращение без сертификата, сертификат другого приложения и попытку выполнить лишнюю операцию. Затем обновите сертификат на работающем экземпляре, замените сам экземпляр и прекратите доступ тестовой идентичности. Используйте разрешённую испытательную среду без настоящих начислений.
Поддержка должна различать отказ доверия, истёкший срок, неверное разрешение и обычную сетевую ошибку. Закрытые ключи в диагностические файлы попадать не должны. По результатам станет понятно, какие новые обязанности компания сможет регулярно выполнять и какую проверку раньше не обеспечивала. Это более полезное основание для выбора mTLS, чем количество соединений, отмеченных как защищённые.