Jedno miejsce, w którym bank, instytucja finansowa lub partner PoC znajdzie wszystkie fakty potrzebne przed rozpoczęciem współpracy: co system robi z danymi, gdzie je trzyma, kto ma dostęp, jak zgłosić podatność i jakie są granice tego pilotażu. Doktryna portalu: claim ≤ proof — każda deklaracja niżej ma pokrycie w konfiguracji, dokumencie lub endpointcie.
Zaufanie budujemy dowodem, nie obietnicą.
Ten pilotaż (PoC) działa na danych syntetycznych lub zanonimizowanych, w regionie UE, z kontrolowanym dostępem na zaproszenie. Nie deklarujemy „nieprzenikalności" — deklarujemy pokrycie dowodowe, jawny rejestr ograniczeń i otwarty kanał zgłaszania podatności.
ZASADY PoC:
dane syntetyczne→region UE→dostęp na zaproszenie→retencja krótka→disclosure otwarte
Aktualny stan komponentów (LIVE / MVP / ROADMAP), wyniki smoke i integracji oraz zdrowie bazy prezentuje żywa macierz statusów.
Jeśli dowolny komponent jest niedostępny lub w trakcie prac, będzie to widoczne w macierzy statusów — nie w tym akapicie. Trust Center nie duplikuje stanu, tylko do niego linkuje (jedno źródło prawdy).
Pilotaż służy demonstracji zdolności orchestratora (import findings → normalizacja → incydent + evidence → pakiet DORA/TIBER → mapowanie prawne) na bezpiecznych danych.
Reguła danych. Jeśli partner chce przetestować import na własnym raporcie (Burp/ZAP/Nessus/CSV), rekomendujemy uprzednią anonimizację. Trust Center zakłada, że dane wprowadzone do PoC są nieprodukcyjne, chyba że strony ustaliły inaczej DPA/NDA.
Retencja danych
Dane wprowadzone w ramach PoC mają krótki, jawny cykl życia.
- Dane demonstracyjne i artefakty PoC są usuwane po zakończeniu pilotażu lub na żądanie partnera (prawo do usunięcia w każdej chwili).
- Rekordy operacyjne (incydenty, evidence, engagementy) trzymane są w bazie PostgreSQL w regionie UE wyłącznie na czas trwania PoC.
- Kopie robocze, logi importu i pakiety raportowe (PDF/JSON) podlegają tej samej retencji — usunięcie obejmuje artefakty pochodne.
- Żądanie usunięcia realizujemy niezwłocznie; potwierdzenie wysyłamy kanałem kontaktowym (poniżej).
Region infrastruktury
System działa na infrastrukturze Fly.io w regionie Unii Europejskiej. Baza danych (PostgreSQL) oraz warstwa aplikacyjna są zlokalizowane w UE.
- Warstwa aplikacyjna: Fly.io, region UE.
- Baza danych: PostgreSQL zarządzana, region UE.
- Domena i publikacja: k0nsult.cloud (DNS operatora). Ruch HTTPS.
Region infrastruktury jest istotny dla RODO (transfer danych) i DORA (lokalizacja krytycznych dostawców). Szczegóły podregionu i providerów podrzędnych udostępniamy w DPA na żądanie.
Kto ma dostęp
Dostęp do środowiska PoC jest kontrolowany i przyznawany na zaproszenie.
- Konta tworzone są indywidualnie dla wskazanych osób po stronie partnera i zespołu K0NSULT.
- Warstwa produkcyjna (
/api/ip3/v1) wymaga uwierzytelnienia (JWT) i autoryzacji ról (RBAC). Ścieżki zapisu/mutacji są chronione; anonimowy dostęp = 401.
- Każdy zapis jest rejestrowany w audit logu (kto / co / kiedy) w bazie.
- Brak samodzielnej rejestracji — nie ma otwartego sign-upu do środowiska PoC.
Polityka kont demonstracyjnych
Konta demo służą wyłącznie do pokazania ścieżek odczytu i zapisu w trakcie PoC.
- Poświadczenia kont demo są rotowane po zakończeniu pilotażu (unieważniane i wydawane na nowo dla kolejnych zaangażowań).
- Hasła i tokeny przekazujemy kanałem osobistym (bezpieczny kanał uzgodniony z partnerem), nigdy publicznie ani w tej stronie.
- Konta demo mają zawężone role — nie dają dostępu do danych innych organizacji.
- Po PoC konta demo są dezaktywowane; ponowny dostęp = nowe zaproszenie.
Rate limit + audit log
Warstwa v1 chroni integralność i dostępność środowiska PoC.
- Rate limiting na endpointach API v1 (ochrona przed nadużyciem i przeciążeniem).
- Audit log w bazie — każda operacja zapisu jest utrwalana z tożsamością aktora, typem akcji i znacznikiem czasu.
- Ślad audytowy zasila także pakiety dowodowe (evidence-package / report-package z
package_sha256 i chain-of-custody).
Szczegóły limitów i retencji logów audytowych udostępniamy w ramach DPA. Stan implementacji: patrz status-matrix i roadmap-dev.
Responsible disclosure
Prowadzimy otwarty program zgłaszania podatności (VDP). Jeśli znajdziesz problem bezpieczeństwa — zgłoś go, nie publikuj.
- Zgłoszenia w dobrej wierze przyjmujemy i nie podejmujemy działań prawnych wobec badaczy działających w zakresie i zgodnie z zasadami VDP.
- Prosimy o niepublikowanie szczegółów przed skoordynowaniem naprawy.
- Zakres i wyłączenia opisuje strona disclosure oraz
security.txt.
Brak testów ofensywnych bez RoE
Orchestrator jest narzędziem obrony i zgodności (GRC / blue-team). Nie wykonuje nieautoryzowanych skanów, exploitacji ani hack-back.
- Jakiekolwiek działania o charakterze testu bezpieczeństwa (BAS, red-team, pentest infrastruktury partnera) — wyłącznie w granicach pisemnych Rules of Engagement (RoE).
- Zero payloadów, zero technik ofensywnych po stronie systemu. To narzędzie GRC, nie zestaw ataku.
- W kontekście ćwiczenia purple-team RoE definiuje zakres, okna czasowe, crown-jewels i kanały eskalacji przed jakimkolwiek działaniem.
DPA / RODO art. 28
Jeżeli PoC obejmie przetwarzanie danych osobowych, zawieramy umowę powierzenia przetwarzania (DPA) zgodnie z art. 28 RODO przed rozpoczęciem takiego przetwarzania.
- Role: partner jako administrator, K0NSULT jako podmiot przetwarzający (w zakresie PoC).
- Zakres, cel, czas, kategorie danych i osób oraz obowiązki podmiotu przetwarzającego określa DPA.
- Subprocessorzy (np. dostawca infrastruktury UE) wskazani w załączniku do DPA.
- Prawa osób, których dane dotyczą, oraz procedury naruszeń — zgodnie z RODO i (dla instytucji finansowych) z mapowaniem na DORA/NIS2 (patrz Legal Trigger Engine na roadmap-dev).
NDA
Współpracę PoC poprzedza umowa o zachowaniu poufności (NDA).
- Obie strony chronią informacje poufne ujawnione w trakcie pilotażu (dane techniczne, wyniki, konfiguracje).
- Nazwa partnera (np. banku SIFI) nie jest ujawniana publicznie przed uzgodnieniem i podpisaniem RoE/NDA.
- Materiały PoC nie są wykorzystywane do celów marketingowych bez zgody.
Znane ograniczenia
Prowadzimy jawny rejestr tego, czego system dziś nie robi lub robi w wersji MVP. Uczciwość co do granic jest częścią zaufania.
- Podpis pakietów: dziś sha256 (integralność); PAdES/PQC = ROADMAP.
- Auth: JWT lokalny + RBAC LIVE; OIDC realny IdP / mTLS = ROADMAP.
- Izolacja multi-tenant (RLS PostgreSQL) = ROADMAP.
- Enrichment CVE i MITRE ATT&CK: offline/biblioteka LIVE; online lookup (NVD/CISA) i STIX/TAXII = ROADMAP.
To skrót — kanon ograniczeń trzyma strona known-limitations, a stan implementacji: status-matrix.
Roadmap security hardening
Kolejność wzmacniania bezpieczeństwa środowiska po fazie PoC. Elementy poniżej mają status ROADMAP do czasu dostarczenia z dowodem (kod + test + endpoint).
| Obszar | Dziś | Cel hardeningu | Status |
|---|
| Uwierzytelnianie / tożsamość | JWT lokalny + RBAC | OIDC (realny IdP, JWKS) + mTLS | ROADMAP |
| Podpis pakietów dowodowych | sha256 (integralność) | PAdES + timestamp TSA (opcjonalnie PQC) | ROADMAP |
| Izolacja tenantów | jedna org (PoC) | RLS PostgreSQL + tenant scoping | ROADMAP |
| Audit / rate-limit | audit log + rate-limit v1 (DB) | rozszerzony ślad + limity per-tenant | MVP → hardening |
Pełna sekwencja sprintów i kryteria akceptacji: roadmap-dev.
Kontakt
Zasada nadrzędna. Trust Center nie duplikuje stanu systemu — linkuje do jednego źródła prawdy (
status-matrix,
known-limitations,
roadmap-dev). Każda deklaracja zaufania niżej jest weryfikowalna w konfiguracji, dokumencie umownym (DPA/NDA/RoE) lub endpointcie. Doktryna:
claim ≤ proof.
Zastrzeżenie. Niniejsza strona ma charakter informacyjny i nie stanowi opinii prawnej ani certyfikacji zgodności. Odniesienia do RODO, DORA, NIS2 czy AI Act są orientacyjne (decision-support) i nie zastępują analizy prawnej ani audytu zgodności. Wiążące pozostają podpisane dokumenty (DPA, NDA, RoE). Deklaracja „region UE", „retencja" i „kontrola dostępu" opisuje konfigurację środowiska PoC; szczegóły techniczne i lista subprocessorów — w DPA na żądanie.