Pravilo EC2 samo za VPN: vsaka pripeta varnostna skupina se mora strinjati

Dodate eno vhodno pravilo za bazen odjemalcev VPN, ničesar ne odstranite, storitev pa je še vedno dosegljiva z interneta. Nič ni pokvarjeno. Varnostna skupina nima prepisa, prioritete ali končne zavrnitve, proti kateri bi ozko pravilo lahko zmagalo. Vsaka skupina, pripeta k instanci, prispeva svoja dovoljenja v en združen nabor, in široko pravilo, ki ste ga pozabili, je še vedno v tem naboru. Narediti instanco samo-VPN pomeni revidirati vse, ne pa dodati bolje zveneče pravilo eni od njih.

Zapišite storitev, preden napišete pravilo

Začnite s točnim ciljem, protokolom in vrati ter omrežnim vmesnikom, na katerem storitev v resnici posluša. Instanca z več vmesniki ali več storitvami na enem vratih zahteva revizijo za vsak vmesnik, ker se pripete skupine lahko razlikujejo. Nato ugotovite kateri naslov vira ta vmesnik v resnici prejme za uporabnika VPN, ne pa naslova, ki ga odjemalec prikaže v svojem oknu povezave.

Ta dva naslova se razhajata pogosteje, kot ljudje pričakujejo, ko vstopita prevajanje in usmerjanje.

Trije modeli vira, tri različna pravila

Pri zasebnem usmerjenem dostopu instanca prejme bazen odjemalcev ali korporativni obseg, odvisno od tega, kako je pot usmerjena in prevedena. Pri javni končni točki, doseženi prek korporativnega izhoda, instanca namesto tega vidi korporativni naslov NAT, in to le, če ta cilj v resnici uporablja pot VPN, saj lahko razdeljeno tuneliranje ostane na domači povezavi. Pri upravljani končni točki Client VPN velja dokumentirani model povezave in ciljnega omrežja, naslov odjemalca pa izhaja iz nastavljenega CIDR odjemalca.

Kar ne deluje, je sklicevanje na prehod VPN kot vir varnostne skupine. Sklici na skupine se ujemajo z elastičnimi omrežnimi vmesniki znotraj VPC ali povezanega omrežja, prehod, ki posreduje pakete, pa ni eden od njih.

Preberite unijo po vseh pripetih skupinah

Odprite instanco, poiščite njen omrežni vmesnik in naštete vsako varnostno skupino, pripeto nanjo. Za vsako preverite vsako pravilo, ki pokriva vaš protokol in vrata, vključno s širokimi obsegi vrat in obema družinama naslovov. Pravilo IPv4 z 0.0.0.0/0 vas ne odveže preverjanja ::/0, pravilo, ki dovoljuje ves promet, pa popolnoma skrije vprašanje vrat. Šele po tem popisu lahko rečete, kakšno je dejansko dovoljenje za storitev.

Referenca pravil AWS opisuje varnostne skupine kot samo-dovoljujoče in navaja, da se pravila vseh pripetih skupin združijo, in to je celoten mehanizem za to napako.

Omrežni ACL so ločena politika brez stanja z urejenimi vnosi dovoljenja in zavrnitve, in se ocenjujejo na podomrežju, ne na instanci.

Ne odgovarjajte z zidom zavrnitev

Dodajanje zavrnitve NACL za celotno podomrežje, da bi posnemali požarni zid, ki ste ga vajeni, je napačno orodje in tvegano. Vnosi NACL so urejeni in brez stanja, zato zavrnitev nad obstoječim dovoljenjem tiho prekine nepovezan promet, vključno s povratno potjo za seje, ki ste jih poskušali obdržati. Popravite široko dovoljenje varnostne skupine v skupini, ki ga ima, in nato pustite ACL pri miru, razen če je res del zasnove.

Odstranitev javnega naslova z instance je močnejše zagotovilo, in je tudi arhitekturna sprememba z upravnimi in aplikativnimi posledicami, ne pa kljukica na seznamu dovoljenj.

Preizkusite z novo sejo in obdržite pot noter

Preden umaknete katero koli obstoječe dovoljenje, potrdite odobreno neodvisno upravno pot, ker je pravilo, ki ga boste izbrisali, morda tisto, od katerega je odvisno obnavljanje vaše seje. Nato preizkusite novo dovoljeno povezavo z VPN in novo zavrnjeno povezavo z odobrene preskusne poti brez VPN. Obstoječe sledene seje preživijo spremembe pravil na načine, ki naredijo stare odprte lupine neuporabne kot dokaz sprejetja.

Na koncu ohranite lastno avtorizacijo aplikacije. Prevedeni korporativni izhod lahko predstavlja na stotine ljudi, omrežni vstop pa nikoli ni identificiral posameznega uporabnika ali njegove naprave.