지난 글에서는 AWS의 개념과 클라우드 서비스 모델에 대해 살펴보았습니다. 이번 글에서는 AWS를 사용할 때 가장 먼저 접하게 되는 서비스 중 하나인 IAM(Identity and Access Management)에 대해 알아보겠습니다.
AWS를 처음 사용하다 보면 "이 사용자에게는 S3만 접근하게 하고, EC2는 못 만지게 하고 싶은데 어떻게 하지?" 같은 고민을 하게 됩니다. 실제로 많은 보안 사고는 권한이 과도하게 부여되거나, 퇴사자 계정이 제때 삭제되지 않아 발생합니다. 그만큼 IAM은 AWS를 안전하게 운영하기 위한 가장 기본이 되는 서비스입니다.
최근 AWS는 장기간 사용하는 Access Key보다, 필요한 순간에만 권한을 부여하는 IAM Role 기반의 접근 방식을 권장하고 있습니다.
AWS IAM(Identity and Access Management)이란?
IAM은 AWS 자원에 "누가" 접근할 수 있고, "무엇을" 할 수 있는지를 관리하는 서비스입니다.
쉽게 말해 회사의 출입증 관리 시스템과 비슷합니다. 모든 직원에게 모든 문을 열 수 있는 마스터키를 주지 않고, 직무에 맞는 출입 권한만 부여하는 것처럼, IAM은 AWS 자원에 대한 접근 권한을 세밀하게 통제합니다.
이러한 권한 관리는 단순한 기술적 선택이 아니라, 보안 인증과 컴플라이언스 측면에서도 필수적인 요건입니다. 국내 정보보호 관리체계 인증인 ISMS-P에서도 클라우드 환경의 관리자 계정 관리, 접근권한 최소화, MFA 적용, Access Key 관리, VPN·IP 기반 접근통제, 권한 설정 이력 관리 등을 주요 보안통제 항목으로 안내하고 있습니다. 이는 AWS IAM에서 제공하는 사용자·그룹·역할(Role)·정책(Policy) 기반 권한 관리와 직접적으로 연결됩니다.
[그림 1. ISMS-P 인증기준 안내서의 클라우드 서비스 보안통제 예시] 
출처 : 개인정보보호위원회·과학기술정보통신부, 「정보보호 및 개인정보보호 관리체계(ISMS-P) 인증기준 안내서(2023.11 개정)」
IAM의 핵심 구성요소
AWS 콘솔이나 CLI에 로그인하는 개인 단위의 자격 증명입니다. 개인 학습이나 소규모 환경에서는 IAM User를 사용할 수 있지만, 운영 환경에서는 사용자에게 직접 권한을 부여하기보다 그룹(Group)과 역할(Role)을 활용해 권한을 관리하는 것이 일반적입니다.
동일한 권한이 필요한 사용자들을 묶어 관리하는 단위입니다. 사용자 개개인에게 직접 정책을 붙이기보다 그룹 단위로 정책을 연결하면 권한 부여, 회수, 감사 대응이 훨씬 수월합니다.
AWS 서비스나 사용자가 필요한 순간에만 임시 권한을 사용할 수 있도록 하는 기능입니다. 사용자뿐 아니라 EC2, Lambda 같은 AWS 서비스가 다른 AWS 자원에 접근할 때도 Role을 사용합니다. 예를 들어 EC2 인스턴스에 S3 접근 Role을 부여하면 서버 안에 액세스 키를 저장하지 않아도 S3에 접근할 수 있습니다.
"무엇을 할 수 있는지"를 정의한 JSON 형식의 문서입니다. 사용자, 그룹, 역할에 정책을 연결해 권한을 부여합니다. 정책은 Effect, Action, Resource, Condition 등의 요소를 통해 허용 또는 거부할 작업 범위를 정의합니다.
{
"Effect": "Allow",
"Action": [
"s3:GetObject"
],
"Resource": "*"
}※ 위 정책은 S3 객체를 조회(GetObject)할 수 있도록 허용하는 간단한 예시입니다. 실제 운영 환경에서는 Resource에 특정 S3 버킷이나 객체를 지정하여 필요한 리소스에만 접근하도록 최소 권한을 적용하는 것이 좋습니다.
IAM 정책의 종류
IAM에서 권한을 부여할 때 사용하는 정책은 크게 세 가지로 나뉩니다. 각 정책의 특성과 용도를 이해해야 환경에 맞는 적절한 권한 관리가 가능합니다.
AWS가 직접 생성하고 관리하는 사전 정의된 정책입니다. AmazonS3ReadOnlyAccess, AdministratorAccess처럼 일반적인 사용 사례에 맞춰 미리 만들어져 있어 빠르게 적용할 수 있다는 장점이 있습니다. 다만 AWS가 제공하는 정책이라 모든 AWS 고객이 동일하게 사용할 수 있으며, 특정 조직의 사용 사례에 맞춰 권한을 세밀하게 줄이기는 어렵습니다.
사용자가 직접 작성하고 관리하는 정책입니다. 조직의 보안 요구사항과 업무 환경에 맞춰 권한을 세밀하게 조정할 수 있어, 최소 권한 원칙을 적용하기에 가장 적합합니다.
특정 사용자, 그룹, 역할에 직접 포함되는 정책으로, 정책과 자격 증명이 1:1로 매핑됩니다. 해당 자격 증명이 삭제되면 정책도 함께 삭제됩니다. 특정 자격 증명에만 예외적으로 적용해야 하는 권한이 있을 때 유용하지만, 재사용이 불가능하고 관리가 어렵기 때문에 일반적인 권한 관리에는 권장되지 않습니다. AWS도 정책이 둘 이상의 엔터티에 적용될 수 있는 경우라면 관리형 정책 사용을 권장하고 있습니다.
💡 실무 팁
처음에는 AWS 관리형 정책으로 시작해 빠르게 권한을 부여하고, 운영이 안정화되면 고객 관리형 정책으로 전환해 최소 권한을 적용하는 것이 현실적인 접근입니다. 다만 운영 환경에서는 AWS 관리형 정책을 그대로 장기간 사용하는 것보다, 실제 사용 이력을 기반으로 필요한 Action과 Resource만 남기는 방식으로 점진적으로 줄여가는 것이 좋습니다. 인라인 정책은 특수한 1회성 권한에만 제한적으로 사용하는 것을 권장합니다. |
특수 권한 관리
IAM에서 특히 주의해야 할 부분이 바로 특수 권한(Privileged Access) 관리입니다.
특수 권한이란 AdministratorAccess, IAMFullAccess, PowerUserAccess처럼 시스템 전체나 보안 설정에 영향을 줄 수 있는 강력한 권한을 의미합니다. 이런 권한이 잘못 부여되거나 관리되지 않으면, 단 한 명의 계정 탈취만으로도 전체 AWS 환경이 위험에 노출될 수 있습니다.
특수 권한은 단순히 "누구에게 부여했는가"만 보는 것이 아니라, 신청, 승인, 부여, 사용 이력, 정기 검토, 회수까지 전 과정을 관리해야 합니다.
왜 그룹 단위로 관리해야 하는가?
특수 권한을 사용자 개별로 부여하면 다음과 같은 문제가 발생합니다.
- 누가 어떤 관리자 권한을 가지고 있는지 한눈에 파악하기 어렵습니다.
- 권한 회수 시 일관성이 깨져 누락이 발생하기 쉽습니다.
- 감사·심사 시 권한 부여 이력을 추적하기 어렵습니다.
- 조직 변경(부서 이동, 퇴사)이 발생할 때마다 개별 수정이 필요해 운영 부담이 큽니다.
반면 "Administrators", "SecurityAuditors" 같은 그룹을 만들어 특수 권한 정책을 그룹에 연결하고, 사용자를 그룹에 추가/제거하는 방식으로 관리하면 권한 부여와 회수가 명확해지고, 누가 어떤 권한을 가지는지도 쉽게 확인할 수 있습니다.
ISMS-P 인증 기준 2.5.5 (특수 계정 및 권한 관리)에서는 정보시스템 관리, 개인정보 및 중요정보 관리 등 특수 목적을 위하여 사용하는 계정 및 권한은 최소한으로 부여하고 별도로 식별하여 통제하도록 요구하고 있습니다.
또한 다음과 같은 사항을 명시하고 있습니다.
- 특수 계정 및 권한은 공식적인 절차에 따라 신청·승인이 이루어져야 합니다.
- 일반 사용자 계정보다 엄격한 승인 기준을 적용해야 합니다.
- 특수 권한은 별도 목록으로 관리하고, 사용 여부를 정기적으로 검토해야 합니다.
- 외부자에게 부여하는 특수 권한은 필요시에만 생성하고, 업무 종료 후 즉시 삭제해야 합니다.
특히 유의해야 하는 경우는 "관리자 권한자의 업무가 변경되었음에도 기존 특수 권한이 그대로 유지된 경우"입니다. AWS IAM의 그룹 기반 권한 관리는 이러한 문제를 구조적으로 줄이는 데 도움이 됩니다.
[그림 2. ISMS-P 2.5.5 특수 계정 및 권한 관리]
출처 : 개인정보보호위원회·과학기술정보통신부, 「정보보호 및 개인정보보호 관리체계(ISMS-P) 인증기준 안내서(2023.11 개정)」
Root 계정과 IAM 사용자
AWS 계정을 처음 만들면 Root 계정이 생성되는데, 이 계정은 모든 권한을 가진 최상위 계정입니다.
문제는 Root 계정으로 평소 작업을 하면 실수로 중요한 자원을 삭제하거나, 계정이 탈취당했을 때 피해 범위가 매우 커진다는 점입니다. 그래서 AWS는 Root 계정을 일상적인 작업에 사용하지 않고, 결제 정보 변경이나 계정 설정처럼 꼭 필요한 경우에만 사용하도록 권장합니다.
Root 계정에는 반드시 MFA를 적용해야 합니다. 또한 AWS는 Root 사용자에 대한 Access Key를 생성하지 않을 것을 권장하며, 이미 생성된 경우에는 사용 여부를 점검한 후 필요하지 않다면 삭제하도록 권고합니다.
일반적인 업무는 Root 계정을 사용하지 않고 IAM 사용자 또는 IAM Role을 통해 수행하는 것이 좋습니다. 조직 규모가 커질 경우에는 IAM Identity Center를 활용한 중앙 집중식 계정 관리도 고려할 수 있습니다.
AWS 공식 문서에서도 Root 계정의 일상적인 사용을 지양하고, MFA 적용과 Root Access Key 미생성을 보안 모범 사례(Best Practice)로 권장하고 있습니다.
[그림 3. AWS Root User Best Practices]
출처 : AWS Documentation - Root user best practices
IAM 보안 모범 사례(Best Practices)
IAM은 단순히 사용자와 권한을 생성하는 것으로 끝나는 것이 아닙니다. AWS에서는 계정과 권한을 안전하게 운영하기 위한 다양한 IAM 보안 모범 사례(Best Practices)를 제공하고 있으며, 운영 환경에서는 이러한 권장 사항을 적용하여 계정 탈취와 권한 오남용 위험을 줄이는 것이 중요합니다.
비밀번호만으로는 충분하지 않습니다. 비밀번호가 유출되더라도 두 번째 인증 수단(OTP, 보안 키 등)이 없으면 로그인이 불가능하도록 만드는 것이 MFA입니다. 특히 Root 계정과 관리자 권한을 가진 사용자에게는 MFA 적용이 필수입니다. AWS에서도 Root 계정과 IAM 사용자에 MFA를 등록하여 계정 탈취 위험을 줄일 것을 안내하고 있습니다.
액세스 키는 프로그램이 AWS에 접근할 때 사용하는 자격 증명으로, 한 번 유출되면 큰 피해로 이어질 수 있습니다. 과거에는 주기적인 교체가 강조되었지만, 현재 AWS의 핵심 권고는 장기 Access Key 자체를 가능한 만들지 않는 것입니다. 꼭 필요한 경우가 아니라면 IAM Identity Center 또는 IAM Role을 통해 발급되는 임시 자격 증명(STS)을 사용하는 것이 더 안전합니다.
AWS는 장기 액세스 키 대신, 필요한 순간에만 발급되고 일정 시간이 지나면 만료되는 임시 자격 증명 사용을 권장합니다. 사용자가 직접 접근하는 경우에는 IAM Identity Center나 페더레이션을 통해, 워크로드(애플리케이션, 서버)가 접근하는 경우에는 IAM 역할을 통해 임시 자격 증명을 사용하는 것이 모범 사례입니다.
IAM Access Analyzer는 외부 계정이나 퍼블릭 접근 가능성이 있는 권한을 식별하는 데 활용할 수 있으며, Credential Report는 IAM 사용자별 비밀번호, MFA, Access Key 사용 현황을 점검하는 데 유용합니다. 정기 점검 시 두 기능을 함께 활용하면 접근권한 사후관리를 체계화할 수 있습니다.
접근 권한 사후 관리
권한 설정에서 자주 놓치는 부분이 바로 사후 관리입니다.
처음에는 권한을 적절하게 부여했더라도 시간이 지나면서 부서를 옮긴 직원이 기존 권한을 그대로 가지고 있거나, 퇴사한 직원의 계정이 남아 있는 경우가 발생할 수 있습니다. 따라서 접근 권한은 한 번 설정하는 것으로 끝나는 것이 아니라, 정기적으로 검토하고 불필요한 권한을 제거하는 운영 절차가 필요합니다.
AWS에서는 IAM 사용자와 역할(Role), 정책(Policy)을 통해 권한을 관리할 수 있으며, IAM Access Analyzer, Credential Report 등의 기능을 활용하면 권한 현황을 점검하고 불필요한 계정이나 권한을 확인하는 데 도움이 됩니다.
다음과 같은 항목을 정기적으로 점검하는 것이 좋습니다.
- 퇴사자 또는 계약 종료자의 계정이 남아 있는지 확인
- 장기 미사용 IAM 사용자 및 Access Key 확인
- AdministratorAccess, IAMFullAccess 등 높은 권한을 가진 계정 확인
- 업무 변경 후 불필요한 권한이 그대로 유지되고 있는지 확인
- 외부 사용자 또는 협력사 계정의 사용 기간 및 권한 회수 여부 확인
실제 사용 예시
예를 들어 개발팀에 새로운 인턴이 들어왔다고 가정해보겠습니다. 이 인턴에게는 S3에 파일을 업로드하고 다운로드하는 권한만 필요하고, EC2 서버 종료, IAM 권한 변경, 결제 정보 접근은 필요하지 않습니다.
이때 IAM에서 "S3 읽기/쓰기 권한"만 담긴 고객 관리형 정책을 만들고, 해당 정책을 인턴 개인에게 직접 연결하는 대신 "Intern-S3-Access" 같은 그룹에 연결한 뒤 사용자를 그룹에 추가하면 관리가 훨씬 수월합니다.
워크로드 관점에서는 더 좋은 방법도 있습니다. 만약 EC2에서 S3에 접근해야 한다면 서버 안에 Access Key를 저장하지 말고, EC2 인스턴스에 IAM Role을 연결하는 방식이 더 안전합니다. 이렇게 하면 키 유출 위험을 줄이고, 권한 회수도 Role 정책 변경만으로 처리할 수 있습니다.
이렇게 필요한 권한만 정확히 부여하는 것을 최소 권한 원칙(Principle of Least Privilege)이라고 하며, IAM을 사용하는 가장 중요한 이유이자 핵심 원칙이기도 합니다.
마무리
지금까지 IAM의 개념과 핵심 구성요소, 정책의 종류, 특수 권한 관리, Root 계정 보안, 접근권한 사후관리까지 살펴보았습니다.
IAM은 단순히 사용자를 생성하고 권한을 부여하는 기능이 아니라 AWS 보안의 출발점입니다. 특히 최근 AWS는 IAM 사용자와 장기 Access Key 중심의 운영보다, IAM Identity Center와 IAM Role을 활용한 임시 자격 증명(Temporary Credentials) 기반의 접근 방식을 권장하고 있습니다.
또한 최소 권한 원칙(Principle of Least Privilege)을 기반으로 권한을 설계하고, 정기적으로 권한을 검토하는 운영 습관은 AWS 환경을 더욱 안전하게 유지하는 데 중요한 요소입니다.
다음 글에서는 또 다른 AWS 서비스에 대해 살펴보겠습니다.
참고 문헌
 석민화 | smh@cela.kr |
지난 글에서는 AWS의 개념과 클라우드 서비스 모델에 대해 살펴보았습니다. 이번 글에서는 AWS를 사용할 때 가장 먼저 접하게 되는 서비스 중 하나인 IAM(Identity and Access Management)에 대해 알아보겠습니다.
AWS를 처음 사용하다 보면 "이 사용자에게는 S3만 접근하게 하고, EC2는 못 만지게 하고 싶은데 어떻게 하지?" 같은 고민을 하게 됩니다. 실제로 많은 보안 사고는 권한이 과도하게 부여되거나, 퇴사자 계정이 제때 삭제되지 않아 발생합니다. 그만큼 IAM은 AWS를 안전하게 운영하기 위한 가장 기본이 되는 서비스입니다.
최근 AWS는 장기간 사용하는 Access Key보다, 필요한 순간에만 권한을 부여하는 IAM Role 기반의 접근 방식을 권장하고 있습니다.
AWS IAM(Identity and Access Management)이란?
IAM은 AWS 자원에 "누가" 접근할 수 있고, "무엇을" 할 수 있는지를 관리하는 서비스입니다.
쉽게 말해 회사의 출입증 관리 시스템과 비슷합니다. 모든 직원에게 모든 문을 열 수 있는 마스터키를 주지 않고, 직무에 맞는 출입 권한만 부여하는 것처럼, IAM은 AWS 자원에 대한 접근 권한을 세밀하게 통제합니다.
이러한 권한 관리는 단순한 기술적 선택이 아니라, 보안 인증과 컴플라이언스 측면에서도 필수적인 요건입니다. 국내 정보보호 관리체계 인증인 ISMS-P에서도 클라우드 환경의 관리자 계정 관리, 접근권한 최소화, MFA 적용, Access Key 관리, VPN·IP 기반 접근통제, 권한 설정 이력 관리 등을 주요 보안통제 항목으로 안내하고 있습니다. 이는 AWS IAM에서 제공하는 사용자·그룹·역할(Role)·정책(Policy) 기반 권한 관리와 직접적으로 연결됩니다.
[그림 1. ISMS-P 인증기준 안내서의 클라우드 서비스 보안통제 예시]
출처 : 개인정보보호위원회·과학기술정보통신부, 「정보보호 및 개인정보보호 관리체계(ISMS-P) 인증기준 안내서(2023.11 개정)」
IAM의 핵심 구성요소
"무엇을 할 수 있는지"를 정의한 JSON 형식의 문서입니다. 사용자, 그룹, 역할에 정책을 연결해 권한을 부여합니다. 정책은 Effect, Action, Resource, Condition 등의 요소를 통해 허용 또는 거부할 작업 범위를 정의합니다.
{ "Effect": "Allow", "Action": [ "s3:GetObject" ], "Resource": "*" }※ 위 정책은 S3 객체를 조회(GetObject)할 수 있도록 허용하는 간단한 예시입니다. 실제 운영 환경에서는 Resource에 특정 S3 버킷이나 객체를 지정하여 필요한 리소스에만 접근하도록 최소 권한을 적용하는 것이 좋습니다.
IAM 정책의 종류
IAM에서 권한을 부여할 때 사용하는 정책은 크게 세 가지로 나뉩니다. 각 정책의 특성과 용도를 이해해야 환경에 맞는 적절한 권한 관리가 가능합니다.
특정 사용자, 그룹, 역할에 직접 포함되는 정책으로, 정책과 자격 증명이 1:1로 매핑됩니다. 해당 자격 증명이 삭제되면 정책도 함께 삭제됩니다. 특정 자격 증명에만 예외적으로 적용해야 하는 권한이 있을 때 유용하지만, 재사용이 불가능하고 관리가 어렵기 때문에 일반적인 권한 관리에는 권장되지 않습니다. AWS도 정책이 둘 이상의 엔터티에 적용될 수 있는 경우라면 관리형 정책 사용을 권장하고 있습니다.
💡 실무 팁
처음에는 AWS 관리형 정책으로 시작해 빠르게 권한을 부여하고, 운영이 안정화되면 고객 관리형 정책으로 전환해 최소 권한을 적용하는 것이 현실적인 접근입니다. 다만 운영 환경에서는 AWS 관리형 정책을 그대로 장기간 사용하는 것보다, 실제 사용 이력을 기반으로 필요한 Action과 Resource만 남기는 방식으로 점진적으로 줄여가는 것이 좋습니다. 인라인 정책은 특수한 1회성 권한에만 제한적으로 사용하는 것을 권장합니다.
특수 권한 관리
IAM에서 특히 주의해야 할 부분이 바로 특수 권한(Privileged Access) 관리입니다.
특수 권한이란 AdministratorAccess, IAMFullAccess, PowerUserAccess처럼 시스템 전체나 보안 설정에 영향을 줄 수 있는 강력한 권한을 의미합니다. 이런 권한이 잘못 부여되거나 관리되지 않으면, 단 한 명의 계정 탈취만으로도 전체 AWS 환경이 위험에 노출될 수 있습니다.
특수 권한은 단순히 "누구에게 부여했는가"만 보는 것이 아니라, 신청, 승인, 부여, 사용 이력, 정기 검토, 회수까지 전 과정을 관리해야 합니다.
왜 그룹 단위로 관리해야 하는가?
특수 권한을 사용자 개별로 부여하면 다음과 같은 문제가 발생합니다.
반면 "Administrators", "SecurityAuditors" 같은 그룹을 만들어 특수 권한 정책을 그룹에 연결하고, 사용자를 그룹에 추가/제거하는 방식으로 관리하면 권한 부여와 회수가 명확해지고, 누가 어떤 권한을 가지는지도 쉽게 확인할 수 있습니다.
ISMS-P 인증 기준 2.5.5 (특수 계정 및 권한 관리)에서는 정보시스템 관리, 개인정보 및 중요정보 관리 등 특수 목적을 위하여 사용하는 계정 및 권한은 최소한으로 부여하고 별도로 식별하여 통제하도록 요구하고 있습니다.
또한 다음과 같은 사항을 명시하고 있습니다.
특히 유의해야 하는 경우는 "관리자 권한자의 업무가 변경되었음에도 기존 특수 권한이 그대로 유지된 경우"입니다. AWS IAM의 그룹 기반 권한 관리는 이러한 문제를 구조적으로 줄이는 데 도움이 됩니다.
[그림 2. ISMS-P 2.5.5 특수 계정 및 권한 관리]
출처 : 개인정보보호위원회·과학기술정보통신부, 「정보보호 및 개인정보보호 관리체계(ISMS-P) 인증기준 안내서(2023.11 개정)」
Root 계정과 IAM 사용자
AWS 계정을 처음 만들면 Root 계정이 생성되는데, 이 계정은 모든 권한을 가진 최상위 계정입니다.
문제는 Root 계정으로 평소 작업을 하면 실수로 중요한 자원을 삭제하거나, 계정이 탈취당했을 때 피해 범위가 매우 커진다는 점입니다. 그래서 AWS는 Root 계정을 일상적인 작업에 사용하지 않고, 결제 정보 변경이나 계정 설정처럼 꼭 필요한 경우에만 사용하도록 권장합니다.
Root 계정에는 반드시 MFA를 적용해야 합니다. 또한 AWS는 Root 사용자에 대한 Access Key를 생성하지 않을 것을 권장하며, 이미 생성된 경우에는 사용 여부를 점검한 후 필요하지 않다면 삭제하도록 권고합니다.
일반적인 업무는 Root 계정을 사용하지 않고 IAM 사용자 또는 IAM Role을 통해 수행하는 것이 좋습니다. 조직 규모가 커질 경우에는 IAM Identity Center를 활용한 중앙 집중식 계정 관리도 고려할 수 있습니다.
AWS 공식 문서에서도 Root 계정의 일상적인 사용을 지양하고, MFA 적용과 Root Access Key 미생성을 보안 모범 사례(Best Practice)로 권장하고 있습니다.
[그림 3. AWS Root User Best Practices]
출처 : AWS Documentation - Root user best practices
IAM 보안 모범 사례(Best Practices)
IAM은 단순히 사용자와 권한을 생성하는 것으로 끝나는 것이 아닙니다. AWS에서는 계정과 권한을 안전하게 운영하기 위한 다양한 IAM 보안 모범 사례(Best Practices)를 제공하고 있으며, 운영 환경에서는 이러한 권장 사항을 적용하여 계정 탈취와 권한 오남용 위험을 줄이는 것이 중요합니다.
AWS는 장기 액세스 키 대신, 필요한 순간에만 발급되고 일정 시간이 지나면 만료되는 임시 자격 증명 사용을 권장합니다. 사용자가 직접 접근하는 경우에는 IAM Identity Center나 페더레이션을 통해, 워크로드(애플리케이션, 서버)가 접근하는 경우에는 IAM 역할을 통해 임시 자격 증명을 사용하는 것이 모범 사례입니다.
IAM Access Analyzer는 외부 계정이나 퍼블릭 접근 가능성이 있는 권한을 식별하는 데 활용할 수 있으며, Credential Report는 IAM 사용자별 비밀번호, MFA, Access Key 사용 현황을 점검하는 데 유용합니다. 정기 점검 시 두 기능을 함께 활용하면 접근권한 사후관리를 체계화할 수 있습니다.
접근 권한 사후 관리
권한 설정에서 자주 놓치는 부분이 바로 사후 관리입니다.
처음에는 권한을 적절하게 부여했더라도 시간이 지나면서 부서를 옮긴 직원이 기존 권한을 그대로 가지고 있거나, 퇴사한 직원의 계정이 남아 있는 경우가 발생할 수 있습니다. 따라서 접근 권한은 한 번 설정하는 것으로 끝나는 것이 아니라, 정기적으로 검토하고 불필요한 권한을 제거하는 운영 절차가 필요합니다.
AWS에서는 IAM 사용자와 역할(Role), 정책(Policy)을 통해 권한을 관리할 수 있으며, IAM Access Analyzer, Credential Report 등의 기능을 활용하면 권한 현황을 점검하고 불필요한 계정이나 권한을 확인하는 데 도움이 됩니다.
다음과 같은 항목을 정기적으로 점검하는 것이 좋습니다.
실제 사용 예시
예를 들어 개발팀에 새로운 인턴이 들어왔다고 가정해보겠습니다. 이 인턴에게는 S3에 파일을 업로드하고 다운로드하는 권한만 필요하고, EC2 서버 종료, IAM 권한 변경, 결제 정보 접근은 필요하지 않습니다.
이때 IAM에서 "S3 읽기/쓰기 권한"만 담긴 고객 관리형 정책을 만들고, 해당 정책을 인턴 개인에게 직접 연결하는 대신 "Intern-S3-Access" 같은 그룹에 연결한 뒤 사용자를 그룹에 추가하면 관리가 훨씬 수월합니다.
워크로드 관점에서는 더 좋은 방법도 있습니다. 만약 EC2에서 S3에 접근해야 한다면 서버 안에 Access Key를 저장하지 말고, EC2 인스턴스에 IAM Role을 연결하는 방식이 더 안전합니다. 이렇게 하면 키 유출 위험을 줄이고, 권한 회수도 Role 정책 변경만으로 처리할 수 있습니다.
이렇게 필요한 권한만 정확히 부여하는 것을 최소 권한 원칙(Principle of Least Privilege)이라고 하며, IAM을 사용하는 가장 중요한 이유이자 핵심 원칙이기도 합니다.
마무리
지금까지 IAM의 개념과 핵심 구성요소, 정책의 종류, 특수 권한 관리, Root 계정 보안, 접근권한 사후관리까지 살펴보았습니다.
IAM은 단순히 사용자를 생성하고 권한을 부여하는 기능이 아니라 AWS 보안의 출발점입니다. 특히 최근 AWS는 IAM 사용자와 장기 Access Key 중심의 운영보다, IAM Identity Center와 IAM Role을 활용한 임시 자격 증명(Temporary Credentials) 기반의 접근 방식을 권장하고 있습니다.
또한 최소 권한 원칙(Principle of Least Privilege)을 기반으로 권한을 설계하고, 정기적으로 권한을 검토하는 운영 습관은 AWS 환경을 더욱 안전하게 유지하는 데 중요한 요소입니다.
다음 글에서는 또 다른 AWS 서비스에 대해 살펴보겠습니다.
참고 문헌
석민화 | smh@cela.kr