Apakah menggunakan keamanan terpadu (SSPI) untuk mengakses SQL Server lebih baik untuk aplikasi web?

Saat menyebarkan aplikasi web (.net) ke lingkungan produksi, apakah lebih baik menggunakan keamanan terintegrasi atau apakah itu penting?

Sepertinya saya bahwa jika seorang hacker merusak server web, itu tidak terlalu penting karena mereka dapat dengan mudah meniru mesin.

Pikiran?

Saya akan mengatakan hanya ada dua alasan yang valid untuk menggunakan SQL auth:

1. Anda terkoneksi dari luar domain, auth begitu terintegrasi.
2. Anda menjalankan tolok ukur TPC-C dan setiap siklus diperhitungkan. SQL auth sedikit lebih cepat.

Untuk skenario yang Anda usulkan (host server web sepenuhnya dikompromikan) tidak ada yang dapat melindungi Anda. Peretas dapat melakukan pada server DB minimal semua yang dapat dilakukan server web . Dan saya akan mengatakan bahwa pertahanan mendalam dapat mengajarkan Anda untuk meminimalkan kerugian dalam kasus seperti itu: mengurangi hak DB dari akun yang digunakan oleh server web Anda ke minimum mutlak yang diperlukan dan tidak lebih. Kedua, pastikan jika host server web dikompromikan, ia tidak dapat digunakan untuk meninggikan hak istimewa lebih tinggi dari akun server web (mis. Tidak ada layanan lain pada host WWW yang menggunakan kredensial dengan hak istimewa lebih tinggi pada DB daripada akun WWW). Ini adalah prinsip keamanan dasar dan tidak ada hubungannya dengan skema otentikasi yang digunakan.

Meskipun sql auth vs windows auth tidak memberikan keuntungan yang jelas dalam skenario Anda, ada masalah lain yang perlu dipertimbangkan:

1. Penegakan kebijakan terpusat: Anda memiliki satu tempat untuk mengatur kebijakan kata sandi, termasuk masa pakai dan kedaluwarsa kata sandi, penghentian akun, dll.
2. Kontrol atas peniruan identitas dan pendelegasian kepercayaan. Setelah sql auth digunakan dalam rantai delegasi trust, semua taruhan dimatikan karena itu bukan 'delegasi' nyata dan dengan demikian tidak lagi di bawah batasan kebijakan Anda memberlakukan
3. Audit: sql auth bahkan tidak terlihat oleh LSA Anda sehingga seluruh infrastruktur audit Anda hanya dilewati. Anda perlu menambahkan catatan SQL menghasilkan secara eksplisit tentang peristiwa sql auth, tetapi mencampurkan apel dan jeruk karena peristiwa tersebut memiliki sumber, penyedia, dan skema yang berbeda di log peristiwa

Satu catatan terakhir: protokol TDS memaparkan kata sandi sql auth dalam teks yang jelas atas lalu lintas, tetapi itu biasanya dikurangi dengan meminta enkripsi lalu lintas SSL.

Jadi, mengapa Anda melihat masih sql auth WWW host bahwa toko password jelas dalam web.config? Mereka adalah buruk pengembang / admin, jangan salah satu dari mereka.

msdn.microsoft.com/en-us/library/aa378326(VS.85).aspx

technet.microsoft.com/en-us/library/ms189067.aspx

Jika Anda tidak menggunakan SSPI, Anda mengubah kode nama pengguna dan kata sandi menjadi file sumber.

Jika Anda mengubah kode nama pengguna dan kata sandi menjadi file sumber, semua karyawan Anda memiliki akses ke sana.

Ini relatif tidak aman. Mantan karyawan yang tidak puas dapat menggunakan informasi tersebut dengan jahat. Pengunjung mungkin melihat kode di layar di suatu tempat. Atau kode sumber mungkin tidak sengaja keluar di alam liar.

Keuntungan dari SSPI adalah bahwa kata sandi tidak pernah disimpan di tempat yang jelas.

Jawaban lain sejauh ini bagus, tapi saya akan berikan jawaban lain: manajemen.

Cepat atau lambat, Anda mungkin akan berakhir dengan beberapa SQL Server. Mengelola otentikasi SQL antara aplikasi Anda dan beberapa SQL Server menjadi sedikit menyakitkan, terutama ketika Anda mengalami masalah keamanan. Jika Anda mengubah kata sandi autentikasi Windows satu kali, itu langsung berubah di semua server Anda. Jika Anda perlu memutar kata sandi otentikasi SQL Anda, itu lebih menyakitkan - ke titik di mana Anda mungkin tidak akan melakukannya sama sekali. Itu risiko keamanan.

Saya tidak 100% yakin di sini, tapi saya pikir poin utamanya adalah SQL auth tidak aman, jadi lebih baik menggunakan Windows auth. Bergantung pada bagaimana pengaturan aplikasi Anda, Anda juga dapat menyimpan kredensial yang tepat dalam bentuk terenkripsi pada mesin menggunakan auth Windows. Saya tidak berpikir itu benar-benar mungkin dengan SQL auth. Anda dapat mengaburkannya, tetapi pada akhirnya harus jelas.

Juga, hanya karena seorang peretas dapat masuk ke server tidak berarti itu sudah selesai. Seorang hacker mungkin mendapatkan kendali atas proses yang tidak terjangkau tetapi tidak melakukan hal lain di server. Itulah mengapa penting untuk tidak menjalankan semuanya sebagai administrator atau sistem, tetapi sebagai gantinya menggunakan akun layanan privilege minimum.

Hal terbaik untuk dilakukan adalah membatasi apa yang dapat mereka lakukan Jika / Ketika mereka membobol server web. Itu berarti hanya memberikan hak SQL yang diperlukan agar aplikasi berfungsi. Ini jauh lebih mudah untuk memberikan hak aplikasi DBO, tetapi itu membuat DB jauh lebih rentan jika terjadi serangan yang sukses pada server web.

Saya akan mengawali semua ini dengan mengatakan saya membuat asumsi bahwa Anda berbicara tentang server web internal di jaringan pribadi internal.

Mari kita mulai dengan meniru mesin. Jika identitas kumpulan aplikasi adalah Layanan Jaringan dan tidak ada peniruan dalam aplikasi .NET, maka ya, aplikasi web akan terhubung ke SQL Server back-end menggunakan akun komputer mesin. Dan itu berarti Anda telah memberikan akses ke akun mesin kata. Microsoft CRM bekerja dengan cara ini.

Namun, jika Anda telah menentukan identitas, akun pengguna itu akan memerlukan akses ke SQL Server. Meskipun Anda benar bahwa jika penyerang merusak server web, mereka secara efektif memiliki akses yang sama dengan akun identitas, kebenarannya adalah bahwa menggunakan log masuk SQL Server tidak mengubah apa pun di sini. Setelah saya memiliki akses, saya dapat memodifikasi aplikasi web untuk melakukan apa yang saya inginkan dan akan, semaksimal mungkin izin keamanan Anda pada SQL Server back-end.

Sekarang mengapa menggunakan SSPI. Pertama dan terpenting, Anda tidak menggunakan login berbasis SQL Server. Itu berarti Active Directory adalah satu-satunya sumber keamanan. Itu berarti Anda memiliki sarana audit normal untuk menentukan akses tidak valid. Kedua, ini berarti bahwa kecuali ada aplikasi lain yang memerlukannya, Anda dapat meninggalkan SQL Server dalam mode autentikasi Windows saja. Itu berarti tidak ada login SQL Server yang diizinkan. Itu berarti setiap serangan terhadap sa dihentikan bahkan sebelum mereka mulai. Dan akhirnya, itu membuat pemulihan lebih mudah. Jika Anda menggunakan login berbasis SQL Server, Anda harus mengekstrak login dengan SID dan kata sandi terenkripsi. Jika Anda menggunakan akun pengguna berbasis Windows sebagai "akun layanan," ketika Anda pergi ke SQL Server baru, dengan membuat login,

Pertanyaannya adalah mana yang "lebih baik"? Yang sulit dijawab karena bergantung pada konteks, nilai-nilai dan prioritas si penanya.

Secara pribadi, saya suka SQL auth.

• AD adalah hal lain untuk dijalankan dan mendukung serta mengelola akun layanan.
• AD harus tersedia di lingkungan hosting Anda.
• AD akan membuatnya sulit untuk pindah ke cloud atau cloud hybrid.
• AD memudahkan menambahkan akun layanan ke dalam grup yang tidak boleh mereka masuki oleh admin di beberapa bagian lain dari organisasi Anda.
• SSPI tidak mem-bypass masalah mengenkripsi string koneksi Anda karena Anda harus mengenkripsi nama host SQL Anda dalam konfigurasi.
• SQL auth sederhana dan hanya konfigurasi teks, mudah digunakan.
• Mengatur identitas Pool App adalah hal lain untuk diotomatisasi dan kemudian menyembunyikan nama pengguna dan kata sandi dalam skrip otomatisasi untuk setiap lingkungan.
• Menggunakan dua string koneksi, membuatnya mudah untuk menggunakan kata sandi bergulir, sehingga Anda dapat memperbarui kata sandi tanpa downtime.

Poin terakhir: Anda mengkode kelas manajer koneksi Anda untuk mencoba setiap string koneksi, dengan cara itu Anda dapat mengubah kata sandi pada konfigurasi pertama, mendorong perubahan keluar, dan itu akan gagal pada koneksi kedua, kemudian Anda memperbarui kata sandi pada MSQL dan yang pertama akan digunakan lagi. Perubahan konfigurasi akhir diperlukan untuk mengatur kata sandi kedua sama dengan kata sandi pertama, siap untuk waktu berikutnya.

Jika pengguna tidak akan memanipulasi database secara langsung (melalui alat klien lain seperti SQL Server Management Studio) maka saya biasanya hanya akan membuat satu login SQL untuk aplikasi dan memberikannya akses yang dibutuhkan. Pada saat itu pengguna dibatasi dalam apa yang dapat mereka lakukan sebagaimana diizinkan oleh antarmuka aplikasi web.