단기 클라우드 Mac의 보안 기준과 비밀 정보 정리

출시를 일주일 앞두고 클라우드 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에서 노드 전용 별칭을 지정하고, SSH 클라이언트가 다른 키를 시도하지 않도록 IdentitiesOnly yes를 설정할 수 있습니다. 노드 주소, 사용자 이름, 키 경로는 이번 주문 기록에서 가져와야 하며, 실제 주소를 코드 저장소에 커밋해서는 안 됩니다.

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의 변수를 즉시 제거합니다. 한 번의 출시에만 사용하는 자격 증명이라면 여러 세션에 걸쳐 장기간 남겨 두지 마세요.

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에서 개별 파일을 여러 번 덮어쓰는 것은 플랫폼의 노드 회수 절차를 대신할 수 없습니다. 덮어쓰기 횟수를 정리 완료의 증거로 간주해서도 안 됩니다.

노드를 떠나기 전에는 역방향으로 한 번 더 점검하세요. 전용 키로 계속 로그인할 수 있는지, 임시 토큰이 무효화되었는지, 백그라운드 프로세스가 아직 실행 중인지, 반출 파일이 노드에 남아 있는지, 작업 디렉터리에 커밋되지 않은 변경 사항이 있는지 확인합니다. 결과를 인수인계 기록에 남기면 “삭제했다고 생각한 상태”와 “실제로는 여전히 접근 가능한 상태” 사이의 차이를 줄일 수 있습니다.

자주 묻는 질문