安全檢查監控(secwatch)指南

在畫面上檢視路由至組織(csn)的 SQL 注入二次判定結果(通知/審查/記錄),並以使用組織 SK 讀取的唯讀 API查詢相同內容,讓 AI 能定期檢查異常徵兆。

🛡️ 前往安全檢查監控 →

📋 概述

GIIP 的 secwatch(以 Jev 為基礎的 SQL 注入二次判定)會將採集器(lssn)送出的可疑事件,由閘道器以一次決定性規則 + 二次 AI 判定加以分類,寫入 tKVSSecurityCheck,並將每筆判定區分為路由對象。

路由(kscRoutedTo)	畫面標示	意義
alert	通知	疑似外洩/寫入嘗試或高信賴度攻擊 — 立即通知對象
review	審查	有攻擊可能性但低於自動通知門檻 — 需人工審查對象
log	記錄	判定為正常/雜訊 — 不通知,僅記錄筆數

畫面(/zh-TW/admin/secwatch-monitor)會以期間(最近 1 小時/6 小時/24 小時/7 天)與路由對象(全部/通知/審查/記錄)篩選後顯示這些結果。此畫面對已登入使用者開放,只會顯示路由至自身組織(csn)的結果(由伺服器 SP 保證)。

🔎 畫面判讀方式

畫面由兩個區域組成。

1. 採集覆蓋率面板 — 「正在檢查什麼、哪裡出現了異常」。按來源顯示檢查筆數(scanned)、偵測筆數(flagged)與最後檢查時刻,flagged 為 0 時 🟢 正常,1 筆以上時 🔴 異常。即使沒有偵測,也能確認「檢查正在執行」。
2. 判定結果卡片 — 每筆判定為一張卡片。顯示項目:

畫面項目	欄位	意義
時刻	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 呼叫兩個 SP。不包含資料寫入·判定·封鎖等功能。

共通呼叫規約

項目	值
方法	POST (或 GET)
URL	https://giipfaw.azurewebsites.net/api/giipApiSk4
內文(form-urlencoded) 或查詢	text=<命令>、token=<SK>、jsondata=<JSON>

• text 的第一個 token 為命令名稱,後續 token 是與 jsondata 的鍵一對一對應的欄位名。未寫出的 token,其參數會採用 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"}'

成功回應 (每筆判定對應 data[] 一列)

{
  "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 呼叫固定流程 (異常徵兆判定)

1. 按組織查詢: 以要檢查的各組織 SK 呼叫 KVSSecurityCheckWindow。時間窗依檢查週期設定(例如每小時檢查則 minutes=60,每日一次則 minutes=1440)。
2. 確認認證: 若回應 data[0].RstVal 為 401/403,則將該組織報告為 SK 錯誤或無法存取,並跳至下一個組織。
3. 異常徵兆判定: 在 data[] 中,只要有任何一列 kscRoutedTo 為 alert(通知)或 review(審查),即報告為異常徵兆。若只有 log(記錄),則視為正常記錄。
4. 優先排序: 報告時依 kscSeverity(嚴重度 0~4)與 kscIsInjection(注入機率)由高至低排序,並以 kscActorIp·kscPatternNo 一併記載是否為同一攻擊者/同一手法的重複。
5. 覆蓋率交叉確認: 以 KVSSecurityCoverageWindow 確認各來源是否實際正在被檢查。若某來源的 status 為 anomaly,優先檢查該來源;若預期的來源根本不在覆蓋率中,則一併報告為「可能採集缺漏」。
6. 掃遍所有組織: 對帳號可存取的各組織(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.zh-TW.md