--- title: "不正アクセス対策とは：IPA・JPCERTの2026年10月注意喚起に沿った企業の点検手順" url: "https://www.issoh.co.jp/column/details/18313/" published: 2026-10-13 updated: 2026-10-14 categories: ["セキュリティ"] publisher: "株式会社一創" --- # 不正アクセス対策とは：IPA・JPCERTの2026年10月注意喚起に沿った企業の点検手順 2026年10月8日から9日にかけて、JPCERT/CCとIPAが相次いで不正アクセスへの注意喚起を出しました。9月前後に国内で大量の個人情報が抜き取られる事案が続き、起点の多くが外部公開アプリやAPI、アカウントの侵害と見られているためです。本記事では、この2つの注意喚起と個人情報保護委員会の10月7日の文書を読み合わせ、企業が取るべき不正アクセス対策を「侵入経路の把握」「速やかな点検」「点検後の強化」「異常時の初動」の順に整理します。自社で回せる範囲と、診断や調査を外へ頼むべき条件も言い切ります。 ## まとめ：不正アクセス対策で企業が今月中に点検する順番と判断の基準 - **最初に見るのはログとアカウント**：外部公開アプリのログを直近1か月分から確認し、作成した覚えのないアカウントや無効化したはずのアカウントが動いていないかを洗います。 - **狙われているのは一般向けアプリだけではない**：BIツール、従業員向け管理システム、管理用APIも侵入口になっています。社内向けだから後回し、という判断は通りません。 - **点検で異常がなくても手を入れる**：APIのレート制限とエンドポイント単位の認可、トークンの有効期限、多要素認証、ログの保持期間は、異常の有無と関係なく見直します。 - **持たないデータは漏れない**：保存期間を過ぎた個人データの削除は、最も確実な被害縮小策です。 - **異常を見つけたら当日中にインシデント扱い**：IPAは専門ベンダーへの詳細調査の依頼を強く推奨しています。個人データが絡めば委員会への報告期限も動き出します。 ## 2026年10月の注意喚起が示す不正アクセスの侵入経路と狙われるシステム [JPCERT/CCの注意喚起（JPCERT-AT-2026-0030）](https://www.jpcert.or.jp/at/2026/at260030.html)は、ランサムウェアのような散発的な事案と分けて、大量の情報漏えいにつながる攻撃類型を4つに整理しています。すべての事案で同じ手口が使われたわけではない、と明記されている点は押さえておきます。 ### 既知の脆弱性の探索と設定ファイルの窃取を狙うケースAの手口と特徴 標的ごとに既知の脆弱性を幅広くスキャンし、入れる穴を探す手口です。脆弱性が見つからなくても、管理不備を突いて環境設定ファイルやバックアップファイルを抜き取ろうとする試みも確認されています。設定ファイルにはDB接続情報やAPIキーが書かれていることが多く、1ファイルの露出が次の侵入につながります。 公開ディレクトリに置き忘れた `.env` やバックアップのアーカイブは、パッチ適用では消えません。点検では、修正版の適用状況と並べて「Webから取得できてはいけないファイルが取得できないか」を確かめます。 ### アプリ解析から内部APIを突いて権限変更に至るケースBの手口 公開されているスマートフォンアプリを解析してAPIのエンドポイントやキーを特定し、画面からは呼べない内部APIを直接叩く手口です。JPCERT/CCは、ユーザー権限の変更や不正アカウントの作成、不正な形式の認証トークンを送って応答の違いを確かめる挙動、NoSQLインジェクションのブラインド探索を挙げています。他システムから盗まれたAPIキーが使われた例もあります。 観測されたUser-Agentには `python-requests` や `curl` が含まれていました。アプリの画面に出ない機能でも、APIとして公開されていれば攻撃面です。アプリ側のAPI認可を点検する具体例は、[セイコーマートの不正アクセスとアプリAPIの認可を点検する手順](https://www.issoh.co.jp/tech/details/18093/)で扱っています。 ### BIツールの脆弱性悪用とWebシェル設置で社内向けシステムが狙われる例 ケースCはMetabaseのSQLインジェクション脆弱性（CVE-2026-72898）の悪用で、詳細は[2026年8月14日公開の別の注意喚起](https://www.jpcert.or.jp/at/2026/at260023.html)にまとめられています。10月9日に追記されたケースDでは、公開Webサーバーから到達できるアプリケーションサーバーにWARファイルが置かれ、中のJSPが簡易Webシェルとして動いていました。 どちらも、不特定多数が使う前提ではないシステムが入口になった点が共通しています。BIツール経由の事案の経緯は[LEAN BODYの不正アクセスとMetabaseの脆弱性](https://www.issoh.co.jp/tech/details/18168/)で確認できます。 ## IPAが求める速やかな点検4項目｜公開アプリ・外部サービス・保有データ [IPAの10月9日の文書](https://www.ipa.go.jp/security/security-alert/2026/alert20261009.html)は、大量の情報や機微な情報を扱う事業者の経営者に向けて、点検と見直しを「至急」行うよう求めています。期限の日数は書かれていません。表現は「至急」「速やかに」「できるだけ速やかに」の3段階です。 ### 外部公開アプリのログを直近1か月から3か月へ広げて確認する手順 自社で構築・運用している外部公開アプリを列挙し、アプリ単位で直近のログに異常がないかを見ます。IPAが示す着眼点はエラー出力量と平時との差で、期間は直近1か月から始めて3か月へ段階的に広げる形です。調査は1回で終わらない前提で、誰がどの手順で見られるかを先に決めておきます。 Webサーバーのアクセスログ（combined形式）なら、最初の確認は次の3本で足ります。JPCERT/CCが公表した送信元IPアドレスを1行ずつ書いたファイルを用意して照合します。 ``` # 1. 注意喚起で公表された送信元IPアドレスとの照合 grep -F -f jpcert_ips.txt /var/log/nginx/access.log # 2. 日別の5xx応答件数（平時との差を見る） awk '$9 ~ /^5/ {split($4,d,":"); print d[1]}' /var/log/nginx/access.log | sort | uniq -c # 3. 自動化ツール由来のUser-Agentの件数 grep -E -c 'python-requests|curl/' /var/log/nginx/access.log ``` 公表されたIPアドレスは現在は正規の利用者が使っている可能性があると、JPCERT/CC自身が注記しています。一致しただけで遮断せず、自社ログ上の振る舞いと照らしてください。ログから痕跡を追う手順の全体は[セキュリティログ分析の手法](https://www.issoh.co.jp/tech/details/2788/)で解説しています。 ### クラウドやVPNなど利用中の外部サービスの洗い出しとログイン異常 次はクラウドやVPNなど、自社が利用している外部サービスです。部署単位で契約したSaaSも含めて網羅します。ログの保有期間はサービスごとに違い、提供者と利用者で見られるログも異なるため、サービスごとに「誰が・いつまでの・何のログを見られるか」を表にします。 見る指標はログイン失敗の件数、ログイン元IPアドレス、ログイン時刻の3つです。深夜帯の成功ログインや、普段使わない国からのアクセスが平時と比べて増えていないかを確かめます。 ### 作成した覚えのないアカウントと無効化済みアカウントの棚卸し手順 IPAが具体的に挙げているのは、作成した覚えのないアカウントと、削除・無効化したはずなのに有効になっているアカウントの2種類です。ケースBの手口では内部APIから不正アカウントが作られていたため、管理画面の一覧を見るだけでは足りません。アカウント作成・権限変更の操作ログと突き合わせ、作成者が説明できないアカウントを残さないようにします。 退職者や委託先担当者のアカウントは、棚卸しのたびに残りがちです。人事の異動記録と照合する運用を、四半期など決まった周期で回します。 ### 保有データを減らす判断と個人情報保護法22条の消去の努力義務 4つ目は保有データの再点検です。窃取された情報は公開の脅迫や不正売買に使われるため、IPAはこの点検も速やかに行うよう求めています。[個人情報保護委員会の10月7日の注意喚起](https://www.ppc.go.jp/files/pdf/261007%5Fhoudou.pdf)も、利用する必要がなくなった個人データを遅滞なく消去する努力義務（個人情報保護法22条）を改めて示しました。消去が徹底されず被害が深刻化した事例に接している、とまで書いています。 退会者のデータ、終了したキャンペーンの応募情報、移行前の旧システムに残った複製が典型です。法令で保存期間が決まっているもの以外は、根拠を確認したうえで消します。 ## 点検で異常がなくても進める不正アクセス対策｜API・認証・権限・ログ IPAは、点検で異常が見つからなくても強化策を検討するよう求めています。不正アクセス禁止法も[8条](https://laws.e-gov.go.jp/law/411AC0000000128)で、アクセス管理者に識別符号の適正な管理と、アクセス制御機能の有効性の検証・高度化に努めるよう定めています。 ### APIのレート制限と認可・トークン失効で入口を塞ぐ5つの実装項目 JPCERT/CCがAPIへの対策として挙げた項目を、実装の担当範囲ごとに並べると次のとおりです。 | 対策 | 具体的な中身 | 防げる手口 | | ------------ | ------------------------ | ------------ | | レート制限 | 件数の上限、ログインやSMS送信は個別に制限 | 総当たり・列挙 | | エンドポイント単位の認可 | 非公開APIも許可した利用者とメソッドのみ受付 | 内部APIの直接呼び出し | | 最小権限 | APIの利用者とトークンに必要な権限だけを付ける | 権限変更・不正作成 | | 有効期限 | 長期間有効なトークンを使わない | 盗まれたキーの再利用 | | 即時失効 | 漏えいが疑われるトークンをすぐ無効化できる仕組み | 他システム由来のキー | 優先度が高いのは2行目です。画面に出していないから呼ばれない、という前提がケースBで崩れています。設計の考え方は[APIセキュリティとOWASP API Top 10](https://www.issoh.co.jp/tech/details/13793/)と[OWASPのREST Security Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/REST%5FSecurity%5FCheat%5FSheet.html)、キーの発行から失効までは[APIキー管理の実装](https://www.issoh.co.jp/tech/details/16300/)が参考になります。 トークンの署名鍵を全顧客で共有していたSaaSでは、1本の鍵から全コミュニティの管理者になりすまされた事例が2026年10月に公表されました。テナントごとに鍵と権限を分ける実装は[Commune不正アクセスと共通署名鍵の教訓](https://www.issoh.co.jp/tech/details/18320/)で扱っています。 ### 多要素認証と権限の見直しを公開アプリと外部サービスの両方へ適用 IPAは外部公開アプリと外部サービスの両方について、多要素認証とパスワードの強化、アカウントへの権限付与の見直しを挙げています。管理者アカウントとクラウドの管理コンソールから先に多要素認証を必須にし、一般利用者へは段階的に広げる順番が現実的です。方式の選び方は[多要素認証（MFA）の3要素と実装方式](https://www.issoh.co.jp/tech/details/13314/)で比較しています。 利用地域が国内に限られるサービスなら、アクセス元の地域制限もJPCERT/CCの推奨に入っています。 ### ログの取得内容と保持期間を3か月の遡り調査から逆算する見直し IPAの点検手順は最大3か月の遡りを想定しています。ログが30日で消える設定では、この調査に答えられません。保持期間は「侵入に気づくまでの時間＋調査にかかる時間」から逆算し、少なくとも3か月分は検索できる場所に置く設計を勧めます（この3か月は点検手順からの逆算で、IPAが定めた保存期間ではありません）。 取得内容は、アクセスログに加えてアカウント操作のログとデータアクセスのログです。IPAは保有データについても、データアクセスのログの取得内容と保持期間、暗号化の見直しを挙げています。 ## 不正アクセス対策の優先順位と外部委託の判断｜自社で回す範囲と依頼先 ここからは、注意喚起の内容を受けて一創としての判断を示します。 ### BIツールや管理画面など業務上不要な公開機能を最初に止める判断 最初に手を付けるのは、インターネットに出ている必要のない管理機能やBIツールの公開停止です。JPCERT/CCも業務上不要な公開機能の停止を推奨しています。パッチ適用やログ調査と違い、止めた時点で攻撃面そのものが消えるからです。社内利用が前提のシステムはVPNやIP制限の内側へ移し、外からは到達できない状態にします。 ### 自社で完結できる点検と、脆弱性診断を外部へ頼むべき3つの条件 アカウントの棚卸し、外部サービスの一覧化、不要データの削除は自社で完結できます。外部へ頼むべきなのは、次のいずれかに当たる場合です。 - 独自開発の外部公開アプリやスマートフォンアプリがあり、APIの認可を第三者の目で検証したことがない - ログが残っていない、または誰も調べ方を知らないため、異常の有無を判定できない - 点検で異常なログや不審なアカウントがすでに見つかっている（この場合は診断ではなく調査ベンダーへ） 1つ目はケースBの手口そのものです。外部公開APIを持つ企業は、一創の[脆弱性診断・セキュリティ診断](https://www.issoh.co.jp/service/system/vulnerability/)のような第三者診断で、画面を経由しないAPI呼び出しまで検査範囲に入れてください。診断の種類と費用感は[脆弱性診断とは](https://www.issoh.co.jp/column/details/13101/)で整理しています。 ### 注意喚起を受けても見送ってよい不正アクセス対策と過剰になる場面 公表されたIPアドレスの一律遮断だけで対策を終えるのは見送ります。攻撃元は入れ替わり、正規利用に転じた可能性もあるためです。照合は調査のために使い、防御はレート制限と認可で行います。 海外利用者がいるサービスでの国外アクセス全面遮断も過剰です。売上や問い合わせを失うわりに、国内経由の攻撃は止まりません。新しいセキュリティ製品の導入も、ログとアカウントの点検が終わる前なら後回しで構いません。 ## 不正アクセスの異常を見つけたときの初動と報告・届出の使い分け 点検で異常が出た場合の動き方を最後に整理します。 ### 異常ログや不審アカウントを見つけた当日に行う初動とログの保全 IPAは、異常なログやアカウントを見つけた時点で速やかにセキュリティインシデントと判定し、対応を進めるよう求めています。当日中に行うのは、該当アカウントとトークンの無効化、ログの複製保全、関係するサーバーの状態の記録です。ログの削除やサーバーの再構築を先にすると、原因と漏えい範囲を後から立証できなくなります。 ### 個人情報保護委員会への報告とIPA届出・JPCERT相談の違い 個人データの漏えいやそのおそれがあれば、個人情報保護委員会への報告と本人通知の義務が生じる場合があります。不正アクセスによる事案は不正目的の類型に当たり、件数が1件でも報告対象です。期限と報告事項は[個人情報保護委員会への報告義務](https://www.issoh.co.jp/column/details/17840/)にまとめています。 これとは別に、IPAは[不正アクセスの届出](https://www.ipa.go.jp/security/todokede/crack-virus/index.html)を受け付けており、技術的な相談はJPCERT/CCの窓口が受けます。届出と相談は法的義務ではありませんが、ほかの組織の被害を防ぐ情報源になります。 ## よくある質問 不正アクセス対策について、点検を始める前によく出る疑問に答えます。 ### 中小企業でも2026年10月の注意喚起に沿った点検は必要ですか？ IPAの文書が直接の対象としているのは、大量の情報資産や機微な情報を扱う事業者の経営者です。ただし、ログとアカウントの点検、不要データの削除は規模に関係なく数日で着手できます。会員サイトや予約システムを持つ企業は、件数が少なくても対象と考えてください。IPAは中小企業向けに情報セキュリティ対策ガイドライン第4.0版も公開しています。 ### 不正アクセス禁止法で企業に罰則付きの対策義務はありますか？ 不正アクセス禁止法8条がアクセス管理者に求めているのは、識別符号の適正な管理とアクセス制御機能の検証・高度化で、どちらも「努めるものとする」という努力義務です。罰則はありません。一方、個人データを扱う企業には個人情報保護法23条の安全管理措置が義務として課されます。委員会は10月7日の文書で、技術的安全管理措置の見直し後の内容を先取りして示しました。 ### ログはどのくらいの期間保存しておけばよいですか？ 法令や注意喚起で一律の期間は定められていません。目安になるのは、IPAが点検で示した「直近1か月から3か月へ段階的に広げる」という調査範囲です。この調査に答えるには少なくとも3か月分を検索できる状態が要ります。業界のガイドラインや取引先との契約で期間が決まっている場合は、そちらを優先してください。 ### 公表された不審なIPアドレスが自社のログにあったらどうすればよいですか？ 一致しただけで侵害と断定せず、そのIPアドレスからのリクエストの中身を確認します。管理用のパスへのアクセス、認証エラーの連続、通常は呼ばれないAPIの呼び出しがあれば、インシデントとして扱う段階です。JPCERT/CCは、IPアドレスは現在正規に使われている可能性があると注記しています。判断に迷う場合は、ログを保全したうえでJPCERT/CCの窓口に相談できます。 ### 不正アクセス対策と情報漏洩対策は何が違いますか？ 不正アクセス対策は、外部から権限なくシステムに入られることを防ぐ取り組みです。情報漏洩対策はより広く、委託先からの流出、メールの誤送信、内部不正まで含みます。本記事は外部からの侵入に絞り、2026年10月の注意喚起が示した点検を扱いました。漏えいが起きた後の報告と通知は委員会への報告義務の記事を参照してください。委託先や誤送信、内部不正を含む漏えい全体の優先順位は[情報漏洩対策の原因別ガイド](https://www.issoh.co.jp/column/details/18315/)で整理しています。 ## 関連記事 - [セキュリティログ分析の手法｜不正アクセスの痕跡を見つける手順とコマンド例](https://www.issoh.co.jp/tech/details/2788/)：点検で見たログから痕跡を追う手順 - [APIセキュリティとは？OWASP API Top 10の主要リスクと実装対策を解説](https://www.issoh.co.jp/tech/details/13793/)：ケースBを防ぐAPI設計 - [脆弱性診断とは？種類・費用相場・進め方と外注時の判断基準を解説](https://www.issoh.co.jp/column/details/13101/)：外部診断を頼むときの判断材料 - [個人情報保護委員会への報告義務｜対象4類型・速報3〜5日と確報30日の実務](https://www.issoh.co.jp/column/details/17840/)：異常を見つけた後の報告期限 - [LEAN BODYの不正アクセスと約44万件の取得｜Metabaseの脆弱性とBIツールの公開設定・パッチ適用](https://www.issoh.co.jp/tech/details/18168/)：BIツールが入口になった事案 --- 出典: [不正アクセス対策とは：IPA・JPCERTの2026年10月注意喚起に沿った企業の点検手順]()（株式会社一創）