誰能發送 vs API 金鑰輪替衛生

人員權限與 API 金鑰輪替衛生在上線工單中看似相鄰，但它們回答的是完全不同的問題。誰能夠發送簡訊屬於角色對映(Roles map)：確定哪個席位可以提交正式環境 SMS、核准行銷活動或匯出資料。

IOSOR 嚴格維持這兩者的界線。授予主控台(Console)角色不會輪替 Webhook 簽章密鑰；輪替密鑰也不會授予任何發送權限。

區分席位授權與密鑰生命週期

席位授權回答的是誰可以點擊『發送』、『核准』或『匯出』。這些權限屬於 roles-access 審查範疇，需要指定明確的負責人與最小權限矩陣(Least-privilege matrix)。

角色工單應清楚列出席位與對應的操作動詞(Verbs)。開發人員(Developers)工單則列出密鑰擁有者、輪替時間視窗與切換證明。這兩者不可合併為單一表單。

誰能發送屬於角色權限問題

發送正式環境 SMS 會扣除預付凍結金額(Prepaid holds)，並在即時路徑上留下完整的稽核軌跡(Audit trail)。具備發送權限的席位必須極為明確：例如行銷活動營運人員、值班訊息工程師或具有完整檔案紀錄的自動化身分。唯讀財務人員、KYC 審查員與匯出專員絕不能從共享的管理員角色中繼承發送權限。

當離職發生時，必須在輪替該員工筆記型電腦之前，先撤銷其發送權限。金鑰輪替無法替代席位撤銷 — 如果席位權限依舊有效，離職的工程師仍可重新生成新的 API 金鑰。白標介面上的合作夥伴管理員也需要相同的清晰度：門戶角色應保持為人員權限對映，而非複製貼上正式金鑰的捷徑。

輪替與切換屬於開發人員路徑

無中斷時間的 Webhook 密鑰輪替、沙箱與正式金鑰切換，以及金鑰上線衛生皆屬於開發人員職責。這些作業需要雙軌運行視窗(Dual-run windows)、針對新密鑰進行冒煙測試(Smoke test)，以及不依賴權限持有者的切換查核表。如果角色變更工單包含『順便輪替 API 金鑰』，請將輪替需求轉發至開發人員路徑。roles-access 在席位與動詞對齊時結案；Developers 則在新密鑰生效且舊密鑰廢止時結案。請保持合作夥伴介面獨立於輪替路徑之外。

拒絕在角色工單貼上金鑰的混合授權

如果試算表中標註『Admin — 擁有正式環境金鑰』，會讓組織習慣將席位視為金鑰保險箱。請明確發布兩個獨立產物：角色矩陣(人員 → 動詞)與開發人員金鑰登記冊(密鑰 → 擁有者 → 上次輪替時間)。當合作夥伴要求在同一封電子郵件中提供具發送權限的登入帳號與正式金鑰時，請回覆兩個連結：席位權限前往 roles-access，切換流程前往 Developers。

相關維運路徑

• 如何在不中斷服務的情況下輪替 Webhook 簽章金鑰
• 沙箱金鑰切到正式環境
• 夥伴介面閘門：無品牌洩漏

從 IOSOR 開始

請於今天審查主控台的席位權限，將使用者發送權限與 API 憑證管理區隔開來。透過團隊存取矩陣嚴格指派人工角色，同時將金鑰輪替排程納入開發人員的工作流程中。請務必確認席位配置單或維運紀錄中，未曾存放任何未經處理的憑證或 webhook 金鑰。

IOSOR 要點

人工席位授權決定了誰能觸發訊息或檢視報表，而 API 金鑰的衛生管理則主導了服務憑證的生命週期。將使用者席位配置與機密管理混為一談，將會衍生嚴重的安全風險並降低維運責任歸屬。

務必在使用者存取矩陣與開發人員金鑰登錄檔之間維持嚴格的區隔，並指定明確的負責人與切換時間窗口。絕對不要允許混合型授權，或是將正式環境機密與人工角色核准混貼在試算表中。