Sobat IT RS, pernah nggak ngalamin momen kayak gini: jam 2 subuh HP bunyi, kepala ruangan nelpon karena SIMRS lemot parah. Besoknya deadline klaim BPJS, eh server malah down pas jam 8 pagi. Kalau kamu pernah, selamat, kamu emang beneran IT RS. Tapi serius, dari sekian banyak masalah harian kita, ada satu hal yang kalau sampai meledak bisa bikin seluruh pekerjaan berhenti: keamanan data.

Data RS itu bukan cuma tabel di database. Itu nyawa operasional: rekam medis, data klaim, data SDM, sampai konfigurasi sistem. Sekali bocor, bukan cuma kena denda, tapi kepercayaan pasien dan akreditasi ikut taruhannya. Artikel ini nggak ngebahas teori muluk yang nggak kepake di lapangan. Ini catatan pengalaman ngurus SIMRS, jaringan, server, sampai persiapan MRMIK, lengkap dengan contoh teknis yang bisa langsung kamu contek.

1. Kontrol Akses Berbasis Peran: Jangan Semua Orang Bisa Lihat Semua

Pernah lihat perawat buka data pasien poli lain cuma karena iseng? Atau vendor SIMRS kasih satu akun admin tapi dipakai semua orang, termasuk tukang bersih-bersih ruangan server? Itu tanda RBAC-mu bolong. Konsepnya simpel: setiap user cuma dapat akses sesuai peran, nggak lebih. Prinsipnya dikenal dengan istilah least privilege, dan ini bukan cuma jargon buat laporan akreditasi, tapi penyelamat saat ada dugaan kebocoran.

Di aplikasi, minimal kamu harus punya relasi peran-hak akses yang rapi. Struktur tabelnya kira-kira kayak gini:

CREATE TABLE role_permission (
    role_id        INT NOT NULL,
    permission_id  INT NOT NULL,
    PRIMARY KEY (role_id, permission_id),
    FOREIGN KEY (role_id)       REFERENCES roles(id),
    FOREIGN KEY (permission_id) REFERENCES permissions(id)
);

Kenapa ini penting? Tiga alasan:

  • Kalau ada dugaan kebocoran atau komplain pasien, kamu tinggal tarik siapa aja yang punya akses ke data itu. Nggak perlu nebak-nebak.
  • Rotasi pegawai jadi gampang: pindah peran, tinggal ganti role_id, semua hak ikut berubah. Pegawai keluar, langsung cabut aksesnya.
  • Buat audit MRMIK, dokumentasi hak akses yang jelas jadi nilai plus yang dihargai surveyor.

Mulai dari yang gampang: audit semua akun aktif, matikan akun yang nganggur, dan jangan pernah sharing akun admin. Bikin darah tinggi emang kalau dapet temuan akun vendor yang masih aktif padahal kontraknya udah selesai, tapi itu justru yang paling sering jadi celah.

2. Wajibkan 2FA, Mulai dari Akun Admin

Password doang udah nggak zamannya. Seringnya akun kebobol bukan karena serangan canggih, tapi karena phishing atau akun yang dipinjam-pinjam antar staf. Autentikasi dua faktor (2FA) itu tembok pertama yang murah dan efektif buat ngeblokir sebagian besar serangan otomatis.

  • Mulai dari TOTP pakai Google Authenticator, Aegis, atau aplikasi autentikator lain yang gratis.
  • Akun admin SIMRS dan akses ke server naikkan ke hardware security key kalau budget ngizinin.
  • Akses remote dari luar jaringan rumah sakit juga wajib 2FA, karena ini titik paling rawan.
  • Atur kebijakan pemulihan akun: siapa yang berhak reset password, gimana identitas dikonfirmasi, dan kapan akun dinonaktifkan sementara kalau dicurigai kena kompromi.

Percaya deh, 5 menit setup 2FA jauh lebih murah daripada seminggu begadang nanganin akun admin yang dibobol. Dan jangan cuma diaktifin, tapi pastiin staf beneran pakai — bukan nyimpen kode OTP di sticky note di monitor.

3. Enkripsi: Saat Jalan dan Saat Parkir

Data harus dienkripsi di dua titik: waktu dikirim antar sistem (transit) dan waktu disimpan di database atau backup (at rest).

  • Semua layanan yang diakses publik wajib HTTPS. Matikan HTTP polos dan TLS versi jadul yang celahnya udah umum diketahui.
  • Database dan file backup wajib dienkripsi. Kalau hard disk atau tape backup jatuh ke tangan yang salah, isinya nggak kebaca tanpa kunci.
  • Kunci enkripsi simpan terpisah dari data, misalnya di vault khusus, dan rotasi berkala.

Cek cepat apakah layanan kamu masih ada yang serve HTTP polos:

curl -sI https://simrs.rs-anda.id | grep -i 'strict-transport-security'

Kalau output-nya kosong, berarti header HSTS belum aktif, dan browser bisa aja diarahkan ke koneksi nggak aman. Enkripsi emang nambah beban server, tapi percayalah, itu jauh lebih murah daripada biaya tanggung jawab kebocoran data pasien.

4. Audit Log: Nggak Ada Log, Nggak Ada Bukti

Waktu ada pasien atau keluarga yang komplain "kok data saya dibuka orang?", log akses itu saksi utamanya. Tapi log yang nggak pernah dibaca ya percuma, cuma makan space disk. Biasakan tiga hal ini:

  • Catat semua akses ke rekam medis, perubahan data, dan percobaan login yang gagal.
  • Buat alert untuk pola aneh: akses jam 2 pagi, atau satu akun buka ratusan data dalam semenit.
  • Simpan log di tempat terpisah yang cuma tim IT yang pegang, biar nggak bisa diakali oleh pihak yang bermasalah.

Contoh query sederhana buat nyari akun yang aksesnya di luar jam kerja terus:

SELECT user_id, COUNT(*) AS total
FROM access_log
WHERE TIME(access_at) NOT BETWEEN '06:00' AND '22:00'
GROUP BY user_id
HAVING COUNT(*) > 10
ORDER BY total DESC;

Jadwalkan review log minimal sebulan sekali. Nggak perlu njelimet, mulai dari laporan yang paling gampang dibaca dulu, misalnya akun dengan akses terbanyak di luar jam operasional. Dari situ biasanya ketahuan pola yang nggak wajar.

5. Backup yang Teruji, Bukan Sekadar Ada

Ransomware nyerang rumah sakit justru karena tahu kita nggak bisa nunggu. Setiap menit sistem mati, antrean pasien numpuk, dokter nggak bisa buka rekam medis, dan klaim BPJS molor. Backup adalah garis pertahanan terakhir yang nentuin RS cepat pulih atau harus bayar tebusan.

  • Backup otomatis terjadwal dengan frekuensi sesuai kebutuhan operasional, salinan off-site atau cloud, plus enkripsi.
  • Uji restorasi tiap 3 bulan. Beneran di-restore ke mesin uji dan dicek datanya utuh, bukan cuma lihat filenya ada.
  • Dokumentasikan prosedur pemulihan bencana: siapa pegang peran apa, estimasi waktu, dan jalur komunikasi kalau insiden beneran terjadi.

Contoh cron buat backup harian PostgreSQL yang gampang dimulai:

30 2 * * * pg_dump -U simrs_user -Fc simrs_db | gzip > /backup/simrs_$(date +\%F).dump.gz

Backup yang nggak pernah diuji restorasi itu sama aja kayak nggak punya backup. Temuannya baru kerasa pas paling kritis, dan itu pelajaran yang mahal banget harganya.

6. Patch dan Manajemen Kerentanan yang Konsisten

Banyak RS kena serangan lewat celah yang perbaikannya udah rilis berbulan-bulan. Alasannya selalu klasik: takut patch bikin sistem down pas jam operasional. Solusinya bukan nggak patch, tapi patch dengan prosedur yang bener:

  • Pantau rilis update dari vendor SIMRS, sistem operasi, dan aplikasi pendukung.
  • Uji dulu di lingkungan staging, baru terapkan ke produksi di jam paling sepi.
  • Scan kerentanan berkala, prioritasin perbaikan berdasarkan tingkat keparahan dan seberapa gampang celahnya dieksploitasi.
  • Ganti semua akun default dan password bawaan vendor. Ini hal sepele yang sering dilupakan tapi paling sering dieksploitasi.

Pengelolaan patch yang konsisten itu kayak servis rutin mobil: nggak kelihatan kerjanya, tapi nyegah mogok di tengah jalan pas lagi buru-buru.

Mulai dari yang Kecil, Sobat AITI

Nggak usah nunggu insiden dulu baru gerak. Mulai dari tiga hal yang paling gampang: audit akun dan hak akses, aktifkan 2FA untuk akun admin, dan pastikan backup beneran bisa di-restore. Tiga itu aja udah naikin level keamanan RS-mu drastis tanpa nunggu budget besar.

Keamanan data itu kerjaan tim, bukan cuma tim IT. Pelatihan singkat buat perawat dan staf administrasi soal jangan klik sembarangan dan jangan share password itu investasi yang balik modalnya cepat. Kalau kamu punya pengalaman, error, atau trik soal keamanan data di RS, share di kolom komentar, Sobat AITI. Kita sama-sama belajar, biar nggak ada lagi yang begadang gara-gara server down pas deadline klaim.