AWS - IAM

jsbak·2023년 4월 25일

IAM Identity and Access Management

Cloud

목록 보기

35/59

IAM(; Identity and Access Management)

AWS 서비스에 대한 액세스를 안전하게 제어하는 웹 서비스
사용자, 액세스 키와 같은 보안 자격 증명, 사용자와 애플리케이션이 어떤 AWS 리소스에 액세스할 수 있는지 제어하는 권한을 한 곳에서 관리하도록 지원

IAM Users: Role 또는 group 지정 받아 권한 설정 가능
- IAM 사용자는 단일 개인 또는 애플리케이션에 대한 특정 권한을 가지고 있는 AWS 계정 내 자격 증명
- 가능하면 암호 및 액세스 키와 같은 장기 보안 인증 정보가 있는 IAM 사용자를 생성하는 대신 임시 보안 인증을 사용하는 것이 좋다
IAM Groups: 권한 or Role 할당 받음
- IAM 그룹은 IAM 사용자 컬렉션을 지정하는 자격 증명
- 여러 사용자의 권한을 한 번에 지정
- 대규모 사용자 집합의 권한을 더 쉽게 관리
IAM ROLES
- AWS 리소스에 액세스할 수 없는 사용자, 애플리케이션 또는 서비스에 액세스 권한을 위임
- IAM 역할은 특정 권한이 있는 AWS 계정 내의 ID 이다.
- 임시 자격 증명
- 사용 하는 경우
  - AWS 계정의 사용자에게 이들이 대개 권한이 없는 리소스에 대한 액세스 권한을 부여하는 경우
  - 페더레이션 사용자 액세스 & 임시 IAM 사용자 권한 & 크로스 계정 액세스
  - 교차 서비스 액세스
    - 보안 주체 권한
    - 서비스 역할
      - 서비스가 사용자를 대신하여 작업을 수행하기 위해 수임하는 IAM 역할
      - Ex) ☑️ EC2 인스턴스가 S3 버킷과 상호 작용할 수 있도록 필요한 권한을 구성
    - 서비스 연결 역할
      - AWS 서비스에 연결된 서비스 역할의 한 유형, 서비스는 사용자를 대신하여 작업을 수행하기 위해 역할을 수임
    - 한 AWS 계정의 사용자에게 다른 계정의 리소스에 대한 액세스 권한을 부여
  - Amazon EC2에서 실행 중인 애플리케이션

📶 IAM JSON 정책

IAM JSON 정책 참조 docs
- AWS JSON 정책을 사용하여 누가 무엇에 액세스할 수 있는지를 지정할 수 있습니다. 즉, 어떤 보안 주체가 어떤 리소스와 어떤 조건에서 작업을 수행할 수 있는지를 지정
  - 기본적으로, 사용자와 역할에는 어떠한 권한도 없습니다. 사용자에게 사용자가 필요한 리소스에서 작업을 수행할 권한을 부여하려면 IAM 관리자가 IAM 정책을 생성하면 됩니다. 그런 다음 관리자가 IAM 정책을 역할에 추가하고, 사용자가 역할을 맡을 수 있습니다.
- AWS 글로벌 조건 컨텍스트 키 : 보안 주체가 AWS에 요청하면 AWS는 요청 정보를 요청 컨텍스트로 수집합니다. JSON 정책의 Condition 요소를 사용하여 요청 컨텍스트의 키를 정책에서 지정한 키 값과 비교할 수 있습니다.
- IAM 및 AWS STS 조건 컨텍스트 키 : IAM 서비스(iam: 접두사 포함) 및 AWS Security Token Service(AWS STS) 서비스(sts: 접두사 포함)에서 정의 및 제공하는 키에 대해 설명합니다.

Amazon 리소스 이름(ARN) - ARN 구조 Docs
- IAM ARN docs
- 일부 리소스의 ARN에서는 리전, 계정 ID 또는 리전과 계정 ID가 모두 생략됩니다.

      arn:partition:service:region:account-id:resource-id
      arn:partition:service:region:account-id:resource-type/resource-id
      arn:partition:service:region:account-id:resource-type:resource-id

partition
리소스가 있는 파티션입니다. 파티션은 AWS 리전의 그룹입니다. 각 AWS 계정은 하나의 파티션으로 범위가 지정됩니다.
지원되는 파티션은 다음과 같습니다.
- aws - AWS 리전
- aws-cn - 중국 리전
- aws-us-gov - AWS GovCloud (US) 리전
service
AWS 제품을 식별하는 서비스 네임스페이스입니다.
region
리전 코드. 예를 들어 미국 동부(오하이오)의 경우 us-east-2입니다. 리전 코드 목록은 AWS 일반 참조의 리전 엔드포인트를 참조하세요.
account-id
리소스를 소유한 AWS 계정의 ID(하이픈 없음)입니다. 예: 123456789012.
resource-type
리소스 유형입니다. Virtual Private Cloud(VPC)의 vpc를 예로 들 수 있습니다.
resource-id
리소스 식별자입니다. 리소스의 이름, 리소스의 ID 또는 리소스 경로입니다. 일부 리소스 식별자에는 상위 리소스(sub-resource-type/parent-resource/sub-resource) 또는 버전과 같은 식별자(resource-type:resource-name:qualifier)를 포함할 수 있습니다.

🛜 액세스 관리

자격 증명을 통한 인증 - 인증은 ID 자격 증명을 사용하여 AWS에 로그인하는 방식

AWS 계정 루트 사용자 / 사용자 및 그룹 / IAM 역할

정책을 사용하여 액세스 관리

자격 증명 기반 정책

IAM 사용자, 사용자 그룹 또는 역할과 같은 자격 증명에 연결할 수 있는 JSON 권한 정책 문서, 사용자와 역할이 어떤 리소스와 어떤 조건에서 어떤 태스크를 수행할 수 있는지를 제어

리소스 기반 정책

리소스에 연결하는 JSON 정책 문서 (예: IAM 역할 신뢰 정책과 Amazon S3 버킷 정책), 정책에는 지정된 보안 주체가 해당 리소스와 어떤 조건에서 어떤 태스크를 수행할 수 있는지를 정의하고 이를 지원하는 서비스에서 서비스 관리자는 정책을 이용하여 특정 리소스에 대한 액세스를 제어 합니다.

리소스 기반 정책은 해당 서비스에 있는 인라인 정책, 리소스 기반 정책에서는 IAM의 AWS 관리형 정책을 사용할 수 없습니다.

IAM 과 Role 등의 연관성 알아보고 정리하기?

IAM 정책 평가

IAM 정책 평가 심층 분석 - AWS re:Inforce IAM433의 주요 내용 - 2022.09.29 - Noam Dahan
- 원문 내용 : IAM Policy Evaluation Series: policy evaluation chains | Amazon Web Services
정책 평가 로직
- 자격 증명 기반 + 리소스 기반 정책 을 통해 부여된 모든 권한을 평가하고 두 정책 유형의 모든 권한이 권한으로 부여
- 사용자의 자격 증명 기반 정책 + 권한 경계 를 평가하는 경우 결과적으로 두 범주의 공통 권한만 부여
- 조직 SCP + 자격 증명 기반 정책 평가: 사용자의 정책과 SCP의 공통 권한만 부여
- ❗계정 내에서 요청 허용 여부 결정
  - 동일한 계정 내에서 리소스 기반 정책은 리소스에 액세스하는 주체의 유형과 리소스 기반 정책에서 허용되는 주체에 따라 정책 평가에 다르게 영향을 미칩니다.
    - 주체 유형에 따라 ID 기반 정책, 권한 경계 또는 세션 정책에 암시적 거부가 있는 경우에도 ✅🆘리소스 기반 정책의 Allow 이 최종적으로 Allow 으로 결정될 수 있습니다.✅
      - ➡️ 요청하는 보안 주체 🟰 리소스 기반 정책에서 허용하려는 주체 (😊 두 주체가 동일한 경우 허용 )
- 교차 계정 정책 평가 여부
  - 리소스를 가진 계정(A)에서는 리소스를 사용하려는 외부 계정(B) 에게 리소스 접근을 명시적 허용
  - B에서는 A의 리소스에 접근할 수 있다는 정책을 명시적 허용
  - 두 계정의 각각의 자격 증명 기반 정책 과 리소스 기반 정책에서 모두 명시적 허용이 되어야 허용

정책 평가 결과

암시적 거부 - 작업을 허용하는 허용 문이 없기 때문에 거부
명시적 거부 - 일치하는 거부 문으로 인해 거부, AWS에서는 모든 거부 문이 모든 허용 문보다 우선시 됨.
명시적 허용 - 허용문 일치의 결과
참고: "암시적 허용"은 존재하지 않습니다. 오히려 명시적으로 허용되지 않은 것은 암시적으로 거부됩니다.

평가 규칙
- 명시적인 DENY는 항상 ALLOW 보다 우선시
- 허용하려면 평가 체인의 모든 노드에 명시적인 ALLOW가 필요

요청을 하는 IAM 주체

Role session:
- arn:aws:sts::123456789012:assumed-role/MyRole/MySession
  IAM 역할은 요청을 하지 않는다는 점을 상기시켜 주었습니다. 역할에 대한 임시 자격 증명으로 표시되는 역할 세션이 요청을 수행합니다.
IAM user:
- arn:aws:iam::123456789012:user/MyUser
- Principal 요소로 사용자를 지정할 때는 "모든 사용자"의 의미로 와일드카드(*)를 사용할 수 없습니다.
  - 보안 주체는 항상 특정 사용자가 되어야 하기 때문
  - 따라서 계정 보안 주체를 설정하고 Condition 요소를 통해서 액세스할 수 있는 주체를 제한
Federated user (sts:GetFederationToken 사용):
- arn:aws:sts::123456789012:federated-user/MyUser
  참고: 이름에도 불구하고 연동 사용자는 표준 SSO 연동 프로세스에 직접 관여하지 않습니다. 오히려 IAM 사용자로부터 파생된 임시 세션(임시 자격 증명 포함)입니다.
Anonymous
Root

정책 "Principal" 요소에서 가능한 값

AWS JSON 정책 요소: Principal

All principals(모든 주체): T
- *
Account principal(계정 주체):
- arn:aws:iam::111111111111:root
- 111111111111
Role principal(역할 주체):
- arn:aws:iam::111111111111:role/MyRole
Boundary principal(경계 주체):
- 이는 평가에서 내부적으로 사용되는 가상 주체이며, IAM 정책 언어에서 직접 참조할 수 없습니다.
Session principal(세션 주체):
- arn:aws:sts::111111111111:assumed-role/MyRole/MyRoleSession

🆘정책 평가 로직🆘

정책 평가 로직 docs
🆘 리소스에 리소스 정책이 없는 경우 동작은 원래 평가 체인에서와 동일하며 모든 노드에 명시적 허용이 존재해야 합니다.

리소스 정책에 대해 자세히 알아봅시다. 리소스 정책에서 주체를 허용하면 어떻게 되나요? 이 작업은 서비스 제어 정책에 의해 허용되어야 하며, 리소스 정책에 의해 허용된 주체 다음에 오는 평가 체인의 정책에 의해서만 허용되어야 합니다. 네, 이것이 바로 이 모델에서 가장 어려운 부분입니다.

  {
      "Effect": "Allow",
      "Principal": {
          "AWS": "arn:aws:iam::111111111111:root"
      },
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::my_bucket/*"
  }

위의 정책은 실제로 계정 주체를 허용합니다. 따라서 권한 평가가 허용 결과에 도달하려면 해당 정책이 SCP, ID 기반 정책, 세션 정책, 그리고 존재하는 경우 권한 경계에서 허용되어야 합니다.

질문: 정책에서 역할 주체를 허용하면 어떻게 되나요?

  {
      "Effect": "Allow",
      "Principal": {
          "AWS": "arn:aws:iam::111111111111:role/MyRole"
      },
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::my_bucket/*"
  }

답변: 위의 정책에서 리소스 정책은 역할 주체를 허용하므로 자격 증명 기반 정책에서 허용이 필요하지 않습니다! 이것이 자격 증명 기반 정책에 허용이 없어도 리소스 정책의 허용으로 충분한 익숙한 동작을 만드는 이유입니다.

질문: 허용된 주체가 역할 세션인 경우 어떤 점이 변경되나요?

  {
      "Effect": "Allow",
      "Principal": {
          "AWS": "arn:aws:sts::111111111111:assumed-role/MyRole/MySession"
      },
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::my_bucket/*"
  }

답변: 리소스 정책은 세션 주체를 직접 허용하므로 권한 경계 또는 세션 정책에서 허용이 필요하지 않습니다.

그래도 꼭 기억하세요: 허용 문이 없는 경우에도 거부 문은 모든 관련 정책에 대해 계속 확인됩니다. 예를 들어 권한 경계에 명시적으로 거부를 지정해도 여전히 거부로 이어집니다.

교차 계정의 경우

교차 계정의 경우, 리소스 정책에서 권한을 부여하는 주체에 관계없이 ID와 리소스 양쪽에서 모든 권한 게이트를 통과해야 합니다.

IAM 사용자의 경우

일반적으로 IAM 사용자에게는 세션이 없습니다. 따라서 작업을 수행하는 실제 자격 증명으로 표시되는 주체가 세션을 가지고 있으며, 아래 차트에서 이 엔티티는 가상 경계 주체의 오른쪽에 표시됩니다.

IAM

인증과 접근 권한을 제어하는 서비스

접근: IAM 검색 또는 서비스 - 보안, 자격 증명 및 규정 준수 - IAM 클릭

IAM Role 정의

AWS 관리형 권한과 고객 관리형 권한이 따로 존재
권한 정책
- 최대 10개의 관리형 정책을 연결 가능 ❗

기본 Role 삭제

IAM - 탭 - 액세스 관리 - 역할
지울 수 없는 Role: AWSServiceRoleForSupport, AWSServiceRoleForTrustedAdvisor
기본 role 제거

사용자 그룹 생성

IAM 대시보드 - 액세스 관리 - 사용자 그룹
그룹 생성 클릭
그룹 이름 지정
권한 지정 후 그룹 생성 클릭

사용자 생성

IAM 대시보드 - 액세스 관리 - 사용자
사용자 추가 클릭

사용자 세부 정보 지정

AWS Management Console에 대한 사용자 액세스 권한(웹 콘솔(GUI 환경)을 이용하게 할 것인지 여부)

권한 설정

권한 복사
- 다른 사용자에 부여된 권한을 복사
직접 정책 연결
- 직접 권한을 부여하는 방식
  - ex. administrator 계정 추가시

권한 옵션 설정 및 사용자 그룹 선택

검토 및 생성

사용자 설정 정보 체크 후 사용자 생성 클릭

암호 검색

로그인 URL
사용자 이름
암호: 복사해서 가지고 있어야함.
- |t)A9'*#

생성한 사용자 로그인

콘솔 로그인 URL로 접속하여 생성한 user 사용자로 로그인
최초 로그인 시 암호 설정
계정 정보에 사용자@AWS계정넘버

생성한 사용자의 권한 확인(Read EC2)

보기 확인
권한 부족으로 EC2 생성 실패

사용자 그룹 권한 변경

IAM - 액세스 관리 - 사용자 그룹 - 권한

권한 제거

권한 선택 - 제거 클릭

권한 추가

권한 추가 - 권한 연결 클릭

권한 적용확인

권한 상승 후 EC2생성 확인
IAM 권한 바로 적용
EC2 생성 확인

계정 별칭

7685300152441 같은 12자리 계정 ID 대신 사용 가능한 문자열
IAM 대시보드 또는 보안 자격증명 - 대시보드
계정 별칭 생성 클릭
별칭 지정후 변경 사항 저장 클릭
별칭 저장 결과
별칭으로 사용자 로그인
로그인 결과; 계정 ID 대신 계정 별칭으로 표현됨.

Security Token Services

AWS Security Token Services
IAM 역할에 대한 임시 자격 증명
- 역할 및 아이덴티티 페더레이션을 위한 기초
  - IAM 역할은 계정에 생성할 수 있는, 특정 권한을 지닌 IAM 자격 증명

순서

리소스에 대한 정책 생성
역할 생성 - 리소스 권한 정책 연결 - 다른 엔티티가 역할을 가정할 수 있도록 sts:AssumeRole 설정
- 사용할 정책 선택
리소스 역할을 수임하는 정책 정의 (Assume Policy 생성)
- 역할을 가정하는 데 사용할 역할에게 어떤 역할이나 엔터티가 해당 역할을 가정할 수 있는지를 지정
- 보통의 경우 - 다른 엔터티가 해당 역할을 가정할 수 있도록 "sts:AssumeRole"와 같은 권한을 가진 역할 수임 정책을 지정
Entity IAM User / Resource(ec2/lambda/etc..) 에 리소스에 역할 수임 정책 연결

역할을 생성하고 사용자에게 부여하는 예제

`DynamoDBListTables` 정책 생성

역할 생성

신뢰할 엔티티 타입 정의
- 서비스 유형
- Account 유형 - account 유형 및 설정 옵션 상황에 맞게 선택
Permission 추가
Role 이름 / 설명 정의
역할을 수임하는 정책 정의 - lambda (sts:AssumeRole)
역할을 수임하는 정책 정의 2 - IAM User
- 역할 생성 시 Trusted entity type - Custom trust policy 선택 후 지정
- 또는 생성한 Role 세부 정보 - Trust relationships - Edit trust policy 클릭 후 변경 가능

IAM User 에 역할 수임할 정책 생성

IAM User 에 역할 수임 정책 연결

생성한 유저 혹은 유저 생성시 Add permissions
역할 수임 정책 선택하여 연결

User와 임시 자격 증명을 통한 연결 확인

기본 유저의 권한으로는 DynamoDB 테이블 리스트 조회 불가능
IAM 사용자의 역활 전환하기
- 상단의 사용자 - Switch role 클릭
- 역활 전환 정보 입력후 역할 전환 클릭
역할을 통한 임시 자격 증명 확보
- 역할 전환과 이를 통해 얻은 임시 자격 증명으로 DynamoDB 테이블 리스트 조회 가능

Cf. 역할을 생성하여 IAM 사용자에게 권한 위임 DOCS

역할을 생성하여 IAM 사용자에게 권한 위임 DOCS
IAM 역할을 사용해 AWS 리소스에 대한 액세스 권한을 위임
- 계정 간의 신뢰 관계를 설정할 수 있다.
  - 액세스되는 리소스를 소유하는 계정이 있고, 이 리소스를 액세스 가능한 다른 계정의 사용자를 소유하는 계정 측에 저장
    - 원문
      1. IAM 역할을 사용해 신뢰하는 계정과 다른 AWS 신뢰받는 계정 간에 신뢰 관계를 설정할 수 있다.
      2. 신뢰하는 계정은 액세스되는 리소스를 소유하고 신뢰받는 계정은 리소스에 대한 액세스가 필요한 사용자를 저장한다.
  - 이를 통해 신뢰 관계가 생성되면 다른(외부) 계정의 IAM 사용자 또는 애플리케이션은 AWS STS AssumeRole API 작업 사용 가능 - 외부의 계정에 소유하는 계정의 AWS 리소스에 액세스할 수 있는 임시 자격 증명을 제공

역할을 만들고 다른 계정이 이를 이용하도록 지정하는 방법

IAM Role chaining walkthrough
람다 실행 ▶️ Role 평가 ▶️ 정책 평가 ▶️ 대상 계정의 Role 에서 소스 계정의 역할이 신뢰할 수 있는 것인지 확인 ▶️ 정책 평가 ▶️ 대상 리소스에 대한 API 실행 후 결과 반환

참고 링크

jsbak

끄적끄적 쓰는곳

이전 포스트

AWS - EBS, EBS Snapshot, AMI

다음 포스트