脅威モデリングとリスク管理

1）原則

1.最初の建築。コンテキスト、信頼境界、データフローから始めます。
2.リスク≈影響×可能性。私たちは、感じていない測定します。
3.ディフェンス・イン・デプス。各レイヤーのコントロール：code→protocol→platform→people。
4.Shift Left/Right。PR+モニタリングの初期ゲートとprodの反応。
5.デザインによるプライバシー。セキュリティの脅威だけでなく、プライバシーリスクもシミュレーションします。
6.可能な限り自動化します。コードとしてのポリシー、自動チェック、「赤い線」。

2）在庫： 資産、エンティティ、信託の境界

資産：データ（PII、財務、秘密）、コンピューティングリソース、キー、アクセス、ビジネスプロセス。
対象：ユーザー、サービス、管理者、パートナー、外部プロバイダー。
信頼境界：ユーザー↔フロント、フロント↔ APIゲートウェイ、サービス↔データベース/キャッシュ/キュー、リージョン/クラウド。
攻撃の表面：入力ポイント（API、 webhook、 UI、ネットワーク、CI/CD、サプライチェーン）。

DFD（例、マーメイド）：

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 （безопасность）：なりすまし、改ざん、非難、情報開示、サービス拒否、特権の昇格。
LINDDUN （приватность）：リンク性、識別可能性、否認防止、検出可能性、開示、無意識、不適合。
PASTA（プロセス）：ビジネス目標と脅威アクター→技術的詳細→テストシナリオから。

テーブル（フラグメント、STRIDE ×コンポーネント）：

［コンポーネント］	S/S	R （R）	私は、
APIゲートウェイ	mTLS/OIDC、 WAF、レート制限、監査、HSTS
カフカ（Kafka			ACL、署名済みイベント、クォータ、DLQ
Postgres（ポストグ		TLS、 RLS、 KMS、検証による移行

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+、mTLS、 webhookシグネチャ、idempotency、およびアンチリプレイ。
検証/衛生：スキーム（JSONスキーマ/プロトー）、制限、正規化。
分離：ネットワークポリシー、セグメンテーション、サンドボックス、名前空間、隔壁。

検出して下さい：

監査ログ（認識不能）、SIEMの相関、異常に対するアラート。
署名と完全性の監視（アーティファクトハッシュのエクスポート、証明）。
早期キーリーク検出のためのハネトーケン/カナリア。

応答：

Runbook IR：分類、分離、キーリコール、アラート、フォレンジック。
自動キルスイッチ/フィーチャーフラグ、トークンの「ブラックリスト」。
PDインシデントの場合のユーザー/レギュレータの通知。

6） SDLおよびセキュリティゲート

アイデア/デザイン：脅威モデル（RFC/ADR）、コントロールのチェックリスト。
開発中：SAST/secret-scan、 dependency scans （SCA）、 dependency policy。
アセンブリ：SBOM、アーティファクト署名、脆弱性ポリシー（CVSSしきい値）。
フィールドで：OPA/Kyverno-IaC/マニフェストポリシー（securityContext、ネットワークポリシー、シークレット転送）。
販売で：IDS/WAF、異常検出、カナリアチェック、カオスセキュリティ（例えば、期限切れの証明書）。

ゲートの例（Policy as Code、 pseudo-Rego）：

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/出所：再現可能なアセンブリ、署名、証明。
コンテナ：最小限の画像、ルートレス、ドロップ機能、読み取り専用FS。
IaCスキャン：Terraform/Helm-暗号化ポリシー、オープンポート、ネットワークルール。

8）プライバシーとコンプライアンス

プライバシーの脅威、データの最小化、匿名化/匿名化のLINDDUNマップ。
保持ポリシー：TTL/保持「、削除する権利」、PDへのアクセスの監査。
ローカリゼーション：地理的制限、「データは地域に残ります」。
透明性：処理、通知、同意ログ。

9）雲と周囲

Zero Trust：各リクエストの認証、サービス間のmTLS/OPA。
セグメンテーション：VPC/サブネット/SG、プライベートエンドポイント、排出制御。
キー/秘密：KMS、回転、CI （OIDCフェデレーション）のショートクレジット。
Reserve/DR：暗号化されたバックアップ、キー、回復リハーサル。

10）赤く/紫色のチームおよび卓上の練習

レッドチーム：脅威仮説テスト、ソーシャルエンジニアリング、チェーン開発。
紫色のチーム：検出/アラートの共同デバッグ、playbooks IRを改善します。
卓上：スクリプト「expired certificate」、「leaked keys'、」サプライチェーンの妥協。"結果はコントロールとメトリックが更新されます。

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 Webhookポリシー（擬似コード）

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/不変量のない脅威モデル「for show」。
内部サービスツーサービス認証なしの「超周辺」。
環境変数/リポ変数の長寿命の秘密。
コード→マニュアルとして埋め込まれていないポリシー「忘れられた」。
カモフラージュなしで、保持/TTLなしでPDでログを記録します。
サプライチェーンを無視する（SBOM/署名/スキャンなし）。
所有者と改訂日なしで受け入れる。

14）プロセスへの統合

RFC/ADR-各意味のあるソリューションには、［脅威とコントロール］セクションがあります。
Docs-as-Code：脅威モデル、DFD、コードの横にあるバージョンのリスクレジスタ。
リリースゲート：SAST/SCA/SBOMポリシーが失敗した場合、または重大度の高いコントロールがない場合、リリースがブロックされます。
トレーニング：開発者のためのプレイブック（秘密、署名、PoLP）、通常の卓上。

おわりに

Threat Modelingはリスクマネジメントのエンジニアリング手法であり、ワンタイムドキュメントではありません。アセットと信頼の境界を定義し、STRIDE/LINDDUNを適用し、リスクを測定し、それを登録し、CI/CDと操作に埋め込むことで制御をコードとして実装します。成熟度の指標と定期的な改訂により、安全性を予測可能なアーキテクチャ能力に変えることができます。

脅威モデリングとリスク管理

おわりに

お問い合わせ

迅速な連絡

動画はまもなく更新されます

現在、私たちはプロジェクトで非常に多忙です