Halaman ini memberikan ringkasan tentang cookie yang ditandatangani dan petunjuk untuk menggunakannya dengan Cloud CDN. Cookie yang ditandatangani memberikan akses resource dengan waktu terbatas ke kumpulan file, terlepas dari apakah pengguna memiliki Akun Google atau tidak.
Cookie yang ditandatangani adalah alternatif untuk URL yang ditandatangani. Cookie yang ditandatangani melindungi akses saat menandatangani puluhan atau ratusan URL secara terpisah untuk setiap pengguna tidak memungkinkan di aplikasi Anda.
Cookie yang ditandatangani memungkinkan Anda melakukan hal berikut:
- Beri otorisasi kepada pengguna dan berikan token berbatas waktu untuk mengakses konten yang dilindungi (bukan menandatangani setiap URL).
- Cakup akses pengguna ke awalan URL tertentu, seperti
https://media.example.com/videos/
, dan berikan akses kepada pengguna yang diberi otorisasi untuk konten yang dilindungi dalam awalan URL tersebut saja. - Memastikan URL dan manifes media Anda tidak berubah, sehingga menyederhanakan pipeline paket dan meningkatkan kemampuan penyimpanan dalam cache.
Jika Anda ingin menentukan cakupan akses ke URL tertentu, pertimbangkan untuk menggunakan URL bertanda tangan.
Sebelum memulai
Sebelum menggunakan cookie yang ditandatangani, lakukan hal berikut:
Pastikan Cloud CDN diaktifkan; untuk petunjuknya, lihat Menggunakan Cloud CDN. Anda dapat mengonfigurasi cookie yang ditandatangani di backend sebelum mengaktifkan Cloud CDN, tetapi tidak ada efeknya hingga Cloud CDN diaktifkan.
Jika perlu, update ke Google Cloud CLI versi terbaru:
gcloud components update
Untuk mengetahui ringkasannya, lihat URL yang ditandatangani dan cookie yang ditandatangani.
Mengonfigurasi kunci permintaan yang ditandatangani
Membuat kunci untuk URL atau cookie yang ditandatangani memerlukan beberapa langkah, yang dijelaskan di bagian berikut.
Pertimbangan keamanan
Cloud CDN tidak memvalidasi permintaan dalam situasi berikut:
- Permintaan tidak ditandatangani.
- Layanan backend atau bucket backend untuk permintaan tidak mengaktifkan Cloud CDN.
Permintaan yang ditandatangani harus selalu divalidasi di origin sebelum menayangkan respons. Hal ini karena origin dapat digunakan untuk menayangkan campuran konten yang ditandatangani dan tidak ditandatangani, serta karena klien mungkin mengakses origin secara langsung.
- Cloud CDN tidak memblokir permintaan tanpa parameter kueri
Signature
atau cookie HTTPCloud-CDN-Cookie
. Fungsi ini menolak permintaan dengan parameter permintaan yang tidak valid (atau salah format). - Saat aplikasi mendeteksi tanda tangan yang tidak valid, pastikan aplikasi
merespons dengan kode respons
HTTP 403 (Unauthorized)
. Kode responsHTTP 403
tidak dapat di-cache. - Respons untuk permintaan yang ditandatangani dan tidak ditandatangani di-cache secara terpisah, sehingga respons yang berhasil untuk permintaan yang ditandatangani yang valid tidak pernah digunakan untuk menayangkan permintaan yang tidak ditandatangani.
- Jika aplikasi Anda mengirim kode respons yang dapat di-cache ke permintaan yang tidak valid, permintaan mendatang yang valid mungkin ditolak secara keliru.
Untuk backend Cloud Storage, pastikan untuk menghapus akses publik, sehingga Cloud Storage dapat menolak permintaan yang tidak memiliki tanda tangan yang valid.
Tabel berikut merangkum perilaku tersebut.
Permintaan memiliki tanda tangan | Cache hit | Perilaku |
---|---|---|
Tidak | Tidak | Teruskan ke origin backend. |
Tidak | Ya | Menayangkan dari cache. |
Ya | Tidak | Memvalidasi tanda tangan. Jika valid, teruskan ke origin backend. |
Ya | Ya | Memvalidasi tanda tangan. Jika valid, kirim dari cache. |
Membuat kunci permintaan yang ditandatangani
Anda mengaktifkan dukungan untuk URL yang ditandatangani Cloud CDN dan cookie yang ditandatangani dengan membuat satu atau beberapa kunci di layanan backend, bucket backend, atau keduanya yang mengaktifkan Cloud CDN.
Untuk setiap layanan backend atau bucket backend, Anda dapat membuat dan menghapus kunci sesuai kebutuhan keamanan Anda. Setiap backend dapat memiliki hingga tiga kunci yang dikonfigurasi secara bersamaan. Sebaiknya putar kunci Anda secara berkala dengan menghapus kunci yang paling lama, menambahkan kunci baru, dan menggunakan kunci baru saat menandatangani URL atau cookie.
Anda dapat menggunakan nama kunci yang sama di beberapa layanan backend dan bucket backend karena setiap kumpulan kunci bersifat independen dari yang lain. Nama kunci dapat berisi maksimal 63 karakter. Untuk memberi nama kunci, gunakan karakter A-Z, a-z, 0-9, _ (garis bawah), dan - (tanda hubung).
Saat membuat kunci, pastikan untuk menjaga keamanannya karena siapa pun yang memiliki salah satu kunci Anda dapat membuat URL bertanda tangan atau cookie bertanda tangan yang diterima Cloud CDN hingga kunci dihapus dari Cloud CDN. Kunci disimpan di komputer tempat Anda membuat URL atau cookie bertanda tangan. Cloud CDN juga menyimpan kunci untuk memverifikasi tanda tangan permintaan.
Untuk menjaga kerahasiaan kunci, nilai kunci tidak disertakan dalam respons terhadap permintaan API apa pun. Jika kunci hilang, Anda harus membuat kunci baru.
Untuk membuat kunci permintaan yang ditandatangani, ikuti langkah-langkah berikut.
Konsol
- Di konsol Google Cloud, buka halaman Cloud CDN.
- Klik nama origin tempat Anda ingin menambahkan kunci.
- Di halaman Detail origin, klik tombol Edit.
- Di bagian Dasar-dasar origin, klik Berikutnya untuk membuka bagian Host and path rules.
- Di bagian Host and path rules, klik Next untuk membuka bagian Cache performance.
- Di bagian Restricted content, pilih Restrict access using signed URLs and signed cookies.
Klik Tambahkan kunci penandatanganan.
- Tentukan nama unik untuk kunci penandatanganan baru.
Di bagian Key creation method, pilih Automatically generate. Atau, klik Izinkan saya masuk, lalu tentukan nilai kunci penandatanganan.
Untuk opsi pertama, salin nilai kunci penandatanganan yang dibuat secara otomatis ke file pribadi, yang dapat Anda gunakan untuk membuat URL yang ditandatangani.
Klik Done.
Di bagian Usia maksimum entri cache, masukkan nilai, lalu pilih satuan waktu.
Klik Done.
gcloud
Alat command line gcloud
membaca kunci dari file lokal yang
Anda tentukan. File kunci harus dibuat dengan membuat 128
bit acak yang sangat kuat, mengenkodenya dengan base64, lalu mengganti karakter +
dengan
-
dan mengganti karakter /
dengan _
. Untuk mengetahui informasi selengkapnya, lihat
RFC 4648.
Kunci harus sangat acak. Pada sistem mirip UNIX, Anda dapat
membuat kunci acak yang sangat kuat dan menyimpannya dalam file kunci dengan
perintah berikut:
head -c 16 /dev/urandom | base64 | tr +/ -_ > KEY_FILE_NAME
Untuk menambahkan kunci ke layanan backend:
gcloud compute backend-services \ add-signed-url-key BACKEND_NAME \ --key-name KEY_NAME \ --key-file KEY_FILE_NAME
Untuk menambahkan kunci ke bucket backend:
gcloud compute backend-buckets \ add-signed-url-key BACKEND_NAME \ --key-name KEY_NAME \ --key-file KEY_FILE_NAME
Mengonfigurasi izin Cloud Storage
Jika menggunakan Cloud Storage dan telah membatasi siapa yang dapat membaca objek, Anda harus memberikan izin Cloud CDN untuk membaca objek dengan menambahkan akun layanan Cloud CDN ke ACL Cloud Storage.
Anda tidak perlu membuat akun layanan. Akun layanan akan dibuat secara otomatis saat Anda pertama kali menambahkan kunci ke bucket backend dalam project.
Sebelum menjalankan perintah berikut, tambahkan setidaknya satu kunci ke bucket backend di project Anda. Jika tidak, perintah akan gagal dengan error karena akun layanan pengisian cache Cloud CDN tidak dibuat hingga Anda menambahkan satu atau beberapa kunci untuk project.
gcloud storage buckets add-iam-policy-binding gs://BUCKET \ --member=serviceAccount:service-PROJECT_NUM@cloud-cdn-fill. \ --role=roles/storage.objectViewer
Ganti PROJECT_NUM
dengan nomor project Anda dan BUCKET
dengan bucket penyimpanan Anda.
Akun layanan Cloud CDN
service-PROJECT_NUM@cloud-cdn-fill.
tidak muncul dalam daftar akun layanan di project Anda. Hal ini karena akun layanan Cloud CDN dimiliki oleh Cloud CDN, bukan project Anda.
Untuk informasi selengkapnya tentang nomor project, lihat Menemukan project ID dan nomor project di dokumentasi Bantuan konsol Google Cloud.
Menyesuaikan waktu cache maksimum
Cloud CDN menyimpan respons untuk permintaan yang ditandatangani, apa pun header Cache-Control
backend. Waktu maksimum respons dapat di-cache tanpa validasi ulang ditetapkan oleh flag signed-url-cache-max-age
, yang secara default ditetapkan ke satu jam dan dapat diubah seperti yang ditunjukkan di sini.
Untuk menetapkan waktu cache maksimum untuk layanan backend atau bucket backend, jalankan salah satu perintah berikut:
gcloud compute backend-services update BACKEND_NAME --signed-url-cache-max-age MAX_AGE
gcloud compute backend-buckets update BACKEND_NAME --signed-url-cache-max-age MAX_AGE
Mencantumkan nama kunci permintaan yang ditandatangani
Untuk mencantumkan kunci di layanan backend atau bucket backend, jalankan salah satu perintah berikut:
gcloud compute backend-services describe BACKEND_NAME
gcloud compute backend-buckets describe BACKEND_NAME
Menghapus kunci permintaan yang ditandatangani
Jika URL yang ditandatangani oleh kunci tertentu tidak boleh lagi dihormati, jalankan salah satu perintah berikut untuk menghapus kunci tersebut dari layanan backend atau bucket backend:
gcloud compute backend-services \ delete-signed-url-key BACKEND_NAME --key-name KEY_NAME
gcloud compute backend-buckets \ delete-signed-url-key BACKEND_NAME --key-name KEY_NAME
Membuat kebijakan
Kebijakan cookie yang ditandatangani adalah serangkaian pasangan key-value
(dipisahkan oleh karakter
:
), mirip dengan parameter kueri yang digunakan dalam URL yang ditandatangani.
Untuk contohnya, lihat Mengeluarkan cookie kepada pengguna.
Kebijakan mewakili parameter yang valid untuk permintaan. Kebijakan ditandatangani menggunakan message authentication code (HMAC) berbasis hash yang divalidasi Cloud CDN pada setiap permintaan.
Menentukan format dan kolom kebijakan
Ada empat kolom wajib yang harus Anda tentukan dalam urutan berikut:
URLPrefix
Expires
KeyName
Signature
Pasangan key-value
dalam kebijakan cookie yang ditandatangani peka huruf besar/kecil.
URLPrefix
URLPrefix
menunjukkan awalan URL yang dienkode base64 dan aman untuk URL yang mencakup semua
jalur yang harus valid untuk tanda tangan.
URLPrefix
mengenkode skema (http://
atau https://
), FQDN, dan
jalur opsional. Mengakhiri jalur dengan /
bersifat opsional, tetapi direkomendasikan. Awalan
tidak boleh menyertakan parameter atau fragmen kueri seperti ?
atau #
.
Misalnya, https://media.example.com/videos
cocok dengan permintaan ke kedua
hal berikut:
https://media.example.com/videos?video_id=138183&user_id=138138
https://media.example.com/videos/137138595?quality=low
Jalur awalan digunakan sebagai substring teks, bukan jalur direktori.
Misalnya, awalan https://example.com/data
memberikan akses ke kedua
hal berikut:
/data/file1
/database
Untuk menghindari kesalahan ini, sebaiknya akhiri semua awalan dengan /
, kecuali jika Anda
secara sengaja memilih untuk mengakhiri awalan dengan nama file sebagian seperti
https://media.example.com/videos/123
untuk memberikan akses ke hal berikut:
/videos/123_chunk1
/videos/123_chunk2
/videos/123_chunkN
Jika URL yang diminta tidak cocok dengan URLPrefix
, Cloud CDN menolak permintaan dan menampilkan error HTTP 403
kepada klien.
Expires
Expires
harus berupa stempel waktu Unix (jumlah detik sejak 1 Januari 1970).
KeyName
KeyName
adalah nama kunci untuk kunci yang dibuat berdasarkan bucket backend atau
layanan backend. Nama kunci peka huruf besar/kecil.
Tanda Tangan
Signature
adalah tanda tangan HMAC-SHA-1 yang dienkode base64 dan aman untuk URL dari kolom
yang membentuk kebijakan cookie. Hal ini divalidasi pada setiap permintaan; permintaan
dengan tanda tangan yang tidak valid akan ditolak dengan error HTTP 403
.
Membuat cookie yang ditandatangani secara terprogram
Contoh kode berikut menunjukkan cara membuat cookie yang ditandatangani secara terprogram.
Go
Java
Python
Memvalidasi cookie yang ditandatangani
Proses memvalidasi cookie yang ditandatangani pada dasarnya sama dengan membuat cookie yang ditandatangani. Misalnya, Anda ingin memvalidasi header cookie yang ditandatangani berikut:
Cookie: Cloud-CDN-Cookie=URLPrefix=URL_PREFIX:Expires=EXPIRATION:KeyName=KEY_NAME:Signature=SIGNATURE; Domain=media.example.com; Path=/; Expires=Tue, 20 Aug 2019 02:26:49 GMT; HttpOnly
Anda dapat menggunakan kunci rahasia yang dinamai oleh KEY_NAME
untuk
membuat tanda tangan secara independen, lalu memvalidasi bahwa tanda tangan tersebut cocok dengan
SIGNATURE
.
Memberikan cookie kepada pengguna
Aplikasi Anda harus membuat dan menerbitkan satu cookie HTTP ke setiap pengguna (klien) yang berisi kebijakan yang ditandatangani dengan benar:
Buat penanda tangan HMAC-SHA-1 dalam kode aplikasi Anda.
Tanda tangani kebijakan menggunakan kunci yang dipilih, dengan memperhatikan nama kunci yang Anda tambahkan ke backend, seperti
mySigningKey
.Buat kebijakan cookie dengan format berikut, dengan memperhatikan bahwa nama dan nilai peka huruf besar/kecil:
Name: Cloud-CDN-Cookie Value: URLPrefix=$BASE64URLECNODEDURLORPREFIX:Expires=$TIMESTAMP:KeyName=$KEYNAME:Signature=$BASE64URLENCODEDHMAC
Contoh header
Set-Cookie
:Set-Cookie: Cloud-CDN-Cookie=URLPrefix=aHR0cHM6Ly9tZWRpYS5leGFtcGxlLmNvbS92aWRlb3Mv:Expires=1566268009:KeyName=mySigningKey:Signature=0W2xlMlQykL2TG59UZnnHzkxoaw=; Domain=media.example.com; Path=/; Expires=Tue, 20 Aug 2019 02:26:49 GMT; HttpOnly
Atribut
Domain
danPath
dalam cookie menentukan apakah klien mengirim cookie ke Cloud CDN.
Rekomendasi dan persyaratan
Tetapkan atribut
Domain
danPath
secara eksplisit agar cocok dengan awalan domain dan jalur tempat Anda ingin menayangkan konten yang dilindungi, yang mungkin berbeda dengan domain dan jalur tempat cookie dikeluarkan (example.com
versusmedia.example.com
atau/browse
versus/videos
).Pastikan Anda hanya memiliki satu cookie dengan nama tertentu untuk
Domain
danPath
yang sama.Pastikan Anda tidak mengeluarkan cookie yang bertentangan karena hal ini dapat mencegah akses ke konten di sesi browser lain (jendela atau tab).
Tetapkan flag
Secure
danHttpOnly
jika berlaku.Secure
memastikan bahwa cookie hanya dikirim melalui koneksi HTTPS.HttpOnly
mencegah cookie tersedia untuk JavaScript.Atribut cookie
Expires
danMax-Age
bersifat opsional. Jika Anda menghapusnya, cookie akan ada saat sesi browser (tab, jendela) ada.Saat cache terisi atau cache tidak ditemukan, cookie yang ditandatangani akan diteruskan ke asal yang ditentukan dalam layanan backend. Pastikan Anda memvalidasi nilai cookie yang ditandatangani pada setiap permintaan sebelum menayangkan konten.