ホーム / ブログ / チーム共有Macの権限管理：企業の隔離基準
ENGINEERING_BLOG · 2026.08.14

チーム共有Macの権限管理：企業の隔離基準

管理者アカウントをチームで共有してはいけません。2026年の最低基準は、開発者を個別の標準アカウント、CIを専用サービスアカウント、管理作業を受け入れ制御された管理者アカウントと緊急復旧アカウントに分けることです。

この基準を満たせない場合は、共有Macの利用範囲を広げず、プロジェクト専用または短期独占のリモートMacへ切り替えてください。

この記事は、1台以上のリモートMacを開発チームへ提供する企業IT責任者、iOS CI/CDの証明書やパイプライン資格情報を管理する担当者、共有ホストと専用ホストの選定を行う技術責任者向けです。

SECTION 01共有管理者アカウントが壊す監査境界

「ログインできる」ことと「企業で安全に共有できる」ことは別です。共有管理者アカウントでは、操作した人物、実行目的、権限を取得した時刻を個人単位で結び付けられません。

特に問題になるのは、次の4つです。

  • パスワードを変更すると、正当な利用者も一斉に再設定が必要になる
  • 退職者1人だけのアクセスを確実に止められない
  • シェル操作、画面操作、ファイル変更の責任者を特定できない
  • インシデント調査で、本人の操作と自動処理を区別しにくい

NISTのアクセス制御では、担当業務に必要な範囲だけをユーザーやプロセスへ与える最小権限が求められています。共有管理者アカウントは、個人識別と権限の最小化を同時に難しくするため、企業の標準構成には適しません。詳しくはNIST SP 800-53の最小権限に関する管理策を確認してください。

アカウント・人物・用途の対応表

最初に、次のような対応表を作成します。ユーザー名の一覧だけではなく、誰が、何の目的で、どの資格情報を使うかまで記録することが重要です。

アカウント種別 利用者 主な用途 権限 保持する資格情報 監査・撤回の基準
開発者アカウント 個人 コード編集、手動検証 標準ユーザー 個人SSH鍵、個人用Keychain 人事・IdP連携、個人単位で無効化
CIサービスアカウント パイプライン 自動ビルド、テスト、成果物作成 必要な範囲だけ CI専用トークン、専用Keychain ジョブ単位の記録、トークン単位でローテーション
管理者アカウント 運用担当者 設定変更、保守、承認 受け入れ制御された管理者権限 管理作業用資格情報 承認記録、作業終了後の確認
緊急復旧アカウント 限定された担当者 障害復旧、復旧鍵の管理 必要最小限の復旧権限 保管庫で管理する復旧資格情報 使用理由、承認者、実施結果を記録

SECTION 02権限の膨張を止める役割分離

開発者の作業、CIの自動処理、Macの保守、ディスク復旧を同じ管理者身份に集約してはいけません。役割を分けることで、通常作業の権限を下げながら、必要な保守作業だけを承認できます。

日常アカウント

開発者は標準ユーザーを基本にします。コード編集、ローカルテスト、Git操作、画面共有での作業は、通常この権限で実行できるように設計します。

管理者権限が必要なSDK、ツール、システム設定の変更は、申請と承認を経て実施します。申請記録には、少なくとも次の項目を含めてください。

  • 申請者と承認者
  • 対象Macと対象プロジェクト
  • 実施する変更内容
  • 必要な権限と作業時間
  • 作業後に確認する設定
  • 問題が起きた場合の復旧担当者

Platform SSOを利用する場合でも、IdPグループの設計をそのままローカル管理者権限へ結び付けないよう注意が必要です。Appleの資料では、Platform SSOによって標準ユーザー、管理者、追加グループなどの権限を構成できますが、Secure Tokenや所有権を要求する認証は別の条件になると説明されています。Platform SSOの公式仕様を、利用するmacOSとデバイス管理環境に合わせて確認してください。

CIサービスアカウント

CIは、開発者が画面から利用するアカウントとは分けます。CIサービスアカウントへ管理者権限を与えると、ビルドスクリプトや依存ツールの脆弱性が、そのままMac全体の変更権限につながるためです。

CIアカウントの設計では、対話型ログインを原則として許可せず、対象ワークスペース、成果物保存先、コード取得先、署名処理だけに権限を限定します。ログインシェルやSSHを使う場合も、開発者用の鍵とは別に管理し、所有者と用途を台帳へ記録します。

管理者と緊急復旧

管理者アカウントは、日常開発や自動ビルドに使いません。緊急復旧アカウントも、便利な共用アカウントとして配布せず、保管場所、利用承認、使用後の資格情報変更を決めておきます。

注意：管理者、Secure Token、APFSのボリューム所有者、FileVaultを解除できるユーザーは、同じ意味ではありません。管理者グループへ追加しただけで、すべての復旧操作が可能になるとは限りません。

SECTION 03SSH・画面共有・コンソールの入口分離

リモートアクセスは、入口ごとに目的と本人性を分けます。SSHはコマンドライン保守と自動化、画面共有はGUI操作、管理コンソールはホストの割り当てや運用設定というように、利用目的を定義してください。

macOSの画面共有やリモート管理では、すべてのローカルユーザーを許可するのではなく、アクセス可能なユーザーを限定できます。Appleの画面共有に関する公式手順でも、許可対象を「すべてのユーザー」または「指定したユーザー」から選ぶ構成が示されています。

SSHについても、共有パスワードではなく個人に紐づく鍵を使います。macOSのRemote LoginはSSHまたはSFTPによる接続に利用できますが、AppleのRemote Login設定を確認し、許可ユーザー、鍵の所有者、接続元、対話型ログインの可否を決めてください。

運用開始前には、次の証拠をそろえます。

  1. ローカルアカウントとIdPアカウントの一覧
  2. SSH、画面共有、管理コンソールごとの許可一覧
  3. 各SSH鍵の所有者、用途、登録日
  4. ログインと権限変更の記録
  5. 退職者を無効化した後の接続拒否テスト
  6. CIサービスアカウントが対話操作できないことの確認

「アカウントを削除したから終わり」ではありません。SSH鍵、許可リスト、CIのトークン、証明書、外部サービス側のセッションも順番に確認します。

SECTION 04CIワークスペースと署名資格情報

iOSのビルドでは、ソースコードだけでなく、署名証明書、秘密鍵、Provisioning Profile、App Store Connect関連の資格情報が扱われます。これらを開発者のログイン環境へ置いたままCIから参照すると、意図せず複数ユーザーへ利用範囲が広がります。

macOSのKeychainは、ユーザー名、パスワード、デジタルID、暗号鍵などを保管する仕組みです。AppleのKeychainデータ保護に関する公式資料では、ユーザーごとのKeychainに加え、システムレベルのKeychainも存在し、アクセス制御や署名など複数の仕組みで保護されることが説明されています。

実務では、次の境界を明確にします。

  • 開発者のログインKeychainとCI用Keychainを分ける
  • プロジェクトや信頼レベルごとにワークスペースを分ける
  • 署名秘密鍵を全開発者のアカウントへ配布しない
  • CIジョブが参照する資格情報を台帳化する
  • 証明書やトークンの更新担当者を決める
  • 退職、委託終了、プロジェクト移管時の失効手順を持つ

AppleのmacOSコード署名プロセスでも、署名には証明書と秘密鍵が関係します。したがって、単に証明書ファイルをコピーするのではなく、秘密鍵を誰が保管し、どのジョブが呼び出し、どの条件でローテーションするかまで設計する必要があります。

SECTION 05FileVault・Secure Token・復旧権限

FileVaultの暗号化状態を確認するだけでは、復旧権限の管理として不十分です。誰がディスクを解除できるか、誰がシステム更新を承認できるか、誰が復旧キーを扱えるかを別々に記録します。

AppleのFileVaultをデバイス管理で扱う公式資料では、ストレージを解除するユーザーにはSecure Tokenが必要で、Appleシリコン搭載Macではボリューム所有者の条件も関係すると説明されています。また、ユーザーのFileVault解除能力を削除する操作についても記載されています。

Secure Tokenやボリューム所有権を、開発者全員へ自動的に与える設計は避けてください。リモートで再起動する必要があるからといって、全員を管理者にするのは権限の代替になりません。

最低限、次を別管理します。

  • FileVault復旧キーの保管責任者
  • ディスクを解除できるユーザー
  • システム更新の承認者
  • 復旧操作を実施できる担当者
  • 無人再起動後に再接続する手段
  • 復旧後に確認するアカウントと資格情報

Appleシリコン、macOSのバージョン、デバイス管理サービスの構成によって実際の挙動が異なるため、導入時はSecure Token、Bootstrap Token、ボリューム所有権の公式資料を基準に検証してください。

SECTION 06現場で行う権限分離の手順

既存の共有Macをすぐに作り直せない場合は、次の順番で是正します。

  1. 共有アカウントの棚卸し
    管理者、開発者、CI、復旧用の各アカウントを一覧化し、共用パスワード、SSH鍵、証明書、秘密鍵の保管場所を確認します。

  2. 個人アカウントの作成
    開発者ごとに個別アカウントを作り、日常利用は標準ユーザーにします。IdP連携を使う場合も、ローカル権限の付与条件を確認します。

  3. CIの分離
    CI専用アカウント、専用ワークスペース、専用Keychainを作成します。開発者のホームディレクトリや秘密鍵をCIから参照できない状態にします。

  4. SSHと画面共有の制限
    許可ユーザーを明示し、個人SSH鍵を登録します。画面共有では、作業者を指定したリストへ追加し、不要になったユーザーを削除します。

  5. 管理者操作の承認化
    管理者権限が必要な作業を列挙し、申請者、承認者、作業時間、対象ホスト、作業後の確認項目を記録します。

  6. 署名資格情報の再配置
    開発者用とCI用の証明書、秘密鍵、トークンを分類し、不要な複製を削除します。共有されていた秘密鍵は、影響範囲を確認したうえでローテーションを検討します。

  7. 撤回テストを実施
    1人のテストユーザーを無効化し、SSH、画面共有、CI、Keychain、署名処理、外部サービスの各入口から接続できないことを確認します。

  8. 復旧テストを記録
    FileVault解除、再起動、CI再開、緊急管理者の利用について、担当者と承認記録が残るかを確認します。

この手順で、アカウント、人物、用途、資格情報、撤回操作が1本の記録につながります。逆に、どこか1つでも共有パスワードへ戻ると、監査可能な境界が崩れます。

SECTION 07共有構成を広げない判断

現在の構成が、個人単位のログイン、単独ユーザーの撤回、CIと開発者のKeychain分離、プロジェクトごとの資格情報分離を満たさないなら、共有Macを増やす前に方式を見直してください。

特に、顧客データと署名秘密鍵が同じユーザー環境に置かれている場合、複数プロジェクトを同じホストへ集約する設計は避けたほうが安全です。アクセス記録で操作者を特定できない場合や、退職者の無効化後も鍵やトークンが残る場合も同様です。

MACNOXの日本語サービス案内を確認するときも、価格だけでなく、チーム単位・プロジェクト単位でどのように利用者と資格情報を分けられるかを先に確認してください。継続利用の費用を比較する場合は、料金ページの条件と、自社で必要になる運用・監査作業を合わせて評価します。

現状の共有Macは、初期費用を抑えやすい一方で、管理者権限の拡大、証明書の共有、退職者の撤回漏れ、監査記録の不足という弱点を抱えやすい構成です。独立ID、単独撤回、プロジェクト単位の資格情報隔離を実装できないなら、MACNOXでチームまたはプロジェクト専用のリモートMacを検討するほうが、共有管理者アカウントをさらに増やすより、運用上の責任範囲を明確にできます。

まずは現在のMacを、この記事の「アカウント・人物・用途」表で棚卸ししてください。その結果、誰が使ったかを特定できない、1人だけの撤回ができない、CIと開発環境を分離できないという項目が残るなら、利用環境の申込み案内を確認し、共有構成を拡大する前に専用リモートMacへの切り替え条件を比較してください。