Jaettu CA, erilliset ovet: yksi palvelu hyväksyntätiedostoa kohden

Varmenne, joka validoituu jaettua auktoriteettia vasten, on läpäissyt luottamustestin, ei jäsenyystestiä. Nämä kaksi päätöstä sekoitetaan usein, koska molemmat tapahtuvat yhteyden muodostuksen hetkellä, ja sekoittuminen pysyy näkymättömänä, kunnes palveluun hyväksytään joku, jonka ei pitäisi olla siellä. Korjaus ei ole toinen auktoriteetti; se on toinen päätös, tehty palvelukohtaisesti ja kirjattu sinne, missä daemon sen lukee. Pidä ne erillään, niin suurin osa tämän alueen sekaannuksesta katoaa.

Luotettu ketju ei kerro mitään palvelun jäsenyydestä

Kaksi palvelua voi hyväksyä saman myöntävän hierarkian ja silti niillä voi olla eri populaatiot. Yksi kannettava kuuluu ensimmäiseen eikä saa päästä toiseen, kun taas saman hierarkian muut asiakkaat todella kuuluvat sinne. Auktoriteetin poistaminen tuosta palvelusta lukitsisi pois kaikki, jotka käyttävät sitä laillisesti, joten työ on hyväksyntää, ei luottamusta.

Auttaa kuvitella kaksi lukkoa yhteen oveen. Varmenne avaa ulomman lukon ja palvelukohtainen päätös avaa sisemmän; kumpikaan ei korvaa toista. Palvelu, jossa on vain ulompi lukko, ei valvo jäsenyyttä lainkaan, se vain todentaa. Kirjoita molemmat päätökset ennen kuin muutat mitään, koska politiikkaa, joka on olemassa vain toimivan yhteyden muodossa, ei voi auditoida. Seuraava koskee sisempää lukkoa.

Tee valinnaisista ohituksista hyväksyntäportti

Asiakkaan asetushakemisto on yleensä mukavuus: sen tiedostot ohittavat niiden asiakkaiden asetukset, jotka ne nimeävät, ja asiakas ilman tiedostoa vain toimii palvelimen oletusarvoilla. Yksi direktiivi muuttaa mukavuuden portiksi, niin että puuttuva tiedosto tarkoittaa yhteyden hylkäämistä.

client-config-dir /etc/openvpn/service-a/clients
ccd-exclusive

Yhteisön julkaisu OpenVPN 2.6 ccd-exclusive dokumentoi käsikirjasivullaan juuri tämän ehdon, ja nimetyn tiedoston haku perustuu asiakkaan tehokkaaseen identiteettiin. Muut koontiversiot ja tuotehallitut palvelimet voivat poiketa, joten vahvista asennettu versio ennen kuin luotat samaan semantiikkaan muualla.

Käsittele yllä olevaa polkua esimerkkinä ja tarkista käyttöön otettu asettelu sen sijaan, että loisit hakemiston, jonka jokin opas keksi. Jätä olemassa olevat varmenteen tarkistukset, palvelimen identiteetin tarkistukset ja tilin todentaminen täsmälleen sellaisiksi kuin ne olivat, koska fragmentti lisää ehdon eikä poista mitään. Valmistele muutos ennen tuotantoa, koska väärässä kohdassa nostettu hylkäys näyttää varmenteen virheeltä ja ohjaa tutkinnan auktoriteettiin. Vahvista sen jälkeen, että hylätyn asiakkaan lokirivi nimeää puuttuvan asetustiedoston, ei ketjua.

Yksi hakemisto palvelua kohden, ei yksi jaettu luettelo

Jäsenyys kuuluu palvelulle, joka sitä valvoo, joten jokainen palvelu pitää oman hakemistonsa ja omat tiedostonsa. Kahden palvelun osoittaminen yhteen luetteloon saa ne jakamaan jäsenyyden riippumatta siitä, tarkoittiko joku sitä, ja syntyneen muutoksen jäljittäminen päätökseen on vaikeaa. Jaettu auktoriteetti voi pysyä jaettuna; hyväksyntätiedostot eivät voi. Niiden erillään pitäminen tarkoittaa myös, että yhden palvelun virhe ei voi hiljaa laajentaa toista.

DEFAULT-merkintä on tapaus, joka johtaa ihmisiä harhaan. Se tarjoaa varalla olevat asetukset, kun nimettyä tiedostoa ei löydy, mutta se ei ole se nimetty tiedosto, jota portti vaatii, joten se ei voi hyväksyä asiakasta yksinään. Testaa asiakas, jolla ei ole lainkaan merkintää, ja vahvista hylkäys; jos tämä asiakas hyväksytään, varalla oloa sovelletaan ja ccd-exclusive ei ole voimassa siinä instanssissa.

Tehokas identiteetti päättää, mikä tiedosto luetaan

Haku käyttää identiteettiä, jolla asiakas todella todennettiin, mikä on yleensä varmenteen yleinen nimi. Kun palvelin myös tarkistaa käyttäjätunnuksen ja salasanan ja yhdistää tämän nimen yleiseen nimeen, tiedoston on sen sijaan vastattava todennettua käyttäjätunnusta. Yhteensopimattomuus jättää hakemiston täyteen uskottavia tiedostonimiä, joita ei koskaan valita.

Lukeminen on toinen puoli. Daemon luopuu yleensä oikeuksistaan käynnistyksen jälkeen, joten vähennetyllä tilillä on oltava lukuoikeus hakemistoon ja jokaiseen sen merkintään. Asiakkaat eivät saa pystyä luomaan omaa merkintäänsä minkään kirjoitettavan polun kautta, koska itsepalveluhyväksyntä tekee mekanismista täysin tyhjän. Tarkista liitännän ja jaon käyttöoikeudet eikä vain tiedoston tilaa, koska hakemisto, joka näyttää suljetulta yhdelle tilille, voi olla avoin toiselle. Vahvista sitten, mitä tiliä käynnissä oleva prosessi todella käyttää, ei sitä, mitä tiliä unit-tiedosto mainitsee. Ne kaksi ovat samat vain silloin, kun mikään muu ei ole muuttanut niitä.

Tarkkaile hylkäystä, hyväksyntää ja peruutusta erikseen

Kokeile identiteettiä, joka kuuluu palveluun, ja vahvista, että se yhdistää. Kokeile kelvollista varmennetta ilman merkintää ja vahvista, että se hylätään. Kokeile identiteettiä, joka on hyväksytty toiseen palveluun, ja vahvista, ettei sitä hyväksytä tänne. Kirjaa palvelun instanssi ja tehokas identiteetti jokaisen tuloksen viereen, koska tulosta ilman tätä kontekstia ei kukaan muu voi toistaa.

Peruuttaminen on erillinen toimenpide kuin mitätöinti. Hyväksyntätiedoston muokkaaminen poistaa yhden palvelun oikeuden, kun identiteetti pysyy voimassa kaikkialla muualla, kun taas vaarantunut avain vaatii organisaation mitätöintivasteen. Päätä etukäteen, mitä jo avoinna oleville istunnoille tapahtuu, koska hakemiston muokkaus tai mitätöintiluettelo eivät lopeta niitä itsestään.

Hyväksyntä on myös vain ensimmäinen portti. Palveluun liittyminen ei kerro mitään sen takana olevista aliverkoista, tietokannoista tai hallintaliittymistä, ja se resurssipolitiikka on kirjoitettava ja testattava erikseen.