Praktik integrasi informal seperti penggunaan spreadsheet, akun bersama, dan approval via chat dapat membuka celah keamanan ketika tidak disertai kontrol akses dan pencatatan aktivitas yang memadai. Verizon 2025 DBIR mencatat kredensial yang dikompromikan sebagai vektor akses awal pada 22% insiden yang ditinjau. Karena itu, organisasi perlu memperkuat kontrol akses, jejak aktivitas, dan validasi approval lintas sistem.
Tidak semua proses lintas sistem di perusahaan berjalan lewat integrasi resmi. Data pembayaran diekspor dari ERP ke spreadsheet lalu dikirim lewat email. Satu akun dipakai bergantian oleh beberapa orang di tim. Skrip otomatis berjalan dengan kredensial pribadi seorang engineer. Persetujuan pembayaran diberikan cukup dengan membalas “OK” di aplikasi pesan instan.
Jalur-jalur seperti ini terasa praktis dan sering kali lahir dari kebutuhan nyata, misalnya karena integrasi belum tersedia atau proses harus segera berjalan. Masalahnya, jejak dan kontrolnya hampir selalu terbatas. Ketika terjadi kesalahan atau penyalahgunaan, organisasi kesulitan menjawab pertanyaan paling dasar: siapa melakukan apa, kapan, dan atas kewenangan siapa.
Untuk memahami kapan praktik informal seperti ini masih bisa ditoleransi dan kapan mulai menjadi celah keamanan, tim Mekari Officeless mewawancarai Rein Rachman Putra, Solutions Engineer, Cybersecurity di Cisco.
Rein memiliki pengalaman lebih dari 10 tahun di bidang jaringan dan keamanan, mulai dari NOC engineer, presales, solutions architect, hingga perannya saat ini yang berfokus pada transformasi SASE (Secure Access Service Edge) dan Zero Trust bagi institusi keuangan (BFSI) di kawasan ASEAN. Ia memegang sertifikasi CISM (Certified Information Security Manager) dan CCNP Security.
Artikel ini merupakan bagian kedua dari seri tiga artikel tentang integrasi sistem di perusahaan enterprise. Setelah membahas keamanan integrasi sistem, seri ini berlanjut dengan mengulas risiko keamanan yang muncul dalam praktik integrasi sehari-hari:
- Risiko keamanan integrasi informal: bagaimana praktik seperti pertukaran data melalui spreadsheet, penggunaan akun bersama, dan approval di luar platform resmi dapat menciptakan celah keamanan dalam proses bisnis?
- Strategi Mengamankan Integrasi Sistem Enterprise: bagaimana menerapkan Zero Trust, mengevaluasi keamanan aplikasi pihak ketiga, dan mengatur kewenangan AI agent dalam workflow bisnis?
Pembahasan ini menjadi dasar untuk memahami bagaimana organisasi dapat mengidentifikasi celah keamanan dalam alur kerja yang melibatkan banyak sistem.
Menilai Risiko Keamanan Integrasi Sistem di Luar Platform Resmi
Ketika membahas risiko penggunaan spreadsheet atau aplikasi chat, salah satu respons yang kerap muncul adalah membatasi atau bahkan melarang penggunaannya.
Namun, Rein menawarkan pendekatan yang berbeda. Baginya, persoalan utamanya bukan terletak pada alat yang digunakan, melainkan pada bagaimana organisasi mengelola kontrol atas data dan aktivitas yang berlangsung melalui alat tersebut.
Saya akan menilai kontrolnya, bukan langsung menghakimi alat yang digunakan.
Rein mengakui bahwa spreadsheet masih bisa sesuai untuk kebutuhan tertentu. Aplikasi chat juga tetap bisa dipakai untuk koordinasi antartim. Keduanya tidak otomatis berbahaya hanya karena tidak terhubung secara formal ke sistem inti.
Cara pandang ini penting bagi pemimpin IT karena dua alasan.
- Pertama, larangan total terhadap alat yang sudah melekat dalam kebiasaan kerja jarang efektif dan cenderung mendorong praktik yang lebih tersembunyi.
- Kedua, fokus pada alat membuat organisasi melewatkan pertanyaan yang sebenarnya lebih penting, yaitu apakah data dan keputusan yang mengalir lewat alat tersebut masih bisa dikendalikan.
Kapan Jalur Informal Mulai Menjadi Masalah Keamanan?
Menurut Rein, masalah muncul ketika data sensitif atau keputusan penting berpindah tanpa akses dan pencatatan yang jelas. Batas inilah yang membedakan penggunaan spreadsheet yang wajar dengan yang berisiko.
Ia memberi ilustrasi yang dekat dengan keseharian tim keuangan. Sebuah spreadsheet berisi data pembayaran diekspor dari sistem, lalu dikirim ke beberapa orang.
Sejak saat itu, organisasi perlu bisa menjawab dua pertanyaan:
- Siapa yang masih memegang salinannya? Setiap penerima kini menyimpan data pembayaran di perangkat, kotak masuk email, atau folder pribadinya. Hak akses di ERP tidak lagi berlaku untuk salinan-salinan tersebut.
- Versi mana yang dipakai untuk mengambil keputusan? Ketika file diedit dan diteruskan berkali-kali, sulit memastikan apakah keputusan pembayaran didasarkan pada data yang benar dan terbaru.
Kedua pertanyaan ini menunjukkan blind spot yang khas dari jalur informal. Data sudah keluar dari sistem yang memiliki kontrol akses, sementara jejak tentang siapa yang membaca, mengubah, atau meneruskannya hampir tidak ada.
Blind spot yang sering tidak terlihat dalam integrasi sistem informal
Jika kerangka Rein diterapkan pada praktik informal yang umum ditemui di perusahaan, blind spot-nya dapat dirangkum sebagai berikut:
Risiko akun dan kredensial yang disalahgunakan juga tercermin dalam data global.
Akun bersama dan kredensial pribadi yang dipakai untuk menjalankan proses memperbesar dampak jika satu kredensial saja bocor, karena sulit dilacak siapa yang memakainya dan sulit dicabut tanpa mengganggu pekerjaan.
Jangan Terjebak Rasa Aman: Integrasi Terkelola Belum Tentu Aman
Dibandingkan jalur informal, integrasi data yang dikelola secara terstruktur memiliki keunggulan yang jelas. Menurut Rein, akses dan aktivitas dalam integrasi terkelola dapat dibatasi serta ditelusuri. Organisasi bisa menentukan data apa yang boleh mengalir, ke mana, dan mencatat setiap aktivitas penting.
Namun, Rein juga mengingatkan bahwa integrasi bukan jaminan keamanan. Integrasi yang menggunakan satu akun dengan hak terlalu luas tetap membawa risiko.
Bisa dikatakan, dalam kondisi ini, persoalan akun bersama sebenarnya tidak hilang, melainkan hanya berpindah dari manusia ke mesin. Jika kredensial akun tersebut bocor, dampaknya bisa menjangkau seluruh data dan fungsi yang bisa diakses akun itu.
Prinsip ini sejalan dengan NIST SP 800-207: Zero Trust Architecture, yang menegaskan bahwa akun maupun aset tidak boleh diberi kepercayaan secara implisit hanya karena lokasinya di jaringan atau kepemilikannya. Autentikasi dan otorisasi perlu dilakukan sebelum akses ke sumber daya perusahaan dibuka, termasuk ketika yang mengakses adalah sebuah aplikasi.
Empat kriteria untuk menilai proses lintas sistem
Alih-alih membandingkan “informal” dan “terintegrasi” secara hitam-putih, Rein menawarkan kriteria yang bisa diterapkan pada keduanya.
Jadi kriterianya: apakah proses itu punya owner, batas akses, jejak aktivitas, dan cara menghentikannya?
Keempat kriteria tersebut dapat diterjemahkan menjadi pertanyaan evaluasi berikut.
| Kriteria | Pertanyaan yang perlu dijawab |
|---|---|
| Owner | Siapa yang bertanggung jawab atas proses ini dan bisa menjelaskan mengapa proses ini ada? |
| Batas akses | Data dan tindakan apa saja yang bisa dijangkau, dan apakah itu sesuai dengan kebutuhan prosesnya? |
| Jejak aktivitas | Apakah kita bisa menelusuri siapa atau apa yang membaca, mengubah, dan meneruskan data? |
| Cara menghentikan | Jika terjadi masalah, bisakah akses atau proses ini dihentikan dengan cepat? |
Kelebihan kerangka ini adalah netralitasnya. Spreadsheet yang dikelola dengan owner jelas, akses terbatas, dan pencatatan yang memadai bisa lolos evaluasi. Sebaliknya, integrasi canggih yang memakai satu akun super tanpa owner justru bisa gagal.
Mengapa Kontrol Keamanan pada Jalur Informal Lebih Sulit Ditegakkan?
Jika kriterianya bisa diterapkan pada alat apa pun, mengapa jalur informal tetap dianggap lebih berisiko? Rein menjawabnya dengan menunjuk pada siapa yang menjalankan kontrol tersebut.
Pada tools tradisional seperti spreadsheet, email, dan aplikasi chat, pengelolaan owner, batas akses, jejak aktivitas, dan cara menghentikan proses sangat sulit dilakukan tanpa disiplin kontrol dari penggunanya sendiri.
Sistem tidak menegakkan aturan apa pun. Keamanan bergantung pada apakah setiap orang ingat untuk tidak meneruskan file, menghapus salinan lama, atau mencatat keputusan yang diambil.
Menurut Rein, ketergantungan inilah yang menjadikan tools tradisional sebagai risiko dan celah keamanan baru. Satu orang yang lupa, terburu-buru, atau tidak memahami sensitivitas data sudah cukup untuk membuka celah.
Bagi organisasi enterprise, implikasinya cukup jelas. Semakin penting data atau keputusan yang mengalir dalam sebuah proses, semakin kecil ruang yang sebaiknya diberikan pada kontrol yang bergantung pada kebiasaan individu. Proses semacam itu membutuhkan kontrol yang ditegakkan oleh sistem, bukan hanya oleh niat baik penggunanya.
Apa risikonya jika approval penting dilakukan di luar sistem?
Persetujuan bernilai tinggi, seperti pembayaran, perubahan data vendor, atau pemberian akses ke dokumen sensitif, menuntut kepastian bahwa pihak yang menyetujui benar-benar pihak yang berwenang.
Ketika persetujuan dilakukan lewat kanal di luar sistem utama, misalnya pesan singkat “OK, lanjut” di aplikasi chat, kepastian itu menjadi sulit dibuktikan.
Rein memecah persoalan ini menjadi tiga pertanyaan terpisah yang perlu dijawab untuk setiap approval penting:
- Apakah orangnya benar? Pihak yang menyetujui harus benar-benar orang yang dimaksud, bukan orang lain yang memakai akun atau perangkatnya.
- Apakah dia berwenang? Identitas yang benar belum tentu berarti kewenangan yang cukup. Seorang manajer bisa saja asli, tetapi nilai transaksinya melebihi batas approval yang ia miliki.
- Apakah dia memahami transaksi yang disetujui? Persetujuan hanya bermakna jika pihak yang menyetujui melihat dan memahami apa yang sebenarnya ia setujui.
Pemisahan ini penting karena ketiga hal tersebut mudah dianggap sudah terpenuhi selama approval datang dari nomor atau akun yang dikenal. Padahal, approval melalui chat umumnya hanya memberi petunjuk tentang pertanyaan pertama, itu pun tanpa jaminan yang kuat.
Login yang kuat saja tidak cukup
Rein juga meluruskan anggapan bahwa autentikasi yang kuat sudah menyelesaikan persoalan approval.
Login yang kuat membantu memastikan identitas, tetapi sistem tetap harus memeriksa kewenangan dan batas approval-nya.
Artinya, autentikasi dan otorisasi adalah dua hal yang berbeda. NIST dalam SP 800-207 pun memperlakukan autentikasi dan otorisasi sebagai fungsi yang terpisah, yang keduanya harus dijalankan sebelum akses ke sumber daya perusahaan diberikan.
Selain identitas dan kewenangan, Rein menekankan pentingnya konteks transaksi. Pengguna perlu melihat detail yang penting, seperti nominal dan rekening tujuan, sebelum menyetujui.
Jika detail tersebut berubah setelah persetujuan diberikan, persetujuannya perlu divalidasi ulang. Tanpa mekanisme ini, approval yang sah bisa “dipakai” untuk transaksi yang berbeda dari yang sebenarnya disetujui.
Bagaimana Membuat Approval Aman Tanpa Merepotkan Pengguna?
Risiko tersebut tidak hanya muncul ketika data berpindah dari satu sistem ke sistem lain. Risiko yang sama juga dapat terjadi ketika keputusan bisnis, seperti persetujuan pembayaran atau perubahan data vendor, dilakukan melalui kanal yang tidak memiliki kontrol otorisasi memadai.
Salah satu alasan approval lewat chat begitu populer adalah kecepatannya. Atasan bisa menyetujui dari mana saja, cukup dengan satu balasan. Jika proses yang lebih aman terasa jauh lebih rumit, pengguna cenderung kembali ke jalur informal.
Rein tidak menyarankan untuk meninggalkan kanal yang nyaman sama sekali. Ia memisahkan kanal notifikasi dari proses persetujuan. Notifikasi bisa tetap dikirim melalui kanal yang biasa digunakan pengguna, tetapi tindakan menyetujuinya dilakukan dalam proses yang terautentikasi.
Dari jawaban Rein, alur approval yang memadai untuk transaksi penting dapat digambarkan sebagai berikut:
- Notifikasi dikirim melalui kanal yang nyaman, misalnya email atau aplikasi pesan, berisi pemberitahuan bahwa ada permintaan yang perlu ditinjau.
- Pengguna diarahkan ke proses approval yang terautentikasi, bukan menyetujui langsung dengan membalas pesan.
- Sistem memeriksa kewenangan dan batas approval pengguna tersebut, tidak hanya identitasnya.
- Pengguna melihat detail penting transaksi, seperti nominal dan rekening tujuan, sebelum memberikan persetujuan.
- Verifikasi tambahan diterapkan untuk tindakan berisiko tinggi. Teknologi seperti multi-factor authentication (MFA) dapat membantu di tahap ini.
- Pemeriksaan independen terpisah dipertimbangkan untuk perubahan rekening vendor atau pembayaran besar, sesuai kebijakan perusahaan.
- Jika detail berubah setelah disetujui, persetujuan divalidasi ulang.
Verifikasi tambahan sebaiknya proporsional
Poin penting dari pendekatan ini adalah proporsionalitas. Verifikasi tambahan seperti MFA tidak harus diterapkan pada setiap approval, melainkan pada tindakan yang berisiko tinggi. Dengan begitu, approval rutin tetap berjalan cepat, sementara transaksi yang dampaknya besar mendapat lapisan perlindungan ekstra.
Untuk kasus yang paling sensitif, seperti perubahan rekening vendor dan pembayaran bernilai besar, Rein menambahkan satu lapisan lagi: ia akan mempertimbangkan pemeriksaan independen terpisah, sesuai kebijakan perusahaan.
Logikanya, jika satu orang atau satu kanal berhasil dikompromikan, masih ada pihak kedua yang memeriksa sebelum dana atau data berpindah.
Pendekatan ini relevan dengan temuan Verizon 2025 DBIR bahwa kredensial yang dikompromikan masih menjadi salah satu pintu masuk utama kebocoran data. Ketika kredensial seseorang bisa dicuri, approval yang hanya bergantung pada “siapa yang mengirim pesan” menjadi sangat rentan.
Apa Artinya bagi Pemimpin IT?
Percakapan dengan Rein menunjukkan bahwa risiko terbesar dalam proses lintas sistem sering kali tidak terletak pada serangan yang canggih, melainkan pada praktik sehari-hari yang terasa wajar. Spreadsheet yang diteruskan, akun yang dipakai bersama, dan approval lewat chat adalah titik-titik di mana kontrol berpindah dari sistem ke kebiasaan individu.
Bagi IT Director, IT Manager, Enterprise Architect, dan Head of Digital Transformation, mengenali masalah ini adalah langkah pertama. Beberapa pertanyaan berikut dapat membantu memetakan seberapa besar paparan risikonya di organisasi Anda:
- Proses mana yang masih memindahkan data pembayaran, data vendor, atau data sensitif lain melalui ekspor spreadsheet?
- Apakah masih ada akun yang dipakai bersama, atau skrip yang berjalan dengan kredensial pribadi?
- Untuk setiap proses lintas sistem yang kritis, apakah ada owner, batas akses, jejak aktivitas, dan cara menghentikannya?
- Approval mana yang masih diberikan lewat aplikasi pesan tanpa melalui proses yang terautentikasi?
- Apakah sistem approval memeriksa kewenangan dan batas approval, bukan hanya identitas pengguna?
- Apakah detail transaksi seperti nominal dan rekening tujuan terlihat jelas oleh pihak yang menyetujui, dan apakah perubahan setelah approval memicu validasi ulang?
Selain kontrol pada proses integrasi, organisasi juga perlu mempertimbangkan keamanan platform yang digunakan untuk membangun dan menjalankan workflow digital. Mekari Officeless menghadirkan kapabilitas Security & Governance untuk mendukung kebutuhan tersebut, mulai dari sertifikasi ISO 27001 sebagai standar manajemen keamanan informasi, registrasi PSE Kominfo, hingga end-to-end encryption untuk melindungi data saat dikirim maupun disimpan.
Dengan dukungan kapabilitas tersebut, perusahaan dapat mengembangkan aplikasi dan workflow lintas departemen dengan mempertimbangkan aspek keamanan informasi, kepatuhan, dan tata kelola sebagai bagian dari fondasi transformasi digital.
Referensi
- National Institute of Standards and Technology. (2020, August). Zero trust architecture (NIST Special Publication 800-207). https://doi.org/10.6028/NIST.SP.800-207
- Verizon Business. (2025). Additional 2025 DBIR research on credential stuffing.
