Category: Cloud Computing

Tantangan dalam Mengeksploitasi Redirect URI Kami menemukan bahwa sebagian besar situs web membatasi parameter redirect_uri ke jalur absolut, sehingga hampir mustahil untuk dieksploitasi karena penyerang tidak dapat memanipulasi URI untuk mengarahkan pengguna ke lokasi berbahaya. Salah satu pengujian dalam penelitian kami adalah melihat apakah kami dapat mengubah jalur endpoint setelah nama domain. Sebagai contoh, kami memeriksa apakah terjadi error setelah perubahan berikut: Sebelum: https://www.example.com/oauth/callback Sesudah: https://www.example.com/any/callback Kami menemukan bahwa 28 situs tidak menggunakan pembatasan jalur absolut (karena penggunaan wildcard domain, misalnya “domain.com/*”), dan 18 di antaranya memungkinkan kami menambahkan jalur apa pun setelah nama domain. Namun, perilaku ini tidak memungkinkan kami mengubah domain asli ke domain kami sendiri. Ini berarti kami masih harus menemukan kerentanan open redirect di situs target, karena kami tidak dapat mengubah domain. Metode untuk Melewati redirect_uri Kami mencari lebih banyak metode untuk melewati validasi redirect_uri dengan mencoba berbagai teknik untuk memanipulasi parser. Pada awalnya, kami fokus pada upaya melewati validasi domain redirect_uri. Jika kami dapat mengatur domain kami sendiri, kami bisa langsung meneruskan kode otorisasi tanpa memerlukan kerentanan open redirect. Kami mengumpulkan beberapa teknik bypass yang kami temukan terkait OAuth, beberapa di antaranya berasal dari skenario dunia nyata (misalnya, melewati OAuth menggunakan IDN homograph), dan menyusunnya dalam sebuah daftar (Lampiran A). Untuk mengujinya secara efektif, kami membuat “oauth-hunter” (Gambar 4), sebuah alat penelitian keamanan open-source yang mengotomatisasi kesalahan konfigurasi OAuth. Saat ini, sebagian besar teknik bypass yang kami coba tidak mengungkap banyak kerentanan. Meskipun ada skenario dunia nyata di mana metode ini berhasil (misalnya, melewati OAuth menggunakan IDN homograph), sebagian besar tidak efektif dalam penelitian kami. Hal ini mungkin disebabkan oleh fokus utama kami pada penyedia identitas (IdP) populer seperti Facebook dan GitHub, yang memiliki perlindungan kuat terhadap teknik bypass semacam ini. Manipulasi Parameter state Masalah kedua yang kami periksa adalah validasi parameter state. Seperti yang kami sebutkan sebelumnya, peran parameter state adalah untuk mencegah serangan CSRF. CSRF adalah serangan berbasis web yang menipu pengguna agar secara tidak sadar mengirimkan permintaan berbahaya, memungkinkan penyerang melakukan tindakan atas nama pengguna tanpa persetujuan mereka. Dalam konteks OAuth, serangan CSRF dapat memungkinkan penyerang mengeksploitasi sesi pengguna untuk mendapatkan akses tidak sah ke sumber daya yang dilindungi. Kami menemukan bahwa 21 dari situs web yang kami teliti tidak memverifikasi parameter state dengan benar. Parameter state dapat diatur dan digunakan kembali secara bebas, dan dalam beberapa kasus, bahkan memungkinkan penyerang membuat URL OAuth yang dapat menipu pengguna agar secara tidak sadar terhubung ke sesi milik penyerang. Akibatnya, korban masuk ke akun penyerang tanpa disadari dan berinteraksi dalam sesi tersebut. Setiap tindakan yang dilakukan—seperti memasukkan data pribadi—dapat diakses oleh penyerang, yang kemudian dapat mengambil dan menyalahgunakannya. Dari jumlah tersebut, kami mengidentifikasi delapan situs web yang secara aktif rentan terhadap serangan ini (Gambar 5). Proses serangan berlangsung sebagai berikut: Penyerang mencegat permintaan OAuth awal: Penyerang memulai proses login OAuth dan mencegat kode otorisasi sebelum menukarkannya dengan token akses. Mereka kemudian menyimpan kode otorisasi tersebut dan membatalkan permintaan. Korban menggunakan kode otorisasi milik penyerang: Penyerang menipu korban agar memulai proses OAuth menggunakan URL OAuth yang telah dimodifikasi dengan kode otorisasi milik penyerang. Akibatnya, korban justru terhubung ke akun penyerang. Mengapa ini menjadi masalah? Studi kasus nyata yang dilakukan oleh Salt Security menunjukkan bagaimana penyerang dapat membuat tautan berbahaya dan menyebabkan korban menginstal plugin ChatGPT yang telah dimodifikasi dengan sesi milik penyerang. Dengan demikian, penyerang dapat mengakses data percakapan pribadi korban. Karena penyerang mengendalikan plugin tersebut, mereka dapat mencegat informasi sensitif seperti kredensial atau detail pribadi lainnya. Pre-Account Takeover Analisis terakhir kami berfokus pada kerentanan yang dikenal sebagai pre-account takeover. Jenis kerentanan ini terjadi ketika penyerang mengeksploitasi celah dalam proses otorisasi atau registrasi, memungkinkan mereka mengambil alih akun pengguna sebelum pengguna sah menyelesaikan proses OAuth. Berikut cara serangan ini dapat terjadi: Penyerang memulai proses pendaftaran menggunakan alamat email korban dan membuat akun. Korban kemudian mencoba masuk atau mendaftar ke situs yang sama menggunakan penyedia OAuth dan alamat email mereka. Dalam beberapa kasus, ketika korban terhubung menggunakan penyedia OAuth, situs web hanya memverifikasi akun tanpa mendeteksi bahwa akun tersebut awalnya dibuat oleh penyerang, sehingga penyerang dapat mengambil alih kendali akun tersebut. Karena penyerang telah membuat akun dengan email korban, mereka dapat masuk ke akun korban tanpa disadari oleh korban. Kerentanan ini umumnya tidak dianggap berisiko tinggi karena bergantung pada serangkaian peristiwa yang tidak selalu terjadi: Penyerang harus mengetahui alamat email korban dan berhasil membuat akun sebelum korban mencoba mendaftar. Akibatnya, jenis kerentanan ini sering dikategorikan sebagai low severity, karena tidak melibatkan eksploitasi langsung; penyerang harus menunggu korban untuk masuk, dan waktu kejadian ini tidak dapat diprediksi. Kami menemukan tujuh situs web yang rentan terhadap pre-account takeover (Gambar 6). Hasil Penelitian Dari analisis konfigurasi OAuth di 100 situs web, terlihat bahwa meskipun banyak yang telah menerapkan langkah-langkah keamanan dengan baik, masih ada ruang untuk perbaikan. Tabel berikut merangkum temuan kami sepanjang penelitian ini (Gambar 7). Dalam tabel berikut, kami menunjukkan: Jumlah situs yang telah divalidasi untuk kategori tertentu. Jumlah “Not Validated”, yaitu kesalahan konfigurasi yang tidak dapat dieksploitasi. Jumlah “Exploitable”, yaitu situs yang memiliki kerentanan yang dapat kami eksploitasi. Wawasan dan Rekomendasi Sebagian besar situs web—setidaknya berdasarkan penelitian kami—telah mengikuti praktik terbaik dalam konfigurasi OAuth, sehingga secara signifikan mengurangi potensi serangan. Namun, masih ada beberapa kasus di mana situs web tidak sepenuhnya mematuhi standar keamanan OAuth, yang membuat mereka rentan terhadap berbagai jenis serangan OAuth. Dari penelitian ini, kami telah mempelajari beberapa langkah penting untuk meningkatkan keamanan OAuth: Konfigurasikan redirect_uri ke jalur absolut Pastikan parameter redirect_uri diatur sebagai URL absolut untuk mencegah potensi masalah pengalihan yang dapat dimanfaatkan oleh penyerang. Gunakan PKCE (Proof Key for Code Exchange) Dengan menerapkan PKCE, penyerang tidak dapat menukar kode otorisasi yang dicuri dengan token akses, bahkan jika kode tersebut berhasil dicegat melalui serangan open redirect. Validasi parameter state Parameter state harus dibuat unik untuk setiap sesi dan divalidasi dengan benar untuk mencegah serangan CSRF (Cross-Site Request Forgery). Cegah serangan pre-account takeover dengan: Memverifikasi kepemilikan email: Pastikan pengguna tidak dapat mendaftar dengan alamat email yang bukan milik mereka dan wajibkan penggunaan autentikasi dua faktor (2FA) untuk validasi email. Menangani proses login…

Minggu ini, kami mengumumkan perkembangan penting dalam perjalanan kami untuk menghadirkan platform keamanan identitas yang paling kuat dan komprehensif di industri. CyberArk telah mengakuisisi Zilla Security, pemimpin dalam solusi modern Identity Governance and Administration (IGA), yang membawa teknologi canggih berbasis AI ke dalam platform kami yang terdepan di industri. Akuisisi ini menjadi terobosan besar dalam lanskap tata kelola identitas, mengatasi tantangan yang telah lama menghambat solusi IGA tradisional. Sistem IGA lama sering kali lambat diterapkan, sulit diintegrasikan, memiliki keterbatasan dalam mendukung sistem modern, dan masih bergantung pada proses manual. Hal ini menyebabkan inefisiensi serta meningkatkan risiko keamanan dan kepatuhan. Di dunia modern, di mana identitas tidak lagi statis tetapi dinamis dan membutuhkan akses secara instan, satu-satunya cara untuk menyediakan identitas ini secara efisien dan aman adalah melalui solusi manajemen siklus hidup yang sepenuhnya otomatis. IGA Modern untuk Dunia Modern Berbeda dengan sistem IGA lama, platform IGA SaaS modern dari Zilla dirancang dari nol untuk menghadapi tantangan lingkungan digital saat ini, yang ditandai dengan ledakan aplikasi SaaS, manajemen terdesentralisasi, dan ancaman keamanan berbasis identitas. Dengan memanfaatkan manajemen peran berbasis AI, Zilla mengotomatiskan kepatuhan identitas dan proses provisioning, sehingga tata kelola menjadi lebih mudah, intuitif, dan mencakup semua aspek bagi perusahaan modern. Zilla juga menawarkan integrasi paling lengkap, baik untuk aplikasi SaaS umum maupun aplikasi yang disesuaikan. Dibandingkan dengan sistem IGA lama, pelanggan Zilla menemukan bahwa IGA modern ini: ✅5X lebih cepat diterapkan ✅ 80% lebih sedikit usaha dalam melakukan tinjauan akses ✅ 60% lebih sedikit tiket layanan untuk mempercepat provisioning Bagi pelanggan, akuisisi ini berarti nilai bisnis yang lebih cepat dengan pendekatan tata kelola yang modern dan mengurangi kompleksitas operasional. Membuat Keamanan Identitas Lebih Cerdas, Cepat, dan Efektif Ke depan, kami semakin berkomitmen untuk menghadirkan solusi yang membantu pelanggan menavigasi kompleksitas dunia digital dengan aman. Dengan bergabungnya Zilla, kami akan semakin memperluas Platform Keamanan Identitas berbasis AI paling komprehensif di industri, mencakup: 🔍 Penemuan & onboarding semua identitas dengan pemetaan konteks dan risiko. 🔑 Penerapan kontrol hak akses yang tepat di seluruh manajemen hak istimewa, sesi, kredensial, dan autentikasi. ⚙️ Manajemen siklus hidup otomatis, kebijakan, tata kelola, dan kepatuhan. Kami sangat senang menyambut Deepak Taneja dan Nitin Sonawane, serta seluruh tim berbakat Zilla, ke dalam keluarga CyberArk. Bersama, kita akan mendefinisikan ulang tata kelola identitas dan menjadikan masa depan keamanan identitas lebih cerdas, cepat, dan efektif dari sebelumnya. Jika Zilla Security bergabung dengan CyberArk, beberapa kemungkinan yang dapat terjadi meliputi: Peningkatan Kemampuan Identity Governance dan Keamanan IGA yang lebih kuat: Dengan mengintegrasikan teknologi AI-powered IGA dari Zilla, CyberArk dapat meningkatkan otomatisasi dalam provisioning, compliance, dan access review. Keamanan identitas yang lebih menyeluruh: CyberArk sudah dikenal sebagai pemimpin dalam Privileged Access Management (PAM). Dengan tambahan IGA dari Zilla, mereka bisa menawarkan solusi keamanan identitas yang lebih holistik untuk semua jenis identitas (manusia & mesin). Kecepatan & Efisiensi yang Lebih Baik Penerapan lebih cepat: Zilla dikenal dengan pendekatan SaaS yang 5X lebih cepat dibandingkan solusi IGA tradisional. Ini bisa membuat CyberArk lebih kompetitif di pasar. Otomatisasi yang lebih luas: Dengan 60% lebih sedikit tiket layanan untuk provisioning, pelanggan bisa lebih fokus pada strategi bisnis daripada proses manual. Ekspansi Pasar dan Pelanggan Menjangkau lebih banyak industri: Dengan IGA modern, CyberArk bisa lebih menarik perusahaan yang menggunakan banyak aplikasi SaaS dan membutuhkan tata kelola akses yang lebih fleksibel. Integrasi lebih luas: Zilla memiliki integrasi yang luas dengan SaaS & sistem kustom, yang dapat memperluas ekosistem CyberArk. Dampak pada Kompetitor & Industri Tekanan pada vendor IGA lama: Pemain lama seperti SailPoint atau Saviynt bisa menghadapi tantangan lebih besar karena pendekatan modern CyberArk-Zilla. Standar baru dalam IGA: Dengan menggabungkan IGA + PAM + AI, CyberArk dapat menetapkan standar baru dalam keamanan identitas. Tantangan yang Mungkin Dihadapi Integrasi teknologi: Meskipun Zilla berbasis SaaS, tetap diperlukan waktu dan sumber daya untuk menyelaraskan platformnya dengan ekosistem CyberArk. Adaptasi pelanggan lama: Pelanggan CyberArk yang terbiasa dengan IGA tradisional mungkin perlu waktu untuk mengadopsi pendekatan modern berbasis AI. Secara keseluruhan, akuisisi ini bisa menjadi lompatan besar bagi CyberArk dalam menjadi pemimpin solusi keamanan identitas berbasis AI, sekaligus mengubah cara perusahaan mengelola dan mengamankan akses ke aset digital mereka. Infrastruktur IT yang kuat adalah kunci produktivitas perusahaan. Dengan CyberArk Indonesia, Anda bisa mendapatkan solusi IT lengkap yang sesuai dengan kebutuhan Anda. iLogo Indonesia sebagai mitra terpercaya siap mengintegrasikan semuanya agar bisnis Anda tetap berjalan lancar dan aman. Hubungi kami sekarang atau kunjungi CyberArk.ilogoindnesia.com untuk informasi lebih lanjut!

Anda mungkin tidak mengenali istilah “OAuth” (Open Authorization), tetapi kemungkinan besar Anda telah menggunakannya tanpa menyadarinya. Setiap kali Anda masuk ke aplikasi atau situs web menggunakan akun Google, Facebook, atau lainnya, OAuth memberikan akses terbatas ke data Anda tanpa membagikan kata sandi. OAuth menyederhanakan proses autentikasi pengguna di berbagai platform, menjadikannya bagian penting dalam pengalaman online yang aman. Namun, di balik kesederhanaannya, terdapat sistem yang kompleks yang, jika tidak diterapkan dengan benar, dapat menyebabkan pengambilalihan akun. Dalam postingan blog ini, kami akan membahas analisis kami terhadap implementasi OAuth di 100 situs web, menyoroti masalah keamanan umum, dan membahas teknik yang digunakan untuk mengidentifikasinya. Sebagai bagian dari penelitian ini, kami mengembangkan alat open-source bernama “oauth-hunter” untuk membantu menemukan kerentanan dan menyederhanakan proses penelitian kami. tl;dr (Ringkasan Singkat) Kami menganalisis 100 situs web yang menggunakan OAuth, dari platform besar hingga situs yang lebih kecil. 28 situs web tidak memverifikasi parameter redirect_uri dengan benar, dan 18 di antaranya mengizinkan penambahan path apa pun setelah domain. 21 situs web tidak memverifikasi parameter state dengan benar, dan 8 di antaranya memungkinkan penyerang menipu korban agar menyelesaikan proses OAuth, sehingga memberikan akses ke sesi korban. 7 situs web memiliki kerentanan pre-account takeover. Penelitian Penelitian ini dilakukan untuk memahami bagaimana situs web menerapkan OAuth dan apakah mereka mengikuti praktik terbaik untuk mencegah pengambilalihan akun. Tujuan kami adalah menilai seberapa efektif berbagai situs web dalam mengamankan proses autentikasi mereka terhadap kerentanan terkait OAuth. Selama penyelidikan, kami menganalisis 100 situs web, mulai dari yang besar dan populer hingga yang lebih kecil. Mayoritas situs menggunakan penyedia identitas (IdP) yang umum, seperti: Facebook (47%) GitHub (35%) GitLab (1%) Lainnya (17%) Sebelum masuk ke hasil penelitian, mari kita tinjau dasar-dasar OAuth. Bagaimana OAuth Bekerja? Alur Authorization Code Flow dalam diagram di bawah ini (Gambar 1) menggambarkan proses OAuth. Metode ini adalah salah satu yang paling umum dan aman untuk memberikan akses, karena melibatkan pertukaran kode sementara dengan token akses, sehingga data sensitif seperti kredensial tidak terekspos ke klien. Sebelum memulai, berikut adalah empat komponen utama dalam alur OAuth yang akan kami jelaskan melalui diagram ini: Resource owner → Pengguna yang memiliki data atau sumber daya, misalnya “John”. Client → Aplikasi atau situs web (contoh: example.com) yang meminta akses ke sumber daya atas nama pengguna (John), misalnya informasi profilnya. Authorization server (OAuth provider) → Layanan yang mengautentikasi pengguna dan memberikan token akses, seperti GitHub. Resource server → Server yang menyimpan sumber daya yang dilindungi (data atau layanan) yang ingin diakses oleh klien atas nama pemilik sumber daya. Dalam kasus ini, GitHub bertindak sebagai authorization server dan resource server, sehingga kami tidak membahasnya secara terpisah. Gambar 1 – OAuth Authorization Code Flow Mari kita bahas alur authorization code (Gambar 1): John, sebagai pemilik sumber daya, mengunjungi situs web example.com (OAuth Client) dan memulai proses login dengan memilih opsi GitHub. Karena example.com tidak mengenali John, situs tersebut meminta bukti identitasnya. John kemudian dialihkan ke GitHub, yang bertindak sebagai authorization server, dan GitHub meminta izin dari John untuk mengizinkan example.com mengakses data GitHub miliknya. GitHub mengirimkan kode otorisasi unik kepada John untuk dibagikan ke example.com. John memberikan kode otorisasi tersebut kepada example.com. Example.com meneruskan kode otorisasi John ke GitHub dan meminta access token. Setelah GitHub memverifikasi kode otorisasi, GitHub mengirimkan access token ke example.com. Example.com menggunakan access token tersebut untuk meminta informasi pengguna (misalnya identitas John) dari GitHub. GitHub memvalidasi access token dan mengembalikan informasi identitas pengguna (misalnya, “John”). Example.com mengautentikasi John berdasarkan identitas yang diterima dan memberikan akses ke sumber dayanya. Alur OAuth dapat bervariasi tergantung pada parameter OAuth yang digunakan dalam implementasi yang berbeda. Memahami Parameter Kunci OAuth Sekarang setelah kita memahami alur dasar OAuth Authorization Code, mari kita lihat beberapa parameter OAuth yang penting untuk memahami potensi vektor serangan: redirect_uri: URI tempat penyedia OAuth akan mengarahkan pengguna (dalam hal ini, John) setelah mereka menyetujui atau menolak otorisasi. URI ini harus terdaftar sebelumnya dengan penyedia OAuth sebagai bagian dari proses registrasi aplikasi klien. response_type: Menentukan jenis respons yang diharapkan oleh aplikasi klien dari penyedia OAuth. Jenis yang umum meliputi: code: Flow: Authorization Code Grant. Deskripsi: Klien mengharapkan pemilik sumber daya (pengguna) memberikan otorisasi, sehingga penyedia OAuth mengeluarkan kode otorisasi yang kemudian dapat ditukar dengan token akses. Metode ini paling umum digunakan untuk aplikasi web berbasis server. token: Flow: Implicit Grant. Deskripsi: Klien menerima token akses secara langsung dari pemilik sumber daya. Biasanya digunakan dalam aplikasi klien berbasis JavaScript seperti Single Page Applications (SPA). client_id: Identifikasi unik yang diberikan oleh penyedia OAuth (misalnya, GitHub) kepada aplikasi klien (contohnya, example.com). scope: Menentukan izin spesifik yang diminta oleh klien dalam alur OAuth. state: Fitur keamanan untuk mencegah Cross-Site Request Forgery (CSRF). prompt: Parameter yang mengontrol bagaimana penyedia otorisasi meminta otentikasi pengguna. Beberapa opsi umum: none: Tidak ada interaksi pengguna, gagal jika diperlukan otentikasi atau persetujuan. login: Memaksa pengguna untuk login ulang. consent: Memaksa pengguna untuk memberikan izin lagi, meskipun sudah pernah diberikan. select_account: Memungkinkan pengguna memilih akun jika memiliki lebih dari satu akun yang masuk. response_mode: Menentukan bagaimana respons otorisasi dikirimkan ke klien. Opsi umum meliputi: query: Respons dikirim sebagai parameter kueri dalam URL. fragment: Respons dikirim sebagai parameter fragment (#) dalam URL. form_post: Respons dikirim sebagai form submission (lebih aman untuk server yang menangani POST requests). Eksploitasi Parameter OAuth dalam Serangan Meskipun parameter-parameter ini penting dalam proses OAuth, jika tidak divalidasi dengan benar, mereka dapat menjadi celah keamanan. Beberapa contoh eksploitasi: Bypass Patch CVE-2023-6291: Penyerang berhasil melewati patch dengan mengganti response_mode=fragment menjadi response_mode=form_post, memungkinkan mereka untuk mengubah redirect menggunakan form HTML, sehingga pengguna diarahkan ke situs berbahaya. Eksploitasi prompt=none: Dengan menyetel parameter prompt=none, penyerang dapat menghindari layar persetujuan pengguna. Jika korban sudah masuk sebelumnya, server otorisasi akan langsung mengeluarkan kode otorisasi tanpa persetujuan pengguna. Eksploitasi redirect_uri untuk Pengambilalihan Akun Salah satu metode serangan paling umum dalam OAuth adalah penyalahgunaan redirect_uri, yang dapat mengarahkan korban ke situs milik penyerang dengan kode otorisasi mereka. Jika aplikasi tidak menerapkan validasi ketat pada redirect_uri, penyerang dapat mengubah URL tujuan agar mengarah ke situs mereka sendiri. Contoh skenario serangan: Penyerang mengirimkan tautan OAuth yang telah dimodifikasi melalui email phishing: https://github.com/login/oauth/authorize?redirect_uri=https://attacker.com…

Pesatnya Pertumbuhan Agen AI Berbasis Web Peluncuran ‘Operator’ oleh OpenAI menandai terobosan besar dalam otomatisasi berbasis AI. Saat ini masih ditujukan untuk konsumen, namun hanya soal waktu sebelum agen AI berbasis web seperti ini diadopsi secara luas di lingkungan kerja. Agen ini bukan sekadar chatbot; mereka mampu meniru interaksi manusia dengan aplikasi web, menjalankan perintah, dan mengotomatisasi tugas yang sebelumnya memerlukan input manual. Otomatisasi telah lama mengubah alur kerja di berbagai perusahaan, tetapi kehadiran agen AI ini menjanjikan kemajuan yang lebih signifikan. Namun, di balik potensinya, teknologi ini juga menghadirkan tantangan besar dalam hal keamanan dan manajemen risiko AI yang harus segera diperhatikan. Selama ini, otomatisasi telah menggantikan berbagai tugas berulang di berbagai fungsi bisnis. Namun, agen AI berbasis web tidak hanya menyederhanakan pekerjaan—mereka juga dapat mulai melakukan tindakan yang sebelumnya tidak bisa dilakukan oleh karyawan. Perubahan ini berpotensi merevolusi produktivitas, tetapi juga membawa banyak tantangan keamanan yang harus segera diatasi. Asisten Pribadi atau Risiko Keamanan? Agen AI dalam Penggunaan Konsumen vs. Perusahaan Untuk memahami dampak potensial agen AI berbasis web di lingkungan kerja, pertimbangkan dua skenario berikut: Penggunaan konsumen: “Operator, pesan liburan akhir pekan: cari penerbangan, reservasi hotel, sewa mobil, dan buat reservasi makan malam—semuanya sesuai anggaran saya.” Penggunaan di perusahaan: “Operator, analisis log akses IT selama enam bulan terakhir, cocokkan dengan catatan HR untuk mengidentifikasi perubahan jabatan, tandai akun yang tidak memiliki pemilik, deteksi eskalasi hak akses, dan buat laporan risiko keamanan untuk tim IT dan kepatuhan.” Jika skenario pertama adalah tugas pribadi sederhana dengan implikasi keamanan yang minim, skenario kedua melibatkan data sensitif, otomatisasi keputusan keamanan, dan bahkan berpotensi melewati pengawasan IT tradisional. Hal ini menimbulkan pertanyaan krusial dalam keamanan siber AI: Bagaimana kita mengontrol akses agen AI? Siapa yang mengawasi tindakan mereka? Apa yang terjadi jika mereka diretas? Otomatisasi Perusahaan: Membuka Potensi Lebih dari Sekadar Efisiensi IT Otomatisasi perusahaan selama ini berfokus pada penyederhanaan tugas berulang—melakukan hal yang sudah ada dengan lebih cepat dan efisien. Namun, seiring berkembangnya agen AI, potensinya tidak hanya terbatas pada otomatisasi tugas, tetapi juga membawa risiko baru. Sebagai contoh, agen AI dapat melakukan hal berikut: Masuk ke Salesforce, membuat peluang bisnis, dan menghasilkan laporan secara mandiri. Mengotomatiskan keterlibatan pelanggan melalui rangkaian email di HubSpot. Mengelola akses file dan mengekstrak data dari gambar atau teks. Mengaktifkan infrastruktur cloud sesuai permintaan. Berbeda dengan otomatisasi tradisional yang memerlukan integrasi API atau keahlian teknis mendalam, agen AI beroperasi seperti pengguna manusia—berinteraksi langsung dengan aplikasi bisnis, mengklik tombol, memasukkan kredensial, dan menjalankan tugas secara real-time. Potensi efisiensinya besar, tetapi risikonya juga signifikan. Dari Cloud ke AI: Gelombang Transformasi Berikutnya Seperti halnya komputasi cloud yang merevolusi dunia bisnis dengan kecepatan dan skalabilitasnya, AI kini mengalami transformasi serupa. Cloud membawa tantangan keamanan seperti kesalahan konfigurasi, risiko identitas, dan perluasan permukaan serangan—sesuatu yang memerlukan waktu bertahun-tahun bagi tim IT dan keamanan untuk mengatasinya. AI mengikuti pola yang sama. Bisnis berlomba-lomba mengadopsinya, sementara tim keamanan masih mencari cara untuk melindungi arsitektur, alur kerja, dan data yang didorong oleh AI. Penelitian CyberArk menyoroti beberapa ancaman baru yang muncul bersamaan dengan risiko agen AI berbasis web: Ancaman infrastruktur: Agen AI bergantung pada kredensial, kunci, dan token. Jika token sesi diretas, penyerang dapat mengambil alih agen AI dan menyamar sebagai pengguna yang sah. Ancaman sesi/akses: Agen AI dapat dimanipulasi untuk menjalankan tindakan yang tidak diinginkan melalui serangan penyuntikan perintah (prompt injection attacks)—bentuk baru dari rekayasa sosial. Ancaman identitas AI: Model AI dapat dirusak (poisoned), menyebabkan perilaku berbahaya seperti pencurian data atau penyisipan backdoor ke dalam sistem perusahaan. Dengan meningkatnya ancaman ini, keamanan agen AI harus menjadi prioritas utama dalam strategi keamanan siber perusahaan. Transformasi yang Didukung AI Sudah Hadir, tetapi Pertanyaannya Bukan Apakah AI Akan Mengubah Alur Kerja—Melainkan Apakah Kita Bisa Mengamankannya Sebelum Risikonya Tak Terkendali. Risiko Keamanan Agen AI Berbasis Web: Siapa yang Mengendalikan? Seiring semakin otonomnya agen AI berbasis web, perusahaan harus meninjau ulang strategi keamanannya. Akses berbasis browser: Bagaimana cara mengontrol akses jika agen AI berjalan di cloud dan berinteraksi dengan aplikasi bisnis melalui browser? Apa yang terjadi jika agen AI menggunakan kredensial Anda untuk melakukan tindakan atas nama Anda? Siapa yang bertanggung jawab atas tindakan tersebut? Apakah tindakan tersebut dipantau? Kontrol sesi dan audit: Tim IT dapat memantau sesi dan melacak aktivitas saat manusia berinteraksi dengan aplikasi. Tetapi bagaimana kita dapat mempertahankan tingkat pengawasan dan kontrol yang sama terhadap agen AI? Risiko autentikasi: Setelah diberikan akses, agen AI dapat menjalankan tindakan tanpa autentikasi lebih lanjut. Bagaimana kita dapat mencegah tindakan yang tidak sah dengan dalih otomatisasi? Keamanan identitas dan penilaian kerentanan AI: Dengan semakin banyaknya agen AI, bagaimana perusahaan dapat memastikan infrastruktur identitas tetap tangguh? Kontrol identitas tradisional berfokus pada pengguna manusia, tetapi otomatisasi berbasis AI memerlukan langkah keamanan adaptif untuk identitas mesin. Bisakah kita menetapkan dan mengelola agen AI sebagai identitas terpisah dengan kebijakan hak akses minimal yang dapat ditegakkan? Bagaimana kita mencegah agen AI meningkatkan hak akses mereka atau dieksploitasi sebagai vektor serangan baru? Siklus hidup dan eksposur data: Berapa lama agen AI menyimpan data sensitif? Siapa yang memiliki akses ke log dan riwayat eksekusi mereka? Tindakan pencegahan apa yang mencegah penyalahgunaan atau eksposur yang tidak disengaja? Selama bertahun-tahun, kita telah mengamankan akun pengguna manusia, menegakkan akses dengan hak istimewa minimum, dan memantau aktivitas mencurigakan. Kini, kita harus menerapkan prinsip-prinsip tersebut ke dalam keamanan berbasis AI. AI(Sec)Ops: Lahirnya Paradigma Keamanan Baru? Apakah kita siap membiarkan AI menangani tugas-tugas online pribadi kita? Mungkin saja. Tetapi apakah kita siap membiarkan AI mengambil alih alur kerja perusahaan? Itu pertanyaan lain. Perusahaan akan selalu mengejar efisiensi dan ROI yang lebih tinggi, tetapi keamanan tidak boleh menjadi pemikiran setelahnya. Otomatisasi berbasis AI adalah keniscayaan. Namun, saat perusahaan beralih ke alur kerja yang didukung AI, mereka harus mengadopsi pola pikir yang berorientasi pada keamanan. Masa depan dunia kerja sedang berubah, dan agen AI akan memainkan peran penting. Pertanyaan sebenarnya adalah: Bagaimana kita memastikan mereka bekerja untuk kita—tanpa menjadi ancaman? Untuk mengamankan agen AI, kita harus menerapkan praktik terbaik dari DevSecOps yang telah kita pelajari di era cloud. Membangun AI(Sec)Ops sejak sekarang—sebelum risikonya melampaui upaya mitigasi kita—akan memastikan kita mengelola risiko secara proaktif….