Dajte uporabnikom VPN dostop do ene storitve, ne do podomrežja

Izvajalec potrebuje eno interno spletno aplikacijo in nič drugega, lahek odgovor pa je, da mu damo tunel v podomrežje strežnika. To deluje do dneva, ko jo preišče. Ožja zasnova zahteva več razmišljanja, ker so dosegljivost, usmerjanje in dovoljenje aplikacije tri ločene kontrole, ki se morajo ujemati.

Zahtevo zapišite kot storitev, ne kot podomrežje

Začnite s ciljnim gostiteljem, protokolom in vrati, nato dodajte skupino uporabnikov ali naprav, ki mora priti do njega. Zasebno območje DNS vključite le, če aplikacija razreši ime, ponudnika identitete pa le, če ga potrebuje tok prijave. Vse ostalo je odvisnost, ki je še niste utemeljili.

Podomrežje je podrobnost izvedbe omrežne ekipe, medtem ko je storitev tisto, kar je zahtevalo poslovanje, in enota, ki jo je mogoče pregledati in opustiti.

Če seznam odvisnosti preseže tri elemente, aplikacija verjetno potrebuje svoj pogovor o zasnovi.

Usmerjajte ozko, a izvajajte drugje

Ozka pot ali izbirnik pove tunelu, katere pakete naj nosi; to ni politika avtorizacije. Filter prehoda, požarni zid ciljnega gostitelja in lastni model dovoljenj aplikacije so mesta, kjer se odloča o dostopu. Pot, ki pokriva en naslov, je dober začetek in ni kontrola, ki ustavi odločnega uporabnika. Prav ta ločitev omogoča, da filter spremenite brez prenove tunela.

Nasprotno, široka pot s strogim filtrom je lahko legitimna, a le če vsi vpleteni vedo, katera od obeh izvaja nadzor.

Točko izvajanja izrecno dokumentirajte, sicer jo bo naslednja sprememba pomotoma premaknila.

Preverite vir, ki ga storitev resnično vidi

Cilj vidi bodisi naslov iz bazena odjemalca bodisi naslov prehoda, odvisno od tega, ali prevajate. Pravila požarnega zidu gostitelja in dnevniki se morajo ujemati z dejanskim virom. Če si več uporabnikov deli preveden vir, nobeno pravilo na uporabnika na tem gostitelju ne more ločiti med njimi, in to je omejitev zasnove, ne napaka.

Prevajanje izberite namerno: poenostavi usmerjanje in uniči identiteto vira, kar je pomembno za revizijo in pravila na uporabnika.

Zapišite, katero od dveh ste izbrali, ob pravilu, ki je od tega odvisno.

Avtorizacija aplikacije ni neobvezna

Doseganje vrat ne podeli vloge. Aplikacija še vedno potrebuje svojo prijavo in svoja dovoljenja, ker omrežna plast ne more izraziti, katere zapise lahko uporabnik ureja. Storitev, ki zaupa vsaki zahtevi iz notranjega podomrežja, spremeni ozek tunel v popoln dostop za eno kompromitirano poverilnico. Tunel odloči, kdo lahko odpre vtičnico, aplikacija pa odloči, kaj je z njo mogoče storiti.

Tu se ozka zasnova obrestuje dvakrat, ker manj dosegljivih gostiteljev pomeni manj mest, kjer je napako na ravni aplikacije mogoče izkoristiti.

Omrežno pravilo in vlogo aplikacije imejte v ločenih sistemih in ju opustite ločeno.

Dokažite tako dovoljeno kot zavrnjeno pot

Povežite se kot pooblaščeni uporabnik in izvedite eno neškodljivo reprezentativno operacijo, nato poskusite cilj, ki bi moral biti nedosegljiv. Zasnova, ki preizkusi le prvo polovico, ni preizkušena, in prav zavrnjeni test dokaže zasnovo. Po vsaki spremembi pravila preizkusite svežo sejo in poglejte povratno pot, če zahteve pridejo, odgovori pa ne.

Ne onemogočite filtrov posredovanja, da bi sprejemni test uspel, ker to spremeni stvar, ki se preizkuša.

Ko uporabnik storitve ne potrebuje več, opustite oddaljeno identiteto in vlogo aplikacije v njunih sistemih ter zabeležite oboje. Vodnik strongSwan za posredovanje pokriva stran prehoda na tej poti.