개발자를 위한 AWS 클라우드 보안 (1) - 클라우드 설계 원칙과 IAM

AWS Well-Architected Framework를 기준으로 5개월 동안 클라우드 보안을 강화한 시리즈의 첫 편이다. 단일 AWS 계정을 서비스·환경별 다중 계정 구조로 바꾸고 SSO, Control Tower, Organizations, Guardrails로 중앙 관리했다. 자격 증명과 최소 권한, cross-account resource policy, 운영 문서까지 IAM을 조직 규모에 맞게 적용한 과정이 핵심이다.

핵심 포인트

단일 계정은 팀·환경 간 리소스 격리와 사고 영향 범위 통제가 어려워 서비스와 환경별 다중 계정으로 전환했다.
AWS SSO에서 사용자 개인이 아닌 직군별 group, 재사용 가능한 permission set, 접근 대상 account를 조합했다.
Control Tower와 Organizations로 계정을 OU에 묶고 예방·탐지형 Guardrails를 중앙에서 적용했다.
Access Key 발급을 최소화하고 애플리케이션에는 key 대신 필요한 권한의 role을 부여했다.
최소 권한은 처음부터 모든 action을 세분화하지 않고 서비스 full access부터 구체 action까지 단계적으로 줄였다.
Cross-account 접근은 요청 계정의 identity policy와 대상 리소스의 resource policy가 모두 필요하다.

상세 정리

개선 배경: 스캐터랩은 AWS Well-Architected의 운영, 보안, 안정성, 성능, 비용, 지속 가능성 원칙 중 보안을 우선했다. 권한 관리, 로깅, 데이터 보호, 인프라 보안, 사고 대응의 다섯 영역으로 작업을 나눴다.
단일 계정 문제: 모든 개발자와 팀의 EC2·S3·RDS가 한 계정에 섞여 팀별 권한과 dev·prod 격리가 어려웠다. 한 사람의 실수나 침해가 다른 팀 리소스까지 영향을 줄 수 있었다.
다중 계정: 서비스와 환경별로 계정을 나눠 리소스와 blast radius를 자연스럽게 격리했다. 사용하지 않는 리소스와 비용도 계정 단위로 파악하기 쉬워졌다.
SSO 설계: 로그인 주체는 직군별 SSO group으로 관리해 인원 변동 시 group만 수정했다. 권한은 permission set으로 분리해 같은 group과 권한 묶음을 여러 account에서 재사용했다.
Control Tower: Account Factory로 계정 생성과 federation을 단순화하고 중앙 관리 기반을 만들었다. Organizations의 OU 트리로 서비스·팀·환경 계정을 묶고 비용도 management account에서 통합했다.
예방형 Guardrail: CloudTrail 비활성화처럼 금지할 동작을 Service Control Policy로 차단한다. 계정의 IAM이 허용해도 SCP deny가 우선하므로 과도한 적용은 개발 생산성을 해칠 수 있다.
탐지형 Guardrail: 외부에 공개된 S3처럼 위험한 설정을 막지는 않되 Control Tower에 알린다. 조직 요구에 따라 기본 규칙 외에 custom guardrail을 추가했다.
보안 계정: Control Tower가 만든 Log Archive에는 모든 계정의 보안 로그를 모으고 Audit 계정은 로그 분석과 규정 준수 점검에 사용했다.
자격 증명: SSO에 MFA와 비밀번호 정책을 적용하고 Access Key의 발급·사용·말소 이력을 관리했다. GitHub Actions 외 목적은 다른 대안이 없는지 검토하고, S3 접근에는 key 대신 read-only role을 제공했다.
점진적 최소 권한: AWS action을 전체, 서비스 전체, 읽기·쓰기, 구체 action 네 수준으로 나눴다. 팀과 직무가 쓰는 서비스를 조사해 2~4수준을 혼합하고 Access Advisor로 90일 이상 미사용 권한을 정리했다.
Resource policy: 같은 계정에서도 리소스 정책의 allow가 권한을 만들 수 있어 별도 관리가 필요하다. 다른 계정의 ECR을 쓰는 경우 호출 계정의 pull 권한과 repository의 cross-account allow를 모두 설정했다.
문서화: 계정·OU 구조, Guardrail, 로그인 정책, permission set, resource policy, key 발급 이력, EKS role 사용과 디버깅 방법을 한곳에 모으고 변경 이력을 남겼다.
균형: 계정 구조는 workload가 쌓인 뒤 바꾸기 어렵지만 IAM을 지나치게 세분화하면 권한 요청이 폭증한다. 개발 효율과 보안팀 운영 비용 사이에서 단계적으로 강화했다.