Belajar Cloud Security Engineer - Cloud Network Security

#Pendahuluan

Setelah di episode 3 kita mengunci identitas — users, roles, policies, dan least privilege — sekarang kita naik ke lapisan kedua: network. Identitas menentukan siapa boleh; network menentukan dari mana dan ke mana. Keduanya harus kuat, karena penyerang yang mencuri kredensial tetap butuh jalur jaringan untuk sampai ke target.

Mengapa network security cloud penting? Karena kesalahan konfigurasinya paling murah dibuat dan paling mahal akibatnya: satu security group 0.0.0.0/0 pada port manajemen sudah cukup untuk membuka seluruh fleet. Dan berbeda dengan datacenter fisik, di cloud kalian bisa mendesain ulang jaringan sepenuhnya lewat kode dalam hitungan jam.

#Desain VPC: Subnet Publik vs Privat

Fondasi segmentasi cloud adalah pemisahan subnet:

Prinsip desain yang benar: tidak ada workload tanpa alasan punya IP publik. Load balancer menerima trafik dari internet; semua instance di belakangnya tinggal di subnet privat tanpa public IP.

Diagram di atas adalah pola tiga tier klasik: hanya satu pintu masuk (ALB), app tier tidak bisa diakses langsung, database hanya menerima dari app tier, dan lalu lintas keluar melewati titik kontrol tunggal.

#Security Groups vs NACL

Dua mekanisme filter di AWS yang sering tertukar:

Aturan praktis: SG sebagai kontrol utama, NACL sebagai seat belt kasar (misal blok IP berbahaya secara eksplisit). Kekuatan sesungguhnya SG adalah kemampuannya mereferensi SG lain — aturan "boleh diakses oleh SG app-tier" membuat aturan firewall mengikuti dinamika autoscaling tanpa perlu tahu IP-nya.

Contoh Terraform dua SG yang saling merujuk:

resource "aws_security_group" "alb" {
  name   = "alb-sg"
  vpc_id = aws_vpc.main.id
 
  ingress {
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }
 
  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = [aws_subnet.app.cidr_block]
  }
}
 
resource "aws_security_group" "app" {
  name   = "app-sg"
  vpc_id = aws_vpc.main.id
 
  ingress {
    from_port       = 8080
    to_port         = 8080
    protocol        = "tcp"
    security_groups = [aws_security_group.alb.id]
  }
}

Baris security_groups = [...] adalah inti pola ini: app hanya bisa dijangkau oleh trafik yang datang dari ALB. Tidak ada CIDR yang perlu dipelihara saat instance scale up/down.

#Segmentasi Antar-Tier

Segmentasi menjawab pertanyaan: jika satu workload dikompromikan, seberapa jauh penyerang bisa bergerak? Prinsip-prinsipnya:

1. Deny by default antar-tier — database SG hanya menerima dari app SG pada port spesifik; tidak ada aturan broad seperti "seluruh VPC boleh ke port 5432".
2. Pisahkan environment — dev/staging/prod di VPC atau akun terpisah; insiden staging tidak boleh menyentuh prod.
3. Microsegmentasi untuk data tier — Redis, Kafka, dan message queue juga layak perlakuan database: port terbuka seminimal mungkin.
4. Administrasi via SSM, bukan SSH publik — episode 5 akan membahas ini; artinya port 22 bahkan tidak perlu dibuka sama sekali.

#Egress Control

Mayoritas engineer rajin mengatur inbound tapi melupakan outbound. Padahal egress adalah jalur exfiltrasi data dan C2 (command and control). Pola egress control yang pragmatis:

• Default deny egress untuk workload yang tidak butuh internet; allowlist tujuan spesifik (repo paket internal, API mitra).
• Egress proxy/NAT dengan logging untuk workload yang butuh internet — setiap tujuan dicatat dan bisa diaudit.
• VPC endpoints/PrivateLink untuk service cloud itu sendiri (S3, DynamoDB) sehingga trafik tidak keluar lewat internet sama sekali.

Contoh SG dengan egress ketat:

resource "aws_security_group" "worker" {
  name   = "worker-sg"
  vpc_id = aws_vpc.main.id
 
  ingress {
    from_port       = 0
    to_port         = 0
    protocol        = "-1"
    security_groups = [aws_security_group.alb.id]
  }
 
  egress {
    from_port       = 443
    to_port         = 443
    protocol        = "tcp"
    security_groups = [aws_security_group.egress_proxy.id]
  }
}

Kombinasi endpoint policy pada VPC endpoint S3 juga layak dipakai: meski kredensial bocor, akses dibatasi hanya ke bucket tertentu.

#Private Connectivity

Tiga komponen yang wajib kalian kenal:

• VPC Endpoint (Gateway) — routing ke S3/DynamoDB tanpa internet; gratis, hanya butuh route table entry.
• PrivateLink / Interface Endpoint — expose service privat via ENI dengan IP internal; fondasi arsitektur multi-VPC yang aman.
• Private DNS — memaksa SDK aplikasi tetap resolve ke endpoint privat, mencegah trafik "nyasar" ke internet karena konfigurasi default.

aws ec2 create-vpc-endpoint \
  --vpc-id vpc-0abc123 \
  --vpc-endpoint-type Interface \
  --service-name com.amazonaws.ap-southeast-1.secretsmanager \
  --subnet-ids subnet-0a1b2c3d \
  --security-group-ids sg-secretsclient

Setelah endpoint ini aktif, GetSecretValue dari dalam VPC tidak lagi memerlukan NAT Gateway maupun internet — permukaan serangan menyusut sekaligus biaya turun.

#Common Pitfalls

• 0.0.0.0/0 pada port manajemen (22, 3389) — klasik nomor satu di setiap CSPM report.
• NAT Gateway sebagai "egress control" palsu — NAT memberi akses internet penuh, hanya menyembunyikan IP sumber; bukan kontrol keamanan.
• Lupa NACL ephemeral ports — memblokir return traffic dan membuat debugging panjang.
• Security group "satu untuk semua" — SG raksasa yang dibuka ke seluruh VPC menghilangkan nilai segmentasi.

#Penutup

Inti yang harus dibawa pulang:

• Segmentasi dimulai dari desain subnet: publik hanya untuk entry point, sisanya privat.
• SG stateful mereferensi SG lain sebagai kontrol utama; NACL sekadar seat belt.
• Egress adalah jalur exfiltrasi — default deny, allowlist, dan VPC endpoints.
• Private connectivity (endpoint/PrivateLink) menghilangkan kebutuhan internet untuk trafik internal.

Di episode 5 selanjutnya kita masuk ke workload security — hardening compute (EC2/VM), golden image, IMDSv2 untuk melindungi metadata, dan mengapa SSRF ke metadata service pernah menghasilkan salah satu breach terbesar sejarah. Sampai jumpa!