Architektura skupia się na głębokiej obronie z wykorzystaniem gwarancji kryptograficznych, a nie tylko kontroli dostępu.
Warstwa pobierania: Mikroserwisy publikują strukturalne zdarzenia audytowe do regionalnych klastrów Apache Kafka skonfigurowanych z TLS 1.3 i autoryzacją mTLS. Kafka Connect grupuje te zdarzenia do WORM (Write Once Read Many) przechowywania obiektów, takiego jak Amazon S3 Object Lock w trybie zgodności lub Azure Immutable Blob Storage. Ta konfiguracja fizycznie zapobiega usunięciu lub modyfikacji przez określony czas przechowywania, przetrwając nawet kompromitację poświadczeń administratora.
Warstwa integralności: Każda partia logów jest haszowana do drzewa Merkle'a, którego korzeń jest podpisywany przez Moduł Securitowy Sprzętowy (HSM) lub natywne chmurze enclave, takie jak AWS Nitro Enclaves. Te podpisane korzenie są okresowo publikowane w drugorzędnej niezmiennej księdze (np. GCP Cloud Storage z blokadami przechowywania), aby stworzyć warstwę notariusza między chmurami. To zapewnia, że naruszenie w jednej chmurze dostawcy nie może unieważnić całego łańcucha zaufania.
Warstwa zapytań: Gorące metadane (znaczniki czasu, identyfikatory usług, identyfikatory korelacji) są indeksowane w kolumnowej bazie OLAP, takiej jak ClickHouse lub Apache Druid, podczas gdy pełne zaszyfrowane ładunki znajdują się w zimnym przechowywaniu S3 Glacier lub Azure Archive. Zapytania sądowe najpierw trafiają do indeksu OLAP, aby zlokalizować zakresy czasowe, a następnie pobierają konkretne zaszyfrowane bloki przy użyciu kluczy zarządzanych przez HashiCorp Vault z rygorystycznym RBAC.
Globalny procesor płatności obsługujący dane PCI-DSS poziomu 1 doznał naruszenia, w którym napastnicy uzyskali dostęp do poświadczeń IAM poprzez zatrucony artefakt CI/CD. Natychmiastowym zagrożeniem była eksfiltracja danych, ale krytycznym ryzykiem było zniszczenie dowodów—napastnicy próbowali usunąć logi AWS CloudTrail, aby ukryć ścieżki ruchu bocznego.
Stara architektura opierała się na scentralizowanych tabelach audytowych PostgreSQL z flagami miękkiego usuwania i standardowymi koszykami S3. To nie zadziałało, ponieważ skompromitowane poświadczenia miały uprawnienia s3:DeleteObject, co pozwalało na usuwanie logów wewnątrz okna zgodności.
Rozwiązanie A: Triggery w bazie danych z RLS
To podejście wdrażało triggery PostgreSQL, aby przekierować usunięcia do tabeli archiwum i wprowadzało Row-Level Security (RLS). Zaletą były minimalne zmiany w infrastrukturze i zgodność z ACID dla zapytań relacyjnych. Wady były poważne: superużytkownik bazy danych mógł wyłączyć triggery lub modyfikować archiwalne wiersze, a rozwiązanie nie miało kryptograficznych dowodów integralności, co czyniło je niedopuszczalnym w postępowaniu sądowym.
Rozwiązanie B: Zatwierdzony Blockchain
Ta propozycja sugerowała przechowywanie wskaźników haszowych w Hyperledger Fabric, aby wykorzystać niezmienność rozproszonego rejestru. Zaletą była inherentna odporność na manipulacje i zdecentralizowane zaufanie. Wady były zniechęcające: opóźnienie transakcji wynosiło średnio pięć sekund, łamiąc wymóg zapisu poniżej sekundy dla logów handlu o wysokiej częstotliwości, a koszty przechowywania na łańcuchu dla surowych danych o skali petabajtowej były ekonomicznie nieosiągalne.
Rozwiązanie C: Hybrydowy WORM z Attestacją Merkle’a
To wybrane rozwiązanie umożliwiło Amazon S3 Object Lock w trybie zgodności z siedmioletnim okresem przechowywania, fizycznie zapobiegając usunięciu nawet przez posiadaczy konta administratora. Apache Kafka buforował zdarzenia lokalnie, aby zachować potwierdzenie producenta poniżej sekundy. Korzenie drzewa Merkle'a były obliczane co minutę i podpisywane przez AWS Nitro Enclaves, które przechowują klucze prywatne niedostępne dla hypervisora. Te podpisane korzenie były replikowane do niezmiennych koszyków Azure, tworząc warstwę notariusza między chmurami. Rezultat był udany: napastnik usunął dane aplikacji, ale ślad audytowy pozostał nienaruszony. Zespoły śledcze użyły ClickHouse, aby w ciągu sekund zidentyfikować okno ataku, odzyskały niezmienne logi z S3 i zweryfikowały dowody Merkle'a w stosunku do korzeni między chmurami, dostarczając dowody dopuszczalne w sądzie.
Jak rotujesz klucze podpisu w HSM, nie łamiąc kryptograficznego łańcucha zaufania dla historycznych logów?
Obracanie kluczy często traktowane jest jako prosta zamiana, ale w systemach odpornych na manipulacje naiwna rotacja może unieważnić wcześniejsze podpisy. Rozwiązanie wdraża nakładające się łańcuchy certyfikatów z Shamir's Secret Sharing dla klucza głównego. Gdy dokonuje się rotacji, nowy klucz podpisuje „wydarzenie rotacji”, które zawiera hasz starego klucza publicznego i znacznik czasu. To wydarzenie jest dołączane do łańcucha logów przed zamianą. Historyczna weryfikacja wykorzystuje klucz ważny w czasie podpisywania, podczas gdy samo wydarzenie rotacji jest podpisywane zarówno przez stare, jak i nowe klucze (przejście z podwójnym podpisem). HashiCorp Vault zarządza tym cyklem życia przy użyciu silników sekretnych PKI z automatycznymi politykami rotacji, które publikują certyfikaty na publicznym punkcie końcowym JWKS, dostępnym dla narzędzi śledczych.
Dlaczego blockchain jest niepotrzebny do osiągnięcia odporności na manipulacje i jakie specyficzne ograniczenia przepustowości sprawiają, że jest on nieodpowiedni w tym scenariuszu?
Kandydaci często mylą niezmienność z blockchainem. Blockchain rozwiązuje problem generałów bizantyjskich dla wzajemnie nieufnych stron bez centralnego organu. W systemie audytowym korporacyjnym podmiot sam jest zaczątkiem zaufania; model zagrożeń to kompromitacja od wewnątrz, a nie zmowa między firmami. Dlatego pozwalające jedynie na dodawanie WORM przechowywanie z weryfikacją drzewa Merkle'a zapewnia wystarczającą niezmienność bez nadmiaru konsensusu. Hyperledger Fabric osiąga około 3 000 transakcji na sekundę na świecie, podczas gdy pojedyncza partycja Kafka może obsługiwać 10 MB/s (miliony małych zdarzeń audytowych). Co ważniejsze, opóźnienie ostateczności blockchaina (sekundy do minut) łamie wymóg zapisu poniżej sekundy dla powiadamiania w czasie rzeczywistym o podejrzanych wzorcach dostępu.
Jak utrzymujesz wydajność zapytań nad petabajtami zaszyfrowanych, połączonych logów, gdy nie możesz odszyfrować całego zbioru danych dla każdego dochodzenia kryminalnego?
Naivna metoda pełnego odszyfrowania tabeli dla każdego zapytania jest obliczeniowo nie do wykonania. Architektura stosuje szyfrowanie w kopertach z hierarchiczną derivacją kluczy. Metadane—takie jak znaczniki czasu, identyfikatory usług oraz konteksty użytkowników—są wydobywane i szyfrowane osobno za pomocą Klucza Szyfrowania Danych (DEK), który jest indeksowany w ClickHouse w postaci otwartej (lub szyfrowanej kluczem specyficznym dla zapytania). Ciężki ładunek pozostaje zaszyfrowany własnym DEK w zimnym przechowywaniu. Gdy analityk pyta „wszystkie akcje administratorów między 2 AM a 3 AM”, ClickHouse zwraca wskaźniki obiektów. Tylko te konkretne obiekty są pobierane z Glacier, odszyfrowywane przy użyciu kluczy buforowanych w Redis z TTL i prezentowane. Ten wzorzec indeksowania metadanych skraca czasy zapytań z godzin do sekund, zachowując pełne szyfrowanie składowane w spoczynku.