”Arkkitehtuuri

Vault on monimutkainen järjestelmä, jossa on monia eri osia. Tämä sivu dokumentoi järjestelmän arkkitehtuurin auttaakseen sekä Vaultin käyttäjiä että sen kehittäjiä rakentamaan henkisen mallin siitä, miten se toimii.

Ennen arkkitehtuurin kuvaamista tarjoamme termien sanaston, joka auttaa selventämään, mistä puhutaan:

• Säilytystietopohja – Säilytystietopohja vastaa salatun datan kestävästä säilytyksestä. Vault ei luota backendeihin, ja niiden odotetaan ainoastaan tarjoavan kestävyyttä. Storage backend konfiguroidaan, kun Vaultserver käynnistetään.

• Barrier – Barrier on salattua terästä ja betonia Vaultin ympärillä. Kaikki tiedot, jotka kulkevat Vaultin ja tallennuksen backendin välillä, kulkevat esteen läpi. Esteen avulla varmistetaan, että ulos kirjoitetaan vain salattua dataa ja että data tarkistetaan ja puretaan matkalla sisään. Aivan kuten pankkiholvissa, este on ”avattava” ennen kuin sen sisällä olevaan pääsee käsiksi.

• Salaisuusmoottori – Salaisuusmoottori vastaa salaisuuksien hallinnasta.Yksinkertaiset salaisuusmoottorit, kuten ”kv”-salaisuusmoottori, yksinkertaisesti palauttavat saman salaisuuden, kun sitä kysytään. Jotkin salaisuusmoottorit tukevat käytäntöjen käyttämistä salaisuuden luomiseksi dynaamisesti joka kerta, kun niitä kysytään. Tämä mahdollistaa ainutkertaisten salaisuuksien käytön, mikä antaa Vaultille mahdollisuuden tehdä hienojakoisia peruutuksia ja käytäntöjen päivityksiä. Esimerkkinä mainittakoon, että MySQL-salaisuusmoottoriin voidaan määrittää ”web”-käytäntö. Kun ”web”-salaisuus luetaan, luodaan uusi MySQL-käyttäjä/salasanapari, jolla on rajoitetut oikeudet web-palvelimelle.

• Tarkastuslaite – Tarkastuslaite vastaa tarkastuslokien hallinnasta.Jokainen pyyntö Vaultille ja vastaus Vaultilta kulkee configuredaudit-laitteiden kautta. Tämä tarjoaa yksinkertaisen tavan integroida Vault useisiin erityyppisiin audit-lokituskohteisiin.

• Auth-menetelmä – Auth-menetelmällä todennetaan käyttäjät tai sovellukset, jotka ovat yhteydessä Vaultiin. Kun auth-metodi on todennettu, se palauttaa luettelon sovellettavista käytännöistä, joita tulisi soveltaa. Vault ottaa todennetun käyttäjän ja palauttaa asiakastunnisteen, jota voidaan käyttää tulevissa pyynnöissä. Esimerkki: userpass auth-metodi käyttää käyttäjätunnusta ja salasanaa käyttäjän todentamiseen. Vaihtoehtoisesti github auth-metodi sallii käyttäjien todennuksen GitHubin kautta.

• Client Token – Asiakastunniste (alias ”Vault Token”) on käsitteellisesti samankaltainen kuin istuntoeväste verkkosivulla. Kun käyttäjä todennetaan, Vaultpalauttaa asiakastunnisteen, jota käytetään tulevissa pyynnöissä. Vault käyttää tunnusta asiakkaan henkilöllisyyden todentamiseen ja sovellettavien ACL-käytäntöjen noudattamiseen. Tämä tunniste välitetään HTTP-otsakkeiden kautta.

• Salaisuus – Salaisuus on termi kaikelle Vaultin palauttamalle luottamuksellista tai kryptografista materiaalia sisältävälle. Kaikki Vaultin palauttamat tiedot eivät ole salaisia, esimerkiksi järjestelmän konfiguraatioita, tilatietoja tai käytäntöjä ei pidetä salaisuuksina. Tämä tarkoittaa, että asiakkaat eivät voi olettaa, että salaisuuden sisältöä voidaan käyttää loputtomiin. Vault peruuttaa salaisuuden vuokrasopimuksen päättyessä, ja operaattori voi peruuttaa salaisuuden ennen vuokrasopimuksen päättymistä. Tämä sopimus Vaultin ja sen asiakkaiden välillä on kriittinen, koska se mahdollistaa avainten ja käytäntöjen muuttamisen ilman manuaalista väliintuloa.

• Palvelin – Vault on riippuvainen pitkäaikaisesta instanssista, joka toimii palvelimena. Vault-palvelin tarjoaa API:n, jonka kanssa asiakkaat ovat vuorovaikutuksessa, ja hallinnoi kaikkien salaisuusmoottoreiden välistä vuorovaikutusta, ACL:n noudattamista ja salaisuusvuokrasopimusten peruuttamista. Palvelinpohjainen arkkitehtuuri irrottaa asiakkaat tietoturva-avaimista ja -käytännöistä, mahdollistaa keskitetyn tarkastuksen kirjaamisen ja yksinkertaistaa operaattoreiden hallintaa.

”Korkean tason yleiskatsaus

Korkean tason yleiskatsaus Vaultista näyttää tältä:

Aloitetaanpa tämän kuvan purkaminen. On olemassa selkeä erottelu komponenttien välillä, jotka ovat turvaesteen sisällä tai ulkopuolella. Ainoastaan storagebackend ja HTTP API ovat ulkopuolella, kaikki muut komponentit ovat esteen sisäpuolella.

Tallennuksen backend on epäluotettava, ja sitä käytetään salattujen tietojen pysyvään tallentamiseen.Kun Vault-palvelin käynnistetään, sille on annettava tallennuksen backend, jotta tiedot ovat käytettävissä uudelleenkäynnistysten aikana. Vastaavasti HTTP API on käynnistettävä Holvi-palvelimen käynnistyksen yhteydessä, jotta asiakkaat voivat olla vuorovaikutuksessa sen kanssa.

Kun Holvi on käynnistetty, se on suljetussa tilassa. Ennen kuin Holviin voidaan suorittaa mitään toimintoja, se on purettava. Tämä tapahtuu antamalla unsealkeys. Kun Holvi alustetaan, se luo salausavaimen, jota käytetäänkaikkien tietojen suojaamiseen. Avain on suojattu pääavaimella. Vault käyttää oletusarvoisesti Shamirin salaisuudenjakoalgoritmiksi kutsuttua tekniikkaa, jolla pääavain jaetaan viiteen osaan, joista kolmea tarvitaan pääavaimen rekonstruoimiseksi.

Sekä jakojen määrä että vaadittu vähimmäiskynnys voidaan määrittää.Shamirin tekniikka voidaan poistaa käytöstä ja käyttää pääavainta suoraan salauksen purkamiseen. Kun Vault hakee salausavaimen, se pystyy purkamaan salausdatan tallennuksen backendissä ja siirtyy unsealed-tilaan. Kun sinetöinti on purettu, Vault lataa kaikki määritetyt audit-laitteet, auth-menetelmät ja secretsengines.

Näiden audit-laitteiden, auth-menetelmien ja secrets-moottoreiden konfigurointi on tallennettava Vaultiin, koska ne ovat arkaluonteisia. Vain käyttäjillä, joilla on oikeat oikeudet, pitäisi olla mahdollisuus muuttaa niitä, eli niitä ei voi määrittää esteen ulkopuolella. Kun ne tallennetaan Holviin, kaikki niihin tehtävät muutokset suojataan ACL-järjestelmällä ja niitä seurataan tarkastuslokien avulla.

Kun Holvi on avattu, HTTP-API:stä voidaan käsitellä pyyntöjä Coreen. Ytimen avulla hallitaan pyyntöjen kulkua järjestelmän läpi,valvotaan ACL:ien noudattamista ja varmistetaan, että audit-lokitukset tehdään.

Kun asiakas muodostaa ensimmäisen kerran yhteyden Holviin, sen on tunnistauduttava. Vault tarjoaa konfiguroitavissa olevia todennusmenetelmiä, jotka tarjoavat joustavuutta käytetyn todennusmekanismin suhteen. Ihmisystävällisiä mekanismeja, kuten käyttäjätunnus/salasana tai GitHub, voidaan käyttää operaattoreille, kun taas sovellukset voivat käyttää tunnistautumiseen julkisia/yksityisiä avaimia tai tunnuksia. Autentikointipyyntö kulkee ytimen kautta auth-metodiin, joka määrittää, onko pyyntö kelvollinen, ja palauttaa luettelon siihen liittyvistä käytännöistä.

Käytännöt ovat vain nimettyjä ACL-sääntöjä. Esimerkiksi ”root”-käytäntö on sisäänrakennettu ja sallii pääsyn kaikkiin resursseihin. Voit luoda minkä tahansa määrän nimettyjä käytäntöjä, joilla on hienojakoinen polkujen hallinta. Vault toimii yksinomaan valkoisen listan tilassa, mikä tarkoittaa, että toimintaa ei sallita, ellei pääsyä ole nimenomaisesti myönnetty käytännöllä. Koska käyttäjällä voi olla useita käytäntöjä, toiminto sallitaan, jos jokin käytäntö sallii sen. Politiikat tallennetaan ja niitä hallinnoidaan sisäisessä politiikkasäilössä. Tätä sisäistä varastoa käsitellään järjestelmän taustajärjestelmän kautta, joka on aina asennettu osoitteeseen sys/.

Kun todennus tapahtuu ja auth-menetelmä antaa joukon sovellettavia käytäntöjä, uusi asiakastunniste luodaan ja sitä hallinnoidaan tunnisteiden varastossa. Tämä asiakastunniste lähetetään takaisin asiakkaalle, ja sitä käytetään tulevien pyyntöjen tekemiseen.Tämä on samanlainen kuin eväste, jonka verkkosivusto lähettää käyttäjän kirjauduttua sisään. Asiakastunnisteeseen voi liittyä vuokrasopimus auth-menetelmämäärityksestä riippuen. Tämä tarkoittaa, että asiakastunniste voidaan joutua uusimaan määräajoin, jotta se ei mitätöityisi.

Todennuksen jälkeen pyynnöt tehdään asiakastunnisteen avulla. Tunnusta käytetään tarkistamaan, että asiakas on valtuutettu, ja lataamaan asiaankuuluvat käytännöt. Käytäntöjä käytetään asiakkaan pyynnön valtuuttamiseen. Pyyntö ohjataan sen jälkeen salaisuuksiin, jotka käsitellään sen tyypin mukaan. Jos secretsengine palauttaa salaisuuden, ydin rekisteröi sen expiration manageriin ja liittää siihen lease ID:n. Asiakkaat käyttävät vuokrasopimustunnusta salaisuutensa uusimiseen tai peruuttamiseen. Jos asiakas antaa vuokrasopimuksen vanhentua, expiration manager peruuttaa salaisuuden automaattisesti.

Ydin hoitaa pyyntöjen ja vastausten kirjaamisen audit-välittäjälle, joka välittää pyynnön kaikille määritetyille audit-laitteille. Pyyntövirran ulkopuolella ydin suorittaa tiettyjä taustatoimintoja. Vuokrasopimusten hallinta on tärkeää, koska sen avulla vanhentuneet asiakastunnisteet tai salaisuudet voidaan peruuttaa automaattisesti. Lisäksi Vault käsittelee tiettyjä osittaisia epäonnistumistapauksia käyttämällä kirjoitusennakkolokitusta ja rollback-hallintaa. Tätä hallitaan läpinäkyvästi ytimen sisällä, eikä se ole käyttäjän nähtävissä.

”Getting in Depth

Tämä on ollut lyhyt yleiskatsaus Vaultin arkkitehtuuriin. Jokaisesta osajärjestelmästä on saatavilla lisää yksityiskohtia.

Muista yksityiskohdista voit lukea koodista, kysyä IRC:ssä tai ottaa yhteyttä sähköpostilistalle.