서론 (Introduction)

수년 동안 AWS Security Hub는 제한적이긴 하지만 명확한 가정 하에 운영되어 왔습니다. 즉, 주요 역할은 AWS 리소스를 보호하는 것이었습니다. 만약 귀하의 조직이 거의 모든 엔터프라이즈 규모의 조직이 그러하듯 Microsoft Azure 또는 Google Cloud Platform에서 워크로드를 실행하고 있다면, 여러 네이티브 대시보드에 걸쳐 보안 태세 (Security Posture)를 관리하거나, 취약한 커스텀 데이터 수집 파이프라인 (Ingestion Pipelines)을 구축하거나, 혹은 값비싼 제3자 클라우드 보안 태세 관리 (CSPM) 도구에 비용을 지불하는 것 중 하나를 선택해야만 했습니다.

AWS가 Microsoft Azure를 AWS Security Hub에 네이티브로 통합하고 GuardDuty AI Protection을 동시에 출시함에 따라, 그 패러다임이 변화했습니다. 처음으로 AWS는 경쟁사 인프라로 보안 제어 평면 (Security Control Plane)을 네이티브하게 확장하는 동시에, 생성형 AI (Generative AI) 워크로드의 고유한 보안 과제를 해결하고 있습니다. 저는 이것이 멀티 클라우드 (Multi-cloud)가 일시적인 전환 상태가 아니라 현대 엔터프라이즈 아키텍처의 영구적인 현실임을 인정하는 AWS의 중대한 실용적 전환이라고 생각합니다.

이 글에서 저는 이러한 새로운 기능들의 근본적인 메커니즘을 분석하고, AWS 중심의 멀티 클라우드 모니터링의 기술적 트레이드오프 (Trade-offs)를 평가하며, 귀하의 환경에서 이러한 기능들을 어떻게 구현하고 운영할지에 대한 실행 가능한 지침을 제공할 것입니다.

AWS Security Hub는 GuardDuty AI Protection과 함께 Microsoft Azure에 대한 네이티브 멀티 클라우드 지원을 도입했습니다. 이 분석은 교차 클라우드 신뢰 (Cross-cloud trust)의 아키텍처 메커니즘과 보안을 탐구합니다

🔐 아키텍처의 변화: Security Hub 내 네이티브 Azure 통합 (Architectural Shift: Native Azure Integration in Security Hub)

네이티브 Azure 지원의 가치를 이해하기 위해서는 먼저 멀티 클라우드 보안 태세 관리 (Multi-cloud Security Posture Management)가 이전에 어떻게 이루어졌는지 살펴보아야 합니다. 역사적으로 Security Hub에서 Azure 보안 권장 사항을 확인하려면, Azure Security Center (현재 Microsoft Defender for Cloud) API를 폴링(poll)하고, JSON 페이로드(payload)를 파싱(parse)하며, 이를 AWS Security Finding Format (ASFF)에 매핑한 후 BatchImportFindings API를 통해 전송하는 Lambda 함수를 배포해야 했습니다. 이러한 패턴은 지연 시간(latency), 유지 관리 오버헤드(maintenance overhead), 그리고 서버리스 실행 제한 및 API 속도 제한(rate limiting)에 따른 장애 지점(failure points)을 발생시켰습니다.

AWS의 네이티브 통합은 AWS와 Azure 사이에 직접적인 연합 신뢰 관계 (federated trust relationship)를 구축함으로써 이러한 커스텀 파이프라인을 제거합니다. 이 통합은 OpenID Connect (OIDC) 및 Azure Active Directory (현재 Microsoft Entra ID) 엔터프라이즈 애플리케이션을 활용하여, AWS Security Hub가 사용자의 Azure 구독으로부터 구성 메타데이터를 읽을 수 있도록 권한을 부여합니다.

설정이 완료되면, Security Hub는 읽기 전용 API를 사용하여 CIS Microsoft Azure Foundations Benchmark와 같은 표준 보안 벤치마크를 기준으로 Azure 리소스 구성을 평가합니다. 평가 엔진은 AWS 컨트롤 플레인 (control plane) 내에서 실행되며, Azure 리소스 상태를 네이티브 ASFF 결과로 직접 변환합니다. 이는 Azure 가상 머신 (Virtual Machines), SQL 데이터베이스 (SQL Databases), 그리고 Entra ID 구성이 Amazon EC2 인스턴스, RDS 데이터베이스, IAM 정책과 함께 단일 콘솔에서 지속적으로 평가되고 통합됨을 의미합니다.

🤖 GuardDuty AI Protection: LLM 및 생성형 AI 파이프라인 보안

멀티 클라우드 포스처 관리 (Multi-cloud posture management)와 더불어, AWS는 GuardDuty AI Protection을 Security Hub에 직접 통합했습니다. 엔지니어링 팀이 Amazon Bedrock을 사용하여 대규모 언어 모델 (LLMs)을 빠르게 배포함에 따라, 보안 팀은 이러한 애플리케이션의 런타임 동작 (runtime behavior)에 대한 가시성을 확보하는 데 어려움을 겪어왔습니다. 기존의 네트워크 레벨 또는 호스트 레벨 침입 탐지 시스템 (Intrusion Detection Systems)은 프롬프트 인젝션 (prompt injection), 모델 응답을 통한 데이터 유출 (data exfiltration), 또는 비정상적인 API 소비 패턴과 같은 시맨틱 공격 (semantic attacks)을 탐지하지 못합니다.

GuardDuty AI Protection은 Amazon Bedrock API 호출 로그와 학습 데이터 또는 검색 증강 생성 (RAG) 벡터 임베딩 (vector embeddings)을 저장하는 기반 S3 버킷의 데이터 액세스 패턴을 지속적으로 모니터링함으로써 이 문제를 해결합니다. 이는 과거의 API 텔레메트리 (telemetry)를 기반으로 학습된 머신러닝 (machine learning) 모델을 사용하여 정상적인 사용자 및 애플리케이션 동작의 기준선 (baseline)을 설정합니다.

GuardDuty가 비정상적인 IP 주소로부터의 갑작스러운 모델 호출 급증이나 모델의 안전 가드레일 (safety guards)을 우회하려는 사용자 프롬프트와 같은 이상 징후를 탐지하면, 고충실도 (high-fidelity) 탐지 결과(finding)를 생성합니다. 이는 Security Hub와 네이티브하게 통합되어 있으므로, 이러한 탐지 결과는 자동으로 우선순위가 지정되고, 더 넓은 인프라 포스처 (infrastructure posture)와 상관관계가 분석되며, 후속 조치 (remediation)를 위해 ASFF 스키마로 매핑됩니다.

🏗️ 구현: 크로스 클라우드 신뢰 및 인제스션(Ingestion) 구성

네이티브 Azure 모니터링을 운영하려면 크로스 클라우드 신뢰 관계를 구성해야 합니다. 여기에는 Microsoft Entra ID에서 앱 등록 (App Registration)을 생성하고, 필요한 Azure Reader 역할을 부여하며, OIDC를 통해 해당 ID를 수용하도록 AWS Security Hub를 구성하는 과정이 포함됩니다.

신뢰 관계가 구축되면, Azure 탐지 결과(findings)가 수집되어 ASFF로 매핑됩니다. 아래는 Azure 가상 머신(Virtual Machine) 보안 탐지 결과가 ASFF에서 어떻게 표현되는지에 대한 예시입니다. 여러분의 다운스트림 보안 정보 및 이벤트 관리 (SIEM) 또는 보안 오케스트레이션, 자동화 및 대응 (SOAR) 플랫폼이 AWS 이외의 리소스 파티션(partitions)을 파싱할 수 있도록 업데이트되어야 하므로, 이 스키마를 면밀히 검토할 것을 권장합니다.

{
  "SchemaVersion": "2018-10-08",
  "Id": "azure/subscription-12345/resourceGroups/prod-rg/providers/Microsoft.Compute/virtualMachines/web-server-01/security-finding",
...

Partition 필드가 azure로 설정되어 있으며, Id는 표준 Azure 리소스 관리자 (ARM) 리소스 ID 형식을 사용한다는 점에 주목하십시오. 이러한 설계 덕분에 기존의 Security Hub 사용자 지정 작업(custom actions) 및 EventBridge 규칙을 사용하여 Azure 전용 탐지 결과를 올바른 엔지니어링 팀으로 라우팅할 수 있습니다.

🏗️ 운영상의 트레이드오프 및 멀티 클라우드 포스처 전략

Security Hub의 네이티브 멀티 클라우드 지원은 도구 환경을 단순화하지만, 기존 시스템을 폐기하기 전에 반드시 평가해야 할 몇 가지 전략적 트레이드오프(trade-offs)를 수반합니다.

통합의 비용

AWS Security Hub는 매월 처리된 보안 검사(security checks) 수에 따라 비용을 청구합니다. Azure 리소스를 수집할 때, 평가된 모든 Azure 정책이 이 볼륨에 포함됩니다. Azure 사용 규모가 큰 경우, Security Hub 평가 비용이 급격히 증가할 수 있습니다. 이를 전용 CSPM 도구의 라이선스 비용과 신중하게 비교하여 검토해야 합니다.

기능 동등성(Feature Parity)의 한계

AWS의 Azure 리소스 평가는 표준 CIS 벤치마크(CIS benchmarks)를 기반으로 합니다. 하지만 Microsoft Defender for Cloud는 AWS Security Hub가 네이티브하게 복제할 수 없는 심층적이고 독점적인 위협 인텔리전스(threat intelligence) 및 실시간 행동 분석(behavioral analytics)을 제공합니다. 만약 귀사의 Azure 사용 환경이 고도로 특화된 서비스(예: 고급 서비스 메시(service meshes)를 사용하는 Azure Kubernetes Service 또는 Azure Synapse Analytics 등)를 사용하고 있다면, 네이티브 AWS 통합은 기본적인 구성 점검(configuration checks)만을 제공할 수 있으며, 더 깊은 런타임 취약점(runtime vulnerabilities)을 놓칠 수 있습니다.

🎯 결론

Microsoft Azure 모니터링과 GuardDuty AI Protection을 Security Hub에 통합하기로 한 AWS의 결정은 매우 실용적인 진화입니다. 이는 보안 팀이 격리된 클라우드 사일로(silos)를 관리할 여유가 없으며, 생성형 AI(generative AI) 인프라를 보호하기 위해 맞춤형 파이프라인(bespoke pipelines)을 구축할 시간도 없다는 점을 인정한 것입니다.

저의 권장 사항은 하이브리드 접근 방식을 채택하는 것입니다. AWS를 주력으로 사용하면서 Azure를 보조적으로 사용하는 조직의 경우, 네이티브 Security Hub 통합은 중앙 집중식 가시성(centralized visibility)을 확보할 수 있는 우아하고 오버헤드가 적은 방법을 제공합니다. 우선 비운영(non-production) Azure 구독에 대해 OIDC 신뢰(OIDC trust)를 활성화하여 비용과 데이터 볼륨의 기준점(baseline)을 파악하는 동시에, 활성화된 Amazon Bedrock 파이프라인에 GuardDuty AI Protection을 적용하여 새롭게 등장하는 AI 워크로드(AI workloads)를 보호해야 합니다.

🔗 원문 게시지: ixuvo.com