View a markdown version of this page

Otentikasi bersama dengan TLS di Application Load Balancer - Elastic Load Balancing
Sebelum Anda mulaiHeader HTTPMengiklankan nama subjek CALog koneksi

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Otentikasi bersama dengan TLS di Application Load Balancer

Otentikasi Mutual TLS adalah variasi dari Transport Layer Security (TLS). TLS tradisional menetapkan komunikasi yang aman antara server dan klien, di mana server perlu memberikan identitasnya kepada kliennya. Dengan TLS bersama, penyeimbang beban menegosiasikan otentikasi timbal balik antara klien dan server sambil menegosiasikan TLS. Saat Anda menggunakan TLS bersama dengan Application Load Balancer, Anda menyederhanakan manajemen otentikasi dan mengurangi beban pada aplikasi Anda.

Dengan menggunakan TLS bersama, load balancer Anda dapat mengelola otentikasi klien untuk membantu memastikan bahwa hanya klien tepercaya yang berkomunikasi dengan aplikasi backend Anda. Saat Anda menggunakan fitur ini, load balancer akan mengotentikasi klien menggunakan sertifikat dari otoritas sertifikat pihak ketiga (CA) atau dengan menggunakan AWS Private Certificate Authority (PCA), secara opsional, dengan pemeriksaan pencabutan. Penyeimbang beban meneruskan informasi sertifikat klien ke backend menggunakan header HTTP, yang dapat digunakan aplikasi Anda untuk otorisasi.

Mutual TLS for Application Load Balancers menyediakan opsi berikut untuk memvalidasi sertifikat klien Anda: X.509v3

  • Mutual TLS passthrough: Penyeimbang beban mengirimkan seluruh rantai sertifikat klien ke target, tanpa memverifikasinya. Target harus memverifikasi rantai sertifikat klien. Kemudian, menggunakan rantai sertifikat klien, Anda dapat menerapkan otentikasi penyeimbang beban dan logika otorisasi target dalam aplikasi Anda.

  • Verifikasi TLS bersama: Penyeim bang beban melakukan otentikasi sertifikat X.509 klien untuk klien saat penyeimbang beban menegosiasikan koneksi TLS.

Untuk menggunakan passthrough TLS bersama, Anda harus mengonfigurasi pendengar untuk menerima sertifikat dari klien. Untuk menggunakan TLS bersama dengan verifikasi, lihatMengkonfigurasi TLS bersama pada Penyeimbang Beban Aplikasi.

Sebelum Anda mulai mengonfigurasi TLS bersama pada Application Load Balancer

Sebelum Anda mulai mengonfigurasi TLS bersama pada Application Load Balancer, perhatikan hal-hal berikut:

Kuota

Penyeimbang Beban Aplikasi menyertakan batasan tertentu yang terkait dengan jumlah penyimpanan kepercayaan, sertifikat CA, dan daftar pencabutan sertifikat yang digunakan dalam akun Anda AWS .

Untuk informasi selengkapnya, lihat Ku ota untuk Penyeimbang Beban Aplikasi Anda.

Persyaratan untuk sertifikat

Application Load Balancers mendukung berikut untuk sertifikat yang digunakan dengan otentikasi TLS bersama:

  • Sertifikat yang didukung: X.509v3

  • Kunci publik yang didukung: RSA 2K - 8K atau ECDSA secp256r1, secp384r1, secp521r1

  • Algoritma tanda tangan yang didukung: SHA256, 384, 512 dengan RSA/SHA256, 384, 512 dengan EC/SHA256 ,384,512 hash dengan MGF1 RSASSA-PSS

Bundel sertifikat CA

Berikut ini berlaku untuk bundel otoritas sertifikat (CA):

  • Application Load Balancers mengunggah setiap bundel sertifikat otoritas sertifikat (CA) sebagai batch. Application Load Balancer tidak mendukung pengunggahan sertifikat individual. Jika Anda perlu menambahkan sertifikat baru, Anda harus mengunggah file bundel sertifikat.

  • Untuk mengganti bundel sertifikat CA, gunakan ModifyTrustStore API.

Pesanan sertifikat untuk passthrough

Saat Anda menggunakan passthrough TLS bersama, Application Load Balancer menyisipkan header untuk menyajikan rantai sertifikat klien ke target backend. Urutan presentasi dimulai dengan sertifikat daun dan diakhiri dengan sertifikat root.

Dimulainya kembali sesi

Dimulainya kembali sesi tidak didukung saat menggunakan mode passthrough TLS bersama atau verifikasi dengan Penyeimbang Beban Aplikasi.

Header HTTP

Application Load Balancers menggunakan X-Amzn-Mtls header untuk mengirim informasi sertifikat saat menegosiasikan koneksi klien menggunakan TLS bersama. Untuk informasi lebih lanjut dan contoh header, lihatHeader HTTP dan TLS bersama.

Berkas sertifikat CA

File sertifikat CA harus memenuhi persyaratan berikut:

  • File sertifikat harus menggunakan format PEM (Privacy Enhanced Mail).

  • Isi sertifikat harus dilampirkan di dalam -----BEGIN CERTIFICATE----- dan -----END CERTIFICATE----- batas-batas.

  • Komentar harus didahului oleh # karakter dan tidak boleh mengandung - karakter apa pun.

  • Tidak boleh ada baris kosong.

Contoh sertifikat yang tidak diterima (tidak valid):

# comments

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 01
    Signature Algorithm: ecdsa-with-SHA384
        Issuer: C=US, O=EXAMPLE, OU=EXAMPLE, CN=EXAMPLE
        Validity
            Not Before: Jan 11 23:57:57 2024 GMT
            Not After : Jan 10 00:57:57 2029 GMT
        Subject: C=US, O=EXAMPLE, OU=EXAMPLE, CN=EXAMPLE
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (384 bit)
                pub: 
                    00:01:02:03:04:05:06:07:08
                ASN1 OID: secp384r1
                NIST CURVE: P-384
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment, Certificate Sign, CRL Sign
            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Subject Key Identifier: 
                00:01:02:03:04:05:06:07:08
            X509v3 Subject Alternative Name: 
                URI:EXAMPLE.COM
    Signature Algorithm: ecdsa-with-SHA384
         00:01:02:03:04:05:06:07:08
-----BEGIN CERTIFICATE-----
Base64–encoded certificate
-----END CERTIFICATE-----

Contoh sertifikat yang diterima (valid):

  1. Sertifikat tunggal (dikodekan PEM-):

    # comments
-----BEGIN CERTIFICATE-----
Base64–encoded certificate
-----END CERTIFICATE-----

  2. Beberapa sertifikat (dikodekan PEM-):

    # comments
-----BEGIN CERTIFICATE-----
Base64–encoded certificate
-----END CERTIFICATE-----
# comments
-----BEGIN CERTIFICATE-----
Base64–encoded certificate
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
Base64–encoded certificate
-----END CERTIFICATE-----

Header HTTP dan TLS bersama

Bagian ini menjelaskan header HTTP yang digunakan Application Load Balancers untuk mengirim informasi sertifikat saat menegosiasikan koneksi dengan klien menggunakan TLS bersama. Header X-Amzn-Mtls spesifik yang digunakan Application Load Balancer bergantung pada mode TLS bersama yang telah Anda tentukan: mode passthrough atau mode verifikasi.

Untuk informasi tentang header HTTP lain yang didukung oleh Application Load Balancers, lihat. Header HTTP dan Application Load Balancer

Header HTTP untuk mode passthrough

Untuk TLS bersama dalam mode passthrough, Application Load Balancers menggunakan header berikut.

Header ini berisi URL-encoded format PEM dari seluruh rantai sertifikat klien yang disajikan dalam koneksi, +=/ dengan karakter aman.

Contoh isi header: 

X-Amzn-Mtls-Clientcert: -----BEGIN%20CERTIFICATE-----%0AMIID<...reduced...>do0g%3D%3D%0A-----END%20CERTIFICATE-----%0A-----BEGIN%20CERTIFICATE-----%0AMIID1<...reduced...>3eZlyKA%3D%3D%0A-----END%20CERTIFICATE-----%0A

Header HTTP untuk mode verifikasi

Untuk TLS bersama dalam mode verifikasi, Penyeimbang Beban Aplikasi menggunakan header berikut.

Header ini berisi representasi heksadesimal dari nomor seri sertifikat daun.

Contoh isi header: 

X-Amzn-Mtls-Clientcert-Serial-Number: 03A5B1

Header ini berisi representasi string RFC2253 dari nama yang dibedakan penerbit (DN).

Contoh isi header: 

X-Amzn-Mtls-Clientcert-Issuer: CN=rootcamtls.com,OU=rootCA,O=mTLS,L=Seattle,ST=Washington,C=US

Header ini berisi representasi string RFC2253 dari nama subjek yang dibedakan (DN).

Contoh isi header: 

X-Amzn-Mtls-Clientcert-Subject: CN=client_.com,OU=client-3,O=mTLS,ST=Washington,C=US

Header ini berisi format ISO8601 dari tanggal notBefore dannotAfter.

Contoh isi header: 

X-Amzn-Mtls-Clientcert-Validity: NotBefore=2023-09-21T01:50:17Z;NotAfter=2024-09-20T01:50:17Z

Header ini berisi URL-encoded format PEM dari sertifikat daun, +=/ dengan karakter aman.

Contoh isi header: 

X-Amzn-Mtls-Clientcert-Leaf: -----BEGIN%20CERTIFICATE-----%0AMIIG<...reduced...>NmrUlw%0A-----END%20CERTIFICATE-----%0A

Nama subjek Advertising Certificate Authority (CA) meningkatkan proses otentikasi dengan membantu klien menentukan sertifikat mana yang akan diterima selama otentikasi TLS bersama.

Saat Anda mengaktifkan Iklan nama subjek CA, Penyeimbang Beban Aplikasi akan mengiklankan daftar nama subjek Otoritas Sertifikat (CA) yang dipercaya, berdasarkan penyimpanan kepercayaan yang terkait dengannya. Ketika klien terhubung ke target melalui Application Load Balancer, klien menerima daftar nama subjek CA tepercaya.

Selama jabat tangan TLS, ketika Application Load Balancer meminta sertifikat klien, aplikasi menyertakan daftar CA Distinguished Names (DN) tepercaya dalam pesan Permintaan Sertifikat. Ini membantu klien memilih sertifikat valid yang cocok dengan nama subjek CA yang diiklankan, merampingkan proses otentikasi dan mengurangi kesalahan koneksi.

Anda dapat mengaktifkan Iklan nama subjek CA pada pendengar baru dan yang sudah ada. Untuk informasi selengkapnya, lihat Menambahkan pendengar HTTPS.

Log koneksi untuk Penyeimbang Beban Aplikasi

Elastic Load Balancing menyediakan log koneksi yang menangkap atribut tentang permintaan yang dikirim ke Penyeimbang Beban Aplikasi Anda. Log koneksi berisi informasi seperti alamat IP klien dan port, informasi sertifikat klien, hasil koneksi, dan sandi TLS yang digunakan. Log koneksi ini kemudian dapat digunakan untuk meninjau pola permintaan, dan tren lainnya.

Untuk mempelajari lebih lanjut tentang log koneksi, lihat Log koneksi untuk Application Load Balancer