跳到主要內容

IL 202 · 模組 2

權限與整合

分角色測試最小權限、設計唯讀連接,並演練失效與撤權情境。

開始第一節
已完成 0 / 3

學習目標

  • 為每個角色定義最小必要權限,而不是沿用現成的管理員帳號。
  • 設計並測試唯讀優先的系統整合方式。
  • 演練帳號失效、離職與撤權情境,確認權限即時生效。

最小權限矩陣

60 分鐘

為每個角色寫出「剛好夠用」的權限

Prototype 階段常見的做法是所有人共用一組高權限帳號,方便快速試錯。進入 Pilot 前,必須把權限拆到角色層級,讓每個角色只有完成任務所需要的最小存取範圍。

存取矩陣範例(SYN-CS-001,合成角色)
角色可存取資料/功能不應擁有的權限
客服人員讀取知識庫文件、AI 草稿工具、送出回覆修改知識庫文件、匯出完整客戶資料庫
客服主管讀取案件統計、覆核 AI 草稿品質報表直接變更權限設定、刪除案件紀錄
知識庫維護人員新增/更新/下架知識庫文件存取客戶個人資料、AI 工具設定
技術管理員設定 AI 工具連接、監控系統狀態讀取個別客戶案件內容

注意

常見錯誤:用「這個人平常什麼都要用到」當理由給予寬鬆權限。最小權限矩陣要問的是「完成這個角色定義的任務,最少需要什麼」,不是「這個人可能需要什麼」。
  1. 第一步
    列出所有會接觸這個解決方案的角色(不是個人姓名)。
  2. 第二步
    為每個角色寫出最小必要的資料與功能存取範圍。
  3. 第三步
    找出目前實際帳號權限超出矩陣範圍的落差,列為待收斂項目。

重點: 最小權限矩陣描述的是「角色需要什麼」,不是「現有帳號已經有什麼」。

唯讀優先的整合測試

60 分鐘

優先用唯讀連接測試整合可行性

與既有系統整合時,先用唯讀連接驗證資料格式、更新頻率與延遲是否符合需求,確認可行後才考慮開放寫入權限。唯讀優先可以大幅降低「AI 工具意外寫壞正式系統資料」的風險。

整合測試記錄欄位
欄位說明
連接方式API/資料庫唯讀複本/匯出檔案,優先順序由左至右
測試日期與版本對應的系統版本與測試腳本版本
資料一致性檢查抽樣比對來源系統與整合結果是否一致
延遲與更新頻率資料同步的實際延遲,是否符合業務需求
失敗案例連線中斷、格式變更、逾時等情境下的實際行為

資訊

如果業務需求真的需要寫入既有系統(例如自動更新案件狀態),寫入範圍必須明確限定在特定欄位,並且有獨立的稽核記錄,不能與唯讀查詢共用同一組權限。
  1. 第一步
    用唯讀連接測試資料格式與延遲是否符合需求,記錄至少一次成功與一次失敗情境。
  2. 第二步
    若確實需要寫入,明確界定寫入欄位範圍,並設計獨立稽核記錄。
  3. 第三步
    把整合測試紀錄(access matrix、test log)保留下來,作為 Module 4 Readiness Review「整合準備度」面向的證據。

重點: 唯讀優先不是為了偷懶,而是把「萬一 AI 工具出錯」的影響範圍先限制住。

失效與撤權演練

60 分鐘

演練帳號失效與撤權:多久才會真的斷掉?

準備度審查不能只看「權限設計得好不好」,還要實際演練「權限撤銷後,多久才會真的生效」。演練的重點是找出延遲與遺漏,而不是假設系統文件上寫的立即生效一定為真。

不合格的撤權說明

「離職後帳號會停用」,沒有說明多久內完成、由誰執行、如何確認。

合格的撤權說明

觸發條件
收到人資離職通知或流程負責人書面要求撤權。
執行時限
24 小時內由技術管理員停用帳號並移除 AI 工具存取權杖。
驗證方式
撤權後實際嘗試以該帳號存取,確認回應為拒絕存取,並記錄驗證時間。
例外處理
若撤權後 24 小時內仍可存取,視為安全事件,依 Module 3 的異常流程通報。

注意

常見缺口:AI 工具本身的存取權杖(API key/token)常常獨立於一般帳號系統之外,撤銷使用者帳號不代表對應的權杖也失效;演練時務必單獨檢查。
  1. 第一步
    選一個角色,實際模擬撤權流程並記錄每個步驟的實際耗時。
  2. 第二步
    單獨確認 AI 工具的存取權杖是否隨帳號一併失效。
  3. 第三步
    把演練結果(含任何延遲或遺漏)寫進 test log,未通過的項目列為權限準備度的缺口。
自我檢測

團隊撤銷了一名離職客服人員的系統帳號,但沒有檢查該帳號連接的 AI 工具 API key 是否也失效。這個做法的風險是什麼?

團隊撤銷了一名離職客服人員的系統帳號,但沒有檢查該帳號連接的 AI 工具 API key 是否也失效。這個做法的風險是什麼?

重點: 撤權演練的目的是找出「文件說立即生效,但實際上沒有」的落差,不是確認流程存在就好。

接下來做什麼?