Rosnący wciąż poziom informatyzacji w firmach, skutkujący stale zwiększającą się liczbą współpracujących ze sobą systemów i aplikacji stanowiących jeden ogromny złożony organizm, jak również tych samodzielnych, często zapomnianych i ginących w gąszczu setek innych im podobnych, powoduje chaos, nad którym czasami trudno zapanować. Wciąż poszukujemy skutecznego rozwiązania mającego na celu zarówno zwiększenie bezpieczeństwa, jak i kontroli, nie utrudniając przy tym pracy sobie i innym. Gdy dodamy do tego istnienie wielu równoległych, często niezależnych od siebie i luźno tylko powiązanych ze sobą bytów w postaci jednostek organizacyjnych firmy, z których każda zarządza pewnym tylko kawałkiem naszej infrastruktury, zadanie takie jest dosyć karkołomne. Pragniemy nad tym zapanować, konsolidując pewne działania, jak chociażby centralne przyznawanie uprawnień czy kontrola dostępu do informacji niejawnych.
Spis treści:
- Czym jest HashiCorp Vault
- Dlaczego HashiCorp Vault?
- Czy to znaczy, że HashiCorp Vault nie ma wad?
- Jak zbudowany jest Vault?
- Zarządzanie jednostkami
- Tokeny
- Opcje instalacji i pamięć masowa
- Zarządzanie Vaultem
- Licencjonowanie i support
- Podsumowanie
To właśnie informacje poufne, które chcemy zabezpieczyć przed niepożądanym dostępem, stanowią dla nas duże wyzwanie, bo nie wystarczy przecież taką informację ukryć i dać odpowiednim jednostkom uprawnienia, należy jeszcze takie dostępy stale kontrolować. Wycieki informacji poufnych są w dzisiejszych czasach plagą, z którą boryka się wiele, na pierwszy rzut oka dobrze przygotowanych firm, w których po głębszej analizie, najczęściej niestety dokonywanej już po fakcie, okazuje się, że sekrety zabezpieczone owszem były, ale kontrola i audyt jednostek mających do nich dostęp już dosyć mocno szwankowały.
Weźmy dla przykładu ludzi, którzy odchodzą z pracy. Rotacja zasobów ludzkich w firmach jest naturalną rzeczą, tylko odpowiedzmy sobie na pytanie, jak często po utracie pracownika, znającego chociażby hasła do systemów, takie hasła zmieniamy? Naturalnie, blokowane są dostępy, konta imienne, ale jak wiele informacji pozostaje niezmienionych? Rzecz jasna trudno sobie wyobrazić rotację haseł w dziesiątkach czy nawet setkach systemów każdorazowo po odejściu pracownika, ale odpowiednie podejście do tematu i konfiguracja systemów z wykorzystaniem dedykowanych do tego celu narzędzi zdecydowanie pomoże nam zaoszczędzić sobie problemów nieautoryzowanego dostępu czy wycieku poufnych danych, które mogą nas drogo kosztować.
Jak zatem poradzić sobie z tematem zarządzania informacjami niejawnymi? Jednym z rozwiązań jest HashiCorp Vault.
Czym jest HashiCorp Vault
HashiCorp Vault jest narzędziem, które pozwala nam kompleksowo i wszechstronnie zarządzać poufnymi danymi w infrastrukturze IT naszej firmy. No dobrze, ale czym są te poufne dane? Czym są sekrety? Sekretem może być wszystko, co chcemy ukryć lub do czego chcemy ograniczyć dostęp. Mogą to być hasła dostępowe do serwerów, klucze certyfikatów SSL, fragmenty konfiguracji oprogramowania czy chociażby poufne raporty. Sekretami mogę być też dane przesyłane pomiędzy systemami, ale również same certyfikaty dostępowe, dzięki którym serwery komunikują się ze sobą, a którymi niekoniecznie chcemy się dzielić. Istotą sekretu jest to, że chcemy mieć go pod kontrolą, a kontrolę taką trudno uzyskać bez odpowiedniego narzędzia.
Dlaczego HashiCorp Vault?
Decydując się na to rozwiązanie, przede wszystkim otrzymujemy bezpieczne, centralne narzędzie do przechowywania i zarządzania informacjami niejawnymi – bezpieczne pod warunkiem właściwej konfiguracji i administracji, kontroli dostępu i odpowiedniego zarządzania politykami oraz czasem życia tokenów. Dlaczego wszechstronne? Bo Vault posiada możliwości znacznie wykraczające poza typowe przechowywanie sekretów typu klucz-wartość. Umożliwia chociażby szyfrowanie danych, dynamiczne sekrety, anonimizację tekstów czy generowanie certyfikatów SSL i kluczy dostępu.
Jest bezpieczne ze względu na poziom szyfrowania danych, ale również dzięki sposobowi, w jaki sekrety są udostępniane – użytkownik nawet nie musi znać hasła, którym się posługuje. Jego dostęp może być tymczasowy i w każdej chwili odebrany lub przyznany na określony czas. Natomiast centralne zarządzanie polega na tym, że zmiana hasła w jednym systemie (niech to będzie baza danych) nie powoduje konieczności propagowania tego hasła we wszystkich systemach, które z niego korzystają.
Czy to znaczy, że HashiCorp Vault nie ma wad?
Niestety ma. Chyba trudno znaleźć oprogramowanie całkowicie pozbawione wad. Nie inaczej jest i tym przypadku. HCP Vault jest dosyć trudny. Powiedziałbym, że ma wysoki tzw. próg wejścia. Pewnych rzeczy konfiguracyjnych zwyczajnie nie przeskoczymy, a dodając do tego fakt, że wszystko jest w nim oparte o ścieżki, co nie jest zbyt intuicyjne (odnosząc się do innych programów tego typu) oraz to, że do większości czynności administracyjnych będziemy potrzebować dostępu poprzez API bądź CLI, otrzymujemy produkt, którego „okiełznanie” może zająć nam trochę czasu.
Czy zatem warto? Parafrazując klasyka: może i ten Vault ma jakieś wady, chodzi jednak o to, aby te wady nie przysłoniły nam zalet. Oczywiście, że warto. HCP Vault jest fantastycznym narzędziem i zdecydowanie warto mu poświęcić trochę czasu, a wysiłek włożony w konfigurację będzie bardzo procentował w przyszłości.
Jak zbudowany jest Vault?
HCP Vault jak większość nowoczesnych aplikacji ma budowę modułową, czyli składa się z elementów, które ze sobą współpracują, ale każdy jest do pewnego stopnia niezależny i odpowiada za coś innego.
Większość modułów znajduje się za tzw. barierą. Oznacza to mniej więcej tyle, że wszystko, co jest wewnątrz bariery, traktowane jest przez Vaulta jako zaufane, natomiast wszystkie dane opuszczające barierę są automatycznie szyfrowane. Można zauważyć, że Storage Backend, służący do fizycznego przechowywania danych, nie znajduje się wewnątrz bariery, co sugeruje, że nie jest on traktowany jako bezpieczny moduł. Tak jest w istocie, wszystkie dane znajdujące się w pamięci masowej są szyfrowane i przekazywane do samego Vaulta również w postaci zaszyfrowanej.
Każdy moduł pełni jakąś określoną funkcję, ale patrząc na architekturę Vaulta nie można oprzeć się wrażeniu, że niektóre wydają się być ważniejsze od innych. W gruncie rzeczy tak jest, bo porównując chociażby Secret Engine do Rollback Managera widzimy na pierwszy rzut oka, że ten pierwszy pełni o wiele ważniejszą, przynajmniej z punktu widzenia użytkownika, rolę. Ważniejszą, ale w dalszym ciągu jego funkcja jest tylko jedną z wielu i to właśnie wszystkie współpracujące ze sobą moduły sprawiają, że Vault stanowi narzędzie kompletne i wszechstronne.
Secret Engines
Czym właściwie są? Secret Engines to prawdopodobnie najbardziej kluczowy element całego Vaulta. Można go określić jako rdzeń funkcjonalny. Silniki sekretów są pewnym zestawem funkcji umożliwiających wykonanie określonych czynności, jak przechowywanie sekretów, generowanie kluczy i certyfikatów, szyfrowanie danych czy nawet wykonywanie pewnych działań w systemach zewnętrznych poprzez konta serwisowe w tychże systemach.
Secret Engines umożliwiają zarówno anonimizację i zamianę tekstu według określonego klucza, jak i zarządzanie użytkownikami w chmurach publicznych. Dlatego to one decydują o możliwościach tego narzędzia i są kluczowym elementem Vaulta. Silniki sekretów, dla lepszej przejrzystości, pogrupowane są w trzech kategoriach: Generic, Cloud i Infra.
Jak się zalogować?
Podstawową i jednocześnie jedyną dostępną po zainstalowaniu HCP Vaulta metodą autoryzacji są tokeny. Nie możemy ich wyłączyć i możemy z nich skorzystać zawsze. Wszystkie inne metody są opcjonalne i również tutaj podzielone na 3 kategorie:
- Generic – czyli ogólne, np. user/password czy certyfikaty;
- Cloud wykorzystujący uwierzytelnienie zewnętrzne, jak chociażby chmury publiczne;
- Infra, które wymagają systemów zarządzania tożsamością, jak LDAP czy OKTA.
W przypadku korzystania z API lub CLI najczęściej korzystamy jednak z tokenów. Są one też podstawowym sposobem kontroli dostępu, ściśle związanym z politykami – nawet uwierzytelnienie user/password niejawnie korzysta z generowanych automatycznie tokenów.
Widzimy klasyczny trójkąt obrazujący sposób korzystania z Vaulta z punktu widzenia użytkownika bądź systemu, w którym poprzez jedną z dostępnych metod uwierzytelnienia logujemy się do Vaulta i zakładając ,że posiadamy odpowiednie, określone w politykach uprawnienia, otrzymujemy dostęp do danego silnika sekretów.
Polityki
No właśnie, czym są wspomniane już wcześniej polityki? Klasyczny model dostępu do aplikacji zakłada odseparowanie procesu uwierzytelnienia od autoryzacji. Po zalogowaniu użytkownik znajduje się w aplikacji, ale nie ma w niej żadnych uprawnień. Uprawnienia do wykonywania w systemie określonych czynności otrzymuje dopiero po autoryzacji. Właśnie za proces autoryzacji odpowiadają polityki.
Polityki to nic innego jak klasyczny RBAC (ang. Role Base Access Control) znany z większości programów z kontrolą dostępu z tą różnicą jednak, że Vault, nawet w graficznym interfejsie użytkownika, nie oferuje standardowego sposobu na ich przyznawanie. Pisania polityk musimy się nauczyć i niestety jest to jedno z trudniejszych działań, z którymi przyjdzie nam się zmierzyć. Możemy do tego celu wykorzystać znany również z innych produktów HashiCorpa język HCL (ang. HashiCorp Configuration Language) lub JSON (ang. JavaScript Object Notation).
Domyślnie HCP Vault zawiera dwie polityki – „default”, która poza uprawnieniami do zarządzania własnym tokenem daje także dostęp do jedynego domyślnie zainicjowanego silnika sekretów, jakim jest Cubbyhole oraz „root”, która daje wszystkie możliwe uprawnienia w systemie. Tej jednak nie możemy przydzielić nikomu poza rootem. Polityki roota nie możemy także modyfikować ani usunąć.
Pisania polityk musimy się nauczyć, co więcej, musimy to zrobić już praktycznie na samym początku. Modyfikacja domyślnej polityki raczej nie jest dobrym pomysłem. Odpowiednią praktyką jest tworzenie własnych i to niezbyt rozbudowanych, również dlatego, że jednej jednostce (lub tokenowi) możemy przydzielić praktycznie dowolną ich liczbę. Warto ustalić pewien schemat nazewnictwa, którego będziemy się trzymać, gdyż jedyną skuteczną metodą ich wyszukiwania, przynajmniej z poziomu graficznego interfejsu użytkownika, jest filtrowanie po nazwie.
Zarządzanie jednostkami
Czym w ogóle jest jednostka? O jednostkach wspomnieliśmy już przy okazji omawiania polityk, ale warto poświęcić temu tematowi nieco więcej uwagi. Jednostką jest osoba, aplikacja czy serwer logujący się do Vaulta. Przy czym należy wspomnieć, że nie ma znaczenia, jak wiele metod uwierzytelnienia jej udostępnimy, w dalszym ciągu jest to jedna jednostka.
Jednak skoro jedna jednostka może korzystać z wielu różnych metod logowania, musi istnieć jakiś system, aby je wszystkie do tej jednostki przypisać. Do tego celu służą aliasy.
Aliasy to nic innego jak metody uwierzytelnienia, np. token czy userpass oraz zewnętrzne konta, jak GitHub czy katalog AD, przypisane do danej jednostki.
Tokeny
Podstawową metodą uwierzytelniania, dostępną bezpośrednio po odpieczętowaniu Vaulta, są tokeny. Tokenów nie możemy dezaktywować czy usunąć również dlatego, że bez względu na to, jakiej metody uwierzytelnienia użyjemy i tak Vault wygeneruje nam niejawnie token, który możemy skopiować w celu dalszego użycia. Po ponownym zalogowaniu token jest już zupełnie inny.
Innym sposobem na uwierzytelnienie jest silnik Cubbyhole, który zgodnie z definicją przechowuje sekrety tak długo, jak długo token jest aktywny. Po ponownym zalogowaniu nasz sekret znika.
Jawne generowanie tokenu, czy to przypisanego do jednostki, czy też nie (bo istnieją również takie) odbywa się poprzez interfejs CLI lub API. Określamy jego typ i parametry oraz czas życia (TTL), po którym token przestaje być aktywny. Wśród parametrów, które możemy zdefiniować, są między innymi: możliwość odnowienia, maksymalny czas życia, po którym token przestaje być odnawialny czy możliwość tworzenia tokenów podrzędnych.
Specjalnym typem tokena są tokeny wsadowe (ang. batch tokens). Są to zaszyfrowane duże obiekty binarne (obiekty typu blob), które zawierają wystarczającą ilość informacji do wykonywania działań w programie Vault. Tokeny wsadowe są jednak dosyć specyficzne i używane w zupełnie odmienny sposób niż tokeny usług, czyli te, na których się skupimy. Ponadto nie posiadają one większości cech tokenów usług – między innymi są nieodnawialne, nie mogą tworzyć tokenów podrzędnych, jak również nie mają możliwości odwołania.
Opcje instalacji i pamięć masowa
Omówiliśmy podstawowe elementy HashiCorp Vaulta, ale nie wspomnieliśmy do tej pory o platformach, na których program może być zainstalowany i jak wybrać odpowiedni Storage Backend, czyli zaplecze do fizycznego przechowywania naszych sekretów.
Instalacja Vaulta jest relatywnie prosta, a lista platform, z jakich możemy skorzystać, jest bogata, gdyż zawiera zarówno popularne systemy operacyjne jak Linux (z prekompilowanymi pakietami dla poszczególnych dystrybucji) czy Windows, jak również zdecydowanie rzadziej już dzisiaj wykorzystywane systemy, jak te z rodziny BSD czy Solaris. Trudno sobie wyobrazić instalację produkcyjną na systemach macOS, ale taka możliwość również istnieje. Równie trudno wyobrazić sobie nowoczesne oprogramowanie bez wsparcia dla platform konteneryzacyjnych. Dlatego także i tutaj HashiCorp zaoferował nam taką możliwość. Możemy wykorzystać zarówno czystego Kubernetesa, jak i wszystkie jego implementacje, jak Rancher czy OpenShift.
Wybór zaplecza, na którym będziemy przechowywać nasze sekrety, jest w procesie instalacji często bagatelizowany lub nawet zupełnie pomijany. Nie zastanawiamy się, czy moglibyśmy coś zyskać, wykorzystując zamiast standardowego filesystemu chociażby Consula, bazę danych PostgreSQL czy nawet object storage w chmurze publicznej. HashiCorp Vault w obecnej wersji wspiera ponad 20 typów backendów, z których, poza wspomnianymi wcześniej, znajdują się między innymi takie jak DynamoDB, Etcd, MSSQL czy Zookeeper.
Zanim wybierzemy właściwy dla nas backend, musimy sobie odpowiedzieć na kilka pytań. Między innymi czy nasz backend będzie pracował w trybie wysokiej dostępności oraz, czy interesuje nas pełny support producenta. Naturalnie, nie bez znaczenia są także własne preferencje oraz polityka firmy. Może się zatem okazać, że wybór, który z pozoru jest bardzo trudny, wcale takim nie jest, gdyż ogranicza się do jednej bądź dwóch opcji. Jeśli jednak nie mamy takich ograniczeń, warto sobie rozrysować drzewko decyzyjne, które może nam znacznie ułatwić podjęcie tej decyzji.
Zarządzanie Vaultem
Gdy nasze oprogramowanie jest już zainstalowane i odpieczętowane (Vault dostarczany jest bowiem w stanie „sealed”. Oznacza to, że jest on niezdolny do wykonania jakiejkolwiek czynności. W procesie odpieczętowania uzyskujemy klucz główny służący do odszyfrowania danych.) musimy zastanowić się, z jakiego interfejsu będziemy korzystać. HCP Vault daje nam trzy możliwości: GUI (ang. Graphical User Interface), CLI (ang. Command Line Interface) oraz API (ang. Application Programming Interface).
Wydawać by się mogło, że mając do dyspozycji graficzny interfejs użytkownika, większość czynności najprościej nam będzie wykonać właśnie z niego. Niestety nie jest to prawdą, gdyż GUI pod względem funkcjonalnym jest dosyć mocno ograniczony i służy bardziej do wykonywania prostych czynności administracyjnych. Z GUI mamy dostęp do silników danych, metod autoryzacji czy polityk i częściowo możemy nimi zarządzać, ale jak się szybko okaże wielu, nawet podstawowych rzeczy, nie możemy zrobić. Nie możemy na przykład wykonać tak prostej, jak by się mogło wydawać, rzeczy jak wygenerowanie tokena.
Bardziej skomplikowane czynności możemy wykonać przy pomocy CLI. Mamy tutaj możliwości znacznie większe niż w GUI, a na dodatek konstrukcja wiersza poleceń jest dosyć prosta i raczej intuicyjna. Z CLI możemy wykonać większość działań. Większość, ale nie wszystkie. Może się zdarzyć, że będziemy chcieli wykonać coś, czego CLI nie umożliwia, jak chociażby przeszukiwanie wszystkich sekretów w poszukiwaniu tego jednego. W sytuacji, gdy mamy mocno zagnieżdżoną strukturę ścieżek, w której znajdują się nasze sekrety, znalezienie tego jednego, gdy nie za bardzo wiemy, gdzie szukać, jest zadaniem dosyć trudnym.
Ostatnim, jednocześnie dającym najwięcej możliwości sposobem zarządzania Vaultem, jest API. Możemy tutaj zrobić dosłownie wszystko. Niestety wywoływanie zapytań przy pomocy API, który bądź co bądź jest dedykowany raczej dla aplikacji, jest mało wygodne i przejrzyste. Niemniej jednak są działania, które wykonamy wyłącznie tą metodą. Wspomniane wcześniej wyszukiwanie sekretu możemy zrobić, pisząc na przykład odpowiedni skrypt. Zresztą tworzenie skryptów ułatwiających nam wykonywanie codziennych czynności jest w świecie IT bardzo często praktykowane. Nawet w sytuacji, gdy mamy do dyspozycji mocno rozbudowany interfejs graficzny – tak jest zwyczajnie prościej i szybciej.
Nie sposób nie wspomnieć jednak o jeszcze jednej metodzie, która nie jest co prawda oddzielnym sposobem zarządzania Vaultem, gdyż sama w sobie korzysta z interfejsu API, jednak znacznie upraszcza nasze działania. Przy okazji pozwala te działania automatyzować w sposób prosty i przejrzysty. Mówię oczywiście o Terraformie. Fakt, że Terraform jest produktem firmy HashiCorp, nie jest tutaj bez znaczenia. Otrzymujemy bowiem w pełni supportowanego providera, który znacznie ułatwi nam pracę z Vaultem.
Licencjonowanie i support
Wybór licencji nie jest sprawą prostą i zależy w równym stopniu od tego, czego tak naprawdę potrzebujemy od strony funkcjonalnej, jak i od regulacji wewnętrznych i skali systemu informatycznego naszej firmy. HashiCorp daje nam do dyspozycji wersję Community Edition, która w wielu przypadkach w zupełności nam wystarczy. Nie zaoferuje nam jednak wsparcia ze strony producenta. W wersji darmowej mamy do dyspozycji całą gamę silników oraz większość funkcji, które HCP Vault oferuje i z których dowolnie możemy korzystać. Gdy jednak nasze środowisko jest mocno rozbudowane lub po prostu w sytuacji, gdy potrzebujemy pewnego i gwarantowanego rozwiązania, przyjdzie czas, że będziemy musieli się zastanowić nad wyborem wersji Enterprise.
Wersja Enterprise posiada dodatkowe możliwości, których w wersji darmowej niestety nie znajdziemy. Są wśród nich zarówno takie rzeczy, jak wsparcie dla wysokiej dostępności, obsługa przestrzeni nazw czy synchronizacja sekretów z chmurą publiczną. To także obsługa standardu bezpieczeństwa FIPS 140-2, co zwłaszcza w instytucjach finansowych jest rzeczą niebagatelną. Wersja Enterprise oferuje również wiele dodatkowych silników sekretów, jak chociażby Transform służący do przekształcania i anonimizacji danych czy KMIP umożliwiający obsługę protokołu do zarządzania kluczami tajnymi.
Wersja Enterprise dzieli się również na edycje: Standard, Plus, Premium oraz Advanced Data Protection. Tutaj także będziemy musieli się zastanowić i dogłębnie przeanalizować nasze potrzeby, gdyż każda z nich wprowadza pewne dodatkowe elementy.
Edycje wersji Enterprise nie mają jednak znaczenia dla wyboru rodzaju supportu. Mamy tutaj do dyspozycji pakiety Bronze, Silver oraz Gold, które różnią się od siebie zarówno czasem reakcji ze strony firmy HashiCorp, jak i klasyfikacją zgłoszeń. W pakiecie najniższym jedynie zgłoszenia o najwyższym priorytecie będą analizowane. Jeśli natomiast zależy nam na najwyższym poziomie obsługi oferowanym w trybie 24/7, będziemy musieli wybrać pakiet złoty.
Sprecyzowanie potrzeb naszej firmy nie jest sprawą prostą i wymaga od nas dogłębnej analizy systemu, jaki posiadamy oraz pewnego perspektywicznego spojrzenia i zastanowienia się na tym, co może nas czekać w przyszłości. W każdym momencie jednak możemy edycję oraz poziom wsparcia zwiększyć, co zdecydowanie podjęcie takiej decyzji upraszcza. HashiCorp Vault umożliwia również migrację wersji Community do Enterprise, co przed zakupem pozwala nam zapoznać się z możliwościami programu.
Klienci
Jeżeli zdecydujemy się na wersję Enterprise, będzie nas czekać jeszcze jedna decyzja, mianowicie zakup odpowiedniej ilości licencji. Licencjonowanie HashiCorp Vault opiera się bowiem na pojęciu zwanym Klientem.
Czym jest Klient? Zgodnie z definicją producenta Klienci reprezentują wszystko, co zostało uwierzytelnione w Vault w celu wykonania jakiegoś działania. Klientami mogą być użytkownicy, aplikacje (lub mikrousługi), systemy (platformy, maszyny wirtualne, pody), systemy automatyzacji (Ansible, Terraform, potoki CI/CD), Agenci (Vault Agents) czy wreszcie same tokeny, które nie są powiązane z żadną Jednostką. Każdy Klient liczony jest tylko raz bez względu na to, ile razy w okresie objętym supportem zalogował się do Vaulta oraz z jakich poświadczeń skorzystał.
Omówiliśmy już nieco szerzej temat Jednostek i w większości przypadków to Jednostka jest właśnie Klientem. Należy tutaj jednak wspomnieć, że token, który nie jest powiązany z żadną Jednostką, również jest traktowany jako Klient, co należy wziąć pod uwagę. Może się bowiem okazać, że pewne przyzwyczajenia, na które nie zwracaliśmy uwagi, korzystając z wersji Community, w wersji Enterprise doprowadzą do niekontrolowanego zwiększenia się liczby Klientów liczonych przez aplikację. Vault daje nam zresztą narzędzia, które w dość prosty sposób pomogą nam kontrolować liczbę Klientów.
Z poziomu GUI mamy do dyspozycji narzędzie Vault Usage Metric, które po zainicjowaniu, w dosyć przejrzysty sposób pokazuje nam, ilu Klientów zostało przez system zliczonych. Widzimy, że narzędzie pokazuje nam osobno Jednostki oraz wspomniane wcześniej tokeny, które zostały utworzone poza Jednostką. Narzędzie to jest dostępne również w wersji Community, dzięki czemu migracja na wersję Enterprise staje się relatywnie prosta, gdyż dosyć precyzyjnie możemy zliczyć, ilu Klientów aktywnie korzysta z naszego Vaulta.
Liczbę Klientów, przynajmniej jeśli chodzi o Jednostki, możemy też do pewnego stopnia kontrolować poprzez zakładkę Entities. Musimy tutaj jednak pamiętać, że strona ta zawiera wszystkie utworzone w systemie jednostki, niekoniecznie korzystające z Vaulta w danym okresie czasu.
Podsumowanie
Trudno znaleźć na rynku rozwiązanie, które w równie kompleksowy sposób podchodzi do tematu zarządzania informacjami niejawnymi jak HashiCorp Vault. Mamy tu do dyspozycji nie tylko całą gamę silników i funkcjonalności, ale również wersję w pełni supportowaną, co daje gwarancję, że nasze sekrety są przechowywane i zarządzane w sposób pewny i niepozostawiający miejsca na kompromisy.
