Keamanan Sistem Terdistribusi: Konsep Dasar, Risiko, dan Cara Mengamankannya

Pengertian Keamanan Sistem Terdistribusi

Keamanan sistem terdistribusi adalah upaya melindungi sistem yang terdiri dari banyak komputer, server, service, atau aplikasi yang saling terhubung melalui jaringan.

Dalam sistem terdistribusi, data tidak hanya diproses di satu tempat, tetapi berpindah dari satu komponen ke komponen lain.

Contohnya:

Frontend → Order Service → Queue → Worker → Payment Service → Log/Event

Karena banyak komponen saling berkomunikasi, maka risiko keamanan juga semakin besar.

Mengapa Keamanan Penting?

Pada sistem biasa, serangan mungkin hanya menargetkan satu aplikasi. Namun pada sistem terdistribusi, serangan bisa terjadi di banyak titik.

Contoh risiko:

• API bisa diakses sembarang orang
• Data order bisa dimanipulasi
• Token antar service bisa dicuri
• Service palsu bisa mengirim request
• Log sistem bisa dihapus
• Data dikirim tanpa enkripsi

Jika sistem tidak diamankan, maka penyerang bisa membuat order palsu, mengubah status pembayaran, mengambil data user, atau membuat service tidak berjalan.

Tujuan Keamanan Sistem Terdistribusi

Keamanan sistem terdistribusi bertujuan untuk menjaga:

a. Confidentiality

Data hanya boleh diakses oleh pihak yang berhak.

Contoh:

Data pembayaran tidak boleh dilihat oleh orang sembarangan.

b. Integrity

Data tidak boleh diubah secara ilegal.

Contoh:

Total pembayaran Rp50.000 tidak boleh dimanipulasi menjadi Rp5.000.

c. Availability

Sistem harus tetap tersedia dan dapat digunakan.

Contoh:

Order Service tetap bisa menerima order meskipun Payment Service sedang lambat.

Tiga konsep ini dikenal sebagai CIA Triad:

1. Confidentiality
2. Integrity
3. Availability

Tantangan Keamanan pada Sistem Terdistribusi

Sistem terdistribusi memiliki tantangan lebih besar dibanding sistem monolithic.

a. Banyak Titik Akses

Setiap service memiliki endpoint masing-masing.

Contoh:

/order.php
/payment.php
/events.php
/queue_worker.php

Semakin banyak endpoint, semakin banyak titik yang bisa diserang.

b. Komunikasi Melalui Jaringan

Service saling berkomunikasi melalui HTTP, API, message queue, atau event.

Jika tidak diamankan, data dapat:

1. Disadap
2. Dimodifikasi
3. Dipalsukan
4. Dikirim ulang

c. Service Saling Bergantung

Jika satu service diserang, service lain bisa ikut terganggu.

Contoh:

Payment Service mati → order tidak bisa diproses → notifikasi tidak muncul

d. Identitas Service Sulit Dipastikan

Dalam sistem terdistribusi, kita harus memastikan bahwa request benar-benar berasal dari service yang sah.

Contoh:

• Apakah request ke Payment Service benar-benar dari Worker?
• Atau dari pihak luar?

Prinsip Dasar Keamanan Sistem Terdistribusi

a. Authentication

Authentication adalah proses memastikan siapa yang mengakses sistem.

Contoh:

• User login menggunakan username dan password
• Frontend mengirim API Key
• Worker mengirim service token

Dalam praktikum:

Frontend → Order Service menggunakan API KEY
Worker → Payment Service menggunakan SERVICE TOKEN

b. Authorization

Authorization adalah proses menentukan apa yang boleh dilakukan oleh pengguna atau service.

Contoh:

• User biasa hanya boleh membuat order
• Admin boleh melihat semua transaksi
• Worker boleh memproses pembayaran

Authentication menjawab:

1. Siapa Anda?
2. Apa yang boleh Anda lakukan?

c. Integrity

Integrity memastikan data tidak berubah secara ilegal selama proses pengiriman atau penyimpanan.

Contoh:

• order_id tidak boleh diubah sembarangan
• amount tidak boleh dimanipulasi
• status paid tidak boleh diberikan tanpa validasi

d. Non-Repudiation

Non-repudiation berarti aktivitas yang dilakukan tidak dapat disangkal.

Contoh:

Jika sebuah order dibuat, sistem menyimpan log siapa yang membuatnya dan kapan dibuat.

Dalam praktikum, ini dilakukan dengan:

1. log.txt
2. atau tabel events

e. Availability

Availability memastikan sistem tetap berjalan meskipun ada gangguan.

Contoh penerapan:

• Queue digunakan agar order tetap tersimpan walaupun payment service sedang sibuk.
• Worker dapat memproses queue ketika service siap.

Ancaman Keamanan pada Sistem Terdistribusi

a. Unauthorized Access

Terjadi ketika pihak luar mengakses API tanpa izin.

Contoh:

Orang langsung membuka:

http://localhost:8001/order.php

Tanpa API Key, ini berbahaya.

Solusi:

Gunakan API Key, token, session, JWT, atau OAuth.

b. Data Manipulation

Penyerang mengubah data sebelum dikirim ke service.

Contoh:

amount = 50000

diubah menjadi

amount = 1000

Solusi:

1. Validasi input di sisi server
2. Jangan percaya data dari frontend

c. Injection Attack

Serangan terjadi ketika input user mengandung kode berbahaya.

Contoh:

<script>alert('hack')</script>

Atau SQL injection:

' OR '1'='1

Solusi:

1. Gunakan prepared statement
2. Gunakan htmlspecialchars
3. Validasi dan sanitasi input

d. Man-in-the-Middle Attack

Penyerang menyadap komunikasi antar service.

Contoh:

Frontend → Order Service
Worker → Payment Service

Jika tidak memakai HTTPS, data bisa disadap di jaringan nyata.

Solusi:

1. Gunakan HTTPS/TLS
2. Gunakan token
3. Gunakan signature

e. Replay Attack

Penyerang mengirim ulang request lama yang pernah valid.

Contoh:

Request pembayaran lama dikirim ulang agar status order berubah lagi.

Solusi:

1. Gunakan timestamp
2. Gunakan nonce
3. Gunakan token sekali pakai

f. Denial of Service

Serangan dilakukan dengan mengirim request sangat banyak sehingga service lambat atau mati.

Contoh:

1000 request per detik ke Order Service

Solusi:

1. Rate limiting
2. Queue
3. Firewall
4. Monitoring

g. Service Spoofing

Penyerang membuat service palsu yang berpura-pura menjadi service asli.

Contoh:

Service palsu mengaku sebagai Worker dan mengirim request ke Payment Service.

Solusi:

1. Service token
2. Mutual authentication
3. mTLS

Keamanan pada Komunikasi Antar Service

Dalam sistem terdistribusi, komunikasi antar service adalah bagian yang sangat penting.

Contoh:

Frontend → Order Service
Order Service → Queue
Worker → Payment Service
Payment Service → Event

Setiap jalur komunikasi perlu diamankan.

a. API Key

API Key adalah kode rahasia sederhana yang digunakan untuk membatasi akses ke API.

Contoh:

X-API-KEY: SECRET123

Kelebihan:

• Mudah digunakan
• Cocok untuk praktikum
• Mudah dipahami mahasiswa

Kekurangan:

• Jika bocor, bisa digunakan orang lain
• Belum seaman JWT/OAuth

b. Service Token

Service Token digunakan untuk komunikasi antar service.

Contoh:

Worker → Payment Service
Token: PAYMENT_SECRET

Tujuannya agar Payment Service hanya menerima request dari service yang dipercaya.

c. JWT

JWT atau JSON Web Token adalah token yang membawa informasi user atau service dalam format tertentu.

Biasanya digunakan pada aplikasi modern.

Contoh isi token:

user_id
role
expired_time
signature

JWT lebih cocok untuk sistem yang memiliki login user dan role.

d. HTTPS/TLS

HTTPS digunakan untuk mengenkripsi data selama proses pengiriman.

Tanpa HTTPS:

Data bisa dibaca oleh pihak lain

Dengan HTTPS:

Data dienkripsi
Lebih aman untuk jaringan publik

Pada praktikum lokal, HTTPS tidak wajib.

Namun pada sistem nyata, HTTPS wajib digunakan.

Keamanan pada Input Data

Input dari user adalah salah satu sumber serangan paling umum.

Contoh input:

Nama customer
Nama produk
Jumlah pembayaran
Order ID
Token

Sistem tidak boleh langsung percaya pada input user.

Prinsip penting:

Never trust user input

Artinya:

Semua input harus divalidasi
Semua input harus disanitasi
Semua query database harus menggunakan prepared statement

Contoh Validasi

$amount = (int) $_POST['amount'];

if ($amount <= 0) {
    echo "Jumlah pembayaran tidak valid";
    exit;
}

Contoh Sanitasi

$customerName = htmlspecialchars(trim($_POST['customer_name']));

Tujuannya untuk mencegah script berbahaya tampil sebagai kode aktif di browser.

Keamanan Database

Database menyimpan data penting seperti:

order
payment queue
event
log
status pembayaran

Jika database tidak aman, maka seluruh sistem berisiko.

Prinsip keamanan database:

• Gunakan prepared statement
• Batasi hak akses user database
• Jangan gunakan root di production
• Backup berkala
• Jangan tampilkan error database ke user

Pada praktikum lokal, user database biasanya:

root
password kosong

Namun untuk sistem nyata, ini tidak aman.

Logging dan Monitoring

Logging adalah proses mencatat aktivitas sistem.

Contoh log:

• Order dibuat
• API Key salah
• Token salah
• Pembayaran berhasil
• Input tidak valid

Log penting karena membantu:

• Mendeteksi serangan
• Melacak kesalahan
• Menganalisis aktivitas sistem
• Membuktikan kejadian tertentu

Contoh log sederhana:

2026-04-26 10:20:01 - Order dibuat oleh Andi
2026-04-26 10:20:07 - Payment berhasil untuk Order ID 1

Perbedaan Logging dan Monitoring

Logging:

Mencatat kejadian

Monitoring:

Mengawasi kondisi sistem secara terus-menerus

Contoh monitoring:

• Jumlah request
• Jumlah error
• Waktu respon API
• Status service aktif atau mati

Keamanan Queue

Queue digunakan untuk memproses data secara asynchronous.

Dalam sistem payment:

Order Service → Database Queue → Worker → Payment Service

Risiko pada queue:

• Data queue palsu
• Order ID dimanipulasi
• Queue diproses berulang
• Queue tidak pernah selesai

Solusi:

• Gunakan status queue
• Gunakan validasi order_id
• Gunakan log pemrosesan
• Gunakan retry limit
• Gunakan timestamp

Contoh status queue:

• Waiting
• Processing
• Processed
• Failed

Keamanan Worker

Worker adalah program yang berjalan di belakang layar untuk memproses queue.

Risiko pada worker:

• Worker memproses data palsu
• Worker memanggil service yang salah
• Token worker bocor
• Worker berjalan tanpa kontrol

Solusi:

• Gunakan service token
• Batasi akses file worker
• Jalankan worker hanya di server internal
• Catat semua aktivitas worker

Worker tidak seharusnya bisa diakses langsung dari browser.

Keamanan Event / SSE

SSE atau Server-Sent Events digunakan untuk mengirim notifikasi dari server ke browser secara real-time.

Contoh:

• Pembayaran berhasil
• Status order berubah
• Event diterima frontend

Risiko SSE:

• Event sensitif terbaca user lain
• Event palsu dikirim
• Informasi internal terlalu terbuka

Solusi:

• Filter event berdasarkan user
• Jangan tampilkan data sensitive
• Gunakan session/token
• Batasi isi pesan event

Contoh pesan aman:

Order #1 berhasil diproses

Contoh pesan kurang aman:

Nomor kartu pembayaran user berhasil diverifikasi

Studi Kasus Praktikum

Pada praktikum ini, sistem yang digunakan adalah mini sistem order dan pembayaran.

Alur sistem:

Lapisan Keamanan pada Studi Kasus

a. API Key pada Frontend ke Order Service

Frontend tidak boleh sembarangan mengirim order.

Maka digunakan:

X-API-KEY: SECRET123

Jika API Key salah:

Unauthorized - API KEY salah

b. Validasi Input pada Order Service

Order Service memeriksa data:

• Nama tidak boleh kosong
• Produk tidak boleh kosong
• Amount harus lebih dari 0

Jika input tidak valid, order ditolak.

c. Logging pada Order Service

Setiap order dicatat.

Contoh:

Order dibuat oleh Andi

Log ini berguna jika terjadi kesalahan atau serangan.

d. Queue untuk Pemrosesan Aman

Order tidak langsung diproses oleh Payment Service.

Order dimasukkan ke queue terlebih dahulu.

Keuntungannya:

• Sistem tidak blocking
• Bisa diproses bertahap
• Lebih mudah dikontrol

e. Service Token pada Worker ke Payment Service

Payment Service hanya menerima request yang membawa token benar.

Contoh:

PAYMENT_SECRET

Jika token salah:

Unauthorized Service

f. Event / Log Setelah Pembayaran

Setelah pembayaran berhasil, sistem membuat event.

Contoh:

Order #1 berhasil dibayar

Event ini dapat ditampilkan ke frontend atau disimpan sebagai riwayat sistem.

Perbandingan Sistem Tanpa Keamanan dan Dengan Keamanan

Aspek	Tanpa Keamanan	Dengan Keamanan
Akses API	Siapa saja bisa akses	Harus punya API Key
Input	Bisa berbahaya	Divalidasi
Payment Service	Bisa dipanggil bebas	Harus pakai service token
Aktivitas	Tidak tercatat	Dicatat dalam log
Queue	Rentan data palsu	Lebih terkontrol
Debugging	Sulit	Lebih mudah

Contoh Skenario Serangan

Skenario 1: API Diakses Tanpa API Key

Penyerang mencoba mengirim order langsung ke:

http://localhost:8001/order.php

Jika tidak ada API Key, sistem menolak.

Unauthorized

Skenario 2: Token Payment Salah

Worker mengirim token salah ke Payment Service.

Payment Service menolak request.

Unauthorized Service

Skenario 3: Input Script Berbahaya

User memasukkan:

<script>alert('hack')</script>

Sistem melakukan sanitasi agar script tidak dijalankan browser.

Skenario 4: Amount Tidak Valid

User memasukkan:

-50000

Sistem menolak karena pembayaran tidak boleh negatif.

Best Practice Keamanan Sistem Terdistribusi

Beberapa praktik terbaik:

• Gunakan HTTPS di production
• Gunakan token yang kuat dan sulit ditebak
• Jangan simpan secret langsung di kode production
• Gunakan file .env
• Batasi akses database
• Validasi semua input
• Gunakan prepared statement
• Catat aktivitas penting
• Gunakan rate limiting
• Gunakan monitoring
• Gunakan backup
• Gunakan role dan permission