# 자격 증명 및 액세스 관리
AWS 서비스를 사용하려면 사용자와 애플리케이션에 AWS 계정 내 리소스에 대한 액세스 권한을 부여해야 합니다. AWS에서 더 많은 워크로드를 실행할 경우 적절한 사람이 적절한 조건에서 적절한 리소스에 액세스할 수 있도록 강력한 자격 증명 관리 및 권한이 필요합니다. AWS는 인력 및 시스템 자격 증명과 그 권한을 관리하는 데 도움이 되는 다양한 기능을 제공합니다. 이러한 기능에 대한 모범 사례는 두 가지 주요 영역으로 나뉩니다.
**Topics**
+ [자격 증명 관리](identity-management.md)
+ [권한 관리](permissions-management.md)
# 자격 증명 관리
보안 AWS 워크로드를 운영할 때는 두 가지 유형의 ID를 관리해야 합니다.
+ **인적 자격 증명:** AWS 환경 및 애플리케이션에 액세스해야 하는 인적 자격 증명은 인력, 서드파티 및 사용자라는 세 그룹으로 분류할 수 있습니다.
*인력* 그룹에는 조직의 구성원인 관리자, 개발자 및 운영자가 포함됩니다. 이들이 AWS 리소스를 관리, 구축 및 운영하려면 액세스 권한이 필요합니다.
*서드파티*는 계약업체, 공급업체 또는 파트너와 같은 외부 협력자입니다. 이들은 계약의 일환으로 AWS 리소스와 상호 작용합니다.
*사용자*는 애플리케이션의 소비자입니다. 이들은 웹 브라우저, 클라이언트 애플리케이션, 모바일 앱 또는 대화형 명령줄 도구를 통해 AWS 리소스에 액세스합니다.
+ **머신 자격 증명:** 워크로드 애플리케이션, 운영 도구 및 구성 요소에서 AWS 서비스에 요청을 하려면(예: 데이터 읽기) 자격 증명이 필요합니다. 이러한 자격 증명에는 AWS 환경에서 실행되는 머신이 포함됩니다(예: Amazon EC2 인스턴스 또는 AWS Lambda 함수). 외부 당사자 또는 AWS 환경에 액세스해야 하는 AWS 외부 머신의 머신 자격 증명을 관리할 수도 있습니다.
**Topics**
+ [SEC02-BP01 강력한 로그인 메커니즘 사용](sec_identities_enforce_mechanisms.md)
+ [SEC02-BP02 임시 자격 증명 사용](sec_identities_unique.md)
+ [SEC02-BP03 안전하게 보안 암호 저장 및 사용](sec_identities_secrets.md)
+ [SEC02-BP04 중앙 집중식 ID 공급업체 사용](sec_identities_identity_provider.md)
+ [SEC02-BP05 정기적으로 자격 증명 감사 및 교체](sec_identities_audit.md)
+ [SEC02-BP06 사용자 그룹 및 속성 사용](sec_identities_groups_attributes.md)
# SEC02-BP01 강력한 로그인 메커니즘 사용
로그인(로그인 자격 증명을 사용한 인증)은 다중 인증(MFA)과 같은 메커니즘을 사용하지 않을 때, 특히 로그인 자격 증명이 의도치 않게 공개되었거나 쉽게 추측되는 상황에서 위험을 초래할 수 있습니다. 강력한 로그인 메커니즘을 사용하면 MFA 및 강력한 암호 정책을 요구하여 이러한 위험을 줄일 수 있습니다.
**원하는 성과:** [AWS Identity and Access Management(IAM)](https://aws.amazon.com/iam/) 사용자, [AWS 계정 루트 사용자](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html), [AWS IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html), 서드파티 ID 제공업체에 대한 강력한 로그인 메커니즘을 사용하여 AWS의 자격 증명에 대한 의도치 않은 액세스 위험을 줄입니다. 즉, MFA를 요구하고 강력한 암호 정책을 적용하며 비정상적인 로그인 동작을 감지합니다.
**일반적인 안티 패턴**:
+ 복잡한 암호 및 MFA를 포함하여 자격 증명에 대한 강력한 암호 정책을 적용하지 않습니다.
+ 다른 사용자 간에 동일한 자격 증명을 공유합니다.
+ 의심스러운 로그인에 대한 탐지 제어를 사용하지 않습니다.
**이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 높음
## 구현 지침
인적 자격 증명으로 AWS에 로그인하는 방법에는 몇 가지가 있습니다. AWS에 인증할 때 페더레이션(AWS IAM과 중앙 집중화된 IdP 간의 직접 SAML 2.0 페더레이션 또는 AWS IAM Identity Center 사용)을 사용하는 중앙 집중식 ID 제공업체를 사용하는 것이 AWS 모범 사례입니다. 이 경우 ID 제공업체 또는 Microsoft Active Directory를 사용하여 보안 로그인 프로세스를 설정합니다.
AWS 계정을 처음 열면 AWS 계정 루트 사용자로 시작합니다. 루트 사용자 계정은 사용자(및 [루트 사용자가 필요한 작업](https://docs.aws.amazon.com/accounts/latest/reference/root-user-tasks.html))에 대한 액세스 권한을 설정할 때만 사용해야 합니다. AWS 계정을 개설한 직후에는 계정 루트 사용자에 대해 다중 인증(MFA)을 활성화하고 [AWS 모범 사례 가이드](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_securely_operate_aws_account.html)를 사용하여 루트 사용자를 보호하는 것이 중요합니다.
AWS IAM Identity Center는 인력 사용자를 위해 설계되었으며 서비스 내에서 사용자 ID를 생성 및 관리하고 MFA로 로그인 프로세스를 보호할 수 있습니다. 반면 AWS Cognito는 애플리케이션의 외부 사용자 ID에 대한 사용자 풀 및 ID 제공업체를 제공하는 고객 ID 및 액세스 관리(CIAM)용으로 설계되었습니다.
AWS IAM Identity Center에서 사용자를 생성하는 경우 해당 서비스에서 로그인 프로세스를 보호하고 [MFA를 켭니다](https://docs.aws.amazon.com/singlesignon/latest/userguide/enable-mfa.html). 애플리케이션의 외부 사용자 ID의 경우 [Amazon Cognito 사용자 풀](https://docs.aws.amazon.com/cognito/index.html)을 사용하고 해당 서비스에서 로그인 프로세스를 보호하거나 Amazon Cognito 사용자 풀이 지원하는 ID 제공업체 중 하나를 사용할 수 있습니다.
또한 AWS IAM Identity Center의 사용자의 경우 AWS 리소스에 대한 액세스 권한을 부여하기 전에 [AWS Verified Access](https://docs.aws.amazon.com/verified-access/latest/ug/what-is-verified-access.html)를 사용하여 사용자의 자격 증명 및 디바이스 태세를 확인하여 추가 보안 계층을 제공할 수 있습니다.
[AWS Identity and Access Management(IAM)](https://aws.amazon.com/iam/) 사용자를 사용하는 경우 IAM을 사용하여 로그인 프로세스를 보호합니다.
AWS IAM Identity Center와 직접 IAM 페더레이션을 동시에 사용하여 AWS에 대한 액세스를 관리할 수 있습니다. IAM 페더레이션을 사용하여 AWS Management Console 및 서비스에 대한 액세스를 관리하고 IAM Identity Center를 사용하여 Quick 또는 Amazon Q Business와 같은 비즈니스 애플리케이션에 대한 액세스를 관리할 수 있습니다.
로그인 방법에 관계없이 강력한 로그인 정책을 적용하는 것이 중요합니다.
### 구현 단계
다음은 일반적인 강력한 로그인 권장 사항입니다. 구성하는 실제 설정은 회사 정책에 따라 설정하거나 [NIST 800-63](https://pages.nist.gov/800-63-3/sp800-63b.html)과 같은 표준을 사용해야 합니다.
+ MFA 필수(Require MFA). 사람의 ID 및 워크로드에 [MFA를 요구하는 것이 IAM 모범 사례](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#enable-mfa-for-privileged-users)입니다. MFA를 활성화하면 사용자가 로그인 자격 증명과 일회용 암호(OTP) 또는 하드웨어 디바이스에서 암호로 확인 및 생성된 문자열을 제공해야 하는 추가 보안 계층이 제공됩니다.
+ 암호 강도의 기본 요소인 최소 암호 길이를 적용합니다.
+ 암호 복잡성을 적용하여 암호를 추측하기 어렵게 만듭니다.
+ 사용자에게 자신의 암호를 변경할 수 있도록 허용
+ 공유 자격 증명 대신 개별 자격 증명을 생성합니다. 개별 자격 증명을 생성하여 각 사용자에게 고유한 보안 자격 증명 세트를 제공할 수 있습니다. 개별 사용자는 각 사용자의 활동을 감사할 수 있는 기능을 제공합니다.
IAM Identity Center 권장 사항:
+ IAM Identity Center는 암호 길이, 복잡성 및 재사용 요구 사항을 설정하는 기본 디렉터리를 사용할 때 미리 정의된 [암호 정책](https://docs.aws.amazon.com/singlesignon/latest/userguide/password-requirements.html)을 제공합니다.
+ [MFA를 활성화](https://docs.aws.amazon.com/singlesignon/latest/userguide/mfa-enable-how-to.html)하고 자격 증명 소스가 기본 디렉터리, AWS Managed Microsoft AD 또는 AD Connector인 경우 MFA에 대한 컨텍스트 인식 또는 상시 설정을 구성합니다.
+ 사용자가 [자신의 MFA 디바이스를 등록](https://docs.aws.amazon.com/singlesignon/latest/userguide/how-to-allow-user-registration.html)하도록 허용합니다.
Amazon Cognito 사용자 풀 디렉터리 권장 사항:
+ [암호 강도](https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-settings-policies.html) 설정을 구성합니다.
+ 사용자에게 [MFA를 요청](https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-settings-mfa.html)합니다.
+ Amazon Cognito 사용자 풀의 [고급 보안 설정](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pool-settings-advanced-security.html)을 사용하여 의심되는 로그인을 차단할 수 있는 [적응형 인증](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pool-settings-adaptive-authentication.html)과 같은 기능을 사용합니다.
IAM 사용자 권장 사항:
+ IAM Identity Center 또는 직접 페더레이션을 사용하는 것이 좋습니다. 그러나 IAM 사용자가 필요할 수 있습니다. 이 경우 IAM 사용자에 대한 [암호 정책](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_passwords_account-policy.html)을 설정합니다. 암호 정책을 사용하여 최소 길이 또는 알파벳 이외 문자 포함 여부 등과 같은 요구 사항을 정의할 수 있습니다.
+ [MFA 로그인을 적용](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_users-self-manage-mfa-and-creds.html#tutorial_mfa_step1)하도록 IAM 정책을 생성합니다. 그러면 사용자가 자신의 암호와 MFA 디바이스를 관리할 수 있습니다.
## 리소스
**관련 모범 사례:**
+ [SEC02-BP03 안전하게 보안 암호 저장 및 사용](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_secrets.html)
+ [SEC02-BP04 중앙 집중식 ID 공급업체 사용](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_identity_provider.html)
+ [SEC03-BP08 안전하게 조직과 리소스 공유](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_share_securely.html)
**관련 문서:**
+ [AWS IAM Identity Center 암호 정책](https://docs.aws.amazon.com/singlesignon/latest/userguide/password-requirements.html)
+ [IAM 사용자의 암호 정책](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_passwords_account-policy.html)
+ [AWS 계정 루트 사용자 암호 설정](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html)
+ [Amazon Cognito password policy](https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-settings-policies.html)
+ [AWS 보안 인증 정보](https://docs.aws.amazon.com/general/latest/gr/aws-sec-cred-types.html)
+ [ IAM 보안 모범 사례](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)
**관련 비디오:**
+ [Managing user permissions at scale with AWS IAM Identity Center](https://youtu.be/aEIqeFCcK7E)
+ [Mastering identity at every layer of the cake](https://www.youtube.com/watch?v=vbjFjMNVEpc)
# SEC02-BP02 임시 자격 증명 사용
모든 유형의 인증을 수행할 때 자격 증명이 의도치 않게 공개되거나 공유되거나 도난당하는 위험을 줄이거나 제거하기 위해 장기 자격 증명 대신 임시 자격 증명을 사용하는 것이 가장 좋습니다.
**원하는 성과:** 장기 자격 증명의 위험을 줄이려면 가능한 한 인적 자격 증명과 시스템 자격 증명 모두에 대해 임시 자격 증명을 사용합니다. 장기 자격 증명은 퍼블릭 리포지토리에 대한 업로드를 통한 노출과 같은 많은 위험을 초래합니다. 임시 자격 증명을 사용하면 자격 증명이 손상될 가능성이 크게 줄어듭니다.
**일반적인 안티 패턴**:
+ 개발자가 페더레이션을 사용하여 CLI에서 임시 자격 증명을 획득하는 대신 IAM 사용자의 장기 액세스 키를 사용합니다.
+ 개발자가 장기 액세스 키를 코드에 포함하고 해당 코드를 퍼블릭 Git 리포지토리에 업로드합니다.
+ 개발자가 앱 스토어에서 사용할 수 있도록 장기 액세스 키를 모바일 앱에 포함합니다.
+ 사용자가 다른 사용자와 장기 액세스 키를 공유하거나 직원이 장기 액세스 키를 소유한 상태로 퇴사합니다.
+ 임시 자격 증명을 사용할 수 있는 경우에도 시스템 자격 증명에 장기 액세스 키를 사용합니다.
**이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 높음
## 구현 지침
모든 AWS API 및 CLI 요청에 대해 장기 자격 증명 대신 임시 자격 증명을 사용합니다. AWS 서비스에 대한 API 및 CLI 요청은 거의 모든 경우에 [AWS 액세스 키](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html)를 사용하여 서명해야 합니다. 이러한 요청은 임시 또는 장기 자격 증명으로 서명할 수 있습니다. 장기 액세스 키라고도 하는 장기 자격 증명을 사용해야 하는 유일한 경우는 [IAM 사용자](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html) 또는 [AWS 계정 루트 사용자](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html)를 사용하는 경우입니다. 다른 방법을 통해 AWS에 페더레이션하거나 [IAM 역할](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)을 수임할 때 임시 자격 증명이 생성됩니다. 로그인 자격 증명을 사용하여 AWS Management Console에 액세스하는 경우에도 AWS 서비스를 직접 호출할 수 있도록 임시 자격 증명이 생성됩니다. 장기 자격 증명이 필요한 경우는 거의 없으며 임시 자격 증명을 사용하여 대부분의 작업을 수행할 수 있습니다.
임시 자격 증명을 선호하여 장기 자격 증명 사용을 피하는 것은 페더레이션 및 IAM 역할과 함께 IAM 사용자의 사용을 줄이는 전략과 함께 수행해야 합니다. 과거에는 IAM 사용자가 인적 자격 증명과 시스템 자격 증명 모두에 사용되었지만 이제는 장기 액세스 키 사용의 위험을 피하기 위해 사용하지 않는 것이 좋습니다.
### 구현 단계
#### 인적 자격 증명
직원, 관리자, 개발자, 운영자와 같은 인적 자격 증명의 경우:
+ [중앙 집중식 ID 제공업체를 사용](https://docs.aws.amazon.com//wellarchitected/latest/security-pillar/sec_identities_identity_provider.html)해야 하며 [인적 사용자가 임시 자격 증명을 사용하여 AWS에 액세스하려면 ID 제공업체와의 페더레이션을 사용해야 합니다.](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp) 사용자에 대한 페더레이션은 각 [AWS 계정에 대한 직접 페더레이션](https://aws.amazon.com/identity/federation/)을 사용하거나 [AWS IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html) 및 선택한 ID 제공업체를 사용하여 수행할 수 있습니다. 페더레이션은 장기 자격 증명을 제거하는 것 외에도 IAM 사용자를 사용하는 것보다 많은 이점을 제공합니다. 사용자는 [직접 페더레이션](https://aws.amazon.com/blogs/security/how-to-implement-federated-api-and-cli-access-using-saml-2-0-and-ad-fs/)을 위해 명령줄에서 또는 [IAM Identity Center](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-sso.html)를 사용하여 임시 자격 증명을 요청할 수도 있습니다. 즉, IAM 사용자 또는 사용자에 대한 장기 자격 증명이 필요한 사용 사례가 거의 없습니다.
서드파티 자격 증명의 경우:
+ 서비스형 소프트웨어(SaaS) 공급자와 같은 서드파티에 AWS 계정의 리소스에 대한 액세스 권한을 부여할 때 [크로스 계정 역할](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html) 및 [리소스 기반 정책](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_identity-vs-resource.html)을 사용할 수 있습니다. 또한 B2B SaaS 고객 또는 파트너를 위한 [Amazon Cognito OAuth 2.0 권한 부여](https://docs.aws.amazon.com/cognito/latest/developerguide/federation-endpoints-oauth-grants.html) 클라이언트 자격 증명 흐름을 사용할 수 있습니다.
웹 브라우저, 클라이언트 애플리케이션, 모바일 앱 또는 대화형 명령줄 도구를 통해 AWS 리소스에 액세스하는 사용자 자격 증명:
+ 소비자 또는 고객에게 AWS 리소스에 대한 액세스 권한을 부여해야 하는 경우 [Amazon Cognito 자격 증명 풀](https://docs.aws.amazon.com/cognito/latest/developerguide/identity-pools.html) 또는 [Amazon Cognito 사용자 풀](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-identity-pools.html)을 사용하여 임시 자격 증명을 제공할 수 있습니다. 자격 증명의 권한은 IAM 역할을 통해 제어됩니다. 인증되지 않은 게스트 사용자의 권한이 제한된 개별 IAM 역할을 정의할 수도 있습니다.
#### 기계 자격 증명
시스템 자격 증명의 경우 장기 자격 증명을 사용해야 할 수 있습니다. 이 경우 [AWS에 액세스하려면 워크로드에 IAM 역할이 있는 임시 자격 증명을 사용하도록 요구](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-workloads-use-roles)해야 합니다.
+ [Amazon Elastic Compute Cloud](https://aws.amazon.com/pm/ec2/)(Amazon EC2)의 경우 [Amazon EC2의 역할](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2.html)을 사용할 수 있습니다.
+ [https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html](https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html)AWS를 사용하면 임시 자격 증명을 사용하여 AWS Lambda 작업을 수행할 수 있는 [서비스 권한을 부여하도록 Lambda 실행 역할](https://aws.amazon.com/lambda/)을 구성할 수 있습니다. IAM 역할을 사용하여 임시 자격 증명을 부여하는 AWS 서비스에 대한 다른 유사한 모델이 많이 있습니다.
+ IoT 디바이스의 경우 [AWS IoT Core 자격 증명 공급자](https://docs.aws.amazon.com/iot/latest/developerguide/authorizing-direct-aws.html)를 사용하여 임시 자격 증명을 요청할 수 있습니다.
+ AWS 리소스에 액세스해야 하는 AWS 외부에서 실행되는 시스템 또는 온프레미스 시스템의 경우 [IAM Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html)를 사용할 수 있습니다.
임시 자격 증명이 지원되지 않는 시나리오가 있으며, 이 경우 장기 자격 증명을 사용해야 합니다. 이러한 상황에서는 [자격 증명을 주기적으로 감사 및 교체](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_audit.html)하고 [정기적으로 액세스 키를 교체](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#rotate-credentials)합니다. 매우 제한된 IAM 사용자 액세스 키의 경우 다음과 같은 추가 보안 조치를 고려하세요.
+ 매우 제한된 권한 부여:
+ 최소 권한 원칙을 준수합니다(작업, 리소스 및 조건을 구체적으로 지정).
+ IAM 사용자에게 하나의 특정 역할에 대한 AssumeRole 작업만 부여하는 것을 고려합니다. 온프레미스 아키텍처에 따라 이 접근 방식은 장기 IAM 자격 증명을 격리하고 보호하는 데 도움이 됩니다.
+ IAM 역할 신뢰 정책에서 허용되는 네트워크 소스 및 IP 주소를 제한합니다.
+ 사용량을 모니터링하고 미사용 권한 또는 오용에 대한 알림을 설정합니다(AWS CloudWatch Logs 지표 필터 및 경보 사용).
+ [권한 경계](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html)를 적용합니다(서비스 제어 정책(SCP) 및 권한 경계가 서로를 보완함 - SCP는 개괄적이지만 권한 경계는 세분화됨).
+ 자격 증명을 프로비저닝하고 안전하게 저장하는 프로세스를 구현합니다(온프레미스 볼트에 저장).
장기 보안 인증이 필요한 시나리오에 대한 몇 가지 다른 옵션은 다음과 같습니다.
+ 자체 토큰 벤딩 API를 구축합니다(Amazon API Gateway 사용).
+ 장기 자격 증명을 사용해야 하는 상황이나 데이터베이스 로그인과 같이 AWS 액세스 키 이외의 자격 증명을 사용해야 하는 시나리오에서 [AWS Secrets Manager](https://aws.amazon.com/secrets-manager/)와 같은 보안 암호 관리를 처리하도록 설계된 서비스를 사용할 수 있습니다. Secrets Manager는 암호화된 보안 암호의 관리, 교체 및 보안 저장을 간소화합니다. 많은 AWS 서비스가 Secrets Manager와의 [직접 통합](https://docs.aws.amazon.com/secretsmanager/latest/userguide/integrating.html)을 지원합니다.
+ 멀티 클라우드 통합의 경우 소스 자격 증명 서비스 공급자(CSP) 자격 증명을 기반으로 ID 페더레이션을 사용할 수 있습니다([AWS STSAssumeRoleWithWebIdentity](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html) 참조).
장기 자격 증명 교체에 대한 자세한 내용은 [rotating access keys](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_RotateAccessKey)를 참조하세요.
## 리소스
**관련 모범 사례:**
+ [SEC02-BP03 안전하게 보안 암호 저장 및 사용](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_secrets.html)
+ [SEC02-BP04 중앙 집중식 ID 공급업체 사용](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_identity_provider.html)
+ [SEC03-BP08 안전하게 조직과 리소스 공유](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_share_securely.html)
**관련 문서:**
+ [Temporary Security Credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html)
+ [AWS 보안 인증](https://docs.aws.amazon.com/general/latest/gr/aws-sec-cred-types.html)
+ [IAM 보안 모범 사례](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)
+ [IAM 역할](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)
+ [IAM Identity Center](https://aws.amazon.com/iam/identity-center/)()
+ [Identity Providers and Federation](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html)
+ [Rotating Access Keys](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_RotateAccessKey)
+ [보안 파트너 솔루션: 액세스 및 액세스 제어](https://aws.amazon.com/security/partner-solutions/#access-control)
+ [AWS 계정 루트 사용자](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html)
+ [Access AWS using a Google Cloud Platform native workload identity](https://aws.amazon.com/blogs/security/access-aws-using-a-google-cloud-platform-native-workload-identity/)
+ [How to access AWS resources from Microsoft Entra ID tenants using AWS Security Token Service](https://aws.amazon.com/blogs/security/how-to-access-aws-resources-from-microsoft-entra-id-tenants-using-aws-security-token-service/)
**관련 비디오:**
+ [Managing user permissions at scale with AWS IAM Identity Center](https://youtu.be/aEIqeFCcK7E)
+ [Mastering identity at every layer of the cake](https://www.youtube.com/watch?v=vbjFjMNVEpc)
# SEC02-BP03 안전하게 보안 암호 저장 및 사용
워크로드에는 데이터베이스, 리소스 및 서드파티 서비스에 대한 자격 증명을 증명하는 자동화된 기능이 필요합니다. 이는 API 액세스 키, 암호, OAuth 토큰과 같은 보안 암호 액세스 자격 증명을 사용하여 수행됩니다. 특별 제작된 서비스를 사용하여 이러한 자격 증명을 저장, 관리 및 교체하면 해당 자격 증명이 손상될 가능성을 줄이는 데 도움이 됩니다.
**원하는 성과:** 다음 목표를 달성하는 애플리케이션 자격 증명을 안전하게 관리하기 위한 메커니즘을 구현합니다.
+ 워크로드에 필요한 보안 암호를 식별합니다.
+ 가능한 경우 장기 자격 증명을 단기 자격 증명으로 대체하여 필요한 장기 자격 증명의 수를 줄입니다.
+ 나머지 장기 자격 증명의 안전한 저장 및 자동 교체를 설정합니다.
+ 워크로드에 존재하는 보안 암호에 대한 액세스 권한을 감사합니다.
+ 개발 프로세스 중에 소스 코드에 보안 암호가 포함되어 있지 않은지 확인하기 위해 지속적으로 모니터링합니다.
+ 자격 증명이 의도치 않게 공개될 가능성을 줄입니다.
**일반적인 안티 패턴:**
+ 자격 증명을 교체하지 않습니다.
+ 소스 코드 또는 구성 파일에 장기 자격 증명을 저장합니다.
+ 자격 증명을 저장 시 암호화되지 않은 상태로 저장합니다.
**이 모범 사례 확립의 이점:**
+ 보안 암호는 저장 시 및 전송 중 암호화된 상태로 저장됩니다.
+ 자격 증명에 대한 액세스 권한은 API를 통해 제한됩니다(*자격 증명 자판기*와 같음).
+ 자격 증명에 대한 액세스 권한(읽기 및 쓰기 모두)은 감사되고 로깅됩니다.
+ 우려 사항 분리: 자격 증명 교체는 아키텍처의 나머지 부분과 분리될 수 있는 별도의 구성 요소에 의해 수행됩니다.
+ 보안 암호는 필요에 따라 소프트웨어 구성 요소에 자동으로 배포되며 중앙 위치에서 교체가 수행됩니다.
+ 자격 증명에 대한 액세스 권한은 세분화된 방식으로 제어할 수 있습니다.
**이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 높음
## 구현 가이드
과거에는 데이터베이스, 서드파티 API, 토큰 및 기타 보안 암호에 인증하는 데 사용되는 자격 증명이 소스 코드나 환경 파일에 포함되었을 수 있습니다. AWS는 이러한 자격 증명을 안전하게 저장하고 자동으로 교체하며 사용을 감사하는 여러 메커니즘을 제공합니다.
보안 암호 관리에 접근하는 가장 좋은 방법은 제거, 대체 및 교체 지침을 따르는 것입니다. 가장 안전한 자격 증명은 저장, 관리 또는 처리할 필요가 없는 자격 증명입니다. 안전하게 제거할 수 있는 워크로드 기능에 더 이상 필요하지 않은 자격 증명이 있을 수 있습니다.
워크로드의 적절한 기능을 위해 여전히 필요한 자격 증명의 경우 장기 자격 증명을 임시 또는 단기 자격 증명으로 대체할 기회가 있을 수 있습니다. 예를 들어 AWS 비밀 액세스 키를 하드 코딩하는 대신 IAM 역할을 사용하여 해당 장기 자격 증명을 임시 자격 증명으로 대체하는 것이 좋습니다.
일부 장기 보안 암호는 제거하거나 대체하지 못할 수 있습니다. 이러한 보안 암호는 [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html)와 같은 서비스에 저장될 수 있습니다. 이를 통해 중앙에서 저장 및 관리되고 정기적으로 교체될 수 있습니다.
워크로드의 소스 코드 및 구성 파일을 감사하면 여러 유형의 자격 증명을 확인할 수 있습니다. 다음 표에는 일반적인 유형의 자격 증명을 처리하기 위한 전략이 요약되어 있습니다.
| 자격 증명 유형 | 설명 | 제안된 전략 |
| --- | --- | --- |
| IAM 액세스 키 | 워크로드 내에서 IAM 역할을 수임하는 데 사용되는 AWS IAM 액세스 및 비밀 키 | 교체: 대신 컴퓨팅 인스턴스에 할당된 [IAM 역할](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios.html)을 사용합니다(예: [Amazon EC2](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2.html) 또는 [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html)). AWS 계정의 리소스에 대한 액세스가 필요한 서드파티와의 상호 운용성을 위해 [AWS 크로스 계정 액세스](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html)를 지원하는지 문의합니다. 모바일 앱의 경우 [Amazon Cognito 자격 증명 풀(페더레이션 자격 증명)](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-identity.html)을 통한 임시 자격 증명 사용을 고려하세요. AWS 외부에서 실행되는 워크로드의 경우 [IAM Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html) 또는 [AWS Systems Manager 하이브리드 정품 인증](https://docs.aws.amazon.com/systems-manager/latest/userguide/activations.html)을 고려하세요. 컨테이너는 [Amazon ECS 작업 IAM 역할](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-iam-roles.html) 또는 [Amazon EKS node IAM role](https://docs.aws.amazon.com/eks/latest/userguide/create-node-role.html)을 참조하세요. |
| SSH 키 | 수동으로 또는 자동화된 프로세스의 일부로 Linux EC2 인스턴스에 로그인하는 데 사용되는 Secure Shell 프라이빗 키 | 교체: [AWS Systems Manager](https://aws.amazon.com/blogs/mt/vr-beneficios-session-manager/) 또는 [EC2 Instance Connect](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Connect-using-EC2-Instance-Connect.html)를 사용하여 IAM 역할을 통해 EC2 인스턴스에 대한 프로그래밍 방식의 액세스 및 인적 액세스를 제공합니다. |
| 애플리케이션 및 데이터베이스 자격 증명 | 암호 - 일반 텍스트 문자열 | 교체: [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html)에 자격 증명을 저장하고 가능하면 자동 교체를 설정합니다. |
| Amazon RDS 및 Aurora 관리자 데이터베이스 자격 증명 | 암호 - 일반 텍스트 문자열 | 교체: [Amazon RDS와의 Secrets Manager 통합](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-secrets-manager.html) 또는 [Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/rds-secrets-manager.html)를 사용합니다. 또한 일부 RDS 데이터베이스 유형은 일부 사용 사례에서 암호 대신 IAM 역할을 사용할 수 있습니다(자세한 내용은 [IAM 데이터베이스 인증](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.IAMDBAuth.html) 참조). |
| OAuth 토큰 | 보안 암호 토큰 - 일반 텍스트 문자열 | 교체: [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html)에 토큰을 저장하고 자동 교체를 구성합니다. |
| API 토큰 및 키 | 보안 암호 토큰 - 일반 텍스트 문자열 | 교체: [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html)에 저장하고 가능하면 자동 교체를 설정합니다. |
일반적인 안티 패턴은 소스 코드, 구성 파일 또는 모바일 앱 내부에 IAM 액세스 키를 포함하는 것입니다. AWS 서비스와 통신하는 데 IAM 액세스 키가 필요한 경우 [임시 (단기) 보안 자격 증명](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html)을 사용합니다. 이러한 단기 자격 증명은 EC2 인스턴스의 경우 [IAM 역할](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html), Lambda 함수의 경우 [실행 역할](https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html), 모바일 사용자 액세스의 경우 [Cognito IAM 역할](https://docs.aws.amazon.com/cognito/latest/developerguide/iam-roles.html), IoT 기기의 경우 [IoT Core 정책](https://docs.aws.amazon.com/iot/latest/developerguide/iot-policies.html)을 통해 제공할 수 있습니다. 서드파티와 연결할 때 IAM 사용자를 구성하고 서드파티에 해당 사용자의 비밀 액세스 키를 보내는 것보다 계정 리소스에 필수 액세스 권한이 있는 [IAM 역할에 대한 액세스 권한을 위임](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html)하는 것이 좋습니다.
워크로드에 다른 서비스 및 리소스와 상호 운용하는 데 필요한 보안 암호를 저장해야 하는 경우가 많습니다. [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html)는 이러한 자격 증명은 물론, API 토큰, 암호 및 기타 자격 증명의 저장, 사용 및 교체를 안전하게 관리하기 위해 특별히 제작되었습니다.
AWS Secrets Manager는 민감한 자격 증명의 안전한 저장 및 처리를 보장하는 5가지 주요 기능, 즉 [저장 시 암호화](https://docs.aws.amazon.com/secretsmanager/latest/userguide/security-encryption.html), [전송 중 암호화](https://docs.aws.amazon.com/secretsmanager/latest/userguide/data-protection.html), [종합적 감사](https://docs.aws.amazon.com/secretsmanager/latest/userguide/monitoring.html), [세분화된 액세스 제어](https://docs.aws.amazon.com/secretsmanager/latest/userguide/auth-and-access.html), [확장 가능한 자격 증명 교체](https://docs.aws.amazon.com/secretsmanager/latest/userguide/rotating-secrets.html)를 제공합니다. AWS 파트너의 기타 보안 암호 관리 서비스 또는 유사한 기능과 보증을 제공하는 현지 개발 솔루션도 허용됩니다.
보안 암호를 검색할 때 Secret Manager 클라이언트 측 캐싱 구성 요소를 사용하여 나중에 사용할 수 있도록 캐싱할 수 있습니다. 캐싱된 보안 암호를 검색하는 것이 Secret Manager에서 검색하는 것보다 빠릅니다. 또한 Secrets Manager API를 호출하는 데는 비용이 발생하므로 캐시를 사용하면 비용을 줄일 수 있습니다. 암호를 검색할 수 있는 모든 방법은 [Get secrets](https://docs.aws.amazon.com/secretsmanager/latest/userguide/retrieving-secrets.html)을 참조하세요.
**참고**
일부 언어에서는 클라이언트 측 캐싱을 위해 자체 메모리 내 암호화를 구현해야 할 수 있습니다.
### 구현 단계
1. [Amazon CodeGuru](https://aws.amazon.com/codeguru/features/)와 같은 자동화된 도구를 사용하여 하드 코딩된 자격 증명이 포함된 코드 경로를 식별합니다.
1. Amazon CodeGuru를 사용하여 코드 리포지토리를 스캔합니다. 검토가 완료되면 CodeGuru에서 유형=보안 암호를 필터링하여 문제가 있는 코드 줄을 찾습니다.
1. 제거하거나 대체할 수 있는 자격 증명을 식별합니다.
1. 더 이상 필요하지 않은 자격 증명을 식별하고 제거하도록 표시합니다.
1. 소스 코드에 포함된 AWS 보안 암호 키의 경우 필요한 리소스와 연결된 IAM 역할로 대체합니다. 워크로드의 일부가 AWS 외부에 있지만 AWS 리소스에 액세스하기 위해 IAM 자격 증명이 필요한 경우 [IAM Roles Anywhere](https://aws.amazon.com/blogs/security/extend-aws-iam-roles-to-workloads-outside-of-aws-with-iam-roles-anywhere/) 또는 [AWS Systems Manager Hybrid Activations](https://docs.aws.amazon.com/systems-manager/latest/userguide/activations.html)을 고려합니다.
1. 교체 전략을 사용해야 하는 서드파티의 장기 보안 암호의 경우 Secrets Manager를 코드에 통합하여 런타임 시 서드파티 보안 암호를 검색합니다.
1. CodeGuru 콘솔은 검색된 자격 증명을 사용하여 [Secrets Manager에서 보안 암호를 자동으로 생성](https://aws.amazon.com/blogs/aws/codeguru-reviewer-secrets-detector-identify-hardcoded-secrets/)할 수 있습니다.
1. Secrets Manager의 보안 암호 검색을 애플리케이션 코드에 통합합니다.
1. 서버리스 Lambda 함수는 언어에 구애받지 않는 [Lambda 확장](https://docs.aws.amazon.com/secretsmanager/latest/userguide/retrieving-secrets_lambda.html)을 사용할 수 있습니다.
1. EC2 인스턴스 또는 컨테이너의 경우 AWS는 널리 사용되는 여러 프로그래밍 언어로 [Secrets Manager에서 보안 암호를 검색하기 위한 클라이언트 측 코드](https://docs.aws.amazon.com/secretsmanager/latest/userguide/retrieving-secrets.html) 예제를 제공합니다.
1. 주기적으로 코드 베이스를 검토하고 다시 스캔하여 코드에 추가된 새 보안 암호가 없는지 확인합니다.
1. 소스 코드 리포지토리에 새로운 보안 암호가 커밋되지 않도록 [git-secrets](https://github.com/awslabs/git-secrets)와 같은 도구 사용을 고려하세요.
1. 예상치 못한 사용, 부적절한 보안 암호 액세스 또는 보안 암호 삭제 시도가 있는지 [Secrets Manager 활동을 모니터링](https://docs.aws.amazon.com/secretsmanager/latest/userguide/monitoring.html)합니다.
1. 자격 증명에 대한 인적 노출을 줄입니다. 자격 증명을 읽고 쓰고 수정할 수 있는 액세스 권한을 이 목적을 위한 전용 IAM 역할로 제한하고, 해당 역할을 수임할 수 있는 액세스 권한을 일부 운영 사용자에게만 제공합니다.
## 리소스
**관련 모범 사례:**
+ [SEC02-BP02 임시 자격 증명 사용](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_unique.html)
+ [SEC02-BP05 정기적으로 자격 증명 감사 및 교체](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_audit.html)
**관련 문서:**
+ [AWS Secrets Manager 시작하기](https://docs.aws.amazon.com/secretsmanager/latest/userguide/getting-started.html)
+ [Identity Providers and Federation](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html)
+ [Amazon CodeGuru Introduces Secrets Detector](https://aws.amazon.com/blogs/aws/codeguru-reviewer-secrets-detector-identify-hardcoded-secrets/)
+ [AWS Secrets Manager의 AWS Key Management Service 활용 방식](https://docs.aws.amazon.com/kms/latest/developerguide/services-secrets-manager.html)
+ [Secret encryption and decryption in Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/security-encryption.html)
+ [Secrets Manager 블로그 항목](https://aws.amazon.com/blogs/security/tag/aws-secrets-manager/)
+ [Amazon RDS, AWS Secrets Manager와의 통합 발표](https://aws.amazon.com/about-aws/whats-new/2022/12/amazon-rds-integration-aws-secrets-manager/)
**관련 비디오:**
+ [Best Practices for Managing, Retrieving, and Rotating Secrets at Scale](https://youtu.be/qoxxRlwJKZ4)
+ [Find Hard-Coded Secrets Using Amazon CodeGuru Secrets Detector](https://www.youtube.com/watch?v=ryK3PN--oJs)
+ [Securing Secrets for Hybrid Workloads Using AWS Secrets Manager](https://www.youtube.com/watch?v=k1YWhogGVF8)
**관련 워크숍:**
+ [Store, retrieve, and manage sensitive credentials in AWS Secrets Manager](https://catalog.us-east-1.prod.workshops.aws/workshops/92e466fd-bd95-4805-9f16-2df07450db42/en-US)
+ [AWS Systems Manager Hybrid Activations](https://mng.workshop.aws/ssm/capability_hands-on_labs/hybridactivations.html)
# SEC02-BP04 중앙 집중식 ID 공급업체 사용
직원 ID(직원 및 계약업체)의 경우 중앙 위치에서 ID를 관리할 수 있는 ID 제공업체를 이용하세요. 이렇게 하면 단일 위치에서 액세스를 생성, 관리 및 취소하므로 여러 애플리케이션과 서비스에 대한 액세스를 더 쉽게 관리할 수 있습니다.
**원하는 성과:** 중앙 집중식 ID 제공업체를 통해 직원, 인증 정책(예: 다중 인증(MFA) 요구), 시스템 및 애플리케이션에 대한 권한 부여(예: 사용자의 그룹 구성원 자격 또는 특성에 따른 액세스 할당)를 중앙에서 관리할 수 있습니다. 직원은 중앙 ID 제공업체에 로그인하고 내부 및 외부 애플리케이션에 페더레이션(sSingle Sign On)하므로 사용자가 여러 자격 증명을 기억할 필요가 없습니다. ID 제공업체는 인사(HR) 시스템과 통합되므로 직원 변경 사항이 ID 제공업체와 자동으로 동기화됩니다. 예를 들어, 누군가가 조직을 떠나는 경우 페더레이션된 애플리케이션 및 시스템(AWS 포함)에 대한 액세스를 자동으로 취소할 수 있습니다. ID 제공업체에서 세부 감사 로깅을 활성화했으며 이러한 로그를 모니터링하여 비정상적인 사용자 동작이 있는지 확인하고 있습니다.
**일반적인 안티 패턴**:
+ 페더레이션 및 Single Sign-On은 사용하지 않습니다. 직원이 여러 애플리케이션과 시스템에서 별도의 사용자 계정과 자격 증명을 생성합니다.
+ ID 제공업체를 HR 시스템에 통합하는 등 직원의 ID 수명 주기를 자동화하지 않습니다. 사용자가 조직을 떠나거나 역할을 변경하면 수동 프로세스에 따라 여러 애플리케이션 및 시스템에서 기록을 삭제하거나 업데이트합니다.
**이 모범 사례 확립의 이점:** 중앙 집중식 ID 제공업체를 사용하면 직원 ID 및 정책을 한 곳에서 관리하고, 사용자와 그룹에 애플리케이션 액세스 권한을 할당하며, 사용자 로그인 활동을 모니터링할 수 있습니다. 인사(HR) 시스템과 통합하면 사용자가 역할을 변경하면 이러한 변경 내용이 ID 제공업체와 동기화되고 할당된 애플리케이션 및 권한이 자동으로 업데이트됩니다. 사용자가 조직을 떠나면 ID 제공업체에서 해당 ID가 자동으로 비활성화되어 페더레이션된 애플리케이션 및 시스템에 대한 액세스 권한이 취소됩니다.
**이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 높음
## 구현 지침
**AWS에 액세스하는 인력 사용자를 위한 지침** 조직의 직원 및 계약직과 같은 인력 사용자는 직무를 수행하기 위해 AWS Management Console 또는 AWS Command Line Interface(AWS CLI)를 사용하여 AWS에 대한 액세스 권한이 필요할 수 있습니다. 중앙 집중식 ID 제공업체에서 두 가지 수준으로 AWS에 페더레이션하여 직원에게 AWS 액세스 권한을 부여할 수 있습니다. 즉, 각 AWS 계정에 대해 직접 페더레이션하거나 [AWS 조직](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html)의 여러 계정에 페더레이션할 수 있습니다.
인력 사용자를 각 AWS 계정과 직접 페더레이션하려면 중앙 집중식 ID 제공업체를 사용하여 해당 계정에서 [AWS Identity and Access Management](https://aws.amazon.com/iam/)에 페더레이션할 수 있습니다. IAM의 유연성을 통해 각 AWS 계정에 대해 별도의 [SAML 2.0](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_saml.html) 또는 [OIDC(Open ID Connect)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc.html) ID 제공업체를 지원하고 액세스 제어를 위해 페더레이션 사용자 속성을 사용할 수 있습니다. 직원은 웹 브라우저를 사용하여 자격 증명(예: 암호 및 MFA 토큰 코드)을 제공하여 ID 제공업체에 로그인합니다. ID 제공업체가 브라우저에 SAML 어설션을 발행하면 이는 AWS Management Console 로그인 URL에 제출되고 사용자가 [IAM 역할을 수임하여 AWS Management Console](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_enable-console-saml.html)에 Single Sign-On으로 로그인할 수 있습니다. 또한 사용자는 ID 제공업체로부터 [SAML 어설션을 사용해 IAM 역할을 수임](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithSAML.html)하여 [AWS STS](https://docs.aws.amazon.com/STS/latest/APIReference/welcome.html)로부터 [AWS CLI](https://aws.amazon.com/cli/) 또는 [AWS SDK](https://aws.amazon.com/developer/tools/)에서 사용할 임시 AWS API 자격 증명을 확보할 수 있습니다.
직원을 AWS 조직의 여러 계정과 페더레이션하려면 [https://aws.amazon.com/single-sign-on/](https://aws.amazon.com/single-sign-on/)를 사용하여 AWS 계정 및 애플리케이션에 대한 직원의 액세스를 중앙에서 관리할 수 있습니다. 조직의 Identity Center를 활성화하고 자격 증명 소스를 구성합니다. IAM Identity Center는 사용자 및 그룹을 관리하는 데 사용할 수 있는 기본 자격 증명 소스 디렉터리를 제공합니다. 또는 SAML 2.0을 사용하여 [https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-idp.html](https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-idp.html)하고 SCIM을 사용하여 사용자 및 그룹을 [자동으로 프로비저닝](https://docs.aws.amazon.com/singlesignon/latest/userguide/provision-automatically.html)하거나 [Directory Service](https://aws.amazon.com/directoryservice/)를 사용하여 [https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-ad.html](https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-ad.html)함으로서 외부 자격 증명 소스를 선택할 수도 있습니다. 자격 증명 소스가 구성되면 [권한 집합](https://docs.aws.amazon.com/singlesignon/latest/userguide/permissionsetsconcept.html)에 최소 권한 정책을 정의하여 AWS 계정 계정에 대한 사용자 및 그룹의 액세스 권한을 할당할 수 있습니다. 직원은 중앙 ID 제공업체를 통해 인증하여 [AWS 액세스 포털](https://docs.aws.amazon.com/singlesignon/latest/userguide/using-the-portal.html)에 로그인하고 할당된 클라우드 애플리케이션 및 AWS 계정에 Single Sign On으로 로그인할 수 있습니다. 사용자는 Identity Center를 통해 인증하고 AWS CLI 명령을 실행하기 위한 자격 증명을 얻기 위해 [AWS CLI v2](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-sso.html)를 구성할 수 있습니다. 또한 Identity Center는 [Amazon SageMaker AI Studio](https://docs.aws.amazon.com/sagemaker/latest/dg/onboard-sso-users.html) 및 [AWS IoT Sitewise Monitor 포털](https://docs.aws.amazon.com/iot-sitewise/latest/userguide/monitor-getting-started.html)과 같은 AWS 애플리케이션에 대한 Single Sign On을 허용합니다.
위의 지침을 따른 후에는 작업자가 AWS에서 워크로드를 관리할 때 정상적인 작업을 위해 더 이상 IAM 사용자와 그룹을 사용할 필요가 없습니다. 대신 사용자와 그룹은 AWS 외부에서 관리되며 사용자는 *페더레이션형 ID*로 AWS 리소스에 액세스할 수 있습니다. 페더레이션 ID는 중앙 ID 제공업체가 정의한 그룹을 사용합니다. AWS 계정에서 더 이상 필요하지 않은 IAM 그룹, IAM 사용자 그리고 장기 사용자 자격 증명(암호 및 액세스 키)을 식별하고 제거해야 합니다. [IAM 자격 증명 보고서](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_getting-report.html)를 사용하여 [사용하지 않은 자격 증명을 찾고](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_finding-unused.html), [해당 IAM 사용자를 삭제하며](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_manage.html), [IAM 그룹을 삭제](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups_manage_delete.html)할 수 있습니다. 조직에 [서비스 제어 정책(SCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)를 적용하여 새로운 IAM 사용자 및 그룹 생성을 방지하고 페더레이션된 ID를 통해 AWS에 액세스하도록 할 수 있습니다.
**참고**
사용자는 [Automatic provisioning](https://docs.aws.amazon.com/singlesignon/latest/userguide/provision-automatically.html) 설명서에 설명된 대로 SCIM 액세스 토큰의 교체를 처리할 책임이 있습니다. 또한 ID 페더레이션을 지원하는 인증서를 교체할 책임이 있습니다.
**애플리케이션 사용자를 위한 지침** [https://aws.amazon.com/cognito/](https://aws.amazon.com/cognito/)를 중앙 집중식 ID 제공업체로 사용하여 모바일 앱과 같은 애플리케이션 사용자의 자격 증명을 관리할 수 있습니다. Amazon Cognito는 웹 및 모바일 앱에 대한 인증, 권한 부여 및 사용자 관리를 지원합니다. Amazon Cognito는 수백만 명의 사용자로 확장 가능한 자격 증명 스토어를 제공하고, 소셜 및 엔터프라이즈 ID 페더레이션을 지원하며, 고급 보안 기능을 제공하여 사용자와 비즈니스를 보호할 수 있도록 지원합니다. 사용자 지정 웹 또는 모바일 애플리케이션을 Amazon Cognito에 통합하여 몇 분 만에 애플리케이션에 사용자 인증 및 액세스 제어를 추가할 수 있습니다. SAML 및 OIDC(Open ID Connect)와 같은 개방형 ID 표준을 기반으로 구축된 Amazon Cognito는 다양한 규정 준수 규정을 지원하고 프론트엔드 및 백엔드 개발 리소스와 통합됩니다.
### 구현 단계
**직원이 AWS에 액세스하는 단계**
+ 다음 접근 방식 중 하나인 AWS 사용하여 직원을 중앙 집중식 ID 제공업체를 사용하도록 통합하세요.
+ IAM Identity Center를 사용하여 ID 제공업체와 페더레이션하여 AWS 조직 내 여러 AWS 계정에 대한 Single Sign On을 지원합니다.
+ IAM을 통해 ID 제공업체를 각 AWS 계정에 직접 연결하여 페더레이션된 세분화된 액세스를 지원합니다.
+ 페더레이션 ID로 대체되는 IAM 사용자 및 그룹을 식별 및 제거합니다.
**애플리케이션 사용자를 위한 단계**
+ Amazon Cognito를 애플리케이션에 대한 중앙 집중식 ID 제공업체로 사용합니다.
+ OpenID Connect 및 OAuth를 사용하여 사용자 지정 애플리케이션을 Amazon Cognito에 통합합니다. 인증을 위해 Amazon Cognito와 같은 다양한 AWS 서비스와 통합할 수 있는 간단한 인터페이스를 제공하는 Amplify 라이브러리를 사용하여 사용자 지정 애플리케이션을 개발할 수 있습니다.
## 리소스
**관련 모범 사례:**
+ [SEC02-BP06 사용자 그룹 및 속성 사용](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_groups_attributes.html)
+ [SEC03-BP02 최소 권한 액세스 부여](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_least_privileges.html)
+ [SEC03-BP06 수명 주기에 따라 액세스 관리](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_lifecycle.html)
**관련 문서**:
+ [AWS의 ID 페더레이션](https://aws.amazon.com/identity/federation/)
+ [IAM의 보안 모범 사례](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)
+ [AWS Identity and Access Management Best practices](https://aws.amazon.com/iam/resources/best-practices/)
+ [Getting started with IAM Identity Center delegated administration](https://aws.amazon.com/blogs/security/getting-started-with-aws-sso-delegated-administration/)
+ [How to use customer managed policies in IAM Identity Center for advanced use cases](https://aws.amazon.com/blogs/security/how-to-use-customer-managed-policies-in-aws-single-sign-on-for-advanced-use-cases/)
+ [AWS CLI v2: IAM Identity Center credential provider](https://docs.aws.amazon.com/sdkref/latest/guide/feature-sso-credentials.html)
**관련 비디오:**
+ [AWS re:Inforce 2022 - AWS Identity and Access Management (IAM) deep dive](https://youtu.be/YMj33ToS8cI)
+ [AWS re:Invent 2022 - Simplify your existing workforce access with IAM Identity Center](https://youtu.be/TvQN4OdR_0Y)
+ [AWS re:Invent 2018: Mastering Identity at Every Layer of the Cake](https://youtu.be/vbjFjMNVEpc)
**관련 예제:**
+ [워크숍: Using AWS IAM Identity Center to achieve strong identity management](https://catalog.us-east-1.prod.workshops.aws/workshops/590f8439-42c7-46a1-8e70-28ee41498b3a/en-US)
**관련 도구:**
+ [AWS 보안 컴피턴시 파트너: 자격 증명 및 액세스 관리](https://aws.amazon.com/security/partner-solutions/)
+ [saml2aws](https://github.com/Versent/saml2aws)
# SEC02-BP05 정기적으로 자격 증명 감사 및 교체
자격 증명을 주기적으로 감사하고 교체하여 리소스에 액세스하는 데 자격 증명을 사용할 수 있는 기간을 제한합니다. 장기 자격 증명은 많은 위험을 초래하며 이러한 위험은 장기 자격 증명을 정기적으로 교체하여 줄일 수 있습니다.
**원하는 성과:** 자격 증명 교체를 구현하여 장기 자격 증명 사용과 관련된 위험을 줄입니다. 자격 증명 교체 정책 미준수를 정기적으로 감사하고 개선합니다.
**일반적인 안티 패턴**:
+ 자격 증명 사용을 감사하지 않습니다.
+ 장기 자격 증명을 불필요하게 사용합니다.
+ 장기 자격 증명을 사용하고 정기적으로 교체하지 않습니다.
**이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 높음
## 구현 지침
임시 자격 증명을 사용할 수 없으며 장기 자격 증명이 필요한 경우 자격 증명을 감사하여 정의된 제어(예: [다중 인증(MFA)](https://aws.amazon.com/iam/features/mfa/))가 적용되고 정기적으로 교체되며 적절한 액세스 수준을 보유하는지 확인합니다.
올바른 제어 기능이 적용되는지 확인하려면 주기적인 검증(가능한 자동화된 도구 사용)을 실시해야 합니다. 인적 자격 증명의 경우, 사용자가 주기적으로 암호를 변경하고 액세스 키 사용을 중지하며 그 대신 임시 자격 증명을 사용하도록 규정해야 합니다. AWS Identity and Access Management(IAM) 사용자에서 중앙 집중식 ID로 전환하면서 [자격 증명 보고서를 생성](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_getting-report.html)하여 사용자를 감사할 수 있습니다.
또한 ID 제공업체에서 MFA를 적용하고 모니터링하는 것이 좋습니다. 사용자가 MFA를 구성한 경우 [AWS Config 규칙](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html)를 설정하거나 [AWS Security Hub CSPM 보안 표준](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-standards-fsbp-controls.html#fsbp-iam-3)을 사용할 수 있습니다. 시스템 자격 증명에 대한 임시 자격 증명을 제공하려면 [IAM Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html)를 사용하는 것이 좋습니다. IAM 역할 및 임시 자격 증명을 사용할 수 없는 상황에서는 빈번한 감사 및 교체 액세스 키가 필요합니다.
### 구현 단계
+ **정기적으로 자격 증명 감사:** ID 제공업체 및 IAM에 구성된 자격 증명을 감사하면 승인된 자격 증명만 워크로드에 액세스하도록 보장할 수 있습니다. 이러한 자격 증명에는 IAM 사용자, AWS IAM Identity Center 사용자, Active Directory 사용자 또는 다른 업스트림 ID 제공업체의 사용자가 포함될 수 있지만 이에 국한되지 않습니다. 예를 들어 퇴사하는 사람을 제거하고 더 이상 필요하지 않은 크로스 계정 역할을 제거합니다. IAM 엔터티가 액세스하는 서비스에 대한 권한을 정기적으로 감사하는 프로세스가 있어야 합니다. 이렇게 하면 사용되지 않는 권한을 제거하기 위해 수정해야 하는 정책을 식별하는 데 도움이 됩니다. 자격 증명 보고서 및 [AWS Identity and Access Management Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html)를 사용하여 IAM 자격 증명 및 권한을 감사합니다. AWS 환경에서 직접 호출되는 [특정 API 직접 호출에 대해 경보를 설정하도록 Amazon CloudWatch를 사용](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudwatch-alarms-for-cloudtrail.html)할 수 있습니다. [Amazon GuardDuty는 예상치 못한 활동을 알릴 수도 있습니다.](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-iam.html) 이때 IAM 자격 증명에 대한 지나치게 허용적인 액세스 또는 의도하지 않은 액세스를 나타낼 수 있습니다.
+ **정기적으로 자격 증명 교체:** 임시 자격 증명을 사용할 수 없는 경우 장기 IAM 액세스 키를 정기적으로 교체합니다(최대 90일마다). 자신도 모르게 액세스 키가 의도치 않게 공개된 경우 자격 증명을 사용하여 리소스에 액세스할 수 있는 기간이 제한됩니다. IAM 사용자의 액세스 키 교체에 대한 자세한 내용은 [액세스 키 교체](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_RotateAccessKey)를 참조하세요.
+ **IMA 권한 검토:** AWS 계정의 보안을 개선하려면 모든 IAM 정책을 정기적으로 검토하고 모니터링합니다. 정책이 최소 권한 원칙을 준수하는지 확인합니다.
+ **IAM 리소스 생성 및 업데이트 자동화 고려:** [IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html)는 역할 및 정책 관리와 같은 많은 IAM 작업을 자동화합니다. 또는 AWS CloudFormation을 사용하면 템플릿을 확인하고 버전을 제어할 수 있으므로, 역할 및 정책을 포함한 IAM 리소스 배포를 자동화하여 인적 오류가 발생할 가능성을 줄일 수 있습니다.
+ **IAM Roles Anywhere를 사용하여 IAM 사용자를 시스템 ID로 교체:** [IAM Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html)를 사용하면 온프레미스 서버와 같이 기존에는 불가능했던 영역에서 역할을 사용할 수 있습니다. IAM Roles Anywhere는 신뢰할 수 있는 [X.509 인증서](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/trust-model.html#signature-verification)를 사용하여 AWS에 인증하고 임시 자격 증명을 받습니다. IAM Roles Anywhere를 사용하면 장기 자격 증명이 온프레미스 환경에 더 이상 저장되지 않으므로 이러한 자격 증명을 교체할 필요가 없습니다. 만료가 가까워지면 X.509 인증서를 모니터링하고 교체해야 합니다.
## 리소스
**관련 모범 사례:**
+ [SEC02-BP02 임시 자격 증명 사용](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_unique.html)
+ [SEC02-BP03 안전하게 보안 암호 저장 및 사용](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_secrets.html)
**관련 문서**:
+ [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)
+ [Identity Providers and Federation](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html)
+ [보안 파트너 솔루션: 액세스 및 액세스 제어](https://aws.amazon.com/security/partner-solutions/#access-control)
+ [Temporary Security Credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html)
+ [AWS 계정의 자격 증명 보고서 가져오기](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_getting-report.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](https://youtu.be/aEIqeFCcK7E)
+ [Mastering identity at every layer of the cake](https://www.youtube.com/watch?v=vbjFjMNVEpc)
# SEC02-BP06 사용자 그룹 및 속성 사용
사용자 그룹 및 속성에 따라 권한을 정의하면 정책의 수와 복잡성을 줄여 최소 권한 원칙을 보다 간단하게 구현할 수 있습니다. 사용자 그룹을 사용하여 조직에서 수행하는 기능에 따라 한 곳에서 여러 사용자의 권한을 관리할 수 있습니다. 부서, 프로젝트 또는 위치와 같은 속성은 사용자가 유사한 기능을 수행하는 리소스의 다른 하위 세트에 대해 권한 범위 계층을 추가로 제공할 수 있습니다.
**원하는 성과:** 기능에 따른 권한 변경 사항을 해당 기능을 수행하는 모든 사용자에게 적용할 수 있습니다. 그룹 멤버십과 속성은 사용자 권한을 관리하므로, 개별 사용자 수준에서 권한을 관리할 필요가 줄어듭니다. ID 제공업체(idP)에서 정의한 그룹 및 속성은 AWS 환경에 자동으로 전파됩니다.
**일반적인 안티 패턴:**
+ 개별 사용자의 권한을 관리하고 여러 사용자에 걸쳐 복제합니다.
+ 지나치게 개괄적으로 그룹을 정의하여 너무 광범위한 권한을 부여합니다.
+ 그룹을 너무 세밀하게 정의하여 멤버십에 대한 중복과 혼란을 야기합니다.
+ 속성을 대신 사용할 수 있는 경우 리소스의 하위 세트에서 권한이 중복된 그룹을 사용합니다.
+ AWS 환경에 통합되어 있는 표준화된 ID 제공업체를 통해 그룹, 속성 및 멤버십을 관리하지 않습니다.
+ AWS IAM Identity Center 세션을 사용할 때 역할 체인 사용
**이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 중간
## 구현 가이드
AWS 권한은 사용자, 그룹, 역할 또는 리소스와 같은 보안 주체와 관련된 *정책*이라는 문서에서 정의됩니다. 직무, 워크로드 및 SDLC 환경을 기반으로 권한 할당(그룹, 권한, 계정)을 구성하여 권한 관리를 확장할 수 있습니다. 직원의 경우 액세스 중인 리소스가 아닌 조직에서 사용자가 수행하는 기능을 기반으로 그룹을 정의할 수 있습니다. 예를 들어 WebAppDeveloper 그룹에는 개발 계정 내에서 Amazon CloudFront와 같은 서비스를 구성하기 위한 정책이 연결되어 있을 수 있습니다. `AutomationDeveloper` 그룹에는 `WebAppDeveloper` 그룹과 일부 중첩 권한이 있을 수 있습니다. 두 기능을 수행하는 사용자가 모두 `CloudFrontAccess` 그룹에 속하도록 하는 대신 이러한 일반적인 권한을 별도의 정책으로 캡처하여 두 그룹에 연결할 수 있습니다.
그룹 외에도 *속성*을 사용하여 액세스 범위를 확대할 수 있습니다. 예를 들어, `WebAppDeveloper` 그룹의 사용자에 대해 Project 속성을 지정하여 프로젝트 관련 리소스에 대한 액세스 범위를 설정할 수 있습니다. 이 기술을 사용하면 권한이 동일할 경우 상이한 프로젝트에서 작업하는 애플리케이션 개발자용 그룹을 서로 다르게 만들 필요가 없습니다. 권한 정책에서 속성을 참조하는 방법은 해당 속성이 페더레이션 프로토콜(예: SAML, OIDC 또는 SCIM)의 일부로 정의되었는지, 사용자 지정 SAML 어설션으로 정의되었는지, IAM Identity Center 내부에 설정되었는지에 관계없이 해당 소스를 기반으로 합니다.
### 구현 단계
1. 그룹 및 속성을 정의할 위치를 설정합니다.
1. [SEC02-BP04 중앙 집중식 ID 공급업체 사용](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_identity_provider.html)의 지침에 따라 그룹 및 속성을 정의할 때 ID 제공업체 내부 또는 IAM Identity Center 내부에서 그룹 및 속성을 정의해야 하는지 아니면 특정 계정의 IAM 사용자 그룹을 사용해야 하는지 결정할 수 있습니다.
1. 그룹을 정의합니다.
1. 기능 및 필요한 액세스 범위를 기준으로 그룹을 결정합니다. 계층 구조 또는 명명 규칙을 사용하여 그룹을 효과적으로 구성하는 것이 좋습니다.
1. IAM Identity Center 내에 정의하는 경우 그룹을 만들고 권한 집합을 사용하여 원하는 수준의 액세스를 연결합니다.
1. 외부 ID 제공업체 내에서 정의하는 경우 제공업체가 SCIM 프로토콜을 지원하는지 확인하고, IAM Identity Center 내에서 자동 프로비저닝을 활성화하는 방법을 고려하세요. 이 기능은 제공업체와 IAM Identity Center 간에 그룹 생성, 멤버십 및 삭제를 동기화합니다.
1. 속성을 정의합니다.
1. 외부 ID 제공업체를 사용하는 경우 SCIM 및 SAML 2.0 프로토콜 모두 기본적으로 특정 속성을 제공합니다. `https://aws.amazon.com/SAML/Attributes/PrincipalTag` 속성 이름을 사용하는 SAML 어설션을 통해 추가 속성을 정의하고 전달할 수 있습니다. 사용자 지정 속성 정의 및 구성에 대한 지침은 ID 제공업체의 설명서를 참조하세요.
1. IAM Identity Center 내부에서 역할을 정의하는 경우 속성 기반 액세스 제어(ABAC) 기능을 활성화하고 필요에 따라 속성을 정의합니다. 조직의 구조 또는 리소스 태그 지정 전략에 맞는 속성을 고려합니다.
IAM Identity Center를 통해 수임된 IAM 역할에서 IAM 역할 체인이 필요한 경우 `source-identity` 및 `principal-tags`와 같은 값은 전파되지 않습니다. 자세한 내용은 [액세스 제어를 위한 속성 활성화 및 구성](https://docs.aws.amazon.com/singlesignon/latest/userguide/configure-abac.html)을 참조하세요.
1. 그룹 및 속성을 기반으로 권한 범위를 지정합니다.
1. 권한 정책에 보안 주체의 속성을 액세스 중인 리소스의 속성과 비교하는 조건을 포함하는 것을 고려해 보세요. 예를 들어 `PrincipalTag` 조건 키의 값이 같은 이름의 `ResourceTag` 키 값과 일치하는 경우에만 리소스에 대한 액세스를 허용하도록 조건을 정의할 수 있습니다.
1. ABAC 정책을 정의할 때는 [ABAC 권한 부여](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) 모범 사례 및 예시의 지침을 따르세요.
1. 조직의 요구가 변화함에 따라 그룹 및 속성 구조를 정기적으로 검토하고 업데이트하여 최적의 권한 관리를 보장합니다.
## 리소스
**관련 모범 사례:**
+ [SEC02-BP04 중앙 집중식 ID 공급업체 사용](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_identity_provider.html)
+ [SEC03-BP02 최소 권한 액세스 부여](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_least_privileges.html)
+ [COST02-BP04 그룹 및 역할 구현](https://docs.aws.amazon.com/wellarchitected/latest/framework/cost_govern_usage_groups_roles.html)
**관련 문서:**
+ [IAM 모범 사례](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)
+ [Manage Identities in IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-sso.html)
+ [What Is ABAC for AWS?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)
+ [ABAC In IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/configure-abac.html)
+ [ABAC 정책 예시](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_examples_aws_abac.html)
**관련 비디오:**
+ [Managing user permissions at scale with AWS IAM Identity Center](https://youtu.be/aEIqeFCcK7E)
+ [Mastering identity at every layer of the cake](https://www.youtube.com/watch?v=vbjFjMNVEpc)
# 권한 관리
AWS 및 워크로드에 액세스해야 하는 인적 자격 증명 및 시스템 자격 증명에 대한 액세스를 제어하는 권한을 관리합니다. 권한을 통해 누가 어떤 조건에서 무엇에 액세스할 수 있는지를 제어할 수 있습니다. 구체적인 인적 및 머신 자격 증명에 권한을 설정하여 특정 리소스의 특정 서비스 작업에 대한 액세스 권한을 부여합니다. 또한 액세스 권한을 부여하려면 충족되어야 하는 조건을 지정할 수 있습니다.
서로 다른 유형의 리소스에 액세스 권한을 부여하는 방법에는 여러 가지가 있습니다. 그중 하나는 서로 다른 정책 유형을 사용하는 것입니다.
IAM의 [자격 증명 기반 정책](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html)은 *관리형* 또는 *인라인* 형태이며, 사용자, 그룹 또는 역할을 포함한 IAM 자격 증명에 연결됩니다. 이러한 정책으로 자격 증명이 수행할 수 있는 작업(권한)을 지정할 수 있습니다. 자격 증명 기반 정책은 하위 범주로 분류할 수 있습니다.
**관리형 정책** - AWS 계정에 속한 다수의 사용자, 그룹 및 역할에게 독립적으로 연결할 수 있는 자격 증명 기반 정책입니다. 두 가지 유형의 관리형 정책이 있습니다.
+ **AWS 관리형 정책** - AWS에서 생성 및 관리하는 관리형 정책입니다.
+ **고객 관리형 정책** - 사용자가 자신의 AWS 계정에서 생성 및 관리하는 관리형 정책입니다. 고객 관리형 정책은 AWS 관리형 정책에 비해 정책을 더 세밀하게 제어할 수 있습니다.
관리형 정책은 권한 적용에 선호되는 방법입니다. 그러나 하나의 사용자, 그룹 또는 역할에 직접 추가하는 인라인 정책을 사용할 수도 있습니다. 인라인 정책은 정책과 자격 증명을 정확히 1대 1 관계로 유지합니다. 자격 증명을 삭제하면 인라인 정책도 삭제됩니다.
대부분의 경우 [최소 권한](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege) 원칙에 따라 고객 관리형 정책을 직접 생성해야 합니다.
[리소스 기반 정책](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)은 리소스에 연결됩니다. 리소스 기반 정책의 예로는 S3 버킷 정책이 있습니다. 이 정책은 리소스와 같거나 다른 계정에 있을 수 있는 보안 주체에 권한을 부여합니다. 리소스 기반 권한을 지원하는 서비스 목록은 [IAM으로 작업하는 AWS 서비스](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)를 참조하세요.
[권한 경계](https://aws.amazon.com/blogs/security/delegate-permission-management-to-developers-using-iam-permissions-boundaries/)를 사용하여 관리자가 설정할 수 있는 최대 권한을 설정할 수 있습니다. 이렇게 하면 IAM 역할 생성과 같은 권한을 생성하고 관리할 수 있는 능력을 개발자에게 위임할 수 있지만, 개발자가 생성한 권한을 사용하여 권한을 에스컬레이션할 수 없도록 제한할 수 있습니다.
AWS의 [속성 기반 액세스 제어(ABAC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)에서는 태그라고 불리는 속성을 기반으로 권한을 부여할 수 있습니다. 이러한 태그는 IAM 보안 주체(사용자 또는 역할) 및 AWS 리소스에 연결될 수 있습니다. 관리자는 IAM 보안 주체의 속성을 기반으로 권한을 적용하는, 재사용 가능한 IAM 정책을 만들 수 있습니다. 예를 들어, 관리자는 조직의 개발자에게 개발자의 프로젝트 태그와 일치하는 AWS 리소스에 대한 액세스 권한을 부여하기 위해 단일 IAM 정책을 사용할 수 있습니다. 개발자 팀이 프로젝트에 리소스를 추가하면 속성에 따라 권한이 자동으로 적용되어 새로운 리소스마다 정책 업데이트를 할 필요가 없습니다.
[조직 서비스 제어 정책(SCP)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_scp)에서는 조직 또는 조직 단위(OU)의 계정 구성원에 대한 최대 권한을 정의합니다. SCP는 자격 증명 기반 정책이나 리소스 기반 정책을 통해 계정 내 엔터티(사용자나 역할)에 부여하는 권한을 *제한*하지만, 권한을 *부여하지는 않습니다*.
[세션 정책](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session)은 역할 또는 페더레이션 사용자를 맡습니다. AWS CLI 또는 AWS API를 사용할 때 세션 정책을 전달합니다. 세션 정책은 역할 또는 사용자의 자격 증명 기반 정책이 세션에 부여하는 권한을 제한합니다. 세션 정책은 생성된 세션에 대한 권한을 *제한*하지 않지만, 권한을 *부여하지도 않습니다*. 자세한 정보는 [세션 정책](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session)을 참조하세요.
**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-BP09 안전하게 서드파티와 리소스 공유](sec_permissions_share_securely_third_party.md)
# SEC03-BP01 액세스 요구 사항 정의
관리자, 최종 사용자 또는 기타 구성 요소별로 워크로드의 각 구성 요소 또는 리소스에 액세스해야 합니다. 각 구성 요소에 대한 액세스 권한 부여 대상을 명확하게 정의하고 적절한 ID 유형과 인증 및 권한 부여 방법을 선택합니다.
**일반적인 안티 패턴:**
+ 애플리케이션에 보안 암호를 하드 코딩 또는 저장합니다.
+ 각 사용자에 대한 사용자 지정 권한을 부여합니다.
+ 장기 자격 증명을 사용합니다.
**이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 높음
## 구현 지침
관리자, 최종 사용자 또는 기타 구성 요소별로 워크로드의 각 구성 요소 또는 리소스에 액세스해야 합니다. 각 구성 요소에 대한 액세스 권한 부여 대상을 명확하게 정의하고 적절한 ID 유형과 인증 및 권한 부여 방법을 선택합니다.
조직 내 AWS 계정에 대한 정기적인 액세스는 [페더레이션 액세스](https://aws.amazon.com/identity/federation/) 또는 중앙 집중식 ID 제공업체를 사용하여 제공되어야 합니다. 또한 자격 증명 관리를 중앙 집중화하고, 직원 액세스 수명 주기에 대한 AWS 액세스를 통합하기 위해 정립된 사례가 있는지 확인해야 합니다. 예를 들어, 직원이 다른 액세스 수준의 직무로 변경할 경우 해당 그룹 멤버십 또한 변경하여 새로운 액세스 요구 사항을 반영해야 합니다.
비인적 자격 증명에 대한 액세스 요구 사항을 정의할 경우 어떤 애플리케이션 및 구성 요소가 액세스해야 하는지 그리고 어떻게 권한이 부여되는지 결정합니다. 권장되는 접근 방식은 최소 권한 액세스 모델을 통해 구축된 IAM 역할을 사용하는 것입니다. [AWS 관리형 정책](https://docs.aws.amazon.com/singlesignon/latest/userguide/security-iam-awsmanpol.html)에서는 대부분의 일반적인 사용 사례를 다루는 미리 정의된 IAM 정책을 제공합니다.
[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)와 같은 AWS 서비스를 사용하면 애플리케이션 또는 워크로드에서 보안 정보를 안전하게 분리할 수 있습니다. Secrets Manager에서 자격 증명의 자동 교체를 설정할 수 있습니다. Systems Manager를 사용하여 스크립트, 명령, SSM 문서, 구성 및 자동화 워크플로의 파라미터를 참조할 수 있으며 이 경우 파라미터를 생성할 때 지정한 고유한 이름을 사용합니다.
[AWS IAM Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html)를 사용하여 AWS 외부에서 실행되는 워크로드에 대한 [IAM의 임시 보안 자격 증명](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html)을 얻을 수 있습니다. 워크로드는 AWS 애플리케이션에서 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)을 사용할 수 있습니다.
가능한 경우, 장기적이고 정적인 자격 증명보다는 단기적이고 임시적인 자격 증명을 사용하는 것이 좋습니다. 사용자가 프로그래밍 방식 및 장기 자격 증명을 사용해야 하는 시나리오의 경우 [액세스 키의 마지막 사용 정보](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_RotateAccessKey)를 사용하여 액세스 키를 교체하고 제거합니다.
사용자가 AWS Management Console 외부에서 AWS와 상호 작용하려면 프로그래밍 방식의 액세스가 필요합니다. 프로그래밍 방식으로 액세스를 부여하는 방법은 AWS에 액세스하는 사용자 유형에 따라 다릅니다.
사용자에게 프로그래밍 방식 액세스 권한을 부여하려면 다음 옵션 중 하나를 선택합니다.
****
| 프로그래밍 방식 액세스가 필요한 사용자는 누구인가요? | To | By |
| --- | --- | --- |
| IAM | (권장됨) 콘솔 자격 증명을 임시 자격 증명으로 사용하여 AWS CLI, AWS SDK 또는 AWS API에 대한 프로그래밍 요청에 서명합니다. | 사용하고자 하는 인터페이스에 대한 지침을 따릅니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/latest/security-pillar/sec_permissions_define.html) |
| 작업 인력 ID (IAM Identity Center가 관리하는 사용자) | 임시 자격 증명을 사용하여 AWS CLI, AWS SDK 또는 AWS API에 대한 프로그래밍 요청에 서명합니다. | 사용하고자 하는 인터페이스에 대한 지침을 따릅니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/latest/security-pillar/sec_permissions_define.html) |
| IAM | 임시 자격 증명을 사용하여 AWS CLI, AWS SDK 또는 AWS API에 대한 프로그래밍 요청에 서명합니다. | IAM 사용자 설명서의 [AWS 리소스와 함께 임시 자격 증명 사용](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html)에 나와 있는 지침을 따르세요. |
| IAM | (권장되지 않음)장기 자격 증명을 사용하여 AWS CLI, AWS SDK 또는 AWS API에 대한 프로그래밍 요청에 서명합니다. | 사용하고자 하는 인터페이스에 대한 지침을 따릅니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/latest/security-pillar/sec_permissions_define.html) |
## 리소스
**관련 문서:**
+ [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)
+ [AWS Managed policies for IAM Identity Center](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)
+ [How to control access to AWS resources based on AWS 계정, OU, or organization](https://aws.amazon.com/blogs/security/how-to-control-access-to-aws-resources-based-on-aws-account-ou-or-organization/)
+ [Identify, arrange, and manage secrets easily using enhanced search in AWS Secrets Manager](https://aws.amazon.com/blogs/security/identify-arrange-manage-secrets-easily-using-enhanced-search-in-aws-secrets-manager/)
**관련 비디오:**
+ [Become an IAM Policy Master in 60 Minutes or Less](https://youtu.be/YQsK4MtsELU)
+ [Separation of Duties, Least Privilege, Delegation, and CI/CD](https://youtu.be/3H0i7VyTu70)
+ [Streamlining identity and access management for innovation](https://www.youtube.com/watch?v=3qK0b1UkaE8)
# SEC03-BP02 최소 권한 액세스 부여
구체적인 조건에서 특정 리소스에 대해 일정한 작업을 수행하기 위해 사용자에게 필요한 액세스 권한만 부여합니다. 개별 사용자에 대한 권한을 정의하는 대신, 그룹 및 자격 증명 속성을 사용하여 대규모로 권한을 동적으로 설정합니다. 예를 들어 개발자 그룹이 자체 프로젝트에 대한 리소스만 관리하도록 액세스 권한을 허용할 수 있습니다. 이렇게 하면 특정 개발자가 프로젝트에서 빠지게 될 경우 기본 액세스 정책을 변경하지 않고도 해당 개발자의 액세스 권한이 자동으로 해지됩니다.
**원하는 성과:** 사용자에게 자신의 특정 작업 기능에 필요한 최소 권한만 있습니다. 별도의 AWS 계정을 사용하여 개발자를 프로덕션 환경에서 격리합니다. 개발자가 특정 작업의 프로덕션 환경에 액세스해야 하는 경우 해당 작업을 수행하는 기간 동안에만 제한되고 제어된 액세스 권한이 부여됩니다. 프로덕션 액세스는 해당 개발자가 필요한 작업을 완료한 후 즉시 취소됩니다. 권한에 대한 정기적인 검토를 수행하고 사용자가 역할을 변경하거나 조직을 떠날 때와 같이 권한이 더 이상 필요하지 않은 경우 즉시 권한을 취소합니다. 관리자 권한을 신뢰할 수 있는 소규모 그룹으로 제한하여 위험 노출을 줄입니다. 머신 또는 시스템 계정에는 의도한 작업을 수행하는 데 필요한 최소 권한만 부여합니다.
**일반적인 안티 패턴:**
+ 사용자에게 기본적으로 관리자 권한을 부여합니다.
+ 일상 활동에 루트 사용자 계정을 사용합니다.
+ 적절한 범위 조정 없이 지나치게 허용적인 정책을 생성합니다.
+ 권한 검토는 자주 수행되지 않으므로 권한이 점차 커지는 상황이 발생합니다.
+ 환경 격리 또는 권한 관리를 위해 속성 기반 액세스 제어에만 의존합니다.
**이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 높음
## 구현 지침
[최소 권한](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege)의 원칙은 자격 증명에서 특정 작업을 완수하는 데 필요한 최소한의 활동만 수행하도록 허용해야 한다고 규정합니다. 이를 통해 사용 편의성, 효율성 및 보안의 균형을 이룰 수 있습니다. 이 원칙에 따라 운영하면 의도하지 않은 액세스를 제한하고 누가 어떤 리소스에 액세스했는지 추적하는 데 도움이 됩니다. 기본적으로 IAM 사용자와 역할에는 어떠한 권한도 없습니다. 루트 사용자는 기본적으로 전체 액세스 권한을 가지므로 엄격하게 제어 및 모니터링하고 [루트 액세스 권한이 필요한 작업](https://docs.aws.amazon.com/accounts/latest/reference/root-user-tasks.html)에만 사용해야 합니다.
IAM 정책은 IAM 역할 또는 특정 리소스에 대한 권한을 명시적으로 부여하는 데 사용됩니다. 예를 들어, 자격 증명 기반 정책은 IAM 그룹에 연결하는 한편 S3 버킷은 리소스 기반 정책으로 제어할 수 있습니다.
IAM 정책을 생성할 때 AWS에서 액세스를 허용하거나 거부하려면 참이어야 하는 서비스 작업, 리소스 및 조건을 지정할 수 있습니다. AWS에서는 액세스 범위를 줄일 수 있도록 다양한 조건을 지원합니다. 예를 들어 PrincipalOrgID [조건 키](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html)를 사용하면 요청자가 AWS 조직에 속하지 않는 경우 요청자의 작업을 거부할 수 있습니다.
또한 CalledVia 조건 키를 사용하여 AWS Lambda 함수를 생성하는 AWS CloudFormation과 같이 사용자를 대신하여 AWS 서비스에서 제출하는 요청을 제어할 수 있습니다. 다양한 정책 유형을 계층화하여 심층 방어를 설정하고 사용자의 권한 전반을 제한할 수 있습니다. 나아가 어떤 조건에서 어떤 권한을 허용할지도 제한할 수도 있습니다. 예를 들어 워크로드 팀이 구축하는 시스템에 대해 자체 IAM 정책을 만들도록 허용하되, 부여할 수 있는 최대 권한을 제한하기 위해 [권한 경계](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html)를 적용할 경우에만 허용할 수 있습니다.
### 구현 단계
+ **최소 권한 정책 구현:** IAM 그룹 및 역할에 최소 권한이 적용된 액세스 정책을 할당하여 사용자별로 정의한 역할 또는 기능을 반영합니다.
+ **별도의 AWS 계정을 통해 개발 및 프로덕션 환경 격리:** 개발 및 프로덕션 환경에 별도의 AWS 계정을 사용하고 [서비스 제어 정책](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html), 리소스 정책 및 자격 증명 정책을 사용하여 이들 간의 액세스를 제어합니다.
+ **API 사용에 대한 기본 정책:** AWS CloudTrail 로그를 검토하여 필요한 권한을 결정하는 한 가지 방법입니다. 이 검토를 사용해 사용자가 AWS 내에서 실제로 수행하는 작업에 맞게 조정된 권한을 만들 수 있습니다. [IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html)는 활동을 기반으로 IAM 정책을 [자동으로 생성](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html)할 수 있습니다. 조직 또는 계정 수준에서 IAM Access Advisor를 사용하여 [특정 정책에 대해 마지막 액세스 정보를 추적](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor.html)할 수 있습니다.
+ **[작업 함수에 AWS 관리형 정책](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) 사용 고려:** 세분화된 권한 정책을 생성하기 시작할 때 결제, 데이터베이스 관리자 및 데이터 과학자와 같은 일반적인 작업 역할에 AWS 관리형 정책을 사용하는 것이 도움이 될 수 있습니다. 이러한 정책은 최소 권한 정책을 구현하는 방법을 결정하는 동시에 사용자의 액세스 범위를 좁히는 데 도움이 될 수 있습니다.
+ **불필요한 권한 제거:** 미사용 IAM 엔터티, 자격 증명 및 권한을 감지하고 제거하여 최소 권한 원칙을 달성합니다. [IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-findings.html)를 사용하여 외부 및 미사용 액세스를 식별할 수 있으며, [IAM Access Analyzer 정책 생성](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html)은 권한 정책을 미세 조정하는 데 도움이 될 수 있습니다.
+ **프로덕션 환경에 대한 사용자 액세스 제한:** 사용자는 유효한 사용 사례가 있는 프로덕션 환경에만 액세스할 수 있어야 합니다. 사용자가 프로덕션 액세스 권한이 필요한 특정 작업을 수행한 후에는 액세스 권한을 해지해야 합니다. 프로덕션 환경에 대한 액세스를 제한하면 예기치 않게 프로덕션에 영향을 미치는 이벤트를 방지하고 의도하지 않은 액세스의 영향 범위를 줄일 수 있습니다.
+ **권한 경계 고려:** [권한 경계](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html)는 ID 기반 정책을 통해 IAM 엔터티에 부여할 수 있는 최대 권한을 설정하는 관리형 정책을 사용하는 기능입니다. 엔터티의 권한 경계는 자격 증명 기반 정책 및 관련 권한 경계 모두에서 허용되는 작업만 수행하도록 허용합니다.
+ **속성 기반 액세스 제어 및 리소스 태그를 사용하여 액세스 구체화:** 리소스 태그를 사용하는 [속성 기반 액세스 제어(ABAC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)를 사용하여 지원되는 경우 권한을 구체화할 수 있습니다. 보안 주체 태그를 리소스 태그와 비교하여 정의한 사용자 지정 차원에 따라 액세스를 구체화하는 ABAC 모델을 사용할 수 있습니다. 이 접근 방식은 조직의 권한 정책 수를 간소화하고 줄일 수 있습니다.
+ 보안 주체와 리소스를 모두 AWS 조직에서 소유한 경우에만 ABAC를 액세스 제어에 사용하는 것이 좋습니다. 외부 당사자는 자체 보안 주체 및 리소스에 대해 조직과 동일한 태그 이름 및 값을 사용할 수 있습니다. 외부 당사자 보안 주체 또는 리소스에 대한 액세스 권한을 부여하기 위해 이러한 이름-값 페어에만 의존하는 경우 의도하지 않은 권한을 제공할 수 있습니다.
+ **AWS Organizations에 서비스 제어 정책 사용:** [서비스 제어 정책](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)은 조직의 구성원 계정에 대해 사용 가능한 최대 권한을 중앙에서 제어합니다. 중요한 점은 서비스 제어 정책을 사용하여 구성원 계정의 루트 사용자 권한을 제한할 수 있다는 사실입니다. AWS Organizations를 보강하는 권장 관리 제어 기능을 제공하는 AWS Control Tower를 사용하는 것도 고려해 보세요. Control Tower 내에서 자체 제어 기능을 정의할 수도 있습니다.
+ **조직을 위한 사용자 수명 주기 정책 수립:** 사용자 수명 주기 정책은 사용자가 AWS에 온보딩하거나, 작업 역할 또는 범위가 변경되거나, 더 이상 AWS에 액세스할 필요가 없을 때 수행할 작업을 정의합니다. 사용자 수명 주기의 각 단계에서 권한 검토를 수행하여 권한이 적절하게 제한되는지 확인하고 권한이 커지는 상황이 없도록 해야 합니다.
+ **권한을 검토하고 불필요한 권한을 제거하기 위한 정기 예약 설정:** 사용자 액세스를 정기적으로 검토하여 사용자에게 과도하게 허용되는 액세스 권한이 없는지 확인해야 합니다. [AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html) 및 IAM Access Analyzer는 사용자 권한을 감사할 때 유용합니다.
+ **작업 역할 매트릭스 설정:** 작업 역할 매트릭스는 AWS 기반 내에서 필요한 여러 역할 및 액세스 수준을 시각화합니다. 작업 역할 매트릭스를 사용하여 조직 내 사용자 책임에 따라 권한을 정의하고 분리할 수 있습니다. 개별 사용자나 역할에 권한을 직접 적용하는 대신 그룹을 사용합니다.
## 리소스
**관련 문서:**
+ [최소 권한 적용](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege)
+ [Permissions boundaries for IAM entities](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html)
+ [Techniques for writing least privilege IAM policies](https://aws.amazon.com/blogs/security/techniques-for-writing-least-privilege-iam-policies/)
+ [IAM Access Analyzer makes it easier to implement least privilege permissions by generating IAM policies based on access activity](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/)
+ [Delegate permission management to developers by using IAM permissions boundaries](https://aws.amazon.com/blogs/security/delegate-permission-management-to-developers-using-iam-permissions-boundaries/)
+ [Refining Permissions using last accessed information](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor.html)
+ [IAM policy types and when to use them](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)
+ [Guardrails in AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/guardrails.html)
+ [Zero Trust architectures: An AWS perspective](https://aws.amazon.com/blogs/security/zero-trust-architectures-an-aws-perspective/)
+ [How to implement the principle of least privilege with CloudFormation StackSets](https://aws.amazon.com/blogs/security/how-to-implement-the-principle-of-least-privilege-with-cloudformation-stacksets/)
+ [ABAC(속성 기반 액세스 제어)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)
+ [Reducing policy scope by viewing user activity](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor.html)
+ [View role access](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_manage_delete.html)
+ [Use Tagging to Organize Your Environment and Drive Accountability](https://docs.aws.amazon.com/aws-technical-content/latest/cost-optimization-laying-the-foundation/tagging.html)
+ [AWS Tagging Strategies](https://aws.amazon.com/answers/account-management/aws-tagging-strategies/)
+ [AWS 리소스에 태그 지정](https://aws.amazon.com/premiumsupport/knowledge-center/tagging-resources/)
**관련 비디오:**
+ [Next-generation permissions management](https://www.youtube.com/watch?v=8vsD_aTtuTo)
+ [Zero Trust: An AWS perspective](https://www.youtube.com/watch?v=1p5G1-4s1r0)
# SEC03-BP03 긴급 액세스 프로세스 설정
중앙 집중식 ID 제공업체에 문제가 발생할 경우 예상치 못한 상황에서 워크로드에 긴급 액세스할 수 있는 프로세스를 만드세요.
긴급 상황을 초래할 수 있는 다양한 장애 모드에 대한 프로세스를 설계해야 합니다. 예를 들어, 일반적인 상황에서는 직원이 중앙 집중식 ID 제공업체를 사용하여 클라우드로 페더레이션함으로써([SEC02-BP04](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_identity_provider.html)) 워크로드를 관리합니다. 그러나 중앙 집중식 ID 제공업체에 장애가 발생하거나 클라우드에서의 페더레이션 구성이 수정되면 직원이 클라우드로 페더레이션하지 못할 수 있습니다. 긴급 액세스 프로세스를 통해 권한 있는 관리자는 대체 수단(예: 대체 형태의 페더레이션 또는 직접 사용자 액세스)을 통해 클라우드 리소스에 액세스하여 페더레이션 구성 또는 워크로드 관련 문제를 해결할 수 있습니다. 긴급 액세스 프로세스는 일반 페더레이션 메커니즘이 복원될 때까지 사용됩니다.
**원하는 성과:**
+ 긴급 상황으로 간주되는 장애 모드를 정의하고 문서화했습니다. 일반적인 상황과 사용자가 워크로드를 관리하기 위해 사용하는 시스템을 고려하세요. 이러한 각 종속성이 어떻게 실패하여 긴급 상황을 초래할 수 있는지 생각해 보세요. 장애 가능성을 최소화하기 위해 장애 모드를 식별하고 보다 탄력적인 시스템을 설계하는 데 유용한 [신뢰성 원칙](https://docs.aws.amazon.com/wellarchitected/latest/framework/a-reliability.html)의 질문 및 모범 사례를 찾아볼 수 있습니다.
+ 장애를 긴급 상황으로 확인하기 위해 따라야 하는 단계를 문서화했습니다. 예를 들어 ID 관리자에게 기본 및 대기 ID 제공업체의 상태를 확인하고 둘 다 사용할 수 없는 경우 ID 제공업체 장애에 대한 긴급 이벤트를 선언하도록 요청할 수 있습니다.
+ 각 유형의 긴급 또는 장애 모드에 맞는 긴급 액세스 프로세스를 정의했습니다. 구체적으로 설명하면 모든 유형의 긴급 상황에서 일반 프로세스를 과도하게 사용하려는 사용자의 유혹을 줄일 수 있습니다. 긴급 액세스 프로세스는 각 프로세스를 사용해야 하는 상황과 반대로 프로세스를 사용하지 않아야 하는 상황을 설명하고 적용될 수 있는 대체 프로세스를 가리킵니다.
+ 프로세스는 빠르고 효율적으로 따를 수 있는 상세한 지침과 플레이북과 함께 잘 문서화되어 있습니다. 긴급 상황은 사용자에게 스트레스를 주는 시간이 될 수 있고 사용자들이 극심한 시간 압박을 받을 수 있다는 점을 기억하세요. 따라서 프로세스를 최대한 단순하게 설계하세요.
**일반적인 안티 패턴:**
+ 긴급 액세스 절차가 제대로 문서화되고 테스트되지 않습니다. 사용자는 긴급 상황에 대비하지 않고 긴급 상황 발생 시 즉흥적인 프로세스를 따릅니다.
+ 긴급 액세스 프로세스는 일반 액세스 메커니즘과 동일한 시스템(예: 중앙 집중식 ID 제공업체)을 기반으로 합니다. 즉, 이러한 시스템에 장애가 발생하면 정상 액세스 메커니즘과 긴급 액세스 메커니즘에 모두 영향을 미치고 장애 복구 능력이 저하될 수 있습니다.
+ 긴급 액세스 프로세스를 긴급하지 않은 상황에서 사용합니다. 예를 들어, 사용자는 파이프라인을 통해 변경 사항을 제출하는 것보다 직접 변경하는 것이 더 쉽기 때문에 긴급 액세스 프로세스를 자주 오용합니다.
+ 긴급 액세스 프로세스는 프로세스를 감사하기에 충분한 로그를 생성하지 않거나 프로세스의 오용 가능성에 대해 경고할 수 있도록 로그를 모니터링하지 않습니다.
**이 모범 사례 확립의 이점:**
+ 잘 문서화되고 테스트를 거친 긴급 액세스 프로세스를 갖추면 사용자가 긴급 상황에 대응하고 해결하는 데 걸리는 시간을 줄일 수 있습니다. 이를 통해 가동 중지 시간이 줄어들고 고객에게 제공하는 서비스의 가용성이 향상될 수 있습니다.
+ 각 긴급 액세스 요청을 추적하고, 프로세스를 긴급 상황이 아닌 이벤트에 악용하려는 무단 시도를 감지하고 경고를 보낼 수 있습니다.
**이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 중간
## 구현 지침
이 섹션에서는 모든 장애 모드에 적용되는 공통 지침부터 시작하여 장애 모드 유형에 따른 구체적인 지침에 이어 AWS에 배포된 워크로드와 관련된 여러 장애 모드에 대한 긴급 액세스 프로세스를 만드는 방법에 대한 지침을 제공합니다.
**모든 장애 모드에 대한 공통 지침**
장애 모드에 대한 긴급 액세스 프로세스를 설계할 때는 다음 사항을 고려하세요.
+ 프로세스의 사전 조건과 전제 조건, 즉 프로세스를 사용해야 하는 시기와 사용하지 말아야 하는 경우를 문서화하세요. 장애 모드를 자세히 설명하고 다른 관련 시스템의 상태와 같은 가정을 문서화하는 데 도움이 됩니다. 예를 들어 장애 모드 2의 프로세스에서는 ID 제공업체를 사용할 수 있지만 설정된 AWS 구성이 수정되었거나 만료된 것으로 가정합니다.
+ 긴급 액세스 프로세스에 필요한 리소스를 미리 생성합니다([SEC10-BP05](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_incident_response_pre_provision_access.html)). 예를 들어, 모든 워크로드 계정에서 IAM 사용자 및 역할과 크로스 계정 IAM 역할을 사용하여 긴급 액세스 AWS 계정을 미리 생성합니다. 이를 통해 긴급 상황 발생 시 이러한 리소스가 준비되어 있고 사용할 수 있는지 확인할 수 있습니다. 리소스를 미리 생성하면 긴급 상황에서 사용할 수 없는 AWS [컨트롤 플레인](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/control-planes-and-data-planes.html) API(AWS 리소스 생성 및 수정에 사용됨)에 대한 종속성이 없습니다. 또한 IAM 리소스를 미리 생성하면 [최종 일관성으로 인한 잠재적 지연](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_general.html#troubleshoot_general_eventual-consistency)을 고려할 필요가 없습니다.
+ 인시던트 관리 계획의 일부로 긴급 액세스 프로세스를 포함하세요([SEC10-BP02](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_incident_response_develop_management_plans.html)). 긴급 상황이 어떻게 추적되고 동료 팀, 경영진 그리고 해당하는 경우 외부 고객 및 비즈니스 파트너와 같은 조직 내 다른 사람에게 전달되는지 문서화하세요.
+ 기존 서비스 요청 워크플로 시스템(있는 경우)에서 긴급 액세스 요청 프로세스를 정의하세요. 일반적으로 이러한 워크플로우 시스템에서는 접수 양식을 만들어 요청에 대한 정보를 수집하고, 워크플로의 각 단계를 통해 요청을 추적하며, 자동 승인 단계와 수동 승인 단계를 모두 추가할 수 있습니다. 각 요청을 인시던트 관리 시스템에서 추적되는 해당 긴급 이벤트와 연관시키세요. 긴급 액세스를 위한 통일된 시스템을 구축하면 단일 시스템에서 이러한 요청을 추적하고, 사용 추세를 분석하며, 프로세스를 개선할 수 있습니다.
+ 긴급 액세스 프로세스는 승인된 사용자만 시작할 수 있고 필요에 따라 사용자의 동료 또는 경영진의 승인이 필요한지 확인하세요. 승인 절차는 업무 시간 내외에서 모두 효과적으로 운영되어야 합니다. 1차 승인자를 사용할 수 없고 승인될 때까지 관리망에 에스컬레이션되는 경우 승인 요청을 2차 승인자가 허용할 수 있는 방법을 정의합니다.
+ 긴급 액세스 프로세스 및 메커니즘에 대한 강력한 로깅, 모니터링 및 알림 메커니즘을 구현합니다. 모든 긴급 액세스 시도 성공 및 실패에 대한 자세한 감사 로그를 생성합니다. 인시던트 관리 시스템의 진행 중인 긴급 이벤트와 활동의 상관관계를 파악하고, 작업이 예상 기간을 벗어나거나 정상 운영 중에 긴급 액세스 계정이 사용되는 경우 알림을 시작합니다. 긴급 절차는 백도어로 간주될 수 있으므로 긴급 상황에만 긴급 액세스 계정에 액세스해야 합니다. 보안 정보 및 이벤트 관리(SIEM) 도구 또는 [AWS Security Hub CSPM](https://aws.amazon.com/security-hub/)와 통합하여 긴급 액세스 기간 동안 모든 활동을 보고하고 감사할 수 있습니다. 정상 작업으로 돌아가면 긴급 액세스 자격 증명을 자동으로 교체하고 관련 팀에 알립니다.
+ 긴급 액세스 프로세스를 정기적으로 테스트하여 단계가 명확한지 확인하고 올바른 액세스 수준을 빠르고 효율적으로 부여하세요. 긴급 액세스 프로세스는 인시던트 대응 시뮬레이션([SEC10-BP07](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_incident_response_run_game_days.html)) 및 재해 복구 테스트([REL13-BP03](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_dr_tested.html))의 일부로 테스트해야 합니다.
**장애 모드 1: AWS로 페더레이션에 사용된 ID 제공업체를 사용할 수 없는 경우**
[SEC02-BP04 중앙 집중식 ID 공급업체 사용](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_identity_provider.html)에서 설명한 대로, 중앙 집중식 ID 제공업체를 통해 직원을 페데레이션하여 AWS 계정에 액세스 권한을 부여하는 것이 좋습니다. IAM Identity Center를 사용하여 AWS 조직 내 여러 AWS 계정으로 페더레이션하거나 IAM을 사용하여 개별 AWS 계정에 페더레이션할 수 있습니다. 두 경우 모두, 직원이 Single Sign On을 위해 AWS 로그인 엔드포인트로 리디렉션되기 전에 중앙 집중식 ID 제공업체를 통해 인증합니다.
드문 경우지만 중앙 집중식 ID 제공업체를 사용할 수 없는 경우 직원은 AWS 계정에 페더레이션하거나 워크로드를 관리할 수 없습니다. 이 긴급 상황에서 중앙 집중식 ID 제공업체가 다시 온라인 상태가 될 때까지 기다릴 수 없는 중요한 작업을 수행할 수 있도록 소수의 관리자가 AWS 계정에 액세스할 수 있는 긴급 액세스 프로세스를 제공할 수 있습니다. 예를 들어 ID 제공업체를 4시간 동안 사용할 수 없는 경우, 예상치 못한 고객 트래픽 급증에 대처하려면 Production 계정의 Amazon EC2 Auto Scaling 그룹 상한선을 수정해야 합니다. 긴급 관리자는 긴급 액세스 프로세스에 따라 특정 프로덕션 AWS 계정에 대한 액세스 권한을 얻고 필요한 사항을 변경해야 합니다.
긴급 액세스 프로세스는 긴급 액세스 AWS 계정에만 사용되고 긴급 액세스 프로세스를 지원하는 AWS 리소스(예: IAM 역할 및 IAM 사용자)가 있는 미리 생성된 긴급 액세스를 기반으로 합니다. 정상적으로 운영되는 동안에는 아무도 긴급 액세스 계정에 접속해서는 안 되며 이 계정의 오용을 모니터링하고 경고해야 합니다(자세한 내용은 이전 공통 지침 섹션 참조).
긴급 액세스 계정에는 긴급 액세스가 필요한 AWS 계정에서 크로스 계정 역할을 수임할 수 있는 권한이 있는 긴급 액세스 IAM 역할이 있습니다. 이러한 IAM 역할은 긴급 계정의 IAM 역할을 신뢰하는 신뢰 정책으로 미리 생성되고 구성됩니다.
긴급 액세스 프로세스는 다음 방법 중 하나를 사용할 수 있습니다.
+ 긴급 액세스 계정에서 관련 강력한 암호 및 MFA 토큰을 사용하여 긴급 관리자용 [IAM 사용자](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html) 세트를 미리 생성할 수 있습니다. 이러한 IAM 사용자는 IAM 역할을 수임할 권한을 보유하고 있습니다. 이를 통해 이후 긴급 액세스가 필요한 AWS 계정에 크로스 계정 액세스를 허용합니다. 가능한 한 적은 수의 사용자를 생성하고 각 사용자를 한 명의 긴급 관리자에게 할당하는 것이 좋습니다. 긴급 상황 발생 시 긴급 관리자 사용자는 암호와 MFA 토큰 코드를 사용하여 긴급 액세스 계정에 로그인하고, 긴급 계정에서 긴급 액세스 IAM 역할로 전환하며, 마지막으로 워크로드 계정의 긴급 액세스 IAM 역할로 전환하여 긴급 변경 작업을 수행합니다. 이 접근 방식의 장점은 각 IAM 사용자가 한 명의 긴급 관리자로 할당되며 CloudTrail 이벤트를 검토하여 어떤 사용자가 로그인했는지 알 수 있다는 점입니다. 단점은 연결된 장기 암호와 MFA 토큰을 사용하여 여러 IAM 사용자를 유지 관리해야 한다는 점입니다.
+ 긴급 액세스 [AWS 계정 루트 사용자](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html)를 사용하여 긴급 액세스 계정에 로그인하고 긴급 액세스를 위한 IAM 역할을 수임하며 워크로드 계정에서 크로스 계정 역할을 수임할 수 있습니다. 루트 사용자에게는 강력한 암호와 여러 MFA 토큰을 설정하는 것이 좋습니다. 또한 강력한 인증 및 권한 부여를 시행하는 안전한 엔터프라이즈 자격 증명 볼트에 암호와 MFA 토큰을 저장하는 것이 좋습니다. 암호 및 MFA 토큰 재설정 요소를 보호해야 합니다. 계정의 이메일 주소를 클라우드 보안 관리자가 모니터링하는 이메일 배포 목록으로 설정하고 계정의 전화번호를 보안 관리자가 모니터링하는 공유 전화번호로 설정합니다. 이 접근 방식의 장점은 한 세트의 루트 사용자 자격 증명을 관리할 수 있다는 것입니다. 단점은 공유 사용자이기 때문에 여러 관리자가 루트 사용자로 로그인할 수 있다는 것입니다. 엔터프라이즈 볼트 로그 이벤트를 감사하여 루트 사용자 암호를 체크아웃한 관리자를 식별해야 합니다.
**장애 모드 2: AWS의 ID 제공업체 구성이 수정되었거나 만료된 경우**
인력 사용자가 AWS 계정에 페더레이션할 수 있도록 하려면 외부 ID 제공업체를 사용하여 IAM Identity Center를 구성하거나 IAM ID 제공업체를 생성할 수 있습니다([SEC02-BP04](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_identity_provider.html)). 일반적으로 ID 제공업체가 제공한 SAML 메타데이터 XML 문서를 가져와서 이를 구성합니다. 메타데이터 XML 문서에는 ID 제공업체가 SAML 어설션에 서명하는 데 사용하는 개인 키에 해당하는 X.509 인증서가 포함되어 있습니다.
AWS 측의 이러한 구성은 관리자가 실수로 수정하거나 삭제할 수 있습니다. 또 다른 시나리오에서는 AWS로 가져온 X.509 인증서가 만료되고 새 인증서가 포함된 새 메타데이터 XML을 AWS에 아직 가져오지 않은 경우가 있습니다. 두 시나리오 모두 인력 사용자에 대한 AWS 페더레이션을 중단하여 긴급 상황을 초래할 수 있습니다.
이러한 긴급 상황의 경우 ID 관리자에게 페더레이션 문제를 해결할 수 있는 AWS 액세스 권한을 제공할 수 있습니다. 예를 들어, ID 관리자는 긴급 액세스 프로세스를 사용하여 AWS 계정에 긴급 액세스로 로그인하고, Identity Center 관리자 계정의 역할로 전환하며, 페더레이션을 다시 활성화하기 위해 ID 제공업체로부터 최신 SAML 메타데이터 XML 문서를 가져와서 외부 ID 제공업체 구성을 업데이트합니다. 페더레이션이 수정되면 인력 사용자는 계속해서 일반 운영 프로세스를 사용하여 워크로드 계정에 페더레이션합니다.
이전 장애 모드 1에 설명된 접근 방식에 따라 긴급 액세스 프로세스를 만들 수 있습니다. ID 관리자에게 Identity Center 관리자 계정에만 액세스하고 해당 계정의 Identity Center에서 작업을 수행할 수 있는 최소 권한 권한을 부여할 수 있습니다.
**장애 모드 3: Identity Center 중단**
IAM Identity Center의 예상치 못한 상황이나 AWS 리전 중단이 발생할 경우 AWS Management Console에 임시 액세스를 제공하는 데 사용할 수 있는 구성을 설정하는 것이 좋습니다.
긴급 액세스 프로세스는 ID 제공업체로부터 긴급 계정의 IAM으로 직접 페더레이션을 사용합니다. 프로세스 및 설계 고려 사항에 대한 자세한 내용은 [Set up emergency access to the AWS Management Console](https://docs.aws.amazon.com/singlesignon/latest/userguide/emergency-access.html)을 참조하세요.
### 구현 단계
**모든 장애 모드에 대한 공통 단계**
+ 긴급 액세스 프로세스 AWS 계정 전용 프로세스를 생성합니다. 계정에 필요한 IAM 리소스(예: IAM 역할 또는 IAM 사용자) 및 선택적으로 IAM ID 제공업체를 미리 생성합니다. 또한 긴급 액세스 계정의 해당 IAM 역할과의 신뢰 관계를 사용하여 워크로드 AWS 계정에서 크로스 계정 IAM 역할을 미리 생성합니다. [AWS Organizations에서 CloudFormation StackSets](https://docs.aws.amazon.com/organizations/latest/userguide/services-that-can-integrate-cloudformation.html)를 사용하여 조직의 구성원 계정에서 이러한 리소스를 만들 수 있습니다.
+ AWS Organizations [서비스 제어 정책](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)(SCP)을 생성하여 구성원 AWS 계정에서 크로스 계정 IAM 역할의 삭제 및 수정을 거부합니다.
+ 긴급 액세스 AWS 계정에 대해 CloudTrail을 활성화하고 로그 컬렉션 AWS 계정에서 중앙 S3 버킷으로 트레일 이벤트를 전송합니다. AWS Control Tower를 사용하여 AWS 다중 계정 환경을 설정하고 관리하는 경우 AWS Control Tower를 사용하여 생성하거나 AWS Control Tower에 등록한 모든 계정에서는 기본적으로 CloudTrail이 활성화되고 전용 로그 아카이브 AWS 계정의 S3 버킷으로 전송됩니다.
+ 긴급 IAM 역할별로 콘솔 로그인 및 API 활동과 일치하는 EventBridge 규칙을 생성하여 긴급 액세스 계정의 활동을 모니터링합니다. 인시던트 관리 시스템에서 추적되는 진행 중인 긴급 이벤트 외부에서 활동이 발생하는 경우 보안 운영 센터에 알림을 보냅니다.
**장애 모드 1: AWS로 페더레이션에 사용된 ID 제공업체를 사용할 수 없는 경우 및 장애 모드 2: AWS의 ID 제공업체 구성이 수정되었거나 만료된 경우의 추가 단계**
+ 긴급 액세스를 위해 선택한 메커니즘에 따라 리소스를 미리 생성하세요.
+ **IAM 사용자 사용:** 강력한 암호 및 관련 MFA 디바이스를 사용하여 IAM 사용자를 미리 생성하세요.
+ **긴급 계정 루트 사용자 사용:** 강력한 암호로 루트 사용자를 구성하고 엔터프라이즈 자격 증명 저장소에 암호를 저장합니다. 여러 물리적 MFA 디바이스를 루트 사용자와 연결하고 긴급 관리자 팀원이 빠르게 액세스할 수 있는 위치에 디바이스를 저장합니다.
**장애 모드 3: Identity Center 중단의 추가 단계**
+ [AWS Management Console에 대한 긴급 액세스 설정](https://docs.aws.amazon.com/singlesignon/latest/userguide/emergency-access.html)에서 설명한 대로, 긴급 액세스 AWS 계정에서는 ID 제공업체로부터 직접 SAML 페더레이션을 활성화하도록 IAM ID 제공업체를 생성합니다.
+ IdP에 구성원 없이 긴급 운영 그룹을 만드세요.
+ 긴급 액세스 계정에서 긴급 운영 그룹에 해당하는 IAM 역할을 생성합니다.
## 리소스
**관련 Well-Architected 모범 사례:**
+ [SEC02-BP04 중앙 집중식 ID 공급업체 사용](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_identities_identity_provider.html)
+ [SEC03-BP02 최소 권한 액세스 부여](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_permissions_least_privileges.html)
+ [SEC10-BP02 인시던트 관리 계획 개발](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_incident_response_develop_management_plans.html)
+ [SEC10-BP07 게임 데이 진행](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_incident_response_run_game_days.html)
**관련 문서:**
+ [Set up emergency access to the AWS Management Console](https://docs.aws.amazon.com/singlesignon/latest/userguide/emergency-access.html)
+ [SAML 2.0 페더레이션 사용자가 AWS Management Console에 액세스할 수 있게 하기](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_enable-console-saml.html)
+ [Break glass access](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/break-glass-access.html)
**관련 비디오:**
+ [AWS re:Invent 2022 - Simplify your existing workforce access with IAM Identity Center](https://youtu.be/TvQN4OdR_0Y)
+ [AWS re:Inforce 2022 - AWS Identity and Access Management (IAM) deep dive](https://youtu.be/YMj33ToS8cI)
**관련 예제:**
+ [AWS Break Glass Role](https://github.com/awslabs/aws-break-glass-role)
+ [AWS customer playbook framework](https://github.com/aws-samples/aws-customer-playbook-framework)
+ [AWS incident response playbook samples](https://github.com/aws-samples/aws-incident-response-playbooks)
# SEC03-BP04 지속적으로 권한 축소
팀에서 필요한 액세스 권한을 결정할 때 불필요한 권한을 제거하고 최소 권한을 부여하기 위한 검토 프로세스를 수립합니다. 인적 액세스와 시스템 액세스 모두에 대해 사용되지 않는 ID와 권한을 지속적으로 모니터링하고 제거합니다.
**원하는 성과:** 권한 정책은 최소 권한 원칙을 준수해야 합니다. 직무와 역할이 더 잘 정의됨에 따라 권한 정책을 검토하여 불필요한 권한을 제거해야 합니다. 이 접근 방식은 자격 증명이 의도치 않게 노출되거나 권한 부여 없이 액세스되는 경우 영향 범위를 줄입니다.
**일반적인 안티 패턴:**
+ 사용자에게 기본적으로 관리자 권한을 부여합니다.
+ 전체 관리자 권한은 아니지만 과도하게 허용적인 정책을 생성합니다.
+ 더 이상 필요하지 않은 권한 정책을 유지합니다.
**이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 중간
## 구현 지침
팀과 프로젝트가 이제 막 시작되었으므로 허용 권한 정책을 사용하여 혁신과 민첩성을 확보할 수 있습니다. 예를 들어 개발 또는 테스트 환경에서 개발자에게 광범위한 AWS 서비스에 대한 액세스 권한을 부여할 수 있습니다. 액세스 권한을 지속적으로 평가하고 현재 작업을 완료하는 데 필요한 서비스 및 서비스 작업으로만 액세스 권한을 제한하는 것이 좋습니다. 인적 자격 증명과 시스템 자격 증명 모두에 대해 이 평가가 권장됩니다. 시스템 또는 서비스 계정이라고도 하는 시스템 자격 증명은 AWS에 애플리케이션 또는 서버에 대한 액세스 권한을 부여하는 자격 증명입니다. 지나친 허용 권한은 광범위한 영향을 미치고 잠재적으로 고객 데이터를 노출시킬 수 있으므로 이 액세스 권한은 프로덕션 환경에서 특히 중요합니다.
AWS는 사용되지 않는 사용자, 역할, 권한 및 자격 증명을 식별하는 데 도움이 되는 여러 방법을 제공합니다. AWS는 또한 연결된 액세스 키와 Amazon S3 버킷의 객체와 같은 AWS 리소스에 대한 액세스 권한을 포함하여 IAM 사용자 및 역할의 액세스 활동을 분석하는 데 도움이 될 수 있습니다. AWS Identity and Access Management Access Analyzer 정책 생성은 보안 주체가 상호 작용하는 실제 서비스 및 작업을 기반으로 제한적 권한 정책을 생성하는 데 도움이 될 수 있습니다. [ABAC(속성 기반 액세스 제어)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)는 권한 정책을 각 사용자에게 직접 연결하는 대신 속성을 사용하여 사용자에게 권한을 제공할 수 있으므로 권한 관리를 간소화하는 데 도움이 됩니다.
### 구현 단계
+ **[AWS Identity and Access Management Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html) 사용:** IAM Access Analyzer를 사용하면 Amazon Simple Storage Service(S3) 버킷 또는 IAM 역할과 같은 조직 및 계정 내 리소스 중 [외부 엔터티와 공유](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-getting-started.html)되는 리소스를 식별할 수 있습니다.
+ **[IAM Access Analyzer 정책 생성](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html) 사용:** IAM Access Analyzer 정책 생성을 통해 [IAM 사용자 또는 역할의 액세스 활동에 따라 세분화된 권한 정책을 생성](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html#access-analyzer-policy-generation-howitworks)할 수 있습니다.
+ **프로덕션 전 하위 환경의 권한 테스트:** 먼저 [덜 중요한 샌드박스 및 개발 환경](https://docs.aws.amazon.com/prescriptive-guidance/latest/choosing-git-branch-approach/understanding-the-devops-environments.html)을 사용하여 IAM Access Analyzer를 사용하여 다양한 작업 기능에 필요한 권한을 테스트하는 것으로 시작합니다. 그런 다음 프로덕션에 적용하기 전에 테스트, 품질 보증 및 스테이징 환경 전반에서 이러한 권한을 점진적으로 더 엄격하게 하고 검증합니다. 서비스 제어 정책(SCP)이 부여된 최대 권한을 제한하여 가드레일을 적용하므로 하위 환경은 처음에 더 완화된 권한을 가질 수 있습니다.
+ **IAM 사용자 및 역할에 대해 허용되는 기간 및 사용 정책 결정:** [마지막으로 액세스한 타임스탬프](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor-view-data.html)를 사용하여 [사용되지 않는 사용자 및 역할을 식별](https://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 S3 작업을 식별하여 그러한 작업으로만 역할의 액세스 권한을 제한할 수 있습니다. 마지막 액세스 정보 기능은 AWS Management Console에서 제공되며, 프로그래밍 방식으로 인프라 워크플로 및 자동화된 도구에 손쉽게 통합할 수 있습니다.
+ **[AWS CloudTrail에서 데이터 이벤트 로깅](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/logging-data-events-with-cloudtrail.html) 고려:** 기본적으로 CloudTrail은 Amazon S3 객체 수준 활동(예: `GetObject` 및 `DeleteObject`) 또는 Amazon DynamoDB 테이블 활동(예: `PutItem` 및 `DeleteItem`)과 같은 데이터 이벤트를 로깅하지 않습니다. 특정 Amazon S3 객체 또는 DynamoDB 테이블 항목에 액세스해야 하는 사용자 및 역할을 결정하려면 이러한 이벤트에 대한 로깅을 활성화하는 방법을 고려하세요.
## 리소스
**관련 문서:**
+ [최소 권한 적용](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)
+ [란 무엇인가요?AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html)
+ [정책 작업](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage.html)
+ [ DynamoDB의 로깅 및 모니터링 ](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/MonitoringDynamoDB.html)
+ [ Amazon S3 버킷 및 객체에 대한 CloudTrail 이벤트 로깅 사용 ](https://docs.aws.amazon.com/AmazonS3/latest/userguide/enable-cloudtrail-logging-for-s3.html)
+ [ 의 자격 증명 보고서 가져오기 AWS 계정](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_getting-report.html)
**관련 비디오:**
+ [Become an IAM Policy Master in 60 Minutes or Less](https://youtu.be/YQsK4MtsELU)
+ [Separation of Duties, Least Privilege, Delegation, and CI/CD](https://youtu.be/3H0i7VyTu70)
+ [AWS re:Inforce 2022 - AWS Identity and Access Management (IAM) deep dive ](https://www.youtube.com/watch?v=YMj33ToS8cI)
# SEC03-BP05 조직에 대한 권한 가드레일 정의
권한 가드레일을 사용하여 보안 주체에 부여할 수 있는 사용 가능한 권한의 범위를 줄이세요. 권한 정책 평가 체인에는 권한 부여 결정을 내릴 때 보안 주체의 *유효 권한*을 결정하기 위한 가드레일이 포함됩니다. 계층 기반 접근 방식을 사용하여 가드레일을 정의할 수 있습니다. 가드레일 중 일부는 조직 전체에 광범위하게 적용하고 일부는 임시 액세스 세션에 세부적으로 적용하세요.
**원하는 성과:** 별도의 AWS 계정을 사용하여 환경을 명확하게 격리할 수 있습니다. 서비스 제어 정책(SCP)은 조직 전체의 권한 가드레일을 정의하는 데 사용됩니다. 더 포괄적인 가드레일은 조직 루트에 가장 근접한 계층 수준에서 설정되고, 더 엄격한 가드레일은 개별 계정 수준에 더 가깝게 설정됩니다.
지원되는 경우 리소스 정책은 보안 주체가 리소스에 액세스하기 위해 충족해야 하는 조건을 정의합니다. 또한, 리소스 정책은 적절한 경우 허용 가능한 작업 집합의 범위를 세분화합니다. 권한 경계는 워크로드 권한을 관리하는 보안 주체에 부여되어 권한 관리를 개별 워크로드 소유자에게 위임합니다.
**일반적인 안티 패턴:**
+ [AWS Organization](https://aws.amazon.com/organizations/) 내에서 구성원 AWS 계정을 생성하지만, 루트 자격 증명에 이용할 수 있는 사용 및 권한을 제한하기 위해 SCP를 사용하지 않습니다.
+ 최소 권한을 기준으로 권한을 할당하지만, 부여할 수 있는 최대 권한 집합에는 가드레일을 설정하지 않습니다.
+ AWS IAM의 *암묵적 거부* 기반에 의존하여 권한을 제한하고, 정책이 원치 않는 *명시적 허용* 권한을 부여하지 않을 것이라고 신뢰합니다.
+ 동일한 AWS 계정에서 여러 워크로드 환경을 실행한 후 VPC, 태그 또는 리소스 정책 등의 메커니즘에 의존하여 권한 경계를 적용합니다.
**이 모범 사례 확립의 이점:** 권한 가드레일은 권한 정책이 허용을 시도하더라도 원하지 않는 권한을 부여할 수 없다는 확신을 심어줍니다. 이를 통해 고려해야 할 권한의 최대 범위를 줄여 권한 정의 및 관리를 단순화할 수 있습니다.
**이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 중간
## 구현 지침
계층 기반 접근 방식을 사용하여 조직의 권한 가드레일을 정의하는 것이 좋습니다. 이 접근 방식은 추가 계층이 적용될 때 가능한 최대 권한 집합을 체계적으로 줄입니다. 이렇게 하면 최소 권한 원칙에 따라 액세스 권한을 부여하여 잘못된 정책 구성으로 인해 의도하지 않은 액세스가 발생할 위험을 줄일 수 있습니다.
권한 가드레일을 구축하는 첫 단계는 워크로드와 환경을 별도의 AWS 계정으로 분리하는 것입니다. 한 계정의 보안 주체는 명시적인 권한 없이는 다른 계정의 리소스에 액세스할 수 없습니다. 이는 두 계정이 동일한 AWS 조직 또는 동일한 [조직 단위(OU)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_ous.html)에 속하더라도 마찬가지입니다. OU를 사용하여 관리하려는 계정을 단일 단위로 그룹화할 수 있습니다.
다음 단계는 조직 구성원 계정 내에서 보안 주체에 부여할 수 있는 최대 권한 집합을 줄이는 것입니다. 이를 위해 OU 또는 계정에 적용 가능한 [서비스 제어 정책(SCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)을 사용할 수 있습니다. SCP는 특정 AWS 리전에 대한 액세스 제한과 같은 일반적인 액세스 제어를 시행하여 리소스 삭제를 방지하거나 잠재적으로 위험한 서비스 작업을 비활성화하도록 할 수 있습니다. 조직의 루트에 적용하는 SCP는 구성원 계정에만 영향을 주고 관리 계정에는 영향을 주지 않습니다. SCP는 조직 내 보안 주체만 관리합니다. SCP는 리소스에 액세스하는 조직 외부의 보안 주체를 관리하지 않습니다.
[AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html)를 사용하는 경우 [제어](https://docs.aws.amazon.com/controltower/latest/userguide/how-control-tower-works.html#how-controls-work) 및 [랜딩 존](https://docs.aws.amazon.com/controltower/latest/userguide/aws-multi-account-landing-zone.html)을 권한 가드레일 및 다중 계정 환경의 기반으로 활용할 수 있습니다. 랜딩 존은 다양한 워크로드 및 애플리케이션에 대한 별도의 계정을 갖춘 사전 구성된 안전한 기준 환경을 제공합니다. 가드레일은 서비스 제어 정책(SCP), AWS Config 규칙 및 기타 구성의 조합을 통해 보안, 운영 및 규정 준수에 대한 필수 제어를 적용합니다. 그러나 사용자 지정 조직 SCP와 함께 Control Tower 가드레일 및 랜딩 존을 사용하는 경우 충돌을 방지하고 적절한 거버넌스를 보장하기 위해 AWS 설명서에 설명된 모범 사례를 따르는 것이 중요합니다. Control Tower 환경 내에서 SCP, 계정 및 조직 단위(OU)를 관리하는 방법에 대한 자세한 권장 사항은 의 [AWS Control Tower guidance for AWS Organizations](https://docs.aws.amazon.com/controltower/latest/userguide/orgs-guidance.html) 섹션을 참조하세요.
이러한 지침을 준수하면 Control Tower의 가드레일, 랜딩 존 및 사용자 지정 SCP를 효과적으로 활용하는 동시에 잠재적 충돌을 완화하고 다중 계정 AWS 환경에 대한 적절한 거버넌스 및 제어를 보장할 수 있습니다.
다음 단계는 [IAM 리소스 정책](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_resource-based)을 사용하여 보안 주체 대행이 충족해야 하는 모든 조건과 함께 관리하는 리소스에서 수행할 수 있는 작업 범위를 지정하는 것입니다. 이는 보안 주체가 조직의 일원인 경우(PrincipalOrgId [조건 키](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) 사용) 모든 작업을 허용하는 것만큼 광범위할 수도 있고, 특정 IAM 역할의 특정 작업만 허용하는 것처럼 세밀할 수도 있습니다. IAM 역할 신뢰 정책의 조건을 사용하여 비슷한 접근 방식을 취할 수 있습니다. 리소스 또는 역할 신뢰 정책에서 해당 리소스나 정책이 관리하는 역할이나 리소스와 동일한 계정의 보안 주체를 명시적으로 지정하는 경우, 해당 보안 주체에는 같은 권한을 부여하는 연결된 IAM 정책이 필요하지 않습니다. 보안 주체가 리소스와 다른 계정에 있는 경우 보안 주체에 해당 권한을 부여하는 연결된 IAM 정책이 필요합니다.
워크로드 팀은 워크로드에 필요한 권한을 관리하고자 하는 경우가 많습니다. 이를 위해서는 새 IAM 역할 및 권한 정책을 만들어야 할 수도 있습니다. 팀이 [IAM 권한 경계](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html)에서 부여할 수 있는 최대 권한 범위를 캡처하고, 이 문서를 팀이 IAM 역할 및 권한을 관리하는 데 사용할 수 있는 IAM 역할에 연결할 수 있습니다. 이러한 접근 방식을 통해 IAM 관리 액세스로 인한 위험을 완화하면서 작업을 완료하는 유연성을 제공할 수 있습니다.
보다 세분화된 단계는 *권한 있는 액세스 관리*(PAM) 및 *임시 승격 액세스 관리*(TEAM) 기술을 구현하는 것입니다. 보안 주체가 권한 있는 작업을 수행하기 전에 다중 인증을 수행하도록 요구하는 것을 PAM의 예로 들 수 있습니다. 자세한 내용은 [Configuring MFA-protected API access](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html)를 참조하세요. TEAM에는 보안 주체에 상위 액세스 권한을 부여할 수 있는 승인 및 기간을 관리하는 솔루션이 필요합니다. 한 가지 방법은 액세스 권한이 승격된 IAM 역할에 대한 역할 신뢰 정책에 보안 주체를 임시로 추가하는 것입니다. 또 다른 방법은 정상적인 운영 상태에서 [세션 정책](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session)을 사용하여 IAM 역할이 보안 주체에 부여한 권한의 범위를 좁힌 다음 승인된 기간에 이 제한을 일시적으로 해제하는 것입니다. AWS 및 일부 파트너가 검증한 솔루션에 대해 자세히 알아보려면 [Temporary elevated access](https://docs.aws.amazon.com/singlesignon/latest/userguide/temporary-elevated-access.html)를 참조하세요.
### 구현 단계
1. 워크로드와 환경을 별도의 AWS 계정으로 분리합니다.
1. SCP를 사용하여 조직 구성원 계정 내에서 보안 주체에 부여할 수 있는 최대 권한 집합을 줄이세요.
1. SCP를 정의하여 조직의 멤버 계정 내 보안 주체에게 부여할 수 있는 최대 권한 세트를 줄일 때 *허용 목록* 또는 *거부 목록* 접근 방식 중에서 선택할 수 있습니다. 허용 목록 전략은 허용되는 액세스를 명시적으로 지정하고 다른 모든 액세스를 암시적으로 차단합니다. 거부 목록 전략은 허용되지 않는 액세스를 명시적으로 지정하고 기본적으로 다른 모든 액세스를 허용합니다. 두 전략 모두 장단점이 있으며 적절한 선택은 조직의 특정 요구 사항과 위험 모델에 따라 달라집니다. 자세한 내용은 [Strategy for using SCPs](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_strategies.html)를 참조하세요.
1. 또한 [Service control policy examples](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html)도 검토하여 SCP를 효과적으로 구성하는 방법을 이해하세요.
1. IAM 리소스 정책을 사용하여 리소스에 허용된 작업의 범위를 좁히고 조건을 지정할 수 있습니다. IAM 역할 신뢰 정책의 조건을 사용하여 역할 수임에 대한 제한을 만드세요.
1. IAM 역할에 IAM 권한 경계를 할당하면 워크로드 팀이 자체 워크로드 IAM 역할 및 권한을 관리하는 데 사용할 수 있습니다.
1. 필요에 따라 PAM 및 TEAM 솔루션을 평가하세요.
## 리소스
**관련 문서:**
+ [Data perimeters on AWS](https://aws.amazon.com/identity/data-perimeters-on-aws/)
+ [Establish permissions guardrails using data perimeters](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_data-perimeters.html)
+ [정책 평가 로직](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html)
**관련 예제:**
+ [Service control policy examples](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html)
**관련 도구:**
+ [AWS Solution: Temporary Elevated Access Management](https://aws-samples.github.io/iam-identity-center-team/)
+ [Validated security partner solutions for TEAM](https://docs.aws.amazon.com/singlesignon/latest/userguide/temporary-elevated-access.html#validatedpartners)
# SEC03-BP06 수명 주기에 따라 액세스 관리
조직 내 전체 수명 주기 동안 보안 주체(사용자, 역할, 그룹)에게 부여된 권한을 모니터링하고 조정합니다. 사용자의 역할이 변경됨에 따라 그룹 멤버십을 조정하고, 사용자가 조직을 떠나면 액세스 권한을 제거하세요.
**원하는 성과:** 조직 내 보안 주체의 수명 주기 전반에 걸쳐 권한을 모니터링하고 조정하여 불필요한 권한이 부여될 위험을 줄입니다. 사용자를 생성할 때 적절한 액세스 권한을 부여합니다. 사용자의 책임이 변경되면 액세스 권한을 수정하고, 사용자가 더 이상 활동하지 않거나 조직을 떠난 경우 액세스 권한을 제거합니다. 사용자, 역할 및 그룹에 대한 변경 사항을 중앙에서 관리합니다. 자동화를 사용하여 변경 사항을 AWS 환경에 전파합니다.
**일반적인 안티 패턴:**
+ 처음에 필요한 것 이상으로 과도하거나 광범위한 액세스 권한을 자격 증명에 미리 부여합니다.
+ 시간이 지남에 따라 자격 증명의 역할과 책임이 변경되어도 액세스 권한을 검토하고 조정하지 않습니다.
+ 활동하지 않거나 퇴사한 직원 자격 증명의 활성 액세스 권한을 그대로 둡니다. 이로 인해 무단 액세스의 위험이 증가합니다.
+ 자격 증명의 수명 주기를 관리하는 데 자동화를 활용하지 않습니다.
**이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 중간
## 구현 가이드
ID(예: 사용자, 역할, 그룹)의 수명 주기 전반에 걸쳐 부여한 액세스 권한을 신중하게 관리하고 조정하세요. 이 수명 주기에는 초기 온보딩 단계, 역할 및 책임의 지속적인 변경, 최종 오프보딩 또는 해고가 포함됩니다. 수명 주기 단계에 따라 액세스를 사전 예방적으로 관리하여 적절한 액세스 수준을 유지하세요. 최소 권한 원칙을 준수하여 과도하거나 불필요한 액세스 권한으로 인해 발생하는 위험을 줄입니다.
AWS 계정 내에서 직접 IAM 사용자의 수명 주기를 관리하거나 직원 ID 제공업체에서 [AWS IAM Identity Center](https://aws.amazon.com/iam/identity-center/)로의 페더레이션을 통해 관리할 수 있습니다. IAM 사용자의 경우 AWS 계정 내에서 사용자 및 관련 권한을 생성, 수정 및 삭제할 수 있습니다. 페더레이션 사용자의 경우 IAM Identity Center를 사용하여 [System for Cross-domain Identity Management](https://docs.aws.amazon.com/singlesignon/latest/developerguide/what-is-scim.html)(SCIM) 프로토콜을 통해 조직 ID 제공업체의 사용자 및 그룹 정보를 동기화하여 수명 주기를 관리할 수 있습니다.
SCIM은 다양한 시스템에서 사용자 ID를 자동 프로비저닝하고 프로비저닝 해제하기 위한 개방형 표준 프로토콜입니다. SCIM을 통해 ID 제공업체와 IAM Identity Center를 통합하여 사용자 및 그룹 정보를 자동으로 동기화함으로써 조직의 권한 있는 ID 소스의 변경 사항에 따라 액세스 권한이 부여, 수정 또는 취소되는지 확인할 수 있습니다.
조직 내에서 직원의 역할과 책임이 변경되면 그에 따라 액세스 권한을 조정하세요. IAM Identity Center의 권한 집합을 사용하여 다양한 직무 역할 또는 책임을 정의하고 적절한 IAM 정책 및 권한에 연결할 수 있습니다. 직원의 역할이 변경되면 새로운 담당 업무를 반영하도록 지정된 권한 집합을 업데이트할 수 있습니다. 최소 권한 원칙을 준수하면서 필요한 액세스 권한이 부여되었는지 확인하세요.
### 구현 단계
1. 초기 액세스 권한 부여, 정기 검토, 오프보딩 절차를 비롯한 액세스 관리 수명 주기 프로세스를 정의하고 문서화합니다.
1. [IAM 역할, 그룹 및 권한 경계](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html)를 구현하여 액세스 권한을 집합적으로 관리하고 최대 허용 액세스 수준을 적용합니다.
1. IAM Identity Center를 사용하여 사용자 및 그룹 정보의 권한 있는 소스로 [페더레이션 ID 제공업체](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html)(예: Microsoft Active Directory, Okta, Ping Identity)와 통합합니다.
1. [SCIM](https://docs.aws.amazon.com/singlesignon/latest/developerguide/what-is-scim.html) 프로토콜을 사용하여 ID 제공업체의 사용자 및 그룹 정보를 IAM Identity Center의 자격 증명 스토어로 동기화합니다.
1. 조직 내의 다양한 직무 역할 또는 책임을 나타내는 [권한 집합](https://docs.aws.amazon.com/singlesignon/latest/userguide/permissionsetsconcept.html)을 IAM Identity Center에서 생성합니다. 각 권한 집합에 적합한 IAM 정책 및 권한을 정의합니다.
1. 정기적인 액세스 검토, 신속한 액세스 취소, 액세스 관리 수명 주기 프로세스의 지속적인 개선을 구현합니다.
1. 직원에게 액세스 관리 모범 사례를 주제로 교육을 제공하고 인식을 제고합니다.
## 리소스
**관련 모범 사례:**
+ [SEC02-BP04 중앙 집중식 ID 공급업체 사용](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_identities_identity_provider.html)
**관련 문서:**
+ [Manage your identity source ](https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source.html)
+ [Manage identities in IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-sso.html)
+ [AWS Identity and Access Management Access Analyzer 사용](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html)
+ [IAM Access Analyzer policy generation](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html)
**관련 비디오:**
+ [AWS re:Inforce 2023 - Manage temporary elevated access with AWS IAM Identity Center](https://www.youtube.com/watch?v=a1Na2G7TTQ0)
+ [AWS re:Invent 2022 - Simplify your existing workforce access with IAM Identity Center](https://www.youtube.com/watch?v=TvQN4OdR_0Y&t=444s)
+ [AWS re:Invent 2022 - Harness power of IAM policies & rein in permissions w/Access Analyzer](https://www.youtube.com/watch?v=x-Kh8hKVX74&list=PL2yQDdvlhXf8bvQJuSP1DQ8vu75jdttlM&index=11)
# SEC03-BP07 퍼블릭 및 크로스 계정 액세스 분석
퍼블릭 및 크로스 계정 액세스를 강조하는 결과를 지속적으로 모니터링합니다. 이 유형의 액세스가 필요한 리소스만 허용하도록 퍼블릭 액세스 및 크로스 계정 액세스를 줄입니다.
**원하는 성과:** 어떤 AWS 리소스가 누구와 공유되는지 파악합니다. 공유 리소스를 지속적으로 모니터링하고 감사하여 권한이 부여된 보안 주체와만 공유되는지 확인합니다.
**일반적인 안티 패턴:**
+ 공유 리소스의 인벤토리를 유지하지 않습니다.
+ 크로스 계정 또는 리소스에 대한 퍼블릭 액세스를 승인하는 프로세스를 따르지 않습니다.
**이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 낮음
## 구현 지침
계정이 AWS Organizations에 있는 경우 전체 조직, 특정 조직 단위 또는 개별 계정에 리소스에 대한 액세스 권한을 부여할 수 있습니다. 계정이 조직의 구성원이 아닌 경우 개별 계정과 리소스를 공유할 수 있습니다. 리소스 기반 정책(예: [Amazon Simple Storage Service(S3) 버킷 정책](https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucket-policies.html))을 사용하거나 다른 계정의 보안 주체가 사용자 계정의 IAM 역할을 수임하도록 허용하여 직접 크로스 계정 액세스 권한을 부여할 수 있습니다. 리소스 정책을 사용할 때 권한이 부여된 보안 주체에게만 액세스 권한이 부여되는지 확인합니다. 공개적으로 사용 가능해야 하는 모든 리소스를 승인하는 프로세스를 정의합니다.
[AWS Identity and Access Management 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를 사용하면 리소스 권한을 배포하기 전에 [조사 결과를 미리 볼 수 있습니다](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/)을 사용하여 역할을 수임할 수 있는 사례를 제어할 수 있습니다. 예를 들어 [`PrincipalOrgId` 조건 키를 사용하여 AWS Organizations 외부에서 역할을 수임하려는 시도를 거부할 수 있습니다](https://aws.amazon.com/blogs/security/how-to-use-trust-policies-with-iam-roles/).
[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/what-is-securityhub.html)와 같은 서비스는 AWS Organizations에서 탐지 제어 및 가드레일을 배포하기만 하면 공개적으로 노출된 리소스를 파악 및 개선할 수 있습니다. 예를 들어 AWS Control Tower에는 [Amazon EBS 스냅샷이 AWS 계정에 의해 복원 가능한지](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html) 감지할 수 있는 관리형 가드레일이 있습니다.
### 구현 단계
+ **[AWS Organizations에 대해 AWS Config](https://docs.aws.amazon.com/organizations/latest/userguide/services-that-can-integrate-config.html) 사용 고려:** AWS Config를 사용하면 AWS Organizations 내의 여러 계정에서 찾은 조사 결과를 위임된 관리자 계정으로 집계할 수 있습니다. 이는 포괄적인 보기를 제공하고 [계정 전체에 AWS Config 규칙 규칙를 배포하여 퍼블릭 액세스가 구성된 리소스를 감지](https://docs.aws.amazon.com/config/latest/developerguide/config-rule-multi-account-deployment.html)할 수 있습니다.
+ **AWS Identity and Access Management Access Analyzer 구성:** IAM Access Analyzer는 조직 및 계정에서 Amazon S3 버킷 또는 IAM 역할과 같이 [외부 엔터티와 공유](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-getting-started.html)되는 리소스를 식별하는 데 도움이 됩니다.
+ **AWS Config에서 자동 수정을 사용하여 Amazon S3 버킷의 퍼블릭 액세스 구성 변경에 대응:** [Amazon S3 버킷에 대한 퍼블릭 액세스 차단 설정을 자동으로 활성화할 수 있습니다.](https://aws.amazon.com/blogs/security/how-to-use-aws-config-to-monitor-for-and-respond-to-amazon-s3-buckets-allowing-public-access/)
+ **모니터링 및 알림을 구현하여 Amazon S3 버킷이 공개되었는지 확인:** Amazon S3 퍼블릭 액세스 차단이 비활성화된 시점과 Amazon S3 버킷이 공개되었는지 확인하기 위해 [모니터링 및 알림 설정](https://aws.amazon.com/blogs/aws/amazon-s3-update-cloudtrail-integration/)을 구현해야 합니다. 또한 AWS Organizations를 사용하는 경우 Amazon S3 퍼블릭 액세스 정책의 변경을 방지하는 [서비스 제어 정책](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)을 생성할 수 있습니다. [AWS Trusted Advisor](https://docs.aws.amazon.com/awssupport/latest/user/trusted-advisor.html)는 열기 액세스 권한이 있는 Amazon S3 버킷을 확인합니다. 모든 사용자에게 업로드 또는 삭제 액세스 권한을 부여하는 버킷 권한은 모든 사용자가 버킷 항목을 추가하거나, 수정하거나, 제거할 수 있도록 허용하여 잠재적 보안 문제가 발생하는 원인이 됩니다. Trusted Advisor 검사에서는 명시적인 버킷 권한뿐 아니라 버킷 권한을 재정의할 수 있는 관련 버킷 정책도 확인합니다. 또한 AWS Config를 사용하여 퍼블릭 액세스에 대해 Amazon S3 버킷을 모니터링할 수 있습니다. 자세한 내용은 [How to Use AWS Config to Monitor for and Respond to Amazon S3 Buckets Allowing Public Access](https://aws.amazon.com/blogs/security/how-to-use-aws-config-to-monitor-for-and-respond-to-amazon-s3-buckets-allowing-public-access/)를 참조하세요.
Amazon S3 버킷에 대한 액세스 제어를 검토할 때 버킷 내에 저장된 데이터의 특성을 고려하는 것이 중요합니다. [Amazon Macie](https://docs.aws.amazon.com/macie/latest/user/findings-types.html)는 개인 식별 정보(PII), 보호 대상 건강 정보(PHI), 프라이빗 키 또는 AWS 액세스 키 등의 자격 증명과 같은 민감한 데이터를 검색하고 보호하는 데 도움이 되도록 설계된 서비스입니다.
## 리소스
**관련 문서:**
+ [ 사용하기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 controls library ](https://docs.aws.amazon.com/controltower/latest/userguide/controls-reference.html)
+ [AWS Foundational Security Best Practices standard](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 check reference](https://docs.aws.amazon.com/awssupport/latest/user/trusted-advisor-check-reference.html)
+ [ Monitoring AWS Trusted Advisor check results with Amazon EventBridge ](https://docs.aws.amazon.com/awssupport/latest/user/cloudwatch-events-ta.html)
+ [ Managing AWS Config Rules Across All Accounts in Your Organization ](https://docs.aws.amazon.com/config/latest/developerguide/config-rule-multi-account-deployment.html)
+ [AWS Config 및 AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/services-that-can-integrate-config.html)
+ [ AMI를 Amazon EC2에서 공개적으로 사용할 수 있도록 설정 ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/sharingamis-intro.html#block-public-access-to-amis)
**관련 비디오:**
+ [Best Practices for securing your multi-account environment](https://www.youtube.com/watch?v=ip5sn3z5FNg)
+ [Dive Deep into IAM Access Analyzer](https://www.youtube.com/watch?v=i5apYXya2m0)
# SEC03-BP08 안전하게 조직과 리소스 공유
워크로드 수가 증가함에 따라 해당 워크로드의 리소스에 대한 액세스 권한을 공유하거나 여러 계정에서 리소스를 여러 번 프로비저닝해야 할 수 있습니다. 개발, 테스트 및 프로덕션 환경과 같이 환경을 분리하는 구성이 있을 수 있습니다. 그러나 분리 구성을 적용한다고 해서 안전하게 공유하지 못하는 것은 아닙니다. 겹치는 구성 요소를 공유하면 운영 오버헤드를 줄일 수 있고 동일한 리소스를 여러 번 생성하는 동안 누락된 부분을 추측하지 않고도 일관된 경험을 제공할 수 있습니다.
**원하는 성과:** 안전한 방법을 사용하여 조직 내에서 리소스를 공유하고 데이터 손실 방지 이니셔티브를 지원하여 의도치 않은 액세스를 최소화합니다. 개별 구성 요소를 관리하는 것에 비해 운영 오버헤드를 줄이고 동일한 구성 요소를 수동으로 여러 번 생성할 때 발생하는 오류를 줄이며 워크로드의 확장성을 높입니다. 다중 장애 지점 시나리오에서 해결 시간을 단축할 수 있고 구성 요소가 더 이상 필요하지 않은 시기를 결정할 때 신뢰성을 높일 수 있습니다. 외부 공유 리소스 분석에 대한 권장 가이드는 [SEC03-BP07 퍼블릭 및 크로스 계정 액세스 분석](sec_permissions_analyze_cross_account.md)을 참조하세요.
**일반적인 안티 패턴:**
+ 예상치 못한 외부 공유를 지속적으로 모니터링하고 자동으로 알리는 프로세스가 부족합니다.
+ 공유해야 할 것과 공유하지 말아야 할 것에 대한 기준이 부족합니다.
+ 필요할 때 명시적으로 공유하는 대신 광범위한 공개 정책을 기본으로 설정합니다.
+ 필요할 때 겹치는 기본 리소스를 수동으로 생성합니다.
**이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 중간
## 구현 지침
액세스 제어 및 패턴을 설계하여 공유 리소스의 소비를 신뢰할 수 있는 엔터티로만 안전하게 관리합니다. 공유 리소스를 모니터링하고 공유 리소스 액세스를 지속적으로 검토하고 부적절하거나 예상치 못한 공유에 대한 알림을 받습니다. [퍼블릭 및 크로스 계정 액세스 분석](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_analyze_cross_account.html)을 검토하면 필요한 리소스에 대한 외부 액세스 권한을 줄이도록 거버넌스를 설정하고, 지속적으로 모니터링하고 자동으로 알리는 프로세스를 설정하는 데 도움이 됩니다.
AWS Organizations 내 크로스 계정 공유는 [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)과 같은 [여러 AWS 서비스](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_integrate_services_list.html)에서 지원됩니다. 이러한 서비스를 통해 데이터를 중앙 계정과 공유하거나, 중앙 계정에서 액세스하거나, 중앙 계정에서 리소스 및 데이터를 관리할 수 있습니다. 예를 들어 AWS Security Hub CSPM는 조사 결과를 개별 계정에서 모든 조사 결과를 볼 수 있는 중앙 계정으로 전송할 수 있습니다. AWS Backup은 리소스를 백업하고 계정 간에 공유할 수 있습니다. [AWS Resource Access Manager](https://aws.amazon.com/ram/)(AWS 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 AI 파이프라인](https://docs.aws.amazon.com/ram/latest/userguide/shareable.html#shareable-sagemaker))를 공유할 수 있습니다.
조직 내에서만 리소스를 공유하도록 계정을 제한하려면 [서비스 제어 정책(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 버킷에 액세스하는 자격 증명이 조직에 속하는지 확인할 수 있습니다. [SCP는 서비스 연결 역할 또는 AWS 서비스 보안 주체에 적용되지 않는다는 점](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html#scp-effects-on-permissions)에 유의해야 합니다.
Amazon S3를 사용할 때 [Amazon S3 버킷에 대한 ACL을 끄고](https://docs.aws.amazon.com/AmazonS3/latest/userguide/about-object-ownership.html) IAM 정책을 사용하여 액세스 제어를 정의합니다. [Amazon CloudFront](https://aws.amazon.com/cloudfront/)에서 [Amazon S3 오리진에 대한 액세스 권한을 제한](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-restricting-access-to-s3.html)하려면 오리진 액세스 ID(OAI)에서 [AWS Key Management Service](https://aws.amazon.com/kms/)를 통한 서버 측 암호화를 비롯한 추가 기능을 지원하는 오리진 액세스 제어(OAC)로 마이그레이션합니다.
경우에 따라 조직 외부에서 리소스 공유를 허용하거나 리소스에 대한 서드파티 액세스 권한을 부여할 수 있습니다. 외부에서 리소스를 공유하기 위한 권한 관리에 대한 권장 가이드는 [권한 관리](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/permissions-management.html)를 참조하세요.
### 구현 단계
1. **AWS Organizations 사용:** AWS Organizations은 사용자가 생성하고 중앙에서 관리하는 단일 조직으로 여러 AWS 계정을 통합하기 위해 사용할 수 있는 계정 관리 서비스입니다. 계정을 조직 단위(OU)로 그룹화하고 각 OU에 서로 다른 정책을 연결하여 예산, 보안 및 규정 준수 요구 사항을 충족할 수 있습니다. 또한 AWS 인공 지능(AI) 및 기계 학습(ML) 서비스가 데이터를 수집 및 저장하는 방법을 제어하고 조직과 통합된 AWS 서비스의 다중 계정 관리를 사용할 수 있습니다.
1. **AWS Organizations을 AWS 서비스와 통합:** AWS 서비스가 조직의 구성원 계정 내에서 사용자를 대신하여 작업을 수행하는 경우 AWS Organizations은 각 구성원 계정에서 해당 서비스에 대해 IAM 서비스 연결 역할(SLR)을 생성합니다. AWS Management Console, AWS API 또는 AWS CLI를 사용하여 신뢰할 수 있는 액세스를 관리해야 합니다. 신뢰할 수 있는 액세스 활성화에 대한 권장 가이드는 [Using AWS Organizations with other AWS services](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_integrate_services.html) 및 [AWS services that you can use with Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_integrate_services_list.html)를 참조하세요.
1. **데이터 경계 설정:** 데이터 경계는 신뢰와 소유권의 명확한 경계를 제공합니다. AWS에서는 일반적으로 AWS 리소스에 액세스하는 온프레미스 네트워크 또는 시스템과 함께 AWS Organizations에서 관리하는 AWS 조직으로 표시됩니다. 데이터 경계의 목표는 자격 증명을 신뢰할 수 있고 리소스를 신뢰할 수 있으며 네트워크가 예상되는 경우 액세스가 허용되는지 확인하는 것입니다. 그러나 데이터 경계를 설정하는 것이 모든 상황에 적합한 접근 방식은 아닙니다. 특정 보안 위험 모델 및 요구 사항에 따라 [Building a Perimeter on AWS 백서](https://docs.aws.amazon.com/whitepapers/latest/building-a-data-perimeter-on-aws/welcome.html)에 설명된 제어 목표를 평가하고 채택합니다. 고유한 위험 태세를 신중하게 고려하고 보안 요구 사항에 맞는 경계 제어를 구현해야 합니다.
1. **AWS 서비스에서 리소스 공유 사용 및 적절히 제한:** [Amazon Machine Image(AMI)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html) 및 [AWS Resource Access Manager(AWS RAM)](https://docs.aws.amazon.com/ram/latest/userguide/getting-started-sharing.html)와 같이 많은 AWS 서비스에서는 다른 계정과 리소스를 공유하거나 다른 계정에서 리소스를 대상으로 지정할 수 있습니다. AMI를 공유하기 위해 신뢰할 수 있는 계정을 지정하도록 `ModifyImageAttribute` API를 제한합니다. 신뢰할 수 없는 자격 증명의 액세스를 방지하도록 AWS RAM을 사용할 때 `ram:RequestedAllowsExternalPrincipals` 조건을 지정하여 사용자 조직으로만 공유를 제한합니다. 권장 가이드 및 고려 사항은 [Resource sharing and external targets](https://docs.aws.amazon.com/whitepapers/latest/building-a-data-perimeter-on-aws/perimeter-implementation.html)를 참조하세요.
1. **AWS RAM을 사용하여 한 계정 내에서 또는 다른 AWS 계정과 안전하게 공유:** [AWS RAM](https://aws.amazon.com/ram/)은 사용자가 생성한 리소스를 사용자 계정 및 다른 AWS 계정의 역할 및 사용자와 안전하게 공유하는 데 도움이 됩니다. 다중 계정 환경에서 AWS RAM을 사용하면 리소스를 한 번 생성하여 다른 계정과 공유할 수 있습니다. 이 접근 방식은 Amazon CloudWatch 및 AWS CloudTrail과의 통합을 통해 일관성, 가시성 및 감사 가능성을 제공하는 동시에 운영 오버헤드를 줄이는 데 도움이 됩니다. 이러한 이점은 크로스 계정 액세스를 사용할 경우 얻을 수 없습니다.
이전에 리소스 기반 정책을 사용하여 공유한 리소스가 있는 경우 [`PromoteResourceShareCreatedFromPolicy` API](https://docs.aws.amazon.com/ram/latest/APIReference/API_PromoteResourceShareCreatedFromPolicy.html) 또는 이에 상응하는 기능을 사용하여 리소스 공유를 전체 AWS RAM 리소스 공유로 승격할 수 있습니다.
경우에 따라 리소스를 공유하기 위해 추가 단계를 수행해야 할 수도 있습니다. 예를 들어 암호화된 스냅샷을 공유하려면 [AWS KMS 키를 공유](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-modifying-snapshot-permissions.html#share-kms-key)해야 합니다.
## 리소스
**관련 모범 사례:**
+ [SEC03-BP07 퍼블릭 및 크로스 계정 액세스 분석](sec_permissions_analyze_cross_account.md)
+ [SEC03-BP09 안전하게 서드파티와 리소스 공유](sec_permissions_share_securely_third_party.md)
+ [SEC05-BP01 네트워크 계층 생성](sec_network_protection_create_layers.md)
**관련 문서:**
+ [버킷 소유자가 자신의 소유가 아닌 객체에 크로스 계정 권한 부여](https://docs.aws.amazon.com/AmazonS3/latest/userguide/example-walkthroughs-managing-access-example4.html)
+ [How to use Trust Policies with IAM](https://aws.amazon.com/blogs/security/how-to-use-trust-policies-with-iam-roles/)
+ [Building Data Perimeter on 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 services you can use with AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_integrate_services_list.html)
+ [ Establishing a data perimeter on AWS: Allow only trusted identities to access company data ](https://aws.amazon.com/blogs/security/establishing-a-data-perimeter-on-aws-allow-only-trusted-identities-to-access-company-data/)
**관련 비디오:**
+ [Granular Access with AWS Resource Access Manager](https://www.youtube.com/watch?v=X3HskbPqR2s)
+ [Securing your data perimeter with VPC endpoints](https://www.youtube.com/watch?v=iu0-o6hiPpI)
+ [ Establishing a data perimeter on AWS](https://www.youtube.com/watch?v=SMi5OBjp1fI)
**관련 도구:**
+ [ Data Perimeter Policy Examples ](https://github.com/aws-samples/data-perimeter-policy-examples)
# SEC03-BP09 안전하게 서드파티와 리소스 공유
클라우드 환경의 보안은 조직에 국한되지 않습니다. 조직은 서드파티를 이용하여 데이터의 일부를 관리할 수 있습니다. 서드파티 관리형 시스템에 대한 권한 관리는 임시 자격 증명으로 최소 권한 원칙을 사용하여 적시 액세스 방식을 따라야 합니다. 서드파티와 긴밀히 협력하면 영향 범위와 의도치 않은 액세스의 위험을 함께 줄일 수 있습니다.
**원하는 성과:** 액세스 키 및 보안 키와 같은 장기 AWS Identity and Access Management(IAM) 자격 증명은 오용될 경우 보안 위험이 있으므로 사용하지 않습니다. 대신, IAM 역할과 임시 자격 증명을 사용하여 보안 태세를 개선하고 장기 자격 증명 관리의 운영 오버헤드를 최소화합니다. 서드파티 액세스 권한을 부여할 때 IAM 신뢰 정책의 외부 ID로 Universally Unique Identifier(UUID)를 사용하고 최소 권한 액세스를 보장하기 위해 IAM 정책을 제어하에 역할에 연결해 둡니다. 외부에서 공유되는 리소스에 대한 권장 가이드는 [SEC03-BP07 퍼블릭 및 크로스 계정 액세스 분석](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_analyze_cross_account.html)을 참조하세요.
**일반적인 안티 패턴:**
+ 조건 없이 기본 IAM 신뢰 정책을 사용합니다.
+ 장기 IAM 자격 증명 및 액세스 키를 사용합니다.
+ 외부 ID를 재사용합니다.
**이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 중간
## 구현 지침
AWS Organizations 외부에서 리소스 공유를 허용하거나 서드파티에 계정에 대한 액세스 권한을 부여할 수 있습니다. 예를 들어, 서드파티가 계정 내 리소스에 액세스해야 하는 모니터링 솔루션을 제공할 수 있습니다. 이 경우, 서드파티에만 필요한 권한이 포함된 IAM 크로스 계정 역할을 생성합니다. 또한 [외부 ID 조건](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user_externalid.html)을 사용하여 신뢰 정책을 정의합니다. 외부 ID를 사용하는 경우 사용자 또는 서드파티는 각 고객, 서드파티 또는 테넌시용으로 고유한 ID를 생성할 수 있습니다. 고유한 ID는 생성된 후에는 사용자 외에는 누구도 제어해서는 안 됩니다. 서드파티는 안전하고 감사 가능하며 재현 가능한 방식으로 외부 ID를 고객과 연결하는 프로세스를 구현해야 합니다.
또한 [IAM Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html)를 사용하여 AWS API를 사용하는 AWS 외부 애플리케이션에 대한 IAM 역할을 관리할 수 있습니다.
서드파티가 더 이상 환경에 액세스할 필요가 없으면 역할을 제거합니다. 장기 자격 증명을 서드파티에 제공하지 않아야 합니다. 다른 AWS 계정과 [워크로드를 공유](https://docs.aws.amazon.com/wellarchitected/latest/userguide/workloads-sharing.html)할 수 있도록 허용하는 AWS Well-Architected Tool 및 소유한 AWS 리소스를 다른 계정과 안전하게 공유할 수 있도록 지원하는 [AWS Resource Access Manager](https://docs.aws.amazon.com/ram/latest/userguide/what-is.html) 등 공유를 지원하는 다른 AWS 서비스를 지속적으로 파악하세요.
### 구현 단계
1. **크로스 계정 역할을 사용하여 외부 계정에 대한 액세스 권한을 제공합니다.** [크로스 계정 역할](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html)을 사용하면 고객을 지원하기 위해 서드파티 및 외부 계정에서 저장하는 민감한 정보의 양을 줄일 수 있습니다. 교차 계정 역할을 사용하면 AWS 파트너 또는 조직의 다른 계정과 같은 서드파티에 계정의 AWS 리소스에 대한 액세스 권한을 안전하게 부여하는 동시에 해당 액세스를 관리 및 감사하는 기능을 유지할 수 있습니다. 서드파티는 하이브리드 인프라에서 서비스를 제공하거나 오프사이트 위치로 데이터를 가져올 수 있습니다. [IAM Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html)를 사용하면 서드파티 워크로드에서 AWS 워크로드와 안전하게 상호 작용하고 추가적으로 장기 자격 증명의 필요성을 줄일 수 있습니다.
외부 계정 액세스를 제공하기 위해 장기 자격 증명 또는 사용자와 연결된 액세스 키를 사용해서는 안 됩니다. 대신 크로스 계정 역할을 사용하여 크로스 계정 액세스를 제공합니다.
1. **실사를 수행하고 서드파티 SaaS 공급자에 대한 보안 액세스를 보장합니다.** 서드파티 SaaS 공급자와 리소스를 공유할 때 철저한 실사를 수행하여 서드파티가 AWS 리소스에 액세스할 수 있는 안전하고 책임 있는 접근 방식을 갖추도록 하세요. 서드파티의 공동 책임 모델을 평가하여 서드파티가 제공하는 보안 조치와 나의 책임에 해당하는 조치를 파악합니다. SaaS 공급자가 [외부 ID](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user_externalid.html) 및 최소 권한 액세스 원칙 사용을 포함하여 리소스에 액세스하기 위한 안전하고 감사 가능한 프로세스를 갖추고 있는지 확인합니다. 외부 ID를 사용하면 [혼동된 대리자 문제](https://aws.amazon.com/blogs/security/how-to-use-external-id-when-granting-access-to-your-aws-resources/)를 해결하는 데 도움이 됩니다.
보안 제어를 구현하여 서드파티 SaaS 공급자에 액세스 권한을 부여할 때 보안 액세스 및 최소 권한 원칙을 준수하도록 합니다. 여기에는 외부 ID, Universally Unique Identifiers(UUID) 및 엄격하게 필요한 것으로만 액세스를 제한하는 IAM 신뢰 정책의 사용이 포함될 수 있습니다. SaaS 공급자와 긴밀히 협력하여 안전한 액세스 메커니즘을 설정하고 AWS 리소스에 대한 SaaS 공급자의 액세스를 정기적으로 검토하며 감사를 수행하여 보안 요구 사항을 준수하는지 확인합니다.
1. **고객이 제공한 장기 자격 증명을 사용 중단합니다.** 장기 자격 증명 사용을 중단하고 크로스 계정 역할 또는 IAM Roles Anywhere를 사용합니다. 장기 자격 증명을 사용해야 하는 경우 역할 기반 액세스로의 마이그레이션 계획을 수립합니다. 키 관리에 대한 자세한 내용은 [Identity management](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/identity-management.html)를 참조하세요. 또한 AWS 계정 팀 및 서드파티와 협력하여 위험 완화 런북을 수립합니다. 보안 인시던트의 잠재적 영향에 대한 대응 및 완화에 대한 권장 가이드는 [Incident response](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/incident-response.html)를 참조하세요.
1. **설정에 권장 가이드가 있는지 또는 자동화되어 있는지 확인합니다.** 외부 ID는 보안 암호로 취급되지는 않지만 전화번호, 이름, 계정 ID와 같이 쉽게 추측할 수 있는 값이 아니어야 합니다. 설정을 가장할 목적으로 외부 ID를 변경할 수 없도록 외부 ID를 읽기 전용 필드로 만듭니다.
사용자 또는 서드파티가 외부 ID를 생성할 수 있습니다. ID 생성 담당자를 결정하는 프로세스를 정의합니다. 외부 ID를 생성하는 엔터티에 관계없이 서드파티는 고객 간에 고유성과 형식을 일관되게 적용합니다.
사용자 계정의 크로스 계정 액세스를 위해 생성된 정책은 [최소 권한 원칙](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege)을 따라야 합니다. 서드파티는 역할 정책 문서를 제공하거나 AWS CloudFormation 템플릿 또는 이에 상응하는 템플릿을 사용하는 자동화된 설정 메커니즘을 제공해야 합니다. 이는 수동 정책 생성과 관련된 오류가 발생할 가능성을 줄이고 감사 가능한 트레일을 제공합니다. AWS CloudFormation 템플릿을 사용하여 교차 계정 역할을 생성하는 방법에 대한 자세한 내용은 [Cross-Account Roles](https://aws.amazon.com/blogs/apn/tag/cross-account-roles/)을 참조하세요.
서드파티는 자동화되고 감사 가능한 설정 메커니즘을 제공해야 합니다. 그러나 필요한 액세스를 설명하는 역할 정책 문서를 사용하여 역할 설정을 자동화해야 합니다. AWS CloudFormation 템플릿 또는 이에 상응하는 템플릿을 사용하여 감사 방식의 일환으로 드리프트 감지를 사용하여 변경 사항을 모니터링해야 합니다.
1. **변경 사항을 고려합니다.** 계정 구조, 서드파티에 대한 요구 사항 또는 제공되는 서비스 오퍼링이 변경될 수 있습니다. 변경 사항과 장애를 예상하고 적절한 인력, 프로세스 및 기술을 사용하여 그에 따라 계획을 수립해야 합니다. 사용자가 제공하는 액세스 수준을 정기적으로 감사하고 감지 방법을 구현하여 예상치 못한 변경 사항을 알립니다. 외부 ID의 역할 및 데이터 스토어의 사용을 모니터링하고 감사합니다. 예상치 못한 변경 사항 또는 액세스 패턴의 결과로 일시적으로 또는 영구적으로 서드파티 액세스를 취소할 준비가 되어 있어야 합니다. 또한 수행하는 데 걸리는 시간, 관련된 담당자, 비용, 다른 리소스에 미치는 영향을 포함하여 취소 작업에 미치는 영향을 측정합니다.
탐지 방법에 대한 권장 가이드는 [탐지 모범 사례](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/detection.html)를 참조하세요.
## 리소스
**관련 모범 사례:**
+ [SEC02-BP02 임시 자격 증명 사용](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_unique.html)
+ [SEC03-BP05 조직에 대한 권한 가드레일 정의](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_define_guardrails.html)
+ [SEC03-BP06 수명 주기에 따라 액세스 관리](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_lifecycle.html)
+ [SEC03-BP07 퍼블릭 및 크로스 계정 액세스 분석](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_analyze_cross_account.html)
+ [SEC04 Detection](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/detection.html)
**관련 문서:**
+ [버킷 소유자가 자신의 소유가 아닌 객체에 크로스 계정 권한 부여](https://docs.aws.amazon.com/AmazonS3/latest/userguide/example-walkthroughs-managing-access-example4.html)
+ [How to use trust policies with IAM roles](https://aws.amazon.com/blogs/security/how-to-use-trust-policies-with-iam-roles/)
+ [Delegate access across AWS 계정 using IAM roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html)
+ [IAM을 사용하여 다른 AWS 계정의 리소스에 액세스하려면 어떻게 해야 합니까?](https://aws.amazon.com/premiumsupport/knowledge-center/cross-account-access-iam/)
+ [IAM의 보안 모범 사례](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)
+ [Cross-account policy evaluation logic](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic-cross-account.html)
+ [How to use an external ID when granting access to your AWS resources to a third party](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user_externalid.html)
+ [Collecting Information from AWS CloudFormation Resources Created in External Accounts with Custom Resources](https://aws.amazon.com/blogs/apn/collecting-information-from-aws-cloudformation-resources-created-in-external-accounts-with-custom-resources/)
+ [Securely Using External ID for Accessing AWS Accounts Owned by Others](https://aws.amazon.com/blogs/apn/securely-using-external-id-for-accessing-aws-accounts-owned-by-others/)
+ [Extend IAM roles to workloads outside of IAM with IAM Roles Anywhere](https://aws.amazon.com/blogs/security/extend-aws-iam-roles-to-workloads-outside-of-aws-with-iam-roles-anywhere/)
**관련 비디오:**
+ [How do I allow users or roles in a separate AWS 계정 access to my AWS 계정?](https://www.youtube.com/watch?v=20tr9gUY4i0)
+ [AWS re:Invent 2018: Become an IAM Policy Master in 60 Minutes or Less](https://www.youtube.com/watch?v=YQsK4MtsELU)
+ [AWS Knowledge Center Live: IAM Best Practices and Design Decisions](https://www.youtube.com/watch?v=xzDFPIQy4Ks)
**관련 예제:**
+ [Amazon DynamoDB에 대한 크로스 계정 액세스 구성](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/configure-cross-account-access-to-amazon-dynamodb.html)
+ [AWS STS Network Query Tool](https://github.com/aws-samples/aws-sts-network-query-tool)