Halaman ini berisi ringkasan tentang cookie bertanda tangan dan petunjuk untuk menggunakannya dengan Cloud CDN. Cookie bertanda tangan memberikan akses resource dengan waktu terbatas ke sekumpulan file, terlepas dari apakah pengguna memiliki Akun Google atau tidak.
Cookie bertanda tangan adalah alternatif untuk URL bertanda tangan. Cookie bertanda tangan melindungi akses jika penandatanganan puluhan atau ratusan URL secara terpisah untuk tiap pengguna di aplikasi Anda tidak mungkin dilakukan.
Cookie bertanda tangan memungkinkan Anda melakukan hal-hal berikut:
- Mengizinkan pengguna dan memberi mereka token berbatas waktu untuk mengakses konten yang dilindungi (bukan menghasilkan URL bertanda tangan).
- Membatasi cakupan akses pengguna ke awalan URL tertentu, seperti
https://media.example.com/videos/, dan memberikan akses kepada pengguna yang diberi otorisasi ke konten yang dilindungi dalam awalan URL tersebut saja. - Menjaga URL dan manifes media Anda tidak berubah, sehingga menyederhanakan pipeline paket dan meningkatkan kemampuan pembuatan cache.
Jika Anda ingin membatasi akses ke URL tertentu, pertimbangkan untuk menggunakan URL bertanda tangan.
Sebelum memulai
Sebelum Anda menggunakan cookie bertanda tangan, lakukan hal-hal berikut:
Pastikan Cloud CDN diaktifkan; untuk mengetahui petunjuknya, baca bagian Menggunakan Cloud CDN. Anda dapat mengonfigurasi cookie bertanda tangan di backend sebelum mengaktifkan Cloud CDN, tetapi tidak akan ada efek apa-apa hingga Cloud CDN diaktifkan.
Jika perlu, update ke Google Cloud CLI versi terbaru:
gcloud components update
Untuk mengetahui ringkasannya, baca bagian URL bertanda tangan dan cookie bertanda tangan.
Mengonfigurasi kunci permintaan bertanda tangan
Membuat kunci untuk URL bertanda tangan atau cookie bertanda tangan 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 belum dikonfigurasi untuk menggunakan Cloud CDN.
Permintaan bertanda tangan harus selalu divalidasi di server asal sebelum menyajikan respons. Hal ini penting karena server asal dapat digunakan untuk menyajikan campuran konten bertanda tangan dan tidak bertanda tangan, dan karena klien dapat mengakses server asal secara langsung.
- Cloud CDN tidak akan memblokir permintaan tanpa parameter kueri
Signatureatau cookie HTTPCloud-CDN-Cookie. Menolak permintaan dengan parameter permintaan yang tidak valid (atau salah format). - Saat aplikasi Anda mendeteksi tanda tangan yang tidak valid, pastikan aplikasi Anda merespons dengan kode respons
HTTP 403 (Unauthorized). Kode responsHTTP 403tidak dapat di-cache. - Respons terhadap permintaan bertanda tangan dan tidak bertanda tangan akan di-cache secara terpisah, sehingga respons yang berhasil terhadap permintaan bertanda tangan yang valid tidak akan pernah digunakan untuk menyajikan permintaan yang tidak bertanda tangan.
- Jika aplikasi Anda mengirimkan kode respons yang dapat di-cache ke permintaan yang tidak valid, permintaan mendatang yang valid mungkin akan 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 ditemukan | Perilaku |
|---|---|---|
| Tidak | Tidak | Meneruskan ke server asal backend. |
| Tidak | Ya | Menyajikan dari cache. |
| Ya | Tidak | Memvalidasi tanda tangan. Jika valid, meneruskan ke server asal backend. |
| Ya | Ya | Memvalidasi tanda tangan. Jika valid, menyajikan dari cache. |
Membuat kunci permintaan bertanda tangan
Anda akan mengaktifkan dukungan untuk URL dan cookie bertanda tangan Cloud CDN dengan membuat satu atau beberapa kunci di layanan backend berkemampuan Cloud CDN, bucket backend, atau keduanya.
Untuk tiap layanan backend atau bucket backend, Anda dapat membuat dan menghapus kunci sesuai kebutuhan keamanan Anda. Tiap backend dapat memiliki hingga tiga kunci yang dikonfigurasi sekaligus. Sebaiknya Anda merotasi kunci secara berkala dengan menghapus kunci terlama, 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 tiap set kunci tidak bergantung pada 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 menjaganya tetap aman karena siapa pun yang memiliki salah satu kunci Anda dapat membuat URL bertanda tangan atau cookie bertanda tangan yang divalidasi Cloud CDN hingga kunci tersebut dihapus dari Cloud CDN. Kunci akan disimpan di komputer tempat Anda membuat URL bertanda tangan atau cookie bertanda tangan. Cloud CDN juga akan menyimpan kunci untuk memverifikasi tanda tangan permintaan.
Untuk menjaga kerahasiaan kunci, nilai kunci tidak akan disertakan dalam respons terhadap permintaan API apa pun. Jika Anda kehilangan kunci, Anda harus membuat yang baru.
Untuk membuat kunci permintaan bertanda tangan, ikuti langkah-langkah berikut.
Konsol
- Di konsol Google Cloud , buka halaman Cloud CDN.
- Klik nama server asal yang ingin Anda tambahi kunci.
- Di halaman Origin details, klik tombol Edit.
- Di bagian Origin basics, klik Next 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 Add signing key.
- Tentukan nama unik untuk kunci penandatanganan baru.
Di bagian Key creation method, pilih Automatically generate. Atau, klik Let me enter, 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 bertanda tangan.
Klik Done.
Di bagian Cache entry maximum ag, masukkan nilai, lalu pilih satuan waktu.
Klik Done.
gcloud
Alat command line gcloud akan membaca kunci dari file lokal yang Anda tentukan. File kunci harus dibuat dengan membuat 128 bit acak yang kuat, mengenkode bit tersebut dengan base64, lalu mengganti karakter + dengan - dan mengganti karakter / dengan _. Untuk mengetahui informasi selengkapnya, baca bagian RFC 7300.
Kunci harus sangat acak. Pada sistem mirip UNIX, Anda dapat membuat kunci acak yang 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 Anda menggunakan Cloud Storage dan telah membatasi siapa yang dapat membaca objek, Anda harus memberikan izin kepada Cloud CDN untuk membaca objek dengan menambahkan akun layanan Cloud CDN ke ACL Cloud Storage.
Anda tidak perlu membuat akun layanan. Akun layanan dibuat secara otomatis saat Anda pertama kali menambahkan kunci ke bucket backend dalam project.
Sebelum menjalankan perintah berikut, tambahkan minimal satu kunci ke bucket backend di project Anda. Jika tidak, perintah akan gagal disertai error karena akun layanan pengisian cache Cloud CDN tidak akan dibuat sampai Anda menambahkan satu atau beberapa kunci untuk project tersebut.
gcloud storage buckets add-iam-policy-binding gs://BUCKET \ --member=serviceAccount:service-PROJECT_NUMBER@cloud-cdn-fill.iam.gserviceaccount.com \ --role=roles/storage.objectViewer
Ganti PROJECT_NUMBER dengan nomor project Anda dan BUCKET dengan bucket penyimpanan Anda.
Akun layanan Cloud CDN service-PROJECT_NUMBER@cloud-cdn-fill.iam.gserviceaccount.com tidak akan muncul dalam daftar akun layanan di project Anda. Hal ini karena akun layanan Cloud CDN dimiliki oleh Cloud CDN, bukan project Anda.
Untuk mengetahui informasi selengkapnya tentang nomor project, baca bagian Menemukan project ID dan nomor project dalam dokumentasi Bantuan konsol Google Cloud .
Menyesuaikan waktu cache maksimum
Cloud CDN menyimpan respons dalam cache untuk permintaan bertanda tangan, terlepas dari header Cache-Control backend. Waktu maksimum saat respons dapat di-cache tanpa validasi ulang ditetapkan oleh flag signed-url-cache-max-age, yang secara default adalah 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 bertanda tangan
Untuk mencantumkan kunci pada 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 bertanda tangan
Jika URL bertanda tangan oleh kunci tertentu tidak boleh lagi digunakan, 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 bertanda tangan adalah serangkaian pasangan key-value (dibatasi oleh karakter :), yang mirip dengan parameter kueri yang digunakan dalam URL bertanda tangan.
Untuk melihat contoh, baca bagian Menyediakan cookie kepada pengguna.
Kebijakan mewakili parameter yang membuat permintaan menjadi valid. Kebijakan ditandatangani menggunakan hash-based message authentication code (HMAC) yang divalidasi Cloud CDN pada tiap permintaan.
Menentukan format dan kolom kebijakan
Ada empat kolom wajib diisi yang harus Anda tentukan dalam urutan berikut:
URLPrefixExpiresKeyNameSignature
Pasangan key-value dalam kebijakan cookie bertanda tangan bersifat peka huruf besar/kecil.
Awalan URL
URLPrefix menunjukkan awalan URL berenkode base64 yang aman untuk URL yang mencakup semua jalur bertanda tangan valid.
URLPrefix mengenkode skema (http:// atau https://), FQDN, dan jalur opsional. Mengakhiri jalur dengan / bersifat opsional, tetapi direkomendasikan. Awalan tidak boleh menyertakan parameter kueri atau fragmen seperti ? atau #.
Misalnya, https://media.example.com/videos cocok dengan permintaan ke kedua URL berikut:
https://media.example.com/videos?video_id=138183&user_id=138138https://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 sengaja memilih untuk mengakhiri awalan dengan nama file parsial 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 akan 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 atas bucket backend atau layanan backend. Nama kunci peka huruf besar/kecil.
Signature
Signature adalah tanda tangan HMAC-SHA-1 berenkode base64 yang aman untuk URL dari kolom yang membentuk kebijakan cookie. Tanda tangan ini divalidasi pada tiap permintaan. Permintaan dengan tanda tangan yang tidak valid akan ditolak dengan error HTTP 403.
Membuat cookie bertanda tangan secara terprogram
Contoh kode berikut menunjukkan cara membuat cookie bertanda tangan secara terprogram.
Go
Java
Python
Memvalidasi cookie bertanda tangan
Proses memvalidasi cookie bertanda tangan pada dasarnya sama dengan membuat cookie bertanda tangan. Misalnya, anggaplah Anda ingin memvalidasi header cookie bertanda tangan 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.
Menyediakan cookie kepada pengguna
Aplikasi Anda harus membuat dan menyediakan satu cookie HTTP untuk tiap pengguna (klien) yang berisi kebijakan bertanda tangan dengan benar:
Buat penanda tangan HMAC-SHA-1 dalam kode aplikasi Anda.
Tandatangani kebijakan menggunakan kunci yang dipilih, dengan mencatat nama kunci yang Anda tambahkan ke backend, seperti
mySigningKey.Buat kebijakan cookie dengan format berikut, dengan memperhatikan bahwa nama dan nilai tersebut bersifat 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
DomaindanPathdalam cookie menentukan apakah klien mengirim cookie ke Cloud CDN atau bukan.
Rekomendasi dan persyaratan
Tetapkan atribut
DomaindanPathsecara eksplisit agar cocok dengan awalan domain dan jalur tempat Anda ingin menyajikan konten yang dilindungi, yang mungkin berbeda dengan domain dan jalur tempat cookie disediakan (example.comversusmedia.example.comatau/browseversus/videos).Pastikan Anda hanya memiliki satu cookie dengan nama tertentu untuk
DomaindanPathyang 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
SecuredanHttpOnlyjika berlaku.Securememastikan bahwa cookie hanya dikirim melalui koneksi HTTPS.HttpOnlymencegah ketersediaan cookie untuk JavaScript.Atribut cookie
ExpiresdanMax-Agebersifat opsional. Jika Anda mengecualikannya, cookie tersebut akan ada selama sesi browser (tab, jendela) ada.Saat cache terisi atau terjadi cache tidak ditemukan, cookie yang ditandatangani akan diteruskan ke server asal yang didefinisikan di layanan backend. Pastikan Anda memvalidasi nilai cookie bertanda tangan pada tiap permintaan sebelum menyajikan konten.