Data sering kali memerlukan keamanan tingkat tinggi di hampir setiap tingkat transaksi data agar dapat memenuhi kebijakan keamanan, kepatuhan, dan peraturan pemerintah. Reputasi organisasi dapat rusak jika ada akses tidak sah ke data sensitif, sehingga gagal mematuhi mandat yang digariskan.
Dalam blog ini kita akan membahas beberapa langkah keamanan yang dapat Anda terapkan terkait dengan MongoDB, terutama berfokus pada sisi klien.
Skenario Di Mana Data Dapat Diakses
Ada beberapa cara seseorang dapat mengakses data MongoDB Anda, berikut beberapa di antaranya...
- Mengambil data melalui jaringan yang tidak aman. Seseorang dapat mengakses data Anda melalui API dengan jaringan VPN dan akan sulit untuk melacaknya. Data diam sering menjadi penyebab dalam kasus ini.
- Pengguna super seperti administrator yang memiliki akses langsung. Ini terjadi jika Anda gagal menentukan peran dan batasan pengguna.
- Memiliki akses ke data di disk saat membaca database file cadangan.
- Membaca memori server dan data yang dicatat.
- Pengungkapan data yang tidak disengaja oleh anggota staf.
Kategori Data MongoDB dan Cara Pengamanannya
Secara umum, setiap sistem database melibatkan dua jenis data:
- Data-at-rest :Yang disimpan dalam file database
- Data-in-transit:Data yang ditransaksikan antara klien, server, dan database.
MongoDB memiliki fitur Encryption at Rest yang mengenkripsi file database pada disk sehingga mencegah akses ke file database pada disk.
Data-in-transit melalui jaringan dapat diamankan di MongoDB melalui Enkripsi Transportasi menggunakan TLS/SSL dengan mengenkripsi data.
Dalam kasus data yang secara tidak sengaja diungkapkan oleh anggota staf misalnya resepsionis di layar desktop, MongoDB mengintegrasikan Kontrol Akses Berbasis Peran yang memungkinkan administrator untuk memberikan dan membatasi izin tingkat pengumpulan untuk pengguna.
Data yang ditransaksikan melalui server mungkin tetap berada di memori dan pendekatan ini sama sekali tidak mengatasi masalah keamanan terhadap akses data di memori server. Oleh karena itu, MongoDB memperkenalkan Enkripsi Tingkat Bidang Sisi Klien untuk mengenkripsi bidang tertentu dari dokumen yang melibatkan data rahasia.
Enkripsi Tingkat Bidang
MongoDB bekerja dengan dokumen yang memiliki bidang yang ditentukan. Beberapa bidang mungkin diperlukan untuk menyimpan informasi rahasia seperti nomor kartu kredit, nomor jaminan sosial, data diagnosis kesabaran, dan banyak lagi.
Enkripsi Tingkat Bidang akan memungkinkan kami mengamankan bidang dan bidang tersebut hanya dapat diakses oleh personel yang berwenang dengan kunci dekripsi.
Enkripsi dapat dilakukan dengan dua cara
- Menggunakan kunci rahasia. Sebuah kunci tunggal digunakan untuk enkripsi dan dekripsi karena itu harus disajikan di sumber dan tujuan transmisi tetapi dirahasiakan oleh semua pihak.
- Menggunakan kunci publik. Menggunakan sepasang kunci yang satu digunakan untuk mengenkripsi dan yang lainnya digunakan untuk mendekripsi
Saat menerapkan Enkripsi Tingkat Bidang, pertimbangkan untuk menggunakan penyiapan basis data baru daripada yang sudah ada.
Enkripsi Tingkat Bidang Sisi Klien (CSFLE)
Diperkenalkan di MongoDB versi 4.2 Enterprise untuk menawarkan administrator basis data dengan penyesuaian untuk mengenkripsi bidang yang melibatkan nilai yang perlu diamankan. Artinya, data sensitif dienkripsi atau didekripsi oleh klien dan hanya dikomunikasikan ke dan dari server dalam bentuk terenkripsi. Selain itu, bahkan pengguna super yang tidak memiliki kunci enkripsi, tidak akan memiliki kendali atas bidang data terenkripsi ini.
Cara Menerapkan CSFLE
Agar Anda dapat menerapkan Enkripsi Tingkat Bidang Sisi Klien, Anda memerlukan hal berikut:
- MongoDB Server 4.2 Enterprise
- MongoDB Kompatibel dengan CSFLE
- Izin Sistem File
- Driver bahasa tertentu. (Di blog kita, kita akan menggunakan Node.js)
Prosedur implementasi melibatkan:
- Lingkungan pengembangan lokal dengan perangkat lunak untuk menjalankan klien dan server
- Membuat dan memvalidasi kunci enkripsi.
- Mengonfigurasi klien untuk enkripsi tingkat bidang otomatis
- Sepanjang operasi dalam hal kueri bidang terenkripsi.
Implementasi CSFLE
CSFLE menggunakan strategi enkripsi amplop di mana kunci enkripsi data dienkripsi dengan kunci lain yang dikenal sebagai kunci master. Aplikasi Klien membuat kunci master yang disimpan di Penyedia Kunci Lokal pada dasarnya sistem file lokal. Namun, pendekatan penyimpanan ini tidak aman sehingga dalam produksi, disarankan untuk mengonfigurasi kunci dalam Sistem Manajemen Kunci (KMS) yang menyimpan dan mendekripsi kunci enkripsi data dari jarak jauh.
Setelah kunci enkripsi data dibuat, kunci tersebut disimpan dalam koleksi vault di replika MongoDB yang sama dengan data terenkripsi.
Buat Kunci Master
Dalam node js, kita perlu membuat kunci master yang dikelola secara lokal 96-byte dan menulisnya ke file di direktori tempat skrip utama dijalankan:
$npm install fs && npm install crypto
Kemudian di script:
const crypto = require(“crypto”)
const fs = require(“fs”)
try{
fs.writeFileSync(‘masterKey.txt’, crypto.randomBytes(96))
}catch(err){
throw err;
}
Buat Kunci Enkripsi Data
Kunci ini disimpan dalam kumpulan brankas kunci tempat klien yang mengaktifkan CSFLE dapat mengakses kunci untuk enkripsi/dekripsi. Untuk membuatnya, Anda memerlukan yang berikut ini:
- Kunci master yang dikelola secara lokal
- Koneksi ke database Anda, yaitu string koneksi MongoDB
- Ruang nama kubah kunci (basis data dan koleksi)
Langkah-Langkah Membuat Kunci Enkripsi Data
-
Baca pembuatan kunci master lokal sebelum
const localMasterKey = fs.readFileSync(‘./masterKey.txt’);
-
Tentukan setelan penyedia KMS yang akan digunakan oleh klien untuk menemukan kunci master.
const kmsProvider = {
local: {
key: localMasterKey
}
}
-
Membuat Kunci Enkripsi Data. Kita perlu membuat klien dengan string koneksi MongoDB dan konfigurasi namespace key vault. Katakanlah kita akan memiliki database yang disebut pengguna dan di dalamnya ada koleksi keyVault. Anda perlu menginstal uuid-base64 terlebih dahulu dengan menjalankan perintah
$ npm install uuid-base64
Kemudian di skrip Anda
const base64 = require('uuid-base64');
const keyVaultNamespace = 'users.keyVaul';
const client = new MongoClient('mongodb://localhost:27017', {
useNewUrlParser: true,
useUnifiedTopology: true,
});
async function createKey() {
try {
await client.connect();
const encryption = new ClientEncryption(client, {
keyVaultNamespace,
kmsProvider,
});
const key = await encryption.createDataKey('local');
const base64DataKeyId = key.toString('base64');
const uuidDataKeyId = base64.decode(base64DataKeyId);
console.log('DataKeyId [UUID]: ', uuidDataKeyId);
console.log('DataKeyId [base64]: ', base64DataKeyId);
} finally {
await client.close();
}
}
createKey();
Selanjutnya Anda akan disajikan beberapa hasil yang menyerupai
DataKeyId [UUID]: ad4d735a-44789-48bc-bb93-3c81c3c90824
DataKeyId [base64]: 4K13FkSZSLy7kwABP4HQyD==
Klien harus memiliki izin ReadWrite pada namespace key vault yang ditentukan
-
Untuk memverifikasi bahwa Kunci Enkripsi Data telah dibuat
const client = new MongoClient('mongodb://localhost:27017', {
useNewUrlParser: true,
useUnifiedTopology: true,
});
async function checkClient() {
try {
await client.connect();
const keyDB = client.db(users);
const keyColl = keyDB.collection(keyVault);
const query = {
_id: ‘4K13FkSZSLy7kwABP4HQyD==’,
};
const dataKey = await keyColl.findOne(query);
console.log(dataKey);
} finally {
await client.close();
}
}
checkClient();
Anda akan menerima beberapa hasil semacam itu
{
_id: Binary {
_bsontype: 'Binary',
sub_type: 4,
position: 2,
buffer: <Buffer 68 ca d2 10 16 5d 45 bf 9d 1d 44 d4 91 a6 92 44>
},
keyMaterial: Binary {
_bsontype: 'Binary',
sub_type: 0,
position: 20,
buffer: <Buffer f1 4a 9f bd aa ac c9 89 e9 b3 da 48 72 8e a8 62 97 2a 4a a0 d2 d4 2d a8 f0 74 9c 16 4d 2c 95 34 19 22 05 05 84 0e 41 42 12 1e e3 b5 f0 b1 c5 a8 37 b8 ... 110 more bytes>
},
creationDate: 2020-02-08T11:10:20.021Z,
updateDate: 2020-02-08T11:10:25.021Z,
status: 0,
masterKey: { provider: 'local' }
}
Data dokumen yang dikembalikan mencakup:id kunci enkripsi data (UUID), kunci enkripsi data dalam bentuk terenkripsi, informasi penyedia KMS kunci master dan metadata seperti hari kreasi.
Menentukan Bidang yang Akan Dienkripsi Menggunakan Skema JSON
Ekstensi JSON Schema digunakan oleh driver MongoDB untuk mengonfigurasi enkripsi dan dekripsi sisi klien otomatis dari bidang dokumen yang ditentukan dalam koleksi. Konfigurasi CSFLE untuk skema ini akan memerlukan:algoritme enkripsi yang digunakan saat mengenkripsi setiap bidang, satu atau semua kunci enkripsi yang dienkripsi dengan kunci master CSFLE dan Jenis BSON dari setiap bidang.
Namun, skema JSON CSFLE ini tidak mendukung validasi dokumen jika tidak, setiap instance validasi akan menyebabkan klien membuat kesalahan.
Klien yang tidak dikonfigurasi dengan Skema JSON sisi klien yang sesuai dapat dibatasi dari menulis data yang tidak dienkripsi ke bidang dengan menggunakan Skema JSON sisi server.
Terutama ada dua algoritme enkripsi:Acak dan deterministik.
Kami akan mendefinisikan beberapa kunci encryptMetadata di tingkat akar Skema JSON dan mengonfigurasinya dengan bidang yang akan dienkripsi dengan mendefinisikannya di bidang properti skema sehingga mereka akan dapat mewarisi kunci enkripsi ini .
{
"bsonType" : "object",
"encryptMetadata" : {
"keyId" : // keyId generated here
},
"properties": {
// field schemas here
}
}
Misalnya Anda ingin mengenkripsi bidang nomor rekening bank, Anda akan melakukan sesuatu seperti:
"bankAccountNumber": {
"encrypt": {
"bsonType": "int",
"algorithm": "AEAD_AES_256_CBC_HMAC_SHA_512-Deterministic"
}
}
Karena kardinalitas tinggi dan bidang dapat dikueri, kami menggunakan pendekatan deterministik. Kolom sensitif seperti golongan darah yang memiliki rencana kueri rendah dan kardinalitas rendah dapat dienkripsi menggunakan pendekatan acak.
Bidang array harus menggunakan enkripsi acak dengan CSFLE untuk meningkatkan enkripsi otomatis untuk semua elemen.
Aplikasi Mongocryptd
Diinstal di MongoDB Enterprise Service 4.2 dan yang lebih baru, ini adalah aplikasi enkripsi terpisah yang mengotomatiskan Enkripsi Tingkat Bidang Sisi-Klien. Setiap kali klien berkemampuan CSFLE dibuat, layanan ini secara otomatis dimulai secara default ke:
- Validasi instruksi enkripsi yang diuraikan dalam Skema JSON, deteksi bidang mana yang akan dienkripsi dalam operasi throughput.
- Mencegah operasi yang tidak didukung agar tidak dijalankan pada bidang terenkripsi.
Untuk menyisipkan data, kita akan melakukan kueri penyisipan normal dan dokumen yang dihasilkan akan memiliki contoh data di bawah terkait dengan bidang rekening bank.
{
…
"bankAccountNumber":"Ac+ZbPM+sk7gl7CJCcIzlRAQUJ+uo/0WhqX+KbTNdhqCszHucqXNiwqEUjkGlh7gK8pm2JhIs/P3//nkVP0dWu8pSs6TJnpfUwRjPfnI0TURzQ==",
…
}
Saat personel yang berwenang melakukan kueri, pengemudi akan mendekripsi data ini dan mengembalikannya dalam format yang dapat dibaca yaitu
{
…
"bankAccountNumber":43265436456456456756,
…
}
Catatan: Anda tidak dapat membuat kueri untuk dokumen di bidang yang dienkripsi secara acak kecuali Anda menggunakan bidang lain untuk menemukan dokumen yang berisi perkiraan data bidang yang dienkripsi secara acak.
Kesimpulan
Keamanan data harus dipertimbangkan di semua tingkatan sehubungan dengan satu saat istirahat dan transit. MongoDB Enterprise 4.2 Server menawarkan pengembang dengan jendela untuk mengenkripsi data dari sisi klien menggunakan Enkripsi Tingkat Bidang Sisi Klien sehingga mengamankan data dari penyedia host database dan akses jaringan yang tidak aman. CSFLE menggunakan enkripsi amplop di mana kunci utama digunakan untuk mengenkripsi kunci enkripsi data. Oleh karena itu, kunci master harus disimpan dengan aman menggunakan alat manajemen kunci seperti Sistem Manajemen Kunci.