公開アプリケーション セキュリティチェック（CSIRT 対応版）

IPA「不正アクセスによる漏えい等の事案を踏まえ、速やかに実施すべき対策等について」(2026-10-09) と JPCERT/CC JPCERT-AT-2026-0030 を基準に外部公開アプリケーションを点検し、 異常が見つかった場合は CSIRT/CERT が行うインシデント対応の流れ（検知・トリアージ → 封じ込め → 根絶 → 復旧 → 報告・通知 → 事後対応）に沿って確認を進め、Markdown レポートを出力する。

• IPA: https://www.ipa.go.jp/security/security-alert/2026/alert20261009.html
• JPCERT/CC: https://www.jpcert.or.jp/at/2026/at260030.html

同梱ファイル

パス	用途	読むタイミング
references/checklist.md	IPA/JPCERT の点検・強化策の全項目チェックリスト	Step 2〜5 の実施時
references/ioc.md	JPCERT 公表の不審 IP・User-Agent・手口別の痕跡	ログ点検時。更新される可能性があるので原文も確認
references/incident-response.md	CSIRT 対応手順（フェーズ別チェック、証拠保全、報告先・期限）	異常が見つかった時、または平時の体制点検時
references/report-template.md	レポート雛形	Step 7 の出力時
scripts/scan_logs.sh	アクセスログから IOC 一致・不審パス・大量リクエスト・エラー率を集計	Step 2-2
scripts/find_webshell.sh	最近作成・変更された .war/.jsp/.php 等を列挙	Step 2-2, 根絶フェーズ
scripts/inventory_endpoints.sh	IaC・ルーティング定義から公開エンドポイント候補を抽出	Step 1
scripts/check_persistence.sh	サーバ上の永続化痕跡（cron, 新規ユーザー, SSH 鍵, 不審プロセス）を確認	根絶フェーズ

スクリプトは bash のみで動作し、対象を変更しない（読み取り専用）。実行前に --help で引数を確認する。

前提と原則

• 点検は「異常の有無」と「強化策」を分けて報告する。 異常がなくても強化策は提案する。
• 断定できない項目は ❓ とし、推測で ✅ にしない。 不審 IP/UA の一致は調査の起点であり、単独で侵害と結論づけない。
• 証拠を壊さない。 異常の疑いがある環境では、ログの削除・ローテーション停止、サーバの再起動・再構築、ファイルの削除・上書きを行う前に証拠保全（references/incident-response.md 参照）を済ませる。スクリプトは読み取り専用だが、対象環境での実行自体がログに残ることを担当者に伝える。
• シークレットを転記しない。 本番ログや認証情報の取り扱いは必要最小限にし、レポートにトークン・パスワード・個人情報の実値を書かない。IP やアカウント名などの識別子は必要な範囲でマスクする。
• コードそのものの脆弱性診断（OWASP Top 10 等）は本スキルの対象外。必要なら別の診断ツール・手順（Claude 環境なら security-inspector スキル等）を併用する。

手順

Step 0. スコープ確認

対象が未指定なら、利用者に質問して確認する（質問ツールがあれば使い、なければ通常の対話で聞く）:

• 対象（リポジトリ / 環境 / サービス名）と、本番環境へのアクセス可否（ログ・設定・サーバを直接確認できるか）
• 現在の状況: 平時の予防点検か、すでに異常・侵害の疑いがあるか（疑いがあれば Step 6 を優先する）
• レポートに記載する組織名（自組織名、または点検対象の顧客名）と、レポートの読者（経営者 / CSIRT / 開発チーム / 顧客）
• 出力先（レポートのみ / 顧客向け資料 / Issue 化）

リポジトリや設定にアクセスできる範囲で自動点検し、できない項目は「要ヒアリング」として確認質問リストに落とす。

Step 1. 外部公開アプリの棚卸し

scripts/inventory_endpoints.sh <repo-dir> で候補を抽出し、以下を一覧表にする（名称 / 公開 URL・ポート / 用途 / 想定利用者 / 認証方式 / 構成要素 / 担当者 / ログの場所と保持期間）:

• IaC (terraform, wrangler.toml, serverless.yml, docker-compose, k8s manifests, CloudFormation)、DNS ゾーン、リバースプロキシ設定、ルーティング定義
• 管理画面・社内ツール・BI ツール・バッチ用エンドポイント・Webhook 受信口・ヘルスチェック・デバッグ用機能など、「公開しているつもりのないもの」を特に拾う
• モバイルアプリが叩く API（画面操作では呼ばれない内部 API・管理 API を含む）
• 各アプリのログの所在・保持期間・確認できる人（インシデント時に即答できる状態にしておく）

Step 2. 外部公開アプリの点検（異常の有無）

各アプリ単位で references/checklist.md の「②点検」を確認し、✅/⚠️/❌/❓ で記録する。要点:

2-1 パッチ・既知脆弱性 — 依存関係・ランタイム・ミドルウェア（BI、AP サーバ、VPN 機器）のバージョンと未適用修正を npm audit / pip-audit / trivy / lockfile で確認。Metabase は CVE-2026-72898 の修正版かを必ず確認。

2-2 ログの異常 — scripts/scan_logs.sh <logfile...> を直近 1 か月 → 3 か月と段階的に広げて実行し、references/ioc.md と照合する。確認する観点: 平時との差（エラー量、4xx/5xx 率、時間帯、送信元国）、IOC 一致、画面から呼ばれないエンドポイント、認証ヘッダー欠落・不正形式トークン、ログイン/リセット/SMS/検索の異常回数、設定ファイル・バックアップへのアクセス試行、.war/.jsp の作成・変更（scripts/find_webshell.sh）、権限変更・アカウント作成の操作ログ。

2-3 アカウント・権限の異常 — 身に覚えのないアカウント、無効化済みのはずが有効なアカウント、管理者権限の一覧、長期未使用、API キー/トークンの一覧と有効期限。

2-4 設定不備 — 管理画面・内部 API・デバッグ機能の公開、認証なしエンドポイント、HTTP メソッド/オリジン/レート/地域制限、設定ファイル・バックアップの公開パス配置、ディレクトリリスティング。

Step 3. 利用している外部サービスの点検

クラウド（AWS/GCP/Azure/Cloudflare 等）、VPN、SaaS、CI/CD、監視ツールを組織全体・部署単位で洗い出し、references/checklist.md の「③外部サービス」を確認する。ログ確認手段（保持期間、提供者側/利用者側で見られる範囲、確認者）、ログイン失敗数・ログイン元 IP・時間帯の平時比較、不審アカウント、MFA 未設定、権限過多、未棚卸しの API 連携。

Step 4. 保有データの点検

「不要な情報は持たない」を原則に、個人情報・機微情報を含むデータストアの一覧（場所、件数規模、保持目的、保持期限）、保存期間超過・利用目的終了データ、本番データのコピー（ステージング、ログ、バックアップ、BI の抽出先）、暗号化状況、データアクセスログの取得有無と保持期間を確認する。漏えい時の影響範囲（件数・項目）を即答できるかも確認する。

Step 5. 対応体制の点検（平時の CSIRT 準備）

異常がなくても、インシデント発生時に動けるかを references/incident-response.md の「平時の準備」で確認する:

• インシデント対応責任者・連絡網（経営層、法務、広報、委託先、セキュリティベンダー）と、夜間休日の連絡手段
• 検知手段（監視・アラート）と、検知から判断までの手順・判断基準（何をもってインシデントと判定するか）
• 証拠保全の手順と保全先（ログの書き出し先、ディスクイメージ取得の可否）
• 封じ込めの手順（公開停止、アカウント無効化、トークン失効、ネットワーク遮断）を誰が・どの権限で・何分で実行できるか
• バックアップの世代・隔離・復元テストの実績
• 報告先と期限（個人情報保護委員会、所管官庁、警察、JPCERT/CC・IPA、顧客・取引先）の一覧と、報告テンプレート
• 脅迫（公開をほのめかす連絡、身代金要求）を受けた場合の対応方針（支払わない方針の事前決定、警察相談）
• 机上演習（テーブルトップ）の実施有無

Step 6. 異常が見つかった場合のインシデント対応チェック

Step 2〜4 で ❌ または ⚠️ があり侵害の疑いがある場合は、セキュリティインシデントと判定して対応を開始し、専門ベンダーへの詳細調査依頼を強く推奨すると明記したうえで、references/incident-response.md のフェーズ別チェックを進める。要点:

1. 検知・トリアージ: 何を・いつ・どこで検知したか、影響を受けうるシステムとデータ、深刻度の暫定判定、対応責任者の指名、タイムライン（UTC/JST を明記）の記録開始
2. 証拠保全: ログ（Web/AP/DB/認証/クラウド監査/WAF）の書き出しとハッシュ、ローテーションによる消失の防止、メモリ・ディスクイメージの取得判断、改変しない
3. 封じ込め: 侵害経路の遮断（該当機能の公開停止、IP 遮断、WAF ルール）、侵害されたアカウント・トークン・API キーの無効化と全面的なローテーション、横展開の抑止（同一認証情報を使う他システムの確認）、攻撃者に気づかれる前提での段取り
4. 根絶: Web シェル・不正アカウント・永続化（cron、SSH 鍵、新規ユーザー、不審プロセス、scripts/check_persistence.sh）の除去、脆弱性の修正、侵害されたホストの再構築（クリーンイメージから）
5. 復旧: クリーンなバックアップからの復元、復旧後の監視強化、再発がないことの確認期間の設定
6. 影響範囲の特定: 漏えいした可能性のあるデータの種類・件数・対象者、アクセスされた期間、二次被害（なりすまし、不正利用）の可能性
7. 報告・通知: 個人情報保護委員会（速報・確報）、所管官庁、警察、JPCERT/CC・IPA への届出、顧客・取引先への通知、公表の要否と文面、問い合わせ窓口の設置
8. 事後対応: 根本原因分析、再発防止策、対応の振り返り（うまくいった点・改善点）、IOC の共有、平時の準備（Step 5）への反映

Step 7. 強化策と レポート出力

references/checklist.md の「強化策」から優先度（高/中/低）と工数目安を付けて提案し、 references/report-template.md に沿って security-check-YYYYMMDD.md を出力する（経営者向けサマリーを冒頭に置く）。 インシデント対応中の場合は、レポートとは別にタイムラインと**対応状況（フェーズ別の完了/未完了）**を更新し続ける。

注意

• 顧客向けに出す場合は、対象の組織名・環境名を正確に記載し、点検実施者・実施日・対象範囲・点検できなかった範囲を明記する。
• 法的な報告義務（期限・要否）は組織の業種・所在地・契約により異なる。references/incident-response.md の期限は一般的な目安であり、最終判断は法務・顧問弁護士に確認するよう促す。
• 攻撃者への接触、身代金の支払い判断、公表の文面は、技術者単独で決めず、経営層・法務・警察に相談するよう促す。