外部攻撃面とは
外部攻撃面(external attack surface)とは、攻撃者や第三者が インターネット経由で到達・観測できる入口の総称です。 社内 LAN のファイル共有や ERP の内部画面は、通常ここには含まれません。
代表的な例は次のとおりです。
- コーポレートサイト・採用ページ・顧客向けポータルの URL
- メール送信に使うドメイン(
example.co.jpなど)の DNS 設定 - サブドメイン(
www、mail、stgなど)の有無と向き先 - HTTPS で応答するサービスと、証明書・セキュリティヘッダの状態
つまり「社内は守っているが、外から見えるところが古い・多い・説明できない」という状態を、 第三者の視点で地図にする作業が、外部攻撃面の整理にあたります。
内部監査・クラウド設定とは別物
Microsoft 365 や Google Workspace の管理画面設定、社内 PC のウイルス対策、 サーバー室の入退室管理は内部または契約ベンダー側の話です。 外部攻撃面レビューは、権限のない第三者がブラウザや DNS から確認できる事実に焦点を当てます。
両方必要な場合もありますが、同じ契約・同じ報告書に含まれるとは限りません。 まず外側を整理すると、内部投資の優先順位を決めやすくなることが多いです。
なぜ今、中小企業でも話題になるか
高度なサイバー攻撃のニュースばかりが目に入りますが、現場で多いのは次のような被害です。
- メールのなりすまし — 代表名義で取引先に振込先変更を送る(社内システム侵害なしでも起きうる)
- 古いサブドメイン・検証環境 — 更新を止めたホスト名がインターネット上に残る
- 公開設定のままの管理画面 — 意図せず外部から到達できる URL
いずれも「社内の基幹システムは別ベンダーが守っている」状況でも表面化します。 外部攻撃面の整理は、基幹とは独立した現実的な一歩として位置づけられます。
調査で「見る」ことの例
当社の攻撃面レビュー(契約スコープ内)では、おおむね次のような事実を報告書にまとめます。
| 観点 | 確認する内容(例) |
|---|---|
| ドメイン・DNS | 公式サイトの向き先、サブドメインの一覧、委任の健全性 |
| メール認証 | SPF / DMARC / DKIM などのレコードの有無と内容 |
| Web・TLS | 生存している URL、証明書、代表的なセキュリティヘッダ |
| 公開サービス | 契約範囲内での代表ポート・応答(全ポートスキャンは別契約) |
目的は「点数をつける」ことではなく、事実と優先して見るべき点を社内で共有できる形にすることです。 報告書の体裁例はサンプル(架空企業)でご覧いただけます。
含まないこと(よくある誤解)
外部攻撃面レビューは、次のような内容を標準では含みません。
- 社内 LAN・ファイルサーバー・社員 PC の調査
- パスワードや API キーの入手・漏洩 DB の照合
- ログイン突破や権限取得までの侵入実証(ペンテストは別契約)
- 無許可の第三者資産へのスキャン
スコープを狭く保つことで、許可範囲を明確にし、不要な負荷や法務リスクを避けます。
調査データは閉域環境内で扱います
御社からお預かりした .eml や調査結果の記録は、当社事業所内の閉域環境でのみ保管・処理します。 調査のためにインターネット上の公開情報へ問い合わせる通信は発生しますが、 御社のデータを当社のクラウド・共有 SaaS・第三者の管理サーバーに載せる運用は行いません。
- 御社クラウドへの預け込みは不要 — M365 / Google 等の管理画面ログインや、調査用の顧客ポータルはお願いしません
- 調査画面のログインはお渡ししません — お客様にお渡しするのは読みやすい報告書(PDF 等)が中心です
- 他社顧客のデータと混在させない — ご依頼・契約ごとに閉域内で管理し、他社向けの調査 SaaSに集約しません
- 納品は基本メール — 報告書の授受を中心とし、常時公開のダッシュボードは提供しません
「データを外に出したくない」「ベンダーのクラウドに調査結果を置きたくない」というご要望に沿った形です。 会計事務所・医療・金融に近い中小など、預け先を増やしたくない組織にも選ばれやすい運用にしています。 詳細はご契約時にご説明します。
はじめ方の目安
すべてを一度にやる必要はありません。状況に応じた入口の例です。
- 不審メール 1 通 — 送信インフラの事実整理から(単発)
- 代表ドメイン 1 件のライト調査 — 公開情報のみで地図を作る(能動スキャンなし)
- 攻撃面パッケージ — サブドメイン列挙から代表ポートまで、限定能動を含む整理
詳細なメニュー・見積りはお問い合わせください。 段階を上げる場合の目安は、攻撃面 → 脆弱性診断 → 必要ならペンテストの順です(以下)。
脆弱性診断について
外部攻撃面の整理で生存ホストや URL が分かったあと、 既知の弱点(CVE 等)の有無をスキャンし、一覧化するのが脆弱性診断です。 「侵入できたか」まで実証するのではなく、 検出結果の整理と優先度付けが中心になります。
3 つの調査の関係は、ざっくり次のイメージです。
| 段階 | 区分 | 主な問い | 典型の手段 |
|---|---|---|---|
| 1 | 外部攻撃面レビュー | 外から何が見えているか | 公開情報・限定ポート確認など |
| 2 | 脆弱性診断 | 既知の弱点はないか | 脆弱性スキャナ(GVM 等)によるチェック |
| 3 | ペンテスト | 本当に突破できるか | 手順を再現した侵入実証 |
脆弱性診断は攻撃面レビューとは別契約です。 初回に攻撃面で生存ホストを特定したうえでスキャンするセット契約、 すでに IP / FQDN のリストがある場合の単独実施、 攻撃面完了後に CVE 確認だけ追加する、など形はご依頼ごとに決めます。
- 含む — 契約したホスト・URL に対する既知脆弱性の検出と報告
- 含まない — ログイン突破の実証、内部ネットワーク全体の走査、無許可の第三者資産
脆弱性診断のご相談はお問い合わせください。
ペンテスト(侵入実証試験)について
脆弱性診断で弱点が見つかっても、実際に突破できるかは別問題です。 許可された URL・ホスト・認証情報の範囲で攻撃手順を再現し、 到達できた事実と再現手順を報告書にまとめるのがペンテスト(侵入実証試験)です。 多くの組織では、必要な場合にのみこの段階に進みます。
脆弱性診断との違いは、おおむね次のとおりです。
| 区分 | 脆弱性診断 | ペンテスト |
|---|---|---|
| 目的 | 既知弱点の検出と一覧化 | 許可範囲内で侵入できるかの実証 |
| 典型の内容 | CVE 等のスキャン結果の整理 | 脆弱性の悪用、認証突破、権限取得まで(契約による) |
| 契約 | 攻撃面とのセットまたは単独 | 別契約・別スコープ(対象リスト・実施ルール必須) |
ペンテストは攻撃面レビュー・脆弱性診断の標準範囲には含まれません。 事前の作業許可、対象の明示、実施時間帯の調整、影響の取り決めが必要で、 期間・費用も個別見積りになります。 すべてを一度に契約する必要はありません。 ペンテストのご相談はお問い合わせから承ります(範囲のすり合わせから開始します)。