Уласны 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 — месца, дзе пацвердзіць параметры перанакіравання, перш чым абяцаць вузкі кантракт. Калі вы не можаце апісаць крок выдалення адным сказам, мяжа большая за праблему.