Apache Kafka w obronności: bezpieczna architektura przesyłania komunikatów w czasie rzeczywistym

Systemy obronne generują dane w tempie i wolumenie, których konwencjonalne architektury żądanie-odpowiedź nie są w stanie wchłonąć. Pojedynczy BSP przesyła dziesiątki parametrów telemetrii na sekundę. Węzeł C2 na poziomie brygady obsługuje setki raportów pozycji i zdarzeń statusowych na minutę. Komórka fuzji ISR jednocześnie przetwarza dane z radarów, rozpoznania sygnałowego i raportowania ludzkiego — wszystkie wymagające korelacji poniżej jednej sekundy. Gdy te strumienie muszą przepływać niezawodnie przez odporną, audytowalną i niejawną infrastrukturę, Apache Kafka stał się architektonicznym filarem z wyboru.

Niniejszy artykuł omawia wdrożenie Kafka specjalnie dla zastosowań obronnych: strategię partycjonowania dla środowisk wielopoziomowej klauzuli tajności, pełną konfigurację szyfrowania, wdrożenie air-gap z użyciem trybu KRaft oraz kompromis między klastrami samodzielnie hostowanymi a zarządzanymi alternatywami, takimi jak Azure Event Hubs dla obciążeń GovCloud.

Dlaczego strumieniowanie zdarzeń pasuje do architektur obronnych

Przepływy pracy w obronności są z natury sterowane zdarzeniami. Telemetria sensorowa nie przybywa w schludnych partiach — jest to ciągły strumień odczytów, które muszą być przetwarzane w chwili nadejścia, aby były operacyjnie użyteczne. Zdarzenia C2 — ruch jednostek, zmiany zadań, aktualizacje statusu — to dyskretne komunikaty, których jednocześnie potrzebuje wiele systemów konsumujących: wspólny obraz operacyjny, logistyka, koordynacja ognia i raportowanie po akcji — wszystkie potrzebują tego samego zdarzenia źródłowego, nie wiedząc, kto słucha.

Model publish-subscribe Kafka czysto odwzorowuje to wymaganie. Producent zapisuje odczyt sensorowy lub zdarzenie C2 do tematu. Dowolna liczba grup konsumentów — każda reprezentująca inną aplikację downstream — odtwarza zdarzenie niezależnie we własnym tempie. To odsprzężenie oznacza, że dodanie nowego obciążenia analitycznego nie wymaga zmian w systemie produkującym, co jest kluczowe w środowiskach obronnych, gdzie kontrola zmian oprogramowania jest powolna, a cykle zatwierdzania są długie.

Poza odsprzężeniem, trwały log Kafka zapewnia dziennik audytowy tylko do dołączania, spełniający wymagania kryminalistyczne większości systemów obronnych. Każdy komunikat jest przechowywany na dysku przez konfigurowalny okres. Jeśli dojdzie do incydentu, operatorzy mogą odtworzyć dokładną sekwencję zdarzeń poprzedzających go, bez polegania na logowaniu na poziomie aplikacji.

Podstawowa architektura Kafka dla środowisk niejawnych

Topologia brokerów

Klaster Kafka klasy produkcyjnej dla zastosowań niejawnych wymaga minimum trzech węzłów brokerów, aby obsługiwać współczynnik replikacji trzy i ustawienie min.insync.replicas równe dwa. Taka konfiguracja toleruje utratę jednego brokera bez utraty danych ani błędów producentów. W przypadku wdrożeń niejawnych o wysokiej dostępności, pięć brokerów — rozłożonych na co najmniej trzech fizycznych szafach lub strefach dostępności — zapewnia silniejszą odporność na awarie z marginesem na aktualizacje kroczące.

Od Kafka 3.3 tryb KRaft zastępuje ZooKeeper w zarządzaniu metadanymi klastra. W przypadku izolowanych wdrożeń obronnych nie jest to opcja — to prawidłowe domyślne rozwiązanie. Oddzielny zestaw ZooKeeper dodaje trzy kolejne węzły, oddzielną domenę awarii i dodatkową powierzchnię ataku. KRaft konsoliduje zarządzanie metadanymi w samych brokerach Kafka, używając kworum kontrolerów opartego na Raft, zazwyczaj współhostowanego z brokerami w małych klastrach lub oddzielonego w dużych.

Partycjonowanie tematów według poziomu klauzuli tajności

Najważniejszą decyzją architektoniczną we wdrożeniu Kafka z wielopoziomową klauzulą tajności jest sposób wymuszania izolacji między danymi na różnych poziomach wrażliwości. Istnieją dwa podejścia.

Pierwsze podejście używa jednego klastra z izolacją ACL na poziomie tematu. Tematy są przestrzenie nazw według klauzuli tajności: ts.sensor.uav-telemetry dla telemetrii ściśle tajnej, s.c2.position-reports dla tajnych danych C2, c.logistics.supply-events dla poufnych danych logistycznych. Każde konto usługi ma przyznane prawa do produkcji i konsumpcji wyłącznie z tematów odpowiadających jego poziomowi uprawnień. Podejście to zmniejsza złożoność operacyjną, ale wymaga wysokiego zaufania do egzekwowania ACL przez Kafka i starannej segmentacji sieci, aby procesy brokerów same nie stały się ścieżką do ruchu bocznego.

Drugie podejście — preferowane przy obsłudze danych powyżej TAJNEGO na tej samej infrastrukturze fizycznej — używa oddzielnych klastrów brokerów na domenę klauzuli tajności, połączonych przez rozwiązanie między domenami (CDS) w rzadkich przypadkach, gdy zdegradowane dane muszą przepłynąć przez granicę. Całkowicie eliminuje ryzyko współdzielonego brokera, kosztem zwiększonego obciążenia operacyjnego. Szczegółowe omówienie architektur między domenami znajdziesz w artykule na temat rozwiązań między domenami dla obronności.

Retencja i liczba partycji

Ustalaj liczbę partycji na podstawie oczekiwanej przepustowości, a nie wygody. Temat obsługujący 10 000 komunikatów na sekundę z tablicy sensorowej powinien mieć wystarczająco dużo partycji, aby każdy konsument w grupie mógł przetwarzać przypisane mu partycje bez opóźnień. Praktyczna zasada: liczba partycji powinna wynosić co najmniej tyle, ile konsumentów w grupie konsumentów, a najlepiej dwa do trzech razy więcej, aby umożliwić rebalansowanie grupy konsumentów bez powstawania wąskich gardeł.

Decyzje dotyczące polityki retencji muszą być udokumentowane i uzasadnione. Telemetria sensorowa analizowana niemal w czasie rzeczywistym zazwyczaj potrzebuje tylko 24–72 godzin retencji przed przeniesieniem do zimnego magazynu lub usunięciem. Dzienniki zdarzeń C2 wymagane do przeglądu po akcji powinny być przechowywane przez 30–90 dni w warstwie gorącej, po czym należy je wyeksportować do zaszyfrowanego, niezmiennego archiwum. Nie polegaj wyłącznie na Kafka jako długoterminowym magazynie audytowym — jest to magistrala zdarzeń, nie baza danych archiwalna.

Szyfrowanie w trakcie transmisji: TLS 1.3 i SASL SCRAM

Środowiska niejawne nakazują szyfrowanie na każdej ścieżce danych. Dla Kafka oznacza to dwa odrębne mechanizmy: szyfrowanie transportu i uwierzytelnianie klientów.

Konfiguracja TLS 1.3

Skonfiguruj każdy nasłuch Kafka — łącznie z komunikacją między brokerami — z TLS 1.3. W server.properties:

listeners=SASL_SSL://0.0.0.0:9093
advertised.listeners=SASL_SSL://broker-1.internal:9093
ssl.protocol=TLSv1.3
ssl.enabled.protocols=TLSv1.3
ssl.keystore.location=/etc/kafka/ssl/broker.keystore.jks
ssl.keystore.password=${KEYSTORE_PASSWORD}
ssl.truststore.location=/etc/kafka/ssl/ca.truststore.jks
ssl.truststore.password=${TRUSTSTORE_PASSWORD}
ssl.client.auth=required

Ustawienie ssl.client.auth=required wymusza wzajemne TLS (mTLS): każdy łączący się klient musi przedstawić certyfikat podpisany przez wewnętrzny urząd certyfikacji. Gwarantuje to, że tylko znane, aprowizowane systemy mogą połączyć się z klastrem — wymóg w każdej niejawnej enklawie. Nie używaj requested ani none w środowiskach niejawnych.

Certyfikaty muszą pochodzić z wewnętrznej infrastruktury PKI. Nie używaj certyfikatów podpisanych przez publiczne CA w środowisku air-gap — i nie zezwalaj na publiczne korzenie CA w truststore brokera, ponieważ mogłoby to umożliwić skompromitowanemu zewnętrznemu certyfikatowi podszywanie się pod legalnego klienta.

SASL SCRAM-SHA-512

Ponad mTLS używaj SASL SCRAM-SHA-512 do uwierzytelniania na poziomie użytkownika. Wiąże to nazwaną tożsamość — na przykład konto usługi dla konkretnej aplikacji — z połączeniem TLS, umożliwiając szczegółowe egzekwowanie ACL oparte na nazwie podmiotu, a nie tylko na nazwie podmiotu certyfikatu.

sasl.enabled.mechanisms=SCRAM-SHA-512
sasl.mechanism.inter.broker.protocol=SCRAM-SHA-512
security.inter.broker.protocol=SASL_SSL

Aprowizuj poświadczenia przy użyciu kafka-configs.sh i przechowuj je w systemie zarządzania sekretami — HashiCorp Vault lub odpowiednim magazynie sekretów air-gap — a nie w plikach konfiguracyjnych. Rotuj poświadczenia zgodnie z harmonogramem odpowiadającym polityce zarządzania kluczami akredytacji, zazwyczaj co 90 dni lub przy zmianach personalnych.

Szyfrowanie danych w spoczynku: AES-256 i mechanizmy warstwy magazynowej

Kafka natywnie nie szyfruje danych zapisywanych do segmentów logów. Szyfrowanie danych w spoczynku jest odpowiedzialnością warstwy magazynowej. W przypadku wdrożeń na sprzęcie fizycznym lub maszynach wirtualnych używaj LUKS (Linux Unified Key Setup) z AES-256 w trybie XTS na urządzeniach blokowych hostujących log.dirs Kafka. W przypadku wdrożeń opartych na Kubernetes, udostępniaj zasoby StorageClass obsługiwane przez zaszyfrowane wolumeny — na Azure Government używaj szyfrowania po stronie serwera z kluczami zarządzanymi przez klienta (SSE-CMK) na Azure Disk. Odpowiedniki lokalne obejmują NetApp z dyskami NSE lub czysto programowy LUKS na standardowym NVMe.

W przypadku obciążeń, gdzie nawet operator magazynu nie może odczytać zawartości komunikatów — szczególnie istotne dla programów specjalnego dostępu — zaimplementuj szyfrowanie na poziomie aplikacji: producent szyfruje ładunek komunikatu przed zapisem, a tylko autoryzowani konsumenci posiadają klucz deszyfrowania. Podejście to jest niezależne od konfiguracji Kafka i zapewnia poufność end-to-end, która utrzymuje się nawet w przypadku kompromitacji magazynu brokera. Kompromisem jest to, że filtrowanie i kompakcja po stronie brokera stają się niemożliwe na zaszyfrowanych ładunkach, ponieważ broker nie może sprawdzić zawartości.

Izolowane wdrożenie Kafka (air-gap) z trybem KRaft

Izolowane wdrożenie Kafka nie ma łączności z Internetem, zewnętrznego rozwiązywania DNS ani dostępu do publicznych rejestrów kontenerów ani serwerów lustrzanych pakietów. Każdy komponent musi być dostępny lokalnie przed uruchomieniem klastra. Ta sekcja omawia konkretne pułapki, które napotykają inżynierowie przy wdrażaniu w tym środowisku.

Tryb KRaft i działanie bez ZooKeeper

Używaj Kafka 3.6 lub nowszej z włączonym trybem KRaft. Klaster wymaga kworum kontrolerów — zazwyczaj trzy węzły kontrolerów, które mogą być współlokowane z brokerami we wdrożeniach trzech do pięciu węzłów. Każdemu węzłowi przypisuje się node.id i wartość process.roles równą controller, broker lub obu.

Uruchom klaster poleceniem kafka-storage.sh format, aby wygenerować UUID klastra i zapisać początkowy log metadanych. Ten krok musi być uruchomiony na każdym węźle z tym samym UUID przed uruchomieniem jakiegokolwiek procesu brokera. W środowisku air-gap generuj UUID na jednym węźle, kopiuj go do pozostałych, a następnie uruchamiaj format na każdym z nich.

CLUSTER_ID=$(kafka-storage.sh random-uuid)
kafka-storage.sh format -t $CLUSTER_ID -c /etc/kafka/server.properties

Wewnętrzny DNS i zarządzanie certyfikatami

Skonfiguruj advertised.listeners tak, aby używały w pełni kwalifikowanych nazw hostów rozwiązywalnych w obrębie enklawy — przez wewnętrzny serwer DNS lub przez /etc/hosts na każdym hoście, który będzie łączył się z klastrem. Bezpośrednie używanie adresów IP w advertised.listeners działa, ale komplikuje zarządzanie certyfikatami, ponieważ SAN certyfikatów muszą zawierać każdy adres IP.

Uruchom offline root CA przy użyciu step-ca lub CFSSL — obu nie mających zewnętrznych zależności w czasie działania. Generuj certyfikaty brokerów z SAN obejmującymi nazwę hosta brokera. Dystrybuuj certyfikat główny CA do truststore każdego klienta. Ustalaj okresy ważności certyfikatów zgodnie z harmonogramem ponownej akredytacji i prowadź inwentarz certyfikatów, aby odnowienia nie powodowały nieoczekiwanych awarii.

Zarządzanie obrazami kontenerów i artefaktami

Pobieraj wszystkie wymagane obrazy — Kafka, stos monitorowania i wszelkie wtyczki Kafka Connect — na maszynie z dostępem do Internetu, eksportuj je za pomocą docker save, transferuj do środowiska air-gap przy użyciu zatwierdzonej diody danych lub procesu przenośnych nośników i ładuj do lokalnego rejestru za pomocą docker load. Przypinaj tagi obrazów do konkretnych skrótów w manifestach wdrożeniowych, aby zapobiec nieoczekiwanym zmianom w przypadku aktualizacji lokalnego rejestru. Szczegółowe informacje na temat wdrożeń Kubernetes air-gap w kontekście obronnym znajdziesz w artykule na temat wzorców wdrożeń air-gap dla obronności.

Azure Event Hubs jako alternatywa kompatybilna z Kafka

Nie każde obciążenie obronne wymaga w pełni odłączonego, samodzielnie zarządzanego klastra. W przypadku programów działających w granicach GovCloud — Azure Government, IL4 lub IL5 — warstwy Azure Event Hubs Premium i Dedicated zapewniają punkt końcowy kompatybilny z Kafka, który akceptuje standardowych producentów i konsumentów Kafka bez zmian w kodzie. Powierzchnia protokołu jest kompatybilna z bibliotekami klienckimi Kafka 1.0 i nowszymi.

Event Hubs w Azure Government spełnia autoryzację FedRAMP High, a w przypadku warstwy Dedicated obsługuje klucze zarządzane przez klienta poprzez Azure Key Vault Managed HSM, zapewniając mechanizm szyfrowania AES-256 danych w spoczynku, którego wymagają niejawne obciążenia. Korzyść operacyjna jest znacząca: brak aprowizacji brokerów, brak rotacji certyfikatów dla samego klastra, wbudowana georedundancja i dostępność gwarantowana umową SLA.

Kompromis jest oczywisty: Event Hubs nie obsługuje pełnej powierzchni API Kafka (brak transakcji, brak semantyki dokładnie raz między tematami na poziomie brokera i brak niestandardowego modelu ACL poza RBAC na poziomie przestrzeni nazw). A w przypadku obciążeń, które muszą być całkowicie izolowane od sieci — bez łączności z jakąkolwiek zewnętrzną siecią — Event Hubs nie jest opcją. Dla tych programów samodzielnie hostowane klastry KRaft pozostają jedyną realną ścieżką.

Integracja zero-trust dla konsumentów Kafka

Model ACL Kafka jest koniecznym, ale niewystarczającym mechanizmem bezpieczeństwa w środowisku zero-trust. Każda usługa konsumenta powinna uwierzytelniać się przy użyciu krótkotrwałego poświadczenia wydanego przez dostawcę tożsamości w momencie uruchamiania poda lub procesu, a nie długotrwałego statycznego hasła. Silnik sekretów Kafka w Vault może dynamicznie wydawać krótkotrwałe poświadczenia SCRAM, z automatycznym unieważnieniem po wygaśnięciu dzierżawy. W połączeniu z certyfikatami klienta mTLS rotowanymi zgodnie z harmonogramem, gwarantuje to, że skompromitowane poświadczenie konta usługi ma ograniczone okno operacyjne dla atakującego.

Stosuj polityki sieciowe na poziomie Kubernetes lub zapory sieciowej, aby tylko pody z właściwymi etykietami mogły docierać do portów brokera Kafka. Natywne ACL Kafka powinny być drugą linią obrony, a nie pierwszą. Pełne omówienie architektury zero-trust zastosowanej do sieci obronnych znajdziesz w artykule na temat architektury zero-trust dla sieci wojskowych.

Corvus.Quantum: strumieniowanie oparte na Kafka z szyfrowaniem postkwantowym

Corvus.Quantum to sprawdzona bojowo platforma strumieniowania zdarzeń zbudowana na Kafka, wdrożona operacyjnie na Ukrainie do przetwarzania danych obronnych w czasie rzeczywistym. Rozszerza standardową Kafka o szyfrowanie postkwantowe na poziomie aplikacji — używając CRYSTALS-Kyber do enkapsulacji kluczy i AES-256-GCM do szyfrowania ładunków — tak aby komunikaty były chronione zarówno przed bieżącym przechwytywaniem przez przeciwnika, jak i przyszłymi atakami deszyfrowania z użyciem komputerów kwantowych. Odpowiada to na zagrożenie „zbierz teraz, odszyfruj później", które jest szczególnie istotne dla danych sygnałowych i ISR o długim czasie wrażliwości.

Poza szyfrowaniem Corvus.Quantum zapewnia wstępnie utwardzoną konfigurację brokerów dla niejawnych wdrożeń: szablony klastrów w trybie KRaft, automatyzację certyfikatów TLS 1.3 przy użyciu wbudowanej instancji step-ca, rotację poświadczeń SCRAM zintegrowaną z HashiCorp Vault oraz szablony ACL tematów uwzględniające klauzulę tajności. Platforma została zwalidowana w środowiskach bez łączności z Internetem, obsługując tysiące zdarzeń sensorowych na sekundę z opóźnieniem end-to-end poniżej 100 ms.

Dla zespołów ds. zamówień oceniających Kafka dla programów obronnych, Corvus.Quantum skraca czas zabezpieczenia klastra Kafka z miesięcy do dni, zapewniając jednocześnie audytowalną linię bazową konfiguracji zgodną z wymaganiami CNSA 2.0 i obsługującą integrację z istniejącymi rozwiązaniami między domenami.

Powiązane artykuły

• Architektura zero-trust dla sieci wojskowych
• Wzorce wdrożeń air-gap dla obciążeń obronnych
• Kryptografia postkwantowa i zgodność z CNSA 2.0 dla obronności