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-шлюз, сервистер, БД/кэштер/кезектер, өңірлер/бұлттар.
Шабуыл беті: кіру нүктелері (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 Тәуекел рейтингі немесе осалдықтар үшін CVSS.
Ықтималдық (L): шабуылдаушының уәжі/мүмкіндігі, күрделілігі, бетінің экспозициясы.
Әсері (I): қаржы, юрриски, тоқтап қалу, ӨД ағуы.
Тәуекел (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, вебхук қолтаңбалары, іспеттілік және anti-replay.
• Валидация/санитария: схемалар (JSON Schema/Proto), лимиттер, қалыпқа келтіру.
• Оқшаулау: network policies, сегментация, sandbox, namespaces, bulkheads.

• Аудит-логтар (шеттетілмейтін), SIEM-дегі корелляция, аномалиядағы алерталар.
• Қол қою және тұтастық мониторингі (артефактілер хэштерінің экспорты, attestation).
• Honeytokens/кілттердің жылыстауының ерте детекторы үшін канарейка.

• Runbook IR: жіктеу, оқшаулау, кілттерді қайтару, хабарландыру, форензия.
• Автоматты kill-switch/feature-flag, белгілердің «қара тізімдері».
• ПД-мен болған тосын оқиғалар кезінде пайдаланушылардың/реттеушілердің хабарламалары.

6) SDL және қауіпсіздік гейттері

Идеяға/дизайнға: threat model (RFC/ADR), чек-бақылау парағы.
Әзірлеуде: SAST/secret-scan, тәуелділік сканерлері (SCA), тәуелділік саясаты.
Жинақта: SBOM, артефактілердің қолы, осалдықтар саясаты (CVSS табалдырықтары).
Деплойда: OPA/Kyverno - IaC/манифесттер саясаты (securityContext, желілік саясат, құпиялардың көбеюі).
Өнімде: IDS/WAF, anomaly detection, canary-тексерулер, хаос-қауіпсіздік (мысалы, мерзімі өткен сертификат).

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: ойнатылатын жиынтықтар, қолтаңбалар, attestations.
Контейнерлер: минималды бейнелер, rootless, drop capabilities, read-only FS.
IaC-сканерлер: Terraform/Helm - шифрлау, ашық порттар, желілік ережелер жөніндегі саясат.

8) Құпиялылық және комплаенс

LINDDUN-құпиялылық қатерінің картасы, data minimization, бүркеншік атау/анонимдеу.
Сақтау саясаты: TTL/ретеншн, «жою құқығы», ПД-ға қол жеткізу аудиті.
Оқшаулау: гео-шектеулер, «деректер өңірде қалады».
Ашықтық: өңдеу, хабарлама және келісім журналдары.

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: өзекті threat model және DFD қызметтерінің%.
MTTD/MTTR қауіпсіздік, бақылаумен ұсталған оқыс оқиғалар үлесі.
CI-дегі policy pass-rate, сыни бойынша осалдықтарды жабу уақыты.
Құпиялылық: 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 жаңартылды ма?
Privacy: минимизация, шифрлау, 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/инварианттары жоқ «белгі үшін» Threat моделі.
Сервистің ішкі аутентификациясы жоқ «супер-периметр».
Қоршаған орта ауыспалыларындағы ұзақ өмір сүретін құпиялар/репо.
Код ретінде енгізілмеген саясаттар → қолмен «ұмытылады».
ПД бар бүркемеленбеген және ретеншнсіз/TTL.
Supply chain дегенді елемеу (SBOM/қолтаңбалар/сканерлер жоқ).
Иесiз және қайта қарау күнiнсiз тәуекелдi (Accept) қабылдау.

14) Процестерге интеграциялау

RFC/ADR: әрбір маңызды шешім «Қатерлер мен бақылаулар» бөлімін қамтиды.
Docs-as-Code: threat model, DFD, кодпен қатар нұсқадағы тәуекелдер тіркелімі.
Release gates: SAST/SCA/SBOM саясатының сәтсіздігі немесе жоғары сыни бақылаудың болмауы кезінде шығарылым бұғатталады.
Оқыту: әзірлеушілерге арналған плейбуктер (құпиялар, қолтаңбалар, PoLP), тұрақты tabletop.

Қорытынды

Threat Modeling - бұл бір реттік құжат емес, тәуекелді басқарудың инженерлік практикасы. Активтер мен сенім шектерін анықтаңыз, STRIDE/LINDDUN қолданыңыз, тәуекелді өлшеңіз, оны тіркелімде белгілеңіз және CI/CD-ге және пайдалануға кірістіріп, бақылауды код ретінде жүзеге асырыңыз. Жетілу өлшемдерімен және үнемі қайта қараумен сіз қауіпсіздікті болжамды архитектуралық қабілетке айналдырасыз - түсінікті бағамен, әсермен және жылдамдықпен.