Ang mga patakaran ng AWS Client VPN ay nasa resource, hindi sa subnet

Kailangang maabot ng kawani ang isang application sa VPC at hindi dapat maabot ang database listener sa parehong instance, kaya may nagdaragdag ng ikalawang pampublikong subnet para sa endpoint ng VPN at sinasabing natugunan ang pangangailangan. Binabago ng lokasyon ng subnet ang routing at availability. Hindi ito nagbibigay o nag-aalis ng kahit isang port. Ang pahintulot na nagpapahayag ng pangangailangan ay nasa destinasyon, sa security group ng resource, at ang hangganan ng VPN ay nagbibigay ng hawakan na tinutukoy ng patakarang iyon.

Ang lokasyon ng subnet ay routing, hindi awtorisasyon

Kung saan naroroon ang network association ng endpoint ang nagtatakda kung aling route table ang nagdadala ng trapiko ng kliyente at aling availability zone ang nakakaligtas sa pagkabigo. Wala itong sinasabi tungkol sa kung aling port sa aling instance ang maaaring maabot ng trapikong iyon. Dalawang kliyenteng naka-associate sa parehong subnet ay dumarating pa rin na may parehong source identity, at hindi sila maaaring paghiwalayin ng resource sa pamamagitan ng pangalan ng subnet.

Magsimula sa pangangailangan: sino ang tumatawag, aling resource, aling service port at aling direksyon. Pagkatapos piliin ang modelong patakaran na makapagpapahayag ng apat na bagay na iyon sa destinasyon. Karaniwang inaalis ng balangkas na iyon ang dagdag na subnet mula sa disenyo.

Ang association group ng Client VPN ang hawakan

Para sa endpoint ng AWS Client VPN na naka-associate sa subnet, ang dokumentadong kaayusan ay tiyak. Ilapat ang nilalayong security group sa mga target-network association ng endpoint, pagkatapos ay payagan ang kinakailangang trapiko sa security group ng resource gamit ang grupong Client VPN na iyon bilang source.

Sa kongkreto, pinapayagan ng grupo ng application instance ang application port mula sa association group, at wala nang iba. Inilalarawan ng proseso ng pag-access sa resource ng AWS ang ugnayang iyon, at sulit na panatilihin ang parehong patakaran ng grupo sa bawat subnet na ina-associate ng endpoint, dahil ang lumang association sa ibang grupo ay tahimik na nagpapalawak ng hangganan.

Hindi nagpapatunay ng sinuman ang patakarang iyon. Ang pag-log in ay hiwalay na kontrol, at ang ruta patungo sa resource ay pangatlo. Dapat maging totoo ang tatlo bago dumating ang isang kahilingan. Alin ang mabibigo ang nagtatakda kung aling pagwawasto ang tama, at ang pagbabago ng patakaran ay tamang sagot para lamang sa una.

Ang hindi kayang paghiwalayin ng isang association group

Bawat kliyenteng nasa likod ng parehong association group ay umaabot sa resource bilang parehong source ng security group. Dalawang user na may magkaibang role ay hindi mapaghiwalay sa antas na iyon, anuman ang pangalan o tag ng grupo. Ang awtorisasyon ng panlabas na grupo ng Client VPN ay naglilimita ng access ayon sa destination prefix para sa directory o SAML group, na mas magaspang kaysa role ng resource at dapat ituring na hangganan ng network, hindi sistema ng identity.

Ang mas pinong pagkakaiba ay pag-aari ng application. Ang database listener na dapat manatiling sarado sa karamihan ng kawani ay mas mahusay na protektado sa pamamagitan ng hindi ito maabot sa pinapayagang prefix kaysa sa umasa na mananatiling maayos ang membership sa grupo.

Ang pagpapalit ng pangalan ng grupo ay hindi lumilikha ng identity, at ang pagkopya nito bawat team ay nagpaparami lamang ng mga association na dapat i-audit.

Huwag kopyahin ang patakarang iyon sa bawat disenyo ng VPN

Ang self-managed EC2 VPN gateway, routed inspection appliance at managed Client VPN ay tatlong magkaibang packet path. Tukuyin kung aling source address ang aktwal na umaabot sa resource, kung may translation sa pagitan, at aling reference mechanism ang sinusuportahan ng serbisyo sa path na iyon.

Ang pagpapasa ng trapiko sa pamamagitan ng middlebox ay hindi nagpapanatili ng source security-group reference tulad ng ginagawa ng direktang instance-to-instance na trapiko. Dokumentado ng AWS na ang gayong disenyo ay maaaring mangailangan ng naaangkop na pribadong source address o CIDR sa halip na group reference. Ang pamamaraan ng managed Client VPN ay hindi patunay na ang nakakabit na grupo ng bawat gateway ay gumagana bilang universal identity token para sa mga ipinadalang packet.

Sapat na ang isang NAT hop sa path upang sirain ang palagay, at ang pagkabigo ay mukhang patakarang naroroon ngunit hindi kailanman tumutugma.

Suriin ang epektibong hangganan

Basahin ang bawat security group na nakakabit sa resource, dahil nagsasama-sama ang mga allow rule at ang makitid na patakaran ay hindi kinakansela ang mas malawak sa ibang grupo. Pagkatapos suriin ang network ACL, host firewall at sariling awtorisasyon ng application, na magkaibang layer na may magkaibang pagkakamali.

Tapusin sa isang pinapayagang kahilingan at isang sadyang ibinukod na kahilingan laban sa parehong resource. Ang pares ay nagpapatunay ng hangganan, samantalang ang isang matagumpay na koneksyon ay nagpapatunay lamang na may bukas. Kumpirmahin ang ruta, ang epektibong source at ang nilalayong service port, hindi ang subnet na naglalaman ng endpoint.

Pagkakasunod-sunod ng trabaho: isulat ang apat-na-bahaging pangangailangan, ikabit ang grupo sa mga association, limitahan ang patakaran ng resource sa port, i-verify ang isang pagpayag at isang pagtanggi, at pagkatapos lamang isaalang-alang ang paghahati ng subnet dahil sa routing.