ISMS-P 2.12.1 재해·재난 대비 안전조치 High Risk

재해·재난 대비 안전조치가 수립되어 있는가?

ISMS-P 2.12.1은 자연재해, 통신·전력 장애, 해킹 등 IT 재해·재난에 대비한 비상계획과 IT 재해복구체계를 요구합니다. 클라우드 환경에서는 Multi-AZ 고가용성과 Multi-Region DR 아키텍처를 통해 RTO/RPO 목표를 충족하는 업무연속성 체계를 구축해야 합니다.

📋

ISMS-P 인증 기준

ISMS-P 2.12.1 재해·재난 대비 안전조치 요구사항

2.12.1

재해·재난 대비 안전조치

인증 기준 정의

"자연재해, 통신·전력 장애, 해킹 등 IT 재해·재난 발생에 대비하여 비상계획을 수립하고, 비상시 업무연속성을 보장할 수 있도록 IT 재해복구체계를 마련하여야 한다."

📌 클라우드 환경 적용 포인트

Multi-AZ 고가용성 아키텍처 설계
Multi-Region DR(재해복구) 체계 구축
RTO/RPO 목표에 맞는 DR 전략 선택
AWS Elastic Disaster Recovery 활용
정기적 DR 훈련 및 테스트 자동화

⚠️ 미준수 시 심사 영향

결함: IT 재해복구 계획 미수립 또는 미흡
결함: RTO/RPO 목표 미설정
결함: DR 체계 미구축 (단일 AZ/리전)
결함: DR 훈련/테스트 장기간 미실시

📄 KISA ISMS-P 인증기준 안내서 ↗ ☁️ AWS DR 전략 가이드 ↗

📰

실제 보안 사고 사례

재해복구 체계 미흡으로 발생한 대규모 장애

2025.09

국가정보자원관리원 화재

대전 전산실 배터리 화재로 709개 서비스 영향. 858TB G드라이브 데이터 전량 소실. "3시간 내 복구" 약속했으나 4주 이상 소요. 액티브-액티브 이중화 미도입이 원인.

💡 교훈: 물리적 분리된 DR 사이트 필수, Active-Active 또는 Warm Standby 체계 구축

출처: 다음 뉴스 ↗

2022.10

판교 데이터센터 화재 (카카오)

SK C&C 판교 데이터센터 화재로 카카오 서비스 전면 중단. 카카오톡, 카카오맵 등 32개 서비스 127시간 장애. 단일 데이터센터 의존으로 4천만 사용자 피해.

💡 교훈: 핵심 서비스는 Multi-Site 또는 Multi-Region 이중화 필수

출처: ITWorld ↗

⚡

클라우드 환경의 위험

AWS에서 재해복구 체계가 미흡한 상황

AWS DR 전략 (RTO/RPO 기준)

전략	RTO	RPO	비용	설명
Backup & Restore	수 시간	수 시간	$	데이터만 백업, 필요시 인프라 재구축
Pilot Light	수십 분	분 단위	$$	최소 핵심 인프라 대기, 데이터 실시간 복제
Warm Standby	분 단위	초 단위	$$$	축소된 전체 환경 상시 가동
Active-Active	초 단위	0	$$$$	모든 리전에서 동시 서비스

단일 AZ 운영 (위험)

AZ-a

🏢

✕

AZ-b

-

↑ AZ 장애 = 서비스 전체 중단

단일 장애점 → RTO/RPO 목표 달성 불가

Multi-Region DR (권장)

Seoul

🏢

⟷

Tokyo

🏢

↑ 리전 장애 시 자동 페일오버

리전 간 복제 → RTO/RPO 목표 달성 가능

🚨

발견 사례: 프로덕션 인프라가 단일 AZ에만 배포됨

RDS multi_az = false, EC2가 단일 AZ에만 배포. Cross-Region DR 체계 없이 리전 장애 시 복구 불가 상태.

현재 상태 - 문제가 되는 설정

resource "aws_db_instance" "main" {
  identifier     = "production-db"
  engine         = "mysql"
  instance_class = "db.r5.large"

  multi_az       = false  # 단일 AZ
  # Cross-Region 복제 미설정
  # DR 체계 없음
}

ISMS-P 2.12.1 위반 사항

●

IT 재해복구체계 미구축 (단일 AZ)

●

RTO/RPO 목표 미설정

●

물리적 분리된 복구 사이트 부재

●

DR 훈련/테스트 절차 없음

🔍

사전 탐지 방안

IaC 코드 분석 기반 배포 전 점검

재해복구 아키텍처 탐지 로직

판단 조건	조건 값	결과
🗄️ RDS Multi-AZ	`multi_az = false`	High - 경고
🗄️ RDS Multi-AZ	`multi_az = true`	→ Cross-Region 복제 검사
🌏 Cross-Region 복제	`미설정` DR 사이트 없음	Critical - 차단 + 경고
🌏 Cross-Region 복제	`설정됨` 다른 리전으로 복제	→ DR 계획 검사
📋 DR 계획	`AWS Backup/DRS 미연결`	Medium - 경고
📋 DR 계획	`연결됨` DR 계획 적용	✓ 통과

🔔

사후 대응 방안

런타임 모니터링 및 이상행위 탐지

고가용성 설정 런타임 이벤트 대응 로직

판단 조건	조건 값	결과
📦 변경 유형	`IaC 배포 (Terraform)`	✓ 변경 이력만 저장
📦 변경 유형	`Drift 발생` 콘솔 직접 변경	→ 상세 분석
⚠️ 변경 내용 (Drift 발생 시)	`Multi-AZ 비활성화` multi_az → false	Critical - PagerDuty 호출
	`Cross-Region 복제 중지`	Critical - PagerDuty 호출
	`Auto Scaling 축소` min/max 감소	High - Slack 즉시 알림

모든 알림에 포함되는 정보

리소스 ARN 변경 전/후 설정 변경 주체 (IAM) Multi-Region DR 설정 가이드

✓

조치 가이드

즉시 적용 가능한 권장 설정

❌ 문제

단일 AZ 운영 + Cross-Region DR 체계 없음

✓ 적용

multi_az = true + Cross-Region 복제 + Route 53 페일오버

권장 설정 (복사하여 적용)

dr-architecture.tf

# RDS - Multi-AZ 고가용성 활성화
resource "aws_db_instance" "main" {
  identifier     = "production-db"
  engine         = "mysql"
  instance_class = "db.r5.large"

  multi_az               = true  # ✓ Multi-AZ 고가용성
  backup_retention_period = 7

  tags = {
    Name   = "production-db"
    ISMS-P = "2.12.1"
  }
}

# Cross-Region 읽기 복제본 (DR용)
resource "aws_db_instance" "dr_replica" {
  provider = aws.dr_region

  identifier          = "production-db-dr"
  replicate_source_db = aws_db_instance.main.arn
  instance_class      = "db.r5.large"

  tags = {
    Role   = "DR-Standby"
    ISMS-P = "2.12.1"
  }
}

# Route 53 Health Check 기반 자동 페일오버
resource "aws_route53_health_check" "primary" {
  fqdn              = "api.example.com"
  port              = 443
  type              = "HTTPS"
  resource_path     = "/health"
  failure_threshold = 3
  request_interval  = 30
}

resource "aws_route53_record" "api" {
  zone_id = aws_route53_zone.main.zone_id
  name    = "api.example.com"
  type    = "A"

  failover_routing_policy {
    type = "PRIMARY"
  }

  set_identifier  = "primary"
  health_check_id = aws_route53_health_check.primary.id

  alias {
    name                   = aws_lb.primary.dns_name
    zone_id                = aws_lb.primary.zone_id
    evaluate_target_health = true
  }
}

💡 핵심: multi_az = true 설정으로 AZ 장애에 대비하고, Cross-Region 복제본으로 리전 장애에 대비합니다. Route 53 Health Check를 통해 자동 페일오버를 구현하여 RTO를 최소화합니다. AWS Elastic Disaster Recovery(DRS)를 사용하면 지속적인 데이터 복제로 RPO를 초 단위로 낮출 수 있습니다.

📚 참고 자료

🌏 AWS DR 전략 가이드 ↗ 💾 AWS Elastic Disaster Recovery ↗ 🔒 AWS Multi-Region 아키텍처 ↗

📊

리포트 방안

ISMS-P 심사 증적 및 정기 보고

📋 진단 항목

Multi-AZ 활성화된 RDS 인스턴스 수
Cross-Region 복제 설정 현황
Auto Scaling 구성 상태
DR 훈련 수행 이력 (반기별)
RTO/RPO 목표 달성률

📅 리포트 주기

일간

가용성 설정 변경 알림

주간

DR 아키텍처 현황 요약

반기

DR 훈련 결과 + ISMS-P 증적

📤 발송 및 저장

발송 채널

Email Slack

저장소

S3 (5년 보관)

⚡

BSG 차별점

기존 도구가 놓치는 점검 영역

기존 도구 방식

단순 Multi-AZ 검사

multi_az = true 여부만 체크
rds_instance_multi_az_enabled 단순 비교
정적 분석 결과만 출력

한계: Cross-Region DR 검사 없음, RTO/RPO 목표 미점검

BSG 접근 방식

Multi-AZ + Cross-Region + DR 계획 통합 점검

IaC 코드 분석 기반 DR 아키텍처 검증
런타임 가용성 설정 변경 모니터링 + Drift 탐지
ISMS-P 2.9.3(백업 및 복구관리)과 통합 DR 체계 검증

차별점: 인증 기준 관점에서 탐지 → 조치 → 증적 전 과정 자동화

← Data Protection & Disaster Recovery로 돌아가기