Praktik terbaik untuk keamanan tingkat baris di BigQuery
Dokumen ini menjelaskan praktik terbaik saat menggunakan keamanan tingkat baris.
Sebelum membaca dokumen ini, pahami keamanan tingkat baris dengan membaca Pengantar keamanan tingkat baris BigQuery dan Bekerja dengan tingkat baris keamanan.
Membatasi izin pengguna untuk membatasi serangan side-channel
Serangan side-channel adalah serangan keamanan berdasarkan informasi yang diperoleh dari sistem itu sendiri. Penyerang dengan izin yang lebih luas daripada yang diperlukan dapat lebih mudah memasang serangan side-channel, dan mempelajari data sensitif dengan mengamati atau menelusuri penagihan, logging, atau pesan sistem.
Untuk mengurangi peluang tersebut, BigQuery menyembunyikan statistik sensitif di semua kueri terhadap tabel dengan keamanan tingkat baris. Statistik sensitif ini mencakup jumlah byte dan partisi yang diproses, jumlah byte yang ditagih, dan tahapan paket kueri.
Sebaiknya admin tidak memberikan izin berikut kepada pengguna yang seharusnya hanya melihat data yang difilter, supaya tidak memberikan akses ke data sensitif.
| Izin | Data sensitif |
|---|---|
| Peran Project Owner atau Project Creator | Pemilik project dapat melihat byte yang diproses dan data terkait di log audit. Pembuat project dapat membuat project baru tempat dia menjadi pemiliknya, serta melihat log audit dan penagihan. |
| Peran Edit Data, Pemilik, atau Viewer BigQuery | Melihat pesan error pada kueri. |
| Izin lihat Penagihan Cloud | Lihat penagihan BigQuery. |
Contoh
- Melalui pengamatan berulang terhadap durasi kueri saat membuat kueri tabel dengan kebijakan akses tingkat baris, pengguna dapat menyimpulkan nilai baris yang mungkin dilindungi oleh kebijakan akses tingkat baris. Jenis serangan ini memerlukan banyak upaya berulang pada rentang nilai kunci dalam partisi atau pengelompokan kolom. Meskipun ada derau yang melekat saat mengamati atau mengukur durasi kueri, dengan upaya berulang, penyerang dapat memperoleh perkiraan yang dapat diandalkan. Jika Anda sensitif terhadap tingkat perlindungan ini, sebaiknya gunakan tabel terpisah untuk memisahkan baris dengan persyaratan kontrol akses yang berbeda.
- Penyerang dapat menelusuri byte yang diproses oleh kueri dengan memantau error yang terjadi saat batas tugas kueri (seperti byte maksimum yang ditagih atau kontrol biaya kustom) terlampaui. Namun, serangan ini membutuhkan volume kueri yang tinggi.
- Melalui kueri berulang dan mengamati jumlah penagihan BigQuery di Penagihan Cloud, pengguna dapat menyimpulkan nilai baris yang mungkin dilindungi oleh kebijakan akses tingkat baris. Jenis serangan ini memerlukan banyak upaya berulang pada rentang nilai kunci dalam mempartisi atau mengelompokkan kolom. Jika Anda sensitif terhadap tingkat perlindungan ini, sebaiknya batasi akses ke data penagihan untuk kueri.
Sebaiknya admin juga memantau Cloud Audit Logs(/bigquery/docs/reference/auditlogs) untuk menemukan aktivitas mencurigakan pada tabel dengan keamanan tingkat baris, seperti penambahan yang tidak terduga, modifikasi, dan penghapusan kebijakan akses tingkat baris.
Membatasi izin pengguna untuk membatasi modifikasi data
Pengguna yang memiliki izin tulis ke tabel dapat menyisipkan data ke dalam tabel dengan perintah bq load atau dengan BigQuery Storage Write API. Dengan begitu, pengguna yang memiliki izin tulis dapat mengubah hasil kueri pengguna lain.
Sebaiknya admin membuat grup Google terpisah untuk kebijakan akses tulis tabel dan kebijakan akses tingkat baris. Pengguna yang seharusnya hanya melihat hasil tabel yang difilter tidak boleh memiliki akses tulis ke tabel yang difilter.
Menghindari akses yang tidak disengaja saat membuat ulang kebijakan akses tingkat baris
Saat menambahkan kebijakan akses baris pada tabel untuk pertama kalinya, Anda akan segera mulai memfilter data dalam hasil kueri. Saat menghapus kebijakan akses tingkat baris terakhir di tabel, meskipun Anda hanya ingin membuat ulang kebijakan akses tingkat baris, Anda dapat secara tidak sengaja memberikan akses tanpa filter ke pengguna yang lebih luas daripada audiens yang seharusnya.
Sebaiknya admin memberi perhatian khusus saat membuat ulang kebijakan akses tingkat baris terakhir di tabel, dengan mengikuti panduan berikut:
- Pertama-tama, hapus semua akses ke tabel, menggunakan kontrol akses tabel.
- Hapus semua kebijakan akses tingkat baris.
- Buat ulang kebijakan akses tingkat baris yang diinginkan.
- Aktifkan kembali akses ke tabel.
Atau, Anda dapat membuat kebijakan akses tingkat baris baru terlebih dahulu pada tabel, lalu menghapus kebijakan akses tingkat baris lama yang tidak lagi diperlukan.
Gunakan keamanan tingkat baris hanya dalam organisasi, bukan antar-organisasi
Jangan gunakan fitur keamanan tingkat baris di seluruh organisasi untuk membantu mencegah kebocoran data melalui serangan side-channel dan mempertahankan kontrol yang lebih besar atas akses ke data sensitif.
Untuk kebijakan akses tingkat baris subkueri, buat dan telusuri tabel dalam organisasi atau project. Hal ini menghasilkan keamanan yang lebih baik dan konfigurasi ACL
yang lebih sederhana, karena penerima hibah harus memiliki izin bigquery.tables.getData pada
target dan tabel yang dirujuk dalam kebijakan, serta izin
keamanan tingkat kolom yang relevan.
Sebaiknya gunakan fitur keamanan tingkat baris hanya untuk batasan keamanan dalam organisasi (misalnya untuk berbagi data dalam organisasi/badan usaha/perusahaan), dan bukan untuk lintas organisasi atau keamanan publik.
Contoh
Di luar organisasi, Anda memiliki sedikit kontrol atas siapa yang memiliki akses ke data. Dalam organisasi, Anda dapat mengontrol siapa yang telah diberi akses ke informasi penagihan kueri terhadap tabel dengan kebijakan akses tingkat baris. Informasi penagihan adalah vektor untuk serangan side-channel.
Gunakan peran Filtered Data Viewer dengan hati-hati
Saat Anda membuat kebijakan akses tingkat baris, akun utama dalam kebijakan tersebut akan otomatis diberi peran bigquery.filteredDataViewer. Anda hanya dapat menambahkan atau menghapus akun utama dari kebijakan dengan pernyataan DDL.
Namun, Anda dapat memberikan peran bigquery.filteredDataViewer melalui IAM ke resource dengan level lebih tinggi, seperti tabel, set data, atau project. Memberikan peran bigquery.filteredDataViewer kepada pengguna akan memberi mereka kemampuan untuk melihat baris yang ditentukan oleh semua kebijakan akses tingkat baris dalam tabel, set data, atau project tersebut.
Namun, memberikan peran bigquery.filteredDataViewer pada tabel bukan berarti bahwa pengguna dapat melihat semua baris di tabel tersebut. Gabungan semua ekspresi filter kebijakan akses tingkat baris mungkin membentuk penutupan di seluruh tabel.
Sebaiknya Anda berhati-hati sebelum memberikan peran bigquery.filteredDataViewer pada resource apa pun.
Pemfilteran pada kolom yang dipartisi akan memengaruhi performa
Filter kebijakan akses tingkat baris tidak berpartisipasi dalam pruning kueri pada tabel yang dipartisi dan dikelompokkan.
Jika kebijakan akses tingkat baris menyebutkan kolom yang dipartisi, kueri Anda tidak akan mendapatkan manfaat performa dari pemangkasan kueri.