情報漏洩が相次ぐ今、「社内用だから大丈夫」を見直す

社内向けシステム、誰が安全を確認していますか

顧客に見せるホームページは丁寧に確認していても、売上を集計する画面、予約を管理する画面、社員が使う業務ツールは、担当者だけで動作を確かめて運用していることがあります。「検索結果に出ない」「URLを社員にしか伝えていない」という理由で、安全の確認が後回しになっていないでしょうか。

社内用という言葉が表すのは、使ってほしい相手です。実際に接続できる相手や、情報を読み書きできる相手まで自動的に限定されるわけではありません。担当者には非公開のつもりでも、外部のネットワークから利用できる設定のままになっている可能性があります。まずは呼び名と実際の設定を分けて考えることが必要です。

この話は、今すぐすべてのシステムを止めるという意味ではありません。仕事に使う画面と、その画面で扱う情報、管理している人を並べることから始められます。難しい技術を知らなくても、「どの部署の情報を扱い、誰に利用を許し、どの会社が保守しているか」は、発注者と管理者で確認できます。

自社で作ったツールだけでなく、制作会社に依頼した管理画面や、使わなくなった旧システムも対象です。現役のホームページだけを見て終わりにすると、移行中の環境や以前の管理画面が一覧から漏れます。契約書、請求書、サーバの管理情報を手掛かりに、把握していない入口がないかを確かめましょう。

10月の注意喚起から読み取れること

JPCERT/CCは2026年10月8日に注意喚起を公表し、10月9日に更新しました。国内の情報漏洩事案に関連し、一般向けアプリだけでなく、従業員向けの管理システムなどでも被害があると説明しています。すべての事案が同じ原因だと示す資料ではなく、把握した情報には限りがあることも明記されています。

ここから自社に引き寄せて考えたいのは、「お客様向けではないから点検の対象外」としないことです。一方で、特定のシステムが被害を受けたというニュースだけから、同じ種類の製品はすべて危険、自社もすでに漏洩している、と判断することはできません。公表された事実と、自社で調べるべき事項を分けましょう。

確認を進めるときは、公開範囲と権限の状態を別々に記録します。例えば、社外から接続できる設定であることが分かっても、直ちに情報を閲覧できると決まるわけではありません。接続時の本人確認、その後に見られる情報、情報を出力できる操作まで、担当者に確認する事項を分けて伝えましょう。

経営者から「うちは大丈夫か」と聞かれたときも、「同じ製品を使っていないので問題ありません」で終わらせないことを勧めます。対象の製品を使っているかという確認と、似た管理上の問題がないかという確認は別です。後者を自社の点検項目へ落とし込むことが、ニュースを読む実務上の価値になります。

公開範囲・権限・保有情報を一枚にまとめる

最初の棚卸しでは、システム名ごとに「用途」「接続できる場所」「利用者」「扱う情報」「保守担当」を書き出します。分からない欄を空欄のまま隠す必要はありません。未確認と書き、確認する相手と期限を添えます。作業の目的は立派な資料を作ることではなく、誰に何を聞けば状態が分かるかを明確にすることです。

公開範囲は、社内のネットワークからだけ使えるのか、社員の自宅からも使うのか、取引先にも利用を認めているのかを確認します。接続が必要な範囲を決めてから、現在の設定と比べると判断しやすくなります。外部から使う必要がある場合も、広く公開することと、必要な相手だけに使わせることを同じにしないでください。

権限では、ログインできるかだけでなく、ログイン後に何をできるかを整理します。一般担当者、管理者、外部委託先が同じ操作をできる必要はあるでしょうか。退職者や契約終了者の利用を止める担当も決めます。これは各社の運用を整理する一般的な例であり、今回の被害企業の運用を示したものではありません。

保有情報では、画面に見える一覧だけでなく、ダウンロードしたファイル、作業用のコピー、保存先を含めて確認します。不要な情報を残し続けない運用は、漏洩時の影響を考えるうえでも意味があります。ただし、保存期間には契約や業務上の要件が関わるため、担当者の独断で削除せず、社内の管理方針と照らし合わせます。

棚卸しをする際は、試験用や開発用の環境を忘れないようにします。本番への切り替え後も残っている画面がないか、そこに実際の顧客情報を置いていないかを担当者へ確認してください。使わなくなった環境を止める場合も、ほかの業務から参照されていないかを先に調べます。サーバを契約している会社と、実際に設定を変えられる会社が異なることもあるため、連絡先と作業を依頼する相手まで記録します。

• 公開範囲：本当に必要な相手と場所からだけ接続できるか。
• 利用権限：担当者・管理者・委託先の役割に合っているか。
• 管理責任：更新、アカウント停止、異常時の連絡を誰が受け持つか。

点検結果を、修正と継続確認につなげる

棚卸しができたら、保守担当と「設定を見れば分かる事項」「実際に確認する事項」「追加調査が必要な事項」を分けます。画面上の操作だけでは、サーバ側の権限や内部の構成まで確認できないことがあります。公開URLの診断だけで社内システム全体の安全性が分かる、と受け取らないようにしましょう。

記録には、確認日、対象環境、確認した条件、結果、未確認事項を残します。「問題なし」とだけ書くより、「一般担当者のアカウントで、担当範囲外の情報を表示しないことを確認」のように、何を確かめたかを残す方が、引き継ぐ人にも伝わります。実施した確認と、設計書だけで判断した事項も区別すると、後の再確認がしやすくなります。

修正は、担当者を決め、修正後に同じ条件で確かめて完了とします。修正作業を依頼した時点と、結果を確認できた時点は異なります。業務への影響が大きい変更は、保守担当と適用の順番や戻し方を相談してください。異常や漏洩が疑われる場合は通常の点検とは切り分け、担当部署や専門家に連絡し、調査に必要な記録を保全します。

これから新しい業務画面を公開するなら、動作や仕様の確認を後回しにしないことも大切です。Custosの公開前診断では、公開前の確認を相談できます。APIや社内ネットワークまで含むかどうかは、対象や契約範囲を別途確かめてください。ニュースの事案がこのサービスだけで防げたと説明するものではありません。 このサービスの対象はWebアプリで、ネイティブのAndroid・iOSアプリは対象外です。画面・機能・仕様とのズレを確認するサービスとして利用し、詳しい安全性の確認は別途の脆弱性診断へつなげます。

公開後は、機能追加、利用者の変更、外部サービスの更新に合わせて状態を見直します。公開Webサイトについては、URLから始める脆弱性診断も確認の入口になります。診断で確認した範囲と、権限を持つ担当者による内部点検を組み合わせ、調べていない部分を把握することが必要です。

まとめ：社内用という名前より、実際の状態を見る

情報漏洩のニュースを見たときは、不安だけを社内へ広げるのではなく、自社で使う管理画面や業務システムを見直すきっかけにしましょう。用途、公開範囲、権限、保有情報、担当者を整理すると、点検を依頼する相手と確認したい内容が具体的になります。

公開前には仕様や動作を確かめ、公開後には脆弱性と運用の変化を継続して確認する。それぞれの役割を分け、結果と未確認事項を残すことが大切です。ひとつの診断で安全を保証するのではなく、把握した問題を修正し、再確認できる運用へつなげていきましょう。