Palvelutilin VPN-käyttö: varmenne vai jaettu kirjautuminen

Kaksi mallia kattaa lähes jokaisen valvomattoman VPN-asennuksen: skriptissä pidetty jaettu inhimillinen kirjautuminen tai isäntään sidottu konevarmenne. Ne epäonnistuvat eri kohdissa, millä on enemmän merkitystä kuin asennuksen nopeudella. Tallennettu salasana hajoaa, kun sen omistaja vaihtaa sen tai lähtee; varmenne hajoaa, kun se vanhenee tai isäntä rakennetaan uudelleen ilman avainta. Kolme ehtoa ratkaisee, minkä kustannuksen voit kantaa, eikä kumpikaan malli rajoita mitään ennen kuin valtuutuskäytäntö tekee sen.

Aloita tehtävästä, älä tilistä

Tehtävä määrittää rajan: mitkä kohteet, mitkä palvelut, mitkä tunnit, kuinka kauan istunto voi kestää. Tunnelireitti on vain puolet tästä rajasta. Yhdyskäytävä päättää, sallitaanko istunto; sen takana oleva resurssi päättää, mitä istunto voi tehdä. Kirjoita luettelo ensin, nimetyn omistajan kanssa, koska molempien identiteettimallien on täytettävä se.

Pidä todennus ja valtuutus erillään, kun kirjoitat sitä. Todennus vastaa, kuka yhdistää; valtuutus vastaa, mihin istunto voi sen jälkeen päästä. RADIUS kantaa toisen osan attribuutteina, kuten Filter-Id, Framed-IP-Address, Session-Timeout ja Class, ja yhdyskäytävä liittää ne, kun kirjautuminen onnistuu. Malli, joka vaihtaa kirjautumisen ja jättää valtuutuksen koskemattomaksi, ei ole rajoittanut mitään.

Jaettu inhimillinen kirjautuminen: salasanasta tulee raja

Inhimillisen tilin uudelleenkäyttö on nopein polku ja se, joka vanhenee huonoiten. Tunnus on salasana, joten se päätyy skriptiin, ympäristötiedostoon ja ajastimen kokoonpanoon, ja jokainen kopio vaatii kierron. Kun omistaja vaihtaa sen perjantaina, työ epäonnistuu seuraavalla ajokerralla, eikä kukaan katso.

MFA on paikka, jossa tämä malli yleensä romahtaa. Skripti ei voi vastata push-pyyntöön, joten tili jätetään käytännön ulkopuolelle, ja se on täsmälleen se tili, jonka hyökkääjä valitsisi. Poikkeukset, luotetun sijainnin ohitukset ja tilikohtaiset vapautukset lisääntyvät, eikä mikään niistä näy seuraavalle henkilölle, joka lukee vuokralaisen asetuksia.

Kohdistus on toinen kustannus. Jokainen yhdyskäytävän lokin istunto kantaa samaa käyttäjänimeä, joten yöllistä synkronointia ei voi erottaa sen kirjoittaneen henkilön työstä, ja työn peruuttaminen tarkoittaa kyseisen henkilön peruuttamista.

Konevarmenne: isäntään sidottu identiteetti

Varmenne muuttaa kysymyksen siitä, mitä tili tietää, siihen, mikä isäntä on. EAP-TLS:ssä asiakas esittää varmenteen ja todistaa vastaavan yksityisavaimen hallinnan; käytäntöpalvelin kartoittaa kohteen tai tietokonetilin ryhmään ja soveltaa kyseisen ryhmän käytäntöä. Ei kehotetta, ei tekstitiedostossa istuvaa jaettua salaisuutta.

Sen luoma raja on kapeampi kuin ihmiset odottavat. Varmenne todentaa isännän, ei tehtävää, ja kuka tahansa, jolla on root- tai paikallisen ylläpitäjän oikeudet, voi käyttää sitä avainta kyseisessä isännässä. Pidä avain siellä, missä alusta suojaa sen: ei-vietävänä Windowsin varmennevarastossa, TPM-tuettuna missä profiili sallii, tai rootin omistamana 0600-tiedostona Linuxissa. Isännän vaarantaminen on tunnuksen vaarantamista.

Vanheneminen on toistuva vika. Sunnuntaina vanheneva varmenne pysäyttää työn sunnuntaina, ja yhdyskäytävä ilmoittaa yleensä yleisen todennusvirheen nimeämättä päivämäärää. Tarkista päivämäärät työisännästä osana runbookia:

openssl x509 -in client.pem -noout -subject -issuer -dates
ipsec listcerts

Peruutus tarvitsee polun, jonka yhdyskäytävä tarkistaa. OpenVPN lukee CRL:n crl-verify-valinnan kautta, ja strongSwan riippuu CRL:stä tai OCSP:stä sen mukaan, miten yhteysprofiili on rakennettu. Jos kumpikaan ei ole kytketty, isännän poistaminen tarkoittaa varmenteen vanhenemisen odottamista.

Kolme ehtoa, jotka ratkaisevat niiden välillä

Tee vertailu käytössäsi olevaa alustaa vastaan, ei referenssiratkaisua vastaan.

Ensimmäinen ehto: voiko yhdyskäytävä valtuuttaa koneidentiteetin? Jos se vain kartoittaa RADIUS-käyttäjänimen hakemistokäyttäjäksi, varmenne todentaa isännän ja pysähtyy sitten valtuutukseen. Toinen ehto: tarvitseeko työ resurssikäyttöä, jonka vain käyttäjätili kantaa, kuten liitetty jaettu kansio tai istuinpaikkakohtainen lisenssi? Silloin koneidentiteetti ei voi korvata sitä, ja rehellinen vastaus on erillinen käyttäjätili, jolla on rajattu käytäntö. Kolmas ehto: kuka voi kierrättää tunnuksen ilman henkilöä silmukassa? Automaattinen rekisteröinti tekee varmenteista halpoja pitää; salasana, jonka yksi henkilö tietää, ei.

Lue taulukko kustannusluettelona, ei paremmuusjärjestyksenä. Tallennetun salaisuuden sarake voittaa peruutuksen nopeudessa ja yhteensopivuudessa sellaisten resurssien kanssa, jotka ymmärtävät vain käyttäjätilejä; varmennesarake voittaa kierrossa ja siinä, ettei MFA:ta heikennetä skriptin toimimiseksi.

Aseta raja käytäntöön, todennuksen jälkeen

Minkä identiteetin valitsetkin, käyttöoikeusraja kuuluu käytäntöön, joka ajetaan todennuksen jälkeen. NPS:ssä verkkokäytännöt arvioidaan järjestyksessä, ja ensimmäinen käytäntö, joka vastaa jokaista ehtoa, soveltaa asetuksensa, joten kapean yläpuolelle sijoitettu laaja käytäntö ratkaisee tuloksen riippumatta siitä, mitä asiakas esittää. Microsoft dokumentoi ehto- ja asetusmallin NPS-käytäntöjen yleiskatsauksessa.

Anna työlle oma ryhmä tai käytäntöehto, joka perustuu johonkin, mitä koneidentiteetti kantaa: varmennemalli, soittavan aseman tunniste tai osoite erillisestä altaasta. Rajoita sitten istunto attribuuteilla: Filter-Id roolille, johon yhdyskäytäväsi sen kartoittaa, lyhyt Session-Timeout, jotta juuttunut työ todentaa itsensä uudelleen sen sijaan, että pitäisi istuntoa päiväkausia, ja Framed-IP-Address altaasta, jota palomuuritat toisella puolella. Sovelluksen valtuutus pysyy erillisenä: tunneli tietokantapalvelimeen ei ole lupa lukea siellä olevaa taulukkoa.

Vahvista hylkäykset, suunnittele sitten poisto

Toimiva käyttö ei todista mitään vähimmäisoikeuksista. Testaa sen sijaan hylkäykset: yhdistä työn identiteetillä ja yritä päästä luettelon ulkopuoliseen kohteeseen, avaa toinen samanaikainen istunto, jos yhdyskäytävän on tarkoitus sallia vain yksi, ja toista kirjautuminen tunnuksen peruuttamisen jälkeen.

Vahvista sitten sama istunto kahdessa paikassa. Yhdyskäytävän loki näyttää identiteetin, joka todennettiin; käytäntöpalvelimen loki näyttää, mikä käytäntö täsmäsi ja mitkä attribuutit se palautti. OpenVPN:ssä palvelin tallentaa varmenteen yleisnimen, ja strongSwanin ipsec statusall tulostaa muodostetun tunnelin käytössä olevan identiteetin kanssa. Jos kaksi lokia ovat eri mieltä identiteetistä, käytäntö täsmää johonkin muuhun kuin oletat.

Poisto kuuluu suunnitteluun, ei siivoussprinttiin. Kirjoita ylös kaikki poistettava (varmenne tai tili, ryhmäjäsenyys, verkkokäytäntö, altaan merkintä, palomuurisääntö kohteessa) ja aja se kerran, kun työ on helppo rakentaa uudelleen.

Jos aloitat tänään, etene tässä järjestyksessä: kirjoita resurssiluettelo, valitse identiteetti kolmella ehdolla, aseta raja käytäntöön ja harjoittele yksi hylkäys ennen kuin työ otetaan käyttöön.