규정 대응 실무: evidence collection, control mapping, exception 관리

감사는 준비된 팀과 준비 안 된 팀을 구분한다

SOC 2, PCI DSS, ISO 27001, HIPAA — 어떤 규정이든 감사가 시작되면 감사인은 두 가지를 본다. 첫째, "통제가 존재하는가?" 둘째, "통제가 일관되게 작동했다는 증적이 있는가?"

준비된 팀은 평소에 증적을 수집하고 통제를 문서화해두어서 감사 기간에 추가 작업이 거의 없다. 준비 안 된 팀은 감사 직전에 스크린샷을 모으고, 과거 설정을 재현하고, "이건 사실 항상 하고 있었는데 문서가 없었다"는 상황을 만들어낸다.

이 장은 DBA와 데이터 플랫폼 엔지니어가 규정 대응에서 실제로 해야 하는 일—증적 수집, 통제 매핑, 예외 관리—을 실무 관점에서 다룬다.

1. 주요 프레임워크 비교

데이터베이스와 데이터 플랫폼 운영자가 마주치는 규정은 다음 네 가지가 많다.

SOC 2와 PCI DSS는 약 60%의 통제가 겹친다. 두 가지를 동시에 준수하는 조직은 한 번 증적을 수집해 여러 프레임워크에 재사용하는 방식으로 효율을 높인다.

2. Control Mapping: 통제 매핑

통제 매핑(Control Mapping)은 조직이 실제로 운영하는 보안 통제 하나를 여러 규정 요건에 동시에 연결하는 작업이다.

예를 들어 "DB 접근에 MFA를 적용하고 90일마다 접근 검토를 수행한다"는 단일 통제가 아래 요건을 동시에 만족할 수 있다.

2.1 통제 매핑 테이블 만들기

실무에서는 스프레드시트 또는 GRC 도구에 통제 매핑 테이블을 관리한다. 최소 포함 컬럼:

3. Evidence Collection: 증적 수집

감사인이 원하는 증적은 "통제가 일관되게 작동하고 있다"는 것을 보여주는 기록이다. 한 번의 스크린샷으로는 충분하지 않다. 감사 기간(보통 12개월) 동안 반복적으로 작동했다는 증거가 있어야 한다.

3.1 증적 유형별 예시

3.2 자동화가 핵심이다

수동 스크린샷은 두 가지 문제가 있다. 감사 직전에만 찍히면 "일관된 운영"의 증거가 되지 않는다. 그리고 사람이 기억해야 하므로 빠진다.

자동화된 증적 수집 예시:

#!/bin/bash
# 월간 DB 보안 설정 스냅샷 자동 수집
DATE=$(date +%Y-%m-%d)
OUTPUT_DIR="/evidence/monthly/${DATE}"
mkdir -p "$OUTPUT_DIR"

# MySQL: 보안 관련 변수 스냅샷
mysql -u auditor -p"$AUDIT_PASS" -e "
  SELECT variable_name, variable_value
  FROM performance_schema.global_variables
  WHERE variable_name IN (
    'require_secure_transport',
    'tls_version',
    'audit_log_policy',
    'local_infile',
    'validate_password_policy'
  )
" > "$OUTPUT_DIR/mysql-security-vars.txt"

# MySQL: 전체 계정 목록
mysql -u auditor -p"$AUDIT_PASS" -e "
  SELECT user, host, account_locked, password_expired,
         password_last_changed
  FROM mysql.user
  ORDER BY user
" > "$OUTPUT_DIR/mysql-accounts.txt"

# PostgreSQL: 역할 목록
psql -U auditor -c "
  SELECT rolname, rolsuper, rolcreaterole, rolcreatedb,
         rolcanlogin, rolvaliduntil
  FROM pg_roles
  ORDER BY rolname
" > "$OUTPUT_DIR/pg-roles.txt"

# S3에 증적 업로드 (audit log 전용 버킷, 삭제 방지)
aws s3 cp "$OUTPUT_DIR" \
  "s3://compliance-evidence/${DATE}/" \
  --recursive \
  --storage-class GLACIER_IR

echo "증적 수집 완료: ${OUTPUT_DIR}"

4. Exception 관리: 예외 처리

모든 통제를 100% 충족하는 환경은 거의 없다. 기술적 제약, 비즈니스 요구, 레거시 시스템으로 인해 일부 통제를 지금 당장 이행할 수 없는 경우가 생긴다.

이것이 예외(Exception)다. 중요한 것은 예외를 숨기는 것이 아니라 정식 프로세스로 관리하는 것이다. 감사인은 예외 자체보다 예외가 문서화되지 않거나 위험이 평가되지 않은 상황을 심각하게 본다.

4.1 예외 처리 프로세스

4.2 예외 문서 필수 항목

예외 ID: EXC-2026-031
Control ID: AC-007 (TLS 1.2 이상 강제)
예외 이유: 레거시 ETL 시스템이 TLS 1.0만 지원 (벤더 미지원)
영향 시스템: etl-legacy-01, 내부 네트워크 only
위험 수준: Medium (외부 접근 불가, 내부 트래픽에 한정)
보완 통제:
  - 해당 시스템은 격리된 내부 전용 네트워크에만 노출
  - 네트워크 레벨 암호화(VPN) 적용
  - 해당 시스템 접근 로그 강화 모니터링
승인자: [CISO 이름], [보안위원회]
승인일: 2026-04-15
유효기간: 2026-10-31 (6개월)
해소 계획: ETL 시스템 교체 프로젝트 2026-Q4 완료 예정

4.3 보완 통제(Compensating Controls)

PCI DSS는 보완 통제를 공식으로 인정한다. 원래 요건을 이행할 수 없는 합당한 이유가 있고, 보완 통제가 동등한 수준의 위험 경감을 제공한다면 감사를 통과할 수 있다.

보완 통제가 유효하려면:

1. 동등성: 원래 통제가 막으려는 위협을 보완 통제도 막아야 한다.
2. 문서화: 왜 원래 통제를 이행할 수 없는지 명확한 이유가 있어야 한다.
3. 초과 이행: 보완 통제는 원래 통제와 "동등"하지 않고 "추가"여야 한다는 해석이 일반적이다.

5. 프레임워크별 DB 핵심 통제

5.1 SOC 2 — 데이터베이스 관련 Trust Service Criteria

5.2 PCI DSS v4.0 — 카드 데이터 DB 핵심 요건

PCI DSS v4.0에서 DB 운영자가 직접 대응해야 하는 요건:

Req 3.4: 카드 번호(PAN) 암호화 저장
  → 컬럼 수준 암호화 또는 토크나이제이션

Req 7.1: 접근 최소화
  → DB 계정에 최소 권한, 불필요 계정 삭제

Req 8.3/8.4: 강력한 인증
  → DB 관리자 계정 MFA, 서비스 계정 키 로테이션

Req 10.2: 감사 로그
  → 로그인 실패, 권한 변경, 카드 데이터 접근 기록

Req 10.5: 로그 변조 방지
  → 로그를 별도 보안 시스템에 즉시 전송

Req 11.3: 취약점 스캔
  → DB 버전, 알려진 CVE 분기별 스캔

Req 12.3.2: 연간 위험 평가
  → DB 자산 범위 포함 위험 평가

6. 감사 기간 중 실제 흐름

감사인이 Type II SOC 2 감사를 진행하는 전형적인 흐름은 다음과 같다.

6.1 샘플 요청 대응

감사인은 무작위 날짜를 지정해 증적을 요청한다. "2026년 2월 15일의 DB 계정 목록을 보여주세요"라는 요청에 바로 답할 수 있어야 한다.

이를 위해:

• 증적은 날짜 기준으로 폴더를 구성해 저장한다 (/evidence/2026-02/db-accounts.txt).
• 증적 보관소는 읽기 전용이며 삭제 방지 설정을 적용한다.
• 증적 수집 스크립트 자체도 버전 관리(Git)로 추적한다.

7. GRC 도구 활용

규모가 커지면 스프레드시트만으로 관리가 어렵다. GRC(Governance, Risk, Compliance) 도구를 사용하면 통제 매핑, 증적 수집, 예외 관리, 감사 워크플로를 통합 관리할 수 있다.

도구가 없을 때 최소한의 구조:

• Confluence/Notion에 통제 목록과 매핑 테이블 관리
• 자동화 스크립트로 증적 수집, S3에 날짜별 저장
• Jira에 예외 티켓과 변경 관리 티켓 관리

8. 운영 체크리스트

마무리: 규정 대응은 일상 운영의 부산물이어야 한다

규정 대응을 "감사 직전에 하는 것"으로 보면 항상 고통스럽다. 통제를 평소에 운영하고, 증적을 자동으로 수집하고, 예외를 정식으로 관리하면 감사는 "이미 하고 있던 것을 보여주는 과정"이 된다.

DBA와 데이터 엔지니어에게 규정 대응은 보안팀이 전담하는 일이 아니다. DB 설정, 접근 검토, 백업 로그, 변경 관리—모두 DBA가 직접 소유하는 영역이다. 이 영역의 증적을 누가 관리할 것인지는 DBA 스스로 결정해야 한다.

다음 장에서는 데이터 플랫폼 보안 사고가 발생했을 때의 유출 탐지, 격리, 영향도 분석을 다룬다.

References

• SOC 2 Auditors, "SOC 2 Controls List (2026): All 5 TSCs Mapped to Evidence": https://soc2auditors.org/insights/soc-2-controls-list/
• StrikeGraph, "PCI DSS vs. SOC 2: Differences, Mappings & Streamlining": https://www.strikegraph.com/blog/pci-dss-vs-soc-2
• Neumetric, "SOC 2 Evidence Collection Process to support Audit Readiness": https://www.neumetric.com/journal/soc-2-evidence-collection-process-4856/
• VikingCloud, "Beyond Silos: Mastering Compliance Across PCI, ISO 27001, and SOC 2": https://www.vikingcloud.com/blog/beyond-silos-mastering-compliance-across-pci-iso-27001-and-soc-2
• Pentagon Infosec, "SOC 2 Audit Checklist: Controls Mapping Guide": https://pentagoninfosec.com/blog/soc-2-audit-checklist-controls-mapping
• TruOps GRC, "Navigating Multiple Compliance Frameworks at once": https://truops.com/navigating-multiple-compliance-frameworks-at-once-hipaa-pci-soc-2-and-iso-27001/
• HiComply, "SOC 2 vs PCI DSS in Fintech: Key Differences & Requirements": https://www.hicomply.com/blog/soc-2-vs-pci-dss-in-fintech-what-you-really-need-first
• Linford & Co, "PCI + SOC 2: Can (or Should) You Combine PCI & SOC 2 Audits?": https://linfordco.com/blog/should-pci-soc-2-audits-be-combined/
• GetSecureSlate, "SOC 2 Controls List (2026): Full CC Guide + What Auditors Expect": https://getsecureslate.com/blog/soc-2-controls-full-list-use-cases-and-what-auditors-expect
• PCI Security Standards Council, PCI DSS v4.0 Requirements: https://www.pcisecuritystandards.org/document_library/