기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다. # Lake Formation에서의 교차 계정 데이터 공유 Lake Formation 교차 계정 기능을 사용하면 사용자가 여러 AWS 계정 AWS 조직 간에 분산된 데이터 레이크를 안전하게 공유하거나 다른 계정의 IAM 보안 주체와 직접 공유하여 데이터 카탈로그 메타데이터 및 기본 데이터에 대한 세분화된 액세스를 제공할 수 있습니다. 대기업은 일반적으로 여러 개를 사용하며 AWS 계정, 이러한 계정 중 다수는 단일에서 관리하는 데이터 레이크에 액세스해야 할 수 있습니다 AWS 계정. 사용자 및 AWS Glue 추출, 변환 및 로드(ETL) 작업은 여러 계정의 테이블을 쿼리하고 조인할 수 있으며 Lake Formation 테이블 수준 및 열 수준 데이터 보호를 계속 활용할 수 있습니다. 데이터 카탈로그 리소스에 대한 Lake Formation 권한을 외부 계정에 부여하거나 다른 계정의 IAM 보안 주체에게 직접 부여하면 Lake Formation은 AWS Resource Access Manager (AWS RAM) 서비스를 사용하여 리소스를 공유합니다. 피부여자 계정이 부여자 계정과 동일한 조직에 속해 있는 경우, 피부여자는 공유 리소스를 즉시 사용할 수 있습니다. 피부여자 계정이 동일한 조직에 속하지 않은 경우는 리소스 부여를 수락하거나 거부하도록 피부여자 계정에 초대를 AWS RAM 보냅니다. 그런 다음 공유 리소스를 사용할 수 있도록 하려면 피부여자 계정의 데이터 레이크 관리자가 AWS RAM 콘솔 또는를 사용하여 초대를 AWS CLI 수락해야 합니다. Lake Formation은 하이브리드 액세스 모드에서 외부 계정과의 데이터 카탈로그 리소스 공유를 지원합니다. 하이브리드 액세스 모드는 AWS Glue Data Catalog의 데이터베이스 및 테이블에 대한 Lake Formation 권한을 선택적으로 활성화할 수 있는 유연성을 제공합니다. 
 하이브리드 액세스 모드를 사용하면 이제 다른 기존 사용자 또는 워크로드의 권한 정책을 중단하지 않고 특정 사용자 집합에 대해 Lake Formation 권한을 설정할 수 있는 증분 경로가 제공됩니다. 자세한 내용은 [하이브리드 액세스 모드](hybrid-access-mode.md) 단원을 참조하십시오. **직접 교차 계정 공유** 승인된 보안 주체는 외부 계정의 IAM 보안 주체와 명시적으로 리소스를 공유할 수 있습니다. 이 기능은 계정 소유자가 외부 계정의 누가 리소스에 액세스할 수 있는지 제어하고자 할 때 유용합니다. IAM 보안 주체가 받는 권한은 직접 부여와 보안 주체에게 단계적으로 부여되는 계정 수준 부여의 조합입니다. 권한 부여의 수신자만 직접 교차 계정 권한 부여를 볼 수 있습니다. 리소스 공유를 받는 보안 주체는 다른 보안 주체와 리소스를 공유할 수 없습니다. **데이터 카탈로그 리소스를 공유하는 방법** 단일 Lake Formation 권한 부여 작업으로 다음 데이터 카탈로그 리소스에 대한 계정 간 권한을 부여할 수 있습니다. + 데이터베이스 + 개별 테이블(선택적 열 필터링 포함) + 선택한 테이블 몇 개 + 데이터베이스의 모든 테이블(모든 테이블 와일드카드 사용) 데이터베이스 및 테이블을 다른 계정의 다른 AWS 계정 또는 IAM 보안 주체와 공유하는 두 가지 옵션이 있습니다. + Lake Formation 태그 기반 액세스 제어(LF-TBAC)(권장) Lake Formation 태그 기반 액세스 제어는 속성을 기반으로 권한을 정의하는 권한 부여 전략입니다. 태그 기반 액세스 제어를 사용하여 외부 IAM 보안 주체, 조직 및 조직 단위(OU)와 데이터 카탈로그 리소스(데이터베이스 AWS 계정, 테이블 및 열)를 공유할 수 있습니다.OUs Lake Formation에서 이러한 속성을 LF 태그라고 합니다. 자세한 내용은 [Lake Formation 태그 기반 액세스 제어를 사용하여 데이터 레이크 관리](https://docs.aws.amazon.com/lake-formation/latest/dg/managing-dl-tutorial.html)를 참조하세요. **참고** 교차 계정 권한 부여에 AWS Resource Access Manager 사용할 수 있는 데이터 카탈로그 권한을 부여하는 LF-TBAC 방법입니다. Lake Formation은 이제 LF-TBAC 방식을 사용하여 조직 및 조직 단위에 교차 계정 권한 부여를 지원합니다. 이 기능을 활성화하려면 **교차 계정 버전 설정**을 **버전 3** 이상으로 업데이트해야 합니다. 자세한 내용은 [교차 계정 데이터 공유 버전 설정 업데이트](optimize-ram.md) 단원을 참조하십시오. + Lake Formation 명명된 리소스 명명된 리소스 방법을 사용하는 Lake Formation 크로스 계정 데이터 공유를 사용하면 데이터 카탈로그 테이블 및 데이터베이스에 대한 권한 부여 옵션을 사용하여 외부 AWS 계정, IAM 보안 주체, 조직 또는 조직 단위에 Lake Formation 권한을 부여할 수 있습니다. 권한 부여 작업은 해당 리소스를 자동으로 공유합니다. **참고** Lake Formation 자격 증명을 사용하여 AWS Glue 크롤러가 다른 계정의 데이터 스토어에 액세스하도록 허용할 수도 있습니다. 자세한 내용은 AWS Glue 개발자 안내서의 [교차 계정 크롤링](https://docs.aws.amazon.com/glue/latest/dg/crawler-configuration.html#cross-account-crawling)을 참조하세요. Athena 및 Amazon Redshift Spectrum과 같은 통합 서비스를 사용하려면 쿼리에 공유 리소스를 포함할 수 있는 리소스 링크가 필요합니다. 리소스 링크에 대한 자세한 내용은 [Lake Formation에서 리소스 링크가 작동하는 방식](resource-links-about.md) 섹션을 참조하세요. 고려 사항 및 제한 사항은 [계정 간 데이터 공유 모범 사례 및 고려 사항](cross-account-notes.md) 섹션을 참조하십시오. **Topics** + [사전 조건](cross-account-prereqs.md) + [교차 계정 데이터 공유 버전 설정 업데이트](optimize-ram.md) + [외부 계정에서 AWS 계정 또는 IAM 보안 주체 간에 데이터 카탈로그 테이블 및 데이터베이스 공유](cross-account-data-share-steps.md) + [계정과 공유되는 데이터베이스 또는 테이블에 대한 권한 부여](regranting-shared-resources.md) + [리소스 링크 권한 부여](granting-link-permissions.md) + [공유 테이블의 기본 데이터에 액세스](cross-account-read-data.md) + [계정 간 CloudTrail 로깅](cross-account-logging.md) + [AWS Glue 및 Lake Formation을 모두 사용하여 교차 계정 권한 관리하기](hybrid-cross-account.md) + [GetResourceShares API 작업을 사용하여 모든 교차 계정 권한 부여 보기](cross-account-getresourcepolicies.md) **관련 주제** [Lake Formation 권한 개요](lf-permissions-overview.md) [공유 데이터 카탈로그 테이블 및 데이터베이스 액세스 및 보기](viewing-shared-resources.md) [리소스 링크 생성](creating-resource-links.md) [교차 계정 액세스 문제 해결](troubleshooting.md#trouble-cross-account) # 사전 조건 AWS 계정이 다른 계정 또는 다른 계정의 보안 주체와 데이터 카탈로그 리소스(카탈로그, 데이터베이스 및 테이블)를 공유하려면 먼저 다음 사전 조건을 충족해야 합니다. **일반 교차 계정 데이터 공유 요구 사항** + 하이브리드 액세스 모드에서 Data Catalog 데이터베이스 및 테이블을 공유하고 페더레이션 카탈로그에서 객체를 공유하려면 **교차 계정 버전 설정**을 **버전 4**로 업데이트해야 합니다. + 데이터 카탈로그 리소스에 교차 계정 권한을 부여하려면 먼저 해당 리소스에 대한 `IAMAllowedPrincipals` 그룹에서 모든 Lake Formation 권한을 취소해야 합니다. 호출 보안 주체가 리소스에 액세스할 수 있는 교차 계정 권한을 가지고 있고 리소스에 `IAMAllowedPrincipals` 권한이 있는 경우, Lake Formation은 `AccessDeniedException`을 발생시킵니다. 이 요구 사항은 Lake Formation 모드에서 기본 데이터 위치를 등록하는 경우에만 적용됩니다. 하이브리드 모드에서 데이터 위치를 등록하는 경우 `IAMAllowedPrincipals` 그룹 권한이 공유 데이터베이스 또는 테이블에 존재할 수 있습니다. + 공유하려는 테이블이 포함된 데이터베이스의 경우 새 테이블의 기본 부여 권한이 `Super`에서 `IAMAllowedPrincipals`로 변경되지 않도록 해야 합니다. Lake Formation 콘솔에서 데이터베이스를 편집하고 **이 데이터베이스의 새 테이블에 대한 IAM 액세스 제어만 사용을** 끄거나 다음 AWS CLI 명령을 입력하여 `database`를 데이터베이스 이름으로 바꿉니다. 기본 데이터 위치가 하이브리드 액세스 모드로 등록된 경우 이 기본 설정을 변경할 필요가 없습니다. 하이브리드 액세스 모드에서 Lake Formation을 사용하면 동일한 리소스에서 Amazon S3 및 AWS Glue 에 대한 Lake Formation 권한 및 IAM 권한 정책을 선택적으로 적용할 수 있습니다. ``` aws glue update-database --name database --database-input '{"Name":"database","CreateTableDefaultPermissions":[]}' ``` + 교차 계정 권한을 부여하려면 권한 부여자에게 AWS Glue 및 AWS RAM 서비스에 대한 필수 AWS Identity and Access Management (IAM) 권한이 있어야 합니다. AWS 관리형 정책은 필요한 권한을 `AWSLakeFormationCrossAccountManager` 부여합니다. 를 사용하여 리소스 공유를 수신하는 계정의 데이터 레이크 관리자에게는 다음과 같은 추가 정책이 AWS RAM 있어야 합니다. 이를 통해 관리자는 AWS RAM 리소스 공유 초대를 수락할 수 있습니다. 또한 관리자는 이를 통해 조직과 리소스를 공유할 수 있습니다. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ram:AcceptResourceShareInvitation", "ram:RejectResourceShareInvitation", "ec2:DescribeAvailabilityZones", "ram:EnableSharingWithAwsOrganization" ], "Resource": "*" } ] } ``` ------ + 데이터 카탈로그 리소스를 AWS Organizations 또는 조직 단위와 공유하려면 조직과의 공유를 활성화해야 합니다 AWS RAM. 조직과의 공유를 활성화하는 방법에 대한 자세한 내용은 *AWS RAM 사용 설명서*의 [AWS 조직과의 공유 활성화](https://docs.aws.amazon.com/ram/latest/userguide/getting-started-sharing.html#getting-started-sharing-orgs)를 참조하세요. 조직과 공유할 수 있는 `ram:EnableSharingWithAwsOrganization` 권한이 있어야 합니다. + 다른 계정의 IAM 보안 주체와 직접 리소스를 공유하려면 **교차 계정 버전 설정**을 **버전 3**으로 업데이트해야 합니다. 이 설정은 **데이터 카탈로그 설정** 페이지에서 사용할 수 있습니다. **버전 1**을 사용하는 경우 설정 [교차 계정 데이터 공유 버전 설정 업데이트](optimize-ram.md) 업데이트 지침을 참조하세요. + AWS Glue 서비스 관리형 키로 암호화된 데이터 카탈로그 리소스를 다른 계정과 공유할 수 없습니다. 고객의 암호화 키로 암호화된 데이터 카탈로그 리소스만 공유할 수 있으며, 리소스 공유를 받는 계정에는 데이터 카탈로그 암호화 키에 대한 객체 암호 해독 권한이 있어야 합니다. **LF-TBAC 요구 사항을 사용한 교차 계정 데이터 공유** + 데이터 카탈로그 리소스를 AWS Organizations 및 조직 단위(OUs)와 공유하려면 **교차 계정 버전 설정을** **버전 3** 이상으로 업데이트해야 합니다. + **교차 계정 버전 설정**의 버전 3과 데이터 카탈로그 리소스를 공유하려면 권한 부여자에게 계정의 AWS 관리형 정책 `AWSLakeFormationCrossAccountManager`에 정의된 IAM 권한이 있어야 합니다. + **교차 계정 버전 설정**의 버전 1 또는 버전 2를 사용하는 경우 LF-TBAC을 활성화하는 데이터 카탈로그 리소스 정책(`glue:PutResourcePolicy`)이 있어야 합니다. 자세한 내용은 [AWS Glue 및 Lake Formation을 모두 사용하여 교차 계정 권한 관리하기](hybrid-cross-account.md) 단원을 참조하십시오. + 현재 AWS Glue 데이터 카탈로그 리소스 정책을 사용하여 리소스를 공유하고 있고 **교차 계정 버전 설정** 버전 3을 사용하여 교차 계정 권한을 부여하려는 경우, [AWS Glue 및 Lake Formation을 모두 사용하여 교차 계정 권한 관리하기](hybrid-cross-account.md) 섹션에 표시된 대로 `glue:PutResourcePolicy` API 작업을 사용하여 데이터 카탈로그 설정에서 `glue:ShareResource` 권한을 추가해야 합니다. 계정에서 AWS Glue 데이터 카탈로그 리소스 정책(버전 1 및 버전 2는 `glue:PutResourcePolicy` 권한 사용)을 사용하여 교차 계정 액세스 권한을 부여하지 않은 경우에는 이 정책이 필요하지 않습니다. ``` { "Effect": "Allow", "Action": [ "glue:ShareResource" ], "Principal": {"Service": [ "ram.amazonaws.com" ]}, "Resource": [ "arn:aws:glue:::table/*/*", "arn:aws:glue:::database/*", "arn:aws:glue:::catalog" ] } ``` + 계정이 AWS Glue Data Catalog 리소스 정책을 사용하여 교차 계정 공유를 설정했고, 현재 리소스 공유를 위해 명명된 리소스 메서드 또는 리소스 공유에 AWS RAM 를 사용하는 **교차 계정 설정** 버전 3의 LF-TBAC을 사용하고 있는 경우, `glue:PutResourcePolicy` API 작업을 간접 호출할 때 `EnableHybrid` 인수를 `'true'`로 설정해야 합니다. 자세한 내용은 [AWS Glue 및 Lake Formation을 모두 사용하여 교차 계정 권한 관리하기](hybrid-cross-account.md) 단원을 참조하십시오. **공유 리소스에 액세스하는 각 계정에 설정이 필요합니다.** + 리소스를 공유하는 경우 공유 리소스를 보려면 소비자 계정의 한 명 AWS 계정이상의 사용자가 데이터 레이크 관리자여야 합니다. 데이터 레이크 관리자 생성 방법에 대한 자세한 내용은 [데이터 레이크 관리자 생성](initial-lf-config.md#create-data-lake-admin) 섹션을 참조하세요. 데이터 레이크 관리자는 계정의 다른 보안 주체에게 공유 리소스에 대한 Lake Formation 권한을 부여할 수 있습니다. 다른 보안 주체는 데이터 레이크 관리자가 리소스에 대한 권한을 부여할 때까지 공유 리소스에 액세스할 수 없습니다. + Athena 및 Redshift Spectrum과 같은 통합 서비스를 사용하려면 쿼리에 공유 리소스를 포함할 수 있는 리소스 링크가 필요합니다. 보안 주체는 데이터 카탈로그에 다른 AWS 계정의 공유 리소스로 연결되는 리소스 링크를 생성해야 합니다. 리소스 링크에 대한 자세한 내용은 [Lake Formation에서 리소스 링크가 작동하는 방식](resource-links-about.md) 섹션을 참조하세요. + 리소스가 IAM 보안 주체와 직접 공유되는 경우, Athena를 사용하여 테이블을 쿼리하려면 보안 주체가 리소스 링크를 만들어야 합니다. 리소스 링크를 만들려면 계정 소유자는 Lake Formation `CREATE_TABLE` 또는 `CREATE_DATABASE` 권한과 `glue:CreateTable` 또는 `glue:CreateDatabase` IAM 권한이 필요합니다. 생산자 계정이 동일 또는 다른 보안 주체와 동일한 데이터베이스 아래의 다른 테이블을 공유하는 경우 해당 보안 주체는 즉시 테이블을 쿼리할 수 있습니다. **참고** 데이터 레이크 관리자와 데이터 레이크 관리자가 권한을 부여한 보안 주체의 경우 공유 리소스가 로컬(소유) 리소스인 것처럼 데이터 카탈로그에 표시됩니다. 추출, 전환, 적재(ETL) 작업 시 공유 리소스의 기본 데이터에 액세스할 수 있습니다. 공유 리소스의 경우 Lake Formation 콘솔의 **테이블** 및 **데이터베이스** 페이지에 소유자의 계정 ID가 표시됩니다. 공유 리소스의 기본 데이터에 액세스하면 공유 리소스 수신자 계정과 리소스 소유자 계정 모두에서 CloudTrail 로그 이벤트가 생성됩니다. CloudTrail 이벤트는 데이터에 액세스한 보안 주체의 ARN을 포함할 수 있지만, 이는 수신자 계정이 로그에 보안 주체 ARN을 포함하도록 선택한 경우에만 해당됩니다. 자세한 내용은 [계정 간 CloudTrail 로깅](cross-account-logging.md) 단원을 참조하십시오. # 교차 계정 데이터 공유 버전 설정 업데이트 때때로는 교차 계정 데이터 공유 설정을 AWS Lake Formation 업데이트하여 AWS RAM 사용량에 대한 변경 사항을 구분하고 교차 계정 데이터 공유 기능에 대한 업데이트를 지원합니다. Lake Formation이 이 작업을 수행하면 **교차 계정 버전 설정**의 새 버전이 생성됩니다. ## 교차 계정 버전 설정 간의 주요 차이점 다양한 **교차 계정 버전 설정**에서 교차 계정 데이터 공유가 작동하는 방식에 대한 자세한 내용은 다음 섹션을 참조하세요. **참고** 다른 계정과 데이터를 공유하려면 권한 부여자에게 `AWSLakeFormationCrossAccountManager` 관리형 IAM 정책 권한이 있어야 합니다. 이는 모든 버전의 전제 조건입니다. **교차 계정 버전 설정**을 업데이트해도 수신자가 공유 리소스에 대해 갖는 권한에는 영향을 주지 않습니다. 이는 버전 1에서 버전 2로, 버전 2에서 버전 3으로, 버전 1에서 버전 3으로 업데이트할 때 적용됩니다. 버전을 업데이트할 때는 아래 나열된 고려 사항을 참조하세요. **버전 1** *명명된 리소스 방법: *각 교차 계정 Lake Formation 권한 부여를 하나의 AWS RAM 리소스 공유에 매핑합니다. 사용자(권한 부여자 역할 또는 보안 주체)에게는 추가 권한이 필요하지 않습니다. *LF-TBAC 메서드: *교차 계정 Lake Formation 권한 부여는 AWS RAM 를 사용하여 데이터를 공유하지 않습니다. 사용자는 `glue:PutResourcePolicy` 권한이 있어야 합니다. 버전 업데이트의 이점: 초기 버전 - 해당 없음.** 버전 업데이트 시 고려 사항: 초기 버전 - 해당 없음** **버전 2** *명명된 리소스 방법: * 여러 교차 계정 권한 부여를 하나의 AWS RAM 리소스 공유에 매핑하여 AWS RAM 리소스 공유 수를 최적화합니다. 사용자에게는 추가 권한이 필요하지 않습니다. *LF-TBAC 메서드: *교차 계정 Lake Formation 권한 부여는 AWS RAM 를 사용하여 데이터를 공유하지 않습니다. 사용자는 `glue:PutResourcePolicy` 권한이 있어야 합니다. *버전 업데이트의 이점: * AWS RAM 용량 활용을 최적화하여 계정 간 설정을 확장할 수 있습니다. *버전 업데이트 시 고려 사항: *교차 계정 Lake Formation 권한을 부여하려는 사용자는 `AWSLakeFormationCrossAccountManager` AWS 관리형 정책에 권한이 있어야 합니다. 그렇지 않으면 다른 계정과 리소스를 성공적으로 공유할 수 있는 `ram:AssociateResourceShare` 및 `ram:DisassociateResourceShare` 권한이 있어야 합니다. **버전 3** *명명된 리소스 방법: * 여러 교차 계정 권한 부여를 하나의 AWS RAM 리소스 공유에 매핑하여 AWS RAM 리소스 공유 수를 최적화합니다. 사용자에게는 추가 권한이 필요하지 않습니다. *LF-TBAC 메서드: * Lake Formation은 교차 계정 권한 부여 AWS RAM 에를 사용합니다. 사용자는 `glue:PutResourcePolicy` 권한에 glue:ShareResource 문을 추가해야 합니다. 수신자는 리소스 공유 초대를 수락해야 합니다 AWS RAM. 버전 업데이트의 이점: 다음 기능을 지원합니다.** + 외부 계정의 IAM 보안 주체와 명시적으로 리소스를 공유할 수 있습니다. 자세한 내용은 [데이터 카탈로그 리소스에 대한 권한 부여](granting-catalog-permissions.md) 단원을 참조하십시오. + 조직 또는 조직 단위(OU)에 대해 LF-TBAC 방식을 사용하여 교차 계정 공유를 활성화합니다. + 교차 계정 권한 부여에 대한 추가 AWS Glue 정책을 유지 관리하는 오버헤드를 제거합니다. *버전 업데이트 시 고려 사항:* LF-TBAC 메서드를 사용하여 리소스를 공유할 때 권한 부여자가 버전 3보다 낮은 버전을 사용하고 받는 사람이 버전 3 이상을 사용할 경우, 권한 부여자에게는 다음과 같은 오류 메시지가 표시됩니다. “잘못된 교차 계정 부여 요청입니다. 소비자 계정은 교차 계정 버전: v3에 동의했습니다. `DataLakeSetting`의 `CrossAccountVersion`을 최소 버전인 v3로 업데이트하세요(서비스: AmazonDataCatalog; 상태 코드: 400; 오류 코드: InvalidInputException)”. 하지만 권한 부여자가 버전 3을 사용하고 수신자가 버전 1 또는 버전 2를 사용할 경우 LF 태그를 사용한 교차 계정 부여가 성공적으로 진행됩니다. 명명된 리소스 메서드를 사용하여 이루어진 교차 계정 권한 부여는 다양한 버전에서 호환됩니다. 권한 부여자 계정이 이전 버전(버전 1 또는 2)을 사용하고 수신자 계정이 최신 버전(버전 3 이상)을 사용하더라도 교차 계정 액세스 기능은 호환성 문제나 오류 없이 원활하게 작동합니다. 다른 계정의 IAM 보안 주체와 직접 리소스를 공유하려면 권한 부여자만 버전 3을 사용해야 합니다. LF-TBAC 방식을 사용하여 이루어진 교차 계정 승인을 위해서는 사용자가 계정에 AWS Glue Data Catalog 리소스 정책을 가지고 있어야 합니다. 버전 3으로 업데이트하면 LF-TBAC 권한 부여에 AWS RAM을 사용합니다. AWS RAM 기반 교차 계정 권한 부여가 성공하도록 허용하려면 [AWS Glue 및 Lake Formation을 모두 사용하여 교차 계정 권한 관리하기](hybrid-cross-account.md) 섹션에 표시된 대로 기존 Data Catalog 리소스 정책에 `glue:ShareResource` 문을 추가해야 합니다. **버전 4** Data Catalog 리소스를 하이브리드 액세스 모드로 공유하거나 페더레이션 카탈로그에서 객체를 공유하려면, 권한 부여자는 버전 4 이상의 버전을 사용해야 합니다. **버전 5** 교차 계정 버전 5는 교차 계정 리소스 공유를 개선하여 다른 계정과 무제한 수의 테이블을 공유할 수 있으므로 리소스 유형당 이전 리소스 연결 제한이 없습니다. 시작하려면 Lake Formation 콘솔 또는 API를 통해 교차 계정 버전 5로 업그레이드하세요. 새로운 교차 계정 권한 부여는 개별 리소스 연결 대신 리소스 공유의 와일드카드 패턴을 자동으로 사용합니다. 기존의 모든 교차 계정 공유는 계속 작동하며 기존의 모든 Lake Formation APIs 계속 호환됩니다. *버전 업데이트의 이점: *교차 계정 v5는 교차 계정 공유를 개선하여 계정 간에 수십만 개의 테이블을 공유할 수 있습니다. *버전 업데이트 시 고려 사항: *버전 5 업그레이드 후 새 권한 부여는 기존 AWS Resource Manager 리소스 공유에 와일드카드 리소스 패턴을 추가하거나 와일드카드 패턴으로 새 공유를 생성합니다. 버전 5로 업그레이드한 후에는 다운그레이드가 지원되지 않습니다. ## AWS RAM 리소스 공유 최적화 교차 계정 권한 부여의 새 버전(버전 2 이상)은 AWS RAM 용량을 최적으로 활용하여 교차 계정 사용을 극대화합니다. 리소스를 외부 AWS 계정 또는 IAM 보안 주체와 공유하는 경우 Lake Formation은 새 리소스 공유를 생성하거나 리소스를 기존 공유와 연결할 수 있습니다. Lake Formation은 기존 공유와 연결함으로써 소비자가 수락해야 하는 리소스 공유 초대의 수를 줄여줍니다. 버전 5는 개별 리소스 연결 대신 와일드카드 기반 리소스 패턴을 사용하여 RAM 사용을 추가로 최적화하여 리소스 공유당 리소스 연결을 크게 줄입니다. ## TBAC를 통해 AWS RAM 공유를 활성화하거나 보안 주체와 직접 리소스 공유 다른 계정의 IAM 보안 주체와 직접 리소스를 공유하거나 조직 또는 조직 구성 단위에 대한 TBAC 교차 계정 공유를 활성화하려면 **교차 계정 버전 설정**을 버전 3으로 업데이트해야 합니다. AWS RAM 리소스 제한에 대한 자세한 내용은 섹션을 참조하세요[계정 간 데이터 공유 모범 사례 및 고려 사항](cross-account-notes.md). ### 교차 계정 버전 설정을 업데이트하는 데 필요한 권한 교차 계정 권한 부여자에게 `AWSLakeFormationCrossAccountManager` 관리형 IAM 정책 권한이 있는 경우, 교차 계정 권한 부여자 역할 또는 주체에 대한 추가 권한 설정이 필요하지 않습니다. 하지만 교차 계정 부여자가 관리형 정책을 사용하지 않는 경우 새 버전의 교차 계정 부여가 성공하려면 권한 부여자 역할 또는 보안 주체에 다음과 같은 IAM 권한이 부여되어야 합니다. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "VisualEditor1", "Effect": "Allow", "Action": [ "ram:AssociateResourceShare", "ram:DisassociateResourceShare", "ram:GetResourceShares" ], "Resource": "*", "Condition": { "StringLike": { "ram:ResourceShareName": "LakeFormation*" } } } ] } ``` ------ ## 새 버전을 활성화하려면 다음 단계에 따라 콘솔 또는를 AWS Lake Formation 통해 **교차 계정 버전 설정을** 업데이트합니다 AWS CLI. ------ #### [ Console ] 1. **데이터 카탈로그** **설정 페이지의 교차 계정 버전 설정**에서 버전 **2**, 버전 **3**, 버전 **4** 또는 버전 5를 선택합니다. **** **버전 1**을 선택하면 Lake Formation이 기본 리소스 공유 모드를 사용합니다. ![\[화면에는 계정의 모든 LF 태그에 대한 권한이 표시됩니다.\]](http://docs.aws.amazon.com/ko_kr/lake-formation/latest/dg/images/cross-account-version-setting.png) 1. **저장**을 선택합니다. ------ #### [ AWS Command Line Interface (AWS CLI) ] `put-data-lake-settings` AWS CLI 명령을 사용하여 `CROSS_ACCOUNT_VERSION` 파라미터를 설정합니다. 허용되는 값은 1, 2, 3, 4, 5입니다. ``` aws lakeformation put-data-lake-settings --region us-east-1 --data-lake-settings file://settings { "DataLakeAdmins": [ { "DataLakePrincipalIdentifier": "arn:aws:iam::111122223333:user/test" } ], "CreateDatabaseDefaultPermissions": [], "CreateTableDefaultPermissions": [], "Parameters": { "CROSS_ACCOUNT_VERSION": "3" } } ``` ------ **중요** **버전 2** 또는 **버전 3**을 선택하면 모든 새로운 **명명된 리소스** 권한 부여는 새로운 교차 계정 권한 부여 모드를 거치게 됩니다. 기존 교차 계정 공유에 AWS RAM 용량을 최적으로 사용하려면 이전 버전으로 수행된 권한 부여를 취소하고 새 모드에서 다시 부여하는 것이 좋습니다. # 외부 계정에서 AWS 계정 또는 IAM 보안 주체 간에 데이터 카탈로그 테이블 및 데이터베이스 공유 이 섹션에는 외부 계정, IAM 보안 주체, AWS 조직 또는 조직 단위에 데이터 카탈로그 리소스에 대한 교차 AWS 계정 권한을 부여하는 방법에 대한 지침이 포함되어 있습니다. 권한 부여 작업은 해당 리소스를 자동으로 공유합니다. **Topics** + [태그 기반 액세스 제어를 사용한 데이터 공유](cross-account-TBAC.md) + [명명된 리소스 방법을 사용한 교차 계정 데이터 공유](cross-account-named-resource.md) # 태그 기반 액세스 제어를 사용한 데이터 공유 AWS Lake Formation 태그 기반 액세스 제어(LF-TBAC)는 속성을 기반으로 권한을 정의하는 권한 부여 전략입니다. 다음 단계에서는 LF 태그를 사용하여 교차 계정 권한을 부여하는 방법을 설명합니다. **생산자/권한 부여자 계정에 필요한 설정** 1. LF 태그를 추가합니다. 1. Lake Formation 콘솔에 데이터 레이크 관리자 또는 LF 태그 생성자 계정으로 로그인합니다. 1. 왼쪽 탐색 창에서 **권한** 및 **LF 태그 및 권한**을 선택합니다. 1. **LF 태그 추가**를 선택합니다. LF 태그를 만드는 방법에 대한 상세 지침은 [LF 태그 생성](TBAC-creating-tags.md) 섹션을 참조하세요. 1. 계정 또는 외부 계정의 IAM 보안 주체에 **LF 태그 키-값** 페어에 대한 **설명** 및/또는 **연결** 권한을 부여합니다. **LF 태그 키-값** 페어에 대한 권한을 부여하면 해당 보안 주체가 LF 태그를 조회하고, 이를 Data Catalog 리소스(데이터베이스, 테이블, 열)에 할당할 수 있습니다. 1. 다음으로 데이터 레이크 관리자 또는 **연결** 권한이 있는 IAM 보안 주체는 데이터베이스, 테이블 또는 열에 LF 태그를 할당할 수 있습니다. 자세한 내용은 [데이터 카탈로그 리소스에 LF 태그 할당](TBAC-assigning-tags.md) 단원을 참조하십시오. 1. 그런 다음 LF 태그 표현식을 사용하여 외부 계정에 데이터 권한을 부여합니다. 이렇게 하면 권한의 피부여자 또는 수신자가 동일한 키 및 값으로 태그가 지정된 Data Catalog 리소스에 액세스할 수 있습니다. 1. 탐색 창에서 **권한**과 **데이터 권한**을 선택합니다. 1. **권한 부여**를 선택합니다. 1. **권한 부여** 페이지의 **보안 주체**에서 **외부 계정**을 선택하고 보안 주체의 피부여자 AWS 계정 ID나 IAM 역할 또는 외부 보안 주체에 직접 교차 계정 권한을 부여하는 경우 보안 주체의 Amazon 리소스 이름(ARN)(보안 주체 ARN)을 입력합니다. 계정 ID를 입력한 후 **Enter** 키를 눌러야 합니다. ![\[외부 계정 및 LF 태그 키-값 페어가 지정된 권한 부여 화면입니다.\]](http://docs.aws.amazon.com/ko_kr/lake-formation/latest/dg/images/cross-acct-grant-tags.png) 1. **LF 태그 또는 카탈로그 리소스**의 경우 **LF 태그와 일치하는 리소스**(권장)를 선택합니다. 1. **LF 태그 키-값 페어** 또는 **저장된 LF 태그 표현식** 옵션을 선택합니다. 1. ****LF 태그 키-값 페어**를 선택하는 경우 피부여자 계정과 공유되는 Data Catalog 리소스와 연결된 **LF 태그**의 키와 값을 입력합니다**. 피부여자에게는 LF 태그 표현식에서 일치하는 LF 태그가 할당된 Data Catalog 리소스에 대한 권한이 부여됩니다. LF 태그 표현식이 태그 키당 여러 값을 지정하는 경우 태그 값 중 하나가 일치할 수 있습니다. 1. LF 태그 표현식과 일치하는 리소스에 부여할 데이터베이스 수준 또는 테이블 수준 권한을 선택합니다. **중요** 데이터 레이크 관리자는 피부여자 계정의 보안 주체에게 공유 리소스에 대한 권한을 부여해야 하므로 항상 권한 부여 옵션을 사용하여 교차 계정 권한을 부여해야 합니다. 자세한 내용은 [콘솔을 사용하여 LF 태그 권한 부여](TBAC-granting-tags-console.md) 단원을 참조하십시오. **참고** 교차 계정 직접 승인을 받는 보안 주체에게는 **부여 가능한 권한** 옵션이 제공되지 않습니다. **수신자/피부여자 계정에서 필요한 설정** 1. 소비자 계정의 데이터 레이크 관리자 권한으로 Lake Formation 콘솔에 로그인합니다. 1. 그런 다음 소비자 계정에서 리소스 공유를 수신합니다. 1. AWS RAM 콘솔을 엽니다. 1. 탐색 창의 **나와 공유됨**에서 **리소스 공유**를 선택합니다. 1. 리소스 공유를 선택하고 **리소스 공유 수락**을 선택합니다. 1. 다른 계정과 리소스를 공유해도 해당 리소스는 여전히 생산자 계정에 속하며 Athena 콘솔에 표시되지 않습니다. Athena 콘솔에서 리소스를 표시하려면 공유 리소스를 가리키는 리소스 링크를 만들어야 합니다. 리소스 링크 생성에 대한 지침은 [공유 데이터 카탈로그 테이블에 대한 리소스 링크 만들기](create-resource-link-table.md) 및 [공유 데이터 카탈로그 데이터베이스에 대한 리소스 링크 만들기](create-resource-link-database.md) 섹션을 참조하세요. 1. Data Catalog에서 **데이터베이스** 또는 **테이블**을 선택합니다. 1. 데이터베이스/테이블 페이지에서 **생성**, **리소스 링크**를 선택합니다. 1. 데이터베이스 리소스 링크에 다음 정보를 입력합니다. + **리소스 링크 이름** - 리소스 링크의 고유한 이름입니다. + **대상 카탈로그** - 리소스 링크를 생성하는 카탈로그입니다. + **공유 데이터베이스 리전** - 다른 리전에서 리소스 링크를 생성할 경우, 데이터베이스의 해당 리전이 공유됩니다. + **공유 데이터베이스** - 공유 데이터베이스를 선택합니다. + **공유 데이터베이스의 카탈로그 ID** - 공유 데이터베이스의 카탈로그 ID를 입력합니다. 1. **생성(Create)**을 선택합니다. 데이터베이스 목록에서 새로 생성된 리소스 링크를 볼 수 있습니다. 마찬가지로 공유 테이블에 대한 리소스 링크를 생성할 수 있습니다. 1. 이제 리소스를 공유하는 IAM 보안 주체에게 리소스 링크에 대한 **설명** 권한을 부여합니다. 1. **데이터베이스/테이블** 페이지에서 리소스 링크를 선택하고, **작업** 메뉴에서 **권한 부여**를 선택합니다. 1. **권한 부여** 섹션에서 **IAM 사용자 및 역할**을 선택합니다. 1. 리소스 링크에 대한 액세스 권한을 부여할 IAM 역할을 선택합니다. 1. **리소스 링크** 권한 섹션에서 **설명**을 선택합니다. 1. **권한 부여**를 선택합니다. 1. 그런 다음 소비자 계정의 보안 주체에게 **LF 태그 키-값 권한**을 부여합니다. Lake Formation 콘솔의 **권한**, **LF 태그 및 권한**에서 소비자 계정에서 공유된 LF 태그를 찾을 수 있어야 합니다. 데이터베이스, 테이블 및 열을 포함하여 권한 부여자 계정에서 공유된 리소스에서 권한 부여자에서 공유된 태그를 연결할 수 있습니다. 리소스에 대한 권한을 다른 보안 주체에게 추가로 부여할 수 있습니다. ![\[화면에는 계정의 LF 태그에 대한 권한이 표시됩니다.\]](http://docs.aws.amazon.com/ko_kr/lake-formation/latest/dg/images/lf-tag-permissions.png) 1. 탐색 창의 **권한**, **데이터 권한**에서 **권한 부여**를 선택합니다. 1. **권한 부여** 페이지에서 **IAM 사용자 및 역할**을 선택합니다. 1. 그런 다음 계정의 IAM 사용자 및 역할을 선택하여 공유 데이터베이스/테이블에 대한 액세스 권한을 부여합니다. 1. 다음으로 **LF 태그 또는 카탈로그 리소스**의 경우 **LF 태그와 일치하는 리소스**를 선택합니다. 1. 그런 다음 공유되는 LF 태그의 키와 값을 선택합니다. 1. 그런 다음 IAM 사용자 및 역할에 부여하려는 데이터베이스 및 테이블 권한을 선택합니다. IAM 사용자 및 역할이 다른 사용자/역할에 권한을 부여할 수 있도록 **부여 가능한 권한**을 선택할 수도 있습니다. 1. **권한 부여**를 선택합니다. 1. Lake Formation 콘솔의 **데이터 권한**에서 권한 부여를 볼 수 있습니다. # 명명된 리소스 방법을 사용한 교차 계정 데이터 공유 다른 AWS 계정의 보안 주체 또는 외부 AWS 계정 또는에 직접 권한을 부여할 수 있습니다 AWS Organizations. 조직 또는 조직 단위에 Lake Formation 권한을 부여하는 것은 AWS 계정 해당 조직 또는 조직 단위의 모든에 권한을 부여하는 것과 같습니다. 외부 계정이나 조직에 권한을 부여할 때는 **부여 가능한 권한** 옵션을 포함해야 합니다. 관리자가 외부 계정의 다른 팀원에게 공유 리소스에 대한 권한을 부여할 때까지 외부 계정의 데이터 레이크 관리자만 공유 리소스에 액세스할 수 있습니다. **참고** **부여 가능한 권한** 옵션은 외부 계정에서 IAM 보안 주체에 직접 권한을 부여할 때는 지원되지 않습니다. [Granting database permissions using the named resource method](granting-database-permissions.md)의 지침에 따라 명명된 리소스 방법을 사용하여 교차 계정 권한을 부여합니다. 다음 동영상에서는 Lake Formation을 사용하여 AWS 조직과 데이터를 공유하는 방법을 보여줍니다. [![AWS Videos](http://img.youtube.com/vi/https://www.youtube.com/embed/S-Mdcmq6oPM?controls=0&/0.jpg)](http://www.youtube.com/watch?v=https://www.youtube.com/embed/S-Mdcmq6oPM?controls=0&) # 계정과 공유되는 데이터베이스 또는 테이블에 대한 권한 부여 다른 AWS 계정에 속한 데이터 카탈로그 리소스를 계정 AWS 과 공유한 후 데이터 레이크 관리자는 공유 리소스에 대한 권한을 계정의 다른 보안 주체에게 부여할 수 있습니다. 하지만 리소스에 대한 권한을 다른 AWS 계정이나 조직에 부여할 수는 없습니다. AWS Lake Formation 콘솔, API 또는 AWS Command Line Interface (AWS CLI)를 사용하여 권한을 부여할 수 있습니다. **공유 데이터베이스(명명된 리소스 방법, 콘솔)에 대한 권한 부여** + [Granting database permissions using the named resource method](granting-database-permissions.md)의 지침을 따르세요. **LF 태그 또는 카탈로그 리소스** 아래의 **데이터베이스** 목록에서 데이터베이스의 리소스 링크가 아닌 외부 계정의 데이터베이스를 선택했는지 확인합니다. 데이터베이스 목록에 데이터베이스가 표시되지 않으면 데이터베이스에 대한 AWS Resource Access Manager (AWS RAM) 리소스 공유 초대를 수락했는지 확인합니다. 자세한 내용은 [에서 리소스 공유 초대 수락 AWS RAM](accepting-ram-invite.md) 단원을 참조하십시오. 또한 `CREATE_TABLE` 및 `ALTER` 권한의 경우 [데이터 위치 권한 부여(동일 계정)](granting-location-permissions-local.md)의 지침을 따르고 **등록된 계정 위치** 필드에 소유 계정 ID를 입력해야 합니다. **공유 테이블(명명된 리소스 방법, 콘솔)에 대한 권한 부여** + [명명된 리소스 방법을 사용하여 테이블 권한 부여](granting-table-permissions.md)의 지침을 따르세요. **LF 태그 또는 카탈로그 리소스** 아래의 **데이터베이스** 목록에서 데이터베이스의 리소스 링크가 아닌 외부 계정의 데이터베이스를 선택했는지 확인합니다. 테이블 목록에 테이블이 표시되지 않으면 테이블에 대한 AWS RAM 리소스 공유 초대를 수락했는지 확인합니다. 자세한 내용은 [에서 리소스 공유 초대 수락 AWS RAM](accepting-ram-invite.md) 단원을 참조하십시오. 또한 `ALTER` 권한의 경우, [데이터 위치 권한 부여(동일 계정)](granting-location-permissions-local.md)의 지침을 따르고 **등록된 계정 위치** 필드에 소유 계정 ID를 입력해야 합니다. **공유 리소스(LF-TBAC 방법, 콘솔)에 대한 권한을 얻으려면** + [데이터 카탈로그 권한 부여](granting-catalog-perms-TBAC.md#granting-cat-perms-TBAC-console)의 지침을 따르세요. **LF 태그 또는 카탈로그 리소스** 섹션에서 외부 계정이 내 계정에 부여한 정확한 LF 태그 표현식 또는 해당 표현식의 하위 집합을 부여합니다. 예를 들어 외부 계정에서 부여 옵션을 사용하여 내 계정에 LF 태그 표현식 `module=customers AND environment=production`을 부여한 경우, 데이터 레이크 관리자는 계정의 보안 주체에 동일한 표현식 또는 `module=customers` 또는 `environment=production`을 부여할 수 있습니다. LF 태그 표현식을 통해 리소스에 부여된 Lake Formation 권한과 동일하거나 하위 집합(예: `SELECT`, `ALTER` 등)만 부여할 수 있습니다. **공유 테이블에 대한 권한을 부여하려면(명명된 리소스 메서드 AWS CLI)** + 다음과 유사한 명령을 입력합니다. 이 예에서는 + AWS 계정 ID는 1111-2222-3333입니다. + 테이블을 소유하고 내 계정에 테이블을 부여한 계정은 1234-5678-9012입니다. + 공유 테이블 `pageviews`에 대한 `SELECT` 권한이 사용자 `datalake_user1`에게 부여되고 있습니다. 해당 사용자는 계정의 보안 주체입니다. + `pageviews` 테이블은 계정 1234-5678-9012가 소유한 `analytics` 데이터베이스에 있습니다. ``` aws lakeformation grant-permissions --principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:user/datalake_user1 --permissions "SELECT" --resource '{ "Table": {"CatalogId":"123456789012", "DatabaseName":"analytics", "Name":"pageviews"}}' ``` 단, `resource` 인수의 `CatalogId` 속성에 소유 계정을 지정해야 합니다. # 리소스 링크 권한 부여 다음 단계에 따라 AWS 계정의 보안 주체에 하나 이상의 리소스 링크에 대한 AWS Lake Formation 권한을 부여합니다. 리소스 링크를 만든 후에는 사용자만 보고 액세스할 수 있습니다. (데이터베이스에 대해 **이 데이터베이스의 새 테이블에 대해 IAM 액세스 제어만 사용**이 활성화되어 있지 않다고 가정합니다.) 계정의 다른 보안 주체가 리소스 링크에 액세스할 수 있도록 허용하려면 최소한 `DESCRIBE` 권한을 부여하세요. **중요** 리소스 링크에 대한 권한을 부여해도 대상(링크된) 데이터베이스 또는 테이블에 대한 권한은 부여되지 않습니다. 대상에 대한 권한을 별도로 부여해야 합니다. Lake Formation 콘솔, API 또는 AWS Command Line Interface ()를 사용하여 권한을 부여할 수 있습니다AWS CLI. ------ #### [ console ] **Lake Formation 콘솔을 사용하여 리소스 링크 권한 부여** 1. 다음 중 하나를 수행하세요. + 데이터베이스 리소스 링크의 경우 [Granting database permissions using the named resource method](granting-database-permissions.md)의 단계에 따라 다음을 수행합니다. 1. Data Catalog, **데이터베이스** 아래의 데이터베이스 목록에서 리소스 링크를 선택합니다. 1. **권한 부여**를 선택하여 **권한 부여** 페이지를 엽니다. 1. 권한을 부여할 보안 주체를 지정합니다. 1. **카탈로그** 및 **데이터베이스** 필드가 채워집니다. + 테이블 리소스 링크의 경우 [명명된 리소스 방법을 사용하여 테이블 권한 부여](granting-table-permissions.md)의 단계에 따라 다음을 수행합니다. 1. Data Catalog, **테이블** 아래의 테이블 목록에서 리소스 링크를 선택합니다. 1. **권한 부여** 페이지를 엽니다. 1. 보안 주체를 지정합니다. 1. **카탈로그**, **데이터베이스**, **테이블** 필드가 채워집니다. 1. 보안 주체를 지정합니다. 1. **권한**에서 부여할 권한을 선택합니다. 선택적으로 부여 가능한 권한을 선택합니다. ![\[권한 섹션에는 1개의 타일이 있습니다. 타일에는 부여할 리소스 링크 권한에 대한 확인란 그룹이 있습니다. 확인란에는 '삭제'와 '설명'이 포함되어 있습니다. 해당 그룹 아래에는 부여 가능한 권한을 위한 동일한 확인란으로 구성된 또 다른 그룹이 있습니다.\]](http://docs.aws.amazon.com/ko_kr/lake-formation/latest/dg/images/grant-resource-link-permissions-TBAC.png) 1. **권한 부여**를 선택합니다. ------ #### [ AWS CLI ] **를 사용하여 리소스 링크 권한을 부여하려면 AWS CLI** + 리소스 링크를 리소스로 지정하여 `grant-permissions` 명령을 실행합니다. **Example** 이 예제에서는 AWS 계정 1111-2222-3333`datalake_user1`의 데이터베이스에 `incidents-link` 있는 테이블 리소스 링크`issues`에서 `DESCRIBE` 사용자에게를 부여합니다. ``` 1. aws lakeformation grant-permissions --principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:user/datalake_user1 --permissions "DESCRIBE" --resource '{ "Table": {"DatabaseName":"issues", "Name":"incidents-link"}}' ``` ------ **추가 참고:** [리소스 링크 생성](creating-resource-links.md) [Lake Formation 권한 참조](lf-permissions-reference.md) # 공유 테이블의 기본 데이터에 액세스 AWS 계정 A가 계정 B와 데이터 카탈로그 테이블을 공유한다고 가정합니다. 예를 들어`SELECT`, 계정 B의 보안 주체가 공유 테이블의 기본 데이터를 읽을 수 있으려면 다음 조건을 충족해야 합니다. + 계정 B의 데이터 레이크 관리자는 공유를 수락해야 합니다. (계정 A와 B가 같은 조직에 있거나 Lake Formation 태그 기반 액세스 제어 방법을 사용하여 권한을 부여한 경우에는 필요하지 않습니다.) + 데이터 레이크 관리자는 계정 A가 공유 테이블에 부여한 Lake Formation `SELECT` 권한을 보안 주체에 다시 부여해야 합니다. + 보안 주체는 해당 테이블, 해당 테이블이 포함된 데이터베이스 및 계정 A 데이터 카탈로그에 대해 다음과 같은 IAM 권한을 가지고 있어야 합니다. **참고** 다음 IAM 정책에서: **를 AWS 계정 A의 계정 ID로 바꿉니다. **을 유효한 리전으로 바꿉니다. **를 공유 테이블이 포함된 계정 A의 데이터베이스 이름으로 바꿉니다. **을 공유 테이블의 이름으로 바꿉니다. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "glue:GetTable", "glue:GetTables", "glue:GetPartition", "glue:GetPartitions", "glue:BatchGetPartition", "glue:GetDatabase", "glue:GetDatabases" ], "Resource": [ "arn:aws:glue:us-east-1:111122223333:table//
", "arn:aws:glue:us-east-1:111122223333:database/", "arn:aws:glue:us-east-1:111122223333:catalog" ] }, { "Effect": "Allow", "Action": [ "lakeformation:GetDataAccess" ], "Resource": [ "*" ] } ] } ``` ------ **추가 참고:** [에서 리소스 공유 초대 수락 AWS RAM](accepting-ram-invite.md) # 계정 간 CloudTrail 로깅 Lake Formation은 데이터 레이크의 데이터에 대한 모든 크로스 계정 액세스에 대한 중앙 집중식 감사 추적을 제공합니다. 수신자 AWS 계정이 공유 테이블의 데이터에 액세스하면 Lake Formation은 CloudTrail 이벤트를 소유 계정의 CloudTrail 로그에 복사합니다. 복사된 이벤트에는 Amazon Athena 및 Amazon Redshift Spectrum과 같은 통합 서비스의 데이터에 대한 쿼리와 AWS Glue 작업별 데이터 액세스가 포함됩니다. 데이터 카탈로그 리소스의 교차 계정 작업에 대한 CloudTrail 이벤트도 비슷하게 복사됩니다. 리소스 소유자의 경우, Amazon S3에서 객체 수준 로깅을 활성화하면 S3 CloudTrail 이벤트를 Lake Formation CloudTrail 이벤트와 조인하는 쿼리를 실행하여 S3 버킷에 액세스한 계정을 확인할 수 있습니다. **Topics** + [교차 계정 CloudTrail 로그에 보안 주체 자격 증명 포함](#cross-account-logging-optin) + [Amazon S3 교차 계정 액세스에 대한 CloudTrail 로그 쿼리](#cross-account-logging-s3) ## 교차 계정 CloudTrail 로그에 보안 주체 자격 증명 포함 기본적으로 공유 리소스 수신자의 로그에 추가되고 리소스 소유자의 로그에 복사되는 교차 계정 CloudTrail 이벤트에는 외부 계정 AWS 보안 주체의 보안 주체 ID만 포함되며 보안 주체(보안 주체 ARN)의 사람이 읽을 수 있는 Amazon 리소스 이름(ARN)은 포함되지 않습니다. 동일한 조직 또는 팀과 같이 신뢰할 수 있는 경계 내에서 리소스를 공유하는 경우, CloudTrail 이벤트에 보안 주체 ARN을 포함하도록 선택할 수 있습니다. 그러면 리소스 소유자 계정은 소유한 리소스에 액세스하는 수신자 계정의 보안 주체를 추적할 수 있습니다. **중요** 공유 리소스 수신자가 자체 CloudTrail 로그의 이벤트에서 보안 주체 ARN을 보려면 소유자 계정과 보안 주체 ARN을 공유하도록 옵트인해야 합니다. 리소스 링크를 통해 데이터에 액세스하는 경우, 공유 리소스 수신자 계정에 두 개의 이벤트, 즉 리소스 링크 액세스를 위한 이벤트 하나와 대상 리소스 액세스를 위한 이벤트가 기록됩니다. 리소스 링크 액세스 이벤트에는 보안 주체 ARN이 포함됩니다.** 대상 리소스 액세스 이벤트에는 옵트인 없는 보안 주체 ARN이 포함되지 않습니다. 리소스 링크 액세스 이벤트는 소유자 계정에 복사되지 않습니다. 다음은 기본 교차 계정 CloudTrail 이벤트(옵트인 없음)에서 발췌한 내용입니다. 데이터 액세스를 수행하는 계정은 1111-2222-3333입니다. 이 로그는 호출 계정과 리소스 소유자 계정 모두에 표시되는 로그입니다. Lake Formation은 교차 계정의 경우 두 계정의 로그를 모두 채웁니다. ``` { "eventVersion": "1.05", "userIdentity": { "type": "AWSAccount", "principalId": "AROAQGFTBBBGOBWV2EMZA:GlueJobRunnerSession", "accountId": "111122223333" }, "eventSource": "lakeformation.amazonaws.com", "eventName": "GetDataAccess", ... ... "additionalEventData": { "requesterService": "GLUE_JOB", "lakeFormationRoleSessionName": "AWSLF-00-GL-111122223333-G13T0Rmng2" }, ... } ``` 공유 리소스 소비자로서 보안 주체 ARN을 포함하도록 옵트인하면 발췌는 다음과 같이 됩니다. `lakeFormationPrincipal` 필드는 Amazon Athena, Amazon Redshift Spectrum 또는 AWS Glue 작업을 통해 쿼리를 수행하는 최종 역할 또는 사용자를 나타냅니다. ``` { "eventVersion": "1.05", "userIdentity": { "type": "AWSAccount", "principalId": "AROAQGFTBBBGOBWV2EMZA:GlueJobRunnerSession", "accountId": "111122223333" }, "eventSource": "lakeformation.amazonaws.com", "eventName": "GetDataAccess", ... ... "additionalEventData": { "requesterService": "GLUE_JOB", "lakeFormationPrincipal": "arn:aws:iam::111122223333:role/ETL-Glue-Role", "lakeFormationRoleSessionName": "AWSLF-00-GL-111122223333-G13T0Rmng2" }, ... } ``` **교차 계정 CloudTrail 로그에 보안 주체 ARN을 포함하도록 선택하는 방법** 1. Lake Formation 콘솔([https://console.aws.amazon.com/lakeformation/](https://console.aws.amazon.com/lakeformation/))을 엽니다. `Administrator` 사용자 또는 `Administrator Access` IAM 정책이 있는 사용자로 로그인합니다. 1. 탐색 창에서 **설정**을 선택합니다. 1. **데이터 카탈로그 설정** 페이지의 **기본 권한 AWS CloudTrail** 섹션에서 **리소스 소유자**에 하나 이상의 AWS 리소스 소유자 계정 IDs 입력합니다. 각 계정 ID를 입력한 후에 **Enter** 키를 누릅니다. 1. **저장**을 선택합니다. 이제 공유 리소스 수신자와 리소스 소유자 모두의 로그에 저장된 교차 계정 CloudTrail 이벤트에 보안 주체 ARN이 포함됩니다. ## Amazon S3 교차 계정 액세스에 대한 CloudTrail 로그 쿼리 공유 리소스 소유자는 S3 CloudTrail 로그를 쿼리하여 Amazon S3 버킷에 액세스한 계정을 확인할 수 있습니다(Amazon S3에서 객체 수준 로깅을 활성화한 경우 제공됨). 이는 Lake Formation에 등록한 S3 위치에만 적용됩니다. 공유 리소스 소비자가 Lake Formation CloudTrail 로그에 보안 주체 ARN을 포함하도록 옵트인한 경우, 버킷에 액세스한 역할 또는 사용자를 확인할 수 있습니다. 를 사용하여 쿼리를 실행할 때 세션 이름 속성에서 Lake Formation CloudTrail 이벤트 및 S3 CloudTrail 이벤트에 조인할 Amazon Athena수 있습니다. 쿼리를 통해 Lake Formation 이벤트는 `eventName="GetDataAccess"`에서, S3 이벤트는 `eventName="Get Object"` 또는 `eventName="Put Object"`에서 필터링할 수도 있습니다. 다음은 등록된 S3 위치의 데이터에 액세스한 Lake Formation의 교차 계정 CloudTrail 이벤트에서 발췌한 내용입니다. ``` { "eventSource": "lakeformation.amazonaws.com", "eventName": "GetDataAccess", .............. .............. "additionalEventData": { "requesterService": "GLUE_JOB", "lakeFormationPrincipal": "arn:aws:iam::111122223333:role/ETL-Glue-Role", "lakeFormationRoleSessionName": "AWSLF-00-GL-111122223333-B8JSAjo5QA" } } ``` `lakeFormationRoleSessionName` 키 값인 `AWSLF-00-GL-111122223333-B8JSAjo5QA`는 S3 CloudTrail 이벤트의 `principalId` 키에 있는 세션 이름과 결합할 수 있습니다. 다음은 S3 CloudTrail 이벤트에서 발췌한 내용입니다. 세션 이름의 위치를 보여줍니다. ``` { "eventSource": "s3.amazonaws.com", "eventName": "Get Object" .............. .............. "principalId": "AROAQSOX5XXUR7D6RMYLR:AWSLF-00-GL-111122223333-B8JSAjo5QA", "arn": "arn:aws:sets::111122223333:assumed-role/Deformationally/AWSLF-00-GL-111122223333-B8JSAjo5QA", "session Context": { "session Issuer": { "type": "Role", "principalId": "AROAQSOX5XXUR7D6RMYLR", "arn": "arn:aws:iam::111122223333:role/aws-service-role/lakeformation.amazonaws.com/Deformationally", "accountId": "111122223333", "user Name": "Deformationally" }, .............. .............. } ``` 세션 이름은 다음 형식입니다. ``` AWSLF---- ``` **`version-number`** 이 형식의 버전은 현재 `00`입니다. 세션 이름 형식이 변경되면 다음 버전은 `01`이 됩니다. **`query-engine-code`** 데이터에 액세스한 엔터티를 나타냅니다. 현재 값은 다음과 같습니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/lake-formation/latest/dg/cross-account-logging.html) **`account-id`** Lake Formation에서 자격 증명을 요청한 AWS 계정 ID입니다. **`suffix`** 무작위로 생성된 문자열입니다. # AWS Glue 및 Lake Formation을 모두 사용하여 교차 계정 권한 관리하기 데이터 카탈로그 리소스 및 기본 데이터에 대한 교차 계정 액세스 권한을 AWS Glue 또는 AWS Lake Formation을 사용하여 부여할 수 있습니다. AWS Glue에서는 데이터 카탈로그 리소스 정책을 만들거나 업데이트하여 교차 계정 권한을 부여합니다. Lake Formation에서는 Lake Formation `GRANT/REVOKE` 권한 모델과 `Grant Permissions` API 작업을 사용하여 교차 계정 권한을 부여합니다. **작은 정보** Lake Formation 권한에만 의존하여 데이터 레이크를 보호하는 것이 좋습니다. Lake Formation 콘솔 또는 AWS Resource Access Manager (AWS RAM) 콘솔을 사용하여 Lake Formation 교차 계정 부여를 볼 수 있습니다. 그러나 이러한 콘솔 페이지에는 AWS Glue 데이터 카탈로그 리소스 정책에 의해 부여된 교차 계정 권한이 표시되지 않습니다. 마찬가지로 AWS Glue 콘솔의 **설정** 페이지를 사용하여 데이터 카탈로그 리소스 정책에서 교차 계정 권한 부여를 볼 수 있지만, 이 페이지에는 Lake Formation을 사용하여 부여된 교차 계정 권한이 표시되지 않습니다. 교차 계정 권한을 보고 관리할 때 권한 부여를 놓치지 않도록 하기 위해, Lake Formation과 AWS Glue는 사용자가 Lake Formation과 AWS Glue의 교차 계정 권한 부여를 인지하고 허용하고 있음을 표시하기 위해 다음 작업을 수행하도록 요구합니다. **AWS Glue 데이터 카탈로그 리소스 정책을 사용하여 교차 계정 권한을 부여하는 경우** 계정(권한 부여자 계정 또는 생산자 계정)이 AWS RAM 을 사용하여 리소스를 공유하는 교차 계정 권한 부여를 하지 않은 경우 AWS Glue에서와 같이 데이터 카탈로그 리소스 정책을 저장할 수 있습니다. 그러나 AWS RAM 리소스 공유와 관련된 권한 부여가 이미 이루어진 경우 리소스 정책을 성공적으로 저장하려면 다음 중 하나를 수행해야 합니다. + AWS Glue 콘솔의 **설정** 페이지에서 리소스 정책을 저장하면, 정책의 권한이 Lake Formation 콘솔을 사용하여 부여된 모든 권한에 추가된다는 알림이 콘솔에 표시됩니다. 정책을 저장하려면 **계속 진행**을 선택해야 합니다. + `glue:PutResourcePolicy` API 작업을 사용하여 리소스 정책을 저장하는 경우 `EnableHybrid` 필드를 '`TRUE`'(유형 = 문자열)로 설정해야 합니다. 기존 리소스 정책을 업데이트하려면 `glue:GetResourcePolicy` API 작업을 사용하여 현재 정책을 먼저 검색한 다음 `glue:PutResourcePolicy`를 직접 호출하기 전에 필요에 따라 수정합니다. **참고** 교차 계정 액세스를 위한 AWS Glue 리소스 정책을 생성할 때 특정 사용 사례에 필요한 최소 권한만 부여합니다. 자세한 내용은 **AWS Glue 개발자 안내서의 [PutResourcePolicy 작업(Python: put\$1resource\$1policy)](https://docs.aws.amazon.com/glue/latest/dg/aws-glue-api-jobs-security.html#aws-glue-api-jobs-security-PutResourcePolicy)을 참조하세요. **Lake Formation 명명된 리소스 방법을 사용하여 교차 계정 권한을 부여하는 경우** 계정에 데이터 카탈로그 리소스 정책이 없는 경우(생산자 계정) Lake Formation 교차 계정 권한 부여는 평소와 같이 진행됩니다. 그러나 데이터 카탈로그 리소스 정책이 있는 경우, 명명된 리소스 방법을 사용하여 교차 계정 권한 부여가 성공할 수 있도록 하기 위해 다음 명령문을 추가해야 합니다. **을 유효한 리전 이름으로 바꾸고 **를 AWS 계정 ID(생산자 계정 ID)로 바꿉니다. ``` { "Effect": "Allow", "Action": [ "glue:ShareResource" ], "Principal": {"Service": [ "ram.amazonaws.com" ]}, "Resource": [ "arn:aws:glue:::table/*/*", "arn:aws:glue:::database/*", "arn:aws:glue:::catalog" ] } ``` 이 추가 문이 없으면 Lake Formation 권한 부여는 성공하지만에서 차단되고 수신자 계정 AWS RAM은 부여된 리소스에 액세스할 수 없습니다. **중요** Lake Formation 태그 기반 액세스 제어(LF-TBAC) 방법을 사용하여 계정 간 권한을 부여하는 경우, 최소한 [사전 조건](cross-account-prereqs.md)에 지정된 권한이 있는 데이터 카탈로그 리소스 정책이 있어야 합니다. **추가 참고:** [메타데이터 액세스 제어](access-control-metadata.md)(명명된 리소스 방식과 Lake Formation 태그 기반 액세스 제어(LF-TBAC) 방식에 대한 설명 참조). [공유 데이터 카탈로그 테이블 및 데이터베이스 보기](viewing-available-shared-resources.md) **AWS Glue 개발자 안내서의 [AWS Glue 콘솔에서 데이터 카탈로그 설정 관련 작업](https://docs.aws.amazon.com/glue/latest/dg/console-data-catalog-settings.html) **AWS Glue 개발자 안내서의 [교차 계정 액세스 권한 부여](https://docs.aws.amazon.com/glue/latest/dg/cross-account-access.html)(데이터 카탈로그 리소스 정책 샘플의 경우) # GetResourceShares API 작업을 사용하여 모든 교차 계정 권한 부여 보기 기업이 AWS Glue Data Catalog 리소스 정책과 Lake Formation 권한 부여를 모두 사용하여 교차 계정 권한을 부여하는 경우 모든 교차 계정 권한을 한 곳에서 볼 수 있는 유일한 방법은 `glue:GetResourceShares` API 작업을 사용하는 것입니다. 명명된 리소스 메서드를 사용하여 계정 간에 Lake Formation 권한을 부여하면 AWS Resource Access Manager (AWS RAM)는 AWS Identity and Access Management (IAM) 리소스 정책을 생성하여 AWS 계정에 저장합니다. 이 정책은 리소스에 액세스하는 데 필요한 권한을 부여합니다.는 각 교차 계정 권한 부여에 대해 별도의 리소스 정책을 AWS RAM 생성합니다. `glue:GetResourceShares` API 작업을 사용하여 이러한 모든 정책을 볼 수 있습니다. **참고** 이 작업은 데이터 카탈로그 리소스 정책도 반환합니다. 그러나 데이터 카탈로그 설정에서 메타 데이터 암호화를 활성화했는데 AWS KMS 키에 대한 권한이 없는 경우 작업은 데이터 카탈로그 리소스 정책을 반환하지 않습니다. **모든 교차 계정 권한 부여를 보려면** + 다음 AWS CLI 명령을 입력합니다. ``` aws glue get-resource-policies ``` 다음은 데이터베이스의 테이블에 대한 권한을 `db1` AWS 계정 1111-2222-3333에 부여할 때 `t`가 AWS RAM 생성하고 저장하는 리소스 정책의 예입니다. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "glue:GetTable", "glue:GetTables", "glue:GetTableVersion", "glue:GetTableVersions", "glue:GetPartition", "glue:GetPartitions", "glue:BatchGetPartition", "glue:SearchTables" ], "Principal": {"AWS": [ "111122223333" ]}, "Resource": [ "arn:aws:glue:us-east-1:111122223333:table/db1/t" ] } ] } ``` ------ **또한 다음 섹션도 참조하세요.** **AWS Glue 개발자 안내서의 [GetResourceShares 작업(Python: get\$1resource\$1policies)](https://docs.aws.amazon.com/glue/latest/dg/aws-glue-api-jobs-security.html#aws-glue-api-jobs-security-GetResourcePolicies)