会社のログイン画面洗い出しとは？見落としやすい管理画面の見つけ方を徹底解説

会社のログイン画面洗い出しとは何か

ログイン画面洗い出しの目的は『危険な画面を叩く』ことではなく『見落としを減らす』ことです

会社のログイン画面洗い出しというと、多くの人は「不正ログインを防ぐ設定」や「MFA をどう入れるか」を連想します。しかし、その前に必要なのは、そもそも外から見えている認証導線を把握することです。main のログインページしか見えていない前提で対策を組んでも、古い管理画面や委託先 portal が残っていれば、現実の auth surface はもっと広いままです。したがって洗い出しの目的は、攻撃テクニックを学ぶことではなく、自社が管理対象として持つべき login surface を把握することにあります。

ここでいう login surface には、製品の user login だけではなく、管理画面、SSO 入口、VPN login、委託先用 portal、サポート向け認証導線、停止予定だった staging も含みます。これらは部署や委託先ごとにバラバラに管理されやすく、incident 時に「その画面はまだ残っていたのか」と気づかれることが少なくありません。つまり問題は脆弱性以前に、一覧化の対象が狭すぎることです。

既存の 管理画面・開発環境の露出リスク は危険性を主役にしていますが、本記事ではどう見つけ、どう owner を戻し、どう月次で見直すかへ焦点を当てます。危険性の理解だけでは、放置された login page は減りません。洗い出しを運用へ落とし込んで初めて、auth surface の整理が始まります。

見落とされるのは『知らない画面』より『知っていたが終わったはずの画面』です

実務で本当に厄介なのは、完全に未知の画面より、以前は把握していたが、今は誰も owner を持っていない画面です。移行途中の admin 画面、停止予定だった portal、M&A で引き継いだ login page、委託先が保守で使っていた remote access portal は、この典型です。これらは「もう使っていないはず」という認識で放置されやすく、棚卸しの対象から落ちます。

そのため洗い出しでは、現役の main login を調べるだけでは不十分です。過去に存在した画面、用途が曖昧な導線、委託先が触る入口まで含めて、認証に関わる公開接点を丸ごと戻す必要があります。ここを狭く取ると、一覧表は綺麗でも、現実の auth surface とずれたままになります。

なぜログイン画面は見落とされやすいのか

ログイン画面が見落とされる一番の理由は、管理責任が分散していることです。main の製品画面はプロダクト部門が把握していても、委託先 portal はベンダー管理、VPN login はインフラ部門、SSO 入口は情シス、サポート用 portal は別チーム、と分かれていることが多くあります。この状態だと、誰も auth surface 全体を見ていません。つまり見落としは技術不足より、責任分界の断絶から起こります。

もう一つの理由は、停止や移行が「完全に終わった」と思い込みやすいことです。新しい portal へ切り替えたつもりでも、旧 portal が外から残っている、SSO の入口だけ古い URL が残っている、ベンダー向け login が close されていない、といったことは珍しくありません。こうした残骸は、平時には見えにくいのに、incident 時には真っ先に説明を求められます。

CISA の remote access software guidance↗でも、remote access の接点を inventory 化し、不要な公開を閉じることが基本とされています。ログイン画面洗い出しも同じで、認証方式の話を始める前に、まずどの入口があるかを列挙する必要があります。ここが曖昧なままでは、MFA や SSO を入れても coverage gap が残ります。

何を一覧化対象へ入れるべきか

現役の main login だけを見ると、実際の auth surface は必ずこぼれます。移行途中の画面、委託先向け導線、停止予定だった portal まで含めて、一度同じ inventory へ戻してください。

管理画面・SSO 入口・VPN login を別物として扱わないでください

実際の運用では、管理画面は Web アプリ、SSO 入口は identity team、VPN login はインフラ、と別物として扱われがちです。しかし攻撃者目線では、どれも認証導線です。したがって棚卸しも、製品分類より「認証導線かどうか」でまとめた方が見落としが減ります。管理画面、SSO 入口、VPN login、委託先 portal を一枚の一覧へ戻すと、auth surface の全体像がやっと見えるようになります。

既存の 公開RDPとは？ や 境界機器の脆弱性管理とは？ とつなげると分かりやすいですが、入口が多いほど統制は難しくなります。だから一覧化では、プロダクト単位より、入口単位で auth surface を戻す方が効果的です。

owner・approver・停止条件まで一緒に持つと、後から詰まりにくくなります

URL 一覧だけ作ると、見つけた後に必ず止まります。誰が owner か、誰が継続判断をするか、不要ならいつ閉じるのかが分からないからです。ログイン画面洗い出しは inventory で終わるものではなく、owner 管理へ戻す前段です。そのため一覧には、最低でも用途、owner、approver、reviewer、停止条件、次回確認日を持たせた方が運用しやすくなります。

とくに委託先が関わる login page では、社内 owner と外部窓口を分けて持つべきです。委託先が運用しているからといって、社内 owner を空欄にすると、incident 時に説明責任が宙に浮きます。これは既存の 外部公開資産のオーナー管理とは？ と同じ考え方です。

再公開や放置をどう継続監視するか

ログイン画面の棚卸しは、一度だけの調査だとすぐ古くなります。新しいサービス導入、委託先変更、M&A、移行作業、検証環境の残存などで、auth surface は継続的に変わるからです。したがって、月次の差分確認を前提にした方が安全です。見るべきなのは、新しい login page が増えたか、閉じたはずの画面が戻っていないか、owner が空欄になっていないか、例外期限が切れていないか、の四つです。

また、差分を見つけた後の動きも先に決める必要があります。新規 login page が見つかったら誰へ戻すか、用途不明なら何日以内に確認するか、不要なら誰が停止判断をするか、残すなら次回確認日をどこへ記録するか。この流れが決まっていないと、差分検知だけ増えて現場が疲弊します。だから継続監視では、検知そのものより、検知後に止まらない運用設計 が重要です。

認証方式の変更プロジェクトは、新しい login page を増やす契機にもなると理解しておくべきです

会社のログイン画面が増えるのは、放置だけが理由ではありません。SSO 移行、passkey 導入、ベンダー切替、社内ポータル刷新のような改善プロジェクトでも、新しい login page や一時的な認証導線が増えます。つまり auth surface は、改善の過程でも増える可能性があります。これを前提にしないと、プロジェクト完了後に「旧画面が消えていない」「検証用 login が残った」という事故が起こりやすくなります。

したがって継続監視では、障害対応や脆弱性対応だけでなく、認証方式の変更案件そのものを差分検知のトリガーに入れた方が良いです。改善プロジェクトを inventory 更新の契機として扱うと、auth surface の変化を後追いしにくくなります。

ログイン画面を見つけるときに何を情報源にするべきか

DNS や証明書だけでは足りず、IdP・委託先・過去資産の記録も必要です

会社のログイン画面を洗い出すとき、DNS やサブドメインの一覧だけを見ても十分ではありません。なぜなら、認証導線は「login.company.jp」のような分かりやすい host だけでなく、委託先 portal、製品 vendor のカスタム domain、SSO の relay URL、VPN login、M&A で引き継いだ古い portal にも散らばるからです。つまり探索では、DNS や証明書透明性ログのような外部観測だけでなく、IdP の設定一覧、委託先契約書、導入時の runbook、廃止予定システムの記録まで見ないと、auth surface は戻りません。

OWASP WSTG でも、認証まわりの testing は画面一枚ではなく、アプリの flow 全体を対象として扱います。実務でも同じで、単純に「login」を含む URL を集めるだけでは不足します。「admin」「sso」「portal」「vpn」「support」「remote」など、用途ごとに残りやすい入口を洗い出し、どの導線が現役かを突き合わせる必要があります。ログイン画面 inventory は discovery 技術だけでなく、社内に散らばった記録を戻す作業でもあります。

特に子会社や委託先が絡む組織では、情シスが直接管理していない login page が残りやすくなります。これは 子会社ドメイン管理 や 外部公開資産のオーナー管理 と同じで、inventory 対象そのものが organizational boundary をまたぐからです。だから最初の棚卸しでは、技術探索と契約・運用記録の回収を同時に進める方が、後で取りこぼしに気付きにくくなります。

検索エンジン、古いブックマーク、委託先ドキュメントも実務では有効です

技術的には洗練されて見えなくても、実務では古いブックマーク、ヘルプデスク手順書、ベンダー向け導入資料、社内 wiki が非常に役立ちます。現場では「昔の手順書に残っていた URL がまだ生きていた」「委託先向け手順のスクリーンショットから portal を発見した」といったケースが珍しくありません。つまり login page の洗い出しは、脆弱性診断のような高度な探索だけではなく、運用ドキュメントから auth surface を掘り起こす作業でもあります。

ここを軽視すると、「技術的には全部見たはずなのに、後から委託先向けの古い画面が出てきた」という事故が起きます。検索エンジン、古い documentation、サポートメールのテンプレート、ベンダーの導入ガイドまで含めて情報源にすると、auth surface の現実に近い inventory を作りやすくなります。

見つけたログイン画面の優先順位をどう決めるか

『公開されている』『owner が曖昧』『認証が弱い』の三条件が重なるものから先に対応します

ログイン画面を洗い出したあとに迷いやすいのが、どこから対応するかです。実務では、単に危険そうに見える順ではなく、「外から見えているか」「owner が明確か」「MFA や SSO が入っているか」の三条件で優先順位を付けると整理しやすくなります。たとえば、現役の main login は外から見えていても owner が明確で認証が強いなら、すぐ閉じる対象ではありません。一方、古い admin 画面や用途不明の portal は、存在理由を説明できない時点で優先度が上がると考えた方が実務に合います。

CISA の cross-sector cybersecurity performance goals でも、asset と access point の inventory を継続的に維持し、不要な exposure を減らすことが前提になっています。会社のログイン画面洗い出しでも同じで、「危険に見えるか」より「残している理由を説明できるか」で優先順位を付けた方が、閉鎖判断へつなげやすくなります。

閉じる、残す、期限付きで例外にする、の三択を明文化すると運用が止まりにくくなります

洗い出し後の運用で重要なのは、すべてを即時閉鎖しようとしないことです。現場では、委託先の契約やシステム移行の都合で今すぐ閉じられない login page もあります。その場合は、「残す」か「閉じる」かの二択ではなく、「期限付き例外」を明確に置く方が運用しやすくなります。例外にするときは、理由、期限、次回確認日、暫定的な防御策を一緒に記録しないと、単なる放置へ戻ります。

ここを文章化しておくと、棚卸しはただの inventory で終わらず、是正フローへつながります。ログイン画面の洗い出しは、一覧を作る作業ではなく、閉じる判断を前に進めるための準備です。だから優先順位付けでは、見つけた画面を分類するだけでなく、次に何をするかまで同じ表に戻す必要があります。

M&A や委託先変更がある組織では、引き継ぎ直後の確認を定例化した方が安全です

子会社化、事業譲渡、委託先変更がある組織では、引き継ぎ直後に auth surface が最も見えにくくなります。旧委託先の portal が残る、新委託先の support login が追加される、親会社では把握していない login page が残る、といったことが起きやすいためです。だからこの種のイベントを棚卸しの例外対応ではなく、定例の再確認イベントとして扱った方が運用しやすくなります。

こうしたタイミングを inventory 更新の必須イベントにしておくと、owner 不明や用途不明の login page を長期間放置しにくくなります。会社のログイン画面洗い出しは、技術探索だけでなく organizational change を拾えるかどうかでも質が変わります。

ログイン画面の棚卸しをASM診断 PROで進めるなら

ASM診断 PRO は ID 管理製品ではありませんし、ログイン画面そのものへ MFA を入れる製品でもありません。ただ、会社のログイン画面洗い出しで最初に困るのは、そもそも何を一覧へ戻すべきか分からないことです。管理画面、staging、古い portal、用途不明の login page、委託先が使う support 導線が外から見えていると、owner 管理や月次レビューの前提が崩れます。ASM診断 PRO は、こうした公開接点を外から棚卸しし、認証導線の inventory を始める対象をそろえるのに向いています。

とくに login surface は、部門ごとに分散していて全体像が見えにくいのが問題です。ASM診断 PRO で外部公開資産を洗い出すと、管理画面、staging、ベンダー portal、API host、古い subdomain を一枚の対象一覧へ戻しやすくなります。その上で、各項目へ owner、approver、reviewer、停止条件を戻せば、「見つけたが誰も引き取らない」状態を減らせます。つまり ASM診断 PRO は、単なる危険性の可視化ではなく、ログイン画面 inventory を owner 管理へつなぐ起点として効きます。

既存の 管理画面・開発環境の露出リスク、外部接続点は見えているか？、外部公開資産台帳テンプレート と合わせると、危険性の理解、対象一覧、owner 管理、月次差分確認までを一つの運用へつなげやすくなります。会社のログイン画面洗い出しを本当に進めたいなら、まず 外から見える認証導線を一度揃え、そのうえで owner を戻す 流れから始めてください。

よくある質問（FAQ）

main のログイン画面だけ管理していれば十分ですか

十分ではありません。管理画面、SSO 入口、VPN login、委託先 portal、旧環境 login を同じ一覧へ戻さないと、auth surface の見落としが残ります。

一覧化だけで owner 管理は後回しでもよいですか

後回しにすると是正が止まりやすくなります。URL 一覧と同時に owner、approver、reviewer、停止条件まで持つ方が実務では進みます。

委託先が運用する login page も棚卸し対象ですか

対象です。社内 owner と外部窓口を分けて持たないと、契約変更や incident 時に説明責任が曖昧になります。

月次で何を確認すればよいですか

新しい login page、復活した旧画面、owner 空欄、例外期限切れの四つを差分として確認すると運用しやすくなります。

MFA や SSO が入っていれば棚卸しは不要ですか

不要にはなりません。認証方式が強くても、存在を把握していない login page が残っていれば、coverage gap が続きます。

まとめ

会社のログイン画面洗い出しは、認証設定の一般論ではなく、外から見える auth surface を漏れなく戻す運用です。main のログイン画面だけ見ていても、古い staging、委託先 portal、VPN login、SSO 入口、停止予定だった admin 画面が残っていれば、現実の管理対象とはずれたままになります。だから最初に必要なのは、何が認証導線として残っているかを一枚で見えるようにすることです。

実務で重要なのは、URL を並べるだけで終わらせないことです。owner、approver、reviewer、停止条件、次回確認日まで一緒に戻すと、見つかった後に止まりにくくなります。特に委託先や子会社が関わる login page は、社内 owner を明確にしないと、incident の後で誰も説明責任を持てません。ログイン画面 inventory は、結局 owner 管理へ戻して初めて価値が出ます。

さらに、棚卸しは一度で終わらせず、月次差分で再公開と owner 空欄を追い続ける必要があります。auth surface は導入、移行、契約変更、検証作業で簡単に増減するからです。会社のログイン画面洗い出しを進めるなら、危険性記事を読むだけでなく、外から見える接点をそろえ、owner を戻し、月次で差分を見る運用まで一気に設計してください。そこまでできると、見落としや責任者不明の login page をかなり減らしやすくなります。