この記事は株式会社エス・エム・エスAdvent Calendar 2025 vol.1の12月4日の記事です。
エス・エム・エスで全社SREというロールで活動しているSecurity Hub芸人の山口（@yamaguchi_tk）です。おすすめのAWSサービスは営業です（いつもお世話になっています）。
はじめに
私が所属している全社SREチームで監視基盤の入れ替えを行った際、そのタイミングで監視設定自体も見直しました。 その見直しの中で、脅威モデリングの考え方をインフラレイヤーの監視設計に応用して整理を行いました。
本記事では、そのときに実施した手法をできるだけ具体的に言語化し、同じように監視を見直したい方の参考になることを目指して紹介します。
背景
オンプレからAWSにLiftした際にオンプレと同じ構成でAmazon EC2を構築し、監視もZabbixを利用してオンプレと同じ構成で構築しました。 Zabbix自体のアップデートやAmazon EC2、Amazon RDSのアップデートを何度か実施した結果、アップデートの検証工数やZabbix自体の運用工数が課題になってきたため、フルマネージドサービスであるAmazon CloudWatchへの移行を行いました。
監視設定の整理の目的
監視設定自体はZabbixの基本テンプレートをベースに一部をカスタマイズして利用しており、特にメトリクスベースのアラートがシステムの実態と合っておらず無駄なアラートが発生している状況でした。
無駄と判断した監視設定は、発生のたびに削除したり閾値や監視するメトリクス自体を見直ししたりしていましたが、発生都度の対応ではどうしてもいたちごっこになってしまいます。 そこで、Amazon CloudWatchへの移行を機に方針を決めて監視設定を整理することにしました。
インフラレイヤーの監視設定への応用
インフラレイヤーの監視設定に脅威モデリングの手法を応用できないか検討し、実際に行ってみました。 これは古典的なセキュリティ原則の「可用性（Availability）」にフォーカスして脅威モデリングを実施した、と言えるかもしれません。
脅威モデリングについて
脅威モデリング（Threat Modeling）は、システムやアプリケーションのセキュリティを設計段階から考慮するための手法です。
アダム・ショースタック氏の以下のフレームワークが有名です。 Shostack’s Four Question Framework for Threat Modeling
- 何に取り組んでいるのか？ What are we working on?
- 何が問題を引き起こす可能性があるか？ What can go wrong?
- それに対して何をするのか？ What are we going to do about it?
- 十分によい対応をしたか？ Did we do a good job?
具体的には、DFD等でシステムの構成要素を可視化し、「起こったら困ること」という視点で脅威を特定します。 特定した脅威をSTRIDE等でカテゴリ分けし、その発生確率をアタックツリーで分析し影響度と併せてリスク評価することで、セキュリティリスクを事前に把握し、適切な対策を検討することができる手法です。
実施手順
ここからは、実際に行った手順を紹介します。
発生したら困ることを洗い出す
まず、AWSの構成図を作成します。
1つ目の構成図（EC2版）には、オンラインWebサービスと同じインスタンスで処理されるバッチ処理が含まれています。
2つ目の構成図（AWS Fargate版）には、オンラインWebサービスとバッチ処理、非同期処理が含まれています。
AWSの構成図を見ながら、起こったら困ることを基準に付箋などを張ったりして洗い出していきます。
例示したAWSの構成図の場合だと、以下のようになります。
- オンラインサービス系
- オンラインサービスが応答しない
- オンラインサービスの応答が遅延している
- バッチ系
- バッチが処理されない
- 非同期処理系
- 非同期処理が処理されない
- 非同期処理が遅延している
処理フローを可視化する
洗い出した起こったら困ることに対して、その処理（オンラインサービス系／バッチ系／非同期処理系）がどのようなシステムフローで実行されているかを、AWS構成図ごとに可視化していきます。
作成したAWS構成図から必要な処理フローを抜き出して構成します。 以下に上で例示したAWS構成図での可視化例を示します。
オンラインサービス系(EC2)
バッチ系(EC2)
オンラインサービス系(Fargate)
バッチ系(Fargate)
非同期処理系(Fargate)
発生要因を分析する
洗い出した起こったら困ることに対して、処理フロー図を見ながらその発生要因を抽象度高めで洗い出していきます。 ここでは「xxxというエラーでyyyが発生して処理が異常終了する」という詳細な記載ではなく、「処理が正常終了しない」といった抽象度高めの粒度で洗い出しを行います。
洗い出した例を図で示します。
オンラインサービス系発生要因(EC2)
バッチ系発生要因(EC2)
オンラインサービス系発生要因(Fargate)
バッチ系発生要因(Fargate)
非同期処理系発生要因(Fargate)
直接的に監視できるところを探す
分析で洗い出した発生要因に対して、一番直接的に観測できる箇所・監視内容や、処理の急所（ここを監視すればシステムフローの下流の異常が検知できる箇所・監視内容）を処理フローから探します。
洗い出した例を図で示します。
オンラインサービス系監視ポイント(EC2)
バッチ系監視ポイント(EC2)
ハートビート系処理でログを監視する場合は、ハートビート系処理をどこで動作させるのか、バッチ処理のログをどこに出力するのか、といった点もあわせて考慮する必要があります。
オンラインサービス系監視ポイント(Fargate)
バッチ系監視ポイント(Fargate)
非同期処理系監視ポイント(Fargate)
バッチ系監視ポイント(Fargate)では、以下の理由でAWS Step Functions以降を監視することで全体をカバーしています。
- Throttlingが発生する可能性がある場合は通常Amazon SQS等を挟むため、このシステムはThrottlingが発生する状況になることは少ないと考えられる。
- Amazon S3とAmazon EventBridge間でThrottlingが発生してもAWS Step Functions自体は起動することを期待している。
- Amazon EventBridgeの定時処理は少なくとも1回は起動することを期待している。
まとめ
監視設定の整理に脅威モデリングの手法を応用することで、以下の効果が得られました。
- システムの実態に合った最低限必要な監視設定が可能になります。
- 「起こったら困ること」を起点にすることで、無駄なアラートを削減できます。
- 処理フローを可視化することで、監視ポイントの選定根拠が明確になります。
この手法は既存の監視設定の見直しだけでなく、新規システムの監視設計にも応用できると考えています。
