Собствен 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 е мястото, където да потвърдите опциите за препращане, преди да обещаете тесен договор. Ако не можете да опишете стъпката за премахване с едно изречение, границата е по-голяма от проблема.