원격 Mac에서 파일을 안전하게 인계하는 방법

팀이 서명 자료, 테스트 데이터 또는 검수를 기다리는 빌드 산출물을 클라우드 Mac으로 전송할 때 가장 흔히 저지르는 실수는 파일을 저장소 루트에 바로 넣는 것입니다. 파일이 도착하는 즉시 인덱서, 빌드 스크립트, 정리 작업이 이를 읽을 수 있습니다. 압축 파일에 경계를 벗어나는 경로, 잘못된 권한 또는 설명되지 않은 확장 속성이 포함되어 있다면 문제가 작업 공간 전체로 곧바로 확산될 수 있습니다. 더 안전한 방법은 ‘전송’과 ‘사용’을 별도의 두 단계로 분리하는 것입니다.

먼저 인계 경계 정의하기

인계할 때마다 최소한 발신자, 수신자, 파일 용도, 보관 기간의 네 가지 항목을 명확히 해야 합니다. 소스 코드 패치, 테스트 픽스처, 빌드 산출물, 자격 증명을 하나의 압축 파일에 섞어서는 안 됩니다. 자격 증명은 통제된 주입 메커니즘을 통해 제공해야 하며, 채팅 기록이나 빌드 로그, 일반 파일 패키지에 포함해서는 안 됩니다.

VMRunner의 전용 물리 노드에서도 장기간 유지되는 Downloads를 재사용하지 말고 작업마다 별도의 임시 반입 디렉터리를 만들어야 합니다. 디렉터리 이름에는 티켓 번호나 내부 작업 번호를 사용할 수 있지만, 고객 이름이나 이메일 주소를 비롯한 민감한 정보는 포함하지 마십시오.

umask 077
handoff_root="$HOME/Handoffs/task-4821"
install -d -m 700 "$handoff_root/incoming"
install -d -m 700 "$handoff_root/verified"
install -d -m 700 "$handoff_root/logs"
stat -f '%Su %Sg %Sp %N' "$handoff_root" "$handoff_root/incoming"

umask 077을 설정하면 이후 생성되는 파일은 기본적으로 현재 사용자만 접근할 수 있습니다. install -d는 디렉터리를 만들면서 동시에 권한을 설정하므로, 디렉터리를 먼저 만든 뒤 권한을 수정하는 사이에 잠시 노출되는 상황을 방지합니다.

임시 반입 영역의 목적은 파일을 영구 보관하는 것이 아닙니다. 파일이 프로젝트 작업 공간으로 들어가기 전에 검사하고, 거부하고, 정리할 수 있는 완충 구역을 제공하는 데 목적이 있습니다.

전송 전에 검증 가능한 목록 만들기

발신자는 먼저 디렉터리 내용을 확정한 다음 체크섬을 생성해야 합니다. 빌드 작업이 산출물을 계속 수정하는 동안 해시를 계산하면 수신자가 받은 목록이 서로 다른 버전의 파일을 가리킬 수 있습니다. 먼저 읽기 전용 배포 디렉터리로 복사하고 파일 수를 확인한 뒤 SHA-256 목록을 생성하는 것이 좋습니다.

패키징할 때 불필요한 내용 제외하기

소스 코드를 전달할 때는 .git, 로컬 캐시, 파생 데이터, 환경 파일을 제외하십시오. 반면 빌드 산출물을 전달할 때는 필요한 서명 구조와 확장 속성을 유지해야 합니다. 용량을 줄이겠다는 이유로 애플리케이션 디렉터리를 임의로 다시 패키징해서는 안 됩니다.

cd "$HOME/Delivery/task-4821"
find . -type f ! -name 'SHA256SUMS' -print0 \
  | sort -z \
  | xargs -0 shasum -a 256 > SHA256SUMS
shasum -a 256 SHA256SUMS

수신자는 사전에 확인된 내부 채널을 통해 SHA256SUMS 파일 자체의 체크섬을 별도로 받아야 합니다. 목록과 파일이 검증되지 않은 동일한 경로로 전달되면 공격자가 두 항목을 동시에 바꿀 수 있습니다.

수신 후 압축을 풀기 전에 검증하기

파일은 저장소를 직접 덮어쓰지 말고 먼저 incoming에 넣어야 합니다. 수신이 완료되면 이름, 크기, 소유자, 권한을 먼저 기록한 뒤 체크섬을 비교하십시오. 하나라도 일치하지 않으면 작업을 중단해야 합니다. ‘수정한 다음 계속 사용’하려고 해서는 안 됩니다. 차이는 전송 중단, 발신자의 재패키징 또는 파일 교체로 인해 발생했을 수 있기 때문입니다.

cd "$handoff_root/incoming"
shasum -a 256 -c SHA256SUMS
find . -maxdepth 2 -print0 \
  | xargs -0 stat -f '%z %Su %Sg %Sp %N' \
  > "$handoff_root/logs/received-files.txt"

압축 파일의 경로부터 확인하기

ZIP 파일은 먼저 unzip -l package.zip을 실행하고, tar 파일은 tar -tf package.tar을 실행하십시오. 절대 경로, 디렉터리 경계를 벗어나는 ../ 경로 또는 예상하지 못한 심볼릭 링크가 포함된 패키지는 거부해야 합니다. 내용을 확인한 뒤에는 빈 디렉터리에만 압축을 풀고 파일 목록과 권한을 다시 검사하십시오.

macOS 파일에는 확장 속성이 포함될 수도 있습니다. xattr -lr을 사용해 출처 표시와 기타 속성을 확인하되, 습관적으로 재귀 삭제하지 마십시오. 속성의 출처가 명확하고 영향을 이해했으며 작업에 실제로 필요한 경우에만 지정한 파일의 지정한 속성을 처리해야 합니다.

작업 공간으로 옮길 때 권한 제한하기

검증을 통과한 파일은 verified로 복사한 뒤 프로젝트 책임자가 작업 공간으로 옮기도록 하십시오. 이렇게 하면 처음 수신한 내용과 분리된 검수 완료본을 보관할 수 있습니다. 일반 자료는 현재 사용자에게 읽기 및 쓰기 권한을 부여할 수 있으며, 빌드에서 읽기만 하는 고정 입력 파일은 읽기 전용으로 변경할 수 있습니다.

cp -R "$handoff_root/incoming/ProjectInput" \
  "$handoff_root/verified/"
chmod -R go-rwx "$handoff_root/verified"
find "$handoff_root/verified" -type f -exec chmod 600 {} +
find "$handoff_root/verified" -type d -exec chmod 700 {} +

프로젝트 전체에 재귀 chmod를 무분별하게 실행하지 마십시오. 실행 스크립트, 애플리케이션 번들, 프레임워크는 필요한 권한이 서로 다르므로 모두 600으로 바꾸면 후속 작업이 중단될 수 있습니다. 권한 제한은 이번 인계에 사용하는 임시 복사본에만 적용해야 합니다. 정식으로 가져올 때는 저장소 기록이나 빌드 규칙에 따라 필요한 권한을 복원해야 합니다.

여러 사람이 동일한 클라우드 Mac에서 협업한다면 별도의 시스템 사용자와 디렉터리를 우선 사용하십시오. 일시적으로 모든 사용자에게 읽기 및 쓰기 권한을 허용하면 편리할 수 있지만, 파일의 출처와 수정 책임을 추적할 수 없게 됩니다.

인계 종료 시 잔여 파일 확인하기

작업을 끝내기 전에 프로젝트가 필요한 파일을 확보했는지 확인하고 최종 체크섬을 기록하십시오. 그런 다음 압축을 푼 복사본, 실패 후 재시도한 패키지, 로그 첨부 파일, 파일을 계속 열고 있는 프로세스가 남아 있는지 검사해야 합니다. lsof +D는 큰 디렉터리에서 느릴 수 있으므로 이번 작업의 임시 반입 디렉터리에만 실행하십시오.

lsof +D "$handoff_root" 2>/dev/null
find "$handoff_root" -type f -maxdepth 4 -print
rm -rf "$handoff_root"
test ! -e "$handoff_root" && printf '%s\n' 'handoff removed'

임시 반입 영역을 삭제했다고 해서 키 관리까지 끝난 것은 아닙니다. 민감한 값이 명령줄 인수, Shell 기록, 빌드 로그 또는 오류 보고서에 들어갔다면 관련 기록을 계속 정리하고 해당 자격 증명을 교체해야 합니다. 일반적인 인계에서는 작업 식별자, 발신 및 수신 시간, 목록 체크섬, 검수 결과, 삭제 결과처럼 감사에 필요한 최소 정보만 보관하고 파일 본문은 보관하지 마십시오.

안정적인 원격 협업 절차는 ‘모두가 알아서 조심할 것’이라는 기대에 의존하지 않습니다. 파일이 격리, 검증, 권한 부여, 회수라는 네 가지 명확한 단계를 반드시 거치도록 해야 합니다. 이러한 명령을 팀 스크립트로 만든 뒤에는 무해한 샘플을 사용해 해시 불일치, 경계를 벗어나는 경로, 권한 이상을 정기적으로 테스트하고, 정상 경로뿐 아니라 거부 경로도 실제로 실행 가능한지 확인해야 합니다.

자주 묻는 질문