Hogyan dokumentáljunk egy VPN-zárolási kivételt, hogy eltávolítható legyen
A kivétel, amelyet senki sem tud leírni, tartós. Rögzítsük az engedélyezett forgalmat, a követelményt, a hibaviselkedést és az eltávolító komponenst.
Azok a megkerülések, amelyek célja a szerzőjükkel együtt távozott, azok, amelyek túlélik hasznosságukat, és a zárolási szabályzatok gyorsabban gyűjtik őket, mint bármely más konfigurációtípus. Az „engedélyezze a helyi hálózatot” formában írt kivétel olyan szabály, amelyet senki sem tud megvédeni és senki sem tud kivezetni, mert a mögötte álló követelmény a hozzáadó személlyel együtt távozott. Az ilyen szabályzatok azzal buknak el, hogy olyan mentességeket hordoznak, amelyek indoka elpárolgott, miközben a kockázat megmaradt. A hatókör, a hibaviselkedés és az eltávolítási lépés írásának pillanata az a pillanat, amikor hozzáadjuk a kivételt, amíg valaki még emlékszik rá, miért.
Ez egy döntés arról, hogy minek kell szerepelnie a feljegyzésben, nem kitöltendő sablon. Az alábbi négy mező az, amely eldönti, hogy egy bíráló egy év múlva megbeszélés nélkül el tudja-e távolítani a szabályt. Mindegyik azért létezik, mert a hiányának kiszámítható költsége van.
Miért nem vezetik ki soha a nem dokumentált megkerülést
A leírás nélküli megkerülés nem tesztelhető, ezért nem távolítható el biztonságosan. Túléli az összes felülvizsgálatot, mert a törlés kockázatosnak, a megtartás ártalmatlannak látszik, és minden felülvizsgálat, amely átlép rajta, a következőt is könnyebbé teszi átlépni. A költség addig láthatatlan, amíg egy audit meg nem kérdezi, miért mentes egy privát tartomány, és akkorra a válasz egy vállrándítás.
A feljegyzésnek elég rövidnek kell lennie ahhoz, hogy az emberek tényleg megírják a változási ablakban. Egy sor a forgalomnak, egy a követelménynek, amelyet szolgál.
A hatókör írása forgalomként
Soroljuk fel az alkalmazást vagy a cél tartományt, az érintett címcsaládokat, a szolgáltatást és a portot, valamint azt a hálózati környezetet, amelyben a szabály érvényes, majd nevezzük meg a jóváhagyót és az azt hordozó pontos kliens- vagy platformbeállítást. A „nyomtató” szándék; a „TCP 631 a 192.168.1.50-re, csak otthoni hálózaton” olyan hatókör, amelyet valaki ellenőrizni tud. Ha a „hol lakik ez” kérdésre a válasz „valahol az MDM-profilban”, a feljegyzés nincs kész. Egy fájlútvonal, egy profilnév vagy egy beállításkulcs jobb, mint annak leírása, hogy hol lehet a beállítás.
Ahol a platform támogatja az alkalmazásonkénti szabályokat, részesítsük előnyben azokat a címtartományokkal szemben, mert egyetlen alkalmazásnak engedni az alagút megkerülését szűkebb, mint egy egész privát alhálózat mentesítése, és túléli, ha az eszköz új címre költözik. Az Android VpnService-útmutatója ezt az alkalmazásonkénti modellt írja le; az asztali kliensek ugyanezt az ötletet a saját profilbeállításaikon keresztül fejezik ki. A címalapú mentességek a tartalék megoldás, amikor a platform semmi szűkebbet nem kínál, ezért van szükségük élesebb hatókörsorra.
Négy kivételtípus, négy eltávolítási kockázat
A kivételek nem egy kategóriát alkotnak, és eltávolításuk eltérő következményekkel jár. Egy sor megosztása két típus között az az út, ahogy egy nyomtató kivezetése a csatlakozási képességet is kivezeti.
| Kind | Typical example | Removal risk |
|---|---|---|
| Endpoint bootstrap | reaching the gateway before the tunnel exists | high: nothing comes up without it |
| Captive portal | hotel or airport sign-in page | medium: only matters on untrusted networks |
| Local device | printer, casting target, test instrument | low: one service at one address |
| Excluded application | an app that must not use the tunnel | medium: depends on the app's own behaviour |
Tartsuk a bootstrap-, portál-, eszköz- és alkalmazáskivételeket külön sorokon, még akkor is, ha a gyakorlatban átfednek. Egy privát tartomány mentessége csendesen minden szomszédnak hozzáférést ad azon az alhálózaton, nem csak annak az egy eszköznek, amelyet el akartunk érni, és ez a különbség a megvédhető hatókör és a csak remélt hatókör között.
Mit tesz a megkerülés, amikor az alagút leesik
Tegyünk fel három kérdést, és írjuk le a válaszokat, mert ezek döntik el, hogy a zárolás valódi-e. Használható marad-e a kivétel, amikor az alagút leesik: egy captive portálnál muszáj, különben soha senki nem tud bejelentkezni, míg egy privát erőforrásnál általában nem szabad, különben a szabályzat dekoratív. Minden hálózaton érvényes-e, vagy csak a szánt környezetben, mivel az otthoni alhálózatra szűkített szabály egészen másképp viselkedik egy nyilvános hálózaton, amely véletlenül ugyanazt a tartományt használja. Minden válasz megváltoztatja a szabályt és a feljegyzést is, így a megválaszolatlan kérdés olyan döntés, amelyet később valaki más hibásan hoz meg.
A harmadik kérdés az, hogy mi történik amikor a cél megváltoztatja a címét, ahol a domainalapú és a címalapú mentességek elválnak. A domainalapú szabályok attól függnek, mikor történik a feloldás, és attól, hogyan alkalmazza a kliens az eredményt, ezért csendesen megszűnhetnek illeszkedni egy látszólag független változás után, és a hiba inkább törött VPN-nek látszik, mint elavult mentességnek.
Teszteljünk, teszteljünk újra, és írjuk le az eltávolítási lépést
Írjunk egy ártalmatlan tesztet az engedélyezett útvonalra és egy közeli elutasított esetet: a nyomtató oldala betöltődik, az ugyanazon az alhálózaton lévő fájlmegosztás pedig nem. Ez a pár bizonyítja, hogy a kivétel szűk, és ez az a pár, amelyet egy bíráló az eredeti kérés megértése nélkül meg tud ismételni. Ezután állítsuk be az újratesztelési triggereket, mert a soha újra nem tesztelt kivétel eltávolodik attól a követelménytől, amelyre írták, és az eltávolodás addig láthatatlan, amíg valami el nem törik.
Végül rögzítsük, hogyan kell a szabályt eltávolítani a tulajdonos komponensen keresztül, és tartsuk a titkokat a feljegyzésen kívül. Egy szolgáltatás és egy útvonal leírása soha nem igényel privát kulcsot, jelszót vagy bárki böngészési előzményeit, és egy rövid, karbantartott lista jobb, mint egy ideiglenes szabály, amely túlélte a szerzőjét.