クラウドネイティブ環境の脅威モデリング

イベント登壇資料です。2025/05/08 #TMCTokyo
https://lu.ma/tmc-tokyo-meetup-2025-05

Transcript

1. クラウドネイティブ環境の脅威 モデリング @kyohmizu 脅威モデリングナイト #9
2. whoami Security Engineer at 3-shake inc. • Container/Kubernetes Security • AWS/Google Cloud Security • Security Operations & Technical Support for Blue Team • Cloud Native Security Assessment Others: • 3-shake SRE Tech Talk イベント運営 • 「コンテナセキュリティ」書籍監訳 Kyohei Mizumoto
3. 本セッションについて クラウドネイティブ環境の脅威モデリングについて、業務で実践した内容をベースにご紹 介します • 脅威モデリングの背景 • クラウドネイティブと Kubernetesについて • 脅威モデリングの実施手順とポイント • 結果と課題
4. 背景と前提 01
5. プロジェクトについて セキュアなコンテナシステムをKubernetesで実現する • 複数コンポーネントで構成される分散システムを想定 • データを安全に管理することが最重要 • アプリケーションは実装済みで、コンテナ化されている • オンプレ環境において、インフラを 0からKubernetesで構築する • Kubernetes設定の最適化、OSSの利用によりセキュアなシステムを実現する
6. システム構成（サンプル） 分析用データの加工処理を行うシステム • 取得したデータを分散処理し、中間データとして保管 • 中間データから分析用データに復元して保管 • 分析者は保管された分析用データを取得する
7. セキュリティ対策のアプローチ コンテナシステムの脅威を洗い出し、各脅威に対して有効な対策を検討 • 脅威マトリクスを参考に、 Kubernetes環境の脅威を洗い出し • 各脅威に対してセキュリティ対策をマッピング • 脅威モデリングを実施し、システム固有の脅威の発見と対策優先度の決定 • 優先度に基づいて導入すべきセキュリティ対策を決定 • システム構築＆セキュリティ対策の導入
8. 脅威モデリングの目的 システム固有の脅威を発見し、各脅威への対策優先度を決定する • Kubernetes環境の一般的な脅威は整理済み ◦ 脅威モデリングのインプットとして利用 • 脅威モデリングを実施することで、整理しきれなかったシステム固有の脅威を発見 ◦ 発見した脅威を事前に整理した脅威一覧に追加 • 各脅威の重大度を環境情報を含めて評価し、対策すべき脅威の優先度を決定 ◦ 導入するセキュリティ対策の根拠を明確化したい
9. Kubernetes環境における脅威一覧 脅威マトリクスを参考に、140の脅威と対策をマッピング
10. コンテナ/Kubernetesの脅威マトリクス Containers Matrix - MITRE ATT&CK https://attack.mitre.org/matrices/enterprise/containers/ Secure containerized environments with updated threat matrix for Kubernetes https://www.microsoft.com/en-us/security/blog/2021/03/23/secure-containerized-environments-with- updated-threat-matrix-for-kubernetes/ Restructuring the Kubernetes Threat Matrix and Evaluating Attack Detection by Falco https://engineering.mercari.com/en/blog/entry/20220928-kubernetes-threat-matrix-and-attack-detect ion-by-falco/
11. クラウドネイティブとKubernetes 02
12. クラウドネイティブについて クラウドネイティブ技術は、パブリッククラウド、プライベートクラウド、ハイブリッドクラウド などの近代的でダイナミックな環境において、スケーラブルなアプリケーションを構築およ び実行するための能力を組織にもたらします。 このアプローチの代表例に、コンテナ、 サービスメッシュ、マイクロサービス、イミュータブルインフラストラクチャ、および宣言型 APIがあります。 これらの手法により、回復性、管理力、および可観測性のある疎結合システムが実現しま す。 これらを堅牢な自動化と組み合わせることで、エンジニアはインパクトのある変更を 最小限の労力で頻繁かつ予測どおりに行うことができます。 https://github.com/cncf/toc/blob/main/DEFINITION.md
13. Kubernetesについて Kubernetesは、宣言的な構成管理と自動化を促進し、コンテナ化されたワークロードや サービスを管理するための、ポータブルで拡張性のあるオープンソースのプラットフォーム です。Kubernetesは巨大で急速に成長しているエコシステムを備えており、それらのサー ビス、サポート、ツールは幅広い形で利用可能です。 公式リンク: https://kubernetes.io/ https://github.com/kubernetes/kubernetes https://kubernetes.io/docs/concepts/overview/
14. Kubernetesの特徴 ① インフラリソースの抽象化 ネットワークやストレージなど、すべてのインフラリソースを Kubernetes 上のリソースとして管理しま す。Kubernetes は複数のVMを束ねて一つのクラスタを構成しますが、それぞれの VMの状態（CPU やメモリ使用率など）を気にする必要はなく、ワークロードに適切なインフラリソースを割り当てることが できます。 インフラのコード化 (Infrastructure as Code) Kubernetes はインフラを宣言的なコード（マニフェストファイル）として管理します。これにより、インフラ の構築や変更をコードとしてバージョン管理し、自動化することができます。マニフェストファイルにはリ ソースのあるべき姿（ Desired State）を記述します。 https://github.com/kyohmizu/seccamp2024-B6/tree/master/ch01_k8s_intro#kubernetes-%E3%81%AE%E7%89%B9%E5%BE%B4
15. Kubernetesの特徴 ② オーケストレーション Kubernetes を構成する各種コンポーネントが協調し、一つのクラスタを稼働させます。コンポーネント 同士が直接通信・連携するのではなく、各々の役割を果たすことで全体として理想の状態を維持しま す。 高い拡張性 ネットワーク、ストレージ、コンテナランタイムなど、多くの機能をプラグインを通じて拡張できます。 • CNI (Container Network Interface), CSI (Storage), CRI (Runtime) • Admission Controllers, Custom Resources https://github.com/kyohmizu/seccamp2024-B6/tree/master/ch01_k8s_intro#kubernetes-%E3%81%AE%E7%89%B9%E5%BE%B4
16. Kubernetesの構成 https://kubernetes.io/ja/docs/concepts/overview/components/
17. Kubernetesの構成 コントロールプレーン • kube-apiserver ◦ Kubernetes APIを提供し、すべてのコンポーネントと通信する ◦ Kubernetes のフロントエンドとして機能し、すべての REST 操作を処理 • etcd ◦ クラスタのすべてのデータを保存するキー・バリュー・ストア • kube-scheduler ◦ 新しい Pod のスケジューリングを行い、最適なノードに割り当てます • kube-controller-manager ◦ クラスタ全体の状態を管理するコントローラー群 https://kubernetes.io/ja/docs/concepts/overview/components/
18. Kubernetesの構成 ワーカーノード • kubelet ◦ 各ノード上で実行され、 Podのライフサイクルを管理 ◦ APIサーバーから Pod 定義を受け取り、コンテナランタイムにコンテナ作成を指示 • kube-proxy ◦ 各ノード上で実行され、ネットワーク通信を管理 ◦ クラスタ内のサービス間通信を実現し、ネットワークルールを適用 • コンテナランタイム ◦ 実際にコンテナを実行するソフトウェア（例： Docker、containerd） ◦ コンテナの実行、停止、ネットワーク設定などを実行 https://kubernetes.io/ja/docs/concepts/overview/components/
19. マニフェストファイル Kubernetesリソースを記述するYAML形式のファイル リソース例: • Pod ◦ デプロイの最小単位 • ReplicaSet ◦ 指定された数の Pod を常に稼働させる • Deployment ◦ アプリのデプロイと管理を簡素化 https://kubernetes.io/docs/concepts/overview/working-with-objects/ apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment spec: selector: matchLabels: app: nginx replicas: 2 template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.14.2 ports: - containerPort: 80
20. 開発・デプロイプロセス https://speakerdeck.com/kyohmizu/kontenasapuraitiensekiyuritei?slide=9
21. クラウドネイティブセキュリティ (4C Model) アプリケーションコードの脆弱性対策、依存 関係の脆弱性管理と安全性評価、コードへ のアクセス制御など。 Dockerfileの堅牢化、コンテナイメージの脆 弱性管理と信頼性確認、分離レベルの高い コンテナランタイムの導入など。 クラスタコンポーネントの堅牢化と脆弱性管 理、クラスタ内リソースの堅牢化、ポスチャー 管理、Admission Control、ランタイムセ キュリティなど。 責任共有モデルの理解、セキュリティサービ スを利用したアクセス制御、ポスチャー管 理、不審なアクティビティの監視など。 Code Cluster Container Cloud https://kubernetes.io/ja/docs/concepts/security/overview/
22. クラウドネイティブセキュリティ (SDLC) アプリケーションコードやIaCのコード解析、 テストの開発、開発者によるコードレビューな ど。 CIパイプラインにおけるコード解析、コンテナ イメージの脆弱性スキャン、イメージ署名や 暗号化、アプリケーションの動的解析など。 デプロイ前のセキュリティチェック（イメージ署 名の検証、各種ポリシーの検証）、監視やロ グ機能のデプロイなど。 コンテナホストのセキュリティ、クラスタのセ キュリティ、ID管理とアクセス制御、可用性 の維持など。 Develop Deploy Distribute Runtime https://cnsmap.netlify.app/
23. 脅威モデリングの実践 03
24. 脅威モデリングの実施手順 • 実施計画の作成 ◦ 脅威モデルの選定 ◦ 対象範囲の決定 ◦ 評価基準の作成 • DFDの作成 • 脅威の洗い出し • 脅威の評価 • 結果報告
25. 脅威モデルの選定 システムの脅威を特定するのに適した STRIDEモデルを利用 • 情報や実績が多数あり、実践しやすい点も◯ • カテゴリはカスタマイズせずにそのまま利用 https://www.windriver.com/japan/solutions/learning/threat-modeling なりすまし（Spoofing） ユーザ名やパスワードなど、他のユーザの認証情報への不正アクセスやその 使用 改ざん（Tampering） データの悪意ある改ざん 否認（Repudiation） ある行為の実行を否定するユーザに関係。他者が証明する術を持たない 情報漏えい（Information Disclosure） 情報を入手する権限のない個人への情報漏洩 サービス妨害（DoS） 正当なユーザがサービスを受けられないようにする攻撃 特権昇格（Elevation of Privileges） 非特権ユーザが特権的にアクセスし、システム全体を危険にさらすか破壊する のに十分なアクセス権を持っていること
26. STRIDEを使った脅威モデリング OWASP Threat Dragon https://github.com/OWASP/threat-dragon ビルダーのための脅威モデリング https://catalog.workshops.aws/threatmodel/ja-JP 複数名による効率的な脅威モデリングの実践 https://developers.cyberagent.co.jp/blog/archives/41487/
27. Kubernetesの脅威モデリング A Deep Dive Into Kubernetes Threat Modeling https://www.trendmicro.com/vinfo/us/security/news/security-technology/a-deep-dive-into-kubernete s-threat-modeling 脅威モデリングで考える Kubernetes セキュリティ https://speakerdeck.com/mrtc0/cloudnative-days-tokyo-2021-number-cndt2021-number-cndt2021-b
28. 対象範囲の決定 脅威モデリングの対象範囲は本プロジェクトのスコープに限定 対象: • VMとKubernetes、Kubernetes上のリソース • アプリケーションコンテナ • ビルド、デプロイシステム 対象外: • VMより下の物理インフラ、ネットワークなど • アプリケーションのソースコード
29. DFDの作成 OWASP Threat Dragonを参考にDFDを作成 https://github.com/OWASP/threat-dragon
30. 各コンポーネントに以下情報を付与 • 保有するデータ • 保有する資格情報 DFDの作成
31. 脅威の洗い出し DFDを見ながらコンポーネント毎の脅威を洗い出し • OWASP Threat Dragonを参考にフォーマットを決定 ◦ 評価軸等は後からカスタマイズ • AWSワークショップのDocsを参考にステートメントを決定 ◦ https://catalog.workshops.aws/threatmodel/ja-JP/what-can-go-wrong/threat-grammar ◦ [脅威アクターの前提条件 ] + [脅威アクション] + [脅威による影響] • 事前に整理したKubernetes環境の脅威一覧をインプットとする
32. 脅威の評価 洗い出した脅威を3つの基準で評価し、脅威の重大度と対策優先度を決定 攻撃の容易性 脅威アクターから見たコンポーネントへの到達性と攻撃の複雑さ コンポーネントへの到達性：インターネット、社内ネットワーク、 k8sクラスタ内 攻撃の複雑さ：脆弱性またはユーザー操作の必要性 重要データ 重要データに何ステップで到達可能か 1ステップで到達可能：高 2ステップで到達可能：中 3ステップ以上が必要：低 影響度 脅威が発生した際の影響範囲と影響の大きさ 影響範囲：システム全体、システムの一部、単一のコンポーネント 影響の大きさ：情報セキュリティの CIA（機密性、完全性、可用性）
33. 脅威の評価 • 機械的に判断できるよう、定量的な評価基準を作成 ◦ 評価基準の明確化 ◦ セキュリティに詳しくない人でも評価可能な基準とする • 3つの評価基準をもとに最終的な重大度を決定 ◦ 重要データの基準を重視した重み付け ◦ 定量的な評価基準とし、計算式を作成して自動入力 • 重大度が分散するように評価基準を決定 ◦ 優先的に導入すべき対策、導入しない対策を選別
34. 脅威モデリングレポート
35. ふりかえり ① • 当初の目的は達成 ◦ 事前に整理した脅威一覧に、脅威モデリングで発見した脅威を追加 ◦ 脅威の重大度をもとにセキュリティ対策の優先を決定 • システムの網羅的な理解に役立った ◦ アプリ仕様と処理の流れ ◦ システム構成、コンポーネント毎のデータと資格情報 ◦ 攻撃シナリオと攻撃パス • 複数人で脅威モデリングを実施するにあたり、基準の明確化が重要 ◦ 脅威のステートメントや評価基準の認識合わせ ◦ 曖昧な判断にならず、すべてが説明可能 ◦ 脅威モデリングを進めながら適宜変更
36. ふりかえり ② • 脅威の洗い出しにはセキュリティと Kubernetesの知識が必要 ◦ 両方を知る人がいない場合、完成度に影響しないか？ • 想定より時間がかかり、関係者を巻き込んだ実施はできなかった ◦ セキュリティエンジニアのみで実施し、関係者にはヒアリングと結果報告 • 他タスクと並行で作業を進め、実施期間は 1ヶ月ほど ◦ 要件整理や内容の見直しに多く時間を取ることができた点は◯ • 脅威モデリングの継続的な実施にはつながらなかった ◦ 今回の実施手順と評価基準を用い、継続的に実施することは可能なはず • コンポーネント毎にセキュリティ対策の柔軟な適用ができなかった ◦ セキュリティ対策はクラスタ全体に一律に適用 ◦ コンポーネント毎の対策優先度をどのように活用するか？
37. さいごに 初めて脅威モデリングを実践し、様々な気づきを得られました。 今回ご紹介した内容が、皆さんが脅威モデリングを実践する際の一助になれば幸いです。 私自身手探りで取り組んでいますので、ご意見・ご感想などありましたらぜひ教えてくださ い！
38. CREDITS: This presentation template was created by Slidesgo, and includes icons by Flaticon, and infographics & images by Freepik Thanks! Do you have any questions? https://twitter.com/kyohmizu