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

# Konfigurasikan akses aman dan batasi akses ke konten
<a name="SecurityAndPrivateContent"></a>

CloudFront menyediakan beberapa opsi untuk mengamankan konten yang dikirimkannya. Berikut ini adalah beberapa cara yang dapat Anda gunakan CloudFront untuk mengamankan dan membatasi akses ke konten:
+ Konfigurasi koneksi HTTPS
+ Cegah pengguna di lokasi geografis tertentu agar tidak mengakses konten
+ Mewajibkan pengguna untuk mengakses konten menggunakan cookie yang CloudFront ditandatangani URLs atau ditandatangani
+ Siapkan enkripsi tingkat lapangan untuk kolom konten khusus
+ Gunakan AWS WAF untuk mengontrol akses ke konten Anda

Anda juga harus menerapkan arsitektur DDo tangguh S untuk infrastruktur dan aplikasi Anda. Untuk informasi lebih lanjut, lihat [Praktik AWS Terbaik untuk Ketahanan DDo S](https://docs.aws.amazon.com/whitepapers/latest/aws-best-practices-ddos-resiliency/aws-best-practices-ddos-resiliency.html).

Untuk informasi tambahan, lihat hal berikut:
+ [Mengamankan pengiriman konten Anda dengan CloudFront](https://aws.amazon.com/cloudfront/security/)
+ [SIEM di Layanan Amazon OpenSearch ](https://github.com/aws-samples/siem-on-amazon-opensearch-service/blob/main/README.md)

**Topics**
+ [Gunakan HTTPS dengan CloudFront](using-https.md)
+ [Gunakan nama domain alternatif dan HTTPS](using-https-alternate-domain-names.md)
+ [Otentikasi TLS timbal balik dengan CloudFront (Viewer mTLS)](mtls-authentication.md)
+ [Asal TLS timbal balik dengan CloudFront](origin-mtls-authentication.md)
+ [Sajikan konten pribadi dengan cookie yang ditandatangani URLs dan ditandatangani](PrivateContent.md)
+ [Batasi akses ke asal AWS](private-content-restricting-access-to-origin.md)
+ [Batasi akses ke Application Load Balancers](restrict-access-to-load-balancer.md)
+ [Batasi distribusi geografis konten Anda](georestrictions.md)
+ [Gunakan enkripsi tingkat lapangan untuk membantu melindungi data sensitif](field-level-encryption.md)

# Gunakan HTTPS dengan CloudFront
<a name="using-https"></a>

Anda dapat mengonfigurasi CloudFront agar pemirsa menggunakan HTTPS sehingga koneksi dienkripsi saat CloudFront berkomunikasi dengan pemirsa. Anda juga dapat mengonfigurasi CloudFront untuk menggunakan HTTPS dengan asal Anda sehingga koneksi dienkripsi saat CloudFront berkomunikasi dengan asal Anda.

Jika Anda mengonfigurasi CloudFront untuk mewajibkan HTTPS baik untuk berkomunikasi dengan pemirsa maupun untuk berkomunikasi dengan asal Anda, inilah yang terjadi saat CloudFront menerima permintaan:

1. Penampil mengirimkan permintaan HTTPS ke CloudFront. Ada beberapa SSL/TLS negosiasi di sini antara pemirsa dan CloudFront. Pada akhirnya, penampil mengajukan permintaan dalam format terenkripsi.

1. Jika lokasi CloudFront tepi berisi respons yang di-cache, CloudFront mengenkripsi respons dan mengembalikannya ke penampil, dan penampil mendekripsi.

1. Jika lokasi CloudFront edge tidak berisi respons cache, CloudFront lakukan negosiasi SSL/TLS dengan asal Anda dan, ketika negosiasi selesai, teruskan permintaan ke asal Anda dalam format terenkripsi.

1. Asal Anda mendekripsi permintaan, memprosesnya (menghasilkan respons), mengenkripsi respons, dan mengembalikan respons ke. CloudFront

1. CloudFront mendekripsi respons, mengenkripsi ulang, dan meneruskannya ke pemirsa. CloudFrontjuga menyimpan respons di lokasi tepi sehingga tersedia saat diminta berikutnya.

1. Penampil akan mendekripsi respons.

Proses ini bekerja pada dasarnya dengan cara yang sama apakah asal Anda adalah bucket Amazon S3 MediaStore, atau custom origin seperti server HTTP/S.

**catatan**  
Untuk membantu menggagalkan serangan tipe negosiasi ulang SSL, CloudFront tidak mendukung negosiasi ulang untuk permintaan penampil dan asal.

Atau, Anda dapat mengaktifkan otentikasi timbal balik untuk CloudFront distribusi Anda. Untuk informasi selengkapnya, lihat [Otentikasi TLS timbal balik dengan CloudFront (Viewer mTLS)Asal TLS timbal balik dengan CloudFront](mtls-authentication.md).

Untuk informasi tentang cara mewajibkan HTTPS antara pemirsa dan CloudFront, CloudFront dan antara dan asal Anda, lihat topik berikut.

**Topics**
+ [Memerlukan HTTPS antara pemirsa dan CloudFront](using-https-viewers-to-cloudfront.md)
+ [Memerlukan HTTPS ke custom origin](using-https-cloudfront-to-custom-origin.md)
+ [Memerlukan HTTPS ke asal Amazon S3](using-https-cloudfront-to-s3-origin.md)
+ [Protokol dan sandi yang didukung antara pemirsa dan CloudFront](secure-connections-supported-viewer-protocols-ciphers.md)
+ [Protokol dan cipher yang didukung antara dan asal CloudFront](secure-connections-supported-ciphers-cloudfront-to-origin.md)

# Memerlukan HTTPS untuk komunikasi antara pemirsa dan CloudFront
<a name="using-https-viewers-to-cloudfront"></a>

Anda dapat mengonfigurasi satu atau beberapa perilaku cache dalam CloudFront distribusi Anda agar memerlukan HTTPS untuk komunikasi antara pemirsa dan CloudFront. Anda juga dapat mengonfigurasi satu atau lebih perilaku cache untuk memungkinkan HTTP dan HTTPS, sehingga CloudFront memerlukan HTTPS untuk beberapa objek tetapi tidak untuk yang lain. Langkah-langkah konfigurasi tergantung pada nama domain yang Anda gunakan di objek URLs:
+ Jika Anda menggunakan nama domain yang CloudFront ditetapkan ke distribusi Anda, seperti d111111abcdef8.cloudfront.net, Anda mengubah setelan **Kebijakan Protokol Penampil** untuk satu atau beberapa perilaku cache agar memerlukan komunikasi HTTPS. Dalam konfigurasi itu, CloudFront berikan SSL/TLS sertifikat. 

  Untuk mengubah nilai **Kebijakan Protokol Penampil** dengan menggunakan CloudFront konsol, lihat prosedurnya nanti di bagian ini.

  Untuk informasi tentang cara menggunakan CloudFront API untuk mengubah nilai `ViewerProtocolPolicy` elemen, lihat [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html)di *Referensi Amazon CloudFront API*.
+ Jika Anda menggunakan nama domain Anda sendiri, seperti contoh.com, Anda perlu mengubah beberapa CloudFront pengaturan. Anda juga perlu menggunakan SSL/TLS sertifikat yang disediakan oleh AWS Certificate Manager (ACM), atau mengimpor sertifikat dari otoritas sertifikat pihak ketiga ke ACM atau toko sertifikat IAM. Untuk informasi selengkapnya, lihat [Gunakan nama domain alternatif dan HTTPS](using-https-alternate-domain-names.md).

**catatan**  
Jika Anda ingin memastikan bahwa objek yang didapat pemirsa CloudFront dienkripsi saat CloudFront mendapatkannya dari asal Anda, selalu gunakan HTTPS antara CloudFront dan asal Anda. Jika Anda baru saja mengubah dari HTTP ke HTTPS antara CloudFront dan asal Anda, kami sarankan Anda membatalkan objek di lokasi CloudFront tepi. CloudFront akan mengembalikan objek ke penampil terlepas dari apakah protokol yang digunakan oleh penampil (HTTP atau HTTPS) cocok dengan protokol yang CloudFront digunakan untuk mendapatkan objek. Untuk informasi lebih lanjut tentang menghapus atau mengganti objek dalam distribusi, lihat [Menambahkan, menghapus, atau mengganti konten yang CloudFront mendistribusikan](AddRemoveReplaceObjects.md).

## Memerlukan HTTPS untuk pemirsa
<a name="configure-cloudfront-HTTPS-viewers"></a>

Untuk mewajibkan HTTPS antara CloudFront pemirsa dan untuk satu atau beberapa perilaku cache, lakukan prosedur berikut.<a name="using-https-viewers-to-cloudfront-procedure"></a>

**Untuk mengonfigurasi CloudFront agar memerlukan HTTPS antara pemirsa dan CloudFront**

1. Masuk ke Konsol Manajemen AWS dan buka CloudFront konsol di[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Di panel atas CloudFront konsol, pilih ID untuk distribusi yang ingin Anda perbarui.

1. Pada tab **Perilaku**, pilih perilaku cache yang ingin Anda perbarui, lalu pilih **Edit**.

1. Tentukan salah satu nilai berikut untuk **kebijakan protokol Viewer**:  
**Arahkan ulang HTTP ke HTTPS**  
Penampil dapat menggunakan kedua protokol. HTTP `GET` dan `HEAD` permintaan secara otomatis dialihkan ke permintaan HTTPS. CloudFront mengembalikan kode status HTTP 301 (Dipindahkan Secara Permanen) bersama dengan URL HTTPS baru. Penampil kemudian mengirimkan kembali permintaan untuk CloudFront menggunakan URL HTTPS.  
Jika Anda mengirim`POST`,`PUT`,`DELETE`,`OPTIONS`, atau `PATCH` melalui HTTP dengan perilaku cache HTTP ke HTTPS dan versi protokol permintaan HTTP 1.1 atau lebih tinggi, CloudFront mengalihkan permintaan ke lokasi HTTPS dengan kode status HTTP 307 (Pengalihan Sementara). Ini menjamin bahwa permintaan dikirim kembali ke lokasi baru menggunakan metode dan muatan tubuh yang sama.  
Jika Anda mengirim`POST`,`PUT`,`DELETE`,`OPTIONS`, atau `PATCH` permintaan melalui HTTP ke perilaku cache HTTPS dengan versi protokol permintaan di bawah HTTP 1.1, CloudFront mengembalikan kode status HTTP 403 (Terlarang).
Saat penampil membuat permintaan HTTP yang diarahkan ke permintaan HTTPS, CloudFront biaya untuk kedua permintaan. Untuk permintaan HTTP, biaya hanya untuk permintaan dan untuk header yang CloudFront kembali ke penampil. Untuk permintaan HTTPS, biaya adalah untuk permintaan, dan untuk header dan objek yang dikembalikan oleh asal Anda.  
**HTTPS saja**  
Penampil dapat mengakses konten Anda hanya jika mereka menggunakan HTTPS. Jika penampil mengirim permintaan HTTP alih-alih permintaan HTTPS, CloudFront mengembalikan kode status HTTP 403 (Terlarang) dan tidak mengembalikan objek.

1. Pilih **Simpan perubahan**.

1. Ulangi langkah 3 hingga 5 untuk setiap perilaku cache tambahan yang ingin Anda perlukan HTTPS untuk antara pemirsa dan CloudFront.

1. Konfirmasikan hal berikut sebelum menggunakan konfigurasi yang diperbarui dalam lingkungan produksi:
   + Pola jalur dalam setiap perilaku cache hanya berlaku untuk permintaan yang ingin digunakan penampil dengan HTTPS.
   + Perilaku cache tercantum dalam urutan yang CloudFront ingin Anda evaluasi. Untuk informasi selengkapnya, lihat [Pola jalur](DownloadDistValuesCacheBehavior.md#DownloadDistValuesPathPattern).
   + Perilaku singgahan sedang mengarahkan permintaan ke asal-usul yang benar. 

# Memerlukan HTTPS untuk komunikasi antara CloudFront dan asal kustom Anda
<a name="using-https-cloudfront-to-custom-origin"></a>

Anda dapat meminta HTTPS untuk komunikasi antara CloudFront dan asal Anda.

**catatan**  
Jika asal Anda adalah bucket Amazon S3 yang dikonfigurasi sebagai titik akhir situs web, Anda tidak dapat mengonfigurasi CloudFront untuk menggunakan HTTPS dengan asal Anda karena Amazon S3 tidak mendukung HTTPS untuk titik akhir situs web.

Untuk meminta HTTPS antara CloudFront dan asal Anda, ikuti prosedur dalam topik ini untuk melakukan hal berikut:

1. Pada distribusi Anda, ubah pengaturan **Kebijakan Protokol Asal** untuk asal itu.

1. Instal SSL/TLS sertifikat di server asal Anda (ini tidak diperlukan saat Anda menggunakan asal Amazon S3 atau asal tertentu lainnya AWS ).

**Topics**
+ [Memerlukan HTTPS untuk asal kustom](#using-https-cloudfront-to-origin-distribution-setting)
+ [Instal SSL/TLS sertifikat pada asal kustom Anda](#using-https-cloudfront-to-origin-certificate)

## Memerlukan HTTPS untuk asal kustom
<a name="using-https-cloudfront-to-origin-distribution-setting"></a>

Prosedur berikut menjelaskan cara mengonfigurasi penggunaan HTTPS CloudFront untuk berkomunikasi dengan penyeimbang beban Elastic Load Balancing, instans Amazon EC2, atau custom origin lainnya. Untuk informasi tentang menggunakan CloudFront API untuk memperbarui distribusi, lihat [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html)di *Referensi CloudFront API Amazon*. <a name="using-https-cloudfront-to-custom-origin-procedure"></a>

**Untuk mengonfigurasi CloudFront agar memerlukan HTTPS antara CloudFront dan asal kustom Anda**

1. Masuk ke Konsol Manajemen AWS dan buka CloudFront konsol di[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Di panel atas CloudFront konsol, pilih ID untuk distribusi yang ingin Anda perbarui.

1. Pada tab **Perilaku**, pilih asal yang ingin Anda perbarui, lalu pilih **Edit**.

1. Perbarui pengaturan berikut:  
**Kebijakan Protokol Asal**  
Ubah **Kebijakan Protokol Asal** untuk asal yang berlaku dalam distribusi Anda:  
   + **Hanya HTTPS** — hanya CloudFront menggunakan HTTPS untuk berkomunikasi dengan custom origin Anda.
   + **Match Viewer** — CloudFront berkomunikasi dengan custom origin Anda menggunakan HTTP atau HTTPS, tergantung pada protokol permintaan viewer. Misalnya, jika Anda memilih **Penampil Pencocokan** untuk **Kebijakan Protokol Asal** dan penampil menggunakan HTTPS untuk meminta objek CloudFront, CloudFront juga menggunakan HTTPS untuk meneruskan permintaan ke asal Anda.

     Pilih **Penampil Kecocokan** hanya jika Anda menentukan **Arahkan ulang HTTP ke HTTPS** atau **HTTPS Saja** untuk **Kebijakan Protokol Penampil**.

     CloudFront cache objek hanya sekali meskipun pemirsa membuat permintaan menggunakan protokol HTTP dan HTTPS.  
**Protokol SSL Asal**  
Pilih **Protokol SSL Asal** untuk asal yang berlaku dalam distribusi Anda. SSLv3 Protokolnya kurang aman, jadi kami sarankan Anda memilih SSLv3 hanya jika asal Anda tidak mendukung TLSv1 atau lebih baru. TLSv1 Jabat tangan kompatibel dengan mundur dan maju SSLv3, tetapi TLSv1 .1 dan yang lebih baru tidak. Saat Anda memilih SSLv3, CloudFront *hanya* mengirim permintaan SSLv3 jabat tangan.

1. Pilih **Simpan perubahan**.

1. Ulangi langkah 3 hingga 5 untuk setiap asal tambahan yang ingin Anda perlukan HTTPS untuk antara CloudFront dan asal kustom Anda.

1. Konfirmasikan hal berikut sebelum menggunakan konfigurasi yang diperbarui dalam lingkungan produksi:
   + Pola jalur dalam setiap perilaku cache hanya berlaku untuk permintaan yang ingin digunakan penampil dengan HTTPS.
   + Perilaku cache tercantum dalam urutan yang CloudFront ingin Anda evaluasi. Untuk informasi selengkapnya, lihat [Pola jalur](DownloadDistValuesCacheBehavior.md#DownloadDistValuesPathPattern).
   + Perilaku singgahan sedang mengarahkan permintaan ke asal-usul perubahan **Kebijakan Protokol Asal** untuk. 

## Instal SSL/TLS sertifikat pada asal kustom Anda
<a name="using-https-cloudfront-to-origin-certificate"></a>

Anda dapat menggunakan SSL/TLS sertifikat dari sumber berikut di asal kustom Anda:
+ Jika asal Anda adalah penyeimbang beban Elastic Load Balancing, Anda bisa menggunakan sertifikat yang disediakan oleh AWS Certificate Manager (ACM). Anda juga dapat menggunakan sertifikat yang ditandatangani oleh otoritas sertifikat pihak ketiga tepercaya dan diimpor ke ACM.
+ Untuk asal selain penyeimbang beban Elastic Load Balancing, Anda harus menggunakan sertifikat yang ditandatangani oleh otoritas sertifikat pihak ketiga tepercaya (CA), misalnya, Comodo, atau Symantec. DigiCert

Sertifikat yang dikembalikan dari asal harus menyertakan salah satu nama domain berikut:
+ Nama domain di bidang **domain Origin asal** (`DomainName`bidang di CloudFront API).
+ Nama domain di `Host` header, jika perilaku cache dikonfigurasi untuk meneruskan `Host` header ke asal.

Saat CloudFront menggunakan HTTPS untuk berkomunikasi dengan asal Anda, CloudFront verifikasi bahwa sertifikat dikeluarkan oleh otoritas sertifikat tepercaya. CloudFront mendukung otoritas sertifikat yang sama seperti yang dilakukan Mozilla. Untuk daftar saat ini, lihat [Daftar Sertifikat CA yang Disertakan Mozilla](https://wiki.mozilla.org/CA/Included_Certificates). Anda tidak dapat menggunakan sertifikat yang ditandatangani sendiri untuk komunikasi HTTPS antara CloudFront dan asal Anda.

**penting**  
Jika server asal mengembalikan sertifikat kedaluwarsa, sertifikat yang tidak valid, atau sertifikat yang ditandatangani sendiri, atau jika server asal mengembalikan rantai sertifikat dalam urutan yang salah, lepaskan koneksi TCP, CloudFront mengembalikan kode status HTTP 502 (Bad Gateway) ke penampil, dan menyetel header ke. `X-Cache` `Error from cloudfront` Juga, jika rantai lengkap sertifikat, termasuk sertifikat perantara, tidak ada, lepaskan CloudFront koneksi TCP.

# Memerlukan HTTPS untuk komunikasi antara CloudFront dan asal Amazon S3 Anda
<a name="using-https-cloudfront-to-s3-origin"></a>

Jika asal Anda adalah bucket Amazon S3, opsi Anda untuk menggunakan HTTPS untuk komunikasi CloudFront bergantung pada cara Anda menggunakan bucket. Jika bucket Amazon S3 Anda dikonfigurasi sebagai titik akhir situs web, Anda tidak dapat mengonfigurasi CloudFront untuk menggunakan HTTPS untuk berkomunikasi dengan asal Anda karena Amazon S3 tidak mendukung koneksi HTTPS dalam konfigurasi tersebut.

Jika asal Anda adalah bucket Amazon S3 yang mendukung komunikasi HTTPS, CloudFront teruskan permintaan ke S3 dengan menggunakan protokol yang digunakan pemirsa untuk mengirimkan permintaan. Pengaturan default untuk [Protokol (hanya asal kustom)](DownloadDistValuesOrigin.md#DownloadDistValuesOriginProtocolPolicy) adalah **Penampil Kecocokan** dan tidak dapat diubah. Namun, jika Anda mengaktifkan kontrol akses asal (OAC) untuk asal Amazon S3 Anda, komunikasi yang digunakan CloudFront antara dan Amazon S3 tergantung pada pengaturan Anda. Untuk informasi selengkapnya, lihat [Buat kontrol akses asal baru](private-content-restricting-access-to-s3.md#create-oac-overview-s3).

**Jika Anda ingin meminta HTTPS untuk komunikasi antara CloudFront dan Amazon S3, Anda harus mengubah nilai **Kebijakan Protokol Penampil** untuk **Mengalihkan HTTP ke HTTPS atau HTTPS** Saja.** Prosedur nanti di bagian ini menjelaskan cara menggunakan CloudFront konsol untuk mengubah **Kebijakan Protokol Penampil**. Untuk informasi tentang penggunaan CloudFront API untuk memperbarui `ViewerProtocolPolicy` elemen untuk distribusi, lihat [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html)di *Referensi Amazon CloudFront API*. 

Saat Anda menggunakan HTTPS dengan bucket Amazon S3 yang mendukung komunikasi HTTPS, Amazon S3 menyediakan SSL/TLS sertifikat, jadi Anda tidak perlu melakukannya.

## Memerlukan HTTPS untuk asal Amazon S3
<a name="configure-cloudfront-HTTPS-S3-origin"></a>

Prosedur berikut menunjukkan kepada Anda cara mengonfigurasi CloudFront agar memerlukan HTTPS ke asal Amazon S3 Anda.<a name="using-https-cloudfront-to-s3-origin-procedure"></a>

**Untuk mengonfigurasi CloudFront agar memerlukan HTTPS ke Amazon S3 asal Anda**

1. Masuk ke Konsol Manajemen AWS dan buka CloudFront konsol di[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Di panel atas CloudFront konsol, pilih ID untuk distribusi yang ingin Anda perbarui.

1. Di **Perilaku** , pilih perilaku cache yang ingin Anda perbarui, lalu pilih **Edit**.

1. Tentukan salah satu nilai untuk **Kebijakan Protokol Penampil**:  
**Arahkan ulang HTTP ke HTTPS**  
Pemirsa dapat menggunakan kedua protokol, tetapi permintaan HTTP secara otomatis dialihkan ke permintaan HTTPS. CloudFront mengembalikan kode status HTTP 301 (Dipindahkan Secara Permanen) bersama dengan URL HTTPS baru. Penampil kemudian mengirimkan kembali permintaan untuk CloudFront menggunakan URL HTTPS.  
CloudFront tidak mengalihkan`DELETE`,,,`OPTIONS`, `PATCH``POST`, atau `PUT` permintaan dari HTTP ke HTTPS. Jika Anda mengonfigurasi perilaku cache untuk mengarahkan ulang ke HTTPS, CloudFront merespons HTTP,`DELETE`,,, `OPTIONS` `PATCH``POST`, atau `PUT` permintaan untuk perilaku cache tersebut dengan kode status HTTP 403 (Terlarang).
Saat penampil membuat permintaan HTTP yang diarahkan ke permintaan HTTPS, CloudFront biaya untuk kedua permintaan. Untuk permintaan HTTP, biaya hanya untuk permintaan dan untuk header yang CloudFront kembali ke penampil. Untuk permintaan HTTPS, biaya adalah untuk permintaan, dan untuk header dan objek yang dikembalikan oleh asal Anda.  
**HTTPS Saja**  
Penampil dapat mengakses konten Anda hanya jika mereka menggunakan HTTPS. Jika penampil mengirim permintaan HTTP alih-alih permintaan HTTPS, CloudFront mengembalikan kode status HTTP 403 (Terlarang) dan tidak mengembalikan objek.

1. Pilih **Ya, Edit**.

1. Ulangi langkah 3 hingga 5 untuk setiap perilaku cache tambahan yang ingin Anda perlukan HTTPS untuk antara pemirsa dan CloudFront, dan antara CloudFront dan S3.

1. Konfirmasikan hal berikut sebelum menggunakan konfigurasi yang diperbarui dalam lingkungan produksi:
   + Pola jalur dalam setiap perilaku cache hanya berlaku untuk permintaan yang ingin digunakan penampil dengan HTTPS.
   + Perilaku cache tercantum dalam urutan yang CloudFront ingin Anda evaluasi. Untuk informasi selengkapnya, lihat [Pola jalur](DownloadDistValuesCacheBehavior.md#DownloadDistValuesPathPattern).
   + Perilaku singgahan sedang mengarahkan permintaan ke asal-usul yang benar. 

# Protokol dan sandi yang didukung antara pemirsa dan CloudFront
<a name="secure-connections-supported-viewer-protocols-ciphers"></a>

Jika Anda [memerlukan HTTPS antara pemirsa dan CloudFront distribusi Anda](DownloadDistValuesCacheBehavior.md#DownloadDistValuesViewerProtocolPolicy), Anda harus memilih [kebijakan keamanan](DownloadDistValuesGeneral.md#DownloadDistValues-security-policy), yang menentukan pengaturan berikut:
+  SSL/TLS Protokol minimum yang CloudFront digunakan untuk berkomunikasi dengan pemirsa.
+ Cipher yang CloudFront dapat digunakan untuk mengenkripsi komunikasi dengan pemirsa.

Untuk memilih kebijakan keamanan, tentukan nilai yang berlaku untuk [Kebijakan keamanan ( SSL/TLS versi minimum)](DownloadDistValuesGeneral.md#DownloadDistValues-security-policy). Tabel berikut mencantumkan protokol dan cipher yang CloudFront dapat digunakan untuk setiap kebijakan keamanan.

Penampil harus mendukung setidaknya satu dari cipher yang didukung untuk membuat koneksi HTTPS dengan. CloudFront CloudFront memilih cipher dalam urutan yang terdaftar dari antara cipher yang didukung pemirsa. Lihat juga [Nama cipher OpenSSL, s2n, dan RFC](#secure-connections-openssl-rfc-cipher-names).


|  | Kebijakan keamanan |  | SSLv3 | TLSv1 | TLSv1\$12016 | TLSv1.1\$12016 | TLSv1.2\$12018 | TLSv1.2\$12019 | TLSv1.2\$12021 | TLSv1.2\$12025 | TLSv1.3\$12025 | 
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | 
|  SSL/TLS Protokol yang didukung | 
| TLSv1.3 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | 
| TLSv1.2 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |  | 
| TLSv1.1 | ♦ | ♦ | ♦ | ♦ |  |  |  |  |  | 
| TLSv1 | ♦ | ♦ | ♦ |  |  |  |  |  |  | 
| SSLv3 | ♦ |  |  |  |  |  |  |  |  | 
| Didukung TLSv1 .3 cipher | 
| TLS\$1AES\$1128\$1GCM\$1 SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | 
| TLS\$1AES\$1256\$1GCM\$1 SHA384 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | 
| TLS\$1 \$1 \$1 CHACHA20 POLY1305 SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |  | ♦ | 
| Cipher ECDSA yang didukung | 
| ECDHE-ECDSA- -GCM- AES128 SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |  | 
| ECDHE-ECDSA- - AES128 SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |  |  |  | 
| ECDHE-ECDSA- -SHA AES128 | ♦ | ♦ | ♦ | ♦ |  |  |  |  |  | 
| ECDHE-ECDSA- -GCM- AES256 SHA384 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |  | 
| ECDHE-ECDSA- - CHACHA20 POLY1305 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |  |  | 
| ECDHE-ECDSA- - AES256 SHA384 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |  |  |  | 
| ECDHE-ECDSA- -SHA AES256 | ♦ | ♦ | ♦ | ♦ |  |  |  |  |  | 
| Cipher RSA yang didukung | 
| ECDHE-RSA- -GCM- AES128 SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |  | 
| ECDHE-RSA- - AES128 SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |  |  |  | 
| ECDHE-RSA- -SHA AES128 | ♦ | ♦ | ♦ | ♦ |  |  |  |  |  | 
| ECDHE-RSA- -GCM- AES256 SHA384 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |  | 
| ECDHE-RSA- - CHACHA20 POLY1305 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |  |  | 
| ECDHE-RSA- - AES256 SHA384 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |  |  |  | 
| ECDHE-RSA- -SHA AES256 | ♦ | ♦ | ♦ | ♦ |  |  |  |  |  | 
| AES128-GCM- SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ |  |  |  |  | 
| AES256-GCM- SHA384 | ♦ | ♦ | ♦ | ♦ | ♦ |  |  |  |  | 
| AES128-SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ |  |  |  |  | 
| AES256-SHA | ♦ | ♦ | ♦ | ♦ |  |  |  |  |  | 
| AES128-SHA | ♦ | ♦ | ♦ | ♦ |  |  |  |  |  | 
| DES- CBC3 -SHA | ♦ | ♦ |  |  |  |  |  |  |  | 
| RC4-MD5 | ♦ |  |  |  |  |  |  |  |  | 

## Nama cipher OpenSSL, s2n, dan RFC
<a name="secure-connections-openssl-rfc-cipher-names"></a>

OpenSSL dan [s2n](https://github.com/awslabs/s2n) menggunakan nama lain untuk cipher selain penggunaan standar TLS ([RFC 2246](https://tools.ietf.org/html/rfc2246), [RFC 4346](https://tools.ietf.org/html/rfc4346), [RFC 5246](https://tools.ietf.org/html/rfc5246), dan [RFC 8446](https://tools.ietf.org/html/rfc8446)). Tabel berikut memetakan nama OpenSSL dan s2n ke nama RFC untuk cipher lain.

CloudFront mendukung pertukaran kunci klasik dan kuantum yang aman. Untuk pertukaran kunci klasik menggunakan kurva elips, CloudFront mendukung yang berikut:
+ `prime256v1`
+ `X25519`
+ `secp384r1`

Untuk pertukaran kunci yang aman kuantum, CloudFront mendukung yang berikut:
+ `X25519MLKEM768`
+ `SecP256r1MLKEM768`
**catatan**  
Pertukaran kunci aman kuantum hanya didukung dengan TLS 1.3. TLS 1.2 dan versi sebelumnya tidak mendukung pertukaran kunci kuantum yang aman.

  Untuk informasi selengkapnya, lihat topik berikut:
  + [Kriptografi Pasca-Kuantum](https://aws.amazon.com/security/post-quantum-cryptography/)
  + [Algoritma kriptografi dan Layanan AWS](https://docs.aws.amazon.com/prescriptive-guidance/latest/encryption-best-practices/aws-cryptography-services.html#algorithms)
  + [Pertukaran kunci hibrida di TLS 1.3](https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/)

Untuk informasi selengkapnya tentang persyaratan sertifikat CloudFront, lihat[Persyaratan untuk menggunakan SSL/TLS sertifikat dengan CloudFront](cnames-and-https-requirements.md).


| Nama cipher OpenSSL dan s2n | Nama cipher RFC | 
| --- | --- | 
| Didukung TLSv1 .3 cipher | 
| TLS\$1AES\$1128\$1GCM\$1 SHA256 | TLS\$1AES\$1128\$1GCM\$1 SHA256 | 
| TLS\$1AES\$1256\$1GCM\$1 SHA384 | TLS\$1AES\$1256\$1GCM\$1 SHA384 | 
| TLS\$1 \$1 \$1 CHACHA20 POLY1305 SHA256 | TLS\$1 \$1 \$1 CHACHA20 POLY1305 SHA256 | 
| Cipher ECDSA yang didukung | 
| ECDHE-ECDSA- -GCM- AES128 SHA256 | TLS\$1ECDHE\$1ECDSA\$1WITH\$1AES\$1128\$1GCM\$1 SHA256 | 
| ECDHE-ECDSA- - AES128 SHA256 | TLS\$1ECDHE\$1ECDSA\$1DENGAN\$1AES\$1128\$1CBC\$1 SHA256 | 
| ECDHE-ECDSA- -SHA AES128 | TLS\$1ECDHE\$1ECDSA\$1WITH\$1AES\$1128\$1CBC\$1SHA | 
| ECDHE-ECDSA- -GCM- AES256 SHA384 | TLS\$1ECDHE\$1ECDSA\$1WITH\$1AES\$1256\$1GCM\$1 SHA384 | 
| ECDHE-ECDSA- - CHACHA20 POLY1305 | TLS\$1ECDHE\$1ECDSA\$1DENGAN\$1 \$1 \$1 CHACHA20 POLY1305 SHA256 | 
| ECDHE-ECDSA- - AES256 SHA384 | TLS\$1ECDHE\$1ECDSA\$1DENGAN\$1AES\$1256\$1CBC\$1 SHA384 | 
| ECDHE-ECDSA- -SHA AES256 | TLS\$1ECDHE\$1ECDSA\$1WITH\$1AES\$1256\$1CBC\$1SHA | 
| Cipher RSA yang didukung | 
| ECDHE-RSA- -GCM- AES128 SHA256 | TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1128\$1GCM\$1 SHA256 | 
| ECDHE-RSA- - AES128 SHA256 | TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1128\$1CBC\$1 SHA256  | 
| ECDHE-RSA- -SHA AES128 | TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1128\$1CBC\$1SHA | 
| ECDHE-RSA- -GCM- AES256 SHA384 | TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1256\$1GCM\$1 SHA384  | 
| ECDHE-RSA- - CHACHA20 POLY1305 | TLS\$1ECDHE\$1RSA\$1DENGAN\$1 \$1 \$1 CHACHA20 POLY1305 SHA256 | 
| ECDHE-RSA- - AES256 SHA384 | TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1256\$1CBC\$1 SHA384  | 
| ECDHE-RSA- -SHA AES256 | TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1256\$1CBC\$1SHA | 
| AES128-GCM- SHA256 | TLS\$1RSA\$1WITH\$1AES\$1128\$1GCM\$1 SHA256 | 
| AES256-GCM- SHA384 | TLS\$1RSA\$1WITH\$1AES\$1256\$1GCM\$1 SHA384 | 
| AES128-SHA256 | TLS\$1RSA\$1WITH\$1AES\$1128\$1CBC\$1 SHA256 | 
| AES256-SHA | TLS\$1RSA\$1WITH\$1AES\$1256\$1CBC\$1SHA | 
| AES128-SHA | TLS\$1RSA\$1WITH\$1AES\$1128\$1CBC\$1SHA | 
| DES- CBC3 -SHA  | TLS\$1RSA\$1WITH\$13DES\$1EDE\$1CBC\$1SHA  | 
| RC4-MD5 | RC4TLS\$1RSA\$1DENGAN\$1 \$1128\$1 MD5 | 

## Skema tanda tangan yang didukung antara pemirsa dan CloudFront
<a name="secure-connections-viewer-signature-schemes"></a>

CloudFront mendukung skema tanda tangan berikut untuk koneksi antara pemirsa danCloudFront.


|  | Kebijakan keamanan | Skema tanda tangan | SSLv3 | TLSv1 | TLSv1\$12016 | TLSv1.1\$12016 | TLSv1.2\$12018 | TLSv1.2\$12019 |  TLSv1.2\$12021 | TLSv1.2\$12025 | TLSv1.3\$12025 | 
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | 
| TLS\$1SIGNATURE\$1SCHEME\$1RSA\$1PSS\$1PSS\$1 SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | 
| TLS\$1SIGNATURE\$1SCHEME\$1RSA\$1PSS\$1PSS\$1 SHA384 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | 
| TLS\$1SIGNATURE\$1SCHEME\$1RSA\$1PSS\$1PSS\$1 SHA512 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | 
| TLS\$1SIGNATURE\$1SCHEME\$1RSA\$1PSS\$1RSAE\$1 SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | 
| TLS\$1SIGNATURE\$1SCHEME\$1RSA\$1PSS\$1RSAE\$1 SHA384 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | 
| TLS\$1SIGNATURE\$1SCHEME\$1RSA\$1PSS\$1RSAE\$1 SHA512 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | 
| PKCS1TLS\$1SIGNATURE\$1SCHEME\$1RSA\$1 \$1 SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | 
| PKCS1TLS\$1SIGNATURE\$1SCHEME\$1RSA\$1 \$1 SHA384 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | 
| PKCS1TLS\$1SIGNATURE\$1SCHEME\$1RSA\$1 \$1 SHA512 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | 
| PKCS1TLS\$1SIGNATURE\$1SCHEME\$1RSA\$1 \$1 SHA224 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |  |  | 
| TLS\$1SIGNATURE\$1SCHEME\$1ECDSA\$1 SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | 
| TLS\$1SIGNATURE\$1SCHEME\$1ECDSA\$1 SHA384 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | 
| TLS\$1SIGNATURE\$1SCHEME\$1ECDSA\$1 SHA512 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | 
| TLS\$1SIGNATURE\$1SCHEME\$1ECDSA\$1 SHA224 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |  |  | 
| TLS\$1SIGNATURE\$1SCHEME\$1ECDSA\$1 R1\$1 SECP256 SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | 
| TLS\$1SIGNATURE\$1SCHEME\$1ECDSA\$1 R1\$1 SECP384 SHA384 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | 
| PKCS1TLS\$1SIGNATURE\$1SCHEME\$1RSA\$1 \$1 SHA1 | ♦ | ♦ | ♦ | ♦ |  |  |  |  |  | 
| TLS\$1SIGNATURE\$1SCHEME\$1ECDSA\$1 SHA1 | ♦ | ♦ | ♦ | ♦ |  |  |  |  |  | 

# Protokol dan cipher yang didukung antara dan asal CloudFront
<a name="secure-connections-supported-ciphers-cloudfront-to-origin"></a>

Jika Anda memilih untuk [meminta HTTPS antara CloudFront dan asal Anda](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-web-values-specify.html#DownloadDistValuesOriginProtocolPolicy), Anda dapat memutuskan [ SSL/TLS protokol mana yang memungkinkan](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-web-values-specify.html#DownloadDistValuesOriginSSLProtocols) koneksi aman, dan CloudFront dapat terhubung ke asal menggunakan salah satu sandi ECDSA atau RSA yang tercantum dalam tabel berikut. Asal Anda harus mendukung setidaknya satu dari cipher ini CloudFront untuk membuat koneksi HTTPS ke asal Anda.

OpenSSL dan [s2n](https://github.com/awslabs/s2n) menggunakan nama lain untuk cipher selain penggunaan standar TLS ([RFC 2246](https://tools.ietf.org/html/rfc2246), [RFC 4346](https://tools.ietf.org/html/rfc4346), [RFC 5246](https://tools.ietf.org/html/rfc5246), dan [RFC 8446](https://tools.ietf.org/html/rfc8446)). Tabel berikut mencakup nama OpenSSL dan s2n, dan nama RFC, untuk setiap cipher.

Untuk cipher dengan algoritma pertukaran kunci kurva elips, CloudFront mendukung kurva elips berikut:
+ primer256v1
+ secp384r1
+ X25519


| Nama cipher OpenSSL dan s2n | Nama cipher RFC | 
| --- | --- | 
| Cipher ECDSA yang didukung | 
| ECDHE-ECDSA- -GCM- AES256 SHA384 | TLS\$1ECDHE\$1ECDSA\$1WITH\$1AES\$1256\$1GCM\$1 SHA384 | 
| ECDHE-ECDSA- - AES256 SHA384 | TLS\$1ECDHE\$1ECDSA\$1DENGAN\$1AES\$1256\$1CBC\$1 SHA384 | 
| ECDHE-ECDSA- -SHA AES256 | TLS\$1ECDHE\$1ECDSA\$1WITH\$1AES\$1256\$1CBC\$1SHA | 
| ECDHE-ECDSA- -GCM- AES128 SHA256 | TLS\$1ECDHE\$1ECDSA\$1WITH\$1AES\$1128\$1GCM\$1 SHA256 | 
| ECDHE-ECDSA- - AES128 SHA256 | TLS\$1ECDHE\$1ECDSA\$1DENGAN\$1AES\$1128\$1CBC\$1 SHA256 | 
| ECDHE-ECDSA- -SHA AES128 | TLS\$1ECDHE\$1ECDSA\$1WITH\$1AES\$1128\$1CBC\$1SHA | 
| Cipher RSA yang didukung | 
| ECDHE-RSA- -GCM- AES256 SHA384 | TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1256\$1GCM\$1 SHA384 | 
| ECDHE-RSA- - AES256 SHA384 | TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1256\$1CBC\$1 SHA384 | 
| ECDHE-RSA- -SHA AES256 | TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1256\$1CBC\$1SHA | 
| ECDHE-RSA- -GCM- AES128 SHA256 | TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1128\$1GCM\$1 SHA256 | 
| ECDHE-RSA- - AES128 SHA256 | TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1128\$1CBC\$1 SHA256 | 
| ECDHE-RSA- -SHA AES128 | TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1128\$1CBC\$1SHA | 
| AES256-SHA | TLS\$1RSA\$1WITH\$1AES\$1256\$1CBC\$1SHA | 
| AES128-SHA | TLS\$1RSA\$1WITH\$1AES\$1128\$1CBC\$1SHA | 
| DES- CBC3 -SHA | TLS\$1RSA\$1WITH\$13DES\$1EDE\$1CBC\$1SHA | 
| RC4-MD5 | RC4TLS\$1RSA\$1DENGAN\$1 \$1128\$1 MD5 | 

**Skema tanda tangan yang didukung antara CloudFront dan asal**

CloudFront mendukung skema tanda tangan berikut untuk koneksi antara CloudFront dan asal.
+ PKCS1TLS\$1SIGNATURE\$1SCHEME\$1RSA\$1 \$1 SHA256
+ PKCS1TLS\$1SIGNATURE\$1SCHEME\$1RSA\$1 \$1 SHA384
+ PKCS1TLS\$1SIGNATURE\$1SCHEME\$1RSA\$1 \$1 SHA512
+ PKCS1TLS\$1SIGNATURE\$1SCHEME\$1RSA\$1 \$1 SHA224
+ TLS\$1SIGNATURE\$1SCHEME\$1ECDSA\$1 SHA256
+ TLS\$1SIGNATURE\$1SCHEME\$1ECDSA\$1 SHA384
+ TLS\$1SIGNATURE\$1SCHEME\$1ECDSA\$1 SHA512
+ TLS\$1SIGNATURE\$1SCHEME\$1ECDSA\$1 SHA224
+ PKCS1TLS\$1SIGNATURE\$1SCHEME\$1RSA\$1 \$1 SHA1
+ TLS\$1SIGNATURE\$1SCHEME\$1ECDSA\$1 SHA1

# Gunakan nama domain alternatif dan HTTPS
<a name="using-https-alternate-domain-names"></a>

Jika Anda ingin menggunakan nama domain Anda sendiri di URLs file Anda (misalnya,`https://www.example.com/image.jpg`) dan Anda ingin pemirsa menggunakan HTTPS, Anda harus menyelesaikan langkah-langkah dalam topik berikut. (Jika Anda menggunakan nama domain CloudFront distribusi default di URLs, misalnya`https://d111111abcdef8.cloudfront.net/image.jpg`, ikuti panduan dalam topik berikut:[Memerlukan HTTPS untuk komunikasi antara pemirsa dan CloudFront](using-https-viewers-to-cloudfront.md).)

**penting**  
Saat Anda menambahkan sertifikat ke distribusi Anda, CloudFront segera menyebarkan sertifikat ke semua lokasi tepinya. Saat lokasi tepi baru tersedia, CloudFront menyebarkan sertifikat ke lokasi tersebut juga. Anda tidak dapat membatasi lokasi tepi yang CloudFront menyebarkan sertifikat ke.

**Topics**
+ [Pilih cara CloudFront melayani permintaan HTTPS](cnames-https-dedicated-ip-or-sni.md)
+ [Persyaratan untuk menggunakan SSL/TLS sertifikat dengan CloudFront](cnames-and-https-requirements.md)
+ [Kuota tentang penggunaan SSL/TLS sertifikat dengan CloudFront (HTTPS antara pemirsa dan CloudFront hanya)](cnames-and-https-limits.md)
+ [Konfigurasikan nama domain alternatif dan HTTPS](cnames-and-https-procedures.md)
+ [Tentukan ukuran kunci publik dalam sertifikat SSL/TLS RSA](cnames-and-https-size-of-public-key.md)
+ [Tingkatkan kuota untuk sertifikat SSL/TLS](increasing-the-limit-for-ssl-tls-certificates.md)
+ [Putar SSL/TLS sertifikat](cnames-and-https-rotate-certificates.md)
+ [Kembalikan dari SSL/TLS sertifikat kustom ke sertifikat default CloudFront](cnames-and-https-revert-to-cf-certificate.md)
+ [Beralih dari SSL/TLS sertifikat khusus dengan alamat IP khusus ke SNI](cnames-and-https-switch-dedicated-to-sni.md)

# Pilih cara CloudFront melayani permintaan HTTPS
<a name="cnames-https-dedicated-ip-or-sni"></a>

Jika Anda ingin pemirsa menggunakan HTTPS dan menggunakan nama domain alternatif untuk file Anda, pilih salah satu opsi berikut untuk cara CloudFront melayani permintaan HTTPS:
+ Gunakan [Indikasi Nama Server (SNI) — Rekomendasi](https://en.wikipedia.org/wiki/Server_Name_Indication)
+ Gunakan alamat IP khusus di setiap lokasi tepi

Bagian ini menjelaskan cara kerja setiap opsi.

## Gunakan SNI untuk melayani permintaan HTTPS (berfungsi untuk sebagian besar klien)
<a name="cnames-https-sni"></a>

[Server Name Indication (SNI)](https://en.wikipedia.org/wiki/Server_Name_Indication) adalah ekstensi ke protokol TLS yang didukung oleh browser dan klien yang dirilis setelah 2010. Jika Anda mengonfigurasi CloudFront untuk melayani permintaan HTTPS menggunakan SNI, CloudFront kaitkan nama domain alternatif Anda dengan alamat IP untuk setiap lokasi tepi. Saat penampil mengirimkan permintaan HTTPS untuk konten Anda, DNS mengirimkan permintaan ke alamat IP untuk lokasi tepi yang benar. Alamat IP ke nama domain Anda ditentukan selama negosiasi SSL/TLS jabat tangan; alamat IP tidak didedikasikan untuk distribusi Anda.

 SSL/TLS Negosiasi terjadi di awal proses membangun koneksi HTTPS. Jika tidak CloudFront dapat segera menentukan domain mana permintaan itu, itu akan menghentikan koneksi. Saat penampil yang mendukung SNI mengirimkan permintaan HTTPS untuk konten Anda, inilah yang terjadi:

1. Penampil secara otomatis mendapatkan nama domain dari URL permintaan dan menambahkannya ke ekstensi SNI dari pesan halo klien TLS.

1. Saat CloudFront menerima halo klien TLS, ia menggunakan nama domain di ekstensi SNI untuk menemukan CloudFront distribusi yang cocok dan mengirimkan kembali sertifikat TLS terkait.

1. Penampil dan CloudFront melakukan SSL/TLS negosiasi.

1. CloudFront mengembalikan konten yang diminta ke pemirsa.

Untuk daftar terkini dari browser yang mendukung SNI, lihat entri Wikipedia [Indikasi Nama Server](https://en.wikipedia.org/wiki/Server_Name_Indication).

Jika Anda ingin menggunakan SNI tetapi beberapa browser pengguna tidak mendukung SNI, Anda memiliki beberapa opsi:
+ Konfigurasikan CloudFront untuk melayani permintaan HTTPS dengan menggunakan alamat IP khusus, bukan SNI. Untuk informasi selengkapnya, lihat [Gunakan alamat IP khusus untuk melayani permintaan HTTPS (berfungsi untuk semua klien)](#cnames-https-dedicated-ip).
+ Gunakan sertifikat CloudFront SSL/TLS alih-alih sertifikat khusus. Ini mengharuskan Anda menggunakan nama CloudFront domain untuk distribusi Anda di URLs file Anda, misalnya,`https://d111111abcdef8.cloudfront.net/logo.png`.

  Jika Anda menggunakan CloudFront sertifikat default, pemirsa harus mendukung protokol SSL TLSv1 atau yang lebih baru. CloudFront tidak mendukung SSLv3 dengan CloudFront sertifikat default.

  Anda juga harus mengubah SSL/TLS sertifikat yang CloudFront digunakan dari sertifikat kustom ke CloudFront sertifikat default:
  + Jika Anda belum menggunakan distribusi untuk mendistribusikan konten Anda, Anda dapat mengubah konfigurasinya. Untuk informasi selengkapnya, lihat [Perbarui distribusi](HowToUpdateDistribution.md).
  + Jika Anda telah menggunakan distribusi Anda untuk mendistribusikan konten Anda, Anda harus membuat CloudFront distribusi baru dan mengubah file Anda URLs untuk mengurangi atau menghilangkan jumlah waktu konten Anda tidak tersedia. Untuk informasi selengkapnya, lihat [Kembalikan dari SSL/TLS sertifikat kustom ke sertifikat default CloudFront](cnames-and-https-revert-to-cf-certificate.md).
+ Jika Anda dapat mengontrol browser yang digunakan pengguna, minta mereka meng-upgrade browser mereka ke browser yang mendukung SNI.
+ Gunakan HTTP alih-alih HTTPS.

## Gunakan alamat IP khusus untuk melayani permintaan HTTPS (berfungsi untuk semua klien)
<a name="cnames-https-dedicated-ip"></a>

Indikasi Nama Server (Ser Server Name Indication atau SNI) adalah salah satu cara untuk mengaitkan permintaan dengan domain. Cara lainnya adalah menggunakan alamat IP khusus. Jika Anda memiliki pengguna yang tidak dapat meng-upgrade ke browser atau klien yang dirilis setelah 2010, Anda dapat menggunakan alamat IP khusus untuk melayani permintaan HTTPS. Untuk daftar terkini dari browser yang mendukung SNI, lihat entri Wikipedia [Indikasi Nama Server](https://en.wikipedia.org/wiki/Server_Name_Indication). 

**penting**  
Jika Anda mengonfigurasi CloudFront untuk melayani permintaan HTTPS menggunakan alamat IP khusus, Anda dikenakan biaya bulanan tambahan. Biaya dimulai ketika Anda mengaitkan SSL/TLS sertifikat Anda dengan distribusi dan Anda mengaktifkan distribusi. Untuk informasi selengkapnya tentang CloudFront harga, lihat [ CloudFront Harga Amazon](https://aws.amazon.com/cloudfront/pricing). Selain itu, lihat [Using the Same Certificate for Multiple CloudFront Distributions](cnames-and-https-limits.md#cnames-and-https-same-certificate-multiple-distributions).

Saat Anda mengonfigurasi CloudFront untuk melayani permintaan HTTPS dengan menggunakan alamat IP khusus, CloudFront kaitkan sertifikat Anda dengan alamat IP khusus di setiap lokasi CloudFront tepi. Saat penampil mengirimkan permintaan HTTPS untuk konten Anda, inilah yang terjadi:

1. DNS mengarahkan permintaan ke alamat IP untuk distribusi Anda di lokasi edge yang berlaku.

1. Jika permintaan klien menyediakan ekstensi SNI dalam `ClientHello` pesan, CloudFront cari distribusi yang terkait dengan SNI tersebut.
   + Jika ada kecocokan, CloudFront tanggapi permintaan dengan sertifikat SSL/TLS.
   + Jika tidak ada kecocokan, CloudFront gunakan alamat IP sebagai gantinya untuk mengidentifikasi distribusi Anda dan untuk menentukan sertifikat SSL/TLS mana yang akan dikembalikan ke penampil.

1. Penampil dan CloudFront melakukan SSL/TLS negosiasi menggunakan sertifikat SSL/TLS Anda.

1. CloudFront mengembalikan konten yang diminta ke pemirsa.

Metode ini berfungsi untuk setiap permintaan HTTPS, terlepas dari browser atau penampil lain yang digunakan pengguna. 

**catatan**  
Dedicated IPs tidak statis IPs dan dapat berubah seiring waktu. Alamat IP yang dikembalikan untuk lokasi tepi dialokasikan secara dinamis dari rentang alamat IP dari daftar [server CloudFront tepi](LocationsOfEdgeServers.md).  
Rentang alamat IP untuk server CloudFront edge dapat berubah sewaktu-waktu. Untuk diberitahu tentang perubahan alamat IP, [berlangganan Perubahan Alamat IP AWS Publik melalui Amazon SNS](https://aws.amazon.com/blogs/aws/subscribe-to-aws-public-ip-address-changes-via-amazon-sns/).

## Meminta izin untuk menggunakan tiga atau lebih SSL/TLS sertifikat IP khusus
<a name="cnames-and-https-multiple-certificates"></a>

Jika Anda memerlukan izin untuk secara permanen mengaitkan tiga atau lebih sertifikat IP khusus SSL/TLS dengan CloudFront, lakukan prosedur berikut. Untuk detail lebih lanjut tentang permintaan HTTPS, lihat [Pilih cara CloudFront melayani permintaan HTTPS](#cnames-https-dedicated-ip-or-sni).

**catatan**  
Prosedur ini adalah untuk menggunakan tiga atau lebih sertifikat IP khusus di seluruh CloudFront distribusi Anda. Nilai default-nya adalah 2. Harap diingat bahwa Anda tidak dapat mengikat lebih dari satu sertifikat SSL ke distribusi.  
Anda hanya dapat mengaitkan satu SSL/TLS sertifikat ke CloudFront distribusi pada satu waktu. Jumlah ini untuk jumlah total sertifikat SSL IP khusus yang dapat Anda gunakan di semua CloudFront distribusi Anda.<a name="cnames-and-https-multiple-certificates-procedure"></a>

**Untuk meminta izin untuk menggunakan tiga atau lebih sertifikat dengan CloudFront distribusi**

1. Buka [Pusat Dukungan](https://console.aws.amazon.com/support/home?#/case/create?issueType=service-limit-increase&limitType=service-code-cloudfront-distributions) dan membuat kasus.

1. Sebutkan berapa banyak sertifikat yang Anda perlukan izin penggunaannya, dan jelaskan keadaan di dalam permintaan Anda. Kami akan memperbarui akun Anda sesegera mungkin.

1. Lanjutkan dengan prosedur berikutnya.

# Persyaratan untuk menggunakan SSL/TLS sertifikat dengan CloudFront
<a name="cnames-and-https-requirements"></a>

Persyaratan untuk SSL/TLS sertifikat dijelaskan dalam topik ini. Mereka berlaku untuk kedua hal berikut, kecuali sebagaimana disebutkan:
+ Sertifikat untuk menggunakan HTTPS antara pemirsa dan CloudFront 
+ Sertifikat untuk menggunakan HTTPS antara CloudFront dan asal Anda

**Topics**
+ [Penerbit sertifikat](#https-requirements-certificate-issuer)
+ [Wilayah AWS untuk AWS Certificate Manager](#https-requirements-aws-region)
+ [Format Sertifikat](#https-requirements-certificate-format)
+ [Sertifikat Menengah](#https-requirements-intermediate-certificates)
+ [Tipe Kunci](#https-requirements-key-type)
+ [Kunci privat](#https-requirements-private-key)
+ [Izin](#https-requirements-permissions)
+ [Ukuran kunci sertifikat](#https-requirements-size-of-public-key)
+ [Jenis sertifikat yang didukung](#https-requirements-supported-types)
+ [Tanggal kedaluwarsa sertifikat dan perpanjangan](#https-requirements-cert-expiration)
+ [Nama domain dalam CloudFront distribusi dan sertifikat](#https-requirements-domain-names-in-cert)
+ [Versi SSL/TLS protokol minimum](#https-requirements-minimum-ssl-protocol-version)
+ [Versi HTTP yang didukung](#https-requirements-supported-http-versions)

## Penerbit sertifikat
<a name="https-requirements-certificate-issuer"></a>

Kami menyarankan Anda menggunakan sertifikat publik yang dikeluarkan oleh [AWS Certificate Manager (ACM)](https://aws.amazon.com/certificate-manager/). Untuk informasi tentang mendapatkan sertifikat dari ACM, lihat *[Panduan AWS Certificate Manager Pengguna](https://docs.aws.amazon.com/acm/latest/userguide/)*. Untuk menggunakan sertifikat ACM dengan CloudFront distribusi, pastikan Anda meminta (atau mengimpor) sertifikat di Wilayah AS Timur (Virginia Utara) (`us-east-1`).

 CloudFront mendukung otoritas sertifikat (CAs) yang sama dengan Mozilla, jadi jika Anda tidak menggunakan ACM, gunakan sertifikat yang dikeluarkan oleh CA pada Daftar Sertifikat [CA Termasuk Mozilla](https://wiki.mozilla.org/CA/Included_Certificates). 

Sertifikat TLS yang digunakan oleh asal yang Anda tentukan untuk CloudFront distribusi Anda juga harus dikeluarkan dari CA pada Daftar Sertifikat CA Termasuk Mozilla.

Untuk informasi lebih lanjut tentang mendapatkan dan menginstal sertifikat, lihat dokumentasi untuk perangkat lunak server HTTP Anda dan ke dokumentasi untuk CA.

## Wilayah AWS untuk AWS Certificate Manager
<a name="https-requirements-aws-region"></a>

Untuk menggunakan sertifikat di AWS Certificate Manager (ACM) untuk mewajibkan HTTPS antar pemirsa danCloudFront, pastikan Anda meminta (atau mengimpor) sertifikat di Wilayah AS Timur (Virginia Utara) (`us-east-1`).

Jika Anda ingin meminta HTTPS antara CloudFront dan asal Anda, dan Anda menggunakan penyeimbang beban di Elastic Load Balancing sebagai asal Anda, Anda dapat meminta atau mengimpor sertifikat di mana pun. Wilayah AWS

## Format Sertifikat
<a name="https-requirements-certificate-format"></a>

Sertifikat harus dalam format X.509 PEM. Ini adalah format default jika Anda menggunakan AWS Certificate Manager.

## Sertifikat Menengah
<a name="https-requirements-intermediate-certificates"></a>

Jika Anda menggunakan otoritas sertifikat pihak ketiga (CA), cantumkan semua sertifikat perantara dalam rantai sertifikat yang ada di `.pem` file, dimulai dengan sertifikat untuk CA yang menandatangani sertifikat untuk domain Anda. Biasanya, Anda akan menemukan file di situs web CA yang mencantumkan sertifikat perantara dan root dalam urutan rantai yang tepat.

**penting**  
Jangan sertakan yang berikut ini: sertifikat root, sertifikat perantara yang tidak berada di jalur kepercayaan, atau sertifikat kunci publik CA Anda.

Berikut ini contohnya:

```
-----BEGIN CERTIFICATE-----
Intermediate certificate 2
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
Intermediate certificate 1
-----END CERTIFICATE-----
```

## Tipe Kunci
<a name="https-requirements-key-type"></a>

CloudFront mendukung pasangan kunci publik-pribadi RSA dan ECDSA.

CloudFront mendukung koneksi HTTPS ke pemirsa dan asal menggunakan sertifikat RSA dan ECDSA. Dengan [AWS Certificate Manager (ACM)](https://console.aws.amazon.com/acm), Anda dapat meminta dan mengimpor sertifikat RSA atau ECDSA dan kemudian mengaitkannya dengan distribusi Anda. CloudFront 

Untuk daftar sandi RSA dan ECDSA yang didukung oleh CloudFront yang dapat Anda negosiasikan dalam koneksi HTTPS, lihat dan. [Protokol dan sandi yang didukung antara pemirsa dan CloudFront](secure-connections-supported-viewer-protocols-ciphers.md) [Protokol dan cipher yang didukung antara dan asal CloudFront](secure-connections-supported-ciphers-cloudfront-to-origin.md)

## Kunci privat
<a name="https-requirements-private-key"></a>

Jika Anda menggunakan sertifikat dari otoritas sertifikat pihak ketiga (CA), catat hal-hal berikut: 
+ Kunci pribadi harus cocok dengan kunci publik yang ada dalam sertifikat.
+ Kunci pribadi harus dalam format PEM.
+ Kunci pribadi tidak dapat dienkripsi dengan kata sandi.

Jika AWS Certificate Manager (ACM) memberikan sertifikat, ACM tidak melepaskan kunci pribadi. Kunci pribadi disimpan dalam ACM untuk digunakan oleh AWS layanan yang terintegrasi dengan ACM.

## Izin
<a name="https-requirements-permissions"></a>

Anda harus memiliki izin untuk menggunakan dan mengimpor SSL/TLS sertifikat. Jika Anda menggunakan AWS Certificate Manager (ACM), sebaiknya gunakan AWS Identity and Access Management izin untuk membatasi akses ke sertifikat. Untuk informasi selengkapnya, lihat [Identitas dan manajemen akses](https://docs.aws.amazon.com/acm/latest/userguide/security-iam.html) di *Panduan AWS Certificate Manager Pengguna*.

## Ukuran kunci sertifikat
<a name="https-requirements-size-of-public-key"></a>

Ukuran kunci sertifikat yang CloudFront mendukung tergantung pada jenis kunci dan sertifikat.

**Untuk sertifikat RSA:**  
CloudFront mendukung kunci RSA 1024-bit, 2048-bit, dan 3072-bit, dan 4096-bit. Panjang kunci maksimum untuk sertifikat RSA yang Anda gunakan CloudFront adalah 4096 bit.  
 Perhatikan bahwa ACM mengeluarkan sertifikat RSA dengan kunci hingga 2048-bit. Untuk menggunakan sertifikat RSA 3072-bit atau 4096-bit, Anda perlu mendapatkan sertifikat secara eksternal dan mengimpornya ke ACM, setelah itu akan tersedia untuk Anda gunakan. CloudFront   
Untuk informasi tentang cara menentukan ukuran kunci RSA, lihat[Tentukan ukuran kunci publik dalam sertifikat SSL/TLS RSA](cnames-and-https-size-of-public-key.md).

**Untuk sertifikat ECDSA:**  
CloudFront mendukung kunci 256-bit. Untuk menggunakan sertifikat ECDSA di ACM untuk mewajibkan HTTPS antar pemirsa dan CloudFront, gunakan kurva elips prime256v1.

## Jenis sertifikat yang didukung
<a name="https-requirements-supported-types"></a>

CloudFront mendukung semua jenis sertifikat yang dikeluarkan oleh otoritas sertifikat tepercaya.

## Tanggal kedaluwarsa sertifikat dan perpanjangan
<a name="https-requirements-cert-expiration"></a>

Jika Anda menggunakan sertifikat yang Anda dapatkan dari otoritas sertifikat pihak ketiga (CA), Anda harus memantau tanggal kedaluwarsa sertifikat dan memperbarui sertifikat yang Anda impor ke AWS Certificate Manager (ACM) atau mengunggah ke toko AWS Identity and Access Management sertifikat sebelum kedaluwarsa.

**penting**  
Untuk menghindari masalah kedaluwarsa sertifikat, perbarui atau impor ulang sertifikat Anda setidaknya 24 jam sebelum `NotAfter` nilai sertifikat Anda saat ini. Jika sertifikat Anda kedaluwarsa dalam waktu 24 jam, mintalah sertifikat baru dari ACM atau impor sertifikat baru ke ACM. Selanjutnya, kaitkan sertifikat baru ke CloudFront distribusi.  
CloudFront mungkin terus menggunakan sertifikat sebelumnya saat perpanjangan atau impor ulang sertifikat Anda sedang berlangsung. Ini adalah proses asinkron yang dapat memakan waktu hingga 24 jam sebelum CloudFront menunjukkan perubahan Anda.

Jika Anda menggunakan sertifikat yang disediakan ACM, ACM mengelola perpanjangan sertifikat untuk Anda. Untuk informasi lebih lanjut, lihat [Perpanjangan Terkelola](https://docs.aws.amazon.com/acm/latest/userguide/managed-renewal.html) dalam *AWS Certificate Manager Panduan Pengguna*.

## Nama domain dalam CloudFront distribusi dan sertifikat
<a name="https-requirements-domain-names-in-cert"></a>

Saat Anda menggunakan custom origin, SSL/TLS sertifikat di asal Anda menyertakan nama domain di bidang **Nama Umum**, dan mungkin beberapa lainnya di bidang **Nama Alternatif Subjek**. (CloudFront mendukung karakter wildcard dalam nama domain sertifikat.) 

Salah satu nama domain dalam sertifikat harus sesuai dengan nama domain yang Anda tentukan untuk Nama Domain Asal. Jika tidak ada nama domain yang cocok, CloudFront mengembalikan kode status HTTP `502 (Bad Gateway)` ke penampil.

**penting**  
Saat Anda menambahkan nama domain alternatif ke distribusi, CloudFront periksa apakah nama domain alternatif dicakup oleh sertifikat yang telah Anda lampirkan. Sertifikat harus mencakup nama domain alternatif di bidang nama alternatif subjek (SAN) pada sertifikat. Ini berarti bidang SAN harus berisi kecocokan persis untuk nama domain alternatif, atau berisi wildcard pada tingkat yang sama dengan nama domain alternatif yang Anda tambahkan.  
Untuk informasi selengkapnya, lihat [Persyaratan untuk menggunakan nama domain alternatif](CNAMEs.md#alternate-domain-names-requirements).

## Versi SSL/TLS protokol minimum
<a name="https-requirements-minimum-ssl-protocol-version"></a>

Jika Anda menggunakan alamat IP khusus, tetapkan versi SSL/TLS protokol minimum untuk koneksi antara pemirsa dan CloudFront dengan memilih kebijakan keamanan.

Untuk informasi lebih lanjut, lihat [Kebijakan keamanan ( SSL/TLS versi minimum)](DownloadDistValuesGeneral.md#DownloadDistValues-security-policy) dalam topik [Semua referensi pengaturan distribusi](distribution-web-values-specify.md).

## Versi HTTP yang didukung
<a name="https-requirements-supported-http-versions"></a>

Jika Anda mengaitkan satu sertifikat dengan lebih dari satu CloudFront distribusi, semua distribusi yang terkait dengan sertifikat harus menggunakan opsi yang sama untuk[Versi HTTP yang didukung](DownloadDistValuesGeneral.md#DownloadDistValuesSupportedHTTPVersions). Anda menentukan opsi ini saat membuat atau memperbarui CloudFront distribusi.

# Kuota tentang penggunaan SSL/TLS sertifikat dengan CloudFront (HTTPS antara pemirsa dan CloudFront hanya)
<a name="cnames-and-https-limits"></a>

Perhatikan kuota berikut tentang penggunaan SSL/TLS sertifikat denganCloudFront. Kuota ini hanya berlaku untuk SSL/TLS sertifikat yang Anda berikan dengan menggunakan AWS Certificate Manager (ACM), yang Anda impor ke ACM, atau unggah ke penyimpanan sertifikat IAM untuk komunikasi HTTPS antara pemirsa dan. CloudFront

Untuk informasi selengkapnya, lihat [Tingkatkan kuota untuk sertifikat SSL/TLS](increasing-the-limit-for-ssl-tls-certificates.md).

**Jumlah maksimum sertifikat per CloudFront distribusi**  
Anda dapat mengaitkan maksimal satu SSL/TLS sertifikat dengan setiap CloudFront distribusi.

**Jumlah maksimum sertifikat yang dapat Anda impor ke ACM atau unggah ke toko sertifikat IAM**  
Jika Anda memperoleh SSL/TLS sertifikat dari CA pihak ketiga, Anda harus menyimpan sertifikat di salah satu lokasi berikut:  
+ **AWS Certificate Manager** – Untuk kuota saat ini pada jumlah sertifikat ACM, lihat [Kuota](https://docs.aws.amazon.com/acm/latest/userguide/acm-limits.html) di *Panduan Pengguna AWS Certificate Manager *. Kuota terdaftar adalah total yang mencakup sertifikat yang Anda berikan dengan menggunakan ACM dan sertifikat yang Anda impor ke ACM.
+ *Penyimpanan **sertifikat IAM** — Untuk kuota saat ini (sebelumnya dikenal sebagai batas) pada jumlah sertifikat yang dapat Anda unggah ke toko sertifikat IAM untuk sebuah AWS akun, lihat [Batas IAM dan STS di Panduan Pengguna IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-limits.html).* Anda dapat meminta kuota yang lebih tinggi di konsol Service Quotas.

**Jumlah maksimum sertifikat per AWS akun (hanya alamat IP khusus)**  
Jika Anda ingin melayani permintaan HTTPS dengan menggunakan alamat IP khusus, perhatikan hal berikut:  
+ Secara default, CloudFront memberi Anda izin untuk menggunakan dua sertifikat dengan AWS akun Anda, satu untuk penggunaan sehari-hari dan satu untuk saat Anda perlu memutar sertifikat untuk beberapa distribusi.
+ Jika Anda memerlukan lebih dari dua SSL/TLS sertifikat khusus untuk AWS akun Anda, Anda dapat meminta kuota yang lebih tinggi di konsol Service Quotas.

**Gunakan sertifikat yang sama untuk CloudFront distribusi yang dibuat dengan menggunakan akun yang berbeda AWS **  
Jika Anda menggunakan CA pihak ketiga dan ingin menggunakan sertifikat yang sama dengan beberapa CloudFront distribusi yang dibuat menggunakan AWS akun yang berbeda, Anda harus mengimpor sertifikat ke ACM atau mengunggahnya ke penyimpanan sertifikat IAM sekali untuk setiap akun. AWS   
Jika Anda menggunakan sertifikat yang disediakan oleh ACM, Anda tidak dapat mengonfigurasi CloudFront untuk menggunakan sertifikat yang dibuat oleh AWS akun lain.

**Gunakan sertifikat yang sama untuk CloudFront dan untuk AWS layanan lainnya**  
Jika Anda membeli sertifikat dari otoritas sertifikat tepercaya seperti Comodo,, atau Symantec DigiCert, Anda dapat menggunakan sertifikat yang sama untuk CloudFront dan untuk layanan lainnya. AWS Jika Anda mengimpor sertifikat ke ACM, Anda perlu mengimpornya hanya satu kali untuk menggunakannya untuk beberapa layanan AWS .  
Jika Anda menggunakan sertifikat yang diberikan oleh ACM, sertifikat tersebut disimpan di ACM.

**Gunakan sertifikat yang sama untuk beberapa CloudFront distribusi**  
Anda dapat menggunakan sertifikat yang sama untuk setiap atau semua CloudFront yang Anda gunakan untuk memenuhi permintaan HTTPS. Perhatikan hal-hal berikut:  
+ Anda dapat menggunakan sertifikat yang sama untuk melayani permintaan menggunakan alamat IP khusus dan untuk melayani permintaan menggunakan SNI. 
+ Anda hanya dapat mengaitkan satu sertifikat dengan setiap distribusi.
+ Setiap distribusi harus menyertakan satu atau beberapa nama domain alternatif yang juga muncul di **Nama Umum** bidang atau **Nama Alternatif Subjek** dalam sertifikat.
+ Jika Anda melayani permintaan HTTPS menggunakan alamat IP khusus dan Anda membuat semua distribusi Anda dengan menggunakan AWS akun yang sama, Anda dapat secara signifikan mengurangi biaya Anda dengan menggunakan sertifikat yang sama untuk semua distribusi. CloudFront biaya untuk setiap sertifikat, bukan untuk setiap distribusi. 

  Misalnya, Anda membuat tiga distribusi dengan menggunakan AWS akun yang sama, dan Anda menggunakan sertifikat yang sama untuk ketiga distribusi. Anda hanya akan dikenakan satu biaya untuk menggunakan alamat IP khusus.

  Namun, jika Anda melayani permintaan HTTPS menggunakan alamat IP khusus dan menggunakan sertifikat yang sama untuk membuat CloudFront distribusi di AWS akun yang berbeda, setiap akun dikenakan biaya untuk menggunakan alamat IP khusus. Misalnya, jika Anda membuat tiga distribusi dengan menggunakan tiga AWS akun berbeda dan Anda menggunakan sertifikat yang sama untuk ketiga distribusi, setiap akun dikenakan biaya penuh untuk menggunakan alamat IP khusus.

# Konfigurasikan nama domain alternatif dan HTTPS
<a name="cnames-and-https-procedures"></a>

Untuk menggunakan nama domain alternatif di URLs file Anda dan menggunakan HTTPS antara pemirsa dan CloudFront, lakukan prosedur yang berlaku.

**Topics**
+ [Dapatkan SSL/TLS sertifikat](#cnames-and-https-getting-certificates)
+ [Impor SSL/TLS sertifikat](#cnames-and-https-uploading-certificates)
+ [Perbarui CloudFront distribusi Anda](#cnames-and-https-updating-cloudfront)

## Dapatkan SSL/TLS sertifikat
<a name="cnames-and-https-getting-certificates"></a>

Dapatkan SSL/TLS sertifikat jika Anda belum memilikinya. Untuk informasi lebih lanjut, lihat dokumentasi yang berlaku:
+ Untuk menggunakan sertifikat yang disediakan oleh AWS Certificate Manager (ACM), lihat [Panduan AWS Certificate Manager Pengguna](https://docs.aws.amazon.com/acm/latest/userguide/). Lalu, langsung ke [Perbarui CloudFront distribusi Anda](#cnames-and-https-updating-cloudfront).
**catatan**  
Kami menyarankan Anda menggunakan ACM untuk menyediakan, mengelola, dan menyebarkan SSL/TLS sertifikat pada sumber daya AWS terkelola. Anda harus meminta sertifikat ACM di Wilayah Timur AS (N. Virginia).
+ Untuk mendapatkan sertifikat dari otoritas sertifikat pihak ketiga (CA), lihat dokumentasi yang diberikan oleh otoritas sertifikat. Jika Anda memiliki sertifikat, lanjutkan dengan prosedur berikutnya.

## Impor SSL/TLS sertifikat
<a name="cnames-and-https-uploading-certificates"></a>

Jika Anda mendapatkan sertifikat Anda dari CA pihak ketiga, impor sertifikat ke ACM atau unggah ke toko sertifikat IAM:

**ACM (disarankan)**  
ACM memungkinkan Anda mengimpor sertifikat pihak ketiga dari konsol ACM, dan juga secara terprogram. Untuk informasi tentang mengimpor sertifikat ke ACM, lihat [Mengimpor Sertifikat ke dalam AWS Certificate Manager](https://docs.aws.amazon.com/acm/latest/userguide/import-certificate.html) dalam *Panduan Pengguna AWS Certificate Manager *. Anda harus mengimpor sertifikat di Wilayah Timur AS (N. Virginia).

**Toko sertifikat IAM**  
(Tidak disarankan) Gunakan AWS CLI perintah berikut untuk mengunggah sertifikat pihak ketiga Anda ke toko sertifikat IAM.  

```
aws iam upload-server-certificate \
        --server-certificate-name CertificateName \
        --certificate-body file://public_key_certificate_file \
        --private-key file://privatekey.pem \
        --certificate-chain file://certificate_chain_file \
        --path /cloudfront/path/
```
Perhatikan hal-hal berikut:  
+ **AWS akun** — Anda harus mengunggah sertifikat ke toko sertifikat IAM menggunakan AWS akun yang sama dengan yang Anda gunakan untuk membuat CloudFront distribusi Anda.
+ **--parameter batas** – Ketika Anda mengunggah sertifikat ke IAM, nilai `--path` parameter (jalur sertifikat) harus dimulai dengan `/cloudfront/`, misalnya, `/cloudfront/production/` atau `/cloudfront/test/`. Jalan harus diakhiri dengan /.
+ **Sertifikat yang ada** – Anda harus menentukan nilai untuk `--server-certificate-name` dan `--path` parameter yang berbeda dari nilai yang terkait dengan sertifikat yang ada.
+ **Menggunakan CloudFront konsol** — Nilai yang Anda tentukan untuk `--server-certificate-name` parameter di AWS CLI, misalnya`myServerCertificate`, muncul di daftar **Sertifikat SSL** di CloudFront konsol.
+ **Menggunakan CloudFront API** — Catat string alfanumerik yang AWS CLI dikembalikan, misalnya,. `AS1A2M3P4L5E67SIIXR3J` Ini adalah nilai yang akan Anda tentukan di elemen `IAMCertificateId`. Anda tidak perlu IAM ARN, yang juga dikembalikan oleh CLI.
Untuk informasi selengkapnya tentang AWS CLI, lihat [Panduan AWS Command Line Interface Pengguna](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html) dan [Referensi AWS CLI Perintah](https://docs.aws.amazon.com/cli/latest/reference/).

## Perbarui CloudFront distribusi Anda
<a name="cnames-and-https-updating-cloudfront"></a>

Untuk memperbarui pengaturan distribusi Anda, lakukan prosedur berikut:<a name="cnames-and-https-updating-cloudfront-procedure"></a>

**Untuk mengonfigurasi CloudFront distribusi Anda untuk nama domain alternatif**

1. Masuk ke Konsol Manajemen AWS dan buka CloudFront konsol di[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Pilih ID untuk distribusi yang ingin Anda perbarui.

1. Di **Umum** pilih, pilih **Edit**.

1. Perbarui nilai berikut:  
**Nama domain alternatif (CNAME)**  
Pilih **Tambahkan item** untuk menambahkan nama domain alternatif yang berlaku. Pisahkan nama domain dengan koma, atau ketikkan setiap nama domain pada baris baru.  
**Sertifikat SSL kustom**  
Pilih sertifikat dari daftar dropdown.  
Hingga 100 sertifikat tercantum di sini. Jika Anda memiliki lebih dari 100 sertifikat dan tidak melihat sertifikat yang ingin Anda tambahkan, Anda dapat mengetikkan sertifikat ARN di bidang untuk memilihnya.  
Jika Anda mengunggah sertifikat ke penyimpanan sertifikat IAM tetapi tidak tercantum, dan Anda tidak dapat memilihnya dengan mengetikkan nama di bidang, periksa prosedurnya [Impor SSL/TLS sertifikat](#cnames-and-https-uploading-certificates) untuk mengonfirmasi bahwa Anda telah mengunggah sertifikat dengan benar.   
Setelah Anda mengaitkan SSL/TLS sertifikat Anda dengan CloudFront distribusi Anda, jangan hapus sertifikat dari ACM atau penyimpanan sertifikat IAM sampai Anda menghapus sertifikat dari semua distribusi dan semua distribusi dikerahkan.

1. Pilih **Simpan perubahan**.

1. Konfigurasikan CloudFront untuk mewajibkan HTTPS antara pemirsa dan CloudFront:

   1. Di **Perilaku** pilih perilaku cache yang ingin Anda perbarui, lalu pilih **Edit**.

   1. Tentukan salah satu nilai untuk **Kebijakan Protokol Penampil**:  
**Arahkan ulang HTTP ke HTTPS**  
Pemirsa dapat menggunakan kedua protokol, tetapi permintaan HTTP secara otomatis dialihkan ke permintaan HTTPS. CloudFrontmengembalikan kode status HTTP `301 (Moved Permanently)` bersama dengan URL HTTPS baru. Penampil kemudian mengirimkan kembali permintaan untuk CloudFront menggunakan URL HTTPS.  
CloudFront tidak mengalihkan`DELETE`,,,`OPTIONS`, `PATCH``POST`, atau `PUT` permintaan dari HTTP ke HTTPS. Jika Anda mengonfigurasi perilaku cache untuk mengarahkan ulang ke HTTPS, CloudFront merespons HTTP`DELETE`,,,`OPTIONS`, `PATCH``POST`, atau `PUT` permintaan untuk perilaku cache tersebut dengan kode status HTTP. `403 (Forbidden)`
Saat penampil membuat permintaan HTTP yang dialihkan ke permintaan HTTPS, CloudFront dikenakan biaya untuk kedua permintaan tersebut. Untuk permintaan HTTP, tagihan hanya untuk permintaan dan header yang CloudFront kembali ke penampil. Untuk permintaan HTTPS, biayanya adalah untuk permintaan, dan untuk header dan file yang dikembalikan oleh asal Anda.  
**HTTPS Saja**  
Penampil dapat mengakses konten Anda hanya jika mereka menggunakan HTTPS. Jika penampil mengirim permintaan HTTP bukan permintaan HTTPS, CloudFront mengembalikan kode status HTTP `403 (Forbidden)` dan tidak mengembalikan file.

   1. Pilih **Ya, Edit**.

   1. Ulangi langkah a hingga c untuk setiap perilaku cache tambahan yang ingin Anda perlukan HTTPS antara pemirsa danCloudFront.

1. Konfirmasikan hal berikut sebelum menggunakan konfigurasi yang diperbarui dalam lingkungan produksi:
   + Pola jalur dalam setiap perilaku cache hanya berlaku untuk permintaan yang ingin digunakan penampil dengan HTTPS.
   + Perilaku singgahan dicantumkan sesuai urutan yang Anda inginkan CloudFront untuk mengevaluasinya. Untuk informasi selengkapnya, lihat [Pola jalur](DownloadDistValuesCacheBehavior.md#DownloadDistValuesPathPattern).
   + Perilaku singgahan sedang mengarahkan permintaan ke asal-usul yang benar. 

# Tentukan ukuran kunci publik dalam sertifikat SSL/TLS RSA
<a name="cnames-and-https-size-of-public-key"></a>

Saat Anda menggunakan nama domain CloudFront alternatif dan HTTPS, ukuran maksimum kunci publik dalam sertifikat SSL/TLS RSA adalah 4096 bit. (Ini adalah ukuran kunci, bukan jumlah karakter dalam kunci publik.) Jika Anda menggunakan AWS Certificate Manager untuk sertifikat Anda, meskipun ACM mendukung kunci RSA yang lebih besar, Anda tidak dapat menggunakan kunci yang lebih besar dengan. CloudFront

Anda dapat menentukan ukuran kunci publik RSA dengan menjalankan perintah OpenSSL berikut:

```
openssl x509 -in path and filename of SSL/TLS certificate -text -noout 
```

Di mana:
+ `-in`menentukan path dan nama file sertifikat SSL/TLS RSA Anda.
+ `-text`menyebabkan OpenSSL menampilkan panjang kunci publik RSA dalam bit.
+ `-noout` mencegah OpenSSL menampilkan kunci publik.

Contoh output:

```
Public-Key: (2048 bit)
```

# Tingkatkan kuota untuk sertifikat SSL/TLS
<a name="increasing-the-limit-for-ssl-tls-certificates"></a>

Ada kuota pada jumlah SSL/TLS sertifikat yang dapat Anda impor ke AWS Certificate Manager (ACM) atau unggah ke AWS Identity and Access Management (IAM). Ada juga kuota pada jumlah SSL/TLS sertifikat yang dapat Anda gunakan dengan Akun AWS ketika Anda mengkonfigurasi CloudFront untuk melayani permintaan HTTPS dengan menggunakan alamat IP khusus. Namun, Anda dapat meminta kuota yang lebih tinggi.

**Topics**
+ [Meningkatkan kuota sertifikat yang diimpor ke ACM](#certificates-to-import-into-acm)
+ [Meningkatkan kuota sertifikat yang diunggah ke IAM](#certificates-to-upload-into-iam)
+ [Meningkatkan kuota pada sertifikat yang digunakan dengan alamat IP khusus](#certificates-using-dedicated-ip-address)

## Meningkatkan kuota sertifikat yang diimpor ke ACM
<a name="certificates-to-import-into-acm"></a>

Untuk kuota jumlah sertifikat yang dapat Anda impor menjadi ACM, lihat [Kuota](https://docs.aws.amazon.com/acm/latest/userguide/acm-limits.html) dalam *Panduan Pengguna AWS Certificate Manager *.

Untuk meminta kuota yang lebih tinggi, gunakan konsol Service Quotas. Untuk informasi selengkapnya, lihat [Meminta peningkatan kuota](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html) di *Panduan Pengguna Service Quotas*.

## Meningkatkan kuota sertifikat yang diunggah ke IAM
<a name="certificates-to-upload-into-iam"></a>

Untuk kuota (sebelumnya dikenal sebagai batas) pada jumlah sertifikat yang dapat Anda unggah ke IAM, lihat [Batas IAM dan STS](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-limits.html) dalam *Panduan Pengguna IAM*.

Untuk meminta kuota yang lebih tinggi, gunakan konsol Service Quotas. Untuk informasi selengkapnya, lihat [Meminta peningkatan kuota](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html) di *Panduan Pengguna Service Quotas*.

## Meningkatkan kuota pada sertifikat yang digunakan dengan alamat IP khusus
<a name="certificates-using-dedicated-ip-address"></a>

Untuk kuota jumlah sertifikat SSL yang dapat Anda gunakan untuk setiap Akun AWS saat melayani permintaan HTTPS menggunakan alamat IP khusus, lihat. [Kuota pada sertifikat SSL](cloudfront-limits.md#limits-ssl-certificates)

Untuk meminta kuota yang lebih tinggi, gunakan konsol Service Quotas. Untuk informasi selengkapnya, lihat [Meminta peningkatan kuota](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html) di *Panduan Pengguna Service Quotas*.

# Putar SSL/TLS sertifikat
<a name="cnames-and-https-rotate-certificates"></a>

Ketika SSL/TLS sertifikat Anda hampir kedaluwarsa, Anda perlu memutarnya untuk memastikan keamanan distribusi Anda dan menghindari gangguan layanan bagi pemirsa Anda. Anda dapat memutarnya dengan cara berikut:
+ Untuk SSL/TLS sertifikat yang disediakan oleh AWS Certificate Manager (ACM), Anda tidak perlu memutarnya. ACM *secara otomatis* mengelola perpanjangan sertifikat untuk Anda. Untuk informasi selengkapnya, lihat [Perpanjangan sertifikat terkelola](https://docs.aws.amazon.com/acm/latest/userguide/acm-renewal.html) di *Panduan AWS Certificate Manager Pengguna*.
+ Jika Anda menggunakan otoritas sertifikat pihak ketiga dan Anda mengimpor sertifikat ke ACM (disarankan) atau mengunggahnya ke toko sertifikat IAM, Anda harus sesekali mengganti satu sertifikat dengan yang lain.

  

**penting**  
ACM tidak mengelola perpanjangan sertifikat untuk sertifikat yang Anda peroleh dari otoritas sertifikat pihak ketiga dan impor ke ACM.
Jika Anda mengonfigurasi CloudFront untuk melayani permintaan HTTPS dengan menggunakan alamat IP khusus, Anda mungkin dikenakan biaya tambahan pro-rating untuk menggunakan satu atau beberapa sertifikat tambahan saat Anda memutar sertifikat. Kami menyarankan Anda memperbarui distribusi Anda untuk meminimalkan biaya tambahan.

## Putar SSL/TLS sertifikat
<a name="rotate-ssl-tls-certificate"></a>

Untuk memutar sertifikat Anda, lakukan prosedur berikut. Penampil dapat terus mengakses konten Anda saat Anda memutar sertifikat serta setelah proses selesai.<a name="rotate-ssl-tls-certificates-proc"></a>

**Untuk memutar SSL/TLS sertifikat**

1. [Tingkatkan kuota untuk sertifikat SSL/TLS](increasing-the-limit-for-ssl-tls-certificates.md) untuk menentukan apakah Anda memerlukan izin untuk menggunakan lebih banyak sertifikat SSL. Jika ya, minta izin dan tunggu sampai izin diberikan sebelum Anda melanjutkan langkah 2.

1. Impor sertifikat baru ke ACM atau unggah ke IAM. Untuk informasi selengkapnya, lihat [Mengimpor SSL/TLS Sertifikat](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/cnames-and-https-procedures.html#cnames-and-https-uploading-certificates) di *Panduan CloudFront Pengembang Amazon*.

1. (Hanya untuk sertifikat IAM) Perbarui distribusi Anda satu per satu untuk menggunakan sertifikat baru. Untuk informasi selengkapnya, lihat [Perbarui distribusi](HowToUpdateDistribution.md).

1. (Opsional) Hapus sertifikat sebelumnya dari ACM atau IAM.
**penting**  
Jangan menghapus SSL/TLS sertifikat sampai Anda menghapusnya dari semua distribusi dan hingga status distribusi yang telah Anda perbarui telah berubah. `Deployed`

# Kembalikan dari SSL/TLS sertifikat kustom ke sertifikat default CloudFront
<a name="cnames-and-https-revert-to-cf-certificate"></a>

Jika Anda mengonfigurasi CloudFront untuk menggunakan HTTPS antara penonton dan CloudFront, dan Anda mengonfigurasi CloudFront untuk menggunakan SSL/TLS sertifikat kustom, Anda dapat mengubah konfigurasi untuk menggunakan sertifikat CloudFront SSL/TLS default. Proses tersebut bergantung pada apakah Anda telah menggunakan distribusi Anda untuk mendistribusikan konten:
+ Jika Anda belum menggunakan distribusi untuk mendistribusikan konten, Anda dapat mengubah konfigurasi saja. Untuk informasi selengkapnya, lihat [Perbarui distribusi](HowToUpdateDistribution.md).
+ Jika Anda telah menggunakan distribusi Anda untuk mendistribusikan konten Anda, Anda harus membuat CloudFront distribusi baru dan mengubah file Anda URLs untuk mengurangi atau menghilangkan jumlah waktu konten Anda tidak tersedia. Untuk melakukannya, lakukan prosedur berikut.

## Kembalikan ke sertifikat default CloudFront
<a name="revert-default-cloudfront-certificate"></a>

Prosedur berikut menunjukkan kepada Anda cara mengembalikan dari sertifikat kustom ke SSL/TLS CloudFront sertifikat default.<a name="cnames-and-https-revert-to-cf-certificate-proc"></a>

**Untuk kembali ke sertifikat default CloudFront**

1. Buat CloudFront distribusi baru dengan konfigurasi yang diinginkan. Untuk **Sertifikat SSL**, pilih **Default CloudFront Sertifikat (\$1.cloudfront.net)**. 

   Untuk informasi selengkapnya, lihat [Buat distribusi](distribution-web-creating-console.md).

1. Untuk file yang Anda distribusikan CloudFront, perbarui URLs di aplikasi Anda untuk menggunakan nama domain yang CloudFront ditetapkan ke distribusi baru. Misalnya, perubahan `https://www.example.com/images/logo.png` ke `https://d111111abcdef8.cloudfront.net/images/logo.png`.

1. Hapus distribusi yang terkait dengan sertifikat SSL/TLS kustom, atau perbarui distribusi untuk mengubah nilai Sertifikat **SSL menjadi Sertifikat **Default CloudFront ** (\$1.cloudfront.net**). Untuk informasi selengkapnya, lihat [Perbarui distribusi](HowToUpdateDistribution.md).
**penting**  
Sampai Anda menyelesaikan langkah ini, AWS terus menagih Anda untuk menggunakan SSL/TLS sertifikat khusus.

1. (Opsional) Hapus SSL/TLS sertifikat kustom Anda.

   1. Jalankan AWS CLI perintah `list-server-certificates` untuk mendapatkan ID sertifikat sertifikat yang ingin Anda hapus. Untuk informasi selengkapnya, lihat [list-server-certificates](https://docs.aws.amazon.com/cli/latest/reference/iam/list-server-certificates.html) dalam *AWS CLI Referensi Perintah*.

   1. Jalankan AWS CLI perintah `delete-server-certificate` untuk menghapus sertifikat. Untuk informasi selengkapnya, lihat [delete-server-certificate](https://docs.aws.amazon.com/cli/latest/reference/iam/delete-server-certificate.html) dalam *AWS CLI Referensi Perintah*.

# Beralih dari SSL/TLS sertifikat khusus dengan alamat IP khusus ke SNI
<a name="cnames-and-https-switch-dedicated-to-sni"></a>

Jika Anda mengonfigurasi CloudFront untuk menggunakan SSL/TLS sertifikat khusus dengan alamat IP khusus, Anda dapat beralih menggunakan SSL/TLS sertifikat khusus dengan SNI sebagai gantinya dan menghilangkan biaya yang terkait dengan alamat IP khusus.

**penting**  
Pembaruan CloudFront konfigurasi Anda ini tidak berpengaruh pada pemirsa yang mendukung SNI. Pemirsa dapat mengakses konten Anda sebelum dan sesudah perubahan, serta saat perubahan menyebar ke lokasi CloudFront tepi. Pemirsa yang tidak mendukung SNI tidak dapat mengakses konten Anda setelah perubahan. Untuk informasi selengkapnya, lihat [Pilih cara CloudFront melayani permintaan HTTPS](cnames-https-dedicated-ip-or-sni.md). 

## Beralih dari sertifikat khusus ke SNI
<a name="cloudfront-switch-custom-cert-sni"></a>

Prosedur berikut menunjukkan kepada Anda cara beralih dari SSL/TLS sertifikat khusus dengan alamat IP khusus ke SNI.<a name="cnames-and-https-switch-dedicated-to-sni-proc"></a>

**Untuk beralih dari SSL/TLS sertifikat khusus dengan alamat IP khusus ke SNI**

1. Masuk ke Konsol Manajemen AWS dan buka CloudFront konsol di[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Pilih ID distribusi yang ingin Anda lihat atau perbarui.

1. Pilih **Pengaturan Distribusi**.

1. Di **Umum** pilih, pilih **Edit**.

1. Di bawah **sertifikasi SSL Kustom - *opsional***, **batalkan pilihan dukungan klien Legacy.**

1. Pilih **Ya, Edit**.

# Otentikasi TLS timbal balik dengan CloudFront (Viewer mTLS)
<a name="mtls-authentication"></a>

Mutual TLS Authentication (Mutual Transport Layer Security Authentication — mTLS) adalah protokol keamanan yang memperluas otentikasi TLS standar dengan memerlukan otentikasi berbasis sertifikat dua arah, di mana klien dan server harus membuktikan identitas mereka sebelum membuat koneksi yang aman. Menggunakan TLS timbal balik, Anda dapat memastikan bahwa hanya klien yang menyajikan sertifikat TLS tepercaya yang mendapatkan akses ke distribusi Anda. CloudFront 

## Cara kerjanya
<a name="how-mtls-works"></a>

Dalam jabat tangan TLS standar, hanya server yang menyajikan sertifikat untuk membuktikan identitasnya kepada klien. Dengan TLS timbal balik, proses otentikasi menjadi dua arah. Ketika klien mencoba untuk terhubung ke CloudFront distribusi Anda, CloudFront meminta sertifikat klien selama jabat tangan TLS. Klien harus menunjukkan sertifikat X.509 yang valid yang CloudFront memvalidasi terhadap penyimpanan kepercayaan Anda yang dikonfigurasi sebelum membuat koneksi aman.

CloudFront melakukan validasi sertifikat ini di lokasi AWS tepi, menurunkan kompleksitas otentikasi dari server asal Anda sambil mempertahankan CloudFront manfaat kinerja global. Anda dapat mengonfigurasi mTL dalam dua mode: mode verifikasi (yang mengharuskan semua klien untuk menunjukkan sertifikat yang valid) atau mode opsional (yang memvalidasi sertifikat saat disajikan tetapi juga memungkinkan koneksi tanpa sertifikat).

## Kasus penggunaan
<a name="mtls-use-cases"></a>

Otentikasi TLS timbal balik dengan CloudFront membahas beberapa skenario keamanan kritis di mana metode otentikasi tradisional tidak mencukupi:
+ **Otentikasi perangkat dengan caching konten** - Anda dapat mengautentikasi konsol game, perangkat IoT, atau perangkat keras perusahaan sebelum mengizinkan akses ke pembaruan firmware, unduhan game, atau sumber daya internal. Setiap perangkat berisi sertifikat unik yang membuktikan keasliannya sambil memanfaatkan kemampuan caching CloudFront.
+ **API-to-API otentikasi** - Anda dapat mengamankan machine-to-machine komunikasi antara mitra bisnis tepercaya, sistem pembayaran, atau layanan mikro. Otentikasi berbasis sertifikat menghilangkan kebutuhan akan rahasia bersama atau kunci API sambil memberikan verifikasi identitas yang kuat untuk pertukaran data otomatis.

**Topics**
+ [Cara kerjanya](#how-mtls-works)
+ [Kasus penggunaan](#mtls-use-cases)
+ [Toko kepercayaan dan manajemen sertifikat](trust-stores-certificate-management.md)
+ [Aktifkan TLS timbal balik untuk distribusi CloudFront](enable-mtls-distributions.md)
+ [Kaitkan Fungsi CloudFront Koneksi](connection-functions.md)
+ [Mengkonfigurasi pengaturan tambahan](configuring-additional-settings.md)
+ [Header mTLS penampil untuk kebijakan cache dan diteruskan ke asal](viewer-mtls-headers.md)
+ [Pencabutan menggunakan Fungsi CloudFront Koneksi dan KVS](revocation-connection-function-kvs.md)
+ [Observabilitas menggunakan log koneksi](connection-logs.md)

# Toko kepercayaan dan manajemen sertifikat
<a name="trust-stores-certificate-management"></a>

Membuat dan mengonfigurasi toko kepercayaan adalah persyaratan wajib untuk menerapkan otentikasi TLS timbal balik dengan. CloudFront Trust store berisi sertifikat Certificate Authority (CA) yang CloudFront digunakan untuk memvalidasi sertifikat klien selama proses otentikasi.

## Apa itu toko kepercayaan?
<a name="what-is-trust-store"></a>

Toko kepercayaan adalah repositori sertifikat CA yang CloudFront digunakan untuk memvalidasi sertifikat klien selama otentikasi TLS bersama. Trust store berisi sertifikat CA root dan intermediate yang membentuk rantai kepercayaan untuk mengautentikasi sertifikat klien.

Saat Anda menerapkan TLS timbal balik CloudFront, toko kepercayaan menentukan Otoritas Sertifikat mana yang Anda percayai untuk menerbitkan sertifikat klien yang valid. CloudFront memvalidasi setiap sertifikat klien terhadap toko kepercayaan Anda selama jabat tangan TLS. Hanya klien yang menyajikan sertifikat yang berantai ke salah satu toko kepercayaan Anda yang CAs akan berhasil diautentikasi.

Trust store CloudFront adalah sumber daya tingkat akun yang dapat Anda kaitkan dengan beberapa distribusi. Ini memungkinkan Anda mempertahankan kebijakan validasi sertifikat yang konsisten di seluruh CloudFront penerapan sekaligus menyederhanakan manajemen sertifikat CA.

## Dukungan Otoritas Sertifikat
<a name="ca-support"></a>

CloudFront mendukung sertifikat yang dikeluarkan oleh Otoritas Sertifikat AWS Pribadi dan Otoritas Sertifikat swasta pihak ketiga. Fleksibilitas ini memungkinkan Anda untuk menggunakan infrastruktur sertifikat yang ada atau memanfaatkan layanan sertifikat AWS terkelola berdasarkan persyaratan organisasi Anda.
+ **AWS Otoritas Sertifikat Pribadi:** Anda dapat menggunakan sertifikat yang dikeluarkan oleh AWS Private CA, yang menyediakan layanan otoritas sertifikat swasta yang dikelola. Integrasi ini menyederhanakan manajemen siklus hidup sertifikat dan menyediakan integrasi tanpa batas dengan layanan lain. AWS 
+ **Otoritas Sertifikat Pribadi Pihak Ketiga:** Anda juga dapat menggunakan sertifikat dari infrastruktur Otoritas Sertifikat pribadi Anda yang ada, termasuk perusahaan CAs atau penyedia sertifikat pihak ketiga lainnya. Hal ini memungkinkan Anda untuk mempertahankan proses manajemen sertifikat Anda saat ini sambil menambahkan CloudFront kemampuan mTLS.

## Persyaratan dan spesifikasi sertifikat
<a name="certificate-requirements"></a>

Toko kepercayaan memiliki persyaratan khusus untuk sertifikat CA yang dikandungnya:

### Persyaratan format sertifikat CA
<a name="ca-cert-format-requirements"></a>
+ **Format: Format** PEM (Privacy Enhanced Mail)
+ **Batasan konten: Sertifikat harus dilampirkan dalam batas** ------ MULAI SERTIFIKAT ------ dan ------ END CERTIFICATE ------
+ **Komentar:** Harus didahului oleh karakter \$1 dan tidak dapat berisi - karakter
+ **Jeda baris:** Tidak ada baris kosong yang diizinkan di antara sertifikat

### Spesifikasi sertifikat yang didukung
<a name="supported-cert-specs"></a>
+ **Jenis sertifikat:** X.509v3
+ **Jenis kunci publik:**
  + RSA 2048, RSA 3072, RSA 4096
  + ECDSA: secp256r1, secp384r1
+ **Algoritma tanda tangan:**
  + SHA256, SHA384, SHA512 dengan RSA
  + SHA256, SHA384, SHA512 dengan EC
  + SHA256, SHA384, SHA512 dengan RSASSA-PSS dengan MGF1

### Contoh format bundel sertifikat
<a name="example-cert-bundle"></a>

Beberapa sertifikat (dikodekan PEM):

```
# Root CA Certificate
-----BEGIN CERTIFICATE-----
MIIDXTCCAkWgAwIBAgIJAKoK/OvD/XqiMA0GCSqGSIb3DQEBCwUAMEUxCzAJBgNV
BAYTAkFVMRMwEQYDVQQIDApTb21lLVN0YXRlMSEwHwYDVQQKDBhJbnRlcm5ldCBX
aWRnaXRzIFB0eSBMdGQwHhcNMTcwNzEyMTU0NzQ4WhcNMjcwNzEwMTU0NzQ4WjBF
MQswCQYDVQQGEwJBVTETMBEGA1UECAwKU29tZS1TdGF0ZTEhMB8GA1UECgwYSW50
ZXJuZXQgV2lkZ2l0cyBQdHkgTHRkMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB
CgKCAQEAuuExKvY1xzHFylsHiuowqpmzs7rEcuuylOuEszpFp+BtXh0ZuEtts9LP
-----END CERTIFICATE-----
# Intermediate CA Certificate
-----BEGIN CERTIFICATE-----
MIIDXTCCAkWgAwIBAgIJAKoK/OvD/XqjMA0GCSqGSIb3DQEBCwUAMEUxCzAJBgNV
BAYTAkFVMRMwEQYDVQQIDApTb21lLVN0YXRlMSEwHwYDVQQKDBhJbnRlcm5ldCBX
aWRnaXRzIFB0eSBMdGQwHhcNMTcwNzEyMTU0NzQ4WhcNMjcwNzEwMTU0NzQ4WjBF
MQswCQYDVQQGEwJBVTETMBEGA1UECAwKU29tZS1TdGF0ZTEhMB8GA1UECgwYSW50
ZXJuZXQgV2lkZ2l0cyBQdHkgTHRkMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB
CgKCAQEAuuExKvY1xzHFylsHiuowqpmzs7rEcuuylOuEszpFp+BtXh0ZuEtts9LP
-----END CERTIFICATE-----
```

## Buat toko kepercayaan
<a name="create-trust-store"></a>

Sebelum membuat toko kepercayaan, Anda harus mengunggah bundel sertifikat CA Anda dalam format PEM ke bucket Amazon S3. Bundel sertifikat harus berisi semua sertifikat CA root dan perantara tepercaya yang diperlukan untuk memvalidasi sertifikat klien Anda.

Bundel sertifikat CA hanya dibaca sekali dari S3 saat membuat toko kepercayaan. Jika perubahan future dilakukan pada bundel sertifikat CA, maka trust store harus diperbarui secara manual. Tidak ada sinkronisasi yang dipertahankan antara toko kepercayaan dan bundel sertifikat S3 CA.

### Prasyarat
<a name="trust-store-prerequisites"></a>
+ Bundel sertifikat dari Otoritas Sertifikat (CA) yang diunggah ke bucket Amazon S3
+ Izin yang diperlukan untuk membuat sumber daya CloudFront 

### Untuk membuat toko kepercayaan (Konsol)
<a name="create-trust-store-console"></a>

1. Masuk ke Konsol Manajemen AWS dan buka CloudFront konsol di[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Di panel navigasi, pilih **Trust store**.

1. Pilih **Buat toko kepercayaan**.

1. Untuk **nama toko Trust**, masukkan nama untuk toko kepercayaan Anda.

1. Untuk paket **otoritas Sertifikat (CA), masukkan jalur Amazon S3 ke bundel** sertifikat CA format PEM Anda.

1. Pilih **Buat toko kepercayaan**.

### Untuk membuat toko kepercayaan (AWS CLI)
<a name="create-trust-store-cli"></a>

```
aws cloudfront create-trust-store \
  --name MyTrustStore \
  --ca-certificates-bundle-source '{"CaCertificatesBundleS3Location":{"Bucket":"my-bucket","Key":"ca-bundle.pem","Region":"bucket-region"}}' \
  --tags Items=[{Key=Environment,Value=Production}]
```

## Mengaitkan toko kepercayaan dengan distribusi
<a name="associate-trust-store"></a>

Setelah membuat toko kepercayaan, Anda harus mengaitkannya dengan CloudFront distribusi untuk mengaktifkan otentikasi TLS timbal balik.

### Prasyarat
<a name="associate-prerequisites"></a>
+  CloudFront Distribusi yang ada dengan kebijakan protokol penampil khusus HTTP diaktifkan dan HTTP3 dukungan dinonaktifkan.

### Untuk mengaitkan toko kepercayaan (Konsol)
<a name="associate-trust-store-console"></a>

Ada dua cara untuk mengaitkan toko kepercayaan di dalam CloudFront konsol: melalui halaman detail toko kepercayaan atau melalui halaman pengaturan distribusi.

**Mengaitkan toko kepercayaan melalui halaman detail toko kepercayaan:**

1. Masuk ke Konsol Manajemen AWS dan buka CloudFront konsol di[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Di panel navigasi, pilih **Trust store**.

1. Pilih nama toko kepercayaan yang ingin Anda kaitkan.

1. Pilih **Associate to Distribution**.

1. Konfigurasikan opsi mTLS Viewer yang tersedia:
   + Mode **validasi sertifikat klien: Pilih antara mode** Diperlukan dan Opsional. Dalam mode wajib, semua klien diharuskan untuk menunjukkan sertifikat. Dalam mode opsional, klien yang menyajikan sertifikat divalidasi, sementara klien yang tidak menunjukkan sertifikat diizinkan mengakses.
   + **Iklankan nama CA toko kepercayaan:** Pilih apakah akan mengiklankan nama CA di toko kepercayaan Anda kepada klien selama jabat tangan TLS.
   + **Abaikan tanggal kedaluwarsa sertifikat:** Pilih apakah akan mengizinkan koneksi dengan sertifikat kedaluwarsa (kriteria validasi lainnya masih berlaku).
   + **Fungsi Koneksi:** Fungsi Koneksi opsional dapat dikaitkan dengan allow/deny koneksi berdasarkan kriteria khusus lainnya.

1. Pilih satu atau beberapa distribusi untuk dikaitkan dengan toko kepercayaan. Hanya distribusi dengan perilaku cache yang HTTP3 dinonaktifkan dan hanya HTTP yang dapat mendukung mTL Penampil.

1. Pilih **Kaitkan**.

**Mengaitkan toko kepercayaan melalui halaman pengaturan distribusi:**

1. Masuk ke Konsol Manajemen AWS dan buka CloudFront konsol di[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Pilih distribusi yang ingin Anda kaitkan

1. Di bawah tab **Umum**, di dalam wadah **Pengaturan**, pilih **Edit** di sudut kanan atas

1. Gulir ke bawah ke bagian bawah halaman, di dalam wadah **Konektivitas**, aktifkan sakelar **Viewer mTLS**

1. Konfigurasikan opsi mTLS Viewer yang tersedia:
   + Mode **validasi sertifikat klien: Pilih antara mode** Diperlukan dan Opsional. Dalam mode wajib, semua klien diharuskan untuk menunjukkan sertifikat. Dalam mode opsional, klien yang menyajikan sertifikat divalidasi, sementara klien yang tidak menunjukkan sertifikat diizinkan mengakses.
   + **Iklankan nama CA toko kepercayaan:** Pilih apakah akan mengiklankan nama CA di toko kepercayaan Anda kepada klien selama jabat tangan TLS.
   + **Abaikan tanggal kedaluwarsa sertifikat:** Pilih apakah akan mengizinkan koneksi dengan sertifikat kedaluwarsa (kriteria validasi lainnya masih berlaku).
   + **Fungsi Koneksi:** Fungsi Koneksi opsional dapat dikaitkan dengan allow/deny koneksi berdasarkan kriteria khusus lainnya.

1. Pilih **Simpan perubahan** di sudut kanan bawah.

### Untuk mengaitkan toko kepercayaan (AWS CLI)
<a name="associate-trust-store-cli"></a>

Toko kepercayaan dapat dikaitkan dengan distribusi melalui. DistributionConfig ViewerMtlsConfig properti. Ini berarti pertama-tama kita perlu mengambil konfigurasi distribusi dan kemudian memberikan permintaan ViewerMtlsConfig berikutnya UpdateDistribution .

```
// First fetch the distribution
aws cloudfront get-distribution {DISTRIBUTION_ID}

// Update the distribution config, for example:
Distribution config, file://distConf.json: 
{
  ...other fields,
  ViewerMtlsConfig: {
    Mode: 'required',
    TrustStoreConfig: {
        AdvertiseTrustStoreCaNames: false,
        IgnoreCertificateExpiry: true,
        TrustStoreId: {TRUST_STORE_ID}
    }
  }
}

aws cloudfront update-distribution \
   --id {DISTRIBUTION_ID} \
   --if-match {ETAG} \
   --distribution-config file://distConf.json
```

## Kelola toko kepercayaan
<a name="manage-trust-stores"></a>

### Lihat detail toko kepercayaan
<a name="view-trust-store-details"></a>

1. Masuk ke Konsol Manajemen AWS dan buka CloudFront konsol di[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Di panel navigasi, pilih **Trust store**.

1. Pilih nama toko kepercayaan untuk melihat halaman detailnya.

Halaman detail menunjukkan:
+ Nama dan ID toko kepercayaan
+ Jumlah sertifikat CA
+ Tanggal pembuatan dan tanggal modifikasi terakhir
+ Distribusi terkait
+ Tag

### Ubah toko kepercayaan
<a name="modify-trust-store"></a>

Untuk mengganti bundel sertifikat CA:

1. Masuk ke Konsol Manajemen AWS dan buka CloudFront konsol di[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Di panel navigasi, pilih **Trust store**.

1. Pilih nama toko kepercayaan.

1. Pilih **Tindakan**, lalu **Edit**.

1. Untuk **bundel otoritas Sertifikat (CA)**, masukkan lokasi Amazon S3 dari file PEM bundel CA yang diperbarui.

1. Pilih **Perbarui toko kepercayaan**.

### Hapus toko kepercayaan
<a name="delete-trust-store"></a>

**Prasyarat:** Anda harus terlebih dahulu memisahkan toko kepercayaan dari semua distribusi. CloudFront 

1. Masuk ke Konsol Manajemen AWS dan buka CloudFront konsol di[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Di panel navigasi, pilih **Trust store**.

1. Pilih nama toko kepercayaan.

1. Pilih **Hapus toko kepercayaan**.

1. Pilih **Hapus** untuk mengonfirmasi.

### Langkah selanjutnya
<a name="trust-store-next-steps"></a>

Setelah membuat dan mengaitkan toko kepercayaan Anda dengan CloudFront distribusi, Anda dapat melanjutkan untuk mengaktifkan otentikasi TLS timbal balik pada distribusi Anda dan mengonfigurasi pengaturan tambahan seperti meneruskan header sertifikat ke asal Anda. Untuk petunjuk terperinci tentang mengaktifkan MTL pada distribusi Anda, lihat. [Aktifkan TLS timbal balik untuk distribusi CloudFront](enable-mtls-distributions.md)

# Aktifkan TLS timbal balik untuk distribusi CloudFront
<a name="enable-mtls-distributions"></a>

## Prasyarat dan persyaratan
<a name="mtls-prerequisites-requirements"></a>

CloudFrontMode verifikasi TLS timbal balik mengharuskan semua klien untuk menunjukkan sertifikat yang valid selama jabat tangan TLS dan menolak koneksi tanpa sertifikat yang valid. Sebelum mengaktifkan TLS timbal balik pada CloudFront distribusi, pastikan Anda memiliki:
+ Membuat toko kepercayaan dengan sertifikat Otoritas Sertifikat Anda
+ Mengaitkan toko kepercayaan dengan CloudFront distribusi Anda
+ Memastikan semua perilaku cache distribusi menggunakan kebijakan protokol penampil khusus HTTP
+ Memastikan distribusi Anda menggunakan HTTP/2 (pengaturan default, MTL Viewer tidak didukung pada HTTP/3)

**catatan**  
Otentikasi TLS timbal balik memerlukan koneksi HTTPS antara pemirsa dan. CloudFront Anda tidak dapat mengaktifkan mTL pada distribusi dengan perilaku cache apa pun yang mendukung koneksi HTTP.

## Aktifkan TLS timbal balik (Konsol)
<a name="enable-mtls-console"></a>

### Untuk distribusi baru
<a name="enable-mtls-new-distributions"></a>

MTL penampil tidak dapat dikonfigurasi dalam proses pembuatan distribusi baru di CloudFront konsol. Pertama buat distribusi dengan cara apa pun (konsol, CLI, API), lalu edit pengaturan distribusi untuk mengaktifkan mTL Penampil sesuai instruksi distribusi yang ada di bawah ini.

### Untuk distribusi yang ada
<a name="enable-mtls-existing-distributions"></a>

1. Masuk ke Konsol Manajemen AWS dan buka CloudFront konsol di[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Dari daftar distribusi, pilih distribusi yang ingin Anda ubah.

1. Pastikan kebijakan protokol Viewer disetel ke **Redirect HTTP ke HTTPS atau HTTPS** **Only** untuk semua perilaku cache. (Anda dapat memilih tab **Perilaku cache** untuk melihat dan memperbarui perilaku cache apa pun dengan kebijakan protokol HTTP.)

1. Pilih tab **Umum**.

1. Di bagian **Pengaturan**, pilih **Edit**.

1. Di bagian **Konektivitas**, temukan **otentikasi bersama Viewer (mTLS**).

1. Alihkan **Aktifkan otentikasi timbal balik** ke Aktif.

1. Untuk **mode validasi sertifikat Klien**, pilih **Diperlukan** (semua klien harus menunjukkan sertifikat) atau **Opsional** (klien dapat menyajikan sertifikat secara opsional).

1. Untuk **toko Trust**, pilih toko kepercayaan yang Anda buat sebelumnya.

1. (Opsional) Alihkan **Iklan nama CA toko kepercayaan jika Anda ingin mengirim nama** CA CloudFront ke klien selama jabat tangan TLS.

1. (Opsional) Alihkan **Abaikan tanggal kedaluwarsa sertifikat** jika Anda ingin mengizinkan koneksi dengan sertifikat kedaluwarsa.

1. Pilih **Simpan perubahan**.

## Aktifkan TLS timbal balik (AWS CLI)
<a name="enable-mtls-cli"></a>

### Untuk distribusi baru
<a name="enable-mtls-cli-new"></a>

Contoh berikut menunjukkan cara membuat file konfigurasi distribusi (distribution-config.json) yang menyertakan pengaturan mTLS:

```
{
  "CallerReference": "cli-example-1",
  "Origins": {
    "Quantity": 1,
    "Items": [
      {
        "Id": "my-origin",
        "DomainName": "example.com",
        "CustomOriginConfig": {
          "HTTPPort": 80,
          "HTTPSPort": 443,
          "OriginProtocolPolicy": "https-only"
        }
      }
    ]
  },
  "DefaultCacheBehavior": {
    "TargetOriginId": "my-origin",
    "ViewerProtocolPolicy": "https-only",
    "MinTTL": 0,
    "ForwardedValues": {
      "QueryString": false,
      "Cookies": {
        "Forward": "none"
      }
    }
  },
  "ViewerCertificate": {
    "CloudFrontDefaultCertificate": true
  },
  "ViewerMtlsConfig": {
    "Mode": "required", 
    "TrustStoreConfig": {
        "TrustStoreId": {TRUST_STORE_ID},
        "AdvertiseTrustStoreCaNames": true,
        "IgnoreCertificateExpiry": true
    }
  },
  "Enabled": true
}
```

Buat distribusi dengan mTL diaktifkan menggunakan perintah contoh berikut:

```
aws cloudfront create-distribution --distribution-config file://distribution-config.json
```

### Untuk distribusi yang ada
<a name="enable-mtls-cli-existing"></a>

Dapatkan konfigurasi distribusi saat ini menggunakan perintah contoh berikut:

```
aws cloudfront get-distribution-config --id E1A2B3C4D5E6F7 --output json > dist-config.json
```

Edit file untuk menambahkan pengaturan mTLS. Tambahkan bagian contoh berikut ke konfigurasi distribusi Anda:

```
"ViewerMtlsConfig": {
    "Mode": "required", 
    "TrustStoreConfig": {
        "TrustStoreId": {TRUST_STORE_ID},
        "AdvertiseTrustStoreCaNames": true,
        "IgnoreCertificateExpiry": true
    }
}
```

Hapus ETag bidang dari file tetapi simpan nilainya secara terpisah.

Perbarui distribusi dengan konfigurasi baru menggunakan perintah contoh berikut:

```
aws cloudfront update-distribution \
    --id E1A2B3C4D5E6F7 \
    --if-match YOUR-ETAG-VALUE \
    --distribution-config file://dist-config.json
```

## Kebijakan protokol penampil
<a name="viewer-protocol-policies"></a>

Saat menggunakan TLS timbal balik, semua perilaku cache distribusi harus dikonfigurasi dengan kebijakan protokol penampil khusus HTTP:
+ **Redirect HTTP ke HTTPS** - Mengalihkan permintaan HTTP ke HTTPS sebelum melakukan validasi sertifikat.
+ **Hanya HTTPS** - Hanya menerima permintaan HTTPS dan melakukan validasi sertifikat.

**catatan**  
Kebijakan protokol penampil HTTP dan HTTPS tidak didukung dengan TLS timbal balik karena koneksi HTTP tidak dapat melakukan validasi sertifikat.

## Langkah selanjutnya
<a name="enable-mtls-next-steps"></a>

Setelah mengaktifkan Viewer TLS pada CloudFront distribusi Anda, Anda dapat mengaitkan Fungsi Koneksi untuk menerapkan logika validasi sertifikat kustom. Fungsi Koneksi memungkinkan Anda untuk memperluas kemampuan otentikasi mTLS bawaan dengan aturan validasi kustom, pemeriksaan pencabutan sertifikat, dan pencatatan. Untuk detail tentang membuat dan mengaitkan Fungsi Koneksi, lihat[Kaitkan Fungsi CloudFront Koneksi](connection-functions.md).

# Kaitkan Fungsi CloudFront Koneksi
<a name="connection-functions"></a>

CloudFront Fungsi Koneksi memungkinkan Anda menerapkan logika validasi sertifikat kustom selama jabat tangan TLS, menyediakan ekstensi ke kemampuan otentikasi mTLS bawaan.

## Apa itu Fungsi Koneksi?
<a name="what-are-connection-functions"></a>

Fungsi Koneksi adalah JavaScript fungsi yang berjalan selama jabat tangan TLS setelah sertifikat klien divalidasi. Sertifikat klien yang divalidasi diteruskan ke Fungsi Koneksi di mana Fungsi Koneksi dapat membuat penentuan tambahan apakah akan memberikan akses atau tidak. Untuk informasi rinci tentang Fungsi Koneksi, lihat[Sesuaikan di tepi dengan CloudFront Fungsi](cloudfront-functions.md).

## Bagaimana Fungsi Koneksi bekerja dengan mTL
<a name="how-connection-functions-work"></a>

Ketika klien mencoba membuat koneksi mTLS ke CloudFront distribusi Anda, urutan berikut terjadi:

1. Klien memulai jabat tangan TLS dengan CloudFront lokasi tepi.

1. CloudFront meminta dan menerima sertifikat klien.

1. CloudFront melakukan validasi sertifikat standar terhadap trust store.

1. Jika sertifikat melewati validasi standar, CloudFront memanggil Fungsi Koneksi Anda. Jika **IgnoreCertificateExpiry**diaktifkan di dalam Anda **ViewerMtlsConfig**, maka sertifikat Anda yang kedaluwarsa—tetapi valid—juga diteruskan ke Fungsi Sambungan. Jika sertifikat klien tidak valid, Fungsi Koneksi tidak akan dipanggil.

1. Fungsi Koneksi Anda menerima informasi sertifikat dan detail koneksi yang diuraikan.

1. Fungsi Anda membuat allow/deny keputusan berdasarkan logika kustom.

1. CloudFront menyelesaikan atau mengakhiri koneksi TLS berdasarkan keputusan Anda.

Fungsi Koneksi dipanggil untuk mode verifikasi dan mode opsional (saat klien menyajikan sertifikat).

## Buat Fungsi Koneksi
<a name="create-connection-function"></a>

Anda dapat membuat Fungsi Koneksi menggunakan CloudFront konsol atau AWS CLI.

### Untuk membuat Fungsi Koneksi (Konsol)
<a name="create-connection-function-console"></a>

1. Masuk ke Konsol Manajemen AWS dan buka CloudFront konsol di[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Di panel navigasi, pilih **Fungsi**.

1. Pilih tab **Fungsi Koneksi** dan pilih **Buat Fungsi Koneksi**.

1. Masukkan nama fungsi yang unik di dalam AWS akun Anda.

1. Pilih **Lanjutkan**.

1. Di editor fungsi, tulis JavaScript kode Anda untuk validasi sertifikat. Penangan fungsi harus memanggil allow atau deny.

1. Opsional: KeyValue toko dapat dikaitkan dengan Fungsi Koneksi untuk mengimplementasikan kontrol pencabutan.

1. Pilih **Simpan perubahan**.

### Untuk membuat Fungsi Koneksi (AWS CLI)
<a name="create-connection-function-cli"></a>

Contoh berikut menunjukkan cara membuat Fungsi Koneksi:

Tulis kode fungsi Anda dalam file terpisah, misalnya code.js:

```
function connectionHandler(connection) {
  connection.allow();
}
```

```
aws cloudfront create-connection-function \
  --name "certificate-validator" \
  --connection-function-config '{
      "Comment": "Client certificate validation function",
      "Runtime": "cloudfront-js-2.0"
  }' \
  --connection-function-code fileb://code.js
```

## Struktur kode Fungsi Koneksi
<a name="connection-function-code-structure"></a>

Fungsi Koneksi mengimplementasikan fungsi ConnectionHandler yang menerima objek koneksi yang berisi sertifikat dan informasi koneksi. Fungsi Anda harus menggunakan salah satu `connection.allow()` atau `connection.deny()` untuk membuat keputusan tentang koneksi.

### Contoh Fungsi Koneksi Dasar
<a name="basic-connection-function-example"></a>

Contoh berikut menunjukkan Fungsi Koneksi sederhana yang memverifikasi bidang subjek sertifikat klien:

```
function connectionHandler(connection) {
    // Only process if a certificate was presented
    if (!connection.clientCertificate) {
        console.log("No certificate presented");
        connection.deny();
    }
    
    // Check the subject field for specific organization
    const subject = connection.clientCertificate.certificates.leaf.subject;
    if (!subject.includes("O=ExampleCorp")) {
        console.log("Certificate not from authorized organization");
       connection.deny();
    } else {
        // All checks passed
        console.log("Certificate validation passed");
        connection.allow();
    }
}
```

Spesifikasi lengkap properti sertifikat klien yang tersedia pada objek koneksi tersedia di sini:

```
{
  "connectionId": "Fdb-Eb7L9gVn2cFakz7wWyBJIDAD4-oNO6g8r3vXDV132BtnIVtqDA==", // Unique identifier for this TLS connection
  "clientIp": "203.0.113.42", // IP address of the connecting client (IPv4 or IPv6)
  "clientCertificate": {
    "certificates": {
      "leaf": {
        "subject": "CN=client.example.com,O=Example Corp,C=US", // Distinguished Name (DN) of the certificate holder
        "issuer": "CN=Example Corp Intermediate CA,O=Example Corp,C=US", // Distinguished Name (DN) of the certificate authority that issued this certificate
        "serialNumber": "4a:3f:5c:92:d1:e8:7b:6c", // Unique serial number assigned by the issuing CA (hexadecimal)
        "validity": {
          "notBefore": "2024-01-15T00:00:00Z", // Certificate validity start date (ISO 8601 format)
          "notAfter": "2025-01-14T23:59:59Z"   // Certificate expiration date (ISO 8601 format)
        },
        "sha256Fingerprint": "a1b2c3d4e5f6...abc123def456", // SHA-256 hash of the certificate (64 hex characters)
      },
    },
  },
}
```

## Kaitkan Fungsi Koneksi
<a name="associate-connection-function-section"></a>

Setelah membuat Fungsi Koneksi Anda, Anda harus mempublikasikannya ke tahap LIVE dan mengaitkannya dengan distribusi Anda.

### Untuk memublikasikan dan mengaitkan Fungsi Koneksi (Konsol)
<a name="publish-associate-console"></a>

1. Masuk ke Konsol Manajemen AWS dan buka CloudFront konsol di[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. **Di panel navigasi, pilih Fungsi**

1. Pilih tab **Fungsi Koneksi** dan pilih Fungsi Koneksi Anda.

1. Pilih **Publikasikan** untuk memindahkannya ke panggung LIVE.

1. Pilih **Tambahkan asosiasi** dalam tabel distribusi terkait di bawah bagian penerbitan.

1. Pilih distribusi dengan mTL Penampil yang diaktifkan yang ingin Anda kaitkan.

Fungsi Koneksi yang dipublikasikan secara alternatif juga dapat dikaitkan dari halaman detail distribusi.

1. Arahkan ke halaman beranda konsol tempat semua distribusi Anda terdaftar.

1. Pilih distribusi yang ingin Anda kaitkan.

1. Pilih tab **Umum**.

1. Di bagian **Pengaturan**, pilih **Edit**.

1. Di bagian **Konektivitas**, temukan **otentikasi bersama Viewer (mTLS**).

1. Untuk **Fungsi Koneksi**, pilih fungsi Anda.

1. Pilih **Simpan perubahan**.

### Untuk mengaitkan Fungsi Koneksi (AWS CLI)
<a name="associate-connection-function-cli"></a>

Contoh berikut menunjukkan bagaimana mengaitkan Fungsi Koneksi dengan distribusi:

```
// DistributionConfig:
{
   ...other settings,
    "ConnectionFunctionAssociation": {
        "Id": "cf_30c2CV2elHwCoInb3LtcaUJkZeD"
    }
}
```

## Kasus penggunaan untuk Fungsi Koneksi
<a name="connection-function-use-cases"></a>

Fungsi Koneksi memungkinkan beberapa kasus penggunaan mTL tingkat lanjut:
+ **Validasi atribut sertifikat** - Verifikasi bidang tertentu dalam sertifikat klien seperti persyaratan unit organisasi atau pola nama alternatif subjek.
+ Pemeriksaan **pencabutan sertifikat - Menerapkan pemeriksaan** pencabutan sertifikat khusus menggunakan KeyValueStore untuk menyimpan nomor seri sertifikat yang dicabut.
+ **Kebijakan sertifikat berbasis IP** - Menerapkan kebijakan sertifikat yang berbeda berdasarkan alamat IP klien atau batasan geografis.
+ **Validasi multi-penyewa - Menerapkan aturan validasi** khusus penyewa di mana persyaratan sertifikat yang berbeda berlaku berdasarkan nama host atau atribut sertifikat.

**catatan**  
Fungsi Koneksi berjalan sekali per koneksi klien selama jabat tangan TLS.  
Fungsi Koneksi hanya dapat mengizinkan atau menolak koneksi, tidak mengubah permintaan/tanggapan HTTP.  
Hanya fungsi panggung LIVE (diterbitkan) yang dapat dikaitkan dengan distribusi.  
Setiap distribusi dapat memiliki paling banyak satu Fungsi Koneksi.

## Langkah selanjutnya
<a name="connection-function-next-steps"></a>

Setelah mengaitkan Fungsi Sambungan dengan CloudFront distribusi Anda, Anda dapat mengonfigurasi pengaturan opsional untuk menyesuaikan perilaku implementasi mTLS Anda. Untuk petunjuk terperinci tentang mengonfigurasi pengaturan tambahan seperti mode validasi sertifikat klien opsional, lihat. [Mengkonfigurasi pengaturan tambahan](configuring-additional-settings.md)

# Mengkonfigurasi pengaturan tambahan
<a name="configuring-additional-settings"></a>

Setelah mengaktifkan otentikasi TLS timbal balik dasar, Anda dapat mengonfigurasi pengaturan tambahan untuk menyesuaikan perilaku otentikasi untuk kasus dan persyaratan penggunaan tertentu.

## Validasi sertifikat klien Mode opsional
<a name="optional-mode"></a>

CloudFront menawarkan alternatif mode validasi sertifikat klien opsional yang memvalidasi sertifikat klien yang disajikan tetapi memungkinkan akses ke klien yang tidak menunjukkan sertifikat.

### Perilaku mode opsional
<a name="optional-mode-behavior"></a>
+ Memberikan koneksi ke klien dengan sertifikat yang valid, (sertifikat tidak valid ditolak).
+ Memungkinkan koneksi ke klien tanpa sertifikat
+ Memungkinkan skenario otentikasi klien campuran melalui distribusi tunggal.

Mode opsional sangat ideal untuk migrasi bertahap ke otentikasi mTLS, mendukung klien dengan sertifikat dan klien tanpa sertifikat, atau mempertahankan kompatibilitas mundur dengan klien lama.

**catatan**  
Dalam mode opsional, Fungsi Koneksi masih dipanggil bahkan ketika klien tidak menunjukkan sertifikat. Hal ini memungkinkan Anda untuk menerapkan logika kustom seperti mencatat alamat IP klien atau menerapkan kebijakan yang berbeda berdasarkan apakah sertifikat disajikan.

### Untuk mengkonfigurasi mode opsional (Konsol)
<a name="configure-optional-mode-console"></a>

1. Di pengaturan distribusi Anda, navigasikan ke tab **Umum**, pilih **Edit**.

1. Gulir ke bagian Authentication **Mutual Authentication (mTLS) Viewer** dalam wadah **Konektivitas**.

1. Untuk **mode validasi sertifikat Klien**, pilih **Opsional**.

1. Simpan perubahan.

### Untuk mengkonfigurasi mode opsional (AWS CLI)
<a name="configure-optional-mode-cli"></a>

Contoh berikut menunjukkan cara mengkonfigurasi mode opsional:

```
"ViewerMtlsConfig": {
   "Mode": "optional",
   ...other settings
}
```

## Iklan Otoritas Sertifikat
<a name="ca-advertisement"></a>

 AdvertiseTrustStoreCaNames Bidang mengontrol apakah CloudFront mengirimkan daftar nama CA tepercaya ke klien selama jabat tangan TLS, membantu klien memilih sertifikat yang sesuai.

### Untuk mengonfigurasi iklan CA (Konsol)
<a name="configure-ca-advertisement-console"></a>

1. Di pengaturan distribusi Anda, navigasikan ke tab **Umum**, pilih **Edit**.

1. Gulir ke bagian Authentication **Mutual Authentication (mTLS) Viewer** dalam wadah **Konektivitas**.

1. Pilih atau hapus centang kotak **centang Iklankan nama CA toko kepercayaan**.

1. Pilih **Simpan perubahan**.

### Untuk mengkonfigurasi iklan CA (AWS CLI)
<a name="configure-ca-advertisement-cli"></a>

Contoh berikut menunjukkan cara mengaktifkan iklan CA:

```
"ViewerMtlsConfig": {
   "Mode": "required", // or "optional"
   "TrustStoreConfig": {
      "AdvertiseTrustStoreCaNames": true,
      ...other settings
   } 
}
```

## Penanganan kedaluwarsa sertifikat
<a name="certificate-expiration-handling"></a>

 IgnoreCertificateExpiry Properti menentukan bagaimana CloudFront menanggapi sertifikat klien yang kedaluwarsa. Secara default, CloudFront menolak sertifikat klien yang kedaluwarsa, tetapi Anda dapat mengonfigurasinya untuk menerimanya bila perlu. Ini biasanya diaktifkan untuk perangkat dengan sertifikat kedaluwarsa yang tidak dapat diperbarui dengan mudah.

### Untuk mengonfigurasi penanganan kedaluwarsa sertifikat (Konsol)
<a name="configure-expiration-console"></a>

1. Di pengaturan distribusi Anda, navigasikan ke tab **Umum**, pilih **Edit**.

1. Gulir ke bagian **Viewer mutual authentication (mTLS)** dari **Connectivity** container.

1. Pilih atau batalkan pilihan kotak centang **Abaikan tanggal kedaluwarsa sertifikat**.

1. Pilih **Simpan perubahan**.

### Untuk mengonfigurasi penanganan kedaluwarsa sertifikat (CLI AWS )
<a name="configure-expiration-cli"></a>

Contoh berikut menunjukkan cara mengabaikan kedaluwarsa sertifikat:

```
"ViewerMtlsConfig": {
  "Mode": "required", // or "optional"
  "TrustStoreConfig": {
     "IgnoreCertificateExpiry": false,
     ...other settings
  }
}
```

**catatan**  
**IgnoreCertificateExpiry**hanya berlaku untuk tanggal validitas sertifikat. Semua pemeriksaan validasi sertifikat lainnya masih berlaku (rantai kepercayaan, validasi tanda tangan).

## Langkah selanjutnya
<a name="additional-settings-next-steps"></a>

Setelah mengonfigurasi pengaturan tambahan, Anda dapat mengatur penerusan header untuk meneruskan informasi sertifikat ke asal Anda, menerapkan pencabutan sertifikat menggunakan Fungsi Koneksi dan KeyValueStore, dan mengaktifkan log koneksi untuk pemantauan. Untuk detail tentang meneruskan informasi sertifikat ke asal, lihat [Teruskan Header ke](viewer-mtls-headers.md) asal.

# Header mTLS penampil untuk kebijakan cache dan diteruskan ke asal
<a name="viewer-mtls-headers"></a>

Saat menggunakan otentikasi TLS timbal balik, CloudFront dapat mengekstrak informasi dari sertifikat klien dan meneruskannya ke asal Anda sebagai header HTTP. Ini memungkinkan server asal Anda untuk mengakses detail sertifikat tanpa menerapkan logika validasi sertifikat.

Header berikut tersedia untuk membuat perilaku cache:


| Nama header | Deskripsi | Nilai contoh | 
| --- | --- | --- | 
| CloudFront-Pemirsa Seri-Seri-Nomor | Representasi heksadesimal dari nomor seri sertifikat | 4a: 3f: 5c: 92: d1: e 8:7 b: 6c | 
| CloudFront-Viewer-Cert-Penerbit | RFC2253 representasi string dari nama terhormat penerbit (DN) | cn = Rootcamtls.com, OU = Rootca, O = MTLS, L = Seattle, ST = Washington, C = AS | 
| CloudFront-Pemirsa-Cert-Subjek | RFC2253 representasi string dari nama terhormat subjek (DN) | cn=client\$1.com, OU = klien-3, O = MTLS, ST = Washington, C = AS | 
| CloudFront-Pemirsa-Sertifikat-Hadir | Baik 1 (sekarang) atau 0 (tidak ada) yang menunjukkan apakah sertifikat tersebut ada. Nilai ini selalu 1 dalam mode Wajib. | 1 | 
| CloudFront-Pemirsa-Sert-Sha256 |  SHA256 Hash dari sertifikat klien | 01fbf94fef5569753420c349f49adbfd80af5275377816e3ab1fb371b29cb586 | 

Untuk permintaan asal, dua header tambahan disediakan, selain header di atas yang tersedia untuk perilaku cache. Karena potensi ukuran header, CloudFront-Viewer-Cert-Pem header tidak terkena fungsi tepi (Lambda @Edge atau CloudFront Functions) dan hanya diteruskan ke asal.


| Nama header | Deskripsi | Nilai contoh | 
| --- | --- | --- | 
| CloudFront-Viewer-Cert-Validitas | ISO8601 format tanggal NotBefore dan NotAfter | CloudFront-Viewer-Cert-Validitas: = 2023-09-21T 01:50:17 Z; = 2024-09-20T 01:50:17 Z NotBefore NotAfter | 
| CloudFront-Pemirsa-Sert-Pem | Format PEM yang dikodekan URL dari sertifikat daun | CloudFront-Viewer-Cert-Pem: -----MULAI% 20SERTIFIKAT ----- %0AMIIG<... dikurangi... > NmrUlw %0A ----- AKHIR%20SERTIFIKAT ----- %0A | 

## Konfigurasikan penerusan header
<a name="configure-header-forwarding"></a>

### Konsol
<a name="configure-headers-console"></a>

Dalam mode verifikasi, CloudFront secara otomatis menambahkan header CloudFront-Viewer-Cert -\$1 ke semua permintaan penampil. Untuk meneruskan header ini ke asal Anda:

1. **Dari halaman distribusi daftar utama, pilih distribusi Anda dengan mTL penampil diaktifkan dan buka tab Perilaku**

1. Pilih perilaku cache dan pilih **Edit**

1. Di bagian **Kebijakan permintaan asal**, pilih **Buat kebijakan** atau pilih kebijakan yang ada

1. Pastikan header berikut disertakan dalam kebijakan permintaan asal:
   + CloudFront-Pemirsa Seri-Seri-Nomor
   + CloudFront-Viewer-Cert-Penerbit
   + CloudFront-Pemirsa-Cert-Subjek
   + CloudFront-Pemirsa-Sertifikat-Hadir
   + Cloudfront-Viewer-Cert-Sha256
   + CloudFront-Viewer-Cert-Validitas
   + CloudFront-Pemirsa-Sert-Pem

1. Pilih **Buat** (untuk kebijakan baru) atau **Simpan perubahan** (untuk kebijakan yang ada)

1. Pilih kebijakan dalam perilaku cache Anda dan simpan perubahan

### Menggunakan AWS CLI
<a name="configure-headers-cli"></a>

Contoh berikut menunjukkan cara membuat kebijakan permintaan asal yang menyertakan header mTLS untuk mode verifikasi:

```
aws cloudfront create-origin-request-policy \
  --origin-request-policy-config '{
    "Name": "MTLSHeadersPolicy",
    "HeadersConfig": {
      "HeaderBehavior": "whitelist",
      "Headers": {
        "Quantity": 5,
        "Items": [
          "CloudFront-Viewer-Cert-Serial-Number",
          "CloudFront-Viewer-Cert-Issuer",
          "CloudFront-Viewer-Cert-Subject",
          "CloudFront-Viewer-Cert-Validity",
          "CloudFront-Viewer-Cert-Pem"
        ]
      }
    },
    "CookiesConfig": {
      "CookieBehavior": "none"
    },
    "QueryStringsConfig": {
      "QueryStringBehavior": "none"
    }
  }'
```

## Pertimbangan pemrosesan header
<a name="header-processing-considerations"></a>

Saat bekerja dengan header sertifikat, pertimbangkan praktik terbaik ini:
+ **Validasi header:** Verifikasi nilai header sertifikat di asal Anda sebagai langkah keamanan tambahan
+ **Batas ukuran header:** Header sertifikat PEM bisa besar, pastikan server asal Anda dapat menanganinya
+ **Pertimbangan cache:** Menggunakan header sertifikat di kunci cache Anda meningkatkan fragmentasi cache
+ **Permintaan lintas asal:** Jika aplikasi Anda menggunakan CORS, Anda mungkin perlu mengonfigurasinya untuk mengizinkan header sertifikat

## Langkah selanjutnya
<a name="headers-next-steps"></a>

Setelah mengonfigurasi penerusan header, Anda dapat menerapkan pemeriksaan pencabutan sertifikat menggunakan Fungsi Koneksi dan. CloudFront KeyValueStore Untuk detail tentang penerapan pemeriksaan pencabutan, lihat. [Pencabutan menggunakan Fungsi CloudFront Koneksi dan KVS](revocation-connection-function-kvs.md)

# Pencabutan menggunakan Fungsi CloudFront Koneksi dan KVS
<a name="revocation-connection-function-kvs"></a>

Anda dapat menerapkan pemeriksaan pencabutan sertifikat untuk otentikasi TLS timbal balik dengan menggabungkan CloudFront Fungsi Koneksi dengan. KeyValueStore Pendekatan ini menyediakan mekanisme pencabutan sertifikat real-time yang dapat diskalakan yang melengkapi validasi sertifikat bawaan CloudFront.

Fungsi Koneksi adalah JavaScript fungsi yang berjalan selama pembentukan koneksi TLS di lokasi CloudFront tepi dan memungkinkan Anda menerapkan logika validasi sertifikat khusus untuk otentikasi mTLS. Untuk informasi rinci tentang Fungsi Koneksi, lihat[Kaitkan Fungsi CloudFront Koneksi](connection-functions.md).

## Cara kerja pencabutan sertifikat dengan Fungsi Koneksi
<a name="how-revocation-works"></a>

CloudFrontvalidasi sertifikat standar memverifikasi rantai sertifikat, tanda tangan, dan kedaluwarsa tetapi tidak termasuk pemeriksaan pencabutan sertifikat bawaan. Dengan menggunakan Fungsi Koneksi, Anda dapat menerapkan pemeriksaan pencabutan kustom selama jabat tangan TLS.

Proses pencabutan sertifikat berfungsi sebagai berikut:

1. Simpan nomor seri sertifikat yang telah dicabut di file. CloudFront KeyValueStore

1. Ketika klien menyajikan sertifikat, Fungsi Koneksi Anda dipanggil.

1. Fungsi memeriksa nomor seri sertifikat terhadap KeyValueStore.

1. Jika nomor seri ditemukan di toko, sertifikat dicabut.

1. Fungsi Anda menolak koneksi untuk sertifikat yang dicabut.

Pendekatan ini menyediakan pemeriksaan near-real-time pencabutan di seluruh jaringan CloudFront edge global.

## Siapkan KeyValueStore untuk sertifikat yang dicabut
<a name="setup-kvs-revoked-certs"></a>

Pertama, buat a KeyValueStore untuk menyimpan nomor seri sertifikat yang dicabut:

### Untuk membuat KeyValueStore (Konsol)
<a name="create-kvs-console"></a>

1. Masuk ke Konsol Manajemen AWS dan buka CloudFront konsol di[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Di panel navigasi, pilih **Key value stores**.

1. Pilih **Buat toko nilai kunci**.

1. Masukkan nama untuk penyimpanan nilai kunci Anda (misalnya, sertifikat yang dicabut).

1. (Opsional) Tambahkan deskripsi.

1. Pilih **Buat toko nilai kunci**.

### Untuk membuat KeyValueStore (AWS CLI)
<a name="create-kvs-cli"></a>

Contoh berikut menunjukkan cara membuat KeyValueStore:

```
aws cloudfront create-key-value-store \
  --name "revoked-certificates" \
  --comment "Store for revoked certificate serial numbers"
```

## Impor nomor seri sertifikat yang dicabut
<a name="import-revoked-serials"></a>

Setelah membuat KeyValueStore, Anda perlu mengimpor nomor seri sertifikat yang dicabut:

### Siapkan data pencabutan
<a name="prepare-revocation-data"></a>

Buat file JSON dengan nomor seri sertifikat yang telah dicabut:

```
{
  "data": [
    {
      "key": "ABC123DEF456",
      "value": ""
    },
    {
      "key": "789XYZ012GHI",
      "value": ""
    }
  ]
}
```

### Impor dari S3
<a name="import-from-s3"></a>

1. Unggah file JSON ke bucket S3

1. Impor file ke KeyValueStore:

   ```
   aws cloudfront create-key-value-store \
     --name "revoked-certificates" \
     --import-source '{
       "SourceType": "S3",
       "SourceARN": "arn:aws:s3:::amzn-s3-demo-bucket1/revoked-serials.json"
     }'
   ```

## Buat Fungsi Koneksi untuk pemeriksaan pencabutan
<a name="create-revocation-connection-function"></a>

Buat Fungsi Koneksi yang memeriksa nomor seri sertifikat terhadap KeyValueStore:

### Contoh kode Fungsi Koneksi
<a name="revocation-function-example"></a>

Contoh berikut menunjukkan Fungsi Koneksi yang melakukan pemeriksaan pencabutan sertifikat:

```
import cf from 'cloudfront';

async function connectionHandler(connection) {
    const kvsHandle = cf.kvs();
    
    // Get client certificate serial number
    const clientSerialNumber = connection.clientCertificate.certificates.leaf.serialNumber;
    
    // Check if the serial number exists in the KeyValueStore
    const isRevoked = await kvsHandle.exists(clientSerialNumber.replaceAll(':', ''));
    
    if (isRevoked) {
        console.log(`Certificate ${clientSerialNumber} is revoked. Denying connection.`);
        connection.logCustomData(`REVOKED:${clientSerialNumber}`);
        connection.deny();
    } else {
        console.log(`Certificate ${clientSerialNumber} is valid. Allowing connection.`);
        connection.allow();
    }
    
}
```

### Untuk membuat Fungsi Koneksi (AWS CLI)
<a name="create-revocation-function-cli"></a>

Contoh berikut menunjukkan cara membuat Fungsi Koneksi dengan KeyValueStore asosiasi:

```
aws cloudfront create-connection-function \
  --name "revocation-checker" \
  --connection-function-config '{
      "Comment": "Certificate revocation checking function",
      "Runtime": "cloudfront-js-2.0",
      "KeyValueStoreAssociations": {
          "Quantity": 1,
          "Items": [
              {
                  "KeyValueStoreARN": "arn:aws:cloudfront::123456789012:key-value-store/revoked-certificates"
              }
          ]
      }
  }' \
  --connection-function-code fileb://revocation-checker.js
```

## Kaitkan fungsi dengan distribusi Anda
<a name="associate-revocation-function"></a>

Setelah membuat dan memublikasikan Fungsi Koneksi Anda, kaitkan dengan CloudFront distribusi berkemampuan MTLS seperti yang dijelaskan di bagian. [Kaitkan Fungsi CloudFront Koneksi](connection-functions.md)

# Observabilitas menggunakan log koneksi
<a name="connection-logs"></a>

CloudFront log koneksi memberikan visibilitas terperinci ke dalam peristiwa otentikasi TLS timbal balik, memungkinkan Anda memantau validasi sertifikat, melacak upaya koneksi, dan memecahkan masalah otentikasi.

## Apa itu log koneksi?
<a name="what-are-connection-logs"></a>

Log koneksi menangkap informasi terperinci tentang jabat tangan TLS dan validasi sertifikat untuk distribusi yang mendukung TLS bersama. Tidak seperti log akses standar yang merekam informasi permintaan HTTP, log koneksi berfokus secara khusus pada fase pembentukan koneksi TLS, termasuk:
+ Status koneksi (sukses/kegagalan)
+ Detail sertifikat klien
+ Protokol TLS dan informasi sandi
+ Metrik waktu koneksi
+ Data kustom dari Fungsi Koneksi

Log ini memberikan visibilitas komprehensif ke dalam peristiwa otentikasi berbasis sertifikat, membantu Anda memantau keamanan, memecahkan masalah, dan memenuhi persyaratan kepatuhan.

## Aktifkan log koneksi
<a name="enable-connection-logs"></a>

Log koneksi hanya tersedia untuk distribusi dengan otentikasi TLS timbal balik diaktifkan. Anda dapat mengirim log koneksi ke beberapa tujuan termasuk CloudWatch Log, Amazon Data Firehose, dan Amazon S3.

### Prasyarat
<a name="connection-logs-prerequisites"></a>

Sebelum mengaktifkan log koneksi:
+ Konfigurasikan TLS timbal balik untuk distribusi Anda CloudFront 
+ Aktifkan log koneksi untuk CloudFront distribusi Anda
+ Pastikan Anda memiliki izin yang diperlukan untuk tujuan pencatatan yang Anda pilih
+ Untuk pengiriman lintas akun, konfigurasikan kebijakan IAM yang sesuai

### Untuk mengaktifkan log koneksi (Konsol)
<a name="enable-connection-logs-console"></a>

1. Masuk ke Konsol Manajemen AWS dan buka CloudFront konsol di[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Dari daftar distribusi, pilih distribusi berkemampuan MTLS Anda.

1. Pilih tab **Logging**.

1. Pilih **Tambahkan**.

1. Pilih layanan untuk menerima log Anda:
   + **CloudWatch Log**
   + **Firehose**
   + **Amazon S3**

1. Untuk **Tujuan**, pilih sumber daya untuk layanan yang Anda pilih:
   + Untuk CloudWatch Log, masukkan **nama grup Log**
   + **Untuk Firehose, pilih aliran pengiriman Firehose**
   + Untuk Amazon S3, masukkan **nama Bucket** (opsional dengan awalan)

1. (Opsional) Konfigurasikan pengaturan tambahan:
   + **Pemilihan bidang:** Pilih bidang log tertentu untuk disertakan.
   + **Format keluaran:** Pilih dari JSON, Plain, w3c, Raw, atau Parket (hanya S3).
   + **Pembatas bidang:** Tentukan cara memisahkan bidang log.

1. Pilih **Save changes (Simpan perubahan)**

### Untuk mengaktifkan log koneksi (AWS CLI)
<a name="enable-connection-logs-cli"></a>

Contoh berikut menunjukkan cara mengaktifkan log koneksi menggunakan CloudWatch API:

```
# Step 1: Create a delivery source
aws logs put-delivery-source \
  --name "cf-mtls-connection-logs" \
  --resource-arn "arn:aws:cloudfront::123456789012:distribution/E1A2B3C4D5E6F7" \
  --log-type CONNECTION_LOGS

# Step 2: Create a delivery destination
aws logs put-delivery-destination \
  --name "s3-destination" \
  --delivery-destination-configuration \
  "destinationResourceArn=arn:aws:s3:::amzn-s3-demo-bucket1"

# Step 3: Create the delivery
aws logs create-delivery \
  --delivery-source-name "cf-mtls-connection-logs" \
  --delivery-destination-arn "arn:aws:logs:us-east-1:123456789012:delivery-destination:s3-destination"
```

**catatan**  
Saat menggunakan CloudWatch API, Anda harus menentukan Wilayah AS Timur (Virginia N.) (us-east-1) bahkan saat mengirimkan log ke wilayah lain.

## Bidang log koneksi
<a name="connection-log-fields"></a>

Log koneksi mencakup informasi terperinci tentang setiap upaya koneksi TLS:


| Bidang | Deskripsi | Contoh | 
| --- | --- | --- | 
| eventTimestamp | Stempel waktu ISO 8601 saat koneksi dibuat atau gagal | 1731620046814 | 
| connectionId | Pengidentifikasi unik untuk koneksi TLS | oLHiEKbQSn8lkvJfA3D4gFowK3\$1iZ0g4i5nMUjE1Akod8TuAzn5nzg== | 
| connectionStatus |  Status upaya koneksi mTLS.  | Success atau Failed | 
| clientIp | Alamat IP dari klien penghubung | 2001:0db8:85a3:0000:0000:8a2e:0370:7334 | 
| clientPort | Port yang digunakan oleh klien | 12137 | 
| serverIp | Alamat IP dari server CloudFront tepi | 99.84.71.136 | 
| distributionId | CloudFront ID distribusi | E2DX1SLDPK0123 | 
| distributionTenantId | CloudFront ID penyewa distribusi (bila berlaku) | dt\$12te1Ura9X3R2iCGNjW123 | 
| tlsProtocol | Versi protokol TLS digunakan | TLSv1.3 | 
| tlsCipher | TLS cipher suite digunakan untuk koneksi | TLS\$1AES\$1128\$1GCM\$1SHA256 | 
| tlsHandshakeDuration | Durasi jabat tangan TLS dalam milidetik | 153 | 
| tlsSni | Nilai Indikasi Nama Server dari jabat tangan TLS | d111111abcdef8.cloudfront.net | 
| clientLeafCertSerialNumber | Nomor seri sertifikat klien | 00:b1:43:ed:93:d2:d8:f3:9d | 
| clientLeafCertSubject | Bidang subjek sertifikat klien | C=US, ST=WA, L=Seattle, O=Amazon.com, OU=CloudFront, CN=client.test.mtls.net | 
| clientLeafCertIssuer | Bidang penerbit sertifikat klien | C=US, ST=WA, L=Seattle, O=Amazon.com, OU=CloudFront, CN=test.mtls.net | 
| clientLeafCertValidity | Masa berlaku sertifikat klien | NotBefore=2025-06-05T23:28:21Z;NotAfter=2125-05-12T23:28:21Z | 
| connectionLogCustomData | Data kustom ditambahkan melalui Fungsi Koneksi | REVOKED:00:b1:43:ed:93:d2:d8:f3:9d | 

## Kode kesalahan koneksi
<a name="connection-error-codes"></a>

```
Failed:ClientCertMaxChainDepthExceeded
Failed:ClientCertMaxSizeExceeded
Failed:ClientCertUntrusted
Failed:ClientCertNotYetValid
Failed:ClientCertExpired
Failed:ClientCertTypeUnsupported
Failed:ClientCertInvalid
Failed:ClientCertIntentInvalid
Failed:ClientCertRejected
Failed:ClientCertMissing
Failed:TcpError
Failed:TcpTimeout
Failed:ConnectionFunctionError
Failed:ConnectionFunctionDenied
Failed:Internal
Failed:UnmappedConnectionError
```

Ketika koneksi gagal, CloudFront mencatat kode alasan tertentu:


| Kode | Deskripsi | 
| --- | --- | 
| ClientCertMaxChainDepthExceeded | Kedalaman rantai sertifikat maksimum terlampaui | 
| ClientCertMaxSizeExceeded | Ukuran sertifikat maksimum terlampaui | 
| ClientCertUntrusted | Sertifikat tidak dipercaya | 
| ClientCertNotYetValid | Sertifikat belum valid | 
| ClientCertExpired | Sertifikat kedaluwarsa | 
| ClientCertTypeUnsupported | Jenis sertifikat tidak didukung | 
| ClientCertInvalid | Sertifikat tidak valid | 
| ClientCertIntentInvalid | Maksud sertifikat tidak valid | 
| ClientCertRejected | Sertifikat ditolak oleh validasi kustom | 
| ClientCertMissing | Sertifikat tidak ada | 
| TcpError |  Terjadi kesalahan saat mencoba membuat koneksi  | 
| TcpTimeout |  Koneksi tidak dapat dibuat dalam periode batas waktu  | 
| ConnectionFunctionError |  Pengecualian yang tidak tertangkap dilemparkan selama eksekusi Fungsi Koneksi  | 
| Internal |  Terjadi kesalahan layanan internal  | 
| UnmappedConnectionError |  Terjadi kesalahan yang tidak termasuk dalam kategori lainnya  | 

# Asal TLS timbal balik dengan CloudFront
<a name="origin-mtls-authentication"></a>

Mutual TLS Authentication (Mutual Transport Layer Security Authentication — mTLS) adalah protokol keamanan yang memperluas otentikasi TLS standar dengan memerlukan otentikasi berbasis sertifikat dua arah, di mana klien dan server harus membuktikan identitas mereka sebelum membuat koneksi yang aman.

## Penampil mTL vs mTL Asal
<a name="viewer-mtls-vs-origin-mtls"></a>

Otentikasi timbal balik (mTL) dapat diaktifkan antara pemirsa dan CloudFront distribusi Anda (mTL penampil) and/or juga antara CloudFront distribusi Anda dan asal (mTL asal). Dokumentasi ini berkaitan dengan konfigurasi mTLS asal. Untuk konfigurasi mTLS penampil lihat:[Otentikasi TLS timbal balik dengan CloudFront (Viewer mTLS)Asal TLS timbal balik dengan CloudFront](mtls-authentication.md).

Origin mTLS memungkinkan CloudFront untuk mengautentikasi dirinya ke server asal Anda menggunakan sertifikat klien. Dengan mTL asal, Anda dapat memastikan bahwa hanya CloudFront distribusi resmi Anda yang dapat membuat koneksi dengan server aplikasi Anda, membantu melindungi dari upaya akses yang tidak sah.

**catatan**  
Dalam koneksi mTLS asal, CloudFront bertindak sebagai klien dan menyajikan sertifikat kliennya ke server asal Anda selama jabat tangan TLS. CloudFront tidak melakukan validasi validitas atau status pencabutan sertifikat klien — ini adalah tanggung jawab server asal Anda. Infrastruktur asal Anda harus dikonfigurasi untuk memvalidasi sertifikat klien terhadap trust store, memeriksa kedaluwarsa sertifikat, dan melakukan pemeriksaan pencabutan (seperti validasi CRL atau OCSP) sesuai dengan persyaratan keamanan Anda. CloudFrontPeran terbatas pada penyajian sertifikat; semua logika validasi sertifikat dan kebijakan keamanan diberlakukan oleh server asal Anda.

## Cara kerjanya
<a name="how-origin-mtls-works"></a>

Dalam jabat tangan TLS standar antara CloudFront dan asal, hanya server asal yang menyajikan sertifikat untuk membuktikan identitasnya. CloudFront Dengan mTL asal, proses otentikasi menjadi dua arah. Saat CloudFront mencoba terhubung ke server asal Anda, berikan CloudFront sertifikat klien selama jabat tangan TLS. Server asal Anda memvalidasi sertifikat ini terhadap trust store sebelum membuat koneksi aman.

## Kasus penggunaan
<a name="origin-mtls-use-cases"></a>

Origin mTLS membahas beberapa skenario keamanan kritis di mana metode otentikasi tradisional membuat overhead operasional:
+ **Keamanan hybrid dan multi-cloud** - Anda dapat mengamankan koneksi antara CloudFront dan asal-usul yang dihosting di luar AWS atau asal publik. AWS Ini menghilangkan kebutuhan untuk mengelola daftar izin IP atau solusi header khusus, menyediakan otentikasi berbasis sertifikat yang konsisten di seluruh AWS, pusat data lokal, dan penyedia pihak ketiga. Perusahaan media, pengecer, dan perusahaan yang mengoperasikan infrastruktur terdistribusi mendapat manfaat dari kontrol keamanan standar di seluruh infrastruktur mereka.
+ **B2B API dan keamanan backend** - Anda dapat melindungi backend APIs dan layanan mikro Anda dari upaya akses langsung sambil mempertahankan manfaat kinerja. CloudFront Platform SaaS, sistem pemrosesan pembayaran, dan aplikasi perusahaan dengan persyaratan otentikasi yang ketat dapat memverifikasi bahwa permintaan API hanya berasal dari CloudFront distribusi resmi, mencegah man-in-the-middle serangan dan upaya akses yang tidak sah.

## Penting: Persyaratan Server Asal
<a name="important-origin-server-requirements"></a>

Origin mTLS mengharuskan server asal Anda dikonfigurasi untuk mendukung otentikasi TLS timbal balik. Infrastruktur asal Anda harus mampu:
+ Meminta dan memvalidasi sertifikat klien selama jabat tangan TLS
+ Mempertahankan toko kepercayaan dengan sertifikat Otoritas Sertifikat yang mengeluarkan sertifikat CloudFront klien
+ Pencatatan dan pemantauan peristiwa koneksi TLS timbal balik
+ Mengelola kebijakan validasi sertifikat dan menangani kegagalan otentikasi

CloudFront menangani presentasi sertifikat sisi klien, tetapi server asal Anda bertanggung jawab untuk memvalidasi sertifikat ini dan mengelola koneksi TLS bersama. Pastikan infrastruktur asal Anda dikonfigurasi dengan benar sebelum mengaktifkan mTL asal. CloudFront

## Memulai
<a name="how-origin-mtls-getting-started"></a>

Untuk mengimplementasikan mTL asal CloudFront, Anda harus mengimpor sertifikat klien di AWS Certificate Manager, mengonfigurasi server asal Anda agar memerlukan TLS bersama, dan mengaktifkan mTL asal pada distribusi Anda. CloudFront Bagian berikut memberikan step-by-step instruksi untuk setiap tugas konfigurasi.

**Topics**
+ [Penampil mTL vs mTL Asal](#viewer-mtls-vs-origin-mtls)
+ [Cara kerjanya](#how-origin-mtls-works)
+ [Kasus penggunaan](#origin-mtls-use-cases)
+ [Penting: Persyaratan Server Asal](#important-origin-server-requirements)
+ [Memulai](#how-origin-mtls-getting-started)
+ [Manajemen sertifikat dengan AWS Certificate Manager](origin-certificate-management-certificate-manager.md)
+ [Aktifkan TLS timbal balik asal untuk distribusi CloudFront](origin-enable-mtls-distributions.md)
+ [Menggunakan CloudFront Fungsi dengan TLS timbal balik asal](origin-mtls-cloudfront-functions.md)

# Manajemen sertifikat dengan AWS Certificate Manager
<a name="origin-certificate-management-certificate-manager"></a>

[AWS Certificate Manager (ACM)](https://aws.amazon.com/certificate-manager/) menyimpan sertifikat klien yang CloudFront ditampilkan ke server asal Anda selama otentikasi TLS timbal balik asal.

## Dukungan Otoritas Sertifikat
<a name="origin-ca-support"></a>

CloudFront mTL asal memerlukan sertifikat klien dengan Extended Key Usage (EKU) untuk Otentikasi Klien TLS. Karena persyaratan ini, Anda harus mengeluarkan sertifikat dari Otoritas Sertifikat Anda dan mengimpornya ke AWS Certificate Manager. Fitur penyediaan dan pembaruan sertifikat otomatis ACM tidak tersedia untuk sertifikat klien mTLS asal. CloudFront mTL asal mendukung sertifikat klien dari dua sumber:
+ **AWS Otoritas Sertifikat Pribadi:** Anda dapat menerbitkan sertifikat dari CA AWS Pribadi menggunakan templat sertifikat yang menyertakan Otentikasi Klien TLS di bidang Penggunaan Kunci yang Diperpanjang (seperti EndEntityClientAuthCertificate templat). Setelah mengeluarkan sertifikat dari AWS Private CA, Anda harus mengimpornya ke ACM di Wilayah AS Timur (Virginia N.) (us-east-1). Pendekatan ini memberikan manfaat keamanan dari AWS Private CA sekaligus memberi Anda kendali atas manajemen siklus hidup sertifikat.
+ **Otoritas Sertifikat Pribadi Pihak Ketiga:** Anda juga dapat menerbitkan sertifikat dari infrastruktur Otoritas Sertifikat pribadi Anda yang ada dan mengimpornya ke ACM. Ini memungkinkan Anda untuk mempertahankan proses manajemen sertifikat Anda saat ini sambil memanfaatkan kemampuan CloudFront mTLS asal. Sertifikat harus menyertakan Otentikasi Klien TLS di bidang Penggunaan Kunci Diperpanjang dan harus dalam format PEM dengan sertifikat, kunci pribadi, dan rantai sertifikat.

**penting**  
Untuk CA AWS Pribadi dan pihak ketiga CAs, Anda bertanggung jawab untuk memantau tanggal kedaluwarsa sertifikat dan mengimpor sertifikat yang diperbarui ke ACM sebelum kedaluwarsa. Fitur perpanjangan otomatis ACM tidak berlaku untuk sertifikat impor yang digunakan untuk mTL asal.

## Persyaratan dan spesifikasi sertifikat
<a name="origin-certificate-requirements"></a>

### Persyaratan sertifikat klien
<a name="origin-ca-cert-format-requirements"></a>
+ **Format: Format** PEM (Privacy Enhanced Mail)
+ **Komponen:** Sertifikat, kunci pribadi, dan rantai sertifikat
+ **Kedalaman rantai sertifikat maksimum:** 3 (sertifikat daun\$1sertifikat perantara\$1sertifikat akar)
+ **Ukuran rantai sertifikat maksimum:** 64 KB
+ **Ukuran sertifikat:** Tidak boleh melebihi 96 KB
+ **Ukuran kunci pribadi maksimum:** 5 KB (pembatasan ACM)
+ **Sertifikat mTLS asal unik maksimum ARNs yang dapat ditambahkan atau dimodifikasi per CloudFront distribusi membuat atau memperbarui panggilan API: 5**
+ **Wilayah:** Sertifikat harus disimpan di ACM di Wilayah AS Timur (Virginia N.) (us-east-1)

### Spesifikasi sertifikat yang didukung
<a name="origin-supported-cert-specs"></a>
+ **Jenis sertifikat:** X.509v3
+ **Algoritma kunci publik:**
  + RSA: 2048-bit
  + ECDSA: P-256
+ **Algoritma tanda tangan:**
  + SHA256, SHA384, SHA512 dengan RSA
  + SHA256, SHA384, SHA512 dengan ECDSA
  + SHA256, SHA384, SHA512 dengan RSASSA-PSS dengan MGF1
+ **Penggunaan Kunci yang Diperpanjang (wajib):** Sertifikat memerlukan ekstensi Extended Key Usage (EKU) yang disetel ke Otentikasi Klien TLS, memastikannya diotorisasi untuk tujuan mTLS

### Persyaratan sertifikat server
<a name="origin-server-certificate-requirements"></a>

Server asal Anda harus menunjukkan sertifikat dari Otoritas Sertifikat yang dipercaya publik selama jabat tangan TLS bersama. Untuk detail lengkap tentang persyaratan sertifikat server asal, lihat [Persyaratan untuk menggunakan SSL/TLS sertifikat dengan CloudFront](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/using-https-cloudfront-to-custom-origin.html#using-https-cloudfront-to-origin-certificate).

### Meminta atau mengimpor sertifikat
<a name="origin-request-import-certificate"></a>

Sebelum mengaktifkan mTL asal, Anda harus memiliki sertifikat klien yang tersedia di ACM.

#### Meminta dan mengimpor sertifikat dari AWS Private CA
<a name="request-certificate-aws-private-ca"></a>

Prasyarat:
+ Otoritas Sertifikat AWS Pribadi yang dikonfigurasi di akun Anda
+ Izin untuk menerbitkan sertifikat dari AWS Private CA
+ Izin untuk mengimpor sertifikat ke ACM
+ [Templat sertifikat](https://docs.aws.amazon.com/privateca/latest/userguide/UsingTemplates.html) ARN `Extended key usage:TLS web client authentication` yang sesuai dengan kasus penggunaan Anda
+ Instal OpenSSL AWS , CLI, dan jq (untuk parsing JSON).

##### Untuk meminta sertifikat dari PCA dan impor ke ACM (CLI AWS )
<a name="request-certificate-cli"></a>

1. Atur ARN CA Pribadi Anda dalam variabel agar lebih mudah digunakan kembali.

   ```
   PCA_ARN="arn:aws:acm-pca:region:account:certificate-authority/12345678..."
   ```

1. Gunakan OpenSSL untuk menghasilkan kunci pribadi ECDSA P-256 (kurva prime256v1) dan Certificate Signing Request (CSR), memastikan flag -nodes digunakan untuk menjaga kunci pribadi tidak terenkripsi seperti yang diperlukan untuk impor ACM.

   ```
   openssl req -new -newkey ec -pkeyopt ec_paramgen_curve:prime256v1 -nodes \
       -keyout private.key \
       -out request.csr \
       -subj "/CN=client.example.com"
   ```

1. Kirimkan CSR ke CA AWS Pribadi Anda untuk menerbitkan sertifikat, yang mengembalikan ARN dari sertifikat yang baru diterbitkan.

   ```
   CERT_ARN=$(aws acm-pca issue-certificate \
       --certificate-authority-arn "$PCA_ARN" \
       --csr fileb://request.csr \
       --signing-algorithm "SHA256WITHECDSA" \
       --validity Value=365,Type="DAYS" \
       --template-arn arn:aws:acm-pca:::template/EndEntityCertificate/V1 \
       --query 'CertificateArn' --output text)
   ```

1. Ambil bundel sertifikat dari AWS PCA menggunakan perintah get-certificate, yang mengembalikan sertifikat daun dan rantai, lalu gunakan jq untuk memisahkannya menjadi file yang berbeda.

   ```
   # Retrieve the full certificate bundle in JSON format
   aws acm-pca get-certificate \
       --certificate-authority-arn "$PCA_ARN" \
       --certificate-arn "$CERT_ARN" \
       --output json > full_cert.json
   
   # Split into Leaf and Chain
   jq -r '.Certificate' full_cert.json > leaf_cert.pem
   jq -r '.CertificateChain' full_cert.json > cert_chain.pem
   ```

1. Impor kunci pribadi yang tidak terenkripsi, sertifikat daun, dan rantai sertifikat ke AWS ACM, menggunakan protokol fileb://untuk menangani data file biner dengan benar di CLI.

   ```
   aws acm import-certificate \
       --certificate fileb://leaf_cert.pem \
       --private-key fileb://private.key \
       --certificate-chain fileb://cert_chain.pem \
       --region us-east-1 \
       --query 'CertificateArn' \
       --output text
   ```

#### Impor sertifikat dari CA pihak ketiga
<a name="import-certificate-third-party-ca"></a>

Prasyarat:
+ Sertifikat, kunci pribadi yang tidak terenkripsi, dan rantai sertifikat dari Otoritas Sertifikat Anda dalam format PEM
+ Sertifikat harus menyertakan Penggunaan Kunci yang Diperpanjang untuk Otentikasi Klien TLS
+ Izin untuk mengimpor sertifikat ke ACM

##### Untuk mengimpor sertifikat ke ACM (AWS CLI)
<a name="import-certificate-cli"></a>

```
aws acm import-certificate \
  --certificate fileb://certificate.pem \
  --private-key fileb://private-key.pem \
  --certificate-chain fileb://certificate-chain.pem \
  --region us-east-1 \
  --query 'CertificateArn' \
  --output text
```

#### Langkah selanjutnya
<a name="certificate-next-steps"></a>

Setelah memperoleh atau mengimpor sertifikat klien Anda di ACM, Anda dapat mengonfigurasi server asal Anda untuk meminta otentikasi TLS bersama dan mengaktifkan mTL asal pada distribusi Anda. CloudFront Untuk petunjuk tentang mengaktifkan mTL asal CloudFront, lihat bagian selanjutnya “Aktifkan TLS timbal balik asal untuk CloudFront distribusi.”

# Aktifkan TLS timbal balik asal untuk distribusi CloudFront
<a name="origin-enable-mtls-distributions"></a>

Setelah mendapatkan sertifikat klien melalui AWS Certificate Manager dan mengonfigurasi server asal Anda untuk meminta TLS bersama, Anda dapat mengaktifkan mTL asal pada distribusi Anda. CloudFront 

## Prasyarat dan persyaratan
<a name="origin-mtls-prerequisites-requirements"></a>

Sebelum mengaktifkan mTL asal pada CloudFront distribusi, pastikan Anda memiliki:
+ Sertifikat klien yang disimpan di AWS Certificate Manager di Wilayah AS Timur (Virginia N.) (us-east-1)
+ Server asal dikonfigurasi untuk memerlukan otentikasi TLS bersama dan memvalidasi sertifikat klien
+ Server asal yang menyajikan sertifikat dari Otoritas Sertifikat yang dipercaya publik
+ Izin untuk memodifikasi distribusi CloudFront 
+ Origin mTLS hanya tersedia pada paket Bisnis, Premium, atau Paket harga Pay as you go.

**catatan**  
MTL Asal dapat dikonfigurasi untuk asal kustom (termasuk asal yang dihosting di luar AWS) dan AWS asal yang mendukung TLS timbal balik seperti Application Load Balancer dan API Gateway.

**penting**  
 CloudFront Fitur-fitur berikut tidak didukung dengan mTL asal:  
**lalu lintas gRPC: protokol gRPC** tidak didukung untuk asal dengan mTL asal diaktifkan
**WebSocket koneksi:** WebSocket protokol tidak didukung untuk asal dengan mTL asal diaktifkan
**Asal VPC:** mTL asal tidak dapat digunakan dengan asal VPC
**Permintaan asal dan pemicu respons asal dengan Lambda @Edge:** Fungsi Lambda @Edge dalam permintaan asal dan posisi respons asal tidak didukung dengan mTL asal
**Tertanam POPs:** mTL asal tidak didukung untuk disematkan POPs

## Aktifkan mTL asal
<a name="origin-enable-mtls-per-origin"></a>

Konfigurasi per asal memungkinkan Anda menentukan sertifikat klien yang berbeda untuk asal yang berbeda dalam distribusi yang sama. Pendekatan ini memberikan fleksibilitas maksimum ketika asal Anda memiliki persyaratan otentikasi yang berbeda.

### Untuk distribusi baru (Konsol)
<a name="origin-enable-mtls-new-distributions"></a>

1. Masuk ke Konsol Manajemen AWS dan buka CloudFront konsol di[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Pilih **Buat distribusi**

1. Pilih paket harga: Pilih **Bisnis** atau **Premium** atau **Bayar Saat Anda Pergi** (MTL Asal tidak tersedia pada paket Gratis)

1. Di bagian Pengaturan asal, pilih Jenis Asal sebagai Lainnya

1. Di bagian **Pengaturan asal**, pilih **Sesuaikan pengaturan asal**

1. Konfigurasikan asal pertama Anda (nama domain, protokol, dll.)

1. Dalam konfigurasi asal, temukan **mTL**

1. Alihkan mTLS ke **On**

1. Untuk **sertifikat Klien**, pilih sertifikat Anda dari AWS Certificate Manager

1. (Opsional) Tambahkan asal tambahan dengan konfigurasi mTL asal mereka sendiri

1. Lengkapi pengaturan distribusi yang tersisa dan pilih **Buat distribusi**

### Untuk distribusi yang ada (Konsol)
<a name="origin-enable-mtls-existing-distributions"></a>

1. Masuk ke Konsol Manajemen AWS dan buka CloudFront konsol di[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Dari daftar distribusi, pilih distribusi yang ingin Anda ubah. (Catatan: Pastikan distribusi Anda menggunakan paket harga **Pro atau Premium atau Pay As You Go**. Jika tidak, Anda harus meningkatkan paket harga Anda sebelum mengaktifkan mTL asal)

1. Pilih tab **Origins**

1. Pilih asal yang ingin Anda konfigurasikan dan pilih **Edit**

1. Di pengaturan asal, temukan **mTL**

1. Alihkan mTLS ke **On**

1. Untuk **sertifikat Klien**, pilih sertifikat Anda dari AWS Certificate Manager. (Catatan: Hanya sertifikat klien dengan properti EKU (Extended Key Usage) yang disetel ke “Otentikasi Klien TLS” yang akan dicantumkan)

1. Pilih **Save changes (Simpan perubahan)**

1. Ulangi untuk asal tambahan sesuai kebutuhan

## Menggunakan AWS CLI
<a name="origin-enable-mtls-cli"></a>

Untuk konfigurasi per asal, tentukan pengaturan mTLS asal dalam konfigurasi masing-masing asal:

```
{
  "Origins": {
    "Quantity": 2,
    "Items": [
      {
        "Id": "origin-1",
        "DomainName": "api.example.com",
        "CustomOriginConfig": {
          "HTTPSPort": 443,
          "OriginProtocolPolicy": "https-only"
        },
        "OriginMtlsConfig": {
          "ClientCertificateArn": "arn:aws:acm:us-east-1:123456789012:certificate/cert-1"
        }
      },
      {
        "Id": "origin-2",
        "DomainName": "backend.example.com",
        "CustomOriginConfig": {
          "HTTPSPort": 443,
          "OriginProtocolPolicy": "https-only"
        },
        "OriginMtlsConfig": {
          "CertificateArn": "arn:aws:acm:us-east-1:123456789012:certificate/cert-2"
        }
      }
    ]
  }
}
```

**catatan**  
CloudFront tidak akan memberikan sertifikat klien jika server tidak memintanya, memungkinkan koneksi berjalan normal.

## Langkah selanjutnya
<a name="origin-enable-mtls-next-steps"></a>

Setelah mengaktifkan mTL asal pada CloudFront distribusi Anda, Anda dapat memantau peristiwa otentikasi menggunakan CloudFront log akses.

# Menggunakan CloudFront Fungsi dengan TLS timbal balik asal
<a name="origin-mtls-cloudfront-functions"></a>

CloudFront Fungsi menyediakan komputasi ringan tanpa server di tepi untuk menyesuaikan pengiriman konten. Saat menggunakan TLS timbal balik asal dengan CloudFront Fungsi, ada perilaku dan batasan khusus yang harus diperhatikan mengenai pemilihan dan manipulasi asal.

## Operasi CloudFront Fungsi yang Didukung
<a name="supported-cloudfront-functions-operations"></a>

CloudFront Fungsi dapat berinteraksi dengan asal-usul berkemampuan MTLS dengan cara berikut:

### updateRequestOrigin()
<a name="update-request-origin-function"></a>

Fungsi updateRequestOrigin () mendukung modifikasi terbatas saat bekerja dengan asal-usul berkemampuan MTLS:
+ **Beralih di antara asal mTLS asal:** Anda dapat memperbarui permintaan untuk merutekan ke asal berbeda yang menggunakan mTL asal, asalkan kedua asal menggunakan sertifikat **klien yang sama**. Hal ini memungkinkan Anda untuk menerapkan logika routing kustom sambil mempertahankan otentikasi TLS timbal balik.
+ **Menonaktifkan mTL asal: Anda dapat beralih dari asal berkemampuan MTLS** ke asal non-MTLS dengan menyetel fungsi. `mTLSConfig: 'off'` Ini memberikan fleksibilitas untuk menonaktifkan otentikasi TLS timbal balik secara kondisional berdasarkan karakteristik permintaan.

#### Contoh: Beralih antara asal mTLS asal dengan sertifikat yang sama
<a name="example-switching-mtls-origins"></a>

```
function handler(event) {
    var request = event.request;

    // Route to different origin based on request path
    if (request.uri.startsWith('/api/v2')) {
        request.origin = {
            domainName: 'api-v2.example.com',
            customHeaders: {},
            // Both origins must use the same certificate
        };
    }

    return request;
}
```

#### Contoh: Menonaktifkan mTL asal secara kondisional
<a name="example-disabling-mtls"></a>

```
function handler(event) {
    var request = event.request;

    // Disable mTLS for specific paths
    if (request.uri.startsWith('/public')) {
        request.origin = {
            domainName: 'public-origin.example.com',
            customHeaders: {},
            mTLSConfig: 'off'
        };
    }

    return request;
}
```

## Operasi CloudFront Fungsi Tidak Didukung
<a name="unsupported-cloudfront-functions-operations"></a>

Operasi CloudFront Fungsi berikut tidak mendukung asal berkemampuan MTLS pada ketersediaan umum:

### selectRequestOriginById()
<a name="select-request-origin-by-id-function"></a>

`selectRequestOriginById()`Fungsi tidak dapat memilih asal yang mengaktifkan mTL asal. Mencoba memilih asal berkemampuan MTLS menggunakan fungsi ini akan menghasilkan kesalahan validasi.

Jika kasus penggunaan Anda memerlukan pemilihan asal dinamis dengan mTL asal, gunakan `updateRequestOrigin()` sebagai gantinya, memastikan semua asal target menggunakan sertifikat klien yang sama.

### createRequestOriginKelompok ()
<a name="create-request-origin-group-function"></a>

`createRequestOriginGroup()`Fungsi ini tidak mendukung pembuatan grup asal yang menyertakan asal yang mendukung MTLS. Grup asal dengan asal mTLS asal tidak dapat dibuat secara dinamis melalui CloudFront Fungsi.

Jika Anda memerlukan kemampuan failover asal dengan mTL asal, konfigurasikan grup asal secara langsung di setelan CloudFront distribusi Anda daripada membuatnya secara dinamis dalam fungsi.

# Sajikan konten pribadi dengan cookie yang ditandatangani URLs dan ditandatangani
<a name="PrivateContent"></a>

Banyak perusahaan yang mendistribusikan konten melalui internet ingin membatasi akses ke dokumen, data bisnis, aliran media, atau konten yang ditujukan untuk pengguna tertentu, misalnya, pengguna yang telah membayar biaya. Untuk menyajikan konten pribadi ini dengan aman CloudFront, Anda dapat melakukan hal berikut:
+ Mengharuskan pengguna Anda mengakses konten pribadi Anda dengan menggunakan cookie khusus yang CloudFront ditandatangani URLs atau ditandatangani. 
+ Mengharuskan pengguna mengakses konten Anda dengan menggunakan CloudFront URLs, bukan URLs mengakses konten langsung di server asal (misalnya, Amazon S3 atau server HTTP pribadi). Memerlukan CloudFront URLs tidak diperlukan, tetapi kami merekomendasikannya untuk mencegah pengguna melewati batasan yang Anda tentukan dalam cookie yang ditandatangani URLs atau ditandatangani.

Untuk informasi selengkapnya, lihat [Batasi akses ke file](private-content-overview.md).

## Cara menyajikan konten pribadi
<a name="private-content-task-list"></a>

Untuk mengonfigurasi CloudFront untuk menyajikan konten pribadi, lakukan tugas-tugas berikut:

1. (Opsional tetapi disarankan) Minta pengguna Anda untuk mengakses konten Anda hanya melalui CloudFront. Metode yang Anda gunakan tergantung pada apakah Anda menggunakan Amazon S3 atau asal kustom:
   + **Amazon S3** – Lihat [Batasi akses ke asal Amazon S3](private-content-restricting-access-to-s3.md).
   + **Asal yang disesuaikan** – Lihat [Batasi akses ke file pada asal kustom](private-content-overview.md#forward-custom-headers-restrict-access).

   Asal kustom termasuk Amazon EC2, bucket Amazon S3 yang dikonfigurasi sebagai titik akhir situs web, Elastic Load Balancing, dan server web HTTP Anda sendiri.

1. Tentukan *grup kunci tepercaya* *atau penandatangan tepercaya* yang ingin Anda gunakan untuk membuat cookie yang ditandatangani URLs atau ditandatangani. Kami menyarankan agar Anda menggunakan grup kunci tepercaya. Untuk informasi selengkapnya, lihat [Tentukan penandatangan yang dapat membuat cookie yang ditandatangani URLs dan ditandatangani](private-content-trusted-signers.md).

1. Tulis aplikasi Anda untuk menanggapi permintaan dari pengguna yang berwenang baik dengan ditandatangani URLs atau dengan `Set-Cookie` header yang menetapkan cookie yang ditandatangani. Ikuti langkah-langkah di salah satu topik berikut: 
   + [Gunakan ditandatangani URLs](private-content-signed-urls.md)
   + [Gunakan cookie yang ditandatangani](private-content-signed-cookies.md)

   Jika Anda tidak yakin metode mana yang harus digunakan, lihat [Memutuskan untuk menggunakan cookie yang ditandatangani URLs atau ditandatangani](private-content-choosing-signed-urls-cookies.md).

**Topics**
+ [Cara menyajikan konten pribadi](#private-content-task-list)
+ [Batasi akses ke file](private-content-overview.md)
+ [Tentukan penandatangan yang dapat membuat cookie yang ditandatangani URLs dan ditandatangani](private-content-trusted-signers.md)
+ [Memutuskan untuk menggunakan cookie yang ditandatangani URLs atau ditandatangani](private-content-choosing-signed-urls-cookies.md)
+ [Gunakan ditandatangani URLs](private-content-signed-urls.md)
+ [Gunakan cookie yang ditandatangani](private-content-signed-cookies.md)
+ [Perintah Linux dan OpenSSL untuk pengkodean dan enkripsi base64](private-content-linux-openssl.md)
+ [Contoh kode untuk membuat tanda tangan untuk URL yang ditandatangani](PrivateCFSignatureCodeAndExamples.md)

# Batasi akses ke file
<a name="private-content-overview"></a>

Anda dapat mengontrol akses pengguna ke konten pribadi Anda dengan dua cara:
+ [Batasi akses ke file dalam CloudFront cache](#private-content-overview-edge-caches).
+ Batasi akses ke file yang ada di tempat Anda dengan melakukan salah satu hal berikut:
  + [Siapkan kontrol akses asal (OAC) untuk bucket Amazon S3 Anda](private-content-restricting-access-to-s3.md).
  + [Konfigurasikan header khusus untuk server HTTP privat (asal khusus)](#forward-custom-headers-restrict-access).

## Batasi akses ke file dalam cache CloudFront
<a name="private-content-overview-edge-caches"></a>

Anda dapat mengonfigurasi CloudFront untuk meminta pengguna mengakses file Anda menggunakan *cookie yang *ditandatangani URLs* atau ditandatangani*. Anda kemudian mengembangkan aplikasi Anda baik untuk membuat dan mendistribusikan yang ditandatangani URLs ke pengguna yang diautentikasi atau untuk mengirim `Set-Cookie` header yang menetapkan cookie yang ditandatangani untuk pengguna yang diautentikasi. (Untuk memberi beberapa pengguna akses jangka panjang ke sejumlah kecil file, Anda juga dapat membuat URLs secara manual.) 

Saat Anda membuat cookie yang ditandatangani URLs atau ditandatangani untuk mengontrol akses ke file Anda, Anda dapat menentukan batasan berikut:
+ Tanggal dan waktu akhir, yang setelahnya URL tidak lagi valid. 
+ (Opsional) Tanggal dan waktu URL menjadi valid.
+ (Opsional) Alamat IP atau berbagai alamat komputer yang dapat digunakan untuk mengakses konten Anda. 

Salah satu bagian dari URL yang ditandatangani atau cookie yang ditandatangani di- hash dan ditandatangani menggunakan kunci pribadi dari pasangan kunci publik–swasta. Ketika seseorang menggunakan URL yang ditandatangani atau cookie yang ditandatangani untuk mengakses file, CloudFront bandingkan bagian URL atau cookie yang ditandatangani dan tidak ditandatangani. Jika mereka tidak cocok, CloudFront tidak melayani file.

Anda harus menggunakan kunci pribadi RSA 2048 atau ECDSA 256 untuk penandatanganan atau cookie. URLs 

## Batasi akses ke file di bucket Amazon S3
<a name="private-content-overview-s3"></a>

Anda dapat secara opsional mengamankan konten di bucket Amazon S3 Anda sehingga pengguna dapat mengaksesnya melalui distribusi yang CloudFront ditentukan tetapi tidak dapat mengaksesnya secara langsung dengan menggunakan Amazon S3. URLs Ini mencegah seseorang melewati CloudFront dan menggunakan URL Amazon S3 untuk mendapatkan konten yang ingin Anda batasi aksesnya. Langkah ini tidak diwajibkan untuk menggunakan URLs, tetapi kami merekomendasikannya.

Untuk mengharuskan pengguna mengakses konten Anda CloudFront URLs, Anda melakukan tugas-tugas berikut:
+ Berikan izin *kontrol akses CloudFront asal* untuk membaca file di bucket S3.
+ Buat kontrol akses asal dan kaitkan dengan CloudFront distribusi Anda.
+ Hapus izin bagi orang lain untuk menggunakan Amazon S3 URLs untuk membaca file.

Untuk informasi selengkapnya, lihat [Batasi akses ke asal Amazon S3](private-content-restricting-access-to-s3.md) atau [Batasi akses ke asal Titik Akses Multi-Wilayah Amazon S3](private-content-restricting-access-to-s3-mrap.md).

## Batasi akses ke file pada asal kustom
<a name="forward-custom-headers-restrict-access"></a>

Jika Anda menggunakan asal kustom, Anda dapat secara opsional mengatur header khusus untuk membatasi akses. CloudFront Untuk mendapatkan file Anda dari asal kustom, file harus dapat diakses dengan CloudFront menggunakan permintaan HTTP (atau HTTPS) standar. Tetapi dengan menggunakan header khusus, Anda dapat lebih membatasi akses ke konten Anda sehingga pengguna dapat mengaksesnya hanya melaluiCloudFront, tidak secara langsung. Langkah ini tidak diperlukan untuk menggunakan tanda tangan URLs, tetapi kami merekomendasikannya.

Untuk mengharuskan pengguna mengakses konten CloudFront, ubah pengaturan berikut di CloudFront distribusi Anda:

**Header Kustom Asal**  
Konfigurasikan CloudFront untuk meneruskan header khusus ke asal Anda. Lihat [Konfigurasikan CloudFront untuk menambahkan header khusus ke permintaan asal](add-origin-custom-headers.md#add-origin-custom-headers-configure).

**Kebijakan Protokol Penampil**  
Konfigurasikan distribusi Anda agar pemirsa menggunakan HTTPS untuk mengakses CloudFront. Lihat [Kebijakan protokol penampil](DownloadDistValuesCacheBehavior.md#DownloadDistValuesViewerProtocolPolicy). 

**Kebijakan Protokol Asal**  
Konfigurasikan distribusi Anda CloudFront agar perlu menggunakan protokol yang sama dengan pemirsa untuk meneruskan permintaan ke asal. Lihat [Protokol (hanya asal kustom)](DownloadDistValuesOrigin.md#DownloadDistValuesOriginProtocolPolicy). 

Setelah Anda membuat perubahan ini, perbarui aplikasi Anda di asal kustom Anda untuk hanya menerima permintaan yang menyertakan header khusus yang telah Anda konfigurasi CloudFront untuk dikirim.

Kombinasi dari **Kebijakan Protokol Penampil** dan **Kebijakan Protokol Asal** memastikan bahwa header kustom dienkripsi saat transit. Namun, kami menyarankan Anda melakukan hal berikut secara berkala untuk memutar header khusus yang CloudFront diteruskan ke asal Anda:

1. Perbarui CloudFront distribusi Anda untuk mulai meneruskan header baru ke asal kustom Anda.

1. Perbarui aplikasi Anda untuk menerima header baru sebagai konfirmasi bahwa permintaan tersebut berasal CloudFront.

1. Ketika permintaan tidak lagi menyertakan header yang Anda ganti, perbarui aplikasi Anda agar tidak lagi menerima header lama sebagai konfirmasi bahwa permintaan tersebut berasal CloudFront.

# Tentukan penandatangan yang dapat membuat cookie yang ditandatangani URLs dan ditandatangani
<a name="private-content-trusted-signers"></a>

**Topics**
+ [Pilih antara grup kunci tepercaya (disarankan) dan Akun AWS](#choosing-key-groups-or-AWS-accounts)
+ [Buat pasangan kunci untuk penandatangan Anda](#private-content-creating-cloudfront-key-pairs)
+ [Memformat ulang kunci pribadi (hanya .NET dan Java)](#private-content-reformatting-private-key)
+ [Menambahkan tanda tangan ke distribusi](#private-content-adding-trusted-signers)
+ [Pasangan kunci berputar](#private-content-rotating-key-pairs)

Untuk membuat cookie yang ditandatangani URLs atau ditandatangani, Anda memerlukan *penandatangan*. Penandatangan adalah grup kunci tepercaya yang Anda buat CloudFront, atau AWS akun yang berisi CloudFront key pair. Kami menyarankan Anda menggunakan grup kunci tepercaya dengan cookie yang ditandatangani URLs dan ditandatangani. Untuk informasi selengkapnya, lihat [Pilih antara grup kunci tepercaya (disarankan) dan Akun AWS](#choosing-key-groups-or-AWS-accounts).

Signer memiliki dua tujuan:
+ Segera setelah Anda menambahkan tanda tangan ke distribusi Anda, CloudFront mulai mengharuskan pemirsa menggunakan cookie yang ditandatangani URLs atau ditandatangani untuk mengakses file Anda.
+ Saat Anda membuat cookie yang ditandatangani URLs atau ditandatangani, Anda menggunakan kunci pribadi dari key pair penandatangan untuk menandatangani sebagian URL atau cookie. Ketika seseorang meminta file terbatas, CloudFront membandingkan tanda tangan di URL atau cookie dengan URL atau cookie yang tidak ditandatangani, untuk memverifikasi bahwa itu belum dirusak. CloudFront juga memverifikasi bahwa URL atau cookie valid, artinya, misalnya, bahwa tanggal kedaluwarsa dan waktu belum berlalu.

Saat Anda menentukan penandatangan, Anda juga secara tidak langsung menentukan file yang memerlukan cookie yang ditandatangani URLs atau ditandatangani dengan menambahkan penandatangan ke perilaku cache. Jika distribusi Anda hanya memiliki satu perilaku cache, pemirsa harus menggunakan cookie yang ditandatangani URLs atau ditandatangani untuk mengakses file apa pun dalam distribusi. Jika Anda membuat beberapa perilaku cache dan menambahkan tanda tangan ke beberapa perilaku cache dan tidak ke yang lain, Anda dapat meminta pemirsa menggunakan cookie yang ditandatangani URLs atau ditandatangani untuk mengakses beberapa file dan bukan yang lain.

Untuk menentukan tanda tangan (kunci pribadi) yang diizinkan untuk membuat cookie yang ditandatangani URLs atau ditandatangani, dan untuk menambahkan penandatangan ke CloudFront distribusi Anda, lakukan tugas-tugas berikut:

1. Putuskan apakah akan menggunakan grup kunci tepercaya atau Akun AWS sebagai penandatangan. Kami merekomendasikan penggunaan grup kunci tepercaya. Untuk informasi selengkapnya, lihat [Pilih antara grup kunci tepercaya (disarankan) dan Akun AWS](#choosing-key-groups-or-AWS-accounts).

1. Untuk signer yang Anda pilih pada langkah 1, buat pasangan kunci publik–pribadi. Untuk informasi selengkapnya, lihat [Buat pasangan kunci untuk penandatangan Anda](#private-content-creating-cloudfront-key-pairs).

1. Jika Anda menggunakan .NET atau Java untuk membuat cookie yang ditandatangani URLs atau ditandatangani, format ulang kunci pribadi. Untuk informasi selengkapnya, lihat [Memformat ulang kunci pribadi (hanya .NET dan Java)](#private-content-reformatting-private-key).

1. Dalam distribusi yang Anda buat cookie yang ditandatangani URLs atau ditandatangani, tentukan penandatangan. Untuk informasi selengkapnya, lihat [Menambahkan tanda tangan ke distribusi](#private-content-adding-trusted-signers).

## Pilih antara grup kunci tepercaya (disarankan) dan Akun AWS
<a name="choosing-key-groups-or-AWS-accounts"></a>

Untuk menggunakan cookie yang ditandatangani URLs atau ditandatangani, Anda memerlukan *penandatangan*. Penandatangan adalah grup kunci tepercaya yang Anda buat CloudFront, atau Akun AWS yang berisi CloudFront key pair. Kami sarankan Anda menggunakan grup kunci tepercaya, karena alasan berikut:
+ Dengan grup CloudFront kunci, Anda tidak perlu menggunakan pengguna root AWS akun untuk mengelola kunci publik untuk cookie yang CloudFront ditandatangani URLs dan ditandatangani. [AWS praktik terbaik](https://docs.aws.amazon.com/general/latest/gr/root-vs-iam.html#aws_tasks-that-require-root) merekomendasikan agar Anda tidak menggunakan pengguna root saat Anda tidak perlu melakukannya.
+ Dengan grup CloudFront kunci, Anda dapat mengelola kunci publik, grup kunci, dan penandatangan tepercaya menggunakan CloudFront API. Anda dapat menggunakan API untuk mengotomatiskan pembuatan kunci dan rotasi utama. Saat Anda menggunakan pengguna AWS root, Anda harus menggunakan Konsol Manajemen AWS untuk mengelola pasangan CloudFront kunci, sehingga Anda tidak dapat mengotomatiskan prosesnya.
+ Karena Anda dapat mengelola grup kunci dengan CloudFront API, Anda juga dapat menggunakan kebijakan izin AWS Identity and Access Management (IAM) untuk membatasi apa yang diizinkan dilakukan oleh pengguna yang berbeda. Misalnya, Anda dapat mengizinkan pengguna mengunggah kunci publik, tetapi tidak dapat menghapusnya. Atau Anda dapat mengizinkan pengguna untuk menghapus kunci publik, tetapi hanya jika kondisi tertentu terpenuhi, seperti menggunakan autentikasi multifaktor, mengirim permintaan dari jaringan tertentu, atau mengirim permintaan dalam rentang tanggal dan waktu tertentu.
+ Dengan grup CloudFront kunci, Anda dapat mengaitkan jumlah kunci publik yang lebih tinggi dengan CloudFront distribusi Anda, memberi Anda lebih banyak fleksibilitas dalam cara Anda menggunakan dan mengelola kunci publik. Secara default, Anda dapat mengaitkan hingga empat kelompok utama dengan satu distribusi, dan Anda dapat memiliki hingga lima kunci publik dalam grup utama.

  Saat Anda menggunakan pengguna root AWS akun untuk mengelola pasangan CloudFront kunci, Anda hanya dapat memiliki hingga dua pasangan CloudFront kunci aktif per AWS akun.

## Buat pasangan kunci untuk penandatangan Anda
<a name="private-content-creating-cloudfront-key-pairs"></a>

Setiap penandatangan yang Anda gunakan untuk membuat cookie yang CloudFront ditandatangani URLs atau ditandatangani harus memiliki key pair publik-pribadi. Penandatangan menggunakan kunci pribadinya untuk menandatangani URL atau cookie, dan CloudFront menggunakan kunci publik untuk memverifikasi tanda tangan.

Cara Anda membuat key pair tergantung pada apakah Anda menggunakan grup kunci tepercaya sebagai penandatangan (recommended), atau CloudFront key pair. Untuk informasi selengkapnya, silakan lihat bagian-bagian berikut ini. Pasangan kunci yang Anda buat harus memenuhi persyaratan berikut:
+ Ini harus berupa key pair SSH-2 RSA 2048 atau ECDSA 256.
+ Informasi tersebut harus dalam format PEM yang dikodekan base64.

Untuk membantu mengamankan aplikasi Anda, kami sarankan Anda memutar pasangan kunci secara berkala. Untuk informasi selengkapnya, lihat [Pasangan kunci berputar](#private-content-rotating-key-pairs).

### Buat pasangan kunci untuk kelompok kunci yang dipercaya (disarankan)
<a name="create-key-pair-and-key-group"></a>

Untuk membuat pasangan kunci untuk grup kunci tepercaya, lakukan langkah-langkah berikut:

1. Ciptakan pasangan kunci publik–pribadi.

1. Unggah kunci publik ke CloudFront.

1. Tambahkan kunci publik ke grup CloudFront kunci.

Untuk informasi selengkapnya, lihat prosedur berikut.<a name="private-content-uploading-cloudfront-public-key-procedure"></a>

**Untuk membuat pasangan kunci**
**catatan**  
Langkah-langkah berikut menggunakan OpenSSL sebagai contoh dari satu metode untuk membuat key pair. Ada banyak cara lain untuk membuat key pair RSA atau ECDSA.

1. Jalankan salah satu perintah contoh berikut:
   + Contoh perintah berikut menggunakan OpenSSL untuk membuat pasangan kunci RSA dengan panjang 2048 bit dan menyimpan ke file dengan nama `private_key.pem`.

     ```
     openssl genrsa -out private_key.pem 2048
     ```
   + Contoh perintah berikut menggunakan OpenSSL untuk menghasilkan key pair ECDSA `prime256v1` dengan kurva dan simpan ke file bernama. `private_key.pem`

     ```
     openssl ecparam -name prime256v1 -genkey -noout -out privatekey.pem
     ```

1. Berkas yang dihasilkan berisi baik publik maupun kunci pribadi. Contoh perintah berikut mengekstrak kunci publik dari file yang diberi nama `private_key.pem`.

   ```
   openssl rsa -pubout -in private_key.pem -out public_key.pem
   ```

   Anda mengunggah kunci publik (di `public_key.pem` file) nanti, dalam prosedur berikut.

**Untuk mengunggah kunci publik ke CloudFront**

1. Masuk ke Konsol Manajemen AWS dan buka CloudFront konsol di[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Dalam menu navigasi, pilih **Kunci publik**.

1. Pilih **Buat kunci publik**.

1. Di jendela **Create public key**, lakukan hal berikut:

   1. Untuk **Nama kunci**, ketik nama untuk mengidentifikasi kunci publik.

   1. Untuk **Nilai utama**, merekatkan kunci publik. Jika Anda mengikuti langkah-langkah dalam prosedur sebelumnya, kunci publik ada dalam file dengan nama `public_key.pem`. Untuk menyalin dan menempelkan isi kunci publik, Anda dapat:
      + Gunakan perintah **cat** pada baris perintah macOS atau Linux, seperti ini:

        ```
        cat public_key.pem
        ```

        Salin hasil dari perintah tersebut, kemudian rekatkan ke **Nilai utama** bidang.
      + Buka `public_key.pem` file dengan editor teks biasa seperti Notepad (di Windows) atau (di macOS). TextEdit Salin konten file, lalu tempelkan ke **Nilai utama** bidang.

   1. (Opsional) Untuk **Komentar**, tambahkan komentar untuk menggambarkan kunci publik.

   Setelah selesai, pilih **Tambahkan**.

1. Catat ID kunci publik. Anda menggunakannya nanti ketika Anda membuat cookie yang ditandatangani URLs atau ditandatangani, sebagai nilai `Key-Pair-Id` bidang.

**Untuk menambahkan kunci publik ke kelompok utama**

1. Buka CloudFront konsol di[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Dalam menu navigasi, pilih **Kelompok utama**.

1. Pilih **Tambahkan kelompok kunci**.

1. Di **Buat grup utama** , lakukan hal berikut:

   1. Untuk **Nama grup utama**, ketikkan nama untuk mengidentifikasi kelompok kunci.

   1. (Opsional) Untuk **Komentar**, ketik komentar untuk mendeskripsikan kelompok utama.

   1. Untuk **Kunci publik**, pilih kunci publik untuk ditambahkan ke kelompok utama, lalu pilih **Tambahkan**. Ulangi langkah ini untuk setiap kunci publik yang ingin Anda tambahkan ke grup utama.

1. Pilih **Buat grup utama**.

1. Catat nama kelompok kunci. Anda menggunakannya nanti untuk mengaitkan grup kunci dengan perilaku cache dalam CloudFront distribusi. (Di CloudFront API, Anda menggunakan ID grup kunci untuk mengaitkan grup kunci dengan perilaku cache.)

### Buat CloudFront key pair (tidak disarankan, membutuhkan pengguna Akun AWS root)
<a name="create-key-pair-aws-account"></a>

**penting**  
Kami sarankan Anda membuat kunci publik untuk grup kunci yang dipercaya, bukan mengikuti langkah-langkah ini. Untuk cara yang disarankan untuk membuat kunci publik untuk cookie yang ditandatangani URLs dan ditandatangani, lihat[Buat pasangan kunci untuk kelompok kunci yang dipercaya (disarankan)](#create-key-pair-and-key-group).

Anda dapat membuat CloudFront key pair dengan cara berikut:
+ Buat key pair di Konsol Manajemen AWS dan unduh kunci privat. Lihat prosedur berikut.
+ Buat pasangan kunci RSA dengan menggunakan aplikasi seperti OpenSSL, lalu unggah kunci publik ke Konsol Manajemen AWS. Untuk informasi lebih lanjut tentang membuat pasangan kunci RSA, lihat [Buat pasangan kunci untuk kelompok kunci yang dipercaya (disarankan)](#create-key-pair-and-key-group).<a name="private-content-creating-cloudfront-key-pairs-procedure"></a>

**Untuk membuat pasangan CloudFront kunci di Konsol Manajemen AWS**

1. Masuk ke Konsol Manajemen AWS menggunakan kredensyal pengguna root AWS akun.
**penting**  
Pengguna IAM tidak dapat membuat pasangan CloudFront kunci. Anda harus masuk menggunakan kredensial pengguna akar untuk membuat pasangan kunci.

1. Pilih nama akun Anda, lalu pilih **Kredensial Keamanan Saya**.

1. Pilih **CloudFront pasangan kunci**.

1. Konfirmasikan bahwa Anda tidak memiliki lebih dari satu pasangan kunci aktif. Anda tidak dapat membuat pasangan kunci jika Anda sudah memiliki dua pasangan kunci aktif.

1. Pilih **Buat Pasangan Kunci Baru**.
**catatan**  
Anda juga dapat memilih untuk membuat key pair Anda sendiri dan mengunggah kunci publik. CloudFront pasangan kunci mendukung kunci 1024, 2048, atau 4096-bit.

1. Di **Buat Pasangan Utama** kotak dialog, pilih **Unduh File Kunci Pribadi**, lalu simpan file di komputer Anda.
**penting**  
Simpan kunci pribadi untuk CloudFront key pair Anda di lokasi yang aman, dan atur izin pada file sehingga hanya administrator yang diinginkan yang dapat membacanya. Jika seseorang mendapatkan kunci pribadi Anda, mereka dapat menghasilkan cookie yang ditandatangani URLs dan ditandatangani yang valid dan mengunduh konten Anda. Anda tidak bisa mendapatkan kunci pribadi lagi, jadi jika Anda kehilangan atau menghapusnya, Anda harus membuat CloudFront key pair baru.

1. Catat ID pasangan kunci untuk pasangan kunci Anda. (Dalam Konsol Manajemen AWS, ini disebut **ID Kunci Akses**.) Anda akan menggunakannya saat membuat cookie yang ditandatangani URLs atau ditandatangani.

## Memformat ulang kunci pribadi (hanya .NET dan Java)
<a name="private-content-reformatting-private-key"></a>

Jika Anda menggunakan .NET atau Java untuk membuat cookie yang ditandatangani URLs atau ditandatangani, Anda tidak dapat menggunakan kunci pribadi dari key pair Anda dalam format PEM default untuk membuat tanda tangan. Sebaliknya, lakukan hal berikut:
+ **Kerangka kerja .NET** – Konversikan kunci pribadi ke format XML yang digunakan kerangka kerja .NET. Tersedia beberapa alat.
+ **Jawa** – Mengonversi kunci pribadi menjadi format DER. Salah satu cara untuk melakukannya adalah dengan perintah OpenSSL. Dengan perintah berikut, `private_key.pem` adalah nama file yang berisi kunci pribadi yang diformat PEM, dan `private_key.der` adalah nama file yang berisi kunci pribadi yang diformat DER setelah Anda menjalankan perintah.

  ```
  openssl pkcs8 -topk8 -nocrypt -in private_key.pem -inform PEM -out private_key.der -outform DER
  ```

  Untuk memastikan bahwa encoder berfungsi dengan benar, tambahkan JAR untuk kriptografi Bouncy Castle Java APIs ke proyek Anda dan kemudian tambahkan penyedia Bouncy Castle.

## Menambahkan tanda tangan ke distribusi
<a name="private-content-adding-trusted-signers"></a>

Penandatangan adalah grup kunci tepercaya (recommended) atau CloudFront key pair yang dapat membuat cookie yang ditandatangani URLs dan ditandatangani untuk distribusi. Untuk menggunakan cookie yang ditandatangani URLs atau ditandatangani dengan CloudFront distribusi, Anda harus menentukan penandatangan.

Signer dikaitkan dengan perilaku cache. Ini memungkinkan Anda untuk meminta cookie yang ditandatangani URLs atau ditandatangani untuk beberapa file dan bukan untuk yang lain dalam distribusi yang sama. Distribusi memerlukan ditandatangani URLs atau cookie hanya untuk file yang terkait dengan perilaku cache yang sesuai.

Demikian pula, penandatangan hanya dapat menandatangani URLs atau cookie untuk file yang terkait dengan perilaku cache yang sesuai. Misalnya, jika Anda memiliki satu penandatangan untuk satu perilaku cache dan penandatangan yang berbeda untuk perilaku cache yang berbeda, penandatangan tidak dapat membuat tanda tangan URLs atau cookie untuk file yang terkait dengan perilaku cache lainnya.

**penting**  
Sebelum Anda menambahkan signer ke distribusi Anda, lakukan hal berikut:  
Tentukan pola jalur dalam perilaku cache dan urutan perilaku cache secara saksama sehingga Anda tidak memberi pengguna akses yang tidak diinginkan ke konten Anda atau mencegah mereka mengakses konten yang ingin tersedia bagi semua orang.  
Misalnya, anggaplah permintaan tersebut sesuai dengan pola jalur untuk perilaku cache. Perilaku cache pertama tidak memerlukan cookie yang ditandatangani URLs atau ditandatangani dan perilaku cache kedua tidak. Pengguna akan dapat mengakses file tanpa menggunakan cookie yang ditandatangani URLs atau ditandatangani karena CloudFront memproses perilaku cache yang terkait dengan kecocokan pertama.  
Untuk informasi lebih lanjut tentang pola jalur, lihat [Pola jalur](DownloadDistValuesCacheBehavior.md#DownloadDistValuesPathPattern).
Untuk distribusi yang sudah Anda gunakan untuk mendistribusikan konten, pastikan Anda siap untuk mulai membuat cookie yang ditandatangani URLs dan ditandatangani sebelum menambahkan penandatangan. Saat Anda menambahkan tanda tangan, CloudFront tolak permintaan yang tidak menyertakan URL bertanda tangan yang valid atau cookie yang ditandatangani.

Anda dapat menambahkan tanda tangan ke distribusi menggunakan CloudFront konsol atau CloudFront API.

------
#### [ Console ]

Langkah-langkah berikut menunjukkan cara menambahkan kelompok kunci tepercaya sebagai signer. Anda juga dapat menambahkan Akun AWS sebagai penandatangan tepercaya, tetapi tidak disarankan.<a name="private-content-adding-trusted-signers-console-procedure"></a>

**Untuk menambahkan signer ke distribusi menggunakan konsol**

1. Catat ID kelompok utama dari kelompok kunci yang ingin Anda gunakan sebagai signer tepercaya. Untuk informasi selengkapnya, lihat [Buat pasangan kunci untuk kelompok kunci yang dipercaya (disarankan)](#create-key-pair-and-key-group).

1. Buka CloudFront konsol di[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Pilih distribusi yang filenya ingin Anda lindungi dengan cookie yang ditandatangani URLs atau ditandatangani.
**catatan**  
Untuk menambahkan signer ke distribusi baru, Anda menentukan pengaturan yang sama yang dijelaskan di langkah 6 saat Anda membuat distribusi.

1. Pilih **Perilaku** tab.

1. Pilih perilaku cache yang pola jalurnya cocok dengan file yang ingin Anda lindungi dengan cookie yang ditandatangani URLs atau ditandatangani, lalu pilih **Edit**.

1. Di **Edit Perilaku** , lakukan hal berikut:

   1. Untuk **Membatasi Akses Penampil (Gunakan Cookie yang Ditandatangani URLs atau Ditandatangani)**, pilih **Ya**.

   1. Untuk **Grup Kunci Tepercaya atau Signer Tepercaya**, pilih **Grup Utama yang Dipercaya**.

   1. Untuk **Grup Utama yang Dipercaya**, pilih grup utama untuk ditambahkan, lalu pilih **Tambahkan**. Ulangi jika Anda ingin menambahkan lebih dari satu grup kunci.

1. Pilih **Ya, Edit** untuk memperbarui perilaku cache.

------
#### [ API ]

Anda dapat menggunakan CloudFront API untuk menambahkan grup kunci tepercaya sebagai penandatangan. Anda dapat menambahkan signer ke distribusi yang ada atau ke distribusi baru. Dalam kedua kasus, tentukan nilai dalam `TrustedKeyGroups` elemen lainnya.

Anda juga dapat menambahkan Akun AWS sebagai penandatangan tepercaya, tetapi tidak disarankan.

Lihat topik berikut di *Referensi Amazon CloudFront API*:
+ **Perbarui distribusi yang ada** — [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html)
+ **Buat distribusi baru** — [CreateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateDistribution.html)

------

## Pasangan kunci berputar
<a name="private-content-rotating-key-pairs"></a>

Kami menyarankan Anda secara berkala memutar (mengubah) pasangan kunci Anda untuk cookie yang ditandatangani URLs dan ditandatangani. Untuk memutar pasangan kunci yang Anda gunakan untuk membuat cookie yang ditandatangani URLs atau ditandatangani tanpa membatalkan URLs atau cookie yang belum kedaluwarsa, lakukan tugas berikut:

1. Buat pasangan kunci baru, dan tambahkan kunci publik ke kelompok kunci. Untuk informasi selengkapnya, lihat [Buat pasangan kunci untuk kelompok kunci yang dipercaya (disarankan)](#create-key-pair-and-key-group).

1. Jika Anda membuat grup kunci baru di langkah sebelumnya, [menambahkan grup utama ke dalam distribusi sebagai penanda tangan](#private-content-adding-trusted-signers).
**penting**  
Jangan hapus kunci publik yang ada dari grup utama, atau grup utama mana pun dari distribusi. Hanya tambahkan yang baru.

1. Perbarui aplikasi Anda untuk membuat tanda tangan menggunakan kunci pribadi dari pasangan kunci baru. Konfirmasikan bahwa cookie yang ditandatangani URLs atau ditandatangani dengan kunci pribadi baru berfungsi.

1. Tunggu hingga tanggal kedaluwarsa berlalu URLs atau cookie yang ditandatangani menggunakan kunci pribadi sebelumnya. Kemudian, hapus kunci publik lama dari kelompok utama. Jika Anda membuat grup kunci baru di langkah 2, hapus grup kunci lama dari distribusi Anda.

# Memutuskan untuk menggunakan cookie yang ditandatangani URLs atau ditandatangani
<a name="private-content-choosing-signed-urls-cookies"></a>

CloudFront Cookie yang ditandatangani URLs dan ditandatangani menyediakan fungsionalitas dasar yang sama: mereka memungkinkan Anda untuk mengontrol siapa yang dapat mengakses konten Anda. Jika Anda ingin menyajikan konten pribadi CloudFront dan Anda mencoba memutuskan apakah akan menggunakan cookie yang ditandatangani URLs atau ditandatangani, pertimbangkan hal berikut.

Gunakan yang ditandatangani URLs dalam kasus berikut:
+ Anda ingin membatasi akses ke file individual, misalnya, unduhan penginstalan untuk aplikasi Anda.
+ Pengguna Anda menggunakan klien (misalnya, klien HTTP kustom) yang tidak mendukung cookie.

Gunakan cookie yang ditandatangani dalam kasus berikut:
+ Anda ingin memberikan akses ke beberapa file terbatas, misalnya, semua file untuk video dalam format HLS atau semua file dalam area pelanggan di situs web.
+ Anda tidak ingin mengubah URLs.

Jika saat ini Anda tidak menggunakan tanda tangan URLs, dan jika Anda (tidak ditandatangani) URLs berisi salah satu parameter string kueri berikut, Anda tidak dapat menggunakan cookie yang ditandatangani URLs atau ditandatangani:
+ `Expires`
+ `Policy`
+ `Signature`
+ `Key-Pair-Id`
+ `Hash-Algorithm`

CloudFront mengasumsikan URLs bahwa yang berisi salah satu parameter string kueri tersebut ditandatangani URLs, dan oleh karena itu tidak akan melihat cookie yang ditandatangani.

## Gunakan cookie yang ditandatangani URLs dan ditandatangani
<a name="private-content-using-signed-urls-and-cookies"></a>

Ditandatangani URLs lebih diutamakan daripada cookie yang ditandatangani. Jika Anda menggunakan cookie yang ditandatangani URLs dan ditandatangani untuk mengontrol akses ke file yang sama dan penampil menggunakan URL yang ditandatangani untuk meminta file, CloudFront tentukan apakah akan mengembalikan file ke penampil hanya berdasarkan URL yang ditandatangani.

# Gunakan ditandatangani URLs
<a name="private-content-signed-urls"></a>

URL yang ditandatangani mencakup informasi tambahan, misalnya, tanggal dan waktu kedaluwarsa, yang memberi Anda lebih banyak kendali atas akses ke konten Anda. Informasi tambahan ini muncul dalam pernyataan kebijakan, yang didasarkan pada kebijakan terekam atau kebijakan pabean. Perbedaan antara kebijakan terekam dan kustom dijelaskan dalam dua bagian berikutnya.

**catatan**  
Anda dapat membuat beberapa yang ditandatangani URLs menggunakan kebijakan kalengan dan membuat beberapa yang ditandatangani URLs menggunakan kebijakan khusus untuk distribusi yang sama.

**Topics**
+ [Memutuskan untuk menggunakan kebijakan kalengan atau kustom untuk ditandatangani URLs](#private-content-choosing-canned-custom-policy)
+ [Cara URLs kerja ditandatangani](#private-content-how-signed-urls-work)
+ [Tentukan berapa lama ditandatangani URLs valid](#private-content-overview-choosing-duration)
+ [Saat CloudFront memeriksa tanggal dan waktu kedaluwarsa di URL yang ditandatangani](#private-content-check-expiration)
+ [Kode contoh dan alat pihak ketiga](#private-content-overview-sample-code)
+ [Membuat URL yang ditandatangani menggunakan kebijakan kalengan](private-content-creating-signed-url-canned-policy.md)
+ [Membuat URL yang ditandatangani menggunakan kebijakan khusus](private-content-creating-signed-url-custom-policy.md)

## Memutuskan untuk menggunakan kebijakan kalengan atau kustom untuk ditandatangani URLs
<a name="private-content-choosing-canned-custom-policy"></a>

Saat Anda membuat URL yang ditandatangani, Anda menulis pernyataan kebijakan dalam format JSON yang menetapkan batasan pada URL yang ditandatangani, misalnya, berapa lama URL tersebut valid. Anda dapat menggunakan kebijakan terekam atau kebijakan bea cukai. Berikut ini adalah perbandingan kebijakan yang dapat disesuaikan dan disesuaikan:


****  

| Deskripsi | Kebijakan kalengan | Kebijakan khusus | 
| --- | --- | --- | 
| Anda dapat menggunakan kembali pernyataan kebijakan untuk beberapa file. Untuk menggunakan kembali pernyataan kebijakan, Anda harus menggunakan karakter wildcard dalam `Resource` objek. Untuk informasi lebih lanjut, lihat [Nilai yang Anda sebutkan dalam pernyataan kebijakan untuk URL yang ditandatangani menggunakan kebijakan khusus](private-content-creating-signed-url-custom-policy.md#private-content-custom-policy-statement-values).)  | Tidak | Ya | 
| Anda dapat menentukan tanggal dan waktu pengguna dapat mulai mengakses konten Anda. | Tidak | Ya (opsional) | 
| Anda dapat menentukan tanggal dan waktu saat pengguna tidak lagi dapat mengakses konten Anda. | Ya | Ya | 
| Anda dapat menentukan alamat IP atau berbagai alamat IP pengguna yang dapat mengakses konten Anda. | Tidak | Ya (opsional) | 
| URL yang ditandatangani mencakup versi kebijakan yang dikodekan base64, yang menghasilkan URL yang lebih panjang. | Tidak | Ya | 

Untuk informasi tentang membuat ditandatangani URLs menggunakan kebijakan *kalengan*, lihat[Membuat URL yang ditandatangani menggunakan kebijakan kalengan](private-content-creating-signed-url-canned-policy.md).

Untuk informasi tentang membuat ditandatangani URLs menggunakan kebijakan *kustom*, lihat[Membuat URL yang ditandatangani menggunakan kebijakan khusus](private-content-creating-signed-url-custom-policy.md).

## Cara URLs kerja ditandatangani
<a name="private-content-how-signed-urls-work"></a>

Berikut adalah ikhtisar tentang cara Anda mengonfigurasi CloudFront dan Amazon S3 untuk ditandatangani URLs dan bagaimana CloudFront merespons saat pengguna menggunakan URL yang ditandatangani untuk meminta file. 

1. Dalam CloudFront distribusi Anda, tentukan satu atau beberapa grup kunci tepercaya, yang berisi kunci publik yang CloudFront dapat digunakan untuk memverifikasi tanda tangan URL. Anda menggunakan kunci privat yang sesuai untuk menandatangani URLs.

   CloudFront mendukung ditandatangani URLs dengan tanda tangan kunci RSA 2048 dan ECDSA 256.

   Untuk informasi selengkapnya, lihat [Tentukan penandatangan yang dapat membuat cookie yang ditandatangani URLs dan ditandatangani](private-content-trusted-signers.md).

1. Kembangkan aplikasi Anda untuk menentukan apakah pengguna harus memiliki akses ke konten Anda dan membuat ditandatangani URLs untuk file atau bagian dari aplikasi Anda yang ingin Anda batasi aksesnya. Untuk informasi selengkapnya, lihat topik berikut:
   + [Membuat URL yang ditandatangani menggunakan kebijakan kalengan](private-content-creating-signed-url-canned-policy.md)
   + [Membuat URL yang ditandatangani menggunakan kebijakan khusus](private-content-creating-signed-url-custom-policy.md)

1. Pengguna meminta file yang ingin Anda tandatangani URLs.

1. Aplikasi Anda memverifikasi bahwa pengguna berhak mengakses file: mereka telah masuk, mereka telah membayar akses ke konten, atau mereka telah memenuhi beberapa persyaratan lain untuk akses.

1. Aplikasi Anda membuat dan mengembalikan URL yang ditandatangani ke pengguna.

1. URL yang ditandatangani memungkinkan pengguna mengunduh atau men-streaming konten.

   Langkah ini bersifat otomatis; pengguna biasanya tidak perlu melakukan tindakan tambahan apa pun untuk mengakses konten. Misalnya, jika pengguna mengakses konten Anda di peramban web, aplikasi akan mengembalikan URL yang ditandatangani ke peramban. Browser segera menggunakan URL yang ditandatangani untuk mengakses file di cache CloudFront tepi tanpa campur tangan dari pengguna.

1. CloudFront menggunakan kunci publik untuk memvalidasi tanda tangan dan mengonfirmasi bahwa URL belum dirusak. Jika tanda tangan tidak valid, permintaan ditolak. 

   Jika tanda tangan valid, CloudFront lihat pernyataan kebijakan di URL (atau buat jika Anda menggunakan kebijakan kalengan) untuk mengonfirmasi bahwa permintaan tersebut masih valid. Misalnya, jika Anda menentukan tanggal dan waktu awal dan akhir untuk URL, CloudFront konfirmasikan bahwa pengguna mencoba mengakses konten Anda selama periode waktu yang ingin Anda izinkan akses. 

   Jika permintaan memenuhi persyaratan dalam pernyataan kebijakan, CloudFront lakukan operasi standar: menentukan apakah file sudah ada di cache tepi, meneruskan permintaan ke asal jika perlu, dan mengembalikan file ke pengguna.

**catatan**  
Jika URL yang belum ditandatangani memuat parameter string kueri, pastikan Anda menyertakannya di bagian URL yang Anda tanda tangani. Jika Anda menambahkan string kueri ke URL yang ditandatangani setelah menandatanganinya, URL akan mengembalikan status HTTP 403.

## Tentukan berapa lama ditandatangani URLs valid
<a name="private-content-overview-choosing-duration"></a>

Anda dapat mendistribusikan konten pribadi menggunakan URL bertanda tangan yang hanya berlaku sebentar—mungkin hanya selama beberapa menit. Ditandatangani URLs yang berlaku untuk waktu yang singkat baik untuk mendistribusikan konten on-the-fly kepada pengguna untuk tujuan tertentu, seperti mendistribusikan penyewaan film atau unduhan musik kepada pelanggan sesuai permintaan. Jika tanda tangan Anda URLs akan valid hanya untuk waktu yang singkat, Anda mungkin ingin membuatnya secara otomatis menggunakan aplikasi yang Anda kembangkan. Saat pengguna mulai mengunduh file atau mulai memutar file media, CloudFront bandingkan waktu kedaluwarsa di URL dengan waktu saat ini untuk menentukan apakah URL tersebut masih valid.

Anda juga dapat mendistribusikan konten pribadi menggunakan URL bertanda tangan yang valid untuk waktu yang lebih lama, mungkin selama bertahun-tahun. Ditandatangani URLs yang berlaku untuk jangka waktu yang lebih lama berguna untuk mendistribusikan konten pribadi kepada pengguna yang dikenal, seperti mendistribusikan rencana bisnis kepada investor atau mendistribusikan materi pelatihan kepada karyawan. Anda dapat mengembangkan aplikasi untuk menghasilkan tanda tangan URLs jangka panjang ini untuk Anda.

## Saat CloudFront memeriksa tanggal dan waktu kedaluwarsa di URL yang ditandatangani
<a name="private-content-check-expiration"></a>

CloudFront memeriksa tanggal kedaluwarsa dan waktu dalam URL yang ditandatangani pada saat permintaan HTTP. Jika klien mulai mengunduh file besar segera sebelum waktu kedaluwarsa, pengunduhan harus selesai meskipun waktu kedaluwarsa sudah lewat selama pengunduhan. Jika koneksi TCP menurun dan klien mencoba memulai ulang unduhan setelah waktu kedaluwarsa berlalu, pengunduhan akan gagal.

Jika klien menggunakan Range GETs untuk mendapatkan file dalam potongan yang lebih kecil, permintaan GET apa pun yang terjadi setelah waktu kedaluwarsa berlalu akan gagal. Untuk informasi selengkapnya tentang Range GETs, lihat [Bagaimana CloudFront memproses permintaan sebagian untuk suatu objek (rentang GETs)](RangeGETs.md).

## Kode contoh dan alat pihak ketiga
<a name="private-content-overview-sample-code"></a>

Misalnya kode yang membuat bagian hash dan ditandatangani dari ditandatangani URLs, lihat topik berikut:
+ [Buat tanda tangan URL menggunakan Perl](CreateURLPerl.md)
+ [Buat tanda tangan URL menggunakan PHP](CreateURL_PHP.md)
+ [Buat tanda tangan URL menggunakan C\$1 dan .NET Framework](CreateSignatureInCSharp.md)
+ [Buat tanda tangan URL menggunakan Java](CFPrivateDistJavaDevelopment.md)

# Membuat URL yang ditandatangani menggunakan kebijakan kalengan
<a name="private-content-creating-signed-url-canned-policy"></a>

Untuk membuat URL yang ditandatangani menggunakan kebijakan terekam, lakukan langkah-langkah berikut.<a name="private-content-creating-signed-url-canned-policy-procedure"></a>

**Untuk membuat URL yang ditandatangani menggunakan kebijakan terekam**

1. Jika Anda menggunakan .NET atau Java untuk membuat ditandatangani URLs, dan jika Anda belum memformat ulang kunci pribadi untuk key pair Anda dari format.pem default ke format yang kompatibel dengan.NET atau dengan Java, lakukan sekarang. Untuk informasi selengkapnya, lihat [Memformat ulang kunci pribadi (hanya .NET dan Java)](private-content-trusted-signers.md#private-content-reformatting-private-key).

1. Menggabungkan nilai-nilai berikut. Anda dapat menggunakan format dalam contoh URL yang ditandatangani ini. 

   ```
   https://d111111abcdef8.cloudfront.net/image.jpg?color=red&size=medium&Expires=1767290400&Signature=nitfHRCrtziwO2HwPfWw~yYDhUF5EwRunQA-j19DzZrvDh6hQ73lDx~-ar3UocvvRQVw6EkC~GdpGQyyOSKQim-TxAnW7d8F5Kkai9HVx0FIu-5jcQb0UEmatEXAMPLE3ReXySpLSMj0yCd3ZAB4UcBCAqEijkytL6f3fVYNGQI6&Key-Pair-Id=K2JCJMDEHXQW5F&Hash-Algorithm=SHA256
   ```

   Hapus semua spasi kosong (termasuk tab dan karakter baris baru). Anda mungkin harus memasukkan karakter escape dalam string di kode aplikasi. Semua nilai memiliki tipe`String`.  
**1. *Base URL for the file***  
URL dasar adalah CloudFront URL yang akan Anda gunakan untuk mengakses file jika Anda tidak menggunakan tanda tangan URLs, termasuk parameter string kueri Anda sendiri, jika ada. Pada contoh sebelumnya, URL dasar adalah. `https://d111111abcdef8.cloudfront.net/image.jpg` Untuk informasi selengkapnya tentang format URLs untuk distribusi, lihat[Sesuaikan format URL untuk file di CloudFront](LinkFormat.md).  
   +  CloudFront URL berikut adalah untuk file gambar dalam distribusi (menggunakan nama CloudFront domain). Perhatikan bahwa `image.jpg` dalam `images` direktori. Jalur menuju file dalam URL harus sesuai dengan alur menuju file pada server HTTP Anda atau pada buket Amazon S3.

     `https://d111111abcdef8.cloudfront.net/images/image.jpg`
   +  CloudFront URL berikut mencakup string kueri:

     `https://d111111abcdef8.cloudfront.net/images/image.jpg?size=large`
   + Berikut ini CloudFront URLs adalah untuk file gambar dalam distribusi. Keduanya menggunakan nama domain alternatif. Yang kedua mencakup string kueri:

     `https://www.example.com/images/image.jpg`

     `https://www.example.com/images/image.jpg?color=red`
   +  CloudFront URL berikut adalah untuk file gambar dalam distribusi yang menggunakan nama domain alternatif dan protokol HTTPS:

     `https://www.example.com/images/image.jpg`  
** 2. `?`**  
`?`Ini menunjukkan bahwa parameter kueri mengikuti URL dasar. Sertakan `?` bahkan jika Anda tidak menentukan parameter kueri apa pun.  
Anda dapat menentukan parameter kueri berikut dalam urutan apa pun.  
**3. *Your query string parameters, if any*`&`**  
(Opsional) Anda dapat memasukkan parameter string kueri Anda sendiri. Untuk melakukannya, tambahkan ampersand (`&`) di antara masing-masing, seperti. `color=red&size=medium` Anda dapat menentukan parameter string kueri dalam urutan apa pun dalam URL.  
Parameter string kueri Anda tidak dapat diberi nama`Expires`,`Signature`,`Key-Pair-Id`, atau`Hash-Algorithm`.  
** 4. `Expires=`*date and time in Unix time format (in seconds) and Coordinated Universal Time (UTC)***  
Tanggal dan waktu Anda ingin URL berhenti memungkinkan akses ke file.  
Tentukan tanggal dan waktu kedaluwarsa dalam format waktu Unix (dalam detik) dan Waktu Universal Terkoordinasi (UTC). Misalnya, 1 Januari 2026 10:00 UTC dikonversi ke `1767290400` dalam format waktu Unix, seperti yang ditunjukkan pada contoh di awal topik ini.   
Untuk menggunakan waktu epoch, tentukan bilangan bulat 64-bit untuk tanggal yang paling lambat `9223372036854775807` (Jumat, 11 April 2262 pukul 23:47:16.854 UTC).  
  
Untuk informasi tentang UTC, lihat [RFC 3339, Tanggal dan Waktu di Internet: Stempel Waktu](https://tools.ietf.org/html/rfc3339).  
** 5. `&Signature=`*hashed and signed version of the policy statement***  
Versi yang di-hash, ditandatangani, dan dikodekan base64 dari pernyataan kebijakan JSON. Untuk informasi selengkapnya, lihat [Membuat tanda tangan untuk URL yang ditandatangani yang menggunakan kebijakan kalengan](#private-content-canned-policy-creating-signature).  
** 6. `&Key-Pair-Id=`*public key ID for the CloudFront public key whose corresponding private key you're using to generate the signature***  
ID untuk kunci CloudFront publik, misalnya,`K2JCJMDEHXQW5F`. ID kunci publik memberi tahu kunci publik CloudFront mana yang akan digunakan untuk memvalidasi URL yang ditandatangani. CloudFront membandingkan informasi dalam tanda tangan dengan informasi dalam pernyataan kebijakan untuk memverifikasi bahwa URL belum dirusak.  
Kunci publik ini harus dimiliki oleh kelompok kunci yang merupakan signer tepercaya dalam distribusi. Untuk informasi selengkapnya, lihat [Tentukan penandatangan yang dapat membuat cookie yang ditandatangani URLs dan ditandatangani](private-content-trusted-signers.md).  
** 7. `&Hash-Algorithm=`*SHA1 or SHA256***  
(Opsional) Algoritma hash yang digunakan untuk membuat tanda tangan. Nilai yang didukung adalah `SHA1` dan `SHA256`. Jika Anda tidak menentukan parameter ini, CloudFront defaultnya. `SHA1`

## Membuat tanda tangan untuk URL yang ditandatangani yang menggunakan kebijakan kalengan
<a name="private-content-canned-policy-creating-signature"></a>

Untuk membuat tanda tangan untuk URL yang ditandatangani yang menggunakan kebijakan kalengan, selesaikan prosedur berikut.

**Topics**
+ [Membuat pernyataan kebijakan untuk URL yang ditandatangani yang menggunakan kebijakan yang dikalengkan](#private-content-canned-policy-creating-policy-statement)
+ [Membuat tanda tangan untuk URL yang ditandatangani yang menggunakan kebijakan kalengan](#private-content-canned-policy-signing-policy-statement)

### Membuat pernyataan kebijakan untuk URL yang ditandatangani yang menggunakan kebijakan yang dikalengkan
<a name="private-content-canned-policy-creating-policy-statement"></a>

Saat Anda membuat URL yang ditandatangani menggunakan kebijakan terekam, `Signature` parameter adalah versi dokumen pernyataan kebijakan yang di- hashed dan ditandatangani. Untuk tanda tangan URLs yang menggunakan kebijakan kalengan, Anda tidak menyertakan pernyataan kebijakan di URL, seperti yang Anda lakukan untuk ditandatangani URLs yang menggunakan kebijakan khusus. Untuk membuat pernyataan kebijakan, lakukan prosedur berikut.<a name="private-content-canned-policy-creating-policy-statement-procedure"></a>

**Untuk membuat pernyataan kebijakan untuk URL yang ditandatangani menggunakan kebijakan terekam**

1. Susun pernyataan kebijakan dengan menggunakan format JSON berikut dan menggunakan pengkodean karakter UTF-8. Sertakan semua tanda baca dan nilai literal lainnya persis seperti yang ditentukan. Untuk informasi tentang `Resource` dan `DateLessThan` parameter, lihat [Nilai yang Anda sebutkan dalam pernyataan kebijakan untuk URL yang ditandatangani dengan menggunakan kebijakan terekam](#private-content-canned-policy-statement-values).

   ```
   {
       "Statement": [
           {
               "Resource": "base URL or stream name",
               "Condition": {
                   "DateLessThan": {
                       "AWS:EpochTime": ending date and time in Unix time format and UTC
                   }
               }
           }
       ]
   }
   ```

1. Hapus semua spasi kosong (termasuk tab dan karakter baris baru) dari pernyataan kebijakan. Anda mungkin harus memasukkan karakter escape dalam string di kode aplikasi.

#### Nilai yang Anda sebutkan dalam pernyataan kebijakan untuk URL yang ditandatangani dengan menggunakan kebijakan terekam
<a name="private-content-canned-policy-statement-values"></a>

Ketika Anda membuat pernyataan kebijakan untuk kebijakan terekam, Anda menentukan nilai-nilai berikut.

**Sumber Daya**  
Anda hanya dapat menentukan satu nilai untuk `Resource`.
URL dasar termasuk string kueri Anda, jika ada, tetapi tidak termasuk CloudFront `Expires`,, `Signature``Key-Pair-Id`, dan `Hash-Algorithm` parameter, misalnya:  
`https://d111111abcdef8.cloudfront.net/images/horizon.jpg?size=large&license=yes`  
Perhatikan hal-hal berikut:  
+ **Protokol** – Nilai harus dimulai dengan `http://` atau `https://`.
+ **Parameter string kueri** – Jika Anda tidak memiliki parameter string pencarian, hapus tanda tanya.
+ **Nama domain alternatif** – Jika Anda menentukan nama domain alternatif (CNAME) di URL, Anda harus menentukan nama domain alternatif saat merujuk file di halaman web atau aplikasi Anda. Jangan menentukan URL Amazon S3 untuk objek tersebut.

**DateLessThan**  
Tanggal dan waktu kedaluwarsa untuk URL dalam format waktu Unix (dalam detik) dan Waktu Universal Terkoordinasi (UTC). Misalnya, 1 Januari 2026 10:00 UTC mengkonversi ke 1767290400 dalam format waktu Unix.  
Nilai ini harus cocok dengan nilai `Expires` parameter string kueri dalam URL yang ditandatangani. Jangan melampirkan nilai dalam tanda petik.  
Untuk informasi selengkapnya, lihat [Saat CloudFront memeriksa tanggal dan waktu kedaluwarsa di URL yang ditandatangani](private-content-signed-urls.md#private-content-check-expiration).

#### Contoh pernyataan kebijakan untuk URL yang ditandatangani yang menggunakan kebijakan terekam
<a name="private-content-canned-policy-creating-policy-statement-example"></a>

Saat Anda menggunakan contoh pernyataan kebijakan berikut di URL yang ditandatangani, pengguna dapat mengakses file tersebut `https://d111111abcdef8.cloudfront.net/horizon.jpg` hingga 1 Januari 2026 10:00 UTC:

```
{
    "Statement": [
        {
            "Resource": "https://d111111abcdef8.cloudfront.net/horizon.jpg?size=large&license=yes",
            "Condition": {
                "DateLessThan": {
                    "AWS:EpochTime": 1767290400
                }
            }
        }
    ]
}
```

### Membuat tanda tangan untuk URL yang ditandatangani yang menggunakan kebijakan kalengan
<a name="private-content-canned-policy-signing-policy-statement"></a>

Untuk membuat nilai untuk `Signature` parameter dalam URL yang ditandatangani, Anda telah dan menandatangani pernyataan kebijakan yang Anda buat di [Membuat pernyataan kebijakan untuk URL yang ditandatangani yang menggunakan kebijakan yang dikalengkan](#private-content-canned-policy-creating-policy-statement).

Untuk informasi tambahan dan contoh cara membuat, menandatangani, dan mengkode pernyataan kebijakan, lihat:
+ [Perintah Linux dan OpenSSL untuk pengkodean dan enkripsi base64](private-content-linux-openssl.md)
+ [Contoh kode untuk membuat tanda tangan untuk URL yang ditandatangani](PrivateCFSignatureCodeAndExamples.md)

**catatan**  
Contoh terkait menggunakan SHA-1 secara default. Untuk menggunakan SHA-256 sebagai gantinya, ganti `sha1` dengan `sha256` perintah OpenSSL dan sertakan `Hash-Algorithm=SHA256` parameter kueri di URL yang ditandatangani.<a name="private-content-canned-policy-creating-signature-download-procedure"></a>

**Opsi 1: Untuk membuat tanda tangan dengan menggunakan kebijakan terekam**

1. Gunakan fungsi hash SHA-1 atau SHA-256 dan kunci pribadi RSA atau ECDSA yang dihasilkan untuk melakukan hash dan menandatangani pernyataan kebijakan yang Anda buat dalam prosedur. [Untuk membuat pernyataan kebijakan untuk URL yang ditandatangani menggunakan kebijakan terekam](#private-content-canned-policy-creating-policy-statement-procedure) Gunakan versi pernyataan kebijakan yang tidak lagi menyertakan spasi kosong.

   Jika Anda menggunakan SHA-256, Anda harus menyertakan `&Hash-Algorithm=SHA256` dalam URL yang ditandatangani.

   Untuk kunci privat yang diperlukan oleh fungsi hash, gunakan kunci pribadi yang kunci publiknya berada dalam grup kunci yang dipercaya aktif untuk distribusi.
**catatan**  
Metode yang Anda gunakan untuk men-emuk dan menandatangani pernyataan kebijakan tergantung pada bahasa pemrograman dan platform Anda. Untuk kode sampel, lihat [Contoh kode untuk membuat tanda tangan untuk URL yang ditandatangani](PrivateCFSignatureCodeAndExamples.md).

1. Hapus spasi kosong (termasuk tab dan karakter baris baru) dari string hash dan ditandatangani.

1. Base64 mengodekan string menggunakan pengodean base64 MIME. Untuk informasi selengkapnya, lihat [Bagian 6.8, Base64 Content-Transfer-Encoding](https://tools.ietf.org/html/rfc2045#section-6.8) di *RFC 2045, MIME (Ekstensi Surat Internet Serbaguna) Bagian Satu:* Format Badan Pesan Internet.

1. Ganti karakter yang tidak valid dalam string kueri URL dengan karakter yang valid. Tabel berikut mencantumkan karakter yang tidak valid dan valid.  
****    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonCloudFront/latest/DeveloperGuide/private-content-creating-signed-url-canned-policy.html)

1. Tambahkan nilai yang dihasilkan ke URL Anda yang ditandatangani setelah `&Signature=`, dan kembali ke [Untuk membuat URL yang ditandatangani menggunakan kebijakan terekam](#private-content-creating-signed-url-canned-policy-procedure) untuk menyelesaikan penyatuan bagian URL yang Anda tanda tangani.

# Membuat URL yang ditandatangani menggunakan kebijakan khusus
<a name="private-content-creating-signed-url-custom-policy"></a>

Untuk membuat URL yang ditandatangani menggunakan kebijakan kustom, selesaikan prosedur berikut.<a name="private-content-creating-signed-url-custom-policy-procedure"></a>

**Untuk membuat URL yang ditandatangani menggunakan kebijakan kustom**

1. Jika Anda menggunakan .NET atau Java untuk membuat ditandatangani URLs, dan jika Anda belum memformat ulang kunci pribadi untuk key pair Anda dari format.pem default ke format yang kompatibel dengan.NET atau dengan Java, lakukan sekarang. Untuk informasi selengkapnya, lihat [Memformat ulang kunci pribadi (hanya .NET dan Java)](private-content-trusted-signers.md#private-content-reformatting-private-key).

1. Menggabungkan nilai-nilai berikut. Anda dapat menggunakan format dalam contoh URL yang ditandatangani ini.

   

   ```
   https://d111111abcdef8.cloudfront.net/image.jpg?color=red&size=medium&Policy=eyANCiAgICEXAMPLEW1lbnQiOiBbeyANCiAgICAgICJSZXNvdXJjZSI6Imh0dHA6Ly9kemJlc3FtN3VuMW0wLmNsb3VkZnJvbnQubmV0L2RlbW8ucGhwIiwgDQogICAgICAiQ29uZGl0aW9uIjp7IA0KICAgICAgICAgIklwQWRkcmVzcyI6eyJBV1M6U291cmNlSXAiOiIyMDcuMTcxLjE4MC4xMDEvMzIifSwNCiAgICAgICAgICJEYXRlR3JlYXRlclRoYW4iOnsiQVdTOkVwb2NoVGltZSI6MTI5Njg2MDE3Nn0sDQogICAgICAgICAiRGF0ZUxlc3NUaGFuIjp7IkFXUzpFcG9jaFRpbWUiOjEyOTY4NjAyMjZ9DQogICAgICB9IA0KICAgfV0gDQp9DQo&Signature=nitfHRCrtziwO2HwPfWw~yYDhUF5EwRunQA-j19DzZrvDh6hQ73lDx~-ar3UocvvRQVw6EkC~GdpGQyyOSKQim-TxAnW7d8F5Kkai9HVx0FIu-5jcQb0UEmatEXAMPLE3ReXySpLSMj0yCd3ZAB4UcBCAqEijkytL6f3fVYNGQI6&Key-Pair-Id=K2JCJMDEHXQW5F&Hash-Algorithm=SHA256
   ```

   Hapus semua spasi kosong (termasuk tab dan karakter baris baru). Anda mungkin harus memasukkan karakter escape dalam string di kode aplikasi. Semua nilai memiliki tipe`String`.  
**1. *Base URL for the file***  
URL dasar adalah CloudFront URL yang akan Anda gunakan untuk mengakses file jika Anda tidak menggunakan tanda tangan URLs, termasuk parameter string kueri Anda sendiri, jika ada. Pada contoh sebelumnya, URL dasar adalah. `https://d111111abcdef8.cloudfront.net/image.jpg` Untuk informasi selengkapnya tentang format URLs untuk distribusi, lihat[Sesuaikan format URL untuk file di CloudFront](LinkFormat.md).  
Contoh berikut menunjukkan nilai yang Anda tentukan untuk distribusi.  
   +  CloudFront URL berikut adalah untuk file gambar dalam distribusi (menggunakan nama CloudFront domain). Perhatikan bahwa `image.jpg` dalam `images` direktori. Jalur menuju file dalam URL harus sesuai dengan alur menuju file pada server HTTP Anda atau pada buket Amazon S3.

     `https://d111111abcdef8.cloudfront.net/images/image.jpg`
   +  CloudFront URL berikut mencakup string kueri:

     `https://d111111abcdef8.cloudfront.net/images/image.jpg?size=large`
   + Berikut ini CloudFront URLs adalah untuk file gambar dalam distribusi. Keduanya menggunakan nama domain alternatif; yang kedua menyertakan string kueri:

     `https://www.example.com/images/image.jpg`

     `https://www.example.com/images/image.jpg?color=red`
   +  CloudFront URL berikut adalah untuk file gambar dalam distribusi yang menggunakan nama domain alternatif dan protokol HTTPS:

     `https://www.example.com/images/image.jpg`  
**2. `?`**  
`?`Ini menunjukkan bahwa parameter string kueri mengikuti URL dasar. Sertakan `?` bahkan jika Anda tidak menentukan parameter kueri apa pun.  
Anda dapat menentukan parameter kueri berikut dalam urutan apa pun.  
**3. *Your query string parameters, if any*`&`**  
(Opsional) Anda dapat memasukkan parameter string kueri Anda sendiri. Untuk melakukannya, tambahkan ampersand (&) di antara masing-masing, seperti. `color=red&size=medium` Anda dapat menentukan parameter string kueri dalam urutan apa pun dalam URL.  
Parameter string kueri Anda tidak dapat diberi nama`Policy`,`Signature`,`Key-Pair-Id`, atau`Hash-Algorithm`.
Jika Anda menambahkan parameter Anda sendiri, tambahkan `&` setelah masing-masing, termasuk yang terakhir.   
**4. `Policy=`*base64 encoded version of policy statement***  
Pernyataan kebijakan Anda dalam format JSON, dengan spasi kosong dihapus, lalu base64 dikodekan. Untuk informasi selengkapnya, lihat [Membuat pernyataan kebijakan untuk URL yang ditandatangani yang menggunakan kebijakan kustom](#private-content-custom-policy-statement).  
Pernyataan kebijakan mengontrol akses yang diberikan oleh URL yang ditandatangani kepada pengguna. Ini mencakup URL file, tanggal dan waktu kedaluwarsa, tanggal dan waktu opsional di mana URL menjadi valid, dan alamat IP opsional atau rentang alamat IP yang diizinkan untuk mengakses file.  
**5. `&Signature=`*hashed and signed version of the policy statement***  
Versi yang di-hash, ditandatangani, dan dikodekan base64 dari pernyataan kebijakan JSON. Untuk informasi selengkapnya, lihat [Membuat tanda tangan untuk URL yang ditandatangani yang menggunakan kebijakan kustom](#private-content-custom-policy-creating-signature).  
**6. `&Key-Pair-Id=`*public key ID for the CloudFront public key whose corresponding private key you're using to generate the signature***  
ID untuk kunci CloudFront publik, misalnya,`K2JCJMDEHXQW5F`. ID kunci publik memberi tahu kunci publik CloudFront mana yang akan digunakan untuk memvalidasi URL yang ditandatangani. CloudFrontmembandingkan informasi dalam tanda tangan dengan informasi dalam pernyataan kebijakan untuk memverifikasi bahwa URL belum dirusak.  
Kunci publik ini harus dimiliki oleh kelompok kunci yang merupakan signer tepercaya dalam distribusi. Untuk informasi selengkapnya, lihat [Tentukan penandatangan yang dapat membuat cookie yang ditandatangani URLs dan ditandatangani](private-content-trusted-signers.md).  
**7. `&Hash-Algorithm=`*SHA1 or SHA256***  
(Opsional) Algoritma hash yang digunakan untuk membuat tanda tangan. Nilai yang didukung adalah `SHA1` dan `SHA256`. Jika Anda tidak menentukan parameter ini, CloudFront defaultnya. `SHA1`

## Membuat pernyataan kebijakan untuk URL yang ditandatangani yang menggunakan kebijakan kustom
<a name="private-content-custom-policy-statement"></a>

Selesaikan langkah-langkah berikut untuk membuat pernyataan kebijakan untuk URL yang ditandatangani yang menggunakan kebijakan kustom.

Misalnya pernyataan kebijakan yang mengontrol akses ke file dalam berbagai cara, lihat[Contoh pernyataan kebijakan untuk URL yang ditandatangani menggunakan kebijakan kustom](#private-content-custom-policy-statement-examples).<a name="private-content-custom-policy-creating-policy-procedure"></a>

**Untuk membuat pernyataan kebijakan untuk URL yang ditandatangani menggunakan kebijakan kustom**

1. Buat pernyataan kebijakan dengan menggunakan format JSON berikut. Ganti simbol kurang dari (`<`) dan lebih besar dari (`>`), dan deskripsi di dalamnya, dengan nilai Anda sendiri. Untuk informasi selengkapnya, lihat [Nilai yang Anda sebutkan dalam pernyataan kebijakan untuk URL yang ditandatangani menggunakan kebijakan khusus](#private-content-custom-policy-statement-values).

   ```
   {
       "Statement": [
           {
               "Resource": "<Optional but recommended: URL of the file>",
               "Condition": {
                   "DateLessThan": {
   	                "AWS:EpochTime": <Required: ending date and time in Unix time format and UTC>
                   },
                   "DateGreaterThan": {
   	                "AWS:EpochTime": <Optional: beginning date and time in Unix time format and UTC>
                   },
                   "IpAddress": {
   	                "AWS:SourceIp": "<Optional: IP address>"
                   }
               }
           }
       ]
   }
   ```

   Perhatikan hal-hal berikut:
   + Anda hanya dapat memasukkan satu pernyataan dalam kebijakan.
   + Gunakan pengkodean karakter UTF-8.
   + Sertakan semua nama tanda baca dan parameter persis seperti yang ditentukan. Singkatan untuk nama parameter tidak diterima.
   + Urutan parameter di `Condition` tidak masalah.
   + Untuk informasi tentang nilai untuk `Resource`, `DateLessThan`, `DateGreaterThan`, dan `IpAddress`, lihat [Nilai yang Anda sebutkan dalam pernyataan kebijakan untuk URL yang ditandatangani menggunakan kebijakan khusus](#private-content-custom-policy-statement-values).

1. Hapus semua spasi kosong (termasuk tab dan karakter baris baru) dari pernyataan kebijakan. Anda mungkin harus memasukkan karakter escape dalam string di kode aplikasi.

1. Base64 mengodekan pernyataan kebijakan menggunakan pengodean base64 MIME. Untuk informasi selengkapnya, lihat [Bagian 6.8, Base64 Content-Transfer-Encoding](https://tools.ietf.org/html/rfc2045#section-6.8) di *RFC 2045, MIME (Ekstensi Surat Internet Serbaguna) Bagian Satu:* Format Badan Pesan Internet.

1. Ganti karakter yang tidak valid dalam string kueri URL dengan karakter yang valid. Tabel berikut mencantumkan karakter yang tidak valid dan valid.  
****    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonCloudFront/latest/DeveloperGuide/private-content-creating-signed-url-custom-policy.html)

1. Tambahkan nilai yang dihasilkan ke URL Anda yang ditandatangani setelah `Policy=`.

1. Buat tanda tangan untuk URL yang ditandatangani dengan melakukan, menandatangani, dan memberikan kode dasar64 untuk pernyataan kebijakan. Untuk informasi selengkapnya, lihat [Membuat tanda tangan untuk URL yang ditandatangani yang menggunakan kebijakan kustom](#private-content-custom-policy-creating-signature).

### Nilai yang Anda sebutkan dalam pernyataan kebijakan untuk URL yang ditandatangani menggunakan kebijakan khusus
<a name="private-content-custom-policy-statement-values"></a>

Saat Anda membuat pernyataan kebijakan untuk kebijakan kustom, Anda menentukan nilai berikut.

**Sumber daya**  
URL, termasuk string kueri apa pun, tetapi tidak termasuk CloudFront `Policy`,, `Signature``Key-Pair-Id`, dan `Hash-Algorithm` parameter. Contoh:  
`https://d111111abcdef8.cloudfront.net/images/horizon.jpg\?size=large&license=yes`  
Anda hanya dapat menentukan satu nilai URL untuk`Resource`.  
Anda dapat menghilangkan `Resource` parameter dalam kebijakan, tetapi melakukannya berarti siapa pun yang memiliki URL yang ditandatangani dapat mengakses *semua* file dalam distribusi *apa pun* yang terkait dengan key pair yang Anda gunakan untuk membuat URL yang ditandatangani.
Perhatikan hal-hal berikut:  
+ **Protokol** – Nilai harus dimulai dengan `http://`, `https://`, atau `*://`.
+ **Parameter string kueri** - Jika URL memiliki parameter string kueri, jangan gunakan karakter garis miring terbalik (`\`) untuk menghindari karakter tanda tanya (`?`) yang memulai string kueri. Contoh:

  `https://d111111abcdef8.cloudfront.net/images/horizon.jpg?size=large&license=yes`
+ **Karakter wildcard** — Anda dapat menggunakan karakter wildcard di URL dalam kebijakan. Karakter wildcard berikut didukung:
  + asterisk (`*`), yang cocok dengan nol atau lebih karakter
  + tanda tanya (`?`), yang cocok persis dengan satu karakter

  Saat CloudFront mencocokkan URL dalam kebijakan dengan URL dalam permintaan HTTP, URL dalam kebijakan dibagi menjadi empat bagian—protokol, domain, jalur, dan string kueri—sebagai berikut:

  `[protocol]://[domain]/[path]\?[query string]`

  Bila Anda menggunakan karakter wildcard di URL dalam kebijakan, pencocokan wildcard hanya berlaku dalam batas bagian yang berisi wildcard. Misalnya, pertimbangkan URL ini dalam kebijakan:

  `https://www.example.com/hello*world`

  Dalam contoh ini, wildcard asterisk (`*`) hanya berlaku di bagian jalur, sehingga cocok dengan URLs `https://www.example.com/helloworld` dan`https://www.example.com/hello-world`, tetapi tidak cocok dengan URL. `https://www.example.net/hello?world`

  Pengecualian berikut berlaku untuk batas bagian untuk pencocokan wildcard:
  + Tanda bintang di bagian jalur menyiratkan tanda bintang di bagian string kueri. Misalnya, `http://example.com/hello*` setara dengan `http://example.com/hello*\?*`.
  + Tanda bintang tertinggal di bagian domain menyiratkan tanda bintang di bagian jalur dan string kueri. Misalnya, `http://example.com*` setara dengan `http://example.com*/*\?*`.
  + URL dalam kebijakan dapat menghilangkan bagian protokol dan memulai dengan tanda bintang di bagian domain. Dalam hal ini, bagian protokol secara implisit diatur ke tanda bintang. Misalnya, URL `*example.com` dalam kebijakan setara dengan`*://*example.com/`.
  + Tanda bintang dengan sendirinya (`"Resource": "*"`) cocok dengan URL apa pun.

  Misalnya, nilai: `https://d111111abcdef8.cloudfront.net/*game_download.zip*` dalam kebijakan cocok dengan semua hal berikut URLs:
  + `https://d111111abcdef8.cloudfront.net/game_download.zip`
  + `https://d111111abcdef8.cloudfront.net/example_game_download.zip?license=yes`
  + `https://d111111abcdef8.cloudfront.net/test_game_download.zip?license=temp`
+ **Nama domain alternatif** — Jika Anda menentukan nama domain alternatif (CNAME) di URL dalam kebijakan, permintaan HTTP harus menggunakan nama domain alternatif di halaman web atau aplikasi Anda. Jangan tentukan URL Amazon S3 untuk file dalam kebijakan.

**DateLessThan**  
Tanggal dan waktu kedaluwarsa untuk URL dalam format waktu Unix (dalam detik) dan Waktu Universal Terkoordinasi (UTC). Dalam kebijakan, jangan lampirkan nilai dalam tanda kutip. Untuk informasi tentang UTC, lihat [Tanggal dan Waktu di Internet: Stempel](https://tools.ietf.org/html/rfc3339) Waktu.  
Misalnya, 31 Januari 2023 10:00 UTC dikonversi ke 1675159200 dalam format waktu Unix.  
Ini adalah satu-satunya parameter yang diperlukan di `Condition` bagian ini. CloudFront memerlukan nilai ini untuk mencegah pengguna memiliki akses permanen ke konten pribadi Anda.  
Untuk informasi selengkapnya, lihat [Saat CloudFront memeriksa tanggal dan waktu kedaluwarsa di URL yang ditandatangani](private-content-signed-urls.md#private-content-check-expiration)

**DateGreaterThan (Opsional)**  
Tanggal dan waktu mulai opsional untuk URL dalam format waktu Unix (dalam detik) dan Waktu Universal Terkoordinasi (UTC). Pengguna tidak diizinkan untuk mengakses file pada atau sebelum tanggal dan waktu yang ditentukan. Jangan melampirkan nilai dalam tanda petik. 

**IpAddress (Opsional)**  
Alamat IP klien yang membuat permintaan HTTP. Perhatikan hal-hal berikut:  
+ Untuk mengizinkan alamat IP mengakses file, hapus `IpAddress` parameter.
+ Anda dapat menentukan salah satu alamat IP atau satu rentang alamat IP. Anda tidak dapat menggunakan kebijakan untuk mengizinkan akses jika alamat IP klien berada di salah satu dari dua rentang terpisah.
+ Untuk memungkinkan akses dari satu alamat IP, Anda menentukan:

  `"`*IPv4 IP address*`/32"`
+ Anda harus menentukan rentang alamat IP dalam format IPv4 CIDR standar (misalnya,`192.0.2.0/24`). Untuk informasi selengkapnya, lihat [Classless Inter-domain Routing (CIDR): Rencana Penetapan dan Agregasi Alamat Internet](https://tools.ietf.org/html/rfc4632).
**penting**  
Alamat IP dalam IPv6 format, seperti 2001:0 db 8:85 a3: :8a2e: 0370:7334, tidak didukung. 

  Jika Anda menggunakan kebijakan khusus yang menyertakan`IpAddress`, jangan aktifkan IPv6 distribusi. Jika Anda ingin membatasi akses ke sebagian konten dengan alamat IP dan dukungan IPv6 Anda dapat membuat dua distribusi untuk konten lain. Untuk informasi lebih lanjut, lihat [Aktifkan IPv6 (permintaan penampil)](DownloadDistValuesGeneral.md#DownloadDistValuesEnableIPv6) dalam topik [Semua referensi pengaturan distribusi](distribution-web-values-specify.md).

## Contoh pernyataan kebijakan untuk URL yang ditandatangani menggunakan kebijakan kustom
<a name="private-content-custom-policy-statement-examples"></a>

Contoh pernyataan kebijakan berikut menunjukkan cara mengontrol akses ke file tertentu, semua file di direktori, atau semua file yang terkait dengan ID pasangan kunci. Contoh ini juga menunjukkan cara mengontrol akses dari alamat IP individu atau serangkaian alamat IP, dan cara mencegah pengguna menggunakan URL yang ditandatangani setelah tanggal dan waktu yang ditentukan.

Jika Anda menyalin dan menempelkan salah satu contoh ini, hapus spasi kosong (termasuk tab dan karakter baris baru), ganti nilai dengan nilai Anda sendiri, dan sertakan karakter baris baru setelah tanda kurung kurung penutup (). `}`

Untuk informasi selengkapnya, lihat [Nilai yang Anda sebutkan dalam pernyataan kebijakan untuk URL yang ditandatangani menggunakan kebijakan khusus](#private-content-custom-policy-statement-values).

**Topics**
+ [Contoh pernyataan kebijakan: Akses satu file dari berbagai alamat IP](#private-content-custom-policy-statement-example-one-object)
+ [Contoh pernyataan kebijakan: Akses semua file dalam direktori dari berbagai alamat IP](#private-content-custom-policy-statement-example-all-objects)
+ [Contoh pernyataan kebijakan: Akses semua file yang terkait dengan ID key pair dari satu alamat IP](#private-content-custom-policy-statement-example-one-ip)

### Contoh pernyataan kebijakan: Akses satu file dari berbagai alamat IP
<a name="private-content-custom-policy-statement-example-one-object"></a>

Contoh kebijakan kustom berikut dalam URL yang ditandatangani menetapkan bahwa pengguna dapat mengakses file `https://d111111abcdef8.cloudfront.net/game_download.zip` dari alamat IP dalam rentang `192.0.2.0/24` hingga 31 Januari 2023 10:00 UTC:

```
{
    "Statement": [
        {
            "Resource": "https://d111111abcdef8.cloudfront.net/game_download.zip",
            "Condition": {
                "IpAddress": {
                    "AWS:SourceIp": "192.0.2.0/24"
                },
                "DateLessThan": {
                    "AWS:EpochTime": 1675159200
                }
            }
        }
    ]
}
```

### Contoh pernyataan kebijakan: Akses semua file dalam direktori dari berbagai alamat IP
<a name="private-content-custom-policy-statement-example-all-objects"></a>

Contoh kebijakan kustom berikut memungkinkan Anda membuat tanda tangan URLs untuk file apa pun di `training` direktori, seperti yang ditunjukkan oleh karakter wildcard asterisk (`*`) dalam parameter. `Resource` Pengguna dapat mengakses file dari alamat IP dalam kisaran `192.0.2.0/24` hingga 31 Januari 2023 10:00 UTC:

```
{
    "Statement": [
        {
            "Resource": "https://d111111abcdef8.cloudfront.net/training/*",
            "Condition": {
                "IpAddress": {
                    "AWS:SourceIp": "192.0.2.0/24"
                },
                "DateLessThan": {
                    "AWS:EpochTime": 1675159200
                }
            }
        }
    ]
}
```

Setiap URL yang ditandatangani tempat Anda menggunakan kebijakan ini memiliki URL yang mengidentifikasi file tertentu, misalnya:

`https://d111111abcdef8.cloudfront.net/training/orientation.pdf`

### Contoh pernyataan kebijakan: Akses semua file yang terkait dengan ID key pair dari satu alamat IP
<a name="private-content-custom-policy-statement-example-one-ip"></a>

Contoh kebijakan kustom berikut memungkinkan Anda membuat tanda tangan URLs untuk file apa pun yang terkait dengan distribusi apa pun, seperti yang ditunjukkan oleh karakter wildcard asterisk (`*`) dalam parameter. `Resource` URL yang ditandatangani harus menggunakan `https://` protokol, bukan`http://`. Pengguna harus menggunakan alamat IP `192.0.2.10/32`. (Nilai `192.0.2.10/32` dalam notasi CIDR mengacu pada alamat IP tunggal, `192.0.2.10`.) File hanya tersedia mulai 31 Januari 2023 10:00 UTC hingga 2 Februari 2023 10:00 UTC:

```
{
    "Statement": [
       {
            "Resource": "https://*",
            "Condition": {
                "IpAddress": {
                    "AWS:SourceIp": "192.0.2.10/32"
                },
                "DateGreaterThan": {
                    "AWS:EpochTime": 1675159200
                },
                "DateLessThan": {
                    "AWS:EpochTime": 1675332000
                }
            }
        }
    ]
}
```

Setiap URL bertanda tangan yang Anda gunakan kebijakan ini memiliki URL yang mengidentifikasi file tertentu dalam CloudFront distribusi tertentu, misalnya:

`https://d111111abcdef8.cloudfront.net/training/orientation.pdf`

URL yang ditandatangani juga menyertakan ID key pair, yang harus dikaitkan dengan grup kunci tepercaya dalam distribusi (d111111abcdef8.cloudfront.net) yang Anda tentukan di URL.

## Membuat tanda tangan untuk URL yang ditandatangani yang menggunakan kebijakan kustom
<a name="private-content-custom-policy-creating-signature"></a>

Tanda tangan untuk URL bertanda tangan yang menggunakan kebijakan kustom adalah versi salinan dokumen, ditandatangani, dan dikodekan base64 dari pernyataan kebijakan. Untuk membuat tanda tangan untuk kebijakan kustom, selesaikan langkah berikut.

Untuk informasi tambahan dan contoh cara membuat, menandatangani, dan mengkode pernyataan kebijakan, lihat:
+ [Perintah Linux dan OpenSSL untuk pengkodean dan enkripsi base64](private-content-linux-openssl.md)
+ [Contoh kode untuk membuat tanda tangan untuk URL yang ditandatangani](PrivateCFSignatureCodeAndExamples.md)

**catatan**  
Contoh terkait menggunakan SHA-1 secara default. Untuk menggunakan SHA-256 sebagai gantinya, ganti `sha1` dengan `sha256` perintah OpenSSL dan sertakan `Hash-Algorithm=SHA256` parameter kueri di URL yang ditandatangani.<a name="private-content-custom-policy-creating-signature-download-procedure"></a>

**Opsi 1: Untuk membuat tanda tangan dengan menggunakan kebijakan khusus**

1. Gunakan fungsi hash SHA-1 atau SHA-256 dan kunci pribadi RSA atau ECDSA yang dihasilkan untuk hash dan menandatangani pernyataan kebijakan JSON yang Anda buat dalam prosedur. [Untuk membuat pernyataan kebijakan untuk URL yang ditandatangani menggunakan kebijakan kustom](#private-content-custom-policy-creating-policy-procedure) Gunakan versi pernyataan kebijakan yang tidak lagi menyertakan spasi kosong tetapi belum dikodekan base64.

   Jika Anda menggunakan SHA-256, Anda harus menyertakan `&Hash-Algorithm=SHA256` dalam URL yang ditandatangani.

   Untuk kunci privat yang diperlukan oleh fungsi hash, gunakan kunci pribadi yang kunci publiknya berada dalam grup kunci yang dipercaya aktif untuk distribusi.
**catatan**  
Metode yang Anda gunakan untuk men-emuk dan menandatangani pernyataan kebijakan tergantung pada bahasa pemrograman dan platform Anda. Untuk kode sampel, lihat [Contoh kode untuk membuat tanda tangan untuk URL yang ditandatangani](PrivateCFSignatureCodeAndExamples.md).

1. Hapus spasi kosong (termasuk tab dan karakter baris baru) dari string hash dan ditandatangani.

1. Base64 mengodekan string menggunakan pengodean base64 MIME. Untuk informasi selengkapnya, lihat [Bagian 6.8, Base64 Content-Transfer-Encoding](https://tools.ietf.org/html/rfc2045#section-6.8) di *RFC 2045, MIME (Ekstensi Surat Internet Serbaguna) Bagian Satu:* Format Badan Pesan Internet.

1. Ganti karakter yang tidak valid dalam string kueri URL dengan karakter yang valid. Tabel berikut mencantumkan karakter yang tidak valid dan valid.  
****    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonCloudFront/latest/DeveloperGuide/private-content-creating-signed-url-custom-policy.html)

1. Tambahkan nilai yang dihasilkan ke URL Anda yang ditandatangani setelah `&Signature=`, dan kembali ke [Untuk membuat URL yang ditandatangani menggunakan kebijakan kustom](#private-content-creating-signed-url-custom-policy-procedure) untuk menyelesaikan penyatuan bagian URL yang Anda tanda tangani.

# Gunakan cookie yang ditandatangani
<a name="private-content-signed-cookies"></a>

CloudFront Cookie yang ditandatangani memungkinkan Anda untuk mengontrol siapa yang dapat mengakses konten Anda ketika Anda tidak ingin mengubah konten Anda saat ini URLs atau ketika Anda ingin memberikan akses ke beberapa file terbatas, misalnya, semua file di area pelanggan situs web. Topik ini menjelaskan pertimbangan saat menggunakan cookie yang ditandatangani dan menjelaskan cara mengatur cookie yang ditandatangani menggunakan kebijakan terekam dan kustom.

**Topics**
+ [Memutuskan untuk menggunakan kebijakan kalengan atau kustom untuk cookie yang ditandatangani](#private-content-choosing-canned-custom-cookies)
+ [Cara kerja cookie yang ditandatangani](#private-content-how-signed-cookies-work)
+ [Mencegah penyalahgunaan cookie yang ditandatangani](#private-content-signed-cookie-misuse)
+ [Saat CloudFront memeriksa tanggal dan waktu kedaluwarsa dalam cookie yang ditandatangani](#private-content-check-expiration-cookie)
+ [Kode sampel dan alat pihak ketiga](#private-content-overview-sample-code-cookies)
+ [Tetapkan cookie yang ditandatangani menggunakan kebijakan kalengan](private-content-setting-signed-cookie-canned-policy.md)
+ [Tetapkan cookie yang ditandatangani menggunakan kebijakan khusus](private-content-setting-signed-cookie-custom-policy.md)
+ [Buat cookie yang ditandatangani menggunakan PHP](signed-cookies-PHP.md)

## Memutuskan untuk menggunakan kebijakan kalengan atau kustom untuk cookie yang ditandatangani
<a name="private-content-choosing-canned-custom-cookies"></a>

Saat Anda membuat cookie bertanda tangan, Anda menulis pernyataan kebijakan dalam format JSON yang menetapkan batasan pada cookie yang ditandatangani, misalnya, berapa lama cookie valid. Anda dapat menggunakan kebijakan terekam atau kebijakan khusus. Tabel berikut membandingkan kebijakan terekam dan kustom:


****  

| Deskripsi | Kebijakan kalengan | Kebijakan khusus | 
| --- | --- | --- | 
| Anda dapat menggunakan kembali pernyataan kebijakan untuk beberapa file. Untuk menggunakan kembali pernyataan kebijakan, Anda harus menggunakan karakter wildcard dalam `Resource` objek. Untuk informasi lebih lanjut, lihat [Nilai yang Anda sebutkan dalam pernyataan kebijakan untuk kebijakan kustom untuk cookie yang ditandatangani](private-content-setting-signed-cookie-custom-policy.md#private-content-custom-policy-statement-cookies-values).)  | Tidak | Ya | 
| Anda dapat menentukan tanggal dan waktu pengguna dapat mulai mengakses konten Anda | Tidak | Ya (opsional) | 
| Anda dapat menentukan tanggal dan waktu saat pengguna tidak lagi dapat mengakses konten Anda | Ya | Ya | 
| Anda dapat menentukan alamat IP atau berbagai alamat IP pengguna yang dapat mengakses konten Anda | Tidak | Ya (opsional) | 

Untuk informasi tentang membuat cookie yang ditandatangani menggunakan kebijakan terekam, lihat [Tetapkan cookie yang ditandatangani menggunakan kebijakan kalengan](private-content-setting-signed-cookie-canned-policy.md).

Untuk informasi tentang membuat cookie yang ditandatangani menggunakan kebijakan kustom, lihat [Tetapkan cookie yang ditandatangani menggunakan kebijakan khusus](private-content-setting-signed-cookie-custom-policy.md).

## Cara kerja cookie yang ditandatangani
<a name="private-content-how-signed-cookies-work"></a>

Berikut adalah ikhtisar tentang cara Anda mengonfigurasi CloudFront cookie yang ditandatangani dan bagaimana CloudFront merespons ketika pengguna mengirimkan permintaan yang berisi cookie yang ditandatangani. 

1. Dalam CloudFront distribusi Anda, tentukan satu atau beberapa grup kunci tepercaya, yang berisi kunci publik yang CloudFront dapat digunakan untuk memverifikasi tanda tangan URL. Anda menggunakan kunci privat yang sesuai untuk menandatangani URLs.

   Untuk informasi selengkapnya, lihat [Tentukan penandatangan yang dapat membuat cookie yang ditandatangani URLs dan ditandatangani](private-content-trusted-signers.md).

1. Anda mengembangkan aplikasi untuk menentukan apakah pengguna harus memiliki akses ke konten Anda dan, jika demikian, untuk mengirim tiga `Set-Cookie` judul ke penampil. (Setiap `Set-Cookie` header hanya dapat berisi satu pasangan nama-nilai, dan cookie yang CloudFront ditandatangani memerlukan tiga pasangan nama-nilai.) Anda harus mengirim header `Set-Cookie` ke penampil sebelum penonton meminta konten privat Anda. Jika Anda mengatur waktu kedaluwarsa singkat pada cookie, Anda mungkin juga ingin mengirim tiga lagi `Set-Cookie` header dalam menanggapi permintaan berikutnya, sehingga pengguna terus memiliki akses.

   Biasanya, CloudFront distribusi Anda akan memiliki setidaknya dua perilaku cache, satu yang tidak memerlukan otentikasi dan satu lagi yang melakukannya. Laman kesalahan untuk bagian situs yang aman mencakup pengarah atau tautan ke halaman login.

   Jika Anda mengonfigurasi distribusi Anda ke file cache berdasarkan cookie, CloudFront tidak menyimpan file terpisah berdasarkan atribut dalam cookie yang ditandatangani.

1. Pengguna masuk ke situs web Anda dan membayar konten atau memenuhi beberapa persyaratan lain untuk akses.

1. Aplikasi Anda mengembalikan `Set-Cookie` judul di respons, dan penampil menyimpan pasangan nilai.

1. Pengguna meminta file.

   Browser pengguna atau penampil lain mendapatkan pasangan nilai dari langkah 4 dan menambahkannya ke permintaan dalam `Cookie` header. Ini adalah cookie yang ditandatangani.

1. CloudFront menggunakan kunci publik untuk memvalidasi tanda tangan dalam cookie yang ditandatangani dan untuk mengonfirmasi bahwa cookie belum dirusak. Jika tanda tangan tidak valid, permintaan ditolak.

   Jika tanda tangan dalam cookie valid, CloudFront lihat pernyataan kebijakan di cookie (atau buat jika Anda menggunakan kebijakan kalengan) untuk mengonfirmasi bahwa permintaan tersebut masih valid. Misalnya, jika Anda menentukan tanggal dan waktu awal dan akhir untuk cookie, CloudFront konfirmasikan bahwa pengguna mencoba mengakses konten Anda selama periode waktu yang ingin Anda izinkan akses.

   Jika permintaan memenuhi persyaratan dalam pernyataan kebijakan, CloudFront menyajikan konten Anda seperti halnya untuk konten yang tidak dibatasi: ini menentukan apakah file sudah berada di cache tepi, meneruskan permintaan ke asal jika perlu, dan mengembalikan file ke pengguna.

## Mencegah penyalahgunaan cookie yang ditandatangani
<a name="private-content-signed-cookie-misuse"></a>

Jika Anda menentukan `Domain` parameter dalam `Set-Cookie` tajuk, menentukan nilai paling tepat yang memungkinkan untuk mengurangi potensi akses oleh seseorang dengan nama domain akar yang sama. Misalnya, aplikasi.contoh.com lebih disukai ke contoh.com, terutama ketika Anda tidak mengontrol contoh.com. Ini membantu mencegah seseorang mengakses konten Anda dari www.example.com.

Untuk membantu mencegah jenis serangan ini, lakukan hal berikut:
+ Kecualikan `Expires` dan `Max-Age` sehingga `Set-Cookie` judul membuat cookie sesi. Cookie sesi secara otomatis dihapus ketika pengguna menutup peramban, yang mengurangi kemungkinan seseorang mendapatkan akses tanpa izin ke konten Anda.
+ Sertakan `Secure` sehingga cookie dienkripsi ketika penampil menyertakannya dalam permintaan.
+ Jika memungkinkan, gunakan kebijakan khusus dan sertakan alamat IP penampil.
+ Di `CloudFront-Expires` menentukan waktu kedaluwarsa yang paling pendek yang masuk akal berdasarkan berapa lama Anda ingin pengguna mengakses konten Anda.

## Saat CloudFront memeriksa tanggal dan waktu kedaluwarsa dalam cookie yang ditandatangani
<a name="private-content-check-expiration-cookie"></a>

Untuk menentukan apakah cookie yang ditandatangani masih valid, CloudFront periksa tanggal kedaluwarsa dan waktu dalam cookie pada saat permintaan HTTP. Jika klien mulai mengunduh file besar segera sebelum waktu kedaluwarsa, pengunduhan harus selesai meskipun waktu kedaluwarsa sudah lewat selama pengunduhan. Jika koneksi TCP menurun dan klien mencoba memulai ulang unduhan setelah waktu kedaluwarsa berlalu, pengunduhan akan gagal.

Jika klien menggunakan Range GETs untuk mendapatkan file dalam potongan yang lebih kecil, permintaan GET apa pun yang terjadi setelah waktu kedaluwarsa berlalu akan gagal. Untuk informasi lebih lanjut tentang Rentang GETs, lihat[Bagaimana CloudFront memproses permintaan sebagian untuk suatu objek (rentang GETs)](RangeGETs.md).

## Kode sampel dan alat pihak ketiga
<a name="private-content-overview-sample-code-cookies"></a>

Kode sampel untuk konten pribadi hanya menunjukkan cara membuat tanda tangan untuk ditandatangani URLs. Namun, proses untuk membuat tanda tangan untuk cookie yang ditandatangani sangat mirip, sehingga sebagian besar kode sampel masih relevan. Untuk informasi selengkapnya, lihat topik berikut: 
+ [Buat tanda tangan URL menggunakan Perl](CreateURLPerl.md)
+ [Buat tanda tangan URL menggunakan PHP](CreateURL_PHP.md)
+ [Buat tanda tangan URL menggunakan C\$1 dan .NET Framework](CreateSignatureInCSharp.md)
+ [Buat tanda tangan URL menggunakan Java](CFPrivateDistJavaDevelopment.md)

# Tetapkan cookie yang ditandatangani menggunakan kebijakan kalengan
<a name="private-content-setting-signed-cookie-canned-policy"></a>

Untuk mengatur cookie bertanda tangan dengan menggunakan kebijakan terekam, selesaikan langkah berikut. Untuk membuat tanda tangan, lihat [Membuat tanda tangan untuk cookie yang ditandatangani yang menggunakan kebijakan kalengan](#private-content-canned-policy-signature-cookies).<a name="private-content-setting-signed-cookie-canned-policy-procedure"></a>

**Untuk mengatur cookie bertanda tangan menggunakan kebijakan terekam**

1. Jika Anda menggunakan .NET atau Java untuk membuat cookie yang telah ditandatangani, dan jika Anda belum memformat ulang kunci pribadi untuk pasangan kunci Anda dari format .pem default ke format yang kompatibel dengan .NET atau dengan Java, lakukan sekarang. Untuk informasi selengkapnya, lihat [Memformat ulang kunci pribadi (hanya .NET dan Java)](private-content-trusted-signers.md#private-content-reformatting-private-key).

1. Program aplikasi Anda untuk mengirim tiga `Set-Cookie` header ke pemirsa yang disetujui (atau empat, jika Anda ingin menentukan algoritma hash). Anda perlu tiga `Set-Cookie` karena tiap `Set-Cookie` header hanya dapat berisi satu pasangan dengan nilai nama, dan CloudFront cookie yang ditandatangani memerlukan tiga pasangan nilai. Pasangan nama-nilai adalah: `CloudFront-Expires`, `CloudFront-Signature`, dan `CloudFront-Key-Pair-Id`. Anda dapat secara opsional menyertakan pasangan nama-nilai keempat,`CloudFront-Hash-Algorithm`, untuk menentukan algoritma hash yang digunakan untuk tanda tangan. Nilai harus ada di penampil sebelum pengguna membuat permintaan pertama untuk file yang ingin Anda kontrol akses. 
**catatan**  
Secara umum, kami sarankan Anda tidak memasukkan `Expires` dan `Max-Age` atribut. Kecuali atribut tersebut akan menyebabkan peramban menghapus cookie saat pengguna menutup peramban, yang mengurangi kemungkinan seseorang mendapatkan akses tanpa izin ke konten Anda. Untuk informasi selengkapnya, lihat [Mencegah penyalahgunaan cookie yang ditandatangani](private-content-signed-cookies.md#private-content-signed-cookie-misuse).

   **Nama atribut cookie peka huruf besar-kecil**. 

   Pemutusan jalur hanya disertakan untuk membuat atribut lebih mudah dibaca.

   ```
   Set-Cookie: 
   CloudFront-Expires=date and time in Unix time format (in seconds) and Coordinated Universal Time (UTC); 
   Domain=optional domain name; 
   Path=/optional directory path; 
   Secure; 
   HttpOnly
   
   Set-Cookie: 
   CloudFront-Signature=hashed and signed version of the policy statement; 
   Domain=optional domain name; 
   Path=/optional directory path; 
   Secure; 
   HttpOnly
   
   Set-Cookie: 
   CloudFront-Key-Pair-Id=public key ID for the CloudFront public key whose corresponding private key you're using to generate the signature; 
   Domain=optional domain name; 
   Path=/optional directory path; 
   Secure; 
   HttpOnly
   
   Set-Cookie: 
   CloudFront-Hash-Algorithm=SHA1 or SHA256; 
   Domain=optional domain name; 
   Path=/optional directory path; 
   Secure; 
   HttpOnly
   ```  
**(Opsional) `Domain`**  
Nama domain untuk file yang diminta. Jika Anda tidak menyebutkan `Domain` atribut, nilai default adalah nama domain di URL, dan hanya berlaku untuk nama domain tertentu, bukan subdomain. Jika Anda menentukan `Domain` , ini juga berlaku untuk subdomain. Titik utama pada nama domain (misalnya, `Domain=.example.com`) bersifat opsional. Selain itu, jika Anda menentukan `Domain` , nama domain di URL dan nilai `Domain` atribut harus cocok.  
Anda dapat menentukan nama domain yang CloudFront ditetapkan untuk distribusi Anda, misalnya, d111111abcdef8.cloudfront.net, tetapi Anda tidak dapat menentukan \$1.cloudfront.net untuk nama domain.  
Jika Anda ingin menggunakan nama domain alternatif seperti example.com di URLs, Anda harus menambahkan nama domain alternatif ke distribusi Anda terlepas dari apakah Anda menentukan atribut. `Domain` Untuk informasi lebih lanjut, lihat [Nama domain alternatif (CNAMEs)](DownloadDistValuesGeneral.md#DownloadDistValuesCNAME) dalam [Semua referensi pengaturan distribusi](distribution-web-values-specify.md) topik.  
**(Opsional) `Path`**  
Jalur untuk file yang diminta. Jika Anda tidak menyebutkan `Path` atribut, nilai default adalah alur di URL.  
**`Secure`**  
Meminta pemirsa mengenkripsi cookie sebelum mengirim permintaan. Kami menyarankan Anda mengirim `Set-Cookie` header melalui koneksi HTTPS untuk memastikan bahwa atribut cookie dilindungi dari man-in-the-middle serangan.  
**`HttpOnly`**  
Mendefinisikan bagaimana browser (jika didukung) berinteraksi dengan nilai cookie. Dengan`HttpOnly`, nilai cookie tidak dapat diakses JavaScript. Tindakan pencegahan ini dapat membantu mengurangi serangan cross-site scripting (XSS). Untuk informasi selengkapnya, lihat [Menggunakan cookie HTTP](https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies).  
**`CloudFront-Expires`**  
Tentukan tanggal dan waktu kedaluwarsa dalam format waktu Unix (dalam detik) dan Waktu Universal Terkoordinasi (UTC). Misalnya, 1 Januari 2026 10:00 UTC mengkonversi ke 1767290400 dalam format waktu Unix.   
Untuk menggunakan waktu epoch, tentukan bilangan bulat 64-bit untuk tanggal yang paling lambat `9223372036854775807` (Jumat, 11 April 2262 pukul 23:47:16.854 UTC).  
Untuk informasi tentang UTC, lihat *RFC 3339, Tanggal dan Waktu di Internet: Stempel Waktu*, [https://tools.ietf.org/html/rfc3339](https://tools.ietf.org/html/rfc3339).  
**`CloudFront-Signature`**  
Versi yang di-hash, ditandatangani, dan dikodekan base64 dari pernyataan kebijakan JSON. Untuk informasi selengkapnya, lihat [Membuat tanda tangan untuk cookie yang ditandatangani yang menggunakan kebijakan kalengan](#private-content-canned-policy-signature-cookies).  
**`CloudFront-Key-Pair-Id`**  
ID untuk kunci CloudFront publik, misalnya,`K2JCJMDEHXQW5F`. ID kunci publik memberi tahu kunci publik CloudFront mana yang akan digunakan untuk memvalidasi URL yang ditandatangani. CloudFront membandingkan informasi dalam tanda tangan dengan informasi dalam pernyataan kebijakan untuk memverifikasi bahwa URL belum dirusak.  
Kunci publik ini harus dimiliki oleh kelompok kunci yang merupakan signer tepercaya dalam distribusi. Untuk informasi selengkapnya, lihat [Tentukan penandatangan yang dapat membuat cookie yang ditandatangani URLs dan ditandatangani](private-content-trusted-signers.md).  
**`CloudFront-Hash-Algorithm`**  
(Opsional) Algoritma hash yang digunakan untuk membuat tanda tangan. Nilai yang didukung adalah `SHA1` dan `SHA256`. Jika Anda tidak menyertakan cookie ini, CloudFront defaultnya. `SHA1`

Contoh berikut menunjukkan `Set-Cookie` header untuk satu cookie yang ditandatangani saat Anda menggunakan nama domain yang terkait dengan distribusi Anda di URLs untuk file Anda:

```
Set-Cookie: CloudFront-Expires=1426500000; Domain=d111111abcdef8.cloudfront.net; Path=/images/*; Secure; HttpOnly
Set-Cookie: CloudFront-Signature=yXrSIgyQoeE4FBI4eMKF6ho~CA8_; Domain=d111111abcdef8.cloudfront.net; Path=/images/*; Secure; HttpOnly
Set-Cookie: CloudFront-Key-Pair-Id=K2JCJMDEHXQW5F; Domain=d111111abcdef8.cloudfront.net; Path=/images/*; Secure; HttpOnly
Set-Cookie: CloudFront-Hash-Algorithm=SHA256; Domain=d111111abcdef8.cloudfront.net; Path=/images/*; Secure; HttpOnly
```

Contoh berikut menunjukkan `Set-Cookie` header untuk satu cookie yang ditandatangani saat Anda menggunakan nama domain alternatif example.org URLs untuk file Anda:

```
Set-Cookie: CloudFront-Expires=1426500000; Domain=example.org; Path=/images/*; Secure; HttpOnly
Set-Cookie: CloudFront-Signature=yXrSIgyQoeE4FBI4eMKF6ho~CA8_; Domain=example.org; Path=/images/*; Secure; HttpOnly
Set-Cookie: CloudFront-Key-Pair-Id=K2JCJMDEHXQW5F; Domain=example.org; Path=/images/*; Secure; HttpOnly
Set-Cookie: CloudFront-Hash-Algorithm=SHA256; Domain=example.org; Path=/images/*; Secure; HttpOnly
```

Jika Anda ingin menggunakan nama domain alternatif seperti example.com di URLs, Anda harus menambahkan nama domain alternatif ke distribusi Anda terlepas dari apakah Anda menentukan atribut. `Domain` Untuk informasi selengkapnya, lihat [Nama domain alternatif (CNAMEs)](DownloadDistValuesGeneral.md#DownloadDistValuesCNAME) dalam topik [Semua referensi pengaturan distribusi](distribution-web-values-specify.md).

## Membuat tanda tangan untuk cookie yang ditandatangani yang menggunakan kebijakan kalengan
<a name="private-content-canned-policy-signature-cookies"></a>

Untuk membuat tanda tangan untuk cookie yang ditandatangani yang menggunakan kebijakan kalengan, selesaikan prosedur berikut.

**Topics**
+ [Membuat pernyataan kebijakan untuk cookie yang ditandatangani yang menggunakan kebijakan kalengan](#private-content-canned-policy-statement-cookies)
+ [Menandatangani pernyataan kebijakan untuk membuat tanda tangan untuk cookie yang ditandatangani yang menggunakan kebijakan kalengan](#private-content-canned-policy-cookies-signing-policy-statement)

### Membuat pernyataan kebijakan untuk cookie yang ditandatangani yang menggunakan kebijakan kalengan
<a name="private-content-canned-policy-statement-cookies"></a>

Saat Anda mengatur cookie bertanda tangan yang menggunakan kebijakan terekam, `CloudFront-Signature` atribut adalah versi yang di- hashed dan ditandatangani dari pernyataan kebijakan. Untuk cookie bertanda tangan yang menggunakan kebijakan terekam, Anda tidak menyertakan pernyataan kebijakan di `Set-Cookie` seperti yang Anda lakukan untuk cookie bertanda tangan yang menggunakan kebijakan kustom. Untuk membuat pernyataan kebijakan, selesaikan langkah berikut.<a name="private-content-canned-policy-statement-cookies-procedure"></a>

**Untuk membuat pernyataan kebijakan untuk cookie bertanda tangan yang menggunakan kebijakan terekam**

1. Susun pernyataan kebijakan dengan menggunakan format JSON berikut dan menggunakan pengkodean karakter UTF-8. Sertakan semua tanda baca dan nilai literal lainnya persis seperti yang ditentukan. Untuk informasi tentang `Resource` dan `DateLessThan` parameter, lihat [Nilai yang Anda sebutkan dalam pernyataan kebijakan untuk kebijakan terekam untuk cookie yang ditandatangani](#private-content-canned-policy-statement-cookies-values).

   ```
   {
       "Statement": [
           {
               "Resource": "base URL or stream name",
               "Condition": {
                   "DateLessThan": {
                       "AWS:EpochTime": ending date and time in Unix time format and UTC
                   }
               }
           }
       ]
   }
   ```

1. Hapus semua spasi kosong (termasuk tab dan karakter baris baru) dari pernyataan kebijakan. Anda mungkin harus memasukkan karakter escape dalam string di kode aplikasi.

#### Nilai yang Anda sebutkan dalam pernyataan kebijakan untuk kebijakan terekam untuk cookie yang ditandatangani
<a name="private-content-canned-policy-statement-cookies-values"></a>

Ketika Anda membuat pernyataan kebijakan untuk kebijakan terekam, Anda menentukan nilai-nilai berikut:

**Sumber Daya**  
URL dasar termasuk string pencarian Anda, jika ada, misalnya:  
`https://d111111abcdef8.cloudfront.net/images/horizon.jpg?size=large&license=yes`  
Anda hanya dapat menentukan satu nilai untuk `Resource`.  
Perhatikan hal-hal berikut:  
+ **Protokol** – Nilai harus dimulai dengan `http://` atau `https://`.
+ **Parameter string kueri** – Jika Anda tidak memiliki parameter string pencarian, hapus tanda tanya.
+ **Nama domain alternatif** – Jika Anda menentukan nama domain alternatif (CNAME) di URL, Anda harus menentukan nama domain alternatif saat merujuk file di halaman web atau aplikasi Anda. Jangan tentukan URL Amazon S3 untuk file tersebut.

**DateLessThan**  
Tanggal dan waktu kedaluwarsa untuk URL dalam format waktu Unix (dalam detik) dan Waktu Universal Terkoordinasi (UTC). Jangan melampirkan nilai dalam tanda petik.  
Misalnya, 16 Maret 2015 10.00 UTC dikonversi menjadi 1426500000 dalam format waktu Unix.  
Nilai ini harus cocok dengan nilai `CloudFront-Expires` dalam `Set-Cookie` header. Jangan melampirkan nilai dalam tanda petik.  
Untuk informasi selengkapnya, lihat [Saat CloudFront memeriksa tanggal dan waktu kedaluwarsa dalam cookie yang ditandatangani](private-content-signed-cookies.md#private-content-check-expiration-cookie).

#### Contoh pernyataan kebijakan untuk kebijakan terekam
<a name="private-content-canned-policy-cookies-sample-policy-statement"></a>

Saat Anda menggunakan contoh pernyataan kebijakan berikut dalam cookie yang ditandatangani, pengguna dapat mengakses file `https://d111111abcdef8.cloudfront.net/horizon.jpg` hingga 16 Maret 2015 10.00 UTC:

```
{
    "Statement": [
        {
            "Resource": "https://d111111abcdef8.cloudfront.net/horizon.jpg?size=large&license=yes",
            "Condition": {
                "DateLessThan": {
                    "AWS:EpochTime": 1426500000
                }
            }
        }
    ]
}
```

### Menandatangani pernyataan kebijakan untuk membuat tanda tangan untuk cookie yang ditandatangani yang menggunakan kebijakan kalengan
<a name="private-content-canned-policy-cookies-signing-policy-statement"></a>

Untuk membuat nilai untuk `CloudFront-Signature` atribut dalam `Set-Cookie` tajuk, Anda memiliki dan menandatangani pernyataan kebijakan yang Anda buat di [Untuk membuat pernyataan kebijakan untuk cookie bertanda tangan yang menggunakan kebijakan terekam](#private-content-canned-policy-statement-cookies-procedure). 

Untuk informasi tambahan dan contoh cara membuat, menandatangani, dan mengodekan pernyataan kebijakan, lihat topik berikut:
+ [Perintah Linux dan OpenSSL untuk pengkodean dan enkripsi base64](private-content-linux-openssl.md)
+ [Contoh kode untuk membuat tanda tangan untuk URL yang ditandatangani](PrivateCFSignatureCodeAndExamples.md)

**catatan**  
Contoh terkait menggunakan SHA-1 secara default. Untuk menggunakan SHA-256 sebagai gantinya, ganti `sha1` dengan `sha256` perintah OpenSSL dan sertakan cookie dengan `CloudFront-Hash-Algorithm` nilai. `SHA256`<a name="private-content-canned-policy-cookie-creating-signature-procedure"></a>

**Untuk membuat tanda tangan untuk cookie yang ditandatangani menggunakan kebijakan terekam**

1. Gunakan fungsi hash SHA-1 atau SHA-256 dan RSA untuk hash dan tandatangani pernyataan kebijakan yang Anda buat dalam prosedur. [Untuk membuat pernyataan kebijakan untuk cookie bertanda tangan yang menggunakan kebijakan terekam](#private-content-canned-policy-statement-cookies-procedure) Gunakan versi pernyataan kebijakan yang tidak lagi menyertakan spasi kosong.

   Jika Anda menggunakan SHA-256, Anda harus menyertakan `CloudFront-Hash-Algorithm` cookie dengan nilai. `SHA256`

   Untuk kunci privat yang diperlukan oleh fungsi hash, gunakan kunci pribadi yang kunci publiknya berada dalam grup kunci yang dipercaya aktif untuk distribusi.
**catatan**  
Metode yang Anda gunakan untuk men-emuk dan menandatangani pernyataan kebijakan tergantung pada bahasa pemrograman dan platform Anda. Untuk kode sampel, lihat [Contoh kode untuk membuat tanda tangan untuk URL yang ditandatangani](PrivateCFSignatureCodeAndExamples.md).

1. Hapus spasi kosong (termasuk tab dan karakter baris baru) dari string hash dan ditandatangani.

1. Base64 mengodekan string menggunakan pengodean base64 MIME. Untuk informasi selengkapnya, lihat [Bagian 6.8, Base64 Content-Transfer-Encoding](https://tools.ietf.org/html/rfc2045#section-6.8) di *RFC 2045, MIME (Ekstensi Surat Internet Serbaguna) Bagian Satu:* Format Badan Pesan Internet.

1. Ganti karakter yang tidak valid dalam string kueri URL dengan karakter yang valid. Tabel berikut mencantumkan karakter yang tidak valid dan valid.  
****    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonCloudFront/latest/DeveloperGuide/private-content-setting-signed-cookie-canned-policy.html)

1. Sertakan nilai yang dihasilkan dalam `Set-Cookie` header untuk `CloudFront-Signature` pasangan yang bernilai. Lalu kembali ke [Untuk mengatur cookie bertanda tangan menggunakan kebijakan terekam](#private-content-setting-signed-cookie-canned-policy-procedure) tambahkan `Set-Cookie` header untuk `CloudFront-Key-Pair-Id`.

# Tetapkan cookie yang ditandatangani menggunakan kebijakan khusus
<a name="private-content-setting-signed-cookie-custom-policy"></a>

Untuk mengatur cookie bertanda tangan yang menggunakan kebijakan kustom, selesaikan langkah berikut.<a name="private-content-setting-signed-cookie-custom-policy-procedure"></a>

**Untuk mengatur cookie bertanda tangan menggunakan kebijakan kustom**

1. Jika Anda menggunakan .NET atau Java untuk membuat ditandatangani URLs, dan jika Anda belum memformat ulang kunci pribadi untuk key pair Anda dari format.pem default ke format yang kompatibel dengan.NET atau dengan Java, lakukan sekarang. Untuk informasi selengkapnya, lihat [Memformat ulang kunci pribadi (hanya .NET dan Java)](private-content-trusted-signers.md#private-content-reformatting-private-key).

1. Program aplikasi Anda untuk mengirim tiga `Set-Cookie` header ke pemirsa yang disetujui (atau empat, jika Anda ingin menentukan algoritma hash). Anda memerlukan tiga `Set-Cookie` header karena setiap `Set-Cookie` header hanya dapat berisi satu pasangan nama-nilai, dan cookie yang CloudFront ditandatangani memerlukan tiga pasangan nama-nilai. Pasangan nama-nilai adalah: `CloudFront-Policy`, `CloudFront-Signature`, dan `CloudFront-Key-Pair-Id`. Anda dapat secara opsional menyertakan pasangan nama-nilai keempat,`CloudFront-Hash-Algorithm`, untuk menentukan algoritma hash yang digunakan untuk tanda tangan. Nilai harus ada di penampil sebelum pengguna membuat permintaan pertama untuk file yang ingin Anda kontrol akses. 
**catatan**  
Secara umum, kami sarankan Anda tidak memasukkan `Expires` dan `Max-Age` atribut. Ini menyebabkan browser menghapus cookie saat pengguna menutup browser, yang mengurangi kemungkinan seseorang mendapatkan akses tidak sah ke konten Anda. Untuk informasi selengkapnya, lihat [Mencegah penyalahgunaan cookie yang ditandatangani](private-content-signed-cookies.md#private-content-signed-cookie-misuse).

   **Nama atribut cookie peka huruf besar-kecil**. 

   Pemutusan jalur hanya disertakan untuk membuat atribut lebih mudah dibaca.

   ```
   Set-Cookie: 
   CloudFront-Policy=base64 encoded version of the policy statement; 
   Domain=optional domain name; 
   Path=/optional directory path; 
   Secure; 
   HttpOnly
   
   
   Set-Cookie: 
   CloudFront-Signature=hashed and signed version of the policy statement; 
   Domain=optional domain name; 
   Path=/optional directory path; 
   Secure; 
   HttpOnly
   
   Set-Cookie: 
   CloudFront-Key-Pair-Id=public key ID for the CloudFront public key whose corresponding private key you're using to generate the signature; 
   Domain=optional domain name; 
   Path=/optional directory path; 
   Secure; 
   HttpOnly
   
   Set-Cookie: 
   CloudFront-Hash-Algorithm=SHA1 or SHA256; 
   Domain=optional domain name; 
   Path=/optional directory path; 
   Secure; 
   HttpOnly
   ```  
**(Opsional) `Domain`**  
Nama domain untuk file yang diminta. Jika Anda tidak menyebutkan `Domain` atribut, nilai default adalah nama domain di URL, dan hanya berlaku untuk nama domain tertentu, bukan subdomain. Jika Anda menentukan `Domain` , ini juga berlaku untuk subdomain. Titik utama pada nama domain (misalnya, `Domain=.example.com`) bersifat opsional. Selain itu, jika Anda menentukan `Domain` , nama domain di URL dan nilai `Domain` atribut harus cocok.  
Anda dapat menentukan nama domain yang CloudFront ditetapkan untuk distribusi Anda, misalnya, d111111abcdef8.cloudfront.net, tetapi Anda tidak dapat menentukan \$1.cloudfront.net untuk nama domain.  
Jika Anda ingin menggunakan nama domain alternatif seperti example.com di URLs, Anda harus menambahkan nama domain alternatif ke distribusi Anda terlepas dari apakah Anda menentukan atribut. `Domain` Untuk informasi lebih lanjut, lihat [Nama domain alternatif (CNAMEs)](DownloadDistValuesGeneral.md#DownloadDistValuesCNAME) dalam [Semua referensi pengaturan distribusi](distribution-web-values-specify.md) topik.  
**(Opsional) `Path`**  
Jalur untuk file yang diminta. Jika Anda tidak menyebutkan `Path` atribut, nilai default adalah alur di URL.  
**`Secure`**  
Meminta pemirsa mengenkripsi cookie sebelum mengirim permintaan. Kami menyarankan Anda mengirim `Set-Cookie` header melalui koneksi HTTPS untuk memastikan bahwa atribut cookie dilindungi dari man-in-the-middle serangan.  
**`HttpOnly`**  
Mengharuskan penampil mengirimkan cookie hanya dalam permintaan HTTP atau HTTPS.  
**`CloudFront-Policy`**  
Pernyataan kebijakan Anda dalam format JSON, dengan spasi kosong dihapus, lalu base64 dikodekan. Untuk informasi selengkapnya, lihat [Membuat tanda tangan untuk cookie yang ditandatangani yang menggunakan kebijakan khusus](#private-content-custom-policy-signature-cookies).  
Pernyataan kebijakan mengendalikan akses yang diberikan oleh cookie yang ditandatangani kepada pengguna. Ini mencakup file yang dapat diakses pengguna, tanggal dan waktu kedaluwarsa, tanggal dan waktu opsional URL menjadi valid, dan alamat IP opsional atau rentang alamat IP yang diizinkan untuk mengakses file.  
**`CloudFront-Signature`**  
Versi yang di-hash, ditandatangani, dan dikodekan base64 dari pernyataan kebijakan JSON. Untuk informasi selengkapnya, lihat [Membuat tanda tangan untuk cookie yang ditandatangani yang menggunakan kebijakan khusus](#private-content-custom-policy-signature-cookies).  
**`CloudFront-Key-Pair-Id`**  
ID untuk kunci CloudFront publik, misalnya,`K2JCJMDEHXQW5F`. ID kunci publik memberi tahu kunci publik CloudFront mana yang akan digunakan untuk memvalidasi URL yang ditandatangani. CloudFrontmembandingkan informasi dalam tanda tangan dengan informasi dalam pernyataan kebijakan untuk memverifikasi bahwa URL belum dirusak.  
Kunci publik ini harus dimiliki oleh kelompok kunci yang merupakan signer tepercaya dalam distribusi. Untuk informasi selengkapnya, lihat [Tentukan penandatangan yang dapat membuat cookie yang ditandatangani URLs dan ditandatangani](private-content-trusted-signers.md).  
**`CloudFront-Hash-Algorithm`**  
(Opsional) Algoritma hash yang digunakan untuk membuat tanda tangan. Nilai yang didukung adalah `SHA1` dan `SHA256`. Jika Anda tidak menyertakan cookie ini, CloudFront defaultnya. `SHA1`

## Contoh `Set-Cookie` header untuk kebijakan kustom
<a name="example-set-cookie-headers-custom-policy"></a>

Lihat contoh pasangan `Set-Cookie` header berikut. 

Jika Anda ingin menggunakan nama domain alternatif seperti example.org di URLs, Anda harus menambahkan nama domain alternatif ke distribusi Anda terlepas dari apakah Anda menentukan atribut. `Domain` Untuk informasi selengkapnya, lihat [Nama domain alternatif (CNAMEs)](DownloadDistValuesGeneral.md#DownloadDistValuesCNAME) dalam topik [Semua referensi pengaturan distribusi](distribution-web-values-specify.md).

**Example Contoh 1**  
Anda dapat menggunakan `Set-Cookie` header untuk satu cookie yang ditandatangani saat Anda menggunakan nama domain yang terkait dengan distribusi Anda di URLs untuk file Anda.  

```
Set-Cookie: CloudFront-Policy=eyJTdGF0ZW1lbnQiOlt7IlJlc291cmNlIjoiaHR0cDovL2QxMTExMTFhYmNkZWY4LmNsb3VkZnJvbnQubmV0L2dhbWVfZG93bmxvYWQuemlwIiwiQ29uZGl0aW9uIjp7IklwQWRkcmVzcyI6eyJBV1M6U291cmNlSXAiOiIxOTIuMC4yLjAvMjQifSwiRGF0ZUxlc3NUaGFuIjp7IkFXUzpFcG9jaFRpbWUiOjE0MjY1MDAwMDB9fX1dfQ__; Domain=d111111abcdef8.cloudfront.net; Path=/; Secure; HttpOnly
Set-Cookie: CloudFront-Signature=dtKhpJ3aUYxqDIwepczPiDb9NXQ_; Domain=d111111abcdef8.cloudfront.net; Path=/; Secure; HttpOnly
Set-Cookie: CloudFront-Key-Pair-Id=K2JCJMDEHXQW5F; Domain=d111111abcdef8.cloudfront.net; Path=/; Secure; HttpOnly
Set-Cookie: CloudFront-Hash-Algorithm=SHA256; Domain=d111111abcdef8.cloudfront.net; Path=/; Secure; HttpOnly
```

**Example Contoh 2**  
Anda dapat menggunakan `Set-Cookie` header untuk satu cookie yang ditandatangani saat Anda menggunakan nama domain alternatif (example.org) di file Anda. URLs   

```
Set-Cookie: CloudFront-Policy=eyJTdGF0ZW1lbnQiOlt7IlJlc291cmNlIjoiaHR0cDovL2QxMTExMTFhYmNkZWY4LmNsb3VkZnJvbnQubmV0L2dhbWVfZG93bmxvYWQuemlwIiwiQ29uZGl0aW9uIjp7IklwQWRkcmVzcyI6eyJBV1M6U291cmNlSXAiOiIxOTIuMC4yLjAvMjQifSwiRGF0ZUxlc3NUaGFuIjp7IkFXUzpFcG9jaFRpbWUiOjE0MjY1MDAwMDB9fX1dfQ__; Domain=example.org; Path=/; Secure; HttpOnly
Set-Cookie: CloudFront-Signature=dtKhpJ3aUYxqDIwepczPiDb9NXQ_; Domain=example.org; Path=/; Secure; HttpOnly
Set-Cookie: CloudFront-Key-Pair-Id=K2JCJMDEHXQW5F; Domain=example.org; Path=/; Secure; HttpOnly
Set-Cookie: CloudFront-Hash-Algorithm=SHA256; Domain=example.org; Path=/; Secure; HttpOnly
```

**Example Contoh 3**  
Anda dapat menggunakan pasangan `Set-Cookie` header untuk permintaan yang ditandatangani saat Anda menggunakan nama domain yang terkait dengan distribusi Anda di URLs untuk file Anda.  

```
Set-Cookie: CloudFront-Policy=eyJTdGF0ZW1lbnQiOlt7IlJlc291cmNlIjoiaHR0cDovL2QxMTExMTFhYmNkZWY4LmNsb3VkZnJvbnQubmV0L2dhbWVfZG93bmxvYWQuemlwIiwiQ29uZGl0aW9uIjp7IklwQWRkcmVzcyI6eyJBV1M6U291cmNlSXAiOiIxOTIuMC4yLjAvMjQifSwiRGF0ZUxlc3NUaGFuIjp7IkFXUzpFcG9jaFRpbWUiOjE0MjY1MDAwMDB9fX1dfQ__; Domain=d111111abcdef8.cloudfront.net; Path=/; Secure; HttpOnly
Set-Cookie: CloudFront-Signature=dtKhpJ3aUYxqDIwepczPiDb9NXQ_; Domain=d111111abcdef8.cloudfront.net; Path=/; Secure; HttpOnly
Set-Cookie: CloudFront-Key-Pair-Id=K2JCJMDEHXQW5F; Domain=dd111111abcdef8.cloudfront.net; Path=/; Secure; HttpOnly
Set-Cookie: CloudFront-Hash-Algorithm=SHA256; Domain=d111111abcdef8.cloudfront.net; Path=/; Secure; HttpOnly
```

**Example Contoh 4**  
Anda dapat menggunakan pasangan `Set-Cookie` header untuk satu permintaan yang ditandatangani saat Anda menggunakan nama domain alternatif (example.org) yang terkait dengan distribusi Anda di file URLs Anda.  

```
Set-Cookie: CloudFront-Policy=eyJTdGF0ZW1lbnQiOlt7IlJlc291cmNlIjoiaHR0cDovL2QxMTExMTFhYmNkZWY4LmNsb3VkZnJvbnQubmV0L2dhbWVfZG93bmxvYWQuemlwIiwiQ29uZGl0aW9uIjp7IklwQWRkcmVzcyI6eyJBV1M6U291cmNlSXAiOiIxOTIuMC4yLjAvMjQifSwiRGF0ZUxlc3NUaGFuIjp7IkFXUzpFcG9jaFRpbWUiOjE0MjY1MDAwMDB9fX1dfQ__; Domain=example.org; Path=/; Secure; HttpOnly
Set-Cookie: CloudFront-Signature=dtKhpJ3aUYxqDIwepczPiDb9NXQ_; Domain=example.org; Path=/; Secure; HttpOnly
Set-Cookie: CloudFront-Key-Pair-Id=K2JCJMDEHXQW5F; Domain=example.org; Path=/; Secure; HttpOnly
Set-Cookie: CloudFront-Hash-Algorithm=SHA256; Domain=example.org; Path=/; Secure; HttpOnly
```

## Membuat pernyataan kebijakan untuk cookie yang ditandatangani yang menggunakan kebijakan khusus
<a name="private-content-custom-policy-statement-cookies"></a>

Untuk membuat pernyataan kebijakan untuk kebijakan kustom, selesaikan langkah berikut. Untuk beberapa contoh pernyataan kebijakan yang mengendalikan akses ke file dalam berbagai cara, lihat [Contoh pernyataan kebijakan untuk cookie bertanda tangan yang menggunakan kebijakan kustom](#private-content-custom-policy-statement-signed-cookies-examples).<a name="private-content-custom-policy-statement-cookies-procedure"></a>

**Untuk membuat pernyataan kebijakan untuk cookie bertanda tangan yang menggunakan kebijakan khusus**

1. Buat pernyataan kebijakan dengan menggunakan format JSON berikut.

   ```
   {
       "Statement": [
           {
               "Resource": "URL of the file",
               "Condition": {
                   "DateLessThan": {
                       "AWS:EpochTime":required ending date and time in Unix time format and UTC
                   },
                   "DateGreaterThan": {
                       "AWS:EpochTime":optional beginning date and time in Unix time format and UTC
                   },
                   "IpAddress": {
                       "AWS:SourceIp": "optional IP address"
                   }
               }
           }
       ]
   }
   ```

   Perhatikan hal-hal berikut:
   + Anda dapat menyertakan hanya satu pernyataan.
   + Gunakan pengkodean karakter UTF-8.
   + Sertakan semua nama tanda baca dan parameter persis seperti yang ditentukan. Singkatan untuk nama parameter tidak diterima.
   + Urutan parameter di `Condition` tidak masalah.
   + Untuk informasi tentang nilai untuk `Resource`, `DateLessThan`, `DateGreaterThan`, dan `IpAddress`, lihat [Nilai yang Anda sebutkan dalam pernyataan kebijakan untuk kebijakan kustom untuk cookie yang ditandatangani](#private-content-custom-policy-statement-cookies-values).

1. Hapus semua spasi kosong (termasuk tab dan karakter baris baru) dari pernyataan kebijakan. Anda mungkin harus memasukkan karakter escape dalam string di kode aplikasi.

1. Base64 mengodekan pernyataan kebijakan menggunakan pengodean base64 MIME. Untuk informasi selengkapnya, lihat [Bagian 6.8, Base64 Content-Transfer-Encoding](https://tools.ietf.org/html/rfc2045#section-6.8) di *RFC 2045, MIME (Ekstensi Surat Internet Serbaguna) Bagian Satu:* Format Badan Pesan Internet.

1. Ganti karakter yang tidak valid dalam string kueri URL dengan karakter yang valid. Tabel berikut mencantumkan karakter yang tidak valid dan valid.  
****    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonCloudFront/latest/DeveloperGuide/private-content-setting-signed-cookie-custom-policy.html)

1. Sertakan nilai yang dihasilkan dalam `Set-Cookie` setelah `CloudFront-Policy=`.

1. Buat tanda tangan untuk `Set-Cookie` header untuk `CloudFront-Signature` dengan mengadakan, menandatangani, dan memberikan kode dasar64 pada pernyataan kebijakan. Untuk informasi selengkapnya, lihat [Membuat tanda tangan untuk cookie yang ditandatangani yang menggunakan kebijakan khusus](#private-content-custom-policy-signature-cookies).

### Nilai yang Anda sebutkan dalam pernyataan kebijakan untuk kebijakan kustom untuk cookie yang ditandatangani
<a name="private-content-custom-policy-statement-cookies-values"></a>

Saat Anda membuat pernyataan kebijakan untuk kebijakan kustom, Anda menentukan nilai berikut.

**Sumber Daya**  
URL dasar termasuk string pencarian Anda, jika ada:  
`https://d111111abcdef8.cloudfront.net/images/horizon.jpg?size=large&license=yes`  
Jika Anda menghilangkan `Resource` parameter, pengguna dapat mengakses semua file yang terkait dengan distribusi apa pun yang terkait dengan pasangan kunci yang Anda gunakan untuk membuat URL yang ditandatangani.
Anda hanya dapat menentukan satu nilai untuk `Resource`.  
Perhatikan hal-hal berikut:  
+ **Protokol** – Nilai harus dimulai dengan `http://` atau `https://`.
+ **Parameter string kueri** – Jika Anda tidak memiliki parameter string pencarian, hapus tanda tanya.
+ **Wildcard** – Anda dapat menggunakan karakter wildcard yang sesuai dengan nol karakter atau lebih (\$1) atau karakter wildcard yang persis sesuai dengan satu karakter (?) di mana pun dalam string. Misalnya, nilai:

  `https://d111111abcdef8.cloudfront.net/*game_download.zip*`

  akan mencakup (misalnya) file berikut:
  + `https://d111111abcdef8.cloudfront.net/game_download.zip`
  + `https://d111111abcdef8.cloudfront.net/example_game_download.zip?license=yes`
  + `https://d111111abcdef8.cloudfront.net/test_game_download.zip?license=temp`
+ **Nama domain alternatif** – Jika Anda menentukan nama domain alternatif (CNAME) di URL, Anda harus menentukan nama domain alternatif saat merujuk file di halaman web atau aplikasi Anda. Jangan tentukan URL Amazon S3 untuk file tersebut.

**DateLessThan**  
Tanggal dan waktu kedaluwarsa untuk URL dalam format waktu Unix (dalam detik) dan Waktu Universal Terkoordinasi (UTC). Jangan melampirkan nilai dalam tanda petik.  
Misalnya, 16 Maret 2015 10.00 UTC dikonversi menjadi 1426500000 dalam format waktu Unix.  
Untuk informasi selengkapnya, lihat [Saat CloudFront memeriksa tanggal dan waktu kedaluwarsa dalam cookie yang ditandatangani](private-content-signed-cookies.md#private-content-check-expiration-cookie).

**DateGreaterThan (Opsional)**  
Tanggal dan waktu mulai opsional untuk URL dalam format waktu Unix (dalam detik) dan Waktu Universal Terkoordinasi (UTC). Pengguna tidak diizinkan untuk mengakses file pada atau sebelum tanggal dan waktu yang ditentukan. Jangan melampirkan nilai dalam tanda petik. 

**IpAddress (Opsional)**  
Alamat IP klien yang membuat permintaan GET. Perhatikan hal-hal berikut:  
+ Untuk mengizinkan alamat IP mengakses file, hapus `IpAddress` parameter.
+ Anda dapat menentukan salah satu alamat IP atau satu rentang alamat IP. Misalnya, Anda tidak dapat mengatur kebijakan untuk memungkinkan akses jika alamat IP klien berada dalam satu dari dua rentang yang berbeda.
+ Untuk memungkinkan akses dari satu alamat IP, Anda menentukan:

  `"`*IPv4 IP address*`/32"`
+ Anda harus menentukan rentang alamat IP dalam standar IPv4 Format CIDR (misalnya, `192.0.2.0/24`). Untuk informasi lebih lanjut, buka *RFC 4632, Perutean Antar-domain Tanpa Kelas (CIDR): Paket Penetapan dan Agregasi Alamat Internet*, [https://tools.ietf.org/html/rfc4632](https://tools.ietf.org/html/rfc4632).
**penting**  
Alamat IP dalam IPv6 format, seperti 2001:0 db 8:85 a3: :8a2e: 0370:7334, tidak didukung. 

  Jika Anda menggunakan kebijakan khusus yang menyertakan`IpAddress`, jangan aktifkan IPv6 distribusi. Jika Anda ingin membatasi akses ke beberapa konten berdasarkan alamat IP dan IPv6 permintaan dukungan untuk konten lain, Anda dapat membuat dua distribusi. Untuk informasi lebih lanjut, lihat [Aktifkan IPv6 (permintaan penampil)](DownloadDistValuesGeneral.md#DownloadDistValuesEnableIPv6) dalam topik [Semua referensi pengaturan distribusi](distribution-web-values-specify.md).

## Contoh pernyataan kebijakan untuk cookie bertanda tangan yang menggunakan kebijakan kustom
<a name="private-content-custom-policy-statement-signed-cookies-examples"></a>

Contoh pernyataan kebijakan berikut menunjukkan cara mengontrol akses ke file tertentu, semua file di direktori, atau semua file yang terkait dengan ID pasangan kunci. Contoh ini juga menunjukkan cara mengontrol akses dari alamat IP individu atau serangkaian alamat IP, dan cara mencegah pengguna menggunakan cookie yang ditandatangani setelah tanggal dan waktu yang ditentukan.

Jika Anda menyalin dan menempelkan salah satu contoh ini, hapus spasi kosong (termasuk tab dan karakter baris baru), ganti nilai dengan nilai Anda sendiri, dan sertakan karakter baris baru setelah tanda kurung kurung penutup (\$1).

Untuk informasi selengkapnya, lihat [Nilai yang Anda sebutkan dalam pernyataan kebijakan untuk kebijakan kustom untuk cookie yang ditandatangani](#private-content-custom-policy-statement-cookies-values).

**Topics**
+ [Contoh pernyataan kebijakan: Akses satu file dari berbagai alamat IP](#private-content-custom-policy-statement-signed-cookies-example-one-object)
+ [Contoh pernyataan kebijakan: Akses semua file dalam direktori dari berbagai alamat IP](#private-content-custom-policy-statement-signed-cookies-example-all-objects)
+ [Contoh pernyataan kebijakan: Akses semua file yang terkait dengan ID key pair dari satu alamat IP](#private-content-custom-policy-statement-signed-cookies-example-one-ip)

### Contoh pernyataan kebijakan: Akses satu file dari berbagai alamat IP
<a name="private-content-custom-policy-statement-signed-cookies-example-one-object"></a>

Contoh kebijakan kustom berikut dalam cookie yang ditandatangani menetapkan bahwa pengguna dapat mengakses file `https://d111111abcdef8.cloudfront.net/game_download.zip` dari alamat IP dalam rentang `192.0.2.0/24` hingga 1 Januari 2023 10:00 UTC:

```
{
    "Statement": [
        {
            "Resource": "https://d111111abcdef8.cloudfront.net/game_download.zip",
            "Condition": {
                "IpAddress": {
                    "AWS:SourceIp": "192.0.2.0/24"
                },
                "DateLessThan": {
                    "AWS:EpochTime": 1767290400
                }
            }
        }
    ]
}
```

### Contoh pernyataan kebijakan: Akses semua file dalam direktori dari berbagai alamat IP
<a name="private-content-custom-policy-statement-signed-cookies-example-all-objects"></a>

Contoh kebijakan khusus berikut memungkinkan Anda membuat cookie yang ditandatangani untuk setiap file dalam `training` direktori, sebagaimana ditunjukkan oleh \$1 karakter wildcard di `Resource` parameter. Pengguna dapat mengakses file dari alamat IP di rentang `192.0.2.0/24` hingga 1 Januari 2013 pukul 10.00 UTC:

```
{
    "Statement": [
        {
            "Resource": "https://d111111abcdef8.cloudfront.net/training/*",
            "Condition": {
                "IpAddress": {
                    "AWS:SourceIp": "192.0.2.0/24"
                },
                "DateLessThan": {
                    "AWS:EpochTime": 1767290400
                }
            }
        }
    ]
}
```

Setiap cookie yang ditandatangani di mana Anda menggunakan kebijakan ini mencakup URL dasar yang mengidentifikasi file tertentu, misalnya:

`https://d111111abcdef8.cloudfront.net/training/orientation.pdf`

### Contoh pernyataan kebijakan: Akses semua file yang terkait dengan ID key pair dari satu alamat IP
<a name="private-content-custom-policy-statement-signed-cookies-example-one-ip"></a>

Kebijakan khusus sampel berikut memungkinkan Anda untuk mengatur cookie yang ditandatangani untuk setiap file yang terkait dengan distribusi apa pun, sebagaimana ditunjukkan oleh \$1 karakter wildcard di `Resource` parameter. Pengguna harus menggunakan alamat IP `192.0.2.10/32`. (Nilai `192.0.2.10/32` dalam notasi CIDR mengacu pada alamat IP tunggal, `192.0.2.10`.) File hanya tersedia dari 1 Januari 2013 10.00 UTC hingga 2 Januari 2013 10.00 UTC:

```
{
    "Statement": [
        {
            "Resource": "https://*",
            "Condition": {
                "IpAddress": {
                    "AWS:SourceIp": "192.0.2.10/32"
                },
                "DateGreaterThan": {
                    "AWS:EpochTime": 1767290400
                },
                "DateLessThan": {
                    "AWS:EpochTime": 1767376800
                }
            }
        }
    ]
}
```

Setiap cookie yang ditandatangani di mana Anda menggunakan kebijakan ini mencakup URL dasar yang mengidentifikasi file tertentu dalam CloudFront distribusi tertentu, misalnya:

`https://d111111abcdef8.cloudfront.net/training/orientation.pdf`

Cookie yang ditandatangani juga mencakup ID pasangan kunci, yang harus dikaitkan dengan grup kunci tepercaya dalam distribusi (d111111abcdef8.cloudfront.net) yang Anda tentukan di URL dasar.

## Membuat tanda tangan untuk cookie yang ditandatangani yang menggunakan kebijakan khusus
<a name="private-content-custom-policy-signature-cookies"></a>

Tanda tangan untuk cookie bertanda tangan yang menggunakan kebijakan kustom merupakan versi pernyataan kebijakan yang di-hash, ditandatangani, dan dikodekan base64. 

Untuk informasi tambahan dan contoh cara membuat, menandatangani, dan mengkode pernyataan kebijakan, lihat:
+ [Perintah Linux dan OpenSSL untuk pengkodean dan enkripsi base64](private-content-linux-openssl.md)
+ [Contoh kode untuk membuat tanda tangan untuk URL yang ditandatangani](PrivateCFSignatureCodeAndExamples.md)

**catatan**  
Contoh terkait menggunakan SHA-1 secara default. Untuk menggunakan SHA-256 sebagai gantinya, ganti `sha1` dengan `sha256` perintah OpenSSL dan sertakan cookie dengan `CloudFront-Hash-Algorithm` nilai. `SHA256`<a name="private-content-custom-policy-signature-cookies-procedure"></a>

**Untuk membuat tanda tangan untuk cookie yang ditandatangani dengan menggunakan kebijakan kustom**

1. Gunakan fungsi hash SHA-1 atau SHA-256 dan RSA untuk hash dan tandatangani pernyataan kebijakan JSON yang Anda buat dalam prosedur. [Untuk membuat pernyataan kebijakan untuk URL yang ditandatangani menggunakan kebijakan kustom](private-content-creating-signed-url-custom-policy.md#private-content-custom-policy-creating-policy-procedure) Gunakan versi pernyataan kebijakan yang tidak lagi menyertakan spasi kosong tetapi belum dikodekan base64.

   Jika Anda menggunakan SHA-256, Anda harus menyertakan `CloudFront-Hash-Algorithm` cookie dengan nilai. `SHA256`

   Untuk kunci privat yang diperlukan oleh fungsi hash, gunakan kunci pribadi yang kunci publiknya berada dalam grup kunci yang dipercaya aktif untuk distribusi.
**catatan**  
Metode yang Anda gunakan untuk men-emuk dan menandatangani pernyataan kebijakan tergantung pada bahasa pemrograman dan platform Anda. Untuk kode sampel, lihat [Contoh kode untuk membuat tanda tangan untuk URL yang ditandatangani](PrivateCFSignatureCodeAndExamples.md).

1. Hapus spasi kosong (termasuk tab dan karakter baris baru) dari string hash dan ditandatangani.

1. Base64 mengodekan string menggunakan pengodean base64 MIME. Untuk informasi selengkapnya, lihat [Bagian 6.8, Base64 Content-Transfer-Encoding](https://tools.ietf.org/html/rfc2045#section-6.8) di *RFC 2045, MIME (Ekstensi Surat Internet Serbaguna) Bagian Satu:* Format Badan Pesan Internet.

1. Ganti karakter yang tidak valid dalam string kueri URL dengan karakter yang valid. Tabel berikut mencantumkan karakter yang tidak valid dan valid.  
****    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonCloudFront/latest/DeveloperGuide/private-content-setting-signed-cookie-custom-policy.html)

1. Sertakan nilai yang dihasilkan dalam `Set-Cookie` header untuk `CloudFront-Signature=` nama-nilai, dan kembali ke [Untuk mengatur cookie bertanda tangan menggunakan kebijakan kustom](#private-content-setting-signed-cookie-custom-policy-procedure) untuk menambahkan `Set-Cookie` header untuk `CloudFront-Key-Pair-Id`.

# Buat cookie yang ditandatangani menggunakan PHP
<a name="signed-cookies-PHP"></a>

Contoh kode berikut mirip dengan contoh [Buat tanda tangan URL menggunakan PHP](CreateURL_PHP.md) di mana ia membuat tautan ke video. Namun, alih-alih menandatangani URL dalam kode, contoh ini menandatangani cookie dengan `create_signed_cookies()` fungsi tersebut. Pemain sisi klien menggunakan cookie untuk mengautentikasi setiap permintaan ke distribusi. CloudFront

Pendekatan ini berguna untuk streaming konten, seperti HTTP Live Streaming (HLS) atau Dynamic Adaptive Streaming melalui HTTP (DASH), di mana klien perlu membuat beberapa permintaan untuk mengambil manifes, segmen, dan aset pemutaran terkait. Dengan menggunakan cookie yang ditandatangani, klien dapat mengautentikasi setiap permintaan tanpa perlu membuat URL baru yang ditandatangani untuk setiap segmen. 

**catatan**  
Membuat tanda tangan URL hanyalah salah satu bagian dari proses penyajian konten pribadi menggunakan cookie yang ditandatangani. Untuk informasi selengkapnya, lihat [Gunakan cookie yang ditandatangani](private-content-signed-cookies.md).



**Topics**
+ [Buat tanda tangan RSA SHA-1 atau SHA-256](#create-rsa-sha-1signature-cookies)
+ [Buat cookie yang ditandatangani](#create-the-signed-cookie)
+ [Kode lengkap](#full-code-signed-cookies)

Bagian berikut memecah contoh kode menjadi bagian-bagian individual. Anda dapat menemukan [contoh kode](#full-code-signed-cookies) lengkap di bawah ini.

## Buat tanda tangan RSA SHA-1 atau SHA-256
<a name="create-rsa-sha-1signature-cookies"></a>

Contoh kode ini melakukan hal berikut:

1. Fungsi melakukan `rsa_sha1_sign` hash dan menandatangani pernyataan kebijakan menggunakan SHA-1. Untuk menggunakan SHA-256 sebagai gantinya, gunakan fungsi rsa\$1sha256\$1sign yang ditunjukkan di bawah ini. Argumen yang diperlukan adalah pernyataan kebijakan dan kunci pribadi yang sesuai dengan kunci publik yang ada dalam grup kunci tepercaya untuk distribusi Anda.

1. Selanjutnya, `url_safe_base64_encode` membuat versi URL-safe dari tanda tangan.

   ```
   function rsa_sha1_sign($policy, $private_key_filename) {
       $signature = "";
       $fp = fopen($private_key_filename, "r");
       $priv_key = fread($fp, 8192);
       fclose($fp);
       $pkeyid = openssl_get_privatekey($priv_key);
       openssl_sign($policy, $signature, $pkeyid);
       openssl_free_key($pkeyid);
       return $signature;
   }
   
   function url_safe_base64_encode($value) {
       $encoded = base64_encode($value);
       return str_replace(
           array('+', '=', '/'),
           array('-', '_', '~'),
           $encoded);
   }
   ```

   Fungsi berikut menggunakan SHA-256 bukan SHA-1:

   ```
   function rsa_sha256_sign($policy, $private_key_filename) {
       $signature = "";
       $fp = fopen($private_key_filename, "r");
       $priv_key = fread($fp, 8192);
       fclose($fp);
       $pkeyid = openssl_get_privatekey($priv_key);
       openssl_sign($policy, $signature, $pkeyid, OPENSSL_ALGO_SHA256);
       openssl_free_key($pkeyid);
       return $signature;
   }
   ```

   `rsa_sha256_sign`Fungsinya sama dengan`rsa_sha1_sign`, kecuali bahwa ia lolos `OPENSSL_ALGO_SHA256` ke`openssl_sign`. Saat Anda menggunakan SHA-256, sertakan `CloudFront-Hash-Algorithm` cookie dengan nilai. `SHA256`

## Buat cookie yang ditandatangani
<a name="create-the-signed-cookie"></a>

Kode berikut membangun membuat cookie yang ditandatangani, menggunakan atribut cookie berikut:`CloudFront-Expires`,`CloudFront-Signature`, `CloudFront-Key-Pair-Id` dan`CloudFront-Hash-Algorithm`. Kode menggunakan kebijakan khusus.

```
function create_signed_cookies($resource, $private_key_filename, $key_pair_id, $expires, $client_ip = null, $hash_algorithm = 'SHA1') {
    $policy = array(
        'Statement' => array(
            array(
                'Resource' => $resource,
                'Condition' => array(
                    'DateLessThan' => array('AWS:EpochTime' => $expires)
                )
            )
        )
    );

    if ($client_ip) {
        $policy['Statement'][0]['Condition']['IpAddress'] = array('AWS:SourceIp' => $client_ip . '/32');
    }

    $policy = json_encode($policy);
    $encoded_policy = url_safe_base64_encode($policy);
    if ($hash_algorithm === 'SHA256') {
        $signature = rsa_sha256_sign($policy, $private_key_filename);
    } else {
        $signature = rsa_sha1_sign($policy, $private_key_filename);
    }
    $encoded_signature = url_safe_base64_encode($signature);

    $cookies = array(
        'CloudFront-Policy' => $encoded_policy,
        'CloudFront-Signature' => $encoded_signature,
        'CloudFront-Key-Pair-Id' => $key_pair_id
    );

    if ($hash_algorithm === 'SHA256') {
        $cookies['CloudFront-Hash-Algorithm'] = 'SHA256';
    }

    return $cookies;
}
```

Untuk informasi selengkapnya, lihat [Tetapkan cookie yang ditandatangani menggunakan kebijakan khusus](private-content-setting-signed-cookie-custom-policy.md).

## Kode lengkap
<a name="full-code-signed-cookies"></a>

Kode contoh berikut memberikan demonstrasi lengkap untuk membuat cookie yang CloudFront ditandatangani dengan PHP. Anda dapat mengunduh contoh lengkap dari file [demo-php.zip](samples/demo-php.zip).

Dalam contoh berikut, Anda dapat memodifikasi `$policy Condition` elemen untuk memungkinkan keduanya IPv4 dan rentang IPv6 alamat. Sebagai contoh, lihat [Menggunakan IPv6 alamat dalam kebijakan IAM](https://docs.aws.amazon.com/AmazonS3/latest/userguide/ipv6-access.html#ipv6-access-iam) di *Panduan Pengguna Layanan Penyimpanan Sederhana Amazon*.

```
<?php

function rsa_sha1_sign($policy, $private_key_filename) {
    $signature = "";
    $fp = fopen($private_key_filename, "r");
    $priv_key = fread($fp, 8192);
    fclose($fp);
    $pkeyid = openssl_get_privatekey($priv_key);
    openssl_sign($policy, $signature, $pkeyid);
    openssl_free_key($pkeyid);
    return $signature;
}

function url_safe_base64_encode($value) {
    $encoded = base64_encode($value);
    return str_replace(
        array('+', '=', '/'),
        array('-', '_', '~'),
        $encoded);
}

function rsa_sha256_sign($policy, $private_key_filename) {
    $signature = "";
    $fp = fopen($private_key_filename, "r");
    $priv_key = fread($fp, 8192);
    fclose($fp);
    $pkeyid = openssl_get_privatekey($priv_key);
    openssl_sign($policy, $signature, $pkeyid, OPENSSL_ALGO_SHA256);
    openssl_free_key($pkeyid);
    return $signature;
}

function create_signed_cookies($resource, $private_key_filename, $key_pair_id, $expires, $client_ip = null, $hash_algorithm = 'SHA1') {
    $policy = array(
        'Statement' => array(
            array(
                'Resource' => $resource,
                'Condition' => array(
                    'DateLessThan' => array('AWS:EpochTime' => $expires)
                )
            )
        )
    );

    if ($client_ip) {
        $policy['Statement'][0]['Condition']['IpAddress'] = array('AWS:SourceIp' => $client_ip . '/32');
    }

    $policy = json_encode($policy);
    $encoded_policy = url_safe_base64_encode($policy);
    if ($hash_algorithm === 'SHA256') {
        $signature = rsa_sha256_sign($policy, $private_key_filename);
    } else {
        $signature = rsa_sha1_sign($policy, $private_key_filename);
    }
    $encoded_signature = url_safe_base64_encode($signature);

    $cookies = array(
        'CloudFront-Policy' => $encoded_policy,
        'CloudFront-Signature' => $encoded_signature,
        'CloudFront-Key-Pair-Id' => $key_pair_id
    );

    if ($hash_algorithm === 'SHA256') {
        $cookies['CloudFront-Hash-Algorithm'] = 'SHA256';
    }

    return $cookies;
}



$private_key_filename = '/home/test/secure/example-priv-key.pem';
$key_pair_id = 'K2JCJMDEHXQW5F';
$base_url = 'https://d1234.cloudfront.net';

$expires = time() + 3600; // 1 hour from now

// Get the viewer real IP from the x-forward-for header as $_SERVER['REMOTE_ADDR'] will return viewer facing IP. An alternative option is to use CloudFront-Viewer-Address header. Note that this header is a trusted CloudFront immutable header. Example format: IP:PORT ("CloudFront-Viewer-Address": "1.2.3.4:12345")
$client_ip = $_SERVER['HTTP_X_FORWARDED_FOR'];


// For HLS manifest and segments (using wildcard)
$hls_resource = $base_url . '/sign/*';
$signed_cookies = create_signed_cookies($hls_resource, $private_key_filename, $key_pair_id, $expires, $client_ip, 'SHA256');

// Set the cookies
$cookie_domain = parse_url($base_url, PHP_URL_HOST);
foreach ($signed_cookies as $name => $value) {
    setcookie($name, $value, $expires, '/', $cookie_domain, true, true);
}

?>

<!DOCTYPE html>
<html>
<head>
    <title>CloudFront Signed HLS Stream with Cookies</title>
</head>
<body>
    <h1>Amazon CloudFront Signed HLS Stream with Cookies</h1>
    <h2>Expires at <?php echo gmdate('Y-m-d H:i:s T', $expires); ?> only viewable by IP <?php echo $client_ip; ?></h2>
    
    <div id='hls-video'>
        <video id="video" width="640" height="360" controls></video>
    </div>

    <script src="https://cdn.jsdelivr.net/npm/hls.js@latest"></script>
    <script>
        var video = document.getElementById('video');
        var manifestUrl = '<?php echo $base_url; ?>/sign/manifest.m3u8';
        
        if (Hls.isSupported()) {
            var hls = new Hls();
            hls.loadSource(manifestUrl);
            hls.attachMedia(video);
        }
        else if (video.canPlayType('application/vnd.apple.mpegurl')) {
            video.src = manifestUrl;
        }
    </script>
</body>
</html>
```

Alih-alih menggunakan cookie yang ditandatangani, Anda dapat menggunakan ditandatangani URLs. Untuk informasi selengkapnya, lihat [Buat tanda tangan URL menggunakan PHP](CreateURL_PHP.md).

# Perintah Linux dan OpenSSL untuk pengkodean dan enkripsi base64
<a name="private-content-linux-openssl"></a>

Anda bisa menggunakan baris perintah Linux berikut dan OpenSSL untuk membubuhkan dan menandatangani pernyataan kebijakan, mengodekan tanda tangan dengan base64, dan mengganti karakter yang tidak valid dalam parameter string kueri URL dengan karakter yang valid.

Untuk informasi tentang OpenSSL, kunjungi [https://www.openssl.org](https://www.openssl.org).

SHA-1 (default):

```
cat policy | tr -d "\n" | tr -d " \t\n\r" | openssl sha1 -sign private_key.pem | openssl base64 -A | tr -- '+=/' '-_~'
```

SHA-256:

```
cat policy | tr -d "\n" | tr -d " \t\n\r" | openssl sha256 -sign private_key.pem | openssl base64 -A | tr -- '+=/' '-_~'
```

Dalam perintah sebelumnya:
+ `cat` membaca `policy` file Anda.
+ `tr -d "\n" | tr -d " \t\n\r"`menghapus spasi kosong dan karakter baris baru yang ditambahkan oleh`cat`.
+ OpenSSL melakukan hash file menggunakan SHA-1 (atau SHA-256) dan menandatanganinya menggunakan file kunci pribadi. `private_key.pem` Tanda tangan kunci pribadi dapat berupa RSA 2048 atau ECDSA 256. Jika Anda menggunakan SHA-256, sertakan parameter `Hash-Algorithm=SHA256` kueri di URL yang ditandatangani, atau `CloudFront-Hash-Algorithm=SHA256` cookie untuk cookie yang ditandatangani.
+ OpenSSL base64-mengkodekan pernyataan kebijakan yang di-hash dan ditandatangani.
+ `tr` mengganti karakter yang tidak valid dalam parameter string kueri URL dengan karakter yang valid.

Untuk contoh kode lainnya yang menunjukkan pembuatan tanda tangan, lihat[Contoh kode untuk membuat tanda tangan untuk URL yang ditandatangani](PrivateCFSignatureCodeAndExamples.md).

# Contoh kode untuk membuat tanda tangan untuk URL yang ditandatangani
<a name="PrivateCFSignatureCodeAndExamples"></a>

Bagian ini mencakup contoh aplikasi yang dapat diunduh yang menunjukkan cara membuat tanda tangan untuk ditandatangani. URLs Contoh tersedia di Perl, PHP, C \$1, dan Java. Anda dapat menggunakan salah satu contoh untuk membuat ditandatangani URLs. Skrip Perl berjalan pada platform Linux dan MacOS. Contoh PHP akan bekerja pada setiap server yang menjalankan PHP. Contoh C\$1 menggunakan Kerangka Kerja .NET.

Contoh di bagian ini menggunakan SHA-1 untuk hash dan menandatangani pernyataan kebijakan. Anda juga dapat menggunakan SHA-256. Untuk menggunakan SHA-256, perbarui algoritma hash dalam fungsi penandatanganan (misalnya, ganti dengan panggilan `sha256` OpenSSL, atau gunakan konstanta SHA-256 yang setara `sha1` di pustaka kriptografi bahasa Anda). Saat Anda menggunakan SHA-256, sertakan parameter `Hash-Algorithm=SHA256` kueri di URL yang ditandatangani.

Misalnya kode di JavaScript (Node.js), lihat [Membuat Amazon CloudFront Ditandatangani URLs di Node.js](https://aws.amazon.com/blogs/developer/creating-amazon-cloudfront-signed-urls-in-node-js/) di Blog AWS Pengembang.

[Misalnya kode dengan Python, lihat [Menghasilkan URL yang ditandatangani untuk Amazon CloudFront](https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/cloudfront.html#examples) di *AWS SDK for Python (Boto3) Referensi API dan kode contoh ini di repositori Boto3*.](https://github.com/boto/boto3/blob/develop/boto3/examples/cloudfront.rst) GitHub 

**Topics**
+ [Buat tanda tangan URL menggunakan Perl](CreateURLPerl.md)
+ [Buat tanda tangan URL menggunakan PHP](CreateURL_PHP.md)
+ [Buat tanda tangan URL menggunakan C\$1 dan .NET Framework](CreateSignatureInCSharp.md)
+ [Buat tanda tangan URL menggunakan Java](CFPrivateDistJavaDevelopment.md)

# Buat tanda tangan URL menggunakan Perl
<a name="CreateURLPerl"></a>

Bagian ini mencakup skrip Perl untuk Linux/Mac platform yang dapat Anda gunakan untuk membuat tanda tangan untuk konten pribadi. Untuk membuat tanda tangan, jalankan skrip dengan argumen baris perintah yang menentukan CloudFront URL, jalur ke kunci pribadi penandatangan, ID kunci, dan tanggal kedaluwarsa URL. Alat ini juga dapat memecahkan kode ditandatanganiURLs. 

**Catatan**  
Membuat tanda tangan URL hanyalah satu bagian dari proses menyajikan konten pribadi menggunakan URL yang ditandatangani. Untuk informasi lebih lanjut tentang end-to-end prosesnya, lihat[Gunakan ditandatangani URLs](private-content-signed-urls.md). 
Dalam perintah penandatanganan, perhatikan yang `sha1` dapat diganti dengan `sha256` `openssl dgst` panggilan.

**Topics**
+ [Source untuk skrip Perl untuk membuat URL yang ditandatangani](#CreateURLPerlScriptSource)

## Source untuk skrip Perl untuk membuat URL yang ditandatangani
<a name="CreateURLPerlScriptSource"></a>

Kode sumber Perl berikut dapat digunakan untuk membuat URL yang ditandatangani untuk CloudFront. Komentar dalam kode mencakup informasi tentang saklar baris perintah dan fitur alat.

```
#!/usr/bin/perl -w

# Copyright 2008 Amazon Technologies, Inc.  Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License. You may obtain a copy of the License at:
#
# https://aws.amazon.com/apache2.0
#
# This file is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and limitations under the License.

=head1 cfsign.pl

cfsign.pl - A tool to generate and verify Amazon CloudFront signed URLs

=head1 SYNOPSIS

This script uses an existing RSA key pair to sign and verify Amazon CloudFront signed URLs

View the script source for details as to which CPAN packages are required beforehand. 

For help, try:

cfsign.pl --help

URL signing examples:

cfsign.pl --action encode --url https://images.my-website.com/gallery1.zip --policy sample_policy.json --private-key privkey.pem --key-pair-id mykey

cfsign.pl --action encode --url https://images.my-website.com/gallery1.zip --expires 1257439868 --private-key privkey.pem --key-pair-id mykey

URL decode example:

cfsign.pl --action decode --url "http//mydist.cloudfront.net/?Signature=AGO-PgxkYo99MkJFHvjfGXjG1QDEXeaDb4Qtzmy85wqyJjK7eKojQWa4BCRcow__&Policy=eyJTdGF0ZW1lbnQiOlt7IlJlc291cmNlIjoiaHR0cDovLypicmFkbS5qcGciLCJDb25kaXRpb24iOnsiSXBBZGRyZXNzIjp7IkFXUzpTb3VyY2VJcCI6IjEwLjUyLjE3LjkvMCJ9LCJEYXRlR3JlYXRlclRoYW4iOnsiQVdTOkVwb2NoVGltZSI6MTI1MjUyMDgzMH19fV19Cg__&Key-Pair-Id=mykey"


To generate an RSA key pair, you can use openssl and the following commands:

# Generate a 2048 bit key pair
openssl genrsa -out private-key.pem 2048
openssl rsa -in private-key.pem -pubout -out public-key.pem


=head1 OPTIONS

=over 8

=item B<--help>

Print a help message and exits.

=item B<--action> [action]

The action to execute.  action can be one of:

  encode - Generate a signed URL (using a canned policy or a user policy)
  decode - Decode a signed URL

=item B<--url>

The URL to en/decode

=item B<--stream>

The stream to en/decode

=item B<--private-key>

The path to your private key.

=item B<--key-pair-id>

The key pair identifier.

=item B<--policy>

The CloudFront policy document.

=item B<--expires>

The Unix epoch time when the URL is to expire. If both this option and
the --policy option are specified, --policy will be used. Otherwise, this 
option alone will use a canned policy.

=back

=cut

use strict;
use warnings;

# you might need to use CPAN to get these modules.
# run perl -MCPAN -e "install <module>" to get them.
# The openssl command line will also need to be in your $PATH.
use File::Temp qw/tempfile/;
use File::Slurp;
use Getopt::Long;
use IPC::Open2;
use MIME::Base64 qw(encode_base64 decode_base64);
use Pod::Usage;
use URI;

my $CANNED_POLICY 
    = '{"Statement":[{"Resource":"<RESOURCE>","Condition":{"DateLessThan":{"AWS:EpochTime":<EXPIRES>}}}]}';

my $POLICY_PARAM      = "Policy";
my $EXPIRES_PARAM     = "Expires";
my $SIGNATURE_PARAM   = "Signature";
my $KEY_PAIR_ID_PARAM = "Key-Pair-Id";

my $verbose = 0;
my $policy_filename = "";
my $expires_epoch = 0;
my $action = "";
my $help = 0;
my $key_pair_id = "";
my $url = "";
my $stream = "";
my $private_key_filename = "";

my $result = GetOptions("action=s"      => \$action,
                        "policy=s"      => \$policy_filename,
                        "expires=i"     => \$expires_epoch,
                        "private-key=s" => \$private_key_filename,
                        "key-pair-id=s" => \$key_pair_id,
                        "verbose"       => \$verbose,
                        "help"          => \$help,
                        "url=s"         => \$url,
                        "stream=s"      => \$stream,
                    );

if ($help or !$result) {
    pod2usage(1);
    exit;
}

if ($url eq "" and $stream eq "") {
    print STDERR "Must include a stream or a URL to encode or decode with the --stream or --url option\n";
    exit;
}

if ($url ne "" and $stream ne "") {
    print STDERR "Only one of --url and --stream may be specified\n";
    exit;
}

if ($url ne "" and !is_url_valid($url)) {
    exit;
}

if ($stream ne "") {
    exit unless is_stream_valid($stream);

    # The signing mechanism is identical, so from here on just pretend we're
    # dealing with a URL
    $url = $stream;
} 

if ($action eq "encode") {
    # The encode action will generate a private content URL given a base URL, 
    # a policy file (or an expires timestamp) and a key pair id parameter
    my $private_key;
    my $public_key;
    my $public_key_file;
    
    my $policy;
    if ($policy_filename eq "") {
        if ($expires_epoch == 0) {
            print STDERR "Must include policy filename with --policy argument or an expires" . 
                          "time using --expires\n";            
        }
        
        $policy = $CANNED_POLICY;
        $policy =~ s/<EXPIRES>/$expires_epoch/g;
        $policy =~ s/<RESOURCE>/$url/g;
    } else {
        if (! -e $policy_filename) {
            print STDERR "Policy file $policy_filename does not exist\n";
            exit;
        }
        $expires_epoch = 0; # ignore if set
        $policy = read_file($policy_filename);
    }

    if ($private_key_filename eq "") {
        print STDERR "You must specific the path to your private key file with --private-key\n";
        exit;
    }

    if (! -e $private_key_filename) {
        print STDERR "Private key file $private_key_filename does not exist\n";
        exit;
    }

    if ($key_pair_id eq "") {
        print STDERR "You must specify a key pair id with --key-pair-id\n";
        exit;
    }

    my $encoded_policy = url_safe_base64_encode($policy);
    my $signature = rsa_sha1_sign($policy, $private_key_filename);
    my $encoded_signature = url_safe_base64_encode($signature);

    my $generated_url = create_url($url, $encoded_policy, $encoded_signature, $key_pair_id, $expires_epoch);


    if ($stream ne "") {
        print "Encoded stream (for use within a swf):\n" . $generated_url . "\n";
        print "Encoded and escaped stream (for use on a webpage):\n" .  escape_url_for_webpage($generated_url) . "\n"; 
    } else {
        print "Encoded URL:\n" . $generated_url . "\n";
    }
} elsif ($action eq "decode") {
    my $decoded = decode_url($url);
    if (!$decoded) {
        print STDERR "Improperly formed URL\n";
        exit;
    }

    print_decoded_url($decoded);
} else {
    # No action specified, print help.  But only if this is run as a program (caller will be empty)
    pod2usage(1) unless caller();
}

# Decode a private content URL into its component parts
sub decode_url {
    my $url = shift;

    if ($url =~ /(.*)\?(.*)/) {
        my $base_url = $1;
        my $params = $2;

        my @unparsed_params = split(/&/, $params);
        my %params = ();
        foreach my $param (@unparsed_params) {
            my ($key, $val) = split(/=/, $param);
            $params{$key} = $val;
        }

        my $encoded_signature = "";
        if (exists $params{$SIGNATURE_PARAM}) {
            $encoded_signature = $params{"Signature"};
        } else {
            print STDERR "Missing Signature URL parameter\n";
            return 0;
        }

        my $encoded_policy = "";
        if (exists $params{$POLICY_PARAM}) {
            $encoded_policy = $params{$POLICY_PARAM};
        } else {
            if (!exists $params{$EXPIRES_PARAM}) {
                print STDERR "Either the Policy or Expires URL parameter needs to be specified\n";
                return 0;    
            }
            
            my $expires = $params{$EXPIRES_PARAM};
            
            my $policy = $CANNED_POLICY;
            $policy =~ s/<EXPIRES>/$expires/g;
            
            my $url_without_cf_params = $url;
            $url_without_cf_params =~ s/$SIGNATURE_PARAM=[^&]*&?//g;
            $url_without_cf_params =~ s/$POLICY_PARAM=[^&]*&?//g;
            $url_without_cf_params =~ s/$EXPIRES_PARAM=[^&]*&?//g;
            $url_without_cf_params =~ s/$KEY_PAIR_ID_PARAM=[^&]*&?//g;
            
            if ($url_without_cf_params =~ /(.*)\?$/) {
                $url_without_cf_params = $1;
            }
            
            $policy =~ s/<RESOURCE>/$url_without_cf_params/g;
            
            $encoded_policy = url_safe_base64_encode($policy);
        }

        my $key = "";
        if (exists $params{$KEY_PAIR_ID_PARAM}) {
            $key = $params{$KEY_PAIR_ID_PARAM};
        } else {
            print STDERR "Missing $KEY_PAIR_ID_PARAM parameter\n";
            return 0;
        }

        my $policy = url_safe_base64_decode($encoded_policy);

        my %ret = ();
        $ret{"base_url"} = $base_url;
        $ret{"policy"} = $policy;
        $ret{"key"} = $key;

        return \%ret;
    } else {
        return 0;
    }
}

# Print a decoded URL out
sub print_decoded_url {
    my $decoded = shift;

    print "Base URL: \n" . $decoded->{"base_url"} . "\n";
    print "Policy: \n" . $decoded->{"policy"} . "\n";
    print "Key: \n" . $decoded->{"key"} . "\n";
}

# Encode a string with base 64 encoding and replace some invalid URL characters
sub url_safe_base64_encode {
    my ($value) = @_;

    my $result = encode_base64($value);
    $result =~ tr|+=/|-_~|;

    return $result;
}

# Decode a string with base 64 encoding.  URL-decode the string first
# followed by reversing any special character ("+=/") translation.
sub url_safe_base64_decode {
    my ($value) = @_;

    $value =~ s/%([0-9A-Fa-f]{2})/chr(hex($1))/eg;
    $value =~ tr|-_~|+=/|;

    my $result = decode_base64($value);

    return $result;
}

# Create a private content URL
sub create_url {
    my ($path, $policy, $signature, $key_pair_id, $expires) = @_;
    
    my $result;
    my $separator = $path =~ /\?/ ? '&' : '?';
    if ($expires) {
        $result = "$path$separator$EXPIRES_PARAM=$expires&$SIGNATURE_PARAM=$signature&$KEY_PAIR_ID_PARAM=$key_pair_id";
    } else {
        $result = "$path$separator$POLICY_PARAM=$policy&$SIGNATURE_PARAM=$signature&$KEY_PAIR_ID_PARAM=$key_pair_id";
    }
    $result =~ s/\n//g;

    return $result;
}

# Sign a document with given private key file.
# The first argument is the document to sign
# The second argument is the name of the private key file
sub rsa_sha1_sign {
    my ($to_sign, $pvkFile) = @_;
    print "openssl sha1 -sign $pvkFile $to_sign\n";

    return write_to_program($pvkFile, $to_sign);
}

# Helper function to write data to a program
sub write_to_program {
my ($keyfile, $data) = @_;
unlink "temp_policy.dat" if (-e "temp_policy.dat");
unlink "temp_sign.dat" if (-e "temp_sign.dat");

write_file("temp_policy.dat", $data);

system("openssl dgst -sha1 -sign \"$keyfile\" -out temp_sign.dat temp_policy.dat");

my $output = read_file("temp_sign.dat");

    return $output;
}

# Read a file into a string and return the string
sub read_file {
    my ($file) = @_;

    open(INFILE, "<$file") or die("Failed to open $file: $!");
    my $str = join('', <INFILE>);
    close INFILE;

    return $str;
}

sub is_url_valid {
    my ($url) = @_;

    # HTTP distributions start with http[s]:// and are the correct thing to sign
    if ($url =~ /^https?:\/\//) {
        return 1;
    } else {
        print STDERR "CloudFront requires absolute URLs for HTTP distributions\n";
        return 0;
    }
}

sub is_stream_valid {
    my ($stream) = @_;

    if ($stream =~ /^rtmp:\/\// or $stream =~ /^\/?cfx\/st/) {
        print STDERR "Streaming distributions require that only the stream name is signed.\n";
        print STDERR "The stream name is everything after, but not including, cfx/st/\n";
        return 0;
    } else {
        return 1;
    }
}

# flash requires that the query parameters in the stream name are url
# encoded when passed in through javascript, etc.  This sub handles the minimal
# required url encoding.
sub escape_url_for_webpage {
    my ($url) = @_;

    $url =~ s/\?/%3F/g;
    $url =~ s/=/%3D/g;
    $url =~ s/&/%26/g;

    return $url;
}

1;
```

# Buat tanda tangan URL menggunakan PHP
<a name="CreateURL_PHP"></a>

Setiap server web yang menjalankan PHP dapat menggunakan kode contoh PHP ini untuk membuat pernyataan kebijakan dan tanda tangan untuk distribusi pribadi CloudFront . Contoh lengkap menciptakan halaman web yang berfungsi dengan tautan URL yang ditandatangani yang memutar streaming video menggunakan CloudFront streaming. Anda dapat mengunduh contoh lengkap dari file [demo-php.zip](samples/demo-php.zip).

**Catatan**  
Membuat tanda tangan URL hanyalah satu bagian dari proses menyajikan konten pribadi menggunakan URL yang ditandatangani. Untuk informasi selengkapnya tentang seluruh proses, lihat [Gunakan ditandatangani URLs](private-content-signed-urls.md). 
Anda juga dapat membuat ditandatangani URLs dengan menggunakan `UrlSigner` kelas di AWS SDK untuk PHP. Untuk informasi selengkapnya, lihat [Kelas UrlSigner](https://docs.aws.amazon.com/aws-sdk-php/v3/api/class-Aws.CloudFront.UrlSigner.html) di *Referensi AWS SDK untuk PHP API*.
Dalam `openssl_sign` panggilan tersebut, perhatikan bahwa meneruskan `OPENSSL_ALGO_SHA256` sebagai argumen keempat beralih ke SHA-256. (Lihat juga [Buat cookie yang ditandatangani menggunakan PHP](signed-cookies-PHP.md) untuk contoh lengkap.)

**Topics**
+ [Buat tanda tangan RSA SHA-1](#sample-rsa-sign)
+ [Buat kebijakan yang dikalengkan](#sample-canned-policy)
+ [Buat kebijakan kustom](#sample-custom-policy)
+ [Contoh kode lengkap](#full-example)

Bagian berikut memecah contoh kode menjadi bagian-bagian individual. Anda dapat menemukan di [Contoh kode lengkap](#full-example) bawah ini.

## Buat tanda tangan RSA SHA-1
<a name="sample-rsa-sign"></a>

Contoh kode ini melakukan hal berikut:
+ Fungsi melakukan `rsa_sha1_sign` hash dan menandatangani pernyataan kebijakan. Argumen yang diperlukan adalah pernyataan kebijakan dan kunci pribadi yang sesuai dengan kunci publik yang ada dalam grup kunci tepercaya untuk distribusi Anda. 
+ Selanjutnya, `url_safe_base64_encode` membuat versi URL-safe dari tanda tangan.

```
function rsa_sha1_sign($policy, $private_key_filename) {
    $signature = "";

    // load the private key
    $fp = fopen($private_key_filename, "r");
    $priv_key = fread($fp, 8192);
    fclose($fp);
    $pkeyid = openssl_get_privatekey($priv_key);

    // compute signature
    openssl_sign($policy, $signature, $pkeyid);

    // free the key from memory
    openssl_free_key($pkeyid);

    return $signature;
}

function url_safe_base64_encode($value) {
    $encoded = base64_encode($value);
    // replace unsafe characters +, = and / with 
    // the safe characters -, _ and ~
    return str_replace(
        array('+', '=', '/'),
        array('-', '_', '~'),
        $encoded);
}
```

Cuplikan kode berikut menggunakan fungsi `get_canned_policy_stream_name()` dan `get_custom_policy_stream_name()` untuk membuat kebijakan kalengan dan kustom. CloudFront menggunakan kebijakan untuk membuat URL untuk streaming video, termasuk menentukan waktu kedaluwarsa. 

Anda kemudian dapat menggunakan kebijakan kalengan atau kebijakan khusus untuk menentukan cara mengelola akses ke konten Anda. Untuk informasi selengkapnya tentang mana yang harus dipilih, lihat [Memutuskan untuk menggunakan kebijakan kalengan atau kustom untuk ditandatangani URLs](private-content-signed-urls.md#private-content-choosing-canned-custom-policy) bagian.

## Buat kebijakan yang dikalengkan
<a name="sample-canned-policy"></a>

Contoh kode berikut membangun *kalengan* pernyataan kebijakan untuk tanda tangan. 

**catatan**  
`$expires`Variabel adalah date/time stempel yang harus berupa bilangan bulat, bukan string.

```
function get_canned_policy_stream_name($video_path, $private_key_filename, $key_pair_id, $expires) {
    // this policy is well known by CloudFront, but you still need to sign it, since it contains your parameters
    $canned_policy = '{"Statement":[{"Resource":"' . $video_path . '","Condition":{"DateLessThan":{"AWS:EpochTime":'. $expires . '}}}]}';
    // the policy contains characters that cannot be part of a URL, so we base64 encode it
    $encoded_policy = url_safe_base64_encode($canned_policy);
    // sign the original policy, not the encoded version
    $signature = rsa_sha1_sign($canned_policy, $private_key_filename);
    // make the signature safe to be included in a URL
    $encoded_signature = url_safe_base64_encode($signature);

    // combine the above into a stream name
    $stream_name = create_stream_name($video_path, null, $encoded_signature, $key_pair_id, $expires);
    // URL-encode the query string characters
    return $stream_name;
}
```

Untuk informasi selengkapnya tentang kebijakan terekam, lihat [Membuat URL yang ditandatangani menggunakan kebijakan kalengan](private-content-creating-signed-url-canned-policy.md).

## Buat kebijakan kustom
<a name="sample-custom-policy"></a>

Contoh kode berikut membangun *khusus* pernyataan kebijakan untuk tanda tangan. 

```
function get_custom_policy_stream_name($video_path, $private_key_filename, $key_pair_id, $policy) {
    // the policy contains characters that cannot be part of a URL, so we base64 encode it
    $encoded_policy = url_safe_base64_encode($policy);
    // sign the original policy, not the encoded version
    $signature = rsa_sha1_sign($policy, $private_key_filename);
    // make the signature safe to be included in a URL
    $encoded_signature = url_safe_base64_encode($signature);

    // combine the above into a stream name
    $stream_name = create_stream_name($video_path, $encoded_policy, $encoded_signature, $key_pair_id, null);
    // URL-encode the query string characters
    return $stream_name;
}
```

Untuk informasi selengkapnya tentang kebijakan khusus, lihat [Membuat URL yang ditandatangani menggunakan kebijakan khusus](private-content-creating-signed-url-custom-policy.md).

## Contoh kode lengkap
<a name="full-example"></a>

Kode contoh berikut memberikan demonstrasi lengkap membuat CloudFront ditandatangani URLs dengan PHP. Anda dapat mengunduh contoh lengkap dari file [demo-php.zip](samples/demo-php.zip).

Dalam contoh berikut, Anda dapat memodifikasi `$policy` `Condition` elemen untuk memungkinkan keduanya IPv4 dan rentang IPv6 alamat. Sebagai contoh, lihat [Menggunakan IPv6 alamat dalam kebijakan IAM](https://docs.aws.amazon.com/AmazonS3/latest/userguide/ipv6-access.html#ipv6-access-iam) di *Panduan Pengguna Layanan Penyimpanan Sederhana Amazon*.

```
<?php

function rsa_sha1_sign($policy, $private_key_filename) {
    $signature = "";

    // load the private key
    $fp = fopen($private_key_filename, "r");
    $priv_key = fread($fp, 8192);
    fclose($fp);
    $pkeyid = openssl_get_privatekey($priv_key);

    // compute signature
    openssl_sign($policy, $signature, $pkeyid);

    // free the key from memory
    openssl_free_key($pkeyid);

    return $signature;
}

function url_safe_base64_encode($value) {
    $encoded = base64_encode($value);
    // replace unsafe characters +, = and / with the safe characters -, _ and ~
    return str_replace(
        array('+', '=', '/'),
        array('-', '_', '~'),
        $encoded);
}

function create_stream_name($stream, $policy, $signature, $key_pair_id, $expires) {
    $result = $stream;
    // if the stream already contains query parameters, attach the new query parameters to the end
    // otherwise, add the query parameters
    $separator = strpos($stream, '?') == FALSE ? '?' : '&';
    // the presence of an expires time means we're using a canned policy
    if($expires) {
        $result .= $separator . "Expires=" . $expires . "&Signature=" . $signature . "&Key-Pair-Id=" . $key_pair_id;
    }
    // not using a canned policy, include the policy itself in the stream name
    else {
        $result .= $separator . "Policy=" . $policy . "&Signature=" . $signature . "&Key-Pair-Id=" . $key_pair_id;
    }

    // new lines would break us, so remove them
    return str_replace('\n', '', $result);
}


function get_canned_policy_stream_name($video_path, $private_key_filename, $key_pair_id, $expires) {
    // this policy is well known by CloudFront, but you still need to sign it, since it contains your parameters
    $canned_policy = '{"Statement":[{"Resource":"' . $video_path . '","Condition":{"DateLessThan":{"AWS:EpochTime":'. $expires . '}}}]}';
    // the policy contains characters that cannot be part of a URL, so we base64 encode it
    $encoded_policy = url_safe_base64_encode($canned_policy);
    // sign the original policy, not the encoded version
    $signature = rsa_sha1_sign($canned_policy, $private_key_filename);
    // make the signature safe to be included in a URL
    $encoded_signature = url_safe_base64_encode($signature);

    // combine the above into a stream name
    $stream_name = create_stream_name($video_path, null, $encoded_signature, $key_pair_id, $expires);
    // URL-encode the query string characters
    return $stream_name;
}

function get_custom_policy_stream_name($video_path, $private_key_filename, $key_pair_id, $policy) {
    // the policy contains characters that cannot be part of a URL, so we base64 encode it
    $encoded_policy = url_safe_base64_encode($policy);
    // sign the original policy, not the encoded version
    $signature = rsa_sha1_sign($policy, $private_key_filename);
    // make the signature safe to be included in a URL
    $encoded_signature = url_safe_base64_encode($signature);

    // combine the above into a stream name
    $stream_name = create_stream_name($video_path, $encoded_policy, $encoded_signature, $key_pair_id, null);
    // URL-encode the query string characters
    return $stream_name;
}


// Path to your private key.  Be very careful that this file is not accessible
// from the web!

$private_key_filename = '/home/test/secure/example-priv-key.pem';
$key_pair_id = 'K2JCJMDEHXQW5F';

// Make sure you have "Restrict viewer access" enabled on this path behaviour and using the above Trusted key groups (recommended).
$video_path = 'https://example.com/secure/example.mp4';

$expires = time() + 300; // 5 min from now
$canned_policy_stream_name = get_canned_policy_stream_name($video_path, $private_key_filename, $key_pair_id, $expires);

// Get the viewer real IP from the x-forward-for header as $_SERVER['REMOTE_ADDR'] will return viewer facing IP. An alternative option is to use CloudFront-Viewer-Address header. Note that this header is a trusted CloudFront immutable header. Example format: IP:PORT ("CloudFront-Viewer-Address": "1.2.3.4:12345")
$client_ip = $_SERVER['HTTP_X_FORWARDED_FOR'];
$policy =
'{'.
    '"Statement":['.
        '{'.
            '"Resource":"'. $video_path . '",'.
            '"Condition":{'.
                '"IpAddress":{"AWS:SourceIp":"' . $client_ip . '/32"},'.
                '"DateLessThan":{"AWS:EpochTime":' . $expires . '}'.
            '}'.
        '}'.
    ']' .
    '}';
$custom_policy_stream_name = get_custom_policy_stream_name($video_path, $private_key_filename, $key_pair_id, $policy);

?>

<html>

<head>
    <title>CloudFront</title>
</head>

<body>
    <h1>Amazon CloudFront</h1>
    <h2>Canned Policy</h2>
    <h3>Expires at <?php echo gmdate('Y-m-d H:i:s T', $expires); ?></h3>
    <br />

    <div id='canned'>The canned policy video will be here: <br>
    
        <video width="640" height="360" autoplay muted controls>
        <source src="<?php echo $canned_policy_stream_name; ?>" type="video/mp4">
        Your browser does not support the video tag.
        </video>
    </div>

    <h2>Custom Policy</h2>
    <h3>Expires at <?php echo gmdate('Y-m-d H:i:s T', $expires); ?> only viewable by IP <?php echo $client_ip; ?></h3>
    <div id='custom'>The custom policy video will be here: <br>

         <video width="640" height="360" autoplay muted controls>
         <source src="<?php echo $custom_policy_stream_name; ?>" type="video/mp4">
         Your browser does not support the video tag.
        </video>
    </div> 

</body>

</html>
```

Untuk contoh tanda tangan URL tambahan, lihat topik berikut:
+ [Buat tanda tangan URL menggunakan Perl](CreateURLPerl.md)
+ [Buat tanda tangan URL menggunakan C\$1 dan .NET Framework](CreateSignatureInCSharp.md)
+ [Buat tanda tangan URL menggunakan Java](CFPrivateDistJavaDevelopment.md)

Alih-alih menggunakan tanda tangan URLs untuk membuat tanda tangan, Anda dapat menggunakan cookie yang ditandatangani. Untuk informasi selengkapnya, lihat [Buat cookie yang ditandatangani menggunakan PHP](signed-cookies-PHP.md).

# Buat tanda tangan URL menggunakan C\$1 dan .NET Framework
<a name="CreateSignatureInCSharp"></a>

Contoh C\$1 di bagian ini mengimplementasikan contoh aplikasi yang menunjukkan cara membuat tanda tangan untuk distribusi CloudFront pribadi menggunakan pernyataan kebijakan kalengan dan kustom. Contoh termasuk fungsi utilitas berdasarkan [AWS SDK untuk .NET](https://aws.amazon.com/sdkfornet) yang dapat berguna dalam aplikasi .NET.

Anda juga dapat membuat cookie yang ditandatangani URLs dan ditandatangani dengan menggunakan SDK untuk .NET. Di *Referensi API SDK untuk .NET *, lihat topik berikut:
+ **Ditandatangani URLs** - [AmazonCloudFrontUrlSigner](https://docs.aws.amazon.com/sdkfornet/v3/apidocs/items/CloudFront/TCloudFrontUrlSigner.html) 
+ **Cookie yang ditandatangani** — [AmazonCloudFrontCookieSigner](https://docs.aws.amazon.com/sdkfornet/v3/apidocs/items/CloudFront/TCloudFrontCookieSigner.html) 

Untuk mengunduh kode, kunjungi [Kode Tanda Tangan dalam C\$1](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/samples/AWS_PrivateCF_Distributions.zip).

**Catatan**  
`AmazonCloudFrontCookieSigner`Kelas `AmazonCloudFrontUrlSigner` dan telah pindah ke paket terpisah. Untuk informasi selengkapnya tentang menggunakannya, lihat [CookieSigner dan UrlSigner](https://docs.aws.amazon.com/sdk-for-net/v4/developer-guide/net-dg-v4.html#net-dg-v4-CookieSigner-UrlSigner) di *Panduan Pengembang AWS SDK untuk .NET (V4)*. 
Membuat tanda tangan URL hanyalah satu bagian dari proses menyajikan konten pribadi menggunakan URL yang ditandatangani. Untuk informasi selengkapnya, lihat [Gunakan ditandatangani URLs](private-content-signed-urls.md). Untuk informasi selengkapnya tentang penggunaan cookie yang ditandatangani, lihat[Gunakan cookie yang ditandatangani](private-content-signed-cookies.md).
Dalam panggilan penandatanganan RSA, perhatikan bahwa `SHA1` dapat diganti dengan `SHA256` parameter algoritma hash.

## Gunakan kunci RSA di .NET Framework
<a name="rsa-key-sdk-net"></a>

Untuk menggunakan kunci RSA di .NET Framework, Anda harus mengonversi file.pem yang AWS disediakan ke format XML.NET Framework yang digunakan.NET Framework.

Setelah konversi, file kunci privat RSA memiliki format berikut:

**Example : Kunci pribadi RSA dalam format XML.NET Framework**  <a name="RSAPrivateKeyXML.NETFrameworkFormat"></a>

```
<RSAKeyValue>
  <Modulus>
    wO5IvYCP5UcoCKDo1dcspoMehWBZcyfs9QEzGi6Oe5y+ewGr1oW+vB2GPB
    ANBiVPcUHTFWhwaIBd3oglmF0lGQljP/jOfmXHUK2kUUnLnJp+oOBL2NiuFtqcW6h/L5lIpD8Yq+NRHg
    Ty4zDsyr2880MvXv88yEFURCkqEXAMPLE=
  </Modulus>
  <Exponent>AQAB</Exponent>
  <P>
    5bmKDaTz
    npENGVqz4Cea8XPH+sxt+2VaAwYnsarVUoSBeVt8WLloVuZGG9IZYmH5KteXEu7fZveYd9UEXAMPLE==
  </P>
  <Q>
    1v9l/WN1a1N3rOK4VGoCokx7kR2SyTMSbZgF9IWJNOugR/WZw7HTnjipO3c9dy1Ms9pUKwUF4
    6d7049EXAMPLE==
  </Q>
  <DP>
    RgrSKuLWXMyBH+/l1Dx/I4tXuAJIrlPyo+VmiOc7b5NzHptkSHEPfR9s1
    OK0VqjknclqCJ3Ig86OMEtEXAMPLE==
  </DP>
  <DQ>
    pjPjvSFw+RoaTu0pgCA/jwW/FGyfN6iim1RFbkT4
    z49DZb2IM885f3vf35eLTaEYRYUHQgZtChNEV0TEXAMPLE==
  </DQ>
  <InverseQ>
    nkvOJTg5QtGNgWb9i
    cVtzrL/1pFEOHbJXwEJdU99N+7sMK+1066DL/HSBUCD63qD4USpnf0myc24in0EXAMPLE==</InverseQ>
  <D>
      Bc7mp7XYHynuPZxChjWNJZIq+A73gm0ASDv6At7F8Vi9r0xUlQe/v0AQS3ycN8QlyR4XMbzMLYk
      3yjxFDXo4ZKQtOGzLGteCU2srANiLv26/imXA8FVidZftTAtLviWQZBVPTeYIA69ATUYPEq0a5u5wjGy
      UOij9OWyuEXAMPLE=
   </D>
</RSAKeyValue>
```

## Metode penandatanganan kebijakan kalengan di C \$1
<a name="canned-policy-signed-url-net"></a>

Kode C\$1 berikut membuat URL yang ditandatangani yang menggunakan kebijakan terekam dengan melakukan hal berikut:
+ Membuat pernyataan kebijakan.
+ Hash pernyataan kebijakan menggunakan SHA1, dan menandatangani hasilnya menggunakan RSA dan kunci pribadi yang kunci publiknya terkait berada dalam grup kunci tepercaya.
+ Base64 mengodekan pernyataan kebijakan yang di-hash dan ditandatangani serta menggantikan karakter khusus untuk membuat string aman digunakan sebagai parameter permintaan URL.
+ Menyusun nilai.

Untuk implementasi lengkap, lihat contoh di [Kode Tanda Tangan dalam C\$1](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/samples/AWS_PrivateCF_Distributions.zip). 

**catatan**  
`keyId`Dikembalikan saat Anda mengunggah kunci publik ke CloudFront. Untuk informasi selengkapnya, lihat ![\[6\]](http://docs.aws.amazon.com/id_id/AmazonCloudFront/latest/DeveloperGuide/images/callouts/6.png) [&Key-Pair-Id](private-content-creating-signed-url-canned-policy.md).

**Example : Metode penandatanganan kebijakan kalengan di C \$1**  <a name="ExampleCannedPolicySigningMethod-CSharp"></a>

```
public static string ToUrlSafeBase64String(byte[] bytes)
{
    return System.Convert.ToBase64String(bytes)
        .Replace('+', '-')
        .Replace('=', '_')
        .Replace('/', '~');
}

public static string CreateCannedPrivateURL(string urlString, 
    string durationUnits, string durationNumber, string pathToPolicyStmnt, 
    string pathToPrivateKey, string keyId)
{
    // args[] 0-thisMethod, 1-resourceUrl, 2-seconds-minutes-hours-days 
    // to expiration, 3-numberOfPreviousUnits, 4-pathToPolicyStmnt, 
    // 5-pathToPrivateKey, 6-keyId

    TimeSpan timeSpanInterval = GetDuration(durationUnits, durationNumber);

    // Create the policy statement.
    string strPolicy = CreatePolicyStatement(pathToPolicyStmnt,
        urlString, 
        DateTime.Now, 
        DateTime.Now.Add(timeSpanInterval), 
        "0.0.0.0/0");
    if ("Error!" == strPolicy) return "Invalid time frame." + 
        "Start time cannot be greater than end time.";

    // Copy the expiration time defined by policy statement.
    string strExpiration = CopyExpirationTimeFromPolicy(strPolicy);

    // Read the policy into a byte buffer.
    byte[] bufferPolicy = Encoding.ASCII.GetBytes(strPolicy);

    // Initialize the SHA1CryptoServiceProvider object and hash the policy data.
    using (SHA1CryptoServiceProvider 
        cryptoSHA1 = new SHA1CryptoServiceProvider())
    {
        bufferPolicy = cryptoSHA1.ComputeHash(bufferPolicy);

        // Initialize the RSACryptoServiceProvider object.
        RSACryptoServiceProvider providerRSA = new RSACryptoServiceProvider();
        XmlDocument xmlPrivateKey = new XmlDocument();

        // Load your private key, which you created by converting your 
        // .pem file to the XML format that the .NET framework uses.  
        // Several tools are available. 
        xmlPrivateKey.Load(pathToPrivateKey);

        // Format the RSACryptoServiceProvider providerRSA and 
        // create the signature.
        providerRSA.FromXmlString(xmlPrivateKey.InnerXml);
        RSAPKCS1SignatureFormatter rsaFormatter = 
            new RSAPKCS1SignatureFormatter(providerRSA);
        rsaFormatter.SetHashAlgorithm("SHA1");
        byte[] signedPolicyHash = rsaFormatter.CreateSignature(bufferPolicy);

        // Convert the signed policy to URL-safe base64 encoding and 
        // replace unsafe characters + = / with the safe characters - _ ~
        string strSignedPolicy = ToUrlSafeBase64String(signedPolicyHash);

        // Concatenate the URL, the timestamp, the signature, 
        // and the key pair ID to form the signed URL.
        return urlString + 
            "?Expires=" + 
            strExpiration + 
            "&Signature=" + 
            strSignedPolicy + 
            "&Key-Pair-Id=" + 
            keyId;
    }
}
```

## Metode penandatanganan kebijakan kustom di C \$1
<a name="custom-policy-signed-url-net"></a>

Kode C\$1 berikut membuat URL yang ditandatangani menggunakan kebijakan kustom dengan melakukan hal berikut:

1. Membuat pernyataan kebijakan.

1. Base64 mengodekan pernyataan kebijakan dan menggantikan karakter khusus untuk membuat string tersebut aman untuk digunakan sebagai parameter permintaan URL.

1. Hash pernyataan kebijakan menggunakan SHA1, dan mengenkripsi hasilnya menggunakan RSA dan kunci pribadi yang kunci publiknya terkait berada dalam grup kunci tepercaya.

1. Base64 mengodekan pernyataan kebijakan yang di-hash dan mengganti karakter khusus untuk membuat string aman digunakan sebagai parameter permintaan URL.

1. Menyusun nilai.

Untuk implementasi lengkap, lihat contoh di [Kode Tanda Tangan dalam C\$1](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/samples/AWS_PrivateCF_Distributions.zip). 

**catatan**  
`keyId`Dikembalikan saat Anda mengunggah kunci publik ke CloudFront. Untuk informasi selengkapnya, lihat ![\[6\]](http://docs.aws.amazon.com/id_id/AmazonCloudFront/latest/DeveloperGuide/images/callouts/6.png) [&Key-Pair-Id](private-content-creating-signed-url-canned-policy.md).

**Example : Metode penandatanganan kebijakan khusus di C \$1**  <a name="ExampleCustomPolicySigningMethod-CSharp"></a>

```
public static string ToUrlSafeBase64String(byte[] bytes)
{
    return System.Convert.ToBase64String(bytes)
        .Replace('+', '-')
        .Replace('=', '_')
        .Replace('/', '~');
}

public static string CreateCustomPrivateURL(string urlString, 
    string durationUnits, string durationNumber, string startIntervalFromNow, 
    string ipaddress, string pathToPolicyStmnt, string pathToPrivateKey, 
    string keyId)
{
    // args[] 0-thisMethod, 1-resourceUrl, 2-seconds-minutes-hours-days 
    // to expiration, 3-numberOfPreviousUnits, 4-starttimeFromNow, 
    // 5-ip_address, 6-pathToPolicyStmt, 7-pathToPrivateKey, 8-keyId

    TimeSpan timeSpanInterval = GetDuration(durationUnits, durationNumber);
    TimeSpan timeSpanToStart = GetDurationByUnits(durationUnits, 
        startIntervalFromNow);
    if (null == timeSpanToStart) 
        return "Invalid duration units." + 
            "Valid options: seconds, minutes, hours, or days";
            
    string strPolicy = CreatePolicyStatement(
        pathToPolicyStmnt, urlString, DateTime.Now.Add(timeSpanToStart), 
        DateTime.Now.Add(timeSpanInterval), ipaddress);

    // Read the policy into a byte buffer.
    byte[] bufferPolicy = Encoding.ASCII.GetBytes(strPolicy);

    // Convert the policy statement to URL-safe base64 encoding and 
    // replace unsafe characters + = / with the safe characters - _ ~

    string urlSafePolicy = ToUrlSafeBase64String(bufferPolicy);

    // Initialize the SHA1CryptoServiceProvider object and hash the policy data.
    byte[] bufferPolicyHash;
    using (SHA1CryptoServiceProvider cryptoSHA1 = 
        new SHA1CryptoServiceProvider())
    {
        bufferPolicyHash = cryptoSHA1.ComputeHash(bufferPolicy);

        // Initialize the RSACryptoServiceProvider object.
        RSACryptoServiceProvider providerRSA = new RSACryptoServiceProvider();
        XmlDocument xmlPrivateKey = new XmlDocument();

        // Load your private key, which you created by converting your 
        // .pem file to the XML format that the .NET framework uses.  
        // Several tools are available. 
        xmlPrivateKey.Load(pathToPrivateKey);

        // Format the RSACryptoServiceProvider providerRSA 
        // and create the signature.
        providerRSA.FromXmlString(xmlPrivateKey.InnerXml);
        RSAPKCS1SignatureFormatter RSAFormatter = 
            new RSAPKCS1SignatureFormatter(providerRSA);
        RSAFormatter.SetHashAlgorithm("SHA1");
        byte[] signedHash = RSAFormatter.CreateSignature(bufferPolicyHash);

        // Convert the signed policy to URL-safe base64 encoding and 
        // replace unsafe characters + = / with the safe characters - _ ~
        string strSignedPolicy = ToUrlSafeBase64String(signedHash);

        return urlString + 
            "?Policy=" + 
            urlSafePolicy + 
            "&Signature=" + 
            strSignedPolicy + 
            "&Key-Pair-Id=" + 
            keyId;
    }
}
```

## Metode utilitas untuk pembuatan tanda tangan
<a name="utility-methods-signed-url"></a>

Metode berikut ini mendapatkan pernyataan kebijakan dari interval waktu file dan parse untuk pembuatan tanda tangan.

**Example : Metode utilitas untuk pembuatan tanda tangan**  <a name="UtilityMethodsForSignatureGeneration"></a>

```
public static string CreatePolicyStatement(string policyStmnt, 
   string resourceUrl, 
   DateTime startTime, 
   DateTime endTime, 
   string ipAddress)
   
{
   // Create the policy statement.
   FileStream streamPolicy = new FileStream(policyStmnt, FileMode.Open, FileAccess.Read);
   using (StreamReader reader = new StreamReader(streamPolicy))
   {
      string strPolicy = reader.ReadToEnd();

      TimeSpan startTimeSpanFromNow = (startTime - DateTime.Now);
      TimeSpan endTimeSpanFromNow = (endTime - DateTime.Now);
      TimeSpan intervalStart = 
         (DateTime.UtcNow.Add(startTimeSpanFromNow)) - 
         new DateTime(1970, 1, 1, 0, 0, 0, DateTimeKind.Utc);
      TimeSpan intervalEnd = 
         (DateTime.UtcNow.Add(endTimeSpanFromNow)) - 
         new DateTime(1970, 1, 1, 0, 0, 0, DateTimeKind.Utc);

      int startTimestamp = (int)intervalStart.TotalSeconds; // START_TIME
      int endTimestamp = (int)intervalEnd.TotalSeconds;  // END_TIME

      if (startTimestamp > endTimestamp)
         return "Error!";

      // Replace variables in the policy statement.
      strPolicy = strPolicy.Replace("RESOURCE", resourceUrl);
      strPolicy = strPolicy.Replace("START_TIME", startTimestamp.ToString());
      strPolicy = strPolicy.Replace("END_TIME", endTimestamp.ToString());
      strPolicy = strPolicy.Replace("IP_ADDRESS", ipAddress);
      strPolicy = strPolicy.Replace("EXPIRES", endTimestamp.ToString());
      return strPolicy;
   }   
}

public static TimeSpan GetDuration(string units, string numUnits)
{
   TimeSpan timeSpanInterval = new TimeSpan();
   switch (units)
   {
      case "seconds":
         timeSpanInterval = new TimeSpan(0, 0, 0, int.Parse(numUnits));
         break;
      case "minutes":
         timeSpanInterval = new TimeSpan(0, 0, int.Parse(numUnits), 0);
         break;
      case "hours":
         timeSpanInterval = new TimeSpan(0, int.Parse(numUnits), 0 ,0);
         break;
      case "days":
         timeSpanInterval = new TimeSpan(int.Parse(numUnits),0 ,0 ,0);
         break;
      default:
         Console.WriteLine("Invalid time units;" + 
            "use seconds, minutes, hours, or days");
         break;
   }
   return timeSpanInterval;
}

private static TimeSpan GetDurationByUnits(string durationUnits, 
   string startIntervalFromNow)
{
   switch (durationUnits)
   {
      case "seconds":
         return new TimeSpan(0, 0, int.Parse(startIntervalFromNow));
      case "minutes":
         return new TimeSpan(0, int.Parse(startIntervalFromNow), 0);
      case "hours":
         return new TimeSpan(int.Parse(startIntervalFromNow), 0, 0);
      case "days":
         return new TimeSpan(int.Parse(startIntervalFromNow), 0, 0, 0);
      default:
         return new TimeSpan(0, 0, 0, 0);
   }
}

public static string CopyExpirationTimeFromPolicy(string policyStatement)
{
   int startExpiration = policyStatement.IndexOf("EpochTime");
   string strExpirationRough = policyStatement.Substring(startExpiration + 
      "EpochTime".Length);
   char[] digits = { '0', '1', '2', '3', '4', '5', '6', '7', '8', '9' };
         
   List<char> listDigits = new List<char>(digits);
   StringBuilder buildExpiration = new StringBuilder(20);
         
   foreach (char c in strExpirationRough)
   {
      if (listDigits.Contains(c))
         buildExpiration.Append(c);
   }
   return buildExpiration.ToString();   
}
```

Lihat juga
+ [Buat tanda tangan URL menggunakan Perl](CreateURLPerl.md)
+ [Buat tanda tangan URL menggunakan PHP](CreateURL_PHP.md)
+ [Buat tanda tangan URL menggunakan Java](CFPrivateDistJavaDevelopment.md)

# Buat tanda tangan URL menggunakan Java
<a name="CFPrivateDistJavaDevelopment"></a>

Selain contoh kode berikut, Anda dapat menggunakan [kelas `CloudFrontUrlSigner` utilitas di AWS SDK untuk Java (versi 1)](https://docs.aws.amazon.com/AWSJavaSDK/latest/javadoc/com/amazonaws/services/cloudfront/CloudFrontUrlSigner.html) untuk membuat [CloudFront ditandatangani URLs](private-content-signed-urls.md).

Untuk contoh selengkapnya, lihat [Membuat cookie yang ditandatangani URLs dan menggunakan AWS SDK](https://docs.aws.amazon.com/code-library/latest/ug/cloudfront_example_cloudfront_CloudFrontUtilities_section.html) di Perpustakaan *Kode Contoh Kode AWS SDK*. 

**Catatan**  
Membuat URL yang ditandatangani hanyalah salah satu bagian dari proses [penyajian konten pribadi CloudFront](PrivateContent.md). Untuk informasi selengkapnya tentang seluruh proses, lihat [Gunakan ditandatangani URLs](private-content-signed-urls.md).
Dalam `Signature.getInstance` panggilan, perhatikan yang `SHA1withRSA` dapat diganti dengan`SHA256withRSA`.

**Example Kebijakan Java dan metode enkripsi tanda tangan**  <a name="ExampleJavaPolicyAndSignatureEncryptionMethods"></a>

```
package org.example;

import java.time.Instant;
import java.time.temporal.ChronoUnit;
import software.amazon.awssdk.services.cloudfront.CloudFrontUtilities;
import software.amazon.awssdk.services.cloudfront.model.CannedSignerRequest;
import software.amazon.awssdk.services.cloudfront.url.SignedUrl;

public class Main {

    public static void main(String[] args) throws Exception {
        CloudFrontUtilities cloudFrontUtilities = CloudFrontUtilities.create();
        Instant expirationDate = Instant.now().plus(7, ChronoUnit.DAYS);
        String resourceUrl = "https://a1b2c3d4e5f6g7.cloudfront.net";
        String keyPairId = "K1UA3WV15I7JSD";
        CannedSignerRequest cannedRequest = CannedSignerRequest.builder()
                .resourceUrl(resourceUrl)
                .privateKey(new java.io.File("/path/to/private_key.pem").toPath())
                .keyPairId(keyPairId)
                .expirationDate(expirationDate)
                .build();
        SignedUrl signedUrl = cloudFrontUtilities.getSignedUrlWithCannedPolicy(cannedRequest);
        String url = signedUrl.url();
        System.out.println(url);

    }
}
```

**Example Contoh Penandatanganan Kebijakan Kalengan dengan SHA256 di Java**  <a name="ExampleJavaPolicySHA256AndSignatureEncryptionMethods"></a>

```
package org.example;

import java.io.File;
import java.nio.file.Files;
import java.security.KeyFactory;
import java.security.PrivateKey;
import java.security.Signature;
import java.security.spec.PKCS8EncodedKeySpec;
import java.time.Instant;
import java.time.temporal.ChronoUnit;
import java.util.Base64;

public class Main {

    public static void main(String[] args) throws Exception {
        String resourceUrl = "https://a1b2c3d4e5f6g7.cloudfront.net/myfile.html";
        String keyPairId = "K1UA3WV15I7JSD";
        Instant expiration = Instant.now().plus(7, ChronoUnit.DAYS);
        PrivateKey privateKey = loadPrivateKey("/path/to/private_key.der");

        System.out.println(createSignedUrl(resourceUrl, keyPairId, privateKey, expiration, "SHA1"));
        System.out.println(createSignedUrl(resourceUrl, keyPairId, privateKey, expiration, "SHA256"));
    }

    static String createSignedUrl(String resourceUrl, String keyPairId,
                                  PrivateKey privateKey, Instant expiration,
                                  String hashAlgorithm) throws Exception {
        long epochSeconds = expiration.getEpochSecond();

        String policy = "{\"Statement\":[{\"Resource\":\"" + resourceUrl
                + "\",\"Condition\":{\"DateLessThan\":{\"AWS:EpochTime\":" + epochSeconds + "}}}]}";

        String jcaAlgorithm = hashAlgorithm.equals("SHA256") ? "SHA256withRSA" : "SHA1withRSA";

        Signature sig = Signature.getInstance(jcaAlgorithm);
        sig.initSign(privateKey);
        sig.update(policy.getBytes("UTF-8"));
        String signature = base64UrlEncode(sig.sign());

        String url = resourceUrl
                + (resourceUrl.contains("?") ? "&" : "?")
                + "Expires=" + epochSeconds
                + "&Signature=" + signature
                + "&Key-Pair-Id=" + keyPairId;

        if (hashAlgorithm.equals("SHA256")) {
            url += "&Hash-Algorithm=SHA256";
        }

        return url;
    }

    static String base64UrlEncode(byte[] bytes) {
        return Base64.getEncoder().encodeToString(bytes)
                .replace('+', '-')
                .replace('=', '_')
                .replace('/', '~');
    }

    static PrivateKey loadPrivateKey(String path) throws Exception {
        byte[] keyBytes = Files.readAllBytes(new File(path).toPath());
        return KeyFactory.getInstance("RSA")
                .generatePrivate(new PKCS8EncodedKeySpec(keyBytes));
    }
}
```

Lihat juga:
+ [Buat tanda tangan URL menggunakan Perl](CreateURLPerl.md)
+ [Buat tanda tangan URL menggunakan PHP](CreateURL_PHP.md)
+ [Buat tanda tangan URL menggunakan C\$1 dan .NET Framework](CreateSignatureInCSharp.md)

# Batasi akses ke asal AWS
<a name="private-content-restricting-access-to-origin"></a>

Anda dapat mengonfigurasi CloudFront dan beberapa AWS asal dengan cara yang memberikan manfaat berikut:
+ Membatasi akses ke AWS asal sehingga tidak dapat diakses publik.
+ Memastikan bahwa pemirsa (pengguna) dapat mengakses konten di AWS asal hanya melalui CloudFront distribusi yang ditentukan. Ini mencegah pemirsa mengakses konten langsung dari asal, atau melalui distribusi yang tidak diinginkan CloudFront .

Untuk melakukan ini, konfigurasikan CloudFront untuk mengirim permintaan yang diautentikasi ke AWS asal Anda, dan konfigurasikan AWS asal untuk hanya mengizinkan akses ke permintaan yang diautentikasi dari. CloudFront Untuk informasi selengkapnya, lihat topik berikut untuk jenis AWS asal yang kompatibel.

**Topics**
+ [Batasi akses ke asal AWS Elemental MediaPackage v2](private-content-restricting-access-to-mediapackage.md)
+ [Batasi akses ke asal AWS Elemental MediaStore](private-content-restricting-access-to-mediastore.md)
+ [Batasi akses ke asal URL AWS Lambda fungsi](private-content-restricting-access-to-lambda.md)
+ [Batasi akses ke asal Amazon S3](private-content-restricting-access-to-s3.md)
+ [Batasi akses dengan asal VPC](private-content-vpc-origins.md)
+ [Batasi akses ke asal Titik Akses Multi-Wilayah Amazon S3](private-content-restricting-access-to-s3-mrap.md)

# Batasi akses ke asal AWS Elemental MediaPackage v2
<a name="private-content-restricting-access-to-mediapackage"></a>

CloudFront menyediakan *kontrol akses asal* (OAC) untuk membatasi akses ke asal MediaPackage v2.

**catatan**  
CloudFront OAC hanya mendukung MediaPackage v2. MediaPackage v1 tidak didukung.

**Topics**
+ [Membuat OAC baru](#create-oac-overview-mediapackage)
+ [Pengaturan lanjutan untuk kontrol akses asal](#oac-advanced-settings-mediapackage)

## Membuat OAC baru
<a name="create-oac-overview-mediapackage"></a>

Selesaikan langkah-langkah yang dijelaskan dalam topik berikut untuk menyiapkan OAC baru. CloudFront

**Topics**
+ [Prasyarat](#oac-prerequisites-mediapackage)
+ [Berikan CloudFront izin untuk mengakses asal MediaPackage v2](#oac-permission-to-access-mediapackage)
+ [Menciptakan OAC](#create-oac-mediapackage)

### Prasyarat
<a name="oac-prerequisites-mediapackage"></a>

Sebelum Anda membuat dan mengatur OAC, Anda harus memiliki CloudFront distribusi dengan asal MediaPackage v2. Untuk informasi selengkapnya, lihat [Gunakan MediaStore wadah atau MediaPackage saluran](DownloadDistS3AndCustomOrigins.md#concept_AWS_Media).

### Berikan CloudFront izin untuk mengakses asal MediaPackage v2
<a name="oac-permission-to-access-mediapackage"></a>

Sebelum Anda membuat OAC atau mengaturnya dalam CloudFront distribusi, pastikan bahwa CloudFront memiliki izin untuk mengakses asal MediaPackage v2. Lakukan ini setelah Anda membuat CloudFront distribusi, tetapi sebelum Anda menambahkan OAC ke asal MediaPackage v2 dalam konfigurasi distribusi.

Gunakan kebijakan IAM untuk mengizinkan prinsipal CloudFront layanan (`cloudfront.amazonaws.com`) mengakses asal. `Condition`Elemen dalam kebijakan memungkinkan CloudFront untuk mengakses asal MediaPackage v2 *hanya* jika permintaan atas nama CloudFront distribusi yang berisi asal MediaPackage v2. Ini adalah distribusi dengan asal MediaPackage v2 yang ingin Anda tambahkan OAC.

**Example : Kebijakan IAM yang memungkinkan akses hanya-baca untuk CloudFront distribusi dengan OAC diaktifkan**  
Kebijakan berikut memungkinkan akses CloudFront distribusi (`E1PDK09ESKHJWT`) ke asal MediaPackage v2. Asal adalah ARN yang ditentukan untuk elemen. `Resource`    
****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "AllowCloudFrontServicePrincipal",
            "Effect": "Allow",
            "Principal": {"Service": "cloudfront.amazonaws.com"},
            "Action": "mediapackagev2:GetObject",
            "Resource": "arn:aws:mediapackagev2:us-east-1:123456789012:channelGroup/channel-group-name/channel/channel-name/originEndpoint/origin_endpoint_name",
            "Condition": {
                "StringEquals": {"AWS:SourceArn": "arn:aws:cloudfront::123456789012:distribution/E1PDK09ESKHJWT"}
            }
        }
    ]
}
```

**Catatan**  
Jika Anda mengaktifkan fitur MQAR dan kontrol akses asal (OAC), tambahkan `mediapackagev2:GetHeadObject` tindakan ke kebijakan IAM. MQAR memerlukan izin ini untuk mengirim `HEAD` permintaan ke asal MediaPackage v2. Untuk informasi lebih lanjut tentang MQAR, lihat. [Ketahanan sadar kualitas media](media-quality-score.md)
Jika Anda membuat distribusi yang tidak memiliki izin ke asal MediaPackage v2 Anda, Anda dapat memilih **Salin kebijakan** dari CloudFront konsol dan kemudian memilih **Perbarui izin titik akhir**. Anda kemudian dapat melampirkan izin yang disalin ke titik akhir. Untuk informasi selengkapnya, lihat [bidang kebijakan titik akhir](https://docs.aws.amazon.com/mediapackage/latest/userguide/endpoints-policy.html) di *Panduan AWS Elemental MediaPackage Pengguna*. 

### Menciptakan OAC
<a name="create-oac-mediapackage"></a>

Untuk membuat OAC, Anda dapat menggunakan Konsol Manajemen AWS CloudFormation, AWS CLI, atau CloudFront API.

------
#### [ Console ]

**Untuk membuat OAC**

1. Masuk ke Konsol Manajemen AWS dan buka CloudFront konsol di[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Di panel navigasi, pilih **Akses asal**.

1. Pilih **Buat pengaturan kontrol**.

1. Pada formulir **Create new OAC**, lakukan hal berikut:

   1. Masukkan **Nama** dan (opsional) **Deskripsi** untuk OAC.

   1. Untuk **perilaku Penandatanganan**, sebaiknya Anda meninggalkan setelan default (**Permintaan tanda tangan (disarankan)**). Untuk informasi selengkapnya, lihat [Pengaturan lanjutan untuk kontrol akses asal](#oac-advanced-settings-mediapackage).

1. Untuk **tipe Origin**, pilih **MediaPackage V2**. 

1. Pilih **Buat**.
**Tip**  
Setelah Anda membuat OAC, catat **Nama**. Anda membutuhkan ini dalam prosedur berikut.

**Untuk menambahkan OAC ke asal MediaPackage v2 dalam distribusi**

1. Buka CloudFront konsol di[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Pilih distribusi dengan asal MediaPackage V2 yang ingin Anda tambahkan OAC, lalu pilih tab **Origins**.

1. Pilih asal MediaPackage v2 yang ingin Anda tambahkan OAC, lalu pilih **Edit**.

1. Pilih **HTTPS hanya** untuk **Protokol** asal Anda.

1. Dari menu tarik-turun **kontrol akses Origin**, pilih nama OAC yang ingin Anda gunakan.

1. Pilih **Simpan perubahan**.

Distribusi mulai menyebar ke semua lokasi CloudFront tepi. Ketika lokasi tepi menerima konfigurasi baru, ia menandatangani semua permintaan yang dikirim ke asal MediaPackage v2.

------
#### [ CloudFormation ]

Untuk membuat OAC dengan CloudFormation, gunakan jenis `AWS::CloudFront::OriginAccessControl` sumber daya. Contoh berikut menunjukkan sintaks CloudFormation template, dalam format YAMAL, untuk membuat OAC.

```
Type: AWS::CloudFront::OriginAccessControl
Properties: 
  OriginAccessControlConfig: 
      Description: An optional description for the origin access control
      Name: ExampleOAC
      OriginAccessControlOriginType: mediapackagev2
      SigningBehavior: always
      SigningProtocol: sigv4
```

Untuk informasi selengkapnya, lihat [AWS::CloudFront::OriginAccessKontrol](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-cloudfront-originaccesscontrol.html) di *Panduan AWS CloudFormation Pengguna*.

------
#### [ CLI ]

Untuk membuat kontrol akses asal dengan AWS Command Line Interface (AWS CLI), gunakan **aws cloudfront create-origin-access-control** perintah. Anda dapat menggunakan file input untuk memberikan parameter input untuk perintah, daripada menentukan setiap parameter individu sebagai input baris perintah.

**Untuk membuat kontrol akses asal (CLI dengan file input)**

1. Gunakan perintah berikut untuk membuat file yang diberi nama`origin-access-control.yaml`. File ini berisi semua parameter input untuk **create-origin-access-control** perintah.

   ```
   aws cloudfront create-origin-access-control --generate-cli-skeleton yaml-input > origin-access-control.yaml
   ```

1. Buka `origin-access-control.yaml` file yang baru saja Anda buat. Edit file untuk menambahkan nama untuk OAC, deskripsi (opsional), dan ubah `SigningBehavior` ke`always`. Kemudian simpan filenya.

   Untuk informasi tentang pengaturan OAC lainnya, lihat[Pengaturan lanjutan untuk kontrol akses asal](#oac-advanced-settings-mediapackage).

1. Gunakan perintah berikut untuk membuat kontrol akses asal menggunakan parameter input dari `origin-access-control.yaml` file.

   ```
   aws cloudfront create-origin-access-control --cli-input-yaml file://origin-access-control.yaml
   ```

   Catat `Id` nilai dalam output perintah. Anda membutuhkannya untuk menambahkan OAC ke asal MediaPackage v2 dalam CloudFront distribusi.

**Untuk melampirkan OAC ke asal MediaPackage v2 dalam distribusi yang ada (CLI dengan file input)**

1. Gunakan perintah berikut untuk menyimpan konfigurasi distribusi untuk CloudFront distribusi yang ingin Anda tambahkan OAC. Distribusi harus memiliki asal MediaPackage v2.

   ```
   aws cloudfront get-distribution-config --id <CloudFront distribution ID> --output yaml > dist-config.yaml
   ```

1. Buka file yang diberi nama `dist-config.yaml` yang baru saja Anda buat. Edit file akan membuat perubahan berikut:
   + Di `Origins` objek, tambahkan ID OAC ke bidang yang diberi `OriginAccessControlId` nama.
   + Hapus nilai dari bidang yang diberi nama`OriginAccessIdentity`, jika ada.
   + Ubah nama `ETag` bidang menjadi`IfMatch`, tetapi jangan ubah nilai bidang.

   Simpan file setelah selesai.

1. Gunakan perintah berikut untuk memperbarui distribusi untuk menggunakan kontrol akses asal.

   ```
   aws cloudfront update-distribution --id <CloudFront distribution ID> --cli-input-yaml file://dist-config.yaml
   ```

Distribusi mulai menyebar ke semua lokasi CloudFront tepi. Ketika lokasi tepi menerima konfigurasi baru, ia menandatangani semua permintaan yang dikirim ke asal MediaPackage v2.

------
#### [ API ]

Untuk membuat OAC dengan CloudFront API, gunakan [CreateOriginAccessControl](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateOriginAccessControl.html). Untuk informasi selengkapnya tentang bidang yang Anda tentukan dalam panggilan API ini, lihat dokumentasi referensi API untuk AWS SDK atau klien API lainnya.

Setelah membuat OAC, Anda dapat melampirkannya ke asal MediaPackage v2 dalam distribusi, menggunakan salah satu panggilan API berikut:
+ Untuk melampirkannya ke distribusi yang ada, gunakan [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html).
+ Untuk melampirkannya ke distribusi baru, gunakan [CreateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateDistribution.html).

Untuk kedua panggilan API ini, berikan ID OAC di `OriginAccessControlId` bidang, di dalam asal. Untuk informasi selengkapnya tentang bidang lain yang Anda tentukan dalam panggilan API ini, lihat [Semua referensi pengaturan distribusi](distribution-web-values-specify.md) dan dokumentasi referensi API untuk AWS SDK atau klien API lainnya.

------

## Pengaturan lanjutan untuk kontrol akses asal
<a name="oac-advanced-settings-mediapackage"></a>

Fitur CloudFront OAC mencakup pengaturan lanjutan yang ditujukan hanya untuk kasus penggunaan tertentu. Gunakan pengaturan yang disarankan kecuali Anda memiliki kebutuhan khusus untuk pengaturan lanjutan.

OAC berisi setelan bernama **Perilaku penandatanganan** (di konsol), atau `SigningBehavior` (di API, CLI, CloudFormation dan). Pengaturan ini menyediakan opsi berikut:

**Selalu tandatangani permintaan asal (pengaturan yang disarankan)**  
Sebaiknya gunakan pengaturan ini, bernama **Permintaan tanda (disarankan)** di konsol, atau `always` di API, CLI, dan. CloudFormation Dengan pengaturan ini, CloudFront selalu tandatangani semua permintaan yang dikirimkan ke asal MediaPackage v2.

**Jangan pernah menandatangani permintaan asal**  
Pengaturan ini diberi nama **Jangan menandatangani permintaan** di konsol, atau `never` di API, CLI, dan. CloudFormation Gunakan pengaturan ini untuk mematikan OAC untuk semua asal di semua distribusi yang menggunakan OAC ini. Ini dapat menghemat waktu dan tenaga dibandingkan dengan menghapus OAC dari semua asal dan distribusi yang menggunakannya, satu per satu. Dengan pengaturan ini, CloudFront tidak menandatangani permintaan apa pun yang dikirimkan ke asal MediaPackage v2.  
Untuk menggunakan pengaturan ini, asal MediaPackage v2 harus dapat diakses publik. Jika Anda menggunakan setelan ini dengan asal MediaPackage v2 yang tidak dapat diakses publik, tidak CloudFront dapat mengakses asal. Asal MediaPackage v2 mengembalikan kesalahan ke CloudFront dan CloudFront meneruskan kesalahan tersebut ke pemirsa. Untuk informasi selengkapnya, lihat contoh kebijakan MediaPackage v2 untuk [Kebijakan dan Izin MediaPackage](https://docs.aws.amazon.com/mediapackage/latest/userguide/policies-permissions.html) di *Panduan AWS Elemental MediaPackage Pengguna*.

**Jangan mengganti header penampil (klien) `Authorization`**  
Pengaturan ini diberi nama **Jangan timpa header otorisasi** di konsol, atau `no-override` di API, CLI, dan. CloudFormation Gunakan setelan ini saat Anda CloudFront ingin menandatangani permintaan asal hanya jika permintaan penampil yang sesuai tidak menyertakan `Authorization` header. Dengan pengaturan ini, CloudFront meneruskan `Authorization` header dari permintaan penampil saat ada, tetapi menandatangani permintaan asal (menambahkan tajuknya sendiri`Authorization`) saat permintaan penampil tidak menyertakan `Authorization` header.  
Untuk meneruskan `Authorization` header dari permintaan penampil, Anda *harus* menambahkan `Authorization` header ke [kebijakan cache](controlling-the-cache-key.md) untuk semua perilaku cache yang menggunakan asal MediaPackage v2 yang terkait dengan kontrol akses asal ini.

# Batasi akses ke asal AWS Elemental MediaStore
<a name="private-content-restricting-access-to-mediastore"></a>

CloudFront menyediakan *kontrol akses asal* (OAC) untuk membatasi akses ke asal AWS Elemental MediaStore .

**Topics**
+ [Buat kontrol akses asal baru](#create-oac-overview-mediastore)
+ [Pengaturan lanjutan untuk kontrol akses asal](#oac-advanced-settings-mediastore)

## Buat kontrol akses asal baru
<a name="create-oac-overview-mediastore"></a>

Selesaikan langkah-langkah yang dijelaskan dalam topik berikut untuk menyiapkan kontrol akses asal baru CloudFront.

**Topics**
+ [Prasyarat](#oac-prerequisites-mediastore)
+ [Berikan CloudFront izin untuk mengakses MediaStore asal](#oac-permission-to-access-mediastore)
+ [Buat kontrol akses asal](#create-oac-mediastore)

### Prasyarat
<a name="oac-prerequisites-mediastore"></a>

Sebelum Anda membuat dan mengatur kontrol akses asal, Anda harus memiliki CloudFront distribusi dengan MediaStore asal. 

### Berikan CloudFront izin untuk mengakses MediaStore asal
<a name="oac-permission-to-access-mediastore"></a>

Sebelum Anda membuat kontrol akses asal atau mengaturnya dalam CloudFront distribusi, pastikan bahwa CloudFront memiliki izin untuk mengakses MediaStore asal. Lakukan ini setelah membuat CloudFront distribusi, tetapi sebelum menambahkan OAC ke MediaStore asal dalam konfigurasi distribusi. 

Gunakan kebijakan MediaStore kontainer untuk mengizinkan CloudFront service principal (`cloudfront.amazonaws.com`) mengakses origin. Gunakan `Condition` elemen dalam kebijakan CloudFront untuk mengizinkan akses MediaStore penampung hanya jika permintaan atas nama CloudFront distribusi yang berisi MediaStore asal. Ini adalah distribusi dengan MediaStore asal yang ingin Anda tambahkan OAC.

Berikut ini adalah contoh kebijakan MediaStore kontainer yang memungkinkan CloudFront distribusi mengakses MediaStore asal.

**Example MediaStore kebijakan kontainer yang memungkinkan akses hanya-baca untuk CloudFront distribusi dengan OAC diaktifkan**    
****  

```
{
        "Version":"2012-10-17",		 	 	 
        "Statement": [
            {
                "Sid": "AllowCloudFrontServicePrincipalReadOnly",
                "Effect": "Allow",
                "Principal": {
                  "Service": "cloudfront.amazonaws.com"
                },
                "Action": [ 
                  "mediastore:GetObject"
                ],
                "Resource": "arn:aws:mediastore:us-east-1:111122223333:container/<container name>/*",
                "Condition": {
                    "StringEquals": {
                      "AWS:SourceArn": "arn:aws:cloudfront::111122223333:distribution/CloudFront-distribution-ID"
                    },
                    "Bool": {
                      "aws:SecureTransport": "true"
                    }
                }
            }
        ]
}
```

**Example MediaStore kebijakan kontainer yang memungkinkan akses baca dan tulis untuk CloudFront distribusi dengan OAC diaktifkan**    
****  

```
{
        "Version":"2012-10-17",		 	 	 
        "Statement": [
            {
                "Sid": "AllowCloudFrontServicePrincipalReadWrite",
                "Effect": "Allow",
                "Principal": {
                  "Service": "cloudfront.amazonaws.com"
                },
                "Action": [ 
                  "mediastore:GetObject",
                  "mediastore:PutObject"
                ],
                "Resource": "arn:aws:mediastore:us-east-1:111122223333:container/container-name/*",
                "Condition": {
                    "StringEquals": {
                      "AWS:SourceArn": "arn:aws:cloudfront::111122223333:distribution/CloudFront-distribution-ID"
                    },
                    "Bool": {
                      "aws:SecureTransport": "true"
                    }
                }
            }
        ]
}
```

**catatan**  
Untuk mengizinkan akses tulis, Anda harus mengonfigurasi **metode HTTP yang Diizinkan** untuk disertakan `PUT` dalam pengaturan perilaku CloudFront distribusi Anda.

### Buat kontrol akses asal
<a name="create-oac-mediastore"></a>

Untuk membuat OAC, Anda dapat menggunakan Konsol Manajemen AWS CloudFormation, AWS CLI, atau CloudFront API.

------
#### [ Console ]

**Untuk membuat kontrol akses asal**

1. Masuk ke Konsol Manajemen AWS dan buka CloudFront konsol di[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Di panel navigasi, pilih **Akses asal**.

1. Pilih **Buat pengaturan kontrol**.

1. Pada formulir **pengaturan Create control**, lakukan hal berikut:

   1. Di panel **Detail**, masukkan **Nama** dan (opsional) **Deskripsi** untuk kontrol akses asal.

   1. Di panel **Pengaturan**, kami sarankan Anda meninggalkan pengaturan default (**Permintaan tanda tangan (disarankan))**. Untuk informasi selengkapnya, lihat [Pengaturan lanjutan untuk kontrol akses asal](#oac-advanced-settings-mediastore).

1. Pilih MediaStore dari **dropdown tipe Origin**.

1. Pilih **Buat**.

   Setelah OAC dibuat, catat **Namanya**. Anda membutuhkan ini dalam prosedur berikut.

**Untuk menambahkan kontrol akses asal ke MediaStore asal dalam distribusi**

1. Buka CloudFront konsol di[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Pilih distribusi dengan MediaStore asal yang ingin Anda tambahkan OAC, lalu pilih tab **Origins**.

1. Pilih MediaStore asal yang ingin Anda tambahkan OAC, lalu pilih **Edit**.

1. Pilih **HTTPS hanya** untuk **Protokol** asal Anda.

1. Dari menu tarik-turun **kontrol akses Origin**, pilih OAC yang ingin Anda gunakan.

1. Pilih **Simpan perubahan**.

Distribusi mulai menyebar ke semua lokasi CloudFront tepi. Saat lokasi tepi menerima konfigurasi baru, ia akan menandatangani semua permintaan yang dikirimkan ke asal MediaStore bucket.

------
#### [ CloudFormation ]

Untuk membuat kontrol akses asal (OAC) dengan CloudFormation, gunakan jenis `AWS::CloudFront::OriginAccessControl` sumber daya. Contoh berikut menunjukkan sintaks CloudFormation template, dalam format YAMM, untuk membuat kontrol akses asal.

```
Type: AWS::CloudFront::OriginAccessControl
Properties: 
  OriginAccessControlConfig: 
      Description: An optional description for the origin access control
      Name: ExampleOAC
      OriginAccessControlOriginType: mediastore
      SigningBehavior: always
      SigningProtocol: sigv4
```

Untuk informasi selengkapnya, lihat [AWS::CloudFront::OriginAccessKontrol](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-cloudfront-originaccesscontrol.html) di *Panduan AWS CloudFormation Pengguna*.

------
#### [ CLI ]

Untuk membuat kontrol akses asal dengan AWS Command Line Interface (AWS CLI), gunakan **aws cloudfront create-origin-access-control** perintah. Anda dapat menggunakan file input untuk memberikan parameter input untuk perintah, daripada menentukan setiap parameter individu sebagai input baris perintah.

**Untuk membuat kontrol akses asal (CLI dengan file input)**

1. Gunakan perintah berikut untuk membuat file yang diberi nama`origin-access-control.yaml`. File ini berisi semua parameter input untuk **create-origin-access-control** perintah.

   ```
   aws cloudfront create-origin-access-control --generate-cli-skeleton yaml-input > origin-access-control.yaml
   ```

1. Buka `origin-access-control.yaml` file yang baru saja Anda buat. Edit file untuk menambahkan nama untuk OAC, deskripsi (opsional), dan ubah `SigningBehavior` ke`always`. Kemudian simpan filenya.

   Untuk informasi tentang pengaturan OAC lainnya, lihat[Pengaturan lanjutan untuk kontrol akses asal](#oac-advanced-settings-mediastore).

1. Gunakan perintah berikut untuk membuat kontrol akses asal menggunakan parameter input dari `origin-access-control.yaml` file.

   ```
   aws cloudfront create-origin-access-control --cli-input-yaml file://origin-access-control.yaml
   ```

   Catat `Id` nilai dalam output perintah. Anda membutuhkannya untuk menambahkan OAC ke MediaStore asal dalam CloudFront distribusi.

**Untuk melampirkan OAC ke MediaStore asal dalam distribusi yang ada (CLI dengan file input)**

1. Gunakan perintah berikut untuk menyimpan konfigurasi distribusi untuk CloudFront distribusi yang ingin Anda tambahkan OAC. Distribusi harus memiliki MediaStore asal.

   ```
   aws cloudfront get-distribution-config --id <CloudFront distribution ID> --output yaml > dist-config.yaml
   ```

1. Buka file yang diberi nama `dist-config.yaml` yang baru saja Anda buat. Edit file akan membuat perubahan berikut:
   + Di `Origins` objek, tambahkan ID OAC ke bidang yang diberi `OriginAccessControlId` nama.
   + Hapus nilai dari bidang yang diberi nama`OriginAccessIdentity`, jika ada.
   + Ubah nama `ETag` bidang menjadi`IfMatch`, tetapi jangan ubah nilai bidang.

   Simpan file setelah selesai.

1. Gunakan perintah berikut untuk memperbarui distribusi untuk menggunakan kontrol akses asal.

   ```
   aws cloudfront update-distribution --id <CloudFront distribution ID> --cli-input-yaml file://dist-config.yaml
   ```

Distribusi mulai menyebar ke semua lokasi CloudFront tepi. Ketika lokasi tepi menerima konfigurasi baru, ia menandatangani semua permintaan yang dikirim ke MediaStore asal.

------
#### [ API ]

Untuk membuat kontrol akses asal dengan CloudFront API, gunakan [CreateOriginAccessControl](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateOriginAccessControl.html). Untuk informasi selengkapnya tentang bidang yang Anda tentukan dalam panggilan API ini, lihat dokumentasi referensi API untuk AWS SDK atau klien API lainnya.

Setelah membuat kontrol akses asal, Anda dapat melampirkannya ke MediaStore asal dalam distribusi, menggunakan salah satu panggilan API berikut:
+ Untuk melampirkannya ke distribusi yang ada, gunakan [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html).
+ Untuk melampirkannya ke distribusi baru, gunakan [CreateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateDistribution.html).

Untuk kedua panggilan API ini, berikan ID kontrol akses asal di `OriginAccessControlId` bidang, di dalam asal. Untuk informasi selengkapnya tentang bidang lain yang Anda tentukan dalam panggilan API ini, lihat [Semua referensi pengaturan distribusi](distribution-web-values-specify.md) dan dokumentasi referensi API untuk AWS SDK atau klien API lainnya.

------

## Pengaturan lanjutan untuk kontrol akses asal
<a name="oac-advanced-settings-mediastore"></a>

Fitur kontrol akses CloudFront asal mencakup pengaturan lanjutan yang ditujukan hanya untuk kasus penggunaan tertentu. Gunakan pengaturan yang disarankan kecuali Anda memiliki kebutuhan khusus untuk pengaturan lanjutan.

Kontrol akses asal berisi setelan bernama **Perilaku penandatanganan** (di konsol), atau `SigningBehavior` (di API, CLI, dan CloudFormation). Pengaturan ini menyediakan opsi berikut:

**Selalu tandatangani permintaan asal (pengaturan yang disarankan)**  
Sebaiknya gunakan pengaturan ini, bernama **Permintaan tanda (disarankan)** di konsol, atau `always` di API, CLI, dan. CloudFormation Dengan pengaturan ini, CloudFront selalu tandatangani semua permintaan yang dikirim ke MediaStore asal.

**Jangan pernah menandatangani permintaan asal**  
Pengaturan ini diberi nama **Jangan menandatangani permintaan** di konsol, atau `never` di API, CLI, dan. CloudFormation Gunakan pengaturan ini untuk menonaktifkan kontrol akses asal untuk semua asal di semua distribusi yang menggunakan kontrol akses asal ini. Ini dapat menghemat waktu dan tenaga dibandingkan dengan menghapus kontrol akses asal dari semua asal dan distribusi yang menggunakannya, satu per satu. Dengan pengaturan ini, CloudFront tidak menandatangani permintaan apa pun yang dikirim ke MediaStore asal.  
Untuk menggunakan pengaturan ini, MediaStore asal harus dapat diakses publik. Jika Anda menggunakan setelan ini dengan MediaStore asal yang tidak dapat diakses publik, CloudFront tidak dapat mengakses asal. MediaStore Asal mengembalikan kesalahan ke CloudFront dan CloudFront meneruskan kesalahan tersebut ke pemirsa. Untuk informasi selengkapnya, lihat contoh kebijakan MediaStore kontainer untuk [akses baca Publik melalui HTTPS](https://docs.aws.amazon.com/mediastore/latest/ug/policies-examples-public-https.html).

**Jangan mengganti header penampil (klien) `Authorization`**  
Pengaturan ini diberi nama **Jangan timpa header otorisasi** di konsol, atau `no-override` di API, CLI, dan. CloudFormation Gunakan setelan ini saat Anda CloudFront ingin menandatangani permintaan asal hanya jika permintaan penampil yang sesuai tidak menyertakan `Authorization` header. Dengan pengaturan ini, CloudFront meneruskan `Authorization` header dari permintaan penampil saat ada, tetapi menandatangani permintaan asal (menambahkan tajuknya sendiri`Authorization`) saat permintaan penampil tidak menyertakan `Authorization` header.  
Untuk meneruskan `Authorization` header dari permintaan penampil, Anda *harus* menambahkan `Authorization` header ke [kebijakan cache](controlling-the-cache-key.md) untuk semua perilaku cache yang menggunakan MediaStore asal yang terkait dengan kontrol akses asal ini.

# Batasi akses ke asal URL AWS Lambda fungsi
<a name="private-content-restricting-access-to-lambda"></a>

CloudFront menyediakan *kontrol akses asal* (OAC) untuk membatasi akses ke asal URL fungsi Lambda.

**Topics**
+ [Buat OAC baru](#create-oac-overview-lambda)
+ [Pengaturan lanjutan untuk kontrol akses asal](#oac-advanced-settings-lambda)
+ [Contoh kode template](#example-template-code-lambda-oac)

## Buat OAC baru
<a name="create-oac-overview-lambda"></a>

Selesaikan langkah-langkah yang dijelaskan dalam topik berikut untuk menyiapkan OAC baru. CloudFront

**penting**  
Jika Anda menggunakan `PUT` atau `POST` metode dengan URL fungsi Lambda Anda, pengguna Anda harus menghitung isi dan menyertakan nilai hash payload dari badan permintaan di `x-amz-content-sha256` header saat mengirim permintaan ke. SHA256 CloudFront Lambda tidak mendukung muatan yang tidak ditandatangani.

**Topics**
+ [Prasyarat](#oac-prerequisites-lambda)
+ [Berikan CloudFront izin untuk mengakses URL fungsi Lambda](#oac-permission-to-access-lambda)
+ [Buat OAC](#create-oac-lambda)

### Prasyarat
<a name="oac-prerequisites-lambda"></a>

Sebelum Anda membuat dan mengatur OAC, Anda harus memiliki CloudFront distribusi dengan URL fungsi Lambda sebagai asal. Untuk menggunakan OAC, Anda harus menentukan `AWS_IAM` sebagai nilai untuk `AuthType` parameter. Untuk informasi selengkapnya, lihat [Gunakan URL fungsi Lambda](DownloadDistS3AndCustomOrigins.md#concept_lambda_function_url).

### Berikan CloudFront izin untuk mengakses URL fungsi Lambda
<a name="oac-permission-to-access-lambda"></a>

Sebelum Anda membuat OAC atau mengaturnya dalam CloudFront distribusi, pastikan bahwa CloudFront memiliki izin untuk mengakses URL fungsi Lambda. Lakukan ini setelah Anda membuat CloudFront distribusi, tetapi sebelum Anda menambahkan OAC ke URL fungsi Lambda dalam konfigurasi distribusi.

**catatan**  
Untuk memperbarui kebijakan IAM untuk URL fungsi Lambda, Anda harus menggunakan () AWS Command Line Interface .AWS CLI Mengedit kebijakan IAM di konsol Lambda tidak didukung saat ini.

 AWS CLI Perintah berikut memberikan akses CloudFront service principal (`cloudfront.amazonaws.com`) ke URL fungsi Lambda Anda. `Condition`Elemen dalam kebijakan memungkinkan CloudFront untuk mengakses Lambda *hanya* jika permintaan atas nama CloudFront distribusi yang berisi URL fungsi Lambda. Ini adalah distribusi dengan asal URL fungsi Lambda yang ingin Anda tambahkan OAC.

**Example : AWS CLI perintah untuk memperbarui kebijakan untuk mengizinkan akses hanya-baca untuk CloudFront distribusi dengan OAC diaktifkan**  
 AWS CLI Perintah berikut memungkinkan CloudFront distribusi (`E1PDK09ESKHJWT`) akses ke Lambda *`FUNCTION_URL_NAME`* Anda.

```
aws lambda add-permission \
--statement-id "AllowCloudFrontServicePrincipal" \
--action "lambda:InvokeFunctionUrl" \
--principal "cloudfront.amazonaws.com" \
--source-arn "arn:aws:cloudfront::123456789012:distribution/E1PDK09ESKHJWT" \
--function-name FUNCTION_URL_NAME
```

```
aws lambda add-permission \
--statement-id "AllowCloudFrontServicePrincipalInvokeFunction" \
--action "lambda:InvokeFunction" \
--principal "cloudfront.amazonaws.com" \
--source-arn "arn:aws:cloudfront::123456789012:distribution/E1PDK09ESKHJWT" \
--function-name FUNCTION_URL_NAME
```

**catatan**  
Jika Anda membuat distribusi dan tidak memiliki izin ke URL fungsi Lambda Anda, Anda dapat memilih Salin perintah **CLI dari CloudFront konsol, lalu masukkan perintah** ini dari terminal baris perintah Anda. Untuk informasi selengkapnya, lihat [Memberikan akses fungsi Layanan AWS](https://docs.aws.amazon.com/lambda/latest/dg/access-control-resource-based.html#permissions-resource-serviceinvoke) di *Panduan AWS Lambda Pengembang*. 

### Buat OAC
<a name="create-oac-lambda"></a>

Untuk membuat OAC, Anda dapat menggunakan Konsol Manajemen AWS CloudFormation, AWS CLI, atau CloudFront API.

------
#### [ Console ]

**Untuk membuat OAC**

1. Masuk ke Konsol Manajemen AWS dan buka CloudFront konsol di[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Di panel navigasi, pilih **Akses asal**.

1. Pilih **Buat pengaturan kontrol**.

1. Pada formulir **Create new OAC**, lakukan hal berikut:

   1. Masukkan **Nama** dan (opsional) **Deskripsi** untuk OAC.

   1. Untuk **perilaku Penandatanganan**, sebaiknya Anda meninggalkan pengaturan default (**Permintaan tanda tangan (disarankan)**). Untuk informasi selengkapnya, lihat [Pengaturan lanjutan untuk kontrol akses asal](#oac-advanced-settings-lambda).

1. Untuk **tipe Origin**, pilih **Lambda**. 

1. Pilih **Buat**.
**Tip**  
Setelah Anda membuat OAC, catat **Nama**. Anda membutuhkan ini dalam prosedur berikut.

**Untuk menambahkan kontrol akses asal ke URL fungsi Lambda dalam distribusi**

1. Buka CloudFront konsol di[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. **Pilih distribusi dengan URL fungsi Lambda yang ingin Anda tambahkan OAC, lalu pilih tab Origins.**

1. **Pilih URL fungsi Lambda yang ingin Anda tambahkan OAC, lalu pilih Edit.**

1. Pilih **HTTPS hanya** untuk **Protokol** asal Anda.

1. Dari menu tarik-turun **kontrol akses Origin**, pilih nama OAC yang ingin Anda gunakan.

1. Pilih **Simpan perubahan**.

Distribusi mulai menyebar ke semua lokasi CloudFront tepi. Ketika lokasi tepi menerima konfigurasi baru, ia menandatangani semua permintaan yang dikirim ke URL fungsi Lambda.

------
#### [ CloudFormation ]

Untuk membuat OAC dengan CloudFormation, gunakan jenis `AWS::CloudFront::OriginAccessControl` sumber daya. Contoh berikut menunjukkan sintaks CloudFormation template, dalam format YAMAL, untuk membuat OAC.

```
Type: AWS::CloudFront::OriginAccessControl
Properties: 
  OriginAccessControlConfig: 
      Description: An optional description for the origin access control
      Name: ExampleOAC
      OriginAccessControlOriginType: lambda
      SigningBehavior: always
      SigningProtocol: sigv4
```

Untuk informasi selengkapnya, lihat [AWS::CloudFront::OriginAccessKontrol](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-cloudfront-originaccesscontrol.html) di *Panduan AWS CloudFormation Pengguna*.

------
#### [ CLI ]

Untuk membuat kontrol akses asal dengan AWS Command Line Interface (AWS CLI), gunakan **aws cloudfront create-origin-access-control** perintah. Anda dapat menggunakan file input untuk memberikan parameter input untuk perintah, daripada menentukan setiap parameter individu sebagai input baris perintah.

**Untuk membuat kontrol akses asal (CLI dengan file input)**

1. Gunakan perintah berikut untuk membuat file yang diberi nama`origin-access-control.yaml`. File ini berisi semua parameter input untuk **create-origin-access-control** perintah.

   ```
   aws cloudfront create-origin-access-control --generate-cli-skeleton yaml-input > origin-access-control.yaml
   ```

1. Buka `origin-access-control.yaml` file yang baru saja Anda buat. Edit file untuk menambahkan nama untuk OAC, deskripsi (opsional), dan ubah `SigningBehavior` ke`always`. Kemudian simpan filenya.

   Untuk informasi tentang pengaturan OAC lainnya, lihat[Pengaturan lanjutan untuk kontrol akses asal](#oac-advanced-settings-lambda).

1. Gunakan perintah berikut untuk membuat kontrol akses asal menggunakan parameter input dari `origin-access-control.yaml` file.

   ```
   aws cloudfront create-origin-access-control --cli-input-yaml file://origin-access-control.yaml
   ```

   Catat `Id` nilai dalam output perintah. Anda membutuhkannya untuk menambahkan OAC ke URL fungsi Lambda dalam CloudFront distribusi.

**Untuk melampirkan OAC ke URL fungsi Lambda dalam distribusi yang ada (CLI dengan file input)**

1. Gunakan perintah berikut untuk menyimpan konfigurasi distribusi untuk CloudFront distribusi yang ingin Anda tambahkan OAC. Distribusi harus memiliki URL fungsi Lambda sebagai asal.

   ```
   aws cloudfront get-distribution-config --id <CloudFront distribution ID> --output yaml > dist-config.yaml
   ```

1. Buka file yang diberi nama `dist-config.yaml` yang baru saja Anda buat. Edit file akan membuat perubahan berikut:
   + Di `Origins` objek, tambahkan ID OAC ke bidang yang diberi `OriginAccessControlId` nama.
   + Hapus nilai dari bidang yang diberi nama`OriginAccessIdentity`, jika ada.
   + Ubah nama `ETag` bidang menjadi`IfMatch`, tetapi jangan ubah nilai bidang.

   Simpan file setelah selesai.

1. Gunakan perintah berikut untuk memperbarui distribusi untuk menggunakan kontrol akses asal.

   ```
   aws cloudfront update-distribution --id <CloudFront distribution ID> --cli-input-yaml file://dist-config.yaml
   ```

Distribusi mulai menyebar ke semua lokasi CloudFront tepi. Ketika lokasi tepi menerima konfigurasi baru, ia menandatangani semua permintaan yang dikirim ke URL fungsi Lambda.

------
#### [ API ]

Untuk membuat OAC dengan CloudFront API, gunakan [CreateOriginAccessControl](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateOriginAccessControl.html). Untuk informasi selengkapnya tentang bidang yang Anda tentukan dalam panggilan API ini, lihat dokumentasi referensi API untuk AWS SDK atau klien API lainnya.

Setelah membuat OAC, Anda dapat melampirkannya ke URL fungsi Lambda dalam distribusi, menggunakan salah satu panggilan API berikut:
+ Untuk melampirkannya ke distribusi yang ada, gunakan [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html).
+ Untuk melampirkannya ke distribusi baru, gunakan [CreateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateDistribution.html).

Untuk kedua panggilan API ini, berikan ID OAC di `OriginAccessControlId` bidang, di dalam asal. Untuk informasi selengkapnya tentang bidang lain yang Anda tentukan dalam panggilan API ini, lihat dan dokumentasi referensi API untuk AWS SDK atau klien API lainnya.

------

## Pengaturan lanjutan untuk kontrol akses asal
<a name="oac-advanced-settings-lambda"></a>

Fitur CloudFront OAC mencakup pengaturan lanjutan yang ditujukan hanya untuk kasus penggunaan tertentu. Gunakan pengaturan yang disarankan kecuali Anda memiliki kebutuhan khusus untuk pengaturan lanjutan.

OAC berisi setelan bernama **Perilaku penandatanganan** (di konsol), atau `SigningBehavior` (di API, CLI, CloudFormation dan). Pengaturan ini menyediakan opsi berikut:

**Selalu tandatangani permintaan asal (pengaturan yang disarankan)**  
Sebaiknya gunakan pengaturan ini, bernama **Permintaan tanda (disarankan)** di konsol, atau `always` di API, CLI, dan. CloudFormation Dengan pengaturan ini, CloudFront selalu tandatangani semua permintaan yang dikirimkan ke URL fungsi Lambda.

**Jangan pernah menandatangani permintaan asal**  
Pengaturan ini diberi nama **Jangan menandatangani permintaan** di konsol, atau `never` di API, CLI, dan. CloudFormation Gunakan pengaturan ini untuk mematikan OAC untuk semua asal di semua distribusi yang menggunakan OAC ini. Ini dapat menghemat waktu dan tenaga dibandingkan dengan menghapus OAC dari semua asal dan distribusi yang menggunakannya, satu per satu. Dengan pengaturan ini, CloudFront tidak menandatangani permintaan apa pun yang dikirimkan ke URL fungsi Lambda.  
Untuk menggunakan pengaturan ini, URL fungsi Lambda harus dapat diakses publik. Jika Anda menggunakan setelan ini dengan URL fungsi Lambda yang tidak dapat diakses publik, tidak CloudFront dapat mengakses asal. URL fungsi Lambda mengembalikan kesalahan ke CloudFront dan CloudFront meneruskan kesalahan tersebut ke pemirsa. Untuk informasi selengkapnya, lihat [Model keamanan dan autentikasi untuk URLs fungsi Lambda](https://docs.aws.amazon.com/lambda/latest/dg/urls-auth.html) di Panduan Pengguna *AWS Lambda .*

**Jangan mengganti header penampil (klien) `Authorization`**  
Pengaturan ini diberi nama **Jangan timpa header otorisasi** di konsol, atau `no-override` di API, CLI, dan. CloudFormation Gunakan setelan ini saat Anda CloudFront ingin menandatangani permintaan asal hanya jika permintaan penampil yang sesuai tidak menyertakan `Authorization` header. Dengan pengaturan ini, CloudFront meneruskan `Authorization` header dari permintaan penampil saat ada, tetapi menandatangani permintaan asal (menambahkan tajuknya sendiri`Authorization`) saat permintaan penampil tidak menyertakan `Authorization` header.  
+ Jika Anda menggunakan setelan ini, Anda harus menentukan penandatanganan Tanda Tangan Versi 4 untuk URL fungsi Lambda, bukan nama CloudFront distribusi atau CNAME. Saat CloudFront meneruskan `Authorization` header dari permintaan penampil ke URL fungsi Lambda, Lambda akan memvalidasi tanda tangan terhadap host domain URL Lambda. Jika tanda tangan tidak didasarkan pada domain URL Lambda, host dalam tanda tangan tidak akan cocok dengan host yang digunakan oleh asal URL Lambda. Ini berarti permintaan akan gagal, menghasilkan kesalahan validasi tanda tangan.
+ Untuk meneruskan `Authorization` header dari permintaan penampil, Anda *harus* menambahkan `Authorization` header ke [kebijakan cache](controlling-the-cache-key.md) untuk semua perilaku cache yang menggunakan fungsi Lambda yang URLs terkait dengan kontrol akses asal ini.

## Contoh kode template
<a name="example-template-code-lambda-oac"></a>

Jika CloudFront asal Anda adalah URL fungsi Lambda yang terkait dengan OAC, Anda dapat menggunakan skrip Python berikut untuk mengunggah file ke fungsi Lambda dengan metode tersebut. `POST` 

Kode ini mengasumsikan bahwa Anda mengonfigurasi OAC dengan perilaku penandatanganan default yang disetel ke **Selalu menandatangani permintaan asal** dan Anda tidak memilih setelan header **Jangan timpa otorisasi**.

Konfigurasi ini memungkinkan OAC untuk mengelola otorisasi SiGv4 dengan benar dengan Lambda dengan menggunakan nama host Lambda. Payload ditandatangani dengan menggunakan Sigv4 dari identitas IAM yang diotorisasi untuk URL fungsi Lambda, yang ditetapkan sebagai tipe. `IAM_AUTH` 

Template menunjukkan cara menangani nilai hash payload yang ditandatangani di x-amz-content-sha256 header untuk `POST` permintaan dari sisi klien. Secara khusus, template ini dirancang untuk mengelola muatan data formulir. Template memungkinkan unggahan file aman ke URL fungsi Lambda CloudFront melalui, dan AWS menggunakan mekanisme otentikasi untuk memastikan bahwa hanya permintaan resmi yang dapat mengakses fungsi Lambda.

**Kode ini mencakup fungsionalitas berikut:**  
Memenuhi persyaratan untuk memasukkan hash payload di header x-amz-content-sha256
Menggunakan otentikasi SiGv4 untuk akses aman Layanan AWS 
Mendukung unggahan file dengan menggunakan data formulir multi-bagian
Termasuk penanganan kesalahan untuk pengecualian permintaan

```
import boto3
from botocore.auth import SigV4Auth
from botocore.awsrequest import AWSRequest
import requests
import hashlib
import os


def calculate_body_hash(body):
    return hashlib.sha256(body).hexdigest()


def sign_request(request, credentials, region, service):
    sigv4 = SigV4Auth(credentials, service, region)
    sigv4.add_auth(request)


def upload_file_to_lambda(cloudfront_url, file_path, region):
    # AWS credentials
    session = boto3.Session()
    credentials = session.get_credentials()

    # Prepare the multipart form-data
    boundary = "------------------------boundary"

    # Read file content
    with open(file_path, 'rb') as file:
        file_content = file.read()

    # Get the filename from the path
    filename = os.path.basename(file_path)

    # Prepare the multipart body
    body = (
        f'--{boundary}\r\n'
        f'Content-Disposition: form-data; name="file"; filename="{filename}"\r\n'
        f'Content-Type: application/octet-stream\r\n\r\n'
    ).encode('utf-8')
    body += file_content
    body += f'\r\n--{boundary}--\r\n'.encode('utf-8')

    # Calculate SHA256 hash of the entire body
    body_hash = calculate_body_hash(body)

    # Prepare headers
    headers = {
        'Content-Type': f'multipart/form-data; boundary={boundary}',
        'x-amz-content-sha256': body_hash
    }

    # Create the request
    request = AWSRequest(
        method='POST',
        url=cloudfront_url,
        data=body,
        headers=headers
    )

    # Sign the request
    sign_request(request, credentials, region, 'lambda')

    # Get the signed headers
    signed_headers = dict(request.headers)

    # Print request headers before sending
    print("Request Headers:")
    for header, value in signed_headers.items():
        print(f"{header}: {value}")

    try:
        # Send POST request with signed headers
        response = requests.post(
            cloudfront_url,
            data=body,
            headers=signed_headers
        )

        # Print response status and content
        print(f"\nStatus code: {response.status_code}")
        print("Response:", response.text)

        # Print response headers
        print("\nResponse Headers:")
        for header, value in response.headers.items():
            print(f"{header}: {value}")

    except requests.exceptions.RequestException as e:
        print(f"An error occurred: {e}")


# Usage
cloudfront_url = "https://d111111abcdef8.cloudfront.net"
file_path = r"filepath"
region = "us-east-1"  # example: "us-west-2"

upload_file_to_lambda(cloudfront_url, file_path, region)
```

# Batasi akses ke asal Amazon S3
<a name="private-content-restricting-access-to-s3"></a>

CloudFront menyediakan dua cara untuk mengirim permintaan yang diautentikasi ke asal Amazon S3*: kontrol akses asal* (OAC) *dan identitas akses asal* (OAI). OAC membantu Anda mengamankan asal Anda, seperti Amazon S3. 

Kami *menyarankan* Anda menggunakan OAC sebagai gantinya karena mendukung fitur-fitur berikut:
+ Semua bucket Amazon S3 secara keseluruhan Wilayah AWS, termasuk Wilayah keikutsertaan diluncurkan setelah Desember 2022
+ Enkripsi [sisi server Amazon S3 dengan (SSE-KMS](https://docs.aws.amazon.com/AmazonS3/latest/userguide/serv-side-encryption.html)) AWS KMS
+ Permintaan dinamis (`PUT`dan`DELETE`) ke Amazon S3

OAI tidak mendukung fitur-fitur ini atau memerlukan solusi tambahan dalam skenario tersebut. Jika Anda sudah menggunakan OAI dan ingin bermigrasi, lihat. [Migrasi dari Origin Access Identity (OAI) ke Origin Access Control (OAC)](#migrate-from-oai-to-oac)

**Catatan**  
Saat menggunakan CloudFront OAC dengan asal bucket Amazon S3, Anda harus menyetel Kepemilikan **Objek Amazon S3** ke **pemilik Bucket yang diberlakukan, default untuk bucket** Amazon S3 baru. Jika perlu ACLs, gunakan setelan **pilihan pemilik Bucket** untuk mempertahankan kontrol atas objek yang diunggah melalui CloudFront.
Jika asal Anda adalah bucket Amazon S3 yang dikonfigurasi sebagai [titik akhir situs web](https://docs.aws.amazon.com/AmazonS3/latest/userguide/WebsiteEndpoints.html), Anda harus mengaturnya CloudFront sebagai asal khusus. Itu berarti Anda tidak dapat menggunakan OAC (atau OAI). OAC tidak mendukung pengalihan asal dengan menggunakan Lambda @Edge.
Jika Anda menggunakan Titik Akses Multi-Wilayah Amazon S3 sebagai CloudFront asal Anda, lihat. [Batasi akses ke asal Titik Akses Multi-Wilayah Amazon S3](private-content-restricting-access-to-s3-mrap.md) S3 Multi-Region Access Points memerlukan konfigurasi OAC yang berbeda.

Topik berikut menjelaskan cara menggunakan OAC dengan asal Amazon S3. 

**Topik**
+ [Buat kontrol akses asal baru](#create-oac-overview-s3)
+ [Hapus distribusi dengan OAC yang terpasang pada bucket S3](#delete-oac-distribution-s3)
+ [Migrasi dari Origin Access Identity (OAI) ke Origin Access Control (OAC)](#migrate-from-oai-to-oac)
+ [Pengaturan lanjutan untuk kontrol akses asal](#oac-advanced-settings-s3)

## Buat kontrol akses asal baru
<a name="create-oac-overview-s3"></a>

Selesaikan langkah-langkah yang dijelaskan dalam topik berikut untuk menyiapkan kontrol akses asal baru CloudFront.

**Topics**
+ [Prasyarat](#oac-prerequisites-s3)
+ [Berikan CloudFront izin untuk mengakses bucket S3](#oac-permission-to-access-s3)
+ [Buat kontrol akses asal](#create-oac-s3)

### Prasyarat
<a name="oac-prerequisites-s3"></a>

Sebelum membuat dan mengatur kontrol akses asal (OAC), Anda harus memiliki CloudFront distribusi dengan asal bucket Amazon S3. Asal ini harus berupa bucket S3 biasa, bukan bucket yang dikonfigurasi sebagai titik [akhir situs web](https://docs.aws.amazon.com/AmazonS3/latest/userguide/WebsiteEndpoints.html). Untuk informasi selengkapnya tentang menyiapkan CloudFront distribusi dengan asal bucket S3, lihat[Memulai dengan distribusi CloudFront standar](GettingStarted.SimpleDistribution.md).

**penting**  
**Saat Anda menggunakan OAC untuk mengamankan asal Amazon S3 Anda, komunikasi CloudFront antara dan Amazon S3 selalu melalui HTTPS, tetapi hanya ketika Anda memilih untuk selalu menandatangani permintaan.** Anda harus memilih **Permintaan tanda tangan (disarankan)** di konsol atau tentukan `always` di CloudFront API, AWS CLI, atau CloudFormation.   
Jika Anda memilih opsi **Jangan menandatangani permintaan** atau **Jangan timpa header otorisasi**, CloudFront gunakan protokol koneksi yang Anda tentukan dalam kebijakan berikut:  
[Kebijakan protokol penampil](using-https-viewers-to-cloudfront.md) 
[Kebijakan protokol asal](DownloadDistValuesOrigin.md#DownloadDistValuesOriginProtocolPolicy) (hanya asal kustom)
[Misalnya, jika Anda memilih **Jangan timpa header otorisasi** dan ingin menggunakan HTTPS antara CloudFront dan asal Amazon S3 Anda, **gunakan Redirect HTTP ke HTTPS **atau HTTPS** hanya untuk kebijakan** protokol penampil.](using-https-viewers-to-cloudfront.md)

### Berikan CloudFront izin untuk mengakses bucket S3
<a name="oac-permission-to-access-s3"></a>

Sebelum Anda membuat kontrol akses asal (OAC) atau mengaturnya dalam CloudFront distribusi, pastikan bahwa CloudFront memiliki izin untuk mengakses asal bucket S3. Lakukan ini setelah membuat CloudFront distribusi, tetapi sebelum menambahkan OAC ke asal S3 dalam konfigurasi distribusi.

Gunakan [kebijakan bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucket-policies.html) S3 untuk mengizinkan CloudFront service principal (`cloudfront.amazonaws.com`) mengakses bucket. Gunakan `Condition` elemen dalam kebijakan CloudFront untuk mengizinkan akses bucket hanya jika permintaan tersebut atas nama CloudFront distribusi yang berisi asal S3. Ini adalah distribusi dengan asal S3 yang ingin Anda tambahkan OAC.

Untuk informasi tentang menambahkan atau memodifikasi kebijakan bucket, lihat [Menambahkan kebijakan bucket menggunakan konsol Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/add-bucket-policy.html) di Panduan Pengguna *Amazon S3*.

Berikut ini adalah contoh kebijakan bucket S3 yang memungkinkan CloudFront distribusi dengan akses berkemampuan OAC ke asal S3.

**Example Kebijakan bucket S3 yang memungkinkan akses hanya-baca untuk CloudFront distribusi dengan OAC diaktifkan**    
****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Sid": "AllowCloudFrontServicePrincipalReadOnly",
      "Effect": "Allow",
      "Principal": {
        "Service": "cloudfront.amazonaws.com"
      },
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*",
      "Condition": {
        "StringEquals": {
          "AWS:SourceArn": "arn:aws:cloudfront::111122223333:distribution/<CloudFront distribution ID>"
        }
      }
    }
  ]
}
```

**Example Kebijakan bucket S3 yang memungkinkan akses baca dan tulis untuk CloudFront distribusi dengan OAC diaktifkan**    
****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Sid": "AllowCloudFrontServicePrincipalReadWrite",
      "Effect": "Allow",
      "Principal": {
        "Service": "cloudfront.amazonaws.com"
      },
      "Action": [
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*",
      "Condition": {
        "StringEquals": {
          "AWS:SourceArn": "arn:aws:cloudfront::111122223333:distribution/CloudFront-distribution-ID>"
        }
      }
    }
  ]
}
```

#### SSE-KMS
<a name="oac-permissions-sse-kms"></a>

Jika objek dalam asal bucket S3 dienkripsi menggunakan [enkripsi sisi server dengan AWS Key Management Service (SSE-KMS)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingKMSEncryption.html), Anda harus memastikan bahwa distribusi memiliki izin untuk menggunakan kunci. CloudFront AWS KMS Untuk memberikan izin CloudFront distribusi untuk menggunakan kunci KMS, tambahkan pernyataan ke kebijakan [kunci KMS](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html). Untuk informasi tentang cara mengubah kebijakan kunci, lihat [Mengubah kebijakan kunci](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-modifying.html) di *Panduan AWS Key Management Service Pengembang*.

**Example Pernyataan kebijakan kunci KMS**  
Contoh berikut menunjukkan pernyataan AWS KMS kebijakan yang memungkinkan CloudFront distribusi dengan OAC untuk mengakses kunci KMS untuk SSE-KMS.  

```
{
    "Sid": "AllowCloudFrontServicePrincipalSSE-KMS",
    "Effect": "Allow",
    "Principal": {
        "Service": [
            "cloudfront.amazonaws.com"
        ]
     },
    "Action": [
        "kms:Decrypt",
        "kms:Encrypt",
        "kms:GenerateDataKey*"
    ],
    "Resource": "*",
    "Condition": {
            "StringEquals": {
                "AWS:SourceArn": "arn:aws:cloudfront::111122223333:distribution/<CloudFront distribution ID>"
            }
        }
}
```

### Buat kontrol akses asal
<a name="create-oac-s3"></a>

Untuk membuat kontrol akses asal (OAC), Anda dapat menggunakan Konsol Manajemen AWS CloudFormation, AWS CLI, atau CloudFront API.

------
#### [ Console ]

**Untuk membuat kontrol akses asal**

1. Masuk ke Konsol Manajemen AWS dan buka CloudFront konsol di[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Di panel navigasi, pilih **Akses asal**.

1. Pilih **Buat pengaturan kontrol**.

1. Pada formulir **pengaturan Create control**, lakukan hal berikut:

   1. Di panel **Detail**, masukkan **Nama** dan (opsional) **Deskripsi** untuk kontrol akses asal.

   1. Di panel **Pengaturan**, kami sarankan Anda meninggalkan pengaturan default (**Permintaan tanda tangan (disarankan))**. Untuk informasi selengkapnya, lihat [Pengaturan lanjutan untuk kontrol akses asal](#oac-advanced-settings-s3).

1. Pilih S3 dari dropdown **tipe Origin**.

1. Pilih **Buat**.

   Setelah OAC dibuat, catat **Namanya**. Anda membutuhkan ini dalam prosedur berikut.

**Untuk menambahkan kontrol akses asal ke asal S3 dalam distribusi**

1. Buka CloudFront konsol di[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Pilih distribusi dengan asal S3 yang ingin Anda tambahkan OAC, lalu pilih tab **Origins**.

1. **Pilih asal S3 yang ingin Anda tambahkan OAC, lalu pilih Edit.**

1. Untuk **akses Origin**, pilih **Pengaturan kontrol akses Origin (disarankan)**.

1. Dari menu tarik-turun **kontrol akses Origin**, pilih OAC yang ingin Anda gunakan.

1. Pilih **Simpan perubahan**.

Distribusi mulai menyebar ke semua lokasi CloudFront tepi. Saat lokasi edge menerima konfigurasi baru, ia menandatangani semua permintaan yang dikirimkan ke bucket origin S3.

------
#### [ CloudFormation ]

Untuk membuat kontrol akses asal (OAC) dengan CloudFormation, gunakan jenis `AWS::CloudFront::OriginAccessControl` sumber daya. Contoh berikut menunjukkan sintaks CloudFormation template, dalam format YAMM, untuk membuat kontrol akses asal.

```
Type: AWS::CloudFront::OriginAccessControl
Properties: 
  OriginAccessControlConfig: 
      Description: An optional description for the origin access control
      Name: ExampleOAC
      OriginAccessControlOriginType: s3
      SigningBehavior: always
      SigningProtocol: sigv4
```

Untuk informasi selengkapnya, lihat [AWS::CloudFront::OriginAccessKontrol](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-cloudfront-originaccesscontrol.html) di *Panduan AWS CloudFormation Pengguna*.

------
#### [ CLI ]

Untuk membuat kontrol akses asal dengan AWS Command Line Interface (AWS CLI), gunakan **aws cloudfront create-origin-access-control** perintah. Anda dapat menggunakan file input untuk memberikan parameter input untuk perintah, daripada menentukan setiap parameter individu sebagai input baris perintah.

**Untuk membuat kontrol akses asal (CLI dengan file input)**

1. Gunakan perintah berikut untuk membuat file yang diberi nama`origin-access-control.yaml`. File ini berisi semua parameter input untuk **create-origin-access-control** perintah.

   ```
   aws cloudfront create-origin-access-control --generate-cli-skeleton yaml-input > origin-access-control.yaml
   ```

1. Buka `origin-access-control.yaml` file yang baru saja Anda buat. Edit file untuk menambahkan nama untuk OAC, deskripsi (opsional), dan ubah `SigningBehavior` ke`always`. Kemudian simpan filenya.

   Untuk informasi tentang pengaturan OAC lainnya, lihat[Pengaturan lanjutan untuk kontrol akses asal](#oac-advanced-settings-s3).

1. Gunakan perintah berikut untuk membuat kontrol akses asal menggunakan parameter input dari `origin-access-control.yaml` file.

   ```
   aws cloudfront create-origin-access-control --cli-input-yaml file://origin-access-control.yaml
   ```

   Catat `Id` nilai dalam output perintah. Anda membutuhkannya untuk menambahkan OAC ke asal bucket S3 dalam distribusi. CloudFront 

**Untuk melampirkan OAC ke asal bucket S3 dalam distribusi yang ada (CLI dengan file input)**

1. Gunakan perintah berikut untuk menyimpan konfigurasi distribusi untuk CloudFront distribusi yang ingin Anda tambahkan OAC. Distribusi harus memiliki asal bucket S3.

   ```
   aws cloudfront get-distribution-config --id <CloudFront distribution ID> --output yaml > dist-config.yaml
   ```

1. Buka file yang diberi nama `dist-config.yaml` yang baru saja Anda buat. Edit file akan membuat perubahan berikut:
   + Di `Origins` objek, tambahkan ID OAC ke bidang yang diberi `OriginAccessControlId` nama.
   + Hapus nilai dari bidang yang diberi nama`OriginAccessIdentity`, jika ada.
   + Ubah nama `ETag` bidang menjadi`IfMatch`, tetapi jangan ubah nilai bidang.

   Simpan file setelah selesai.

1. Gunakan perintah berikut untuk memperbarui distribusi untuk menggunakan kontrol akses asal.

   ```
   aws cloudfront update-distribution --id <CloudFront distribution ID> --cli-input-yaml file://dist-config.yaml
   ```

Distribusi mulai menyebar ke semua lokasi CloudFront tepi. Saat lokasi edge menerima konfigurasi baru, ia menandatangani semua permintaan yang dikirimkan ke bucket origin S3.

------
#### [ API ]

Untuk membuat kontrol akses asal dengan CloudFront API, gunakan [CreateOriginAccessControl](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateOriginAccessControl.html). Untuk informasi selengkapnya tentang bidang yang Anda tentukan dalam panggilan API ini, lihat dokumentasi referensi API untuk AWS SDK atau klien API lainnya.

Setelah membuat kontrol akses asal, Anda dapat melampirkannya ke bucket origin S3 dalam distribusi, menggunakan salah satu panggilan API berikut:
+ Untuk melampirkannya ke distribusi yang ada, gunakan [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html).
+ Untuk melampirkannya ke distribusi baru, gunakan [CreateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateDistribution.html).

Untuk kedua panggilan API ini, berikan ID kontrol akses asal di `OriginAccessControlId` bidang, di dalam asal. Untuk informasi selengkapnya tentang bidang lain yang Anda tentukan dalam panggilan API ini, lihat [Semua referensi pengaturan distribusi](distribution-web-values-specify.md) dan dokumentasi referensi API untuk AWS SDK atau klien API lainnya.

------

## Hapus distribusi dengan OAC yang terpasang pada bucket S3
<a name="delete-oac-distribution-s3"></a>

Jika Anda perlu menghapus distribusi dengan OAC yang terpasang pada bucket S3, Anda harus menghapus distribusi sebelum menghapus asal bucket S3. Atau, sertakan Wilayah dalam nama domain asal. Jika ini tidak memungkinkan, Anda dapat menghapus OAC dari distribusi dengan beralih ke publik sebelum dihapus. Untuk informasi selengkapnya, lihat [Menghapus sebuah distribusi](HowToDeleteDistribution.md).

## Migrasi dari Origin Access Identity (OAI) ke Origin Access Control (OAC)
<a name="migrate-from-oai-to-oac"></a>

Untuk bermigrasi dari identitas akses asal lama (OAI) ke kontrol akses asal (OAC), perbarui terlebih dahulu asal bucket S3 untuk memungkinkan OAI dan distribusi dengan OAC diaktifkan untuk mengakses konten bucket. Ini memastikan bahwa CloudFront tidak pernah kehilangan akses ke bucket selama transisi. Untuk memungkinkan OAI dan distribusi dengan OAC diaktifkan mengakses bucket S3, perbarui [kebijakan bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucket-policies.html) untuk menyertakan dua pernyataan, satu untuk setiap jenis prinsipal.

Contoh kebijakan bucket S3 berikut memungkinkan OAI dan distribusi dengan OAC diaktifkan untuk mengakses asal S3.

**Example Kebijakan bucket S3 yang memungkinkan akses hanya-baca untuk OAI dan distribusi dengan OAC diaktifkan CloudFront**    
****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "AllowCloudFrontServicePrincipalReadOnly",
            "Effect": "Allow",
            "Principal": {
                "Service": "cloudfront.amazonaws.com"
            },
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::<S3 bucket name>/*",
            "Condition": {
                "StringEquals": {
                    "AWS:SourceArn": "arn:aws:cloudfront::111122223333:distribution/<CloudFront distribution ID>"
                }
            }
        },
        {
            "Sid": "AllowLegacyOAIReadOnly",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity <origin access identity ID>"
            },
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::<S3 bucket name>/*"
        }
    ]
}
```

Setelah memperbarui kebijakan bucket asal S3 untuk mengizinkan akses ke OAI dan OAC, Anda dapat memperbarui konfigurasi distribusi untuk menggunakan OAC, bukan OAI. Untuk informasi selengkapnya, lihat [Buat kontrol akses asal baru](#create-oac-overview-s3).

Setelah distribusi sepenuhnya diterapkan, Anda dapat menghapus pernyataan dalam kebijakan bucket yang memungkinkan akses ke OAI. Untuk informasi selengkapnya, lihat [Berikan CloudFront izin untuk mengakses bucket S3](#oac-permission-to-access-s3).

## Pengaturan lanjutan untuk kontrol akses asal
<a name="oac-advanced-settings-s3"></a>

Fitur kontrol akses CloudFront asal mencakup pengaturan lanjutan yang ditujukan hanya untuk kasus penggunaan tertentu. Gunakan pengaturan yang disarankan kecuali Anda memiliki kebutuhan khusus untuk pengaturan lanjutan.

Kontrol akses asal berisi setelan bernama **Perilaku penandatanganan** (di konsol), atau `SigningBehavior` (di API, CLI, dan CloudFormation). Pengaturan ini menyediakan opsi berikut:

**Selalu tandatangani permintaan asal (pengaturan yang disarankan)**  
Sebaiknya gunakan pengaturan ini, bernama **Permintaan tanda (disarankan)** di konsol, atau `always` di API, CLI, dan. CloudFormation Dengan pengaturan ini, CloudFront selalu tandatangani semua permintaan yang dikirimkan ke asal bucket S3.

**Jangan pernah menandatangani permintaan asal**  
Pengaturan ini diberi nama **Jangan menandatangani permintaan** di konsol, atau `never` di API, CLI, dan. CloudFormation Gunakan pengaturan ini untuk menonaktifkan kontrol akses asal untuk semua asal di semua distribusi yang menggunakan kontrol akses asal ini. Ini dapat menghemat waktu dan tenaga dibandingkan dengan menghapus kontrol akses asal dari semua asal dan distribusi yang menggunakannya, satu per satu. Dengan pengaturan ini, CloudFront tidak menandatangani permintaan apa pun yang dikirim ke asal bucket S3.  
Untuk menggunakan pengaturan ini, asal bucket S3 harus dapat diakses publik. Jika Anda menggunakan setelan ini dengan asal bucket S3 yang tidak dapat diakses publik, CloudFront tidak dapat mengakses asal. Asal bucket S3 mengembalikan kesalahan ke CloudFront dan CloudFront meneruskan kesalahan tersebut ke pemirsa.

**Jangan mengganti header penampil (klien) `Authorization`**  
Pengaturan ini diberi nama **Jangan timpa header otorisasi** di konsol, atau `no-override` di API, CLI, dan. CloudFormation Gunakan setelan ini saat Anda CloudFront ingin menandatangani permintaan asal hanya jika permintaan penampil yang sesuai tidak menyertakan `Authorization` header. Dengan pengaturan ini, CloudFront meneruskan `Authorization` header dari permintaan penampil saat ada, tetapi menandatangani permintaan asal (menambahkan tajuknya sendiri`Authorization`) saat permintaan penampil tidak menyertakan `Authorization` header.  
Untuk meneruskan `Authorization` header dari permintaan penampil, Anda *harus* menambahkan `Authorization` header ke [kebijakan cache](controlling-the-cache-key.md) untuk semua perilaku cache yang menggunakan asal bucket S3 yang terkait dengan kontrol akses asal ini.

## Gunakan identitas akses asal (warisan, tidak disarankan)
<a name="private-content-restricting-access-to-s3-oai"></a>

### Ikhtisar identitas akses asal
<a name="private-content-restricting-access-to-s3-overview"></a>

CloudFront *Origin Access Identity* (OAI) menyediakan fungsionalitas yang mirip dengan *Origin Access Control* (OAC), tetapi tidak berfungsi untuk semua skenario. Secara khusus, OAI tidak mendukung:
+ Bucket Amazon S3 di semua, termasuk Wilayah Wilayah AWS keikutsertaan
+ Enkripsi [sisi server Amazon S3 dengan (SSE-KMS](https://docs.aws.amazon.com/AmazonS3/latest/userguide/serv-side-encryption.html)) AWS KMS
+ Permintaan dinamis (`PUT``POST`,, atau`DELETE`) ke Amazon S3
+ Baru Wilayah AWS diluncurkan setelah Januari 2023

**Tip**  
Kami menyarankan Anda menggunakan OAC sebagai gantinya. Untuk mengatur OAC, lihat[Buat kontrol akses asal baru](#create-oac-overview-s3). Untuk informasi tentang cara bermigrasi dari OAI ke OAC, lihat. [Migrasi dari Origin Access Identity (OAI) ke Origin Access Control (OAC)](#migrate-from-oai-to-oac)

### Berikan izin identitas akses asal untuk membaca file di bucket Amazon S3
<a name="private-content-granting-permissions-to-oai"></a>

Saat membuat OAI atau menambahkannya ke distribusi dengan CloudFront konsol, Anda dapat memperbarui kebijakan bucket Amazon S3 secara otomatis untuk memberikan izin kepada OAI untuk mengakses bucket Anda. Atau, Anda dapat memilih untuk membuat atau memperbarui kebijakan bucket secara manual. Metode apa pun yang Anda gunakan, Anda masih harus meninjau izin untuk memastikan bahwa:
+  CloudFront OAI Anda dapat mengakses file dalam ember atas nama pemirsa yang memintanya. CloudFront
+ Pemirsa tidak dapat menggunakan Amazon S3 URLs untuk mengakses file Anda di luar. CloudFront

**penting**  
Jika Anda mengonfigurasi CloudFront untuk menerima dan meneruskan semua metode HTTP yang CloudFront mendukung, pastikan Anda memberikan CloudFront OAI izin yang diinginkan. Misalnya, jika Anda mengonfigurasi CloudFront untuk menerima dan meneruskan permintaan yang menggunakan `DELETE` metode ini, konfigurasikan kebijakan bucket Anda untuk menangani `DELETE` permintaan dengan tepat sehingga penonton hanya dapat menghapus file yang Anda inginkan.

#### Menggunakan kebijakan bucket Amazon S3
<a name="private-content-updating-s3-bucket-policies"></a>

Anda dapat memberikan akses CloudFront OAI ke file di bucket Amazon S3 dengan membuat atau memperbarui kebijakan bucket dengan cara berikut:
+ [Menggunakan tab **Izin** bucket Amazon S3 di konsol Amazon S3.](https://console.aws.amazon.com/s3/home)
+ Menggunakan [PutBucketPolicy](https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutBucketPolicy.html) di API Amazon S3.
+ Menggunakan [CloudFront konsol](https://console.aws.amazon.com/cloudfront/v4/home). Saat menambahkan OAI ke setelan asal di CloudFront konsol, Anda dapat memilih **Ya, perbarui kebijakan bucket** untuk memberi tahu CloudFront agar kebijakan bucket diperbarui atas nama Anda.

Jika Anda memperbarui kebijakan keranjang secara manual, pastikan bahwa Anda:
+ Tentukan OAI yang tepat sebagai `Principal` dalam kebijakan.
+ Berikan izin yang diperlukan OAI untuk mengakses objek atas nama penampil.

Untuk informasi selengkapnya, silakan lihat bagian-bagian berikut ini.

##### Tentukan OAI sebagai `Principal` kebijakan dalam bucket
<a name="private-content-updating-s3-bucket-policies-principal"></a>

Untuk menentukan OAI sebagai kebijakan bucket Amazon S3, gunakan Nama Sumber Daya Amazon (ARN) OAI, yang menyertakan ID OAI. `Principal` Contoh:

```
"Principal": {
    "AWS": "arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity <origin access identity ID>"
}
```

Temukan ID OAI di CloudFront konsol di bawah **Security**, **Origin access**, **Identities (legacy)**. Atau, gunakan [ListCloudFrontOriginAccessIdentities](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_ListCloudFrontOriginAccessIdentities.html)di CloudFront API.

##### Berikan izin ke OAI
<a name="private-content-updating-s3-bucket-policies-permissions"></a>

Untuk memberikan izin kepada OAI untuk mengakses objek di bucket Amazon S3 Anda, gunakan tindakan dalam kebijakan yang terkait dengan operasi API Amazon S3 tertentu. Misalnya, `s3:GetObject` tindakan memungkinkan OAI untuk membaca objek di ember. Untuk informasi selengkapnya, lihat contoh di bagian berikut, atau lihat [tindakan Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/dev/using-with-s3-actions.html) di *Panduan Pengguna Layanan Penyimpanan Sederhana Amazon*.

##### Contoh kebijakan bucket Amazon S3
<a name="private-content-updating-s3-bucket-policies-examples"></a>

Contoh berikut menunjukkan kebijakan bucket Amazon S3 yang memungkinkan CloudFront OAI mengakses bucket S3.

Temukan ID OAI di CloudFront konsol di bawah **Security**, **Origin access**, **Identities (legacy)**. Atau, gunakan [ListCloudFrontOriginAccessIdentities](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_ListCloudFrontOriginAccessIdentities.html)di CloudFront API.

**Example Kebijakan buket Amazon S3 yang memberikan akses baca OAI**  
Contoh berikut memungkinkan OAI untuk membaca objek dalam buket yang ditentukan (`s3:GetObject`).    
****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Id": "PolicyForCloudFrontPrivateContent",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity <origin access identity ID>"
            },
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::<S3 bucket name>/*"
        }
    ]
}
```

**Example Kebijakan buket Amazon S3 yang memberikan akses baca dan tulis OAI**  
Contoh berikut memungkinkan OAI untuk membaca dan menulis objek dalam buket yang ditentukan (`s3:GetObject` dan `s3:PutObject`). Ini memungkinkan pemirsa untuk mengunggah file ke bucket Amazon S3 Anda. CloudFront    
****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Id": "PolicyForCloudFrontPrivateContent",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity <origin access identity ID>"
            },
            "Action": [
                "s3:GetObject",
                "s3:PutObject"
            ],
            "Resource": "arn:aws:s3:::<S3 bucket name>/*"
        }
    ]
}
```

#### Gunakan objek Amazon S3 ACLs (tidak disarankan)
<a name="private-content-updating-s3-acls"></a>

**penting**  
Sebaiknya [gunakan kebijakan bucket Amazon S3](#private-content-updating-s3-bucket-policies) untuk memberikan akses OAI ke bucket S3. Anda dapat menggunakan daftar kontrol akses (ACLs) seperti yang dijelaskan di bagian ini, tetapi kami tidak merekomendasikannya.  
Amazon S3 merekomendasikan untuk menyetel [Kepemilikan Objek S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/about-object-ownership.html) ke **pemilik bucket yang diberlakukan**, yang berarti hal itu ACLs dinonaktifkan untuk bucket dan objek di dalamnya. Saat menerapkan pengaturan ini untuk Kepemilikan Objek, Anda harus menggunakan kebijakan bucket untuk memberikan akses ke OAI (lihat bagian sebelumnya).  
Bagian berikut ini hanya untuk kasus penggunaan lama yang membutuhkan ACLs.

Anda dapat memberikan akses CloudFront OAI ke file di bucket Amazon S3 dengan membuat atau memperbarui ACL file dengan cara berikut:
+ [Menggunakan tab **Izin** objek Amazon S3 di konsol Amazon S3.](https://console.aws.amazon.com/s3/home)
+ Menggunakan [PutObjectAcl](https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutObjectAcl.html) di API Amazon S3.

Ketika Anda memberikan akses ke OAI menggunakan ACL, Anda harus menentukan OAI menggunakan ID pengguna kanonik Amazon S3. Di CloudFront konsol, Anda dapat menemukan ID ini di bawah **Keamanan**, **akses Asal**, **Identitas (warisan)**. Jika Anda menggunakan CloudFront API, gunakan nilai `S3CanonicalUserId` elemen yang dikembalikan saat Anda membuat OAI, atau panggil [ListCloudFrontOriginAccessIdentities](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_ListCloudFrontOriginAccessIdentities.html)di CloudFront API.

### Menggunakan identitas akses asal di wilayah Amazon S3 yang hanya mendukung otentikasi tanda tangan versi 4
<a name="private-content-origin-access-identity-signature-version-4"></a>

Wilayah Amazon S3 yang lebih baru mengharuskan Anda menggunakan Signature Version 4 untuk permintaan yang diautentikasi. (Untuk versi tanda tangan yang didukung di setiap Wilayah Amazon S3, lihat [titik akhir dan kuota Amazon Simple Storage Service](https://docs.aws.amazon.com/general/latest/gr/s3.html) di.) *Referensi Umum AWS* Jika Anda menggunakan identitas akses asal dan jika bucket Anda berada di salah satu Wilayah yang memerlukan Tanda Tangan Versi 4, perhatikan hal berikut:
+ `DELETE`, `GET`, `HEAD`, `OPTIONS`, dan `PATCH` permintaan didukung tanpa kualifikasi.
+ `POST` permintaan tidak didukung.

# Batasi akses dengan asal VPC
<a name="private-content-vpc-origins"></a>

Anda dapat menggunakannya CloudFront untuk mengirimkan konten dari aplikasi yang di-host di subnet pribadi virtual private cloud (VPC) Anda. Anda dapat menggunakan Application Load Balancers (ALB), Network Load Balancers (NLBs), dan instans EC2 di subnet pribadi sebagai asal VPC.

Berikut adalah beberapa alasan mengapa Anda mungkin ingin menggunakan asal VPC:
+ **Keamanan** - Asal VPC dirancang untuk meningkatkan postur keamanan aplikasi Anda dengan menempatkan penyeimbang beban dan instans EC2 Anda di subnet pribadi, menjadikan titik masuk tunggal. CloudFront Permintaan pengguna beralih dari CloudFront ke asal VPC melalui koneksi pribadi dan aman, memberikan keamanan tambahan untuk aplikasi Anda.
+ **Manajemen** — Asal VPC mengurangi overhead operasional yang diperlukan untuk konektivitas yang aman antara CloudFront dan asal. Anda dapat memindahkan asal Anda ke subnet pribadi tanpa akses publik, dan Anda tidak perlu menerapkan daftar kontrol akses (ACLs) atau mekanisme lain untuk membatasi akses ke asal Anda. Dengan cara ini, Anda tidak perlu berinvestasi dalam pekerjaan pengembangan yang tidak terdiferensiasi untuk mengamankan aplikasi web Anda. CloudFront 
+ **Skalabilitas dan kinerja** - Asal VPC membantu Anda mengamankan aplikasi web Anda, membebaskan waktu untuk fokus pada pengembangan aplikasi bisnis penting Anda sambil meningkatkan keamanan dan mempertahankan kinerja tinggi dan skalabilitas global dengan. CloudFront Asal VPC merampingkan manajemen keamanan dan mengurangi kompleksitas operasional sehingga Anda dapat menggunakannya CloudFront sebagai titik masuk tunggal untuk aplikasi Anda.

**Tip**  
CloudFront mendukung berbagi asal VPC di seluruh Akun AWS, apakah mereka berada di organisasi Anda atau tidak. Anda dapat membagikan asal VPC dari CloudFront konsol atau menggunakan AWS Resource Access Manager ()AWS RAM. Untuk informasi selengkapnya, lihat [Bekerja dengan sumber daya bersama di CloudFront](sharing-resources.md).

## Prasyarat
<a name="vpc-origin-prerequisites"></a>

Sebelum Anda membuat asal VPC untuk CloudFront distribusi Anda, Anda harus menyelesaikan yang berikut ini:

### Konfigurasi VPC
<a name="vpc-configuration"></a>

**Buat virtual private cloud (VPC) di Amazon VPC** di salah satu Wilayah AWS yang didukung untuk asal VPC. *Untuk informasi tentang membuat VPC, lihat [Membuat VPC plus sumber daya VPC lainnya di Panduan Pengguna Amazon VPC](https://docs.aws.amazon.com/vpc/latest/userguide/create-vpc.html#create-vpc-and-other-resources).* Untuk mengetahui daftar Wilayah yang didukung, lihat [Didukung Wilayah AWS untuk asal VPC](#vpc-origins-supported-regions).

VPC Anda harus menyertakan hal-hal berikut:
+ **Internet gateway** — Anda perlu menambahkan gateway internet ke VPC yang memiliki sumber daya asal VPC Anda. Gateway internet diperlukan untuk menunjukkan bahwa VPC dapat menerima lalu lintas dari internet. Gateway internet tidak digunakan untuk merutekan lalu lintas ke asal di dalam subnet, dan Anda tidak perlu memperbarui kebijakan perutean.
+ **Subnet pribadi dengan setidaknya satu IPv4 alamat yang tersedia** — CloudFront rute ke subnet Anda dengan menggunakan service-managed elastic network interface (ENI) yang CloudFront dibuat setelah Anda menentukan sumber daya asal VPC Anda. CloudFront Anda harus memiliki setidaknya satu IPv4 alamat yang tersedia di subnet pribadi Anda sehingga proses pembuatan ENI dapat berhasil. IPv4 Alamatnya bisa pribadi, dan tidak ada biaya tambahan untuk itu. IPv6-hanya subnet tidak didukung.

### Sumber Daya Asal
<a name="origin-resources"></a>

Di subnet pribadi, luncurkan Application Load Balancer, Network Load Balancer, atau instans EC2 untuk digunakan sebagai asal Anda. Sumber daya yang Anda luncurkan harus sepenuhnya digunakan dan dalam status Aktif sebelum Anda dapat menggunakannya untuk asal VPC.

**Pembatasan asal:**
+ Gateway Load Balancers tidak dapat ditambahkan sebagai asal
+ Dual-stack Network Load Balancers tidak dapat ditambahkan sebagai asal
+ Network Load Balancers dengan pendengar TLS tidak dapat ditambahkan sebagai asal
+ Untuk digunakan sebagai asal VPC, Network Load Balancer harus memiliki grup keamanan yang melekat padanya

### Konfigurasi Grup Keamanan
<a name="security-group-configuration"></a>

Sumber daya asal VPC Anda (Application Load Balancer, Network Load Balancer, atau instans EC2) harus memiliki grup keamanan yang terpasang. Saat Anda membuat asal VPC, CloudFront secara otomatis membuat grup keamanan yang dikelola layanan dengan pola penamaan. `CloudFront-VPCOrigins-Service-SG` Grup keamanan ini sepenuhnya dikelola oleh AWS, dan tidak boleh diedit.

Untuk mengizinkan lalu lintas dari CloudFront untuk mencapai asal VPC Anda, perbarui grup keamanan yang dilampirkan ke sumber daya asal Anda (instans ALB, NLB, atau EC2) untuk mengizinkan lalu lintas masuk menggunakan salah satu metode berikut:
+ **Opsi 1:** Izinkan lalu lintas dari daftar awalan CloudFront terkelola. Untuk informasi selengkapnya, lihat [Gunakan daftar awalan CloudFront terkelola](LocationsOfEdgeServers.md#managed-prefix-list). Ini dapat dilakukan sebelum asal VPC dibuat juga.
+ **Opsi 2:** Izinkan lalu lintas dari grup keamanan CloudFront yang dikelola layanan ()`CloudFront-VPCOrigins-Service-SG`. Ini dapat dilakukan hanya setelah asal VPC dibuat dan grup keamanan yang dikelola layanan dibuat. Konfigurasi ini lebih ketat karena membatasi lalu lintas hanya untuk distribusi Anda CloudFront .

**penting**  
Jangan membuat grup keamanan Anda sendiri dengan nama yang dimulai dengan`CloudFront-VPCOrigins-Service-SG`. Ini adalah pola penamaan yang AWS dicadangkan untuk grup keamanan yang dikelola layanan. Untuk informasi selengkapnya, lihat [Membuat grup keamanan](https://docs.aws.amazon.com/vpc/latest/userguide/creating-security-groups.html).

### Pembatasan Protokol dan Fitur
<a name="protocol-feature-restrictions"></a>

Asal VPC tidak mendukung hal berikut:
+ WebSockets
+ lalu lintas gRPC
+ Permintaan asal dan respons asal dipicu dengan Lambda @Edge

## Buat asal VPC (distribusi baru)
<a name="new-vpc-origin"></a>

Prosedur berikut menunjukkan cara membuat asal VPC untuk CloudFront distribusi baru Anda di CloudFront konsol. Atau, Anda dapat menggunakan operasi [CreateVpcOrigin](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateVpcOrigin.html)dan [CreateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateDistribution.html)API dengan AWS CLI atau AWS SDK.

**Untuk membuat asal VPC untuk distribusi baru CloudFront**

1. Buka CloudFront konsol di[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Pilih asal **VPC, Buat asal** **VPC**.

1. Isi bidang yang diperlukan. Untuk **Origin ARN, pilih ARN** Application Load Balancer, Network Load Balancer, atau instans EC2 Anda. Jika Anda tidak melihat ARN, Anda dapat menyalin ARN sumber daya spesifik Anda dan menempelkannya di sini.

1. Pilih **Buat asal VPC**.

1. **Tunggu status asal VPC Anda berubah menjadi Deployed.** Ini bisa memakan waktu hingga 15 menit.

1. Pilih **Distribusi**, **Buat distribusi**.

1. Untuk **domain Origin**, pilih sumber daya asal VPC Anda dari daftar tarik-turun.

   **Jika asal VPC Anda adalah instans EC2, salin dan tempel **nama DNS IP Pribadi** instance ke bidang domain Origin.**

1. Selesai membuat distribusi Anda. Untuk informasi selengkapnya, lihat [Buat CloudFront distribusi di konsol](distribution-web-creating-console.md#create-console-distribution).

## Buat asal VPC (distribusi yang ada)
<a name="existing-vpc-origin"></a>

Prosedur berikut menunjukkan kepada Anda cara membuat asal VPC untuk CloudFront distribusi yang ada di CloudFront konsol, yang membantu memastikan ketersediaan aplikasi Anda secara berkelanjutan. Atau, Anda dapat menggunakan operasi [CreateVpcOrigin](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateVpcOrigin.html)dan [UpdateDistributionWithStagingConfig](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistributionWithStagingConfig.html)API dengan AWS CLI atau AWS SDK.

Secara opsional, Anda dapat memilih untuk menambahkan asal VPC Anda ke distribusi yang ada tanpa membuat distribusi pementasan.

**Untuk membuat asal VPC untuk distribusi yang ada CloudFront**

1. Buka CloudFront konsol di[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Pilih asal **VPC, Buat asal** **VPC**.

1. Isi bidang yang diperlukan. Untuk **Origin ARN, pilih ARN** Application Load Balancer, Network Load Balancer, atau instans EC2 Anda. Jika Anda tidak melihat ARN, Anda dapat menyalin ARN sumber daya spesifik Anda dan menempelkannya di sini.

1. Pilih **Buat asal VPC**.

1. **Tunggu status asal VPC Anda berubah menjadi Deployed.** Ini bisa memakan waktu hingga 15 menit.

1. Di panel navigasi, pilih **Distribusi**.

1. Pilih ID distribusi Anda.

1. Pada tab **Umum**, di bawah **Penerapan berkelanjutan**, pilih **Buat distribusi pementasan**. Untuk informasi selengkapnya, lihat [Gunakan penerapan CloudFront berkelanjutan untuk menguji perubahan konfigurasi CDN dengan aman](continuous-deployment.md).

1. Ikuti langkah-langkah di wizard **Buat distribusi pementasan untuk membuat distribusi** pementasan. Sertakan langkah-langkah berikut:
   + Untuk **Origins**, pilih **Create Origin**.
   + Untuk **domain Origin**, pilih sumber daya asal VPC Anda dari menu tarik-turun.

     **Jika asal VPC Anda adalah instans EC2, salin dan tempel **nama DNS IP Pribadi** instance ke bidang domain Origin.**
   + Pilih **Buat asal**.

1. Dalam distribusi pementasan Anda, uji asal VPC.

1. Promosikan konfigurasi distribusi pementasan ke distribusi utama Anda. Untuk informasi selengkapnya, lihat [Mempromosikan konfigurasi distribusi pementasan](working-with-staging-distribution-continuous-deployment-policy.md#promote-staging-distribution-configuration).

1. Hapus akses publik ke asal VPC Anda dengan membuat subnet pribadi. Setelah Anda melakukan ini, asal VPC tidak akan dapat ditemukan melalui internet, tetapi masih CloudFront akan memiliki akses pribadi ke sana. Untuk informasi selengkapnya, lihat [Mengaitkan atau memisahkan subnet dengan tabel rute di Panduan](https://docs.aws.amazon.com/vpc/latest/userguide/WorkWithRouteTables.html#AssociateSubnet) Pengguna Amazon *VPC*.

## Perbarui asal VPC
<a name="update-vpc-origin"></a>

Prosedur berikut menunjukkan cara memperbarui asal VPC untuk CloudFront distribusi Anda di konsol. CloudFront Atau, Anda dapat menggunakan operasi [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html)dan [UpdateVpcOrigin](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateVpcOrigin.html)API dengan AWS CLI atau AWS SDK.

**Untuk memperbarui asal VPC yang ada untuk distribusi Anda CloudFront**

1. Buka CloudFront konsol di[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Di panel navigasi, pilih **Distribusi**.

1. Pilih ID distribusi Anda.

1. Pilih **Perilaku** tab.

1. Pastikan bahwa asal VPC bukan asal default untuk perilaku cache Anda. 

1. Pilih tab **Origins**.

1. **Pilih asal VPC yang akan Anda perbarui dan pilih Hapus.** Ini memisahkan asal VPC dari distribusi Anda. Ulangi langkah 2-7 untuk memisahkan asal VPC dari distribusi lainnya.

1. Pilih **asal VPC**.

1. **Pilih asal VPC dan pilih Edit.**

1. Buat pembaruan Anda dan pilih **Perbarui asal VPC**.

1. **Tunggu status asal VPC Anda berubah menjadi Deployed.** Ini bisa memakan waktu hingga 15 menit.

1. Di panel navigasi, pilih **Distribusi**.

1. Pilih ID distribusi Anda.

1. Pilih tab **Origins**.

1. Pilih **Buat asal**.

1. Untuk **domain Origin**, pilih sumber daya asal VPC Anda dari menu tarik-turun.

   **Jika asal VPC Anda adalah instans EC2, salin dan tempel **nama DNS IP Pribadi** instance ke bidang domain Origin.**

1. Pilih **Buat asal**. Ini mengaitkan asal VPC dengan distribusi Anda lagi. Ulangi langkah 12-17 untuk mengaitkan asal VPC yang diperbarui dengan distribusi lainnya.

## Didukung Wilayah AWS untuk asal VPC
<a name="vpc-origins-supported-regions"></a>

Asal VPC saat ini didukung dalam iklan berikut. Wilayah AWS Pengecualian Availability Zone (AZ) dicatat.

[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonCloudFront/latest/DeveloperGuide/private-content-vpc-origins.html)

# Batasi akses ke asal Titik Akses Multi-Wilayah Amazon S3
<a name="private-content-restricting-access-to-s3-mrap"></a>

Anda dapat menggunakan kontrol akses asal (OAC) untuk membatasi akses ke asal Titik Akses Multi-Wilayah Amazon S3. Titik Akses Multi-Wilayah S3 menyediakan titik akhir global yang merutekan permintaan ke bucket S3 terdekat berdasarkan latensi jaringan.

Untuk informasi tentang penggunaan OAC dengan asal bucket Amazon S3 standar, lihat. [Batasi akses ke asal Amazon S3](private-content-restricting-access-to-s3.md)

## Prasyarat
<a name="oac-prerequisites-s3-mrap"></a>

Sebelum Anda membuat dan mengatur OAC, Anda harus memiliki CloudFront distribusi dengan asal Amazon S3 Multi-Region Access Point. Nama domain asal harus menggunakan format nama host S3 Multi-Region Access Point:

`multi-region-access-point-alias.accesspoint.s3-global.amazonaws.com`

Untuk informasi selengkapnya tentang membuat Titik Akses Multi-Wilayah S3, lihat [Membuat Titik Akses Multi-Wilayah](https://docs.aws.amazon.com/AmazonS3/latest/userguide/CreatingMultiRegionAccessPoints.html) di Panduan Pengguna *Layanan Penyimpanan Sederhana Amazon*.

## Berikan CloudFront izin untuk mengakses Titik Akses Multi-Wilayah S3
<a name="oac-permission-to-access-s3-mrap"></a>

Perbarui kebijakan Titik Akses Multi-Wilayah untuk memungkinkan prinsipal CloudFront layanan (`cloudfront.amazonaws.com`) mengakses Titik Akses Multi-Wilayah. Gunakan `Condition` elemen dalam kebijakan CloudFront untuk mengizinkan mengakses Titik Akses Multi-Wilayah hanya jika permintaan tersebut atas nama CloudFront distribusi yang berisi asal.

Untuk informasi tentang menambahkan atau memodifikasi kebijakan Titik Akses Multi-Wilayah, lihat [contoh kebijakan Titik Akses Multi-Wilayah](https://docs.aws.amazon.com/AmazonS3/latest/userguide/MultiRegionAccessPointPermissions.html) di Panduan Pengguna *Layanan Penyimpanan Sederhana Amazon*.

**Example Kebijakan Titik Akses Multi-Wilayah untuk CloudFront OAC**  

```
{
    "Version": "2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "AllowCloudFrontOACAccess",
            "Effect": "Allow",
            "Principal": {
                "Service": "cloudfront.amazonaws.com"
            },
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3::111122223333:accesspoint/Multi-Region-Access-Point-Alias.mrap/object/*",
            "Condition": {
                "StringEquals": {
                    "aws:SourceArn": "arn:aws:cloudfront::111122223333:distribution/CloudFront distribution ID"
                }
            }
        }
    ]
}
```

## Berikan CloudFront izin untuk mengakses bucket S3 yang mendasarinya
<a name="oac-permission-to-access-s3-mrap-buckets"></a>

Selain kebijakan Titik Akses Multi-Wilayah, Anda juga harus memberikan CloudFront izin untuk mengakses setiap bucket S3 yang mendasari yang terkait dengan Titik Akses Multi-Wilayah. Anda dapat melakukannya dengan salah satu dari dua cara berikut:

### Opsi 1: Berikan akses hanya ke CloudFront
<a name="oac-s3-mrap-bucket-option1"></a>

Tambahkan kebijakan bucket ke setiap bucket S3 yang memungkinkan kepala CloudFront layanan mengakses bucket. Gunakan opsi ini ketika Anda juga perlu mengizinkan akses langsung ke ember dari sumber lain.

**Example Kebijakan bucket S3 untuk bucket yang mendasarinya**  

```
{
    "Version": "2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "AllowCloudFrontOACAccessViaMRAP",
            "Effect": "Allow",
            "Principal": {
                "Service": "cloudfront.amazonaws.com"
            },
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::amzn-s3-demo-bucket-us-east-1/*",
            "Condition": {
                "StringEquals": {
                    "aws:SourceArn": "arn:aws:cloudfront::111122223333:distribution/CloudFront distribution ID"
                }
            }
        }
    ]
}
```

### Opsi 2: Delegasikan akses bucket penuh ke Titik Akses Multi-Wilayah
<a name="oac-s3-mrap-bucket-option2"></a>

Berikan Akses Point Multi-Wilayah akses penuh ke setiap bucket yang mendasarinya. Dengan pendekatan ini, semua akses ke bucket dikendalikan oleh kebijakan Titik Akses Multi-Wilayah, yang menyederhanakan manajemen akses. Kami merekomendasikan opsi ini untuk kasus penggunaan yang tidak memerlukan akses langsung ke bucket.

**Example Kebijakan bucket S3 yang mendelegasikan akses ke Titik Akses Multi-Wilayah**  

```
{
    "Version": "2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "DelegateAccessToMRAP",
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:*",
            "Resource": [
                "arn:aws:s3:::amzn-s3-demo-bucket-us-east-1",
                "arn:aws:s3:::amzn-s3-demo-bucket-us-east-1/*"
            ],
            "Condition": {
                "StringEquals": {
                    "s3:DataAccessPointArn": "arn:aws:s3::111122223333:accesspoint/Multi-Region-Access-Point-Alias.mrap"
                }
            }
        }
    ]
}
```

Untuk informasi selengkapnya, lihat [contoh kebijakan Titik Akses Multi-Wilayah](https://docs.aws.amazon.com/AmazonS3/latest/userguide/MultiRegionAccessPointPermissions.html#MultiRegionAccessPointPolicyExamples) di *Panduan Pengguna Layanan Penyimpanan Sederhana Amazon*.

**penting**  
Anda harus menambahkan kebijakan bucket ini ke setiap bucket S3 yang terkait dengan Titik Akses Multi-Wilayah. Jika ada bucket yang tidak memiliki kebijakan, CloudFront permintaan yang dialihkan ke bucket tersebut akan ditolak.

### SSE-KMS
<a name="oac-s3-mrap-sse-kms"></a>

Jika objek dalam bucket S3 yang mendasarinya dienkripsi menggunakan enkripsi sisi server dengan AWS KMS (SSE-KMS), Anda harus memastikan bahwa distribusi memiliki izin untuk menggunakan kunci. CloudFront AWS KMS Karena Titik Akses Multi-Wilayah S3 dapat merutekan permintaan ke bucket di beberapa Wilayah, Anda harus menambahkan pernyataan ke kebijakan kunci KMS di setiap Wilayah di mana bucket yang mendasarinya menggunakan SSE-KMS. Untuk informasi tentang cara mengubah kebijakan kunci, lihat [Mengubah kebijakan kunci](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-modifying.html) di *Panduan AWS Key Management Service Pengembang*.

**Example Pernyataan kebijakan kunci KMS**  
Contoh berikut menunjukkan pernyataan kebijakan kunci KMS yang memungkinkan CloudFront distribusi dengan OAC untuk mengakses kunci KMS untuk SSE-KMS.  

```
{
    "Sid": "AllowCloudFrontServicePrincipalSSE-KMS",
    "Effect": "Allow",
    "Principal": {
        "Service": "cloudfront.amazonaws.com"
    },
    "Action": [
        "kms:Decrypt",
        "kms:Encrypt",
        "kms:GenerateDataKey*"
    ],
    "Resource": "*",
    "Condition": {
        "StringEquals": {
            "aws:SourceArn": "arn:aws:cloudfront::111122223333:distribution/CloudFront distribution ID"
        }
    }
}
```

**penting**  
Anda harus menambahkan pernyataan kebijakan kunci ini ke kunci KMS di setiap Wilayah di mana bucket S3 yang mendasarinya menggunakan enkripsi SSE-KMS.

## Buat kontrol akses asal
<a name="create-oac-s3-mrap"></a>

Untuk membuat kontrol akses asal (OAC), Anda dapat menggunakan Konsol Manajemen AWS CloudFormation, AWS CLI, atau CloudFront API.

------
#### [ Console ]

**Untuk membuat kontrol akses asal**

1. Masuk ke Konsol Manajemen AWS dan buka CloudFront konsol di[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Di panel navigasi, pilih **Akses asal**.

1. Pilih **Buat pengaturan kontrol**.

1. Pada formulir **pengaturan Create control**, lakukan hal berikut:

   1. Di panel **Detail**, masukkan **Nama** dan (opsional) **Deskripsi** untuk kontrol akses asal.

   1. Di panel **Pengaturan**, kami sarankan Anda meninggalkan pengaturan default (**Permintaan tanda tangan (disarankan))**. Untuk informasi selengkapnya, lihat [Pengaturan lanjutan untuk kontrol akses asal](private-content-restricting-access-to-s3.md#oac-advanced-settings-s3).

1. Pilih **S3 Multi-Region Access Point dari dropdown** **tipe Origin**.

1. Pilih **Buat**.

   Setelah OAC dibuat, catat **Nama**. Anda membutuhkan ini dalam prosedur berikut.

**Untuk menambahkan kontrol akses asal ke asal Titik Akses Multi-Wilayah S3 dalam distribusi**

1. Buka CloudFront konsol di[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. **Pilih distribusi dengan asal Titik Akses Multi-Wilayah S3 yang ingin Anda tambahkan OAC, lalu pilih tab Origins.**

1. **Pilih asal S3 Multi-Region Access Point yang ingin Anda tambahkan OAC, lalu pilih Edit.**

1. Untuk **akses Origin**, pilih **Pengaturan kontrol akses Origin (disarankan)**.

1. Dari menu tarik-turun **kontrol akses Origin**, pilih OAC yang ingin Anda gunakan.

1. Pilih **Simpan perubahan**.

Distribusi mulai menyebar ke semua lokasi CloudFront tepi. Ketika lokasi tepi menerima konfigurasi baru, ia menandatangani semua permintaan yang dikirim ke asal Titik Akses Multi-Wilayah S3.

------
#### [ CLI ]

Gunakan **create-origin-access-control** perintah:

```
aws cloudfront create-origin-access-control \
    --origin-access-control-config '{
        "Name": "my-s3-mrap-oac",
        "Description": "OAC for S3 Multi-Region Access Point",
        "SigningProtocol": "sigv4a",
        "SigningBehavior": "always",
        "OriginAccessControlOriginType": "s3mrap"
    }'
```

------
#### [ CloudFormation ]

Tentukan nilai berikut di`OriginAccessControlConfig`:
+ `SigningProtocol`: `sigv4a`
+ `SigningBehavior`:`always`,`never`, atau `no-override`
+ `OriginAccessControlOriginType`: `s3mrap`

**Example CloudFormation Template**  

```
Type: AWS::CloudFront::OriginAccessControl
Properties:
  OriginAccessControlConfig:
    Description: An optional description for the origin access control
    Name: my-s3-mrap-oac
    OriginAccessControlOriginType: s3mrap
    SigningBehavior: always
    SigningProtocol: sigv4a
```

------

## Perilaku penandatanganan
<a name="oac-signing-behavior-s3-mrap"></a>

Opsi perilaku penandatanganan untuk asal Titik Akses Multi-Wilayah S3 sama dengan opsi untuk asal bucket Amazon S3 biasa. Untuk informasi selengkapnya, lihat [Pengaturan lanjutan untuk kontrol akses asal](private-content-restricting-access-to-s3.md#oac-advanced-settings-s3) di *Membatasi akses ke asal Amazon S3*.

# Batasi akses ke Application Load Balancers
<a name="restrict-access-to-load-balancer"></a>

Anda dapat menggunakan Application Load Balancer internal dan internet dengan Amazon. CloudFront Anda dapat menggunakan Application Load Balancer internal di dalam subnet pribadi dengan CloudFront menggunakan asal VPC. CloudFront Asal VPC memungkinkan Anda untuk menyajikan konten dari aplikasi yang dihosting di subnet VPC pribadi tanpa memaparkannya ke internet publik. Untuk informasi selengkapnya, lihat [Batasi akses dengan asal VPC](private-content-vpc-origins.md).

Jika Anda menggunakan Application Load Balancer CloudFront yang menghadap ke internet, Anda dapat menggunakan mitigasi keamanan berikut untuk mencegah pengguna mengakses Application Load Balancer secara langsung, dan mengizinkan akses hanya melalui. CloudFront

1. Konfigurasikan CloudFront untuk menambahkan header HTTP kustom ke permintaan yang dikirim ke Application Load Balancer.

1. Mengonfigurasi Application Load Balancer untuk hanya meneruskan permintaan yang berisi header HTTP kustom.

1. Memerlukan HTTPS untuk meningkatkan keamanan solusi ini.

CloudFront juga dapat membantu mengurangi latensi dan bahkan menyerap beberapa serangan penolakan layanan (DDoS) terdistribusi.

Jika kasus penggunaan Anda memerlukan akses ganda ke aplikasi web dari keduanya CloudFront dan Application Load Balancer langsung melalui internet, pertimbangkan untuk memisahkan aplikasi APIs web Anda sebagai berikut:
+ APIs yang harus dilalui CloudFront. Dalam hal ini, pertimbangkan untuk menggunakan Application Load Balancer pribadi terpisah sebagai asal.
+ APIs yang membutuhkan akses melalui Application Load Balancer. Dalam hal ini, Anda melewati CloudFront.

Atau, untuk aplikasi web atau konten lain yang disajikan oleh Application Load Balancer yang menghadap ke internet di Elastic Load Balancing CloudFront , dapat menyimpan objek dan menyajikannya langsung ke pengguna (pemirsa), mengurangi beban pada Application Load Balancer Anda. Penyeimbang beban yang menghadap ke internet memiliki nama DNS yang dapat diselesaikan secara publik dan mengarahkan permintaan dari klien ke target melalui internet.

Untuk informasi selengkapnya, lihat topik berikut. Setelah Anda menyelesaikan langkah-langkah ini, pengguna hanya dapat mengakses Application Load Balancer Anda melalui. CloudFront

**Topics**
+ [Konfigurasikan CloudFront untuk menambahkan header HTTP kustom ke permintaan](#restrict-alb-add-custom-header)
+ [Konfigurasikan Application Load Balancer untuk hanya meneruskan permintaan yang berisi header tertentu](#restrict-alb-route-based-on-header)
+ [(Opsional) tingkatkan keamanan solusi ini.](#restrict-alb-improve-security)
+ [(Opsional) Batasi akses ke asal dengan menggunakan daftar awalan AWS-managed untuk CloudFront](#limit-access-to-origin-using-aws-managed-prefixes)

## Konfigurasikan CloudFront untuk menambahkan header HTTP kustom ke permintaan
<a name="restrict-alb-add-custom-header"></a>

Anda dapat mengonfigurasi CloudFront untuk menambahkan header HTTP kustom ke permintaan yang dikirim ke asal Anda (dalam hal ini, Application Load Balancer).

**penting**  
Kasus penggunaan ini bergantung pada menjaga nama header kustom dan rahasia nilai. Jika nama header dan nilai tidak rahasia, klien HTTP lain berpotensi memasukkannya dalam permintaan yang mereka kirim langsung ke Application Load Balancer. Hal ini dapat menyebabkan Application Load Balancer berperilaku seolah-olah permintaan berasal dari CloudFront saat tidak. Untuk mencegah hal ini, rahasiakan nama header kustom dan nilai.

Anda dapat mengonfigurasi CloudFront untuk menambahkan header HTTP kustom ke permintaan asal dengan CloudFront konsol CloudFormation, atau CloudFront API.

**Untuk menambahkan header HTTP kustom (CloudFront konsol)**  
Di CloudFront konsol, gunakan pengaturan **Header Kustom Asal** di **Pengaturan Asal**. Masukkan **Nama Header** dan **Nilainya**.  
Dalam produksi, gunakan nama dan nilai header yang dihasilkan secara acak. Perlakukan nama dan nilai header sebagai kredensyal aman, seperti nama pengguna dan kata sandi.
Anda dapat mengedit setelan **Header Kustom Asal** saat membuat atau mengedit asal untuk CloudFront distribusi yang ada, dan saat Anda membuat distribusi baru. Untuk informasi selengkapnya, lihat [Perbarui distribusi](HowToUpdateDistribution.md) dan [Buat distribusi](distribution-web-creating-console.md).

**Untuk menambah header HTTP kustom (CloudFormation)**  
Dalam CloudFormation template, gunakan `OriginCustomHeaders` properti, seperti yang ditunjukkan pada contoh berikut.  
Nama header dan nilai dalam contoh ini hanya untuk demonstrasi. Dalam produksi, gunakan nilai yang dihasilkan secara acak. Perlakukan nama header dan nilai sebagai kredensial aman, seperti nama pengguna dan kata sandi.

```
AWSTemplateFormatVersion: '2010-09-09'
Resources:
  TestDistribution:
    Type: 'AWS::CloudFront::Distribution'
    Properties:
      DistributionConfig:
        Origins:
          - DomainName: app-load-balancer.example.com
            Id: Example-ALB
            CustomOriginConfig:
              OriginProtocolPolicy: https-only
              OriginSSLProtocols:
                - TLSv1.2
            OriginCustomHeaders:
               - HeaderName: X-Custom-Header
                 HeaderValue: random-value-1234567890
        Enabled: 'true'
        DefaultCacheBehavior:
          TargetOriginId: Example-ALB
          ViewerProtocolPolicy: allow-all
          CachePolicyId: 658327ea-f89d-4fab-a63d-7e88639e58f6
        PriceClass: PriceClass_All
        ViewerCertificate:
          CloudFrontDefaultCertificate: 'true'
```
Untuk informasi selengkapnya, lihat [Asal](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-cloudfront-distribution-origin.html) dan [OriginCustomHeader](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-cloudfront-distribution-origincustomheader.html)properti di *Panduan AWS CloudFormation Pengguna*.

**Untuk menambahkan header HTTP kustom (CloudFront API)**  
Di CloudFront API, gunakan `CustomHeaders` objek di dalamnya`Origin`. Untuk informasi selengkapnya, lihat [CreateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateDistribution.html)dan [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html)di *Referensi Amazon CloudFront API*, dan dokumentasi untuk SDK Anda atau klien API lainnya.

Ada beberapa nama header yang Anda tidak dapat tentukan sebagai header kustom asal. Untuk informasi selengkapnya, lihat [Header khusus yang tidak CloudFront dapat ditambahkan ke permintaan asal](add-origin-custom-headers.md#add-origin-custom-headers-denylist).

## Konfigurasikan Application Load Balancer untuk hanya meneruskan permintaan yang berisi header tertentu
<a name="restrict-alb-route-based-on-header"></a>

Setelah Anda mengonfigurasi CloudFront untuk menambahkan header HTTP kustom ke permintaan yang dikirimkan ke Application Load Balancer Anda (lihat [bagian sebelumnya](#restrict-alb-add-custom-header)), Anda dapat mengonfigurasi penyeimbang beban untuk hanya meneruskan permintaan yang berisi header kustom ini. Anda melakukan ini dengan menambah aturan baru dan memodifikasi aturan default dalam listener penyeimbang beban Anda.

**Prasyarat**  
Untuk menggunakan prosedur berikut, Anda memerlukan Application Load Balancer dengan setidaknya satu listener. Jika Anda belum membuatnya, lihat [Membuat Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-application-load-balancer.html) di *Panduan Pengguna untuk Application Load Balancers*.

Prosedur berikut ini memodifikasi listener HTTPS. Anda dapat menggunakan proses yang sama untuk memodifikasi listener HTTP.

**Untuk memperbarui aturan dalam listener Application Load Balancer**

1. Tambahkan aturan baru. Gunakan instruksi dari [Tambahkan aturan](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/listener-update-rules.html#add-rule), dengan modifikasi berikut:
   + Tambahkan aturan ke penyeimbang beban yang merupakan asal CloudFront distribusi Anda.
   + Untuk **kondisi Tambah**, pilih **header Http**. Tentukan nama header HTTP dan nilai yang Anda tambahkan sebagai header kustom asal CloudFront.
   + Untuk **menambahkan tindakan**, pilih **Teruskan ke**. Pilih grup target tempat Anda ingin meneruskan permintaan.

1. Edit aturan default di pendengar penyeimbang beban Anda. Gunakan instruksi dari [Edit aturan](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/listener-update-rules.html#edit-rule), dengan modifikasi berikut:
   + Edit aturan default penyeimbang beban yang merupakan asal CloudFront distribusi Anda.
   + Hapus tindakan default, lalu untuk **Add action**, pilih **Return fixed response**. 
   + Untuk **Kode respons**, masukkan **403**.
   + Untuk **Isi respons**, masukkan **Access denied**.

Setelah Anda menyelesaikan langkah-langkah ini, pendengar penyeimbang beban Anda memiliki dua aturan. Satu aturan meneruskan permintaan yang berisi header HTTP (permintaan yang berasal dari CloudFront). Aturan lain mengirimkan respons tetap ke semua permintaan lainnya (permintaan yang tidak berasal CloudFront).

Anda dapat memverifikasi bahwa solusi berfungsi dengan mengirimkan permintaan ke CloudFront distribusi Anda dan satu ke Application Load Balancer Anda. Permintaan untuk CloudFront mengembalikan aplikasi web atau konten Anda, dan yang dikirim langsung ke Application Load Balancer Anda mengembalikan `403` respons dengan pesan teks biasa. `Access denied`

## (Opsional) tingkatkan keamanan solusi ini.
<a name="restrict-alb-improve-security"></a>

Untuk meningkatkan keamanan solusi ini, Anda dapat mengonfigurasi CloudFront distribusi Anda agar selalu menggunakan HTTPS saat mengirim permintaan ke Application Load Balancer Anda. Ingat, solusi ini hanya berfungsi jika Anda menyimpan nama header kustom dan rahasia nilai. Menggunakan HTTPS dapat membantu mencegah penyadap menemukan nama dan nilai header. Kami juga merekomendasikan merotasi nama header dan nilai secara berkala.

**Menggunakan HTTPS untuk permintaan asal**  
 CloudFront Untuk mengonfigurasi penggunaan HTTPS untuk permintaan asal, setel pengaturan **Kebijakan Protokol Asal** ke **HTTPS Saja**. Pengaturan ini tersedia di CloudFront konsol, CloudFormation, dan CloudFront API. Untuk informasi selengkapnya, lihat [Protokol (hanya asal kustom)](DownloadDistValuesOrigin.md#DownloadDistValuesOriginProtocolPolicy).

Berikut ini juga berlaku saat Anda mengonfigurasi CloudFront untuk menggunakan HTTPS untuk permintaan asal:
+ Anda harus mengonfigurasi CloudFront untuk meneruskan `Host` header ke asal dengan kebijakan permintaan asal. Anda dapat menggunakan [kebijakan permintaan asal AllViewer terkelola](using-managed-origin-request-policies.md#managed-origin-request-policy-all-viewer).
+ Pastikan Application Load Balancer Anda memiliki listener HTTPS (seperti yang ditunjukkan pada [bagian sebelumnya](#restrict-alb-route-based-on-header)). Untuk informasi lebih lanjut, lihat [Buat listener HTTPS](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-https-listener.html) di *Panduan pengguna untuk Application Load Balancers*. Menggunakan pendengar HTTPS mengharuskan Anda memiliki SSL/TLS sertifikat yang cocok dengan nama domain yang dirutekan ke Application Load Balancer Anda.
+ Sertifikat SSL/TLS untuk hanya CloudFront dapat diminta (atau diimpor) di in (ACM). `us-east-1` Wilayah AWS AWS Certificate Manager Karena CloudFront merupakan layanan global, secara otomatis mendistribusikan sertifikat dari `us-east-1` Wilayah ke semua Wilayah yang terkait dengan CloudFront distribusi Anda.
  + Misalnya, jika Anda memiliki Application Load Balancer (ALB) di `ap-southeast-2` Wilayah, Anda harus mengonfigurasi SSL/TLS sertifikat di `ap-southeast-2` Wilayah (untuk menggunakan HTTPS antara CloudFront dan asal ALB) dan `us-east-1` Wilayah (untuk menggunakan HTTPS antara pemirsa dan). CloudFront Kedua sertifikat harus sesuai dengan nama domain yang dirutekan ke Application Load Balancer Anda. Untuk informasi selengkapnya, lihat [Wilayah AWS untuk AWS Certificate Manager](cnames-and-https-requirements.md#https-requirements-aws-region).
+ Jika pengguna akhir (juga dikenal sebagai *pemirsa*, atau *klien*) aplikasi web Anda dapat menggunakan HTTPS, Anda juga dapat mengonfigurasi CloudFront untuk memilih (atau bahkan memerlukan) koneksi HTTPS dari pengguna akhir. Untuk melakukannya, gunakan pengaturan **Kebijakan Protokol Penampil**. Anda dapat mengaturnya untuk mengarahkan pengguna akhir dari HTTP ke HTTPS, atau untuk menolak permintaan yang menggunakan HTTP. Pengaturan ini tersedia di CloudFront konsol, CloudFormation, dan CloudFront API. Untuk informasi selengkapnya, lihat [Kebijakan protokol penampil](DownloadDistValuesCacheBehavior.md#DownloadDistValuesViewerProtocolPolicy).

**Memutar nama header dan nilai**  
Selain menggunakan HTTPS, kami juga merekomendasikan merotasi nama header dan nilai secara berkala. Langkah-langkah tingkat tinggi untuk melakukan ini adalah sebagai berikut:

1. Konfigurasikan CloudFront untuk menambahkan header HTTP kustom tambahan ke permintaan yang dikirim ke Application Load Balancer.

1. Perbarui aturan listener Application Load Balancer untuk meneruskan permintaan yang berisi header HTTP kustom tambahan ini.

1. Konfigurasikan CloudFront untuk berhenti menambahkan header HTTP kustom asli ke permintaan yang dikirim ke Application Load Balancer.

1. Perbarui aturan listener Application Load Balancer untuk menghentikan penerusan permintaan yang berisi header HTTP kustom tambahan ini.

Untuk informasi lebih lanjut tentang pencapaian langkah-langkah ini, lihat bagian sebelumnya.

## (Opsional) Batasi akses ke asal dengan menggunakan daftar awalan AWS-managed untuk CloudFront
<a name="limit-access-to-origin-using-aws-managed-prefixes"></a>

Untuk lebih membatasi akses ke Application Load Balancer, Anda dapat mengonfigurasi grup keamanan yang terkait dengan Application Load Balancer sehingga hanya menerima CloudFront lalu lintas dari saat layanan AWS menggunakan daftar awalan -managed. Ini mencegah lalu lintas yang tidak berasal CloudFront dari mencapai Application Load Balancer Anda di lapisan jaringan (layer 3) atau lapisan transport (layer 4).

Untuk informasi selengkapnya, lihat [Batasi akses ke asal Anda menggunakan daftar awalan AWS-managed untuk CloudFront posting blog Amazon](https://aws.amazon.com//blogs/networking-and-content-delivery/limit-access-to-your-origins-using-the-aws-managed-prefix-list-for-amazon-cloudfront/).

# Batasi distribusi geografis konten Anda
<a name="georestrictions"></a>

Anda dapat menggunakan *pembatasan geografis*, kadang-kadang dikenal sebagai *pemblokiran geografis*, untuk mencegah pengguna di lokasi geografis tertentu mengakses konten yang Anda distribusikan melalui distribusi Amazon. CloudFront Untuk menggunakan batasan geografis, Anda memiliki dua opsi:
+ Gunakan fitur pembatasan CloudFront geografis. Gunakan opsi ini untuk membatasi akses ke semua file yang terkait dengan distribusi dan untuk membatasi akses di tingkat negara.
+ Gunakan layanan geolokasi pihak ketiga. Gunakan opsi ini untuk membatasi akses ke subset file yang terkait dengan distribusi atau untuk membatasi akses pada granularitas yang lebih baik dari tingkat negara.

**Topics**
+ [Gunakan CloudFront batasan geografis](#georestrictions-cloudfront)
+ [Gunakan layanan geolokasi pihak ketiga](#georestrictions-geolocation-service)

## Gunakan CloudFront batasan geografis
<a name="georestrictions-cloudfront"></a>

Ketika pengguna meminta konten Anda, CloudFront biasanya menyajikan konten yang diminta di mana pun pengguna berada. Jika Anda perlu mencegah pengguna di negara tertentu mengakses konten Anda, Anda dapat menggunakan fitur pembatasan CloudFront geografis untuk melakukan salah satu hal berikut:
+ Berikan izin kepada pengguna Anda untuk mengakses konten Anda hanya jika mereka berada di salah satu negara yang disetujui di daftar izin Anda.
+ Cegah pengguna Anda mengakses konten Anda jika mereka berada di salah satu negara terlarang di denylist Anda.

Misalnya, jika permintaan berasal dari negara di mana Anda tidak berwenang untuk mendistribusikan konten Anda, Anda dapat menggunakan batasan CloudFront geografis untuk memblokir permintaan tersebut.

**catatan**  
CloudFront menentukan lokasi pengguna Anda dengan menggunakan database pihak ketiga. Keakuratan pemetaan antara alamat IP dan negara berbeda-beda berdasarkan Wilayah. Berdasarkan pengujian terbaru, keseluruhan keakuratannya adalah 99,8%. Jika tidak CloudFront dapat menentukan lokasi pengguna, CloudFront menyajikan konten yang diminta pengguna.

Inilah cara kerja pembatasan geografis:

1. Misalkan Anda memiliki hak untuk mendistribusikan konten Anda hanya di Liechtenstein. Anda memperbarui CloudFront distribusi Anda untuk menambahkan daftar izin yang hanya berisi Liechtenstein. (Atau, Anda dapat menambahkan denlist yang berisi setiap negara kecuali Liechtenstein.)

1. Seorang pengguna di Monako meminta konten Anda, dan DNS merutekan permintaan ke lokasi CloudFront tepi di Milan, Italia.

1. Lokasi edge di Milan mencari distribusi Anda dan menentukan bahwa pengguna di Monako tidak memiliki izin untuk mengunduh konten Anda.

1. CloudFront mengembalikan kode status HTTP `403 (Forbidden)` ke pengguna.

Anda dapat mengonfigurasi secara opsional CloudFront untuk mengembalikan pesan kesalahan khusus kepada pengguna, dan Anda dapat menentukan berapa lama Anda CloudFront ingin menyimpan respons kesalahan untuk file yang diminta. Nilai default adalah 10 detik. Untuk informasi selengkapnya, lihat [Buat halaman kesalahan khusus untuk kode status HTTP tertentu](creating-custom-error-pages.md).

Pembatasan geografis berlaku untuk seluruh distribusi. Jika Anda perlu menerapkan satu batasan pada bagian konten Anda dan pembatasan yang berbeda (atau tidak ada batasan) ke bagian lain dari konten Anda, Anda harus membuat CloudFront distribusi terpisah atau [menggunakan](#georestrictions-geolocation-service) layanan geolokasi pihak ketiga.

Jika Anda mengaktifkan [log CloudFront standar](AccessLogs.md) (log akses), Anda dapat mengidentifikasi permintaan yang CloudFront ditolak dengan mencari entri log di mana nilai `sc-status` (kode status HTTP) berada`403`. Namun, hanya dengan menggunakan log standar, Anda tidak dapat membedakan permintaan yang CloudFront ditolak berdasarkan lokasi pengguna dari permintaan yang CloudFront ditolak karena pengguna tidak memiliki izin untuk mengakses file karena alasan lain. Jika Anda memiliki layanan geolokasi pihak ketiga seperti Elemen Digital atau MaxMind, Anda dapat mengidentifikasi lokasi permintaan berdasarkan alamat IP di kolom `c-ip` (IP klien) di log akses. Untuk informasi selengkapnya tentang log CloudFront standar, lihat[Akses log (log standar)](AccessLogs.md).

Prosedur berikut menjelaskan cara menggunakan CloudFront konsol untuk menambahkan batasan geografis ke distribusi yang ada. Untuk informasi tentang cara menggunakan konsol untuk membuat distribusi, lihat [Buat distribusi](distribution-web-creating-console.md).<a name="restrictions-geo-procedure"></a>

**Untuk menambahkan batasan geografis ke distribusi CloudFront web Anda (konsol)**

1. Masuk ke Konsol Manajemen AWS dan buka CloudFront konsol di[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Di panel navigasi, pilih **Distribusi**, lalu pilih distribusi yang ingin Anda perbarui.

1. Pilih tab **Keamanan**, lalu pilih **Pembatasan geografis**.

1. Pilih **Edit**.

1. Pilih **Izinkan daftar** untuk membuat daftar negara yang diizinkan, atau **Blokir daftar** untuk membuat daftar negara yang diblokir.

1. Tambahkan negara yang diinginkan ke daftar, lalu pilih **Simpan perubahan**.

## Gunakan layanan geolokasi pihak ketiga
<a name="georestrictions-geolocation-service"></a>

Dengan fitur pembatasan CloudFront geografis, Anda mengontrol distribusi konten Anda di tingkat negara untuk semua file yang Anda distribusikan dengan distribusi web tertentu. Jika Anda memiliki kasus penggunaan untuk pembatasan geografis di mana pembatasan tidak mengikuti batas negara, atau jika Anda ingin membatasi akses hanya ke beberapa file yang Anda layani oleh distribusi tertentu, Anda dapat menggabungkan CloudFront dengan layanan geolokasi pihak ketiga. Ini memberi Anda kontrol atas konten Anda tidak hanya berdasarkan negara tetapi juga berdasarkan kota, ZIP, atau kode pos, atau bahkan garis lintang dan bujur.

Saat Anda menggunakan layanan geolokasi pihak ketiga, kami sarankan Anda menggunakan CloudFront tanda tanganURLs, yang dengannya Anda dapat menentukan tanggal dan waktu kedaluwarsa setelah URL tidak lagi valid. Selain itu, kami menyarankan Anda menggunakan bucket Amazon S3 sebagai asal Anda karena Anda kemudian dapat menggunakan [kontrol akses CloudFront asal](private-content-restricting-access-to-s3.md) untuk mencegah pengguna mengakses konten Anda langsung dari asal. Untuk informasi selengkapnya tentang kontrol akses yang ditandatangani URLs dan asal, lihat[Sajikan konten pribadi dengan cookie yang ditandatangani URLs dan ditandatangani](PrivateContent.md).

Langkah-langkah berikut menjelaskan cara mengontrol akses ke file Anda dengan menggunakan layanan geolokasi pihak ketiga.

**Untuk menggunakan layanan geolokasi pihak ketiga untuk membatasi akses ke file dalam distribusi CloudFront**

1. Dapatkan akun dengan layanan geolokasi.

1. Unggah konten Anda ke keranjang Amazon S3.

1. Konfigurasikan Amazon CloudFront dan Amazon S3 untuk menyajikan konten pribadi. Untuk informasi selengkapnya, lihat [Sajikan konten pribadi dengan cookie yang ditandatangani URLs dan ditandatangani](PrivateContent.md).

1. Tulis aplikasi web Anda untuk melakukan hal berikut:
   + Kirim alamat IP untuk setiap permintaan pengguna ke layanan geolokasi.
   + Evaluasi nilai pengembalian dari layanan geolokasi untuk menentukan apakah pengguna berada di lokasi tempat Anda CloudFront ingin mendistribusikan konten Anda.
   + Jika Anda ingin mendistribusikan konten ke lokasi pengguna, buat URL yang ditandatangani untuk CloudFront konten Anda. Jika Anda tidak ingin mendistribusikan konten ke lokasi tersebut, kembalikan kode status HTTP `403 (Forbidden)` ke pengguna. Atau, Anda dapat mengonfigurasi CloudFront untuk mengembalikan pesan kesalahan khusus. Untuk informasi selengkapnya, lihat [Buat halaman kesalahan khusus untuk kode status HTTP tertentu](creating-custom-error-pages.md).

   Untuk informasi selengkapnya, lihat dokumentasi untuk layanan geolokasi yang Anda gunakan.

Anda dapat menggunakan variabel server web untuk mendapatkan alamat IP pengguna yang mengunjungi situs web Anda. Perhatikan peringatan berikut ini:
+ Jika server web Anda tidak terhubung ke internet melalui neraca beban, Anda dapat menggunakan variabel server web untuk mendapatkan alamat IP jarak jauh. Namun, alamat IP ini tidak selalu alamat IP pengguna. Ini juga dapat berupa alamat IP dari server proksi, bergantung pada bagaimana pengguna terhubung ke internet.
+ Jika server web Anda terhubung ke internet melalui neraca beban, variabel server web mungkin berisi alamat IP dari neraca beban, bukan alamat IP pengguna. Dalam konfigurasi ini, kami menyarankan Anda menggunakan alamat IP terakhir dalam `X-Forwarded-For` Header HTTP. Header ini biasanya berisi lebih dari satu alamat IP, sebagian besar untuk proksik atau timbangan beban. Alamat IP terakhir dalam daftar adalah yang paling mungkin dikaitkan dengan lokasi geografis pengguna.

Jika server web Anda tidak terhubung ke neraca beban, sebaiknya gunakan variabel server web, bukan `X-Forwarded-For` untuk menghindari spoofing alamat IP.

# Gunakan enkripsi tingkat lapangan untuk membantu melindungi data sensitif
<a name="field-level-encryption"></a>

Dengan Amazon CloudFront, Anda dapat menerapkan end-to-end koneksi aman ke server asal dengan menggunakan HTTPS. Enkripsi tingkat lapangan menambahkan lapisan keamanan tambahan yang memungkinkan Anda melindungi data tertentu selama pemrosesan sistem sehingga hanya aplikasi tertentu yang dapat melihatnya.

Enkripsi tingkat lapangan memungkinkan pengguna Anda untuk mengunggah informasi sensitif secara aman ke server web Anda. Informasi sensitif yang diberikan oleh pengguna Anda dienkripsi di edge, dekat dengan pengguna, dan tetap dienkripsi di seluruh tumpukan aplikasi Anda. Enkripsi ini memastikan bahwa hanya aplikasi yang memerlukan data—dan memiliki kredensial untuk mendekripsinya—dapat melakukannya.

Untuk menggunakan enkripsi tingkat bidang, saat Anda mengonfigurasi CloudFront distribusi, tentukan kumpulan bidang dalam permintaan POST yang ingin dienkripsi, dan kunci publik yang akan digunakan untuk mengenkripsi mereka. Anda dapat mengenkripsi hingga 10 kolom data dalam permintaan. (Anda tidak dapat mengenkripsi semua data dalam permintaan dengan enkripsi tingkat lapangan; Anda harus menentukan bidang individu untuk mengenkripsi.)

Ketika permintaan HTTPS dengan enkripsi tingkat lapangan diteruskan ke asal, dan permintaan diarahkan ke seluruh aplikasi atau subsistem asal Anda, data sensitif masih dienkripsi, sehingga mengurangi risiko pelanggaran data atau kehilangan data data sensitif yang tidak disengaja. Komponen yang membutuhkan akses ke data sensitif untuk alasan bisnis, seperti sistem pemrosesan pembayaran yang memerlukan akses ke nomor kredit, dapat menggunakan kunci pribadi yang sesuai untuk mendekripsi dan mengakses data.

**catatan**  
Untuk menggunakan enkripsi tingkat-lapangan, asal Anda harus mendukung pengkodean yang disusun ( chunked encoding).

![\[Enkripsi tingkat lapangan di CloudFront\]](http://docs.aws.amazon.com/id_id/AmazonCloudFront/latest/DeveloperGuide/images/fleoverview.png)


CloudFront enkripsi tingkat lapangan menggunakan enkripsi asimetris, juga dikenal sebagai enkripsi kunci publik. Anda memberikan kunci publik CloudFront, dan semua data sensitif yang Anda tentukan dienkripsi secara otomatis. Kunci yang Anda berikan CloudFront tidak dapat digunakan untuk mendekripsi nilai terenkripsi; hanya kunci pribadi Anda yang dapat melakukannya.

![\[Enkripsikan data sensitif saja\]](http://docs.aws.amazon.com/id_id/AmazonCloudFront/latest/DeveloperGuide/images/encryptedfields.png)


**Topics**
+ [Ikhtisar enkripsi tingkat lapangan](#field-level-encryption-overview)
+ [Siapkan enkripsi tingkat lapangan](#field-level-encryption-setting-up)
+ [Dekripsi bidang data di tempat asal Anda](#field-level-encryption-decrypt)

## Ikhtisar enkripsi tingkat lapangan
<a name="field-level-encryption-overview"></a>

Langkah-langkah berikut memberikan ikhtisar pengaturan enkripsi tingkat lapangan. Untuk langkah spesifik, lihat [Siapkan enkripsi tingkat lapangan](#field-level-encryption-setting-up).

1. **Dapatkan public key-private key pair.** Anda harus mendapatkan dan menambahkan kunci publik sebelum memulai pengaturan enkripsi tingkat lapangan di CloudFront.

1. **Buat profil enkripsi tingkat lapangan.** Profil enkripsi tingkat lapangan, yang Anda buat CloudFront, menentukan bidang yang ingin dienkripsi.

1. **Buat konfigurasi enkripsi tingkat lapangan.** Konfigurasi menentukan profil yang akan digunakan, berdasarkan jenis permintaan atau argumen kueri, untuk mengenkripsi kolom data spesifik. Anda juga dapat memilih opsi perilaku permintaan-penerusan yang Anda inginkan untuk skenario yang berbeda. Misalnya, Anda dapat mengatur perilaku saat nama profil yang ditentukan oleh argumen kueri di URL permintaan tidak ada CloudFront.

1. **Tautan ke perilaku cache.** Menautkan konfigurasi ke perilaku cache untuk distribusi, untuk menentukan kapan CloudFront harus mengenkripsi data.

## Siapkan enkripsi tingkat lapangan
<a name="field-level-encryption-setting-up"></a>

Ikuti langkah-langkah ini untuk mulai menggunakan enkripsi tingkat lapangan. Untuk mempelajari tentang kuota (sebelumnya dikenal sebagai batas) pada enkripsi tingkat lapangan, lihat [Kuota](cloudfront-limits.md).
+ [Langkah 1: Buat key pair RSA](#field-level-encryption-setting-up-step1)
+ [Langkah 2: Tambahkan kunci publik Anda CloudFront](#field-level-encryption-setting-up-step2)
+ [Langkah 3: Buat profil untuk enkripsi tingkat lapangan](#field-level-encryption-setting-up-step3)
+ [Langkah 4: Buat konfigurasi](#field-level-encryption-setting-up-step4)
+ [Langkah 5: Tambahkan konfigurasi ke perilaku cache](#field-level-encryption-setting-up-step5)

### Langkah 1: Buat key pair RSA
<a name="field-level-encryption-setting-up-step1"></a>

Untuk memulai, Anda harus membuat pasangan kunci RSA yang mencakup kunci publik dan kunci pribadi. Kunci publik memungkinkan CloudFront untuk mengenkripsi data, dan kunci pribadi memungkinkan komponen di asal Anda untuk mendekripsi bidang yang telah dienkripsi. Anda dapat menggunakan OpenSSL atau alat lain untuk membuat pasangan kunci. Ukuran kunci harus 2048 bit.

Misalnya, jika Anda menggunakan OpenSSL, Anda dapat menggunakan perintah berikut untuk membuat pasangan kunci dengan panjang 2048 bit dan menyimpannya dalam file `private_key.pem`:

```
openssl genrsa -out private_key.pem 2048
```

Berkas yang dihasilkan berisi baik publik maupun kunci pribadi. Untuk mengekstrak kunci publik dari file tersebut, jalankan perintah berikut:

```
openssl rsa -pubout -in private_key.pem -out public_key.pem
```

File kunci publik (`public_key.pem`) berisi nilai kunci terkode yang Anda tempelkan pada langkah berikut.

### Langkah 2: Tambahkan kunci publik Anda CloudFront
<a name="field-level-encryption-setting-up-step2"></a>

Setelah Anda mendapatkan key pair RSA Anda, tambahkan kunci publik Anda ke CloudFront.<a name="field-level-encryption-setting-up-step2-procedure"></a>

**Untuk menambahkan kunci publik Anda ke CloudFront (konsol)**

1. Masuk ke Konsol Manajemen AWS dan buka CloudFront konsol di[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Di panel navigasi, pilih **Kunci publik**.

1. Pilih **Tambahkan kunci publik**.

1. Untuk **Nama kunci**, ketikkan nama unik untuk kunci. Nama tidak boleh memiliki spasi dan hanya dapat menyertakan karakter alfanumerik, garis bawah (\$1), dan tanda hubung (-). Jumlah karakter maksimum adalah 128.

1. Untuk **Nilai utama**, tempelkan nilai utama yang disandikan untuk kunci publik Anda, termasuk `-----BEGIN PUBLIC KEY-----` dan `-----END PUBLIC KEY-----` yang tepat.

1. Untuk **Komentar**, tambahkan komentar opsional. Misalnya, Anda dapat menyertakan tanggal kedaluwarsa kunci publik.

1. Pilih **Tambahkan**.

Anda dapat menambahkan lebih banyak kunci untuk digunakan CloudFront dengan mengulangi langkah-langkah dalam prosedur.

### Langkah 3: Buat profil untuk enkripsi tingkat lapangan
<a name="field-level-encryption-setting-up-step3"></a>

Setelah Anda menambahkan setidaknya satu kunci publik CloudFront, buat profil yang memberi tahu bidang CloudFront mana yang akan dienkripsi.<a name="field-level-encryption-setting-up-step3-procedure"></a>

**Untuk membuat profil enkripsi tingkat lapangan (konsole)**

1. Di panel navigasi, pilih **Enkripsi tingkat lapangan**.

1. Pilih **Buat profil**.

1. Isi kolom berikut:  
**Nama profil**  
Ketikkan nama unik untuk profil. Nama tidak boleh memiliki spasi dan hanya dapat menyertakan karakter alfanumerik, garis bawah (\$1), dan tanda hubung (-). Jumlah karakter maksimum adalah 128.  
**Nama kunci publik**  
Dalam daftar drop-down, pilih nama kunci publik yang Anda tambahkan CloudFront pada langkah 2. CloudFront menggunakan kunci untuk mengenkripsi bidang yang Anda tentukan di profil ini.  
**Nama penyedia**  
Ketikkan frasa untuk membantu mengidentifikasi kunci, seperti penyedia tempat Anda mendapatkan pasangan kunci. Informasi ini, bersama dengan kunci pribadi, diperlukan ketika aplikasi mendekripsi bidang data. Nama penyedia tidak boleh memiliki spasi dan hanya dapat menyertakan karakter alfanumerik, usus besar (:), garis bawah (\$1), dan tanda hubung (-). Jumlah karakter maksimum adalah 128.  
**Pola nama bidang agar cocok**  
Ketik nama bidang data, atau pola yang mengidentifikasi nama bidang data dalam permintaan, yang Anda inginkan CloudFront untuk mengenkripsi. Pilih opsi \$1 untuk menambahkan semua kolom yang ingin Anda enkripsi dengan kunci ini.  
Untuk pola nama bidang, Anda dapat mengetikkan seluruh nama bidang data, seperti DateOfBirth, atau hanya bagian pertama dari nama dengan karakter wildcard (\$1), CreditCard seperti\$1. Pola nama bidang hanya boleh menyertakan karakter alfanumerik, tanda kurung persegi ([ dan ]), periode (.), garis bawah (\$1), dan tanda hubung (-), selain karakter wildcard opsional (\$1).  
Pastikan Anda tidak menggunakan karakter yang tumpang tindih untuk pola nama bidang yang berbeda. Misalnya, jika Anda memiliki pola nama kolom ABC\$1, Anda tidak dapat menambahkan pola nama bidang lain yang merupakan AB\$1. Selain itu, nama bidang bersifat peka huruf besar dan jumlah maksimal karakter yang dapat Anda gunakan adalah 128.  
**Komentar**  
(Opsional) Ketik komentar tentang profil ini. Jumlah maksimal karakter yang dapat Anda gunakan adalah 128.

1. Setelah mengisi kolom, pilih **Buat profil**.

1. Jika Anda ingin menambahkan profil lagi, pilih **Tambahkan profil**.

### Langkah 4: Buat konfigurasi
<a name="field-level-encryption-setting-up-step4"></a>

Setelah Anda membuat satu atau beberapa profil enkripsi tingkat lapangan, buat konfigurasi yang menentukan jenis konten permintaan yang menyertakan data yang akan dienkripsi, profil yang akan digunakan untuk enkripsi, dan opsi lain yang menentukan cara Anda ingin menangani enkripsi. CloudFront 

Misalnya, ketika tidak CloudFront dapat mengenkripsi data, Anda dapat menentukan apakah CloudFront harus memblokir atau meneruskan permintaan ke asal Anda dalam skenario berikut:
+ **Jika jenis konten permintaan tidak ada dalam konfigurasi** — Jika Anda belum menambahkan tipe konten ke konfigurasi, Anda dapat menentukan apakah CloudFront harus meneruskan permintaan dengan tipe konten tersebut ke asal tanpa mengenkripsi bidang data, atau memblokir permintaan dan mengembalikan kesalahan.
**catatan**  
Jika Anda menambahkan jenis konten ke konfigurasi tetapi belum menentukan profil untuk digunakan dengan tipe tersebut, CloudFront selalu teruskan permintaan dengan jenis konten tersebut ke asal.
+ **Bila nama profil yang disediakan dalam argumen kueri tidak diketahui** - Bila Anda menentukan argumen `fle-profile` kueri dengan nama profil yang tidak ada untuk distribusi Anda, Anda dapat menentukan apakah CloudFront harus mengirim permintaan ke asal tanpa mengenkripsi bidang data, atau memblokir permintaan dan mengembalikan kesalahan.

Dalam konfigurasi, Anda juga dapat menentukan apakah memberikan profil sebagai argumen kueri dalam URL membatalkan profil yang telah dipetakan ke jenis konten untuk kueri tersebut. Secara default, CloudFront gunakan profil yang telah Anda petakan ke jenis konten, jika Anda menentukannya. Ini memungkinkan Anda memiliki profil yang digunakan secara default tetapi memutuskan untuk permintaan tertentu yang ingin Anda gunakan profil berbeda.

Jadi, misalnya, Anda dapat menentukan (dalam konfigurasi Anda) **SampleProfile** sebagai profil argumen kueri untuk digunakan. Kemudian Anda dapat menggunakan URL `https://d1234.cloudfront.net?fle-profile=SampleProfile` alih-alih`https://d1234.cloudfront.net`, untuk CloudFront digunakan **SampleProfile** untuk permintaan ini, alih-alih profil yang akan Anda siapkan untuk jenis konten permintaan.

Anda dapat membuat hingga 10 konfigurasi untuk satu akun, lalu mengaitkan salah satu konfigurasi ke perilaku cache dari setiap distribusi untuk akun.<a name="field-level-encryption-setting-up-step4-procedure"></a>

**Untuk membuat konfigurasi enkripsi tingkat lapangan (konsole)**

1. Di **Enkripsi tingkat lapangan** halaman, pilih **Buat konfigurasi**.

   Catatan: Jika Anda belum membuat setidaknya satu profil, Anda tidak akan melihat opsi untuk membuat konfigurasi.

1. Isi kolom berikut untuk menentukan profil yang akan digunakan. (Beberapa kolom tidak dapat diubah.)  
**Jenis konten (tidak dapat diubah)**  
Jenis konten diatur ke `application/x-www-form-urlencoded` dan tidak dapat diubah.  
**ID profil default (opsional)**  
Di daftar menurun, pilih profil yang ingin Anda petakan ke jenis konten di **Jenis konten** bidang.  
**Format konten (tidak dapat diubah)**  
Format konten diatur ke `URLencoded` dan tidak dapat diubah.

1. Jika Anda ingin mengubah perilaku CloudFront default untuk opsi berikut, pilih kotak centang yang sesuai.  
**Teruskan permintaan ke asal ketika jenis konten permintaan tidak dikonfigurasi**  
Pilih kotak centang jika Anda ingin mengizinkan permintaan untuk pergi ke asal Anda *jika Anda belum menentukan profil yang akan digunakan untuk jenis permintaan konten tersebut*.  
**Ubah profil untuk jenis konten dengan argumen kueri yang diberikan**  
Centang kotak jika Anda ingin mengizinkan profil yang diberikan dalam argumen kueri *menimpa profil yang telah Anda tentukan untuk jenis konten*.

1. Jika Anda memilih kotak centang untuk mengizinkan argumen kueri menimpa profil default, Anda harus melengkapi kolom tambahan berikut untuk konfigurasi. Anda dapat membuat hingga lima pemetaan argumen kueri ini untuk digunakan dengan kueri.  
**Argumen pertanyaan**  
Ketik nilai yang ingin Anda sertakan URLs untuk argumen `fle-profile` kueri. Nilai ini memberitahu CloudFront untuk menggunakan ID profil (yang Anda tentukan di bidang berikutnya) yang terkait dengan argumen kueri ini untuk enkripsi tingkat bidang untuk kueri ini.  
Jumlah maksimal karakter yang dapat Anda gunakan adalah 128. Nilai tidak boleh menyertakan spasi, dan hanya boleh menggunakan karakter alfanumerik atau karakter berikut: tanda hubung (-), periode (.), garis bawah (\$1), tanda bintang (\$1), tanda tambah (\$1), persen (%).  
**ID Profil**  
Di daftar menurun, pilih profil yang ingin Anda kaitkan dengan nilai yang Anda masukkan **Argumen pertanyaan**.  
**Teruskan permintaan ke asal ketika profil yang ditentukan dalam argumen kueri tidak ada**  
Pilih kotak centang jika Anda ingin mengizinkan permintaan untuk pergi ke asal Anda *jika profil yang ditentukan dalam argumen kueri tidak didefinisikan dalam CloudFront*.

### Langkah 5: Tambahkan konfigurasi ke perilaku cache
<a name="field-level-encryption-setting-up-step5"></a>

Untuk menggunakan enkripsi tingkat lapangan, tautkan konfigurasi ke perilaku cache untuk distribusi dengan menambahkan ID konfigurasi sebagai nilai untuk distribusi Anda.

**penting**  
Untuk menautkan konfigurasi enkripsi tingkat lapangan ke perilaku cache, distribusi harus dikonfigurasi untuk selalu menggunakan HTTPS, dan untuk menerima HTTP `POST` dan `PUT` permintaan dari penampil. Yaitu, hal-hal berikut harus benar:  
Perilaku singgahan **Kebijakan Protokol Penampil** harus diatur menjadi **Arahkan ulang HTTP ke HTTPS** atau **HTTPS Saja**. (Dalam CloudFormation atau CloudFront API, `ViewerProtocolPolicy` harus disetel ke `redirect-to-https` atau`https-only`.)
Perilaku singgahan **Metode HTTP yang Diizinkan** harus ditetapkan ke **DAPATKAN, KEPALA, OPSI, PUT, POST, PATCH, DELETE**. (Dalam CloudFormation atau CloudFront API, `AllowedMethods` harus disetel ke`GET`,`HEAD`,`OPTIONS`,`PUT`,`POST`,`PATCH`,`DELETE`. Ini dapat ditentukan dalam urutan apa pun.)
Pengaturan asal **Kebijakan Protokol Asal** harus diatur menjadi **Penampil Kecocokan** atau **HTTPS Saja**. (Dalam CloudFormation atau CloudFront API, `OriginProtocolPolicy` harus disetel ke `match-viewer` atau`https-only`.)

Untuk informasi selengkapnya, lihat [Semua referensi pengaturan distribusi](distribution-web-values-specify.md).

## Dekripsi bidang data di tempat asal Anda
<a name="field-level-encryption-decrypt"></a>

CloudFront mengenkripsi bidang data dengan menggunakan file. [AWS Encryption SDK](https://docs.aws.amazon.com/encryption-sdk/latest/developer-guide/introduction.html) Data tetap terenkripsi di seluruh tumpukan aplikasi Anda dan hanya dapat diakses oleh aplikasi yang memiliki kredensial untuk mendekripsinya.

Setelah enkripsi, ciphertext adalah dasar64 yang dikodekan. Ketika aplikasi Anda mendekripsi teks pada awalnya, aplikasi harus menguraikan ciphertext, lalu menggunakan AWS Encryption SDK untuk mendekripsi data.

Contoh kode berikut mengcitrakan bagaimana aplikasi dapat mendekripsi data di tempat asal Anda. Perhatikan hal-hal berikut: 
+ Untuk menyederhanakan contoh, sampel ini memuat kunci publik dan privat (dalam format DER) dari file di direktori kerja. Dalam praktiknya, Anda akan menyimpan kunci pribadi di lokasi offline yang aman, seperti modul keamanan perangkat keras offline, dan mendistribusikan kunci publik ke tim pengembangan Anda.
+ CloudFront menggunakan informasi spesifik saat mengenkripsi data, dan set parameter yang sama harus digunakan di tempat asal untuk mendekripsi data. Parameter yang CloudFront digunakan saat menginisialisasi MasterKey meliputi yang berikut:
  + PROVIDER\$1NAME: Anda menentukan nilai ini saat membuat profil enkripsi tingkat lapangan. Gunakan nilai yang sama di sini.
  + KEY\$1NAME: Anda membuat nama untuk kunci publik Anda ketika Anda mengunggahnya CloudFront, dan kemudian menentukan nama kunci di profil. Gunakan nilai yang sama di sini.
  + ALGORITHM: CloudFront digunakan `RSA/ECB/OAEPWithSHA-256AndMGF1Padding` sebagai algoritma untuk mengenkripsi, jadi Anda harus menggunakan algoritma yang sama untuk mendekripsi data.
+ Jika Anda menjalankan program sampel berikut dengan ciphertext sebagai input, data yang didekripsi adalah output untuk konsol Anda. Untuk informasi selengkapnya, lihat [Kode Contoh Java](https://docs.aws.amazon.com/encryption-sdk/latest/developer-guide/java-example-code.html) di SDK AWS Enkripsi.

### Kode sampel
<a name="field-level-encryption-decrypt-sample"></a>

```
import java.nio.file.Files;
import java.nio.file.Paths;
import java.security.KeyFactory;
import java.security.PrivateKey;
import java.security.PublicKey;
import java.security.spec.PKCS8EncodedKeySpec;
import java.security.spec.X509EncodedKeySpec;

import org.apache.commons.codec.binary.Base64;

import com.amazonaws.encryptionsdk.AwsCrypto;
import com.amazonaws.encryptionsdk.CryptoResult;
import com.amazonaws.encryptionsdk.jce.JceMasterKey;

/**
 * Sample example of decrypting data that has been encrypted by CloudFront field-level encryption.
 */
public class DecryptExample {

    private static final String PRIVATE_KEY_FILENAME = "private_key.der";
    private static final String PUBLIC_KEY_FILENAME = "public_key.der";
    private static PublicKey publicKey;
    private static PrivateKey privateKey;

    // CloudFront uses the following values to encrypt data, and your origin must use same values to decrypt it.
    // In your own code, for PROVIDER_NAME, use the provider name that you specified when you created your field-level
    // encryption profile. This sample uses 'DEMO' for the value.
    private static final String PROVIDER_NAME = "DEMO";
    // In your own code, use the key name that you specified when you added your public key to CloudFront. This sample
    // uses 'DEMOKEY' for the key name.
    private static final String KEY_NAME = "DEMOKEY";
    // CloudFront uses this algorithm when encrypting data.
    private static final String ALGORITHM = "RSA/ECB/OAEPWithSHA-256AndMGF1Padding";

    public static void main(final String[] args) throws Exception {

        final String dataToDecrypt = args[0];

        // This sample uses files to get public and private keys.
        // In practice, you should distribute the public key and save the private key in secure storage.
        populateKeyPair();

        System.out.println(decrypt(debase64(dataToDecrypt)));
    }

    private static String decrypt(final byte[] bytesToDecrypt) throws Exception {
        // You can decrypt the stream only by using the private key.

        // 1. Instantiate the SDK
        final AwsCrypto crypto = new AwsCrypto();

        // 2. Instantiate a JCE master key
        final JceMasterKey masterKey = JceMasterKey.getInstance(
                publicKey,
                privateKey,
                PROVIDER_NAME,
                KEY_NAME,
                ALGORITHM);

        // 3. Decrypt the data
        final CryptoResult <byte[], ? > result = crypto.decryptData(masterKey, bytesToDecrypt);
        return new String(result.getResult());
    }

    // Function to decode base64 cipher text.
    private static byte[] debase64(final String value) {
        return Base64.decodeBase64(value.getBytes());
    }

    private static void populateKeyPair() throws Exception {
        final byte[] PublicKeyBytes = Files.readAllBytes(Paths.get(PUBLIC_KEY_FILENAME));
        final byte[] privateKeyBytes = Files.readAllBytes(Paths.get(PRIVATE_KEY_FILENAME));
        publicKey = KeyFactory.getInstance("RSA").generatePublic(new X509EncodedKeySpec(PublicKeyBytes));
        privateKey = KeyFactory.getInstance("RSA").generatePrivate(new PKCS8EncodedKeySpec(privateKeyBytes));
    }
}
```