Szkielet trybu, w którym jeden operator MSSP (dostawca usług bezpieczeństwa zarządzanego) obsługuje wielu klientów końcowych z jednego panelu ipIII — z rozdzielonymi danymi, osobnym Board Packiem per klient i zbiorczym rozliczeniem. Status całej strony: ROADMAP. Ta funkcja wprost zależy od izolacji tenantowej (F3): warstwa 1 (kolumny/scoping) jest obecna w repozytorium, ale nie jest podłączona do ścieżki zapytań — nie działa, więc nie nazywamy jej LIVE; warstwa 2 (PostgreSQL Row-Level Security) jest dopiero w planie. Dopóki F3 nie jest domknięte, MSSP Mode nie może bezpiecznie wystartować.
MSSP Mode ma sens tylko wtedy, gdy dane klienta A nigdy nie są widoczne dla klienta B na tej samej instancji.
Ten warunek nie jest dziś spełniony: kod scopingu tenantowego (kolumna tenant_id, filtrowanie w
query) jest częściowo obecny w repozytorium z prac nad F3, ale nie jest podłączony do żadnej ścieżki
produkcyjnej — to martwy kod (dead code), nie działająca funkcja. PostgreSQL Row-Level Security, testy
izolacji IDOR/BOLA i audit per tenant są dopiero specyfikacją na /tenant-model.
MSSP Mode dziedziczy ten sam priorytet i tę samą blokadę.
Bez działającej izolacji tenantowej panel MSSP byłby ryzykiem, nie funkcją — klient A mógłby teoretycznie zobaczyć dane klienta B. Dlatego kolejność jest twarda: najpierw izolacja, potem panel na niej zbudowany.
| Zależność | Co to jest | Stan dziś | Status |
|---|---|---|---|
| F3 warstwa 1 — scoping | Kolumna tenant_id i logika filtrowania zapytań per tenant, opisana w modelu na /tenant-model. |
Fragmenty obecne w repozytorium (z prac przygotowawczych), ale niepodłączone do ścieżki API/DB — nie wykonują się w produkcji. To martwy kod, nie funkcja. | obecny, nieaktywny |
| F3 warstwa 2 — RLS | PostgreSQL Row-Level Security wymuszający separację na poziomie bazy, nawet gdy warstwa aplikacyjna zawiedzie. | Wyłącznie szkic polityki (przykładowy SQL) na /tenant-model. Wymaga migracji schematu i ACK operatora. | ROADMAP P1 |
| Testy izolacji (IDOR/BOLA) | Dowód, że tenant A nie widzi danych tenanta B — nie tylko że widzi swoje. | Zestaw testów opisany jako spec, nie uruchomiony (brak środowiska multi-tenant do testowania). | ROADMAP |
| White Label Board Pack (F13) | Raport per klient z brandingiem MSSP, ale z niezmiennym K0NSULT evidence hash — opisane na /white-label. | Warstwa dowodowa (hash, chain-of-custody, /verify) istnieje w ipIII; sam mechanizm nakładania brandingu — nie. | ROADMAP |
| Billing per-tenant | Zbiorcze i rozdzielne rozliczenie MSSP wobec K0NSULT oraz MSSP wobec swoich klientów końcowych. | Wyłącznie specyfikacja poniżej. Brak licznika zużycia per tenant, brak integracji billingowej. | ROADMAP |
Model warstwowy: operator MSSP zarządza wieloma tenantami-klientami z jednego panelu; każdy klient końcowy widzi wyłącznie własne dane i własny Board Pack. Cały diagram = ROADMAP, ilustracja docelowej struktury.
SPEC / ROADMAP — nie wdrożone MSSP operator (panel zbiorczy) ├─ Tenant: Klient A (scoping: tenant_id + RLS) │ ├─ evidence / incydenty / findings — widoczne TYLKO dla Klienta A i MSSP │ └─ Board Pack (white-label MSSP) — branding MSSP, evidence_hash niezmienny ├─ Tenant: Klient B (scoping: tenant_id + RLS) │ ├─ evidence / incydenty / findings — widoczne TYLKO dla Klienta B i MSSP │ └─ Board Pack (white-label MSSP) └─ Tenant: Klient C ... Panel MSSP: widok zbiorczy (metryki, SLA, kolejka retestów) — bez mieszania danych dowodowych między tenantami. Billing: zużycie liczone per tenant, agregowane do jednej faktury MSSP + rozbicie per klient (spec poniżej).
Poniżej opis zamierzonego modelu rozliczeń MSSP. Warunki, stawki i poziomy ustalane są indywidualnie na piśmie — pełny cennik bazowy na /pricing. Liczby w tabeli to przykład formatu, nie oferta ani cennik obowiązujący.
| Element | Co mierzy (docelowo) | Komu trafia rozliczenie | Status |
|---|---|---|---|
| Licznik per tenant | Zużycie (liczba engagementów, evidence-package, retestów) osobno dla każdego klienta końcowego. | Wejście do faktury zbiorczej MSSP. | ROADMAP |
| Faktura zbiorcza MSSP | Jedna faktura od K0NSULT do operatora MSSP, z rozbiciem per tenant w załączniku. | Operator MSSP. | ROADMAP |
| Rozliczenie MSSP → klient końcowy | To, jak MSSP fakturuje własnego klienta (marża, pakiet usług), pozostaje poza ipIII — narzędzie dostarcza dane zużycia, nie wystawia faktury klienta końcowego. | Operator MSSP (poza zakresem ipIII). | ROADMAP (poza zakresem) |
| Próg alertu / limit tenanta | Opcjonalny limit zużycia per tenant z powiadomieniem przed przekroczeniem. | Operator MSSP (widok panelu). | ROADMAP |
MSSP Mode nie startuje od zera — część fundamentu dowodowego już działa w trybie single-org i zostanie ponownie użyta, gdy izolacja tenantowa będzie gotowa.
Import parserów, evidence-package, chain-of-custody, close-with-evidence — działa dziś w jednym kontekście organizacyjnym.
LIVE MVP (single-org)
Uwierzytelnianie i ślad audytowy istnieją; docelowo audit zostanie rozszerzony o kotwicę tenant_id per zdarzenie.
LIVE MVP / rozszerzenie per tenant ROADMAP
Generowanie raportu istnieje jako element; branding partnera (white-label) to osobna warstwa, opisana na /white-label.
ROADMAP (white-label)
Mapowanie obowiązków (DORA/NIS2/RODO/AI Act) działa dziś dla jednego kontekstu; per-tenant różnicowanie jurysdykcji to rozszerzenie do zaplanowania.
LIVE MVP / per tenant ROADMAP
Powiązane: model tenantowy i RLS → /tenant-model · White Label Board Pack → /white-label · rejestr znanych ograniczeń → /known-limitations · macierz statusów → /status-matrix.