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 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:

  1. Pertama-tama, hapus semua akses ke tabel, menggunakan kontrol akses tabel.
  2. Hapus semua kebijakan akses tingkat baris.
  3. Buat ulang kebijakan akses tingkat baris.
  4. Aktifkan kembali akses ke tabel.

Atau, Anda dapat membuat kebijakan akses tingkat baris baru terlebih dahulu pada tabel, lalu menghapus kebijakan akses tingkat baris sebelumnya 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 harus memiliki izin bigquery.tables.getData di 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.

Mengelola peran Filtered Data Viewer melalui kebijakan akses tingkat baris

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 akses dengan pernyataan DDL.

Peran bigquery.filteredDataViewer tidak boleh diberikan melalui IAM ke resource dengan level lebih tinggi, seperti tabel, set data, atau project. Memberikan peran dengan cara ini memungkinkan pengguna melihat baris yang ditentukan oleh semua kebijakan akses tingkat baris dalam cakupan tersebut, terlepas dari batasan yang diinginkan. Meskipun gabungan filter kebijakan akses tingkat baris mungkin tidak mencakup seluruh tabel, praktik ini menimbulkan risiko keamanan yang signifikan dan merusak tujuan keamanan tingkat baris.

Sebaiknya kelola peran bigquery.filteredDataViewer secara eksklusif melalui kebijakan akses tingkat baris. Metode ini memastikan bahwa akun utama diberi peran bigquery.filteredDataViewer secara implisit dan benar, dengan mematuhi predikat filter yang ditentukan untuk setiap kebijakan.

Dampak performa filter pada kolom yang dipartisi

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.