센터포인트 에너지 해킹, 인증·방화벽 없는 API 하나로 고객정보 749만 건 유출됐다

[핵심요약] 휴스턴 소재 미국 대형 에너지 기업 센터포인트 에너지가 인증·속도제한 없는 외부 API 하나 때문에 고객 749만 명의 이름, 주소, 계좌번호, 사회보장번호 일부까지 유출되는 사고를 겪었어요.

미국 텍사스·인디애나·미네소타·오하이오 4개 주에서 약 700만 가구에 전기·가스를 공급하는 센터포인트 에너지가 2026년 9월 14일, 미국 증권거래위원회(SEC)에 대규모 개인정보 유출 사실을 공식 신고했어요. 해커는 온라인 포럼에 749만 건의 고객 데이터를 확보했다고 직접 게시글을 올렸고, 여기에는 이름, 전화번호, 서비스·청구 주소, 계좌번호, 청구 금액, 자동이체 여부, 이메일, 운전면허번호, 사회보장번호 뒷 4자리까지 담겨 있었어요. 해커의 닉네임은 '4d722e4d656f77'였고, 원래 확보한 원본 데이터는 1,744만 건에 달했지만 CAPTCHA에 막혀 다운로드가 중단됐다고 주장했어요. 회사 측은 전기·가스 공급 서비스에는 영향이 없다고 밝혔지만, 이미 여러 주에서 집단소송이 제기된 상태예요.

무슨 일이 있었나?

해커는 센터포인트 에너지가 운영하는 외부 노출 API 하나를 표적으로 삼았어요. 이 API에는 웹 애플리케이션 방화벽(WAF)도, 요청 속도 제한(rate limiting)도, 인증서 검증도, 심지어 접근을 위한 인증 토큰도 걸려 있지 않았다고 해커 스스로 주장했어요. 사실상 URL만 알면 누구나 데이터를 끌어올 수 있는 구조였던 셈이에요. 해커는 이 API를 JSONL 형식으로 대량 호출해 데이터를 내려받은 뒤, 이를 다시 CSV 파일로 변환해 정리했다고 설명했어요. 이 과정이 얼마 동안 이어졌는지, 언제 처음 시작됐는지는 센터포인트 측이 아직 구체적으로 밝히지 않고 있어요. 회사는 위협 행위자의 게시물을 통해서야 사고를 인지했고, 그제서야 외부 보안 전문가를 투입해 조사에 들어갔어요. 즉 공격자가 시스템에 침투해서 뭔가를 훔친 게 아니라, 애초에 잠겨 있지 않던 문(API)으로 걸어 들어가 데이터를 퍼간 구조에 가까워요.

왜 중요한가? 무엇이 위험한가?

이 사고가 유독 뼈아픈 이유는 '해킹'이라고 부르기도 민망할 만큼 낮은 기술 장벽 때문이에요. 랜섬웨어처럼 악성코드를 심거나 취약점을 정교하게 파고들 필요도 없이, 기본적인 API 보안 설정 몇 가지가 빠져 있었다는 것만으로 700만 명 넘는 고객의 개인정보가 통째로 빠져나갔어요. 더구나 유출 항목에 사회보장번호(한국의 주민등록번호에 해당) 뒷자리와 운전면허번호, 계좌 관련 정보까지 섞여 있어서, 단순 스팸을 넘어 명의도용·피싱·계정탈취로 바로 이어질 수 있는 조합이에요. 최근 보안 업계에서는 공격자들이 사람이 일일이 API 엔드포인트를 뒤지는 대신 자동화 스캐너와 생성형 AI 도구로 인증 누락·설정 오류가 있는 API를 대량으로 빠르게 찾아내는 사례가 늘고 있다고 지적해요. 이번처럼 방화벽·인증·속도 제한이 모두 빠진 API는 이런 자동 스캔에 가장 먼저 걸리는 표적이라, 앞으로 유사한 사고가 더 늘어날 가능성이 커요.

우리 회사도 대비하려면?

이번 사고는 미국 에너지 기업 사례지만, 외부와 데이터를 주고받는 API를 운영하는 국내 기업이라면 남 일이 아니에요. 특히 자체 앱·홈페이지·파트너사 연동을 위해 API를 열어둔 제조업·중견기업일수록, 처음 만들어질 때는 보안 검토를 거쳤어도 이후 기능이 추가되거나 담당자가 바뀌면서 인증·속도 제한 설정이 슬그머니 빠지거나 느슨해지는 경우가 많아요.

가장 기본적인 원칙은 모든 외부 노출 API에 인증 토큰과 속도 제한을 예외 없이 적용하는 거예요. '내부용이라 괜찮겠지'라는 판단으로 임시로 열어둔 API가 시간이 지나면서 존재 자체를 잊혀지는 경우가 실제로 많이 발생해요.

또한 API가 얼마나 많은 데이터를, 어떤 패턴으로 반환하고 있는지 정기적으로 로그를 점검해야 해요. 정상적인 서비스 트래픽이라면 나오지 않을 대량 순차 조회(예: 계정번호를 1부터 순서대로 스캔하는 패턴)가 보이면 그 자체가 침해의 신호예요.

마지막으로 개인정보를 다루는 API는 응답값에 불필요한 항목(주민등록번호, 계좌번호 등)을 애초에 포함시키지 않는 '최소 수집 원칙'을 지켜야, API 하나가 뚫려도 피해 범위를 줄일 수 있어요.

• 외부에 공개된 API 목록을 전체 인벤토리로 관리하고 있나요? (담당자도 모르는 '잊혀진 API'가 없는지 확인해보세요)
• 모든 API 엔드포인트에 인증 토큰과 속도 제한(rate limiting)이 예외 없이 걸려 있나요?
• API 응답 로그에서 짧은 시간에 대량 순차 조회가 발생한 흔적이 있는지 확인해보셨나요?
• API가 반환하는 값에 사회보장번호·계좌번호처럼 민감한 항목이 불필요하게 포함돼 있지 않나요?
• 고객 데이터를 다루는 API에 대해 최근 6개월 이내 침투 테스트나 보안 점검을 받아보셨나요?

회사 내부망은 안 뚫렸는데도 이렇게 큰 유출이 가능한가요?

네, 가능해요. 이번 사고는 내부 시스템 침투가 아니라 외부에 그대로 노출된 API 엔드포인트를 통해 데이터를 긁어간 사례예요. 방화벽·서버 보안이 아무리 튼튼해도, 외부와 통신하는 API 자체에 인증이 빠져 있으면 내부망은 멀쩡한 채로 데이터만 빠져나갈 수 있어요.

1,744만 건 중 749만 건만 유출됐다는 게 그나마 다행 아닌가요?

CAPTCHA가 다운로드를 중단시킨 건 사실이지만, 이는 회사가 의도적으로 막은 보안 조치가 아니라 우연히 걸린 제한에 가까워요. 애초에 인증도 속도 제한도 없던 API였다는 점에서, 조금만 시간이 더 걸렸어도 전체 1,744만 건이 그대로 빠져나갔을 상황이에요.

이번 사고는 정교한 랜섬웨어나 제로데이 취약점이 아니라, 기본적인 API 보안 설정 몇 가지가 빠졌다는 이유만으로 700만 명 넘는 개인정보가 빠져나갈 수 있다는 걸 보여줬어요. 공격자 입장에서는 코드를 짜거나 침투 경로를 뚫을 필요도 없이, 그냥 열려 있는 문으로 걸어 들어간 셈이에요. 외부에 API를 열어둔 기업이라면, 지금 이 순간에도 비슷한 문이 열려 있지는 않은지 점검해볼 가치가 있어요.

이런 사고를 막으려면 API 앞단 보안만큼이나, 뚫렸을 때 최후 보루가 되어줄 백업까지 손대지 못하게 만드는 구조가 필요해요. 물리적으로 분리된 이중 데이터 다이오드 방식의 디포트리스가 그 역할을 해줘요. 관리자 권한이든 API든 뚫린 이후에도 백업 데이터만은 지킬 수 있는 원리가 궁금하다면 여기서 확인해보세요.