Belajar Cloud Security Engineer - Serverless & Function Security

#Pendahuluan

Setelah di episode 12 kita mengamankan container dan Kubernetes, sekarang kita pindah ke ujung spektrum model compute: serverless. Tidak ada server untuk di-hardening — provider mengelola patching, isolasi runtime, dan availability. Tapi jangan tertipu: permukaan serangan tidak hilang, ia hanya berpindah — dari infrastruktur ke konfigurasi, identitas, dan data event.

Mengapa episode ini penting? Karena serverless punya karakteristik keamanan unik: satu fungsi bisa dipanggil ribuan kali per menit oleh event dari banyak sumber (API, queue, S3), dan setiap event itu adalah input tak terpercaya. Kesalahan IAM di serverless lebih mudah terjadi karena role sering di-generate template, bukan ditulis sadar.

#Model Tanggung Jawab Serverless

Yang masih menjadi tugas kalian:

Intinya: security serverless = identity configuration + input handling. Dua hal itulah yang kita kerjakan.

#Execution Role: Least Privilege per Fungsi

Kesalahan nomor satu di serverless: semua fungsi berbagi satu role besar. Ketika satu fungsi dikompromikan (misal via event injection), penyerang mendapat izin gabungan semuanya.

Pola yang benar — satu fungsi, satu role, dengan policy yang menyebut resource spesifik:

resource "aws_iam_role_policy" "order_processor" {
  name = "order-processor-min"
  role = aws_iam_role.order_processor.id
 
  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Effect   = "Allow"
        Action   = ["sqs:ReceiveMessage", "sqs:DeleteMessage"]
        Resource = aws_sqs_queue.orders.arn
      },
      {
        Effect   = "Allow"
        Action   = ["dynamodb:GetItem", "dynamodb:UpdateItem"]
        Resource = aws_dynamodb_table.orders.arn
      }
    ]
  })
}

Perhatikan: tidak ada s3:*, tidak ada secretsmanager:GetSecretValue pada *. Fungsi ini hanya boleh menyentuh dua resource. Verifikasi dengan alat dari episode 3:

aws iam simulate-principal-policy \
  --policy-source-arn arn:aws:iam::123456789012:role/order-processor \
  --action-names s3:GetObject secretsmanager:GetSecretValue \
  --resource-arns '*'

Hasil idealnya implicitDeny untuk keduanya.

#Event Injection: Serangan Khas Serverless

Ini topik yang paling sering luput. Di serverless, event adalah input tak terpercaya — termasuk metadata-nya. Contoh rantai nyata:

1. Aplikasi menerima upload file; nama file dimasukkan user.
2. Upload memicu Lambda process-upload dengan event berisi key = nama file itu.
3. Handler memakai key langsung dalam command atau path: s3.get_object(Bucket=bucket, Key=key).
4. User mengirim ../../credentials/config.json → path traversal membaca objek lain.

Mitigasinya klasik tapi wajib: validasi dan sanitasi field event sebelum dipakai, jangan pernah percaya field seperti Records[0].s3.object.key, dan batasi regex nama file ke allowlist ketat.

Handler defensif: validasi key event

import re
 
SAFE_KEY = re.compile(r"^uploads/[a-f0-9-]{36}/[A-Za-z0-9._-]{1,128}$")
 
def handler(event, context):
    for record in event["Records"]:
        key = record["s3"]["object"]["key"]
        if not SAFE_KEY.match(key):
            raise ValueError(f"rejected malformed key: {key[:64]}")
        process(bucket="uploads-prod", key=key)

Pola sama berlaku untuk payload SQS/SNS/API Gateway: schema-validate dulu, baru proses.

#Exposures: Function URL dan API Gateway

Function URL (endpoint publik bawaan Lambda) praktis untuk demo, berbahaya jika lupa auth. Aturan sederhana:

• Function URL: hanya dengan AuthType: AWS_IAM; NONE hanya untuk endpoint publik yang memang disengaja dan rate-limited.
• API Gateway sebagai pintu utama: authorizer (JWT/Cognito/Lambda authorizer), throttling, WAF di depannya.

aws lambda list-functions \
  --query 'Functions[?FunctionUrlConfig!=null].{fn:FunctionName,url:FunctionUrlConfig.FunctionUrl,auth:FunctionUrlConfig.AuthType}'

Jika output menampilkan auth: NONE, perlakukan sebagai finding HIGH — sama seperti bucket publik di episode 7.

#Secrets: Environment Variable Bukan Tempatnya

Environment variable di Lambda nyaman tetapi bocor lewat banyak jalur: GetFunctionConfiguration, console, error stack trace, snapshot debug. Pola yang benar:

Resources:
  OrderProcessor:
    Type: AWS::Serverless::Function
    Properties:
      Runtime: python3.12
      Policies:
        - Statement:
            - Effect: Allow
              Action: secretsmanager:GetSecretValue
              Resource: !Sub arn:aws:secretsmanager:${AWS::Region}:${AWS::AccountId}:secret:prod/orders/db-*
      Environment:
        Variables:
          DB_SECRET_ARN: !Sub arn:aws:secretsmanager:${AWS::Region}:${AWS::AccountId}:secret:prod/orders/db

Yang ada di env var hanya referensi (ARN), bukan nilai. Fungsi fetch secret saat cold start dengan cache in-memory — pola lengkapnya kita bahas di episode 14.

#Checklist Serverless Security

• Satu fungsi = satu execution role; policy menyebut ARN spesifik.
• Semua field event divalidasi (schema + allowlist) sebelum dipakai.
• Function URL hanya AWS_IAM; API publik lewat API Gateway + authorizer + throttling.
• Env var hanya berisi referensi secret; nilai diambil runtime dengan cache.
• Log retention ditentukan; error tidak mengekspos nilai sensitif (masking di logging).
• Dependensi discan (SCA) bersama build — supply chain tetap relevan di serverless.

#Penutup

Inti yang harus dibawa pulang:

• Security serverless berpindah ke identitas (execution role) dan penanganan input (event).
• Satu fungsi satu role dengan resource spesifik — verifikasi lewat simulate-principal-policy.
• Event injection adalah vektor khas serverless: validasi semua field event tanpa kecuali.
• Eksposur dikontrol: function URL AWS_IAM, API publik lewat gateway dengan authorizer.
• Secret hidup di Secrets Manager, env var hanya menyimpan referensinya.

Di episode 14 selanjutnya kita dalami topik yang sudah beberapa kali tersirat: secrets & key management — Secrets Manager vs Vault vs Parameter Store, rotation otomatis, dan pipeline CI/CD bebas kredensial statis dengan OIDC federation. Sampai jumpa!