Halaman ini memberikan ringkasan URL yang ditandatangani dan petunjuk untuk menggunakannya dengan Cloud CDN. URL bertanda tangan memberikan akses resource dengan waktu terbatas kepada siapa saja yang memiliki URL, terlepas dari apakah pengguna memiliki Akun Google atau tidak.
URL yang ditandatangani adalah URL yang memberikan izin berbatas waktu untuk membuat permintaan. URL yang ditandatangani berisi informasi autentikasi dalam string kuerinya, yang memungkinkan pengguna tanpa kredensial melakukan tindakan tertentu pada resource. Saat membuat URL yang ditandatangani, tentukan pengguna atau akun layanan yang harus memiliki izin yang memadai untuk membuat permintaan yang terkait dengan URL.
Setelah Anda membuat URL yang ditandatangani, siapa saja yang memilikinya dapat menggunakan URL yang ditandatangani untuk melakukan tindakan tertentu (seperti membaca objek) dalam jangka waktu tertentu.
URL yang ditandatangani juga mendukung parameter URLPrefix
opsional, yang memungkinkan Anda menyediakan akses ke beberapa URL berdasarkan awalan yang sama.
Jika Anda ingin menentukan cakupan akses ke awalan URL tertentu, pertimbangkan untuk menggunakan cookie yang ditandatangani.
Sebelum memulai
Sebelum menggunakan URL bertanda tangan, lakukan hal berikut:
Pastikan Cloud CDN diaktifkan; untuk petunjuknya, lihat Menggunakan Cloud CDN. Anda dapat mengonfigurasi URL 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 salah ditolak.
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, tayangkan 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.iam.gserviceaccount.com \ --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.iam.gserviceaccount.com
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 dalam dokumentasi Bantuan konsol Google Cloud.
Menyesuaikan waktu cache maksimum
Cloud CDN menyimpan respons untuk permintaan yang ditandatangani, terlepas dari 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 menampilkan 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
URL Tanda Tangan
Langkah terakhir adalah menandatangani URL dan mendistribusikannya. Anda dapat menandatangani URL menggunakan
perintah gcloud compute sign-url
atau menggunakan kode yang Anda tulis sendiri.
Jika Anda memerlukan banyak URL yang ditandatangani, kode kustom akan memberikan performa yang lebih baik.
Membuat URL yang ditandatangani
Gunakan petunjuk ini untuk membuat URL yang ditandatangani menggunakan perintah gcloud compute sign-url
. Langkah ini mengasumsikan bahwa Anda telah
membuat kunci.
Konsol
Anda tidak dapat membuat URL yang ditandatangani menggunakan konsol Google Cloud. Anda dapat menggunakan Google Cloud CLI atau menulis kode kustom menggunakan contoh berikut.
gcloud
Google Cloud CLI menyertakan perintah untuk menandatangani URL. Perintah ini menerapkan algoritma yang dijelaskan di bagian tentang menulis kode Anda sendiri.
gcloud compute sign-url \ "URL" \ --key-name KEY_NAME \ --key-file KEY_FILE_NAME \ --expires-in TIME_UNTIL_EXPIRATION \ [--validate]
Perintah ini membaca dan mendekode nilai kunci yang dienkode base64url
dari KEY_FILE_NAME
, lalu menghasilkan
URL yang ditandatangani yang dapat Anda gunakan untuk permintaan GET
atau HEAD
untuk URL yang diberikan.
Contoh:
gcloud compute sign-url \ "https://example.com/media/video.mp4" \ --key-name my-test-key \ --expires-in 30m \ --key-file sign-url-key-file
URL
harus berupa URL yang valid dan memiliki komponen
jalur. Misalnya, http://example.com
tidak valid, tetapi
https://example.com/
dan https://example.com/whatever
adalah URL
yang valid.
Jika tanda --validate
opsional diberikan, perintah ini akan mengirim permintaan HEAD
dengan URL yang dihasilkan, dan mencetak kode respons HTTP. Jika URL yang ditandatangani benar, kode respons akan sama dengan kode hasil yang dikirim oleh backend Anda. Jika kode respons tidak sama, periksa kembali
KEY_NAME
dan konten file yang ditentukan,
dan pastikan nilai
TIME_UNTIL_EXPIRATION
setidaknya beberapa detik.
Jika tanda --validate
tidak diberikan, hal berikut tidak akan diverifikasi:
- Input
- URL yang dibuat
- URL yang ditandatangani yang dihasilkan
Membuat URL yang ditandatangani secara terprogram
Contoh kode berikut menunjukkan cara membuat URL yang ditandatangani secara terprogram.
Go
Ruby
.NET
Java
Python
PHP
Membuat URL yang ditandatangani secara terprogram dengan awalan URL
Contoh kode berikut menunjukkan cara membuat URL tertanda tangan secara terprogram dengan awalan URL.
Go
Java
Python
Membuat URL yang ditandatangani kustom
Saat menulis kode sendiri untuk membuat URL yang ditandatangani, sasaran Anda adalah membuat URL dengan format atau algoritma berikut; semua parameter URL peka huruf besar/kecil dan harus dalam urutan yang ditampilkan:
https://example.com/foo?Expires=EXPIRATION&KeyName=KEY_NAME&Signature=SIGNATURE
Untuk membuat URL yang ditandatangani, ikuti langkah-langkah berikut:
Pastikan URL untuk penandatanganan tidak memiliki parameter kueri
Signature
.Tentukan kapan URL berakhir masa berlakunya dan tambahkan parameter kueri
Expires
dengan waktu habis masa berlaku yang diperlukan dalam waktu UTC (jumlah detik sejak 1970-01-01 00:00:00 UTC). Untuk memaksimalkan keamanan, tetapkan nilai ke jangka waktu terpendek yang memungkinkan untuk kasus penggunaan Anda. Makin lama URL yang ditandatangani valid, makin besar risiko pengguna yang Anda beri URL tersebut membagikannya kepada orang lain, baik secara tidak sengaja maupun tidak.Tetapkan nama kunci. URL harus ditandatangani dengan kunci layanan backend atau bucket backend yang menayangkan URL. Sebaiknya gunakan kunci yang baru ditambahkan untuk rotasi kunci. Tambahkan kunci ke URL dengan menambahkan
&KeyName=KEY_NAME
. GantiKEY_NAME
dengan nama kunci yang dipilih dan dibuat di Membuat kunci permintaan yang ditandatangani.Tanda tangani URL. Buat URL yang ditandatangani dengan mengikuti langkah-langkah berikut. Pastikan parameter kueri berada dalam urutan yang ditampilkan tepat sebelum langkah 1, dan pastikan tidak ada yang mengubah kasus URL yang ditandatangani.
a. Hash seluruh URL (termasuk
http://
atauhttps://
di awal dan&KeyName...
di akhir) dengan HMAC-SHA1 menggunakan kunci secret yang sesuai dengan nama kunci yang dipilih sebelumnya. Gunakan kunci rahasia 16 byte mentah, bukan kunci yang dienkode base64url. Dekode jika perlu.b. Gunakan base64url encode untuk mengenkode hasilnya.
c. Tambahkan
&Signature=
ke URL, diikuti dengan tanda tangan yang dienkode.
Menggunakan awalan URL untuk URL yang ditandatangani
Daripada menandatangani URL permintaan lengkap dengan parameter kueri Expires
dan KeyName
, Anda dapat menandatangani parameter kueri URLPrefix
, Expires
, dan KeyName
saja. Hal ini memungkinkan kombinasi parameter kueri URLPrefix
, Expires
,
KeyName
, dan Signature
tertentu digunakan kembali secara verbatim di
beberapa URL yang cocok dengan URLPrefix
, sehingga Anda tidak perlu membuat tanda tangan
baru untuk setiap URL yang berbeda.
Dalam contoh berikut, teks yang ditandai menunjukkan
parameter yang Anda tanda tangani. Signature
ditambahkan sebagai parameter kueri
akhir, seperti biasa.
https://media.example.com/videos/id/master.m3u8?userID=abc123&starting_profile=1&URLPrefix=aHR0cHM6Ly9tZWRpYS5leGFtcGxlLmNvbS92aWRlb3Mv&Expires=1566268009&KeyName=mySigningKey&Signature=8NBSdQGzvDftrOIa3WHpp646Iis=
Tidak seperti menandatangani URL permintaan lengkap, saat menandatangani dengan URLPrefix
, Anda tidak menandatangani parameter kueri apa pun, sehingga parameter kueri dapat disertakan secara bebas dalam URL. Selain itu, tidak seperti tanda tangan URL permintaan lengkap, parameter kueri tambahan tersebut
dapat muncul sebelum dan sesudah parameter kueri yang membentuk
tanda tangan. Oleh karena itu, URL berikut juga valid dengan awalan URL
yang ditandatangani:
https://media.example.com/videos/id/master.m3u8?userID=abc123&URLPrefix=aHR0cHM6Ly9tZWRpYS5leGFtcGxlLmNvbS92aWRlb3Mv&Expires=1566268009&KeyName=mySigningKey&Signature=8NBSdQGzvDftrOIa3WHpp646Iis=&starting_profile=1
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.
Memvalidasi URL yang ditandatangani
Proses memvalidasi URL yang ditandatangani pada dasarnya sama dengan membuat URL yang ditandatangani. Misalnya, Anda ingin memvalidasi URL yang ditandatangani berikut:
https://example.com/PATH?Expires=EXPIRATION&KeyName=KEY_NAME&Signature=SIGNATURE
Anda dapat menggunakan kunci rahasia yang diberi nama oleh KEY_NAME
untuk
membuat tanda tangan secara independen untuk URL berikut:
https://example.com/PATH?Expires=EXPIRATION&KeyName=KEY_NAME
Kemudian, Anda dapat memverifikasi bahwa cocok dengan SIGNATURE
.
Misalkan Anda ingin memvalidasi URL yang ditandatangani yang memiliki URLPrefix
, seperti yang ditunjukkan
di sini:
https://example.com/PATH?URLPrefix=URL_PREFIX&Expires=EXPIRATION&KeyName=KEY_NAME&Signature=SIGNATURE
Pertama, pastikan nilai URL_PREFIX
yang didekode base64
adalah awalan https://example.com/PATH
. Jika demikian, Anda
dapat menghitung tanda tangan untuk hal berikut:
URLPrefix=URL_PREFIX&Expires=EXPIRATION&KeyName=KEY_NAME
Kemudian, Anda dapat memverifikasi bahwa cocok dengan SIGNATURE
.
Untuk metode penandatanganan berbasis URL, dengan tanda tangan sebagai bagian dari parameter
kueri atau disematkan sebagai komponen jalur URL, tanda tangan dan parameter
terkait akan dihapus dari URL sebelum permintaan dikirim ke
asal. Hal ini mencegah tanda tangan menyebabkan masalah pemilihan rute saat
asal menangani permintaan. Untuk memvalidasi permintaan ini, Anda dapat memeriksa
header permintaan x-client-request-url
, yang menyertakan URL permintaan klien
asli (ditandatangani) sebelum penghapusan komponen yang ditandatangani.
Menghapus akses publik ke bucket Cloud Storage
Agar URL yang ditandatangani dapat melindungi konten dengan benar, server origin tidak boleh memberikan akses publik ke konten tersebut. Saat menggunakan bucket Cloud Storage, pendekatan umum adalah membuat objek bersifat publik untuk sementara untuk tujuan pengujian. Setelah mengaktifkan URL yang ditandatangani, Anda harus
menghapus izin BACA allUsers
(dan allAuthenticatedUsers
, jika berlaku) (dengan kata lain, peran Identity and Access Management Storage Object Viewer) di bucket.
Setelah Anda menonaktifkan akses publik di bucket, setiap pengguna masih dapat mengakses Cloud Storage tanpa URL yang ditandatangani jika mereka memiliki izin akses, seperti izin PEMILIK.
Untuk menghapus akses BACA allUsers
publik di bucket Cloud Storage, lakukan tindakan yang dijelaskan dalam Membuat semua objek dalam bucket dapat dibaca oleh publik.
Mendistribusikan dan menggunakan URL yang ditandatangani
URL yang ditampilkan dari Google Cloud CLI atau yang dihasilkan oleh kode kustom Anda dapat didistribusikan sesuai kebutuhan Anda. Sebaiknya hanya tanda tangani URL
HTTPS, karena HTTPS menyediakan transpor aman yang mencegah komponen Signature
dari URL yang ditandatangani disadap. Demikian pula, pastikan
Anda mendistribusikan URL yang ditandatangani melalui protokol transpor aman seperti
TLS/HTTPS.