Cara menolak akses ke SQL Server ke login tertentu melalui SSMS, tetapi mengizinkan melalui .Net SqlClient Data Provider

Kami memiliki situasi di mana Pengembang tidak memiliki UPDATEizin apa pun , TETAPI mereka bekerja dengan aplikasi dan melihat string koneksi -> mereka tahu kata sandi dari beberapa akun SQL (contoh SQLLogin1) yang memiliki izin UPDATE. Operasi kami saat ini tidak sempurna, dan terkadang data produksi perlu dimodifikasi (belum ada GUI untuk itu).

Alih-alih menghubungi DBA, dan memintanya untuk mengubah data, Pengembang akan (secara tidak benar) menggunakan akun SQL SQLLogin1(yang memiliki izin untuk memodifikasi data), dan terhubung melalui SQL Server Management Studio untuk memodifikasi data sendiri.

DBA tidak dapat mengubah kata sandi untuk SQLLogin1tanpa Pengembang melihat string koneksi baru dan kata sandi baru, karena string koneksi aplikasi yang digunakan SQLLogin1dikelola oleh Pengembang.

Pertanyaan:

Apakah ada cara untuk menolak akses ke SQLLogin1login SQL, tetapi hanya jika terhubung melalui SSMS?

Pada saat yang sama jika SQLLogin1terhubung .Net SqlClient Data Provider( program_namedi sys.dm_exec_sessions), itu harus diizinkan masuk.

Dengan cara ini kami ingin agar Pengembang tidak terhubung menggunakan SSMS SQLLogin1, sementara aplikasi yang menggunakan SQLLogin1, masih dapat terhubung.

Anda dapat menggunakan pemicu masuk server untuk membuat validasi masuk khusus dan menolaknya kapan pun Anda mau. Anda akan melihat pemicu ini tercantum di bawah "Objek Server" dan di dalam "Pemicu" jika Anda menggunakan SSMS.

Sebagai contoh:

CREATE TRIGGER strRejectSSMSConnectionForSQLLogin1
ON ALL SERVER FOR LOGON
AS
BEGIN

    IF ORIGINAL_LOGIN() = N'SQLLogin1' AND PROGRAM_NAME() LIKE N'Microsoft SQL Server Management Studio%'
    BEGIN
        RAISERROR('Direct connection by SSMS refused.', 16, 1)
        ROLLBACK
    END

END

Bagian ROLLBACKdalam pemicu akan menolak koneksi (ada transaksi implisit yang membungkus panggilan ke pemicu pada acara masuk).

Hati-hati saat menerapkan pemicu masuk, jika tidak dikodekan dengan benar, Anda akan menolak masuk yang seharusnya bisa masuk (termasuk milik Anda!). Pastikan untuk menguji pada lingkungan uji / dev terlebih dahulu.

Ingatlah bahwa kode ini dijalankan sebelum sesi dibuat , sehingga tampilan sistem yang mengandalkan id sesi (SPID) tidak akan berisi login yang saat ini diperiksa sampai pemicu berakhir tanpa rollback atau kegagalan yang cukup tinggi.

Saya pikir tidak ada solusi yang dapat diandalkan untuk masalah Anda karena Application Namedapat dimodifikasi parameteragar cam diubah oleh pengguna mana pun.

Berikut ini cara mengubahnya SSMS:

Dalam Connect to Database Objectdialog pilih Opsi, buka Additional Connection Parametersdan pilih nama untuk Application Nameseperti ini:

Sekarang sys.dm_exec_sessionsDMV dan Program_name () akan menunjukkan kepada Anda apa yang Anda berikan dalam string koneksi Anda di Application Nameparameter:

Anda tidak dapat memotong klien tertentu, seperti yang sudah dirinci dalam jawaban lainnya.

Solusinya adalah dengan menghapus hak akses ke sistem produksi dari akun pengembang.

Setiap perubahan harus ditulis dan dba akan menjalankan skrip.

Penempatan dilakukan oleh sysadmin; devs menghasilkan paket yang mereka berikan kepada seseorang dengan hak istimewa yang layak dan devs tidak pernah melihat konfigurasi yang digunakan pada sistem produksi.

Debugging disusun berdasarkan kasus per kasus dengan salinan data produksi dalam lingkungan pementasan sebagai solusi pilihan atau akun sementara dengan hak istimewa terbatas jika diperlukan.

1. Dalam arti ideal, ini adalah masalah proses / kebijakan / manajemen. Bahkan jika seseorang mengetahui kata sandi, jika itu melanggar kebijakan perusahaan untuk siapa pun kecuali DBA untuk terhubung ke Produksi (well, Anda mungkin memiliki tim Release Engineering dan / atau sys admin, dll), dan ada hukuman karena melanggar aturan, maka itu harus memadai (dengan asumsi bahwa aturan tersebut ditegakkan).

2. Mencoba mencegah aplikasi tertentu agar tidak terhubung tidak mungkin. Seperti yang ditunjukkan oleh sepupic , cukup mudah untuk mengubah "nama program". Tetapi bahkan jika pengembang tidak dapat mengetahuinya, ada banyak program lain yang dapat terhubung ke SQL Server. Kebanyakan orang akan memiliki akses ke SQLCMD.exe dan bahkan OSQL.exe yang sudah usang . Pengembang dapat terhubung dari dalam Visual Studio, dan mereka bahkan dapat membuat aplikasi mereka sendiri untuk terhubung melalui ". Penyedia Data SqlClient Net". Oh, dan sekarang kami bahkan memiliki Azure Data Studio. Terlalu banyak.

3. Namun, ini mungkin masih mungkin terjadi jika kita mendekatinya dari arah lain: alih-alih mencegah aplikasi X dari menghubungkan, bagaimana kalau hanya memungkinkan aplikasi Y untuk terhubung? Tentu, kita kembali masuk ke "nama program", dan bahkan "nama host" dapat dipalsukan, TETAPI, saya cukup yakin bahwa Alamat IP klien tidak dapat dipalsukan (setidaknya tidak melalui kata kunci string koneksi). Anda tahu Alamat IP server aplikasi, atau dapat dengan mudah menemukannya dari sys.dm_exec_connectionsDMV (di client_net_addressbidang).

   Dimulai dengan Pemicu Logon yang disarankan oleh EzLo , kita dapat memodifikasi logika yang menentukan apakah koneksi valid atau tidak menjadi sebagai berikut:

   IF (ORIGINAL_LOGIN() = N'SQLLogin1'
       AND (
                CONVERT(VARCHAR(10), CONNECTIONPROPERTY('net_transport')) <> 'TCP'
             OR CONVERT(VARCHAR(10), CONNECTIONPROPERTY('client_net_address')) <> '10.10.10.10'
    -- uncomment below (and comment-out line above) if app uses multiple IP addresses
    --       OR CONVERT(VARCHAR(10), CONNECTIONPROPERTY('client_net_address'))
    --                   NOT IN ( '10.10.10.10', '10.10.10.11', ...)
           ))
   BEGIN
       RAISERROR('Non-application connection refused.', 16, 1);
       ROLLBACK;
   END;
   

   Satu-satunya cara sekarang adalah dengan masuk ke mesin Produksi, atau meminta workstation mereka memprotes IP dari server aplikasi. Semoga para devs tidak memiliki akses untuk masuk ke Produksi. Dan spoofing IP yang ada di jaringan menyebabkan masalah yang dapat mempengaruhi Produksi, sehingga mereka tidak akan mencobanya, kan? Baik?

Saya sebelumnya bekerja untuk perusahaan yang memiliki masalah ini dengan satu pengembang. Dia dipecat, tetapi kami juga menerapkan tabel yang memiliki LoginName dan DiizinkanMesin (Server Aplikasi) melalui Pemicu Login. Ini menyelesaikan masalah kami. Atau mungkin itu karena penembakan.