AWS EventBridge 기반 보안 이벤트 오케스트레이션 구현하기

1. 배경

 

GuardDuty Finding 처리

 

AWS GuardDuty는 머신러닝 기반으로 위협을 탐지한다. 그러나 Finding이 발생했을 때 어떻게 대응할 것인가는 별개의 문제다. 특히 소규모 조직에서는 다음과 같은 현실적인 문제에 직면한다:

• 탐지 후 대응 지연: 담당자가 부재 중일 때 Finding 발견이 몇 시간 지연
• 수동 검증의 한계: 각 Finding마다 IP 평판을 수동으로 확인
• 일관성 없는 대응: 담당자마다 다른 판단 기준

이러한 문제를 해결하기 위해 자동화된 대응 파이프라인이 필요하다고 생각했고, AWS의 서버리스 서비스를 활용한 이벤트 기반 아키텍처를 설계해 보았다.

 

 

동기 vs 비동기 처리

보안 이벤트 처리에서 중요한 설계 결정 중 하나는 동기 처리 vs 비동기 처리다.

 

동기 처리 (Lambda 직접 호출):

GuardDuty → Lambda A → Lambda B → Lambda C

• 장점: 단순한 흐름, 디버깅 용이
• 단점: 단일 실패 지점, 타임아웃 누적, 확장성 제한

 

비동기 처리 (EventBridge):

GuardDuty → EventBridge → Lambda A
                        → Lambda B
                        → Lambda C

• 장점: 느슨한 결합, 병렬 처리, 확장 용이
• 단점: 디버깅 복잡, 이벤트 추적 필요

 

보안 자동화에서는 단일 장애로 전체 파이프라인이 멈춰서는 안 되고, 새로운 대응 로직을 쉽게 추가할 수 있어야 하므로 비동기 처리를 선택했다.

 

 

서버리스 아키텍처 선택 이유

EC2 기반 서버 대신 서버리스를 선택한 이유는 다음과 같다:

1. 비용 효율성: 이벤트 발생 시에만 과금 (월 예상 Finding 100건 → $3 미만)
2. 운영 부담 감소: 서버 패치, 모니터링 불필요
3. 자동 확장: Finding 급증 시에도 자동 처리
4. 고가용성: AWS 관리형 서비스의 SLA

 

---

 

2. 아키텍처 설계

 

전체 흐름

1️⃣ GuardDuty Finding
2️⃣ EventBridge Rule #1
      Pattern: GuardDuty IAM Findings
3️⃣ TI Lambda (평판 조회) - VirusTotal API, AbuseIPDB API
      Custom Event 발행
4️⃣ EventBridge Rule #2
      Pattern: ti-analysis-complete
5️⃣ Slack Lambda (알림 전송) - Webhook

 

 

Event Pattern 정의

 

Rule #1: GuardDuty Finding 필터링

 

{
  "source": ["aws.guardduty"],
  "detail-type": ["GuardDuty Finding"],
  "detail": {
    "type": [
      "UnauthorizedAccess:IAMUser/MaliciousIPCaller",
      "Discovery:IAMUser/AnomalousBehavior",
      "Impact:IAMUser/AnomalousBehavior"
    ],
    "severity": [
      { "numeric": [">=", 4.0] }
    ]
  }
}

 

• IAM 관련 Finding만 필터링
• Medium 이상 심각도 (4.0+)만 처리
• 불필요한 Lambda 실행 방지 → 비용 절감

 

Rule #2: TI 분석 완료 이벤트

 

{
  "source": ["custom.guardduty"],
  "detail-type": ["TI Analysis Complete"]
}

 

 

Lambda 체이닝 vs EventBridge 비교

Lambda 체이닝 방식:

def ti_lambda_handler(event, context):
    ti_result = analyze_threat_intelligence(event)
    
    # 다음 Lambda 직접 호출
    lambda_client.invoke(
        FunctionName='slack-lambda',
        InvocationType='Event',
        Payload=json.dumps(ti_result)
    )

문제점:

• TI Lambda가 Slack Lambda를 알아야 함 (강한 결합)
• 알림 대상 추가 시 TI Lambda 수정 필요
• 실패 시 재시도 로직 직접 구현

EventBridge 방식:

def ti_lambda_handler(event, context):
    ti_result = analyze_threat_intelligence(event)
    
    # Custom Event 발행
    eventbridge.put_events(
        Entries=[{
            'Source': 'custom.guardduty',
            'DetailType': 'TI Analysis Complete',
            'Detail': json.dumps(ti_result)
        }]
    )

장점:

• TI Lambda는 분석만 담당 (단일 책임)
• 새로운 구독자 추가 시 TI Lambda 수정 불필요
• EventBridge가 재시도, DLQ 등 처리

 

 

Custom Event 발행 전략

Custom Event 설계 시 고려사항:

1. Event 구조 표준화

{
  "version": "1.0",
  "finding_id": "abc123...",
  "timestamp": "2024-11-23T10:30:00Z",
  "source_ip": "61.135.22.10",
  "severity": 7.5,
  "ti_result": {
    "virustotal": {...},
    "abuseipdb": {...},
    "composite_score": 85.2,
    "threat_level": "HIGH"
  },
  "recommended_action": "block"
}

2. 버전 관리

• Event 구조 변경 시 하위 호환성 유지
• version 필드로 구독자가 파싱 방식 선택

3. 최소 정보 원칙

• 필요한 정보만 포함 (전체 GuardDuty Finding 포함 X)
• 구독자가 원본 필요 시 finding_id로 조회

 

---

 

3. 확장 및 개선 방향

 

다른 보안 서비스 통합

 

SecurityHub 통합:

{
  "source": ["aws.securityhub"],
  "detail-type": ["Security Hub Findings - Imported"],
  "detail": {
    "findings": {
      "Severity": {
        "Label": ["HIGH", "CRITICAL"]
      }
    }
  }
}

동일한 TI Lambda 재사용 가능 (IP 추출 로직만 추가)

 

Inspector 통합:

{
  "source": ["aws.inspector2"],
  "detail-type": ["Inspector2 Finding"]
}

 

Step Functions 고려

복잡한 워크플로우 (예: 관리자 승인 필요) 시:

GuardDuty → EventBridge → Step Functions
                           ├─ TI 조회
                           ├─ 위험도 판단
                           ├─ (HIGH) 자동 차단
                           └─ (MEDIUM) 승인 대기 → SNS

장점:

• 시각적 워크플로우
• 재시도 정책 세밀 제어
• 상태 추적 용이

단점:

• 비용 증가
• 복잡도 증가

현재는 EventBridge로 충분하지만, 향후 고려 가능

 

이벤트 추적 및 디버깅

CloudWatch Logs Insights 쿼리:

# 특정 Finding 추적
fields @timestamp, @message
| filter finding_id = "abc123..."
| sort @timestamp asc

 

X-Ray 통합:

from aws_xray_sdk.core import xray_recorder

@xray_recorder.capture('ti_analysis')
def lambda_handler(event, context):
    # X-Ray가 자동으로 EventBridge → Lambda 흐름 추적
    pass

 

---

 

4. 참고 자료

• AWS EventBridge 공식 문서
• GuardDuty Finding 형식
• 우아한형제들 - SOAR 구축 사례
• VirusTotal API
• AbuseIPDB API

 

 

---

 

마무리

 

EventBridge를 활용한 이벤트 기반 아키텍처는 보안 자동화에서 다음과 같은 이점을 제공한다:

1. 낮은 결합도: 각 Lambda가 독립적으로 동작
2. 확장성: 새로운 대응 로직 추가 용이
3. 비용 효율: 이벤트 발생 시에만 과금
4. 신뢰성: DLQ, 재시도 등 AWS 관리형 기능 활용

 

현재는 GuardDuty IAM Finding에 집중했지만, 동일한 패턴을 SecurityHub, Inspector, CloudTrail 등 다른 보안 서비스에도 적용할 수 있다.

대시보드 시각화가 포함된 전체 프로젝트 코드는 GitHub 저장소에서 확인할 수 있다.