mTLS и идентичность сервиса

От «сервер настоящий» к «настоящие обе стороны»

Обычный TLS — это односторонняя аутентификация. Во время рукопожатия сервер присылает свой сертификат, клиент сверяет его с доверенным CA, и дальше клиент знает, что говорит с настоящим api.example.com. А вот сервер не узнаёт ничего проверяемого о клиенте — кто дотянулся до порта, тот и получил TLS-сессию. Эта асимметрия нормальна для браузера, заходящего на публичный сайт, потому что человек потом залогинится. Но для трафика между сервисами это дыра: там нет человека, а «логином» исторически был bearer-токен или сетевой ACL — и то и другое атакующий, уже находящийся внутри периметра, может украсть или удовлетворить.

mTLS (взаимный TLS) закрывает эту асимметрию. Рукопожатие TLS 1.3 (RFC 8446) поддерживает CertificateRequest: после того как аутентифицировался сервер, он просит клиента тоже предъявить сертификат, и клиент доказывает владение соответствующим приватным ключом подписью CertificateVerify поверх транскрипта рукопожатия. Теперь у обоих концов есть криптографически доказанная личность ещё до того, как пройдёт хоть один байт прикладных данных. Что критично: приватный ключ никогда не пересекает провод — сторона доказывает, что владеет ключом, подписывая, поэтому наблюдение или переигрывание рукопожатия не даёт атакующему ничего.

Это и есть несущий сдвиг для сети с нулевым доверием (NIST SP 800-207): доверие больше не свойство того, откуда пришёл пакет, а того, какая личность предъявила валидный учётный признак. Приватная сеть перестаёт быть границей доверия. Скомпрометированный под всё равно не сможет выдать себя за сервис заказов, потому что не держит его приватный ключ.

Что на самом деле идентифицирует сертификат

Сертификат аутентифицирует личность, но для сервисов личность — это не имя хоста, которое набрал бы браузер, а рабочая нагрузка. Господствующее соглашение здесь — SPIFFE: личность рабочей нагрузки кодируется как URI в поле Subject Alternative Name (SAN) сертификата, SPIFFE ID вида spiffe://prod.example/ns/payments/sa/orders. Эта строка говорит: в домене доверия prod.example это сервисная учётная запись orders в пространстве имён payments. Когда сервис заказов соединяется с платежами, платежи читают проверенный SAN, видят знакомый SPIFFE ID и затем решают, разрешено ли этой личности делать то, что она просит.

Вот эту последнюю оговорку инженеры и пропускают. mTLS даёт тебе аутентификацию — сильный, неподделываемый ответ на вопрос «кто это?». Он не даёт авторизации — «разрешено ли этой личности делать это?». Валидный сертификат из твоего домена доверия доказывает, что вызывающий — легитимная рабочая нагрузка; он ничего не говорит о том, должна ли эта нагрузка иметь право оформлять возвраты. Полный дизайн таков: mTLS устанавливает личность на уровне соединения, а слой политики (SPIFFE-осведомлённая авторизация, AuthorizationPolicy в Istio, проверка в OPA) принимает по этой личности решение allow/deny на каждый запрос. Смешать одно с другим — «сертификат прошёл проверку, значит, пропускаем» — это и есть способ построить плоский, полностью доверенный mesh, где любая скомпрометированная нагрузка может вызвать что угодно.

Самое трудное: ротация в масштабе

Криптография mTLS решена; жизнь или смерть — в эксплуатации. Если каждому сервису нужен сертификат и приватный ключ, ты теперь держишь центр сертификации и конвейер раздачи для тысяч короткоживущих учётных признаков. Зрелый инстинкт — делать сертификаты короткоживущими: часы, а не годы. Сертификат, живущий час, сжимает окно, в котором украденный ключ полезен, и почти снимает проблему отзыва: ты не воюешь с печально ненадёжной машинерией отзыва CRL/OCSP, а просто даёшь сертификату истечь и не перевыпускаешь его нагрузке, которую отрезал. Истечение становится твоим отзывом.

Но короткоживущие сертификаты работают, только если ротация полностью автоматизирована и перекрывается. Вот сбой, который поднимает людей среди ночи: задача обновления умерла, сертификаты истекли в 03:00, и внезапно каждый сервис отвергает каждую сторону разом — самонанесённый общекластерный отказ без всякого атакующего. Защиты таковы: ротировать задолго до истечения (обновлять на ~50–66% срока жизни, чтобы у провалившегося обновления оставались часы запаса), перезагружать новый сертификат без обрыва живых соединений и делать ротацию якоря доверия (CA) отдельным, более медленным процессом с перекрытием, где во время переключения одновременно доверяют и старому, и новому корню. На практике этот цикл за тебя крутит service mesh (Istio, Linkerd) или SPIRE из SPIFFE — выпуская, раздавая и ротируя сертификаты нагрузок через sidecar или агент, так что код приложения никогда не касается ключа. Сделка, которую ты покупаешь: настоящая личность на каждую нагрузку в обмен на эксплуатацию высокодоступного CA, чей отказ теперь — продакшен-отказ.

Как зрелый инженер рассуждает о внедрении

mTLS не бесплатен, и честная формулировка — это компромисс, а не серебряная пуля. Ты получаешь доверие на основе личности, переживающее пробой сети и превращающее латеральное движение из «бесплатно внутри периметра» в «всё ещё нужен приватный ключ каждого сервиса». Платишь же ты тем, что CA должен быть высокодоступным (его отказ — твой отказ), циклом автоматической ротации, который нельзя дать молча сломаться, и реальной ценой CPU/задержки на каждом рукопожатии — поэтому ты терминируешь mTLS на sidecar и держишь сессии долгоживущими, чтобы её амортизировать. И ты должен помнить границу: mTLS аутентифицирует рабочую нагрузку, а не конечного пользователя. Личность человека (его сессия, его скоупы) по-прежнему едет внутри запроса на прикладном уровне; mTLS защищает трубу и доказывает идентичность сервиса-вызывающего, но сервис, которому доверено тебя вызывать, всё ещё может нести поддельное или раздутое по правам пользовательское утверждение, если ты его не проверишь.