【クラウドネイティブ会議】「うちのサービスは大丈夫？」に答えるためのクラウドネイティブ環境の脅威モデリング入門

クラウドネイティブ環境の普及により、Kubernetesをはじめとするコンテナ基盤を本番環境で運用するチームは増えている。一方で、ワークロードが動的に生成・破棄され、内部通信も単純には信頼できない環境では、従来型の境界防御だけでは守るべきポイントを判断しにくい。クラウドネイティブ会議のセッション「セキュリティ対策、何から始める？――CloudNative環境の脅威モデリングとリスク評価実践入門」では、AUDERのLead Engineer（SRE）である中村昴氏が、脅威ベースアプローチを軸に、DFD、STRIDE、リスク評価を用いた実践手順を解説した。

なぜ脅威ベースでセキュリティ対策を考えるのか

AUDERの中村昴氏は、ソーシャルゲームやWebサービスのインフラエンジニア、SREとして10年ほど経験し、現在は同社のLead EngineerとしてセキュリティチームやSREチームの立ち上げを担当している。

セッションの本題は、クラウドネイティブ環境におけるセキュリティ対策をどこから始めるかである。中村氏はまず「情報セキュリティ10大脅威 2026」を取り上げた。組織編では「ランサム攻撃による被害」が11年連続でランクインし、新たに「AIの利用をめぐるサイバーリスク」も初選出された。

ただし重要なのは、脅威ランキングそのものではない。中村氏は、10大脅威の順位は毎回変動するが、ランキングは各組織で実施すべき対策の優先度と必ずしも一致しないことを示した。攻撃手口や動向に加え、自組織が抱える要因を把握し、組織ごとの状況を考慮して優先度を決める必要がある。

ここで中村氏は「うちのサービスは、大丈夫なの？」という問いを提示した。これに対して「脆弱性診断をやっているから大丈夫です」「ISMSを取得しているから大丈夫です」「クラウドのベストプラクティスに沿っているから大丈夫です」「EDRやSASEを入れているから大丈夫です」と答えることはできる。しかしそれだけでは自社サービスにとって何が本当に危険で、どの対策がどの脅威を防いでいるのかを説明しきれない。

うちのサービスは、大丈夫なの？

中村氏は前提として、セキュリティとはCIA、すなわち機密性（Confidentiality）、完全性（Integrity）、可用性（Availability）のいずれかを脅かすものを減らすことだと整理した。さらにリスクは「脅威×脆弱性×資産」と捉えられると説明した。脅威は害を及ぼしうる事象・要因、脆弱性は弱点や欠陥、資産は守るべき対象である。リスクは脆弱性が脅威にさらされて初めて顕在化するものであり、脆弱性があるからといって必ずしもリスクになるとは限らない。

ガイドライン準拠だけではなく、攻撃シナリオから考える

続いて中村氏は、リスク管理手法として、ベースライン型アプローチと脅威ベースアプローチを比較した。

ベースライン型アプローチは、ガイドラインを利用して課題を洗い出し、リスクを把握し、対策する方法である。各種基準に沿って確認できるため、セキュリティ対策の土台としては有効である。一方で、項目や指摘事項をクリアすること自体が目的化し、「その対策によってどんな脅威を防ぐのか」という観点が抜けがちになる。「管理策をクリアしたところで、どんな脅威を防げるのかという観点が抜けがちになります」と中村氏は語った。

リスク管理手法：ベースライン型アプローチ

これに対し脅威ベースアプローチは、攻撃者目線の攻撃シナリオをもとに、保護すべき資産に優先度を付けて対処する考え方である。特定の脅威から対策を考えられるため、限られたリソースの中でも優先順位を付けやすい。スタートアップやスモールチームでも実施しやすく、「どこで対策するのか」をシナリオで語れるため、経営層にも説明しやすい。「この脅威に対してはこういう対策をしています、とシナリオで語ることができます」と中村氏は説明した。

リスク管理手法：脅威ベースアプローチ

ただし、ベースライン型アプローチが不要というわけではない。中村氏は、基本的な対策の重要性は変わらないとしたうえで、ベースライン型と脅威ベース型はバランスが重要だと示した。ガイドラインで基本的な対策を押さえつつ、自組織のサービス、アーキテクチャ、扱うデータ、攻撃されうる経路に応じて、脅威ベースで優先度を決めることが現実的な進め方となる。

その実践手法として紹介されたのが脅威モデリングである。中村氏は、脅威モデリングを「システムの構成を分析し、セキュリティやプライバシーに関する懸念事項を明らかにする取り組み」として説明した。セキュリティの専門家だけでなく、セキュリティに関心のある人なら誰でも始められるという。

脅威モデリングでは、4つの質問に答えていく。第一に「我々は何を作っているのか」。ここでは参加者を決め、DFDやシステム構成図を描いて可視化する。第二に「何がうまくいかないか」。ブレインストーミングやSTRIDE分析で脅威を洗い出す。第三に「我々はそれに対して何をするか」。MITRE ATT&CKなどを参考に攻撃手法を具体化し、リスク評価で優先順位を決める。第四に「十分な仕事ができたか」。対策を設計に反映し、振り返る。このサイクルを繰り返すことが重要である。

DFD、STRIDE、リスク評価で実践する脅威モデリング

後半では、架空のECサイトを題材に、脅威モデリングの実践手順が示された。食品・日用品を扱う中規模ECサイトで、AWS EKS、Istio、ArgoCD、RDS、ElastiCacheなどを利用し、外部連携としてStripeによる決済、配送API、OIDC認証を持つ想定である。セッションでは、このシステムを例にDFDの作成、STRIDE分析、リスク評価までの流れが解説された。

4つの質問から具体的にステップに落とし込む

最初のステップは、DFD、すなわちデータフローダイアグラムを書くことである。中村氏は、図を書くことでシステムの全体像が見え、エンジニア以外のメンバーも参加しやすくなり、どこを守るべきかを視覚的に把握できると説明した。「何を作っているのかを絵にすることで、システムの全体像が見えてきます。コードを読めなくても参加できるので、エンジニア以外のメンバーも巻き込めます」と中村氏は語った。DFDは、データストア、外部エンティティ、プロセス、データフロー、信頼境界という5つの要素で表現される。

まず事業レベルのコンテキストダイアグラムを作成し、顧客、IDP、Stripe API、配送APIなどの外部エンティティとの関係を整理した。さらにLevel 0のDFDに展開し、Frontend Pod、Order Pod、Payment Pod、Inventory Pod、RDSなどの主要コンポーネントとデータの流れを整理する。

ここで重要なのが信頼境界である。インターネット、EKSクラスター、AWSマネージドサービス、外部サービスといった境界を引くことで、データがどの境界からどこへ流れているのかが明確になる。境界をまたぐフローは攻撃面になりうるため、脅威の入り口を可視化できる。クラウドネイティブ環境ではワークロードや通信経路が動的になりやすいため、境界とデータフローを明示することが対策の出発点となる。

次に行うのがSTRIDE分析である。STRIDEは、なりすまし（Spoofing）、改ざん（Tampering）、否認（Repudiation）、情報漏洩（Information Disclosure）、サービス不能（Denial of Service）、権限昇格（Elevation of Privilege）に対応する脅威分類である。セッションでは、これに水平移動（Lateral Movement）を加えたSTRIDE-LMにも触れられた。たとえば、ユーザーからフロントエンドへの大量HTTPリクエストはサービス不能、フロントエンドからRedisへのカート情報改ざんは改ざんとして整理できる。

中村氏は、STRIDE-per-Elementの考え方も紹介した。これは、DFDの要素タイプごとに適用すべきSTRIDEカテゴリを整理する方法である。要素ごとに見るべき脅威カテゴリがわかるため、チェックシートのように使える。さらに、MITRE ATT&CKを補助的に使えば、洗い出した脅威を実際の攻撃手法として具体化しやすくなる。

最後に、リスク評価によって優先順位を決める。中村氏は、攻撃者の動機・能力・機会、脆弱性、ビジネスインパクトを3段階で評価し、最大27点のスコアとして扱う方法を紹介した。絶対的な正解を求めるのではなく、チーム内で相対的な優先順位に合意するための方法である。

具体例として示されたのが、カート改ざんである。攻撃者がSSRF経由でVPC内のRedisへ直接接続し、SETコマンドでカート単価を改ざんして低額で決済を成立させる、というシナリオである。前提脆弱性として、サーバ側で価格を再計算していないこと、Redis AUTHが未設定であること、NetworkPolicyが未設定であることなどが挙げられた。この場合、対策前のリスク値は2×2×3＝12となる。対策として、サーバ側で価格を再計算し、Redis Auth TokenやIAM認証を利用し、NetworkPolicyで通信を制限することで、対策後のリスク値は2×2×1＝4に下がる。

このように、脅威モデリングとリスク評価を組み合わせることで、対策の効果を定性的ながらも数値で示せる。すなわち各々の脅威に対して、どのような対策を行い、その結果リスクがどう変化したのかをチームで共有しやすくなるというわけだ。

セッションの最後に、中村氏は明日から実践できるステップを示した。まずDFDを書く。次に信頼境界を引き、STRIDE分析を1周する。そしてリスクアセスメントでリスク値順に並べ、上位のリスクから対策する。このサイクルを定期的に回すことで、自分たちのサービスにどのようなリスクがあり、どこから対処すべきかが見えてくる。

重要なのは、自分たちのシステム、資産、脅威、脆弱性を結び付け、攻撃シナリオとして理解することである。中村氏のセッションは、脅威ベースアプローチを通じて、限られたリソースの中でもセキュリティ対策の優先順位を説明可能にする実践的な方法を示したと言えるだろう。