

# 자격 증명 및 액세스 관리
<a name="a-identity-and-access-management"></a>

**Topics**
+ [SEC 2  사람과 시스템에 대한 인증은 어떻게 관리합니까?](w2aac19b7b7b5.md)
+ [SEC 3 사람과 시스템에 대한 권한은 어떻게 관리합니까?](w2aac19b7b7b7.md)

# SEC 2  사람과 시스템에 대한 인증은 어떻게 관리합니까?
<a name="w2aac19b7b7b5"></a>

 안전한 AWS 워크로드 운영에 접근할 때 관리해야 하는 두 가지 유형의 자격 증명이 있습니다. 액세스 권한을 관리하고 부여하는 데 필요한 자격 증명의 유형을 이해하면 적절한 자격 증명이 적절한 조건에서 적절한 리소스에 액세스할 수 있도록 보장할 수 있습니다. 

인적 자격 증명: 관리자, 개발자, 운영자 및 최종 사용자가 AWS 환경과 애플리케이션에 액세스하려면 자격 증명이 필요합니다. 이들은 조직의 구성원이거나 협업하는 외부 사용자로, 웹 브라우저, 클라이언트 애플리케이션 또는 대화형 명령줄 도구를 통해 AWS 리소스와 상호작용합니다. 

시스템 자격 증명: 서비스 애플리케이션, 운영 도구 및 워크로드에서 AWS 서비스에 요청하려면(예: 데이터 읽기) 자격 증명이 필요합니다. 이러한 자격 증명에는 Amazon EC2 인스턴스 또는 AWS Lambda 함수와 같이 AWS 환경에서 실행되는 시스템이 포함됩니다. 액세스가 필요한 외부 당사자의 시스템 자격 증명을 관리할 수도 있습니다. 또한 AWS 환경에 액세스해야 하는 시스템이 AWS 외부에 있을 수도 있습니다. 

**Topics**
+ [SEC02-BP01 강력한 로그인 메커니즘 사용](sec_identities_enforce_mechanisms.md)
+ [SEC02-BP02 임시 보안 인증 정보 사용](sec_identities_unique.md)
+ [SEC02-BP03 안전하게 보안 암호를 저장 및 사용](sec_identities_secrets.md)
+ [SEC02-BP04 중앙 집중식 자격 증명 공급자 사용](sec_identities_identity_provider.md)
+ [SEC02-BP05 정기적으로 보안 인증 정보 감사 및 교체](sec_identities_audit.md)
+ [SEC02-BP06 사용자 그룹 및 속성 활용](sec_identities_groups_attributes.md)

# SEC02-BP01 강력한 로그인 메커니즘 사용
<a name="sec_identities_enforce_mechanisms"></a>

 최소 암호 길이를 적용하고, 사용자에게 일반적인 암호나 재사용된 암호를 사용하지 않도록 교육합니다. 추가적인 확인 계층을 제공하기 위해 소프트웨어 또는 하드웨어 메커니즘을 사용하여 MFA(Multi-Factor Authentication)를 적용합니다. 예를 들어 IAM Identity Center를 자격 증명 소스로 사용하는 경우, MFA에 “컨텍스트 인식” 또는 “상시 작동” 설정을 구성하고 사용자가 자신의 MFA 디바이스를 등록하여 도입 속도를 향상할 수 있습니다. 외부 자격 증명 공급자(IdP)를 사용하는 경우 MFA에 IdP를 구성합니다. 

 **이 모범 사례를 정립하지 않을 경우 노출되는 위험의 수준:** 높음 

## 구현 가이드
<a name="implementation-guidance"></a>
+  Identify and Access Management(IAM) 정책 생성: 사용자가 내 보안 인증 정보 페이지에서 역할을 수임하고 자신의 보안 인증 정보를 변경하고 MFA 디바이스를 관리할 수 있도록 하는 몇 가지 작업을 제외한 모든 IAM 작업을 금지하는 고객 관리형 IAM 정책을 [생성합니다](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_users-self-manage-mfa-and-creds.html#tutorial_mfa_step1). 
+  자격 증명 공급자에서 MFA 사용: 사용하는 자격 증명 공급자 또는 Single Sign-On에서 [MFA](https:/aws.amazon.com/iam/details/mfa) 를 사용합니다(예: [AWS IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/step1.html)). 
+  강력한 암호 정책 구성: 무작위 대입 공격으로부터 보호할 수 있도록 강력한 [암호 정책을](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_passwords_account-policy.html?ref=wellarchitected) IAM 또는 연동 자격 증명 시스템에서 구성합니다. 
+  [정기적인 자격 증명 교체](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#rotate-credentials): 워크로드 관리자가 암호와 액세스 키(사용하는 경우)를 정기적으로 변경해야 합니다. 

## 리소스
<a name="resources"></a>

 **관련 문서:** 
+  [AWS Secrets Manager 시작하기](https://docs.aws.amazon.com/secretsmanager/latest/userguide/getting-started.html) 
+  [IAM 모범 사례](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) 
+  [자격 증명 공급자 및 연동](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html) 
+  [AWS 계정 루트 사용자](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html?ref=wellarchitected) 
+  [AWS Secrets Manager 시작하기](https://docs.aws.amazon.com/secretsmanager/latest/userguide/getting-started.html?ref=wellarchitected) 
+   [임시 보안 자격 증명](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html?ref=wellarchitected) 
+  [보안 파트너 솔루션: 액세스 및 액세스 제어](https://aws.amazon.com/security/partner-solutions/#access-control) 
+  [임시 보안 자격 증명](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) 
+  [AWS 계정 루트 사용자](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html) 

 **관련 동영상:** 
+  [Best Practices for Managing, Retrieving, and Rotating Secrets at Scale(대규모 보안 암호 관리, 검색, 교체 모범 사례)](https://youtu.be/qoxxRlwJKZ4) 
+  [Managing user permissions at scale with IAM Identity Center(AWS SSO를 사용하여 대규모로 사용자 권한 관리)](https://youtu.be/aEIqeFCcK7E) 
+  [Mastering identity at every layer of the cake](https://www.youtube.com/watch?v=vbjFjMNVEpc) 

# SEC02-BP02 임시 보안 인증 정보 사용
<a name="sec_identities_unique"></a>

 자격 증명이 있어야 [임시 자격 증명을 동적으로 획득할 수 있습니다.](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_request.html). 인력 자격 증명의 경우 AWS IAM Identity Center를 사용하거나 AWS Identity and Access Management(IAM)과의 페더레이션을 사용하여 AWS 계정에 액세스합니다. 시스템 자격 증명(예: Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스 또는 AWS Lambda 함수)의 경우 장기적인 액세스 키를 포함한 IAM 사용자 대신 IAM 역할을 사용해야 합니다. 

AWS Management Console을 사용하는 인적 자격 증명의 경우, 사용자가 임시 보안 인증을 획득하여 AWS에 연동해야 합니다. AWS IAM Identity Center 사용자 포털을 사용하면 됩니다. CLI 액세스가 필요한 사용자의 경우, [AWS CLI v2](http://aws.amazon.com/blogs/developer/aws-cli-v2-is-now-generally-available/)를 사용합니다. CLI v2는 IAM Identity Center와의 직접적인 통합을 지원합니다. 사용자는 IAM Identity Center 계정과 역할에 연결된 CLI 프로필을 생성할 수 있습니다. 그러면 CLI가 자동으로 IAM Identity Center에서 AWS 보안 인증 정보를 검색하여 사용자를 대신해 새로 고칩니다. 따라서 IAM Identity Center 콘솔에서 임시 AWS 보안 인증 정보를 복사해 붙여넣지 않아도 됩니다. SDK의 경우, 사용자는 AWS Security Token Service(AWS STS)를 사용하여 임시 보안 인증 정보를 수신할 역할을 수임해야 합니다. 경우에 따라 임시 자격 증명이 실용적이지 않을 수 있습니다. 액세스 키를 저장하는 데 수반되는 위험을 알고 있어야 하고, 키를 자주 교체해 사용해야 하며, 가능한 경우 다중 인증(MFA)을 필수 조건으로 지정해야 합니다. 마지막으로 액세스한 정보를 사용하여 액세스 키를 교체하거나 제거할 시기를 결정합니다.

소비자에게 AWS 리소스에 대한 액세스 권한을 부여해야 하는 경우, [Amazon Cognito](https://docs.aws.amazon.com/cognito/latest/developerguide/role-based-access-control.html) 자격 증명 풀을 사용해 임시적이고 권한이 제한된 일련의 보안 인증 정보를 할당하여 AWS 리소스에 액세스합니다. 각 사용자에 대한 권한은 생성한 [IAM 역할](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) 을 통해 제어됩니다. 사용자의 ID 토큰에 있는 클레임에 따라 각 사용자의 역할을 선택하는 규칙을 정의할 수 있습니다. 인증된 사용자에 대한 기본 역할을 정의할 수 있습니다. 또한 인증되지 않은 게스트 사용자의 경우, 권한이 제한된 별도의 IAM 역할을 정의할 수 있습니다.

시스템 자격 증명의 경우, IAM 역할을 사용하여 AWS에 대한 액세스 권한을 부여해야 합니다. Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스의 경우 [Amazon EC2 역할](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2.html)을 사용할 수 있습니다. Amazon EC2 인스턴스에 IAM 역할을 연결하면 Amazon EC2에서 실행 중인 애플리케이션에서 Instance Metadata Service(IMDS)를 통해 AWS가 생성, 배포 및 교체하는 임시 보안 인증 정보를 자동으로 사용하도록 할 수 있습니다. 이 [최신 버전의](https://aws.amazon.com/blogs/security/defense-in-depth-open-firewalls-reverse-proxies-ssrf-vulnerabilities-ec2-instance-metadata-service/) IMDS는 임시 보안 인증 정보를 노출하는 취약점을 예방하는 데 도움이 되므로 구현해야 합니다. 키 또는 암호를 사용하여 Amazon EC2 인스턴스에 액세스하는 경우 [AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/what-is-systems-manager.html) 를 사용하면 저장된 보안 암호 없이 사전 설치된 에이전트를 통해 보다 안전하게 인스턴스에 액세스하고 이를 관리할 수 있습니다. 또한 AWS Lambda와 같은 다른 AWS 서비스를 사용하여 IAM 서비스 역할을 구성하고, 이를 통해 임시 보안 인증 정보를 사용해 AWS 작업을 수행하도록 서비스 권한을 부여할 수 있습니다. 임시 보안 인증 정보를 사용하지 못하는 경우 프로그래밍 방식의 도구(예: [AWS Secrets Manager](https://aws.amazon.com/secrets-manager/))를 사용하여 보안 인증 정보 교체와 관리를 자동화합니다.

**정기적으로 자격 증명 감사 및 교체: **올바른 제어 기능이 적용되는지 확인하려면 주기적인 검증(가능한 자동화된 도구 사용)을 실시해야 합니다. 인적 자격 증명의 경우, 사용자가 주기적으로 암호를 변경하고 액세스 키 사용을 중지하며 그 대신 임시 자격 증명을 사용하도록 규정해야 합니다. IAM 사용자에서 중앙화된 자격 증명으로 이전할 때 [보안 인증 보고서를 생성하여 ](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_getting-report.html)IAM 사용자를 감사할 수 있습니다. 또한 자격 증명 공급자에 MFA 설정을 사용하는 것이 좋습니다. 이를 위해 [AWS Config 규칙](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html) 를 설정하여 이러한 설정을 모니터링할 수 있습니다. 시스템 자격 증명의 경우, IAM 역할을 사용한 임시 보안 인증 정보를 사용해야 합니다. 이러한 방법이 불가능한 경우, 액세스 키를 자주 감사하고 교체해 사용해야 합니다.

**안전하게 보안 암호 저장 및 사용:** IAM과 관련이 없는 보안 인증 정보이며 임시 보안 인증 정보를 사용할 수 없는 경우(예: 데이터베이스 로그인) [Secrets Manager](https://aws.amazon.com/secrets-manager/)와 같이 보안 암호 관리 작업을 처리하도록 설계된 서비스를 사용합니다. Secrets Manager를 사용하면 [지원 서비스를 통해 간편하게 암호화된 보안 암호를 관리 및 교체하고 안전하게 저장할 수 있습니다.](https://docs.aws.amazon.com/secretsmanager/latest/userguide/integrating.html). 보안 암호에 액세스하기 위한 호출은 감사를 위해 AWS CloudTrail에 기록되며, IAM 권한은 이에 액세스하기 위한 최소 권한을 부여할 수 있습니다.

 **이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 높음 

## 구현 가이드
<a name="implementation-guidance"></a>
+  최소 권한 정책 구현: IAM 그룹 및 역할에 최소 권한 액세스 정책을 적용하여 사용자별로 정의한 역할 또는 기능을 반영합니다. 
  +  [최소 권한 부여](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege) 
+  불필요한 권한 제거: 불필요한 권한을 제거하여 최소 권한 정책을 구현합니다. 
  +  [사용자 활동 보기를 통한 정책 범위 축소](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor.html) 
  +  [역할 액세스 보기](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_manage_delete.html#roles-delete_prerequisites) 
+  권한 경계 고려: 권한 경계는 자격 증명 기반 정책을 통해 IAM 엔터티에 부여할 수 있는 최대 권한을 설정하는 관리형 정책을 사용하는 고급 기능입니다. 엔터티의 권한 경계는 자격 증명 기반 정책과 권한 경계 모두에서 허용되는 작업만 수행하도록 허용합니다. 
  +  [실습: 역할 생성을 위임하는 IAM 권한 경계](https://wellarchitectedlabs.com/Security/300_IAM_Permission_Boundaries_Delegating_Role_Creation/README.html) 
+  권한에 리소스 태그 고려: 태그를 사용하여 태깅을 지원하는 AWS 리소스에 대한 액세스를 제어할 수 있습니다. IAM 사용자 및 역할에 태깅하여 액세스할 수 있는 항목을 제어할 수도 있습니다. 
  +  [실습: EC2에 대한 IAM 태그 기반 액세스 제어](https://wellarchitectedlabs.com/Security/300_IAM_Tag_Based_Access_Control_for_EC2/README.html) 
  +  [ABAC(속성 기반 액세스 제어)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) 

## 리소스
<a name="resources"></a>

 **관련 문서:** 
+  [AWS Secrets Manager 시작하기](https://docs.aws.amazon.com/secretsmanager/latest/userguide/getting-started.html) 
+  [IAM 모범 사례](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) 
+  [자격 증명 공급자 및 연동](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html) 
+  [보안 파트너 솔루션: 액세스 및 액세스 제어](https://aws.amazon.com/security/partner-solutions/#access-control) 
+  [임시 보안 자격 증명](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) 
+  [AWS 계정 루트 사용자](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html) 

 **관련 동영상:** 
+  [Best Practices for Managing, Retrieving, and Rotating Secrets at Scale(대규모 보안 암호 관리, 검색, 교체 모범 사례)](https://youtu.be/qoxxRlwJKZ4) 
+  [Managing user permissions at scale with AWS IAM Identity Center(AWS SSO를 사용하여 대규모로 사용자 권한 관리)](https://youtu.be/aEIqeFCcK7E) 
+  [Mastering identity at every layer of the cake](https://www.youtube.com/watch?v=vbjFjMNVEpc) 

# SEC02-BP03 안전하게 보안 암호를 저장 및 사용
<a name="sec_identities_secrets"></a>

 보안 암호(예: 서드 파티 애플리케이션에 대한 암호)가 필요한 인력 및 시스템 자격 증명의 경우 특수 서비스의 최신 업계 표준을 사용하여 자동화된 교체 시스템에 암호를 저장합니다. 예를 들면, IAM과 관련이 없는 보안 인증 정보이며 임시 보안 인증 정보를 사용할 수 없는 경우(예: 데이터베이스 로그인) AWS Secrets Manager와 같이 보안 암호 관리 작업을 처리하도록 설계된 서비스를 사용합니다. Secrets Manager를 사용하면 지원 서비스를 통해 간편하게 암호화된 보안 암호를 관리 및 교체하고 안전하게 저장할 수 있습니다. 보안 암호에 액세스하기 위한 호출은 감사를 위해 AWS CloudTrail에 기록되며, IAM 권한은 이에 액세스하기 위한 최소 권한을 부여할 수 있습니다. 

 **이 모범 사례를 정립하지 않을 경우 노출되는 위험의 수준:** 높음 

## 구현 가이드
<a name="implementation-guidance"></a>
+  AWS Secrets Manager 사용: [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) 는 보안 암호를 쉽게 관리할 수 있게 해 주는 AWS 서비스입니다. 데이터베이스 자격 증명, 암호, 타사 API 키는 물론 임의의 텍스트도 보안 정보에 해당할 수 있습니다. 

## 리소스
<a name="resources"></a>

 **관련 문서:** 
+  [AWS Secrets Manager 시작하기 ](https://docs.aws.amazon.com/secretsmanager/latest/userguide/getting-started.html)
+  [자격 증명 공급자 및 연동](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html) 

 **관련 동영상:** 
+  [Best Practices for Managing, Retrieving, and Rotating Secrets at Scale(대규모 보안 암호 관리, 검색, 교체 모범 사례)](https://youtu.be/qoxxRlwJKZ4) 

# SEC02-BP04 중앙 집중식 자격 증명 공급자 사용
<a name="sec_identities_identity_provider"></a>

 인력 자격 증명의 경우 중앙 집중식 위치에서 자격 증명을 관리할 수 있는 자격 증명 공급자를 사용합니다. 이렇게 하면 단일 위치에서 액세스를 생성, 관리 및 취소하므로 여러 애플리케이션과 서비스에 대한 액세스를 더 쉽게 관리할 수 있습니다. 예를 들어 누군가가 퇴사한다면 한 곳에서 모든 애플리케이션 및 서비스(AWS 포함)에 대한 액세스 권한을 취소할 수 있습니다. 이렇게 하면 자격 증명을 여러 개 만들 필요가 없고, 기존 인사(HR) 프로세스와 통합할 수도 있습니다. 

개인 AWS 계정과 페더레이션하려면 AWS Identity and Access Management의 SAML 2.0 기반 공급자를 통해 AWS용 중앙 집중식 자격 증명을 사용할 수 있습니다. AWS에서 직접 호스팅하든, AWS 외부에서 호스팅하든, AWS Partner에서 제공하든 [SAML 2.0](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_saml.html) 프로토콜과 호환되기만 하면 어느 공급자를 사용해도 됩니다. AWS 계정과 선택한 공급자 사이의 페더레이션을 활용하면 SAML 어설션을 사용해 임시 보안 인증 정보를 얻어 사용자나 애플리케이션에 AWS API 작업을 호출할 액세스 권한을 부여할 수 있습니다. 웹 기반 SSO(Single Sign-On)도 지원되므로 사용자가 로그인 웹 사이트에서 AWS Management Console에 로그인할 수 있습니다.

AWS Organizations 내 여러 계정에 페더레이션하려면 [AWS IAM Identity Center(IAM Identity Center)](http://aws.amazon.com/single-sign-on/)에서 자격 증명 소스를 구성하여 사용자와 그룹이 저장될 위치를 지정하면 됩니다. 구성이 완료되면 자격 증명 공급자가 실제 소스가 되며, System for Cross-domain Identity Management(SCIM) v2.0 프로토콜을 사용해 정보를 [동기화](https://docs.aws.amazon.com/singlesignon/latest/userguide/provision-automatically.html) 할 수 있습니다. 그러면 사용자나 그룹을 검색하여 이들에게 AWS 계정, 클라우드 애플리케이션 또는 둘 모두에 IAM Identity Center 액세스 권한을 부여할 수 있습니다.

IAM Identity Center는 AWS Organizations와 통합되므로 자격 증명 공급자를 한 번 구성하면 조직에서 관리하는 [기존 및 새 계정에 대한 액세스 권한을 부여](https://docs.aws.amazon.com/singlesignon/latest/userguide/useraccess.html) 할 수 있습니다. IAM Identity Center는 사용자 및 그룹을 관리하는 데 사용할 수 있는 기본 스토어를 제공합니다. IAM Identity Center 스토어를 사용하는 경우, 최소 권한의 모범 사례를 염두에 두고 사용자와 그룹을 생성하고 해당 액세스 수준을 AWS 계정 및 애플리케이션에 할당합니다. 또는 SAML 2.0을 사용하여 [외부 자격 증명 공급자에 연결 ](https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-idp.html)하거나 [Microsoft AD Directory에 연결](https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-ad.html) (AWS Directory Service 사용)할 수 있습니다. 구성이 완료되면 중앙 자격 증명 공급자를 통해 인증한 후 AWS Management Console 또는 AWS 모바일 앱에 로그인할 수 있습니다.

최종 사용자 또는 워크로드 소비자(예: 모바일 앱)를 관리할 때는 다음을 사용할 수 있습니다. [Amazon Cognito](http://aws.amazon.com/cognito/). 이는 웹 및 모바일 앱의 인증, 권한 부여 및 사용자 관리 등의 기능을 제공합니다. 사용자는 사용자 이름과 암호를 통해 직접 로그인하거나, Amazon, Apple, Facebook 또는 Google 등 타사를 통해 로그인할 수 있습니다.

 **이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 높음 

## 구현 가이드
<a name="implementation-guidance"></a>
+  중앙화된 관리 액세스: AWS 계정과 ID 제공업체(idP) 간의 신뢰 관계를 구축하기 위해 Identity and Access Management(IAM) 자격 증명 공급자 엔터티를 생성합니다. IAM는 OpenID Connect (OIDC) 또는 SAML 2.0(Security Assertion Markup Language 2.0)과 호환되는 idP를 지원합니다. 
  +  [자격 증명 공급자 및 연동](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html) 
+  중앙화된 애플리케이션 액세스: 애플리케이션 액세스 중앙화에는 Amazon Cognito를 고려하십시오. Amazon Cognito를 사용하면 웹 및 모바일 앱에 사용자 가입/로그인 기능 및 액세스 제어를 빠르고 손쉽게 추가할 수 있습니다. [Amazon Cognito](https://aws.amazon.com/cognito/) 는 수백만 명의 사용자로 확장되며 Facebook, Google 및 Amazon과 같은 소셜 자격 증명 공급자와 SAML 2.0을 통한 엔터프라이즈 자격 증명 공급자를 통한 로그인을 지원합니다. 
+  오래된 IAM 사용자 및 그룹 제거: ID 제공업체(idP)를 사용하기 시작한 후 더 이상 필요하지 않은 IAM 사용자 및 그룹을 제거합니다. 
  +  [사용되지 않는 보안 인증 정보 찾기](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_finding-unused.html) 
  +  [IAM 그룹 삭제](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups_manage_delete.html) 

## 리소스
<a name="resources"></a>

 **관련 문서:** 
+  [IAM 모범 사례](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) 
+  [보안 파트너 솔루션: 액세스 및 액세스 제어](https://aws.amazon.com/security/partner-solutions/#access-control) 
+  [임시 보안 자격 증명](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) 
+  [AWS 계정 루트 사용자](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html) 

 **관련 동영상:** 
+  [Best Practices for Managing, Retrieving, and Rotating Secrets at Scale(대규모 보안 암호 관리, 검색, 교체 모범 사례)](https://youtu.be/qoxxRlwJKZ4) 
+  [Managing user permissions at scale with AWS IAM Identity Center(AWS SSO를 사용하여 대규모로 사용자 권한 관리)](https://youtu.be/aEIqeFCcK7E) 
+  [Mastering identity at every layer of the cake](https://www.youtube.com/watch?v=vbjFjMNVEpc) 

# SEC02-BP05 정기적으로 보안 인증 정보 감사 및 교체
<a name="sec_identities_audit"></a>

 임시 보안 인증 정보를 사용할 수 없으며 장기 보안 인증 정보가 필요한 경우 보안 인증 정보를 감사하여 정의된 제어(예: 다중 인증(MFA))가 적용되고 정기적으로 교체되며 적절한 액세스 수준을 보유하는지 확인합니다. 올바른 제어 기능이 적용되는지 확인하려면 주기적인 검증(가능한 자동화된 도구 사용)을 실시해야 합니다. 인적 자격 증명의 경우, 사용자가 주기적으로 암호를 변경하고 액세스 키 사용을 중지하며 그 대신 임시 자격 증명을 사용하도록 규정해야 합니다. AWS Identity and Access Management(IAM) 사용자에서 중앙화된 자격 증명으로 이전할 때 [보안 인증 보고서를 생성하여 ](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_getting-report.html)IAM 사용자를 감사할 수 있습니다. 또한 자격 증명 공급자에 MFA 설정을 사용하는 것이 좋습니다. 이를 위해 [AWS Config 규칙](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html) 를 설정하여 이러한 설정을 모니터링할 수 있습니다. 시스템 자격 증명의 경우, IAM 역할을 사용한 임시 보안 인증 정보를 사용해야 합니다. 이러한 방법이 불가능한 경우, 액세스 키를 자주 감사하고 교체해 사용해야 합니다. 

 **이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 보통 

## 구현 가이드
<a name="implementation-guidance"></a>
+  정기적으로 보안 인증 정보 감사: 보안 인증 보고와 Identify and Access Management(IAM) Access Analyzer를 사용하여 IAM 보안 인증 정보 및 권한을 감사합니다. 
  +  [IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html) 
  +  [보안 인증 보고서 가져오기](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_getting-report.html) 
  +  [실습: 자동화된 IAM 사용자 정리](https://wellarchitectedlabs.com/Security/200_Automated_IAM_User_Cleanup/README.html?ref=wellarchitected-tool) 
+  액세스 수준을 사용하여 IAM 권한 검토: AWS 계정의 보안을 강화하기 위해 각 IAM 정책을 정기적으로 검토하고 모니터링합니다. 필요한 작업을 수행하는 데 필요한 최소 권한만 정책에서 부여하는지 확인합니다. 
  +  [액세스 수준을 사용하여 IAM 권한 검토](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#use-access-levels-to-review-permissions) 
+  IAM 리소스 생성 및 업데이트 자동화 고려: AWS CloudFormation을 사용하면 템플릿을 확인하고 버전을 제어할 수 있으므로, 역할 및 정책을 포함한 IAM 리소스 배포를 자동화하고 인적 오류를 줄일 수 있습니다. 
  +  [실습: IAM 그룹 및 역할의 자동 배포](https://wellarchitectedlabs.com/Security/200_Automated_Deployment_of_IAM_Groups_and_Roles/README.html) 

## 리소스
<a name="resources"></a>

 **관련 문서:** 
+  [AWS Secrets Manager 시작하기](https://docs.aws.amazon.com/secretsmanager/latest/userguide/getting-started.html) 
+  [IAM 모범 사례](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) 
+  [자격 증명 공급자 및 연동](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html) 
+  [보안 파트너 솔루션: 액세스 및 액세스 제어](https://aws.amazon.com/security/partner-solutions/#access-control) 
+  [임시 보안 자격 증명](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) 

 **관련 동영상:** 
+  [Best Practices for Managing, Retrieving, and Rotating Secrets at Scale(대규모 보안 암호 관리, 검색, 교체 모범 사례)](https://youtu.be/qoxxRlwJKZ4) 
+  [Managing user permissions at scale with AWS IAM Identity Center(AWS SSO를 사용하여 대규모로 사용자 권한 관리)](https://youtu.be/aEIqeFCcK7E) 
+  [Mastering identity at every layer of the cake](https://www.youtube.com/watch?v=vbjFjMNVEpc) 

# SEC02-BP06 사용자 그룹 및 속성 활용
<a name="sec_identities_groups_attributes"></a>

 관리하는 사용자 수가 늘어나면서 사용자를 체계적으로 정리하여 대규모로 관리할 방법을 결정해야 합니다. 공통 보안 요구 사항이 있는 사용자들을 자격 증명 공급자가 정의한 그룹에 배치하고, 액세스 제어에 사용할 수 있는 사용자 속성(예: 부서 또는 위치)이 정확하게 업데이트되었는지 확인하는 메커니즘을 적절히 설정합니다. 액세스를 제어할 때는 개별적인 사용자가 아니라 이러한 그룹과 속성을 사용합니다. 이를 통해 사용자의 액세스 권한을 변경해야 할 때 여러 개별 정책을 업데이트하는 대신 [권한 세트](https://docs.aws.amazon.com/singlesignon/latest/userguide/permissionsets.html)를 사용해 사용자의 그룹 멤버십 또는 속성을 한 번 변경하여 중앙에서 액세스를 관리할 수 있습니다. AWS IAM Identity Center(IAM Identity Center)를 사용하여 사용자 그룹 및 속성을 관리할 수 있습니다. IAM Identity Center는 가장 보편적으로 사용되는 속성을 지원합니다. 사용자 생성 중에 수동으로 입력한 것이든, 동기화 엔진을 사용하여 자동으로 프로비저닝된 것(예: System for Cross-Domain Identity Management(SCIM) 사양에 정의된 대로)이든 마찬가지입니다. 

공통 보안 요구 사항이 있는 사용자들을 자격 증명 공급자가 정의한 그룹에 배치하고, 액세스 제어에 사용할 수 있는 사용자 속성(예: 부서 또는 위치)이 정확하게 업데이트되었는지 확인하는 메커니즘을 적절히 설정합니다. 개별 사용자가 아닌 이러한 그룹 및 속성을 사용하여 액세스를 제어합니다. 이를 통해 사용자의 액세스 권한을 변경해야 할 때 여러 개별 정책을 업데이트하는 대신 사용자의 그룹 멤버십 또는 속성을 한 번 변경하여 중앙에서 액세스를 관리할 수 있습니다.

 **이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 낮음 

## 구현 가이드
<a name="implementation-guidance"></a>
+  AWS IAM Identity Center(IAM Identity Center)를 사용하는 경우 그룹 구성: IAM Identity Center는 사용자 그룹을 구성하고 그룹에 원하는 수준의 권한을 할당할 수 있는 기능을 제공합니다. 
  +  [AWS Single Sign-On - 자격 증명 관리](https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-sso.html) 
+  속성 기반 액세스 제어(ABAC) 자세히 알아보기: ABAC는 속성을 기반으로 권한을 정의하는 권한 부여 전략입니다. 
  +  [AWS용 ABAC란 무엇입니까?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) 
  +  [실습: EC2에 대한 IAM 태그 기반 액세스 제어](https://www.wellarchitectedlabs.com/Security/300_IAM_Tag_Based_Access_Control_for_EC2/README.html) 

## 리소스
<a name="resources"></a>

 **관련 문서:** 
+  [AWS Secrets Manager 시작하기](https://docs.aws.amazon.com/secretsmanager/latest/userguide/getting-started.html) 
+  [IAM 모범 사례](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) 
+  [자격 증명 공급자 및 연동](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html) 
+  [AWS 계정 루트 사용자](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html) 

 **관련 동영상:** 
+  [Best Practices for Managing, Retrieving, and Rotating Secrets at Scale(대규모 보안 암호 관리, 검색, 교체 모범 사례)](https://youtu.be/qoxxRlwJKZ4) 
+  [Managing user permissions at scale with AWS IAM Identity Center(AWS SSO를 사용하여 대규모로 사용자 권한 관리)](https://youtu.be/aEIqeFCcK7E) 
+  [Mastering identity at every layer of the cake](https://www.youtube.com/watch?v=vbjFjMNVEpc) 

 **관련 예시:** 
+  [실습: EC2에 대한 IAM 태그 기반 액세스 제어](https://www.wellarchitectedlabs.com/Security/300_IAM_Tag_Based_Access_Control_for_EC2/README.html) 

# SEC 3 사람과 시스템에 대한 권한은 어떻게 관리합니까?
<a name="w2aac19b7b7b7"></a>

 AWS 및 워크로드에 액세스해야 하는 사람 및 시스템 자격 증명에 대한 액세스를 제어하는 권한을 관리합니다. 권한은 누가 어떤 조건에서 무엇에 액세스할 수 있는지를 제어합니다. 

**Topics**
+ [SEC03-BP01 액세스 요구 사항 정의](sec_permissions_define.md)
+ [SEC03-BP02 최소 권한 액세스 부여](sec_permissions_least_privileges.md)
+ [SEC03-BP03 긴급 액세스 프로세스 설정](sec_permissions_emergency_process.md)
+ [SEC03-BP04 지속적으로 권한 축소](sec_permissions_continuous_reduction.md)
+ [SEC03-BP05 조직에 대한 권한 가드레일 정의](sec_permissions_define_guardrails.md)
+ [SEC03-BP06 수명 주기에 따라 액세스 관리](sec_permissions_lifecycle.md)
+ [SEC03-BP07 퍼블릭 및 크로스 계정 액세스 분석](sec_permissions_analyze_cross_account.md)
+ [SEC03-BP08 안전하게 리소스 공유](sec_permissions_share_securely.md)

# SEC03-BP01 액세스 요구 사항 정의
<a name="sec_permissions_define"></a>

관리자, 최종 사용자 또는 기타 구성 요소는 워크로드의 각 구성 요소 또는 리소스에 액세스해야 합니다. 누가 혹은 무엇이 각 구성 요소에 액세스할 수 있는지 명확하게 정의한 다음 적절한 자격 증명 유형과 인증 및 권한 부여 방법을 선택해야 합니다.

 **일반적인 안티 패턴:** 
+ 애플리케이션에 보안 암호를 하드 코딩 또는 저장합니다. 
+ 각 사용자에 대한 사용자 지정 권한을 부여합니다. 
+ 수명이 긴 보안 인증을 사용합니다. 

 **이 모범 사례가 확립되지 않을 경우 노출되는 위험의 수준:** 높음 

## 구현 가이드
<a name="implementation-guidance"></a>

 관리자, 최종 사용자 또는 기타 구성 요소는 워크로드의 각 구성 요소 또는 리소스에 액세스해야 합니다. 누가 혹은 무엇이 각 구성 요소에 액세스할 수 있는지 명확하게 정의한 다음 적절한 자격 증명 유형과 인증 및 권한 부여 방법을 선택해야 합니다.

조직 내 AWS 계정에 대한 정기적인 액세스를 제공하려면 [페더레이션 액세스](https://aws.amazon.com/identity/federation/) 또는 중앙 집중식 자격 증명 공급자를 사용해야 합니다. 또한 자격 증명 관리를 중앙 집중화하고, 직원 액세스 수명 주기에 대한 AWS 액세스를 통합하기 위해 정립된 사례가 있는지 확인해야 합니다. 예를 들어, 직원이 다른 액세스 수준의 직무로 변경할 경우 해당 그룹 멤버십 또한 변경하여 새로운 액세스 요구 사항을 반영해야 합니다.

 비 인적 자격 증명에 대한 액세스 요구 사항을 정의할 경우 어떤 애플리케이션 및 구성 요소가 액세스해야 하는지, 그리고 어떻게 권한이 부여되는지 결정합니다. 권장되는 접근 방식은 최소 권한 액세스 모델을 통해 구축된 IAM 역할을 사용하는 것입니다. [AWS 관리형 정책은](https://docs.aws.amazon.com/singlesignon/latest/userguide/security-iam-awsmanpol.html) 대부분의 일반적인 사용 사례를 다루는 사전 정의된 IAM 정책을 제공합니다.

AWS 서비스, 즉 [AWS Secrets Manager](https://aws.amazon.com/blogs/security/identify-arrange-manage-secrets-easily-using-enhanced-search-in-aws-secrets-manager/) 및 [AWS Systems Manager Parameter Store는](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-parameter-store.html)IAM 역할 사용이 실현 불가능한 경우 애플리케이션 또는 워크로드로부터 보안 암호를 안전하게 분리할 수 있도록 지원합니다. Secrets Manager에서 보안 인증에 대한 자동 교체를 설정할 수 있습니다. Systems Manager를 사용하여 스크립트, 명령, SSM 문서, 구성 및 자동화 워크플로의 파라미터를 참조할 수 있으며 이 경우 파라미터를 생성할 때 지정한 고유한 이름을 사용합니다.

AWS Identity and Access Management Roles Anywhere를 사용하여 [IAM 외부에서 실행되는 워크로드에 대한](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) AWS의 임시 보안 자격 증명을 얻을 수 있습니다. 워크로드에서 사용하는 [IAM 정책](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) 및 [IAM 역할은](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) AWS 애플리케이션에서 AWS 리소스에 액세스하는 데 사용하는 것과 동일한 것일 수 있습니다. 

 가능한 경우, 장기적이고 정적인 보안 인증보다는 단기적이고 임시적인 보안 인증을 사용하는 것이 좋습니다. 프로그래밍 방식 액세스 및 장기 보안 인증을 사용하는 IAM 사용자가 필요한 경우 [마지막으로 사용된 액세스 키 정보를](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_RotateAccessKey) 사용하여 액세스 키를 교체 및 제거합니다. 

## 리소스
<a name="resources"></a>

 **관련 문서:** 
+  [속성 기반 액세스 제어(ABAC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) 
+  [AWS IAM Identity Center](https://aws.amazon.com/iam/identity-center/) 
+  [IAM Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html) 
+  [IAM Identity Center의 AWS 관리형 정책](https://docs.aws.amazon.com/singlesignon/latest/userguide/security-iam-awsmanpol.html) 
+  [AWS IAM 정책 조건](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) 
+  [IAM 사용 사례](https://docs.aws.amazon.com/IAM/latest/UserGuide/IAM_UseCases.html) 
+  [불필요한 보안 인증 제거](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#remove-credentials) 
+  [정책 사용](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage.html) 
+  [AWS 계정, OU 또는 조직을 기준으로 AWS 리소스에 대한 액세스를 제어하는 방법](https://aws.amazon.com/blogs/security/how-to-control-access-to-aws-resources-based-on-aws-account-ou-or-organization/) 
+  [AWS Secrets Manager의 향상된 검색을 사용하여 보안 암호를 쉽게 식별, 정렬 및 관리](https://aws.amazon.com/blogs/security/identify-arrange-manage-secrets-easily-using-enhanced-search-in-aws-secrets-manager/) 

 **관련 동영상:** 
+  [60분 이내에 IAM 정책 마스터하기](https://youtu.be/YQsK4MtsELU) 
+  [업무 분리, 최소 권한, 위임 및 CI/CD](https://youtu.be/3H0i7VyTu70) 
+  [혁신을 위한 자격 증명 및 액세스 관리 간소화](https://www.youtube.com/watch?v=3qK0b1UkaE8) 

# SEC03-BP02 최소 권한 액세스 부여
<a name="sec_permissions_least_privileges"></a>

특정 조건에서 특정 AWS 리소스에 대한 특정 작업과 관련한 액세스를 허용하여 자격 증명에 필요한 액세스 권한만 부여합니다. 개별 사용자에 대한 권한을 정의하는 대신, 그룹 및 자격 증명 속성을 사용하여 대규모로 권한을 동적으로 설정합니다. 예를 들어 개발자 그룹이 자체 프로젝트에 대한 리소스만 관리하도록 액세스 권한을 허용할 수 있습니다. 이렇게 하면 특정 개발자를 그룹에서 제거했을 때 액세스 정책을 변경할 필요 없이 해당 그룹을 액세스 제어에 사용한 모든 리소스에서 이 개발자에 대한 액세스가 취소됩니다.

 **일반적인 안티 패턴:** 
+ 사용자에게 기본적으로 관리자 권한을 부여합니다. 
+ 일상적인 활동에 루트 계정을 사용합니다. 

 **이 모범 사례가 확립되지 않을 경우 노출되는 위험의 수준:** 높음 

## 구현 가이드
<a name="implementation-guidance"></a>

원칙으로 [최소 권한](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege) 을 확립하면 사용 가능성과 효율성을 적절하게 절충하면서 자격 증명이 특정 작업을 처리하는 데 필요한 최소한의 기능 세트만 수행하도록 할 수 있습니다. 이 원칙에 따라 운영하면 의도치 않은 액세스를 제한하고, 누가 어떤 리소스에 액세스할 수 있는지 감사할 수 있습니다. AWS에서는 루트 사용자를 제외하고는 기본적으로 자격 증명에 권한이 없습니다. 루트 사용자의 보안 인증은 엄격하게 제어되어야 하며 [특정 작업](https://docs.aws.amazon.com/general/latest/gr/aws_tasks-that-require-root.html)에만 사용해야 합니다. 

IAM 또는 리소스 엔터티(예: 페더레이션형 ID, 시스템 또는 리소스(예: S3 버킷)에서 사용하는 IAM 역할)에 연결된 권한을 명시적으로 부여하는 경우 정책을 사용합니다. 정책을 생성하여 연결할 때 서비스 작업, 리소스는 물론 AWS가 액세스를 허용하려면 참이어야 하는 조건을 지정할 수 있습니다. AWS는 다양한 조건을 지원하여 액세스 범위를 축소할 수 있도록 도와줍니다. 예를 들어, `PrincipalOrgID` [조건 키](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html)를 사용하면 AWS Organizations의 식별자를 확인하므로 AWS Organization 내에서만 액세스를 허용할 수 있습니다.

또한 AWS CloudFormation에서 AWS Lambda 함수를 생성하는 등 AWS 서비스가 사용자를 대신하여 수행하는 요청을 `CalledVia` 조건 키를 사용하여 제어할 수도 있습니다. 계정 내 전체 권한을 효과적으로 제한하기 위해 다른 정책 유형 간 계층을 지정해야 합니다. 예를 들어, 애플리케이션 팀에서 자체적으로 IAM 정책을 생성하도록 허용할 수 있지만 [권한 경계](https://aws.amazon.com/blogs/security/delegate-permission-management-to-developers-using-iam-permissions-boundaries/) 를 사용하여 이들이 허용할 수 있는 최대 권한을 제한해야 합니다. 

권한 관리를 확장하고 최소 권한의 원칙을 준수하는 데 도움이 되는 다양한 AWS 기능이 있습니다. [속성 기반 액세스 제어](https://aws.amazon.com/blogs/security/delegate-permission-management-to-developers-using-iam-permissions-boundaries/) 를 통해 리소스의 *[태그](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/tagging-best-practices.html)* 를 기준으로 권한을 제한할 수 있으며, 이를 통해 리소스 및 호출하는 IAM 보안 주체에 적용된 태그를 기준으로 권한 부여 결정을 내릴 수 있습니다. 이렇게 하면 태그 지정과 권한 정책을 결합하여 여러 사용자 지정 정책 없이도 세분화된 리소스 액세스를 달성할 수 있습니다.

최소 권한 정책 생성을 가속화하는 또 다른 방법은 활동 실행 후 CloudTrail 권한을 기반으로 정책을 수립하는 것입니다. [IAM Access Analyzer는 활동을 기반으로 IAM 정책을 자동으로 생성할 수 있습니다](https://aws.amazon.com/blogs/security/delegate-permission-management-to-developers-using-iam-permissions-boundaries/). 또한 조직 또는 개별 계정 수준에서 IAM Access Advisor를 사용하여 [특정 정책에 대해 마지막 액세스 정보를 추적](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor.html)할 수 있습니다.

이러한 세부 정보를 검토하고 불필요한 권한을 제거할 주기를 설정할 수 있습니다. AWS 조직 내 권한 가드레일을 설정하여 모든 멤버 계정 내에서 최대 권한을 제어해야 합니다. 서비스, 즉 [AWS Control Tower는 권장 관리형 예방 제어 기능](https://docs.aws.amazon.com/controltower/latest/userguide/guardrails.html) 이 있어 자체적인 제어를 정의할 수 있습니다. 

## 리소스
<a name="resources"></a>

 **관련 문서:** 
+  [IAM 엔터티의 권한 경계](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html) 
+  [최소 권한 IAM 정책 작성 기법](https://aws.amazon.com/blogs/security/techniques-for-writing-least-privilege-iam-policies/) 
+  [IAM Access Analyzer를 통해 액세스 활동에 기반한 IAM 정책을 생성하여 보다 쉽게 최소 권한을 구현](https://aws.amazon.com/blogs/security/iam-access-analyzer-makes-it-easier-to-implement-least-privilege-permissions-by-generating-iam-policies-based-on-access-activity/) 
+  [마지막 액세스 정보를 사용하여 권한 수정](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor.html) 
+  [IAM 정책 유형과 사용 시기](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) 
+  [IAM 정책 시뮬레이터로 IAM 정책 테스트](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_testing-policies.html) 
+  [AWS Control Tower의 가드레일](https://docs.aws.amazon.com/controltower/latest/userguide/guardrails.html) 
+  [제로 트러스트 아키텍처: AWS의 철학](https://aws.amazon.com/blogs/security/zero-trust-architectures-an-aws-perspective/) 
+  [CloudFormation StackSets로 최소 권한의 원칙을 구현하는 방법](https://aws.amazon.com/blogs/security/how-to-implement-the-principle-of-least-privilege-with-cloudformation-stacksets/) 

 **관련 동영상:** 
+  [차세대 권한 관리](https://www.youtube.com/watch?v=8vsD_aTtuTo) 
+  [제로 트러스트: AWS의 철학](https://www.youtube.com/watch?v=1p5G1-4s1r0) 
+  [권한 경계를 사용하여 IAM 사용자 및 역할을 제한하고 권한 승격을 방지하려면 어떻게 해야 하나요?](https://www.youtube.com/watch?v=omwq3r7poek) 

 **관련 예시:** 
+  [실습: 역할 생성을 위임하는 IAM 권한 경계](https://wellarchitectedlabs.com/Security/300_IAM_Permission_Boundaries_Delegating_Role_Creation/README.html) 

# SEC03-BP03 긴급 액세스 프로세스 설정
<a name="sec_permissions_emergency_process"></a>

 가능성은 낮지만 자동화된 프로세스 또는 파이프라인에 문제가 발생할 때 워크로드에 긴급 액세스할 수 있도록 하는 프로세스입니다. 이 긴급 액세스 프로세스를 통해 최소 권한 액세스를 사용할 수 있습니다. 그러나 사용자가 적절한 수준의 액세스 권한이 필요할 때는 해당 권한을 얻을 수 있습니다. 예를 들어, 관리자가 액세스를 위한 긴급 AWS 크로스 계정 역할 등의 요청을 확인하고 승인하는 프로세스 또는 관리자가 긴급 요청을 확인하고 승인하기 위해 따라야 하는 특정 프로세스를 설정합니다. 

 **일반적인 안티 패턴:** 
+ 기존 자격 증명 구성을 사용하여 중단으로부터 복구할 수 있는 긴급 프로세스가 없습니다.
+ 승격된 장기 권한을 문제 해결 또는 복구 목적으로 부여합니다.

 **이 모범 사례가 확립되지 않을 경우 노출되는 위험의 수준:** 보통 

## 구현 가이드
<a name="implementation-guidance"></a>

 긴급 액세스 설정은 여러 가지 형태일 수 있으며 이에 대비해야 합니다. 첫 번째는 기본 자격 증명 공급자의 실패입니다. 이 경우 복구에 필요한 권한을 통해 액세스의 두 번째 방법을 사용해야 합니다. 이 방법은 백업 자격 증명 공급자 또는 IAM 사용자일 수 있습니다. 이 두 번째 방법을 사용할 경우 [엄격한 제어, 모니터링 및 알림](https://aws.amazon.com/blogs/mt/monitor-and-notify-on-aws-account-root-user-activity/) 이 필요합니다. 긴급 액세스 자격 증명은 이 목적에 맞는 계정에서 생성되어야 하며 복구를 위해 특별히 설계된 역할을 수행할 수 있는 권한만 가지고 있어야 합니다. 

 또한 승격된 임시 관리 액세스가 필요할 경우에 대비하여 긴급 액세스를 준비해야 합니다. 일반적인 시나리오는 변경 사항을 배포하는 데 사용하는 자동 프로세스로 권한 변경을 제한하는 것입니다. 이 프로세스에 문제가 발생할 경우 사용자는 기능 복원을 위해 승격된 권한을 요청해야 할 수 있습니다. 이 경우, 사용자가 승격된 액세스를 요청할 수 있고 관리자가 이를 확인 및 승인할 수 있는 프로세스를 설정합니다. 구현 계획에는 사전 프로비저닝 액세스 및 긴급 설정, *브레이크 글라스*, 역할이 [SEC10-BP05 액세스 권한 사전 프로비저닝](sec_incident_response_pre_provision_access.md)의 일부로서 제공되며 이에 대한 모범 사례 지침이 자세히 설명되어 있습니다. 

## 리소스
<a name="resources"></a>

 **관련 문서:** 
+ [AWS 모니터링 및 알림](https://aws.amazon.com/blogs/mt/monitor-and-notify-on-aws-account-root-user-activity) 
+ [임시 승격된 액세스 관리](https://aws.amazon.com/blogs/security/managing-temporary-elevated-access-to-your-aws-environment/) 

 **관련 동영상:** 
+  [60분 이내에 IAM 정책 마스터하기](https://youtu.be/YQsK4MtsELU) 

# SEC03-BP04 지속적으로 권한 축소
<a name="sec_permissions_continuous_reduction"></a>

 팀 및 워크로드가 필요한 액세스 권한을 결정할 때 더 이상 사용하지 않는 권한을 제거하고 최소 권한을 부여하기 위한 검토 프로세스를 설정합니다. 사용하지 않는 자격 증명 및 권한을 지속적으로 모니터링하고 줄입니다. 

팀과 프로젝트를 막 시작하는 경우, 혁신과 민첩성을 이끌어내기 위해 광범위한 액세스 권한(개발 또는 테스트 환경에서)을 부여하고자 하는 경우가 있습니다. 특히 프로덕션 환경에서 액세스를 지속적으로 평가하고, 필요한 권한에 대해서만 제한적으로 액세스를 부여하고, 최소 권한을 구현하는 것을 권장합니다. AWS에서는 사용되지 않는 액세스를 파악할 수 있도록 액세스 분석 기능을 제공합니다. AWS에서 액세스 활동을 분석하여 액세스 키와 역할이 마지막으로 사용된 사례의 정보를 제공하므로 미사용된 사용자와 역할, 권한, 보안 인증 정보를 파악하는 데 도움이 됩니다. 즉 [마지막으로 액세스한 타임스탬프](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor-view-data.html) 을 [를 사용하면 미사용된 사용자와 역할을 파악하여](http://aws.amazon.com/blogs/security/identify-unused-iam-roles-remove-confidently-last-used-timestamp/)제거할 수 있습니다. 또한 서비스와 작업의 마지막 액세스 정보를 검토하면 [특정 사용자와 역할을 대상으로 권한을 강화할 수도 있습니다.](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor.html). 예를 들어 마지막 액세스 정보를 사용하면 애플리케이션 역할에 필요한 특정 Amazon Simple Storage Service(Amazon S3) 작업을 파악하여 그러한 작업에 대해서만 액세스를 제한할 수 있습니다. 이러한 기능은 AWS Management Console에서 프로그램 방식으로 제공되므로 인프라 워크플로 및 자동화된 도구에 손쉽게 통합할 수 있습니다.

 **이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 보통 

## 구현 가이드
<a name="implementation-guidance"></a>
+  AWS Identity and Access Management(IAM) Access Analyzer 구성: AWS IAM Access Analyzer를 사용하면 Amazon Simple Storage Service(Amazon S3) 버킷 또는 IAM 역할과 같은 조직 및 계정 내 리소스 중 외부 엔터티와 공유되는 리소스를 식별할 수 있습니다. 
  + [AWS IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html) 

## 리소스
<a name="resources"></a>

 **관련 문서:** 
+  [ABAC(속성 기반 액세스 제어)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) 
+  [최소 권한 부여](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege) 
+  [불필요한 자격 증명 삭제](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#remove-credentials) 
+  [정책 사용](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage.html) 

 **관련 동영상:** 
+  [60분 이내에 IAM 정책 마스터하기](https://youtu.be/YQsK4MtsELU) 
+  [업무 분리, 최소 권한, 위임 및 CI/CD](https://youtu.be/3H0i7VyTu70) 

# SEC03-BP05 조직에 대한 권한 가드레일 정의
<a name="sec_permissions_define_guardrails"></a>

 조직의 모든 자격 증명에 대한 액세스를 제한하는 공통 제어를 설정합니다. 예를 들어, 특정 AWS 리전에 대한 액세스를 제한하거나 중앙 보안 팀에 사용되는 IAM 역할과 같은 공통 리소스를 운영자가 삭제하지 못하게 할 수 있습니다. 

 **일반적인 안티 패턴:** 
+ 조직의 관리자 계정에서 워크로드를 실행합니다. 
+ 프로덕션과 비 프로덕션 워크로드를 동일한 계정에서 실행합니다. 

 **이 모범 사례가 확립되지 않을 경우 노출되는 위험의 수준:** 보통 

## 구현 가이드
<a name="implementation-guidance"></a>

 AWS에서 추가 워크로드를 확장하고 관리하면서, 계정을 사용하여 이러한 워크로드를 분리하고 AWS Organizations를 사용하여 해당 계정을 관리해야 합니다. 이 경우 조직 내 모든 자격 증명에 대한 액세스를 제한하는 공통 권한 가드레일을 설정하는 것이 좋습니다. 예를 들어, 특정 AWS 리전에 대한 액세스를 제한하거나 중앙 보안팀이 사용하는 IAM 역할과 같은 공통 리소스를 팀에서 삭제하지 못하게 할 수 있습니다. 

 사용자가 주요 서비스를 비활성화하지 못하도록 방지하는 등 서비스 제어 정책 예시를 구현하는 것부터 시작할 수 있습니다. SCP는 IAM 정책 언어를 사용하여 모든 IAM 보안 주체(사용자 및 역할)가 준수하는 제어를 설정할 수 있습니다. 특정 서비스 작업과 리소스에 대한 액세스를 제한하거나, 조직의 액세스 제어 요구 사항에 부합하도록 특정 조건을 기반으로 액세스를 제한할 수 있습니다. 필요한 경우, 가드레일에 예외를 정의할 수 있습니다. 예를 들어, 주어진 계정에서 특정 관리자 역할을 제외한 모든 IAM 엔터티에 대해 서비스 작업을 제한할 수 있습니다. 

 관리 계정에서 워크로드를 실행하지 않는 것이 좋습니다. 관리 계정은 멤버 계정에 영향을 미치는 보안 가드레일을 관리 및 배포하는 데 사용해야 합니다. 일부 AWS 서비스는 위임된 관리자 계정의 사용을 지원합니다. 가능한 경우, 이 위임된 계정을 관리 계정 대신 사용해야 합니다. 조직의 관리자 계정에 대한 액세스는 강력하게 제한해야 합니다. 

다중 계정 전략을 사용하면 워크로드에 가드레일을 훨씬 더 유연하게 적용할 수 있습니다. AWS Security Reference Architecture는 계정 구조 설계 방법에 대한 권장 가이드를 제공합니다. AWS Control Tower와 같은 AWS 서비스는 조직 전체에 대한 사전 예방 제어와 탐지 제어 모두를 중앙에서 관리할 수 있는 기능을 제공합니다. 조직 내 각 계정 또는 OU에 대한 명확한 목적을 정의하고 해당 목적에 따라 제어를 제한합니다. 

## 리소스
<a name="resources"></a>

 **관련 문서:** 
+ [AWS Organizations](https://aws.amazon.com/organizations/) 
+ [서비스 제어 정책(SCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) 
+ [다중 계정 환경에서 서비스 제어 정책 최대한 활용](https://aws.amazon.com/blogs/security/get-more-out-of-service-control-policies-in-a-multi-account-environment/) 
+ [AWS Security Reference Architecture(AWS SRA)](https://docs.aws.amazon.com/prescriptive-guidance/latest/security-reference-architecture/welcome.html) 

 **관련 동영상:** 
+ [서비스 제어 정책을 사용한 예방적 가드레일 적용](https://www.youtube.com/watch?v=mEO05mmbSms) 
+  [AWS Control Tower를 통해 대규모 거버넌스 구축](https://www.youtube.com/watch?v=Zxrs6YXMidk) 
+  [AWS Identity and Access Management 심층 분석](https://www.youtube.com/watch?v=YMj33ToS8cI) 

# SEC03-BP06 수명 주기에 따라 액세스 관리
<a name="sec_permissions_lifecycle"></a>

 액세스 제어를 운영자 및 애플리케이션 수명 주기/중앙 집중식 페더레이션 공급자와 통합합니다. 예를 들어 조직에서 나가거나 역할이 변경될 때 사용자의 액세스 권한을 제거합니다. 

워크로드를 관리할 때 별도의 여러 계정을 사용하다 보면, 해당 계정 간에 리소스를 공유해야 하는 경우가 있습니다. 리소스를 공유할 때는 [AWS Resource Access Manager(AWS RAM)를 사용하는 것이 좋습니다.](http://aws.amazon.com/ram/). 이 서비스를 사용하면 AWS Organizations 및 조직 단위 내에서 AWS 리소스를 쉽고 안전하게 공유할 수 있습니다. AWS RAM을 사용하면 리소스를 공유하는 조직이나 조직 단위에서의 계정 포함 여부에 따라 공유 리소스에 대한 액세스 권한이 자동으로 부여되거나 취소됩니다. 이렇게 하면 리소스를 원하는 계정끼리만 공유하도록 할 수 있습니다.

 **이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 낮음 

## 구현 가이드
<a name="implementation-guidance"></a>

 사용자 액세스 수명 주기 현재 사용자만 액세스할 수 있도록 시설의 신규 참여 사용자, 직무 기능 변경, 퇴거 사용자에 적용할 사용자 액세스 수명 주기 정책을 구현합니다. 

## 리소스
<a name="resources"></a>

 **관련 문서:** 
+  [ABAC(속성 기반 액세스 제어)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) 
+  [최소 권한 부여](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege) 
+  [IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html) 
+  [불필요한 자격 증명 삭제](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#remove-credentials) 
+  [정책 사용](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage.html) 

 **관련 동영상:** 
+  [60분 이내에 IAM 정책 마스터하기](https://youtu.be/YQsK4MtsELU) 
+  [업무 분리, 최소 권한, 위임 및 CI/CD](https://youtu.be/3H0i7VyTu70) 

# SEC03-BP07 퍼블릭 및 크로스 계정 액세스 분석
<a name="sec_permissions_analyze_cross_account"></a>

퍼블릭 및 크로스 계정 액세스를 강조하는 결과를 지속적으로 모니터링합니다. 이 유형의 액세스가 필요한 리소스에 대해서만 퍼블릭 액세스 및 크로스 계정 액세스를 줄입니다. 

 **일반적인 안티 패턴:** 
+  크로스 계정에 대한 액세스 및 리소스에 대한 퍼블릭 액세스를 관리하는 프로세스를 따르지 않습니다. 

 **이 모범 사례가 확립되지 않을 경우 노출되는 위험의 수준:** 낮음 

## 구현 가이드
<a name="implementation-guidance"></a>

AWS에서는 다른 계정의 리소스에 대한 액세스 권한을 부여할 수 있습니다. 리소스에 연결된 정책(예: [Amazon Simple Storage Service(Amazon S3) 버킷 정책](https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucket-policies.html)을 사용하거나 자격 증명이 다른 계정에서 IAM 역할을 수임하도록 허용하여 다른 계정의 직접 액세스를 허용합니다. 리소스 정책을 사용하는 경우, 조직의 자격 증명에 액세스 권한이 부여되었는지, 그리고 사용자가 리소스를 공개하려는 의도인지 확인해야 합니다. 공개적으로 사용 가능해야 하는 모든 리소스를 승인하는 프로세스를 정의합니다. 

 [IAM Access Analyzer](https://aws.amazon.com/iam/features/analyze-access/) 는 [증명 가능한 보안](https://aws.amazon.com/security/provable-security/) 을 사용하여 자격 증명에 계정 외부의 리소스에 대한 전체적인 액세스 경로를 제공합니다. 따라서 리소스 정책을 지속적으로 검토하고, 퍼블릭 또는 크로스 계정 액세스 결과를 보고하여 잠재적인 광범위한 액세스를 쉽게 분석할 수 있습니다. AWS Organizations에서 IAM Access Analyzer를 구성하여 모든 계정에 대한 가시성을 확인합니다. 또한 IAM Access Analyzer를 사용하면 리소스 사용 권한을 배포하기 전에 [Access Analyzer 결과를 미리 보기](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-access-preview.html)도 가능합니다. 따라서 정책 변경 사항이 리소스에 대해 의도한 퍼블릭 및 크로스 계정 액세스만 부여하는지 확인할 수 있습니다. 다중 계정 액세스를 설계할 경우 [역할을 수임할 수 있는 경우를 제어하는 신뢰 정책](https://aws.amazon.com/blogs/security/how-to-use-trust-policies-with-iam-roles/)을 사용할 수 있습니다. 예를 들어, 특정 소스 IP 범위로 역할 수임을 제한할 수 있습니다. 

 또한 실수로 인한 퍼블릭 액세스 구성에 대해 [AWS Config를 사용하여 리소스를 보고 및 개선](https://docs.aws.amazon.com/config/latest/developerguide/operational-best-practices-for-Publicly-Accessible-Resources.html) 할 수 있으며, 이 경우 AWS Config 정책 확인을 사용합니다. 또한 [AWS Control Tower](https://aws.amazon.com/controltower) 및 [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-standards-fsbp.html) 와 같은 서비스는 AWS Organizations 전체에 검사 및 가드레일을 배포하기만 하면 공개적으로 노출된 리소스를 파악 및 개선할 수 있습니다. 예를 들어, AWS Control Tower는 [Amazon EBS 스냅샷이 모든 AWS 계정에 의해 복원 가능한지](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html)탐지할 수 있는 관리형 가드레일을 보유합니다.

## 리소스
<a name="resources"></a>

 **관련 문서:** 
+  [AWS Identity and Access Management Access Analyzer 사용](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html?ref=wellarchitected)
+  [AWS Control Tower의 가드레일](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html) 
+  [AWS 기초 보안 모범 사례 표준](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-standards-fsbp.html)
+  [AWS Config 관리형 규칙](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config_use-managed-rules.html) 
+  [AWS Trusted Advisor 확인 참조](https://docs.aws.amazon.com/awssupport/latest/user/trusted-advisor-check-reference.html) 

 **관련 동영상:** 
+ [다중 계정 환경 보안 모범 사례](https://www.youtube.com/watch?v=ip5sn3z5FNg)
+ [IAM Access Analyzer 심층 분석](https://www.youtube.com/watch?v=i5apYXya2m0)

# SEC03-BP08 안전하게 리소스 공유
<a name="sec_permissions_share_securely"></a>

 계정 전체에 걸쳐 또는 AWS Organizations 내에서 공유된 리소스의 사용을 관리합니다. 공유 리소스를 모니터링하고 공유 리소스 액세스를 검토합니다. 

 **일반적인 안티 패턴:** 
+  서드파티 크로스 계정 액세스 권한을 부여할 때 기본 IAM 신뢰 정책을 사용합니다. 

 **이 모범 사례가 확립되지 않을 경우 노출되는 위험의 수준:** 낮음 

## 구현 가이드
<a name="implementation-guidance"></a>

 여러 AWS 계정을 사용하여 워크로드를 관리할 경우 계정 간에 리소스를 공유해야 할 수 있습니다. 이것은 흔히 AWS Organizations 내에서 공유되는 크로스 계정 공유입니다. 여러 AWS 서비스, 즉 [AWS Security Hub CSPM](https://docs.aws.amazon.com/organizations/latest/userguide/services-that-can-integrate-securityhub.html), [Amazon GuardDuty](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_organizations.html) 및 [AWS Backup](https://docs.aws.amazon.com/organizations/latest/userguide/services-that-can-integrate-backup.html) 은 Organizations와 통합되는 크로스 계정 기능이 있습니다. 이때 [AWS Resource Access Manager](https://aws.amazon.com/ram/) 를 사용하여 기타 일반적인 리소스, 즉 [VPC 서브넷 또는 Transit Gateway Attachment](https://docs.aws.amazon.com/ram/latest/userguide/shareable.html#shareable-vpc), [AWS Network Firewall](https://docs.aws.amazon.com/ram/latest/userguide/shareable.html#shareable-network-firewall)또는 [Amazon SageMaker Runtime 파이프라인](https://docs.aws.amazon.com/ram/latest/userguide/shareable.html#shareable-sagemaker)을 공유합니다. 계정이 Organizations 내 리소스만 공유하도록 하려면 [서비스 제어 정책(SCP)](https://docs.aws.amazon.com/ram/latest/userguide/scp.html) 을 사용하여 외부 보안 주체에 대한 액세스를 방지하는 것이 좋습니다.

 리소스를 공유할 때는 의도하지 않은 액세스로부터 보호할 수 있는 조치를 마련해야 합니다. 이를 위해 자격 증명 기반 제어와 네트워크 제어를 결합하여 [조직의 데이터 경계를 생성](https://docs.aws.amazon.com/whitepapers/latest/building-a-data-perimeter-on-aws/building-a-data-perimeter-on-aws.html)하는 것을 권장합니다. 이러한 제어를 통해 어떤 리소스를 공유할 수 있는지에 대한 엄격한 제한을 설정하고, 리소스의 허용되지 않은 공유 또는 노출을 예방할 수 있습니다. 예를 들어, 데이터 경계의 일부로 VPC 엔드포인트 정책 및 `aws:PrincipalOrgId` 조건을 사용하여 Amazon S3 버킷에 액세스하는 자격 증명이 조직 내에 속한 것인지 확인할 수 있습니다. 

 경우에 따라 Organizations 외부 리소스의 공유를 허용하거나 사용자의 계정에 서드파티 액세스 권한을 부여해야 할 수 있습니다. 예를 들어, 파트너가 사용자의 계정 내 리소스에 액세스해야 하는 모니터링 솔루션을 제공할 수 있습니다. 이 경우, 서드파티에만 필요한 권한이 포함된 IAM 크로스 계정 역할을 생성해야 합니다. 또한 [외부 ID 조건](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user_externalid.html)을 사용하여 신뢰 정책을 만들어야 합니다. 외부 ID를 사용할 경우 각 서드파티를 위한 고유 ID를 생성해야 합니다. 고유 ID는 서드파티가 공급하거나 제어할 수 없습니다. 서드파티가 더 이상 환경에 액세스할 필요가 없다면 역할을 제거해야 합니다. 또한 어떠한 경우라도 서드파티에 장기 IAM 보안 인증을 제공하지 않아야 합니다. 기본적으로 공유를 지원하는 다른 AWS 서비스를 계속 인지하고 있어야 합니다. 예를 들어, AWS Well-Architected Tool에서 [워크로드 공유](https://docs.aws.amazon.com/wellarchitected/latest/userguide/workloads-sharing.html) 로 다른 AWS 계정과의 공유를 허용할 수 있습니다. 

 Amazon S3와 같은 서비스를 사용할 경우 [Amazon S3 버킷에 대한 ACL을 비활성화](https://docs.aws.amazon.com/AmazonS3/latest/userguide/about-object-ownership.html) 하고 IAM 정책을 사용하여 액세스 제어를 정의하는 것이 좋습니다. [Amazon S3 오리진에](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-restricting-access-to-s3.html) 대한 액세스를 [Amazon CloudFront](https://aws.amazon.com/cloudfront/)에서 제한하려면 오리진 액세스 ID(OAI)에서 [AWS KMS](https://aws.amazon.com/kms/)를 통한 서버 측 암호화를 비롯한 추가 기능을 지원하는 오리진 액세스 제어(OAC)로 마이그레이션하세요.

## 리소스
<a name="resources"></a>

 **관련 문서:** 
+ [버킷 소유자가 소유하지 않은 객체에 크로스 계정 권한 부여](https://docs.aws.amazon.com/AmazonS3/latest/userguide/example-walkthroughs-managing-access-example4.html)
+ [IAM을 통한 신뢰 정책 사용 방법](https://aws.amazon.com/blogs/security/how-to-use-trust-policies-with-iam-roles/)
+ [AWS에 데이터 경계 구축](https://docs.aws.amazon.com/whitepapers/latest/building-a-data-perimeter-on-aws/building-a-data-perimeter-on-aws.html)
+ [AWS 리소스에 대한 서드파티 액세스 권한을 부여할 때 외부 ID를 사용하는 방법](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user_externalid.html)

 **관련 동영상:** 
+ [AWS Resource Access Manager를 통한 세분화된 액세스](https://www.youtube.com/watch?v=X3HskbPqR2s)
+ [VPC 엔드포인트를 통한 데이터 경계 보호](https://www.youtube.com/watch?v=iu0-o6hiPpI)
+ [AWS에 데이터 경계 설정 ](https://www.youtube.com/watch?v=SMi5OBjp1fI)