不正アクセス対策の点検を、IPA（情報処理推進機構）が2026年10月9日に事業者へ呼びかけました。題は「不正アクセスによる漏えい等の事案を踏まえ、速やかに実施すべき対策等について」です。同じ日に国家サイバー統括室（NCO）も注意喚起を出しています。

求められているのは「外部公開アプリ」「外部サービス」「保有データ」の3つの点検と、異常を見つけたときの動き方です。本記事は、それぞれを何を表にし、どのログのどこを見るかまで落とし込みます。

THREE CHECKS点検の地図

IPAの点検は3か所＋異常時の1手

  1. 01

    外部公開アプリ・サービス

    棚卸し → ログを1か月、次に3か月 → 未適用パッチ

  2. 02

    外部サービス（クラウド・VPN・SaaS）

    部署単位の契約まで洗い出し、ログとアカウントを確認

  3. 03

    保有データ

    何をどこに置くか・アクセスログの保持期間・暗号化

  4. 04

    異常を見つけたら

    インシデントと判定し、専門事業者に詳しい調査を依頼

出典: IPA 2026-10-09 の注意喚起（当サイトは検索結果に載った本文で確認）

30秒でわかる（2026年10月17日時点）

  • ・何が出た：漏えい事案が相次いだことを受け、IPAが10月9日に「速やかに実施すべき対策等」を公表。NCOや個人情報保護委員会も注意喚起を出した
  • ・やること：外部公開アプリ・外部サービス・保有データの3つを点検。ログは直近1か月、次に3か月へ広げる
  • ・落とし穴：既定の保持期間では1か月分も残らないログがある。最初に「何日残っているか」を確かめる
  • ・見つけたら：速やかにインシデントと判定し、専門事業者に調査を依頼。IPAは10月16日に特別相談窓口を開いた

供給網全体の守り方は サプライチェーン攻撃とは｜手口・防御ツール比較・npm 12の新機構まで実践解説 にまとめています。

IPA注意喚起までのタイムラインと、何が起きているか

日付（日本時間） 出来事
2026-09-30〜10-01 Studio に不正アクセス（10月16日に第一報）
09-30 日本経済新聞社の社員の Microsoft 365 が不正に使われる
10-07 個人情報保護委員会が「大規模な漏えい等事案を踏まえた対応について（注意喚起）」。同日、日経の開発用クラウドに不正アクセス
10-09 IPA が「速やかに実施すべき対策等」、NCO が「不正アクセスによる漏えい等の事案を踏まえた対応について」を公表。同日、ソースネクストの会員情報取得 API への不正な取得が始まる
10-14 NCO が各機関の注意喚起をまとめたページを公開（個人情報保護委員会・金融庁・総務省・経済産業省など）
10-15〜16 ソースネクスト（最大22,519,960件）、日経（約183万件）、Studio が相次いで公表。IPA が不正アクセス特別相談窓口を開設

NCO の注意喚起は背景として、ウェブシステムの脆弱性の悪用、サプライチェーンを通じた侵害、堅牢さを欠くデータ管理を挙げています。IPA は「現段階では、特定のプロダクトやサービスの脆弱性を狙った攻撃とは断定されて」いないとしたうえで、外部公開のアプリやサービス、アカウントの侵害が起点になっている傾向を示しています。

個々の事案は 日経不正アクセスで183万件漏えい｜開発用クラウドの認証情報が入口、対象者と開発チームの点検 と ソースネクスト情報漏洩｜最大2,252万件・パスワードも対象、会員とAPIを持つ側が確認すること で扱っています。

当サイトの環境からは ipa.go.jp と cyber.go.jp を開けませんでした。IPA と NCO の文言は、検索エンジンの索引に載った本文の抜粋を複数の検索で突き合わせて確かめ、引用はその範囲に留めています。

不正アクセス対策①外部公開アプリ・サービスを点検する

IPA はまず、自組織が独自に構築・運用している外部公開のアプリやサービスがあるかを確かめ、直近のログに異常がないかを見るよう求めています。目安はエラーの出力量や平時との差です。期間は「直近１ヵ月、その後３ヵ月といったように、段階的に対象範囲を広げて」確認します。構成要素に未適用のパッチがあれば速やかに当てます。

最初に作る棚卸し表

頭の中の一覧では漏れます。次の列で表を作り、1行ずつ埋めます。

列 書く内容の例
名前・URL 会員サイト、問い合わせフォーム、キャンペーン用の LP、管理画面
作った人・保守する人 社内／制作会社／委託先（連絡先まで）
構成要素と版 OS、Web サーバー、CMS とプラグイン、ライブラリ、WAF
認証 管理画面のログイン方法、多要素認証の有無
ログの置き場所と保持日数 アクセスログ・エラーログ・WAF・認証ログ、それぞれ何日残るか
最終パッチ日 最後に更新を当てた日と、未適用の更新の有無

キャンペーン終了後も残っている LP や検証用のサーバーは、更新が止まったまま外に開いていることがあります。IPA は、ホームページや EC サイトを制作会社・委託先に任せている場合、未適用の更新がないか問い合わせるよう勧めています。

ログの見方：1か月から3か月へ

LOG REVIEWログの見方

まず直近1か月、次に3か月へ広げる

  1. 保存期間を確認

    ローテーションの設定

  2. 直近1か月を見る

    エラーの量・平時との差

  3. 怪しい点を記録

    IP・アカウント・時刻

  4. 3か月へ広げる

    同じ痕跡を遡って探す

  5. 判定する

    異常ならインシデント

「直近1か月、その後3か月」はIPA（2026-10-09）の記載。各段の中身は当サイトの整理

IPA は、今後複数回の調査がありうるとして、誰がどのように調査できるかも把握しておくよう勧めています。アクセスログで見る兆候は次のとおりです。

・.env・.git/・wp-login.php・../ など、存在しないはずの場所を探るリクエスト
・特定の IP からの 4xx の急増、特定の URL での 5xx の急増
・ログインやパスワードリセットへの POST の集中、深夜・休日の管理画面へのアクセス
・普段より極端に大きいレスポンス（一覧や CSV の大量取得）

「探られた」だけなら侵入ではありません。応答が 200 になっている、管理画面に入れているなど、成功した痕跡があるかを区別します。

未適用パッチの確かめ方

パッチは層ごとに確かめる場所が違います。棚卸し表の「構成要素と版」の列を上から順に埋めると、抜けが見えます。

層 確かめ方
OS Debian・Ubuntu なら apt list --upgradable で更新待ちのパッケージが出る
CMS とプラグイン 管理画面の更新一覧。更新が止まったプラグインは代わりを探すか外す
アプリのライブラリ Node.js なら npm audit で既知の脆弱性がある依存が出る
委託先が持つもの 制作会社・保守会社に版と最終更新日を書面で出してもらう
VPN・ルーターなどの装置 管理画面のファームウェアの版を、メーカーのセキュリティ情報と JVN の公開情報に突き合わせる

「更新が出ていない」ことと「安全」は別です。サポートが終わった版には、更新そのものが出ません。

不正アクセス対策②外部サービスを洗い出し、ログとアカウントを見る

IPA は、外部サービスにはクラウド・VPN などさまざまな分類があり、組織全体だけでなく部署単位での利用もありうるとして、網羅的な洗い出しを求めています。サービスごとにログの保有期間が異なること、提供者と利用者で見られるログが違うことから、誰がいつどのように確認できるかを整理するよう求めています。

部署の経費で契約した SaaS は情報システム部門の一覧に載りません。経理の支払い明細やクレジットカードの利用明細、シングルサインオンの連携先一覧から逆に拾うと漏れが減ります。

サービス 見るログ 既定で残る期間 見る兆候
AWS CloudTrail のイベント履歴（管理イベント） 90日（リージョンごと） CreateUser・CreateAccessKey・AttachUserPolicy・ConsoleLogin・StopLogging
Google Cloud Cloud Audit Logs の管理アクティビティ監査ログ 400日（_Required バケット） IAM の権限付与、サービスアカウントの鍵の作成
Microsoft Entra ID サインインログ・監査ログ 無料版 7日、P1/P2 30日 見慣れない国・時間帯からの成功、多要素認証の回避
Microsoft 365 Purview 監査（Standard） 180日 メール転送ルールの追加、大量のファイル取得
VPN 装置 認証ログ・管理操作ログ 機器の容量次第で上書き 退職者や使っていない ID での接続、管理者の追加

Entra ID の無料版では、IPA の言う「直近1か月」すら既定では残りません。まず各サービスの保持設定を確かめ、足りなければ外部の保存先へ転送します。

VPN 装置は別枠で見る

VPN 装置は社内への入口そのものなのに、SaaS の一覧にも Web サイトの一覧にも載りません。本体のログ領域が小さく、古いログから上書きされる機器もあります。点検では次の3つを見ます。

・ファームウェアが最新か、サポートが続いている機種か
・接続できる ID の一覧に、退職者や共有 ID が残っていないか
・ログを syslog で外のサーバーに送っているか（送っていなければ今日から送る）

忘れられたアカウントの見つけ方

・退職者・異動者の一覧と、各サービスのユーザー一覧を突き合わせる
・最終ログインが長く空いている ID、作った人が分からない管理者を洗い出す
・API キーやサービスアカウントの鍵の作成日と最終使用日を見る
・共有の管理者 ID を個人の ID に置き換え、多要素認証を必須にする

鍵が外に出た場合の取り替え方は Studio不正アクセスで利用者がやること｜APIキー・フォーム・保護ページの鍵を取り替える手順 で扱っています。

保有データを再点検する

IPA は、盗まれた情報が脅迫や不正売買などの二次被害に使われる傾向を重く見て、「不要な情報は持たない」を基本に、保有データを必要最小限に絞るよう求めています。対策として、保有し続ける必要があるかの再検討、保管場所の再検討、アクセスログの取得内容と保持期間の見直し、暗号化が挙がっています。

列 書く内容の例
データの種類 会員の氏名・メール・住所、決済情報、問い合わせ内容
置き場所 本番 DB、バックアップ、開発環境の複製、SaaS、共有ドライブの CSV
件数と保有の理由 退会者のデータまで持つ必要があるか
誰が読めるか 人の権限、API・サービスアカウントの権限
アクセスログ 誰がいつ何件読んだかが残るか、何日残るか
暗号化 保存時の暗号化、バックアップの暗号化

開発環境に本番の複製を置いていると、入口が開発用でも被害は本番と同じになります。日経の事案は、開発用クラウドの認証情報が入口でした。

自システム確認コマンド（Linux の Web サーバー）

Web サーバーで今日から打てる3本です。パスは nginx の既定です。Apache なら /var/log/apache2/ などに読み替えます（combined 形式なら列の並びは同じです）。zgrep と zcat -f はローテーションで圧縮された古いログもまとめて読みます。

# 1) 存在しないはずの場所を探ったIPの上位
zgrep -hE '"[A-Z]+ [^"]*(\.env|\.git/|wp-login\.php|phpunit|\.\./|%2e%2e|\.\.%2f)' /var/log/nginx/access.log* | cut -d' ' -f1 | sort | uniq -c | sort -rn | head -20
# 2) 日ごとのリクエスト数・4xx・5xx（平時との差を見る）
zcat -f /var/log/nginx/access.log* | awk '{d=substr($4,2,11); n[d]++; if($9~/^4/)e4[d]++; if($9~/^5/)e5[d]++} END{for(d in n) print d, n[d], e4[d]+0, e5[d]+0}' | LC_ALL=C sort -t/ -k3n -k2M -k1n

3本目は、ドキュメントルートで直近30日に作られた・書き換えられた PHP ファイルを出します。Web シェルは wp-content/uploads/ のような、本来 PHP を置かない場所に紛れ込むことがあります。

cd /var/www/html
find . -type f -name '*.php' -ctime -30 -print

-mtime ではなく -ctime にしたのは、touch -d で更新日時を過去に偽装されても inode の変更時刻は戻らないからです。

当サイトで、怪しい行を混ぜたログ（圧縮した古いログを含む）と混ぜないログ、PHP を置いた Web ルートと置かない Web ルートを作って実行しました。1本目は探りに来た2つの IP だけを出し、きれいなログでは何も出しませんでした。2本目は 5xx が41件に跳ねた日を出しました。3本目は更新日時を5月に偽装した cache.php も拾い、同じ条件で -mtime -30 に変えると取りこぼしました。

ログが14日分しか無かったら：何日分あるかは ls -l /var/log/nginx/ で、残す日数は /etc/logrotate.d/nginx の rotate と daily／weekly で分かります。足りなければ 90日以上に延ばし、別のサーバーやクラウドのストレージにも送ります。侵入者は手元のログを消せるからです。

異常を見つけたときの対策と、今日・今週・今月の優先順

TRIAGE異常の判定

入られた痕跡があれば、インシデントとして扱う

インシデント判定

  • ID覚えのない管理者 インシデントアカウントの新規作成・権限の付与
  • IN海外からログイン成功 インシデントVPN・SaaS・クラウドの管理画面
  • DL大量ダウンロード インシデントAPI・エクスポート・ストレージ
  • 404設定ファイル探し 記録して監視.env・wp-login.php 宛て。成功なし
判定の例は当サイトの整理。IPAは異常なログやアカウントを見つけたら速やかにインシデントと判定するよう求めている（2026-10-09）

IPA は「異常なログやアカウントの発見があった場合は、速やかにセキュリティインシデントと判定し、インシデント対応を進めてください」としています。専門のセキュリティベンダーによる詳細調査も強く勧めています。自分でログを消したりサーバーを作り直したりする前に、ログとディスクを保全してから相談します。

IPA が10月16日に開いた不正アクセス特別相談窓口は、被害の可能性がある段階でも相談でき、助言のほか、インシデント対応を行う専門業者の一覧や他の相談・報告先を紹介します。個人情報保護委員会などへの報告は、窓口への相談とは別に要否を判断します。

いつまでに やること
今日 外部公開アプリと外部サービスの棚卸し表を作り始める／各ログが何日残っているか確かめる／管理者と VPN に多要素認証が付いているか確かめる
今週 直近1か月のログを見る／未適用のパッチを当てる／使っていない ID と鍵を止める／委託先に未適用の更新が無いか問い合わせる
今月 3か月分へ広げる／ログを外部へ転送し90日以上残す／保有データの表を作り、不要なデータを消す・暗号化する／権限を最小に絞る

IPA は、自社だけでなく情報を共有する取引先や委託先とも連携し、サプライチェーン全体で考えるよう求めています。今後、不審な IP アドレスやログの痕跡などが公開される可能性があるとして、情報収集の強化も呼びかけています。

影響範囲：誰がこの点検をやるべきか

影響を受けるのは、外から届くアプリやサービスを持つ組織と、会員情報などを預かる組織です。規模は問いません。部署単位で SaaS を契約している会社、Web サイトを制作会社に任せている会社は、棚卸しの段階で漏れが出やすい層です。

参照ソース