Wyobraź sobie taką sytuację. Budujesz aplikację i potrzebujesz klucza API do połączenia z usługą, hasła do bazy danych lub klucza konta magazynu. Więc umieszczasz go w swoim kodzie, może w pliku konfiguracyjnym lub zmiennej środowiskowej. Działa, wszystko uruchamia się poprawnie, dopóki nie wypchniesz kodu na GitHub lub nie udostępnisz notatnika współpracownikowi. I w jednej chwili Twój sekret przestaje być sekretem. Jeśli ten kod wpadnie w niepowołane ręce, cały Twój system jest zagrożony. Azure Key Vault to narzędzie, które rozwiązuje ten problem. Daje Ci bezpieczne miejsce do przechowywania sekretów, aby nigdy nie trafiły do kodu. Ale oto rzecz, w której większość ludzi popełnia błąd. Samo posiadanie Key Vault nie sprawia automatycznie, że jesteś bezpieczny. Sposób konfiguracji, kontroli dostępu i przyznawania uprawnień jest równie ważny. Pod koniec tego odcinka dowiesz się, czym właściwie jest Key Vault, co możesz w nim przechowywać, jak działa dostęp i jaki jest największy błąd, przez który Twoje sekrety mogą wycieknąć.

Wszystko prostym językiem, bez żargonu, tylko to, co musisz wiedzieć. Czym więc dokładnie jest Azure Key Vault? Czym jest Azure Key Vault? Oto najprostsza definicja. Azure Key Vault to chmurowy, cyfrowy sejf na Twoje sekrety. To zarządzana usługa Microsoftu na klucze API, hasła do baz danych, ciągi połączeniowe, klucze szyfrujące i certyfikaty w jednym centralnym miejscu. Nie musisz martwić się o infrastrukturę, ponieważ Azure zajmuje się aktualizacjami, dostępnością i bezpieczeństwem. Ty po prostu z niego korzystasz. Pomyśl o tym jak o budynku biurowym. Masz stanowiska pracy, sale spotkań i szafki na dokumenty, ale gdzieś w piwnicy jest bezpieczny skarbiec, w którym trzymasz ważne rzeczy. Główne klucze, gotówkę, dokumenty prawne. Nikt nie wchodzi tam bez pozwolenia i uwierzytelnienia, a każde otwarcie drzwi jest rejestrowane w logach. Taki właśnie jest Key Vault. Bezpieczny pokój w piwnicy Twojej architektury Azure.

Teraz porównaj to ze starym sposobem. 20 lat temu, jeśli potrzebowałeś hasła do bazy danych, wpisywałeś je na sztywno w pliku konfiguracyjnym, może w zmiennej środowiskowej, albo gorzej, zostawiałeś je w czystym tekście w kodzie źródłowym. Jeśli ktoś uzyskał dostęp do serwera, miał wszystko. A jeśli musiałeś zmienić to hasło, musiałeś aktualizować je wszędzie. W każdym pliku konfiguracyjnym, w każdym środowisku, w każdym wdrożeniu. To był koszmar. Key Vault zmienia to wszystko. Zamiast rozpraszać sekrety w kodzie i plikach konfiguracyjnych, przechowujesz je w jednym centralnym miejscu. Twoje aplikacje pobierają je w czasie działania, tylko wtedy, gdy ich potrzebują. A ponieważ wszystko jest scentralizowane, możesz zmienić klucz w jednym miejscu, a każda aplikacja, która z niego korzysta, automatycznie pobierze nową wartość bez zmian w kodzie czy ponownego wdrażania. Ale rzecz w tym, że Key Vault to nie tylko menedżer haseł dla Twoich aplikacji.

To podstawowa usługa bezpieczeństwa. Każda usługa Azure może się z nią zintegrować. App Service, funkcje, AKS, data factory, Synapse, Logic Apps, potoki DevOps, wszystkie potrafią komunikować się z Key Vault. Staje się on kręgosłupem Twojej bezpiecznej architektury chmurowej. A kiedy już go poprawnie skonfigurujesz, całkowicie przestajesz myśleć o zarządzaniu poświadczeniami. Co można w nim przechowywać? Skoro wiesz już, czym jest Key Vault, porozmawiajmy o tym, co faktycznie możesz w nim umieścić. Masz trzy główne kategorie, sekrety, klucze i certyfikaty. Każda z nich służy do czegoś innego, a zrozumienie tej różnicy pomoże Ci właściwie korzystać z Key Vault. Zacznijmy od sekretów. To najczęstsza rzecz, którą ludzie przechowują. Sekrety to parametry połączeń, klucze API, hasła do baz danych, klucze konta magazynu, w zasadzie wszystkie codzienne poświadczenia, których aplikacje potrzebują do komunikacji z innymi usługami.

Zamiast umieszczać je w kodzie lub pliku konfiguracyjnym, przechowujesz je w Key Vault. Twoja aplikacja pobiera je w czasie wykonywania i nikt nigdy nie widzi ich w postaci czystego tekstu. Pomyśl o tym, jak o zamkniętej szufladzie w Twojej cyfrowej szafce na dokumenty. Następne w kolejności są klucze. To klucze szyfrujące dla danych w spoczynku. Jeśli używasz kluczy zarządzanych przez klienta dla Azure Storage, baz danych SQL lub szyfrowania dysków maszyn wirtualnych, te klucze mogą znajdować się w Key Vault. Daje Ci to pełną kontrolę nad tym, kto i kiedy może z nich korzystać. A jeśli ze względu na zgodność potrzebujesz kluczy sprzętowych, wersja premium zapewnia ochronę HSM. Potem mamy certyfikaty. Certyfikaty TLS i SSL dla Twoich aplikacji internetowych, API i usług wewnętrznych. Key Vault może je przechowywać, zarządzać ich cyklem życia, a nawet automatycznie odnawiać, gdy zbliża się termin ich wygaśnięcia.

To ratunek dla każdego, komu certyfikat wygasł kiedyś w niedzielę o trzeciej nad ranem. Oto przykład z życia. Wyobraź sobie, że masz aplikację internetową, która potrzebuje ciągu połączenia z bazą danych i klucza API dla usługi zewnętrznej. W starym stylu umieściłbyś oba w pliku JSON z ustawieniami aplikacji. Jeśli ten plik trafi do Twojego repozytorium, każdy, kto ma dostęp do kodu, zobaczy Twoje poświadczenia bazy danych. Dzięki Key Vault przechowujesz obie wartości jako sekrety. Aplikacja pobiera je podczas uruchamiania i nigdy nie pojawiają się one w kodzie źródłowym. Musisz zmienić hasło do bazy danych? Zaktualizuj je w Key Vault. Aplikacja automatycznie pobierze nową wartość przy kolejnym restarcie. Bez zmian w kodzie, bez ponownego wdrażania. Jedną z rzeczy, która zaskakuje użytkowników, jest wbudowana obsługa wersji. Podczas aktualizacji wpisu tajnego Key Vault nie nadpisuje starej wartości.

Tworzy nową wersję. Stare wersje są zachowywane, więc w razie problemów można przywrócić poprzedni stan. To niezwykle przydatne podczas incydentów. Możesz szybko wrócić do poprzedniego wpisu bez konieczności pamiętania jego starej wartości. W tym samym magazynie możesz przechowywać wszystkie trzy typy, wpisy tajne, klucze i certyfikaty. Najlepszą praktyką jest jednak rozdzielenie ich według środowisk. Użyj osobnego magazynu dla programowania, testów i produkcji. Zapobiega to przypadkowemu użyciu produkcyjnego wpisu w środowisku deweloperskim i ogranicza zasięg szkód w razie włamania do magazynu. Jednak przechowywanie wpisów to tylko połowa sukcesu. Prawdziwe pytanie brzmi, kto ma do nich dostęp? Jak działa kontrola dostępu? Porozmawiajmy teraz o tym, kto uzyskuje dostęp. Key Vault oferuje dwa sposoby kontroli dostępu do zawartości i wybór metody ma duże znaczenie. Pierwszym modelem są starsze zasady dostępu Legacy Access Policies.

To stary sposób. Tworzysz zasady bezpośrednio w magazynie i przypisujesz uprawnienia konkretnym użytkownikom lub grupom dla określonych typów danych, wpisów, kluczy lub certyfikatów. Problem polega na tym, że zasady te są ściśle powiązane z konkretnym magazynem. Jeśli masz wiele magazynów, musisz zarządzać zasadami dla każdego z nich osobno. Nie skaluje się to dobrze. Microsoft odradza obecnie ich stosowanie, ponieważ mają znane luki w zabezpieczeniach. Nie obsługują one zarządzania tożsamością uprzywilejowaną i mogą prowadzić do nieoczekiwanej eskalacji uprawnień. Drugim modelem jest Azure RBAC, czyli kontrola dostępu oparta na rolach. To nowoczesny sposób. Wykorzystuje tożsamości EntraID i jest spójny z zarządzaniem uprawnieniami w pozostałych usługach Azure. Jeśli wiesz, jak nadać komuś dostęp do konta magazynu lub maszyny wirtualnej, wiesz też, jak nadać mu dostęp do Key Vault. Ten sam system, te same wzorce.

Oto złota zasada, najmniejsze uprawnienia. Dawaj tylko minimalny dostęp, którego ktoś potrzebuje, nic więcej. Jeśli ktoś musi tylko odczytywać wpisy, nie dawaj mu uprawnień do ich tworzenia ani usuwania. Jeśli ktoś musi tylko zarządzać certyfikatami, nie dawaj mu dostępu do kluczy. Omówię teraz kluczowe role. Masz role czytelnika Key Vault, Key Vault Reader. Pozwala ona na wyświetlenie listy wpisów, ale nie na odczyt ich wartości. Użytkownik wpisów Key Vault, Key Vault Secrets User. Pozwala ona na rzeczywisty odczyt wartości wpisów tajnych. Oraz oficer wpisów Key Vault, Key Vault Secrets Officer. Pozwala ona na tworzenie, aktualizację i usuwanie wpisów tajnych. Zauważ ten schemat. Każda rola dotyczy danych wewnątrz magazynu, a nie samego magazynu. Zestawmy to teraz z ogólnymi rolami właściciela, współtwórcy i czytelnika. Dotyczą one skarbca jako zasobu, a nie danych w nim zawartych. Właściciel może usunąć cały skarbiec.

Współtwórca może modyfikować ustawienia skarbca. Jednak żadna z tych ról sama w sobie nie daje dostępu do znajdujących się wewnątrz sekretów. To oddzielna warstwa uprawnień i to jest kluczowy punkt. Kontrola dostępu to system warstwowy. Potrzebujesz dostępu do samego skarbca to pierwsza warstwa oraz dostępu do danych wewnątrz skarbca to druga warstwa. Oba muszą zostać przyznane oddzielnie. Większość początkujących myśli tylko o pierwszej warstwie, zapominając o drugiej. Od tego zaczynają się kłopoty. To błąd numer jeden w zabezpieczeniach. Rzecz w tym, że większość ludzi patrzy na rolę współtwórca Kivolt i uważa ją za bezpieczną. Widzą słowo współtwórca i zakładają, że mogą zarządzać ustawieniami skarbca, ale nie ruszać zawartych w nim sekretów. Oryginalna dokumentacja Microsoftu głosiła dokładnie to samo. Ta rola nie pozwala na dostęp do sekretów, kluczy ani certyfikatów. Z wyjątkiem tego, że nie do końca jest to prawda.

Użytkownik z rolą współtwórca Kivolt może modyfikować zasady dostępu do skarbca. A jeśli ten skarbiec wciąż używa starszych zasad dostępu, co jest częstą praktyką, mogą oni po prostu przyznać sobie pełny dostęp do odczytu każdego sekretu, klucza i certyfikatu w środku. Nie potrzeba żadnego specjalnego eksploita ani łatania luk. Tak po prostu działają te uprawnienia. Badacze bezpieczeństwa z Datadog udowodnili to w 2024 roku. Wykazali, że współtwórca może uzyskać pełny dostęp do danych w każdym skarbcu korzystającym ze starszych zasad dostępu. Reakcja Microsoftu była interesująca. Stwierdzili, że nie jest to luka, ponieważ współtwórcy mają zarządzać zasadami dostępu, ale zaktualizowali dokumentację, by wyraźnie ostrzec, że rola ta może sama przyznać sobie dostęp do płaszczyzny danych. Nie jest to więc błąd w samym Key Vault, lecz pułapka konfiguracyjna. Wpada w nią nawet doświadczone zespoły, bo nazwa roli brzmi niegroźnie.

Współtwórca nie brzmi jak ktoś, kto może odczytać twoje hasła do baz danych, ale w praktyce może. Pomyśl o ryzyku. Jeśli atakujący przejmie konto z rolą współtwórcy w twoim Key Vault, nie musi włamywać się do skarbca. Nie musi łamać szyfrowania. Wystarczy, że zmodyfikuje zasady dostępu, przyzna sobie prawo do odczytu i po cichu wykradnie każdy przechowywany sekret, ciągi połączeń, klucze API, certyfikaty, wszystko. A ponieważ zmiany zasad dostępu to normalna czynność administracyjna, może to nie wywołać żadnych alertów. Jak więc to naprawić? Po pierwsze, używaj Azure RBAC do dostępu do płaszczyzny danych zamiast starszych zasad dostępu. RBAC oddziela zarządzanie skarbcem od znajdujących się w nim danych. Po drugie, nigdy nie nadawaj roli współautora Key Vault nikomu, kto jej absolutnie nie potrzebuje. Po trzecie, jeśli masz już użytkowników z tą rolą, przeprowadź ich audyt jeszcze dzisiaj.

dostępu Key Vault istnieje drugi błąd, który potęguje pierwszy, przechowywanie wszystkich sekretów w jednym magazynie. Jeśli masz jeden magazyn do wszystkiego programowania, testów, wdrożeń, produkcji i wszystkich aplikacji, a magazyn ten zostanie przejęty, wszystko zostaje ujawnione. To pojedynczy punkt awarii. Za chwilę porozmawiamy więcej o strategii wielu magazynów, ale zasada jest prosta. Nie wkładaj wszystkich jajek do jednego koszyka, zwłaszcza gdy w tym koszyku znajdują się klucze do całej twojej infrastruktury. Tożsamość zarządzana, złoty standard. Jak więc zrobić to dobrze? Porozmawiajmy o najlepszym sposobie dostępu do Key Vault. Istnieje fundamentalny problem. Aby uzyskać poświadczenia z Key Vault, aplikacja musi się uwierzytelnić, ale do uwierzytelnienia potrzebuje poświadczeń. Gdzie przechowywać poświadczenia, których aplikacja używa do zdobycia innych poświadczeń? To problem jajka i kury.

Starym rozwiązaniem była jednostka usługi z kluczem tajnym, ale ten klucz musi gdzieś istnieć może w pliku konfiguracyjnym, zmiennych środowiskowych lub potoku wdrażania. I wracasz do tego samego problemu. Po prostu przeniosłeś sekret w inne miejsce. Tożsamość zarządzana rozwiązuje to całkowicie. Oto jak to działa. Gdy włączasz tożsamość zarządzaną w zasobie Azure, na przykład w aplikacji webowej, funkcji lub maszynie wirtualnej, Azure automatycznie tworzy tożsamość dla tego zasobu w EntraID. Ta tożsamość jest w całości zarządzana przez Azure. Żadnych poświadczeń do tworzenia, żadnych sekretów do rotowania, nic do przechowywania. Zasób po prostu posiada tożsamość, o której Azure wie. Istnieją dwa typy. Tożsamość zarządzana przypisana przez system jest powiązana z jednym konkretnym zasobem. Jeśli usuniesz zasób, tożsamość również zniknie. Dzielą one cykl życia, co upraszcza administrację.

Tożsamość zarządzana przypisana przez użytkownika to samodzielna tożsamość, którą możesz przypisać do wielu zasobów. Nie dzieli ona cyklu życia z żadnym z nich, więc jest przydatna, gdy potrzebujesz tej samej tożsamości dla kilku usług. Oto jak wygląda to w praktyce. Masz aplikację webową, która musi odczytać ciąg połączenia z bazą danych z Key Vault. Włączasz tożsamość zarządzaną przypisaną przez system dla tej aplikacji webowej. Następnie nadajesz tej tożsamości rolę użytkownika sekretów Key Vault w swoim magazynie. To wszystko. Żadnych ciągów połączeń w kodzie, żadnych kluczy tajnych w plikach konfiguracyjnych. Aplikacja internetowa uwierzytelnia się w usłudze Key Vault za pomocą swojej tożsamości zarządzanej, a Azure zajmuje się całym zarządzaniem poświadczeniami. Jest to rozwiązanie najbliższe uwierzytelnianiu bez poświadczeń w środowisku Azure. To przełom w dziedzinie bezpieczeństwa, ponieważ eliminuje najczęstszy wektor ataku kradzież poświadczeń.

Jeśli nie ma poświadczeń do ukradzienia, atakujący nie ma czego przejąć. Podam przykład z życia wzięty. Wyobraźmy sobie potok danych w Synaps, który musi uzyskać dostęp do konta magazynu. Dawniej przechowywałoby się klucz konta magazynu w konfiguracji potoku. Jeśli ktoś uzyskał dostęp do tego potoku, miał dostęp do klucza. Dzięki tożsamości zarządzanej obszar roboczy Synaps posiada własną tożsamość. Tożsamości tej przyznaje się dostęp do Key Vault, gdzie przechowywany jest klucz konta magazynu. Potok pobiera klucz w czasie wykonywania, używa go i nigdy nigdzie go nie zapisuje. Brak kluczy w kodzie, brak sekretów w konfiguracji potoku. Gdy połączysz tożsamość zarządzaną z RBAC i zasadą najmniejszych uprawnień, zyskasz bezpieczny fundament dla każdego obciążenia w Azure. Twoje aplikacje uwierzytelniają się bez użycia poświadczeń. Uzyskują dostęp tylko do tego, czego potrzebują, a każde użycie jest rejestrowane i możliwe do skontrolowania.

To wzorzec zalecany przez Microsoft w niemal każdym scenariuszu. Gdy zaczniesz go używać, będziesz się zastanawiać, dlaczego kiedykolwiek robiłeś to inaczej. Koszty i strategia wielu magazynów. Porozmawiajmy więc o kosztach. W tym miejscu większość osób jest zaskoczona. Ile tak naprawdę kosztuje Azure Key Vault? Model cenowy jest prosty. Brak opłaty za przechowywanie poszczególnych sekretów. Nie płacisz za każde hasło czy klucz API, które przechowujesz. Płacisz natomiast za operację. W warstwie standardowej to około 3 centy za każde 10 tysięcy operacji. Wywołanie pobrania sekretu liczy się jako jedna operacja. Podobnie jak tworzenie sekretu czy wyświetlanie zawartości magazynu. Dla typowej małej lub średniej aplikacji sumuje się to do kilku centów miesięcznie. Dosłownie kilku centów. Porównaj to z AWS Secrets Manager. Pobierają 40 centów za sekret miesięcznie za samo przechowywanie plus dodatkowe opłaty za wywołania API.

Jeśli masz 100 sekretów to 40 dolarów miesięcznie zanim jeszcze odczytasz choćby jeden z nich. W Azure Key Vault 100 sekretów przy umiarkowanym użyciu może kosztować Cię 15 centów. Różnica szybko rośnie wraz ze skalą. Istnieje również warstwa premium. Dodaje ona klucze oparte na HSM dla obciążeń wymagających najwyższego poziomu gwarancji kryptograficznej. Pomyśl o transakcjach finansowych, danych medycznych, systemach rządowych. Koszt operacji jest wyższy około 15 centów za 10 tysięcy operacji dla zaawansowanych typów kluczy plus miesięczna opłata za klucz HSM. Jednak dla większości aplikacji warstwa standardowa jest w zupełności wystarczająca. Oto zaskakujący koszt, który często bierze ludzi z zaskoczenia. W przypadku typowej aplikacji internetowej z kilkoma sekretami i kilkoma tysiącami operacji miesięcznie, kosztki volt to mniej niż dolar. Więcej wydasz na kawę, którą wypijesz podczas konfiguracji.

Istnieje jednak strategia, która jest ważniejsza niż koszt. Liczba używanych magazynów. Rozsądnym podejściem jest strategia wielu magazynów. Używaj oddzielnych magazynów dla środowisk programistycznych, testowych, stagingowych i produkcyjnych. Zapobiega to najczęstszemu przypadkowi. Ktoś uruchamia skrypt testowy, który przypadkowo odczytuje bazę produkcyjną, ponieważ ciąg połączeniowy był w tym samym magazynie. Gdy środowiska są odseparowane, taki błąd staje się niemożliwy. Powinieneś również dokonać separacji według jednostek biznesowych lub obszarów zgodności. Jeśli obsługujesz dane kart płatniczych, umieść te sekrety w osobnym magazynie. Ogólne zadania biznesowe trafiają do innego, a dane medyczne do trzeciego. Nie chodzi o utrudnianie pracy, lecz o ograniczenie zasięgu ewentualnej awarii. Jeśli jeden magazyn zostanie skompromitowany, narażone będą tylko sekrety w nim zawarte. Reszta Twojej infrastruktury pozostaje bezpieczna.

Oraz dwie wbudowane sieci bezpieczeństwa, które zawsze warto włączyć. Usuwanie nietrwałe Soft Delete oznacza, że jeśli ktoś usunie sekret, nie znika on na stałe. Przechodzi w stan odzyskiwalny na wybrany okres przechowywania do 90 dni. Ochrona przed czyszczeniem Perge Protection idzie o krok dalej. Nikt nie może trwale usunąć magazynu ani jego zawartości, dopóki okres przechowywania nie minie. Razem zapobiegają one przypadkowej utracie danych, która spędza sen z powiek zespołom do spraw. Bezpieczeństwa. Jak to wszystko się łączy? Epnijmy to wszystko razem i zobaczmy, jak elementy do siebie pasują. Key Vault nie jest wyspą. To centralny układ nerwowy dla sekretów w Twojej architekturze Azure. Gdy zrozumiesz, jak przepływa cały system, wszystko wskoczy na swoje miejsce. Oto co dzieje się, gdy aplikacja potrzebuje sekretu. Aplikacja wysyła żądanie przy użyciu swojej tożsamości zarządzanej. Ta tożsamość jest już zarejestrowana w EntraID.

Azure utworzył ją automatycznie, gdy włączyłeś tożsamość zarządzaną dla zasobu. EntraID weryfikuje, czy tożsamość jest autentyczna, a następnie przekazuje żądanie do Key Vault. Key Vault sprawdza uprawnienia RBAC, które zostały przypisane. Jeśli tożsamość ma odpowiednią rolę, na przykład Key Vault Secrets User, sekret zostaje zwrócony. Wszystko to dzieje się w milisekundach. Aplikacja nigdy nie widzi danych uwierzytelniających. Nigdy nie przechowuje hasła. Po prostu otrzymuje wartość, której potrzebuje. Teraz pomyśl, jak wiele usług Azure może się z tym połączyć. App Service, Functions, AKS, Data Factory, Synapse, Logic Apps, DevOps Pipelines wszystkie wiedzą, jak komunikować się z Key Vault. Możesz skonfigurować aplikację internetową tak, aby odwoływała się do sekretu bezpośrednio w ustawieniach aplikacji. Możesz skonfigurować potok Data Factory tak, aby pobierał klucz konta magazynu z Key Vault w trakcie działania.

Możesz skonfigurować klaster Kubernetes tak, aby pobierał sekrety za pomocą sterownika Key Vault CSI. Każda usługa integruje się w ten sam sposób, używając tego samego systemu tożsamości, tych samych ról RBAC i tego samego dziennika audytu. Wzorzec CI-CD jest szczególnie skuteczny. Twoje potoki pobierają sekrety z Key Vault w czasie wdrażania. Nigdy nie przechowują ich w zmiennych potoku ani w sekretach repozytorium. Jeśli musisz zmienić hasło do bazy danych, aktualizujesz je w Key Vault. Przy następnym uruchomieniu potok automatycznie pobierze nową wartość. Bez zmian w potoku, bez zmian w kodzie, bez ponownych wdrożeń. Oto element, dzięki któremu wszystko nabiera sensu. Gdy skonfigurujesz Key Vault z tożsamością zarządzaną i RBAC, całkowicie przestaniesz myśleć o zarządzaniu poświadczeniami. Twoje aplikacje po prostu działają. Sekrety są Rotowain, a nikt nawet tego nie zauważa. Certyfikaty odnawiają się bez nocnych sytuacji awaryjnych.

System zajmuje się tym wszystkim w tle. To jest postawa bezpieczeństwa, która ma znaczenie. Tożsamość stanowi perymetr, a nie sieć. Nie ma znaczenia, czy ktoś znajduje się wewnątrz Twojej sieci wirtualnej, czy poza nią. Liczy się to, czy posiada prawidłową tożsamość z odpowiednimi uprawnieniami. Key Vault wymusza to w swojej konstrukcji. Każde żądanie dostępu przechodzi przez uwierzytelnianie EntraID i autoryzację RBAC, niezależnie od tego, skąd pochodzi. I wszystko jest rejestrowane. Każdy odczyt sekretu, każda operacja na kluczu, każde pobranie certyfikatu. Możesz zobaczyć, kto uzyskał dostęp do czego i kiedy. Jeśli coś wygląda podejrzanie, masz dane do przeprowadzenia dochodzenia. Jest to kluczowe dla zgodności reagowania na incydenty oraz po prostu wiedzy o tym, co dzieje się w Twoim środowisku. Na tym polega piękno tego rozwiązania. Key Vault, EntraID, RBAC i tożsamość zarządzana współpracują jako zintegrowane ramy bezpieczeństwa.

Każdy element wzmacnia pozostałe. A gdy wszystko jest poprawnie skonfigurowane, otrzymujesz system zarządzania poświadczeniami, który jest bezpieczniejszy i łatwiejszy w obsłudze niż cokolwiek, co mógłbyś zbudować samodzielnie. Praktyczne wnioski. Co więc powinieneś zrobić już teraz? Przekujmy tę wiedzę w działanie. Oto rzeczy, którymi możesz zająć się w tym tygodniu.

Key Vault w portalu przejdź do konfiguracji dostępu i sprawdź, co tam jest napisane. Jeśli widzisz zasady dostępu do magazynu, to jest to przestarzała metoda. Zamiast tego wybierz kontrolę dostępu opartą na rolach platformy Azure. Migracja jest prosta. Zmień model uprawnień i przypisz rolę RBAC tym samym osobom, które już miały zasady dostępu. Zrób to dzisiaj. Microsoft to zaleca, a badania, o których mówiliśmy, dokładnie pokazują dlaczego. Następnie sprawdź konta posiadające rolę współautora Key Vault. Otwórz kartę IAM w swoim magazynie i sprawdź, kto ma dostęp typu współautor. Każda osoba z tą rolą musi mieć ku temu dobry powód. Przez większość czasu tego nie robią. Zastąp rolę współtwórcy czymś bardziej szczegółowym. Jeśli ktoś musi tylko odczytywać sekrety, nadaj mu uprawnienia użytkownika wpisów Key Vault. Jeśli musi zarządzać sekretami, użyj roli administratora wpisów Key Vault. Celem jest całkowite zamknięcie tej ścieżki eskalacji uprawnień.

Następnie skorzystaj z tożsamości zarządzanej. Każda usługa Azure wymagająca dostępu do Key Vault powinna z niej korzystać. Jeśli masz aplikację internetową, funkcję, data factory lub maszynę wirtualną korzystającą z jednostki usługi z kluczem tajnym, przejdź na tożsamość zarządzaną.

Mówiliśmy. Azure zajmuje się zarządzaniem poświadczeniami za Ciebie w tle. Jeszcze jedno. Włącz usuwanie nietrwałe i ochronę przed przeczyszczaniem w każdym magazynie. Usuwanie nietrwałe jest domyślnie włączone dla nowych magazynów, ale ochrona przed przeczyszczaniem nie. Włącz ją. To ustawienie uniemożliwia trwałe usunięcie magazynu lub jego zawartości w okresie przechowywania. Uratowało już niejeden zespół przed katastrofalnym błędem. Oto Twoje zadanie do wykonania. Przyjrzyj się swojemu obecnemu podejściu do zarządzania sekretami. Znajdź jeden sekret, który wciąż znajduje się w pliku konfiguracyjnym zmiennej środowiskowej lub jest zakodowany w kodzie. Przenieś go do Key Vault w tym tygodniu. Tylko jeden. Gdy zobaczysz, jakie to proste, zechcesz przenieść resztę. Bezpieczeństwo to nie jednorazowa konfiguracja. To ciągła praktyka. Key Vault ułatwia tę praktykę, ale tylko wtedy, gdy używasz go poprawnie.

Narzędzia są dostępne. Wzorce są sprawdzone. Teraz od Ciebie zależy, czy je wdrożysz. Taki jest ten system. Key Vault to Twój cyfrowy sejf, ale jest tak bezpieczny, jak kontrola dostępu, którą wokół niego ustanowisz. Zacznij od audytu, który właśnie opisałem. Sprawdź swój model uprawnień. Zweryfikuj przypisania współtwórców i przenieś jeden sekret do magazynu w tym tygodniu. Zasubskrybuj, aby otrzymywać więcej wskazówek o bezpieczeństwie w chmurze i udostępnij to komuś, kto wciąż przechowuje sekrety w plikach konfiguracyjnych.