기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

# AWS Control Tower 작동 방식
<a name="how-control-tower-works"></a>

이 섹션에서는 AWS Control Tower의 작동 방식을 개략적으로 설명합니다. 랜딩 존은 모든 AWS 리소스를 위한 잘 설계된 다중 계정 환경입니다. 이 환경을 사용하여 모든 AWS 계정에 규정 준수 규정을 적용할 수 있습니다.

## AWS Control Tower 랜딩 존의 구조
<a name="landing-zone-structure"></a>

AWS Control Tower의 랜딩 존 구조는 다음과 같습니다.
+ **루트** – 랜딩 존의 다른 모든 OU를 포함하는 상위 항목입니다.
+ **보안 OU** – 이 OU에는 로그 아카이브 계정 및 감사 계정이 포함되어 있습니다. 이러한 계정을 *공유 계정*이라고도 합니다. 랜딩 존을 시작할 때 이러한 공유 계정의 사용자 지정 이름을 선택할 수 있으며 보안 및 로깅을 위해 기존 AWS 계정을 AWS Control Tower로 가져올 수 있습니다. 그러나 나중에 이름을 변경할 수 없으며, 처음 시작한 후에는 보안 및 로깅을 위해 기존 계정을 추가할 수 없습니다.
+ **샌드박스 OU** - 랜딩 존을 활성화한 경우 랜딩 존을 시작하면 샌드박스 OU가 생성됩니다. 이 OU와 기타 등록된 OU에는 사용자가 AWS 워크로드를 수행하기 위해 사용하는 등록된 계정이 포함되어 있습니다.
+ **IAM Identity Center 디렉터리** - 기본적으로 이 디렉터리에는 IAM Identity Center 사용자가 포함되어 있습니다. 각 IAM Identity Center 사용자에 대한 권한 범위를 정의합니다. 선택적으로 ID 및 액세스 제어를 자체 관리하도록 선택할 수 있습니다. 자세한 내용은 [AWS IAM Identity Center 및 AWS Control Tower 작업을](https://docs.aws.amazon.com/controltower/latest/userguide/sso.html) 참조하세요.
+ **IAM Identity Center 사용자** - 사용자가 랜딩 존에서 AWS 워크로드를 수행하기 위해 수임할 수 있는 자격 증명입니다.

## 랜딩 존 설정 시 발생하는 일
<a name="how-it-works-setup"></a>

랜딩 존을 설정하면 AWS Control Tower가 사용자 대신 관리 계정에서 다음 작업을 수행합니다.
+  AWS Organizations 조직 루트 구조에 포함된 보안 및 샌드박스(선택 사항)라는 두 개의 조직 단위(OUs)를 생성합니다.
+ 보안 OU에 로그 아카이브 계정과 감사 계정이라는 두 개의 공유 계정을 생성하거나 추가합니다.
+ 기본 AWS Control Tower 구성을 선택하거나 ID 공급자를 자체 관리할 수 있는 경우 IAM Identity Center에 사전 구성된 그룹 및 Single Sign-On 액세스 권한이 있는 클라우드 네이티브 디렉터리를 생성합니다.
+ 정책 적용을 위해 모든 필수 예방 제어를 적용합니다.
+ 구성 위반 탐지를 위해 모든 필수 탐지 제어를 적용합니다.
+ *예방 제어는 관리 계정에 적용되지 않습니다.*
+ 관리 계정을 제외하고 제어는 조직 전체에 적용됩니다.

**AWS Control Tower 랜딩 존 및 계정에서 안전하게 리소스 관리**
+ 랜딩 존을 생성하면 여러 AWS 리소스가 생성됩니다. AWS Control Tower를 사용할 때 이 설명서에서 설명하는 지원되는 방법 이외의 방법으로 이러한 AWS Control Tower 관리형 리소스를 수정하거나 삭제하면 안 됩니다. 이러한 리소스를 삭제하거나 수정하면 랜딩 존이 알 수 없는 상태로 전환됩니다. 자세한 내용은 [AWS Control Tower 리소스 생성 및 수정 지침](getting-started-guidance.md) 섹션을 참조하세요.
+ 선택적 제어(*권장되거나 선택적인 * 지침이 있는 제어)를 활성화하면 AWS Control Tower는 계정에서 관리하는 AWS 리소스를 생성합니다. AWS Control Tower에 의해 생성된 리소스를 수정하거나 삭제하지 마세요. 그러면 제어가 알 수 없는 상태가 될 수 있습니다.

# 공유 계정이란?
<a name="what-shared"></a>

AWS Control Tower에서는 설정 중에 랜딩 존의 공유 계정인 관리 계정, 로그 아카이브 계정 및 감사 계정이 프로비저닝됩니다.

## 관리 계정이란?
<a name="what-is-mgmt"></a>

이 계정은 랜딩 존을 위해 특별히 생성한 계정입니다. 이 계정은 랜딩 존의 모든 항목에 대한 결제에 사용됩니다. OU 및 제어 관리는 물론 계정에 대한 Account Factory 프로비저닝에도 사용됩니다.

**참고**  
AWS Control Tower 관리 계정에서는 어떤 유형의 프로덕션 워크로드도 실행하지 않는 것이 좋습니다. 워크로드를 실행할 별도의 AWS Control Tower 계정을 만드세요.

자세한 내용은 [관리 계정](special-accounts.md#mgmt-account) 섹션을 참조하세요.

## 로그 아카이브 계정이란?
<a name="what-is-log-archive"></a>

이 계정은 랜딩 존의 모든 계정에서 API 활동 및 리소스 구성 로그의 리포지토리로 사용됩니다.

자세한 내용은 [로그 아카이브 계정](special-accounts.md#log-archive-account) 섹션을 참조하세요.

## 감사 계정이란?
<a name="what-is-audit"></a>

감사 계정은 보안 및 규정 준수 팀에 랜딩 존의 모든 계정에 대한 읽기 및 쓰기 액세스 권한을 부여하도록 설계된 제한된 계정입니다. 감사 계정에서, Lambda 함수에만 부여된 역할을 통해 프로그래밍 방식으로 액세스하여 계정을 검토할 수 있습니다. 감사 계정을 이용해 다른 계정에 수동으로 로그인할 수 없습니다. Lambda 함수 및 역할에 대한 자세한 내용은 [다른 AWS 계정에서 역할을 맡도록 Lambda 함수 구성](https://aws.amazon.com/premiumsupport/knowledge-center/lambda-function-assume-iam-role)을 참조하세요.

자세한 내용은 [감사 계정](special-accounts.md#audit-account) 단원을 참조하십시오.

# 제어 작동 방식
<a name="how-controls-work"></a>

제어는 전반적인 AWS 환경에 대한 지속적인 거버넌스를 제공하는 상위 수준 규칙이며, 각 제어는 단일 규칙을 적용하고 일반적인 언어로 표현됩니다. 적용 중인 선택적 제어 또는 적극 권장 제어는 언제든지 AWS Control Tower 콘솔 또는 AWS Control Tower API에서 변경할 수 있습니다. 필수 제어는 항상 적용되며 변경할 수 없습니다.

예방 제어는 조치가 발생하지 않도록 방지합니다. 예를 들어 **Amazon S3 버킷에 대한 버킷 정책 변경 허용 안 함**(이전: **로그 아카이브에 대한 정책 변경 허용 안 함**)이라는 선택적 제어는 로그 아카이브 공유 계정 내의 IAM 정책 변경을 방지합니다. 방지된 작업을 수행하려고 하면 이 시도가 거부되고 CloudTrail에 기록됩니다. 리소스도 로그인됩니다 AWS Config.

탐지적 제어는 특정 이벤트가 발생할 때 이를 탐지하고 CloudTrail에 동작을 기록합니다. 예를 들어 **Amazon EC2 인스턴스에 연결된 Amazon EBS 볼륨에 암호화가 활성화되었는지 여부 탐지**라는 적극 권장 제어는 암호화되지 않은 Amazon EBS 볼륨이 랜딩 존의 EC2 인스턴스에 연결되었는지 여부를 탐지합니다.

선제적 제어는 리소스가 계정에 프로비저닝되기 전에 리소스가 회사 정책 및 목표를 준수하는지 확인합니다. 리소스가 규정을 준수하지 않으면 리소스는 프로비저닝되지 않습니다. 사전 예방적 제어는 CloudFormation 템플릿을 통해 계정에 배포되는 리소스를 모니터링합니다.

*익숙한 사용자의 경우 AWS:* AWS Control Tower에서 예방 제어는 서비스 제어 정책(SCPs) 및 리소스 제어 정책(RCPs. 탐지 제어는 AWS Config 규칙을 사용하여 구현됩니다. 사전 예방적 제어는 CloudFormation 후크로 구현됩니다.

## 관련 항목
<a name="how-controls-related"></a>
+ [AWS Control Tower의 드리프트 감지 및 해결](drift.md)

## AWS Control Tower가 StackSets와 작동하는 방식
<a name="stacksets-how"></a>



AWS Control Tower는 기본적으로 CloudFormation StackSets를 사용하여 계정에 리소스를 설정합니다. 각 스택 세트에는 계정 및 계정 AWS 리전 당에 해당하는 StackInstances가 있습니다. AWS Control Tower는 계정 및 리전당 하나의 스택 세트 인스턴스를 배포합니다.

AWS Control Tower는 CloudFormation 파라미터에 따라 특정 계정에 업데이트를 AWS 리전 선택적으로 적용합니다. 일부 스택 인스턴스에 업데이트가 적용되면 다른 스택 인스턴스는 **오래됨** 상태로 남아있을 수 있습니다. 이는 예상된 정상 동작입니다.

스택 인스턴스가 **오래됨** 상태가 되면 일반적으로 그 스택 인스턴스에 해당하는 스택이 스택 세트의 최신 템플릿과 정렬되지 않음을 의미합니다. 스택은 이전 템플릿에 남아 있으므로 최신 리소스 또는 파라미터가 포함되지 않을 수 있습니다. 스택은 여전히 완전히 사용할 수 있습니다.

 다음은 업데이트 중에 지정된 CloudFormation 파라미터를 기반으로 예상되는 동작에 대한 간략한 요약입니다.

스택 세트 업데이트에 템플릿에 대한 변경 사항이 포함되거나(즉, `TemplateBody` 또는 `TemplateURL` 속성이 지정된 경우) `Parameters` 속성이 지정된 경우는 지정된 계정의 스택 인스턴스를 업데이트하기 전에 모든 스택 인스턴스를 **오래된** 상태로 CloudFormation 표시합니다 AWS 리전. 스택 세트 업데이트에 템플릿 또는 파라미터에 대한 변경 사항이 포함되지 않은 경우는 다른 모든 스택 인스턴스를 기존 스택 인스턴스 상태로 유지하면서 지정된 계정 및 리전의 스택 인스턴스를 CloudFormation 업데이트합니다. 스택 세트와 연결된 모든 스택 인스턴스를 업데이트하려면 `Accounts` 또는 `Regions` 속성을 지정하지 마세요.

자세한 내용은 CloudFormation 사용 설명서의 [스택 세트 업데이트를 참조하세요](https://docs.aws.amazon.com//AWSCloudFormation/latest/UserGuide/stacksets-update.html).