AWS IAM 보안 모범 사례 — 과도하게 허용된 접근이 가장 큰 클라우드 위험인 이유
Source: Dev.to
TL;DR
나는 작년에 시리즈 A 스타트업의 AWS 계정을 감사했다. 개발자 7명 모두 AdministratorAccess 권한을 가지고 있었다. 회사를 떠난 사람들의 비활성 계정 3개가 여전히 활성화돼 있었고, 여전히 전체 권한을 가지고 있었다. MFA가 설정되지 않은 루트 계정. 18 개월 동안 API 키 교체가 이루어지지 않았다. 이것은 드문 일이 아니라 일반적인 상황이다. IAM 잘못된 구성은 클라우드 공격 벡터 1위이며, 이를 고치는 데 비용은 들지 않고 시간만 투자하면 된다. 바로 고쳐야 할 사항은 다음과 같다.
왜 IAM이 중요한가
AWS Identity and Access Management (IAM) 은 AWS 계정에서 누가 무엇을 할 수 있는지를 제어하는 시스템입니다. 모든 API 호출, 모든 콘솔 로그인, 클라우드 인프라를 건드리는 모든 자동화 프로세스는 IAM을 거칩니다.
IAM이 잘못 구성되면 다른 모든 보안 제어가 무력화됩니다 — 올바른 IAM 자격 증명을 가진 공격자는 다음을 할 수 있습니다:
- 데이터를 읽고,
- 인프라를 수정하고,
- 백업을 삭제하고,
- 구축한 모든 것을 유출합니다.
CrowdStrike 2025 Global Threat Report에 따르면, 2024년 클라우드 관련 침해가 전년 대비 75 % 증가했으며, 자격 증명 기반 공격과 IAM 잘못 구성이 일관되게 주요 진입점으로 지목되었습니다. 이는 정교한 공격 유형이 아니라, 처음부터 올바르게 구성되지 않은 접근 제어를 악용한 사례입니다.
흔히 보는 문제들
-
모두가
AdministratorAccess를 가지고 있음
AdministratorAccess는 모든 직원에게 회사의 모든 시스템, 데이터베이스, 설정에 대한 마스터 키를 주는 AWS 버전입니다. 초기에는 개발자들이 빠르게 움직이기 위해 필요할 수 있지만, 문제는 이 권한이 절대 제거되지 않는다는 점입니다. 기업이 시리즈 A 단계에 도달할 때쯤이면, 전체 엔지니어링 팀이 아직도 필요 없고 가져서는 안 되는 완전한 관리 권한을 가지고 있는 경우가 대부분입니다. -
퇴사한 직원의 비활성 계정이 그대로 남아 있음
누군가 퇴사하면 해당 IAM 사용자를 비활성화하고 결국 삭제해야 합니다. 이 단계는 종종 건너뛰어지는데, 이는 오프보딩 체크리스트에 포함되지 않거나 “다음 스프린트에 할게요”라는 이유 때문입니다. 삼 달이 지나면 계정은 잊혀지지만 여전히 활성 상태입니다. 퇴사한 직원이든, 이메일을 탈취하고 비밀번호 재설정을 트리거한 공격자든, 생산 환경에 대한 완전한 접근 권한을 얻게 됩니다. -
루트 계정을 일상 업무에 사용
AWS 루트 계정은 처음 가입할 때 만든 계정이며, IAM 정책으로 제한할 수 없습니다—모든 것에 대한 절대적이고 무제한적인 접근 권한을 가집니다. 일상 업무에 절대 사용해서는 안 되며, 접근 키도 존재해서는 안 됩니다. 제가 수행하는 거의 모든 스타트업 감사에서 루트 계정이 실제로 사용되고 있으며, MFA가 설정되지 않은 경우가 많습니다. -
오래된 접근 키가 회전되지 않음
IAM 접근 키(AKIA…키 ID와 비밀)는 프로그래밍 방식 API 접근을 허용합니다. 비밀번호와 달리 기본적으로 만료되지 않습니다. 18~24개월 전에 생성된 키—아마도 이미 퇴사한 개발자에게 할당되었거나 폐기된 애플리케이션에 남아 있는—가 아직도 유효하며, 어디선가 유출될 경우 악용 가능한 자격 증명이 됩니다. -
관리 권한을 가진 서비스 계정
개발자가 AWS에 접근해야 하는 서비스(배포 파이프라인, Lambda 함수, 서드파티 통합 등)가 필요할 때 가장 빠른 해결책은 광범위한 권한을 가진 IAM 사용자입니다. 올바른 해결책은 해당 서비스가 필요로 하는 최소 권한만을 가진 IAM 역할을 사용하는 것입니다.AdministratorAccess를 가진 서비스 계정은 하나의 침해된 애플리케이션만으로 전체 계정 탈취가 가능하게 만듭니다. -
IAM 권한 경계나 서비스 제어 정책(SCP) 부재
다수 개발자가 있는 계정에서는 IAM 권한을 가진 개발자가 자신의 권한을 상승시킬 수 있는 방어 장치가 없습니다—새 관리자를 만들거나, 자신에게 관리 정책을 부착하거나, 더 넓은 권한을 가진 역할을 가정하는 식입니다. 권한 경계와 SCP는 이러한 상황을 방지하는 가드레일이며, 초기 단계 계정에서는 거의 설정되지 않은 경우가 많습니다.
원칙: 최소 권한
최소 권한은 모든 정체성(인간이든 기계든)에게 오직 자신의 기능을 수행하는 데 필요한 접근만을 허용하고 그 외는 전혀 허용하지 않는다는 의미입니다.
AWS IAM 예시
| Identity | Required actions | Scope |
|---|---|---|
| 특정 S3 버킷에 배포하는 개발자 | s3:PutObject, s3:GetObject | Only the specific bucket ARN |
| DynamoDB 테이블을 읽는 Lambda 함수 | dynamodb:GetItem, dynamodb:Query | Only that table |
절대 필요한 경우가 아니면 *에 s3:*를 사용하거나 AdministratorAccess를 사용하지 마세요.
실용적인 접근법
- 보다 넓은 권한부터 시작
- AWS CloudTrail 및 IAM Access Analyzer 활성화
- 해당 도구들이 생성한 데이터를 사용하여 각 역할이 실제로 사용하는 권한을 식별
- 현실에 맞게 권한 범위 축소
AWS의 IAM Access Advisor는 각 권한이 마지막으로 사용된 시간을 표시하므로, 사용되지 않는 권한을 식별하고 제거하는 것이 간단합니다.
단계별 복구 체크리스트
| 단계 | 작업 | 방법 |
|---|---|---|
| 1 | IAM 자격 증명 보고서 생성 | AWS 콘솔에서: IAM → Credential Report → Download Report. CSV 파일에는 모든 IAM 사용자, 비밀번호/액세스 키 상태, 마지막 사용 시각, MFA 상태가 나열됩니다. password_last_used 가 never 로 표시되거나 90일 이상 지난 사용자는 즉시 검토해야 합니다. |
| 2 | AdministratorAccess 할당 식별 | IAM → Users에서 AdministratorAccess 정책으로 필터링합니다. 이 정책이 적용된 모든 사용자 또는 역할을 검토하고, 이유가 명확하지 않거나 현재 필요하지 않다면 제거합니다. |
| 3 | 루트 계정 확인 | AWS 콘솔에 로그인하고 루트 계정에 MFA가 활성화되어 있는지 확인합니다(IAM 대시보드의 IAM Security Recommendations 패널에서 확인 가능). 루트 액세스 키가 존재한다면(자격 증명 보고서에 표시됨) 즉시 삭제합니다. |
| 4 | 액세스 키 연령 검토 | 자격 증명 보고서에서 90일 이상 된 활성 액세스 키를 찾습니다. 해당 키를 교체하고 이를 사용하는 시스템을 업데이트합니다. |
| 5 | 비활성 사용자 감사 | 90일 이상 활동이 없는 IAM 사용자는 비활성화해야 합니다. 퇴사한 직원의 계정은 마지막 활동 여부와 관계없이 즉시 비활성화합니다. |
| 6 | 서비스에 IAM 사용자 대신 IAM 역할 사용 | 장기 사용 IAM 사용자 자격 증명 대신 IAM 역할(최소 권한 정책 적용)을 EC2 인스턴스, Lambda 함수, CI/CD 파이프라인, 서드파티 연동 등에 사용합니다. |
IAM 역할을 사용하세요 … (원본 텍스트는 여기서 끝났으며, 조직의 구체적인 지침을 이어서 작성하세요)
Final note
IAM 구성 오류를 수정하는 것은 금전적으로 무료이며, 시간과 규율만이 필요합니다. 위의 단계를 구현하고 최소 권한 정책을 적용하면 가장 일반적인 클라우드 공격 벡터를 크게 줄일 수 있습니다. 🚀
Source:
IAM 모범 사례
-
장기 사용 액세스 키 대신 IAM 역할 사용
- IAM 역할은 일시적으로 가정되며 자동으로 단기 자격 증명을 발급합니다.
- 정적 액세스 키가 없어 유출되거나 잊어버릴 위험이 없습니다.
- AWS — EC2 인스턴스, Lambda 함수, ECS 컨테이너 — 에서 실행되는 모든 서비스는 장기 사용 액세스 키가 아니라 IAM 역할을 통해 인증해야 합니다.
-
모든 인간 IAM 사용자에게 MFA 적용
- 현재 세션에서 MFA가 사용되지 않은 경우 모든 작업을 거부하는 IAM 정책을 연결합니다.
- 이 2분 구현으로 인간 계정에 대한 자격 증명만을 이용한 침해를 방지할 수 있습니다.
- AWS는 문서에서 MFA 적용 정책 예시를 제공합니다.
-
루트 계정을 운영 목적으로 절대 사용하지 않음
- 관리 작업을 위한 전용 관리자 IAM 사용자를 생성합니다.
- 해당 관리자 사용자에 MFA를 활성화합니다.
- 루트 계정 자격 증명을 안전하게 보관하고, 루트가 반드시 필요한 계정 수준 작업에만 사용합니다.
Typical Attack Chain
-
유효한 자격 증명 획득
- 공개 GitHub 저장소에 누출된 액세스 키.
- EC2 메타데이터 엔드포인트에 접근하는 SSRF 취약점을 이용해 인스턴스 역할 자격 증명을 반환받음.
- 개발자를 대상으로 한 피싱 공격.
-
권한 열거
- Pacu(오픈소스 AWS 익스플로잇 프레임워크)와 같은 도구가 이 단계를 자동화함: “이 자격 증명으로 실제로 무엇을 할 수 있나요?”
-
권한 상승
- 침해된 자격 증명에
iam:CreateUser,iam:AttachUserPolicy,iam:PassRole권한이 있는 경우, 공격자는 다음을 수행할 수 있음:- 새 관리자 사용자 생성, 혹은
- 더 높은 권한의 역할로 상승.
- 여기서부터 전체 계정이 탈취됨 – 모든 서비스, 데이터 스토어, 비밀이 위험에 처함.
- 침해된 자격 증명에
This is not a theoretical scenario. It is documented in real breaches and in AWS’s own security guidance.
유용한 AWS‑네이티브 및 오픈‑소스 도구
| 도구 | 설명 | 비용 |
|---|---|---|
| IAM Access Analyzer | AWS 내장 서비스로, 계정 외부에서 접근 가능한 리소스와 역할, 또는 의도보다 넓은 접근 권한을 부여하는 리소스를 식별합니다. | 무료 |
| AWS Trusted Advisor (보안 검사) | IAM 전용 권고 사항을 제공합니다: 루트 계정에 MFA 적용, 액세스 키 교체, 권한 검토 등. Business 및 Enterprise 지원 플랜에서 이용 가능. | 지원 플랜에 포함 |
| Prowler | 오픈소스 클라우드 보안 스캐너로, AWS 계정에 대해 수백 개의 검사를 수행합니다(CIS 벤치마크, AWS 모범 사례) 및 포괄적인 IAM 커버리지를 제공합니다. | 무료 (오픈 소스) |
Prowler를 AWS 계정에 실행하기
pip install prowler
prowler aws --services iam이러한 단계와 도구는 IAM을 강화하고, 잘못된 구성을 감지하며, 자격 증명 기반 공격 위험을 줄이는 데 도움이 됩니다.