
이 글은 인프런 강의 「백엔드 개발자를 위한 서버 보안 실무」 섹션 5를 입문자용으로 풀어 쓴 글이에요.
우리 서비스는 디스크 암호화를 켜 두었어요. 그런데 웹 서버에 누군가 남겨 둔 DB 백업 파일 하나가 새어 나갔고, 열어 보니 회원 이메일과 전화번호가 그대로 보입니다.
어떻게 된 걸까요? 디스크 암호화는 디스크를 통째로 들고 갈 때만 막아 줍니다. 서버가 켜져 있는 동안 DB가 돌려주는 값은 이미 평문이에요. 금고에 넣어 둔 서류를 꺼내 복사해 가면, 금고는 아무 역할도 못 하는 것과 같습니다.

그러니 "암호화했나요?"보다 "무엇을 막으려고, 어느 계층에서 했나요?" 가 맞는 질문이에요. 참고로 비밀번호는 암호화가 아니라 느린 해시로 저장합니다(지난 글에서 다뤘어요).
암호화의 진짜 어려움은 키 관리예요. 코드 안에 키를 박아 두면, 코드와 데이터가 함께 새는 순간 암호화는 의미가 없어집니다.

그래서 많이 쓰는 방식이 봉투 암호화입니다. 데이터는 데이터 키로 암호화하고, 그 데이터 키는 다시 KMS(키 관리 서비스) 가 감싸요. DB에는 암호문과 "감싼 키"만 저장됩니다. 덤프가 새도, KMS에 풀어 달라고 요청할 권한이 없으면 읽을 수 없어요. 그리고 누가 언제 풀었는지 기록이 남습니다.

정말 흔한 장면이에요. 로컬 설정 파일이 커밋에 섞여 공개 저장소에 올라갔고, 다음 커밋에서 지웠습니다. 하지만 이력에는 그대로 남아 있고, 공개 저장소는 자동 수집기들이 쉬지 않고 훑어요. 키처럼 생긴 문자열은 사람보다 먼저 찾아냅니다.
문제를 키우는 건 키의 성격이에요. 만료 없는 키에 관리자에 가까운 권한이 붙어 있다면 피해는 채굴 서버, 데이터 반출, 요금 폭탄으로 이어집니다. 원칙은 푸시 단계에서 막고, 값은 시크릿 매니저에 두고, 가능하면 짧게 사는 자격 증명을 쓰는 것이에요. 새었다면 커밋을 지우는 게 아니라 폐기가 먼저입니다.
TLS 검증 끄기. 개발 서버의 인증서 오류를 피하려고 "임시로" 인증서 검증을 꺼 둔 한 줄은, 대개 운영까지 따라갑니다. 그러면 중간에 끼어든 공격자의 가짜 인증서도 그냥 믿게 돼요. 끄지 말고, 내부 API라면 믿을 사내 인증 기관을 지정하는 게 맞습니다. 게다가 인증서 수명이 단계적으로 짧아지고 있어서, 갱신은 사람이 아니라 자동화가 해야 해요.
로그로 새는 개인정보. DB를 아무리 잘 지켜도, 요청 본문을 통째로 남긴 로그에 전화번호와 주소가 쌓여 있다면 로그 저장소가 유출 경로가 됩니다. 필요한 것만 받고, 남기기 전에 마스킹하고, 기간이 지나면 파기하는 것이 개발자가 코드로 할 수 있는 개인정보 보호예요.

월요일 아침, 모든 파일에 낯선 확장자가 붙어 있습니다. 다행히 매일 백업을 했는데, 서버에 연결해 둔 백업까지 똑같이 잠겨 있어요. 공격자는 랜섬웨어를 돌리기 전에 백업부터 찾습니다.
그래서 백업은 서버의 권한으로는 지울 수 없는 곳에, 변경 불가 사본을 포함해 둡니다. 그리고 실제로 되돌려 보는 복구 시험을 해야 진짜 백업이에요. 한 번도 복구해 보지 않은 백업은 희망 사항에 가깝습니다.
강의에서는 이걸 직접 해 봅니다
섹션 5에서는 덤프 유출, 커밋 속 키, 검증을 끈 클라이언트, 로그 속 개인정보, 백업까지 잠그는 랜섬웨어 시나리오를 실습 환경에서 재현하고 막습니다.
- KMS 봉투 암호화와 검색 가능한 암호화 컬럼 구현
- 시크릿 스캔과 키 회전, 단기 자격 증명으로 바꾸는 과정
- 이그레스 통제로 서버 밖으로 나가는 길 막기, 변경 불가 백업과 복구 훈련
- 공개된 대형 유출 사고를 예제 서비스 위에 다시 그려 "어디서 끊었을지" 따져 보기
강의 보러 가기: https://inf.run/XvwyH