# THECR3W-DEV — POLITYKA BEZPIECZEŃSTWA I MODEL ZAGROŻEŃ ## Wersja: 1.0.0 | Data: 2026-10-31 --- ## 1. Zasady Nadrzędne Bezpieczeństwa 1. **Zasada Minimalnych Uprawnień (Least Privilege):** Żaden proces, kontener ani użytkownik nie otrzymuje uprawnień wykraczających poza jego niezbędną funkcję. 2. **Zero Fikcyjnych Integracji:** Wszystkie integracje opierają się na twardych, zweryfikowanych kontraktach i mechanizmach kryptograficznych. 3. **Brak Sekretów w Repozytorium:** Żadne hasła, klucze prywatne, tokeny czy pliki środowiskowe nie mogą znaleźć się w systemie kontroli wersji. 4. **Niezmienność i Integralność (Immutability & Integrity):** Każdy artefakt binarny oraz manifest wdrożeniowy jest identyfikowany przez kryptograficzny skrót (SHA256) i weryfikowany podpisem cyfrowym Ed25519. --- ## 2. Model Zagrożeń (STRIDE) | Kategoria Zagrożenia | Identyfikowany Wektor Ataku | Środek Zaradczy w TheCr3w-dev | |---|---|---| | **Spoofing (Podszywanie)** | Podszycie się pod serwer aktualizacji lub nieuprawnionego administratora. | Wymóg TLS, autoryzacja OIDC (Keycloak Bearer JWT z walidacją aud/iss), podpisywanie metadanych release'ów kluczem Ed25519. | | **Tampering (Modyfikacja)** | Podmiana pliku binarnego (APK/EXE/MSI) w magazynie lub modyfikacja obrazu Docker. | Rygorystyczna weryfikacja SHA256 pobranego pliku przez SDK przed instalacją; wdrożenia Docker wyłącznie po niezmiennym `immutable_digest` (`sha256:...`). | | **Repudiation (Wypieranie się)** | Operator lub programista zaprzecza wykonaniu wdrożenia lub publikacji wydania. | Niezmienny dziennik audytowy w PostgreSQL (`audit_events`) rejestrujący tożsamość aktora, korelacyjny identyfikator UUID, adres IP oraz kryptograficzne podpisy manifestów/wydań. | | **Information Disclosure (Wyciek Danych)** | Wyciek kluczy dostępowych Cloudflare R2, haseł bazodanowych lub tokenów administracyjnych. | Klienci pobierają pliki wyłącznie przez krótko żyjące Pre-signed URLs; brak ekspozycji kluczy R2; bezpieczne wstrzykiwanie zmiennych `.env` na serwerze; maskowanie wrażliwych pól w logach. | | **Denial of Service (Odmowa Usługi)** | Przeciążenie endpointów sprawdzania aktualizacji lub próba wyczerpania zasobów serwera. | Wbudowany Rate Limiting w ASP.NET Core; bezpośrednie pobieranie artefaktów z Cloudflare R2 (odciążenie łącza VPS); brak obciążania bazy danymi binarnymi. | | **Elevation of Privilege (Eskalacja Uprawnień)** | Wykorzystanie realm `master` w Keycloak lub przejęcie kontroli nad Docker Socket. | Używanie wyłącznie ról klienta (`thecr3w-backend:client-roles`) bez ról `realm-management`; Deployment Agent operujący w oparciu o białą listę poleceń; brak wystawienia Docker Socket na zewnątrz. | --- ## 3. Zabezpieczenie Integracji z Keycloak (Realm `master`) > [!WARNING] > Zgodnie z wymaganiem Właściciela Projektu, integracja IAM odbywa się z istniejącym realm `master` na `https://login.thecr3wnet.com`. > Ponieważ realm `master` standardowo zarządza całym serwerem Keycloak, wdrożono następujące twarde reguły: > 1. **Client Scopes i Client Roles:** Wszystkie uprawnienia systemowe (`thecr3w:admin`, `thecr3w:release-manager`, `thecr3w:approver`, `thecr3w:deployer`, `thecr3w:viewer`) są tworzone jako role przypisane do dedykowanego klienta `thecr3w-backend`. > 2. **Brak ról w `master-realm`:** Żaden użytkownik panelu TheCr3w-dev nie może posiadać roli `admin`, `create-realm` ani uprawnień z `realm-management`. > 3. **Walidacja Tokenu:** Backend ASP.NET Core weryfikuje: > - `iss` (Issuer): `https://login.thecr3wnet.com/realms/master` > - `aud` (Audience): `thecr3w-backend` > - Ważność kluczy JWKS pobieranych automatycznie z Keycloak. > 4. **Wyłączona rejestracja użytkowników:** Brak publicznej rejestracji w realm `master`. --- ## 4. Ochrona Magazynu Cloudflare R2 - Bucket `thecr3w-app` jest **całkowicie prywatny**. - Dostęp publiczny jest blokowany na poziomie Cloudflare R2 Settings. - Jedynym uprawnionym podmiotem posiadającym `R2_ACCESS_KEY_ID` i `R2_SECRET_ACCESS_KEY` jest backend Native Update API. - URLs pobierania posiadają restrykcyjny parametr wygasania: `ExpiresIn = 900 seconds` (15 minut). --- ## 5. Zabezpieczenie Wdrożeń Kontenerowych i Docker Socket - Deployment Control API **nie ma bezpośredniego dostępu do `/var/run/docker.sock`**. - Wszelkie operacje wdrożeniowe są przekazywane przez izolowany interfejs IPC/Agenta wdrożeniowego. - Dozwolona jest wyłącznie realizacja wdrożeń na podstawie podpisanych manifestów wdrożeniowych (`deployment_manifests`), których skrót SHA256 został wcześniej zatwierdzony przez uprawnionego Approvera. - Wdrożenia produkcyjne po zmiennym tagu `:latest` są **programowo blokowane** przez walidację schematu.