Praktik terbaik untuk mengamankan aplikasi dan resource menggunakan akses kontekstual

Last reviewed 2025-07-22 UTC

Dokumen ini menjelaskan praktik terbaik yang direkomendasikan untuk menggunakan akses yang memahami konteks guna membantu melindungi Google Cloud resource Anda secara efektif. Akses kontekstual adalah pendekatan keamanan yang memungkinkan Anda mengontrol akses pengguna berdasarkan kekuatan autentikasi, kondisi perangkat, lokasi jaringan, lokasi geografis, atau atribut lainnya. Pendekatan ini tidak hanya menggunakan identitas pengguna dasar untuk akses keamanan, tetapi juga dapat membantu Anda menerapkan model keamanan zero-trust untuk meningkatkan postur keamanan secara keseluruhan. Untuk mengetahui detail tentang cara menerapkan akses kontekstual untuk berbagai jenis aplikasi dan resource, lihat Mengamankan aplikasi dan resource menggunakan akses kontekstual.

Untuk membantu mengamankan aplikasi dan Google Cloud resource Anda, Anda dapat menentukan kontrol akses terperinci, berdasarkan berbagai faktor kontekstual dan kombinasinya. Anda dapat menggunakan Access Context Manager untuk menentukan kebijakan akses, yang berisi tingkat akses dan parameter layanan.

Dokumen ini ditujukan untuk profesional keamanan yang bertanggung jawab atas Pengelolaan Identitas dan Akses (IAM) serta keamanan resource dan aplikasi. Google Cloud Dokumen ini mengasumsikan bahwa Anda sudah memahami Access Context Manager,Google Cloud, dan pengelolaan IAM.

Pendekatan akses kontekstual

Saat menyiapkan akses kontekstual di organisasi, Anda harus memutuskan apakah Anda ingin menerapkan kontrol akses kontekstual ke aplikasi, resource, atau keduanya. Untuk membuat keputusan tersebut, Anda perlu membedakan berbagai jenis aplikasi dan layanan berikut:

  • Aplikasi administratif: Aplikasi ini memungkinkan pengguna mengelola atau berinteraksi dengan Google Cloud resource seperti instance VM, set data BigQuery, atau bucket Cloud Storage. Contoh aplikasi administratif mencakup konsol Google Cloud , Google Cloud CLI, Terraform, dan IAP Desktop.
  • Aplikasi lini bisnis: Aplikasi ini mencakup aplikasi web yang berjalan di Google Cloud dan menggunakan SAML atau Identity-Aware Proxy (IAP) untuk autentikasi dan otorisasi. Aplikasi ini terkadang disebut aplikasi internal. Contoh aplikasi lini bisnis mencakup sistem CRM, dasbor, dan aplikasi kustom lainnya.
  • Google Workspace dan layanan Google lainnya: Layanan ini disediakan oleh Google, tetapi tidak terkait dengan Google Cloud.

Anda dapat lebih membedakan aplikasi lini bisnis berdasarkan cara aplikasi menangani autentikasi dan otorisasi:

  • SAML: Aplikasi yang menggunakan SAML Google Workspace untuk autentikasi. Aplikasi SaaS sering kali termasuk dalam kategori ini.
  • IAP: Aplikasi web kustom yang telah Anda deploy di balik IAP.
  • OAuth: Aplikasi web atau desktop kustom yang menggunakan OAuth 2.0 dan menggunakan satu atau beberapa cakupan OAuth 2.0.Google Cloud

Diagram alur berikut menunjukkan pendekatan akses yang sesuai dan sadar konteks untuk setiap jenis aplikasi:

Pohon keputusan untuk pendekatan akses kontekstual untuk setiap jenis aplikasi.

Diagram menunjukkan jenis aplikasi berikut:

  • Aplikasi administratif: Secara umum, lebih penting untuk melindungi resourceGoogle Cloud yang memfasilitasi akses aplikasi administratif, daripada aplikasi itu sendiri. Perhatikan skenario berikut:

    • Pengguna tidak dapat mengakses resource apa pun. Dalam skenario ini, kemungkinan akses ke aplikasi administratif tidak terlalu berharga bagi pengguna.
    • Pengguna memiliki akses ke resource, tetapi tidak dapat mengakses aplikasi administratif. Dalam skenario ini, mereka mungkin dapat menemukan aplikasi administratif lain yang tidak diblokir dan memungkinkan mereka mengakses resource.

    Oleh karena itu, untuk aplikasi administratif, gunakan pendekatan yang berfokus pada resource. Untuk cara paling efektif dalam menerapkan kontrol akses kontekstual yang tepat ke resource, gunakan perimeter layanan Virtual Private Cloud (VPC) dengan aturan masuk yang sesuai. Anda dapat melengkapi perimeter layanan VPC dengan binding akses.

  • Aplikasi lini bisnis yang menggunakan OAuth: Untuk aplikasi ini, penting untuk melindungi akses ke aplikasi itu sendiri, serta resource yang mungkin digunakan aplikasi. Untuk melindungi aplikasi menggunakan akses kontekstual, gunakan binding akses.

  • Aplikasi lini bisnis yang menggunakan IAP: Meskipun IAP menggunakan OAuth, Anda tidak dapat menggunakan binding akses untuk melindungi aplikasi yang menggunakan IAP untuk mengautentikasi pengguna. Sebagai gantinya, lindungi aplikasi ini menggunakan kondisi IAM.

  • Aplikasi lini bisnis yang menggunakan SAML: Mirip dengan aplikasi lini bisnis yang menggunakan OAuth, penting untuk melindungi akses ke aplikasi itu sendiri, serta resource yang mungkin digunakan aplikasi. Untuk melindungi aplikasi ini, gunakan akses kontekstual Google Workspace.

  • Google Workspace dan layanan Google lainnya: Untuk aplikasi ini, penting untuk melindungi akses ke aplikasi itu sendiri, serta resource yang mungkin digunakan aplikasi. Untuk melindungi aplikasi ini, gunakan akses kontekstual Google Workspace.

Pengelolaan tingkat akses

Bagian berikut menjelaskan praktik yang direkomendasikan untuk digunakan saat Anda mengelola tingkat akses.

Membuat tingkat akses yang dapat digunakan kembali

Tingkat akses adalah resource global dan dimaksudkan untuk digunakan di seluruh resource dalam Google Cloud organisasi Anda. Oleh karena itu, sebaiknya batasi jumlah keseluruhan tingkat akses, dan buat tingkat akses tersebut bermakna dan dapat diterapkan di beberapa resource. Pertimbangkan hal berikut:

  • Hindari menyematkan nama aplikasi atau resource tertentu dalam nama tingkat akses.
  • Hindari mengenkode persyaratan khusus resource atau khusus aplikasi dalam tingkat akses.
  • Gunakan nama yang menegaskan postur pengguna atau perangkat tertentu, seperti Fully Trusted Device.

Menggunakan tingkat akses komposit

Untuk membantu mengurangi beban pemeliharaan dan memastikan konsistensi saat subnetwork atau region berubah, jangan ulangi persyaratan yang sama di beberapa tingkat akses. Sebagai gantinya, biarkan tingkat akses bergantung satu sama lain.

Misalnya, jangan mencantumkan region atau subnetwork IP tepercaya yang sama di beberapa tingkat akses, tetapi buat tingkat akses tambahan yang disebut Trusted location. Tingkat Trusted location ini dapat berfungsi sebagai dependensi untuk tingkat akses lainnya.

Mengecualikan pengguna akses darurat di tingkat akses

Untuk mencegah penguncian yang tidak disengaja, sebaiknya kecualikan setidaknya satu pengguna akses darurat dari semua tingkat akses. Untuk memastikan bahwa pengecualian berlaku untuk semua aplikasi dan resource yang Anda terapkan tingkat aksesnya, konfigurasi pengecualian di tingkat akses itu sendiri:

  • Tambahkan satu kondisi yang menentukan persyaratan reguler Anda.
  • Tambahkan kondisi lain dengan persyaratan members yang mencantumkan satu atau beberapa pengguna akses darurat Anda.
  • Tetapkan fungsi penggabungan ke kondisi OR sehingga pengguna hanya perlu memenuhi salah satu dari dua kondisi.

Misalnya, tingkat akses berikut membatasi akses ke tiga wilayah, tetapi pengguna emergencyaccess@example.net dikecualikan dari persyaratan ini:

{
  "name": "accessPolicies/…",
  "title": "Example access level",
  "basic": {
    "conditions": [
      {
        "members": [
          "user:emergencyaccess@example.net"
        ]
      },
      {
        "regions": [
          "DE",
          "AU",
          "SG"
        ]
      }
    ],
    "combiningFunction": "OR"
  }
}

Mengonfigurasi pesan perbaikan

Pengguna di organisasi Anda mungkin tidak menyadari bahwa lokasi, perangkat, dan faktor lainnya dapat memengaruhi apakah mereka diizinkan mengakses aplikasi tertentu atau tidak. Untuk terus memberi tahu pengguna, dan untuk membantu mengurangi permintaan dukungan, konfigurasi pesan perbaikan kustom yang memberi pengguna langkah-langkah yang harus dilakukan untuk mendapatkan kembali akses.

Pengelolaan binding akses

Dengan binding akses, Anda dapat mengonfigurasi akses kontekstual untuk aplikasi OAuth yang menggunakan satu atau beberapa cakupan Google Cloud . Binding akses juga merupakan cara yang efektif untuk menerapkan akses kontekstual bagi aplikasi lini bisnis.

Bagian berikut menjelaskan praktik yang direkomendasikan untuk digunakan saat Anda menggunakan binding akses.

Menggunakan satu binding akses dengan setelan yang dicakup

Saat menggunakan binding akses, Anda harus mempertimbangkan batasan berikut:

  • Setiap grup Cloud Identity dapat memiliki maksimum satu binding akses.
  • Jika lebih dari satu binding akses berlaku untuk pengguna, binding akses yang kurang ketat akan diprioritaskan.

Untuk mengakomodasi kedua batasan ini, gunakan satu binding akses yang berlaku untuk semua pengguna Anda:

  1. Buat grup yang secara otomatis berisi semua pengguna akun Cloud Identity atau Google Workspace Anda.
  2. Buat atau gunakan binding akses yang mengaitkan tingkat akses default dengan grup. Tingkat akses default harus sesuai untuk sebagian besar pengguna, perangkat, dan aplikasi.
  3. Jika perlu, gunakan setelan akses yang tercakup (scopedAccessSettings) untuk menetapkan tingkat akses yang lebih rendah ke aplikasi yang dipilih.

Menggunakan tingkat akses default yang ketat

Jika binding akses menentukan setelan akses yang tercakup dan tingkat akses default, kedua tingkat akses tersebut akan digabungkan menggunakan semantik OR. Perilaku ini memiliki implikasi berikut:

  • Pengguna hanya perlu memenuhi salah satu tingkat akses untuk mengakses aplikasi OAuth.
  • Saat menambahkan setelan akses yang memiliki cakupan untuk aplikasi OAuth, Anda dapat menurunkan persyaratan akses yang efektif.
  • Setelan akses yang tercakup tidak berpengaruh jika menggunakan tingkat akses yang lebih ketat daripada tingkat akses default binding akses.

Saat memilih tingkat akses default untuk binding akses, sebaiknya Anda melakukan hal berikut:

  • Gunakan tingkat akses ketat sebagai tingkat akses default.
  • Terapkan tingkat akses yang lebih rendah ke setiap aplikasi OAuth menggunakan setelan akses yang diberi cakupan.

Pertimbangkan untuk menambahkan beberapa atau semua batasan berikut ke tingkat akses default:

  • Pembatasan browser dan perangkat: Mewajibkan pengguna Anda mengakses aplikasi menggunakan browser Chrome terkelola dan perangkat yang disetujui administrator.
  • Pembatasan geografis: Jika organisasi Anda beroperasi secara eksklusif di wilayah tertentu, gunakan pembatasan wilayah untuk menyertakan hanya wilayah tersebut dalam daftar yang diizinkan. Jika tidak, Anda dapat menggunakan pembatasan wilayah untuk membatasi akses ke wilayah yang dikenai sanksi atau yang tidak relevan karena alasan lain.
  • Pembatasan jaringan IP: Jika pengguna di organisasi Anda mengakses Google Cloud secara eksklusif dari jaringan tertentu, atau jika organisasi Anda menggunakan proxy keluar umum, Anda dapat menyertakan pembatasan jaringan IP.

Jangan gunakan tingkat akses yang memerlukan autentikasi berbasis sertifikat sebagai tingkat akses default. Autentikasi berbasis sertifikat paling cocok untuk aturan masuk perimeter layanan VPC.

Mengelola pengecualian menurut aplikasi

Untuk mengelola pengecualian pada tingkat akses default, tambahkan pengecualian untuk setiap aplikasi, bukan pengecualian untuk pengguna atau grup.

Tingkat akses default yang ketat mungkin cocok untuk sebagian besar aplikasi, tetapi tidak untuk semua aplikasi Anda:

  • Beberapa aplikasi mungkin kurang sensitif, dan Anda perlu membuatnya dapat diakses oleh pengguna yang tidak memenuhi tingkat akses default. Contohnya dapat mencakup aplikasi yang harus dapat diakses oleh partner, tamu, atau alumni.
  • Beberapa aplikasi mungkin secara teknis tidak kompatibel dengan salah satu batasan yang diterapkan oleh tingkat akses default.

Untuk mengecualikan aplikasi tertentu dari tingkat akses default, gunakan setelan akses cakupan. Untuk setiap aplikasi yang terpengaruh, tambahkan setelan yang tercakup dan tetapkan tingkat akses yang lebih sesuai untuk setiap aplikasi.

Jangan membuat binding akses tambahan untuk mengelola pengecualian menurut pengguna atau grup. Binding akses tambahan dapat menyebabkan masalah berikut:

  • Anda mungkin tidak sengaja membuat binding akses yang tumpang-tindih.
  • Mungkin sulit untuk menentukan persyaratan akses kontekstual mana yang diterapkan secara efektif untuk setiap aplikasi.

Menghindari tumpang-tindih binding akses

Binding akses dikaitkan dengan grup. Jika pengguna adalah anggota beberapa grup, beberapa binding akses dapat berlaku untuknya. Dalam hal ini, persyaratan akses yang sesuai konteks dari binding akses ini digabungkan menggunakan semantik OR.

Perilaku ini dapat menyebabkan efek yang tidak diinginkan. Misalnya, jika pengguna diizinkan bergabung ke grup tambahan, perlindungan aplikasi tertentu mungkin terganggu.

Untuk membantu mencegah situasi seperti itu, sebaiknya hindari tumpang-tindih binding akses:

  • Minimalkan jumlah binding akses, idealnya menjadi satu.
  • Jika Anda memerlukan beberapa binding akses, tetapkan binding tersebut ke grup yang saling eksklusif.

Melindungi grup dari modifikasi yang tidak sah

Secara default, Cloud Identity mengizinkan anggota grup keluar dari grup. Perilaku ini sesuai untuk grup akses, tetapi bermasalah untuk grup dengan binding akses terkait. Jika pengguna keluar dari grup yang memiliki binding akses terkait, pengguna tersebut tidak lagi tunduk pada persyaratan akses kontekstual yang diberlakukan oleh binding akses. Oleh karena itu, pengguna dapat mengakali persyaratan akses kontekstual dengan keluar dari grup.

Selalu gunakan grup penerapan dan jangan izinkan pengguna keluar dari grup penerapan saat Anda mengonfigurasi binding akses. Atau, buat grup yang secara otomatis berisi semua pengguna akun Cloud Identity atau Google Workspace Anda.

Jangan izinkan akses pengguna eksternal saat Anda menggunakan binding akses

Binding akses hanya memengaruhi pengguna akun Cloud Identity atau Google Workspace yang menjadi anggota Google Cloud organisasi Anda. Pengguna ini tetap tunduk pada binding akses di organisasi Google Cloud Anda jika mereka mencoba mengakses resource di organisasi Google Cloud lain. Penerapan binding akses ini pada pengguna berbeda dengan perilaku dalam konteks lain dengan Cloud Identity.

Jika Anda mengizinkan pengguna dari akun Cloud Identity atau Google Workspace eksternal untuk mengakses resource di Google Cloud organisasi Anda, binding akses Anda tidak akan berpengaruh pada pengguna tersebut.

Untuk membantu memastikan bahwa binding akses Anda efektif, jangan berikan akses kepada pengguna eksternal ke aplikasi atau resource apa pun di organisasi Google Cloud Anda. Selain itu, jangan menambahkan pengguna eksternal ke grup di akun Cloud Identity atau Google Workspace Anda.

Menggunakan binding akses terpisah untuk kontrol durasi sesi

Selain kontrol akses kontekstual, Anda juga dapat menggunakan binding akses untuk mengelola durasi sesi browser dan token OAuth.

Saat menggunakan binding akses untuk mengontrol akses kontekstual, sebaiknya hindari binding akses yang tumpang-tindih.

Saat menggunakan binding akses untuk mengontrol durasi sesi, jangan membuat binding akses yang tumpang-tindih. Jika lebih dari satu binding akses semacam itu berlaku untuk pengguna, hanya binding akses yang terakhir diperbarui yang akan berlaku, yang dapat menyebabkan hasil yang tidak diinginkan.

Untuk membantu mencegah hasil yang tidak diinginkan tersebut, gunakan binding akses terpisah untuk mengontrol durasi sesi.

Jangan izinkan pengguna bertindak sebagai akun layanan

Binding akses berlaku untuk pengguna Cloud Identity dan Google Workspace, tetapi binding akses tidak memengaruhi akun layanan. Jika Anda mengizinkan pengguna untuk mengautentikasi dan bertindak sebagai akun layanan, mereka mungkin dapat merusak kontrol akses yang sadar konteks Anda.

Risiko lain juga terlibat saat pengguna dapat bertindak sebagai akun layanan. Jika Anda ingin mengizinkan pengguna meningkatkan hak istimewa mereka untuk sementara, sebaiknya gunakan Privileged Access Manager. Jangan gunakan peniruan identitas akun layanan, kecuali untuk tujuan pengembangan.

Untuk informasi selengkapnya tentang cara mengamankan akun layanan dan kunci akun layanan, lihat Praktik terbaik untuk menggunakan akun layanan dan Praktik terbaik untuk mengelola kunci akun layanan.

Aturan ingress untuk perimeter layanan VPC

Aturan masuk memungkinkan Anda memberikan akses kontekstual dari luar perimeter layanan ke resource di dalam perimeter. Perimeter layanan VPC dan aturan masuk melindungi resource, bukan aplikasi individual. Google Cloud Oleh karena itu, perimeter layanan dengan aturan traffic masuk sangat ideal untuk menerapkan akses kontekstual untuk alat administratif seperti konsol Google Cloud dan gcloud CLI.

Untuk mengetahui informasi dan praktik terbaik selengkapnya tentang perimeter layanan VPC, lihat Praktik terbaik untuk mengaktifkan Kontrol Layanan VPC.

Bagian berikut menjelaskan praktik yang direkomendasikan saat Anda menggunakan aturan ingress untuk menerapkan akses yang sesuai konteks.

Menyertakan penerusan TCP IAP sebagai layanan terbatas

Mengizinkan pengguna terhubung ke instance VM di perimeter layanan Anda menggunakan SSH atau RDP dapat menimbulkan risiko karena alasan berikut:

  • Aturan ingress Anda tidak berlaku untuk koneksi karena penggunaan SSH dan RDP tidak melibatkan akses Google API.
  • Setelah pengguna membuat sesi SSH atau RDP, setiap akses API yang dimulai dari dalam sesi tersebut dianggap berasal dari dalam perimeter layanan. Oleh karena itu, aturan ingress Anda tidak berlaku untuk akses API apa pun yang dimulai dari dalam sesi tersebut.

Untuk mengurangi risiko ini, izinkan akses SSH dan RDP ke VM hanya melalui penerusan TCP IAP:

Gunakan penerusan TCP IAP untuk membantu memastikan bahwa konfigurasi aturan ingress perimeter layanan VPC Anda berlaku untuk setiap upaya akses SSH dan RDP.

Menggunakan akses berbasis sertifikat untuk perimeter layanan sensitif

Secara default, token akses dan token refresh Google tidak terikat ke perangkat dan dapat rentan terhadap pencurian atau serangan replay. Untuk membantu mengurangi risiko ini, Anda dapat menggunakan akses berbasis sertifikat (CBA), yang membatasi akses ke perangkat yang memiliki sertifikat X.509 tepercaya.

CBA membantu Anda memperkuat keamanan, tetapi pendekatan ini juga menambahkan persyaratan infrastruktur tambahan:

  • Perangkat pengguna harus memiliki sertifikat X.509 yang dikeluarkan oleh otoritas sertifikat internal.
  • Kunci yang terkait dengan sertifikat harus disimpan dengan cara yang mencegah ekspor yang tidak sah.
  • Aplikasi klien harus menggunakan autentikasi TLS timbal balik (mTLS) untuk terhubung ke Google Cloud API.

Gunakan CBA untuk melindungi akses ke perimeter layanan VPC Anda yang paling sensitif. Pendekatan ini memungkinkan Anda menyeimbangkan kekuatan keamanan dengan persyaratan infrastruktur dan dampak keseluruhan yang minimal.

Kontributor

Penulis: Johannes Passing | Cloud Solutions Architect

Kontributor lain: Ido Flatow | Cloud Solutions Architect