it-swarm.asia

Mengapa praktik yang buruk memungkinkan semua orang menggunakan login sa?

Bahkan Microsoft mencegah penggunaan mode otentikasi SQL Server , tetapi aplikasi kami memerlukannya.

Saya telah membaca bahwa ini adalah praktik terbaik untuk tidak membiarkan pengguna menggunakan login sa secara langsung, sebagai gantinya menggunakan Otentikasi Windows dan memungkinkan hak akun sysadmin (atau grup akun) tersebut.

  • Bukankah itu pada dasarnya hal yang sama? Apa kelebihan/kekurangannya?
  • Bagaimana praktik terbaik meningkatkan keamanan contoh SQL Server saya?
  • Apakah ini hanya berlaku untuk mesin virtual produksi, atau mesin virtual pengembangan internal kami juga?
25
Jon Seigel

Anda memiliki beberapa pertanyaan berbeda di sini, jadi saya akan menjatuhkan mereka secara individual:

"Saya pernah membaca bahwa ini adalah praktik terbaik untuk tidak membiarkan pengguna menggunakan login sa secara langsung, alih-alih menggunakan Otentikasi Windows"

Anda mencampur dua hal di sini: konsep SA, dan konsep otentikasi SQL dan otentikasi Windows.

Otentikasi SQL adalah daftar nama pengguna dan kata sandi yang disimpan di setiap dan setiap SQL Server. Fakta bahwa itu disimpan dalam SQL adalah masalah pertama. Jika Anda perlu mengubah kata sandi login, Anda harus mengubahnya di setiap server (atau memelihara kata sandi yang berbeda di server yang berbeda). Dengan otentikasi Windows, Anda dapat menonaktifkan login secara terpusat, mengubah kata sandi, mengatur kebijakan, dll.

Jika Anda memilih untuk menggunakan otentikasi SQL, maka SA hanya satu login otentikasi SQL. Ini adalah nama pengguna administrator default, sama seperti Administrator dalam otentikasi Windows. Ia memiliki kekuatan super lokal pada satu contoh itu, tetapi bukan kekuatan super global di semua contoh.

"... dan mengizinkan akun tersebut (atau grup akun) hak istimewa sysadmin."

Apa pun metode otentikasi yang Anda pilih, idealnya Anda ingin mengikuti prinsip hak istimewa: memberi orang hak minimum yang mereka butuhkan untuk menyelesaikan pekerjaan mereka, dan tidak lebih.

Jangan menganggap mereka hanya sebagai login - mereka adalah orang-orang yang dapat membuat Anda dipecat. Jika mereka menjatuhkan database atau menonaktifkan pekerjaan cadangan Anda secara tidak sengaja, mereka tidak akan dipecat, karena secara default, SQL tidak melacak siapa yang melakukan apa. Kaulah yang akan dipecat karena itu akan terjadi, dan kau tidak akan bisa mengatakan orang mana yang melakukannya.

"Bagaimana praktik terbaik meningkatkan keamanan instance SQL Server saya?"

Anda ingin melakukan dua hal:

  1. Hentikan orang dari memecahkan server
  2. Ketika mereka memecahkan server, dapat mengidentifikasi dengan tepat siapa yang melakukannya

Yang pertama dilakukan dengan prinsip privilege paling rendah: memberi orang hanya izin yang mereka butuhkan, dan tidak lebih.

Yang kedua dilakukan dengan memberikan masing-masing orang login mereka sendiri, tidak mengizinkan login bersama (seperti membiarkan semua orang menggunakan nama pengguna/kata sandi yang sama), dan idealnya, mengaudit login. Anda mungkin tidak akan langsung melakukan bagian terakhir itu, karena ini agak menyakitkan, tetapi mari kita letakkan potongan-potongan itu di tempat pertama sehingga Anda dapat menambahkan audit nanti setelah seseorang menjatuhkan database dan atasan Anda ingin tahu mengapa.

Saya tahu apa yang Anda pikirkan: "Tapi kami sedang mengkode aplikasi, dan aplikasi itu perlu login." Ya, berikan aplikasi loginnya sendiri, dan pengembang perlu tahu kata sandi itu, tetapi login itu harus dilucuti sehingga tidak ada orang waras yang mau menggunakannya. Sebagai contoh, itu mungkin harus di peran db_datareader dan db_datawriter saja, tidak ada yang lain. Dengan begitu ia dapat menyisipkan, memperbarui, menghapus, dan memilih data, tetapi tidak harus mengubah skema, menambah indeks, mengubah prosedur tersimpan, dll.

"Apakah ini hanya berlaku untuk instans produksi, atau instans pengembangan internal kami juga?"

Saya pikir itu berlaku sama banyak untuk contoh pengembangan karena saya biasanya khawatir orang melanggar hal-hal. Orang-orang suka memecahkan server dalam pengembangan. Dan tentu saja, ketika saatnya untuk menggabungkan daftar perubahan untuk bermigrasi ke produksi, saya perlu tahu apakah indeks tertentu benar-benar penting untuk aplikasi atau apakah beberapa orang bodoh hanya menjalankan Penasihat Penyesuaian Database dan menyuruhnya untuk menerapkan semua perubahan . Izin yang tepat membantu mengurangi rasa sakit itu.

52
Brent Ozar

Sebenarnya jika Anda membaca whitepaper ini: Pemisahan Tugas SQL Server Whitepaper

Ini akan memberi tahu Anda bahwa NO ONE harus menggunakan hak istimewa sysadmin di akun mereka. Akun akses harian Anda harus diberikan akses minimum, bukan hak sysadmin eksplisit. Memberi mereka CONTROL SERVER sebenarnya dekat dengan apa sysadmin dan kemudian memungkinkan Anda untuk tetap MENYANGKAL/REVOKE akses di mana mereka tidak membutuhkannya. Mengizinkan hak sysadmin kepada siapa pun menjadi masalah jika Anda diharuskan memenuhi standar kepatuhan TI apa pun. Sebagian besar standar memerlukan penggunaan minimum peran sysadmin.

Saya menonaktifkan dan mengubah nama akun "sa", sama seperti yang Anda lakukan dengan akun administrator bawaan pada OS. Hanya untuk digunakan dalam keadaan darurat.

Pengembang biasanya diberikan akses penuh ke lingkungan pengembangan mereka. Kemudian ketika program mereka dipindahkan ke instance pra-produksi, akses mereka harus minimum atau tidak sama sekali; sama seperti itu akan di produksi. Itu adalah dunia yang sempurna. Namun jika Anda tidak berada di sana dan pengembang Anda memiliki hak istimewa lebih tinggi daripada yang Anda butuhkan, saya akan mengaudit heck keluar dari akun mereka. Saya akan menangkap segala sesuatu dan apa pun yang mereka lakukan sampai batas tertentu. Jadi jika terjadi kesalahan ketika mereka berada di server produksi Anda, Anda dapat kembali dan mencari tahu apa yang mereka lakukan.

15
user507

Jika Anda tunduk pada kontrol atau standar regulasi eksternal (SOX, PCI dll), maka Anda

  • akan gagal audit
  • gagal pada pemeriksaan PCI bulanan Anda

Pengembang harus memiliki db_owner di jaringan SQL Server hanya untuk pengembangan.

Jika SQL Server Anda semuanya ada di jaringan dengan build standar (mis. Akun layanan yang sama), maka sa dalam satu memberikan hak atas semuanya.

Jika akun layanan adalah admin lokal, maka pengembang Anda memiliki kontrol penuh atas server juga.

Tidak ada sisi buruknya.

8
gbn

sa = sysadmin

Masuk dengan sa memberi pengguna kemampuan untuk melakukan semua hal berikut: - jatuhkan dan buat basis data - modifikasi objek dalam database - jatuhkan dan buat info masuk - ubah kata sandi - hapus semua data

Memberi hak istimewa sysadmin akun windows menyelesaikan hal yang sama.

Daftar berjalan, tetapi ini akan memberi Anda beberapa alasan bagus untuk TIDAK PERNAH PERNAH membiarkan non-admin menggunakan sa.

Anda harus membuat akun windows atau SQL dengan hak minimum minimal yang diperlukan untuk membuat aplikasi berfungsi. (mis. login, mengakses prosedur dan tampilan yang tersimpan)

6
datagod

Praktik terbaik adalah membuat kata sandi yang kuat dan melupakannya.

5
garik

Saya memiliki dua opsi dalam pikiran saya saat ini, mengapa seseorang tidak boleh memiliki akun lemah SA. Jika Anda memiliki kata sandi yang lemah/kosong untuk SA = satu orang jahat (menerjemahkannya ke 'teman dekat') dapat:

  • aktifkan prosedur sistem xp_cmdshell dan, dengan menggunakan hak istimewa dari akun layanan Sql Server, lakukan kerusakan pada kotak lokal Anda (buat/hapus file ..). Memiliki keamanan yang rendah untuk SA tidak benar-benar mengatakan banyak tentang pengaturan instance, tetapi dapat menyiratkan bahwa pengguna layanan dapat mengikuti praktik buruk (seperti menjadi admin :-));

  • aktifkan surat pada contoh Anda dan cepatkan script menyenangkan spam kecil (yang kemungkinan akan menyebabkan Anda beberapa masalah baik dengan penyedia internet Anda atau dengan kolega Anda .. tergantung di mana surat pergi ;-));

Saya tidak akan menunjukkan fakta yang jelas bahwa ia dapat menjatuhkan basis data, login ... dll.

  • Bukankah itu pada dasarnya hal yang sama? Apa kelebihan/kekurangannya?
  • Tidak harus: misalnya - pada contoh SQL Server dari laptop Anda perbedaan antara otentikasi Windows dan otentikasi SQL berarti bahwa, secara teori, penyerang eksternal hanya dapat menggunakan akun SQL, karena otentikasi windows tidak dapat digunakan di luar domain Anda sendiri Akun. Seorang pengguna dapat memindai laptop tetangga dari mal tempat Anda minum kopi dan mungkin melihat Anda memiliki instance SQL yang diinstal dan dimulai dan dapat mencoba bersenang-senang secara gratis. Bukannya itu bisa sering terjadi ... tapi itu kemungkinan :-).

  • Bagaimana praktik terbaik meningkatkan keamanan instance SQL Server saya?

  • Karena setiap praktik terbaik di dunia ini melakukan tugasnya..menurunkan peluang penurunan yang mungkin terjadi (misalnya: praktik terbaik dalam melakukan aktivitas fisik akan mengurangi peluang Anda menjadi seperti saya .. kentang sofa) yang dapat terjadi sebaliknya.

  • Apakah ini hanya berlaku untuk instans produksi, atau instans pengembangan internal kami juga?

  • Katakanlah saya menyarankan untuk menerapkan praktik terbaik keamanan (diuji dan dimodifikasi untuk kebutuhan lingkungan Anda) setidaknya dalam produksi. Tetapi jika dalam pengembangan Anda juga menggunakan data produksi (sensitif..etc) selain itu merupakan indikasi kuat bahwa Anda juga harus mengubah praktik pengembangan Anda.
1
Marian

Menjawab pertanyaan terakhir Anda, kami menggunakan SA akun di semua basis data pengembangan kami (dengan kata sandi "sa", pada saat itu!)

Namun, penting untuk dicatat bahwa kami tidak menyimpan data dan kami tidak menghasilkan data. Basis data kami hanya digunakan untuk datastore untuk aplikasi C/C++. Basis data pengembangan ini murni berisi data uji dan sering dibuat, dijatuhkan, dimodifikasi, dll. \

Juga, sama pentingnya, semua database pengembangan diinstal pada mesin pengembangan. (Setidaknya satu salinan per pengembang!) Jadi, jika seseorang mengacaukan seluruh instalasi, mereka hanya akan mengacaukan diri mereka sendiri, dan tidak ada orang lain.

Ketika datang ke lingkungan di mana Anda ingin memastikan bahwa database, tabel, dan data Anda benar-benar konsisten dan aman, maka Anda menginginkan kata sandi yang bagus, padat SA. Jika Anda membiarkan ini lemah, maka siapa pun dan semua orang memiliki akses penuh ke data Anda dan dapat sepenuhnya menghancurkan database Anda.

Untuk sekelompok pengembang dengan salinan database mereka sendiri yang murni berisi data uji, saya masih belum menemukan argumen yang kuat untuk mempertahankan akun SA yang kuat.

0
Richard

Parameter keamanan sistem SQL Server default yang disediakan harus diubah. Dianjurkan untuk tidak menggunakan mode campuran (mengaktifkan otentikasi Windows dan SQL Server) untuk otentikasi. Alih-alih, beralihlah ke otentikasi Windows saja - yang akan menegakkan kebijakan kata sandi Windows - memeriksa panjang kata sandi, durasi hidup, dan riwayat. Fitur kebijakan kata sandi Windows yang membuatnya berbeda dari otentikasi SQL Server adalah penguncian login - setelah sejumlah upaya login yang gagal berturut-turut, login menjadi terkunci dan tidak dapat digunakan lagi untuk penggunaan lebih lanjut

Di sisi lain, otentikasi SQL Server tidak menyediakan metode untuk mendeteksi upaya serangan brute-force, dan yang lebih buruk, SQL Server bahkan dioptimalkan untuk menangani sejumlah besar upaya login cepat. Jadi, jika otentikasi SQL Server adalah suatu keharusan dalam sistem SQL Server tertentu, sangat disarankan untuk menonaktifkan login SA

0
Ivan Stankovic