Mengapa praktik yang buruk memungkinkan semua orang menggunakan login sa?

25

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 salogin secara langsung, alih-alih menggunakan Otentikasi Windows dan mengizinkan 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?

sql-server security

— Jon Seigel
sumber

Saya meminta setengah ini sebagai referensi kanonik karena saya tidak dapat menemukan apa pun melalui Google (jangan ragu untuk mengedit dalam aspek yang tidak saya bahas), dan setengahnya untuk mendapatkan amunisi untuk meyakinkan manajemen bahwa membuat perubahan ini adalah hal yang baik (tm).

— Jon Seigel

6

Ini sama baiknya dengan memberi semua orang salinan kunci rumah Anda. ;)

— Jeremiah Peschka

1

Belum lagi, 'sa' adalah nama login yang dikenal secara publik untuk SQL Server, oleh karena itu menjadikannya target yang mudah. Tidak ada tebakan yang benar-benar terlibat. Saya telah melihat perusahaan mengubah nama dari 'sa' menjadi sesuatu yang berbeda. Bahkan jika hanya level kecil, itu membuat pengganggu cyber sedikit lebih sulit untuk mengetahui sesuatu.

— Thomas Stringer

3

Aplikasi Anda tidak memerlukannya . Tolong beri tahu kami mengapa menurut Anda demikian.

— nvogel

Pertanyaan bagus Jika saja profesional basis data lainnya berhenti dan mengajukan pertanyaan yang sama, akan ada jauh lebih sedikit celah keamanan.

— Thomas Stringer

52

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

"Saya telah membaca bahwa ini adalah praktik terbaik untuk tidak membiarkan pengguna menggunakan login 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 hanyalah satu login otentikasi SQL. Itu adalah nama pengguna administrator default, sama seperti Administrator dalam otentikasi Windows. Ini memiliki kekuatan super lokal pada satu contoh itu, tetapi tidak kekuatan super global di semua contoh.

"... dan mengizinkan hak akun sysadmin (atau grup akun) itu."

Apa pun metode otentikasi yang Anda pilih, idealnya Anda ingin mengikuti prinsip hak istimewa: memberi orang hak minimum yang mereka butuhkan untuk menyelesaikan pekerjaan, 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 kamu tidak akan bisa mengatakan orang mana yang melakukannya.

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

Anda ingin melakukan dua hal:

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

Yang pertama dilakukan dengan prinsip privilege: 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 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 dari izin sehingga tidak ada orang waras yang ingin 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 mesin virtual produksi, atau juga mesin pengembangan internal kami?"

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.

— Brent Ozar
sumber

1

SA pada satu contoh dapat memberikan hak-hak Tuhan pada semua contoh karena server terhubung, ntfs dll

— gbn

@ GBN - Saya tidak yakin saya mengikuti. Bisakah Anda menunjukkan beberapa contohnya? Saya dapat mengerti jika Anda berbicara tentang konfigurasi yang buruk (seperti semua server berbagi akun layanan yang sama) tapi saya tidak jelas tentang bagaimana Anda menyelesaikannya ketika server berjalan di bawah akun layanan yang berbeda.

— Brent Ozar

Bangun standar akan menggunakan akun domain yang sama di organisasi besar. Bahkan jika mereka berbeda, mereka akan menjadi anggota kelompok AD yang sama (tergantung wilayah, tentu saja, mungkin) jadi memiliki hak yang sama. Saya telah melihat keduanya di organisasi besar di seluruh dunia (Bank investasi)

— gbn

9

Oke, itu masalah yang berbeda. Di sebagian besar organisasi aman yang saya lihat, sudah menjadi praktik standar untuk menempatkan setiap server di bawah akun layanannya sendiri. Itu juga bagian dari Daftar Periksa Pengaturan SQL Server saya secara online. Tentu, jika Anda mengabaikan langkah dasar yang jelas itu, maka Anda kurang aman - tetapi apa gunanya?

— Brent Ozar

15

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

Ini akan memberi tahu Anda bahwa TIDAK seorang pun 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 mensyaratkan penggunaan minimum peran sysadmin.

Saya menonaktifkan dan mengganti nama akun "sa", 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 dalam hal itu dan pengembang Anda memiliki hak istimewa lebih tinggi daripada yang Anda butuhkan, saya akan mengaudit heck keluar dari akun mereka. Saya akan menangkap semua dan apapun 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.

— Shawn Melton
sumber

2

+1000 Papan tulis itu sangat bagus. Saya belajar banyak dari hal itu.

— Jon Seigel

8

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 (yaitu akun layanan yang sama) maka sa dalam satu hak memberikan semuanya.

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

Tidak ada sisi buruknya.

— gbn
sumber

Ada adalah terbalik, itu hanya sebanding dengan yang lain: kenyamanan. Sangat mudah bagi semua orang untuk menggunakan sa(mungkin dengan "kata sandi" sebagai kata sandi), itulah mengapa ini terus berlanjut sebagai praktik.

— Jon of All Trades

6

sa = sysadmin

Masuk dengan sa memberi pengguna kemampuan untuk melakukan semua hal berikut: - jatuhkan dan buat basis data - modifikasi objek dalam basis data - 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, akses prosedur tersimpan dan tampilan)

— datagod
sumber

5

Praktik terbaik adalah membuat kata sandi yang kuat dan melupakannya.

— garik
sumber

1

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

aktifkan prosedur sistem xp_cmdshell dan, dengan menggunakan hak istimewa 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 rekening. Seorang pengguna dapat memindai laptop tetangga dari mal tempat Anda minum kopi dan mungkin melihat Anda telah menginstal dan menjalankan SQL contoh dan dapat mencoba bersenang-senang secara gratis. Bukannya itu bisa sering terjadi ... tapi itu kemungkinan :-).
Bagaimana praktik terbaik meningkatkan keamanan contoh 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 mesin virtual produksi, atau mesin virtual 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.

— Marian
sumber

-1 Pertanyaannya telah benar-benar bertanya mengapa lebih menyukai otentikasi Windows Terpadu dan menghindari otentikasi SQL Server sementara itu tidak mungkin dilakukan tetapi TAPI tidak bagaimana atau "mengapa seseorang tidak boleh memiliki akun SA yang lemah"

— Fulproof

@Fulproof: Saya mengerti apa yang Anda katakan dan terima kasih atas umpan baliknya. Interpretasi saya terhadap akun SA yang lemah adalah akun SA dengan kata sandi yang lemah / tidak ada yang digunakan oleh semua orang di perusahaan. Tapi pertanyaannya sudah tua dan saya tidak sepenuhnya mengingat semua detail. Dan saya memiliki aksen pada pertanyaan utama dari judul - Mengapa itu praktik yang buruk untuk memungkinkan semua orang menggunakan login sa?

— Marian

0

Mengatasi pertanyaan terakhir Anda, kami menggunakan akun SA pada 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 SA yang bagus dan solid. 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.

— Richard
sumber

1

Dengan sa, mereka dapat mengaktifkan XP_cmdshell misalnya dan kemudian meminta masuk ke prod. Dan ketika saya menjawab, itu dapat memberi hak pada semua server. Dbo dan sebagian sa (buat db) dll: tidak ada masalah

— gbn

Di lingkungan pengembangan yang tidak menghasilkan atau menyimpan data pelanggan - lingkungan di mana semua salinan dari database adalah salinan uji, murni untuk pengembangan dan penyebaran - Saya tidak bisa melihat ini benar-benar menjadi masalah. Jika ada potensi kode buruk mengenai database produksi, maka ya, saya bisa melihat kapal sedikit lebih ketat.

— Richard

0

Parameter keamanan sistem SQL Server default apa pun 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

— Ivan Stankovic
sumber