“Architecture

A Vault egy komplex rendszer, amely sok különböző részből áll. Annak érdekében, hogy mind a felhasználók, mind a Vault fejlesztői felépíthessenek egy mentális modellt arról, hogyan működik, ez az oldal dokumentálja a rendszer architektúráját.

Az architektúra leírása előtt egy fogalomtárral segítünk tisztázni, hogy miről is van szó:

• Storage Backend – A storage backend felelős a titkosított adatok tartós tárolásáért. A Vault nem bízik a backendekben, és csak a tartósságot várják el tőlük. A tárolási backend a Vaultserver indításakor kerül beállításra.

• Barrier – A barrier a Vaultot körülvevő kriptográfiai acél és beton. Minden adat, amely a Vault és a tároló backend között áramlik, áthalad az akadályon. A gát biztosítja, hogy csak titkosított adatok kerüljenek kiírásra, és hogy az adatok befelé jövet ellenőrizve és visszafejtve legyenek. Hasonlóan egy banki trezorhoz, a korlátot “fel kell oldani”, mielőtt bármihez hozzáférhetünk benne.

• Titokmotor – A titokmotor felelős a titkok kezeléséért.Az egyszerű titokmotorok, mint a “kv” titokmotor, egyszerűen visszaadják az azonos titkot, amikor lekérdezik. Néhány titokmotor támogatja a házirendek használatát, hogy dinamikusan generáljon egy titkot minden egyes lekérdezéskor. Ez lehetővé teszi az egyedi titkok használatát, ami lehetővé teszi a Vault számára a finomszemcsés visszavonást és a házirend frissítését. Egy MySQL titokmotor például “web” házirenddel konfigurálható. A “web” titok olvasásakor egy új MySQL felhasználó/jelszó páros generálódik korlátozott jogosultságokkal a webkiszolgáló számára.

• Audit eszköz – Az audit eszköz felelős az audit naplók kezeléséért.Minden Vault-hoz érkező kérés és a Vault-tól érkező válasz a configuredaudit eszközökön keresztül megy. Ez egyszerű módot biztosít a Vault integrálására több különböző típusú auditnaplózási célállomással.

• Auth módszer – Az auth módszer a Vault-hoz csatlakozó felhasználók vagy alkalmazások hitelesítésére szolgál. A hitelesítés után az auth módszer visszaadja az alkalmazandó házirendek listáját, amelyeket alkalmazni kell. A Vault elfogad egy hitelesített felhasználót, és visszaad egy ügyfél-token-t, amely a jövőbeni lekérdezésekhez használható. A userpass auth módszer például felhasználónevet és jelszót használ a felhasználó hitelesítéséhez. Alternatívaként a github auth módszer lehetővé teszi a felhasználók számára a GitHub-on keresztül történő hitelesítést.

• Client Token – Az ügyfél token (más néven “Vault Token”) koncepcionálisan hasonlít a weboldalak munkamenet cookie-jaihoz. Miután a felhasználó hitelesíti magát, a Vaultvisszaad egy ügyfél-token-t, amelyet a jövőbeli kérésekhez használ. A tokent a Vault az ügyfél személyazonosságának ellenőrzésére és a vonatkozó ACL-szabályok érvényesítésére használja. Ez a token a HTTP fejléceken keresztül kerül átadásra.

• Titok – A titok a Vault által visszaküldött minden olyan dolog megnevezése, amely bizalmas vagy kriptográfiai anyagot tartalmaz. Nem minden, amit a Vault visszaküld, titkos, például a rendszerkonfiguráció, az állapotinformációk vagy a házirendek nem minősülnek titoknak. A titkok mindig rendelkeznek egy kapcsolódó bérleti idővel.Ez azt jelenti, hogy az ügyfelek nem feltételezhetik, hogy a titkos tartalmak korlátlan ideig használhatók. A Vault a bérlet végén visszavonja a titkot, és a bérlet lejárta előtt az üzemeltető közbeléphet, hogy visszavonja a titkot. Ez a szerződés a Vault és az ügyfelek között kritikus fontosságú, mivel lehetővé teszi a kulcsok és házirendek kézi beavatkozás nélküli módosítását.

• Server – A Vault egy hosszú távon futó példánytól függ, amely szerverként működik. A Vault szerver biztosítja az API-t, amellyel az ügyfelek kapcsolatba lépnek, és kezeli az összes titokmotor közötti interakciót, az ACL érvényesítését és a titokbérlet visszavonását. A szerver alapú architektúra függetleníti az ügyfeleket a biztonsági kulcsoktól és irányelvektől, lehetővé teszi a központi ellenőrzési naplózást és leegyszerűsíti az adminisztrációt az üzemeltetők számára.

“Magas szintű áttekintés

A Vault nagyon magas szintű áttekintése így néz ki:

Kezdjük el lebontani ezt a képet. Egyértelműen elkülönülnek azok a komponensek, amelyek a biztonsági korláton belül vagy kívül vannak. Csak a storagebackend és a HTTP API van kívül, az összes többi komponens a korláton belül van.

A storagebackend nem megbízható, és a titkosított adatok tartós tárolására szolgál.A Vault kiszolgáló indításakor egy storagebackenddel kell ellátni, hogy az adatok az újraindítások során is rendelkezésre álljanak. A HTTP API-t szintén el kell indítani a Vault-kiszolgálóval az indításkor, hogy az ügyfelek kölcsönhatásba léphessenek vele.

A Vault indítás után a Vault zárt állapotba kerül. Mielőtt bármilyen művelet elvégezhető lenne a Vaulton, azt fel kell oldani. Ez az unsealkeys megadásával történik. A Vault inicializálásakor generál egy titkosítási kulcsot, amely az összes adat védelmére szolgál. Ezt a kulcsot egy mesterkulcs védi. Alapértelmezés szerint a Vault a Shamir-féle titokmegosztási algoritmus néven ismert technikát használja a mesterkulcs 5 részre osztására, amelyek közül 3 bármelyik szükséges a mesterkulcs rekonstruálásához.

A részek száma és a minimálisan szükséges küszöbérték is megadható.A Shamir-technika kikapcsolható, és a mesterkulcsot közvetlenül a feloldáshoz lehet használni. Miután a Vault lekérte a titkosítási kulcsot, képes visszafejteni az adatokat a tároló háttértárban, és belép a titkosítás nélküli állapotba. A titkosítás feloldása után a Vault betölti az összes konfigurált ellenőrzési eszközt, auth módszert és secretsengine-t.

Az ellenőrzési eszközök, auth módszerek és secrets engines konfigurációját a Vaultban kell tárolni, mivel ezek biztonsági szempontból érzékenyek. Csak a megfelelő jogosultságokkal rendelkező felhasználók módosíthatják őket, ami azt jelenti, hogy az akadályon kívül nem módosíthatók. A Vaultban való tárolásukkal a változtatásokat az ACL-rendszer védi, és az ellenőrzési naplók nyomon követik őket.

A Vault feloldása után a HTTP API-ból a maghoz intézett kérések feldolgozhatók. A magot arra használják, hogy kezelje a kérések áramlását a rendszeren keresztül, érvényre juttassa az ACL-eket, és biztosítsa az ellenőrzési naplózást.

Amikor egy ügyfél először csatlakozik a Vaulthoz, hitelesítenie kell magát. A Vault konfigurálható hitelesítési módszereket biztosít, amelyek rugalmasságot biztosítanak a használt hitelesítési mechanizmusban. Az emberbarát mechanizmusok, mint például a felhasználónév/jelszó vagy a GitHub használható az üzemeltetők számára, míg az alkalmazások nyilvános/magánkulcsokat vagy tokeneket használhatnak a hitelesítéshez. A hitelesítési kérelem a core-on keresztül egy authmethodba kerül, amely meghatározza, hogy a kérelem érvényes-e, és visszaadja a kapcsolódó házirendek listáját.

A házirendek csak egy megnevezett ACL-szabály. Például a “root” házirend beépített, és minden erőforráshoz való hozzáférést engedélyez. Bármennyi megnevezett házirend hozható létre az elérési utak finomabb szabályozásával. A Vault kizárólag fehérlistás üzemmódban működik, ami azt jelenti, hogy a művelet nem engedélyezett, hacsak a hozzáférést nem engedélyezik kifejezetten egy házirenddel. Mivel egy felhasználóhoz több házirend is kapcsolódhat, egy művelet akkor engedélyezett, ha bármelyik házirend engedélyezi azt. A házirendeket egy belső házirend-tároló tárolja és kezeli. Ezt a belső tárolót a rendszer backendjén keresztül kezelik, amely mindig a sys/ címre van felcsatolva.

Mihelyt megtörténik a hitelesítés, és egy auth módszer megadja az alkalmazandó irányelveket, egy új ügyfél-token generálódik, amelyet a token tároló kezel. Ezt az ügyfél-token-t visszaküldik az ügyfélnek, és a jövőbeni kérésekhez használják.Ez hasonló ahhoz a sütihez, amelyet egy weboldal küld a felhasználó bejelentkezése után. Az ügyfélkódhoz az auth-módszer konfigurációjától függően bérleti szerződés is társulhat. Ez azt jelenti, hogy az ügyfél-token-t rendszeresen meg kell újítani az érvénytelenség elkerülése érdekében.

A hitelesítés után a kérések az ügyfél-token megadásával történnek. A tokent az ügyfél jogosultságának ellenőrzésére és a vonatkozó házirendek betöltésére használják. A házirendek segítségével engedélyezik az ügyfél kérését. A kérés ezután a titokmotorhoz kerül, amely a típusától függően kerül feldolgozásra. Ha a secretsengine egy titkot ad vissza, a mag regisztrálja azt a lejárat-kezelőnél, és hozzárendel egy bérleti azonosítót. A bérleti azonosítót az ügyfelek használják a titkuk megújítására vagy visszavonására. Ha egy ügyfél hagyja, hogy a bérlet lejárjon, a lejárati menedzserautomatikusan visszavonja a titkot.

A mag kezeli a kérések és válaszok naplózását az ellenőrzési bróker felé, amely a kérést az összes konfigurált ellenőrzési eszközre továbbítja. A kérésfolyamaton kívül a mag bizonyos háttértevékenységeket végez. A bérletkezelés kritikus fontosságú, mivel lehetővé teszi a lejárt ügyfél-tokenek vagy titkok automatikus visszavonását. Emellett a Vault bizonyos részleges hiba eseteket a rollback-kezelővel ellátott write ahead logging alkalmazásával kezel. Ezt a magon belül átláthatóan kezelik, és a felhasználó számára nem látható.

“Mélyebbre ásás

Ez egy rövid, magas szintű áttekintés volt a Vault architektúrájáról. Az egyes alrendszerekről további részletek állnak rendelkezésre.

A további részletekért nézd meg a kódot, kérdezz az IRC-ben vagy lépj kapcsolatba a levelezőlistával.