Identity and Access Management(IAM) - 고급

AWS Organizations

• 글로벌 서비스로 다수의 AWS 계정을 동시에 관리할 수 있게 해준다
• 조직을 생성하면 조직의 메인 계정이 관리계정
  • 조직에 가입한 계정 → 기타 계정
  • 조직에서 생성한 계정 → 멤버 계정(한 개의 조직에만 속할 수 있음)
• 모든 계정의 비용을 통합 결제가 가능하다
• 조직 내 모든 계정에 대해 집계된 사용량에 기반해 계산되므로 큰 할인을 받을 수 있다
• 계정간 예약 인스턴스와 Saving 플랜 할인이 공유
  • 어떤 계정에서 사용하지 않는 예약 인스턴스가 있으면 다른 계정이 사용 가능
  • 할인이 조직 전체에 걸쳐 적용됨

 

그룹 유닛 예시

비즈니스, 환경, 프로젝트 모두 그룹 단위로 짤라서 분리가 가능하다

 

장점

• 다수의 계정을 가지므로 다수의 VPC를 가진 단일 계정에 비해 보안이 뛰어난다
  • 계정이 VPC보다 독립적
• 청구 목적의 태그 기준을 적용할 수 있다
• 모든 계정에 대해 CloudTrail을 활성화해서 로그를 중앙 S3 계정으로 전송
• CloudWatch Logs를 중앙 로깅 계정으로 전송가능
• 자동으로 관리 목적의 계정 간 역할 수립 가능
  • 관리 계정에서 몯느 계정 관리 가능

Security: Service Control Policies(SCP)

• 특정 OU 또는 게정에 적용되는 IAM 정책
• 해당 사용자와 역할 모두가 계정에서 할 수 있는 일을 제한
• 모든 대상에 적용되지만 관리 계정에는 적용되지 않음
• 기본적으로 아무것도 설정되어 있지 않음

 

Management Account

• Athena 권한을 없앴지만 관리자 계정이라 적용안된다

계정 A

• 계정 A 상위 OU(prod)에 Redshift 거부 권한이 있어 Redshift 이용 불가
• 계정 A에는 Redshift 권한 허용이 있지만 정책에 명시적 거부가 하나라도 포함되면 액세스 거부
• Redshift외에 모든 역할 수행 가능

계정 B

• Redshift Lambda 엑세스 외 모든 일

계정C

• Redshift 엑세스 외 모두 가능

 

SCP Blocklist & Allowlist

계정이 사용하지 못할 서비스(Deny) → 모든 작업을 허용한 다음 특정 엑세스만 허용,

특정 작업만 허용하고 나머지는 사용 불가능

 

IAM Conditions

IAM 내부의 정책이 적용된다 → ex) s3 버킷에 대한 리소스 정책, 엔드포인트 관련 등

aws:SourceIp

• API 호출이 생성되는 클라이언트 IP를 제한하는데 사용되는 조건
• 모든 작업과 리소스를 거부하지만 조건이 있다
  • sourceIP를 제외하곤 모두 거부
  • 클라이언트가 특정 IP에서 호출하지 않으면 거부된다

 

aws:RequestedRegion

• 글로벌 조건으로 API 콜 리전을 제한
• 특정 리전에서 특정 서비스를 거부

 

ec2:ResourceTag

• 접두사가 ec2이기 때문에 ec2 인스턴스 태그에 적용된다
• 태그가 ResourceTag/Project가 DataAnalytics일 때 모든 인스턴스의 시작과 종료를 허용한다
• aws:PrincipleTag 사용자 태그에 적용된다

 

 

aws:MultiFactorAuthPresent

• 멀티팩터 인증을 강제
• ec2에서 모든 작업을 할 수 있지만 멀티패거 인증이 있어야 중지하고 종료가 가능하다

 

 

IAM for S3

• Action을 보면 버킷 수준과 객체 수준으로 나뉘어진다
• s3:ListBucket
  • s3::test라는 arn에 적용됨
  • 버킷 수준이므로 버킷을 특정해야 함
• Get/Put/Delete Object
  • 객체에 적용되므로 ARN이 달라진다
  • arn:awn:s3::test/* → /* 모든 객체에 적용되기 때문에

 

 

Resource Policies & aws:PrincipalOrgID

• aws:PrincipalOrgID는 AWS 조직 멤버 계정에만 리소스 정책이 적용되도록 제한
  • 조직내의 멤버 계정만 s3 버킷에 엑세스가 가능

이 외에도 사용 사례를 잘 연구하면 보안성을 더 높힐 수 있다

 

 

IAM Roles vs Resource Based Policies

• 교차 계정의 경우
  • s3 버킷에 s3 정책을 적용하는 것처럼 리소스에 리소스 기반 정책을 추가 가능
  • 리소스에 엑세스할 수 있는 역할을 사용할 수도 있었다
• 계정 A의 사용자가 엑세스 권한이 있는 계정B 사용하거나 계정 A의 사용자가 s3버킷에 적용된 버킷 정책을 통해 s3 버킷에 엑세스
  • IAM Role을 통한 엑세스와 s3 버킷 정책을 통한 엑세스

• 계정이 역할을 맡으면 기존의 권한을 모두 포기하고 해당 역할에 할당된 권한을 상속
  • 어떤 작업을 수행하는 역할을 맡게 되면 해당 역할에 부여된 작업은 할 수 있지만 기존의 권한은 사용할 수 없다
• 리소스 기반 정책을 사용하면 본인이 역할을 맡지 않으므로 권한을 포기할 필요가 없다
  • 리소스 기반 정책을 지원하는 AWS 서비스와 리소스가 점점 늘어나고 있다
• s3 버킷, SNS 토픽, SQS 큐, lambda 함수

 

Amazon EventBridge - Security

• EventBridge에서 원하는 작업을 하려면 타겟에 대한 권한을 요구, 허용해야하는 규칙이 있다
• Resource-based Policy → Lambda, SNS, SQS, CloudWatch Logs API Gateway
  • 이 경우 대상 리소스 기반 규칙으로 리소스를 변경해서 EventBridge가 원하는 작업을 수행할 수 있어야 한다

 

• IAM Role → Kinesis data stream, System Manager Run Command…
  • IAM 규칙을 EventBridge 규칙에 추가하면 Kinesi에 쓰기 작업을 수행할 권한을 갖게 된다

 

공식 문서를 통한 구분

 

IAM Permission Boundaries

• 사용자와 역할만 지원하고 그룹은 지원하지 않는다
• IAM 개체의 최대 권한을 정의하는 고급 기능
  • s3, cloudwatch, ec2 모두 허용하고 있다.
• 이걸 IAM 사용자에 연결하여 권한 경계를 설정하여 해당 작업만 할 수 있게 만든다
• IAM 정책을 통해 IAM 권한을 지정해서 권한 경계와 IAM 정책을 통한 권한을 완성되지만 실제로는 아무 권한도 생기지 않는다
• IAM 정책은 IAM 권한 경계 밖에 있기 때문에 사용자가 다른 IAM 사용자를 생성할 수 없다
  • IAM 권한 경계에 아무것도 포함되지 않았다

→ 관리자 엑세스를 부여하는 정책에 연결했음에도 권한 경계로 인해 s3 정책에만 연결된다

• 권한 경계때문에 제한이 생김

 

 

Permission Boundaries

• AWS Organizations SCP와 같이 사용할 수 있다
• Effective Permissions라고 하는 실제 유효 권한은 교집합이다
  • Identity Based Policy- 사용자나 그룹에 부여됨
  • Permissions boundary - 그룹이 아닌 사용자나 역할에만 적용
  • Organizations SCP - 모든 IAM 개체에 적용

사용사례

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

 

IAM Policy Evaluation Logic(IAM 정책 평가 로직)

• AWS내에 액션에 대한 권한 부여 방법을 알 수 있다
• 특정 IAM 액션을 할 때마다 각 사용자는 모든 방면에서 평가된다
  • 모든 방면에서 허용됐을 때만 최종 허용되고 액션을 수행할 수 있다

 

IAM Policy 예시

• sqs:CreateQueue를 실행 가능한지 → 불가능, Deny라는 명시적인 거부
• sqs:DeleteQueue를 실행 가능한지 → Deny와 Allow가 있더라도 명시적 거부가 있다면 바로 결정이 거부(Allow가 명시되어 있더라도 명시적인 거부에 포함되어 있다면 실행할 수 없다
• ec2:DescribeInstances는 실행 가능한지 → 불가능, 관련 사항이 없기 때문에(명시적 거부, 허용) 해당 IAM 정책에서는 실행이 불가능하다

 

AWS Cognito

• 사용자에게 웹 및 모바일 앱과 상호작용할 수 있는 자격 증명을 부여
  • 일반적으로 사용자들은 AWS 계정 외부에 있다
  • 모르는 사용자(외부 사용자)들에게 자격증명을 부여해 사용자를 인식한다
• 하위 서비스
  • 앱사용자에게 가입 기능을 제공하는 Cognito 사용자 풀(User pool)
  • API Gateway 및 애플리케이션 로드밸런서와 원활히 통합
• Federated Identity
  • 앱에 등록된 사용자에게 임시 AWS 자격 증명 제공 일부 AWS 리소스에 직접 엑세스 가능
  • 사용자 풀과 원활히 통합된다
• Cognito vs IAM 수백 명의 사용자, 모바일 사용자, SAML을 통한 인증 → Cognito를 설명한다

 

Cognito User Pools(CUP)

User Features

• 웹 및 모바일 앱을 대상으로하는 서버리스 사용자 데이터베이스
• 사용자 이름 또는 이메일, 비밀번호의 조합으로 간단한 로그인 절차를 정의 가능
  • 비밀번호재설정, 전화번호 이메일 검증, Facebook, Google과 통합을 통한 소셜 로그인

Integrations

• API gateway, ALB와 통합됨
• AWS 인프라 단위에서 유저를 검증할 수 있다

 

Cognito Identity Pools(Federated Identities)

• 사용자에게 자격 증명을 제공하지만 API 게이트웨이나 ALB를 거치지 않고 임시 AWS 자격 증명을 통해 AWS 계정에 직접 엑세스
• Cognito 사용자 풀 내의 사용자 혹은 써드파티의 타사 외부 사용자가 될 수 있다
  • 사용자는 직접 or API 게이트웨이를 통해 서비스에 엑세스 할 수 있다
• 자격 증명에 적용되는 IAM 정책은 Cognito에 이미 정의되어 있음
• user_id를 기반으로 사용자 정의하여 세분화된 제어 가능
• 기본 IAM 역할을 정의할 수도 있고 게스트같이 인증되지 않은 사용자는 기본 IAM 역할을 받음

웹 혹은 모바일 애플리케이션에서 사용자가 직접 s3 버킷, DynamoDB 테이블에 직접 엑세스를 원함

1. 타사 로그인 혹은 Cognito User Pools에서 토큰을 받는다
2. 이후 토큰을 Cognito Identity Pools에서 임시 AWS 자격 증명과 교환
3. 전달받은 토큰이 유효한 토큰인지 검증
4. 해당 사용자에게 적용되는 IAM 정책을 생성
5. 관련 임시 자격 증명으로 직접 엑세스하는 방식이다

 

Identity Pools를 사용하면 사용자에게 Row Level 자격 증명을 생성할 수 있다.

 

정리

웹이나 모바일 애플리케이션의 사용자 기반으로 생성할 수 있고 세분화된 엑세스 제어를 위해 Identity Pools를 활용 가능, 마지막으로 Cognito 사용자 풀은 API gateway 또는 ALB와 통합 가능

 

AWS IAM Identity Center

AWS의 SSO(Single Sign-On) 후속 제품

• 한번만 로그인하면 Salesforce, Box, Microsoft 365등에 연결 가능
• SAML2.0 통합이 가능한 어떤 앱에라도 연결 가능
  • ec2 windows 인스턴스에 대해서도 싱글 로그인 제공

Identity providers

• IAM 자격 증명 센터에 내장된 ID 저장소
• 서드파티 ID 공급자(AD, OneLogin, Okta)

Login Flow

한 번의 로그인으로 여러 AWS 계정 사용 가능

• IAM 자격 증명 센터 포털에 로그인하면 된다
• 뿐만 아니라 다른 비즈니스 애플리케이션과 연동도 가능

 

 

작동 방식

• AWS IAM Identity Center로 로그인해야한다
• Active Directory 혹은 IAM 자격증명센터를 통해 사용자 증명을 저장한다
• 한 번 로그인하면 다양한 서비스들과 통합
• Permission sets을 정의해서 어떤 계정이 무엇에 엑세스할 수 있는지 정의해야한다
• 사용자, 그룹 단위로 관리가 가능

 

 

IAM Identity Center

• Bob과 Alice가 개발 OU에 대해 전체 엑세스 권한을 주려고 함
  • 퍼미션 셋을 만들어 특정 OU와 연결해서 할당
  • 읽기 전용 엑세스 퍼미션 셋을 만들어 연결하고 다시 할당할 수 있다

 

세분화된 권한 및 할당

• 다중 계정 권한
  • 여러 계정에 대한 엑세스 관리
  • Permission sets을 활용해 사용자를 그룹에 할당하는 하나 이상의 IAM 정책을 정의
  • IAM Identity Center는 조직과 통합되어 수행
• 애플리케이션 할당
  • 사용자 또는 그룹이 어떤 애플리케이션에 엑세스할 수 있는지 정의 가능
  • 필요한 URL ,인증서, 메타데이터가 제공
  • 이를 가능하게 하는 것을 ABAC
• Attribute-Based Access Control(ABAC)
  • IAM 자격 증명 센터 스토어에 저장된 사용자 속성을 기반으로 세분화된 권한을 갖게 된다
  • 사용자를 비용센터에 할당하거나 주니어, 시니어 같은 직함을 주는 것 또한 가능
  • IAM 권한셋을 한 번만 정의하고 이 속성을 활용하여 사용자 또는 그룹의 AWS 엑세스만 수정

 

AWS Directory Service

• Microsoft AD는 도메인 서비스를 이용하는 모든 윈도우 서버에 사용되는 소프트웨어
• 객체의 데이터베이스로 사용자 계정, 컴퓨터, 보안 그룹이 객체가 될 수 있다
• 중앙 집중식 보안 관리 → 계정 생성 및 권한 할당
• 모든 객체는 트리로 구성되며 트리의 그룹을 포레스트(forest)

로그인 정보가 있는지 Domain 컨트롤러를 확인한 다음 로그인을 허용

사용자는 어떤 단일 컴퓨터든지 로그인이 가능하다

 

AWS Directory Services

• 엑티브 디렉터리를 생성하는 서비스
• AWS 관리형 마이크로소프트 AD
  • AWS에 자체 액티브 디렉터리를 생성
  • 로컬에서 관리가능하며 MFA 가능
  • 사용자가 있는 온프레미스 AD와 신뢰관계 구축 가능 → 서로 사용자가 공유됨
• AD Connector
  • 프록시로 온프레미스 AD에 리다이렉트 MFA 인증을 지원
  • 사용자는 온프레미스 AD에서만 관리된다 → AD는 연결만 관리
• Simple AD
  • 마이크로소프트 디렉토리를 사용하지 않고 결합도 되지 않는다

온프레미스 사용자를 프록시 → AD 커넥터

AWS 클라우드에서 사용자관리가 필요하고 MFA → AWS Managed AD

온프레미스가 없을 떄 → SImple AD

 

 

IAM Identity Center - Active Directory Setup

 

AWS Control Tower

• 모범사례를 기반으로 규정을 준수하는 다중 계정 AWS 환경을 손쉽게 설정 관리가 가능
• AWS Organization 서비스를 사용해 계정을 자동 생성
• 환경 구성이 편하다
• 가드레일을 통한 자동 정책 관리
• 정책 위반 감지 자동 교정
• 대화형 대시보드를 통한 규정 준수 모니터링

 

Guardrails

• 컨트롤 타워 환경 내의 모든 AWS 계정에 대한 지속적인 관리를 가능하게 한다
• 예방 가드레일
  • SCP → 모든 계정에서 리전을 제한하고 특정 리전만 푼다
• 탐지적 가드레일
  • 규정을 준수하지 않는 것을 탐지 Config를 사용하여 구현됨
  • 람다로 자동 교정또한 가능