Credential Lama Bisa Menjadi Pintu Masuk Breach Baru

Klue, perusahaan market research asal Vancouver, mengonfirmasi bahwa hacker memakai credential lama dari tahun 2022 untuk mengakses sistemnya dan mencuri data sejumlah customer korporat.

Credential itu disebut berasal dari pilot terbatas dengan pihak ketiga. Masalahnya, credential tersebut masih bisa dipakai bertahun-tahun kemudian.

Di permukaan, ini terdengar seperti insiden teknis: ada credential bocor, ada akses tidak sah, ada data customer yang diambil.

Tetapi pelajaran yang lebih penting bukan hanya tentang credential yang dicuri. Pelajarannya adalah tentang akses lama yang tidak pernah benar-benar ditutup.

The Core Update

Menurut laporan TechCrunch, Klue mendeteksi insiden ini pada 12 Juni dan kemudian mengungkapkan bahwa hacker berhasil mencuri data dari beberapa customer-nya, termasuk perusahaan cybersecurity dan LastPass.

Akses ke sistem Klue menjadi berbahaya karena sistem tersebut menyimpan OAuth tokens yang dapat dipakai untuk mengakses data customer di cloud dan database lain. Dengan kata lain, breach di satu vendor bisa membuka jalan ke data di tempat lain.

Klue menyebut credential yang dipakai hacker adalah legacy credential yang terkait dengan integration service. Perusahaan juga mengatakan credential itu awalnya diberikan kepada pihak ketiga pada 2022 untuk pilot terbatas.

Namun beberapa pertanyaan penting belum dijawab secara publik:

• pilot itu untuk apa?
• berapa lama pilot berjalan?
• siapa pihak ketiga yang menerima credential?
• mengapa credential tidak dicabut setelah pilot selesai?
• apakah credential dicuri dari pihak ketiga atau dari sistem Klue sendiri?
• monitoring seperti apa yang seharusnya mendeteksi akses tidak wajar lebih cepat?

Klue mengatakan sedang melakukan review menyeluruh atas credential management, vendor-access controls, monitoring capabilities, dan deployment security processes.

Itu langkah yang masuk akal. Tetapi bagi banyak bisnis, bagian paling penting dari kasus ini adalah pertanyaan yang lebih sederhana: berapa banyak akses lama yang masih hidup di sistem kita sendiri?

The Reality Check

Banyak organisasi menganggap risiko terbesar datang dari serangan yang canggih. Zero-day, malware baru, teknik social engineering yang rapi, atau attacker yang sangat terorganisir.

Kadang memang begitu.

Tetapi banyak breach juga terjadi karena hal yang lebih membosankan: credential lama, token yang tidak pernah dicabut, akun vendor yang masih aktif, API key yang dibuat untuk testing, atau integrasi sementara yang berubah menjadi permanen karena tidak ada yang menutupnya.

Masalah seperti ini jarang terlihat dramatis di awal. Saat pilot dimulai, tim ingin bergerak cepat. Vendor butuh akses. Integrasi perlu diuji. API key dibuat. OAuth token diberikan. Permission diperluas supaya pekerjaan tidak macet.

Itu semua bisa masuk akal pada saat itu.

Yang sering tidak terjadi adalah tahap penutupannya.

Pilot selesai, tetapi akses tetap hidup. Vendor tidak lagi aktif, tetapi akun masih ada. Engineer pindah project, tetapi token tidak dirotasi. Integrasi tidak dipakai lagi, tetapi credential masih valid. Dokumentasi tidak diperbarui. Tidak ada owner yang jelas.

Akhirnya, sistem punya pintu-pintu kecil yang tidak lagi dipakai oleh bisnis, tetapi masih bisa dipakai oleh attacker.

Ini bukan hanya masalah perusahaan teknologi besar. Bisnis yang lebih kecil juga punya versi yang sama:

• akun admin agency lama yang masih aktif
• akses hosting untuk freelancer lama
• API key payment gateway yang tersimpan di dokumen
• token WhatsApp, CRM, atau email marketing yang tidak pernah dirotasi
• akses Google Workspace atau Meta Business Suite yang tidak diaudit
• integrasi Zapier, Make, atau aplikasi internal yang tidak lagi dipakai

Risikonya membesar ketika satu sistem menyimpan akses ke sistem lain.

Dalam kasus Klue, perhatian publik meningkat karena akses ke Klue diduga dapat dipakai untuk mengambil data customer yang tersimpan di cloud dan database lain. Ini menunjukkan pola yang semakin umum: vendor bukan hanya menyimpan data, tetapi juga menyimpan kunci untuk berpindah ke sistem lain.

Karena itu, pertanyaan security tidak cukup berhenti di “apakah aplikasi ini aman?”

Pertanyaan yang lebih lengkap adalah:

• aplikasi ini punya akses ke data apa?
• akses itu berlaku sampai kapan?
• siapa yang bisa mencabutnya?
• apakah akses masih dibutuhkan hari ini?
• apakah penggunaan credential dimonitor?
• apakah ada alert jika akses dipakai dari lokasi, pola, atau volume yang tidak normal?

Credential lama sering berbahaya karena ia terlihat sah. Sistem tidak selalu tahu bahwa akses itu sudah tidak seharusnya dipakai. Dari sisi teknis, token masih valid. Permission masih ada. Request masih diterima.

Bagi sistem, itu bukan penyusup. Itu tamu lama yang masih memegang kunci.

The Havedev Way

Dari sudut pandang Havedev, kasus seperti ini mengingatkan bahwa keamanan digital tidak hanya soal membeli tool security baru. Banyak organisasi perlu disiplin dasar yang lebih rapi dalam mengelola akses.

Tool bisa membantu. Password manager, secret scanner, SIEM, identity provider, dan monitoring platform semuanya berguna.

Tetapi sebelum itu, bisnis perlu menjawab satu hal: apakah lifecycle akses sudah jelas?

Setiap credential sebaiknya punya konteks yang bisa dibaca:

• dibuat untuk kebutuhan apa
• diberikan kepada siapa
• punya akses ke sistem apa
• berlaku sampai kapan
• siapa owner internalnya
• kapan terakhir dipakai
• kapan harus dirotasi atau dicabut

Tanpa konteks ini, credential management berubah menjadi tumpukan kunci tanpa label.

Untuk bisnis yang memakai banyak SaaS, vendor, automation, dan integrasi internal, audit akses sebaiknya menjadi kebiasaan operasional. Tidak harus rumit di awal. Mulai dari daftar paling sederhana.

Pilih sistem yang paling dekat dengan data penting:

• email bisnis
• CRM
• payment dan invoice
• cloud storage
• customer support platform
• website dan hosting
• database customer
• automation tools
• dashboard internal

Lalu cek siapa dan apa saja yang masih punya akses.

Jika ada akses yang tidak punya owner, itu risiko. Jika ada token yang tidak diketahui fungsinya, itu risiko. Jika ada vendor lama yang masih bisa login, itu risiko. Jika ada credential yang dibuat untuk testing tetapi masih aktif di production, itu risiko.

Security yang sehat sering dimulai dari pekerjaan yang tidak terlihat menarik: mencabut akses, memberi nama credential dengan jelas, membatasi permission, membuat expiry date, merotasi token, dan mencatat owner.

Ini bukan pekerjaan yang ramai di presentasi. Tetapi saat insiden terjadi, disiplin seperti ini sering menjadi pembeda antara gangguan kecil dan breach besar.

Untuk integrasi, prinsipnya sederhana: akses harus sekecil mungkin, sependek mungkin, dan sejelas mungkin.

Sekecil mungkin berarti permission hanya sesuai kebutuhan. Jika vendor hanya perlu membaca satu jenis data, jangan beri akses luas ke seluruh workspace.

Sependek mungkin berarti akses punya masa berlaku. Pilot harus punya tanggal selesai. Testing harus punya tanggal pembersihan. Token sementara harus benar-benar sementara.

Sejelas mungkin berarti setiap akses punya pemilik dan alasan. Kalau tidak ada yang bisa menjelaskan credential itu untuk apa, kemungkinan besar credential itu harus dicabut atau dibuat ulang dengan kontrol yang lebih baik.

Kasus Klue juga menunjukkan pentingnya monitoring. Mencabut akses lama adalah satu sisi. Mendeteksi penyalahgunaan akses yang masih valid adalah sisi lain.

Bisnis perlu tahu ketika ada pola yang tidak biasa:

• data diunduh dalam volume besar
• token lama tiba-tiba aktif kembali
• akses muncul dari lokasi yang tidak lazim
• integrasi mengambil data di luar pola normal
• credential dipakai pada jam atau endpoint yang tidak biasa

Tanpa monitoring, akses sah yang disalahgunakan bisa berjalan cukup lama sebelum terlihat.

Pelajaran praktisnya bukan bahwa semua bisnis harus takut memakai vendor atau integrasi. Vendor dan integrasi tetap penting. Banyak proses modern memang bergantung pada koneksi antar sistem.

Tetapi setiap koneksi adalah tanggung jawab. Setiap token adalah kunci. Setiap pilot yang selesai harus meninggalkan sistem dalam kondisi lebih bersih, bukan menambah pintu yang terlupakan.

Sebelum menambah tool baru, audit dulu akses lama.

Sebelum membuat integrasi baru, tentukan tanggal review.

Sebelum memberi credential ke pihak ketiga, pastikan ada rencana pencabutan.

Karena dalam banyak breach, masalahnya bukan organisasi tidak punya security sama sekali. Masalahnya adalah akses lama masih dipercaya terlalu lama.

Dapatkan Audit Teknis Gratis untuk meninjau akses website, integrasi, automation, dan alur data yang mungkin masih menyimpan risiko tersembunyi.

---

Sumber referensi berita: TechCrunch