Rejestracja użytkownika VPN: najpierw znajdź właściciela tożsamości

Ktoś prosi o dostęp do VPN, a pierwszym odruchem jest uruchomienie adduser na serwerze. Ten odruch jest słuszny tylko w wąskim zestawie wdrożeń. Zanim cokolwiek utworzysz, otwórz konfigurację serwera i sprawdź, jaki produkt tam działa i gdzie weryfikuje poświadczenia, bo konto może mieszkać w bazie produktu, u dostawcy tożsamości albo we własnym stosie uwierzytelniania hosta. Utworzenie niewłaściwego rodzaju konta zostawia osobę z działającym logowaniem i bez tunelu.

Profil klienta, który mówi OpenVPN, opisuje protokół, a nie system tożsamości za nim.

Zacznij od serwera, nie od adduser

Najpierw zidentyfikuj produkt. Community OpenVPN to demon plus dowolne uwierzytelnianie, które do niego podłączyłeś, podczas gdy Access Server to produkt z własną warstwą użytkowników. Poproś o konfigurację, nazwę jednostki i listę pakietów oraz sprawdź, czy istnieje interfejs webowy do zarządzania użytkownikami. Następnie zobacz, jak wdrożony profil oczekuje, że klienci udowodnią, kim są: certyfikatem, nazwą użytkownika i hasłem albo oboma. Ta odpowiedź nazywa system, który posiada konto.

Dopiero potem wyrażenie utworzyć użytkownika ma sens. We wdrożeniu tylko z certyfikatami oznacza to wydanie tożsamości urządzenia w zatwierdzonym procesie, a logowanie Unix niczego nie zmienia. We wdrożeniu z hasłem oznacza to backend, który faktycznie weryfikuje hasło.

Cztery backendy, cztery miejsca utworzenia konta

Lokalne uwierzytelnianie Access Servera trzyma konta we własnej bazie, więc interfejs do ich tworzenia należy do produktu, a nie do hosta. PAM deleguje weryfikację do stosu systemu operacyjnego, dlatego lokalne konto Unix może być częścią rejestracji, gdy usługa wybrała właśnie ten stos. LDAP, RADIUS i SAML przenoszą weryfikację do usługi zewnętrznej, w której żyją provisioning, polityka haseł i MFA. Access Server w każdym z czterech przypadków nadal może trzymać certyfikaty i uprawnienia na użytkownika, i to właśnie czyni podział mylącym.

Sprawdź metodę obowiązującą dla tego konkretnego użytkownika, a nie globalne ustawienie domyślne. Access Server 2.10 i nowsze mogą stosować różne metody uwierzytelniania dla grupy lub użytkownika, więc lokalne ustawienie domyślne nie dowodzi, że konto przed tobą jest weryfikowane lokalnie.

Uprawnienie to odrębna decyzja

Uwierzytelnianie odpowiada, kim jest osoba; uprawnienie odpowiada, do czego może dotrzeć. Trzymaj je jako dwa kroki, bo udane logowanie nie jest nadaniem. Świadomie przydziel zamierzone trasy, uprawnienia do zasobów i prawa administracyjne oraz potwierdź, że niepowiązany dostęp pozostaje odmówiony. Tam, gdzie wdrożenie obsługuje indywidualne tożsamości, wydawaj jedną na osobę zamiast przekazywać profil kogoś innego, bo wspólnego profilu nie można odebrać jednej osobie.

Materiał klienta też ma znaczenie. Profil z automatycznym logowaniem i interaktywne logowanie użytkownika oznaczają różne relacje uwierzytelniania, a zamiana jednego na drugie zmienia to, co serwer naprawdę weryfikuje.

Odebranie dostępu jest częścią rejestracji

Zapisz trzech właścicieli, gdy użytkownik jest tworzony: kto weryfikuje konto, kto autoryzuje dostęp do VPN i które urządzenie lub profil reprezentuje połączenie. To mogą być trzy różne systemy, a plan odebrania, który wymienia tylko jeden z nich, zostawia otwartą ścieżkę. Gdy osoba odchodzi, usuń uprawnienie u jego właściciela i odbierz każde wydane poświadczenie u jego właściciela. Usunięcie pobranego pliku nie jest odebraniem, podobnie jak usunięcie lokalnego wpisu, jeśli tożsamość zewnętrzna nadal się uwierzytelnia.

Następnie przetestuj rejestrację tak, jak zrobiłby to atakujący: połącz się raz z nową tożsamością, potwierdź dostęp do zamierzonego zasobu i potwierdź, że niepowiązany zasób nadal odmawia. Pierwsze działające połączenie plus test negatywny to ukończona rejestracja.

Przechowuj rekord przy profilu, do którego należy. Następny audytor zapyta, kto mógł się połączyć w danym miesiącu, a odpowiedź żyje u tych trzech właścicieli.