7 мая 2026 г.·3 мин чтения

mTLS на собеседовании системного аналитика

Готовься к собесу аналитика как в Duolingo
10 минут в день — SQL, Python, A/B, метрики. 1700+ вопросов в Telegram
Открыть Карьерник в Telegram

Карьерник — Duolingo для аналитиков: 10 минут в день тренируй SQL, Python, A/B, статистику, метрики и ещё 3 темы собеса. 1500+ вопросов в Telegram-боте. Бесплатно.

Содержание:

Зачем спрашивают на собесе SA

mTLS — стандарт для service-to-service auth, особенно в банковской/госов сфере. На собесе SA: «отличие от TLS», «когда mTLS», «как работает».

TLS vs mTLS

TLS (1-way). Клиент проверяет сервер по certificate. Сервер не проверяет клиента (доверяет аутентификации поверх — JWT, OAuth).

mTLS. Both sides проверяют certificates. Клиент должен предоставить свой cert.

TLS:  Server → cert → Client checks
mTLS: Server → cert → Client checks; Client → cert → Server checks

Mutual TLS handshake

1. Client → Server: ClientHello (suite list, etc).
2. Server → Client: ServerHello + Server Certificate + CertificateRequest.
3. Client → Server: Client Certificate + CertificateVerify (signs handshake).
4. Both: derive shared secret.
5. Encrypted communication starts.

CertificateVerify доказывает, что клиент владеет private key соответствующего public cert.

Когда применять

Подходит:

  • Service-to-service в k8s / cloud.
  • B2B integration с partners (банки).
  • IoT (devices с unique certs).
  • Zero Trust networks.

Не подходит:

  • Public-facing endpoints — clients (browser users) не имеют certs.
  • Маленькие проекты — overhead PKI.
Готовься к собесу аналитика как в Duolingo
10 минут в день — SQL, Python, A/B, метрики. 1700+ вопросов в Telegram
Открыть Карьерник в Telegram

PKI и сертификаты

Public Key Infrastructure для управления certs.

  • CA (Certificate Authority). Подписывает certs клиентов / серверов.
  • Cert. Содержит public key + identity + signature CA.
  • Private key. Никогда не покидает endpoint.
  • Revocation. CRL / OCSP — список отозванных.

Internal CA. Для internal services — own CA, не Let's Encrypt.

Cert lifecycle:

  • Generation (CSR → CA).
  • Distribution.
  • Rotation (90 days standard).
  • Revocation.

Service Mesh integration

Istio, Linkerd, Consul Connect — реализуют mTLS прозрачно.

Service A → sidecar proxy → mTLS → sidecar proxy → Service B

App не знает про mTLS — sidecars handle. Auto-rotation, auto-cert distribution.

В k8s — стандарт zero trust setup.

Частые ошибки

Self-signed certs в production. Trust chain ломается. Используй internal CA.

Мануальная rotation. Cert expires → outage. Auto-rotate (cert-manager в k8s).

Один cert на много services. SPOF — компрометация одного → все.

Не проверять CN / SAN. Cert валидный, но от другого сервиса. Проверять identity.

Mixing с JWT. mTLS — channel auth. JWT — application auth (что user делает). Часто комбинируется.

Связанные темы

FAQ

Сколько живёт client cert?

Стандартно 90 дней. SPIFFE / Istio часто 1 час с auto-rotation.

mTLS вместо OAuth?

mTLS — channel-level auth между сервисами. OAuth — user-level. Разные scope. Часто комбинируется.

Это официальная информация?

Нет. Статья основана на RFC 8446 (TLS 1.3), документации Istio.

Тренируйте системный анализ — откройте тренажёр с 1500+ вопросами для собесов.

Ещё по теме