Halaman ini diterjemahkan oleh Cloud Translation API.

Kebijakan batas akses akun utama

Kebijakan batas akses akun utama (PAB) memungkinkan Anda membatasi resource yang dapat diakses akun utama.

Misalnya, Anda dapat menggunakan kebijakan batas akses akun utama untuk mencegah akun utama mengakses resource di organisasi lain, yang dapat membantu mencegah serangan phishing atau pemindahan data yang tidak sah.

Untuk mempelajari jenis kebijakan kontrol akses lainnya yang ditawarkan oleh Identity and Access Management (IAM), lihat Jenis kebijakan.

Cara kerja kebijakan batas akses akun utama

Secara default, akun utama memenuhi syarat untuk mengakses resource Google Cloud apa pun. Artinya, jika akun utama memiliki izin pada resource dan tidak ditolak izin tersebut, akun utama dapat menggunakan izin tersebut untuk mengakses resource.

Dengan kebijakan batas akses akun utama, Anda dapat membatasi resource yang layak diakses oleh akun utama. Jika kebijakan batas akses akun utama membuat akun utama tidak memenuhi syarat untuk mengakses resource, aksesnya ke resource tersebut akan dibatasi, terlepas dari peran yang diberikan kepadanya.

Saat akun utama mencoba mengakses resource yang tidak memenuhi syarat untuk diakses, kebijakan batas akses akun utama dapat memblokir beberapa, tetapi tidak semua, izin Identity and Access Management (IAM). Untuk mempelajari lebih lanjut izin yang diblokir, lihat Izin yang dapat diblokir oleh batas akses akun utama.

Kebijakan batas akses akun utama terdiri dari aturan batas akses akun utama. Setiap aturan batas akses akun utama menentukan kumpulan resource yang memenuhi syarat untuk diakses oleh akun utama yang terpengaruh. Anda dapat membuat hingga 1.000 kebijakan batas akses akun utama di organisasi Anda.

Setelah membuat kebijakan batas akses akun utama, Anda membuat binding kebijakan untuk menerapkan kebijakan ke kumpulan akun utama.

Akun utama dapat tunduk pada satu atau beberapa kebijakan batas akses akun utama. Setiap akun utama hanya memenuhi syarat untuk mengakses resource yang tercantum dalam kebijakan tersebut. Untuk semua resource lainnya, akses akun utama ke resource tersebut terbatas, meskipun Anda memberikan peran ke akun utama di resource tersebut.

Karena kebijakan batas akses akun utama dikaitkan dengan akun utama, bukan dengan resource, Anda dapat menggunakannya untuk mencegah akun utama mengakses resource yang tidak Anda miliki. Misalnya, perhatikan skenario berikut:

Kebijakan batas akses akun utama yang mencegah akses ke resource

Kepala sekolah Tal (tal@altostrat.com) adalah bagian dari organisasi Google Workspace altostrat.com.
Tal diberi peran Storage Admin (roles/storage.admin) di bucket Cloud Storage di organisasi lain, cymbalgroup.com. Peran ini berisi izin storage.objects.get, yang diperlukan untuk melihat objek di bucket.
Tidak ada kebijakan tolak di cymbalgroup.com yang mencegah Tal menggunakan izin storage.objects.get.

Dengan kebijakan izinkan dan tolak saja, altostrat.com tidak dapat mencegah Tal melihat objek di bucket eksternal ini. Tidak ada akun utama altostrat.com yang memiliki izin untuk mengedit kebijakan izin bucket, sehingga mereka tidak dapat mencabut peran Tal. Mereka juga tidak memiliki izin untuk membuat kebijakan penolakan di cymbalgroup.com, sehingga mereka tidak dapat menggunakan kebijakan penolakan untuk mencegah Tal mengakses bucket.

Namun, dengan kebijakan batas akses akun utama, administrator altostrat.com dapat memastikan bahwa Tal tidak dapat melihat objek di bucket cymbalgroup.com, atau bucket apa pun di luar altostrat.com. Untuk melakukannya, administrator dapat membuat kebijakan batas akses akun utama yang menyatakan bahwa akun utama altostrat.com hanya memenuhi syarat untuk mengakses resource di altostrat.com. Kemudian, mereka dapat membuat binding kebijakan untuk melampirkan kebijakan ini ke semua akun utama di organisasi altostrat.com. Dengan kebijakan tersebut, Tal tidak akan dapat melihat objek di bucket cymbalgroup.com, meskipun ia diberi peran Admin Storage di bucket.

Evaluasi fail-open

Selama Rilis pratinjau kebijakan batas akses akun utama, kebijakan batas akses akun utama akan gagal terbuka. Artinya, jika IAM tidak dapat mengevaluasi kebijakan batas akses akun utama, IAM akan mengabaikan kebijakan batas akses akun utama dan melanjutkan untuk mengevaluasi kebijakan izin dan tolak yang relevan.

Izin yang diblokir oleh kebijakan batas akses akun utama

Saat akun utama mencoba mengakses resource yang tidak memenuhi syarat untuk diakses, kebijakan batas akses akun utama akan mencegahnya menggunakan beberapa, tetapi tidak semua, izin Identity and Access Management (IAM) untuk mengakses resource.

Jika kebijakan batas akses akun utama memblokir izin, IAM akan menerapkan kebijakan batas akses akun utama untuk izin tersebut. Dengan kata lain, kebijakan ini mencegah akun utama yang tidak memenuhi syarat untuk mengakses resource agar tidak menggunakan izin tersebut untuk mengakses resource.

Jika kebijakan batas akses akun utama tidak memblokir izin, maka kebijakan batas akses akun utama tidak akan memengaruhi apakah akun utama dapat menggunakan izin tersebut.

Misalnya, bayangkan bahwa akun utama, Lee (lee@example.com), diberi peran Developer Dataflow (roles/dataflow.developer). Peran ini mencakup izin dataflow.jobs.snapshot, yang memungkinkan Lee mengambil snapshot tugas Dataflow. Lee juga tunduk pada kebijakan batas akses akun utama yang membuat dia tidak memenuhi syarat untuk mengakses resource di luar example.com. Namun, jika kebijakan batas akses akun utama tidak memblokir izin dataflow.jobs.snapshot, Lee masih dapat mengambil snapshot tugas Dataflow di organisasi di luar example.com.

Izin yang diblokir oleh kebijakan batas akses akun utama bergantung pada versi penegakan batas akses akun utama.

Versi penerapan batas akses akun utama

Setiap kebijakan batas akses akun utama menentukan versi penerapan, yang mengidentifikasi daftar izin IAM standar yang dapat diblokir oleh kebijakan batas akses akun utama. Anda menentukan versi penerapan saat membuat atau memperbarui kebijakan batas akses akun utama. Jika Anda tidak menentukan versi penerapan, IAM akan menggunakan versi penerapan terbaru, dan akan terus menggunakan versi tersebut hingga Anda mengupdatenya.

Secara berkala, IAM menambahkan versi penegakan batas akses akun utama baru yang dapat memblokir izin tambahan. Setiap versi baru juga dapat memblokir semua izin di versi sebelumnya.

Untuk memblokir izin dalam versi penerapan baru, Anda harus memperbarui kebijakan batas akses akun utama untuk menggunakan versi baru. Jika Anda ingin versi penerapan diupdate secara otomatis saat versi baru dirilis, Anda dapat menggunakan nilai latest saat membuat kebijakan. Namun, sebaiknya jangan gunakan nilai ini, karena dapat menyebabkan akun utama kehilangan akses ke resource secara tidak terduga.

Untuk mengetahui daftar lengkap izin yang diblokir oleh setiap versi penerapan, lihat Izin yang diblokir oleh kebijakan batas akses akun utama.

Mengikat kebijakan batas akses akun utama ke kumpulan akun utama

Untuk mengikat kebijakan batas akses akun utama ke kumpulan akun utama, Anda harus membuat binding kebijakan yang menentukan kebijakan batas akses akun utama yang ingin ditetapkan dan kumpulan akun utama yang ingin Anda terapkan. Setelah Anda mengikat kebijakan ke set akun utama, akun utama dalam set akun utama tersebut hanya dapat mengakses resource yang disertakan dalam aturan kebijakan batas akses akun utama.

Anda dapat mengikat kebijakan batas akses akun utama ke sejumlah kumpulan akun utama. Setiap kumpulan akun utama dapat memiliki hingga 10 kebijakan batas akses utama yang terikat.

Untuk mempelajari cara mengelola kebijakan batas akses akun utama, lihat Membuat dan menerapkan kebijakan batas akses akun utama.

Set utama yang didukung

Tabel berikut mencantumkan jenis kumpulan akun utama yang dapat Anda ikat ke kebijakan batas akses akun utama. Setiap baris berisi hal berikut:

Jenis akun utama yang ditetapkan
Akun utama dalam jenis kumpulan akun utama tersebut
Format ID untuk jenis kumpulan akun utama tersebut
Resource Pengelola Resource (project, folder, atau organisasi) yang menjadi induk binding kebijakan untuk jenis akun utama yang ditetapkan

Kumpulan akun utama	Detail	Resource induk binding kebijakan
Kumpulan identitas tenaga kerja	Berisi semua identitas dalam workforce identity pool yang ditentukan. Format: `//iam.googleapis.com/locations/global/workforcePools/WORKFORCE_POOL_ID`	Organisasi yang berisi kumpulan identitas tenaga kerja
Workload identity pool	Berisi semua identitas dalam workload identity pool yang ditentukan. Format: `//iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/WORKLOAD_POOL_ID`	Project yang berisi workload identity pool
Domain Google Workspace	Berisi semua identitas di domain Google Workspace yang ditentukan. Format: `//iam.googleapis.com/locations/global/workspace/WORKSPACE_ID` Anda dapat menemukan ID ruang kerja menggunakan metode berikut: Gunakan perintah `gcloud organizations describe`. ID ruang kerja Anda ada di kolom `directoryCustomerId` dalam respons. Gunakan metode `organizations.get` di Cloud Resource Manager API. ID ruang kerja Anda ada di kolom `directoryCustomerId` dalam respons. Lihat ID ruang kerja Anda di konsol Admin. Metode ini memerlukan peran admin super Google Workspace.	Organisasi yang terkait dengan domain Google Workspace
Kumpulan akun utama project	Berisi semua akun layanan dan workload identity pool dalam project yang ditentukan. Format: `//cloudresourcemanager.googleapis.com/projects/PROJECT_ID`	Project
Kumpulan akun utama folder	Berisi semua akun layanan dan semua workload identity pool dalam project apa pun di folder yang ditentukan. Format: `//cloudresourcemanager.googleapis.com/folders/FOLDER_ID`	Folder
Kumpulan akun utama organisasi	Berisi identitas berikut: Semua identitas di semua domain yang terkait dengan ID pelanggan Google Workspace Anda Semua kumpulan identitas tenaga kerja di organisasi Anda Semua akun layanan dan workload identity pool di project apa pun di organisasi Format: `//cloudresourcemanager.googleapis.com/organizations/ORGANIZATION_ID`	Organisasi

Binding kebijakan bersyarat untuk kebijakan batas akses akun utama

Anda dapat menggunakan ekspresi kondisi dalam binding kebijakan untuk kebijakan batas akses akun utama guna lebih memfilter akun utama yang menjadi sasaran kebijakan.

Ekspresi kondisi untuk binding kebijakan terdiri dari satu atau beberapa pernyataan yang digabungkan dengan maksimal 10 operator logis (&&, ||, atau !). Setiap pernyataan menyatakan aturan kontrol berbasis atribut yang berlaku untuk binding kebijakan, dan pada akhirnya menentukan apakah kebijakan berlaku.

Anda dapat menggunakan atribut principal.type dan principal.subject dalam kondisi untuk binding kebijakan. Tidak ada atribut lain yang didukung dalam kondisi untuk binding kebijakan.

Atribut principal.type menunjukkan jenis akun utama dalam permintaan—misalnya, akun layanan, atau identitas dalam workload identity pool. Anda dapat menggunakan kondisi dengan atribut ini untuk mengontrol jenis akun utama yang menjadi cakupan kebijakan batas akses akun utama.

Misalnya, jika Anda menambahkan ekspresi kondisi berikut ke binding untuk kebijakan batas akses akun utama, kebijakan tersebut hanya berlaku untuk akun layanan:
```
principal.type == 'iam.googleapis.com/ServiceAccount'
```
Atribut principal.subject menunjukkan identitas akun utama dalam permintaan—misalnya, cruz@example.com. Anda dapat menggunakan kondisi dengan atribut ini untuk mengontrol akun utama mana yang tunduk pada kebijakan batas akses akun utama.

Misalnya, jika Anda menambahkan ekspresi kondisi berikut ke binding untuk kebijakan batas akses akun utama, kebijakan tersebut tidak akan berlaku untuk pengguna special-admin@example.com:
```
principal.subject != 'special-admin@example.com'
```

Untuk mempelajari lebih lanjut nilai yang dapat Anda gunakan untuk kondisi ini, lihat referensi atribut kondisi.

Contoh: Menggunakan kondisi untuk mengurangi resource yang memenuhi syarat untuk diakses oleh akun utama

Salah satu cara Anda dapat menggunakan kondisi dalam binding kebijakan batas akses akun utama adalah dengan mengurangi resource yang memenuhi syarat untuk diakses oleh satu akun utama.

Bayangkan Anda memiliki akun layanan, dev-project-service-account, dengan alamat email dev-project-service-account@dev-project.iam.gserviceaccount.com. Akun layanan ini tunduk pada kebijakan batas akses akun utama yang membuat akun utama memenuhi syarat untuk mengakses semua resource di organisasi example.com. Kebijakan ini dilampirkan ke kumpulan akun utama organisasi example.com.

Anda memutuskan bahwa Anda tidak ingin dev-project-service-account memenuhi syarat untuk mengakses semua resource di example.com—Anda hanya ingin dev-project-service-account memenuhi syarat untuk mengakses resource di dev-project. Namun, Anda tidak ingin mengubah resource yang memenuhi syarat untuk diakses oleh akun utama lain dalam kumpulan akun utama example.com.

Untuk melakukan perubahan ini, Anda mengikuti prosedur untuk mengurangi resource yang layak diakses oleh akun utama, tetapi Anda menambahkan kondisi ke binding kebijakan, bukan menghapusnya:

Anda mengonfirmasi bahwa satu-satunya kebijakan batas akses akun utama yang diikuti dev-project-service-account adalah kebijakan yang membuat akun utama memenuhi syarat untuk mengakses semua resource di example.com.
Anda membuat kebijakan batas akses akun utama baru yang membuat akun utama memenuhi syarat untuk mengakses resource di dev-project dan melampirkannya ke akun utama yang ditetapkan untuk dev-project. Anda menggunakan kondisi berikut dalam binding kebijakan untuk memastikan bahwa kebijakan hanya diterapkan untuk dev-project-service-account:
```
"condition": {
  "title": "Only dev-project-service-account",
  "expression": "principal.type == 'iam.googleapis.com/ServiceAccount' && principal.subject == 'dev-project-service-account@dev-project.iam.gserviceaccount.com'"
}
```
Anda mengecualikan dev-project-service-account dari kebijakan batas akses akun utama yang membuat akun utama memenuhi syarat untuk mengakses semua resource di example.com. Untuk melakukannya, tambahkan kondisi berikut ke binding kebijakan yang melampirkan kebijakan batas akses akun utama tersebut ke kumpulan akun utama organisasi:
```
"condition": {
  "title": "Exempt dev-project-service-account",
  "expression": "principal.subject != 'dev-project-service-account@dev-project.iam.gserviceaccount.com' || principal.type != 'iam.googleapis.com/ServiceAccount'"
}
```
Untuk mempelajari cara memperbarui kebijakan batas akses akun utama yang ada, lihat Mengedit kebijakan batas akses akun utama.

Setelah Anda menambahkan kondisi ini ke binding kebijakan, dev-project-service-account tidak lagi memenuhi syarat untuk mengakses semua resource di example.com—sebaliknya, dev-project-service-account hanya memenuhi syarat untuk mengakses resource di dev-project.

Interaksi kebijakan

IAM mengevaluasi setiap kebijakan batas akses akun utama bersama dengan kebijakan izin dan tolak, serta dengan kebijakan batas akses akun utama lainnya. Semua kebijakan ini digunakan untuk menentukan apakah akun utama dapat mengakses resource.

Interaksi dengan jenis kebijakan lain

Saat akun utama mencoba mengakses resource, IAM mengevaluasi semua kebijakan batas akses akun utama, izinkan, dan tolak yang relevan untuk melihat apakah akun utama diizinkan untuk mengakses resource. Jika salah satu kebijakan ini menunjukkan bahwa akun utama tidak boleh mengakses resource, IAM akan mencegah akses.

Akibatnya, jika kebijakan batas akses akun utama akan mencegah akun utama mengakses resource, IAM akan mencegahnya mengakses resource tersebut, terlepas dari kebijakan izin dan tolak yang dilampirkan ke resource.

Selain itu, kebijakan batas akses akun utama saja tidak memberi akun utama akses ke resource. Meskipun kebijakan batas akses akun utama dapat membuat akun utama memenuhi syarat untuk mengakses resource, hanya kebijakan izin yang benar-benar dapat memberikan akses ke resource kepada akun utama.

Untuk mempelajari evaluasi kebijakan IAM lebih lanjut, lihat Evaluasi kebijakan.

Interaksi antara kebijakan batas akses akun utama

Jika kebijakan batas akses akun utama membuat akun utama memenuhi syarat untuk mengakses resource, akun utama tersebut memenuhi syarat untuk mengakses resource tersebut, terlepas dari kebijakan batas akses akun utama lainnya yang berlaku untuk akun utama tersebut. Akibatnya, jika akun utama sudah tunduk pada kebijakan batas akses akun utama, Anda tidak dapat menambahkan kebijakan batas akses akun utama untuk mengurangi akses akun utama.

Misalnya, bayangkan bahwa akun utama, Dana (dana@example.com), tunduk pada satu kebijakan batas akses akun utama, prod-projects-policy. Kebijakan ini membuat akun utama memenuhi syarat untuk mengakses resource di prod-project. Dana tunduk pada kebijakan ini karena terikat dengan kumpulan akun utama organisasinya.

Anda membuat kebijakan batas akses akun utama baru, dev-staging-projects-policy, yang membuat akun utama memenuhi syarat untuk mengakses resource di dev-project dan staging-project, lalu mengikatkannya ke kumpulan akun utama organisasi.

Sebagai akibat dari kebijakan batas akses akun utama ini, Dana memenuhi syarat untuk mengakses resource di dev-project, staging-project, dan prod-project.

Jika ingin mengurangi resource yang memenuhi syarat untuk diakses Dana, Anda harus mengubah atau menghapus kebijakan batas akses akun utama yang berlaku untuk Dana.

Misalnya, Anda dapat mengedit dev-staging-projects-policy sehingga tidak membuat akun utama memenuhi syarat untuk mengakses resource di dev-project. Kemudian, Dana hanya akan memenuhi syarat untuk mengakses resource di staging-project dan prod-project.

Atau, Anda dapat menghapus prod-projects-policy dengan menghapus binding kebijakan yang mengikat akun utama ke kumpulan akun utama organisasi. Kemudian, Dana hanya akan memenuhi syarat untuk mengakses resource di dev-project dan staging-project.

Namun, perubahan ini tidak hanya memengaruhi Dana—perubahan ini juga memengaruhi akun utama lain yang tunduk pada kebijakan dan binding batas akses akun utama yang diubah. Jika Anda ingin mengurangi resource yang dapat diakses oleh satu akun utama, gunakan binding kebijakan bersyarat.

Pewarisan kebijakan

Kebijakan batas akses akun utama dilampirkan ke set akun utama, bukan resource Resource Manager. Akibatnya, kebijakan tersebut tidak diwariskan melalui hierarki resource dengan cara yang sama seperti kebijakan izin dan penolakan.

Namun, set akun utama untuk resource induk Pengelola Resource—yaitu, folder dan organisasi—selalu menyertakan semua akun utama dalam set akun utama turunannya. Jadi, misalnya, jika akun utama disertakan dalam set akun utama project, akun utama tersebut juga disertakan dalam set akun utama folder atau organisasi induk.

Misalnya, pertimbangkan organisasi, example.com. Organisasi ini dikaitkan dengan domain example.com, dan memiliki resource Resource Manager berikut:

Hierarki resource untuk example.com

Organisasi, example.com
Project, project-1, yang merupakan turunan dari organisasi
Folder, folder-a, yang merupakan turunan dari organisasi
Dua project, project-2 dan project-3, yang merupakan turunan dari folder-a

Kumpulan akun utama resource ini berisi identitas berikut:

Kumpulan akun utama	Identitas Google Workspace di domain `example.com`	Kumpulan workforce identity federation di `example.com`	Akun layanan dan workload identity pool di `project-1`	Akun layanan dan workload identity pool di `project-2`	Akun layanan dan workload identity pool di `project-3`
Prinsipal ditetapkan untuk `example.com`
Prinsipal ditetapkan untuk `folder-a`
Prinsipal ditetapkan untuk `project-1`
Prinsipal ditetapkan untuk `project-2`
Prinsipal ditetapkan untuk `project-3`

Akibatnya, akun utama berikut terpengaruh oleh kebijakan batas akses akun utama berikut:

Identitas Google Workspace di domain example.com berada dalam kumpulan akun utama untuk example.com dan akan terpengaruh oleh kebijakan batas akses utama yang terikat dengan kumpulan akun utama tersebut.
Akun layanan di project-1 berada dalam kumpulan akun utama untuk project-1 dan example.com dan akan terpengaruh oleh kebijakan batas akses utama yang terikat ke salah satu kumpulan akun utama tersebut.
Akun layanan di project-3 berada dalam kumpulan akun utama untuk project-3, folder-a, dan example.com, dan akan terpengaruh oleh kebijakan batas akses akun utama yang terikat ke salah satu kumpulan akun utama tersebut.

Kebijakan batas akses akun utama dan resource yang di-cache

Layanan Google Cloud tertentu menyimpan cache resource yang dapat dilihat oleh publik. Misalnya, Cloud Storage menyimpan objek dalam cache yang dapat dibaca secara publik.

Apakah batas akses akun utama dapat mencegah akun utama yang tidak memenuhi syarat untuk melihat resource yang terlihat secara publik bergantung pada apakah resource di-cache:

Jika resource di-cache, batas akses akun utama tidak dapat mencegah akun utama melihat resource
Jika resource tidak di-cache, batas akses akun utama akan mencegah akun utama yang tidak memenuhi syarat melihat resource

Dalam semua kasus, kebijakan batas akses akun utama mencegah akun utama yang tidak memenuhi syarat untuk mengubah atau menghapus resource yang terlihat secara publik.

Struktur kebijakan batas akses akun utama

Kebijakan batas akses akun utama adalah kumpulan metadata dan detail kebijakan batas akses akun utama. Metadata memberikan informasi seperti nama kebijakan dan kapan kebijakan dibuat. Detail kebijakan menentukan fungsi kebijakan—misalnya, resource yang memenuhi syarat untuk diakses oleh akun utama yang terpengaruh.

Misalnya, kebijakan batas akses akun utama berikut membuat akun utama yang tunduk pada kebijakan tersebut memenuhi syarat untuk mengakses resource di organisasi dengan ID 0123456789012.

{
  "name": "organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-policy",
  "uid": "puid_0123456789012345678",
  "etag": "W/\"Gh/PcTdJD/AWHUhPW45kdw==\"",
  "displayName": "Example policy",
  "annotations": {
    "example-key": "example-value"
  },
  "createTime": "2024-01-02T15:01:23Z",
  "updateTime": "2024-01-02T15:01:23Z",
  "details": {
    "rules": [
      {
        "description": "Example principal access boundary policy rule",
        "resources": [
          "//cloudresourcemanager.googleapis.com/organizations/0123456789012"
        ],
        "effect": "ALLOW"
      }
    ],
    "enforcementVersion": "1"
  }
}

Bagian berikut menjelaskan kolom dalam metadata dan detail kebijakan batas akses utama.

Metadata

Kebijakan batas akses akun utama berisi metadata berikut:

name: Nama kebijakan batas akses akun utama. Nama ini memiliki format organizations/ORGANIZATION_ID/locations/global/principalAccessBoundaryPolicies/PAB_POLICY_ID, dengan ORGANIZATION_ID adalah ID numerik organisasi tempat kebijakan batas akses akun utama dibuat dan PAB_POLICY_ID adalah ID alfanumerik kebijakan batas akses akun utama.
uid: ID unik yang ditetapkan untuk kebijakan batas akses akun utama.
etag: ID untuk status kebijakan saat ini. Nilai ini berubah saat Anda memperbarui kebijakan. Untuk mencegah update yang bertentangan, nilai etag harus cocok dengan nilai yang disimpan di IAM. Jika nilai etag tidak cocok, permintaan akan gagal.
displayName: Nama yang dapat dibaca manusia untuk kebijakan batas akses akun utama.
annotations: Opsional. Daftar pasangan nilai kunci yang ditentukan pengguna. Anda dapat menggunakan anotasi ini untuk menambahkan metadata tambahan ke kebijakan—misalnya, siapa yang membuat kebijakan, atau apakah kebijakan di-deploy oleh pipeline otomatis. Untuk mengetahui informasi selengkapnya tentang anotasi, lihat Anotasi.
createTime: Waktu saat kebijakan batas akses akun utama dibuat.
updateTime: Waktu saat kebijakan batas akses akun utama terakhir diperbarui.

Detail

Setiap kebijakan batas akses akun utama berisi kolom details. Kolom ini berisi versi penerapan dan aturan batas akses utama:

rules: Daftar aturan batas akses akun utama, yang menentukan resource yang layak diakses oleh akun utama yang terpengaruh. Setiap aturan berisi kolom berikut:
- description: Deskripsi aturan yang dapat dibaca manusia.
- resources: Daftar resource Resource Manager (project, folder, dan organisasi) yang Anda inginkan agar dapat diakses oleh akun utama. Setiap prinsipal yang tunduk pada kebijakan ini memenuhi syarat untuk mengakses resource ini.
  
  Setiap kebijakan batas akses akun utama dapat mereferensikan maksimal 500 resource di semua aturan dalam kebijakan.
- effect: Hubungan yang dimiliki akun utama dengan resource yang tercantum di kolom resources. Satu-satunya efek yang dapat Anda tentukan dalam aturan batas akses akun utama adalah "ALLOW". Hubungan ini membuat akun utama memenuhi syarat untuk mengakses resource yang tercantum dalam aturan.
enforcementVersion: Versi penegakan yang digunakan IAM saat menerapkan kebijakan. Versi kebijakan batas akses akun utama menentukan izin yang dapat diblokir oleh kebijakan batas akses akun utama.

Untuk informasi selengkapnya tentang versi kebijakan batas akses akun utama, lihat Versi penerapan batas akses akun utama di halaman ini.

Struktur binding kebijakan

Binding kebijakan untuk kebijakan batas akses akun utama berisi nama kebijakan, nama akun utama yang ditetapkan untuk mengikat kebijakan, dan metadata yang menjelaskan binding kebijakan. Kebijakan ini juga dapat berisi kondisi yang mengubah akun utama yang menjadi sasaran kebijakan.

Misalnya, binding kebijakan berikut mengikat kebijakan example-policy ke semua akun utama di organisasi example.com, yang memiliki ID 0123456789012. Binding kebijakan juga berisi kondisi yang mencegah kebijakan diterapkan untuk akun utama super-admin@example.com.

{
  "name": "organizations/0123456789012/locations/global/policyBindings/example-policy-binding",
  "uid": "buid_01234567890123456789", 
  "etag": "W/\"cRMdDXbT82aLuZlvoL9Gqg==\"",
  "displayName": "Example policy binding",
  "annotations": {
    "example-key": "example-value"
  },
  "target": {
    "principalSet": "//cloudresourcemanager.googleapis.com/organizations/0123456789012"
  },
  "policyKind": "PRINCIPAL_ACCESS_BOUNDARY",
  "policy": "organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-policy",
  "policyUid": "puid_0123456789012345678",
  "condition": {
    "title": "Exempt principal",
    "description": "Don't enforce the policy for super-admin@example.com",
    "expression": "principal.subject != 'super-admin@example.com'"
  },
  "createTime": "2024-01-02T17:00:16Z",
  "updateTime": "2024-01-02T17:00:16Z"
}

Setiap binding kebijakan berisi kolom berikut:

name: Nama binding kebijakan. Nama ini memiliki format RESOURCE_TYPE/RESOURCE_ID/locations/global/policyBindings/BINDING_ID, dengan RESOURCE_TYPE/RESOURCE_ID adalah jenis dan ID resource induk binding kebijakan dan BINDING_ID adalah ID alfanumerik binding kebijakan.
uid: ID unik yang ditetapkan untuk binding kebijakan.
etag: ID untuk status kebijakan saat ini. Nilai ini berubah saat Anda memperbarui kebijakan. Untuk mencegah update yang bertentangan, nilai etag harus cocok dengan nilai yang disimpan di IAM. Jika nilai etag tidak cocok, permintaan akan gagal.
displayName: Nama yang dapat dibaca manusia untuk binding kebijakan.
annotations: Opsional. Daftar pasangan nilai kunci yang ditentukan pengguna. Anda dapat menggunakan anotasi ini untuk menambahkan metadata tambahan ke binding kebijakan—misalnya, siapa yang membuat binding kebijakan, atau apakah binding kebijakan di-deploy oleh pipeline otomatis. Untuk mengetahui informasi selengkapnya tentang anotasi, lihat Anotasi.
target: Entitas utama yang ditetapkan untuk mengikat kebijakan. Nilai ini memiliki format {"principalSet": PRINCIPAL_SET}, dengan PRINCIPAL_SET adalah ID kumpulan akun utama yang ingin Anda ikat dengan kebijakan.

Setiap target dapat memiliki hingga 10 kebijakan yang terikat dengannya.
policyKind: Jenis kebijakan yang dirujuk oleh binding kebijakan. Untuk binding kebijakan untuk kebijakan batas akses akun utama, nilai ini selalu PRINCIPAL_ACCESS_BOUNDARY.
policy: Kebijakan batas akses akun utama untuk mengikat ke kumpulan akun utama target.
policyUid: ID unik yang ditetapkan untuk kebijakan batas akses akun utama yang dirujuk di kolom policy.
condition: Opsional. Ekspresi logika yang memengaruhi akun utama yang akan dikenai kebijakan IAM. Jika kondisi bernilai benar atau tidak dapat dievaluasi, Identity and Access Management akan menerapkan kebijakan untuk akun utama yang membuat permintaan. Jika kondisi bernilai salah (false), Identity and Access Management tidak akan menerapkan kebijakan untuk akun utama. Untuk informasi selengkapnya, lihat Batasan dan kondisi akses akun utama di halaman ini.
createTime: Waktu saat binding kebijakan dibuat.
updateTime: Waktu saat binding kebijakan terakhir diperbarui.

Kasus penggunaan

Berikut adalah situasi umum saat Anda mungkin ingin menggunakan kebijakan batas akses akun utama, dan contoh kebijakan batas akses akun utama serta binding kebijakan yang dapat Anda buat dalam setiap situasi. Untuk mempelajari cara membuat kebijakan batas akses akun utama dan mengikatnya ke kumpulan akun utama, lihat Membuat dan menerapkan kebijakan batas akses akun utama.

Membatasi akun utama ke resource di organisasi Anda

Anda dapat menggunakan kebijakan batas akses akun utama untuk memastikan bahwa akun utama di organisasi Anda hanya memenuhi syarat untuk mengakses resource dalam organisasi Anda.

Misalnya, bayangkan Anda ingin memastikan bahwa semua akun utama di organisasi example.com hanya memenuhi syarat untuk mengakses resource dalam example.com. Akun utama yang ada di example.com mencakup semua identitas di domain example.com, semua kumpulan identitas tenaga kerja di example.com, dan semua akun layanan dan kumpulan identitas beban kerja di project apa pun di example.com.

Anda tidak memiliki kebijakan batas akses akun utama yang berlaku untuk akun utama apa pun di organisasi Anda. Akibatnya, semua akun utama memenuhi syarat untuk mengakses semua resource.

Agar akun utama tidak memenuhi syarat untuk mengakses resource di luar example.com, Anda harus membuat kebijakan batas akses akun utama yang membuat akun utama memenuhi syarat untuk mengakses resource di example.com:

{
  "name": "organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-org-only",
  "displayName": "Boundary for principals in example.org",
  "details": {
    "rules": [
      {
        "description": "Principals are only eligible to access resources in example.org",
        "resources": [
            "//cloudresourcemanager.googleapis.com/organizations/0123456789012"
        ],
        "effect": "ALLOW"
      }
    ],
    "enforcementVersion": "1"
  }
}

Kemudian, Anda membuat binding kebijakan untuk mengikat kebijakan ini ke kumpulan akun utama:

{
  "name": "organizations/0123456789012/locations/global/policyBindings/example-org-only-binding",
  "displayName": "Bind policy to all principals in example.com",
  "target": {
    "principalSet": "//cloudresourcemanager.googleapis.com/organizations/0123456789012"
  },
  "policyKind": "PRINCIPAL_ACCESS_BOUNDARY",
  "policy": "organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-org-only"
}

Sekarang, semua akun utama di example.com hanya memenuhi syarat untuk mengakses resource di example.com. Akun utama tersebut dicegah untuk menggunakan izin yang diblokir oleh kebijakan batas akses akun utama untuk mengakses resource di luar example.com, meskipun akun utama tersebut memiliki izin tersebut di resource tersebut.

Membatasi akun layanan ke resource dalam satu project

Anda dapat menggunakan kebijakan batas akses akun utama untuk memastikan bahwa akun layanan di project tertentu hanya memenuhi syarat untuk mengakses resource dalam project tersebut.

Misalnya, bayangkan Anda memiliki project, example-dev. Anda ingin memastikan bahwa akun layanan di example-dev hanya memenuhi syarat untuk mengakses resource di example-dev.

Anda memiliki kebijakan batas akses akun utama yang membuat semua akun utama di organisasi, termasuk akun layanan di example-dev, memenuhi syarat untuk mengakses resource di example.com. Untuk melihat tampilan jenis kebijakan ini, lihat Membatasi akun utama ke resource di organisasi Anda.

Agar akun layanan di example-dev tidak memenuhi syarat untuk mengakses resource di luar example-dev, Anda harus membuat kebijakan batas akses akun utama terlebih dahulu yang membuat akun utama memenuhi syarat untuk mengakses resource di example-dev

{
  "name": "organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-dev-only",
  "displayName": "Boundary for principals in example-dev",
  "details": {
    "rules": [
      {
        "description": "Principals are only eligible to access resources in example-dev",
        "resources": [
          "//cloudresourcemanager.googleapis.com/projects/example-dev"
        ],
        "effect": "ALLOW"
      }
    ],
    "enforcementVersion": "1"
  }
}

Kemudian, Anda membuat binding kebijakan untuk mengikat kebijakan ini ke semua akun utama di example-dev, dan menambahkan kondisi agar binding kebijakan hanya berlaku untuk akun layanan:

{
  "name": "organizations/0123456789012/locations/global/policyBindings/example-dev-only-binding",
  "displayName": "Bind policy to all service accounts in example-dev",
  "target": {
    "principalSet": "//cloudresourcemanager.googleapis.com/projects/example-dev"
  },
  "policyKind": "PRINCIPAL_ACCESS_BOUNDARY",
  "policy": "organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-dev-only",
  "condition": {
    "title": "Only service accounts",
    "description": "Only enforce the policy if the principal in the request is a service account",
    "expression": "principal.type == 'iam.googleapis.com/ServiceAccount'"
  }
}

Namun, kebijakan ini sendiri tidak membatasi kelayakan akun layanan. Hal ini karena ada kebijakan batas akses akun utama yang membuat semua akun utama di example.com memenuhi syarat untuk mengakses semua resource di example.com. Kebijakan batas akses akun utama bersifat aditif, sehingga akun layanan di example-dev masih memenuhi syarat untuk mengakses semua resource di example.com.

Untuk memastikan bahwa akun layanan di example-dev hanya memenuhi syarat untuk mengakses resource di example-dev, Anda perlu menambahkan kondisi ke binding kebijakan untuk kebijakan batas akses akun utama yang ada yang mencegahnya diterapkan untuk akun layanan di example-dev:

{
  "name": "organizations/0123456789012/locations/global/policyBindings/example-org-only-binding",
  "displayName": "Bind policy to all principals in example.com",
  "target": {
    "principalSet": "//cloudresourcemanager.googleapis.com/organizations/0123456789012"
  },
  "policyKind": "PRINCIPAL_ACCESS_BOUNDARY",
  "policy": "organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-org-only",
  "condition": {
    "title": "Exempt example-dev service accounts",
    "description": "Don't enforce the policy for service accounts in the example-dev project",
    "expression": "principal.type != 'iam.googleapis.com/ServiceAccount' || !principal.subject.endsWith('@example-dev.iam.gserviceaccount.com')"
  }
}

Sekarang, akun layanan di example-dev hanya memenuhi syarat untuk mengakses resource di example-dev. Akun utama tersebut dicegah untuk menggunakan izin yang diblokir oleh kebijakan batas akses akun utama untuk mengakses resource di luar example-dev, meskipun akun utama tersebut memiliki izin tersebut pada resource tersebut.

Langkah selanjutnya

Pelajari cara membuat dan menerapkan kebijakan batas akses akun utama.
Tinjau izin yang diblokir oleh setiap versi penerapan kebijakan batas akses akun utama.