CloudNative の普及により、Kubernetes をはじめとするコンテナ基盤を本番環境で運用するチームが増えてきました。しかしその一方で、従来の境界防御を前提としたセキュリティ設計はこうした環境ではうまく機能しません。
ワークロードは動的に生成・破棄され、内部通信も信頼できず、どこから守るべきかを判断できない状態に陥りがちです。その結果、対策は増えていくのに設計だけが複雑化していきます。
本セッションでは、SaaS アーキテクチャを例に Kubernetes 環境の脅威モデリングを段階的に実践します。STRIDE フレームワークによる脅威の洗い出し、リスクアセスメントによる対策の優先順位決定、そしてその結果を具体的な設計にどう落とし込むかまでの一連のプロセスを紹介します。
AUDER 株式会社
Lead Engineer (SRE)
フリーランスを経て、4月から物流系スタートアップ企業にて、SRE•インフラ•社内ITの領域を中心に自称「非機能要件なんでもやるマン」として働くITエンジニアです
このセッションに関する質問と回答
説明頂いた部分は、インフラ周りの脆弱性がメインになるというイメージでよろしいでしょうか。
ご質問いただきありがとうございます。STRIDE-LMというフレームワーク自体は、本来アプリ・インフラを横断する汎用的な脅威分類で、特定レイヤに偏ったものではありません。ただ、本セッションで題材にしている例はCloudNative環境(コンテナ/Kubernetes/AWS)を前提にしているため、結果的にインフラ・プラットフォーム層の脅威を中心に紹介させていただきました。アプリケーション開発の文脈だと、STRIDE-LMでも同様に「この機能/APIに対して、各カテゴリの脅威が成立するか?」を当てはめていく考え方が一般的です。
Slide 36 (STRIDE-LMについての説明)のテーブルの「脅威」カラム名が間違っているような
ご指摘いただきありがとうございます。わかりにくい表現となっておりましたので、修正し差し替えたものをアップロードしました。