목차
클라우드 인프라를 코드로 관리(IaC)할 때 가장 큰 골칫거리 중 하나는 바로 '드리프트(Drift)'입니다. 드리프트란 코드로 정의된 의도된 상태와 실제 인프라의 현재 상태가 불일치하는 현상을 의미합니다. 수동 변경이나 정책 위반으로 인해 발생하는 이러한 드리프트를 효과적으로 관리하고 차단하기 위해서는, 명확한 '베이스라인 규칙셋'과 '자동화된 대응 전략'을 결합하는 것이 가장 중요합니다.
이 글에서는 IaC 보안을 위한 핵심 베이스라인을 정의하고, 드리프트를 탐지하고 대응하는 구체적인 전략을 단계별로 알아보겠습니다.
IaC 보안의 핵심, 베이스라인 규칙셋 수립
보안의 기본은 예측 가능성입니다. 네트워크, IAM, 암호화 세 가지 핵심 영역에서 '보안 기본값'을 코드로 정의하고, 예외는 철저히 관리하는 베이스라인을 수립해야 합니다. 아래는 각 규칙 카테고리별 운영 방법 예시입니다.
| 규칙 카테고리 | 기본값 (필수) | 예외 (조건/만료) | 검증 (Shift-left) | 리미디에이션 (자동/반자동) |
|---|---|---|---|---|
| 네트워크 | 기본 비공개 서브넷, SG 최소허용 | 공개포트 한시 허용 (7~14일) | PR 단계 OPA/Kyverno 검사 | TTL 만료 시 SG 규칙 자동 제거 |
| IAM | 역할 기반·권한 최소화 | Break-glass 역할 1시간 | CI에서 tf validate + 정책 체크 |
만료 후 세션 강제 종료 |
| 암호화/스토리지 | KMS/KMS CMK 기본 암호화 | 고객 요구 시 BYOK | 키 회전·감사 기준 검사 | 미암호화 버킷 자동 차단/암호화 |
팁: 클라우드 키 관리 정책 수립 시, 키 회전 및 감사 기준에 대한 자세한 내용은 KMS 자체 vs 매니지드 비교 가이드를 참고하세요.
드리프트(Drift), 어떻게 탐지하고 관리할까?
주기적인 탐지와 경보 설정
드리프트는 발생 즉시 탐지하고 위험도를 평가하는 것이 중요합니다. 주요 IaC 도구는 다음과 같은 탐지 기능을 제공합니다.
- Terraform:
plan또는apply실행 시 자동으로 실제 인프라 상태를 확인하여 코드와의 차이점을 알려줍니다. 또한 별도의 'refresh-only' 모드를 사용해 상태 동기화만 수행할 수도 있습니다. - HCP Terraform (Cloud): 표준 에디션부터 자동 드리프트 감지 기능을 제공하여, 주기적인 탐지와 알림 설정이 가능합니다.
- AWS CloudFormation: 스택(Stack) 및 리소스 단위의 드리프트 감지를 지원합니다. 콘솔이나 CLI를 통해 주기적으로 실행하고 결과를 확인해야 합니다.
드리프트 위험도 산정 및 우선순위 부여
모든 드리프트가 동일한 위험을 갖지는 않습니다. 아래와 같은 간단한 계산식을 활용하여 대응의 우선순위를 정할 수 있습니다.
드리프트_위험점수 = (고위험_규칙_위반수 × 가중치) + 미승인_변경수 − (리미디에이션_속도)
드리프트 발생을 막는 4가지 핵심 전략
1. 승인 없는 수동 변경 차단 (가드레일)
콘솔이나 CLI를 통한 직접적인 수동 변경을 원천적으로 줄이기 위해 조직 단위의 가드레일을 구축해야 합니다.
- 프로덕션 계정 접근 제한: SSO 및 승인 워크플로를 통해서만 콘솔 접근을 허용합니다.
- IaC 기반 변경 강제: 모든 변경은 Pull Request(PR)와 동료 검토(Peer Review) 승인을 거치도록 강제합니다.
- 긴급 접근(Break-glass) 관리: 긴급 상황을 위한 접근은 명확한 만료 시간을 설정하고, 모든 활동을 감사 로그로 기록합니다.
참고: 쿠버네티스 환경의 접근 제어 방식은 네임스페이스 격리 및 RBAC 최소권한 가이드에서 아이디어를 얻을 수 있습니다.
2. 정책을 코드로 검증 (Policy as Code)
변경 사항이 배포되기 전, CI/CD 파이프라인 단계에서 정책을 코드로 자동 검증하는 것은 드리프트 예방의 핵심입니다.
- OPA (Open Policy Agent) / Kyverno: PR 단계에서 "공개 포트 금지", "필수 태그 누락 금지", "암호화 필수" 등의 보안 규칙을 자동으로 검사합니다.
- Terraform Precondition & Postcondition: 코드 내에서 리소스 생성 전후의 조건을 명시하여 의도치 않은 변경을 방지합니다.
- HCP Terraform: 배포 가능 요일 및 시간대 제한과 같은 운영 규범도 정책으로 강제할 수 있습니다.
- 컨테이너 이미지 서명: 컨테이너 이미지의 경우, 서명 및 검증 정책을 파이프라인에 통합하여 공급망 보안을 강화합니다.
3. 표준화된 태그와 감사 로그
모든 리소스에 일관된 태그(예: Owner, CostCenter, Environment, TTL)를 강제하고 감사 로그를 통합하여 추적성을 확보합니다. TTL(Time-To-Live) 태그가 만료된 자원은 자동으로 삭제 후보로 분류하여 방치된 리소스를 최소화합니다.
팁: 네트워크 분할 및 라벨링 정책은 하이브리드 클라우드 네트워크 세그먼트 설계 기준과 연계하여 베이스라인에 반영할 수 있습니다.
4. 대규모 환경을 위한 표준화 (멀티계정/멀티리전)
여러 계정과 리전을 운영한다면, 드리프트 탐지와 알림 정책을 중앙에서 표준화해야 합니다. 계정별 예외는 중앙 코드 저장소에서 승인 및 만료를 관리하여 일관성을 유지합니다. 특히 AWS CloudFormation의 StackSets 드리프트 감지 기능은 대규모 환경에서 발생한 드리프트를 효율적으로 점검하는 데 유용합니다.
드리프트 발생 시 대응 및 복구 절차
드리프트가 탐지되었을 때 우왕좌왕하지 않으려면 명확한 대응 절차가 필요합니다.
- 탐지: 자동화된 도구로 드리프트 감지 및 알림 수신
- 분석: 영향도 및 위험 점수 산정
- 결정: 승인 워크플로를 통해 예외로 인정할지, 롤백할지 결정
- 수정: 수정 사항을 담은 새로운 PR 생성
- 검증: CI 파이프라인에서 정책 및 테스트 자동 검증
- 배포: 점진적 릴리즈 (카나리 등)로 안정성 확보
- 기록: 사후 감사 및 조치 내용 기록
중요: 만약 발생한 변경이 장애 대응을 위한 의도된 핫픽스였다면, 즉시 IaC 소스 코드에 해당 변경을 반영하여 '코드에 현실을 맞추는' 작업이 필수입니다. 이를 통해 동일한 드리프트 재발을 방지할 수 있습니다.
Terraform vs. CloudFormation 드리프트 탐지 비교
대표적인 IaC 도구인 Terraform과 AWS CloudFormation은 드리프트를 탐지하는 방식에 차이가 있습니다.
| 항목 | Terraform | CloudFormation |
|---|---|---|
| 트리거 | plan/apply 전 리프레시, refresh-only 모드 |
콘솔/CLI로 스택·리소스·StackSets 온디맨드 실행 |
| 범위 | 상태(State) 파일에 등록된 모든 리소스 속성 | 템플릿에 명시된 속성만 비교 (지원 리소스 타입 한정) |
| 결과 | 실행 계획(Plan)에 차이 표시, HCP는 자동 감지·알림 | 리소스별 DRIFTED/IN_SYNC 등 상태 보고 |
| 주의사항 | IaC 비관리 항목, 호스트 내부 변경은 탐지 한계 | 미지원 리소스 타입, 템플릿에 명시되지 않은 속성은 감지 불가 |
운영 체크리스트 및 비용 고려사항
간단한 운영 체크리스트
주기 설정(예: 일 1회) → 탐지 실행 → 승인/차단 → 수정 PR → 정책·테스트 검증 → 릴리즈 → 감사 기록
비용 및 운영 오버헤드
자동 드리프트 감지 및 정책 시행은 초기 설정 비용이 발생하지만, 장기적으로는 수동 작업으로 인한 장애나 보안 사고 대응 비용을 크게 절감하는 효과가 있습니다. (HCP Terraform의 자동 드리프트 감지는 표준 에디션 이상에서 제공되므로 라이선스 비용을 고려해야 합니다.)
FAQ (자주 묻는 질문)
Q1. Terraform으로 탐지하지 못하는 드리프트도 있나요?
네, 있습니다. Terraform 상태(State) 파일에 의해 관리되지 않는 리소스나, VM 인스턴스 내부의 패키지 설치와 같은 호스트 레벨의 변경은 기본적으로 탐지 대상이 아닙니다. 드리프트 탐지는 주로 plan이나 refresh 시점에 이루어집니다. 더 자세한 내용은 Terraform 공식 드리프트 관리 튜토리얼을 참고하세요.
Q2. CloudFormation 드리프트 탐지의 한계는 무엇인가요?
CloudFormation은 템플릿에 명시적으로 정의된 속성만 비교하며, 드리프트 감지를 지원하는 리소스 타입에 한해서만 결과를 제공합니다. 따라서 템플릿에 정의되지 않은 속성이 변경되거나 지원하지 않는 리소스 타입의 변경은 탐지하지 못할 수 있습니다.
Q3. 드리프트 알림이 너무 많아 피로도가 높습니다. 어떻게 줄일 수 있나요?
위에서 소개한 '드리프트 위험 점수'를 활용하여 임계치를 설정하세요. 고위험 규칙 위반이나 미승인 변경만 즉시 경보로 보내고, 낮은 위험도의 드리프트는 일일 요약 보고서 형태로 묶어서 받는 것이 좋습니다. 또한, 동일 리소스에서 24시간 내 발생하는 중복 경보는 압축하여 알림 피로도를 줄일 수 있습니다.
Q4. 모든 수동 변경을 막아야 하나요? 예외는 없나요?
장애 대응, 긴급 보안 패치, 규제 감사 등 예측 불가능한 긴급 상황에서는 'Break-glass' 절차를 통해 예외적으로 수동 변경을 허용할 수 있습니다. 단, 이 경우에도 명확한 만료 시간 설정, 모든 작업의 감사 로그 기록, 사후 IaC 코드에 변경 사항을 반영하는 프로세스가 반드시 뒤따라야 합니다.
Q5. 리소스 태그 표준을 강제하는 가장 좋은 방법은 무엇인가요?
여러 방법을 조합하는 것이 가장 효과적입니다.
- PR 단계: OPA/Kyverno 정책으로 필수 태그 누락 시 빌드를 실패시킵니다.
- 배포 파이프라인: 배포 직전 단계에서 다시 한번 태그 정책을 검증하고 차단합니다.
- 클라우드 네이티브 정책: AWS Service Control Policies (SCPs)나 Azure Policy 등을 사용하여 비용 관련 태그가 없으면 리소스 생성을 거부하도록 조직 단위 정책을 설정합니다.
결론
IaC 환경에서 드리프트는 피할 수 없는 과제이지만, 체계적으로 관리할 수 있습니다. 명확한 베이스라인 규칙셋을 정의하고, 정책을 코드로 자동화하며, 주기적인 탐지와 신속한 대응 프로세스를 갖추는 것이 핵심입니다. 오늘 소개한 전략들을 통해 더 안정적이고 보안이 강화된 클라우드 인프라를 운영해 보세요.
※ 면책 조항: 본 글은 일반적인 정보 제공을 목적으로 합니다. 실제 환경에 적용하기 전, 반드시 조직의 보안 정책 및 규정 준수 요구사항을 검토하고 테스트 환경에서 충분히 검증하시기 바랍니다.
