보안 인벤토리 — 서버 여러 대를 운영하는 사람이 놓치는 7가지 점검

서버·사이트·도메인 여러 개를 관리하는 1인 또는 소규모 운영자 대상. "돌아가니까"라며 점검을 미뤄왔을수록 더 해당합니다. 공격 절차는 없습니다 — 오직 스스로 나열해 지울 수 있는 위험뿐입니다.

"추가" 전에 "세고 줄이기"

추적되지 않은 상태 자체가 위험입니다. 점검해 보면 보통 이렇습니다:

1. "서버"가 아니라 "키를 쥔 PC"를 지켜라

서버를 아무리 단단히 굳혀도, SSH 개인 키를 쥔 PC가 침해되면 전부 열립니다. 키 인증으로 전환하는 순간, 당신 함대의 진짜 경계가 "키를 쥔 PC"로 옮겨갑니다. 그래서 우선순위는 "서버 → PC"가 아니라 **"PC → 서버"**입니다.

가장 가치 높은 점검: .ssh가 클라우드 동기화 폴더(OneDrive/Drive/Dropbox) 밖에 있는지. 개인 키가 실수로 동기화 아래에 있으면, PC를 건드리지 않아도 클라우드 계정이 함락되는 순간 키가 샙니다. 키에 대한 최소 권한 사고방식은 SSH 키와 최소 권한에 있습니다.

2. "신뢰의 뿌리"로 2FA를 계층화하라

"전부에 2FA를 추가"는 막연히 시작하면 끝이 없습니다. 통제의 사슬(신뢰의 뿌리)로 계층화하면 우선순위가 저절로 정해집니다.

실전의 핵심: 백업 코드를 종이로 보관하고(클라우드에 두면 2FA의 의미가 절반으로), 복구 이메일이 살아 있고 당신의 통제 아래 있는지 확인하세요. 절차는 다단계 인증 가이드와 보안 베이스라인 체크리스트에 있습니다.

3. SSH 키는 매트릭스로 만들기 전까지 "관리된" 것이 아니다

"키 인증이니까 안전"은 관리가 아닙니다. 실제로 필요한 것은 "어느 PC의 어느 키가 어느 서버를 여는가"의 표 하나입니다. 각 서버의 authorized_keys를 지문으로 대조하면 보이지 않던 것이 드러납니다 — 중복 키(같은 키가 두 이름으로), 미사용 키(어디에도 안 쓰임), 고아 등록(사라진 용도로 남음). authorized_keys는 추가하기 쉽고 정리하기를 잊기 쉽습니다. 매트릭스는 행마다 "이건 뭘 위한 거지?"라고 물을 수 있게 합니다.

4. EOL 기기: 노력 대 위험을 저울질한 최소 노력의 차단

OS가 수명 종료(EOL)에 이른 기기의 키는 흔합니다. 크게 가는 것 — "모든 키를 교체하고 모든 서버를 재설정" — 은 너무 무거워 결국 안 하게 됩니다.

요령: 미뤄둔 완벽한 절차보다 오늘 실제로 끝낼 수 있는 차단을 택하세요.

5. 클라우드에서 평문 비밀번호를 제거하라

비밀번호 관리자 논쟁 이전에, 더 큰 실제 피해가 있습니다: 클라우드 문서에 놓인 평문 비밀번호 목록. 새면 즉각 전면 손실입니다.

"어느 관리자가 최고냐"는 "클라우드에서 평문을 제거했는가"보다 훨씬 덜 중요합니다(→ 비밀번호 관리자 고르는 법 / 비밀번호를 안전하게 보관하기).

6. "되돌릴 수 있게, 한 번에 하나씩" 조치하라

인벤토리가 문제를 드러내면 한꺼번에 다 고치고 싶어집니다. 프로덕션에서 기세로 여러 개를 동시에 바꾸는 것이 가장 위험한 수입니다. 되돌리기 어려운 작업 — 키 교체, 설정 변경, 프로덕션 배포 — 은 전체 백업과 복원 절차를 준비한 뒤(즉 되돌릴 수 있게 만든 뒤) 한 번에 하나씩 하세요. 조치 그 자체로 새 구멍을 내지 마세요(→ 백업과 복구).

7. 대장이 시크릿을 담지 않도록 설계하라

결과 대장은 새면 공격 지도가 됩니다. 그러니 미리 선을 그으세요.

지문과 공개 키는 "어느 키인지"만 식별하며 단독으로는 악용될 수 없습니다. 새도 치명적이지 않은 정보만으로 상태를 표현하면 — 대장은 클라우드에 두거나 팀과 공유해도 안전하게 유지됩니다.

다음으로 읽기

• 키: SSH 키와 최소 권한
• 기준: 보안 베이스라인 체크리스트 · 다단계 인증 가이드
• 보관: 비밀번호 관리자 고르는 법