공유 SFTP 진입점에서 격리가 흔히 깨지는 세 지점
실무에서 위험한 것은 쓰기 가능한 chroot 루트, 셸이 남아 있는 ‘SFTP’ 계정, CI와 사람이 같은 키를 쓰는 운영입니다. internal-sftp와 ChrootDirectory는 경로 소유·권한이 불변 조건을 만족할 때만 의미가 있으며, 재귀적 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를 다시 확인합니다.
- chroot 부모 경로를 만들고 조상은 모두 root·755·그룹 쓰기 불가로 둡니다.
- jail 안의
upload/는 테넌트 소유, chroot 루트 자체는 쓰기 불가입니다. Match에ForceCommand internal-sftp,ChrootDirectory, 포워딩 차단. 필요 시 jail 밖AuthorizedKeysFile을 둡니다.sshd -t, reload,sftp -vvv로 검증하고ssh실행은 거절되는지 봅니다.- 상세 인증 로그는 잠시 켠 뒤 되돌립니다.
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 기준선을 재현하기 쉬워 다팀 인도에 적합합니다. 운영상 원자 릴리스와 동시 전송 전략을 병행하는 것을 권장합니다.
