SATUSEHAT Down karena Bot? Simulasi Serangan yang Tidak Pernah Diuji ( Belum Diuji DDoS/Injection )

🔀 Read in English 🇬🇧

Selamat Datang di Hajriah Fajar: Hidup Sehat & Cerdas di Era Digital

SATUSEHAT Down karena Bot? Simulasi Serangan yang Tidak Pernah Diuji

Bayangin ini: hari Senin pagi, jam 09.01, admin rekam medis di rumah sakit daerah baru selesai ngopi. Tiba-tiba layar sistem SATUSEHAT-nya nge-freeze. Dia refresh, keluar error 503. Dikiranya internetnya lemot, padahal koneksi lancar. Lalu dia buka WhatsApp grup—semua admin fasyankes lain juga panik. SATUSEHAT down serentak. Lagi.

Ini bukan fiksi. Cerita kayak gini sudah mulai jadi kebiasaan, bukan kejadian langka. Tapi ada yang lebih absurd dari sekadar sistem down: nggak ada yang tahu persis kenapa. Apakah overload user? Salah konfigurasi? Atau... bot iseng nyamar jadi pasien dan ngirim ratusan request palsu ke endpoint rekam medis?

Serius, ini bukan cuma imajinasi paranoid. Di dunia sistem besar, serangan yang nggak pernah diuji itu justru yang paling bahaya. Dan seringnya, simulasi stress test cuma dilakukan di awal proyek—pas demo. Bukan pas sistem udah beneran hidup, diakses ratusan ribu orang tiap hari.

Waktu Sistem Pingsan, Semua Jadi Korban

Lucunya, waktu SATUSEHAT down, yang disalahin biasanya... laptop admin. Atau jaringan Puskesmas. Padahal kalau dicek, server pusatnya kena banjir request GET /Patient sebanyak 80.000 kali dalam 1 menit. Dan IP-nya bukan dari dalam negeri semua.

Kebanyakan sistem besar di Indonesia belum punya rate limiter yang ketat. Belum pakai CAPTCHA cerdas. Belum punya monitoring real-time untuk spotting anomali. Jadinya, waktu bot datang bertubi-tubi, server cuma bisa pasrah kayak kasir Indomaret kehabisan struk.

Ada satu cerita nyata dari 2024. Seorang pengembang aplikasi kesehatan berhasil mengakses ratusan entri dummy hanya dengan script Python sederhana. API-nya tidak pakai token refresh yang kadaluwarsa. Setelah dites pakai bot sederhana, respon server makin lambat, lalu crash. Tapi waktu itu dibilangnya “simulasi biasa”.

Apa Itu Bot Attack? Kok Bisa Bikin Sistem Kesehatan Tumbang?

Bot di sini bukan robot lucu kayak di film. Ini script otomatis, sering dijalankan dari cloud atau server asing, tujuannya macam-macam:

• Scraping: Mengambil data pasien masal buat dijual atau diolah ulang.
• Brute force: Mencoba masuk ke akun tenaga kesehatan dengan kombinasi login umum kayak “admin123”.
• Spam rekam medis palsu: Mengirim entri diagnosis/kunjungan fiktif supaya sistem bingung, atau buat nutupin jejak manipulasi data asli.

Gini ya... kalau kita bisa bikin 1000 bot dalam waktu 10 menit, lalu masing-masing bot itu kirim 1.000 request dalam 1 jam, artinya server menerima 1 juta serangan halus yang kelihatan kayak pengguna biasa. Kalau belum ada proteksi seperti queue throttling atau AI-based anomaly detection, ya... tinggal nunggu waktu sistem KO.

Kenapa Belum Pernah Disimulasikan?

Karena stress-test itu mahal. Dan nggak seksi buat dilaporin ke kementerian. Bandingin: “Sistem SATUSEHAT berhasil diakses oleh 100.000 pengguna dalam 1 minggu” terdengar lebih keren daripada “Sistem berhasil bertahan dari serangan bot yang meniru pasien palsu.” 😅

Lagipula, siapa yang akan melaporkan kalau sistem berhasil menahan serangan? Kadang malah nggak tahu kalau sudah diserang. Sistem cuma dianggap lambat. Atau dimaklumi sebagai “beban server tinggi karena antusiasme masyarakat”.

Padahal, dalam banyak kasus, kelambatan itu bukan karena user beneran. Tapi karena sistem menerima ratusan permintaan GET dengan ID pasien yang diacak. Tujuannya bukan cuma nyedot data, tapi nge-crash-in sistem pelan-pelan.

Refleksi Singkat: Apakah SATUSEHAT Terlalu Percaya?

SATUSEHAT memang dirancang dengan teknologi yang keren: HL7 FHIR, REST API, autentikasi OAuth, token bearer... secara teknis ini cukup modern. Tapi sayangnya, sistem ini masih mempercayai semua pihak yang "sudah terdaftar". Artinya, kalau kamu developer yang dapat approval, kamu bisa akses data seperti pengguna beneran—bahkan kalau kamu iseng.

Ini bukan soal sistem jahat. Tapi soal asumsi bahwa semua pihak akan bertindak benar. Dan kita tahu, realita sering nggak sebaik idealisme teknokrat.

Tips Reflektif (dan Absurd) Menghindari Bot Attack ala Fasyankes

Oke, ini bukan blog DevSecOps, jadi kita nggak akan bahas teknik rate limiter dengan Redis atau WAF Layer-7. Tapi… boleh dong mimpi punya sistem yang:

• 1. Punya proteksi level petugas front desk
  Kayak ibu-ibu di loket pendaftaran yang bisa bilang: “Maaf, kalau belum bawa kartu, gak bisa lanjut.” Nah sistem juga harus gitu — tiap request API harus bisa disaring dulu: siapa, dari mana, niatnya apa.
• 2. Token akses harus kadaluarsa cepat
  Token API yang bisa hidup 24 jam tanpa refresh itu kayak kunci kamar yang bisa dipakai mantan. Serem.
• 3. Simulasikan serangan aneh sebelum hacker beneran yang nyoba
  Serius. Coba aja buat 1000 request palsu pakai Postman, dan lihat apakah sistemmu ngambek. Lebih baik down pas dites internal daripada pas jam dinas vaksinasi nasional.
• 4. Pasang alarm, bukan hanya lampu indikator
  Kalau ada lonjakan trafik dari IP yang sama dalam 1 menit, harusnya muncul notifikasi. Jangan sampai yang tahu duluan itu user yang marah-marah di Twitter.

Cerita Nyata: Ketika Pasien Virtual Bikin Panik Admin

Salah satu rekan saya — sebut saja Mbak D — kerja di vendor RME lokal. Suatu hari, dia diminta debug kenapa sistem tiba-tiba lambat banget di rumah sakit mitra. Ternyata... ada data pasien baru yang muncul sendiri, dengan nama aneh kayak "zzzz_bot123" dan alamat "cloudflare datacenter".

Yang lucu, data itu valid secara format, jadi masuk ke antrian kunjungan dan bahkan hampir dicetak di antrian nomor poli. Admin kebingungan. Dokter bingung. Server hampir mati. Dan itu semua karena tidak ada validasi nama pasien yang masuk. Selama format JSON-nya bener, semua dianggap sah.

Mbak D akhirnya pasang regex sederhana: nama pasien harus mengandung huruf kapital normal dan tidak boleh mengandung angka. Bukan solusi ideal, tapi cukup menyaring pasien fiktif generasi pertama. Ironisnya, patch itu belum masuk ke update nasional karena “belum standar”.

Kenapa Cerita-Cerita Ini Perlu Diangkat?

Karena sistem sebesar SATUSEHAT bukan cuma soal teknologi keren, tapi soal rasa percaya. Kalau admin fasyankes frustrasi tiap minggu karena error 503, rasa percaya itu pelan-pelan hilang. Dan kalau masyarakat tahu data mereka bisa diakses oleh bot — entah scraping, entah spam — maka proyek sebesar apa pun bakal ditinggal pelan-pelan.

Lagian, kalau kita sebagai bangsa bisa bangun sistem identitas pasien nasional, masa nggak bisa bikin mekanisme ngeblok request GET mencurigakan? Atau minimal, bikin log akses yang bisa dicek publik — biar semua tahu kalau data mereka dijaga, bukan cuma digeser bolak-balik lewat API.

Sekelumit Penutup dari Warung Kopi

Waktu nulis ini, saya lagi duduk di depan warung kopi dekat Puskesmas. Petugas IT-nya lagi ngobrol soal “error 503 yang udah jadi makanan harian”. Satu bilang, “kayaknya sistemnya ngambek kalau hari Senin”. Yang lain jawab, “mungkin servernya kena kiriman cinta dari bot luar negeri.”

Entah lucu, entah sedih. Tapi yang jelas, sistem nasional yang nggak pernah diuji serangan itu kayak jembatan yang belum pernah dilewatin truk. Kelihatannya kokoh, tapi kita nggak tahu kapan retaknya. Dan jangan nunggu jebol dulu baru bikin ulang. Capek, kan?

Kalau kamu pengembang, admin, dokter, atau bahkan pasien... kamu bagian dari ekosistem SATUSEHAT juga. Mungkin kita nggak bisa cegah semua bot, tapi kita bisa mulai dari satu: ngasih tahu bahwa sistem kita belum pernah diuji serangan. Dan sekarang saatnya mulai.

Welcome to Hajriah Fajar: Living Smart & Healthy in the Digital Age

SATUSEHAT Down Because of Bots? A Simulation That Was Never Tested

Imagine this: it’s a regular Monday morning at 9:01 AM. The health admin at a regional hospital has just finished their coffee. Suddenly, SATUSEHAT freezes. They refresh the page. Error 503. They blame the internet, but their connection is fine. Then they check the group chat — turns out everyone else is freaking out too. SATUSEHAT is down. Again.

This isn’t fiction. These kinds of incidents are no longer “occasional.” They’re recurring. But the weirdest part? No one really knows why. Is it just user overload? Configuration gone wrong? Or... is it a swarm of bots pretending to be patients and flooding the medical record endpoints with fake requests?

Seriously, this isn’t just a conspiracy theory. In massive systems, the most dangerous attacks are the ones that were never tested against. And often, stress-testing only happens in the early days — during demo phases. Not when the system is live and serving hundreds of thousands daily.

When the System Faints, Everyone Suffers

Funny thing is, whenever SATUSEHAT goes down, people often blame... the admin’s laptop. Or the clinic’s Wi-Fi. But if you dig deeper, the main server just received 80,000 GET /Patient requests in a minute. And not all of them were from Indonesia.

Most large-scale platforms in Indonesia still lack proper rate limiting. No smart CAPTCHA. No real-time anomaly detection. So when bots attack non-stop, the server acts like a cashier printer out of paper — blinking but helpless.

There was this real case back in 2024. A health app developer ran a simple Python script and was able to access hundreds of dummy records. The API didn’t use refresh tokens that expired. After a basic bot test, server latency spiked and eventually crashed. It was later labeled as a “routine test.”

What Are Bot Attacks, and Why Can They Crash Health Systems?

These aren’t robots from sci-fi movies. These are silent scripts, often running on cloud instances, doing things like:

• Scraping: Mass-harvesting patient data to sell or repurpose.
• Brute force: Attempting logins with common credentials like “admin123”.
• Fake medical record spam: Injecting bogus visits or diagnoses to pollute the system — or cover up data manipulation.

Think about it. If you spawn 1,000 bots in 10 minutes, and each sends 1,000 requests per hour, that’s 1 million quiet attacks in disguise. If the system has no queue throttle or anomaly flagging, it’s only a matter of time before it collapses.

Why Hasn’t This Ever Been Simulated?

Because stress tests aren’t sexy. And they’re expensive. It's easier to show slides like “SATUSEHAT successfully served 100,000 users this week” than to say, “we successfully fended off fake bot patients simulating a silent attack.” 😅

Also, no one really reports successful defenses. Sometimes, they don’t even realize they were under attack. The system is just “sluggish.” Or people say, “high traffic due to public enthusiasm.”

But often, the real cause is repeated GET requests with randomized patient IDs. Not to view real data — just to crash the party.

Quick Reflection: Does SATUSEHAT Trust Too Easily?

SATUSEHAT is built on impressive tech: HL7 FHIR, RESTful APIs, OAuth authentication, bearer tokens... it’s modern on paper. But the system still trusts all parties that are “registered.” That means, once you're approved as a developer, you can act like a full-access user — even if you're just being playful.

This isn’t about bad intentions. It’s about assuming everyone will play nice. And we all know reality isn’t always that optimistic.

Absurd Yet Useful Tips to Keep Bots Out (or At Least Confused)

Look, this isn’t a DevSecOps blog. We won’t get too deep into Redis-based throttling or Layer-7 firewalls. But maybe — just maybe — the health system could learn from front desk aunties who instinctively know how to block weird behavior:

• 1. Treat every API request like a stranger showing up at 2 AM
  Just because someone knows the endpoint doesn’t mean they should get the data. Ask who, from where, and what the heck they’re doing here.
• 2. Expire tokens fast, like expired milk
  A token that stays alive for 24 hours without re-validation is like giving your apartment key to an ex and hoping they “don’t come back.”
• 3. Run fake attacks on your own system
  Spin up 1,000 fake patients, blast the API, see what breaks. Better to crash in internal testing than on vaccination day.
• 4. Alarms, not just blinking lights
  If 300 requests come from one IP in under a minute, somebody should get a message. Preferably not your Twitter DMs.

A True Story: When a Virtual Patient Almost Got in Line

A friend of mine — let’s call her Dee — works at a local EMR vendor. One day she gets a support ticket: hospital’s app is weirdly slow. She dives in and finds a new patient record... with the name “zzzz_bot123” and address “cloudflare datacenter.” Yeah.

And the kicker? The record was technically valid. It made it into the appointment queue. Almost printed on the queue ticket. Admins were confused. The doctor was confused. The system? Overloaded. All because nobody filtered the input properly. If it’s a valid JSON, it goes in.

Dee patched it with a quick regex: names must start with a capital letter and no digits allowed. Not perfect, but it stopped Gen-1 bots. Ironically, the patch wasn’t accepted nationally — “not aligned with the national standard.”

Why Are These Stories Worth Telling?

Because SATUSEHAT isn’t just a tech project. It’s a trust contract. If health admins are burnt out and patients start questioning how their records are used — the system loses credibility, no matter how beautiful the dashboard looks.

Honestly, if we as a nation can build a national patient ID system, surely we can block sketchy GET requests. Or at least make access logs publicly auditable — so people know their data isn’t just floating between APIs.

Closing Thoughts from a Coffee Stall Near a Clinic

I’m writing this while sipping tea at a roadside stall near a community clinic. A group of IT staff is chatting. One says, “Maybe SATUSEHAT just doesn’t like Mondays.” Another replies, “Or maybe some bot out there really loves us.”

Funny. Or maybe sad. But one thing’s clear: national systems that never get tested under attack are like bridges that were never crossed by a truck. They look strong — until one day, snap.

If you’re a dev, a nurse, a sysadmin, or even just a patient... you’re part of this ecosystem too. Maybe we can’t stop every bot. But we can at least talk about the bots. And talking is how security starts.