短期クラウドMacのセキュリティ基準と鍵の整理

リリースの1週間前にクラウドMacを急きょ追加する場合、見落とされやすいのはビルド速度ではなく、アクセス境界です。開発者は普段ローカルで使っているSSH秘密鍵、リポジトリトークン、署名用データをそのままコピーし、作業終了後はプロジェクトディレクトリだけを削除しがちです。より安全に運用するには、レンタル期間ごとに独立したセキュリティサイクルとして扱います。利用開始時にベースラインを定め、稼働中は認証情報を制限し、返却前にはデータの移出と消去結果を検証します。

今回のレンタルにおける信頼境界を先に定義する

まず、ノードの用途、責任者、レンタル終了日時、取り扱うデータを記録します。公開コードのテストに使うマシンと、署名用データを扱うビルドノードで、同じ認証情報を使うべきではありません。複数人で作業する場合は、メンバーごとに個別のログイン手段を割り当てます。秘密鍵を共有したり、管理者の認証情報をチーム文書に記載したりしないでください。

短期レンタルノードのセキュリティ目標は、認証情報を永続的に使える状態にすることではありません。各認証情報の用途、最小権限、検証可能な失効日時を明確にすることです。

初回接続後15分以内に確認する項目

初回ログイン後、すぐにプロジェクトをインポートしないでください。最初に現在のユーザー、システムバージョン、リモートログイン、ファイアウォールの状態を確認し、その結果を保存します。システムアップデートを直ちに適用するかどうかは、現在のビルドツールチェーンが要求するバージョンに基づいて判断します。リリース作業の途中で環境が変わらないようにしてください。

whoami
sw_vers
sudo systemsetup -getremotelogin
sudo /usr/libexec/ApplicationFirewall/socketfilterfw --getglobalstate
softwareupdate --list

レンタル期間専用のSSH鍵を用意する

専用鍵は管理下にあるワークステーションで生成し、既存の長期利用用秘密鍵をコピーしないでください。公開鍵をクラウドMacに追加したら、別のターミナルを開いて新しい接続を確認してから、従来のアクセス方法を変更するか検討します。

umask 077
mkdir -p ~/.ssh
ssh-keygen -t ed25519 -f ~/.ssh/armmacs-rental -C "temporary-build-node"
chmod 700 ~/.ssh
chmod 600 ~/.ssh/armmacs-rental

ローカルの ~/.ssh/config ではノード専用のエイリアスを設定し、IdentitiesOnly yes を指定してSSHクライアントがほかの鍵を試さないようにできます。ノードのアドレス、ユーザー名、鍵のパスには今回の注文記録にある情報を使用し、実際のアドレスをコードリポジトリへコミットしないでください。

Host rented-mac
    HostName <node-address>
    User <node-user>
    IdentityFile ~/.ssh/armmacs-rental
    IdentitiesOnly yes
    ServerAliveInterval 30

シークレットは必要なときだけ利用する

トークンをスクリプト、プロジェクト設定、Shellの起動ファイルに書き込まないでください。対話形式の入力、利用範囲を制限した環境変数、またはmacOSのキーチェーンを優先し、ビルドログに変数の値が出力されないことも確認します。一時ファイルはアクセス権を管理したディレクトリに置き、デフォルトの権限を現在のユーザーだけが読み取れるように設定します。

umask 077
mkdir -p ~/secure-input
chmod 700 ~/secure-input
security add-generic-password -a build -s ci-token -w

使用後は、現在のShellから変数をすぐに削除します。認証情報を1回のリリースでしか使わない場合は、セッションをまたいで長期間保持しないでください。

unset CI_TOKEN
security delete-generic-password -a build -s ci-token

ログやキャッシュへのシークレット混入を防ぐ

ビルドスクリプトでは、コマンド全体を出力するデバッグモードを有効にしないでください。エラーログを共有する前に、リクエストヘッダー、環境変数、ノードアドレス、ユーザー名、ファイルパスを確認します。Derived Data、パッケージ管理キャッシュ、テストの添付ファイルには、プロジェクト名や内部パスが含まれる可能性があります。すべてを無条件にアーカイブするのではなく、作業の機密度に応じて保存の要否を判断してください。

稼働中は簡易監査を行う

少なくとも担当者の変更時、認証情報のローテーション時、重要なリリース前には、ログインセッション、待ち受けポート、バックグラウンドプロセス、ディスクの空き容量を確認します。不審なプロセスを見つけた場合は、実行中のビルドを誤って停止しないよう、終了させる前にプロセスID、起動ユーザー、コマンドパスを記録してください。

who
ps -axo user,pid,ppid,command
lsof -nP -iTCP -sTCP:LISTEN
df -h
find ~/work -type f -perm -004

最後のコマンドは、作業ディレクトリ内でほかのユーザーにも読み取りが許可されているファイルを検出するためのものです。完全な権限監査にはなりませんが、明らかな設定ミスをすばやく見つけられます。複数人で同じノードを利用する場合は、共有ディレクトリと個人用ディレクトリを分け、誰でも書き込めるディレクトリを使って署名用データを受け渡さないでください。

レンタル終了前に順序どおり移出と消去を行う

最初にRunner、ビルドエージェント、独自のバックグラウンドタスクを停止し、消去中にファイルが新たに生成されないようにします。次に、保存が必要なプロジェクト、ログ、成果物をアーカイブしてチェックサムを生成し、別の管理下にあるデバイスで展開して内容を抜き取り確認します。移出が成功したことを確認してから、ノード上の作業コピーを削除してください。

mkdir -p ~/export
ditto -c -k --keepParent ~/work/project ~/export/project.zip
shasum -a 256 ~/export/project.zip
git -C ~/work/project status --short

消去対象には、少なくともプロジェクトディレクトリ、エクスポートディレクトリ、ビルドキャッシュ、一時ディレクトリ、キーチェーン項目、SSHの認証設定、公開鍵の登録情報、専用アカウントのShell履歴を含めます。また、認証情報の発行元でリポジトリトークンを無効化し、自分のワークステーションから今回のレンタル専用秘密鍵を削除します。SSD上の個別ファイルを繰り返し上書きしても、プラットフォーム側のノード回収プロセスの代わりにはなりません。上書き回数を消去完了の証拠にしないでください。

退出前には逆方向からもう一度確認します。専用鍵で引き続きログインできないか、一時トークンが失効しているか、バックグラウンドプロセスがまだ動いていないか、エクスポートファイルがノードに残っていないか、作業ディレクトリに未コミットの変更がないかを点検してください。結果を引き継ぎ記録に残すことで、「削除したつもり」と「実際にはまだアクセスできる状態」の食い違いを防げます。

よくある質問