SQLPLUS untuk user non DBA... Bisa koq...

Apa kabar sobat CommUNIXy ? Semoga sehat selalu ya...

Pada malam ini NgoprekUNIX mo berbagi pengalaman tentang SQLPLUS dari sisi AIX. Maksudnya apa sih ? Terkadang untuk alasan sekuriti, CommUNIXy membutuhkan user non DBA untuk mengakses SQLPLUS. Salah satu manfaatnya adalah untuk membatasi penggunaan user DBA (misalnya : oracle, ora10gas, ora9ias, db2, de el el). Nah lho... jadi bingung ya ? 

User DBA memang dipergunakan untuk kebutuhan akses data base, tapi mengapa harus dibatasi ? Konteks pembatasan disini adalah untuk meminimalisasikan terjadinya human error yang berdampak fatal pada konfigurasi atau justru data itu sendiri. User DBA adalah user dengan tingkat kesaktian tertinggi pada level data base sehingga otoritasnya sangat hebat. Alhasil, penyalahgunaan user ini berdampak serius pada keseluruhan operasional bisnis.

Bagi CommUNIXy yang telah menerapkan standar Quality and Risk Management yang canggih, penggunaan user DBA yang sangat sering menimbulkan potensi terjadinya kerusakan sistem sehingga diawasi sangat ketat. Sejatinya user-user sakti hanya digunakan pada kondisi khusus ketika tidak ada lagi user lain yang mampu melakukan tugas atau misi mulia tersebut. Jadi untuk urusan remeh temeh dan sering seperti kill process aplikasi yang hang harusnya cukup ditangani oleh user khusus dengan otoritas yang terbatas sebagaimana tupoksi (tugas pokok dan fungsi) nya hehehe... Kalau penasaran lanjutkan deh bacanya....

Untuk membuat user biasa memiliki kemampuan mengakses SQLPLUS, tidak sesederhana yang dibayangkan. Apalagi jika CommUNIXy dihadapkan dengan jebakan security policy yang super ketat. Misalnya, restriksi akses folder/file, restriksi otorisasi file dan restriksi service/port.  Tiga pilar inilah yang menurut NgoprekUNIX menjadi dasar-dasar dalam memahami mekanisme kerja dari hardening. Jika kita sepakat bahwa politics is the art of possible, maka heroism is the art of impossible. Nah, menjadi SysAdmin serupa tapi tak sama dengan menjadi seorang pahlawan. CommUNIXy harus mampu menemukan solusi dari dualisme antara restriksi security policy dan solusi best practice pada problematika sehari-hari (business as usual).

Kata kunci dari masalah ini adalah teknik ACL atau Access Control List. Ini adalah perpaduan antara restriksi akses folder/file dan restriksi otorisasi file. Jika CommUNIXy menggunakan teknik penggolongan user dan group saja, maka sangat sulit mengatasi solusi user kategori other yang spesifik diperlukan untuk akses atau eksekusi suatu file dalam rangkaian proses aplikasi. Jika teknik yang dilakukan hanyalah "chmod", maka hal yang serupa akan terjadi karena previlege hanya berlaku bagi user dan grup yang terlihat kasat mata saja.

Secara sederhana, berikut adalah folder (berikut sub folder) yang harus diberikan kepada user non DBA agar bisa mengakses SQLPLUS sebagaimana mestinya :

1. $ora_home/bin
2. $ora_home/dbs
3. $ora_home/lib
4. $ora_home/lib32
5. $ora_home/network/mesg
6. $ora_home/mesg 

dengan $ora_home adalah home dari oracle (atau data base instance lainnya).

Nah, kejutan yang ingin NgoprekUNIX sampaikan adalah ketika CommUNIXy mengalami eror yang tidak lazim seperti berikut :

Padahal CommUNIXy sudah memberikan akses sebagaimana mestinya pada user non DBA yangn diinginkan. Boleh jadi, metode yang sama pernah berhasil diaplikasikan pada server lainnya. Lantas apa solusi dari misteri ini ?

1.   Merupakan bug Oracle Bug 6973208 , sehingga harus dilakukan update Patch 6800649
2.   File system diaktifkan dengan mode nosuid

NgoprekUNIX hanya akan menerangkan kemungkinan yang kedua, yakni mode nosuid. Mode ini artinya adalah file system akan menonaktifkan semua fungsi suid atau set UID maupun GID pada folder/file yang ada padanya. Fungsi suid adalah previlege bagi user bukan pemilik untuk eksekusi sesuai dengan user pemilik (set UID) maupun grup pemilik (set GID). Dengan kata lain, user tertentu yang memiliki otoritas melakukan eksekusi pada file sebagaimana dilakukan oleh pemilik aslinya. Jika mode set GID dikenakan pada folder, maka semua file/folder yang terbentuk di dalamnya akan memiliki group yang sama dengan induknya.

Sebagai catatan, silakan perhatikan ilustrasi berikut :

Adapun solusi untuk masalah nosuid adalah :

    pastikan file system memiliki mode nosuid dengan koman "mount"
    hapus mode nosuid  dengan koman "chfs"

Demikianlah penjelasan singkat untuk studi kasus kali ini. Jika CommUNIXy memiliki pertanyaan seputar kasus ini silakan tinggalkan pesan. Semoga bermanfaat.

Salam NgoprekUNIX,