Tingkat Ketidakamanan MongoDB dan Cara Menghindarinya

Sebagian besar sistem manajemen basis data memiliki beberapa teknik untuk mengamankan datanya dari pihak luar atau orang atau aplikasi yang tidak berwenang. Teknik tersebut mencegah data Anda dibaca atau disalin tanpa izin pengguna.

MongoDB tidak berbeda karena memiliki beberapa tingkat ketidakamanan. Dalam posting blog ini, kita akan membahas tingkat ketidakamanan di MongoDB dan cara menghindarinya sehingga Anda dapat melindungi instalasi MongoDB Anda.

Untuk keselamatan dan keamanan MongoDB Anda, berikut ini adalah beberapa langkah keamanan utama yang harus dipertimbangkan secara ketat:

Otentikasi koneksi pengguna.
Otorisasi/ Kontrol akses Berbasis Peran.
Enkripsi Jaringan/ Enkripsi Transportasi.
Enkripsi Penyimpanan/ Enkripsi-at-rest.
Audit.

Dalam artikel ini, kita akan melihat langkah-langkah keamanan di atas secara mendetail, dengan banyak fokus pada Otentikasi dan Otorisasi.

Otentikasi dan Otorisasi

Otentikasi dan Otorisasi harus diaktifkan secara bersamaan. Namun, mereka dapat digunakan secara independen satu sama lain. Otentikasi mencegah akses ke orang yang tidak dikenal yang memiliki akses jaringan ke server database untuk menyalin atau merusak data database. Otentikasi mengharuskan semua klien dan server untuk memberikan kredensial yang valid sebelum mereka dapat terhubung ke sistem. Otorisasi di sisi lain, mencegah aplikasi atau pengguna membaca, mengubah, atau menghapus data selain dari yang seharusnya.

Untuk mengonfigurasi kontrol akses Berbasis Peran;

Buat administrator pengguna terlebih dahulu.
Buat pengguna tambahan.
Kemudian buat pengguna MongoDB unik untuk setiap orang/aplikasi yang mengakses sistem.
Dengan mengikuti prinsip hak istimewa terkecil, Anda harus membuat peran yang menentukan hak akses tepat yang dibutuhkan oleh satu set pengguna.
Kemudian tetapkan pengguna hanya peran yang perlu mereka lakukan dalam operasi mereka. Seorang pengguna dapat berupa aplikasi klien atau seseorang.

Anda harus mencatat bahwa pengguna dapat memiliki hak istimewa di berbagai atau beberapa database. Dalam skenario tersebut, daripada membuat pengguna beberapa kali di database yang berbeda, buat satu pengguna dengan peran yang memberikan hak istimewa database yang berlaku.

Lebih sering daripada tidak, kedua tindakan keamanan ini mungkin disalahartikan sebagai hal yang sama. Dalam beberapa skenario, mereka mirip satu sama lain, tetapi mereka juga berbeda.

Kesamaan antara Otentikasi dan Otorisasi

Keduanya merupakan satu kesatuan karena, saat Anda mengaktifkan Otentikasi, Otorisasi diaktifkan secara otomatis. Otorisasi diaktifkan bersamaan dengan Otentikasi sehingga koneksi dari pengguna yang tidak dikenal tidak akan memiliki hak istimewa untuk mengakses data database. Otorisasi juga mengharuskan nama pengguna diverifikasi oleh Otentikasi untuk mengetahui hak istimewa mana yang berlaku untuk permintaan koneksi. Oleh karena itu, ini juga tidak dapat diaktifkan secara independen ke yang lain.
Keduanya juga mirip dalam penamaan warisan opsi konfigurasi yang disayangkan. Opsi file konfigurasi untuk otentikasi adalah security.authorization alih-alih otentikasi keamanan seperti yang diharapkan. Saat Anda menggunakan perintah, Otentikasi adalah yang pertama diaktifkan dan Otorisasi hanya diaktifkan sebagai efek samping. “-auth” adalah argumen baris perintah untuk mengaktifkan otentikasi yang secara otomatis memaksa otorisasi untuk diaktifkan juga.

Perbedaan antara Otentikasi dan Otorisasi

Keduanya berbeda karena merupakan dua bagian dari perangkat lunak yang memiliki fungsi berbeda.

Otentikasi ==Identitas pengguna, melalui pemeriksaan kredensial.

Otorisasi ==Menetapkan dan menerapkan objek DB dan izin perintah DB.

Selama penyiapan awal, Otentikasi dinonaktifkan untuk koneksi localhost. Ini singkat meskipun saat Anda mendapatkan satu kesempatan untuk membuat pengguna pertama, maka pengecualian ( untuk Otentikasi dan Otorisasi pada aturan bersama) hak istimewa dijatuhkan.

Cara Memeriksa apakah Otentikasi dan Otorisasi Diaktifkan atau Tidak

Versi pertama MongoDB memiliki "- auth" yang disetel secara default dan ini secara luas dianggap sebagai langkah yang buruk. Bahkan di versi 4.0 itu masih mati secara default. Konfigurasi kosong masih sama dengan menonaktifkan otorisasi meskipun ada peringatan startup dan berbagai pengurangan eksposur seperti localhost menjadi satu-satunya perangkat jaringan terikat default di MongoDB v3.6.

Anda tidak menggunakan Otentikasi atau lebih tepatnya Anda tidak mengaktifkan Otentikasi jika file konfigurasi mongod tidak:

Setel security.authorization ke 'diaktifkan.'
Sertakan security.keyfile.
Sertakan setelan security.clusterAuthMode yang memaksa autentikasi diaktifkan.

Untuk memeriksa ulang apakah autentikasi dan Otorisasi diaktifkan atau tidak, Anda dapat mencoba mongo shell one-liner cepat ini (tanpa argumen kredensial pengguna yang disetel):

mongo --host : --quiet --eval 'db.adminCommand({listDatabases:1})'

Tanggapan yang seharusnya Anda dapatkan adalah kesalahan "tidak sah". Namun, di sisi lain, jika Anda mendapatkan daftar nama database, maka secara otomatis itu berarti Anda memiliki penerapan MongoDB yang telanjang.

Otentikasi Eksternal

Seperti namanya, otentikasi eksternal adalah tentang mengizinkan pengguna untuk diautentikasi dalam layanan eksternal. Sebagai pengecualian, ini tidak dapat digunakan untuk pengguna sistem __ mongodb internal, tetapi menggunakannya untuk pengguna manusia nyata atau akun layanan aplikasi klien sangat cocok.

Sederhananya, layanan auth eksternal akan menjadi Kerberos KDC, atau server ActiveDirectory atau OpenLDAP. Anda harus mencatat bahwa menggunakan otentikasi eksternal tidak mencegah Anda memiliki akun pengguna MongoDB biasa pada saat yang bersamaan.

Otentikasi Internal

Sebaliknya, otentikasi internal MongoDB tidak berarti kebalikan dari otentikasi eksternal. Ini karena node mongod yang berjalan dengan otentikasi diaktifkan tidak akan percaya bahwa rekan TCP mana pun adalah node mongod atau mongos lain hanya karena berkomunikasi seperti itu. Sebaliknya, itu mengharuskan rekan mengautentikasi dengan bukti rahasia bersama.

Ada dua jenis mekanisme otentikasi internal di MongoDB:

Otentikasi internal file kunci.
SCRAM atau autentikasi internal x.509.

Otentikasi Internal File Kunci

Ini adalah mekanisme otentikasi internal default di MongoDB. Istilah "Kunci" menunjukkan kunci enkripsi asimetris tetapi dalam arti sebenarnya itu hanya kata sandi tidak peduli bagaimana Anda membuatnya. Keyfile disimpan dalam file identik yang didistribusikan ke setiap node mongod dan mongos di cluster. Dalam skenario kata sandi berhasil digunakan, simpul mongod akan mengizinkan perintah yang datang dari rekan yang diautentikasi untuk dijalankan sebagai pengguna super “_ _ sistem”.

Jika seseorang memiliki salinan file kunci, mereka cukup menghapus karakter kontrol dan non-cetak dari file kunci untuk membuat string kata sandi yang memungkinkan mereka terhubung sebagai pengguna “_ _ sistem”.

Namun, jika itu terjadi dan Anda menjalankan perintah di bawah ini sebagai pengguna mongod (atau root) di salah satu server MongoDB Anda dan berhasil, Anda tidak perlu khawatir karena tidak akan ada hak istimewa baca yang bocor secara tidak sengaja . Ini karena mongod akan dibatalkan saat startup jika keyfile berada dalam mode izin file selain 400 (atau 600).

mongo --authenticationDatabase local -u __system -p "$(tr -d '\011-\015\040' < /path/to/keyfile)"

Namun, secara tidak sengaja menyimpan file kunci di kontrol sumber yang dapat dibaca dunia memungkinkan pengguna yang bukan DBA (atau admin server dengan root) untuk membaca salinan file kunci. Ini dianggap sebagai kegagalan keamanan.

Risiko ekstrem meningkat saat file kunci didistribusikan dengan node mongos yang dimiliki dan dijalankan sebagai salah satu pengguna unix tim aplikasi alih-alih “mongod” atau pengguna unix milik tim DBA lainnya.

SCRAM atau Otentikasi Internal x.509

Mekanisme autentikasi internal x.509 sebenarnya menggunakan kunci pribadi atau publik asimetris dan harus digunakan bersama dengan TLS/SSL. Mekanisme ini dapat digunakan untuk koneksi klien serta autentikasi internal.

Mekanisme x.509 atau SCRAM memiliki keunggulan dibandingkan mekanisme Keyfile karena dalam mekanisme x.509, kecil kemungkinan salah satu kunci yang disebarkan dengan node mongod dan mongos dapat disalahgunakan oleh penyusup yang mendapat salinannya. Namun, ini tergantung pada seberapa ketat sertifikat x.509 disiapkan. Untuk menikmati keamanan maksimum dari mekanisme ini, Anda harus memiliki tim keamanan khusus yang memahami konsep dan praktik terbaik x.509. Praktik terbaik ini termasuk memperketat host mana yang akan digunakannya, dan dapat mencabut dan mengembalikan sertifikat.

Enkripsi Jaringan/ Enkripsi Transportasi

Enkripsi jaringan mencegah seseorang menyalin data yang sedang ditransfer melalui tautan jaringan di suatu tempat antara dua server. Enkripsi jaringan memerlukan sedikit atau tanpa pemikiran saat memutuskan apakah akan menggunakannya karena sangat penting. Tetapi jika, misalnya, klaster MongoDB Anda dan semua kliennya berada di dalam jaringan pribadi virtual yang Anda yakini tidak memiliki lubang di firewallnya dan tidak ada risiko eskalasi hak istimewa dari aplikasi lain, maka Anda tidak memerlukan enkripsi jaringan.

Untuk enkripsi jaringan, Anda harus mengonfigurasi MongoDB untuk menggunakan TLS/SSL untuk semua koneksi keluar dan masuk. Enkripsi komunikasi antara komponen mongod dan mongos dari penerapan MOngoDB serta antara semua aplikasi dan MongoDB menggunakan TLS/SSL.

Mulai dari versi 4.0; MongoDB menonaktifkan dukungan untuk enkripsi TLS 1.0 pada sistem yang menyediakan TLS 1.1+ dan juga menggunakan pustaka TLS/SSL asli berikut:

Windows - Saluran Aman (Schannel).
Linux/BSD - OpenSSL.
macOS - Transportasi Aman.

Batasi Eksposur Jaringan

Anda harus memastikan bahwa MongoDB berjalan di lingkungan jaringan tepercaya dan juga mengonfigurasi firewall atau grup keamanan untuk mengontrol lalu lintas masuk dan keluar untuk instans MongoDB Anda. Lebih dari itu, konfigurasikan untuk hanya mengizinkan klien tepercaya untuk mengakses antarmuka jaringan dan port tempat instans MongoDB tersedia. Misalnya, gunakan daftar putih IP untuk mengizinkan akses dari alamat IP tepercaya.

Jalankan MongoDB dengan Opsi Konfigurasi Aman

MongoDB mendukung kode JavaScript eksekusi untuk operasi sisi server berikut:

mapReduce.
$where.
$accumulator.
$fungsi.

Gunakan opsi -- noscripting pada baris perintah untuk menonaktifkan skrip sisi server jika Anda tidak menggunakan operasi di atas. Tetap aktifkan validasi input meskipun MongoDB mengaktifkan validasi input secara default melalui pengaturan net.wireObjectCheck. Ini memastikan bahwa semua dokumen yang disimpan oleh instance mongod adalah BSON yang valid.

Enkripsi Penyimpanan MongoDB/ Encryption-at-rest

Enkripsi penyimpanan mencegah seseorang mendapatkan salinan file database yang mendasarinya. Ini mungkin terjadi ketika seseorang membobol pusat data Anda dan mencuri hard disk server Anda. Data MongoDB mencakup file data, file konfigurasi, log audit, dan file kunci.

Mulai dengan MongoDB Enterprise 3.2, Anda dapat mengenkripsi data di lapisan penyimpanan dengan Encryption-at-rest bawaan mesin penyimpanan WiredTiger. Data MongoDB harus dienkripsi pada setiap host menggunakan sistem file, perangkat, atau enkripsi fisik saat tidak menggunakan enkripsi diam WiredTiger. Selain itu, Anda harus mengumpulkan log ke penyimpanan log pusat karena log ini berisi upaya autentikasi DB termasuk alamat IP sumber. Namun, enkripsi penyimpanan memiliki sedikit biaya kinerja.

Audit

Audit membantu melacak pengguna basis data yang tahu cara menutupi jejak mereka setelah mengubah atau mengubah data basis data. Pada dasarnya, audit melacak akses dan perubahan pada konfigurasi database dan data. MongoDB Enterprise memiliki fasilitas sistem audit yang dapat merekam peristiwa sistem seperti operasi pengguna dan peristiwa koneksi pada instance MongoDB.

Catatan audit ini membantu dalam analisis forensik dan memungkinkan administrator untuk memverifikasi kontrol yang tepat. Audit memiliki nilai tinggi bagi beberapa pengguna tetapi hanya dapat dilakukan jika risiko tertentu lainnya dihilangkan. Misalnya, penyerang tidak dapat memperoleh akses root Unix di server saat menjalankan node mongod langsung.

Melangkah Maju

Anda dapat menyiapkan filter untuk merekam peristiwa tertentu seperti peristiwa autentikasi. Tapi hati-hati karena ketika filter audit dibuat terlalu luas, kinerjanya akan cepat tersedak yang menyebabkan biaya kinerja tinggi. Meskipun, jika audit digunakan dengan tepat, tidak akan ada banyak biaya kinerja.