VPN-felhasználó regisztrálása: először az identitás tulajdonosát keresse
Egy VPN-felhasználó hozzáadása az identitásrendszernél kezdődik, nem a shellnél. Derítse ki, melyik backend validálja a fiókot, adja meg a jogosultságot, és tervezze meg a visszavonást.
Valaki VPN-hozzáférést kér, és az első ösztön az, hogy adduser-t futtassunk a szerveren. Ez az ösztön csak szűk telepítési körben helyes. Mielőtt bármit létrehozna, nyissa meg a szerver konfigurációját, és derítse ki, milyen termék fut ott, és hol validálja a hitelesítő adatokat, mert a fiók élhet termékadatbázisban, identitásszolgáltatónál vagy a gazdagép saját hitelesítési vermében. A rossz típusú fiók létrehozása működő bejelentkezéssel és alagút nélkül hagyja a személyt.
Az a kliensprofil, amely OpenVPN-t említ, a protokollt írja le, nem a mögötte álló identitásrendszert.
A szerverrel kezdje, ne az adduserrel
Először azonosítsa a terméket. A Community OpenVPN a daemon plusz bármilyen hitelesítés, amit hozzákötött, míg az Access Server saját felhasználói réteggel rendelkező termék. Kérje el a konfigurációt, az unit nevét és a csomaglistát, és ellenőrizze, van-e webes felület a felhasználókezeléshez. Ezután nézze meg, hogyan várja el a telepített profil, hogy az ügyfelek bizonyítsák, kik ők: tanúsítvánnyal, felhasználónévvel és jelszóval, vagy mindkettővel. Ez a válasz megnevezi a fiókot birtokló rendszert.
Csak ezután jelent valamit a felhasználó létrehozása kifejezés. Csak tanúsítványos telepítésnél ez azt jelenti, hogy eszközidentitást adnak ki a jóváhagyott folyamaton keresztül, és egy Unix-bejelentkezés semmit sem változtat. Jelszavas telepítésnél ez azt a backendet jelenti, amely valóban validálja a jelszót.
Négy backend, négy hely a fiók létrehozására
Az Access Server helyi hitelesítése a saját adatbázisában tartja a fiókokat, ezért a létrehozásukra szolgáló felület a termékhez tartozik, nem a gazdagéphez. A PAM a validálást az operációs rendszer vermére bízza, ezért lehet helyi Unix-fiók a regisztráció része, ha a szolgáltatás ezt a vermet választotta. Az LDAP, a RADIUS és a SAML külső szolgáltatásba helyezi a validálást, ahol a kiépítés, a jelszópolitika és az MFA él. Az Access Server mind a négy esetben továbbra is tárolhat felhasználónkénti tanúsítványokat és engedélyeket, és ez teszi zavaróvá a felosztást.
Ennek a konkrét felhasználónak a tényleges módszerét ellenőrizze, ne a globális alapértelmezést. Az Access Server 2.10 és újabb verziói csoportonként vagy felhasználónként eltérő hitelesítési módszereket alkalmazhatnak, ezért a helyi alapértelmezés nem bizonyítja, hogy az előtte álló fiókot helyben validálják.
A jogosultság külön döntés
A hitelesítés arra válaszol, ki a személy; a jogosultság arra, mit érhet el. Tartsa ezeket két lépésként, mert a sikeres bejelentkezés nem adományozás. Szándékosan ossza ki a tervezett útvonalakat, erőforrás-engedélyeket és adminisztratív jogokat, és erősítse meg, hogy a nem kapcsolódó hozzáférés továbbra is elutasított marad. Ahol a telepítés egyéni identitásokat támogat, személyenként egyet adjon ki ahelyett, hogy valaki más profilját továbbítaná, mert a megosztott profil nem vonható vissza egyetlen személyre.
Az ügyfél-anyag is számít. Az automatikus bejelentkezési profil és az interaktív felhasználói bejelentkezés különböző hitelesítési viszonyokat képvisel, és az egyik felcserélése a másikkal megváltoztatja, mit ellenőriz valójában a szerver.
A hozzáférés visszavonása a regisztráció része
Jegyezzen fel három tulajdonost, miközben a felhasználó létrejön: ki validálja a fiókot, ki engedélyezi a VPN-hozzáférést, és melyik eszköz vagy profil képviseli a kapcsolatot. Ez lehet három különböző rendszer, és egy visszavonási terv, amely csak egyet nevez meg közülük, nyitva hagy egy utat. Amikor a személy távozik, távolítsa el a jogosultságot a tulajdonosától, és vonja vissza az összes kiadott hitelesítő adatot a tulajdonosánál. Egy letöltött fájl törlése nem visszavonás, és egy helyi bejegyzés törlése sem az, ha egy külső identitás még hitelesít.
Ezután tesztelje a regisztrációt úgy, ahogy egy támadó tenné: csatlakozzon egyszer az új identitással, erősítse meg a tervezett erőforráshoz való hozzáférést, és erősítse meg, hogy egy nem kapcsolódó erőforrás továbbra is elutasít. Egy működő első kapcsolat plusz egy negatív teszt kész regisztráció.
Tartsa a nyilvántartást annál a profilnál, amelyhez tartozik. A következő auditor azt fogja kérdezni, ki csatlakozhatott egy adott hónapban, és a válasz abban a három tulajdonosban van.