Власний 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 — місце, де підтверджують параметри перенаправлення, перш ніж обіцяти вузький контракт. Якщо ви не можете описати крок видалення одним реченням, межа більша за проблему.