작성자: Karol Sobieraj, Digital Colliers 설립자 및 CEO

이번 달 CISA의 권고안은 큰 반향 없이 지나갔지만, 그 형태는 새로운 것이 아닙니다. 한 연방 계약업체의 비공개 GitHub 리포지토리(repo)에서 클라우드 액세스 키(access keys)가 유출되었습니다. 업계의 대응은 예측 가능했습니다. 시크릿 스캐닝(secret scanning)을 활성화하고, 노출된 키를 교체(rotate)한 뒤, 다음 단계로 넘어가는 것이었습니다. 하지만 이는 진짜 문제를 놓치고 있습니다. 제가 대화하는 대부분의 중견 은행들은 더 단순한 질문에 답하지 못합니다. 우리의 자격 증명(credentials)이 어디에 저장되어 있는지, 누가 소유하고 있는지, 그리고 얼마나 빨리 하나를 무효화할 수 있는지 말입니다.

이것은 스캐닝(scanning)의 문제가 아닙니다. 인벤토리(inventory)의 문제입니다. 그리고 금융 서비스 분야에서 이 문제를 지금 해결하지 못했을 때 치러야 할 비용은 빠르게 상승하고 있습니다.

유출이 실제로 발생하는 방식

GitHub 사례는 하나의 채널일 뿐입니다. 그 밑바탕에 깔린 패턴은 지루할 정도로 보편적입니다. 개발자가 스테이징 버킷(staging bucket)을 대상으로 무언가를 테스트해야 합니다. 그들은 설정 파일(config file)에 키를 붙여넣습니다. 이 설정 파일은 리포지토리(repo)나 Slack 스레드, Jira 티켓, 또는 6개월 뒤에 이미지가 재설정되는 노트북에 남게 됩니다. 그 키는 1년 동안 유효합니다. 아무도 그것이 존재한다는 사실을 기억하지 못합니다.

2019년 이후 귀하의 은행이 구축한 모든 엔지니어, 모든 계약업체, 모든 CI 작업, 모든 제3자 SaaS 통합에 이 상황을 곱해 보십시오. 당신은 자격 증명(credential) 문제를 겪고 있는 것이 아닙니다. 당신은 자격 증명 고고학(credential archaeology) 문제를 겪고 있는 것입니다.

운영자들이 계속해서 유출을 발견하는 몇 가지 채널은 다음과 같습니다:

• 포크(forks) 및 오래된 브랜치를 포함한 공개 및 비공개 Git 리포지토리(repos)
• 파이프라인(pipeline)보다 오래 살아남은 CI/CD 변수 저장소
• Postman 컬렉션 및 내부 위키(wikis)
• 이메일로 공유된 벤더 온보딩(vendor onboarding) 문서
• 더 이상 아무도 소유하지 않는 프로젝트의 서버리스(Serverless) 환경 변수
• 토큰(tokens)이 내장된 컨테이너 이미지

스캐닝은 처음 두 가지 경우에는 도움이 됩니다. 하지만 나머지 경우에는 거의 아무런 도움이 되지 않습니다.

스캐닝만으로는 실패하는 이유

Secret scanners(비밀번호 스캐너)는 패턴 매칭 도구입니다. 이들은 사용자가 지정한 위치 내에서 키(key)처럼 보이는 것들을 찾아냅니다. 하지만 그 키가 여전히 활성 상태인지, 누가 소유하고 있는지, 그리고 키를 교체(rotate)했을 때 어떤 운영 시스템(production system)이 중단될지는 알려주지 못합니다. 또한, 공개 저장소(public repo)에서 발견된 키가 실제 운영 중인 Lambda 내부에 있는 키와 동일한 것인지도 확실히 알 수 없습니다.

바로 이 마지막 지점에서 해결(remediation) 작업이 지연됩니다. 스캐너는 키가 유출되었다고 알려주지만, 그 키에 무엇이 의존하고 있는지는 아무도 모릅니다. 보안 팀은 티켓을 발행합니다. 엔지니어링 팀이 영향 범위(blast radius)를 파악하는 동안 그 티켓은 몇 주 동안 방치됩니다. 그 사이 규제 노출(regulatory exposure)에 대한 시계는 계속 흘러갑니다.

이는 Verizon이 CVE 측면에서 기록한 것과 동일한 역학 관계입니다. 공개적으로 발표된 취약점 중 30일 이내에 패치되는 것은 약 3~5%에 불과합니다. 병목 현상의 원인은 탐지(detection)가 아닙니다. 이미 알고 있는 정보에 대해 조직이 조치를 취할 수 있는 능력의 문제입니다.

2026년에 이를 해결하지 않았을 때의 비용

DORA(디지털 운영 탄력성법)는 2025년 1월 17일부터 시행되었습니다. 이는 미래의 문제가 아닙니다. DORA는 EU 내 금융 기관이 제3자 자산을 포함한 모든 ICT 자산을 식별, 분류 및 문서화할 것을 요구합니다. 자격 증명(credential)은 ICT 자산입니다. 요청 시 즉시 인벤토리(inventory)를 제시할 수 없다면, 아직 요청을 받지 않았더라도 이미 규정 미준수(non-compliance) 상태입니다.

그 위에는 GDPR(일반 데이터 보호 규정)이 자리 잡고 있습니다. 벌금은 최대 2,000만 유로 또는 전 세계 매출액의 4%에 달할 수 있습니다. 공격자에게 고객 데이터 저장소에 대한 읽기 권한을 부여하는 클라우드 키 유출은 더 이상 단순한 보안 사고가 아닙니다. 이는 통지 대상 침해(notifiable breach)이며, 규제 기관의 첫 번째 질문은 그 키가 얼마나 오랫동안 활성화되어 있었는지, 그리고 왜 아무도 이를 교체하지 않았는지에 대한 것이 될 것입니다. "우리는 그것이 있는지 몰랐다"는 답변은 벌금을 줄여주지 않습니다.

여기서 행동하지 않음으로써 발생하는 비용은 가설이 아닙니다. 그것은 몇 시간 내에 교체하는 것과 몇 주 내에 교체하는 것 사이의 차이이며, 규제 노출과 고객 신뢰라는 가치로 환산됩니다.

몇 시간 내에 교체하기 위한 최소 데이터 모델

플랫폼이 필요한 것이 아닙니다. 테이블이 필요합니다. 이 문제를 제대로 해결하고 있는 은행들은 이와 유사한 것을 구축하고, 단일 장소에서 이를 쿼리(Query)하고 있습니다:

• 자격 증명(Credential) ID 및 유형 (API key, OAuth token, 서비스 계정(Service account), 인증서(Cert))
• 발급 시스템(Issuing system) 및 발급 날짜
• 만료일 (있는 경우)
• 소유 팀 및 지정된 담당자(Named human backup)
• 이를 사용하는 시스템 및 신뢰 수준(Confidence level)
• 발급 시스템에서 가져온 마지막 사용 타임스탬프(Last-used timestamp)
• 로테이션 런북(Rotation runbook) 링크

그게 전부입니다. 7개의 필드입니다. 어려운 점은 스키마(Schema)가 아닙니다. 데이터를 채우고, 최신 상태로 유지하며, 테이블에 없는 모든 자격 증명을 사고(Incident)로 취급하는 규율(Discipline)입니다.

해당 테이블을 한 번에 쿼리할 수 있는 운영자는 몇 시간 내에 로테이션을 수행합니다. 그 외의 모든 사람은 규제 기관이 기다리는 동안 자신들의 git 히스토리와 협상해야 합니다.

출처

• European Commission

이 기사는 원래 Digital Colliers Blog에 게시되었습니다. Digital Colliers는 DACH 및 UK 기업의 AI 도입을 지원합니다 — 저희의 AI 컨설팅 서비스를 확인하거나 문의해 주세요.