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