Keamanan Integrasi Sistem: Mengelola Akses dan Non-Human Identity di Balik Sistem yang Saling Terhubung

Di perusahaan skala enterprise, ERP hampir tidak pernah bekerja sendirian. Sistem ini biasanya terintegrasi dengan berbagai aplikasi lain, mulai dari sistem approval dan document management, dashboard pelaporan, hingga aplikasi operasional lapangan. Sebagian aplikasi dikembangkan oleh tim internal, sementara sebagian lainnya berasal dari vendor pihak ketiga.

Integrasi tersebut membuat proses bisnis berjalan lebih cepat. Namun, setiap integrasi juga memperluas attack surface dan menambah kompleksitas pengelolaan akses ke sistem inti. 

Semakin banyak aplikasi yang terhubung, semakin banyak pula identitas digital, kredensial, service account, serta hak akses yang perlu dikelola dan dipantau untuk memastikan setiap koneksi hanya memiliki akses sesuai kebutuhannya.

Menariknya, sebagian besar jalur akses itu tidak dipegang oleh manusia. Integrasi antarsistem sering menggunakan identitas nonmanusia (non-human identity), seperti service account, API token, dan kredensial konektor yang bekerja di balik layar.

Jika tidak dikelola secara terpusat, identitas dan kredensial ini dapat luput dari proses review akses rutin, padahal hak aksesnya bisa mencakup kemampuan membaca atau mengubah data keuangan, mengakses data vendor, hingga menjalankan transaksi di sistem inti.

Untuk memahami bagaimana praktisi keamanan memandang persoalan ini, kami mewawancarai Rein Rachman Putra, Solutions Engineer, Cybersecurity di Cisco. Rein memiliki pengalaman lebih dari 10 tahun di bidang jaringan dan keamanan. 

Kariernya dimulai sebagai NOC engineer, berlanjut ke presales dan 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 juga memegang sertifikasi CISM (Certified Information Security Manager) dan CCNP Security.

Artikel ini merupakan bagian pertama dari seri tiga artikel tentang integrasi sistem di perusahaan enterprise. Seri ini membahas tantangan pengelolaan identitas, akses, dan kontrol dalam integrasi antarsistem secara bertahap:

1. Keamanan Integrasi Sistem: mengapa konektivitas antarsistem perlu diimbangi dengan pengelolaan akses dan identitas nonmanusia yang jelas?
2. Risiko Keamanan Integrasi Informal: bagaimana spreadsheet, akun bersama, dan approval di luar platform dapat menimbulkan celah keamanan dalam pertukaran data dan proses bisnis?
3. Strategi Mengamankan Integrasi Sistem Enterprise: bagaimana menerapkan Zero Trust, mengevaluasi keamanan aplikasi pihak ketiga, dan mengatur kewenangan AI agent dalam workflow bisnis?

Apakah Integrasi Sistem yang Semakin Banyak Meningkatkan Risiko Keamanan?

Bagi Rein, integrasi antarsistem bukan sesuatu yang perlu dicurigai sejak awal. Integrasi lahir dari kebutuhan bisnis yang sah: perusahaan ingin proses berjalan lebih cepat dan data tidak perlu dipindahkan secara manual berulang kali.

Yang menurutnya perlu ikut berkembang adalah cara organisasi mengelola akses. Ketika sebuah aplikasi terhubung ke ERP, pertanyaannya tidak lagi sebatas “apakah koneksinya berhasil?”. Organisasi perlu bisa menjawab tiga hal yang lebih spesifik:

1. Aplikasi tersebut bisa membaca data apa saja?
2. Aplikasi tersebut bisa mengubah data apa saja?
3. Aplikasi tersebut bertindak atas kewenangan siapa?

Rein memberi contoh sederhana. Aplikasi yang dipakai untuk membuat laporan belum tentu membutuhkan hak untuk mengubah data vendor. Jika hak tersebut tetap diberikan karena “lebih praktis”, organisasi sebenarnya sedang membuka jalur perubahan data yang tidak pernah dibutuhkan oleh proses bisnisnya.

Akses tidak lagi ditentukan oleh posisi di jaringan

Cara pandang ini sejalan dengan prinsip Zero Trust yang dirumuskan National Institute of Standards and Technology (NIST) dalam SP 800-207: Zero Trust Architecture.

NIST menegaskan bahwa aset maupun akun tidak boleh diberi kepercayaan secara implisit hanya karena lokasinya di jaringan, misalnya karena berada di jaringan internal perusahaan. Autentikasi dan otorisasi harus dilakukan sebelum sesi ke sumber daya perusahaan dibuka.

NIST juga menekankan bahwa fokus perlindungan bergeser dari segmen jaringan ke sumber daya itu sendiri, termasuk aset, layanan, workflow, dan akun. Dalam konteks integrasi, artinya sederhana: aplikasi yang sudah “masuk” dan berhasil terhubung ke ERP tidak otomatis berhak mengakses semua yang ada di dalamnya.

Cara menentukan kontrol keamanan untuk integrasi sistem enterprise

Salah satu kesalahan umum dalam mengamankan integrasi adalah langsung melompat ke kontrol teknis: memasang firewall, menambah lapisan enkripsi, atau mewajibkan autentikasi tambahan. Rein justru memulai dari arah sebaliknya.

Saat menilai sebuah integrasi, ia terlebih dahulu memahami kebutuhan bisnis di baliknya. Ada tiga pertanyaan yang biasanya ia ajukan:

• Koneksi ini untuk apa? Proses bisnis apa yang dilayani, dan data apa yang benar-benar dibutuhkan untuk menjalankannya.
• Siapa penanggung jawabnya? Harus ada pihak yang jelas bertanggung jawab atas koneksi tersebut, bukan sekadar tim yang dulu membangunnya.
• Seberapa luas dampaknya kalau disalahgunakan? Integrasi yang hanya membaca laporan memiliki profil risiko yang sangat berbeda dengan integrasi yang bisa memicu pembayaran atau mengubah data vendor.

Setelah ketiga pertanyaan itu terjawab, barulah kontrol ditentukan. Dengan urutan ini, kontrol yang dipasang sesuai dengan risiko nyata dari proses bisnisnya. Integrasi berisiko rendah tidak dibebani prosedur berlebihan, sementara integrasi yang menyentuh uang atau data sensitif mendapat perhatian yang layak.

Bagi pemimpin IT, pendekatan ini juga memudahkan percakapan dengan unit bisnis. Diskusi tidak lagi dimulai dari “tim keamanan melarang ini”, tetapi dari “proses ini butuh akses apa, dan siapa yang menjaganya”.

Risiko Keamanan Integrasi Sistem Bergantung pada Hak Akses

Di banyak organisasi, kekhawatiran soal keamanan integrasi sering diterjemahkan menjadi upaya membatasi jumlah koneksi. Semakin sedikit aplikasi yang terhubung ke ERP, semakin aman, begitu asumsinya.

Rein melihatnya secara berbeda. Menurutnya, yang perlu dinilai bukan berapa banyak aplikasi yang terhubung, melainkan seberapa jauh setiap aplikasi bisa bertindak dan seberapa mampu organisasi mengendalikannya.

Sebagai ilustrasi, banyak integrasi dengan hak akses yang sempit dan terkendali bisa lebih aman daripada segelintir integrasi yang masing-masing memegang akses luas ke seluruh sistem.

Jumlah integrasi saja tidak cukup untuk menilai keamanan; lingkup akses dan kemampuan mengendalikannya jauh lebih menentukan.

Rein Rachman Putra

Solutions Engineer, Cybersecurity, Cisco

Ada dua hal yang terkandung dalam pernyataan tersebut.

1. Lingkup akses: seberapa luas data dan tindakan yang bisa dijangkau sebuah integrasi.
2. Kemampuan mengendalikan: apakah organisasi bisa membatasi, memantau, dan mencabut akses tersebut ketika dibutuhkan.

Pergeseran ini juga tercermin dalam NIST SP 800-207A, panduan lanjutan NIST untuk arsitektur Zero Trust di lingkungan cloud-native dan multi-cloud. Dokumen tersebut menjelaskan bahwa fokus kontrol keamanan bergeser dari parameter jaringan seperti alamat IP, subnet, dan perimeter, ke identitas.

Dari sudut pandang keamanan aplikasi, kebijakan autentikasi dan otorisasi perlu didasarkan pada identitas aplikasi dan layanan, tidak hanya identitas pengguna. NIST juga menekankan pentingnya kebijakan yang granular di level aplikasi, baik di lingkungan on-premise maupun hybrid.

Dengan kata lain, setiap aplikasi yang terhubung ke sistem inti adalah sebuah identitas. Identitas inilah yang perlu dikelola, dibatasi, dan dipantau, sama seperti akun karyawan.

Apa Itu Non-Human Identity, dan Mengapa Pengelolaannya Berbeda?

Identitas non-manusia (non-human identity) adalah identitas yang digunakan oleh aplikasi atau sistem, bukan oleh orang, untuk berkomunikasi dengan sistem lain. Bentuknya beragam, antara lain service account, API token, kunci API, dan kredensial konektor yang menghubungkan satu aplikasi dengan aplikasi lain.

Identitas ini bekerja di balik layar dan aksesnya bisa terus aktif selama integrasi berjalan. Tidak ada yang “login” setiap pagi, tidak ada yang merasa perlu mengganti kata sandi, dan tidak ada atasan yang menyetujui perubahan perannya. 

Karena itulah identitas non-manusia mudah terlupakan, meski kewenangannya sering kali setara atau bahkan lebih luas daripada akun karyawan.

Risiko dari kredensial yang terekspos pun bukan sekadar teori.

Namun, temuan tersebut menunjukkan bahwa kredensial yang bocor tetap menjadi salah satu pintu masuk paling umum. Kredensial integrasi yang jarang ditinjau membawa karakter risiko yang sama: siapa pun yang memegangnya dapat masuk dengan kewenangan penuh dari identitas tersebut.

Akun manusia punya pemicu yang jelas, service account tidak

Rein menunjukkan perbedaan mendasar antara kedua jenis identitas ini. Akun manusia memiliki pemicu (trigger) pengelolaan yang relatif jelas, yaitu ketika seseorang masuk kerja, pindah peran, dan keluar dari perusahaan. Proses HR dan IT umumnya sudah terhubung dengan ketiga momen tersebut.

Identitas non-manusia tidak memiliki momen semacam itu secara alami. Menurut Rein, organisasi perlu menetapkan pemicu review-nya sendiri.

Perbedaan inilah yang membuat pendekatan identity and access management (IAM) yang dirancang untuk karyawan tidak otomatis mencakup identitas mesin. Tanpa pemicu yang ditetapkan secara sadar, sebuah service account bisa tetap aktif dengan hak penuh bertahun-tahun setelah proyek yang membutuhkannya selesai.

Kapan Akses Service Account Perlu Ditinjau Ulang Sepanjang Lifecycle Integrasi?

Ketika ditanya di bagian mana non-human identity paling sering luput dari pengawasan, jawaban Rein tidak mengarah pada teknologi tertentu. Ia menunjuk pada lifecycle, terutama fase setelah integrasi selesai dibangun.

Menurut Rein, saat implementasi, perhatian tim tercurah pada satu tujuan: memastikan koneksi bekerja. Begitu data mengalir dan proses bisnis berjalan, proyek dianggap selesai. Padahal, kondisi di sekitar integrasi terus berubah.

Rein menyebut tiga situasi yang seharusnya memicu peninjauan ulang akses:

1. Aplikasi yang terhubung berubah. Fungsinya bertambah, berkurang, atau diganti dengan sistem lain. Hak akses yang dulu relevan bisa jadi kini berlebihan.
2. Proyek yang membutuhkan integrasi sudah selesai. Koneksi untuk migrasi data, uji coba, atau kebutuhan sementara sering kali tetap aktif setelah tujuannya tercapai.
3. Penanggung jawabnya pindah. Ketika engineer atau vendor yang membangun integrasi berpindah tugas, pengetahuan tentang untuk apa akun itu dibuat ikut hilang.

Dalam ketiga situasi tersebut, tidak ada proses otomatis yang “mengingatkan” organisasi bahwa sebuah service account perlu dievaluasi. Hasilnya adalah kredensial yang masih aktif, masih memiliki hak, tetapi tidak lagi jelas siapa yang memakainya dan untuk apa.

Bagi IT Manager dan Enterprise Architect, ini berarti review akses tidak cukup dijadwalkan berdasarkan kalender. Review perlu dikaitkan dengan peristiwa yang terjadi pada aplikasi, proyek, dan orang di sekitar integrasi tersebut.

Seperti Apa Pengelolaan Non-Human Identity yang Baik?

Rein merumuskan ukuran yang sederhana. Pengelolaan identitas non-manusia bisa dianggap baik apabila organisasi mampu menjawab empat pertanyaan berikut untuk setiap service account atau kredensial integrasi:

1. Akun ini digunakan oleh aplikasi apa?
2. Siapa owner-nya?
3. Apa saja haknya?
4. Apakah akun ini masih dibutuhkan?

Jika salah satu pertanyaan itu tidak bisa dijawab dengan cepat dan pasti, kemungkinan besar ada celah dalam pengelolaannya. Keempat pertanyaan ini juga bisa menjadi titik awal yang praktis bagi tim IT untuk menginventarisasi integrasi yang sudah berjalan.

Kredensial harus bisa disimpan aman, diperbarui, dan dicabut

Selain keempat pertanyaan tersebut, Rein menekankan tiga kemampuan yang perlu dimiliki organisasi terhadap setiap kredensial integrasi:

• Disimpan dengan aman, tidak tertanam di kode, file konfigurasi yang dibagikan, atau catatan pribadi.
• Bisa diperbarui, sehingga kredensial dapat diganti tanpa harus membongkar integrasi dari awal.
• Bisa dicabut ketika diperlukan, misalnya saat terjadi indikasi kebocoran atau ketika integrasi tidak lagi dipakai.

Identitasnya milik aplikasi, tanggung jawabnya tetap milik manusia

Prinsip yang paling penting dari jawaban Rein justru menyangkut akuntabilitas. Service account memang dipakai oleh aplikasi, tetapi aplikasi tidak bisa dimintai pertanggungjawaban.

Identitasnya milik aplikasi, tetapi tetap harus ada manusia yang bertanggung jawab terhadap pengelolaannya.

Rein Rachman Putra

Solutions Engineer, Cybersecurity, Cisco

Apa Artinya bagi Pemimpin IT dan Tim Transformasi Digital?

Percakapan dengan Rein menunjukkan bahwa keamanan integrasi sistem enterprise tidak ditentukan oleh seberapa sedikit sistem yang terhubung. Keamanan ditentukan oleh seberapa jelas organisasi memahami dan mengendalikan setiap jalur akses, termasuk yang dijalankan oleh mesin.

Bagi IT Director, Enterprise Architect, atau Head of Digital Transformation, ada beberapa pertanyaan yang bisa dibawa ke rapat arsitektur atau review integrasi berikutnya:

1. Untuk setiap integrasi ke sistem inti, apakah kita tahu aplikasi tersebut bisa membaca apa, mengubah apa, dan atas kewenangan siapa?
2. Apakah hak akses setiap integrasi sudah sesuai dengan kebutuhan prosesnya, atau masih ada yang memegang hak lebih luas “supaya praktis”?
3. Apakah setiap service account dan API token memiliki owner yang tercatat?
4. Pemicu apa yang kita gunakan untuk meninjau ulang identitas non-manusia, di luar jadwal audit tahunan?
5. Apakah kredensial integrasi bisa diperbarui dan dicabut tanpa mengganggu operasional?
6. Bagaimana kita memastikan kredensial tidak bocor sejak tahap development, termasuk ketika developer menggunakan AI?

Jika sebagian besar pertanyaan tersebut belum bisa dijawab dengan yakin, organisasi perlu mulai mengevaluasi bagaimana keamanan dan tata kelola diterapkan dalam setiap proses integrasi. Aspek ini juga perlu menjadi pertimbangan ketika perusahaan memilih platform untuk mengembangkan aplikasi dan menghubungkan workflow lintas sistem.

Mekari Officeless mendukung kebutuhan tersebut melalui kapabilitas Security & Governance yang mencakup sertifikasi ISO 27001, registrasi PSE Kominfo, serta end-to-end encryption untuk melindungi data saat dikirim maupun disimpan. Kapabilitas ini menjadi bagian penting dalam mendukung perusahaan membangun ekosistem aplikasi dan workflow digital dengan memperhatikan keamanan informasi, kepatuhan, dan tata kelola sejak awal.

Referensi

• BM. (2025, July 30). Cost of a data breach report 2025.
• 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). https://doi.org/10.6028/NIST.SP.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).
• Verizon Business. (2025). Additional 2025 DBIR research on credential stuffing.