세 가지 통증: 로그인은 되는데 감사가 무너지는 이유
첫째, 수명 주기 불일치입니다.외주 종료 후에도 키가 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·접두사를 1:1로 두고 동시 세션을 조정합니다. ssh-keygen 정책과 Principal 매핑을 문서화하여 비공식 스크립트를 막습니다.
수치 기준: 유효기간, 시리얼, 보관
사람은 30~90일, 자동화는 24~72시간을 권장합니다. 발행은 -z 시리얼, -n Principal, 구간, 티켓명을 JSONL에 남기고 90일은 최소 보관합니다. 긴급 중단은 계정 비활성 또는 Principal 제거입니다. chroot와 releases는 디스크·inode를 감시하며, 인증 개선이 용량 문제를 가리지 않게 합니다.
도입 직후에는 휴가 직전 실수와 런북 부족으로 마찰이 납니다. rsync 절차 옆에 재서명을 두고, 규제 환경에서는 시리얼과 변경 티켓을 연결합니다. 이전 후 authorized_keys 행 수가 줄지 않으면 이전이 중간에 멈춘 것입니다.
FAQ, 교차 링크, 호스팅 원격 Mac이 유리한 교환
호스트 인증서는 필수입니까?
필수는 아니나 최초 경고를 줄이고 여러 엔드포인트에서는 사용자 인증서와 잘 맞습니다.
인증서는 하드웨어 보안 키와 공존합니까?
예. 인증서는 공개 키에 서명하며 비밀 키는 YubiKey나 Secure Enclave에 둘 수 있습니다.
체크섬 게이트가 불필요해집니까?
아닙니다. 신원과 무결성은 별개이며 승격 전 검증은 계속합니다.
요약: 사용자 인증서는 신뢰 표면을 줄이고 Principal을 구조화하며 로테이션을 기한 문제로 옮깁니다. SFTP 전용, chroot, 동시 제어, 원자 폴더와 함께 쓰십시오.
한계: CA와 발행 서비스는 지속 비용입니다. 데모만 있고 소유자가 없으면 정적 키로 돌아갑니다. 가동과 경로보다 빌드에 집중하려면 SFTPMAC 호스팅 원격 Mac이 격리와 안정적인 진입점을 묶고 인증서 정책은 고객 측에 둘 수 있습니다. 자체 구축은 전력·냉각·원격 핸드도 누적되며 인증서만으로 사라지지 않습니다.
예측 가능한 SFTP 진입점과 격리가 필요하면 SFTPMAC 요금제를 검토하십시오.