Ringkasan tampilan yang diberi parameter

Dokumen ini menjelaskan tampilan berparameter di Spanner. Tampilan berparameter memungkinkan Anda memfilter data secara dinamis berdasarkan parameter sesi yang diteruskan dengan kueri, terutama untuk aplikasi dan sistem agentic yang menggunakan model bahasa besar (LLM).

Tampilan berparameter memperluas kemampuan tampilan database dengan memasukkan parameter konteks langsung ke dalam definisi tampilan. Tampilan berparameter membantu Anda melakukan hal berikut:

  • Teruskan parameter konteks waktu kueri, seperti identitas pengguna atau tenant, ke dalam definisi tampilan.
  • Membatasi hasil kueri hanya pada baris yang cocok dengan parameter yang diberikan.
  • Mencegah pengguna mengabaikan filter data tingkat aplikasi dalam kueri SQL yang dihasilkan atau ad hoc.

Untuk mengetahui informasi selengkapnya, lihat Membuat tampilan berparameter.

Cara kerja tampilan berparameter

Tampilan berparameter menggunakan parameter untuk meneruskan konteks tingkat aplikasi, seperti ID pengguna, ke database dengan aman. Saat aplikasi Anda menjalankan kueri, aplikasi akan mengirimkan konteks dengan pernyataan kueri. Spanner mengakses konteks ini selama eksekusi, tetapi kueri maupun pengguna aplikasi tidak dapat membaca atau mengubahnya.

Fungsi SECURE_CONTEXT() menyediakan antarmuka SQL untuk mengakses parameter aman ini dalam definisi tampilan. Tampilan berparameter memerlukan model keamanan tampilan hak pendefinisi, dengan tampilan menggunakan SECURE_CONTEXT() untuk mengakses nilai dan memfilter hasil.

Misalnya, untuk memfilter data berdasarkan ID pengguna yang membuat kueri, Anda dapat menyertakan hal berikut dalam klausa WHERE tampilan:

CREATE VIEW MyUserData
SQL SECURITY DEFINER AS
(SELECT *
FROM AllUserData
WHERE UserID = CAST(SECURE_CONTEXT('user_id'), INT));

Tindakan ini memungkinkan aplikasi melihat data mereka, tetapi tidak dapat melihat data orang lain. Anda juga dapat membuat tampilan yang memungkinkan moderator melihat data yang kurang sensitif dari pengguna mana pun:

CREATE VIEW SafeUserData
SQL SECURITY DEFINER AS
(SELECT UserID, AccountCreationTime, PublicProfileText
FROM AllUserData
WHERE SECURE_CONTEXT('role') = 'Moderator');

Meskipun Anda dapat menggunakan SECURE_CONTEXT() di mana saja dalam definisi kueri tampilan, praktik terbaik untuk performa adalah menggunakannya dalam klausa WHERE untuk memfilter kolom kunci utama tabel atau indeks. Hal ini memastikan bahwa Spanner secara efisien mengirimkan logika filter ke lapisan penyimpanan.

Secara default, membuat kueri fungsi SECURE_CONTEXT() secara langsung dalam kueri ad hoc akan gagal kecuali jika peran database memiliki peran spanner_secure_context_reader. Tindakan ini mencegah pengguna yang tidak memiliki hak istimewa untuk memeriksa nilai parameter secara langsung.

Pola yang direkomendasikan adalah menggabungkan tabel virtual berparameter dengan tabel virtual hak penentu dan kontrol akses terperinci (FGAC). Untuk memastikan pengguna hanya dapat mengkueri data melalui tampilan:

  1. Aktifkan FGAC dan buat peran database untuk aplikasi Anda.
  2. GRANT hak istimewa SELECT pada tampilan ke peran.
  3. Pastikan peran sistem public tidak memiliki hak istimewa yang diberikan pada tabel atau tampilan dasar.

Contoh:

-- Create a role for the application user
CREATE ROLE pv_user;

-- Grant SELECT permission on the view to the role
GRANT SELECT ON VIEW MyUserData TO ROLE pv_user;

Setelah Anda membuat tampilan berparameter, proses untuk permintaan standar adalah sebagai berikut:

  1. Aplikasi Anda menetapkan konteks aman pada permintaan kueri. Konteks berisi informasi yang mengidentifikasi pengguna aplikasi, seperti ID atau peran pengguna.
  2. Aplikasi menjalankan kueri terhadap tampilan hak pendefinisi.
  3. Tampilan menggunakan fungsi SECURE_CONTEXT() dalam klausa WHERE untuk memfilter baris berdasarkan nilai yang diberikan dalam konteks aman.
  4. Spanner hanya menampilkan baris yang cocok dengan filter, sehingga secara efektif memfilter hasil kueri ke data yang terkait dengan konteks sesi pengguna.

Misalnya, aplikasi dapat meneruskan ID pengguna saat ini dalam konteks aman menggunakan salah satu library klien Spanner. Contoh berikut menggunakan library klien C++ untuk menetapkan parameter aman user_id:

(*request.mutable_secure_context())["user_id"] = "ca6095c4-1a68-44a8-9562-dd9e897326f0";

Kemudian, aplikasi akan menjalankan kueri SQL standar terhadap tampilan. Tabel virtual menggunakan user_id ini dalam klausa WHERE untuk hanya menampilkan kumpulan data yang dimiliki oleh pengguna tersebut:

--Query executed by the application
SELECT * FROM MyUserData;

Manfaat tampilan berparameter

Parameter membantu Anda mencapai sasaran berikut:

  • Mengisolasi data tenant dalam aplikasi multi-tenant: Gunakan parameter untuk memastikan kueri hanya menampilkan data untuk tenant tertentu.

  • Membatasi kueri AI agentic: Membatasi kueri bahasa alami ke data pengguna atau tenant.

  • Memfilter data dengan kredensial sementara: Membatasi akses data berdasarkan ID pengguna atau tenant yang tidak ada di Identity and Access Management (IAM).

  • Menggunakan kredensial pribadi untuk pemfilteran: Filter data menggunakan nilai yang diperlukan untuk kueri yang tidak boleh ditampilkan kepada pengguna akhir.

Mitigasi risiko keamanan

Tampilan berparameter membantu mengurangi risiko keamanan saat pengguna akhir menjalankan kueri yang tidak tepercaya — seperti kueri bahasa alami — di database Anda. Risiko ini mencakup:

  • Perintah berbahaya: Pengguna mungkin mencoba memanipulasi model yang mendasarinya untuk mengakses semua data aplikasi.
  • Kueri SQL dengan cakupan luas: Model bahasa besar (LLM) dapat menghasilkan kueri SQL yang mengekspos data sensitif, bahkan dari kueri pengguna yang bermaksud baik.

Dengan menggunakan tampilan berparameter, Anda dapat membatasi rentang baris yang ditampilkan kepada setiap pengguna aplikasi, terlepas dari cara pengguna menyusun kueri mereka.

Praktik terbaik

Ikuti praktik berikut untuk menerapkan tampilan berparameter secara efektif.

  • Gabungkan dengan tampilan hak pendefinisi dan FGAC: Gunakan parameter sebagai bagian dari model keamanan komprehensif yang mencakup tampilan hak pendefinisi dan peran kontrol akses terperinci. Beri peran hak istimewa SELECT hanya pada tabel virtual, dan pastikan peran tersebut dan peran sistem public tidak memiliki hak istimewa pada tabel dasar yang mendasarinya.

  • Gunakan JSON untuk konteks yang kompleks: Untuk meneruskan konteks terstruktur, seperti pengguna dengan beberapa peran, serialisasikan data sebagai string JSON. Teruskan string JSON sebagai parameter tunggal. Gunakan JSON atau JSONB bawaan Spanner untuk mengekstrak nilai di dalam tampilan.

  • Sederhanakan akses dengan UDF SQL: Jika Anda sering mengakses kolom dalam konteks JSON terstruktur, buat fungsi SQL yang ditentukan pengguna (UDF) untuk mengenkapsulasi logika ekstraksi. Menggunakan UDF dalam tampilan akan meningkatkan keterbacaan dan kemudahan pemeliharaan.

  • Melindungi dari injeksi perintah dengan Model Armor: Saat membuat kueri menggunakan LLM dengan input pengguna yang tidak tepercaya, gunakan Model Armor untuk mengidentifikasi dan memblokir upaya injeksi perintah dan jailbreak secara proaktif.

Batasan

Tampilan berparameter memiliki batasan berikut:

  • Jenis argumen: Fungsi SECURE_CONTEXT() memerlukan argumen literal string.
  • Jenis hasil: Fungsi SECURE_CONTEXT() menampilkan string.
  • Interaksi fitur Spanner: Anda tidak dapat menggunakan SECURE_CONTEXT() di kolom yang dihasilkan, ekspresi nilai kolom default, atau di dalam fungsi yang ditentukan pengguna (UDF).
  • Penghalang keamanan: Tampilan berparameter di Spanner tidak menyertakan penghalang keamanan. Meskipun semua filter diterapkan sebelum menampilkan hasil kueri, filter tersebut mungkin tidak membatasi data yang diakses selama pemrosesan kueri internal.

Langkah berikutnya