Anna VPN-käyttäjille pääsy yhteen palveluun, älä aliverkkoon

Urakoitsija tarvitsee yhden sisäisen verkkosovelluksen eikä mitään muuta, ja helppo vastaus on antaa hänelle tunneli palvelimen aliverkkoon. Se toimii siihen päivään asti, jolloin hän skannaa sen. Kapeampi suunnittelu vaatii enemmän ajattelua, koska tavoitettavuus, reititys ja sovelluksen lupa ovat kolme erillistä valvontaa, joiden on oltava yhtä mieltä.

Kirjoita vaatimus palveluna, älä aliverkkona

Aloita kohdeisännästä, protokollasta ja portista ja lisää sitten käyttäjä- tai laiteryhmä, jonka pitäisi päästä siihen. Sisällytä yksityinen DNS-vyöhyke vain, jos sovellus ratkaisee nimen, ja sisällytä identiteetintarjoaja vain, jos kirjautumisvirta tarvitsee sitä. Kaikki muu on riippuvuus, jota et ole vielä perustellut.

Aliverkko on verkkotiimin toteutusyksityiskohta, kun taas palvelu on se, mitä liiketoiminta pyysi, ja yksikkö, joka voidaan tarkastaa ja poistaa käytöstä.

Jos riippuvuusluettelo kasvaa yli kolmen kohteen, sovellus tarvitsee todennäköisesti oman suunnittelukeskustelun.

Reititä kapeasti, mutta valvo muualla

Kapea reitti tai valitsin kertoo tunnelille, mitkä paketit se kuljettaa; se ei ole valtuutuskäytäntö. Yhdyskäytävän suodatin, kohdeisännän palomuuri ja sovelluksen oma lupamalli ovat paikkoja, joissa pääsystä päätetään. Yhden osoitteen kattava reitti on hyvä alku, eikä se ole valvonta, joka pysäyttää päättäväisen käyttäjän. Juuri tämä erottelu mahdollistaa suodattimen vaihtamisen tunnelia uudelleen suunnittelematta.

Päinvastoin, laaja reitti tiukalla suodattimella voi olla laillinen, mutta vain jos kaikki osalliset tietävät, kumpi niistä valvoo.

Dokumentoi valvontapiste nimenomaisesti, muuten seuraava muutos siirtää sen vahingossa.

Tarkista lähde, jonka palvelu todella näkee

Kohde näkee joko asiakkaan pooliosoitteen tai yhdyskäytävän osoitteen riippuen siitä, käännätkö. Isännän palomuurisäännöt ja lokit on sovitettava todelliseen lähteeseen. Jos useat käyttäjät jakavat käännetyn lähteen, mikään käyttäjäkohtainen sääntö kyseisellä isännällä ei voi erottaa heitä, ja se on suunnittelurajoitus, ei virhe.

Valitse käännös tarkoituksella: se yksinkertaistaa reititystä ja tuhoaa lähteen identiteetin, millä on merkitystä auditoinnille ja käyttäjäkohtaisille säännöille.

Kirjoita muistiin, kumman kahdesta valitsit, sen säännön viereen, joka siitä riippuu.

Sovelluksen valtuutus ei ole valinnainen

Porttiin pääseminen ei anna roolia. Sovellus tarvitsee edelleen oman kirjautumisensa ja omat lupansa, koska verkkokerros ei voi ilmaista, mitä tietueita käyttäjä saa muokata. Palvelu, joka luottaa kaikkiin sisäisestä aliverkosta tuleviin pyyntöihin, muuttaa kapean tunnelin täydelliseksi pääsyksi yhdelle vaarantuneelle tunnukselle. Tunneli päättää, kuka saa avata pistokkeen, ja sovellus päättää, mitä sillä saa tehdä.

Tässä kapea suunnittelu maksaa itsensä takaisin kahdesti, koska vähemmän tavoitettavia isäntiä tarkoittaa vähemmän paikkoja, joissa sovellustason virhettä voi hyödyntää.

Pidä verkkosääntö ja sovelluksen rooli erillisissä järjestelmissä ja poista ne käytöstä erikseen.

Todista sekä sallittu että estetty polku

Yhdistä valtuutettuna käyttäjänä ja suorita yksi vaaraton edustava toimenpide, yritä sitten kohdetta, jonka pitäisi olla tavoittamaton. Suunnittelu, joka testaa vain ensimmäisen puoliskon, ei ole testattu, ja estetty testi on se, joka todistaa suunnittelun. Testaa tuore istunto jokaisen sääntömuutoksen jälkeen ja katso paluupolkua, jos pyynnöt saapuvat mutta vastaukset eivät.

Älä poista edelleenlähetyssuodattimia käytöstä, jotta hyväksymistesti menisi läpi, koska se muuttaa testattavaa asiaa.

Kun käyttäjä ei enää tarvitse palvelua, poista etätunniste ja sovelluksen rooli niiden omissa järjestelmissä ja kirjaa molemmat. strongSwanin edelleenlähetysopas kattaa polun yhdyskäytäväpuolen.