lhywk 님의 블로그

AWS Security Hub 본문

AWS

AWS Security Hub

lhywk 2026. 5. 11. 14:42

 

들어가며

소규모 아키텍처에서는 CloudWatch Alarm + SNS로 이상 징후를 이메일로 받는 구조가 충분히 효과적입니다. 하지만 계정 수가 늘고, 서비스가 다양해지고, 컴플라이언스 요건이 생기는 중대규모 환경에서는 근본적인 질문이 생깁니다.

"GuardDuty, Inspector, Macie, Config, Access Analyzer… 각각 콘솔을 따로 봐야 하나? 이 findings들을 어떻게 한 곳에서 관리하지?"

그 답이 바로 AWS Security Hub입니다. 이 글에서는 Security Hub의 개념부터 최신 진화 방향, 멀티 계정 아키텍처, 실전 자동화까지 체계적으로 정리합니다.

1. Security Hub가 무엇인지, 먼저 정확히 이해하자

1.1 탄생 배경: "보안 시그널이 너무 분산되어 있다"

AWS에는 목적별 보안 서비스가 많습니다.

서비스 역할
Amazon GuardDuty 위협 탐지 (비정상 API 호출, 네트워크 이상 등)
Amazon Inspector 취약점 관리 (EC2 CVE, ECR 이미지 스캔)
Amazon Macie 민감 데이터 탐지 (S3 내 PII 등)
IAM Access Analyzer 외부에 노출된 리소스 탐지
AWS Config 리소스 구성 변경 추적 및 규정 준수 평가

각 서비스가 개별 콘솔에서 findings를 생성합니다. 10개 계정, 5개 리전 환경이라면 모니터링 포인트가 기하급수적으로 늘어납니다. 이 문제를 해결하기 위해 Security Hub가 만들어졌습니다.

1.2 Security Hub의 핵심 역할 3가지

[분산된 보안 서비스들]          [Security Hub]           [대응]
GuardDuty  ────────────┐
Inspector  ────────────┤──→  집계 + 정규화  ──→  우선순위 기반 대응
Macie      ────────────┤     상관관계 분석        EventBridge 자동화
Config     ────────────┤     통합 가시성          SIEM/SOAR 연동
3rd-party  ────────────┘

1. 통합 집계: 모든 findings를 ASFF(AWS Security Finding Format)로 정규화
2. 보안 상태 평가: CIS, PCI DSS, NIST 등 컴플라이언스 기준으로 자동 점검
3. 자동화 연동: EventBridge를 통한 자동 remediation 트리거

1.3 ASFF (AWS Security Finding Format)

Security Hub가 강력한 이유 중 하나는 모든 finding을 단일 포맷으로 정규화한다는 점입니다.

{
  "SchemaVersion": "2018-10-08",
  "Id": "account-id/region/finding-id",
  "ProductArn": "arn:aws:securityhub:ap-northeast-2::product/aws/guardduty",
  "GeneratorId": "arn:aws:guardduty:...",
  "AwsAccountId": "123456789012",
  "Types": ["TTPs/Initial Access/UnauthorizedAccess"],
  "Severity": {
    "Label": "HIGH",
    "Normalized": 70
  },
  "Resources": [...],
  "Compliance": {...}
}

GuardDuty finding이든, Inspector finding이든, 써드파티 SIEM finding이든 모두 동일한 스키마로 처리됩니다. 별도 파싱 로직 없이 단일 쿼리로 전체 보안 이벤트를 조회할 수 있습니다.

 

2. Security Hub의 진화: CSPM → Unified Security Solution

2025년 기준으로 Security Hub는 단순한 findings 집계 도구를 넘어 대규모 전환을 거쳤습니다.

2.1 브랜드 분리: Security Hub CSPM vs. Security Hub (통합 솔루션)

구분 내용
Security Hub CSPM 기존 Security Hub의 핵심 기능 — 보안 표준 점검, findings 집계, 컴플라이언스 평가
AWS Security Hub (통합) CSPM + GuardDuty + Inspector + Macie를 하나의 콘솔에서 통합 운영. 신호 간 자동 상관관계 분석 추가

쉽게 말하면, Security Hub CSPM은 이제 더 큰 Security Hub 통합 솔루션의 일부가 되었습니다.

2.2 핵심 신기능: Near Real-Time Risk Analytics

기존에는 GuardDuty finding과 Inspector finding이 각각 따로 존재했습니다. 이제는 Security Hub가 이 신호들을 자동으로 상관관계 분석하여 하나의 actionable insight로 만들어줍니다.

예시 시나리오:

[기존 방식]
GuardDuty: "EC2 인스턴스에서 비정상 API 호출 탐지" (별도 콘솔)
Inspector:  "동일 EC2에 CVE-2024-XXXX 취약점 존재" (별도 콘솔)
Macie:      "연결된 S3 버킷에 PII 데이터 존재" (별도 콘솔)
→ 수동 상관관계 분석 필요, 우선순위 판단 어려움

[Security Hub 통합 방식 (2025~)]
Security Hub: "CRITICAL — 외부 노출된 취약한 EC2가 민감 데이터에 접근 중"
→ 자동 상관관계 분석 → 즉시 우선순위화 → EventBridge 자동화 트리거

2.3 2026년 3월 최신 업데이트: CloudWatch 통합

2026년 3월 31일 발표된 신기능으로, Security Hub CSPM findings를 CloudWatch Logs로 직접 수집할 수 있게 되었습니다.

  • ASFF 및 OCSF(Open Cybersecurity Schema Framework) 포맷 지원
  • CloudWatch Logs Insights로 finding 쿼리 가능
  • 조직 전체 또는 특정 계정에 자동 활성화 가능
  • S3 Tables 연동으로 장기 분석 지원

 

3. 멀티 계정 아키텍처: Security Hub를 제대로 설계하는 방법

Security Hub를 제대로 쓰려면 멀티 계정 + 멀티 리전 설계를 이해해야 합니다.

3.1 전체 계정 구조

Management Account (루트)
├── Security Account ← Security Hub 위임 관리자 (Delegated Admin)
│     ├── 전 계정 findings 집계 뷰
│     ├── 보안 표준 중앙 설정
│     └── EventBridge → Lambda 자동화
├── Log Archive Account
│     └── CloudTrail, VPC Flow Logs, Security Hub findings 장기 저장
├── Production Account
│     └── Security Hub 멤버 (findings 생성)
├── Staging Account
│     └── Security Hub 멤버
└── Development Account
      └── Security Hub 멤버

3.2 핵심 설정: Delegated Administrator

Management Account에서 Security Account를 Security Hub 위임 관리자로 지정합니다.

# Management Account에서 실행
aws organizations enable-aws-service-access \
  --service-principal securityhub.amazonaws.com

aws securityhub enable-organization-admin-account \
  --admin-account-id <security-account-id>

위임 관리자로 지정하면:

  • Management Account 자체는 보안 운영에서 분리 (최소 권한 원칙)
  • Security Account에서 전 멤버 계정의 findings를 통합 조회
  • 신규 계정 생성 시 자동으로 Security Hub 활성화

3.3 Cross-Region Aggregation: 리전 통합

Security Hub는 리전 단위 서비스입니다. 멀티 리전 환경이라면 반드시 집계 리전(Aggregation Region)을 설정해야 합니다.

[ap-northeast-2 (서울)] ← Aggregation Region (집계 리전)
      ↑
[us-east-1]  [ap-southeast-1]  [eu-west-1]
(Linked Regions)

모든 findings가 서울 리전으로 실시간 동기화
→ 단일 콘솔에서 전 리전 보안 현황 조회
→ EventBridge도 서울 리전 하나만 구독하면 됨

설정 방법 (Security Hub 관리자 계정, 집계 리전에서):

aws securityhub create-finding-aggregator \
  --region-linking-mode ALL_REGIONS \
  --region ap-northeast-2

3.4 Central Configuration Policy: 표준 일괄 적용

Security Hub CSPM에서 중요한 개념입니다. Security Account에서 보안 표준과 설정을 조직 전체에 일괄 적용할 수 있습니다.

Security Account (Delegated Admin)
└── Central Configuration Policy
      ├── 활성화 범위: 전체 OU 또는 특정 계정
      ├── 활성화 리전: 전체 또는 지정
      ├── 적용 표준: AWS FSBP (필수), CIS v3.0, PCI DSS v4.0
      └── 신규 계정: 자동 적용

이렇게 하면 새 계정이 생성될 때 자동으로 Security Hub가 활성화되고 표준이 적용됩니다. 수동으로 각 계정마다 설정할 필요가 없습니다.

4. Security Standards: 어떤 표준을 활성화해야 하나?

Security Hub CSPM은 리소스를 여러 보안 표준(Security Standards)에 따라 자동 평가합니다.

4.1 지원 표준 목록

표준 설명 권장 환경
AWS Foundational Security Best Practices (FSBP) AWS가 자체 개발한 기준. 273개 이상의 controls 모든 환경 필수
CIS AWS Foundations Benchmark v3.0 독립 기관 CIS의 AWS 보안 기준 금융, 공공기관
PCI DSS v4.0 카드 결제 데이터 보안 표준 핀테크, 커머스
NIST SP 800-53 Rev. 5 미국 정부 보안 프레임워크 공공, 규제 산업
ISO 27001:2022 국제 정보보안 관리 표준 글로벌 서비스

4.2 Security Score: 우선순위 판단 기준

각 표준에 대해 Security Hub는 Security Score (0~100점)를 계산합니다.

Security Score = 통과한 Controls 수 / 전체 활성 Controls 수 × 100

예시:
- 전체 활성 controls: 200개
- 통과(PASSED): 160개
- 실패(FAILED): 40개
- Score: 80점

점수는 멀티 계정, 멀티 리전 환경에서 집계 리전 기준으로 전체 통합 점수를 보여줍니다.

4.3 실전 팁: 표준 활성화 시 노이즈 관리

처음 Security Hub를 활성화하면 findings가 수백 개 쏟아집니다.

노이즈를 줄이는 핵심 전략:

1. 환경별 표준 분리 적용

Production OU  → AWS FSBP + CIS v3.0 + PCI DSS (엄격)
Development OU → AWS FSBP만 적용 (기본)

2. Automation Rules로 알려진 허용 항목 suppress

// 예: Dev 계정의 특정 S3 버킷 Public Access 경고 suppress
{
  "RuleName": "suppress-dev-public-bucket",
  "Criteria": {
    "AwsAccountId": ["dev-account-id"],
    "ResourceId": ["arn:aws:s3:::my-public-static-assets"]
  },
  "Actions": [{
    "Type": "FINDING_FIELDS_UPDATE",
    "FindingFieldsUpdate": {
      "Workflow": {"Status": "SUPPRESSED"},
      "Note": {"Text": "Intentionally public CDN bucket", "UpdatedBy": "security-team"}
    }
  }]
}

3. Severity 기반 필터링

CRITICAL → 즉시 대응 필요 (자동화 고려)
HIGH     → 24시간 내 대응
MEDIUM   → 7일 내 대응
LOW      → 스프린트 단위 정리
INFO     → 참고용, suppress 검토

 

 

5. Automation: EventBridge 연동으로 자동 대응 구현

Security Hub의 진짜 가치는 탐지 → 자동 대응 루프를 구현할 수 있다는 점입니다.

5.1 기본 자동화 아키텍처

Security Hub Finding 발생
         ↓
   EventBridge Rule
   (Finding 조건 매칭)
         ↓
    ┌────┴────┐
    ↓         ↓
 Lambda     SNS
(자동 수정)  (알림)
    ↓
Finding 상태 업데이트
(WORKFLOW_STATUS: RESOLVED)

5.2 실전 EventBridge Rule 예시

예시 1: S3 퍼블릭 접근 자동 차단

// EventBridge Rule Pattern
{
  "source": ["aws.securityhub"],
  "detail-type": ["Security Hub Findings - Imported"],
  "detail": {
    "findings": {
      "Severity": {"Label": ["CRITICAL", "HIGH"]},
      "Types": ["Software and Configuration Checks/AWS Security Best Practices/S3.2"],
      "Workflow": {"Status": ["NEW"]}
    }
  }
}

# Lambda 자동 수정 코드
import boto3

def lambda_handler(event, context):
    s3 = boto3.client('s3')
    finding = event['detail']['findings'][0]
    
    bucket_name = finding['Resources'][0]['Id'].split(':::')[1]
    
    # Public Access Block 강제 적용
    s3.put_public_access_block(
        Bucket=bucket_name,
        PublicAccessBlockConfiguration={
            'BlockPublicAcls': True,
            'IgnorePublicAcls': True,
            'BlockPublicPolicy': True,
            'RestrictPublicBuckets': True
        }
    )
    
    # Finding 상태 업데이트
    hub = boto3.client('securityhub')
    hub.batch_update_findings(
        FindingIdentifiers=[{
            'Id': finding['Id'],
            'ProductArn': finding['ProductArn']
        }],
        Workflow={'Status': 'RESOLVED'},
        Note={'Text': 'Auto-remediated by Lambda', 'UpdatedBy': 'auto-remediation'}
    )

예시 2: Security Group 0.0.0.0/0 인바운드 규칙 자동 제거

def lambda_handler(event, context):
    ec2 = boto3.client('ec2')
    finding = event['detail']['findings'][0]
    
    sg_id = finding['Resources'][0]['Id'].split('/')[-1]
    
    # 위험한 규칙 탐지 및 제거
    sg = ec2.describe_security_groups(GroupIds=[sg_id])['SecurityGroups'][0]
    
    for permission in sg['IpPermissions']:
        for ip_range in permission.get('IpRanges', []):
            if ip_range.get('CidrIp') == '0.0.0.0/0':
                ec2.revoke_security_group_ingress(
                    GroupId=sg_id,
                    IpPermissions=[permission]
                )

5.3 Automation Rules (코드 없이 Finding 조작)

2023년 이후 추가된 기능으로, Lambda 없이 콘솔에서 finding을 자동으로 업데이트할 수 있습니다.

Automation Rule 사용 사례:
① 특정 계정의 LOW findings → 자동 SUPPRESSED
② Critical finding → 심각도 레이블 변경 + 담당자 주석 추가
③ 특정 리소스 태그 기반으로 workflow status 자동 업데이트

Lambda 연동이 필요한 실제 remediation과 달리, finding 메타데이터 조작은 Automation Rules로 간단하게 처리할 수 있습니다.

 

6. 아키텍처에서의 Security Hub 포지셔닝

Security Account 중심 멀티 계정 구조에 Security Hub를 어떻게 연결할지 정리합니다.

6.1 보안 탐지 흐름 전체 그림

Production / Staging / Development Account (Member)
├── GuardDuty Finding    ──┐
├── Inspector Finding    ──┤──→ Security Hub CSPM (Security Account)
├── Macie Finding        ──┤         ↓
├── Access Analyzer      ──┘    상관관계 분석 & 우선순위화
└── Config NON_COMPLIANT ──→         ↓
                               EventBridge Rule (Security Account)
                                     ↓
                    ┌────────────────┼────────────────┐
                    ↓                ↓                ↓
                 Lambda           SNS Topic        SIEM/SOAR
              (자동 수정)      (보안담당자 알림)    (외부 연동)

 

 

7. 비용 구조: 예측 가능하게 관리하기

Security Hub는 활성화 자체는 무료 트라이얼(30일) 이후 과금됩니다.

7.1 Security Hub CSPM 과금 구조

과금 항목 기준
보안 검사(Security Checks) 계정당, 리전당 검사 수
Finding 수집(Finding Ingestion) 수신한 finding 건수
Automation Rules 규칙 평가 건수

실전 비용 최적화 팁:

  • Security Hub 통합 솔루션(GA, 2025년 12월~)은 GuardDuty, Inspector, Macie 요금을 통합 청구하여 비용 예측성 향상
  • Dev 계정에는 표준 수를 최소화하여 검사 수 줄이기
  • 불필요한 써드파티 finding 수집 비활성화 (downstream 연동 확인 후)

 

 

참고 자료

'AWS' 카테고리의 다른 글

LexisNexis 사고 사례 분석  (0) 2026.05.20
ERGO의 이벤트 기반 보안 자동 대응 아키텍처 분석  (0) 2026.05.09
AWS Organizations + SCP  (3) 2026.05.02
IAM Identity Center  (0) 2026.05.02
Directory Service  (0) 2026.05.02
'AWS' Related Articles more