Public vs Private Network #

Salah satu keputusan desain paling fundamental ketika kita merancang arsitektur infrastruktur di cloud adalah menentukan tingkat aksesibilitas dari setiap resource komputasi yang kita deploy: apakah suatu komponen perlu dapat dihubungkan secara langsung dari internet publik, atau cukup diakses dari dalam jaringan internal VPC saja? Jawabannya menentukan apakah resource tersebut berada di Public Network (Public Subnet) atau Private Network (Private Subnet). Pemisahan ini berdampak langsung pada postur keamanan (security posture) keseluruhan sistem kita. Sebagai aturan baku dalam dunia rekayasa keamanan, kita wajib menerapkan prinsip paparan minimal: ekspos sesedikit mungkin komponen ke internet publik, dan lindungi sebanyak mungkin resource di belakang private network yang terisolasi.

Perbedaan Mendasar: Public vs Private Subnet #

Perbedaan utama antara public dan private subnet tidak terletak pada karakteristik fisik hardware server, melainkan pada konfigurasi perutean tabel routing jaringan virtual (Route Table) yang diasosiasikan pada subnet tersebut.

Berikut adalah tabel komparasi detail karakteristik operasional antara Public Network dan Private Network di cloud:

Di Balik Layar: Bagaimana Cloud Provider Mengisolasi Jaringan Kita? #

Di dalam pusat data fisik milik cloud provider, ribuan server hypervisor terhubung dalam satu jaringan fisik raksasa yang sama. Namun, sebagai pelanggan cloud, kita mendapatkan jaminan bahwa jaringan kita terisolasi penuh secara logis. Bagaimana hal ini bekerja?

Cloud provider menggunakan teknologi Software-Defined Networking (SDN) dan Overlay Network. Protokol enkapsulasi seperti Geneve atau VXLAN digunakan untuk membungkus (encapsulate) lalu lintas data kita:

1. Enkapsulasi Paket: Ketika VM kita mengirimkan paket data, hypervisor host menangkap paket tersebut dan membungkusnya ke dalam paket UDP fisik.
2. Metadata Jaringan: Hypervisor menyisipkan metadata khusus berupa ID Pelanggan (Tenant ID) atau ID VPC ke dalam header paket pembungkus tersebut.
3. Database Pemetaan (Mapping Database): Hypervisor berkonsultasi dengan database kontrol terpusat cloud provider untuk menemukan alamat IP fisik server host tempat VM tujuan berada, lalu mengirimkan paket tersebut melewati jaringan fisik data center secara aman.
4. Dekapsulasi: Setibanya di server host tujuan, hypervisor pembaca akan melepas bungkus paket UDP fisik tersebut, memverifikasi ID VPC-nya, dan meneruskan paket ethernet asli ke VM tujuan.

Di sisi lain, proses penerjemahan IP publik dinamis juga terjadi di tingkat infrastruktur. Instans VM kita sebenarnya tidak pernah mengetahui alamat IP publiknya sendiri. Sistem operasi di dalam VM hanya melihat alamat IP privatnya. Ketika paket data dikirim ke luar, Internet Gateway (IGW) yang bertindak melakukan 1:1 NAT (Network Address Translation) dinamis untuk memetakan IP privat kita ke IP publik luar secara instan di level perbatasan jaringan (network edge).

Jenis-Jenis Alamat IP di Cloud #

Untuk memahami bagaimana aksesibilitas jaringan dikendalikan, kita harus membedakan karakteristik jenis-jenis alamat IP yang digunakan di lingkungan cloud:

1. IP Privat (Private IP Address) #

IP privat adalah alamat IP internal yang dialokasikan secara otomatis untuk setiap resource di dalam subnet. Alamat ini diambil dari rentang CIDR block subnet tempat resource tersebut berjalan (sesuai standar RFC 1918). IP privat digunakan untuk komunikasi internal antar-resource di dalam VPC yang sama. IP privat tidak dapat dikenali atau dirutekan di jaringan internet publik.

2. IP Publik Dinamis (Dynamic Public IP Address) #

IP publik dinamis adalah alamat IP publik sementara yang dipinjamkan oleh pool cloud provider kepada instans VM kita. IP ini memungkinkan VM untuk berkomunikasi dengan internet luar.

• Sifat Ephemeral: IP publik dinamis bersifat tidak permanen. Jika kita melakukan operasi stop pada instans VM dan kemudian menyalakannya kembali (start), alamat IP publik tersebut akan dilepaskan kembali ke pool cloud provider dan instans kita akan mendapatkan alamat IP publik baru yang berbeda.

3. Elastic IP / Static IP Address #

Elastic IP (di AWS) atau Static IP adalah alamat IP publik permanen yang dialokasikan khusus untuk akun cloud kita.

• Kelebihan: Alamat IP ini tidak akan berubah meskipun instans VM kita dimatikan, dihapus, atau diganti. Kita dapat mengaitkan (associate) Elastic IP ini ke instans baru sewaktu-waktu.
• Skenario Ideal: Sangat penting digunakan untuk endpoint yang alamat IP-nya tidak boleh berubah — seperti untuk konfigurasi DNS record, whitelist firewall pada API partner pihak ketiga, atau NAT Gateway outbound IP.
• Aturan Biaya: Cloud provider biasanya menerapkan biaya sewa kecil untuk Elastic IP yang tidak dikaitkan dengan instans berjalan. Kebijakan ini diterapkan untuk mencegah penimbunan (hoarding) IP publik yang persediaannya semakin menipis di seluruh dunia.

Pola Arsitektur Keamanan: Defense in Depth (Pemisahan Tier) #

Dalam merancang keamanan jaringan cloud yang andal, kita menerapkan prinsip Defense in Depth (Pertahanan Berlapis). Kita membagi sistem menjadi tier-tier jaringan yang terpisah secara fisik dan logis. Dengan begitu, jika satu lapisan pertahanan berhasil ditembus oleh peretas, komponen inti sistem (seperti database) masih terlindungi dengan aman di lapisan terdalam.

flowchart TD
    Internet["Internet Publik"] --> PublicSubnet
    
    subgraph PublicSubnet["1. PUBLIC SUBNET (DMZ Layer)"]
        ALB["Application Load Balancer (ALB)<br>Port 443 Terbuka"]
    end
    
    ALB -->|"Hanya Teruskan Port 8080"| PrivateSubnet
    
    subgraph PrivateSubnet["2. PRIVATE SUBNET (App Layer)"]
        AppA["App Server A (Stateless)"]
        AppB["App Server B (Stateless)"]
    end
    
    PrivateSubnet -->|"Hanya Teruskan Port 5432"| DataSubnet
    
    subgraph DataSubnet["3. DATA SUBNET (Database Layer)"]
        DB["Database (RDS / NoSQL)<br>No Internet Route"]
    end

Penjelasan Mekanisme Pertahanan: #

1. DMZ (Demilitarized Zone) / Public Subnet: Hanya Load Balancer (ALB) yang terekspos ke internet luar untuk menerima lalu lintas SSL/TLS (Port 443). ALB bertindak sebagai tameng terdepan.
2. App Subnet (Private): Server aplikasi tidak memiliki IP publik. Server aplikasi hanya menerima koneksi HTTP dari Security Group milik Load Balancer pada port internal aplikasi (misal: 8080).
3. Database Subnet (Data): Database diletakkan di subnet paling dalam tanpa rute internet. Database hanya menerima koneksi TCP dari Security Group milik server aplikasi pada port database (misal: 5432). Peretas dari internet sama sekali tidak memiliki jalur jaringan fisik maupun logis untuk menyentuh database secara langsung.

Konektivitas Hibrida: Menghubungkan Jaringan Cloud ke Pusat Data Lokal #

Bagi korporasi berskala enterprise, cloud sering kali tidak berdiri sendiri. Kita membutuhkan konektivitas aman untuk menghubungkan private subnet di cloud dengan pusat data lokal (on-premise data center) atau kantor cabang perusahaan.

Ada dua metode utama untuk menghubungkan kedua lingkungan jaringan terisolasi ini:

1. Site-to-Site VPN (IPsec VPN) #

Site-to-Site VPN membangun terowongan terenkripsi (encrypted tunnel) menggunakan protokol IPsec di atas jalur internet publik untuk menghubungkan router lokal (Customer Gateway) dengan gateway cloud (Virtual Private Gateway).

flowchart LR
    OnPrem["Pusat Data Lokal<br>192.168.0.0/16"] <-->|"IPsec Tunnel (Internet Publik)"| VPC["Cloud Private Subnet<br>10.0.10.0/24"]

• Kelebihan: Biaya implementasi murah, proses setup sangat cepat (hitungan jam), dan didukung oleh hampir semua perangkat router fisik.
• Kekurangan: Latensi dan stabilitas koneksi bergantung sepenuhnya pada kondisi jaringan internet publik yang fluktuatif. Kecepatan bandwidth biasanya terbatasi di kisaran 1.25 Gbps per tunnel.

2. Dedicated Connection (AWS Direct Connect / GCP Dedicated Interconnect) #

Dedicated Connection menyewa jalur kabel serat optik fisik khusus (private leased line) dari penyedia telekomunikasi mitra untuk menghubungkan pusat data lokal kita secara langsung ke fasilitas cloud provider, sepenuhnya melewati jaringan internet publik.

• Kelebihan: Menyediakan performa latensi yang sangat konsisten, tingkat keamanan tertinggi, serta kapasitas bandwidth yang sangat besar (mulai dari 1 Gbps hingga 100 Gbps).
• Kekurangan: Biaya sewa bulanan sangat mahal dan membutuhkan waktu setup fisik yang lama (bisa berminggu-minggu hingga bulanan).

Akses Operasional ke Private Resource secara Aman #

Meskipun server aplikasi dan database kita terisolasi dengan aman di private subnet tanpa IP publik, tim developer dan administrator sistem kita tetap membutuhkan akses masuk untuk kebutuhan pemeliharaan (maintenance), debugging, atau migrasi skema data. Ada tiga metode standar industri untuk membuka jalur akses masuk ini tanpa mengorbankan keamanan:

1. Bastion Host (Jump Server) #

Bastion Host adalah instans VM khusus yang diletakkan di Public Subnet dan bertindak sebagai jembatan lompatan (jump server) bagi engineer untuk melakukan SSH/RDP ke server privat.

flowchart LR
    Engineer["Laptop Engineer"] -->|"1. SSH Port 22"| Bastion["Bastion Host<br>(Public Subnet)"]
    Bastion -->|"2. SSH Port 22"| PrivateServer["App Server / DB<br>(Private Subnet)"]

Praktik Pengerasan Keamanan Bastion Host:

• Batasi Security Group Bastion Host agar hanya menerima koneksi SSH dari IP publik kantor kita atau IP VPN rumah engineer (source IP whitelisting). Jangan buka ke 0.0.0.0/0.
• Nonaktifkan otentikasi berbasis password; wajib gunakan kunci kriptografi SSH Key.
• Gunakan metode SSH ProxyCommand (Tunneling) agar engineer tidak perlu menyimpan private key server produksi di dalam mesin Bastion Host itu sendiri.

2. Client-to-Site VPN #

Client VPN memungkinkan laptop engineer terhubung secara privat ke jaringan VPC melalui terowongan VPN terenkripsi (encrypted VPN tunnel).

• Kelebihan: Begitu VPN aktif, laptop engineer akan mendapatkan IP privat virtual dan dapat mengakses server privat di cloud secara langsung seolah-olah laptop tersebut terhubung kabel fisik di dalam data center. Akses ini jauh lebih natural, aman, dan mudah diaudit melalui sistem logging VPN terpusat.

3. Cloud-Native Session Manager (SSM / IAP) #

Ini adalah metode paling modern dan aman (Zero Open Ports). Cloud provider (seperti AWS Systems Manager Session Manager atau GCP Identity-Aware Proxy) menyediakan agen kecil yang berjalan di dalam OS Virtual Machine privat.

flowchart TD
    Engineer["Engineer CLI / Console"] -->|"HTTPS Request"| CloudControl["Cloud Control Plane (IAM)"]
    CloudControl -->|"Secure Tunnel"| SSMAgent["SSM Agent di VM Privat"]
    SSMAgent --> Shell["Akses Terminal Shell VM"]

• Mengapa ini yang terbaik?: Kita sama sekali tidak perlu membuka port SSH (Port 22) pada Security Group server kita. Seluruh lalu lintas data ditransfer melalui HTTPS aman via agen internal. Otentikasi dan otorisasi dikontrol sepenuhnya menggunakan kebijakan IAM (Identity and Access Management) cloud provider, lengkap dengan logging aktivitas keystroke terminal yang dapat diaudit di CloudWatch atau S3.

Contoh Kode: Pola Rantai Keamanan (Security Group Chaining) dengan Terraform #

Berikut adalah contoh deklarasi Terraform yang menunjukkan praktik terbaik keamanan jaringan: mendeploy Load Balancer di public subnet dan VM aplikasi di private subnet, menggunakan pola Security Group Chaining (Security Group instans VM hanya mengizinkan lalu lintas masuk yang bersumber dari Security Group Load Balancer):

# ✓ BENAR: Gunakan Security Group Chaining untuk mengunci akses ke server privat

# 1. Security Group untuk Load Balancer (Terbuka ke Internet)
resource "aws_security_group" "alb_sg" {
  name        = "alb-security-group"
  description = "Mengontrol trafik masuk dari internet ke ALB"
  vpc_id      = aws_vpc.main.id

  # Mengizinkan HTTPS masuk dari seluruh internet publik
  ingress {
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  # Mengizinkan keluar ke mana saja
  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

# 2. Security Group untuk Server Aplikasi (Terisolasi di Private Subnet)
resource "aws_security_group" "app_sg" {
  name        = "app-server-security-group"
  description = "Hanya menerima trafik dari Load Balancer"
  vpc_id      = aws_vpc.main.id

  # ✓ BENAR: Rantai SG - Hanya terima trafik masuk dari ALB SG, bukan dari CIDR block IP
  ingress {
    from_port       = 8080
    to_port         = 8080
    protocol        = "tcp"
    security_groups = [aws_security_group.alb_sg.id] # Hanya izinkan dari ALB
  }

  # Mengizinkan keluar (outbound) untuk patching via NAT Gateway
  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

Ringkasan #

• Public subnet terhubung langsung ke Internet Gateway, sedangkan private subnet tidak memiliki jalur masuk langsung dari luar.
• Terapkan arsitektur Defense in Depth dengan memisahkan sistem menjadi tier publik (Load Balancer), tier privat (App Server), dan tier data (Database).
• Gunakan Overlay Network dan SDN untuk mengisolasi traffic antar-pelanggan secara logis menggunakan tag ID enkapsulasi di level hypervisor.
• Gunakan Elastic IP untuk alamat IP publik statis yang permanen demi kebutuhan whitelisting pihak ketiga atau DNS record stabil.
• Pola Security Group Chaining mengunci akses server privat agar hanya dapat dihubungi melalui Load Balancer resmi, bukan dari jaringan luar bebas.
• Konektivitas Hibrida menghubungkan cloud dan on-premise — gunakan Site-to-Site VPN untuk alternatif murah, atau Dedicated Connection untuk performa terbaik.
• Akses operasional wajib menggunakan VPN atau Session Manager cloud-native, menghindari pembukaan port SSH (Port 22) ke internet publik.
• Database harus selalu diletakkan di private/data subnet tanpa IP publik untuk meminimalkan celah keamanan (attack surface).

← Sebelumnya: Subnet, CIDR, Routing   Berikutnya: NAT, Firewall, Security Group →