Czym jest tryb mTLS dla konektorów w ipIII?

To specyfikacja dodatkowego, opcjonalnego trybu transportowego: wzajemne uwierzytelnianie TLS (certyfikat klienta obok certyfikatu serwera) dla ruchu konektorów miedzy ipIII a systemami klienta (SIEM, ticketing, CI/CD). Dziś jest to plan (ROADMAP), nie dzialajaca funkcja.

Czy mTLS dziala dzis w produkcji ipIII?

Nie. Dzis warstwa transportowa uzywa standardowego TLS jednostronnego (szyfrowanie i integralnosc danych) oraz uwierzytelniania konektora tokenem bearer, Basic auth lub podpisem HMAC. Zaden fragment kodu nie wymaga ani nie waliduje dzis certyfikatu klienckiego.

Co stanie sie z klientem bez certyfikatu, gdy tryb mTLS bedzie wlaczony (on)?

Zgodnie z docelowym projektem, klient bez waznego certyfikatu, z certyfikatem wygaslym, nie zaufanym do skonfigurowanego CA lub odwolanym zostanie odrzucony na etapie transportu, przed przetworzeniem zadania na poziomie aplikacji. To opis zachowania docelowego (ROADMAP), egzekwowanego dopiero po przejsciu przez tryby off i shadow oraz jawnej decyzji ACK-gate.

Czy mTLS zastapuje kontrole dostepu na poziomie aplikacji albo stanowi certyfikacje zgodnosci?

Nie. mTLS uwierzytelnia strone transportu (ktory system sie laczy), nie uzytkownika ani akcje - kontrola rol, zakres tenanta i audyt pozostaja osobnym zadaniem. Sam w sobie nie stanowi zadnej certyfikacji regulacyjnej ani gwarancji bezpieczenstwa - to kontrola techniczna wspierajaca wlasny pakiet dowodowy klienta, ktora zawsze wymaga niezaleznego przegladu bezpieczenstwa przed wlaczeniem na produkcji.

k0nsult.cloud / ai-truth / ipIII / orchestrator / mtls

mTLS na bramie konektorów — specyfikacja transportu (ROADMAP)

Ta strona opisuje docelowy tryb wzajemnego uwierzytelniania TLS (mTLS) dla ruchu konektorów ipIII — profil bank/partner, klient bez ważnego certyfikatu odrzucony na styku transportu. To jest specyfikacja do przeglądu bezpieczeństwa i planowania, nie ogłoszenie wdrożonej funkcji. Doktryna claim ≤ proof: dziś działa jednostronny TLS + tokeny/HMAC (LIVE); mTLS jest ROADMAP.

Architektura bezpieczeństwa Enterprise Identity Connectors Znane ograniczenia Status matrix mTLS ← ipIII hub

Po co ta strona. Zespół bezpieczeństwa banku lub partnera regulowanego pyta wprost: „czy wasze API wymaga certyfikatu klienckiego na styku integracji?". Odpowiadamy uczciwie: nie, nie dziś. Poniżej opisujemy dokładnie, co działa teraz (LIVE) i co jest udokumentowanym planem bez daty dostawy (ROADMAP) — bez udawania, że funkcja już istnieje.

Dziś: TLS jednostronny hostingu + tokeny/HMAC. mTLS konektorów: plan, nie funkcja.

Wymiana pakietów dowodowych i ticketów remediacji z systemami po stronie klienta (ticketing, SIEM, CI/CD, DefectDojo) działa dziś przez standardowe HTTPS z uwierzytelnianiem po stronie klienta na poziomie tokena (bearer/basic) lub podpisu HMAC — patrz Connectors. Serwer nie wymaga dziś certyfikatu klienckiego od żadnego wywołującego. Dla klientów enterprise, których polityka bezpieczeństwa sieci wymaga wzajemnego uwierzytelniania certyfikatami (typowe w sektorze regulowanym), ta specyfikacja opisuje opcjonalny tryb transportowy dodatkowego hardeningu — mTLS connector mode.

OŚ DOJRZAŁOŚCI TRANSPORTU: TLS jednostronny + token/HMAC (dziś)→shadow mTLS (walidacja bez odrzucania)→on — twarde egzekwowanie→rotacja + odwołanie z dowodem

Stan dziś vs cel (target design)

Kolumna Status: LIVE = mechanizm działa dziś w routes/ip3-transport.js · ROADMAP = opisany w spec, brak implementacji w repo. Data weryfikacji: 2026-07-05.

Warstwa	Mechanizm	Status	Uwaga
Transport	Standardowe HTTPS (TLS 1.2+), walidacja certyfikatu serwera po stronie klienta.	LIVE	Chroni poufność i integralność danych w tranzycie. Nie uwierzytelnia klienta — to zadanie warstwy tokenowej poniżej.
Uwierzytelnianie konektora	Bearer token (GitHub), Basic + token API (Jira), opcjonalny podpis HMAC (`X-IP3-Signature`, generyczny webhook).	LIVE	Wraz z bramką potrójną (intencja `?send=true` + flaga środowiskowa + obecność sekretu) — bez tego egzekwowania egress nie zachodzi.
Certyfikat klienta na bramie API	Walidacja łańcucha zaufania do skonfigurowanego CA, ważności, statusu odwołania (CRL/OCSP), opcjonalny allow-list SAN.	ROADMAP	Brak w kodzie dziś. Cel: klient bez certyfikatu lub z certyfikatem nieważnym/odwołanym jest odrzucany na etapie handshake TLS lub bezpośrednio po nim, przed przetworzeniem żądania na poziomie aplikacji.
Profil bank/partner	Tryb mTLS włączany per tenant, per konektor — nie jako globalny przełącznik.	ROADMAP	Tenant, który nie włączył trybu mTLS, dalej korzysta z dzisiejszego modelu token/HMAC — istniejące konektory nie są dotknięte do czasu jawnej migracji.
Rotacja i odwołanie certyfikatu	Okno ważności (parametr polityki, nie sztywna wartość), okres nakładki przy rotacji, natychmiastowe odrzucenie po odwołaniu (CRL/OCSP lub deny-list po numerze seryjnym).	ROADMAP	Docelowo alert przy zbliżającej się dacie wygaśnięcia certyfikatu, widoczny na istniejących stronach statusu — bez konieczności pełnego redeployu przy odwołaniu.

Rejestr odrzucenia klienta bez certyfikatu (target)

Zgodnie ze specyfikacją, po włączeniu trybu on dla danego tenanta/konektora: klient bez certyfikatu, z certyfikatem wygasłym, niepodpisanym przez skonfigurowane CA lub odwołanym musi zostać odrzucony — bez awaryjnego powrotu do samego uwierzytelniania tokenem. Odrzucone połączenia są logowane (podmiot certyfikatu, powód, znacznik czasu, źródło) do istniejącego rejestru dowodowo-audytowego, bez zapisywania materiału klucza prywatnego ani pełnej treści PEM w logu domyślnie. To jest opis docelowego zachowania — nie ma dziś w repozytorium kodu, który to egzekwuje.

Bramka wdrożenia (rollout gate) — shadow/on/off

Wzorzec spójny z już istniejącym w kodzie podejściem dla OIDC (routes/ip3-oidc.js) i bramki potrójnej dla transportu — nie nowa filozofia aktywacji.

off domyślne

Funkcja nie istnieje dla tenanta. Brak zmiany zachowania.

shadow walidacja

Certyfikaty klienckie są walidowane i wynik logowany (zaakceptowano/odrzucono + powód), bez faktycznego odrzucania. Cel: sprawdzić paczkę CA i proces rotacji na realnym ruchu klienta, nie narażając produkcji na lockout.

on egzekwowanie

Twarde egzekwowanie — klienci niespełniający warunków są odrzucani. Przejście shadow→on wymaga jawnej decyzji operator/klient (ACK-gate), analogicznie do istniejącej bramki dla IP3_OIDC, IP3_RLS, IP3_TENANT_SCOPE.

Dlaczego ACK-gate

Źle skonfigurowana paczka CA lub luka w rotacji, wymuszona bez okresu shadow, ryzykuje zablokowanie legalnego konektora klienta — to realne ryzyko dostępności, nie formalność.

Powierzchnia konfiguracji (nazwy proponowane, target)

Zmienna (proponowana)	Cel
`IP3_MTLS_CONNECTOR`	`off` (domyślnie) / `shadow` / `on` — wzorzec identyczny z OIDC.
`IP3_MTLS_CA_BUNDLE`	ścieżka/referencja do skonfigurowanej paczki CA per tenant.
`IP3_MTLS_CRL_OR_OCSP`	konfiguracja mechanizmu/endpointu sprawdzania odwołania.
`IP3_MTLS_CERT_ALLOWLIST`	opcjonalna lista dopuszczonych podmiotów/SAN per konektor.

Co mTLS chroni, a czego nie (uczciwie)

Chroni (target, po włączeniu)

Atakujący z ważnym tokenem/bearer (np. po wycieku, phishingu, błędzie konfiguracji sekretu), ale bez odpowiadającego certyfikatu klienckiego/klucza prywatnego, nie uwierzytelni się jako legalny konektor. Zmniejsza skutek samego wycieku tokena, wymagając drugiego, trudniejszego do wyeksfiltrowania poświadczenia.

NIE chroni przed (explicite, bez overclaimu)

Kompromitacją punktu przechowującego sam klucz prywatny. Błędami autoryzacji na poziomie aplikacji — mTLS uwierzytelnia stronę transportu, nie użytkownika/akcję; kontrola ról, zakresu tenanta i audyt pozostają osobnym zadaniem. Nie zastępuje pracy nad izolacją tenanta (model tenant/org/project). Sam w sobie nie stanowi żadnej konkretnej certyfikacji regulacyjnej — to kontrola techniczna wspierająca własny pakiet dowodowy klienta, nie zastępująca go.

Uczciwość trybów wdrożenia

Tryb wdrożenia	Znaczenie mTLS connector mode
SaaS (UE), multi-tenant — dziś LIVE	Standardowy TLS dla całego ruchu; uwierzytelnianie konektora token/HMAC jak wyżej. mTLS connector mode nie jest dostępny w tym trybie dziś.
Private tenant / VPC ROADMAP	Tryb projektowany głównie dla tego kształtu wdrożenia — dedykowana granica tenanta czyni konfigurację CA per tenant praktyczną.
On-prem / u klienta ROADMAP	Najbardziej naturalne dopasowanie do CA wystawianego przez klienta i w pełni kontrolowanej przez klienta rotacji.

Żaden tryb wdrożenia dostępny dziś nie zapewnia egzekwowania mTLS na konektorach. Rozmowa procurement odwołująca się do mTLS powinna traktować to jako pozycję roadmapy z projektem (ta specyfikacja), bez ustalonej daty dostawy.

Kryteria akceptacji (target, na moment startu implementacji)

Tryb shadow działający na realnym konektorze klienta przez zdefiniowany okres obserwacji, zero fałszywych odrzuceń w logu.
Rotacja certyfikatu przetestowana end-to-end (stary wygasa, nowy akceptowany, okno nakładki obserwowane) bez przerwy w usłudze.
Odwołanie przetestowane: certyfikat celowo odwołany/deny-listowany jest odrzucony w skonfigurowanym oknie sprawdzania.
Ścieżka odrzucenia logowana do istniejącego rejestru audytowo-dowodowego, z testowalnym przypadkiem negatywnym.
Niezależny przegląd bezpieczeństwa zatwierdzony przed przejściem tenanta z shadow do on na produkcji.

Żadna z powyższych pozycji nie istnieje jeszcze. Ta lista definiuje „gotowe", nie stan bieżący.

Wymogi udziału człowieka (nie automatyzować)

Ta specyfikacja to wsparcie decyzji i artefakt planowania technicznego — nie porada prawna i nie przegląd bezpieczeństwa sam w sobie.

Przegląd architektury bezpieczeństwa — model zaufania CA, przechowywanie kluczy i mechanizm odwołania dla konkretnej infrastruktury PKI klienta. człowiek: security engineer

Akceptacja zespołu sieci/PKI klienta — potwierdzenie zgodności procesu wystawiania/rotacji certyfikatów z projektem docelowym. człowiek: zespół sieci/PKI klienta

Przegląd prawny/DPO, jeśli mTLS jest wymieniany w DPA/MSA/aneksie bezpieczeństwa — wyłącznie przez radcę prawnego, nie automatycznie z tej specyfikacji. człowiek: prawnik/DPO

Przegląd konfiguracji faktycznej implementacji przed uruchomieniem produkcyjnym — błędna konfiguracja TLS/mTLS to znana klasa błędów wysokiego wpływu. człowiek: zespół bezpieczeństwa / niezależny recenzent

Otwarte zależności

Zarządzanie sekretami/KMS — przechowywanie własnego klucza wyjściowego mTLS ipIII to osobny, otwarty element; dziś brak modułu vault/KMS w repozytorium.
Kompletność izolacji tenanta — pełny sens dopiero przy w pełni izolowanym modelu danych tenant/org.
Wybór infrastruktury odwołania (CRL vs OCSP vs krótkotrwałe certyfikaty) — jeszcze nierozstrzygnięty.

Skrót statusów

Mechanizmy LIVE dziś

TLS jednostronny hostingu · token/HMAC konektora

Elementy ROADMAP

certyfikat klienta · profil bank/partner · rotacja · odwołanie

Tenantów z mTLS on

dziś — jawnie, bez ukrywania

Priorytet domknięcia

wg known-limitations

Czego ta strona NIE oznacza

To nie jest ogłoszenie wdrożonej funkcji. Żaden fragment kodu w repozytorium nie waliduje ani nie egzekwuje dziś certyfikatu klienckiego. Wszystko powyżej, co brzmi jak wymóg („MUST", „klient bez certyfikatu jest odrzucany"), opisuje docelowe zachowanie funkcji z roadmapy, nie dzisiejsze zachowanie produkcyjne.

mTLS nie zastępuje kontroli dostępu ani segmentacji sieci klienta. To uzupełniająca kontrola transportowa — uwierzytelnia, który system prezentuje dowód lub odbiera ticket remediacji; nie zastępuje własnej segmentacji, WAF ani monitoringu SOC po stronie klienta.

Granica i zakres. Ta strona to szkielet techniczny i deklaracja planu, nie audyt bezpieczeństwa ani porada prawna. Ocena wymogów regulacyjnych (np. w kontekście DORA/NIS2) dotycząca kontroli transportowych wymaga odrębnej weryfikacji przez dział zgodności, audytora lub prawnika po stronie odbiorcy — ipIII dostarcza wsparcie decyzji (decision-support), nie zastępuje tej oceny.

Powiązane: architektura bezpieczeństwa (kontekst spec) → /security-architecture · tożsamość enterprise (OIDC/SSO, osobny tor) → /auth-enterprise · dzisiejsze konektory i ich uwierzytelnianie → /connectors · pełny rejestr znanych ograniczeń → /known-limitations.