Regulile AWS Client VPN aparțin resursei, nu subrețelei

Personalul trebuie să ajungă la o aplicație din VPC și nu trebuie să ajungă la listenerul bazei de date de pe aceeași instanță, așa că cineva adaugă o a doua subrețea publică pentru endpointul VPN și declară cerința îndeplinită. Plasarea subrețelei schimbă rutarea și disponibilitatea. Nu acordă și nu refuză nici un port. Permisiunea care exprimă cerința se află la destinație, în grupul de securitate al resursei, iar granița VPN oferă mânerul la care se referă acea regulă.

Plasarea subrețelei este rutare, nu autorizare

Unde se află asocierea de rețea a endpointului decide ce tabelă de rutare transportă traficul clienților și ce zone de disponibilitate supraviețuiesc unei defecțiuni. Nu spune nimic despre ce port de pe ce instanță poate atinge acel trafic. Doi clienți asociați cu aceeași subrețea sosesc în continuare cu aceeași identitate de sursă, iar resursa nu îi poate distinge după numele subrețelei.

Începeți mai bine de la cerință: cine apelează, ce resursă, ce port de serviciu și ce direcție. Apoi alegeți modelul de regulă care poate exprima aceste patru lucruri la destinație. Această abordare elimină de obicei complet subrețeaua suplimentară din proiect.

Grupul de asociere Client VPN este mânerul

Pentru un endpoint AWS Client VPN asociat unei subrețele, aranjamentul documentat este concret. Aplicați grupul de securitate dorit asocierilor de rețea țintă ale endpointului, apoi permiteți traficul necesar în grupul de securitate al resursei folosind acel grup Client VPN ca sursă.

Concret, grupul instanței aplicației permite portul aplicației din grupul de asociere și nimic altceva. Procedura de acces la resursă a AWS descrie această relație și merită să păstrați aceeași politică de grup pe fiecare subrețea cu care se asociază endpointul, deoarece o asociere veche cu un alt grup lărgește granița în tăcere.

Acea regulă nu autentifică pe nimeni. Autentificarea este un control separat, iar ruta către resursă este a treia. Toate trei trebuie să fie valabile înainte de a sosi o cerere. Care eșuează decide care corecție este corectă, iar schimbarea regulii este răspunsul corect doar pentru prima.

Ce nu poate distinge un singur grup de asociere

Fiecare client din spatele aceluiași grup de asociere ajunge la resursă ca aceeași sursă de grup de securitate. Doi utilizatori cu roluri diferite sunt de nedistins la acel nivel, indiferent cum este numit sau etichetat grupul. Autorizarea grupurilor externe din Client VPN limitează accesul după prefixul destinației pentru un grup de director sau SAML, ceea ce este mai grosier decât un rol de resursă și trebuie tratat ca o graniță de rețea, nu ca un sistem de identitate.

Distincțiile mai fine aparțin aplicației. Un listener de bază de date care trebuie să rămână închis pentru majoritatea personalului este mai bine protejat dacă nu este deloc accesibil pe prefixul permis decât dacă sperăm că apartenența la grup rămâne ordonată.

Redenumirea grupului nu creează o identitate, iar duplicarea lui pe echipe doar înmulțește asocierile care trebuie auditate.

Nu copiați acea regulă în fiecare proiect VPN

Un gateway EC2 VPN auto-gestionat, un echipament de inspecție rutat și un Client VPN gestionat sunt trei căi diferite de pachete. Stabiliți ce adresă de sursă ajunge efectiv la resursă, dacă are loc o traducere pe parcurs și ce mecanisme de referință acceptă serviciul pe acea cale.

Trimiterea traficului printr-un dispozitiv intermediar nu păstrează o referință la grupul de securitate sursă așa cum o face traficul direct între instanțe. AWS documentează că astfel de proiecte pot avea nevoie de adresele private de sursă sau de CIDR-urile adecvate în locul unei referințe de grup. Procedura pentru Client VPN gestionat nu este dovada că grupul atașat fiecărui gateway funcționează ca token de identitate universal pentru pachetele redirecționate.

Un singur salt NAT pe cale este suficient pentru a rupe presupunerea, iar defecțiunea arată ca o regulă care există, dar nu se potrivește niciodată.

Revedeți granița efectivă

Citiți fiecare grup de securitate atașat resursei, deoarece regulile de permisiune se combină, iar o regulă îngustă nu anulează una mai largă de pe alt grup. Apoi verificați ACL-ul de rețea, firewallul gazdei și autorizarea proprie a aplicației, care sunt straturi separate cu greșeli separate.

Încheiați cu o cerere permisă și una exclusă intenționat împotriva aceleiași resurse. Perechea demonstrează granița, în timp ce o singură conexiune reușită demonstrează doar că ceva este deschis. Confirmați ruta, sursa efectivă și portul de serviciu intenționat, nu subrețeaua care conține endpointul.

Ordinea lucrului: scrieți cerința în patru părți, atașați grupul la asocieri, limitați regula resursei la port, verificați o permisiune și un refuz, și abia apoi luați în calcul împărțirea subrețelelor din motive de rutare.