Server MCP Anda Aman. Buku Besar di Baliknya Tidak.

Dalam artikel terbaru di Unite.AI, Gil Feig menguraikan enam praktik terbaik untuk membangun server MCP yang aman. Saran tersebut tepat, dan siapa pun yang menerapkan server MCP sebaiknya mengikutinya. Sarannya agar setiap integrasi diberi “peran tersendiri dengan cakupan terperinci, yang dibatasi secara ketat pada izin yang diperlukan” memang sangat tepat. Namun, saran itu juga mengasumsikan bahwa sistem di ujung lain memiliki peran dengan cakupan terperinci. Ini mengarah pada asumsi lebih luas yang jarang dinyatakan: sistem di balik server dapat diamankan dengan standar yang sama.

Dalam perangkat lunak bisnis, sering kali hal itu tidak memungkinkan. Saya memimpin tim rekayasa di balik lapisan integrasi yang terhubung ke 32 sistem akuntansi dan ERP, dengan server MCP opsional di atasnya. Kami sering menjumpai agen yang terautentikasi dengan baik, memiliki cakupan akses yang tepat, dan tercatat dengan baik di sisi kami, tetapi menulis ke dalam sistem yang sama sekali tidak dapat mengetahui bahwa agen terlibat.

Artikel ini membahas bagian kedua dari masalah tersebut: apa yang sebenarnya ditawarkan sistem hulu, apa yang dapat Anda kendalikan dari lapisan integrasi, dan di mana kendali itu berakhir.

Batas yang Ditetapkan Spesifikasi MCP

Spesifikasi otorisasi MCP tersebut dengan jelas menjelaskan batas cakupannya sendiri. Server MCP adalah server sumber daya OAuth bagi kliennya. Saat memanggil API hulu, server bertindak sebagai klien OAuth terpisah, dengan token tersendiri yang diterbitkan oleh sistem hulu. Meneruskan token milik klien secara eksplisit dilarang.

Itulah rancangan yang tepat. Namun, ini juga berarti bahwa segala hal terkait pemanggilan ke sistem hulu, termasuk siapa yang berhak melakukan apa dan bagaimana aktivitas itu dicatat, sepenuhnya bergantung pada sistem hulu. Spesifikasi tersebut tidak dapat memperbaiki hal-hal yang tidak disediakan oleh sistem hulu.

Hal yang sama berlaku untuk panduan OWASP tentang kewenangan agen yang berlebihan. Panduan itu menyarankan agar izin yang dimiliki ekstensi agen di sistem lain dibatasi seminimal mungkin dan tindakan dilakukan atas nama pengguna yang diwakilinya. Keduanya merupakan saran yang baik. Namun, keduanya mengasumsikan sistem lain memiliki cara untuk menetapkan izin minimum dan konteks pengguna.

Apa yang Sebenarnya Ditawarkan Sistem Hulu

Berikut gambaran 32 sistem akuntansi dan ERP yang kami hubungkan, dilihat dari sudut pandang integrator.

Sepertiganya tidak memiliki OAuth sama sekali

21 dari 32 sistem menggunakan OAuth. Sebelas sisanya mengandalkan kredensial statis: kunci API, nama pengguna dan kata sandi, atau sepasang token. Sebagian kunci tersebut tidak pernah kedaluwarsa. Salah satu sistem yang banyak digunakan menyatakan dalam dokumentasi bahwa token API-nya berlaku tanpa batas selama pengguna masih ada.

Masa Berlaku Panjang, Opsi Pencabutan Terbatas

OAuth tidak banyak membantu, setidaknya tidak sebanyak yang diharapkan. Salah satu penyedia menerbitkan token penyegaran dengan masa berlaku sekitar 20 tahun. Kredensial ini dirancang agar tetap berlaku lebih lama daripada agen yang menggunakannya, kerangka kerja yang menjadi landasan pembuatannya, dan sangat mungkin juga orang yang mengeklik “izinkan”. Di sistem lain, bahkan token aksesnya tidak kedaluwarsa.

Begitu kredensial tersebar, pertanyaannya adalah siapa yang dapat menonaktifkannya. Standar untuk itu, pencabutan token OAuth (RFC 7009), sudah ada sejak 2013. Namun, pada sekitar empat dari sepuluh sistem, integrator tidak memiliki cara teknis untuk mencabut kredensial. Semua sistem yang menggunakan kunci API termasuk dalam kelompok ini. Satu-satunya langkah yang masih dapat dilakukan adalah meminta pelanggan menghapus akses tersebut secara manual.

Cakupan Izin Terbatas, Tanpa Identitas Agen

Sebagian besar kunci statis mewarisi seluruh hak pengguna yang membuatnya; hanya beberapa sistem yang memungkinkan kunci dibatasi untuk masing-masing titik akhir. Banyak sistem OAuth memiliki cakupan izin, tetapi biasanya cakupannya luas, misalnya “akuntansi, baca dan tulis”. Tak satu pun dari 32 sistem tersebut memungkinkan kami mencatat, melalui API, identitas agen sekaligus orang yang diwakilinya dalam transaksi yang sama. Agen eksternal tercatat sebagai pengguna yang menghubungkannya atau sebagai pengguna sistem umum. Yang menarik, ketika vendor menyertakan agen dalam produknya sendiri, seperti yang dilakukan Microsoft di Business Central, vendor tersebut memberi agen itu akun pengguna khusus. Polanya sama dengan yang saya rekomendasikan di bawah, hanya saja pola itu disediakan khusus bagi agen milik vendor sendiri.

Hal yang Dapat Ditegakkan oleh Lapisan Integrasi

Semua ini bukan berarti kita harus menyerah. Di antara agen dan sistem akuntansi, Anda dapat mengendalikan hampir semuanya:

• kredensial khusus untuk setiap agen saat mengakses lapisan Anda
• cakupan izin Anda sendiri, misalnya akses hanya-baca ke faktur
• log audit untuk setiap pemanggilan agen, beserta identitas orang yang diwakilinya
• kunci idempotensi agar agen yang mencoba kembali tidak membukukan faktur yang sama dua kali
• batas laju untuk setiap agen
• tahap persetujuan sebelum operasi tulis apa pun

Semua itu tidak bergantung pada dukungan sistem tujuan. Lapisan akses yang mumpuni di tingkat integrasi dapat dibuat saat ini, dan jika Anda menempatkan agen di dekat data keuangan, Anda sebaiknya membangunnya.

Batas Kendali

Yang tidak dapat Anda lakukan adalah memperluas lapisan itu melewati batas sistem. Ada tiga hal yang gagal di sana.

Atribusi

Di dalam sistem akuntansi, pencatatan oleh agen akan tampak dilakukan oleh pihak yang mengotorisasi koneksi tersebut atau oleh pengguna teknis. Siapa pun yang mengaudit sistem itu akan melihat pencatatan atas nama pengguna tersebut. Mereka tidak dapat mengetahui apakah pencatatan itu dilakukan oleh seseorang atau oleh agen. Bagi buku besar, agen yang mencatat 400 faktur pada pukul 03.00 tampak persis seperti manajer keuangan yang sangat rajin. Untuk merekonstruksi kejadiannya, Anda memerlukan log milik integrator—rantai kepercayaan yang berbeda dari sistem pencatatan resmi. Untuk keperluan forensik atau audit, ini merupakan posisi yang lemah.

Kebanyakan organisasi juga belum siap menghadapi hal ini. Dalam survei Cloud Security Alliance, hanya 28% responden yang mengatakan bahwa mereka dapat melacak tindakan agen secara andal hingga ke orang atau sistem di seluruh lingkungan, dan 44% menggunakan atau berencana menggunakan kunci API statis untuk agen mereka.

Prinsip hak akses minimum

Anda dapat memastikan bahwa agen hanya membaca faktur. Namun, jika sistem tujuan tidak memiliki cakupan akses, kredensial di balik lapisan Anda tetap memberikan akses penuh. Siapa pun yang mendapatkannya dapat sepenuhnya melewati lapisan Anda beserta semua aturan yang Anda buat di dalamnya.

Pencabutan akses

Anda dapat langsung memutus akses agen Anda sendiri. Namun, itu tidak membantu jika kredensial untuk sistem tujuan itu sendiri telah dibobol. Dan untuk empat dari sepuluh sistem yang tidak memiliki titik akhir untuk pencabutan akses, satu-satunya cara mematikan akses adalah mengirim email kepada pelanggan.

Solusi Praktis: Akun Pengguna Khusus untuk Agen

Hal paling berguna yang dapat Anda lakukan saat ini memang tidak istimewa. Buat akun pengguna khusus untuk agen di sistem tujuan, lalu hubungkan agen hanya melalui akun tersebut.

Cara ini dapat diterapkan pada setiap sistem yang memungkinkan Anda membuat akun pengguna, dan memberikan tiga hal yang tidak bisa diberikan oleh lapisan integrasi:

• Atribusi dalam sistem pencatatan resmi. Pencatatan akan muncul atas nama “agen AP”, bukan manajer keuangan yang mengeklik “hubungkan” enam bulan lalu.
• Cara untuk mencabut akses, bahkan tanpa API. Pelanggan dapat menonaktifkan akun pengguna melalui antarmuka, sehingga cara ini tetap berfungsi pada sistem yang tidak menyediakan titik akhir untuk pencabutan akses.
• Penerapan prinsip hak akses minimum secara parsial. Jika sistem memiliki model peran, akun pengguna agen sering kali dapat dibatasi hanya pada modul yang benar-benar dibutuhkannya.

Biayanya memang nyata. Seseorang harus membuat akun pengguna secara manual saat proses orientasi, sehingga menambah kerepotan tepat pada saat yang paling tidak tepat. Sekitar separuh sistem mengenakan biaya untuk setiap akun pengguna tambahan, mulai dari beberapa euro per bulan pada perangkat lunak untuk usaha kecil hingga lebih dari seratus pada ERP lengkap. Beberapa sistem lainnya membatasi jumlah pengguna berdasarkan paket, sehingga penambahan satu pengguna saja dapat mengharuskan seluruh perusahaan beralih ke paket yang lebih mahal. Selain itu, akun pengguna layanan yang tidak dimiliki siapa pun menjadi risiko tersendiri dan turut memperparah proliferasi identitas nonmanusia yang pernah dibahas Unite.AI. Akun itu memerlukan penanggung jawab dan tanggal peninjauan, sama seperti akun lainnya.

Cara ini juga tidak mengatasi ketiadaan cakupan akses pada sistem yang memang tidak memilikinya. Namun, cara ini mengembalikan atribusi dan pencabutan akses ke dalam sistem yang benar-benar diperiksa auditor.

Solusi Struktural: Identitas yang Didelegasikan

Secara teori, solusi yang tepat sudah ada. Pertukaran Token OAuth 2.0 (RFC 8693) membedakan penyamaran identitas dari pendelegasian. Dengan pendelegasian, agen tetap menggunakan identitasnya sendiri, dan token mencatat bahwa agen bertindak atas nama seseorang melalui klaim “act”.

Jika diterapkan pada akuntansi, artinya:

• buku besar mencatat bahwa agen ini melakukan pencatatan atas nama orang ini
• cakupan akses diberikan untuk setiap pendelegasian, bukan untuk setiap pengguna
• satu pendelegasian dapat dicabut tanpa mengubah akun orang tersebut

Sejauh yang dapat saya temukan, tidak satu pun dari 32 sistem mendukung mekanisme semacam ini. Jadi, untuk saat ini, mekanisme tersebut masih sebatas arah pengembangan, belum menjadi pilihan. Karena itu, permintaan ini sebaiknya ditujukan kepada penyedia perangkat lunak akuntansi dan ERP, bukan menjadi tugas integrator: agen sudah mencatat data ke buku besar Anda, dan API Anda seharusnya dapat menyatakan hal itu.

Yang Perlu Dilakukan Sebelum Agen Mengakses Buku Besar

Jika Anda menghubungkan agen ke sistem akuntansi atau ERP, ikuti daftar periksa singkat ini:

1. Petakan model kredensial setiap sistem tujuan. Apakah sistem menggunakan OAuth atau kunci statis? Berapa lama kredensial berlaku, apakah kredensial memiliki cakupan akses, dan dapatkah aksesnya dicabut?
2. Tetap bangun lapisan akses Anda sendiri. Identitas khusus untuk setiap agen, cakupan akses, idempotensi, dan persetujuan harus ditangani di sisi Anda, apa pun yang disediakan sistem tujuan.
3. Gunakan akun pengguna khusus untuk agen jika sistem memungkinkan. Terima upaya tambahan saat proses orientasi dan biaya lisensi sebagai harga yang harus dibayar demi atribusi.
4. Pastikan jejak audit Anda sendiri dapat menunjukkan jika ada perubahan. Untuk banyak sistem, jejak itu akan menjadi satu-satunya catatan bahwa agen terlibat.
5. Catat risiko residual. Jika suatu sistem tidak memiliki cakupan izin dan mekanisme pencabutan, sampaikan hal itu kepada pelanggan dan cantumkan dalam daftar risiko Anda sendiri.

Batas Itulah Intinya

Mengamankan server MCP Anda memang perlu, tetapi tidak cukup. Keamanan agen yang menulis ke buku besar ditentukan pada batas antara lapisan Anda dan sistem pencatatan, dan saat ini batas tersebut ditetapkan oleh sistem, bukan oleh Anda.

Kabar baiknya, kesenjangan ini sudah terdefinisi dengan jelas. Standarnya sudah ada. Yang belum tersedia adalah dukungan terhadap standar tersebut di sistem yang menyimpan catatan keuangan.