Solusi 1:
-
Siapa yang menginstal Oracle di server?
Jika itu adalah DBA, mereka membutuhkan akses root. Jika sysadmin, DBA tidak. -
Siapa yang dipanggil larut malam ketika server database sedang down?
Jika Anda tidak dapat memastikan sysadmin tersedia 24/7, Anda mungkin ingin memberikan akses root ke DBA.
Ingatlah bahwa jika DBA Anda sudah memiliki akses shell sebagai pengguna biasa (dengan atau tanpa beberapa perintah yang dapat dijalankan melalui sudo; dengan atau tanpa chroot) itu cukup untuk mengacaukan server (orang jahat yang mencuri akunnya dapat melakukan fork bom , melebihi ulimit pengiriman spam, drop database, ...).
Untuk semua alasan ini, menurut saya di dunia yang ideal, DBA tidak boleh memiliki akses root; tetapi di dunia nyata, mereka setidaknya harus selalu bisa mendapatkannya dalam keadaan darurat.
Solusi 2:
Secara umum—dan tidak spesifik untuk DBA—siapa pun yang menuntut root akses tanpa memberikan alasan yang sah adalah:
- Seseorang yang tidak tahu apa yang mereka lakukan.
- Sombong &tidak kooperatif.
- Keduanya di atas.
Sekarang, mungkin ada alasan sebenarnya mengapa mereka membutuhkan root akses untuk menangani tugas mereka, tetapi sekali lagi jika mereka tidak dapat menjelaskan mengapa &menuliskannya, saya tidak akan berurusan dengan mereka. Profesional yang berurusan dengan server memahami &menghormati batasan. Penembak jitu yang cukup tahu untuk mendapat masalah percaya bahwa aturan berlaku untuk semua orang kecuali mereka.
Dalam kasus di mana saya harus bergumul dengan orang-orang seperti ini, saya bersikeras bahwa waktu dijadwalkan sebelumnya sehingga saya dapat berada di server bersama mereka untuk menangani masalah yang muncul. Dan ini benar-benar bekerja dengan baik.
Alternatif lain—yang mungkin tidak praktis—adalah membuat tiruan persis dari server yang dimaksud &memberi mereka root akses pada itu. Pastikan untuk mengubah kata sandi menjadi sesuatu yang spesifik untuk mereka tentunya. Biarkan mereka meledakkan kotak pengembangan yang terisolasi.
Tetapi secara umum, jika Anda adalah orang yang akan dipanggil larut malam untuk membereskan kekacauan yang mungkin dibuat oleh orang ini, maka Anda berhak menolak permintaan menyeluruh untuk root akses.
Solusi 3:
Secara teoritis DBA dapat bekerja tanpa root privs, tetapi PITA untuk kedua belah pihak. Secara praktis tidak mungkin untuk menentukan daftar perintah agar dapat diakses melalui sudo .
Berikan priv root DBA jika:
- Anda tidak ingin dibangunkan di tengah malam, hanya untuk mem-boot ulang server
- Anda menginginkan manajemen insiden yang cepat dan lancar
- jika server Anda didedikasikan hanya untuk server DB
DBA biasanya memerlukan root privs untuk:penyesuaian parameter kernel (sysctl), manipulasi penyimpanan, investigasi masalah.
Audisi yang tepat memastikan kondisi pengoperasian yang lebih baik, daripada aturan keamanan yang ditentukan secara ketat. Jika Anda menerapkan audit, Anda selalu dapat bertanya mengapa mereka melakukan/mengubah sesuatu. Jika Anda tidak memiliki audit, Anda tidak memiliki keamanan.
DIEDIT
Ini adalah daftar persyaratan umum Oracle pada standalone (instalasi non-cluster)
-
Parameter kernel
- Terkait memori (konfigurasi halaman besar/besar, RAM bersama (ipcs), RAM tidak dapat ditukar (dikunci))
- terkait jaringan (ukuran jendela pengiriman/penerimaan, TCP keepalive)
- terkait penyimpanan (jumlah file terbuka, IO asinkron)
Mungkin ada sekitar 15-20 parameter sysctl. Untuk masing-masingnya, Oracle memberikan nilai atau persamaan yang direkomendasikan. Untuk beberapa parameter, persamaan yang direkomendasikan dapat berubah dari waktu ke waktu (aync io) atau dalam beberapa kasus, Oracle menyediakan lebih dari satu persamaan untuk parameter yang sama.
- Penyimpanan:Aturan udev Linux tidak menjamin boot nama perangkat yang persisten. Oleh karena itu Oracle menyediakan driver dan alat kernel (AsmLib). Ini memungkinkan Anda untuk menamai partisi fisik sebagai root dan kemudian Anda dapat melihat label ini saat mengelola penyimpanan database
- Penyelidikan masalah:
- Ketika basis data macet karena tidak dapat membuka lebih banyak pegangan file maka satu-satunya solusi adalah meningkatkan batas kernel, jalankan 'sysctl -p' dan kemudian mulai DB.
- Juga ketika Anda menemukan bahwa RAM fisik terlalu terfragmentasi dan basis data tidak dapat mengalokasikan halaman besar, maka satu-satunya pilihan adalah me-reboot server.
- (DCD) - deteksi koneksi mati. Misalnya di AIX netstat tidak mencetak PID. Satu-satunya cara memasangkan koneksi TCP dengan PID adalah debugger kernel.
- glance (sesuatu seperti top di HP-UX) membutuhkan root privs
- berbagai investigasi tingkat Veritas
- dan banyak lagi lainnya
Terserah Anda untuk memutuskan berapa banyak waktu yang akan Anda "buang" sampai masalah teratasi. Saya hanya ingin menunjukkan bahwa pemisahan peran yang kuat bisa sangat mahal dalam beberapa kasus. Jadi alih-alih meningkatkan "keamanan", fokuslah pada pengurangan risiko dan bahaya. Yang tidak sama. Alat-alat seperti ttysnoop atau shell spy memungkinkan Anda untuk "merekam" seluruh sesi ssh, sehingga mereka memberikan ketakterbantahkan. Ini bisa berfungsi lebih baik daripada sudo.