管理画面も外部攻撃面の一部
外部攻撃面には、 お客様向け Web サイトだけでなく、 管理者・運用者向けの URLも含まれます。 IdP（Identity Provider）や OSS 系の認証管理コンソール、 クラウドサービスの管理 UI などが、 意図せずインターネットに公開されているケースは珍しくありません。
サブドメインの棚卸しで
auth.example.co.jp のようなホスト名が見つかったあと、
HTTP 応答から「管理系 UI かもしれない」と整理する、という流れが攻撃面レビューでは典型です。
なぜ「本番は安全」なのに見落とされるか
社内 LAN の PC 管理や Microsoft 365 の管理者アカウントは 内部・クラウド契約の話です。 一方、インターネット上の管理 URL は、 世界中どこからでも HTTPS で到達を試せる入口です。 次のような状態が重なると優先度が上がります。
- パスワード入力画面がそのまま見える — 総当たり・既知弱点の標的になりうる
- 非本番・検証環境と同じ UI — 設定が緩い・パッチ未適用のことがある
- SSH 等と同時露出 — 入口が複数あると説明・対応が複雑化
- 機微パスとの共存 —
/.git等の誤公開と並ぶと「放置感」が強まる
サンプル報告書で示している例
架空の報告書サンプルでは、 次のような所見を高重要度で挙げています。
- F-01 — 複数ホストで OSS 系認証管理コンソールと推定される HTTP 応答（Keycloak 等の痕跡）
- F-10 —
auth.example.co.jpが HTTP 200 で応答し、タイトルに管理コンソールの痕跡 - F-11 / F-12 — 管理系露出と機微パス、または SSH（TCP 22）との同時存在
推奨アクションは「インターネット非公開、VPN・IP 制限・別管理経路、MFA」など、 入口を狭める方向に整理されています。 ログイン突破の実証までは標準スコープに含めません。
外部攻撃面レビューで「見る」こと（例）
| 観点 | 確認する内容（例） |
|---|---|
| HTTP 応答 | タイトル・リダイレクト先・既知 OSS / 管理 UI の痕跡（契約内の軽量プローブ） |
| パス | /admin、/console 等の代表パスへの応答（機微代表パス調査） |
| ホスト名 | auth / admin 等の命名 — サブドメイン一覧との突合 |
| 相関 | SSH 公開・/.git 露出など、同じホスト・ドメイン上の別所見 |
目的は「侵入できた」ことの証明ではなく、 第三者視点でログイン入口が見えている事実と 先に見直すべき URLを報告書にまとめることです。
対応の方向性（御社・ベンダー側）
設定変更やファイアウォール作業は、通常御社・インフラベンダーが行います。 レビュー結果をもとに検討される構成の例です。
- 非公開化 — VPN 内・踏み台経由のみ到達可能にする
- IP 制限 — 社内固定回線・委託先 IP のみ許可（完全策ではない）
- 認証強化 — MFA、デフォルトアカウント削除、パッチ適用
- DNS 整理 — 不要な
authサブドメインの削除（棚卸し）
含まないこと（よくある誤解）
- 管理画面へのログイン・パスワード総当たり・権限取得（ペンテストは別契約）
- ファイアウォール / WAF 設定の変更代行
- 社内 AD・M365 管理センターへのログイン調査
- 無許可の第三者資産へのスキャン
調査データは閉域環境内で扱います
調査結果の記録は当社事業所内の閉域環境でのみ保管・処理します。 契約範囲内の HTTP プローブ等は発生しますが、 御社データを当社クラウドや第三者 SaaS に載せる運用は行いません。 報告書は基本メールで納品し、調査画面のログインはお渡ししません。