Mengamankan integrasi sistem enterprise membutuhkan lebih dari sekadar koneksi antaraplikasi. IBM (2025) mencatat 63% organisasi yang mengalami kebocoran data belum memiliki kebijakan tata kelola AI atau masih menyusunnya, sementara 97% insiden kebocoran terkait AI terjadi pada organisasi tanpa kontrol akses AI yang memadai. Karena itu, perusahaan perlu menerapkan Zero Trust, mengevaluasi keamanan aplikasi pihak ketiga, dan menetapkan batas kewenangan AI agent.
Mengenali risiko dalam integrasi sistem adalah satu hal. Menentukan apa yang harus dilakukan, dari mana memulainya, dan bagaimana menilai aplikasi pihak ketiga yang akan terhubung ke sistem inti adalah tantangan yang berbeda.
Terlebih jika tim keamanan terbatas, integrasi sudah telanjur berkembang tanpa tata kelola yang jelas, dan AI agent mulai masuk ke dalam proses bisnis.
Artikel ini membahas sisi solusi dari persoalan tersebut berdasarkan wawancara kami dengan 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. Pengalamannya mendampingi proses evaluasi teknis di sektor dengan regulasi ketat menjadikan pandangannya relevan bagi organisasi yang ingin mengamankan integrasi tanpa mengorbankan operasional.
Artikel ini merupakan penutup dari seri tiga artikel tentang integrasi sistem di perusahaan enterprise. Seri ini membahas tantangan keamanan integrasi secara bertahap:
- Keamanan Integrasi Sistem: mengapa konektivitas antarsistem perlu diimbangi dengan pengelolaan akses dan identitas nonmanusia yang jelas?
- Risiko Keamanan Integrasi Informal: bagaimana spreadsheet, akun bersama, dan approval di luar platform dapat menimbulkan celah keamanan dalam proses bisnis?
Selanjutnya, bagian ketiga ini akan membahas strategi mengamankan integrasi sistem aplikasi pihak ketiga serta mempersiapkan tata kelola dan batas kewenangan AI agent dalam workflow bisnis.
Zero Trust untuk Koneksi Mesin-ke-Mesin: Apa Prinsip Dasarnya?
Prinsip Zero Trust, seperti least privilege, segmentasi, dan verifikasi berkelanjutan, selama ini lebih banyak diterapkan pada akses pengguna dan perangkat. Ketika sistem saling terhubung, pertanyaannya adalah bagaimana prinsip yang sama diterapkan pada aplikasi yang berkomunikasi dengan aplikasi lain.
Rein merangkum prinsip dasarnya dalam satu kalimat.
Prinsipnya, sebuah aplikasi tidak otomatis boleh mengakses semuanya hanya karena berada di jaringan internal atau sudah berhasil terhubung.
Pernyataan ini menantang asumsi yang masih umum dalam arsitektur integrasi, yaitu bahwa koneksi yang berhasil dibangun dan berada di jaringan internal sudah cukup menjadi alasan untuk dipercaya.
Dalam Zero Trust, keberhasilan terhubung hanyalah awal. Yang menentukan adalah apa yang boleh dilakukan aplikasi setelah terhubung.
Arah ini sejalan dengan dua publikasi NIST. SP 800-207: Zero Trust Architecture menegaskan bahwa tidak ada kepercayaan implisit yang diberikan kepada aset atau akun hanya berdasarkan lokasi jaringannya.
Sementara itu, SP 800-207A menjelaskan bahwa dari sudut pandang keamanan aplikasi, kebijakan autentikasi dan otorisasi perlu didasarkan pada identitas aplikasi dan layanan, tidak hanya pada parameter jaringan dan identitas pengguna.
NIST juga menekankan kebijakan akses yang granular di level aplikasi, baik untuk lingkungan on-premise, multi-cloud, maupun hybrid.
Verifikasi mesin berbeda dengan verifikasi manusia
Satu catatan penting dari Rein: verifikasi pada koneksi mesin-ke-mesin tidak bisa disamakan dengan verifikasi pengguna. Untuk mesin, verifikasi dilakukan melalui mekanisme sistem dan kebijakan akses, bukan dengan meminta manusia memasukkan OTP setiap kali aplikasi berkomunikasi.
Perbedaan ini penting dipahami ketika organisasi mencoba “menyalin” kontrol akses pengguna ke integrasi. Hasilnya bisa berupa proses yang tidak praktis, atau sebaliknya, celah yang dibiarkan karena kontrolnya dianggap terlalu merepotkan.
Kontrol Apa yang Perlu Diprioritaskan Jika Tim Keamanan Terbatas?
Tidak semua organisasi memiliki tim keamanan besar yang bisa menerapkan seluruh kontrol Zero Trust sekaligus. Untuk kondisi seperti ini, Rein menyarankan pendekatan bertahap berbasis risiko.
Langkah pertamanya adalah memilih integrasi yang paling perlu diamankan lebih dulu, yaitu integrasi yang menyentuh data sensitif atau dapat mengubah transaksi. Integrasi lain bisa menyusul setelah fondasi kontrolnya terbentuk.
Untuk integrasi prioritas tersebut, urutan kontrol yang disarankan Rein adalah sebagai berikut:
- Tentukan owner-nya. Setiap integrasi harus memiliki pihak yang bertanggung jawab.
- Gunakan identitas yang bisa dibedakan. Setiap integrasi sebaiknya memakai identitasnya sendiri, sehingga aktivitasnya dapat dikenali dan tidak tercampur dengan integrasi lain.
- Batasi hak sesuai kebutuhan. Contoh dari Rein: kalau sebuah integrasi hanya perlu membaca laporan, jangan beri hak untuk mengubah data.
- Amankan kredensialnya. Kredensial perlu disimpan dengan aman.
- Siapkan mekanisme pembaruan dan pencabutan. Organisasi harus bisa mengganti atau mencabut kredensial saat dibutuhkan.
- Catat aktivitas penting. Jejak aktivitas memungkinkan organisasi menelusuri apa yang terjadi jika muncul masalah.
Kredensial berumur pendek dan rotasi yang diuji
Selain langkah dasar tersebut, Rein menyebut dua praktik lanjutan.
Pertama, jika platform mendukung, kredensial berumur pendek (short-lived credentials) dapat dipertimbangkan. Kredensial jenis ini kedaluwarsa dengan sendirinya, sehingga jendela penyalahgunaannya lebih sempit jika sampai bocor.
Kedua, rotasi kredensial harus diuji. Rotasi yang dilakukan tanpa pemahaman menyeluruh bisa memutus operasional. Karena itu, organisasi perlu memahami aplikasi mana saja yang memakai suatu kredensial sebelum menggantinya.
Catatan ini penting bagi IT Manager dan Enterprise Architect. Kebijakan rotasi yang terlihat ideal di atas kertas bisa menjadi sumber gangguan layanan jika peta ketergantungan antaraplikasi tidak tersedia. Keamanan dan kelangsungan operasional perlu direncanakan bersamaan.
Bagaimana Mengevaluasi Aplikasi Pihak Ketiga sebelum Terhubung ke Sistem Inti?
Ketika sebuah aplikasi atau platform pihak ketiga akan dihubungkan ke ERP atau sistem inti lainnya, keputusan evaluasi tidak bisa hanya bertumpu pada fitur dan harga.
Berdasarkan pengalamannya mendampingi proses evaluasi teknis, Rein memiliki urutan yang jelas dalam menilai sebuah integrasi.
1. Mulai dari tindakan yang akan diperbolehkan
Titik awal evaluasi Rein adalah apa yang akan boleh dilakukan aplikasi tersebut. Alasannya, aplikasi yang hanya membaca laporan memiliki risiko yang sangat berbeda dengan aplikasi yang bisa mengubah rekening vendor. Tingkat risiko inilah yang menentukan seberapa dalam evaluasi berikutnya perlu dilakukan.
2. Petakan aliran datanya
Setelah itu, Rein ingin memahami aliran data secara utuh:
- Data apa yang dikirim ke aplikasi tersebut?
- Di mana data itu disimpan?
- Siapa yang dapat mengaksesnya?
- Berapa lama data itu disimpan?
3. Periksa model aksesnya
Dari sisi akses, ada dua hal yang ia periksa: apakah izin aplikasi bisa dibatasi, dan apakah integrasi tersebut membutuhkan akun yang terlalu istimewa. Platform yang hanya bisa bekerja dengan akses administrator penuh ke sistem inti patut menjadi perhatian khusus.
4. Minta bukti, bukan hanya klaim
Rein akan meminta bukti bahwa aktivitas integrasi bisa ditelusuri dan aksesnya dapat dicabut. Ia juga ingin mengetahui apa yang terjadi jika koneksinya gagal, karena perilaku sistem saat terjadi kegagalan sama pentingnya dengan perilakunya saat berjalan normal.
5. Perlakukan sertifikasi sebagai bahan, bukan kesimpulan
Sertifikasi keamanan vendor kerap menjadi salah satu dokumen pertama yang diminta dalam proses pengadaan. Rein menempatkannya secara proporsional.
Sertifikasi dapat menjadi salah satu bahan evaluasi, tetapi cakupan dan relevansinya tetap perlu diperiksa.
Dengan kata lain, organisasi perlu memastikan bahwa sertifikasi tersebut benar-benar mencakup layanan, lingkungan, dan kontrol yang relevan dengan integrasi yang akan dibangun.
6. Uji dalam lingkup terbatas sebelum production
Terakhir, Rein lebih nyaman jika kontrol-kontrol yang penting didemonstrasikan dan diuji dalam lingkup terbatas sebelum integrasi naik ke production.
Pengujian ini memberi kesempatan untuk memverifikasi bahwa pembatasan akses, pencatatan aktivitas, dan pencabutan akses benar-benar bekerja seperti yang dijanjikan.
Ringkasan kriteria evaluasi
| Aspek | Pertanyaan evaluasi |
|---|---|
| Tindakan yang diperbolehkan | Apakah aplikasi hanya membaca, atau bisa mengubah data dan memicu transaksi? |
| Aliran data | Data apa yang dikirim, disimpan di mana, siapa yang mengakses, dan berapa lama disimpan? |
| Model akses | Apakah izin bisa dibatasi, dan apakah integrasi membutuhkan akun yang terlalu istimewa? |
| Jejak dan pencabutan | Adakah bukti bahwa aktivitas bisa ditelusuri dan akses bisa dicabut? |
| Skenario kegagalan | Apa yang terjadi jika koneksi gagal? |
| Sertifikasi | Apakah cakupan dan relevansinya sesuai dengan integrasi yang dibangun? |
| Pengujian | Sudahkah kontrol penting didemonstrasikan dan diuji dalam lingkup terbatas sebelum production? |
Kriteria ini sejalan dengan arahan NIST SP 800-207A tentang kebijakan akses granular di level aplikasi. Integrasi yang aman bukan sekadar integrasi yang berhasil terhubung, tetapi integrasi yang hak aksesnya dapat dibatasi dan aktivitasnya dapat ditelusuri.
Bagaimana Mengatur Identitas dan Wewenang AI Agent dalam Proses Bisnis?
AI agent mulai digunakan untuk menjalankan berbagai langkah dalam proses bisnis, termasuk mengambil tindakan berdasarkan instruksi dan data yang tersedia. Perkembangan ini membawa persoalan identitas ke tingkat berikutnya, karena agent tidak hanya membaca data, tetapi juga bisa bertindak.
Rein melihat AI agent sebagai komponen yang bisa mengambil tindakan melalui akses yang diberikan kepadanya. Karena itu, menurutnya batas kewenangan agent harus jelas sejak awal.
Empat hal yang perlu didefinisikan untuk setiap agent
Sebelum sebuah AI agent dilibatkan dalam workflow, Rein menyarankan organisasi menjawab empat pertanyaan berikut:
- Agent bekerja untuk siapa?
- Tool apa saja yang boleh dipakai?
- Data apa saja yang boleh diakses?
- Tindakan mana yang memerlukan persetujuan?
Ada satu prinsip tambahan yang ia tekankan: ketika bekerja atas nama pengguna, agent tidak boleh menjadi jalan untuk melampaui hak pengguna tersebut.
Jika seorang staf tidak berwenang menyetujui pembayaran, agent yang bekerja atas namanya pun tidak boleh bisa melakukannya.
Model dan training data juga bagian dari risiko
Rein juga mengingatkan bahwa pemilihan model dan training data yang digunakan sangat penting. Menurutnya, beberapa model LLM memiliki celah keamanan tersendiri yang akan terbawa sebagai sifat turunan hingga ke use case bisnis yang dibangun di atasnya.
Dengan kata lain, evaluasi keamanan AI agent tidak cukup berhenti pada konfigurasi akses, tetapi juga perlu mencakup fondasi model yang dipakai.
Tindakan berisiko tinggi tetap di bawah kendali manusia
Kekhawatiran utama dalam konsep agentic AI, menurut Rein, adalah kemampuan agent untuk mengeksekusi sesuatu. Karena itu, manusia perlu ditempatkan sebagai pemberi persetujuan secara dinamis, sesuai tingkat risiko tindakannya.
Rein menyebut beberapa jenis tindakan yang menurutnya memerlukan kontrol manusia sebelum dieksekusi:
- Pembayaran.
- Perubahan rekening vendor.
- Penghapusan data penting.
- Pemberian akses istimewa.
Persetujuan manusia pun harus bermakna. Orang yang menyetujui perlu melihat tindakan yang akan dijalankan agent beserta dampaknya, bukan sekadar menekan tombol “setuju”.
Instruksi di prompt bukan kontrol akses
Poin yang barangkali paling penting bagi Enterprise Architect adalah soal di mana batas kewenangan agent ditegakkan.
Batas ini perlu ditegakkan oleh aplikasi atau sistem tujuan. Instruksi di prompt saja tidak cukup sebagai kontrol akses.
Menuliskan “jangan lakukan pembayaran di atas nilai tertentu” di dalam prompt tidak sama dengan membatasi hak akses agent di sistem pembayaran. Prompt dapat dimanipulasi atau diabaikan, sementara kontrol akses di sistem tujuan tetap berlaku apa pun instruksi yang diterima agent.
Selain itu, Rein menekankan bahwa organisasi juga perlu bisa menelusuri tindakan agent dan menghentikan aksesnya ketika diperlukan.
Adopsi AI bergerak lebih cepat daripada tata kelolanya
Kebutuhan ini diperkuat oleh data global.
Sementara itu, Microsoft Cyber Pulse: An AI Security Report (Februari 2026) menyebut bahwa AI agent berkembang lebih cepat daripada kemampuan sebagian perusahaan untuk melihatnya. Microsoft merekomendasikan pencatatan inventaris agent, kejelasan pemilik, akses least privilege, jejak audit, serta pengawasan manusia.
Rekomendasi ini sejalan dengan prinsip yang disampaikan Rein: batas wewenang yang jelas, kontrol yang ditegakkan sistem, dan manusia yang tetap memegang keputusan berisiko tinggi.
Jika Integrasi Sudah Telanjur Berkembang Tanpa Tata Kelola, dari Mana Memulainya?
Banyak organisasi tidak membangun integrasinya dari nol dengan tata kelola yang rapi. Integrasi tumbuh bertahap mengikuti kebutuhan bisnis, dan pada titik tertentu organisasi menyadari bahwa koneksi, akses, dan kontrolnya perlu ditata ulang. Pertanyaannya, dari mana memulai tanpa mengganggu operasional?
Jangan menunggu inventaris yang sempurna
Rein menyarankan untuk memulai dari peta sederhana atas integrasi yang paling kritis, bukan dari inventaris lengkap seluruh perusahaan. Menunggu inventaris yang sempurna justru bisa menunda perbaikan pada titik yang paling berisiko.
Integrasi yang perlu dipetakan lebih dulu adalah proses yang menyentuh salah satu dari tiga hal berikut: uang, data sensitif, atau akses administrator.
Untuk setiap integrasi kritis tersebut, Rein menyarankan lima hal yang perlu dicatat:
| Yang dicatat | Pertanyaan yang dijawab |
|---|---|
| Aplikasi yang terhubung | Sistem apa saja yang terlibat dalam integrasi ini? |
| Identitas yang dipakai | Service account, API token, atau kredensial apa yang digunakan? |
| Hak akses | Apa saja yang bisa dibaca dan diubah oleh identitas tersebut? |
| Owner | Siapa yang bertanggung jawab atas integrasi ini? |
| Ketergantungan | Proses dan aplikasi apa yang akan terdampak jika integrasi ini diubah atau dihentikan? |
Tindakan awal yang realistis
Dari peta tersebut, organisasi dapat menentukan tindakan awal. Rein memberi beberapa contoh:
- Mengurangi izin yang berlebihan.
- Memisahkan akun yang dipakai bersama.
- Memperbaiki pencatatan aktivitas.
Namun, ada dua kehati-hatian yang ia tekankan.
- Pertama, akses yang tampaknya tidak digunakan perlu dikonfirmasi sebelum dicabut. Sebagai gambaran, integrasi yang jarang berjalan, misalnya untuk proses bulanan atau tahunan, bisa saja masih dibutuhkan.
- Kedua, perubahan kredensial dan izin sebaiknya diuji bersama pemilik aplikasi dan disertai rencana pemulihan jika terjadi gangguan.
Dalam hitungan beberapa minggu, target yang menurut Rein realistis adalah memiliki peta risiko awal dan memperbaiki sebagian akses yang berisiko tinggi. Bukan menyelesaikan seluruh persoalan tata kelola integrasi sekaligus.
Yang perlu dihindari: perubahan massal
Rein secara tegas mengingatkan untuk menghindari perubahan massal yang belum dipahami dampaknya terhadap operasional.
Dalam praktik, mencabut puluhan akses atau merotasi semua kredensial sekaligus mungkin terlihat tegas, tetapi berisiko memutus proses bisnis dan justru melemahkan dukungan terhadap program keamanan itu sendiri.
Faktor penentu: dukungan manajemen
Di luar aspek teknis, Rein menyebut satu faktor yang tidak kalah penting, yaitu executive sponsor dari manajemen. Menata ulang integrasi berarti mengakui bahwa ada hal yang selama ini tidak dikelola dengan baik.
Tidak mudah bagi perusahaan ataupun organisasi untuk melakukan evaluasi mendalam terhadap apa yang sudah dikerjakan dan berkata bahwa ‘ya, kami salah, dan kami harus perbaiki’.
Menurut Rein, dukungan dan dorongan dari level manajemen dibutuhkan agar seluruh upaya ini dapat dijalankan dengan ideal. Ini berarti program penataan integrasi perlu diposisikan sebagai inisiatif bisnis yang didukung pimpinan, bukan sekadar proyek teknis tim IT atau keamanan.
Kesimpulan: Mengamankan Integrasi secara Terukur
Dari keseluruhan wawancara, pendekatan Rein konsisten pada satu pola: mulai dari risiko nyata proses bisnis, tetapkan siapa yang bertanggung jawab, batasi akses sesuai kebutuhan, pastikan aktivitasnya bisa ditelusuri, dan siapkan cara untuk menghentikannya. Pola ini berlaku untuk service account, aplikasi pihak ketiga, maupun AI agent.
Beberapa poin berikut dapat menjadi pegangan:
- Zero Trust untuk mesin berarti aplikasi tidak otomatis dipercaya hanya karena berada di jaringan internal atau berhasil terhubung. Verifikasinya dilakukan lewat mekanisme sistem dan kebijakan akses.
- Dengan sumber daya terbatas, prioritaskan integrasi yang menyentuh data sensitif atau dapat mengubah transaksi, lalu terapkan owner, identitas yang bisa dibedakan, pembatasan hak, pengamanan kredensial, serta pencatatan aktivitas.
- Saat mengevaluasi vendor, mulai dari tindakan yang diperbolehkan, petakan aliran data, minta bukti kontrol, periksa cakupan sertifikasi, dan uji dalam lingkup terbatas sebelum production.
- Untuk AI agent, tetapkan batas wewenang sejak awal, tegakkan batas tersebut di sistem tujuan, dan tempatkan manusia sebagai pemberi persetujuan untuk tindakan berisiko tinggi.
- Untuk integrasi yang telanjur berkembang, mulai dari peta integrasi paling kritis, hindari perubahan massal, dan pastikan ada dukungan dari manajemen.
Selain strategi teknis tersebut, pemilihan platform untuk membangun aplikasi dan workflow yang terhubung dengan sistem inti juga perlu mempertimbangkan aspek keamanan dan tata kelola.
Mekari Officeless mendukung kebutuhan ini melalui kapabilitas Security & Governance, termasuk sertifikasi ISO 27001, registrasi PSE Kominfo, serta end-to-end encryption untuk melindungi data saat dikirim maupun disimpan.
Kapabilitas ini menjadi bagian dari pertimbangan perusahaan dalam membangun dan mengembangkan workflow digital dengan memperhatikan keamanan informasi dan kepatuhan.
Referensi
- IBM. (2025, July 30). Cost of a data breach report 2025. IBM Newsroom.
- Microsoft. (2026, February 10). Cyber Pulse: An AI security report. Microsoft Security.
- National Institute of Standards and Technology. (2020, August). Zero trust architecture (NIST Special Publication 800-207).
- National Institute of Standards and Technology. (2023, September). A zero trust architecture model for access control in cloud-native applications in multi-cloud environments (NIST Special Publication 800-207A). https://doi.org/10.6028/NIST.SP.800-207A
