국내 SaaS 기업인 한 곳은 AWS에서 6개월간 서비스를 운영하던 중 어느 날 갑자기 월 청구액이 2,000달러에서 18,000달러로 급증했다는 내용의 이상한 청구 이메일을 받았습니다.
조사 결과, 전 직원의 계정이 제때 삭제되지 않아 액세스 키가 유출된 것으로 드러났습니다. 해커들은 이 키를 이용해 여러 지역에서 고성능 GPU 인스턴스를 실행하여 암호화폐 채굴을 자행했습니다.
만약 그들이 애초에 AWS IAM을 올바르게 구성했더라면 이 사건은 완전히 피할 수 있었을 것입니다.
IAM(Identity and Access Management)은 AWS 계정 보안의 첫 번째 방어선이지만, 가장 쉽게 간과되는 부분이기도 합니다.
1. AWS IAM이란 무엇이며, 어떤 문제를 해결해 줍니까?
AWS IAM은 AWS에서 제공하는 ID 및 액세스 관리 서비스입니다. 핵심 기능은 다음과 같습니다...AWS 리소스에 대한 액세스 권한과 수행 가능한 작업을 제어하세요..
IAM이 없는 세상에서는 어떤 일이 벌어질까요?
- 모든 사용자는 루트 계정의 사용자 이름과 비밀번호를 공유합니다.
- 인턴은 CTO와 동일한 권한을 갖습니다.
- 외부 파트너가 S3 버킷에 액세스할 때 모든 RDS 데이터베이스도 볼 수 있습니다.
IAM을 사용하면 정밀한 제어가 가능합니다.
- WHO(인사/시스템) 접근 가능
- 어느AWS 서비스 및 리소스
- 어떤 작전인가요?(읽기/쓰기/삭제/관리)
- 어떤 조건에서(IP 제한/시간 제한/다단계 인증)
IAM은 무료 서비스이며 추가 요금이 없습니다.
II. IAM의 네 가지 핵심 개념
실제로 적용하기 전에 먼저 IAM의 기본 구성 요소를 이해해야 합니다.
1. IAM 사용자
~을 나타냅니다특정인 또는 신청서각 IAM 사용자는 고유한 로그인 자격 증명(사용자 이름 + 암호 또는 액세스 키)을 가지고 있습니다.
적합한 시나리오:
- 개발팀 구성원 각자를 위한 개별 계정을 만드세요.
- 자동화 스크립트/CI/CD 도구 전용 계정을 생성하세요.
2. IAM 사용자 그룹
여러 사용자를 하나의 그룹으로 묶어 권한을 통합 관리할 수 있습니다. 사용자 그룹에 정책을 할당하면 그룹 내 모든 사용자가 자동으로 해당 정책을 상속받습니다.
적합한 시나리오:
- 개발팀, 운영팀, 데이터팀 각각에게 서로 다른 권한이 부여되었습니다.
- 신규 직원은 별도의 권한 설정 없이 해당 그룹에 자동으로 추가됩니다.
3. IAM 정책
전략은 다음과 같습니다.권한 규칙이 담긴 JSON 문서"어떤 작업이 허용되거나 거부되는지"를 정의합니다.
AWS는 두 가지 유형의 전략을 제공합니다.
- AWS 관리형 정책일반적으로 사용되는 AWS 정책으로는 AdministratorAccess 및 ReadOnlyAccess 등이 있습니다.
- 고객 맞춤형 전략사용자 맞춤형 전략을 통해 더욱 정밀한 플레이가 가능합니다.
4. IAM 역할
그 캐릭터는"일시적으로 가정할 수 있는" 권한정해진 사용자 이름과 비밀번호는 없습니다.
적합한 시나리오:
- EC2 인스턴스가 S3에 액세스해야 합니다(코드에 액세스 키를 작성하는 대신 EC2 인스턴스에 역할을 바인딩하는 방식).
- 계정 간 액세스(A 계정의 서비스가 B 계정의 리소스에 액세스하는 것)
- GitHub Actions와 같은 타사 서비스를 AWS 계정에 배포하기
| 개념 | 유추 | 핵심 용도 |
|---|---|---|
| IAM 사용자 | 직원 ID 배지 | 특정 담당자/시스템의 로그인 ID |
| IAM 사용자 그룹 | 부서 | 동일 유형 사용자에 대한 권한 일괄 관리 |
| IAM 전략 | 권한 목록 | 할 수 있는 것과 할 수 없는 것을 정의하십시오. |
| IAM 역할 | 임시 방문객 출입증 | AWS 서비스 간/계정 간 임시 권한 |
III. 최소 권한 원칙: IAM 보안의 핵심 개념
IAM 권한을 구성하기 전에 한 가지 원칙을 명심해야 합니다.
최소 권한의 원칙
각 사용자/역할/서비스에 필요한 권한만 정확하게 부여하고, 불필요한 권한은 주지 마십시오.
이는 다음을 의미합니다.
- 개발자는 개발 환경에서 EC2 및 RDS에 대한 액세스 권한만 있으면 되며, 프로덕션 환경 권한은 필요하지 않습니다.
- 데이터 분석가에게는 S3 읽기 권한만 필요하고 EC2 부팅 권한은 필요하지 않습니다.
- Lambda 함수는 DynamoDB에 대한 쓰기 권한만 필요하고 S3에 대한 읽기 권한은 필요하지 않습니다.
많은 회사들이 시간을 절약하려는 목적으로 모든 직원에게 관리자 권한을 부여하는데, 이는 매우 위험한 관행입니다.
IV. 실습 구성: 처음부터 안전한 IAM 시스템 구축하기
1단계: 루트 계정 보호
루트 계정은 AWS 계정 시스템에서 "가장 높은 권한"을 가진 계정이며, 이 계정이 탈취될 경우 그 결과는 예측할 수 없습니다.
루트 계정을 안전하게 유지하기 위한 세 가지 사항:
- 다중 요소 인증(MFA)을 활성화하세요AWS 콘솔에서 보안 자격 증명 → MFA 활성화로 이동하여 인증 앱을 휴대폰에 연결하세요.
- 액세스키를 생성하지 마십시오.루트 계정에 대한 프로그래밍 액세스 키를 생성하지 마십시오.
- 청구 관리 용도로만 사용 가능IAM 사용자 계정으로 전환하여 모든 일상적인 작업을 완료했습니다.
2단계: 관리자 IAM 사용자 생성
일상적인 운영 및 유지 관리를 위해 IAM 콘솔에 관리자 사용자를 생성하여 로그인에 사용되는 루트 계정을 대체하십시오.
구성 지점:
- 사용자 이름은 본인의 실명 또는 직원 ID여야 합니다. 예: admin-zhangsan
- 액세스 유형: "AWS 관리 콘솔을 통한 액세스"를 선택하세요.
- 접근 제어 정책: 관리자 접근 권한 추가(정당한 관리자만 사용 가능)
- 이 사용자에게는 MFA(다단계 인증)도 활성화되어 있습니다.
앞으로는 이 IAM 사용자를 사용하여 AWS에 로그인하십시오. 루트 계정은 향후 사용을 위해 잠금 상태로 유지하십시오.
3단계: 사용자 그룹을 생성하고 권한을 할당합니다.
팀 기능에 따라 사용자 그룹을 생성하고 각 그룹에 해당하는 전략을 할당합니다.
권장되는 기본 사용자 그룹 구성:
| 사용자 그룹 이름 | 적합한 인력 | 추가적인 전략이 권장됩니다. |
|---|---|---|
| 개발자 | 개발 엔지니어 | Amazon EC2 전체 액세스 + Amazon S3 전체 액세스 (개발 환경 전용) |
| 데이터 분석가 | 데이터 분석가 | AmazonS3ReadOnlyAccess + AmazonAthenaFullAccess |
| 데브옵스 | 운영 엔지니어 | 파워 유저 액세스(IAM 관리자 권한 제외) |
| 청구 | 재무/경영 | AWSBillingReadOnlyAccess |
| 읽기 전용 | 감사/준수 | 읽기 전용 액세스 |
4단계: EC2/Lambda에 대한 IAM 역할 구성
이 단계는 가장 쉽게 간과되는 부분이며, 안전사고 발생 위험이 매우 높은 부분이기도 합니다.
잘못된 관행이는 액세스 키 ID와 비밀 키를 EC2 인스턴스의 코드 또는 구성 파일에 직접 기록하는 것을 의미합니다. 이러한 키가 GitHub에 제출되거나 유출되면 공격자는 즉시 이를 사용할 수 있습니다.
올바른 접근 방식IAM 역할을 생성하고 EC2 인스턴스에 연결합니다.
구체적인 단계:
- IAM 콘솔 → 역할 → 역할 생성
- 신뢰할 수 있는 엔티티로 "AWS 서비스" → "EC2"를 선택하십시오.
- 추가적으로 필요한 전략(예: Amazon S3 ReadOnlyAccess)
- 캐릭터에 ec2-s3-readonly-role과 같은 이름을 지정하세요.
- EC2 인스턴스 설정에서 이 역할을 인스턴스에 연결합니다.
EC2 인스턴스의 코드는 인스턴스 메타데이터에서 임시 자격 증명을 자동으로 가져오므로 코드에 키를 하드코딩할 필요가 없습니다.
5단계: 맞춤형 세부 전략 수립
AWS 관리형 정책이 충분히 세분화되어 있지 않은 경우 사용자 지정 정책을 생성해야 합니다.
일반적인 시나리오: 모든 S3 버킷이 아닌 특정 S3 버킷만 사용자가 읽을 수 있도록 허용하는 경우.
맞춤형 전략의 핵심 요소는 다음 네 가지 분야를 포함합니다.
- 효과허용 또는 거부
- 행동s3:GetObject 및 ec2:DescribeInstances와 같은 특정 API 작업
- 의지특정 리소스의 ARN(Amazon Resource Name)을 입력하세요. 와일드카드 사용이 지원됩니다.
- 상태(선택 사항): IP 제한, 다단계 인증(MFA) 요구 사항과 같은 추가 조건
"읽기 전용 특정 S3 버킷"을 예로 들면, 전략 논리는 다음과 같습니다. s3:GetObject 및 s3:ListBucket 두 작업의 실행을 허용하되, 모든 S3 리소스가 아닌 특정 버킷의 ARN으로 접근 권한을 제한합니다.
V. 고급 IAM 보안: 쉽게 간과되는 4가지 핵심 설정
암호 정책 설정
IAM 콘솔 → 계정 설정 → 암호 정책에서 다음을 구성하는 것이 좋습니다.
- 최소 비밀번호 길이: 12자 이상
- 대문자, 소문자, 숫자 및 특수 기호를 모두 포함해야 합니다.
- 비밀번호 유효 기간: 90일
- 최근 사용한 비밀번호 5개를 재사용하지 마세요.
액세스키를 정기적으로 검토하고 교체하십시오.
IAM의 "자격 증명 보고서" 기능을 사용하면 모든 사용자의 액세스 키 사용 정보를 내보낼 수 있습니다. 여기에는 다음이 포함됩니다.
- 열쇠를 90일 이상 돌리지 않았습니까?
- 해당 키는 한 번도 사용된 적이 없습니까(즉시 삭제해야 합니까)?
- 사용자의 마지막 로그인 시간 (사용자가 장기간 로그인하지 않은 경우 이 기능을 비활성화해야 할 수 있습니다).
분기별로 영수증 감사를 실시하는 것이 좋습니다.
AWS CloudTrail에서 모든 IAM 작업 로그를 기록하도록 설정
CloudTrail은 IAM 구성 변경, 사용자 로그인 및 리소스 액세스를 포함하여 계정 내의 모든 API 호출을 기록합니다.
이는 보안 사고의 원인을 추적하는 데 있어 핵심적인 도구입니다. 이상 징후가 발생하면 어떤 사용자/역할/서비스가 어떤 작업을 언제 수행했는지 정확하게 파악할 수 있습니다.
CloudTrail 로그를 S3에 동기화하고 암호화된 저장소를 활성화하여 최소 1년 동안 보관하는 것이 좋습니다.
권한 경계를 활용하세요.
DevOps 리더와 같은 하위 관리자에게 IAM 사용자 생성 권한을 부여해야 하지만, 그들이 생성하는 사용자 권한이 본인의 권한을 초과할까 봐 걱정될 경우 "권한 경계" 기능을 사용할 수 있습니다.
권한 경계는 사용자 또는 역할을 정의합니다.사용자가 가질 수 있는 최대 권한 수정책에 더 높은 권한이 명시되어 있더라도 실제 실행은 여전히 경계 제한의 적용을 받습니다.
VI. 일반적인 IAM 문제 해결
질문 1: 로그인 시 사용자에게 "액세스 거부됨"이라는 메시지가 표시됩니다.
수사 명령:
- 사용자가 정책의 적용을 받는지 (또는 사용자 그룹에 정책이 있는지) 확인하십시오.
- 리소스 ARN이 올바르게 작성되었는지 확인하십시오(많은 사람들이 ARN을 잘못 작성합니다).
- 허용 정책을 재정의하는 명시적인 거부 정책이 있는지 확인하십시오(거부 정책이 더 높은 우선순위를 가집니다).
질문 2: EC2가 S3에 접근할 수 없습니다
가장 일반적인 이유는 EC2 인스턴스가 IAM 역할에 바인딩되어 있지 않거나, 바인딩된 역할 정책에 S3 권한이 포함되어 있지 않기 때문입니다.
질문 3: 계정 간 액세스에 실패했습니다.
액세스하는 계정의 리소스 정책이 다른 계정의 ARN을 허용하도록 양쪽 모두 구성해야 하며, 액세스하는 계정의 사용자/역할에 가정한 대상 역할의 권한이 부여되어 있어야 합니다(sts:AssumeRole).
결론적으로
AWS IAM 구성은 복잡해 보일 수 있지만 핵심 로직은 실제로 매우 간단합니다.최소 권한, 역할 기반 키 및 주기적 감사.
이 세 가지를 실천하면 80%의 클라우드 보안 위험을 피할 수 있습니다.
초기에 거의 2만 달러의 손실을 입을 뻔했던 이 회사는 "직원마다 고유한 IAM 사용자를 생성하고 퇴사 시 즉시 계정을 삭제"했더라면 이러한 사고를 겪지 않았을 것입니다.
클라우드 보안 비용은 종종 부주의가 발생한 순간에 이미 결정됩니다.
AWS 환경을 설정 중이거나 기존 IAM 구성이 안전한지 확신이 서지 않는 경우,aws-oncloudai.com에서 기술 지원팀에 문의해 주세요.저희는 무료 AWS 계정 보안 평가 서비스를 제공합니다.
이 글은 aws-oncloudai.com 클라우드 아키텍처 팀에서 작성한 것입니다. 재인쇄 시 출처를 명시해 주시기 바랍니다.
