Blog

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

Tags: , ,

노출된 AWS 자격 증명과 Amazon Bedrock API 호출량·비용 증가 위험을 표현한 보안 이미지

AWS Bedrock을 통해 생성형 AI를 도입할 때 가장 먼저 떠올리는 리스크는
보통 hallucination, prompt injection, 개인정보 유출 같은 문제 입니다.

물론 이것들은 어느 하나 빠짐없이 중요합니다.


하지만 실무 관점에서 더 즉각적인 피해로 이어질 수 있는 리스크가 하나 있습니다.

바로 API key 또는 AWS credential 탈취를 통한 Bedrock API 비정상 호출입니다.

쉽게 말하면,

누군가 내 AWS 계정 권한을 탈취한 뒤 Amazon Bedrock을 대량으로 호출하고,

그 비용은 고스란히 계정 소유자에게 청구되는 구조입니다.

AI 모델이 틀린 답을 했다는 수준의 문제가 아니라,

실제 비용 피해로 바로 연결될 수 있는 운영 보안 이슈입니다.

사고의 본질은 AI 모델 문제가 아니라 ‘호출 권한’ 문제

탈취된 호출 권한을 통해 Amazon Bedrock API가 비정상적으로 사용되는 과정을 표현한 이미지

Amazon Bedrock은 여러 foundation model을 AWS 환경에서

통합 API로 호출할 수 있게 해주는 서비스입니다.

Claude, Nova 등의 모델을 하나의 AWS 계정과 권한 체계 안에서 사용할 수 있다는 점에서

많은 엔지니어와 고객의 선택을 받고 있는 대표적인 AI 서빙 서비스입니다.

문제는 이 편리함이 공격자에게도 동일하게 작동한다는 점입니다.

공격자가 다음 중 하나를 확보했다고 가정해 보겠습니다.

  • GitHub에 노출된 AWS access key
  • .env 파일에 남아 있던 Bedrock API key
  • 로컬 개발 PC에 저장된 장기 credential
  • CI/CD 로그에 출력된 token
  • 지나치게 넓은 IAM 권한이 부여된 개발용 계정

이 경우 공격자는 굳이 시스템 내부 데이터를 훔치지 않아도 됩니다.
그냥 Bedrock API를 계속 호출하면 됩니다.

특히 고성능 모델을 대량 호출하면 token 사용량이 빠르게 증가하고,

그에 따라 비용도 빠르게 커집니다.

이러한 유형의 공격을 ‘LLMjacking‘ 이라고 부릅니다.

기존 클라우드에서 EC2를 탈취해 crypto mining을 돌리던 방식이,

생성형 AI 시대에는 LLM API 과대 호출 공격으로 바뀐 셈입니다.

사례에서 보이는 공통 패턴

최근 공개 커뮤니티와 보안 업계 자료에서 Bedrock API 비정상 호출로

수만 달러 규모의 비용 피해가 발생했다는 사례들이 공유되고 있습니다.

이러한 공격 사례의 공통 흐름은 대체로 다음과 같습니다.

  1. 개발자가 실험용으로 AWS credential 또는 Bedrock API key를 생성한다.
  2. key가 GitHub, 로그, 노트북, 설정 파일, 공유 문서 등에 노출된다.
  3. 공격자는 자동화된 scanner로 노출된 credential을 탐지한다.
  4. Bedrock 모델 목록과 호출 가능 여부를 확인한다.
  5. 고비용 모델을 대량 호출한다.
  6. 계정 소유자는 CloudWatch, Budgets, Cost Explorer 또는 월말 청구서를 보고 나서야 이상을 인지한다.

여기서 중요한 포인트는 하나입니다.

공격자는 모델을 해킹한 것이 아니라, 호출 권한을 사용한 것입니다.

즉, 이 문제는 AI 모델 보안만으로 막을 수 없습니다.


IAM, credential 관리, logging, quota, 비용 알림, incident response 등

Bedrock API의 비정상 호출 전체를 아우를 수 있는 전방위적인 보안 거버넌스가 필요합니다.

왜 Bedrock API는 특히 주의해야 하는가?

Bedrock 자체가 위험한 서비스라는 의미는 아닙니다.

오히려 AWS IAM, CloudTrail, GuardDuty, CloudWatch, VPC endpoint 등과 결합하면

enterprise 환경에서 통제 가능한 AI 플랫폼을 구성하기 좋습니다.

다만 Bedrock은 비용 구조상 “호출량”이 곧 비용과 직결됩니다.

일반적인 웹 API는 비정상 호출이 발생해도 서버 부하, rate limit, WAF 로그 정도에서

먼저 감지되는 경우가 많습니다.

반면 LLM API는 다음 특성을 가집니다.

구분일반 APILLM API
주요 비용 기준request 수, 서버 리소스input/output token
피해 확산 속도상대적으로 완만token 양에 따라 급격히 증가
공격자 목적데이터 접근, 시스템 장악API 호출권 남용, resale, 자동화 작업
관측 지표request count, latency, errorinvocation count, token count, modelId, quota usage
대응 핵심인증/인가, WAF, rate limitcredential 통제, model 권한 제한, token 관측, 비용 차단

결국 Bedrock 운영에서는 “API가 호출된다”는 사실만 보면 부족합니다.

누가 호출했는지, 어떤 modelId를 호출했는지, input/output token이 얼마나 발생했는지,

평소 baseline과 비교해 비정상적인지까지 봐야 합니다.

예방 방안 1. Long-term key 사용 최소화

개발 환경에 노출된 AWS credential을 탐지하고 Amazon Bedrock 호출 권한을 보호하는 보안 이미지

가장 먼저 봐야 할 것은 credential 정책입니다.

실험 단계에서는 Bedrock API key가 편리합니다.

특히 API key 기반 인증을 요구하는 도구나 SDK를 붙일 때는 빠르게 테스트할 수 있습니다.

하지만 운영 환경에서는 이야기가 달라집니다.

운영 서비스에서는 가능한 한 다음 순서를 권장합니다.

  1. IAM Role + temporary credential
  2. AWS STS 기반 short-lived credential
  3. Bedrock short-term API key
  4. 불가피한 경우에만 Bedrock long-term API key

Long-term key는 한 번 만들어두면 편하다는 장점이 있지만,

그 편의성만큼 노출 시 피해 범위도 커집니다.

특히 만료일이 길거나, 권한이 넓거나, 사용처가 명확하지 않은 key는

보안 거버넌스 관점에서 그 부담이 배가 됩니다.

실무적으로는 다음 정책을 기본값으로 두는 것이 좋습니다.

  • production 계정에서는 long-term Bedrock API key 생성을 기본 차단
  • 개발 계정에서도 만료일 없는 key 금지
  • key 생성 가능 주체를 별도 IAM group 또는 role로 제한
  • bedrock:CallWithBearerToken 사용 여부를 CloudTrail에서 점검
  • 사용하지 않는 IAM user와 service-specific credential 정기 제거

AI 활용을 빠르게 시작하는 것보다 중요한 것은,

AI 호출 권한이 어디에 존재하는지 추적 가능한 상태로 만드는 것입니다.

예방 방안 2. IAM 권한을 ‘모델 단위’로 좁힌다

Bedrock 권한을 줄 때 bedrock:* 형태로 넓게 부여하는 것은 편하지만 위험합니다.

실무에서는 최소한 다음 기준으로 권한을 나누는 편이 안전합니다.

계정/환경허용 범위권장 정책
개인 실험제한된 model, 제한된 region비용 알림 필수
개발 환경승인된 modelId만 허용호출량 모니터링
운영 환경application role 기반 허용least privilege
보안 민감 환경특정 model, 특정 VPC, 특정 workflowSCP + GuardDuty + CloudTrail
미사용 계정Bedrock 호출 차단deny-by-default

중요한 것은 Bedrock 접근 가능 여부가 아니라

어떤 role이 어떤 model을 어떤 목적으로 호출할 수 있는지 여부입니다.

AI 서비스는 모델 성능보다 운영 권한 설계가 먼저 정리되어야 합니다.

이 순서가 뒤집히면 PoC는 빠르게 만들 수 있지만,

운영 전환 시 언제 터질지 모르는 보안 시한폭탄을 품고 있는 것과 같습니다.

예방 방안 3. CloudTrail과 Model Invocation Logging을 활성화한다

Amazon Bedrock 호출량, 토큰 사용량, IAM 역할과 이상 징후를 모니터링하는 대시보드 이미지

비정상 호출을 막지 못했다면 최소한 빨리 알아야 합니다.

이를 위해 기본적으로 확인해야 할 것은 세 가지입니다.

첫째, CloudTrail입니다.
CloudTrail은 Bedrock API 호출 이력을 확인하는 기본 감사 로그입니다.

InvokeModel, InvokeModelWithResponseStream, Converse, ConverseStream 같은 호출 이벤트를 확인할 수 있습니다.

둘째, Model Invocation Logging입니다.
Bedrock은 model invocation log를 CloudWatch Logs 또는 S3로 보낼 수 있으며,

이를 통해 호출 metadata, input/output 정보, token 사용량 등을 분석할 수 있습니다.

단, 민감한 prompt나 response가 로그에 포함될 수 있으므로

logging 대상과 보관 정책은 별도로 설계해야 합니다.

셋째, CloudWatch Metrics입니다.
Bedrock은 Invocations, InvocationLatency, InputTokenCount,

OutputTokenCount, InvocationThrottles 같은 지표를 제공합니다.

최근에는 quota 사용량이나 streaming latency 관측을 위한 metric도 강화되고 있습니다.

실무적으로는 다음 dashboard를 권장합니다.

  • modelId별 invocation count
  • modelId별 input/output token count
  • role 또는 user 기준 호출량
  • region별 Bedrock 사용량
  • 비정상 시간대 호출 여부
  • quota 사용률
  • throttling 발생 여부
  • 일별/시간별 비용 추정치

보안 사고 대응에서 가장 어려운 것은 “무슨 일이 있었는지 모르는 상태”입니다.
로그와 metric은 사고 후 분석용이 아니라, 사고를 작게 끝내기 위한 사전 장치입니다.

예방 방안 4. 비용 알림은 ‘최후 방어선’이다

AWS Budgets, CloudWatch Billing Alarm, Cost Anomaly Detection은 반드시 설정해야 합니다.

다만 이것만으로 충분하다고 보면 안 됩니다.

비용 알림은 이미 비용이 발생한 뒤 울리는 경우가 많습니다.

특히 billing data는 실시간 보안 이벤트와 다르게 지연될 수 있습니다.

따라서 비용 알림은 1차 방어선이 아니라 최후 방어선에 가깝습니다.

권장 구성은 다음과 같습니다.

통제 항목목적
AWS Budgets월별/일별 비용 threshold 알림
Forecasted budget alert예상 초과 비용 사전 감지
CloudWatch Billing Alarm전체 예상 비용 기준 알림
Cost Anomaly Detection평소 패턴 대비 비정상 비용 감지
CloudWatch token metric alarmBedrock token 사용량 급증 탐지
SNS/Slack 알림운영자 즉시 인지
Budget Action특정 threshold 초과 시 IAM 제한 정책 적용

핵심은 비용 알림과 보안 이벤트를 분리해서 보지 않는 것입니다.

Bedrock 비용이 갑자기 늘어나는 것은 FinOps 이슈이기도 하지만,

동시에 credential compromise 가능성을 의심해야 합니다.

예방 방안 5. 사고 대응 Runbook을 미리 만든다

보안 사고는 사고 사실을 알게 된 뒤 어떻게 대응할 것인지 미리 정해져 있어야 합니다.

Bedrock API 비정상 호출이 의심될 때는 다음 순서로 대응하는 것이 좋습니다.

  1. 비정상 호출 계정, region, role, user 식별
  2. 의심 credential 즉시 비활성화
  3. Bedrock API key 사용 중이면 key deactivate/reset/delete
  4. long-term API key가 만든 IAM user 확인 및 삭제 여부 검토
  5. CloudTrail에서 InvokeModel, Converse, CallWithBearerToken 관련 이벤트 확인
  6. Service Quotas increase 요청 여부 확인
  7. Model Invocation Log에서 호출 modelId, token 사용량, prompt 패턴 확인
  8. AWS Support에 보안 사고 및 billing dispute 접수
  9. 동일 credential이 GitHub, CI/CD, local, secret manager 외부에 노출됐는지 재점검
  10. SCP/IAM policy로 재발 방지 정책 적용

여기서 중요한 것은 비용 환불 가능 여부보다 다시 호출되지 않게 막는 것입니다.

비용은 협의의 영역이지만, credential 차단은 즉시 실행할 수 있는 영역입니다.

실무 체크리스트

Bedrock을 이미 사용 중이거나 PoC를 준비 중이라면 아래 항목부터 점검하는 것이 좋습니다.

점검 항목확인 질문
Credentiallong-term key가 필요한가?
IAMbedrock:* 권한이 남아 있지 않은가?
API key만료일 없는 key가 존재하는가?
CloudTrailBedrock 호출 이벤트를 추적할 수 있는가?
Invocation Logging호출 metadata와 token 사용량을 확인할 수 있는가?
CloudWatchmodelId별 token metric dashboard가 있는가?
Budget실제/예상 비용 알림이 설정되어 있는가?
Anomaly Detection평소 비용 패턴 대비 이상 징후를 감지하는가?
GuardDutyBedrock 관련 suspicious activity 탐지가 가능한가?
Runbook의심 호출 발생 시 누가 무엇을 차단하는가?

이 체크리스트에서 3개 이상 답변이 불명확하다면,

Bedrock의 운영 환경을 다시 한 번 점검해 볼 필요가 있습니다.

AI 거버넌스는 모델 관리가 아니라 호출 권한 관리에서 시작된다

비정상 AI 호출과 비용 증가 위험을 IAM 권한 관리와 보안 통제로 방어하는 AI 거버넌스 이미지

생성형 AI 도입은 이제 실험 단계를 지나 운영 단계로 넘어가고 있습니다.
그만큼 보안 거버넌스의 기준도 바뀌어야 합니다.

과거에는 누가 서버에 접근할 수 있는가가 중요했다면,

이제는 어떤 AI 모델을 얼마나 호출할 수 있는가가 더 치명적입니다.

Bedrock API 비정상 호출 사고는 단순한 비용 사고가 아닙니다.

AI 활용이 늘어날수록 credential, IAM, logging, monitoring,

billing, incident response가 하나의 운영 체계로 묶여야 한다는 신호입니다.

AI를 빠르게 붙이는 것은 어렵지 않습니다.


어려운 것은 AI를 안전하게, 추적 가능하게, 비용 통제 가능한 상태로 운영하는 것입니다.

결국 실무에서 필요한 질문은 이것입니다.

“우리 조직은 Bedrock을 사용할 수 있는가?”가 아니라,
“우리 조직은 Bedrock의 사용에 더해 보안 취약점도 안전하게 방어할 수 있는가?” 입니다.


생성형 AI를 안전하게 운영하려면 모델 도입만으로는 충분하지 않습니다.
IAM, credential, 네트워크, 로깅, 비용 통제, 사고 대응까지 함께 설계되어야 합니다.

NDS는 기업이 Amazon Bedrock을 보다 안전하고 추적 가능하며,

비용 통제 가능한 방식으로 활용할 수 있도록 AI 보안 거버넌스 체계 수립을 지원합니다.

AI Engineer 박정현

조회수 : 1