Penulis: Faisal Yahya, IT Strategist
Inovasi cloud computing beberapa tahun belakangan makin menekankan pada konsep pay as you go, terlebih dengan adanya serverless architecture atau juga biasa disebut serverless computing. Meski masih terbilang teknologi baru dalam software delivery, serverless architecture menjadi sebuah terobosan potensial bagi bisnis pada berbagai tingkatan karena skalabilitas (scalability) dan keterjangkauan (affordability) pada konsep tersebut.
Hal ini karena konsep serverless architecture memungkinkan perusahaan mengkonsumsi cloud computing berdasarkan resources yang dikonsumsi oleh sebuah aplikasi. Hal ini berbeda dengan konsep cloud computing umumnya yang mengharuskan perusahaan mengalokasikan sumber daya komputasi yang dibutuhkan terlebih dulu.
Berkat serverless architecture, perusahaan juga tidak perlu khawatir investasi menjadi percuma. Biaya awal capital expenditure (capex) dapat di tekan ke titik terendah. Operating expenditure (opex) tidak lagi mengacu pada uptime dari node pada mesin virtual, namun berapa kali sebuah function pada serverless architecture di-invoke.
Pendek kata, perusahaan cukup berkonsentrasi pada kemampuan dan kualitas coding.
Dua Bagian Komponen
Arsitektur serverless pada dasarnya terdiri atas dua bagian besar, yakni:
Function-as-a-service (FaaS), yakni tempat penyimpanan sekaligus tempat mengeksekusi business-logic yang sederhana. FaaS terdiri dari kumpulan fungsi (function) yang sangat cocok dengan arsitektur event driven. Horizontal scalling pada FaaS dilakukan oleh penyedia layanan secara otomatis (elastic) dan pelanggan hanya membayar computing power yang digunakan, bahkan daya tersebut dihitung dalam satuan per 100 milisekon.
Backend-as-a-service (BaaS), merupakan sistem backend dengan ketersediaan tinggi (highly available) dari arsitektur serverless yang hampir tidak memerlukan setup atau konfigurasi. Contohnya, database Firebase (Google). Seperti halnya FaaS, developer tidak perlu berpikir tentang sumber daya komputasi yang mereka butuhkan. Para developer hanya perlu menyimpan dan mengolah data.
Kedua bagian tersebut tidak perlu seluruhnya ada. Elastisitas sumber daya komputasi bisa dianggap secara virtual tanpa batas karena penyedia layanan-lah yang melakukan provisioning secara otomatis.
Lebih jauh, proses simplifikasi pada arsitektur rupanya tidak hanya terjadi pada hardware. Para pekerja sistem yang tadinya bervariasi, seperti developer, tester, database administrator, operation, bahkan security engineer, kini digabungkan dalam satu pekerjaan, yakni cloud engineer.
Mengapa ini bisa terjadi? Dengan penerapan serverless architecture, developer tidak perlu lagi berpikir tentang perangkat keras, perangkat lunak, patch, maupun sumber daya komputasi. Mereka cukup berkonsentrasi pada coding sehingga menghasilkan runtime yang efektif, efisien, dan aman.
Ancaman Keamanan
serverless architecture
Keunggulan serverless architecture dalam proses delivery (penghantaran) software kepada end-user ternyata memerlukan perhatian khusus pada unsur keamanan. Meskipun developer tidak perlu dipusingkan dengan mekanisme patching atas celah keamanan pada server, merek perlu ekstra hati-hati dalam proses pembuatan coding.
Mekanisme white box testing menjadi sebuah keharusan dalam upaya mempertahankan integritas dan kualitas data yang diproses. Jika semua ini tidak disusun dengan pertimbangan keamanan, maka ada bahaya terburuk yang mengintai, yaitu kebocoran data nasabah.
Gb: expertsays3-diagram
Meski banyak variasi bentuk alur, diagram ini memberikan alur umum (general flow) serverless architecture. End-user atau end-point merupakan input sekaligus tujuan output. Alur ini melibatkan API gateway, FaaS, dan Baas, serta tiga point attack vector. Dengan mengacu pada alur ini, ada enam ancaman potensial sekaligus ancaman yang paling sering membayangi arsitektur ini.
- Event Injection
Ancaman ini terjadi akibat aplikasi atau threat actor yang mengirimkan data (sebagai parameter) dengan format dan content/script yang membahayakan. Ini bisa terjadi pada attack vector 1, 2, dan 3. Potensi kerusakan yang dapat terjadi pun tidak terbatas.
Countermeasure: lelakukan sanitasi atas data yang dikirimkan dalam parameter proses untuk memastikan jenis data sesuai dengan spesifikasi dan kuantitas yang diperlukan function.
- Broken Authentication
Ancaman ini terjadi karena lepasnya kontrol terhadap token yang berjalan pada proses. Serverless architecture mengenal session atau stateless authentication, dan tidak ada masalah memilih salah satunya. Yang menjadi masalah adalah jika token bocor dan bisa digunakan pada session yang berbeda sehingga memungkinkan akses terhadap data pada seluruh session yang berjalan dari setiap user yang berbeda.
Countermeasure: terapkan Identity Access Management pada setiap alur proses.
- Insecure Environment and Setting
Kelemahan pada teknik enkripsi yang diterapkan pada file (data at rest) maupun data (data in motion) akan menimbulkan kebocoran data. Serverless architecture memiliki titik (hop) lintasan data yang jauh lebih panjang dari client-server.
Ini menyebabkan potensi kebocoran data yang jauh lebih tinggi. Selain itu, setting yang terletak pada environment variable perlu dienkripsi sehingga tidak dapat terbaca oleh pihak luar.
Countermeasure: terapkan tingkat enkripsi yang cukup kuat.
- Over-Priviledged Permission
Celah keamanan ini merupakan kelemahan yang disebabkan oleh single access authentication atas semua function yang berjalan. Jika authentication access pada satu function bocor, maka akan menyebabkan kebocoran yang lebih luas.
Countermeasure: pisahkan authentication per function, satu function, satu role, dan satu authentication.
- Cross-Site-Scripting (XSS)
Celah keamanan ini paling sering menjadi penyebab kebocoran secara umum, termasuk pada arsitektur serverless architecture. Fleksibilitas yang kita berikan pada aplikasi ibarat “pisau bermata dua”. Misalnya, formulir komentar pada blog memiliki kapabilitas HTML editor, sehingga tidak sedikit script jahat yang diinjeksi bersamaan.
Countermeasure: melakukan sanitasi setiap tag script yang dikirimkan.
- Cross-Site Request Forgery (CSRF)
Celah keamanan ini selalu menyasar halaman atau function yang melakukan perubahan data. Penyerang (attacker) mengirimkan parameter dan query-string (dari field yang ada) secara otomatis melalui halaman palsu (forged) yang seolah-olah dikirimkan oleh user.
Countermeasure: berikan satu field dengan nama dan nilai acak, dan berubah setiap halaman di buka, sehingga menyulitkan penyerangan CSRF ini.
Keunggulan scalability (elastic) dan affordability yang diberikan oleh serverless architecture memerlukan trade-off dengan pertimbangan arsitektur keamanan yang agile dan bersifat prediktif. Serangan denial-of-service (DoS) pada arsitektur serverless dapat membuat tagihan bulanan membesar, sehingga kontradiktif dengan keterjangkauan yang dijanjikan.
Perancangan strategis terhadap keamanan siber sangat berpengaruh untuk memaksimalkan keuntungan atau manfaat yang dapat diperoleh dari arsitektur serverless. Dan ini bisa dimulai dari kesadaran developer sehingga dapat menciptakan coding yang capable dan aman.