CISA에서 터진 데이터 유출, 미 의회가 답을 요구하기 시작했다

무슨 일이 벌어진 걸까요

미국에서 사이버보안을 총괄하는 기관이 있어요. 이름은 CISA(Cybersecurity and Infrastructure Security Agency), 우리말로 풀면 "사이버보안 및 인프라 보안국" 정도 되겠네요. 한국으로 치면 KISA(한국인터넷진흥원)와 비슷한 역할을 하는 곳인데, 미국 연방정부 산하의 핵심 보안 기관이라고 보시면 됩니다. 그런데 바로 이 기관에서 데이터 유출 사고가 터졌고, 이번 주 미국 의회 의원들이 "도대체 무슨 일이냐, 정확히 설명하라"고 공식적으로 답변을 요구하기 시작했어요.

흥미로운 건 이번 사건이 "외부 해커가 침투했다"는 단순한 그림이 아니라는 점이에요. 보안 정책을 만들고 다른 기관을 감독해야 할 기관이 정작 자기 데이터를 흘렸다는 점에서, 그 정치적·기술적 파장이 훨씬 큽니다. 보안업계의 유명 기자인 브라이언 크렙스(Brian Krebs)가 이번 사안을 추적해서 정리한 글이 화제예요.

사건의 핵심 — 어떤 데이터가 어떻게 새어 나갔나

CISA는 미국 전역의 주요 인프라(전력망, 상수도, 금융망, 통신 같은 것들)를 사이버 위협으로부터 보호하는 역할을 맡고 있어요. 그래서 이 기관에는 "어떤 회사의 어떤 시스템에 어떤 취약점이 있다"는 식의 굉장히 민감한 정보가 모입니다. 즉, 만약 이 데이터가 공격자 손에 들어간다면, 그건 단순한 개인정보 유출이 아니라 "미국 핵심 인프라의 약점이 적힌 지도"가 공개되는 셈인 거죠.

이번에 문제가 된 건 CISA가 운영하는 한 시스템에서 외부에서 접근 가능한 형태로 데이터가 노출됐다는 점이에요. 권한 설정이 잘못됐든, 인증 절차가 허술했든, 어쨌든 "내부용으로만 봐야 할 정보"가 일정 기간 동안 외부에 떠 있었다는 거예요. 의원들이 분노하는 지점은 두 가지인데요. 첫째, 이런 일이 일어났다는 사실을 CISA가 외부에 빨리 알리지 않았다는 점. 둘째, 정확히 어떤 데이터가, 누구에 의해, 얼마나 다운로드됐는지 아직도 명확한 답변이 안 나온다는 점입니다.

왜 이게 더 큰 문제인가

보안 업계에는 오래된 격언이 있어요. "방화벽을 만드는 사람이 가장 먼저 뚫린다"는 말이요. 농담 같지만 사실에 가까운데, 보안 기관일수록 공격 타깃이 되기 쉽고, 또 그 안에 모인 데이터의 가치가 어마어마하기 때문이에요. 이번 사건도 그런 패턴의 연장선이에요.

특히 CISA의 경우 "취약점 정보 공유 프로그램"이라는 걸 운영해요. 민간 기업이 자기 시스템의 약점을 정부에 알려주면, 정부가 이를 익명화해서 다른 기업과 공유하는 거죠. 그런데 이 익명화된 정보 안에는 사실상 "어느 회사의 어떤 제품에 어떤 약점이 있다"를 추적할 수 있는 단서가 들어 있어요. 만약 이번 유출에 그런 데이터가 포함됐다면, 공격자는 패치되지 않은 취약점 목록을 손에 쥔 셈이 됩니다.

비슷한 사례들 — 이게 처음은 아니다

사실 정부 기관의 데이터 유출은 그동안 꾸준히 있었어요. 2015년 미국 인사관리처(OPM) 사건에서는 공무원 2,200만 명의 신상정보와 지문 데이터까지 유출됐고요. 2020년 솔라윈즈(SolarWinds) 사건 때는 미국 재무부, 국무부, 국토안보부의 내부 네트워크가 몇 달 동안 공격자에게 노출돼 있었던 게 뒤늦게 밝혀졌어요. 한국도 예외가 아니어서, 행정안전부의 정부24나 KT 사태 같은 굵직한 사건들이 있었죠.

이번 CISA 사건이 다른 건, 다른 모든 기관에 "이렇게 보안하라"고 가이드를 주는 곳에서 벌어졌다는 점이에요. 이건 마치 운전면허 시험장에서 무면허 운전 사고가 난 격이에요.

한국 개발자 입장에서 무엇을 배울까

실무에서 가장 자주 일어나는 데이터 유출은 사실 "해킹"보다 "설정 실수"예요. S3 버킷 권한을 public으로 열어둔다거나, 디버그용 엔드포인트를 운영 환경에 그대로 남겨두는 식이죠. 이번 CISA 사건도 정확한 원인은 밝혀지지 않았지만, 보안 전문가들 사이에선 "또 권한 설정 실수일 가능성이 높다"는 추측이 나오고 있어요.

그래서 우리가 할 수 있는 가장 현실적인 대비책은요. 첫째, 클라우드 리소스에 대해 정기적으로 권한 감사(IAM audit)를 돌리는 거예요. AWS Config나 GCP의 Security Command Center 같은 도구들이 자동으로 잘못된 설정을 잡아줍니다. 둘째, 민감 데이터는 무조건 "필요한 사람만, 필요한 시간만" 접근하는 원칙(Principle of Least Privilege)을 지키는 거예요. 셋째, 침해가 발생했을 때 누가, 언제, 무엇을 봤는지 추적할 수 있는 감사 로그를 반드시 켜둬야 해요.

마무리

결국 이번 사건의 교훈은 단순합니다. "보안은 만드는 곳에서도 깨진다." 아무리 큰 기관이라도, 아무리 보안에 신경 쓰는 조직이라도, 한 명의 설정 실수나 한 줄의 잘못된 코드로 모든 게 무너질 수 있어요.

여러분 회사의 클라우드 권한 설정, 마지막으로 점검한 게 언제인가요? 혹시 "누가 한번 정리해야 하는데..."라며 미뤄둔 권한 정책이 있다면, 이번 주에는 한번 들여다보시는 게 어떨까요?