Keberhasilan integrasi sistem biasanya dilihat dari kelancaran pertukaran informasi. Data dari aplikasi sumber dapat muncul pada aplikasi tujuan, pekerjaan manual berkurang, dan proses bisnis berjalan lebih cepat.

Namun, keberhasilan teknis tersebut sering menyembunyikan persoalan lain. Data yang berhasil dikirim ternyata jauh lebih banyak daripada yang benar-benar dibutuhkan.

Bayangkan aplikasi absensi yang terhubung dengan sistem HR. Untuk mencatat kehadiran, aplikasi tersebut sebenarnya hanya membutuhkan ID pegawai, nama, unit kerja, dan status kepegawaian. Akan tetapi, API justru mengirimkan seluruh profil pegawai, termasuk alamat rumah, nomor identitas, informasi keluarga, rekening bank, dan komponen gaji.

Integrasi tetap berjalan. Tidak ada pesan kesalahan dan tidak ada layanan yang terhenti. Meskipun demikian, satu sistem tambahan kini menyimpan data sensitif yang tidak berkaitan dengan fungsinya.

Kondisi seperti inilah yang membuat keamanan integrasi sistem tidak cukup dinilai dari keberhasilan koneksi. Pertanyaan yang lebih penting adalah apakah setiap data yang berpindah memang memiliki tujuan yang jelas.

Integrasi Tidak Hanya Menambah Koneksi

Ketika dua aplikasi dihubungkan, perusahaan tidak sekadar menciptakan jalur komunikasi baru. Perusahaan juga dapat menciptakan lokasi penyimpanan, akun teknis, token akses, log, cache, dan salinan data baru.

Data yang dikirim melalui satu integrasi dapat masuk ke berbagai tempat, antara lain:

• database sistem penerima;
• cache aplikasi;
• antrean pesan;
• penyimpanan sementara;
• sistem monitoring;
• log aplikasi;
• data warehouse;
• file ekspor;
• lingkungan pengujian;
• sistem pencadangan.

Setiap lokasi membawa kewajiban pengamanan tersendiri. Aksesnya perlu dibatasi, aktivitasnya harus dicatat, masa penyimpanannya perlu ditentukan, dan datanya harus dapat dihapus ketika tidak lagi diperlukan.

Jika satu dataset disalin ke lima sistem, perusahaan tidak lagi melindungi data tersebut pada satu tempat. Perusahaan harus memastikan kelima sistem memiliki kontrol yang memadai.

Semakin banyak salinan dibuat, semakin banyak pula kemungkinan salah konfigurasi, akses berlebihan, atau penyimpanan data yang tidak terpantau.

Data Berlebih Sering Berpindah karena Lebih Mudah

Dalam banyak proyek, pertukaran data berlebihan tidak bermula dari niat untuk mengabaikan keamanan. Penyebabnya sering kali lebih sederhana: mengirimkan seluruh objek dianggap lebih praktis daripada memilih field satu per satu.

Developer dapat menggunakan model data yang sama untuk beberapa endpoint. Aplikasi penerima juga terkadang meminta seluruh informasi dengan alasan mungkin akan digunakan pada masa mendatang.

Keputusan tersebut mempercepat implementasi awal, tetapi menimbulkan beban jangka panjang.

Data yang tidak diperlukan tetap harus dilindungi. Ketika sistem penerima mengalami insiden, data tersebut dapat ikut terekspos meskipun tidak pernah digunakan untuk menjalankan fungsi aplikasi.

Beberapa pola yang sering menyebabkan masalah antara lain:

• API mengembalikan seluruh kolom dari database;
• satu endpoint digunakan untuk berbagai kebutuhan;
• sistem penerima menyimpan semua respons secara otomatis;
• payload lengkap dicatat dalam log;
• developer mengandalkan aplikasi pengguna untuk menyaring data;
• tidak ada klasifikasi data sebelum integrasi dibuat;
• kebutuhan setiap field tidak pernah didokumentasikan;
• akses lama tetap aktif setelah kerja sama berakhir.

Analisis ini sering kami temukan saat melakukan penetration testing pada perusahaan di Indonesia.

Masalahnya bukan selalu pada ketiadaan autentikasi atau enkripsi. Sistem dapat menggunakan HTTPS dan token yang valid, tetapi tetap membagikan informasi lebih banyak daripada yang seharusnya.

Sistem Internal Tidak Harus Mengetahui Semuanya

Label “internal” sering membuat sebuah aplikasi memperoleh kepercayaan terlalu besar. Padahal, setiap sistem memiliki pengguna, administrator, vendor, konfigurasi, dan tingkat pemeliharaan yang berbeda.

Aplikasi yang hanya digunakan oleh pegawai belum tentu terbebas dari risiko. Akun pegawai dapat diambil alih. Kredensial teknis dapat bocor. Server internal dapat menggunakan komponen yang sudah tidak diperbarui. Vendor juga dapat memiliki akses administratif yang tidak lagi diawasi.

Karena itu, lokasi jaringan tidak seharusnya menjadi satu-satunya alasan untuk mempercayai sebuah sistem.

Prinsip Zero Trust menempatkan setiap permintaan sebagai aktivitas yang perlu diverifikasi. Identitas sistem harus diketahui, aksesnya harus memiliki tujuan, dan data yang diberikan harus dibatasi sesuai kebutuhan.

Pendekatan ini tidak berarti setiap sistem harus dicurigai secara berlebihan. Tujuannya adalah mencegah satu aplikasi yang mengalami kompromi menjadi jalan masuk menuju seluruh data perusahaan.

Attack Surface Mengikuti Pergerakan Data

Ketika data tersebar, penyerang tidak harus menyerang sistem utama yang memiliki perlindungan paling kuat. Mereka dapat memilih sistem lain yang menyimpan salinan data serupa tetapi memiliki pengamanan lebih lemah.

Target tersebut dapat berupa:

• aplikasi lama yang jarang diperbarui;
• dashboard internal dengan kontrol akses sederhana;
• server staging;
• akun vendor;
• penyimpanan cloud pihak ketiga;
• endpoint API yang tidak terdokumentasi;
• file ekspor yang tersimpan terlalu lama;
• sistem monitoring yang mencatat payload sensitif.

Berbagai laporan insiden dan kajian keamanan pihak ketiga menunjukkan bahwa risiko dapat menyebar melalui organisasi yang saling terhubung. Sebuah perusahaan mungkin telah melindungi sistem utamanya dengan baik, tetapi tetap terdampak ketika penyedia teknologi atau aplikasi pendukung mengalami kebocoran.

Luasnya dampak tersebut sering disebut sebagai blast radius. Semakin banyak tempat yang menerima data, semakin luas pula dampak yang mungkin terjadi ketika salah satu tempat mengalami kompromi.

Minimalisasi data membantu memperkecil dampak tersebut. Sistem yang tidak menyimpan data sensitif tidak akan kehilangan data itu ketika diretas.

Enkripsi Bukan Jawaban untuk Data yang Tidak Dibutuhkan

Enkripsi merupakan kontrol penting dalam keamanan integrasi sistem. Data perlu dilindungi ketika dikirim maupun disimpan.

Namun, enkripsi tidak menjawab pertanyaan mengenai kebutuhan.

Jika aplikasi absensi tidak membutuhkan nomor rekening pegawai, mengenkripsi pengiriman nomor rekening tersebut tidak membuat prosesnya menjadi tepat. Sistem penerima tetap harus membuka data agar dapat memproses atau menampilkannya.

Masalah utamanya bukan apakah data dikirim secara aman, melainkan mengapa data tersebut ikut dikirim.

Setiap kontrol memiliki fungsi berbeda. Enkripsi melindungi kerahasiaan data. Autentikasi memastikan identitas peminta. Otorisasi menentukan hak akses. Masa retensi mengatur berapa lama data disimpan. Sementara itu, minimalisasi data membatasi informasi sejak awal agar hanya data yang relevan yang diproses.

Kontrol-kontrol tersebut harus digunakan bersama. Salah satunya tidak dapat menggantikan yang lain.

API yang Aman Perlu Membatasi Sampai Tingkat Field

Banyak perusahaan telah menerapkan autentikasi pada API. Namun, token yang valid belum tentu berarti sistem penerima berhak memperoleh seluruh informasi dalam sebuah objek.

Sebagai contoh, objek pegawai dapat berisi ID, nama, unit kerja, alamat, kontak keluarga, rekening, jabatan, dan gaji. Aplikasi absensi mungkin hanya membutuhkan ID, nama, unit kerja, dan status aktif. Sistem payroll memerlukan rekening serta komponen gaji, tetapi tidak selalu membutuhkan alamat atau kontak keluarga.

Otorisasi dengan demikian tidak cukup berhenti pada tingkat endpoint. Pembatasan juga perlu diterapkan pada objek dan field yang dikembalikan.

OWASP API Security Top 10 menempatkan kegagalan otorisasi pada tingkat properti objek sebagai salah satu risiko utama API. Kondisi ini dapat membuat pengguna atau sistem menerima informasi sensitif yang tidak berkaitan dengan kewenangannya.

Risiko tersebut sering tidak terlihat pada antarmuka aplikasi. Tampilan hanya menunjukkan beberapa informasi, tetapi respons API di belakangnya masih membawa seluruh data. Seseorang yang memeriksa lalu lintas jaringan dapat melihat informasi yang disembunyikan oleh antarmuka.

Karena itu, penyaringan data harus dilakukan pada sisi server. Aplikasi penerima tidak boleh menjadi pihak yang menentukan sendiri field mana yang akan ditampilkan dan mana yang akan diabaikan.

Hubungkan Proses Bisnis, Bukan Seluruh Basis Data

Integrasi yang baik tidak harus memindahkan seluruh data sumber. Dalam banyak situasi, sistem penerima hanya membutuhkan hasil, status, atau referensi.

Dashboard manajemen, misalnya, mungkin hanya membutuhkan jumlah transaksi dan nilai agregat. Sistem tersebut tidak perlu menyimpan seluruh detail pelanggan.

Aplikasi pihak ketiga mungkin hanya perlu mengetahui bahwa identitas pengguna telah diverifikasi. Aplikasi itu tidak harus menerima salinan dokumen identitas.

Sistem perjalanan dinas mungkin membutuhkan unit kerja dan status pegawai. Informasi mengenai gaji, rekening, atau anggota keluarga tidak perlu ikut dikirim.

Prinsip tersebut dapat diterapkan melalui beberapa pendekatan:

• menyediakan endpoint khusus berdasarkan tujuan;
• menggunakan daftar field yang diizinkan;
• mengirimkan data agregat;
• menggunakan token atau kode referensi;
• menerapkan data masking;
• melakukan pseudonimisasi;
• memberikan akses sementara;
• memproses data tanpa menyimpan kembali;
• membatasi scope token;
• menghapus akses ketika tidak lagi digunakan.

Pendekatan ini mungkin membutuhkan perencanaan lebih matang. Namun, hasilnya adalah arsitektur yang lebih mudah dikendalikan dan memiliki risiko lebih kecil.

Data Contract Harus Menjelaskan Batas Penggunaan

Data contract sering hanya berisi nama field, format, tipe data, dan contoh respons. Dokumentasi seperti itu memang membantu integrasi secara teknis, tetapi belum cukup untuk mengendalikan keamanan data.

Data contract seharusnya juga menjelaskan:

• sistem yang boleh meminta data;
• tujuan penggunaan setiap field;
• klasifikasi sensitivitas;
• kondisi pemberian akses;
• apakah data boleh disimpan;
• berapa lama data dapat disimpan;
• apakah data boleh diteruskan;
• pihak yang bertanggung jawab;
• prosedur perubahan;
• mekanisme penghapusan.

Dengan ketentuan tersebut, penambahan field tidak lagi dianggap sebagai perubahan teknis biasa. Tim perlu mempertimbangkan apakah sistem penerima benar-benar membutuhkan informasi tambahan dan apakah kontrolnya telah memadai.

Data contract akhirnya menjadi batas kepercayaan, bukan sekadar petunjuk bagi developer.

Minimisasi Data Harus Dimulai Sebelum Kode Ditulis

Membatasi data setelah integrasi selesai sering lebih sulit. Sistem penerima mungkin sudah bergantung pada struktur respons lama. Data juga dapat terlanjur tersebar ke database, log, backup, dan platform analitik.

Karena itu, pembahasan mengenai kebutuhan data harus dimulai pada tahap requirement dan desain.

Sebelum integrasi disetujui, tim perlu menjawab beberapa pertanyaan:

1. Proses bisnis apa yang ingin dijalankan?
2. Data minimum apa yang diperlukan?
3. Apakah sistem membutuhkan data mentah atau cukup hasil pemrosesan?
4. Apakah data perlu disimpan oleh sistem penerima?
5. Siapa yang dapat mengaksesnya?
6. Berapa lama data dibutuhkan?
7. Apakah data akan masuk ke log dan backup?
8. Apakah informasi dapat diganti dengan referensi atau data agregat?
9. Bagaimana akses dihentikan?
10. Bagaimana data dihapus setelah tujuan pemrosesan berakhir?

Pertanyaan tersebut juga relevan dengan pelindungan data pribadi di Indonesia. Undang-Undang Nomor 27 Tahun 2022 menempatkan pelindungan data sebagai tanggung jawab dalam seluruh rangkaian pemrosesan. Artinya, perusahaan perlu mempertimbangkan keamanan sejak data diperoleh, digunakan, disimpan, dikirim, hingga dimusnahkan.

Perusahaan tidak cukup hanya mengetahui bahwa data diproses. Perusahaan juga perlu memahami alasan, tujuan, lokasi, dan pihak yang terlibat dalam pemrosesan tersebut.

Peta Integrasi Belum Tentu Menjadi Peta Data

Daftar integrasi biasanya menunjukkan aplikasi sumber, aplikasi tujuan, metode koneksi, serta endpoint yang digunakan. Informasi tersebut belum menjelaskan data apa yang sebenarnya bergerak.

Perusahaan membutuhkan peta aliran data yang memuat:

• kategori data;
• sistem asal;
• sistem penerima;
• tujuan pemrosesan;
• lokasi penyimpanan;
• pihak yang memiliki akses;
• aliran menuju pihak ketiga;
• masa retensi;
• kontrol keamanan;
• metode penghapusan.

Pemetaan ini membantu perusahaan menemukan data yang berpindah tanpa tujuan yang jelas. Proses tersebut juga dapat mengungkap integrasi lama yang masih aktif, akun teknis yang tidak lagi digunakan, dan salinan data yang melewati masa retensinya.

Tanpa visibilitas tersebut, perusahaan hanya mengetahui bahwa sistem terhubung. Perusahaan belum tentu mengetahui sejauh mana datanya telah tersebar.

Log dan Sistem Monitoring Dapat Menjadi Salinan yang Terlupakan

Logging dibutuhkan untuk pemantauan, audit, dan penanganan insiden. Namun, konfigurasi yang kurang tepat dapat membuat log menyimpan payload API secara lengkap.

Akibatnya, data sensitif yang sudah dilindungi pada database utama justru muncul pada platform monitoring. Akses ke platform tersebut mungkin lebih luas karena digunakan oleh developer, administrator, vendor, atau tim operasional.

Masalah serupa dapat terjadi pada pesan kesalahan. Respons error dapat menampilkan struktur data, token, identitas pengguna, atau informasi internal yang tidak dibutuhkan.

Karena itu, pengamanan integrasi perlu memeriksa bukan hanya database sumber dan penerima, tetapi juga jejak data yang tercipta selama proses komunikasi.

Data sensitif sebaiknya disamarkan atau dikeluarkan dari log. Masa retensi log juga perlu disesuaikan dengan tujuan audit dan kebutuhan operasional.

Pengujian Keamanan Harus Memeriksa Isi Respons

Pengujian API tidak cukup hanya memastikan endpoint menggunakan HTTPS dan meminta token autentikasi. Tim perlu memeriksa isi respons dari perspektif pengguna atau sistem dengan kewenangan berbeda.

Beberapa skenario yang perlu diuji meliputi:

• API mengirimkan field sensitif yang tidak diperlukan;
• pengguna dapat membaca objek milik pengguna lain;
• role biasa menerima data khusus administrator;
• token memiliki scope terlalu luas;
• filter dapat dimanipulasi;
• data dapat diambil dalam jumlah besar;
• payload sensitif masuk ke log;
• endpoint lama masih dapat diakses;
• respons error membocorkan informasi internal;
• integrasi pihak ketiga memiliki akses permanen.

Pengujian juga perlu melihat hubungan antarsistem. Endpoint yang terlihat aman ketika diperiksa sendiri dapat menghasilkan risiko ketika responsnya diteruskan, disimpan, atau digabungkan dengan sumber data lain.

Inilah alasan penetration testing tetap dibutuhkan. Pengujian independen dapat membantu perusahaan melihat integrasi dari sudut pandang penyerang, termasuk kemungkinan penyalahgunaan akses yang secara teknis terlihat sah.

Keberhasilan Integrasi Perlu Diukur Secara Berbeda

Keberhasilan proyek integrasi biasanya dinilai dari kecepatan pertukaran data, kestabilan koneksi, dan pengurangan pekerjaan manual. Metrik tersebut penting, tetapi belum menggambarkan kualitas perlindungan data.

Perusahaan juga perlu mengukur:

• jumlah field sensitif pada setiap integrasi;
• jumlah sistem yang menyimpan salinan data;
• API yang belum menggunakan daftar field terkontrol;
• integrasi tanpa tujuan pemrosesan terdokumentasi;
• token dengan hak akses berlebihan;
• data sensitif yang masuk ke log;
• data yang melewati masa retensi;
• endpoint tidak aktif yang masih tersedia;
• waktu pencabutan akses pihak ketiga;
• temuan excessive data exposure.

Metrik tersebut membantu tim melihat apakah efisiensi bisnis dicapai dengan tetap menjaga batas data.

Integrasi yang baik bukan sekadar integrasi yang mampu mengirimkan informasi dengan cepat. Integrasi juga harus mampu menahan informasi yang tidak seharusnya ikut dikirimkan.

Sistem Boleh Terhubung, tetapi Data Tetap Memerlukan Batas

Perusahaan tidak perlu menghentikan integrasi untuk mengurangi risiko. Sistem yang terhubung tetap dibutuhkan agar proses bisnis lebih cepat, konsisten, dan mudah dikembangkan.

Hal yang perlu diubah adalah anggapan bahwa setiap sistem yang terhubung boleh menerima seluruh data yang tersedia.

Setiap pertukaran informasi harus memiliki tujuan. Setiap field perlu memiliki alasan. Setiap salinan harus diketahui lokasinya. Setiap akses harus dapat dihentikan ketika tidak lagi diperlukan.

Ketika prinsip tersebut diterapkan, minimalisasi data tidak menjadi penghambat inovasi. Justru, pendekatan ini membantu perusahaan membangun arsitektur yang lebih terkontrol, mudah diaudit, dan memiliki dampak lebih kecil ketika terjadi insiden.

Sistem boleh semakin terhubung, tetapi data tetap harus memiliki batas. Integrasi yang matang bukan integrasi yang mampu mengirimkan semuanya, melainkan integrasi yang mengetahui informasi apa yang tidak perlu ikut berpindah.

Evaluasi Keamanan Integrasi Bersama Fourtrezz

Fourtrezz dapat membantu perusahaan mengevaluasi keamanan aplikasi, API, dan infrastruktur melalui layanan Penetration Testing dan Vulnerability Assessment. Pengujian dapat disesuaikan dengan karakteristik sistem, role pengguna, integrasi, aliran data, dan risiko perusahaan.

Fourtrezz juga menyediakan layanan IT Development untuk mendukung pembangunan dan pengembangan sistem yang mempertimbangkan kebutuhan bisnis sekaligus aspek keamanan.

Kolaborasi dengan Fourtrezz dapat membantu perusahaan menemukan akses berlebihan, kelemahan otorisasi, paparan data melalui API, dan risiko lain yang mungkin tidak terlihat selama pengujian fungsional.

Hubungi Fourtrezz:

Website: www.fourtrezz.co.id
Telepon/WhatsApp: +62 857-7771-7243
Email: [email protected]