Registrace uživatele VPN: nejprve najděte vlastníka identity

Někdo požádá o přístup k VPN a prvním instinktem je spustit adduser na serveru. Tento instinkt je správný jen v úzké množině nasazení. Než cokoli vytvoříte, otevřete konfiguraci serveru a zjistěte, který produkt tam běží a kde ověřuje přihlašovací údaje, protože účet může žít v databázi produktu, u poskytovatele identity nebo ve vlastním autentizačním stacku hostitele. Vytvoření špatného typu účtu nechá člověka s funkčním přihlášením a bez tunelu.

Klientský profil, který uvádí OpenVPN, popisuje protokol, ne systém identity za ním.

Začněte serverem, ne adduserem

Nejprve identifikujte produkt. Community OpenVPN je démon plus jakákoli autentizace, kterou jste k němu připojili, zatímco Access Server je produkt s vlastní uživatelskou vrstvou. Vyžádejte si konfiguraci, název unitu a seznam balíčků a zkontrolujte, zda existuje webové rozhraní pro správu uživatelů. Potom se podívejte, jak nasazený profil očekává, že klienti prokážou, kdo jsou: certifikátem, uživatelským jménem a heslem, nebo obojím. Tato odpověď pojmenovává systém, který účet vlastní.

Teprve potom fráze vytvoření uživatele něco znamená. V nasazení pouze s certifikáty to znamená vydat identitu zařízení schváleným procesem, a přihlášení Unix nic nemění. V nasazení s heslem to znamená backend, který heslo skutečně ověřuje.

Čtyři backendy, čtyři místa pro vytvoření účtu

Místní autentizace Access Serveru drží účty ve vlastní databázi, takže rozhraní pro jejich vytváření patří produktu, ne hostiteli. PAM deleguje ověření na stack operačního systému, a proto může být místní účet Unix součástí registrace, když si služba vybrala právě tento stack. LDAP, RADIUS a SAML přesouvají ověření do externí služby, kde žije provisioning, politika hesel a MFA. Access Server může ve všech čtyřech případech stále držet certifikáty a oprávnění pro jednotlivé uživatele, a to je to, co rozdělení dělá matoucím.

Zkontrolujte efektivní metodu pro tohoto konkrétního uživatele, ne globální výchozí hodnotu. Access Server 2.10 a novější může uplatnit různé metody autentizace pro skupinu nebo uživatele, takže výchozí hodnota místní neznamená, že se účet před vámi ověřuje místně.

Oprávnění je samostatné rozhodnutí

Autentizace odpovídá, kdo osoba je; oprávnění odpovídá, kam může dosáhnout. Držte to jako dva kroky, protože úspěšné přihlášení není udělení. Záměrně přidělte zamýšlené trasy, oprávnění k prostředkům a administrativní práva a potvrďte, že nesouvisející přístup zůstává zamítnut. Kde nasazení podporuje individuální identity, vydávejte jednu na osobu místo přeposílání cizího profilu, protože sdílený profil nelze odebrat jedné osobě.

Klientský materiál také záleží. Profil s automatickým přihlášením a interaktivní uživatelské přihlášení představují různé autentizační vztahy a záměna jednoho za druhé mění to, co server skutečně ověřuje.

Odebrání přístupu je součástí registrace

Zapište tři vlastníky, zatímco se uživatel vytváří: kdo účet ověřuje, kdo autorizuje přístup k VPN a které zařízení nebo profil představuje připojení. Mohou to být tři různé systémy a plán odebrání, který jmenuje jen jeden z nich, nechává cestu otevřenou. Když osoba odejde, odeberte oprávnění od jeho vlastníka a zrušte každý vydaný údaj u jeho vlastníka. Smazání staženého souboru není odebrání a není jím ani smazání místní položky, pokud se externí identita stále autentizuje.

Potom registraci otestujte tak, jak by to udělal útočník: připojte se jednou s novou identitou, potvrďte přístup k zamýšlenému prostředku a potvrďte, že nesouvisející prostředek stále odmítá. První funkční připojení plus negativní test je dokončená registrace.

Uchovávejte záznam s profilem, ke kterému patří. Další auditor se zeptá, kdo se mohl během daného měsíce připojit, a odpověď žije v těchto třech vlastnících.