공개 S3 버킷으로 86,000개 이상 의료 기록·PII가 노출된 ‘간호사 우버’ ESHYFT 사건

 (websiteplanet.com)
1P by GN⁺ | ★ favorite | 댓글 1개
  • 뉴저지 기반 HealthTech 회사 ESHYFT 관련 공개 데이터베이스에서 86,341개 기록과 108.8GB 데이터가 노출됐고, 이 플랫폼은 29개 주에서 의료 시설과 간호 인력을 연결함
  • 노출 자료에는 프로필·얼굴 이미지, 월별 근무 일정 CSV, 전문 자격증, 근무 배정 계약서, 이력서와 추가 PII가 포함됨
  • 일부 파일은 결근이나 병가 사유 증빙으로 앱에 올라간 의료 문서로 보이며, 진단·처방·치료 정보가 포함돼 HIPAA 규제 대상이 될 가능성이 있음
  • 연구자의 책임 있는 공개 통지 뒤 데이터베이스 접근은 한 달 이상 지나 제한됐지만, 관리 주체·노출 기간·제3자 접근 여부는 확인되지 않음
  • 의료 인력 플랫폼은 민감 데이터 암호화, 정기 보안 감사, 최소 보관·익명화, 민감도별 분리 저장, MFA, 침해 대응 계획과 신고 채널을 갖춰야 함

ESHYFT 공개 데이터베이스에서 확인된 노출

  • 사이버보안 연구자 Jeremiah Fowler가 비밀번호 보호나 암호화가 없는 데이터베이스를 발견해 Website Planet에 공유함
  • 데이터베이스에는 ESHYFT에 속한 것으로 보이는 86,341개 기록이 있었고, 전체 크기는 108.8GB였음
  • 데이터베이스 이름과 내부 문서는 해당 기록이 ESHYFT 소유임을 가리켰으며, 대부분의 문서는 “App” 폴더 안에 있었음
  • ESHYFT는 뉴저지 기반 HealthTech 회사로, 의료 시설과 의료 인력을 연결하는 모바일 앱 플랫폼을 운영함
    • 대상 인력에는 Certified Nursing Assistants(CNAs), Licensed Practical Nurses(LPNs), Registered Nurses(RNs)가 포함됨
    • 앱은 Apple App Store와 Google Play Store에서 제공됨
    • Google Play Store 기준 다운로드 수는 50,000회를 넘음
    • Apple은 더 이상 사용자 통계를 제공하지 않음

노출된 파일과 의료 정보의 민감도

  • 제한적 샘플 확인에서 여러 유형의 파일이 발견됨
    • 사용자 프로필 또는 얼굴 이미지
    • 월별 근무 일정 로그가 담긴 .csv 파일
    • 전문 자격증
    • 근무 배정 계약서
    • CV와 이력서, 추가 개인 식별 정보(PII)
  • 단일 스프레드시트 문서 하나에는 800,000개 이상 항목이 들어 있었음
    • 간호사 내부 ID
    • 시설명
    • 교대 근무 시간과 날짜
    • 근무 시간 등
  • 앱에 업로드된 것으로 보이는 의료 문서도 확인됨
    • 개별 간호사가 근무를 놓치거나 병가를 낸 이유를 증빙하기 위한 파일일 가능성이 있음
    • 의료 보고서에는 진단, 처방, 치료 정보가 포함돼 있었음
    • 해당 정보는 HIPAA 규제 범위에 들어갈 가능성이 있음

통지 이후 조치와 남은 불확실성

  • 연구자는 ESHYFT에 책임 있는 공개 통지를 즉시 보냄
  • 데이터베이스는 한 달 이상 지난 뒤 공개 접근이 제한됨
  • ESHYFT 측 응답은 “Thank you! we’re actively looking into this and working on a solution”이었음
  • 아직 확인되지 않은 사항이 남아 있음
    • 데이터베이스를 ESHYFT가 직접 소유·관리했는지, 제3자 계약자가 관리했는지
    • 연구자가 발견하기 전 얼마나 오래 노출돼 있었는지
    • 다른 사람이 접근했는지
  • 추가 접근이나 의심스러운 활동 여부는 내부 포렌식 감사로만 식별할 수 있음

의료 인력 플랫폼이 커질수록 커지는 보안 부담

  • ESHYFT는 간호사가 자신의 일정에 맞는 근무를 선택할 수 있게 하고, 의료 시설에는 검증된 W-2 간호 인력 접근을 제공한다고 내세움
  • 플랫폼은 미국 29개 주에서 제공됨
    • AL, AZ, AR, CA, CT, DE, FL, GA, IL, IN, IA, KS, KY, MD, MI, MN, MO, NE, NJ, OH, PA, RI, SC, TN, VT, VA, WA, WI, WV
  • Health Resources & Services Administration(NCHWA) 보고서는 2027년까지 미국 전역에서 등록 간호사 부족률이 10%에 이를 것으로 전망함
  • 의료 인력 수요가 커지면서 ESHYFT 같은 플랫폼은 인력 부족을 메우는 역할을 함
  • 오프라인 업무를 수행하는 간호 인력도 온라인 기술과 통합되면서, HealthTech 회사에는 더 강한 개인정보 보호 장치가 필요해짐
  • 병원과 의료 종사자가 데이터 저장, 진료 관리, 고용에 기술을 더 많이 의존할수록 업계 전반의 사이버보안 부담도 커짐
  • 병원은 중요 인프라로 간주되며, 최근 몇 년 동안 여러 네트워크가 심각한 랜섬웨어 공격을 받음

잠재 위험과 필요한 보안 조치

  • 간호 전문 인력의 개인 식별 정보, 급여 정보, 근무 이력이 노출되면 개인과 고용 의료 시설 모두에 위험이 생길 수 있음
  • 운전면허증이나 Social Security 카드 같은 신분증 스캔본이 주소·연락처 정보와 결합되면 신원 도용이나 금융 사기에 악용될 가능성이 있음
  • 개인·전문 정보 노출은 실제 정보를 활용한 표적 피싱으로 이어질 수 있음
    • 고용 사기로 피해자를 속이거나 추가 개인·금융 정보를 공개하게 만들 수 있음
    • 다만 ESHYFT 데이터나 사용자 데이터가 사기 또는 부정 행위에 실제로 악용됐다는 뜻은 아님
  • HealthTech 회사와 의료 소프트웨어 제공자는 다음 조치를 고려해야 함
    • 민감 데이터에 대한 필수 암호화 프로토콜
    • 내부 인프라 취약점 식별을 위한 정기 보안 감사
    • 민감 데이터 저장 제한과 가능한 경우 익명화
    • 더 이상 사용하지 않는 데이터에 만료일 지정
    • 문서 민감도에 따른 분리 저장
  • 이 사례에서는 사용자 파일이 민감도 기준으로 분리되지 않고 단일 폴더에 업로드된 것으로 보임
    • 사용자 프로필 이미지는 낮은 민감도일 수 있음
    • 의료 검사 증빙은 높은 민감도일 수 있음
    • 두 문서는 이론적으로 같은 폴더에 저장되지 않아야 함
  • 민감 데이터 분리와 암호화는 우발적 노출이나 악의적 공격이 발생했을 때 추가 보호 계층을 제공함
  • 민감 정보나 문서에 접근할 수 있는 애플리케이션에는 MFA가 필요함
    • 사용자명과 비밀번호 같은 자격 증명이 노출되더라도 애플리케이션이나 사용자 대시보드에 바로 접근하기 어렵게 만듦
  • HealthTech 회사는 데이터 침해 대응 계획과 잠재 보안 사고 신고용 전용 커뮤니케이션 채널을 갖춰야 함
    • 고객 지원이나 영업 연락처만 두면 데이터 침해 시 조치해야 할 핵심 담당자에게 전달이 늦어질 수 있음
    • 민감 데이터가 공개 노출되면 완화와 복구 지연이 치명적일 수 있음
  • 데이터 사고 뒤에는 직접 영향을 받을 수 있는 사용자에게 적시에 책임 있는 공개 통지를 제공해야 함
  • 사용자는 해당 애플리케이션이나 서비스와 관련된 피싱 시도를 알아보는 방법을 안내받아야 함
  • Shiftster LLC dba ESHYFT, 계약자, 계열사의 위법 행위가 있었다는 의미는 아니며, 내부 데이터나 사용자 데이터가 임박한 위험에 있었다는 주장도 아님

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 이 회사는 일감을 제안하기 전에 신용 보고서로 빚이 얼마나 있는지, 즉 얼마나 절박한지 판단한 뒤 그 정보를 이용해 제시 시급을 내림 조정한다는 얘기를 최근 들었음
    이 유출로 어떤 불이익이 생긴다면, 그 이상으로 받아도 마땅해 보임

    • 출처는 기억 안 나지만, “간호사용 Uber” 같은 서비스를 다룬 팟캐스트를 들은 적이 있고, 간호사에게 불리한 온갖 짓을 한다고 했음
      호출을 받으면 위치 추적 앱을 켜야 하고, 교통 체증에 걸리거나 휴대폰 신호가 끊겨도 벌점이 쌓이며, 벌점이 임금 하락으로 이어지는 식이었음
      이미 환자는 너무 많고 보조 인력은 부족하며 12시간 근무 뒤에도 기록을 해야 하는 열악한 간호 환경을 무기화하는 셈임. 아내가 간호사라서 더 현실적으로 느껴짐
    • 간호사 임금 억제를 다룬 발표는 여기임: https://pluralistic.net/2025/02/26/ursula-franklin/
    • 간호사 부족이 심각한데 왜 간호사들이 이런 서비스를 쓰는지 궁금함
      특히 숙련 간호사라면 임금을 후려치는 형편없는 앱을 쓸 이유가 없고, 어떤 의료기관이든 거의 바로 채용될 수 있어야 하며, RN이라면 원격의료 선택지도 넓어 보임
    • 간호사 임금을 추정하는 방식으로는 형편없어 보임
      배우자가 있을 수 있고, 부모가 신용카드 대금을 내줄 수도 있고, 신용이 나쁜 사람이 별로 신경 안 쓸 수도 있으며, 집안 돈이 있을 수도 있음
      빚이 적어도 일자리가 절박할 수 있는데, 이게 실제로 작동하긴 하는지 의문임

  • 개인정보 처리방침의 Data Security 섹션에는 수집·보관 정보의 무결성과 보안을 높이기 위한 물리적·관리적·기술적 보호조치를 쓰지만, 완벽하거나 침투 불가능한 보안은 없고 유출·열람·공개·변조·파괴를 보장하지 않는다고 되어 있음
    특히 이 서비스는 HIPAA상 보호대상 건강정보를 저장하거나 보호하도록 설계되지 않았다고 밝히는데, “HIPAA 준수 시스템으로 만들지 않았으니 죄송”이라는 말로 책임이 사라질 수 있는지는 모르겠음
    0: https://eshyft.com/wp-content/uploads/2019/06/ESHYFT-Privacy...

    • HIPAA는 의료 제공자 데이터가 아니라 환자 데이터에 적용됨
      기사에는 간호사들이 결근이나 병가 사유를 증명하려고 진단·처방·치료 정보가 담긴 의료 문서를 앱에 올린 것으로 보이고, 이게 보호대상 건강정보에 해당할 수 있다고 되어 있음
      이 회사가 HIPAA 적용 대상인지는 covered entity나 business associate인지에 달렸고, 개인정보 처리방침을 보면 Business Associate Agreement를 맺었을 가능성은 낮아 보임
      덧붙이면 HIPAA 자체도 보안 표준으로 이상적이지는 않아서, 큰 회사들이 Gmail이 HIPAA 준수라는 이유로 대량 보호대상 건강정보를 주고받기도 함
      0: https://www.hhs.gov/hipaa/for-professionals/covered-entities...
    • HIPAA는 covered entity라는 특정 주체에만 적용됨
      대략 보험을 받는 의료 제공자나 보험사가 해당하고, 보험을 받지 않는 의료 제공자는 HIPAA를 따르지 않아도 됨
      여기서는 ESHYFT가 노동력을 제공하는 업체일 뿐이라 HIPAA와 직접 관련이 없어 보이고, 인력 보강 서비스를 제공하는 대형 컨설팅 업체와 크게 다르지 않음
    • HIPAA는 허접한 약관에 좌우되지 않고, 적용되거나 적용되지 않을 뿐임
      다만 기대보다 범위가 좁고 처벌도 약함. Facebook이 추적 픽셀 같은 걸 설치하게 해서 개인 의료 데이터를 빼가도, 법 위반이 아닐 가능성이 높고 유출을 만든 쪽에나 청구할 수 있을 것 같음
      이 건도 HIPAA로 손해를 제한하기는 쉽지 않아 보임. 의사가 환자 데이터를 Google Drive에 올렸다가 Google 하청업체나 해킹으로 새어 나간 경우에 더 가까움
      ESHYFT 서비스에는 HIPAA가 보호하는 데이터가 필요하지도, 도움이 되지도 않으므로 HIPAA 위반으로 쉽게 이기기는 어려워 보이지만, 다른 손해배상 책임은 여전히 가능함
    • 직접 의료 제공자가 아니라면 그런 면책 주장이 통할 수도 있음. 그렇다고 지지하는 건 아님

  • 의료인이 가진 권위 때문에 헷갈리기 쉬운데, 의사나 병원에 사회보장번호를 절대 주지 않는 편이 좋음
    그들에게 필요하지 않음. 신분증 확인도 스캔이나 촬영을 뜻하지 않음
    의사·병원·진료소는 정보보안이 최악인 축이고, 교육도 거의 없고 잘못해도 처벌이 약하며, 그런 정보는 결국 청구서를 안 냈을 때 추적하려는 용도에 가깝음

    • 미국에서는 HIPAA가 사실상 가장 강한 개인정보 보호 법제라서, 의료 제공자만큼 정보 유출 시 큰 처벌을 받을 집단도 드물어 보임
    • 사회보장번호 없이는 예약을 잡아주지 않겠다고 하면 어떻게 해야 하는지 궁금함

  • S3 버킷이 얼마나 오래된 건지 궁금함. 어느 시점부터 AWS는 새 S3 버킷을 기본 비공개로 만들었음
    그렇다면 오래된 버킷이거나, 모바일 앱·서비스에서 파일 업로드/다운로드가 안 돼서 무모하게 공개로 열어둔 것일 가능성이 큼

    • 웹 개발자가 웹사이트에서 자산을 쓰려고 열어뒀고, 같은 버킷 안의 다른 민감 데이터를 생각하지 못했을 수도 있음

  • 제목에 실제 회사명 대신 왜 “간호사용 Uber”라고 썼는지 의문임

    • 기사에 따르면 이름은 ESHYFT임. AliExpress에서 볼 법한 전자제품 브랜드처럼 들리는데 품질은 더 낮아 보임
    • 회사명만으로는 알 수 없는 방식으로, 이 회사가 엉터리라는 걸 바로 알려줌

  • 지난주에는 Firebase를 탓하더니 이번에는 AWS를 탓할 건가 싶음
    새벽 3시에 친구들한테 보여줄 걸 대충 만들 때의 보안 절차가 개인식별정보를 호스팅하는 제품에 그대로 적용돼서는 안 됨. 기본 데이터 보안은 운영자가 직접 구현해야 함

    • 기본 데이터 보안을 구현해야 하는 건 맞지만, 플랫폼도 가능한 한 도와야 함
      개발자가 기본값만 따라가도 안전한 성공의 함정으로 빠지게 해야 함
      이 경우 S3 버킷은 기본적으로 비공개·암호화되어야 하고, 개발자가 명시적으로 꺼야 하는 구조여야 함. 지금은 그럴 수 있지만 과거에는 아니었음

  • 의료 산업은 처음부터 끝까지 망가져 있고, 그 주변 기술 회사들까지 무능해 보임
    값싼 기업 소유 병원이 간호사를 W2 직원으로 채용하지 않으려 하니 간호 업무가 Uber화되고, 병원의 인색함이 이런 형편없는 앱 선택으로 이어졌을 가능성이 큼
    승인한 관리자에게 리베이트가 갔을지도 모르고, ESHYFT는 이 일로 파산해야 맞지만 실제로는 아무 일도 안 일어날 가능성이 더 커 보임

    • 파산만으로는 부족하고 형사상 과실도 물어야 함
      임원이 감옥에 가지 않는 한 이런 일은 계속될 것임. 누군가는 정보보안에 투자하지 않고 이 사업으로 큰돈을 벌었을 가능성이 높음
      비용을 아낀 대가는 이익과 무관한 사람들이 치렀고, 몇 년 뒤 그 임원들이 성공한 회사 만드는 법을 강연하러 다닐지도 모름
      이런 행동에 아무 결과가 없으면, 공공이 사적 이익의 대가를 계속 치르게 됨
    • 이런 앱은 어느 정도 독립 병원·의료 제공자가 버틸 수 있게 해줌
      대형 의료 시스템은 자체 float 간호사 풀이나 내부 제안 시스템을 갖고 있음
      휴가·공석 대응 체계에 접근할 수 있다는 점이 대형 시스템에 매각될 때의 설득 포인트이기도 함
    • 리베이트 얘기가 특히 궁금함. 그 가능성에는 공감하지만 현실적으로 어떻게 뿌리 뽑을 수 있을지 모르겠음
      잘못을 아는 사람들이 바로 그 혜택을 받는 사람들이라 고칠 유인이 거의 없음

  • 아직도 이런 일에 조치를 취할 수 있는 기능하는 규제기관이 있다고 믿는 척하는 건가 싶음

    • 이런 걸 찾아내려고 가장 열심히 일하던 사람을 곧바로 해고하니, 정부가 더 효율적이 되긴 함

  • 왜 이런 일이 계속 반복되는지 모르겠음. 매달 열린 S3 버킷에서 새 유출이 나오는 느낌임

    • 미성숙한 시스템을 가진 신생 회사, 오래된 회사에서 젊은 개발자가 자기 영역에서 따로 벌이는 부수 작업, 나쁜 기본 설정 등이 원인일 수 있음
      더 중요한 건 대규모로 계속 탐색하는 동기가 강한 사람들이 많다는 점임. 요즘은 GitHub, IP, 도메인 등 인터넷을 훑기가 매우 쉽고, “잘못된 S3 설정” 탐지도 누구나 쓸 수 있는 스크립트 수준이라 고급 프로그래밍 실력이 필요하지 않음
    • S3와 AWS 대부분은 설계가 끔찍해서, 새 프로젝트를 띄울 때 동작할 법한 접근 정책을 검색해서 가져오게 됨
      그 정책이 나중에 운영 환경에 맞지 않을 수 있음. 옳다는 뜻은 아니고, 실제로 그렇게 일이 벌어진다는 뜻임

  • 인프라를 만든 사람이 너무 피곤한 상태로 구축했다가 아침에 이 일을 보고 깼다면 정말 안타까운 일임

답변달기