Бир булут кызматы үчүн жергиликтүү TLS, SSH өткөрүү же VPN

Суроо эки булут машинасынын ортосунда бир нерсени шифрлөө керекпи дегенде эмес; суроо кайсы интерфейсти шифрлеп жатканыңызда жана ким кимдин инсандыгын текшерет. Мен бул сүйлөшүүлөрдү тармак диаграммасынан эмес, кызматтан баштайм, анткени кызмат эмне керек экенин билет. Үч чек көпчүлүк учурларды камтыйт: колдонмонун өз TLS, SSH аркылуу өткөрүлгөн бир TCP порту жана ар бир катышуучуга дарек берген маршрутталган катмар. Алар күчү боюнча эмес, маселенин канча бөлүгүн камтыганы боюнча иреттелет.

Тармактан эмес, кызматтан баштаңыз

Процесстен сыртка карай жүрүңүз. Ал кайсы протокол менен сүйлөйт, кардар кайсы атты текшерет жана кимге байланыш ачууга уруксат? Бул үч жооп каалаган салыштыруу таблицасынан тезирээк варианттарды жок кылат, ал эми кызматтын өз конфигурациясы адатта аларды бир нече мүнөттө берет.

8443 портунда HTTPS кызмат кылган кичине ички API алыңыз, api.internal.example үчүн сертификат менен. Хосттогу ss -ltnp анын эмнеге байланганын көрсөтөт, ал эми openssl s_client -connect 127.0.0.1:8443 -verify_hostname api.internal.example сертификаттын кардар чындап колдоно турган атка жарактуу экенин көрсөтөт. Экөө тең ден соолукта болсо, кызмат өз агымын коргой алат жана жеткиликтүүлүк гана калат. Бул тармак куруудан алда канча кичине маселе.

1-кадам: кызмат өзүн коргойбу?

Бул туура келгенде тандалуучу вариант жана командалар ойлогондон көп туура келет. Кызматтын шифрлөөсү кардар менен сервердин ортосундагы бүт жолду, анын ичинде ортодогу ар бир секирүүнү камтыйт, аны ортолукту айланган эч бир туннель жакшыртпайт. Күтүлгөн атты жана ишенимди ачык орнотуңуз, кардардын демейки кампасында кокустан бар нерсеге таянуунун ордуна.

Шифрлөө жана жеткиликтүүлүк өзүнчө көзөмөл болуп калат, жана аларды бириктирүү ушул варианттын ката кетирер жери. Чектелбеген ачык угуучудагы TLS кызматы дагы эле кимден болбосун байланыш аракеттерин кабыл алат, ошондуктан угуучу жана тармак эрежелери пайдалуу жүктүн корголгонуна көз карандысыз аныкталышы керек. Андан кийин көз карандылыктарды текшериңиз, анткени TLS үстүндөгү API ачуу акыркы чекити, админ порту же жанындагы жапырт өткөрүү каналы жөнүндө эч нерсе айтпайт. Алардын ар бирине өз жообу керек, ал эми бир корголбогон бир тууган бүт чекти ойдон чыгарылган нерсеге айландырууга жетиштүү.

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 маалымдамасы тар келишимге убада берүүдөн мурун өткөрүү параметрлерин ырастоочу жер. Алып салуу кадамын бир сүйлөм менен сүрөттөй албасаңыз, чек маселеден чоң.