Apakah Oracle DBA saya perlu akses root?

Rekan DBA Oracle saya meminta akses root pada server produksi kami .
Dia berpendapat bahwa dia memerlukannya untuk melakukan beberapa operasi seperti me - reboot server dan beberapa tugas lainnya.

Saya tidak setuju dengannya karena saya telah menetapkannya sebagai pengguna / grup Oracle dan grup dba tempat pengguna Oracle berada. Semuanya berjalan dengan lancar dan tanpa DBA memiliki akses root saat ini.
Saya juga berpikir bahwa semua tugas administratif seperti reboot server terjadwal perlu dilakukan oleh administrator yang tepat (Administrator Sistem dalam kasus kami) untuk menghindari segala jenis masalah yang berkaitan dengan kesalahpahaman interaksi infrastruktur.

Saya ingin masukan dari sysadmin dan Oracle DBAs - Apakah ada alasan bagus untuk Oracle DBA memiliki akses root di lingkungan produksi ?

Jika kolega saya benar-benar membutuhkan tingkat akses ini, saya akan menyediakannya, tetapi saya cukup takut melakukannya karena masalah keamanan dan integritas sistem.

Saya tidak mencari pro / kontra tetapi saran tentang bagaimana saya harus mengambil untuk menghadapi situasi ini.

• Siapa yang memasang Oracle di server?
  Jika itu 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, ia dapat dijalankan melalui sudo; dengan atau tanpa chroot) itu cukup untuk mengacaukan server (orang jahat yang mencuri akunnya dapat melakukan bom) , melebihi ulimit mengirim spam, jatuhkan basis data, ...).

Untuk semua alasan ini, saya pikir dalam dunia ideal, DBA seharusnya tidak memiliki akses root ; tetapi di dunia nyata, mereka setidaknya harus selalu bisa mendapatkannya jika terjadi keadaan darurat.

Secara umum — dan tidak khusus untuk DBA — siapa pun yang menuntut rootakses tanpa memberikan alasan yang valid adalah:

1. Seseorang yang tidak tahu apa yang mereka lakukan.
2. Sombong & tidak kooperatif.
3. Kedua hal di atas.

Sekarang, mungkin ada alasan nyata mereka membutuhkan rootakses 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 & menghargai batasan. Tembakan panas yang cukup tahu untuk mendapat masalah percaya aturan berlaku untuk semua orang kecuali mereka.

Dalam kasus di mana saya harus bertengkar dengan orang-orang seperti ini, saya bersikeras bahwa waktu dijadwalkan sebelumnya sehingga saya bisa berada di server dengan mereka untuk menangani masalah ketika mereka muncul. Dan ini sebenarnya bekerja dengan baik.

Alternatif lain — yang mungkin tidak praktis — adalah membuat tiruan tepat dari server yang dimaksud & memberi mereka rootakses untuk itu. Pastikan untuk mengubah kata sandi ke sesuatu yang spesifik untuk mereka tentu saja. Biarkan mereka meledakkan kotak pengembangan yang terisolasi.

Tetapi secara umum, jika Anda adalah orang yang akan dipanggil larut malam untuk membersihkan kekacauan yang mungkin dibuat oleh orang ini, maka Anda memiliki hak untuk mengatakan tidak pada permintaan selimut untuk rootakses.

Secara teoritis DBA dapat bekerja tanpa root privat, tetapi ini adalah PITA untuk kedua belah pihak. Secara praktis tidak mungkin untuk menentukan daftar perintah yang dapat diakses melalui sudo.

Berikan DBA root privs jika:

• Anda tidak ingin dibangunkan di tengah malam, hanya untuk me-reboot server
• Anda ingin manajemen insiden yang cepat dan lancar
• jika server Anda didedikasikan untuk server DB saja

DBA biasanya membutuhkan root privat untuk: penyesuaian parameter kernel (sysctl), manipulasi penyimpanan, penyelidikan masalah.

Audisi yang tepat memastikan kondisi pengoperasian yang lebih baik, daripada aturan keamanan yang ditetapkan secara ketat. Jika Anda telah menerapkan audit Anda selalu dapat bertanya mengapa mereka melakukan / mengubah sesuatu. Jika Anda tidak memiliki audit, Anda tidak memiliki keamanan.

Diedit

Ini daftar persyaratan umum Oracle pada standalone (instalasi non-clustered)

• Parameter kernel

  • Memori yang terkait (konfigurasi halaman besar / besar, RAM bersama (ipcs), RAM non-swapable (terkunci))
  • terkait jaringan (ukuran jendela pengirim / penerima, TCP keepalive)
  • penyimpanan terkait (jumlah file yang terbuka, async IO)

  Mungkin ada sekitar 15-20 parameter sysctl. Untuk masing-masing Oracle memberikan nilai atau persamaan yang disarankan. Untuk beberapa parameter, persamaan yang disarankan dapat berubah seiring waktu (aync io) atau dalam beberapa kasus Oracle menyediakan lebih dari satu persamaan untuk parameter yang sama.

• Penyimpanan: Aturan udev Linux tidak menjamin nama perangkat boot yang persisten. Karena itu Oracle menyediakan driver dan tools kernel (AsmLib). Ini memungkinkan Anda na "label" partisi fisik sebagai root dan kemudian Anda dapat melihat label ini ketika mengelola penyimpanan database
• Investigasi masalah:
  • Ketika database lumpuh karena tidak dapat membuka lebih banyak file menangani 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 database tidak dapat mengalokasikan halaman besar, maka satu-satunya pilihan adalah me-reboot server.
  • (DCD) - deteksi koneksi mati. Misalnya pada AIX netstat tidak mencetak PID. Satu-satunya cara bagaimana memasangkan koneksi TCP dengan PID adalah debugger kernel.
  • sekilas (sesuatu seperti top pada HP-UX) membutuhkan root privs
  • berbagai investigasi tingkat Veritas
  • dan masih banyak lagi lainnya

Terserah Anda untuk memutuskan berapa banyak waktu yang akan Anda "buang" sampai masalah terselesaikan. Saya hanya ingin menunjukkan bahwa pemisahan peran yang kuat bisa sangat mahal dalam beberapa kasus. Jadi, bukannya meningkatkan "keamanan" fokus pada pengurangan risiko dan bahaya. Yang tidak sama. Alat-alat seperti ttysnoop atau mata-mata shell memungkinkan Anda untuk "merekam" seluruh sesi ssh, sehingga mereka memberikan penolakan. Ini bisa berfungsi lebih baik daripada sudo.

Saya seorang Oracle DBA dan jawaban saya adalah, biasanya DBA tidak memerlukan akses root. Tapi DBA RAC? jelas dia membutuhkan akses root untuk mengelola CRS, pemeliharaan rumah dan semuanya.

Pertanyaan ini berasal dari masa ketika sistem jauh lebih sederhana dan proses OS versus Database secara terpisah didefinisikan dan diidentifikasi. Administrasi Sistem dan Database Administrasi tugas dan tanggung jawab sangat berbeda. Dengan lingkungan TI saat ini dan khususnya, dengan Server Database saat ini, tugas dan tanggung jawab ini, lebih sering daripada tidak, cenderung tumpang tindih. Administrator Sistem melakukan due diligence untuk membatasi akses "root" sehubungan dengan "manajemen risiko".

Dengan tuntutan hari ini untuk "ketersediaan tinggi" dan "perbaikan segera" untuk masalah yang muncul dengan Sistem Database RAC kami, administrator Sistem dan Administrator Database melayani komunitas bisnis fungsional mereka, bekerja bersama sebagai sebuah tim. Seharusnya tidak ada kekhawatiran dengan "kepercayaan", karena kedua belah pihak memiliki kepentingan untuk menjaga Server Database RAC on-line dekat 100% dari waktu. Ingat, DBA sudah memiliki akses shell sebagai Administrator Database (dengan atau tanpa beberapa perintah yang dapat dijalankan melalui sudo; dengan atau tanpa chroot), jadi jelas DBA adalah agen "tepercaya". Jadi, pada kenyataannya pertanyaannya seharusnya, "Mengapa Oracle DBA tidak perlu akses?"

DBA hari ini telah mengambil tanggung jawab tambahan untuk server database, di mana Database Server adalah anggota dari Oracle Real Application Cluster (RAC) dan memanfaatkan Oracle Automatic Storage Management (ASMLIB) untuk menyajikan penyimpanan bersama di seluruh RAC Database (s). Manajemen RAC dan ASM oleh DBA mengurangi Administrator Sistem yang sudah terlalu banyak bekerja, yang seharusnya merupakan kontribusi yang disambut baik untuk Grup / Tim STS.

Dan, seperti yang dikatakan ibre5043, "... pemisahan peran yang kuat bisa sangat mahal adalah beberapa kasus. Jadi alih-alih meningkatkan" keamanan "fokus pada pengurangan risiko dan bahaya. Yang tidak sama. Alat seperti ttysnoop atau shell spy memungkinkan Anda untuk "merekam" seluruh sesi ssh, dengan demikian mereka memberikan hak yang tidak dapat disangkal. Ini bisa berfungsi lebih baik daripada sudo. " Anda juga harus bertanya siapa yang memantau SSA.

Jika server menggunakan perangkat lunak Oracle Grid Infrastructure seperti CRS, RAC atau Oracle Restart, maka banyak layanan database kritis dijalankan sebagai root, dan banyak file konfigurasi database kritis dimiliki oleh root. Ini adalah fitur desain yang melekat pada perangkat lunak. Jika ini merupakan pelanggaran terhadap kebijakan Anda, maka kebijakan tersebut perlu direvisi.

DBA akan membutuhkan akses root untuk mengelola fitur-fitur ini. Secara teoritis Anda bisa memintanya daftar perintah yang akan dijalankan untuk dimasukkan ke dalam Sudo, tetapi jawabannya akan menjadi daftar yang sangat panjang. Lihat saja $ GRID_HOME / bin untuk daftar semua binari yang mungkin digunakan DBA secara teratur. Jika mereka melakukan kegiatan menambal (yang seharusnya) maka daftar bisa menjadi lebih lama.

Saya baru saja mengirim pertanyaan serupa. Sebenarnya alasan seorang sysadmin tidak ingin memberikan hak istimewa root, adalah salah satu tanggung jawab dan akuntabilitas yang saya pikir.

Tetapi jika ini penyebabnya, DBA seharusnya juga menjadi satu-satunya sysadmin. Dan alasannya sederhana. Jika ada kebutuhan untuk pemisahan akuntabilitas dan tanggung jawab, sysadmin dapat SELALU menjadi DBA juga. Dia dapat menyamar sebagai akun oracle, dia dapat memasukkan database sebagai SYSDBA dan melakukan apa pun, tanpa perlu kata sandi SYS atau SYSTEM.

Jadi menurut saya, jika ada kebutuhan untuk pemisahan sysadmin dan DBA, karena akuntabilitas dan tanggung jawab, satu-satunya penyebab logis adalah bahwa server juga harus dikelola oleh DBA dan bukan sysadmin. Server dan database harus secara keseluruhan menjadi tanggung jawab DBA, yang juga harus memiliki pengetahuan administrasi sistem.

Jika server digunakan lebih dari sekadar hosting database, dan ada kebutuhan akan tanggung jawab dan akuntabilitas yang terpisah, ini berarti masalah. Tetapi jika server hanya digunakan untuk hosting database, maka saya tidak melihat alasan mengapa DBA tidak harus memiliki hak akses root, memperhitungkan banyak sekali kasus yang ia perlukan juga.

Secara pribadi saya akan mengajukan pertanyaan sebaliknya. Mengapa sysadmin memiliki hak akses root pada server database khusus? Bahkan, spesialisasinya akan diperlukan dalam kasus yang jauh lebih sedikit, dibandingkan dengan DBA (dengan hak istimewa root).

Akses root diperlukan untuk pemasangan dan penambalan jaringan Oracle. Tidak ada jalan lain. Jika ada cara untuk memberikan akses root sementara ke DBA untuk kebutuhan seperti itu, itu akan ideal.