AWS Organizations는 사용자가 생성해 중앙에서 관리하는 조직으로 여러 AWS 계정을 통합할 수 있는 계정 관리 서비스

AWS Organizations는 사용자가 생성해 중앙에서 관리하는 조직으로 여러 AWS 계정을 통합할 수 있는 계정 관리 서…

cloudhwang 0 1832

AWS Organizations는 사용자가 생성해 중앙에서 관리하는 조직으로 여러 AWS 계정을 통합할 수 있는 계정 관리 서비스입니다. AWS Organizations는 비즈니스의 예산, 보안과 규정 준수 요건을 충족할 수 있는 계정 관리 및 통합 결제 기능을 포함합니다. 조직의 관리자로서 조직에서 계정을 생성하고 기존 계정을 조직에 초대할 수 있습니다.

 

조직

AWS 계정을 단일 단위로 관리할 수 있도록 통합하기 위해 생성하는 개체입니다. AWS Organizations 콘솔을 사용하여 조직 내 모든 계정을 중앙에서 확인하고 관리할 수 있습니다. 조직은 마스터 계정 하나와 0개 이상의 멤버 계정을 갖습니다. 위에는 루트가, 아래에는 조직 단위가 있는 나무형 계층 구조로 계정을 조직할 수 있습니다. 각 계정은 루트에 바로 배치하거나, 계층 구조 내의 OU 중 하나에 배치할 수 있습니다. 조직은 사용자가 설정하는 기능 모음으로 결정되는 다양한 기능을 보유합니다.

루트

조직의 모든 계정에 대한 상위 컨테이너입니다. 정책을 루트에 적용하면, 해당 정책은 조직의 모든 조직 단위(OU)와 계정에 적용됩니다.

참고

지금은 루트 하나만 있습니다. AWS Organizations는 사용자가 조직을 만들 때 이 루트를 자동으로 생성합니다.

조직 단위(OU)

루트에 있는 계정을 위한 컨테이너입니다. 또한 OU는 다른 OU를 포함할 수 있기 때문에 사용자는 위쪽에는 루트가, 아래쪽에는 OU 가지가, 맨 끝에는 나뭇잎에 해당하는 계정이 있는 거꾸로 된 나무 형태의 계층 구조를 만들 수 있습니다. 정책을 계층 구조 내의 노드 하나에 연결하면, 정책은 아래쪽으로 내려와 모든 가지(OU)와 잎(계정)에 영향을 줍니다. 각 OU는 상위 OU를 하나만 가질 수 있으며, 현재 각 계정은 한 OU의 멤버만 될 수 있습니다.

계정

AWS 리소스를 포함하는 표준 AWS 계정입니다. 정책을 계정에 연결해 정책 제어를 해당 계정에만 적용할 수 있습니다.

조직에는 두 가지 유형의 계정이 있습니다. 하나는 마스터 계정으로 지정된 단일 계정이며 다른 하나는 멤버 계정입니다.

  • 마스터 계정은 조직을 생성하는 계정입니다. 조직의 마스터 계정에서 수행할 수 있는 사항은 다음과 같습니다.

    • 조직에서 계정 생성

    • 기존의 다른 계정을 조직에 초대

    • 조직에서 계정 제거

    • 초대 관리

    • 조직 내 개체(루트, OU 또는 계정)에 정책 적용

    마스터 계정은 지급인 계정을 책임지며 멤버 계정에서 발생한 모든 요금을 지불해야 합니다. 조직의 마스터 계정은 변경할 수 없습니다.

  • 조직에 속한 나머지 계정은 멤버 계정이라고 합니다. 하나의 계정은 한 번에 하나의 조직 멤버만 될 수 있습니다.

초대

다른 계정에 조직 가입을 요청하는 과정입니다. 초대는 조직의 마스터 계정에서만 발행할 수 있습니다. 초대는 계정 ID 또는 초대된 계정과 연결된 이메일 주소로 확장됩니다. 초대받은 계정이 초대를 수락하면, 해당 계정은 조직의 멤버 계정이 됩니다. 조직이 모든 멤버가 통합 결제 기능 지원에서 모든 기능 지원으로 전환하는 일을 승인해야 한다면, 현재 존재하는 모든 멤버 계정에 초대를 전송해야 합니다. 초대를 이용하려면 계정이 핸드셰이크를 교환해야 합니다. AWS Organizations 콘솔에서 작업할 때는 핸드셰이크가 표시되지 않을 수 있습니다. 그러나 AWS CLI 또는 AWS Organizations API를 사용하는 경우 핸드셰이크로 직접 작업해야 합니다.

핸드셰이크

두 당사자 간에 정보를 교환하는 다양한 단계로 구성된 과정입니다. AWS Organizations에서 이 핸드셰이크가 주로 사용되는 경우 중 하나는 초대를 위한 기본 작업을 구현할 때입니다. 핸드셰이크 메시지는 핸드셰이크 개시자와 받는 사람 간에 전달되고 응답됩니다. 메시지는 양 당사자가 항상 현재 상태를 알 수 있도록 전달됩니다. 핸드셰이크는 조직이 통합 결제 기능만 지원하다가 AWS Organizations가 제공하는 모든 기능을 지원하도록 변경할 때에도 사용됩니다. 일반적으로는 AWS Organizations API나 AWS CLI 같은 명령줄 도구를 사용할 때에만 핸드셰이크와 직접 상호 작용해야 합니다.

사용 가능한 기능 모음
  • 모든 기능 – AWS Organizations가 사용할 수 있는 기본 기능 세트입니다. 통합 결제의 모든 기능과 조직 내 계정에 대한 더 많은 제어를 제공하는 고급 기능을 함께 제공합니다. 예를 들어 모든 기능을 활성화하면 조직의 마스터 계정은 멤버 계정이 하는 일을 완전히 제어할 수 있습니다. 마스터 계정은 SCP를 적용하여 계정의 사용자(루트 사용자 포함)와 역할이 액세스할 수 있는 서비스와 작업을 제한할 수 있습니다. 마스터 계정은 멤버 계정이 조직에서 나가지 못하도록 할 수도 있습니다. 모든 기능을 활성화한 상태로 조직을 만들거나, 원래 통합 결제 기능만 제공하는 조직에서 모든 기능을 활성화할 수 있습니다. 모든 기능을 활성화하려면 초대받은 멤버 계정 모두가 마스터 계정이 과정을 시작하면서 전송한 초대를 수락해 변경 사항을 승인해야 합니다.

  • 통합 결제 – 이 기능 세트는 공유 결제 기능을 제공하지만 AWS Organizations의 고급 기능은 포함되지 않습니다. 예를 들어, 정책을 사용하여 여러 계정의 사용자와 역할이 수행할 수 있는 작업을 제한할 수 없습니다. 고급 AWS Organizations 기능을 사용하려면 조직에서 모든 기능을 활성화해야 합니다.

서비스 제어 정책(SCP)

SCP의 영향을 받는 계정에서 사용자와 역할이 사용할 수 있는 서비스와 작업을 지정하는 정책입니다. SCP는 권한을 부여하지 않는다는 점을 제외하고 IAM 권한 정책과 비슷합니다. 대신, SCP는 조직, 조직 단위(OU) 또는 계정에 대한 최대 권한을 지정합니다. SCP를 조직 루트 또는 OU에 연결하면 SCP가 멤버 계정의 개체에 대한 권한을 제한합니다.

태그 정책

조직 계정의 리소스 전체에서 태그를 표준화하는 데 도움이 될 수 있는 정책의 한 유형입니다. 태그 정책에서 특정 리소스에 대한 태그 지정 규칙을 지정할 수 있습니다.

허용 목록 및 거부 목록 비교

 

허용 목록과 거부 목록은 SCP를 적용하여 계정에 사용 가능한 권한을 필터링할 때 사용하는 보완적인 기술입니다.

  • 허용 목록(“화이트리스팅”이라고도 알려짐) – 허용되는 액세스를 명시적으로 지정합니다. 다른 모든 액세스는 묵시적으로 차단됩니다. 기본적으로 AWS Organizations는  FullAWSAccess 라는 AWS 관리형 정책을 모든 루트, OU 및 계정에 연결합니다. 따라서 조직을 구축할 때 사용자가 원하기 전까지는 무엇도 차단되지 않습니다. 다시 말해서, 기본적으로 모든 권한이 허용됩니다. 권한을 제한할 준비가 끝났다면,  FullAWSAccess  정책을 더욱 제한적이고 원하는 권한 모음만 허용하는 정책과 교체하면 됩니다. 이렇게 하면 영향받는 계정의 사용자 및 역할은 IAM 정책이 모든 작업을 허용해도 지정된 수준의 액세스만 이용할 수 있습니다. 루트의 기본 정책을 교체하면, 조직의 모든 계정이 제한의 적용을 받게 됩니다. SCP는 권한을 부여하지 않으며 필터링만하기 때문에 계층 구조의 낮은 수준에 다시 추가할 수는 없습니다.

  • 거부 목록(“블랙리스팅”이라고도 알려짐) – 허용되지 않는 액세스를 명시적으로 지정합니다. 다른 액세스는 모두 허용됩니다. 이 시나리오에서는 명시적으로 차단하지 않는 이상 모든 권한이 허용됩니다. 이는 AWS Organizations의 기본 동작입니다. 기본적으로 AWS Organizations는  FullAWSAccess 라는 AWS 관리형 정책을 모든 루트, OU 및 계정에 연결합니다. 따라서 모든 계정은 AWS Organizations–가 적용한 제한을 받지 않고 모든 서비스와 작업에 액세스할 수 있습니다. 위에서 설명한 허용 목록 기술과 달리, 거부 목록을 사용할 때는 일반적으로 “모두” 허용하는 기본  FullAWSAccess  정책을 그대로 둡니다. 그런 다음 원치 않는 서비스와 작업에 대한 액세스를 명시적으로 거부하는 추가 정책을 연결합니다. IAM 권한 정책과 마찬가지로 서비스 작업의 명시적 거부는 해당 작업에 대한 모든 허용을 무시합니다.

0 Comments