클라우드 보안·컴플라이언스

담당 역할: 보안/컴플라이언스 담당자

앞의 세 카테고리가 구조를 어떻게 설계하는가의 문제라면, 보안 baseline은 그 구조가 시간이 지나도 안전한 상태를 유지하는가를 다룬다. 리소스는 수천 개 단위로 늘어나고 매일 새로 생성·삭제된다. 사람이 하나하나 검토해서는 기준선을 유지할 수 없다. 정책을 코드로 표현하고(Policy as Code) 자동으로 강제하라.

• Control과 Guardrail의 구분: Control은 리스크가 현실화됐을 때 이를 완화·탐지하는 수단, Guardrail은 그 Control을 달성하는 기술적 구현이다(Part 1.3 참조).

• CIS Benchmarks: CIS(Center for Internet Security)가 커뮤니티 합의로 만드는 벤더 중립 보안 설정 기준선. 25개 이상 벤더 패밀리, 8대 카테고리에 걸쳐 100개 이상 존재한다.

• Level 1 / Level 2 프로파일: Level 1은 미션크리티컬이 아닌 시스템을 위한 기본 기준선이다. Level 2는 미션크리티컬 시스템을 위한 강한 기준선으로, 운영 트레이드오프를 감수한다.

• Policy as Code: 보안 정책을 사람이 읽는 문서가 아니라 IaC 파이프라인·CI에서 자동 검사되는 코드로 표현하라.

CIS Benchmark 자체는 법적 컴플라이언스가 아니라 기술 기준선이다. NIST·PCI-DSS·HIPAA 같은 규제 요건과 매핑되어, 법 조항을 구체적 설정값으로 번역하는 다리 역할을 한다.

1. 1단계 — 기준선 채택 — CIS Benchmarks, NIST CSF, ISO 27001 중 하나를 조직의 기본 기준선으로 정하라.

2. 2단계 — 현황 감사(Audit 모드) — 선택한 기준선 대비 현재 리소스의 준수 상태를 스캔하라. 곧바로 강제하지 마라.

3. 3단계 — 예외 설계 — 정당한 이유로 기준선을 지킬 수 없는 리소스 유형의 제외 목록을 만들어라.

4. 4단계 — 점진적 Enforce 전환 — 오탐 가능성이 낮은 정책부터 차단 모드로 전환하고, 나머지는 탐지형 통제로 계속 감시하라.

5. 5단계 — 업종별 요건 레이어링 — 기본 기준선 위에 PCI-DSS, HIPAA, GDPR 같은 업종·지역별 요건을 추가하라(Part 13 참조).

6. 6단계 — 지속적 모니터링·재인증 — CSPM으로 설정 표류를 상시 탐지하고, 연 1회 이상 전체 기준선을 재인증하라.

① AWS Organizations 선언형 정책(Declarative Policies) — SCP가 “이 API를 호출 못 하게 막는다”는 액션 레벨 통제라면, Declarative Policy는 “이 설정값은 항상 X여야 한다”는 상태 레벨 선언이다. 정책을 붙인다고 모든 리소스가 즉시 그 상태에 도달하지 않는다 — 신규 리소스는 생성 시점부터 즉시 준수하지만, 기존 리소스는 비동기 전이가 필요하다.

② VPC Encryption Controls — 위 선언형 정책의 구체 사례다. monitor(탐지만) 또는 enforce(생성 자체 거부) 모드로 VPC 트래픽 암호화를 강제한다. 암호화를 지원하지 않는 리소스 타입은 명시적으로 제외하지 않으면 enforce 전이를 막는다 — 롤아웃 전 기존 VPC 구성을 먼저 감사해야 하는 이유다. 과금은 적용 대상 VPC 개수에 선형으로 비례하므로, 모든 환경에 기본값으로 켤 기능이 아니라 명확한 컴플라이언스 요건이 있는 환경에 선택적으로 도입해야 한다.

• 조직의 기본 보안 기준선(CIS/NIST CSF/ISO 27001 중 하나)이 명시적으로 채택되어 있는가?

• 신규 정책 적용 전 Audit 모드로 현황을 먼저 점검하는 절차가 표준화되어 있는가?

• 예방형과 탐지형 가드레일이 함께 구성되어 있는가?

• 정책 롤아웃 시 신규 리소스와 기존 리소스의 비대칭을 감안한 마이그레이션 계획이 있는가?

• CSPM 또는 이에 준하는 도구로 설정 표류를 상시 모니터링하는가?

• 업종별 규제 요건(PCI-DSS/HIPAA/GDPR 등)이 기본 기준선 위에 명시적으로 레이어링되어 있는가?

• Audit 없이 곧바로 Enforce한다: 기존에 정상 운영 중이던 리소스가 무더기로 차단되는 장애로 이어진다.

• 제외 목록 없이 전면 강제한다: 레거시 시스템까지 일괄 적용하면 정당한 예외를 위반으로 오분류해 알림 피로를 부른다.

• 예방형이나 탐지형 한쪽만 쓴다: 예방형만 있으면 예측하지 못한 시나리오에 무방비하고, 탐지형만 있으면 사고를 막지 못하고 사후 대응만 한다.

• 기준선을 한 번 세우고 재검토하지 않는다: 클라우드 서비스는 계속 늘어나고 기준선도 계속 갱신된다. 연 1회 이상 재인증이 없으면 기준선 자체가 낡는다.