Собственный TLS, SSH-перенаправление или VPN для одного облачного сервиса

Вопрос редко в том, шифровать ли что-то между двумя облачными машинами; вопрос в том, какой интерфейс вы шифруете и кто проверяет чью личность. Я начинаю такие разговоры с сервиса, а не со схемы сети, потому что сервис уже знает, что ему нужно. Три границы покрывают большинство случаев: собственный TLS приложения, один перенаправленный TCP-порт через SSH и маршрутизируемое наложение, дающее каждому участнику адрес. Они упорядочены не по силе, а по тому, какую часть проблемы покрывают.

Начните с сервиса, а не с сети

Идите от процесса наружу. По какому протоколу он говорит, какое имя проверит клиент и кому вообще разрешено открывать соединение? Эти три ответа отсекают варианты быстрее любой таблицы сравнения, и собственная конфигурация сервиса обычно даёт их за несколько минут.

Возьмите небольшой внутренний API, который уже отдаёт HTTPS на порту 8443 с сертификатом для api.internal.example. ss -ltnp на хосте показывает, к чему он привязан, а openssl s_client -connect 127.0.0.1:8443 -verify_hostname api.internal.example показывает, действителен ли сертификат для имени, которое клиент реально использует. Если оба здоровы, сервис может защитить свой поток, и остаётся только доступность. Это гораздо меньшая проблема, чем строить сеть.

Шаг 1: защищает ли сервис себя сам?

Это вариант на случай, когда он подходит, и подходит чаще, чем предполагают команды. Шифрование сервиса покрывает весь путь между клиентом и сервером, включая каждый переход между ними, чего не улучшает ни один туннель вокруг середины. Задайте ожидаемое имя и доверие явно, вместо того чтобы полагаться на то, что случайно лежит в хранилище клиента по умолчанию.

Шифрование и доступность остаются отдельными контролями, и именно их смешение — место, где этот вариант ошибается. TLS-сервис на неограниченном публичном слушателе по-прежнему принимает попытки подключения от кого угодно, поэтому слушатель и сетевые правила нужно определять независимо от того, что полезная нагрузка защищена. Затем проверьте зависимости, потому что API поверх TLS ничего не говорит об эндпоинте обнаружения, административном порту или канале массовой передачи рядом. Каждому из них нужен свой ответ, и одного незащищённого собрата достаточно, чтобы вся граница стала фикцией.

Шаг 2: один TCP-порт — это всё требование?

Когда требование действительно один TCP-порт, перенаправление — наименьшее, что работает. Локальное SSH-перенаправление несёт этот порт через уже существующее аутентифицированное соединение.

Форма — ssh -N -L 8443:127.0.0.1:8443 [email protected], и важная деталь — адрес назначения: 127.0.0.1 разрешается на удалённой стороне, поэтому соединение с сервисом открывается с бастиона, а не с вашего ноутбука. Привяжите локальный слушатель узко как -L 127.0.0.1:8443:..., чтобы случайно не опубликовать сервис в своей локальной сети. На стороне сервера ограничьте, что аккаунту разрешено перенаправлять, вместо того чтобы доверять хорошему поведению клиента. PermitOpen, AllowTcpForwarding local и стандартный GatewayPorts no — три настройки, превращающие универсальный ретранслятор в конкретный канал.

Контракт узок в обе стороны. SSH защищает свой канал, а дальнейший переход с бастиона к другому приложению требует собственной защиты. Сервис, слушающий только loopback бастиона, имеет совсем другое воздействие, чем доступный через другую сеть, и перенаправление этого не меняет. Сохраняйте аутентификацию и TLS-проверки приложения вместо того, чтобы считать туннель их заменой.

Это хорошо работает для одного соединения с одним владельцем. В масштабе это становится системой: локальные конфликты портов, надзор, ротация ключей и вопрос, кто перезапустит перенаправление после перезагрузки.

Шаг 3: маршрутизация — это настоящее требование?

Этот список — честная цена наименьшего варианта, и поэтому команды в конце концов заменяют горстку забытых фоновых команд чем-то управляемым. Замена не обязательно VPN. Если требование по-прежнему один TCP-порт, наблюдаемое перенаправление с задокументированным владельцем дешевле в эксплуатации, чем наложение, и отказывает видимыми способами. Измеряйте операционное владение, прежде чем измерять элегантность.

Маршрутизация становится правильным ответом, когда маршрутизация и есть требование. Несколько приложений, которым нужна обычная IP-связность, протоколы, которые TCP-перенаправление не может нести, или сервисы, перемещающиеся между хостами, указывают в одну сторону.

Наложение даёт участникам адрес и маршрут, а затем начинается настоящая работа: непересекающиеся диапазоны, владение маршрутами, DNS, регистрация, отзыв и что происходит, когда партнёр исчезает. Ничего из этого не приходит с адресом. Партнёр, допущенный в наложение, тоже не получает автоматически прав на каждую операцию на назначении, поэтому аутентификация на уровне сервиса остаётся.

Чем вы владеете после

Две вещи принадлежат записи, которую вы оставляете. Первая — личность, которую клиент должен проверить, потому что каждая из этих границ тихо ухудшается, как только проверку имени ослабляют, чтобы что-то заработало. Вторая — шаг удаления: какой ключ, какое правило или какой маршрут исчезает, когда доступ заканчивается, и кто это выполняет.

Обзор заканчивается там, где начался, на сервисе. Выберите границу, которая покрывает реальный трафик и проверяет тех партнёров, которых вы собирались проверить, затем запишите, как доступ обновляется, отслеживается и удаляется. Справочник OpenSSH — место, где подтверждают параметры перенаправления, прежде чем обещать узкий контракт. Если вы не можете описать шаг удаления одним предложением, граница больше проблемы.