ISMS-P 2.8.3 시험과 운영 환경 분리 High Risk

시험과 운영 환경이 분리되어 있는가?

ISMS-P 2.8.3은 개발 및 시험 시스템을 운영시스템과 분리하여 비인가 접근 및 변경의 위험을 감소시키도록 요구합니다. AWS Multi-Account 전략으로 개발/운영 환경을 분리하고, SCP로 개발자의 운영 환경 접근을 통제합니다.

📋

ISMS-P 인증 기준

ISMS-P 2.8.3 시험과 운영 환경 분리 요구사항

2.8.3

시험과 운영 환경 분리

인증 기준 정의

"개발 및 시험 시스템은 운영시스템에 대한 비인가 접근 및 변경의 위험을 감소시키기 위하여 원칙적으로 분리하여야 한다."

📌 AWS Multi-Account 분리 요소

AWS Organizations 계정 분리
Control Tower 거버넌스
SCP (Service Control Policy)
VPC 네트워크 격리
IAM Role 환경별 분리

⚠️ 미준수 시 심사 영향

결함: 운영환경에서 직접 소스 변경
결함: 개발환경에서 운영 접근 허용
결함: 개발자에게 운영 DB 접근 허용
권고: 환경 분리 미수행 시 보완통제 부재

📄 KISA ISMS-P 인증기준 안내서 ↗ ☁️ AWS K-ISMS 규정 준수 ↗

📰

실제 보안 사고 사례

환경 분리 미흡으로 발생한 실제 사고

2025.03

GitHub Actions 공급망 공격

공격자가 tj-actions 리포지토리에 악성코드 삽입. CI/CD 환경에서 환경변수, 토큰, 권한 정보 탈취. 개발-운영 파이프라인 미분리로 운영 환경까지 피해 확산.

💡 교훈: CI/CD 환경별 분리, 개발/운영 파이프라인 격리 필수

2024

DeepSeek 클라우드 설정 오류

클라우드 인프라 설정 오류로 ClickHouse DB 노출, 개발/운영 환경 분리 미흡으로 테스트 데이터와 운영 데이터가 혼재되어 민감 정보 유출.

💡 교훈: 환경별 계정 분리, 네트워크 격리 필수

⚡

클라우드 환경의 위험

AWS에서 환경 분리가 위반되는 상황

단일 계정 환경 (위험)

Dev

✓

Staging

✓

Prod

✓

↑ 단일 계정에 모든 환경 혼재

단일 계정에서 모든 환경 운영 → 개발자가 운영 리소스 직접 접근 가능

Multi-Account 환경 (권장)

Dev

111111

Staging

222222

Prod

333333

↑ 환경별 계정 분리 + SCP 차단

환경별 별도 계정 + SCP 정책 → 개발자의 운영 환경 접근 원천 차단

🚨

발견 사례: 단일 계정에서 Dev/Staging/Prod 모두 운영

단일 계정, 단일 VPC에서 모든 환경을 운영하고 있습니다. 개발자에게 * 권한이 부여되어 운영 환경 리소스에 직접 접근이 가능한 상태입니다.

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

# 문제: 단일 계정, 단일 VPC
resource "aws_vpc" "main" {
  cidr_block = "10.0.0.0/16"
  # Dev/Staging/Prod 모두 동일 VPC
}

resource "aws_subnet" "dev" {
  cidr_block = "10.0.1.0/24"
}
resource "aws_subnet" "prod" {
  cidr_block = "10.0.2.0/24"  # 같은 VPC!
}

# 개발자도 운영 접근 가능
resource "aws_iam_policy" "developer" {
  policy = jsonencode({
    Statement = [{
      Effect = "Allow"
      Action = ["*"]   # 모든 권한!
      Resource = "*"
    }]
  })
}

ISMS-P 2.8.3 위반 사항

●

개발/운영 환경 미분리

●

개발자의 운영 환경 직접 접근 가능

●

네트워크 격리 정책 부재

●

침해 시 전체 환경 피해 확산 위험

🔍

사전 탐지 방안

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

환경 분리 미흡 탐지 로직

탐지 대상	판단 조건	결과
🏢 AWS Organizations	단일 계정에서 모든 환경 운영	High - 환경 분리 불가
🌐 VPC	Dev/Prod 동일 VPC 사용	High - 네트워크 격리 미흡
🔑 IAM Role	개발자에게 Prod 리소스 접근 허용	High - 권한 분리 미흡
🛡️ Security Group	Dev -> Prod 트래픽 허용	High - 네트워크 통제 미흡

🔔

사후 대응 방안

런타임 모니터링 및 교차 접근 탐지

환경 간 교차 접근 탐지 로직

탐지 대상	판단 조건	결과
📋 CloudTrail 교차 접근	개발 IAM이 Prod 리소스 접근 시도	Critical - PagerDuty 호출 Auto
⚙️ AWS Config 직접 변경	Prod 환경에서 콘솔 직접 변경 탐지	Critical - 즉시 알림 Auto
🛡️ GuardDuty 이상 행위	Dev 환경에서 Prod 접근 시도 탐지	High - Slack 즉시 알림 Auto

자동 대응 조치

SCP로 개발자 Prod OU 접근 차단 EventBridge 보안팀 알림 Lambda IAM 자동 비활성화

✓

조치 가이드

AWS Organizations + SCP 환경 분리 구성

권장 설정 (Multi-Account 환경 분리)

organizations.tf

# AWS Organizations + SCP 구성

# 1. OU 구조 설정
resource "aws_organizations_organizational_unit" "workloads" {
  name      = "Workloads"
  parent_id = aws_organizations_organization.main.roots[0].id
}

resource "aws_organizations_organizational_unit" "dev" {
  name      = "Development"
  parent_id = aws_organizations_organizational_unit.workloads.id
}

resource "aws_organizations_organizational_unit" "prod" {
  name      = "Production"
  parent_id = aws_organizations_organizational_unit.workloads.id
}

# 2. 환경별 계정 생성
resource "aws_organizations_account" "dev" {
  name      = "development"
  email     = "aws-dev@example.com"
  parent_id = aws_organizations_organizational_unit.dev.id
}

resource "aws_organizations_account" "prod" {
  name      = "production"
  email     = "aws-prod@example.com"
  parent_id = aws_organizations_organizational_unit.prod.id
}

# 3. SCP - 개발자 Prod 접근 차단
resource "aws_organizations_policy" "deny_dev_to_prod" {
  name = "DenyDevToProdAccess"
  type = "SERVICE_CONTROL_POLICY"

  content = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Sid    = "DenyDevUsersToProd"
      Effect = "Deny"
      Action = "*"
      Resource = "*"
      Condition = {
        StringEquals = {
          "aws:PrincipalTag/Team" = "development"
        }
      }
    }]
  })
}

resource "aws_organizations_policy_attachment" "deny_dev_to_prod" {
  policy_id = aws_organizations_policy.deny_dev_to_prod.id
  target_id = aws_organizations_organizational_unit.prod.id
}

💡 핵심: AWS Organizations로 계정을 분리하고, SCP로 개발자의 운영 계정 접근을 원천 차단합니다. Control Tower를 사용하면 거버넌스와 가드레일을 자동으로 적용할 수 있습니다.

AWS Organizations Control Tower SCP VPC 분리 IAM Role 분리

📚 참고 자료

☁️ AWS SCP 공식 문서 ↗ 🏗️ AWS Control Tower 가이드 ↗ 🔒 AWS Organizations Best Practices ↗

📊

리포트 방안

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

📋 계정 분리 현황

AWS Organizations 구조
OU/계정 목록 스크린샷
환경별 계정 분리 현황
VPC 네트워크 격리 구성

📅 SCP 정책 증적

개발자 Prod 접근 차단 정책
SCP 적용 현황
Control Tower 가드레일
정책 변경 이력

📤 접근 로그 증적

CloudTrail 교차 접근 로그
접근 차단 이력
GuardDuty 탐지 이력
월간 환경 분리 준수 리포트

⚡

BSG 차별점

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

기존 도구 방식

수동 검토 방식

문서 기반 환경 분리 확인
실제 분리 상태 검증 불가
교차 접근 탐지 불가
ISMS-P 매핑 불가

한계: 문서상 분리 선언만으로는 실제 운영 상태 검증 불가

BSG 접근 방식

IaC + CloudTrail + Config 통합 분석

계정/VPC/IAM 분리 상태 자동 검증
교차 접근 시도 실시간 탐지
Multi-Account 아키텍처 준수 평가
환경 분리 자동 검증 + 심사 증적 자동화

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

← CI/CD Pipeline Operations로 돌아가기