대상: 임시 환경 — GPU 클라우드 파드, CI 러너, 일회용 VM — 에서 SSH로 프로덕션에 닿는 모든 사람. 공격 절차는 없습니다 — 오직 폭발 반경을 줄이기 위해 키를 최소 권한으로 만드는 것뿐입니다. 키 분리의 토대는 베이스라인 체크리스트를 보세요.
본 사이트의 견해: 임시 환경을 신뢰할 수 없는 것으로 취급하라
일회용 연산 자원은 흔히 보안 강화를 건너뜁니다 — 침해될 수 있는 곳입니다. 거기에 프로덕션 루트 키를 두는 것은 현관 예비 열쇠를 길에 두는 것과 같습니다. 본 사이트는 호스트마다 별도 키를 쓰고, 각각을 용도로 범위 짓고, 미사용 즉시 키를 회수합니다(→ 폭발 반경을 줄이는 키 분리). 키를 "편리한 통행증"이 아니라 "새면 전부를 여는 가장 중요한 자산"으로 다루는 것이 결국 가장 안전한 자세입니다.
✗ 임시 환경의 루트 키
환경 침해 → 그 키로 프로덕션의 루트 → 파일, 시크릿, 다른 서비스까지 닿음 — 전부.
○ 명령 제한 비루트 키
같은 키가 새도, 지정된 그 한 명령만 실행 가능. 셸 없음, 포워딩 없음 — 피해가 한 작업에 갇힘.
임시 환경의 루트 키가 위험한 이유
임시 환경은 보안 강화를 건너뛰는 경향이 있어("곧 지울 거니까") 공격자에게 손쉬운 디딤돌이 됩니다. 거기의 프로덕션 루트 키는 피해를 단번에 극대화합니다.
연산을 위해 파드를 띄우고, 거기서 프로덕션 작업을 하려고 루트의 authorized_keys에 키를 등록한다고 해봅시다. 편리하지만 — 그 파드가 침해되면 공격자가 그 키로 루트로서 프로덕션에 걸어 들어갑니다. 진입점이 RCE든 키 누출이든, 끝의 모양은 같습니다: 탈취된 키로 프로덕션이 넘어감(관련: RCE로 키가 탈취되어 부정 청구됨).
최소 권한 키로 가는 세 단계
"편리하니까 전권을 준다"에서 "할 수 있는 일을 최소로 제한한다"로 바꾸세요.
임시 환경의 루트 키를 회수한다
~/.ssh/authorized_keys에서 삭제하세요. 유휴 상태라면 제거해도 영향이 없습니다. 먼저 "방치된 것"을 없애세요.다시 필요해도 루트로 돌아가지 않는다
키를 단일 작업으로 제한한다
command="..."와 restrict를 추가하세요. 로그인에 성공해도 지정된 그 한 명령만 실행할 수 있으며, 포트 포워딩과 셸이 꺼집니다. 누출이 그 한 작업에 갇힙니다.# Register a key restricted to ONE operation in a non-root user's authorized_keys.
# Logging in with it can run only the given command; forwarding and PTY are off.
command="/usr/local/bin/deploy-pull",restrict ssh-ed25519 AAAA...rest-of-public-key deploy@cirestrict는 포워딩, 에이전트 포워딩, PTY, X11 등을 한 번에 비활성화하고; command="..."는 실행 가능한 동작을 하나로 고정합니다. 기본 수는 단일 용도로 범위 지은 키 — 배포 풀만, 특정 스크립트 실행만 — 을 용도별로 만드는 것입니다.
사람들이 빠지는 설정(위험)
- 파드/CI에서 프로덕션 루트에 키 등록
- 끝난 키를 그대로 둠
- 하나의 키를 여러 호스트에 재사용
- 전체 셸을 주는 키를 흩뿌림
최소 권한 설정
- 프로덕션엔 비루트 사용자로만 닿음
- 키는 한 작업으로 제한(명령 제한)
- 호스트별·용도별로 키 분리
- 미사용 즉시 authorized_keys에서 키 제거
재사용 키를 가장 중요한 자산으로 취급하라
키를 "편리한 통행증"으로 여기면 재사용하고 삭제를 잊습니다. 뒤집으세요: 그것을 새면 전부를 여는 가장 중요한 자산으로 취급하세요. 호스트별·용도별로 분리하고, 프로덕션 키를 임시 환경에서 빼두고, 사용 후 항상 제거하세요. 그것만으로 최악의 사슬 — 한 번의 누출이 전부로 연쇄하는 것 — 을 끊습니다.
본 사이트는 직접 어떻게 하는가
본 사이트는 서버마다 전용 키를 쓰며 키를 재사용하지 않습니다. 배포는 비루트, 용도 전용 사용자에 떨어지고, 프로덕션은 일방향입니다 — "받기만 하고, 가져오러 나가지 않음"(→ 프로덕션은 받기만). 임시 연산 자원에서 프로덕션으로 가는 상시 키를 남겨두지 않으며, 필요할 때만 최소 권한으로 연결합니다. 이유는 정확히 이 글의 것입니다: 키의 도달 범위를 미리 작게 설계해 한 번의 침해가 전부로 연쇄하지 못하게 하는 것.
다음으로 읽기
FAQ
Q임시 환경에 루트 키를 두는 게 왜 위험한가요?
GPU 클라우드 파드나 CI 러너 같은 임시 환경은 일회용이라 보안 강화를 건너뛰는 경우가 많고 침해될 수 있습니다. 거기에 프로덕션 루트 키를 두면, 그 환경이 침해되는 순간 공격자가 키와 함께 프로덕션에 루트를 얻습니다. 임시 환경을 신뢰할 수 없는 것으로 취급하고 프로덕션 루트 키를 그곳에서 빼두세요.
Q그래도 임시 환경에서 프로덕션에 닿아야 한다면요?
루트로 돌아가지 마세요. 전용 비루트 사용자를 만들고, 할 수 있는 일을 단일 작업으로 제한하는 키를 등록하세요. authorized_keys에서 명령 제한·restrict 플래그가 붙은 키는, 로그인에 성공해도 그 한 명령만 실행할 수 있습니다. 그러면 누출이 그 한 작업에 갇힙니다.
Q키 관리의 핵심 원칙은 무엇인가요?
재사용 키를 가장 중요한 자산으로 취급하고, 한 번의 누출이 전부를 노출하는 구조를 절대 만들지 마세요. 호스트별·용도별로 키를 분리하고, 더는 필요 없는 키를 authorized_keys에서 제거하세요. 그것이 한 번의 누출이 연쇄하는 것을 막습니다.