공유 VPC에서 VPC 엔드포인트를 사용하여 계정 간 액세스를 구성합니다. - Amazon Keyspaces(Apache Cassandra용)

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

공유 VPC에서 VPC 엔드포인트를 사용하여 계정 간 액세스를 구성합니다.

리소스를 애플리케이션과 AWS 계정 분리하기 위해 다양한 리소스를 만들 수 있습니다. 예를 들어 Amazon Keyspaces 테이블에 대한 계정 하나, 개발 환경의 애플리케이션 계정 하나, 프로덕션 환경의 애플리케이션 계정 하나를 생성할 수 있습니다. 이 주제에서는 공유 VPC의 인터페이스 VPC 엔드포인트를 사용하여 Amazon Keyspaces에 대한 크로스 계정 액세스를 설정하는 데 필요한 구성 단계를 안내합니다.

Amazon Keyspaces의 VPC 엔드포인트를 구성하는 방법에 대한 자세한 단계는 3단계: Amazon Keyspaces에 대한 VPC 엔드포인트 생성 섹션을 참조하세요.

이 예제에서는 공유 VPC에서 다음 세 개의 계정을 사용합니다.

  • Account A — 이 계정에는 VPC 엔드포인트, VPC 서브넷, Amazon Keyspaces 테이블을 비롯한 인프라가 포함되어 있습니다.

  • Account B — 이 계정에는 Account A에서 Amazon Keyspaces 테이블에 연결해야 하는 개발 환경의 애플리케이션이 포함되어 있습니다.

  • Account C — 이 계정에는 Account A에서 Amazon Keyspaces 테이블에 연결해야 하는 프로덕션 환경의 애플리케이션이 포함되어 있습니다.

공유 VPC를 사용하는 동일한 AWS 리전 에서 동일한 조직이 소유한 세 개의 계정을 보여주는 다이어그램입니다.

Account A는 Account B 및 Account C이 액세스해야 하는 리소스가 포함된 계정이므로, Account A는 신뢰하는 계정입니다. Account B 및 Account C는 Account A에서 리소스에 액세스해야 하는 보안 주체가 있는 계정이고 Account B 및 Account C은 신뢰 받는 계정입니다. 신뢰하는 계정은 IAM 역할을 공유하여 신뢰 받는 계정에 권한을 부여합니다. 다음 절차에서는 Account A에서 필요한 구성 단계를 간략하게 설명합니다.

Account A에 대한 구성

  1. 서브넷의 리소스 AWS Resource Access Manager 공유를 생성하고 프라이빗 서브넷을 및 와 공유하는 데 사용합니다. Account B Account C

    Account B 및 Account C는 공유된 서브넷에서 리소스를 보고 생성할 수 있습니다.

  2. 에 의해 구동되는 Amazon Keyspaces 프라이빗 VPC 엔드포인트를 생성하십시오. AWS PrivateLink이렇게 하면 Amazon Keyspaces 서비스 엔드포인트에 대한 공유 서브넷 전체와 DNS 항목에 걸쳐 공유되는 여러 엔드포인트가 생성됩니다.

  3. Amazon Keyspaces 키스페이스 및 테이블을 생성합니다.

  4. 다음 정책 예제와 같이 Amazon Keyspaces 테이블에 대한 전체 액세스 권한, Amazon Keyspaces 시스템 테이블에 대한 읽기 액세스 권한을 갖고, Amazon EC2 VPC 리소스를 설명할 수 있는 IAM 역할을 생성합니다.

    {
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "CrossAccountAccess",
            "Effect": "Allow",
            "Action": [
                "ec2:DescribeNetworkInterfaces",
                "ec2:DescribeVpcEndpoints",
                "cassandra:*"
            ],
            "Resource": "*"
        }
    ]
}

  5. 다음 예와 같이 Account B 및 Account C가 신뢰할 수 있는 계정으로 간주할 수 있는 IAM 역할 신뢰 정책을 구성합니다.

    {
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::111111111111:root"
            },
            "Action": "sts:AssumeRole",
            "Condition": {}
        }
    ]
}

    크로스 계정 IAM 정책에 대한 자세한 내용은 IAM 사용 설명서의 크로스 계정 정책을 참조하세요.

Account B 및 Account C에서의 구성

  1. Account B및 Account C에서 새 역할을 만들고 Account A에서 생성된 공유 역할을 주체가 맡도록 허용하는 다음 정책을 연결합니다.

    {
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "ec2.amazonaws.com"
            },
            "Action": "sts:AssumeRole"
        }
    ]
}

    주도자가 공유 역할을 맡도록 허용하는 것은 AWS Security Token Service ()AWS STS의 AssumeRole API를 사용하여 구현됩니다. 자세한 내용은 IAM 사용 설명서에서 AWS 계정 자신이 소유한 다른 IAM 사용자에게 액세스 권한 제공을 참조하십시오.

  2. Account B 및 Account C에서는 SIGV4 인증 플러그인을 활용하는 애플리케이션을 생성할 수 있습니다. 그러면 애플리케이션이 공유 역할을 맡아 공유 VPC의 VPC 엔드포인트를 통해 Account A에 위치한 Amazon Keyspaces 테이블에 연결할 수 있습니다. SIGV4에 대한 자세한 내용은 Amazon Keyspaces에 프로그래밍 방식으로 액세스하기 위한 보안 인증 정보 생성 섹션을 참조하세요.