Setiap petunjuk tentang mengurangi hak istimewa saya dalam produksi tetapi tidak membuat pekerjaan saya terlalu sulit

Menjalankan SQL Server 2005 dan 2008 pada Windows 2008 R2.

Kami akan mengurangi hak istimewa dalam produksi untuk pengembang - dan saya ingin melakukan hal yang sama untuk saya sendiri sebagai DBA , membatasi hak untuk produksi dan meningkatkan ketika diperlukan .

Tujuan utama saya adalah untuk menghilangkan kesalahan bodoh - yang dibuat oleh DBA , para penyembah akan paling banyak membaca akses dalam produksi. Kami suka bertindak seolah-olah kami adalah pahlawan super yang tidak dapat membuat kesalahan, tetapi tidak memiliki hak produksi sepanjang waktu masuk akal dan merupakan praktik terbaik, direkomendasikan oleh beberapa orang.

Apa pendekatan terbaik? Apa yang paling tidak menyakitkan untuk digunakan sehari-hari dan selama instalasi?

Saat ini kami memiliki grup windows untuk DBA yang memiliki hak untuk semua server dan database kami.

Saya juga tertarik untuk menurunkan OS / izin masuk jarak jauh - tapi saya paling peduli dengan hak DB.

Saya kira kita akan membutuhkan privat yang ditinggikan untuk menjalankan jejak sebagai sa, dan mungkin untuk pembersihan kepemilikan sebelum kita mengambil hak SA lama login kita. Masalah apa lagi yang mungkin kita harapkan?

Terima kasih atas saran dan berbagi pengalaman Anda!

Idealnya, untuk database produksi operasional, Anda tidak ingin pengembang memiliki akses ke server atau database sama sekali. Hal semacam itu adalah salah satu hal pertama yang harus Anda lakukan untuk kepatuhan SOX .

Untuk jenis hak yang dijalankan oleh userID, satu-satunya hak yang seharusnya mereka miliki adalah db_datareader, db_datawriterdan eksplisit GRANT EXECUTE ON x TO y(untuk setiap proc yang disimpan dan fungsi yang ditentukan pengguna xuntuk userID y).

Jika Anda perlu menjalankan jejak dalam produksi, Anda memiliki beberapa masalah dan akan membutuhkan Great Wall of Text ™ untuk menjelaskan semuanya. Rekomendasi pertama saya adalah memiliki lingkungan QA yang terkunci seperti produksi dan jika jejak perlu dijalankan, kembalikan cadangan prod db ke QA dan jalankan jejak di sana. Sekali lagi, jika Anda memiliki persyaratan SOX, HIPAA atau PCI-DSS , maka Anda lebih baik membersihkan data prod sebelum mengembalikannya ke QA.

Saat ini kami memiliki grup windows untuk DBA yang memiliki hak untuk semua server dan database kami.

Beri mereka masuk dan lihat hak data; namun untuk melakukan tugas DBAly, gunakan login terpisah dengan hak istimewa yang ditingkatkan. Saya tahu satu pelanggan keuangan yang melakukan ini - login reguler berdasarkan otentikasi windows terbatas pada kerusakan yang mereka dapat lakukan secara tidak sengaja. Memulihkan dan menjalankan DML yang diperlukan untuk menjalankan dengan login otentikasi SQL terpisah.

Satu agen pemerintah tempat saya bekerja menggunakan 2 login terpisah untuk setiap admin server / db. Jadi jika Tangurenaitu adalah login domain saya (login ini akan memiliki Userhak reguler ), maka itu TangurenaAdminakan menjadi Administratorlogin terpisah saya . Anda mendapat masalah jika Anda menggunakan akun admin Anda sepanjang waktu, tetapi kemudian tidak memiliki izin untuk hal-hal lain (seperti tidak ada email. Oh, Anda mengatakan bahwa itu adalah hal yang buruk ... ).

Instansi pemerintah saat ini saya bekerja dengan memiliki masing-masing server / db admin memiliki hak tinggi di atas pengguna standar, tetapi tidak cukup admin (anggap saja sebagai PowerUsergrup). Fungsi admin domain dilakukan dengan akun admin domain bersama.

Kesalahan umum adalah mengembalikan database yang salah (seperti QA dipulihkan melalui server produksi), dan ini tidak akan diselesaikan melalui hak terbatas atau login ganda. Melakukan hal-hal yang berpotensi merusak berpasangan adalah salah satu cara untuk meminimalkan risiko.

Saya kira kita perlu privs tinggi untuk menjalankan jejak sebagai sa

Anda hanya perlu izin ALTER TRACE:
http://msdn.microsoft.com/en-us/library/ms187611.aspx

Pada awalnya, saya sarankan Anda melakukan semua permainan privilege dalam pengembangan atau lingkungan QA di mana tidak ada masalah jika akses dihapus untuk beberapa waktu. Anda perlu melihat apakah aplikasi tidak memiliki masalah dengan keamanan.

Saya akan memberi tahu Anda pendekatan internal kami:

• semua aplikasi menggunakan pengguna domain tunggal yang diberikan izin yang diperlukan pada basis data (biasanya peran basis data db_owner).

• untuk membaca data sesekali kami menggunakan login SQL. Untuk pengguna itu kami menetapkan peran basis data - db_datareader. Di sinilah ini mengakhiri akses untuk pengembang di cluster database utama. Untuk gagasan lain yang akan mereka miliki, mereka akan menggunakan basis data server pelaporan yang merupakan salinan (dilakukan menggunakan Pengiriman Log) dari database server utama yang dilakukan pada tengah malam. Agar tidak membunuh server pelaporan dengan permintaan ad hoc pembunuh, kami menggunakan alokasi grup sumber daya untuk memori dan cpu.

• untuk tim DBA kami memiliki grup domain yang memiliki semua hak istimewa di mesin dan server (admin di mesin windows dan sysadmin di server sql)

• untuk instalasi, kami memiliki pengguna SQL yang db_owner pada database yang kami gunakan saat menjalankan pembaruan - kami menggunakan pemicu DDL untuk memantau perubahan skema dan kami akan melihat perubahan mana yang dilakukan selama instalasi atau sebagai perubahan terpisah

• ada beberapa pengecualian untuk pengembang berpengalaman, tetapi setelah kebutuhan mereka terpenuhi, kami menghapus akses mereka - mereka menerima izin berdasarkan login domain mereka, sehingga kami dapat memantau koneksi dalam jejak / tampilan ddl dan segala kemungkinan perubahan dengan pemicu ddl.

Adapun cara melakukan semua yang bekerja dengan login dan pengguna - di Studio Manajemen dalam folder keamanan server Anda membuat semua login yang diperlukan, dan kemudian, Anda mengasosiasikan mereka dengan database Anda dan memberi mereka peran yang mereka butuhkan. Jika Anda skrip tindakan, Anda akan melihat bahwa awalnya itu akan dibuat login server, kemudian pengguna database terhubung ke login itu, kemudian ditugaskan peran database untuk pengguna itu. Anda dapat menyimpan skrip di set skrip Anda, sehingga Anda dapat memverifikasi setiap kali pengguna mana yang harus ditayangkan dan ditendang dan mana yang tidak.

Dalam SQL server Anda dapat membuat pengguna basis data dan menetapkannya database roledengan izin baca / tulis / kepemilikan. Setelah pengguna dimigrasi ke produksi, Anda dapat pergi ke pengguna database yang dimigrasi dan hapus centang peran yang tidak Anda inginkan. Sebagai contoh, katakanlah stan pengguna adalah anggota db_owner (kepemilikan database) yang sedang diuji. Setelah stan pengguna dimigrasikan ke produksi, Anda dapat mengeluarkannya dari db_owner dan hanya menetapkan peran db_datareader (hanya baca) untuk itu.

Dalam SQL 2005+ lebih banyak kontrol granular dapat dilakukan dengan schema. Periksa tautan ini pada skema untuk detail lebih lanjut.