בדף הזה מופיעה סקירה כללית של כתובות URL חתומות והוראות לשימוש בהן עם Cloud CDN. כתובות URL חתומות מאפשרות לתת גישה למשאבים לזמן מוגבל לכל מי שיש לו את כתובת ה-URL, בין אם יש לו חשבון Google ובין אם לא.
כתובת URL חתומה היא כתובת URL עם הרשאה וזמן מוגבלים לשליחת בקשה. כתובות URL חתומות מכילות פרטי אימות במחרוזות השאילתה, ומאפשרות למשתמשים ללא הרשאות לבצע פעולות מסוימות במשאב. כשיוצרים כתובת URL חתומה, צריך לציין משתמש או חשבון שירות שיש להם את ההרשאה הדרושה כדי לשלוח את הבקשה שמשויכת לכתובת ה-URL.
אחרי שיוצרים כתובת URL חתומה, כל מי שיש לו את הכתובת יכול להשתמש בכתובת ה-URL החתומה כדי לבצע פעולות מסוימות (כמו קריאת אובייקט) בפרק זמן מוגדר.
כתובות URL חתומות תומכות גם בפרמטר URLPrefix אופציונלי, שמאפשר לכם לספק גישה למספר כתובות URL על סמך קידומת משותפת.
אם רוצים להגביל את הגישה לקידומת ספציפית של כתובת URL, כדאי להשתמש בקובצי Cookie חתומים.
לפני שמתחילים
לפני שמשתמשים בכתובות URL חתומות, צריך לבצע את הפעולות הבאות:
מוודאים ש-Cloud CDN מופעל. הוראות מפורטות זמינות במאמר שימוש ב-Cloud CDN. אפשר להגדיר כתובות URL חתומות בשרת עורפי לפני שמפעילים את Cloud CDN, אבל ההגדרה לא משפיעה עד שמפעילים את Cloud CDN.
אם צריך, מעדכנים לגרסה האחרונה של Google Cloud CLI:
gcloud components update
סקירה כללית זמינה במאמר כתובות URL חתומות וקובצי Cookie חתומים.
הגדרת מפתחות לבקשות חתומות
כדי ליצור מפתחות לכתובות URL חתומות או לקובצי Cookie חתומים, צריך לבצע כמה שלבים שמתוארים בקטעים הבאים.
שיקולי אבטחה
Cloud CDN לא מאמת בקשות בנסיבות הבאות:
- הבקשה לא חתומה.
- שירות לקצה העורפי או קטגוריית קצה עורפי של הבקשה לא מוגדרים עם Cloud CDN.
בקשות חתומות חייבות לעבור אימות במקור תמיד לפני הצגת התגובה. הסיבה לכך היא שאפשר להשתמש במקורות להצגת תערובת של תוכן חתום ולא חתום, ולקוח עשוי לגשת למקור ישירות.
- Cloud CDN לא חוסם בקשות ללא פרמטר שאילתה
Signatureאו קובץ Cookie של HTTPCloud-CDN-Cookie. הוא דוחה בקשות עם פרמטרים לא תקינים (או עם פורמט שגוי). - כשהאפליקציה מזהה חתימה לא תקינה, צריך לוודא שהיא מגיבה עם קוד תגובה
HTTP 403 (Unauthorized). אי אפשר לשמור במטמון את קודי התגובהHTTP 403. - התשובות לבקשות חתומות ולבקשות לא חתומות נשמרות במטמון בנפרד, כך שתשובה מוצלחת לבקשה חתומה ותקפה אף פעם לא משמשת להצגת בקשה לא חתומה.
- אם האפליקציה שולחת קוד תגובה שניתן לשמירה במטמון לבקשה לא חוקית, יכול להיות שבקשות עתידיות חוקיות יידחו בטעות.
במקרים של קצה עורפי של Cloud Storage, חשוב להסיר את הגישה הציבורית כדי ש-Cloud Storage יוכל לדחות בקשות שחסר בהן חתימה תקפה.
בטבלה הבאה מפורט סיכום של ההתנהגות.
| לבקשה יש חתימה | מציאה במטמון (cache hit) | התנהגות |
|---|---|---|
| לא | לא | העברה למקור העורפי. |
| לא | כן | הצגה מהמטמון. |
| כן | לא | אימות החתימה. אם הבקשה תקינה, היא מועברת למקור העורפי. |
| כן | כן | אימות החתימה. אם התוקף לא פג, המערכת תציג את התוכן מהמטמון. |
יצירת מפתחות לבקשות חתומות
כדי להפעיל תמיכה בכתובות URL חתומות ובעוגיות חתומות של Cloud CDN, צריך ליצור מפתח אחד או יותר בשירות קצה עורפי, בקטגוריית קצה עורפי או בשניהם, שמופעל בהם Cloud CDN.
לכל שירות לקצה העורפי או קטגוריית קצה עורפי, אפשר ליצור ולמחוק מפתחות בהתאם לצרכי האבטחה. אפשר להגדיר עד שלושה מפתחות לכל קצה עורפי בכל פעם. מומלץ לבצע רוטציה של המפתחות מדי פעם על ידי מחיקת המפתח הכי ישן, הוספת מפתח חדש ושימוש במפתח החדש כשחותמים על כתובות URL או קובצי Cookie.
אפשר להשתמש באותו שם מפתח בכמה שירותי קצה עורפיים ובכמה דליים של קצה עורפי, כי כל קבוצת מפתחות היא עצמאית. שמות של מפתחות יכולים להכיל עד 63 תווים. כדי לתת שם למפתחות, אפשר להשתמש בתווים A-Z, a-z, 0-9, _ (קו תחתון) ו- (מקף).
כשיוצרים מפתחות, חשוב לשמור עליהם בצורה מאובטחת, כי כל מי שיש לו אחד מהמפתחות יכול ליצור כתובות URL חתומות או קובצי Cookie חתומים ש-Cloud CDN מקבל עד שהמפתח נמחק מ-Cloud CDN. המפתחות מאוחסנים במחשב שבו יוצרים את כתובות ה-URL החתומות או קובצי ה-Cookie החתומים. בנוסף, Cloud CDN מאחסן את המפתחות לאימות חתימות של בקשות.
כדי לשמור על סודיות המפתחות, ערכי המפתחות לא נכללים בתשובות לבקשות API. אם מאבדים מפתח, צריך ליצור מפתח חדש.
כדי ליצור מפתח בקשה חתום, פועלים לפי השלבים הבאים.
המסוף
- נכנסים לדף Cloud CDN במסוף Google Cloud .
- לוחצים על שם המקור שרוצים להוסיף לו את המפתח.
- בדף פרטי המקור, לוחצים על הלחצן עריכה.
- בקטע פרטים בסיסיים על המקור, לוחצים על הבא כדי לפתוח את הקטע כללים לגבי מארח ונתיב.
- בקטע Host and path rules (כללים לגבי מארח ונתיב), לוחצים על Next (הבא) כדי לפתוח את הקטע Cache performance (ביצועים של מטמון).
- בקטע Restricted content, בוחרים באפשרות Restrict access using signed URLs and signed cookies.
לוחצים על הוספת מפתח חתימה.
- מציינים שם ייחודי למפתח החתימה החדש.
בקטע שיטת יצירת מפתח, בוחרים באפשרות יצירה אוטומטית. אפשר גם ללחוץ על Let me enter ואז לציין ערך של מפתח חתימה.
באפשרות הראשונה, מעתיקים את הערך של מפתח החתימה שנוצר באופן אוטומטי לקובץ פרטי, שבו אפשר להשתמש כדי ליצור כתובות URL חתומות.
לוחצים על סיום.
בקטע Cache entry maximum age (הגיל המקסימלי של רשומה במטמון), מזינים ערך ואז בוחרים יחידת זמן.
לוחצים על סיום.
gcloud
כלי שורת הפקודה gcloud קורא מפתחות מקובץ מקומי שאתם מציינים. כדי ליצור את קובץ המפתח, צריך ליצור 128 ביטים אקראיים חזקים, לקודד אותם ב-Base64, ואז להחליף את התו + ב-- ואת התו / ב-_. מידע נוסף זמין ב-RFC 4648.
חשוב מאוד שהמפתח יהיה אקראי לחלוטין. במערכת כמו UNIX, אפשר ליצור מפתח אקראי חזק ולאחסן אותו בקובץ המפתח באמצעות הפקודה הבאה:
head -c 16 /dev/urandom | base64 | tr +/ -_ > KEY_FILE_NAME
כדי להוסיף את המפתח לשירות לקצה העורפי:
gcloud compute backend-services \ add-signed-url-key BACKEND_NAME \ --key-name KEY_NAME \ --key-file KEY_FILE_NAME
כדי להוסיף את המפתח לקטגוריית קצה עורפי:
gcloud compute backend-buckets \ add-signed-url-key BACKEND_NAME \ --key-name KEY_NAME \ --key-file KEY_FILE_NAME
הגדרת הרשאות ב-Cloud Storage
אם אתם משתמשים ב-Cloud Storage והגבלתם את האפשרות לקרוא את האובייקטים, אתם צריכים להוסיף את חשבון השירות של Cloud CDN לרשימות ה-ACL של Cloud Storage כדי לתת ל-Cloud CDN הרשאה לקרוא את האובייקטים.
לא צריך ליצור את חשבון השירות. חשבון השירות נוצר באופן אוטומטי בפעם הראשונה שמוסיפים מפתח למאגר (bucket) של קצה עורפי בפרויקט.
לפני שמריצים את הפקודה הבאה, צריך להוסיף לפחות מפתח אחד לקטגוריית קצה עורפי בפרויקט. אחרת, הפקודה תיכשל עם שגיאה כי חשבון השירות של Cloud CDN למילוי מטמון לא נוצר עד שמוסיפים מפתח אחד או יותר לפרויקט.
gcloud storage buckets add-iam-policy-binding gs://BUCKET \ --member=serviceAccount:service-PROJECT_NUMBER@cloud-cdn-fill.iam.gserviceaccount.com \ --role=roles/storage.objectViewer
מחליפים את PROJECT_NUMBER במספר הפרויקט ואת BUCKET בקטגוריית האחסון.
חשבון השירות של Cloud CDN service-PROJECT_NUMBER@cloud-cdn-fill.iam.gserviceaccount.com לא מופיע ברשימת חשבונות השירות בפרויקט. הסיבה לכך היא שחשבון השירות של Cloud CDN הוא בבעלות Cloud CDN, ולא בבעלות הפרויקט שלכם.
מידע נוסף על מספרי פרויקטים זמין במאמר איתור מזהה הפרויקט ומספר הפרויקט במסמכי העזרה של מסוף Google Cloud .
התאמה אישית של זמן השהייה המקסימלי במטמון
Cloud CDN שומר במטמון תגובות לבקשות חתומות, ללא קשר לכותרת Cache-Control של השרת העורפי. הזמן המקסימלי שבו אפשר לשמור תשובות במטמון בלי לבצע אימות מחדש מוגדר באמצעות הדגל signed-url-cache-max-age, שמוגדר כברירת מחדל לשעה אחת. אפשר לשנות את ההגדרה כמו שמוצג כאן.
כדי להגדיר את זמן השהייה המקסימלי במטמון לשירות קצה עורפי או לקטגוריית קצה עורפי, מריצים אחת מהפקודות הבאות:
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
רשימת שמות של מפתחות לבקשות חתומות
כדי להציג את רשימת המפתחות בשירות לקצה העורפי או בקטגוריית קצה עורפי, מריצים אחת מהפקודות הבאות:
gcloud compute backend-services describe BACKEND_NAME
gcloud compute backend-buckets describe BACKEND_NAME
מחיקת מפתחות לבקשות חתומות
אם רוצים להפסיק את השימוש בכתובות URL שחתומות על ידי מפתח מסוים, מריצים אחת מהפקודות הבאות כדי למחוק את המפתח משירות לקצה העורפי או מקטגוריית קצה עורפי:
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
השלב האחרון הוא לחתום על כתובות ה-URL ולהפיץ אותן. אפשר לחתום על כתובות URL באמצעות הפקודה gcloud compute sign-url או באמצעות קוד שכותבים בעצמכם.
אם אתם צריכים הרבה כתובות URL חתומות, קוד בהתאמה אישית יספק ביצועים טובים יותר.
יצירת כתובות URL חתומות
כדי ליצור כתובות URL חתומות באמצעות הפקודה gcloud compute sign-url, פועלים לפי ההוראות הבאות. בשלב הזה אנחנו יוצאים מנקודת הנחה שכבר יצרתם את המפתחות.
המסוף
אי אפשר ליצור כתובות URL חתומות באמצעות Google Cloud המסוף. אפשר להשתמש ב-Google Cloud CLI או לכתוב קוד בהתאמה אישית באמצעות הדוגמאות הבאות.
gcloud
Google Cloud CLI כולל פקודה לחתימה על כתובות URL. הפקודה מטמיעה את האלגוריתם שמתואר בקטע בנושא כתיבת קוד משלכם.
gcloud compute sign-url \ "URL" \ --key-name KEY_NAME \ --key-file KEY_FILE_NAME \ --expires-in TIME_UNTIL_EXPIRATION \ [--validate]
הפקודה הזו קוראת ומפענחת את ערך המפתח בקידוד base64url מ-KEY_FILE_NAME, ואז מוציאה כתובת URL חתומה שאפשר להשתמש בה לבקשות GET או HEAD עבור כתובת ה-URL שצוינה.
לדוגמה:
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 חייב להיות כתובת URL תקינה עם רכיב נתיב. לדוגמה, כתובת ה-URL http://example.com לא תקינה, אבל כתובות ה-URL https://example.com/ ו-https://example.com/whatever תקינות.
אם מציינים את הדגל האופציונלי --validate, הפקודה הזו שולחת בקשת HEAD עם כתובת ה-URL שמתקבלת ומדפיסה את קוד תגובת ה-HTTP. אם כתובת ה-URL החתומה נכונה, קוד התגובה זהה לקוד התוצאה שנשלח על ידי ה-Backend. אם קוד התגובה לא זהה, בודקים שוב את KEY_NAME ואת התוכן של הקובץ שצוין, ומוודאים שהערך של TIME_UNTIL_EXPIRATION הוא לפחות כמה שניות.
אם לא מציינים את הדגל --validate, המערכת לא מאמתת את הפרטים הבאים:
- הקלט
- כתובת ה-URL שנוצרה
- כתובת ה-URL החתומה שנוצרה
יצירה של כתובות URL חתומות באופן פרוגרמטי
בדוגמאות הקוד הבאות אפשר לראות איך ליצור כתובות URL חתומות באופן פרוגרמטי.
המשך
Ruby
.NET
Java
Python
PHP
יצירת כתובות URL חתומות באופן פרוגרמטי באמצעות תחילית של כתובת URL
בדוגמאות הקוד הבאות אפשר לראות איך ליצור כתובות URL חתומות באופן פרוגרמטי באמצעות קידומת של כתובת URL.
המשך
Java
Python
יצירת כתובות URL חתומות בהתאמה אישית
כשכותבים קוד משלכם כדי ליצור כתובות URL חתומות, המטרה היא ליצור כתובות URL בפורמט או באלגוריתם הבאים. כל הפרמטרים של כתובת ה-URL הם תלויי-רישיות וחייבים להיות בסדר שמוצג:
https://example.com/foo?Expires=EXPIRATION&KeyName=KEY_NAME&Signature=SIGNATURE
כדי ליצור כתובות URL חתומות:
מוודאים שלכתובת ה-URL לחתימה אין פרמטר של
Signatureשאילתה.קובעים מתי כתובת ה-URL תפוג ומוסיפים פרמטר של שאילתה
Expiresעם זמן התפוגה הנדרש בשעון UTC (מספר השניות מאז 1.1.1970 בשעה 00:00:00 UTC). כדי למקסם את האבטחה, צריך להגדיר את הערך לתקופת הזמן הקצרה ביותר האפשרית לתרחיש השימוש. ככל שכתובת URL חתומה תקפה לזמן ארוך יותר, כך גדל הסיכון שהמשתמש שנתתם לו אותה ישתף אותה עם אחרים, בטעות או בדרך אחרת.מגדירים את שם המפתח. כתובת ה-URL צריכה להיות חתומה באמצעות מפתח של שירות הקצה העורפי או של קטגוריית קצה עורפי שמשרתת את כתובת ה-URL. מומלץ להשתמש במפתח שנוסף לאחרונה לרוטציית מפתחות. מוסיפים את המפתח לכתובת ה-URL על ידי צירוף
&KeyName=KEY_NAME. מחליפים אתKEY_NAMEבשם של המפתח שנבחר שנוצר ביצירת מפתחות של בקשות חתומות.חותמים על כתובת ה-URL. כדי ליצור את כתובת ה-URL החתומה: חשוב לוודא שפרמטרים של שאילתה מופיעים בסדר שמוצג לפני שלב 1, ולוודא שאין שינוי באותיות הרישיות בכתובת ה-URL החתומה.
א. מבצעים גיבוב של כתובת ה-URL כולה (כולל
http://אוhttps://בתחילת הכתובת ו-&KeyName...בסוף הכתובת) באמצעות HMAC-SHA1, על ידי שימוש במפתח הסודי שמתאים לשם המפתח שנבחר קודם. משתמשים במפתח הסודי הגולמי בגודל 16 בייט, ולא במפתח המקודד ב-base64url. מפענחים אותו אם צריך.ב. משתמשים ב-base64url encode כדי לקודד את התוצאה.
ג. מוסיפים את
&Signature=לכתובת ה-URL, ואחריו את החתימה המקודדת. לא להמיר את התווים האחרונים=של החתימה לפורמט עם קידוד של אחוזים,%3D.
שימוש בתחיליות של כתובות URL לכתובות URL חתומות
במקום לחתום על כתובת ה-URL המלאה של הבקשה עם פרמטרי השאילתה Expires ו-KeyName, אפשר לחתום רק על פרמטרי השאילתה URLPrefix, Expires ו-KeyName. האפשרות הזו מאפשרת לעשות שימוש חוזר בצירוף נתון של פרמטרים של שאילתה URLPrefix, Expires, KeyName ו-Signature, בדיוק כמו שהוא, בכמה כתובות URL שתואמות ל-URLPrefix, וכך לא צריך ליצור חתימה חדשה לכל כתובת URL נפרדת.
בדוגמה הבאה, הטקסט המודגש מראה את הפרמטרים שאתם חותמים עליהם. הפרמטר Signature מצורף כפרמטר האחרון של השאילתה, כרגיל.
https://media.example.com/videos/id/master.m3u8?userID=abc123&starting_profile=1&URLPrefix=aHR0cHM6Ly9tZWRpYS5leGFtcGxlLmNvbS92aWRlb3Mv&Expires=1566268009&KeyName=mySigningKey&Signature=8NBSdQGzvDftrOIa3WHpp646Iis=
בניגוד לחתימה על כתובת URL מלאה של בקשה, כשחותמים באמצעות URLPrefix לא חותמים על פרמטרים של שאילתה, ולכן אפשר לכלול פרמטרים של שאילתה בכתובת ה-URL באופן חופשי. בנוסף, בניגוד לחתימות של כתובות URL מלאות של בקשות, הפרמטרים הנוספים של השאילתה יכולים להופיע לפני ואחרי הפרמטרים של השאילתה שמרכיבים את החתימה. כתוצאה מכך, גם כתובת ה-URL הבאה היא כתובת URL תקינה עם קידומת של כתובת URL חתומה:
https://media.example.com/videos/id/master.m3u8?userID=abc123&URLPrefix=aHR0cHM6Ly9tZWRpYS5leGFtcGxlLmNvbS92aWRlb3Mv&Expires=1566268009&KeyName=mySigningKey&Signature=8NBSdQGzvDftrOIa3WHpp646Iis=&starting_profile=1
URLPrefix מציין קידומת של כתובת URL בקידוד Base64 שמתאימה לשימוש בכתובת URL, וכוללת את כל הנתיבים שהחתימה צריכה להיות תקפה לגביהם.
URLPrefix מקודד סכימה (http:// או https://), FQDN ונתיב אופציונלי. אפשר לסיים את הנתיב בתו /, אבל מומלץ לעשות זאת. הקידומת לא צריכה לכלול פרמטרים של שאילתה או מקטעים כמו ? או #.
לדוגמה, https://media.example.com/videos מתאים לבקשות לשני המיקומים הבאים:
https://media.example.com/videos?video_id=138183&user_id=138138https://media.example.com/videos/137138595?quality=low
הנתיב של הקידומת משמש כמחרוזת משנה של טקסט, ולא כנתיב של ספרייה.
לדוגמה, הקידומת https://example.com/data מעניקה גישה לשני המיקומים הבאים:
/data/file1/database
כדי להימנע מהטעות הזו, מומלץ לסיים את כל הקידומות ב-/, אלא אם אתם רוצים לסיים את הקידומת בשם קובץ חלקי כמו https://media.example.com/videos/123 כדי להעניק גישה ל:
/videos/123_chunk1/videos/123_chunk2/videos/123_chunkN
אם כתובת ה-URL המבוקשת לא תואמת ל-URLPrefix, Cloud CDN דוחה את הבקשה ומחזיר ללקוח את השגיאה HTTP 403.
אימות של כתובות URL חתומות
תהליך האימות של כתובת URL חתומה זהה בעצם לתהליך היצירה של כתובת URL חתומה. לדוגמה, נניח שרוצים לאמת את כתובת ה-URL החתומה הבאה:
https://example.com/PATH?Expires=EXPIRATION&KeyName=KEY_NAME&Signature=SIGNATURE
אפשר להשתמש במפתח הסודי שנקרא KEY_NAME כדי ליצור באופן עצמאי את החתימה של כתובת ה-URL הבאה:
https://example.com/PATH?Expires=EXPIRATION&KeyName=KEY_NAME
אחר כך תוכלו לוודא שהיא תואמת ל-SIGNATURE.
נניח שרוצים לאמת כתובת URL חתומה עם URLPrefix, כמו בדוגמה הבאה:
https://example.com/PATH?URLPrefix=URL_PREFIX&Expires=EXPIRATION&KeyName=KEY_NAME&Signature=SIGNATURE
קודם כול, מוודאים שהערך אחרי פענוח Base64 של URL_PREFIX
הוא קידומת של https://example.com/PATH. אם כן, תוכלו לחשב את החתימה עבור:
URLPrefix=URL_PREFIX&Expires=EXPIRATION&KeyName=KEY_NAME
אחר כך תוכלו לוודא שהיא תואמת ל-SIGNATURE.
בשיטות חתימה שמבוססות על כתובת URL, שבהן החתימה היא חלק מפרמטרים של שאילתה או מוטמעת כרכיב של נתיב כתובת ה-URL, החתימה והפרמטרים שקשורים אליה מוסרים מכתובת ה-URL לפני שהבקשה נשלחת למקור. כך נמנעות בעיות בניווט כשהמקור מטפל בבקשה. כדי לאמת את הבקשות האלה, אפשר לבדוק את כותרת הבקשה x-client-request-url, שכוללת את כתובת ה-URL המקורית (החתומות) של בקשת הלקוח לפני ההסרה של הרכיבים החתומים.
הסרת גישה ציבורית לקטגוריה של Cloud Storage
כדי שכתובות URL חתומות יגנו על התוכן בצורה נכונה, חשוב ששרת המקור לא יאפשר גישה ציבורית לתוכן הזה. כשמשתמשים בקטגוריה של Cloud Storage, גישה נפוצה היא להגדיר אובייקטים כציבוריים באופן זמני למטרות בדיקה. אחרי שמפעילים כתובות URL חתומות, חשוב להסיר את הרשאות הגישה allUsers (וגם allAuthenticatedUsers, אם רלוונטי) לקריאה (במילים אחרות, את התפקיד Storage Object Viewer של ניהול זהויות והרשאות גישה) בקטגוריה.
אחרי שמשביתים את הגישה הציבורית לקטגוריה, משתמשים פרטיים עדיין יכולים לגשת ל-Cloud Storage בלי כתובות URL חתומות אם יש להם הרשאת גישה, כמו הרשאת OWNER.
כדי להסיר גישת קריאה ציבורית allUsers לקטגוריה של Cloud Storage, צריך לבצע את הפעולה שמתוארת במאמר הגדרת כל האובייקטים בקטגוריה כקריאים באופן ציבורי.
הפצה ושימוש בכתובות URL חתומות
אפשר להפיץ את כתובת ה-URL שמוחזרת מ-Google Cloud CLI או שנוצרת על ידי הקוד המותאם אישית שלכם בהתאם לצרכים שלכם. מומלץ לחתום רק על כתובות URL מסוג HTTPS, כי HTTPS מספק העברה מאובטחת שמונעת יירוט של רכיב Signature בכתובת ה-URL החתומה. באופן דומה, חשוב לוודא שאתם מפיצים את כתובות ה-URL החתומות באמצעות פרוטוקולי העברה מאובטחים כמו TLS/HTTPS.