Menyiapkan akses kontekstual dengan Identity-Aware Proxy

Panduan ini menjelaskan cara memperluas kebijakan akses Identity-Aware Proxy (IAP) menggunakan tingkat akses dan Framework Kondisi Identity and Access Management (IAM). Tingkat akses mengizinkan pembatasan akses ke resource berdasarkan alamat IP dan atribut perangkat pengguna akhir. Kondisi IAM memungkinkan pembatasan akses berdasarkan host URL, jalur, tanggal, dan waktu.

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 di grup Akses Jarak Jauh jika mereka menggunakan perangkat perusahaan tepercaya dengan sandi yang aman dan level patch terbaru, dari jaringan apa pun.
Hanya berikan akses kepada karyawan di grup Akses Hak Istimewa jika jalur URL dimulai dengan /admin.

Sebelum memulai

Sebelum memulai, Anda akan memerlukan hal berikut:

Aplikasi yang diamankan oleh IAP yang ingin Anda tambahkan akses individual 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 Pengelola Akses Konteks. IAP menggunakan nama tingkat akses untuk mengaitkannya dengan aplikasi yang diamankan oleh 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 oleh IAP memiliki kebijakan IAM yang mengikat peran IAP ke aplikasi.

Dengan menambahkan binding kondisional IAM ke kebijakan IAM, akses ke resource Anda akan lebih dibatasi berdasarkan atribut permintaan. Atribut permintaan ini mencakup:

Tingkat akses
Host/Jalur URL
Date/Time

Perhatikan bahwa nilai permintaan yang dibandingkan dengan request.host dan request.path yang ditentukan dalam binding kondisional IAM harus sama persis. Misalnya, jika Anda membatasi akses ke jalur yang dimulai dengan /internal admin, seseorang dapat mengabaikan pembatasan ini dengan membuka /internal%20admin. Untuk mengetahui informasi selengkapnya tentang kondisi nama host dan jalur, lihat Menggunakan nama host dan kondisi jalur.

Tambahkan dan edit binding kondisional pada kebijakan IAM Anda dengan mengikuti proses di bawah ini.

Konsol

Untuk menambahkan binding kondisional menggunakan konsol Google Cloud:

Buka halaman admin IAP.
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 perannya.
Di menu drop-down Pilih peran, pilih peran IAP-secured Web App User, lalu tentukan kondisi tingkat akses yang harus dipenuhi akun utama agar dapat mengakses resource.
- Untuk menentukan tingkat akses yang ada, pilih tingkat akses dari menu drop-down Tingkat akses. Anda harus memilih peran IAP-secured Web App User 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 Pengelola Akses Konteks.
Jika Anda ingin menambahkan peran lainnya ke akun utama, klik Tambahkan peran lain.
Setelah selesai menambahkan peran, klik Simpan.

Sekarang Anda telah menambahkan binding kondisional ke resource Anda.

Untuk menghapus binding kondisional:

Buka halaman admin IAP.
Buka halaman admin IAP
Centang kotak di samping resource yang peran IAM akun utamanya ingin Anda hapus.
Di sisi kanan Panel info, di bagian Peran / Kepala, klik peran yang ingin dihapus dari akun utama.
Klik Hapus di samping akun utama.
Pada dialog Remove role from principal yang muncul, klik Remove. Untuk menghapus semua peran yang tidak 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 kondisional level project.

Untuk menetapkan binding kondisional, 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_ID > policy.yaml
```
Edit file policy.yaml untuk menentukan hal berikut:
- Pengguna dan grup yang ingin Anda terapkan kondisi IAM.
- Peran iap.httpsResourceAccessor untuk memberinya 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 kondisional.

API

Untuk mengedit file policy.json aplikasi Anda, ikuti proses di bawah untuk jenis aplikasi Anda. Lihat Mengelola akses ke resource yang diamankan oleh IAP untuk mengetahui informasi selengkapnya tentang penggunaan IAM API untuk mengelola kebijakan akses.

Sebelum melakukan langkah-langkah API khusus aplikasi di bawah ini, 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 akhir mengubah permintaan curl menjadi POST, bukan GET.
```
curl -i -H "Authentication: Bearer $(gcloud auth print-access-token)" \
${GAE_BASE_URL}/:getIamPolicy -d ''
```
Tambahkan binding kondisional IAM Anda ke file JSON kebijakan IAM. Berikut adalah contoh file policy.json yang telah diedit yang mengikat peran iap.httpsResourceAccessor ke dua pengguna, sehingga memberi mereka akses ke resource yang diamankan oleh IAP. Kondisi IAM telah ditambahkan untuk memberi mereka 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 metode setIamPolicy.

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 pada 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 dan setIamPolicy yang ditunjukkan 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 akhir mengubah permintaan curl 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 kondisional IAM Anda ke file JSON kebijakan IAM. Berikut adalah contoh file policy.json yang telah diedit yang mengikat peran iap.httpsResourceAccessor ke dua pengguna, sehingga memberi mereka akses ke resource yang diamankan oleh IAP. Kondisi IAM telah ditambahkan untuk memberi mereka 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 metode setIamPolicy.

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 nama host dan kondisi 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 di grup Akses Hak Istimewa jika jalur URL dimulai dengan /admin.

Untuk mengetahui informasi selengkapnya tentang penggunaan kondisi nama host dan 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 menormalkan nama host dan string jalur saat memeriksa kebijakan.

IAP melakukan dua pemeriksaan kebijakan jika permintaan memiliki jalur yang tidak dinormalisasi. Jika jalur yang tidak dinormalisasi lulus pemeriksaan kebijakan, IAP akan menormalisasi jalur tersebut dan pemeriksaan kebijakan kedua akan dilakukan. Akses diberikan jika jalur yang tidak dinormalisasi dan yang dinormalisasi lulus pemeriksaan kebijakan.

Misalnya, jika permintaan memiliki jalur /internal;some_param/admin, IAP akan melakukan pemeriksaan kebijakan pada jalur yang tidak dinormalisasi (/internal) terlebih dahulu. Jika permintaan tersebut lulus, IAP akan melakukan pemeriksaan kebijakan kedua pada jalur yang dinormalisasi (/internal/admin).

Nama host

Nama host dinormalkan berdasarkan:

Menghapus titik akhir
Karakter huruf kecil
Mengonversi ke ASCII

Nama host yang menyertakan karakter non-ASCII lebih lanjut dinormalisasi dengan punycoding. Anda harus melakukan punycode pada string nama host agar pencocokan dapat dilakukan.

Untuk melakukan punycode untuk string nama host Anda, gunakan pengonversi seperti Punycoder.

Berikut adalah contoh nama host yang dinormalkan:

FOO.com dinormalkan menjadi foo.com
café.fr dinormalkan menjadi xn--caf-dma.fr

Jalur

Jalur dinormalkan berdasarkan:

Menghapus parameter jalur
Menyelesaikan jalur relatif ke padanan absolutnya

Parameter jalur mencakup semua karakter dari ; ke / berikutnya atau akhir jalur.

Permintaan yang berisi ..; di awal bagian jalur akan dianggap tidak valid. Misalnya, /..;bar/ dan /bar/..;/ akan menampilkan error HTTP 400: Bad Request.

Berikut adalah contoh jalur yang dinormalkan:

/internal;some_param/admin dinormalkan menjadi /internal/admin
/a/../b dinormalkan menjadi /b
/bar;param1/baz;baz;param2 dinormalkan menjadi /bar/baz

Akhiran subdomain

Kebijakan yang disetel 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 di bagian akhir dengan google.com, tetapkan kebijakan ke request.host.endsWith(".google.com").

Perlu diketahui bahwa menyetel kebijakan Anda 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 oleh IAP memungkinkan Anda melihat permintaan akses yang diotorisasi dan tidak sah. Lihat permintaan dan semua tingkat akses yang telah dipenuhi pemohon dengan mengikuti proses di bawah:

Buka konsol Google Cloud Logs Explorer untuk project Anda.
Buka halaman log
Pada menu drop-down pemilih resource, pilih resource. Resource HTTPS yang diamankan IAP berada di Aplikasi GAE dan Layanan Backend GCE. Resource TCP dan SSH yang diamankan oleh IAP berada dalam instance VM GTFS.
Di menu drop-down logs type, pilih data_access.
- Jenis log data_access hanya muncul jika ada traffic ke resource Anda setelah Anda mengaktifkan Cloud Audit Logs untuk IAP.
Klik untuk meluaskan tanggal dan waktu akses yang ingin ditinjau.
- Akses yang diizinkan memiliki ikon i berwarna biru.
- Akses yang tidak sah memiliki ikon !! oranye.
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 tidak sah tidak menunjukkan tingkat akses apa 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.