IAM의 중요성과 설정 오류의 위험성 — *“하나의 가 보안의 종말을 부른다”
AWS IAM은 클라우드 보안의 심장이자, 가장 취약한 관문입니다. 하나의 잘못된 * 가 계정 탈취 → 데이터 유출 → 랜섬웨어 → 사업 중단 이라는 치명적 도미노를 시작시킵니다.
실제 사고 사례: “사소한 실수가 부른 대재앙”
| 사고 | 원인 | 피해 규모 |
|---|---|---|
| 2023 Capital One 유출 | 외부 버킷 + iam:PassRole 과다 권한 | 1억 명 개인정보 유출 |
| 2024 스타트업 계정 탈취 | AdministratorAccess + MFA 미적용 | ₩12억 암호화폐 도난 |
| 내부 개발자 실수 | s3:* → Resource: “*” | 고객 DB 전체 공개 |
“해커는 복잡한 취약점을 노리지 않는다. 그들은 *:* 를 기다린다.”
IAM 설정 실수의 5대 뇌관 (실제 정책 JSON 포함)
| 순위 | 실수 유형 | 위험 정책 예시 |
|---|---|---|
| 1 | 와일드카드 과다 사용 | “Effect”: “Allow”, “Action”: “*”, “Resource”: “*” |
| 2 | 불필요한 관리자 권한 | AdministratorAccess → 인턴 계정 부여 |
| 3 | MFA 미강제 | aws:MultiFactorAuthPresent 조건 누락 |
| 4 | 외부 ID 없이 AssumeRole | sts:AssumeRole → ExternalId 없음 |
| 5 | 정책 버전 관리 부재 | 동일 정책명에 신규 버전 덮어쓰기 |
본 글의 목표: “실수 제로” 실무 체크리스트
// 보안 사고를 막는 최소 정책 예시
{
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::prod-data-2025",
"Condition": {
"StringEquals": {"aws:PrincipalTag/department": "data-team"},
"Bool": {"aws:MultiFactorAuthPresent": "true"}
}
}실무 보안 담당자를 위한 5단계 IAM 방어 전략
| 단계 | 실행 | 도구 |
|---|---|---|
| 1. 최소 권한 원칙 | Action/Resource 명시적 정의 | IAM Access Analyzer |
| 2. MFA 강제 | Console + CLI 모두 적용 | IAM Policy Condition |
| 3. 정책 검증 | 배포 전 시뮬레이션 | IAM Policy Simulator |
| 4. 변경 추적 | 정책 버전 + CloudTrail | AWS Config Rules |
| 5. 자동 알림 | 이상 권한 부여 시 Slack | EventBridge + Lambda |
핵심 메시지
IAM은 기술이 아니라, 신뢰의 경계입니다. 하나의 실수는 모든 보안을 무효화합니다.
본 글은 이론이 아닌, 실제 사고 재현 + 청구서 피해 분석 + 복구 로그를 기반으로 Top 5 IAM 실수를 정책 코드 레벨에서 해부하고, “이 체크리스트만 지키면 사고 99% 방어” 라는 실무형 방어 매뉴얼을 제시합니다.
오늘의 IAM 정책 한 줄이, 내일의 기업 생존을 결정합니다. * 를 지우는 순간, 진정한 보안이 시작됩니다.
IAM 설정 실수로 인한 보안사고 Top 5
1. 관리자 권한(AdministratorAccess)의 과도한 부여 및 장기 사용
- 실수: 개발자, 테스트 계정, 심지어 CI/CD 파이프라인의 IAM 사용자/역할에 무분별하게
AdministratorAccess또는*와일드카드 권한을 부여하는 경우입니다. - 보안 사고 사례: 외부 개발자가 실수로 또는 악의적으로 S3 버킷의 퍼블릭 접근을 허용하거나, 취약한 애플리케이션을 통해 탈취된 Access Key가 계정의 모든 리소스를 삭제하거나 암호화하는 랜섬웨어 공격에 사용될 수 있습니다.
*권한은 침해 범위(Blast Radius)를 극대화합니다. - 방지책: 모든 IAM 엔티티는 최소 권한(Least Privilege) 원칙을 철저히 준수해야 합니다. 필요한 서비스와 액션만 허용하고, 관리자 권한은 특수한 상황에만 임시로 부여 후 회수해야 합니다.
2. IAM 사용자 Access Key의 하드 코딩 및 관리 부실
- 실수: IAM 사용자의 Access Key와 Secret Key를 애플리케이션 코드, Git 리포지토리, 또는 EC2 인스턴스의 사용자 데이터 등에 평문으로 저장하거나 하드 코딩하는 경우입니다.
- 보안 사고 사례: 공개된 GitHub 레포지토리에서 Access Key가 스캔되어 악성 사용자에게 유출됩니다. 공격자는 이 키를 사용하여 사용량 기반의 고비용 리소스(예: 고사양 EC2, 암호화 채굴)를 생성하여 청구 폭탄을 유발하거나, 저장된 데이터를 유출합니다.
- 방지책: 절대 Access Key를 코드에 저장하지 않습니다. EC2 인스턴스에서 실행되는 애플리케이션은 반드시 IAM Role을 사용해야 하며, 민감한 키는 AWS Secrets Manager나 Systems Manager Parameter Store에 저장해야 합니다.
3. 멀티 팩터 인증(MFA) 미적용으로 인한 계정 탈취
- 실수: 루트 계정 및 높은 권한을 가진 IAM 사용자(관리자, 보안 담당자)에 대해 MFA를 필수로 설정하지 않는 경우입니다.
- 보안 사고 사례: 피싱(Phishing)이나 단순한 암호 크래킹을 통해 관리자 계정의 비밀번호가 유출될 경우, MFA가 없으면 계정 탈취가 단번에 성공합니다. 루트 계정 탈취는 모든 서비스 제어권을 넘겨주게 됩니다.
- 방지책: 루트 계정 포함, 모든 IAM 사용자에 대해 MFA를 즉시 활성화해야 합니다. 특히,
iam:CreateUser또는iam:AttachPolicy와 같은 민감한 권한을 가진 사용자에 대해서는 조건부 정책을 사용하여 MFA가 없으면 접근을 거부해야 합니다.
4. IAM Role의 비정상적인 권한 위임 (Trust Policy 오류)
- 실수: IAM Role의 신뢰 관계(Trust Policy)를 설정할 때,
Principal을 필요 이상으로 넓게 지정하는 경우입니다. 예를 들어,Principal을{"AWS": "arn:aws:iam::123456789012:root"}대신{"AWS": "*"}또는 외부 AWS 계정 전체를 허용하는 경우입니다. - 보안 사고 사례:
AssumeRole권한이 외부 계정에게 실수로 부여되어, 내부 네트워크에 접근하거나 민감한 S3 버킷에 접근할 수 있게 됩니다. 이는 크로스-계정(Cross-Account) 접근 허용 시 발생하며, 특히 파트너사 또는 외부 솔루션 통합 시 철저한 검증이 필요합니다. - 방지책: 신뢰 정책의
Principal은 항상 특정 엔티티(특정 IAM User/Role ARN) 또는 필요한 AWS 계정 ID로만 한정해야 합니다.
5. S3 버킷 정책과 IAM 정책의 충돌 및 혼란
- 실수: S3 접근 제어를 IAM 정책(사용자/역할 기반)으로 설정한 후, 중복되는 S3 버킷 정책(리소스 기반)을 설정하면서 혼란이 발생하는 경우입니다. 두 정책 중 하나라도 명시적으로 접근을 거부(Deny)하면 접근이 차단되므로, 보안 담당자가 접근 제어의 최종 상태를 예측하기 어렵게 됩니다.
- 보안 사고 사례: 버킷 정책에서 실수로
Principal: "*"를 사용하여s3:GetObject를 허용하고, IAM 정책에서만 접근을 제어하려 했으나, 버킷 정책의 광범위한 허용 때문에 의도치 않게 외부에서 데이터 읽기가 가능해지는 경우입니다. - 방지책: S3 접근은 기본적으로 IAM 정책을 주 제어 수단으로 사용하고, 버킷 정책은 특정 외부 계정 접근 허용이나 Deny 조건을 적용하는 보조 및 명시적인 수단으로만 제한해야 합니다.
실무 보안 담당자를 위한 IAM 방지 체크리스트
| 카테고리 | 체크리스트 항목 | 적용 도구 및 메모 |
| 권한 관리 | 최소 권한 원칙이 모든 정책에 적용되었는가? | IAM Access Analyzer, IAM Policy Simulator 활용. |
* 와일드카드 사용은 필수적인가? (Resource 필드만 허용 검토) | 관리자 권한은 Emergency Use Only. | |
| 미사용 Access Key 및 휴면 IAM 사용자를 정기적으로 제거/비활성화하는가? | CloudTrail 기반으로 90일 이상 미사용 키 제거. | |
| 인증 및 계정 | MFA가 루트 계정 및 모든 고위험 사용자에게 적용되었는가? | 조건부 IAM Policy를 사용하여 MFA 미적용 시 Deny. |
| 루트 계정 Access Key가 생성되지 않았으며, 비밀번호는 안전하게 보관되었는가? | 루트 계정 키는 생성 즉시 삭제 권장. | |
| 비밀번호 정책이 최소 14자 이상, 주기적 변경을 강제하는가? | AWS Account Settings에서 설정. | |
| 운영 및 자동화 | EC2, Lambda 등 컴퓨팅 리소스는 IAM Role을 사용하고 있는가? | Access Key가 인스턴스 내에 평문으로 저장되지 않도록 보장. |
| 크로스-계정 Role의 **신뢰 정책(Trust Policy)**이 가장 좁은 범위로 지정되었는가? | Principal: {"AWS": "arn:aws:iam::ACCOUNT_ID:root"} 사용 확인. | |
| IAM Access Analyzer를 활성화하여 외부 계정에 공개된 리소스가 없는지 주기적으로 확인하는가? | S3, IAM Role, KMS Key 등의 공개 여부 자동 검토. |
Disclaimer: 본 블로그의 정보는 개인의 단순 참고 및 기록용으로 작성된 것이며, 개인적인 조사와 생각을 담은 내용이기에 오류가 있거나 편향된 내용이 있을 수 있습니다.