Terminasi SSL dan Sesi Lengket

Terminasi SSL/TLS berarti penyeimbang beban mendekripsi lalu lintas HTTPS yang masuk, memeriksa permintaan HTTP dalam bentuk teks biasa (untuk menentukan perutean), lalu secara opsional mengenkripsi ulang permintaan tersebut sebelum meneruskannya ke backend. Jika terminasi dilakukan pada ALB, server aplikasi Anda dapat menerima lalu lintas HTTP tanpa enkripsi dari penyeimbang beban, sehingga konfigurasi backend menjadi lebih sederhana.

Terminasi pada penyeimbang beban mengurangi beban CPU pada server aplikasi (tidak ada jabat tangan TLS untuk setiap koneksi), memungkinkan perutean berbasis konten (yang memerlukan pembacaan header HTTP), dan memusatkan pengelolaan sertifikat.

AWS Certificate Manager (ACM) menyediakan, mengelola, dan memperbarui sertifikat SSL/TLS tanpa biaya tambahan. ALB dan NLB terintegrasi langsung dengan ACM: Anda memilih sertifikat ACM dalam konfigurasi listener HTTPS, lalu penyeimbang beban menyajikannya kepada klien yang terhubung.

Sertifikat ACM diperbarui secara otomatis sebelum kedaluwarsa—tanpa pembaruan manual dan tanpa waktu henti akibat sertifikat kedaluwarsa. Untuk sertifikat publik, ACM memvalidasi kepemilikan domain melalui validasi DNS (rekaman CNAME di Route 53) atau validasi email. Untuk penggunaan internal, ACM Private CA dapat menerbitkan sertifikat privat.

SNI (Server Name Indication) adalah ekstensi TLS yang memungkinkan satu alamat IP (dan karena itu satu listener ALB atau NLB) menyajikan beberapa sertifikat TLS untuk nama domain yang berbeda. Klien menyertakan nama host yang hendak diaksesnya dalam pesan TLS ClientHello, lalu penyeimbang beban memilih sertifikat yang sesuai.

ALB mendukung SNI secara bawaan: Anda dapat memasang beberapa sertifikat ACM pada satu listener HTTPS. ALB secara otomatis memilih sertifikat yang tepat berdasarkan nama host SNI milik klien. Dengan demikian, Anda tidak memerlukan listener atau penyeimbang beban terpisah untuk setiap domain, sehingga hosting virtual dengan SSL dapat diterapkan sepenuhnya.

ALB dan NLB mendukung kebijakan keamanan SSL yang dapat dikonfigurasi untuk mengatur versi protokol TLS dan rangkaian cipher yang diterima penyeimbang beban dari klien. AWS menyediakan kebijakan bawaan (misalnya, ELBSecurityPolicy-TLS13-1-2-2021-06) yang diperbarui ketika kerentanan baru ditemukan.

Persyaratan kepatuhan dapat menentukan versi TLS tertentu: PCI-DSS 3.2.1 mensyaratkan minimal TLS 1.2; banyak standar modern merekomendasikan penonaktifan TLS 1.0 dan 1.1 sepenuhnya. Gunakan kebijakan yang mengecualikan protokol usang dan rangkaian cipher yang lemah. Utamakan kebijakan yang menyertakan TLS 1.3 untuk kerahasiaan berkelanjutan dan kinerja.

Dua pendekatan TLS yang berbeda pada ALB:

• Terminasi SSL (paling umum): ALB mendekripsi di penyeimbang beban dan meneruskan HTTP biasa ke target. Sederhana, memungkinkan pemeriksaan untuk perutean, dan mengurangi penggunaan CPU server. Lalu lintas backend tidak terenkripsi di dalam VPC.
• TLS ujung ke ujung: ALB mendekripsi, lalu mengenkripsi ulang sebelum meneruskannya ke target (HTTPS antara ALB dan target). Pendekatan ini memerlukan lebih banyak CPU dan sertifikat pada target, tetapi memastikan enkripsi di dalam VPC untuk skenario dengan kepatuhan ketat.

Dalam mode penerusan TLS NLB: NLB sama sekali tidak mendekripsi—NLB meneruskan TCP mentah ke target yang menangani TLS. Server aplikasi mengelola sertifikatnya sendiri.

Sesi lekat (juga disebut afinitas sesi) memastikan bahwa semua permintaan dari klien yang sama secara konsisten dirutekan ke target yang sama dalam suatu grup target. Hal ini diperlukan untuk aplikasi berstatus yang menyimpan data sesi di memori server individual (bukan dalam cache bersama seperti ElastiCache).

Tanpa sesi lekat, penyeimbang beban tanpa status dapat mengirim permintaan 1 ke server A (yang menyimpan sesi) dan permintaan 2 ke server B (yang tidak memiliki data sesi), sehingga pengguna tampak telah keluar atau kehilangan isi keranjang. Sesi lekat mengikat klien ke target tertentu selama sesi berlangsung.

ALB mendukung dua jenis cookie sesi lekat:

• Kelekatan berbasis durasi (cookie yang dibuat LB): ALB membuat cookie bernama AWSALB (untuk ALB) dan menetapkan durasi kedaluwarsa. Cookie tersebut berisi referensi terenkripsi ke target. Klien mengirimkan cookie ini pada permintaan berikutnya.
• Kelekatan berbasis aplikasi: menggunakan cookie yang sudah ditetapkan oleh aplikasi Anda. ALB membaca nama cookie yang Anda tentukan, membuat versi terenkripsi dalam cookienya sendiri, lalu menggunakannya untuk perutean lekat dengan tetap mempertahankan cookie aplikasi asli.

Konfigurasikan kelekatan untuk setiap grup target, dengan durasi mulai dari 1 detik hingga 7 hari.

Meskipun sesi lekat menyelesaikan masalah aplikasi berstatus, fitur ini memiliki beberapa konsekuensi:

• Distribusi beban tidak merata: beberapa target dapat menerima lebih banyak lalu lintas jika klien tertentu sangat aktif, sehingga tujuan penyeimbangan beban tidak tercapai
• Keterbatasan penskalaan: jika target yang lekat menjadi tidak sehat, sesi terputus—klien harus memulai sesi baru dengan target baru dan kehilangan data sesi dalam memori
• Elastisitas berkurang: sesi lekat menyulitkan pengosongan dan penghentian instans selama peristiwa pengurangan skala

Praktik terbaik: hilangkan kebutuhan akan sesi lekat dengan mengeksternalkan status sesi ke ElastiCache atau DynamoDB. Dengan demikian, aplikasi Anda benar-benar tanpa status dan dapat melakukan penskalaan horizontal secara penuh.

NLB mendukung listener TLS pada port 443 (atau port apa pun) untuk terminasi TLS, serupa dengan ALB. NLB mendekripsi lalu lintas, mengenkripsinya kembali secara opsional, lalu meneruskannya ke target. Sebagai alternatif, NLB dapat meneruskan langsung lalu lintas TCP terenkripsi tanpa mendekripsinya jika Anda mengonfigurasi listener TCP—dalam mode ini, server aplikasi menangani TLS dari ujung ke ujung.

Terminasi TLS NLB dengan ACM memberikan manfaat pengelolaan sertifikat yang sama seperti ALB, tetapi tanpa fitur pada lapisan HTTP. Gunakan terminasi TLS NLB jika Anda memerlukan IP statis dengan terminasi TLS atau jika protokol backend Anda bukan HTTP (misalnya, protokol TCP khusus).

Ketika target yang lekat dibatalkan pendaftarannya (misalnya, selama pengurangan skala Auto Scaling), pengosongan koneksi memungkinkan permintaan yang sedang berlangsung diselesaikan. Namun, permintaan baru dari klien lekat yang masih menyimpan cookie AWSALB untuk target yang sedang dikosongkan akan secara otomatis ditugaskan ke target baru—cookie kelekatan untuk klien tersebut dibatalkan.

Kombinasi penundaan pembatalan pendaftaran dan pembatalan cookie ini memastikan transisi yang baik: permintaan lama yang berlangsung lama dapat selesai, sementara permintaan baru dari klien tersebut dialihkan dengan lancar ke target yang sehat tanpa tampak sebagai kesalahan bagi pengguna akhir.

Praktik terbaik yang relevan untuk ujian:

• Gunakan sertifikat ACM untuk pembaruan otomatis—jangan pernah mengelola sertifikat secara manual pada penyeimbang beban
• Gunakan kebijakan keamanan TLS 1.2+; nonaktifkan TLS 1.0/1.1 untuk kepatuhan PCI/HIPAA
• Utamakan arsitektur tanpa status (sesi di ElastiCache/DynamoDB) daripada sesi lekat
• Gunakan SNI pada ALB untuk menyajikan beberapa domain dari satu listener tanpa memerlukan beberapa sertifikat pada penyeimbang beban terpisah
• Untuk kepatuhan ketat (data di dalam VPC harus terenkripsi): gunakan grup target HTTPS dengan TLS ujung ke ujung, bukan hanya terminasi pada penyeimbang beban

Uji pemahaman Anda tentang konsep AWS Solutions Architect (SAA-C03) dari pelajaran ini.

Dalam pelajaran ini Anda telah mempelajari bahwa: terminasi SSL/TLS ALB dengan sertifikat ACM menyediakan pembaruan otomatis dan SNI untuk beberapa domain, kebijakan keamanan SSL mengatur versi TLS dan rangkaian cipher untuk kepatuhan, dan sesi lekat merutekan pengguna ke target yang sama untuk aplikasi berstatus, tetapi sebaiknya digantikan dengan mengeksternalkan status sesi ke ElastiCache. Selanjutnya, kita akan membahas Grup Auto Scaling dan templat peluncuran.