기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다. # Lake Formation 권한에 온보딩 AWS Lake Formation 는 AWS Glue Data Catalog (데이터 카탈로그)를 사용하여 Amazon S3 데이터 레이크 및 Amazon Redshift와 같은 외부 데이터 소스에 대한 메타데이터를 카탈로그, 데이터베이스 및 테이블 형식으로 저장합니다. Data Catalog의 메타데이터는 카탈로그, 데이터베이스 및 테이블로 구성된 3단계 데이터 계층 구조로 구성됩니다. 다양한 소스의 데이터를 카탈로그라는 논리적 컨테이너로 구성합니다. 데이터베이스는 테이블의 컬렉션입니다. 데이터 카탈로그에는 외부 계정의 공유 데이터베이스 및 테이블에 대한 링크인 리소스 링크도 포함되어 있으며, 데이터 레이크의 데이터에 대한 교차 계정 액세스에 사용됩니다. 각 AWS 계정에는 AWS 리전당 하나의 데이터 카탈로그가 있습니다. Lake Formation은 Amazon S3의 기본 데이터가 포함된 Data Catalog의 카탈로그, 데이터베이스, 테이블 및 열에 대한 액세스 권한을 부여하거나 취소할 수 있는 관계형 데이터베이스 관리 시스템(RDBMS) 권한 모델을 제공합니다. Lake Formation 권한 모델에 대해 자세히 알아보기 전에 다음 배경 정보를 검토하는 것이 좋습니다. + Lake Formation에서 관리하는 데이터 레이크는 Amazon Simple Storage Service(S3)의 지정된 위치에 있습니다. Data Catalog에는 카탈로그 객체도 포함되어 있습니다. 각 카탈로그는 Amazon Redshift 데이터 웨어하우스, Amazon DynamoDB 데이터베이스 및 Snowflake, MySQL과 같은 타사 데이터 소스와 페더레이션 커넥터를 통해 통합된 30개 이상의 외부 데이터 소스의 데이터를 나타냅니다. + Lake Formation은 로그 및 관계형 데이터베이스의 데이터와 같이 데이터 레이크로 가져올 소스 데이터와 Amazon S3의 데이터 레이크에 있는 데이터에 대한 메타데이터가 포함된 데이터 카탈로그를 유지 관리합니다. Data Catalog에는 Amazon S3를 제외한 외부 데이터 소스의 데이터에 대한 메타데이터도 포함되어 있습니다. 메타데이터는 카탈로그, 데이터베이스와 테이블로 구성됩니다. 메타데이터 테이블에는 스키마, 위치, 파티션 및 해당 테이블이 나타내는 데이터에 대한 기타 정보가 포함됩니다. 메타데이터 데이터베이스는 테이블의 컬렉션입니다. + Lake Formation 데이터 카탈로그는 AWS Glue에서 사용하는 것과 동일한 데이터 카탈로그입니다. AWS Glue 크롤러를 사용하여 데이터 카탈로그 테이블을 생성할 수 있고 AWS Glue 추출, 전환, 적재(ETL) 작업을 사용하여 데이터 레이크에 기본 데이터를 채울 수 있습니다. + Data Catalog의 카탈로그, 데이터베이스 및 테이블을 *Data Catalog 리소스*라고 합니다. 데이터 카탈로그의 테이블을 데이터 소스의 테이블 또는 Amazon S3의 테이블 형식 데이터와 구분하기 위해 메타데이터 테이블이라고 합니다.** 메타데이터 테이블이 Amazon S3 또는 데이터 소스에서 가리키는 데이터를 기본 데이터라고 합니다.** + *보안 주체*는 사용자 또는 역할, Amazon Quick 사용자 또는 그룹, SAML 공급자를 통해 Lake Formation으로 인증하거나 교차 계정 액세스 제어를 위해 AWS 계정 ID, 조직 ID 또는 조직 단위 ID를 사용하는 사용자 또는 그룹입니다. + AWS Glue 크롤러는 메타데이터 테이블을 생성하지만 Lake Formation 콘솔, API 또는 AWS Command Line Interface ()를 사용하여 메타데이터 테이블을 수동으로 생성할 수도 있습니다AWS CLI. 메타데이터 테이블을 생성할 때에는 위치를 지정해야 합니다. 데이터베이스를 생성할 때 위치는 선택 사항입니다. 테이블 위치는 Amazon S3 위치 또는 Amazon Relational Database Service(RDS) 데이터베이스와 같은 데이터 소스 위치일 수 있습니다. 데이터베이스 위치는 항상 Amazon S3 위치입니다. + Amazon Athena 및 Amazon Redshift와 같이 Lake Formation과 통합되는 서비스는 데이터 카탈로그에 액세스하여 메타데이터를 가져오고 쿼리 실행에 대한 승인을 확인할 수 있습니다. 통합 서비스의 전체 목록은 [AWS Lake Formation과의 서비스 통합](service-integrations.md) 섹션을 참조하세요. **Topics** + [Lake Formation 권한 개요](lf-permissions-overview.md) + [Lake Formation 페르소나 및 IAM 권한 참조](permissions-reference.md) + [데이터 레이크의 기본 설정 변경](change-settings.md) + [암시적 Lake Formation 권한](implicit-permissions.md) + [Lake Formation 권한 참조](lf-permissions-reference.md) + [IAM Identity Center 통합](identity-center-integration.md) + [데이터 레이크에 Amazon S3 위치 추가](register-data-lake.md) + [하이브리드 액세스 모드](hybrid-access-mode.md) + [에서 객체 생성 AWS Glue Data Catalog](populating-catalog.md) + [Lake Formation의 워크플로를 사용하여 데이터 가져오기](workflows.md) # Lake Formation 권한 개요 AWS Lake Formation에는 다음과 같은 두 가지 주요 권한 유형이 있습니다. + 메타데이터 액세스 - 데이터 카탈로그 리소스에 대한 권한(데이터 카탈로그 권한).** 보안 주체는 이러한 권한을 통해 데이터 카탈로그에서 메타데이터 데이터베이스 및 테이블을 생성하고, 읽고, 업데이트하고, 삭제할 수 있습니다. + 기본 데이터 액세스 - Amazon Simple Storage Service (Amazon S3)의 위치에 대한 권한(*데이터 액세스 권한* 및 *데이터 위치 권한*). + 데이터 레이크 권한을 통해 보안 주체는 기본 Amazon S3 위치(데이터 카탈로그 리소스가 가리키는 데이터)에 데이터를 읽고 쓸 수 있습니다.** + 데이터 위치 권한을 통해 보안 주체는 특정 Amazon S3 위치를 가리키는 메타데이터 데이터베이스 및 테이블을 생성하고 변경할 수 있습니다. 두 영역 모두에서 Lake Formation은 Lake Formation 권한과 AWS Identity and Access Management (IAM) 권한의 조합을 사용합니다. IAM 권한 모델은 IAM 정책으로 구성됩니다. Lake Formation 권한 모델은 `Grant SELECT on tableName to userName`과 같은 DBMS 스타일의 GRANT/REVOKE 명령으로 구현됩니다. 보안 주체가 데이터 카탈로그 리소스 또는 기본 데이터에 대한 액세스를 요청하는 경우 요청이 성공하려면 IAM과 Lake Formation의 권한 검사를 모두 통과해야 합니다. ![\[요청자의 요청은 Lake Formation 권한과 IAM 권한이라는 두 개의 '문'을 통과해야 리소스에 도달할 수 있습니다.\]](http://docs.aws.amazon.com/ko_kr/lake-formation/latest/dg/images/permissions_doors.png) Lake Formation 권한은 데이터 카탈로그 리소스, Amazon S3 위치 및 해당 위치의 기본 데이터에 대한 액세스를 제어합니다. IAM 권한은 Lake Formation 및 AWS Glue API와 리소스에 대한 액세스를 제어합니다. 따라서 데이터 카탈로그(`CREATE_TABLE`)에 메타데이터 테이블을 생성할 수 있는 Lake Formation 권한이 있더라도 `glue:CreateTable` API에 대한 IAM 권한이 없으면 작업이 실패합니다. (`glue:` 권한인 이유는 Lake Formation에서 AWS Glue 데이터 카탈로그를 사용하기 때문입니다.) **참고** Lake Formation 권한은 해당 권한이 부여된 리전에서만 적용됩니다. AWS Lake Formation 에서는 각 보안 주체(사용자 또는 역할)에게 Lake Formation 관리형 리소스에 대한 작업을 수행할 수 있는 권한을 부여해야 합니다. 보안 주체는 데이터 레이크 관리자 또는 Lake Formation 권한 부여가 가능한 다른 보안 주체로부터 필요한 권한을 부여받습니다. Lake Formation 권한을 보안 주체에 부여할 때 선택적으로 해당 권한을 다른 보안 주체에게 전달할 수 있는 기능을 부여할 수 있습니다. Lake Formation 콘솔의 Lake Formation API, AWS Command Line Interface (AWS CLI) 또는 **데이터 권한** 및 **데이터 위치** 페이지를 사용하여 Lake Formation 권한을 부여하고 취소할 수 있습니다. # 세분화된 액세스 제어 방법 데이터 레이크의 목표는 데이터에 대한 세분화된 액세스 제어를 확보하는 것입니다. Lake Formation에서 이것은 데이터 카탈로그 리소스 및 Amazon S3 위치에 대한 세분화된 액세스 제어를 의미합니다. 다음 방법 중 하나를 사용하여 세분화된 액세스 제어를 달성할 수 있습니다. | 방법 | Lake Formation 권한 | IAM 권한 | 설명 | | --- | --- | --- | --- | | 방법 1 | 을 엽니다. | 세분화 | AWS Glue와의 하위 버전 호환성을 위한 **기본적인 방법**입니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/lake-formation/latest/dg/access-control-fine-grained.html) Lake Formation 콘솔에서 이 방법은 **IAM 액세스 제어만 사용**으로 표시됩니다. | | 방법 2 | 세분화 | 대략적 | **권장되는 방법입니다.** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/lake-formation/latest/dg/access-control-fine-grained.html) | **중요** 다음에 유의하세요. 기본적으로 Lake Formation에는 기존 AWS Glue 데이터 카탈로그 동작과의 호환성을 위해 **IAM 액세스 제어 설정만 사용**이 활성화되어 있습니다. Lake Formation 권한 사용으로 전환한 후에는 이러한 설정을 비활성화하는 것이 좋습니다. 자세한 내용은 [데이터 레이크의 기본 설정 변경](change-settings.md) 단원을 참조하십시오. 데이터 레이크 관리자와 데이터베이스 생성자는 사용자가 반드시 숙지해야 하는 암시적인 Lake Formation 권한을 가지고 있습니다. 자세한 내용은 [암시적 Lake Formation 권한](implicit-permissions.md) 단원을 참조하십시오. # 메타데이터 액세스 제어 데이터 카탈로그 리소스에 대한 액세스 제어의 경우, 다음 논의에서는 Lake Formation 권한을 통한 세분화된 액세스 제어와 IAM 정책을 통한 대략적인 액세스 제어를 가정합니다. 데이터 카탈로그 리소스에 대한 Lake Formation 권한을 부여하는 방법에는 두 가지가 있습니다. + **명명된 리소스 액세스 제어** - 이 방법을 사용하면 데이터베이스 또는 테이블 이름을 지정하여 특정 데이터베이스 또는 테이블에 대한 권한을 부여할 수 있습니다. 권한 부여의 형식은 다음과 같습니다. 권한 부여 옵션을 사용하여 리소스에 대한 권한을 보안 주체에 부여합니다.****** 권한 부여 옵션을 사용하면 피부여자가 다른 보안 주체에게 권한을 부여하도록 허용할 수 있습니다. + **태그 기반 액세스 제어** - 이 방법을 사용하면 데이터 카탈로그 데이터베이스, 테이블 및 열에 하나 이상의 LF 태그를 할당하고 보안 주체에 하나 이상의 LF 태그에 대한 권한을 부여할 수 있습니다. 각 LF 태그는 키-값 페어입니다(예: `department=sales`). 데이터 카탈로그 리소스의 LF 태그와 일치하는 LF 태그가 있는 보안 주체는 해당 리소스에 액세스할 수 있습니다. 이 방법은 데이터베이스와 테이블 수가 많은 데이터 레이크에 사용하는 것이 좋습니다. 이에 대해서는 [Lake Formation 태그 기반 액세스 제어](tag-based-access-control.md)에 자세하게 설명되어 있습니다. 보안 주체가 리소스에 대해 갖는 권한은 두 가지 방법에 의해 부여된 권한의 합입니다. 다음 테이블에는 데이터 카탈로그 리소스에 대해 사용 가능한 Lake Formation 권한이 요약되어 있습니다. 열 제목은 권한이 부여된 리소스를 나타냅니다. | 카탈로그 | Database | 표 | | --- | --- | --- | | CREATE\$1DATABASE | CREATE\$1TABLE | ALTER | | | ALTER | DROP | | | DROP | DESCRIBE | | | DESCRIBE | SELECT\$1 | | | | INSERT\$1 | | | | DELETE\$1 | 예를 들어, `CREATE_TABLE` 권한은 데이터베이스에 대해 부여됩니다. 즉, 보안 주체는 해당 데이터베이스에서 테이블을 생성할 수 있습니다. 별표(\$1)가 있는 권한은 데이터 카탈로그 리소스에 부여되지만 기본 데이터에도 적용됩니다. 예를 들어 메타데이터 테이블에 대해 `DROP` 권한이 부여되면 데이터 카탈로그에서 테이블을 삭제할 수 있습니다. 하지만 동일한 테이블에 `DELETE` 권한이 부여되면 Amazon S3에서 테이블의 기본 데이터를 삭제할 수 있습니다(예를 들어 SQL `DELETE` 문 사용). 이러한 권한이 있으면 Lake Formation 콘솔에서 테이블을 보고 AWS Glue API를 사용하여 테이블에 대한 정보를 검색할 수도 있습니다. 따라서, `SELECT`, `INSERT` 및 `DELETE`는 데이터 카탈로그 권한이자 데이터 액세스 권한입니다. 테이블에 대해 `SELECT` 권한을 부여할 때 하나 이상의 열을 포함하거나 제외하는 필터를 추가할 수 있습니다. 이를 통해 메타데이터 테이블 열에 대한 세분화된 액세스 제어가 가능하여 통합 서비스 사용자가 쿼리를 실행할 때 볼 수 있는 열을 제한할 수 있습니다. IAM 정책만으로는 이 기능을 사용할 수 없습니다. `Super`라는 이름의 특수 권한도 있습니다. `Super` 권한을 사용하면 보안 주체는 해당 권한이 부여된 데이터베이스 또는 테이블에서 지원되는 모든 Lake Formation 작업을 수행할 수 있습니다. 이 권한은 다른 Lake Formation 권한과 공존할 수 있습니다. 예를 들어 메타데이터 테이블에 대해 `Super`, `SELECT` 및 `INSERT` 권한을 부여할 수 있습니다. 보안 주체는 테이블에서 지원되는 모든 작업을 수행할 수 있으며 `Super` 권한을 취소해도 `SELECT` 및 `INSERT` 권한은 그대로 유지됩니다. 각 권한에 대한 자세한 내용은 [Lake Formation 권한 참조](lf-permissions-reference.md) 섹션을 참조하세요. **중요** 다른 사용자가 생성한 데이터 카탈로그 테이블을 보려면 해당 테이블에 대해 하나 이상의 Lake Formation 권한을 부여받아야 합니다. 테이블에 대해 하나 이상의 권한을 부여받은 경우 테이블이 속한 데이터베이스도 볼 수 있습니다. Lake Formation 콘솔, API 또는 AWS Command Line Interface (AWS CLI)를 사용하여 데이터 카탈로그 권한을 부여 또는 취소할 수 있습니다. 다음은 사용자에게 `retail` 데이터베이스에서 테이블을 생성할 수 있는 `datalake_user1` 권한을 부여하는 AWS CLI 명령의 예입니다. ``` aws lakeformation grant-permissions --principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:user/datalake_user1 --permissions "CREATE_TABLE" --resource '{ "Database": {"Name":"retail"}}' ``` 다음은 Lake Formation 권한으로 세분화된 액세스 제어를 보완하는 대략적인 액세스 제어 IAM 정책의 예입니다. 이것은 모든 메타데이터 데이터베이스 또는 테이블에 대한 모든 작업을 허용합니다. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "glue:*Database*", "glue:*Table*", "glue:*Partition*" ], "Resource": "*" } ] } ``` ------ 다음 예제도 대략적이지만 좀 더 제한적입니다. 이것은 지정된 계정 및 리전의 데이터 카탈로그에 있는 모든 메타데이터 데이터베이스 및 테이블에 대한 읽기 전용 작업을 허용합니다. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "glue:GetTables", "glue:SearchTables", "glue:GetTable", "glue:GetDatabase", "glue:GetDatabases" ], "Resource": "arn:aws:glue:us-east-1:111122223333:*" } ] } ``` ------ 이러한 정책을 IAM 기반의 세분화된 액세스 제어를 구현하는 다음 정책과 비교해 보세요. 이것은 지정된 계정 및 리전의 고객 관계 관리(CRM) 메타데이터 데이터베이스에 있는 테이블의 하위 집합에 대한 권한만 부여합니다. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "glue:GetTables", "glue:SearchTables", "glue:GetTable", "glue:GetDatabase", "glue:GetDatabases" ], "Resource": [ "arn:aws:glue:us-east-1:111122223333:catalog", "arn:aws:glue:us-east-1:111122223333:database/CRM", "arn:aws:glue:us-east-1:111122223333:table/CRM/P*" ] } ] } ``` ------ 대략적인 액세스 제어 정책의 추가적인 예는 [Lake Formation 페르소나 및 IAM 권한 참조](permissions-reference.md) 섹션을 참조하세요. # 기본 데이터 액세스 제어 통합 AWS 서비스가에서 액세스 제어하는 Amazon S3 위치의 데이터에 대한 액세스를 요청하면 AWS Lake Formation Lake Formation은 데이터에 액세스할 수 있는 임시 자격 증명을 제공합니다. Lake Formation이 Amazon S3 위치의 기본 데이터에 대한 액세스를 제어할 수 있도록 하려면 해당 위치를 Lake Formation에 등록해야 합니다.** Amazon S3 위치를 등록한 후에는 다음과 같은 Lake Formation 권한 부여를 시작할 수 있습니다. + 해당 위치를 가리키는 데이터 카탈로그 테이블에 대한 데이터 액세스 권한(`SELECT`, `INSERT` 및 `DELETE)`). + 해당 위치에 대한 데이터 위치 권한. Lake Formation 데이터 위치 권한은 특정 Amazon S3 위치를 가리키는 데이터 카탈로그 리소스를 생성하는 기능을 제어합니다. 데이터 위치 권한은 데이터 레이크 내의 위치에 대해 추가 보안 계층을 제공합니다. 보안 주체에 `CREATE_TABLE` 또는 `ALTER` 권한을 부여할 때 보안 주체가 메타데이터 테이블을 생성하거나 변경할 수 있는 위치를 제한하는 데이터 위치 권한도 부여합니다. Amazon S3 위치는 버킷 또는 버킷 아래의 접두사이지만 개별 Amazon S3 객체는 아닙니다. Lake Formation 콘솔, API 또는 AWS CLI를 사용하여 보안 주체에 데이터 위치 권한을 부여할 수 있습니다. 일반적인 권한 부여 형식은 다음과 같습니다. ``` grant DATA_LOCATION_ACCESS to principal on S3 location [with grant option] ``` `with grant option`을 포함하면 부여자가 다른 보안 주체에게 권한을 부여할 수 있습니다. Lake Formation 권한은 항상 세분화된 액세스 제어를 위한 AWS Identity and Access Management (IAM) 권한과 함께 작동합니다. 기본 Amazon S3 데이터에 대한 읽기/쓰기 권한의 경우 다음과 같이 IAM 권한이 부여됩니다. 위치를 등록할 때 해당 위치에 대한 읽기/쓰기 권한을 부여하는 IAM 역할을 지정합니다. Lake Formation은 통합 AWS 서비스에 임시 자격 증명을 제공할 때 해당 역할을 수임합니다. 일반적인 역할에는 다음과 같은 정책이 연결되어 있을 수 있습니다. 여기서 등록된 위치는 버킷 `awsexamplebucket`입니다. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:PutObject", "s3:GetObject", "s3:DeleteObject" ], "Resource": [ "arn:aws:s3:::amzn-s3-demo-bucket/*" ] }, { "Effect": "Allow", "Action": [ "s3:ListBucket" ], "Resource": [ "arn:aws:s3:::amzn-s3-demo-bucket" ] } ] } ``` ------ Lake Formation은 등록 중에 이와 같은 정책을 자동으로 생성하는 데 사용할 수 있는 서비스 연결 역할을 제공합니다. 자세한 내용은 [Lake Formation에 서비스 연결 역할 사용](service-linked-roles.md) 단원을 참조하십시오. 따라서 Amazon S3 위치를 등록하면 해당 위치에 필요한 IAM `s3:` 권한이 부여되며, 여기서 권한은 위치를 등록하는 데 사용된 역할에 따라 지정됩니다. **중요** **요청자 지불**이 활성화된 Amazon S3 버킷은 등록하지 마세요. Lake Formation에 등록된 버킷의 경우 버킷 등록에 사용된 역할은 항상 요청자로 표시됩니다. 다른 AWS 계정에서 버킷에 액세스하는 경우 역할이 버킷 소유자와 동일한 계정에 속하는 경우 버킷 소유자에게 데이터 액세스 요금이 부과됩니다. 기본 데이터에 대한 읽기/쓰기 액세스를 위해 보안 주체는 Lake Formation 권한 외에도 `lakeformation:GetDataAccess` IAM 권한이 필요합니다. 이 권한을 통해 Lake Formation은 데이터에 액세스하기 위한 임시 보안 인증 요청을 승인합니다. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "lakeformation:GetDataAccess", "Resource": "*" } ] } ``` ------ 위의 정책에서는 리소스 파라미터를 '\$1'로 설정해야 합니다. 이 권한에 다른 리소스를 지정하는 것은 지원되지 않습니다. 이 구성을 통해 Lake Formation은 전체 데이터 레이크 환경에서 데이터 액세스를 효율적으로 관리할 수 있습니다. **참고** Amazon Athena에서는 사용자에게 `lakeformation:GetDataAccess` 권한을 요구합니다. 다른 통합 서비스에서는 기본 실행 역할에 `lakeformation:GetDataAccess` 권한이 있어야 합니다. 이 권한은 [Lake Formation 페르소나 및 IAM 권한 참조](permissions-reference.md)의 제안 정책에 포함되어 있습니다. 요약하자면, Lake Formation 보안 주체가 Lake Formation 권한으로 제어되는 액세스를 사용하여 기본 데이터를 읽고 쓸 수 있도록 하려면 다음을 수행합니다. + 데이터가 들어 있는 Amazon S3 위치를 Lake Formation에 등록합니다. + 기본 데이터 위치를 가리키는 데이터 카탈로그 테이블을 생성하는 보안 주체는 데이터 위치 권한이 있어야 합니다. + 기본 데이터를 읽고 쓰는 보안 주체는 기본 데이터 위치를 가리키는 데이터 카탈로그 테이블에 대한 Lake Formation 데이터 액세스 권한이 있어야 합니다. + 기본 데이터를 읽고 쓰는 보안 주체는 기본 데이터 위치가 Lake Formation에 등록된 경우 `lakeformation:GetDataAccess` IAM 권한이 있어야 합니다. **참고** Lake Formation 권한 모델은 IAM 또는 Amazon S3 정책을 통해 Amazon S3 위치에 액세스할 수 있는 경우 Amazon S3 API 또는 콘솔을 통한 Amazon S3 위치 액세스를 차단하지 않습니다. IAM 정책을 보안 주체에 연결하여 이러한 액세스를 차단할 수 있습니다. **데이터 위치 권한에 대한 자세한 내용** 데이터 위치 권한은 데이터 카탈로그 데이터베이스 및 테이블에 대한 생성 및 업데이트 작업의 결과를 제어합니다. 규칙은 다음과 같습니다. + 보안 주체가 Amazon S3 위치에 대한 명시적 또는 암시적 데이터 위치 권한을 가지고 있어야 해당 위치를 지정하는 데이터베이스 또는 테이블을 생성하거나 업데이트할 수 있습니다. + 명시적 권한은 콘솔, API 또는를 사용하여 부여`DATA_LOCATION_ACCESS`됩니다 AWS CLI. + 암시적 권한은 데이터베이스에 등록된 위치를 가리키는 위치 속성이 있고, 보안 주체가 데이터베이스에 대한 `CREATE_TABLE` 권한을 가지고 있으며, 보안 주체가 해당 위치나 하위 위치에 테이블을 생성하려고 할 때 부여됩니다. + 보안 주체에게 특정 위치에 대한 데이터 위치 권한이 부여된 경우 보안 주체는 모든 하위 위치에 대한 데이터 위치 권한을 가집니다. + 보안 주체는 기본 데이터에 대한 읽기/쓰기 작업을 수행하는 데 데이터 위치 권한이 필요하지 않습니다. `SELECT` 또는 `INSERT` 데이터 액세스 권한만 있으면 충분합니다. 데이터 위치 권한은 해당 위치를 가리키는 데이터 카탈로그 리소스를 생성하는 데만 적용됩니다. 다음 다이어그램에 표시된 시나리오를 고려하세요. ![\[폴더 계층 구조와 두 개의 데이터베이스(데이터베이스 A와 B)가 있으며 데이터베이스 B는 고객 서비스 폴더를 가리키고 있습니다.\]](http://docs.aws.amazon.com/ko_kr/lake-formation/latest/dg/images/location-permissions-example.png) 이 다이어그램에서: + Amazon S3 버킷 `Products`, `Finance` 및 `Customer Service`가 Lake Formation에 등록되어 있습니다. + `Database A`에는 위치 속성이 없으며 `Database B`에는 `Customer Service` 버킷을 가리키는 위치 속성이 있습니다. + 사용자 `datalake_user`에게는 두 데이터베이스 모두에 대한 `CREATE_TABLE` 권한이 있습니다. + 사용자 `datalake_user`에게는 `Products` 버킷에 대한 데이터 위치 권한만 부여되었습니다. 다음은 사용자 `datalake_user`가 특정 위치의 특정 데이터베이스에 카탈로그 테이블을 생성하려고 할 때의 결과입니다. **`datalake_user`가 테이블을 생성하려는 위치** | 데이터베이스 및 위치 | 성공 또는 실패 | 이유 | | --- | --- | --- | | 데이터베이스 A(Finance/Sales) | 실패 | 데이터 위치 권한 없음 | | 데이터베이스 A(Products) | 성공 | 데이터 위치 권한 있음 | | 데이터베이스 A(HR/Plans) | 성공 | 위치가 등록되지 않음 | | 데이터베이스 B(Customer Service/Incidents) | 성공 | Customer Service에 데이터베이스의 위치 속성이 있음 | 자세한 내용은 다음을 참조하세요. + [데이터 레이크에 Amazon S3 위치 추가](register-data-lake.md) + [Lake Formation 권한 참조](lf-permissions-reference.md) + [Lake Formation 페르소나 및 IAM 권한 참조](permissions-reference.md) # Lake Formation 페르소나 및 IAM 권한 참조 이 섹션에는 몇 가지 제안된 Lake Formation 페르소나와 제안된 AWS Identity and Access Management (IAM) 권한이 나열되어 있습니다. Lake Formation 권한에 대한 자세한 내용은 [Lake Formation 권한 참조](lf-permissions-reference.md) 섹션을 참조하세요. ## AWS Lake Formation 페르소나 다음 표에는 제안된 AWS Lake Formation 페르소나가 나열되어 있습니다. **Lake Formation 페르소나** | 페르소나 | 설명 | | --- | --- | | IAM 관리자(슈퍼 사용자) | (필수) IAM 사용자 및 역할을 생성할 수 있는 사용자입니다. AdministratorAccess AWS 관리형 정책이 있습니다. 모든 Lake Formation 리소스에 대한 모든 권한을 가집니다. 데이터 레이크 관리자를 추가할 수 있습니다. 데이터 레이크 관리자로 지정되지 않은 경우 Lake Formation 권한을 부여할 수 없습니다. | | 데이터 레이크 관리자 | (필수) Amazon S3 위치를 등록하고, 데이터 카탈로그에 액세스하고, 데이터베이스를 생성하고, 워크플로를 생성 및 실행하고, Lake Formation 권한을 다른 사용자에게 부여하고, AWS CloudTrail 로그를 볼 수 있는 사용자입니다. IAM 관리자보다 IAM 권한이 적지만 데이터 레이크를 관리하기에는 충분합니다. 다른 데이터 레이크 관리자를 추가할 수 없습니다. | | 읽기 전용 관리자 | (선택 사항) 업데이트 권한 없이 보안 주체, 데이터 카탈로그 리소스, 권한 및 AWS CloudTrail 로그를 볼 수 있는 사용자입니다. | | 데이터 엔지니어 | (선택 사항) 데이터베이스를 생성하고, 크롤러와 워크플로를 생성 및 실행하고, 크롤러와 워크플로가 생성하는 데이터 카탈로그 테이블에 대한 Lake Formation 권한을 부여할 수 있는 사용자입니다. 모든 데이터 엔지니어를 데이터베이스 생성자로 지정하는 것이 좋습니다. 자세한 내용은 [데이터베이스 생성](creating-database.md) 단원을 참조하십시오. | | 데이터 분석가 | (선택 사항) 예를 들어 Amazon Athena를 사용하여 데이터 레이크에 대해 쿼리를 실행할 수 있는 사용자입니다. 쿼리를 실행할 수 있는 권한만 있습니다. | | 워크플로 역할 | (필수) 사용자를 대신하여 워크플로를 실행하는 역할입니다. 이 역할은 청사진에서 워크플로를 생성할 때 지정합니다. | **참고** Lake Formation에서 데이터베이스 생성 후 추가된 데이터 레이크 관리자는 권한을 부여할 수 있지만, SELECT 또는 DESCRIBE와 같은 데이터 액세스 권한은 자동으로 보유하지 않습니다. 데이터베이스를 생성하는 관리자는 해당 데이터베이스에 대한 `SUPER` 권한을 받습니다. 이 동작은 의도적인 것입니다. 모든 관리자가 자신에게 필요한 권한을 부여할 수 있지만, 이러한 권한은 기존 리소스에 자동으로 적용되지 않습니다. 따라서 관리자는 관리자 권한이 할당되기 전에 존재했던 데이터베이스에 대한 액세스 권한을 명시적으로 부여해야 합니다. ## AWS Lake Formation에 대한 관리형 정책 AWS 관리형 정책 및 인라인 정책을 AWS Lake Formation 사용하여 작업에 필요한 AWS Identity and Access Management (IAM) 권한을 부여할 수 있습니다. Lake Formation에는 다음과 같은 AWS 관리형 정책을 사용할 수 있습니다. ### AWS 관리형 정책:AWSLakeFormationDataAdmin [AWSLakeFormationDataAdmin](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AWSLakeFormationDataAdmin) 정책은 데이터 레이크를 관리하기 위해 AWS Lake Formation 및와 같은 관련 서비스에 AWS Glue 대한 관리 액세스 권한을 부여합니다. 사용자, 그룹 및 역할에 `AWSLakeFormationDataAdmin`를 연결할 수 있습니다. **권한 세부 정보** + `CloudTrail` - 보안 주체가 AWS CloudTrail 로그를 볼 수 있도록 허용합니다. 이 권한은 데이터 레이크 설정 시 발생한 오류를 검토하는 데 필요합니다. + `Glue` - 보안 주체가 데이터 카탈로그의 메타데이터 테이블 및 데이터베이스를 보고, 생성하고, 업데이트할 수 있도록 허용합니다. 여기에는 `Get`, `List`, `Create`, `Update`, `Delete` 및 `Search`로 시작하는 API 작업이 포함됩니다. 이 권한은 데이터 레이크 테이블의 메타데이터를 관리하는 데 필요합니다. + `IAM` - 보안 주체가 IAM 사용자, 역할 및 역할에 연결된 정책에 대한 정보를 검색할 수 있도록 허용합니다. 이 권한은 데이터 관리자가 Lake Formation 권한을 부여할 IAM 사용자 및 역할을 검토하고 나열하는 데 필요합니다. + `Lake Formation` - 데이터 레이크 관리자에게 데이터 레이크를 관리하는 데 필요한 Lake Formation 권한을 부여합니다. + `S3` - 보안 주체가 데이터 레이크의 데이터 위치를 설정하기 위해 Amazon S3 버킷 및 해당 위치에 대한 정보를 검색할 수 있도록 허용합니다. ``` "Statement": [ { "Sid": "AWSLakeFormationDataAdminAllow", "Effect": "Allow", "Action": [ "lakeformation:*", "cloudtrail:DescribeTrails", "cloudtrail:LookupEvents", "glue:CreateCatalog", "glue:UpdateCatalog", "glue:DeleteCatalog", "glue:GetCatalog", "glue:GetCatalogs", "glue:GetDatabase", "glue:GetDatabases", "glue:CreateDatabase", "glue:UpdateDatabase", "glue:DeleteDatabase", "glue:GetConnections", "glue:SearchTables", "glue:GetTable", "glue:CreateTable", "glue:UpdateTable", "glue:DeleteTable", "glue:GetTableVersions", "glue:GetPartitions", "glue:GetTables", "glue:ListWorkflows", "glue:BatchGetWorkflows", "glue:DeleteWorkflow", "glue:GetWorkflowRuns", "glue:StartWorkflowRun", "glue:GetWorkflow", "s3:ListBucket", "s3:GetBucketLocation", "s3:ListAllMyBuckets", "s3:GetBucketAcl", "iam:ListUsers", "iam:ListRoles", "iam:GetRole", "iam:GetRolePolicy" ], "Resource": "*" }, { "Sid": "AWSLakeFormationDataAdminDeny", "Effect": "Deny", "Action": [ "lakeformation:PutDataLakeSettings" ], "Resource": "*" } ] } ``` **참고** `AWSLakeFormationDataAdmin` 정책은 데이터 레이크 관리자에게 필요한 모든 권한을 부여하지는 않습니다. 워크플로를 생성 및 실행하고 서비스 연결 역할 `AWSServiceRoleForLakeFormationDataAccess`에 위치를 등록하려면 추가 권한이 필요합니다. 자세한 내용은 [데이터 레이크 관리자 생성](initial-lf-config.md#create-data-lake-admin) 및 [Lake Formation에 서비스 연결 역할 사용](service-linked-roles.md) 섹션을 참조하세요. ### AWS 관리형 정책:AWSLakeFormationCrossAccountManager [AWSLakeFormationCrossAccountManager](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AWSLakeFormationCrossAccountManager) 정책은 Lake Formation을 통해 AWS Glue 리소스에 대한 교차 계정 액세스 권한을 제공하고 AWS Organizations 및 같은 다른 필수 서비스에 대한 읽기 액세스 권한을 부여합니다 AWS RAM. 사용자, 그룹 및 역할에 `AWSLakeFormationCrossAccountManager`를 연결할 수 있습니다. **권한 세부 정보** 이 정책에는 다음 권한이 포함되어 있습니다. + `Glue` - 보안 주체가 액세스 제어를 위한 데이터 카탈로그 리소스 정책을 설정하거나 삭제할 수 있도록 허용합니다. + `Organizations` - 보안 주체가 조직의 계정 및 OU(조직 구성 단위) 정보를 검색할 수 있도록 허용합니다. + `ram:CreateResourceShare` - 보안 주체가 리소스 공유를 생성할 수 있도록 허용합니다. + `ram:UpdateResourceShare` - 보안 주체가 지정된 리소스 공유의 일부 속성을 수정할 수 있도록 허용합니다. + `ram:DeleteResourceShare` - 보안 주체가 지정된 리소스 공유를 삭제할 수 있도록 허용합니다. + `ram:AssociateResourceShare` - 보안 주체가 지정된 보안 주체 목록 및 리소스 목록을 리소스 공유에 추가할 수 있도록 허용합니다. + `ram:DisassociateResourceShare` - 보안 주체가 지정된 리소스 공유에 참여하지 않도록 지정된 보안 주체 또는 리소스를 제거할 수 있도록 허용합니다. + `ram:GetResourceShares` - 사용자가 소유하거나 공유한 리소스 공유에 대한 세부 정보를 보안 주체가 검색할 수 있도록 허용합니다. + `ram:RequestedResourceType` - 보안 주체가 리소스 유형(데이터베이스, 테이블 또는 카탈로그)을 검색할 수 있도록 허용합니다. + `AssociateResourceSharePermission` - 보안 주체가 리소스 공유에 포함된 리소스 유형에 대한 AWS RAM 권한을 추가하거나 교체할 수 있습니다. 리소스 공유에 포함된 각 리소스 유형에는 하나의 권한만 연결할 수 있습니다. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [{ "Sid": "AllowCreateResourceShare", "Effect": "Allow", "Action": [ "ram:CreateResourceShare" ], "Resource": "*", "Condition": { "StringLikeIfExists": { "ram:RequestedResourceType": [ "glue:Table", "glue:Database", "glue:Catalog" ] } } }, { "Sid": "AllowManageResourceShare", "Effect": "Allow", "Action": [ "ram:UpdateResourceShare", "ram:DeleteResourceShare", "ram:AssociateResourceShare", "ram:DisassociateResourceShare", "ram:GetResourceShares" ], "Resource": "*", "Condition": { "StringLike": { "ram:ResourceShareName": [ "LakeFormation*" ] } } }, { "Sid": "AllowManageResourceSharePermissions", "Effect": "Allow", "Action": [ "ram:AssociateResourceSharePermission" ], "Resource": "*", "Condition": { "ArnLike": { "ram:PermissionArn": [ "arn:aws:ram::aws:permission/AWSRAMLFEnabled*" ] } } }, { "Sid": "AllowXAcctManagerPermissions", "Effect": "Allow", "Action": [ "glue:PutResourcePolicy", "glue:DeleteResourcePolicy", "organizations:DescribeOrganization", "organizations:DescribeAccount", "ram:Get*", "ram:List*" ], "Resource": "*" }, { "Sid": "AllowOrganizationsPermissions", "Effect": "Allow", "Action": [ "organizations:ListRoots", "organizations:ListAccountsForParent", "organizations:ListOrganizationalUnitsForParent" ], "Resource": "*" } ] } ``` ------ ### AWS 관리형 정책:AWSGlueConsoleFullAccess [AWSGlueConsoleFullAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AWSGlueConsoleFullAccess) 정책은 정책이 연결된 자격 증명이를 사용할 때 AWS Glue 리소스에 대한 전체 액세스 권한을 부여합니다 AWS Management Console. 이 정책에 지정된 리소스의 이름 변환을 따르면 사용자는 콘솔 전체 용량을 소유합니다. 이 정책은 일반적으로 AWS Glue 콘솔 사용자에게 연결됩니다. 또한, AWS Glue 및 Lake Formation은 서비스 역할 `AWSGlueServiceRole`을 맡아 Amazon Elastic Compute Cloud(Amazon EC2), Amazon Simple Storage Service(S3) 및 Amazon CloudWatch를 비롯한 관련 서비스에 대한 액세스를 허용합니다. ### AWS managed policy:LakeFormationDataAccessServiceRolePolicy 이 정책은 서비스에서 요청 시 리소스에 대한 작업을 수행할 수 있도록 `ServiceRoleForLakeFormationDataAccess` 서비스 연결 역할에 연결됩니다. 이 정책을 IAM 자격 증명에 연결할 수 없습니다. 이 정책은 Amazon Athena 또는 Amazon Redshift와 같은 Lake Formation 통합 AWS 서비스가 서비스 연결 역할을 사용하여 Amazon S3 리소스를 검색하도록 허용합니다. 자세한 내용은 단원을 참조하십시오[Lake Formation에 서비스 연결 역할 사용](service-linked-roles.md). **권한 세부 정보** 이 정책에는 다음 권한이 포함되어 있습니다. + `s3:ListAllMyBuckets` – 요청의 인증된 발신자가 소유한 모든 버킷의 목록을 반환합니다. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "LakeFormationDataAccessServiceRolePolicy", "Effect": "Allow", "Action": [ "s3:ListAllMyBuckets" ], "Resource": [ "arn:aws:s3:::*" ] } ] } ``` ------ **AWS 관리형 정책에 대한 Lake Formation 업데이트** 이 서비스가 이러한 변경 사항을 추적하기 시작한 이후부터 Lake Formation의 AWS 관리형 정책 업데이트에 대한 세부 정보를 봅니다. | 변경 | 설명 | Date | | --- | --- | --- | | Lake Formation에서 AWSLakeFormationCrossAccountManager 정책을 업데이트함. | Lake Formation은 StringLike 조건 연산자를 IAM이 ARN 형식 확인을 수행할 수 있는 ArnLike 연산자로 대체하여 [AWSLakeFormationCrossAccountManager](https://us-east-1.console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AWSLakeFormationCrossAccountManager) 정책을 개선했습니다. | 2025년 1월 | | Lake Formation에서 AWSLakeFormationDataAdmin 정책을 업데이트함. | Lake Formation은 다중 카탈로그 기능의 일부로 다음 AWS Glue Data Catalog CRUD API를 추가하여 [AWSLakeFormationDataAdmin](https://us-east-1.console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AWSLakeFormationDataAdmin) 정책을 개선했습니다.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/lake-formation/latest/dg/permissions-reference.html)이 관리형 정책 변경은 기본적으로 Lake Formation 관리자 페르소나가 이러한 새 작업에 대한 IAM 권한을 갖도록 하기 위한 것입니다. | 2024년 12월 | | Lake Formation에서 AWSLakeFormationCrossAccountManager 정책을 업데이트함. | Lake Formation은 정책 문에 Sid 요소를 추가하여 [AWSLakeFormationCrossAccountManager](https://us-east-1.console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AWSLakeFormationCrossAccountManager) 정책을 향상했습니다. | 2024년 3월 | | Lake Formation에서 AWSLakeFormationDataAdmin 정책을 업데이트함. | Lake Formation은 정책 문에 Sid 요소를 추가하고 중복 작업을 제거하여 [AWSLakeFormationDataAdmin](https://us-east-1.console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AWSLakeFormationDataAdmin) 정책을 향상했습니다. | 2024년 3월 | | Lake Formation에서 LakeFormationDataAccessServiceRolePolicy 정책을 업데이트함. | Lake Formation은 정책 문에 Sid 요소를 추가하여 [LakeFormationDataAccessServiceRolePolicy](https://us-east-1.console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/LakeFormationDataAccessServiceRolePolicy) 정책을 향상했습니다. | 2024년 2월 | | Lake Formation에서 AWSLakeFormationCrossAccountManager 정책을 업데이트함. | Lake Formation은 하이브리드 액세스 모드에서 교차 계정 데이터 공유를 활성화하는 새로운 권한을 추가하여 [AWSLakeFormationCrossAccountManager](https://us-east-1.console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AWSLakeFormationCrossAccountManager) 정책을 개선했습니다. | 2023년 10월 | | Lake Formation에서 AWSLakeFormationCrossAccountManager 정책을 업데이트함. | Lake Formation은 [AWSlakeFormationCrossAccountManager](https://us-east-1.console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AWSLakeFormationCrossAccountManager) 정책을 개선하여 리소스를 처음 공유할 때 수신자 계정당 하나의 리소스 공유만 생성하도록 했습니다. 이후 동일한 계정으로 공유된 모든 리소스는 동일한 리소스 공유에 연결됩니다. | 2022년 5월 6일 | | Lake Formation에서 변경 내용 추적 시작. | Lake Formation은 AWS 관리형 정책에 대한 변경 사항 추적을 시작했습니다. | 2022년 5월 6일 | ## 페르소나 제안 권한 다음은 각 페르소나에 대해 제안된 권한입니다. IAM 관리자는 포함되지 않습니다. 해당 사용자는 모든 리소스에 대한 모든 권한을 가지고 있기 때문입니다. **Topics** + [데이터 레이크 관리자 권한](#persona-dl-admin) + [읽기 전용 관리자 권한](#persona-read-only-admin) + [데이터 엔지니어 권한](#persona-engineer) + [데이터 분석가 권한](#persona-user) + [워크플로 역할 권한](#persona-workflow-role) ### 데이터 레이크 관리자 권한 **중요** 다음 정책에서에 정의된 대로 **를 유효한 AWS 계정 번호로 바꾸고 **을 워크플로를 실행할 권한이 있는 역할의 이름으로 바꿉니다[워크플로 역할 권한](#persona-workflow-role). | 정책 유형 | 정책 | | --- | --- | | AWS 관리형 정책 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/lake-formation/latest/dg/permissions-reference.html) 선택적 AWS 관리형 정책에 대한 자세한 내용은 섹션을 참조하세요[데이터 레이크 관리자 생성](initial-lf-config.md#create-data-lake-admin). | | 인라인 정책(Lake Formation 서비스 연결 역할 생성용) | 
{
    "Version": "2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "iam:CreateServiceLinkedRole",
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "iam:AWSServiceName": "lakeformation.amazonaws.com"
                }
            }
        },
        {
            "Effect": "Allow",
            "Action": [
                "iam:PutRolePolicy"
            ],
            "Resource": "arn:aws:iam:::role/aws-service-role/lakeformation.amazonaws.com/AWSServiceRoleForLakeFormationDataAccess"
        }
    ]
}
| | (선택 사항) 인라인 정책(워크플로 역할에 대한 passrole 정책). 이는 데이터 레이크 관리자가 워크플로를 생성하고 실행하는 경우에만 필요합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/lake-formation/latest/dg/permissions-reference.html) | | (선택 사항) 인라인 정책(계정이 교차 계정 Lake Formation 권한을 부여하거나 받는 경우). 이 정책은 AWS RAM 리소스 공유 초대를 수락 또는 거부하고 조직에 교차 계정 권한을 부여하기 위한 것입니다. ram:EnableSharingWithAwsOrganization는 관리 계정의 데이터 레이크 관리자에게 AWS Organizations 만 필요합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/lake-formation/latest/dg/permissions-reference.html) | ### 읽기 전용 관리자 권한 | 정책 유형 | 정책 | | --- | --- | | 인라인 정책(기본) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/lake-formation/latest/dg/permissions-reference.html) | ### 데이터 엔지니어 권한 **중요** 다음 정책에서 **를 유효한 AWS 계정 번호로 바꾸고 **을 워크플로 역할 이름으로 바꿉니다. | 정책 유형 | 정책 | | --- | --- | | AWS 관리형 정책 | AWSGlueConsoleFullAccess | | 인라인 정책(기본) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/lake-formation/latest/dg/permissions-reference.html) | | 인라인 정책(트랜잭션 내 작업을 포함하여 관리되는 테이블에 대한 작업용) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/lake-formation/latest/dg/permissions-reference.html) | | 인라인 정책(Lake Formation 태그 기반 액세스 제어(LF-TBAC) 방법을 사용한 메타데이터 액세스 제어용) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/lake-formation/latest/dg/permissions-reference.html) | | 인라인 정책(워크플로 역할에 대한 passrole 정책) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/lake-formation/latest/dg/permissions-reference.html) | ### 데이터 분석가 권한 | 정책 유형 | 정책 | | --- | --- | | AWS 관리형 정책 | AmazonAthenaFullAccess | | 인라인 정책(기본) | 
{
    "Version": "2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "lakeformation:GetDataAccess",
                "glue:GetTable",
                "glue:GetTables",
                "glue:SearchTables",
                "glue:GetDatabase",
                "glue:GetDatabases",
                "glue:GetPartitions",
                "lakeformation:GetResourceLFTags",
                "lakeformation:ListLFTags",
                "lakeformation:GetLFTag",
                "lakeformation:SearchTablesByLFTags",
                "lakeformation:SearchDatabasesByLFTags"                
           ],
            "Resource": "*"
        }
    ]
}
| | (선택 사항) 인라인 정책(트랜잭션 내 작업을 포함하여 관리되는 테이블에 대한 작업용) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/lake-formation/latest/dg/permissions-reference.html) | ### 워크플로 역할 권한 이 역할에는 워크플로를 실행하는 데 필요한 권한이 있습니다. 워크플로를 생성할 때 이러한 권한이 있는 역할을 지정합니다. **중요** 다음 정책에서 **을 유효한 AWS 리전 식별자(예: `us-east-1`), **를 유효한 AWS 계정 번호로, **을 워크플로 역할 이름으로, **을 AWS CloudTrail 로그의 Amazon S3 경로로 바꿉니다. | 정책 유형 | 정책 | | --- | --- | | AWS 관리형 정책 | AWSGlueServiceRole | | 인라인 정책(데이터 액세스) | 
{
    "Version": "2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "Lakeformation",
            "Effect": "Allow",
            "Action": [
                 "lakeformation:GetDataAccess",
                 "lakeformation:GrantPermissions"
             ],
            "Resource": "*"
        }
    ]
}
| | 인라인 정책(워크플로 역할에 대한 passrole 정책) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/lake-formation/latest/dg/permissions-reference.html) | | 인라인 정책(예: AWS CloudTrail 로그) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/lake-formation/latest/dg/permissions-reference.html) | # 데이터 레이크의 기본 설정 변경 와의 이전 버전과의 호환성을 유지하기 위해 AWS Glue AWS Lake Formation 에는 다음과 같은 초기 보안 설정이 있습니다. + 그룹 `IAMAllowedPrincipals`에 모든 기존 AWS Glue 데이터 카탈로그 리소스에 대한 `Super` 권한이 부여됩니다. + 새 데이터 카탈로그 리소스에 대해 'IAM 액세스 제어만 사용' 설정이 활성화됩니다. 이러한 설정을 사용하면 데이터 카탈로그 리소스 및 Amazon S3 위치에 대한 액세스가 AWS Identity and Access Management (IAM) 정책에 의해서만 제어됩니다. 개별 Lake Formation 권한은 유효하지 않습니다. `IAMAllowedPrincipals` 그룹에는 IAM 정책에 따라 데이터 카탈로그 리소스에 대한 액세스가 허용된 모든 IAM 사용자 및 역할이 포함됩니다. `Super` 권한을 사용하면 보안 주체는 해당 권한이 부여된 데이터베이스 또는 테이블에서 지원되는 모든 Lake Formation 작업을 수행할 수 있습니다. Lake Formation 권한으로 데이터 카탈로그 리소스(데이터베이스 및 테이블)에 대한 액세스가 관리되도록 보안 설정을 변경하려면 다음을 수행합니다. 1. 새 리소스의 기본 보안 설정을 변경합니다. 지침은 [기본 권한 모델 변경 또는 하이브리드 액세스 모드 사용](initial-lf-config.md#setup-change-cat-settings) 섹션을 참조하세요. 1. 기존 데이터 카탈로그 리소스의 설정을 변경합니다. 지침은 [AWS Lake Formation 모델로 AWS Glue 데이터 권한 업그레이드](upgrade-glue-lake-formation.md) 섹션을 참조하세요. **Lake Formation `PutDataLakeSettings` API 작업을 사용하여 기본 보안 설정 변경** Lake Formation [PutDataLakeSettings](https://docs.aws.amazon.com/lake-formation/latest/APIReference/API_PutDataLakeSettings.html) API 작업을 사용하여 기본 보안 설정을 변경할 수도 있습니다. 이 작업은 선택적 카탈로그 ID 및 [DataLakeSettings](https://docs.aws.amazon.com/lake-formation/latest/APIReference/API_DataLakeSettings.html) 구조를 인수로 사용합니다. 새 데이터베이스 및 테이블에서 Lake Formation을 통해 메타데이터 및 기본 데이터 액세스 제어를 적용하려면 `DataLakeSettings` 구조를 다음과 같이 코딩합니다. **참고** **를 유효한 AWS 계정 ID로 바꾸고 **을 유효한 IAM 사용자 이름으로 바꿉니다. 둘 이상의 사용자를 데이터 레이크 관리자로 지정할 수 있습니다. ``` { "DataLakeSettings": { "DataLakeAdmins": [ { "DataLakePrincipalIdentifier": "arn:aws:iam:::user/" } ], "CreateDatabaseDefaultPermissions": [], "CreateTableDefaultPermissions": [] } } ``` 다음과 같이 구조를 코딩할 수도 있습니다. `CreateDatabaseDefaultPermissions` 또는 `CreateTableDefaultPermissions` 파라미터를 생략하는 것은 빈 목록을 전달하는 것과 같습니다. ``` { "DataLakeSettings": { "DataLakeAdmins": [ { "DataLakePrincipalIdentifier": "arn:aws:iam:::user/" } ] } } ``` 이 작업은 새 데이터베이스 및 테이블에 대한 `IAMAllowedPrincipals` 그룹의 모든 Lake Formation 권한을 효과적으로 취소합니다. 데이터베이스를 생성할 때 이 설정을 재정의할 수 있습니다. 새 데이터베이스 및 테이블에서 IAM을 통해서만 메타데이터 및 기본 데이터 액세스 제어를 적용하려면 다음과 같이 `DataLakeSettings` 구조를 코딩합니다. ``` { "DataLakeSettings": { "DataLakeAdmins": [ { "DataLakePrincipalIdentifier": "arn:aws:iam:::user/" } ], "CreateDatabaseDefaultPermissions": [ { "Principal": { "DataLakePrincipalIdentifier": "IAM_ALLOWED_PRINCIPALS" }, "Permissions": [ "ALL" ] } ], "CreateTableDefaultPermissions": [ { "Principal": { "DataLakePrincipalIdentifier": "IAM_ALLOWED_PRINCIPALS" }, "Permissions": [ "ALL" ] } ] } } ``` 이렇게 하면 새 데이터베이스 및 테이블에 대한 `Super` Lake Formation 권한이 `IAMAllowedPrincipals` 그룹에 부여됩니다. 데이터베이스를 생성할 때 이 설정을 재정의할 수 있습니다. **참고** 앞의 `DataLakeSettings` 구조에서 `DataLakePrincipalIdentifier`에 허용되는 유일한 값은 `IAM_ALLOWED_PRINCIPALS`이고, `Permissions`에 허용되는 유일한 값은 `ALL`입니다. # 암시적 Lake Formation 권한 AWS Lake Formation 는 데이터 레이크 관리자, 데이터베이스 생성자 및 테이블 생성자에게 다음과 같은 암시적 권한을 부여합니다. **데이터 레이크 관리자** + 다른 계정에서 다른 보안 주체와 직접 공유하는 리소스를 제외하고 데이터 카탈로그의 모든 리소스에 대한 `Describe` 액세스 권한이 있습니다. 관리자는 이 액세스 권한을 취소할 수 없습니다. + 데이터 레이크의 모든 곳에 데이터 위치 권한이 있습니다. + 데이터 카탈로그의 모든 리소스에 대한 액세스 권한을 모든 보안 주체(자신 포함)에게 부여하거나 취소할 수 있습니다. 관리자는 이 액세스 권한을 취소할 수 없습니다. + 데이터 카탈로그에서 데이터베이스를 생성할 수 있습니다. + 다른 사용자에게 데이터베이스 생성 권한을 부여할 수 있습니다. 데이터 레이크 관리자는 해당하는 IAM 권한이 있는 경우에만 Amazon S3 위치를 등록할 수 있습니다. 이 안내서에서 제안하는 데이터 레이크 관리자 정책은 이러한 권한을 부여합니다. 또한 데이터 레이크 관리자에게는 데이터베이스를 삭제하거나 다른 사람이 생성한 테이블을 변경/삭제할 수 있는 암시적인 권한이 없습니다. 하지만 자신에게 그러한 권한을 부여할 수는 있습니다. 데이터 레이크 관리자에 대한 자세한 내용은 [데이터 레이크 관리자 생성](initial-lf-config.md#create-data-lake-admin) 섹션을 참조하세요. **카탈로그 생성자** + 생성하는 카탈로그에 대한 모든 카탈로그 권한이 있고, 카탈로그에서 생성하는 데이터베이스 및 테이블에 대한 권한이 있으며, 동일한 AWS 계정의 다른 보안 주체에게 카탈로그에서 데이터베이스 및 테이블을 생성할 수 있는 권한을 부여할 수 있습니다. `AWSLakeFormationCrossAccountManager` AWS 관리형 정책도 보유한 카탈로그 생성자는 카탈로그에 대한 권한을 다른 AWS 계정 또는 조직에 부여할 수 있습니다. 데이터 레이크 관리자는 Lake Formation 콘솔 또는 API를 사용하여 카탈로그 생성자를 지정할 수 있습니다. **참고** 카탈로그 생성자는 다른 사람이 카탈로그에서 생성하는 데이터베이스 및 테이블에 대한 권한을 암시적으로 가지지 않습니다. 카탈로그 생성 방법에 대한 자세한 내용은 [로 데이터 가져오기 AWS Glue Data Catalog](bring-your-data-overview.md) 섹션을 참조하세요. **데이터베이스 생성자** + 생성한 데이터베이스에 대한 모든 데이터베이스 권한이 있고, 데이터베이스에서 생성한 테이블에 대한 권한이 있으며, 동일한 AWS 계정의 다른 보안 주체에게 데이터베이스에 테이블을 생성할 수 있는 권한을 부여할 수 있습니다. `AWSLakeFormationCrossAccountManager` AWS 관리형 정책도 보유한 데이터베이스 생성자는 데이터베이스에 대한 권한을 다른 AWS 계정 또는 조직에 부여할 수 있습니다. 데이터 레이크 관리자는 Lake Formation 콘솔 또는 API를 사용하여 데이터베이스 생성자를 지정할 수 있습니다. **참고** 데이터베이스 생성자는 다른 사람이 데이터베이스에서 생성하는 테이블에 대한 권한을 암시적으로 가지지 않습니다. 자세한 내용은 [데이터베이스 생성](creating-database.md) 단원을 참조하십시오. **테이블 생성자** + 자신이 생성하는 테이블에 대한 모든 권한을 가집니다. + 생성하는 모든 테이블에 대한 권한을 동일한 AWS 계정의 보안 주체에 부여할 수 있습니다. + `AWSLakeFormationCrossAccountManager` AWS 관리형 정책이 있는 경우 생성한 모든 테이블에 대한 권한을 다른 AWS 계정 또는 조직에 부여할 수 있습니다. + 생성하는 테이블이 포함된 데이터베이스를 볼 수 있습니다. # Lake Formation 권한 참조 AWS Lake Formation 작업을 수행하려면 보안 주체에게 Lake Formation 권한과 AWS Identity and Access Management (IAM) 권한이 모두 필요합니다. 일반적으로 [Lake Formation 권한 개요](lf-permissions-overview.md)에 설명된 대로 대략적인 액세스 제어 정책을 사용하여 IAM 권한을 부여합니다.** 콘솔, API 또는 AWS Command Line Interface ()를 사용하여 Lake Formation 권한을 부여할 수 있습니다AWS CLI. Lake Formation 권한을 부여 또는 취소하는 방법에 대한 자세한 내용은 [데이터 카탈로그 리소스에 대한 권한 부여](granting-catalog-permissions.md) 및 [데이터 위치 권한 부여](granting-location-permissions.md) 섹션을 참조하세요. **참고** 이 섹션의 예제는 동일한 AWS 계정의 보안 주체에 권한을 부여하는 방법을 보여줍니다. 교차 계정 권한 부여의 예는 [Lake Formation에서의 교차 계정 데이터 공유](cross-account-permissions.md) 섹션을 참조하세요. ## 리소스 유형별 Lake Formation 권한 다음은 각 리소스 유형에 사용할 수 있는 유효한 Lake Formation 권한입니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/lake-formation/latest/dg/lf-permissions-reference.html) **Topics** + [리소스 유형별 Lake Formation 권한](#lf-resource-permissions-summary) + [Lake Formation 권한 부여 및 취소 AWS CLI 명령](#perm-command-format) + [Lake Formation 권한](#lf-permissions) ## Lake Formation 권한 부여 및 취소 AWS CLI 명령 이 섹션의 각 권한 설명에는 AWS CLI 명령을 사용하여 권한을 부여하는 예제가 포함되어 있습니다. 다음은 Lake Formation **grant-permissions** 및 **revoke-permissions** AWS CLI 명령의 개요입니다. ``` grant-permissions [--catalog-id ] --principal --resource --permissions [--permissions-with-grant-option ] [--cli-input-json ] [--generate-cli-skeleton ] ``` ``` revoke-permissions [--catalog-id ] --principal --resource --permissions [--permissions-with-grant-option ] [--cli-input-json ] [--generate-cli-skeleton ] ``` 이러한 명령에 대한 자세한 설명은AWS CLI 명령 참조의 [grant-permissions](https://docs.aws.amazon.com/cli/latest/reference/lakeformation/grant-permissions.html) 및 [revoke-permissions](https://docs.aws.amazon.com/cli/latest/reference/lakeformation/revoke-permissions.html)를 참조하세요.** 이 섹션에서는 `--principal` 옵션에 대한 추가 정보를 제공합니다. `--principal` 옵션의 값은 다음 중 하나입니다. + (IAM) 사용자 또는 역할의 Amazon 리소스 이름 AWS Identity and Access Management (ARN) + Microsoft Active Directory Federation Service(AD FS)와 같은 SAML 공급자를 통해 인증하는 사용자 또는 그룹의 ARN + Amazon Quick 사용자 또는 그룹의 ARN + 교차 계정 권한의 경우 AWS 계정 ID, 조직 ID 또는 조직 단위 ID + IAM Identity Center 사용자 또는 그룹의 경우 IAM Identity Center 사용자 또는 그룹 ARN입니다. 다음은 모든 `--principal` 유형의 구문과 예제입니다. **보안 주체가 IAM 사용자임** 구문: ``` --principal DataLakePrincipalIdentifier=arn:aws:iam:::user/ ``` 예제: ``` --principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:user/datalake_user1 ``` **보안 주체가 IAM 역할임** 구문: ``` --principal DataLakePrincipalIdentifier=arn:aws:iam:::role/ ``` 예제: ``` --principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:role/workflowrole ``` **보안 주체가 SAML 공급자를 통해 인증하는 사용자임** 구문: ``` --principal DataLakePrincipalIdentifier=arn:aws:iam:::saml-provider/:user/ ``` 예시: ``` --principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:saml-provider/idp1:user/datalake_user1 ``` ``` --principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:saml-provider/AthenaLakeFormationOkta:user/athena-user@example.com ``` **보안 주체가 SAML 공급자를 통해 인증하는 그룹임** 구문: ``` --principal DataLakePrincipalIdentifier=arn:aws:iam:::saml-provider/:group/ ``` 예시: ``` --principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:saml-provider/idp1:group/data-scientists ``` ``` --principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:saml-provider/AthenaLakeFormationOkta:group/my-group ``` **보안 주체가 Amazon Quick Enterprise Edition 사용자임** 구문: ``` --principal DataLakePrincipalIdentifier=arn:aws:quicksight:::user// ``` **에 대해 `default`를 지정해야 합니다. 예제: ``` --principal DataLakePrincipalIdentifier=arn:aws:quicksight:us-east-1:111122223333:user/default/bi_user1 ``` **보안 주체는 Amazon Quick Enterprise Edition 그룹입니다.** 구문: ``` --principal DataLakePrincipalIdentifier=arn:aws:quicksight:::group// ``` **에 대해 `default`를 지정해야 합니다. 예제: ``` --principal DataLakePrincipalIdentifier=arn:aws:quicksight:us-east-1:111122223333:group/default/data_scientists ``` **보안 주체는 AWS 계정입니다.** 구문: ``` --principal DataLakePrincipalIdentifier= ``` 예제: ``` --principal DataLakePrincipalIdentifier=111122223333 ``` **보안 주체가 조직임** 구문: ``` --principal DataLakePrincipalIdentifier=arn:aws:organizations:::organization/ ``` 예제: ``` --principal DataLakePrincipalIdentifier=arn:aws:organizations::111122223333:organization/o-abcdefghijkl ``` **보안 주체가 조직 단위임** 구문: ``` --principal DataLakePrincipalIdentifier=arn:aws:organizations:::ou// ``` 예제: ``` --principal DataLakePrincipalIdentifier=arn:aws:organizations::111122223333:ou/o-abcdefghijkl/ou-ab00-cdefghij ``` **보안 주체 = IAM Identity Center ID 사용자 또는 그룹** Example:User ``` --principal DataLakePrincipalIdentifier=arn:aws:identitystore:::user/ ``` Example:Group: ``` --principal DataLakePrincipalIdentifier=arn:aws:identitystore:::group/ ``` **보안 주체 = IAM 그룹 - `IAMAllowedPrincipals`** Lake Formation은 데이터 카탈로그의 모든 데이터베이스 및 테이블에 대한 `Super` 권한을 기본적으로 `IAMAllowedPrincipals` 그룹으로 설정합니다. 이 그룹 권한이 데이터베이스 또는 테이블에 존재할 경우 계정의 모든 보안 주체는 AWS Glue에 대한 IAM 보안 주체 정책을 통해 리소스에 액세스할 수 있습니다. Lake Formation 권한을 사용하여 이전에 AWS Glue에 대한 IAM 정책으로 보호된 데이터 카탈로그 리소스를 보호할 때 이전 버전과의 호환성을 제공합니다. Lake Formation을 사용하여 데이터 카탈로그 리소스에 대한 권한을 관리할 경우 먼저 리소스에 대한 `IAMAllowedPrincipals` 권한을 취소하거나 Lake Formation 권한이 작동하도록 보안 주체 및 리소스를 하이브리드 액세스 모드로 선택해야 합니다. 예제: ``` --principal DataLakePrincipalIdentifier=IAM_Allowed_Principals ``` **보안 주체 = IAM 그룹 - `ALLIAMPrincipals`** `ALLIAMPrincipals` 그룹에 데이터 카탈로그 리소스에 대한 권한을 부여하면 계정의 모든 보안 주체는 Lake Formation 권한 및 IAM 권한을 사용하여 데이터 카탈로그 리소스에 액세스할 수 있습니다. 예제: ``` --principal DataLakePrincipalIdentifier=123456789012:IAMPrincipals ``` ## Lake Formation 권한 이 섹션에는 보안 주체에 부여할 수 있는 사용 가능한 Lake Formation 권한이 포함되어 있습니다. ### `ALTER` | 권한 | 부여 대상 리소스 | 피부여자에게 필요한 추가 권한 | | --- | --- | --- | | ALTER | DATABASE | glue:UpdateDatabase | | ALTER | TABLE | glue:UpdateTable | | ALTER | LF-Tag | lakeformation:UpdateLFTag | 이 권한이 있는 보안 주체는 데이터 카탈로그에 있는 데이터베이스 또는 테이블의 메타데이터를 변경할 수 있습니다. 테이블의 경우 열 스키마를 변경하고 열 파라미터를 추가할 수 있습니다. 메타데이터 테이블이 가리키는 기본 데이터의 열은 변경할 수 없습니다. 변경되는 속성이 등록된 Amazon Simple Storage Service(S3) 위치인 경우, 보안 주체는 새 위치에 대한 데이터 위치 권한을 가지고 있어야 합니다. **Example** 다음 예제에서는 `retail` AWS 계정 1111-2222-3333의 데이터베이스에 `datalake_user1` 있는 사용자에게 `ALTER` 권한을 부여합니다. ``` aws lakeformation grant-permissions --principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:user/datalake_user1 --permissions "ALTER" --resource '{ "Database": {"Name":"retail"}}' ``` **Example** 다음 예제는 `retail` 데이터베이스의 `inventory` 테이블에 대한 `ALTER` 권한을 사용자 `datalake_user1`에게 부여합니다. ``` aws lakeformation grant-permissions --principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:user/datalake_user1 --permissions "ALTER" --resource '{ "Table": {"DatabaseName":"retail", "Name":"inventory"}}' ``` ### `CREATE_DATABASE` | 권한 | 부여 대상 리소스 | 피부여자에게 필요한 추가 권한 | | --- | --- | --- | | CREATE\$1DATABASE | 데이터 카탈로그 | glue:CreateDatabase | 이 권한이 있는 보안 주체는 데이터 카탈로그에서 메타데이터 데이터베이스 또는 리소스 링크를 생성할 수 있습니다. 또한 보안 주체는 데이터베이스에 테이블을 생성할 수도 있습니다. **Example** 다음 예제에서는 AWS 계정 1111-2222-3333`datalake_user1`의 사용자에게 `CREATE_DATABASE`를 부여합니다. ``` aws lakeformation grant-permissions --principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:user/datalake_user1 --permissions "CREATE_DATABASE" --resource '{ "Catalog": {}}' ``` 보안 주체가 데이터 카탈로그에서 데이터베이스를 생성하는 경우 기본 데이터에 대한 권한은 부여되지 않습니다. 다음과 같은 추가 메타데이터 권한이 부여되며 이러한 권한을 다른 사람에게 부여할 수도 있습니다. + 데이터베이스에서 `CREATE_TABLE` + `ALTER` 데이터베이스 + `DROP` 데이터베이스 데이터베이스를 생성할 때 보안 주체는 Amazon S3 위치를 선택적으로 지정할 수 있습니다. 보안 주체에 데이터 위치 권한이 있는지 여부에 따라 `CREATE_DATABASE` 권한이 모든 경우에 데이터베이스를 생성하기에 충분하지 않을 수 있습니다. 다음 세 가지 경우를 염두에 두어야 합니다. | 데이터베이스 생성 사용 사례 | 필요한 권한 | | --- | --- | | 위치 속성이 지정되지 않았습니다. | CREATE\$1DATABASE 권한이면 충분합니다. | | 위치 속성이 지정되었고 Lake Formation에서 위치를 관리하지 않습니다(위치가 등록되지 않음). | CREATE\$1DATABASE 권한이면 충분합니다. | | 위치 속성이 지정되었고 Lake Formation에서 위치를 관리합니다(위치가 등록됨). | CREATE\$1DATABASE 권한이 필요하며 지정된 위치에 대한 데이터 위치 권한도 필요합니다. | ### `CREATE_TABLE` | 권한 | 부여 대상 리소스 | 피부여자에게 필요한 추가 권한 | | --- | --- | --- | | CREATE\$1TABLE | DATABASE | glue:CreateTable | 이 권한이 있는 보안 주체는 지정된 데이터베이스 내의 데이터 카탈로그에 메타데이터 테이블 또는 리소스 링크를 생성할 수 있습니다. **Example** 다음 예제에서는 사용자에게 AWS 계정 1111-2222-3333의 `retail` 데이터베이스에 테이블을 생성할 수 있는 `datalake_user1` 권한을 부여합니다. ``` aws lakeformation grant-permissions --principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:user/datalake_user1 --permissions "CREATE_TABLE" --resource '{ "Database": {"Name":"retail"}}' ``` 보안 주체가 데이터 카탈로그에서 테이블을 생성하면 테이블에 대한 모든 Lake Formation 권한이 보안 주체에 부여되며, 이러한 권한을 다른 사용자에게 부여할 수도 있습니다. **교차 계정 권한 부여** 데이터베이스 소유자 계정이 수신자 계정에 `CREATE_TABLE` 권한을 부여하고 수신자 계정의 사용자가 소유자 계정의 데이터베이스에 테이블을 성공적으로 생성하는 경우 다음 규칙이 적용됩니다. + 수신자 계정의 사용자 및 데이터 레이크 관리자는 테이블에 대한 모든 Lake Formation 권한을 가집니다. 해당 계정에 있는 다른 보안 주체에게 테이블에 대한 권한을 부여할 수 있습니다. 소유자 계정이나 다른 계정의 보안 주체에게는 권한을 부여할 수 없습니다. + 소유자 계정의 데이터 레이크 관리자는 해당 계정의 다른 보안 주체에게 테이블에 대한 권한을 부여할 수 있습니다. **데이터 위치 권한** Amazon S3 위치를 가리키는 테이블을 생성하려는 경우 데이터 위치 권한이 있는지 여부에 따라 `CREATE_TABLE` 권한이 테이블을 생성하는 데 충분하지 않을 수 있습니다. 다음 세 가지 경우를 염두에 두어야 합니다. | 테이블 생성 사용 사례 | 필요한 권한 | | --- | --- | | Lake Formation에서 지정 위치를 관리하지 않습니다(위치가 등록되지 않음). | CREATE\$1TABLE 권한이면 충분합니다. | | Lake Formation에서 지정 위치를 관리하며(위치가 등록됨), 포함된 데이터베이스에 위치 속성이 없거나 테이블 위치의 Amazon S3 접두사가 아닌 위치 속성이 있습니다. | CREATE\$1TABLE 권한이 필요하며 지정된 위치에 대한 데이터 위치 권한도 필요합니다. | | Lake Formation에서 지정 위치를 관리하며(위치가 등록됨), 포함된 데이터베이스에 등록된 위치를 가리키고 테이블 위치의 Amazon S3 접두사인 위치 속성이 있습니다. | CREATE\$1TABLE 권한이면 충분합니다. | ### `DATA_LOCATION_ACCESS` | 권한 | 부여 대상 리소스 | 피부여자에게 필요한 추가 권한 | | --- | --- | --- | | DATA\$1LOCATION\$1ACCESS | Amazon S3 위치 | (위치에 대한 Amazon S3 권한. 이 권한은 위치를 등록하는 데 사용되는 역할에 의해 지정되어야 합니다.) | 이 권한은 유일한 데이터 위치 권한입니다. 이 권한이 있는 보안 주체는 지정된 Amazon S3 위치를 가리키는 메타데이터 데이터베이스 또는 테이블을 생성할 수 있습니다. 위치를 등록해야 합니다. 위치에 대한 데이터 위치 권한이 있는 보안 주체는 하위 위치에 대한 위치 권한도 갖습니다. **Example** 다음 예제는 AWS 계정 1111-2222-3333의 사용자 `datalake_user1`에게 `s3://products/retail`에 대한 데이터 위치 권한을 부여합니다. ``` aws lakeformation grant-permissions --principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:user/datalake_user1 --permissions "DATA_LOCATION_ACCESS" --resource '{ "DataLocation": {"ResourceArn":"arn:aws:s3:::products/retail"}}' ``` `DATA_LOCATION_ACCESS`는 기본 데이터 쿼리 또는 업데이트에는 필요하지 않습니다. 이 권한은 데이터 카탈로그 리소스 생성에만 적용됩니다. 데이터 위치 권한에 대한 자세한 내용은 [Underlying data access control](access-control-underlying-data.md#data-location-permissions) 섹션을 참조하세요. ### `DELETE` | 권한 | 부여 대상 리소스 | 피부여자에게 필요한 추가 권한 | | --- | --- | --- | | DELETE | TABLE | (위치가 등록된 경우 추가 IAM 권한이 필요하지 않습니다.) | 이 권한이 있는 보안 주체는 테이블에 지정된 Amazon S3 위치에서 기본 데이터를 삽입하고, 업데이트하고, 읽을 수 있습니다. 또한 보안 주체는 Lake Formation 콘솔에서 테이블을 보고 AWS Glue API를 사용하여 테이블에 대한 정보를 검색할 수 있습니다. **Example** 다음 예제에서는 AWS 계정 1111-2222-3333`datalake_user1`의 데이터베이스에 `inventory` 있는 테이블`retail`의 사용자에게 `DELETE` 권한을 부여합니다. ``` aws lakeformation grant-permissions --principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:user/datalake_user1 --permissions "DELETE" --resource '{ "Table": {"DatabaseName":"retail", "Name":"inventory"}}' ``` 이 권한은 Amazon S3의 데이터에만 적용되며 Amazon Relational Database Service(RDS)와 같은 다른 데이터 스토어의 데이터에는 적용되지 않습니다. ### `DESCRIBE` | 권한 | 부여 대상 리소스 | 피부여자에게 필요한 추가 권한 | | --- | --- | --- | | DESCRIBE | 테이블 리소스 링크 데이터베이스 리소스 링크 | `glue:GetTable` `glue:GetDatabase` | | DESCRIBE | DATABASE | glue:GetDatabase | | DESCRIBE | TABLE | glue:GetTable | | DESCRIBE | LF-Tag | `glue:GetTable` `glue:GetDatabase` `lakeformation:GetResourceLFTags` `lakeformation:ListLFTags` `lakeformation:GetLFTag` `lakeformation:SearchTablesByLFTags` `lakeformation:SearchDatabasesByLFTags` | 이 권한이 있는 보안 주체는 지정된 데이터베이스, 테이블 또는 리소스 링크를 볼 수 있습니다. 다른 데이터 카탈로그 권한은 암시적으로 부여되지 않으며 데이터 액세스 권한도 암시적으로 부여되지 않습니다. 데이터베이스와 테이블은 통합 서비스의 쿼리 편집기에 표시되지만 다른 Lake Formation 권한(예:`SELECT`)이 부여되지 않는 한 데이터베이스와 테이블에 대해 쿼리를 수행할 수 없습니다. 예를 들어 데이터베이스에 대한 `DESCRIBE` 권한이 있는 사용자는 데이터베이스와 모든 데이터베이스 메타데이터(설명, 위치 등)를 볼 수 있습니다. 하지만 데이터베이스에 포함된 테이블을 찾을 수는 없으며 데이터베이스에서 테이블을 삭제, 변경 또는 생성할 수 없습니다. 마찬가지로 테이블에 대한 `DESCRIBE` 권한이 있는 사용자는 테이블과 테이블 메타데이터(설명, 스키마, 위치 등)를 볼 수 있지만 테이블을 삭제, 변경하거나 테이블에 대해 쿼리를 실행할 수 없습니다. 다음은 `DESCRIBE`에 대한 몇 가지 추가 규칙입니다. + 사용자에게 데이터베이스, 테이블 또는 리소스 링크에 대한 다른 Lake Formation 권한이 있는 경우 `DESCRIBE` 권한이 암시적으로 부여됩니다. + 사용자가 테이블 열의 하위 집합에 대해서만 `SELECT` 권한이 있는 경우(부분 `SELECT`) 사용자는 해당 열만 볼 수 있도록 제한됩니다. + 테이블에 대해 부분 선택 권한이 있는 사용자에게는 `DESCRIBE` 권한을 부여할 수 없습니다. 반대로 `DESCRIBE` 권한이 부여된 테이블에 대해서는 열 포함 또는 제외 목록을 지정할 수 없습니다. **Example** 다음 예제에서는 `retail` AWS 계정 1111-2222-3333의 데이터베이스에 `datalake_user1` 있는 테이블 리소스 링크`inventory-link`에서 사용자에게 `DESCRIBE` 권한을 부여합니다. ``` aws lakeformation grant-permissions --principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:user/datalake_user1 --permissions "DESCRIBE" --resource '{ "Table": {"DatabaseName":"retail", "Name":"inventory-link"}}' ``` ### `DROP` | 권한 | 부여 대상 리소스 | 피부여자에게 필요한 추가 권한 | | --- | --- | --- | | DROP | DATABASE | glue:DeleteDatabase | | DROP | TABLE | glue:DeleteTable | | DROP | LF-Tag | lakeformation:DeleteLFTag | | DROP | 데이터베이스 리소스 링크 테이블 리소스 링크 | `glue:DeleteDatabase` `glue:DeleteTable` | 이 권한이 있는 보안 주체는 데이터 카탈로그에서 데이터베이스, 테이블 또는 리소스 링크를 삭제할 수 있습니다. 외부 계정 또는 조직에 데이터베이스에 대한 DROP 권한을 부여할 수 없습니다. **주의** 데이터베이스를 삭제하면 데이터베이스의 모든 테이블이 삭제됩니다. **Example** 다음 예제에서는 `retail` AWS 계정 1111-2222-3333의 데이터베이스에 `datalake_user1` 있는 사용자에게 `DROP` 권한을 부여합니다. ``` aws lakeformation grant-permissions --principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:user/datalake_user1 --permissions "DROP" --resource '{ "Database": {"Name":"retail"}}' ``` **Example** 다음 예제는 `retail` 데이터베이스의 `inventory` 테이블에 대한 `DROP` 권한을 사용자 `datalake_user1`에게 부여합니다. ``` aws lakeformation grant-permissions --principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:user/datalake_user1 --permissions "DROP" --resource '{ "Table": {"DatabaseName":"retail", "Name":"inventory"}}' ``` **Example** 다음 예제는 `retail` 데이터베이스의 테이블 리소스 링크 `inventory-link`에 대한 `DROP` 권한을 사용자 `datalake_user1`에게 부여합니다. ``` aws lakeformation grant-permissions --principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:user/datalake_user1 --permissions "DROP" --resource '{ "Table": {"DatabaseName":"retail", "Name":"inventory-link"}}' ``` ### `INSERT` | 권한 | 부여 대상 리소스 | 피부여자에게 필요한 추가 권한 | | --- | --- | --- | | INSERT | TABLE | (위치가 등록된 경우 추가 IAM 권한이 필요하지 않습니다.) | 이 권한이 있는 보안 주체는 테이블에 지정된 Amazon S3 위치에서 기본 데이터를 삽입하고, 업데이트하고, 읽을 수 있습니다. 또한 보안 주체는 Lake Formation 콘솔에서 테이블을 보고 AWS Glue API를 사용하여 테이블에 대한 정보를 검색할 수 있습니다. **Example** 다음 예제에서는 AWS 계정 1111-2222-3333`datalake_user1`의 데이터베이스에 `inventory` 있는 테이블`retail`의 사용자에게 `INSERT` 권한을 부여합니다. ``` aws lakeformation grant-permissions --principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:user/datalake_user1 --permissions "INSERT" --resource '{ "Table": {"DatabaseName":"retail", "Name":"inventory"}}' ``` 이 권한은 Amazon S3의 데이터에만 적용되며 Amazon RDS와 같은 다른 데이터 스토어의 데이터에는 적용되지 않습니다. ### `SELECT` | 권한 | 부여 대상 리소스 | 피부여자에게 필요한 추가 권한 | | --- | --- | --- | | SELECT | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/lake-formation/latest/dg/lf-permissions-reference.html) | (위치가 등록된 경우 추가 IAM 권한이 필요하지 않습니다.) | 이 권한이 있는 보안 주체는 데이터 카탈로그의 테이블을 볼 수 있으며 테이블에 지정된 위치에서 Amazon S3의 기본 데이터를 쿼리할 수 있습니다. 보안 주체는 Lake Formation 콘솔에서 테이블을 보고 AWS Glue API를 사용하여 테이블에 대한 정보를 검색할 수 있습니다. 이 권한이 부여되었을 때 열 필터링이 적용된 경우 보안 주체는 포함된 열의 메타데이터만 볼 수 있고 포함된 열의 데이터만 쿼리할 수 있습니다. **참고** 쿼리를 처리할 때 열 필터링을 적용하는 것은 통합 분석 서비스의 책임입니다. **Example** 다음 예제에서는 AWS 계정 1111-2222-3333`datalake_user1`의 데이터베이스에 `inventory` 있는 테이블`retail`의 사용자에게 `SELECT` 권한을 부여합니다. ``` aws lakeformation grant-permissions --principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:user/datalake_user1 --permissions "SELECT" --resource '{ "Table": {"DatabaseName":"retail", "Name":"inventory"}}' ``` 이 권한은 Amazon S3의 데이터에만 적용되며 Amazon RDS와 같은 다른 데이터 스토어의 데이터에는 적용되지 않습니다. 선택적 포함 목록 또는 제외 목록을 사용하여 특정 열을 필터링(액세스 제한)할 수 있습니다. 포함 목록은 액세스할 수 있는 열을 지정합니다. 제외 목록은 액세스할 수 없는 열을 지정합니다. 포함 또는 제외 목록이 없는 경우 모든 테이블 열에 액세스할 수 있습니다. `glue:GetTable`의 결과는 호출자가 볼 수 있는 권한이 있는 열만 반환합니다. Amazon Athena 및 Amazon Redshift와 같은 통합 서비스는 열 포함 및 제외 목록을 고려합니다. **Example** 다음 예제는 포함 목록을 사용하여 `inventory` 테이블의 사용자 `datalake_user1`에게 `SELECT` 권한을 부여합니다. ``` aws lakeformation grant-permissions --principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:user/datalake_user1 --permissions "SELECT" --resource '{ "TableWithColumns": {"DatabaseName":"retail", "Name":"inventory", "ColumnNames": ["prodcode","location","period","withdrawals"]}}' ``` **Example** 다음 예제는 제외 목록을 사용하여 `inventory` 테이블에 대한 `SELECT` 권한을 부여합니다. ``` aws lakeformation grant-permissions --principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:user/datalake_user1 --permissions "SELECT" --resource '{ "TableWithColumns": {"DatabaseName":"retail", "Name":"inventory", "ColumnWildcard": {"ExcludedColumnNames": ["intkey", "prodcode"]}}}' ``` `SELECT` 권한에 적용되는 제한은 다음과 같습니다. + `SELECT` 권한을 부여할 때 열 필터링이 적용된 경우에는 권한 부여 옵션을 포함할 수 없습니다. + 파티션 키인 열에 대한 액세스 제어를 제한할 수 없습니다. + 테이블의 열 하위 집합에 대한 `SELECT` 권한이 있는 보안 주체는 해당 테이블에 대한 `ALTER`, `DROP`, `DELETE` 또는 `INSERT` 권한을 부여받을 수 없습니다. 마찬가지로, 테이블에 대해 `ALTER`, `DROP`, `DELETE` 또는 `INSERT` 권한이 있는 보안 주체에게는 열 필터링이 포함된 `SELECT` 권한을 부여할 수 없습니다. `SELECT` 권한은 항상 Lake Formation 콘솔의 **데이터 권한** 페이지에 별도의 행으로 표시됩니다. 다음 이미지는 `inventory` 테이블의 모든 열에 대해 `datalake_user2` 및 `datalake_user3` 사용자에게 `SELECT` 권한이 부여되었음을 보여줍니다. ![\[데이터 권한 페이지에는 4개의 행이 표시됩니다. 첫 번째와 세 번째 행은 인벤토리로 표시된 리소스를 가진 리소스 유형이 테이블인 삭제 및 삽입 권한을 나열하고, 두 번째와 네 번째 행은 리소스 유형이 열인 선택 권한을 나열합니다. 리소스는 retail.inventory.*로 표시됩니다.\]](http://docs.aws.amazon.com/ko_kr/lake-formation/latest/dg/images/data-permissions-dialog-select-cross.png) ### `Super` | 권한 | 부여 대상 리소스 | 피부여자에게 필요한 추가 권한 | | --- | --- | --- | | Super | DATABASE | glue:\$1Database\$1 | | Super | TABLE | glue:\$1Table\$1, glue:\$1Partition\$1 | 이 권한을 통해 보안 주체는 데이터베이스 또는 테이블에서 지원되는 모든 Lake Formation 작업을 수행할 수 있습니다. 외부 계정에 데이터베이스에 대해서는 `Super` 권한을 부여할 수 없습니다. 이 권한은 다른 Lake Formation 권한과 공존할 수 있습니다. 예를 들어 메타데이터 테이블에 대한 `Super`, `SELECT` 및 `INSERT` 권한을 부여할 수 있습니다. 그러면 보안 주체는 테이블에서 지원되는 모든 작업을 수행할 수 있습니다. `Super` 권한을 취소하면 `SELECT` 및 `INSERT` 권한은 그대로 유지되며 보안 주체는 선택 및 삽입 작업만 수행할 수 있습니다. `Super` 권한을 개별 보안 주체에 부여하는 대신 그룹 `IAMAllowedPrincipals`에 부여할 수 있습니다. `IAMAllowedPrincipals` 그룹은 자동으로 생성되며 IAM 정책에 따라 데이터 카탈로그 리소스에 대한 액세스가 허용된 모든 IAM 사용자 및 역할을 포함합니다. `Super` 권한이 데이터 카탈로그 리소스에 대해 `IAMAllowedPrincipals`에 부여되면 리소스에 대한 액세스는 IAM 정책에 의해서만 효과적으로 제어됩니다. Lake Formation 콘솔의 **설정** 페이지에 있는 옵션을 활용하여 새 카탈로그 리소스에 대해 `Super` 권한이 `IAMAllowedPrincipals`에 자동으로 부여되도록 할 수 있습니다. ![\[데이터 카탈로그 설정 대화 상자에는 “새로 생성된 데이터베이스 및 테이블에 대한 기본 사용 권한”이라는 부제가 있으며 텍스트에 설명된 두 개의 확인란이 있습니다.\]](http://docs.aws.amazon.com/ko_kr/lake-formation/latest/dg/images/settings-page.png) + 모든 새 데이터베이스에 대해 `Super` 권한을 `IAMAllowedPrincipals`에 부여하려면 **새 데이터베이스에 대해 IAM 액세스 제어만 사용**을 선택합니다. + 새 데이터베이스의 모든 새 테이블에 대해 `Super` 권한을 `IAMAllowedPrincipals`에 부여하려면 **새 데이터베이스의 새 테이블에 대해 IAM 액세스 제어만 사용**을 선택합니다. **참고** 이 옵션을 사용하면 **데이터베이스 생성** 대화 상자에서 **이 데이터베이스의 새 테이블에 대해 IAM 액세스 제어만 사용** 확인란이 기본적으로 선택됩니다. 그 외의 변화는 없습니다. 이것은 `IAMAllowedPrincipals`에 `Super` 권한을 부여할 수 있는 **데이터베이스 생성** 대화 상자의 확인란입니다. 이러한 **설정** 페이지 옵션은 기본적으로 활성화되어 있습니다. 자세한 내용은 다음을 참조하세요. + [데이터 레이크의 기본 설정 변경](change-settings.md) + [AWS Lake Formation 모델로 AWS Glue 데이터 권한 업그레이드](upgrade-glue-lake-formation.md) ### `SUPER_USER` | 권한 | 부여 대상 리소스 | 피부여자에게 필요한 추가 권한 | | --- | --- | --- | | Super user | Catalog | glue:GetCatalog | 기본 Data Catalog 내의 카탈로그에 있는 특정 보안 주체에만 `Super user` 권한을 부여할 수 있습니다. 기본 카탈로그 또는 데이터베이스 및 테이블과 같은 다른 리소스 유형에 대해서나 외부 계정의 보안 주체를 대상으로 `Super user` 권한을 부여할 수 없습니다. `Super user` 권한을 통해 보안 주체는 부여된 카탈로그 내의 데이터베이스 및 테이블에 대해 지원되는 모든 Lake Formation 작업을 수행할 수 있습니다. `Super user` 권한을 통해 보안 주체(피부여자)는 카탈로그 내의 리소스(카탈로그, 데이터베이스 및 테이블)에 대해 다음 작업을 수행할 수 있습니다. + 카탈로그에 대한 `CREATE_DATABASE`, `DESCRIBE` 권한 + 카탈로그 내의 모든 데이터베이스에 대한 `DROP`, `ALTER`, `CREATE_TABLE`, `DESCRIBE`(효과적으로 `SUPER`) 권한 + 카탈로그 내 모든 데이터베이스의 모든 테이블에 대한 `DROP`, `ALTER`, `DESCRIBE`, `SELECT`, `INSERT`, `DELETE`(효과적으로 `SUPER`) 권한 + 카탈로그 내의 카탈로그에 대한 `All`(효과적으로 SUPER) 권한 + 카탈로그 내의 모든 카탈로그, 데이터베이스 및 테이블에 대해 부여 가능한(다른 보안 주체에게 이러한 권한을 부여하는 기능) 권한 카탈로그 리소스에 대한 `Super user` 권한이 있는 경우 피부여자는 카탈로그에서 `ALTER` 및 `DROP` 작업을 수행하거나 위임할 수 없습니다. ### `ASSOCIATE` | 권한 | 부여 대상 리소스 | 피부여자에게 필요한 추가 권한 | | --- | --- | --- | | ASSOCIATE | LF-Tag | `glue:GetDatabase` `glue:GetTable` `lakeformation:AddLFTagsToResource"` `lakeformation:RemoveLFTagsFromResource"` `lakeformation:GetResourceLFTags` `lakeformation:ListLFTags` `lakeformation:GetLFTag` `lakeformation:SearchTablesByLFTags` `lakeformation:SearchDatabasesByLFTags` | LF 태그에 대해 이 권한이 있는 보안 주체는 LF 태그를 데이터 카탈로그 리소스에 할당할 수 있습니다. `ASSOCIATE` 권한을 부여하면 암시적으로 `DESCRIBE` 권한이 부여됩니다. **Example** 이 예제는 사용자 `datalake_user1`에게 `module` 키를 가진 LF 태그에 대한 `ASSOCIATE` 권한을 부여합니다. 별표(\$1)로 표시된 대로 해당 키의 모든 값을 보고 할당할 수 있는 권한을 부여합니다. ``` aws lakeformation grant-permissions --principal DataLakePrincipalIdentifier=arn:aws:iam::111122223333:user/datalake_user1 --permissions "ASSOCIATE" --resource '{ "LFTag": {"CatalogId":"111122223333","TagKey":"module","TagValues":["*"]}}' ``` # IAM Identity Center 통합 를 사용하면 ID 제공업체(IdPs)에 연결하고 AWS 분석 서비스 전반에서 사용자 및 그룹에 대한 액세스를 중앙에서 관리할 AWS IAM Identity Center수 있습니다. Okta, Ping 및 Microsoft Entra ID(이전 Azure Active Directory)와 같은 자격 증명 공급자를 IAM Identity Center와 통합하여 조직의 사용자가 Single Sign-On 환경을 사용하여 데이터에 액세스하도록 할 수 있습니다. 또한 IAM Identity Center는 추가 타사 자격 증명 공급자 연결을 지원합니다. 자세한 내용은 AWS IAM Identity Center 사용 설명서의 [지원되는 자격 증명 공급자](https://docs.aws.amazon.com/singlesignon/latest/userguide/supported-idps.html)를 참조하세요. IAM Identity Center에서를 활성화된 애플리케이션 AWS Lake Formation 으로 구성할 수 있으며, 데이터 레이크 관리자는 AWS Glue Data Catalog 리소스의 승인된 사용자 및 그룹에 세분화된 권한을 부여할 수 있습니다. 조직의 사용자는 조직의 자격 증명 공급자를 사용하여 모든 Identity Center 지원 애플리케이션에 로그인하고 Lake Formation 권한을 적용하여 데이터세트를 쿼리할 수 있습니다. 이 통합을 통해 여러 IAM 역할을 생성하지 않고도 AWS 서비스에 대한 액세스를 관리할 수 있습니다. [신뢰할 수 있는 자격 증명 전파](https://docs.aws.amazon.com//singlesignon/latest/userguide/trustedidentitypropagation-overview.html)는 연결된의 관리자가 서비스 데이터에 대한 액세스 권한을 부여하고 감사하는 데 사용할 AWS 서비스 수 있는 AWS IAM Identity Center 기능입니다. 이 데이터에 대한 액세스는 그룹 연결과 같은 사용자 속성을 기반으로 합니다. 신뢰할 수 있는 자격 증명 전파를 설정하려면 연결된의 관리자와 AWS 서비스 IAM Identity Center 관리자 간의 협업이 필요합니다. 자세한 내용은 [사전 조건 및 고려 사항](https://docs.aws.amazon.com//singlesignon/latest/userguide/trustedidentitypropagation-overall-prerequisites.html)을 참조하세요. 제한 사항은 [IAM Identity Center 통합 제한 사항](identity-center-lf-notes.md) 섹션을 참조하세요. **Topics** + [IAM Identity Center를 Lake Formation과 통합하기 위한 사전 조건](prerequisites-identity-center.md) + [Lake Formation과 IAM Identity Center 연결](connect-lf-identity-center.md) + [IAM Identity Center 통합 업데이트](update-lf-identity-center-connection.md) + [IAM Identity Center와의 Lake Formation 연결 삭제](delete-lf-identity-center-connection.md) + [사용자 및 그룹에 권한 부여](grant-permissions-sso.md) + [CloudTrail 로그에 IAM Identity Center 사용자 컨텍스트 포함](identity-center-ct-logs.md) # IAM Identity Center를 Lake Formation과 통합하기 위한 사전 조건 다음은 IAM Identity Center를 Lake Formation과 통합하기 위한 사전 조건입니다. 1. IAM Identity Center 활성화 - IAM Identity Center 활성화는 인증 및 자격 증명 전파를 지원하기 위한 사전 조건입니다. 1. 자격 증명 원본 선택 - IAM Identity Center를 활성화한 후에는 사용자와 그룹을 관리할 자격 증명 공급자가 있어야 합니다. 내장된 Identity Center 디렉터리를 ID 소스로 사용하거나 Microsoft Entra ID 또는 Okta와 같은 외부 IdP를 사용할 수 있습니다. 자세한 내용은 AWS IAM Identity Center 사용 설명서의 자격 [증명 소스 관리](https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source.html) 및 [외부 자격 증명 공급자에 연결을](https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-idp.html) 참조하세요. 1. IAM 역할 생성 - IAM Identity Center 연결을 생성하는 역할에는 다음 인라인 정책에서와 같이 Lake Formation 및 IAM Identity Center에서 애플리케이션 구성을 생성하고 수정할 수 있는 권한이 필요합니다. IAM 모범 사례에 따라 권한을 추가해야 합니다. 구체적인 권한은 다음 절차에 자세히 설명되어 있습니다. 자세한 내용은 [IAM Identity Center 시작하기](https://docs.aws.amazon.com/singlesignon/latest/userguide/get-started-enable-identity-center.html)를 참조하세요. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "lakeformation:CreateLakeFormationIdentityCenterConfiguration", "sso:CreateApplication", "sso:PutApplicationAssignmentConfiguration", "sso:PutApplicationAuthenticationMethod", "sso:PutApplicationGrant", "sso:PutApplicationAccessScope" ], "Resource": [ "*" ] } ] } ``` ------ 외부 AWS 계정 또는 조직과 데이터 카탈로그 리소스를 공유하는 경우 리소스 공유를 생성할 수 있는 AWS Resource Access Manager (AWS RAM) 권한이 있어야 합니다. 리소스 공유에 필요한 권한에 대한 자세한 내용은 [교차 계정 데이터 공유 필수 조건](cross-account-prereqs.md) 섹션을 참조하세요. 다음 인라인 정책에는 Lake Formation과 IAM Identity Center의 통합 속성을 확인, 업데이트 및 삭제하는 데 필요한 특정 권한이 포함되어 있습니다. + 다음 인라인 정책을 사용하여 IAM 역할이 IAM Identity Center와의 Lake Formation 통합을 볼 수 있도록 허용하십시오. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "lakeformation:DescribeLakeFormationIdentityCenterConfiguration", "sso:DescribeApplication" ], "Resource": [ "*" ] } ] } ``` ------ + 다음 인라인 정책을 사용하여 IAM 역할이 IAM Identity Center와의 Lake Formation 통합을 업데이트할 수 있도록 허용하십시오. 이 정책에는 외부 계정과 리소스를 공유하는 데 필요한 옵션 권한도 포함되어 있습니다. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "lakeformation:UpdateLakeFormationIdentityCenterConfiguration", "lakeformation:DescribeLakeFormationIdentityCenterConfiguration", "sso:DescribeApplication", "sso:UpdateApplication" ], "Resource": [ "*" ] } ] } ``` ------ + 다음 인라인 정책을 사용하여 IAM 역할이 IAM Identity Center와의 Lake Formation 통합을 삭제할 수 있도록 허용하십시오. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "lakeformation:DeleteLakeFormationIdentityCenterConfiguration", "sso:DeleteApplication" ], "Resource": [ "*" ] } ] } ``` ------ + IAM Identity Center 사용자 및 그룹에 데이터 레이크 권한을 부여하거나 취소하는 데 필요한 IAM 권한은 [Lake Formation 권한을 부여 또는 취소하는 데 필요한 IAM 권한](required-permissions-for-grant.md) 섹션을 참조하세요. *권한 설명* + `lakeformation:CreateLakeFormationIdentityCenterConfiguration` - Lake Formation IdC 구성을 생성합니다. + `lakeformation:DescribeLakeFormationIdentityCenterConfiguration` - 기존 IdC 구성을 설명합니다. + `lakeformation:DeleteLakeFormationIdentityCenterConfiguration` - 기존 Lake Formation IdC 구성을 삭제할 수 있는 기능을 제공합니다. + `lakeformation:UpdateLakeFormationIdentityCenterConfiguration` - 기존 Lake Formation 구성을 변경하는 데 사용됩니다. + `sso:CreateApplication` - IAM Identity Center 애플리케이션을 생성하는 데 사용됩니다. + `sso:DeleteApplication` - IAM Identity Center 애플리케이션을 삭제하는 데 사용됩니다. + `sso:UpdateApplication` - IAM Identity Center 애플리케이션을 업데이트하는 데 사용됩니다. + `sso:PutApplicationGrant` - 신뢰할 수 있는 토큰 발급자 정보를 변경하는 데 사용됩니다. + `sso:PutApplicationAuthenticationMethod` - Lake Formation 인증 액세스 권한을 부여합니다. + `sso:GetApplicationGrant` - 신뢰할 수 있는 토큰 발급자 정보를 나열하는 데 사용됩니다. + `sso:DeleteApplicationGrant` - 신뢰할 수 있는 토큰 발급자 정보를 삭제합니다. + `sso:PutApplicationAccessScope` - 애플리케이션의 IAM Identity Center 액세스 범위에 대한 승인된 대상 목록을 추가하거나 업데이트합니다. + `sso:PutApplicationAssignmentConfiguration` - 사용자가 애플리케이션에 액세스하는 방법을 구성하는 데 사용됩니다. # Lake Formation과 IAM Identity Center 연결 IAM Identity Center를 통해 Lake Formation을 사용하여 데이터 카탈로그 리소스에 대한 액세스를 허용하도록 자격 증명을 관리하려면 먼저 다음 단계를 완료해야 합니다. Lake Formation 콘솔 또는 AWS CLI를 사용하여 IAM Identity Center 통합을 생성할 수 있습니다. ------ #### [ AWS Management Console ] **Lake Formation을 IAM Identity Center와 연결** 1. 에 로그인 AWS Management Console하고 [https://console.aws.amazon.com/lakeformation/](https://console.aws.amazon.com/lakeformation/) Lake Formation 콘솔을 엽니다. 1. 왼쪽 탐색 창에서 **IAM Identity Center 통합**을 선택합니다. ![\[Identity Center ARN을 사용한 IAM Identity Center 통합 화면\]](http://docs.aws.amazon.com/ko_kr/lake-formation/latest/dg/images/identity-center-integ.png) 1. (선택 사항) 외부 계정이 데이터 카탈로그 리소스에 액세스할 수 있도록 하나 이상의 AWS 계정 IDs, 조직 IDs 및/또는 조직 단위 IDs를 입력합니다. IAM Identity Center 사용자 또는 그룹이 Lake Formation 관리형 데이터 카탈로그 리소스에 액세스하려고 하면 Lake Formation은 메타데이터 액세스를 승인하는 IAM 역할을 수임합니다. IAM 역할이 AWS Glue 리소스 정책 및 AWS RAM 리소스 공유가 없는 외부 계정에 속하는 경우 IAM Identity Center 사용자 및 그룹은 Lake Formation 권한이 있더라도 리소스에 액세스할 수 없습니다. Lake Formation은 AWS Resource Access Manager (AWS RAM) 서비스를 사용하여 리소스를 외부 계정 및 조직과 공유합니다.는 피부여자 계정에 리소스 공유를 수락하거나 거부하라는 초대를 AWS RAM 보냅니다. 자세한 내용은 [에서 리소스 공유 초대 수락 AWS RAM](accepting-ram-invite.md) 단원을 참조하십시오. **참고** Lake Formation은 외부 계정의 IAM 역할이 데이터 카탈로그 리소스에 액세스하기 위한 IAM Identity Center 사용자 및 그룹을 대신하여 통신 사업자 역할을 수행하도록 허용하지만 소유 계정 내의 데이터 카탈로그 리소스에 대해서만 권한을 부여할 수 있습니다. 외부 계정의 데이터 카탈로그 리소스에 대한 IAM Identity Center 사용자 및 그룹에 권한을 부여하려고 할 경우 Lake Formation에서 “보안 주체에 대해 교차 계정 권한 부여가 지원되지 않습니다.” 오류가 발생합니다. 1. (선택 사항) **Lake Formation 통합 생성** 화면에서 Lake Formation에 등록된 Amazon S3 위치의 데이터에 액세스할 수 있는 타사 애플리케이션의 ARN을 지정합니다. Lake Formation은 권한 있는 애플리케이션이 사용자를 대신하여 데이터에 액세스할 수 있도록 유효 권한에 따라 등록된 Amazon S3 위치에 AWS STS 토큰 형태의 범위 축소된 임시 자격 증명을 제공합니다. 1. (선택 사항) **Lake Formation 통합 생성** 화면에서 신뢰할 수 있는 자격 증명 전파의 Amazon Redshift Connect 확인란을 선택하여 IDC를 통한 Amazon Redshift 페더레이션 권한 검색을 활성화합니다. Lake Formation은 유효 권한을 기반으로 자격 증명을 다운스트림에 전파하므로 권한이 부여된 애플리케이션이 사용자를 대신하여 데이터에 액세스할 수 있습니다. 1. **제출**을 선택합니다. Lake Formation 관리자가 단계를 완료하고 통합을 생성하면 IAM Identity Center 속성이 Lake Formation 콘솔에 표시됩니다. 이러한 작업을 완료하면 Lake Formation이 IAM Identity Center를 지원하는 애플리케이션이 됩니다. 콘솔의 속성에는 통합 상태가 포함됩니다. 통합 상태는 완료 시 `Success`로 표시됩니다. 이 상태는 IAM Identity Center 구성이 완료되었는지 여부를 나타냅니다. ------ #### [ AWS CLI ] + 다음은 IAM Identity Center와의 Lake Formation 통합을 생성하는 방법을 나타낸 예제입니다. 애플리케이션의 `Status`(`ENABLED`, `DISABLED`)를 지정할 수도 있습니다. ``` aws lakeformation create-lake-formation-identity-center-configuration \ --catalog-id <123456789012> \ --instance-arn \ --share-recipients '[{"DataLakePrincipalIdentifier": "<123456789012>"}, {"DataLakePrincipalIdentifier": "<555555555555>"}]' \ --external-filtering '{"AuthorizedTargets": ["", ""], "Status": "ENABLED"}' ``` + 다음은 IAM Identity Center와의 Lake Formation 통합을 확인하는 방법을 나타낸 예제입니다. ``` aws lakeformation describe-lake-formation-identity-center-configuration --catalog-id <123456789012> ``` + 다음 예제에서는 `Redshift:Connect` 권한 부여를 활성화하는 방법을 보여줍니다. 권한 부여는 활성화 또는 비활성화될 수 있습니다. ``` aws lakeformation create-lake-formation-identity-center-configuration \ --instance-arn \ --service-integrations '[{ "Redshift": [{ "RedshiftConnect": { "Authorization": "ENABLED" } }] }]' ``` + `describe-lake-formation-identity-center-configuration` 명령을 사용하여 레이크 형성 ID 센터 애플리케이션을 설명합니다. `Redshift:Connect` 서비스 통합은 교차 서비스 및 교차 클러스터 IdC ID 전파에 필수적입니다. ``` aws lakeformation describe-lake-formation-identity-center-configuration --catalog-id <123456789012> ``` 응답: ``` { "CatalogId": "CATALOG ID", "InstanceArn": "INSTANCE ARN", "ApplicationArn": "APPLICATION ARN", "ShareRecipients": [], "ServiceIntegrations": [ { "Redshift": [ { "RedshiftConnect": { "Authorization": "ENABLED" } } ] } ] } ``` ------ ## 여러에서 IAM Identity Center 사용 AWS 리전 Lake Formation은 여러에서 IAM Identity Center를 지원합니다 AWS 리전. IAM Identity Center를 기본 리전에서 추가 리전 AWS 리전 으로 확장하여 사용자와의 근접성과 신뢰성을 통해 성능을 개선할 수 있습니다. IAM Identity Center에 새 리전이 추가되면 기본 리전에서 자격 증명을 복제하지 않고도 새 리전에서 Lake Formation Identity Center 애플리케이션을 생성할 수 있습니다. 여러 리전에서 IAM Identity Center를 시작하는 방법에 대한 자세한 내용은 [IAM Identity Center 사용 설명서의 다중 리전](https://docs.aws.amazon.com/singlesignon/latest/userguide/multi-region-iam-identity-center.html) *IAM Identity Center*를 참조하세요. # IAM Identity Center 통합 업데이트 연결을 생성한 후, IAM Identity Center 통합을 위한 타사 애플리케이션을 추가하여 Lake Formation과 통합하고, 사용자를 대신하여 Amazon S3 데이터에 액세스할 수 있습니다. IAM Identity Center 통합에서 기존 애플리케이션을 제거할 수도 있습니다. Lake Formation 콘솔 AWS CLI과 [UpdateLakeFormationIdentityCenterConfiguration](https://docs.aws.amazon.com/lake-formation/latest/APIReference/API_UpdateLakeFormationIdentityCenterConfiguration.html) 작업을 사용하여 애플리케이션을 추가하거나 제거할 수 있습니다. **참고** IAM Identity Center 통합을 생성한 후에는 인스턴스 `ARN`을 업데이트할 수 없습니다. ------ #### [ AWS Management Console ] **Lake Formation으로 기존 IAM Identity Center 연결을 업데이트하려면** 1. 에 로그인 AWS Management Console하고 [https://console.aws.amazon.com/lakeformation/](https://console.aws.amazon.com/lakeformation/) Lake Formation 콘솔을 엽니다. 1. 왼쪽 탐색 창에서 **IAM Identity Center 통합**을 선택합니다. 1. **IAM Identity Center 통합** 페이지에서 **추가**를 선택합니다. 1. 외부 계정이 데이터 카탈로그 리소스에 액세스할 수 있도록 하나 이상의 AWS 계정 IDs, 조직 IDs 및/또는 조직 단위 IDs를 입력합니다. 1. **애플리케이션 추가** 화면에서 Lake Formation과 통합하려는 타사 애플리케이션의 애플리케이션 ID를 입력합니다. 1. **추가**를 선택합니다. 1. (최적) **IAM Identity Center 통합** 페이지에서 Amazon Redshift 연결 또는 비활성화에 대해 신뢰할 수 있는 자격 증명 전파를 활성화할 수 있습니다. Lake Formation은 유효 권한을 기반으로 자격 증명을 다운스트림에 전파하므로 권한이 부여된 애플리케이션이 사용자를 대신하여 데이터에 액세스할 수 있습니다. ------ #### [ AWS CLI ] 다음 AWS CLI 명령을 실행하여 IAM Identity Center 통합을 위한 타사 애플리케이션을 추가하거나 제거할 수 있습니다. 외부 필터링 상태를 `ENABLED`로 설정하면 IAM Identity Center에서 타사 애플리케이션이 Lake Formation에서 관리하는 데이터에 액세스할 수 있도록 자격 증명 관리를 제공할 수 있습니다. 또한 애플리케이션 상태를 설정하여 IAM Identity Center 통합을 활성화하거나 비활성화할 수 있습니다. ``` aws lakeformation update-lake-formation-identity-center-configuration \ --external-filtering '{"AuthorizedTargets": ["", ""], "Status": "ENABLED"}'\ --share-recipients '[{"DataLakePrincipalIdentifier": "<444455556666>"} {"DataLakePrincipalIdentifier": "<777788889999>"}]' \ --application-status ENABLED ``` 기존 LF IDC 애플리케이션이 있지만 `Redshift:Connect` 권한 부여를 추가하려는 경우 다음을 사용하여 Lake Formation IDC 애플리케이션을 업데이트할 수 있습니다. 권한 부여는 활성화 또는 비활성화될 수 있습니다. ``` aws lakeformation update-lake-formation-identity-center-configuration \ --service-integrations '[{ "Redshift": [{ "RedshiftConnect": { "Authorization": "ENABLED" } }] }]' ``` ------ # IAM Identity Center와의 Lake Formation 연결 삭제 기존 IAM Identity Center 통합을 삭제하려면 Lake Formation 콘솔 AWS CLI또는 [DeleteLakeFormationIdentityCenterConfiguration](https://docs.aws.amazon.com/lake-formation/latest/APIReference/API_DeleteLakeFormationIdentityCenterConfiguration.html) 작업을 사용하여 삭제할 수 있습니다. ------ #### [ AWS Management Console ] **Lake Formation과의 기존 IAM Identity Center 연결을 삭제하려면** 1. 에 로그인 AWS Management Console하고 [https://console.aws.amazon.com/lakeformation/](https://console.aws.amazon.com/lakeformation/) Lake Formation 콘솔을 엽니다. 1. 왼쪽 탐색 창에서 **IAM Identity Center 통합**을 선택합니다. 1. **IAM Identity Center 통합** 페이지에서 **삭제**를 선택합니다. 1. **통합 확인** 화면에서 작업을 확인하고 **삭제**를 선택합니다. ------ #### [ AWS CLI ] 다음 AWS CLI 명령을 실행하여 IAM Identity Center 통합을 삭제할 수 있습니다. ``` aws lakeformation delete-lake-formation-identity-center-configuration \ --catalog-id <123456789012> ``` ------ # 사용자 및 그룹에 권한 부여 데이터 레이크 관리자는 IAM Identity Center 사용자 및 그룹에 데이터 카탈로그 리소스(데이터베이스, 테이블, 뷰)에 대한 권한을 부여하여 데이터에 쉽게 액세스하도록 할 수 있습니다. 데이터 레이크 권한을 부여하거나 취소하려면 부여자에게 다음과 같은 IAM Identity Center 작업에 대한 권한이 필요합니다. + [DescribeUser](https://docs.aws.amazon.com/singlesignon/latest/IdentityStoreAPIReference/API_DescribeUser.html) + [DescribeGroup](https://docs.aws.amazon.com/singlesignon/latest/IdentityStoreAPIReference/API_DescribeGroup.html) + [DescribeInstance](https://docs.aws.amazon.com/singlesignon/latest/APIReference/API_DescribeInstance.html) Lake Formation 콘솔, API 또는 AWS CLI를 사용하여 권한을 부여할 수 있습니다. 권한 부여에 대한 자세한 내용은 [데이터 카탈로그 리소스에 대한 권한 부여](granting-catalog-permissions.md) 섹션을 참조하세요. **참고** 계정의 리소스에 대한 권한만 부여할 수 있습니다. 공유된 리소스의 사용자 및 그룹에 권한을 캐스케이드하려면 AWS RAM 리소스 공유를 사용해야 합니다. ------ #### [ AWS Management Console ] **사용자 및 그룹에 권한을 부여하려면** 1. 에 로그인 AWS Management Console하고 [https://console.aws.amazon.com/lakeformation/](https://console.aws.amazon.com/lakeformation/) Lake Formation 콘솔을 엽니다. 1. Lake Formation 콘솔 탐색 창의 **권한**에서 **데이터 레이크 권한**을 선택합니다. 1. **허용**을 선택합니다. 1. **데이터 레이크 권한 부여** 페이지에서 **IAM Identity Center** 사용자 및 그룹을 선택합니다. 1. **추가**를 선택하여 권한을 부여할 사용자와 그룹을 선택합니다. ![\[IAM Identity Center 사용자 및 그룹을 선택한 상태에서 데이터 레이크 권한 부여 화면을 선택합니다.\]](http://docs.aws.amazon.com/ko_kr/lake-formation/latest/dg/images/identity-center-grant-perm.png) 1. **사용자 및 그룹 할당** 화면에서 권한을 부여할 사용자 및/또는 그룹을 선택합니다. **할당**을 선택합니다. ![\[IAM Identity Center 사용자 및 그룹을 선택한 상태에서 데이터 레이크 권한 부여 화면을 선택합니다.\]](http://docs.aws.amazon.com/ko_kr/lake-formation/latest/dg/images/identity-center-assign-users-groups.png) 1. 다음으로, 권한을 부여할 방법을 선택합니다. 명명된 리소스 방법을 사용하여 권한을 부여하는 방법에 대한 지침은 [명명된 리소스 메서드를 사용하여 데이터 권한 부여](granting-cat-perms-named-resource.md) 섹션을 참조하십시오. LF 태그를 사용하여 권한을 부여하는 방법에 대한 지침은 [LF-TBAC 방법을 사용하여 데이터 레이크 권한 부여](granting-catalog-perms-TBAC.md) 섹션을 참조하십시오. 1. 권한을 부여할 데이터 카탈로그 리소스를 선택합니다. 1. 부여할 데이터 카탈로그 권한을 선택합니다. 1. **허용**을 선택합니다. ------ #### [ AWS CLI ] 다음은 IAM Identity Center 사용자에게 테이블에 대한 `SELECT` 권한을 부여하는 방법을 나타낸 예제입니다. ``` aws lakeformation grant-permissions \ --principal DataLakePrincipalIdentifier=arn:aws:identitystore:::user/ \ --permissions "SELECT" \ --resource '{ "Table": { "DatabaseName": "retail", "TableWildcard": {} } }' ``` IAM Identity Center에서 `UserId`를 검색하려면 IAM Identity Center API 참조의 [GetUserId](https://docs.aws.amazon.com/singlesignon/latest/IdentityStoreAPIReference/API_GetUserId.html) 작업을 참조하십시오. ------ # CloudTrail 로그에 IAM Identity Center 사용자 컨텍스트 포함 Lake Formation은 [자격 증명 벤딩](using-cred-vending.md) 기능을 사용하여 Amazon S3 데이터에 대한 임시 액세스를 제공합니다. 기본적으로 IAM Identity Center 사용자가 통합 분석 서비스에 쿼리를 제출하면 CloudTrail 로그에는 서비스가 단기 액세스를 제공하기 위해 수임하는 IAM 역할만 포함됩니다. 사용자 정의 역할을 사용하여 Lake Formation에 Amazon S3 데이터 위치를 등록할 경우 CloudTrail 이벤트에 IAM Identity Center 사용자의 컨텍스트를 포함하도록 선택한 다음, 리소스에 액세스하는 사용자를 추적할 수 있습니다. **중요** CloudTrail에 객체 수준 Amazon S3 API 요청을 포함하려면 Amazon S3 버킷 및 객체에 대한 CloudTrail 이벤트 로깅을 활성화해야 합니다. 자세한 내용은 Amazon S3 사용 설명서의 [S3 버킷 및 객체에 대한 CloudTrail 이벤트 로깅 활성화](https://docs.aws.amazon.com/AmazonS3/latest/userguide/enable-cloudtrail-logging-for-s3.html) 섹션을 참조하세요. **사용자 정의 역할로 등록된 데이터 레이크 위치에서 자격 증명 벤딩 감사 활성화** 1. Lake Formation 콘솔([https://console.aws.amazon.com/lakeformation/](https://console.aws.amazon.com/lakeformation/))에 로그인합니다. 1. 왼쪽 탐색에서 **관리**를 펼치고 **데이터 카탈로그 설정**을 선택합니다. 1. **향상된 감사**에서 **제공된 컨텍스트 전파**를 선택합니다. 1. **저장**을 선택합니다. [PutDataLakeSettings](https://docs.aws.amazon.com/lake-formation/latest/APIReference/API_PutDataLakeSettings.html) 작업에서 `Parameters` 특성을 설정하여 향상된 감사 옵션을 활성화할 수도 있습니다. 기본적으로 `SET_CONTEXT"` 파라미터 값은 “true”로 설정됩니다. ``` { "DataLakeSettings": { "Parameters": {"SET_CONTEXT": "true"}, } } ``` 다음은 향상된 감사 옵션이 포함된 CloudTrail 이벤트의 발췌문입니다. 이 로그에는 IAM Identity Center 사용자의 세션 컨텍스트와 Amazon S3 데이터 위치에 액세스하기 위해 Lake Formation이 수임하는 사용자 정의 IAM 역할이 모두 포함됩니다. 다음 발췌문에서 `onBehalfOf` 파라미터를 참조하세요. ``` { "eventVersion":"1.09", "userIdentity":{ "type":"AssumedRole", "principalId":"AROAW7F7MOX4OYE6FLIFN:access-grants-e653760c-4e8b-44fd-94d9-309e035b75ab", "arn":"arn:aws:sts::123456789012:assumed-role/accessGrantsTestRole/access-grants-e653760c-4e8b-44fd-94d9-309e035b75ab", "accountId":"123456789012", "accessKeyId":"ASIAW7F7MOX4CQLD4JIZN", "sessionContext":{ "sessionIssuer":{ "type":"Role", "principalId":"AROAW7F7MOX4OYE6FLIFN", "arn":"arn:aws:iam::123456789012:role/accessGrantsTestRole", "accountId":"123456789012", "userName":"accessGrantsTestRole" }, "attributes":{ "creationDate":"2023-08-09T17:24:02Z", "mfaAuthenticated":"false" } }, "onBehalfOf":{ "userId": "", "identityStoreArn": "arn:aws:identitystore::" } }, "eventTime":"2023-08-09T17:25:43Z", "eventSource":"s3.amazonaws.com", "eventName":"GetObject", .... ``` # 데이터 레이크에 Amazon S3 위치 추가 데이터 위치를 데이터 레이크의 스토리지로 추가하려면 위치(**데이터 레이크 위치**)를에 *등록*합니다 AWS Lake Formation. 그런 다음 Lake Formation 권한을 사용하여이 위치와 위치의 기본 데이터를 가리키는 AWS Glue Data Catalog 객체에 대한 세분화된 액세스 제어를 수행할 수 있습니다. 또한 Lake Formation을 사용하면 하이브리드 액세스 모드에서 데이터 위치를 등록할 수 있으며 데이터 카탈로그의 데이터베이스 및 테이블에 대해 Lake Formation 권한을 선택적으로 활성화할 수 있는 유연성이 제공됩니다. 하이브리드 액세스 모드를 사용하면 다른 기존 사용자 또는 워크로드의 권한 정책을 중단하지 않고 특정 사용자 집합에 대해 Lake Formation 권한을 설정할 수 있는 증분 경로가 제공됩니다. 하이브리드 액세스 모드 설정에 대한 자세한 내용은 [하이브리드 액세스 모드](hybrid-access-mode.md) 섹션을 참조하세요. 위치를 등록하면 해당 Amazon S3 경로와 해당 경로 아래의 모든 폴더가 등록됩니다. 예를 들어 다음과 같은 Amazon S3 경로 조직이 있다고 가정합니다. `/mybucket/accounting/sales/` `S3://mybucket/accounting`을 등록하면 `sales` 폴더도 등록되어 Lake Formation 아래 관리됩니다. 위치 등록에 대한 자세한 내용은 [Underlying data access control](access-control-underlying-data.md#underlying-data-access-control) 섹션을 참조하세요. **참고** Lake Formation 권한은 정형 데이터(행과 열이 있는 테이블에 정렬)에 권장됩니다. 데이터에 객체 기반 비정형 데이터가 포함된 경우 Amazon S3 access grants를 사용하여 데이터 액세스를 관리하는 것을 고려해 보세요. **Topics** + [위치를 등록하는 데 사용되는 역할에 대한 요구 사항](registration-role.md) + [Amazon S3 위치 등록](register-location.md) + [암호화된 Amazon S3 위치 등록](register-encrypted.md) + [다른 AWS 계정에 Amazon S3 위치 등록](register-cross-account.md) + [AWS 계정 간에 암호화된 Amazon S3 위치 등록](register-cross-encrypted.md) + [Amazon S3 위치 등록 취소](unregister-location.md) # 위치를 등록하는 데 사용되는 역할에 대한 요구 사항 Amazon Simple Storage Service AWS Identity and Access Management (Amazon S3) 위치를 등록할 때 (IAM) 역할을 지정해야 합니다.는 해당 위치의 데이터에 액세스할 때 해당 역할을 AWS Lake Formation 수임합니다. 다음 역할 유형 중 하나를 사용하여 위치를 등록할 수 있습니다. + Lake Formation 서비스 연결 역할. 이 역할은 위치에 대해 필요한 권한을 부여합니다. 이 역할을 사용하는 것이 위치를 등록하는 가장 간단한 방법입니다. 자세한 내용은 [Lake Formation에 서비스 연결 역할 사용](service-linked-roles.md) 및 [서비스 연결 역할 제한 사항](service-linked-role-limitations.md) 섹션을 참조하세요. + 사용자 정의 역할. 서비스 연결 역할이 제공하는 것보다 더 많은 권한을 부여해야 하는 경우 사용자 정의 역할을 사용하세요. 다음과 같은 상황에서는 사용자 정의 역할을 사용해야 합니다. + 다른 계정에 위치를 등록하는 경우 자세한 내용은 [다른 AWS 계정에 Amazon S3 위치 등록](register-cross-account.md) 및 [AWS 계정 간에 암호화된 Amazon S3 위치 등록](register-cross-encrypted.md) 섹션을 참조하세요. + AWS 관리형 CMK(`aws/s3`)를 사용하여 Amazon S3 위치를 암호화하는 경우. 자세한 내용은 [암호화된 Amazon S3 위치 등록](register-encrypted.md) 단원을 참조하십시오. + Amazon EMR을 사용하여 위치에 액세스하려는 경우 서비스 연결 역할로 위치를 이미 등록한 상태에서 Amazon EMR로 위치에 액세스하려면 위치를 등록 취소하고 사용자 정의 역할로 다시 등록해야 합니다. 자세한 내용은 [Amazon S3 위치 등록 취소](unregister-location.md) 단원을 참조하십시오. # Lake Formation에 서비스 연결 역할 사용 AWS Lake Formation 는 AWS Identity and Access Management (IAM) *서비스 연결 역할을* 사용합니다. 서비스 연결 역할은 Lake Formation에 직접 연결된 고유한 유형의 IAM 역할입니다. 서비스 연결 역할은 Lake Formation에서 사전 정의하며 서비스가 사용자를 대신하여 다른 AWS 서비스를 호출하는 데 필요한 모든 권한을 포함합니다. 서비스 연결 역할을 사용하면 역할을 생성하고 필요한 권한을 수동으로 추가할 필요가 없으므로 Lake Formation을 더 쉽게 설정할 수 있습니다. Lake Formation은 서비스 연결 역할의 권한을 정의하며, 달리 정의하지 않는 한 Lake Formation만 해당 역할을 수행할 수 있습니다. 정의된 권한에는 신뢰 정책과 권한 정책이 포함되며, 이 권한 정책은 다른 IAM 엔터티에 연결할 수 없습니다. 이 서비스 연결 역할은 역할을 수행하기 위해 다음 서비스를 신뢰합니다. + `lakeformation.amazonaws.com` 계정 A에서 서비스 연결 역할을 사용하여 계정 B가 소유한 Amazon S3 위치를 등록하면 계정 B의 Amazon S3 버킷 정책(리소스 기반 정책)은 계정 A의 서비스 연결 역할에 대한 액세스 권한을 부여해야 합니다. 서비스 연결 역할을 사용하여 데이터 위치를 등록하는 방법에 대한 자세한 내용은 [서비스 연결 역할 제한 사항](service-linked-role-limitations.md) 섹션을 참조하세요. **참고** 서비스 제어 정책(SCP)은 서비스 연결 역할에 영향을 미치지 않습니다. 자세한 내용은 *AWS Organizations 사용 설명서*의 [서비스 제어 정책(SCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)을 참조하세요. ## Lake Formation의 서비스 연결 역할 권한 Lake Formation은 `AWSServiceRoleForLakeFormationDataAccess`라는 서비스 연결 역할을 사용합니다. 이 역할은 Lake Formation 통합 서비스(예: )가 등록된 위치에 액세스할 수 있도록 하는 Amazon Simple Storage Service(Amazon S3 Amazon Athena) 권한 세트를 제공합니다. 데이터 레이크 위치를 등록할 때는 해당 위치에 대한 필수 Amazon S3 읽기/쓰기 권한이 있는 역할을 제공해야 합니다. 필수 Amazon S3 권한이 있는 역할을 생성하는 대신 이 서비스 연결 역할을 사용할 수 있습니다. 경로를 등록할 역할로 서비스 연결 역할을 처음 지정하면 서비스 연결 역할과 새 IAM 정책이 자동으로 생성됩니다. Lake Formation은 인라인 정책에 경로를 추가하고 이 경로를 서비스 연결 역할에 연결합니다. 서비스 연결 역할에 후속 경로를 등록하면 Lake Formation이 기존 정책에 경로를 추가합니다. 데이터 레이크 관리자로 로그인한 상태에서 데이터 레이크 위치를 등록합니다. 그런 다음 IAM 콘솔에서 `AWSServiceRoleForLakeFormationDataAccess` 역할을 검색하고 연결된 정책을 확인합니다. 예를 들어 `s3://my-kinesis-test/logs` 위치를 등록하면 Lake Formation이 다음 인라인 정책을 생성한 후 `AWSServiceRoleForLakeFormationDataAccess`에 연결합니다. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "LakeFormationDataAccessPermissionsForS3", "Effect": "Allow", "Action": [ "s3:PutObject", "s3:GetObject", "s3:DeleteObject", "s3:AbortMultipartUpload", "s3:ListMultipartUploadParts" ], "Resource": [ "arn:aws:s3:::my-kinesis-test/logs/*" ] }, { "Sid": "LakeFormationDataAccessPermissionsForS3ListBucket", "Effect": "Allow", "Action": [ "s3:ListBucket", "s3:ListBucketMultipartUploads" ], "Resource": [ "arn:aws:s3:::my-kinesis-test" ] } ] } ``` ------ ## Lake Formation에 대한 서비스 연결 역할 생성 서비스 연결 역할은 수동으로 생성할 필요가 없습니다. AWS CLI, 또는 AWS API에서 Lake Formation AWS Management Console에 Amazon S3 위치를 등록하면 Lake Formation에서 서비스 연결 역할을 생성합니다. **중요** 이러한 서비스 연결 역할은 해당 역할이 지원하는 기능을 사용하는 다른 서비스에서 작업을 완료했을 경우 계정에 나타날 수 있습니다. 자세한 내용은 [내 IAM 계정에 표시되는 새 역할](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_roles.html#troubleshoot_roles_new-role-appeared)을 참조하십시오. 이 서비스 연결 역할을 삭제했다가 다시 생성해야 하는 경우 동일한 프로세스를 사용하여 계정에서 역할을 다시 생성할 수 있습니다. Lake Formation에 Amazon S3 위치를 등록하면 Lake Formation이 서비스 연결 역할을 다시 생성합니다. IAM 콘솔을 사용하여 **Lake Formation** 사용 사례로 서비스 연결 역할을 생성할 수도 있습니다. AWS CLI 또는 AWS API에서 서비스 이름을 사용하여 `lakeformation.amazonaws.com` 서비스 연결 역할을 생성합니다. 자세한 내용은 *IAM 사용자 설명서*의 [서비스 연결 역할 생성](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#create-service-linked-role) 섹션을 참조하세요. 이 서비스 연결 역할을 삭제하면 동일한 프로세스를 사용하여 역할을 다시 생성할 수 있습니다. ## Lake Formation에 대한 서비스 연결 역할 편집 Lake Formation에서는 `AWSServiceRoleForLakeFormationDataAccess` 서비스 연결 역할을 편집하도록 허용하지 않습니다. 서비스 연결 역할을 생성한 후에는 다양한 개체가 역할을 참조할 수 있기 때문에 역할 이름을 변경할 수 없습니다. 하지만 IAM을 사용하여 역할의 설명을 편집할 수 있습니다. 자세한 내용은 IAM 사용 설명서**의 [서비스 연결 역할 편집](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role)을 참조하세요. ## Lake Formation에 대한 서비스 연결 역할 삭제 서비스 연결 역할이 필요한 기능 또는 서비스가 더 이상 필요 없는 경우에는 해당 역할을 삭제하는 것이 좋습니다. 따라서 적극적으로 모니터링하거나 유지하지 않는 미사용 엔터티가 없도록 합니다. 단, 서비스 연결 역할에 대한 리소스를 먼저 정리해야 수동으로 삭제할 수 있습니다. **참고** 리소스를 삭제하려 할 때 Lake Formation 서비스가 역할을 사용 중이면 삭제에 실패할 수 있습니다. 이 문제가 발생하면 몇 분 기다렸다가 작업을 다시 시도하세요. **Lake Formation에서 사용하는 Lake Formation 리소스 삭제** + 서비스 연결 역할을 사용하여 Lake Formation에 Amazon S3 위치를 등록한 경우 서비스 연결 역할을 삭제하기 전에 위치를 등록 취소하고 사용자 지정 역할을 사용하여 다시 등록해야 합니다. **IAM을 사용하여 수동으로 서비스 연결 역할을 삭제하려면 다음을 수행하세요.** IAM 콘솔 AWS CLI, 또는 AWS API를 사용하여 `AWSServiceRoleForLakeFormationDataAccess` 서비스 연결 역할을 삭제합니다. 자세한 내용은 IAM 사용 설명서**의 [서비스 연결 역할 삭제](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role)를 참조하세요. 사용자 정의 역할의 요구 사항은 다음과 같습니다. + 새 역할을 생성할 때 IAM 콘솔의 **역할 생성** 페이지에서 **AWS 서비스**를 선택한 다음 **사용 사례 선택**에서 **Lake Formation**을 선택합니다. 다른 경로를 사용하여 역할을 생성하는 경우 해당 역할이 `lakeformation.amazonaws.com`과 신뢰 관계가 있는지 확인합니다. 자세한 내용은 [역할 신뢰 정책 수정(콘솔)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_update-role-trust-policy.html)을 참조하세요. + 역할에는 위치에 대한 Amazon S3 읽기/쓰기 권한을 부여하는 인라인 정책이 있어야 합니다. 다음은 일반적인 정책입니다. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:PutObject", "s3:GetObject", "s3:DeleteObject" ], "Resource": [ "arn:aws:s3:::awsexamplebucket/*" ] }, { "Effect": "Allow", "Action": [ "s3:ListBucket" ], "Resource": [ "arn:aws:s3:::awsexamplebucket" ] } ] } ``` ------ + Lake Formation 서비스가 역할을 수임하고 통합 분석 엔진에 임시 자격 증명을 제공할 수 있도록 IAM 역할에 다음 신뢰 정책을 추가합니다. CloudTrail 로그에 IAM Identity Center 사용자 컨텍스트를 포함하려면 신뢰 정책에 `sts:SetContext` 작업에 대한 권한이 있어야 합니다. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "DataCatalogViewDefinerAssumeRole1", "Effect": "Allow", "Principal": { "Service": [ "lakeformation.amazonaws.com" ] }, "Action": [ "sts:AssumeRole", "sts:SetContext" ] } ] } ``` ------ + 위치를 등록하는 데이터 레이크 관리자에게는 역할에 대한 `iam:PassRole` 권한이 있어야 합니다. 다음은 이 권한을 부여하는 인라인 정책입니다. **를 유효한 AWS 계정 번호로 바꾸고 **을 역할 이름으로 바꿉니다. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "PassRolePermissions", "Effect": "Allow", "Action": [ "iam:PassRole" ], "Resource": [ "arn:aws:iam::111122223333:role/" ] } ] } ``` ------ + Lake Formation이 CloudWatch Logs에 로그를 추가하고 지표를 게시하도록 허용하려면 다음 인라인 정책을 추가합니다. **참고** CloudWatch Logs에 기록하면 요금이 발생합니다. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "Sid1", "Effect": "Allow", "Action": [ "logs:CreateLogStream", "logs:CreateLogGroup", "logs:PutLogEvents" ], "Resource": [ "arn:aws:logs:us-east-1:111122223333:log-group:/aws-lakeformation-acceleration/*", "arn:aws:logs:us-east-1:111122223333:log-group:/aws-lakeformation-acceleration/*:log-stream:*" ] } ] } ``` ------ # Amazon S3 위치 등록 Amazon Simple Storage Service AWS Identity and Access Management (Amazon S3) 위치를 등록할 때 (IAM) 역할을 지정해야 합니다. Lake Formation은 해당 위치의 데이터에 액세스하는 통합 AWS 서비스에 임시 자격 증명을 부여할 때 해당 역할을 수임합니다. **중요** **요청자 지불**이 활성화된 Amazon S3 버킷은 등록하지 마세요. Lake Formation에 등록된 버킷의 경우 버킷 등록에 사용된 역할은 항상 요청자로 표시됩니다. 다른 AWS 계정에서 버킷에 액세스하는 경우 역할이 버킷 소유자와 동일한 계정에 속하는 경우 버킷 소유자에게 데이터 액세스 요금이 부과됩니다. AWS Lake Formation 콘솔, Lake Formation API 또는 AWS Command Line Interface (AWS CLI)를 사용하여 Amazon S3 위치를 등록할 수 있습니다. **시작하기 전 준비 사항** [위치를 등록하는 데 사용되는 역할에 대한 요구 사항](registration-role.md)을 검토합니다. **위치를 등록하려면(콘솔)** **중요** 다음 절차에서는 Amazon S3 위치가 데이터 카탈로그와 동일한 AWS 계정에 있고 해당 위치의 데이터가 암호화되지 않았다고 가정합니다. 이 장의 다른 섹션에서는 교차 계정 등록 및 암호화된 위치 등록에 대해 다룹니다. 1. [https://console.aws.amazon.com/lakeformation/](https://console.aws.amazon.com/lakeformation/) AWS Lake Formation 콘솔을 엽니다. 데이터 레이크 관리자 또는 `lakeformation:RegisterResource` IAM 권한이 있는 사용자로 로그인합니다. 1. 탐색 창의 **관리**에서 **데이터 레이크 위치**를 선택합니다. 1. **위치 등록**을 선택한 다음 **찾아보기**를 선택하고 Amazon Simple Storage Service(S3) 경로를 선택합니다. 1. (선택 사항이지만 강력히 권장됨) 선택한 Amazon S3 위치에 있는 모든 기존 리소스 및 해당 권한의 목록을 보려면 **위치 권한 검토**를 선택합니다. 선택한 위치를 등록하면 Lake Formation 사용자가 해당 위치에 이미 있는 데이터에 액세스할 수 있습니다. 이 목록을 보면 기존 데이터를 안전하게 유지하는 데 도움이 됩니다. 1. **IAM 역할**의 경우 `AWSServiceRoleForLakeFormationDataAccess` 서비스 연결 역할(기본값) 또는 [위치를 등록하는 데 사용되는 역할에 대한 요구 사항](registration-role.md)의 요구 사항을 충족하는 사용자 지정 IAM 역할을 선택합니다. 사용자 지정 IAM 역할을 사용하여 등록한 경우에만 등록된 위치 또는 기타 세부 정보를 업데이트할 수 있습니다. 서비스 연결 역할을 사용하여 등록된 위치를 편집하려면 위치를 등록 취소하고 다시 등록해야 합니다. 1. Lake Formation이 역할을 수임하고 통합 AWS 서비스에 임시 자격 증명을 벤딩하여 **페더레이션 데이터베이스의 테이블에 액세스할 수 있도록 하려면 데이터 카탈로그 페더레이션 활성화** 옵션을 선택합니다. 위치가 Lake Formation에 등록되어 있고 페더레이션된 데이터베이스의 테이블에 동일한 위치를 사용하려면 **데이터 카탈로그 페더레이션 활성화** 옵션을 사용하여 동일한 위치를 등록해야 합니다. 1. **하이브리드 액세스 모드**를 선택하여 Lake Formation 권한을 기본적으로 활성화하지 않도록 설정합니다. 하이브리드 액세스 모드에서 Amazon S3 위치를 등록하면 해당 위치 아래의 데이터베이스 및 테이블에 대한 보안 주체를 선택하여 Lake Formation 권한을 활성화할 수 있습니다.
 하이브리드 액세스 모드 설정에 대한 자세한 내용은 [하이브리드 액세스 모드](hybrid-access-mode.md) 섹션을 참조하세요. 1. **위치 등록**을 선택합니다. **위치를 등록하려면(AWS CLI)** 1. **Lake Formation에 새로운 위치를 등록합니다.** 이 예제는 서비스 연결 역할을 사용하여 위치를 등록합니다. 대신 `--role-arn` 인수를 사용하여 사용자 고유의 역할을 제공할 수 있습니다. **를 유효한 Amazon S3 경로로, 계정 번호를 유효한 AWS 계정으로, **을 데이터 위치를 등록할 권한이 있는 IAM 역할로 바꿉니다. **참고** 서비스 연결 역할을 사용하여 등록한 경우 등록된 위치의 속성을 편집할 수 없습니다. ``` aws lakeformation register-resource \ --resource-arn arn:aws:s3::: \ --use-service-linked-role ``` 다음 예에서는 사용자 지정 역할을 사용하여 위치를 등록합니다. ``` aws lakeformation register-resource \ --resource-arn arn:aws:s3::: \ --role-arn arn:aws:iam::<123456789012>:role/ ``` 1. **Lake Formation에 등록된 위치를 업데이트하려면** 사용자 지정 IAM 역할을 사용하여 등록한 경우에만 등록된 위치를 편집할 수 있습니다. 서비스 연결 역할로 등록된 위치의 경우 위치를 등록 취소하고 다시 등록해야 합니다. 자세한 내용은 [Amazon S3 위치 등록 취소](unregister-location.md) 단원을 참조하십시오. ``` aws lakeformation update-resource \ --role-arn arn:aws:iam::<123456789012>:role/\ --resource-arn arn:aws:s3::: ``` ``` aws lakeformation update-resource \ --resource-arn arn:aws:s3::: \ --use-service-linked-role ``` 1. **페더레이션을 사용하여 하이브리드 액세스 모드에서 데이터 위치 등록** ``` aws lakeformation register-resource \ --resource-arn arn:aws:s3::: \ --role-arn arn:aws:iam::<123456789012>:role/ \ --hybrid-access-enabled ``` ``` aws lakeformation register-resource \ --resource-arn arn:aws:s3::: \ --role-arn arn:aws:iam::<123456789012>:role/ \ --with-federation ``` ``` aws lakeformation update-resource \ --resource-arn arn:aws:s3::: \ --role-arn arn:aws:iam::<123456789012>:role/ \ --hybrid-access-enabled ``` 자세한 내용은 [RegisterResource](https://docs.aws.amazon.com/lake-formation/latest/APIReference/API_RegisterResource.html) API 작업을 참조하세요. **참고** Amazon S3 위치를 등록하면 위치(또는 하위 위치)를 가리키는 AWS Glue 테이블은 `GetTable` 호출`true`에서와 같이 `IsRegisteredWithLakeFormation` 파라미터 값을 반환합니다. `GetTables` 및 `SearchTables`와 같은 데이터 카탈로그 API 작업은 `IsRegisteredWithLakeFormation` 파리미터 값을 업데이트하지 않고 기본값인 false를 반환한다는 알려진 제한 사항이 있습니다. `IsRegisteredWithLakeFormation` 파라미터의 올바른 값을 보려면 `GetTable` API를 사용하는 것이 좋습니다. # 암호화된 Amazon S3 위치 등록 Lake Formation은 [AWS Key Management Service](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html)(AWS KMS)와 통합되어 다른 통합 서비스를 더 쉽게 설정하고 Amazon Simple Storage Service(S3) 위치에서 데이터를 암호화하고 해독할 수 있습니다. 고객 관리형 AWS KMS keys 및 AWS 관리형 키 가 모두 지원됩니다. 현재 클라이언트 측 암호화 및 해독은 Athena에서만 지원됩니다. Amazon S3 위치를 등록할 때 AWS Identity and Access Management (IAM) 역할을 지정해야 합니다. 암호화된 Amazon S3 위치의 경우 역할에 로 데이터를 암호화 및 해독할 수 있는 권한이 AWS KMS key있거나 KMS 키 정책이 역할에 키에 대한 권한을 부여해야 합니다. **중요** **요청자 지불**이 활성화된 Amazon S3 버킷은 등록하지 마세요. Lake Formation에 등록된 버킷의 경우 버킷 등록에 사용된 역할은 항상 요청자로 표시됩니다. 다른 AWS 계정에서 버킷에 액세스하는 경우 역할이 버킷 소유자와 동일한 계정에 속하는 경우 버킷 소유자에게 데이터 액세스 요금이 부과됩니다. Lake Formation은 서비스 연결 역할을 사용하여 데이터 위치를 등록합니다. 그러나 이 역할에는 몇 가지 [제한 사항](service-linked-role-limitations.md)이 있습니다. 이러한 제약 조건으로 인해 유연성과 제어 수준을 높이려면 사용자 지정 IAM 역할을 생성하고 사용하는 것이 좋습니다. 위치를 등록하기 위해 생성하는 사용자 지정 역할은 [위치를 등록하는 데 사용되는 역할에 대한 요구 사항](registration-role.md)에 지정된 요구 사항을 충족해야 합니다. **중요** AWS 관리형 키 를 사용하여 Amazon S3 위치를 암호화하는 경우 Lake Formation 서비스 연결 역할을 사용할 수 없습니다. 사용자 지정 역할을 사용하고 키에 대한 IAM 권한을 역할에 추가해야 합니다. 자세한 내용은 이 섹션의 뒷부분에서 설명합니다. 다음 절차는 고객 관리형 키 또는 AWS 관리형 키로 암호화된 Amazon S3 위치를 등록하는 방법을 설명합니다. + [고객 관리형 키로 암호화된 위치 등록](#proc-register-cust-cmk) + [로 암호화된 위치 등록 AWS 관리형 키](#proc-register-aws-cmk) **시작하기 전** [위치를 등록하는 데 사용되는 역할에 대한 요구 사항](registration-role.md)을 검토합니다. **고객 관리형 키로 암호화된 Amazon S3 위치를 등록하려면** **참고** KMS 키 또는 Amazon S3 위치가 데이터 카탈로그와 동일한 AWS 계정에 있지 않은 경우 [AWS 계정 간에 암호화된 Amazon S3 위치 등록](register-cross-encrypted.md) 대신의 지침을 따릅니다. 1. [https://console.aws.amazon.com/kms](https://console.aws.amazon.com/kms) AWS KMS 콘솔을 열고 AWS Identity and Access Management (IAM) 관리 사용자 또는 위치를 암호화하는 데 사용되는 KMS 키의 키 정책을 수정할 수 있는 사용자로 로그인합니다. 1. 탐색 창에서 **고객 관리형 키**를 선택한 다음 원하는 KMS 키의 이름을 선택합니다. 1. KMS 키 세부 정보 페이지에서 **키 정책** 탭을 선택한 다음 다음 중 하나를 수행하여 사용자 지정 역할 또는 Lake Formation 서비스 연결 역할을 KMS 키 사용자로 추가합니다. + **기본 보기가 표시되는 경우**(**키 관리자**, **키 삭제**, **키 사용자** 및 **기타 AWS 계정** 섹션 포함) - **키 사용자** 섹션에서 사용자 지정 역할 또는 Lake Formation 서비스 연결 역할을 추가합니다`AWSServiceRoleForLakeFormationDataAccess`. + **키 정책(JSON) 이 표시되는 경우** - 다음 예제와 같이 정책을 편집하여 사용자 지정 역할 또는 Lake Formation 서비스 연결 역할 `AWSServiceRoleForLakeFormationDataAccess`를 '키 사용 허용' 객체에 추가합니다. **참고** 해당 객체가 없는 경우 예제에 표시된 권한과 함께 추가하세요. 예제에서는 서비스 연결 역할을 사용합니다. ``` ... { "Sid": "Allow use of the key", "Effect": "Allow", "Principal": { "AWS": [ "arn:aws:iam::111122223333:role/aws-service-role/lakeformation.amazonaws.com/AWSServiceRoleForLakeFormationDataAccess", "arn:aws:iam::111122223333:user/keyuser" ] }, "Action": [ "kms:Encrypt", "kms:Decrypt", "kms:ReEncrypt*", "kms:GenerateDataKey*", "kms:DescribeKey" ], "Resource": "*" }, ... ``` 1. [https://console.aws.amazon.com/lakeformation/](https://console.aws.amazon.com/lakeformation/) AWS Lake Formation 콘솔을 엽니다. 데이터 레이크 관리자 또는 `lakeformation:RegisterResource` IAM 권한이 있는 사용자로 로그인합니다. 1. 탐색 창의 **관리**에서 **데이터 레이크 위치**를 선택합니다. 1. **위치 등록**을 선택한 다음 **찾아보기**를 선택하고 Amazon Simple Storage Service(S3) 경로를 선택합니다. 1. (선택 사항이지만 강력히 권장됨) 선택한 Amazon S3 위치에 있는 모든 기존 리소스 및 해당 권한의 목록을 보려면 **위치 권한 검토**를 선택합니다. 선택한 위치를 등록하면 Lake Formation 사용자가 해당 위치에 이미 있는 데이터에 액세스할 수 있습니다. 이 목록을 보면 기존 데이터를 안전하게 유지하는 데 도움이 됩니다. 1. **IAM 역할**의 경우 `AWSServiceRoleForLakeFormationDataAccess` 서비스 연결 역할(기본값) 또는 [위치를 등록하는 데 사용되는 역할에 대한 요구 사항](registration-role.md)을 충족하는 사용자 지정 IAM 역할을 선택합니다. 1. **위치 등록**을 선택합니다. 서비스 링크 역할에 대한 자세한 내용은 [Lake Formation의 서비스 연결 역할 권한](service-linked-roles.md#service-linked-role-permissions)을(를) 참조하세요. **로 암호화된 Amazon S3 위치를 등록하려면 AWS 관리형 키** **중요** Amazon S3 위치가 데이터 카탈로그와 동일한 AWS 계정에 있지 않은 경우 [AWS 계정 간에 암호화된 Amazon S3 위치 등록](register-cross-encrypted.md) 대신의 지침을 따르세요. 1. 위치를 등록하는 데 사용할 IAM 역할을 생성합니다. [위치를 등록하는 데 사용되는 역할에 대한 요구 사항](registration-role.md)에 나열된 요구 사항을 충족하는지 확인합니다. 1. 다음 인라인 정책을 역할에 추가합니다. 역할에 키에 대한 권한을 부여합니다. `Resource` 사양은 AWS 관리형 키의 Amazon 리소스 이름(ARN)을 지정해야 합니다. AWS KMS 콘솔에서 ARN을 가져올 수 있습니다. 올바른 ARN을 가져오려면 위치를 암호화하는 데 AWS 관리형 키 사용된와 동일한 AWS 계정 및 리전으로 AWS KMS 콘솔에 로그인해야 합니다. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "kms:Encrypt", "kms:Decrypt", "kms:ReEncrypt*", "kms:GenerateDataKey*", "kms:DescribeKey" ], "Resource": "arn:aws:kms:us-east-1:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab" } ] } ``` ------ 키 ID - `arn:aws:kms:region:account-id:key/alias/your-key-alias` 대신 KMS 키 별칭을 사용할 수 있습니다. 자세한 내용은 AWS Key Management Service 개발자 안내서의 섹션의 [별칭 AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/kms-alias.html)을 참조하세요. 1. [https://console.aws.amazon.com/lakeformation/](https://console.aws.amazon.com/lakeformation/) AWS Lake Formation 콘솔을 엽니다. 데이터 레이크 관리자 또는 `lakeformation:RegisterResource` IAM 권한이 있는 사용자로 로그인합니다. 1. 탐색 창의 **관리**에서 **데이터 레이크 위치**를 선택합니다. 1. **위치 등록**을 선택한 다음 **찾아보기**를 선택하고 Amazon S3 경로를 선택합니다. 1. (선택 사항이지만 강력히 권장됨) 선택한 Amazon S3 위치에 있는 모든 기존 리소스 및 해당 권한의 목록을 보려면 **위치 권한 검토**를 선택합니다. 선택한 위치를 등록하면 Lake Formation 사용자가 해당 위치에 이미 있는 데이터에 액세스할 수 있습니다. 이 목록을 보면 기존 데이터를 안전하게 유지하는 데 도움이 됩니다. 1. **IAM 역할**의 경우, 1단계에서 생성한 역할을 선택합니다. 1. **위치 등록**을 선택합니다. # 다른 AWS 계정에 Amazon S3 위치 등록 AWS Lake Formation 를 사용하면 AWS 계정 간에 Amazon Simple Storage Service(Amazon S3) 위치를 등록할 수 있습니다. 예를 들어 AWS Glue Data Catalog 가 계정 A에 있는 경우 계정 A의 사용자는 계정 B에 Amazon S3 버킷을 등록할 수 있습니다. AWS 계정 A의 AWS Identity and Access Management (IAM) 역할을 사용하여 계정 B에 AWS Amazon S3 버킷을 등록하려면 다음 권한이 필요합니다. + 계정 A의 역할은 계정 B의 버킷에 대한 권한을 부여해야 합니다. + 계정 B의 버킷 정책은 계정 A의 역할에 대해 액세스 권한을 부여해야 합니다. **중요** **요청자 지불**이 활성화된 Amazon S3 버킷은 등록하지 마세요. Lake Formation에 등록된 버킷의 경우 버킷 등록에 사용된 역할은 항상 요청자로 표시됩니다. 다른 AWS 계정에서 버킷에 액세스하는 경우 역할이 버킷 소유자와 동일한 계정에 속하는 경우 버킷 소유자에게 데이터 액세스 요금이 부과됩니다. Lake Formation 서비스 연결 역할을 사용하여 다른 계정에 위치를 등록할 수 없습니다. 대신 사용자 정의 역할을 사용해야 합니다. 역할은 [위치를 등록하는 데 사용되는 역할에 대한 요구 사항](registration-role.md)의 요구 사항을 충족해야 합니다. 서비스 링크 역할에 대한 자세한 내용은 [Lake Formation의 서비스 연결 역할 권한](service-linked-roles.md#service-linked-role-permissions)을(를) 참조하세요. **시작하기 전 준비 사항** [위치를 등록하는 데 사용되는 역할에 대한 요구 사항](registration-role.md)을 검토합니다. **다른 AWS 계정에 위치를 등록하려면** **참고** 위치가 암호화된 경우 대신 [AWS 계정 간에 암호화된 Amazon S3 위치 등록](register-cross-encrypted.md)의 지침을 따르세요. 다음 절차에서는 데이터 카탈로그를 포함하는 계정 1111-2222-3333의 보안 주체가 계정 1234-5678-9012에 있는 Amazon S3 버킷 `awsexamplebucket1`을 등록하려고 한다고 가정합니다. 1. 계정 1111-2222-3333에서에 로그인 AWS Management Console 하고에서 IAM 콘솔을 엽니다[https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/). 1. [위치를 등록하는 데 사용되는 역할에 대한 요구 사항](registration-role.md)의 요구 사항을 충족하는 새 역할을 생성하거나 기존 역할을 봅니다. 이 역할은 `awsexamplebucket1`에 대해 Amazon S3 권한을 부여해야 합니다. 1. [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)에서 S3 콘솔을 엽니다. 계정 1234-5678-9012로 로그인합니다. 1. **버킷 이름** 목록에서 버킷 이름 `awsexamplebucket1`을 선택합니다. 1. **권한**을 선택합니다. 1. **권한** 페이지에서 **버킷 정책**을 선택합니다. 1. **버킷 정책 편집기**에 다음 정책을 붙여 넣습니다. **을 역할 이름으로 바꿉니다. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect":"Allow", "Principal": { "AWS":"arn:aws:iam::111122223333:role/" }, "Action":"s3:ListBucket", "Resource":"arn:aws:s3:::awsexamplebucket1" }, { "Effect":"Allow", "Principal": { "AWS":"arn:aws:iam::111122223333:role/" }, "Action": [ "s3:DeleteObject", "s3:GetObject", "s3:PutObject" ], "Resource":"arn:aws:s3:::awsexamplebucket1/*" } ] } ``` ------ 1. **저장**을 선택합니다. 1. [https://console.aws.amazon.com/lakeformation/](https://console.aws.amazon.com/lakeformation/) AWS Lake Formation 콘솔을 엽니다. 데이터 레이크 관리자 또는 위치를 등록할 수 있는 충분한 권한이 있는 사용자로 계정 1111-2222-3333에 로그인합니다. 1. 탐색 창의 **관리**에서 **데이터 레이크 위치**를 선택합니다. 1. **데이터 레이크 위치** 페이지에서 **위치 등록**을 선택합니다. 1. **위치 등록 페이지**에서 **Amazon S3 경로**에 버킷 이름 `s3://awsexamplebucket1`을 입력합니다. **참고** **찾아보기**를 선택하면 교차 계정 버킷이 목록에 나타나지 않으므로 버킷 이름을 입력해야 합니다. 1. **IAM 역할**에서 역할을 선택합니다. 1. **위치 등록**을 선택합니다. # AWS 계정 간에 암호화된 Amazon S3 위치 등록 AWS Lake Formation 는 [AWS Key Management Service](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html) (AWS KMS)와 통합되어 Amazon Simple Storage Service(Amazon S3) 위치에서 데이터를 암호화하고 해독하도록 다른 통합 서비스를 보다 쉽게 설정할 수 있습니다. 고객 관리형 키와 AWS 관리형 키 가 모두 지원됩니다. 클라이언트 측 암호화/암호 해독은 지원되지 않습니다. **중요** **요청자 지불**이 활성화된 Amazon S3 버킷은 등록하지 마세요. Lake Formation에 등록된 버킷의 경우 버킷 등록에 사용된 역할은 항상 요청자로 표시됩니다. 다른 AWS 계정에서 버킷에 액세스하는 경우 역할이 버킷 소유자와 동일한 계정에 속하는 경우 버킷 소유자에게 데이터 액세스 요금이 부과됩니다. 이 섹션에서는 다음과 같은 상황에서 Amazon S3 위치를 등록하는 방법에 대해 설명합니다. + Amazon S3 위치의 데이터가 AWS KMS에서 생성된 KMS 키로 암호화됩니다. + Amazon S3 위치가와 동일한 AWS 계정에 있지 않습니다 AWS Glue Data Catalog. + KMS 키는 데이터 카탈로그와 동일한 AWS 계정에 있거나 없습니다. AWS 계정 A의 (IAM) 역할을 사용하여 AWS 계정 B에 AWS KMS암호화된 Amazon S3 버킷을 AWS Identity and Access Management 등록하려면 다음 권한이 필요합니다. + 계정 A의 역할은 계정 B의 버킷에 대한 권한을 부여해야 합니다. + 계정 B의 버킷 정책은 계정 A의 역할에 대해 액세스 권한을 부여해야 합니다. + KMS 키가 계정 B에 있는 경우 키 정책은 계정 A의 역할에 대한 액세스 권한을 부여하고, 계정 A의 역할은 KMS 키에 대한 권한을 부여해야 합니다. 다음 절차에서는 데이터 카탈로그가 포함된 AWS 계정에서 역할을 생성합니다(이전 설명의 계정 A). 그런 다음 이 역할을 사용하여 위치를 등록합니다. Lake Formation은 Amazon S3의 기본 데이터에 액세스할 때 이 역할을 맡습니다. 맡은 역할에는 KMS 키에 대한 필수 권한이 있습니다. 따라서 ETL 작업이나 Amazon Athena와 같은 통합 서비스를 통해 기본 데이터에 액세스하는 보안 주체에 KMS 키에 대한 권한을 부여하지 않아도 됩니다. **중요** Lake Formation 서비스 연결 역할을 사용하여 다른 계정에 위치를 등록할 수 없습니다. 대신 사용자 정의 역할을 사용해야 합니다. 역할은 [위치를 등록하는 데 사용되는 역할에 대한 요구 사항](registration-role.md)의 요구 사항을 충족해야 합니다. 서비스 링크 역할에 대한 자세한 내용은 [Lake Formation의 서비스 연결 역할 권한](service-linked-roles.md#service-linked-role-permissions)을(를) 참조하세요. **시작하기 전** [위치를 등록하는 데 사용되는 역할에 대한 요구 사항](registration-role.md)을 검토합니다. **AWS 계정 간에 암호화된 Amazon S3 위치를 등록하려면** 1. 데이터 카탈로그와 동일한 AWS 계정에서에 로그인 AWS Management Console 하고에서 IAM 콘솔을 엽니다[https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/). 1. [위치를 등록하는 데 사용되는 역할에 대한 요구 사항](registration-role.md)의 요구 사항을 충족하는 새 역할을 생성하거나 기존 역할을 봅니다. 이 역할은 위치에 대한 Amazon S3 권한을 부여하는 정책을 포함해야 합니다. 1. KMS 키가 데이터 카탈로그와 동일한 계정에 있지 않은 경우 KMS 키에 필요한 권한을 부여하는 인라인 정책을 역할에 추가합니다. 다음은 예제 정책입니다. 리전 및 계정 ID를 KMS 키의 리전 및 계정 번호로 바꿉니다. **를 키 ID로 바꿉니다. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "kms:Encrypt", "kms:Decrypt", "kms:ReEncrypt*", "kms:GenerateDataKey*", "kms:DescribeKey" ], "Resource": "arn:aws:kms:us-east-1:111122223333:key/" } ] } ``` ------ 1. Amazon S3 콘솔에서 역할에 필요한 Amazon S3 권한을 부여하는 버킷 정책을 추가합니다. 다음은 버킷 정책의 예입니다. 계정 ID를 Data Catalog의 AWS 계정 번호로, **을 역할 이름으로, **을 버킷 이름으로 바꿉니다. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect":"Allow", "Principal": { "AWS":"arn:aws:iam::111122223333:role/" }, "Action":"s3:ListBucket", "Resource":"arn:aws:s3:::" }, { "Effect":"Allow", "Principal": { "AWS":"arn:aws:iam::111122223333:role/" }, "Action": [ "s3:DeleteObject", "s3:GetObject", "s3:PutObject" ], "Resource":"arn:aws:s3:::/*" } ] } ``` ------ 1. 에서 역할을 KMS 키의 사용자로 AWS KMS추가합니다. 1. [https://console.aws.amazon.com/kms](https://console.aws.amazon.com/kms) AWS KMS 콘솔을 엽니다. 그런 다음 관리자 사용자 또는 위치를 암호화하는 데 사용된 KMS 키의 키 정책을 수정할 수 있는 사용자로 로그인합니다. 1. 탐색 창에서 **고객 관리형 키**를 선택한 다음 KMS 키의 이름을 선택합니다. 1. KMS 키 세부 정보 페이지의 **키 정책** 탭에서 키 정책의 JSON 보기가 표시되지 않는 경우 **정책 보기로 전환**을 선택합니다. 1. **키 정책** 섹션에서 **편집**을 선택하고 다음 예제와 같이 역할의 Amazon 리소스 이름(ARN)을 `Allow use of the key` 객체에 추가합니다. **참고** 해당 객체가 없는 경우 예제에 표시된 권한과 함께 추가하세요. ``` ... { "Sid": "Allow use of the key", "Effect": "Allow", "Principal": { "AWS": [ "arn:aws:iam:::role/" ] }, "Action": [ "kms:Encrypt", "kms:Decrypt", "kms:ReEncrypt*", "kms:GenerateDataKey*", "kms:DescribeKey" ], "Resource": "*" }, ... ``` 자세한 내용은AWS Key Management Service 개발자 안내서의 [다른 계정의 사용자가 KMS 키를 사용하도록 허용](https://docs.amazonaws.cn/en_us/kms/latest/developerguide/key-policy-modifying-external-accounts.html)을 참조하세요.** 1. [https://console.aws.amazon.com/lakeformation/](https://console.aws.amazon.com/lakeformation/) AWS Lake Formation 콘솔을 엽니다. 데이터 카탈로그 AWS 계정에 데이터 레이크 관리자로 로그인합니다. 1. 탐색 창의 **관리**에서 **데이터 레이크 위치**를 선택합니다. 1. **위치 등록**을 선택합니다. 1. **위치 등록 페이지**에서 **Amazon S3 경로**에 위치 경로를 **s3://**/****로 입력합니다. **을 버킷 이름으로 바꾸고 **를 위치의 나머지 경로로 바꿉니다. **참고** **찾아보기**를 선택하면 교차 계정 버킷이 목록에 나타나지 않으므로 경로를 입력해야 합니다. 1. **IAM 역할**의 경우 2단계의 역할을 선택합니다. 1. **위치 등록**을 선택합니다. # Amazon S3 위치 등록 취소 더 이상 Lake Formation에서 위치를 관리하지 않으려는 경우 Amazon Simple Storage Service(S3) 위치 등록을 취소할 수 있습니다. 위치 등록을 취소해도 해당 위치에 부여된 Lake Formation 데이터 위치 권한에는 영향을 미치지 않습니다. 등록 취소한 위치를 다시 등록할 수 있으며 데이터 위치 권한은 계속 유효합니다. 다른 역할을 사용하여 위치를 다시 등록할 수 있습니다. **위치를 등록 취소하려면(콘솔)** 1. [https://console.aws.amazon.com/lakeformation/](https://console.aws.amazon.com/lakeformation/) AWS Lake Formation 콘솔을 엽니다. 데이터 레이크 관리자 또는 `lakeformation:RegisterResource` IAM 권한이 있는 사용자로 로그인합니다. 1. 탐색 창의 **관리**에서 **데이터 레이크 위치**를 선택합니다. 1. 위치를 선택하고 **작업** 메뉴에서 **제거**를 선택합니다. 1. 확인 메시지가 표시되면 **제거**를 선택합니다. # 하이브리드 액세스 모드 AWS Lake Formation *하이브리드 액세스 모드*는 동일한 AWS Glue Data Catalog 객체에 대한 두 개의 권한 경로를 지원합니다. 
 첫 번째 경로에서는 Lake Formation을 통해 특정 보안 주체를 선택하고 옵트인을 통해 해당 보안 주체에 카탈로그, 데이터베이스, 테이블, 보기에 액세스할 수 있는 Lake Formation 권한을 부여할 수 있습니다. 두 번째 경로는 다른 모든 보안 주체가 Amazon S3 및 AWS Glue 작업에 대한 기본 IAM 보안 주체 정책을 통해 이러한 리소스에 액세스할 수 있도록 허용합니다. Amazon S3 위치를 Lake Formation에 등록하면 이 위치의 모든 리소스에 대해 Lake Formation 권한을 적용하거나 하이브리드 액세스 모드를 사용할 수 있습니다. 하이브리드 액세스 모드는 기본적으로 `CREATE_TABLE`, `CREATE_PARTITION`, `UPDATE_TABLE` 권한만 적용합니다. Amazon S3 위치가 하이브리드 모드인 경우 해당 위치 아래의 Data Catalog 객체에 대한 보안 주체를 옵트인하여 Lake Formation 권한을 활성화할 수 있습니다.
즉, Lake Formation 권한과 IAM 권한 모두 해당 데이터에 대한 액세스를 제어할 수 있습니다. 즉, 옵트인 보안 주체는 데이터에 액세스하려면 Lake Formation 권한과 IAM 권한이 모두 필요한 반면, 옵트인이 아닌 보안 주체는 IAM 권한만 사용하여 데이터에 계속 액세스합니다. 따라서 하이브리드 액세스 모드는 다른 기존 사용자 또는 워크로드에 대한 액세스를 중단하지 않고도 특정 사용자 집합의 Data Catalog의 카탈로그, 데이터베이스 및 테이블에 대해 Lake Formation을 선택적으로 활성화할 수 있는 유연성을 제공합니다. ![\[AWS 계정 architecture showing data flow between S3, Glue, Lake Formation, Athena, and IAM roles.\]](http://docs.aws.amazon.com/ko_kr/lake-formation/latest/dg/images/hybrid-access-mode-concept.png) 고려 사항 및 제한 사항은 [하이브리드 액세스 모드 고려 사항 및 제한 사항](notes-hybrid.md) 단원을 참조하세요.용어 및 정의 액세스 권한 설정 방법에 따른 데이터 카탈로그 리소스의 정의는 다음과 같습니다. Lake Formation 리소스 Lake Formation에 등록된 리소스입니다. 사용자가 리소스에 액세스하려면 Lake Formation 권한이 필요합니다. AWS Glue 리소스 Lake Formation에 등록되지 않은 리소스입니다. 리소스에는 `IAMAllowedPrincipals` 그룹 권한이 있으므로 사용자는 IAM 권한만 있으면 리소스에 액세스할 수 있습니다. Lake Formation 권한은 적용되지 않습니다. `IAMAllowedPrincipals` 그룹 권한에 대한 자세한 내용은 [메타데이터 권한](metadata-permissions.md) 섹션을 참조하십시오. 하이브리드 리소스 하이브리드 액세스 모드에서 등록된 리소스입니다. 리소스에 액세스하는 사용자에 따라 리소스는 Lake Formation 리소스 또는 AWS Glue 리소스 간에 동적으로 전환됩니다. ## 일반적인 하이브리드 액세스 모드 사용 사례 하이브리드 액세스 모드를 사용하여 단일 계정 및 교차 계정 데이터 공유 시나리오에서 액세스를 제공할 수 있습니다. **단일 계정 시나리오** + ** AWS Glue 리소스를 하이브리드 리소스로 변환 **-이 시나리오에서는 현재 Lake Formation을 사용하고 있지 않지만 데이터 카탈로그 객체에 대해 Lake Formation 권한을 채택하려고 합니다. 하이브리드 액세스 모드에서 Amazon S3 위치를 등록하면 해당 위치를 가리키는 특정 데이터베이스 및 테이블을 옵트인하는 사용자에게 Lake Formation 권한을 부여할 수 있습니다. + **Lake Formation 리소스를 하이브리드 리소스로 전환** - 현재는 Lake Formation 권한을 사용하여 데이터 카탈로그 데이터베이스에 대한 액세스를 제어하고 있지만 기존 Lake Formation 권한을 중단하지 않으면서 Amazon S3 및 AWS Glue 에 대한 IAM 권한을 사용하여 새 보안 주체에 대한 액세스를 제공하려고 합니다. 데이터 위치 등록을 하이브리드 액세스 모드로 업데이트하면 새 보안 주체가 기존 사용자의 Lake Formation 권한을 방해하지 않고 IAM 권한 정책을 사용하여 Amazon S3 위치를 가리키는 데이터 카탈로그 데이터베이스에 액세스할 수 있습니다. 하이브리드 액세스 모드를 활성화하도록 데이터 위치 등록을 업데이트하기 전에 먼저 현재 Lake Formation 권한으로 리소스에 액세스하고 있는 보안 주체를 옵트인해야 합니다. 
 이는 현재 워크플로에 대한 잠재적 중단을 방지하기 위한 것입니다. 
 또한 데이터베이스의 테이블에 대한 `Super` 권한을 `IAMAllowedPrincipal` 그룹에 부여해야 합니다. **교차 계정 데이터 공유 시나리오** + **하이브리드 액세스 모드를 사용하여 AWS Glue 리소스 공유** -이 시나리오에서 생산자 계정에는 Amazon S3 및 AWS Glue 작업에 대한 IAM 권한 정책을 사용하여 현재 소비자 계정과 공유되는 데이터베이스의 테이블이 있습니다. 데이터베이스의 데이터 위치는 Lake Formation에 등록되어 있지 않습니다. 하이브리드 액세스 모드에서 데이터 위치를 등록하기 전에 **교차 계정 버전 설정**을 버전 4로 업데이트해야 합니다. 버전 4는 `IAMAllowedPrincipal` 그룹에 리소스에 대한 AWS RAM 권한이 있을 때 교차 계정 공유에 필요한 새로운 `Super` 권한 정책을 제공합니다. `IAMAllowedPrincipal` 그룹 권한이 있는 리소스의 경우 외부 계정에 Lake Formation 권한을 부여하고 외부 계정에서 Lake Formation 권한을 사용하도록 옵트인할 수 있습니다. 수신자 계정의 데이터 레이크 관리자는 계정의 보안 주체에 Lake Formation 권한을 부여하고 보안 주체가 Lake Formation 권한을 적용하도록 옵트인할 수 있습니다. + **하이브리드 액세스 모드를 사용하여 Lake Formation 리소스 공유** - 현재 생산자 계정에는 Lake Formation 권한을 적용하는 소비자 계정과 공유되는 데이터베이스 테이블이 있습니다. 데이터베이스의 데이터 위치는 Lake Formation에 등록되어 있습니다. 이 경우 Amazon S3 위치 등록을 하이브리드 액세스 모드로 업데이트하고, Amazon S3 버킷 정책 및 데이터 카탈로그 리소스 정책을 사용하여 Amazon S3의 데이터와 데이터 카탈로그의 메타데이터를 소비자 계정의 보안 주체와 공유할 수 있습니다. Amazon S3 위치 등록을 업데이트하기 전에 기존 Lake Formation 권한을 다시 부여하고 보안 주체를 옵트인해야 합니다. 또한 데이터베이스의 테이블에 대한 `Super` 권한을 `IAMAllowedPrincipals` 그룹에 부여해야 합니다. **Topics** + [일반적인 하이브리드 액세스 모드 사용 사례](#hybrid-access-mode-use-cases) + [하이브리드 액세스 모드의 작동 방식](hybrid-access-workflow.md) + [하이브리드 액세스 모드 설정 - 일반 시나리오](hybrid-access-setup.md) + [하이브리드 액세스 모드에서 보안 주체 및 리소스 제거](delete-hybrid-access.md) + [하이브리드 액세스 모드에서 보안 주체 및 리소스 보기](view-hybrid-access.md) + [추가 리소스](additional-resources-hybrid.md) # 하이브리드 액세스 모드의 작동 방식 다음 다이어그램은 데이터 카탈로그 리소스를 쿼리할 때 하이브리드 액세스 모드에서 Lake Formation 권한 부여가 작동하는 방식을 보여줍니다. ![\[AWS Lake Formation authorization process flowchart for hybrid access mode queries.\]](http://docs.aws.amazon.com/ko_kr/lake-formation/latest/dg/images/hybrid-workflow.png) 데이터 레이크 관리자 또는 관리 권한이 있는 사용자는 데이터 레이크의 데이터에 액세스하기 전에 개별 데이터 카탈로그 테이블 사용자 정책을 설정하여 데이터 카탈로그의 테이블에 대한 액세스를 허용하거나 거부합니다. 그러면 `RegisterResource` 작업을 수행할 권한이 있는 보안 주체가 하이브리드 액세스 모드에서 테이블의 Amazon S3 위치를 Lake Formation에 등록합니다. 데이터 위치가 Lake Formation에 등록되어 있지 않은 경우, 관리자는 Data Catalog 데이터베이스 및 테이블의 특정 사용자에게 Lake Formation 권한을 부여하고 하이브리드 액세스 모드에서 해당 데이터베이스 및 테이블에 대해 Lake Formation 권한을 사용하도록 옵트인합니다. 1. **쿼리 제출** - 보안 주체는 Amazon Athena, Amazon EMR 또는 Amazon Redshift Spectrum과 같은 통합 서비스를 사용하여 쿼리 또는 AWS Glue ETL 스크립트를 제출합니다. 1. **데이터 요청** - 통합 분석 엔진이 요청 중인 테이블을 식별하고 데이터 카탈로그(`GetTable`, `GetDatabase`)에 메타데이터 요청을 보냅니다. 1. **권한 확인** - 데이터 카탈로그가 Lake Formation을 사용하여 쿼리 보안 주체의 액세스 권한을 확인합니다. 1. 테이블에 `IAMAllowedPrincipals` 그룹 권한이 연결되어 있지 않은 경우 Lake Formation 권한이 적용됩니다. 1. 보안 주체가 하이브리드 액세스 모드에서 Lake Formation 권한을 사용하도록 선택하고 테이블에 `IAMAllowedPrincipals` 그룹 권한이 연결되어 있는 경우 Lake Formation 권한이 적용됩니다. 쿼리 엔진은 Lake Formation에서 수신한 필터를 적용하고 사용자에게 데이터를 반환합니다. 1. 테이블 위치가 Lake Formation에 등록되어 있지 않고 보안 주체가 하이브리드 액세스 모드에서 Lake Formation 권한을 사용하도록 선택하지 않은 경우 데이터 카탈로그는 테이블에 `IAMAllowedPrincipals` 그룹 권한이 연결되어 있는지 확인합니다. 테이블에 이 권한이 있는 경우 계정의 모든 보안 주체가 테이블에 대해 `Super` 또는 `All` 권한을 갖게 됩니다. Lake Formation 자격 증명 제공은 데이터 위치가 Lake Formation에 등록되어 있지 않은 한 옵트인한 경우에도 사용할 수 없습니다. 1. **자격 증명 가져오기** — 데이터 카탈로그는 테이블 위치가 Lake Formation에 등록되었는지 여부를 확인하여 엔진에 알려줍니다. 기본 데이터가 Lake Formation에 등록된 경우 분석 엔진은 Lake Formation에 Amazon S3 버킷의 데이터에 액세스할 수 있는 임시 자격 증명을 요청합니다. 1. **데이터 가져오기** - 보안 주체가 테이블 데이터에 액세스할 수 있는 경우 Lake Formation이 통합 분석 엔진에 대한 임시 액세스를 제공합니다. 분석 엔진은 임시 액세스를 사용하여 Amazon S3에서 데이터를 가져오고 열, 행 또는 셀 필터링과 같은 필요한 필터링을 수행합니다. 엔진에서 작업 실행을 마치면 결과가 사용자에게 반환됩니다. 이 프로세스를 자격 증명 벤딩이라고 합니다. 자세한 정보는 [Lake Formation과 서드 파티 서비스 통합](Integrating-with-LakeFormation.md) 섹션을 참조하십시오. 1. 
테이블의 데이터 위치가 Lake Formation에 등록되지 않은 경우 분석 엔진에서 두 번째 호출이 Amazon S3로 직접 전송됩니다. 관련 Amazon S3 버킷 정책 및 IAM 사용자 정책은 데이터 액세스에 대해 평가됩니다. IAM 정책을 사용할 때마다 IAM 모범 사례를 따라야 합니다. 자세한 내용은 [IAM 사용 설명서의 IAM의 보안 모범 사례](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)를 참조하세요. # 하이브리드 액세스 모드 설정 - 일반 시나리오 Lake Formation 권한과 마찬가지로 일반적으로 하이브리드 액세스 모드를 사용하여 데이터 액세스를 관리할 수 있는 두 가지 유형의 시나리오가 있습니다. 하나는 보안 주체에 대한 액세스를 제공하고 다른 하나는 외부 AWS 계정 또는 보안 주체에 대한 액세스를 AWS 계정 제공합니다. 이 섹션에서는 다음과 같은 시나리오에서 하이브리드 액세스 모드를 설정하는 방법에 대한 지침을 제공합니다. **내에서 하이브리드 액세스 모드에서 권한 관리 AWS 계정** + [AWS Glue 리소스를 하이브리드 리소스로 변환](hybrid-access-mode-new.md) - 현재 Amazon S3에 대한 IAM 권한을 사용하여 계정의 모든 보안 주체에 대해 데이터베이스의 테이블에 대한 액세스를 제공하고 AWS Glue 있지만 Lake Formation을 채택하여 권한을 점진적으로 관리하려고 합니다. + [Lake Formation 리소스를 하이브리드 리소스로 변환](hybrid-access-mode-update.md) - 현재 Lake Formation을 사용하여 계정의 모든 보안 주체에 대해 데이터베이스의 테이블 액세스를 관리하고 있지만 특정 보안 주체에 대해서만 Lake Formation을 사용하려고 합니다. 동일한 데이터베이스 및 테이블에서 AWS Glue 및 Amazon S3에 대한 IAM 권한을 사용하여 새 보안 주체에 대한 액세스를 제공하려고 합니다. **에서 하이브리드 액세스 모드 AWS 계정의 권한 관리** + [하이브리드 액세스 모드를 사용하여 AWS Glue 리소스 공유](hybrid-access-mode-cross-account.md) - 현재 Lake Formation을 사용하여 테이블에 대한 권한을 관리하고 있지 않지만 Lake Formation 권한을 적용하여 다른 계정의 보안 주체에 대한 액세스 권한을 제공하려고 합니다. + [하이브리드 액세스 모드를 사용한 Lake Formation 리소스 공유](hybrid-access-mode-cross-account-IAM.md) - Lake Formation을 사용하여 테이블에 대한 액세스를 관리하지만 동일한 데이터베이스 AWS Glue 및 테이블에서 및 Amazon S3에 대한 IAM 권한을 사용하여 다른 계정의 보안 주체에 대한 액세스를 제공하려고 합니다. **하이브리드 액세스 모드 설정 - 주요 단계** 1. **하이브리드 액세스 모드**를 선택하여 Lake Formation에 Amazon S3 데이터 위치를 등록합니다. 1. 보안 주체에 데이터 레이크 위치에 대한 `DATA_LOCATION` 권한이 있어야 해당 위치를 가리키는 데이터 카탈로그 테이블 또는 데이터베이스를 생성할 수 있습니다. 1. **교차 계정 버전 설정**을 버전 4로 설정합니다. 1. 데이터베이스 및 테이블에 대한 특정 IAM 사용자 또는 역할에 세분화된 권한을 부여합니다. 동시에 데이터베이스 및 데이터베이스의 전체 테이블 또는 선택한 테이블에 대해 `IAMAllowedPrincipals` 그룹에 `Super` 또는 `All` 권한을 설정해야 합니다. 1. 보안 주체와 리소스를 옵트인합니다. 계정의 다른 보안 주체는 및 Amazon S3 작업에 대한 IAM 권한 정책을 사용하여 데이터베이스 AWS Glue 및 테이블에 계속 액세스할 수 있습니다. 1. Lake Formation 권한을 사용하도록 선택한 보안 주체에 대한 Amazon S3의 IAM 권한 정책을 선택적으로 정리할 수 있습니다. # 하이브리드 액세스 모드 설정을 위한 필수 조건 다음은 하이브리드 액세스 모드를 설정하기 위한 필수 조건입니다. **참고** Lake Formation 관리자는 하이브리드 액세스 모드에서 Amazon S3 위치를 등록하고 보안 주체와 리소스를 옵트인하는 것이 좋습니다. 1. Amazon S3 위치를 가리키는 데이터 카탈로그 리소스를 생성할 수 있는 데이터 위치 권한(`DATA_LOCATION_ACCESS`)을 부여합니다. 데이터 위치 권한은 특정 Amazon S3 위치를 가리키는 Data Catalog 카탈로그, 데이터베이스 및 테이블을 생성하는 기능을 제어합니다. 1. 하이브리드 액세스 모드에서 다른 계정과 데이터 카탈로그 리소스를 공유하려면(리소스에서 `IAMAllowedPrincipals` 그룹 권한을 제거하지 않고) **교차 계정 버전 설정을** 버전 4 이상으로 업데이트해야 합니다. Lake Formation 콘솔을 사용하여 버전을 업데이트하려면 **데이터 카탈로그** **설정 페이지의 교차 계정 버전 설정**에서 버전 **4** 또는 버전 5를 선택합니다. **** `put-data-lake-settings` AWS CLI 명령을 사용하여 `CROSS_ACCOUNT_VERSION` 파라미터를 버전 4 또는 5로 설정할 수도 있습니다. ``` aws lakeformation put-data-lake-settings --region us-east-1 --data-lake-settings file://settings { "DataLakeAdmins": [ { "DataLakePrincipalIdentifier": "arn:aws:iam::<111122223333>:user/" } ], "CreateDatabaseDefaultPermissions": [], "CreateTableDefaultPermissions": [], "Parameters": { "CROSS_ACCOUNT_VERSION": "5" } } ``` 1. 
하이브리드 액세스 모드에서 교차 계정 권한을 부여하려면 부여자에게 AWS Glue 및 AWS RAM 서비스에 필요한 IAM 권한이 있어야 합니다. AWS 관리형 정책은 필요한 권한을 `AWSLakeFormationCrossAccountManager` 부여합니다. 
 하이브리드 액세스 모드에서 교차 계정 데이터 공유를 활성화하기 위해 다음 두 개의 새 IAM 권한을 추가하여 `AWSLakeFormationCrossAccountManager` 관리형 정책을 업데이트했습니다. + ram:ListResourceSharePermissions + ram:AssociateResourceSharePermission **참고** 권한 부여자 역할에 관리 AWS 형 정책을 사용하지 않는 경우 위의 정책을 사용자 지정 정책에 추가합니다. ## Amazon S3 버킷 위치 및 사용자 액세스 에서 카탈로그, 데이터베이스 또는 테이블을 생성할 때 기본 데이터의 Amazon S3 버킷 위치를 지정하고 Lake Formation에 등록할 AWS Glue Data Catalog수 있습니다. 아래 표에서는 테이블 또는 데이터베이스의 Amazon S3 데이터 위치를 기반으로 AWS Glue 및 Lake Formation 사용자(보안 주체)에 대한 권한이 작동하는 방식을 설명합니다. **Lake Formation에 Amazon S3 위치 등록** | 데이터베이스의 Amazon S3 위치 | AWS Glue 사용자 | Lake Formation 사용자 | | --- | --- | --- | | Lake Formation에 등록(하이브리드 액세스 모드 또는 Lake Formation 모드) | IAMAllowedPrincipals 그룹(슈퍼 액세스) 권한에서 권한을 상속하여 Amazon S3 데이터 위치에 대한 읽기 및 쓰기 액세스 권한을 갖습니다. | 부여된 CREATE TABLE 권한에서 테이블을 생성할 수 있는 권한을 상속합니다. | | 연결된 Amazon S3 위치 없음 | CREATE TABLE 및 INSERT TABLE 문을 실행하려면 명시적 DATA LOCATION 권한이 필요합니다. | CREATE TABLE 및 INSERT TABLE 문을 실행하려면 명시적 DATA LOCATION 권한이 필요합니다. | ****IsRegisteredWithLakeFormation** 테이블 속성** 테이블의 `IsRegisteredWithLakeFormation` 속성은 테이블의 데이터 위치가 요청자의 Lake Formation에 등록되어 있는지 여부를 나타냅니다. 위치의 권한 모드가 Lake Formation으로 등록될 경우 모든 사용자가 해당 테이블에 옵트인된 것으로 간주되므로 `IsRegisteredWithLakeFormation` 속성은 데이터 위치에 액세스하는 모든 사용자에 대해 `true`입니다. 위치가 하이브리드 액세스 모드로 등록될 경우 해당 테이블에 대해 옵트인한 사용자에 대해서만 값이 `true`로 설정됩니다. **`IsRegisteredWithLakeFormation` 작동 방식** | 권한 모드 | 사용자 및 역할 | `IsRegisteredWithLakeFormation` | 설명 | | --- | --- | --- | --- | | Lake Formation | 모두 | True | 위치가 Lake Formation에 등록되면 모든 사용자에 대해 `IsRegisteredWithLakeFormation` 속성이 true로 설정됩니다. 다시 말해 Lake Formation에 정의된 권한이 등록된 위치에 적용됩니다. 자격 증명 벤딩은 Lake Formation에서 수행합니다. | | 하이브리드 액세스 모드 | 옵트인됨 | True | 테이블에 대한 데이터 액세스 및 거버넌스에 Lake Formation을 사용하도록 선택한 사용자의 경우 해당 테이블에 대한 `IsRegisteredWithLakeFormation` 속성이 `true`로 설정됩니다. 등록된 위치에서 Lake Formation에 정의된 권한 정책이 적용됩니다. | | 하이브리드 액세스 모드 | 옵트인되지 않음 | False | Lake Formation 권한을 사용하도록 옵트인하지 않은 사용자의 경우 `IsRegisteredWithLakeFormation` 속성이 `false`로 설정됩니다. 등록된 위치에서 Lake Formation에 정의된 권한 정책이 적용되지 않습니다. 대신 사용자는 Amazon S3 권한 정책을 따릅니다. | # AWS Glue 리소스를 하이브리드 리소스로 변환 다음 단계에 따라 Amazon S3 위치를 하이브리드 액세스 모드로 등록하고 기존 데이터 카탈로그 사용자의 데이터 액세스를 중단하지 않고도 새로운 Lake Formation 사용자를 온보딩할 수 있습니다. 시나리오 설명 - 데이터 위치가 Lake Formation에 등록되지 않았으며 데이터 카탈로그 데이터베이스 및 테이블에 대한 사용자 액세스 권한이 Amazon S3 및 AWS Glue 작업에 대한 IAM 권한 정책에 따라 결정됩니다. 
 `IAMAllowedPrincipals` 그룹은 기본적으로 데이터베이스의 모든 테이블에 대한 `Super` 권한을 가집니다. **Lake Formation에 등록되지 않은 데이터 위치에 대해 하이브리드 액세스 모드를 활성화하려면** 1. **Amazon S3 위치를 등록하여 하이브리드 액세스 모드를 활성화합니다.** ------ #### [ Console ] 1. [Lake Formation 콘솔](https://console.aws.amazon.com/lakeformation/)에 데이터 레이크 관리자로 로그인합니다. 1. 탐색 창의 **관리**에서 **데이터 레이크 위치**를 선택합니다. 1. **위치 등록**을 선택합니다. ![\[Register location form for Amazon S3 data lake with path input, IAM role selection, and permission mode options.\]](http://docs.aws.amazon.com/ko_kr/lake-formation/latest/dg/images/hybrid-access-register-s3.png) 1. **위치 등록** 창에서 Lake Formation에 등록하려는 **Amazon S3** 경로를 선택합니다. 1. **IAM 역할**의 경우 `AWSServiceRoleForLakeFormationDataAccess` 서비스 연결 역할(기본값) 또는 [위치를 등록하는 데 사용되는 역할에 대한 요구 사항](registration-role.md)의 요구 사항을 충족하는 사용자 지정 IAM 역할을 선택합니다. 1. **하이브리드 액세스 모드**를 선택하면 등록된 위치를 가리키는 옵트인 보안 주체와 데이터 카탈로그 데이터베이스 및 테이블에 세분화된 Lake Formation 액세스 제어 정책을 적용할 수 있습니다.
 Lake Formation이 등록된 위치에 대한 액세스 요청을 승인하도록 허용하려면 Lake Formation을 선택합니다.
 1. **위치 등록**을 선택합니다. ------ #### [ AWS CLI ] 다음은 HybridAccessEnabled:true/false를 사용하여 Lake Formation에 데이터 위치를 등록하는 예제입니다. `HybridAccessEnabled` 파라미터의 기본값은 false입니다. Amazon S3 경로, 역할 이름 및 AWS 계정 ID를 유효한 값으로 바꿉니다. ``` aws lakeformation register-resource --cli-input-json file:file path json: { "ResourceArn": "arn:aws:s3:::s3-path", "UseServiceLinkedRole": false, "RoleArn": "arn:aws:iam::<123456789012>:role/", "HybridAccessEnabled": true } ``` ------ 1. **하이브리드 액세스 모드의 리소스에 대해 Lake Formation 권한을 사용하도록 권한을 부여하고 보안 주체를 옵트인합니다.** 하이브리드 액세스 모드에서 보안 주체 및 리소스를 옵트인하기 전에 하이브리드 액세스 모드에서 Lake Formation에 위치가 등록된 데이터베이스 및 테이블에 대해 `IAMAllowedPrincipals` 그룹에 대한 `Super` 또는 `All` 권한이 있는지 확인합니다. **참고** 데이터베이스 내에서는 `IAMAllowedPrincipals` 그룹에 `All tables`에 대한 권한을 부여할 수 없습니다. 드롭다운 메뉴에서 각 테이블을 개별적으로 선택하고 권한을 부여해야 합니다. 또한 데이터베이스에 새 테이블을 생성할 때 **데이터 카탈로그 설정**에서 `Use only IAM access control for new tables in new databases`를 사용하도록 선택할 수 있습니다. 이 옵션은 데이터베이스 내에 새 테이블을 생성할 때 `IAMAllowedPrincipals` 그룹에 자동으로 `Super` 권한을 부여합니다. ------ #### [ Console ] 1. Lake Formation 콘솔의 **Data Catalog**에서 **카탈로그**, **데이터베이스** 또는 **테이블**을 선택합니다. 1. 목록에서 카탈로그, 데이터베이스 또는 테이블을 선택하고 **작업** 메뉴에서 **권한 부여**를 선택합니다. 1. 명명된 리소스 방법 또는 LF 태그를 사용하여 데이터베이스, 테이블 및 열에 대한 권한을 부여할 보안 주체를 선택합니다. 또는 **데이터 권한**을 선택하고 목록에서 권한을 부여할 보안 주체를 선택한 다음 **권한 부여**를 선택합니다. 데이터 권한 부여에 대한 자세한 내용은 [데이터 카탈로그 리소스에 대한 권한 부여](granting-catalog-permissions.md) 섹션을 참조하세요. **참고** 보안 주체에게 테이블 생성 권한을 부여하는 경우 보안 주체에 데이터 위치 권한(`DATA_LOCATION_ACCESS`)도 부여해야 합니다. 테이블을 업데이트하는 데는 이 권한이 필요하지 않습니다. 자세한 내용은 [데이터 위치 권한 부여](granting-location-permissions.md) 단원을 참조하십시오. 1. **명명된 리소스 방법**을 사용하여 권한을 부여하는 경우 **데이터 권한** 부여 페이지의 하단 섹션에서 보안 주체 및 리소스를 옵트인하는 옵션을 사용할 수 있습니다. **Lake Formation 권한을 즉시 적용**을 선택하여 보안 주체 및 리소스에 대해 Lake Formation 권한을 활성합니다. ![\[Data Catalog 리소스에 대한 하이브리드 액세스 모드를 선택하는 옵션입니다.\]](http://docs.aws.amazon.com/ko_kr/lake-formation/latest/dg/images/hybrid-access-grant-option.png) 1. **권한 부여**를 선택합니다. 데이터 위치를 가리키는 테이블 A에서 보안 주체 A를 옵트인하면 데이터 위치가 하이브리드 모드로 등록된 경우 보안 주체 A가 Lake Formation 권한을 사용하여 이 테이블의 위치에 액세스할 수 있습니다. ------ #### [ AWS CLI ] 다음은 하이브리드 액세스 모드에서 보안 주체와 테이블을 옵트인하기 위한 예제입니다. 역할 이름, AWS 계정 ID, 데이터베이스 이름 및 테이블 이름을 유효한 값으로 바꾸세요. ``` aws lakeformation create-lake-formation-opt-in --cli-input-json file://file path json: { "Principal": { "DataLakePrincipalIdentifier": "arn:aws:iam::<123456789012>:role/" }, "Resource": { "Table": { "CatalogId": "<123456789012>", "DatabaseName": "", "Name": "" } } } ``` ------ 1. 권한을 부여하기 위해 LF 태그를 선택하는 경우, 보안 주체가 별도의 단계에서 Lake Formation 권한을 사용하도록 옵트인할 수 있습니다. 왼쪽 탐색 표시줄의 **권한** 아래에서 **하이브리드 액세스 모드**를 선택하여 이 작업을 수행할 수 있습니다. 1. **하이브리드 액세스 모드** 페이지의 하단에서 **추가**를 선택하여 하이브리드 액세스 모드에 리소스와 보안 주체를 추가합니다. 1. **리소스 및 보안 주체 추가** 페이지에서 하이브리드 액세스 모드로 등록된 카탈로그, 데이터베이스와 테이블을 선택합니다. 데이터베이스에서 `All tables`를 선택하여 액세스 권한을 부여할 수 있습니다. ![\[하이브리드 액세스 모드에서 카탈로그, 데이터베이스 및 테이블을 추가하는 인터페이스입니다.\]](http://docs.aws.amazon.com/ko_kr/lake-formation/latest/dg/images/hybrid-access-opt-in.png) 1. 하이브리드 액세스 모드에서 Lake Formation 권한을 사용하도록 옵트인할 보안 주체를 선택합니다. + **보안 주체** - 동일한 계정 또는 다른 계정에서 IAM 사용자 및 역할을 선택할 수 있습니다. SAML 사용자 및 그룹을 선택할 수도 있습니다. + **속성** - 속성을 선택하여 속성을 기반으로 권한을 부여합니다. ![\[속성 표현식을 사용하여 보안 주체와 리소스를 추가하는 인터페이스입니다.\]](http://docs.aws.amazon.com/ko_kr/lake-formation/latest/dg/images/abac-hybrid-access.png) + 키-값 페어를 입력하여 속성을 기반으로 권한 부여를 생성합니다. 콘솔에서 Cedar 정책 표현식을 검토합니다. Cedar에 대한 자세한 내용은 [What is Cedar?를 참조하세요. \$1 Cedar 정책 언어 참조 가이드 링크](https://docs.cedarpolicy.com/) + **추가**를 선택합니다. 일치하는 속성을 가진 모든 IAM 역할/사용자에게 액세스 권한이 부여됩니다. 1. **추가**를 선택합니다. # Lake Formation 리소스를 하이브리드 리소스로 변환 현재 데이터 카탈로그 데이터베이스 및 테이블에 대해 Lake Formation 권한을 사용하고 있는 경우 위치 등록 속성을 편집하여 하이브리드 액세스 모드를 활성화할 수 있습니다. 이렇게 하면 기존 Lake Formation 권한을 중단하지 않고 Amazon S3 및 AWS Glue 작업에 대한 IAM 권한 정책을 사용하여 새 보안 주체에게 동일한 리소스에 대한 액세스 권한을 제공할 수 있습니다. 시나리오 설명 - 다음 단계에서는 Lake Formation에 데이터 위치가 등록되어 있고 해당 위치를 가리키는 데이터베이스, 테이블 또는 열에 대한 권한을 보안 주체에 설정했다고 가정합니다. 위치가 서비스 연결 역할로 등록된 경우 위치 파라미터를 업데이트하고 하이브리드 액세스 모드를 활성화할 수 없습니다. `IAMAllowedPrincipals` 그룹은 기본적으로 데이터베이스와 데이터베이스의 모든 테이블에 대한 Super 권한을 가집니다. **중요** 이 위치의 데이터에 액세스하는 보안 주체를 옵트인하지 않고 위치 등록을 하이브리드 액세스 모드로 업데이트하지 마세요. **Lake Formation에 등록된 데이터 위치에 대해 하이브리드 액세스 모드 활성화** 1. **주의** 다른 기존 사용자 또는 워크로드의 권한 정책이 중단되지 않도록 Lake Formation 관리 데이터 위치를 하이브리드 액세스 모드로 변환하지 않는 것이 좋습니다. Lake Formation 권한이 있는 보안 주체를 옵트인합니다. 1. 카탈로그, 데이터베이스 및 테이블에 대해 보안 주체에 부여한 권한을 나열하고 검토합니다. 자세한 내용은 [Lake Formation의 데이터베이스 및 테이블 권한 보기](viewing-permissions.md) 단원을 참조하십시오. 1. 왼쪽 탐색 표시줄의 **권한**에서 **하이브리드 액세스 모드**를 선택하고 **추가**를 선택합니다. 1. **보안 주체 및 리소스 추가** 페이지에서 하이브리드 액세스 모드에서 사용하려는 Amazon S3 데이터 위치의 카탈로그, 데이터베이스 및 테이블을 선택합니다. 이미 Lake Formation 권한이 있는 보안 주체를 선택합니다. 1. 하이브리드 액세스 모드에서 Lake Formation 권한을 사용하도록 보안 주체를 옵트인하려면 **추가**를 선택합니다. 1. **하이브리드 액세스 모드** 옵션을 선택하여 Amazon S3 버킷/접두사 등록을 업데이트합니다. ------ #### [ Console ] 1. Lake Formation 콘솔에 데이터 레이크 관리자로 로그인합니다. 1. 탐색 창의 **등록 및 수집**에서 **데이터 레이크 위치**를 선택합니다. 1. 위치를 선택하고 **작업** 메뉴에서 **편집**을 선택합니다. 1. **하이브리드 액세스 모드**를 선택합니다. 1. **저장**을 선택합니다. 1. 데이터 카탈로그에서 데이터베이스 또는 테이블을 선택하고 `Super` 또는 `All` 권한을 `IAMAllowedPrincipals`라는 가상 그룹에 부여합니다. 1. 위치 등록 속성을 업데이트했을 때 기존 Lake Formation 사용자의 액세스가 중단되지 않았는지 확인합니다. Athena 콘솔에 Lake Formation 보안 주체로 로그인하고 업데이트된 위치를 가리키는 테이블에서 샘플 쿼리를 실행합니다. 마찬가지로 IAM 권한 정책을 사용하여 데이터베이스 및 테이블에 액세스하는 AWS Glue 사용자의 액세스를 확인합니다. ------ #### [ AWS CLI ] 다음은 HybridAccessEnabled:true/false를 사용하여 Lake Formation에 데이터 위치를 등록하는 예제입니다. `HybridAccessEnabled` 파라미터의 기본값은 false입니다. Amazon S3 경로, 역할 이름 및 AWS 계정 ID를 유효한 값으로 바꿉니다. ``` aws lakeformation update-resource --cli-input-json file://file path json: { "ResourceArn": "arn:aws:s3:::", "RoleArn": "arn:aws:iam::<123456789012>:role/", "HybridAccessEnabled": true } ``` ------ # 하이브리드 액세스 모드를 사용하여 AWS Glue 리소스 공유 기존 Data Catalog 사용자의 IAM 기반 액세스를 중단하지 않고 Lake Formation 권한을 AWS 계정 적용하는 다른의 다른 AWS 계정 또는 보안 주체와 데이터를 공유합니다. 시나리오 설명 - 생산자 계정에는 Amazon S3 및 AWS Glue 작업에 대한 IAM 보안 주체 정책을 사용하여 액세스를 제어하는 데이터 카탈로그 데이터베이스가 있습니다. 데이터베이스의 데이터 위치는 Lake Formation에 등록되어 있지 않습니다. `IAMAllowedPrincipals` 그룹은 기본적으로 데이터베이스와 데이터베이스의 모든 테이블에 대한 `Super` 권한을 가집니다. **하이브리드 액세스 모드에서 교차 계정 Lake Formation 권한 부여** 1. **생산자 계정 설정** 1. `lakeformation:PutDataLakeSettings` IAM 권한이 있는 역할을 사용하여 Lake Formation 콘솔에 로그인합니다. 1. **데이터 카탈로그 설정**으로 이동하고 **교차 계정 버전 설정**에 대해 `Version 4`를 선택합니다. 현재 버전 1 또는 2를 사용 중인 경우 [교차 계정 데이터 공유 버전 설정 업데이트](optimize-ram.md) 섹션에서 버전 3으로의 업데이트에 대한 지침을 참조할 수 있습니다. 버전 3에서 4로 업그레이드할 때는 권한 정책을 변경할 필요가 없습니다. 1. 하이브리드 액세스 모드에서 공유하려는 데이터베이스 또는 테이블의 Amazon S3 위치를 등록합니다. 1. 위 단계에서 하이브리드 액세스 모드에서 데이터 위치를 등록한 데이터베이스와 테이블에 대한 `Super` 권한이 `IAMAllowedPrincipals` 그룹에 있는지 확인합니다. 1. AWS 조직, 조직 단위(OUs) 또는 다른 계정의 IAM 보안 주체와 직접 Lake Formation 권한을 부여합니다. 1. IAM 보안 주체에 직접 권한을 부여하는 경우 **Lake Formation 권한을 즉시 적용** 옵션을 활성화하여 하이브리드 액세스 모드에서 Lake Formation 권한을 적용하도록 소비자 계정의 보안 주체를 옵트인합니다. 다른 AWS 계정에 교차 계정 권한을 부여하는 경우 계정을 옵트인하면 Lake Formation 권한이 해당 계정의 관리자에 대해서만 적용됩니다. 수신자 계정 데이터 레이크 관리자는 하이브리드 액세스 모드에 있는 공유 리소스에 대해 Lake Formation 권한을 적용하도록 권한을 하향 조정하고 계정의 보안 주체를 옵트인해야 합니다. **LF 태그와 일치하는 리소스** 옵션을 선택하여 교차 계정 권한을 부여하는 경우 먼저 권한 부여 단계를 완료해야 합니다. Lake Formation 콘솔의 왼쪽 탐색 표시줄에 있는 권한에서 **하이브리드 액세스 모드**를 선택하여 보안 주체와 리소스를 별도의 단계로 하이브리드 액세스 모드로 옵트인할 수 있습니다. 그런 다음 **추가**를 선택하여 Lake Formation 권한을 적용하려는 리소스와 보안 주체를 추가합니다. 1. **소비자 계정 설정** 1. Lake Formation 콘솔([https://console.aws.amazon.com/lakeformation/](https://console.aws.amazon.com/lakeformation/))에 데이터 레이크 관리자로 로그인합니다. 1. [https://console.aws.amazon.com/ram/home](https://console.aws.amazon.com/ram/home) 이동하여 리소스 공유 초대를 수락합니다. AWS RAM 콘솔의 **나와 공유** 탭에는 계정과 공유된 데이터베이스 및 테이블이 표시됩니다. 1. Lake Formation의 공유 데이터베이스 및/또는 테이블에 대한 리소스 링크를 생성합니다. 1. (소비자) 계정의 IAM 보안 주체에 리소스 링크에 대한 `Describe` 권한과 `Grant on target` 권한(원래 공유 리소스에 대한)을 부여합니다. 1. 공유된 데이터베이스 또는 테이블에 대한 Lake Formation 권한을 계정의 보안 주체에 부여합니다. **Lake Formation 권한을 즉시 적용** 옵션을 활성화하여 하이브리드 액세스 모드에서 Lake Formation 권한을 적용하도록 보안 주체 및 리소스를 옵트인합니다. 1. 샘플 Athena 쿼리를 실행하여 보안 주체의 Lake Formation 권한을 테스트합니다. Amazon S3 및 AWS Glue 작업에 대한 IAM 보안 주체 정책을 사용하여 AWS Glue 사용자의 기존 액세스를 테스트합니다. (선택 사항) 데이터 액세스를 위한 Amazon S3 버킷 정책과 Lake Formation 권한을 사용하도록 구성한 보안 주체에 대한 AWS Glue 및 Amazon S3 데이터 액세스를 위한 IAM 보안 주체 정책을 제거합니다. # 하이브리드 액세스 모드를 사용한 Lake Formation 리소스 공유 외부 계정의 새 데이터 카탈로그 사용자가 기존 Lake Formation 교차 계정 공유 권한을 중단하지 않고 IAM 기반 정책을 사용하여 데이터 카탈로그 데이터베이스 및 테이블에 액세스할 수 있도록 허용합니다. 시나리오 설명 - 생산자 계정에는 계정 수준 또는 IAM 보안 수준에서 외부(소비자) 계정과 공유되는 Lake Formation 관리 데이터베이스 및 테이블이 있습니다. 데이터베이스의 데이터 위치는 Lake Formation에 등록되어 있습니다. `IAMAllowedPrincipals` 그룹에는 데이터베이스 및 데이터베이스의 테이블에 대한 `Super` 권한이 없습니다. **기존 Lake Formation 권한을 중단하지 않고 IAM 기반 정책을 통해 새 데이터 카탈로그 사용자에게 교차 계정 액세스 권한 부여** 1. **생산자 계정 설정** 1. `lakeformation:PutDataLakeSettings` 역할을 사용하여 Lake Formation 콘솔에 로그인합니다. 1. **데이터 카탈로그 설정**에서 **교차 계정 버전 설정**에 대해 `Version 4`를 선택합니다. 현재 버전 1 또는 2를 사용 중인 경우 [교차 계정 데이터 공유 버전 설정 업데이트](optimize-ram.md) 섹션에서 버전 3으로의 업데이트에 대한 지침을 참조할 수 있습니다. 버전 3에서 4로 업그레이드할 때는 권한 정책을 변경할 필요가 없습니다. 1. 데이터베이스 및 테이블에 대해 보안 주체에 부여한 권한을 나열합니다. 자세한 내용은 [Lake Formation의 데이터베이스 및 테이블 권한 보기](viewing-permissions.md) 단원을 참조하십시오. 1. 보안 주체 및 리소스를 옵트인하여 기존 Lake Formation 교차 계정 권한을 다시 부여합니다. **참고** 데이터 위치 등록을 하이브리드 액세스 모드로 업데이트하여 교차 계정 권한을 부여하기 전에 계정당 하나 이상의 교차 계정 데이터 공유를 다시 부여해야 합니다. 이 단계는 AWS RAM 리소스 공유에 연결된 AWS RAM 관리형 권한을 업데이트하는 데 필요합니다. 2023년 7월에 Lake Formation은 데이터베이스 및 테이블 공유에 사용되는 AWS RAM 관리형 권한을 업데이트했습니다. `arn:aws:ram::aws:permission/AWSRAMLFEnabledGlueAllTablesReadWriteForDatabase`(데이터베이스 수준 공유 정책) `arn:aws:ram::aws:permission/AWSRAMLFEnabledGlueTableReadWrite`(테이블 수준 공유 정책) 2023년 7월 이전에 수행된 교차 계정 권한 부여에는 이러한 업데이트된 AWS RAM 권한이 없습니다. 교차 계정 권한을 보안 주체에 직접 부여한 경우 해당 권한을 보안 주체에 개별적으로 다시 부여해야 합니다. 이 단계를 건너뛰면 공유 리소스에 액세스하는 보안 주체에 잘못된 조합 오류가 발생할 수 있습니다. 1. [https://console.aws.amazon.com/ram/home](https://console.aws.amazon.com/ram/home) 이동합니다. 1. AWS RAM 콘솔의 **내 공유** 탭에는 외부 계정 또는 보안 주체와 공유한 데이터베이스 및 테이블 이름이 표시됩니다. 공유 리소스에 연결된 권한에 올바른 ARN이 있는지 확인합니다. 1. AWS RAM 공유의 리소스가 `Associated` 상태인지 확인합니다. 상태가 `Associating`으로 표시되면 `Associated` 상태가 될 때까지 기다립니다. 상태가 `Failed`가 되면 작업을 중지하고 Lake Formation 서비스 팀에 문의합니다. 1. 왼쪽 탐색 표시줄의 **권한**에서 **하이브리드 액세스 모드**를 선택하고 **추가**를 선택합니다. 1. **보안 주체 및 리소스 추가** 페이지에는 데이터베이스 및/또는 테이블 그리고 액세스 권한이 있는 보안 주체가 표시됩니다. 보안 주체 및 리소스를 추가하거나 제거하여 필요한 업데이트를 수행할 수 있습니다. 1. 하이브리드 액세스 모드로 변경하려는 데이터베이스 및 테이블에 대한 Lake Formation 권한이 있는 보안 주체를 선택합니다. 데이터베이스 및 테이블을 선택합니다. 1. 하이브리드 액세스 모드에서 Lake Formation 권한을 적용하도록 보안 주체를 옵트인하려면 **추가**를 선택합니다. 1. 가상 그룹 `IAMAllowedPrincipals`에 데이터베이스 및 선택한 테이블에 대한 `Super` 권한을 부여합니다. 1. Amazon S3 위치 Lake Formation 등록을 하이브리드 액세스 모드로 편집합니다. 1. Amazon S3 AWS Glue actions에 대한 IAM 권한 정책을 사용하여 외부(소비자) 계정의 AWS Glue 사용자에게 권한을 부여합니다. 1. **소비자 계정 설정** 1. Lake Formation 콘솔([https://console.aws.amazon.com/lakeformation/](https://console.aws.amazon.com/lakeformation/))에 데이터 레이크 관리자로 로그인합니다. 1. [https://console.aws.amazon.com/ram/home](https://console.aws.amazon.com/ram/home) 이동하여 리소스 공유 초대를 수락합니다. AWS RAM 페이지의 **나와 공유된 리소스** 탭에는 계정과 공유된 데이터베이스 및 테이블 이름이 표시됩니다. AWS RAM 공유의 경우 연결된 권한에 공유 AWS RAM 초대의 올바른 ARN이 있는지 확인합니다. AWS RAM 공유의 리소스가 `Associated` 상태인지 확인합니다. 상태가 `Associating`으로 표시되면 `Associated` 상태가 될 때까지 기다립니다. 상태가 `Failed`가 되면 작업을 중지하고 Lake Formation 서비스 팀에 문의합니다. 1. Lake Formation의 공유 데이터베이스 및/또는 테이블에 대한 리소스 링크를 생성합니다. 1. (소비자) 계정의 IAM 보안 주체에 리소스 링크에 대한 `Describe` 권한과 `Grant on target` 권한(원래 공유 리소스에 대한)을 부여합니다. 1. 다음으로, 공유된 데이터베이스 또는 테이블에서 계정의 보안 주체에 대한 Lake Formation 권한을 설정합니다. 왼쪽 탐색 표시줄의 **권한**에서 **하이브리드 액세스 모드**를 선택합니다. 1. **하이브리드 액세스 모드** 페이지 하단에서 **추가**를 선택하여 생산자 계정에서 공유되는 데이터베이스 또는 테이블과 보안 주체를 옵트인합니다. 1. Amazon S3 AWS Glue actions에 대한 IAM 권한 정책을 사용하여 계정의 AWS Glue 사용자에게 권한을 부여합니다. 1. Athena를 사용하여 테이블에서 별도의 샘플 쿼리를 실행하여 사용자의 Lake Formation 권한 및 AWS Glue 권한 테스트 (선택 사항) 하이브리드 액세스 모드에 있는 보안 주체에 대한 Amazon S3의 IAM 권한 정책을 정리합니다. # 하이브리드 액세스 모드에서 보안 주체 및 리소스 제거 하이브리드 액세스 모드에서 데이터베이스, 테이블 및 보안 주체를 제거하려면 다음 단계를 따릅니다. ------ #### [ Console ] 1. Lake Formation 콘솔([https://console.aws.amazon.com/lakeformation/](https://console.aws.amazon.com/lakeformation/))에 로그인합니다. 1. **권한**에서 **하이브리드 액세스** 모드를 선택합니다. 1. **하이브리드 액세스 모드** 페이지에서 데이터베이스 또는 테이블 이름 옆의 확인란을 선택하고 `Remove`를 선택합니다. 1. 작업을 확인하라는 경고 메시지가 나타납니다. **** 제거를 선택합니다. Lake Formation은 더 이상 이러한 리소스에 대한 권한을 적용하지 않으며,이 리소스에 대한 액세스는 IAM 및 AWS Glue 권한을 사용하여 제어됩니다. 따라서 적절한 IAM 권한이 없는 사용자는 더 이상 이 리소스에 액세스하지 못할 수 있습니다. ------ #### [ AWS CLI ] 다음 예제는 하이브리드 액세스 모드에서 리소스를 제거하는 방법을 보여줍니다. ``` aws lakeformation delete-lake-formation-opt-in --cli-input-json file://file path json: { "Principal": { "DataLakePrincipalIdentifier": "arn:aws:iam::<123456789012>:role/role name" }, "Resource": { "Table": { "CatalogId": "<123456789012>", "DatabaseName": "", "Name": "" } } } ``` ------ # 하이브리드 액세스 모드에서 보안 주체 및 리소스 보기 하이브리드 액세스 모드에서 데이터베이스, 테이블 및 보안 주체를 보려면 다음 단계를 따릅니다. ------ #### [ Console ] 1. Lake Formation 콘솔([https://console.aws.amazon.com/lakeformation/](https://console.aws.amazon.com/lakeformation/))에 로그인합니다. 1. **권한**에서 **하이브리드 액세스** 모드를 선택합니다. 1. **하이브리드 액세스 모드** 페이지에는 현재 하이브리드 액세스 모드에 있는 리소스와 보안 주체가 표시됩니다. ------ #### [ AWS CLI ] 다음 예제는 하이브리드 액세스 모드에 있는 모든 옵트인 보안 주체와 리소스를 나열하는 방법을 보여줍니다. ``` aws lakeformation list-lake-formation-opt-ins ``` 다음 예제는 특정 보안 주체-리소스 페어에 대한 옵트인을 나열하는 방법을 보여줍니다. ``` aws lakeformation list-lake-formation-opt-ins --cli-input-json file://file path json: { "Principal": { "DataLakePrincipalIdentifier": "arn:aws:iam:::role/" }, "Resource": { "Table": { "CatalogId": "", "DatabaseName": "", "Name": "
" } } } ``` ------ # 추가 리소스 다음 블로그 게시물에서는 IAM 및 Amazon S3 권한을 통해 다른 사용자가 데이터베이스에 이미 액세스할 수 있는 상태에서 선택된 사용자에 대해 하이브리드 액세스 모드에서 Lake Formation 권한을 온보딩하는 방법을 안내합니다. 계정 내에서 그리고 두 AWS 계정 간에 하이브리드 액세스 모드를 설정하는 지침을 검토하겠습니다. + [ Lake Formation 및 IAM 및 Amazon S3 정책을 사용하여 액세스를 보호하기 AWS Glue Data Catalog 위한 하이브리드 액세스 모드를 소개합니다. ](https://aws.amazon.com/blogs/big-data/introducing-hybrid-access-mode-for-aws-glue-data-catalog-to-secure-access-using-aws-lake-formation-and-iam-and-amazon-s3-policies/) # 에서 객체 생성 AWS Glue Data Catalog AWS Lake Formation 는 AWS Glue Data Catalog (데이터 카탈로그)를 사용하여 데이터 레이크, 데이터 소스, 변환 및 대상에 대한 메타데이터를 저장합니다. 메타데이터는 데이터 세트의 기본 데이터에 대한 데이터입니다. 각 AWS 계정에는 AWS 리전당 하나의 데이터 카탈로그가 있습니다. Data Catalog의 메타데이터는 카탈로그, 데이터베이스 및 테이블로 구성된 3단계 데이터 계층 구조로 구성됩니다. 다양한 소스의 데이터를 카탈로그라는 논리적 컨테이너로 구성합니다. 각 카탈로그는 Amazon Redshift 데이터 웨어하우스, Amazon DynamoDB 데이터베이스 및 Snowflake, MySQL과 같은 타사 데이터 소스와 페더레이션 커넥터를 통해 통합된 30개 이상의 외부 데이터 소스의 데이터를 나타냅니다. Data Catalog에서 새 카탈로그를 생성하여 S3 Table 버킷 또는 Redshift 관리형 스토리지(RMS)에 데이터를 저장할 수도 있습니다. 테이블에는 스키마 정보, 파티션 정보, 데이터 위치 등 기본 데이터에 대한 정보가 저장됩니다. 데이터베이스는 테이블의 컬렉션입니다. Data Catalog에는 외부 계정의 공유 카탈로그, 데이터베이스 및 테이블에 대한 링크인 리소스 링크도 포함되어 있으며, 데이터 레이크의 데이터에 대한 교차 계정 액세스에 사용됩니다. Data Catalog는 카탈로그, 데이터베이스 및 테이블을 포함하는 중첩된 카탈로그 객체입니다. AWS 계정 ID로 참조되며 계정 및의 기본 카탈로그입니다 AWS 리전. Data Catalog는 3단계 계층 구조(catalog.database.table)를 사용하여 테이블을 구성합니다. + 카탈로그 - Data Catalog의 3단계 메타데이터 계층 구조의 최상위 수준입니다. 페더레이션을 통해 Data Catalog에 여러 카탈로그를 추가할 수 있습니다. + 데이터베이스 - 테이블과 보기로 구성된 메타데이터 계층 구조의 두 번째 수준입니다. 데이터베이스는 Amazon Redshift 및 Trino와 같은 많은 데이터 시스템에서 스키마라고도 합니다. + 테이블 및 보기 - Data Catalog의 3단계 데이터 계층 구조의 세 번째 수준입니다. Amazon S3의 모든 Iceberg 테이블은 카탈로그 ID = AWS 계정 ID인 기본 데이터 카탈로그에 저장됩니다. 페더레이션을 통해 Amazon Redshift, Amazon S3 Table 스토리지 또는 기타 타사 데이터 소스에 테이블 정의를 AWS Glue Data Catalog 저장하는 페더레이션 카탈로그를에서 생성할 수 있습니다. **Topics** + [카탈로그 생성](creating-catalog.md) + [데이터베이스 생성](creating-database.md) + [테이블 생성](creating-tables.md) + [AWS Glue Data Catalog 뷰 빌드](working-with-views.md) # 카탈로그 생성 카탈로그는 AWS Glue Data Catalog의 3단계 메타데이터 계층 구조에서 최상위 또는 최상위 수준을 나타냅니다. 여러 방법을 사용하여 데이터를 Data Catalog로 가져오고 다단계 카탈로그를 생성할 수 있습니다. 외부 데이터 소스에서 카탈로그를 생성하는 방법에 대한 자세한 내용은 [로 데이터 가져오기 AWS Glue Data Catalog](bring-your-data-overview.md) 섹션을 참조하세요. Lake Formation 콘솔을 사용하여 카탈로그를 생성하려면 데이터 레이크 관리자 또는 *카탈로그 생성자*로 로그인해야 합니다. 카탈로그 생성자는 Lake Formation `CREATE_CATALOG` 권한을 부여받은 보안 주체입니다. Lake Formation 콘솔의 **관리 역할 및 작업** 페이지에서 카탈로그 생성자 목록을 볼 수 있습니다. 이 목록을 보려면 `lakeformation:ListPermissions` IAM 권한이 있어야 하며 데이터 레이크 관리자 또는 `CREATE_CATALOG` 권한에 대한 권한 부여 옵션이 있는 카탈로그 생성자로 로그인해야 합니다. # 데이터베이스 생성 데이터 카탈로그의 메타데이터 테이블은 데이터베이스에 저장됩니다. 필요한 만큼 데이터베이스를 생성할 수 있으며 각 데이터베이스에 대해 서로 다른 Lake Formation 권한을 부여할 수 있습니다. 데이터베이스에는 선택적 위치 속성이 있을 수 있습니다. 이 위치는 일반적으로 Lake Formation에 등록된 Amazon Simple Storage Service(S3) 위치 내에 있습니다. 위치를 지정하면 보안 주체는 데이터베이스 위치 내의 위치를 가리키는 데이터 카탈로그 테이블을 생성하기 위한 데이터 위치 권한이 필요하지 않습니다. 자세한 내용은 [Underlying data access control](access-control-underlying-data.md#data-location-permissions) 단원을 참조하십시오. Lake Formation 콘솔을 사용하여 데이터베이스를 생성하려면 데이터 레이크 관리자 또는 데이터베이스 생성자로 로그인해야 합니다.** 데이터베이스 생성자는 Lake Formation `CREATE_DATABASE` 권한을 부여받은 보안 주체입니다. Lake Formation 콘솔의 **관리 역할 및 작업** 페이지에서 데이터베이스 생성자 목록을 볼 수 있습니다. 이 목록을 보려면 `lakeformation:ListPermissions` IAM 권한이 있어야 하며 데이터 레이크 관리자 또는 `CREATE_DATABASE` 권한에 대한 권한 부여 옵션이 있는 데이터베이스 생성자로 로그인해야 합니다. **데이터베이스를 생성하려면** 1. [https://console.aws.amazon.com/lakeformation/](https://console.aws.amazon.com/lakeformation/) AWS Lake Formation 콘솔을 열고 데이터 레이크 관리자 또는 데이터베이스 생성자로 로그인합니다. 1. 탐색 창의 **데이터 카탈로그**에서 **데이터베이스**를 선택합니다. 1. **데이터베이스 생성**을 선택합니다. 1. **데이터베이스 생성** 대화 상자에 데이터베이스 이름, 선택적 위치 및 선택적 설명을 입력합니다. 1. 필요한 경우 **이 데이터베이스의 새 테이블에 대해 IAM 액세스 제어만 사용**을 선택합니다. 이 옵션에 대한 자세한 내용은 [데이터 레이크의 기본 설정 변경](change-settings.md) 섹션을 참조하세요. 1. **데이터베이스 생성**을 선택합니다. # 테이블 생성 AWS Lake Formation 메타데이터 테이블에는 스키마 정보, 파티션 정보 및 데이터 위치를 포함하여 데이터 레이크의 데이터에 대한 정보가 포함됩니다. 이러한 테이블은 AWS Glue 데이터 카탈로그에 저장됩니다. 이를 사용하여 데이터 레이크의 기본 데이터에 액세스하고 Lake Formation 권한으로 해당 데이터를 관리할 수 있습니다. 테이블은 데이터 카탈로그의 데이터베이스 내에 저장됩니다. 데이터 카탈로그 테이블을 생성하는 몇 가지 방법이 있습니다. + AWS Glue에서 크롤러를 실행합니다. **AWS Glue 개발자 안내서의 [크롤러 정의](https://docs.aws.amazon.com/glue/latest/dg/add-crawler.html)를 참조하세요. + 워크플로를 생성 및 실행합니다. [Lake Formation의 워크플로를 사용하여 데이터 가져오기](workflows.md)을(를) 참조하세요. + Lake Formation 콘솔, AWS Glue API 또는 AWS Command Line Interface (AWS CLI)를 사용하여 수동으로 테이블을 생성합니다. + 를 사용하여 테이블을 생성합니다 Amazon Athena. + 외부 계정의 테이블에 대한 리소스 링크를 생성합니다. [리소스 링크 생성](creating-resource-links.md)을(를) 참조하세요. # Apache Iceberg 테이블 생성 AWS Lake Formation 는 Amazon S3에 있는 데이터와 AWS Glue Data Catalog 함께에서 Apache Parquet 데이터 형식을 사용하는 Apache Iceberg 테이블 생성을 지원합니다. 테이터 카탈로그의 테이블은 데이터 스토어의 데이터를 표현하는 메타데이터 정의입니다. 기본적으로 Lake Formation은 Iceberg v2 테이블을 생성합니다. v1과 v2 테이블의 차이점은 Apache Iceberg 설명서의 [Format version changes](https://iceberg.apache.org/spec/#appendix-e-format-version-changes)(포맷 버전 변경 사항)을 참조하세요. [Apache Iceberg](https://iceberg.apache.org/)는 매우 큰 분석 데이터세트를 위한 오픈 테이블 형식입니다. Iceberg를 사용하면 스키마를 쉽게 변경할 수 있습니다(이를 스키마 진화라고도 함). 다시 말해서 사용자는 기본 데이터를 손상시키지 않고 데이터 테이블에서 열을 추가하거나, 이름을 바꾸거나, 제거할 수 있습니다. 또한 Iceberg는 사용자가 시간 경과에 따른 데이터 변경 사항을 추적할 수 있는 데이터 버전 관리를 지원합니다. 이를 통해 사용자는 과거 버전의 데이터에 액세스하여 데이터를 쿼리하고 업데이트와 삭제 사이의 데이터 변화를 분석할 수 있습니다. Lake Formation 콘솔 또는 AWS Glue API의 `CreateTable` 작업을 사용하여 데이터 카탈로그에 Iceberg 테이블을 생성할 수 있습니다. 자세한 내용은 [CreateTable 작업(Python: create\$1table)](https://docs.aws.amazon.com/glue/latest/dg/aws-glue-api-catalog-tables.html#aws-glue-api-catalog-tables-CreateTable)을 참조하세요. 데이터 카탈로그에서 Iceberg 테이블을 생성할 때 Amazon S3에서 테이블 형식과 메타데이터 파일 경로를 지정해야 읽기 및 쓰기를 수행할 수 있습니다. Amazon S3 데이터 위치를 등록할 때 Lake Formation을 사용하여 세분화된 액세스 제어 권한을 사용하여 Iceberg 테이블을 보호할 수 있습니다 AWS Lake Formation. Amazon S3의 소스 데이터 및 Lake Formation에 등록되지 않은 메타데이터의 경우 액세스는 Amazon S3 및 AWS Glue 작업에 대한 IAM 권한 정책에 따라 결정됩니다. 자세한 내용은 [Lake Formation 권한 관리](managing-permissions.md) 단원을 참조하십시오. **참고** 데이터 카탈로그는 파티션 생성 및 Iceberg 테이블 속성 추가를 지원하지 않습니다. **Topics** + [사전 조건](#iceberg-prerequisites) + [Iceberg 테이블 생성](#create-iceberg-table) ## 사전 조건 데이터 카탈로그에서 Iceberg 테이블을 생성하고 Lake Formation 데이터 액세스 권한을 설정하려면 다음 요구 사항을 완료해야 합니다. 1. **Lake Formation에 등록된 데이터 없이 Iceberg 테이블을 생성하는 데 필요한 권한.** 데이터 카탈로그에서 테이블을 생성하는 데 필요한 권한 외에도 테이블 생성자는 다음 권한이 필요합니다. + 리소스 arn:aws:s3:::\$1bucketName\$1에 대한 `s3:PutObject` + 리소스 arn:aws:s3:::\$1bucketName\$1에 대한 `s3:GetObject` + 리소스 arn:aws:s3:::\$1bucketName\$1에 대한 `s3:DeleteObject` 1. **Lake Formation에 등록된 데이터를 사용하여 Iceberg 테이블을 생성하는 데 필요한 권한.** Lake Formation을 사용하여 데이터 레이크의 데이터를 관리하고 보호하려면 테이블을 위한 데이터가 있는 Amazon S3 위치를 Lake Formation에 등록합니다. 이는 Lake Formation이 Athena, Redshift Spectrum 및 Amazon EMR과 같은 AWS 분석 서비스에 자격 증명을 벤딩하여 데이터에 액세스할 수 있도록 하기 위한 것입니다. Amazon S3 위치 등록에 대한 자세한 내용은 [데이터 레이크에 Amazon S3 위치 추가](register-data-lake.md) 섹션을 참조하세요. Lake Formation에 등록된 기본 데이터를 읽고 쓰는 보안 주체는 다음과 같은 권한이 필요합니다. + `lakeformation:GetDataAccess` + `DATA_LOCATION_ACCESS` 위치에 대한 데이터 위치 권한이 있는 보안 주체는 모든 하위 위치에 대한 위치 권한도 갖습니다. 데이터 위치 권한에 대한 자세한 내용은 [기본 데이터 액세스 제어](access-control-underlying-data.md) 섹션을 참조하세요. 압축을 활성화하려면 서비스가 데이터 카탈로그의 테이블을 업데이트할 권한이 있는 IAM 역할을 맡아야 합니다. 자세한 내용은 [Table optimization prerequisites](https://docs.aws.amazon.com/glue/latest/dg/optimization-prerequisites.html)를 참조하세요. ## Iceberg 테이블 생성 Lake Formation 콘솔을 사용하거나이 페이지에 설명된 AWS Command Line Interface 대로 Iceberg v1 및 v2 테이블을 생성할 수 있습니다. AWS Glue 콘솔 또는를 사용하여 Iceberg 테이블을 생성할 수도 있습니다 AWS Glue 크롤러. 자세한 내용은 AWS Glue 개발자 안내서의 [데이터 카탈로그 및 크롤러](https://docs.aws.amazon.com/glue/latest/dg/catalog-and-crawler.html)를 참조하세요. **Iceberg 테이블을 생성하려면** ------ #### [ Console ] 1. 에 로그인 AWS Management Console하고 [https://console.aws.amazon.com/lakeformation/](https://console.aws.amazon.com/lakeformation/) Lake Formation 콘솔을 엽니다. 1. 데이터 카탈로그에서 **테이블**을 선택하고 **테이블 생성** 버튼을 사용하여 다음 속성을 지정합니다. + **테이블 이름**: 테이블 이름을 입력합니다. Athena를 사용하여 테이블에 액세스하는 경우 Amazon Athena 사용 설명서의 [이름 지정 팁](https://docs.aws.amazon.com/athena/latest/ug/tables-databases-columns-names.html)을 사용하세요. + **데이터베이스**: 기존 데이터베이스를 선택하거나 새 데이터베이스를 생성합니다. + **설명**: 테이블에 대한 설명. 테이블 내용을 이해할 수 있도록 설명을 적을 수 있습니다. + **테이블 형식**: **테이블 형식**으로 Apache Iceberg를 선택합니다. ![\[테이블 최적화 옵션으로 Apache Iceberg 테이블 옵션이 선택되었습니다.\]](http://docs.aws.amazon.com/ko_kr/lake-formation/latest/dg/images/table-optimization.png) + **테이블 최적화** + **압축** - 데이터 파일이 병합 및 재작성되어 불필요한 데이터를 제거하고 조각난 데이터를 더 크고 효율적인 파일로 통합합니다. + **스냅샷 보존** - 스냅샷은 Iceberg 테이블의 타임스탬프가 표시된 버전입니다. 스냅샷 보존 구성을 통해 고객은 스냅샷을 보존하는 기간과 보존할 스냅샷 수를 적용할 수 있습니다. 스냅샷 보존 최적화 프로그램을 구성하면 오래되고 불필요한 스냅샷과 연결된 파일을 제거하여 스토리지 오버헤드를 관리하는 데 도움이 될 수 있습니다. + **분리된 파일 삭제** - 분리된 파일은 Iceberg 테이블 메타데이터에서 더 이상 참조되지 않는 파일입니다. 이러한 파일은 시간이 지남에 따라 누적될 수 있으며, 특히 테이블 삭제 같은 작업이나 ETL 작업 실패 이후에 누적될 수 있습니다. 분리된 파일 삭제를 활성화하면 AWS Glue 가 이러한 불필요한 파일을 주기적으로 식별하고 제거하여 스토리지를 확보할 수 있습니다. 자세한 내용은 [Iceberg 테이블 최적화](https://docs.aws.amazon.com/glue/latest/dg/table-optimizers.html)를 참조하세요. + **IAM 역할**: 압축을 실행하기 위해 서비스는 사용자를 대신하여 IAM 역할을 맡습니다. 드롭다운을 사용하여 IAM 역할을 선택할 수 있습니다. 압축 기능을 활성화하는 데 필요한 권한이 역할에 있는지 확인합니다. 필수 권한에 대한 자세한 내용은 [Table optimization prerequisites](https://docs.aws.amazon.com/glue/latest/dg/optimization-prerequisites.html)를 참조하세요. + **위치**: 메타데이터 테이블을 저장하는 Amazon S3의 폴더 경로를 지정합니다. Iceberg가 읽기 및 쓰기를 수행하려면 데이터 카탈로그에 메타데이터 파일과 위치가 필요합니다. + **스키마**: **열 추가**를 선택하여 열과 열의 데이터 유형을 추가합니다. 빈 테이블을 생성하고 나중에 스키마를 업데이트할 수 있습니다. 데이터 카탈로그는 Hive 데이터 유형을 지원합니다. 자세한 내용은 [Hive 데이터 유형](https://cwiki.apache.org/confluence/plugins/servlet/mobile?contentId=27838462#content/view/27838462)을 참조하세요. Iceberg를 사용하면 테이블을 생성한 후 스키마와 파티션을 개선할 수 있습니다. [Athena 쿼리](https://docs.aws.amazon.com/athena/latest/ug/querying-iceberg-evolving-table-schema.html)를 사용하여 테이블 스키마를 업데이트하고 [Spark 쿼리](https://iceberg.apache.org/docs/latest/spark-ddl/#alter-table-sql-extensions)를 사용하여 파티션을 업데이트할 수 있습니다. ------ #### [ AWS CLI ] ``` aws glue create-table \ --database-name iceberg-db \ --region us-west-2 \ --open-table-format-input '{ "IcebergInput": { "MetadataOperation": "CREATE", "Version": "2" } }' \ --table-input '{"Name":"test-iceberg-input-demo", "TableType": "EXTERNAL_TABLE", "StorageDescriptor":{ "Columns":[ {"Name":"col1", "Type":"int"}, {"Name":"col2", "Type":"int"}, {"Name":"col3", "Type":"string"} ], "Location":"s3://DOC_EXAMPLE_BUCKET_ICEBERG/" } }' ``` ------ # Iceberg 테이블 최적화 Lake Formation은 AWS 분석 엔진 및 ETL 작업에 사용되는 Apache Iceberg 테이블의 관리 및 성능을 개선하기 위해 여러 테이블 최적화 옵션을 지원합니다. 이러한 최적화 프로그램은 효율적인 스토리지 활용, 향상된 쿼리 성능 및 효과적인 데이터 관리를 제공합니다. Lake Formation에서 사용할 수 있는 기본 옵티마이저에는 다음 세 가지 유형이 있습니다. + **압축** - 데이터 압축은 작은 데이터 파일을 압축하여 스토리지 사용량을 줄이고 읽기 성능을 향상시킵니다. 데이터 파일이 병합 및 재작성되어 불필요한 데이터를 제거하고 조각난 데이터를 더 크고 효율적인 파일로 통합합니다. 필요에 따라 압축을 자동으로 실행하거나 수동으로 트리거하도록 구성할 수 있습니다. + **스냅샷 보존** - 스냅샷은 Iceberg 테이블의 타임스탬프가 표시된 버전입니다. 스냅샷 보존 구성을 통해 고객은 스냅샷을 보존하는 기간과 보존할 스냅샷 수를 적용할 수 있습니다. 스냅샷 보존 최적화 프로그램을 구성하면 오래되고 불필요한 스냅샷과 연결된 파일을 제거하여 스토리지 오버헤드를 관리하는 데 도움이 될 수 있습니다. + **분리된 파일 삭제** - 분리된 파일은 Iceberg 테이블 메타데이터에서 더 이상 참조되지 않는 파일입니다. 이러한 파일은 시간이 지남에 따라 누적될 수 있으며, 특히 테이블 삭제 같은 작업이나 ETL 작업 실패 이후에 누적될 수 있습니다. 분리된 파일 삭제를 활성화하면 AWS Glue 가 이러한 불필요한 파일을 주기적으로 식별하고 제거하여 스토리지를 확보할 수 있습니다. AWS Glue 콘솔 또는 AWS Glue API 작업을 사용하여 데이터 카탈로그의 개별 Iceberg 테이블에 대해 압축 AWS CLI, 스냅샷 보존 및 분리된 파일 삭제 옵티마이저를 활성화하거나 비활성화할 수 있습니다. 자세한 내용은 AWS Glue 개발자 안내서의 [Iceberg 테이블 최적화](https://docs.aws.amazon.com/glue/latest/dg/table-optimizers.html)를 참조하세요. # 테이블 검색 AWS Lake Formation 콘솔을 사용하여 이름, 위치, 데이터베이스 포함 등을 기준으로 데이터 카탈로그 테이블을 검색할 수 있습니다. 검색 결과에는 Lake Formation 권한이 있는 테이블만 표시됩니다. **테이블을 검색하려면(콘솔)** 1. 에 로그인 AWS Management Console 하고 [https://console.aws.amazon.com/lakeformation/](https://console.aws.amazon.com/lakeformation/) Lake Formation 콘솔을 엽니다. 1. 탐색 창에서 **테이블**을 선택합니다. 1. 페이지 상단의 검색 필드에 커서를 놓습니다. 필드에는 **속성으로 테이블 찾기라는 자리 표시자 텍스트가 있습니다. **속성** 메뉴가 나타나고 검색 기준으로 사용할 다양한 테이블 속성이 표시됩니다. ![\[속성 메뉴는 검색 필드에서 드롭다운되며 이름, 분류, 데이터베이스, 위치, 카탈로그 ID 등의 항목을 포함합니다.\]](http://docs.aws.amazon.com/ko_kr/lake-formation/latest/dg/images/search-for-tables.png) 1. 다음 중 하나를 수행하세요. + 포함된 데이터베이스로 검색합니다. 1. **속성** 메뉴에서 **데이터베이스**를 선택한 다음 **데이터베이스** 메뉴가 나타나면 데이터베이스를 선택하거나 데이터베이스 이름을 입력하고 **Enter** 키를 누릅니다. 데이터베이스에서 권한이 있는 테이블이 나열됩니다. 1. (선택 사항) 데이터베이스의 단일 테이블로 목록 범위를 좁히려면 다시 검색 필드에 커서를 놓고 **속성** 메뉴에서 **이름**을 선택한 다음 **테이블** 메뉴가 나타나면 테이블 이름을 선택하거나 테이블 이름을 입력하고 **Enter** 키를 누릅니다. 단일 테이블이 나열되고 데이터베이스 이름과 테이블 이름이 모두 검색 필드 아래에 타일로 표시됩니다. ![\[검색 필드 아래에는 두 개의 타일이 있습니다. 하나는 선택한 데이터베이스 이름이 포함된 데이터베이스 타일이고, 다른 하나는 선택한 테이블 이름이 포함된 테이블 타일입니다. 타일 오른쪽에는 필터 지우기 버튼이 있습니다.\]](http://docs.aws.amazon.com/ko_kr/lake-formation/latest/dg/images/search-for-tables-with-filter.png) 필터를 조정하려면 타일 중 하나를 닫거나 **필터 지우기**를 선택합니다. + 다른 속성으로 검색합니다. 1. **속성** 메뉴에서 검색 속성을 선택합니다. AWS 계정 ID로 검색하려면 **속성** 메뉴에서 **카탈로그 ID**를 선택하고 유효한 AWS 계정 ID(예: 111122223333)를 입력한 다음 **Enter** 키를 누릅니다. 위치로 검색하려면 **속성** 메뉴에서 **위치**를 선택하고 **위치** 메뉴가 나타나면 위치를 선택합니다. 선택한 위치(예: Amazon S3)의 루트 위치에 있는 모든 테이블이 반환됩니다. **를 사용하여 테이블 검색 AWS CLI** + 다음 예제에서는 부분 검색을 실행하는 방법을 보여줍니다. `--search-text` 파라미터를 사용하면 메타데이터에 지정된 텍스트가 포함된 테이블을 검색할 수 있습니다. 이 경우 이름, 설명 또는 기타 메타데이터 필드에 '고객'이 있는 모든 테이블을 반환합니다. ``` aws glue search-tables --search-text "customer" --region AWS 리전 --max-results 10 --sort-criteria "FieldName=Name,Sort=ASC" ``` # AWS 계정 간에 데이터 카탈로그 테이블 및 데이터베이스 공유 리소스에 대한 Lake Formation 권한을 외부 AWS 계정에 부여하여 데이터 카탈로그 리소스(데이터베이스 및 테이블)를 외부 계정과 공유할 수 있습니다. 그러면 사용자는 여러 계정의 테이블을 조인하고 쿼리하는 작업과 쿼리를 실행할 수 있습니다. 몇 가지 제한 사항이 있지만 데이터 카탈로그 리소스를 다른 계정과 공유하면 해당 계정의 보안 주체는 해당 리소스가 자신의 데이터 카탈로그에 있는 것처럼 해당 리소스에서 작업을 수행할 수 있습니다. 외부 AWS 계정의 특정 보안 주체와 리소스를 공유하지 않고 AWS 계정 또는 조직과 리소스를 공유합니다. AWS 조직과 리소스를 공유하면 해당 조직의 모든 수준에 있는 모든 계정과 리소스를 공유하게 됩니다. 이때 각 외부 계정의 데이터 레이크 관리자는 계정의 보안 주체에 공유 리소스에 대한 권한을 부여해야 합니다. 자세한 내용은 [Lake Formation에서의 교차 계정 데이터 공유](cross-account-permissions.md) 및 [데이터 카탈로그 리소스에 대한 권한 부여](granting-catalog-permissions.md) 섹션을 참조하세요. **추가 참고:** [공유 데이터 카탈로그 테이블 및 데이터베이스 액세스 및 보기](viewing-shared-resources.md) [사전 조건](cross-account-prereqs.md) # AWS Glue Data Catalog 뷰 빌드 에서 AWS Glue Data Catalog*뷰*는 하나 이상의 테이블을 참조하는 SQL 쿼리에 의해 콘텐츠가 정의되는 가상 테이블입니다. EMR Serverless 또는 AWS Glue 버전 5.0을 사용하여 Amazon Athena, Amazon Redshift 또는 Apache Spark용 SQL 편집기를 사용하여 최대 10개의 테이블을 참조하는 데이터 카탈로그 뷰를 생성할 수 있습니다. 뷰의 기본 참조 테이블은 동일한 데이터베이스 또는 동일한 데이터 카탈로그 내의 다른 데이터베이스에 속할 수 AWS 계정있습니다. [Apache Hudi, Linux Foundation Delta Lake, Apache](https://hudi.incubator.apache.org/) [Iceberg](https://iceberg.apache.org/)와 같은 개방형 테이블 형식(OTF)의 표준 AWS Glue 테이블과 테이블을에 등록된 Amazon S3 위치에 저장된 기본 데이터와 함께 참조할 수 있습니다 AWS Lake Formation. [https://delta.io/](https://delta.io/) 또한 Lake Formation과 공유되는 Amazon Redshift 데이터 공유의 연동 테이블에서 뷰를 생성할 수 있습니다. ## 다른 뷰 유형과 데이터 카탈로그 뷰 구분 데이터 카탈로그 뷰는 Apache Hive, Apache Spark 및 Amazon Athena 뷰와 다릅니다. Data Catalog 뷰는의 기본 기능 AWS Glue Data Catalog이며 다중 언어 정의자 생성 뷰입니다. Athena 또는 Amazon Redshift Spectrum과 같이 지원되는 분석 서비스 중 하나를 사용하여 데이터 카탈로그 뷰를 생성하고 지원되는 다른 분석 서비스를 사용하여 동일한 보기에 액세스할 수 있습니다. 반면 Apache Hive, Apache Spark 및 Athena 뷰는 Athena 및 Amazon Redshift와 같은 각 분석 서비스에서 독립적으로 생성되며 해당 서비스 내에서만 볼 수 있고 액세스할 수 있습니다. ## 정의자 뷰란 무엇입니까? 정의자 뷰는 생성한 보안 주체의 권한에 따라 작동하는 SQL 뷰입니다. 정의자 역할은 참조된 테이블에 액세스하기 위해 필요한 권한을 보유하며 뷰를 정의하는 SQL 문을 실행합니다. 정의자는 보기를 생성하고 AWS Lake Formation세분화된 액세스 제어를 통해 다른 사용자와 공유합니다. 사용자가 정의자 뷰를 쿼리하면 쿼리 엔진은 정의자 역할의 권한을 사용하여 기본 참조 테이블에 액세스합니다. 이 접근 방식을 사용하면 사용자가 소스 테이블에 직접 액세스할 필요 없이 뷰와 상호 작용하여 보안을 강화하고 데이터 액세스 관리를 간소화할 수 있습니다. 정의자 보기를 설정하려면 정의자 IAM 역할이 기본 테이블과 동일한 AWS 계정 내에 있거나 교차 계정 정의자 역할을 사용하는 다른 계정에 있을 수 있습니다. 정의자 역할에 필요한 권한에 대한 자세한 내용은 [뷰 생성을 위한 사전 조건](views-prereqs.md)을 참조하세요. ## 다중 언어 뷰용 프레임워크 데이터 카탈로그는 여러 구조화된 쿼리 언어(SQL) 방언을 사용하여 뷰 생성을 지원합니다. SQL은 관계형 데이터베이스에 정보를 저장하고 처리하는 데 사용되는 언어이며 각 AWS 분석 엔진은 자체 SQL 변형 또는 SQL 언어를 사용합니다. 지원되는 분석 쿼리 엔진 중 하나를 사용하여 단일 SQL 언어에서 데이터 카탈로그 뷰를 생성합니다. 그런 다음, 지원되는 다른 분석 엔진 내에서 다른 SQL 언어의 `ALTER VIEW` 문을 사용하여 뷰를 업데이트할 수 있습니다. 그러나 각 언어는 동일한 테이블, 열 및 데이터 유형 세트를 참조해야 합니다. `GetTable` API AWS CLI 및 AWS 콘솔을 사용하여 보기에 사용할 수 있는 여러 언어에 액세스할 수 있습니다. 따라서 데이터 카탈로그 뷰가 표시되며 지원되는 다양한 분석 엔진에서 쿼리할 수 있습니다. 여러 엔진에서 쿼리할 수 있는 공통 뷰 스키마와 메타데이터 객체를 정의함으로써 데이터 카탈로그 뷰를 사용하면 데이터 레이크 전체에서 균일한 뷰를 사용할 수 있습니다. 각 언어에 대한 스키마 해결 방법의 자세한 내용은 [API 참조 링크]() 섹션을 참조하세요. 다양한 유형의 일치 규칙에 대한 자세한 내용은 [API 문서의 관련 섹션 링크]()를 참조하세요. ## Lake Formation 권한과 통합 AWS Lake Formation 를 사용하여 사용자의 AWS Glue Data Catalog 뷰에 대한 권한 관리를 중앙 집중화할 수 있습니다. 명명된 리소스 메서드 또는 LF 태그를 사용하여 데이터 카탈로그 뷰에 대한 세분화된 권한을 부여하고 AWS 계정, AWS 조직 및 조직 단위 간에 공유할 수 있습니다. 리소스 링크를 AWS 리전 사용하여 간에 데이터 카탈로그 뷰를 공유하고 액세스할 수도 있습니다. 이를 통해 사용자는 데이터 소스를 복제하고 기존 테이블을 공유하지 않고도 데이터 액세스를 제공할 수 있습니다. 데이터 카탈로그 보기의 `CREATE VIEW` DDL 문은 Hudi, Delta Lake 및 Iceberg와 같은 개방형 테이블 형식(OTF)의 표준 AWS Glue 테이블과 테이블을 Lake Formation에 등록된 Amazon S3 위치에 저장된 기본 데이터와 Lake Formation과 공유되는 Amazon Redshift 데이터 공유의 페더레이션 테이블과 참조할 수 있습니다. 테이블은 뷰를 쿼리하는 데 사용되는 엔진이 해당 형식을 지원하는 한 모든 파일 형식일 수 있습니다. 또한 실행되는 엔진의 기본 제공 함수를 참조할 수 있지만 다른 엔진별 리소스는 허용되지 않을 수 있습니다. 자세한 내용은 [데이터 카탈로그 뷰 고려 사항 및 제한 사항](views-notes.md) 섹션을 참조하세요. ## 사용 사례 다음은 데이터 카탈로그 뷰의 중요한 사용 사례입니다. + 단일 뷰 스키마에서 권한을 생성하고 관리합니다. 이렇게 하면 여러 엔진에서 생성된 중복된 뷰에서 권한이 일치하지 않을 위험을 피할 수 있습니다. + 기본 참조 테이블에 대한 권한을 직접 부여하지 않고 여러 테이블을 참조하는 뷰에 대한 권한을 사용자에게 부여합니다. + 뷰에 LF 태그를 적용하고 사용자에게 LF 태그 기반 권한을 부여하여 LF 태그(LF 태그는 열 수준까지만 캐스케이딩됨)를 사용하여 테이블에서 행 수준 필터링을 달성합니다. ## 뷰에 지원되는 AWS 분석 서비스 다음 AWS 분석 서비스는 데이터 카탈로그 뷰 생성을 지원합니다. + Amazon Redshift + Amazon Athena 버전 3 + EMR Serverless의 Apache Spark + AWS Glue 버전 5.0의 Apache Spark ## 추가 리소스 이 설명서와 다음 리소스를 사용하여 데이터 카탈로그에 대해 자세히 알아볼 수 있습니다. 다음 동영상에서는 Athena 및 Amazon Redshift에서 뷰를 생성하고 쿼리하는 방법을 설명합니다. [![AWS Videos](http://img.youtube.com/vi/https://www.youtube.com/embed/rFO2OoxVYxE?si=Z0qsyuvTp2ZJg-PL/0.jpg)](http://www.youtube.com/watch?v=https://www.youtube.com/embed/rFO2OoxVYxE?si=Z0qsyuvTp2ZJg-PL) **Topics** + [다른 뷰 유형과 데이터 카탈로그 뷰 구분](#diff-views) + [정의자 뷰란 무엇입니까?](#definer-view) + [다중 언어 뷰용 프레임워크](#multi-dialect) + [Lake Formation 권한과 통합](#lf-view-integ) + [사용 사례](#views-use-cases) + [뷰에 지원되는 AWS 분석 서비스](#views-supported-engines) + [추가 리소스](#views-addtional-resources) + [뷰 생성을 위한 사전 조건](views-prereqs.md) + [DDL 문을 사용하여 데이터 카탈로그 뷰 생성](create-views.md) + [AWS Glue APIs 사용하여 데이터 카탈로그 뷰 생성](views-api-usage.md) + [데이터 카탈로그 뷰에 대한 권한 부여](grant-perms-views.md) + [구체화된 뷰](materialized-views.md) # 뷰 생성을 위한 사전 조건 + 데이터 카탈로그에서 뷰를 생성하려면 참조 테이블의 기본 Amazon S3 데이터 위치를 Lake Formation에 등록해야 합니다. Lake Formation에 데이터를 등록하는 방법에 대한 자세한 내용은 [데이터 레이크에 Amazon S3 위치 추가](register-data-lake.md) 섹션을 참조하십시오. + IAM 역할만 데이터 카탈로그 뷰를 생성할 수 있습니다. 다른 IAM ID로는 데이터 카탈로그 뷰를 생성할 수 없습니다. + 뷰를 정의하는 IAM 역할은 다음과 같은 권한이 있어야 합니다. + 모든 참조 테이블에 대한 `Grantable` 옵션이 포함된 전체 Lake Formation `SELECT` 권한, 모든 열 포함. + 보기가 생성되는 대상 데이터베이스에 대한 Lake Formation `CREATE_TABLE` 권한입니다. + Lake Formation 및 AWS Glue 서비스가 역할을 수임하기 위한 신뢰 정책입니다. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "DataCatalogViewDefinerAssumeRole1", "Effect": "Allow", "Principal": { "Service": [ "glue.amazonaws.com", "lakeformation.amazonaws.com" ] }, "Action": "sts:AssumeRole" } ] } ``` ------ + AWS Glue 및 Lake Formation에 대한 iam:PassRole 권한입니다. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "DataCatalogViewDefinerPassRole1", "Action": [ "iam:PassRole" ], "Effect": "Allow", "Resource": "*", "Condition": { "StringEquals": { "iam:PassedToService": [ "glue.amazonaws.com", "lakeformation.amazonaws.com" ] } } } ] } ``` ------ + AWS Glue 및 Lake Formation 권한. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "Glue:GetDatabase", "Glue:GetDatabases", "Glue:CreateTable", "Glue:GetTable", "Glue:GetTables", "Glue:BatchGetPartition", "Glue:GetPartitions", "Glue:GetPartition", "Glue:GetTableVersion", "Glue:GetTableVersions", "Glue:PassConnection", "lakeFormation:GetDataAccess" ], "Resource": "*" } ] } ``` ------ + `IAMAllowedPrincipals` 그룹에 `Super` 또한 `ALL` 권한이 부여된 데이터베이스에서는 뷰를 생성할 수 없습니다. 데이터베이스의 `IAMAllowedPrincipals` 그룹에 대한 `Super` 권한을 취소하거나, [4단계: 데이터 스토어를 Lake Formation 권한 모델로 전환](upgrade-glue-lake-formation.md#upgrade-glue-lake-formation-step4)를 참조하거나, **새로 생성된 테이블을 위한 기본 권한**에서 **이 데이터베이스의 새 테이블에 대해 IAM 액세스 제어만 사용**을 사용하여 새로운 데이터베이스를 생성할 수 있습니다. # DDL 문을 사용하여 데이터 카탈로그 뷰 생성 Athena용 SQL 편집기, Amazon Redshift 및 API/를 사용하여 AWS Glue Data Catalog 뷰를 생성할 수 있습니다AWS CLI. AWS Glue APIs SQL 편집기를 사용하여 데이터 카탈로그 뷰를 생성하려면 Athena 또는 Redshift Spectrum을 선택하고 `CREATE VIEW` 데이터 정의 언어(DDL) 문을 사용하여 뷰를 생성합니다. 첫 번째 엔진의 언어에서 뷰를 생성한 후 두 번째 엔진의 `ALTER VIEW` DDL 문을 사용하여 추가 언어를 추가할 수 있습니다. 뷰를 정의할 때 다음을 고려하는 것이 중요합니다. + **다중 언어 뷰 정의** - 여러 언어로 뷰를 정의할 때 서로 다른 언어의 스키마가 일치해야 합니다. 각 SQL 언어의 구문 사양은 약간 다릅니다. 데이터 카탈로그 뷰를 정의하는 쿼리 구문은 모든 언어에서 유형과 이름을 모두 포함하여 정확히 동일한 열 목록으로 해석되어야 합니다. 이 정보는 뷰의 `StorageDescriptor`에 저장됩니다. 또한 언어는 데이터 카탈로그에서 동일한 기본 테이블 객체를 참조해야 합니다. `ALTER VIEW` 문을 사용하여 DDL로 뷰에 다른 언어를 추가할 수 있습니다. `ALTER VIEW` 문이 뷰의 스토리지 설명자 또는 기본 테이블을 수정하는 등 뷰 정의를 업데이트하려고 시도하면 문에 “입력 및 기존 스토리지 설명자 불일치” 오류가 발생합니다. SQL 캐스트 작업을 사용하여 뷰 열 유형이 일치하는지 확인할 수 있습니다. + **뷰 업데이트** - `UpdateTable` API를 사용하여 뷰를 업데이트할 수 있습니다. 스토리지 설명자 또는 참조 테이블과 일치시키지 않고 뷰를 업데이트할 경우 `FORCE` 플래그를 제공할 수 있습니다(구문은 엔진 SQL 설명서 참조). 강제 업데이트 후 뷰에 강제 `StorageDescriptor` 및 참조 테이블이 적용됩니다. 추가 `ALTER VIEW` DDL은 수정된 값과 일치해야 합니다. 호환되지 않는 언어를 사용하도록 업데이트된 뷰는 “기한 경과” 상태가 됩니다. 뷰 상태는 Lake Formation 콘솔에서 및 `GetTable` 작업을 사용할 경우 볼 수 있습니다. + **varchar 열 유형을 문자열로 참조** - Redshift Spectrum의 varchar 열 유형을 문자열에 캐스팅할 수 없습니다. Redshift Spectrum에서 varchar 열 유형을 사용하여 뷰가 생성되고 후속 언어가 해당 필드를 문자열로 참조하려고 하면 데이터 카탈로그는 `FORCE` 플래그 없이 이를 문자열로 취급합니다. + **복합 유형 필드 처리** - Amazon Redshift는 모든 복합 유형을 [SUPER 유형](https://docs.aws.amazon.com/redshift/latest/dg/r_SUPER_type.html)으로 처리하는 반면 Athena는 복합 유형을 지정합니다. 뷰에 `SUPER` 유형 필드가 있고 다른 엔진이 해당 열을 구문(`>`)과와 같은 특정 복합 유형으로 참조할 경우 데이터 카탈로그는 필드를 특정 복합 유형으로 가정하고 `Force` 플래그 없이 스토리지 설명자에서 이를 사용합니다. 데이터 카탈로그 뷰 생성 및 관리 구문에 대한 자세한 내용은 다음 섹션을 참조하세요. + Amazon Athena 사용 설명서의 [AWS Glue Data Catalog 뷰 사용](https://docs.aws.amazon.com/athena/latest/ug/views-glue.html) + Amazon Athena 사용 설명서의 [Glue 데이터 카탈로그 뷰 쿼리 구문](https://docs.aws.amazon.com/athena/latest/ug/views-glue-ddl.html) + Amazon Redshift 데이터베이스 개발자 안내서의 [AWS Glue Data Catalog에서 뷰 생성](https://docs.aws.amazon.com/redshift/latest/dg/data-catalog-views-overview.html) 데이터 카탈로그의 뷰와 관련된 SQL 명령에 대한 자세한 내용은 [CREATE EXTERNAL VIEW](https://docs.aws.amazon.com/redshift/latest/dg/r_CREATE_EXTERNAL_VIEW.html), [ALTER EXTERNAL VIEW](https://docs.aws.amazon.com/redshift/latest/dg/r_ALTER_EXTERNAL_VIEW.html), [DROP EXTERNAL VIEW](https://docs.aws.amazon.com/redshift/latest/dg/r_DROP_EXTERNAL_VIEW.html)를 참조하세요. 데이터 카탈로그 뷰를 만든 후 Lake Formation 콘솔에서 뷰의 세부 정보를 사용할 수 있습니다. 1. Lake Formation 콘솔의 데이터 카탈로그에서 **뷰**를 선택합니다. 1. 사용 가능한 뷰 목록이 뷰 페이지에 나타납니다. 1. 목록에서 뷰를 선택하면 세부 정보 페이지에 해당 뷰의 속성이 표시됩니다. ![\[하단 섹션에는 가로로 정렬된 다섯 개의 탭이 있으며 각 탭에는 해당 정보가 포함됩니다.\]](http://docs.aws.amazon.com/ko_kr/lake-formation/latest/dg/images/view-definition.png) 스키마 `Column` 행을 선택하고 **LF 태그 편집**을 선택하여 태그 값을 업데이트하거나 새 LF 태그를 할당합니다. SQL 정의 사용 가능한 SQL 정의 목록을 참조할 수 있습니다. **SQL 정의 추가**를 선택하고 SQL 정의를 추가할 쿼리 엔진을 선택합니다. `Edit definition` 열에서 쿼리 엔진(Athena 또는 Amazon Redshift)을 선택하여 SQL 정의를 업데이트합니다. LF 태그 **LF 태그 편집**을 선택하여 태그 값을 편집하거나 새 태그를 할당합니다. LF 태그를 사용하여 뷰에 대한 권한을 부여할 수 있습니다. 크로스 계정 액세스 데이터 카탈로그 보기를 공유한 AWS 계정조직 및 조직 단위(OUs) 목록을 볼 수 있습니다. 기본 테이블 뷰를 만드는 데 사용된 SQL 정의에서 참조되는 기본 테이블이 이 탭에 표시됩니다. # AWS Glue APIs 사용하여 데이터 카탈로그 뷰 생성 AWS Glue [CreateTable](https://docs.aws.amazon.com/glue/latest/webapi/API_CreateTable.html) 및 [UpdateTable](https://docs.aws.amazon.com/glue/latest/webapi/API_UpdateTable.html) APIs 사용하여 데이터 카탈로그에서 뷰를 생성하고 업데이트할 수 있습니다. `CreateTable` 및 `UpdateTable` 작업에는 `ViewDefinition`에 대한 새 `TableInput` 구조가 있는 반면 `SearchTables`, `GetTable`, `GetTables`, `GetTableVersion`, `GetTableVersions` 작업은 뷰에 대한 출력 구문에서 `ViewDefinition`을 제공합니다. 또한 `GetTable` API 출력에 새 `Status` 필드가 있습니다. 지원되는 각 쿼리 엔진 Amazon Athena 과 Amazon Redshift에 대해 SQL 언어를 검증하는 데 두 가지 새로운 AWS Glue 연결을 사용할 수 있습니다. 뷰와 사용하면 `CreateTable` 및 `UpdateTable` API는 비동기식입니다. 해당 API는 여러 SQL 언어로 직접 호출하면 각 엔진에서 직접 호출을 검증하여 해당 엔진에서 언어를 실행할 수 있는지 및 각 언어에서 뷰의 결과적인 스키마가 일치하는지 여부를 확인합니다. AWS Glue 서비스는 이러한 연결을 사용하여 분석 엔진을 내부적으로 호출합니다. 이러한 직접 호출은 엔진에서 `CREATE VIEW` 또는 `ALTER VIEW` SQL DDL이 실행되었는지 확인하기 위해 엔진이 수행하는 작업을 시뮬레이션합니다. 제공된 SQL이 유효하고 스키마가 뷰 언어 간에 일치할 경우 AWS Glue API는 원자적으로 결과를 커밋합니다. 원자성을 사용하면 가동 중지 시간 없이 여러 언어를 사용하는 뷰를 생성하거나 변경할 수 있습니다. **Topics** + [상태 확인을 위한 AWS Glue 연결 생성](views-api-usage-connection.md) + [뷰 생성 상태 검증](views-api-usage-get-table.md) + [비동기 상태 및 작업](views-api-usage-async-states.md) + [비동기 작업 중 뷰 생성 실패 시나리오](views-api-usage-errors.md) # 상태 확인을 위한 AWS Glue 연결 생성 `CreateTable` 또는 `UpdateTable` 작업을 사용하여 AWS Glue Data Catalog 뷰를 생성하거나 업데이트하려면 검증을 위해 새 유형의 AWS Glue 연결을 생성하고 지원되는 분석 엔진에 제공해야 합니다. 해당 연결은 Athena 또는 Amazon Redshift에서 데이터 카탈로그 뷰를 사용하기 위해 필요합니다. 이러한 연결은 AWS CLI, AWS SDKs 또는 AWS Glue APIs. AWS Management Console 를 사용하여 AWS Glue 연결을 생성할 수 없습니다. **참고** 뷰 정의자 역할 및 `CreateTable` 또는 `UpdateTable`을 직접적으로 호출하는 역할이 다를 경우 둘 모두 IAM 정책 문에 `glue:PassConnection` 권한이 필요합니다. 자세한 내용은 [연결 생성](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/glue/create-connection.html) AWS CLI 설명서를 참조하세요. **AWS CLI 연결을 생성하기 위한 명령** 다음은 연결을 생성하기 위한 AWS CLI 명령입니다. ``` aws glue create-connection --region us-east-1 --endpoint-url https://glue.us-east-1.amazonaws.com --cli-input-json file:///root/path/to/create-connection.json ``` **AWS CLI 입력 JSON** Amazon Redshift: ``` { "CatalogId": "123456789012", "ConnectionInput": { "ConnectionType": "VIEW_VALIDATION_REDSHIFT", "Name": "views-preview-cluster-connection-2", "Description": "My first Amazon Redshift validation connection", "ConnectionProperties": { "DATABASE": "dev", "CLUSTER_IDENTIFIER": "glue-data-catalog-views-preview-cluster" } } } ``` Amazon Athena: ``` { "CatalogId": "123456789012", "ConnectionInput": { "ConnectionType": "VIEW_VALIDATION_ATHENA", "Name": "views-preview-cluster-connection-3", "Description": "My first Amazon Athena validation connection", "ConnectionProperties": { "WORKGROUP_NAME": "workgroup-name" } } } ``` # 뷰 생성 상태 검증 `CreateTable` 또는 `UpdateTable` 작업을 실행하면 `GetTable` API 출력의 `Status` 필드에 뷰 생성 상태의 세부 정보가 표시됩니다. 테이블이 아직 없는 `create` 요청의 경우는 비동기 프로세스 기간 동안 빈 테이블을 AWS Glue 생성합니다. `GetTable`을 직접적으로 호출할 때 요청에 대한 진단 정보가 표시되는 선택적 부울 플래그 `IncludeStatusDetails`를 전달할 수 있습니다. 실패할 경우 이 플래그는 각 언어의 개별 상태와 함께 오류 메시지를 표시합니다. 뷰 생성, 읽기, 업데이트 및 삭제(CRUD) 작업 중 오류는 AWS Glue/Lake Formation 서비스에서 처리하는 동안 또는 Amazon Redshift 또는 Athena에서 뷰 SQL 검증 중에 발생할 수 있습니다. 엔진에서 검증 중에 오류가 발생하면 AWS Glue 서비스는 엔진이 반환하는 오류 메시지를 제공합니다. **상태 필드** 다음은 상태 필드입니다. + 상태: 다양한 유형의 작업과 무관한 일반 상태: + 대기됨 + IN\$1PROGRESS + 성공 + FAILED + 작업 - 테이블에서 직접적으로 호출된 작업을 나타냅니다. 현재 `CREATE` 또는 `UPDATE` 작업만 사용할 수 있습니다. 뷰 작업 시 `UPDATE` 및 `CREATE` 작업을 구분해야 합니다. 작업 유형에 따라 테이블 쿼리를 진행하는 방법이 결정됩니다. `UPDATE` 작업은 테이블이 데이터 카탈로그에 이미 있음을 나타냅니다. 이 경우 문제 없이 이전에 생성한 테이블을 계속 쿼리할 수 있습니다. 반면 `CREATE ` 작업은 테이블이 이전에 성공적으로 생성된 적이 없음을 나타냅니다. 테이블이 `CREATE`로 표시될 경우 시스템에 아직 테이블이 없으므로 쿼리 시도에 실패합니다. 따라서 테이블을 쿼리하기 전에 작업 유형(UPDATE 또는 CREATE)을 식별해야 합니다. + RequestedBy - 비동기 변경을 요청한 사용자의 ARN입니다. + UpdatedBy - 취소 또는 수정 요청과 같이 비동기 변경 프로세스를 마지막으로 수동으로 변경하는 사용자의 ARN입니다. + Error - 이 필드는 상태가 **FAILED**인 경우에만 나타납니다. 상위 수준 예외 메시지입니다. 각 언어마다 오류가 다를 수 있습니다. + ErrorCode - 예외 유형입니다. + ErrorMessage - 예외의 간략한 설명입니다. + RequestTime - 변경이 시작된 시간을 나타내는 ISO 8601 형식의 날짜 문자열입니다. + UpdateTime - 상태가 마지막으로 업데이트된 시간을 나타내는 ISO 8601 형식의 날짜 문자열입니다. # 비동기 상태 및 작업 `glue:CreateTable` 요청을 실행하면 데이터 카탈로그 뷰의 비동기 생성이 시작됩니다. 다음 단원에서는 `glue:GetTable` 응답에서 사용할 수 있는 AWS Glue 뷰`Status`의에 대해 설명합니다. 편의상 이 섹션에서는 전체 응답을 생략합니다. ``` { "Table": { ... "Status": { ... "Action": "CREATE", "State": "QUEUED", } } } ``` 위의 두 특성 모두 비동기 작업의 상태와 이 뷰에서 수행할 수 있는 작업을 나타내는 중요한 진단 정보를 나타냅니다. 다음은 이러한 특성이 취할 수 있는 가능한 값입니다. 1. `Status.Action` 1. CREATE 1. UPDATE 1. `Status.State` 1. 대기됨 1. IN\$1PROGRESS 1. 성공 1. FAILED 또한 데이터 카탈로그 뷰의 일부 업데이트에는 비동기 작업이 필요하지 않습니다. 테이블의 `Description` 특성을 업데이트하려는 경우를 예로 들어보겠습니다. 비동기 작업이 필요하지 않으므로 결과 테이블 메타데이터에는 `Status`가 없으며 특성은 `NULL`입니다. ``` { "Table": { ..., "Description": "I changed this attribute!" } } ``` 다음으로이 주제에서는 위의 상태 정보가 AWS Glue 뷰에서 수행할 수 있는 작업에 어떤 영향을 미칠 수 있는지 살펴봅니다. **glue:CreateTable** Glue 테이블에 대해 `glue:CreateTable`이 작동하는 방식을 비교할 때 이 API에는 변경 사항이 없습니다. `CreateTable`은 아직 존재하지 않는 테이블 이름에 대해 직접적으로 호출될 수 있습니다. **glue:UpdateTable** 다음 상태 정보가 있는 AWS Glue 뷰에서는이 작업을 수행할 수 없습니다. 1. 작업 == CREATE 및 State == QUEUED 1. 작업 == CREATE 및 State == IN\$1PROGRESS 1. 작업 == CREATE 및 state == FAILED 1. 작업 == UPDATE 및 state == QUEUED 1. 작업 == UPDATE 및 state == IN\$1PROGRESS 요약하자면 다음 요구 사항을 충족하는 경우에만 데이터 카탈로그 뷰를 업데이트할 수 있습니다. 1. 처음 성공적으로 생성되었습니다. 1. 작업 == CREATE 및 State == SUCCESS 1. 비동기 업데이트 작업 후 터미널 상태에 도달했습니다. 1. 작업 == UPDATE 및 State == SUCCESS 1. 작업 == UPDATE 및 State == FAILED 1. 동기 업데이트의 결과로 상태 특성은 `NULL`입니다. **glue:DeleteTable** 가 AWS Glue 테이블에 대해 `glue:DeleteTable` 작동하는 방식과 비교할 때이 작업에는 변경 사항이 없습니다. 상태와 무관하게 데이터 카탈로그 뷰를 삭제할 수 있습니다. **glue:GetTable** 가 AWS Glue 테이블에 대해 `glue:GetTable` 작동하는 방식과 비교할 때이 작업에는 변경 사항이 없습니다. 그러나 처음으로 성공적으로 생성될 때까지 분석 엔진에서 데이터 카탈로그 뷰를 쿼리할 수 없습니다. `Action == CREATE and State == SUCCESS`. 데이터 카탈로그 뷰를 처음 성공적으로 생성한 후에는 상태와 무관하게 뷰를 쿼리할 수 있습니다. **참고** 이 섹션의 모든 정보는 `GetTable`, `GetTables`, `SearchTables` 등 모든 테이블 읽기 API에 적용됩니다. # 비동기 작업 중 뷰 생성 실패 시나리오 다음 예제는 `CreateTable` 또는 `UpdateTable` 뷰 API 직접 호출에서 발생할 수 있는 오류의 대표적인 유형입니다. SQL 쿼리 실패의 오류 측면이 상당히 크므로 완전하지 않습니다. ## 시나리오 1: Amazon Redshift 쿼리 실패 Amazon Redshift에 제공된 쿼리에는 검증 중에 데이터 카탈로그에서 찾을 수 없는 맞춤법이 틀린 테이블 이름이 포함됩니다. 결과적인 오류는 뷰에 대한 `GetTable` 응답의 `Status` 필드에 표시됩니다. `GetTable` 요청: ``` { "CatalogId": "123456789012", "DatabaseName": "async-view-test-db", "TableInput": { "Name": "view-athena-redshift-72", "Description": "This is an atomic operation", "StorageDescriptor": { "Columns": [ { "Name": "col1", "Type": "int" }, { "Name": "col2", "Type": "string" }, { "Name": "col3", "Type": "double" } ] }, "ViewDefinition": { "Definer": "arn:aws:iam::123456789012:role/GDCViewDefiner", "SubObjects": [ "arn:aws:glue:us-east-1:123456789012:table/gdc-view-playground-db/table_1" ], "Representations": [ { "Dialect": "ATHENA", "DialectVersion": "3", "ViewOriginalText": "SELECT * FROM \"gdc-view-playground-db\".\"table_1\"", "ValidationConnection": "athena-connection" }, { "Dialect": "REDSHIFT", "DialectVersion": "1.0", "ViewOriginalText": "SELECT * FROM \"gdc-view-playground-external-schema\".\"table__1\";", "ValidationConnection": "redshift-connection" } ] } } } ``` `GetTable` 응답: ``` IncludeStatusDetails = FALSE { "Table": { "Name": "view-athena-redshift-72", "DatabaseName": "async-view-test-db", "Description": "", "CreateTime": "2024-07-11T11:39:19-07:00", "UpdateTime": "2024-07-11T11:39:19-07:00", "Retention": 0, "ViewOriginalText": "", "ViewExpandedText": "", "TableType": "", "CreatedBy": "arn:aws:iam::123456789012:user/zcaisse", "IsRegisteredWithLakeFormation": false, "CatalogId": "123456789012", "IsRowFilteringEnabled": false, "VersionId": "-1", "DatabaseId": "", "IsMultiDialectView": false, "Status": { "RequestedBy": "arn:aws:iam::123456789012:user/zcaisse", "UpdatedBy": "arn:aws:iam::123456789012:user/zcaisse", "RequestTime": "2024-07-11T11:39:19-07:00", "UpdateTime": "2024-07-11T11:40:06-07:00", "Action": "CREATE", "State": "FAILED" } } } IncludeStatusDetails = TRUE { "Table": { "Name": "view-athena-redshift-72", "DatabaseName": "async-view-test-db", "Description": "", "CreateTime": "2024-07-11T11:39:19-07:00", "UpdateTime": "2024-07-11T11:39:19-07:00", "Retention": 0, "ViewOriginalText": "", "ViewExpandedText": "", "TableType": "", "CreatedBy": "arn:aws:iam::123456789012:user/zcaisse", "IsRegisteredWithLakeFormation": false, "CatalogId": "123456789012", "IsRowFilteringEnabled": false, "VersionId": "-1", "DatabaseId": "", "IsMultiDialectView": false, "Status": { "RequestedBy": "arn:aws:iam::123456789012:user/zcaisse", "UpdatedBy": "arn:aws:iam::123456789012:user/zcaisse", "RequestTime": "2024-07-11T11:39:19-07:00", "UpdateTime": "2024-07-11T11:40:06-07:00", "Action": "CREATE", "State": "FAILED", "Error": { "ErrorCode": "QueryExecutionException", "ErrorMessage": "Error received during view SQL validation using a connection: [Connection Name: redshift-connection | Query Execution Id: ddb711d3-2415-4aa9-b251-6a76ab4f41b1 | Timestamp: Thu Jul 11 18:39:37 UTC 2024]: Redshift returned error for the statement: ERROR: AwsClientException: EntityNotFoundException from glue - Entity Not Found" }, "Details": { "RequestedChange": { "Name": "view-athena-redshift-72", "DatabaseName": "async-view-test-db", "Description": "This is an atomic operation", "Retention": 0, "StorageDescriptor": { "Columns": [ { "Name": "col1", "Type": "int" }, { "Name": "col2", "Type": "string" }, { "Name": "col3", "Type": "double" } ], "Compressed": false, "NumberOfBuckets": 0, "SortColumns": [], "StoredAsSubDirectories": false }, "TableType": "VIRTUAL_VIEW", "IsRegisteredWithLakeFormation": false, "CatalogId": "123456789012", "IsRowFilteringEnabled": false, "VersionId": "-1", "DatabaseId": "", "ViewDefinition": { "IsProtected": true, "Definer": "arn:aws:iam::123456789012:role/GDCViewDefiner", "SubObjects": [ "arn:aws:glue:us-east-1:123456789012:table/gdc-view-playground-db/table_1" ], "Representations": [ { "Dialect": "ATHENA", "DialectVersion": "3", "ViewOriginalText": "SELECT * FROM \"gdc-view-playground-db\".\"table_1\"", "IsStale": false }, { "Dialect": "REDSHIFT", "DialectVersion": "1.0", "ViewOriginalText": "SELECT * FROM \"gdc-view-playground-external-schema\".\"table__1\";", "IsStale": false } ] }, "IsMultiDialectView": true }, "ViewValidations": [ { "Dialect": "ATHENA", "DialectVersion": "3", "ViewValidationText": "SELECT * FROM \"gdc-view-playground-db\".\"table_1\"", "UpdateTime": "2024-07-11T11:40:06-07:00", "State": "SUCCESS" }, { "Dialect": "REDSHIFT", "DialectVersion": "1.0", "ViewValidationText": "SELECT * FROM \"gdc-view-playground-external-schema\".\"table__1\";", "UpdateTime": "2024-07-11T11:39:37-07:00", "State": "FAILED", "Error": { "ErrorCode": "QueryExecutionException", "ErrorMessage": "Error received during view SQL validation using a connection: [Connection Name: redshift-connection | Query Execution Id: ddb711d3-2415-4aa9-b251-6a76ab4f41b1 | Timestamp: Thu Jul 11 18:39:37 UTC 2024]: Redshift returned error for the statement: ERROR: AwsClientException: EntityNotFoundException from glue - Entity Not Found" } } ] } } } } ``` ## 시나리오 2: 잘못된 Amazon Redshift 연결 다음 예제의 Amazon Redshift 연결은 제공된 클러스터 및 서버리스 엔드포인트에 존재하지 않는 Amazon Redshift 데이터베이스를 참조하므로 잘못된 형식입니다. Amazon Redshift는 뷰를 검증할 수 없으며 `GetTable` 응답의 `Status` 필드에 오류(Amazon Redshift의 `"State": "FAILED"`)가 표시됩니다. `GetTable` 요청: ``` { "CatalogId": "123456789012", "DatabaseName": "async-view-test-db", "TableInput": { "Name": "view-athena-redshift-73", "Description": "This is an atomic operation", "StorageDescriptor": { "Columns": [ { "Name": "col1", "Type": "int" }, { "Name": "col2", "Type": "string" }, { "Name": "col3", "Type": "double" } ] }, "ViewDefinition": { "Definer": "arn:aws:iam::123456789012:role/GDCViewDefiner", "SubObjects": [ "arn:aws:glue:us-east-1:123456789012:table/gdc-view-playground-db/table_1" ], "Representations": [ { "Dialect": "ATHENA", "DialectVersion": "3", "ViewOriginalText": "SELECT * FROM \"gdc-view-playground-db\".\"table_1\"", "ValidationConnection": "athena-connection" }, { "Dialect": "REDSHIFT", "DialectVersion": "1.0", "ViewOriginalText": "SELECT * FROM \"gdc-view-playground-external-schema\".\"table_1\";", "ValidationConnection": "redshift-connection-malformed" } ] } } } ``` `GetTable` 응답: ``` IncludeStatusDetails = FALSE { "Table": { "Name": "view-athena-redshift-73", "DatabaseName": "async-view-test-db", "Description": "", "CreateTime": "2024-07-11T11:43:27-07:00", "UpdateTime": "2024-07-11T11:43:27-07:00", "Retention": 0, "ViewOriginalText": "", "ViewExpandedText": "", "TableType": "", "CreatedBy": "arn:aws:iam::123456789012:user/zcaisse", "IsRegisteredWithLakeFormation": false, "CatalogId": "123456789012", "IsRowFilteringEnabled": false, "VersionId": "-1", "DatabaseId": "", "IsMultiDialectView": false, "Status": { "RequestedBy": "arn:aws:iam::123456789012:user/zcaisse", "UpdatedBy": "arn:aws:iam::123456789012:user/zcaisse", "RequestTime": "2024-07-11T11:43:27-07:00", "UpdateTime": "2024-07-11T11:43:40-07:00", "Action": "CREATE", "State": "FAILED" } } } IncludeStatusDetails = TRUE { "Table": { "Name": "view-athena-redshift-73", "DatabaseName": "async-view-test-db", "Description": "", "CreateTime": "2024-07-11T11:43:27-07:00", "UpdateTime": "2024-07-11T11:43:27-07:00", "Retention": 0, "ViewOriginalText": "", "ViewExpandedText": "", "TableType": "", "CreatedBy": "arn:aws:iam::123456789012:user/zcaisse", "IsRegisteredWithLakeFormation": false, "CatalogId": "123456789012", "IsRowFilteringEnabled": false, "VersionId": "-1", "DatabaseId": "", "IsMultiDialectView": false, "Status": { "RequestedBy": "arn:aws:iam::123456789012:user/zcaisse", "UpdatedBy": "arn:aws:iam::123456789012:user/zcaisse", "RequestTime": "2024-07-11T11:43:27-07:00", "UpdateTime": "2024-07-11T11:43:40-07:00", "Action": "CREATE", "State": "FAILED", "Error": { "ErrorCode": "QueryExecutionException", "ErrorMessage": "Error received during view SQL validation using a connection: [Connection Name: redshift-connection-malformed | Query Execution Id: 69bfafd4-3d51-4cb0-9320-7ce5404b1809 | Timestamp: Thu Jul 11 18:43:38 UTC 2024]: Redshift returned error for the statement: FATAL: database \"devooo\" does not exist" }, "Details": { "RequestedChange": { "Name": "view-athena-redshift-73", "DatabaseName": "async-view-test-db", "Description": "This is an atomic operation", "Retention": 0, "StorageDescriptor": { "Columns": [ { "Name": "col1", "Type": "int" }, { "Name": "col2", "Type": "string" }, { "Name": "col3", "Type": "double" } ], "Compressed": false, "NumberOfBuckets": 0, "SortColumns": [], "StoredAsSubDirectories": false }, "TableType": "VIRTUAL_VIEW", "IsRegisteredWithLakeFormation": false, "CatalogId": "123456789012", "IsRowFilteringEnabled": false, "VersionId": "-1", "DatabaseId": "", "ViewDefinition": { "IsProtected": true, "Definer": "arn:aws:iam::123456789012:role/GDCViewDefiner", "SubObjects": [ "arn:aws:glue:us-east-1:123456789012:table/gdc-view-playground-db/table_1" ], "Representations": [ { "Dialect": "ATHENA", "DialectVersion": "3", "ViewOriginalText": "SELECT * FROM \"gdc-view-playground-db\".\"table_1\"", "IsStale": false }, { "Dialect": "REDSHIFT", "DialectVersion": "1.0", "ViewOriginalText": "SELECT * FROM \"gdc-view-playground-external-schema\".\"table_1\";", "IsStale": false } ] }, "IsMultiDialectView": true }, "ViewValidations": [ { "Dialect": "ATHENA", "DialectVersion": "3", "ViewValidationText": "SELECT * FROM \"gdc-view-playground-db\".\"table_1\"", "UpdateTime": "2024-07-11T11:43:40-07:00", "State": "SUCCESS" }, { "Dialect": "REDSHIFT", "DialectVersion": "1.0", "ViewValidationText": "SELECT * FROM \"gdc-view-playground-external-schema\".\"table_1\";", "UpdateTime": "2024-07-11T11:43:38-07:00", "State": "FAILED", "Error": { "ErrorCode": "QueryExecutionException", "ErrorMessage": "Error received during view SQL validation using a connection: [Connection Name: redshift-connection-malformed | Query Execution Id: 69bfafd4-3d51-4cb0-9320-7ce5404b1809 | Time stamp: Thu Jul 11 18:43:38 UTC 2024]: Redshift returned error for the statement: FATAL: database \"devooo\" does not exist" } } ] } } } } ``` ## 시나리오 3: Athena 쿼리 실패 쿼리에서 데이터베이스 이름의 맞춤법이 잘못되었으므로 SQL for Athena는 유효하지 않습니다. Athena 쿼리 검증은 이를 포착하며 결과적인 오류가 `GetTable` 직접 호출의 `Status` 객체를 통해 표시됩니다. `GetTable` 요청: ``` { "CatalogId": "123456789012", "DatabaseName": "async-view-test-db", "TableInput": { "Name": "view-athena-redshift-70", "Description": "This is an atomic operation", "StorageDescriptor": { "Columns": [ { "Name": "col1", "Type": "int" }, { "Name": "col2", "Type": "string" }, { "Name": "col3", "Type": "double" } ] }, "ViewDefinition": { "Definer": "arn:aws:iam::123456789012:role/GDCViewDefiner", "SubObjects": [ "arn:aws:glue:us-east-1:123456789012:table/gdc-view-playground-db/table_1" ], "Representations": [ { "Dialect": "ATHENA", "DialectVersion": "3", "ViewOriginalText": "SELECT * FROM \"gdc--view-playground-db\".\"table_1\"", "ValidationConnection": "athena-connection" }, { "Dialect": "REDSHIFT", "DialectVersion": "1.0", "ViewOriginalText": "SELECT * FROM \"gdc-view-playground-external-schema\".\"table_1\";", "ValidationConnection": "redshift-connection" } ] } } } ``` `GetTable` 응답: ``` IncludeStatusDetails = FALSE { "Table": { "Name": "view-athena-redshift-70", "DatabaseName": "async-view-test-db", "Description": "", "CreateTime": "2024-07-11T11:09:53-07:00", "UpdateTime": "2024-07-11T11:09:53-07:00", "Retention": 0, "ViewOriginalText": "", "ViewExpandedText": "", "TableType": "", "CreatedBy": "arn:aws:iam::123456789012:user/", "IsRegisteredWithLakeFormation": false, "CatalogId": "123456789012", "IsRowFilteringEnabled": false, "VersionId": "-1", "DatabaseId": "", "IsMultiDialectView": false, "Status": { "RequestedBy": "arn:aws:iam::123456789012:user/zcaisse", "UpdatedBy": "arn:aws:iam::123456789012:user/zcaisse", "RequestTime": "2024-07-11T11:09:54-07:00", "UpdateTime": "2024-07-11T11:10:41-07:00", "Action": "CREATE", "State": "FAILED", } } } IncludeStatusDetails = TRUE { "Table": { "Name": "view-athena-redshift-70", "DatabaseName": "async-view-test-db", "Description": "", "CreateTime": "2024-07-11T11:09:53-07:00", "UpdateTime": "2024-07-11T11:09:53-07:00", "Retention": 0, "ViewOriginalText": "", "ViewExpandedText": "", "TableType": "", "CreatedBy": "arn:aws:iam::123456789012:user/zcaisse", "IsRegisteredWithLakeFormation": false, "CatalogId": "123456789012", "IsRowFilteringEnabled": false, "VersionId": "-1", "DatabaseId": "", "IsMultiDialectView": false, "Status": { "RequestedBy": "arn:aws:iam::123456789012:user/zcaisse", "UpdatedBy": "arn:aws:iam::123456789012:user/zcaisse", "RequestTime": "2024-07-11T11:09:54-07:00", "UpdateTime": "2024-07-11T11:10:41-07:00", "Action": "CREATE", "State": "FAILED", "Error": { "ErrorCode": "QueryExecutionException", "ErrorMessage": "Error received during view SQL validation using a connection: [Connection Name: athena-connection | Query Execution Id: d9bb1e6d-ce26-4b35-8276-8a199af966aa | Timestamp: Thu Jul 11 18:10: 41 UTC 2024]: Athena validation FAILED: {ErrorCategory: 2,ErrorType: 1301,Retryable: false,ErrorMessage: line 1:118: Schema 'gdc--view-playground-db' does not exist}" }, "Details": { "RequestedChange": { "Name": "view-athena-redshift-70", "DatabaseName": "async-view-test-db", "Description": "This is an atomic operation", "Retention": 0, "StorageDescriptor": { "Columns": [ { "Name": "col1", "Type": "int" }, { "Name": "col2", "Type": "string" }, { "Name": "col3", "Type": "double" } ], "Compressed": false, "NumberOfBuckets": 0, "SortColumns": [], "StoredAsSubDirectories": false }, "TableType": "VIRTUAL_VIEW", "IsRegisteredWithLakeFormation": false, "CatalogId": "123456789012", "IsRowFilteringEnabled": false, "VersionId": "-1", "DatabaseId": "", "ViewDefinition": { "IsProtected": true, "Definer": "arn:aws:iam::123456789012:role/GDCViewDefiner", "SubObjects": [ "arn:aws:glue:us-east-1:123456789012:table/gdc-view-playground-db/table_1" ], "Representations": [ { "Dialect": "ATHENA", "DialectVersion": "3", "ViewOriginalText": "SELECT * FROM \"gdc--view-playground-db\".\"table_1\"", "IsStale": false }, { "Dialect": "REDSHIFT", "DialectVersion": "1.0", "ViewOriginalText": "SELECT * FROM \"gdc-view-playground-external-schema\".\"table_1\";", "IsStale": false } ] }, "IsMultiDialectView": true }, "ViewValidations": [ { "Dialect": "ATHENA", "DialectVersion": "3", "ViewValidationText": "SELECT * FROM \"gdc--view-playground-db\".\"table_1\"", "UpdateTime": "2024-07-11T11:10:41-07:00", "State": "FAILED", "Error": { "ErrorCode": "QueryExecutionException", "ErrorMessage": "Error received during view SQL validation using a connection: [Connection Name: athena-connection | Query Execution Id: d9bb1e6d-ce26-4b35-8276-8a199af966aa | Timestamp: Thu J ul 11 18:10:41 UTC 2024]: Athena validation FAILED: {ErrorCategory: 2,ErrorType: 1301,Retryable: false,ErrorMessage: line 1:118: Schema 'gdc--view-playground-db' does not exist}" } }, { "Dialect": "REDSHIFT", "DialectVersion": "1.0", "ViewValidationText": "SELECT * FROM \"gdc-view-playground-external-schema\".\"table_1\";", "UpdateTime": "2024-07-11T11:10:41-07:00", "State": "SUCCESS" } ] } } } } ``` ## 시나리오 4: 불일치 스토리지 설명자 Athena 언어에 제공된 SQL은`col1` 및 `col2`를 선택하고 SQL for Redshift는 `col1`만 선택합니다. 이로 인해 스토리지 설명자 불일치 오류가 발생합니다. `GetTable` 요청: ``` { "CatalogId": "123456789012", "DatabaseName": "async-view-test-db", "TableInput": { "Name": "view-athena-redshift-71", "Description": "This is an atomic operation", "StorageDescriptor": { "Columns": [ { "Name": "col1", "Type": "int" }, { "Name": "col2", "Type": "string" }, { "Name": "col3", "Type": "double" } ] }, "ViewDefinition": { "Definer": "arn:aws:iam::123456789012:role/GDCViewDefiner", "SubObjects": [ "arn:aws:glue:us-east-1:123456789012:table/gdc-view-playground-db/table_1" ], "Representations": [ { "Dialect": "ATHENA", "DialectVersion": "3", "ViewOriginalText": "SELECT col1, col2 FROM \"gdc-view-playground-db\".\"table_1\"", "ValidationConnection": "athena-connection" }, { "Dialect": "REDSHIFT", "DialectVersion": "1.0", "ViewOriginalText": "SELECT col1 FROM \"gdc-view-playground-external-schema\".\"table_1\";", "ValidationConnection": "redshift-connection" } ] } } } ``` `GetTable` 응답: ``` IncludeStatusDetails = FALSE { "Table": { "Name": "view-athena-redshift-71", "DatabaseName": "async-view-test-db", "Description": "", "CreateTime": "2024-07-11T11:22:02-07:00", "UpdateTime": "2024-07-11T11:22:02-07:00", "Retention": 0, "ViewOriginalText": "", "ViewExpandedText": "", "TableType": "", "CreatedBy": "arn:aws:iam::123456789012:user/zcaisse", "IsRegisteredWithLakeFormation": false, "CatalogId": "123456789012", "IsRowFilteringEnabled": false, "VersionId": "-1", "DatabaseId": "", "IsMultiDialectView": false, "Status": { "RequestedBy": "arn:aws:iam::123456789012:user/zcaisse", "UpdatedBy": "arn:aws:iam::123456789012:user/zcaisse", "RequestTime": "2024-07-11T11:22:02-07:00", "UpdateTime": "2024-07-11T11:23:19-07:00", "Action": "CREATE", "State": "FAILED" } } } IncludeStatusDetails = TRUE { "Table": { "Name": "view-athena-redshift-71", "DatabaseName": "async-view-test-db", "Description": "", "CreateTime": "2024-07-11T11:22:02-07:00", "UpdateTime": "2024-07-11T11:22:02-07:00", "Retention": 0, "ViewOriginalText": "", "ViewExpandedText": "", "TableType": "", "CreatedBy": "arn:aws:iam::123456789012:user/zcaisse", "IsRegisteredWithLakeFormation": false, "CatalogId": "123456789012", "IsRowFilteringEnabled": false, "VersionId": "-1", "DatabaseId": "", "IsMultiDialectView": false, "Status": { "RequestedBy": "arn:aws:iam::123456789012:user/zcaisse", "UpdatedBy": "arn:aws:iam::123456789012:user/zcaisse", "RequestTime": "2024-07-11T11:22:02-07:00", "UpdateTime": "2024-07-11T11:23:19-07:00", "Action": "CREATE", "State": "FAILED", "Error": { "ErrorCode": "InvalidInputException", "ErrorMessage": "Engine and existing storage descriptor mismatch" }, "Details": { "RequestedChange": { "Name": "view-athena-redshift-71", "DatabaseName": "async-view-test-db", "Description": "This is an atomic operation", "Retention": 0, "StorageDescriptor": { "Columns": [ { "Name": "col1", "Type": "int" }, { "Name": "col2", "Type": "string" }, { "Name": "col3", "Type": "double" } ], "Compressed": false, "NumberOfBuckets": 0, "SortColumns": [], "StoredAsSubDirectories": false }, "TableType": "VIRTUAL_VIEW", "IsRegisteredWithLakeFormation": false, "CatalogId": "123456789012", "IsRowFilteringEnabled": false, "VersionId": "-1", "DatabaseId": "", "ViewDefinition": { "IsProtected": true, "Definer": "arn:aws:iam::123456789012:role/GDCViewDefiner", "SubObjects": [ "arn:aws:glue:us-east-1:123456789012:table/gdc-view-playground-db/table_1" ], "Representations": [ { "Dialect": "ATHENA", "DialectVersion": "3", "ViewOriginalText": "SELECT col1, col2 FROM \"gdc-view-playground-db\".\"table_1\"", "IsStale": false }, { "Dialect": "REDSHIFT", "DialectVersion": "1.0", "ViewOriginalText": "SELECT col1 FROM \"gdc-view-playground-external-schema\".\"table_1\";", "IsStale": false } ] }, "IsMultiDialectView": true }, "ViewValidations": [ { "Dialect": "ATHENA", "DialectVersion": "3", "ViewValidationText": "SELECT col1, col2 FROM \"gdc-view-playground-db\".\"table_1\"", "UpdateTime": "2024-07-11T11:23:19-07:00", "State": "FAILED", "Error": { "ErrorCode": "InvalidInputException", "ErrorMessage": "Engine and existing storage descriptor mismatch" } }, { "Dialect": "REDSHIFT", "DialectVersion": "1.0", "ViewValidationText": "SELECT col1 FROM \"gdc-view-playground-external-schema\".\"table_1\";", "UpdateTime": "2024-07-11T11:22:49-07:00", "State": "FAILED", "Error": { "ErrorCode": "InvalidInputException", "ErrorMessage": "Engine and existing storage descriptor mismatch" } } ] } } } } ``` # 데이터 카탈로그 뷰에 대한 권한 부여 에서 뷰를 생성한 후 AWS Glue Data Catalog, AWS 계정조직 및 조직 단위의 보안 주체에게 뷰에 대한 데이터 레이크 권한을 부여할 수 있습니다. LF 태그 또는 명명된 리소스 메서드를 사용하여 테이블 권한을 부여할 수 있습니다. 리소스 태깅에 대한 자세한 내용은 [Lake Formation 태그 기반 액세스 제어](tag-based-access-control.md) 섹션을 참조하세요. 뷰에 대한 권한을 직접 부여하는 방법은 [명명된 리소스 방법을 사용하여 뷰에 대한 권한 부여](granting-view-permissions.md) 섹션을 참조하세요. # 구체화된 뷰 **Topics** + [구체화된 뷰를 다른 뷰 유형과 구분](#materialized-views-differentiating) + [사용 사례](#materialized-views-use-cases) + [주요 개념](#materialized-views-key-concepts) + [구체화된 뷰에 대한 권한](#materialized-views-permissions) + [구체화된 뷰 생성 및 관리](#materialized-views-creating-managing) + [스토리지 및 데이터 액세스](#materialized-views-storage-access) + [AWS Lake Formation 권한과 통합](#materialized-views-lake-formation) + [모니터링 및 디버깅](#materialized-views-monitoring-debugging) + [새로 고침 작업 관리](#materialized-views-managing-refresh-jobs) + [모니터링 및 문제 해결](#materialized-views-monitoring-troubleshooting) + [고려 사항 및 제한 사항](#materialized-views-considerations-limitations) AWS Glue 데이터 카탈로그에서 구체화된 뷰는 SQL 쿼리의 미리 계산된 결과를 Apache Iceberg 형식으로 저장하는 관리형 테이블입니다. 쿼리에 액세스할 때마다 쿼리를 실행하는 표준 Data Catalog 뷰와 달리 구체화된 뷰는 쿼리 결과를 물리적으로 저장하고 기본 소스 테이블이 변경될 때 업데이트합니다. Amazon Athena, Amazon EMR 또는에서 Apache Spark 버전 3.5.6 이상을 사용하여 구체화된 뷰를 생성할 수 있습니다 AWS Glue. 구체화된 뷰는 AWS Glue 데이터 카탈로그에 등록된 Apache Iceberg 테이블을 참조하며, 사전 계산된 데이터는 Amazon S3 Tables 버킷 또는 Amazon S3 범용 버킷의 Apache Iceberg 테이블로 저장되므로 Amazon Athena, Amazon Redshift 및 타사 Iceberg 호환 엔진을 비롯한 여러 쿼리 엔진에서 액세스할 수 있습니다. ## 구체화된 뷰를 다른 뷰 유형과 구분 구체화된 뷰는 기본적인 방식으로 AWS Glue 데이터 카탈로그 뷰, Apache Spark 뷰 및 Amazon Athena 뷰와 다릅니다. Data Catalog 뷰는 액세스할 때마다 SQL 쿼리 정의를 실행하는 가상 테이블이지만 구체화된 뷰는 미리 계산된 쿼리 결과를 물리적으로 저장합니다. 따라서 중복 계산이 필요 없으며 자주 액세스하는 복잡한 변환에 대한 쿼리 성능이 크게 향상됩니다. 구체화된 뷰는 AWS Glue ETL 또는 사용자 지정 Spark 작업으로 구축된 기존 데이터 변환 파이프라인과도 다릅니다. 변경 감지, 증분 업데이트 및 워크플로 오케스트레이션을 처리하는 사용자 지정 코드를 작성하는 대신 표준 SQL 구문을 사용하여 구체화된 뷰를 정의합니다. 데이터 카탈로그는 AWS Glue 소스 테이블을 자동으로 모니터링하고, 변경 사항을 감지하고, 완전 관리형 컴퓨팅 인프라를 사용하여 구체화된 뷰를 새로 고칩니다. ## 사용 사례 구체화된 뷰의 중요한 사용 사례는 다음과 같습니다. + **복잡한 분석 쿼리 가속화** - 비용이 많이 드는 조인, 집계 및 창 함수를 미리 계산하는 구체화된 뷰를 생성합니다. Spark 엔진은 사전 계산된 결과를 사용하기 위해 후속 쿼리를 자동으로 다시 작성하여 쿼리 지연 시간과 컴퓨팅 비용을 줄입니다. + **데이터 변환 파이프라인 간소화** - 변경 감지, 증분 업데이트 및 워크플로 오케스트레이션을 처리하는 복잡한 ETL 작업을 간단한 SQL 기반 구체화된 뷰 정의로 대체합니다. AWS Glue 데이터 카탈로그는 모든 운영 복잡성을 자동으로 관리합니다. + **관리형 데이터 액세스를 통한 셀프 서비스 분석 활성화 -** 원시 데이터를 비즈니스용 데이터 세트로 변환하는 큐레이트된 구체화된 뷰를 생성합니다. 기본 소스 테이블을 노출하지 않고 구체화된 뷰에 대한 액세스 권한을 사용자에게 부여하여 보안 관리를 간소화하는 동시에 셀프 서비스 분석을 강화합니다. + **기계 학습을 위한 특성 엔지니어링 최적화** - ML 모델에 대한 특성 변환을 구현하는 구체화된 뷰를 정의합니다. 자동 새로 고침 기능은 소스 데이터가 발전함에 따라 특성 저장소를 최신 상태로 유지하는 동시에 증분 새로 고침은 컴퓨팅 비용을 최소화합니다. + **효율적인 데이터 공유 구현** - 특정 소비자의 데이터를 필터링하고 변환하는 구체화된 뷰를 생성합니다. 를 사용하여 계정 및 리전 간에 구체화된 보기를 공유 AWS Lake Formation하므로 중앙 집중식 거버넌스를 유지하면서 데이터 중복이 필요하지 않습니다. ## 주요 개념 ### 자동 새로 고침 자동 새로 고침은 소스 테이블을 지속적으로 모니터링하고 정의한 일정에 따라 구체화된 뷰를 업데이트하는 기능입니다. 구체화된 뷰를 생성할 때 간격이 1시간인 시간 기반 일정을 사용하여 새로 고침 빈도를 지정할 수 있습니다. AWS Glue 데이터 카탈로그는 관리형 Spark 컴퓨팅 인프라를 사용하여 백그라운드에서 새로 고침 작업을 실행하여 변경 감지 및 증분 업데이트의 모든 측면을 투명하게 처리합니다. 새로 고침 간격 간에 소스 데이터가 변경되면 구체화된 보기가 일시적으로 오래됩니다. 구체화된 뷰에 직접 액세스하는 쿼리는 예약된 다음 새로 고침이 완료될 때까지 오래된 결과를 반환할 수 있습니다. 최신 데이터에 즉시 액세스해야 하는 시나리오의 경우 `REFRESH MATERIALIZED VIEW` SQL 명령을 사용하여 수동 새로 고침을 실행할 수 있습니다. ### 증분 새로 고침 증분 새로 고침은 구체화된 전체 보기를 다시 계산하는 대신 마지막 새로 고침 이후 소스 테이블에서 변경된 데이터만 처리하는 최적화 기법입니다. AWS Glue 데이터 카탈로그는 Apache Iceberg의 메타데이터 계층을 활용하여 소스 테이블의 변경 사항을 효율적으로 추적하고 구체화된 뷰에서 업데이트가 필요한 부분을 결정합니다. 이 접근 방식은 전체 새로 고침 작업에 비해 컴퓨팅 비용과 새로 고침 기간을 크게 줄입니다. 특히 새로 고침 주기 사이에 데이터 비율이 약간만 변경되는 대규모 데이터 세트의 경우 더욱 그렇습니다. 증분 새로 고침 메커니즘은 자동으로 작동하므로 변경된 데이터를 감지하거나 처리하기 위해 사용자 지정 로직을 작성할 필요가 없습니다. ### 자동 쿼리 재작성 자동 쿼리 재작성은 Amazon Athena, Amazon EMR 및의 Spark 엔진에서 사용할 수 있는 쿼리 최적화 기능입니다 AWS Glue. 기본 테이블에 대해 쿼리를 실행하면 Spark 옵티마이저는 쿼리 계획을 분석하고 사용 가능한 구체화된 뷰가 쿼리를 더 효율적으로 충족할 수 있는지 여부를 자동으로 결정합니다. 적절한 구체화된 뷰가 있는 경우 최적화 프로그램은 기본 테이블을 처리하는 대신 미리 계산된 결과를 사용하도록 쿼리를 투명하게 다시 작성합니다. 이 최적화는 애플리케이션 코드 또는 쿼리 문을 변경할 필요 없이 수행됩니다. Spark 옵티마이저는 구체화된 뷰가 최신이고 정확한 결과를 생성할 수 있는 경우에만 자동 쿼리 재작성이 적용되도록 합니다. 구체화된 뷰가 오래되었거나 쿼리 요구 사항과 완전히 일치하지 않는 경우 최적화 프로그램은 기본 테이블에 대해 원래 쿼리 계획을 실행하여 성능보다 정확성을 우선시합니다. ### 정의자 역할 보기 구체화된 뷰는 뷰 정의자 역할이라고 하는 뷰를 생성한 IAM 역할의 권한을 기반으로 작동합니다. 정의자 역할에는 구체화된 뷰 정의에서 참조되는 모든 기본 테이블에 대한 읽기 액세스 권한이 있어야 하며 대상 데이터베이스에 대한 테이블 권한을 생성해야 합니다. 데이터 카탈로그가 구체화된 뷰를 새로 고치면 AWS Glue 정의자 역할을 수임하여 소스 테이블에 액세스하고 업데이트된 결과를 작성합니다. 이 보안 모델을 사용하면 사용자에게 기본 소스 테이블에 대한 직접 권한을 부여하지 않고도 구체화된 뷰에 대한 액세스 권한을 부여할 수 있습니다. 뷰 정의자 역할이 기본 테이블에 대한 액세스 권한을 상실하면 권한이 복원될 때까지 후속 새로 고침 작업이 실패합니다. ## 구체화된 뷰에 대한 권한 구체화된 뷰를 생성하고 관리하려면 AWS Lake Formation 권한을 구성해야 합니다. 구체화된 뷰를 생성하는 IAM 역할(정의자 역할)에는 소스 테이블 및 대상 데이터베이스에 대한 특정 권한이 필요합니다. ### 정의자 역할에 필요한 권한 정의자 역할에는 다음과 같은 Lake Formation 권한이 있어야 합니다. + 소스 테이블에서 - 행, 열 또는 셀 필터가 없는 SELECT 또는 ALL 권한 + 대상 데이터베이스에서 - CREATE\$1TABLE 권한 + AWS Glue 데이터 카탈로그에서 - GetTable 및 CreateTable API 권한 구체화된 뷰를 생성하면 정의자 역할의 ARN이 뷰 정의에 저장됩니다. AWS Glue 데이터 카탈로그는 자동 새로 고침 작업을 실행할 때이 역할을 수임합니다. 정의자 역할이 소스 테이블에 대한 액세스 권한을 상실하면 권한이 복원될 때까지 새로 고침 작업이 실패합니다. ### AWS Glue 작업에 대한 IAM 권한 AWS Glue 작업의 IAM 역할에는 다음 권한이 필요합니다. ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "glue:GetCatalog", "glue:GetCatalogs", "glue:GetTable", "glue:GetTables", "glue:CreateTable", "glue:UpdateTable", "glue:DeleteTable", "glue:GetDatabase", "glue:GetDatabases", "cloudwatch:PutMetricData" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "s3:GetObject", "s3:PutObject", "s3:DeleteObject" ], "Resource": [ "arn:aws:s3:::amzn-s3-demo-bucket/*" ] }, { "Effect": "Allow", "Action": [ "s3:ListBucket" ], "Resource": [ "arn:aws:s3:::amzn-s3-demo-bucket" ] }, { "Effect": "Allow", "Action": [ "logs:CreateLogGroup", "logs:CreateLogStream", "logs:PutLogEvents" ], "Resource": [ "arn:aws:logs:*:*:*:/aws-glue/*" ] }, { "Effect": "Allow", "Action": [ "lakeformation:GetDataAccess" ], "Resource": "*" } ] } ``` 구체화된 뷰 자동 새로 고침에 사용하는 역할에는 역할에 대한 iam:PassRole 권한이 있어야 합니다. ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "iam:PassRole" ], "Resource": [ "arn:aws:iam::111122223333:role/materialized-view-role-name" ] } ] } ``` Glue가 구체화된 뷰를 자동으로 새로 고치도록 하려면 서비스가 역할을 수임할 수 있도록 하는 다음과 같은 신뢰 정책도 역할에 있어야 합니다. ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "glue.amazonaws.com" }, "Action": "sts:AssumeRole" } ] } ``` 구체화된 뷰가 S3 Tables 버킷에 저장된 경우 역할에 다음 권한도 추가해야 합니다. ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3tables:PutTableMaintenanceConfiguration" ], "Resource": "arn:aws:s3tables:*:123456789012:*" } ] } ``` ### 구체화된 뷰에 대한 액세스 권한 부여 다른 사용자에게 구체화된 뷰를 쿼리할 수 있는 액세스 권한을 부여하려면 AWS Lake Formation 를 사용하여 구체화된 뷰 테이블에 대한 SELECT 권한을 부여합니다. 사용자는 기본 소스 테이블에 직접 액세스할 필요 없이 구체화된 뷰를 쿼리할 수 있습니다. Lake Formation 권한 구성에 대한 자세한 내용은 AWS Lake Formation 개발자 안내서의 데이터 카탈로그 리소스에 대한 권한 부여 및 취소를 참조하세요. ## 구체화된 뷰 생성 및 관리 Spark 엔진의 `CREATE MATERIALIZED VIEW` SQL 문을 사용하여 구체화된 뷰를 생성합니다. 뷰 정의는 변환 로직, 대상 데이터베이스 및 테이블 이름, 선택적 새로 고침 구성을 정의하는 SQL 쿼리를 지정합니다. 집계, 여러 테이블의 조인, 필터, 창 함수 등 복잡한 변환을 정의할 수 있습니다. ``` CREATE MATERIALIZED VIEW sales_summary AS SELECT region, product_category, SUM(sales_amount) as total_sales, COUNT(DISTINCT customer_id) as unique_customers FROM sales_transactions WHERE transaction_date >= current_date - interval '90' day GROUP BY region, product_category; ``` 자동 새로 고침을 구성하려면 보기 정의에 새로 고침 일정을 포함합니다. ``` CREATE MATERIALIZED VIEW sales_summary SCHEDULE REFRESH EVERY 1 HOUR AS SELECT region, product_category, SUM(sales_amount) as total_sales FROM sales_transactions GROUP BY region, product_category; ``` `REFRESH MATERIALIZED VIEW` 명령을 사용하여 언제든지 구체화된 뷰를 수동으로 새로 고칠 수 있습니다. ``` REFRESH MATERIALIZED VIEW sales_summary; ``` 기존 구체화된 뷰의 새로 고침 일정을 수정하려면 `ALTER MATERIALIZED VIEW` 문을 사용합니다. ``` ALTER MATERIALIZED VIEW sales_summary ADD SCHEDULE REFRESH EVERY 2 HOURS; ``` ### 중첩된 구체화된 뷰 다른 구체화된 뷰를 기본 테이블로 참조하는 구체화된 뷰를 생성하여 다단계 데이터 변환을 활성화할 수 있습니다. 중첩된 구체화된 뷰를 생성하면 AWS Glue 데이터 카탈로그는 종속성을 추적하고 구체화된 뷰 계층 구조를 통해 업데이트를 자동으로 전파합니다. 기본 구체화된 뷰가 새로 고쳐지면 그에 의존하는 모든 다운스트림 구체화된 뷰가 그에 따라 업데이트됩니다. 이 기능을 사용하면 복잡한 변환을 논리적 단계로 분해하여 유지 관리를 개선하고 데이터 최신성 요구 사항에 따라 변환 계층을 선택적으로 새로 고칠 수 있습니다. ## 스토리지 및 데이터 액세스 구체화된 뷰는 사전 계산된 결과를 AWS 계정 내의 S3 Tables 버킷 또는 범용 S3 버킷에 Apache Iceberg 테이블로 저장합니다. AWS Glue 데이터 카탈로그는 S3 Tables의 자동 최적화 기능을 통해 압축 및 스냅샷 보존을 포함하여 Iceberg 테이블 유지 관리의 모든 측면을 관리합니다. 구체화된 뷰는 Iceberg 테이블로 저장되므로 Amazon Athena, Amazon Redshift 및 타사 분석 플랫폼을 포함한 모든 Iceberg 호환 엔진에서 직접 읽을 수 있습니다. 이러한 다중 엔진 접근성을 통해 데이터 복제 또는 형식 변환 없이 전체 분석 에코시스템에서 사전 계산된 데이터에 계속 액세스할 수 있습니다. ## AWS Lake Formation 권한과 통합 AWS Lake Formation 를 사용하여 구체화된 뷰에 대한 세분화된 권한을 관리할 수 있습니다. 뷰 생성자는 구체화된 뷰의 소유자가 되며 AWS Lake Formation명명된 리소스 메서드 또는 LF 태그를 사용하여 다른 사용자 또는 역할에 권한을 부여할 수 있습니다. 구체화된 뷰에 대한 `SELECT` 권한을 사용자에게 부여하면 기본 소스 테이블에 액세스할 필요 없이 미리 계산된 결과를 쿼리할 수 있습니다. 이 보안 모델은 데이터 액세스 관리를 간소화하고 최소 권한 원칙을 구현하여 사용자에게 필요한 특정 데이터 변환에만 액세스할 수 있는 권한을 제공합니다. AWS Lake Formation의 교차 AWS 계정 공유 기능을 사용하여 계정, AWS 조직 및 조직 단위 간에 구체화된 보기를 공유할 수 있습니다. 리소스 링크를 사용하여 AWS 여러 리전에서 구체화된 뷰에 액세스하여 분산 데이터 액세스를 통해 중앙 집중식 데이터 거버넌스를 활성화할 수도 있습니다. ## 모니터링 및 디버깅 AWS Glue 데이터 카탈로그는 구체화된 모든 보기 새로 고침 작업 및 관련 지표를 Amazon CloudWatch에 게시합니다. CloudWatch 지표를 통해 새로 고침 시작 시간, 종료 시간, 기간, 처리된 데이터 볼륨 및 새로 고침 상태를 모니터링할 수 있습니다. 새로 고침 작업이 실패하면 오류 메시지와 진단 정보가 CloudWatch Logs에 캡처됩니다. 새로 고침 작업이 예상 기간을 초과하거나 반복적으로 실패할 때 알림을 받도록 CloudWatch 경보를 설정할 수 있습니다. 또한 AWS Glue 데이터 카탈로그는 성공적인 새로 고침 실행과 실패한 새로 고침 실행 모두에 대해 변경 이벤트를에 게시하므로 구체화된 보기 작업을 더 광범위한 워크플로 자동화에 통합할 수 있습니다. 구체화된 뷰의 현재 상태를 확인하려면 기한 경과 상태, 마지막 새로 고침 타임스탬프 및 새로 고침 일정 구성을 포함한 메타데이터를 반환하는 `DESCRIBE MATERIALIZED VIEW` SQL 명령을 사용합니다. ## 새로 고침 작업 관리 ### 수동 새로 고침 시작 예약된 간격 밖에서 즉시 새로 고침을 트리거합니다. 필수 권한: API 호출에 사용되는 AWS 자격 증명에는 구체화된 뷰에 대한 `glue:GetTable` 권한이 있어야 합니다. S3 테이블 카탈로그의 경우: ``` aws glue start-materialized-view-refresh-task-run \ --catalog-id :s3tablescatalog/ \ --database-name \ --table-name ``` 루트 카탈로그의 경우: ``` aws glue start-materialized-view-refresh-task-run \ --catalog-id \ --database-name \ --table-name ``` ### 새로 고침 상태 확인 특정 새로 고침 작업의 상태를 가져옵니다. ``` aws glue get-materialized-view-refresh-task-run \ --catalog-id \ --materialized-view-refresh-task-run-id ``` ### 새로 고침 기록 나열 구체화된 보기에 대한 모든 새로 고침 작업 보기: ``` aws glue list-materialized-view-refresh-task-runs \ --catalog-id \ --database-name \ --table-name ``` **참고** S3 테이블`:s3tablescatalog/`의 경우를 사용하고 루트 카탈로그의 `` 경우를 사용합니다. ### 실행 중인 새로 고침 중지 진행 중인 새로 고침 작업 취소: ``` aws glue stop-materialized-view-refresh-task-run \ --catalog-id \ --database-name \ --table-name ``` ## 모니터링 및 문제 해결 구체화된 보기 새로 고침 작업을 모니터링하는 세 가지 방법이 있습니다. ### CloudWatch 지표 CloudWatch에서 구체화된 모든 보기 새로 고침 작업에 대한 집계된 지표를 봅니다. 사용 가능한 지표: + AWS차원이 있는 /Glue 네임스페이스: + CatalogId: 카탈로그 식별자 + DatabaseName: 구체화된 뷰가 포함된 데이터베이스 + TableName: 구체화된 뷰 이름 + TaskType: "MaterializedViewRefresh"로 설정 콘솔에서 보기: 1. CloudWatch 콘솔 → 지표로 이동 1. Select AWS/Glue 네임스페이스 1. 차원별 필터링: CatalogId, DatabaseName, TableName, TaskType 1. 작업 성공, 실패 및 기간에 대한 지표 보기 CloudWatch 지표 쿼리 예제: ``` {AWS/Glue,CatalogId,DatabaseName,TableName,TaskType} MaterializedViewRefresh ``` 사용 AWS CLI: ``` aws cloudwatch get-metric-statistics \ --namespace AWS/Glue \ --metric-name \ --dimensions Name=CatalogId,Value= \ Name=DatabaseName,Value= \ Name=TableName,Value= \ Name=TaskType,Value=MaterializedViewRefresh \ --start-time \ --end-time \ --period 3600 \ --statistics Sum \ --region ``` ### CloudWatch Logs 개별 새로 고침 작업 실행에 대한 세부 실행 로그를 봅니다. 로그 그룹: `/aws-glue/materialized-views/` 여기서 ``는 UUID(예: abc12345-def6-7890-ghij-klmnopqrstuv)입니다. 로그 보기: ``` # List log streams for a task run aws logs describe-log-streams \ --log-group-name /aws-glue/materialized-views/ \ --region # Get log events aws logs get-log-events \ --log-group-name /aws-glue/materialized-views/ \ --log-stream-name \ --region ``` CloudWatch 콘솔에서: 1. CloudWatch → 로그 그룹으로 이동 1. /aws-glue/materialized-views/ 검색 1. 작업 실행 ID가 인 로그 그룹 선택 1. 세부 실행 로그, 오류 및 Spark 작업 출력 보기 ### 알림 새로 고침 작업 상태 변경에 대한 실시간 알림을 받으려면 이벤트를 구독하세요. 사용 가능한 이벤트 유형: + Glue 구체화된 보기 새로 고침 작업이 시작됨 + Glue 구체화된 뷰 새로 고침 작업 성공 + Glue 구체화된 보기 새로 고침 작업 실패 + Glue 구체화된 뷰 자동 새로 고침 호출 실패 규칙 생성: ``` aws events put-rule \ --name materialized-view-refresh-notifications \ --event-pattern '{ "source": ["aws.glue"], "detail-type": [ "Glue Materialized View Refresh Task Started", "Glue Materialized View Refresh Task Succeeded", "Glue Materialized View Refresh Task Failed", "Glue Materialized View Auto-Refresh Invocation Failure" ] }' \ --region ``` 대상 추가(예: SNS 주제): ``` aws events put-targets \ --rule materialized-view-refresh-notifications \ --targets "Id"="1","Arn"="arn:aws:sns:::" \ --region ``` ### 새로 고침 상태 보기 AWS Glue API를 사용하여 구체화된 보기 새로 고침 작업의 상태를 확인합니다. ``` aws glue get-materialized-view-refresh-task-run \ --catalog-id \ --materialized-view-refresh-task-run-id \ --region ``` 또는 모든 최근 새로 고침 실행을 나열합니다. ``` aws glue list-materialized-view-refresh-task-runs \ --catalog-id \ --database-name \ --table-name \ --region ``` 이는 다음을 보여줍니다. + 마지막 새로 고침 시간 + 새로 고침 상태(SUCCEEDED, FAILED, RUNNING, STOPPED) + 작업 실행 ID + 오류 메시지(실패한 경우) 일반적인 새로 고침 상태: + 실행 중: 새로 고침 작업이 현재 실행 중입니다. + 성공: 새로 고침이 성공적으로 완료되었습니다. + FAILED: 새로 고침에 오류가 발생했습니다. + 중지됨: 새로 고침이 수동으로 취소됨 실패한 새로 고침 문제 해결: 새로 고침에 실패하면 다음을 확인합니다. 1. IAM 권한: 정의자 역할이 모든 기본 테이블 및 구체화된 뷰 위치에 액세스할 수 있는지 확인합니다. 1. 기본 테이블 가용성: 참조된 모든 테이블이 존재하고 액세스할 수 있는지 확인 1. 쿼리 유효성: SQL 쿼리가 Spark SQL 언어에 유효한지 확인 1. 리소스 제한: 계정의 동시 새로 고침 제한에 도달했는지 확인합니다. GetMaterializedViewRefreshTaskRun API를 사용하여 자세한 오류 메시지를 검색합니다. ## 고려 사항 및 제한 사항 + 구체화된 뷰는 AWS Glue 데이터 카탈로그에 기본 테이블로 등록된 Apache Iceberg 테이블만 참조할 수 있습니다. + 보기 생성 및 자동 쿼리 재작성은 Amazon Athena, Amazon EMR 및 AWS Glue (버전 5.1)에서 Apache Spark 버전 3.5.6 이상의 Spark 엔진에서만 사용할 수 있습니다. + 구체화된 뷰는 결국 기본 테이블과 일치합니다. 새로 고침 기간 동안 구체화된 뷰에 직접 액세스하는 쿼리는 오래된 데이터를 반환할 수 있습니다. 현재 데이터에 즉시 액세스하려면 수동 새로 고침을 실행합니다. + 최소 자동 새로 고침 간격은 1시간입니다. 더 자주 업데이트해야 하는 사용 사례의 경우 `REFRESH MATERIALIZED VIEW` 명령을 사용하여 프로그래밍 방식으로 수동 새로 고침을 실행합니다. + 쿼리 재작성은 성능보다 정확성을 우선시합니다. 구체화된 뷰가 오래되었거나 쿼리 요구 사항을 정확하게 충족할 수 없는 경우 Spark 엔진은 기본 테이블에 대해 원래 쿼리를 실행합니다. # Lake Formation의 워크플로를 사용하여 데이터 가져오기 AWS Lake Formation을 사용하면 *워크플로*를 사용하여 데이터를 가져올 수 있습니다. 워크플로는 데이터를 데이터 레이크로 가져오는 일정과 데이터 소스를 정의합니다. 워크플로는 데이터 레이크를 로드하고 업데이트하는 프로세스를 조정하는 데 사용되는 AWS Glue 크롤러, 작업 및 트리거를 위한 컨테이너입니다. **Topics** + [Lake Formation의 청사진 및 워크플로](workflows-about.md) + [워크플로 생성](workflows-creating.md) + [워크플로 실행](workflows-running.md) # Lake Formation의 청사진 및 워크플로 워크플로는 복잡한 다중 작업 추출, 전환, 적재(ETL) 활동을 캡슐화합니다. 워크플로는 데이터 로드 및 업데이트를 조정하기 위한 AWS Glue 크롤러, 작업 및 트리거를 생성합니다. Lake Formation은 워크플로를 단일 엔터티로 실행하고 추적합니다. 요청 시 또는 일정에 따라 실행되도록 워크플로를 구성할 수 있습니다. **참고** Spark parquet 라이터는 열 이름에 특수 문자를 지원하지 않습니다. 이는 라이터 자체의 기술적 제한이며 구성 문제가 아닙니다. Lake Formation에서 생성한 워크플로는 AWS Glue 콘솔에서 DAG(방향성 비순환 그래프)로 표시됩니다. 각 DAG 노드는 작업, 크롤러 또는 트리거입니다. 진행 상황을 모니터링하고 문제를 해결하기 위해 워크플로에서 각 노드의 상태를 추적할 수 있습니다. Lake Formation 워크플로가 완료되면 해당 워크플로를 실행한 사용자에게 워크플로가 생성하는 데이터 카탈로그 테이블에 대한 Lake Formation `SELECT` 권한이 부여됩니다. AWS Glue에서 워크플로를 생성할 수도 있습니다. 그러나 Lake Formation을 사용하면 청사진에서 워크플로를 생성할 수 있으므로 Lake Formation에서 워크플로를 생성하는 것이 훨씬 간단합니다. Lake Formation은 다음과 같은 유형의 청사진을 제공합니다. + **데이터베이스 스냅샷** - 모든 테이블의 데이터를 JDBC 소스의 데이터 레이크로 로드하거나 다시 로드합니다. 제외 패턴에 따라 소스에서 일부 데이터를 제외할 수 있습니다. + **증분 데이터베이스** - 이전에 설정한 북마크를 기반으로 JDBC 소스에서 데이터 레이크로 새 데이터만 로드합니다. 포함시킬 JDBC 소스 데이터베이스의 개별 테이블을 지정합니다. 각 테이블에 대해 북마크 열과 북마크 정렬 순서를 선택하여 이전에 로드된 데이터를 추적할 수 있습니다. 테이블 집합에 대해 증분 데이터베이스 청사진을 처음 실행하면 워크플로는 테이블에서 모든 데이터를 로드하고 다음 증분 데이터베이스 청사진 실행을 위한 북마크를 설정합니다. 따라서 데이터 소스의 각 테이블을 파라미터로 지정하기만 하면 데이터베이스 스냅샷 청사진 대신 증분 데이터베이스 청사진을 사용하여 모든 데이터를 로드할 수 있습니다. + **로그 파일** - AWS CloudTrail, Elastic Load Balancing 로그 및 Application Load Balancer 로그를 비롯한 로그 파일 소스에서 데이터를 대량으로 로드합니다. 다음 테이블을 참조하면 데이터베이스 스냅샷을 사용할지 증분 데이터베이스 청사진을 사용할지 결정하는 데 도움이 됩니다. | 데이터베이스 스냅샷 사용... | 증분 데이터베이스 사용... | | --- | --- | | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/lake-formation/latest/dg/workflows-about.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/lake-formation/latest/dg/workflows-about.html) | **참고** 사용자는 Lake Formation에서 생성한 청사진 및 워크플로를 편집할 수 없습니다. # 워크플로 생성 시작하기 전에 역할 `LakeFormationWorkflowRole`에 필요한 데이터 권한과 데이터 위치 권한을 부여했는지 확인합니다. 이는 워크플로가 데이터 카탈로그에 메타데이터 테이블을 생성하고 Amazon S3의 대상 위치에 데이터를 쓸 수 있도록 하기 위한 것입니다. 자세한 내용은 [(선택 사항) 워크플로에 대한 IAM 역할 생성](initial-lf-config.md#iam-create-blueprint-role) 및 [Lake Formation 권한 개요](lf-permissions-overview.md)(을)를 참조하세요. **참고** Lake Formation은 `GetTemplateInstance`, `GetTemplateInstances` 및 `InstantiateTemplate` 작업을 사용하여 블루프린트에서 워크플로를 생성합니다. 해당 작업은 공개적으로 사용할 수 없으며 사용자를 대신하여 리소스를 생성하기 위해 내부적으로만 사용됩니다. 워크플로 생성에 대한 CloudTrail 이벤트를 수신합니다. **청사진에서 워크플로를 생성하려면** 1. AWS Lake Formation 콘솔([https://console.aws.amazon.com/lakeformation/](https://console.aws.amazon.com/lakeformation/))을 엽니다. 데이터 레이크 관리자 또는 데이터 엔지니어 권한이 있는 사용자로 로그인합니다. 자세한 내용은 [Lake Formation 페르소나 및 IAM 권한 참조](permissions-reference.md) 섹션을 참조하세요. 1. 탐색 창에서 **청사진**을 선택한 다음 **청사진 사용**을 선택합니다. 1. **청사진 사용** 페이지에서 타일을 선택하여 청사진 유형을 선택합니다. 1. **소스 가져오기**에서 데이터 소스를 지정합니다. JDBC 소스에서 가져오는 경우 다음을 지정합니다. + ****데이터베이스 연결**** - 목록에서 연결을 선택합니다. AWS Glue 콘솔을 사용하여 추가 연결을 생성합니다. 연결의 JDBC 사용자 이름과 암호에 따라 워크플로가 액세스할 수 있는 데이터베이스 개체가 결정됩니다. + ****소스 데이터 경로**** - 데이터베이스 제품에 따라 **/**/*
* 또는 **/*
*을 입력합니다. Oracle Database 및 MySQL은 경로의 스키마를 지원하지 않습니다. ** 또는 *
* 대신에 백분율 문자(%)를 사용할 수 있습니다. 예를 들어 시스템 식별자(SID)가 `orcl`인 Oracle Database의 경우 `orcl/%`를 입력하여 연결에 이름이 지정된 사용자가 액세스할 수 있는 모든 테이블을 가져옵니다. **중요** 이 필드는 대/소문자를 구분합니다. 구성 요소 중 하나라도 대/소문자가 일치하지 않으면 워크플로가 실패합니다. MySQL 데이터베이스를 지정하는 경우 AWS Glue ETL은 기본적으로 Mysql5 JDBC 드라이버를 사용하므로 MySQL8은 기본적으로 지원되지 않습니다. *AWS Glue 개발자 안내서*의 [JDBC 연결 유형 값](https://docs.aws.amazon.com/glue/latest/dg/aws-glue-programming-etl-connect.html#aws-glue-programming-etl-connect-jdbc)에 설명된 대로 `customJdbcDriverS3Path` 파라미터를 사용하여 MySQL8을 지원하는 다른 JDBC 드라이버를 사용하도록 ETL 작업 스크립트를 편집할 수 있습니다. 로그 파일에서 가져오는 경우 워크플로에 지정한 역할('워크플로 역할')에 데이터 소스에 액세스하는 데 필요한 IAM 권한이 있는지 확인합니다. 예를 들어 AWS CloudTrail 로그를 가져오려면 사용자에게 워크플로를 생성하는 동안 CloudTrail 로그 목록을 볼 수 있는 `cloudtrail:DescribeTrails` 및 `cloudtrail:LookupEvents` 권한이 있어야 하고, 워크플로 역할에는 Amazon S3의 CloudTrail 위치에 대한 권한이 있어야 합니다. 1. 다음 중 하나를 수행합니다. + **데이터베이스 스냅샷** 청사진 유형의 경우 선택적으로 하나 이상의 제외 패턴을 지정하여 가져올 데이터의 하위 집합을 식별할 수 있습니다. 이러한 제외 패턴은 Unix 스타일 `glob` 패턴입니다. 이러한 패턴은 워크플로에서 생성한 테이블의 속성으로 저장됩니다. 사용 가능한 제외 패턴에 대한 자세한 내용은 *AWS Glue 개발자 안내서*의 [포함 및 제외 패턴](https://docs.aws.amazon.com/glue/latest/dg/define-crawler.html#crawler-data-stores-exclude)을 참조하세요. + **증분 데이터베이스** 청사진 유형의 경우 다음 필드를 지정합니다. 가져올 각 테이블에 대한 행을 추가합니다. **테이블 이름** 가져올 테이블. 모두 소문자여야 합니다. **북마크 키** 북마크 키를 정의하는 열 이름을 쉼표로 구분한 목록입니다. 비어 있는 경우 기본 키를 사용하여 새 데이터를 결정합니다. 각 열의 대/소문자는 데이터 소스에 정의된 대/소문자와 일치해야 합니다. 기본 키는 간격 없이 순차적으로 증가하거나 감소하는 경우에만 기본 북마크 키로 인정됩니다. 기본 키를 북마크 키로 사용하려는 경우 간격이 있다면 기본 키 열의 이름을 북마크 키로 지정해야 합니다. **북마크 순서** **오름차순**을 선택하는 경우 북마크 지정된 값보다 큰 값이 있는 행이 새 행으로 식별됩니다. **내림차순**을 선택하는 경우 북마크 지정된 값보다 작은 값이 있는 행이 새 행으로 식별됩니다. **파티셔닝 체계** (선택 사항) 슬래시(/) 로 구분된 파티션 키 열 목록. 예: ` year/month/day`. ![\[콘솔의 증분 데이터 섹션에는 테이블 이름, 북마크 키, 북마크 순서, 파티셔닝 체계와 같은 필드가 포함됩니다. 행을 추가하거나 제거할 수 있습니다. 여기서 각 행은 서로 다른 테이블에 대한 것입니다.\]](http://docs.aws.amazon.com/ko_kr/lake-formation/latest/dg/images/incremental-data.png) 자세한 내용은 *AWS Glue 개발자 안내서*의 [처리된 데이터를 작업 북마크로 추적](https://docs.aws.amazon.com/glue/latest/dg/monitor-continuations.html)을 참조하세요. 1. **가져오기 대상**에서 대상 데이터베이스, 대상 Amazon S3 위치 및 데이터 형식을 지정합니다. 워크플로 역할에 데이터베이스 및 Amazon S3 대상 위치에 대한 필수 Lake Formation 권한이 있는지 확인합니다. **참고** 현재 청사진은 대상에서의 데이터 암호화를 지원하지 않습니다. 1. 가져오기 빈도를 선택합니다. **사용자 지정** 옵션을 사용하여 `cron` 표현식을 지정할 수 있습니다. 1. **가져오기 옵션**에서: 1. 워크플로 이름을 입력합니다. 1. 역할의 경우 [(선택 사항) 워크플로에 대한 IAM 역할 생성](initial-lf-config.md#iam-create-blueprint-role)에서 생성한 `LakeFormationWorkflowRole` 역할을 선택합니다. 1. 필요한 경우 테이블 접두사를 지정합니다. 접두사는 워크플로에서 생성하는 데이터 카탈로그 테이블 이름 앞에 추가됩니다. 1. **생성**을 선택하고 콘솔에서 워크플로가 성공적으로 생성되었음을 보고할 때까지 기다립니다. **작은 정보** 다음과 같은 오류 메시지가 표시되나요? `User: arn:aws:iam:::user/ is not authorized to perform: iam:PassRole on resource:arn:aws:iam:::role/...` 그렇다면 모든 정책에서 **를 유효한 AWS 계정 번호로 바꾸었는지 확인하세요. **추가 참고:** [Lake Formation의 청사진 및 워크플로](workflows-about.md) # 워크플로 실행 Lake Formation 콘솔, AWS Glue 콘솔 또는 AWS Glue 명령줄 인터페이스(AWS CLI) 또는 API를 사용하여 워크플로를 실행할 수 있습니다. **워크플로를 실행하려면(Lake Formation 콘솔)** 1. AWS Lake Formation 콘솔([https://console.aws.amazon.com/lakeformation/](https://console.aws.amazon.com/lakeformation/))을 엽니다. 데이터 레이크 관리자 또는 데이터 엔지니어 권한이 있는 사용자로 로그인합니다. 자세한 내용은 [Lake Formation 페르소나 및 IAM 권한 참조](permissions-reference.md) 섹션을 참조하세요. 1. 탐색 창에서 [**블루프린트(Blueprints)**]를 선택합니다. 1. **청사진** 페이지에서 워크플로를 선택합니다. **작업** 메뉴에서 **시작**을 선택합니다. 1. 워크플로가 실행되면 **마지막 실행 상태** 열에서 진행 상황을 봅니다. 가끔 새로 고침 버튼을 선택합니다. 상태가 **실행 중**에서 **검색 중**, **가져오는 중**, **완료됨**으로 바뀝니다. 워크플로가 완료되면: + 데이터 카탈로그에 새 메타데이터 테이블이 포함됩니다. + 데이터가 데이터 레이크에 수집됩니다. 워크플로가 실패하면 다음을 수행합니다. 1. 워크플로를 선택합니다. **작업**을 선택한 후 **그래프 보기**를 선택합니다. 워크플로가 AWS Glue 콘솔에서 열립니다. 1. 워크플로가 선택되어 있는지 확인하고 [**기록(History)**] 탭을 선택합니다. 1. **기록**에서 가장 최근 실행을 선택하고 **실행 세부 정보 보기**를 선택합니다. 1. 동적(런타임) 그래프에서 실패한 작업이나 크롤러를 선택하고 오류 메시지를 검토합니다. 장애가 발생한 노드는 빨간색 또는 노란색입니다. **추가 참고:** [Lake Formation의 청사진 및 워크플로](workflows-about.md)