VPN:stä VLANiin -pääsy: rakenna matriisi ennen sääntöjä
Roolit yhdellä puolella, palvelut toisella. Viisi tarkistusta muuttaa epämääräisen VPN–VLAN-suunnitelman taulukoksi, jonka palomuurin omistaja voi toteuttaa.
Aloita matriisista, älä palomuurin syntaksista. Taulukon, jossa roolit ovat yhdellä puolella ja palvelut toisella, voi tarkistaa sovelluksen omistaja, siitä voi väitellä turvallisuuden omistaja ja sen voi toteuttaa se, jonka hallussa yhdyskäytävä on. Se tarkistus on halvempaa kuin sellaisten sääntöjen virheenkorjaus, joista kukaan ei sopinut.
Tunti kirjoittamista säästää myöhemmin viikon sääntöarkeologiaa. Suunnitelma kertoo, kuka pääsee mihin palveluun, ja juuri se osa kestää uudelleennumeroinnin.
Vaihe 1: nimeä roolit ennen verkkoja
Aloita ihmisistä, älä kytkimestä. Kirjoita ylös jokainen ryhmä, joka yhdistää etänä, ja yksi lause, joka kuvaa mitä ryhmä tekee, kuten varastotyöntekijät, jotka lukevat varastotasoja, tai urakoitsija, joka ylläpitää yhtä integraatiota. Jos kaksi ryhmää saisi saman pääsyn, ne ovat tässä tarkoituksessa yksi rooli.
Pysähdy tähän, jos rooli on olemassa vain organisaatiokaavion takia. Roolista, jolla ei ole omaa palvelutarvetta, tulee rivi identtisiä soluja, ja identtiset rivit houkuttelevat jotakuta myöhemmin antamaan mukavuuden vuoksi kokonaisen aliverkon. Jaa sen mukaan, mitä ihmiset tekevät, ei sen mukaan, kuka allekirjoittaa heidän kulunsa. Kuusi roolia on pienelle toimistolle yleensä liikaa ja kolme on usein oikein.
Vaihe 2: tee jokaisesta solusta palvelulause
Solu, jossa lukee „Sovellukset“, ei ole testattavissa. Solu, jossa lukee „HTTPS ERP-isäntään portissa 443, henkilöstön poolista“, on. Korvaa jokainen verkon nimi kohteella, protokollalla ja portilla ja lisää sitten riippuvuus, jota ilman palvelu ei toimi, kuten sisäinen nimipalvelin tai identiteetintarjoaja.
| 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 |
Suuntasarake nappaa kalleimmat virheet. Lupa henkilöstölle avata sovellus ei tarkoita lupaa sovelluspalvelimille avata yhteyksiä takaisin henkilöstön kannettaviin, ja tilallinen sääntö, joka sallii ensimmäisen suunnan, luetaan usein toisen suunnan luvaksi.
Vaihe 3: päätä, missä identiteetistä tulee käytäntö
Jonkun on muutettava todennettu istunto rooliksi, jonka yhdyskäytävä voi toteuttaa. Tuetut vaihtoehdot ovat todennuksen taustajärjestelmän toimittama ryhmäkäytäntö, luotetut istuntomääritteet tai roolikohtaiset erilliset osoitepoolit. Kaikki kolme toimivat; asiakkaan lähettämä leima ei toimi. Valitse mekanismi, jonka yhdyskäytäväsi dokumentoi, ei se, jota foorumiviesti kuvaa.
Osoitteen antaminen, joka vain näyttää kuuluvan VLANiin, on sama ei-vastaus toisessa asussa. Netgaten ohje OpenVPN:n palomuurisäännöistä tekee eron selväksi: tunnelin nousemisen salliminen on eri päätös kuin liikenteen päästäminen sen läpi.
Kirjoita muistiin, minkä mekanismin valitsit ja mihin se on määritetty. Kun rooli muuttuu, se muistiinpano on ero yhden muokkauksen ja kolmen käyttöliittymän läpi tehtävän metsästyksen välillä. Se kertoo myös auditorille, mistä katsoa ensin.
Vaihe 4: seuraa lähdeosoitetta, jonka kohde näkee
Edelleenohjauskäytännön on vastattava todellista lähdettä rajalla. Jos yhdyskäytävä kääntää VPN-asiakkaat omaksi osoitteekseen, jokainen alempi palomuuri näkee yhden lähteen ja menettää kyvyn päättää roolikohtaisesti. Jos se säilyttää asiakkaan osoitteen, paluupolun on oltava olemassa sille poolille.
Testaa molemmat suunnat ennen lopullisten sääntöjen kirjoittamista ja kirjaa sitten havaittu lähde jokaisen solun viereen. Aja sama tarkistus kahdesta eri roolista ja vertaa tulosta. Jos molemmat näyttävät yhdyskäytävän osoitteen, roolien erottelu on jo menetetty. Matriisi, joka olettaa säilytetyt osoitteet, kun yhdyskäytävä tekee lähdekäännöstä, epäonnistuu ensimmäisessä alemmassa ACL:ssä.
Vaihe 5: testaa jokainen solu ennen julkaisua
Muuta jokainen sallittu solu yhdeksi edustavaksi toiminnoksi ja jokainen kielletty solu negatiiviseksi tapaukseksi. Aja molemmat asiakkaalta todellisessa roolissa, älä yhdyskäytävän konsolista, koska konsoli ohittaa polun, jota testaat.
# 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'Negatiivinen tapaus, joka yhdistää, on löydös, ei sattuma, ja se kuuluu matriisiin epäonnistuneena soluna, kunnes sääntö korjataan. Pidä testikomennot taulukon vieressä, jotta seuraava arvioija ajaa ne uudelleen sen sijaan että rakentaisi perustelun uudelleen.
Valmis taulukko elää kauemmin kuin yhdyskäytävä, jolle se kirjoitettiin. Säännöt muuttuvat laiteohjelmiston ja toimittajan mukana, mutta rivi, joka sanoo, että urakoitsija pääsee yhteen projektipalveluun, pysyy totena kunnes se työ muuttuu.