Azure Event Hubs vs lokalny Kafka dla środowisk obronnych

Wybór platformy do strumieniowania zdarzeń dla programu obronnego to coś więcej niż porównanie wskaźników przepustowości. Wymagania dotyczące rezydencji danych, mandaty izolacji, ramy zgodności i poziomy klasyfikacji ograniczają decyzję w sposób, który nie ma odpowiednika w wdrożeniach komercyjnych. Zespół, który wybierze zarządzaną usługę chmurową bez sprawdzenia autoryzacji poziomów wpływu lub wdroży własny Kafka bez planowania obciążenia operacyjnego, napotka problemy niemożliwe do naprawienia po uruchomieniu systemu w produkcji.

Ten artykuł przedstawia schemat decyzyjny dla wyboru między Azure Event Hubs a lokalnym Apache Kafka dla środowisk obronnych, omawia specyficzne implikacje zgodności i architektury każdego z nich, opisuje model hybrydowy używający obu platform dla różnych warstw klasyfikacji i wyjaśnia ścieżkę migracji między nimi przy zmianie wymagań.

Dlaczego decyzja o platformie strumieniowania ma znaczenie w obronności

W wdrożeniu komercyjnym wybór między zarządzaną usługą strumieniowania a własnym klastrem to przede wszystkim kompromis operacyjny: zarządzane usługi kosztują więcej za zdarzenie, ale eliminują koszty zarządzania klastrem. W obronności decyzja jest również decyzją dotyczącą architektury zgodności i bezpieczeństwa, której konsekwencje przeżywają każdy sprint.

Przepisy dotyczące rezydencji danych dla informacji sklasyfikowanych określają nie tylko miejsce przechowywania danych, ale również którzy dostawcy infrastruktury są autoryzowani do ich obsługi. Program działający w ramach ograniczeń IL5 może korzystać tylko z regionów Azure Government, które otrzymały tymczasową autoryzację IL5 — nie każda usługa Azure w Azure Government kwalifikuje się i nie każdy region ma te same autoryzacje. Program z twardym wymaganiem izolacji nie ma ścieżki do zarządzanej usługi chmurowej, niezależnie od jej statusu FedRAMP, ponieważ nawet usługa autoryzowana przez FedRAMP High wymaga połączenia sieciowego do działania.

Platforma strumieniowania jest również miejscem, gdzie obowiązki zgodności dotyczące rejestrowania audytu, własności klucza szyfrowania i retencji danych są egzekwowane na poziomie infrastruktury. Właściwa architektura od samego początku oszczędza miesiące przeróbek, gdy urzędnik autoryzujący przegląda plan bezpieczeństwa systemu.

Azure Event Hubs: zarządzane strumieniowanie dla obciążeń GovCloud

API kompatybilne z Kafka i zero zarządzania klastrem

Poziomy Premium i Dedicated usługi Azure Event Hubs udostępniają punkt końcowy protokołu kompatybilnego z Kafka. Producenci i konsumenci zbudowani na bazie biblioteki klienta Apache Kafka łączą się z przestrzenią nazw Event Hubs, zmieniając dwie wartości konfiguracyjne: bootstrap.servers wskazuje na <namespace>.servicebus.usgovcloudapi.net:9093 w Azure Government, a sasl.mechanism jest ustawiony na PLAIN z poświadczeniami parametrów połączenia lub na token Azure Active Directory przy użyciu mechanizmu OAuth bearer. Nie są wymagane żadne zmiany kodu specyficzne dla Kafka. API jest kompatybilne z bibliotekami klientów Kafka 1.0 i nowszymi.

Konsekwencją operacyjną jest to, że nikt w twoim zespole nie musi zarządzać aprowizacją brokerów, konfiguracją kworum kontrolera, rotacją certyfikatów TLS klastra, magazynami poświadczeń SCRAM ani skalowaniem pojemności. Jednostki przepustowości skalują się na żądanie. Dostępność jest objęta umową o poziomie usług. Georedundancja to ustawienie konfiguracyjne, a nie projekt wielolokalizacyjny.

Autoryzacja FedRAMP High, IL4 i IL5

Azure Event Hubs w Azure Government posiada autoryzację FedRAMP High. Poziom Dedicated, który zapewnia infrastrukturę z jednym najemcą, obsługuje poziomy wpływu IL4 i IL5 zgodnie z dokumentacją w macierzy dostępności usług Azure Government. Szyfrowanie przy użyciu kluczy zarządzanych przez klienta jest dostępne za pośrednictwem Azure Key Vault Managed HSM, spełniając wymaganie AES-256 dla danych w spoczynku, które niosą obciążenia IL5. Dane przetwarzane i przechowywane w Event Hubs Dedicated w Azure Government nie opuszczają granicy chmury rządowej.

Dla programów, których pułap klasyfikacji to CONFIDENTIAL lub FOUO — lub obciążeń SECRET z zatwierdzonym punktem dostępu do chmury — Event Hubs Dedicated w Azure Government jest często najszybszą ścieżką do zgodnej infrastruktury strumieniowania. Infrastruktura brokerów jest objęta pakietem autoryzacji FedRAMP firmy Microsoft, zmniejszając obszar, który twój zespół musi udokumentować i bronić w planie bezpieczeństwa systemu.

Ograniczenia API i ich znaczenie dla aplikacji obronnych

Event Hubs nie implementuje kompletnego API Kafka. Transakcje i semantyka exactly-once między wieloma tematami nie są obsługiwane na poziomie brokera. API zarządzania ACL AdminClient są nieobecne — kontrola dostępu jest obsługiwana na poziomie Azure RBAC (role Data Sender i Data Receiver w zakresie przestrzeni nazw lub encji) zamiast natywnych ACL Kafka. Przesunięcia grup konsumentów są zarządzane przez usługę i nie są bezpośrednio manipulowalny za pomocą API zatwierdzania przesunięć Kafka w taki sam sposób jak w własnym klastrze.

Dla aplikacji obronnych budowanych od podstaw z myślą o Event Hubs te luki są możliwe do obejścia przez projektowanie wokół nich. Dla aplikacji migrujących z własnego Kafka, które polegają na transakcjach lub programowym zarządzaniu ACL, wymagają zmian kodu. Przeprowadź audyt tej listy zależności przed zaangażowaniem się w Event Hubs jako długoterminową platformę.

Lokalny Kafka: możliwości izolacji i pełna kontrola klasyfikacji

Jedyna opłacalna ścieżka dla twardych wymagań izolacji

Każdy program z mandatem do działania bez zewnętrznej łączności sieciowej — czy to ze względów bezpieczeństwa fizycznego, operacyjnego, czy akredytacyjnych — ma dokładnie jedną opłacalną platformę strumieniowania: własny Kafka na lokalnej infrastrukturze. Nie ma równoważnej zarządzanej usługi, która działa bez dostępu do internetu. Azure Event Hubs, niezależnie od statusu zgodności, wymaga łączności z płaszczyzną sterowania Azure Government do aprowizacji zasobów, rotacji tokenów SAS i odbierania wywołań API zarządzania.

Lokalny Kafka w trybie KRaft, wdrożony bez interfejsów sieciowych przekierowanych poza granicę enklawy, spełnia twarde wymaganie izolacji. Wszystkie zależności — JVM, binarne Kafka, obrazy kontenerów, certyfikaty TLS — są wstępnie przygotowywane lokalnie przed odcięciem sieci. Klaster następnie działa nieskończenie bez łączności wychodzącej. Szczegółowy opis etapowania obrazów kontenerów i wzorców wdrożenia izolowanego znajdziesz w artykule o wzorcach wdrożenia izolowanego dla środowisk obronnych.

Tryb KRaft i autonomiczne działanie klastra

Kafka 3.3 wprowadził tryb KRaft jako zastępstwo dla zarządzania metadanymi opartego na ZooKeeper. Dla wdrożeń obronnych KRaft jest właściwym domyślnym ustawieniem dla każdego nowego klastra. Oddzielny ensemble ZooKeeper dodaje trzy lub więcej dodatkowych węzłów, oddzielną domenę awarii, odrębną powierzchnię konfiguracji i dodatkowy proces do łatania i zabezpieczania. KRaft konsoliduje zarządzanie kworum kontrolera w samym procesie brokera Kafka przy użyciu dziennika konsensusu opartego na Raft.

W małym lub średnim sklasyfikowanym wdrożeniu — trzech do pięciu węzłów brokerów — role kontrolera i brokera mogą być współlokalizowane na tych samych węzłach, utrzymując całkowitą liczbę węzłów na poziomie trzech. W większych wdrożeniach dedykowane kworum trzech kontrolerów oddzielone od węzłów brokerów zapewnia czystsze granice operacyjne. W obu przypadkach klaster nie ma zewnętrznych zależności usług podczas działania po uruchomieniu.

Obciążenie operacyjne i implikacje kadrowe

Własny Kafka nie jest operacyjnie bezpłatny. Klaster Kafka sklasyfikowany w klasie produkcyjnej wymaga ciągłej uwagi: utwardzanie OS i cykle łatania, zarządzanie cyklem życia certyfikatów TLS zgodne z harmonogramem odnowień wewnętrznej PKI, rotacja poświadczeń SCRAM, dostrajanie retencji dziennika brokera, ponowne równoważenie partycji wraz z rosnącą przepustowością tematu i planowanie pojemności dla dysku brokera. Aktualizacje kroczące między małymi wersjami Kafka wymagają starannego sekwencjonowania, aby uniknąć niezgodności protokołu.

Programy, które nie doceniają tego obciążenia, kończą z klastrami, które z czasem odbiegają od zatwierdzonej linii bazowej konfiguracji — problem, który boleśnie ujawnia się podczas przeglądów ponownej akredytacji. Jeśli program nie ma dedykowanej funkcji inżynieryjnej platformy, zaplanuj jawnie, kto będzie właścicielem operacji Kafka przed uruchomieniem klastra w produkcji.

Macierz decyzyjna

Poniższa tabela mapuje kluczowe czynniki wdrożenia na odpowiedni wybór platformy.

Czynnik	Azure Event Hubs	Lokalny Kafka
Twarda izolacja wymagana	Niewykonalne	W pełni obsługiwane
FedRAMP High / IL4/IL5	Dziedziczone z Azure Gov	Odpowiedzialność operatora
Pułap klasyfikacji danych	IL5 / FOUO (GovCloud)	SECRET / TS (izolacja)
Wymagana zdolność operacyjna	Minimalna (usługa zarządzana)	Wysoka (pełne operacje klastra)
Zarządzanie klastrem	Brak (w pełni zarządzany)	Pełne (TLS, KRaft, łatki)
Elastyczność przepustowości	Elastyczna (jednostki przepustowości)	Ręczne skalowanie brokerów
Pełna powierzchnia API Kafka	Częściowa (brak transakcji)	Kompletna

Architektura hybrydowa: warstwowe strumieniowanie według poziomu klasyfikacji

Wiele programów obronnych działa jednocześnie w wielu domenach klasyfikacji. Platforma zarządzania przestrzenią walki może pobierać niesklasyfikowane kanały OSINT, dane logistyczne FOUO i telemetrię czujników SECRET z tego samego obrazu operacyjnego. Zbudowanie pojedynczej infrastruktury strumieniowania spełniającej wszystkie trzy warstwy jest niemożliwe — wymaganie izolacji dla danych SECRET jest niekompatybilne z podejściem zarządzanej chmury, które dobrze sprawdza się dla danych FOUO.

Praktyczną odpowiedzią jest architektura warstwowa: Azure Event Hubs w Azure Government obsługuje warstwę UNCLASSIFIED i FOUO, gdzie autoryzacja FedRAMP High pokrywa wymaganie zgodności, a zarządzane skalowanie obsługuje zmienne wskaźniki pozyskiwania. Lokalny Kafka za izolowaną enklawą obsługuje warstwę SECRET i TS, gdzie żadna zewnętrzna zależność sieciowa nie jest tolerowana. Dwie warstwy nie są bezpośrednio połączone.

Rozwiązania cross-domain na granicy warstw

Tam, gdzie zdegradowane lub udostępnialne dane muszą przepłynąć ze sklasyfikowanej warstwy do niesklasyfikowanej — na przykład oczyszczony raport o pozycji wyprowadzony z fuzji śladu SECRET — certyfikowane rozwiązanie cross-domain (CDS) egzekwuje granicę. CDS sprawdza dane wychodzące według zdefiniowanej polityki treści, usuwa oznaczenia klasyfikacji i pola wrażliwe oraz udostępnia wynik niesklasyfikowanej przestrzeni nazw Event Hubs. Nie istnieje bezpośrednia ścieżka sieciowa między dwoma środowiskami Kafka. CDS jest jedynym przewodem, a jego przepływy danych są udokumentowane w planie bezpieczeństwa systemu i zatwierdzane podczas akredytacji.

Ta architektura jest bardziej złożona w działaniu niż rozwiązanie jednowarstwowe, ale odzwierciedla rzeczywistość wielodomenowych programów obronnych. Głębsze omówienie wzorców projektowania cross-domain znajdziesz w artykule o rozwiązaniach cross-domain dla obronności.

Ścieżka migracji: z Event Hubs do lokalnego Kafka

Programy czasami zaczynają od Event Hubs — ponieważ obciążenie początkowo kwalifikuje się do wdrożenia GovCloud — i później odkrywają, że wymagania klasyfikacyjne rosną, dodawany jest mandat izolacji lub program migruje do bardziej restrykcyjnej enklawy sieciowej. API kompatybilne z Kafka oznacza, że ta migracja to zmiana konfiguracji, a nie przepisywanie kodu.

Co zmienia się podczas migracji

Po stronie producenta i konsumenta zmieniają się trzy wartości konfiguracyjne. Po pierwsze, bootstrap.servers przenosi się z punktu końcowego przestrzeni nazw Event Hubs na wewnętrzny adres lokalnego klastra Kafka. Po drugie, security.protocol i sasl.mechanism zmieniają się z SASL_SSL z PLAIN na SASL_SSL z SCRAM-SHA-512. Po trzecie, konfiguracja truststore zmienia się z publicznego łańcucha certyfikatów usługi Azure na certyfikat wewnętrznego CA dla lokalnego klastra. Identyfikatory grup konsumentów, nazwy tematów i cała logika warstwy aplikacji pozostają niezmienione.

Po stronie infrastruktury lokalny klaster Kafka musi być aprowizowany, utwardzony i przetestowany z reprezentatywnym obciążeniem przed przełączeniem producentów. Konfiguracja tematów — liczby partycji, współczynniki replikacji, polityki retencji — musi być replikowana z przestrzeni nazw Event Hubs do klastra lokalnego. Przesunięcia grup konsumentów z Event Hubs nie mogą być bezpośrednio przetransferowane; zaplanuj okno przełączenia, w którym konsumenci ponownie przetwarzają od początku okna retencji lub od znalezionego punktu kontrolnego.

Lista kontrolna przed migracją

Przed wykonaniem przełączenia potwierdź, że lokalny klaster przeszedł przegląd bezpieczeństwa: TLS 1.3 zweryfikowany na wszystkich listenerach przez openssl s_client, audyt ACL zakończony za pomocą kafka-acls.sh --list, porty brokerów potwierdzone nieosiągalne spoza enklawy przez skan sieci, i wszystkie poświadczenia SCRAM konta serwisowego przechowywane w systemie zarządzania sekretami z skonfigurowaną rotacją. Udokumentuj procedurę przełączenia w runbooku i przeprowadź próbę z obciążeniami nieprodukcyjnymi przed migracją sklasyfikowanych strumieni danych. Informacje o kontrolach sieci zero-trust, które powinny owijać warstwę Kafka, znajdziesz w artykule o architekturze zero-trust dla sieci wojskowych.

Corvus.Quantum: dwutryb strumieniowania dla sklasyfikowanych programów obronnych

Corvus.Quantum to zabezpieczona platforma strumieniowania zdarzeń dla obronności, obsługująca oba tryby wdrożenia opisane w tym artykule. W wdrożeniach GovCloud integruje się z Azure Event Hubs Dedicated przy użyciu kluczy zarządzanych przez klienta i uwierzytelniania Azure Active Directory, zapewniając wstępnie skonfigurowany stos producentów i konsumentów z szyfrowaniem post-kwantowym na poziomie aplikacji. W wdrożeniach izolowanych działa na autonomicznym klastrze Kafka w trybie KRaft z TLS 1.3, SCRAM-SHA-512 i zaszyfrowanym przez LUKS przechowywaniem brokerów — wszystko wstępnie utwardzone i zatwierdzone dla środowisk sklasyfikowanych.

Platforma została wdrożona operacyjnie do przetwarzania danych obronnych w czasie rzeczywistym, obsługując tysiące zdarzeń na sekundę przy opóźnieniu end-to-end poniżej 100 ms. Dodaje enkapsulację klucza CRYSTALS-Kyber i szyfrowanie ładunku AES-256-GCM na poziomie aplikacji, chroniąc zawartość wiadomości zarówno przed bieżącym przechwyceniem, jak i przyszłym kwantowym deszyfrowaniem — wymóg dla danych czujników i ISR o długim czasie wrażliwości.

Dla programów poruszających się w wyborze między Event Hubs a lokalnym Kafka, Corvus.Quantum eliminuje potrzebę budowania i utrzymywania oddzielnych utwardzonych konfiguracji dla każdego trybu wdrożenia. Ta sama aplikacja łączy się z dowolnym zapleczem przez tę samą warstwę abstrakcji, a ścieżka migracji między trybami nie wymaga zmian kodu aplikacji. Kiedy wymagania klasyfikacyjne programu się zmieniają, infrastruktura strumieniowania zmienia się wraz z nimi.

Powiązane artykuły

• Apache Kafka dla obronności: bezpieczna architektura przesyłania wiadomości w czasie rzeczywistym
• Wzorce wdrożenia izolowanego dla środowisk obronnych
• Architektura zero-trust dla sieci wojskowych