← 모든 글

SSH key 회전 정책 — 우리는 분기에 한 번

팀 서버의 SSH 키를 얼마나 자주 바꿔야 하는가 — 우리가 분기 1회로 결론 낸 이유와 실제 운영 절차를 공유한다.

보안 분야에서 “SSH 키는 주기적으로 교체해야 한다”는 말은 누구나 알고 있다. 그런데 실제로 얼마나 자주, 어떤 절차로 바꿔야 하는지를 명문화해둔 팀은 많지 않다. 우리도 처음에는 “문제 생기면 바꾸자” 수준이었다. 팀원이 나가거나 서버가 이상하다 싶을 때. 이 글은 그 느슨한 상태에서 분기 1회 정책으로 바꾸게 된 이유와 실제 절차에 대한 기록이다.

왜 분기인가

연간 교체는 너무 길다. 1년 동안 키가 유출되어도 모를 수 있다. 월별 교체는 너무 잦다. 세 명이 각자 서버 몇 대의 키를 매달 교체하면 작업 자체가 부담이 되고 실수가 생긴다. 분기는 그 중간이다. 3개월마다 한 번, 일정에 넣어두면 잊지 않고 할 수 있는 주기다.

보안 팀이 있는 조직이라면 더 자주 하겠지만, 세 명짜리 팀에서는 지킬 수 있는 정책이 가장 좋은 정책이다.

우리의 교체 절차

절차는 단순하게 유지한다. 복잡하면 빠뜨리거나 미루게 된다.

  1. 새 키 페어를 생성한다. ssh-keygen -t ed25519 -C "팀원명@hedvion-YYYYQQ" 형태로 코멘트에 분기 정보를 박아둔다.
  2. 새 공개키를 대상 서버의 ~/.ssh/authorized_keys에 추가한다. 아직 기존 키는 남겨둔다.
  3. 새 키로 접속이 정상인지 확인한다.
  4. 기존 공개키를 authorized_keys에서 제거한다.
  5. 로컬의 기존 키 파일을 삭제 또는 아카이브한다.

팀원이 세 명이므로 각자 담당 서버가 있고, 다른 두 명이 접근할 수 있는 서버에는 교체 전에 슬랙에서 미리 공지한다. 같은 서버에 여러 명의 공개키가 등록된 경우, 한 명이 먼저 자신의 키를 교체하고 나머지가 순서대로 따라간다.

키 파일 네이밍 규칙

~/.ssh/ 아래에 키가 쌓이면 나중에 어느 키가 어느 서버용인지 알기 어렵다. 우리는 {서비스명}_{환경}_{분기} 형태를 사용한다. 예를 들어 hedvion_prod_2026q2 같은 식이다. 오래된 키는 ~/.ssh/archive/에 분기 단위로 폴더를 만들어 보관한다. 언제부터 어떤 키를 썼는지 이력이 남는다.

팀원이 나갈 때

팀원이 나가는 경우에는 분기를 기다리지 않고 즉시 해당 팀원의 공개키를 모든 서버에서 제거한다. 이것은 정책이 아니라 즉시 수행 사항이다. 퇴사 처리와 동시에 진행하도록 체크리스트에 넣어두었다.

분기 회전 정책이 완벽한 보안 솔루션은 아니다. 하지만 아무것도 안 하는 것보다는 훨씬 낫고, 실제로 지킬 수 있다는 점에서 우리 팀에 맞는 방식이라고 생각한다.

— by slecs