IAM 및 AWS CLI

IAM: Users & Groups

IAM = Identity and Access Management, Global Service

• 기본적으로 생성된 루트 계정은 사용하거나 공유하면 안됩니다.
• 사용자는 조직 내 사람들이며 그룹화할 수 있습니다.
• 그룹에는 다른 그룹이 아닌 사용자만 포함됩니다.
• 사용자는 그룹에 속할 필요가 없으며 사용자는 여러 그룹에 속할 수 있습니다.

IAM Policies

• 사용자 또는 그룹에 정책이라는 JSON 문서를 할당할 수 있습니다.
• 이러한 정책은 사용자의 권한을 정의합니다.

⚠️ AWS에서는 최소 권한 원칙을 적용합니다.
사용자가 필요로 하는 것보다 더 많은 권한을 부여하지 마세요.

IAM Policies inheritance

IAM Policies Structure

Consists of

• Version: 언어버전, 항상 “2012-10-17” 포함
• Id: 정책에 대한 식별자 (선택 사항)
• Statement: 하나 이상의 개별 statements (필수)

Statements consists of

• Sid: statement에 대한 식별자 (선택 사항)
• Effect: 액세스를 허용하는지 여부 (Allow, Deny)
• Principal: 이 정책이 적용되는 계정 / 사용자 / 역할
• Action: 이 정책이 허용하거나 거부하는 작업 목록
• Resource: 작업이 적용된 리소스 목록
• Condition: 이 정책이 적용되는 조건 (선택 사항)

IAM - 비밀번호 정책

• Strong passwords = 계정에 대한 높은 보안
• 최소 비밀번호 길이 설정

특정 문자 유형 필요:

- 대문자 포함
- 소문자
- 번호
- 영숫자가 아닌 문자

• 모든 IAM 사용자가 자신의 암호를 변경할 수 있도록 허용
• 일정 시간이 지나면 사용자에게 비밀번호 변경 요구(비밀번호 만료)
• 비밀번호 재사용 방지

Multi Factor Authentication - MFA

• 사용자는 계정에 엑세스할 수 있으며 AWS 계정에서 구성을 변경하거나 리소스를 삭제할 수 있습니다.
• 루트 계정 및 IAM 사용자를 보호하려는 경우
• MFA = 비밀번호 + 소유한 보안 기기

MFA의 주요 이점:

📌 비밀번호가 도용되거나 해킹된 경우에도 계정이 도용되지 않습니다.

MFA 디바이스 종류 in AWS

1. Virtual MFA device

• Google Authenticator (phone-only)
• Authy (multi-device)

2. Universal 2nd Factor (U2F) Security Key

3. Hardware Key For MFA Device

4. Hardware Key For MFA Device for AWS GovCloud (US)

How can users access AWS ?

AWS에 액세스하기 위해서 세 가지 옵션이 있습니다.

• AWS Management Console: protected by password + MFA

• AWS Command Line Interface (CLI): protected by access keys

• AWS Software Developer Kit (SDK): for code: protected by access keys

• 액세스 키는 AWS 콘솔을 통해 생성됩니다.

• 사용자가 자신의 액세스 키를 관리합니다.

• 액세스 키는 비밀번호와 마찬가지로 비밀로 유지해야 합니다.

• Access Key ID ~= username

• Secrets Access Key ~= password

What’s the AWS CLI ?

• command-line shell에서 명령을 사용하여 AWS 서비스와 상호 작용할 수 있는 도구
• AWS 서비스의 공개 API에 직접 액세스
• 리소스를 관리하는 스크립트 개발
• Open Source
• AWS Management 콘솔 사용의 대안

What’s the AWS SDK ?

• AWS Software Development Kit (AWS SDK)
• 언어별 API (라이브러리 세트)
• 프로그래밍 방식으로 AWS 서비스에 액세스하고 관리할 수 있습니다.
• 애플리케이션에 저장

Supports:

- SDKs (JavaScript, Python, PHP, NET, Ruby, Java, Go, Node.js, C++)
- Mobile SDKs (Android, iOS, …)
- IoT Device SDKs (Embedded C, Arduino, …)

👨‍💻 Example: AWS CLI는 Python용 AWS SDK를 기반으로 합니다.

IAM Roles for Services

• 일부 AWS 서비스는 사용자를 대신하여 작업을 수행해야 합니다.
• 이를 위해 IAM 역할을 사용하여 AWS 서비스에 권한을 할당합니다.

Common roles:

• EC2 Instance Roles
• Lambda Function Roles
• Roles for CloudFormation

IAM Security Tools

IAM Credentials Report (account-level) - 자격 증명 보고서

• 계정의 모든 사용자와 다양한 자격 증명의 상태를 나열하는 보고서

IAM Access Advisor (user-level) - 액세스 어드바이저

• 액세스 관리자는 사용자에게 부여된 서비스 권한과 해당 서비스에 마지막으로 액세스한 시간을 보여줍니다.
• 이 정보를 사용하여 정책을 수정할 수 있습니다.

IAM Guidelines & Best Practices

• AWS 계정 설정 외에는 루트 계정을 사용하지 마세요.
• 실제 사용자 1명 = AWS 사용자 1명
• 사용자를 그룹에 할당하고 그룹에 권한 할당
• 강력한 비밀번호 정책 만들기
• MFA(Multi Factor Authentication) 사용 및 시행
• AWS 서비스에 권한을 부여하기 위한 역할 생성 및 사용
• 프로그래머틱 액세스에 액세스 키 사용 (CLI/SDK)
• IAM 자격 증명 보고서로 계정 권한 감사
• IAM 사용자 및 액세스 키를 절대 공유하지 마세요.

IAM 요약

• Users: 실제 사용자에 매핑되고 AWS 콘솔에 대한 암호가 있습니다.
• Groups: 사용자만 포함 (그룹 안에 그룹은 포함되지 않습니다.)
• Policies: 사용자 또는 그룹에 대한 권한을 설명하는 JSON 문서
• Roles: EC2 인스턴스 또는 AWS 서비스용
• Security: MFA + 비밀번호 정책
• Access Keys: CLI 또는 SDK를 사용하여 AWS에 액세스
• Audit: IAM 자격 증명 보고서 및 IAM 액세스 어드바이저

역할 용어 및 개념

역할

계정에서 생성할 수 있는 특정 권한을 가진 IAM 자격 증명입니다. IAM 역할은 IAM 사용자와 몇 가지 점에서 유사합니다. 역할과 사용자 모두 AWS에서 자격 증명으로 할 수 있는 것과 할 수 없는 것을 결정하는 권한 정책을 포함하는 AWS 자격 증명입니다. 그러나 역할은 한 사람과만 연관되지 않고 해당 역할이 필요한 사람이라면 누구든지 맡을 수 있어야 합니다. 또한 역할에는 그와 연관된 암호 또는 액세스 키와 같은 표준 장기 자격 증명이 없습니다. 대신에 역할을 맡은 사람에게는 해당 역할 세션을 위한 임시 보안 자격 증명이 제공됩니다.

역할은 다음의 주체들이 사용할 수 있습니다.

• 역할과 동일한 AWS 계정의 IAM 사용자
• 역할과 다른 AWS 계정의 IAM 사용자
• AWS에서 제공하는 웹 서비스 (ex: EC2)
• SAML 2.0, OpenID Connect 또는 사용자 지정 구축 자격 증명 브로커와 호환되는 외부 자격 증명 공급자(IdP) 서비스에 의해 인증된 외부 사용자

AWS 서비스 역할

서비스가 사용자를 대신하여 사용자 계정에서 작업을 수행하기 위해 수임한 역할입니다. 일부 AWS 서비스 환경을 설정할 때, 서비스에서 맡을 역할을 정의해야 합니다. 이 서비스 역할에는 서비스가 AWS 리소스에 액세스하는 데 필요한 모든 권한이 포함되어야 합니다. 서비스 역할은 서비스마다 다르지만, 해당 서비스에 대한 문서화된 요구 사항을 충족하는 한 대부분의 경우 권한을 선택할 수 있습니다. IAM 내에서 서비스 역할을 만들고, 수정하고, 삭제할 수 있습니다.

EC2 인스턴스의 AWS 서비스 역할

Amazon EC2 인스턴스에서 실행 중인 애플리케이션이 계정에서 작업을 수행하기 위해 수임할 수 있는 특수한 유형의 서비스 역할입니다. 이 역할은 시작된 EC2 인스턴스에 할당됩니다. 해당 인스턴스에서 실행 중인 애플리케이션은 임시 보안 자격 증명을 검색하고 역할이 허용하는 작업을 수행할 수 있습니다.

AWS 서비스 연결 역할

AWS 서비스에 직접 연결된 고유한 유형의 서비스 역할입니다. 서비스 연결 역할은 해당 서비스에서 사전 정의하며 서비스에서 다른 AWS 서비스를 자동으로 호출하기 위해 필요한 모든 권한을 포함합니다. 또한 연결된 서비스는 서비스 연결 역할을 만들고 수정하며 삭제하는 방법을 정의합니다. 서비스는 역할을 자동으로 만들거나 삭제하도록 허용할 수도 있습니다. 또는 사용자가 IAM을 사용하여 역할을 생성하거나 삭제해야 할 수도 있습니다. 방법이 어떻든, 서비스 연결 역할을 사용하면 필요한 권한을 수동으로 추가할 필요가 없으므로 서비스를 더 쉽게 설정할 수 있습니다.

역할 함께 묶기

역할 함께 묶기는 AWS CLI 또는 API를 통해 역할을 사용하여 두 번째 역할을 수임하는 경우 발생합니다. 예를 들어, User1에게 RoleA 및 RoleB를 맡을 권한이 있다고 가정해 보겠습니다. 또한 RoleA에는 RoleB를 맡을 권한이 있습니다. RoleA API 작업에서 User1의 장기 사용자 자격 증명을 사용하여 AssumeRole를 맡을 수 있습니다. 이 작업은 RoleA의 단기 자격 증명을 반환합니다. 역할 체인에 참여하기 위해 RoleA의 단기 자격 증명을 사용하여 RoleB를 맡을 수 있습니다.

역할을 맡을 때 세션 태그를 전달하고 태그를 전이적으로 설정할 수 있습니다. 전이적 세션 태그는 역할 체인의 모든 후속 세션에 전달됩니다.

역할 체인을 사용하면 AWS CLI 또는 AWS API 역할 세션이 최대 1시간으로 제한됩니다. AssumeRole API 작업을 사용하여 역할을 수임할 때 DurationSeconds 파라미터를 사용하여 역할 세션 길이를 지정할 수 있습니다. 역할에 대한 최대 세션 기간 설정에 따라 파라미터 값을 최대 43200초(12시간)까지 지정할 수 있습니다. 그러나 역할 함께 묶기를 사용해 역할을 수임하고 1시간보다 큰 DurationSeconds 파라미터 값을 지정하면 작업이 실패합니다.

AWS에서는 역할을 사용하여 EC2 인스턴스에서 실행되는 애플리케이션에 권한을 부여하는 것을 역할 함께 묶기로 간주하지 않습니다.

위임

제어하는 리소스에 대한 액세스를 허용하는 권한을 누군가에게 부여하는 것입니다. 위임은 두 계정 간에 신뢰를 설정하는 것을 포함합니다. 첫 번째는 리소스를 소유한 계정입니다. (신뢰하는 계정), 두 번째는 리소스에 액세스해야 하는 사용자가 포함된 계정입니다. (신뢰되는 계정). 신뢰받는 계정과 신뢰하는 계정은 다음 중 하나가 될 수 있습니다.

• 동일 계정
• 조직에서 통제하는 별도의 계정
• 서로 다른 조직이 소유한 2개의 계정

리소스에 액세스할 수 있는 권한을 위임하려면 두 개의 정책이 연결된 신뢰하는 계정에서 IAM 역할을 생성합니다. **권한 정책**은 역할 사용자에게 리소스에 대해 의도한 작업을 수행하는 데 필요한 권한을 부여합니다. **신뢰 정책(신뢰 관계)**은 역할을 위임하도록 허용된 신뢰할 수 있는 계정 멤버를 지정합니다.

신뢰 정책을 생성할 때 와일드카드(*)를 보안 주체로 지정할 수 없습니다. 신뢰 정책은 신뢰하는 계정의 역할에 연결되어 있고 권한의 절반에 해당합니다. 나머지 절반은 사용자에게 역할 전환 또는 위임을 허용하는 신뢰받는 계정의 사용자에게 연결된 권한 정책입니다. 임시로 역할을 위임하는 사용자는 자신의 고유 권한을 포기하고 대신 해당 역할의 권한을 위임합니다. 사용자가 역할을 끝내거나 역할 사용을 중지하면 원래 사용자 권한이 자동으로 회복됩니다. 외부 ID라 불리는 부가적인 파라미터는 동일한 조직에 의해 제어되지 않는 계정 사이에서 역할을 안전하게 사용하도록 하는 데 도움이 됩니다.

연동

외부 자격 증명 공급자와 AWS 사이에 신뢰 관계를 생성하는 것입니다. 사용자는 Login with Amazon, Facebook, Google 또는 **OpenID Connect(OIDC)**와 호환되는 IdP 등의 웹 자격 증명 공급자에 로그인할 수 있습니다. 또한, 사용자는 Microsoft Active Directory 연동 서비스와 같은 Security Assetion Markup Language(SAML) 2.0과 호환되는 앤터프라이즈 자격 증명 시스템에 로그인할 수 있습니다. OIDC 및 SAML 2.0을 사용해 이 외부 자격 증명 공급자와 AWS 사이에 신뢰 관계를 구성하면 사용자가 IAM 역할에 할당됩니다. 사용자는 임시 보안 자격 증명을 부여받아 AWS 리소스에 대한 액세스가 가능합니다.

페더레이션 사용자

IAM 사용자를 생성하는 대신 AWS Directory Service, 엔터프라이즈 사용자 디렉터리 또는 웹 자격 증명 공급자의 기존 자격 증명을 사용할 수 있습니다. 이 사용자를 페더레이션 사용자라고 합니다. AWS에서는 자격 증명 공급자를 통해 액세스가 요청되면 페더레이션 사용자에게 역할을 할당합니다.

신뢰 정책

역할을 수임하도록 신뢰하는 보안 주체를 정의하는 JSON 정책 문서입니다. 역할 신뢰 정책은 IAM의 역할에 연결된 필수 리소스 기반 정책입니다. 신뢰 정책에서 지정할 수 있는 보안 주체에는 사용자, 역할, 계정 및 서비스가 포함됩니다.

💡 신뢰 정책은 역할을 맡을 수 있는 보안 주체 엔터티(계정, 사용자, 역할 및 연합 사용자)를 정의합니다. IAM 역할은 리소스 기반 정책을 지원하는 리소스이자 자격 증명입니다. 이러한 이유로 신뢰 정책과 자격 증명 기반 정책을 모두 IAM 역할에 연결해야 합니다. IAM 서비스는 IAM 역할에 연결된 역할 신뢰 정책이라는 한 가지 유형의 리소스 기반 정책만 지원합니다.

권한 정책

JSON 형식의 권한 문서로, 역할이 사용할 수 있는 리소스와 작업을 정의합니다. 이 문서는 IAM 정책 언어의 규칙에 따라 작성됩니다.

권한 경계

자격 증명 기반 정책이 역할에 부여할 수 있는 최대 권한을 제어하는 정책을 사용하는 고급 기능입니다. 서비스 연결 역할에 권한 경계를 적용할 수 없습니다.

보안 주체

작업을 수행하고 리소스에 액세스할 수 있는 AWS의 개체입니다. 보안 주체는 AWS 계정 루트 사용자, IAM 사용자 또는 역할일 수 있습니다. 리소스에 액세스할 수 있는 권한을 다음 두 가지 중 한 가지 방식으로 부여할 수 있습니다.

• 권한 정책을 사용자에게(직접 또는 그룹을 통해 간접적으로) 또는 역할에게 연결할 수 있습니다.
• 리소스 기반 정책을 지원하는 서비스의 경우 해당 리소스에 연결된 정책의 Principal 요소에서 보안 주체를 식별할 수 있습니다.

AWS 계정을 보안 주체로 참조하는 경우 그 보안 주체는 일반적으로 해당 계정 내에서 정의된 모든 보안 주체를 의미합니다.

✅ 역할의 신뢰 정책에서 Principal 요소에 와일드카드(*)를 사용할 수 없습니다.

교차 계정 액세스를 위한 역할

한 계정의 리소스에 대한 액세스 권한을 다른 계정의 신뢰할 수 있는 보안 주체에 부여하는 역할. 역할은 교차 계정 액세스를 부여하는 기본적인 방법입니다. 그러나 일부 AWS 제품을 사용하면 (역할을 프록시로 사용하는 대신) 리소스에 직접 정책을 연결할 수 있습니다. 이를 리소스 기반 정책이라고 하며, 이 정책을 사용하여 다른 AWS 계정의 보안 주체에게 리소스에 대한 액세스 권한을 부여할 수 있습니다. 이러한 리소스에는 Amazon Simple Storage Service(S3) 버킷, S3 Glacier 볼트, Amazon Simple Notification Service (SNS) 주제 및 Amazon SImple Queue Service (SQS) 대기열이 포함됩니다.