클라우드
이 태그가 달린 문서 14건
산토리 그룹 개인정보 유출(직원 및 파트너사 직원 약 90,000명, 그 밖의 그룹): 외부 클라우드 서비스 무단 접근으로 이름·이메일 주소 등 유출, 지원자와 고객이 할 일
산토리 그룹은 2026년 11월 2일, 그룹이 이용하는 외부 클라우드 서비스에 대한 제3자의 무단 접근을 확인했으며, 제3자가 내려받은 파일 일부에 개인정보가 포함되어 있었다고 발표했습니다. 10월 28일 이상을 감지해 접근을 차단했고, 10월 29일 개인정보가 포함된 것을 확인했습니다. 11월 1일까지 유출이 확인된 개인정보는 7개 그룹입니다. 그룹 직원과 파트너사 직원 약 90,000명의 이름·이메일 주소, 기업 활동 체험 프로그램 Mar de Shine에 2023년 말 시점 등록된 7,323명의 이메일 주소, 산토리 홀딩스 2026년 신입 채용 비즈니스 부문 오픈 전형 지원자 7,173명의 지원자 마이페이지 등록 정보 등(이름·이메일 주소·전화번호 등), Suntory Beverage Solution의 업무용 휴대전화 2대에 저장된 1,097명의 이름·전화번호, Monte Bussan 직원과 파트너사 직원 324명의 이름·이메일 주소·전화번호, Izutsu Maisen 택배 주문 고객과 배송 직원 96명의 이름·배송지 위치 정보, 산토리 거래처 직원 25명의 이름·직책입니다. 신용카드 등 결제 정보는 포함되지 않았습니다. 발표 시점에 부정 이용은 확인되지 않았습니다. 회사는 대상자에게 개별 연락하고 있다고 밝혔습니다. 이 사이트의 결론: 산토리나 그룹사를 사칭하는 전형·내정·배송·거래 관련 연락의 링크는 열지 말고, 직접 연 공식 사이트나 공지 페이지의 창구에서 확인하세요.
Trigger.dev 보안 사고(2026년 11월): 고객의 0.66%에서 루트 API 키와 환경 변수에 접근, 키를 재생성하고 시크릿을 교체하세요
백그라운드 작업과 AI 에이전트를 실행하는 플랫폼 Trigger.dev는 2026년 11월 1일 보안 사고를 공개하고 11월 6일 후속 보고서를 게시했습니다. 회사는 11월 1일 인프라 경보가 비정상 활동을 포착했고, 악의적인 활동으로 판단해 공격자를 차단했다고 밝혔습니다. 영향을 받은 것은 전체 고객의 0.66%입니다. 공격자는 일부 고객 환경의 루트 API 키를 확보했고, 루트 키는 환경 변수를 포함한 환경 설정 전체에 접근할 수 있습니다. 일부 환경에서는 최근 실행, 배포, 스케줄 목록도 조회했으며, 그 결과로 ID, 작업 이름, 실행 멱등성 키, 실행 상태, 태그, 배포 메타데이터와 오류, 스케줄 외부 ID, 실행 메타데이터가 반환되었습니다. 회사는 그 밖의 고객 데이터, 다른 서비스, 자사 운영 데이터베이스, 고객 대시보드 계정에 접근한 증거는 찾지 못했다고 밝혔습니다. 조사와 고객을 보호하기 위해 공격 경로는 공개하지 않습니다. 영향을 받은 고객에게는 이메일(11월 1일과 2일)과 대시보드 배너(시점은 명시되지 않음)로 연락했고, 영향을 받았을 수 있는 API 키는 폐기했습니다. 영향을 받은 고객은 API 키를 재생성하고, 영향을 받은 환경의 데이터베이스 비밀번호나 서드파티 API 키 같은 자격 증명을 교체하면서 이전 것은 발급처에서 폐기해야 합니다. 회사는 영향 통지를 받지 않은 고객은 영향을 받지 않았고, 웹훅 서명 시크릿은 노출되지 않았으며, 셀프 호스팅 배포는 영향이 없다고 밝혔습니다. 이 사이트의 판단: 먼저 이메일과 대시보드 배너를 확인하고, 영향을 받았다면 회사의 안내대로 키를 재생성하고 자격 증명을 교체하세요.
Chainstack(블록체인 노드·API 플랫폼) 운영 환경 침해: 개발자와 dApp 운영자가 계정 데이터와 노드 자격 증명에 대해 해야 할 일
Chainstack은 2026년 11월 3일자 공지에서 외부 공격자가 제3자 구성 요소를 통해 인프라 일부에 접근했다고 밝혔습니다. 10월 26일에는 개발 환경, 10월 29일에는 운영 환경 일부였고, 10월 31일에 감지해 차단했으며 11월 2일에 조사를 마쳤습니다. 고객 계정 데이터베이스에서 노출되었을 수 있는 정보는 조직 이름, 계정 소유자 이름, 조직 구성원의 이메일 주소, 비밀번호 해시입니다. 노드 자격 증명을 보관하는 시스템에도 접근이 있었으며, 회사는 이를 읽었다는 증거는 없지만 노출된 것으로 취급합니다. 결제 수단 정보는 저장하지 않으며, 노드, 콘솔, API는 변경되지 않았고 서비스는 계속되었다고 합니다. 고객 수는 밝히지 않았습니다. 이 사이트의 결론: 사용자는 비밀번호를 바꾸고, 노드 자격 증명과 플랫폼 API 키를 교체하고, 앱, CI, 프런트엔드에 들어 있는 엔드포인트를 교체해야 합니다.
PingCAP(TiDB Cloud) 무단 접근 및 정보 유출(일본 내 최대 약 5만 건): TiDB Cloud 조직 관리자가 계정 정보, SQL 편집기 기록, 지원 티켓에 대해 해야 할 일
PingCAP는 2026년 9월 9일부터 10월 7일(미국 시간) 사이에 제3자가 탈취한 자격 증명으로 내부 시스템에 들어와 데이터를 복사했고, 일본 내 최대 약 5만 건의 개인 정보가 유출된 것으로 확인되었다고 밝혔습니다(일본어 공지). 회사가 영향을 받은 것으로 확인한 항목(고객에 따라 다름)은 TiDB Cloud 계정 정보(사용자 이름, 이메일 주소, 조직과 프로젝트의 연결 관계, SQL 편집기 실행 기록과 오류, 지원 티켓을 뜻하는 문의 정보), 업무 및 청구 정보(이름, 이메일, 회사명, 전화번호, 주문, 지불 조건, 청구 설정), 그리고 TiDB Cloud API 키의 암호화된 Public Key 부분입니다. 회사는 신용카드 유출이나 TiDB Cloud 자체에 대한 무단 접근은 확인하지 못했고 Private Key는 노출되지 않았다고 밝혔습니다. 이 건수가 사람 수인지 레코드 수인지는 명시되지 않았습니다. 회사의 영어 공지에는 소스 코드가 취득되었다는 내용도 있습니다. 이 사이트의 결론: TiDB Cloud 조직 관리자는 API 키를 교체하고, 접근 로그와 멤버, 역할을 점검하고, SQL 편집기나 지원 티켓에 붙여 넣었을 수 있는 자격 증명을 변경하세요.
구인 사이트 MyBRANDS 부정 접근과 개인정보 유출 가능성(최대 약 13만 5천 계정): 이름, 연락처, 경력 정보가 걸린 구직자와 기업 담당자가 해야 할 일
일본의 iDA 주식회사는 2026년 10월 30일, 자사가 운영하는 구인 사이트 MyBRANDS의 서버 환경에 제3자가 부정 접근해 등록된 구직자와 기업 담당자의 정보가 외부로 유출됐을 가능성이 있다고 발표했다. 회사에 따르면 위탁업체가 사용하던 클라우드 접근 키가 10월 21일부터 22일 사이에 제3자에게 악용되었고, 10월 26일 데이터베이스 사본에서 데이터가 외부로 전송된 기록이 있음을 알게 되었다. 전송된 데이터의 내용은 확인할 수 없어, 회사가 보유한 모든 정보가 대상이라는 전제로 알리고 있다. 범위는 10월 30일 기준 탈퇴한 사람을 포함해 최대 약 13만 5천 계정이다. 정보는 이름, 이메일 주소, 전화번호, 프로필(경력 등), 로그인 비밀번호(변환된 값으로 보관)이며 등록 내용에 따라 다르다. 신용카드와 은행 계좌 정보는 보유하지 않아 포함되지 않았다. 이름, 이메일 주소, 전화번호, 주소는 암호화해 보관했으나 복호화 키도 함께 탈취됐을 가능성이 있다고 한다. 지금까지 악용(2차 피해)은 확인되지 않았다. 이 사이트의 결론: MyBRANDS와 같은 비밀번호를 쓰는 다른 서비스(기업 담당자는 사내 시스템도)의 비밀번호를 바꾸고, 채용 담당자나 스카우트를 자칭하는 연락은 메시지 속 링크나 번호가 아닌 공식 경로로 확인하라.
Northflank 보안 사고(2026년 10월): 저장된 환경 변수가 복호화된 것으로 간주, AI API 키 부정 사용 보고
2026년 10월 30일(UTC), 클라우드 배포 플랫폼 Northflank는 상태 페이지에 보안 사고를 게시했습니다. 보안 업체의 위협 경보가 11:43 UTC에 들어왔고, 회사는 12:02 UTC부터 패치를 배포했으며, 13:40 UTC에 고객에게 환경 변수를 교체하라고 안내했고, 13:58 UTC에는 모든 환경 변수가 복호화된 것으로 가정하라고 안내했습니다. 15:12 UTC에 이미 여러 이용자가 자신의 AI 키가 사용되었다고 보고하고 있다고 상태 페이지에 적었고, 23:38 UTC에는 플랫폼에 저장된 AI API 키가 무단 사용되었다는 이용자 보고가 있다고 밝혔습니다. 10월 31일에는 모든 고객에게 감사 로그를 활성화하고, 애드온의 시크릿 교체 기능을 유형별로 하나씩 공개했습니다. 11월 2일 업데이트(11:09 UTC, 상태 Monitoring)에서 회사는 첫 경보로부터 1시간 안에 공격을 차단했다고 보고 있으며, 실행 중인 워크로드는 영향을 받지 않았고 워크로드나 그 데이터에 접근한 흔적은 보지 못했으며, 공격은 컨트롤 플레인의 시크릿에 집중된 것으로 보인다고 밝혔습니다. 독립된 포렌식 감사인이 검토 중이며, 회사는 액세스 토큰, 세션, VCS 연동, 계정 간 IAM 역할을 폐기했고(그래서 이용자는 다시 로그인하고 연동을 다시 연결해야 합니다), 조사 결과가 확인되면 근본 원인 분석을 공개하겠다고 약속했습니다. 11월 6일 업데이트(10:09 UTC)에서 회사는 시크릿이 처음으로 복호화된 것으로 파악되는 시점이 첫 경보(11:43 UTC)보다 앞선 10월 30일 02:39–03:08 UTC라고 밝혔고, 익스플로잇은 통보를 받고 60분 안에 패치했으며 고객에게는 2시간 안에 알렸고, 고객 워크로드나 그 데이터에 접근한 증거는 찾지 못했으며, 가능한 범위에서 상위 업체와 협력해 자격 증명을 폐기했다고 밝혔습니다. 포렌식 검토는 계속되고 있습니다. 영향을 받은 고객 수, 공격자의 침입 경로, 관련된 AI 업체는 공개되지 않았습니다. 이 사이트의 판단: Northflank에 저장한 모든 시크릿을 발급한 서비스에서 폐기하고, 각 AI 업체의 사용량과 청구를 살펴보고, 지출 한도를 설정하세요.
Zeabur 보안 사고(2026년 10월, 환경 변수 322만 건 열람): 교체할 시크릿과 이용자가 해야 할 일
2026년 10월 19일, 앱 배포 플랫폼 Zeabur는 10월 14–15일(UTC)의 보안 사고에 관한 예비 보고서를 공개했습니다. 회사에 따르면 공격자는 유출된 Zeabur 내부 자격 증명으로 공유 클러스터, 일부 전용 서버(Dedicated Servers), 내부 시스템에 들어간 뒤, 10월 15일 16:10부터 16:47 UTC 사이에 플랫폼 데이터베이스를 열람했습니다. 회사는 환경 변수 3,218,965건(이름과 값)과 321,810개 계정의 데이터(이메일, 사용자 이름, 전화번호 등), 그리고 566개의 zSend API 키가 열람된 것을 확인했으며, zSend API 키는 폐기했습니다. 회사는 근본 원인이 Zeabur에 있다고 밝혔습니다. 장기간 유효한 관리자 자격 증명이 평문으로 저장되어 있었고 공용 인터넷에서 사용할 수 있었다는 것입니다. 회사는 8월의 별도 사고 뒤 이미 교체했더라도 Zeabur에 저장한 모든 비밀번호와 키를 교체하라고 모든 이용자에게 요청하고 있습니다. Zeabur는 10월 17일 2026년 12월 31일에 서비스를 종료한다고 발표했고, 10월 22일에는 사고로 인한 손해 청구 기한을 2026년 11월 30일로 정했습니다. 이 사이트의 견해: Zeabur 환경 변수에 넣은 적이 있는 모든 시크릿을 다른 누군가가 알고 있다고 보고, 먼저 발급한 서비스에서 폐기한 뒤 10월 14일 이후의 청구서와 로그를 확인하세요.
닛케이 부정 접속(약 183만 건): 이름·이메일 주소 등 약 15만 건 유출 — 이용자가 해야 할 일
일본 신문사 Nikkei Inc.는 2026년 10월 16일, 시스템 개발에 사용하는 클라우드 서비스에 부정 접속이 있었으며 16일 시점에 개인정보 약 183만 건이 유출됐다고 발표했습니다. 약 15만 건에는 이름, 이메일 주소, 우편 주소, 전화번호, 생년월일 중 하나 이상이 포함돼 있었고, 그중 약 12만 건에는 이메일 주소가 포함돼 있었습니다. 나머지 약 168만 건은 그것만으로는 개인을 식별할 수 없는 식별자뿐이었습니다. 신용카드 정보는 포함되지 않았습니다. 회사에 따르면 클라우드 서비스에 접속하기 위한 인증 정보가 어떤 방법으로 탈취됐고, 부정 접속은 10월 7일 새벽부터 아침 사이에 이뤄졌습니다. 회사는 사용된 인증 정보를 무효화했고 10월 11일 일본 개인정보보호위원회에 보고했습니다. 16일 시점에 정보 악용 등 2차 피해, 시스템 장애나 데이터 변조는 확인되지 않았습니다. 회사는 유출이 확인된 사람에게 개별적으로 알리겠다고 밝혔습니다. 그룹사 Nikkei National Geographic은 10월 22일, 자사 서비스 일부 이용자의 정보가 포함돼 있었다고 밝혔습니다. 어떤 서비스의 이용자가 해당되는지, 항목별 건수, 인증 정보가 탈취된 경위는 공개되지 않았습니다. 이 사이트의 견해: 닛케이를 사칭하는 이메일이나 전화의 링크와 전화번호는 사용하지 말고 공식 사이트에서 확인하세요.
Railway 환경 변수 노출 가능성 (2026년 10월, 최대 1.85% 워크스페이스): 교체해야 할 시크릿과 사용자 조치
Railway는 2026년 10월 21일(UTC), 고객 환경 변수를 저장하는 시스템에서 이상 활동을 탐지했으며 권한 없는 제3자가 암호화된 환경 변수에 접근하고 그중 일부는 복호화된 내용을 확보했을 수 있다고 발표했습니다. 10월 22일자 예비 보고서(상태 페이지 기준 10월 23일 16:38 UTC 공개)에 따르면 공격은 10월 20일 13:58 UTC부터 10월 22일 03:32 UTC까지 이어졌습니다. 공격은 빌드 인프라에 대한 권한 상승 시도로 시작되었고, 10월 21일에 CI 환경 자격 증명이 사용되어 암호화된 환경 변수 일부가 복호화되었습니다. 전체 워크스페이스의 최대 1.85%(회사에 따르면 약 100,000개 워크스페이스)에서 일부 환경 변수가 유출되었을 가능성이 있습니다. 회사는 Railway 사용자 계정에는 접근이 없었다고 밝혔으며, 소스 코드 접근 가능성은 최종 보고서 전까지 배제하지 않았습니다. 공격자는 AI 제공업체 API 키를 노린 것으로 보입니다. Railway는 모든 사용자에게 10월 21일 이전에 저장한 시크릿을 교체하고, 데이터베이스의 공개 네트워크 접근을 제거하며, GitHub와 레지스트리(Docker Hub 등)의 감사 로그를 확인할 것을 권고합니다. 이 사이트의 결론: 연락을 받지 않았더라도 Railway에 저장한 시크릿은 노출된 것으로 간주하고, 원본에서 재발급한 뒤 재배포하고 나서 이전 값을 폐기하십시오.
섀도 AI란? 회사가 파악하지 못한 AI 사용의 위험과, 조직·개인이 할 일
섀도 AI는 회사가 승인하지 않았거나 관리하지 않는 AI 도구(챗봇, AI 브라우저 확장, 코딩 어시스턴트, 회의록 AI, 업무 계정에 연결된 AI 에이전트)를 직원이 업무에 쓰는 것이다. 섀도 IT의 AI판이다. 주된 위험: 입력한 기밀·개인정보가 제공자에게 저장되고, 플랜과 설정에 따라 학습에 쓰일 수 있다(개인용과 업무용 약관이 다르다). OAuth 허가와 API 키가 외부 도구에 메일·드라이브 접근을 넘긴다. 출력의 오류와 라이선스 문제. 개인정보 관련 법과 감사 의무. 금지만 하면 사용이 보이지 않는 곳으로 숨으므로, 입력을 학습하지 않는 업무용 약관의 승인 도구, 입력해도 되는 데이터에 대한 짧은 규칙, SSO와 관리 기능, OAuth 허가와 확장 기능의 정기 점검, 먼저 물어볼 수 있는 창구를 마련한다.
Vercel 보안 사고 (2026년 4월): 환경 변수가 노출됐을 때 개발자가 할 일
2026년 4월 19일 Vercel은 일부 내부 시스템에 대한 무단 접근을 공개했다. Vercel에 따르면 직원이 쓰던 서드파티 AI 도구가 침해되면서 공격자가 그 직원의 Google Workspace 계정을 탈취했고, 그 직원의 Vercel 계정과 Vercel 환경에 들어가, 일부 제한된 고객의 '민감'으로 표시되지 않은 환경 변수를 열거하고 복호화했다. Vercel은 영향받은 고객에게 직접 연락했고, 자사가 배포한 npm 패키지는 침해되지 않았음을 확인했다. 이 사이트의 결론 = 변수의 유출 여부는 그 분류, 즉 읽기 가능(저장 후 값을 다시 표시할 수 있음)인지 쓰기 전용(덮어쓸 수는 있지만 표시할 수 없음)인지에 달려 있었다. 다시 읽을 일이 없는 비밀값은 모두 쓰기 전용(현재 Vercel의 Secret)으로 저장하고, 직원이 OAuth(외부 앱이 회사 계정에 접근하도록 허용하는 방식)로 회사 계정에 연결하는 AI 도구도 의존성처럼 목록으로 관리한다.
서브도메인 탈취(dangling DNS): 남겨진 DNS 레코드로 공격자가 내 도메인을 쓰는 구조
DNS 레코드를 지우지 않고 클라우드 리소스만 삭제하면 '매달린(dangling)' 항목이 남습니다. 누구든 같은 FQDN으로 리소스를 만들면 그 서브도메인을 차지할 수 있습니다. 내 서버는 건드려지지 않은 채, 정상 서브도메인이 공격자의 콘텐츠를 내보냅니다. 피해는 겉모습에 그치지 않습니다. 앱은 흔히 세션 쿠키를 와일드카드 서브도메인에 공개하므로, 탈취된 서브도메인이 그것을 읽을 수 있습니다. 그리고 문서는 인증서가 지켜 준다는 믿음을 명시적으로 부정합니다. 해결책은 삭제 순서를 기억에 맡기지 않고 절차와 도구에 넣는 것입니다.
SSRF(Server-Side Request Forgery)란
SSRF는 외부 입력 URL을 악용해 서버가 내부 자원(내부 IP, 클라우드 메타데이터)에 접근하게 만듭니다. URL을 가져오는 기능이 있다면, 목적지 허용 목록, 내부 대상 차단, 그리고 리디렉션/DNS 리바인딩 우회에 대한 대책이 필요합니다. Capital One 침해의 원인이었습니다.
Capital One 데이터 유출 사고(2019) — 단 하나의 SSRF가 1억 건이 넘는 기록을 유출시킨 경위와 방어법
단 하나의 SSRF가 메타데이터 엔드포인트에 도달 → 과도한 권한의 IAM 임시 자격 증명 → S3 일괄 복사로 약 1억 600만 건이 유출되었습니다. 어느 단계에서든 막을 수 있었습니다. 여러분의 환경에서는 IMDSv2, IAM 최소 권한, 그리고 아웃바운드 조회에 대한 허용 목록이 핵심입니다.