it-swarm.asia

Haruskah pengembang dapat meminta basis data produksi?

Haruskah pengembang diberikan izin untuk query (SELECT/hanya baca) database produksi? Tempat saya sebelumnya bekerja, tim pengembangan memiliki db_datareader wewenang; tempat saya bekerja sekarang tim pengembangan bahkan tidak dapat terhubung ke instance produksi.

Salah satu contoh pengujian adalah salinan produksi yang dipulihkan dari cadangan produksi seminggu sekali, jadi tidak ada masalah dengan pengembang yang benar-benar melihat data.

Apa alasan bagus untuk tidak mengizinkan pengembang untuk meminta produksi (kecuali untuk hanya tidak ingin mereka memiliki akses untuk membaca data sensitif)?

164
Tom Hunter

Itu sangat tergantung pada apakah pengembang memiliki tanggung jawab dukungan. Jika mereka berada di hook untuk dukungan lini ketiga maka mereka mungkin perlu melihat pada database produksi untuk melakukan ini.

Secara umum itu adalah ide yang buruk untuk melakukan sesuatu pada server produksi kecuali jika benar-benar diperlukan untuk melakukannya di sana.

Untuk sebagian besar tujuan pengembangan, mirror atau snapshots dari database produksi akan memadai, dan mungkin lebih baik daripada database produksi langsung. Jika Anda melakukan sesuatu yang melibatkan integrasi maka Anda ingin lingkungan database yang stabil di mana Anda dapat mengontrol apa yang ada di dalamnya. Apa pun yang melibatkan rekonsiliasi juga perlu kemampuan untuk melihat titik waktu yang terkendali.

Jika masalahnya adalah Anda tidak memiliki lingkungan mirror produksi atau sarana apa pun untuk menempatkan salinan data produksi di suatu tempat untuk pengembang Anda, maka ini adalah pertanyaan yang agak berbeda. Dalam hal ini pengembang Anda benar-benar membutuhkan setidaknya satu lingkungan cermin. Jika Anda tidak dapat melihat apa masalahnya di dalam data, maka agak sulit untuk memecahkannya.

Tidak.

Pengembang tidak boleh memiliki akses ke sistem basis data produksi karena alasan berikut:

  1. Ketersediaan dan Kinerja : Memiliki hak baca-saja ke database adalah bukan tidak berbahaya. Kueri yang ditulis dengan buruk dapat:

    1. Mengunci tabel, memblokir proses penting lainnya.
    2. Sampah cache data Anda, memaksa proses lain untuk membaca kembali data dari disk.
    3. Pajak lapisan penyimpanan Anda, berdampak pada layanan lain yang berbagi penyimpanan itu.
  2. Keamanan : Basis data produksi Anda mungkin berisi informasi sensitif seperti:

    • kata sandi hash
    • informasi tagihan
    • informasi pengenal pribadi lainnya

    Hanya mereka yang benar-benar membutuhkan akses ke informasi ini yang harus memilikinya. Di perusahaan yang terorganisasi dengan baik, pengembang tidak termasuk di antara mereka. Lebih lanjut, perusahaan Anda akan gagal memenuhi PCI dan SOX jika pengembangnya dapat mengakses sistem produksi dengan data ini.

    Alasannya jelas. Pekerjaan pengembangan pengembang melewati banyak tangan sebelum ditayangkan. Apa yang menghentikan pengembang jahat dengan akses produksi langsung dari mencuri data produksi Anda atau membuat database langsung Anda bertekuk lutut?

    "Tapi itu juga berlaku untuk DBA! Mereka bisa melakukannya!" Persis. Anda ingin superuser sesedikit mungkin bertanggung jawab.

Iya.

Pengembang harus memiliki akses ke sistem produksi.

Di perusahaan saya, kami memiliki empat tim yang berurusan dengan basis data produksi. Mereka:

  1. Pengembang , yang mendesain dan menulis skema dan kode untuk basis data. Mereka tidak memiliki akses ke database dalam produksi. Namun, mereka kadang-kadang duduk bersama Administrator atau mendukung orang dan membantu mereka melihat sesuatu secara langsung.
  2. Administrator , yang menyebarkan, memantau, dan mengelola basis data dalam produksi.
  3. Mendukung orang-orang , yang menyelidiki masalah-masalah produksi yang sensitif terhadap waktu dan memberikan umpan balik kepada para pengembang sehingga mereka dapat mengembangkan perbaikan.
  4. Orang-orang Intelijen Bisnis , yang mengekstrak data dari basis data produksi menggunakan salinan yang diperbarui secara teratur dari basis data tersebut atau ekstrak yang ditulis dengan cermat dan QA-ed (biasanya dirancang oleh Administrator ).

Sangat tepat untuk memberikan akses produksi pengembang Anda ketika Anda memiliki kekurangan tertentu dalam grup lain ini.

Sebagai contoh:

  • Anda tidak memiliki tim pendukung. Siapa yang akan tahu ke mana harus mencari debug masalah produksi yang sensitif waktu? Pengembang Anda. Berikan mereka " buka gelas " akses.
  • Anda tidak memiliki tim BI. Admin Anda tidak memiliki atau ingin ada hubungannya dengan laporan atau ekstrak. Siapa yang akan memecahkan masalah laporan yang dilihat eksekutif Anda setiap pagi? Pengembang Anda. Berikan mereka akses terbatas untuk men-debug laporan dan ekstrak ini.
  • Anda tidak memiliki tim admin. Anda berada di perusahaan yang sangat kecil atau startup, jadi ucapkan halo pada "DBA yang tidak disengaja". Pengembang Anda berfungsi ganda sebagai administrator Anda, dan karenanya memerlukan akses penuh ke produksi.
136
Nick Chammas

Kinerja akan menjadi alasan BESAR.

Hanya karena mereka tidak dapat mengubah data tidak berarti mereka tidak dapat mempengaruhi server. Permintaan yang ditulis dengan buruk dapat membuat lingkungan produksi bertekuk lutut, dan berpotensi menyebabkan masalah lain (seperti kelebihan tempdb):

SELECT *
FROM BigTable A, OtherBigTable B
ORDER BY Somecolumn

Itu resep untuk bencana. Perhatikan bahwa ini adalah produk kartesius dengan pesanan oleh, yang berarti akan diurutkan dalam tempDB.

79
JNK

Prinsipnya adalah "privilege paling" dan "perlu tahu": apakah pengembang lulus dari tes ini?
Terutama ketika Auditor atau Sarbannes-Oxley datang mengetuk.

Kemudian, asumsi saya selanjutnya: pengembang itu bodoh. Jadi jika mereka perlu mengatakan untuk dukungan baris ke-3, siapa lal membutuhkannya? Monyet web biasanya tidak tetapi tipe database ya jika mereka diharapkan untuk mendukungnya.

Lalu, apakah akses diperlukan secara permanen? Mereka dapat memiliki akses "memecahkan kaca" menggunakan login SQL atau akun Windows alternatif yang memerlukan sign off. Dalam kasus kami, pemilik data (semoga pengusaha yang mengerti teknologi) dan manajer TI yang menyetujuinya.

Saya memiliki melihat pengembang menguji atau menjalankan kueri pada produksi dan menghapusnya karena ketidaktahuan. Mengatakan itu, pengembang harus bertanggung jawab atas tindakan mereka: jika mereka menurunkan server, mereka harus menderita karenanya. Saya mendapati seseorang diturunkan setelah satu kejadian ...

Ini mengasumsikan toko yang cukup besar tentu saja. Semakin banyak topi yang dikenakan orang, semakin sedikit pemisahan tugas yang dapat Anda miliki

Juga, apakah ada lingkungan yang pengembang dapat menjalankan kueri terhadap data terbaru? Di toko terakhir saya, prod dikembalikan setiap malam ke server uji untuk menyediakan ini.

33
gbn

Saya pikir jawabannya adalah, seperti halnya dengan banyak hal IT, "itu tergantung".

Basis data besar ERP dengan banyak informasi perusahaan dan pelanggan yang sensitif? Mungkin tidak (baik karena alasan keamanan dan kinerja).

Database 5 MB departemen dengan front-end Access yang melacak kontribusi ke dana donat dan pizza? Tidak akan membuat banyak perbedaan, setidaknya untuk akses read-only.

Memang, contoh pertama jauh lebih umum daripada yang kedua, tetapi ini adalah perbedaan yang harus Anda ketahui jika Anda bertanggung jawab untuk membuat keputusan kebijakan jenis ini. Namun di sisi lain, sungguh menakjubkan betapa cepatnya basis data donat-dan-pizza-5 MB dapat merambah cakupannya menjadi 50-part part/pelanggan-kredit-kartu-angka/siapa-tahu-apa- database lain jika Anda membiarkannya.

20
db2

Pada lingkungan 24/7 biasa OLTP pengembang normal tidak boleh diizinkan dalam produksi. Periode! Jika, dari waktu ke waktu, alasan tertentu muncul, maka izin dapat diberikan atas permintaan. Tetapi secara biasa tidak.

Saya telah melihat banyak alasan untuk ini:

  • SELECT * dari tabel besar yang menuju ke:

    • masalah kinerja (produk kartesius);
    • memblokir masalah yang akhirnya membuat situs itu bertekuk lutut;
    • memblokir rantai yang membuat replikasi digantung;
    • memesan set besar data yang mengisi drive TempDB yang .. coba tebak? Disebabkan kegilaan total :-)!
    • tekanan darah tinggi untuk DBA yang bertanggung jawab atas produksi untuk malam itu;
  • membaca data sensitif (pengembang tidak boleh mengakses informasi kartu kredit .. atau detail pribadi pengguna);

Saya yakin ada lebih banyak alasan.

20
Marian
  • Keamanan: Mungkin ada informasi sensitif yang disanitasi ketika mereka membuatnya tersedia untuk pengembang.
  • Paranoia: Beberapa orang mungkin berpikir Anda masih bisa mengacaukan data dengan hanya memilih akses.
  • Kinerja: Kueri membutuhkan beberapa sumber daya untuk melakukan, dan Anda tidak dapat memberi tahu saya pengembang Anda sempurna ketika mereka menulis kode.
19
Paul

Beberapa item untuk dipertimbangkan

  • Apakah data sensitif?
  • Apakah pemrogram bagian dari tim inti tepercaya atau tim lepas pantai?
  • Apa skala data yang ditanyakan dalam hal dampak kinerja?
  • Apa skala proyek atau dolar yang terlibat?
  • Seberapa kritis uptime-nya?

Dolar lebih kecil perlu lebih sedikit proses membutuhkan aliran pengembangan yang lebih cepat.

Dolar lebih besar perlu lebih banyak proses membutuhkan standar praktik pembangunan yang lebih ketat.

Sesuaikan praktik Anda dengan apa yang Anda lakukan.

16
Jason Sebring

Saya bekerja sebagai pengembang untuk perusahaan yang sangat besar. Semua pengembang kami yang akan melakukan segala jenis dukungan (pada dasarnya semuanya) memiliki akses ke basis data produksi yang relevan. Saya hanya dapat berbicara untuk tim khusus saya, tetapi saya akan memberi tahu Anda mengapa kami memiliki akses.

  1. Kita perlu akses waktu nyata untuk mengawasi pemrosesan harian kita. (Meskipun kami memiliki dasbor, kami harus dapat mengawasi hal-hal secara mendalam. Meskipun akan menyenangkan jika memiliki fitur ini di dasbor kami, kami mendapati bahwa itu tidak taktis.)
  2. Kami membutuhkan akses waktu nyata untuk menyelidiki setiap kegagalan produksi karena penundaan dapat berdampak besar. (Saya tidak akan membahas kegagalan kami di sini. Mereka datang dalam segala macam)
  3. Kami sering perlu melakukan laporan khusus untuk pengguna bisnis dan informasi ini perlu terbaru. (dba tidak punya waktu untuk melakukan ini dan kami tidak punya waktu untuk menunggu mereka. non-ideal, pasti.)
  4. Kita perlu melakukan verifikasi penyebaran/tambalan DDL/DML produksi. (DBA menyebarkannya, tetapi hanya kita yang tahu bagaimana strukturnya. Kita tahu lebih banyak tentang struktur basis data kita daripada DBA. Kita mungkin aneh di sini, tetapi basis data sangat rumit karena bisnis kita sangat rumit.)

Kinerja adalah masalah. Kami memang memiliki kemunculan pengembang yang menyebabkan pelambatan. Namun, ini adalah contoh yang terisolasi dan SQL kami sangat didorong oleh kinerja sehingga jarang pengembang kami tidak memahami dampak dari pertanyaan mereka.

14
user606723

Agar pertanyaan ini dapat ditanyakan, seseorang harus menganggap bahwa mereka saat ini tidak memiliki akses. Jika organisasi seseorang mengembangkan perangkat lunak dan ini untuk pemecahan masalah masalah pelanggan dan pelanggan memasok salinan database mereka, maka 'ya'. Kalau tidak, saya akan menganjurkan menjaga pengembang dari produksi dan memiliki lingkungan alternatif yang dibuat untuk kebutuhan penelitian mereka. Setelah pasta gigi keluar dari tabung, sulit memasukkannya kembali.

11
jl01

Saya setuju bahwa beban pembenaran harus ada pada orang-orang yang membutuhkan akses. Biasanya di lingkungan tempat saya berkonsultasi, saya memiliki akses ke sistem produksi di mana itu adalah lingkungan kecil dan saya adalah orang yang mendukung. Saya telah memiliki akses ke cadangan, dll. Di mana saya mendukung untuk dukungan, dan akses tidak langsung (melalui pengembang dukungan khusus) ke data produksi.

Yang penting adalah: Anda memerlukan akses ini ketika Anda berada di hook untuk menjaga semuanya berjalan lancar dan Anda harus menjawab pertanyaan orang keuangan tentang sesuatu yang tidak berfungsi. Anda tidak dapat selalu bekerja dari data lama bahkan dalam kasus itu. Di sisi lain, semakin banyak akses semakin buruk. Biasanya sebagai konsultan saya cenderung menghindari mendapatkan akses semacam ini kecuali jika diperlukan. Karena saya sedang mengerjakan basis data keuangan, hal terakhir yang saya inginkan adalah dituduh memasukkan faktur saya sendiri :-D.

Di sisi lain, jika Anda tidak membutuhkan akses Anda tidak harus memilikinya. Saya tidak benar-benar membeli argumen data sensitif karena pengembang mungkin siap untuk memastikan ini ditangani dengan benar (dan sangat sulit untuk memverifikasi tanpa melihat apa yang sebenarnya disimpan ketika laporan bug masuk). Jika Anda tidak dapat mempercayai pengembang untuk melihat data yang disimpan oleh aplikasi pengembang, Anda tidak boleh menyewa pengembang untuk menulis aplikasi. Ada terlalu banyak cara pengembang bisa mengaburkan data dan mengirim email, dan Anda tidak pernah bisa yakin. Kontrol MAC membantu di sini tetapi masih cukup rumit untuk diterapkan.

Masalah besar dari pihak saya berkaitan dengan akses tulis. Jika pengembang tidak memiliki akses, maka fortiori, pengembang tidak memiliki akses tulis. Jika Anda ingin memverifikasi integritas buku, Anda ingin tetap akses tulis ke sesedikit mungkin orang. Jalur audit jauh lebih mudah untuk divalidasi jika pengembang tidak memiliki akses. Jika pengembang memiliki akses baca, maka Anda selalu memiliki beberapa pertanyaan, apakah telah ada beberapa privilege escallation attach yang dapat memberikan akses tulis (mungkin injeksi SQL prosedur yang tersimpan?). Saya sering memiliki akses penuh ke info penagihan klien ketika saya memiliki akses ke lingkungan pementasan. Jika ada lingkungan pementasan yang berfungsi, saya biasanya akan secara aktif meminta tidak untuk memiliki akses ke produksi kecuali jika diperlukan.

Jadi ini tidak sempurna, tentu saja. Pengembang masih dapat membangun pintu belakang ke dalam aplikasi yang mungkin tidak mudah terdeteksi, tetapi pendekatan ini adalah pendekatan yang masuk akal, mengingat fakta bahwa data cadangan tersedia dari sehari sebelum bagi saya tampaknya ini adalah masalah yang mereka miliki.

Semoga ini membantu.

Sunting: Hanya menambahkan bahwa pada lingkungan yang lebih besar tempat saya bekerja, saya telah memiliki akses ke data cadangan lengkap yang sering berkisar dari beberapa hari hingga beberapa bulan untuk sistem keuangan. Ini selal sudah cukup baik untuk pekerjaan saya dan satu-satunya waktu itu telah rusak adalah ketika orang-orang keuangan membutuhkan kemampuan untuk menguji dengan data yang lebih baru sehingga mereka dapat cocok dengan produksi.

10
Chris Travers

Tidak memiliki akses adalah hal yang baik dan cara untuk melindungi pengembang dan orang lain dari tidak sengaja merusak data atau melihatnya. Ini juga melindungi perusahaan dari melanggar hukum (yaitu pelanggaran Hipaa dan masalah privasi)

Pengembang tidak pernah benar-benar membutuhkan akses ke lingkungan produksi, itu hanya lebih mudah dari sudut pandang pengembang jika bug yang sulit tidak dapat direproduksi.

Namun, pengembang dapat memasukkan mini-dumps atau file log dan menggunakan file simbol PDB untuk membuat kembali bug.

Jika data memang perlu dibawa ke lingkungan pengujian maka itu adalah khas untuk beberapa jenis proses untuk menggosok data yang dapat membuat pekerjaan tambahan.

Tergantung pada perangkat lunak basis data yang digunakan dalam apa yang Anda sebut produksi, lisensi baru mungkin diperlukan bagi pengembang untuk mengakses database, yang merupakan biaya besar untuk hanya memiliki akses baca.

Jika perusahaan Anda tidak memberi Anda alat untuk men-debug atau meneliti masalah produksi, itu bukan karena Anda tidak memiliki akses ke data produksi.

Data adalah bagian paling berharga dari sebagian besar aplikasi!

9

Kinerja mungkin menjadi salah satu alasannya.

Kueri pengembang seringkali tidak efisien, menyebabkan penguncian yang berlebihan atau penggunaan sumber daya sampai mereka disetel dengan benar.

Sistem produksi bukan tempat yang cocok bagi pengembang untuk bereksperimen.

8
JSR

Itu tergantung pada DBA dan bagaimana dia percaya diri dengan pengembang. Biasanya pengembang diberikan hak kueri (baca) ke basis data produksi. Sebagai aturan praktis, pengembang harus hanya bekerja dengan database uji/dev.

8
MarlonRibunal

Tantangannya adalah sebagian besar aplikasi perangkat lunak didorong oleh data. Jadi ketika Anda mencoba untuk memperbaiki masalah dalam aplikasi, Anda benar-benar perlu melihat data yang mengendarainya. Jadi pengembang benar-benar membutuhkan beberapa bentuk akses.

Menggunakan SQL login hanya memberi mereka akses hanya baca ke tabel sangat bagus. TETAPI, apa yang mencegah mereka membuat kueri dengan 20 bergabung atau melakukan SELECT * dari tabel dengan jutaan catatan? Kueri ini secara tidak sengaja dapat mematikan kinerja basis data dan penyimpanan Anda.

Perusahaan saya Stackify datang dengan cara cerdas untuk menyelesaikan ini. Pengembang dapat menjalankan kueri melalui perangkat lunak kami dan kami menggunakan rencana kueri untuk memastikan itu hanya pernyataan SELECT dan bahwa perkiraan biaya kueri rendah dan akan mengembalikan hanya beberapa catatan. Dengan cara ini mereka tidak bisa berbuat banyak kerusakan. Kami juga mengaudit semua kueri yang mereka jalankan.

Ini hanya salah satu hal yang kami sediakan. Lihat kami di http://www.Stackify.com untuk mempelajari lebih lanjut tentang dukungan DevOps kami solusi.

8

Iya. Dalam beberapa kasus, masuk akal untuk mengizinkan beberapa subset pengguna, termasuk pengembang beberapa tingkat akses ke permintaan data produksi. Namun, batasan yang tepat harus ada karena dua alasan. Pertama, sebagai DBA, Anda harus melakukan yang terbaik untuk memastikan tingkat layanan yang dibutuhkan oleh semua pengguna. Juga, Anda ingin mencegah pertanyaan buruk yang tidak disengaja seperti penghapusan massal atau vilolasi aturan bisnis. Ini harus berjalan tanpa mengatakan bahwa kontrol keamanan yang tepat harus ada.

Apa pun alasan yang mungkin Anda miliki untuk tidak mengizinkan permintaan ad hoc langsung ke tabel database, mungkin ada kasus yang dibuat untuk memungkinkan permintaan untuk dilihat dan prosedur yang tersimpan. Dengan menggunakan izin basis data, Anda dapat mencegah permintaan SELECT terhadap tabel secara langsung dan bahkan membatasi tampilan dan prosedur tersimpan yang diberikan pengguna. Metode ini tidak hanya memberikan fleksibilitas kepada basis pengguna Anda, tetapi juga melindungi integritas dan keandalan data Anda ketika diimplementasikan dengan benar.

7
Tom Resing

Di perusahaan kami, kami memelihara budak hanya-baca dari basis data produksi yang tidak diandalkan oleh layanan produksi. Kami memberikan pengembang akses kepada mereka untuk mengakses data produksi. Jika ada data sensitif (Info Pelanggan, info pembayaran, dll.) Kami membatasi replikasi tabel-tabel itu dan mempertahankan tabel data sampel pada server slave.

5
Ryan Waldron

Tidak. Tidak pernah !!

Inilah sebabnya kami memiliki server pengembangan/Uji/UAT. Data dari Produksi dapat disalin ke lingkungan pengujian dan pengembang dapat melanjutkan pengujian mereka. Kueri pemilihan bisa sangat berbahaya juga jika terjadi lingkungan Produksi. Ini meningkatkan beban dan pada waktu puncak dapat menurunkan seluruh kinerja.

Setiap informasi yang mereka butuhkan harus melalui DBA yang dapat menjalankan apa yang mereka inginkan (Pilih) dan mengirimkan hasilnya kepada mereka. Itulah yang kami lakukan di lingkungan kami.

1