Dokument referencyjny dla zespołów technicznych oceniających Evidence & Resilience Orchestrator: architektura, endpointy, model danych, model dowodu, RBAC, audit log, chain-of-custody, integracje, tryby wdrożenia, model bezpieczeństwa i ograniczenia. Rozdzielamy jawnie co jest LIVE od tego, co jest ROADMAP. Wszystkie liczby i przykłady poniżej to dane syntetyczne. Doktryna: claim ≤ proof.
ipIII przyjmuje findings ze skanerów, normalizuje je do wspólnego modelu, buduje pakiet dowodowy z hashem integralności i łańcuchem custody, wspiera retest i domknięcie incydentu z dowodem — całość na żywej PostgreSQL, za JWT/RBAC i z audit-logiem. Poniżej rozkładamy każdą warstwę na części pierwsze i wskazujemy granicę między tym, co działa, a tym, co planowane.
Monolityczna aplikacja usługowa z jednym magazynem stanu. Świadomie prosta na etapie MVP — mniej ruchomych części do zaudytowania.
klient (CLI / UI / konektor)
│ HTTPS + Bearer JWT
▼
┌───────────────────────────────┐
│ API ipIII (/api/ip3/v1) │ ← RBAC middleware, walidacja wejścia
│ ├─ import (parsery skanerów) │
│ ├─ incidents / claims │
│ ├─ evidence-package (+hash) │
│ ├─ retest / close-with-proof │
│ ├─ legal-triggers (support) │
│ └─ audit-log (append) │
└───────────────┬───────────────┘
▼
PostgreSQL (stan + audit + custody)
REST pod /api/ip3/v1. Wejście walidowane, odpowiedzi JSON. Middleware RBAC przed handlerami.
PostgreSQL jako pojedyncze źródło prawdy: incydenty, claims, evidence, audit, custody.
Parsery Burp / ZAP / Nessus / CSV normalizują findings do wspólnego modelu.
Webhook ingestion, STIX/TAXII, SIEM (Splunk/Sentinel/QRadar), DefectDojo/ticketing sync.
Pełna specyfikacja w /api-docs. Poniżej reprezentatywny podzbiór z wymaganą rolą.
| Metoda / ścieżka | Funkcja | Rola min. | Status |
|---|---|---|---|
POST /api/ip3/v1/import | Import findings ze skanera (parser wg formatu) | analyst | LIVE |
GET /api/ip3/v1/incidents | Lista incydentów (filtry: severity, status) | viewer | LIVE |
POST /api/ip3/v1/incidents/:id/claims | Dodanie claimu do incydentu (claim ≤ proof) | analyst | LIVE |
POST /api/ip3/v1/evidence-package | Budowa pakietu dowodowego + sha256 + manifest | analyst | LIVE |
POST /api/ip3/v1/incidents/:id/retest | Rejestracja retestu (wynik: fixed / regression) | analyst | LIVE |
POST /api/ip3/v1/incidents/:id/close | Domknięcie z dowodem (close-with-evidence) | lead | LIVE |
GET /api/ip3/v1/audit | Odczyt audit-logu (append-only) | auditor | LIVE |
GET /api/ip3/v1/coverage | Metryki pokrycia dowodowego incydentów | viewer | LIVE |
POST /api/ip3/v1/legal-triggers/evaluate | Mapowanie obowiązków (DORA/NIS2/RODO/AI Act) — decision-support | analyst | LIVE |
POST /api/ip3/v1/webhook/ingest | Strumieniowy ingest zdarzeń (SIEM / STIX-TAXII) | service | ROADMAP |
Relacyjny, znormalizowany wokół incydentu. Uproszczony schemat (kolumny wybrane; dane przykładowe syntetyczne).
incident (id, title, severity, status, source, created_at, closed_at) finding (id, incident_id, scanner, cve, cvss, epss_hint, raw_ref) claim (id, incident_id, statement, proof_ref, verdict) -- claim ≤ proof evidence (id, incident_id, kind, blob_ref, package_sha256, created_at) retest (id, incident_id, result, tester, evidence_ref, ts) custody_event (id, evidence_id, actor, action, prev_hash, hash, ts) -- chain-of-custody audit_event (id, actor, role, action, target, ts) -- append-only user_role (user_id, role) -- RBAC
Findings, claims, evidence i retesty wiszą pod incydentem. Jeden agregat = jeden przedmiot audytu.
claim.proof_ref i verdict wymuszają, że twierdzenie ma wskazać dowód, inaczej pozostaje GAP.
audit_event i custody_event są dopisywane, nie modyfikowane w miejscu.
Pakiet dowodowy jest samoopisujący: manifest listuje artefakty, każdy z hashem, a łańcuch custody wiąże zdarzenia w sekwencję.
package_sha256 — zmiana dowolnego bajtu unieważnia hash.custody_event) zapisuje aktora, akcję, prev_hash i hash — łańcuch pozwala wykryć wstawienie/usunięcie ogniwa.sha256 dowodzi niezmienności treści pakietu, ale to nie jest kwalifikowany podpis
elektroniczny. Podpis PAdES i znacznik czasu TSA (RFC 3161), a docelowo podpis PQC, są ROADMAP.
Dopóki ich nie ma, pakiet ma wartość operacyjną i integralnościową, a nie formalno-prawną najwyższego rzędu. Szczegóły granic → /known-limitations.
Kontrola dostępu oparta na rolach, egzekwowana w middleware przed handlerem. Model najmniejszych uprawnień.
| Rola | Zakres | Przykładowe uprawnienia |
|---|---|---|
viewer | odczyt | lista incydentów, coverage, dashboard |
analyst | praca operacyjna | import, claims, evidence-package, retest, legal-triggers |
lead | domknięcia | close-with-evidence, zatwierdzenia |
auditor | wgląd rozliczalny | odczyt audit-logu i custody, bez modyfikacji |
service | maszynowy | ingest webhook (ROADMAP) |
Rozliczalność każdej zmiany stanu. Log jest dopisywany, adresowany rolą aktora i przeznaczony do odczytu przez rolę auditor.
GET /api/ip3/v1/audit z filtrami po aktorze, akcji i zakresie czasu.| Integracja | Kierunek | Status |
|---|---|---|
| Parsery skanerów (Burp / ZAP / Nessus / CSV) | import → ipIII | LIVE |
| Evidence-package (JSON + PDF board-pack) | ipIII → eksport | LIVE |
| Legal Trigger Engine (DORA/NIS2/RODO/AI Act) | wewn. decision-support | LIVE |
| DefectDojo / ticketing (Jira-style) | ipIII ↔ tracker | ROADMAP |
| SIEM (Splunk / Microsoft Sentinel / QRadar) | SIEM → ipIII (webhook) | ROADMAP |
| STIX / TAXII (MISP / OpenCTI) | dwukierunkowo | ROADMAP |
| CVE enrichment online (NVD / CISA KEV / EPSS) | lookup → ipIII | ROADMAP (dziś offline hint) |
Instancja prowadzona przez K0NSULT: aplikacja + PostgreSQL, TLS na warstwie hostingu. Najszybsza ścieżka pilota.
Wdrożenie w infrastrukturze klienta (kontener + własna baza). Wymaga paczki wdrożeniowej i dokumentacji ops.
Izolacja per organizacja: tenant scoping + Row-Level Security w PostgreSQL, rozdzielone audit-logi. Priorytet P1.
Pełny opis warstwy bezpieczeństwa i modelu zagrożeń → /security-architecture. Skrót poniżej.
Bearer JWT na każdym wywołaniu. ROADMAP: OIDC/JWKS z zewnętrznego IdP.
RBAC w middleware, najmniejsze uprawnienia, rola sprawdzana przed handlerem. LIVE
TLS jednostronny na hostingu. mTLS (wzajemny) między usługami/konektorami — ROADMAP P0.
Hash sha256 pakietu + chain-of-custody. Podpis PAdES/TSA — ROADMAP.
Append-only audit-log dostępny dla roli auditor. LIVE
Przykłady i seedy są syntetyczne. Brak danych osobowych klientów w środowisku demo.
Pełny rejestr z ryzykiem, mitigacją i priorytetem → /known-limitations.
Powiązane: model bezpieczeństwa i zagrożeń → /security-architecture · specyfikacja endpointów → /api-docs · rejestr ograniczeń → /known-limitations.