EASMとIASMは「両輪」であるべきなのか？統合運用とコスト最適化の現実解
はじめに
Attack Surface（攻撃対象領域）という言葉を、近年セキュリティ関連のニュースやセミナーなどで耳にする機会が増えてきたのではないでしょうか。
DXの加速、テレワークの普及、そしてクラウド利用の拡大。企業のIT資産がオフィスの壁を越えて広がり続ける中で、従来の境界防御だけでは対応しきれない課題が浮き彫りになってきました。 私たちはこれまで3回にわたり、この変化した環境において、どのように資産を把握し守っていくべきか、そのアプローチについて解説してきました。
第1弾ではASMの全体像と必要性『ASM(Attack Surface Management)とは？その概要と導入ステップについて解説～』
第2弾では外から見える攻撃領域面：EASM（『外部(External)ASMとは？その内容について解説 ～EASM編～』）
そして第3弾では内から見える攻撃領域面：IASM（『内部(Internal)ASMとは？その内容について解説 ～IASM編～』）について掘り下げてきました。
シリーズ最終章となる今回のテーマはEASMとIASM、これらの「統合」です。
ASMへの取り組みを検討、あるいは始めたばかりの企業において、新たな壁に直面するケースが出てきています。
これらの課題の多くは、外部視点（EASM）と内部視点（IASM）が分断されていることにあります。
片方の目だけでは、距離感がつかめないのと同じように、セキュリティにおいても「外」と「内」の両方の視点が揃って初めて、リスクを立体的に捉えることが可能になります。
本記事では、EASMとIASMを統合することの真価と、多くの担当者が頭を悩ませる「コストとリソース」の壁をどう乗り越えるか、そしてその先にある「CTEM」という未来について、実践的な解を提示します。
1章 なぜ片方だけでは不十分なのか？
「EASMツールを入れたから安心だ」、「資産管理台帳は完璧だから問題ない」、「内部ネットワーク内のサーバーや特権アカウントはすべて把握できている」
もしそう考えているとしたら、それは非常に危険な状態かもしれません。なぜなら、単独の運用には致命的な「死角」が存在するからです。
EASMだけの限界
EASMの取り組みでは、インターネット越しに攻撃者と同じ視点で自社の資産を調査します。例えば、公開ポート、SSL証明書、サブドメインなどを次々と発見します。 しかし、EASMには決定的な弱点があります。それは「中身が見えない」ことです。
例えば、EASMが「脆弱性のある古いWebサーバー」を見つけたとします。
それは、顧客の個人情報が詰まった「本番サーバー」でしょうか？
それとも、中身が空っぽの「廃棄予定の検証機」でしょうか？
外部からの調査だけでは、この区別がつきません。その結果、セキュリティ担当者はすべての検知に対して優先度を上げて扱わざるを得なくなります。検証機1つの対応に追われている間に、本当に守るべき本番サーバーへの攻撃を見逃してしまう――。これが、アラート過多による現場の疲弊を招く原因です。
IASMだけの限界
一方、IASM（または従来の資産管理ツール）はどうでしょうか。エージェントなどを導入し、OSのバージョン、インストールされたアプリ、パッチ適用状況など、「資産の実態」を詳細に把握します。 しかし、ここにも落とし穴があります。IASMは「外からの見え方が分からない」のです。
例えば、IASM上で「パッチ未適用のサーバー」があるとします。
それは、インターネットに直接さらされている危険な状態なのか？
それとも、厳重なファイアウォールの内側にあり、インターネットからはアクセス不可能なのか？
内部の設定情報だけを見ていても、実際の攻撃リスク（外部からのアクセスのしやすさや誤って外部に公開されていないか）までは客観的な判断ができません。また、そもそも管理台帳に載っていない、またはエージェントが入っていないものは、IASMのスコープから完全に抜け落ちてしまいます。
EASMとIASMの統合
この2つの違いは、攻撃者が「建物の外にいるか、中にいるか」の違いで整理すると明確です。どちらも攻撃者にとっての攻め入る隙であることに変わりはありません。
EASM（侵入前の視点）： インターネットという「外」から見て、建物への「侵入口」が開いていないかを探す視点です。 （ポートは開いているか？ ID/Passが推測可能であり、認証試行可能な管理画面はないか？）
IASM（侵入後の視点）： もし内部ネットワークに侵入された場合、あるいは内部に攻撃者がいた場合（内部不正や不法侵入など）、そこから「どれだけ目的に向かって進行できるか」を探す視点です。 （サーバー内に放置された特権IDはないか？ 隣の重要サーバーへ移動できる脆弱性はないか？）
セキュリティ対応において重要なのはトリアージ（優先順位付け）です。
「侵入口が開いている（EASM）」かつ「その先に重要なデータや致命的な脆弱性がある（IASM）」。
この2つが繋がったルートこそが、攻撃者が狙う「攻撃経路（Attack Path）」となります。 単に「穴がある」だけでなく、「その穴が致命傷に繋がるか」を判断するために、外と内の情報を統合する必要があるのです。
2章 EASMとIASMの統合アプローチ
では、具体的にどのようにこの2つを統合し、運用に乗せていけばよいのでしょうか。単に2つのツールを並べて画面を見比べるだけでは意味がありません。データの「意味」を統合するプロセスが必要です。
データの突合によるシナジー効果
統合の最大のメリットは、リスク判断の精度が劇的に向上することです。以下のシナリオで考えてみましょう。
【シナリオ：Apache HTTP Serverに緊急の脆弱性が公開された場合】
EASMの視点： 「自社のグローバルIPアドレスのうち、50個でポート80/443が開いている」→ これら全てが疑わしい。
IASMの視点： 「把握済みのサーバー1,000台のうち、該当バージョンのApacheを使っているのは200台ある」→ これら全てが修正対象。
それぞれ個別に対応しようとすると、膨大な工数がかかります。しかし、ここで両者の情報を突き合わせます。
統合された視点：
EASMで「ポートが開いている（＝外部から攻撃可能）」なグローバルIPアドレスを特定。
そのIPに紐づくサーバーをIASMで照合し、「該当バージョンかつ、顧客DBに接続されている」ものを抽出。
結果： 「外部から攻撃可能で、かつ実被害が出るサーバー」はわずか3台だった。
このように情報を重ね合わせることで、「今すぐ対応すべき3台」と「来週の定期メンテで対応すればよいその他」を明確に分けることができます。これが統合の威力です。
シャドーITを管理化するサイクル
EASMで見つかる「所有者不明の資産」への対応も変わります。 これまでは「見つかったからポートを閉じろ」と現場に指示するだけの一過性の対応になりがちでした。統合運用では、以下のようなサイクルを回すことができます。
発見： 未知のサブドメインやクラウドインスタンスを検知。
特定： 社内ネットワークのログ等と照合し、利用部門を特定。
正規化： その資産をIASM（資産管理台帳）に正式登録し、エージェントを導入するか、あるいは明確に廃棄させる。
「未把握の資産」を「管理対象資産」へと昇華させるこのプロセスこそが、継続的なセキュリティ向上には不可欠です。
3章 ASMの高い「コスト」との付き合い方
「統合が理想的なのはわかる。しかし、予算も人も足りない」
これが多くの担当者の本音ではないでしょうか。 ASMツールは高機能なものほどライセンス費用がかさみ、検知数が増えれば対応工数（人件費）も跳ね上がります。ここでは、現実的なコスト最適化の戦略を提示します。
戦略1：資産のティアリングによる「選択と集中」
全ての資産を最高レベルで守ろうとすれば、コストは膨大に膨れ上がります。守るべき資産にランク（ティア）を付ける戦略が有効です。
Tier 1（最重要資産）：
対象：顧客データ、決済システム、メインブランドのWebサイトなど。
対策： リアルタイムのEASM監視 ＋ エージェント型IASM ＋ 定期的なペネトレーションテスト。コストを惜しまず投資する領域です。
Tier 2（重要資産）：
対象：社内業務システム、開発環境など。
対策： 日次・週次のEASMスキャン ＋ エージェントレスなIASM（API連携など）。
Tier 3（その他一般資産）：
対象：検証用の一時的な環境、重要度の低いランディングページ（LP）など。
対策： ライトな資産管理のみ。異常検知時のみ詳細調査を行う。
このようにスコープを定義し優先付けすることで、高価なツールのライセンス数を適正化し、運用チームのリソース配分を最適化できます。
戦略2：「Attack Path（攻撃経路）」思考への転換
「システムの脆弱性をゼロにする」という目標は極めて難しいです。代わりに「攻撃経路（Attack Path）を断つ」ことを目指します。
たとえ内部に脆弱なサーバーがあったとしても、それがインターネットから到達不可能で、かつ重要資産への踏み台にもならない孤立した環境であれば、リスクは低いと判断できます。 EASMとIASMの情報を組み合わせ、「攻撃者が重要資産に到達できるルート」上に存在する脆弱性だけを最優先で潰す。
この「要所」を押さえるアプローチが最もコストパフォーマンスの高い防御策となります。
戦略3：自前主義からの脱却（Managed ASMの活用）
「ツールは買ったが、使いこなせるエンジニアがいない」
この場合、無理に自社運用にこだわると、かえって高くつきます。 最近では、ツールの提供だけでなく、専門のアナリストが検知内容を精査し、「本当に対応が必要なもの」だけを通知してくれる「Managed ASM」サービスも増えています。 社内で専任者を1人雇うコスト（採用費・教育費・給与）と比較した場合、外部のプロに運用ごと任せる方が、総保有コストが安くなるケースは多々あります。自社のリソース状況に合わせて、アウトソースを賢く利用することも重要な戦略です。
第4章 将来への展望 ～ASMからCTEMへ～
最後に、少しだけ未来の話をしましょう。 EASMとIASMを統合し、リスクを正確に把握できるようになった後、私たちはどこへ向かうべきなのでしょうか。
その答えとして、米調査会社ガートナー社が提唱し、現在セキュリティ業界の新たなスタンダードとなりつつある「CTEM（Continuous Threat Exposure Management：継続的な脅威露出管理）」というフレームワークをご紹介します。
ASM（Attack Surface Management）という言葉には「管理」が含まれていますが、実際の運用現場では「発見（検知）」まではできても、その後の「対応（修復）」が追いつかないという課題が頻発しています。 脆弱性が1,000個見つかったとしても、リソースは限られており、すべてをすぐに直すことは極めて困難です。結果として、ASMツールが導入されていても、リスクが放置されてしまうケースが後を絶ちません。
ガートナー社が提唱する5つのステップ
CTEMは、この課題に対し、単なる発見だけでなく「ビジネス主導で直しきる」までのサイクルを5段階で定義しています。
Scoping（範囲設定）： ビジネスにとって守るべき重要資産は何かを定義する。
Discovery（発見）： ASMなどのツールを使って弱点を見つける。
Prioritization（優先順位）：発見された問題に対して対応の優先順位を設定する。
Validation（検証）： 「本当に攻撃が通じるのか？」をペネトレーションテスト等などで確かめる。
Mobilization（動員・修復）： 「誰がいつまでに直すか」という組織的な動きを作り出す。
統合ASMこそが、CTEMのエンジンになる
ガートナー社は、このCTEMに取り組む組織は、そうでない組織に比べて「侵害を3分の2削減できる」と予測しています。 そして、このサイクルを回すためのエンジンこそが、今回解説した「EASMとIASMの統合」です。
「外と内」の両方を知っているからこそ、正しい優先順位（Prioritization）を付けることができ、現場を納得させて動かす（Mobilization）ことが可能になります。
おわりに：最初の一歩を踏み出すために
全4回にわたってお届けしたASMシリーズはいかがでしたでしょうか。
サイバー攻撃の手口が日々進化する中、「境界防御」だけで企業を守れた時代は終わりました。守るべき資産がどこにあり、どのような状態で、外部からどう見えているのか。EASMとIASMの両方を持ち合わせることは、もはや推奨事項ではなく、必須条件となりつつあります。
もちろん、いきなり完璧な統合運用を目指す必要はありません。まずは自社の現状を知ることから始めてみてください。 「資産台帳にあるサーバー数」と「EASMツールが検知した外部公開サーバー数」を突き合わせてみる。その数字のズレに気づくことこそが、より強固なセキュリティへの第一歩です。
コストやリソースの制約の中で、いかに効率よく、賢く守るか。 本シリーズが、皆様の組織のセキュリティ戦略を見直すきっかけとなれば幸いです。
関連サービス
