[Cloud] AWS IAM 권한 설계 베스트 프랙티스 - CISA GovCloud 키 유출 사건으로 배우는 클라우드 보안

목차

• AWS IAM 권한 설계 베스트 프랙티스 - CISA GovCloud 키 유출 사건으로 배우는 클라우드 보안
• AWS IAM, 최소 권한 원칙(Principle of Least Privilege)이란?
• 실전 구현: AWS IAM 권한 설계 베스트 프랙티스
• ⚠️ 주의사항 및 트러블슈팅: 삽질은 나의 힘!
• AWS Access Analyzer를 통한 최종 검증
• 마무리하며: 보안은 끝이 없는 마라톤!

AWS IAM 권한 설계 베스트 프랙티스 - CISA GovCloud 키 유출 사건으로 배우는 클라우드 보안

안녕하세요, 13년차 서버실 지킴이 '13년차의 서버실'입니다. 오늘은 최근 발생했던 흥미롭지만 무서운 사건을 통해 AWS IAM 권한 설계의 중요성을 다시 한번 되짚어보려고 합니다. 바로 CISA (Cybersecurity and Infrastructure Security Agency)의 AWS GovCloud 키 유출 사건인데요. 미국 연방 기관에서 이런 보안 사고가 터졌다는 소식을 듣고 저도 처음엔 '설마 저런 일이...' 싶었는데, 내용을 살펴보니 우리가 평소에 간과하기 쉬운 부분에서 발생한 문제더라고요.

솔직히 인프라 엔지니어라면 누구나 한 번쯤은 '빨리 배포해야 하는데', '이거 권한 없어서 안 되네, 그냥 다 열어버릴까?' 하는 유혹에 빠져본 적 있을 겁니다. 저도 처음엔 이게 뭔가 싶어서 그냥 `*` (와일드카드)로 대충 권한 설정했다가 나중에 등골이 오싹했던 경험이 있거든요. 실제로 이런 클라우드 보안 사고가 터지면 수습하기 정말 힘들고, 기업 이미지에도 치명타를 입을 수 있습니다. 그래서 오늘은 CISA 사건을 교훈 삼아, AWS IAM(Identity and Access Management) 권한 설계를 어떻게 해야 안전하고 효율적으로 할 수 있을지, 제 삽질 경험을 녹여서 이야기해볼까 합니다.

클라우드 환경에서 IAM은 단순한 사용자 관리를 넘어 전체 보안의 핵심입니다.

AWS IAM, 최소 권한 원칙(Principle of Least Privilege)이란?

본격적인 이야기에 앞서, 핵심 개념인 AWS IAM과 최소 권한 원칙(Principle of Least Privilege)에 대해 잠깐 짚고 넘어갈게요.

• AWS IAM (Identity and Access Management, 아이덴티티 및 접근 관리): AWS 클라우드 리소스에 대한 접근을 안전하게 관리하는 웹 서비스입니다. 누가 어떤 리소스에 어떤 작업을 할 수 있는지 정의하는 역할을 하죠. 쉽게 말해, '회사 문지기'라고 생각하시면 편합니다. 누가 회사에 들어올 수 있고(인증), 어디까지 갈 수 있는지(권한 부여)를 결정하는 거죠.
• 최소 권한 원칙 (Principle of Least Privilege): 이 원칙은 '필요한 최소한의 권한만 부여하라'는 강력한 보안 철학입니다. 예를 들어, 웹 서버가 S3 버킷에 파일을 업로드해야 한다면, S3에 파일을 읽고 쓰는 권한만 주면 됩니다. S3의 모든 설정 변경 권한이나 다른 서비스의 권한까지 줄 필요는 없다는 거죠. CISA 사건도 이 최소 권한 원칙이 제대로 지켜지지 않아 발생한 부분이 크다고 볼 수 있습니다.

AWS IAM은 크게 IAM 사용자(User), IAM 그룹(Group), IAM 역할(Role), 그리고 이들의 권한을 정의하는 정책(Policy)으로 구성됩니다. 이 네 가지 요소를 잘 조합해서 안전한 환경을 만드는 게 핵심이에요.

실전 구현: AWS IAM 권한 설계 베스트 프랙티스

자, 이제 저의 홈랩에서 직접 적용하고 있는 AWS IAM 권한 설계 베스트 프랙티스 몇 가지를 소개해드릴게요. 이건 제가 직접 여러 번의 삽질 끝에 깨달은 소중한 경험들이거든요.

1. 루트 사용자(Root User)는 금고에! MFA(Multi-Factor Authentication)는 필수!
   AWS 계정을 처음 만들면 '루트 사용자'가 생성되죠? 이 루트 사용자는 계정의 모든 권한을 가지고 있는 슈퍼 계정입니다. 절대! 일상적인 작업에 사용하면 안 됩니다. 저도 처음엔 그냥 루트 계정으로 다 했었는데, 나중에 보안 교육을 받고 식겁했어요. 루트 사용자는 계정 생성 후 한 번만 사용해서 IAM 사용자를 만들고, 강력한 암호와 함께 MFA (Multi-Factor Authentication, 다단계 인증)를 설정한 뒤 금고에 넣어두세요. 그리고 다시는 사용하지 않는 것이 좋습니다. 혹시 아직 MFA 설정 안 하셨다면 지금 당장 설정하세요! ⚠️
2. IAM 사용자(User) 대신 IAM 역할(Role)을 적극 활용하세요!
   많은 분들이 EC2 인스턴스나 람다(Lambda) 함수에 권한을 줄 때, IAM 사용자 자격 증명(Access Key, Secret Key)을 직접 코드에 하드코딩하는 경우가 있습니다. 절대 금물입니다! 이 키가 유출되면 CISA 사건처럼 큰일 날 수 있어요. 대신 IAM 역할(Role)을 사용해야 합니다. IAM 역할은 특정 AWS 서비스나 사용자가 임시 자격증명을 자동으로 받아서 다른 리소스에 접근할 수 있게 해주는 기능이거든요. 키를 직접 관리할 필요가 없어서 훨씬 안전하고 편리하죠.

   {
       "Version": "2012-10-17",
       "Statement": [
           {
               "Effect": "Allow",
               "Action": [
                   "s3:PutObject",
                   "s3:GetObject",
                   "s3:ListBucket"
               ],
               "Resource": [
                   "arn:aws:s3:::my-secure-bucket",
                   "arn:aws:s3:::my-secure-bucket/*"
               ]
           }
       ]
   }

   이 역할은 <code>my-secure-bucket이라는 S3 버킷에 대해서만 객체를 넣고, 가져오고, 버킷 내용을 나열하는 최소한의 권한만 부여합니다. 🎉
3. 예를 들어, EC2 인스턴스가 S3 버킷에 파일을 업로드해야 한다면, 다음과 같은 정책을 가진 IAM 역할을 만들어서 EC2 인스턴스에 할당하면 됩니다.
4. 최소 권한 원칙에 기반한 정책(Policy) 설계
   위 예시처럼, 필요한 최소한의 작업(Action)과 리소스(Resource)만 명시하는 커스텀 정책(Custom Policy)을 만드는 습관을 들여야 합니다. AWS에서 제공하는 관리형 정책(Managed Policy)도 편리하지만, 너무 포괄적인 권한을 포함하는 경우가 많아요. 예를 들어, AmazonS3FullAccess 정책은 S3의 모든 작업을 허용하는데, 이건 대부분의 경우 과도한 권한입니다. 제가 직접 해보니 커스텀 정책이 손은 더 가지만, 훨씬 안전하더라고요. 처음엔 좀 어렵게 느껴질 수 있지만, 몇 번 만들어보면 익숙해집니다.
5. 조건 키(Condition Keys)를 활용한 정교한 제어
   IAM 정책은 단순히 '누가 무엇을 할 수 있는가'를 넘어, '언제, 어디서, 어떻게' 할 수 있는가까지 제어할 수 있습니다. 바로 조건 키(Condition Keys)를 활용하는 건데요. 특정 IP 주소 대역에서만 접근을 허용하거나, MFA 인증이 된 사용자만 특정 작업을 수행할 수 있도록 강제하는 등의 설정이 가능합니다. CISA 사건처럼 키가 유출되더라도, 추가적인 조건이 없다면 접근을 막을 수 있는 강력한 방어선이 됩니다.위 정책은 203.0.113.0/24 IP 대역에서 MFA 인증을 거친 사용자만 S3 객체를 가져올 수 있도록 허용합니다. 💡
6. {
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::my-secure-bucket/*",
"Condition": {
"IpAddress": {
"aws:SourceIp": "203.0.113.0/24"
},
"Bool": {
"aws:MultiFactorAuthPresent": "true"
}
}
}
]
}
7. AWS Access Analyzer로 권한 검토하기
   아무리 열심히 정책을 설계해도, 사람인지라 실수는 할 수 있습니다. 이때 AWS Access Analyzer가 정말 큰 도움이 됩니다. 이 서비스는 외부 엔티티(다른 AWS 계정, IAM 사용자, 역할 등)가 내 계정의 리소스(S3 버킷, SQS 큐 등)에 접근할 수 있는 경로를 분석하고 경고해줍니다. 제가 직접 써보니 예상치 못한 경로로 외부에 리소스가 공유된 걸 찾아내서 바로 조치할 수 있었어요. 정기적으로 Access Analyzer를 돌려 외부 접근 권한을 점검하는 습관을 들이는 게 좋습니다.

Access Analyzer는 예상치 못한 권한 설정을 찾아내고 시각적으로 경고해줍니다.

⚠️ 주의사항 및 트러블슈팅: 삽질은 나의 힘!

저도 AWS IAM 권한 설계를 하면서 수많은 삽질을 했습니다. 여러분은 저 같은 실수 하지 마시라고 몇 가지 팁을 공유해드려요.

• 와일드카드(`*`) 사용은 정말 신중하게!
  특히 Action: "*"이나 Resource: "*"는 치명적일 수 있습니다. 처음엔 귀찮아서 이렇게 줬다가 나중에 '아차!' 싶었던 적이 한두 번이 아니거든요. 항상 필요한 최소한의 범위만 지정하는 연습을 해야 합니다.
• IAM Policy Simulator로 미리 테스트해보세요
  정책을 만들었는데 제대로 작동하는지 확신이 없을 때, IAM Policy Simulator를 사용하면 아주 유용합니다. 특정 사용자/역할이 특정 리소스에 대해 특정 작업을 수행할 수 있는지 시뮬레이션해볼 수 있거든요. 이거 써보니 삽질 많이 줄었습니다. '아, 이렇게 하면 되는구나!' 하고 바로 알 수 있어서 진짜 편하더라고요.
• 너무 빡빡한 권한은 오히려 문제!
  최소 권한 원칙도 좋지만, 너무 권한을 빡빡하게 설정해서 정작 필요한 작업이 안 되는 경우도 있습니다. 예를 들어, S3 버킷에 객체를 업로드하는 권한만 줬는데, 버킷 리스트를 볼 수 없어서 디버깅이 어려운 경우가 있었어요. 이때는 임시로 디버깅용 권한을 추가했다가, 문제 해결 후 다시 최소 권한으로 돌리는 유연함도 필요하더라고요. 역시 디버깅이 중요하더라고요.

정책 적용 전 IAM Policy Simulator로 미리 검증하면 불필요한 오류를 줄일 수 있습니다.

AWS Access Analyzer를 통한 최종 검증

권한 설정을 모두 마쳤다면, 다시 한번 AWS Access Analyzer를 통해 점검하는 과정을 거쳐야 합니다. 저는 이 과정을 습관처럼 하고 있는데요, 실제로 개발팀에서 실수로 특정 S3 버킷을 'Public'으로 열어둔 것을 Access Analyzer가 잡아내서 바로 수정했던 경험이 있습니다. 이렇게 검증하는 과정이 진짜 중요합니다. 단순한 실수가 큰 보안 사고로 이어질 수 있거든요.

Access Analyzer는 지속적으로 계정을 모니터링하여 예상치 못한 외부 접근을 감지하고, 이에 대한 상세한 보고서를 제공합니다. 이 보고서를 바탕으로 정책을 조정하거나, 문제가 되는 설정을 수정하는 것이 중요합니다. ✅

마무리하며: 보안은 끝이 없는 마라톤!

오늘은 CISA AWS GovCloud 키 유출 사건을 통해 AWS IAM 권한 설계의 중요성과 베스트 프랙티스에 대해 이야기해봤습니다. 13년차 인프라 엔지니어로 살아오면서 느낀 건데, 보안은 정말 끝이 없는 마라톤과 같아요. 한 번 설정했다고 끝이 아니라, 지속적으로 검토하고 개선해야 합니다.

오늘 제가 소개해드린 내용은 AWS IAM 권한 설계의 기본적인 베스트 프랙티스이지만, 이것만 잘 지켜도 대부분의 보안 위협으로부터 계정을 안전하게 보호할 수 있을 겁니다. 특히 최소 권한 원칙과 IAM 역할 활용은 꼭 기억해주세요. 혹시 이 글을 읽고 여러분의 AWS 환경을 다시 한번 점검해보는 계기가 된다면, 정말 기쁠 것 같네요.

다음 글에서는 AWS GuardDuty나 Security Hub 같은 다른 보안 서비스들을 활용한 클라우드 보안 강화 방안에 대해 다뤄볼까 합니다. 기대해주세요! 👋

안전한 AWS 환경을 위한 IAM 베스트 프랙티스 요약.

📚 함께 읽으면 좋은 글

• GitLab CI/CD, 월 300달러 린트 비용 낭비 막는 법
• 기존 인프라를 Pulumi로 전환하기: 마이그레이션 전략 및 체크리스트
• Jenkins 빌드 실패 디버깅: 흔한 문제와 해결 전략 5가지