ISMS-P 3.4.2 처리목적 달성 후 보유 시 조치 High Risk

처리목적 달성 후 보유 조치가 적절한가?

ISMS-P 3.4.2는 법령에 따라 개인정보를 보존해야 할 경우, 최소한의 항목으로 제한하고 다른 개인정보와 분리하여 저장·관리하도록 요구합니다. 클라우드 환경에서는 별도 버킷 + Object Lock + 접근권한 최소화로 구현해야 합니다.

📋

ISMS-P 인증 기준

ISMS-P 3.4.2 처리목적 달성 후 보유 시 조치 요구사항

3.4.2

처리목적 달성 후 보유 시 조치

인증 기준 정의

"개인정보의 보유기간 경과 또는 처리목적 달성 후에도 관련 법령 등에 따라 파기하지 아니하고 보존하는 경우에는 해당 목적에 필요한 최소한의 항목으로 제한하고 다른 개인정보와 분리하여 저장·관리하여야 한다."

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

S3 별도 버킷으로 물리적/논리적 분리 저장
S3 Object Lock (Compliance Mode)으로 무결성 보장
IAM 정책으로 접근권한 최소 인원 제한
S3 Glacier로 장기 보관 비용 최적화
법정 보존기간 경과 후 자동 파기 연계 (3.4.1)

⚠️ 미준수 시 심사 영향

결함: 법정 보존 개인정보 미분리 저장
결함: 분리 저장 후 접근권한 미분리
결함: 법정 보존기간 초과 장기 보관
과태료: 1천만원 이하 (개인정보 보호법 제75조)

📄 KISA ISMS-P 인증기준 안내서 ↗ 📖 ISMS-P 3.4.2 상세 안내 ↗

📰

실제 보안 사고 사례

분리 보관 미이행으로 발생한 개인정보 유출 사례

2025.12

쿠팡 탈퇴회원 정보 분리보관 미이행

탈퇴 2년 경과한 회원의 개인정보까지 유출. 전자상거래법상 5년 보존 의무 데이터는 활성 회원 정보와 분리 저장해야 하나, 분리 보관 미이행 의혹. 개인정보보호위원회 조사 진행 중.

💡 교훈: 법정 보존 데이터는 별도 버킷/테이블로 분리, 접근 권한 최소화 필수

출처: SBS 뉴스 ↗

2023

온라인 쇼핑몰 법정 보존정보 유출

전자상거래법상 5년 보존 주문정보 테이블에서 개인정보 유출. 회원정보와 분리되지 않은 주문정보 테이블이 해킹 대상이 됨. 개인정보보호위원회로부터 과태료 600만원 부과.

💡 교훈: 법정 보존 데이터도 별도 저장소로 분리하고 접근 통제 강화 필요

출처: 개인정보보호위원회 의결 ↗

⚡

클라우드 환경의 위험

AWS에서 법정 보존 데이터 분리 저장이 미구현된 상황

미분리 저장 (위험)

활성 회원

👤

+

탈퇴 회원

👤

↑ 동일 버킷에 혼재 저장

전체 데이터 유출 위험 + 1천만원 이하 과태료 → ISMS-P 3.4.2 미충족

분리 저장 (권장)

운영 버킷

👤

|

법정 보존

🔒

↑ 별도 버킷 + Object Lock

물리적 분리 + 접근 권한 최소화 → 인증 기준 충족

🚨

발견 사례: 탈퇴회원 정보가 활성회원과 동일 버킷에 저장, 접근 권한 미분리

법정 보존이 필요한 탈퇴회원 데이터가 동일 S3 버킷에 Flag값만 변경하여 저장되어 있고, Object Lock이 미설정되어 삭제/수정이 가능한 상황.

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

# 동일 버킷에 활성 회원과 탈퇴 회원 혼재
resource "aws_s3_bucket" "user_data" {
  bucket = "company-user-data"

  # 탈퇴회원 정보도 동일 버킷에 저장
  # 별도 분리 버킷 없음
  # Object Lock 미설정
}

# IAM 정책 - 모든 운영자가 전체 버킷 접근
resource "aws_iam_policy" "s3_access" {
  name = "s3-full-access"
  policy = jsonencode({
    Statement = [{
      Effect   = "Allow"
      Action   = ["s3:*"]
      Resource = ["arn:aws:s3:::company-user-data/*"]
    }]
  })
}

ISMS-P 3.4.2 위반 사항

●

법정 보존 개인정보 미분리 저장

●

분리 저장 후 접근권한 미분리

●

데이터 무결성 보호 조치 부재

●

법정 보존기간 경과 후 자동 파기 미연계

🔍

사전 탐지 방안

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

법정 보존 데이터 분리 저장 탐지 로직

판단 조건	조건 값	결과
📦 법정 보존용 별도 버킷	`미존재` 분리 저장 안됨	Critical - 차단
📦 법정 보존용 별도 버킷	`존재`	→ Object Lock 검사
🔒 Object Lock 설정	`미설정` 삭제/수정 가능	High - 경고
	`Governance Mode` 우회 가능	Medium - Compliance 권장
	`Compliance Mode`	→ 접근 권한 검사
👥 Bucket Policy	`접근 제한 없음` 전체 접근 허용	High - 경고
👥 Bucket Policy	`최소 권한 적용`	✓ 통과

🔔

사후 대응 방안

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

분리 저장 설정 런타임 이벤트 대응 로직

판단 조건	조건 값	결과
📦 변경 유형	`IaC 배포 (Terraform)` 정상 변경	✓ 변경 이력만 저장
📦 변경 유형	`Drift 발생` 콘솔 직접 변경	→ 상세 분석
⚠️ 변경 내용 (Drift 발생 시)	`Object Lock 비활성화` 무결성 손상	Critical - PagerDuty 호출
	`Bucket Policy 완화` 접근 권한 확대	High - Slack 즉시 알림
	`법정 보존 버킷 삭제 시도`	Critical - 차단 + PagerDuty

모든 알림에 포함되는 정보

법정 보존 버킷 ARN 변경 전/후 Object Lock 설정 변경 주체 (IAM) 분리 저장 가이드

✓

조치 가이드

즉시 적용 가능한 권장 설정

❌ 문제

활성/탈퇴 회원 동일 버킷, Object Lock 미설정, 접근 권한 미분리

✓ 적용

별도 버킷 + Object Lock (Compliance) + IAM 최소 권한

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

legal-retention.tf

# 법정 보존용 별도 버킷 (분리 저장)
resource "aws_s3_bucket" "legal_retention" {
  bucket              = "company-legal-retention"
  object_lock_enabled = true  # Object Lock 필수

  tags = {
    Name    = "legal-retention"
    ISMS-P  = "3.4.2"
    Purpose = "법정 보존 개인정보 분리 저장"
  }
}

# Object Lock 설정 (Compliance Mode - 누구도 삭제 불가)
resource "aws_s3_bucket_object_lock_configuration" "legal_retention" {
  bucket = aws_s3_bucket.legal_retention.id

  rule {
    default_retention {
      mode  = "COMPLIANCE"  # 누구도 삭제/수정 불가
      years = 5             # 전자상거래법: 거래기록 5년
    }
  }
}

# Bucket Policy - 접근권한 최소화
resource "aws_s3_bucket_policy" "legal_retention" {
  bucket = aws_s3_bucket.legal_retention.id

  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Sid       = "DenyAllExceptLegalAdmin"
      Effect    = "Deny"
      Principal = "*"
      Action    = ["s3:DeleteObject", "s3:PutObject"]
      Resource  = "${aws_s3_bucket.legal_retention.arn}/*"
      Condition = {
        StringNotEquals = {
          "aws:PrincipalArn" = ["arn:aws:iam::ACCOUNT:role/LegalRetentionAdmin"]
        }
      }
    }]
  })
}

# 법정 보존기간 경과 후 자동 파기 (3.4.1 연계)
resource "aws_s3_bucket_lifecycle_configuration" "legal_retention" {
  bucket = aws_s3_bucket.legal_retention.id

  rule {
    id     = "archive-and-expire"
    status = "Enabled"

    transition {
      days          = 90
      storage_class = "GLACIER"
    }

    expiration {
      days = 1825  # 5년 후 자동 삭제
    }
  }
}

💡 핵심: object_lock_enabled = true로 버킷 생성 시 Object Lock을 활성화하고, mode = "COMPLIANCE"를 설정하면 법정 보존기간 동안 누구도 데이터를 삭제하거나 수정할 수 없습니다. aws_s3_bucket_policy로 접근 권한을 최소 인원(법정 보존 관리자)으로 제한합니다. 법정 보존기간 경과 후에는 Lifecycle Expiration으로 자동 파기되어 3.4.1과 연계됩니다.

📚 참고 자료

🔒 AWS S3 Object Lock ↗ 🗄️ AWS S3 Glacier ↗ 📜 전자상거래법 시행령 ↗

📊

리포트 방안

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

📋 진단 항목

법정 보존용 분리 버킷 존재 여부
Object Lock Compliance Mode 설정
Bucket Policy 접근 권한 현황
법정 보존 데이터 보관 기간
자동 파기 연계 (Lifecycle) 설정

📅 리포트 주기

일간

Object Lock/Policy 변경 이벤트

주간

분리 저장 준수 현황 요약

월간

ISMS-P 증적 리포트 (분리보관 대장)

📤 발송 및 저장

발송 채널

Email Slack

저장소

S3 (5년 보관)

⚡

BSG 차별점

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

기존 도구 방식

단순 Object Lock 활성화 검사

bucket.object_lock == True 단순 비교
Compliance/Governance 모드 구분 없음
정적 분석 결과만 출력

한계: 분리 저장 여부 미점검, 접근 권한 분리 미점검, 보존기간 적정성 미검증

BSG 접근 방식

분리 저장 + Object Lock + 접근 권한 통합 점검

IaC 코드 분석 기반 법정 보존 아키텍처 검증
Object Lock Compliance Mode 필수 검증
런타임 설정 변경 모니터링 + Drift 탐지

차별점: ISMS-P 3.4.1(개인정보 파기)과 통합하여 데이터 생명주기 전체 검증

← Data Protection & Disaster Recovery로 돌아가기