thecr3w-dev/docs/SECURITY.md

58 lines
4.7 KiB
Markdown

# 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.