보안 사고에서 가장 위험한 순간은 “시스템이 뚫렸다”가 아니라 “정상 권한이 밖으로 나갔다”일 때가 많습니다. 공개 GitHub 저장소로 알려진 ‘Private-CISA’ 논란도 결국 이 문제를 드러냅니다.
보도에 따르면 CISA 계약자가 관리한 공개 GitHub 저장소 ‘Private-CISA’에는 CISA/DHS 내부 자격 증명, 클라우드 키, 토큰, 평문 비밀번호, 로그가 포함돼 있었습니다.1 CISA 대변인은 기관이 보고된 노출을 인지하고 조사 중이라고 밝혔습니다.1
핵심은 GitHub가 아니라 비밀값의 위치다
GitHub 자체가 문제의 본질은 아닙니다. GitHub는 코드와 문서를 협업하기 위한 도구입니다. 위험은 비밀번호, 토큰, 클라우드 키 같은 비밀값이 코드와 같은 저장소 흐름 안에 놓였을 때 발생합니다.
자격 증명은 단순한 문자열이 아닙니다. 시스템에 접근할 수 있는 열쇠입니다. 특히 ‘importantAWStokens’ 파일에 AWS GovCloud 서버 3개의 관리자 자격 증명이 포함돼 있었다는 점은 위험도를 크게 높입니다.1 관리자 권한은 노출 범위와 피해 가능성을 동시에 키우기 때문입니다.
또 다른 파일인 ‘AWS-Workspace-Firefox-Passwords.csv’에는 CISA 내부 시스템 수십 개의 평문 사용자 이름과 비밀번호가 포함돼 있었다고 보도됐습니다.1 평문 비밀번호는 별도 해독 과정 없이 곧바로 사용될 수 있어, 유출 즉시 사고 대응의 우선순위가 됩니다.
공격자는 취약점보다 유효한 계정을 선호한다
현대 공격은 반드시 악성코드나 복잡한 취약점에서 시작하지 않습니다. 정상 계정과 정상 도구만으로도 내부 이동이 가능합니다. 국내 보안 기사에서도 “악성 코드 없이 정상 명령어와 업무용 소프트웨어를 이용한 공격” 흐름이 언급됩니다.2
이 관점에서 보면 자격 증명 유출은 단순한 관리 실수가 아닙니다. 공격자에게는 침입 과정을 단축하는 지름길입니다. 방화벽을 우회하거나 취약점을 찾지 않아도, 유효한 키와 비밀번호가 있으면 정상 사용자처럼 접근할 수 있습니다.
특히 정부·공공 클라우드 환경의 계정은 더 민감합니다. 권한 범위가 넓거나 로그·내부 시스템에 접근할 수 있다면, 사고 대응은 “무엇이 노출됐는가”를 넘어 “해당 권한으로 실제 무엇에 접근했는가”까지 확인해야 합니다.
실무에서 바로 적용할 기준
이번 사건이 주는 교훈은 명확합니다. 비밀값은 코드 저장소에 두지 않는다는 원칙을 기술과 절차로 강제해야 합니다.
첫째, 비밀번호·토큰·클라우드 키는 저장소가 아니라 시크릿 매니저, 환경 변수, 단기 토큰 같은 방식으로 관리해야 합니다. 사람이 조심하는 방식만으로는 부족합니다.
둘째, 유출이 확인되면 삭제보다 폐기가 먼저입니다. 저장소에서 파일을 지우거나 비공개로 전환하는 것만으로는 이미 복제됐을 가능성을 없앨 수 없습니다. 노출된 키와 비밀번호를 즉시 회전하고, 사용 기록을 추적해야 합니다.
셋째, 계약자 계정도 내부자와 같은 기준으로 관리해야 합니다. 최소 권한 원칙을 적용하고, 저장소 공개 여부와 시크릿 포함 여부를 자동으로 점검해야 합니다. 외부 협업 구조가 많아질수록 이 기준은 선택이 아니라 기본 통제가 됩니다.
‘Private-CISA’ 사건의 결론은 간단합니다. 보안은 침입을 막는 일만이 아닙니다. 조직의 열쇠가 어디에 저장되고, 누가 접근하며, 노출됐을 때 얼마나 빨리 폐기할 수 있는지 계속 확인하는 일입니다.
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.