# SEC 3 사람과 시스템에 대한 권한은 어떻게 관리합니까?
AWS 및 워크로드에 액세스해야 하는 사람 및 시스템 자격 증명에 대한 액세스를 제어하는 권한을 관리합니다. 권한은 누가 어떤 조건에서 무엇에 액세스할 수 있는지를 제어합니다.
**Topics**
+ [SEC03-BP01 액세스 요구 사항 정의](sec_permissions_define.md)
+ [SEC03-BP02 최소 권한 액세스 부여](sec_permissions_least_privileges.md)
+ [SEC03-BP03 긴급 액세스 프로세스 설정](sec_permissions_emergency_process.md)
+ [SEC03-BP04 지속적으로 권한 축소](sec_permissions_continuous_reduction.md)
+ [SEC03-BP05 조직에 대한 권한 가드레일 정의](sec_permissions_define_guardrails.md)
+ [SEC03-BP06 수명 주기에 따라 액세스 관리](sec_permissions_lifecycle.md)
+ [SEC03-BP07 퍼블릭 및 크로스 계정 액세스 분석](sec_permissions_analyze_cross_account.md)
+ [SEC03-BP08 안전하게 리소스 공유](sec_permissions_share_securely.md)
# SEC03-BP01 액세스 요구 사항 정의
관리자, 최종 사용자 또는 기타 구성 요소는 워크로드의 각 구성 요소 또는 리소스에 액세스해야 합니다. 누가 혹은 무엇이 각 구성 요소에 액세스할 수 있는지 명확하게 정의한 다음 적절한 자격 증명 유형과 인증 및 권한 부여 방법을 선택해야 합니다.
**일반적인 안티 패턴:**
+ 애플리케이션에 보안 암호를 하드 코딩 또는 저장합니다.
+ 각 사용자에 대한 사용자 지정 권한을 부여합니다.
+ 수명이 긴 보안 인증을 사용합니다.
**이 모범 사례가 확립되지 않을 경우 노출되는 위험의 수준:** 높음
## 구현 가이드
관리자, 최종 사용자 또는 기타 구성 요소는 워크로드의 각 구성 요소 또는 리소스에 액세스해야 합니다. 누가 혹은 무엇이 각 구성 요소에 액세스할 수 있는지 명확하게 정의한 다음 적절한 자격 증명 유형과 인증 및 권한 부여 방법을 선택해야 합니다.
조직 내 AWS 계정에 대한 정기적인 액세스를 제공하려면 [페더레이션 액세스](https://aws.amazon.com/identity/federation/) 또는 중앙 집중식 자격 증명 공급자를 사용해야 합니다. 또한 자격 증명 관리를 중앙 집중화하고, 직원 액세스 수명 주기에 대한 AWS 액세스를 통합하기 위해 정립된 사례가 있는지 확인해야 합니다. 예를 들어, 직원이 다른 액세스 수준의 직무로 변경할 경우 해당 그룹 멤버십 또한 변경하여 새로운 액세스 요구 사항을 반영해야 합니다.
비 인적 자격 증명에 대한 액세스 요구 사항을 정의할 경우 어떤 애플리케이션 및 구성 요소가 액세스해야 하는지, 그리고 어떻게 권한이 부여되는지 결정합니다. 권장되는 접근 방식은 최소 권한 액세스 모델을 통해 구축된 IAM 역할을 사용하는 것입니다. [AWS 관리형 정책은](https://docs.aws.amazon.com/singlesignon/latest/userguide/security-iam-awsmanpol.html) 대부분의 일반적인 사용 사례를 다루는 사전 정의된 IAM 정책을 제공합니다.
AWS 서비스, 즉 [AWS Secrets Manager](https://aws.amazon.com/blogs/security/identify-arrange-manage-secrets-easily-using-enhanced-search-in-aws-secrets-manager/) 및 [AWS Systems Manager Parameter Store는](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-parameter-store.html)IAM 역할 사용이 실현 불가능한 경우 애플리케이션 또는 워크로드로부터 보안 암호를 안전하게 분리할 수 있도록 지원합니다. Secrets Manager에서 보안 인증에 대한 자동 교체를 설정할 수 있습니다. Systems Manager를 사용하여 스크립트, 명령, SSM 문서, 구성 및 자동화 워크플로의 파라미터를 참조할 수 있으며 이 경우 파라미터를 생성할 때 지정한 고유한 이름을 사용합니다.
AWS Identity and Access Management Roles Anywhere를 사용하여 [IAM 외부에서 실행되는 워크로드에 대한](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) AWS의 임시 보안 자격 증명을 얻을 수 있습니다. 워크로드에서 사용하는 [IAM 정책](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) 및 [IAM 역할은](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) AWS 애플리케이션에서 AWS 리소스에 액세스하는 데 사용하는 것과 동일한 것일 수 있습니다.
가능한 경우, 장기적이고 정적인 보안 인증보다는 단기적이고 임시적인 보안 인증을 사용하는 것이 좋습니다. 프로그래밍 방식 액세스 및 장기 보안 인증을 사용하는 IAM 사용자가 필요한 경우 [마지막으로 사용된 액세스 키 정보를](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_RotateAccessKey) 사용하여 액세스 키를 교체 및 제거합니다.
## 리소스
**관련 문서:**
+ [속성 기반 액세스 제어(ABAC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)
+ [AWS IAM Identity Center](https://aws.amazon.com/iam/identity-center/)
+ [IAM Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html)
+ [IAM Identity Center의 AWS 관리형 정책](https://docs.aws.amazon.com/singlesignon/latest/userguide/security-iam-awsmanpol.html)
+ [AWS IAM 정책 조건](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html)
+ [IAM 사용 사례](https://docs.aws.amazon.com/IAM/latest/UserGuide/IAM_UseCases.html)
+ [불필요한 보안 인증 제거](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#remove-credentials)
+ [정책 사용](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage.html)
+ [AWS 계정, OU 또는 조직을 기준으로 AWS 리소스에 대한 액세스를 제어하는 방법](https://aws.amazon.com/blogs/security/how-to-control-access-to-aws-resources-based-on-aws-account-ou-or-organization/)
+ [AWS Secrets Manager의 향상된 검색을 사용하여 보안 암호를 쉽게 식별, 정렬 및 관리](https://aws.amazon.com/blogs/security/identify-arrange-manage-secrets-easily-using-enhanced-search-in-aws-secrets-manager/)
**관련 동영상:**
+ [60분 이내에 IAM 정책 마스터하기](https://youtu.be/YQsK4MtsELU)
+ [업무 분리, 최소 권한, 위임 및 CI/CD](https://youtu.be/3H0i7VyTu70)
+ [혁신을 위한 자격 증명 및 액세스 관리 간소화](https://www.youtube.com/watch?v=3qK0b1UkaE8)
# SEC03-BP02 최소 권한 액세스 부여
특정 조건에서 특정 AWS 리소스에 대한 특정 작업과 관련한 액세스를 허용하여 자격 증명에 필요한 액세스 권한만 부여합니다. 개별 사용자에 대한 권한을 정의하는 대신, 그룹 및 자격 증명 속성을 사용하여 대규모로 권한을 동적으로 설정합니다. 예를 들어 개발자 그룹이 자체 프로젝트에 대한 리소스만 관리하도록 액세스 권한을 허용할 수 있습니다. 이렇게 하면 특정 개발자를 그룹에서 제거했을 때 액세스 정책을 변경할 필요 없이 해당 그룹을 액세스 제어에 사용한 모든 리소스에서 이 개발자에 대한 액세스가 취소됩니다.
**일반적인 안티 패턴:**
+ 사용자에게 기본적으로 관리자 권한을 부여합니다.
+ 일상적인 활동에 루트 계정을 사용합니다.
**이 모범 사례가 확립되지 않을 경우 노출되는 위험의 수준:** 높음
## 구현 가이드
원칙으로 [최소 권한](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege) 을 확립하면 사용 가능성과 효율성을 적절하게 절충하면서 자격 증명이 특정 작업을 처리하는 데 필요한 최소한의 기능 세트만 수행하도록 할 수 있습니다. 이 원칙에 따라 운영하면 의도치 않은 액세스를 제한하고, 누가 어떤 리소스에 액세스할 수 있는지 감사할 수 있습니다. AWS에서는 루트 사용자를 제외하고는 기본적으로 자격 증명에 권한이 없습니다. 루트 사용자의 보안 인증은 엄격하게 제어되어야 하며 [특정 작업](https://docs.aws.amazon.com/general/latest/gr/aws_tasks-that-require-root.html)에만 사용해야 합니다.
IAM 또는 리소스 엔터티(예: 페더레이션형 ID, 시스템 또는 리소스(예: S3 버킷)에서 사용하는 IAM 역할)에 연결된 권한을 명시적으로 부여하는 경우 정책을 사용합니다. 정책을 생성하여 연결할 때 서비스 작업, 리소스는 물론 AWS가 액세스를 허용하려면 참이어야 하는 조건을 지정할 수 있습니다. AWS는 다양한 조건을 지원하여 액세스 범위를 축소할 수 있도록 도와줍니다. 예를 들어, `PrincipalOrgID` [조건 키](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html)를 사용하면 AWS Organizations의 식별자를 확인하므로 AWS Organization 내에서만 액세스를 허용할 수 있습니다.
또한 AWS CloudFormation에서 AWS Lambda 함수를 생성하는 등 AWS 서비스가 사용자를 대신하여 수행하는 요청을 `CalledVia` 조건 키를 사용하여 제어할 수도 있습니다. 계정 내 전체 권한을 효과적으로 제한하기 위해 다른 정책 유형 간 계층을 지정해야 합니다. 예를 들어, 애플리케이션 팀에서 자체적으로 IAM 정책을 생성하도록 허용할 수 있지만 [권한 경계](https://aws.amazon.com/blogs/security/delegate-permission-management-to-developers-using-iam-permissions-boundaries/) 를 사용하여 이들이 허용할 수 있는 최대 권한을 제한해야 합니다.
권한 관리를 확장하고 최소 권한의 원칙을 준수하는 데 도움이 되는 다양한 AWS 기능이 있습니다. [속성 기반 액세스 제어](https://aws.amazon.com/blogs/security/delegate-permission-management-to-developers-using-iam-permissions-boundaries/) 를 통해 리소스의 *[태그](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/tagging-best-practices.html)* 를 기준으로 권한을 제한할 수 있으며, 이를 통해 리소스 및 호출하는 IAM 보안 주체에 적용된 태그를 기준으로 권한 부여 결정을 내릴 수 있습니다. 이렇게 하면 태그 지정과 권한 정책을 결합하여 여러 사용자 지정 정책 없이도 세분화된 리소스 액세스를 달성할 수 있습니다.
최소 권한 정책 생성을 가속화하는 또 다른 방법은 활동 실행 후 CloudTrail 권한을 기반으로 정책을 수립하는 것입니다. [IAM Access Analyzer는 활동을 기반으로 IAM 정책을 자동으로 생성할 수 있습니다](https://aws.amazon.com/blogs/security/delegate-permission-management-to-developers-using-iam-permissions-boundaries/). 또한 조직 또는 개별 계정 수준에서 IAM Access Advisor를 사용하여 [특정 정책에 대해 마지막 액세스 정보를 추적](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor.html)할 수 있습니다.
이러한 세부 정보를 검토하고 불필요한 권한을 제거할 주기를 설정할 수 있습니다. AWS 조직 내 권한 가드레일을 설정하여 모든 멤버 계정 내에서 최대 권한을 제어해야 합니다. 서비스, 즉 [AWS Control Tower는 권장 관리형 예방 제어 기능](https://docs.aws.amazon.com/controltower/latest/userguide/guardrails.html) 이 있어 자체적인 제어를 정의할 수 있습니다.
## 리소스
**관련 문서:**
+ [IAM 엔터티의 권한 경계](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html)
+ [최소 권한 IAM 정책 작성 기법](https://aws.amazon.com/blogs/security/techniques-for-writing-least-privilege-iam-policies/)
+ [IAM Access Analyzer를 통해 액세스 활동에 기반한 IAM 정책을 생성하여 보다 쉽게 최소 권한을 구현](https://aws.amazon.com/blogs/security/iam-access-analyzer-makes-it-easier-to-implement-least-privilege-permissions-by-generating-iam-policies-based-on-access-activity/)
+ [마지막 액세스 정보를 사용하여 권한 수정](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor.html)
+ [IAM 정책 유형과 사용 시기](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html)
+ [IAM 정책 시뮬레이터로 IAM 정책 테스트](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_testing-policies.html)
+ [AWS Control Tower의 가드레일](https://docs.aws.amazon.com/controltower/latest/userguide/guardrails.html)
+ [제로 트러스트 아키텍처: AWS의 철학](https://aws.amazon.com/blogs/security/zero-trust-architectures-an-aws-perspective/)
+ [CloudFormation StackSets로 최소 권한의 원칙을 구현하는 방법](https://aws.amazon.com/blogs/security/how-to-implement-the-principle-of-least-privilege-with-cloudformation-stacksets/)
**관련 동영상:**
+ [차세대 권한 관리](https://www.youtube.com/watch?v=8vsD_aTtuTo)
+ [제로 트러스트: AWS의 철학](https://www.youtube.com/watch?v=1p5G1-4s1r0)
+ [권한 경계를 사용하여 IAM 사용자 및 역할을 제한하고 권한 승격을 방지하려면 어떻게 해야 하나요?](https://www.youtube.com/watch?v=omwq3r7poek)
**관련 예시:**
+ [실습: 역할 생성을 위임하는 IAM 권한 경계](https://wellarchitectedlabs.com/Security/300_IAM_Permission_Boundaries_Delegating_Role_Creation/README.html)
# SEC03-BP03 긴급 액세스 프로세스 설정
가능성은 낮지만 자동화된 프로세스 또는 파이프라인에 문제가 발생할 때 워크로드에 긴급 액세스할 수 있도록 하는 프로세스입니다. 이 긴급 액세스 프로세스를 통해 최소 권한 액세스를 사용할 수 있습니다. 그러나 사용자가 적절한 수준의 액세스 권한이 필요할 때는 해당 권한을 얻을 수 있습니다. 예를 들어, 관리자가 액세스를 위한 긴급 AWS 크로스 계정 역할 등의 요청을 확인하고 승인하는 프로세스 또는 관리자가 긴급 요청을 확인하고 승인하기 위해 따라야 하는 특정 프로세스를 설정합니다.
**일반적인 안티 패턴:**
+ 기존 자격 증명 구성을 사용하여 중단으로부터 복구할 수 있는 긴급 프로세스가 없습니다.
+ 승격된 장기 권한을 문제 해결 또는 복구 목적으로 부여합니다.
**이 모범 사례가 확립되지 않을 경우 노출되는 위험의 수준:** 보통
## 구현 가이드
긴급 액세스 설정은 여러 가지 형태일 수 있으며 이에 대비해야 합니다. 첫 번째는 기본 자격 증명 공급자의 실패입니다. 이 경우 복구에 필요한 권한을 통해 액세스의 두 번째 방법을 사용해야 합니다. 이 방법은 백업 자격 증명 공급자 또는 IAM 사용자일 수 있습니다. 이 두 번째 방법을 사용할 경우 [엄격한 제어, 모니터링 및 알림](https://aws.amazon.com/blogs/mt/monitor-and-notify-on-aws-account-root-user-activity/) 이 필요합니다. 긴급 액세스 자격 증명은 이 목적에 맞는 계정에서 생성되어야 하며 복구를 위해 특별히 설계된 역할을 수행할 수 있는 권한만 가지고 있어야 합니다.
또한 승격된 임시 관리 액세스가 필요할 경우에 대비하여 긴급 액세스를 준비해야 합니다. 일반적인 시나리오는 변경 사항을 배포하는 데 사용하는 자동 프로세스로 권한 변경을 제한하는 것입니다. 이 프로세스에 문제가 발생할 경우 사용자는 기능 복원을 위해 승격된 권한을 요청해야 할 수 있습니다. 이 경우, 사용자가 승격된 액세스를 요청할 수 있고 관리자가 이를 확인 및 승인할 수 있는 프로세스를 설정합니다. 구현 계획에는 사전 프로비저닝 액세스 및 긴급 설정, *브레이크 글라스*, 역할이 [SEC10-BP05 액세스 권한 사전 프로비저닝](sec_incident_response_pre_provision_access.md)의 일부로서 제공되며 이에 대한 모범 사례 지침이 자세히 설명되어 있습니다.
## 리소스
**관련 문서:**
+ [AWS 모니터링 및 알림](https://aws.amazon.com/blogs/mt/monitor-and-notify-on-aws-account-root-user-activity)
+ [임시 승격된 액세스 관리](https://aws.amazon.com/blogs/security/managing-temporary-elevated-access-to-your-aws-environment/)
**관련 동영상:**
+ [60분 이내에 IAM 정책 마스터하기](https://youtu.be/YQsK4MtsELU)
# SEC03-BP04 지속적으로 권한 축소
팀 및 워크로드가 필요한 액세스 권한을 결정할 때 더 이상 사용하지 않는 권한을 제거하고 최소 권한을 부여하기 위한 검토 프로세스를 설정합니다. 사용하지 않는 자격 증명 및 권한을 지속적으로 모니터링하고 줄입니다.
팀과 프로젝트를 막 시작하는 경우, 혁신과 민첩성을 이끌어내기 위해 광범위한 액세스 권한(개발 또는 테스트 환경에서)을 부여하고자 하는 경우가 있습니다. 특히 프로덕션 환경에서 액세스를 지속적으로 평가하고, 필요한 권한에 대해서만 제한적으로 액세스를 부여하고, 최소 권한을 구현하는 것을 권장합니다. AWS에서는 사용되지 않는 액세스를 파악할 수 있도록 액세스 분석 기능을 제공합니다. AWS에서 액세스 활동을 분석하여 액세스 키와 역할이 마지막으로 사용된 사례의 정보를 제공하므로 미사용된 사용자와 역할, 권한, 보안 인증 정보를 파악하는 데 도움이 됩니다. 즉 [마지막으로 액세스한 타임스탬프](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor-view-data.html) 을 [를 사용하면 미사용된 사용자와 역할을 파악하여](http://aws.amazon.com/blogs/security/identify-unused-iam-roles-remove-confidently-last-used-timestamp/)제거할 수 있습니다. 또한 서비스와 작업의 마지막 액세스 정보를 검토하면 [특정 사용자와 역할을 대상으로 권한을 강화할 수도 있습니다.](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor.html). 예를 들어 마지막 액세스 정보를 사용하면 애플리케이션 역할에 필요한 특정 Amazon Simple Storage Service(Amazon S3) 작업을 파악하여 그러한 작업에 대해서만 액세스를 제한할 수 있습니다. 이러한 기능은 AWS Management Console에서 프로그램 방식으로 제공되므로 인프라 워크플로 및 자동화된 도구에 손쉽게 통합할 수 있습니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 보통
## 구현 가이드
+ AWS Identity and Access Management(IAM) Access Analyzer 구성: AWS IAM Access Analyzer를 사용하면 Amazon Simple Storage Service(Amazon S3) 버킷 또는 IAM 역할과 같은 조직 및 계정 내 리소스 중 외부 엔터티와 공유되는 리소스를 식별할 수 있습니다.
+ [AWS IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html)
## 리소스
**관련 문서:**
+ [ABAC(속성 기반 액세스 제어)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)
+ [최소 권한 부여](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege)
+ [불필요한 자격 증명 삭제](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#remove-credentials)
+ [정책 사용](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage.html)
**관련 동영상:**
+ [60분 이내에 IAM 정책 마스터하기](https://youtu.be/YQsK4MtsELU)
+ [업무 분리, 최소 권한, 위임 및 CI/CD](https://youtu.be/3H0i7VyTu70)
# SEC03-BP05 조직에 대한 권한 가드레일 정의
조직의 모든 자격 증명에 대한 액세스를 제한하는 공통 제어를 설정합니다. 예를 들어, 특정 AWS 리전에 대한 액세스를 제한하거나 중앙 보안 팀에 사용되는 IAM 역할과 같은 공통 리소스를 운영자가 삭제하지 못하게 할 수 있습니다.
**일반적인 안티 패턴:**
+ 조직의 관리자 계정에서 워크로드를 실행합니다.
+ 프로덕션과 비 프로덕션 워크로드를 동일한 계정에서 실행합니다.
**이 모범 사례가 확립되지 않을 경우 노출되는 위험의 수준:** 보통
## 구현 가이드
AWS에서 추가 워크로드를 확장하고 관리하면서, 계정을 사용하여 이러한 워크로드를 분리하고 AWS Organizations를 사용하여 해당 계정을 관리해야 합니다. 이 경우 조직 내 모든 자격 증명에 대한 액세스를 제한하는 공통 권한 가드레일을 설정하는 것이 좋습니다. 예를 들어, 특정 AWS 리전에 대한 액세스를 제한하거나 중앙 보안팀이 사용하는 IAM 역할과 같은 공통 리소스를 팀에서 삭제하지 못하게 할 수 있습니다.
사용자가 주요 서비스를 비활성화하지 못하도록 방지하는 등 서비스 제어 정책 예시를 구현하는 것부터 시작할 수 있습니다. SCP는 IAM 정책 언어를 사용하여 모든 IAM 보안 주체(사용자 및 역할)가 준수하는 제어를 설정할 수 있습니다. 특정 서비스 작업과 리소스에 대한 액세스를 제한하거나, 조직의 액세스 제어 요구 사항에 부합하도록 특정 조건을 기반으로 액세스를 제한할 수 있습니다. 필요한 경우, 가드레일에 예외를 정의할 수 있습니다. 예를 들어, 주어진 계정에서 특정 관리자 역할을 제외한 모든 IAM 엔터티에 대해 서비스 작업을 제한할 수 있습니다.
관리 계정에서 워크로드를 실행하지 않는 것이 좋습니다. 관리 계정은 멤버 계정에 영향을 미치는 보안 가드레일을 관리 및 배포하는 데 사용해야 합니다. 일부 AWS 서비스는 위임된 관리자 계정의 사용을 지원합니다. 가능한 경우, 이 위임된 계정을 관리 계정 대신 사용해야 합니다. 조직의 관리자 계정에 대한 액세스는 강력하게 제한해야 합니다.
다중 계정 전략을 사용하면 워크로드에 가드레일을 훨씬 더 유연하게 적용할 수 있습니다. AWS Security Reference Architecture는 계정 구조 설계 방법에 대한 권장 가이드를 제공합니다. AWS Control Tower와 같은 AWS 서비스는 조직 전체에 대한 사전 예방 제어와 탐지 제어 모두를 중앙에서 관리할 수 있는 기능을 제공합니다. 조직 내 각 계정 또는 OU에 대한 명확한 목적을 정의하고 해당 목적에 따라 제어를 제한합니다.
## 리소스
**관련 문서:**
+ [AWS Organizations](https://aws.amazon.com/organizations/)
+ [서비스 제어 정책(SCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)
+ [다중 계정 환경에서 서비스 제어 정책 최대한 활용](https://aws.amazon.com/blogs/security/get-more-out-of-service-control-policies-in-a-multi-account-environment/)
+ [AWS Security Reference Architecture(AWS SRA)](https://docs.aws.amazon.com/prescriptive-guidance/latest/security-reference-architecture/welcome.html)
**관련 동영상:**
+ [서비스 제어 정책을 사용한 예방적 가드레일 적용](https://www.youtube.com/watch?v=mEO05mmbSms)
+ [AWS Control Tower를 통해 대규모 거버넌스 구축](https://www.youtube.com/watch?v=Zxrs6YXMidk)
+ [AWS Identity and Access Management 심층 분석](https://www.youtube.com/watch?v=YMj33ToS8cI)
# SEC03-BP06 수명 주기에 따라 액세스 관리
액세스 제어를 운영자 및 애플리케이션 수명 주기/중앙 집중식 페더레이션 공급자와 통합합니다. 예를 들어 조직에서 나가거나 역할이 변경될 때 사용자의 액세스 권한을 제거합니다.
워크로드를 관리할 때 별도의 여러 계정을 사용하다 보면, 해당 계정 간에 리소스를 공유해야 하는 경우가 있습니다. 리소스를 공유할 때는 [AWS Resource Access Manager(AWS RAM)를 사용하는 것이 좋습니다.](http://aws.amazon.com/ram/). 이 서비스를 사용하면 AWS Organizations 및 조직 단위 내에서 AWS 리소스를 쉽고 안전하게 공유할 수 있습니다. AWS RAM을 사용하면 리소스를 공유하는 조직이나 조직 단위에서의 계정 포함 여부에 따라 공유 리소스에 대한 액세스 권한이 자동으로 부여되거나 취소됩니다. 이렇게 하면 리소스를 원하는 계정끼리만 공유하도록 할 수 있습니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 낮음
## 구현 가이드
사용자 액세스 수명 주기 현재 사용자만 액세스할 수 있도록 시설의 신규 참여 사용자, 직무 기능 변경, 퇴거 사용자에 적용할 사용자 액세스 수명 주기 정책을 구현합니다.
## 리소스
**관련 문서:**
+ [ABAC(속성 기반 액세스 제어)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)
+ [최소 권한 부여](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege)
+ [IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html)
+ [불필요한 자격 증명 삭제](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#remove-credentials)
+ [정책 사용](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage.html)
**관련 동영상:**
+ [60분 이내에 IAM 정책 마스터하기](https://youtu.be/YQsK4MtsELU)
+ [업무 분리, 최소 권한, 위임 및 CI/CD](https://youtu.be/3H0i7VyTu70)
# SEC03-BP07 퍼블릭 및 크로스 계정 액세스 분석
퍼블릭 및 크로스 계정 액세스를 강조하는 결과를 지속적으로 모니터링합니다. 이 유형의 액세스가 필요한 리소스에 대해서만 퍼블릭 액세스 및 크로스 계정 액세스를 줄입니다.
**일반적인 안티 패턴:**
+ 크로스 계정에 대한 액세스 및 리소스에 대한 퍼블릭 액세스를 관리하는 프로세스를 따르지 않습니다.
**이 모범 사례가 확립되지 않을 경우 노출되는 위험의 수준:** 낮음
## 구현 가이드
AWS에서는 다른 계정의 리소스에 대한 액세스 권한을 부여할 수 있습니다. 리소스에 연결된 정책(예: [Amazon Simple Storage Service(Amazon S3) 버킷 정책](https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucket-policies.html)을 사용하거나 자격 증명이 다른 계정에서 IAM 역할을 수임하도록 허용하여 다른 계정의 직접 액세스를 허용합니다. 리소스 정책을 사용하는 경우, 조직의 자격 증명에 액세스 권한이 부여되었는지, 그리고 사용자가 리소스를 공개하려는 의도인지 확인해야 합니다. 공개적으로 사용 가능해야 하는 모든 리소스를 승인하는 프로세스를 정의합니다.
[IAM Access Analyzer](https://aws.amazon.com/iam/features/analyze-access/) 는 [증명 가능한 보안](https://aws.amazon.com/security/provable-security/) 을 사용하여 자격 증명에 계정 외부의 리소스에 대한 전체적인 액세스 경로를 제공합니다. 따라서 리소스 정책을 지속적으로 검토하고, 퍼블릭 또는 크로스 계정 액세스 결과를 보고하여 잠재적인 광범위한 액세스를 쉽게 분석할 수 있습니다. AWS Organizations에서 IAM Access Analyzer를 구성하여 모든 계정에 대한 가시성을 확인합니다. 또한 IAM Access Analyzer를 사용하면 리소스 사용 권한을 배포하기 전에 [Access Analyzer 결과를 미리 보기](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-access-preview.html)도 가능합니다. 따라서 정책 변경 사항이 리소스에 대해 의도한 퍼블릭 및 크로스 계정 액세스만 부여하는지 확인할 수 있습니다. 다중 계정 액세스를 설계할 경우 [역할을 수임할 수 있는 경우를 제어하는 신뢰 정책](https://aws.amazon.com/blogs/security/how-to-use-trust-policies-with-iam-roles/)을 사용할 수 있습니다. 예를 들어, 특정 소스 IP 범위로 역할 수임을 제한할 수 있습니다.
또한 실수로 인한 퍼블릭 액세스 구성에 대해 [AWS Config를 사용하여 리소스를 보고 및 개선](https://docs.aws.amazon.com/config/latest/developerguide/operational-best-practices-for-Publicly-Accessible-Resources.html) 할 수 있으며, 이 경우 AWS Config 정책 확인을 사용합니다. 또한 [AWS Control Tower](https://aws.amazon.com/controltower) 및 [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-standards-fsbp.html) 와 같은 서비스는 AWS Organizations 전체에 검사 및 가드레일을 배포하기만 하면 공개적으로 노출된 리소스를 파악 및 개선할 수 있습니다. 예를 들어, AWS Control Tower는 [Amazon EBS 스냅샷이 모든 AWS 계정에 의해 복원 가능한지](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html)탐지할 수 있는 관리형 가드레일을 보유합니다.
## 리소스
**관련 문서:**
+ [AWS Identity and Access Management Access Analyzer 사용](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html?ref=wellarchitected)
+ [AWS Control Tower의 가드레일](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html)
+ [AWS 기초 보안 모범 사례 표준](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-standards-fsbp.html)
+ [AWS Config 관리형 규칙](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config_use-managed-rules.html)
+ [AWS Trusted Advisor 확인 참조](https://docs.aws.amazon.com/awssupport/latest/user/trusted-advisor-check-reference.html)
**관련 동영상:**
+ [다중 계정 환경 보안 모범 사례](https://www.youtube.com/watch?v=ip5sn3z5FNg)
+ [IAM Access Analyzer 심층 분석](https://www.youtube.com/watch?v=i5apYXya2m0)
# SEC03-BP08 안전하게 리소스 공유
계정 전체에 걸쳐 또는 AWS Organizations 내에서 공유된 리소스의 사용을 관리합니다. 공유 리소스를 모니터링하고 공유 리소스 액세스를 검토합니다.
**일반적인 안티 패턴:**
+ 서드파티 크로스 계정 액세스 권한을 부여할 때 기본 IAM 신뢰 정책을 사용합니다.
**이 모범 사례가 확립되지 않을 경우 노출되는 위험의 수준:** 낮음
## 구현 가이드
여러 AWS 계정을 사용하여 워크로드를 관리할 경우 계정 간에 리소스를 공유해야 할 수 있습니다. 이것은 흔히 AWS Organizations 내에서 공유되는 크로스 계정 공유입니다. 여러 AWS 서비스, 즉 [AWS Security Hub CSPM](https://docs.aws.amazon.com/organizations/latest/userguide/services-that-can-integrate-securityhub.html), [Amazon GuardDuty](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_organizations.html) 및 [AWS Backup](https://docs.aws.amazon.com/organizations/latest/userguide/services-that-can-integrate-backup.html) 은 Organizations와 통합되는 크로스 계정 기능이 있습니다. 이때 [AWS Resource Access Manager](https://aws.amazon.com/ram/) 를 사용하여 기타 일반적인 리소스, 즉 [VPC 서브넷 또는 Transit Gateway Attachment](https://docs.aws.amazon.com/ram/latest/userguide/shareable.html#shareable-vpc), [AWS Network Firewall](https://docs.aws.amazon.com/ram/latest/userguide/shareable.html#shareable-network-firewall)또는 [Amazon SageMaker Runtime 파이프라인](https://docs.aws.amazon.com/ram/latest/userguide/shareable.html#shareable-sagemaker)을 공유합니다. 계정이 Organizations 내 리소스만 공유하도록 하려면 [서비스 제어 정책(SCP)](https://docs.aws.amazon.com/ram/latest/userguide/scp.html) 을 사용하여 외부 보안 주체에 대한 액세스를 방지하는 것이 좋습니다.
리소스를 공유할 때는 의도하지 않은 액세스로부터 보호할 수 있는 조치를 마련해야 합니다. 이를 위해 자격 증명 기반 제어와 네트워크 제어를 결합하여 [조직의 데이터 경계를 생성](https://docs.aws.amazon.com/whitepapers/latest/building-a-data-perimeter-on-aws/building-a-data-perimeter-on-aws.html)하는 것을 권장합니다. 이러한 제어를 통해 어떤 리소스를 공유할 수 있는지에 대한 엄격한 제한을 설정하고, 리소스의 허용되지 않은 공유 또는 노출을 예방할 수 있습니다. 예를 들어, 데이터 경계의 일부로 VPC 엔드포인트 정책 및 `aws:PrincipalOrgId` 조건을 사용하여 Amazon S3 버킷에 액세스하는 자격 증명이 조직 내에 속한 것인지 확인할 수 있습니다.
경우에 따라 Organizations 외부 리소스의 공유를 허용하거나 사용자의 계정에 서드파티 액세스 권한을 부여해야 할 수 있습니다. 예를 들어, 파트너가 사용자의 계정 내 리소스에 액세스해야 하는 모니터링 솔루션을 제공할 수 있습니다. 이 경우, 서드파티에만 필요한 권한이 포함된 IAM 크로스 계정 역할을 생성해야 합니다. 또한 [외부 ID 조건](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user_externalid.html)을 사용하여 신뢰 정책을 만들어야 합니다. 외부 ID를 사용할 경우 각 서드파티를 위한 고유 ID를 생성해야 합니다. 고유 ID는 서드파티가 공급하거나 제어할 수 없습니다. 서드파티가 더 이상 환경에 액세스할 필요가 없다면 역할을 제거해야 합니다. 또한 어떠한 경우라도 서드파티에 장기 IAM 보안 인증을 제공하지 않아야 합니다. 기본적으로 공유를 지원하는 다른 AWS 서비스를 계속 인지하고 있어야 합니다. 예를 들어, AWS Well-Architected Tool에서 [워크로드 공유](https://docs.aws.amazon.com/wellarchitected/latest/userguide/workloads-sharing.html) 로 다른 AWS 계정과의 공유를 허용할 수 있습니다.
Amazon S3와 같은 서비스를 사용할 경우 [Amazon S3 버킷에 대한 ACL을 비활성화](https://docs.aws.amazon.com/AmazonS3/latest/userguide/about-object-ownership.html) 하고 IAM 정책을 사용하여 액세스 제어를 정의하는 것이 좋습니다. [Amazon S3 오리진에](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-restricting-access-to-s3.html) 대한 액세스를 [Amazon CloudFront](https://aws.amazon.com/cloudfront/)에서 제한하려면 오리진 액세스 ID(OAI)에서 [AWS KMS](https://aws.amazon.com/kms/)를 통한 서버 측 암호화를 비롯한 추가 기능을 지원하는 오리진 액세스 제어(OAC)로 마이그레이션하세요.
## 리소스
**관련 문서:**
+ [버킷 소유자가 소유하지 않은 객체에 크로스 계정 권한 부여](https://docs.aws.amazon.com/AmazonS3/latest/userguide/example-walkthroughs-managing-access-example4.html)
+ [IAM을 통한 신뢰 정책 사용 방법](https://aws.amazon.com/blogs/security/how-to-use-trust-policies-with-iam-roles/)
+ [AWS에 데이터 경계 구축](https://docs.aws.amazon.com/whitepapers/latest/building-a-data-perimeter-on-aws/building-a-data-perimeter-on-aws.html)
+ [AWS 리소스에 대한 서드파티 액세스 권한을 부여할 때 외부 ID를 사용하는 방법](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user_externalid.html)
**관련 동영상:**
+ [AWS Resource Access Manager를 통한 세분화된 액세스](https://www.youtube.com/watch?v=X3HskbPqR2s)
+ [VPC 엔드포인트를 통한 데이터 경계 보호](https://www.youtube.com/watch?v=iu0-o6hiPpI)
+ [AWS에 데이터 경계 설정 ](https://www.youtube.com/watch?v=SMi5OBjp1fI)