Jeden dokument dla zespołu bezpieczeństwa banku, audytora lub partnera integracyjnego: model zagrożeń (STRIDE-lite), macierz kontroli z jawnym stanem LIVE / ROADMAP per kontrola, zasady bezpiecznego przyjmowania danych wejściowych (input-safety), zarządzanie sekretami i polityka ujawniania podatności. ipIII to warstwa dowodowo-regulacyjna między pentest/AppSec/SOC/GRC a zarządem, audytem i regulatorem — nie konkurent skanera, SIEM czy GRC. Doktryna claim ≤ proof: nie deklarujemy kontroli, której nie potrafimy pokazać kodem, testem i endpointem.
ipIII jest dziś dowodliwym MVP warstwy evidence: import ustaleń skanera → incydent → evidence-package → retest → close, z uwierzytelnianiem JWT+RBAC, audytem w PostgreSQL i łańcuchem skrótów (hash-chain) na eksporcie audytu. To NIE jest jeszcze warstwa z federacją tożsamości (OIDC/SSO), wzajemnym TLS (mTLS), formalnym podpisem dowodów (PAdES/TSA) ani bezpieczną wielodostępnością (multi-tenant). Poniżej — dokładnie które kontrole i w jakim stanie.
Model zagrożeń poniżej używa uproszczonej siatki STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege), zastosowanej do aktywów ipIII: rekordów evidence, logu audytu, eksportów board-pack i publicznego API. Dla każdej kategorii podajemy dziś działającą kontrolę pierwszej linii i jej stan. Data weryfikacji: 2026-07-05.
| Kategoria | Scenariusz wobec ipIII | Kontrola pierwszej linii | Status |
|---|---|---|---|
| Spoofing podszycie |
Fałszywa tożsamość klienta API lub konektora ingest. | JWT wystawiany lokalnie + RBAC na endpointach. Federacja z zewnętrznym IdP (OIDC/JWKS) — kod i testy istnieją, nie jest jeszcze podłączona do middleware uwierzytelniania. | LIVE (JWT+RBAC) / ROADMAP (OIDC wpięty) |
| Tampering manipulacja |
Cicha podmiana wpisu w logu audytu lub w eksporcie board-pack. | Hash-chain (prev_sha256 per wpis) + append-only log w PostgreSQL + export_sha256 manifestu. Weryfikator CLI wykrywa pierwszy niezgodny wpis. |
LIVE |
| Repudiation zaprzeczenie |
Użytkownik lub agent zaprzecza wykonaniu akcji (np. zamknięcia incydentu). | Audit-log wiąże każdą akcję z rolą/kontem i znacznikiem czasu serwera. Kwalifikowany znacznik czasu TSA (RFC 3161) niezależny od serwera — nie wdrożony. | LIVE (audit-log) / ROADMAP (TSA) |
| Information Disclosure ujawnienie |
Wyciek danych między klientami przy współdzieleniu instancji; ekspozycja sekretów w repo. | Dziś: single-org (brak współdzielenia instancji między klientami). Multi-tenant z Row-Level Security (RLS, „fala 2") — zaprojektowany, nie wdrożony. Ekspozycja sekretów w repo: wykrywana przez konektor parsujący eksporty Gitleaks/TruffleHog/GitHub secret-scanning (sygnał narzędzia, nie prewencja). | LIVE (single-org, wykrywanie po fakcie) / ROADMAP (multi-tenant RLS w2) |
| Denial of Service odmowa usługi |
Zalanie API żądaniami; nadmiarowo duże payloady na ingest. | Rate-limit na endpointach wrażliwych (np. logowanie/OTP), limit rozmiaru body (1mb), nagłówki bezpieczeństwa (helmet). Dedykowana brama API / WAF na brzegu — nie wdrożona. |
LIVE (rate-limit, limit body) / ROADMAP (WAF/API-GW) |
| Elevation of Privilege eskalacja uprawnień |
Konto o niższej roli wykonuje akcję zastrzeżoną dla roli wyższej (np. close-with-evidence). | RBAC egzekwowany w warstwie API (rola z tokenu JWT sprawdzana per endpoint). Granularna polityka dostępu do sekretów (vault) i rotacja kluczy — nie wdrożone. | LIVE (RBAC) / ROADMAP (vault + rotacja) |
Kolumna Dowód wskazuje, co stoi za deklaracją LIVE (plik/endpoint/test). Kolumna Priorytet: P0 blokuje wdrożenie enterprise · P1 wymagane dla banku/partnera, nie blokuje pilota · P2 hardening.
| Kontrola | Stan | Dowód | Priorytet |
|---|---|---|---|
| IAM / uwierzytelnianie | JWT wystawiany lokalnie. LIVE | Middleware auth() na API; brak federacji z zewnętrznym IdP. | P0 (OIDC do wpięcia) |
| RBAC (autoryzacja) | Role/uprawnienia egzekwowane per endpoint. LIVE | Sprawdzenie roli z tokenu JWT przed akcją (np. close-with-evidence, retest). | — |
| Audit-log | Append-only zapis zdarzeń w PostgreSQL. LIVE | Log wiąże akcję z rolą/kontem i czasem; endpoint /audit/export. |
— |
| Hash-chain | prev_sha256 per wpis + export_sha256 manifestu. LIVE |
Weryfikator CLI przelicza łańcuch i wskazuje pierwszy rozjazd (→ tamper-export). | — |
| OIDC / JWKS (federacja tożsamości) | Moduł walidacji RS256+JWKS ma kod i 10/10 testów jednostkowych, fail-closed przy błędzie walidacji. Nie jest jeszcze podłączony do głównego middleware uwierzytelniania (domyślnie wyłączony flagą). ROADMAP (integracja) | Moduł w repo + zestaw testów jednostkowych; brak wpięcia do produkcyjnej ścieżki auth(). | P0 |
| Transport (mTLS) | TLS jednostronny na warstwie hostingu. Wzajemne uwierzytelnianie TLS (mTLS) między klientem a API — nie wdrożone. ROADMAP | Brak certyfikatów klienckich / bramy mTLS w konfiguracji. | P0 |
| Multi-tenant RLS (fala 2) | Dziś: single-org, brak współdzielenia instancji. Row-Level Security w PostgreSQL + tenant scoping per zapytanie — zaprojektowane, nie zaimplementowane. ROADMAP (w2) | Brak kolumny/polityki tenant_id w warstwie danych. | P1 |
| Signed evidence (PAdES/TSA) | Integralność treści dziś opiera się na sha256, nie na kwalifikowanym podpisie elektronicznym ani niezależnym znaczniku czasu (TSA/RFC 3161). ROADMAP |
Brak modułu podpisu PAdES / integracji TSA (→ signed-evidence). | P1 |
| Gateway / WAF | Rate-limit, CORS z allowlistą origin, nagłówki bezpieczeństwa (helmet, CSP z nonce). Dedykowana brama API / WAF na brzegu — nie wdrożona. ROADMAP | Konfiguracja middleware w aplikacji; brak osobnej warstwy brzegowej. | P2 |
ipIII przyjmuje dane wejściowe z dwóch źródeł: (a) eksporty skanerów/narzędzi (Burp, ZAP, Nessus, SARIF, SBOM, Gitleaks/TruffleHog i inne, w formatach JSON/CSV/XML) oraz (b) treści przetwarzane przez komponenty agentowe (np. dane wejściowe do wzbogacania/analizy). Poniżej stan kontroli na obu ścieżkach.
Konektory (Burp/ZAP/Nessus/SARIF/SBOM/Gitleaks/TruffleHog/GitHub secret-scanning) rozpoznają własny format wejścia i normalizują go do wspólnego modelu findingu. Import ustaleń, nie uruchamianie testu.
Body JSON ograniczone do 1mb na warstwie API. Ochrona przed nadmiarowym payloadem na ingest.
Origin dozwolony tylko z jawnej listy domen; rate-limit na endpointach wrażliwych (np. logowanie).
Parser eksportów skanerów sekretów nigdy nie zapisuje pełnej wartości sekretu — zawsze zredagowany podgląd (maskowanie). Zasada twarda na poziomie kodu.
Parsery odrzucają nierozpoznany format (brak dopasowania struktury), ale brak jeszcze scentralizowanej walidacji schematu (JSON Schema) na bramie API dla wszystkich endpointów ingest. Hardening: ROADMAP.
Koncept warstwy AI-security (Faza 4) opisuje detektor wzorców instrukcji nadpisujących cel agenta i kwarantannę wejścia. Dziś jest to komponent demonstracyjny/symulacyjny, nie jest to jeszcze egzekwowana kontrola produkcyjna na realnym ruchu. Status: ROADMAP (enforcement) — patrz agent-security.
| Element | Stan dziś | Cel | Priorytet |
|---|---|---|---|
| Przechowywanie sekretów aplikacji | Zmienne środowiskowe platformy hostingowej (poza repozytorium kodu). LIVE | Dedykowany sejf (vault) z wersjonowaniem i granularną kontrolą dostępu. | P1 |
| Rotacja kluczy | Ręczna, bez automatycznego harmonogramu. ROADMAP | Automatyczna rotacja + wymuszona wygaśnięcie po okresie. | P1 |
| Wykrywanie sekretów w repo/kodzie | Konektor importuje i normalizuje eksporty Gitleaks / TruffleHog / GitHub secret-scanning jako findingi evidence, z redakcją wartości. LIVE (jako connector, nie skaner) | Natywna integracja z API skanera (bez pośredniego eksportu pliku), weryfikacja aktywności sekretu. | P2 |
Rozróżnienie ważne dla audytora. Konektor sekretów to warstwa wykrywania po fakcie (import ustaleń zewnętrznego skanera) — nie jest to prewencyjny sejf sekretów (vault) i nie zastępuje go. Oba elementy są potrzebne i mają różny status: connector = LIVE, vault = ROADMAP.
Pełna polityka Coordinated Vulnerability Disclosure (CVD, zgodna z ISO/IEC 29147 i 30111) jest opisana osobno i jest LIVE od chwili publikacji: potwierdzenie zgłoszenia ≤72h, safe harbor dla badacza działającego w dobrej wierze, kanał security.txt (RFC 9116), SLA napraw wg severity. Ten dokument nie powiela treści polityki — pełna wersja: /disclosure.
security@k0nsult.cloud + security.txt.
Ochrona prawna dla testów in-scope, nieinwazyjnych, w dobrej wierze.
Uznanie (credit/hall of fame) dostępne dziś; nagrody finansowe w przygotowaniu.
Powiązane: architektura warstw bezpieczeństwa → /security-architecture · rejestr granic → /known-limitations · tamper-evident audit export → /tamper-export · podpis formalny dowodów → /signed-evidence · polityka ujawniania → /disclosure.