Modelowanie zagrożeń i kontrola ryzyka
1) Zasady
1. Architektoniczny pierwszy. Zaczynamy od kontekstów, granic zaufania i przepływów danych.
2. Prawdopodobieństwo ryzyka × wpływ. Mierzymy, nie czujemy.
3. Obrona w głębi. Sterowanie na każdej warstwie: kod → protokół → platforma → ludzie.
4. Zmiana w lewo/prawo. Wczesne bramy w PR + monitorowanie i reakcja w prod.
5. Prywatność przez Design. Symulujemy nie tylko zagrożenia bezpieczeństwa, ale także zagrożenia prywatności.
6. Automatyzuj tam, gdzie to możliwe. Zasady jako kod, automatyczne kontrole, „czerwone linie”.
2) Inwentaryzacja: aktywa, podmioty, granice zaufania
Aktywa: dane (PII, finanse, sekrety), zasoby obliczeniowe, klucze, dostęp, procesy biznesowe.
Tematy: użytkownicy, usługi, administratorzy, partnerzy, dostawcy zewnętrzni.
Granice zaufania: użytkownicy z przodu, przednia brama API, bazy danych/bufory/kolejki, regiony/chmury.
Powierzchnia ataku: punkty wejściowe (API, webhaki, interfejsy użytkowe, sieci, CI/CD, łańcuch dostaw).
mermaid flowchart LR
U[Пользователь] -- TLS --> WAF[WAF/CDN]
WAF --> GW[API Gateway]
GW --> Svc[Service A]
Svc --> DB[(Postgres)]
Svc --> MQ[[Kafka]]
MQ --> SvcB[Service B]
subgraph Trust Boundary
GW; Svc; SvcB end3) Ramy zagrożenia
STRIDE (беровасноста): Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege.
LINDDUN (бриватноста): Linkability, Identifiability, Non-repudiation, Detectability, Disclosure, Unawareness, Non-compliance.
PASTA (proces): od celów biznesowych i podmiotów zagrożenia → szczegóły techniczne → scenariusze testów.
4) Ocena ryzyka
DREAD/OWASP Risk Rating lub CVSS dla słabości.
Prawdopodobieństwo (L): motyw/możliwości napastnika, złożoność, ekspozycja na powierzchnię.
Wpływ (I): finansowanie, ryzyko prawne, przestoje, wycieki PD.
Ryzyko (R = L × I) → Priorytety i tritment: Unikaj/Zmniejszaj/Przenoś/Akceptuj.
Impact
Low Med High Critical
Lik Low L L M H
Med L M H H
High M H High CritRejestr ryzyka (minimalne pola): „identyfikator, scenariusz, STRIDE, aktywa, L, I, R, właściciele, kontrole, status, data zmiany”.
5) Sterowanie: Zapobieganie/wykrywanie/reagowanie
Zapobieganie:- Uwierzytelnianie/autoryzacja: OIDC/OAuth2, PoLP, RBAC/ABAC, krótkoterminowe kredyty serwisowe.
- Sekrety/klucze: KMS/HSM, obrót, nie wiem, szyfrowanie FPE/pole.
- Bezpieczne protokoły: TLS1. 2 +, mTLS, podpisy webhook, idempotence i anty-replay.
- Walidacja/kanalizacja: schematy (JSON Schema/Proto), granice, normalizacja.
- Izolacja: zasady sieci, segmentacja, piaskownica, obszary nazw, grodzie.
- Dzienniki audytu (nierozpoznawalne), korelacja w SIEM, wpisy do anomalii.
- Podpis monitorujący i integralność (eksport hashes artefaktu, zaświadczenie).
- Pszczoły/kanarki do wczesnego wykrywania wycieków kluczy.
- Runbook IR: klasyfikacja, izolacja, odwołanie kluczy, alerty, technicy sądowi.
- Automatyczne kill-switch/feature-flag, „czarne listy” żetonów.
- Powiadomienia użytkowników/regulatorów w przypadku incydentów PD.
6) SDL i bramy bezpieczeństwa
W idei/projekcie: model zagrożenia (RFC/ADR), lista kontrolna sterowania.
W rozwoju: SAST/secret-scan, skany zależności (SCA), polityka zależności.
W zgromadzeniu: SBOM, podpis artefakt, polityka podatności (progi CVSS).
W dziedzinie: OPA/Kyverno - IaC/manifest policy (na przykład kontekst, polityka sieciowa, tajne przekazywanie).
W sprzedaży: IDS/WAF, wykrywanie anomalii, kontrole kanaryjskie, bezpieczeństwo chaosu (na przykład, wygasły certyfikat).
rego package policy.cicd deny[msg] {
some v input.sbom.vulns[v].cvss >= 7.0 msg:= sprintf("High vuln blocked: %s %s", [v.package, v.id])
}
deny[msg] {
input.k8s.pod.spec.securityContext.runAsRoot == true msg:= "RunAsRoot forbidden"
}7) Łańcuch dostaw i zaufanie do artefaktów
SBOM na obraz/pakiet; aktualizacje zależności - poprzez bot/policy.
SLSA/Pochodzenie: powtarzalne zespoły, podpisy, zaświadczenia.
Pojemniki: minimalne obrazy, bez korzeni, możliwości spadania, tylko do odczytu FS.
Skany IaC: Terraform/Helm - zasady szyfrowania, otwarte porty, zasady sieci.
8) Prywatność i zgodność
LINDDUN-mapa zagrożeń dla prywatności, minimalizacja danych, pseudonimizacja/anonimizacja.
Polityka zatrzymywania: TTL/retencja, „prawo do usunięcia”, kontrola dostępu do PD.
Lokalizacja: ograniczenia geograficzne, „dane pozostają w regionie”.
Przejrzystość: rejestry przetwarzania, powiadamiania i zgody.
9) Chmury i obwody
Zero Trust: uwierzytelnianie każdego żądania, mTLS/OPA między usługami.
Segmentacja: VPC/podsieci/SG, prywatne punkty końcowe, kontrola wyjścia.
Klucze/sekrety: KMS, obrót, krótkie kredyty w CI (federacja OIDC).
Rezerwa/DR: zaszyfrowane kopie zapasowe, klucze oddzielnie, próby odzyskiwania.
10) Czerwone/fioletowe zespoły i ćwiczenia stołowe
Czerwony zespół: testowanie hipotez zagrożenia, inżynieria społeczna, eksploatacja łańcucha.
Purple Team: wspólne debugowanie wykrywaczy/wpisów, poprawa IR odtwarzaczy.
Tablop: skrypty "wygasły certyfikat", "wyciekłe klucze", "kompromis łańcucha dostaw. "Rezultatem jest aktualizacja kontroli i mierników.
11) Wskaźniki zapadalności i zarządzanie
Zasięg:% usług z obecnym modelem zagrożenia i DFD.
Bezpieczeństwo MTTD/MTTR, odsetek incydentów złapanych przez kontrole.
Pass-rate polityki w CI, czas na zamknięcie słabości przez krytykę.
Prywatność:% zbiorów danych z TTL/ILM, udział dostępu z uzasadnieniem.
Audyt: prawidłowość przeglądu rejestru ryzyka (kwartalny).
12) Wzory artefaktów
12. 1 Karta ryzyka (przykład)
Risk ID: SEC-API-012
Сценарий: SSRF через изображение в профиле
STRIDE: Tampering/Info Disclosure
Актив: API / файловый прокси
Likelihood: High Impact: High Risk: Critical
Контроли: denylist схем, egress-прокси, URL-fetcher в изолированном рантайме,
DNS-resolv только через прокси, время/размер-лимиты, allowlist.
Владелец: team-accounts Статус: Reduce (в работе)
Дата пересмотра: 2025-12-0112. 2 Lista kontrolna projektu
Aktywa i PII zidentyfikowane? Granice zaufania oznaczone?
Czy DFD/pętle danych są skomponowane i mapowane do ADR?
STRZAŁKA/LINDDUN przemierzała każdą strzałkę DFD?
Wybrany tritment ryzyka; czy właściciele/terminy/DoD?
Zasady jako kod dodany (OPA/Kyverno/CI bramki)?
Plan monitorowania/wpisy i zaktualizowany IR-runbook?
Prywatność: minimalizacja, szyfrowanie, TTL/retencja, lokalizacja?
12. 3 Polityka Webhook (pseudokoda)
python def verify_webhook(req, keys):
ts = int(req.h["X-Timestamp"])
if abs(now_utc()-ts) > 300: return 401 if not hmac_ok(req.body, ts, keys.active_or_prev(), req.h["X-Signature"]):
return 401 if replay_cache.seen(req.h["X-Event-ID"]): return 200
PoLP: в обработчике — только нужные скоупы handle(json.loads(req.body))
replay_cache.mark(req.h["X-Event-ID"])
return 20013) Anty-wzory
Model zagrożenia „na pokaz” bez DFD/niezmiennych.
„Superobwodu” bez uwierzytelniania usług wewnętrznych.
Długotrwałe tajemnice w środowisku/zmiennych repo.
Zasady nie wbudowane jako kod → instrukcja „zapomniane”.
Dzienniki z PD bez kamuflażu i bez retencji/TTL.
Ignorowanie łańcucha dostaw (brak SBOM/podpisów/skanów).
Akceptuj bez właściciela i daty zmiany.
14) Integracja z procesami
RFC/ADR - Każde znaczące rozwiązanie zawiera sekcję Zagrożenia i Kontroli.
Docs-as-Code: model zagrożenia, DFD, rejestr ryzyka w wersji obok kodu.
Bramki uwolnienia: zwolnienie jest zablokowane, gdy zasady SAST/SCA/SBOM nie działają lub brakuje kontroli o dużej powadze.
Szkolenie: playbooks dla programistów (sekrety, podpisy, PoLP), regularny tablet.
Wniosek
Modelowanie zagrożeń to praktyka inżynieryjna zarządzania ryzykiem, a nie dokument jednorazowy. Definiuj aktywa i granice zaufania, stosuj STRIDE/LINDDUN, mierz ryzyko, rejestruj je i wdrażaj kontrole jako kod, wbudowując je w CI/CD i działanie. Dzięki metrykom dojrzałości i regularnej rewizji, zmienisz bezpieczeństwo w przewidywalną zdolność architektoniczną - z zrozumiałą ceną, efektem i szybkością.