Day 21：一套完整性監控，最容易死在「合法的變動」手上

延續合規落地的主題，今天談檔案完整性監控（FIM）——一個聽起來很正派、很容易寫進稽核報告的東西，但它真正的難處不在技術，在一個很不起眼的地方：你有沒有把「哪些變動其實是合法的」盤點乾淨。這篇有意思的是，它同時出現兩個方向的把關——有時候是我踩 AI 的剎車，有時候是 AI 踩我的。

起點：一個想拿去跟稽核交代的機制

我手上已經在做一件事：排程比對部署目錄跟 git 基準版本的差異，抓有沒有人繞過正常流程、直接改了主機上的程式碼。我問 AI：把這個納入排程之後，我是不是就可以跟稽核說系統「使用完整性驗證工具，偵測未授權變更特定軟體及資訊」了？

我以為 AI 會順著我。結果它踩了我剎車。

AI 反過來踩我剎車：別宣稱過頭

AI 的回答很直接：可以往這方向做，但要拿去跟稽核交代，先誠實看清楚它「實際能涵蓋到什麼範圍」，別宣稱過頭，被稽核方一問細節就站不住腳。然後它把這個 git 比對機制的缺口一條條攤開：

• 只涵蓋 git 追蹤的檔案。 套件本身、環境設定檔、上傳檔案這些通常被 git 忽略，比對完全看不到；容器映像檔本身、容器內的系統檔案、作業系統層設定檔更是 git 管不到。稽核如果追問「那套件有沒有做完整性檢查」，這招答不出來。
• 防不了「透過 git 流程本身推進來的惡意變更」。 如果攻擊者是帳號被盜、或內部人員，用正常流程推了一筆惡意 commit，那筆 commit 一旦變成最新版，比對結果就是「乾淨」——因為它本身就成了新的基準值。

這一輪值得記，因為它跟這個階段的預設印象相反：不是我在防 AI 亂講，是 AI 在防我把一個半套的機制拿去對稽核說滿話。它甚至幫我改了一個更精確的說法，把「使用完整性驗證工具」這種大話，收斂成「針對應用程式原始碼目錄，定期比對與版本控制基準之差異」這種一問細節也不會垮的敘述。AI 守住的是誠實，而這件事，人反而容易在稽核壓力下鬆手。

換我踩 AI 剎車：AIDE 撐不撐得住

既然 git 涵蓋不到套件跟系統檔案，那就補一套真正的 FIM 工具（AIDE）。AI 給了一張很清楚的分層地圖：主機系統檔案該用 AIDE、業務資料的實體掛載點該用 AIDE、映像檔分層用它訊噪比太差、容器內部它幾乎看不到——每一層用對應的工具，而不是靠一個 AIDE 硬撐所有情境。這是它的守備範圍，答得又快又整齊。

但它在建議「業務資料的實體掛載點也用 AIDE 監控」時，漏了一個只有我知道的現實。我戳了一句：這些業務資料動輒幾十 GB，其中影像資料甚至是幾十 TB，AIDE 撐得住嗎？

AI 立刻修正，而且修得很誠實：「不是撐不撐得住的問題，是用途不對。」AIDE 的運作方式是把監控範圍裡每個檔案都算一次雜湊、下次全部重算比對，套在幾十 TB、每天都有大量正常新增的業務資料上，只會得到每天幾萬筆「異動」報告、幾乎全是雜訊，真正的攻擊反而被淹沒。FIM 這個概念，本來就只該用在「內容應該固定、任何改動都值得警覺」的東西上——程式碼、系統設定檔；業務資料是動態的，該用的是備份/快照加存取控制，不是逐檔比對。

於是分類就清楚了：內容固定的（程式碼、套件）用唯讀掛載加比對監控；內容持續變動的（業務資料）不設唯讀，改用備份快照確保救得回來。 兩種資料，兩套邏輯。

那個上線當晚就狂響的警報

分類講到這裡，我想起自己以前踩過的一個坑，就順口跟 AI 講了：我以前自建過完整性驗證，針對網站資料夾算雜湊值、跟手上的基準比對，不一樣就發告警信、還把整個網站打包起來。結果好死不死，有一支排程會定時丟檔案進那個資料夾提供下載——上線當晚，警報就狂響。

AI 沒有把這當一句閒聊帶過，它把這個親身教訓昇華成整篇最重要的一句話：完整性監控最大的風險不是工具本身，而是有沒有把所有「合法會變動的來源」都盤點清楚。 我那次出包，不是雜湊比對這個方法錯了，是漏掉了一個合法、但我當下沒意識到的變動來源（那支排程）。

然後它給的解法，全部圍繞這條原則打轉，而不是叫我換更強的工具：

• AIDE 天生就把「檢查」跟「更新基準值」分成兩個動作——它不是要你「永遠不准變」，而是「每次合法變動後，有人確認過、手動按下更新」。這樣一來，告警的定義就變成「沒有經過變更流程的異動」，而不是「有變動就吵」。
• 把「變更後更新基準值」寫進變更管理流程，而不是期待工具自己聰明分辨——半夜跳告警時，你可以直接回頭問「這個時間點有沒有人送變更單」，答案是沒有，那才是真正該緊張的。
• 導入前先讓它跑一週「只記錄、不告警」，把這台機器背景到底有哪些你意料之外的變動來源先抓出來——這正是我上次沒做、才會「上線當晚就爆」的那一步。

還有一條 AI 提的捷徑：與其偵測，不如讓它根本改不了

前面兜的一大圈——git 比對、AIDE、盤點合法變動來源——本質上都是「事後偵測」：讓你在東西被改之後知道它被改了。但在討論怎麼防網站程式碼被置換時，AI 丟回一個我沒料到、而且簡單得多的方向：與其花力氣事後比對，不如把容器裡那個程式目錄直接掛成唯讀（:ro），從源頭擋掉寫入。

這招之所以成立，是因為要盯的那個目錄——放網站程式碼的地方——正好就是漏洞最想寫入的目標；而它在正常運作下根本不該被改。既然如此，把整個目錄的寫入權限收掉，就比裝一套工具去盯它、再逐筆判斷改動合不合法，省事也徹底：偵測是「讓你知道被改了」，唯讀是「讓它改不了」。這也剛好收束了前面那條分類——內容固定的程式碼用唯讀焊死，會變動的業務資料才交給監控與備份。

這一天的分工

這篇的分工是雙向的，比大多數篇章都對稱。

AI 守住兩件我容易失守的事：一是誠實——在我想把半套機制拿去對稽核說滿話時，它踩了剎車、幫我把話收到站得住腳的範圍；二是體系——它對「哪一層該用哪種工具」的分層地圖、對 AIDE 檢查與更新基準值分離的正確用法，都是紮實的領域知識，我補不出來。

我守住的是現場：git 涵蓋不到什麼、業務資料有幾十 TB、那支半夜丟檔案的排程——這些是 AI 再博學也拿不到的事實與教訓。尤其最後那個上線當晚的警報，它不是知識，是痛過的經驗；而 AI 的價值，是把我這個具體的痛，抽象成一條「盤點所有合法變動來源」的通則，讓它下次能用在別的地方。

所以這篇的主軸，比「知識可外包、判斷不行」多了一層：判斷不是只有人在做，好的協作是兩邊各自守住對方容易失守的那一塊——AI 守誠實與體系，人守現場與經驗。

明天接著談完整性監控延伸出來的一條線：為了讓程式碼目錄唯讀，log 沒地方寫了、只能往標準輸出丟——那這些 log 要收到哪去、怎麼長期保存供稽核？這個問題，把我推向了自建一套集中式 log server。