Dokumen ini menjelaskan praktik terbaik yang direkomendasikan untuk menggunakan akses kontekstual guna membantu melindungi resource Anda Google Cloud secara efektif. Akses kontekstual adalah pendekatan keamanan yang memungkinkan Anda mengontrol akses pengguna berdasarkan kekuatan autentikasi, postur 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 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 Identity and Access Management (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 ingin menerapkan kontrol akses kontekstual ke aplikasi, resource, atau keduanya. Untuk membuat keputusan tersebut, sebaiknya bedakan antara 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 Google Cloud konsol, 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 membedakan lebih lanjut aplikasi lini bisnis berdasarkan cara aplikasi tersebut 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 Anda deploy di balik IAP.
- OAuth: Aplikasi web atau desktop kustom yang menggunakan OAuth 2.0 dan menggunakan satu atau beberapa Google Cloud cakupan OAuth.
Diagram alur berikut menunjukkan pendekatan akses kontekstual yang paling sesuai untuk setiap jenis aplikasi:
Diagram ini menunjukkan jenis aplikasi berikut:
Aplikasi administratif: Umumnya, lebih penting untuk melindungi Google Cloud resource yang aksesnya difasilitasi oleh aplikasi administratif daripada aplikasi itu sendiri. Pertimbangkan skenario berikut:
- Pengguna tidak dapat mengakses resource apa pun. Dalam skenario ini, kemungkinan besar akses ke aplikasi administratif tidak terlalu berharga bagi pengguna.
- Pengguna memiliki akses ke resource, tetapi tidak dapat mengakses aplikasi administratif. Dalam skenario ini, pengguna mungkin dapat menemukan aplikasi administratif lain yang tidak diblokir dan memungkinkan mereka mengakses resource.
Oleh karena itu, untuk aplikasi administratif, gunakan pendekatan yang berpusat pada resource. Untuk cara paling efektif menerapkan kontrol akses kontekstual yang tepat ke resource, gunakan perimeter layanan Virtual Private Cloud (VPC) dengan aturan ingress 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 di organisasi Anda Google Cloud . Oleh karena itu, sebaiknya batasi jumlah keseluruhan tingkat akses, dan buat tingkat akses yang bermakna dan dapat diterapkan di beberapa resource. Pertimbangkan hal berikut:
- Hindari menyematkan nama resource atau aplikasi 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 gabungan
Untuk membantu mengurangi overhead pemeliharaan dan memastikan konsistensi saat subnetwork atau region berubah, jangan ulangi persyaratan yang sama di beberapa tingkat akses. Sebagai gantinya, buat tingkat akses saling bergantung.
Misalnya, jangan cantumkan region tepercaya
atau subnetwork IP 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 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
membersyang mencantumkan satu atau beberapa pengguna akses darurat Anda. - Tetapkan fungsi gabungan ke kondisi
ORsehingga pengguna hanya perlu memenuhi salah satu dari dua kondisi.
Misalnya, tingkat akses berikut membatasi akses ke tiga region, 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 memberi tahu pengguna, dan membantu mengurangi permintaan dukungan, konfigurasi pesan perbaikan kustom yang memberi pengguna langkah-langkah yang harus diambil untuk mendapatkan kembali akses.
Pengelolaan binding akses
Binding akses memungkinkan Anda mengonfigurasi akses kontekstual untuk aplikasi OAuth yang menggunakan satu atau beberapa Google Cloud cakupan. Binding akses juga merupakan cara efektif untuk menerapkan akses kontekstual untuk aplikasi lini bisnis.
Bagian berikut menjelaskan praktik yang direkomendasikan untuk digunakan saat Anda menggunakan binding akses.
Menggunakan satu binding akses dengan setelan cakupan
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 dua batasan ini, gunakan satu binding akses yang berlaku untuk semua pengguna Anda:
- Buat grup yang otomatis berisi semua pengguna akun Cloud Identity atau Google Workspace Anda.
- Buat atau gunakan binding akses yang mengaitkan tingkat akses default dengan grup. Tingkat akses default harus sesuai untuk sebagian besar pengguna, perangkat, dan aplikasi.
- Jika perlu, gunakan
setelan akses cakupan (
scopedAccessSettings) untuk menetapkan tingkat akses yang lebih lemah ke aplikasi yang dipilih.
Menggunakan tingkat akses default yang ketat
Jika binding akses menentukan setelan akses cakupan 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 cakupan untuk aplikasi OAuth, Anda dapat menurunkan persyaratan akses efektif.
- Setelan akses cakupan tidak berpengaruh jika menggunakan tingkat akses yang lebih ketat daripada tingkat akses default binding akses.
Saat memilih tingkat akses default untuk binding akses, sebaiknya lakukan hal berikut:
- Gunakan tingkat akses yang ketat sebagai tingkat akses default.
- Terapkan tingkat akses yang lebih rendah ke setiap aplikasi OAuth menggunakan setelan akses cakupan.
Pertimbangkan untuk menambahkan beberapa atau semua batasan berikut ke tingkat akses default:
- Pembatasan browser dan perangkat: Wajibkan pengguna mengakses aplikasi menggunakan browser Chrome terkelola dan perangkat yang disetujui administrator.
- Pembatasan geografis: Jika organisasi Anda beroperasi secara eksklusif di region tertentu, gunakan pembatasan region untuk hanya menyertakan region tersebut dalam daftar yang diizinkan. Jika tidak, Anda dapat menggunakan pembatasan region untuk membatasi akses ke wilayah geografis 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 ingress perimeter layanan VPC.
Mengelola pengecualian menurut aplikasi
Untuk mengelola pengecualian ke tingkat akses default, tambahkan pengecualian untuk setiap aplikasi, bukan pengecualian untuk pengguna atau grup.
Tingkat akses default yang ketat mungkin sesuai untuk sebagian besar aplikasi, tetapi tidak untuk semua aplikasi Anda:
- Beberapa aplikasi mungkin kurang sensitif, dan Anda harus membuatnya dapat diakses oleh pengguna yang tidak memenuhi tingkat akses default. Contohnya mungkin 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 setiap aplikasi dari tingkat akses default, gunakan setelan akses cakupan. Untuk setiap aplikasi yang terpengaruh, tambahkan setelan cakupan dan tetapkan tingkat akses yang lebih sesuai untuk setiap aplikasi.
Jangan buat 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 binding akses yang tumpang-tindih
Binding akses dikaitkan dengan grup. Jika pengguna adalah anggota beberapa grup, beberapa binding akses dapat berlaku untuknya. Dalam hal ini, persyaratan akses kontekstual dari binding akses ini digabungkan menggunakan semantik OR.
Perilaku ini dapat menyebabkan efek yang tidak diinginkan. Misalnya, saat pengguna diizinkan bergabung dengan grup tambahan, perlindungan aplikasi tertentu mungkin terganggu.
Untuk membantu mencegah situasi seperti itu, sebaiknya hindari binding akses yang tumpang-tindih:
- Minimalkan jumlah binding akses, idealnya menjadi satu.
- Jika Anda memerlukan beberapa binding akses, tetapkan binding akses tersebut ke grup yang saling eksklusif.
Melindungi grup dari modifikasi yang tidak sah
Secara default, Cloud Identity memungkinkan 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 menghindari 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 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 dimiliki Google Cloud organisasi Anda. Pengguna ini masih tunduk pada binding akses di organisasi Google Cloud Anda jika mereka mencoba mengakses resource di organisasi Google Cloud lain. Penerapan binding akses pada pengguna ini 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 binding akses Anda efektif, jangan berikan akses pengguna eksternal ke aplikasi atau resource apa pun di organisasi Google Cloud Anda. Selain itu, jangan tambahkan 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 buat binding akses yang tumpang-tindih. Jika lebih dari satu binding akses tersebut berlaku untuk pengguna, hanya binding akses yang terakhir diupdate 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 mengganggu kontrol akses kontekstual Anda.
Ada risiko lain yang terlibat saat pengguna dapat bertindak sebagai akun layanan. Jika Anda ingin mengizinkan pengguna untuk sementara meningkatkan hak istimewa mereka, sebaiknya gunakan Privileged Access Manager. Jangan gunakan peniruan identitas akun layanan, kecuali untuk tujuan pengembangan.
Untuk mengetahui 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 ingress memungkinkan Anda memberikan akses kontekstual dari luar perimeter layanan ke resource di dalam perimeter. Perimeter layanan VPC dan aturan ingress melindungi Google Cloud resource, bukan setiap aplikasi. Oleh karena itu, perimeter layanan dengan aturan ingress sangat ideal untuk menerapkan akses kontekstual untuk alat administratif seperti konsol dan gcloud CLI. Google Cloud
Untuk mengetahui informasi selengkapnya dan praktik terbaik 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 kontekstual.
Menyertakan penerusan TCP IAP sebagai layanan yang dibatasi
Mungkin berisiko jika mengizinkan pengguna terhubung ke instance VM di perimeter layanan Anda menggunakan SSH atau RDP karena alasan berikut:
- Aturan ingress Anda tidak berlaku untuk koneksi karena penggunaan SSH dan RDP tidak melibatkan akses Google API apa pun.
- Setelah pengguna membuat sesi SSH atau RDP, akses API apa pun 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:
- Sertakan layanan
iaptunnel.googleapis.comsebagai layanan yang dibatasi. - Konfigurasi aturan firewall yang membatasi akses ke port SSH dan RDP 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 Google dan token refresh 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 certificate authority 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 yang paling sensitif. Pendekatan ini memungkinkan Anda menyeimbangkan kekuatan keamanan dengan persyaratan infrastruktur minimal dan dampak keseluruhan.
Kontributor
Penulis: Johannes Passing | Cloud Solutions Architect
Kontributor lainnya: Ido Flatow | Cloud Solutions Architect