Hurtownie Danych a Big Data: Ewolucja Bezpieczeństwa w Architekturach Strumieniowych

Głównym celem projektu jest wykazanie, że tradycyjne modele bezpieczeństwa ("Zamek i Fosa"), stosowane w hurtowniach danych, są niewystarczające ("nieporadne") w obliczu dynamicznego charakteru danych strumieniowych Big Data.

Użyte Technologie

• Apache Kafka (broker wiadomości)
• Apache Zookeeper (koordynacja klastra)
• Python (biblioteka kafka-python dla producenta i konsumenta)
• Docker & Docker Compose (konteneryzacja środowiska)
• OpenSSL & Keytool (generowanie certyfikatów CA i kluczy)
• Wireshark (analiza pakietów sieciowych)

Kontrast Dwóch Światów

Podstawowa różnica w bezpieczeństwie wynika z odmiennego charakteru danych w obu podejściach.

Cecha	Tradycyjna Hurtownia Danych	Architektura Big Data (strumieniowa)
Charakter Danych	Ustrukturyzowane, transakcyjne, historyczne.	Nieustrukturyzowane, strumieniowe, wysoka częstotliwość.
Przetwarzanie	Wsadowe (batch). Cykliczne ładowanie (ETL), np. raz na dobę.	Potokowe (stream). Przetwarzanie ciągłe "w locie", tuż po nadejściu.
Stan Danych	Dane "w spoczynku" (Data at Rest).	Dane "w ruchu" (Data in Motion).
Model Ochrony	"Zamek i Fosa". Silna ochrona perymetru sieciowego i centralnej bazy.	"Zero Trust". Ochrona każdej interakcji, szyfrowanie end-to-end, granularna autoryzacja.
Wniosek	Model centralny nie skaluje się do systemów rozproszonych.	Wymagane jest podejście warstwowe i rozproszone.

"Tradycyjna baza danych, zoptymalizowana pod kątem spójności transakcyjnej, nie jest zaprojektowana do obsługi tak intensywnego obciążenia zapisem jak strumienie Big Data."

Symulacja Potoku Danych IoT

Stworzono symulację potoku danych, w którym Producent (symulator czujnika IoT) wysyła odczyty temperatury do Brokera (Kafka), a Konsument je odbiera.

Architektura Systemu

Rys. 1. Schemat logiczny zaimplementowanego rozwiązania.

Proces zabezpieczania potoku został przeprowadzony w 4 krokach:

1. Scenariusz: Komunikacja Niezabezpieczona

• Stan: Domyślna konfiguracja PLAINTEXT.
• Zagrożenie: Dane przesyłane są jawnym tekstem. Każdy w sieci może je podsłuchać i zmodyfikować.
• Dowód: Analiza Wireshark pokazująca czytelny JSON z danymi sensora.

2. Scenariusz: Wdrożenie Szyfrowania (SSL/TLS)

• Rozwiązanie: Implementacja szyfrowania kanału komunikacyjnego.
• Działanie: Wygenerowanie własnego CA i certyfikatów dla brokera. Konfiguracja portu 9093 z protokołem SSL.
• Efekt: Zapewnienie poufności. Dane w Wiresharku są zaszyfrowane.

3. Scenariusz: Wdrożenie Uwierzytelniania (SASL)

• Rozwiązanie: Wymuszenie identyfikacji klientów (Authentication).
• Działanie: Konfiguracja mechanizmu SASL_PLAIN oraz plików JAAS.
• Efekt: Broker wie, KTO się łączy. Próba połączenia z błędnym hasłem kończy się błędem uwierzytelniania SASL.

4. Scenariusz: Wdrożenie Autoryzacji (ACL)

• Rozwiązanie: Zasada najmniejszych uprawnień (Authorization).
• Działanie: Włączenie AclAuthorizer w Kafce. Zdefiniowanie reguł:
  • Producer -> Może tylko PISAĆ (Write).
  • Consumer -> Może tylko CZYTAĆ (Read).

• Symulacja Ataku: Użytkownik zalogowany jako Consumer próbuje wysłać dane do brokera.
• Wynik: Operacja zablokowana przez serwer. Błąd TopicAuthorizationFailedError.

Podsumowanie

W środowiskach Big Data samo zabezpieczenie perymetru sieciowego jest nieskuteczne. Niezbędne jest wdrożenie wielowarstwowego modelu bezpieczeństwa obejmującego:

1. Szyfrowanie (dla poufności danych w ruchu).
2. Uwierzytelnianie (dla weryfikacji tożsamości maszyn/serwisów).
3. Autoryzację ACL (dla kontroli dostępu do konkretnych zasobów).

Tylko takie podejście pozwala na bezpieczne przetwarzanie strumieni danych o wysokiej intensywności w rozproszonym środowisku.