개발자를 위한 AWS 클라우드 보안 (2) - 로깅 및 모니터링과 데이터 보호

AWS 다중 계정 환경에서 감사 로그를 중앙화하고 보안 이벤트를 감시하며 데이터를 암호화한 구축기다. CloudTrail과 서비스별 로그를 Log Archive 계정의 S3로 모으는 과정에서 cross-account 권한, CloudWatch export, S3 replication 제약을 해결한다. 이후 AWS Config 기반 규정 준수와 TLS·SSE·KMS를 이용한 데이터 보호 정책까지 연결한다.

핵심 포인트

CloudTrail뿐 아니라 WAF, GuardDuty, S3, VPC, DNS, ELB, CloudFront, DocumentDB, EKS 로그를 수집해 사고 조사에 필요한 근거를 남겼다.
모든 로그를 Control Tower의 Log Archive 계정으로 모아 접근 권한, 무결성, 보관 주기와 분석 환경을 한곳에서 관리했다.
CloudWatch 전용 로그는 Lambda가 4시간마다 확인하되 마지막 export 후 24시간이 지난 그룹만 S3로 내보내 비용을 통제했다.
CloudWatch Alarm과 custom metric으로 보안 그룹 변경 같은 이벤트를 Slack에 전달하고, AWS Config로 규정 위반을 지속 탐지했다.
전송 중에는 ACM 기반 TLS와 HTTP→HTTPS redirect를 강제하고, 저장 데이터는 S3 SSE·KMS·필요시 client-side encryption으로 보호했다.
데이터 중요도와 PII 여부를 tag로 표현해 버킷 생성, 접근 권한, 암호화, 보관 주기 정책을 자동 적용할 수 있게 했다.

상세 정리

로그 범위: CloudTrail은 역할, source IP, API·콘솔 행위, 요청 parameter를 기록한다. 여기에 WAF ACL, GuardDuty finding, VPC flow, DNS query, ELB·CloudFront access, DocumentDB audit·profiler, EKS control plane 로그를 더했다.
보관 정책: S3 object는 생성 90일 뒤 Glacier로 이동시키고 365일 또는 법정 기간 뒤 삭제했다. CloudWatch 자체 retention은 자동 삭제되므로 별도 백업 여부를 고려했다.
중앙화 이유: 계정마다 저장소를 두면 권한·보관 주기·모니터링을 반복 설정해야 한다. 보안 담당자만 Log Archive에 접근하게 해 단일 진실 공급원과 로그 접근 이력을 확보했다.
Cross-account 권한: 로그를 보내는 계정의 identity policy와 Log Archive S3의 resource policy를 모두 설정했다. WAF와 VPC Flow Log는 콘솔이 같은 계정 버킷만 허용해 CLI로 목적지를 지정했다.
CloudWatch export: DNS, DocumentDB, EKS 로그는 먼저 CloudWatch에 쌓인다. `ExportToS3: true` tag가 붙은 log group만 Lambda가 가져오고 Parameter Store의 마지막 export 시간을 기준으로 전송했다.
S3 access log: 목적지가 같은 계정 버킷이어야 해서 각 계정에 먼저 저장한 다음 bucket replication으로 중앙 계정에 복제했다. 원본은 lifecycle policy로 하루 뒤 삭제했다.
리전과 prefix: 서울과 버지니아 북부에 중앙 버킷을 각각 만들었다. CloudWatch export task UUID가 prefix에 끼는 불편은 남았지만 Organization, Account, Service, Region 구조로 조회 가능하게 했다.
모니터링 선택: OpenSearch·Kibana 대시보드는 활용도가 낮아 중단했고 당시 SIEM도 조직 상황에 맞지 않았다. CloudWatch dashboard, alarm, log filter로 필요한 패턴만 감시했다.
지속 준수: AWS Config로 설정 변경과 위반을 추적하고 간단한 항목은 remediation action으로 자동 복구했다. K-ISMS conformance pack으로 ISMS-P 기준을 적용하고 Audit 계정에서 전체 계정을 점검했다.
TLS 적용: CloudFront와 ALB에 ACM 인증서를 연결하고 HTTP 요청을 HTTPS로 redirect했다. CloudFront 인증서는 us-east-1에 있어야 하는 등 서비스별 리전 제약을 반영했다.
저장 암호화: S3 관리 키 SSE와 KMS 기반 SSE의 권한 차이를 구분했다. 인증키 자체가 유출되는 위협에는 별도 키와 애플리케이션 암·복호화가 필요한 client-side encryption을 검토했다.
KMS 데이터 키: 큰 데이터는 평문 data key로 로컬 암호화하고, KMS master key로 암호화된 data key를 데이터와 함께 저장한다. 복호화할 때만 KMS에서 실제 data key를 받아 사용하며 KMS의 연간 자동 rotation도 활용한다.
데이터 정책: Secure·Confidential·Internal·Public처럼 3~5단계로 분류하고 `DataClass`, `PII` tag를 붙인다. tag가 없는 버킷 생성 차단, PII 리소스 접근 제한, tag 변경 알림 같은 정책으로 이어진다.