Biała Księga Bezpieczeństwa

Architektura bezpieczeństwa platformy CyberZgodność EDU  ·  Ostatnia aktualizacja: 2026-05-15  ·  Wersja: 1.0

1. Izolacja Dzierżawców (RLS PostgreSQL)

Fundamentem izolacji jest FORCE ROW LEVEL SECURITY w PostgreSQL 16. Każda tabela zawierająca dane Dzierżawcy posiada kolumny tenant_id i (opcjonalnie) org_unit_id. Middleware Django ustawia zmienne sesji GUC przed każdym zapytaniem:

-- Middleware ustawia parę GUC przy każdym żądaniu:
SET LOCAL app.current_tenant_id = '<uuid>';
SET LOCAL app.current_org_unit_id = '<uuid>';
SET LOCAL ROLE app;  -- rola bez uprawnień superuser

-- Przykładowa polityka RLS:
CREATE POLICY tenant_isolation ON audit_log
  USING (tenant_id = current_setting('app.current_tenant_id')::uuid);

ALTER TABLE audit_log ENABLE ROW LEVEL SECURITY;
ALTER TABLE audit_log FORCE ROW LEVEL SECURITY;

Rola app ma uprawnienia INSERT/SELECT/UPDATE na tabelach biznesowych. Rola audit_writer ma wyłącznie INSERT na dzienniku audytu (append-only). Migracje wykonuje oddzielna rola superuser migrator — nigdy w trakcie obsługi żądania.

2. Integralność dziennika audytu

Każdy wpis dziennika audytu jest powiązany z poprzednim przez kryptograficzny łańcuch skrótów SHA-256:

# Obliczanie skrótu wiersza (Python):
import hashlib, json

def compute_row_hash(prev_hash: str, row_data: dict) -> str:
    canonical = json.dumps(row_data, sort_keys=True, ensure_ascii=False)
    payload = prev_hash + canonical
    return hashlib.sha256(payload.encode()).hexdigest()

# Weryfikacja całego łańcucha:
# GET /api/audit/verify  --> zwraca {valid: true, chain_length: N}
# lub wskazuje pierwszy uszkodzony wiersz

Rola audit_writer ma wyłącznie INSERT — brak UPDATE ani DELETE. FORCE ROW LEVEL SECURITY obowiązuje również na dzienniku. Przerwanie łańcucha (np. przywracanie po awarii) tworzy „kotwicę nieciągłości” z dokumentacją zdarzenia — jest to celowa funkcja, nie błąd.

3. Szyfrowanie haseł

Hasła są szyfrowane Argon2id z parametrami broniącymi przed atakami brute-force nawet przy użyciu GPU:

• Pamięć ≥ 64 MiB per hash (domyślnie 64 MiB)
• Iteracje ≥ 3
• Równoległość ≥ 1
• Sól losowa 16 bajtów (per hasło)

Nigdy nie przechowujemy hasła w postaci jawnej ani zaszyfrowanej odwracalnie. Skrót jest przechowywany w kolumnie z ograniczeniami RLS — niedostępny dla roli app przez SELECT.

4. Uwierzytelnianie wieloskładnikowe (MFA)

MFA jest obowiązkowe dla wszystkich kont bez wyjątku. Dostępne metody:

• TOTP (RFC 6238) — kompatybilne z Google Authenticator, Aegis, Microsoft Authenticator. Sekret szyfrowany AES w bazie danych (klucz w Vault).
• WebAuthn / Passkeys — klucze sprzętowe (YubiKey, Titan) lub klucze platformy (Face ID, Windows Hello). Klucz prywatny nigdy nie opuszcza urządzenia.

5. Zarządzanie kluczami (HashiCorp Vault)

Vault obsługuje envelope encryption per dzierżawca:

• DEK (Data Encryption Key) — per dzierżawca, generowany losowo przy tworzeniu konta.
• KEK (Key Encryption Key) — przechowywany w Vault Transit Engine; szyfruje DEK.
• Vault jest uszczelniany kluczami Shamira podzielonymi między uprawnionych operatorów (n-of-m). Brak pojedynczego punktu kompromitacji.
• Rotacja kluczy: protokół dual-window (stary DEK dekryptuje stare dane, nowy szyfruje nowe; migracja w tle).

6. Transport danych — TLS 1.3

Cała komunikacja sieciowa odbywa się przez TLS 1.3 (wymuszane przez Cloudflare). VPS nie ma otwartych portów na zewnątrz — cały ruch HTTP/HTTPS trafia przez Cloudflare Tunnel (mTLS wewnętrznie). Nagłówki HSTS z preloadingiem.

7. Kopie zapasowe (polityka 3-2-1)

Testy przywracania są wykonywane automatycznie co 90 dni i rejestrowane w dzienniku audytu z kodem backup.restore_drill.complete.

8. Kontrola dostępu pracowników Operatora

Dostęp do infrastruktury produkcyjnej jest ograniczony do minimum niezbędnych osób. Każde połączenie z VPS odbywa się przez Cloudflare Access (SSO + MFA), a SSH przez Cloudflare Tunnel — nie przez otwarty port 22.

9. OIDC / SAML SSO per Dzierżawca

Platforma obsługuje federację tożsamości per Dzierżawca:

• OIDC (OpenID Connect) — kompatybilne z Microsoft Entra ID (Azure AD), Google Workspace, Keycloak.
• SAML 2.0 — dla starszych IdP; podpisane asercje, weryfikacja ACS RelayState.
• WebAuthn Passkeys — dostępne również jako metoda logowania (bez hasła).

Konfiguracja IdP jest per Dzierżawca — jeden Dzierżawca nie może wpłynąć na konfigurację innego.

10. Zarządzanie podatnościami

• Automatyczne aktualizacje bezpieczeństwa OS (unattended-upgrades).
• Przegląd CVE dla zależności Python/Node co miesiąc.
• Responsible disclosure: security@cyberzgodnosc.edu.pl / security.txt.
• Testy penetracyjne: [DO UZUPEŁNIENIA: planowane Q4 2026 lub nazwa wykonawcy].

11. Monitoring i reagowanie na incydenty

• Monitoring uptime z alertami SMS/e-mail do dyspozytora on-call.
• Wewnętrzna procedura reagowania na incydenty (Severity 1–4) z wyznaczonym koordynatorem.
• Powiadomienie Dzierżawcy o naruszeniu danych w ciągu 72h (DPA art. 10).
• Post-mortem i raport dla Dzierżawców przy incydentach Severity ≤2.

12. Bezpieczeństwo fizyczne

VPS jest hostowany w centrum danych OVHcloud (Warszawa, Polska) posiadającym certyfikat ISO/IEC 27001. Dane nie opuszczają UE i pozostają w Polsce. Operator nie posiada własnej infrastruktury fizycznej. Fizyczny dostęp do serwerów jest wyłączną kompetencją OVHcloud.

13. Zgodność z NIS2 / KSC

Architektura bezpieczeństwa platformy jest zaprojektowana tak, aby same środki techniczne spełniały wymagania art. 21 §2 NIS2 (szyfrowanie, MFA, kontrola dostępu, ciągłość działania, zarządzanie incydentami, bezpieczeństwo łańcucha dostaw). Szczegółowe mapowanie: Nota zgodności z NIS2/KSC.

14. Czego jeszcze nie robimy