AWS IAM (Identity and Access management)

AWS IAM은 AWS 리소스에 대한 접근을 안전하게 관리하는 서비스이다. 누가 어떤 AWS 서비스 및 리소스에 접근할 수 있는지 정교하게 제어할 수 있도록 돕는다

IAM 사용자 – 루트 사용자와 IAM 사용자

  • 루트 사용자 (Root User): AWS 계정을 처음 생성할 때 만들어지는 사용자이다. 이메일 주소와 비밀번호로 로그인하며, 계정의 모든 AWS 서비스 및 리소스에 대한 완전한 접근 권한을 가진다. 보안상 루트 사용자는 일상적인 작업에 사용하지 않고 강력한 MFA(Multi-Factor Authentication)를 설정하여 안전하게 보관하는 것이 권장된다
  • IAM 사용자 (IAM User): 루트 사용자가 생성하는 하위 계정으로, 특정 권한만 부여받는 사용자이다. AWS 계정 ID(12자리), 사용자 이름, 비밀번호로 로그인하며, 할당된 정책에 따라 제한된 범위의 AWS 서비스에 접근할 수 있다. 실무에서는 보안 및 권한 분리를 위해 대부분 IAM 사용자를 통해 AWS 서비스에 접근하고 관리한다

IAM의 핵심 요소 – 사용자, 정책, 역할

사용자 (User)

AWS 서비스에 접근하는 주체(사람 또는 애플리케이션)이다

생성: AWS Management Console에서 사용자 이름을 지정하고 AWS Management Console 접근 권한(UI 접근)을 부여할지 여부를 선택한다. 콘솔 암호는 자동 또는 수동으로 생성할 수 있으며, 초기 로그인 시 암호 변경을 강제할 수 있다

AWS는 2022년 이후 Identity Center 사용을 강력하게 권장한다. IAM 사용자를 사용하다가 Identity Center로 변경된 이유가 궁금하여 AI에게 질문을 해보았다

  • 임시 자격 증명 사용으로 보안 강화: IAM 사용자는 수동 삭제 전까지 유효한 엑세스 키를 사용하지만, Identity Center는 자동 만료되는 임시 자격 증명을 발급한다. 엑세스 키 유출 시에도 피해 범위가 제한되어 보안 위험이 크게 감소한다
  • 중앙집중식 사용자 관리: 기존 방식은 각 AWS 계정마다 별도로 IAM 사용자를 관리해야 했지만 Identity Center는 하나의 중앙 위치에서 모든 사용자와 권한을 통합 관리할 수 있다. 한 번의 작업으로 모든 계정에 일괄 적용된다
  • 다중 계정 환경 지원: 개발, 테스트, 운영 환경을 별도 계정으로 분리하여 운영하는 추세에 맞춰, Identity Center는 AWS Organizations와 통합되어 여러 계정에 대한 접근을 체계적으로 관리하고 사용자별로 세밀한 권한 제어가 가능하다
  • 외부 ID 제공자와의 통합: Active Directory, Okta, Microsoft Entra ID(구 Azure AD) 등 기존 기업 ID 시스템과 연동하여 Single Sign-On 환경을 구축할 수 있다. 기존 회사 계정으로 AWS에 접근하여 별도 계정 관리가 불필요하다
  • 향상된 감사 및 컴플라이언스: 모든 사용자의 접근 활동과 권한 변경 내역이 중앙에서 체계적으로 로깅되어 감사 추적이 용이하고 기업의 규제 준수 요구사항 충족에 도움이 된다
  • 사용자 경험 개선: AWS Access Portal을 통해 접근 가능한 모든 계정과 역할을 한눈에 확인하고 선택할 수 있다. 브라우저만으로 접근이 가능해 별도 프로그램 설치 없이 쉽게 이용할 수 있다
  • 관리 오버헤드 감소: 엑세스 키 교체 관리가 불필요하고 직원 퇴사 시 모든 AWS 계정에서 자동 접근 차단된다. 권한 검토 및 정리 작업도 중앙에서 일괄 처리하여 관리자 업무 부담이 줄어든다.

단일 계정의 소규모 환경에서는 IAM 사용자도 유효한 선택지라(공부용이라서) IAM 사용자를 선택하였다

3

콘솔 로그인: 계정 ID, 사용자 이름, 암호를 사용하여 콘솔에 로그인한다

프로그래밍 방식 접근 (Access Key): 사용자가 콘솔이 아닌 프로그램(AWS CLI, AWS SDK, API 등)을 통해 AWS를 제어하고자 할 때 엑세스 키(Access Key ID)와 비밀 엑세스 키 (Secret Access Key)를 생성하여 사용한다. 이 키는 해당 IAM 사용자가 가진 권한과 동일한 권한으로 AWS 리소스에 접근할 수 있도록 인증 정보를 제공한다. 엑세스 키는 보안상 매우 중요하므로 절대로 유출되지 않도록 철저히 관리해야 한다. 루트 사용자의 엑세스 키는 보안상 발급받지 않는 것이 좋다

오른쪽 상단 엑세스 키 만들기

CLI 선택, 확인 체크

설명은 필수로 작성하지 않아도 된다

엑세스 키와 비밀 엑세스 키는 파일 다운로드 후 저장 혹은 잃어버리거나 까먹지 않게 잘 보관해야 한다. 알 수 있는 방법을 제공해주지 않아서 삭제 후 다시 만들어야 한다

정책 (Policy)

JSON 형식으로 작성된 문서로 특정 권한과 조건을 정의한다. 이를 통해 IAM 사용자, 그룹, 역할이 수행할 수 있는 작업과 접근할 수 있는 AWS 리소스를 명확하게 지정한다

  • AWS는 미리 정의된 수많은 관리형 정책(Managed Policy)을 제공하며, 사용자는 필요한 권한(예: EC2 Full Access, S3 Read-Only Access)을 선택하여 사용자에게 부여할 수 있다
  • 실무에서는 AdministratorAccess와 같이 모든 권한을 부여하는 정책보다는, 특정 서비스 및 리소스에 대한 최소한의 필요한 권한만 부여하는 것이 보안 모범 사례이다

역할 (Role)

특정 AWS 리소스 (예: EC2 인스턴스)나 서비스(예: AWS Lambda)가 다른 AWS 서비스에 접근할 수 있도록 임시 권한을 부여하는 데 사용되는 권한 세트이다

  • 사용자는 아이디 / 비밀번로로 로그인하는 ‘실체’이지만 역할은 로그인하는 주체가 아니라 ‘특정 권한의 묶음’을 나타낸다
  • 활용 예시: EC2 인스턴스가 S3 버킷에 파일을 업로드하거나, RDS 데이터베이스에 접근해야 할 경우 EC2 인스턴스에 IAM 사용자를 할당하는 대신 S3 접근 권한이나 RDS 접근 권한을 포함한 ‘역할’을 부여한다. 이렇게 하면 EC2 인스턴스는 해당 역할이 가진 권한을 임시로 위임받아 다른 AWS 서비스와 상호작용할 수 있으며, 별도의 자격 증명(Access Key)을 관리할 필요가 없어 보안성이 높아진다

출처 – eks를 활용한 spring 운영서버 배포(feat. devops의 모든것)