香港支付公司的HKMA滲透測試要求

摘要： 一家持牌香港支付公司收到一次例行監管審查請求，其中一項要求是提供滲透測試的證據——公司精簡的資訊團隊這才意識到，「證據」不只是兩年前某次掃描留下的一份PDF。這是一個複合的示範情境，並非指涉任何一家真實客戶。本文討論測試從一次性事件變成持續節奏之後會發生什麼改變，以及資訊夥伴的營運角色止步於何處、企業自身的法遵與法律判斷從何處開始。

持牌機構，以及一個不會在發照後就消失的監管者

香港有相當數量的持牌支付與貨幣服務企業——儲值支付工具（SVF）營運商、貨幣服務營運商，以及以資金移轉或支付處理為核心業務的公司。取得牌照是一個里程碑，但牌照之後發生的事，從外部往往不容易被看見：香港金融管理局及其管理的相關框架，對持牌機構如何管理科技風險持續保持關注——這不是發照時勾選一次就結束的事項，而是一段持續的監理關係。

這種關注對不同機構呈現出不同形式——定期申報、臨時的資料索取、現場或非現場審查，以及由業界其他地方發生的事件所觸發的詢問。就HKMA與科技風險相關指引通常被公開描述的方式而言，業界普遍理解持牌機構被期望能夠證明自己理解並主動管理自身的科技風險，包括其應用系統與基礎設施可能存在可被利用弱點的風險。某一次具體審查究竟會索取什麼、按什麼節奏、依據什麼具體標準，這是HKMA與機構自身法遵職能之間的判斷，而不是資訊服務商能夠代為預測或承諾的事情。以下內容描述這類問題在實務上常見的樣貌，以及Brocent對其中營運層面工作的自身理解，這些理解都根植於Brocent在香港金融服務產業的實際工作經驗。

持有這類牌照的公司往往比在HKMA相關監理議題中更常被提及的銀行與保險公司要小得多。一家員工不到百人的支付或貨幣服務營運商，很少配備銀行那種規模的專職法遵部門，甚至常常根本沒有專職的資安職位——負責回答監管審查中技術問題的人，往往同時也是管理服務台工單和雲端主機帳單的那個人。這不是對這類企業經營方式的批評，而是精簡型支付企業面對的真實營運現實——也正是在這種現實下，臨時性的測試做法最容易生根，因為沒有人有餘力在其他所有事務之外，再去持續擁有一套標準化的測試專案。

為什麼這類客群與銀行、保險公司不同

公開討論較多的香港金融IT議題，往往集中在避險基金、家族辦公室與保險經紀這類法遵人力較充足、測試專案（若已存在）通常也相對成熟的細分領域。持牌支付或貨幣服務企業是一個明顯不同的客群：通常規模更精簡、業務歷史更短，而且往往是在平台已經明顯超出最初設計範圍之後，才第一次面對針對自身科技態勢的正式監管審查。本文所描述的落差，對這一細分領域而言並非一種假設性的邊緣情形，而更接近預設的起點——這正是為什麼營運層面的補救措施在這裡比一句籠統的「多做測試」建議更具實際意義。

一次審查請求，對不上公司手邊的證據

設想一家員工約50至90人的香港持牌支付公司。它穩步成長——新增的商戶對接、持續成長的交易量，以及多年來陸續疊加在原有平台上的幾條新產品線。它的資訊職能規模不大：幾個人維持平台運作、開發功能、處理日常支援。安全測試並非從未發生過，只是發生的方式和許多同等規模的公司一樣——被動反應式的。某家有意合作的銀行在開立結算帳戶前要求提供一份滲透測試報告，於是公司委託做了一次。一年後，某個大商戶自己的供應商安全問卷又問了同樣的問題，公司再跑了一次掃描。沒有人負責一套持續性的測試專案；測試始終是對「最近是誰在問」的回應，而不是任何人行事曆上的固定事項。

隨後，一次常規的監管審查到來——是一次週期性的檢查，並非由某個事件觸發，是持牌機構理應預期時不時會面對的那種審查。其中一個問題公司先前非正式地回答過，但從未真正好好整理成文件：你們的滲透測試專案是什麼，能否提供相關證據。公司翻出手邊能找到的資料：大約兩年前做的一次測試留下的PDF，那次測試是為了配合銀行開戶流程而委託的，並非出於自身風險管理的主動安排。此後再無任何紀錄。對於當時具體測試了什麼，也說不清楚——是面向公眾的支付API、商戶入口網站，還是內部網路，抑或三者皆有？當時決定測試範圍的人，如今已經沒人還在公司裡。

正是在這一刻，落差變得顯而易見。這不是因為公司管理鬆散——平台整體運作得還算穩健，原本那次測試也不是造假或敷衍的——而是因為測試從未被當作一套專案來建構，它只是對最近誰在追問而做出的一系列一次性回應。

「我們做過一次掃描」實際上暴露了什麼

一旦公司真的要向審查方拿出自己的測試歷史，而不只是口頭聲稱「我們做過測試」，通常會浮現三個問題：

沒有帶日期的證據鏈。 兩年前的一份單一報告，只能回答「你們是否測試過」，回答不了「你們目前是否維持著經過測試、狀態更新的安全態勢」。審查方看到一套明顯已經改變的技術堆疊——新的對接、新的產品線，也許還有新的基礎設施——卻無從判斷這些變化是否曾被測試過。
測試範圍不清楚。 即便報告確實存在，公司也未必能確切說清它涵蓋了什麼。是只測了外部網路，還是也包含了網頁應用層？上次測試之後新增的API端點有沒有被納入？一份沒有清楚保留範圍說明的報告，很難被當作對任何具體事項的現行證據來使用。
在截止日期前倉促補測。 一旦落差被發現，本能反應是立刻預約一次測試——但合格的測試團隊往往需要提前數週預約，而在截止日期壓力下倉促安排的測試，其起點其實比按計畫安排的測試更糟。僅僅為了回答某一次審查而委託的測試，而不是作為持續專案的第一個週期，往往會重複公司本想擺脫的那種一次性模式。

這三個問題其實都與任何單次測試本身的品質無關，而是關乎圍繞單次測試的專案結構是否存在——正是這套專案結構，才能把「我們做過一次測試」變成「我們持續維持一個經過測試、狀態更新的環境，並且能準確展示給你看」。

Brocent的角色從哪裡開始、又止步於何處

在這類情境中，清楚說明一家資訊與資安夥伴能做什麼、不能做什麼，是很有必要的——因為正是在這種情況下，如果服務商誇大自己的角色，對持牌機構沒有任何好處。

Brocent在這類情境中扮演的角色是營運性的，而非監理性的。具體而言：透過針對公司實際環境量身訂定範圍的滲透測試專案來執行實際測試——使用持證測試人員，並提供帶有概念驗證證據、按CVSS評分的發現結果——按公司自行設定並堅持執行的節奏進行；維護文件紀錄與帶日期的報告，使其隨時間累積成一條證據鏈；協助公司的法遵團隊以清楚的營運語言理解測試了什麼、何時測試的、發現了什麼以及如何修復的。Brocent不做、也不應該被期待去做的事情是：告訴持牌機構其監理方會認為什麼才算充分，認定某一套測試節奏滿足了HKMA的某項具體要求，或者替代公司自身的法遵與法律顧問去解讀某次審查究竟要求什麼。這些判斷屬於公司自身的法遵職能，以及在適當情況下的外部法律顧問——而不屬於任何技術服務商，無論其經驗多麼豐富。任何聲稱能替代這些判斷的夥伴，都是在承諾自己實際上無法兌現的東西。

這種分工值得直白地再說一次，因為對於一支被拉得很緊的五人資訊團隊來說，很容易希望事情比實際更簡單：任何服務商，無論資質多高，都無法給持牌機構一張寫著「合規」的證書。Brocent能夠給到公司的，是一份證據——帶日期、有範圍、已修復、保持更新——公司自身的法遵職能可以據此向自己的監理方闡述立場。證據是Brocent的工作。這份證據對某次審查而言是否足夠，這個判斷是公司自己的工作，需要透過其法遵與法律顧問來行使。把這兩件事混為一談，正是公司容易出問題的地方——要麼是因為服務商暗示「合規的事我們已經搞定」而投入不足，要麼是過度依賴某一次早已過時的測試結果。

持續測試節奏在實務上的樣子

從臨時性測試到持續性專案，兩種狀態之間的實際差別，歸結起來是幾個具體習慣，而不是理念上的轉變：

固定週期的節奏，而不是一次性預約。 不再只是有外部方問起才委託測試，而是按公司自己選定並能夠說明理由的固定週期運作——常見做法是至少每年一次，對於直接處理支付資料的系統，有時會更頻繁。Brocent自己的滲透測試專案正是按這種節奏設計的，年度測試套餐中包含修復後的複測，而不是一份單一時間點的報告。
保留帶日期的報告，形成持續更新的證據鏈，而不是需要時才臨時找出的單一檔案。每個週期的報告、範圍說明和修復紀錄不斷累積，形成一段歷史，法遵負責人可以直接交給審查方，而不必在時間壓力下臨時重新拼湊。
每個週期都重新檢視測試範圍，而不是預設範圍一成不變。 如果公司自上次測試以來新增了面向商戶的API、將部分基礎設施遷移到新的雲端環境，或推出了新產品線，實際上就等於新增了未經測試的攻擊面。在每個週期開始時重新檢視範圍——而不是預設沿用上一次的測試計畫——正是讓證據鏈真正貼合目前環境（包括雲端託管的部分）的關鍵。
清楚區分掃描與測試，各自按其適當的節奏獨立運作，而不是混為一談。弱點掃描是自動化的、涵蓋面廣的，適合更頻繁的節奏；滲透測試是人工的、更深入的，適合頻率較低但更徹底的節奏。如果一家公司只做其中一項，無論缺的是哪一項，都是一個實實在在的缺口。

這一切並不需要多麼特殊的工具，也不需要龐大的內部資安團隊。它需要的是把測試關係建構成一套有明確負責人的持續專案，而不是每次外部有人提問才發生的一筆交易。

香港支付公司應對滲透測試的三種方式

沒有正式專案。 只有當客戶、銀行合作方或商戶直接索取證據時才做測試。沒有固定週期，測試範圍也不一致——正如上文情境所示，一旦審查方問出一個公司先前從未以書面形式回答過的問題，風險曝露就會立刻顯現。
歸檔保留的一次性測試。 比什麼都沒有要好：至少存在一份帶日期的報告。但面對一個持續變化的平台，單次測試很快就會過時，它回答的是「是否測試過一次」，而不是「目前是否在測試目前實際運行的系統」。
具備持續證據鏈的固定測試節奏（Brocent模式）。 測試按照公司自己擁有並能夠說明的週期運作，每個週期都對照目前環境重新檢視範圍，報告與修復紀錄不斷累積成一段站得住腳的歷史，公司的法遵團隊可以隨時提出這段歷史——而關於什麼才算「充分」的監理判斷，則始終留在它本應歸屬的地方：公司自身及其顧問手中。

常見問題

弱點掃描能滿足滲透測試方面的要求嗎？

通常不能單獨滿足——這是兩種不同的活動。弱點掃描使用自動化工具，在較大的涵蓋範圍內找出已知弱點；滲透測試則由持證測試人員主動嘗試利用這些弱點、將它們串聯起來，並展示真實世界中的影響。如果審查方明確詢問的是滲透測試，通常不太可能接受一份掃描報告作為等同的證據，不過這兩者是互補的，成熟的專案通常會按各自適當的節奏同時進行兩者。某個具體監理方或某次具體審查是否接受以其中一種取代另一種，這屬於公司自身法遵判斷的範疇，而不是服務商應代為斷言的事情。

持牌機構應該多久測試一次？

沒有一個適用於所有公司的統一數字，Brocent也不會將某個具體頻率斷言為監理要求。實務上，處理支付資料的公司常見的做法是至少每年一個週期，若發生重大變化——新的面向外部的系統、重大的基礎設施遷移、涉及客戶資金的新產品線——則會觸發額外測試。對某家具體公司而言合適的節奏，是一個需要公司自身法遵與風險職能參與、並根據其實際風險狀況來判斷的決定。

一份測試證據鏈應當包含什麼？

至少應包括：每個測試週期對應的帶日期報告、清楚說明具體測試了什麼（系統、環境、測試類型）的範圍說明、附帶嚴重程度評級的發現結果，以及顯示修復了什麼、何時修復的修復紀錄——理想情況下還應有確認修復到位的複測。目標是讓法遵負責人能夠向審查方呈現一幅清楚、按時間順序排列的圖像，而不必從散落的檔案中臨時拼湊歷史。

誰來判斷我們的測試專案是否充分？

由公司自身，連同其自身的法遵職能，以及在需要時的外部法律或法遵顧問來判斷——並以適用於其牌照與業務的具體監理期望為依據。資訊或資安服務商，包括Brocent在內，可以描述自身測試專案做了什麼，並提供公司所需的證據，但不能、也不應該告訴公司某套專案滿足了某項具體的監理標準。這個判斷屬於公司自身，並且這與執行測試本身的營運工作，本質上是兩種不同性質的判斷。

同一家服務商能否同時負責掃描和測試？

可以——這是相當常見的做法，因為同一家服務商對同一環境在兩項活動中都有可見性，往往能夠維持更一致的文件紀錄。但這並非必須；有些公司會刻意為測試與更廣泛的受管資訊服務關係分別選用不同的服務商。對證據鏈而言，真正重要的是無論由哪家服務商執行測試，都按照一致的節奏進行，並保留帶日期的紀錄——而不是具體採用哪一種服務商組合方式。

如果審查發現先前沒有測試紀錄，會發生什麼事？

這屬於公司與其監理方之間的事情，Brocent不會對具體的監理後果進行推測。資訊夥伴能夠掌控的，是協助公司從那一刻起迅速而有說服力地做出回應——及時界定範圍並進行測試，更重要的是，從此建立起持續性的專案，避免同樣的落差在下一次審查中再次出現。公司對某項發現的應對方式，以及這種應對如何被看待，通常在很大程度上取決於事後發生的改變，而不僅僅是最初的那個落差本身。

雲端託管的基礎設施會改變需要測試的內容嗎？

它改變的是需要納入範圍的內容，而不是是否需要測試這件事本身。一個部分或全部運行在雲端的支付平台，依然存在攻擊面——API、網頁應用層、身分與存取設定，以及根據雲端服務商的責任共擔模式，公司自身直接負有測試責任的某些基礎設施層面。前文所述的「每個週期重新檢視範圍」，正是為了捕捉這類變化——自上次測試以來的一次雲端遷移，恰恰是應當觸發重新檢視測試範圍的那類變化。

把測試節奏納入受管資訊服務方案，而不是一次次單獨預約

這個情境中的公司，其實並不是孤立地存在一個「測試問題」——它存在的是一個「專案問題」，而測試只是恰好最先讓它顯現出來的地方。只要仔細看，同樣的落差往往也會出現在其他地方：修補節奏、備份驗證、存取權限審查——所有這些持續性的營運紀律，對一支同時還要交付產品的五人資訊團隊來說，做一次容易，持續做則很難。

這正是為什麼Brocent把持續的測試節奏定位為受管資訊服務方案本身的一部分，而不是每次審查方提問時才單獨商定的一次次預約。該頁面上按使用者計費的受管資訊服務方案，正是圍繞這種持續性營運紀律建構的——安全測試、修補管理、監控與文件紀錄按固定節奏運作，作為這段合作關係中一項常態化的內容，而不是每次需要時才在截止日期壓力下從零拼湊。對一家持牌支付公司而言，這種持續性才是真正的產品：不是某一次通過的測試，而是無論下一次何時被問起「給我們看看你們的測試專案」，都能給出一份站得住腳、狀態更新的答案。滲透測試——以及對於環境需要更深入測試層級的公司而言，更高階的Red Team進階滲透測試選項——都作為該方案內的附加項存在，而不是終點本身；真正讓節奏在各次測試之間持續運轉的，是這套方案。

如果貴公司正面對一次審查請求，而對自己現有的測試歷史並不滿意，務實的下一步是先展開一次對話，而不是倉促預約一次測試。歡迎查看受管資訊服務方案的定價，或與我們聯繫，一起討論適合貴公司具體環境的持續測試節奏應該是什麼樣子——以及在監理這一側，Brocent的營運角色如何與貴公司自身的法遵與法律判斷相互配合。