Akses nga VPN në VLAN: ndërto matricën para rregullave
Role nga njëra anë, shërbime nga ana tjetër. Pesë kontrolle e kthejnë një projekt të paqartë aksesi nga VPN në VLAN në një tabelë që pronari i firewall-it mund ta zbatojë.
Filloni me matricën, jo me sintaksën e firewall-it. Një tabelë me role nga njëra anë dhe shërbime nga ana tjetër mund të rishikohet nga pronari i një aplikacioni, të diskutohet nga pronari i sigurisë dhe të zbatohet nga kushdo që mban portën. Ai rishikim kushton më pak se korrigjimi i rregullave për të cilat askush nuk është marrë vesh.
Një orë shkrim kursen më vonë një javë arkeologji rregullash. Dizajni flet për atë se kush arrin në cilën shërbim, dhe pikërisht kjo pjesë i mbijeton rinumërimit.
Hapi 1: emërtoni rolet para rrjeteve
Filloni nga njerëzit, jo nga switch-i. Shkruani çdo grup që lidhet në distancë dhe fjalinë e vetme që përshkruan çfarë bën ai grup, për shembull personeli i magazinës që lexon nivelet e stokut ose një kontraktor që mirëmban një integrim. Nëse dy grupe do të merrnin të njëjtin akses, për këtë qëllim janë një rol.
Ndaleni këtu nëse një rol ekziston vetëm për shkak të një organigrame. Një rol pa nevojë të vetën për shërbim bëhet një rresht qelizash identike, dhe rreshtat identikë nxisin dikë më vonë të japë një nënrrjet të tërë për lehtësi. Ndani sipas asaj që bëjnë njerëzit, jo sipas kujt nënshkruan shpenzimet e tyre. Gjashtë role janë zakonisht shumë për një zyrë të vogël dhe tre shpesh janë të saktë.
Hapi 2: kthejeni çdo qelizë në një deklarim shërbimi
Një qelizë që thotë «Aplikacione» nuk është e verifikueshme. Një qelizë që thotë «HTTPS te hosti ERP në 443, nga grupi i personelit» është. Zëvendësoni çdo emër rrjeti me një destinacion, një protokoll dhe një portë, pastaj shtoni varësinë pa të cilën shërbimi nuk funksionon, si zgjidhësi i brendshëm ose ofruesi i identitetit.
| Check | Passes when | Stop if |
|---|---|---|
| Destination named | Host and port appear in the cell | Cell names a VLAN or a subnet |
| Direction stated | Initiator and responder are both clear | Cell implies two-way access |
| Dependency listed | DNS or identity path is explicit | Whole infrastructure range is granted |
| Negative case written | At least one denied pair is recorded | Only allow rules exist |
Kolona e drejtimit kap gabimet më të shtrenjta. Leja që personeli të hapë një aplikacion nuk nënkupton leje që serverat e aplikacionit të hapin lidhje kthimi te laptopët e personelit, dhe një rregull me gjendje që lejon drejtimin e parë shpesh lexohet sikur lejon të dytin.
Hapi 3: vendosni ku identiteti bëhet politikë
Dikush duhet të kthejë një sesion të vërtetuar në një rol që porta mund ta zbatojë. Opsionet e mbështetura përfshijnë politikën e grupit të dhënë nga backend-i i vërtetimit, atributet e besueshme të sesionit ose grupe adresash të veçanta për çdo rol. Të tre funksionojnë; një etiketë e dërguar nga klienti jo. Zgjidhni mekanizmin që dokumenton porta juaj, jo atë që përshkruan një postim në forum.
Caktimi i një adrese që thjesht duket se i përket një VLAN është i njëjti mos-përgjigje në një kostum tjetër. Udhëzuesi i Netgate për rregullat e firewall-it të OpenVPN e bën të qartë ndarjen: lejimi që tuneli të ngrihet është një vendim tjetër nga lejimi që trafiku të kalojë përmes tij.
Shkruani cilin mekanizëm zgjodhët dhe ku është konfiguruar. Kur një rol ndryshon, ai shënim është ndryshimi midis një redaktimi dhe një gjuetie nëpër tre ndërfaqe. Ai i thotë gjithashtu një audituesi ku duhet të shohë së pari.
Hapi 4: vëzhgoni adresën burimore që sheh destinacioni
Politika e përcjelljes duhet të përputhet me burimin e vërtetë në kufi. Nëse porta përkthen klientët VPN në adresën e vet, çdo firewall në rrjedhën e poshtme sheh një burim të vetëm dhe humbet aftësinë për të vendosur sipas rolit. Nëse e ruan adresën e klientit, rruga e kthimit duhet të ekzistojë për atë grup.
Provoni të dy drejtimet para se të shkruani rregullat përfundimtare, pastaj shënoni burimin e vëzhguar pranë çdo qelize. Ekzekutoni të njëjtin kontroll nga dy role të ndryshme dhe krahasoni rezultatin. Nëse të dyja tregojnë adresën e portës, dallimi i roleve tashmë është humbur. Një matricë që supozon adresa të ruajtura ndërsa porta bën përkthim burimi dështon në ACL-në e parë të poshtme.
Hapi 5: provoni çdo qelizë para se ta publikoni
Kthejeni çdo qelizë të lejuar në një operacion përfaqësues dhe çdo qelizë të refuzuar në një rast negativ. Ekzekutoni të dyja nga një klient në rolin e vërtetë, jo nga konsola e portës, sepse konsola anashkalon rrugën që po provoni.
# allowed: staff role reaches the ERP endpoint
curl -sS -o /dev/null -w '%{http_code}\n' --max-time 5 https://erp.internal.example/health
# denied: the same role must not reach a management host
nc -vz -w 3 10.30.5.11 22
# observed source address at the destination
sudo tcpdump -ni any 'tcp port 443 and host 10.30.20.15'Një rast negativ që lidhet është një gjetje, jo një rastësi, dhe vendi i tij është në matricë si një qelizë e dështuar derisa rregulli të korrigjohet. Mbani komandat e provës pranë tabelës, që rishikuesi tjetër t'i ekzekutojë përsëri në vend që ta rindërtojë arsyetimin.
Tabela e përfunduar mbijeton më shumë se porta për të cilën u shkrua. Rregullat ndryshojnë me firmware dhe furnizues, ndërsa rreshti që thotë se një kontraktor arrin në një shërbim projekti mbetet i vërtetë derisa ai punë të ndryshojë.