SEC03-BP05 조직의 권한 가드레일 정의 - 보안 요소
구현 지침구현 단계리소스

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

SEC03-BP05 조직의 권한 가드레일 정의

권한 가드레일을 사용하여 보안 주체에 부여할 수 있는 사용 가능한 권한의 범위를 줄이세요. 권한 정책 평가 체인에는 권한 부여 결정을 내릴 때 보안 주체의 유효 권한을 결정하기 위한 가드레일이 포함됩니다.  계층 기반 접근 방식을 사용하여 가드레일을 정의할 수 있습니다. 가드레일 중 일부는 조직 전체에 광범위하게 적용하고 일부는 임시 액세스 세션에 세부적으로 적용하세요.

원하는 성과: 별도의 AWS 계정을 사용하여 환경을 명확하게 격리할 수 있습니다.   서비스 제어 정책(SCPs)은 조직 전체 권한 가드레일을 정의하는 데 사용됩니다. 더 포괄적인 가드레일은 조직 루트에 가장 근접한 계층 수준에서 설정되고, 더 엄격한 가드레일은 개별 계정 수준에 더 가깝게 설정됩니다.  지원되는 경우 리소스 정책은 보안 주체가 리소스에 액세스하기 위해 충족해야 하는 조건을 정의합니다. 또한, 리소스 정책은 적절한 경우 허용 가능한 작업 집합의 범위를 세분화합니다.  권한 경계는 워크로드 권한을 관리하는 보안 주체에 부여되어 권한 관리를 개별 워크로드 소유자에게 위임합니다.

일반적인 안티 패턴:

  • 조직 AWS 계정 내에서 멤버를 생성하지만 SCPs를 사용하여 루트 보안 인증에 사용할 수 있는 사용 및 권한을 제한하지는 않습니다. AWS

  • 최소 권한을 기준으로 권한을 할당하지만, 부여할 수 있는 최대 권한 집합에는 가드레일을 설정하지 않습니다.

  • 권한을 제한 AWS IAM하기 위해 의 암시적 거부 기반에 의존하여 정책이 원치 않는 명시적 허용 권한을 부여하지 않을 것이라고 신뢰합니다.

  • 동일한 에서 여러 워크로드 환경을 실행한 다음 AWS 계정, VPCs태그 또는 리소스 정책과 같은 메커니즘에 의존하여 권한 경계를 적용합니다.

이 모범 사례 확립의 이점: 권한 가드레일은 권한 정책이 허용을 시도하더라도 원하지 않는 권한을 부여할 수 없다는 확신을 심어줍니다.  이를 통해 고려해야 할 권한의 최대 범위를 줄여 권한 정의 및 관리를 단순화할 수 있습니다.

이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준: 중간

구현 가이드

계층 기반 접근 방식을 사용하여 조직의 권한 가드레일을 정의하는 것이 좋습니다. 이 접근 방식은 추가 계층이 적용될 때 가능한 최대 권한 집합을 체계적으로 줄입니다. 이렇게 하면 최소 권한 원칙에 따라 액세스 권한을 부여하여 잘못된 정책 구성으로 인해 의도하지 않은 액세스가 발생할 위험을 줄일 수 있습니다.

권한 가드레일을 구축하는 첫 단계는 워크로드와 환경을 별도의 AWS 계정으로 분리하는 것입니다.  한 계정의 보안 주체는 두 계정이 동일한 AWS 조직 또는 동일한 조직 단위(OU)에 있는 경우에도 명시적 권한 없이 다른 계정의 리소스에 액세스할 수 없습니다.  OUs 를 사용하여 관리하려는 계정을 단일 단위로 그룹화할 수 있습니다.  

다음 단계는 조직 구성원 계정 내에서 보안 주체에 부여할 수 있는 최대 권한 집합을 줄이는 것입니다.  이 용도로 서비스 제어 정책(SCPs)을 사용할 수 있으며, 이는 OU 또는 계정에 적용할 수 있습니다.  SCPs 는 특정 에 대한 액세스 제한, 리소스 삭제 AWS 리전방지 또는 잠재적으로 위험한 서비스 작업 비활성화와 같은 일반적인 액세스 제어를 적용할 수 있습니다.   SCPs 조직의 루트에 적용하는 는 관리 계정이 아닌 멤버 계정에만 영향을 미칩니다.  SCPs 조직 내 보안 주체만 관리합니다. 는 리소스에 액세스하는 조직 외부의 보안 주체를 관리하지 SCPs 않습니다.

또 다른 단계는 IAM 리소스 정책을 사용하여 운영 보안 주체가 충족해야 하는 조건과 함께 해당 보안 주체가 관리하는 리소스에 대해 수행할 수 있는 사용 가능한 작업의 범위를 지정하는 것입니다.  이는 보안 주체가 조직의 일부인 한 모든 작업을 허용하는 것만큼 광범위하거나( PrincipalOrgId조건 키 사용) 특정 IAM 역할별 특정 작업만 허용하는 것만큼 세분화될 수 있습니다.  IAM 역할 신뢰 정책의 조건을 사용하여 유사한 접근 방식을 취할 수 있습니다.  리소스 또는 역할 신뢰 정책이 관리하는 역할 또는 리소스와 동일한 계정의 보안 주체를 명시적으로 지정하는 경우 해당 보안 주체는 동일한 권한을 부여하는 연결된 IAM 정책이 필요하지 않습니다.  보안 주체가 리소스와 다른 계정에 있는 경우 보안 주체는 해당 권한을 부여하는 연결된 IAM 정책이 필요합니다.

워크로드 팀은 워크로드에 필요한 권한을 관리하고자 하는 경우가 많습니다.  이렇게 하려면 새 IAM 역할 및 권한 정책을 생성해야 할 수 있습니다.  팀이 권한 IAM 경계에서 부여할 수 있는 최대 권한 범위를 캡처하고 이 문서를 팀이 IAM 역할 및 권한을 관리하는 데 사용할 수 있는 IAM 역할에 연결할 수 있습니다.  이 접근 방식은 IAM 관리 액세스 권한을 가질 때 발생하는 위험을 완화하면서 작업을 완료할 수 있는 기능을 제공할 수 있습니다.

보다 세분화된 단계는 권한 있는 액세스 관리(PAM) 및 일시적으로 향상된 액세스 관리(TEAM) 기술을 구현하는 것입니다.  의 한 가지 예는 보안 주체PAM가 권한 있는 작업을 수행하기 전에 다단계 인증을 수행하도록 요구하는 것입니다.  자세한 내용은 MFA-보호된 API 액세스 구성을 참조하세요. TEAM 에는 보안 주체가 액세스 권한을 높일 수 있는 승인 및 기간을 관리하는 솔루션이 필요합니다.  한 가지 접근 방법은 액세스 권한이 높은 역할에 대한 IAM 역할 신뢰 정책에 보안 주체를 일시적으로 추가하는 것입니다.  또 다른 접근 방식은 정상적인 작업에서 세션 정책 을 사용하여 IAM 역할이 보안 주체에게 부여한 권한을 범위로 축소한 다음 승인된 기간 동안 이 제한을 일시적으로 해제하는 것입니다. AWS 및 일부 파트너가 검증한 솔루션에 대해 자세히 알아보려면 Temporary elevated access를 참조하세요.

구현 단계

  1. 워크로드와 환경을 별도의 AWS 계정으로 분리합니다.

  2. SCPs를 사용하여 조직의 멤버 계정 내 보안 주체에게 부여할 수 있는 최대 권한 세트를 줄입니다.

    1. 허용 목록 접근 방식을 사용하여 허용된 작업을 제외한 모든 작업과 허용되는 조건을 거부SCPs하는 를 작성하는 것이 좋습니다. 먼저 제어하려는 리소스를 정의하고 효과를 거부로 설정합니다. NotAction 요소를 사용하여 지정한 작업을 제외한 모든 작업을 거부합니다. 이 작업을 NotLike 조건과 결합하여 StringNotLike 및 와 같은 해당 작업의 허용 시기를 정의합니다 ArnNotLike.

    2. Service control policy examples를 참조하세요.

  3. IAM 리소스 정책을 사용하여 리소스에 대해 허용되는 작업에 대한 조건을 범위 내리고 지정합니다.  IAM 역할 신뢰 정책의 조건을 사용하여 역할 수임에 대한 제한을 생성합니다.

  4. 워크로드 팀이 자신의 워크로드 IAM 역할 및 IAM 권한을 관리하는 데 사용할 수 있는 IAM 역할에 권한 경계를 할당합니다.

  5. 필요에 따라 PAM 및 TEAM 솔루션을 평가합니다.

리소스

관련 문서:

관련 예제:

관련 도구: