IAM 고급

조직 (Organizations)

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

장점

• 다수의 계정을 가지므로 다수의 VPC를 가진 단일 계정에 비해 보안이 뛰어나다. 계정이 VPC보다 독립적이기 때문
• 청구 목적의 태그 기준을 적용할 수 있고 한 번에 모든 계정에 대해 CloudTrail을 활성화해서 모든 로그를 중앙 S3 계정으로 전송할 수 있다.
• CloudWatch Logs를 중앙 로깅 계정으로 전송 가능
• 자동으로 관리 목적의 계정 간 역할을 수립할 수 있어 관리 계정에서 모든 멤버 계정을 관리할 수 있다.
• 보안 측면에서도 큰 장점이 있다,.바로  서비스 제어 정책, 즉 SCP(Service Policies)를 정의할 수 있다.

SCP

• 특정 OU 또는 계정에 적용되는 IAM 정책으로 해당 사용자와 역할 모두가 계정 내에서 할 수 있는 일을 제한한다.
• SCP는 모든 대상에 적용되나 영구적인 관리자 권한을 갖는 관리 계정에는 적용되지 않는다.
• 실수가 발생했을 때 누군가는 복구를 해야 하므로
• SCP는 기본적으로 아무것도 허용하지 않는다. IAM처럼
• 구체적인 허용 항목을 설정해야 작동한다.
• SCP에는 '차단 목록'과 '허용 목록' 두 가지 전략이 있다.
• 차단 목록은 계정이 사용하지 못하게 할 서비스를 지정
• Allow, *(별표)로 모든 서비스의 모든 작업을 허용한 다음 Deny 문을 추가해 DynamoDB에 대한 액세스를 거부하는 식
• 허용 목록은 모든 액션을 허용하지 않고 가령 EC2와 CloudWatch만 허용하는 방식
• 해당 SCP가 적용된 계정에서는 EC2와 CloudWatch만이 허용되며 다른 서비스는 사용할 수 없고 사용하려면 명시적 허용이 필요하다.

IAM 고급

IAM 조건

• IAM 조건은 IAM 내부의 정책에 적용되며 사용자 정책일 수도 있고 리소스 정책일 수도 있고 엔드포인트 정책 등 어떤 정책도 될 수 있다.
• aws:SourceIp
  • API 호출이 생성되는 클라이언트 IP를 제한하는 데 사용되는 조건
  • 회사 네트워크에서만 AWS를 사용하도록 제한하여 회사 내에서만 AWS 환경에 액세스할 수 있게 설정할 수 있다
• aws:RequestedRegion
  • AWS로 시작하므로 글로벌 조건이며 API 호출 리전을 제한한다
  • 예시에서는 eu-central-1와 eu-west-1 리전에서 오는 EC2, RDS, DynamoDB 호출을 제한
  • 특정 리전에서 특정 서비스에 대한 액세스를 거부하는 것
  • 이 조건을 조직 SCP에 보다 글로벌하게 적용해서 특정 리전의 액세스를 허용하거나 거부할 수 있다.
• ec2:ResourceTag
  • 이 조건은 EC2 인스턴스의 태그에 적용된다.
  • 태그를 가지고 제한하는 방법이다.
• aws:PrincipleTag
  • 사용자 태그에 적용된다.
• aws:MultiFactorAuthPresent
  • 멀티팩터 인증을 강제하는 조건
• aws:PrincipalOrgID
  • 해당 조건은 AWS 조직의 멤버 계정에만 리소스 정책이 적용되도록 제한한다

IAM for S3

• 2개의 선언문이 있다.
• 첫 번째는 목록 버킷이고 s3:::test라는 ARN(Amazon Resource Number)에 적용된다.
• 버킷 수준의 권한이므로 버킷을 특정해야 한다.
• GetObject, PutObject DeleteObject는 버킷 내의 객체에 적용되므로 ARN이 달라진다.
• 버킷 내의 모든 객체를 나타내는 /*이 들어간다.
• 객체 수준 권한이기 때문에 ARN이 달라진 것

IAM Roles vs Resource Base Policies

• 역할을 맡으면 기존의 권한을 모두 포기하고 해당 역할에 할당된 권한을 상속하게 된다.
• 어떤 작업을 수행하는 역할을 맡게 되면 해당 역할에 부여된 작업은 할 수 있지만 기존의 권한은 사용할 수 없습니다
• 대신 리소스 기반 정책을 사용하면 본인이 역할을 맡지 않으므로 권한을 포기할 필요가 없다.
• 예를 들어 계정 A의 사용자가 본인 계정의 DynamoDB 테이블을 스캔해 계정 B의 S3 버킷에 넣을 경우에는 리소스 기반 정책을 사용하는 것이 좋다. 역할을 맡을 필요가 없으므로 DynamoDB 테이블을 스캔하고 다른 계정의 S3 버킷에 쓰기 작업도 할 수 있기 때문
• 리소스 기반 정책을 지원하는 AWS 서비스와 리소스가 점점 늘어나고 있다
• 리소스 기반 정책을 지원하는 대상에는 Lambda, SNS, SQS CloudWatch Logs API Gateway 등이 있다.
• Kinesis Data Streams, Systems Manager Run Command, ECS 태스크를 시작할 때는 IAM 역할이 필요하다.
• SNS, SQS, Lambda에는 리소스 기반 정책을 사용하고 Kinesis Data Streams에는 IAM 역할을 사용 (중요)

권한 경계

• 권한 경계(Permissions boundary)는 사용자와 역할만 지원하고 그룹은 지원하지 않는다.
• IAM 개체의 최대 권한을 정의하는 고급 기능
• IAM 권한 경계는 AWS Organizations SCP와 함께 사용될 수 있어요

사용 

• 관리자가 아닌 사용자에 책임을 위임하기 위해 권한 경계 내에서 새 IAM 사용자를 생성할 때 사용
• 개발자가 권한을 스스로 부여하고 관리하는데 특권을 남용하는 것을 막기 위해 스스로를 관리자로 만들지 못하게 할 수 있다.
• 또 계정에 SCP를 적용해서 계정의 모든 사용자를 제한하지 않고 AWS Organizations의 특정 사용자만 제한할 수도 있다.

정책 평가 로직

Amazon Cognito

• Cognito는 사용자에게 웹 및 모바일 앱과 상호 작용할 수 있는 자격 증명을 부여한다.
• 일반적으로 이 사용자들은 AWS 계정 외부에 있다.
• Cognito에는 두 종류의 하위 서비스가 있다.
• 앱 사용자에게 가입 기능을 제공하는 Cognito 사용자 풀이 있다.
• API Gateway 및 애플리케이션 로드 밸런서와 원활히 통합된다.
• 다음은 페더레이션 자격 증명이라고 불리던 Cognito 자격 증명 풀이 있는데 이는 앱에 등록된 사용자에게 임시 AWS 자격 증명을 제공해서 일부 AWS 리소스에 직접 액세스할 수 있도록 해 주고 Cognito 사용자 풀과 원활히 통합된다.
• 웹이나 모바일 애플리케이션의 사용자 기반을 생성할 수 있고 세분화된 액세스 제어를 위해 DynamoDB에서 행 수준 보안을 활성화할 수 있다.

Cognito 사용자 풀

• 웹 및 모바일 앱을 대상으로 하는 서버리스 사용자 데이터베이스
• 사용자 이름 또는 이메일, 비밀번호의 조합으로 간단한 로그인 절차를 정의할 수 있다.
• 비밀번호 재설정 기능이 있고 이메일 및 전화번호 검증 및 사용자 멀티팩터 인증이 가능하다.
• 또한 Facebook이나 Google과 통합할 수 있어 소셜 로그인도 가능하다.
• Cognito 사용자 풀은 API Gateway나 애플리케이션 로드 밸런서와 통합된다.

Cognito 자격 증명 풀

• 페더레이션 자격 증명이라고도 한다.
• 사용자에게 자격 증명을 제공하지만 API Gateway나 애플리케이션 로드 밸런서를 통해서 애플리케이션에 액세스하지 않고 임시 AWS 자격 증명을 사용해 AWS 계정에 직접 액세스한다.
• 사용자는 Cognito 사용자 풀 내의 사용자가 될 수도 있고 타사 로그인이 될 수도 있다.
• 직접 또는 API Gateway를 통해 서비스에 액세스할 수도 있다.
• 자격 증명에 적용되는 IAM 정책은 Cognito 자격 증명 풀 서비스에 사전 정의되어 있다.
• user_id를 기반으로 사용자 정의하여 세분화된 제어를 할 수도 있다.
• 원한다면 기본 IAM 역할을 정의할 수도 있다.
• 게스트 사용자나 특정 역할이 정의되지 않은 인증된 사용자는 기본 IAM 역할을 상속하게 된다.

IAM Identity Center

• AWS 싱글 사인온 서비스의 후속 서비스
• 한 번만 로그인 하면 되므로 Single Sign On 이라고 부른다.
• AWS 조직이나 비즈니스 클라우드 애플리케이션의 모든 AWS 계정에서 싱글 사인온을 할 수 있다.
• 즉, Salesforce, Box, Microsoft 365 등에 연결할 수 있다. SAML2.0 통합이 가능한 어떤 애플리케이션에라도 연결할 수 있다.
• 마지막으로 EC2 Windows 인스턴스에 대해서도 싱글 로그인을 제공한다.
• IAM 자격 증명 센터에 내장된 ID 저장소나, 서드파티 ID 공급자에 연결할 수 있다. Active Directory(AD), OneLogin, Okta 등
• 여러 개의 AWS 계정을 가지고 있다면 이 서비스를 사용하는 것을 추천

세분화된 권한 및 할당

• 다중 계정 권한
  • 이 서비스를 사용하면 여러분의 조직에서 여러 계정에 대한 액세스를 관리할 수 있다.
  • 또한 권한 셋을 사용하여 사용자를 그룹에 할당하는 하나 이상의 IAM 정책을 정의한다.
  • AWS에서 사용자가 무엇에 액세스할 수 있는지 정의하기 위함
• 애플리케이션 할당
  • 어떤 사용자 또는 그룹이 어떤 애플리케이션에 액세스할 수 있는지 정의할 수 있다.
  • 그러면 필요한 URL, 인증서, 메타데이터가 제공된다.
• 속성 기반 액세스 제어
  • IAM 자격 증명 센터 스토어에 저장된 사용자 속성을 기반으로 세분화된 권한을 갖게 되는 것. 태그와 유사
  • 이를 사용하여 사용자를 비용 센터에 할당하거나, 주니어나 시니어와 같은 직함을 주거나 로케일을 줘서 특정 리전에만 액세스하도록 할 수 있다.
  • 사용 사례는 IAM 권한 셋을 한 번만 정의하고 이 속성을 활용하여 사용자 또는 그룹의 AWS 액세스만 수정하는 것

AWS Directory Service

• Microsoft AD는 AD 도메인 서비스를 사용하는 모든 Windows 서버에 사용되는 소프트웨어
• 객체의 데이터베이스이며 사용자 계정, 컴퓨터 프린터, 파일 공유, 보안 그룹이 객체가 될 수 있다.
• 전체 Microsoft 생태계에서 관리되는 온프레미스의 모든 사용자는 Microsoft Active Directory의 관리 대상이 된다.
• 또한 중앙 집중식 보안 관리로 계정 생성, 권한 할당 등의 작업이 가능하다.
• 모든 객체는 트리로 구성되며 트리의 그룹을 포리스트라고 한다.

AWS Directory 서비스

• AWS에 액티브 디렉터리를 생성하는 서비스로 세 가지 서비스가 있다.
• AWS 관리형 Microsoft AD
  • AWS에 자체 액티브 디렉터리를 생성하고 로컬에서 관리할 수 있으며 멀티팩터 인증을 지원한다.
  • 독립 실행형 Active Directory로 사용자가 있는 온프레미스 AD와 신뢰 관계를 구축할 수 있다.
  • AWS 관리형 AD가 온프레미스 AD와 상호 신뢰 관계를 구축하게 되는 것
  • AWS 관리형 AD의 인증된 사용자가 AWS 관리형이 아닌 계정을 사용할 때 온프레미스 AD에서 계정을 검색할 수 있고 반대로 온프레미스 AD 사용자가 AWS 계정을 사용해 온프레미스 AD에서 인증하려 할 때도 신뢰 관계에 의거해 AWS AD에서 검색할 수 있다.
  • 온프레미스와 AWS 액티브 디렉터리 간에 사용자가 공유되는 셈
• AD 커넥터
  • 디렉터리 게이트웨이, 다시 말해 프록시로 온프레미스 AD에 리다이렉트하며 MFA, 즉 멀티팩터 인증을 지원한다.
  • 사용자는 온프레미스 AD에서만 관리된다
• Simple AD
  
  • AWS의 AD 호환 관리형 디렉터리로 Microsoft 디렉터리를 사용하지 않으며 온프레미스 AD와도 결합되지 않는다.
  • 온프레미스 AD가 없으나 AWS 클라우드에 액티브 디렉터리가 필요한 경우 독립형인 Simple AD 서비스를 사용한다.
  • 액티브 디렉터리를 사용해 Windows를 실행할 EC2 인스턴스를 생성하고 이 Windows 인스턴스는 네트워크용 도메인 컨트롤러와 결합되어 모든 로그인 정보와 자격 증명 등을 공유
• 온프레미스에서 사용자를 프록시한다면 AD 커넥터가 필요
• AWS 클라우드에서 사용자를 관리하고 MFA를 사용해야 할 때는 AWS 관리형 AD가 필요
• 온프레미스가 없을 때는Simple AD를 선택

IAM Identity Center와 액티브 디렉터리

• IAM Identity Center를 AWS 관리형 Microsoft AD에 통합하고 연결하도록 설정하면 통합이 간단하다.
• 액티브 디렉터리를 클라우드에서 관리하지 않고 온프레미스에 자체 관리형 디렉터리가 있는 경우에는 어떻게 할까?
• 자체 관리형 디렉터리에 연결하는 방법은 두 가지다.
• 첫 번째 방법은 AWS 관리형 Microsoft AD를 사용해 양방향 신뢰 관계를 구축하는 것
  • Directory 서비스를 이용하여 관리형 Microsoft AD를 생성하고 온프레미스에 있는 AD와 관리형 AD 간에 양방향 신뢰 관계를 구축한 다음 IAM Identity Center에서 싱글 사인온으로 간단히 통합하면 된다.
• 다른 방법은 AD 커넥터를 활용하는 것입니다
  • AD 커넥터는 IAM Identity Center와 연결하는 역할을 하고 연결한 다음에는 자동으로 모든 요청을 자체 디렉터리로 프록시한다.
• 클라우드에 있는 액티브 디렉터리에서 사용자를 관리하고 싶다면 첫 번째 솔루션이 낫고 API 호출만 프록시하려면 두 번째 솔루션이 적합하다.

AWS Control Tower

• Control Tower 서비스를 사용하면 안전하고 규정을 준수하는 다중 계정 AWS 환경을 손쉽게 설정하고 관리할 수 있다.
• 다중 계정을 생성하기 위해 Control Tower 서비스는 AWS Organization 서비스를 사용해 계정을 자동 생성한다.
• Control Tower 서비스의 장점은 클릭 몇 번으로 환경을 자동으로 설정할 수 있고 원하는 모든 것을 미리 구성이 가능한 점이며 가드레일을 사용해 자동으로 지속적인 정책 관리를 할 수 있는 점이다.
• 정책 위반을 감지하고 자동으로 교정할 수 있으며 대화형 대시보드를 통해 모든 계정의 전반적인 규정 준수를 모니터링 한다.
• AWS Organization를 활용하는 또 다른 서비스

가드레일

• AWS에서 다중 계정을 설정한다고 생각해봤을 때  특정 항목에 관해 한 번에 모두 제한하거나 특정 유형의 규정 준수 사항을 모니터링하고자 한다.
• 이때 가드레일을 사용하면 Control Tower 환경 내의 모든 계정에 관한 거버넌스를 얻을 수 있다.
• 가드레일은 두 가지 유형이 있다.
• 첫 번째는 예방(Preventive) 가드레일이다.
  • 계정을 무언가로부터 보호하는 것이므로 제한적이기 때문에 AWS Organization 서비스의 서비스 제한 정책인 SCP를 사용해 모든 계정에 적용한다.
  • 예를 들어, 예방 가드레일을 생성해 모든 계정에서 리전을 제한하고 us-east-1과 eu-west-2의 리전에서만 작업하도록 할 수 있다.
  • Control Tower에서 Organization에 SCPs를 사용하도록 하는 것
• 두 번째 유형의 가드레일은 탐지(Detective) 가드레일이다.
  • 규정을 준수하지 않는 것을 탐지하는 것
  • 규정 준수에 대해 말씀드린 것처럼 AWS Config 서비스를 사용한다.
  • 가령, 계정에서 태그가 지정되지 않은 리소스를 식별한다고 하면 Control Tower로 탐지 가드레일을 설정하고 AWS Config를 사용하면 모든 멤버 계정에 Config가 배포되어 규칙과 태그가 지정되지 않은 리소스를 모니터링 하는데 규정을 준수하지 않으면 SNS 주제를 트리거 해서 관리자로서 알림을 받거나 SNS 주제도 Lambda 함수를 실행해 Lambda 함수가 자동으로 문제를 교정할 수 있다.