„Architektura

Vault jest złożonym systemem, który składa się z wielu różnych części. Aby pomóc zarówno użytkownikom, jak i twórcom programu Vault w zbudowaniu mentalnego modelu jego działania, ta strona dokumentuje architekturę systemu.

Przed opisem architektury przedstawiamy słowniczek pojęć, który pomoże wyjaśnić, o czym jest mowa:

• Storage Backend – Storage Backend jest odpowiedzialny za trwałe przechowywanie zaszyfrowanych danych. Vault nie ufa tym backendom i oczekuje od nich jedynie zapewnienia trwałości danych. Zaplecze pamięci masowej jest konfigurowane podczas uruchamiania serwera Vaultserver.

• Bariera – Barierę stanowi stal kryptograficzna i beton wokół skarbca. Przez barierę przechodzą wszystkie dane przepływające między skarbcem a zapleczem magazynowym. Bariera zapewnia, że tylko zaszyfrowane dane są wypisywane, a po drodze są weryfikowane i odszyfrowywane. Podobnie jak w przypadku bankuvault, bariera musi zostać „odpieczętowana”, zanim będzie można uzyskać dostęp do czegokolwiek, co znajduje się w środku.

• Secrets Engine – Silnik sekretów jest odpowiedzialny za zarządzanie sekretami.Proste silniki sekretów, takie jak silnik sekretów „kv”, po prostu zwracają samesecret, gdy są o niego pytane. Niektóre silniki sekretów wspierają używanie polityk do dynamicznego generowania sekretów przy każdym zapytaniu. Pozwala to na użycie unikalnych sekretów, co pozwala Vault na drobnoziarniste unieważnianie i aktualizacje polityki. Dla przykładu, silnik sekretów MySQL może być skonfigurowany z polityką „web”. Kiedy sekret „web” zostanie odczytany, zostanie wygenerowana nowa para użytkownik/hasło MySQL z ograniczonym zestawem uprawnień dla serwera WWW.

• Urządzenie audytowe – Urządzenie audytowe jest odpowiedzialne za zarządzanie logami audytu.Każde żądanie do Vault i odpowiedź z Vault przechodzi przez configuredaudit devices. Zapewnia to prosty sposób integracji programu Vault z wieloma miejscami docelowymi dla dzienników audytowych różnych typów.

• Metoda autoryzacji – Metoda autoryzacji służy do uwierzytelniania użytkowników lub aplikacji łączących się z programem Vault. Po uwierzytelnieniu metoda auth zwraca listę stosownych zasad, które powinny zostać zastosowane. Vault przyjmuje uwierzytelnionego użytkownika i zwraca token klienta, który może być użyty do przyszłych zapytań. Przykładowo, metoda userpass auth używa nazwy użytkownika i hasła do uwierzytelnienia użytkownika. Alternatywnie, metoda github auth pozwala użytkownikom uwierzytelniać się za pośrednictwem GitHub.

• Token klienta – Token klienta (aka „Token Vault”) jest koncepcyjnie podobny do pliku cookie sesji w witrynie internetowej. Gdy użytkownik dokona uwierzytelnienia, Vault zwraca token klienta, który jest używany w przyszłych żądaniach. Token ten jest używany przez Vault do weryfikacji tożsamości klienta i egzekwowania odpowiednich zasad ACL. Ten token jest przekazywany za pośrednictwem nagłówków HTTP.

• Sekret – Sekret to termin określający wszystko, co jest zwracane przez Vault, a co zawiera materiał poufny lub kryptograficzny. Nie wszystko zwracane przez Vault jest sekretem, na przykład konfiguracja systemu, informacje o statusie czy polityki nie są uważane za sekrety. Sekrety zawsze mają powiązany okres dzierżawy, co oznacza, że klienci nie mogą zakładać, że zawartość sekretu może być używana w nieskończoność. Vault wycofa sekret na koniec okresu dzierżawy, a operator może interweniować, by wycofać sekret przed upływem okresu dzierżawy. Ta umowa między Vault a jego klientami jest krytyczna, ponieważ pozwala na zmiany kluczy i polityk bez ręcznej interwencji.

• Serwer – Vault zależy od długo działającej instancji, która działa jako serwer. Serwer Vault udostępnia API, z którym klienci wchodzą w interakcję, i zarządza interakcją między wszystkimi silnikami sekretów, egzekwowaniem ACL i unieważnianiem dzierżawy sekretów. Architektura oparta na serwerze oddziela klientów od kluczy bezpieczeństwa i polityk, umożliwia scentralizowane rejestrowanie audytów i upraszcza administrację dla operatorów.

„High-Level Overview

Przegląd Vault na bardzo wysokim poziomie wygląda następująco:

Zacznijmy rozkładać ten obraz. Istnieje wyraźne rozdzielenie komponentów, które znajdują się wewnątrz lub na zewnątrz bariery bezpieczeństwa. Na zewnątrz znajdują się tylko stacja bazowa pamięci masowej i interfejs API HTTP, a wszystkie inne komponenty znajdują się wewnątrz bariery.

Stacja bazowa pamięci masowej jest niezaufana i służy do trwałego przechowywania zaszyfrowanych danych.Kiedy serwer Vault jest uruchamiany, musi mieć zapewnioną stację bazową pamięci masowej, aby dane były dostępne po ponownym uruchomieniu. Podobnie interfejs API HTTP musi być uruchamiany przez serwer Vault przy starcie, aby klienci mogli z nim współdziałać.

Po uruchomieniu serwer Vault znajduje się w stanie zapieczętowanym. Przed wykonaniem jakiejkolwiek operacji na skarbcu musi on zostać odpieczętowany. Dokonuje się tego przez podanie klucza unsealkeys. Gdy skarbiec jest inicjalizowany, generuje klucz szyfrujący, który jest używany do ochrony wszystkich danych. Klucz ten jest chroniony przez klucz główny. Domyślnie Vault używa techniki znanej jako algorytm Shamira do dzielenia klucza głównego na 5 udziałów, z których 3 dowolne są wymagane do zrekonstruowania klucza głównego.

Można określić zarówno liczbę udziałów, jak i minimalny wymagany próg.Technikę Shamira można wyłączyć, a klucz główny użyć bezpośrednio do odpieczętowania. Gdy Vault pobierze klucz szyfrujący, jest w stanie odszyfrować dane znajdujące się na zapleczu pamięci masowej i przechodzi w stan odpieczętowania. Po odpieczętowaniu Vault ładuje wszystkie skonfigurowane urządzenia audytowe, metody autoryzacji i silniki sekretów.

Konfiguracja tych urządzeń audytowych, metod autoryzacji i silników sekretów musi być przechowywana w Vault, ponieważ są one wrażliwe pod względem bezpieczeństwa. Tylko użytkownicy z odpowiednimi uprawnieniami powinni móc je modyfikować, co oznacza, że nie mogą być one modyfikowane poza barierą. Przechowując je w Vault, wszelkie ich zmiany są chronione przez system ACL i śledzone przez dzienniki audytu.

Po odpieczętowaniu Vault żądania mogą być przetwarzane z HTTP API do rdzenia. Rdzeń służy do zarządzania przepływem żądań przez system, egzekwowania list ACL i zapewniania rejestrowania audytów.

Kiedy klient po raz pierwszy łączy się z Vault, musi się uwierzytelnić. Vault udostępnia konfigurowalne metody uwierzytelniania, zapewniając elastyczność w zakresie stosowanego mechanizmu uwierzytelniania. Mechanizmy przyjazne dla człowieka, takie jak nazwa użytkownika/hasło lub GitHub, mogą być używane przez operatorów, podczas gdy aplikacje mogą używać kluczy publicznych/prywatnych lub tokenów do uwierzytelniania. Żądanie uwierzytelnienia przepływa przez rdzeń do autometody, która określa, czy żądanie jest ważne i zwraca listę powiązanych polityk.

Polityki są po prostu nazwanymi regułami ACL. Na przykład, polityka „root” jest wbudowana i zezwala na dostęp do wszystkich zasobów. Można utworzyć dowolną liczbę nazwanych reguł z precyzyjną kontrolą nad ścieżkami. Program Vault działa wyłącznie w trybie białej listy, co oznacza, że jeśli dostęp nie zostanie wyraźnie przyznany za pośrednictwem zasad, działanie nie jest dozwolone. Ponieważ użytkownik może mieć przypisanych wiele polityk, czynność jest dozwolona, jeśli zezwala na nią jakakolwiek polityka. Polityki są przechowywane i zarządzane przez wewnętrzny magazyn polityk. Ten wewnętrzny magazyn jest obsługiwany przez backend systemu, który jest zawsze zamontowany pod adresem sys/.

Po uwierzytelnieniu i dostarczeniu przez metodę auth zestawu odpowiednich polityk, generowany jest nowy token klienta, który jest zarządzany przez magazyn tokenów. Thisclient token is sent back to the client, and is used to make future requests.This is similar to a cookie sent by a website after a user logs in. Token klienta może mieć dzierżawę związaną z nim w zależności od konfiguracji auth methodconfiguration. Oznacza to, że token klienta może wymagać okresowego odnawiania, aby uniknąć unieważnienia.

Po uwierzytelnieniu, żądania są wykonywane przy użyciu tokena klienta. Token jest wykorzystywany do weryfikacji, czy klient jest autoryzowany i do załadowania odpowiednich polityk. Polityki te są wykorzystywane do autoryzacji żądania klienta. Żądanie jest następnie kierowane do silnika sekretów, który jest przetwarzany w zależności od jego typu. Jeśli silnik sekretów zwróci sekret, rdzeń rejestruje go w menadżerze wygasania i nadaje mu identyfikator dzierżawy. Identyfikator ten jest używany przez klientów do odnawiania lub unieważniania ich sekretów. Jeśli klient pozwoli na wygaśnięcie dzierżawy, menedżer wygaśnięcia automatycznie unieważnia sekret.

Rdzeń obsługuje rejestrowanie żądań i odpowiedzi do brokera audytowego, który rozsyła żądanie do wszystkich skonfigurowanych urządzeń audytowych. Poza przepływem żądań, rdzeń wykonuje pewne czynności w tle. Zarządzanie dzierżawą jest krytyczne, ponieważ pozwala na automatyczne unieważnienie wygasłych tokenów lub sekretów klienta. Dodatkowo, Vault obsługuje pewne przypadki częściowej awarii poprzez użycie logowania wyprzedzającego zapis z menedżerem cofania. Jest to zarządzane transparentnie wewnątrz rdzenia i nie jest widoczne dla użytkownika.

„Getting in Depth

To był krótki, wysokopoziomowy przegląd architektury Vault. Więcej szczegółów jest dostępnych dla każdego z podsystemów.

W celu uzyskania innych szczegółów, należy zapoznać się z kodem, zapytać na IRC lub wejść na listę mailingową.