Threat Modeling და რისკების კონტროლი

1) პრინციპები

1. Architectural First. ჩვენ ვიწყებთ კონტექსტებს, ნდობის საზღვრებს და მონაცემთა ნაკადს.
2. Risk ≈ Likelihood × Impact. ჩვენ ვზომავთ, მაგრამ არ ვგრძნობთ.
3. Defense in Depth. თითოეულ ფენაზე აკონტროლებდნენ: კოდი - ოქმი - პლატფორმა - ხალხი.
4. Shift Left/Right. ადრეული კარიბჭეები PR + -ში მონიტორინგი და რეაქცია გაყიდვაში.
5. Privacy by Design. ჩვენ მოდელირებთ არა მხოლოდ უსაფრთხოების საფრთხეებს, არამედ კონფიდენციალურობის რისკებს.
6. Automate Where Possible. პოლიტიკოსები, როგორიცაა კოდი, მანქანის მრჩევლები, „წითელი ხაზები“.

2) ინვენტარიზაცია: აქტივები, საგნები, ნდობის საზღვრები

აქტივები: მონაცემები (PII, ფინანსები, საიდუმლოებები), გამოთვლითი რესურსები, გასაღებები, წვდომა, ბიზნეს პროცესები.
საგნები: მომხმარებლები, სერვისები, ადმირალები, პარტნიორები, გარე პროვაიდერები.
ნდობის საზღვრები: მომხმარებლები - ფრონტი, ფრონტი - API კარიბჭე, სერვისები - BD/ქეში/ხაზები, რეგიონები/ღრუბლები.
თავდასხმის ზედაპირი: შესასვლელი წერტილები (API, ვებჰუკი, UI, ქსელები, CI/CD, supply chain).

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 end

3) მუქარის ჩარჩოები

STRIDE (безопасность): Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege.
LINDDUN (приватность): Linkability, Identifiability, Non-repudiation, Detectability, Disclosure, Unawareness, Non-compliance.
PASTA (პროცესი): ბიზნეს მიზნებიდან და მუქარის მსახიობიდან, ტექნიკური დეტალები და ტესტის სცენარები.

4) რისკების შეფასება

DREAD/OWASP Risk Rating ან CVSS დაუცველობებისთვის.
ალბათობა (L): თავდასხმის მოტივი/შესაძლებლობები, სირთულე, ზედაპირის ექსპოზიცია.
გავლენა (I): ფინანსები, იურისკი, მარტივი, PD გაჟონვა.
რისკი (R = L × I) არის პრიორიტეტი და ტირაჟი: Avoid/Reduce/Transfer/Accept.

Impact
Low Med High Critical
Lik Low  L  L  M   H
Med  L  M  H   H
High M  H  High  Crit

რისკების რეესტრი (მინიმალური ველები): 'id, სცენარი, STRIDE, აქტივი, L, I, R, მეპატრონეები, კონტროლირებადი, სტატუსი, გადასინჯვის თარიღი'.

5) კონტროლი: Prevent/Detect/Respond

• ავთენტიფიკაცია/ავტორიზაცია: OIDC/OAuth2, PoLP, RBAC/ABAC, მოკლემეტრაჟიანი მომსახურება.
• საიდუმლოებები/გასაღებები: KMS/HSM, როტაცია, პრინციპი „არ იცოდეთ“, FPE/ველების დაშიფვრა.
• უსაფრთხო ოქმები: TLS1. 2 +, mTLS, ვებჰუკების ხელმოწერები, იდემპოტენტობა და ანტი-რეპლეი.
• სავალდებულო/სანიტარული: სქემები (JSON Schema/Proto), ლიმიტები, ნორმალიზაცია.
• იზოლაცია: ქსელის პოლიტიკა, სეგმენტი, sandbox, namespaces, bulkheads.

• აუდიტის ლოგოები (არარეგულირებული), კორელაცია SIEM- ში, ალერტები ანომალიებში.
• ხელმოწერისა და მთლიანობის მონიტორინგი (მძიმე არტეფაქტების ექსპორტი, ატესტაცია).
• Honeytokens/კანარის გაჟონვის ადრეული დეტალებისთვის.

• Runbook IR: კლასიფიკაცია, იზოლაცია, გასაღებების მიმოხილვა, სიგნალიზაცია, წინსვლა.
• ავტომატური დარტყმა/feature-flag, ნიშნების „შავი სიები“.
• მომხმარებელთა/რეგულატორთა შეტყობინებები PD- სთან ინციდენტებთან დაკავშირებით.

6) SDL და უსაფრთხოების კარიბჭეები

იდეაში/დიზაინში: ასეთი მოდელი (RFC/ADR), კონტროლის შემოწმების სია.
განვითარების პროცესში: SAST/secret-scan, დამოკიდებული სკანერები (SCA), დამოკიდებულების პოლიტიკა.
ასამბლეა: SBOM, არტეფაქტების ხელმოწერა, დაუცველობის პოლიტიკა (CVSS ბარიერები).
უკანა პლანზე: OPA/Kyverno - IaC/მანიფესტის პოლიტიკა (Context, ქსელის პოლიტიკა, საიდუმლოების გაჟონვა).
გაყიდვაში: IDS/WAF, ანომალიური გამოცემა, საკანალიზაციო შემოწმება, ქაოსის უსაფრთხოება (მაგალითად, ამოწურული სერთიფიკატი).

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) Supply Chain და არტეფაქტების ნდობა

SBOM თითოეული გამოსახულების/პაკეტისთვის; დამოკიდებულების განახლებები - ბოტა/პოლიტიკის საშუალებით.
SLSA/Provenance: რეპროდუცირებული შეკრებები, ხელმოწერები, ატესტაციები.
კონტეინერები: მინიმალური სურათები, rootless, drop capabilities, read-only FS.
IaC სკანები: Terraform/Helm - დაშიფვრის, ღია პორტების, ქსელის წესების პოლიტიკა.

8) კონფიდენციალურობა და შესაბამისობა

LINDDUN კონფიდენციალურობის საფრთხეების რუკა, მონაცემთა მინიმიზაცია, ფსევდონიმიზაცია/ანონიმიზაცია.
შენახვის პოლიტიკა: TTL/retenshne, „მოცილების უფლება“, PD- ზე წვდომის აუდიტი.
ლოკალიზაცია: გეო-შეზღუდვები, „მონაცემები რჩება რეგიონში“.
გამჭვირვალობა: დამუშავების, შეტყობინებების და თანხმობის ჟურნალები.

9) ღრუბლები და პერიმეტრები

Zero Trust: თითოეული მოთხოვნის ავთენტიფიკაცია, mTLS/OPA სერვისებს შორის.
სეგმენტი: VPC/ქვესახეები/SG, პირადი ენდოინტები, egress კონტროლი.
გასაღებები/საიდუმლოებები: KMS, rotation, მოკლე კრედიტები CI- ში (OIDC ფედერაცია).
ნაკრძალი/DR: დაშიფრული ზურგჩანთები, გასაღებები ცალკე, აღდგენის რეპეტიციები.

10) წითელი/მეწამული გუნდები და tabletop სავარჯიშოები

Red Team: საფრთხეების ჰიპოთეზის შემოწმება, სოციალური ინჟინერია, ჯაჭვების ექსპლუატაცია.
Purple Team: დეტალების/ალერტების ერთობლივი გამართვა, IR playbook- ის გაუმჯობესება.
Tabletop: სკრიპტები „ამოიწურა სერთიფიკატი“, „გასაღების გაჟონვა“, „supply-chain კომპრომისი“. შედეგი - განახლებული კონტროლი და მეტრიკა.

11) სიმწიფის მეტრიკა და კონტროლი

Coverage: სერვისების%, რომელთაც აქვთ შესაბამისი მოდელი და DFD.
MTTD/MTTR უსაფრთხოება, მაკონტროლებლების მიერ დაჭერილი ინციდენტების წილი.
Policy pass-rate CI- ში, კრიტიკულად დაუცველების დახურვის დრო.
კონფიდენციალურობა: TTL/ILM დანაყოფების%, ხელმისაწვდომობის წილი დასაბუთებით.
აუდიტი: რისკების რეგისტრაციის რეგულირება (კვარტალურად).

12) არტეფაქტების შაბლონები

12. 1 რისკის ბარათი (მაგალითი)

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-01

12. 2 დიზაინის შემოწმების სია

იდენტიფიცირებულია აქტივები და PII? აღინიშნება ნდობის საზღვრები?
DFD/მონაცემთა კონტურები შედგენილია და უკავშირდება ADR- ს?
STRIDE/LINDDUN გადის თითოეულ DFD ისარზე?
არჩეულია რისკის ტრიტინგი; არსებობს მფლობელები/ვადები/DoD?
პოლიტიკოსები, როგორც კოდი დაემატა (OPA/Kyverno/CI კარიბჭე)?
განახლებულია მონიტორინგის გეგმა/ალერტები და IR-runbook?
პირადი: მინიმიზაცია, დაშიფვრა, TTL/ჭრა, ლოკალიზაცია?

12. 3 ვებჰუკების პოლიტიკა (ფსევდო კოდი)

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 200

13) ანტი შაბლონები

ეს მოდელი „შოუსთვის“ DFD/ინვარიანტების გარეშე.
სუპერ პერიმეტრი სერვისის შიდა ავთენტიფიკაციის გარეშე.
ხანგრძლივი საიდუმლოებები გარემოში/რეპოში.
პოლიტიკოსები, რომლებიც არ არიან დანერგილი, როგორც კოდი, სახელმძღვანელო „დავიწყებულია“.
Logs PD- ით შენიღბვის გარეშე და ჭრის გარეშე/TTL.
Supply chain- ის უგულებელყოფა (არ არსებობს SBOM/ხელმოწერები/სკანერები).
რისკის მიღება (Accept) მფლობელის გარეშე და გადასინჯვის თარიღი.

14) ინტეგრაცია პროცესებში

RFC/ADR: თითოეული მნიშვნელოვანი გადაწყვეტილება შეიცავს „საფრთხეების და კონტროლის“ განყოფილებას.
Docs-as-Code: threat მოდელი, DFD, რისკის რეესტრი ვერსიაში კოდის გვერდით.
Release gates: გამოშვება იბლოკება SAST/SCA/SBOM პოლიტიკოსის წარუმატებლობის ან მაღალი კრიტიკის არარსებობის კონტროლების დროს.
ტრენინგი: playbuks დეველოპერებისთვის (საიდუმლოებები, ხელმოწერები, PoLP), რეგულარული tabletop.

დასკვნა

Threat Modeling არის რისკის მართვის საინჟინრო პრაქტიკა და არა ერთჯერადი დოკუმენტი. დაადგინეთ აქტივები და ნდობის საზღვრები, გამოიყენეთ STRIDE/LINDDUN, გაზომეთ რისკი, დააფიქსირეთ იგი რეესტრში და გააცნობიერეთ, როგორც კოდი, მათი ინტეგრირება CI/CD და ექსპლუატაციაში. სიმწიფის მეტრიკებით და რეგულარული გადასინჯვით, თქვენ უსაფრთხოებას გადააქცევთ პროგნოზირებულ არქიტექტურულ უნარზე - გასაგები ფასით, ეფექტით და სიჩქარით.