Bigyan ang mga VPN user ng access sa isang serbisyo, hindi sa subnet

Ang isang kontratista ay nangangailangan ng isang panloob na web application at wala nang iba, at ang madaling sagot ay bigyan siya ng tunnel papasok sa subnet ng server. Gumagana iyon hanggang sa araw na i-scan niya ito. Ang mas makitid na disenyo ay nangangailangan ng mas maraming pag-iisip, dahil ang maabot, ruta at pahintulot ng application ay tatlong hiwalay na kontrol na dapat magkasundo.

Isulat ang pangangailangan bilang serbisyo, hindi bilang subnet

Magsimula sa destinasyong host, protocol at port, pagkatapos idagdag ang grupo ng user o device na dapat makarating dito. Isama ang pribadong DNS zone lamang kung ang application ay nagresolba ng pangalan, at isama ang identity provider lamang kung kailangan ito ng daloy ng pag-sign in. Lahat ng iba pa ay dependency na hindi mo pa nabibigyang katwiran.

Ang subnet ay detalye ng pagpapatupad ng network team, samantalang ang serbisyo ay ang hiniling ng negosyo at ang yunit na maaaring suriin at i-retire.

Kung ang listahan ng dependency ay lumampas sa tatlong item, malamang kailangan ng application ang sarili nitong usapan sa disenyo.

Rutahin nang makitid, ngunit ipatupad sa ibang lugar

Ang makitid na ruta o selector ay nagsasabi sa tunnel kung aling mga packet ang dadalhin; hindi ito patakaran ng awtorisasyon. Ang filter ng gateway, firewall ng destinasyong host at sariling modelo ng pahintulot ng application ang mga lugar kung saan napagpasyahan ang access. Ang rutang sumasaklaw sa isang address ay magandang simula, at hindi ito ang kontrol na pumipigil sa determinadong user. Ang paghihiwalay na iyon ang nagpapahintulot sa iyong baguhin ang filter nang hindi nire-redesign ang tunnel.

Sa kabaligtaran, ang malawak na ruta na may mahigpit na filter ay maaaring maging lehitimo, ngunit kung alam lamang ng lahat ng kasangkot kung alin sa dalawa ang nagpapatupad.

Idokumento nang tahasan ang punto ng pagpapatupad, kung hindi ay ililipat ito ng susunod na pagbabago nang hindi sinasadya.

Suriin ang pinagmulan na aktwal na nakikita ng serbisyo

Ang target ay nakikita ang address ng pool ng kliyente o ang address ng gateway, depende kung nagsasalin ka. Dapat tumugma ang mga patakaran ng firewall ng host at mga log sa tunay na pinagmulan. Kung maraming user ang nagbabahagi ng isinaling pinagmulan, walang patakaran kada user sa host na iyon ang makakapagtatangi sa kanila, at ito ay limitasyon ng disenyo, hindi bug.

Piliin ang pagsasalin nang sadya: pinapasimple nito ang ruta at sinisira ang pagkakakilanlan ng pinagmulan, na mahalaga para sa audit at sa mga patakaran kada user.

Isulat kung alin sa dalawa ang pinili mo, sa tabi ng patakarang umaasa dito.

Ang awtorisasyon ng application ay hindi opsyonal

Ang maabot ang isang port ay hindi nagbibigay ng papel. Kailangan pa rin ng application ang sarili nitong login at sarili nitong mga pahintulot, dahil hindi maipahayag ng network layer kung aling mga record ang maaaring i-edit ng user. Ang serbisyong nagtitiwala sa bawat kahilingan mula sa panloob na subnet ay ginagawang buong access ang makitid na tunnel para sa isang kompromisadong kredensyal. Ang tunnel ang nagpapasya kung sino ang maaaring magbukas ng socket, at ang application ang nagpapasya kung ano ang maaaring gawin dito.

Dito nagbabayad nang dalawang beses ang makitid na disenyo, dahil ang mas kaunting maabot na host ay nangangahulugan ng mas kaunting lugar kung saan maaaring samantalahin ang pagkakamali sa antas ng application.

Panatilihin ang network rule at papel ng application sa hiwalay na mga sistema, at i-retire sila nang hiwalay.

Patunayan ang parehong pinahihintulutan at tinanggihang landas

Kumonekta bilang awtorisadong user at magsagawa ng isang hindi nakakapinsalang kinatawan na operasyon, pagkatapos subukan ang destinasyong dapat hindi maabot. Ang disenyong sumusubok lamang sa unang kalahati ay hindi pa nasubok, at ang tinanggihang pagsubok ang nagpapatunay sa disenyo. Subukan ang bagong session pagkatapos ng bawat pagbabago ng patakaran, at tingnan ang return path kung dumarating ang mga kahilingan ngunit hindi ang mga tugon.

Huwag paganahin ang mga filter ng pagpapasa upang pumasa ang acceptance test, dahil binabago nito ang bagay na sinusubok.

Kapag hindi na kailangan ng user ang serbisyo, i-retire ang remote identity at papel ng application sa kani-kanilang sistema, at itala ang pareho. Ang gabay sa pagpapasa ng strongSwan ay sumasaklaw sa gilid ng gateway ng landas.