Kuroco Security Audit

Kuroco セキュリティ設定チェック Skill（Admin MCP）

概要

Admin MCP の読み取り系ツールのみでKurocoサイトの設定を収集し、 references/checklist.md の基準に照らして所見をまとめる。

最小フロー（通常 3〜6 tool call）:

1. 監査スコープの合意（対象サイト・確認カテゴリ・レポート形式）
2. 利用可能な読み取りツールの把握
3. 設定値の収集（読み取り専用・並列可）
4. チェックリストで判定 → レポート

前提: 接続

Admin MCP の接続・認証・スコープ付きURLの仕様は /kuroco-admin-mcp を参照。本スキルでは以下だけ守る。

• /readonly 付きのスコープURLを推奨する。 書き込み系ツールが一覧に出ないため、事故が構造的に防げる

  https://{site}.g.kuroco.app/direct/rcms_api/admin_mcp/x/all/readonly
  

• 監査は横断的にモジュールを見るため、スコープは all が適切なことが多い。/readonly と併用する
• 接続済みサーバが書き込み可能なスコープ（/x/all など）の場合でも、本スキル実行中は読み取り系ツールしか呼ばない

手順

Step 1: 監査スコープの合意

実行前にユーザーへ確認する（推測で始めない）:

1. 対象サイト — 接続済みAdmin MCPサーバが複数ある場合はどれか。本番／ステージングの別
2. 確認カテゴリ — 全カテゴリか、特定カテゴリ（例: 公開APIまわりだけ）か
3. サイトの前提 — 「完全公開のメディアサイト」「会員限定サイト」「社内利用」で妥当な設定は変わる。判定の基準になるため必ず聞く
4. レポートの出力先 — チャット上のみか、ファイル保存か（保存はユーザーの明示的な同意を得てから。セキュリティ注意事項参照）

ユーザーに聞けない場合（非対話実行・AskUserQuestion が使えない等）は、監査を止めない。 次の順で埋め、埋めた内容をレポート冒頭に「仮定（未確認）」として列挙する:

Step 1.5: whoami で接続コンテキストを確定する

最初に呼ぶツールは whoami。 引数なしで、1コールでチェックリストの複数カテゴリを一次情報として埋められる。

security.ip_restrictions の rules（設定内容そのもの）は、サイト設定を更新できる接続でのみ返る。返らなかった場合は enabled までを事実として報告し、rules は「手動確認」に回す。

Step 2: 利用可能な読み取りツールの把握

MCPクライアントが接続時に取得済みのツール一覧を確認する。MCPツール以外の経路（curl での REST 呼び出し・管理画面のブラウザ操作・シェル）は使わない — MCP の権限・承認・監査ログを迂回するため。見えているツールで届かない項目は Step 4 の「手動確認」に回す。

チェックリストの各カテゴリを、一覧に実在するツール名へ対応づける。

• ツール名を推測して呼ばない。 一覧に見えている名前が正
• 対応する読み取りツールが見つからない項目は、その場で諦めず Step 4 で手動確認項目として扱う（チェックリストに管理画面上の場所を記載してある）
• レコード数ゼロのモジュールでは読み取り系ツールが一覧から除外される仕様のため、「ツールが無い＝設定が存在しない」ではない

Step 3: 設定値の収集

• 読み取り系ツールのみを使う。create / update / delete / bulk_* は本スキルでは一切呼ばない
• 独立した読み取りは複数のtool callを同時に発行して並列実行してよい
• 一覧取得は cnt で件数を制限する。件数が知りたいだけの場合は cnt を小さくし pageInfo.totalCnt を見る。cnt / columns を持たないツールもあるので、呼ぶ前に inputSchema で確認する
• 取得できたレスポンスの実フィールド名と実値だけを根拠にする。値が取れなかった項目を「設定済み」「未設定」と断定しない
• キーがレスポンスに存在しないことを「無効」「未設定」と読み替えない。 真偽値の設定を判定するときは、false / 0 が明示的に返っていることを確認する。キー自体が無い場合は取得できなかった（＝手動確認）
• A7（未使用API／エンドポイント）は設定値ではなく利用実績で判定する。 api-list → api_uri-list（直近8日間）、より長い窓は api_analytics-list（→ checklist の A7 の裏取り）
• 何らかの理由で取得できなかったとき、黙ってチェック項目を落とさない。 レスポンスが大きすぎて読めない、ツールが見えない、値が返らない——理由は何であれ、そのために確認できなくなった項目を**「手動確認」に列挙し、理由を書く**。カバレッジが落ちたことを隠すと、監査結果が実態より安全に見える

Step 4: チェックリストによる判定

references/checklist.md の各項目について、次のいずれかに分類する:

重大度はチェックリストの既定値を出発点とし、サイト前提で調整する（例: 完全公開のメディアサイトで 「APIセキュリティ＝なし」は既定 HIGH だが、公開データ専用APIと確認できれば「問題なし」に下げてよい）。 調整した場合は理由をレポートに書く。

Step 5: レポート

references/report-format.md の形式で報告する。最低限、以下を含める。

• 対象サイト・実施日時・スコープ・使用した接続（/readonly か否か）
• 重大度順の指摘一覧（現在値・推奨値・根拠となった取得元ツール・対処方針）
• 手動確認が必要な項目の一覧（取得できなかったことを隠さない）
• 設定変更を一切行っていない旨の明記

重要なルール

エラーハンドリング

接続・認証まわり（400 / 401 / 403 / ツール拒否）の原因と対処は /kuroco-admin-mcp の エラーハンドリング節と同一。本スキル固有の扱いは以下。

セキュリティ注意事項

• トークン・シークレット・パスワードの実値を表示・ログ出力・ファイル保存しない。 静的アクセストークンや自動ログイントークンの一覧を取得した場合も、報告するのは件数・有効期限・作成日時までにとどめる
• レポートのファイル保存はユーザーの明示的な同意を得てから。 セキュリティ監査結果は「どこが弱いか」の一覧そのものであり、漏洩時の影響が大きい。会員データやIPアドレスなど個人情報を含む場合は、保存範囲を提示して確認する
• メンバー一覧・ログイン履歴の取得は必要最小限に。 権限棚卸しに必要なのは通常「ユーザー種別」「有効/無効」「所属グループ」であり、個人情報カラムまで取得する必要はない
  • columns を省略すると全カラムが返る。 メンバー系・ログイン履歴系のツールは、氏名・メールアドレスを含んだ状態で返ってくる。一度取得してしまえばレポートに書かなくても取得の事実は残るので、columns を指定してから呼ぶ（例: member-list なら member_id / group_ids / login_ok_flg）
  • columns に指定できる名前が分からない場合は、まず存在しない名前を1つ渡してエラーを出させ、返るメッセージから有効なカラム名を得る。 個人情報を取得してから絞るのではなく、絞ってから取得する
• 監査自体が管理操作ログに記録される。共有環境では実施をチーム内に周知するようユーザーに勧める

アンチパターン

他スキルとの連携