2026SFTPChroot멀티테넌트

2026 원격 Mac SFTP 멀티테넌트 격리 실무: ChrootDirectory, internal-sftp, 「업로드 전용 계정」 의사결정표

외주·CI·내부가 같은 원격 Mac SFTP 입구를 쓸 때 전형적 위험은 쓰기 가능한 chroot 루트, 남은 셸, 공유 키입니다. internal-sftp·ChrootDirectory 불변 조건을 동시 세션·원자 릴리스·권한 감사와 함께 설계하세요.

원격 MacSFTPChrootDirectoryinternal-sftp최소 권한
원격 Mac에서 테넌트별 SFTP 경로를 격리하는 개념

공유 SFTP 진입점에서 격리가 흔히 깨지는 세 지점

실무에서 위험한 것은 쓰기 가능한 chroot 루트, 셸이 남아 있는 ‘SFTP’ 계정, CI와 사람이 같은 키를 쓰는 운영입니다. internal-sftpChrootDirectory는 경로 소유·권한이 불변 조건을 만족할 때만 의미가 있으며, 재귀적 chmod -R 777는 모델을 망가뜨립니다.

1) chroot와 그 조상 디렉터리는 root 소유여야 하고 테넌트가 쓸 수 없어야 합니다. 그렇지 않으면 하위 시스템이 거부하거나 심링크 치환 리스크가 남습니다.

2) ForceCommand internal-sftp가 없거나 Match 순서가 잘못되면 셸·scp·포워딩이 남을 수 있습니다.

3) 키·로그가 테넌트와 매핑되지 않음. authorized_keys 오류는 약한 비밀번호로 회귀를 부릅니다. 경계마다 계정 분리, 키 주석에 담당자, 동시 세션 한도와 맞춰 inode 고갈을 막습니다.

SFTP 전용과 셸: chroot를 택할 만한 때

작은 팀이 동일 신뢰 도메인이면 ‘계정 분리+경로 접두’로 충분할 수 있습니다. 외주·CI 봇처럼 경계를 넘으면 chroot가 맞습니다. 대가는 root가 소유하는 골격 디렉터리와 키 프로세스 유지입니다.

SFTP 전용은 nologin 셸, ForceCommand internal-sftp, 포워딩 차단, 대외적으로 scp 금지를 명시합니다. 관리 셸은 별도 Match나 별 호스트명으로 둡니다.

chroot와 원자 릴리스는 보완 관계입니다. chroot는 가로 확산을 줄이고, 스테이징+심링크가 읽기 일관성을 담당합니다. 프로토콜·권한 감사Mac 클라이언트·CI 도구 선정과 함께 설계하세요.

의사결정표: 격리 강도와 운용 비용

가장 잘 맞는 경우주요 리스크최소 통제면
공유 디렉터리, chroot 없음단일 신뢰 도메인·소규모 팀한 키 유출 시 횡적 이동그룹 권한, CI 전용 계정, 중앙 로그
SFTP만, chroot 없음내부망 개발자, IAM 강함경로 설정 실수로 우회주기적 find 점검, 기본 umask
chroot + internal-sftp외주·컴플라이언스 구획소유자 오류로 로그인 불가root 소유 체인, 잎만 쓰기 허용
테넌트별 독립 호스트강한 규제·노이지 네이버비용·패치 면적이미지 기준선, 자동 패치, 키 백업

다섯 단계: OpenSSH Match 골격

변경 전 설정과 sshd -T를 백업하고, macOS 메이저 업그레이드 후 diff를 다시 확인합니다.

  1. chroot 부모 경로를 만들고 조상은 모두 root·755·그룹 쓰기 불가로 둡니다.
  2. jail 안의 upload/는 테넌트 소유, chroot 루트 자체는 쓰기 불가입니다.
  3. MatchForceCommand internal-sftp, ChrootDirectory, 포워딩 차단. 필요 시 jail 밖 AuthorizedKeysFile을 둡니다.
  4. sshd -t, reload, sftp -vvv로 검증하고 ssh 실행은 거절되는지 봅니다.
  5. 상세 인증 로그는 잠시 켠 뒤 되돌립니다.

3단계 이후 역방향 테스트(scp·원격 실행·포워딩)가 모두 실패해야 하며, 공급사 문서에 기대값을 적습니다. 5단계는 모니터링에 연결해 인증 실패·하위 시스템 오류, 디스크와 inode를 봅니다.

# 片段示例 —— 用户名/路径/组请按实际替换;改前 sshd -t
Match Group sftponly
  ChrootDirectory /srv/sftp/%u
  ForceCommand internal-sftp
  AllowTCPForwarding no
  X11Forwarding no
  PermitTunnel no
  AuthorizedKeysFile /etc/ssh/authorized_keys/%u

# 宿主机侧(jail 外)示意:
# mkdir -p /srv/sftp/vendorA/upload
# chown root:wheel /srv/sftp /srv/sftp/vendorA
# chmod 755 /srv/sftp /srv/sftp/vendorA
# chown vendorA:vendorA /srv/sftp/vendorA/upload
# chmod 750 /srv/sftp/vendorA/upload

chown·chmod를 Runbook에 남기고, 임시 완화에는 반드시 회수 일정을 둡니다. reload와 롤백도 리허설합니다.

인용하기 쉬운 수치와 불변 조건

chroot 조상은 현장에서 흔히 755, 테넌트 데이터는 750로 그룹 메타데이터 읽기를 줄입니다. chroot 루트에 그룹 쓰기나 기타 쓰기를 주지 않는다는 요구는 OpenSSH 문서에도 분명합니다. 컴플라이언스로 subtree를 world-readable로 해야 해도, 루트에서 파일시스템까지 이어지는 전체 체인을 느슨하게 하지 마세요.

디스크 쿼터는 연결 한도를 대체하지 않습니다. 소용량 파일을 대량으로 올리는 테넌트는 남은 GB가 있어도 inode를 먼저 소모할 수 있어 두 지표를 함께 봅니다. 단일 객체가 약 5 GiB를 넘으면 검증·스테이징 전략(원자 릴리스 글 참고)을 쓰고, SFTP 타임아웃만 늘리는 방식은 피합니다.

외부 테넌트 키는 90일 전후 로테이션, 노트북 분실 시 즉시 폐기. CI는 짧은 수명·파이프라인 전용 키, 공개키 변경은 코드 리뷰. 인증 로그 최소 30일, authorized_keys 주석에 담당자 표기.

FAQ, 한계, 관리형 원격 Mac

  • chroot 켜자마자 끊김? 경로 소유·권한, internal-sftp 강제, sshd가 키 파일을 읽는지 층별로 확인합니다.
  • chroot가 클라이언트 랜섬웨어를 막나? 아니요. 주로 서버 측 자격 증명 유출 후 횡적 이동을 줄입니다.

정리: internal-sftp + ChrootDirectory + root 소유 체인 + 잎만 쓰기 + SFTP 전용 Match가 재현 가능한 멀티테넌트 경계를 만듭니다. 세션 예산·원자 릴리스·키 감사와 함께 쓰세요.

한계: 자체 원격 Mac은 sshd 수동 편집, 임시 계정, 공유 비밀번호가 쌓이기 쉽습니다. IaC와 주기 감사가 없으면 chroot 설정이 ‘문서와 실물 불일치’로 표류합니다.

SFTPMAC: 관리형 원격 Mac은 SFTP 경로 격리와 sshd 기준선을 재현하기 쉬워 다팀 인도에 적합합니다. 운영상 원자 릴리스동시 전송 전략을 병행하는 것을 권장합니다.