Ta strona opisuje docelowy magazyn dowodów (S3-compatible, retencja per klasa, legal hold, eksport) — to jest specyfikacja, nie działający komponent. Dziś dowody żyją w PostgreSQL z hash-chain (sha256 + chain-of-custody) — to jest LIVE. Vault jako osobna warstwa storage z politykami retencji i blokadą prawną to ROADMAP. Zero mieszania tych dwóch rzeczy.
Evidence-package (GET /reports/evidence-package/:id) generuje dziś JSON i PDF z manifestem,
package_sha256 oraz śladem chain-of-custody, zapisane jako rekordy w żywej PostgreSQL. To jest
dowodliwy szkielet integralności — nie jest to jednak dedykowany magazyn (vault) z politykami retencji
per klasa dowodu, blokadą prawną (legal hold) ani eksportem do zewnętrznego storage S3-compatible. Ta strona
opisuje, czego brakuje do takiego vaulta i dlaczego to osobny etap dojrzałości.
GET /reports/evidence-package/:id — manifest, package_sha256, ślad audytowy,
chain-of-custody. Realny generator PDF bez zewnętrznych zależności.
Parsery Burp/ZAP/Nessus/CSV → normalizacja severity → incydent + evidence z sha256 i
chain-of-custody zapisane w PostgreSQL (import = MEDIA_SIGNAL, nie dowód naprawy).
Reguła egzekwowana w bazie: zamknięcie incydentu bez statusu CONFIRMED zwraca 422. Retest zmienia
package_sha256 evidence-package.
Dziś: obiekty evidence i pliki PDF żyją w PostgreSQL / procesie generowania on-demand — nie w osobnym S3-compatible object store z własnymi politykami dostępu.
Poniżej opisujemy elementy, które składałyby się na dedykowany vault. Żaden z nich nie istnieje dziś jako uruchomiony komponent — to plan architektoniczny.
| Element | Cel | Opis (SPEC) | Status |
|---|---|---|---|
| Storage backend | Trwałość niezależna od bazy aplikacyjnej | Obiektowy magazyn S3-compatible (np. MinIO / kompatybilny provider) jako warstwa pod evidence-package i surowe artefakty (raporty skanerów, załączniki). Odseparowany od bazy transakcyjnej — awaria aplikacji nie zagraża dowodom. | ROADMAP |
| Retencja per klasa | Różne okresy przechowywania wg typu dowodu i wymogu regulacyjnego | Polityki retencji przypisane do klasy dowodu (np. finding-evidence, engagement-report, incident-audit-log) z różnymi okresami zgodnymi z wymogami sektorowymi (DORA/NIS2 orientacyjnie — wymaga potwierdzenia przez dział compliance/prawnika instytucji, nie jest to porada prawna). | ROADMAP |
| Legal hold | Blokada usunięcia/nadpisania podczas postępowania | Flaga na obiekcie/klasie dowodu wstrzymująca automatyczne usuwanie zgodnie z retencją, gdy trwa postępowanie, spór lub żądanie organu. Wymaga audytowalnego rejestru „kto i kiedy nałożył hold”. | ROADMAP |
| Eksport z manifestem | Przekazanie dowodu na zewnątrz (audytor, organ, partner) w formie weryfikowalnej | Paczka eksportowa: artefakty + manifest (hash każdego pliku, chain-of-custody, zakres czasowy) + docelowo podpis formalny (PAdES/TSA — patrz znane ograniczenia). Dziś mamy odpowiednik tylko dla evidence-package (manifest + sha256), nie dla całego vaulta. | ROADMAP |
| Kontrola dostępu per obiekt | Granularne uprawnienia niezależne od RBAC aplikacji | Polityki dostępu na poziomie pojedynczego obiektu w vault (np. tylko rola audytora + rola CISO), odrębne od dzisiejszego RBAC na poziomie API (który jest LIVE). | ROADMAP |
| Weryfikacja integralności w czasie | Wykrycie nadpisania/usunięcia poza kontrolą aplikacji | Okresowa rekalkulacja hash i porównanie z manifestem zapisanym w chwili wstawienia, niezależnie od warstwy aplikacyjnej — dowód, że dowód się nie zmienił. | ROADMAP |
sha256 i chain-of-custody w rekordzie PostgreSQL
dowodzi integralności treści w danym momencie odczytu, ale nie daje: (1) izolacji storage od aplikacji,
(2) wymuszonej retencji, (3) blokady prawnej niezależnej od logiki aplikacyjnej. Świadomie nie nazywamy
dzisiejszego stanu „vaultem" — to byłby overclaim.
Powiązane: rejestr znanych ograniczeń (auth/transport/PDF/tenancy) → /known-limitations · pełna roadmapa sprintów z dowodami → /roadmap-dev · macierz statusów → /status-matrix.