Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

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

Avatar for Kyohei Mizumoto

Kyohei Mizumoto

May 08, 2025
Tweet

More Decks by Kyohei Mizumoto

Other Decks in Technology

Transcript

  1. 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
  2. コンテナ/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/
  3. 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
  4. Kubernetesの構成 コントロールプレーン • kube-apiserver ◦ Kubernetes APIを提供し、すべてのコンポーネントと通信する ◦ Kubernetes のフロントエンドとして機能し、すべての

    REST 操作を処理 • etcd ◦ クラスタのすべてのデータを保存するキー・バリュー・ストア • kube-scheduler ◦ 新しい Pod のスケジューリングを行い、最適なノードに割り当てます • kube-controller-manager ◦ クラスタ全体の状態を管理するコントローラー群 https://kubernetes.io/ja/docs/concepts/overview/components/
  5. Kubernetesの構成 ワーカーノード • kubelet ◦ 各ノード上で実行され、 Podのライフサイクルを管理 ◦ APIサーバーから Pod

    定義を受け取り、コンテナランタイムにコンテナ作成を指示 • kube-proxy ◦ 各ノード上で実行され、ネットワーク通信を管理 ◦ クラスタ内のサービス間通信を実現し、ネットワークルールを適用 • コンテナランタイム ◦ 実際にコンテナを実行するソフトウェア(例: Docker、containerd) ◦ コンテナの実行、停止、ネットワーク設定などを実行 https://kubernetes.io/ja/docs/concepts/overview/components/
  6. マニフェストファイル 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
  7. クラウドネイティブセキュリティ (4C Model) アプリケーションコードの脆弱性対策、依存 関係の脆弱性管理と安全性評価、コードへ のアクセス制御など。 Dockerfileの堅牢化、コンテナイメージの脆 弱性管理と信頼性確認、分離レベルの高い コンテナランタイムの導入など。 クラスタコンポーネントの堅牢化と脆弱性管

    理、クラスタ内リソースの堅牢化、ポスチャー 管理、Admission Control、ランタイムセ キュリティなど。 責任共有モデルの理解、セキュリティサービ スを利用したアクセス制御、ポスチャー管 理、不審なアクティビティの監視など。 Code Cluster Container Cloud https://kubernetes.io/ja/docs/concepts/security/overview/
  8. 脅威モデルの選定 システムの脅威を特定するのに適した STRIDEモデルを利用 • 情報や実績が多数あり、実践しやすい点も◯ • カテゴリはカスタマイズせずにそのまま利用 https://www.windriver.com/japan/solutions/learning/threat-modeling なりすまし(Spoofing) ユーザ名やパスワードなど、他のユーザの認証情報への不正アクセスやその

    使用 改ざん(Tampering) データの悪意ある改ざん 否認(Repudiation) ある行為の実行を否定するユーザに関係。他者が証明する術を持たない 情報漏えい(Information Disclosure) 情報を入手する権限のない個人への情報漏洩 サービス妨害(DoS) 正当なユーザがサービスを受けられないようにする攻撃 特権昇格(Elevation of Privileges) 非特権ユーザが特権的にアクセスし、システム全体を危険にさらすか破壊する のに十分なアクセス権を持っていること
  9. 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
  10. 脅威の洗い出し DFDを見ながらコンポーネント毎の脅威を洗い出し • OWASP Threat Dragonを参考にフォーマットを決定 ◦ 評価軸等は後からカスタマイズ • AWSワークショップのDocsを参考にステートメントを決定

    ◦ https://catalog.workshops.aws/threatmodel/ja-JP/what-can-go-wrong/threat-grammar ◦ [脅威アクターの前提条件 ] + [脅威アクション] + [脅威による影響] • 事前に整理したKubernetes環境の脅威一覧をインプットとする
  11. 脅威の評価 • 機械的に判断できるよう、定量的な評価基準を作成 ◦ 評価基準の明確化 ◦ セキュリティに詳しくない人でも評価可能な基準とする • 3つの評価基準をもとに最終的な重大度を決定 ◦

    重要データの基準を重視した重み付け ◦ 定量的な評価基準とし、計算式を作成して自動入力 • 重大度が分散するように評価基準を決定 ◦ 優先的に導入すべき対策、導入しない対策を選別
  12. ふりかえり ① • 当初の目的は達成 ◦ 事前に整理した脅威一覧に、脅威モデリングで発見した脅威を追加 ◦ 脅威の重大度をもとにセキュリティ対策の優先を決定 • システムの網羅的な理解に役立った

    ◦ アプリ仕様と処理の流れ ◦ システム構成、コンポーネント毎のデータと資格情報 ◦ 攻撃シナリオと攻撃パス • 複数人で脅威モデリングを実施するにあたり、基準の明確化が重要 ◦ 脅威のステートメントや評価基準の認識合わせ ◦ 曖昧な判断にならず、すべてが説明可能 ◦ 脅威モデリングを進めながら適宜変更
  13. ふりかえり ② • 脅威の洗い出しにはセキュリティと Kubernetesの知識が必要 ◦ 両方を知る人がいない場合、完成度に影響しないか? • 想定より時間がかかり、関係者を巻き込んだ実施はできなかった ◦

    セキュリティエンジニアのみで実施し、関係者にはヒアリングと結果報告 • 他タスクと並行で作業を進め、実施期間は 1ヶ月ほど ◦ 要件整理や内容の見直しに多く時間を取ることができた点は◯ • 脅威モデリングの継続的な実施にはつながらなかった ◦ 今回の実施手順と評価基準を用い、継続的に実施することは可能なはず • コンポーネント毎にセキュリティ対策の柔軟な適用ができなかった ◦ セキュリティ対策はクラスタ全体に一律に適用 ◦ コンポーネント毎の対策優先度をどのように活用するか?
  14. 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