Kredit Gambar: the-lightwriter/iStock/Getty Images Plus via Getty Images
Ikuti ZDNET: Tambahkan kami sebagai sumber terpilih di Google.
—
Intisari ZDNET
- Manajer TI memiliki visibilitas terbatas kapan pengguna memberikan akses data perusahaan ke aplikasi eksternal.
- Ketika aplikasi eksternal itu adalah agen AI, risiko keamanannya berlipat ganda secara eksponensial.
- Okta telah mengusulkan sebuah standar baru untuk memberi organisasi lebih banyak visibilitas dan kendali atas izin-izin tersebut.
—
Diperkirakan pada akhir tahun 2026, banyak dari kita akan memiliki setidaknya satu agen bertenaga AI yang bekerja di balik layar mewakili kita. Dalam lima tahun ke depan, jumlahnya bisa mencapai puluhan atau ratusan agen. Mereka tidak hanya akan mengambil keputusan tentang apa yang harus dilakukan (berdasarkan observasi otonom mereka), tetapi juga akan terhubung ke berbagai sumber data (serta satu sama lain) untuk mengoptimalkan keputusan dan hasil tersebut.Masa depan ini seharusnya mencemaskan sebagian besar organisasi yang sudah berupaya keras melindungi sumber daya digital mereka dari akses tak berwenang. Seiring tekanan pada karyawan untuk berbuat lebih banyak dengan bantuan AI, mereka akan cenderung meluncurkan agen-agen ini dan memberikannya akses ke sumber daya perusahaan apa pun yang dianggap perlu.
Kredensial yang digunakan saat ini untuk akses aplikasi-ke-aplikasi yang disediakan pengguna—dikenal sebagai token OAuth—mungkin sangat tidak cocok untuk tugas ini.
Beberapa tahun lalu, jauh sebelum agen AI muncul, ketika pengguna organisasi memberikan akses data kerja mereka ke aplikasi tertentu seperti Slack, pihak-pihak di penyedia manajemen identitas Okta menyadari adanya kelemahan fundamental dalam cara persetujuan dan pemberian akses tersebut dilakukan.
Sistem manajemen identitas dan akses (IAM), seperti Okta Identity Platform dan Microsoft Entra, berfungsi sebagai panel kendali pusat untuk mengatur manusia mana yang memiliki akses ke sumber daya perusahaan mana. Namun, sistem yang sama itu seringkali tidak dilibatkan ketika aplikasi lain diberi akses serupa ke sumber daya atas nama pengguna tersebut. Alih-alih, keputusan itu diserahkan (dan dalam banyak kasus, masih diserahkan) kepada pengguna akhir, yang mengakibatkan titik buta IAM dan risiko keamanan yang sebenarnya dapat dihindari. Sejak saat itu, Okta telah bekerja sama dengan Internet Engineering Task Force (IETF) pada draf standar terbuka yang dirancang untuk menutup celah ini.
Mengusulkan Standar Baru
Secara internal dan dalam materi promosinya, Okta menyebut spesifikasi ini sebagai "Cross-App Access" atau XAA. Namun, spesifikasi ini dikenal dengan nama lain dalam percakapan standar terbuka IETF: Identity Assertion Authorization Grant (IAAG). Dibandingkan teknologi proprietary dan dalam beberapa kasus standar de facto, standar terbuka adalah teknologi yang tersedia untuk industri secara bebas tanpa hambatan. Perusahaan dan pengembang, termasuk pesaing IAM Okta seperti Microsoft dan Ping Identity, bebas membangun implementasi teknologi mereka sendiri tanpa perlu membayar royalti kepada penemunya.
HTTP—teknologi inti yang memungkinkan web browser mana pun mengakses situs web mana pun—adalah standar terbuka. Dua teknologi utama yang digabungkan untuk membuat passkey bekerja seperti fungsinya—WebAuthn dari World Wide Web Consortium dan Client to Authenticator Protocol (CTAP) dari FIDO Alliance—juga merupakan standar terbuka.
Meskipun perusahaan mana pun dapat menciptakan suatu teknologi dan menyumbangkannya ke dunia untuk dipertimbangkan sebagai standar terbuka, ukuran sejati apakah teknologi itu benar-benar menjadi standar terbuka terikat pada tingkat adopsinya oleh perusahaan lain. Menurut Okta, Google, Amazon, Salesforce, Box, dan Zoom termasuk di antara pengadopsi awal IAAG.
Dalam sebuah wawancara tentang rencana Microsoft untuk membantu organisasi mengendalikan penyebaran agen AI, Wakil Presiden Korporat Inovasi AI Microsoft, Alex Simons, menyatakan kepada ZDNET bahwa Microsoft berencana mendukung standar IAAG baru di Entra (solusi IAM berbasis cloud perusahaan). Sementara Aaron Parecki, Direktur Standar Identitas Okta, awalnya muncul sebagai penulis spesifikasi, insinyur terkemuka Ping Identity Brian Campbell kini muncul sebagai ko-penulis pada draf terbaru, yang merupakan indikator cukup baik bahwa Ping juga mendukung. (Saya belum menerima tanggapan dari Campbell).
Waktu pengusulan standar ini sangatlah tepat. Menurut Parecki, ketika Okta pertama kali mulai mengerjakan masalah ini, agen AI bahkan belum terpikirkan. Namun kini, ketika kategori perangkat lunak yang cerdas, terukur, dan terkadang sepenuhnya otonom ini siap untuk pertumbuhan eksplosif—terutama di balik firewall banyak organisasi—standar baru ini berada pada posisi yang tepat untuk memberi manajer TI kendali dan visibilitas yang mereka butuhkan untuk mengatur aplikasi dan agen dengan aman, seolah-olah mereka berada pada lapangan permainan yang setara dengan manusia.
Di Balik Layar Akses Delegasi
Meskipun beberapa detail teknis diabaikan, inilah yang biasanya terjadi di balik layar: Ketika satu aplikasi diberi akses langsung ke aplikasi lain atas nama pengguna akhir (jenis akses yang dikenal sebagai "akses delegasi"), operator aplikasi kedua ("resource server") diminta untuk menerbitkan kredensial masuk khusus yang kemudian digunakan oleh aplikasi pertama ("client application") untuk melakukan autentikasi dengan resource server seolah-olah sedang menyamar sebagai pengguna akhir itu sendiri.
Pada langkah ini dalam alur kerja OAuth yang khas, resource server akun Google memberitahukan pengguna akhir bahwa ia telah menerima permintaan dari Slack (sebagai client application) yang menginginkan hak akses spesifik (yang tercantum dalam daftar yang ditampilkan) ke akun Google pengguna. Gambar: the-lightwriter/iStock/Getty Images Plus via Getty Images
Apabila pengguna menyetujui dengan mengeklik tombol "Izinkan", Google akan mengeluarkan token akses OAuth untuk Slack yang spesifik bagi pengguna akhir, akun Google mereka, dan hak akses yang tertera.Tangkapan layar oleh David Berlind/ZDNET
Dalam skenario seperti ini, pengguna akhir—yang dianggap sebagai "pemilik sumber daya" menurut standar OAuth—dikatakan sedang mendelegasikan sebagian atau seluruh hak akses server sumber dayanya ke aplikasi klien. Kredensial khusus ini dikenal sebagai token OAuth. Sebelum server sumber daya menerbitkan token tersebut ke aplikasi klien, pengguna akhir biasanya dimintai persetujuan melalui kotak dialog (lihat tangkapan layar di atas) untuk memberikan izin terkait delegasi tersebut. Jika pengguna akhir menyetujui, server sumber daya (biasanya diwakili oleh "server otorisasi" khusus) menerbitkan token OAuth ke aplikasi klien, yang kemudian bertanggung jawab untuk menyimpannya dengan aman. Bagaimanapun, token ini pada dasarnya setara dengan ID pengguna dan kata sandi pengguna akhir.
Tautan terkait: Battered by cyberattacks, Salesforce faces a trust problem – and a potential class action lawsuit
Awal tahun ini, ketika lebih dari satu miliar catatan pelanggan berhasil diekstraksi secara kriminal dan sebenarnya dapat dicegah dari instansi Salesforce milik beberapa merek terbesar dan paling dikenal di dunia, pelaku ancaman mengandalkan token OAuth yang dicuri untuk melakukan kejahatan tersebut.
Setelah pengguna akhir menyetujui penerbitan token OAuth dan aplikasi klien menerima token itu, token tersebut digunakan sebagai kredensial masuk ke server sumber daya, mirip dengan cara manusia memberikan ID pengguna dan kata sandi saat login. Setiap token OAuth ini terbatas pada:
- Pengguna (sekali lagi, "pemilik sumber daya") yang memberikannya,
- Hak akses spesifik yang didelegasikan saat pemberian (ini bisa berupa subset dari hak pengguna secara keseluruhan), dan
- Server sumber daya yang menerbitkannya.
Token OAuth yang diterbitkan oleh Google (server sumber daya) untuk Slack (aplikasi klien) atas nama saya, oleh karena itu, spesifik untuk Google dan terhubung dengan identitas Slack saya. Slack tidak dapat menggunakan token yang sama ke aplikasi lain seperti Zoom, dan tidak dapat pula memberikannya ke Google atas nama pengguna lain. Ada token yang berlaku selamanya, ada pula yang kadaluwarsa setelah jangka waktu tertentu. Penerbit token juga dapat membatalkan token (disebut revoking a token) sewaktu-waktu, serupa dengan menonaktifkan kata sandi atau mengganti kunci pintu depan.
Setelah OAuth hadir
Meskipun ada beberapa jenis token untuk berbagai kasus penggunaan, konsep token Otorisasi Terbuka atau token OAuth muncul pada saat—dalam skenario yang disebutkan sebelumnya—pengguna hanya perlu memasukkan ID pengguna dan kata sandi Google mereka ke dalam Slack. Sulit dipercaya bahwa banyak dari kita dulu dengan senang hati memberikan kredensial tersebut tanpa mempertimbangkan risiko bahaya yang serius. Dari perspektif keamanan siber, praktik tersebut memunculkan beberapa pertanyaan kritis yang cenderung retoris: Kepada siapa sebenarnya kita memberikan ID pengguna dan kata sandi itu? Apakah itu bisnis yang sah atau aplikasi berbahaya yang disamarkan sebagai alat yang sangat berguna? Bahkan jika aplikasinya sah, bagaimana dan di mana ia menyimpan kredensial rahasia yang baru saja kita bagikan? Bagaimana jika aplikasi klien hanya membutuhkan subset dari hak akses pengguna secara keseluruhan?
Tautan terkait: How to prove you’re not a deepfake on Zoom: LinkedIn’s ‘verified’ badge is now free for all platforms
Juga, berbeda dengan OAuth, tidak ada langkah eksplisit di mana pengguna memberikan persetujuan. "Persetujuan itu tersirat dalam [berbagi] kredensial," ujar Parecki dalam wawancara dengan ZDNET. "Anda memberikan kata sandi ke suatu aplikasi, aplikasi tersebut membawa kata sandi itu ke layanan, dan menyajikannya seolah-olah itu adalah Anda. Itu semacam persetujuan tersirat, bukan? Karena fakta bahwa aplikasi memiliki kata sandi berarti ia harus mendapatkannya secara sah, kan? Yang jelas, kita tahu itu bukan pola yang baik untuk dianggap benar."
Kehadiran OAuth menghilangkan kebutuhan bagi pengguna untuk membagikan kredensial rahasia mereka guna mengaktifkan akses lintas-aplikasi atas nama mereka. Skema ini telah bekerja cukup baik di internet selama beberapa dekade terakhir. Namun kemudian muncul pertanyaan tentang siapa sebenarnya pemilik sumber daya itu. Seperti disebutkan di atas, pengguna akhir dianggap sebagai pemilik sumber daya, dan karenanya, pengguna akhirlah yang memberikan persetujuan atas penerbitan token OAuth. Tetapi, benarkah pengguna akhir adalah pemilik sumber daya? Atau organisasinya? Dan jika itu adalah organisasi—yang memang benar—bukankah organisasi seharusnya terlibat dalam alur kerja OAuth?
Menurut perspektif Okta, dalam skenario konsumen di mana pengguna akhir ingin aplikasi klien (seperti agen AI) mengambil tindakan atas akun Gmail pribadi mereka, adalah wajar jika pengguna akhir bertindak sebagai pemilik sumber daya yang menyetujui penerbitan token akses OAuth. Namun, dalam skenario organisasi di mana sumber daya sebenarnya merupakan milik organisasi, dan akses ke sumber daya tersebut dikontrol melalui control plane terpusat, persetujuan akhir harus berasal dari control plane terpusat itu—sistem IAM—bukan dari individu.
Mengapa ini masuk akal? Pengguna akhir sudah memiliki rekam jejak yang buruk ketika mereka menjadi garis pertahanan terakhir antara pelaku ancaman dan infrastruktur aplikasi organisasi. Misalnya, penelitian menunjukkan bahwa bahkan setelah menerima pelatihan keamanan siber, 98% pengguna masih lengah dan jatuh ke dalam serangan phishing yang sebenarnya dapat dicegah. Di bawah standar IAAG, pengguna akhir tetap dapat memilih untuk menyetujui koneksi antara aplikasi klien seperti Slack dan sumber daya seperti instalasi Zoom milik organisasi. Namun, sistem IAM organisasilah yang pada akhirnya menyetujui permintaan koneksi dan penerbitan token akses OAuth yang diperlukan.
Tautan terkait: Roaming authenticators offer what other passkey solutions can’t – but there are trade-offs
Mirip dengan cara akses sumber daya diberikan kepada manusia, bentuk persetujuan ini, kata Parecki, dikonfigurasi sebelumnya oleh administrator sistem. "the-lightwriter/iStock/Getty Images Plus via Getty Images" "Bagi semua pengguna di perusahaan, kami ingin mengaktifkan agar Slack dapat memperoleh token akses ke akun Dropbox para pengguna," ujar Parecki sebagai contoh. "Kebijakan tersebut berada dalam IdP [Identity Provider, akronim yang kadang digunakan bersamaan dengan IAM]. Jadi sekarang, [Slack] dapat mengambil token akses karena kebijakannya telah dikonfigurasi di IdP."
Saat Agen AI Tidak Terkendali
Pendekatan ini juga relevan di dunia yang akan dipenuhi oleh agen AI—khususnya yang, jika diberi kesempatan (mirip seperti manusia), dapat secara mandiri terlibat dalam alur kerja OAuth tanpa diketahui siapa pun di organisasi. Dalam skenario agen-AI-yang-liar tersebut, tidak sulit membayangkan betapa cepatnya sistem IAM pusat dapat kehilangan sinkronisasi dengan semua izin yang diberikan, atas nama siapa, dan untuk sumber daya apa. Dalam skala besar, satu agen yang bocor atau jahat dapat menyebabkan kerusakan besar dalam waktu singkat.
"Meskipun itu sebenarnya sebuah agen, ia tetaplah perangkat lunak, dan diwakili oleh ID kliennya," jelas Parecki. "Misalnya, Anda ingin sebuah agen baru mampu mengindeks seluruh konten Anda di 20 aplikasi perusahaan. Agen itu menginginkan lebih banyak data, dan mencoba mengakses lebih banyak hal [dibandingkan skenario aplikasi klien OAuth biasa]. Anda tidak ingin setiap karyawan harus mengklik perintah persetujuan sebanyak 20 kali hanya untuk mulai menggunakan alat AI baru Anda."
Untuk mendukung pengalaman pengguna yang lebih baik dan keamanan yang menyertainya, standar yang diusulkan melibatkan lebih dari sekadar penyesuaian alur kerja OAuth untuk memverifikasi pemilik asli sumber daya (organisasi) alih-alih pengguna akhir. Struktur tokennya juga perlu peningkatan. Misalnya, jika alur kerja OAuth standar melibatkan ID pengguna dari penyedia sumber daya, alur kerja OAuth yang disempurnakan ini melibatkan ID pengguna dari sistem IAM organisasi. Catatan dari sistem IAM juga disertakan dalam alur kerja yang ditingkatkan ini.
Bidang data tambahan ini tidak hanya memungkinkan penyisipan sistem IAM organisasi ke dalam proses pemberian OAuth, tetapi juga memfasilitasi visibilitas dan kontrol terpusat yang lebih tinggi yang sebelumnya tidak tersedia bagi manajer TI. Contohnya, pertimbangkan skenario berikut:
Seorang karyawan memiliki 25 agen AI yang bekerja atas namanya, beroperasi pada berbagai server sumber daya organisasi. Saat ia memutuskan keluar dari perusahaan, departemen TI perlu mencabut akses agen-agen tersebut. Dalam skema OAuth baru ini, manajer TI dapat mengkueri sistem IAM organisasi tidak hanya untuk melihat semua token yang diterbitkan untuk pengguna tertentu di semua server sumber daya, tetapi juga lebih mudah mencabut sebagian atau semua token tersebut sebagai bagian dari proses pencabutan yang ditargetkan.
Organisasi menemukan bahwa sebuah agen AI, yang awalnya disetujui untuk digunakan oleh semua karyawan, membocorkan informasi rahasia ke model bahasa besar yang mendasarinya. Untuk menghentikan kebocoran, CISO memutuskan bahwa seluruh penyedia solusi AI agen harus segera dicabut dari infrastruktur aplikasi organisasi. Dengan satu kueri ke sistem IAM, seorang manajer TI seharusnya dapat lebih mudah menemukan token yang relevan dan mencabutnya.
Seperti banyak standar baru, mungkin diperlukan waktu sebelum semua komponen berjalan dengan baik sehingga memberi manajer TI kendali terpusat atas maraknya AI agen (belum lagi koneksi aplikasi-ke-aplikasi standar yang sudah terjalin tanpa sepengetahuan TI). Tidak hanya draf standar ini harus melalui tahap persetujuan akhir di IETF, tetapi dukungan untuk standar baru ini juga perlu diimplementasikan di berbagai server otorisasi yang digunakan oleh penyedia SaaS yang mendukung koneksi berbasis OAuth dari aplikasi klien. Sumber foto: the-lightwriter/iStock/Getty Images Plus via Getty Images