Когда зашифрованный backend-трафик избегает инспекции безопасности, TLS производит слепоту, а не доверие.
В корпоративных архитектурах TLS часто описывается как сквозное шифрование. Но с точки зрения инспекции безопасности ключевой вопрос таков: когда трафик зашифрован, может ли WAAP, движок сигнатур и контроль утечки данных реально видеть содержимое? Традиционные подходы терминируют TLS на frontend и либо повторно шифруют, либо передают трафик в plaintext к backend — но в этом переходе контроль тела ответа и чувствительных данных часто отключается.
В архитектуре нулевого доверия аутентификация только клиента недостаточна. Сертификат backend также должен быть проверен, сверен с правильной цепочкой CA, и там, где нужно, транзитный уровень сам должен быть идентифицирован через mTLS. Однонаправленная проверка сертификатов создаёт неполную модель доверия для современного трафика внутренних сервисов.
Инспекция тела ответа — отдельная задача. Номера карт, идентификаторы записей пациентов, персональные данные или внутренние чувствительные поля часто появляются в ответах приложений. Если уровень безопасности не может видеть это тело после повторного шифрования, обнаружение утечки данных и маскирование остаются лишь теоретическими возможностями.
Файлы custom CA, валидация цепочки сертификатов, SNI, ограничения TLS 1.2/1.3, ALPN и политики cipher suite становятся сложными для ручного управления. Один сервис может требовать современного TLS, тогда как legacy-сервис в процессе перехода ещё зависит от более старых cipher suite. Без центральной политики стандарты безопасности фрагментируются per-service.
Именно эту проблему решает TR7: сохраняет трафик к backend зашифрованным, сохраняя при этом инспекцию безопасности, mTLS-идентификацию, контроль чувствительных данных и запись аудита.
Наш подход
TR7 рассматривает путь TLS к backend как задачу инспекции безопасности, идентификации и контроля политики — а не просто параметр подключения.
Инспекция безопасности продолжается непрерывно через повторное шифрование
TR7 терминирует TLS на frontend, пропускает трафик через конвейер безопасности и повторно шифрует его к backend. Правила инспекции тела ответа, маскирования и замены выполняются до повторного шифрования.
mTLS-идентификация управляется независимо на каждом конце цепочки
Валидация клиентского сертификата и клиентский сертификат на стороне backend настраиваются независимо друг от друга. Это позволяет AAM устанавливать доверенный уровень идентификации как для доступа пользователей, так и для транзитного хопа сервиса.
Каждый backend-пул получает свою валидацию сертификата
Сертификаты backend могут проверяться против выделенного CA-файла, и certificate pinning можно добавить там, где необходимо. Поддержка SNI обеспечивает правильное разделение разных идентификаторов сервисов на одной инфраструктуре.
TLS-профиль безопасности применяется per backend-пул
Минимальная и максимальная TLS-версия, политика cipher suite и настройки ALPN определяются на уровне backend-пула. Современные сервисы работают под строгими политиками, тогда как переходные сервисы обрабатываются с контролируемыми исключениями.
Возможности
TR7 настраивает путь TLS к backend не просто как опцию подключения, а как аудируемую политику безопасности.
Backend TLS включается на уровне backend-пула
С `sslService: true` TR7 устанавливает соответствующее backend-соединение через TLS. Это предотвращает передачу трафика в plaintext через внутреннюю сеть и делает транзит сервиса зашифрованным. Организации могут централизованно управлять политикой повторного шифрования, терминируя TLS на frontend.
Исходящий трафик тоже: прямой прокси с выборочной расшифровкой и цепочкой ICAP
То же устройство, которое публикует ваши приложения, контролирует и выход наружу. Браузеры и серверы выходят в интернет через него, а на исходящем пути применяются аутентификация, политика по URL и назначениям, журналирование и проверка на угрозы. Расшифровка выборочна по назначению — банковские и медицинские категории могут проходить, вообще не вскрываясь, — а расшифрованный поток передаётся внешним системам инспекции в заданном порядке по ICAP, и вердикт каждой переходит к следующей. Одно устройство, одна модель политик, один журнал аудита на оба направления.
Верификация сертификата может быть принудительной с custom CA цепочкой
При выборе `sslVerify: required` TR7 проверяет backend-сертификат против custom CA-файла. Каждый backend-пул может использовать отдельный CA bundle, обеспечивая гибкость для внутренних CA цепочек, самоподписанных сертификатов или изолированных якорей доверия. Верификация может быть отключена, но рекомендуемая модель для корпоративных сред — обязательная верификация.
Backend mTLS-транзит получает идентификацию через клиентский сертификат
С `sslClientCert` и связанным объектом сертификата TR7 может предъявлять клиентский сертификат при подключении к backend. Это гарантирует, что backend принимает соединения только от правильного транзитного уровня. В приложениях, защищённых AAM, доступ пользователей и транзитный хоп сервиса управляются как два отдельных звена одной цепочки доверия.
Ограничения TLS-версий задаются через профиль безопасности
`minSslVersion` и `maxSslVersion` определяют диапазон TLS-версий для backend-соединений. Например, может быть применён профиль, допускающий только TLS 1.2 и TLS 1.3. Это предотвращает неконтролируемое использование более старых протоколов и делает переходы соответствия на уровне сервисов более безопасными.
Политика cipher suite применяется через именованный профиль или ручной список
Поле `cipherAlgorithm` может быть установлено в именованный профиль безопасности или ручной список. В ручном режиме `manualCipherAlgorithmList` явно определяет допустимые cipher suites, включая суиты на основе ECDHE. Организации могут применять стандартизированную TLS-политику, при этом контролируемым образом учитывая специфические требования сервисов.
Контролируемый legacy cipher suite может настраиваться для старых backend
Для legacy-backend, ещё находящихся в процессе перехода, доступна опция с менее безопасным cipher suite как контролируемое исключение. Это не постоянная модель безопасности — это мост совместимости, которым нужно тщательно управлять в ходе модернизации, чтобы избежать нарушений сервиса. Операционные команды могут поддерживать современный TLS-стандарт на frontend, мигрируя legacy-сервисы по плановому графику.
Инспекция тела ответа и маскирование выполняются до повторного шифрования
TR7 может выполнять правила инспекции тела ответа backend перед его пересылкой пользователю. Маскирование, замена и оценка WAAP-сигнатур не теряются внутри зашифрованного транзитного пути. Если номера карт, идентификаторы записей или другие чувствительные поля появляются в ответе приложения, уровень безопасности всё ещё может вмешаться.
Двунаправленная TLS-телеметрия отражается в CEF-записях
TR7 может записывать информацию TLS frontend и backend в записи аудита отдельно. Более 20 полей TLS-телеметрии — cipher suite, протокол, алгоритм ключа, субъект сертификата, эмитент сертификата и даты действия — доступны для мониторинга. Эта видимость упрощает доказательство зашифрованной цепочки при анализе инцидентов и аудите соответствия.
Аутентифицированное объединение в цепочку с вышестоящим прокси
Исходящий трафик может пересылаться на вышестоящий родительский прокси с сохранением учётных данных, поэтому инфраструктура, уже завершающая выход в интернет на корпоративном прокси, сохраняет эту цепочку. TR7 стоит в тракте, применяет выборочную расшифровку и цепочку ICAP и передаёт запрос дальше аутентифицированным, а не анонимным.
Операционная глубина
Инспекцию backend TLS следует рассматривать совместно с управлением сертификатами, журналированием аудита, контролем исключений и сценариями восстановления в ежедневных операциях.
Управление CA per-пул
Каждый backend-пул может проверяться против своего CA-файла. Это важно для отделов, использующих разные внутренние CA цепочки или изолированные конфигурации vTenant. Правильное сопоставление CA bundle с правильным пулом при обновлении сертификатов снижает операционные ошибки.
Опция certificate pinning
В дополнение к валидации CA цепочки доступно pinning по отпечатку сертификата. Эта модель полезна, когда требуется более строгая проверка идентификатора сервиса, чем доверие CA. Неожиданные изменения сертификатов на критических backend обнаруживаются быстрее.
Ограничения захвата ответа
Определённые области захвата для обработки заголовков ответа и тела обеспечивают операционную видимость. Дефолтная длина захвата 4 096 байт сохраняет существенные данные аудита, ограничивая стоимость логирования и инспекции. Область правил должна проектироваться тщательно для сценариев, требующих более широкой инспекции.
Legacy TLS исключения
Опция с менее безопасным cipher suite для legacy-backend должна рассматриваться исключительно как переходная потребность. Такие исключения должны управляться с отдельной политикой, отдельным мониторингом и чётким планом модернизации. Внутренний технический долг становится видимым, тогда как строгий TLS-стандарт на frontend сохраняется.
Аудит и анализ инцидентов
Детали TLS frontend и backend могут мониториться независимо в CEF-записях. Протокол, cipher suite, DN сертификата и даты действия показывают реальную позицию безопасности соединения при расследовании инцидентов. Эти записи позволяют командам соответствия ответить на вопрос, какой сервис работал с каким сертификатом при какой TLS-политике.
Цепочка идентификации с AAM
AAM может объединять идентификацию доступа на стороне клиента с mTLS-идентификацией на стороне backend в рамках той же транзитной архитектуры. Аутентификация пользователей, доступ к приложению и идентификатор сервиса не остаются разрозненными уровнями. Эта структура усиливает транзитный контроль на основе идентификации в архитектурах нулевого доверия.
Когда применять
Маскирование данных карт в платёжных приложениях
Финансовые и платёжные системы могут аутентифицировать входящий трафик через AAM и пересылать его к backend по повторно зашифрованному TLS. TR7 обнаруживает и маскирует поля, похожие на номера карт, в телах ответов, снижая риск утечки данных.
Инспекция данных пациентов в медицинских порталах
Медицинские организации могут контролировать, появляются ли номера записей пациентов или похожие чувствительные поля в ответах порталов. TR7 может поддерживать зашифрованный транзит к backend, продолжая инспекцию тела ответа.
Архитектура нулевого доверия для транзита сервисов
Крупные предприятия хотят идентифицировать не только пользователя, но и транзитный уровень сервиса с помощью сертификатов. TR7 устанавливает двунаправленную цепочку доверия — верификацию клиента на frontend и mTLS на backend.
Цепочка TLS-доказательств для аудита соответствия
Команды аудита должны доказать, какой протокол, какой cipher suite и какой сертификат использовались. TR7 выносит двунаправленную TLS-телеметрию в CEF-записи, делая зашифрованный трафик аудируемым.
Часто задаваемые вопросы
Действительно ли WAAP-инспекция работает, пока TR7 повторно шифрует трафик к backend?
Управляется ли конфигурация mTLS отдельно для frontend и backend?
Можно ли использовать разный CA-файл для каждого backend?
Поддерживаются ли TLS 1.3 и ECDHE для backend-соединений?
Какая TLS-телеметрия доступна в CEF-записях?
Что делать, когда legacy-backend требует более старый cipher suite?
Сделайте путь TLS к backend аудируемым
Инспекция безопасности, цепочка mTLS-идентификации и маскирование данных, работающие вместе через повторное шифрование. Давайте разберём живую настройку на вашей собственной инфраструктуре.