在 CCoP 2.0 下，檔案進入看起來是什麼樣子

本區域的每一套控制措施都要求縱深防禦，而新加坡針對關鍵資訊基礎設施的 Cybersecurity Code of Practice 也不例外。這是那種能在審查會議中存活下來的說法，因為沒有人會反對它。

若按字面理解，這也是在談一條鏈中控制措施的種類，而不是數量。這個區別在多數資安情境中幾乎沒有作用，因為各層確實不同：防火牆、身分控制與端點代理程式並不是同一概念的變體。但在檔案進入這件事上，它就非常重要，因為這是組織經常把三到四個控制措施疊在一起，而這些措施其實都用同一種方法回答同一個問題的唯一路徑。

誰在適用範圍內，以及哪些地方改變了

《Cybersecurity Act 2018》賦予 Singapore 的 Cyber Security Agency 指定橫跨十一個產業的關鍵資訊基礎設施的權力，這些產業包括能源、資訊通訊、水務、醫療保健、銀行與金融、安全與緊急服務、航空、陸路交通、海事、政府與媒體。經過指定後，Code of Practice 才會從指引轉變為法定義務。

《Cybersecurity (Amendment) Act 2024》大幅擴大了適用範圍。自 2025 年 10 月 31 日起，新的 Part 3A 會涵蓋那些並未擁有其所依賴基礎設施的基本服務供應商，以及雲端服務供應商與資料中心營運者。如果貴組織在幾年前曾認為這套制度屬於別人，因為你們是租用而非擁有，那麼這個結論值得重新確認。

CSA 於 2026 年 7 月 22 日宣布，Code 將再次更新，以因應進階持續性威脅與 AI-enabled attacks，並且會依照相同時程另行制定一份適用於 Cloud Services 的 Code。該公告也提到與更新後 Code 相關的 Cyber Trust Mark Level 5 certification，這正是值得留意的訊號：當一個自願性標章與一份具約束力的文件並列提及時，往往會變成所有向該產業銷售產品者的採購篩選條件，不論是否已被指定。

檔案實際從哪裡進入

「File ingress」聽起來像是一件事。在 CII 環境中，它通常有七種，而且很少由同一個團隊負責。

1. 電子郵件附件，大家都想到過，而且這也是大多數控制圖所顯示的唯一路徑。
2. 供應商與客戶入口網站：上傳表單、理賠提交、投標回覆、 入職文件。通常由應用程式團隊建置，並以當天應用程式框架所提供的任何機制來保護。
3. 受管檔案傳輸與排程交換，與交易對手之間進行，控制設計著重於可用性與對帳，而不是內容。
4. OT 供應商資料：韌體映像檔、組態檔、PLC 專案檔、 試運轉文件。這條路徑帶來最高的後果，卻幾乎沒有檢查，因為格式是專有的，而且維護視窗很短。
5. IT 與 OT 邊界上的可移除媒體，正式 policy 通常禁止， 但實務上通常會容許，因為供應商工程師帶著筆電和截止期限已經到了。
6. 與第三方共用的雲端儲存與協作介面，檔案到達時，並未經過任何操作員會認為是邊界的東西。
7. 備份與還原路徑，會重新引入在某個更早時間點已被允許進來的檔案，當時所適用的控制是什麼，就依那時而定。

先把這七條路徑對照你自己的環境寫下來，再來爭論引擎。這個練習通常比任何產品比較更能消除風險，因為常見的發現不是某個控制措施很弱，而是七條路徑中有三條從來就不在任何控制措施的適用範圍內。

為什麼把相似控制措施疊加起來不算縱深

先挑一條有防護的路徑，看看是什麼在防護它。

典型的 inbound chain 會先經過一個 gateway engine，再經過第二個使用不同供應商 signatures 的引擎，然後可能再加上一個 sandbox。三個產品、三張發票、三個儀表板。問它們各自在回答什麼問題，答案都一樣：這個檔案是否惡意？問它們各自如何判斷，方法也很相似：對已知惡意樣本做 pattern matching、對結構做 heuristics，以及觀察檔案在某個環境中可能會或可能不會選擇顯露自身的行為。

當兩個控制措施共用同一種方法時，它們也共用這種方法的盲點。以 signatures 為基礎的偵測，會落後於新樣本，落後多久取決於樣本被蒐集、分析與散布所需的時間，而再加一組 signatures 只會縮短這個時間窗，並不會把它關閉。sandbox 的效果只取決於它的設計是否完善：如果檔案會檢查 sandbox，或是會等待，或是需要一次 sandbox 不會執行的點擊，那它就會表現得完美無缺。把它跑兩次，只會得到兩次同樣好的表現。

三個控制措施對同一個問題做取樣，這是一種一致性測試。它告訴你這些引擎彼此一致，但不會告訴你檔案是安全的，而在一份要求縱深的 Code 之下，這仍然只是同一層，只是被報成三層。

從這個片語所宣稱的意義來看，深度至少需要鏈中的一項控制，必須以完全不同的路徑得出其判定。這是一個類別，不是一個產品，而且有好幾種：依檔案類型與來源進行 allowlisting，讓意外格式根本無法進入 parser；透過 protocol break 強制重新建立內容，而不是轉送；依文件的格式規格進行 deterministic rebuild，讓一個沒有人見過的檔案與人人都見過的檔案得到相同結果；將 rendering 步驟隔離，讓 parsing 發生在一個無關緊要的地方。

每一種都有實際成本，與其假裝沒有，不如把它們說清楚。Allowlisting 會產生例外，而例外會不斷累積，直到清單只剩裝飾作用。Protocol break 會增加延遲，OT maintenance windows 未必能容忍。Rebuilding 會改變檔案，這在交易對手預期 byte-identical document，或 signature 必須保留時就很重要。Isolation 只是把風險移走，並沒有消除風險。若誠實看待這些成本來選擇控制組合，在醫院與在港口，結果會很不一樣。

能通過評估的解讀

CCoP 要求持續監控、涵蓋 IT 與 OT 的行為異常偵測，以及足以支援調查與稽核驗證、且可按需調閱的保存。這些義務關乎看見與證明。上面的深度論點則關乎決定，而兩者在一個實務點上交會：當評估人員詢問某條路徑如何受到防護時，會接受一串相似的 engine，但這串 engine 的描述最後會濃縮成一句話，而那句話就是，這條路徑上的一切都以相同方式決定。

對金融機構而言，MAS Technology Risk Management Guidelines 以不同措辭提出了平行的期待：透過 email、upload portal 或 third-party exchange 進來的不受信任檔案，會在邊界處理，而不是先放行再事後審查。

這兩份文件都沒有點名任何技術，而且本來就不該點名。它們真正要問的，歸根究柢，是營運者能否描述檔案所經過的路徑，以及每一步套用的推理。七條路徑，每一步一種方法，並在方法重複的步驟旁誠實註記：那份文件只需要一個下午就能寫完，而正是它讓其餘對話變得合理。

更完整的控制對應與文件細節請見我們的 Singapore compliance page。