Memberikan hak istimewa SA untuk Pengembang pada kotak pengembangan

8

Terlepas dari protes keras kami, manajemen kami telah memutuskan bahwa tim pengembangan harus diberi hak 'sa' di server pengembangan. Tangkapannya adalah bahwa kita, kelompok pendukung DB masih bertanggung jawab untuk memelihara kotak ini.

Kami sekarang telah dipercayakan tugas untuk membuat daftar Dos dan Larangan untuk tim pengembangan dengan hak istimewa yang ditingkatkan ini.

Silakan tambahkan ke daftar ini:

DO - membatasi aktivitas pada DB yang sedang dikembangkan

TIDAK --

  • ubah pengaturan instance SQL apa pun
  • sp_configure (termasuk cmdshell)
  • tambah / ubah / hapus semua pengaturan keamanan
  • tambah / ubah / hapus objek basis data
  • tambah / ubah / hapus objek server seperti perangkat cadangan dan server terkait
  • tambah / ubah / hapus replikasi
  • tambah / ubah / hapus paket perawatan
  • sentuh basis data apa pun yang bukan milik tim Anda

Setiap petunjuk ke alat yang tersedia untuk melacak aktivitas pengguna ini akan sangat dihargai.

sql-server  sql-server-2005  permissions 
— Raj
sumber
1
Tugas apa yang perlu mereka lakukan yang membutuhkan tingkat SA yang lebih tinggi?
Saya akan berpikir bahwa db_owner akan semua yang mereka butuhkan ...
5
OK, jika mereka disarankan untuk TIDAK "menambah / mengubah / menghapus objek database", apa yang harus mereka lakukan? Bukankah inti dari memiliki kotak pengembangan adalah mereka dapat memecahkannya?
— Stuart Ainsworth
Ini adalah pengembang aplikasi. Mereka membutuhkan hak 'sa' untuk dapat men-debug prosedur yang tersimpan di Dev Studio. Keputusan sudah dibuat oleh manajemen dan mereka tidak mau mengalah. Kami mencoba untuk meminimalkan potensi sakit kepala
2
+1 untuk pertanyaan, karena saya telah menemukan masalah itu beberapa kali. Solusi lain: Berikan devs VM berpasir dengan SQL di atasnya bahwa mereka 100% bos. Mereka juga 100% bertanggung jawab untuk membuatnya tetap hidup :) -> sungguh menakjubkan betapa cepatnya DEV belajar untuk tidak merusak sistem mereka sendiri :)
— Martin S. Stoller

Jawaban:

8

Jika belum terlambat, satu opsi kompromi yang menurut saya berfungsi dengan baik alih-alih memutakhirkan izin atau mengganti akun pengembang yang ada, buat akun terpisah yang hanya digunakan saat mereka membutuhkan izin tinggi.

Jadi biasanya mereka bekerja di bawah akun "terbatas" individu (yang saya gunakan secara longgar karena akun terbatas ini masih memerlukan beberapa izin yang lumayan - yaitu membuat, menjatuhkan, mengubah tabel). Tetapi untuk kesempatan langka ketika mereka merasa perlu sa, mereka dapat masuk menggunakan akun ini. Kemudian Anda dapat menandai akun di log Anda dan melakukan pemantauan ekstra. Anda telah memberi para pengembang akses yang mereka minta, tetapi dengan cara yang sedikit lebih terkendali.

Akhirnya, jika ada penyalahgunaan, log pada akun ini dapat digunakan sebagai bukti untuk membawanya pergi.

— Joel Coehoorn
sumber
6

Dikatakan di sini (MSDN) Anda perlu sysadmin (sa) untuk debug pada SQL Server 2005.

Namun, pertanyaan SO ini menunjukkan cara lain tanpa sa, yang saya pikir awalnya. Cukup izinkan mereka untuk berjalansp_sidedebug

Saya juga menyarankan memberi mereka SQL Express lokal yang juga memecahkan masalah lain ...

(diedit dengan info lebih lanjut)

Edit, setelah jawaban W. Craig Trader

Masalah lain dengan hak "sa", dalam kasus terburuk:

  • pengembang akan membuat majelis CLR yang tidak terpercaya
  • mereka akan menggunakan xp_cmdshell
  • semua tindakan dalam konteks akun layanan server sql
  • mereka akan menganggap hak sa untuk koneksi klien
  • dll

misalnya xp_cmdshell 'scm -Action 6 -Server PRODSERVER'

— gbn
sumber
1
Jawaban untuk pengembang yang kode di luar garis adalah untuk melakukan integrasi terus menerus dengan dikunci 'seperti yang akan dijalankan oleh izin pengguna, dan gagal membangun sesuai. Minta server build untuk membuat ulang basis data dari awal dan mengisinya dengan data uji (tentu saja semua dari SCM). (Dalam kasus saya, saya menggunakan kode yang persis sama dengan yang akan digunakan oleh penginstal aplikasi untuk membuat database baru, sehingga menguji penginstal serta aplikasi.)
1
@Craig trader: tidak akan berfungsi. Untuk mengulangi jawaban lama saya, pengembang tidak dapat dipercaya dan integratiointegrn tidak akan mendeteksi semua kasus. Saya seorang pengembang dba: monyet kode klien adalah musuh saya. Di perusahaan saya, saya menang .... itu kereta saya dan saya berurusan dengan penyebut umum terendah ...
— gbn
Rupanya, Mileage Anda Mungkin Bervariasi. Dalam pengalaman saya, saya biasanya harus melakukan sedikit pelatihan / orientasi untuk menjelaskan bagaimana dan mengapa hal-hal dilakukan, tetapi setelah itu hal-hal biasanya berjalan cukup baik. Tentu saja, saya selalu bersikeras bahwa satu-satunya build yang melampaui pengembangan adalah mereka yang berasal dari server build yang dikontrol ketat - jika kode tidak membangun di sana, itu masalah dengan kode Anda (atau tes Anda) bukan konfigurasi. Saya telah melakukan ini dengan tim kecil dan proyek besar, di banyak perusahaan, dan selalu berhasil.
4

Saran yang saya miliki adalah mengatur Manajemen Berbasis Kebijakan dan menegakkan semua 'lakukan' Anda dan 'jangan' sebagai aturan kebijakan. Ini akan sangat melindungi instansinya.

Saya juga akan menggunakan audit perubahan DDL, lihat Mengaudit di SQL Server 2008 , bukan sebagai pencegah, tetapi sebagian besar sebagai sistem pelacakan perubahan sehingga ketika ada sesuatu yang kacau, setidaknya Anda akan tahu apa yang berubah.

— Remus Rusanu
sumber
3

Jika itu server DEVELOPMENT, apa masalah dengan DEVELOPERS untuk dapat memiliki akses penuh? Memberi tahu pengembang bahwa Anda tidak dapat menambah / menghapus / mengubah objek basis data (misalnya: tabel, kolom, indeks) seperti memberi tahu mereka "Anda dapat memiliki kompiler, tetapi Anda tidak diizinkan menjalankannya". Tampak bagi saya bahwa pengembang ingin / memerlukan akses ke contoh database mereka sendiri secara khusus untuk memungkinkan mereka menguji berbagai metode penyelesaian masalah TANPA harus muck dengan database PRODUCTION atau TEST. Anda harus mendorong perilaku semacam itu, bukan mengecilkannya.

Beberapa mungkin menyarankan bahwa pengembang bekerja dengan contoh lokal SQL Express, tetapi sementara SQL Express untuk setiap pengembang dapat memecahkan masalah tertentu, ia memiliki keterbatasan dan karakteristik kinerja yang berbeda dari SQL Server penuh pada server yang terpisah.

Apa yang HARUS Anda lakukan adalah melembagakan jadwal pencadangan rutin (setidaknya setiap malam) dan bekerja dengan pengembang untuk memastikan bahwa mereka tahu cara memulai pencadangan yang tidak dijadwalkan, dan memulihkan dari pencadangan, sehingga waktu henti diminimalkan jika terjadi masalah.

— Craig Trader
sumber
Analogi Anda sepenuhnya salah. Apa yang terjadi adalah mereka berkeliaran dan bersiul ketika mereka tidak dapat melakukan migrasi ke server yang terkunci. Saya seorang pengembang DBA tentu saja :-)
— gbn
Kemudian sedikit pendidikan dilakukan. Saya seorang pengembang yang terlalu sering menjadi DBA. Dengan kaki di kedua dunia, biasanya sudah tugas saya untuk mengajar kedua belah pihak untuk hidup berdampingan. Setelah semua, itu adalah pengguna yang adalah musuh, bukan DBA atau Pengembang ...
Ada juga hal-hal seperti rencana pemeliharaan yang tidak boleh mereka akses.
— Joel Coehoorn
1
Masalahnya adalah, kami memiliki beberapa grup Dev dan server ini meng-host semua DB mereka. Grup ini yang membutuhkan hak 'sa' hanya memiliki 33% dari DBS. Kekhawatirannya adalah bahwa mereka mungkin bermain-main dan menjatuhkan server, berdampak pada kelompok lain juga. Perusahaan tidak ingin mendapatkan perangkat keras yang terpisah untuk mereka, kecuali kami dapat membuktikan bahwa mereka gagal.
2
Itu konyol. Setiap grup pengembangan harus memiliki server sendiri, sehingga tidak ada yang menginjak siapa pun. Perangkat keras dewasa ini praktis gratis, dan perangkat lunak hampir semurah perangkat keras. Dan jika organisasi Anda cukup besar untuk memiliki beberapa grup pengembangan, itu harus menggunakan virtualisasi server, yang akan membuat semua ini lebih mudah.
3

Yang dev server, bukan DB kelompok dukungan server, atau server produksi. Simpan cadangan / gambar yang bagus dan biarkan devs meretas. Membiarkan kontrol DBA pada devbox seperti membiarkan ekor mengibas anjing. Ada di sana untuk pengembang untuk melakukan pekerjaan pengembang. Ini kadang-kadang melibatkan hal-hal yang melanggar dan menjatuhkan tabel, dan kemudian meletakkannya kembali dengan pengaturan yang berbeda. Kotak pengembang selalu akan rusak setelah beberapa saat, itulah yang kami lakukan. Jika kita tidak tahu di mana masalah terjadi, kami mencoba berbagai hal. Beberapa dari mereka mudah dibatalkan, beberapa tidak begitu banyak.

Masalahnya di sini adalah mudah bagi pengembang untuk melupakan bahwa aplikasi yang mereka buat tidak akan memiliki hak yang sama sepanjang waktu. Ya, beri mereka sa, tetapi buatlah agar mereka tidak secara default, sehingga mereka sadar ketika mereka melakukan sesuatu yang akan membutuhkan sedikit kerja ekstra untuk digunakan dengan benar.
— Joel Coehoorn
1

Saya tidak berpikir bahwa mereka membutuhkan hak SA di kotak Pengembangan. Dalam hampir semua kasus, mereka dapat melakukannya tanpa.

Saya pikir pilihan yang baik adalah menginstal edisi dev lokal.

pertanyaan:

Anda tidak ingin pengembang menambah / mengubah / menghapus objek basis data? !! Bagaimana mereka akan berkembang?

— Raj More
sumber
Maaf tentang kebingungannya. Yang saya maksud dengan poin itu adalah bahwa pengembang tidak boleh mengubah pengaturan basis data atau menjatuhkan basis data.
1

Kami mengharuskan semua perubahan struktur basis data dilakukan dengan skrip (bahkan pada dev) dan disimpan dalam subversi. Kemudian pada jadwal yang telah ditentukan kita menyegarkan dev dari prod dan mereka harus menjalankan kembali skrip mereka untuk kembali ke tempat mereka berada dalam siklus pengembangan. Ini membantu memastikan bahwa semuanya dilakukan melalui skrip dan bahwa mereka memiliki skrip yang siap ketika saatnya untuk penyebaran.

Saya tahu di tahun 2008 Anda dapat mengatur Pemicu DDL untuk melacak perubahan struktural basis data, dapatkah Anda melakukan ini pada tahun 2005? Dengan cara ini setidaknya Anda bisa mengetahui kapan seseorang mengubah pengaturan siapa yang melakukannya dan mencari tahu mengapa.

— HLGEM
sumber
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.