서버·사이트·도메인 여러 개를 관리하는 1인 또는 소규모 운영자 대상. "돌아가니까"라며 점검을 미뤄왔을수록 더 해당합니다. 공격 절차는 없습니다 — 오직 스스로 나열해 지울 수 있는 위험뿐입니다.
통제를 추가하기 전에 가진 것을 세고 줄이기
추적되지 않은 상태 자체가 위험입니다. 점검해 보면 보통 이렇습니다:
1. 키와 자격 증명을 쥔 PC를 지켜라
서버를 아무리 단단히 굳혀도, SSH 개인 키를 쥔 PC가 침해되면 그 키로 접근할 수 있는 모든 서버가 노출됩니다. 키 인증으로 전환하는 순간, 운영하는 서버 전체의 실질적인 경계가 "키를 쥔 PC"로 옮겨갑니다. 그래서 우선순위는 "서버 → PC"가 아니라 "PC → 서버"입니다.
가장 가치 높은 점검: .ssh가 클라우드 동기화 폴더(OneDrive/Drive/Dropbox) 밖에 있는지. 개인 키가 실수로 동기화 아래에 있으면, PC를 건드리지 않아도 클라우드 계정이 탈취되는 순간 키가 샙니다. 키에 대한 최소 권한 사고방식은 SSH 키와 최소 권한에 있습니다.
2. 2FA를 우선순위대로 설정하라: 이메일, 도메인, 청구 순
"전부에 2FA를 추가"는 막연히 시작하면 끝이 없습니다. 어느 계정이 다른 계정을 복구할 수 있는지(신뢰의 뿌리)로 순위를 매기면 우선순위가 분명해집니다.
| 계층 | 대상 | 최우선인 이유 |
|---|---|---|
| Tier 0 | 이메일 계정 | 거의 모든 서비스가 "이메일로 재설정 링크"로 복구함 — 이메일을 빼앗으면 아래 2FA들이 우회됨 |
| Tier 1 | 도메인 통제(등록기관/DNS/호스팅/코드 플랫폼) | 사이트 자체가 탈취·교체될 수 있음 |
| Tier 2 | 청구 API(결제 / AI API / 메일 발송) | 직접적 금전 손실로 이어짐 |
실전에서는: 백업 코드를 종이로 보관하고(클라우드에 두면 2FA의 의미가 절반으로), 복구 이메일이 아직 작동하고 당신의 통제 아래 있는지 확인하세요. 절차는 다단계 인증 가이드와 보안 베이스라인 체크리스트에 있습니다.
3. 어느 SSH 키가 어느 서버를 여는지 목록으로 만들어라
"키 인증이니까 안전"은 관리가 아닙니다. 실제로 필요한 것은 "어느 PC의 어느 키가 어느 서버를 여는가"의 표 하나입니다. 각 서버의 authorized_keys를 지문으로 대조하면 보이지 않던 것이 드러납니다 — 중복 키(같은 키가 두 이름으로), 미사용 키(어디에도 안 쓰임), 고아 등록(사라진 용도로 남음). authorized_keys는 추가하기 쉽고 정리하기를 잊기 쉽습니다. 표가 있으면 행마다 "이건 뭘 위한 거지?"라고 물을 수 있습니다.
4. 지원 종료 기기를 최소한의 작업으로 차단하라
OS가 수명 종료(EOL)에 이른 기기의 키는 흔합니다. 크게 가는 것 — "모든 키를 교체하고 모든 서버를 재설정" — 은 너무 무거워 결국 안 하게 됩니다.
누출 징후가 있는지 확인한다
최소 노력의 차단 = 기기에서 키를 삭제한다
지원 종료 기한을 캘린더에 올린다
요령: 미뤄둔 완벽한 절차보다 오늘 실제로 끝낼 수 있는 차단을 택하세요.
5. 클라우드에서 평문 비밀번호를 제거하라
비밀번호 관리자 논쟁 이전에, 더 큰 실제 피해가 있습니다: 클라우드 문서에 놓인 평문 비밀번호 목록. 새면 모든 계정이 한꺼번에 노출됩니다.
평문 목록(클라우드 문서)
- 계정 하나가 탈취되면 전부 누출
- 손으로 가짜 사이트에 붙여넣게 됨
- 침해 탐지도, 자동 입력도 없음
기기 측 암호화 저장
- 내용이 당신의 기기에서 암호화됨(제공자는 읽지 못함)
- 가짜 도메인엔 자동 입력 안 함 = 피싱 저항
- 이전 후 평문을 완전히 삭제
"어느 관리자가 최고냐"는 "클라우드에서 평문을 제거했는가"보다 훨씬 덜 중요합니다(→ 비밀번호 관리자 고르는 법 / 비밀번호를 안전하게 보관하기).
6. 한 번에 하나씩, 되돌릴 수 있게 조치하라
인벤토리가 문제를 드러내면 한꺼번에 다 고치고 싶어집니다. 프로덕션에서 기세로 여러 개를 동시에 바꾸는 것이 가장 위험한 수입니다. 되돌리기 어려운 작업 — 키 교체, 설정 변경, 프로덕션 배포 — 은 전체 백업과 복원 절차를 준비한 뒤(즉 되돌릴 수 있게 만든 뒤) 한 번에 하나씩 하세요. 조치 그 자체로 새로운 문제를 만들지 마세요(→ 백업과 복구).
7. 대장이 시크릿을 담지 않도록 설계하라
결과 대장은 새면 공격자의 표적 목록이 됩니다. 그러니 미리 선을 그으세요.
적어도 됨(새도 치명적이지 않음)
- 공개 키, 지문
- 설정의 구조, 2FA 켜짐 여부
- 통과/실패 결과
절대 적지 말 것(한 줄만 새도 악용될 수 있음)
- 개인 키 내용
- 비밀번호, API 키
- 실제 재설정 코드
지문과 공개 키는 "어느 키인지"만 식별하며 단독으로는 악용될 수 없습니다. 새도 치명적이지 않은 정보만으로 상태를 표현하면 — 대장은 클라우드에 두거나 팀과 공유해도 안전하게 유지됩니다.
본 사이트의 견해: 도구를 추가하기 전에 인벤토리부터
본 사이트는 시크릿(키, 비밀번호, 접속 정보)을 평문으로 두지 않으며 — 공유 문서에도, 코드에도 — 키를 용도별로 나누고(한 번의 누출이 다른 곳으로 번지지 않게), 한 번에 하나씩 되돌릴 수 있게 조치합니다. 새 도구를 추가하기 전에, 먼저 "추적되지 않은 상태"를 "나열된 상태"로 바꾸세요. 화려하지 않지만, 그것이 무엇보다 많은 위험을 지웁니다.
다음으로 읽기
- 키: SSH 키와 최소 권한
- 기준: 보안 베이스라인 체크리스트 · 다단계 인증 가이드
- 보관: 비밀번호 관리자 고르는 법
- 놓이는 곳: 공개 버킷(점검 대상은 서버만이 아니다)
- 지우는 것을 잊은 것: 서브도메인 탈취와 남은 DNS 레코드(쓰지 않게 된 것도 삭제 전까지는 자산)
- 큰 그림: 흔한 보안 실수 4가지(점검이 효과가 있는 이유)