管理APIの点検では、公開範囲、利用者が操作できるデータと機能、トークンの権限、利用回数の制限、監査ログを確認します。ログイン画面があることや、URLを一般向けに案内していないことだけで、対策済みとは判断できません。
JPCERTは2026年10月8日に国内組織の不正アクセスに関する注意喚起を公開し、翌9日に更新しました。一般利用者向けアプリだけでなく、BIツールや従業員向け管理システムも点検を促されています。本記事は10月22日時点の一次資料を基に、運用者向けの確認表として整理します。
確認された事実と、まだ分からないこと
JPCERTは、把握している技術情報は限定的・断片的であり、すべての事案で同じ手法が使われたとは示していません。今回の注意喚起を「一つの脆弱性を直せば全部解決する話」とまとめないことが重要です。
この記事の点検表は、自分の組織が管理するシステムの設定と実装を確認するためのものです。外部のサイトへ試験用リクエストを送る手順ではありません。検証は権限のある環境とテスト用アカウントで行い、実データを使う必要がない項目は検証用データで確認してください。
最初にAPIと管理機能の一覧を作る
| 記録する項目 | 確認したいこと |
|---|---|
| システム名・担当者 | 誰が修正と判断を行えるか |
| 公開範囲 | インターネット、社内、特定接続元のどこから利用できるか |
| API・管理機能の用途 | 一般利用、管理、連携、過去版、デバッグ用のどれか |
| 認証と権限 | 誰を識別し、どのデータ・操作を許可するか |
| 保存データと提供製品の版 | 漏えい時の影響と更新の担当範囲 |
| ログと通知 | 何が記録され、異常時に誰が確認するか |
OWASPのAPI Security Top 10も、古いAPIやデバッグ用エンドポイントなどを含む資産管理の不備を取り上げています。トップページだけでなく、管理画面、モバイルアプリ用API、外部連携、旧バージョンを一覧に含めてください。
認証の次に「どこまで操作できるか」を確認
認証は利用者が誰かを確認すること、認可はその利用者が何をしてよいかを判断することです。ログインが成功することだけを確認しても、別の利用者のデータや管理者専用機能へのアクセス制御は確認できません。
以下は自組織の検証環境で使う確認例です。仕様として許可される操作と拒否すべき操作を先に決め、それぞれの結果を残します。画面でボタンを非表示にしているだけでなく、サーバー側の判定を確認することが目的です。
| 観点 | 確認例 | 期待する結果 |
|---|---|---|
| データの所有者 | 利用者Aのデータに利用者Bがアクセスする場合 | 仕様上の許可がなければ拒否 |
| 機能の権限 | 一般利用者が管理者専用操作を行う場合 | 権限がなければ拒否 |
| 変更できる項目 | 更新APIで役割など保護すべき項目を指定した場合 | 一般利用者には変更させない |
| 未認証・期限切れ | 有効な認証情報がない場合 | 保護データや処理を提供しない |
拒否されたときの表示だけでなく、データが書き換わっていないことも確認してください。結果を確認しないまま「エラーが出たので安全」と判断すると、処理の一部だけが実行される問題を見逃すことがあります。
APIトークンは権限・期限・失効を管理する
JPCERTは、必要最小限の権限、適切な有効期限、不要または漏えいが疑われるトークンを無効化できる仕組みを推奨しています。トークンを発行して終わりにせず、用途・所有者・更新方法・失効方法まで管理します。
- 読み取りだけの連携に、書き込みや管理者権限を与えていないか。
- 誰のためのトークンか、使っている連携先が分かるか。
- 退職・契約終了・連携廃止のときに無効化できるか。
- 漏えいを疑ったとき、影響範囲を確認して置き換える手順があるか。
- ログ、URL、公開コード、問い合わせの文章に秘密値を残していないか。
トークンの棚卸し資料には、秘密値そのものを集める必要はありません。識別名、用途、権限、有効期限などの管理情報を残し、実際の秘密値は組織の適切な保管場所で扱います。
レート制限は機能ごとに確認する
ログイン、パスワード再設定、SMS送信、検索などは、負荷や費用、不正利用の影響が異なります。全APIへ同じ上限を一つ設定するだけでなく、重要な機能ごとに制限と異常検知を設計してください。
確認では「上限に達したときに処理が止まるか」「通常利用まで止めていないか」「誰かが通知を確認するか」を分けます。適切な回数はサービスの用途や通常利用に依存するため、根拠のない一律の数値を正解として当てはめないでください。
不要な管理機能の公開と監査ログを見直す
OWASPのREST Security Cheat Sheetは、管理エンドポイントをインターネットに公開しないことを推奨しています。必要な場合も、認証や接続元の制限などを組み合わせます。非公開のつもりでも到達できる状態になっていないか、ネットワーク構成と設定を照合してください。
監査ログは、誰が、いつ、どの機能で、何に対して、成功・拒否のどちらになったかを追えるようにします。認証情報や個人情報を必要以上に記録しない配慮も必要です。保存期間、時刻の基準、閲覧権限、異常時の確認担当を決めておきます。
点検の完了条件を残す
- 対象一覧に、管理API・旧版・連携APIを含めた。
- 役割とデータの境界について、許可と拒否の結果を記録した。
- トークン、利用制限、公開範囲、ログの確認結果がある。
- 未確認事項や修正待ちに、担当と期限を設定した。
- 変更後にもう一度確認し、結果と確認日を保存した。
不審なアカウントや大量の取得履歴などを見つけた場合は、通常の点検とは分けてインシデント対応へ引き継ぎます。関連ログや設定を保全し、影響範囲と必要な制限を担当者が判断します。
よくある質問
WAFがあればAPIの認可確認は不要ですか？
不要にはなりません。利用者ごとに操作可能なデータや機能を決める処理は、アプリケーションの仕様と実装で確認する必要があります。
不審IPを遮断すれば終わりですか？
終わりではありません。JPCERT掲載のIPは観測時点の情報で、調査時に正規利用へ変わっている可能性もあります。現在の挙動や他の証拠も確認してください。
すべての項目に問題がなければ侵害なしですか？
この点検は、過去の侵害がなかったことを証明する調査ではありません。確認範囲と未確認事項を残し、疑わしい兆候があれば別途調査します。
コメント