위협 모델링 및 위험 제어
1) 원칙
1. 건축 우선. 우리는 상황, 신뢰 경계 및 데이터 흐름으로 시작합니다.
2. 위험 가능성 × 영향. 우리는 느끼지 않고 측정합니다.
3. 깊이의 방어. 각 계층의 제어: 코드 → 프로토콜 → 플랫폼 → 사람.
4. 왼쪽/오른쪽으로 이동하십시오 PR + 모니터링의 초기 게이트 및 prod의 반응.
5. 디자인에 의한 개인 정보. 보안 위협뿐만 아니라 개인 정보 보호 위험도 시뮬레이션합니다.
6. 가능한 곳에서 자동화하십시오. 코드, 자동 점검, "빨간 선" 과 같은 정책.
2) 재고: 자산, 실체, 신뢰의 경계
자산: 데이터 (PII, 재무, 비밀), 컴퓨팅 리소스, 키, 액세스, 비즈니스 프로세스.
주제: 사용자, 서비스, 관리자, 파트너, 외부 제공 업체.
신뢰할 수있는 경계: 사용자 전면, 전면 API 게이트웨이, 서비스 데이터베이스/캐시/대기열, 지역/구름.
공격 표면: 입력 지점 (API, 웹 후크, UI, 네트워크, CI/CD, 공급망).
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) 위협 프레임 워크
LINDDUN (
스트라이드: 스푸핑, 탬 퍼링, 배상, 정보 공개, 서비스 거부, 특권 상승.
PASTA (프로세스): 비즈니스 목표 및 위협 행위자 → 기술 세부 사항 → 테스트 시나리오.
4) 위험 평가
취약점에 대한 DREAD/OWASP 위험 등급 또는 CVSS.
확률 (L): 공격자의 동기/기능, 복잡성, 표면 노출.
영향 (I): 재무, 법적 위험, 다운 타임, PD 누출.
위험 (R = L × I) → 우선 순위 지정 및 재판: 피하기/감소/전송/수락.
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) 제어: 예방/탐지/응답
예방:- 인증/인증: OIDC/OAuth2, PoLP, RBAC/ABAC, 단기 서비스 크레딧.
- 비밀/키: KMS/HSM, 회전, 모름, FPE/필드 암호화.
- 보안 프로토콜: TLS1. 2 +, mSL, 웹 후크 시그니처, demempotency 및 재생 방지.
- 검증/위생: 체계 (JSON Schema/Proto), 한계, 정규화.
- 격리: 네트워크 정책, 세분화, 샌드 박스, 네임 스페이스, 벌크 헤드.
- SIEM의 상관 관계 인 감사 로그 (인식 할 수 없음) 는 이상에 대해 경고합니다.
- 서명 및 무결성 모니터링 (아티팩트 해시 내보내기, 증명).
- 초기 키 누출 감지를위한 허니 토큰/카나리아.
- Runbook IR: 분류, 격리, 주요 리콜, 경고, 법의학.
- 토큰의 자동 킬 스위치/기능 플래그, "검은 색 목록".
- PD 사고가 발생했을 때 사용자/규제 기관의 알림.
6) SDL 및 보안 게이트
아이디어/디자인: 위협 모델 (RFC/ADR), 컨트롤 체크리스트.
개발 중: SAST/비밀 스캔, 종속성 스캔 (SCA), 종속성 정책.
어셈블리: SBOM, 아티팩트 서명, 취약성 정책 (CVSS 임계 값).
현장: OPA/Kyverno-IaC/manifest 정책 (SecurityContex, 네트워크 정책, 비밀 전달).
판매: 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) 유물을 공급하고 신뢰하십시오
이미지/패키지 당 SBOM; 봇/정책을 통한 종속성 업데이트.
SLSA/Provenance: 재현 가능한 어셈블리, 서명, 증명.
컨테이너: 최소한의 이미지, 뿌리가없는, 드롭 기능, 읽기 전용 FS.
IaC 스캔: Terraform/Helm-암호화 정책, 개방형 포트, 네트워크 규칙.
8) 개인 정보 보호 및 준수
LINDDUN 개인 정보 보호 위협, 데이터 최소화, 가명/익명화 맵.
보존 정책: TTL/보존, "삭제권", PD 액세스 감사.
현지화: 지리 제한, "데이터는 해당 지역에 남아 있습니다".
투명성: 처리, 알림 및 동의 로그.
9) 구름과 주변
제로 트러스트: 각 요청의 인증, 서비스 간 mSL/OPA.
세분화: VPC/서브 넷/SG, 개인 엔드 포인트, 탈출 제어.
키/비밀: CI (OIDC 페더레이션) 의 KMS, 로테이션, 짧은 크레딧.
예약/DR: 암호화 된 백업, 키가 별도, 복구 리허설.
10) 빨강/보라색 팀 및 탁상 운동
레드 팀: 위협 가설 테스트, 사회 공학, 연쇄 이용.
퍼플 팀: 탐지/경고의 공동 디버깅, 플레이 북 IR을 개선합니다.
테이블 탑: 스크립트 "만료 된 인증서", "누출 된 키", "공급망 손상. "결과는 업데이트 된 컨트롤과 메트릭입니다.
11) 성숙도 지표 및 관리
적용 범위: 현재 위협 모델 및 DFD 서비스의%.
안전 MTTD/MTTR, 통제에 의해 잡힌 사고의 비율.
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 런북이 업데이트 되었습니까?
개인 정보 보호: 최소화, 암호화, 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/불변량이없는 "쇼 용" 위협 모델.
내부 서비스 간 인증이없는 "초 주변".
환경/레포 변수의 오랜 비밀.
코드 → 수동 "잊혀진" 으로 포함되지 않은 정책.
위장이없고 보존/TTL이없는 PD가있는 로그.
공급망 무시 (SBOM/서명/스캔 없음).
소유자와 개정 날짜없이 수락하십시오
14) 프로세스로의 통합
RFC/ADR-각 의미있는 솔루션에는 위협 및 제어 섹션이 포함되어 있습니다.
Docs-as-Code: 위협 모델, DFD, 코드 옆에있는 버전의 위험 등록.
릴리스 게이트: SAST/SCA/SBOM 정책이 실패하거나 심각도가 높은 제어가 누락되면 릴리스가 차단됩니다.
교육: 개발자를위한 플레이 북 (비밀, 서명, PoLP), 일반 탁상.
결론
Threat Modeling은 일회성 문서가 아닌 위험 관리의 엔지니어링 관행입니다. 자산 및 신뢰 경계를 정의하고, STRIDE/LINDDUN을 적용하고, 위험을 측정하고, 등록하고, CI/CD 및 운영에 포함시켜 컨트롤을 코드로 구현하십시오. 성숙도 지표와 정기적 인 수정으로 안전을 이해할 수있는 가격, 효과 및 속도로 예측 가능한 아키텍처 기능으로 전환합니다.