App Store Connect API Key：2026 團隊密鑰還是個人密鑰？

Apple 官方說明指出，App Store Connect API 的私鑰檔案只能下載一次，之後若遺失就必須撤銷並重新建立；詳見 Apple 的 API Key 建立說明。

症狀： CI 仍依賴員工 Apple Account、個人 API Key，或把 p8 長期放在共享建置機。
最快解法： 生產發布改用按任務拆分、授予最低必要角色的 Team API Key；Individual API Key 只用於與特定使用者權限綁定、且不涉及 Provisioning 或 notarytool 的有限自動化。

誰應該採用這套 App Store Connect API Key 企業 CI 判斷方式

本文適合正在移除 Apple ID、雙重認證或員工個人憑證依賴的研發效能負責人。若您需要替多個應用程式建立最小權限、撤銷及審計制度，也可以用本文的指標逐項驗收。

計畫把 fastlane、TestFlight 或公證工作移到共享或遠端 Mac 工作環境的技術負責人，同樣需要先確認密鑰能否與發布節點、簽名資產及建置權限分離。

先按自動化任務判斷密鑰，而不是先選名稱

企業 CI 的第一個錯誤，是把「團隊密鑰」理解成所有自動化工作的通用入口。實際上，應先列出流水線呼叫的 API、使用的 Apple 工具，以及是否涉及簽名或公證，再決定密鑰類型。

自動化任務	初步密鑰方向	主要限制與審批判斷
App Store Connect 元資料維護	Team API Key 或受限 Individual API Key	先核對工具是否支援該密鑰類型，以及所需角色
TestFlight 上傳與分發	以 Team API Key 為主	應按產品線或任務拆分，避免所有應用程式共用同一個生產密鑰
Provisioning 相關工作	Team API Key	Individual API Key 不適合作為此類自動化的長期憑證
證書與簽名資產管理	與 API Key 分開治理	Apple 簽名私鑰、Provisioning Profile、Keychain 不是同一種憑證
macOS 軟體公證	Team API Key 或 Apple 官方支援的專用流程	個人密鑰不能取代 `notarytool` 所需的支援能力

fastlane 的 App Store Connect API 說明與其 API Key Action 文件都應在上線前逐項核對。不要只看 fastlane 是否能讀取 key_id、issuer_id 與私鑰；還要確認實際 Action 對 Team API Key、Individual API Key 及所需端點的支援狀態。

其中，App Store Connect API Key、Apple Account、簽名證書私鑰、Provisioning Profile 與 macOS Keychain 必須分開登錄。把它們統稱為「Apple 憑證」，會令撤銷範圍、責任人和故障回退都變得不清楚。

權限範圍：Team API Key 不等於單一應用程式隔離

Team API Key 按 App Store Connect 角色授權，但覆蓋該團隊的應用程式；Individual API Key 則繼承關聯使用者的應用程式存取範圍與權限。這是兩者在企業治理上的核心差異，而不是單純的便利性比較。

Apple 的角色權限說明應作為角色審批依據；應用程式存取範圍則應對照 Apple 的 App 存取控制文件。降低 Team API Key 的角色，只能降低可執行的操作，不代表它因此被限制到某一個應用程式。

因此，以下結論不能成立：

把 Team API Key 命名為 app-a-release，不會產生伺服器端的 App A 隔離。
把不同密鑰放進不同 CI 變數群組，不等於洩漏後的權限影響範圍已縮小。
把同一個團隊密鑰交給多條流水線，會令所有使用它的應用程式共同承受洩漏風險。

如果團隊只有一個應用程式，且發布任務和其他 App Store Connect 操作已經分離，Team API Key 可以是合理的生產選擇。若同一 Apple 團隊包含多個產品線，則應按任務拆分密鑰與流水線；當真正需要強應用程式隔離、又無法透過現有 API 權限達成時，才評估拆分 Apple 團隊邊界。

Team API Key 與 Individual API Key 的實際差異

評估指標	Team API Key	Individual API Key
權限來源	由團隊為密鑰指定角色	繼承關聯使用者的 App 存取與權限
應用程式範圍	團隊層級，不能僅靠命名變成單一 App	可隨使用者的 App 存取範圍收斂
人員依賴	不綁定單一員工，較適合生產基礎設施	綁定使用者，適合責任明確的有限自動化
Provisioning	可作為相關自動化的候選，但仍須核對角色與端點	不適合作為此類長期自動化憑證
`notarytool`	需依 Apple 官方流程核對	不可把 Individual API Key 當作替代方案
洩漏後影響	取決於團隊角色，可能跨多個應用程式	取決於該使用者的 App 存取與角色
離職或停權影響	不依附單一員工，但仍須建立專人治理	使用者狀態變更可能直接影響流水線

企業 CI 應該使用 Team API Key 還是 Individual API Key

決策不應是「永遠選 Team」或「永遠選 Individual」，而應依照下列條件分支：

若工作是正式發布、TestFlight 分發、Provisioning 或共用 CI 基礎設施，則選按任務拆分的 Team API Key，並把角色降到任務所需的最低程度。
若工作只代表某位使用者執行有限的 App Store Connect 自動化，且不涉及 Provisioning 或 notarytool，則可選Individual API Key。
若工具只支援 Apple Account 登入、或尚未確認支援的 API 端點，則回退到人工審批或隔離的過渡流程，不要直接把員工個人憑證放進生產 CI。
若同一 Team API Key 被多個產品線、簽名任務和管理任務共用，則先拆分任務和流水線，再判斷是否需要更高層級的 Apple 團隊隔離。
若安全團隊無法取得密鑰存取、撤銷演練及任務後清理證據，則不要把該密鑰視為可上線的生產憑證。

這個分支也回答了 Team API Key 與 Individual API Key 的實務選擇：生產基礎設施需要人員獨立性，有限的使用者自動化才接受個人權限繼承。

應用程式隔離與人員依賴是兩個不同指標

多應用程式環境常把「誰可以操作」和「可以操作哪些 App」混為一談。Individual API Key 可能隨使用者的 App 存取範圍收斂，但它仍然與該使用者的角色、帳號狀態及職務變化相連；Team API Key 則較適合服務帳戶式的生產工作，卻不能自然提供單一 App 隔離。

App Store Connect 團隊密鑰能否限制到單個應用程式

一般不能只靠建立 Team API Key 或降低角色，推導出單一應用程式限制。Apple 的 App 存取控制可以管理使用者對 App 的存取，但團隊密鑰的授權模型與個人使用者的 App 存取模型不是同一件事。

企業需要用架構補足這個邊界：

為每個產品線建立獨立的發布流水線。
按元資料、TestFlight、發布及管理任務分拆密鑰。
將密鑰只注入可信的發布工作，不讓非可信分支取得。
將可執行工作、審批人和回退方式寫入 CI 設定庫。
只有在團隊內仍無法達成必要隔離時，才評估拆分 Apple 團隊。

員工調職、離職或 Apple Account 停用時，Individual API Key 的責任鏈會變得特別脆弱。它是否立即失效，不能只依賴口頭認知，必須按 Apple 當前撤銷及帳號狀態規則實際驗證。生產流水線不應把「某位員工仍在職」當成可用性的前置條件。

私鑰保存：p8、簽名私鑰與 Keychain 必須分層

fastlane 發布流水線如何安全保存 p8 私鑰，答案不是把檔案放進加密過的 Git 儲存庫，而是縮短存在時間、限定讀取工作、避免落入長期工作區。

建議將風險邊界分成四層：

CI Secret 儲存區：保存受控的 Secret，不把原始 p8 提交到程式碼儲存庫。
任務啟動時注入：只在可信工作開始時產生臨時檔案，檔案權限限於執行工作。
任務結束清理：刪除臨時 p8、環境變數、日誌中的 JWT 或其他可還原內容。
節點隔離：一般建置節點不接觸發布密鑰；可信發布 Mac 才能讀取相關 Secret。

這裡仍要把 Apple API Key 與 Apple 簽名私鑰分開。Provisioning Profile 可能包含團隊與 App 的簽名關聯，但不等於 API Key；macOS Keychain 又是另一個保存及存取控制層。Apple 也對 Provisioning Profile 更新有獨立說明，不能用同一份資產清單代替三者的撤銷管理。

在遠端 Mac 或共享 Mac 上，建議採用「通用建置池＋專用可信發布節點」的架構。來自非可信分支的工作只能進入通用節點；正式分支經審批後，才由可信節點取得短暫 Secret。若租用或配置遠端 Mac，應把節點存取帳號、CI Secret、工作區和退出流程納入同一份驗收紀錄，而不是只驗證 VNC 或 SSH 能否連線。

撤銷、輪換與審計決定最終可維護性

App Store Connect API Key 洩漏後如何輪換，不能等同於「刪除 p8 檔案」。正確處理至少包括：停止仍在執行的工作、建立替代密鑰、更新受控 Secret、驗證流水線、撤銷舊密鑰，以及檢查舊 JWT 或檔案是否殘留在日誌和工作區。

Apple 提供撤銷 API Key 的官方文件，企業應把它轉化為可演練的作業，而非只記在安全政策中。資產帳本至少應包含：

密鑰識別名稱與用途；
所屬 Apple 團隊及角色；
是否為 Team API Key 或 Individual API Key；
建立審批人與業務負責人；
使用中的 CI 專案、發布節點及 Secret 名稱；
最近一次權限複核日期；
離職、調職、洩漏、專案終止時的撤銷條件；
撤銷後的失敗回退與證據位置。

我們建議以以下評分方向做最後審查，而不是只比較「能不能成功上傳」：

功能覆蓋：目標 Action 和 API 端點是否真的支援。
最低權限：角色是否仍包含不必要的管理能力。
人員獨立性：員工停權後，正式發布是否仍可運作。
應用程式隔離：洩漏後是否會影響不相關產品線。
輪換難度：能否在不修改程式碼的情況下替換 Secret。
故障範圍：單一密鑰失效會令多少流水線停止。

若任一密鑰無法完成撤銷演練、失敗回退、Secret 讀取審計或任務後工作區清理，就不應直接進入生產。

將密鑰治理落到 Mac 節點，才算完成 CI 設計

密鑰選型只是控制平面的一部分。真正的發布環境還要處理節點登入、工作區殘留、磁碟存取、建置快取和換機恢復。對企業而言，將 p8 放到一台長期在線、多人共用的 Mac 上，並不會因為該 Mac 是 Apple Silicon 就自動變得安全。

如果現有流程依賴員工個人 API Key，或把 p8 長期存放在共享建置機，較穩妥的改造順序是：

盤點所有 App Store Connect API、fastlane Action、Provisioning 與公證工作。
為每項任務指定 Team、Individual 或人工審批結論。
拆分普通建置節點與可信發布 Mac。
把 p8 改為 CI Secret，在任務期間短暫注入。
建立日誌遮罩、工作區清理與節點重置驗收。
以撤銷舊密鑰的方式演練輪換，確認失敗時能回退。
每季重新核對 Apple 與 fastlane 官方文件，因為端點、角色及工具支援狀態可能變更。

若團隊需要的是長期固定的高負載建置、實體介面或完全掌控硬體，企業自購 Mac 仍可能較合適；但自購方案會帶來資產折舊、硬碟清理、換機、遠端維運及閒置容量成本。相較之下，對臨時發布節點、跨地域團隊或需要按專案擴充的 CI，將專用 Mac 節點交由 VNCMac 的 Mac 方案評估，前提是先取得憑證注入、存取權限、任務後清理及換機恢復的可審計證據。

我們的結論很明確：生產發布使用按任務拆分、最低角色授權的 Team API Key；有限且責任明確的使用者自動化才使用 Individual API Key；簽名資產、Provisioning Profile、Keychain 與 API Key 分開管理。若現有方案仍依賴個人帳號、共享 Mac 長期保存 p8，或沒有撤銷後的恢復證據，短期看似省事，長期卻會把離職、洩漏和換機風險集中到同一個故障點。對需要臨時算力或隔離發布環境的團隊，先以這套矩陣驗證遠端 Mac 是否符合治理要求，再決定是否租用，會比直接把舊流程搬到雲端更安全。