참고 자료
https://www.udemy.com/course/best-aws-certified-solutions-architect-associate/
AWS Organizations
- 글로벌 서비스
- 여러 개의 AWS 계정을 관리할 수 있음
- 조직을 생성하면 조직의 메인 계정이 관리 계정이며, 다른 계정은 멤버 계정이다.
- 멤버 계정은 한 개의 조직에만 속할 수 있다.
- 모든 계정의 비용을 통합 결제 할 수 있음 - 하나의 지불 방법만 설정해두면 됨
- 집계된 사용량에 기반한 비용 할인을 받을 수 있음 (EC2, S3 등의 모든 계정의 사용량에 따른 할인)
- 계정 간 예약 인스턴스와 Saving Plans 할인이 공유된다.
- AWS 계정 생성을 자동화하기 위한 API 제공
- Advantages
- 다수의 계정을 가지므로 다수의 VPC를 가진 단일 계정에 비해 보안이 뛰어남 - 계정이 VPC보다 독립적이기 때문
- 청구 목적을 위한 태그 기준을 적용할 수 있음
- 한 번에 모든 계정에 대해 CloudTrail 활성화 및 로그를 중앙 S3 계정으로 전송
- CloudWatch Logs를 중앙 로깅 계정으로 전송
- 관리용으로 Cross Account 역할 설정
- Security: 서비스 제어 정책 (Service Control Policies, SCP)
- OU 또는 계정에 적용되는 IAM 정책으로 사용자 및 역할 제한
- SCP는 모든 계정에 적용되나 관리 계정에는 적용되지 않음
- 명시적 허용이 필요함 (IAM과 마찬가지로 기본적으로는 아무것도 허용하지 않음)
SCP Hierarchy
- 관리 계정 (Management Account)
- 관리 계정에는 SCP가 적용되지 않음
- 모든 작업 가능
- 모든 대상에 대해 관리자 권한을 갖는다.
- Account A
- Account B
- Redshift, Lamda 액세스 외 모든 작업 가능
- Account C
SCP Examples - Blocklist and Allowlist strategies
SCP에는 'Blocklist (차단 목록)'과 'Allowlis (허용 목록)' 두 가지 전략이 있다.
IAM Conditions
IAM Conditions는 IAM의 내부 정책에 적용되며 사용자 정책일 수도, S3 버킷에 대한 리소스 정책일 수도, 엔드 포인트 등 어떤 정책도 될 수 있다.
aws:SourceIP
- 모든 작업과 리소스를 거부하지만 조건이 있다.
- 두 개의 IP 주소 범위에 포함되지 않는 IP 주소는 거부하는 것이다.
- 클라이언트가 해당 IP 주소 내에서 API 호출을 하지 않으면 API 호출이 거부된다는 뜻이다.
aws:RequestedRegion
- AWS로 시작하므로 글로벌 조건이며 API 호출 리전을 제한한다.
- 위 예시에서는 eu-central-1, eu-west-1 리전에서 오는 EC2, RDS, DynamoDB 호출을 제한한다.
ec2:ResourceTag
, aws:PrincipleTag
- 접두사가 EC2이기 때문에 EC2 인스턴스의 태그에 적용된다.
- 위 예시에서는 ResourceTag/Project가 DataAnalytics일 때 모든 인스턴스의 시작과 종료를 허용한다.
- EC2 인스턴스가 올바른 태그를 갖고 있으면, 즉, procjet가 DataAnalytics이면 허용한다.
- 다음 줄의
aws:PrincipleTag
는 사용자 태그에 적용된다.
- 상기 작업을 수행하려면 사용자의 Department가 Data여야 한다.
aws:MultiFactorAuthPresent
- 정책을 보면 사용자는 EC2에서 모든 작업을 할 수 있지만 멀티팩터 인증이 있어야만 인스턴스를 중지하고 종료할 수 있다.
- MFA가 false일 때 거부된다.
IAM for S3
s3:ListBucket
은 s3:::test
라는 ARN에 적용된다.
s3:GetObject
, s3:PutObject
, s3:DeleteObject
는 버킷 내의 객체에 적용되므로 ARN이 달라진다.
- 버킷 내의 모든 객체를 나타내는
/*
이 들어간다.
- 객체 수준의 권한
(ARN: Amazon Resource Name의 약자로, AWS 리소스를 고유하게 식별하기 위해 사용되는 Amazon의 리소스 식별자, arn:partition:service:region:account-id:resource
과 같은 형식을 갖는다.)
Resource Policies & aws:PrincipalOrgID
aws:PrincipalOrgID
는 AWS 조직의 멤버 계정에만 리소스 정책이 적용되도록 제한한다.
IAM Roles vs Resource Based Policies
- 교차 계정의 경우
- 리소스 기반 정책을 리소스에 연결하는 방법 (ex. S3 버킷에 S3 정책을 사용하는 것)
- 또는 리소스에 액세스할 수 있는 역할을 사용할 수 있다.
- 첫 번째 예시에서는 Account A의 사용자가 Amazon S3 버킷에 대한 액세스 권한이 있는 Account B의 역할을 사용한다.
- 두 번째 예시에서는 Account A의 사용자가 Account B의 Amazon S3 버킷에 적용된 버킷 정책을 통해 S3 버킷에 액세스한다.
- IAM Role: 역할(사용자, 애플리케이션, 서비스)을 맡으면 기존의 권한을 모두 포기하고 해당 역할에 할당된 권한을 상속하게 된다.
- Resource-based Polices: 주체(사용자 또는 역할)는 본인이 역할을 맡지 않으므로 자신의 권한을 포기할 필요가 없다.
- Example: 계정 A의 사용자가 본인 계정의 DynamoDB 테이블을 스캔하고 그 계정을 계정 B의 버킷에 넣는 경우에는 리소스 기반 정책을 사용하는 것이 좋다.
- 리소스 기반 정책은 Amazon S3 버킷, SNS 토픽, SQS 큐 등 다양한 리소스에서 지원된다.
- 주체가 자신의 권한을 유지하면서 리소스에 대한 액세스를 제어할 수 있다.
Amazon EventBridge – Security
- Rule이 실행될 때 해당 대상(target)에 대한 권한이 필요하다.
- 리소스 기반 정책: Lambda, SNS, SQS, CloudWatch Logs, API Gateway 등
- IAM Role: Kinesis stream, Systems Manager Run Command, ECS 작업 등
SNS, SQS, Lambda에는 리소스 기반 정책, Kinesis Data Stream에는 IAM Role!!
IAM Permission Boundaries
- IAM 권한 경계는 사용자와 역할만 지원하고 그룹은 지원하지 않는다.
- IAM 개체가 받을 수 있는 최대 권한을 설정하기 위해 관리형 정책을 사용하는 고급 기능이다.
- IAM 권한 경계: S3, CloudWatch, EC2를 모두 허용
- 이를 IAM 사용자에게 연결하면 권한 경계를 설정하는 것이다. (S3, CloudWatch, EC2 내의 작업만 할 수 있게 됨)
- IAM 정책:
iam:Createuser
액션과 *
리소스를 같은 사용자에 연결하면 권한 경계와 IAM 정책을 통한 권한이 완성된다.
- 결과적으로 어떤 권한이 생길까?
- IAM 정책은 IAM 권한 경계 밖에 있기 때문에 사용자가 다른 IAM 사용자를 생성할 수 없다.
IAM Permission Boundaries
- AWS Organizations SCP와 함께 사용할 수 있다.
사용 사례:
- 관리자가 아닌 사용자에게 권한 경계 내에서 책임을 위임하는 경우, 예를 들어 새 IAM 사용자 생성
- 개발자가 자체적으로 정책을 할당하고 자신의 권한을 관리할 수 있도록 허용하면서도 "권한 상승"을 방지하여 특권을 얻을 수 없도록 함 (=자체적으로 관리자 권한 부여 불가)
- 조직 및 SCP를 사용하면 전체 계정이 아닌 특정 사용자의 권한을 제한하는 데 유용함
IAM Policy Evaluation Logic
모든 방면에서 거부되지 않고 허용됐을 때에만 마지막 허용 여부가 결정되고 액션을 진행할 수 있다.
Example IAM Policy
sqs:CreateQueue
를 실행할 수 있을까?
- No!
sqs:*
에 Deny와 *
가 있는데, CreateQueue가 해당 블록에 포함되기 때문
sqs:DeleteQueue
를 실행할 수 있을까?
- No!
- 위 쪽에는 Deny, 아래에는 Allow가 있다.
- 하지만 명시적 거부가 있으면 바로 결정이 거부된다.
sqs:*
에 Deny가 명시되어 있기 때문에 sqs:*
안에 있는 sqs:DeleteQueue
는 Allow가 있음에도 자동으로 거부된다.
ec2:DescribeInstances
는 실행할 수 있을까?
- No!
- IAM 정책에 EC2 관련 사항은 없다.
- 명시적 거부도 없지만 명시적 허용도 없기 때문에 해당 IAM 정책에서는
ec2:DescribeInstances
를 실행할 수 없다.
Amazon Cognito
- 웹 또는 모바일 애플리케이션과 상호 작용하는 사용자에게 식별 정보를 제공한다.
- Cognito 사용자 풀
- 앱 사용자를 위한 로그인 기능
- API Gateway 및 Application Load Balancer와 통합
- Cognito 자격 증명 풀 (Federated Identity)
- 사용자에게 AWS 자격 증명을 제공하여 직접 AWS 리소스에 액세스할 수 있도록 함
- Cognito 사용자 풀과 통합하여 신원 제공자로 사용함
- Cognito vs IAM: "수백 명의 사용자", "모바일 사용자", "SAML로 인증"과 같은 키워드가 나오는 경우 Cognito 사용
Cognito User Pools (CUP)
User Features
- 웹 및 모바일 앱을 위한 사용자의 서버리스 데이터베이스 생성
- 간편한 로그인: 사용자 이름(또는 이메일) / 비밀번호 조합
- 비밀번호 재설정 기능
- 이메일 및 전화번호 검증
- 사용자 멀티팩터 인증 (MFA)
- Federated Identities: Facebook, Google 등의 소셜 로그인, SAML
Integrations
- API Gateway 및 Application Load Balancer와 통합될 수 있다.
- API Gateway
- 사용자는 Cognito 사용자 풀에 접속하여 토큰을 받고 검증을 위해 API Gateway로 토큰을 전달한다. 확인이 끝나면 사용자 자격 증명으로 변환되어 백엔드의 Lambda 함수로 전달된다.
- ALB
- Cognito 사용자 풀을 애플리케이션 로드 밸런서 위에 배치한다. 애플리케이션이 Cognito 사용자 풀에 연결한 다음 ALB에 전달해서 유효한 로그인인지 확인한다. 유효한 로그인이라면 요청을 백엔드로 리다이렉트하고, 사용자의 자격증명과 함께 추가 헤더를 전송한다.
- API Gateway나 ALB를 통해 사용자의 로그인을 한 곳에서 확실히 검증할 수 있고 검증 책임을 백엔드로부터 백엔드의 로드를 밸런싱하는 실제 위치인 API Gateway 또는 ALB로 옮긴 것이다.
Cognito Identity Pools (Federated Identities)
- 사용자에 대한 자격 증명을 제공하여 일시적인 AWS 자격 증명을 얻을 수 있게 한다.
- 사용자는 Cognito 사용자 풀 내의 사용자 혹은 타사 로그인 등이 될 수 있다.
- 사용자는 직접 또는 API Gateway를 통해 서비스에 액세스할 수 있다.
- 자격 증명에 적용되는 IAM 정책은 Cognito에서 사전 정의되어 있다.
- user_id를 기반으로 사용자 정의하여 세부적인 제어를 할 수 있다.
- 게스트 사용자나 특정 역할이 정의되지 않은 인증된 사용자는 기본 IAM 역할을 상속하게 된다.
Diagram
Row Level Security in DynamoDB
- 위 예시에서는 DynamoDB의 LeadingKey가 Cognito 자격 증명 사용자 ID와 같아야 한다는 조건이다.
- 이 정책이 사용된 사용자는 DynamoDB 테이블의 모든 항목을 읽고 쓸 수 있는 것이 아니라, 이 조건을 통해 액세스를 얻은 항목에만 액세스할 수 있다.
Cognito: 웹이나 모바일 앱의 사용자 기반을 생성할 수 있고, 세분화된 액세스 제어를 위해 DynamoDB에서 행 수준 보안을 활성화할 수 있다. 또한 Cognito 사용자 풀과 API Gateway 또는 ALB를 통합할 수 있다.
AWS IAM Identity Center
- AWS Single Sign-On 서비스의 후속 제품
- 단일 로그인 기능
- AWS Organization 내의 모든 AWS 계정
- 비즈니스 클라우드 애플리케이션 (예: Salesforce, Box, Microsoft 365 등)
- SAML 2.0을 지원하는 애플리케이션
- EC2 Windows 인스턴스
- ID 공급자
- IAM Identity Center에 내장된 ID 저장소
- 서드파티 ID 공급자: Active Directory (AD), OneLogin, Okta 등
AWS IAM Identity Center – Login Flow
AWS IAM Identity Center
- 모든 것을 한 번만 로그인해도 된다는 것이 큰 장점이다. 흐름이 많이 단순화되기 때문이다.
- 하지만 로그인했다고 해서 모든 항목에 로그인할 수 있는 것은 아니다.
- 자격 증명 센터에서 권한 셋을 정의하여 어떤 사용자가 무엇에 액세스할 수 있는지 정의한다.
Fine-grained Permissions and Assignments
- 다중 계정 권한 (Multi-Account Permissions)
- AWS Organization 내의 여러 AWS 계정에 대한 액세스 관리
- 권한 세트 (Permission Sets): 사용자 및 그룹에 할당된 하나 이상의 IAM 정책을 모아서 AWS 액세스를 정의하는 기능
- 애플리케이션 할당 (Application Assignments)
- SAML 2.0 비즈니스 애플리케이션(Salesforce, Box, Microsoft 365 등)에 대한 SSO(Single Sign-On) 액세스 제공
- 필요한 URL, 인증서 및 메타데이터 제공
- 속성 기반 액세스 제어 (Attribute-Based Access Control, ABAC)
- 사용자의 속성에 기반한 세부적인 권한 제어
- 예: cost center, title, locale 등과 같은 사용자 속성을 활용한 세밀한 권한 부여
- 사용 사례: IAM 권한 세트를 한 번만 정의한 후, 이 속성을 활용하여 사용자 또는 그룹의 AWS 액세스를 수정하는 등의 유연한 권한 관리
AWS Directory Services
What is Microsoft Active Directory (AD)?
- AD 도메인 서비스를 사용하는 모든 Windows 서버에 사용되는 소프트웨어
- 객체의 데이터베이스: 사용자 계정, 컴퓨터, 프린터, 파일 공유, 보안 그룹이 객체가될 수 있음
- 중앙 집중식 보안 관리: 계정 생성, 권한 할당 등의 작업
- Objects are organized in trees
- A group of trees is a forest
AWS Directory Services
- AWS Managed Microsoft AD:
- AWS에 자체 AD를 생성하고 로컬에서 관리할 수 있으며 멀티팩터 인증을 지원한다.
- 독립 실행형 Active Directory로 사용자가 있는 온프레미스 AD와 "신뢰" 관계를 구축할 수 있다.
- AD Connector
- Directory Gateway (프록시)로 온프레미스 AD에 리다이렉트, 멀티팩터 인증 지원
- 온프레미스 AD에서만 사용자를 관리할 수 있음
- Simple AD
- AWS의 AD 호환 관리형 디렉토리
- Microsoft Directory를 사용하지 않으며 온프레미스 AD와도 결합되지 않는다.
온프레미스에서 사용자를 프록시한다면 AD 커넥터, AWS 클라우드에서 사용자를 관리하고 MFA를 사용해야 할 때는 AWS 관리형 AD, 온프레미스가 없을 땐 Simple AD
IAM Identity Center – Active Directory Setup
- Directory 서비스를 통해 AWS 관리형 AD를 연결하는 경우
- 통합은 즉시 사용 가능하다.
- 자체 관리형 디렉터리에 연결하는 경우
- AWS 관리형 Microsoft AD를 사용하여 양방향 신뢰 관계 구축
- 클라우드에 있는 액티브 디렉터리에서 사용자를 관리하고 싶을 때
- AD Connector 활용
- API 호출만 프록시할 때 - 지연 시간이 길어지긴 함
AWS Control Tower
- 모범 사례를 기반으로 안전하고 규정을 준수하는 다중 계정 AWS 환경을 손쉽게 설정하고 관리할 수 있다.
- AWS Control Tower 서비스는 AWS Organizations를 사용하여 계정을 생성한다.
- 장점:
- 몇 번의 클릭만으로 환경 설정 자동화
- 가드레일을 사용하여 지속적인 정책 관리 자동화
- 정책 위반 감지 및 조치
- 대화형 대시보드를 통한 규정 준수 모니터링
Guardrails
- AWS Control Tower의 가드레일은 Control Tower 환경 내의 모든 AWS 계정에 대한 지속적인 거버넌스를 제공한다.
- 예방적 가드레일 (Preventive Guardrail)
- SCP(Security Control Policies)를 사용하여 구현
- ex. 모든 계정에서 리전 제한을 설정하여 특정 리전의 사용을 제한
- 탐지적 가드레일 (Detective Guardrail)
- AWS Config를 사용하여 구현
- ex. 태그가 지정되지 않은 리소스 식별