IAM - 고급(1)

AWS Organizations

• 글로벌 서비스
  다수의 AWS 계정을 동시에 관리
• 조직을 생성하면 조직의 메인 계정이 관리 계정이 된다.
• 조직에 가입한 기타 계정이나 조직에서 생성한 계쩡은 멤버 계정이라 부른다.
  멤버 계정은 한 조직에만 소속된다.
• Organizations는 모든 계정의 비용을 통합 결제할 수 있다.
  관리 계쩡에 하나의 지불 방법만 설정해 두면 조직 전체의 비용을 지불할 수 있다.
  또 조직 내 모든 계정에 대해 집계된 사용량에 기반한 비용 할인을 받을 수 있다.
• 모든 계정에서 EC2 또는 S3를 많이 사용한다면 모든 계쩡의 사용량이 합쳐져 계산되므로 큰 할인 혜택을 받을 수 있다.
• 계정 간에 예약 인스턴스와 Savings Plans 할인이 공유된다.
  어떤 계정에서 사용하지 않는 예약 인스턴스가 있을 때 다른 계정이 해당 인스턴스를 사용할 수 있습니다.
• Organizations 내 계정 생성을 자동화할 수 있는 API가 있어 Organizations를 사용해 계정을 쉽게 생성할 수 있다.

동작 원리

- 루트 조직 단위(OU)가 있다.
이는 전체 계정에서 제일 외곽에 있음.
- OU안에는 관리 계정이 있고 서브 OU를 생성할 수 있다.
예를 들어 개발 계정 OU를 생성하고 그 안에 멤버 계정을 생성하거나
프로덕션 계정 OU를 생성하고 멤버 계정을 추가할 수 있다.
- OU 안에 HR 멤버 계정 OU를 만들 수도 있고, 재무 멤버 계정 OU를 만들 수도 있고 원하는대로 조직이 가능하다.

• OU 활용 예시
  

Organizations의 장단점

• 장점
  • 다수의 계정을 가지므로 다수의 VPC를 가진 단일 계정에 비해 보안이 뛰어나다.
    계정이 VPC보다 독립적이기 때문이다.
  • 청구 목적의 태그 기준을 적용할 수 있다.
  • 한 번에 모든 계정에 대해 CloudTrail을 활성화해서 모든 로그를 중앙 S3 계정으로 전송할 수 있다.
  • CloudWatch Logs를 중앙 로깅 계정으로 전송할 수도 있다.
  • 자동으로 관리 목적의 계정 간 역할을 수립할 수 있어 관리 계정에서 모든 멤버 계정을 관리할 수 있다.
• 보안 측면: 서비스 제어 정책(SCP) 정의
  • 특정 OU 또는 계쩡에 적용되는 IAM 정책으로 해당 사용자와 역할 모두가 계정 내에서 할 수 있는 일을 제한한다.
  • SCP는 모든 대상에 적용되나 영구적인 관리자 권한을 갖는 관리 계정은 적용되지 않는다.
  • SCP는 기본적으로 아무것도 허용하지 않는다
    구체적인 허용 항목을 설정해야 한다.

SCP Hierarchy

- 루트 OU가 있고, 관리 계정이 있다.
- 프로덕션 OU안에 계정 A가 있다.
- 서브 OU인 HR OU, 재무 OU에는 각각 계정 B와 C가 들어있다.
- SCP가 각 계정의 권한에 미치는 영향을 보자
----------------------------------------------------------
- 일반적으로 루트 OU에는 FullAWSAccess SCP를 적용한다.
- 관리 계정에는 DenyAccessAthena SCP를 적용한다.
- 프로덕션 OU에는 DenyRedshift SCP를 적용한다.
- HR OU에 DenyAWSLambda SCP 적용
--------------------------------------------------------
[관리 계정]
- 관리 계정에 Athena 서비스 액세스를 제한하기 위해 DenyAccessAthena SCP를 적용했지만 관리 계쩡에는 SCP가 적용되지 않으므로 여전히 모든 것이 가능하고 모든 대상에 대해 관리자 권한을 갖는다.
[계정 A]
- 루트 OU에 있으므로 많은 것을 할 수 있다.
계정 A는 프로덕션 OU에 속하기도 하기때문에 프로덕션 OU에는 DenyRedshift SCP가 적용되어있어 Redshift에 액세스할 수 없다.
- AuthorizedRedshift SCP가 계정 A에 추가되어 있지만 정책에 명시적 거부가 하나라도 포함되면 기본적으로 액세스가 거부된다.
즉, 계정 A는 Redshift 외의 모든 일을 할 수 있다.
[계정 B]
- 프로덕션 OU 안에있는 HR OU에 속하고 모든 것을 상속한다.
계정 B는 루트 OU로부터 FullAWSAccess SCP를 상속하고 프로덕션 OU로부터 DenyRedshift SCP를 HR OU로부터 DenyAWSLambda SCP를 상속받는다.
즉, Redshift, Lambda 외의 모든 일을 할 수 있다.
[계정 C]
- 계정 B와 같지만 Lambda SCP는 해당하지 않아 Redshift 외의 모든 일을 할 수 있다.

SCP 예시 (차단 목록/허용 목록 전략)

• 차단 목록: 계정이 사용하지 못하게 할 서비스 지정
  
  Allow, *로 모든 서비스 허용 후 Deny를 추가해 특정 액세스 거부하는 방법
• 허용 목록: 계정이 사용할 서비스 지정
  
  모든 액션을 허용하지 않고 특정 서비스만 허용하는 방식
  
  

IAM 조건

• IAM 조건은 IAM 내부의 정책에 적용되고 사용자 정책이거나 예를들어 S3 버킷에 대한 리소스 정책일 수 있다.
  + 엔드 포인트 정책 등 어떤 정책도 될 수 있다.
• 첫 번째 조건: aws:SourceIp
  
  API 호출이 생성되는 클라이언트 IP를 제한하는 데 사용되는 조건
  - 위 정책은 모든 작업과 리소스를 거부하지만 두 개의 IP 주소 범위에 포함되지 않는 IP 주소를 거부
  - 이는 클라이언트가 해당 IP 주소 내에서 API 호출을 하지 않으면 API 호출이 거부된다는 뜻
  - 예를 들어 회사 네트워크에서만 AWS를 사용하도록 제한
• 두 번째 조건: aws:RequestedRegion
  
  AWS로 시작하므로 글로벌 조건이다
  API 호출 리전을 제한한다.
  - eu-central-1와 eu-west-1 리전에서 오는 EC2, RDS, DynamoDB 호출을 제한한다.
  - 특정 리전에서 특정 서비스에 대한 액세스를 거부
  - 이 조건을 조직 SCP에 보다 글로벌하게 적용해 특정 리전의 액세스를 허용하거나 거부할 수 있다.
• ec2:ResourceTag
  
  태그의 접두사가 EC2이므로 이 조건은 EC2 인스턴스의 태그에 적용된다.
  - ResourceTag/Project가 DataAnalytics일 때 모든 인스턴스의 시작과 종료를 허용한다.
  - 인스턴스가 올바른 태그를 갖고 있으면 즉, Project가 DataAnalytics이면 허용된다.
  - 다음 줄의 aws:PrincipleTag는 사용자 태그에 적용된다.
  EC2 인스턴스 태그가 아닌 사용자 태그이다.
  - 상기 작업을 수행하려면 사용자의 Department가 Data여야 한다.
• aws:MultiFactorAuthPresent // 멀티팩터 인증을 강제하기
  
  - 정책을 보면 EC2에서 모든 작업을 할 수 있지만 멀티팩터 인증이 있어야만 인스턴스를 중지하고 종료할 수 있다.
  - MFA가 false일 때 거부된다.
• S3에 대한 IAM 정책
  
  - s3:ListBucket
  s3:::test라는 ARN에 적용되는 정책
  - 버킷 수준의 권한이므로 버킷을 특정해야 한다.
  - s3:GetObject, se:PutObject, s3:DeleteObject는 버킷 내의 객체에 적용되므로 ARN이 달라진다.
  s3:::test/ 같이 버킷 내의 모든 객체를 나타내는 / 가 들어간다.
  ==> 객체 수준 권한이기 떄문에 ARN이 달라진 것이다.
• aws:PrincipalOrgID & 리소스 정책
  - aws:PrincipalOrgID는 AWS 조직의 멤버 계정에만 리소스 정책이 적용되도록 제한한다.
  
  - 다수의 계정이 포함된 조직이 있고, 오른쪽과 같은 정책이 적용된 s3 버킷이 있다.
  - 이에 따르면 PrincipleOrgID의 계정에서 API 호출이 생성된 경우에만 PutObject, GetObject 작업을 할 수 있다.
  - 조직 내의 멤버 계정만 S3 버킷에 액세스할 수 있고, 조직 외부의 사용자는 이 S3 버킷에 액세스할 수 없다.

IAM 역할 VS 리소스 기반 정책

• 교차 계정(특히 S3 버킷 교차 계정)
  • API 호출을 수행하려는 경우 옵션
    
    • 1. 리소스 기반 정책(ex: S3 버킷 정책)을 리소스에 연결
    • 2. 또는 실제로 리소스에 액세스할 수 있는 역할을 사용하도록 결정
  • 계정 A의 사용자가 계정 B에서 역할을 맡을 수 있는 예시
    해당 역할에는 S3 버킷에 액세스할 수 있는 권한이 있다.
  • 또는 계정 B의 S3 버킷에 적용된 버킷 정책을 통해 계쩡 A의 사용자가 S3 버킷에 액세스할 수 있다.
  • 위 두 가지 방법의 차이점
    - 첫 번째는 S3 버킷에 액세스할 수 있는 IAM 역할이고
    - 두 번째는 사용자에게 허용된 S3 버킷 정책이다.

실제로 역할을 맡을 때 차이점은?

• 원래의 모든 권한을 실제로 포기하고 해당 역할에 할당된 모든 권한을 가져 간다.
  예를들어 어떤 역할을 맡는다는 것을 의미한다.
  이 역할은 현재 우리가 할 수 있는 모든 작업을 할 수 있다.
  하지만 우너래 우리의 권한을 사용할 수는 없다.
• 따라서 리소스 기반 정책을 사용할 때는 우너칙이 역할을 가정하지 않으므로 권한을 포기할 필요가 없다.
  예를 들어 계정 A의 사용자가 계쩡 A의 DynamoDb 테이블을 스캔하고 그 데이터를 계정 B의 S3 버킷에 덤프해야 할 경우 리소스 기반 정책을 사용해야 한다.
  - 이렇게 하면 역할을 가정할 필요 없이 DynamoDB 테이블을 스캔하고 다른 계정의 S3 버킷에 데이터를 쓸 수 있다.
• 리소스 기반 정책은 시간이 지남에 따라 더 많은 AWS 서비스 및 리소스에서 지원되게 될 것이다.
  S3 버킷, SNS, SQS, Lambda 등..
  
  
• 가장 큰 차이점은 EventBridge를 사용할 때이다.
  • EventBridge는 규칙이 있다.
    이 규칙들은 목표 대상에서 원하는 일을 수행하기 위한 권한이 필요하다.
• 대상 (2 가지)
  
  • 리소스 기반 정책을 지원하는 대상
    Lambda, SNS, SQS, API Gateway 등..
    이 경우 EventBridge 규칙이 필요로 하는 자겅ㅂ을 수행할 수 있도록 대상 리소스의 리소스 기반 정책을 변경해야 한다.
  • IAM 역할이 필요한 대상
    kinesis Data Streams나 Systems Manager Run Command, ECS 작업 시작 과 같은 경우 IAM 역할이 필요하므로 IAM 역할이 EventBridge 규칙에 첨부될 것이다.
    그리고 Kinesis에 쓸 수 있는 권한을 갖게 된다.