K0NSULT // ai-truth/ipIII
k0nsult.cloud / ai-truth / ipIII / orchestrator / security-architecture

Architektura bezpieczeństwa ipIII — specyfikacja warstw

Szkielet warstwowy: gateway → auth → transport → secrets → audit → izolacja. Dla każdej warstwy podajemy uczciwie stan dzisiejszy (co działa) i cel (co jest ROADMAP). To specyfikacja, nie deklaracja gotowości — jeśli warstwa nie jest oznaczona LIVE, traktuj ją jako ROADMAP. Doktryna: claim ≤ proof.

Po co ta strona. Audytor, bank SIFI czy regulator powinien móc przeczytać architekturę bezpieczeństwa bez zgadywania, co jest zbudowane, a co dopiero zaplanowane. Każda z sześciu warstw ma dwa jawne stany: LIVE (dowód: kod + test + endpoint) oraz ROADMAP (cel docelowy). Nie przedstawiamy szkicu jako wdrożenia. Zgodnie z doktryną claim ≤ proof — deklarujemy dokładnie tyle, ile potrafimy pokazać.
6 warstw. Każda: stan LIVE vs cel ROADMAP — jawnie.

ipIII jest dziś dowodliwym MVP warstwy evidence z uwierzytelnianiem JWT+RBAC i audytem na żywej PostgreSQL. Warstwy tożsamości federacyjnej (OIDC), transportu wzajemnie uwierzytelnianego (mTLS), sejfu sekretów (vault), niemodyfikowalnego audytu i wielodostępności (multi-tenant RLS) są zaprojektowane jako spec, ale nie są jeszcze wdrożone — dlatego oznaczamy je ROADMAP.

OŚ DOJRZAŁOŚCI: MVP evidence + JWT/RBAC (dziś)OIDC + mTLSvault + immutable auditmulti-tenant RLSenterprise-ready (cel)

Diagram warstw (tekstowy)

Ruch wchodzi od góry. Znaczniki: LIVE = zbudowane i testowane · ROADMAP = specyfikacja, jeszcze nie wdrożone.

   klient / konektor / przeglądarka
              │
              ▼
  ┌────────────────────────────────────────────┐
  │  [1] GATEWAY            rate-limit, CORS,    │
  │      warstwa brzegowa   nagłówki bezp.       │  TLS (host) .......... LIVE
  │                         WAF / API-GW ........ ROADMAP
  ├────────────────────────────────────────────┤
  │  [2] AUTH               JWT + RBAC .......... LIVE
  │      tożsamość i role   OIDC / JWKS / SSO ... ROADMAP
  ├────────────────────────────────────────────┤
  │  [3] TRANSPORT          TLS jednostronny .... LIVE
  │      kanał usług        mTLS wzajemny ....... ROADMAP
  ├────────────────────────────────────────────┤
  │  [4] SECRETS            fly secrets ......... LIVE
  │      zarządzanie kluczy  vault + rotacja .... ROADMAP
  ├────────────────────────────────────────────┤
  │  [5] AUDIT              audit-log w DB ...... LIVE
  │      ślad zdarzeń       append-only immutable ROADMAP
  ├────────────────────────────────────────────┤
  │  [6] IZOLACJA           single-org .......... LIVE
  │      rozdział danych    multi-tenant RLS .... ROADMAP
  └────────────────────────────────────────────┘
              │
              ▼
     PostgreSQL (evidence + audit)
  

Warstwy — stan vs cel

Kolumna Priorytet domknięcia luki: P0 blokuje wdrożenie enterprise · P1 wymagane dla banku/partnera, nie blokuje PoC/pilota · P2 hardening. Data weryfikacji: 2026-07-05.

WarstwaStan dziś (LIVE)Cel (ROADMAP)Po co / ryzyko lukiPriorytet
[1] Gateway TLS na warstwie hostingu, rate-limit, CORS, nagłówki bezpieczeństwa. LIVE WAF / dedykowana brama API, filtrowanie na brzegu, centralne polityki. ROADMAP Bez bramy filtrującej brzeg opiera się na regułach aplikacji; przy skali potrzebna dedykowana warstwa. P2
[2] Auth JWT wystawiany lokalnie + RBAC (role/uprawnienia egzekwowane w API). LIVE OIDC (authorization-code), walidacja JWKS z zewnętrznego IdP (np. Keycloak), SSO, provisioning/deprovisioning. ROADMAP enterprise gap — brak federacji tożsamości i centralnego zarządzania kontami; szczegóły → /auth-enterprise. P0
[3] Transport TLS jednostronny na styku hostingu. LIVE mTLS (wzajemne uwierzytelnianie TLS) na bramie API + certyfikaty klienckie konektorów; opcjonalnie spięcie z PKI instytucji. ROADMAP bank gap — bank SIFI wymaga wzajemnego TLS na styku integracji; dziś tylko jednostronny. P0
[4] Secrets Sekrety jako fly secrets (zmienne środowiskowe poza repo). LIVE Dedykowany sejf (vault) z wersjonowaniem, kontrolą dostępu i rotacją kluczy. ROADMAP hardening gap — brak automatycznej rotacji i granularnej polityki dostępu do sekretów. P1
[5] Audit Ślad zdarzeń (audit-log) zapisywany w PostgreSQL, powiązany z akcjami użytkownika/roli. LIVE Dziennik append-only / niemodyfikowalny (immutable), docelowo znacznik czasu i łańcuch integralności. ROADMAP formal evidence gap — log w DB jest odczytywalny i spójny, ale nie jest technicznie niemodyfikowalny. P1
[6] Izolacja Jedna organizacja (single-org); dane nie są współdzielone między klientami. LIVE Multi-tenant z Row-Level Security (RLS) w PostgreSQL, tenant scoping w każdym zapytaniu, rozdział audit-logów per tenant. ROADMAP bank/partner gap — brak bezpiecznej wielodostępności; model → /tenant-model. P1

Skrót statusu warstw

6/6
warstw ma stan LIVE
gateway·auth·transport·secrets·audit·izolacja — podstawa zbudowana
2
P0 — blokują enterprise
Auth (OIDC/JWKS) · Transport (mTLS)
3
P1 — dla banku/partnera
Secrets vault · Immutable audit · Multi-tenant RLS
6/6
warstw ma cel ROADMAP
jawnie oznaczone, zero ukrytych deklaracji

AI-security / arena — zakres

Wyłącznie defensywnie. Ta architektura opisuje obronę i zgodność (GRC/blue). Elementy związane z testowaniem odporności AI działają na danych syntetycznych, wyłącznie po pisemnych Rules of Engagement, jako PoC/MVP. Strona nie zawiera payloadów ani instrukcji ataku — to szkielet decision-support po stronie obrony.

Czego ta strona NIE oznacza

To nie jest deklaracja gotowości. Stan LIVE dotyczy fundamentu (JWT+RBAC, audit-log w DB, single-org, TLS hostingu, fly secrets). Warstwy OIDC, mTLS, vault, immutable audit i multi-tenant RLS to ROADMAP — specyfikacja z zaplanowaną ścieżką domknięcia, nie funkcje wdrożone. Pełny rejestr granic → /known-limitations; macierz dojrzałości → /enterprise-readiness.
„100%" u nas znaczy pokrycie dowodowe, nie nieprzenikalność. Deklarujemy dokładnie tyle, ile potrafimy pokazać kodem, testem i endpointem. Skoro nie mamy dowodu na mTLS, vault czy RLS, mówimy o nich jako ROADMAP, a nie jako o gotowych warstwach.
Granica etyczna i prawna. ipIII jest narzędziem obrony i zgodności. Nie wykonuje nieautoryzowanych skanów ani hack-back. Mapowania obowiązków i architektura bezpieczeństwa to wsparcie decyzji (decision-support), nie porada prawna ani deklaracja bezpieczeństwa. Działania o charakterze testu bezpieczeństwa wyłącznie w granicach pisemnych Rules of Engagement.

Powiązane: macierz dojrzałości → /enterprise-readiness · rejestr granic → /known-limitations · auth federacyjny → /auth-enterprise · model wielodostępny → /tenant-model.