Antisipasi Kebocoran Data Medis: Standar Enkripsi Database RME

Antisipasi Kebocoran Data Medis: Standar Enkripsi Database RME

Sobat IT RS, pasti pernah ngalamin deg-degan pas dengar berita bocornya data pasien. Apalagi kalau ada yang bilang, “File rekam medis kita aman, kan?” Langsung keringat dingin. Data medis bukan cuma file PDF atau gambar hasil radiologi — jantungnya ya di database RME (Rekam Medis Elektronik). Di sinilah kita harus mikir: cukup backup doang, atau udah harus main enkripsi dan hashing?

Bocor data medis itu mimpi buruk. Bukan sekadar takut diomelin manajemen, tapi bisa kena jerat hukum (lihat UU PDP dan Permenkes 24/2022). Apalagi sekarang, BPJS, Kemenkes, sampai pasien makin kritis soal privasi. Makanya, antisipasi bukan cuma slogan. Sudah saatnya database RME di rumah sakit Sobat IT RS naik kelas: pakai enkripsi dan hash, bukan cuma firewall & backup.

Kenapa Data Medis RME Harus Di-enkripsi?

  • Data sangat sensitif: Nama, NIK, diagnosa, pengobatan, alergi — sekali bocor bisa dipakai buat pemerasan, penipuan, atau pencemaran nama baik.
  • Aturan makin ketat: Permenkes 24/2022, PP 71/2019, UU PDP: wajib jaga kerahasiaan dan integritas data pasien.
  • Serangan makin canggih: Hacker & malware sekarang bukan cuma iseng, tapi bisnis. Data medis = duit.
  • Akses internal juga riskan: Kadang bocor bukan dari luar, tapi dari staf/teknisi yang iseng atau lalai.

Jangan mikir, “Server sudah di-locked, sudah cukup.” Kalau ada backup bocor, restore di luar, atau dump database jatuh ke tangan salah, alamat habis! Enkripsi dan hash jadi sabuk pengaman kedua.

Praktik Standar: Transparent Data Encryption (TDE) & Hashing Field Sensitif

Ada dua level proteksi utama:

  1. Transparent Data Encryption (TDE): Enkripsi database file-level. Data di disk dan backup terenkripsi otomatis; aplikasi tetap akses data kayak biasa.
  2. Hashing Field Sensitif: Untuk data high risk (misal password, PIN, kode verifikasi), hash satu arah. Data asli nggak bisa dilihat siapa pun, bahkan admin DB.

Implementasi Transparent Data Encryption (TDE) di SQL Server

SQL Server (Standard/Enterprise, versi modern) sudah support TDE out-of-the-box. Konsep: data di disk (termasuk backup) selalu dalam bentuk terenkripsi, hanya bisa dibaca oleh SQL Server yang punya sertifikatnya.

Skema Kerja TDE

  • Setiap database punya Database Encryption Key (DEK).
  • DEK diamankan pakai sertifikat di master DB.
  • SQL Server otomatis enkripsi/dekripsi saat tulis/baca ke disk.
  • Aplikasi/SQL query tetap akses data seperti biasa.

Langkah Setting TDE (Staging, Bukan Produksi!)

-- 1. Buat master key di master DB
USE master;
CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'GantiPasswordKuat!';

-- 2. Buat certificate buat TDE
CREATE CERTIFICATE RME_TDE_Cert
    WITH SUBJECT = 'TDE for RME Database';

-- 3. Buat Database Encryption Key di DB target & aktifkan TDE
USE RME_DATABASE;
CREATE DATABASE ENCRYPTION KEY
    WITH ALGORITHM = AES_256
    ENCRYPTION BY SERVER CERTIFICATE RME_TDE_Cert;

ALTER DATABASE RME_DATABASE
    SET ENCRYPTION ON;

-- 4. Cek status TDE
SELECT db.name, db.is_encrypted
FROM sys.databases db
WHERE db.name = 'RME_DATABASE';
  • Jangan lupa backup certificate & private key! Kalau server crash & sertifikat hilang, database terenkripsi nggak bisa di-mount, data hangus.
-- Backup certificate (simpan baik-baik di tempat aman, bukan folder aplikasi!)
BACKUP CERTIFICATE RME_TDE_Cert
    TO FILE = 'D:\backup\RME_TDE_Cert.cer'
    WITH PRIVATE KEY (
        FILE = 'D:\backup\RME_TDE_Cert_privatekey.pvk',
        ENCRYPTION BY PASSWORD = 'GantiPasswordRahasia!'
    );

Pokok e, backup sertifikat diluar server utama. Minimal flashdisk, lebih baik offline vault. Sertifikat hilang = bencana.

Performa TDE?

  • Enkripsi disk-level, overhead performa kecil (biasanya <5-10%).
  • Aplikasi & query enggak perlu diubah.
  • Backup tetap aman, data tidak bisa dibaca di luar server tanpa sertifikat.
  • Yang tidak terenkripsi: data di memori/hasil query di layar, network traffic (pakai SSL/TLS buat proteksi di jaringan).

Implementasi Hashing di Field Sensitif: Password, PIN, OTP

Kalau TDE itu enkripsi file DB, hash itu buat field yang nilai aslinya tidak boleh bisa dipulihkan. Password, PIN, token verifikasi — semua wajib hash, bukan sekadar enkripsi.

Praktik Hashing di SIMRS (Contoh Password User)

  • Pakai algoritma hash kuat: bcrypt, PBKDF2, Argon2, minimal SHA-256 dengan salt (tapi SHA-256 saja sudah mulai dianggap kurang aman untuk password).
  • Jangan pernah simpan password plaintext atau hash tanpa salt!
Hash = fungsi satu arah. Tidak bisa di-reverse. Kalau ada bocor, attacker cuma dapat hash — itu pun harus brute force.

Contoh Struktur Tabel User (SQL Server)

CREATE TABLE [dbo].[users] (
    [id] INT IDENTITY(1,1) PRIMARY KEY,
    [username] VARCHAR(50) NOT NULL,
    [password_hash] VARCHAR(255) NOT NULL,
    [password_salt] VARCHAR(50) NOT NULL,
    [last_login] DATETIME NULL,
    [is_active] BIT NOT NULL DEFAULT 1
);

Hash Password di Backend (Contoh: Python)

import bcrypt

def hash_password(password):
    salt = bcrypt.gensalt()
    hashed = bcrypt.hashpw(password.encode('utf-8'), salt)
    return hashed, salt

def check_password(password, hashed):
    return bcrypt.checkpw(password.encode('utf-8'), hashed)
  • Simpan hasil hash di password_hash, salt (byte/hex) di password_salt.
  • Jangan pernah kirim password asli ke luar sistem, bahkan ke admin.
  • Validasi login: hash password input dengan salt, bandingkan hasil hash.

Hash Field Non-Password: Misal PIN, Token Reset, Kode OTP

  • Field apa pun yang bisa dipakai akses langsung (PIN CPPT, token reset password) wajib hash.
  • Prinsip sama: hash pakai salt unik per user/token.
  • Field yang tetap harus bisa dibaca (misal NIK, No RM) tidak di-hash, tapi mungkin bisa disamarkan/enkripsi field (lihat di bawah).

Perbandingan: TDE vs Field-Level Encryption/Hashing

Teknik Proteksi Apa? Kapan Pakai? TDE (Transparent Data Encryption) Proteksi data di file DB & backup Selalu aktif di server yang punya data sensitif; aplikasi tidak perlu ubah Hash field sensitif (password, PIN) Cegah recovery data asli jika DB bocor Untuk data yang tidak perlu dibaca ulang, hanya perlu diverifikasi Field-level encryption (misal, NIK, No HP di kolom tertentu) Data tetap bisa dibaca ulang (dengan kunci), lebih secure, tapi query/search jadi ribet Data yang harus tetap dibaca, tapi sangat sensitif dan rawan disalahgunakan

Studi Kasus Nyata: Kebocoran Backup DB, Data Aman Karena TDE

Skenario:
IT RS dapat laporan: backup nightly DB sempat di-copy ke folder publik internal, lalu didownload staf iseng. Panic! Tapi, karena DB sudah pakai TDE, file backup tidak bisa dibuka langsung. 

RESTORE DATABASE RME_DATABASE
FROM DISK = 'D:\leaked\rme_backup.bak';

-- Error: Cannot find server certificate with thumbprint...
  • Tanpa sertifikat, backup useless buat attacker.
  • Kalau backup plaintext? Fatal. Semua field bisa dibaca, password bisa dicrack hash-nya kalau lemah.

Tips Implementasi di Lapangan Buat Sobat IT RS

1. Audit & Mapping Data Sensitif

  • Identifikasi table & field mana yang harus dilindungi maksimal (password, PIN, data kontak, diagnosa, dsb).
  • Dokumentasikan: siapa saja yang boleh akses, lewat route mana (aplikasi, reporting, export manual, API, backup).

2. Nyalakan TDE di Semua DB Medis (Kalau Engine Support)

  • SQL Server: Enterprise/Standard Edition, mudah. Express tidak support TDE — upgrade atau pakai field-level encryption sebagai pengganti minimal.
  • PostgreSQL: Ada plugin eksternal (pgcrypto), native TDE mulai release 16 (2023) tapi belum widespread, cek rencana migrasi engine.
  • MySQL/MariaDB: Support InnoDB encryption, setup beda. Biasakan baca dokumentasi vendor DB yang dipakai.

3. Backup Sertifikat TDE di Tempat Aman

  • Jangan simpan di server produksi doang. Copy ke offline drive, simpan di brankas/kantor.
  • Jangan share password private key sembarangan.

4. Hash Semua Field Autentikasi

  • Password, PIN, OTP, token akses — semua hash pakai algoritma standar. Jangan pernah hash manual pakai MD5/SHA1 tanpa salt!
  • Untuk aplikasi lama, audit & migrasi bertahap. Bisa pakai mekanisme double hashing sampai semua reset password.

5. Enkripsi Field Khusus (Opsional, Kalau Butuh)

  • Misal: data kontak pasien, email, NIK — bisa pakai field-level encryption. Tapi hati-hati: search & reporting bisa ribet.
  • Contoh SQL Server: ENCRYPTBYKEY/DECRYPTBYKEY built-in, atau aplikasi handle sebelum insert/select.
-- Contoh field-level encryption SQL Server
-- 1. Buat symmetric key
CREATE SYMMETRIC KEY RME_Field_Key
    WITH ALGORITHM = AES_256
    ENCRYPTION BY PASSWORD = 'GantiPasswordFieldKuat!';

-- 2. Simpan data terenkripsi
OPEN SYMMETRIC KEY RME_Field_Key
    DECRYPTION BY PASSWORD = 'GantiPasswordFieldKuat!';

INSERT INTO pasien (nama, nik_encrypted)
VALUES (
    'Andi',
    ENCRYPTBYKEY(KEY_GUID('RME_Field_Key'), '3276xxxxxx')
);

-- 3. Baca data terenkripsi
SELECT nama,
    CONVERT(VARCHAR, DECRYPTBYKEY(nik_encrypted)) as nik
FROM pasien;
  • Enkripsi field bikin pencarian by NIK/No HP jadi lambat, bahkan impossible tanpa ekstraksi hash khusus.

6. Pastikan Jalur Network Juga Aman

  • TDE hanya proteksi disk/backup. Data yang nyebrang di network (aplikasi ke DB server) harus pakai SSL/TLS, apalagi kalau ada akses WAN/cloud.
  • Konfigurasi koneksi DB client: aktifkan Encrypt=True atau sslmode=require sesuai driver.

Pantauan & Uji Coba: Jangan Lupa!

  • Setelah setup TDE/hash, tes restore backup di server dummy tanpa sertifikat — pastikan data aman.
  • Audit periodik: cek field sensitif jangan sampe ada isian plaintext.
  • Simulasi insiden: bocor backup, bocor dump, bocor akses — cek seberapa jauh data bisa diambil attacker.
  • Log semua akses critical ke data sensitif, aktifkan audit trail di DB & aplikasi.

Kendala Umum di Lapangan (dan Cara Ngatasinnya)

  • DB Engine Tidak Support TDE?
    • SQL Server Express, beberapa engine lama: akali dengan field-level encryption/hash, atau upgrade engine kalau memungkinkan.
  • Developer Ga Paham Proteksi Data?
    • Kasih training singkat, kasih contoh kode hash/encrypt. Review code backend, audit semua proses input/output data sensitif.
  • Manajemen Takut Performa Drop?
    • TDE overhead kecil di hardware modern, kecuali DB gede banget. Benchmark dulu di staging, tunjukkan hasil ke manajemen.
  • Lupa Backup Certifikat?
    • Bikin SOP backup certifikat setiap kali setup/renew. Segera backup ke media offline.

Checklist Ringkas Enkripsi & Hashing Database RME

  • Audit: List semua field sensitif di database.
  • TDE aktif di semua DB medis (kalau engine support).
  • Hash semua password/PIN/token dengan salt & algoritma kuat.
  • Backup certifikat TDE ke media offline, aman dari akses umum.
  • Field-level encryption hanya untuk data sangat sensitif & tidak sering dipakai search/report.
  • Pakai koneksi secure (SSL/TLS) untuk semua akses DB dari aplikasi.
  • Lakukan audit berkala & tes insiden leak backup/dump.

Penutup: Jangan Sampe Keteteran Setelah Bocor

Sobat IT RS, sekali data medis bocor, nggak bisa balik. Setingan TDE dan hash kelihatan njlimet di awal, tapi bikin tidur lebih nyenyak. Jangan tunggu audit, surat teguran, atau headline media. Mulai cek, audit, dan aktifkan sekarang juga. Kalau perlu, kasih contoh ke manajemen: simulasikan restore backup tanpa sertifikat — baru deh mereka paham pentingnya. Data pasien = tanggung jawab kita semua!