Belajar Cloud Security Engineer - Workload Security

#Pendahuluan

Setelah di episode 4 kita membangun network yang tersegmentasi — SG granular, egress terkontrol, private endpoint — sekarang kita amankan penghuni jaringan itu sendiri: workload compute. Network yang sempurna tidak menolong apa-apa jika instance-nya menjalankan AMI basi dengan SSH terbuka dan metadata service versi rentan.

Mengapa workload security penting? Karena workload adalah titik akhir dari hampir semua rantai serangan cloud. Penyerang yang mendapat foothold di satu instance akan menemukan kredensial role di metadata service, membaca secret di disk, dan menggunakan instance itu sebagai pijakan. Setiap pengerasan di episode ini bertujuan membuat rantai tersebut putus sedini mungkin.

#Golden Image: Hardening Sejak Lahir

Jangan hardening instance satu per satu setelah launch — bangun golden image: template VM yang sudah dikeraskan, dipatch, dan diverifikasi, lalu regenerasi secara rutin.

Pipeline golden image modern:

Mulai dari base image resmi distro.
Terapkan baseline CIS via Ansible/Packer provisioning.
Scan hasilnya (misal OpenSCAP/Trivy), gagalkan build jika ada finding critical.
Publish sebagai AMI/image baru; ganti launch template otomatis.

Launch template memakai golden image terbaru

resource "aws_launch_template" "app" {
  name          = "app-golden"
  image_id      = var.golden_ami_id # output dari pipeline Packer+scan
  instance_type = "m7g.large"
 
  metadata_options {
    http_tokens                 = "required" # IMDSv2 only
    http_endpoint               = "enabled"
    http_put_response_hop_limit = 1
  }
 
  block_device_mappings {
    device_name = "/dev/xvda"
    ebs {
      encrypted   = true
      kms_key_id  = aws_kms_key.ebs.arn
      delete_on_termination = true
    }
  }
 
  iam_instance_profile { name = aws_iam_instance_profile.app.name }
}

Tiga atribut di template inilah inti hardening compute: image terverifikasi, metadata dilindungi, disk terenkripsi, dan identitas melekat lewat instance profile.

#IMDSv2: Pelajaran dari Breach Capital One

Instance Metadata Service (IMDS) menyediakan kredensial role ke instance di 169.254.169.254. Versi pertama (IMDSv1) berbasis GET biasa — artinya bug SSRF di aplikasi cukup untuk mencuri kredensial tanpa autentikasi. Breach Capital One 2019 (±100 juta data) bekerja persis lewat jalur ini: SSRF → IMDSv1 → kredensial role → exfiltrasi bucket.

IMDSv2 memutus rantai tersebut dengan token PUT + TTL: request metadata harus dimulai dengan HTTP PUT yang tidak akan pernah diteruskan oleh reverse proxy/CDN yang dikonfigurasi benar.

Uji IMDSv2 dari dalam instance

TOKEN=$(curl -sX PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")
curl -sH "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/iam/security-credentials/

Enforce lewat SCP agar seluruh organisasi tidak bisa meluncurkan instance tanpa IMDSv2:

scp-imdsv2-required.json

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "RequireImdsV2",
    "Effect": "Deny",
    "Action": "ec2:RunInstances",
    "Resource": "arn:aws:ec2:*:*:instance/*",
    "Condition": {
      "StringNotEquals": {"ec2:MetadataHttpTokens": "required"}
    }
  }]
}

Important

Set juga http_put_response_hop_limit = 1. Nilai lebih tinggi diperlukan hanya untuk kontainer yang butuh fetch metadata lewat bridge jaringan — dan itulah celah yang dipakai malware kontainer untuk mencuri kredensial host.

#Ganti SSH dengan Session Manager

SSH publik adalah permukaan serangan yang tidak perlu: key management, bastion, audit manual. AWS Systems Manager Session Manager memberi shell tanpa port terbuka sama sekali — trafik keluar lewat SSM agent, diaudit ke CloudTrail, dan bisa direkam penuh.

Yang dibutuhkan: IAM permission ssm:StartSession untuk manusia, dan instance profile dengan policy AmazonSSMManagedInstanceCore.

Policy operator: session hanya di akun produksi, MFA wajib

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": "ssm:StartSession",
    "Resource": [
      "arn:aws:ec2:ap-southeast-1:123456789012:instance/*",
      "arn:aws:ssm:ap-southeast-1::document/AWS-SessionManagerS3LoggingDisabled"
    ],
    "Condition": {"Bool": {"aws:MultiFactorAuthPresent": "true"}}
  }]
}

Hasil akhirnya: nol inbound rule SSH, nol key statis, dan setiap sesi tercatat siapa-mengapa-kapan.

#Patch Management dan Drift

Golden image menyelesaikan hardening awal, tetapi vulnerability baru lahir tiap minggu. Dua mekanisme pelengkap:

Patch baseline terkelola (AWS Patch Manager / Azure Update Manager): definisikan jadwal scan + install, prioritaskan CVE critical.
Drift detection: instance yang menyimpang dari golden path (package liar, agent mati) harus terdeteksi otomatis — bukan saat audit tahunan.

Cek compliance patch sebuah fleet

aws ssm describe-instance-patch-states \
  --instance-ids i-0abc i-0def \
  --query 'InstancePatchStates[].{Id:InstanceId,CriticalNonCompliant:CriticalNonCompliantCount}'

Angka non-compliant yang tidak turun setelah patch window adalah sinyal pipeline patch kalian bermasalah — periksa sebelum auditor yang menemukannya.

#Enkripsi Disk dan Data Sementara

Semua block storage harus terenkripsi (lihat template di atas), termasuk volume swap/temporary. Tambahkan dua kebiasaan:

Snapshot EBS ikut terenkripsi otomatis bila source-nya terenkripsi — snapshot plaintext adalah kebocoran data yang paling sering luput.
Instance store/ephemeral untuk data sensitif harus di-shred sebelum release, atau gunakan opsi delete_on_termination dan encryption-by-default di level region:

Aktifkan encryption by default untuk EBS di region

aws ec2 enable-ebs-encryption-by-default --region ap-southeast-1
aws ec2 get-ebs-default-kms-key-id --region ap-southeast-1

#Checklist Hardening Workload

Rangkuman praktik yang bisa langsung kalian terapkan:

Launch template memakai golden image hasil pipeline scan.
IMDSv2 required + hop limit 1, enforced via SCP.
EBS encrypted by default; snapshot ikut terenkripsi.
Akses administratif via Session Manager; port 22/3389 tertutup total.
Patch baseline terjadwal + laporan compliance mingguan.
Agent security (EDR/runtime) terpasang dan terpantau health-nya.

Tip

Jadikan checklist ini bagian dari module Terraform standar tim kalian — bukan dokumen yang dibaca sekali. Kontrol yang hidup di kode akan bertahan; kontrol yang hidup di wiki akan lapuk.

#Penutup

Inti yang harus dibawa pulang:

Hardening workload dimulai sebelum launch: golden image + launch template secure by default.
IMDSv2 dengan hop limit rendah memutus serangan SSRF→kredensial yang pernah menelan ratusan juta data.
Session Manager menggantikan SSH: tanpa port terbuka, dengan audit penuh.
Patch management dan drift detection menjaga hardening tetap relevan seiring waktu.

Di episode 6 selanjutnya kita turun ke aset yang paling berharga: data — enkripsi dengan KMS, envelope encryption, key management dan rotation, serta klasifikasi data yang menentukan mana yang layak proteksi maksimal. Sampai jumpa!