AWS Organizations은 글로벌 서비스로 이를 통해 조직의 여러 AWS 계정을 관리할 수 있음
메인 계정은 마스터 계정이라고 부르고 바꿀 수 없으며 조직 내 다른 계정들은 멤버 계정
멤버 계정은 하나의 조직에만 속할 수 있지만 다른 조직으로 이동하는 마이그레이션을 할 수 있음
조직의 경우 모든 계정에서 단일 결제 수단으로 통합 결제를 할 수 있다는 이점이 존재하므로 원하는 만큼 계정을 만들 수 있고 마스터 계정으로 청구됨 예) EC2나 S3에 대한 대량 구매 할인이 있는 경우 통합 사용으로 가격 혜택을 얻을 수 있고 이는 조직 수준에서 얻을 수 있음 즉, 모든 계정을 하나의 조직으로 통합하여 더 적은 비용을 지불하고 청구 방법을 단순화할 수 있음
AWS 계정 생성을 자동화하는 API가 존재하며 온디맨드로 AWS 계정을 생성하고 해당 계정으로 청구된 금액을 더 큰 계정으로 롤백되도록 할 수 있음
Multi Account Strategies
AWS에 여러 계정이 있을 때의 여러 전략들 예1) 부서, 코스트 센터 또는 환경당 하나의 계정을 만들 수 있음 예2) dev, test, prod로 만들거나 또는 규제 제한을 기반으로 만들거나 더 나은 리소스 격리를 위해 만들 수 있음 그러므로 두 개의 계정을 만들고 페어링하지 않으며 리소스는 가상으로 격리됨 또한 계정당 서비스 제한과 로깅을 위한 별도 계정이 있는 것이 좋음
여러 계정에 대한 여러 전략이 존재하며 이는 조직의 주요 아키텍트를 어떻게 설계하려고 하느냐에 따라 달라짐 즉, 어떤 방식으로 어떻게 조직을 운영할지에 따라 달라짐
계정을 여러 개 갖는 것(Multi Account) vs 여러 VPC가 하나의 계정을 갖는 것 (One Account Multi VPC) 여러 계정이 있는 경우 계정이 정말 잘 분리되어 있고 다른 사용자 계정 등을 가지게 된다는 것이며 반면에 여러 VPC가 있는 큰 계정이 하나 있는 경우 리소스가 서로 통신할 수 있고 인스턴스와 사용자도 여러 VPC에 액세스 가능
결제 목적으로 태그 표준을 지정할 수 있음
CloudTrail을 활성화해서 Amazon S3 계정과 같은 중앙 계정에 로그를 보낼 수 있음
CloudWatch 로그를 중앙 로깅 계정으로 보낼 수 있음
교차 계정에 대해 매우 다양한 전략이 있고 모든 계정을 관리하려면 관리 목적을 위해 교차 계정 역할을 설정할 수 있으며 마스터 계정이 모든 하위 계정에 대해 관리자 역할을 수임할 수 있음
Organizational Units (OU) - Examples
모든 계정의 구성은 조직 단위인 OU를 사용해 구성하며 OU 유형을 설계하는 것은 전적으로 각자의 몫
조직 단위를 사업부별로 구성할 수 있음 예) 마스터 계정, 영업 OU, 소매 OU, 재무 OU가 있으며 각 OU 아래에는 서로 다른 계정이 존재
조직 단위를 환결별로 구성할 수 있음 예) 마스터 계정, 운영 OU, 개발 OU, 테스트 OU가 있으며 각 OU에 또 여러 계정이 존재
조직 단위를 프로젝트별로 구성할 수 있음 예) 프로젝트1, 프로젝트2, 프로젝트3, 그리고 그 아래 각각 계정이 여러 개
AWS Organization
조직이 어떻게 구성될 수 있는지
Root OU가 있고 루트 계정이 마스터 계정으로 되어 있고 그 안에 여러 OU를 가질 수 있음 예) 두 개의 계정을 가진 Dev OU와 두 개의 계정을 가진 Prod OU, Prod OU 안 쪽에 계정 두 개를 가진 Finance OU, 두 개의 계정을 가진 HR OU
원하는 OU에 계정을 할당할 수 있고 몇 가지 규칙과 SCP를 상속받게 됨
Service Control Policies (SCP)
OU의 보안으로는 서비스 제어 정책이라는 SCP가 존재
루트 OU나 루트 계정 수준에서 적용된 IAM 작업을 화이트리스트나 블랙리스트에 추가할 수 있으나 마스터 계정에는 적용되지 않음 즉, SCP는 마스터 계정에는 영향을 미치지 않으며 루트를 포함하여 계정의 사용자와 역할에만 적용할 수 있음
OU 내 계정에서 SCP를 적용하고 EC2를 사용할 수 없다고 하면 해당 계정 내 관리자라도 EC2를 사용할 수 없음
SCP는 다른 서비스가 조직과 상호 작용하는데 사용되는 서비스 연결 역할에는 적용되지 않음
SCP는 명시적인 허용이 있어야 허용되며 기본값으로는 아무것도 허용하지 않음
특정 서비스에 대한 액세스를 제한하는 SCP 사용 예) 프로덕션 계정에서 EMR을 쓸 수 없다고 하거나 AWS에서 아직 PCI를 준수하지 않는 서비스를 명시적으로 비활성화하여 PCI 규정 준수를 시행할 수 있음
SCP Hierarchy
루트 계정이 있는 루트 OU, 계정 A가 있는 Prod OU, 계정 B가 있는 HR OU, 계정 C가 있는 Finance OU
루트 OU에 FullAWSAccess SCP를 추가하여 모든 서비스와 모든 작업이 가능하여 계정을 사용할 수 있게 함
마스터 계정에는 DenyAccessAthena SCP를 추가하더라도 루트 OU의 마스터 계정이므로 SCP가 적용되지 않아 무엇이든 가능
Prod OU에 DenyRedShift SCP를 추가하고 AuthorizeRedshift SCP가 적용된 계정 A가 있을 때 계정 A는 FullAWSAccess SCP가 있기 때문에 무엇이든 할 수 있지만 Redshift에는 접근할 수 없음 OU 수준에서 Redshift에 대한 명시적 거부가 있으므로 AuthorizeRedsfhit SCP를 계정 A에 연결해도 거부가 승인보다 우선됨 계정 A는 OU 수준과 OU의 루트에서 SCP를 상속하므로 트리의 형태가 되며 이 중 하나라도 거부라면 거부가 됨
HR O에 DenyAWSLambda SCP를 추가하면 계정 B는 FullAWSAccess SCP가 있기 때문에 무엇이든 접근할 수 있으나 더 큰 OU인 Prod OU에 속해있으므로 Redshift에는 접근할 수 없고 HR OU 내에 있으므로 AWS Lambda에 액세스할 수 없음
반면 DenyAWSLambda SCP가 Finance OU에는 적용되지 않았기 때문에 Finance OU의 계정 C는 Redshift 외 모든 것이 허용된 접근 권한을 가짐
SCP Examples Blacklist and Whitelist strategies
SCP는 IAM 정책과 비슷하게 생김
블랙리스트 전략 AllowAllActions이므로 리소스와 작업을 모두 *로 하며 DenyDynamoDB 외의 모든 작업을 허용하기 위해 Effect는 Deny로 모든 리소스에 dynamodb:*를 적용
또 다른 전략으로는 특정 유형의 서비스만 화이트리스트에 추가 ec2: *와 CloudWatch: *를 모든 리소스에 허용하면 EC2와 CloudWatch 외엔 사용할 수 없게 됨
AWS Organization – Moving Accounts
Org A와 Org B가 있고 계정을 A에서 B로 옮길 때 (마이그레이션할 때)의 방법
멤버 계정을 이전 조직에서 제거
새로운 조직에 해당 계정을 포함하도록 초대
멤버 계정에 포함될 수 있도록 새로운 조직에 대한 초대를 수락 즉, 첫 조직을 떠나고 두 번째 조직으로부터 초대를 받으면 마이그레이션이 됨
만약 마스터 계정을 마이그레이션하는 경우에는 마스터 계정 내의 모든 단일 계정을 마이그레이션해야 하며 그 작업이 끝나면 조직을 삭제하고 독립 실행형 계정을 다시 Org B로 마이그레이션해야 함
<조직 실습>
조직 실습을 위한 새로운 계정 생성 Organizations은 계정들과 계정들을 재배치하는 것과 관련되어 있으므로 글로벌 서비스 조직 실습을 위한 새로운 aws-course-master 마스터 계정과 aws-course-child 하위 계정을 조직에 생성하여 실습을 진행
조직에 계정 초대 루트 조직 단위 안에 있는 마스터 계정에서 조직을 하나 더 생성하기 위해 Add an AWS account를 클릭
두 가지 옵션이 존재하며 하나는 계정을 생성하는 것으로 계정 이름, 계정 소유자의 이메일 주소, 대상 계정에 생성될 IAM 역할을 지정해서 조직에 의해 관리될 수 있도록 할 수 있음 아니면 기존의 AWS 계정을 초대할 수 있어 해당 계정과 연결된 이메일 주소나 초대할 계정의 계정 ID를 제공해야 함 이후 초대장이 보내지며 만약 이를 2주 내에 수락하지 않을 경우 만료가 됨
초대장을 받기 위해서는 Invitations를 클릭하고 마스터 계정의 초대장을 수락하면 AWS Organizations에 등록되고 조직 ID와 특성 세트를 볼 수 있으며 계정은 조직을 떠날 수도 있음
초대장
조직 단위로 계정 정리 루트가 있고 루트 안에 마스터와 하위 계정으로 두 개의 계정이 존재할 때 조직 단위인 OU로 계정을 정리하도록 함
루트로 가서 Actions의 Create new를 클릭해서 Dev라는 OU를 생성하고 이 후 Test OU, Prod OU 그리고 Prod OU 안에 다양한 부서인 HR OU, Finance OU를 생성
이처럼 계정을 정리, 이동할 수도 있고 Organizations에서 특정 OU 내에 계정을 만들 수도 있어 서비스 제어 정책을 갖도록 함
서비스 제어 정책 Policies로 가면 현재 사용 가능한 4개의 다른 정책이 있고 모두 비활성화되어 있음 이제 원하는 중요한 정책 유형인 서비스 제어 정책을 활성화하여 하위 계정이 수행할 수 있는 작업을 제한하도록 함
이외에도 백업 정책을 통해 조직 전체의 백업 계획을 배포하여 모든 계정이 규정을 준수하고 백업이 활성화되도록 할 수 있음 또는 태그 정책을 통해 조직의 다른 모든 계정 내의 태그를 사용하는 방법을 표준화할 수 있음
Service control policies를 클릭하면 지금까지 생성된 서비스 제어 정책인 FullAWSAccess를 볼 수 있음 FullAWSAccess는 모든 계정이 모든 서비스에 액세스하는 것을 허용함 루트 OU에 직접 연결된 적용 정책에 FullAWSAccess가 있어 루트의 모든 계정들과 하위 계정들이 AWS의 모든 서비스에 대해 액세스하는 것이 허용되는 것 또한 이들은 직접 연결될 수도 있고 상속될 수도 있음
Service control policies에 새로운 정책을 생성하여 연결하기 위해 Create policy를 클릭하고 DenyAccessS3라는 정책 생성 그리고 해당 정책과 연결된 OU 또는 계정에 대한 S3 서비스로의 액세스가 거부되도록 문장을 작성함 이후 이를 계정에 연결시키면 S3로의 액세스를 거부할 것임 이를 확인하기 위해 Prod의 Finance OU로 가서 DenyAccessS3를 연결하고 aws-course-child를 확인하면 DenyAccessS3가 Finance에서 상속된 것을 볼 수 있으며 이 계정을 통해 S3에 들어가면 권한이 없어 S3를 사용할 수 없음
Root 안의 Prod OU 안의 Finace OU의 하위 계정인 aws-course-child의 Policies
