

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

# Memberikan akses lintas akun
<a name="cross-account-access"></a>

Memberikan akses ke sumber daya Katalog Data di seluruh akun memungkinkan tugas extract, transform, and load (ETL) untuk meng-kueri dan menggabungkan data dari akun yang berbeda.

**Topics**
+ [Metode untuk memberikan akses lintas akun di AWS Glue](#cross-account-how-works)
+ [Menambahkan atau memperbarui kebijakan sumber daya Katalog Data](#cross-account-adding-resource-policy)
+ [Melakukan panggilan API lintas akun](#cross-account-calling)
+ [Melakukan panggilan ETL lintas akun](#cross-account-calling-etl)
+ [Pencatatan lintas akun CloudTrail](#cross-account-ct-logs)
+ [Kepemilikan dan penagihan sumber daya lintas akun](#cross-account-ownership-and-billing)
+ [Batasan akses lintas akun](#cross-account-limitations)

## Metode untuk memberikan akses lintas akun di AWS Glue
<a name="cross-account-how-works"></a>

Anda dapat memberikan akses ke data Anda ke AWS akun eksternal dengan menggunakan AWS Glue metode atau dengan menggunakan hibah AWS Lake Formation lintas akun. AWS GlueMetode menggunakan kebijakan AWS Identity and Access Management (IAM) untuk mencapai kontrol akses berbutir halus. Lake Formation menggunakan model izin `GRANT/REVOKE` yang lebih sederhana yang mirip dengan perintah `GRANT/REVOKE` dalam sistem basis data relasional.

Bagian ini menjelaskan penggunaan AWS Glue metode. Untuk informasi tentang menggunakan pemberian Lake Formation lintas kaun, lihat [Memberikan Izin Lake Formation](https://docs.aws.amazon.com/lake-formation/latest/dg/lake-formation-permissions.html) di *Panduan Developer AWS Lake Formation *.

Ada dua AWS Glue metode untuk memberikan akses lintas akun ke sumber daya:
+ Menggunakan kebijakan sumber daya Katalog Data
+ Menggunakan sebuah IAM role

**Memberikan akses lintas akun menggunakan kebijakan sumber daya**  
Berikut ini adalah langkah-langkah umum untuk memberikan akses lintas akun menggunakan sebuah kebijakan sumber daya Katalog Data:

1. Administrator (atau identitas yang diotorisasi lainnya) di akun A melampirkan sebuah kebijakan sumber daya untuk Katalog Data di Akun A. Kebijakan ini memberikan kepada Akun B izin lintas akun tertentu untuk melakukan operasi pada sumber daya di katalog Akun A.

1. Administrator di Akun B melampirkan kebijakan IAM ke identitas IAM di Akun B yang mendelegasikan izin yang diterima dari Akun A.

   Identitas di Akun B sekarang memiliki akses ke sumber daya yang ditentukan di Akun A.

   *Identitas memerlukan izin dari pemilik sumber daya (Akun A) *dan* akun induknya (Akun B) untuk dapat mengakses sumber daya.*

**Memberikan akses lintas akun menggunakan sebuah IAM role**  
Berikut ini adalah langkah-langkah umum untuk memberikan akses lintas akun menggunakan sebuah IAM role:

1. Administrator (atau identitas yang mendapat otorisasi lainnya) di akun yang memiliki sumber daya (Akun A) menciptakan sebuah IAM role.

1. Administrator di Akun A melampirkan sebuah kebijakan pada peran yang memberikan izin lintas akun untuk mengakses ke sumber daya yang dimaksud.

1. Administrator di Akun A melampirkan sebuah kebijakan kepercayaan pada peran yang mengidentifikasi identitas IAM di akun yang berbeda (Akun B) sebagai prinsipal utama yang dapat mengambil peran tersebut.

   Prinsipal dalam kebijakan kepercayaan juga dapat menjadi kepala AWS layanan jika Anda ingin memberikan izin AWS layanan untuk mengambil peran tersebut.

1. Administrator di Akun B sekarang mendelegasikan izin untuk satu atau beberapa identitas IAM di Akun B sehingga mereka dapat mengambil peran itu. Dengan demikian, itu akan memberikan kepada identitas-identitas yang ada di Akun B akses ke sumber daya yang ada di Akun A.

Untuk informasi selengkapnya tentang cara menggunakan IAM untuk mendelegasikan izin, lihat [Manajemen Akses](https://docs.aws.amazon.com/IAM/latest/UserGuide/access.html) dalam *Panduan Pengguna IAM*. Untuk informasi lebih lanjut tentang pengguna, kelompok, peran, dan izin, lihat [Identitas (Pengguna, Grup, dan Peran)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html) dalam *Panduan Pengguna IAM*.

*Untuk perbandingan kedua pendekatan ini, lihat [Bagaimana peran IAM berbeda dari kebijakan berbasis sumber daya](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_compare-resource-policies.html) di Panduan Pengguna IAM.* AWS Gluemendukung kedua opsi, dengan batasan bahwa kebijakan sumber daya hanya dapat memberikan akses ke sumber daya Katalog Data.

Misalnya, untuk memberikan `Dev` peran di Akun B akses ke database `db1` di Akun A, lampirkan kebijakan sumber daya berikut ke katalog di Akun A.

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "glue:GetDatabase"
      ],
      "Principal": {
        "AWS": [
          "arn:aws:iam::111122223333:role/Dev"
        ]
      },
      "Resource": [
        "arn:aws:glue:us-east-1:111122223333:catalog",
        "arn:aws:glue:us-east-1:111122223333:database/db1"
      ]
    }
  ]
}
```

------

Selain itu, Akun B harus melampirkan kebijakan IAM berikut ke `Dev` peran sebelum benar-benar mendapatkan akses ke `db1` Akun A.

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "glue:GetDatabase"
      ],
      "Resource": [
        "arn:aws:glue:us-east-1:111122223333:catalog",
        "arn:aws:glue:us-east-1:111122223333:database/db1"
      ]
    }
  ]
}
```

------

## Menambahkan atau memperbarui kebijakan sumber daya Katalog Data
<a name="cross-account-adding-resource-policy"></a>

Anda dapat menambahkan atau memperbarui kebijakan sumber daya Katalog AWS Glue Data menggunakan konsol, API, atau AWS Command Line Interface (AWS CLI).

**penting**  
Jika Anda telah melakukan pemberian izin lintas akun dari akun Anda dengan AWS Lake Formation, untuk menambahkan atau memperbarui kebijakan sumber daya Katalog Data akan memerlukan sebuah langkah tambahan. Untuk informasi selengkapnya, lihat [Mengelola izin lintas akun menggunakan keduanya AWS Glue dan Lake Formation](https://docs.aws.amazon.com/lake-formation/latest/dg/hybrid-cross-account.html) di Panduan *AWS Lake Formation Pengembang*.  
Untuk menentukan apakah hibah lintas akun Lake Formation ada, gunakan operasi `glue:GetResourcePolicies` API atau. AWS CLI Jika `glue:GetResourcePolicies` mengembalikan kebijakan apa pun selain kebijakan Katalog Data yang sudah ada, maka hibah Lake Formation ada. Untuk informasi selengkapnya, lihat [Melihat semua hibah lintas akun menggunakan operasi GetResourcePolicies API di Panduan AWS Lake Formation](https://docs.aws.amazon.com/lake-formation/latest/dg/cross-account-getresourcepolicies.html) *Pengembang*.

**Untuk menambah atau memperbarui kebijakan sumber daya Katalog Data (konsol)**

1. Buka konsol AWS Glue di [https://console.aws.amazon.com/glue/](https://console.aws.amazon.com/glue/).

   Masuk sebagai pengguna administratif AWS Identity and Access Management (IAM) yang memiliki `glue:PutResourcePolicy` izin.

1. Pada panel navigasi, silakan pilih **Pengaturan**.

1. Pada halaman **Pengaturan katalog data**, pada **Izin**, tempel kebijakan sumber daya ke area teks. Lalu, pilih **Simpan**.

   Jika konsol tersebut menampilkan pemberitahuan yang menyatakan bahwa izin dalam kebijakan tersebut merupakan tambahan pada izin yang diberikan menggunakan Lake Formation, pilih **Lanjutkan**.

**Untuk menambah atau memperbarui kebijakan sumber daya Katalog Data (AWS CLI)**
+ Mengirimkan sebuah perintah `aws glue put-resource-policy`. Jika pemberian Lake Formation sudah ada, pastikan Anda menyertakan pilihan `--enable-hybrid` dengan nilai `'TRUE'`.

  Untuk contoh menggunakan perintah ini, lihat [Contoh kebijakan berbasis sumber daya untuk Glue AWS](security_iam_resource-based-policy-examples.md).

## Melakukan panggilan API lintas akun
<a name="cross-account-calling"></a>

Semua AWS Glue Data Catalog operasi memiliki `CatalogId` bidang. Jika izin yang diperlukan telah diberikan untuk mengaktifkan akses lintas akun, pemanggil dapat membuat panggilan API Katalog Data di seluruh akun. Pemanggil tersebut melakukan hal ini dengan memberikan ID akun AWS target di `CatalogId` sehingga dapat mengakses sumber daya di akun target tersebut.

Jika tidak ada `CatalogId` nilai yang diberikan, AWS Glue gunakan ID akun pemanggil sendiri secara default, dan panggilan tidak lintas akun.

## Melakukan panggilan ETL lintas akun
<a name="cross-account-calling-etl"></a>

Beberapa AWS Glue PySpark dan Scala APIs memiliki bidang ID katalog. Jika semua izin yang diperlukan telah diberikan untuk mengaktifkan akses lintas akun, tugas ETL dapat membuat PySpark dan Scala panggilan ke operasi API di seluruh akun dengan meneruskan ID AWS akun target di bidang ID katalog untuk mengakses sumber daya Katalog Data di akun target.

Jika tidak ada nilai ID katalog yang diberikan, AWS Glue gunakan ID akun pemanggil sendiri secara default, dan panggilan tidak lintas akun.

Untuk dukungan PySpark APIs itu`catalog_id`, lihat[GlueContext kelas](aws-glue-api-crawler-pyspark-extensions-glue-context.md). Untuk Scala APIs yang mendukung`catalogId`, lihat[AWS GlueScala GlueContext APIs](glue-etl-scala-apis-glue-gluecontext.md).

Contoh berikut menunjukkan izin yang diperlukan oleh penerima untuk menjalankan sebuah tugas ETL. Dalam contoh ini, *grantee-account-id* adalah klien yang menjalankan pekerjaan dan *grantor-account-id* merupakan pemilik sumber daya. `catalog-id` Contoh ini memberikan izin untuk semua sumber daya katalog di akun pemberi. Untuk membatasi ruang lingkup sumber daya yang diberikan, Anda dapat memberikan spesifik ARNs untuk katalog, database, tabel, dan koneksi.

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "glue:GetConnection",
        "glue:GetDatabase",
        "glue:GetTable",
        "glue:GetPartition"
      ],
      "Principal": {
        "AWS": [
          "arn:aws:iam::111122223333:root"
        ]
      },
      "Resource": [
        "arn:aws:glue:us-east-1:111122223333:*"
      ]
    }
  ]
}
```

------

**catatan**  
Jika sebuah tabel di akun pemberi mengarahkan ke lokasi Amazon S3 yang juga ada di akun pemberi, maka IAM role yang digunakan untuk menjalankan tugas ETL di akun penerima harus memiliki izin untuk mencantumkan dan mengambil objek dari akun pemberi.

Mengingat bahwa klien di Akun A sudah memiliki izin untuk membuat dan menjalankan tugas ETL, berikut ini adalah langkah-langkah dasar untuk mengatur tugas ETL untuk akses lintas akun:

1. Izinkan akses data lintas akun (lewati langkah ini jika akses lintas akun Amazon S3 sudah ditetapkan).

   1. Memperbarui kebijakan bucket Amazon S3 di Akun B untuk memungkinkan akses lintas-akun dari Akun A.

   1. Memperbarui kebijakan IAM di akun A untuk memungkinkan akses ke bucket yang ada di Akun B.

1. Izinkan akses Katalog Data lintas akun.

   1. Membuat atau memperbarui kebijakan sumber daya yang dilampirkan pada Katalog Data di Akun B untuk memungkinkan akses dari Akun A.

   1. Memperbarui kebijakan IAM di akun A untuk memungkinkan akses ke Katalog Data yang ada di Akun B.

## Pencatatan lintas akun CloudTrail
<a name="cross-account-ct-logs"></a>

Saat pekerjaan AWS Glue ekstrak, transformasi, dan muat (ETL) mengakses data dasar tabel Katalog Data yang dibagikan melalui hibah AWS Lake Formation lintas akun, ada perilaku pencatatan tambahan. AWS CloudTrail 

Untuk tujuan diskusi ini, AWS akun yang membagikan tabel adalah akun pemilik, dan akun tempat tabel dibagikan adalah akun penerima. Ketika pekerjaan ETL di akun penerima mengakses data dalam tabel di akun pemilik, CloudTrail peristiwa akses data yang ditambahkan ke log untuk akun penerima akan disalin ke log akun pemilik. CloudTrail Hal ini agar akun pemilik tersebut dapat melacak akses data oleh berbagai akun penerima. Secara default, CloudTrail peristiwa tidak menyertakan pengidentifikasi utama yang dapat dibaca manusia (ARN utama). Administrator yang ada di akun penerima dapat memilih untuk menyertakan ARN utama dalam log.

Untuk informasi selengkapnya, lihat [ CloudTrailLogging lintas akun](https://docs.aws.amazon.com/lake-formation/latest/dg/cross-account-logging.html) di *Panduan AWS Lake Formation Pengembang*.

**Lihat Juga**  
[Penebangan dan pemantauan di AWS Glue](logging-and-monitoring.md)

## Kepemilikan dan penagihan sumber daya lintas akun
<a name="cross-account-ownership-and-billing"></a>

Ketika pengguna dalam satu AWS akun (Akun A) membuat sumber daya baru seperti database di akun yang berbeda (Akun B), sumber daya tersebut kemudian dimiliki oleh Akun B, akun tempat pembuatannya. Administrator di Akun B secara otomatis mendapatkan izin penuh untuk mengakses sumber daya baru tersebut, termasuk untuk membaca, menulis, dan memberikan izin akses ke akun ketiga. Pengguna di Akun A dapat mengakses sumber daya yang baru mereka buat tersebut jika mereka memiliki izin yang sesuai yang diberikan oleh Akun B.

Biaya penyimpanan dan biaya lain yang secara langsung dikaitkan dengan sumber daya baru akan ditagih ke Akun B, pemilik sumber daya. Biaya permintaan dari pengguna yang membuat sumber daya ditagih ke akun peminta, yakni Akun A.

 Untuk informasi selengkapnya tentang AWS Glue penagihan dan harga, lihat [Cara Kerja AWS Harga](https://d0.awsstatic.com/whitepapers/aws_pricing_overview.pdf).

## Batasan akses lintas akun
<a name="cross-account-limitations"></a>

AWS Glueakses lintas akun memiliki batasan sebagai berikut:
+ Akses lintas akun ke tidak AWS Glue diizinkan jika Anda membuat database dan tabel menggunakan Amazon Athena atau Amazon Redshift Spectrum sebelum AWS Glue dukungan wilayah untuk dan akun pemilik sumber daya belum memigrasikan katalog data Amazon Athena ke. AWS Glue Anda dapat menemukan status migrasi saat ini menggunakan [GetCatalogImportStatus (get\$1catalog\$1import\$1status)](aws-glue-api-catalog-migration.md#aws-glue-api-catalog-migration-GetCatalogImportStatus). Untuk detail selengkapnya tentang cara memigrasikan katalog AWS Glue Athena, [lihat Memutakhirkan ke Panduan Pengguna AWS Glue Data Catalog step-by-step](https://docs.aws.amazon.com/athena/latest/ug/glue-upgrade.html) Amazon *Athena*.
+ Akses lintas akun didukung *hanya* untuk sumber daya Katalog Data, termasuk basis data, tabel, fungsi yang ditetapkan pengguna, dan koneksi.
+ Akses lintas akun ke Katalog Data dari Athena mengharuskan Anda mendaftarkan katalog sebagai sumber daya Athena`DataCatalog`. Untuk petunjuk, lihat [Mendaftarkan AWS Glue Data Catalog dari akun lain](https://docs.aws.amazon.com/athena/latest/ug/data-sources-glue-cross-account.html) di *Panduan Pengguna Amazon Athena*.