Teknologi terus maju dengan kecepatan yang belum pernah terjadi sebelumnya. Pengembangan dan penggunaan Antarmuka Pemrograman Aplikasi (API) menjadi contoh yang sangat terkenal.
Laporan Salt Labs State of API Security terbaru menemukan bahwa keseluruhan lalu lintas API meningkat 168 persen selama 12 bulan, dengan lalu lintas serangan API meningkat sebesar 117 persen dalam periode waktu yang sama. Mungkin dapat dimengerti, banyak CISO berjuang untuk mengikutinya.
Menurut laporan yang sama, 94 persen organisasi mengalami insiden keamanan API selama 12 bulan. Termasuk dalam pengelompokan ini adalah nama-nama rumah tangga seperti Experian, Peloton, dan Starbucks. Bahkan Lego memiliki panggilan dekat, memperbaiki kerentanan API yang berpotensi bencana akhir tahun lalu. Perusahaan besar, dengan anggaran keamanan yang besar, secara konsisten tersandung pada insiden keamanan API. Jelas, teknik keamanan aplikasi tradisional tidak cukup untuk mengamankan API.
Dengan mengingat hal ini, kami berbicara dengan Yaniv Balmas, VP penelitian di Salt Security untuk menjernihkan beberapa pertanyaan yang paling sering diajukan tentang keamanan API.
BN: Bisakah arsitektur zero trust melindungi API?
YB: Sayangnya, banyak risiko API tidak dapat dikurangi dengan kepercayaan nol. Tujuan dari zero trust adalah untuk membatasi akses, sedangkan API membutuhkan akses untuk berfungsi. Sebagian besar API bersifat publik atau terbuka, dirancang untuk dikonsumsi oleh internet secara keseluruhan dan basis pelanggan yang besar, menghadirkan tantangan unik terhadap kepercayaan nol.
Terlebih lagi, serangan API biasanya terjadi di saluran tepercaya dan sesi yang diautentikasi. Penyerang tahu jika mereka dapat memperoleh kunci atau kredensial pengguna yang sah, mereka dapat mengakses data berharga. Dengan membonceng atau membajak sesi yang diautentikasi dengan cookie sesi aktif yang dicuri, token autentikasi, tantangan autentikasi dua faktor, kunci API, dan materi autentikasi lainnya, peretas tidak terhalang oleh arsitektur tanpa kepercayaan. Perlu diingat bahwa, menurut laporan State of API Security, 94 persen eksploit yang mengejutkan terjadi terhadap API yang diautentikasi.
Dalam hal kepercayaan nol, organisasi harus melampaui prinsip otentikasi dan otorisasi. Mereka membutuhkan perlindungan runtime API untuk terus memvalidasi akses dan perilaku pengguna yang sah terhadap sumber daya API, menemukan anomali, dan menunjukkan aktor jahat.
BN: Bisakah penawaran keamanan cloud melindungi API?
YB: Meskipun beberapa penyedia keamanan cloud menyediakan alat seperti manajemen API atau gateway API, produk poin seperti ini tidak cukup untuk melindungi perusahaan dari serangan API. Alat-alat ini memiliki kemampuan keamanan API yang terbatas pada lapisan aplikasi dan API, membuat API kurang terlindungi. Serangan API adalah eksploitasi zero-day yang efektif, yang berarti bahwa alat keamanan yang dirancang untuk mencari perilaku ‘buruk’ yang diketahui — tanda tangan atau IP yang masuk daftar hitam, misalnya — tidak akan pernah dapat melindungi API dengan baik. Perlu juga dicatat di sini bahwa karena API adalah logika aplikasi, pelanggan cloud memegang tanggung jawab utama untuk melindungi mereka dalam model tanggung jawab bersama untuk keamanan.
BN: Mengapa IAM, WAF, atau gateway API tidak dapat melindungi API?
YB: Meskipun IAM, WAF, dan gateway API adalah semua alat yang diperlukan dan penting dalam tumpukan keamanan setiap organisasi, mereka gagal melindungi API — sebagian besar karena mereka tidak menyediakan visibilitas atau kontrol keamanan yang diperlukan.
Penyerang secara konsisten melewati kontrol akses, serta mengambil kunci dan token. Peretas kontemporer ahli dalam menghindari kontrol akses, membonceng sesi pengguna yang diautentikasi, atau memanen materi autentikasi dari lalu lintas, penyimpanan perangkat, atau kode aplikasi. Teknik serangan ini tidak dapat dideteksi oleh solusi IAM, API, atau WAF.
Alat ini juga gagal mendeteksi masalah spesifik API — penyalahgunaan logika bisnis dan eksploitasi otorisasi, misalnya — karena mengandalkan tanda tangan dan aturan untuk deteksi serangan. Lebih buruk lagi, komponen manajemen API yang melekat dengan mereka juga dapat dieksploitasi.
Terlebih lagi, IAM, WAF, dan gateway API semuanya mengandalkan proxy. Karena model proxy memperlambat komunikasi API, organisasi biasanya gagal memediasi setiap API yang digunakan dengan gateway atau WAF — terutama untuk API dalam atau internal. Hal ini menyebabkan kurangnya visibilitas tentang bagaimana API tersebut digunakan.
BN: Bisakah API diamankan dengan perlindungan beban kerja?
YB: Perlindungan keamanan beban kerja memberikan banyak manfaat. Antara lain, mereka membantu menyediakan keamanan infrastruktur untuk memastikan Anda tidak menjalankan beban kerja pada versi perangkat lunak yang rentan, dan juga berguna untuk memblokir akses ke beban kerja pengguna eksternal. Namun, mereka gagal menyediakan API atau konteks tingkat aplikasi, sehingga gagal mengamankan API itu sendiri.
BN: Seberapa efektifkah shift-left untuk mengamankan API?
YB: Meskipun mengimplementasikan keamanan dalam tahap pengembangan adalah praktik yang bermanfaat, dukungan shift-left tidak berarti bahwa setiap API akan diamankan sebelum produksi. Alat pengujian pengembang tidak dapat mengidentifikasi semua kerentanan. Banyak masalah keamanan API yang umum tidak dapat diidentifikasi sebagai bagian dari pemindaian desain, pengembangan, dan pembuatan otomatis dengan analisis keamanan umum dan alat pengujian — cacat logika bisnis tidak dapat terlihat kecuali API dijalankan.
Kredit Foto: Panchenko Vladimir/Shutterstock
