Bedrock API Key 하나가 수 천만원 청구서로 돌아온 이유

Amazon Bedrock 도입 시 hallucination이나 prompt injection보다 즉각적인 피해로 이어지는 리스크로 credential 탈취를 통한 API 비정상 호출을 짚는다. 공격자가 모델을 해킹하는 것이 아니라 호출 권한을 그대로 사용하는 구조라, 토큰 사용량이 곧 비용인 LLM API에서는 피해가 빠르게 커진다. 이런 공격을 LLMjacking이라 부르며, credential 정책·IAM 범위·로깅·비용 알림·사고 대응 Runbook을 한 체계로 묶는 방안을 정리했다.

핵심 포인트

노출 경로는 GitHub의 access key, .env에 남은 Bedrock API key, 로컬 PC의 장기 credential, CI/CD 로그의 token, 지나치게 넓은 IAM 권한이 붙은 개발용 계정이다.
일반 API는 비정상 호출이 서버 부하나 rate limit, WAF 로그에서 먼저 잡히지만 LLM API는 토큰 양에 따라 피해가 급격히 커진다.
관측 지표가 다르다. request count와 latency가 아니라 invocation count, token count, modelId, quota 사용률을 봐야 한다.
비용 알림은 billing data 지연 때문에 이미 비용이 발생한 뒤 울리는 경우가 많아 1차 방어선이 아니라 최후 방어선이다.
Bedrock 비용 급증은 FinOps 이슈인 동시에 credential compromise 신호로 함께 의심해야 한다.

상세 정리

공격 흐름: 실험용으로 만든 credential이나 API key가 GitHub·로그·노트북·설정 파일·공유 문서에 노출되고, 자동화 scanner가 이를 탐지한 뒤 모델 목록과 호출 가능 여부를 확인해 고비용 모델을 대량 호출한다. 계정 소유자는 CloudWatch나 Budgets, Cost Explorer, 월말 청구서를 보고서야 인지한다.
성격 규정: 기존 클라우드에서 EC2를 탈취해 crypto mining을 돌리던 방식이 생성형 AI 시대에 LLM API 과대 호출로 바뀐 셈이라고 정리한다. 수만 달러 규모 피해 사례가 공개 커뮤니티와 보안 업계 자료로 공유되고 있다고 인용한다.
예방 1 credential 순서: 운영 서비스는 IAM Role과 temporary credential을 우선하고, 다음이 STS 기반 short-lived credential, 그다음이 Bedrock short-term API key이며, long-term API key는 불가피한 경우에만 쓴다.
기본값으로 둘 정책: 운영 계정에서 long-term Bedrock API key 생성 기본 차단, 개발 계정에서도 만료일 없는 key 금지, key 생성 가능 주체를 별도 IAM group이나 role로 제한, bedrock:CallWithBearerToken 사용 여부를 CloudTrail에서 점검, 미사용 IAM user와 service-specific credential 정기 제거.
예방 2 권한 범위: bedrock:* 형태의 넓은 부여 대신 환경별로 나눈다. 개인 실험은 제한된 model과 region에 비용 알림 필수, 개발 환경은 승인된 modelId만 허용하고 호출량 모니터링, 운영 환경은 application role 기반 least privilege, 보안 민감 환경은 특정 model·VPC·workflow로 좁히고 SCP와 GuardDuty·CloudTrail을 붙이며, 미사용 계정은 deny-by-default로 호출을 차단한다.
판단 기준을 "Bedrock에 접근 가능한가"가 아니라 "어떤 role이 어떤 model을 어떤 목적으로 호출할 수 있는가"로 바꿔야 한다고 강조한다. 순서가 뒤집히면 PoC는 빨라도 운영 전환 시 부담이 남는다.
예방 3 로깅 세 갈래: CloudTrail은 InvokeModel, InvokeModelWithResponseStream, Converse, ConverseStream 같은 호출 이벤트를 남기는 기본 감사 로그다.
Model Invocation Logging은 CloudWatch Logs나 S3로 호출 metadata와 input/output 정보, 토큰 사용량을 보낼 수 있다. 다만 민감한 prompt나 response가 로그에 포함될 수 있어 대상과 보관 정책을 따로 설계해야 한다.
CloudWatch Metrics는 Invocations, InvocationLatency, InputTokenCount, OutputTokenCount, InvocationThrottles를 제공한다.
권장 대시보드: modelId별 invocation count와 input/output token count, role 또는 user 기준 호출량, region별 사용량, 비정상 시간대 호출 여부, quota 사용률, throttling 발생 여부, 일별·시간별 비용 추정치.
예방 4 비용 통제: AWS Budgets로 월별·일별 threshold 알림, forecasted budget alert로 예상 초과 사전 감지, CloudWatch Billing Alarm, Cost Anomaly Detection으로 평소 패턴 대비 이상 감지, CloudWatch token metric alarm으로 토큰 급증 탐지, SNS나 Slack 알림, threshold 초과 시 IAM 제한 정책을 적용하는 Budget Action을 함께 건다.
예방 5 사고 대응 순서: 비정상 호출 계정·region·role·user 식별 → 의심 credential 즉시 비활성화 → API key라면 deactivate/reset/delete → long-term key가 만든 IAM user 확인과 삭제 검토 → CloudTrail에서 InvokeModel·Converse·CallWithBearerToken 이벤트 확인 → Service Quotas 증설 요청 여부 확인 → Invocation Log에서 modelId·토큰 사용량·prompt 패턴 확인 → AWS Support에 보안 사고와 billing dispute 접수 → 동일 credential의 외부 노출 재점검 → SCP와 IAM policy로 재발 방지.
대응 우선순위: 비용 환불 가능 여부보다 다시 호출되지 않게 막는 것이 먼저다. 비용은 협의 영역이지만 credential 차단은 즉시 실행할 수 있는 영역이기 때문이다.
점검 체크리스트: long-term key 필요 여부, bedrock:* 권한 잔존 여부, 만료일 없는 key 존재 여부, CloudTrail 추적 가능 여부, Invocation Logging으로 metadata와 토큰 확인 가능 여부, modelId별 token metric 대시보드 유무, 실제·예상 비용 알림 설정, 비용 이상 징후 감지, GuardDuty의 Bedrock 관련 탐지, 의심 호출 시 누가 무엇을 차단하는지 정해진 Runbook. 세 개 이상 불명확하면 운영 환경을 다시 점검하라고 권한다.
Bedrock 자체가 위험하다는 뜻은 아니며 IAM·CloudTrail·GuardDuty·CloudWatch·VPC endpoint와 결합하면 통제 가능한 AI 플랫폼을 구성하기 좋다고 전제를 분명히 한다.