IPA、相次ぐ不正アクセスで企業に対策点検を要請―今すぐ確認するWeb・SaaS・API・個人情報管理の12項目

コラム・インタビュー

投稿日時: 更新日時:

IPA、相次ぐ不正アクセスで企業に対策点検を要請―今すぐ確認するWeb・SaaS・API・個人情報管理の12項目

独立行政法人情報処理推進機構(IPA)は2026年10月9日、「不正アクセスによる漏えい等の事案を踏まえ、速やかに実施すべき対策等について」を公表しました。国内でWebサービスやアカウントサービスから大量の個人情報が窃取される事案が相次いでいるとして、企業の経営者に対し、外部公開アプリケーション、利用中のクラウドサービス、保有データの緊急点検を求めています。

今回の注意喚起の特徴は、脆弱性修正だけでなく、過去のアクセスログの確認、不審なアカウントの発見、委託先を含む外部サービスの棚卸し、保有データの削減を並行して行うよう求めている点です。JPCERT/CC、国家サイバー統括室(NCO)、個人情報保護委員会などの公表内容も踏まえ、直近で着手できる確認項目を整理します。

IPA注意喚起の要点

  • 公表日:2026年10月9日。対象は大量の個人情報や機微な情報を保有する事業者など。
  • IPAは一連の被害について、特定の製品・サービスの脆弱性を狙った攻撃と断定していません。
  • 外部公開している独自Webアプリ・サービスを洗い出し、異常なログと未適用のセキュリティ修正を確認するよう求めています。
  • ログ調査は直近1か月を起点に、必要に応じて3か月へ広げる方法を挙げています。
  • SaaS、クラウド、VPNなど部署単位で契約・利用しているサービスも含め、ログ・アカウントを確認するよう求めています。
  • 身に覚えのないアカウントの作成、無効化済みアカウントの復活などは、優先して確認する異常です。
  • 異常なログやアカウントが見つかった場合には、インシデント対応へ移行し、専門事業者による調査を強く推奨しています。
  • 不要な個人データの保有を見直し、認証・権限・API連携・ログ・暗号化の強化を検討するよう求めています。
  • JPCERT/CCは10月9日の更新で、APIへの不正な操作やアプリケーションサーバーへのWebシェル設置など、確認された手口を追加しています。
確認対象 最初に見るもの 異常の例 担当部門の例
外部公開Webサイト・アプリ 資産一覧、WAF/Web/アプリログ、パッチ状況 通常と異なる大量アクセス、想定外のエラー、未更新コンポーネント インフラ・開発・SOC
SaaS・クラウド・VPN 契約一覧、監査ログ、認証ログ 不審なログイン元、時間帯、無効化済みIDの再利用 情シス・ID管理担当
管理画面・API 特権ID、APIトークン、操作ログ、認可設計 権限変更、不審なアカウント作成、大量データ取得 開発・アプリ運用
顧客・従業員情報 データの所在、保存期間、アクセス権 不要な旧データ、部門横断の過大な閲覧権限 情シス・個人情報管理部門
委託先・再委託先 データ提供範囲、障害報告経路、責任分界 保管場所やログ確認者が不明、終了済み契約の権限残存 調達・法務・事業部門

※以下の「当日・1週間・1か月」という区分は、注意喚起の内容を実務向けに整理した編集上の着手目安です。IPAや各省庁が一律の実施期限を定めたものではありません。既に侵害を疑う兆候がある場合は、期間に関係なく直ちに対応します。

【最優先・当日】まず確認したい5項目

1.公開中のWebアプリ・管理画面・APIを把握する

自社が構築した会員サイト、予約サイト、EC、顧客向けポータル、公開APIに加えて、従業員用の管理画面、BIツール、テスト環境、保守用の管理URLを洗い出します。「利用者向けには非公開」であっても、インターネットから到達できる場合は点検対象に含めます。

最初の作業は、システム名、公開URL・ドメイン、管理責任者、取扱データ、認証方法、ログ保管場所を一覧にすることです。DNS、CDN・WAF、クラウド、ロードバランサーの設定、開発・運用部門が管理する一覧を突き合わせ、台帳から漏れた環境がないか確認します。IPAが求める「外部公開アプリケーションの精査」を実施するための出発点です。

2.直近1か月のログを確保し、異常があれば3か月へ拡大する

IPAは、ログの確認範囲を直近1か月から始め、その後3か月に広げる段階的な調査を例示しています。ログが短期で削除されるサービスでは、調査前にエクスポートや保全を検討します。

アクセスログ、認証ログ、アプリの監査ログ、WAF・CDNログ、クラウド管理ログを時刻と利用者IDで関連付けて確認します。例えば、通常より多い認証失敗、4xx・5xxエラー、短時間の大量検索・大量ダウンロード、深夜の特権操作、普段使用しない地域やIPアドレスからのアクセスなどです。いずれも単独では侵害の証拠とは限らないため、正常な業務や監視アクセスとの照合が必要です。

ログが残っていない場合には「異常なし」と判断せず、取得できる範囲、欠損期間、保存設定を記録します。調査用コピーは権限を限定して保管し、ログの改変・上書きを避けます。

3.管理者アカウントと認証方式を確認する

SaaS、クラウド、ID管理基盤、社内管理画面で、身に覚えのない管理者ID、退職・異動後も有効なID、削除したはずのアカウント、特権の追加を確認します。直近の管理者作成、権限変更、パスワードリセット、認証方式変更に関する監査ログも調べます。

外部から利用できる管理者アカウントや大量の個人データにアクセスできるアカウントは、多要素認証(MFA)の適用状況を優先確認します。個人情報保護委員会の10月7日付資料では、組織外からのアクセス、管理者権限でのアクセス、重要な個人データへのアクセスについて、フィッシング耐性のある方式を含むMFAが「手法の例示」として示されています。個々の例示が一律の法的義務という意味ではありません。

不審なIDを発見した際は、操作ログや証拠を保全したうえで、該当するセッション・トークンの無効化やアクセス遮断などを判断します。

4.外部公開製品と構成要素の未修正脆弱性を点検する

OS、Webサーバー、CMS、フレームワーク、プラグイン、APIゲートウェイ、VPN・ネットワーク機器などのバージョンを確認し、セキュリティ修正が適用されていないものを抽出します。公開範囲、悪用情報、取り扱うデータ、管理者権限への到達可能性を加味して対応順を決めます。

JPCERT/CCは10月8日公開・9日更新の注意喚起で、標的ごとに複数の既知脆弱性を探索する活動や、設定ファイル・バックアップファイルの取得を試みる手口も報告しています。単一製品だけを確認して終了せず、バックアップファイルや設定ファイルが公開ディレクトリから取得できないかも調べます。

稼働中サービスへの変更は影響評価と復旧手段を確保して実施し、直ちにパッチを適用できない場合は一時的な公開範囲制限などの代替策を検討します。脆弱性管理の進め方は、脆弱性管理の基本と対応優先順位でも解説しています。

5.APIの認証・認可と異常操作を確認する

管理APIや内部APIは、URLを知っているだけでは操作できないこと、一般会員の権限で他会員の情報を取得・変更できないこと、サーバー側で対象データへの権限を都度検証することを確認します。スマートフォンアプリの画面に現れない操作でも、API経由では実行できてしまう設定がないか点検します。

JPCERT/CCは、管理APIの悪用を通じた権限変更、不正アカウントの作成、認証トークンを変えた応答の確認、他環境から流出したAPIキーの悪用などを報告しています。APIトークンの発行履歴、権限、有効期限、保管場所を確認し、漏えいが疑われる鍵は影響評価とログ保全を行ったうえで失効・再発行を進めます。

国内で相次ぐWebシステムへの不正アクセスとAPI悪用の手口では、JPCERT/CCが確認した攻撃類型を整理しています。

【直近1週間の着手目安】委託先・保有情報・検知体制を見直す

6.部門ごとのSaaS・外部サービスも含めて棚卸しする

IPAは、組織全体で導入したサービスに限らず、部署単位のクラウドサービスやVPNなども含めて洗い出すよう求めています。契約部門、利用者、管理者、個人情報の保存有無、監査ログの保有期間、ログの取得・開示方法を整理します。

ログの閲覧権限が自社にない場合は、サービス提供者が何を記録し、事故時に何時間・何日分を提供できるのか確認します。管理者の退職や委託契約終了後もアクセス権が残っていないか、再委託先まで確認範囲を広げます。国家サイバー統括室も10月9日、委託先管理や保有データの削減を含む対策強化を要請しています。

7.大量ダウンロードや権限変更を検知できるか確認する

「ログを記録する」ことと「攻撃を発見できる」ことは別です。重要な顧客データについて、大量の一覧取得、異常に多いCSV出力、利用者単位の短時間連続アクセス、管理者変更、APIキー発行などを検知・通知できるかを確認します。

Web・APIでは、ログイン、パスワード再設定、SMS送信、検索・データ取得といった処理ごとにレート制限の設定を検討します。JPCERT/CCは、単位時間あたりの要求数を制限し、APIエンドポイントごとの認可とトークンの最小権限を確保するよう勧めています。ただし、一律に厳しい制限を加えると共用IPの法人利用や正規のバッチ処理を妨げるため、正常な利用状況を測定し、検知モードで確認してから制御を強める方法が考えられます。

8.保有データの「場所・必要性・閲覧者」を点検する

対象は会員DBだけではありません。本人確認書類画像、問い合わせ履歴、退会済み会員情報、CSVのエクスポート先、データ分析環境、開発・検証環境、バックアップ、委託先に預けた複製データを含めて、保管場所とアクセス権を把握します。

個人情報保護委員会は10月7日、利用する必要がなくなった個人データを遅滞なく消去するよう努める規定を踏まえ、保有の必要性と保存根拠を確認するよう注意喚起しました。法令で保存が求められるデータまで一律に削除するものではありません。保存期間、削除判断者、削除対象、バックアップからの削除方法を整理します。

9.不正アクセス時の連絡と調査の責任分界を確認する

自社、運用委託先、クラウド事業者のうち、誰がアクセス遮断を判断し、誰がログを保存し、誰が影響人数と情報項目を特定するのか確認します。インシデント対応責任者、連絡先、休日の緊急連絡経路、法務・広報との連携も合わせて確認します。

NCOは委託先・再委託先を含む継続的な管理を呼びかけています。複数のサービスを連携している場合、APIキーの管理者や情報の持ち出し先まで責任分界を明らかにします。

10.本人確認書類の画像とアカウント不正利用への対策を確認する

本人確認書類画像を保存するサービスでは、画像が本当に保存を要するか、閲覧可能な職員・委託先が限定されているか、エクスポートを検知できるかを確認します。

金融庁は10月9日、非対面本人確認で本人確認書類や顔画像の不自然な点を確認するよう注意喚起し、該当する手続きについては2027年4月の制度変更を待たずICチップ情報の読み取り方式への早期対応を求めました。これは犯罪収益移転防止法等の対象となる本人確認業務についての要請であり、すべてのWebサービスへ一律に同じ本人確認方法を義務付けるものではありません。

【その後1か月の整備目安】再発を防ぐための仕組み

11.不要な公開・過大権限・長期間有効な鍵を解消する

外部公開する必要のない管理画面・APIを非公開化し、職務に不要な管理権限を縮小します。長期間有効なAPIキーや、複数システムで共用している管理者IDの見直しも対象です。アクセス権の定期棚卸し、MFA、認証情報の保管方法、ログの保持期間と定期レビューを運用ルールへ落とし込みます。

暗号化については、保存時・通信時の保護だけでなく、復号権限や鍵の保管者も確認します。バックアップや分析用のデータ複製が本番環境と同じ権限で取得できないかも点検します。

12.経営層へ点検結果と残留リスクを報告する

点検を「実施済み」で終えず、確認対象の一覧、検出した問題、実施した遮断・修正、未対応項目、必要な予算・外部支援を経営層へ示します。IPAは経営者のリーダーシップによる見直しを求めています。経済産業省の「サイバーセキュリティ経営ガイドライン」も、自社だけでなく取引先・委託先を含めた対策と関係者とのコミュニケーションを経営上の課題に位置づけています。

例えば、経営報告では「外部公開システム○件のうち点検済み○件」「ログを1か月以上確認できるシステム○件」「MFA未適用の特権ID○件」「保管目的を確認できない個人データ○件」といった、次の意思決定につながる項目を用います。これらは編集部が挙げる報告指標の例です。

異常を発見した場合、点検からインシデント対応へ切り替える

IPAは、異常なログやアカウントが確認された場合、速やかにインシデント対応を進め、専門事業者への詳細調査を強く推奨しています。単にパスワードを変更して作業を終了するのではなく、次の順に事実を整理します。

  1. 不審な操作の日時、対象システム、アカウント、アクセス元、操作内容と確認者を記録する。
  2. 関連ログや設定情報の証拠を保全し、必要に応じて専門家へ引き継ぐ。
  3. 攻撃継続の危険に応じて通信遮断、セッション無効化、アカウント停止などの封じ込めを行う。
  4. 顧客データや認証情報へのアクセス・取得の可能性を、記録に基づいて評価する。
  5. 個人情報保護委員会等への報告・本人通知の要否を、法令・契約上の要件と確認事実に沿って判断する。
  6. 復旧後も不審なアクセスが続いていないか、再発監視を継続する。

封じ込めやログ保全の順序は、攻撃が進行しているか、証拠が失われるかなどによって調整が必要です。調査対象の端末・サーバーを不用意に初期化したり、関連ログを消去したりしないよう注意します。

JPCERT/CCが10月9日に更新した技術情報には、不審なIPアドレスやWebシェルに関する追加情報もあります。ただし、示されたIPアドレスが現在も攻撃に使われているとは限らず、正規の利用が重なる可能性もあるため、単独で被害を断定したり、無条件で恒久ブロックしたりせず、時刻・操作内容と組み合わせて評価します。

情報システム部門が使える点検記録のひな型

記録項目 記入内容の例
点検対象 会員サイト/API/SaaS名、管理担当者
取扱情報 氏名、連絡先、本人確認書類、認証情報など
公開状況 インターネット公開/アクセス元制限/非公開
確認したログと期間 WAF・認証・監査ログ、2026年9月9日~10月9日など
点検結果 異常なし/要追加調査/要是正/ログ不足
脆弱性・認証状況 未適用更新、MFA、特権ID、APIキー
データ保有状況 保存先、保存期間、バックアップ、委託先
対応責任者と期限 担当部署、実施予定日、再点検日

IPAの注意喚起は、特定の1製品を更新すれば対応が終わるというものではありません。外部公開システムと外部サービスの把握、ログの確認、権限管理、保有情報の削減を並行し、確認結果を残すところから着手できます。

出典