AWS Client VPN taisyklės priklauso ištekliui, o ne potinkiui

Darbuotojams reikia pasiekti vieną programą VPC, o ne duomenų bazės klausytoją toje pačioje instancijoje, todėl kas nors prideda antrą viešą potinkį VPN endpoint ir paskelbia reikalavimą įvykdytu. Potinkio vieta keičia maršrutizavimą ir prieinamumą. Jis nesuteikia ir neatima nė vieno prievado. Reikalavimą išreiškiantis leidimas yra paskirties vietoje, išteklio saugos grupėje, o VPN riba suteikia rankeną, į kurią nurodo ši taisyklė.

Potinkio vieta yra maršrutizavimas, o ne autorizacija

Tai, kur yra endpoint tinklo susiejimas, nulemia, kuri maršrutų lentelė neša kliento srautą ir kurios prieinamumo zonos atlaiko gedimą. Tai nieko nesako apie tai, į kurį prievadą kurioje instancijoje tas srautas gali patekti. Du klientai, susieti su tuo pačiu potinkiu, vis tiek ateina su ta pačia šaltinio tapatybe, o išteklius negali jų atskirti pagal potinkio pavadinimą.

Pradėkite nuo reikalavimo: kas skambina, kuris išteklius, kuris paslaugos prievadas ir kuri kryptis. Tada pasirinkite taisyklės modelį, galintį išreikšti tuos keturis dalykus paskirties vietoje. Toks požiūris paprastai visiškai pašalina papildomą potinkį iš projekto.

Client VPN susiejimo grupė yra ta rankena

Su potinkiu susietam AWS Client VPN endpoint dokumentuota tvarka yra konkreti. Taikykite numatytą saugos grupę endpoint tikslinio tinklo susiejimams, tada leiskite reikiamą srautą išteklio saugos grupėje, naudodami tą Client VPN grupę kaip šaltinį.

Konkrečiai, programos instancijos grupė leidžia programos prievadą iš susiejimo grupės ir nieko daugiau. AWS ištekliaus prieigos procedūra aprašo šį ryšį, ir verta išlaikyti tą pačią grupės politiką kiekviename potinkyje, su kuriuo susiejamas endpoint, nes pasenęs susiejimas su kita grupe tyliai praplečia ribą.

Ta taisyklė nieko neautentifikuoja. Prisijungimas yra atskira kontrolė, o kelias iki ištekliaus yra trečias. Visi trys turi galioti prieš atvykstant užklausai. Kuri nepavyksta, nulemia, kuri pataisa yra teisinga, o taisyklės keitimas yra teisingas atsakymas tik pirmajai.

Ko viena susiejimo grupė negali atskirti

Kiekvienas klientas už tos pačios susiejimo grupės pasiekia išteklių kaip tas pats saugos grupės šaltinis. Du vartotojai su skirtingais vaidmenimis tame sluoksnyje yra neatskiriami, kad ir kaip grupė pavadinta ar pažymėta. Client VPN išorinių grupių autorizacija riboja prieigą pagal paskirties prefiksą katalogo ar SAML grupei, o tai yra grubiau nei ištekliaus vaidmuo ir turėtų būti traktuojama kaip tinklo riba, o ne tapatybės sistema.

Smulkesni skirtumai priklauso programai. Duomenų bazės klausytoją, kuris turi likti uždarytas daugumai darbuotojų, geriau apsaugoti visiškai nepasiekiamu leidžiamame prefikse, nei tikintis, kad grupės narystė išliks tvarkinga.

Grupės pervadinimas nesukuria tapatybės, o jos dubliavimas komandomis tik padaugina susiejimus, kuriuos reikia audituoti.

Nekopijuokite šios taisyklės į kiekvieną VPN projektą

Savarankiškai valdoma EC2 VPN tinklo vartų, maršrutizuotas patikros įrenginys ir valdomas Client VPN yra trys skirtingi paketų keliai. Nustatykite, kuris šaltinio adresas iš tikrųjų pasiekia išteklių, ar kelyje atliekamas vertimas ir kokius nuorodų mechanizmus paslauga palaiko tame kelyje.

Srauto perdavimas per tarpinį įrenginį neišsaugo šaltinio saugos grupės nuorodos taip, kaip tai daro tiesioginis instancijų tarpusavio srautas. AWS dokumentuoja, kad tokiems projektams gali prireikti atitinkamų privačių šaltinio adresų arba CIDR vietoj grupės nuorodos. Valdomo Client VPN procedūra nėra įrodymas, kad kiekvienų vartų prijungta grupė veikia kaip universali tapatybės žymė perduodamiems paketams.

Vieno NAT šuolio kelyje pakanka prielaidai sugriauti, o gedimas atrodo kaip taisyklė, kuri egzistuoja, bet niekada nesutampa.

Peržiūrėkite veiksmingą ribą

Perskaitykite kiekvieną su ištekliu susietą saugos grupę, nes leidimo taisyklės sumuojasi ir siaura taisyklė nepanaikina platesnės kitoje grupėje. Tada patikrinkite tinklo ACL, pagrindinio kompiuterio užkardą ir pačios programos autorizaciją, kurie yra atskiri sluoksniai su atskiromis klaidomis.

Užbaikite viena leidžiama ir viena sąmoningai atmesta užklausa tam pačiam ištekliui. Ši pora įrodo ribą, o vienas sėkmingas ryšys įrodo tik tai, kad kažkas atvira. Patvirtinkite maršrutą, veiksmingą šaltinį ir numatytą paslaugos prievadą, o ne potinkį, kuriame yra endpoint.

Darbo tvarka: parašykite keturių dalių reikalavimą, prijunkite grupę prie susiejimų, susiaurinkite ištekliaus taisyklę iki prievado, patikrinkite vieną leidimą ir vieną atmetimą, ir tik tada svarstykite potinkių skaidymą dėl maršrutizavimo.