Kebijakan batas akses utama

Kebijakan Principal Access Boundary (PAB) memungkinkan Anda menentukan resource yang dapat diakses oleh akun utama.

Kebijakan terkait akses lainnya, seperti kebijakan izinkan dan tolak, dilampirkan ke resource. Kebijakan ini menentukan siapa yang diizinkan untuk mengakses resource yang dilampirkan. Sebaliknya, kebijakan Batas Akses Akun Utama (PAB) dilampirkan ke set akun utama dan mengontrol apa yang boleh dilakukan oleh akun utama dalam set akun utama.

Misalnya, Anda dapat menggunakan kebijakan Batas Akses Principal untuk mencegah principal Anda mengakses resource di organisasi lain, yang dapat membantu mencegah serangan phishing atau pemindahan data yang tidak sah.

Cara kerja kebijakan Batas Akses Principal

Secara default, akun utama memenuhi syarat untuk mengakses resource Cloud de Confiance by S3NS apa pun. Artinya, jika kebijakan izinkan memberikan akses akun utama ke resource dan tidak ada kebijakan tolak yang memblokir akses tersebut, maka akun utama dapat mengakses resource.

Dengan kebijakan Principal Access Boundary, Anda dapat menentukan resource yang memenuhi syarat untuk diakses oleh akun utama. Jika akun utama tidak memenuhi syarat untuk mengakses resource, maka aksesnya ke resource tersebut dibatasi, terlepas dari peran yang telah diberikan kepadanya. Untuk mengetahui informasi selengkapnya tentang cara menggunakan kebijakan Batas Akses Akun Utama untuk menentukan resource yang memenuhi syarat untuk diakses oleh akun utama, lihat Menentukan resource yang memenuhi syarat.

Kebijakan Principal Access Boundary hanya memblokir upaya akses yang melibatkan izin yang didukung. Jika kebijakan Batas Akses Akun Utama tidak dapat memblokir izin, maka akun utama memenuhi syarat untuk menggunakan izin tersebut guna mengakses resource apa pun, terlepas dari kebijakan yang berlaku untuknya. Untuk mengetahui informasi selengkapnya, lihat Izin yang dapat diblokir oleh kebijakan Batas Akses Akun Utama.

Kasus penggunaan

Kebijakan Batas Akses Akun Utama berguna dalam situasi seperti berikut:

• Mencegah prinsipal mengakses resource yang tidak Anda miliki
• Membatasi jenis akun utama tertentu, seperti akun layanan, untuk project tertentu

Untuk mengetahui contoh mendetail tentang cara menggunakan kebijakan Principal Access Boundary dalam situasi seperti ini, lihat Contoh kasus penggunaan untuk kebijakan Principal Access Boundary.

Komponen kebijakan Principal Access Boundary

Kebijakan Batas Akses Utama (PAB) terdiri dari aturan individual. Setiap aturan menentukan serangkaian resource yang memenuhi syarat untuk diakses oleh akun utama. Setiap kebijakan dapat memiliki hingga 500 aturan.

Kebijakan juga berisi informasi lain, termasuk metadata dan detail konfigurasi. Untuk mengetahui informasi selengkapnya, lihat Struktur kebijakan Batas Akses Akun Utama.

Setelah membuat kebijakan Batas Akses Akun Utama, Anda menerapkan kebijakan tersebut ke sekumpulan akun utama dengan membuat pengikatan kebijakan. Semua akun utama dalam set akun utama tersebut kemudian tunduk pada kebijakan Batas Akses Akun Utama tersebut, yang berarti akun utama tersebut memenuhi syarat untuk mengakses resource yang tercantum dalam kebijakan. Anda dapat mengikat kebijakan Batas Akses Akun Utama ke sejumlah set akun utama.

Anda dapat membuat hingga 1.000 kebijakan batas akses utama di organisasi Anda.

Izin yang diblokir oleh kebijakan Batas Akses Utama

Kebijakan Batas Akses Akun Utama dapat memblokir semua izin yang disertakan dalam versi penerapan kebijakan. Jika kebijakan Batas Akses Akun Utama dapat memblokir izin, maka kebijakan tersebut dapat mencegah akun utama yang tidak memenuhi syarat menggunakan izin tersebut untuk mengakses resource.

Anda menentukan versi penerapan kebijakan saat membuat kebijakan. Memperbarui versi penegakan akan memperbarui izin yang dapat diblokir oleh kebijakan. Untuk mengetahui daftar lengkap izin yang diblokir oleh setiap versi penegakan, lihat referensi versi penegakan.

Jika kebijakan Batas Akses Akun Utama tidak dapat memblokir izin, maka kebijakan tersebut tidak berpengaruh pada apakah akun utama dapat menggunakan izin tersebut atau tidak. Dengan kata lain, IAM tidak dapat menerapkan kebijakan untuk upaya akses yang melibatkan izin tersebut.

Misalnya, anggaplah bahwa akun utama, Lee (lee@example.com), diberi peran Dataflow Developer (roles/dataflow.developer). Peran ini mencakup izin dataflow.googleapis.com/jobs.snapshot, yang memungkinkan Lee mengambil snapshot tugas Dataflow. Lee juga tunduk pada kebijakan Batas Akses Akun Utama yang membuatnya tidak memenuhi syarat untuk mengakses resource di luar example.com. Namun, jika kebijakan Batas Akses Akun Utama tersebut tidak dapat memblokir izin dataflow.jobs.snapshot, Lee masih dapat mengambil snapshot tugas Dataflow di organisasi di luar example.com.

Mengelola versi penegakan

Secara berkala, IAM menambahkan versi penerapan baru yang dapat memblokir izin tambahan. Setiap versi baru juga dapat memblokir semua izin dalam versi sebelumnya.

Untuk memblokir izin dalam versi penerapan baru, Anda harus memperbarui kebijakan Batas Akses Principal untuk menggunakan versi baru.

Jika ingin versi penerapan kebijakan diperbarui secara otomatis saat versi baru dirilis, Anda dapat menggunakan nilai latest saat membuat kebijakan. Namun, sebaiknya jangan gunakan nilai ini karena dapat menyebabkan prinsipal kehilangan akses ke resource secara tidak terduga.

Kebijakan yang menggunakan latest untuk nomor versi menggunakan versi penerapan default. Versi penerapan default biasanya adalah versi terbaru. Namun, diperlukan waktu hingga 4 minggu agar versi baru menjadi versi penerapan default. Untuk mempelajari versi penerapan mana yang default, lihat referensi versi penerapan.

Versi penerapan default juga digunakan untuk kebijakan Batas Akses Akun Utama baru yang tidak menentukan nomor versi.

Menentukan resource yang memenuhi syarat

Akun utama dapat terpengaruh oleh, atau tunduk pada, sejumlah kebijakan Batas Akses Akun Utama. Bersama-sama, kebijakan ini menentukan resource yang memenuhi syarat untuk diakses oleh akun utama.

Kebijakan Principal Access Boundary bersifat kumulatif. Artinya, resource yang dapat diakses oleh prinsipal adalah gabungan dari semua resource dalam semua kebijakan Principal Access Boundary yang tunduk pada prinsipal tersebut. Dengan kata lain, jika satu kebijakan Batas Akses Akun Utama membuat akun utama memenuhi syarat untuk mengakses resource, maka akun utama tersebut memenuhi syarat untuk mengakses resource, terlepas dari kebijakan Batas Akses Akun Utama lainnya yang berlaku untuknya.

Jika akun utama tidak tunduk pada kebijakan Principal Access Boundary, maka akun utama tersebut berhak mengakses resource Cloud de Confiance apa pun.

Bagian berikut menjelaskan cara menyesuaikan kumpulan resource yang dapat diakses oleh prinsipal.

Menambahkan resource yang memenuhi syarat

Ada beberapa cara untuk membuat prinsipal memenuhi syarat untuk mengakses resource yang tidak memenuhi syarat untuk diakses:

• Tambahkan resource ke kebijakan Principal Access Boundary yang tunduk pada akun utama.
• Buat kebijakan Batas Akses Akun Utama baru dengan resource tambahan dan ikat kebijakan ke set akun utama yang menyertakan akun utama.
• Hapus semua kebijakan Batas Akses Akun Utama yang berlaku untuk akun utama. Tindakan ini membuat akun utama memenuhi syarat untuk mengakses semua Cloud de Confiance resource.

Menghapus resource yang memenuhi syarat

Ada beberapa cara untuk membuat prinsipal tidak memenuhi syarat untuk mengakses resource yang memenuhi syarat untuk diaksesnya.

Pertama, temukan semua kebijakan Batas Akses Akun Utama yang tunduk pada akun utama yang mencakup resource. Berdasarkan kebijakan yang Anda temukan, Anda dapat melakukan salah satu hal berikut:

• Jika akun utama tidak tunduk pada kebijakan Batas Akses Akun Utama, maka buat kebijakan Batas Akses Akun Utama baru yang hanya mencakup resource yang Anda inginkan agar akun utama memenuhi syarat untuk mengaksesnya. Kemudian, ikat kebijakan tersebut ke set akun utama yang berisi akun utama.

  Setelah Anda menerapkan kebijakan, akun utama akan beralih dari yang memenuhi syarat untuk mengakses semua resource menjadi hanya memenuhi syarat untuk mengakses resource yang tercantum dalam kebijakan.

• Jika akun utama sudah tunduk pada satu atau beberapa kebijakan Batas Akses Akun Utama, Anda harus memastikan bahwa tidak ada kebijakan Batas Akses Akun Utama yang tunduk padanya yang menyertakan resource. Untuk mengetahui petunjuk langkah demi langkah, lihat Mengurangi resource yang dapat diakses oleh akun utama.

  Selama proses ini, Anda harus memastikan bahwa prinsipal selalu tunduk pada setidaknya satu kebijakan Principal Access Boundary. Jika tidak, akun utama mungkin memenuhi syarat untuk mengakses semua resource.

Kebijakan Batas Akses Utama dan resource yang di-cache

Layanan Cloud de Confiance by S3NS tertentu menyimpan cache resource yang terlihat secara publik. Misalnya, Cloud Storage meng-cache objek yang dapat dibaca oleh publik.

Apakah kebijakan Batas Akses Akun Utama dapat mencegah akun utama yang tidak memenuhi syarat melihat resource yang terlihat secara publik bergantung pada apakah resource di-cache:

• Jika resource di-cache, kebijakan 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 Principal Access Boundary tetap mencegah akun utama yang tidak memenuhi syarat memodifikasi atau menghapus resource yang terlihat secara publik.

Evaluasi kebijakan Principal Access Boundary

Saat akun utama mencoba mengakses resource, IAM mengevaluasi kebijakan Principal Access Boundary yang relevan untuk menentukan apakah akan memblokir upaya akses tersebut. Kebijakan relevan jika akun utama yang melakukan upaya akses tunduk pada kebijakan tersebut.

Kebijakan Principal Access Boundary hanya dapat memblokir atau tidak memblokir akses—kebijakan ini tidak dapat memberikan akses. Hanya kebijakan izinkan yang benar-benar dapat memberikan akses akun utama ke resource. Untuk mempelajari pengaruh berbagai jenis kebijakan terhadap akses pokok ke resource, lihat Jenis kebijakan.

IAM tidak memblokir akses jika salah satu hal berikut berlaku:

• Akun utama tidak tunduk pada kebijakan Principal Access Boundary (PAB) apa pun
• Kebijakan Batas Akses Utama (PAB) yang relevan tidak dapat memblokir izin dalam permintaan
• Kebijakan Batas Akses Akun Utama membuat akun utama memenuhi syarat untuk mengakses resource

IAM memang memblokir akses jika akun utama tunduk pada setidaknya satu kebijakan Batas Akses Akun Utama, tetapi tidak ada kebijakan yang relevan yang membuat akun utama memenuhi syarat untuk mengakses resource.

Evaluasi gagal-tertutup

Kebijakan Principal Access Boundary (PAB) gagal ditutup. Artinya, jika IAM mengalami error saat mengevaluasi kebijakan Batas Akses Akun Utama, IAM akan mencegah akun utama mengakses resource.

Alasan paling umum IAM mengalami error saat mengevaluasi kebijakan Batas Akses Akun Utama adalah karena detail akun utama masih disalurkan melalui sistem. Hal ini kemungkinan besar terjadi pada pengguna yang baru dibuat. Untuk mengatasi masalah ini, minta prinsipal baru menunggu dan mencoba mengakses resource lagi nanti.

Menerapkan kebijakan Batas Akses Utama ke set akun utama

Untuk menerapkan kebijakan Batas Akses Akun Utama ke set akun utama, Anda membuat pengikatan kebijakan yang menentukan kebijakan Batas Akses Akun Utama yang ingin Anda terapkan dan set akun utama yang ingin Anda terapkan kebijakan tersebut. Pengikatan kebijakan ini mengikat kebijakan ke set akun utama.

Setelah Anda mengikat kebijakan ke set utama, akun utama dalam set utama tersebut hanya dapat mengakses resource yang tercantum dalam kebijakan Batas Akses Akun Utama yang berlaku untuknya.

Anda dapat mengikat kebijakan Batas Akses Akun Utama ke sejumlah set akun utama. Setiap set akun utama dapat memiliki hingga 10 kebijakan Batas Akses Akun Utama yang terikat dengannya.

Anda hanya dapat membuat pengikatan untuk kebijakan Batas Akses Utama yang ada. Mencoba membuat pengikatan untuk kebijakan Batas Akses Utama yang dihapus akan gagal. Jika Anda baru saja menghapus kebijakan Batas Akses Akun Utama, terkadang Anda dapat berhasil membuat binding, tetapi binding tersebut tidak akan berpengaruh. IAM membersihkan binding ini secara otomatis.

Untuk mempelajari cara mengelola kebijakan Batas Akses Principal, lihat Membuat dan menerapkan kebijakan Batas Akses Principal.

Kumpulan prinsipal yang didukung

Tabel berikut mencantumkan jenis set akun utama yang dapat Anda ikat dengan kebijakan Batas Akses Akun Utama. Setiap baris berisi hal berikut:

• Jenis set utama
• Entitas utama dalam jenis set entitas utama tersebut
• Format ID untuk jenis set utama tersebut
• Resource Resource Manager (project, folder, atau organisasi) yang mengandung binding kebijakan untuk jenis set akun utama tersebut

Pewarisan kebijakan dan set utama

Kebijakan Batas Akses Utama (PAB) dilampirkan ke set utama, bukan resource. Akibatnya, kebijakan ini tidak diwariskan melalui hierarki resource dengan cara yang sama seperti kebijakan izinkan dan tolak.

Namun, set akun utama untuk 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 berikut:

• 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:

Akibatnya, pokok berikut terpengaruh oleh kebijakan Batas Akses Pokok (PAB) berikut:

• Identitas Google Workspace di domain example.com berada dalam kumpulan akun utama untuk example.com dan akan terpengaruh oleh kebijakan Batas Akses Akun Utama yang terikat dengan kumpulan akun utama tersebut.

• Akun layanan di project-1 berada di set akun utama untuk project-1 dan example.com dan akan terpengaruh oleh kebijakan Batas Akses Akun Utama yang terikat ke salah satu set akun utama tersebut.

• Identitas agen di project-3 berada di set akun utama untuk project-3, folder-a, dan example.com, dan akan terpengaruh oleh kebijakan Batas Akses Akun Utama yang terikat ke salah satu set akun utama tersebut.

Pengikatan kebijakan bersyarat untuk kebijakan Batas Akses Utama

Anda dapat menggunakan ekspresi kondisi dalam binding kebijakan untuk kebijakan Batas Akses Akun Utama guna lebih menyempurnakan akun utama yang akan menerapkan 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.

• Atribut principal.type mengacu pada jenis akun utama yang membuat permintaan—misalnya, akun layanan atau identitas agen. Anda dapat menggunakan kondisi dengan atribut ini untuk mengontrol jenis principal yang dicakup oleh kebijakan Batas Akses Principal.

  Misalnya, jika Anda menambahkan ekspresi kondisi berikut ke binding untuk kebijakan Batas Akses Akun Utama, maka kebijakan hanya berlaku untuk akun layanan:

  principal.type == 'iam.googleapis.com/ServiceAccount'
  

• Atribut principal.subject mengacu pada identitas akun utama yang membuat permintaan—misalnya, cruz@example.com. Anda dapat menggunakan kondisi dengan atribut ini untuk mengontrol secara tepat principal mana yang tunduk pada kebijakan Batas Akses Principal.

  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.

Untuk contoh cara menggunakan kondisi ini dalam kebijakan Batas Akses Akun Utama, lihat Membuat akun layanan memenuhi syarat untuk mengakses resource dalam satu project.

Binding kebijakan lintas organisasi

Anda tidak dapat membuat pengikatan kebijakan lintas organisasi untuk kebijakan Batas Akses Akun Utama. Pengikatan kebijakan lintas organisasi adalah pengikatan kebijakan yang mengikat kebijakan di satu organisasi ke set akun utama di organisasi lain.

IAM secara berkala menghapus binding kebijakan lintas organisasi yang ada. Binding kebijakan lintas organisasi dapat terjadi saat Anda memindahkan project dari satu organisasi ke organisasi lain. Misalnya, pertimbangkan situasi berikut:

• Anda memiliki project, example-project, di organisasi example.com.
• Anda ingin akun utama di example-project memenuhi syarat untuk mengakses resource di example.com. Untuk melakukannya, Anda membuat kebijakan Batas Akses Principal di example.com yang membuat principal memenuhi syarat untuk mengakses resource di example.com dan mengikat kebijakan tersebut ke set principal untuk example-project.
• Anda memindahkan example-project dari example.com ke cymbalgroup.com.

Dalam situasi ini, memindahkan project akan membuat pengikatan kebijakan lintas organisasi. Hal ini karena kebijakan Principal Access Boundary di example.com terikat ke set akun utama di cymbalgroup.com. Jika Anda tidak menghapus binding secara manual, IAM pada akhirnya akan menghapusnya secara otomatis. Menghapus pengikatan ini membantu memastikan bahwa administrator cymbalgroup.com memiliki akses ke semua kebijakan Batas Akses Utama yang terikat ke akun utama mereka.

Struktur kebijakan Principal Access Boundary

Kebijakan Batas Akses Utama adalah kumpulan metadata dan detail kebijakan Batas Akses Utama. Metadata memberikan informasi seperti nama kebijakan dan waktu pembuatan kebijakan. Detail kebijakan menentukan apa yang dilakukan kebijakan—misalnya, resource yang dapat 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 dalam 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": "4"
  }
}

Bagian berikut menjelaskan kolom dalam metadata dan detail kebijakan Batas Akses Principal.

Metadata

Kebijakan Batas Akses Utama berisi metadata berikut:

• name: Nama kebijakan Principal Access Boundary. 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 Principal Access Boundary.
• 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 mudah dibaca manusia untuk kebijakan Batas Akses Principal.
• 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 Principal Access Boundary dibuat.
• updateTime: Waktu saat kebijakan Principal Access Boundary terakhir kali diperbarui.

Detail

Setiap kebijakan Principal Access Boundary berisi kolom details. Kolom ini berisi aturan Principal Access Boundary dan versi penegakannya:

• rules: Daftar aturan principal access boundary, yang menentukan resource yang dapat 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 pokok dapat mengaksesnya. Setiap pengguna yang tunduk pada kebijakan ini berhak mengakses resource ini.

    Setiap kebijakan Batas Akses Akun Utama dapat mereferensikan maksimum 500 resource di semua aturan dalam kebijakan.

  • effect: Hubungan yang dimiliki principal dengan resource yang tercantum di kolom resources. Satu-satunya efek yang dapat Anda tentukan dalam aturan principal access boundary adalah "ALLOW". Hubungan ini membuat akun utama memenuhi syarat untuk mengakses resource yang tercantum dalam aturan.

• enforcementVersion: Versi penerapan yang digunakan IAM saat menerapkan kebijakan. Versi kebijakan Principal Access Boundary menentukan izin yang dapat diblokir oleh kebijakan Principal Access Boundary.

  Untuk mengetahui informasi selengkapnya tentang cara menyetel dan mengelola versi penerapan, lihat Mengelola versi penerapan di halaman ini.

Struktur binding kebijakan

Binding kebijakan untuk kebijakan Principal Access Boundary berisi nama kebijakan, nama set akun utama yang akan mengikat kebijakan, dan metadata yang menjelaskan binding kebijakan. Kebijakan ini juga dapat berisi kondisi yang mengubah prinsipal persisnya yang menjadi cakupan 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: Entity utama yang ditetapkan untuk mengikat kebijakan. Nilai memiliki format {"principalSet": PRINCIPAL_SET}, dengan PRINCIPAL_SET adalah ID set 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 pengikatan kebijakan untuk kebijakan Batas Akses Utama, nilai ini selalu PRINCIPAL_ACCESS_BOUNDARY.

• policy: Kebijakan Principal Access Boundary yang akan diikat ke set 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 kebijakan IAM-nya diterapkan. 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 mengetahui informasi selengkapnya, lihat Kondisi dan Batas Akses Utama di halaman ini.

• createTime: Waktu saat pengikatan kebijakan dibuat.

• updateTime: Waktu saat binding kebijakan terakhir diperbarui.

Langkah berikutnya

• Pelajari lebih lanjut kasus penggunaan untuk kebijakan Batas Akses Principal.
• Pelajari cara membuat dan menerapkan kebijakan Batas Akses Principal.
• Tinjau izin yang diblokir oleh setiap versi penerapan kebijakan Principal Access Boundary.