שימוש בכתובות URL חתומות

בדף הזה מופיעה סקירה כללית של כתובות 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 של HTTP‏ Cloud-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. אם מאבדים מפתח, צריך ליצור מפתח חדש.

כדי ליצור מפתח בקשה חתום, פועלים לפי השלבים הבאים.

המסוף

  1. נכנסים לדף Cloud CDN במסוף Google Cloud .

    מעבר אל Cloud CDN

  2. לוחצים על שם המקור שרוצים להוסיף לו את המפתח.
  3. בדף פרטי המקור, לוחצים על הלחצן עריכה.
  4. בקטע פרטים בסיסיים על המקור, לוחצים על הבא כדי לפתוח את הקטע כללים לגבי מארח ונתיב.
  5. בקטע Host and path rules (כללים לגבי מארח ונתיב), לוחצים על Next (הבא) כדי לפתוח את הקטע Cache performance (ביצועים של מטמון).
  6. בקטע Restricted content, בוחרים באפשרות Restrict access using signed URLs and signed cookies.

  7. לוחצים על הוספת מפתח חתימה.

    1. מציינים שם ייחודי למפתח החתימה החדש.

    2. בקטע שיטת יצירת מפתח, בוחרים באפשרות יצירה אוטומטית. אפשר גם ללחוץ על Let me enter ואז לציין ערך של מפתח חתימה.

      באפשרות הראשונה, מעתיקים את הערך של מפתח החתימה שנוצר באופן אוטומטי לקובץ פרטי, שבו אפשר להשתמש כדי ליצור כתובות URL חתומות.

    3. לוחצים על סיום.

    4. בקטע Cache entry maximum age (הגיל המקסימלי של רשומה במטמון), מזינים ערך ואז בוחרים יחידת זמן.

  8. לוחצים על סיום.

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. אם קוד התגובה לא זהה, בודקים שוב את