AWS Client VPN noteikumi pieder resursam, nevis apakštīklam

Darbiniekiem jāsasniedz viena lietotne VPC un nav jāsasniedz datubāzes klausītājs tajā pašā instancē, tāpēc kāds pievieno otru publisku apakštīklu VPN galapunktam un pasludina prasību izpildītu. Apakštīkla novietojums maina maršrutēšanu un pieejamību. Tas nepiešķir un neatsaka nevienu portu. Atļauja, kas izsaka prasību, atrodas galamērķī, resursa drošības grupā, un VPN robeža nodrošina rokturi, uz kuru šis noteikums atsaucas.

Apakštīkla novietojums ir maršrutēšana, nevis autorizācija

Tas, kur atrodas galapunkta tīkla asociācija, nosaka, kura maršrutu tabula pārvadā klientu satiksmi un kuras pieejamības zonas pārdzīvo kļūmi. Tas neko nepasaka par to, uz kuru portu kurā instancē šī satiksme var nokļūt. Divi klienti, kas asociēti ar vienu un to pašu apakštīklu, joprojām ierodas ar vienu un to pašu avota identitāti, un resurss nevar tos atšķirt pēc apakštīkla nosaukuma.

Sāciet ar prasību: kas zvana, kurš resurs, kurš pakalpojuma ports un kurš virziens. Pēc tam izvēlieties noteikuma modeli, kas spēj izteikt šīs četras lietas galamērķī. Šāda pieeja parasti pilnībā izņem papildu apakštīklu no projekta.

Client VPN asociācijas grupa ir tas rokturis

Apakštīklam piesaistītam AWS Client VPN galapunktam dokumentētā kārtība ir konkrēta. Piemērojiet paredzēto drošības grupu galapunkta mērķa tīkla asociācijām, pēc tam atļaujiet nepieciešamo satiksmi resursa drošības grupā, izmantojot šo Client VPN grupu kā avotu.

Konkrēti, lietotnes instances grupa atļauj lietotnes portu no asociācijas grupas un neko citu. AWS resursa piekļuves procedūra apraksta šīs attiecības, un ir vērts saglabāt to pašu grupas politiku katrā apakštīklā, ar kuru galapunkts asociējas, jo novecojusi asociācija ar citu grupu klusi paplašina robežu.

Šis noteikums nevienu neautentificē. Pieteikšanās ir atsevišķa kontrole, un ceļš uz resursu ir trešais. Visiem trim jābūt spēkā, pirms pienāk pieprasījums. Kurš no tiem neizdodas, tas nosaka, kurš labojums ir pareizs, un noteikuma maiņa ir pareizā atbilde tikai pirmajam.

Ko viena asociācijas grupa nevar atšķirt

Katrs klients aiz vienas un tās pašas asociācijas grupas sasniedz resursu kā viens un tas pats drošības grupas avots. Divi lietotāji ar atšķirīgām lomām šajā slānī nav atšķirami, lai kā grupa būtu nosaukta vai atzīmēta. Client VPN ārējo grupu autorizācija ierobežo piekļuvi pēc galamērķa prefiksa direktorija vai SAML grupai, kas ir rupjāk nekā resursa loma un jāuzskata par tīkla robežu, nevis identitātes sistēmu.

Smalkākās atšķirības pieder lietotnei. Datubāzes klausītāju, kam jāpaliek slēgtam lielākajai daļai darbinieku, labāk aizsargāt, ja tas vispār nav sasniedzams atļautajā prefiksā, nekā cerēt, ka grupas dalība paliks kārtīga.

Grupas pārdēvēšana neveido identitāti, un tās dublēšana pa komandām tikai vairo asociācijas, kas jāauditē.

Nekopējiet šo noteikumu katrā VPN projektā

Pašpārvaldīts EC2 VPN vārteja, maršrutēta pārbaudes iekārta un pārvaldīts Client VPN ir trīs dažādi pakešu ceļi. Nosakiet, kura avota adrese faktiski sasniedz resursu, vai pa ceļam notiek tulkošana un kādus atsauces mehānismus pakalpojums atbalsta šajā ceļā.

Satiksmes pārvirzīšana caur starpierīci nesaglabā avota drošības grupas atsauci tā, kā to dara tieša instance-uz-instances satiksme. AWS dokumentē, ka šādiem projektiem grupas atsauces vietā var būt vajadzīgas atbilstošas privātās avota adreses vai CIDR. Pārvaldītā Client VPN procedūra nav pierādījums, ka katras vārtejas piesaistītā grupa darbojas kā universāla identitātes zīme pārsūtītajām paketēm.

Viens NAT lēciens ceļā ir pietiekams, lai salauztu pieņēmumu, un kļūme izskatās kā noteikums, kas pastāv, bet nekad nesakrīt.

Pārskatiet faktisko robežu

Izlasiet katru resursam piesaistīto drošības grupu, jo atļaušanas noteikumi summējas un šaurs noteikums neatceļ plašāku citā grupā. Pēc tam pārbaudiet tīkla ACL, resursdatora ugunsmūri un pašas lietotnes autorizāciju, kas ir atsevišķi slāņi ar atsevišķām kļūdām.

Pabeidziet ar vienu atļautu un vienu apzināti izslēgtu pieprasījumu pret to pašu resursu. Šis pāris pierāda robežu, savukārt viens veiksmīgs savienojums pierāda tikai to, ka kaut kas ir atvērts. Apstipriniet maršrutu, faktisko avotu un paredzēto pakalpojuma portu, nevis apakštīklu, kas satur galapunktu.

Darbu secība: uzrakstiet četrdaļīgo prasību, piesaistiet grupu asociācijām, ierobežojiet resursa noteikumu ar portu, pārbaudiet vienu atļauju un vienu liegumu, un tikai pēc tam apsveriet apakštīklu sadalīšanu maršrutēšanas dēļ.