Registrere en VPN-bruker: finn identitetseieren først

Noen ber om VPN-tilgang, og den første refleksen er å kjøre adduser på serveren. Den refleksen er bare riktig i et smalt sett av installasjoner. Før du oppretter noe, åpne serverens konfigurasjon og finn ut hvilket produkt som kjører der og hvor det validerer legitimasjon, fordi kontoen kan ligge i en produktdatabase, hos en identitetsleverandør eller i vertens egen autentiseringsstakk. Å opprette feil type konto etterlater personen med en fungerende innlogging og uten tunnel.

En klientprofil som sier OpenVPN beskriver protokollen, ikke identitetssystemet bak den.

Start med serveren, ikke med adduser

Identifiser produktet først. Community OpenVPN er daemonen pluss all autentisering du koblet til den, mens Access Server er et produkt med sitt eget brukerlag. Be om konfigurasjonen, enhetsnavnet og pakkelisten, og sjekk om det finnes et webgrensesnitt for brukeradministrasjon. Se deretter på hvordan den utrullede profilen forventer at klienter beviser hvem de er: et sertifikat, et brukernavn og passord, eller begge. Det svaret navngir systemet som eier kontoen.

Først etter det gir uttrykket å opprette brukeren mening. I en installasjon med bare sertifikater betyr det å utstede en enhetsidentitet gjennom den godkjente prosessen, og en Unix-innlogging endrer ingenting. I en passordinstallasjon betyr det backend som faktisk validerer passordet.

Fire backends, fire steder å opprette kontoen

Access Servers lokale autentisering holder kontoer i sin egen database, så grensesnittet for å opprette dem tilhører produktet og ikke verten. PAM delegerer valideringen til operativsystemets stakk, og derfor kan en lokal Unix-konto være del av registreringen når tjenesten har valgt nettopp den stakken. LDAP, RADIUS og SAML flytter valideringen til en ekstern tjeneste, der provisjonering, passordpolicy og MFA ligger. Access Server kan fortsatt holde sertifikater og tillatelser per bruker i alle fire tilfellene, og det er det som gjør oppdelingen forvirrende.

Sjekk den effektive metoden for denne konkrete brukeren i stedet for den globale standarden. Access Server 2.10 og nyere kan bruke forskjellige autentiseringsmetoder per gruppe eller bruker, så en lokal standard beviser ikke at kontoen foran deg valideres lokalt.

Rettigheten er en egen beslutning

Autentisering svarer på hvem personen er; rettigheten svarer på hva personen kan nå. Hold dem som to trinn, fordi en vellykket innlogging ikke er en tildeling. Tildel de tiltenkte rutene, ressurstillatelsene og de administrative rettighetene bevisst, og bekreft at urelatert tilgang fortsatt avvises. Der installasjonen støtter individuelle identiteter, utsted én per person i stedet for å videresende noen andres profil, fordi en delt profil ikke kan tilbakekalles for én person alene.

Klientmaterialet betyr også noe. En auto-innloggingsprofil og en interaktiv brukerinnlogging representerer forskjellige autentiseringsforhold, og å bytte det ene mot det andre endrer hva serveren faktisk verifiserer.

Tilbakekalling av tilgang er en del av registreringen

Skriv ned tre eiere mens brukeren opprettes: hvem som validerer kontoen, hvem som autoriserer VPN-tilgangen, og hvilken enhet eller profil som representerer forbindelsen. Det kan være tre forskjellige systemer, og en tilbakekallingsplan som bare nevner én av dem, lar en vei stå åpen. Når personen slutter, fjern rettigheten fra eieren og tilbakekall hver utstedt legitimasjon hos eieren. Å slette en nedlastet fil er ikke tilbakekalling, og det er heller ikke å slette en lokal oppføring hvis en ekstern identitet fortsatt autentiseres.

Test deretter registreringen slik en angriper ville gjort: koble til én gang med den nye identiteten, bekreft tilgang til den tiltenkte ressursen, og bekreft at en urelatert ressurs fortsatt avviser. En første forbindelse som virker pluss en negativ test er en fullført registrering.

Oppbevar posten sammen med profilen den tilhører. Den neste revisoren vil spørre hvem som kunne koble til i en gitt måned, og svaret ligger hos de tre eierne.