VPN-käyttäjän rekisteröinti: etsi ensin identiteetin omistaja

Joku pyytää VPN-yhteyttä, ja ensimmäinen vaisto on ajaa adduser palvelimella. Tuo vaisto on oikea vain kapeassa joukossa käyttöönottoja. Ennen kuin luot mitään, avaa palvelimen kokoonpano ja selvitä, mikä tuote siellä toimii ja missä se validoi tunnistetiedot, koska tili voi sijaita tuotetietokannassa, identiteettipalvelussa tai isäntäkoneen omassa todennuspinossa. Vääränlaisen tilin luominen jättää henkilön toimivan kirjautumisen kanssa ilman tunnelia.

Asiakasprofiili, jossa lukee OpenVPN, kuvaa protokollan, ei sen takana olevaa identiteettijärjestelmää.

Aloita palvelimesta, älä adduserista

Tunnista ensin tuote. Community OpenVPN on daemon plus kaikki todennus, jonka siihen kytkit, kun taas Access Server on tuote, jolla on oma käyttäjäkerroksensa. Pyydä kokoonpano, unitin nimi ja pakettiluettelo, ja tarkista, onko käyttäjähallintaan verkkokäyttöliittymää. Katso sitten, miten käyttöön otettu profiili odottaa asiakkaiden todistavan kuka he ovat: varmenne, käyttäjänimi ja salasana tai molemmat. Tuo vastaus nimeää järjestelmän, joka omistaa tilin.

Vasta sen jälkeen ilmaus käyttäjän luominen tarkoittaa jotain. Vain varmenteisiin perustuvassa käyttöönotossa se tarkoittaa laiteidentiteetin myöntämistä hyväksytyn prosessin kautta, eikä Unix-kirjautuminen muuta mitään. Salasanaan perustuvassa käyttöönotossa se tarkoittaa backendia, joka todella validoi salasanan.

Neljä backendia, neljä paikkaa luoda tili

Access Serverin paikallinen todennus pitää tilit omassa tietokannassaan, joten niiden luontikäyttöliittymä kuuluu tuotteelle eikä isännälle. PAM delegoi validoinnin käyttöjärjestelmän pinoon, ja siksi paikallinen Unix-tili voi olla osa rekisteröintiä, kun palvelu on valinnut juuri tuon pinon. LDAP, RADIUS ja SAML siirtävät validoinnin ulkoiseen palveluun, jossa provisiointi, salasanakäytäntö ja MFA sijaitsevat. Access Server voi kaikissa neljässä tapauksessa yhä pitää käyttäjäkohtaiset varmenteet ja oikeudet, ja juuri se tekee jaosta hämmentävän.

Tarkista tämän tietyn käyttäjän tehokas menetelmä, älä yleistä oletusarvoa. Access Server 2.10 ja uudemmat voivat soveltaa eri todennusmenetelmiä ryhmä- tai käyttäjäkohtaisesti, joten paikallinen oletusarvo ei todista, että edessäsi oleva tili validoidaan paikallisesti.

Oikeus on erillinen päätös

Todennus vastaa siihen, kuka henkilö on; oikeus vastaa siihen, mihin hän voi päästä. Pidä ne kahtena vaiheena, koska onnistunut kirjautuminen ei ole myöntö. Määritä aiotut reitit, resurssioikeudet ja hallinnolliset oikeudet tarkoituksella ja varmista, että asiaankuulumaton pääsy pysyy kiellettynä. Kun käyttöönotto tukee yksilöllisiä identiteettejä, myönnä yksi henkilöä kohden sen sijaan että välität jonkun toisen profiilin, koska jaettua profiilia ei voi peruuttaa yhdeltä henkilöltä.

Myös asiakasmateriaalilla on merkitystä. Automaattisen kirjautumisen profiili ja vuorovaikutteinen käyttäjäkirjautuminen edustavat erilaisia todennussuhteita, ja toisen vaihtaminen toiseen muuttaa sitä, mitä palvelin todella tarkistaa.

Pääsyn peruuttaminen on osa rekisteröintiä

Kirjaa kolme omistajaa, kun käyttäjää luodaan: kuka validoi tilin, kuka valtuuttaa VPN-pääsyn ja mikä laite tai profiili edustaa yhteyttä. Ne voivat olla kolme eri järjestelmää, ja peruutussuunnitelma, joka nimeää vain yhden niistä, jättää polun avoimeksi. Kun henkilö lähtee, poista oikeus sen omistajalta ja peruuta jokainen myönnetty tunnistetieto sen omistajalta. Ladatun tiedoston poistaminen ei ole peruutus, eikä paikallisen merkinnän poistaminen ole sitä, jos ulkoinen identiteetti yhä todennetaan.

Testaa sitten rekisteröintiä kuten hyökkääjä tekisi: yhdistä kerran uudella identiteetillä, vahvista pääsy aiottuun resurssiin ja vahvista, että asiaankuulumaton resurssi yhä kieltäytyy. Toimiva ensimmäinen yhteys plus negatiivinen testi on valmis rekisteröinti.

Säilytä merkintä sen profiilin kanssa, johon se kuuluu. Seuraava auditoija kysyy, kuka saattoi yhdistää tietyn kuukauden aikana, ja vastaus on noissa kolmessa omistajassa.