환자 의료기록 133GB가 공개 서버에 노출됐고, 병원은 답이 없었다

• 환자 의료기록 133GB가 공개 서버에 노출된 것으로 보고됨

  • 대상은 캘리포니아 백 앤 페인 스페셜리스트라는 의료기관
  • 노출된 정보에는 환자 개인정보와 민감 문서가 포함된 것으로 설명됨
  • 의료 데이터라서 일반 계정 정보 유출보다 훨씬 무거운 사고임

• 제보 타임라인이 꽤 답답함

  • 2026년 3월 31일, 웹사이트 관리자에게 노출 사실과 민감 문서가 서버에 있다는 내용을 이메일로 알림
  • 그런데 아무도 응답하지 않았고, 문제도 해결되지 않았다고 함
  • 제보자는 며칠을 더 기다린 뒤 다른 경로로 신고하기로 함

• 결국 AWS에 신고하자 6일 만에 조치가 들어감

  • 2026년 5월 20일, 해당 IP를 가진 AWS 고객이 민감한 환자 정보를 노출하고 있다고 Amazon에 신고함
  • Amazon은 추가 정보를 요청했고, 제보자는 조사에 필요한 내용을 제공함
  • 2026년 5월 26일, Amazon은 노출 서버가 완화 조치됐다고 답변함

• 더 큰 문제는 “환자에게 알릴 거냐”는 질문에도 답이 없었다는 점임

  • 2026년 5월 27일, 제보자는 병원 측에 환자, 규제기관, 고객에게 통지할 계획이 있는지 다시 문의함
  • 기사 작성 시점까지 답변을 받지 못했다고 밝힘
  • 의료정보 유출은 조치 완료만으로 끝나는 게 아니라 통지와 규제 대응까지 따라붙는 영역임

• 권고 사항은 화려한 보안 제품보다 기본기에 가까움

  • 모든 서버에서 공개 접근과 디렉터리 리스팅을 즉시 비활성화하라고 권고함
  • 사용자 이름과 비밀번호, 아이피 허용 목록, VPN 같은 강한 인증을 적용하라고 제시함
  • 민감한 환자 데이터는 안전하고 암호화된 환경으로 옮기거나 제거해야 한다고 함
  • 공개 파일 대신 서명된 URL이나 임시 접근 토큰을 쓰는 방식도 권고됨

• 의료정보 취급 쪽에서는 HIPAA 대응 가능한 클라우드 구성이 핵심으로 언급됨

  • 보호 대상 의료정보(PHI)를 공개 서버에 저장하지 말라는 게 첫 번째 원칙임
  • HIPAA 적격 클라우드 스토리지와 사업자 계약(BAA)을 갖춘 구성을 써야 한다고 함
  • 저장 중 암호화와 전송 중 암호화를 모두 적용하고, AES-256 같은 강한 암호화를 권고함

• 한국 개발자에게도 그대로 들어맞는 사고임

  • 의료가 아니어도 주민번호, 결제 정보, 상담 첨부파일, 계약서가 공개 버킷이나 공개 디렉터리에 올라가면 구조는 똑같음
  • “누가 봐도 기본 설정 실수”처럼 보여도, 유출 규모가 133GB면 사고 대응은 전혀 가볍지 않음

---

기술 맥락

• 이 사고에서 핵심 선택지는 민감 파일을 공개 웹서버에 둘 것인지, 접근 제어가 있는 스토리지로 분리할 것인지예요. 공개 디렉터리에 파일을 두면 운영은 쉬워 보이지만, 인증이 빠지는 순간 검색 가능한 유출 경로가 돼요.

• Signed URL이나 임시 토큰을 쓰라는 권고는 그래서 나와요. 파일 자체는 비공개 스토리지에 두고, 필요한 사용자에게만 짧은 시간 동안 접근 권한을 주면 노출 범위를 훨씬 줄일 수 있거든요.

• AWS가 6일 만에 완화 조치를 했다는 대목도 중요해요. 클라우드 사업자가 인프라 레벨에서 막을 수는 있지만, 환자 통지나 규제 대응은 서비스 운영 주체가 해야 해요. 기술 조치와 사고 대응 책임은 같은 게 아니에요.

• 의료정보는 암호화만으로 끝나지 않아요. 누가 접근했는지 로그를 남기고, 최소 권한을 적용하고, 정기적으로 설정을 점검해야 해요. 이런 기본 운영 체계가 없으면 다음 사고도 비슷한 모양으로 반복돼요.