Seluruh komponen otomasi sudah mendapat persetujuan. Sumber data menggunakan aplikasi perusahaan, konektor tercantum dalam daftar yang diizinkan, dan alur berhasil melewati pengujian fungsi.

Namun, laporan pelanggan justru terkirim ke ruang penyimpanan milik akun pribadi.

Tidak ada konektor baru yang dipasang. Tidak ada kata sandi yang dibobol. Alur menjalankan instruksi yang dikonfigurasi, tetapi tujuan pengirimannya berada di luar batas pengelolaan perusahaan.

Ilustrasi ini memperlihatkan kelemahan dalam cara organisasi menilai keamanan low-code. Persetujuan terhadap konektor sering dianggap sekaligus sebagai persetujuan terhadap seluruh pengiriman yang dapat dilakukan melalui konektor tersebut.

Padahal, keputusan itu memiliki cakupan berbeda.

Konektor yang diizinkan tetap dapat mengirimkan data ke penerima yang tidak berwenang apabila tujuan dan konteks pengirimannya tidak dibatasi.

Persetujuan Konektor Masih Menyisakan Pertanyaan Penting

Konektor membantu aplikasi low-code berinteraksi dengan layanan lain, seperti penyimpanan berkas, surat elektronik, basis data, atau API. Kemampuan tersebut mempercepat pengembangan otomasi karena pembuat alur tidak perlu membangun seluruh integrasi dari awal.

Namun, satu jenis konektor dapat digunakan untuk berbagai kebutuhan dan tujuan.

Konektor penyimpanan dapat mengarah ke ruang kerja perusahaan atau akun di luar pengelolaannya. Konektor HTTP dapat memanggil API internal maupun alamat eksternal. Konektor surat elektronik dapat mengirimkan dokumen kepada pegawai, vendor, atau penerima yang keliru.

Karena itu, persetujuan konektor perlu diikuti pertanyaan yang lebih terperinci: data apa yang boleh dikirim, melalui tindakan apa, menuju lokasi mana, dan atas kewenangan siapa?

Tanpa batas tersebut, daftar konektor yang diizinkan hanya memberikan sebagian gambaran keamanan integrasi.

Perusahaan mengetahui sarana yang digunakan, tetapi belum tentu mengetahui apakah setiap penggunaannya sesuai dengan tujuan bisnis.

Domain yang Dikenal Belum Membuktikan Penerimanya Berwenang

Layanan yang memiliki reputasi baik dapat menampung banyak pelanggan dengan kebijakan akses berbeda. Mengirimkan berkas ke layanan tersebut belum membuktikan bahwa berkas masuk ke akun yang dikelola perusahaan.

Ruang kerja pribadi dan ruang kerja organisasi dapat berada pada penyedia yang sama. Demikian pula, folder terbatas dan folder yang dapat dibagikan secara luas dapat menggunakan infrastruktur layanan yang sama.

Pemeriksaan tujuan perlu menjangkau identitas akun, organisasi atau tenant, ruang kerja, serta objek penerima yang relevan.

Sebagai contoh, perusahaan mungkin mengizinkan laporan penjualan dikirim ke folder analitik internal. Persetujuan itu tidak otomatis mencakup folder lain yang dapat diakses mitra eksternal, meskipun keduanya berada pada layanan penyimpanan yang sama.

Hal serupa berlaku pada kanal percakapan dan daftar penerima surel. Tujuan yang terlihat internal dapat memiliki anggota tamu atau mekanisme penerusan yang memperluas jangkauan informasi.

Keamanan pengiriman data bergantung pada siapa yang akhirnya dapat mengaksesnya.

Tujuan Dinamis Mengubah Risiko Setelah Alur Disetujui

Sebagian alur menggunakan tujuan tetap yang ditulis langsung dalam konfigurasi. Alur lain mengambil alamat tujuan dari variabel, tabel pengaturan, formulir, atau hasil proses sebelumnya.

Fleksibilitas tersebut berguna ketika satu otomasi melayani banyak unit bisnis. Namun, keputusan pengiriman kemudian bergantung pada sumber nilai tujuan dan pihak yang dapat mengubahnya.

Bayangkan sebuah alur yang membaca alamat webhook dari tabel konfigurasi. Pada saat peninjauan, alamat itu menunjuk ke layanan resmi perusahaan. Setelah alur disetujui, pengguna yang memiliki akses mengubah isinya.

Jika perubahan tersebut tidak diperiksa, alur yang sama dapat mulai mengirimkan data ke penerima berbeda.

Dokumentasi Microsoft Power Platform mengenai fitur pratinjau penyaringan endpoint memberikan contoh batas yang perlu diperhatikan. Dokumentasi tersebut menyebutkan bahwa aturan penyaringan tertentu mengevaluasi tujuan statis, sedangkan variabel lingkungan, masukan khusus, dan tujuan yang dibentuk secara dinamis saat eksekusi memiliki keterbatasan penegakan.

Keterangan ini berlaku pada fitur dan cakupan yang didokumentasikan. Perusahaan tetap perlu memeriksa perilaku platform, jenis alur, dan versi yang digunakan.

Implikasinya jelas: persetujuan rancangan tidak dapat menjadi satu-satunya bukti apabila tujuan pengiriman masih dapat berubah setelah peninjauan.

Kebijakan DLP Perlu Dibaca Bersama Batas Teknisnya

Kebijakan pencegahan kehilangan data atau DLP membantu organisasi mengendalikan penggunaan konektor dan hubungan antarlayanan. Namun, kemampuan setiap kebijakan perlu diperiksa sesuai implementasinya.

Pembatasan jenis konektor, pembatasan tindakan, dan penyaringan tujuan menangani persoalan yang berbeda.

Sebuah kebijakan dapat berhasil mencegah penggunaan konektor tertentu, tetapi belum tentu membatasi semua penerima pada konektor yang diizinkan. Kebijakan lain mungkin mendukung pembatasan tujuan hanya pada konektor atau bentuk konfigurasi tertentu.

Karena itu, pernyataan “DLP sudah aktif” perlu disertai bukti tentang perilaku yang benar-benar dicegah.

Apakah pengiriman ke akun pribadi ditolak? Apakah perubahan variabel tujuan ikut diperiksa? Apakah kebijakan tetap berlaku setelah alur dipindahkan ke lingkungan produksi?

Pengujian perlu menjawab pertanyaan tersebut pada konfigurasi yang digunakan perusahaan.

Pelajaran mengenai pentingnya konfigurasi juga terlihat dalam pemberitaan WIRED pada Agustus 2021 tentang paparan jutaan rekaman melalui portal Power Apps. Kasus historis tersebut berkaitan dengan akses publik pada portal, bukan pembatasan tujuan konektor. Relevansinya adalah bahwa penggunaan platform resmi tetap membutuhkan pengaturan akses yang tepat pada aplikasi yang dibangun di atasnya.

Keamanan Harus Mengikuti Data sampai ke Penerima

Pengendalian pengiriman perlu menghubungkan sumber, isi, tujuan, dan kewenangan pelaksana.

Pendekatan ini dapat dimulai dengan membatasi tujuan yang memang diperlukan oleh proses bisnis. Jika sebuah alur hanya bertugas mengirimkan laporan ke sistem analitik perusahaan, pilihan tujuan yang terlalu luas memerlukan alasan yang dapat dipertanggungjawabkan.

Selanjutnya, perusahaan perlu mengurangi data yang dikirim. Integrasi yang hanya membutuhkan jumlah transaksi tidak semestinya menerima seluruh profil pelanggan.

Minimisasi data membantu membatasi dampak apabila terjadi kesalahan konfigurasi. Perusahaan tetap perlu memastikan bahwa informasi yang tersisa sesuai dengan kebutuhan penerima.

Identitas koneksi juga perlu diperiksa. Kredensial berhak akses luas dapat membuat satu otomasi menjangkau data yang jauh lebih besar daripada kebutuhan tugasnya. Koneksi khusus dengan kewenangan terbatas membuat batas pemakaian lebih mudah dikelola.

Perubahan konfigurasi harus mendapat perhatian yang setara. Mengganti tujuan dari satu ruang kerja ke ruang kerja lain dapat mengubah penerima data tanpa mengubah nama konektor.

Karena itu, perubahan akun koneksi, webhook, folder, kanal, dan konfigurasi lingkungan perlu dinilai berdasarkan dampaknya terhadap aliran informasi.

Pengujian Harus Membuktikan ke Mana Data Benar-Benar Pergi

Evaluasi keamanan low-code perlu mengikuti perjalanan data dari sumber sampai tujuan. Memeriksa layar konfigurasi saja dapat melewatkan nilai yang baru dibentuk ketika alur dijalankan.

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

Untuk menguji alur pengiriman, gunakan data sintetis dengan penanda unik dan tujuan uji yang terkendali. Penanda tersebut membantu tim membuktikan komponen mana yang menerima data tanpa mengekspos informasi bisnis yang sebenarnya.

Beberapa skenario yang perlu dievaluasi meliputi:

• Penggantian tujuan resmi dengan akun lain pada penyedia layanan yang sama.
• Perubahan alamat webhook melalui variabel atau tabel konfigurasi.
• Pengiriman ke folder atau kanal yang memiliki anggota eksternal.
• Pemindahan alur dari lingkungan pengujian ke produksi dengan koneksi berbeda.
• Perubahan konfigurasi setelah persetujuan awal diberikan.
• Permintaan yang mengandung data lebih banyak daripada kebutuhan penerima.
• Pengalihan tujuan oleh layanan penerima, apabila mekanisme tersebut didukung oleh konektor.

Skenario tersebut merupakan rancangan pengujian yang perlu disesuaikan dengan kemampuan platform dan aturan perusahaan.

Bukti keberhasilan tidak cukup berupa pesan bahwa alur selesai dijalankan. Tim perlu memverifikasi tujuan akhir yang dapat diamati, identitas koneksi, jenis data yang terkirim, dan hasil penegakan kebijakan.

Riwayat eksekusi juga perlu diperiksa. Isi permintaan, respons, atau pesan kesalahan dapat menyimpan informasi sensitif. Akses dan masa penyimpanannya harus dikelola agar bukti operasional tidak menimbulkan paparan baru.

Persetujuan Integrasi Harus Memiliki Batas yang Terukur

Low-code memberi unit bisnis kemampuan membangun otomasi dengan cepat. Agar manfaatnya dapat dipertahankan, perusahaan perlu membuat batas penggunaan yang mudah dipahami sekaligus dapat diuji.

Setiap alur yang memindahkan data sensitif sebaiknya memiliki pemilik, tujuan bisnis, sumber informasi, penerima yang disetujui, dan prosedur perubahan. Dengan informasi tersebut, tim dapat menilai apakah perubahan konfigurasi masih berada dalam cakupan persetujuan.

Tanggung jawab juga perlu dibagi secara jelas. Pengelola platform menetapkan kemampuan teknis yang tersedia, pemilik data menentukan penggunaan yang diperbolehkan, dan pengelola alur memastikan implementasinya sesuai.

Daftar konektor yang diizinkan menjadi lebih berguna ketika dilengkapi bukti bahwa data hanya dikirim sesuai batas tersebut.

Persetujuan konektor merupakan awal pengendalian. Keamanannya harus dibuktikan sampai ke tujuan pengiriman.

Evaluasi Keamanan Integrasi Bersama Fourtrezz

Fourtrezz menyediakan layanan Penetration Testing dan Vulnerability Assessment untuk aplikasi web, API, jaringan, serta server. Layanan ini relevan untuk mengevaluasi aplikasi dan komponen integrasi yang mendukung otomasi perusahaan.

Diskusikan kerjasama dengan Fourtrezz untuk menentukan ruang lingkup pengujian sesuai arsitektur low-code yang digunakan. Cakupan dapat dibahas dengan mempertimbangkan endpoint yang dapat diuji, otorisasi, akun koneksi, konfigurasi tujuan, serta perpindahan data antar-API.

Melalui pengujian yang terarah, perusahaan dapat memperoleh bukti teknis untuk menilai risiko dan menentukan prioritas perbaikan integrasi.

Hubungi Fourtrezz:

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