Владимир Соловьев

Владимир Соловьев 

Архитектор решений (Solution Architect)

3subscribers

18posts

Showcase and bundles

3
A bundle is a collection, compilation, playlist, or catalog of posts that saves you from searching through the blog and lets you buy the entire content series in a single click.

HTTP, HTTPS и mTLS: что на самом деле под капотом

В ТЗ на интеграцию рано или поздно встречается строчка «взаимодействие по HTTPS» или «по mTLS». Аналитик не настраивает сертификаты руками, но должен понимать, что стоит за этими словами: какой уровень защиты выбран, кто кого проверяет и что из этого записать в требования. Разберём три уровня по порядку.

HTTP: всё открытым текстом

HTTP (HyperText Transfer Protocol) – базовый протокол, по которому клиент и сервер обмениваются сообщениями. Проблема одна: данные передаются в открытом виде. Любой узел на пути – Wi-Fi-точка, провайдер, прокси – может прочитать и заголовки, и тело запроса.
POST /login
{ "user": "ivan", "password": "12345" }
Если это ушло по HTTP, логин и пароль видны всем, через кого прошёл пакет. Поэтому для любых чувствительных данных чистый HTTP сегодня неприемлем.

HTTPS: шифрование и проверка сервера

HTTPS – это тот же HTTP, но поверх защищённого канала TLS (Transport Layer Security). «S» в конце – это и есть TLS под капотом. Он решает две задачи.
1. Шифрование. Данные шифруются, и перехватчик по пути видит только бессмысленный набор байтов, а не логин с паролем.
2. Аутентификация сервера. Перед обменом данными сервер предъявляет TLS-сертификат – документ, подтверждённый доверенным центром сертификации (CA). Клиент проверяет его и убеждается, что общается с настоящим сайтом, а не с подставным.
Упрощённо TLS-рукопожатие выглядит так:
  1. Клиент подключается и запрашивает защищённое соединение
  2. Сервер присылает свой сертификат
  3. Клиент проверяет сертификат по доверенным CA
  4. Стороны согласуют ключ шифрования
  5. Дальше весь обмен идёт зашифрованным

Ключевой нюанс: HTTPS проверяет только сервер

Вот момент, который упускают чаще всего. В обычном HTTPS сертификат предъявляет только сервер. Клиент убеждается, что сервер настоящий, а вот сервер в подлинности клиента не убеждается – он готов общаться с кем угодно, кто к нему подключился.
Для публичного сайта это нормально: магазину не важно, какой браузер пришёл, важно зашифровать канал. Но для интеграции между двумя системами этого мало – сервер должен быть уверен, что запрос пришёл именно от доверенного партнёра, а не от постороннего.

mTLS: взаимная проверка

mTLS (mutual TLS, взаимный TLS) закрывает этот пробел. Здесь сертификат предъявляют обе стороны: не только сервер клиенту, но и клиент серверу.
  • Сервер показывает свой сертификат – как в обычном HTTPS
  • Клиент дополнительно показывает свой клиентский сертификат
  • Соединение устанавливается, только если обе стороны доверяют сертификатам друг друга
В результате сервер обслуживает не любого, а лишь клиента с валидным сертификатом. Посторонний, даже зная адрес API, не подключится – своего сертификата у него нет.

Где применяется mTLS

  • Банковские и платёжные интеграции – обе стороны должны строго доверять друг другу
  • Взаимодействие микросервисов внутри компании (service-to-service)
  • Партнёрские API, где доступ строго ограничен известными клиентами
  • Госсистемы и обмен по регламентам, где двусторонняя аутентификация обязательна

Что аналитику писать в ТЗ

Недостаточно фразы «обеспечить безопасность». Конкретизируй:
  • Протокол – HTTPS или mTLS
  • Кто предъявляет сертификат – только сервер или обе стороны
  • Откуда берутся сертификаты – какой центр сертификации, кто выпускает клиентский
  • Срок действия и обновление – сертификаты истекают; кто и как их продлевает
  • Поведение при невалидном сертификате – соединение отклоняется, какой код и лог

Коротко

  • HTTP – данные открытым текстом, читает кто угодно по пути
  • HTTPS – канал шифруется, сервер сертификатом доказывает свою подлинность; клиент – нет
  • mTLS – сертификат предъявляют обе стороны, они аутентифицируют друг друга
  • «S» в HTTPS – это TLS, а не украшение
  • Выбор между HTTPS и mTLS – это про то, нужно ли серверу проверять клиента
Понимая эти три уровня, аналитик описывает защиту канала не общими словами, а конкретными требованиями, по которым разработчик всё настроит без переспросов.
pdf
07_чеклист_защита_канала.pdf107.08 Kb
Subscription levels1

Стажер

$5.1 per month
Для тех, кто только заходит в системный анализ.
• Все посты канала без задержки
• Словарь из 200+ IT-терминов - сразу после оплаты
• Шаблоны документов, которые я реально использую в работе
Подготовка к собеседованию: 151 вопрос в 10 разделах: роль СА, требования, моделирование, API, интеграции, безопасность, архитектура, базы данных и SQL и тд
Мне был 33 года, когда я ушёл из МВД после 13 лет службы и начал заново.
Здесь всё, что я хотел бы иметь под рукой в тот момент.
Go up