TLS-шифрование — это не аутентификация, mTLS доказывает, кем является клиент.
Стандартное TLS-соединение шифрует трафик, но в большинстве сценариев не доказывает, кем клиент является на самом деле. Пароли, API-ключи, IP allowlist и контроль на основе токенов добавляют уровни безопасности, но они могут быть переданы, утечены, скопированы или использованы в неверном контексте. mTLS, напротив, верифицирует, что клиент владеет закрытым ключом, производя более сильный сигнал идентификации на уровне соединения.
В B2B API, платёжных потоках, совместном использовании медицинских данных, IoT-трафике устройств и доступе к управляющим интерфейсам это различие критично. Каждый партнёр, устройство или администратор приходит со своим сертификатом; срок действия сертификата, CA цепочка, CN, отпечаток и результат верификации — всё аудируемо. Однако требование каждого приложения независимо парсить эту информацию увеличивает операционную сложность.
В традиционных развёртываниях mTLS управление CA bundle, выбор режима верификации, коды ошибок, извлечение полей сертификата и пересылка этой информации в приложение — разрозненные задачи. Одна среда может требовать обязательного сертификата, тогда как другой нужен режим optional при переходе. Legacy CA цепочки, тестовые сертификаты и миграции партнёров — всё требует тонкого баланса между строгой валидацией и контролируемой терпимостью.
Правильный подход — управлять mTLS как профилем сервиса. Режим верификации, CA-файл, стратегия ошибок CA, пересылка полей сертификата к backend и политики условного доступа AAM — всё должно жить в одной модели.
TR7 TLS / mTLS Client-Cert Authentication реализует эту модель: извлекает клиентский сертификат из контроля уровня соединений и превращает его в пригодный для использования объект идентификации как для backend-сервисов, так и для политик доступа.
Наш подход
TR7 применяет mTLS-верификацию совместно с per-service режимом верификации, управлением CA, пересылкой полей сертификата и политикой доступа AAM в единой согласованной модели.
Три режима верификации охватывают разные уровни миграции и безопасности
С режимами none, optional и required каждый сервис может применять свою собственную mTLS-политику. Сертификаты могут быть обязательными, оставаться опциональными при переходе или полностью отключёнными для данного сервиса.
Поля сертификата пересылаются к backend как HTTP-заголовки
Код верификации, SHA1-отпечаток, CN и дополнительные поля сертификата могут маппироваться в HTTP-заголовки. Backend читает информацию идентификации напрямую без необходимости парсить сертификат.
Backend и уровень управления потребляют данные сертификата нативно
Заголовки сертификата могут разбираться на поля, такие как present, verified, verify, sha1 и cn. Даже при сбое верификации данные сертификата могут логироваться и передаваться в движок решений контролируемым образом.
Стратегия ошибок CA разделяет поведение миграции от production
Ошибки валидации CA могут полностью отклоняться, полностью допускаться при переходе или ослабляться только для конкретных кодов ошибок. Это позволяет политикам staging, миграции партнёров и production сосуществовать в одной mTLS-модели.
Возможности
TLS / mTLS Client-Cert Authentication верифицирует, парсит, логирует и делится клиентским сертификатом с backend — всё на границе.
Per-service mTLS-политика задаётся режимами none, optional и required
TR7 управляет поведением аутентификации по клиентскому сертификату независимо для каждого сервиса. В режиме none сертификат не запрашивается. В режиме optional сертификат парсится при предъявлении; при отсутствии соединение может продолжаться. В режиме required любое соединение без сертификата отклоняется. Эта структура обеспечивает строгую безопасность в production, гибкость в staging и поэтапный выкат при миграции. Разные сервисы на одной платформе могут применять разные требования mTLS.
Каждый сервис может верифицировать против собственного CA bundle
TR7 может проверять клиентские сертификаты против per-service CA-файлов. CA цепочка партнёра A может использоваться на одном сервисе, тогда как цепочка партнёра B применяется к другому. Это разделение позволяет управлять разными бизнес-партнёрами или группами устройств изолированно на одном ADC без полагания на единый глобальный CA список. На сервис определяется отдельный корень доверия.
Результат верификации сертификата пересылается к backend как чёткий заголовок
TR7 может доставлять статус верификации клиентского сертификата к backend через заголовки, такие как x-ssl-verify. Успешная верификация, отсутствие сертификата или конкретный сбой верификации видны приложению. Backend может принимать решения на основе mTLS-статуса соединения без работы с TLS-стеком или парсингом сертификата.
CN и SHA1-отпечаток несут идентификатор клиента в приложение
TR7 может извлекать Common Name и SHA1-отпечаток из клиентского сертификата и пересылать их как заголовки к backend. CN может служить идентификатором партнёра, устройства, пользователя или сервиса. SHA1-отпечаток предлагает практический ключ для сценариев allowlist, аудита, сопоставления или быстрой отзыва. Отпечатки нормализуются, чтобы разные стили форматирования не производили разные значения идентификации.
Стратегия ошибок CA обеспечивает контролируемую терпимость при переходах
caErrorStrategy позволяет по-разному реагировать на сбои валидации CA. ignoreAll может допускать все ошибки CA во временных сценариях отладки или миграции; manualIgnoreList ограничивает терпимость конкретными кодами ошибок валидации. В production эта гибкость может быть отключена для принуждения к нулевой терпимости. Модель создаёт контролируемый баланс между строгой безопасностью и реальными потребностями миграции.
ADC может устанавливать mTLS к backend в качестве клиента
TR7 не только запрашивает сертификаты от входящих клиентов — он также может предъявлять клиентский сертификат при подключении к backend-сервису. Соединение, смотрящее на backend, может быть настроено с требуемой верификацией, CA-файлом и клиентским сертификатом ADC. Это обеспечивает независимые TLS-политики доверия как на клиент-TR7, так и на TR7-backend плечах. Трафик может инспектироваться на границе, тогда как внутреннее соединение остаётся полностью защищённым.
Политики условного доступа AAM сочетаются с идентификацией сертификата
Клиентский сертификат — сильный сигнал идентификации, но ему не нужно нести полное решение по доступу самостоятельно. TR7 может использовать данные сертификата как один из входных параметров политик условного доступа AAM. Сертификат, IP-адрес, состояние устройства, группа пользователя, время суток и статус MFA — всё может оцениваться совместно. mTLS становится одним компонентом более широкого решения доступа нулевого доверия.
mTLS, WAAP и защита от DDoS работают на одном пути трафика
Успешная верификация сертификата не делает запрос автоматически безопасным — контроль содержимого и объёма продолжают применяться. TR7 выполняет уровень mTLS-идентификации совместно с WAAP, DDoS и анализом поведения ботов. mTLS устанавливает, кто является клиентом; WAAP оценивает, что делает запрос; уровень DDoS оценивает объём трафика. Все три контроля могут работать совместно перед одним сервисом.
Режим optional обеспечивает fallback на API-ключ и постепенную миграцию партнёров
В режиме optional партнёры, предъявляющие сертификат, обрабатываются с mTLS-идентификацией, тогда как клиенты, ещё не завершившие миграцию сертификата, могут переходить к альтернативному механизму аутентификации. Этот паттерн позволяет безопасно выкатывать крупные B2B-миграции без принуждения всех партнёров к mTLS в один день. Backend может выбирать между потоками на основе сертификата и API-ключа на основе наличия заголовка x-ssl-verify. После завершения миграции сервис может быть переведён в режим required.
Детальные TLS и сертификатные логи усиливают цепочку аудита
Для mTLS-соединений могут логироваться поля, такие как субъект сертификата, эмитент, окно действия, результат верификации и отпечаток. В SIEM становится ясно, какой партнёр обращался к какому сервису с каким сертификатом. События, такие как истёкший, самоподписанный или сбои эмитента, могут анализироваться отдельно. Эти записи создают сильную цепочку аудита для соответствия, расследования инцидентов и аудита партнёров.
Операционная глубина
Операция mTLS охватывается сквозно: поведение bind, коды верификации, обнаружение сертификата через заголовок, нормализация отпечатка, область CA-файла и валидация SNI/Host.
Поведение верификации bind
Поведение верификации none, optional или required задаётся в точке входа сервиса. В режиме required клиентское соединение без сертификата отклоняется. В режиме optional сертификат парсится при наличии; при отсутствии запрос может продолжаться к альтернативному потоку политики.
Коды верификации
Результат верификации сертификата может быть выражен как числовой код ошибки. Ноль означает успешную верификацию; другие значения указывают на условия, такие как эмитент не найден, сертификат истёк, сертификат ещё не действителен или самоподписанный сертификат. Это значение может быть переслано к backend как заголовок.
Обнаружение сертификата через заголовок
Если x-ssl-verify пуст или указывает, что сертификат не использовался, клиент считается не предъявившим сертификат. Значение 0 означает, что сертификат успешно верифицирован. Любое другое значение означает, что данные сертификата могут присутствовать, но верификация не прошла — это может быть обработано отдельно в логах и политических решениях.
Нормализация SHA1-отпечатка
Значения отпечатков могут приходить со смешанным регистром и форматированием с двоеточиями. TR7 нормализует значение, чтобы операции сравнения и allowlist работали последовательно. Один и тот же сертификат не считается другой идентичностью из-за различия форматирования.
Область CA-файла
Каждый сервис может использовать свой CA bundle, что позволяет изолировать корни доверия по партнёрам, группам устройств и внутренним сервисам. Изменения CA должны планироваться с учётом влияния на сервис и должны быть аудированы.
Валидация SNI и Host
На сервисах с mTLS могут быть включены валидация SNI и Host в дополнение к верификации сертификата. Когда сертификат, SNI и Host оцениваются совместно, идентификатор запроса, целевой домен и намерение HTTP-маршрутизации все проверяются в комбинации. Эта модель помогает снизить риск злоупотребления в стиле domain fronting.
Когда применять
Идентификация по сертификату для партнёров B2B API
Каждый партнёр подключается к API с уникальным клиентским сертификатом. TR7 логирует значения CN и SHA1-отпечатка, пересылает их к backend и упрощает аудит и решения по ограничению скорости для каждого партнёра.
Регистрация IoT-устройств и верификация телеметрии
Каждое устройство может подключаться к TR7, используя уникальный сертификат, загруженный на заводе. Серийный номер устройства хранится в поле CN, и allowlist по отпечатку ускоряет управление потоками отзыва и ограничения доступа.
Верификация идентификатора провайдера при совместном использовании медицинских данных
Медицинские организации могут использовать mTLS при совместном использовании данных с системами провайдеров для аутентификации на уровне соединения. При истечении сертификата или сбое верификации доступ может быть отрезан автоматически без ручного вмешательства.
Доступ к управляющему интерфейсу с mTLS и MFA
Системные администраторы могут подключаться к управляющему интерфейсу TR7, используя клиентский сертификат. В сочетании с MFA и состоянием устройства через AAM один конкретный ноутбук, конкретный сертификат и верифицированный идентификатор администратора подтверждаются совместно.
Часто задаваемые вопросы
В чём разница между режимами mTLS верификации?
Как информация сертификата пересылается к backend?
Когда следует использовать стратегию ошибок CA?
Может ли TR7 предъявлять собственный сертификат при подключении к backend?
Могут ли mTLS, WAAP и защита от DDoS работать совместно?
Как политики условного доступа AAM сочетаются с mTLS?
Добавьте mTLS в уровень идентификации сервиса
Верифицируйте клиентский сертификат на границе, пересылайте его к backend и комбинируйте с политикой AAM. Давайте разберём живую настройку на ваших собственных сервисах.