Apa hak istimewa yang wajar untuk memberikan pengguna biasa? [Tutup]

Saya menemukan daftar hak istimewa yang disediakan oleh MySQL sedikit berlebihan. Saya tidak yakin siapa yang harus memiliki hak istimewa apa. Menurut saya ada tiga pengguna biasa untuk situasi saya:

1. root
2. developer
3. application

rootcukup jelas. Untuk developerpengguna ini harus dapat dengan mudah mengakses database apa pun, membuat penyesuaian untuk itu, dll. Sebagai permulaan saya mengatur pengguna ini ke set hak istimewa ini:

SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, FILE, REFERENCES, INDEX, ALTER, SHOW DATABASES, CREATE TEMPORARY TABLES, LOCK TABLES, EXECUTE, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE, EVENT, TRIGGER ON

applicationmemiliki set yang lebih terbatas. Seharusnya hanya terbatas pada memanipulasi database tertentu.

Saya tidak yakin apa yang diberikan serangkaian hak istimewa yang masuk akal. Apa hak istimewa yang wajar untuk memberikan pengembang dan aplikasi dan mengapa?

Pengguna biasa harus memiliki:

SELECT, INSERT, DELETE, UPDATE, CREATE TEMPORARY TABLES, EXECUTE

Empat yang pertama cukup jelas - meskipun Anda juga dapat mengatur pengguna "baca saja" dengan hanya SELECT.

CREATE TEMPORARYjuga berguna dan biasanya tidak berbahaya: tabel sementara dapat membantu dalam mengoptimalkan kueri, memecahnya menjadi bagian yang lebih kecil & lebih cepat. Mereka terbatas pada koneksi yang mengeksekusi, dan secara otomatis terjatuh ketika ditutup.

EXECUTEtergantung pada jenis sistem Anda. Apakah Anda sudah menyimpan rutinitas? Apakah Anda ingin pengguna Anda mengaksesnya? Pastikan Anda juga tahu tentang SECURITY=DEFINER/INVOKERdefinisi untuk rutinitas yang disimpan.

Bagaimanapun, pastikan untuk menerapkan semua hal di atas pada skema tertentu . Hindari menggunakan:

GRANT SELECT, INSERT, UPDATE, DELETE ON *.* TO 'some_user'@'some_host';

seperti di atas juga memberikan hak istimewa pada mysqltabel sistem, yang secara efektif memungkinkan setiap pengguna untuk membuat akun baru atau memutakhirkan rangkaian hak istimewa mereka sendiri. Sebaliknya, lakukan:

GRANT SELECT, INSERT, UPDATE, DELETE ON some_schema.* TO 'some_user'@'some_host';
GRANT SELECT, INSERT, UPDATE, DELETE ON another_schema.* TO 'some_user'@'some_host';

Dalam sistem skala nyata apa pun (yaitu bukan proyek pribadi) tipe-tipe pengguna itu akan berbeda di setiap lingkungan sehingga tidak sesederhana itu.

Di semua lingkungan aplikasi harus memiliki apa yang dibutuhkan dan tidak lebih (umumnya ini adalah "pilih / masukkan / perbarui semua tabel" dan "exec pada semua prosedur". Untuk sistem yang lebih besar di mana Anda mungkin memiliki pengguna aplikasi yang terpisah untuk tugas yang berbeda (untuk Misalnya satu aplikasi bertanggung jawab untuk memasukkan data sensor dan lainnya untuk menghasilkan laporan) Anda harus memisahkan hak istimewa mereka sehingga mereka memiliki yang paling mereka butuhkan (pengguna pelaporan mungkin tidak perlu dan hak menulis). Pastikan Anda mereplikasi ini dalam pengujian Anda lingkungan jika Anda memilikinya: Saya telah melihat kode jatuh ketika dipromosikan ke Live yang bekerja dalam pengujian karena segala sesuatu di lingkungan pengujian mengakses DB sebagai sa(setara dengan MSSQL root).Idealnya, seorang pengguna aplikasi umumnya tidak memiliki hak istimewa yang memungkinkannya mengubah skema Anda (CREATE,, DROP...) - ada pengecualian untuk ini tetapi mereka sedikit dan jarang.

rootadalah, yah root,. Dalam produksi, ini hanya DBA Anda dan jarang digunakan - hanya untuk pemeliharaan sistem (upgrade ke desain DB dan sebagainya) dan pemantauan. Untuk sistem besar, terutama di lingkungan yang diatur di mana Anda harus mempertahankan kontrol ketat individu untuk tujuan akuntabilitas, Anda mungkin tidak mengizinkan satu rootpengguna sama sekali dan mencoba memisahkan hak istimewa menjadi gulungan kecil (saya tidak yakin seberapa jauh Anda bisa pergi dengan ini di mysql, tetapi Anda bisa dibilang cukup baik dalam MSSQL, Oracle dan sebagainya).

Untuk pengguna pengembang: mereka seharusnya tidak memiliki akses sama sekali ke lingkungan langsung Anda. Ini adalah salah satu alasan mengapa pengguna aplikasi tidak boleh memiliki skema yang memengaruhi hak: seseorang dengan akses ke akun pengembang berpotensi menghindari penguncian mereka dengan cara ini. Di lingkungan pengujian juga mereka biasanya tidak memiliki akses: mereka akan mengirimkan tambalan ke QA dan DBA (mungkin menggunakan rootpengguna) untuk QA akan menerapkan pembaruan ke lingkungan pengujian (pada kenyataannya ini sering otomatis di organisasi besar, jadi QA DBA sebenarnya adalah serangkaian skrip yang mengontrol pembangunan kembali lingkungan pengujian untuk setiap siklus). Dalam lingkungan pengembangan, terutama jika pengembang memiliki salinan lokal mereka sendiri dari layanan yang sedang berjalan, pengguna ini tentu saja harus memiliki akses penuh ke segala sesuatu untuk dapat bereksperimen.

Walaupun demikian, semua di atas adalah catatan umum: untuk membuat rekomendasi spesifik apa pun, kami perlu mengetahui lebih banyak tentang aplikasi Anda dan lingkungan tempat mereka beroperasi. Lingkungan target terkadang lebih penting daripada yang Anda kira: tergantung pada lingkungan bisnis Anda hak-hak pengguna Anda bahkan dapat didikte secara langsung menjadi peraturan hukum, bahkan dalam pengembangan jika klien Anda pernah memberi Anda akses ke data nyata untuk tujuan diagnostik.