Katutubong TLS, pagpapasa ng SSH o VPN para sa isang serbisyo sa cloud

Bihirang tanong kung dapat bang i-encrypt ang isang bagay sa pagitan ng dalawang cloud machine; ang tanong ay kung aling interface ang ini-encrypt mo at sino ang nagche-check ng pagkakakilanlan ng kanino. Sinisimulan ko ang mga pag-uusap na ito sa serbisyo at hindi sa diagram ng network, dahil alam na ng serbisyo kung ano ang kailangan nito. Tatlong hangganan ang sumasaklaw sa karamihan ng kaso: ang sariling TLS ng application, isang port ng TCP na ipinapasa sa SSH, at isang rutadong overlay na nagbibigay ng address sa bawat kalahok. Hindi sila niraranggo ayon sa lakas, kundi ayon sa kung gaano karami ng problema ang sinasaklaw nila.

Magsimula sa serbisyo, hindi sa network

Lumakad palabas mula sa proseso. Anong protocol ang sinasalita nito, anong pangalan ang che-check ng kliyente, at sino ang pinapayagang magbukas ng koneksyon? Ang tatlong sagot na iyon ay nag-aalis ng mga opsyon nang mas mabilis kaysa sa anumang talahanayan ng paghahambing, at ang sariling configuration ng serbisyo ay karaniwang sumasagot sa mga ito sa loob ng ilang minuto.

Kumuha ng maliit na panloob na API na naghahain na ng HTTPS sa port 8443 na may sertipiko para sa api.internal.example. Ipinapakita ng ss -ltnp sa host kung ano ang nakakabit dito, at ipinapakita ng openssl s_client -connect 127.0.0.1:8443 -verify_hostname api.internal.example kung valid ang sertipiko para sa pangalan na talagang gagamitin ng kliyente. Kung pareho silang malusog, mapoprotektahan ng serbisyo ang sarili nitong stream at natitira na lang ang maabot. Mas maliit na problema iyon kaysa sa pagbuo ng network.

Hakbang 1: pinoprotektahan ba ng serbisyo ang sarili nito?

Ito ang opsyon na dapat piliin kapag bagay ito, at mas madalas itong bagay kaysa sa inaakala ng mga team. Sinasaklaw ng encryption ng serbisyo ang buong landas sa pagitan ng kliyente at server, kasama ang bawat pagtalon sa gitna, na walang tunnel sa paligid ng gitna ang makapagpapabuti. Itakda nang tahasan ang inaasahang pangalan at pagtitiwala sa halip na umasa sa kung ano ang nagkataong nasa default na imbakan ng kliyente.

Nananatiling magkahiwalay na kontrol ang encryption at pag-abot, at ang pagsasama ng mga ito ang lugar kung saan nagkakamali ang opsyong ito. Ang serbisyo ng TLS sa isang walang limitasyong pampublikong tagapakinig ay tumatanggap pa rin ng mga pagtatangkang kumonekta mula sa kahit sino, kaya ang tagapakinig at mga tuntunin ng network ay dapat tukuyin nang hiwalay sa katotohanang protektado ang payload. Pagkatapos ay suriin ang mga dependency, dahil ang API sa ibabaw ng TLS ay walang sinasabi tungkol sa discovery endpoint, admin port o ang bulk transfer channel sa tabi nito. Bawat isa ay nangangailangan ng sarili nitong sagot, at sapat ang isang kapatid na walang proteksyon upang gawing kathang-isip ang buong hangganan.

Hakbang 2: isang port ng TCP ba ang buong pangangailangan?

Kapag ang pangangailangan ay talagang isang port ng TCP, ang pagpapasa ang pinakamaliit na bagay na gumagana. Ang lokal na pagpapasa ng SSH ay nagdadala ng port na iyon sa pamamagitan ng koneksyong na-authenticate na umiiral na.

Ang hugis ay ssh -N -L 8443:127.0.0.1:8443 [email protected], at ang detalyeng mahalaga ay ang target na address: ang 127.0.0.1 ay nireresolba sa malayong panig, kaya ang koneksyon sa serbisyo ay binubuksan mula sa bastion at hindi mula sa iyong laptop. Itali ang lokal na tagapakinig nang makitid bilang -L 127.0.0.1:8443:... upang hindi mo aksidenteng mailathala ang serbisyo sa sarili mong lokal na network. Sa panig ng server, limitahan kung ano ang maaaring ipasa ng account sa halip na magtiwala sa mabuting pag-uugali ng kliyente. Ang PermitOpen, AllowTcpForwarding local at default na GatewayPorts no ay ang tatlong setting na nagpapalit ng pangkalahatang relay tungo sa partikular na channel.

Makitid ang kontrata sa parehong direksyon. Pinoprotektahan ng SSH ang sarili nitong channel, at ang karagdagang pagtalon mula sa bastion patungo sa ibang application ay nangangailangan ng sarili nitong proteksyon. Ang serbisyong nakikinig lamang sa loopback ng bastion ay may ganap na kakaibang pagkakalantad kaysa sa naaabot sa ibang network, at hindi iyon binabago ng pagpapasa. Panatilihin ang authentication at mga TLS check ng application sa halip na ituring ang tunnel bilang kapalit ng mga ito.

Gumagana ito nang maayos para sa isang koneksyon na may isang may-ari. Sa malaking sukat ito ay nagiging isang sistema: mga salungatan ng lokal na port, pangangasiwa, pag-ikot ng key at ang tanong kung sino ang muling magsisimula ng pagpapasa pagkatapos ng reboot.

Hakbang 3: ang rutadong pagpapasa ba ang tunay na pangangailangan?

Ang listahang iyon ay ang tapat na halaga ng pinakamaliit na opsyon, at iyon ang dahilan kung bakit kalaunan ay pinapalitan ng mga team ang ilang nakalimutang background command ng isang bagay na pinamamahalaan. Ang kapalit ay hindi awtomatikong VPN. Kung ang pangangailangan ay isa pa ring port ng TCP, ang binabantayang pagpapasa na may dokumentadong may-ari ay mas mura pang patakbuhin kaysa sa overlay at nabigo ito sa mga paraang nakikita mo. Sukatin ang pagmamay-ari sa operasyon bago sukatin ang kagandahan.

Nagiging tamang sagot ang rutadong pagpapasa kapag ito ang pangangailangan. Ilang application na nangangailangan ng ordinaryong konektibidad ng IP, mga protocol na hindi kayang dalhin ng pagpapasa ng TCP, o mga serbisyong lumilipat sa pagitan ng host — lahat sila ay tumuturo sa iisang direksyon.

Ang overlay ay nagbibigay sa mga kalahok ng address at ruta, at pagkatapos ay nagsisimula ang tunay na gawain: mga saklaw na hindi nagsasapawan, pagmamay-ari ng ruta, DNS, pagpapatala, pagbawi at kung ano ang nangyayari kapag nawala ang isang kapares. Wala sa mga ito ang dumarating kasama ng address. Ang kapares na tinanggap sa overlay ay hindi rin awtomatikong pinahihintulutan para sa bawat operasyon sa destinasyon, kaya nananatili ang authentication sa antas ng serbisyo.

Ano ang pagmamay-ari mo pagkatapos

Dalawang bagay ang nabibilang sa rekord na iniiwan mo. Ang una ay ang pagkakakilanlang inaasahang i-verify ng kliyente, dahil ang bawat isa sa mga hangganang ito ay tahimik na lumalala kapag ang pagsusuri ng pangalan ay niluwagan upang gumana ang isang bagay. Ang pangalawa ay ang hakbang ng pag-alis: aling key, aling tuntunin o aling ruta ang nawawala kapag natapos ang access, at sino ang nagsasagawa nito.

Nagtatapos ang paglalakbay sa lugar kung saan ito nagsimula, sa serbisyo. Piliin ang hangganang sumasaklaw sa tunay na trapiko at nagbe-verify sa mga kapares na nilayon mong i-verify, pagkatapos ay isulat kung paano ina-update, mino-monitor at tinatanggal ang access. Sanggunian ng OpenSSH ang lugar upang kumpirmahin ang mga opsyon sa pagpapasa bago mangako ng makitid na kontrata. Kung hindi mo maipaliwanag ang hakbang ng pag-alis sa isang pangungusap, mas malaki ang hangganan kaysa sa problema.