The_Cr3w/thecr3w-dev
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions 1
thecr3w-dev/docs/SECURITY.md

4.7 KiB
Raw Blame History

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.