Konsep cache keamanan

Berlaku untuk:SQL ServerAzure SQL DatabaseAzure SQL Managed Instance

Artikel ini menjelaskan bagaimana SQL Server menggunakan cache keamanan untuk memvalidasi hak akses yang dimiliki pengguna terhadap objek yang dapat diamankan.

Tujuan

Mesin Database mengatur kumpulan hierarkis entitas, yang dikenal sebagai securables, yang dapat diamankan dengan izin. Keamanan yang paling menonjol adalah server dan database, tetapi izin juga dapat diatur pada tingkat yang lebih halus. SQL Server mengontrol tindakan prinsipal pada objek yang diamankan dengan memastikan mereka memiliki izin yang sesuai.

Diagram berikut menunjukkan bahwa pengguna, Alice, memiliki login di tingkat server, dan tiga pengguna berbeda yang dipetakan ke login yang sama di setiap database yang berbeda.

Untuk mengoptimalkan proses autentikasi, SQL Server menggunakan cache keamanan.

Tidak ada alur kerja cache

Ketika cache keamanan tidak valid, SQL Server mengikuti alur kerja tanpa cache untuk memvalidasi izin. Bagian ini menjelaskan alur kerja tanpa cache.

Untuk menunjukkan, pertimbangkan kueri berikut:

SELECT t1.Column1,
       t2.Column1
FROM Schema1.Table1 AS t1
     INNER JOIN Schema2.Table2 AS t2
         ON t1.Column1 = t2.Column2;

Saat cache keamanan tidak valid, layanan menyelesaikan langkah-langkah yang dijelaskan dalam alur kerja berikut sebelum menyelesaikan kueri.

Untuk SQL Server, tugas tanpa cache keamanan meliputi:

1. Sambungkan ke instance.
2. Lakukan validasi masuk.
3. Buat token konteks keamanan dan token masuk. Detail token ini dijelaskan di bagian berikutnya.
4. Sambungkan ke database.
5. Buat token pengguna database di dalam database.
6. Periksa keanggotaan peran database. Misalnya, db_datareader, db_datawriter, atau db_owner.
7. Verifikasi izin pengguna pada semua kolom, misalnya, izin pengguna di t1.Column1 dan t2.Column1.
8. Memeriksa izin pengguna pada semua tabel, seperti table1 dan table2, dan izin skema pada Schema1 dan Schema2.
9. Memverifikasi izin database.

SQL Server mengulangi proses untuk setiap peran yang dimiliki pengguna. Setelah semua izin diperoleh, server melakukan pemeriksaan untuk memastikan bahwa pengguna memiliki semua izin yang diperlukan dalam rantai dan tidak ada satu pun penolakan dalam rantai. Setelah pemeriksaan izin selesai, eksekusi kueri dimulai.

Untuk informasi selengkapnya, tinjau Ringkasan algoritma pemeriksaan izin.

Untuk menyederhanakan validasi, SQL Server menggunakan cache keamanan.

Definisi cache keamanan

Cache keamanan menyimpan izin untuk pengguna atau login untuk berbagai objek yang dapat diamankan dalam database atau server. Salah satu manfaatnya adalah mempercepat eksekusi kueri. Sebelum SQL Server menjalankan kueri, SQL Server memeriksa apakah pengguna memiliki izin yang diperlukan untuk keamanan database yang berbeda, seperti izin tingkat skema, izin tingkat tabel, dan izin kolom.

Objek cache keamanan

Untuk membuat alur kerja dijelaskan di bagian sebelumnya lebih cepat, SQL Server menyimpan banyak objek berbeda di dalam cache keamanan. Beberapa objek yang di-cache meliputi:

Tanda	Deskripsi
SecContextToken	Konteks keamanan di level server untuk suatu prinsipal disimpan dalam struktur ini. Ini berisi hashtable token pengguna dan berfungsi sebagai titik awal atau dasar untuk semua cache lainnya. Termasuk referensi ke token masuk, token pengguna, cache audit, dan cache TokenPerm. Selain itu, ini bertindak sebagai token dasar untuk login di tingkat server.
LoginToken	Mirip dengan token konteks keamanan. Berisi detail prinsipal tingkat server. Token masuk mencakup berbagai elemen seperti SID, ID masuk, jenis login, nama login, status isDisabled, dan keanggotaan peran tetap server. Selain itu, ini mencakup peran khusus di tingkat server, seperti sysadmin dan admin keamanan.
UserToken	Struktur ini terkait dengan prinsipal tingkat database. Ini termasuk detail seperti nama pengguna, peran database, SID, bahasa default, skema default, ID, peran, dan nama. Ada satu token pengguna per database untuk login.
TokenPerm	Merekam semua izin untuk objek yang dapat diatur keamanannya untuk UserToken atau SecContextToken.
TokenAudit	Kuncinya adalah kelas dan ID objek yang dapat diamankan. Entri adalah serangkaian daftar yang berisi ID audit untuk setiap operasi yang dapat diaudit pada objek. Audit server didasarkan pada pemeriksaan izin, merinci setiap operasi yang dapat diaudit yang dimiliki pengguna tertentu pada objek tertentu.
TokenAccessResult	Cache ini menyimpan hasil pemeriksaan izin kueri untuk kueri individual, dengan satu entri per paket kueri. Ini adalah cache yang paling penting dan umum digunakan, karena ini adalah hal pertama yang diperiksa selama eksekusi kueri. Untuk mencegah kueri ad hoc membanjiri cache, cache hanya menyimpan hasil pemeriksaan izin kueri jika kueri itu dijalankan tiga kali.
ObjectPerm	Ini mencatat semua izin untuk objek dalam database untuk semua pengguna dalam database. Perbedaan antara TokenPerm dan ObjectPerm adalah bahwa TokenPerm adalah untuk pengguna tertentu, sementara ObjectPerm dapat untuk semua pengguna dalam database.

Cache penyimpanan keamanan

Token disimpan di dalam penyimpanan cache yang berbeda.

Store	Deskripsi
TokenAndPermUserStore	Satu toko besar yang berisi semua objek berikut: - SecContextToken - LoginToken - UserToken - TokenPerm - TokenAudit
SecCtxtACRUserStore	Penyimpanan hasil pemeriksaan akses (ACR). Setiap login memiliki penyimpanan pengguna konteks keamanan terpisah mereka sendiri.
ACRUserStore	Akses penyimpanan hasil pemeriksaan <unique id> - <db id> - <user id> Setiap pengguna memiliki penyimpanan ACR pengguna yang terpisah. Misalnya, dua login dengan lima pengguna dalam dua database yang berbeda berjumlah dua SecCtxtACRUserStore dan 10 berbeda ACRUserStore.
ObjectPerm	Satu per token database ObjPerm . Semua keamanan yang berbeda di dalam database.

Masalah yang diketahui

Bagian ini menjelaskan masalah dengan cache keamanan.

Invalidasi cache keamanan

Berbagai skenario dapat memicu pembatalan cache keamanan di tingkat database atau server. Ketika pembatalan terjadi, semua entri singgahan saat ini tidak valid. Semua kueri dan pemeriksaan izin yang akan datang akan mengikuti alur kerja lengkap "Tidak ada cache" sampai cache terisi kembali. Pembatalan dapat berdampak signifikan pada performa server, terutama di bawah beban tinggi, karena semua koneksi aktif perlu membangun kembali entri yang di-cache. Pembatalan cache berulang dapat membuat dampak ini lebih buruk. Pembatalan dalam master database diperlakukan sebagai pembatalan di seluruh server, yang memengaruhi cache di semua database pada instans.

SQL Server 2025 memperkenalkan fitur yang membatalkan cache hanya untuk login tertentu. Ini berarti bahwa ketika entri cache keamanan tidak valid, hanya entri milik login yang terpengaruh yang terpengaruh. Misalnya, jika Anda memberikan izin masuk L1 baru, token untuk masuk L2 tetap tidak terpengaruh.

Sebagai langkah awal, fitur ini berlaku untuk skenario login CREATE, ALTER, dan DROP, dan perubahan izin untuk login individual. Login grup terus mengalami pembatalan tingkat server.

Tabel di bawah ini mencantumkan semua tindakan Security Data Definition Language (DDL) yang membatalkan cache keamanan.

Tindakan	Subyek	Ruang Lingkup
CREATE/ALTER/DROP	APPLICATION ROLE SYMMETRIC KEY ASYMMETRIC KEY AUTHORIZATION CERTIFICATE ROLE SCHEMA USER	Database yang ditentukan
DROP	Objek apa pun yang muncul di sys.all_objects atau yang dapat diamankan yang tercantum dalam database atau daftar yang dapat diamankan dengan cakupan skema.	Database yang ditentukan
GRANT/DENY/REVOKE	Izin apa punkepada objek yang dapat diamankan yang terdapat dalam database atau skema.	Database yang ditentukan
CREATE/ALTER/DROP	LOGIN Aku akan menemuinya.SERVICEMASTER KEY	instans SQL Server
ALTER	DATABASE	Database yang ditentukan

Performa kueri saat ukuran TokenAndPermUserStore tumbuh

Masalah performa, seperti penggunaan CPU yang tinggi dan peningkatan konsumsi memori, dapat disebabkan oleh entri yang berlebihan dalam cache TokenAndPermUserStore. Secara default, SQL Server hanya membersihkan entri dalam cache ini ketika mendeteksi tekanan memori internal. Namun, di server dengan banyak RAM, tekanan memori internal mungkin tidak sering terjadi. Seiring bertambahnya cache, waktu yang diperlukan untuk mencari entri yang ada untuk menggunakan kembali meningkat. Cache ini dikelola oleh spinlock, memungkinkan hanya satu utas untuk melakukan pencarian pada satu waktu. Akibatnya, perilaku ini dapat menyebabkan penurunan performa kueri dan penggunaan CPU yang lebih tinggi.

Penanganan masalah

SQL Server menyediakan dua bendera pelacakan (TF) yang dapat digunakan untuk mengatur kuota untuk cache TokenAndPermUserStore. Secara default, tidak ada kuota, yang berarti cache dapat menyimpan jumlah entri yang tidak terbatas.

• TF 4618: Membatasi jumlah entri di TokenAndPermUserStore hingga 1024.
• TF 4618 dan TF 4610: Membatasi jumlah entri di TokenAndPermUserStore ke 8192. Jika batas jumlah entri rendah TF 4618 menyebabkan masalah performa lainnya, disarankan untuk menggunakan bendera pelacakan 4610 dan 4618 bersama-sama. Untuk informasi selengkapnya, lihat Mengatur bendera pelacakan dengan DBCC TRACEON.

Untuk informasi selengkapnya, Anda dapat merujuk ke artikel Masalah performa dapat disebabkan oleh entri berlebihan dalam cache TokenAndPermUserStore - SQL Server

Praktik terbaik

Bagian ini mencantumkan praktik terbaik untuk mengoptimalkan alur kerja keamanan.

Manajemen pengguna selama jam nonpeak

Mengingat sifat invalidasi cache keamanan tingkat tinggi (tingkat database/server), lakukan perintah DDL keamanan selama di luar jam kerja ketika beban server rendah. Jika invalidasi cache keamanan terjadi selama beban kerja yang berat, mungkin ada dampak performa yang nyata pada seluruh server karena cache keamanan diisi ulang.

Menggunakan transaksi tunggal untuk modifikasi izin

Melakukan beberapa operasi Data Definition Language (DDL) keamanan dalam transaksi yang sama dapat secara signifikan meningkatkan kemungkinan mengalami kebuntuan dengan koneksi aktif lainnya Untuk mengurangi risiko ini, disarankan untuk menghindari eksekusi beberapa DLL keamanan dalam satu transaksi. Sebagai gantinya, jalankan operasi DDL terkait keamanan dalam transaksi terpisah untuk meminimalkan ketidakcocokan kunci.

Konten terkait

• Mulai menggunakan izin Mesin Database