ARDNTECH | Publiczny threat model

Metodyka: STRIDE (Spoofing / Tampering / Repudiation / Information disclosure / Denial of service / Elevation of privilege) zastosowana do pięciu powierzchni produktu. Każdy wiersz : zagrożenie - mitygacja ARDNTECH - świadomy trade-off.

Dokument przeznaczony dla CISO, audytorów i badaczy bezpieczeństwa. Kod źródłowy AGPL jest publiczny na github.com/aegirex/server. Szczegółowe runbooki operacyjne pozostają zarezerwowane dla design partnerów na podstawie NDA.

1. Zamodelowani aktorzy

Dziewięć profili atakującego uwzględnionych w modelu.

Aktor	Opis	Możliwości
Atakujący zewnętrzny	Internet, brak początkowego dostępu	Brute force, phishing, exploity web, MITM sieciowy
Sphishowany użytkownik	Użytkownik będący celem sklonowanej strony	Podaje swoje poświadczenia domenie atakującego
Złośliwy współlokator	Użytkownik innej organizacji ARDNTECH	Próbuje odczytać sekrety sąsiednich organizacji
Skompromitowana przeglądarka	Przeglądarka zainfekowana malware lub złośliwym rozszerzeniem	Dostęp do DOM, może odczytać pola wejściowe
Administrator serwera	Operator infrastruktury z dostępem SSH do serwera	Czyta bazę danych, czyta pamięć, modyfikuje kod
Eksfiltracja bazy danych	Skradziony backup, wyciekły dump SQL	Pełny snapshot bazy danych
Organ sądowy	Wezwanie sądowe, nakaz administracyjny	Zmusza hostingodawcę do dostarczenia przechowywanych danych
Insider ARDNTECH	Przyszły pracownik lub podwykonawca ARDNTECH	Przegląd kodu, dostęp do wdrożeń, odczyt logów
Przeciwnik kwantowy	Operacyjny komputer kwantowy (horyzont > 2030)	Łamie RSA / ECC w czasie wielomianowym (Shor)

2. Chronione dane

Klasyfikacja danych i poziom ochrony w spoczynku.

Dane	Wrażliwość	Przechowywanie
Hasło główne użytkownika	Krytyczne	Wyłącznie hash Argon2id (RFC 9106)
Treść sekretów (payload)	Krytyczne	Szyfrowane end-to-end (OpenPGP), serwer przechowuje nieprzejrzysty blob
Klucz prywatny OpenPGP użytkownika	Krytyczne	Nigdy na serwerze. Przechowywany lokalnie, chroniony passphrase użytkownika
Sekrety TOTP w spoczynku	Krytyczne	Szyfrowane XChaCha20-Poly1305 (klucz poza bazą danych)
Sekrety webhooków w spoczynku	Krytyczne	Szyfrowane XChaCha20-Poly1305 (klucz poza bazą danych)
Nazwy sekretów i folderów	Umiarkowane	W postaci jawnej po stronie serwera. Trade-off udokumentowany 5.1
Log audytu	Wysokie	Łańcuch HMAC-SHA-256, tamper-evidence w O(1)

3. Zagrożenia i mitygacje per powierzchnia

3.1 Aplikacja web SaaS

Zagrożenie	Mitygacja	Status
Brute force na haśle	Rate limiter 5 prób / 15 min per IP + Argon2id (256 MiB, 5 przebiegów) - 1 s na lokalną próbę	Dostarczone
Credential stuffing	Ten sam rate limiter + skan HIBP opt-in po logowaniu (wyraźna zgoda RODO)	Dostarczone
Obejście 2FA	TOTP RFC 6238 z issuer pinning + jednorazowe kody odzyskiwania + WebAuthn PRF	Dostarczone
XSS przechowywany lub odbity	Ścisła CSP (script-src 'self' 'wasm-unsafe-eval'), włączone Trusted Types, automatyczne escapowanie Twig	Dostarczone
Naruszenie zależności OpenPGP.js	Biblioteka vendorowana z odciskiem SHA-256 weryfikowanym przy buildzie (manifest integralności SRI)	Dostarczone
Phishing hasła głównego	Silna mitygacja wkrótce : passkeys WebAuthn PRF, które eliminują przesyłanie hasła i są powiązane z domeną pochodzenia przez przeglądarkę. W międzyczasie : szkolenie użytkowników + wskaźniki UI.	Wkrótce

3.2 Zaszyfrowane przechowywanie

Zagrożenie	Mitygacja	Status
Skradziony dump bazy danych	Payload szyfrowany OpenPGP E2E nieczytelny bez klucza prywatnego użytkownika. Hasła w hashu Argon2id nieodzyskiwalne	Dostarczone
Skradziony backup	Zaszyfrowane backupy (Argon2id + ChaCha20-Poly1305), multi-odbiorcy. Automatyczny test przywracania w CI	Dostarczone
Administrator serwera czyta treść sekretu	Niemożliwe bez klucza prywatnego użytkownika. Serwer przechowuje wyłącznie nieprzejrzyste bloby	Dostarczone
Manipulacja logiem audytu (tampering)	Łańcuch HMAC-SHA-256, wykrywanie w O(1) przy weryfikacji. Szczegóły łańcucha	Dostarczone

3.3 API REST

Zagrożenie	Mitygacja	Status
Wyciek danych cross-organizacja	Każdy token API powiązany z unikalną organizacją. Systematyczne filtrowanie na każdym endpoincie. Jawne testy izolacji w CI przy każdym commicie	Dostarczone
Kradzież tokenu API	Token hashowany Argon2id w bazie. Swobodna rotacja przez użytkownika. Minimalny scope (odczyt / zapis) konfigurowalny	Dostarczone
Atak DoS aplikacyjny	Rate limiter per token i per IP (framework Symfony)	Dostarczone

3.4 Rozszerzenia przeglądarki

Zagrożenie	Mitygacja	Status
Naruszenie pipeline buildu	Weryfikacja odcisku SHA-256 zależności łączona z buildem. Zaplanowany podpisany SBOM	Dostarczone
Zamknięcie popup = tymczasowa utrata dostępu	Trade-off pierwszej wersji : klucz prywatny nie jest utrwalany, aby ograniczyć powierzchnię ataku. Wkrótce : konfigurowalny auto-lock + persystencja przez kontrolowany service worker.	Wkrótce
Przechwycenie poświadczeń na stronie phishingowej	Użytkownik widzi rzeczywistą nazwę domeny w popup rozszerzenia przed kliknięciem "Zapisz"	Dostarczone

3.5 Infrastruktura self-hostowana

Zagrożenie	Mitygacja	Status
Skompromitowany obraz Docker	Automatyczny skan podatności w CI. Zaplanowany podpis Sigstore do weryfikacji użytkownika po stronie wdrożenia	W toku
Nieprzetestowany backup	Automatyczny test przywracania w CI przy każdym wydaniu. Brak niezweryfikowanego backupu na produkcji	Dostarczone
mTLS na produkcji	Aktywowalne przez konfigurację. Dostępne tryby audytu (tylko logi), a następnie enforcement	Dostarczone

4. Zakres ochrony - świadome ograniczenia

Uczciwość redakcyjna : oto powierzchnie, których ARDNTECH nie obejmuje sam, oraz zalecana mitygacja.

Ograniczenie	Dlaczego	Zalecana mitygacja
Pełne naruszenie stanowiska użytkownika	Malware z dostępem do RAM przeglądarki może odczytać odszyfrowany klucz prywatny	Sprzętowy passkey (YubiKey, TPM) zamykający klucz w bezpiecznym elemencie
Naruszenie serwera ARDNTECH (root)	Atakujący root może odczytać aktywne sesje HTTP	Przechowywane sekrety pozostają nieczytelne (zero-knowledge). Ryzykowne są wyłącznie sesje otwarte w momencie naruszenia. Zalecany krótki auto-lock
Utrata hasła głównego	Bezpośrednia konsekwencja ścisłego zero-knowledge : brak możliwości odzyskania klucza po stronie serwera	Kody odzyskiwania drukowane przy tworzeniu. Wkrótce : dzielenie Shamira M-z-N dla planów Enterprise
Przeciwnik kwantowy (horyzont > 2030)	OpenPGP v6 + AES-256 są szacowane jako bezpieczne przez 5 do 10 lat według RGS ANSSI 2024	Migracja post-kwantowa (ML-KEM, ML-DSA) w długoterminowej ocenie
Atak fizyczny na stanowisko użytkownika	ARDNTECH to sejf logiczny, a nie sejf fizyczny	Krótki auto-lock sejfu + sprzętowy passkey WebAuthn
Insider ARDNTECH (przyszły pracownik)	Świadoma granica modelu zaufania wydawcy SaaS	NDA, rozdzielenie obowiązków, obowiązkowy przegląd kodu, łańcuch audytu odporny na manipulacje, zasada najmniejszych uprawnień

5. Świadome trade-offy

5.1 Nazwy sekretów i folderów w postaci jawnej po stronie serwera

Wybór : nazwy przechowywane w postaci jawnej po stronie serwera.

Dlaczego : natychmiastowe wyszukiwanie po stronie serwera, wyświetlanie drzewa bez odszyfrowywania przy każdej nawigacji, możliwe hierarchiczne udostępnianie folderów.

Wpływ : atakujący, który eksfiltruje bazę danych, widzi, że sekret o nazwie "AWS Prod" istnieje w folderze "DevOps / Cloud". NIE widzi treści (payload szyfrowany E2E).

Rozważana alternatywa : opcja "anonymise me", która szyfruje również nazwy. Znaczący koszt UX : brak wyszukiwania po stronie serwera, pełny skan kliencki przy każdym żądaniu.

5.2 Hasło w postaci jawnej w DOM podczas wpisywania

Wybór : OpenPGP szyfruje payload po tym, jak użytkownik wpisze swoje hasło.

Dlaczego : brak alternatywy - przeglądarka musi widzieć postać jawną, aby umożliwić użytkownikowi jej wpisanie.

Mitygacje : Trusted Types CSP uniemożliwia DOM XSS wstrzyknięcie eksfiltrującego JavaScriptu. Wkrótce : passkeys WebAuthn, które całkowicie eliminują przesyłanie haseł.

5.3 Hasło główne = jedyny klucz sejfu

Wybór : brak odzyskiwania, jeśli użytkownik utraci jednocześnie swoje hasło główne ORAZ swoje kody odzyskiwania.

Dlaczego : ścisłe zero-knowledge. Gdybyśmy mogli odzyskać, istniałaby ścieżka odszyfrowywania po stronie serwera.

Mitygacja wkrótce : dzielenie Shamira klucza prywatnego (M-z-N części), jedna część u ARDNTECH z zabezpieczeniami proceduralnymi (odblokowanie wyłącznie przy obecności N-1 innych części zatwierdzonej przez użytkownika). Zarezerwowane dla planów Enterprise.

6. Plan reakcji na incydenty

Poziom	Wyzwalacz	Akcja
L1 Podejrzenie	Anomalia w logu audytu, zgłoszenie użytkownika	Wewnętrzne dochodzenie w ciągu 24 h, weryfikacja łańcucha audytu
L2 Potwierdzone naruszenie	Naruszenie techniczne potwierdzone przez dochodzenie	Powiadomienie użytkowników w ciągu 72 h (RODO Art. 33), rotacja dotkniętych kluczy, wdrożenie mitygacji
L3 Poważne naruszenie	Naruszenie bazy danych lub kodu źródłowego	Powiadomienie organu nadzorczego i ANSSI, publiczny transparency report, zewnętrzny audyt śledczy

Odpowiedzialne ujawnianie: Zgodnie z RFC 9116, plik /.well-known/security.txt w katalogu głównym witryny wskazuje nasz adres kontaktowy security@aegirex.eu. Termin potwierdzenia odbioru : 72 h.

Doprecyzować dokument?

Ten threat model to żywy dokument. Jeśli jesteś CISO, audytorem lub badaczem bezpieczeństwa i jakieś zagrożenie jest źle zamodelowane, skontaktuj się z nami bezpośrednio.

Macierz claims/dowody security@aegirex.eu

Publiczny <em>threat model.</em>