IAM

PreviousAWS Console / CLI / SDK NextEC2

Last updated 28 days ago

IAM

조직

AWS 조직은 글로벌 서비스이며, 여러 AWS 계정을 동시에 관리할 수 있게 해준다.
관리 계정은 조직 내의 주요 계정을 의미하고, 멤버 계정은 조직에 가입하거나 조직에서 생성된 계정들을 의미한다.
멤버 계정은 하나의 조직에만 속할 수 있다.
관리 계정에 하나의 결제 방법을 설정하면 조직의 모든 비용을 지불할 수 있다.
조직 내부의 사용량이 통합되어 집계되므로 가격 혜택을 받을 수 있다. 예를 들어 예약 인스턴스와 절약 계획 할인을 계정 간에 공유하며 한 계정에서 예약 인스턴스가 사용되지 않으면 다른 계정이 그 혜택을 받을 수 있고 할인 역시 전체 조직에 적용된다.
조직 내에서 계정 생성을 자동화할 수 있는 API를 제공하므로 계정을 쉽게 생성할 수 있다.
OU
- 루트 조직 단위
- 계층을 갖도록 생성 가능하다.
장점
- 계정이 분리되어 있는 형태이므로 하나의 계정에 여러 VPC를 두는 것보다 더 나은 보안을 제공한다.
- 청구 목적을 위한 태그 표준을 강제할 수 있다.
- 한 번에 모든 계정에 대해 CloudTrail을 활성화하여 모든 로그를 중앙 S3 계정으로 보낼 수 있다.
- CloudWatch 로그를 중앙 로깅 계정으로 보낼 수 있다.
- 관리 목적으로 Cross Account Roles을 설정해 관리 계정에서 모든 멤버 계정을 관리할 수 있다.
서비스 제어 정책
- SCP (Service Control Policy)
- 특정 OU나 계정에 적용되는 IAM 정책
- 사용자와 역할이 계정 내에서 할 수 있는 작업을 제한할 수 있다.
- 관리 계정에는 적용되지 않는다. 관리 계정은 항상 전체 관리자 권한을 가진다.
- 루트를 포함한 각 사용자가 특정 작업을 허용하기 위해 명시적인 허용을 가지고 있는지 확인해야 한다.
- SCP 계층 구조는 다음과 같다.
  - 전체 AWS 액세스를 루트에 지정한다. 관리 계정은 루트 OU 아래에 있다.
  - 관리 계정에 Athena를 거부하는 SCP를 적용하더라도 관리 계정에는 영향이 없다.
  - 각 OU에 명시적 허용을 위한 전체 AWS 액세스를 적용하고, 거부 정책을 적용한다. 전체 AWS 액세스를 적용하지 않으면 아무 것에도 접근하지 못할 것이다.
  - 각 계정마다도 정책을 적용할 수 있다.
특정 서비스를 차단하려면 모든 작업을 허용한 다음 거부 정책을 추가하면 된다.
특정 서비스만 허용하도록 정책을 추가할 수도 있다.

IAM 권한

유저와 그룹

유저
- AWS 계정 설정하는 경우 외에는 루트 계정 대신 IAM 계정을 만들어 사용해야 한다.
- 사용자를 그룹에 할당하여 그룹 별로 권한을 할당할 수 있다.
- 다양한 권한 종류가 존재한다.
그룹
정책
- JSON 기반으로 설정할 수 있다.

방어 매커니즘

비밀번호 정책 정의
- IAM 콘솔에서 최소 비밀번호 길이, 포함해야 할 문자 타입, 만료 시간, 이전 비밀번호 재사용 금지 등의 정책을 설정할 수 있다.
MFA (Multi Factor Authentication)
- 다중 인증 (n단계 인증)
- 관리자인 경우 많은 작업을 사용할 수 있다.
- 비밀번호를 도난당하여도 등록된 물리적 장비가 있어야 로그인 가능하게 된다.
- 다음 장치들을 사용할 수 있다.
  - Virtual MFA device (Duo Mobile, Google Authenticator, Authy 등 애플리케이션)
  - YubiKey (단일 보안키를 사용해 여러 루트 및 IAM 사용자를 지원한다.)
  - Hardware Key Fob MFA Device (장치로부터 TOTP 토큰을 생성해 사용한다.)

IAM 역할

AWS 서비스에게 할당하는 권한을 IAM 역할으로 관리한다. 이 경우에는 실제 사용자가 사용하지 않는다.
AWS에서 정보를 조회하기 위해 IAM 역할으로 접근 권한을 부여해야 한다.

Resource-base Policy와의 차이점

서로 다른 계정 간 호출을 위해 리소스에 리소스 기반 정책을 부여하거나 리소스에 실제로 접근할 수 있는 IAM 역할을 사용할 수 있다.
역할을 부여받으면 모든 원래의 권한을 포기하고 그 역할에 할당된 모든 권한을 받는다. 하지만 원래의 권한은 사용할 수 없다.
리소스 기반 정책을 사용할 때는 주체가 역할을 맡지 않으므로 자신의 권한을 포기할 필요가 없다.
예를 들어, 계정 A가 계정 A의 DynamoDB 테이블을 스캔하고, 이를 계정 B의 S3 버킷에 덤프해야 한다면 리소스 기반 정책을 사용하여 다른 계정의 S3 버킷에 DynamoDB 테이블을 스캔하고 쓸 수 있다.
Amazon S3 버킷, SNS, SQS, Lambda 함수 등 점점 더 많은 AWS 서비스와 리소스가 리소스 기반 정책을 지원하고 있다.
Amazon EventBridge를 사용할 때 대상에 대한 권한이 필요한데, 대상이 리소스 기반 정책을 지원한다면 EventBridge가 대상에 리소스 기반 정책을 추가하여 EventBridge 규칙에서의 호출을 허용할 수 있다. 대상이 리소스 정책을 지원하지 않는다면 EventBridge는 IAM 역할을 사용하여 대상 서비스를 호출한다.
- Kinesis Stream, EC2 Auto Scaling, System Manager Run Command, ECS 작업 등은 아직 리소스 기반 정책을 지원하지 않는다.
IAM 역할을 이용하면 일반적으로 여러분 조직의 AWS 리소스에 액세스할 수 없는 사용자나 서비스에게 액세스 권한을 위임할 수 있다.

IAM Security Tools

IAM Credentials Report (자격 증명 보고서)
- 계정에 있는 사용자와 다양한 자격 증명 상태를 포함한다.
Access Advisor (액세스 관리자)
- 사용자에게 부여된 서비스 권한과 서비스에 마지막으로 접근한 시간을 알려준다.
- 어떤 권한이 사용되지 않는지 확인하여 최소 권한 원칙을 지킬 수 있다.

IAM 조건

IAM 내부의 정책에 적용되며 사용자 정책이거나 리소스 정책, 엔드포인트 정책 등이 될 수 있다.
아래 조건들을 비롯한 다양한 조건들이 존재한다.
aws:SourceIp
- API 호출이 생성되는 클라이언트 IP를 제한하는 데 사용되는 조건이다.
- 특정 IP 주소 범위에 포함되지 않는 IP 주소에 대해 모든 작업과 리소스를 거부(Deny)한다.
- 이를 통해 회사 네트워크에서만 AWS를 사용하도록 제한하여 회사 내에서만 AWS 환경에 액세스할 수 있게 설정할 수 있다.
aws:RequestedRegion
- API 호출 리전을 제한하는 글로벌 조건이다.
- 특정 리전에서 특정 서비스에 대한 액세스를 거부한다.
ec2:ResourceTag
- EC2 인스턴스의 태그가 매칭될 때 특정 작업을 수행하도록 할 수 있다.
- 예를 들어 ResourceTag/Project가 DataAnalytics일 때 모든 인스턴스의 시작과 종료를 허용할 수 있다.
aws:PrincipleTag
- 사용자 태그가 매칭될 때 AWS의 특정 작업을 수행하도록 한다.
aws:MultiFactorAuthPresent
- 멀티팩터 인증을 강제하는 조건이다.
- 예를 들어 사용자가 멀티팩터 인증을 거쳐야만 EC2에서 작업이 가능하도록 할 수 있다.
aws:PrincipalOrgPaths
- 요청자가 AWS Organizations의 지정된 조직 루트 또는 조직 단위(OU) 내의 계정 멤버인지 확인한다.
S3 IAM 정책
- 버킷 수준 정책과 객체 수준 정책을 설정할 수 있다.
- 버킷 수준의 권한은 버킷을 특정해야 한다.
- 객체 수준의 권한은 객체에 대한 허용 범위(GetObject, PutObject DeleteObject 등)와 객체를 특정해야 한다. /*을 명시해 버킷 내의 모든 객체를 나타낼 수 있다.

리소스 정책
- aws:PrincipalOrgID 조건은 AWS 조직에 속한 멤버 계정에만 리소스 정책이 적용되도록 제한할 수 있다.
- 조직 외부의 사용자는 정책에 의해 액세스가 거부된다.

Permission Boundaries

IAM의 최대 권한을 정의할 수 있다.
권한 경계(Permissions boundary)는 사용자와 역할만 지원하고 그룹은 지원하지 않는다.
IAM 권한 경계를 작성하여 IAM 사용자에 연결하면 권한 경계를 설정할 수 있다.
IAM 권한 경계 밖에 있는 IAM 정책은 유효하지 않게 된다.
예를 들어 IAM 권한 경계에서 AmazonS3FullAccess만을 지정하면, 사용자에게 AdministratorAcess가 있어도 권한 경계인 S3 내부에만 액세스할 수 있다.
다음 그림과 같이 사용자나 그룹에 부여된 자격 증명 기반 정책과 그룹이 아닌 사용자나 역할에만 적용되는 권한 경계와 Organizations SCP에 모두 해당되는 권한만 사용자에게 주어진다.

사용 목적
- 관리자가 아닌 사용자에 권한 경계 내에서 새 IAM 사용자를 생성하는 등의 책임을 위임하기 위해 사용된다.
- 개발자가 권한을 스스로 부여하고 관리하는데 특권을 남용하는 것을 막기 위해 스스로를 관리자로 만들지 못하게 할 수 있다.
- 계정에 SCP를 적용하여 계정의 모든 사용자를 제한하지 않고 AWS Organizations의 특정 사용자만 제한할 수도 있다.
IAM 정책 평가 논리
- 전체 흐름 중에 각 단계마다 평가가 이루어지며 명시적인 거부가 있다면 자동으로 거부된다.
- 모든 단계에서 허용됐을 때만 최종적으로 작업을 진행할 수 있다.
예를 들어 IAM 정책은 다음과 같이 동작한다.
- sqs:*에 Deny가 명시되어 있기 때문에 sqs:* 안에 있는 sqs:DeleteQueue는 Allow가 있음에도 자동으로 거부된다.
- 명시적 허용이 없기 때문에 ec2:DescribeInstances를 실행할 수 없다.

IAM Identity Center

이전에 AWS 싱글 사인온 서비스라고 불리던 것과 동일한 제품이다.
AWS 조직이나 비즈니스 클라우드 애플리케이션의 모든 AWS 계정에서 한 번만 로그인하면 된다.
Identity Center를 Salesforce, Box, Microsoft 365 등 비즈니스 클라우드 애플리케이션, SAML2.0 통합이 가능한 애플리케이션, EC2 Windows 인스턴스와 통합하면 싱글 로그인 기능을 이용할 수 있다.

시험에서는 아마 여러 AWS 계정을 한 번에 로그인하는 것에 대해 나올 겁니다

Identity Providers
- 사용자는 IAM 자격 증명 센터에 내장된 ID 저장소나, 서드파티 ID 공급자에 저장될 수 있다.
- IAM과 유사하게 사용자나 그룹을 정의할 수 있다.
- 서드 파티 ID 공급자는 Active Directory(AD), OneLogin, Okta 등일 수 있다.
자격 증명 센터에 로그인하고 원하는 계정을 클릭하여 바로 원하는 서비스로 연결할 수 있다.
여러 개의 AWS 계정을 가지고 있다면 이 서비스를 사용하면 편리하다.
자격 증명 센터에서 권한 셋을 정의해서 사용자마다 액세스 권한을 정의해야 한다.
- 예를 들어 한 AWS 조직이 있으면 관리 계정에 IAM 자격 증명 센터를 설정한다.
- 그리고 여러 OU가 있고 OU 내부에 여러 계정이 있는 상황에서 Bob과 Alice가 개발 OU의 모든 계정에 대해 액세스 권한을 갖게 하려면, 권한 셋을 개발 OU와 연결하고 Identity Center의 그룹에 할당하면 된다.
다중 계정 권한
- AWS 조직에서 여러 계정에 대한 액세스를 관리할 수 있다.
- 권한 셋을 사용하여 사용자를 그룹에 할당하는 하나 이상의 IAM 정책을 정의한다.
- 예를 들면 다음과 같이 설정할 수 있다.
  - 데이터베이스 관리자를 위한 권한 셋에 Dev 계정의 RDS 또는 Aurora, Prod 계정의 RDS 또는 Aurora에 액세스할 수 있다고 정의한다.
  - 사용자에 대해 IAM 역할이 자동으로 생성된다.
  - 데이터베이스 관리자가 IAM 자격 증명 센터를 통해 로그인해서 Dev 계정 또는 Prod 계정의 콘솔에 액세스할 때 해당 계정에서 IAM 역할을 자동으로 위임한다.
애플리케이션 할당
- 어떤 사용자 또는 그룹이 어떤 애플리케이션에 액세스할 수 있는지 정의할 수 있다.
- 필요한 URL, 인증서, 메타데이터가 제공된다.
속성 기반 액세스 제어(Attribute-Based Access Control)
- IAM 자격 증명 센터 스토어에 저장된 사용자 속성을 기반으로 세분화된 권한을 갖도록 한다.
- 사용자를 cost center에 할당하거나, 주니어/시니어 같은 직함을 주거나, 로케일을 줘서 특정 리전에만 액세스하도록 할 수 있다.
- IAM 권한 셋을 한 번만 정의하고 이 속성을 활용하여 사용자 또는 그룹의 AWS 액세스만 수정할 수 있다.

AWS Directory

Microsoft AD
- Microsoft AD는 Active Dirctory 도메인 서비스를 사용하는 모든 Windows 서버에 사용되는 소프트웨어이다.
- 객체를 담는 데이터베이스이며 사용자 계정, 컴퓨터, 프린터, 파일 공유, 보안 그룹이 객체가 될 수 있다.
- Microsoft 생태계에서 관리되는 온프레미스의 모든 사용자는 Microsoft Active Directory의 관리 대상이 된다.
- 중앙 집중식 보안 관리로 계정 생성, 권한 할당 등의 작업이 가능하다.
- 모든 객체는 트리로 구성되며 트리의 그룹을 포리스트라고 한다.
- 모든 머신은 도메인 컨트롤러에 연결되어 있으므로 사용자는 어떤 단일 머신에서도 액세스할 수 있다.
AWS Directory 서비스
- AWS에 AD를 생성하는 서비스
AWS 관리형 Microsoft AD
- AWS에 자체 액티브 디렉터리를 생성하고 로컬에서 관리할 수 있으며 멀티팩터 인증을 지원한다.
- 독립 실행형 Active Directory로 온프레미스 AD와 신뢰 관계를 구축할 수 있다.
- AWS 관리형 AD의 인증된 사용자가 온프레미스 AD에서 계정을 검색할 수 있고, 반대로 온프레미스 AD 사용자가 AWS 계정을 사용해 온프레미스 AD에서 인증하려 할 때도 신뢰 관계에 의거해 AWS AD에서 검색할 수 있다.
- 온프레미스와 AWS 액티브 디렉터리 간에 사용자가 공유되는 개념이다.
AD 커넥터
- 프록시로 온프레미스 AD에 리다이렉트하며 MFA를 지원한다.
- 사용자는 온프레미스 AD에서만 관리된다.
- 예를 들어 사용자가 AD 커넥터를 사용해 인증하려고 하면, 커넥터는 온프레미스 AD에 요청을 프록시하기만 한다.
Simple AD
- 온프레미스가 없을 때 사용하는 독립 실행형 AD
- AWS의 AD 호환 관리형 디렉터리
- AWS 클라우드에 액티브 디렉터리가 필요한 경우 독립형인 Simple AD 서비스를 사용한다.
- 예를 들어 Windows를 실행할 EC2 인스턴스를 생성하고 네트워크용 도메인 컨트롤러와 결합되어 모든 로그인 정보와 자격 증명 등을 공유할 수 있다.
IAM Identity Center와 AD 통합
- Directory 서비스를 통해 AWS 관리형 AD 연결할 경우 IAM Identity Center를 AWS 관리형 Microsoft AD에 통합하고 연결하도록 설정만 하면 된다.
- 온프레미스에 자체 관리형 AD가 있는 경우 두 방법을 사용해 통합할 수 있다.
  - 온프레미스 AD와 AWS 관리형 Microsoft AD 간에 양방향 신뢰 관계를 구축한다. 이후 IAM Identity Center에서 싱글 사인온으로 간단히 통합한다.
  - AD 커넥터를 활용하여 IAM Identity Center와 연결하고 모든 요청을 자체 디렉터리로 프록시한다.

Control Tower

안전하고 규정을 준수하는 다중 계정 AWS 환경을 손쉽게 설정하고 관리할 수 있다.
다중 계정을 생성하기 위해 AWS Organization 서비스를 사용해 계정을 자동 생성한다.
보안과 규정 준수 방법
장점
- 간단하게 환경을 자동으로 설정할 수 있고, 원하는 모든 것을 미리 구성이 가능하다.
- 가드레일을 사용해 자동으로 지속적인 정책 관리를 할 수 있다.
- 정책 위반을 감지하고 자동으로 교정할 수 있다.
- 대시보드를 통해 모든 계정의 전반적인 규정 준수를 모니터링한다.
가드레일
- AWS에서 다중 계정을 설정할 때 특정 항목에 관해 한 번에 모두 제한하거나, 특정 유형의 규정 준수 사항을 모니터링할 수 있다.
- Control Tower 환경 내의 모든 계정에 관한 거버넌스를 얻을 수 있다.
- 예방(Preventive) 가드레일
  - 계정을 무언가로부터 보호하기 위해 사용되며, AWS Organization 서비스의 서비스 제한 정책인 SCP를 사용해 모든 계정에 적용한다.
  - 예를 들어 모든 계정에 대해 us-east-1과 eu-west-2의 리전에서만 작업하도록 할 수 있다.
- 탐지(Detective) 가드레일
  - AWS Config 서비스를 사용해 규정을 준수하지 않는 사항을 탐지한다.
  - 규정을 준수하지 않으면 SNS로 트리거해 알림을 받거나 SNS를 통해 Lambda 함수를 실행해 Lambda 함수가 자동으로 문제를 해결하도록 할 수 있다.
  - 예를 들어 계정에서 태그가 지정되지 않은 리소스가 있는지 식별하기 위해 Control Tower로 탐지 가드레일을 설정하면 모든 멤버 계정에 Config가 배포되어 규칙과 태그가 지정되지 않은 리소스를 모니터링하게 된다.

PreviousAWS Console / CLI / SDK NextEC2

Last updated 28 days ago

조직

AWS 조직은 글로벌 서비스이며, 여러 AWS 계정을 동시에 관리할 수 있게 해준다.
관리 계정은 조직 내의 주요 계정을 의미하고, 멤버 계정은 조직에 가입하거나 조직에서 생성된 계정들을 의미한다.
멤버 계정은 하나의 조직에만 속할 수 있다.
관리 계정에 하나의 결제 방법을 설정하면 조직의 모든 비용을 지불할 수 있다.
조직 내부의 사용량이 통합되어 집계되므로 가격 혜택을 받을 수 있다. 예를 들어 예약 인스턴스와 절약 계획 할인을 계정 간에 공유하며 한 계정에서 예약 인스턴스가 사용되지 않으면 다른 계정이 그 혜택을 받을 수 있고 할인 역시 전체 조직에 적용된다.
조직 내에서 계정 생성을 자동화할 수 있는 API를 제공하므로 계정을 쉽게 생성할 수 있다.
OU
- 루트 조직 단위
- 계층을 갖도록 생성 가능하다.
장점
- 계정이 분리되어 있는 형태이므로 하나의 계정에 여러 VPC를 두는 것보다 더 나은 보안을 제공한다.
- 청구 목적을 위한 태그 표준을 강제할 수 있다.
- 한 번에 모든 계정에 대해 CloudTrail을 활성화하여 모든 로그를 중앙 S3 계정으로 보낼 수 있다.
- CloudWatch 로그를 중앙 로깅 계정으로 보낼 수 있다.
- 관리 목적으로 Cross Account Roles을 설정해 관리 계정에서 모든 멤버 계정을 관리할 수 있다.
서비스 제어 정책
- SCP (Service Control Policy)
- 특정 OU나 계정에 적용되는 IAM 정책
- 사용자와 역할이 계정 내에서 할 수 있는 작업을 제한할 수 있다.
- 관리 계정에는 적용되지 않는다. 관리 계정은 항상 전체 관리자 권한을 가진다.
- 루트를 포함한 각 사용자가 특정 작업을 허용하기 위해 명시적인 허용을 가지고 있는지 확인해야 한다.
- SCP 계층 구조는 다음과 같다.
  - 전체 AWS 액세스를 루트에 지정한다. 관리 계정은 루트 OU 아래에 있다.
  - 관리 계정에 Athena를 거부하는 SCP를 적용하더라도 관리 계정에는 영향이 없다.
  - 각 OU에 명시적 허용을 위한 전체 AWS 액세스를 적용하고, 거부 정책을 적용한다. 전체 AWS 액세스를 적용하지 않으면 아무 것에도 접근하지 못할 것이다.
  - 각 계정마다도 정책을 적용할 수 있다.
특정 서비스를 차단하려면 모든 작업을 허용한 다음 거부 정책을 추가하면 된다.
특정 서비스만 허용하도록 정책을 추가할 수도 있다.

IAM 권한

유저와 그룹

유저
- AWS 계정 설정하는 경우 외에는 루트 계정 대신 IAM 계정을 만들어 사용해야 한다.
- 사용자를 그룹에 할당하여 그룹 별로 권한을 할당할 수 있다.
- 다양한 권한 종류가 존재한다.
그룹
정책
- JSON 기반으로 설정할 수 있다.

방어 매커니즘

비밀번호 정책 정의
- IAM 콘솔에서 최소 비밀번호 길이, 포함해야 할 문자 타입, 만료 시간, 이전 비밀번호 재사용 금지 등의 정책을 설정할 수 있다.
MFA (Multi Factor Authentication)
- 다중 인증 (n단계 인증)
- 관리자인 경우 많은 작업을 사용할 수 있다.
- 비밀번호를 도난당하여도 등록된 물리적 장비가 있어야 로그인 가능하게 된다.
- 다음 장치들을 사용할 수 있다.
  - Virtual MFA device (Duo Mobile, Google Authenticator, Authy 등 애플리케이션)
  - YubiKey (단일 보안키를 사용해 여러 루트 및 IAM 사용자를 지원한다.)
  - Hardware Key Fob MFA Device (장치로부터 TOTP 토큰을 생성해 사용한다.)

IAM 역할

AWS 서비스에게 할당하는 권한을 IAM 역할으로 관리한다. 이 경우에는 실제 사용자가 사용하지 않는다.
AWS에서 정보를 조회하기 위해 IAM 역할으로 접근 권한을 부여해야 한다.
IAM 사용자 또는 AWS 서비스는 AWS API 호출을 하는 데 사용할 수 있는 임시 보안 자격 증명을 얻기 위해 역할을 부여받을 수 있다. 이를 통해 리소스에 액세스하기 위한 장기적인 자격 증명을 공유하지 않아도 된다. IAM 역할을 이용하면 다른 계정의 리소스에 액세스할 수 있다.

Resource-base Policy와의 차이점

서로 다른 계정 간 호출을 위해 리소스에 리소스 기반 정책을 부여하거나 리소스에 실제로 접근할 수 있는 IAM 역할을 사용할 수 있다.
역할을 부여받으면 모든 원래의 권한을 포기하고 그 역할에 할당된 모든 권한을 받는다. 하지만 원래의 권한은 사용할 수 없다.
리소스 기반 정책을 사용할 때는 주체가 역할을 맡지 않으므로 자신의 권한을 포기할 필요가 없다.
예를 들어, 계정 A가 계정 A의 DynamoDB 테이블을 스캔하고, 이를 계정 B의 S3 버킷에 덤프해야 한다면 리소스 기반 정책을 사용하여 다른 계정의 S3 버킷에 DynamoDB 테이블을 스캔하고 쓸 수 있다.
Amazon S3 버킷, SNS, SQS, Lambda 함수 등 점점 더 많은 AWS 서비스와 리소스가 리소스 기반 정책을 지원하고 있다.
Amazon EventBridge를 사용할 때 대상에 대한 권한이 필요한데, 대상이 리소스 기반 정책을 지원한다면 EventBridge가 대상에 리소스 기반 정책을 추가하여 EventBridge 규칙에서의 호출을 허용할 수 있다. 대상이 리소스 정책을 지원하지 않는다면 EventBridge는 IAM 역할을 사용하여 대상 서비스를 호출한다.
- Kinesis Stream, EC2 Auto Scaling, System Manager Run Command, ECS 작업 등은 아직 리소스 기반 정책을 지원하지 않는다.
IAM 역할을 이용하면 일반적으로 여러분 조직의 AWS 리소스에 액세스할 수 없는 사용자나 서비스에게 액세스 권한을 위임할 수 있다.

IAM Security Tools

IAM Credentials Report (자격 증명 보고서)
- 계정에 있는 사용자와 다양한 자격 증명 상태를 포함한다.
Access Advisor (액세스 관리자)
- 사용자에게 부여된 서비스 권한과 서비스에 마지막으로 접근한 시간을 알려준다.
- 어떤 권한이 사용되지 않는지 확인하여 최소 권한 원칙을 지킬 수 있다.

IAM 조건

IAM 내부의 정책에 적용되며 사용자 정책이거나 리소스 정책, 엔드포인트 정책 등이 될 수 있다.
아래 조건들을 비롯한 다양한 조건들이 존재한다.
aws:SourceIp
- API 호출이 생성되는 클라이언트 IP를 제한하는 데 사용되는 조건이다.
- 특정 IP 주소 범위에 포함되지 않는 IP 주소에 대해 모든 작업과 리소스를 거부(Deny)한다.
- 이를 통해 회사 네트워크에서만 AWS를 사용하도록 제한하여 회사 내에서만 AWS 환경에 액세스할 수 있게 설정할 수 있다.
aws:RequestedRegion
- API 호출 리전을 제한하는 글로벌 조건이다.
- 특정 리전에서 특정 서비스에 대한 액세스를 거부한다.
ec2:ResourceTag
- EC2 인스턴스의 태그가 매칭될 때 특정 작업을 수행하도록 할 수 있다.
- 예를 들어 ResourceTag/Project가 DataAnalytics일 때 모든 인스턴스의 시작과 종료를 허용할 수 있다.
aws:PrincipleTag
- 사용자 태그가 매칭될 때 AWS의 특정 작업을 수행하도록 한다.
aws:MultiFactorAuthPresent
- 멀티팩터 인증을 강제하는 조건이다.
- 예를 들어 사용자가 멀티팩터 인증을 거쳐야만 EC2에서 작업이 가능하도록 할 수 있다.
aws:PrincipalOrgPaths
- 요청자가 AWS Organizations의 지정된 조직 루트 또는 조직 단위(OU) 내의 계정 멤버인지 확인한다.
S3 IAM 정책
- 버킷 수준 정책과 객체 수준 정책을 설정할 수 있다.
- 버킷 수준의 권한은 버킷을 특정해야 한다.
- 객체 수준의 권한은 객체에 대한 허용 범위(GetObject, PutObject DeleteObject 등)와 객체를 특정해야 한다. /*을 명시해 버킷 내의 모든 객체를 나타낼 수 있다.

리소스 정책
- aws:PrincipalOrgID 조건은 AWS 조직에 속한 멤버 계정에만 리소스 정책이 적용되도록 제한할 수 있다.
- 조직 외부의 사용자는 정책에 의해 액세스가 거부된다.

Permission Boundaries

IAM의 최대 권한을 정의할 수 있다.
권한 경계(Permissions boundary)는 사용자와 역할만 지원하고 그룹은 지원하지 않는다.
IAM 권한 경계를 작성하여 IAM 사용자에 연결하면 권한 경계를 설정할 수 있다.
IAM 권한 경계 밖에 있는 IAM 정책은 유효하지 않게 된다.
예를 들어 IAM 권한 경계에서 AmazonS3FullAccess만을 지정하면, 사용자에게 AdministratorAcess가 있어도 권한 경계인 S3 내부에만 액세스할 수 있다.
다음 그림과 같이 사용자나 그룹에 부여된 자격 증명 기반 정책과 그룹이 아닌 사용자나 역할에만 적용되는 권한 경계와 Organizations SCP에 모두 해당되는 권한만 사용자에게 주어진다.

사용 목적
- 관리자가 아닌 사용자에 권한 경계 내에서 새 IAM 사용자를 생성하는 등의 책임을 위임하기 위해 사용된다.
- 개발자가 권한을 스스로 부여하고 관리하는데 특권을 남용하는 것을 막기 위해 스스로를 관리자로 만들지 못하게 할 수 있다.
- 계정에 SCP를 적용하여 계정의 모든 사용자를 제한하지 않고 AWS Organizations의 특정 사용자만 제한할 수도 있다.
IAM 정책 평가 논리
- 전체 흐름 중에 각 단계마다 평가가 이루어지며 명시적인 거부가 있다면 자동으로 거부된다.
- 모든 단계에서 허용됐을 때만 최종적으로 작업을 진행할 수 있다.
예를 들어 IAM 정책은 다음과 같이 동작한다.
- sqs:*에 Deny가 명시되어 있기 때문에 sqs:* 안에 있는 sqs:DeleteQueue는 Allow가 있음에도 자동으로 거부된다.
- 명시적 허용이 없기 때문에 ec2:DescribeInstances를 실행할 수 없다.

IAM Identity Center

이전에 AWS 싱글 사인온 서비스라고 불리던 것과 동일한 제품이다.
AWS 조직이나 비즈니스 클라우드 애플리케이션의 모든 AWS 계정에서 한 번만 로그인하면 된다.
Identity Center를 Salesforce, Box, Microsoft 365 등 비즈니스 클라우드 애플리케이션, SAML2.0 통합이 가능한 애플리케이션, EC2 Windows 인스턴스와 통합하면 싱글 로그인 기능을 이용할 수 있다.

시험에서는 아마 여러 AWS 계정을 한 번에 로그인하는 것에 대해 나올 겁니다

Identity Providers
- 사용자는 IAM 자격 증명 센터에 내장된 ID 저장소나, 서드파티 ID 공급자에 저장될 수 있다.
- IAM과 유사하게 사용자나 그룹을 정의할 수 있다.
- 서드 파티 ID 공급자는 Active Directory(AD), OneLogin, Okta 등일 수 있다.
자격 증명 센터에 로그인하고 원하는 계정을 클릭하여 바로 원하는 서비스로 연결할 수 있다.
여러 개의 AWS 계정을 가지고 있다면 이 서비스를 사용하면 편리하다.
자격 증명 센터에서 권한 셋을 정의해서 사용자마다 액세스 권한을 정의해야 한다.
- 예를 들어 한 AWS 조직이 있으면 관리 계정에 IAM 자격 증명 센터를 설정한다.
- 그리고 여러 OU가 있고 OU 내부에 여러 계정이 있는 상황에서 Bob과 Alice가 개발 OU의 모든 계정에 대해 액세스 권한을 갖게 하려면, 권한 셋을 개발 OU와 연결하고 Identity Center의 그룹에 할당하면 된다.
다중 계정 권한
- AWS 조직에서 여러 계정에 대한 액세스를 관리할 수 있다.
- 권한 셋을 사용하여 사용자를 그룹에 할당하는 하나 이상의 IAM 정책을 정의한다.
- 예를 들면 다음과 같이 설정할 수 있다.
  - 데이터베이스 관리자를 위한 권한 셋에 Dev 계정의 RDS 또는 Aurora, Prod 계정의 RDS 또는 Aurora에 액세스할 수 있다고 정의한다.
  - 사용자에 대해 IAM 역할이 자동으로 생성된다.
  - 데이터베이스 관리자가 IAM 자격 증명 센터를 통해 로그인해서 Dev 계정 또는 Prod 계정의 콘솔에 액세스할 때 해당 계정에서 IAM 역할을 자동으로 위임한다.
애플리케이션 할당
- 어떤 사용자 또는 그룹이 어떤 애플리케이션에 액세스할 수 있는지 정의할 수 있다.
- 필요한 URL, 인증서, 메타데이터가 제공된다.
속성 기반 액세스 제어(Attribute-Based Access Control)
- IAM 자격 증명 센터 스토어에 저장된 사용자 속성을 기반으로 세분화된 권한을 갖도록 한다.
- 사용자를 cost center에 할당하거나, 주니어/시니어 같은 직함을 주거나, 로케일을 줘서 특정 리전에만 액세스하도록 할 수 있다.
- IAM 권한 셋을 한 번만 정의하고 이 속성을 활용하여 사용자 또는 그룹의 AWS 액세스만 수정할 수 있다.

AWS Directory

Microsoft AD
- Microsoft AD는 Active Dirctory 도메인 서비스를 사용하는 모든 Windows 서버에 사용되는 소프트웨어이다.
- 객체를 담는 데이터베이스이며 사용자 계정, 컴퓨터, 프린터, 파일 공유, 보안 그룹이 객체가 될 수 있다.
- Microsoft 생태계에서 관리되는 온프레미스의 모든 사용자는 Microsoft Active Directory의 관리 대상이 된다.
- 중앙 집중식 보안 관리로 계정 생성, 권한 할당 등의 작업이 가능하다.
- 모든 객체는 트리로 구성되며 트리의 그룹을 포리스트라고 한다.
- 모든 머신은 도메인 컨트롤러에 연결되어 있으므로 사용자는 어떤 단일 머신에서도 액세스할 수 있다.
AWS Directory 서비스
- AWS에 AD를 생성하는 서비스
AWS 관리형 Microsoft AD
- AWS에 자체 액티브 디렉터리를 생성하고 로컬에서 관리할 수 있으며 멀티팩터 인증을 지원한다.
- 독립 실행형 Active Directory로 온프레미스 AD와 신뢰 관계를 구축할 수 있다.
- AWS 관리형 AD의 인증된 사용자가 온프레미스 AD에서 계정을 검색할 수 있고, 반대로 온프레미스 AD 사용자가 AWS 계정을 사용해 온프레미스 AD에서 인증하려 할 때도 신뢰 관계에 의거해 AWS AD에서 검색할 수 있다.
- 온프레미스와 AWS 액티브 디렉터리 간에 사용자가 공유되는 개념이다.
AD 커넥터
- 프록시로 온프레미스 AD에 리다이렉트하며 MFA를 지원한다.
- 사용자는 온프레미스 AD에서만 관리된다.
- 예를 들어 사용자가 AD 커넥터를 사용해 인증하려고 하면, 커넥터는 온프레미스 AD에 요청을 프록시하기만 한다.
Simple AD
- 온프레미스가 없을 때 사용하는 독립 실행형 AD
- AWS의 AD 호환 관리형 디렉터리
- AWS 클라우드에 액티브 디렉터리가 필요한 경우 독립형인 Simple AD 서비스를 사용한다.
- 예를 들어 Windows를 실행할 EC2 인스턴스를 생성하고 네트워크용 도메인 컨트롤러와 결합되어 모든 로그인 정보와 자격 증명 등을 공유할 수 있다.
IAM Identity Center와 AD 통합
- Directory 서비스를 통해 AWS 관리형 AD 연결할 경우 IAM Identity Center를 AWS 관리형 Microsoft AD에 통합하고 연결하도록 설정만 하면 된다.
- 온프레미스에 자체 관리형 AD가 있는 경우 두 방법을 사용해 통합할 수 있다.
  - 온프레미스 AD와 AWS 관리형 Microsoft AD 간에 양방향 신뢰 관계를 구축한다. 이후 IAM Identity Center에서 싱글 사인온으로 간단히 통합한다.
  - AD 커넥터를 활용하여 IAM Identity Center와 연결하고 모든 요청을 자체 디렉터리로 프록시한다.

Control Tower

안전하고 규정을 준수하는 다중 계정 AWS 환경을 손쉽게 설정하고 관리할 수 있다.
다중 계정을 생성하기 위해 AWS Organization 서비스를 사용해 계정을 자동 생성한다.
보안과 규정 준수 방법
장점
- 간단하게 환경을 자동으로 설정할 수 있고, 원하는 모든 것을 미리 구성이 가능하다.
- 가드레일을 사용해 자동으로 지속적인 정책 관리를 할 수 있다.
- 정책 위반을 감지하고 자동으로 교정할 수 있다.
- 대시보드를 통해 모든 계정의 전반적인 규정 준수를 모니터링한다.
가드레일
- AWS에서 다중 계정을 설정할 때 특정 항목에 관해 한 번에 모두 제한하거나, 특정 유형의 규정 준수 사항을 모니터링할 수 있다.
- Control Tower 환경 내의 모든 계정에 관한 거버넌스를 얻을 수 있다.
- 예방(Preventive) 가드레일
  - 계정을 무언가로부터 보호하기 위해 사용되며, AWS Organization 서비스의 서비스 제한 정책인 SCP를 사용해 모든 계정에 적용한다.
  - 예를 들어 모든 계정에 대해 us-east-1과 eu-west-2의 리전에서만 작업하도록 할 수 있다.
- 탐지(Detective) 가드레일
  - AWS Config 서비스를 사용해 규정을 준수하지 않는 사항을 탐지한다.
  - 규정을 준수하지 않으면 SNS로 트리거해 알림을 받거나 SNS를 통해 Lambda 함수를 실행해 Lambda 함수가 자동으로 문제를 해결하도록 할 수 있다.
  - 예를 들어 계정에서 태그가 지정되지 않은 리소스가 있는지 식별하기 위해 Control Tower로 탐지 가드레일을 설정하면 모든 멤버 계정에 Config가 배포되어 규칙과 태그가 지정되지 않은 리소스를 모니터링하게 된다.