Mengapa otentikasi OS dianggap keamanan yang buruk untuk database Oracle?

29

Oracle mencela otentikasi OS sesuai dengan Oracle Security Database Guide , yang mengatakan

Ketahuilah bahwa parameter REMOTE_OS_AUTHENT tidak digunakan lagi dalam Oracle Database 11g Release 1 (11.1), dan hanya disimpan untuk kompatibilitas ke belakang.

Selain itu, sebagian besar informasi dan alat keamanan menganggap otentikasi OS (eksternal) sebagai masalah keamanan. Saya mencoba memahami mengapa hal ini terjadi. Berikut ini beberapa kelebihan yang saya lihat dari otentikasi OS:

Tanpa OS Authentication aplikasi harus menyimpan kata sandi di berbagai aplikasi masing-masing dengan model keamanan dan kerentanan mereka sendiri.
Otentikasi domain sudah harus aman karena jika tidak maka keamanan database hanya memperlambat akses ke database, tetapi tidak dapat mencegahnya.
Pengguna yang hanya perlu mengingat satu kata sandi domain dapat dibuat untuk membuat kata sandi domain yang lebih aman lebih mudah daripada membuat kata sandi basis data yang lebih tidak aman karena jumlah basis data berbeda yang harus mereka hubungkan untuk meningkat.

oracle oracle-11g-r2 security

— Leigh Riffel
sumber

Di mana Anda melihat bahwa Oracle tidak lagi menggunakan otentikasi eksternal?

— Justin Cave

1

@Justin Cave Saya akan memperbarui pertanyaan dengan informasi itu.

— Leigh Riffel

2

Terima kasih atas pembaruannya. Namun, hanya untuk kejelasan, Oracle tidak mencela otentikasi eksternal, itu mencabut otentikasi eksternal jarak jauh yang umumnya jauh lebih tidak aman (seperti yang dibahas Gayus di bawah)

— Justin Cave

16

Pertimbangkan skenario berikut:

Ada pengguna Unix bernama gaiuspada server Oracle dengan otentikasi eksternal, jadi di Oracle ada pengguna yang sesuai disebut ops$gaius. Ketika masuk ke dalam shell, saya juga bisa login langsung ke skema Oracle saya, dan pekerjaan cron saya tidak perlu kata sandi tertanam dalam skrip juga.
Otentikasi OS jarak jauh diizinkan, dengan asumsi bahwa LAN 100% aman dan klien dapat dipercaya (sama seperti rlogin/ rshbiasanya diizinkan)
Seorang penyerang membawa laptopnya ke LAN dengan cara apa pun, tahu bahwa saya bekerja di sana, dan membuat pengguna lokal di laptop mereka dipanggil gaiusdan menjalankan SQL * Plus sebagai pengguna itu
Oracle melihat (yaitu OSUSERdalam V$SESSION) adalah gaiusdan mencatat bahwa pengguna jarak jauh sebagaiops$gaius

Itu tidak hanya laughably mudah untuk spoof, tapi mengenakan topi saya sinis ini, Oracle tidak dapat membuat lebih banyak uang menjual Anda mereka mewah single sign-on produk ... Yang dengan cara tidak memenuhi semua poin yang Anda meningkatkan sebagai keuntungan dari OS tingkat auth. Dua kata sandi yang lebih baik dari satu sama sekali palsu; kebanyakan orang akan tetap sama (tidak ada mekanisme di Oracle untuk mencegah hal ini).

Prinsip umum adalah bahwa sangat sulit untuk bertahan dalam perangkat lunak ketika penyerang memiliki akses fisik. Dan jangan pernah mempercayai klien.

— Gayus
sumber

2

Bahkan lebih buruk dari itu. Lihat orafaq's 'Mengapa $ OPS risiko keamanan di lingkungan klien / server?' (Mereka menyalahkan windows, tapi Anda benar, itu semua yang ada di jaringan)

— Joe

3

Bagaimana server berada pada faktor domain windows ke dalam ini? yaitu apakah penyerang harus bergabung dengan komputer mereka ke domain untuk memiliki akun yang menyertakan domain, atau bisakah penyerang mensimulasikan keberadaan domain tanpa benar-benar harus bergabung dengan komputer mereka?

— Leigh Riffel

Saya menduga itu ditulis pada awalnya ketika semua server adalah Unix dan semua desktop adalah Windows

— Gayus

3

@Leigh - Anda dapat membuat otentikasi OS jarak jauh lebih aman dengan klien Windows dengan mengatur OS_AUTHENT_PREFIX menjadi domain Windows tepercaya. Itu mengharuskan klien jarak jauh (atau tampaknya) berada di domain tepercaya itu. Itu secara substansial meningkatkan standar lebih dari "plug komputer ke port cadangan, tambahkan pengguna lokal, dan Anda berada di" serangan tetapi masih cukup bisa dikalahkan.

— Justin Cave

1

membandingkan dan kontras dengan apakah itu melakukan otentikasi AD / Kerberos yang sebenarnya, dan mengambil tiket dari pengguna dan memverifikasinya dengan KDC, yang saya kira adalah apa yang dilakukan SqlServer ketika diatur untuk menggunakan otentikasi Windows?

— araqnid

8

Ini meningkatkan titik kegagalan tunggal dan memperbesar permukaan risiko data Anda.

Penyerang yang mendapatkan akses ke sistem akan, dengan Otentikasi OS, memiliki akses ke database. Dengan memerlukan akses yang lebih aman ke database, penyerang potensial harus meningkatkan hak istimewa mereka pada sistem yang dikompromikan untuk mendapatkan akses root atau oracle, daripada pengguna mana pun.

Masalah ini adalah fungsi dari akses eksternal ke database. Jika tidak ada akses eksternal dan mesin sepenuhnya diamankan maka pertanyaan tentang perizinan diperdebatkan. Namun, jika pengembang memiliki akses, izin pengguna tingkat OS meningkatkan cakupan potensi bencana keamanan.

Pertimbangkan untuk menggunakan akses multitier untuk membatasi ruang lingkup pelanggaran keamanan dan memberikan akses kepada pengguna, aplikasi, atau klien apa pun yang mereka butuhkan tanpa perlu membuat akun tingkat OS untuk setiap contoh.

— Brian Ballsun-Stanton
sumber

Begitu ya, jadi terlalu sederhana - dua persyaratan nama pengguna / kata sandi lebih aman daripada satu -. Poin Anda terdengar masuk akal.

— Leigh Riffel

Ini adalah jawaban yang salah secara halus - masalahnya bukan otentikasi eksternal tetapi otentikasi eksternal jarak jauh . Saya akan jelaskan di bawah ini.

— Gayus

@ Gayus Bukankah otentikasi OS eksternal menjadi sangat terbatas hampir sampai tidak berharga jika tidak jauh? Apakah Anda mengatakan Oracle tidak mencela otentikasi menggunakan OS, tetapi hanya mencela otentikasi OS dari komputer jarak jauh?

— Leigh Riffel

@Leigh - Kasus penggunaan utama untuk otentikasi OS akun lokal adalah untuk tugas-tugas tipe DBA di mana Anda memiliki banyak skrip shell yang berjalan di server database yang perlu mengakses akun yang sangat kuat di server database. Otentikasi OS memungkinkan Anda menghindari kata sandi tingkat DBA yang tidak terenkripsi dalam skrip shell tersebut.

— Justin Cave

@Justin pekerjaan batch secara umum, diimplementasikan sebagai skrip shell atau apa pun, di crons individu

— Gayus

4

Gayus telah menunjukkan mengapa otentikasi sistem operasi jarak jauh (yang bertentangan dengan otentikasi sistem operasi vanilla di mana Anda mengizinkan pengguna mesin lokal untuk mengakses database tanpa menentukan kata sandi yang terpisah) relatif tidak aman.

Saya berharap bahwa Oracle bergerak ke arah ini karena ingin mendorong orang untuk menggunakan pengguna perusahaan (atau rangkaian manajemen identitas lengkap) daripada pengguna yang diautentikasi sistem operasi jarak jauh. Pengguna perusahaan memiliki keuntungan yang sama dengan pengguna yang diautentikasi sistem operasi jarak jauh tetapi Oracle benar-benar keluar dan memukul server Active Directory Anda untuk mengautentikasi pengguna. Anda mendapatkan manfaat tanda tunggal yang sama tanpa meninggalkan pemeriksaan keamanan ke mesin klien.

— Gua Justin
sumber

Otentikasi LDAP dapat membuka kaleng cacing lain ... Saya akan mengirim jawaban yang lebih panjang.

— Joe

+1 Terima kasih telah menunjukkan Keamanan Pengguna Perusahaan. Kami telah mempertimbangkan Keamanan Tingkat Lanjut dan ini membuatnya semakin menarik.

— Leigh Riffel

4

Anda secara khusus menunjuk ke otentikasi gaya-identifikasi, tetapi saya juga ingin menunjukkan bahwa metode lain mengikat database atau login lain ke login OS sama buruknya. (baik itu file kata sandi lokal, LDAP, atau apa pun untuk penyimpanan kredensial yang sebenarnya)

Jika Anda mengizinkan koneksi jarak jauh ke basis data (atau server web, atau apa pun yang melakukan otentikasi), beberapa OS akan mengabaikan aturan yang mungkin diatur untuk menyulitkan brute paksa akun (misalnya, memblokir IP di mana upaya gagal berasal; mengunci pengguna untuk periode setelah jumlah kesalahan yang ditetapkan, dll). Biasanya, aturan-aturan ini terikat sshd, dan bukan sistem otentikasi secara keseluruhan.

Jadi, jika seseorang dapat terhubung ke database / server web / apa pun dari jarak jauh, mereka dapat dengan kasar memaksa kata sandi, karena basis data tidak cenderung cenderung memiliki mekanisme yang sama untuk memperlambat upaya, kemudian ssh masuk begitu mereka menemukan kredensial yang diperlukan.

— Joe
sumber

2

Saya tidak yakin saya mengikuti alasannya di sini. Jika Anda memiliki Oracle otentikasi terhadap LDAP, Anda harus memecahkan LDAP untuk mendapatkan kata sandi - tidak akan ada salinan lokal hash kata sandi untuk brute force seperti akan ada untuk pengguna Oracle biasa. Jika Anda khawatir penyerang mengalahkan otentikasi LDAP Anda, Anda mungkin memiliki masalah lebih besar daripada bagaimana Anda mengautentikasi pengguna Oracle. Dan cukup mudah untuk mengonfigurasi Oracle untuk mengunci akun setelah sejumlah upaya gagal, membatasi alamat IP yang diizinkan, dll. Sebagian besar dari itu, pada kenyataannya, adalah perilaku default dalam 11g.

— Justin Cave

@Justin: ini hanya masalah jika Anda mengikatnya sehingga kredensial untuk masuk ke dalam OS sama dengan kredensial untuk masuk ke dalam basis data (atau server web, dll.). Dan sepertinya Oracle menjadi lebih baik tentang otentikasi daripada ketika saya terakhir kali menggunakannya, tetapi kebanyakan database lain belum. (dan Apache juga tidak, jadi pengguna MacOS X Server harus bertukar mod_auth_appledan mod_auth_digest_appleuntuk versi standar, meskipun saya belum menguji apakah masalahnya masih ada di 10.6)

— Joe