Kebijakan batas akses akun utama

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

Misalnya, Anda dapat menggunakan kebijakan batas akses utama untuk mencegah akun utama Anda 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 Identity and Access Management (IAM), lihat Jenis kebijakan.

Cara kerja kebijakan batas akses 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, maka akun utama dapat menggunakan izin tersebut untuk mengakses resource.

Dengan kebijakan batas akses utama, Anda dapat menentukan resource yang dapat diakses oleh akun utama. Jika kebijakan batas akses akun utama membuat akun utama tidak memenuhi syarat untuk mengakses resource, maka aksesnya ke resource tersebut akan dibatasi, terlepas dari peran yang telah 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 serangkaian resource yang dapat diakses oleh akun utama yang terpengaruh. Anda dapat membuat hingga 1.000 kebijakan batas akses utama di organisasi Anda.

Setelah membuat kebijakan batas akses utama, Anda membuat pengikatan kebijakan untuk menerapkan kebijakan ke sekumpulan akun utama.

Akun utama dapat tunduk pada satu atau beberapa kebijakan batas akses akun utama. Setiap prinsipal 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 kepada akun utama pada 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 bukan milik Anda. Misalnya, perhatikan skenario berikut:

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

Dengan kebijakan hanya izinkan dan tolak, example.com tidak dapat mencegah Tal melihat objek di bucket eksternal ini. Tidak ada prinsipal example.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 apa pun di cymbalgroup.com, sehingga mereka tidak dapat menggunakan kebijakan penolakan untuk mencegah Tal mengakses bucket.

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

Evaluasi fail-closed

Kebijakan batas akses utama gagal ditutup. Artinya, jika IAM tidak dapat mengevaluasi kebijakan batas akses akun utama saat mengevaluasi akses akun utama, IAM akan mencegah akun utama mengakses resource.

Alasan paling umum IAM tidak dapat mengevaluasi kebijakan batas akses utama adalah karena detail utama masih disebarkan 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.

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 mencegahnya menggunakan beberapa, tetapi tidak semua, izin Identity and Access Management (IAM) untuk mengakses resource.

Jika kebijakan batas akses akun utama memblokir izin, maka IAM menerapkan kebijakan batas akses akun utama untuk izin tersebut. Dengan kata lain, kebijakan ini mencegah akun utama yang tidak memenuhi syarat untuk mengakses resource 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, anggap akun utama, Lee (lee@example.com), diberi peran Dataflow Developer (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 membuatnya tidak memenuhi syarat untuk mengakses resource di luar example.com. Namun, jika kebijakan batas akses utama tidak memblokir izin dataflow.jobs.snapshot, maka 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 penerapan batas akses akun utama.

Versi penerapan batas akses akun utama

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

Secara berkala, IAM menambahkan versi penerapan 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 utama untuk menggunakan versi baru. Jika ingin versi penerapan 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.

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

Mengikat kebijakan batas akses utama ke set utama

Untuk mengikat 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. 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 set akun utama. Setiap set akun utama dapat memiliki hingga 10 kebijakan batas akses akun utama yang terikat dengannya.

Anda hanya dapat membuat binding untuk kebijakan batas akses akun utama yang ada. Mencoba membuat binding untuk kebijakan batas akses akun 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 utama, lihat Membuat dan menerapkan kebijakan batas akses utama.

Kumpulan prinsipal yang didukung

Tabel berikut mencantumkan jenis set prinsipal yang dapat Anda ikat dengan kebijakan batas akses prinsipal. 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 mengatur binding kebijakan induk untuk jenis pokok tersebut

Binding 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 dalam kondisi untuk binding kebijakan.

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

  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 menunjukkan identitas akun utama dalam permintaan—misalnya, cruz@example.com. Anda dapat menggunakan kondisi dengan atribut ini untuk mengontrol secara tepat 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, maka 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 untuk 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 set 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 set akun utama example.com.

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

1. Anda mengonfirmasi bahwa satu-satunya kebijakan batas akses akun utama yang dev-project-service-account tunduk padanya adalah kebijakan yang membuat akun utama memenuhi syarat untuk mengakses semua resource di example.com.

2. Anda membuat kebijakan batas akses akun utama baru yang membuat akun utama memenuhi syarat untuk mengakses resource di dev-project dan melampirkannya ke kumpulan akun utama 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'"
   }
   

3. 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, Anda menambahkan kondisi berikut ke binding kebijakan yang melampirkan kebijakan batas akses akun utama tersebut ke set 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. Sebagai gantinya, dev-project-service-account hanya memenuhi syarat untuk mengakses resource di dev-project.

Pengikatan kebijakan lintas organisasi

Anda tidak dapat membuat binding kebijakan lintas organisasi untuk kebijakan batas akses utama. Pengikatan kebijakan lintas organisasi adalah pengikatan kebijakan yang mengikat kebijakan di satu organisasi ke akun utama yang ditetapkan di organisasi lain.

IAM secara berkala menghapus binding kebijakan lintas organisasi yang ada. Pengikatan 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 akun utama di example.com yang membuat akun utama memenuhi syarat untuk mengakses resource di example.com dan mengikat kebijakan tersebut ke set akun utama untuk example-project.
• Anda memindahkan example-project dari example.com ke cymbalgroup.com.

Dalam situasi ini, memindahkan project akan membuat binding kebijakan lintas organisasi. Hal ini karena kebijakan batas akses akun utama di example.com akan 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 akun utama yang terikat ke akun utama mereka.

Interaksi kebijakan

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

Interaksi dengan jenis kebijakan lainnya

Saat akun utama mencoba mengakses resource, IAM mengevaluasi semua kebijakan izin, penolakan, dan batas akses akun utama yang relevan untuk melihat apakah akun utama diizinkan 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 izinkan dan tolak yang dilampirkan ke resource.

Selain itu, kebijakan batas akses akun utama saja tidak memberikan akses akun utama 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 akun utama ke resource.

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

Interaksi antara kebijakan batas akses utama

Jika ada kebijakan batas akses akun utama yang membuat akun utama memenuhi syarat untuk mengakses resource, maka akun utama tersebut memenuhi syarat untuk mengakses resource tersebut, terlepas dari kebijakan batas akses akun utama lainnya yang tunduk pada 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 pada set utama organisasi mereka.

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

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

Jika Anda ingin mengurangi resource yang dapat 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 memenuhi syarat untuk mengakses resource di staging-project dan prod-project.

Atau, Anda dapat menghapus prod-projects-policy dengan menghapus binding kebijakan yang mengikatnya ke set akun utama organisasi. Kemudian, Dana hanya berhak mengakses resource di dev-project dan staging-project.

Namun, perubahan ini tidak hanya memengaruhi Dana, tetapi 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 prinsipal, 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 Resource Manager—yaitu, folder dan organisasi—selalu menyertakan semua akun utama dalam set akun utama turunannya. Jadi, misalnya, jika akun utama disertakan dalam kumpulan akun utama project, akun utama tersebut juga disertakan dalam kumpulan akun utama folder atau organisasi induk.

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

• Organisasi, example.com
• Project, project-1, yang merupakan turunan 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 keamanan berikut terpengaruh oleh kebijakan batas akses pokok keamanan 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, serta akan terpengaruh oleh kebijakan batas akses akun utama yang terikat ke salah satu set akun utama tersebut.

• Akun layanan 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.

Kebijakan batas akses utama dan resource yang di-cache

Layanan Google Cloud tertentu menyimpan cache resource yang terlihat secara publik. Misalnya, Cloud Storage meng-cache objek yang dapat dibaca secara publik.

Apakah 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, 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 memodifikasi atau menghapus resource yang terlihat secara publik.

Struktur kebijakan batas akses utama

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

Misalnya, kebijakan batas akses 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": "1"
  }
}

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

Metadata

Kebijakan batas akses utama berisi metadata berikut:

• name: Nama kebijakan batas akses 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 utama dibuat dan PAB_POLICY_ID adalah ID alfanumerik kebijakan batas akses utama.
• uid: ID unik yang ditetapkan untuk kebijakan batas akses 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 mudah dibaca manusia untuk kebijakan batas akses 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 utama dibuat.
• updateTime: Waktu saat kebijakan batas akses utama terakhir diperbarui.

Detail

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

• rules: Daftar aturan batas akses utama, 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 principal 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 principal dengan resource yang tercantum di kolom resources. Satu-satunya efek yang dapat Anda tentukan dalam aturan batas akses prinsipal 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 batas akses akun utama menentukan izin mana yang dapat diblokir oleh kebijakan batas akses akun utama.

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

Struktur binding kebijakan

Binding kebijakan untuk kebijakan batas akses akun utama 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 padanya.

• policyKind: Jenis kebijakan yang dirujuk oleh binding kebijakan. Untuk binding kebijakan untuk kebijakan batas akses utama, nilai ini selalu PRINCIPAL_ACCESS_BOUNDARY.

• policy: Kebijakan batas akses utama yang akan diikat ke set 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.

Kasus penggunaan

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

Membuat principal memenuhi syarat untuk mengakses resource di organisasi Anda

Anda dapat menggunakan kebijakan batas akses utama untuk membuat akun utama di organisasi Anda memenuhi syarat untuk mengakses resource dalam organisasi Anda. Jika ini adalah satu-satunya kebijakan batas akses akun utama yang tunduk pada akun utama di organisasi Anda, maka kebijakan batas akses akun utama juga akan membuat akun utama di organisasi Anda tidak memenuhi syarat untuk mengakses resource di luar organisasi Anda.

Misalnya, bayangkan Anda ingin membuat semua akun utama di organisasi example.com memenuhi syarat untuk mengakses resource dalam example.com dan tidak memenuhi syarat untuk mengakses resource di organisasi lain. Principal yang ada di example.com mencakup semua identitas di domain example.com, semua workforce identity pool di example.com, dan semua akun layanan dan workload identity pool di project mana pun di example.com.

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

Agar akun utama memenuhi syarat untuk mengakses resource di example.com dan tidak memenuhi syarat untuk mengakses resource di luar example.com, Anda 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 set utama organisasi:

{
  "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"
}

Jika terikat ke set akun utama organisasi, kebijakan ini membuat semua akun utama di example.com memenuhi syarat untuk mengakses resource di example.com. Karena ini adalah satu-satunya kebijakan batas akses akun utama yang tunduk pada akun utama ini, kebijakan ini juga membuat akun utama di example.com tidak memenuhi syarat untuk mengakses resource di luar organisasi Anda. Artinya, mereka tidak dapat menggunakan izin yang diblokir oleh kebijakan batas akses akun utama untuk mengakses resource di luar example.com, meskipun mereka memiliki izin tersebut di resource tersebut.

Membuat akun layanan memenuhi syarat untuk mengakses resource dalam satu project

Anda dapat membuat kebijakan batas akses utama untuk membuat akun layanan di project tertentu memenuhi syarat untuk mengakses resource dalam project tersebut.

Jika ini adalah satu-satunya kebijakan batas akses akun utama yang tunduk pada akun layanan, maka akun layanan tersebut hanya memenuhi syarat untuk mengakses resource dalam project tersebut.

Misalnya, bayangkan Anda memiliki project, example-dev, dengan nomor project 901234567890. 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 Anda, termasuk akun layanan di example-dev, memenuhi syarat untuk mengakses resource di example.com. Untuk melihat tampilan jenis kebijakan ini, lihat Membuat akun utama memenuhi syarat untuk mengakses 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 utama 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 sehingga 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 mengubah resource yang memenuhi syarat untuk diakses oleh akun layanan. Hal ini karena ada kebijakan batas akses akun utama yang sudah ada 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 tetap 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 harus menambahkan kondisi ke binding kebijakan untuk kebijakan batas akses utama yang ada yang mencegahnya diterapkan untuk akun layanan, termasuk akun layanan default, 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') || !principal.subject == 'example-dev@appspot.gserviceaccount.com || !principal.subject == '901234567890-compute@developer.gserviceaccount.com'"
  }
}

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

Nanti, jika Anda ingin menambah resource yang memenuhi syarat untuk diakses oleh akun layanan ini, Anda dapat menambahkan resource lain ke kebijakan example-dev-only atau membuat kebijakan batas akses utama tambahan dan mengikatnya ke akun layanan.

Langkah berikutnya

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