„Architektura

Vault je komplexní systém, který má mnoho různých částí. Abychom uživatelům i vývojářům Vaultu pomohli vytvořit mentální model jeho fungování, dokumentuje tato stránka architekturu systému.

Před popisem architektury uvádíme slovníček pojmů, který pomůže objasnit, o čem je řeč:

• Storage Backend – Úložný backend je zodpovědný za trvalé uložení zašifrovaných dat. Backendům Vault nedůvěřuje a očekává se od nich pouze zajištění trvanlivosti. Úložný backend se konfiguruje při spuštění serveru Vaultserver.

• Bariéra – Bariéra je kryptografická ocel a beton kolemVaultu. Všechna data, která proudí mezi Trezorem a backendem úložiště, procházejí bariérou. Bariéra zajišťuje, že se ven zapisují pouze zašifrovaná data a že se data na cestě dovnitř ověřují a dešifrují. Podobně jako bankovní trezor musí být bariéra „odpečetěna“, aby bylo možné přistupovat k čemukoli uvnitř.

• Secrets Engine – Secrets engine je zodpovědný za správu tajemství.Jednoduché secrets engines, jako je „kv“ secrets engine, jednoduše vracejí stejné tajemství při dotazu. Některé secrets engines podporují použití zásad pro dynamické generování tajemství při každém dotazu. To umožňuje používat unikátní tajemství, což Trezoru umožňuje provádět jemné revokace a aktualizace politik. Jako příklad lze uvést tajný stroj MySQL, který může být nakonfigurován s politikou „web“. Při načtení „webového“ tajemství bude vygenerován nový pár uživatel/heslo MySQL s omezenou sadou oprávnění pro webový server.

• Auditní zařízení – Auditní zařízení je zodpovědné za správu auditních protokolů. každý požadavek na Trezor a odpověď z Trezoru prochází konfiguračnímauditním zařízením. To poskytuje jednoduchý způsob, jak integrovat Vault s více cíliauditních protokolů různých typů.

• Auth metoda – Auth metoda se používá k ověřování uživatelů nebo aplikací, které se připojují k Vaultu. Po ověření vrátí metoda auth seznam použitelných zásad, které by měly být použity. Vault přijme autentizovaného uživatele a vrátí klientský token, který lze použít pro budoucí požadavky. Jako příklad lze uvést metodu userpass auth, která k ověření uživatele používá uživatelské jméno a heslo. Alternativně metoda github authumožňuje uživatelům ověřit se prostřednictvím služby GitHub.

• Klientský token – Klientský token (také známý jako „Vault Token“) je koncepčně podobný souboru cookie relace na webových stránkách. Jakmile se uživatel ověří, Vaultvrátí klientský token, který se použije pro budoucí požadavky. Token slouží službě Vault k ověření identity klienta a k vynucení příslušných politik ACL. Tento token je předáván prostřednictvím hlaviček HTTP.

• Tajemství – Tajemství je označení pro cokoli, co Trezor vrací a co obsahuje důvěrný nebo kryptografický materiál. Ne vše, co službaVault vrací, je tajemství, například konfigurace systému, stavové informace nebo politiky nejsou považovány za tajemství. S tajemstvím je vždy spojen pronájem.To znamená, že klienti nemohou předpokládat, že obsah tajemství lze používat donekonečna. Vault odvolá tajemství na konci pronájmu a operátor může zasáhnout a odvolat tajemství před koncem pronájmu. Tatosmlouva mezi Vaultem a jeho klienty je kritická, protože umožňuje změnyklíčů a zásad bez ručního zásahu.

• Server – Vault závisí na dlouhodobě běžící instanci, která funguje jako server. Server Vault poskytuje rozhraní API, s nímž klienti komunikují, a spravuje interakci mezi všemi motory tajemství, vynucování ACL a odvolávání pronájmu tajemství. Architektura založená na serveru odděluje klienty od bezpečnostních klíčů a zásad, umožňuje centralizované protokolování auditů a zjednodušuje správu pro operátory.

„Přehled na vysoké úrovni

Velmi vysoký přehled služby Vault vypadá takto:

Začněme tento obrázek rozebírat. Je zde zřetelné odděleníkomponent, které jsou uvnitř nebo vně bezpečnostní bariéry. Pouze storagebackend a HTTP API jsou vně, všechny ostatní komponenty jsou uvnitř bariéry.

Storage backend je nedůvěryhodný a slouží k trvalému ukládání zašifrovaných dat. když je server Vault spuštěn, musí mu být poskytnut storage backend, aby byla data dostupná i při restartech. Podobně musí být při spuštění serveru Trezor spuštěno rozhraní HTTP API, aby s ním klienti mohli komunikovat.

Po spuštění je Trezor v zapečetěném stavu. Před provedením jakékoli operace na Trezoru musí být Trezor odpečetěn. To se provádí poskytnutím unsealkeys. Při inicializaci Trezor vygeneruje šifrovací klíč, který se používák ochraně všech dat. Tento klíč je chráněn hlavním klíčem. Ve výchozím nastavení používá Trezor techniku známou jako Shamirův algoritmus sdílení tajemství k rozdělení hlavního klíče na 5 podílů, z nichž libovolné 3 jsou nutné k rekonstrukci hlavního klíče.

Počet podílů i minimální požadovaný práh lze určit.Shamirovu techniku lze vypnout a k odpečetění použít přímo hlavní klíč. Jakmile Trezor získá šifrovací klíč, je schopen dešifrovatdata v backendu úložiště a přejde do stavu odpečetění. Jakmile je stav odpečetěn,Trezor načte všechna nakonfigurovaná auditní zařízení, autentizační metody a secretsenginy.

Konfigurace těchto auditních zařízení, autentizačních metod a secretsenginů musí být uložena v Trezoru, protože jsou bezpečnostně citlivé. Měli by je mít možnost upravovat pouze uživatelé se správnými oprávněními, což znamená, že je nelze specifikovat mimo bariéru. Tím, že jsou uloženy ve Vaultu, jsou všechny jejich změny chráněny systémem ACL a sledovány pomocí auditních protokolů.

Po odpečetění Vaultu lze zpracovávat požadavky z HTTP API na jádro. Jádro slouží ke správě toku požadavků systémem,vynucuje ACL a zajišťuje protokolování auditů.

Když se klient poprvé připojí k Trezoru, musí se ověřit. Vault poskytujekonfigurovatelné autentizační metody, které poskytují flexibilitu v použitém autentizačním mechanismu. Pro operátory mohou být použity lidsky přívětivé mechanismy, jako je uživatelské jméno/heslo nebo GitHub, zatímco aplikace mohou k autentizaci používat veřejné/soukromé klíče nebo tokeny. Požadavek na ověření prochází jádrem a vstupuje do metody authmethod, která určí, zda je požadavek platný, a vrátí seznam souvisejících zásad.

Zásady jsou pouze pojmenovaná pravidla ACL. Například politika „root“ je vestavěnáa povoluje přístup ke všem prostředkům. Můžete vytvořit libovolný počet pojmenovaných zásads jemným řízením cest. Vault pracuje výhradně v režimu bílé listiny, což znamená, že pokud není přístup výslovně povolen prostřednictvím zásady, není akce povolena. Protože uživatel může mít přiřazeno více zásad, je akce povolena, pokud ji některá ze zásad povoluje. Zásady jsou ukládány a spravovány interním úložištěm zásad. S tímto interním úložištěm se manipuluje prostřednictvím systémového backendu,který je vždy připojen na adrese sys/.

Jakmile proběhne autentizace a metoda auth poskytne sadu použitelnýchpolitik, je vygenerován nový klientský token, který je spravován úložištěm tokenů. Tentoklientský token je odeslán zpět klientovi a je používán k provádění budoucích požadavků. je to podobné jako soubor cookie odeslaný webovou stránkou po přihlášení uživatele. Ke klientskému tokenu může být přiřazen pronájem v závislosti na konfiguraci metody auth. To znamená, že klientský token může být nutné pravidelně obnovovat, aby se zabránilo jeho zneplatnění.

Po ověření jsou požadavky prováděny s použitím klientského tokenu. Token se používá k ověření, zda je klient autorizován, a k načtení příslušných zásad. Tyto politiky se použijí k autorizaci požadavku klienta. Požadavek je poté směrován na secrets engine, který je zpracován v závislosti na jeho typu. Pokud secretsengine vrátí tajemství, jádro jej zaregistruje u správce vypršení platnosti a připojí ID pronájmu. ID pronájmu používají klienti k obnovení nebo odvolání svého tajemství. Pokud klient dovolí, aby platnost pronájmu vypršela, správce expiraceautomaticky zruší platnost tajemství.

Jádro zpracovává protokolování požadavků a odpovědí na audit broker, kterýrozesílá požadavky na všechna nakonfigurovaná auditní zařízení. Mimo tok požadavků provádí jádro určité činnosti na pozadí. Správa pronájmů je kritická, protože umožňuje automatické odvolání prošlých klientských tokenů nebo tajemství. Kromě toho Trezor řeší některé případy částečného selhání pomocí protokolování zápisů dopředu se správcem vrácení. Toto je řízeno transparentněv rámci jádra a není viditelné pro uživatele.

„Getting in Depth

Toto byl stručný přehled architektury Vaultu na vysoké úrovni. Pro každý z podsystémů jsou k dispozici další podrobnosti.

Pro další podrobnosti se buď podívejte do kódu, zeptejte se na IRC nebo se obraťte namailing list.