Database Access

Cluster Atlas yang baru dibuat menolak semua koneksi sampai ada database user yang sah. User ini berbeda dari akun Atlas yang kita pakai untuk login ke panel: database user adalah identitas yang dipakai mongosh, Compass, dan driver aplikasi untuk melakukan autentikasi. Chapter ini membahas cara membuat user, memilih role yang tepat, memeriksa isi role langsung dari mongosh, hingga kebiasaan rotasi kata sandi yang sehat untuk produksi.

Membuat Database User #

Menu Database Access di sisi kiri project menampilkan seluruh database user. Tombol + Add New Database User membuka formulir dengan tiga bagian:

1. Authentication — pilih Password (SCRAM), metode paling umum.
2. Password — gunakan tautan Autogenerate Password agar Atlas membuatkan kata sandi panjang dan acak, atau ketik sendiri (kata sandi kustom harus lolos kebijakan kompleksitas). Simpan hasil autogenerate sekarang karena hanya sekali ditampilkan.
3. Built-in Roles — pilih role dan, bila perlu, database tujuannya.

Beri nama yang menjelaskan pemakainya, misalnya app-tokobuku untuk aplikasi utama. Satu user per aplikasi mempermudah pencabutan akses ketika satu layanan dihentikan. Langkah yang sama bisa dilakukan lewat Atlas CLI:

atlas dbusers create \
  --username app-tokobuku \
  --password YOUR_PASSWORD \
  --role "readWrite@tokobuku" \
  --projectId PROJECT_ID_ANDA

Format role@database pada flag --role menunjukkan role bawaan beserta cakupan database-nya. Setelah user dibuat, mongosh dapat terhubung dengan opsi --username dan --authenticationDatabase "admin" — Atlas menyimpan seluruh database user pada database admin.

Role Bawaan Atlas #

Atlas menyediakan role bawaan yang sama dengan MongoDB Server, ditambah beberapa nama khusus Atlas. Pilihan yang paling sering dipakai:

Prinsip hak minimum dari Chapter Least Privilege berlaku lugas di sini: aplikasi cukup memakai readWrite pada satu database-nya, panel dashboard internal cukup read, dan hanya manusia (atau tool khusus) yang membutuhkan role yang lebih luas.

Role bawaan tidak bisa diubah isinya — kita buktikan langsung pada server latihan:

use latihan_dbaccess

Output yang Dihasilkan:

switched to db latihan_dbaccess

printjson(db.getRole("readWrite", { showPrivileges: false }))

Output yang Dihasilkan:

{
  db: 'latihan_dbaccess',
  role: 'readWrite',
  roles: [],
  inheritedRoles: [],
  isBuiltin: true
}

Field isBuiltin: true menandakan bahwa definisi readWrite dibakukan oleh server, bukan rakitan kita. Meski isinya tetap, kita tetap bisa memeriksa daftar aksi yang menyertainya:

const rw = db.getRole("readWrite", { showPrivileges: true })
const aksi = rw.privileges.find(p => p.resource.collection === "")
printjson({ cakupan: rw.db, jumlahAksi: aksi.actions.length, contoh: aksi.actions.slice(0, 6) })

Output yang Dihasilkan:

{
  cakupan: 'latihan_dbaccess',
  jumlahAksi: 25,
  contoh: [
    'changeStream',
    'cleanupStructuredEncryptionData',
    'collStats',
    'compactStructuredEncryptionData',
    'convertToCapped',
    'createCollection'
  ]
}

Objek privileges berisi pasangan resource dan actions: baris kedua kode di atas mengambil privilege yang cakupannya seluruh collection pada database aktif, lalu menampilkan enam dari 25 aksinya. Terlihat jelas bahwa readWrite mencakup insert, update, remove, hingga createCollection — lebih dari cukup untuk kebutuhan CRUD aplikasi.

Custom Role dan Metode Autentikasi Lain #

Bila tidak ada role bawaan yang pas, menu Custom Roles memungkinkan kita merakit role dari aksi granular — misalnya hanya insert dan find tanpa remove, untuk layanan yang sekadar mencatat event. Mekanisme custom role ini identik dengan createRole pada MongoDB Server yang dibahas di Chapter *Role-Based Access Control`.

SCRAM bukan satu-satunya metode. Atlas juga mendukung autentikasi X.509 memakai sertifikat klien (cocok untuk koneksi server-ke-server) serta Workload Identity Federation yang memetakan AWS IAM role, Azure Managed Identity, atau Google Service Account menjadi database user — aplikasi di cloud bisa mengautentikasi tanpa menyimpan kata sandi sama sekali. Keduanya diatur dari formulir yang sama pada bagian Authentication.

Mengedit User dan Rotasi Kata Sandi #

Menu titik tiga di baris user membuka Edit dan Delete. Pengeditan role berlaku untuk koneksi baru; koneksi lama yang masih hidup sebaiknya ditutup agar perubahan segera terasa. Penghapusan user adalah cara bersih mencabut akses ketika aplikasi dinonaktifkan.

Rotasi kata sandi dilakukan lewat Edit → Edit Password pada UI, atau lewat CLI:

atlas dbusers update app-tokobuku --password YOUR_NEW_PASSWORD --projectId PROJECT_ID_ANDA

Setelah rotasi, perbarui nilai di environment variable aplikasi lalu lakukan rolling restart. Jadwalkan rotasi berkala (misalnya tiap kuartal) dan lakukan segera ketika ada anggota tim yang keluar atau indikasi kredensial bocor — kebiasaan yang sama berlaku untuk seluruh rahasia aplikasi seperti dibahas pada Chapter Credential Management.

Rangkuman #

• Database user dibuat per aplikasi lewat menu Database Access atau atlas dbusers create; gunakan Autogenerate Password dan simpan sekali tampil.
• Pilih role paling kecil yang cukup: readWrite@tokobuku untuk aplikasi, read untuk pelaporan, clusterMonitor untuk alat pantau.
• Role bawaan bersifat tetap (isBuiltin: true) dengan 25 aksi untuk readWrite — bisa diperiksa lewat db.getRole() kapan pun.
• Custom role menggabungkan aksi granular; X.509 dan Workload Identity Federation menggantikan kata sandi untuk skenario machine-to-machine.
• Rotasi kata sandi via UI atau atlas dbusers update, diikuti pembaruan environment variable dan rolling restart.