Data encryption in transit — это защита данных в тот момент, когда они бегут по сети. Не когда лежат на диске, а именно «по проводам»: клиент-сервер, микросервисы между собой, вызовы API, подключения к базам и прочие сетевые разговоры. Задача простая: сделать так, чтобы никто не смог подслушать, подменить или незаметно увести трафик по дороге.
В отличие от шифрования at rest, которое заботится о том, что записано на диск, шифрование в транзите закрывает именно сетевой уровень — интернет, внутренние сегменты, связки между кластерами и дата-центрами.
Где это реально используется #
- Веб-приложения — классический HTTPS (HTTP over TLS) для защиты трафика между браузером и сервером;
- Межсервисные вызовы — gRPC, REST, GraphQL, SOAP, всё то же самое, но с TLS с обеих сторон;
- Базы данных — TLS-подключения к PostgreSQL, MySQL, MongoDB, Redis и прочим;
- VPN и туннели — WireGuard, OpenVPN, IPsec, когда надо связать сети или обеспечить доступ пользователям;
- Почта — SMTP/IMAP с STARTTLS или SMTPS, чтобы письма не шли голым текстом;
- Облачные API и CLI — SDK и веб-морды AWS, Azure, GCP общаются только по TLS.
Основные технологии и протоколы #
- TLS 1.2 / 1.3 — базовый стандарт шифрования для современных сервисов; по-хорошему, сейчас стоит ориентироваться на TLS 1.3;
- mTLS — когда аутентифицируются оба конца: и клиент, и сервер. Популярен в Service Mesh (Istio, Linkerd и прочие);
- HTTPS — тот же TLS, только в обёртке HTTP; обязателен для публичных API и пользовательских интерфейсов;
- VPN — шифрует весь трафик между сетями или пользователями; WireGuard сейчас часто выбирают за скорость и простоту;
- SSH-туннели — старый, но рабочий способ закрыть доступ к внутренним сервисам, особенно когда нужно «на время» и для отладки.
Пример: включаем TLS в PostgreSQL #
# сервер postgresql.conf
ssl = on
ssl_cert_file = '/etc/ssl/certs/server.crt'
ssl_key_file = '/etc/ssl/private/server.key'
# клиентская строка подключения
psql "host=db.internal.local sslmode=require dbname=prod user=readonly"
После такой настройки клиент разговаривает с базой по зашифрованному каналу, и логины с данными уже не летают в открытую.
Почему без этого сейчас никуда #
- Конфиденциальность — пароли, токены, персональные данные и прочее «чувствительное» не утекают при банальном перехвате трафика;
- Целостность — защита от подмены данных в пути и атак типа man-in-the-middle;
- Нормативка — GDPR, HIPAA, PCI DSS прямо требуют шифрования при передаче;
- Защита API и сервисов — особенно в микросервисах, где внутренний трафик кипит круглосуточно;
- Безопасность DevOps-инструментов — Terraform, kubectl, helm, CI/CD — всё это давно ездит по TLS, и так и надо.
Практические рекомендации #
- Ставьте TLS 1.3 по умолчанию, старые версии и слабые шифры лучше отключать, иначе ими рано или поздно воспользуются;
- Для внутреннего трафика в Kubernetes и Service Mesh используйте mTLS — меньше шансов, что кто-то внедрится в сервисы незамеченным;
- Автоматизируйте выпуск и обновление сертификатов через cert-manager или ACME, чтобы не ловить истёкшие сертификаты в проде;
- Собирайте метрики по TLS-handshake и трафику — это помогает и в отладке, и в безопасности (Prometheus, Envoy, Kiali и т.п.);
- Шифруйте трафик даже во «внутренних» сетях, особенно если это облако или гибрид — там «внутреннее» не такое уж и изолированное.
Data Encryption in Transit давно перестало быть «опцией». Это стандарт де-факто для любой современной системы, основа для Zero Trust-подхода и нормальная защита в мире публичных сетей и сильно раздробленных архитектур.
Аренда VPS/VDS — от ₽219/месяц
Почему выбирают VPS от AdminVPS:
✓ Дешевле физического сервера
✓ Более гибкий и мощный, чем обычный хостинг
✓ Бесплатная защита от DDoS и техподдержка 24/7
✓ Масштабируется под любые задачи
Виртуальный сервер VPS/VDS — ваш личный сервер для сайтов, магазинов, ботов и других проектов.
