【保守案件】アタックサーフェスの洗い出し方と外部公開資産の点検手順
監修・編集責任者:牛尾 昭昌(株式会社LASSIC 執行役員)

📘 この記事でわかること
- 外部公開アプリ・外部サービス・アカウント・保有データの4つに分けて、アタックサーフェスを整理する見方
- IPAが2026年10月9日に示した点検の流れと、ログの確認を直近1か月からその後3か月へ広げる段取り
- 異常を見つけたときの専門ベンダーへの依頼と、外部公開範囲・認証・アカウント棚卸の見直しへ進む順序
保守で入っている参画先から、「ニュースで不正アクセスが続いているので、うちの外部に出ているものを全部洗い出してほしい」と頼まれました。フリーランスエンジニアとして、管理画面、APIのエンドポイント、使っているクラウドやVPNのアカウントと書き出し始めたところで、どこまでが「外部」なのか手が止まりました。外部から攻撃を受けうる範囲がアタックサーフェスで、数え方が決まらないうちは、洗い出しは進みません。見えている入口から数え始めて、使っている外のサービスまで数えます。
▶ あわせて読みたい
・案件は出荷後も続く?脆弱性の情報を追い続ける手順を解説
・【サプライチェーンリスク】委託先・再委託の事故3実例と案件で確かめる契約・暗号の注意点
・脆弱性対処は12項目のどこから始める?レベル分けで決める着手の手順と開示の考え方
1. アタックサーフェスの意味と4つの範囲
語の使われ方
アタックサーフェスは、攻撃を受けうる範囲を指す言葉です。IPAのAIセキュリティ短信は、AIコーディングエージェントの浸透と、開発工程全般のアタックサーフェス(攻撃を受けうる範囲)化を動向の一つに挙げています1。
ただし、保守の現場で頼まれる点検は、開発工程の話ではなく、動いているシステムの話です。IPAが2026年10月9日に示した点検の資料には、アタックサーフェスという語は出てきません2。
そこでこの記事では、書き手の整理として、外部から攻撃を受けうる範囲を外部公開アプリ・外部サービス・アカウント・保有データの4つに分けて呼びます。IPAの点検項目が、この4つに対応しているためです。
4つの範囲と点検項目
外部公開アプリは、自組織が独自に構築・運用している外部公開アプリケーションやサービスです。IPAは、これがあるかどうかの確認を求めています2。
外部サービスは、クラウドサービスやVPNサービスなど、自組織が利用している外のサービスです2。アカウントについては、作ったはずのないアカウントがないか、削除・無効化されているはずのアカウントが有効になっていないかの確認を求めています2。
保有データは、持っている情報資産です。IPAは、不要な情報は持たないという基本原則のもと、保有する情報資産を正確に把握し、必要最小限にする再点検も必要だとしています2。
図の作成:Remogu編集部。IPAの点検項目を整理したもので、統計データではありません
では、IPAはなぜこの点検を示したのでしょうか。
2. IPAが示した点検の背景
公表事例から見た起点
IPAは、相次ぐ不正アクセスによる漏えい等の事案について、公表事例の傾向から、外部公開しているアプリケーションやサービスの侵害、アカウントの侵害が起点となっていることがうかがえるとしています2。
「うかがえる」は断定ではなく、傾向から見える範囲の見立てです。この記事でも、個別の事案の原因には触れません。
起点として2つが挙がっているため、点検も外部公開アプリ・サービスと、アカウントを軸に組まれています。
起点と点検対象の対応
起点として挙げられた2つは、点検の対象と次のように対応します。外部公開しているアプリケーションやサービスの侵害には、自組織が独自に構築・運用しているものがあるかの確認が当たります2。アカウントの侵害には、作ったはずのないアカウントなどの確認が当たります2。この対応づけは書き手の整理で、IPAが表の形で示したものではありません。
| 起点として見られるもの | 点検の対象 |
|---|---|
| 外部公開しているアプリケーションやサービスの侵害 | 自組織が独自に構築・運用している外部公開アプリケーションやサービス |
| アカウントの侵害 | 作ったはずのないアカウント、削除・無効化されているはずのアカウント |
異常を見つけたときの扱い
点検で異常なログやアカウントを見つけた場合、IPAは速やかにセキュリティインシデントと判定し、専門のセキュリティベンダーに詳細調査を依頼することを強く推奨しています2。
そのため、自分で調べ切る前提では段取りを組みません。作業の範囲と、専門ベンダーへの引き継ぎ方は、参画先と協議して決めます。
Remogu(株式会社LASSIC運営)は、リモートワーク案件特化のエンジニアマッチングで、案件の90%以上がフルリモート可能です3。保守やインフラの案件を探す場面でも使えます。
点検の対象のうち、最初に数えるのは外部公開アプリです。
リモートで参画できる案件を見てみる →
3. 外部公開アプリを数える
独自に構築・運用しているものの洗い出し
最初に数えるのは、自組織が独自に構築・運用している外部公開アプリケーションやサービスです。IPAは、そうしたものがあるかどうかの確認を求めています2。
管理画面やAPIのエンドポイントは、冒頭の依頼で挙がった例です。見えているものから書き出し、参画先に尋ねて足していく形で進められます。
数える単位は、アプリケーションやサービスです。洗い出した一覧が、次のログ確認とパッチ確認の対象になります。
ログは1か月から3か月へ広げる
IPAは、各アプリケーション・サービスのログの異常を、直近1か月、その後3か月と段階的に範囲を広げて確認するよう求めています2。
順番は、直近1か月が先で、3か月が後です。まず直近1か月の異常を確かめ、そのあとに範囲を広げます。
未適用パッチの確認
ログの確認と並べて、各アプリケーション・サービスの構成要素に未適用の脆弱性対応パッチがないかを確かめます。あれば、できるだけ速やかに適用するようIPAは求めています2。
対象はアプリケーション本体に限らず、構成要素に及びます。一覧を作っておくと、パッチの確認はアプリケーションごとの作業になります。
図の作成:Remogu編集部。IPAの点検項目を整理したもので、統計データではありません
次は、自組織で作っていない側の、利用している外部サービスです。
4. 使っている外部サービスを数える
分類が多い外部サービス
外部公開アプリは自分たちで作ったものを数えましたが、外部サービスは借りているものを数えます。IPAは、クラウドサービスやVPNサービスなど様々な分類があることを踏まえて、できる限り網羅的に洗い出すよう求めています2。
冒頭の依頼にあった「使っているクラウドやVPNのアカウント」は、この分類にそのまま当たります。分類が様々だと、見えているサービスから書き出して、抜けを足していく進め方になります。
提供者と利用者で見えるログの違い
外部サービスには、ログの見え方という注意点があります。IPAは、サービス提供者と利用者で確認できるログにも違いがある可能性があるとしています2。
そのため、ログの確認では、利用者として見られる範囲を先に確かめます。見られないログがあれば、提供者側で何が確認できるかを、参画先を通じて尋ねる形になります。
分類ごとに確かめること
外部サービスは分類ごとに、確かめることが少しずつ変わります。クラウドサービスとVPNサービスは、IPAが分類の例として挙げているものです2。どちらも洗い出しの対象に入っているかを確かめ、ログについては提供者側と利用者側で見える範囲が違う可能性を踏まえます2。分類の例はこの2つに限られず、様々な分類があります。
| 分類の例 | 確かめること |
|---|---|
| クラウドサービス | 洗い出しの対象に入っているか、利用者側で確認できるログは何か |
| VPNサービス | 洗い出しの対象に入っているか、提供者側との違いを踏まえてログを確認できるか |
| その他の分類 | 様々な分類があることを踏まえ、洗い出しに漏れがないか |
次は、これらを使うためのアカウントの状態です。
5. アカウントを確かめる
確かめる2つの異常
IPAは、アカウントについて2点の確認を求めています。作ったはずのないアカウントが存在しないか。削除・無効化されているはずのアカウントが有効化されていないか。この2つです2。
書き手の整理として、前者は「誰も把握していない入口」、後者は「閉じたはずなのに開いている入口」と捉えると、見る方向が分かれます。IPAの文面にこの言い方があるわけではありません。
前者は、アカウントの一覧に見覚えのない名前が混じっていないかを見る作業です。後者は、削除や無効化の記録があるアカウントについて、現在の状態を見る作業です。どちらも参画先が持つ一覧や記録との突き合わせが前提で、手元の画面だけでは判断できません。この見方も書き手の整理です。
見られる範囲を先に確かめる
アカウントは、自組織で作った外部公開アプリにも、利用している外部サービスにもあります。外部サービスについては、サービス提供者と利用者で確認できるログにも違いがある可能性があるとIPAは指摘しています2。
そのため、アカウントの作成や有効化の履歴が利用者の側から見られるかどうかは、サービスごとに先に確かめます。見られない履歴があれば、提供者の側で何が確認できるのかを、参画先から尋ねてもらう形で進めます。
棚卸の運用へつなげる
IPAは、利用している外部サービスのその後の対策として、アカウント棚卸の運用見直しなどを挙げています2。一度きりの点検とは別に、棚卸の進め方そのものを見直す対策です。
保守で入っている立場なら、点検で見つけた状態を記録に残しておくと、運用を見直すときの材料になります。何を、いつ、どのサービスで見たのかが残っていれば、次の担当者も同じ手順を踏めます。
図の作成:Remogu編集部。IPAの点検項目を整理したもので、統計データではありません
アカウントを見たあとは、持っているデータの点検に進みます。
保守・運用の経験を活かせるリモート案件をチェックする →
6. 保有データを減らす
不要な情報は持たない原則
点検の最後に残るのは、保有しているデータです。IPAは、不要な情報は持たないという基本原則のもと、保有する情報資産を正確に把握し、必要最小限にする再点検も必要だとしています2。
外部公開アプリや外部サービスの数え上げは、入口を見る作業でした。保有データは、その入口の先にあるものを見る作業です。書き手の整理ですが、入口を絞る点検と、先にあるものを絞る点検が組になっています。
「正確に把握」と「必要最小限にする」は、別の作業です。先に何を持っているかを正確に数え、そのうえで要らないものを減らします。順番は、把握が先で削減が後です。
点検の対象とその後の対策
点検の対象と、IPAが挙げるその後の対策を並べると、次の表のとおりです。外部公開アプリでは外部公開範囲の見直しと、認証機能(多要素認証・パスワード)の強化2、外部サービスではアカウント棚卸の運用見直し2、保有データでは必要最小限にする再点検2が挙がっています。表の形に並べたのは書き手の整理です。
| 点検の対象 | その後の対策の例 |
|---|---|
| 外部公開アプリ | 外部公開範囲の見直し、認証機能(多要素認証・パスワード)の強化 |
| 利用している外部サービス | アカウント棚卸の運用見直し |
| 保有データ | 保有する情報資産の正確な把握と、必要最小限にする再点検 |
減らす判断は参画先が持つ
データを減らす作業は、削除や廃棄を伴います。保守の立場で独断では進めません。何を持ち続け、何を減らすかは参画先が決める事柄で、作業の範囲は参画先と協議して決めます。
手伝う側にできるのは、持っているデータの一覧を整え、判断の材料を渡すところまでです。ここも書き手の整理で、契約の範囲を決めるものではありません。
4つの範囲を見終えたあとに、何が続くのかを次の節で整理します。
7. 点検のあとに続けること
異常があったときの進め方
異常なログやアカウントを見つけた場合、IPAは速やかにセキュリティインシデントと判定し、専門のセキュリティベンダーに詳細調査を依頼することを強く推奨しています2。
保守の立場なら、見つけた時点で原因を調べ切ろうとはしません。どのサービスの、どのログやアカウントで見つけたのかを記録に添えて、参画先に伝える段取りが考えられます。判定と依頼は参画先の判断で、ここは書き手の整理です。
見直しの段階へ進む
点検のあとには、見直しの段階があります。IPAは、外部公開アプリケーションのその後の対策として、外部公開範囲の見直しや認証機能の強化を挙げています2。外部サービスについては、アカウント棚卸の運用見直しなどです2。
点検は、数えて終わりではありません。数えた一覧は、見直しの順番を決める土台として使えます。
図の作成:Remogu編集部。IPAの点検項目を整理したもので、統計データではありません
評価制度の開始予定
IPAは、サプライチェーン強化に向けたセキュリティ評価制度(SCS評価制度)について、2027年3月の制度開始に向けて準備を進めているとしています2。まだ始まっていない制度で、現時点は準備の段階です。
制度の中身は、この記事では扱いません。ただ、今回の点検で作った外部公開アプリ・外部サービス・アカウントの一覧は、参画先の手元に残る資料です。
冒頭の依頼に戻ります。管理画面、APIのエンドポイント、クラウドやVPNのアカウントを書き出して手が止まったとき、どこまでが「外部」なのかは、4つの範囲で線を引けます。見えている入口から数え始めて、使っている外のサービスまで数えます。
次の一歩は、見えている入口の一覧を作って、参画先に渡すところからです。リモートで参画できる保守の案件を探すときは、点検の段取りを組んだ経験を面談で伝える材料にして、Remoguの案件一覧も見てみてください。
8. よくある質問
アタックサーフェスとは何ですか
攻撃を受けうる範囲を指す言葉です。IPAのAIセキュリティ短信は、開発工程全般のアタックサーフェス(攻撃を受けうる範囲)化を動向の一つに挙げています1。この記事では、外部公開アプリ・外部サービス・アカウント・保有データの4つに分けて整理しましたが、これは書き手の整理です。IPAの点検の資料に、この語は出てきません2。
ログはどこまで遡ればよいですか
IPAは、各アプリケーション・サービスのログの異常を、直近1か月、その後3か月と段階的に範囲を広げて確認するよう求めています2。まず直近1か月を確かめ、そのあとに範囲を広げる順序です。
異常を見つけたら自分で調べてよいですか
IPAは、異常なログやアカウントを見つけた場合、速やかにセキュリティインシデントと判定し、専門のセキュリティベンダーに詳細調査を依頼することを強く推奨しています2。自分で調べ切る前提にはせず、見つけた場所の記録を添えて参画先に伝え、どこまで関わるかは参画先と協議して決めます。
リモートワーク案件をお探しの方へ
Remoguは、株式会社LASSICが運営するITエンジニア・デザイナー専門のリモートワーク案件紹介サービスです。フルリモート・ハイブリッドの案件から、スキルに合うものを探せます。
外部公開資産を洗い出せる力は、運用保守の現場で頼られる理由になります。その経験を生かせるリモートの案件から探してみてください。
会員登録無料 / 案件閲覧・相談は無料
※公開中の案件数は時期によって変わります。記事中の案件の傾向は執筆時点のものです。
出典・参考情報
*1 独立行政法人情報処理推進機構「AIセキュリティ短信(2026年9月7日 公開版)」(2026年9月7日・2026年10月確認)
*2 独立行政法人情報処理推進機構「不正アクセスによる漏えい等の事案を踏まえ、速やかに実施すべき対策等について」(2026年10月9日・2026年10月確認)
*3 Remogu(株式会社LASSIC運営)公開情報:扱う案件の90%以上がフルリモート可能