8分で読了

セキュリティ監視モニター(secwatch)ガイド

組織(csn)へルーティングされた SQLインジェクション二次判定結果(通知/レビュー/記録)を画面で見て、同じ内容を 組織SKで読み取る読み取り専用API で照会することで、AIが異常兆候を定期的に点検できるようにします。

🛡️ セキュリティ監視モニターページへ →

📋 概要

GIIPのsecwatch(JevベースのSQLインジェクション二次判定)は、収集器(lssn)が送った疑わしい事象をゲートウェイが一次決定論ルール + 二次AI判定で分類し tKVSSecurityCheck に格納して、各判定を ルーティング対象 に振り分けます。

ルーティング(`kscRoutedTo`)	画面表記	意味
`alert`	通知	漏洩/書き込み試行の疑い、または高信頼の攻撃 — 即時通知対象
`review`	レビュー	攻撃の可能性はあるが自動通知のしきい値未満 — 人によるレビュー対象
`log`	記録	正常/ノイズと判定 — 通知せず件数のみ記録

画面(/ja/admin/secwatch-monitor)は、この結果を期間(直近1時間/6時間/24時間/7日)と ルーティング対象(全体/通知/レビュー/記録)でフィルターして表示します。この画面はログインユーザーに公開され、自組織(csn)へルーティングされた結果のみが表示されます(サーバーのSPが保証)。

🔎 画面の読み方

画面は2つの領域で構成されます。

収集カバレッジパネル — 「何を検査していて、どこだけが異常だったか」。ソース別に検査件数(scanned)・検知件数(flagged)・最終検査時刻を表示し、flaggedが0なら🟢正常、1件以上なら🔴異常です。検知がなくても「検査は動いている」ことを確認できます。
判定結果カード — 各判定1件がカード1枚。表示項目:

画面項目	フィールド	意味
時刻	`kscRegdt`	判定格納時刻
ルーティングバッジ	`kscRoutedTo`	通知(alert)/レビュー(review)/記録(log)
イベント種別	`kscFactor`	事象の種類(`secevt_*`)
注入確率	`kscIsInjection`	SQLインジェクション/攻撃準備の確率(0〜1、画面は%)
深刻度	`kscSeverity`	0 ノイズ・ 1 偵察・ 2 列挙・読み取り・ 3 認証情報・個人情報の読み取り・ 4 書き込み・権限操作
攻撃種別	`kscAttackType`	分類された攻撃の種類
パターン	`kscPatternNo`	同じ手口(csn内のパターン連番) — 反復攻撃の追跡用
攻撃者IP	`kscActorIp`	攻撃の出所IP(追跡・遮断用)
フラグ	`kscIsInjection`/`kscDataExtracted`/`kscWriteAttempt`	各確率が0.7以上なら注入/データ漏洩/書き込み試行のバッジ
信頼度	`kscConfidence`	分類/深刻度判定の信頼度(0〜1)
エンジン	`kscEngine`	判定エンジン
収集器	`kscKey`	結果を上げた収集器(lssn)
ルーティング理由	`kscWhy`	ゲートウェイが残したルーティングの理由

注入確率・データ漏洩・書き込み試行は0〜1の確率値であり、画面は 0.7以上 を「成立」とみなしてバッジを表示します。

🔌 API参照 (読み取り専用 — AI/外部クライアント向け)

画面と 同じ内容 を、組織識別値(csn)とその組織の秘密キー(SK)で読み取る読み取り専用APIです。汎用ディスパッチャー giipApiSk4 を通じて2つのSPを呼び出します。データの格納・判定・遮断の機能は含みません。

共通呼び出し規約

項目	値
メソッド	`POST` (または `GET`)
URL	`https://giipfaw.azurewebsites.net/api/giipApiSk4`
本文(form-urlencoded) またはクエリ	`text=<命令>`、`token=<SK>`、`jsondata=<JSON>`

text の最初のトークンが命令名で、以降のトークンは jsondata のキーと1:1で対応する フィールド名 です。トークンを書かない場合、そのパラメータはSPの既定値を使います(下記の例が最も安全な形です)。
token には組織の SK を入れます。SKはそのSKが属する組織(csn)の結果のみ を返します(csnを別途渡さなくても自動的にその組織へスコープされます)。
応答は常にHTTP 200で、本文は { "data": [ ... ], "debug": { ... } } 形式です。認証/パラメータのエラーもHTTP 200で返り、data[0] に { "RstVal": 401|403, "RstMsg": "..." } が格納されます — AIは data[0].RstVal を先に確認 する必要があります。

(1) 判定結果の照会 — `KVSSecurityCheckWindow`

フィールド(jsondata)	必須	意味
`minutes`	任意	照会の時間ウィンドウ(分)。既定60、最大10080(7日)。1時間=60 / 6時間=360 / 24時間=1440 / 7日=10080
`routedTo`	任意	`alert`/`review`/`log` のいずれか。省略すると全体

リクエスト例 (直近24時間の全体 — 最も安全な基本形)

export GIIP_API_BASE_URL="https://giipfaw.azurewebsites.net"
export GIIP_SK="実行時のみ設定"

curl --fail-with-body -X POST "${GIIP_API_BASE_URL}/api/giipApiSk4" \
  --data-urlencode "text=KVSSecurityCheckWindow minutes" \
  --data-urlencode "token=${GIIP_SK}" \
  --data-urlencode 'jsondata={"minutes":1440}'

リクエスト例 (直近24時間のうち通知対象のみ)

curl --fail-with-body -X POST "${GIIP_API_BASE_URL}/api/giipApiSk4" \
  --data-urlencode "text=KVSSecurityCheckWindow minutes routedTo" \
  --data-urlencode "token=${GIIP_SK}" \
  --data-urlencode 'jsondata={"minutes":1440,"routedTo":"alert"}'

成功応答 (判定1件ごとに data[] 1行)

{
  "data": [
    {
      "kscsn": 0, "kscKey": "12345", "kscFactor": "secevt_...",
      "kscIsInjection": 0.97, "kscAttackType": "...", "kscSeverity": 4,
      "kscDataExtracted": 0.10, "kscWriteAttempt": 0.95, "kscConfidence": 0.9,
      "kscEngine": "...", "kscRoutedTo": "alert", "kscActorIp": "...",
      "kscPatternNo": 1, "kscStatus": "...", "kscRegdt": "...", "kscWhy": "..."
    }
  ],
  "debug": { }
}

各行は画面カードの項目にそのまま対応します(上の「画面の読み方」の表を参照)。
SK/AK/キー/DB接続情報はどの応答にも含まれません。

(2) 収集カバレッジの照会 — `KVSSecurityCoverageWindow`

「検査したが送らなかった(正常を含む)」ソース別の集計です。画面上部のカバレッジパネルと同じ内容です。

フィールド(jsondata)	必須	意味
`minutes`	任意	照会の時間ウィンドウ(分)。既定1440、最大10080

リクエスト例

curl --fail-with-body -X POST "${GIIP_API_BASE_URL}/api/giipApiSk4" \
  --data-urlencode "text=KVSSecurityCoverageWindow minutes" \
  --data-urlencode "token=${GIIP_SK}" \
  --data-urlencode 'jsondata={"minutes":1440}'

成功応答

{
  "data": [
    { "ksvSource": "...", "ksvSystem": "...", "scanned": 1200, "flagged": 0, "lastTs": "...", "status": "normal" }
  ],
  "debug": { }
}

status は flagged が0なら normal、1件以上なら anomaly です。

エラー応答(両API共通)

data[0] に格納されて返ります(HTTPステータスコードは常に200)。

条件	`RstVal`	`RstMsg`
SK欠落または無効	401	`Invalid sk`
要求csnがSKのcsnと異なる(クロスcsn遮断)	403	`csn mismatch (sk 의 csn 과 다름)`

⚠️ セキュリティ: SKをURL、Issue、リポジトリ、プロンプト本文、ログに入れないでください。実行環境変数または秘密ストアからのみ渡します。

🤖 AI呼び出し固定手順 (異常兆候の判定)

組織別の照会: 点検する各組織のSKで KVSSecurityCheckWindow を呼び出す。時間ウィンドウは点検周期に合わせる(例: 毎時点検なら minutes=60、1日1回なら minutes=1440)。
認証確認: 応答 data[0].RstVal が401/403なら、その組織はSKが誤っているかアクセス不可として報告し、次の組織へ進む。
異常兆候の判定: data[] のうち kscRoutedTo が alert(通知)または review(レビュー)の行が 1件でもあれば異常兆候として報告 する。log(記録)のみなら正常な記録とみなす。
優先順位付け: 報告時は kscSeverity(深刻度0〜4)と kscIsInjection(注入確率)が高い順に並べ替え、kscActorIp・kscPatternNo で同一攻撃者/同一手口の反復の有無も併記する。
カバレッジの突き合わせ: KVSSecurityCoverageWindow で各ソースが実際に検査されているかを確認する。あるソースの status が anomaly ならそのソースを優先して点検し、期待したソースがカバレッジにそもそも無ければ「収集欠落の可能性」として併せて報告する。
全組織スイープ: アカウントでアクセス可能な各組織(csn)に対して1〜5を繰り返す。SKは組織単位なので、複数の組織を点検するには各組織のSKでそれぞれ呼び出す。

🛠 トラブルシューティング

症状	原因	解決
画面に「アクセス拒否」	ログインしているがその組織(csn)のコンテキスト/所属がない	該当組織に所属するアカウントでログイン。APIならその組織SKを使えば画面なしでも照会可能
API `data[0].RstVal=401`	SK欠落または無効	`token` に正しい組織SKを渡す(環境変数)
API `data[0].RstVal=403`	要求csnがSKのcsnと異なる	csnを別途渡さず、その組織SKのみを使う(SKがcsnを決定する)
`data` が空配列	その時間ウィンドウに該当組織の判定結果がない	正常(異常兆候なし)とみなす。`minutes` を増やして再照会可能
カバレッジが空	その時間ウィンドウに収集カバレッジの集計がない	収集器が動いているか確認し、`minutes` を増やして再照会

API参照

このガイドはAPIの詳細(エンドポイント・パラメータ・応答・エラー)を上の「🔌 API参照」節に自己完結的に含んでいます。別途のAPIガイドはありません。

バージョン: 1.0 最終更新: 2026-10-30 変更履歴: giip 4314 — secwatchセキュリティ監視モニターのユーザーガイドを新規作成。判定結果(KVSSecurityCheckWindow)・収集カバレッジ(KVSSecurityCoverageWindow)のSK読み取り専用APIを文書化し、AI異常兆候判定の固定手順を含む。 ソースファイル: giipv3/public/help/secwatch.ja.md