EASMとは？脆弱性から会社を守る方法

会社のWebサイトは管理していても、数年前のキャンペーンサイトや、検証用に作ったクラウドサーバーまで把握できているでしょうか。

使わなくなったサービスが、インターネット上では動き続けていることがあります。更新されないまま残っていれば、攻撃者に狙われる入口になりかねません。

こうした「会社が見落としている入口」を、外から確認する取り組みが EASM（外部攻撃対象領域管理） です。

この記事では、専門知識のない方にもイメージしやすいように、EASMの役割、ほかの対策との違い、導入の進め方を説明します。後半では、SMART AI WATCHERに実装した脆弱性評価機能と、日々の管理に役立つメリットも紹介します。

1．EASMは、会社の「外から見える入口」を点検する取り組み

EASMは、External Attack Surface Managementの略です。インターネットから見える自社のサーバーやサービスを探し、セキュリティ上の問題がないか継続的に確認します。

建物に例えるなら、社内の設備台帳を確認するだけでなく、建物の外を歩いて、忘れられた出入口や閉め忘れた窓がないか調べるようなものです。

ここでいう「入口」は、Webサイトだけではありません。

確認する対象	例えば、こんな状態を見つける
Webサイト・ドメイン	終了したキャンペーンサイトに古いソフトウェアが残っている
VPN装置	社外から接続するための機器に、未修正の弱点がある
リモート接続の窓口	遠隔操作用の接続口が、必要以上に外部へ公開されている
クラウドストレージ・API	社内向けのデータや機能が、設定ミスで公開されている
メール関連の設定	自社ドメインのなりすまし対策に不足がある
SSL/TLS証明書	Webサイトの安全な通信に使う証明書の期限が切れている

確認できる範囲や詳しさは、利用するサービスによって異なります。また、外部に公開されていること自体が問題とは限りません。公開する必要があるか、適切に保護されているかを確認することが大切です。

特に役立つのが、管理台帳に載っていない資産の発見です。例えば、部署が独自に作った検証サイトや、引き継ぎから漏れたサーバーなどが該当します。こうした会社の管理が行き届かないIT利用は「シャドーIT」と呼ばれます。

ただし、EASMですべてのシャドーITが見つかるわけではありません。外部から手掛かりを得られないサービスは、社内での棚卸しなどで補う必要があります。

2．なぜ、普段の資産管理だけでは足りないのか

普段の資産管理は、会社が把握している機器やサービスを出発点にします。一方、攻撃者は、会社の台帳に載っているかどうかに関係なく、外から接続できる場所を探します。

この視点の違いによって、管理の抜けが生まれます。

例えば、次のようなケースです。

これは説明のための例ですが、問題はソフトウェアの古さだけではありません。「誰が管理するのか」「いつ停止するのか」が曖昧なことも原因です。

クラウドや外部サービスを使えば、短時間で新しい環境を作れます。その便利さに合わせて、公開状況や管理担当者を継続的に確認する仕組みも必要になります。

「管理しているつもりの資産」と「実際に外から見える資産」のずれを見つけること。 これがEASMの出発点です。

3．EASMは「見つけて終わり」ではない

EASMは、次の5つを繰り返す運用です。

段階	やること	押さえるポイント
① 発見する	自社のドメインなどを手掛かりに公開資産を探す	台帳にない資産も確認する
② 管理者を確認する	自社の資産かを確かめ、管理部署や用途を整理する	他社の資産を誤って含めない
③ 優先順位を決める	弱点、公開状況、業務への影響を確認する	検出件数や点数だけで判断しない
④ 対応する	更新、設定変更、公開停止などを行う	担当者と期限を決める
⑤ 再確認する	問題の解消や、新しい公開資産の有無を確かめる	次の発見と対応につなげる

例えば、同じ「古いソフトウェア」でも、外部から攻撃可能な重要システムと、接続が厳しく制限された環境では対応の緊急度が異なります。

実際に悪用されている弱点があるか、顧客情報を扱うか、停止すると業務にどの程度影響するかも含めて判断します。

ツールを選ぶ際も、検出機能に加えて、発見した問題を誰が受け取り、どう直すかを決めておくことが欠かせません。

4．脆弱性診断とは、何が違う？

「すでに脆弱性診断を受けているから、EASMは不要では？」と思う方もいるかもしれません。

脆弱性とは、ソフトウェアやシステムにある、攻撃に悪用され得る弱点のことです。EASMと脆弱性診断は、この弱点を管理するうえで役割が異なります。

対策	主に答える問い	活用する場面
EASM	外から見える自社の資産はどこにあり、どんなリスクがあるか？	未把握の公開資産の発見、公開状況の継続確認
脆弱性診断	このシステムには、どんな弱点があるか？	指定したシステムの詳しい点検
ペネトレーションテスト	想定した攻撃で、どこまで侵入や被害が成立するか？	合意した範囲での実践的な検証

例えば、EASMで見つかった古いサイトを脆弱性診断の対象に加え、重要なシステムについてはペネトレーションテストで対策の有効性を確認する、という使い方ができます。

診断やテストの範囲、深さ、頻度は契約や目的によって異なります。EASMだけで詳しい診断を代替できるとは限りません。

5．関連用語は「何を見るか」で整理する

セキュリティ分野には似た略語が多く登場します。最初は、次の違いを押さえれば十分です。

用語	わかりやすくいうと
ASM	攻撃の入口になる領域を把握・管理する取り組み全般。国内では外部公開資産の管理を指す場合もある
EASM	そのうち、インターネット側から見える資産を確認する取り組み
CAASM	資産管理やセキュリティ製品の情報を統合し、社内も含めた資産と管理の抜けを把握する仕組み
DRPS	偽サイト、漏えいした認証情報など、社外のデジタルリスクを監視するサービス
CTEM	攻撃にさらされる状態を継続的に評価し、重要な問題から改善する運用の枠組み

まずは「外から見えるものをEASMで確認し、社内の資産情報やほかの対策と組み合わせる」と考えると理解しやすくなります。

6．国内でも、公開資産を把握する重要性が高まっている

経済産業省は2023年5月に「ASM導入ガイダンス」を公表し、外部から得られる情報で自社のIT資産を発見・管理する考え方を整理しています。[1]

また、取引先を含めた対策状況を可視化する「サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度）」の検討も進んでいます。経済産業省の公表情報では、★3・★4は2026年度末頃の申請受付開始を目指し、★5は別途具体化を進める位置づけです。[2]

こうした取引先への説明でも、資産の把握や脆弱性への対応記録は役立ちます。ただし、EASMの導入だけで制度の要求を満たせるわけではありません。制度全体の要求事項と、自社の実際の運用を照らし合わせる必要があります。

※制度の予定や要件は変更される場合があります。対応時には公式情報を確認してください。

7．中小企業は、どこから始めればいい？

最初から全社・全拠点を対象にする必要はありません。まずは自社の主要なドメインや重要サービスから始め、対応できる範囲を広げていきます。

ステップ1：自社が把握している情報を集める

会社のドメイン、Webサイト、公開サーバー、VPN装置、クラウド上の公開サービスを一覧にします。管理担当者や委託先も、分かる範囲で記録します。

ステップ2：外から見える資産と照合する

EASMサービスの試用や専門家の支援を活用し、一覧にない資産が見つからないか確認します。見つかった候補は、そのまま自社資産と決めつけず、契約や管理部署と照合します。

ステップ3：重要な問題から対応する

使っていないサイトは停止する、必要な機器は更新する、不要な公開設定を閉じるなど、対象に合った対応を行います。外部公開の状況、悪用の実績、業務への影響を考慮して順番を決めます。

ステップ4：担当者・期限・確認方法を決める

「担当部署に連絡した」で終わらず、いつまでに直し、誰が解消を確認するかまで決めます。その記録を、次回の点検にも使います。

ステップ5：変更を継続的に確認する

新しいサービスの公開、担当者の異動、契約終了に合わせて台帳を更新し、定期的な確認を続けます。監視頻度は、資産の重要性や変化の多さに合わせて設定します。

なお、子会社や取引先まで調査範囲を広げる場合は、管理責任と許可された範囲を事前に確認します。第三者のシステムに対する能動的な検査を、自己判断で行わない運用が必要です。

8．外からの確認に、端末の内側の情報を組み合わせる

EASMでは、外部から得られる情報を基にリスクを見つけます。しかし、ソフトウェアの正確な版数や、端末の利用者、修正の実施状況は、外からの情報だけでは判断しにくい場合があります。

そこで役立つのが、端末の内側から集める情報です。

視点	主に確認できること	単独では把握しにくいこと
外から見るEASM	公開されている資産、外部から見える設定や弱点の兆候	内部の詳細な構成、利用者や担当部署
端末の内側から見る資産情報	導入ソフトウェア、取得可能な版数、端末や利用者の情報	管理対象外の機器や、未知の公開資産
両方を組み合わせる	公開状況と端末の情報を照合した対応判断	正確な関連付けと、対象範囲の確認は必要

例えば、「インターネットに公開された資産に、実際に悪用が確認されている脆弱性が該当する」と確認できれば、優先して対応する根拠になります。

ただし、公開IPアドレスだけで端末を特定できるとは限りません。クラウド構成や中継機器も考慮し、正しく関連付ける必要があります。

9．SMART AI WATCHERの脆弱性評価機能を実装しました

SMART AI WATCHERでは、端末のソフトウェア情報と公開の脆弱性情報を組み合わせる、脆弱性評価の主要機能を実装しました。 2026年11月3日版の実装仕様書では、情報の取得、端末との照合、優先度・対応期限の判定、メール通知、管理画面への反映が完了しています。

「このソフトウェアに弱点がある」という情報から、「自社のどの端末を、どの順番で確認・対応すればよいか」までつなげる機能です。

メリット1：外部EASMを契約していなくても、端末の評価から始められる

本機能は、外部EASM連携を必要とせず、標準機能として単独で動作します。Windows・Mac・Linuxの対応エージェントが収集したソフトウェア名や版数を、公開の脆弱性情報と照合します。

例えば、ブラウザーの弱点が公表されたときに、担当者が端末を1台ずつ調べる作業を減らし、該当する可能性のある端末を管理画面から確認できます。

外部公開資産の発見はEASM、管理対象端末のソフトウェア評価はSMART AI WATCHERという役割分担です。本機能が、EASMによる未把握の公開資産の発見を代替するわけではありません。

※利用には対応するエージェント、管理者権限、資産管理のライセンス、および機能の有効化が必要です。

メリット2：「深刻度の点数」だけに頼らず、対応順を決められる

脆弱性が多数見つかると、すべてを同時に直すのは困難です。SMART AI WATCHERでは、次の情報を組み合わせ、緊急・高・中・低の優先度と対応期限を付けます。

情報・指標	判断に使う内容
NVD	脆弱性の概要、深刻度、影響する製品と版数の情報
CNAの影響製品情報	CVEを割り当てる組織などが示す製品・版数の情報。NVDから取得するデータを利用して照合を補完
CISA KEV	実際の悪用が確認されている脆弱性かどうか
FIRST EPSS	今後30日間に実環境で悪用が観測される可能性の推定値
CVSS	脆弱性の技術的な深刻度
端末ごとの設定	外部公開の有無、業務上の重要度を管理者が登録

KEVは悪用が確認された事実、EPSSは今後の悪用に関する予測です。EPSSは、自社が攻撃される確率そのものではありません。[3][4]

例えば、KEVに掲載された脆弱性に該当し、管理者が「外部に公開」と設定した端末は、緊急・対応期限3日という初期ルールで扱います。 外部公開の自動検出は現時点では行わず、管理者が端末ごとに設定します。

優先度	主な判定条件（初期設定）	対応期限の初期値
緊急	KEV掲載、かつ外部公開と設定された端末	3日
高	KEV掲載、またはEPSSが10%以上かつCVSSが7.0以上	14日
中	上記に該当せず、CVSSが7.0以上、またはEPSSの順位が上位10%相当	30日
低	上記以外	期限なし

ランサムウェアでの悪用が確認されている場合や、重要度を高く設定した端末では、優先度を引き上げます。しきい値や期限は組織ごとに変更でき、判定理由も記録されるため、対応順の根拠を確認できます。

なお、この日数は製品の初期設定であり、すべての企業に共通する安全基準ではありません。自社の業務や対応体制に合わせて調整します。

メリット3：新しい問題と対応漏れを、メールで把握できる

管理画面を毎日開く作業だけに頼らず、メール通知で確認のきっかけを作れます。

毎時の照合時：取り込み後に新たにKEVへ追加された脆弱性が端末に該当する場合や、緊急・高の新しい所見を通知します。「要確認」は即時通知の対象から除きます。
毎日9時20分（日本時間）：期限超過の所見や、中・低・要確認の新しい所見をまとめて通知します。
期限超過は継続して通知：解消するまで日次の通知対象となるため、未対応の問題を追いやすくなります。

ここでいう通知は、データ取得と毎時の照合を経て行われます。脆弱性の公表と同時に届くものではありません。運用にはメール送信と宛先の設定が必要です。

メリット4：端末・ソフトウェア・CVEをつないで確認できる

管理画面の「資産情報 → 脆弱性」では、優先度別の件数、KEVに該当する端末数、対応期限を過ぎた所見を確認できます。

一覧は、端末名、ソフトウェア名、CVE番号、優先度などで絞り込めます。CVEは脆弱性を識別する番号です。CVEの詳細から影響する製品と版数、自社で該当する端末を確認し、端末の詳細からその端末の所見を確認できます。

さらに、所見一覧のCSV出力にも対応しています。担当部署への確認依頼や、社内の管理資料を作る際の材料として活用できます。

更新後の資産情報を再照合し、該当しなくなった所見を解消済みにする処理も実装しています。この処理はテストで確認済みですが、添付仕様書の時点では、実機のアップデートによる一連の解消確認は未実施です。

メリット5：判定の確かさが分かり、確認作業を整理できる

同じ名前の別製品や、取得できない版数まで一律に「脆弱性あり」と扱うと、確認作業が増えてしまいます。

SMART AI WATCHERでは、製品の対応表、製品名・発行元の情報、版数などに基づき、照合結果の確かさを「確定」「推定」「要確認」に分けて表示します。「要確認」はダッシュボードでも別枠となり、即時通知の対象にはしません。

ここでいう「確定」は、製品照合の確かさを表す区分です。実際に攻撃が成立することを実証したという意味ではありません。

また、影響する製品の情報がなく照合できないCVEは、その件数を表示します。「判定できなかったもの」と「問題がないもの」を区別できることも、確認の抜けを把握するうえで役立ちます。

メリット6：公開情報の更新を自動化し、情報の古さにも気づける

公開の脆弱性情報は、管理サーバーが定期的に取得します。初期設定では、NVDは2時間ごと、KEVは6時間ごと、EPSSは1日1回の更新です。端末情報との照合は1時間ごとに行います。

担当者が各情報源を手作業で巡回する負担を減らしながら、管理対象端末に関係する問題を確認できます。

取得に失敗した場合も、保存済みのデータを使って判定を継続し、更新失敗を画面に表示します。最終更新が3日以上前の場合は強調されるため、情報が古い状態を見過ごしにくくなります。ただし、取得に失敗している間は、最新の脆弱性情報が反映されない場合があります。

NVDの詳細情報が不足する場合に備え、今回の実装ではCNAが示す影響製品・版数の情報でも照合を補います。NVDが詳細情報の付与に優先順位を設けていることを踏まえた対応です。[6]

現時点での対象範囲と、今後の拡張

今回実装した機能を適切に活用するため、次の範囲も押さえておきましょう。

項目	現在の対応状況
Windows・Mac・Linuxのソフトウェア情報との照合	対応エージェントからの収集・照合を実装済み
Linuxの判定	修正済みでも古い版数を維持する配布方式を厳密に判定できないため、すべて「要確認」。公開から2年以内のCVEを対象とし、Linuxカーネルは照合対象外
JVN iPediaによる補完	現行実装では未使用。脆弱性の概要は英語で表示
外部公開の判定	管理者による手動設定。外部EASMなどによる自動判定は未着手
管理者による「要確認」の確定・却下画面	未着手
AIによる説明文の生成	未着手。現在はルールに基づく判定理由を記録
SCS評価制度向け専用レポート	未着手。現在は所見一覧のCSV出力に対応
オフライン更新パッケージ	未着手。完全オフラインで最新データを更新する仕組みは今後の拡張

対象となるエージェントの版は、Windows A2260以降、Mac A2321以降、Linux 1.1.21以降です。エージェントのない機器や、情報を収集できないソフトウェアは評価に限界があります。

また、脆弱性評価は更新・設定変更の判断を支援する機能です。自動パッチ適用や、外部からの侵入テストを行うものではありません。

10．まずは「公開しているもの」と「管理する人」を確認しよう

EASMの出発点は、自社がインターネットからどう見えているかを知ることです。

管理台帳にないサービスを見つけ、必要なものは適切に保護し、不要なものは停止する。その後も、新しい公開や設定変更を確認し続けます。

最初の一歩として、自社のドメインと公開サービスを一覧にし、「何のために使っているか」「誰が管理しているか」を確認してみてください。

外から見える入口と、端末の内側の情報。その両方をつなげることで、発見した問題を具体的な対応へ進めやすくなります。