DBA adalah penjaga data, dan ada dua aspek menjadi penjaga. Yang pertama adalah integritas. Ini mencakup tugas-tugas seperti memeriksa konsistensi basis data, membuat cadangan, dan, jika ada masalah, memiliki rencana pemulihan basis data yang dirancang dengan baik dan komprehensif.
Aspek kedua adalah keamanan. Ini menyarankan untuk memastikan bahwa hanya pengguna yang berwenang yang memiliki akses ke data, dan hanya ke data yang mereka butuhkan.
Anda dapat menemukan banyak sumber daya yang didedikasikan untuk keamanan di Web. Padahal, saya pikir beberapa hal penting kurang mendapat perhatian yang tepat. Dalam artikel ini, saya ingin berfokus pada opsi ini dan menunjukkan mengapa penting untuk menyadarinya dan menanganinya dengan benar.
Misi untuk Mengkompromikan SQL Server
Mari kita bermain Role-Playing Game di mana Anda adalah Agen Rahasia, dan misi Anda, jika Anda menerimanya, adalah untuk mencuri Data Sangat Penting dari TargetDB database yang dihosting oleh SQL Server. Anda perlu mendapatkan data ini dan menghapusnya.
Dimungkinkan untuk mendapatkan Login untuk Anda, tetapi setiap login di server memiliki izin DITOLAK eksplisit pada database dan data target. Satu-satunya informasi yang dapat diberikan agen kami kepada Anda adalah informasi yang dibuat untuk verifikasi oleh protokol keamanan selama pembuatan login Anda.
Informasi basis data dari server target.
Izin server:
Izin basis data:
Sebagai setiap agen yang baik, mari lakukan pekerjaan rumah dan periksa apa yang Anda hadapi.
Anda tidak bisa begitu saja masuk dan terhubung ke TargetDB , karena setiap izin ditolak untuk login Anda, dan pengguna yang dipetakan secara eksplisit. Anda harus masuk dari database lain.
Pintu Terkunci
Tindakan lintas basis data bukanlah hal yang mudah untuk dilakukan. Anggap saja sebagai pintu tertutup dengan dua kunci di atasnya. Kami tidak akan fokus pada detail teknis di sini, tetapi Anda dapat merujuk ke Memperluas Peniruan Identitas Basis Data dengan Menggunakan artikel EXECUTE AS MSDN (saya sangat menyarankan untuk melakukannya).
Kunci pertama adalah Mempercayai pengautentikasi , dan yang kedua adalah Mempercayai database .
Mari kita mulai dengan kunci pertama. Mempercayai autentikator berarti bahwa untuk mengakses database B lain, pemilik database A harus diberikan (secara eksplisit atau implisit) AUTHENTICATE izin di database B.
Tunggu sebentar! Pengautentikasi pada tingkat basis data adalah pemilik basis data itu sendiri (Jangan mencampuradukkannya dengan db_owner peran basis data!).
Periksa pemilik database:
Meskipun mereka mengikuti praktik yang cukup baik dengan menggunakan satu akun per server, yang bukan SA , dengan cara ini mereka dengan baik hati membuka kunci pertama untuk Anda.
Mari kita fokus pada kunci kedua.
Entah bagaimana, Anda harus memiliki database yang dibuat di server dengan TERPERCAYA properti AKTIF . Praktik terbaik di sini adalah menyetel properti database TERPERCAYA ke MATI .
Inilah saatnya kita harus mengatakan:bagaimana jika Anda sudah memiliki database seperti itu?
Ini adalah database MSDB.
Kunci kedua selesai. Anda bahkan tidak perlu membuka kunci apa pun.
Pentingnya peran db_owner
Saat ini, Anda harus menghadapi satu tantangan. Entah bagaimana, Anda harus masuk ke database MSDB dengan db_owner peran basis data karena memiliki izin implisit yang meniru identitas.
Karena MSDB biasanya tidak menjadi fokus administrator database, misi ini bukan tidak mungkin lagi. Mari kita lihat apa yang dapat Anda lakukan hanya karena Anda mendapatkan pengguna dengan db_owner peran database dalam database MSDB:
Coba sambungkan ke TargetDB :
Ini adalah kesalahan yang diharapkan. Ingat protokol keamanan yang diterapkan pada login yang disediakan. Mari kita mulai.
Coba sambungkan ke TargetDB dan untuk memilih data target:
Berhasil! Mari kita ubah dan setelah itu verifikasi tindakan.
Itu saja.
Misi tercapai.
Seperti yang Anda lihat, saya berfokus pada kombinasi konfigurasi database keamanan tertentu. Mereka adalah pemilik database dan TERPERCAYA pilihan database memberikan perhatian khusus pada MSDB. Skenario yang disajikan hanyalah satu di mana data sensitif dapat dikompromikan dengan cara yang sama. Mari kita tinjau kemungkinan skenario lain sekarang.
Pemilik basis data + TERPERCAYA
Mari kita periksa detail latar belakang dimulai dengan masalah yang terkenal:kepemilikan basis data. Detail login apa yang harus digunakan oleh pemilik database Anda? Banyak orang mengatakan bahwa SA adalah pilihan yang tepat.
Saya melakukan pencarian Google cepat dan menemukan jawaban seperti berikut:
“Saya tidak ingat ini menjadi perhatian saya. Selain terlihat mengganggu dalam laporan, atau tidak dapat menghapus pengguna jika mereka memiliki database, tetapi menurut saya itu tidak memengaruhi operasi server. Anda cukup memilih sa untuk konsistensi.”
Atau
“Saya tidak berpikir untuk memiliki database oleh SA atau pengguna lain apa pun yang harus menjadi perhatian. Yang penting adalah siapa yang melakukan 'apa' di database Anda. Jadi, merupakan ide bagus untuk membuat pengguna dengan hak istimewa yang valid. Untuk mempermudah, Anda dapat menentukan pemiliknya sebagai SA.”
Situasi saat ini adalah menggunakan akun SA sebagai pemilik database adalah praktik TERBURUK . Menurut saya pribadi, ini harus disorot di setiap blog dan di setiap dokumentasi, yang terkait dengan topik ini.
Jika kami membuat pengguna hanya dengan hak istimewa yang valid, itu sudah cukup, tetapi sayangnya, ini bukan cara kerja biasanya. Anda perlu bersiap untuk skenario 'kemungkinan terburuk'. Coba pikirkan, apa yang bisa kita lakukan dalam contoh sebelumnya jika pemilik database default adalah SA !
Mari kita lanjutkan dengan opsi kedua, TERPERCAYA pilihan basis data. Situasinya sedikit lebih baik tetapi masih memiliki masalah umum. Seperti yang biasa dipertimbangkan, praktik terbaik di sini adalah Menyetel Properti Database 'Terpercaya' ke Nonaktif . Kami baru saja melihat mengapa opsi ini buruk .
Tapi ini bukan segalanya. Jika Anda mencoba menemukan beberapa skrip untuk memeriksa properti ini, Anda mungkin akan menemukan skrip yang mirip dengan ini:
SELECT name FROM sys.databases WHERE is_trustworthy_on = 1 AND name != 'msdb' sp_Blitz skrip yang memeriksa kesehatan SQL Server juga memeriksa pengaturan default database (termasuk TRUSTWORTHY sebagai nilai default 0) dan melaporkan setiap database yang memiliki pengaturan non-default. Namun, skrip melewati database sistem.
Selanjutnya, ada artikel MS KB, yang berfokus pada topik ini. Lihat panduan untuk menggunakan pengaturan database TERPERCAYA di SQL Server:
Ada contoh kode dalam artikel, yang mencantumkan database yang memiliki bit TRUSTWORTHY ON, dan pemilik database yang memiliki peran server sysadmin:
SELECT SUSER_SNAME(owner_sid) AS DBOWNER, d.name AS DATABASENAME
FROM sys.server_principals r
INNER JOIN sys.server_role_members m ON r.principal_id = m.role_principal_id
INNER JOIN sys.server_principals p ON
p.principal_id = m.member_principal_id
inner join sys.databases d on suser_sname(d.owner_sid) = p.name
WHERE is_trustworthy_on = 1 AND d.name NOT IN ('MSDB') and r.type = 'R' and r.name = N'sysadmin'
Apa yang umum dalam skrip ini? Setiap skrip mengecualikan MSDB, tetapi sebagai catatan artikel MS KB, Anda baru saja melihatnya di "misi" kami:
Catatan :Secara default, pengaturan TRUSTWORTHY diatur ke ON untuk database MSDB. Mengubah pengaturan ini dari nilai defaultnya dapat mengakibatkan perilaku tak terduga oleh komponen SQL Server yang menggunakan database MSDB.
Saya ingin menekankan bahwa fokus utama dari bagian ini bukanlah opsi basis data yang TERPERCAYA atau properti pemilik basis data itu sendiri, tetapi kombinasi dari dua opsi ini. Saya sebagian besar berkonsentrasi pada MSDB karena pengaturan TRUSTWORTHY diatur ke ON untuk database MSDB secara default.
Kesimpulan
Itu saja untuk saat ini. Kami memeriksa dan memeriksa skenario praktis yang terkait dengan keamanan SQL Server. Kami juga meninjau opsi basis data yang penting, sebagai pemilik basis data dan pengaturan basis data TERPERCAYA.
Saya hanya ingin menyoroti opsi-opsi ini sejak – karena mereka sangat penting, terutama ketika kita membicarakannya secara bersamaan.
