Security Model

Security Model

Cel

Celem modelu bezpieczeństwa jest ochrona:

• danych lokalnych po stronie węzłów,
• integralności procesu trenowania federacyjnego,
• poufności i autentyczności komunikacji między komponentami.

Warstwy bezpieczeństwa

1. Transport security (TLS)

• Komunikacja REST i gRPC jest realizowana przez TLS.
• Certyfikaty serwera muszą być poprawnie skonfigurowane.
• Klienci weryfikują certyfikat CA (lub dedykowany truststore).

2. Uwierzytelnianie i autoryzacja (JWT)

• Node clients uwierzytelniają się i otrzymują token JWT.
• Każde wywołanie API/gRPC powinno przekazywać ważny token.
• Wygasłe lub nieprawidłowe tokeny powodują odrzucenie żądania.

3. Tożsamość węzła i podpisy

• Węzeł posiada klucz prywatny/publiczny.
• Rejestracja i/lub handshake może wykorzystywać podpis żądania.
• Agregator utrzymuje spójność tożsamości node i odrzuca niespójne dane.

4. Lokalna prywatność różnicowa (DP)

• Aktualizacje modelu są przycinane (clipping).
• Dodawany jest szum Gaussa.
• Parametry DP mogą być centralnie sterowane per runda przez Aggregator:
  • dp_enabled
  • dp_noise_multiplier

5. Szyfrowanie homomorficzne (HE)

• W trybie HE aktualizacje wag są szyfrowane po stronie node.
• HE Sidecar wykonuje agregację na szyfrogramach bez deszyfrowania.
• Agregator wymusza zgodność publicznego kontekstu HE między zgłoszeniami.

6. Ochrona przed złośliwymi aktualizacjami

• Agregator stosuje robust aggregation (np. Multi-Krum/Bulyan).
• Podejrzane aktualizacje mogą być odrzucane.
• Odrzucenia i statusy są rejestrowane do obserwowalności.

Dynamiczne sterowanie hiperparametrami a bezpieczeństwo

Agregator może adaptacyjnie stroić:

• fedprox_mu
• dp_noise_multiplier
• dp_enabled

Korzyści:

• lepszy kompromis prywatność vs jakość modelu,
• szybsza reakcja na pogorszenie metryk,
• centralna kontrola polityki bezpieczeństwa treningu.

Zagrożenia i mechanizmy obrony

Podsłuch / MITM

• Mitigacja: TLS, poprawna walidacja certyfikatów.

Nieautoryzowany klient

• Mitigacja: JWT + walidacja tożsamości węzła.

Zatrute aktualizacje modelu

• Mitigacja: robust aggregation, monitorowanie odrzuceń, polityki quorum.

Wyciek danych z aktualizacji

• Mitigacja: DP (clipping + noise), opcjonalnie HE.

Niespójny kontekst HE

• Mitigacja: walidacja he_context_public i odrzucanie niespójnych payloadów.

Dobre praktyki operacyjne

• Regularna rotacja sekretów i certyfikatów.
• Minimalne uprawnienia kont i serwisów.
• Monitoring błędów auth/TLS/HE.
• Aktualizacje dependency i obrazów kontenerów.
• Separacja środowisk (dev/test/prod).
• Audyt logów oraz alerty na nietypowe zdarzenia.

Checklist bezpieczeństwa przed produkcją

1. TLS włączony dla REST i gRPC.
2. JWT aktywne, sekret ustawiony bez wartości domyślnych.
3. Certyfikaty i sekrety trzymane poza kodem źródłowym.
4. Konfiguracja DP świadomie ustawiona (zakresy i cele).
5. HE przetestowane end-to-end (jeśli używane).
6. Reguły agregacji odpornej aktywne i monitorowane.
7. Dashboardy oraz alerty bezpieczeństwa skonfigurowane.

Incydenty: szybka procedura

1. Zidentyfikuj komponent (Aggregator, node, RabbitMQ, HE Sidecar).
2. Sprawdź błędy autoryzacji i certyfikatów.
3. Zweryfikuj integralność i źródło zgłoszeń node.
4. Ogranicz wpływ: wyłącz podejrzane node / zaostrz politykę.
5. Zbierz artefakty (logi, metryki, status rund).
6. Przywróć działanie i wykonaj postmortem.