Keamanan Tanpa Server dan Fungsi

Komputasi tanpa server (Functions as a Service, FaaS) memungkinkan pengembang men-deploy fungsi individual yang dipanggil oleh peristiwa — permintaan HTTP, pesan antrean, pemicu basis data, atau pengatur waktu terjadwal — tanpa mengelola server yang mendasarinya. Platform terkemuka mencakup AWS Lambda, Google Cloud Functions, dan Azure Functions. Penyedia cloud mengelola penambalan, penskalaan, dan infrastruktur. Meskipun hal ini mengurangi beban operasional, model tanggung jawab keamanan menjadi berbeda: penyedia mengamankan lingkungan runtime, tetapi pengembang sepenuhnya bertanggung jawab atas kode fungsi, izin, dan konfigurasi.

Fungsi tanpa server memiliki permukaan serangan yang berbeda dibandingkan aplikasi tradisional: fungsi biasanya berumur singkat (detik hingga menit), sehingga EDR tradisional dan pemantauan jaringan menjadi kurang efektif; fungsi bersifat digerakkan oleh peristiwa, artinya banyak sumber input berbeda (peristiwa S3, API Gateway, SNS) dapat memicu eksekusi; fungsi sering berjalan dengan izin IAM yang dapat mengakses Resource cloud lain; dan fungsi menggunakan dependensi pihak ketiga (paket npm, pip) yang mungkin berisi kode berbahaya. Permukaan serangan ditentukan oleh input peristiwa, izin IAM, dan rantai kepercayaan dependensi.

Kerentanan keamanan tanpa server yang paling umum adalah peran IAM dengan hak berlebihan. Ketika pengembang memerlukan fungsi untuk mengakses satu bucket S3, mereka mungkin tergoda menetapkan s3:* (akses S3 penuh) untuk menghindari kesalahan izin. Fungsi yang disusupi atau rentan dengan peran ini kemudian dapat membaca, menulis, atau menghapus bucket apa pun dalam akun tersebut. Pertahanannya adalah peran IAM dengan hak istimewa minimum: setiap fungsi sebaiknya memiliki peran khusus yang hanya memberikan izin minimum yang diperlukan untuk tugas khusus fungsi tersebut. Alat seperti AWS IAM Access Analyzer dan Cloudsplaining secara otomatis mengidentifikasi peran Lambda dengan hak berlebihan.

Injeksi peristiwa terjadi ketika data yang dikendalikan penyerang dalam muatan peristiwa diproses secara tidak aman oleh kode fungsi. Karena fungsi tanpa server dapat dipicu oleh banyak sumber peristiwa — header HTTP, parameter kueri, catatan perubahan basis data, isi pesan antrean, dan konten email — semuanya dapat membawa muatan berbahaya. Jenis injeksi umum meliputi: injeksi SQL jika fungsi melakukan kueri ke basis data menggunakan data peristiwa, injeksi NoSQL (operator MongoDB dalam muatan JSON), injeksi perintah jika data peristiwa digunakan dalam perintah OS, dan SSRF (Server-Side Request Forgery) jika URL dari data peristiwa diambil. Validasi input dan kueri berparameter merupakan pertahanan yang penting.

Fungsi tanpa server sering bergantung pada lusinan paket pihak ketiga. Dependensi ini menimbulkan risiko rantai pasokan: paket berbahaya atau yang telah disusupi dapat menjalankan kode arbitrer dalam lingkungan eksekusi fungsi, mengakses variabel lingkungan (yang sering berisi secret), membuat koneksi jaringan keluar, dan menggunakan peran IAM fungsi untuk mengakses Resource cloud. Serangan terkenal seperti kompromi paket npm event-stream (2018) dan banyak paket typosquatting menunjukkan risiko ini. Pertahanannya mencakup penetapan dependensi, pemindaian SCA dalam CI/CD, dan jejak dependensi yang minimal.

Fungsi tanpa server sering menerima secret melalui variabel lingkungan yang dikonfigurasi di konsol cloud. Variabel lingkungan ini dapat dilihat oleh siapa saja yang memiliki akses IAM ke konfigurasi Lambda dan dapat diakses oleh kode apa pun yang berjalan di dalam fungsi. Praktik terbaik: hindari menyimpan secret secara langsung sebagai variabel lingkungan teks biasa; sebagai gantinya, simpan ARN atau nama secret dan ambil secret saat runtime dari AWS Secrets Manager atau Parameter Store; aktifkan enkripsi KMS untuk variabel lingkungan Lambda saat tersimpan; dan jangan pernah mencatat variabel lingkungan (banyak pencatat debug membuang semua variabel lingkungan saat terjadi error).

Penolakan layanan terhadap fungsi tanpa server dapat berupa pembanjiran pemanggilan — penyerang yang dapat memicu fungsi berulang kali mungkin menghabiskan batas konkurensi akun (bawaan Lambda adalah 1.000 eksekusi serentak per wilayah), sehingga fungsi lain dalam akun tersebut tidak dapat dieksekusi. Fungsi yang memproses input yang dikendalikan pengguna sebaiknya menerapkan pembatasan laju pada tingkat API Gateway, memvalidasi batas ukuran muatan, dan menetapkan nilai batas waktu yang sesuai untuk mencegah eksekusi yang tidak terkendali. Fungsi juga dapat menjadi sasaran serangan perluasan bergaya Billion Laughs saat mengurai XML/YAML jika input tidak dibatasi ukurannya.

Secara bawaan, fungsi AWS Lambda berjalan dalam VPC yang dikelola AWS dengan akses internet, tetapi tidak memiliki akses ke Resource dalam VPC privat Anda (basis data RDS, ElastiCache, API privat). Untuk mengakses Resource privat, Lambda harus dikonfigurasi agar berjalan di dalam VPC Anda dengan subnet dan kelompok keamanan tertentu. Namun, fungsi Lambda yang terhubung ke VPC tidak memiliki akses internet secara bawaan — fungsi tersebut memerlukan NAT Gateway untuk internet keluar. Kelompok keamanan yang terhubung ke fungsi Lambda sebaiknya mengikuti aturan hak istimewa minimum: hanya izinkan port dan tujuan tertentu yang diperlukan. Hindari penggunaan aturan keluar 0.0.0.0/0 pada kelompok keamanan fungsi produksi.

Pemantauan keamanan tanpa server memerlukan pendekatan yang berbeda dari pemantauan host tradisional. Karena fungsi bersifat sementara, agen berbasis host tidak praktis. Pemantauan yang efektif menggunakan: AWS CloudTrail untuk mencatat semua panggilan API Lambda (pemanggilan, perubahan konfigurasi, asumsi peran); CloudWatch Logs Insights untuk mengueri log eksekusi fungsi guna mencari pola anomali; Amazon GuardDuty untuk deteksi ancaman, termasuk aktivitas jaringan Lambda yang tidak biasa; serta alat keamanan komersial khusus tanpa server seperti Protego (sekarang bagian dari Check Point) atau pemantauan tanpa server Datadog yang menginstrumentasikan fungsi melalui lapisan untuk menyediakan visibilitas saat runtime.

Pengujian keamanan tanpa server memerlukan alat khusus: PureSec CLI (sekarang Check Point) dan Prowler memindai konfigurasi cloud untuk mencari kesalahan konfigurasi tanpa server; alat DAST dapat menguji fungsi yang dipicu HTTP untuk mencari kerentanan injeksi; analisis statis kode fungsi dengan alat seperti Bandit (Python) atau plugin keamanan ESLint dapat menemukan pola pengodean yang tidak aman; dan pengujian manual sebaiknya mencatat semua sumber peristiwa yang dapat memicu setiap fungsi lalu menguji masing-masing dengan muatan yang cacat dan berbahaya. OWASP Serverless Top 10 menyediakan daftar periksa kerentanan menyeluruh yang khusus untuk arsitektur tanpa server.

Komputasi tanpa server memperluas model tanggung jawab bersama lebih jauh ke arah penyedia. Penyedia cloud bertanggung jawab atas: lingkungan runtime fungsi, penambalan OS, keamanan infrastruktur yang mendasari, dan fasilitas fisik. Pelanggan tetap bertanggung jawab atas: keamanan kode fungsi, desain izin IAM, pengelolaan secret, validasi input, pengelolaan dependensi, konfigurasi pencatatan, dan kebijakan jaringan. Berkurangnya tanggung jawab atas infrastruktur bukan berarti berkurangnya tanggung jawab keamanan — hal ini hanya mengalihkan fokus investasi keamanan, terutama ke keamanan tingkat aplikasi dan IAM.

Uji pemahaman Anda tentang konsep CompTIA Security+ (SY0-701) dari pelajaran ini.

Dalam pelajaran ini Anda mempelajari: peran IAM dengan hak berlebihan merupakan risiko utama sistem tanpa server — setiap fungsi memerlukan peran khusus dengan hak istimewa minimum; serangan injeksi peristiwa mengeksploitasi sumber peristiwa apa pun yang mengirimkan data yang dikendalikan penyerang ke fungsi yang tidak memiliki validasi input; dan risiko rantai pasokan dependensi dari paket pihak ketiga dapat menyusupi eksekusi fungsi beserta akses ke kredensial IAM dan secret. Selanjutnya kita akan membahas pemindaian keamanan Infrastructure as Code untuk menemukan kesalahan konfigurasi sebelum deployment.