Szolgáltatásfiók VPN-hozzáférése: tanúsítvány vagy megosztott bejelentkezés

Két terv lefedi szinte az összes felügyelet nélküli VPN-beállítást: egy szkriptben tartott megosztott emberi bejelentkezés, vagy a hoszthoz kötött gépi tanúsítvány. Máshol hibáznak, ami fontosabb a beállítás sebességénél. A tárolt jelszó akkor törik el, amikor a tulajdonosa megváltoztatja vagy elmegy; a tanúsítvány akkor törik el, amikor lejár, vagy amikor a hostot a kulcs nélkül építik újra. Három feltétel dönti el, melyik költséget bírja el, és egyik terv sem korlátoz semmit, amíg az engedélyezési szabályzat meg nem teszi.

A feladatból induljon ki, ne a fiókból

A feladat határozza meg a határt: mely célok, mely szolgáltatások, mely órák, meddig futhat egy munkamenet. Az alagútútvonal csak a határ fele. Az átjáró dönti el, engedélyezett-e a munkamenet; a mögötte lévő erőforrás dönti el, mit tehet a munkamenet. Először írja le a listát, megnevezett tulajdonossal, mert mindkét identitástervnek meg kell felelnie neki.

A leírás közben tartsa külön a hitelesítést és az engedélyezést. A hitelesítés azt válaszolja meg, ki kapcsolódik; az engedélyezés azt, mit érhet el utána a munkamenet. A RADIUS a második részt attribútumokként hordozza, például Filter-Id, Framed-IP-Address, Session-Timeout és Class, és az átjáró a sikeres bejelentkezés után csatolja őket. Az a terv, amely lecseréli a bejelentkezést, és az engedélyezést érintetlenül hagyja, semmit sem korlátozott.

Megosztott emberi bejelentkezés: a jelszó lesz a határ

Az emberi fiók újrafelhasználása a leggyorsabb út, és ez öregszik a legrosszabbul. A hitelesítő adat jelszó, így szkriptbe, környezeti fájlba és ütemező-konfigurációba kerül, és minden másolatot rotálni kell. Amikor a tulajdonos pénteken megváltoztatja, a feladat a következő futáskor elbukik, és senki sem figyel.

Az MFA az a pont, ahol ez a terv általában összeomlik. A szkript nem tud válaszolni egy push kérésre, ezért a fiókot kizárják a szabályzatból, és ez pontosan az a fiók, amelyet egy támadó választana. A kivételek, a megbízható hely megkerülése és a fiókonkénti mentességek sokasodnak, és egyik sem látható a bérlő beállításait olvasó következő ember számára.

A besorolás a másik költség. Az átjárónapló minden munkamenete ugyanazt a felhasználónevet hordozza, így az éjszakai szinkronizálás nem különböztethető meg az azt író ember munkájától, és a feladat visszavonása azt az embert jelenti visszavonni.

Gépi tanúsítvány: a hoszthoz kötött identitás

A tanúsítvány a kérdést arról, mit tud a fiók, arra változtatja, mi a host. EAP-TLS esetén az ügyfél bemutat egy tanúsítványt, és bizonyítja a hozzá tartozó privát kulcs birtoklását; a házirend-kiszolgáló a tárgyat vagy a számítógépfiókot csoporthoz rendeli, és erre a csoportra alkalmazza a szabályzatot. Nincs kérés, nincs szövegfájlban ülő megosztott titok.

Az általa létrehozott határ szűkebb, mint amire az emberek számítanak. A tanúsítvány a hostot hitelesíti, nem a feladatot, és bárki, akinek root vagy helyi rendszergazdai joga van, használhatja azt a kulcsot azon a hoston. Tartsa a kulcsot ott, ahol a platform védi: nem exportálhatóan a Windows tanúsítványtárában, TPM-támogatással ahol a profil engedi, vagy root-tulajdonú 0600 fájlként Linuxon. A host kompromittálása a hitelesítő adat kompromittálása.

A lejárat a visszatérő hiba. A vasárnap lejáró tanúsítvány vasárnap állítja meg a feladatot, és az átjáró általában általános hitelesítési hibát jelent a dátum megnevezése helyett. Ellenőrizze a dátumokat a feladat hostjáról a runbook részeként:

openssl x509 -in client.pem -noout -subject -issuer -dates
ipsec listcerts

A visszavonáshoz olyan útvonal kell, amelyet az átjáró ellenőriz. OpenVPN CRL-t olvas a crl-verify opcióval, a strongSwan pedig a kapcsolati profil felépítésétől függően CRL-re vagy OCSP-re támaszkodik. Ha egyik sincs bekötve, egy host eltávolítása azt jelenti, meg kell várni a tanúsítvány lejáratát.

Három feltétel, amely közöttük dönt

A saját platformjához hasonlítson, ne egy referenciatervhez.

Első feltétel: tud-e az átjáró gépi identitást engedélyezni? Ha csak egy RADIUS-felhasználónevet képez le egy könyvtárfelhasználóra, a tanúsítvány hitelesíti a hostot, majd megakad az engedélyezésnél. Második feltétel: szüksége van-e a feladatnak olyan erőforrás-hozzáférésre, amelyet csak felhasználói fiók hordoz, például csatolt megosztásra vagy ülésenkénti licencre? Akkor a gépi identitás nem helyettesíthet, és az őszinte válasz egy dedikált felhasználói fiók szűk szabályzattal. Harmadik feltétel: ki tudja rotálni a hitelesítő adatot ember nélkül a folyamatban? Az automatikus regisztráció olcsóvá teszi a tanúsítványok tartását; az egy ember által ismert jelszó nem.

A táblázatot költséglistaként olvassa, nem rangsorként. A tárolt titok oszlopa a visszavonás sebességében és azon erőforrásokkal való kompatibilitásban nyer, amelyek csak felhasználói fiókokat értenek; a tanúsítvány oszlopa a rotációban és abban nyer, hogy nem gyengíti az MFA-t egy szkript működéséért.

Tegye a korlátot a szabályzatba, a hitelesítés után

Bármelyik identitást választja, a jogosultsági korlát ahhoz a szabályzathoz tartozik, amely a hitelesítés után fut. Az NPS-ben a hálózati szabályzatokat sorrendben értékelik, és az első szabályzat, amely minden feltételnek megfelel, alkalmazza a beállításait, így egy szűk fölé helyezett széles szabályzat dönti el az eredményt, függetlenül attól, mit mutat be az ügyfél. A Microsoft a feltétel- és beállításmodellt a NPS-szabályzatok áttekintésében.

Adjon a feladatnak saját csoportot vagy szabályzatfeltételt, valami olyan alapján, amit a gépi identitás hordoz: tanúsítványsablon, a hívó állomás azonosítója vagy egy dedikált pool címe. Ezután attribútumokkal határolja a munkamenetet: Filter-Id ahhoz a szerephez, amelyre az átjárója leképezi, rövid Session-Timeout, hogy egy elakadt feladat újrahitelesítsen ahelyett, hogy napokig tartana egy munkamenetet, és Framed-IP-Address olyan poolból, amelyre a túloldalon tűzfalat tesz. Az alkalmazásengedélyezés külön marad: az adatbázis-kiszolgálóhoz vezető alagút nem jogosít fel a benne lévő tábla olvasására.

Ellenőrizze az elutasításokat, majd tervezze meg az eltávolítást

A működő hozzáférés semmit sem bizonyít a legkisebb jogosultságról. Tesztelje inkább az elutasításokat: kapcsolódjon a feladat identitásával, és próbáljon elérni a listán kívüli célt, nyisson második párhuzamos munkamenetet, ha az átjárónak csak egyet szabad engednie, és ismételje meg a bejelentkezést a hitelesítő adat visszavonása után.

Majd igazolja ugyanazt a munkamenetet két helyen. Az átjárónapló mutatja a hitelesített identitást; a házirend-kiszolgáló naplója mutatja, melyik szabályzat illeszkedett, és milyen attribútumokat adott vissza. Az OpenVPN-en a kiszolgáló rögzíti a tanúsítvány köznapi nevét, a strongSwan ipsec statusall parancsa pedig kinyomtatja a létrejött alagutat a használt identitással. Ha a két napló nem ért egyet az identitásról, a szabályzat valami máshoz illeszkedik, mint amit feltételez.

Az eltávolítás a terv része, nem takarítási sprint. Írjon le mindent, amit törölni kell (tanúsítvány vagy fiók, csoporttagság, hálózati szabályzat, pool-bejegyzés, tűzfalszabály a célon), és futtassa le egyszer, amíg a feladat könnyen újraépíthető.

Ha ma kezdi, ebben a sorrendben dolgozzon: írja le az erőforráslistát, válassza ki az identitást a három feltétellel, tegye a korlátot a szabályzatba, és gyakoroljon egy elutasítást, mielőtt a feladat élesbe megy.