JPCERT/CCの国内の不正アクセスの注意喚起は10月23日に更新された。対策の節は、トークンの有効期限と失効を挙げている ── 失効の手順を実際に引き、社内向けの画面が外から開かないかを確かめる13項目（2026年10月時点）

目次

1. 01 何が書いてあるか — 10月23日に更新された。対策の節は、トークンの有効期限と失効を挙げている
   1. 改訂の日付を、順に並べる
   2. 2026年10月23日に足されたことの範囲（要旨）
   3. 対策の節が挙げている項目（要旨）
   4. 原文が書いていないこと
2. 02 なぜ・背景 — 手順書が在ることと、手順が引けることは別
   1. 有効期限のないトークンは、漏れたあとも有効なまま残る
   2. 失効の手順は、書いてあるだけでは、いざというときに引けない
   3. 一般向けでない画面は、外から開く想定がない
   4. 日付を、開いたページごとに並べる
3. 03 用語 — 出てくる言葉を、先にそろえる
   1. トークンとAPIキー
   2. 有効期限と失効
   3. レート制限と429
   4. 最小権限
   5. 一般向けでない画面
4. 04 型別 — 台帳に書く、トークンの4種類と、画面の4種類
   1. トークンとキーを、4種類に分ける
   2. 種類1: 期限が短ければ、漏れても被害が短い
   3. 種類2: 長いトークンは、盗まれたときの影響が長い
   4. 種類3: 固定のキーは、差し替えの日を決める
   5. 種類4: 渡した先の失効も、自分の台帳に書く
   6. 一般向けでない画面を、4種類に分ける
   7. 画面の確かめは、誰が、どの回線で行うか
   8. 画面は、開いただけで中身を触らない
5. 05 明日、自社のサイトで確認できることチェックリスト
6. 06 代替・他の選択肢 — 失効のやり方と、制限のかけ方を選ぶ
   1. 失効のやり方を、3つに分ける
   2. 失効の訓練は、いつ、誰が行うか
   3. RFC 7009の応答の読み方
   4. 制限のかけ方を、4つに分ける
   5. 地域による制限は、正規の利用者も止めうる
   6. 不要なものを、止める・消す
7. 07 当サイトで確かめたこと — この記事の13項目は、これから行う
   1. 外から確かめる考え方は、これまでの記事に書いた
   2. トークンの失効を引く訓練は、まだ行っていない
   3. 設定の中身は、ここには書かない
8. 08 このテーマは、ここまで
   1. この記事で扱った範囲
   2. この記事で扱っていないこと
   3. 2026年10月30日 — この記事の確認日
9. 09 この記事のまとめ

01 何が書いてあるか — 10月23日に更新された。対策の節は、トークンの有効期限と失効を挙げている

JPCERT/CCは、国内の複数の組織で、不正アクセスによる個人情報の漏えいが報告されているとして、2026年10月8日に注意喚起を出した。この注意喚起は、10月23日に更新された。この記事は、更新された注意喚起の対策のうち、API のトークンの有効期限と失効と、従業員向けなど、一般向けでない画面が外から開かないかの2つに絞る。API の台帳そのものの作り方は、すでに書いた記事に任せ、ここでは「台帳に書いたトークンを、実際に失効させられるか」を主題にする。

改訂の日付を、順に並べる

注意喚起の末尾にある改訂履歴は、次の3回の変更を示している。

• 2026年10月8日: 公開。
• 2026年10月9日: 「概要」と「確認されている攻撃手法や攻撃の痕跡」に情報を追記。
• 2026年10月23日: 「概要」「攻撃手法や痕跡」「参考情報」に情報を追記し、攻撃手法の節の記載を整理。

2026年10月23日に足されたことの範囲（要旨）

10月23日の更新で足されたことの要旨を、2つに分ける。

• 攻撃の試みの型に、AIを使った侵入テストの基盤を悪用した試行が、新しく加わった。
• すでにあった型に、不審な送信元のアドレスなどの痕跡が追加された。ただし、痕跡のうち、通信の特徴だけでは判別に使えないものがあると、注意書きが付いている。

事例の詳しい中身は、この記事では取り上げない。守る側が確かめることは、更新の前から書かれていた「対策」の節にある。この記事は、その対策のうち、確かめやすいものを選んで書く。

対策の節が挙げている項目（要旨）

対策の節が挙げていることを、要旨で並べる。

• APIについて: レート制限、重要な機能への個別の制限、すべてのエンドポイントでのアクセス制御、権限の最小化、トークンの有効期限の設定と、速やかな無効化。
• それ以外: アクセス元の地域による制限（サービスの利用地域が限定される場合）、脆弱性の更新の適用、内側への横展開への対策の見直し、検知の体制と初動対応の点検、顧客への二次被害の防止の呼びかけ、不要な管理機能の公開の停止、不要なデータの削除。
• 点検の範囲: 従業員向けのシステムやBIツールなど、不特定多数の利用を想定していないシステムも、点検の対象に入れること。

原文が書いていないこと

注意喚起は、自分の会社が当たっているかを、判定する材料は与えない。どのトークンに有効期限があるか、失効の手順が引けるか、どの画面が外から開くかは、自分の会社で確かめるしかない。後ろの章が、その確かめ方を書く。なお、被害の件数や期間の数字は、外部の記事の数字が、集計の範囲をそれぞれの記事で決めているので、この記事では使わない。

02 なぜ・背景 — 手順書が在ることと、手順が引けることは別

有効期限のないトークンは、漏れたあとも有効なまま残る

トークンに有効期限がなければ、漏れた時点の値が、そのまま使い続けられる。期限があれば、漏れても、期限が来た時点で使えなくなる。筆者の読みでは、有効期限は、漏れたあとの被害の長さを、あらかじめ決めておく仕組みである。期限を付けられないキーでは、その代わりに、鍵を差し替える日を決める。

失効の手順は、書いてあるだけでは、いざというときに引けない

失効の手順書が在るのに、引けなかった、という場面は、起こりうる。手順書の画面に入る権限が、担当者に付いていなかった。手順書が指す画面の場所が、変わっていた。夜間や休日に、連絡がつく人がいなかった。これらは、実際に1回引いてみないと見つからない。当サイトは、サーバーのPHPの修正で、手順を実行したことと、修正が効いたことを、別のこととして確かめた。その話は、記事PHPの修正を入れても、版の番号も「作った日」も入れ替える前と同じ文字だった ── 修正が入ったかを値で確かめる4つの方法と、3本目の知らせ（CVE-2026-115560）を当サイトで確かめた記録に書いた。

一般向けでない画面は、外から開く想定がない

従業員向けの画面やBIツールは、外の人が使う想定で作られていない。そのため、外から開く設定になっていても、誰も気づかないことがある、と筆者は読む。注意喚起が、不特定多数の利用を想定していないシステムも点検の対象にするよう求めている理由は、ここにあると考えられる。ただし、これは筆者の読みで、注意喚起がその理由を書いているわけではない。

日付を、開いたページごとに並べる

開いたページの日付を、古い順に並べた。

03 用語 — 出てくる言葉を、先にそろえる

トークンとAPIキー

有効期限と失効

レート制限と429

OWASPのREST Securityの文書は、リクエストが速すぎるときに、ステータスコード429（Too Many Requests）を返すことを挙げている。429は、RFC 6585が定めたコードで、一定の時間に送られたリクエストが多すぎることを示す。RFC 6585は、Retry-Afterという項目で、待つ時間を示してよいと書く。回数の制限があるかは、この429が返るかどうかで、外から確かめられる場合がある。ただし、自社のサービスに、確かめの範囲を超えて負荷をかけないよう、1回か2回の確かめにとどめる。

最小権限

最小権限は、トークンやアカウントに、必要な操作だけを許すことである。注意喚起の対策にも挙がっている。1つのトークンが全部の操作を許していれば、漏れたときの被害は、全部の操作に及ぶ。操作ごとにトークンを分けておけば、漏れたトークンだけを失効させ、ほかは動かし続けられる。

一般向けでない画面

この記事で「一般向けでない画面」と呼ぶのは、従業員、取引先、運営者だけが使う画面である。BIツール、従業員の情報を扱う画面、サイトの管理画面、テスト用の画面が、その例である。外のインターネットから開けること自体が、想定外な画面を指す。

04 型別 — 台帳に書く、トークンの4種類と、画面の4種類

トークンとキーを、4種類に分ける

当サイトの記事スマホアプリを解析してAPIを直接使う攻撃が報告されている。署名や難読化に頼らず、サーバー側で守る ── WebとアプリのAPIの台帳を作って確認する13項目（2026年10月時点）は、APIの台帳を作る話だった。この記事は、台帳の中のトークンとキーだけを取り出す。種類で、有効期限の見方と、失効の手順が変わる。分け方は、出典に書かれたものではなく、確かめる場所を決めるための筆者の整理である。

種類1: 期限が短ければ、漏れても被害が短い

種類1は、OWASPの文書が、検証の対象に挙げている種類である。文書は、APIのアクセスの制御では、トークンの有効期限（expという項目）を検証するよう勧めている。ただし、期間の長さは、文書には書かれていない。何分にするかは、自社の事情で決める。

種類2: 長いトークンは、盗まれたときの影響が長い

更新用の長いトークンは、新しいアクセストークンを受け取るために使われる。筆者の読みでは、長く使える分、漏れたときに有効なまま残る期間が長くなる。台帳には、期限が「ない」ものを、先頭に出す。

種類3: 固定のキーは、差し替えの日を決める

固定のAPIキーは、期限を付けられないことがある。OWASPの文書は、第三者に渡したキーは漏れやすい（relatively easy to compromise）と書いている。期限がない代わりに、キーを差し替える日を、台帳に日付で書く。差し替えの手順は、先に1回、テスト用のキーで引いておく。

種類4: 渡した先の失効も、自分の台帳に書く

外部のサービスに渡した連携用のキーは、渡した先の画面でしか失効できないことがある。マクニカのブログは、サービスを終了するとき、サーバーの停止と、APIキーの破棄を行うよう提言している。使わなくなったキーは、残さない。使っていない連携のキーが、台帳に残っていないかも確かめる。

一般向けでない画面を、4種類に分ける

画面の側も、種類で確かめ方が変わる。この分け方も、筆者の整理である。

• 1 BIツールの画面: 使う人は、分析をする社員。外から確かめる場所は、ツールのアドレスを、社外の回線のブラウザで開く。
• 2 従業員の情報を扱う画面: 使う人は、人事・総務の社員。外から確かめる場所は、同上。ログイン前の画面が出るかを見る。
• 3 サイトの管理画面: 使う人は、運営者、制作会社。外から確かめる場所は、管理画面のアドレスを、社外の回線で開く。
• 4 テスト用の画面: 使う人は、制作会社、開発者。外から確かめる場所は、テスト用のサイトのアドレスを、社外の回線で開く。

画面の確かめは、誰が、どの回線で行うか

外から開くかの確かめは、社内のネットワークにつないだ端末では意味がない。社内からは開けても、外からは開けない設定のことがあるからである。社外のスマートフォンの回線か、自宅の回線につないだ端末を使う。端末と回線の名前を、台帳に書いておくと、あとで同じ条件で取り直せる。

確かめを行う人は、画面の持ち主の許可を得てから行う。自社の画面でも、制作会社が預かっているテスト用のサイトなど、持ち主が別にある画面がある。持ち主が違う画面は、開く前に、持ち主へ連絡する。

画面は、開いただけで中身を触らない

確かめるときは、ログイン前の画面が出るかどうかを見るだけにとどめる。ログインを試したり、入力欄に値を入れたりしない。自社の画面でも、確かめ方が攻撃の試行と見分けがつかない動きになってしまうと、監視の側に不要な警報を出させる。開く回数も、1画面につき1回にとどめる。外から開くかの確かめ方は、記事PHPの脆弱性にWAFの保護が入っても、PHPの更新は要る。Cloudflareは「追加の層」と書いた ── CDNを通らない経路・ルールの対象外・WAFを切ったときを確かめる13項目（2026年10月時点）にも、外側から見る考え方が書いてある。

05 明日、自社のサイトで確認できることチェックリスト

以下は、トークンの失効の手順を実際に引き、一般向けでない画面が外から開かないかを確かめる、13項目である。1〜4番目はトークンの数え方、5〜8番目は失効の手順を引く作業、9〜11番目は外から画面を開く確認、12〜13番目は制限と保管の確認である。1項目は5分以内でできる。確かめた結果は、台帳に日付つきで書く。失効を引く項目は、本番のトークンではなく、テスト用のトークンで行う。

• 担当サイトのAPIを使う場所を、サイトごとに書き出し、使っているトークンとキーの数を、数字でメモに書く
• トークンとキーを1つずつ、短い期限のトークン・更新用の長いトークン・固定のAPIキー・連携用のキーの4つのどれかに分けて、台帳の種類の欄に書く
• 発行元の管理画面か設定を1つずつ開き、有効期限の欄を見て、日付か「なし」を台帳に書き写す
• 有効期限が「なし」のものの数を数え、台帳の先頭に、その数と該当のトークンの名前を書く
• 漏えいが疑われたときにトークンを失効させる人を、トークンごとに1人、名前で台帳に書く
• テスト用のトークンを1つ作り、その担当者の権限で、失効の画面か命令に実際にたどり着き、かかった分数を台帳に書く
• 失効させたテスト用のトークンで、APIを1回呼び、拒否されたかを確かめて、返ってきた状態コードを台帳に書く
• 失効の連絡先の電話やチャットの宛先を台帳に書き、夜間と休日に連絡がつく人がいるかを、「いる」か「いない」で書く
• 社外のスマートフォンの回線につないだ端末で、BIツール、従業員の情報を扱う画面、サイトの管理画面、テスト用のサイトのアドレスを1つずつ開き、ログイン前の画面が出たか、開かなかったかを書く
• 開いた画面ごとに、ログイン前の画面に出ている文字（会社名、製品名、版の番号）を、画面を見て書き写す
• 外から開いた画面は、アクセス元を事務所のアドレスなどに絞る設定ができるかを、設定画面で1回確かめ、「できる」か「できない」かを書く
• ログインとAPIの入り口に、回数の制限があるかを、設定画面か説明書で1つずつ確かめ、「あり」か「なし」を書く
• 個人情報を保管する期限を、プライバシーポリシーの文と、実際のデータの一番古い日付で見比べ、食い違うかを書く

06 代替・他の選択肢 — 失効のやり方と、制限のかけ方を選ぶ

失効のやり方を、3つに分ける

トークンやキーを使えなくするやり方は、3つに分けられる。出典に書かれた分類ではなく、筆者の整理である。

失効の訓練は、いつ、誰が行うか

訓練は、一度やって終わりにしない。担当者が替わったとき、認証の仕組みを入れ替えたとき、連携の相手を増やしたときに、もう一度行う。筆者の読みでは、失効の手順が壊れるのは、手順を使わない間に、周りが変わったときである。台帳の「次に引く日」の欄に、日付を入れておく。最初の1回は、担当者の名前と、引いた日時、かかった分数だけを書けば足りる。

RFC 7009の応答の読み方

RFC 7009によると、失効の入り口は、失効に成功したときだけでなく、無効なトークンが送られたときにも、同じ成功の応答（HTTPの200）を返す。理由は、目的がすでに達成されているからである。筆者の読みでは、これは、失効の画面で「成功」と出ても、そのトークンが元から無効だったのか、今回の操作で無効になったのかは、応答だけでは区別できないことを意味する。そこで、チェックリストの7番目は、失効のあとに、そのトークンでAPIを呼んで、拒否されることを確かめる。

制限のかけ方を、4つに分ける

注意喚起とOWASPの文書が挙げた制限を、台帳の欄に合わせて4つに分けた。制限ごとに、確かめる場所が違う。

• 回数の制限: 止めるのは、短い間に多すぎるリクエスト。多すぎれば429を返す。確かめる場所は、設定画面か説明書。外からの確かめは、1回か2回にとどめる。
• メソッドの制限: 止めるのは、許していないHTTPメソッド。許可の一覧に載らなければ405を返す。確かめる場所は、APIの説明書の、許可するメソッドの一覧。
• アクセス元の制限: 止めるのは、事務所や関係者以外のアドレス、または地域。確かめる場所は、設定画面。制限を入れたあと、正規の利用者が使えるかも確かめる。
• 機能ごとの制限: 止めるのは、危険度の高い機能。ほかの機能より厳しくする。確かめる場所は、機能の一覧。どれを「危険度が高い」とするかを、担当者と決める。

地域による制限は、正規の利用者も止めうる

注意喚起は、サービスの利用地域が限定される場合は、アクセス元の地域による制限を、対策の1つに挙げている。筆者の読みでは、これは効くが、副作用がある。出張や海外の拠点から使う社員、海外のパートナーも、同じ制限で止まる。地域の制限を入れる前に、これらの利用者が、実際にいるかを、台帳の「利用者」の欄で確かめる。

不要なものを、止める・消す

注意喚起は、不要な管理機能の公開の停止と、不要なデータの削除も、対策に挙げている。使っていない画面や機能は、制限をかけるより、止めるほうが確実である。止める前に、本当に使っていないかを、アクセスの記録で確かめる。控えファイルを外から確かめて、外へ移した当サイトの記録は、記事控えファイルを外から確かめた日 ── 当サイトで読めたのは25本。「403でも置かない」理由と、次から積もらない手順に書いた。IPAの呼びかけを台帳にした記事IPAは、外部に公開しているアプリ・利用中の外部サービス・保有データの3つを速やかに点検するよう呼びかけた ── 管理画面の利用者・ログの保持日数・不要なデータを台帳にして確かめる13項目（2026年10月時点）とも、つながっている。

07 当サイトで確かめたこと — この記事の13項目は、これから行う

外から確かめる考え方は、これまでの記事に書いた

当サイトは、サーバーに残ったファイルを、外から開いて確かめる作業を、控えファイルを外から確かめた日に書いた。外へつなぐ通信の発行元を見直す話は、記事認証局の中間証明書8枚の秘密鍵が漏れた週、当サイトのサーバーの中からつなぐ通信は、漏れた証明書を通していた ── AIの知らせを自分で測り直して、塞いだ記録に書いた。共有の認証情報を、規律で守る話は、記事並列運用の三値の番人 — SSH キーを破壊した日に見えた、AI エージェント時代の共有認証情報保護規律に書いた。

トークンの失効を引く訓練は、まだ行っていない

この記事の主題である、トークンの失効を実際に引く訓練は、2026年10月30日の時点で、当サイトでは行っていない。当サイトの運営の側でも、この記事の13項目を、これから順に行う。結果は、行ったあとに、この記事の末尾へ日付つきで書き足す。数字や所要時間は、確かめるまで書かない。

設定の中身は、ここには書かない

当サイトの認証の仕組みや、管理画面の場所、防御の設定の値は、この記事には書かない。公開すると、今まさに空いている穴の案内になりうるからである。書くのは、確かめる手順と、確かめた日付までに絞る。確かめ方の、値で見る考え方は、記事PHPの2件の脆弱性が悪用リストに載り、期限は10月29日だった ── 期限の日に当サイトで確かめた4つと、自分の記事の言い過ぎ、期限を自分のサイトの期限に読み替える方法に書いた。

08 このテーマは、ここまで

この記事で扱った範囲

この記事が扱ったのは、2026年10月23日に更新されたJPCERT/CCの注意喚起のうち、トークンの有効期限と失効、一般向けでない画面の外からの開き方、回数やメソッドやアクセス元の制限の確かめ方である。

この記事で扱っていないこと

• 事例に出てくる組織の名前や、攻撃に使われた道具・技術の細部（守る側の確認に必要ないので書かない）
• アクセスログから、不審なアクセスを見つける手順（記事PHPの脆弱性の「痕跡」は、ログに無いこともある ── 圧縮されたログ・エラーの出る先・回転の直後を落とさずに、件数で数える13項目（2026年10月時点）に任せた）
• APIの台帳そのものの作り方（スマホアプリを解析してAPIを直接使う攻撃が報告されている。署名や難読化に頼らず、サーバー側で守るに任せた）
• 各社のサービスごとの、トークンの失効の画面の場所（サービスごとに違い、筆者は確かめていない）

2026年10月30日 — この記事の確認日

この記事の内容は、2026年10月30日に、JPCERT/CCの注意喚起、JPCERT/CC Eyes、NICT、マクニカ、OWASP、RFCのページを開いて確かめた時点のものである。注意喚起は、今後も更新されうる。更新の内容を確かめたときは、日付つきで書き足す。