Сопствени TLS, SSH прослеђивање или VPN за једну cloud услугу

Питање је ретко да ли шифровати нешто између две cloud машине; питање је који интерфејс шифрујете и ко проверава чији идентитет. Ове разговоре почињем од услуге, а не од мрежног дијаграма, јер услуга већ зна шта јој треба. Три границе покривају већину случајева: сопствени 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 је место где потврђујете опције прослеђивања пре него што обећате узак уговор. Ако не можете да опишете корак уклањања у једној реченици, граница је већа од проблема.