三つの痛み：ログインは通るのに監査が破綻する理由
第一、ライフサイクルのずれです。外注終了後も鍵が authorized_keys に残り、CI は長寿命鍵のまま改名します。ログは共有 Unix アカウントの成功だけで、リモート Mac でデザイン転送まで混ざると説明がさらに難しくなります。
第二、コメントは身元データベースになりません。from= 等は強力ですが数百行はレビュー不能に近く、IdP やチケットへ結べないと運用は先送りされます。
第三、ディレクトリだけでは説明が足りません。chroot でも Unix 名は一つに束ねられがちです。Principal と専用アカウントでパイプライン単位の説明責任を戻します。
人事オフボードと鍵行の対応が切れると退出後も残りますが、短期証明書は期限で締めます。調達はローテ証跡を求め、シリアル付き JSONL が表計算より速いです。
信頼のアンカー：ユーザー CA を入れると何が変わるか
静的鍵は「行ごとの公開鍵」に信頼を置きます。証明書は TrustedUserCAKeys で少数 CA を信じ、短命の署名付き資格を提示します。ローテは行削除より期限の性質へ寄ります。証明書は誰が入ったか、原子リリースはどこへ書けるかです。新規は ed25519、CA 秘密鍵はオフラインか HSM、侵害時は CA の付け替えが必要です。
フィッシングは止めませんがサーバー側の古さは縮みます。管理端末方針と併用し、Mac では iCloud と SSH 素材の取り扱いに注意します。遠隔から同一リモート Macへ大容量転送するなら、キープアライブとセットです。更新は手作業ではなくパイプライン工程に載せます。
意思決定表：静的鍵、アカウント分割、証明書、追加バスション
共有リモート Mac の SFTP が詰まるときの比較です。
| 戦略 | 最適なとき | 運用コスト | 監査の質 |
|---|---|---|---|
| 長大な authorized_keys のみ | 単一チーム、稀な変更、コンプラ無し | 短期的には低い | 低い |
| パイプラインごとの Unix アカウント＋静的鍵 | 中規模でアカウント所有者が明確 | 中程度 | 所有者マッピングができれば良い |
| SSH ユーザー証明書＋ Principal | 多チーム、頻繁なローテ、SOC の質問 | 中〜高 | シリアルログが揃えば強い |
| 別バスションまたは VPN＋ SFTP | 厳格なネットワーク分離 | 高い | 層状ログなら強い |
初日より月次の再署名・監査対応の分を見積もり、静的鍵の「見た目の簡さ」に騙されないでください。
実践パス：CA 作成、署名、sshd 配線
ステージングで検証し、Match User は SFTP のみと chroot に合わせます。reload 前に sshd -t、管理セッションは二重化。期限切れ拒否と時計ずれもテストします。
# Step 1: generate a CA keypair in an offline or jump-admin context
ssh-keygen -t ed25519 -f ./user_ca -C "[email protected]"
# Step 2: install the public key on the server
sudo install -m 644 ./user_ca.pub /etc/ssh/user_ca.pub
# In sshd_config add:
# TrustedUserCAKeys /etc/ssh/user_ca.pub
# Optional: AuthorizedPrincipalsFile /etc/ssh/auth_principals/%u
# Step 3: sign a user key for ninety days with a Principal
ssh-keygen -s ./user_ca -I build-ios-202603 -n ci-ios -V +90d -z 10001 id_ed25519.pub
# Step 4: client presents id_ed25519 and id_ed25519-cert.pub
# ssh -i id_ed25519 -o CertificateFile=id_ed25519-cert.pub deploy@remote-mac
# Step 5: combine with Match User sftpdeploy, ForceCommand internal-sftp,
# ChrootDirectory as in the multitenant guide, and separate CI accounts.
# Step 6: append issuance JSON lines with serial, principal, window, pipeline id.
CA が無い間も鍵・Unix・接頭辞を一対一にし、同時セッションを調整します。ssh-keygen 方針と Principal マッピングを文書化し、闇スクリプトを防ぎます。
数値基準：有効期間、シリアル番号、保持
人向けは三十〜九十日、自動化は二十四〜七十二時間を目安にします。発行は -z シリアル、-n Principal、区間、チケット名を JSONL に残し、九十日は最低保持します。緊急停止はアカウント無効か Principal 削除です。chroot と releases はディスク・inode を監視し、認証改善が容量問題を隠しません。
導入直後は休暇前の失念や Runbook 不足で揉みます。rsync 手順の横に再署名を置き、規制向けにはシリアルと変更票を結びます。移行後の authorized_keys 行数が減らなければ、移行は途中で止まっています。
FAQ、クロスリンク、ホスト型リモート Mac が優れるトレード
ホスト証明書は必須ですか？
必須ではありませんが、初回警告を減らし複数エンドポイントではユーザー証明書と併用しやすいです。
証明書はハードウェアセキュリティキーと共存しますか？
はい。証明書は公開鍵に署名し、秘密鍵は YubiKey や Secure Enclave に置けます。
チェックサムゲートは不要になりますか？
いいえ。身元と整合性は別です。昇格前検証は続けます。
まとめ：ユーザー証明書は信頼面を縮め Principal を構造化し、ローテを期限の問題に寄せます。SFTP のみ、chroot、同時制御、原子フォルダと組み合わせてください。
限界：CA と発行サービスは継続コストです。デモだけ作って所有者がいなければ静的鍵に戻ります。稼働と経路よりビルドに集中するなら SFTPMAC のホスト型リモート Macが隔離と安定入口を束ね、証明書はお客様側に残せます。自前は電力・冷却・リモートハンドも積み上がり、証明書だけでは消えません。
予測可能な SFTP 入口と隔離が欲しい場合は SFTPMAC のプランをご覧ください。