Prinsip Keamanan

Sebuah database produksi menyimpan data pelanggan, transaksi, dan rahasia bisnis — dan di internet selalu ada pihak yang mencoba membaca atau mengubah data itu tanpa izin. Keamanan MongoDB bukan satu tombol yang dinyalakan, melainkan gabungan kebiasaan desain yang saling menopang. Chapter ini meletakkan fondasi berpikirnya sebelum kita masuk ke perintah teknis di chapter-chapter berikutnya.

Peta materi Chapter ini:

• Tiga pilar keamanan: confidentiality, integrity, availability (CIA).
• Defense in depth: mengapa satu lapisan pertahanan tidak pernah cukup.
• Tiga ancaman paling sering menimpa deployment MongoDB.
• Ringkasan kewajiban pelindungan data pribadi di Indonesia (UU PDP).
• Daftar cek pola pikir sebelum menulis kode atau konfigurasi.

Tiga Pilar: Confidentiality, Integrity, Availability #

Kerangka CIA menjadi peta untuk menilai setiap keputusan keamanan. Setiap pilar mengajukan satu pertanyaan berbeda, dan MongoDB menyediakan alat yang berbeda pula untuk menjawabnya.

Confidentiality menjaga agar data hanya terbaca bagi pihak berhak — inilah alasan bab-bab berikutnya membahas user, password, dan role. Integrity memastikan perubahan hanya terjadi lewat jalur yang sah; pembatasan hak tulis dengan role dan validasi schema di Section Schema Validation melayani pilar ini. Availability menuntut sistem tetap hidup saat komponen gagal — replica set rs0 adalah jawaban arsitektur untuk pilar ketiga.

Defense in Depth #

Prinsip defense in depth berangkat dari asumsi pesimistis: setiap lapisan pertahanan bisa gagal, jadi jangan pernah bertumpu pada satu saja. Jika password kuat adalah satu-satunya pertahanan, satu password bocor berarti seluruh data terbuka. Lapisan yang saling menopang membuat satu kegagalan tidak langsung menjadi bencana.

Diagram di atas dibaca dari luar ke dalam: seorang penyerang harus menembus semua lapisan secara berurutan untuk sampai ke data. Tabel berikut memetakan setiap lapisan ke chapter yang membahasnya:

Tiga Ancaman yang Sering Terjadi #

Instance terbuka ke internet. Skenario paling klasik: mongod dijalankan dengan bindIp: 0.0.0.0 tanpa authentication aktif. Siapa pun yang menemukan port 27017 terbuka bisa terhubung dan membaca seluruh database. Pemindaian internet publik seperti Shodan secara rutin menemukan ribuan instance MongoDB terekspos akibat kombinasi ini.

Kredensial lemah dan menetap di kode. Password pendek, user admin yang dipakai aplikasi biasa, dan password yang ditulis langsung di source code memperpendek jalan seorang penyerang. Kredensial adalah data rahasia yang perlu diganti berkala, bukan konstanta.

Injection pada query. Input pengguna yang ditempel langsung ke filter bisa membentuk query yang tidak kita maksudkan — misalnya login form yang menerima {"$ne": null} sebagai username sehingga filter selalu cocok. Pencegahannya adalah validasi input dan query berparameter, dibahas penuh di Chapter Injection Attacks.

Memeriksa Postur Server Latihan #

Kita bisa mengaudit konfigurasi server latihan sendiri dengan dua perintah ringkas. Perintah pertama membaca konfigurasi yang sedang dipakai mongod:

const parsed = db.adminCommand({ getCmdLineOpts: 1 }).parsed
printjson({ net: parsed.net, security: parsed.security })

Output yang Dihasilkan:

{
  net: {
    bindIp: '127.0.0.1',
    port: 27017
  },
  security: undefined
}

Server hanya mendengarkan 127.0.0.1:27017 — lapisan jaringan sudah benar secara default. Field security bernilai undefined karena konfigurasi kita memang tidak memuat blok security: authorization sedang tidak aktif. Wajar untuk server latihan bersama, tetapi tidak untuk produksi.

Perintah kedua menanyakan identitas koneksi kita saat ini:

db.runCommand({ connectionStatus: 1 })

Output yang Dihasilkan:

{
  authInfo: { authenticatedUsers: [], authenticatedUserRoles: [] },
  uuid: UUID('6f4465bb-fbc6-4d4f-b910-903b185be97f'),
  ok: 1,
  '$clusterTime': {
    clusterTime: Timestamp({ t: 1792261353, i: 1 }),
    signature: {
      hash: Binary.createFromBase64('AAAAAAAAAAAAAAAAAAAAAAAAAAA=', 0),
      keyId: Long('0')
    }
  },
  operationTime: Timestamp({ t: 1792261353, i: 1 })
}

authenticatedUsers kosong — kita terhubung sebagai klien anonim dan tetap bisa berbuat apa pun karena authorization mati. Pada server produksi, koneksi tanpa identitas seperti ini harus ditolak sejak awal; itulah pekerjaan authentication yang kita bahas di chapter berikutnya.

Pelindungan Data Pribadi di Indonesia #

Indonesia memiliki payung hukum untuk data pribadi: Undang-Undang Nomor 27 Tahun 2022 tentang Pelindungan Data Pribadi (UU PDP), yang berlaku penuh sejak 17 Oktober 2024 setelah masa transisi dua tahun. Pesan praktisnya bagi kita sebagai pengembang: data pribadi pengguna (nama, email, nomor telepon) yang tersimpan di MongoDB adalah tanggung jawab kita untuk dilindungi, dan CIA bersama defense in depth adalah cara teknis memenuhinya. Detail hukumnya di luar cakupan course ini.

Daftar Cek Pola Pikir #

Sebelum menulis kode atau konfigurasi yang menyentuh data, lewati daftar ini sekali:

• Asumsikan server bisa dijangkau pihak lain, bahkan yang “hanya di jaringan internal”.
• Setiap koneksi punya identitas — tanpa operasi produksi dari klien anonim.
• Berikan hak minimum yang membuat pekerjaan selesai, bukan hak yang paling praktis.
• Data bergerak (jaringan) dan data diam (disk) sama-sama perlu perlindungan.
• Kredensial hidup di secret manager atau variabel lingkungan, bukan di source code.
• Jadwalkan audit user, role, dan konfigurasi secara berkala.

Rangkuman #

• CIA memetakan keamanan ke tiga pertanyaan: siapa boleh membaca, bagaimana data tidak berubah sembarangan, dan apakah data tetap tersedia.
• Defense in depth menumpuk lapisan jaringan, identitas, otorisasi, transport, dan penyimpanan.
• Tiga ancaman rutin: instance terekspos publik, kredensial lemah, dan injection pada query.
• UU PDP menjadikan pelindungan data pribadi kewajiban hukum di Indonesia; fondasi teknisnya tetap CIA dan defense in depth.
• getCmdLineOpts dan connectionStatus adalah dua perintah audit cepat untuk menilai postur server Anda.