키 하나가 계정 전체가 될 때: 클라우드 보안과 사고 대응 입문

아프로·2026년 10월 29일

키 하나가 계정 전체가 될 때 표지

이 글은 인프런 강의 「백엔드 개발자를 위한 서버 보안 실무」 섹션 6 뒷부분을 입문자용으로 풀어 쓴 글이에요.

토요일 새벽의 청구서

몇 년 전 배포용으로 만든 액세스 키가 하나 있어요. 그 키가 토요일 새벽에 쓰이기 시작합니다. 처음 몇 번은 "이 키는 누구고 무슨 권한이 있지?"를 확인하는 요청이에요. 1분 뒤에는 새 관리자 계정이 만들어지고, 곧 모든 리전에 비싼 인스턴스가 뜹니다.

월요일 아침, 팀이 처음 보는 건 보안 알림이 아니라 청구서예요. 기록은 다 남아 있었지만 아무도 보지 않았습니다.

오래된 액세스 키 하나가 새면 일어나는 다섯 단계

클라우드: 키 하나 = 계정 전체

서버 한 대가 뚫리면 그 서버가 피해 범위예요. 하지만 클라우드 키 하나가 새면 그 키가 닿는 모든 서버, 스토리지, 백업이 피해 범위가 됩니다. 요즘은 훔친 키로 남의 계정에서 채굴을 하거나, 생성형 AI 서비스를 몰래 써서 요금을 떠넘기는 공격(이른바 LLMjacking)도 알려져 있어요.

클라우드는 공동 책임 모델이에요. 데이터센터와 하드웨어는 클라우드 사업자가 지키지만, 계정·권한·설정·데이터는 우리 몫입니다. 원칙은 네 가지로 정리돼요.

  • 장기 키를 없앤다: 사람은 SSO로 로그인하고, CI는 실행마다 짧은 자격 증명을 받습니다.
  • 최소 권한: "모든 동작, 모든 자원"은 키가 새는 순간 계정 전체라는 뜻이에요.
  • 안 쓰는 리전은 막는다: 공격자는 우리가 안 보는 곳에 자원을 띄웁니다.
  • 바로 알린다: 감사 로그와 예산 알림. 비용도 보안 신호예요.

쿠버네티스: 파드 하나가 클러스터 전체로

파드 하나가 뚫렸을 때 번지는 세 경로

쿠버네티스의 기본값도 "편하게"에 맞춰져 있어요. 파드 안에는 쿠버네티스 API를 부를 수 있는 서비스 계정 토큰이 기본으로 들어 있고, 네트워크는 모든 파드가 서로 통신할 수 있게 열려 있습니다. 여기에 배포를 편하게 하려고 관리자 권한까지 붙여 두면, 게시판 앱 하나가 뚫렸을 때 결제 서비스의 시크릿까지 읽힐 수 있어요.

방향은 이번 시리즈에서 반복해 온 원칙과 같습니다. 토큰은 필요한 앱에만, 네트워크는 기본 차단 후 필요한 길만, 권한은 최소로.

위협 헌팅: 알림을 기다리지 않는다

공격자가 서버에 남기는 다시 올 문 네 가지

오늘 보안 알림은 한 건도 없었어요. 그런데 서버 연결 목록을 보니, 커널 작업처럼 생긴 이름의 프로세스가 외부 주소와 연결돼 있습니다. 알림이 없다고 안전한 건 아니에요.

공격자는 들어온 뒤 다시 올 문을 남깁니다. 몰래 추가한 SSH 키, 주기적으로 외부에서 무언가를 받아 오는 예약 작업, 그럴듯한 이름의 서비스, 임시 폴더에 숨은 실행 파일. 입구만 막으면 공격자는 그대로 남아 있어요. 위협 헌팅은 "공격자라면 어디에 남았을까?"라는 가설을 세우고 직접 찾는 일입니다. 그리고 찾은 것은 다음부터 자동으로 잡히도록 규칙으로 남겨요.

침해 확인 직후, 첫 한 시간

침해 직후 흔한 실수와 원칙

침해를 확인하면 마음이 급해져요. 그래서 가장 흔한 실수가 일단 재부팅입니다. 메모리에서만 돌던 악성 프로세스와 연결 정보가 함께 사라져요. 의심 파일을 바로 지우면 들어온 길을 잃습니다. 눈에 덜 띄는 실수도 있어요. 평소 돌던 로그 자동 삭제를 그대로 두면, 사고 기간의 접속 기록이 사라집니다. 평소의 정리 작업이 사고 때는 증거 인멸이 되는 거예요.

원칙은 "기록부터 시작하고, 사라지기 쉬운 것부터 보존하고, 전원은 켠 채 네트워크만 격리하고, 그 서버의 비밀은 모두 샜다고 보고 바꾼다"입니다.

사고 이후: 두 개의 시계

침해를 알게 된 순간부터 법적인 시계도 돌아요. 국내 기준으로 정보통신망법의 침해사고 신고(알게 된 뒤 24시간 안), 개인정보가 유출됐다면 이용자 통지와 기관 신고(72시간 안)가 대표적입니다. 원인을 다 몰라도 먼저 알리고, 새로 알게 된 건 보완해서 다시 알려요. (이 글은 법률 자문이 아니에요. 실제 대응은 최신 조문과 전문가 의견으로 확인하세요.)

그리고 회고는 "누가 잘못했나"가 아니라 "왜 가능했나" 를 묻습니다. 원인마다 구체적인 개선 과제를 하나씩 정하고, 같은 입구가 정말 닫혔는지 직접 두드려 확인해요.

정리

  • 클라우드 키 하나는 계정 전체다. 장기 키를 없애고, 최소 권한, 안 쓰는 리전 차단, 비용 알림까지.
  • 파드 하나가 클러스터 전체가 되지 않게: 토큰·네트워크·권한을 기본 차단으로.
  • 알림이 없어도 직접 찾고, 사고 첫 한 시간은 "지우기"가 아니라 "보존"부터.

강의에서는 이걸 직접 해 봅니다

섹션 6 후반부에서는 파드 탈취 후 확산, 유출된 클라우드 키로 권한 확대, 서버에 남은 지속성 흔적 찾기, 침해 직후 증거 보존과 격리를 실습 환경에서 단계별로 진행합니다.

  • 쿠버네티스 보안 기준·네트워크 정책·최소 권한을 실제로 적용하고 확인
  • 클라우드 IAM 정리, 감사 로그와 위협 탐지·예산 알림 구성
  • 헌팅 결과를 탐지 규칙으로 남기는 법, 첫 한 시간 대응 순서와 사후 신고·회고의 흐름

강의 보러 가기: https://inf.run/XvwyH


profile
고인물 개발자(OG)

0개의 댓글