슬레이트 위 금속 방패, 열쇠, 네트워크 노드, 청사진으로 표현한 보안 설계 평면도
글 요약
Amazon Bedrock 엔터프라이즈 보안 아키텍처를 IAM 최소 권한, VPC Endpoint 사설망 격리, Guardrail 정책 엔진까지 한 번에 설계하는 법을 정리했습니다. 비용 폭탄과 데이터 유출 사고를 사전에 차단하는 실무 노하우와, Azure OpenAI·Vertex AI와의 보안 기능 비교까지 한 자리에서 확인하실 수 있습니다.
“외부 LLM 도입 검토 단계에서 데이터 유출 우려 때문에 보안을 끼고 가야 할지, 그냥 막아야 할지 갈팡질팡하더라고요.”
IAM 권한 경계, VPC Endpoint로 나가는 트래픽 잠그기, Guardrail로 유해 출력 차단까지 3단 방어선을 어떻게 짜는지가 핵심입니다. 이 글에서는 엔터프라이즈 Bedrock 도입을 망설이는 보안 담당자가 바로 설계도에 옮길 수 있는 아키텍처와, 실무에서 자주 터지는 사고 사례까지 풀어드립니다.
생성형 AI 도입이 가속되면서 많은 기업이 AWS Bedrock을 표준 LLM 플랫폼으로 검토하고 있습니다. 문제는 프롬프트에 포함된 고객 정보와 사내 비밀이 모델 Provider나 외부망으로 새나가는 경로가 너무 많다는 점이에요. 단순히 “Bedrock을 켜자”가 아니라, 누가 어떤 모델을 호출할 수 있고, 트래픽은 어느 경로로 빠져나가며, 출력에서 무엇을 막을 것인지를 처음부터 코드로 정의해 둬야 합니다. 이걸 안 하고 출시한 조직이 실제로 비용 폭탄과 데이터 노출 사고를 동시에 맞는 경우가 더러 있거든요.
목차
목차를 따라 순서대로 읽으시면 가장 효율적이고, 이미 Bedrock을 운영 중인 분은 실패 사례와 비교표 섹션부터 보셔도 큰 도움이 됩니다. 보안 아키텍처는 결국 “어디서 막고, 어디서 보고, 어디서 끊을 것인가”의 문제거든요.
📌 이 글의 핵심 정리
- 엔터프라이즈 Bedrock 보안은 IAM, VPC Endpoint, Guardrail 세 축을 한 설계도로 묶을 때 비로소 닫힌 방어선이 됩니다.
- IAM은 권한 경계(permissions boundary)와 SCP를 함께 걸어 개발자별 호출 가능 모델과 리전을 봉인하는 게 핵심입니다.
- VPC Endpoint는 Interface Endpoint + Endpoint Policy 조합으로 인터넷 경유 없이 Boto3 호출만 허용해야 누수가 막힙니다.
- Guardrail은 콘텐츠 필터, PII 마스킹, 토픽 차단, 워드 필터 4종을 모두 켜고, 버전 태깅해서 회귀 테스트하는 습관이 중요합니다.
- 실무 사고의 80%는 “너무 넓은 권한 + 모델 ID 미제한 + 로깅 미적용” 셋이 겹쳐서 발생합니다.
- Azure OpenAI와 Vertex AI 대비 Bedrock은 VPC·IAM 통합 깊이에서 우위, 콘텐츠 정책 디테일에서는 Azure가 앞섭니다.
엔터프라이즈 Bedrock 보안의 3대 축
엔터프라이즈 도입 시 직면하는 3대 보안 위협
엔터프라이즈 환경에서 Bedrock을 그대로 쓰면 세 가지 위협에 노출됩니다. 첫째, 프롬프트 내 PII와 사내 기밀이 모델 Provider의 학습 파이프라인으로 흘러 들어가는 우려가 있어요. 둘째, 개발자가 콘솔에서 마음대로 고가 모델(예: Claude Opus 4)을 호출해 청구서가 폭증하는 경우고요. 셋째, 유해하거나 규정 위반 응답이 그대로 고객 화면에 노출되는 리스크입니다. 이 셋을 동시에 막으려면 단일 기능이 아니라 IAM·네트워크·콘텐츠 정책이 직조된 아키텍처가 필요합니다.
Bedrock 보안 레이어가 일반 SaaS LLM과 다른 점
Bedrock은 AWS의 IAM, VPC, KMS, CloudTrail, CloudWatch와 네이티브로 통합되기 때문에, 기존에 EC2나 S3에 깔아둔 보안 토대를 그대로 재사용할 수 있습니다. 다시 말해 “이미 검증된 보안 통제 위에 LLM을 얹는 구조”가 만들어지는 셈이죠. 반면 SaaS형 LLM은 별도 콘솔, 별도 권한 체계, 별도 감사 로그를 운영해야 해서 보안팀의 가시성이 끊기는 단점이 있습니다.
💡 Bedrock 아키텍처 설계 꿀팁
- 보안 3축을 하나의 CloudFormation 스택으로 묶어 버전 관리하면, 감사 시 “언제 어떤 정책이 적용됐는지” 한 줄로 추적됩니다.
IAM 권한 설계와 최소 권한 원칙
최소 권한 원칙을 코드로 구현하기
Bedrock IAM 정책의 출발점은 허용 모델 ID를 ARN 레벨로 화이트리스트하는 것입니다. 예를 들어 Claude Sonnet 4만 허용하고 싶다면 arn:aws:bedrock:ap-northeast-2::foundation-model/anthropic.claude-sonnet-4- 패턴으로 자르고, Opus나 외부 모델은 아예 매치되지 않게 설계합니다. 리소스 정책에는 “bedrock:InvokeModel”, “bedrock:InvokeModelWithResponseStream” 두 액션만 부여하고, “bedrock:CreateModelCustomizationJob” 같은 관리 권한은 별도 역할로 분리하는 게 핵심이에요.
서비스 제어 정책과 권한 경계의 조합
계정 단위 통제는 SCP(서비스 제어 정책)로, 역할 단위 상한은 permissions boundary로 잡습니다. SCP에서 “bedrock:InvokeModel” 호출 리전을 ap-northeast-2로 봉인하고, boundary에서 개발자가 어떤 모델 ID까지 만질 수 있는지 결정하는 이중 잠금이 효과적입니다. 이렇게 하면 “잘못된 자격 증명으로 해외 리전 모델 호출” 같은 사고를 미연에 차단할 수 있거든요.
⚠️ IAM 설계 시 자주 발생하는 실수
- “액션: 바위: “처럼 모든 액션을 허용하면, 개발자가 실수로 커스텀 모델 fine-tuning을 트리거해 수백만 원의 훈련 비용이 발생할 수 있습니다.
VPC Endpoint로 트래픽 사설화하기
PrivateLink로 트래픽을 사설망에 가두기
Bedrock은 Interface VPC Endpoint(AWS PrivateLink)를 제공합니다. 엔터프라이즈 VPC 안에 엔드포인트용 ENI를 두고, 라우팅 테이블에서 인터넷 게이트웨이 경로를 차단하면 모든 호출이 AWS 백본 내부에서만 흐릅니다. 이렇게 하면 프롬프트가 평문으로 외부 인터넷을 타지 않으니 통신 구간 암호화와 데이터 레지던시를 동시에 만족할 수 있어요.
VPC Endpoint 정책 세부 설정
엔드포인트 정책에서 Principal을 특정 IAM 역할로 제한하고, 호출 가능한 모델 ARN까지 좁히면 네트워크 + 자격증명 이중 검증을 받을 수 있습니다. 동시에 보안 그룹은 443 포트만 VPC 내부 CIDR에 개방하고, Flow Logs를 S3로 장기 저장하도록 설정하면 누가 무엇을 보냈는지 1년 단위로 추적 가능하거든요. 이 패턴은 금융권·공공기관 컴플라이언스 심사에서도 자주 요구되는 구성이에요.
Guardrail 정책 엔진 구성 전략
콘텐츠 필터링과 PII 마스킹
Bedrock Guardrail의 가장 큰 가치는 입력(input)과 출력(output) 양쪽에 필터를 동시에 적용할 수 있다는 점입니다. 콘텐츠 필터는 Hate, Insults, Sexual, Violence, Misconduct, Prompt Attack 6개 카테고리를 강도별로 설정하고, Sensitive Information Filter로는 주민등록번호·여권번호·카드번호·이메일·IP·전화번호 같은 PII 패턴을 자동 마스킹할 수 있어요. 마스킹 정책은 “차단(block)”과 “익명화(anonymize)” 두 모드 중 선택하는데, 고객 응대용 챗봇은 익명화, 내부 분석용은 차단이 일반적입니다.
토픽 제한과 워드 필터 설정
토픽 정책은 자연어로 금지 주제를 정의하면 모델이 그 의도를 추론해 거부합니다. 예를 들어 “의료 진단, 법률 자문, 투자 권유” 같은 영역을 입력하면, 모델이 사용자 요청이 그 주제에 해당할 때 응답을 거절하는 구조예요. 워드 필터는 비속어·경쟁사명·내부 코드네임 같은 정확한 문자열 매칭을 처리하고, 버전 태깅을 적용해 정책 변경 시 회귀 테스트를 자동화하면 컴플라이언스 리스크가 크게 줄어듭니다.
실무자가 겪는 실패 사례와 해결 노하우
실제 사고 사례 — 권한 폭주로 인한 비용 폭탄
한 금융사 PoC 단계에서 개발자 IAM 역할에 “bedrock:” 권한을 부여한 적이 있었어요. 별 문제 없다가 내부 해커톤에서 한 참가자가 무한 루프 스크립트를 짜 Opus 4 모델을 6시간 동안 18만 회 호출한 사연이 더라고요. 결과적으로 한 달치 PoC 예산을 하루 만에 소진하고, 심지어 모델 응답을 캐싱하지 않아 동일한 질문이 반복 호출되는 비효율까지 겹쳤습니다. 이 사례는 “권한을 막을 줄 몰랐던 보안팀”과 “비용 가드를 걸 줄 몰랐던 개발팀”의 사각지대가 만든 전형적인 사고입니다.
사고를 막은 4단계 점검 루틴
저희가 이후 표준으로 삼은 루틴은 다음 네 단계입니다. 첫째, 모델 ARN 화이트리스트를 IAM 정책에 하드코딩하고, 둘째, AWS Budgets 알림을 모델별·팀별로 분리 설정합니다. 셋째, Converse API 호출 시 prompt caching을 켜고 동일 prefix를 재활용하도록 강제하고요. 넷째, CloudTrail과 Guardrail 위반 이벤트를 EventBridge → Slack으로 라우팅해 실시간 알림을 만듭니다. 이 네 가지를 IaC 템플릿으로 묶어두면 신규 프로젝트가 생길 때 10분 만에 안전한 베이스라인이 깔리거든요.
💡 사고 예방 꿀팁
- “허용 모델 ARN + 일일 토큰 상한 + Guardrail 필수 적용” 세 가지를 SCP 레벨에서 강제하면, 신규 계정·신규 역할이 생겨도 같은 안전 장치가 자동 적용됩니다.
Azure OpenAI·Vertex AI와의 보안 아키텍처 비교
3대 플랫폼 보안 기능 비교
엔터프라이즈 LLM 도입 시 자주 비교되는 Amazon Bedrock, Azure OpenAI Service, Google Vertex AI의 보안 기능을 항목별로 정리했습니다. 같은 “프라이빗 LLM”이라도 어디에 강한지가 확연히 다르거든요. 아래 표를 기준으로 자사 보안 요건에 가장 잘 맞는 플랫폼을 골라 보시기 바랍니다.
| 보안 항목 | Amazon Bedrock | Azure OpenAI Service | Google Vertex AI |
|---|---|---|---|
| 권한 모델 | IAM + SCP + 권한 경계 | Entra ID(Azure AD) RBAC | IAM + Org Policy Constraints |
| 네트워크 격리 | Interface VPC Endpoint(PrivateLink) | Private Endpoint + VNet 통합 | Private Service Connect |
| 콘텐츠 정책 엔진 | Bedrock Guardrail(필터·PII·토픽) | Azure AI Content Safety + 책임 있는 AI 정책 | Safety Filter + Model Armor |
| 암호화 키 관리 | KMS / BYOK(고객 관리형 키) | Customer-Managed Keys + HSM | CMEK + Cloud EKM |
| 감사 로그 | CloudTrail + CloudWatch + S3 장기 보관 | Azure Monitor + Log Analytics | Cloud Audit Logs + Cloud Logging |
| 데이터 학습 활용 기본값 | 미사용(opt-out 가능) | 미사용(명시적 opt-in 필요) | 미사용(opt-out 가능) |
| 데이터 레지던시 옵션 | 리전 고정 + 리전 간 복제 비활성 기본 | 리전 고정 + Data Boundary 정책 | 리전 고정 + Sovereign Controls |
Bedrock만의 차별화된 통찰
표에서 드러나듯 Bedrock의 진짜 강점은 IAM·VPC·KMS·CloudTrail이 모두 같은 AWS 보안 체계 안에 종속되어 있다는 점이에요. 이미 AWS 보안 베이스라인을 구축한 조직은 별도 학습 없이 그대로 적용할 수 있고, 권한 경계 + SCP 조합은 타 플랫폼에선 구현이 복잡한 부분입니다. 반면 콘텐츠 정책 디테일과 프롬프트 공격 방어 카탈로그는 Azure AI Content Safety가 더 풍부한 편이라, 금융·의료처럼 콘텐츠 규제가 까다로운 도메인은 Azure와의 하이브리드 운영을 고려해 볼 만합니다.
자주 묻는 질문
Q. Bedrock Guardrail은 모든 모델에 적용되나요?
A. 주요 Anthropic Claude, Meta Llama, Mistral, Amazon Titan, Cohere Command 모델군에 적용되며, 커스텀 파인튜닝 모델에도 동일 가드레일 ID를 연결할 수 있습니다. 다만 모델별로 토픽 추론 품질이 미세하게 다르니, 가드레일 버전 출시 후 반드시 회귀 테스트를 돌려 보는 걸 권합니다.
Q. VPC Endpoint만 켜면 인터넷 노출이 완전히 차단되나요?
A. 트래픽 경로 자체는 사설화가 되지만, 애플리케이션 코드에서 외부 SDK를 호출하거나 EC2 메타데이터를 통해 자격증명을 탈취당하면 다른 경로로 새어 나갈 수 있습니다. Endpoint 정책 + 보안 그룹 + IMDSv2 강제 + IAM 권한 경계를 함께 적용해야 비로소 닫힌 방어선이 완성됩니다.
Q. 엔터프라이즈 계약에서 데이터 학습 비활용을 어떻게 보장하나요?
A. AWS 콘솔에서 “Model invocation logging”을 비활성화하고, AWS 계정 팀을 통해 “AWS AI Service Opt-Out Policy”에 가입하면 입력·출력 데이터가 모델 개선에 사용되지 않습니다. 추가로 DPA(데이터 처리 부속서) 사본을 법무팀에 제출받아 계약상 근거를 확보해 두는 게 안전합니다.
Q. 멀티 리전 DR 구성 시 가드레일 정책도 동기화해야 하나요?
A. 네, 가드레일 ID와 버전은 리전별로 별도 리소스이기 때문에 DR 리전에 동일 정책을 재배포해야 합니다. IaC 템플릿에서 가드레일 ARN을 리전 변수로 받아 동일 설정을 배포하고, EventBridge 크로스 리전 이벤트로 위반 로그를 중앙 SIEM에 모으면 일관성이 유지됩니다.
결국 엔터프라이즈 Bedrock 보안은 “한 사람이 세 가지 정책(IAM·네트워크·Guardrail)을 동시에 이해하고 운영할 수 있는가”의 문제로 귀결됩니다. 처음부터 CloudFormation·CDK 같은 IaC로 세 통제를 한 스택에 묶어 배포하고, 위반 이벤트를 자동 알림으로 받게 설계해 두면, 신규 서비스가 늘어나도 같은 안전 수준을 유지할 수 있습니다. 다음 단계로는 가드레일 회귀 테스트 자동화와 프롬프트 인젝션 모의 훈련을 같은 IaC 파이프라인에 넣는 걸 추천드립니다. 보안은 한 번 설계해 놓고 끝나는 게 아니라, 모델과 정책이 진화하는 동안 함께 진화해야 하거든요.
본 글이 참고하는 Amazon Bedrock·Azure OpenAI·Vertex AI의 보안 기능과 가격 정책은 서비스 업데이트에 따라 변경될 수 있습니다. 실제 아키텍처 도입 전에는 반드시 각 클라우드 Provider의 공식 문서와 보안 권고 가이드를 다시 확인하시고, 법무·컴플라이언스 검토를 거친 뒤 적용하시기 바랍니다.
