[보안] 클라우드 보안 감사 체크리스트: AWS, Azure, GCP 공통 점검 사항과 베스트 프랙티스

클라우드 보안 감사 이야기가 나오면 많은 분들이 일단 한숨부터 쉬시더라고요. 계정은 많고, 권한은 꼬여 있고, 네트워크는 복잡하고, 로그는 쌓이는데 정작 뭘 먼저 봐야 할지 막막하거든요. 저도 홈랩이랑 실제 운영 환경을 오가면서 비슷한 삽질을 꽤 했습니다 ㅎㅎ 처음엔 서비스별 메뉴만 뒤지다가 시간을 다 썼었는데, 나중에 보니 공통 체크리스트를 먼저 잡아두는 게 훨씬 효율적이었습니다. 이번 글에서는 클라우드 보안 감사를 할 때 AWS, Azure, GCP에서 공통으로 봐야 하는 항목을 한 번에 정리해보겠습니다.

특히 이 글은 체크리스트 성격으로 구성했습니다. 즉, 이론만 설명하는 글이 아니라 실제로 점검 순서를 잡고, 빠르게 누락을 찾고, 운영팀과 보안팀이 같은 화면을 보면서 이야기할 수 있게 만드는 데 초점을 맞췄습니다. AWS 보안, Azure 보안, GCP 보안을 각각 따로 공부해도 결국 핵심은 비슷하더라고요. 인증, 권한, 네트워크, 로깅, 암호화, 자산 파악, 그리고 운영 통제. 여기서 중요한 포인트입니다.

멀티 클라우드 환경에서 IAM, 네트워크, 로깅, 암호화, 자산 관리가 어떻게 연결되는지 보여주는 개요 이미지입니다.

1. 클라우드 보안 감사가 왜 어려운가

쉽게 말해, 온프레미스(On-premise, 사내 구축 환경)에서는 자산이 한곳에 모여 있었는데 클라우드에서는 계정, 구독, 프로젝트 단위로 권한과 리소스가 흩어집니다. 여기에 사람이 직접 만든 예외 설정이 계속 쌓이니까, 어느 날 보면 기본 정책보다 예외가 더 많아지기도 합니다. 실제로 써보니까 보안 사고는 거창한 제로데이보다 오래된 액세스 키, 과도한 관리자 권한, 퍼블릭 오픈 스토리지 같은 기본 실수에서 더 자주 시작되더라고요.

감사(Audit, 점검)의 목적은 단순히 체크박스를 채우는 게 아닙니다. 지금 환경이 누가 접근 가능한지, 무엇이 외부에 열려 있는지, 이상 징후를 추적 가능한지를 검증하는 과정입니다. 그래서 제품별 기능 이름보다 통제 항목(Control, 보안 통제)을 기준으로 보는 게 훨씬 낫습니다.

2. AWS, Azure, GCP 공통 개념 먼저 잡기

플랫폼 이름은 달라도 아래 개념은 거의 같습니다. 저도 처음엔 콘솔 화면이 달라서 별개처럼 느꼈는데, 구조로 보면 생각보다 단순합니다.

클라우드 보안 감사를 할 때는 이 표처럼 기능명이 아니라 역할 기준으로 정리하시면 훨씬 덜 헷갈립니다. 특히 멀티 클라우드 운영이면 더 그렇습니다.

3. 클라우드 보안 감사 체크리스트: 계정과 권한

3-1. 가장 먼저 볼 항목

1. 루트(root) 또는 최고 권한 계정에 MFA(Multi-Factor Authentication)가 적용되어 있는지 확인해야 합니다.
2. 공유 계정 사용 여부를 봅니다. 사람별 계정 분리가 안 되어 있으면 추적이 거의 안 됩니다.
3. 장기 액세스 키(Long-lived access key) 사용 현황을 확인합니다.
4. 권한이 광범위한 역할(Role)과 그룹(Group)을 찾습니다.
5. 퇴사자, 장기 미사용 계정, 테스트용 계정을 비활성 또는 삭제합니다.

제가 직접 해보니 여기서 제일 많이 걸리는 건 관리자 권한 남발이었습니다. 처음엔 빠르게 작업하려고 광범위한 권한을 주는데, 그게 몇 달 지나면 아무도 왜 있는지 모르는 권한 덩어리가 되거든요.

3-2. 빠르게 확인하는 예시 명령어

# AWS: 계정 별칭, 사용자, 액세스 키 마지막 사용일 확인 예시
aws iam list-users
aws iam get-account-summary
aws iam generate-credential-report
aws iam get-credential-report

# Azure: 역할 할당 확인 예시
az role assignment list --all
az ad user list --query "[].{userPrincipalName:userPrincipalName,accountEnabled:accountEnabled}"

# GCP: 프로젝트 IAM 정책 확인 예시
gcloud projects get-iam-policy PROJECT_ID

명령어 결과를 보면 중요한 건 수치보다 패턴입니다. 예를 들어 서비스 계정(Service Account, 시스템용 계정)이 사람처럼 쓰이고 있다거나, 테스트 계정이 아직도 관리자 권한을 가지고 있다면 바로 정리 대상입니다.

4. 네트워크와 외부 노출 점검

두 번째는 네트워크입니다. 보안 사고 대응할 때 제일 식은땀 나는 순간이 뭐냐면, 내부용이라고 생각했던 포트가 인터넷에 열려 있는 걸 발견했을 때입니다. 저도 예전에 홈랩에서 관리 포트를 열어놓고 잊어버린 적이 있었는데, 로그 보고 진짜 놀랐습니다.

• 0.0.0.0/0 또는 모든 소스 허용 규칙이 있는지 확인합니다.
• SSH(22), RDP(3389), 데이터베이스 포트가 외부에 직접 열려 있는지 확인합니다.
• 관리망과 서비스망이 분리되어 있는지 봅니다.
• 로드밸런서(Load Balancer, 트래픽 분산 장치) 뒤에 있어야 할 자원이 직접 노출되지 않았는지 확인합니다.
• Egress(이그레스, 외부로 나가는 통신) 제어 정책이 있는지 확인합니다.

보안 그룹(Security Group), NSG, 방화벽 규칙에서 외부 노출 경로를 식별하는 과정을 보여주는 이미지입니다.

4-1. 점검 예시 명령어

# AWS: 보안 그룹 확인 예시
aws ec2 describe-security-groups

# Azure: NSG 규칙 확인 예시
az network nsg list
az network nsg rule list --nsg-name MY_NSG --resource-group MY_RG

# GCP: 방화벽 규칙 확인 예시
gcloud compute firewall-rules list

여기서 중요한 포인트! 단순히 포트가 열려 있냐만 보면 반쪽짜리 감사가 됩니다. 누가, 어떤 경로로, 어떤 자산에 접근 가능한지를 같이 봐야 합니다. Ingress(인그레스, 외부 트래픽 진입점)와 Egress를 함께 보셔야 사고 범위를 읽을 수 있습니다.

5. 로그, 모니터링, 탐지 체계 확인

로그가 없으면 사고가 나도 복기가 안 됩니다. 드디어 됐다! 싶게 정책을 잘 걸어놔도, 누가 언제 어떤 변경을 했는지 기록이 안 남으면 감사 품질이 확 떨어집니다. 그래서 클라우드 보안 감사에서 로그 영역은 거의 필수 코스입니다.

1. 관리 이벤트 로그가 활성화되어 있는지 확인합니다.
2. 로그 보존 기간이 조직 기준에 맞는지 확인합니다.
3. 로그 저장소 접근 권한이 제한되어 있는지 확인합니다.
4. 위험 이벤트에 대한 알림이 있는지 확인합니다.
5. 시간 동기화와 리전별 로그 수집 누락이 없는지 확인합니다.

# AWS: CloudTrail 추적 상태 확인 예시
aws cloudtrail describe-trails
aws cloudtrail get-trail-status --name TRAIL_NAME

# Azure: 활동 로그 확인 예시
az monitor activity-log list --max-events 20

# GCP: 감사 로그 설정 확인에 활용할 기본 조회 예시
gcloud logging logs list

실제로 운영하다 보면 로그는 켜져 있는데 중요 이벤트 알림이 빠진 경우가 많습니다. 예를 들어 IAM 정책 변경, 방화벽 변경, 키 삭제, 감사 로그 비활성화 시도 같은 이벤트는 최소한 경보를 받는 구조가 있어야 합니다. 이거 진짜 편하더라고요. 사고 전에 조짐을 보게 되니까요.

6. 데이터 보호: 암호화, 비밀정보, 백업

보안 감사에서 의외로 자주 빠지는 게 백업과 키 접근 제어입니다. 암호화(Encryption, 데이터 보호)를 켜두는 것 자체도 중요하지만, 누가 키를 다룰 수 있는지가 더 중요하거든요.

• 스토리지와 디스크의 기본 암호화가 활성화되어 있는지 확인합니다.
• KMS(Key Management Service, 키 관리 서비스) 또는 동등한 키 관리 체계를 사용 중인지 확인합니다.
• Secrets(시크릿, 비밀번호/토큰)와 인증서를 코드나 환경변수에 평문으로 두지 않는지 확인합니다.
• 백업 데이터도 동일한 수준으로 보호되는지 확인합니다.
• 복구 테스트가 실제로 수행되는지 확인합니다.

checklist:
  encryption_at_rest: true
  encryption_in_transit: true
  kms_key_access_review: monthly
  secret_rotation: enabled
  backup_retention_review: required
  restore_test: scheduled

저도 처음엔 백업만 있으면 된다고 생각했었는데, 복구 테스트를 안 하면 사실상 없는 거랑 비슷하더라고요. 백업 파일은 있는데 권한 문제나 키 문제로 복원이 안 되는 경우, 현장에서는 정말 난감합니다.

로깅, 암호화, 시크릿 관리, 백업 상태를 한눈에 보는 보안 감사 대시보드 예시 이미지입니다.

7. 실전 구현: 제가 쓰는 공통 감사 진행 순서

이 섹션은 제가 실제로 환경 점검할 때 자주 쓰는 흐름입니다. 완벽한 정답은 아니지만, 처음엔 이게 뭔가 싶었는데 몇 번 반복하니 누락이 확 줄었습니다.

1. 자산 목록 수집: 계정, 구독, 프로젝트, 네트워크, 스토리지, 컴퓨트, 데이터베이스를 먼저 나열합니다.
2. 권한 검토: 최고 권한 계정, 서비스 계정, 외부 협력사 계정, 장기 미사용 계정을 봅니다.
3. 외부 노출 확인: 퍼블릭 IP, 오픈 포트, 공개 버킷/스토리지, 직접 노출된 관리 포트를 찾습니다.
4. 로그/경보 확인: 감사 로그와 알림 체계가 빠지지 않았는지 확인합니다.
5. 암호화/백업 확인: 저장 데이터, 전송 데이터, 시크릿, 키 접근 제어, 복구 테스트 여부를 확인합니다.
6. 정책 위반 목록화: 우선순위를 나눠 즉시 수정, 계획 수정, 예외 승인으로 구분합니다.

# 예시: 결과를 수집해 파일로 남기는 매우 단순한 형태
mkdir -p audit-output
aws iam get-account-summary > audit-output/aws-account-summary.json
az role assignment list --all > audit-output/azure-role-assignments.json
gcloud projects get-iam-policy PROJECT_ID --format=json > audit-output/gcp-iam-policy.json

이렇게 결과를 남겨두면 다음 감사 때 비교가 쉬워집니다. 전월 대비 뭐가 늘었는지, 위험한 공개 설정이 새로 생겼는지 바로 보이거든요. 이전 글에서 다뤘던 자산 인벤토리 자동화와도 연결되는 부분이고, 다음 글에서는 정책 위반 항목을 자동으로 티켓화하는 방법도 다뤄볼 예정입니다.

8. ⚠️ 자주 겪는 문제와 트러블슈팅

8-1. MFA는 켰는데 예외 계정이 남아 있는 경우

사람 계정엔 MFA를 걸었는데 자동화 계정이나 오래된 관리자 계정은 빠져 있는 경우가 많습니다. 해결은 단순합니다. 사람 계정과 시스템 계정을 분리하고, 시스템 계정은 키 회전과 최소 권한으로 관리하면 됩니다.

8-2. 로그는 있는데 아무도 안 보는 경우

이거 진짜 흔합니다. CloudTrail, Activity Log, Audit Logs 다 켜놨는데 알림 연결이 없으면 나중에 사고 후 분석용으로만 남습니다. 최소한 관리자 권한 변경, 네트워크 규칙 변경, 감사 비활성화 시도는 알림 대상에 넣어두세요.

8-3. 공개 스토리지 예외가 누적되는 경우

정적 웹 호스팅이나 파일 공유 때문에 공개 접근 예외를 열어두는 경우가 있습니다. 근데 여기서 범위를 넓게 잡아버리면 나중에 어디까지 공개인지 아무도 모르게 됩니다. 예외는 기간, 사유, 승인자를 같이 기록해두는 습관이 필요합니다.

8-4. 멀티 클라우드라 기준이 제각각인 경우

이럴 때는 서비스별 문구를 맞추려 하지 말고 통제 항목을 공통 표준으로 잡으면 됩니다. 예를 들면 “관리자 권한 계정은 월 1회 검토” 같은 식으로요. AWS 보안, Azure 보안, GCP 보안을 같은 언어로 묶는 방식입니다.

9. 검증 결과 확인과 최종 정리

감사가 끝났다고 해서 문서만 남기면 반쪽입니다. 검증은 보통 아래처럼 끝내는 게 좋습니다.

• 고위험 항목이 실제로 줄었는지 확인합니다.
• 예외 정책이 문서화되었는지 확인합니다.
• 다음 감사 때 비교할 기준선(Baseline)을 저장합니다.
• 자동화 가능한 항목과 수동 확인 항목을 분리합니다.

제가 직접 해보니, 좋은 감사는 멋진 보고서보다 다음 달에도 반복 가능한 체크리스트를 남기는 쪽이 훨씬 가치가 컸습니다. 보안은 한 번 대청소하고 끝나는 일이 아니니까요. 결국 클라우드 보안 감사는 복잡한 기능을 다 외우는 싸움이 아니라, 기본 통제를 계속 유지하는 운영 습관의 문제였습니다.

감사 전후의 위험 항목 수 변화, 우선순위 분류, 조치 완료율을 시각적으로 보여주는 이미지입니다.

정리 체크리스트

1. 최고 권한 계정과 사람 계정에 MFA가 적용되어 있는가
2. 장기 액세스 키와 미사용 계정이 정리되어 있는가
3. 관리 포트와 데이터 저장소가 외부에 불필요하게 노출되지 않았는가
4. 감사 로그와 보안 경보가 활성화되어 있는가
5. 암호화, 시크릿 관리, 백업 복구 테스트가 점검되었는가
6. 예외 정책과 수정 이력이 문서화되어 있는가

자주 묻는 질문

Q. 클라우드 보안 감사는 얼마나 자주 해야 하나요?
최소 분기 단위로 권한과 외부 노출 점검은 권장드립니다. 변경이 잦은 환경이면 월 단위가 더 현실적입니다.

Q. 세 클라우드를 동시에 쓰면 도구도 반드시 통합해야 하나요?
반드시 그렇진 않습니다. 다만 점검 기준과 결과 포맷은 통합하는 게 운영 효율이 좋습니다.

Q. 처음 시작할 때 가장 중요한 한 가지는 뭔가요?
권한부터 보시면 됩니다. 로그보다 먼저라는 뜻은 아니고, 사고 확률과 영향도를 같이 보면 권한 정리가 가장 효과가 큽니다.

AWS, Azure, GCP 공통 보안 감사 체크리스트를 한 장으로 요약한 인포그래픽 이미지입니다.

오늘 내용은 공통 체크리스트 중심으로 정리해봤고, 다음 글에서는 각 클라우드별 관리형 보안 서비스와 정책 자동화 포인트를 더 깊게 다뤄보겠습니다. 혹시 이런 경험 있으신가요? 분명 설정은 맞는 것 같은데 감사에서 계속 비슷한 항목이 반복되는 경우요. 그런 환경일수록 체크리스트를 팀 표준으로 만드는 게 정말 중요합니다.