Bulan lalu saya menulis sebuah artikel tentang cara platform kode rendah/tanpa kode menawarkan berbagi kredensial sebagai layanan, mengapa mereka melakukannya, dan bagaimana tampilannya perspektif penyerang. Dalam artikel ini, saya akan fokus pada implikasi dari kompromi itu dan bagaimana pengaruhnya terhadap perusahaan saat ini.
Inilah mengapa berbagi kredensial perusahaan Anda dengan orang lain adalah praktik yang buruk. Katakanlah saya ingin memberikan kredensial saya kepada seorang kolega untuk menanyakan log produksi untuk beberapa analisis perilaku pengguna satu kali. Di perusahaan biasa, memberikan izin kepada seseorang untuk menanyakan sumber data baru dapat berarti proses peninjauan akses yang lama, terutama jika menyangkut produksi atau data sensitif. Rekan saya bisa dengan mudah frustrasi. "Yang saya inginkan hanyalah melakukan permintaan kecil sekali ini, dan saya sudah menunggu selama sebulan!" bisa mereka katakan. Saya hanya bisa menjalankan kueri untuk mereka, tetapi saya dibanjiri dengan tugas sehari-hari saya sendiri, dan kueri satu kali cenderung menjadi rumit.
Saya memiliki satu solusi cepat: Saya bisa membagikan nama pengguna/kata sandi saya dengan kolega saya. Jika mereka mendapatkan tantangan MFA, saya akan dengan senang hati menyetujuinya. Saya tidak perlu menghabiskan waktu menjalankan kueri, dan rekan saya tidak diblokir. Semua orang menang! Benar?
Nah, Anda akan benar dalam analisis Anda, tetapi Anda kehilangan gambaran yang lebih besar. Meskipun penting bagi perusahaan bahwa kolega Anda melakukan analisis perilaku pengguna mereka, sama pentingnya, jika tidak lebih, penting bahwa perusahaan Anda tetap mematuhi seluruh standar privasi dan keamanan dan mempertahankan kepercayaan pelanggan dengan menjaga komitmen perusahaan terhadap keamanan .
Jika tujuan perusahaan tingkat tinggi tidak meyakinkan Anda, pertimbangkan tim manajemen pusat di TI atau keamanan. Tim tersebut mendasarkan operasi dan strategi keamanan mereka pada kenyataan bahwa setiap pengguna memiliki identitas unik mereka sendiri. Tim TI sedang menyiapkan kebijakan jaringan dan akses yang mengasumsikan setiap pengguna akan masuk dari satu IP perusahaan atau laptop perusahaan sekaligus; tim keamanan menghubungkan peristiwa berdasarkan ID pengguna; tim keuangan dapat menggabungkan laporan biaya per pengguna dan lingkungan cloud pribadi mereka. Berbagi kredensial merusak semua asumsi tersebut, antara lain. Ini menghilangkan makna dasar dari identitas online.
Contoh Dunia Nyata
Mari kita beralih ke dunia low-code/no-code dan memeriksa skenario dunia nyata. Di sebuah perusahaan besar, Jane, seorang karyawan yang terinspirasi dari tim layanan pelanggan, menyadari bahwa ketika karyawan di seluruh organisasi mengambil bagian dalam kasus pelanggan, mereka biasanya kehilangan informasi penting tentang pelanggan, seperti riwayat kasus dukungan dan pembelian terbaru. Ini menurunkan pengalaman pelanggan, karena mereka harus menjelaskan masalah mereka lagi dan lagi sementara kasus tersebut dialihkan ke karyawan yang tepat yang dapat mengatasi masalah tersebut.
Untuk meningkatkan ini, Jane membuat aplikasi yang memungkinkan karyawan perusahaan untuk melihat informasi penting tentang pelanggan ini ketika karyawan tersebut adalah bagian dari tim yang bertanggung jawab untuk menangani kasus dukungan pelanggan. Pertama, mari luangkan waktu sejenak untuk mengakui kekuatan kode rendah/tanpa kode, yang memungkinkan Jane mengidentifikasi kebutuhan dan menanganinya sendiri, tanpa meminta anggaran atau menunggu alokasi sumber daya TI.
Saat membangun aplikasi, Jane harus mengatasi banyak masalah, yang terbesar adalah izin. Karyawan di seluruh organisasi tidak memiliki akses langsung untuk menanyakan database pelanggan untuk mendapatkan informasi yang mereka butuhkan. Jika ya, maka Jane tidak perlu membuat aplikasi ini. Untuk mengatasi masalah ini, Jane masuk ke database dan menyematkan sesi terotentikasinya langsung di aplikasi. Ketika aplikasi menerima permintaan dari satu pengguna, itu akan menggunakan identitas Jane untuk mengeksekusi kueri itu dan kemudian mengembalikan hasilnya ke pengguna. Fitur penyematan kredensial ini, seperti yang kami jelajahi bulan lalu, adalah fitur utama platform low-code/no-code. Jane memastikan untuk mengatur kontrol akses berbasis peran (RBAC) dalam aplikasi sehingga setiap pengguna hanya dapat mengakses kasus pelanggan yang ditugaskan kepadanya.
Aplikasi ini memecahkan masalah bisnis yang penting, sehingga dengan cepat mendapatkan adopsi pengguna di seluruh perusahaan. Orang-orang senang bahwa mereka dapat memberikan layanan yang lebih baik kepada pelanggan mereka dengan memiliki konteks yang tepat untuk percakapan. Pelanggan pun senang. Sebulan setelah Jane membuat aplikasi, aplikasi itu sudah digunakan oleh ratusan pengguna di seluruh organisasi, dengan tingkat kepuasan pelanggan yang meningkat.
Sementara itu di SOC, peringatan tingkat keparahan tinggi yang menunjukkan aktivitas abnormal di sekitar basis data pelanggan produksi dipicu dan ditugaskan ke Amy, seorang analis keamanan yang berpengalaman. Investigasi awal Amy menunjukkan pengguna internal mencoba mengorek seluruh database, menanyakan informasi tentang banyak pelanggan dari beberapa alamat IP di seluruh organisasi. Pola kuerinya sangat kompleks; alih-alih pola enumerasi sederhana yang Anda harapkan untuk dilihat ketika database sedang digores, data pelanggan yang sama ditanyakan beberapa kali, terkadang melalui alamat IP yang berbeda dan pada tanggal yang berbeda. Mungkinkah ini penyerang yang mencoba membingungkan sistem pemantauan keamanan?
Setelah penyelidikan cepat, Amy menemukan informasi penting: Semua pertanyaan di semua alamat IP dan tanggal menggunakan satu identitas pengguna, seseorang bernama Jane dari tim layanan pelanggan.
Amy mengulurkan tangan kepada Jane untuk menanyakan apa yang terjadi. Awalnya Jane tidak tahu. Apakah kredensialnya dicuri? Apakah dia mengklik tautan yang salah atau memercayai email masuk yang salah? Tetapi ketika Jane memberi tahu Amy tentang aplikasi yang baru saja dia buat, mereka berdua menyadari bahwa mungkin ada hubungannya. Amy, analis SOC, tidak terbiasa dengan low-code/no-code, jadi mereka menghubungi tim AppSec. Dengan bantuan Jane, tim menemukan bahwa aplikasi Jane memiliki kredensial Jane yang tertanam di dalamnya. Dari perspektif basis data, tidak ada aplikasi — hanya ada Jane, yang menjalankan banyak kueri.
Jane, Amy, dan tim AppSec memutuskan untuk mematikan aplikasi hingga solusi ditemukan. Pengguna aplikasi di seluruh organisasi merasa frustrasi karena mereka mengandalkannya, dan pelanggan juga merasakannya.
Sementara Amy menutup masalah dan mendokumentasikan temuan mereka, VP layanan pelanggan tidak senang melihat tingkat kepuasan pelanggan turun, jadi mereka meminta Jane untuk mencari solusi permanen. Dengan bantuan dokumentasi platform dan tim Center of Excellence organisasi, Jane menghapus identitas yang disematkan dari aplikasi, mengubah aplikasi untuk menggunakan identitas setiap pengguna untuk menanyakan database, dan memastikan pengguna mendapatkan izin hanya untuk kasus pelanggan yang terkait dengannya. . Dalam versi baru dan lebih baik, aplikasi menggunakan identitas setiap pengguna untuk menanyakan database pelanggan. Jane dan pengguna aplikasi senang karena aplikasi kembali online, Amy dan tim AppSec senang identitas Jane tidak lagi dibagikan, dan perusahaan melihat tingkat kepuasan pelanggan mulai naik lagi. Semuanya baik-baik saja.
Dua minggu kemudian, SOC menerima peringatan lain tentang akses abnormal ke database pelanggan produksi. Itu tampak mirip dengan peringatan sebelumnya pada database yang sama. Sekali lagi, alamat IP dari seluruh organisasi menggunakan identitas pengguna tunggal untuk menanyakan database. Sekali lagi, pengguna itu adalah Jane. Namun kali ini, tim keamanan dan Jane mengetahui bahwa aplikasi tersebut menggunakan identitas penggunanya. Apa yang sedang terjadi?
Investigasi mengungkapkan bahwa aplikasi asli memiliki dibagikan secara implisit Sesi database terotentikasi Jane dengan pengguna aplikasi. Dengan berbagi aplikasi dengan pengguna, pengguna tersebut mendapat akses langsung ke koneksi, pembungkus di sekitar sesi database terautentikasi yang disediakan oleh platform low-code/no-code. Dengan menggunakan koneksi itu, pengguna dapat memanfaatkan sesi yang diautentikasi secara langsung — mereka tidak lagi harus melalui aplikasi. Ternyata beberapa pengguna telah mengetahui hal ini dan, berpikir bahwa ini adalah perilaku yang dimaksudkan, menggunakan sesi database terotentikasi Jane untuk menjalankan kueri mereka. Mereka menyukai solusi ini, karena menggunakan koneksi secara langsung memberi mereka akses penuh ke database, tidak hanya untuk kasus pelanggan yang ditugaskan kepada mereka.
Koneksi telah dihapus, dan insiden itu berakhir. Analis SOC menjangkau pengguna yang telah menggunakan koneksi Jane untuk memastikan mereka membuang data pelanggan yang telah mereka simpan.
Mengatasi Tantangan Keamanan Low-Code/No-Code
Kisah di atas adalah skenario kehidupan nyata dari sebuah perusahaan B2C multinasional. Beberapa detail dihilangkan atau disesuaikan untuk melindungi privasi. Kami telah melihat bagaimana seorang karyawan yang bermaksud baik tanpa disadari dapat berbagi identitas mereka dengan pengguna lain, menyebabkan berbagai macam masalah di seluruh TI, keamanan, dan bisnis. Seperti yang kami jelajahi bulan lalu, berbagi kredensial adalah fitur utama dari low-code/no-code. Itu norma, bukan pengecualian.
As kode rendah/tanpa kode terus berkembang di perusahaan, sadar atau tidak, sangat penting bagi tim keamanan dan TI untuk bergabung dalam percakapan pengembangan bisnis. Aplikasi low-code/no-code hadir dengan serangkaian tantangan keamanan yang unik, dan sifatnya yang produktif membuat tantangan tersebut menjadi akut lebih cepat dari sebelumnya.
