Pravila AWS Client VPN pripadaju resursu, a ne podmreži

Osoblju treba pristup jednoj aplikaciji u VPC-u i ne smije pristupati slušatelju baze podataka na istoj instanci, pa netko doda drugu javnu podmrežu za VPN endpoint i proglasi zahtjev ispunjenim. Položaj podmreže mijenja usmjeravanje i dostupnost. On ne daje niti uskraćuje ijedan port. Dopuštenje koje izražava zahtjev živi na odredištu, u sigurnosnoj grupi resursa, a VPN granica daje ručku na koju se to pravilo odnosi.

Položaj podmreže je usmjeravanje, ne autorizacija

Gdje se nalazi mrežno pridruživanje endpointa odlučuje koja tablica usmjeravanja nosi promet klijenata i koje zone dostupnosti preživljavaju kvar. To ne govori ništa o tome koji port na kojoj instanci taj promet može dosegnuti. Dva klijenta pridružena istoj podmreži dolaze s istim identitetom izvora, a resurs ih ne može razlikovati po imenu podmreže.

Umjesto toga počnite od zahtjeva: tko poziva, koji resurs, koji servisni port i koji smjer. Zatim odaberite model pravila koji može izraziti te četiri stvari na odredištu. Taj okvir obično potpuno uklanja dodatnu podmrežu iz dizajna.

Grupa pridruživanja Client VPN je ručka

Za AWS Client VPN endpoint pridružen podmreži dokumentirani raspored je konkretan. Primijenite predviđenu sigurnosnu grupu na mrežna pridruživanja ciljne mreže endpointa, zatim dopustite potreban promet u sigurnosnoj grupi resursa rabeći tu Client VPN grupu kao izvor.

Konkretno, grupa instance aplikacije dopušta aplikacijski port iz grupe pridruživanja i ništa drugo. AWS-ov postupak pristupa resursu opisuje taj odnos i vrijedi zadržati istu politiku grupe na svakoj podmreži s kojom se endpoint pridružuje, jer zastarjelo pridruživanje s drugom grupom tiho širi granicu.

To pravilo nikoga ne autentificira. Prijava je zasebna kontrola, a ruta do resursa je treća. Sve tri moraju vrijediti prije nego zahtjev stigne. Koja god zakaže, određuje koja je ispravka točna, a promjena pravila pravi je odgovor samo za prvu.

Što jedna grupa pridruživanja ne može razlikovati

Svaki klijent iza iste grupe pridruživanja doseže resurs kao isti izvor sigurnosne grupe. Dva korisnika s različitim ulogama nerazlučiva su na tom sloju, bez obzira kako je grupa nazvana ili označena. Autorizacija vanjskih grupa u Client VPN ograničava pristup po prefiksu odredišta za grupu imenika ili SAML, što je grublje od uloge resursa i treba ga tretirati kao mrežnu granicu, a ne kao sustav identiteta.

Finije razlike pripadaju aplikaciji. Slušatelj baze podataka koji mora ostati zatvoren za većinu osoblja bolje je zaštititi tako da uopće nije dostupan na dopuštenom prefiksu nego nadati se da će članstvo u grupi ostati uredno.

Preimenovanje grupe ne stvara identitet, a umnožavanje po timovima samo povećava broj pridruživanja koja treba revidirati.

Ne kopirajte to pravilo u svaki VPN dizajn

Samostalno vođen EC2 VPN gateway, usmjereni inspekcijski uređaj i upravljani Client VPN tri su različita puta paketa. Utvrdite koja adresa izvora zapravo doseže resurs, događa li se prijevod na putu i koje mehanizme reference servis podržava na tom putu.

Prosljeđivanje prometa kroz posredni uređaj ne čuva referencu sigurnosne grupe izvora kao izravan promet instanca-na-instancu. AWS dokumentira da takvi dizajni mogu trebati odgovarajuće privatne adrese izvora ili CIDR-ove umjesto reference grupe. Postupak upravljanog Client VPN nije dokaz da priključena grupa svakog gatewaya radi kao univerzalni identitetski token za proslijeđene pakete.

Jedan NAT skok na putu dovoljan je da sruši pretpostavku, a kvar izgleda kao pravilo koje postoji, ali nikad ne odgovara.

Pregledajte efektivnu granicu

Pročitajte svaku sigurnosnu grupu priključenu na resurs, jer se pravila dopuštanja zbrajaju i usko pravilo ne poništava šire na drugoj grupi. Zatim provjerite mrežni ACL, host firewall i vlastitu autorizaciju aplikacije, koji su odvojeni slojevi s odvojenim greškama.

Završite s jednim dopuštenim i jednim namjerno isključenim zahtjevom prema istom resursu. Taj par dokazuje granicu, dok jedna uspješna veza dokazuje samo da je nešto otvoreno. Potvrdite rutu, efektivni izvor i predviđeni servisni port, a ne podmrežu koja sadrži endpoint.

Redoslijed rada: napišite zahtjev od četiri dijela, priključite grupu na pridruživanja, ograničite pravilo resursa na port, provjerite jedno dopuštanje i jedno odbijanje i tek onda razmotrite dijeljenje podmreža zbog usmjeravanja.