JAWABAN ESSAY UAS BD307 – Reno Andre Permana

1. jelaskan bagaimana API yang tidak diamankan dengan baik dapat menyebabkan kebocoran data meskipun sistem menggunakan enkripsi.

 

2. analisis mengapa enkripsi data tidak menjamin keamanan apabila kontrol akses dan otorisasi gagal.

 

3. rancang langkah pencegahan dari sisi keamanan API dan manejemen akses.

 

4. jelaskan langkah respons insiden awal yang seharusnya dilakukan setelah kebocoran terdeteksi.

 

jawaban

 

1. API yang tidak diamankan dengan baik tetap bisa menyebabkan kebocoran data meskipun menggunakan enkripsi karena enkripsi hanya melindungi data saat disimpan dan dikirim, bukan siapa yang boleh mengaksesnya. Jika autentikasi dan otorisasi lemah, penyerang dapat memanggil endpoint secara sah dan server sendiri akan mengirimkan data dalam bentuk terbuka. Selain itu, API yang mengekspose data berlebihan, memiliki token yang mudah disalahgunakan, konfigurasi HTTPS yang keliru, atau error/log yang tidak aman dapat membocorkan informasi sensitif. Intinya: enkripsi melindungi jalur data, tetapi keamanan API menentukan hak akses—dan di situlah kebocoran sering terjadi.

2. Enkripsi data tidak menjamin keamanan ketika kontrol akses dan otorisasi gagal karena enkripsi hanya melindungi bagaimana data disimpan dan dikirim, bukan siapa yang berhak mengaksesnya. Analisisnya:

  1. Server mendekripsi data untuk pengguna yang “dianggap sah”
    Jika autentikasi/otorisasi lemah, penyerang bisa lolos sebagai pengguna valid. Saat itu, sistem sendiri akan mendekripsi dan menyerahkan data kepadanya. Enkripsi tidak menghalangi akses yang sudah diizinkan secara logika aplikasi.

  2. Kegagalan otorisasi = akses lintas data (BOLA/IDOR)
    Tanpa pemeriksaan kepemilikan objek, pengguna dapat mengakses data milik pihak lain hanya dengan mengganti ID. Data tetap terkirim aman (terenkripsi saat transit), tetapi bocor karena hak akses salah.

  3. Eksposur data berlebihan
    API atau aplikasi sering mengirim lebih banyak field dari yang diperlukan. Enkripsi tidak mencegah kebocoran jika sistem memang “memilih” untuk mengungkapkan data sensitif.

  4. Kredensial/token yang disalahgunakan
    Token yang bocor, tidak kedaluwarsa, atau tidak dibatasi scope-nya memberi akses penuh. Begitu akses diperoleh, enkripsi menjadi tidak relevan karena data diberikan secara resmi.

  5. Permukaan kebocoran di luar penyimpanan/transmisi
    Logging, pesan error, atau cache yang tidak aman dapat menampilkan data terdekripsi. Enkripsi at-rest/in-transit tidak melindungi titik-titik ini.

 

3. Berikut rancangan langkah pencegahan dari sisi keamanan API dan manajemen akses yang ringkas dan praktis:

1. Autentikasi Kuat

  • Gunakan OAuth 2.0 / OpenID Connect atau JWT dengan expiry.

  • Hindari API key statis; lakukan rotasi token dan revoke bila bocor.

  • Terapkan MFA untuk akses administratif.

2. Otorisasi Berlapis (Zero Trust)

  • Terapkan least privilege dan role-based / attribute-based access control (RBAC/ABAC).

  • Validasi kepemilikan objek di setiap request (cegah BOLA/IDOR).

  • Batasi scope token sesuai fungsi.

3. Desain Endpoint Aman

  • Minimalkan data dalam respons (hindari excessive data exposure).

  • Gunakan object filtering/field whitelisting.

  • Pisahkan endpoint publik vs privat.

4. Proteksi Transport & Infrastruktur

  • Wajib HTTPS/TLS, nonaktifkan HTTP.

  • Pasang API Gateway / WAF untuk filtering, throttling, dan IP allowlist bila perlu.

5. Rate Limiting & Anti-Abuse

  • Terapkan rate limiting, quota, dan anomaly detection untuk mencegah enumerasi dan scraping.

6. Validasi Input & Error Handling

  • Lakukan validasi skema (JSON schema), sanitasi input.

  • Jangan bocorkan detail sensitif di pesan error; gunakan pesan generik.

7. Logging, Monitoring, & Audit

  • Log aktivitas akses (tanpa data sensitif), aktifkan alert untuk pola mencurigakan.

  • Lakukan audit berkala dan access review.

8. Manajemen Kredensial & Rahasia

  • Simpan rahasia di secret manager, bukan di kode/klien.

  • Terapkan key rotation, short-lived tokens, dan device binding bila relevan.

9. Pengujian Keamanan

  • Lakukan API security testing (BOLA, auth bypass, data exposure).

  • Penetration test dan code review rutin.

 

4. Berikut langkah respons insiden awal yang seharusnya dilakukan segera setelah kebocoran data terdeteksi:

  1. Isolasi & Hentikan Sumber Kebocoran
    Nonaktifkan endpoint, akun, atau sistem yang terdampak; cabut token/kredensial yang dicurigai; batasi akses jaringan sementara.

  2. Verifikasi & Klasifikasi Insiden
    Konfirmasi bahwa kebocoran benar terjadi, tentukan jenis data yang terpapar (sensitif/pribadi), cakupan, dan periode kejadian.

  3. Amankan Bukti (Preservasi Forensik)
    Simpan log, snapshot sistem, dan artefak terkait tanpa mengubahnya untuk analisis lanjutan dan kepatuhan hukum.

  4. Containment Jangka Pendek
    Terapkan patch sementara: perbaiki kontrol akses yang gagal, aktifkan rate limiting, tutup celah konfigurasi.

  5. Notifikasi Internal & Aktivasi Tim
    Laporkan ke manajemen, tim keamanan, hukum, dan komunikasi; tetapkan satu koordinator insiden.

  6. Penilaian Dampak Awal
    Identifikasi siapa yang terdampak, risiko lanjutan (mis. penyalahgunaan kredensial), dan kebutuhan tindakan cepat (reset sandi, rotasi kunci).

  7. Komunikasi Terkendali
    Siapkan pesan awal yang akurat dan transparan (tanpa spekulasi) untuk pemangku kepentingan; ikuti kewajiban pelaporan regulasi bila berlaku.

Previous Post Previous Post
Newer Post Newer Post

Leave a comment