אימות תוכן

יש שלוש דרכים שבהן Cloud CDN יכול לעזור לכם לשלוט בגישה לתוכן ששמור במטמון:

  • כתובות URL חתומות מאפשרות להציג תגובות ממטמון מבוזר גלובלי של Google Cloudכשצריך לאשר בקשות. כל מי שיש לו את כתובת ה-URL החתומה יכול לגשת למשאב לפרק זמן מוגבל.
  • קובצי Cookie חתומים מאפשרים גם הם גישה למשאב לזמן מוגבל. הן שימושיות כשצריך לחתום על עשרות או מאות כתובות URL לכל משתמש.
  • אימות מקור פרטי מאפשר לכם להגביל את החיבורים לקטגוריות של אמזון Simple Storage Service ‏ (Amazon S3) או למאגרי אובייקטים תואמים אחרים, ולמנוע ממשתמשים גישה ישירה אליהם.

כתובות URL חתומות

כתובת URL חתומה היא כתובת URL עם הרשאה וזמן מוגבלים לשליחת בקשה.

תרחישים לדוגמה

בתרחישים מסוימים, יכול להיות שלא תרצו לדרוש מהמשתמשים חשבון Google כדי שיוכלו לגשת לתוכן ב-Cloud CDN, אבל תרצו לשלוט בגישה באמצעות הלוגיקה הספציפית לאפליקציה.

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

כדאי להשתמש בכתובות URL חתומות במקרים הבאים:

  • כדי להגביל את הגישה לקבצים ספציפיים, כמו קובץ להורדת התקנה.

  • כדי להציג למשתמשים אפליקציות לקוח שלא תומכות בקובצי Cookie.

איך פועלות כתובות URL חתומות

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

כשבקשה משתמשת בכתובת ה-URL החתומה שסיפקתם, הבקשה נחשבת כבקשה מורשית לקבל את התוכן המבוקש. כש-Cloud CDN מקבל בקשה עם חתימה לא תקינה לשירות מופעל, הבקשה נדחית והיא לא מועברת לעולם לשרת העורפי לטיפול.

בדרך כלל, כל מי שיש לו כתובת URL חתומה יכול להשתמש בה. עם זאת, כתובת URL חתומה מיועדת בדרך כלל לשימוש רק על ידי הלקוח שאליו נמסרה כתובת ה-URL. כדי לצמצם את הסיכון שכתובת ה-URL תשמש לקוח אחר, כתובות URL חתומות יפוגו בזמן שתבחרו. כדי למזער את הסיכון שכתובת URL חתומה תשותף, כדאי להגדיר שהתוקף שלה יפוג בהקדם האפשרי.

איך כתובות URL נחתמות

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

טיפול בכתובות URL חתומות

כשטיפול בכתובות URL חתומות מופעל בשרת עורפי, Cloud CDN מטפל בבקשות עם כתובות URL חתומות באופן מיוחד. באופן ספציפי, בקשות עם פרמטר שאילתה Signature נחשבות חתומות. כשמתקבלת בקשה כזו, Cloud CDN מאמת את הדברים הבאים:

  • שיטת ה-HTTP היא GET,‏ HEAD,‏ OPTIONS או TRACE.
  • הפרמטר Expires מוגדר לשעה בעתיד.
  • החתימה של הבקשה תואמת לחתימה שחושבה באמצעות המפתח שצוין.

אם אחת מהבדיקות האלה נכשלת, מוגשת תגובה מסוג 403 Forbidden. אחרת, הבקשה מועברת לשרת העורפי או מוגשת מהמטמון. בקשות OPTIONS ו-TRACE תמיד מועברות ישירות לשרת העורפי ולא מוצגות מהמטמון. כל הבקשות החתומות התקינות לכתובת URL בסיסית מסוימת (החלק שלפני הפרמטר Expires) חולקות את אותו ערך במטמון. תגובות לבקשות חתומות ולבקשות לא חתומות לא משתמשות באותם רשומות במטמון. התשובות נשמרות במטמון ומוצגות עד למועד התפוגה שהגדרתם.

תוכן שדורש בקשות חתומות מסומן לעיתים קרובות כתוכן שלא ניתן לשמור במטמון באמצעות הכותרת Cache-Control. כדי שאובייקטים כאלה יהיו תואמים ל-Cloud CDN בלי שיהיה צורך לבצע שינויים בקצה העורפי, מערכת Cloud CDN מבצעת החלפה של הכותרת Cache-Control כשהיא מגיבה לבקשות שמכילות כתובות URL חתומות תקינות. מערכת Cloud CDN מתייחסת לתוכן כאל תוכן שניתן לשמור במטמון, ומשתמשת בפרמטר max-age שהוגדר בהגדרות של Cloud CDN. התשובה שמוצגת עדיין כוללת את הכותרות Cache-Control שנוצרו בשרת העורפי.

אפשר להפיץ את כתובת ה-URL שמוחזרת מה-CLI של gcloud או שנוצרת על ידי הקוד המותאם אישית שלכם בהתאם לצורך. מומלץ לחתום רק על כתובות URL מסוג HTTPS, כי פרוטוקול HTTPS מספק העברה מאובטחת שמונעת יירוט של רכיב החתימה של כתובת ה-URL החתומה. באופן דומה, צריך להפיץ את כתובות ה-URL החתומות באמצעות פרוטוקולי העברה מאובטחים כמו TLS/HTTPS.

הוראות לשימוש בכתובות URL חתומות עם Cloud CDN מפורטות במאמר שימוש בכתובות URL חתומות.

קובצי Cookie חתומים

קובץ Cookie חתום הוא קובץ Cookie שמספק הרשאה מוגבלת וזמן מוגבל לשליחת בקשות לקבוצה של קבצים.

תרחישים לדוגמה

משתמשים בקובצי Cookie חתומים במקרים הבאים:

  • כדי לספק גישה לכמה קבצים מוגבלים.

  • כדי להימנע משינוי כתובות ה-URL הנוכחיות.

  • כדי להימנע מעדכון כתובות URL בכל פעם שמרעננים את ההרשאה לגישה לתוכן.

סטרימינג של מדיה באמצעות HLS ו-DASH

אם אתם מציגים תוכן של וידאו ואודיו באמצעות הפרוטוקולים HTTP Live Streaming‏ (HLS) או Dynamic Adaptive Streaming over HTTP‏ (DASH), בדרך כלל אתם יוצרים מניפסט שמכיל רשימה של כתובות URL לפלחי וידאו ואודיו. יכול להיות שיהיו לכם כמה מקרים של כל פלח כדי לספק קידודים שונים (codec, קצב העברת נתונים, רזולוציה) ללקוח.

אפשר להשתמש בכתובות URL חתומות של Cloud CDN כדי לחתום על כל אחת מכתובות ה-URL האלה ולאשר גישה אליהן, אבל יצירה דינמית של כל השילובים האפשריים על בסיס משתמשים היא מסובכת ומגדילה את העומס על מקור התוכן ואת מורכבות האפליקציה.

קובצי Cookie חתומים נועדו לפתור את הבעיה הזו. אתם יכולים לספק למשתמש קובץ Cookie חתום שמאשר לו לגשת לכל תוכן שתואם למדיניות (קידומת URL ותאריך תפוגה) בלי שתצטרכו ליצור או לחתום בנפרד על מניפסטים של מדיה. אפשר לרענן את גישת המשתמשים מעת לעת באמצעות ה-API של JavaScript‏ fetch() בניווט בדף או במנגנונים אחרים ברקע באפליקציות מובנות. האפשרות לרענן את גישת המשתמש מאפשרת לכם גם להשתמש בזמני תפוגה קצרים, וכך להקשות על המשתמשים לשתף תוכן מוגן.

אתם יכולים להנפיק את קובצי ה-Cookie האלה למשתמשים עם כמה לקוחות דפדפן ולקוחות אחרים שמשתמשים ב-HTTP, כמו ExoPlayer של Google ו-AVPlayer של iOS.

הורדות בינאריות (גיימינג)

בדומה להזרמת מדיה, אם אתם מספקים הורדות של לקוחות משחקים, יכול להיות שתצטרכו לחלק תיקונים או נתוני משחקים גדולים של כמה גיגה-בייט לחלקים קטנים יותר כדי לתמוך בשמירה במטמון, בביטול תוקף ובמקביליות ברמה גבוהה יותר.

החלקים האלה מפורטים בדרך כלל בקובץ מניפסט. קובצי Cookie חתומים מאפשרים לכם לאשר גישה להורדות האלה רק למשתמשים מאומתים, בלי שתצטרכו לבצע שינויים במניפסט, ובלי לוותר על היתרונות של שמירת נתונים במטמון ב-Cloud CDN (כמו בכתובות URL חתומות).

איך פועלים קובצי Cookie חתומים

הגדרה והנפקה של קובצי Cookie חתומים מתבצעות בשלושה שלבים:

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

‫Cloud CDN מאמת את קובצי ה-Cookie החתומים האלה כשהם נכללים בבקשות.

אתם יכולים למנוע ממשתמשים לעקוף את אמצעי הבקרה שלכם על קובצי Cookie חתומים כשאתם משתמשים בקטגוריה של Cloud Storage. כדי לעשות זאת, צריך להגביל את הגישה לקטגוריה הבסיסית על ידי הסרת התפקיד allUsers והענקת גישת קריאה לחשבון השירות של Cloud CDN לקטגוריה.

באופן דומה, מכונות וירטואליות (VM) צריכות לאמת את החתימות בכל בקשה חתומה שהן משרתות.

הוראות לשימוש בקובצי Cookie חתומים עם Cloud CDN זמינות במאמר שימוש בקובצי Cookie חתומים.

אימות של מקור פרטי

אימות מקור פרטי מעניק ל-Cloud CDN גישה לטווח ארוך לקטגוריות פרטיות של Amazon S3 או למאגרי אובייקטים תואמים. לאחר מכן, Cloud CDN יכול להציג תוכן מהמקורות האלה בלי להשתמש בגישת קריאה ציבורית.

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

אימות מקור פרטי נתמך ב-Cloud CDN עם מאזן עומסים גלובלי חיצוני של אפליקציות (ALB) או עם מאזן עומסים קלאסי של אפליקציות (ALB).

הוראות לשימוש באימות מקור פרטי עם Cloud CDN מופיעות במאמר הגדרת אימות מקור פרטי.

הערות ומגבלות

  • האחריות הבלעדית לעמידה בדרישות בנושא הסכמה ופרטיות שנדרשות לקובצי ה-Cookie החתומים מוטלת עליך. אתם מנפיקים ומנהלים את קובצי ה-Cookie החתומים, ולא Google.

  • אם אתם משתמשים גם בכתובות URL חתומות וגם בקובצי Cookie חתומים כדי לשלוט בגישה לאותם קבצים, וצופה משתמש בכתובת URL חתומה כדי לבקש קובץ, Cloud CDN קובע אם להחזיר את הקובץ לצופה על סמך כתובת ה-URL החתומה בלבד. ‫Cloud CDN מתייחס רק לקובצי Cookie חתומים אם כתובת ה-URL לא חתומה.

  • אם הגדרתם את השירות שלכם לבקשות חתומות, וכתובת ה-URL כוללת את Signature כפרמטר של שאילתה, Cloud CDN ינסה לפרש את כתובת ה-URL ככתובת URL חתומה. אם Cloud CDN מנסה להתייחס לכתובת ה-URL שלכם כאל כתובת URL חתומה כשלא התכוונתם לכך, סביר להניח שכתובת ה-URL שלכם לא חתומה בצורה תקינה, ולכן Cloud CDN דוחה אותה.

  • בדרך כלל, דפדפנים ולקוחות אחרים אוכפים מגבלות על גודל קובץ Cookie (4KB לכל קובץ Cookie) ועל ספירה כוללת של 50 לכל דומיין, בהתאם ל-RFC 6265. כדאי לבדוק את המטען הייעודי (payload) הכולל של קובצי ה-Cookie שנשלחים מהדומיין שלהם.

  • חלות מגבלות והגבלות של Cloud CDN, כולל מקסימום של שלושה מפתחות חתימה לבקשות לכל קצה עורפי.

  • אין חיוב שונה על בקשות חתומות לעומת בקשות קיימות של Cloud CDN. עם זאת, על בקשות שנכשלו (נדחו), כמו בקשות עם חתימות שתוקפן פג או חתימות לא תקינות, עדיין חלים חיובים על חיפוש במטמון.

המאמרים הבאים