Audit

"Audit"

2026-06-26 Security Group 稽核與清理盤點所有 security group 規則、找出 0.0.0.0/0 全開與未使用的 SG、依賴檢查後安全刪除、自動化治理
2026-06-20 查詢消費模式 Debug / Alerting / 產品決策 / 安全審計 / 效能監控 — 五種查詢場景各需要什麼事件、什麼欄位、什麼查詢模式
2026-06-26 CloudTrail AWS 的 API 層稽核日誌服務，記錄誰在什麼時候對什麼資源做了什麼操作
2026-06-26 Legacy PHP 的安全盤點接手 legacy PHP 專案後的系統性安全審查：credential 掃描、PHP 版本風險、常見漏洞模式的 grep 偵測、.htaccess 防線、檔案權限、外部依賴與掃描工具
2026-05-01 資安教學的審查標準要對應風險不對稱一般教學寫不清楚、讀者學不到、損失停在學習端；資安教學寫不清楚、讀者照做後在系統上產生破口、損失轉嫁到生產端。兩者風險不對稱、審查嚴格度應該對應下游實作代價、不是讀者讀懂程度。資安內容的 audit bar 預設要拉到「讀者會 implement」、不是「讀者會 read」、否則所有寫作便利選擇（含糊敘述、省略邊界、引用而不驗證版本）都會 silent 變成實作端破口。
2026-05-01 False sense of security 是資安寫作的主要失敗模式資安教學內容的失敗模式不是「讀者學不到」、是「讀者以為學到了並照做、實際還有破口」。讀者實作後沒警覺 = 後續驗證、修補、事件偵測都不會被觸發、破口在生產系統長期 silent 累積。識別 false sense of security 句子的判準：讀者讀完後會說「我做了 X 防護所以安全」、卻無法回答「對什麼 threat 安全 / 什麼 deployment 條件 / 什麼前提失效」。
2026-05-01 Threat model 明確性：「防什麼」與「不防什麼」必須對稱資安 mitigation 的論述要對稱寫「防什麼 threat」+「不防什麼 threat」。只寫前者、讀者會自行 universal 詮釋（防所有相關攻擊）、實際只擋作者腦中 subset、是 false sense of security 的主要產地。對稱論述不是讓文章變負面、是讓 mitigation 的 scope qualifier 顯式化、讓讀者能驗證實作覆蓋邊界。
2026-05-01 Mitigation 對位：防護對應到具體 threat 的驗證資安寫作裡 mitigation 寫得乾淨不代表對到 threat、必須讓「mitigation X → 防 threat Y」的對應鏈可被反向驗證。常見失效模式：mitigation 攔的是 threat 的 surface artifact、不是 mechanism；mitigation 跟 threat 在不同抽象層；mitigation 假設 threat 已被上層擋掉但上層沒擋。對位驗證的 audit 模板：每個 mitigation 列出「設計攔的 threat」+「驗證 mechanism」+「失效訊號」三欄、缺一即 false sense of security 產地。
2026-05-01 Mitigation 的 context-dependence：deployment 條件改變有效性同一個資安 mitigation 在不同 deployment / runtime / scale / config 條件下、有效性差異很大、甚至完全失效。寫作時把 mitigation 描述成 universal（「使用 HTTPS 保護傳輸」「JWT 用簽章驗身分」）會跳過 context、讀者實作時用單一條件詮釋、deployment 條件不對時 mitigation silent 失效。每個 mitigation 必須附帶「成立條件」+「失效條件」+「deployment 變數列表」。
2026-05-01 Security 標準引用的時效性與精確度資安 citation 跟一般技術引用不同——best practice 時效短（MD5 / SHA-1 / bcrypt 100k / TLS 1.0 都曾是 best practice）、原文常被引用扭曲（conditional → unconditional drift）、版本不標 reader 會套用過時 spec。citation 同時涵蓋外部標準（OWASP / RFC / NIST / CIS）跟內部 citation（knowledge-cards / 跨章引用作為 control-of-record）；後者因無版本號 anchor 反而更易 silent drift / broken。每條 citation 必須附：版本 / 年份、引用句意可回溯、deprecated / superseded 標記、強度參數對應 actor 能力的 review trigger（外部）/ last-checked + sync owner（內部）。
2026-05-01 Audit recommendation 層級：accept / minor / major / 教錯不可保留資安 audit 的產出不該是「OK / 不 OK」二選、要分層給 ship 決策用：accept（無 weakness）/ minor revise（補 boundary 級小改）/ major revise（結構性 false sense、需重寫）/ withdraw（教錯主動誤導、必須移除或全換）。前三層對應學術 peer review、第四層是資安 audit 特有——當內容會 silent 把 reader 帶向破口時、保留是淨負面、不存在「先 ship 後改」的選項。
2026-05-19 Cross-Reviewer Convergence：多 Reviewer 收斂的 finding 比單 Reviewer flag 信號強 Multi-reviewer audit（4-reviewer / N-reviewer parallel）後、finding priority 不該是 *N 個 reviewer 報告平均合併*、應該按 *跨 reviewer convergence* 加權 — 兩個獨立 reviewer 從不同 axis 各自發現同一 finding 是 *信號收斂*、比單 reviewer flag 信號強 5-10x。Case：MySQL 17 篇 4-reviewer audit、Reviewer A（寫作規範）跟 Reviewer B（跨檔一致性）獨立 flag 同一 finding『4 篇 migration playbook 缺 weight + banner』、是跨軸 convergence、是最 high-priority fix。機制：N 個獨立 axis 隨機 hit 同一 finding 的機率隨 N 增加而 exponential decline、convergence 排除噪音、是 signal-to-noise 的最高比訊號。修法：multi-reviewer audit 後做 *cross-reviewer matrix*、convergence column 自動標 priority bump。
2026-05-22 MySQL Audit Log + SIEM MySQL audit log、general log、slow log、privilege event、SIEM pipeline、retention 與 alert route
2026-05-22 PostgreSQL Security / RLS / Audit Logging PostgreSQL role、grant、Row Level Security、pgAudit、log policy、PII access evidence 與合規路由