企業のApp Store Connect自動化では、担当者個人の鍵を長期的な本番資格情報にしてはいけません。この記事では、権限範囲、アプリ隔離、担当者依存、秘密鍵保管、撤回と監査という指標でTeam API KeyとIndividual API Keyを比較し、CIの分離条件を示します。
企業のApp Store Connect自動化では、担当者個人の鍵を長期的な本番資格情報にしてはいけません。この記事では、権限範囲、アプリ隔離、担当者依存、秘密鍵保管、撤回と監査という指標でTeam API KeyとIndividual API Keyを比較し、CIの分離条件を示します。
Appleの公式説明では、App Store Connect APIのTeam API Keyはチーム内の全アプリを対象にし、Individual API Keyは関連付けられたユーザーの権限を引き継ぎます。API Keyの作成仕様から導ける最短の結論は明確です。本番CIは、タスクごとに分けた最低権限のTeam API Keyを基本にし、Individual API Keyは範囲を限定した個人向け自動化にとどめます。
これは、Apple IDや二要素認証への依存をなくしたい開発生産性責任者向けの記事です。複数アプリの公開経路、CI資格情報の監査、共有またはリモートMacの運用を設計するIT・セキュリティ責任者にも適しています。
鍵の種類を先に決めると、権限過多の設計になりやすいです。まず、CIが実際に呼び出すAPI、署名処理、Appleの公証処理を分けて記録します。
企業CIではTeam API KeyとIndividual API Keyのどちらを選ぶべきですか。
本番公開、複数アプリ、担当者不在でも継続すべき処理ならTeam API Keyです。特定ユーザーの権限に厳密に結び付く限定的な自動化で、Provisioningやnotarytoolを使わない場合だけ、Individual API Keyを候補にします。fastlaneのAPI認証仕様も、導入前に利用するAction単位で確認します。
Team API Keyは役割に応じて権限を付与できますが、役割を低く設定しても、単一アプリだけに自動的に閉じるとは限りません。Appleのロール一覧と、アプリへのアクセス設定を確認し、役割名だけで安全性を推測しないことが重要です。
Individual API Keyはユーザーに関連付けられたアプリへのアクセス範囲と権限を引き継ぎます。一方で、利用できないエンドポイントがあるため、「個人鍵のほうが常に最小権限」という整理も不正確です。
実装前には、次のような権限台帳を作ります。
fastlaneを利用する場合も、App Store Connect API Key Actionの公式仕様にある認証項目だけを採用し、CI変数へ不要なApple Account情報を持ち込まない構成にします。
Team API Keyはチーム内の全アプリを対象にするため、同じ鍵を製品A、製品B、顧客向けアプリの公開処理で共用すると、漏えい時の影響範囲が広がります。鍵名を分けたり、CI変数を別グループにしたりしても、Apple側の権限境界が分離されるわけではありません。
複数アプリを運用する場合は、次の条件で分割します。
App Store Connectのチーム鍵を単一アプリだけに制限できますか。
Team API Keyの役割を下げても、単一アプリへの完全なサービス側隔離を意味しません。単一アプリ単位の厳格な境界が必要なら、CIジョブ、実行ノード、Secret、承認経路を分け、必要に応じてAppleチームの境界も見直します。
本番インフラの鍵を社員個人のアカウントに依存させると、異動、休職、退職、権限変更のたびに公開処理が止まる可能性があります。Individual API Keyはユーザーのアクセス権と結び付くため、責任者が明確な小規模自動化には使えても、共有基盤の恒久的な資格情報には向きません。
社員が退職するとIndividual API Keyはすぐ無効になりますか。
ユーザーのアカウント状態や権限変更が鍵の利用可否に影響するため、「退職日まで必ず動く」「退職後も必ず動く」と決め打ちしてはいけません。退職処理と同時に鍵の棚卸し、CI Secretの無効化、代替鍵への切り替えを実施し、Appleのアクセス権管理で実効権限を確認します。
台帳には少なくとも、次の項目を持たせます。
p8秘密鍵は作成時に一度しかダウンロードできないため、作成直後から保管経路を管理します。Appleの作成手順を基準に、ソースコード、リポジトリ、共有管理者ディレクトリ、長期保存されるビルド作業領域へ置かない設計にします。
fastlaneの公開パイプラインでp8秘密鍵を安全に保存するにはどうしますか。
長期ファイルとして共有Macに残すのではなく、CI Secretからジョブ開始時だけ一時ファイルへ注入し、権限を限定して処理後に削除します。ログへの内容出力、アーティファクトへの混入、プルリクエスト由来のジョブからの参照を禁止し、API Key、署名用秘密鍵、Keychainを別Secretとして扱います。
注意：一時ファイルを削除しても、シェル履歴、デバッグログ、キャッシュ、クラッシュダンプに内容が残れば回収経路になります。ジョブ終了後はファイルだけでなく、作業領域、ログ、生成物、キャッシュの扱いまで確認します。
一般ビルドノードと信頼済み公開Macを分離し、外部入力を含むブランチから公開用Secretへ到達できない構成にします。Macを自社購入するか、Macレンタルの構成を使うかにかかわらず、重要なのは物理所有ではなく、アクセス経路、権限、清掃、交換時の復旧証拠です。
漏えい時の対応は、鍵を作り直すだけでは不十分です。新しい鍵を安全に登録し、公開ジョブを切り替え、旧鍵を撤回し、失敗した場合の手動公開へ戻す手順まで検証します。AppleのAPI Key撤回手順を基準に、撤回権限を持つ担当者を限定します。
実務上の確認手順は次の順序が扱いやすいです。
最終判断は、便利さではなく、機能、権限、隔離、担当者依存、輪番、故障時の影響で採点します。
| 評価指標 | Team API Key | Individual API Key | 企業CIの判断 |
|---|---|---|---|
| 本番基盤への依存 | ユーザーから分離しやすい | 特定ユーザーに依存 | 本番はTeamを優先 |
| アプリ範囲 | チーム全体のアプリが対象 | ユーザーのアクセス範囲を継承 | Teamでもジョブを分割 |
| Provisioning・notarytool | APIとツールの対応確認が必要 | 一部能力を利用できない | 別認証経路を設計 |
| 異動・退職時の影響 | 台帳と撤回手順で管理 | ユーザー状態に影響される | 個人鍵を恒久資格情報にしない |
| 漏えい時の影響 | 共用すると大きい | アプリ範囲は狭くなり得る | 用途別に鍵とノードを分離 |
| 監査のしやすさ | 業務単位で管理しやすい | 個人責任は明確 | 所有者と承認者を分離 |
社員の個人API Keyや共有Mac上の長期p8ファイルに依存している環境では、退職時の停止、漏えい範囲の拡大、監査証跡の欠落が起こりやすくなります。自社購入のMacも物理交換、保守、稼働監視、余剰容量の固定化を自社で負担する必要があります。
一方、短期の公開基盤やチーム拡張時には、専用のリモートMac環境を使い、信頼済みノード、限定アクセス、ジョブ後の清掃、交換時の復旧手順を契約前に確認するほうが、運用条件を揃えやすい場合があります。既存の鍵設計をこの比較表で分解し、必要な期間だけVNCMacのMac環境を検証するのが、購入前に取れる現実的な進め方です。