AI를 위한 보안

1. 글을 쓰게 된 배경

• 최근 저의 고객들이 AI를 더 많이 사용하고, AI 플랫폼 (AI platform)을 구축하고 사용하는 사례가 늘어남에 따라, 이러한 새로운 기술들을 어떻게 제어하고 보안을 유지할 것인가에 대한 질문이 제기되었습니다. 이러한 실무적인 배경에서 이 문제에 대한 저의 생각과 조사 내용을 기록하고자 이 글을 작성하게 되었습니다.

2. 보안 역량 강화를 위한 AWS 제공 서비스 활용

2.1. IAM

• 중요한 것은 먼저 말하고 세 번 반복해야 합니다. 권한 부여 (Authorization)는 항상 최우선 순위로 고려되어야 하는 기준입니다.
• AWS IAM & IAM Roles: AI 에이전트 (AI Agent) 또는 노트북 (Notebook)이 필요한 데이터가 담긴 S3 버킷 (S3 bucket)에만 정확히 접근할 수 있도록 세부 권한 제어 (fine-grained access control)를 구성하여, 그 이상의 권한은 갖지 못하도록 보장합니다. AWS IAM Identity Center: AI 개발 팀을 위한 SSO 관리 및 중앙 집중식 권한 부여를 통해 조직의 액세스 정책 준수를 보장합니다.

2.2. 데이터 프라이버시 및 주권 (Data Privacy & Sovereignty)

• Amazon Macie: 데이터가 AI 학습 파이프라인 (pipeline)에 투입되기 전, S3 버킷에 포함된 민감한 데이터 (PII, 금융 데이터 등)를 자동으로 스캔하고 탐지합니다.
• AWS KMS (Key Management Service): 모든 데이터를 암호화합니다. 엔터프라이즈 (Enterprise) 아키텍처에서는 키의 수명 주기를 완전히 제어하기 위해 고객 관리 키 (Customer Managed Keys, CMK) 사용이 필수적입니다.
• AWS Clean Rooms: 원본 데이터를 공유하지 않으면서 외부 파트너와 ML 모델 학습 협업이 필요한 경우 매우 유용하며, 법적 준수성을 보장합니다. 참고 링크

2.3. 플랫폼 보안 및 DLP

• Amazon Bedrock (GenAI용): Bedrock의 아키텍처는 기본적으로 매우 보안이 강력합니다. 고객의 프롬프트 (Prompt) 데이터와 기업 데이터는 제공업체의 파운데이션 모델 (Foundation Models, Base Models)을 재학습시키는 데 절대 사용되지 않습니다. 이 데이터는 기업의 환경 내에 안전하게 머무릅니다.

• Amazon Bedrock Guardrails: 콘텐츠 필터링 (유해성, 혐오 표현 등)을 설정하고, 프롬프트 인젝션 (Prompt Injection, AI를 속이는 공격) 행위를 방지하며, AI의 답변이 사용자에게 전달되기 전에 개인 식별 정보 (PII)를 자동으로 숨기거나 삭제 (Redact)할 수 있는 서비스입니다.

• Amazon SageMaker (커스텀 ML용): Amazon VPC (Virtual Private Cloud) 내에서의 완전한 배포를 지원합니다. 관리자는 AWS PrivateLink를 사용하여 AI 모델로 호출되는 API가 공용 인터넷 (Public Internet)을 거치지 않도록 설정할 수 있으며, 이를 통해 데이터 교환이 항상 조직의 인프라 내에서 이루어지도록 보장합니다.

2.4. SOC/SIEM 통합

• AWS CloudTrail: 감사 (Audit) 및 사고 조사 프로세스를 위해 AI 서비스와 관련된 모든 API 호출 (누가, 언제, 어떤 IP에서 어떤 모델을 호출했는지)을 기록합니다.

• Amazon GuardDuty: 비정상적인 행위 (위협 탐지, Threat Detection)를 감지합니다. 예를 들어, 학습 데이터 (Training Data)가 포함된 S3 버킷에서 대량의 데이터가 다운로드되거나, 의심스러운 IP에서 Bedrock API가 호출되는 경우를 탐지합니다.

• AWS Security Hub: Macie, GuardDuty의 모든 보안 경고를 통합하고, SageMaker/Bedrock의 설정이 베스트 프랙티스 (Best Practice)를 준수하고 있는지 CSPM (Cloud Security Posture Management) 관점에서 점검합니다. 이 모든 로그는 SOC 팀이 처리할 수 있도록 기업의 SIEM 플랫폼으로 전달될 수 있습니다.

3. 보안 업체 서비스 사용

3.1. 에지 계층 (Edge Layer): 네트워크 경계 및 API 보호
솔루션: F5 Distributed Cloud (DDoS, Bot Defense, API Security).

AWS에서의 구현:

• SaaS 모델: Route 53을 F5 XC Global Network로 연결하여, 트래픽이 AWS ALB 또는 API Gateway에 도달하기 전에 대용량 DDoS (Volumetric DDoS)를 필터링하고 데이터 크롤링 봇 (Bot)을 차단합니다.

• VPC Hub 모델: Security VPC에 F5 Customer Edge (CE) 노드 (EC2 형태)를 배포합니다. AWS Transit Gateway와 결합하여 집중형 API 차단 지점으로 활용하며, AI 워크로드가 포함된 스포크(Spoke) VPC로 들어오는 모든 트래픽을 모니터링합니다.

3.2. 마이크로서비스 계층 (Microservices Layer): 내부 컴퓨팅 클러스터 보호
솔루션: F5 WAF for NGINX.

AWS에서의 구현:

• Amazon EKS 위에 NGINX Plus Ingress Controller를 설치합니다.
• 애플리케이션 로직을 겨냥한 악성 페이로드 (Payload)를 차단하기 위해 Ingress 또는 사이드카 (Sidecar)에 NGINX App Protect (WAF) 모듈을 삽입합니다.
• 마이크로서비스 간의 동서 트래픽 (East-West traffic) (예: Backend App ➔ Vector DB)에 대해 mTLS 암호화를 강제하기 위해 NGINX를 사용합니다.

3.3. 모델 계층 (Model Layer): LLM 상호작용 제어
솔루션: F5 AI Guardrails, F5 AI Red Team.

AWS에서의 구현:

• F5 AI Guardrails (Inline): 백엔드 애플리케이션과 Amazon Bedrock / SageMaker 사이의 프록시 (Proxy)로 구성합니다. 실시간 스캐닝을 통해 프롬프트 인젝션 (Prompt Injection)을 차단하고, LLM으로 전송되기 전에 PII/DLP 데이터를 자동으로 마스킹 (Masking)하는 역할을 수행합니다.

• F5 AI Red Team (DevSecOps): AWS CodePipeline 또는 CI/CD 파이프라인에 API를 통해 통합합니다. 스테이징 (Staging) 환경에 대해 탈옥 (Jailbreak) 공격 시나리오를 자동으로 실행하고, 방어 규칙 (Active Guardrails)을 F5 XC 또는 NGINX로 자동 푸시합니다.

** 연구가 계속 진행 중입니다 **