Finding bez kontekstu aktywa jest ślepy: „SQL injection w usłudze X" znaczy co innego dla strony marketingowej, a co innego dla rdzenia płatności. Ta warstwa (F11) mapuje aktywa na krytyczność, usługę biznesową, właściciela, flagę crown-jewel, zależności i blast radius — żeby priorytet remediacji i raport DORA/TIBER wiedziały, czy dana luka dotyka klejnotu koronnego. Dane w tabeli poniżej są syntetyczne (przykład).
Bez rejestru aktywów każdy finding trafia do jednej kolejki i „ważny" miesza się z „kosmetyczny". Crown Jewels Mapping dokłada każdemu aktywu kontekst biznesowy: jak bardzo jest krytyczne, jaką usługę obsługuje, kto za nie odpowiada, czy jest klejnotem koronnym, od czego zależy i jak szeroki jest promień rażenia (blast radius) przy jego kompromitacji. Ten kontekst zmienia sortowanie remediacji i zasila ocenę pokrycia funkcji krytycznych w DORA/TIBER.
Sześć atrybutów, które opisują każde aktywo w rejestrze. To słownik pól, nie zrzut z produkcji.
Krytyczność aktywa w skali C1–C4 (C1 = misja krytyczna, C4 = pomocnicze). Wejście do sortowania findingów.
Usługa biznesowa obsługiwana przez aktywo (np. „Rozliczenia", „Logowanie klienta"). Łączy technikę z funkcją.
Właściciel odpowiedzialny (zespół / rola). Adresat zadania remediacji i punkt kontaktu przy incydencie.
Flaga TAK/NIE: czy kompromitacja zatrzymuje usługę krytyczną lub narusza dane regulowane.
Od czego aktywo zależy (baza, kolejka, IdP, dostawca). Podstawa mapy propagacji ryzyka.
Promień rażenia — ile usług/aktywów upada wraz z tym aktywem. Szacunek zasięgu, nie pomiar.
Ilustracja modelu na fikcyjnej organizacji. Nazwy, właściciele i zależności są wymyślone. Kolumna Crown: ◆ = klejnot koronny.
| Asset ID | Aktywo | Krytyczność | Usługa biznesowa | Właściciel | Crown | Zależności | Blast radius |
|---|---|---|---|---|---|---|---|
AST-001 |
Core Payments API | C1 | Rozliczenia i przelewy | Zespół Płatności | ◆ | AST-004 (DB), AST-006 (IdP), AST-007 (kolejka) | wysoki — 5 usług zależnych |
AST-002 |
Ledger / Księga Główna | C1 | Rachunkowość, rozliczenia | Zespół Fintech-Core | ◆ | AST-004 (DB) | wysoki — dane regulowane |
AST-003 |
Customer Login Gateway | C2 | Logowanie klienta | Zespół IAM | ◆ | AST-006 (IdP) | średni — bramka dostępu |
AST-004 |
Primary PostgreSQL Cluster | C1 | Trwałość danych (współdzielona) | Zespół Platform/DB | ◆ | AST-008 (storage) | wysoki — podpiera AST-001/002 |
AST-005 |
Marketing CMS | C4 | Strona publiczna | Zespół Marketing | — | AST-008 (storage) | niski — izolowany |
AST-006 |
Identity Provider (OIDC) | C1 | Tożsamość i dostęp | Zespół IAM | ◆ | AST-004 (DB) | wysoki — auth wielu usług |
AST-007 |
Message Queue (broker) | C2 | Asynchroniczne przetwarzanie | Zespół Platform | — | AST-008 (storage) | średni — opóźnia płatności |
AST-008 |
Object Storage | C2 | Przechowywanie (współdzielone) | Zespół Platform | — | — | średni — warstwa bazowa |
Legenda krytyczności: C1 misja krytyczna · C2 ważne · C3 standardowe · C4 pomocnicze. Blast radius = szacunek zasięgu na podstawie zadeklarowanych zależności, nie pomiar.
Powiązane: kontekst regulacyjny → /dora-tiber · kolejkowanie napraw → /remediation · metryka pokrycia → /coverage-score · granice systemu → /known-limitations.