Fundament architektury opiera się na topologii opartej na komórkach, w której niezależne klastry regionalne utrzymują suwerenność, uczestnicząc w globalnej płaszczyźnie sterującej. Każda komórka regionalna wdraża aktywny klaster HashiCorp Vault wykorzystujący konsensus Raft do lokalnej replikacji maszyny stanowej, wspierany przez certyfikowane moduły HSM poziomu FIPS 140-2 takie jak Thales Luna lub AWS CloudHSM. Synchronizacja metadanych między-regionowych wykorzystuje oparte na CRDT konflikto-odpornych typach danych replikowanych dla usług odkrywania zgodnych w czasie, podczas gdy wrażliwe operacje kryptograficzne pozostają ściśle lokalne, aby zapobiec wyciekom materiału klucza.
Dynamiczna rotacja poświadczeń eliminuje statyczne sekrety poprzez integrację SPIFFE (Secure Production Identity Framework For Everyone) z agentami SPIRE wdrożonymi na każdym węźle obliczeniowym. Obciążenia uwierzytelniają się za pomocą krótkotrwałych tokenów JWT powiązanych z tożsamościami kryptograficznymi potwierdzonymi przez Node i Workload attestory, umożliwiając automatyczną rotację bez ponownego uruchamiania kontenerów lub przeładowania konfiguracji. Ten mechanizm skraca czas życia sekretów z dni do minut, zasadniczo ograniczając zakres potencjalnej ekfiltacji.
Natychmiastowe propagowanie unieważnienia działa poprzez oparty na plotkach protokół SWIM (Scalable Weakly-consistent Infection-style Process Group Membership), nakładający się na dwukierunkowe połączenia strumieniowe gRPC między klastrami regionalnymi. Gdy incydenty bezpieczeństwa wywołują unieważnienie, inicjator zalewa plotką sieć, osiągając konwergencję w czasie sub-sekundowym w setkach węzłów bez wąskich gardeł koordynacji centralnej. To podejście kontrastuje z tradycyjnymi systemami opartymi na sygnałach heartbeat, które narzucają liniową przeciążenia w zależności od rozmiaru klastra.
Procedury przestrzegania przepisów i ceremonie kluczy wdrażają Shamir's Secret Sharing do operacji odszyfrowania, wymagając od wielu operatorów zrekonstruowania klucza głównego podczas inicjalizacji klastra lub odzyskiwania po awarii. Klastry HSM utrzymują ścisłe fizyczne i logiczne granice bezpieczeństwa, zapewniając, że niezaszyfrowane klucze prywatne nigdy nie istnieją w pamięci aplikacji ani w trwałej pamięci poza granicą sprzętu. Regularne ceremonie rotacji kluczy wykorzystują operacje PKCS#11 w obrębie granicy HSM do generowania nowych par kluczy bez eksponowania materiału systemowi operacyjnemu gospodarza.
Podczas krytycznej reakcji na naruszenie w globalnym przetwarzaniu płatności odkryliśmy, że statyczne poświadczenia AWS IAM zakodowane w plikach stanu Terraform zostały ekfiltrowane, co dało atakującym stały dostęp do baz danych produkcyjnych na trzech kontynentach. Natychmiastowe wyzwanie wymagało jednoczesnej rotacji tysięcy haseł do baz danych bez wywoływania lawinowych awarii w naszej sieci mikrousług, zapewniając jednocześnie, że unieważnione poświadczenia stały się natychmiast bezużyteczne, nawet w regionach doświadczających podziałów sieciowych.
Pierwszym rozważanym rozwiązaniem było wdrożenie centralnej platformy HashiCorp Vault z backendem PostgreSQL w naszym głównym regionie AWS, wykorzystując funkcje Lambda wyzwalane przez CloudWatch Events do automatycznej rotacji. To podejście oferowało silne gwarancje spójności i uproszczone logi audytowe, ale wprowadziło katastrofalny pojedynczy punkt awarii; jakiekolwiek regionalne awarie uczyniłyby sekrety globalnie niedostępnymi, łamiąc nasze SLA dostępności na poziomie 99.999%. Dodatkowo, opóźnienie międzyskalowe w odzyskiwaniu sekretów regularnie przekraczało 300 ms, co nie spełniało naszego wymogu poniżej 100 ms dla przepływów autoryzacji płatności.
Drugie rozwiązanie zaproponowało przyjęcie natywnych menedżerów sekretów w chmurze (Secrets Manager, Azure Key Vault, GCP Secret Manager) z federacyjną płaszczyzną sterującą i mostem tożsamości OAuth 2.0. To zapewniało doskonałą dostępność regionalną i natywne certyfikaty zgodności, ale tworzyło nieakceptowalne zjawisko uzależnienia od dostawcy oraz uniemożliwiało natychmiastowe globalne unieważnienie z powodu asynchronicznych opóźnień replikacji od 1 do 5 minut między chmurami. Brak zjednoczonych śladów audytowych w heterogenicznych środowiskach również komplikował nasze wymagania dotyczące zgodności z PCI DSS poziom 1, ponieważ nie mogliśmy zapewnić jednego źródła prawdy dla analizy kryminalistycznej.
Trzecie rozwiązanie zaprojektowało topologię opartą na komórkach z regionalnymi klastrami Vault wykorzystującymi konsensus Raft, SPIFFE/SPIRE dla kryptograficznej tożsamości obciążenia oraz niestandardowy protokół unieważniania oparty na plotkach przez dwukierunkowe strumienie gRPC. Ten projekt równoważył autonomię z bezpieczeństwem, pozwalając komórkom regionalnym działać niezależnie podczas podziałów, jednocześnie zapewniając propagację unieważnienia w czasie sub-sekundowym poprzez epidemiczne nadawanie. Wybraliśmy to podejście pomimo jego złożoności operacyjnej, ponieważ spełniało unikalny wymóg rotacji bez przestojów i zapewniło zarządzanie kluczami wspierane przez sprzęt za pośrednictwem AWS CloudHSM w celu zapewnienia zgodności z poziomem FIPS 140-2.
Po wdrożeniu infrastruktura skróciła okna wystawienia poświadczeń z czterech godzin do mniej niż pięciu sekund, udanie wytrzymała całkowitą awarię regionalną w us-east-1 bez degradacji usług i przeszła audyty PCI DSS bez konieczności stosowania kontrolnych środków zaradczych dla zarządzania sekretami.
Jak teoremat CAP objawia się szczególnie w zarządzaniu sekretami podczas podziałów sieciowych i dlaczego nie możemy po prostu użyć spójności końcowej dla wszystkich operacji sekretów?
Podczas podziałów system musi wybrać między dostępnością a spójnością. W operacjach rotacji sekretów priorytetem jest CP (spójność ponad dostępność), ponieważ serwowanie nieaktualnych kluczy kryptograficznych podczas scenariusza kompromitacji stwarza nieodwracalne zagrożenie dla bezpieczeństwa. Jednak w przypadku operacji odczytu nieunieważnionych sekretów możemy zaakceptować zachowanie AP (dostępność ponad spójność). Kluczowa różnica polega na oddzieleniu płaszczyzny kontroli metadanych (która musi być spójna) od płaszczyzny danych (która może tolerować nieaktualność dla pamięci podręcznej, nieunieważnionych sekretów). Kandydaci często błędnie zakładają, że wszystkie operacje sekretów wymagają natychmiastowej spójności, pomijając niuanse dotyczące replik odczytu z ograniczoną nieaktualnością, które mogą obsługiwać 95% ruchu, podczas gdy kontrole unieważnienia zawsze trafiają do warstwy konsensusu.
Czym jest problem "thundering herd" w rotacji sekretów i jak wykładnicze opóźnienie z jitterem nie rozwiązuje go w skali?
Gdy certyfikaty wygasają jednocześnie w tysiącach podów (np. o północy UTC), jednoczesne żądania odświeżenia przytłaczają klaster Vault. Proste wykładnicze opóźnienie z pełnym jitterem wciąż tworzy skorelowane burze prób, ponieważ kontrolery Kubernetes często ponownie uruchamiają pody jednocześnie. Rozwiązanie wymaga wdrożenia ograniczenia tempa w stylu Token Bucket po stronie klienta, w połączeniu z aktywnym planowaniem rotacji przy użyciu algorytmów Splay, które rozdzielają okna odnowienia w czasie (np. 6 godzin przed wygaśnięciem). Dodatkowo, użycie uwierzytelnienia Cubbyhole z opakowywaniem odpowiedzi buforuje tokeny ephemeryczne lokalnie, redukując obciążenie uwierzytelnienia o 80%. Kandydaci pomijają, że współpraca po stronie klienta jest obowiązkowa; samo ograniczenie tempa po stronie serwera tworzy awarie lawinowe.
Dlaczego mutual TLS jest niewystarczające dla uwierzytelniania obciążenia w zarządzaniu sekretami w zerze-zaufania i jakie dodatkowe mechanizmy attestacji są wymagane?
mTLS weryfikuje, że obciążenie posiada ważny certyfikat, ale nie zapewnia, że samo obciążenie nie zostało skompromitowane po wdrożeniu lub że certyfikat nie został wyekfiltrowany z skompromitowanego węzła. Musimy wdrożyć SPIFFE z Node Attestation (weryfikacja tożsamości węzła Kubernetes przez projekcję Service Account) oraz Workload Attestation (weryfikacja etykiet podów i hashy obrazów przez Admission Controllers). Ponadto powiązanie sekretów z pomiarami TPM (Trusted Platform Module) zapewnia, że materiały kryptograficzne są związane z konkretami instancjami sprzętowymi. Kandydaci często mylą bezpieczeństwo transportu z autoryzacją tożsamości, pomijając to, że zarządzanie sekretami wymaga ciągłej weryfikacji stanu uruchomieniowego żądającego, a nie tylko kryptograficznego posiadania.