[인프라진단] #CA-19 가상 리소스 이상징후 알림 설정

1. 항목 설명

 

클라우드 가상 리소스의 장애·보안 이상징후를 탐지하고 담당자에게 알림이 전달되도록 설정되어 있는지 점검하는 항목입니다.

 

판단 기준은 조직 정책에 따라 이상징후 알림이 설정된 경우 양호, 설정되지 않은 경우 취약입니다.

 

2026 가이드 근거

 

출처: 과학기술정보통신부·한국인터넷진흥원, 「2026 주요정보통신기반시설 기술적 취약점 분석·평가 방법 상세가이드」, CA-19, p.872. 본 게시글은 위 가이드의 판단 기준을 참고하여 작성했으며, 진단 결과와 증적은 개인 실습 환경에서 직접 수집했습니다.

 

2. 점검 목적

 

가용성 저하, 비정상 사용량과 보안 이벤트를 빠르게 인지해 대응 지연으로 인한 피해 확산을 줄이는 것이 목적입니다.

 

3. 실습 환경

 

• 클라우드: 개인 AWS 실습 계정
• 작업 도구: AWS Management Console, AWS CloudShell, AWS CLI
• 탐지 방식: CA/Lab 네임스페이스의 사용자 지정 보안 이상징후 지표
• 경보: CloudWatch 임계값 경보, 작업 활성화
• 전달 경로: SNS 주제 → 전용 비공개 SQS 큐
• 시험 방법: 지표값 1을 게시해 ALARM 전이와 메시지 1건 전달 확인
• 비용 주의: 사용자 지정 지표, 경보, SNS·SQS 요청은 계정 플랜과 사용량에 따라 비용 발생 가능

 

실습·비용·안전 고지

 

실습에서는 외부 이메일 주소를 사용하지 않고 SQS를 알림 수신 대상으로 사용했습니다. 콘솔 캡처 시점에는 누락 데이터를 정상으로 처리하는 설정 때문에 현재 상태가 정상으로 돌아왔지만, 그래프의 경보 구간과 CLI 이행 증적에서 ALARM 전이와 메시지 전달을 확인했습니다.

 

4. 취약 상태 구성

 

실습 네임스페이스의 경보, SNS 주제와 전용 SQS 수신 큐를 조회해 이상징후 탐지·전달 구성이 없는 상태를 확인합니다.

 

aws cloudwatch describe-alarms --alarm-name-prefix <CA19_PREFIX>
aws sns list-topics
aws sqs list-queues --queue-name-prefix <CA19_PREFIX>

 

지표만 수집하고 경보와 전달 대상을 연결하지 않으면 담당자가 콘솔을 직접 확인할 때까지 이상징후를 놓칠 수 있습니다.

 

5. 최초진단 결과

 

• 최초진단 판정: 취약
• 실제 확인 결과: CA-19용 CloudWatch 경보 없음
• 실제 확인 결과: CA-19용 SNS 주제 없음
• 실제 확인 결과: CA-19용 SQS 알림 수신 큐 없음
• 영향: 이상징후가 발생해도 자동 전달되는 경로가 없음
• 실제 최초진단 증적 파일: ca11_ca19_initial_diagnosis.txt

 

 

6. 조치 방법

 

SNS 주제와 수신 큐를 만들고 큐 정책으로 해당 주제의 메시지만 허용한 뒤 CloudWatch 경보 작업에 SNS를 연결합니다.

 

aws sns create-topic --name <ALERT_TOPIC>
aws sqs create-queue --queue-name <ALERT_QUEUE>
aws sns subscribe \
  --topic-arn <SNS_TOPIC_ARN> \
  --protocol sqs \
  --notification-endpoint <SQS_QUEUE_ARN>

aws cloudwatch put-metric-alarm \
  --alarm-name <ALARM_NAME> \
  --namespace CA/Lab \
  --metric-name SecurityAnomalyCount \
  --statistic Sum --period 60 --evaluation-periods 1 \
  --threshold 1 --comparison-operator GreaterThanOrEqualToThreshold \
  --treat-missing-data notBreaching \
  --alarm-actions <SNS_TOPIC_ARN>

aws cloudwatch put-metric-data \
  --namespace CA/Lab \
  --metric-data MetricName=SecurityAnomalyCount,Value=1,Unit=Count

 

클라우드 콘솔 경로: CloudWatch → 경보 → 모든 경보 → CA-19 전용 경보

 

 

UI 증적 수집(2026-08-25): 실제 CloudWatch 콘솔 그래프에서 시험 지표와 짧은 경보 구간을 확인했습니다. 현재 정상 표시는 누락 데이터를 정상으로 처리한 이후 상태입니다.

 

7. 이행진단 결과

 

• 이행진단 판정: 양호
• 경보 시험: SecurityAnomalyCount=1 게시 후 상태 ALARM
• 경보 작업: 활성화
• 전달 구성: SNS 주제에 SQS 프로토콜 구독 연결
• 전달 시험: SQS ApproximateNumberOfMessages=1 확인
• 콘솔 시점: 시험 데이터 이후 누락 값을 정상으로 처리해 현재 상태는 OK
• 실제 이행진단 증적 파일: ca11_ca19_after_diagnosis.txt

 

 

8. 실무 주의사항

 

경보 수가 많거나 임계값이 부정확하면 반복 알림으로 실제 사고를 놓칠 수 있습니다. 반대로 누락 데이터를 정상으로 처리하면 지표 수집 중단이 감춰질 수 있으므로 지표 특성별 설정이 필요합니다.

 

컨설턴트 조언

 

• 가용성, 인증 실패, 권한 변경, 퍼블릭 노출, 비용 급증 등 위험 시나리오별로 탐지 지표와 담당자를 연결합니다.
• 경보 이름, 심각도, 서비스 소유자, 업무 영향, 대시보드와 실행 절차 링크를 알림 본문에 포함합니다.
• 메일·메신저·티켓 시스템 등 실제 채널의 전달 성공과 야간·휴일 에스컬레이션을 정기적으로 시험합니다.
• 경보 상태뿐 아니라 데이터 누락, SNS 전달 실패, 구독 해제와 수신 채널 장애도 별도 모니터링합니다.
• 초기 임계값은 운영 데이터로 조정하고 오탐·미탐 기록을 남겨 튜닝하되 고위험 경보를 편의상 비활성화하지 않습니다.

 

9. 마무리

 

이상징후 알림은 경보 객체가 존재하는 것보다 실제 상태 전이와 수신 채널 전달이 중요합니다. 이번 실습에서는 CloudWatch에서 SNS를 거쳐 SQS까지 메시지 1건이 도착하는 전 과정을 확인했습니다.