이 글은 24년 하반기 AWS Certified Solutions Architect - Associate(이하 AWS SAA-C03) 자격증 취득을 위해서 아래 유데미 강의를 보고, 공부한 내용을 정리하였습니다.
https://www.udemy.com/course/best-aws-certified-solutions-architect-associate
AWS Organizations
- 글로벌 서비스.. 다수의 AWS 계정을 동시에 관리 가능
- 조직의 메인 계정이 관리 계정이 됨... 조직에서 생성하거나 추가된 계정은 멤버 계정
- 멤버 계정은 한 조직에만 들어가짐
- 모든 계정의 비용을 통합 결제할 수 있음
- 조직 계정을 쓰면 모든 계정에서 집계된 사용량에 기반한 비용 할인을 받을 수 있음
- 계정 간에 예약 인스턴스와 Saving Plan 할인이 공유됨
- 계정 생성을 자동화할 수 있는 API 제공
작동 원리
1. 루트 조직단위(OU, Organization Unit)이 있음
2. 루트 OU 내에 관리 계정 존재
3. 서브 OU를 만들 수 있음.. ex) dev OU 만들고 안에 멤버 계정 생성
4. 서브 OU 안에 OU를 만들 수 있음.. 비즈니스 단위별로..
장점
- 다수 VPC 가진 단일 계정보다, 보안이 뛰어남
- 청구 목적의 태그 기준 적용 가능
- 한 번에 모든 계정에 대해 CloudTrail을 활성화해서 중앙 계정 S3로 전송 가능
- CW Logs 중앙 로깅 가능
- 계정 관리 가능
보안 관점에서 SCP(Service Control Policy) 적용 가능
- 특정 OU 또는 계정에 적용되는 IAM 정책
- 해당 사용자와 역할 모두가 계정에서 할 수 있는 일을 제한할 수 있음.. 기본적으론 모두 제한
- 단, 영구적인 관리자 권한을 갖는 관리 계정에는 적용할 수 없음
- 상위 정책에 명시적 거부가 하나라도 들어가면, 하위정책에서 허용해도 거부됨
- '차단 목록'과 '허용 목록' 전략을 쓸 수 있음 (차단은 다 허용하고 차단할꺼만 정하기.. 허용은 반대)
IAM 고급
IAM 조건
- IAM 내부의 정책에 적용... ex) 특정 API 호출이 생성되는 클라이언트 IP를 제한되게 조건 걸기
- 회사 네트워크 내에서만 가능하도록 조정 가능.. 혹은 API 호출 리전을 제한
- 서비스가 특정 태그가 있을 때만 동작하도록 설정 가능
- S3 버킷에 대한 IAM 정책 : 버킷 수준 권한은 리소스에 버킷 arn을 특정해야하고, 객체 수준 권한은 객체 리소스에 객체 arn을 특정해야함... 버킷/* 로 모든 권한을 나타냄
- PrincipalOrgID : IAM 상태 키로 AWS 조직의 멤버 계정에만 리소스 정책이 적용되도록 제한 가능
- RequestedRegion: IAM 상태 키로 특정 리전에서만 API 호출을 허용 가능
IAM 역할 vs 리소스 기반 정책
- 교차 계정의 경우.. 특히 S3 버킷 교차 계정에서 API 호출을 수행하는 경우 두 가지 옵션이 있음
리소스 기반 정책
- S3 버킷의 S3 버킷 정책과 같은 것들
- 리소스에 리소스 기반 정책이 걸려있는것
- 원칙이 역할을 가정하지 않기에, 권한을 포기할 필요가 없음
`- 지원되는 서비스 : S3 버킷, SNS, SQS, 람다 함수 등..
역할 사용(자격 증명 기반 정책)
- 유저에게 역할이 부여되어 리소스에 접근할 수 있는 것
차이
- EventBridge를 쓸 때 규칙이 있고, 이 규칙들은 목표 대상에서 원하는 일을 수행하기 위한 권한이 필요
- 목표 대상이 리소스 기반 정책을 지원 하는 경우, EventBridge 규칙이 필요로하는 작업을 수행할 수 있도록 대상 리소스의 리소스 기반 정책을 변경해야함
- 그렇지 않은 경우(ex. KDS, ECS 등) IAM 역할을 EventBridge 규칙에 첨부해서 권한을 얻어야함
IAM 권한 경계
- Permissions boundary는 사용자와 역할만 지원하고 그룹은 지원하지 않음
- IAM 개체의 최대 권한을 정의하는 고급 기능
- 특정 리소스에만 접근할 수 있게 권한 경계를 설정하는 것
- 권한 경계 + IAM 정책을 같이 줘서 권한을 만듬... IAM 정책으로 아무리 높은 권한이 있어도 권한 경계에 한정됨
- AWS 조직 SCP와 같이 쓸 수 있음... 즉 SCP+권한경계-IAM 정책 의 교집합이 실제로 유의미한 권한이 됨
- 사례 : 관리자가 아닌 사용자에게 권한 위임을 할 때, 권한 경계 내에서 IAM 사용자를 생성하거나, 개발자가 권한을 남용하는 것을 막기 위해 사용
IAM 정책 평가 논리
1. 가능한 모든 정책 중 명시적인 거부가 있으면 Deny
2. 조직 SCP에서 허용되어 있는지 확인
3. 리소스 기반 정책에서 허용되는지 확인
4. 자격 증명 기반 정책에서 자격 증명이 있는지 확인
5. IAM 권한 경계 확인
6. 세션 정책 확인
7. (1)~(6)에 안 걸리고 다 통과하면 허용됨
AWS IAM 자격 증명 센터
- 한번만 로그인하면됨... 모든 AWS 계정/조직, 비즈니스 클라우드 애플리케이션(세일즈포스, MS365 등)
- SAML2.0 통합이 가능한 어떤 애플리케이션도 연결 가능
- EC2 윈도우 인스턴스도 가능
`- 여러 AWS 계정에 한번에 로그인도 가능
- ID 공급자 : 이 로그인을 위해 사용자는 두 위치에 저장가능(내장 ID 저장소, 서드파티 ID 공급자(Active Directory, OneLogin, Okta 등))
로그인 흐름
- 브라우저 인터페이스에서 로그인 시 AWS IAM 자격 증명센터가 내장 ID 저장소나 서드파티 ID 공급자에 확인하고, SSO를 통해 AWS 조직이나 계정, 비즈니스 클라우드 앱, SAML2.0 지원하는 앱에 로그인
- IAM 자격 증명센터 안에 그룹을 만들고, 권한 셋을 만들어 OU와 연결 후 그룹에 할당하는 방식으로 권한 제어 가능
다중 계정 권한
- 조직에서 여러 계정에 대한 액세스 관리 가능
- 권한 셋으로 사용자를 그룹에 할당하는 하나 이상의 IAM 정책 정의
애플리케이션 할당
- 어떤 사용자 또는 그룹이 어떤 애플리케이션에 액세스할 수 있는지를 정의
- 필요한 URL, 인증서, 메타데이터가 제공됨
속성 기반 액세스 제어
- Attribute-Based Access Control(ABAC)
- IAM 자격 증명 센터 스토어에 저장된 사용자 속성을 기반으로 세분화된 권한을 갖게됨
- 사례 : 사용자를 비용 센터에 할당, 주니어/시니어와 같은 직함 제공, locale로 특정 리전에만 액세스 제어
- 사례 : IAM 권한 셋을 한번만 정의하고 이 속성을 활용하여, 사용자 또는 그룹의 AWS 액세스만 수정하는 것
AWS 디렉토리 서비스
MS Active Directory(AD)
- AD 도메인 서비스를 사용하는 모든 윈도우 서버에 사용되는 SW
- 객체의 데이터베이스로 객체는 유저 계정, 컴퓨터, 프린터, 파일 공유, 보안 그룹이 객체가 될 수 있음
- 중앙 집중식 보안 관리로 계정 생성, 권한 할당 등의 작업 가능
- 모든 객체는 트리로 구성되고, 트리의 그룹을 포리스트(forest)라고 함
- 하나의 도메인 컨트롤러에 여러 윈도우 머신을 연결해서 하나의 계정으로 여러 머신에서 로그인
AWS Directory Service
- AWS에 액티브 디렉터리를 생성하는 서비스
`종류
1. AWS 관리형 MS AD
- AWS에 자체 AD를 생성하고 로컬에서 관리, MFA 지원
- 독립 실행형 AD로 사용자가 있는 온프레미스 AD와 신뢰 관계 구축 가능
- 즉, 서로 신뢰관계인 둘에서 양방향으로 인증을 지원하는 것... 온프레미스/AWS AD 모두 사용자가 있음
2. AD 커넥터
- 디렉터리 게이트웨이(프록시)로 온프레미스 AD에 리다이렉트하며 MFA 지원
- 사용자는 온프레미스에서만 관리
3. Simple AD
- MS 디렉터리를 사용하지 않고 온프레미스와도 결합하지 않음
- 독립형으로 AWS에서 동작
- 윈도우를 실행하는 EC2 인스턴스에 모든 로그인 정보와 자격 증명을 공유할 수 있음
IAM 자격 증명 센터와 AD와 통합 방법
AWS 관리형 MS AD 쓸 때
- IAM 자격 증명 센터를 AWS 관리형 MS AD에 통합하고 연결하도록 설정하면됨
온프레미스에 자체 관리형 AD가 있을 때
- AWS 관리형 MS AD와 양방향 신뢰 관계 구축하고, 자격 증명 센터에서 싱글 사인온으로 통합
- 혹은 AD 커넥터로 프록시만 하고, 자격 증명 센터와 연결
AWS Control Tower
- 모범 사례를 기반으로 안전하고 규정을 준수하는 다중 계정 AWS 환경을 손쉽게 설정 관리
- AWS 조직 서비스를 사용해 계정 자동 생성
장점
- 클릭 몇번으로 환경 자동 설정
- 가드레일을 사용해 자동으로 지속 정책 관리 가능
- 정책 위반 감지 및 자동 교정
- 대화형 대시보드로 모든 계정의 전반적인 규정 준수 모니터링
가드레일
- AWS 다중 계정 설정 시, 특정 항목에 관해 한번에 모두 제한하거나, 특정 유형의 규정 준수 사항을 모니터링
- 컨트롤 타워 내 모든 계정에 관한 거버넌스 획득
종류
- 예방 가드레일 : SCP를 사용해 모든 계정에 적용 (ex. 모든 계정 특정 리전에서만 접속)
- 탐지 가드레일 : AWS Config 서비스로 탐지.. SNS를 트리거해서 메일이나 람다 함수로 넘기기도 가능
'인프라 > AWS' 카테고리의 다른 글
[AWS] AWS 기술 정리 18편 네트워킹, VPC - (AWS SAA, Udemy 강의 정리) (1) | 2024.10.18 |
---|---|
[AWS] AWS 기술 정리 17편 보안 및 암호화, KMS, SSM - (AWS SAA, Udemy 강의 정리) (0) | 2024.10.17 |
[AWS] AWS 기술 정리 15편 모니터링 및 감사 - (AWS SAA, Udemy 강의 정리) (0) | 2024.10.13 |
[AWS] AWS 기술 정리 14편 머신러닝 - (AWS SAA, Udemy 강의 정리) (1) | 2024.10.13 |
[AWS] AWS 기술 정리 13편 AWS Database, 데이터 및 분석 - (AWS SAA, Udemy 강의 정리) (0) | 2024.10.12 |