it-service@brocent.com
訪問與權限複核
2026 年第三季度，對文件共享、Microsoft 365 站點、應用系統與特權角色的權限確認，含職責分離測試與權限回收證據。
複核已完成且留有證據；本季主題是崗位變動後累積的權限
八個系統中的全部 386 項權限，均在本季度內由具名的業務審批人完成確認，複核完成率連續第二個週期達到 100%。據此回收了 23 項權限，其中 21 項屬於員工崗位變動後仍被保留的權限，而非當初就授錯的權限。
本次識別出兩處控制薄弱環節。一項職責分離衝突仍未關閉：同一人在會計系統中既能創建付款指令、又能審批該指令，目前僅靠人工的「四眼原則」慣例加以緩解，系統層面沒有任何強制約束。其次，投資者關係 SharePoint 站點向十一名員工授予了編輯權限，而實際上六名即已足夠 —— 原因是權限繼承自一個寬泛的用戶組，而非按角色授予。
季末複核狀況
一項權限指某一身份對某一資源在某一權限級別上的訪問。同一個人對兩個共享目錄的讀取權限算作兩項權限 —— 這也是權限總數遠高於帳號數的原因。
四項需要採取行動
證據。 財務經理在會計系統中同時持有付款制單與付款審批兩個角色。該系統本身支援角色分離，但兩個角色被分配給了同一身份。目前的補償性控制，只是由第二人在放款前人工複核銀行文件這一慣例，系統中沒有該複核的任何記錄。
影響。 單獨一個人即可發起並放行付款，且不存在被強制執行的第二雙眼睛；公司也無法向審計師或投資人證明確實進行了第二次複核。這是訪問控制領域後果最嚴重的一項發現。
建議。 從制單人身份上移除審批角色，改由 COO 持有，並指定一名代理人以應對其缺席。若系統無法強制實現，則將付款放行改到銀行門戶自帶的雙人授權流程，並在財務制度中記錄該安排。
證據。 編輯權限繼承自「全體員工」用戶組，而非按角色授予。實際參與投資人材料工作的有六人，其餘五人沒有業務需要。該站點還存放著《Microsoft 365 安全》報告中列出的四條匿名共享鏈接中的全部四條。
影響。 對投資人材料授予過寬的編輯權限，既提高了誤改風險，也擴大了單個帳號被攻陷後的影響範圍。而權限繼承還意味著新入職員工會自動獲得該訪問權。
建議。 斷開權限繼承，創建一個包含六名必需成員的投資者關係角色組，其餘員工設爲無訪問權限，而不是隻讀。
證據。 文件服務器上有四個共享，其訪問權來自最深嵌套三層的用戶組，其中兩個組創建於 2023 年之前，組名已與任何現有團隊對不上。有效權限只能計算得出而無法直接讀取，兩名審批人未經調查無法確認當初的授權意圖。
影響。 當權限無法被直接讀出時，複核也就無法真正進行。確認流程淪爲形式，而這比不做複核更糟 —— 因爲它製造了虛假的保證感。
建議。 將每個共享的每個權限級別扁平化爲單一用戶組，下線那兩個遺留組，扁平化完成後對這四個共享進行計劃外的重新確認。
證據。 兩項行情終端權限的移除分別耗時九天和十一天，原因是該變更需要提交廠商工單，而非本地管理操作即可完成。
建議。 與廠商約定權限變更的服務級別；或者對廠商控制的系統接受一個書面記錄的十天目標，使該指標反映實際情況。
第二季度識別出的三項屬於離職員工的權限，已於 2026-07-14 移除。第二季度那項「運營人員既能修改又能放行交易確認書」的衝突，已通過將放行權移交前台業務主管於 2026-08-05 解決。
五項服務級別中達成四項
| 承諾服務級別 | 目標 | 實際 | 狀態 | 說明 |
|---|---|---|---|---|
| 在本季度內完成複核 | 100% | 100% | MET | 386 項權限，8 個系統 |
| 每個系統均有具名審批人 | 8／8 | 8／8 | MET | 全部確認書均已簽署 |
| 權限回收執行 | ≤ 5 天 | 平均 3.1 天 | MISSED | 23 項中有 2 項超時（廠商系統） |
| 特權角色理由說明 | 100% | 100% | MET | 5 個角色，全部重新說明理由 |
| 季末後報告出具 | ≤ 10 個工作日 | 第 3 個工作日 | MET | 爲期中版本；最終版於 09-30 出具 |
三個週期的變化
| 指標 | 2026 Q1 | 2026 Q2 | 2026 Q3 | 變化方向 |
|---|---|---|---|---|
| 納入範圍的權限項 | 402 | 394 | 386 | 隨累積權限被清理而下降。 |
| 複核完成率 | 78% | 100% | 100% | 自第一季度流程調整後持續保持。 |
| 已回收權限 | 8 | 14 | 23 | 上升，因爲複核現在真正在質疑權限的必要性。 |
| 未關閉的職責分離衝突 | 3 | 2 | 1 | 每季度關閉一項；付款衝突是最難的一項。 |
| 孤立權限 | 7 | 3 | 0 | 已清零；離職流程現在會直接移除權限。 |
| 平均回收耗時 | 6.8 天 | 4.2 天 | 3.1 天 | 持續改善；殘餘延遲來自廠商控制的系統。 |
23 項回收中有 21 項是崗位變動後仍被保留的權限 —— 這正是入職／調職／離職流程中的「調職」環節最值得投入的原因。
按系統的複核覆蓋情況
| 系統 | 審批人角色 | 權限項 | 已確認 | 已降級 | 已回收 | 確認日期 | 說明 |
|---|---|---|---|---|---|---|---|
| 文件服務器共享 | 客戶方 IT 負責人 | 118 | 104 | 5 | 9 | 2026-08-12 | 4 個共享需扁平化 |
| SharePoint 站點 | 站點所有者 | 96 | 88 | 3 | 5 | 2026-08-14 | 投資者站點權限過寬 |
| Microsoft 365 組 | 運營主管 | 64 | 61 | 0 | 3 | 2026-08-14 | 移除 3 個休眠來賓 |
| 會計系統 | 客戶方 COO | 31 | 29 | 1 | 1 | 2026-08-19 | 職責分離衝突未關閉 |
| 行情終端 | 前台業務主管 | 34 | 31 | 1 | 2 | 2026-08-21 | 變更由廠商控制 |
| VPN 與遠程訪問 | 客戶方 IT 負責人 | 22 | 21 | 0 | 1 | 2026-08-12 | 已關閉外包人員訪問 |
| 特權角色（租戶） | 客戶方 COO | 5 | 5 | 0 | 0 | 2026-08-19 | 全部重新說明理由 |
| 網絡設備管理 | BCS 服務經理 | 16 | 14 | 0 | 2 | 2026-08-26 | 共享帳號待替換 |
合計：386 項權限，353 項確認，10 項降級，23 項回收。每一次確認均有簽署的確認書爲證，保存在服務記錄中並可供查閱。
職責分離測試
| 測試的衝突組合 | 結果 | 明細 |
|---|---|---|
| 創建與審批付款 | 存在衝突 | 財務經理同時持有兩個角色；僅有人工四眼原則慣例。未關閉的發現事項。 |
| 修改與放行交易確認書 | 無衝突 | 已於 2026-08-05 解決；放行權現由業務主管持有。 |
| 創建用戶與授予特權 | 無衝突 | BCS 負責創建帳號；特權分配需客戶方 COO 批准。 |
| 管理備份與刪除數據 | 部分緩解 | 其中一個備份集已由不可變性緩解；另兩個仍可刪除 — 參見《備份》報告 BKUP-R01。 |
| 審批自己的權限申請 | 無衝突 | 流程禁止自審批；本季度有兩次嘗試被正確拒絕。 |
訪問例外
| 例外事項 | 批准日期 | 到期日 | 審批人 | 理由 |
|---|---|---|---|---|
| 臨時財務只讀權限 | 2026-08-04 | 2026-09-30 | 客戶方 COO | 運營主管爲審計準備工作提供支援。 |
| 外包人員 VPN 權限恢復 | 2026-08-18 | 2026-10-31 | 客戶方 IT 負責人 | 範圍固定的研究項目；訪問權限僅限一個共享目錄。 |
每一項例外在批准時都必須帶有到期日。沒有到期日的例外不算例外，而按發現事項處理。
跨季度結轉的未決事項
| 編號 | 風險 | 嚴重程度 | 負責人 | 到期日 | 狀態 | 下一步行動 |
|---|---|---|---|---|---|---|
| ACR-R01 | 付款的創建與審批集中於同一身份 — 缺少被強制執行的四眼原則 | CRITICAL | 客戶方 COO | 2026-09-30 | 未處理 | 改派審批角色，或將放行改到銀行的雙人授權流程。 |
| ACR-R02 | 投資人材料的編輯權限過寬 — 繼承自「全體員工」組 | HIGH | BCS Support Center | 2026-09-30 | 未處理 | 斷開繼承；建立六人角色組。 |
| ACR-R03 | 四個共享上的嵌套組氾濫 — 權限無法被直接讀取 | MEDIUM | BCS Support Center | 2026-11-30 | 未處理 | 每共享每級別扁平化爲單一用戶組；計劃外重新確認。 |
| ACR-R04 | 網絡設備的共享管理員帳號 — 操作無法歸因到個人 | MEDIUM | BCS Support Center | 2026-10-31 | 處理中 | 改爲由身份系統支撐的具名帳號 —— 參見 CONF-R01。 |
| ACR-R05 | 廠商未承諾權限變更的服務級別 — 回收目標無法達成 | LOW | BCS + 客戶方 IT | 2026-12-31 | 未處理 | 與廠商約定目標，或爲這些系統書面確定 10 天目標。 |
下一週期承諾事項
| BCS Support Center 將 | 需要客戶配合 |
|---|---|
| 斷開投資者站點的權限繼承，並建立角色組。 | 將付款審批角色從制單人身上剝離。 |
| 將四個嵌套組共享扁平化，並計劃外重新確認。 | 確認哪六名員工需要投資人材料的編輯權限。 |
| 以具名帳號替換網絡設備的共享憑據。 | 確認兩項訪問例外是否按期到期。 |
| 在 2026-09-30 季末後出具第三季度最終版報告。 | 在 2026-10-07 前指定第四季度複核週期的審批人。 |
本報告的產生方式
| 資料來源 | 擷取時間 | 記錄數 | 用於 |
|---|---|---|---|
| 文件共享 ACL 導出 | 2026-08-10 21:00 香港時間 | 118 項權限 | 解析用戶組後，各身份對各共享的有效訪問權。 |
| SharePoint 權限報表 | 2026-08-12 21:00 香港時間 | 96 項權限 | 站點與文檔庫權限、繼承狀態。 |
| Entra ID 組與角色 | 2026-08-12 21:10 香港時間 | 69 項權限 | 組成員關係、來賓訪問、特權角色分配。 |
| 應用系統角色導出 | 2026-08-18 | 65 項權限 | 用於職責分離測試的會計與行情終端角色。 |
| 確認書記錄 | 2026-08-26 | 8 份確認書 | 審批人身份、決定、日期與備註。 |
| HR 花名冊 | 2026-08-29 | 41 名員工 | 崗位核驗與調職識別。 |
方法與定義
權限項 指某一身份對某一資源在某一權限級別上的訪問。通過用戶組獲得的權限歸屬於個人而非用戶組，因此複核質疑的是有效權限，而不是名義上的組成員關係。
確認（Certification） 要求由具名的業務審批人 —— 絕不能僅由 BCS —— 對每一項權限記錄「確認／降級／回收」的決定。沒有記錄決定的權限項計爲未完成，而不是已確認。
職責分離衝突 依據與客戶約定的五組不兼容角色的固定矩陣進行測試。僅靠人工慣例緩解的衝突仍按衝突報告 —— 因爲它事後無法舉證。
排除範圍。 帳號是否存在及其 MFA 狀態在每月的《系統帳號管理》報告中呈現。租戶級的共享配置在《Microsoft 365 安全》報告中呈現。辦公場所的物理門禁不在託管服務範圍內。
本文檔爲用於展示的匿名化樣本。客戶名稱、系統名稱、角色名稱、共享名稱與審批人身份均已替換爲虛構或通用值；數量、比例、日期與發現事項反映的是一個具有代表性的受管環境。文檔中不含任何真實客戶數據。
BCS Support Center · it-service@brocent.com
客戶常問的關於本報告的問題
每一個身份對每一項資源在每一個權限級別上的訪問，都會呈交給一位具名的業務審批人，由其記錄「確認／降級／回收」。Brocent 絕不代客戶確認權限 —— 沒有業務方書面決定的權限項計爲未完成，而不是已確認。
依據與客戶約定的一組不兼容角色配對的固定矩陣進行測試 —— 例如創建付款與審批付款。僅靠人工慣例緩解的衝突仍會按衝突報告，因爲它事後無法舉證。
對權限項與特權角色而言，多數投資人盡職調查問卷預期的是每季度一次；而離職當天的權限移除，則由每月的帳號流程處理，不必等到複核週期。
看看你自己的訪問與權限複核報告會寫些什麼
免費 IT 健康檢查會針對你的真實環境產出本報告的第一版，不收費、無義務。整個過程約需一週，佔用你團隊幾個小時。