Panduan ini menjelaskan cara memperluas kebijakan akses Identity-Aware Proxy (IAP) menggunakan tingkat akses dan Framework Kondisi Identity and Access Management (IAM). Tingkat akses memungkinkan pembatasan akses ke resource berdasarkan alamat IP dan atribut perangkat pengguna akhir. Kondisi IAM memungkinkan pembatasan akses berdasarkan host, jalur, tanggal, dan waktu URL.
Misalnya, bergantung pada konfigurasi kebijakan, aplikasi sensitif Anda dapat:
- Berikan akses ke semua karyawan jika mereka menggunakan perangkat perusahaan tepercaya dari jaringan perusahaan Anda.
- Berikan akses kepada karyawan dalam grup Akses Jarak Jauh jika mereka menggunakan perangkat perusahaan tepercaya dengan sandi yang aman dan tingkat patch terbaru, dari jaringan mana pun.
- Hanya berikan akses kepada karyawan dalam grup Akses Berhak Istimewa jika jalur URL dimulai dengan
/admin
.
Sebelum memulai
Sebelum memulai, Anda memerlukan hal-hal berikut:
- Aplikasi yang diamankan IAP yang ingin Anda tambahkan akses individu atau grup.
- Nama pengguna atau grup yang ingin Anda beri akses.
Menyiapkan tingkat akses
Untuk membatasi akses berdasarkan alamat IP atau atribut perangkat pengguna akhir, Anda perlu membuat tingkat akses. Untuk mempelajari cara membuat tingkat akses, lihat panduan Access Context Manager. IAP menggunakan nama tingkat akses untuk mengaitkannya dengan aplikasi yang diamankan IAP.
Penggunaan kebijakan cakupan tidak didukung oleh IAP. Tingkat akses harus ditetapkan dalam kebijakan akses organisasi. Untuk mengetahui informasi selengkapnya, lihat Membuat kebijakan akses.
Mengedit kebijakan IAM
Aplikasi yang diamankan IAP memiliki kebijakan IAM yang mengikat peran IAP ke aplikasi.
Dengan menambahkan binding bersyarat IAM ke kebijakan IAM, akses ke resource Anda akan lebih dibatasi berdasarkan atribut permintaan. Atribut permintaan ini mencakup:
- Tingkat akses
- Host/Jalur URL
- Tanggal/Waktu
Perhatikan bahwa nilai permintaan yang dibandingkan dengan request.host
dan request.path
yang ditentukan dalam binding bersyarat IAM harus sama persis. Misalnya,
jika Anda membatasi akses ke jalur yang dimulai dengan /internal admin
,
seseorang dapat mengabaikan pembatasan dengan membuka /internal%20admin
. Untuk mengetahui informasi selengkapnya
tentang kondisi nama host dan jalur, lihat Menggunakan kondisi nama host dan jalur.
Tambahkan dan edit binding kondisional pada kebijakan IAM Anda dengan mengikuti proses di bawah.
Konsol
Untuk menambahkan binding kondisional menggunakan konsol Google Cloud:
Buka halaman admin IAP.
Pilih kotak centang di samping resource yang izin IAM-nya ingin Anda perbarui.
Di sisi kanan Panel info, klik Tambahkan akun utama.
Di kotak New principal, masukkan akun utama yang ingin Anda tetapkan peran.
Di menu drop-down Select a role, pilih peran IAP-secured Web App User dan tentukan kondisi tingkat akses yang harus dipenuhi akun utama untuk mengakses resource.
- Untuk menentukan tingkat akses yang ada, pilih tingkat akses dari menu drop-down Tingkat akses. Anda harus memilih peran Pengguna Aplikasi Web yang Dilindungi IAP dan memiliki izin tingkat organisasi untuk melihat tingkat akses yang ada. Anda harus diberi salah satu peran berikut:
- Access Context Manager Admin
- Access Context Manager Editor
- Access Context Manager Reader
- Untuk membuat dan mengelola tingkat akses, gunakan Access Context Manager.
- Untuk menentukan tingkat akses yang ada, pilih tingkat akses dari menu drop-down Tingkat akses. Anda harus memilih peran Pengguna Aplikasi Web yang Dilindungi IAP dan memiliki izin tingkat organisasi untuk melihat tingkat akses yang ada. Anda harus diberi salah satu peran berikut:
Jika Anda ingin menambahkan lebih banyak peran ke akun utama, klik Tambahkan peran lain.
Setelah selesai menambahkan peran, klik Simpan.
Sekarang Anda telah menambahkan binding kondisional ke resource.
Untuk menghapus binding bersyarat:
Buka halaman admin IAP.
Pilih kotak centang di samping resource yang ingin Anda hapus peran IAM akun utamanya.
Di Panel info sebelah kanan, klik peran yang ingin Anda hapus dari akun utama di bagian Peran / Akun utama.
Klik Hapus di samping akun utama.
Pada dialog Hapus peran dari akun utama yang muncul, klik Hapus. Untuk menghapus semua peran non-diwarisi dari akun utama di resource yang dipilih, centang kotak sebelum mengklik Hapus.
gcloud
Saat ini, Anda hanya dapat menggunakan alat gcloud untuk menetapkan binding bersyarat tingkat project.
Untuk menetapkan binding bersyarat, edit file policy.yaml
project Anda dengan mengikuti proses di bawah ini:
Buka kebijakan IAM untuk aplikasi menggunakan perintah gcloud berikut:
gcloud iap web get-iam-policy --project=PROJECT_ID > policy.yaml
Edit file
policy.yaml
untuk menentukan hal berikut:- Pengguna dan grup yang ingin Anda terapkan kondisi IAM.
- Peran
iap.httpsResourceAccessor
untuk memberi mereka akses ke resource. Kondisi IAM.
Cuplikan berikut menunjukkan kondisi IAM dengan hanya satu atribut yang ditentukan. Kondisi ini memberikan akses kepada pengguna dan grup jika persyaratan tingkat akses ACCESS_LEVEL_NAME terpenuhi dan jalur URL resource dimulai dengan
/
.
bindings: ... - members: - group:EXAMPLE_GROUP@GOOGLE.COM - user:EXAMPLE_USER@GOOGLE.COM role: roles/iap.httpsResourceAccessor condition: expression: "accessPolicies/ORGANIZATION_NUMBER/accessLevels/ACCESS_LEVEL_NAME" in request.auth.access_levels && request.path.startsWith("/") title: CONDITION_TITLE ...
Ikat kebijakan ke aplikasi menggunakan perintah
set-iam-policy
.gcloud iap web set-iam-policy --project=PROJECT_ID policy.yaml
Kebijakan IAM Anda kini menyertakan binding bersyarat.
API
Untuk mengedit file policy.json
aplikasi, ikuti proses di bawah untuk jenis aplikasi Anda.
Lihat Mengelola akses ke resource yang diamankan IAP
untuk mengetahui informasi selengkapnya tentang penggunaan IAM API untuk mengelola kebijakan akses.
Sebelum melakukan langkah-langkah API khusus aplikasi di bawah, ekspor variabel berikut:
export PROJECT_NUM=PROJECT_NUMBER export IAP_BASE_URL=https://iap.googleapis.com/v1/projects/${PROJECT_NUM}/iap_web # Replace POLICY_FILE.JSON with the name of JSON file to use for setIamPolicy export JSON_NEW_POLICY=POLICY_FILE.JSON
App Engine
Ekspor variabel App Engine berikut:
# The APP_ID is usually the project ID export GAE_APP_ID=APP_ID export GAE_BASE_URL=${IAP_BASE_URL}/appengine-${GAE_APP_ID}
Dapatkan kebijakan IAM untuk aplikasi App Engine menggunakan metode
getIamPolicy
. Bit data kosong di bagian akhir mengubah permintaancurl
menjadi POST, bukan GET.curl -i -H "Authentication: Bearer $(gcloud auth print-access-token)" \ ${GAE_BASE_URL}/:getIamPolicy -d ''
Tambahkan binding bersyarat IAM Anda ke file JSON kebijakan IAM. Berikut adalah contoh file
policy.json
yang diedit yang mengikat peraniap.httpsResourceAccessor
ke dua pengguna, yang memberi mereka akses ke resource yang diamankan IAP. Kondisi IAM telah ditambahkan untuk memberinya akses ke resource hanya jika persyaratan tingkat akses ACCESS_LEVEL_NAME terpenuhi dan jalur URL resource dimulai dengan/
. Hanya boleh ada satu kondisi per binding.
Contoh file policy.json{ "policy": { "bindings": [ { "role": "roles/iap.httpsResourceAccessor", "members": [ "group:EXAMPLE_GROUP@GOOGLE.COM", "user:EXAMPLE_USER@GOOGLE.COM" ], "condition": { "expression": ""accessPolicies/ORGANIZATION_NUMBER/accessLevels/ACCESS_LEVEL_NAME" in request.auth.access_levels && request.path.startsWith("/")", "title": "CONDITION_NAME" } } ] } }
Tetapkan file
policy.json
baru menggunakan metodesetIamPolicy
.curl -i -H "Authentication: Bearer $(gcloud auth print-access-token)" \ ${GAE_BASE_URL}:setIamPolicy -d @${JSON_NEW_POLICY}
Layanan dan versi App Engine
Anda juga dapat memperbarui kebijakan IAM layanan App Engine, semua versi, atau versi layanan tertentu. Untuk melakukannya untuk versi layanan tertentu:
- Ekspor variabel tambahan berikut.
export GAE_SERVICE=SERVICE_NAME export GAE_VERSION=VERSION_NAME
- Perbarui variabel GAE_BASE_URL yang diekspor.
export GAE_BASE_URL=${IAP_BASE_URL}/appengine-${GAE_APP_ID}/services/${GAE_SERVICE}/versions/${GAE_VERSION}
- Dapatkan dan tetapkan kebijakan IAM untuk versi menggunakan perintah
getIamPolicy
dansetIamPolicy
yang ditampilkan di atas.
GKE dan Compute Engine
Ekspor project ID layanan backend Anda.
export BACKEND_SERVICE_NAME=BACKEND_SERVICE_NAME
Dapatkan kebijakan IAM untuk aplikasi Compute Engine menggunakan metode
getIamPolicy
. Bit data kosong di bagian akhir mengubah permintaancurl
menjadi POST, bukan GET.curl -i -H "Authentication: Bearer $(gcloud auth print-access-token)" \ ${IAP_BASE_URL}/compute/services/${BACKEND_SERVICE_NAME}:getIamPolicy \ -d ''
Tambahkan binding bersyarat IAM Anda ke file JSON kebijakan IAM. Berikut adalah contoh file
policy.json
yang diedit yang mengikat peraniap.httpsResourceAccessor
ke dua pengguna, yang memberi mereka akses ke resource yang diamankan IAP. Kondisi IAM telah ditambahkan untuk memberinya akses ke resource hanya jika persyaratan tingkat akses ACCESS_LEVEL_NAME terpenuhi dan jalur URL resource dimulai dengan/
. Hanya boleh ada satu kondisi per binding.
Contoh file policy.json{ "policy": { "bindings": [ { "role": "roles/iap.httpsResourceAccessor", "members": [ "group":EXAMPLE_GROUP@GOOGLE.COM, "user:EXAMPLE_USER@GOOGLE.COM" ], "condition": { "expression": ""accessPolicies/ORGANIZATION_NUMBER/accessLevels/ACCESS_LEVEL_NAME" in request.auth.access_levels && request.path.startsWith("/")", "title": "CONDITION_NAME" } } ] } }
Tetapkan file
policy.json
baru menggunakan metodesetIamPolicy
.curl -i -H "Content-Type:application/json" \ -H "Authentication: Bearer $(gcloud auth print-access-token)" \ ${IAP_BASE_URL}/compute/services/${BACKEND_SERVICE_NAME}:setIamPolicy \ -d @${JSON_NEW_POLICY}
Menggunakan kondisi nama host dan jalur
Akses ke aplikasi Anda dapat diamankan menggunakan nama host dan jalur URL permintaan.
Misalnya, kondisi IAM request.path.startsWith
dapat
digunakan untuk hanya memberikan akses kepada karyawan dalam grup Privileged Access jika
jalur URL diawali dengan /admin
.
Untuk mengetahui informasi selengkapnya tentang penggunaan nama host dan kondisi jalur, lihat atribut permintaan.
Normalisasi string
URL memiliki nama host dan jalur. Misalnya, URL https://sheets.google.com/create?query=param
memiliki nama host sheets.google.com
dan jalur /create
.
Backend dapat menafsirkan nama host dan jalur dengan cara yang berbeda. Untuk menghilangkan ambiguitas, IAP akan menormalisasi string nama host dan jalur saat memeriksa kebijakan.
IAP melakukan dua pemeriksaan kebijakan saat permintaan memiliki jalur yang tidak dinormalisasi. Jika jalur yang tidak dinormalisasi lulus pemeriksaan kebijakan, IAP akan melakukan normalisasi jalur dan pemeriksaan kebijakan kedua akan dilakukan. Akses diberikan jika jalur yang tidak dinormalisasi dan dinormalisasi lulus pemeriksaan kebijakan.
Misalnya, jika permintaan memiliki jalur /internal;some_param/admin
,
IAP terlebih dahulu melakukan pemeriksaan
kebijakan pada jalur yang tidak dinormalisasi (/internal
). Jika lulus,
IAP akan melakukan pemeriksaan kebijakan kedua pada jalur yang dinormalisasi
(/internal/admin
).
Nama host
Nama host dinormalisasi oleh:
- Menghapus titik di akhir
- Mengubah karakter menjadi huruf kecil
- Mengonversi ke ASCII
Nama host yang menyertakan karakter non-ASCII akan dinormalisasi lebih lanjut dengan punycoding. Anda harus melakukan punycode pada string nama host agar kecocokan dapat dibuat.
Untuk membuat string nama host Anda menjadi punycode, gunakan pengonversi seperti Punycoder.
Berikut adalah contoh nama host yang dinormalisasi:
FOO.com
dinormalisasi menjadifoo.com
café.fr
dinormalisasi menjadixn--caf-dma.fr
Jalur
Jalur dinormalisasi oleh:
- Menghapus parameter jalur
- Me-resolve jalur relatif ke jalur absolut yang setara
Parameter jalur mencakup semua
karakter dari ;
ke /
berikutnya atau akhir jalur.
Permintaan yang berisi ..;
di awal bagian jalur dianggap tidak valid.
Misalnya, /..;bar/
dan /bar/..;/
menampilkan error
HTTP 400: Bad Request
.
Berikut adalah contoh jalur yang dinormalisasi:
/internal;some_param/admin
dinormalisasi menjadi/internal/admin
/a/../b
dinormalisasi menjadi/b
/bar;param1/baz;baz;param2
dinormalisasi menjadi/bar/baz
Akhiran subdomain
Kebijakan yang ditetapkan dengan request.host.endsWith("google.com")
akan cocok dengan
sub_domain.google.com
dan testgoogle.com
. Jika sasaran Anda adalah membatasi
kebijakan ke semua subdomain yang diakhiri dengan google.com
, tetapkan kebijakan Anda ke
request.host.endsWith(".google.com")
.
Perhatikan bahwa menetapkan kebijakan ke request.host.endsWith(".google.com")
akan cocok dengan sub_domain.google.com
, tetapi tidak akan cocok dengan google.com
karena .
tambahan.
Cloud Audit Logs dan tingkat akses
Mengaktifkan Cloud Audit Logs untuk project yang diamankan IAP memungkinkan Anda melihat permintaan akses yang diotorisasi dan tidak diotorisasi. Lihat permintaan dan semua tingkat akses yang telah dipenuhi pemohon dengan mengikuti proses di bawah ini:
-
Buka
Logs Explorer konsol Google Cloud untuk project Anda.
Buka halaman log - Pada menu drop-down pemilih resource, pilih resource. Resource HTTPS yang diamankan IAP berada di bagian Aplikasi GAE dan Layanan Backend GCE. Resource SSH dan TCP yang diamankan IAP berada di instance VM GCE.
-
Pada menu drop-down jenis log, pilih data_access.
- Jenis log data_access hanya muncul jika ada traffic ke resource Anda setelah Anda mengaktifkan Log Audit Cloud untuk IAP.
-
Klik untuk meluaskan tanggal dan waktu akses yang ingin Anda tinjau.
- Akses yang diotorisasi memiliki ikon
i
biru. - Akses tidak sah memiliki ikon
!!
oranye.
- Akses yang diotorisasi memiliki ikon
-
Lihat tingkat akses yang telah dipenuhi pemohon dengan mengklik untuk meluaskan bagian
hingga Anda mencapai
protoPayload
>requestMetadata
>requestAttributes
>auth
>accessLevels
.
Perhatikan bahwa semua tingkat akses yang telah dipenuhi pengguna akan terlihat saat melihat permintaan, termasuk tingkat akses yang tidak diperlukan untuk mengaksesnya. Melihat permintaan yang tidak sah tidak menunjukkan tingkat akses yang tidak terpenuhi. Hal ini ditentukan dengan membandingkan kondisi pada resource dengan tingkat akses yang terlihat pada permintaan.
Lihat panduan Cloud Audit Logs untuk mengetahui informasi selengkapnya tentang log.