Cloud CDN יכול לעזור לכם לשלוט בגישה לתוכן ששמור במטמון בדרכים הבאות:
- כתובות URL חתומות מאפשרות להציג תגובות ממטמון מבוזר גלובלי של Google Cloudכשצריך לאשר בקשות. כל מי שיש לו את כתובת ה-URL החתומה יכול לגשת למשאב לפרק זמן מוגבל.
- קובצי Cookie חתומים מאפשרים גם הם גישה למשאב לזמן מוגבל. הן שימושיות כשצריך לחתום על עשרות או מאות כתובות URL לכל משתמש.
- גישה לקטגוריות פרטיות מאפשרת להגביל את הגישה לתוכן שמאוחסן בקטגוריות פרטיות, וכך לוודא שהגישה לתוכן הפרטי מתבצעת רק דרך Cloud CDN או Cloud Load Balancing.
- אימות מקור פרטי מאפשר לכם להגביל את החיבורים לקטגוריות של Amazon 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 מאמת את הדברים הבאים:
- ה-method של HTTP היא
GET,HEAD,OPTIONSאוTRACE. - הפרמטר
Expiresמוגדר לזמן עתידי. - החתימה של הבקשה תואמת לחתימה שחושבה באמצעות המפתח שצוין.
אם אחת מהבדיקות האלה נכשלת, מוחזרת תגובה מסוג 403 Forbidden. אחרת, הבקשה מועברת דרך שרת proxy לקצה העורפי או מוגשת מהמטמון.
בקשות 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 חתומים מתבצעות בשלושה שלבים:
- יוצרים מפתח חתימה לשירות הקצה העורפי הנתון.
- יוצרים ערך של קובץ Cookie עם קידומת כתובת ה-URL המותרת, תאריך התפוגה, שם המפתח והחתימה הקריפטוגרפית.
- מנפיקים את קובץ ה-Cookie בקוד האפליקציה.
מערכת Cloud CDN מאמתת את קובצי ה-Cookie החתומים האלה כשהם נכללים בבקשות.
אתם יכולים למנוע ממשתמשים לעקוף את אמצעי הבקרה שלכם על קובצי Cookie חתומים כשאתם משתמשים בקטגוריה של Cloud Storage. כדי לעשות זאת, צריך להגביל את הגישה לקטגוריה הבסיסית על ידי הסרת התפקיד allUsers והענקת גישת קריאה לקטגוריה לחשבון השירות של Cloud CDN.
באופן דומה, המכונות הווירטואליות (VM) צריכות לאמת את החתימות בכל בקשה חתומה שהן משרתות.
הוראות לשימוש בקובצי Cookie חתומים עם Cloud CDN מפורטות במאמר שימוש בקובצי Cookie חתומים.
גישה לקטגוריה פרטית
גישה לקטגוריות פרטיות מאפשרת גישה לתוכן פרטי רק דרך Cloud CDN או Cloud Load Balancing. התכונה הזו מאפשרת לכם לשלוט יותר בהצגת התוכן שלכם, ועוזרת להפוך את התהליך למאובטח יותר. במקום להפוך את קטגוריית האחסון לנגישה באופן ציבורי, מה שחושף אותה לכל אחד באינטרנט, רק Cloud CDN יכול לגשת לתוכן ולספק אותו לפי הצורך. Google Cloud
גישה פרטית לקטגוריות של Cloud Storage נתמכת ב-Cloud CDN עם מאזן עומסים גלובלי חיצוני של אפליקציות (ALB) או עם מאזן עומסים קלאסי של אפליקציות.
הוראות לשימוש בגישה לקטגוריות פרטיות עם Cloud CDN מופיעות במאמר הגדרת גישה לקטגוריות פרטיות לקטגוריות של Cloud Storage.
אימות של מקור פרטי
אימות מקור פרטי מעניק ל-Cloud CDN גישה לטווח ארוך לקטגוריות פרטיות של Amazon S3 או למאגרי אובייקטים תואמים. לאחר מכן, Cloud CDN יכול להציג תוכן מהמקורות האלה בלי להשתמש בגישת קריאה ציבורית.
אימות מקור פרטי פונה למקור, בעוד שכתובות URL חתומות וקובצי Cookie חתומים פונים ללקוח. אפשר להפעיל את שניהם לאותו תוכן. אימות מקור פרטי מגביל את הגישה של שירותים שאינם Cloud CDN או Cloud Load Balancing למקורות ולתוכן שלכם. כתובות URL חתומות וקובצי Cookie קובעים לאילו משתמשים יש גישה ל-Cloud CDN.
יש תמיכה באימות מקור פרטי ב-Cloud CDN עם מאזן עומסים גלובלי חיצוני של אפליקציות (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 קובצי Cookie לכל דומיין, בהתאם ל-RFC 6265. כדאי לבדוק את המטען הייעודי (payload) הכולל של קובצי ה-Cookie שנשלחים מהדומיין שלהם.
חלות מגבלות והגבלות של Cloud CDN, כולל מקסימום של שלושה מפתחות של בקשות חתומות לכל קצה עורפי.
אין חיוב שונה על בקשות חתומות בהשוואה לבקשות קיימות של Cloud CDN. עם זאת, בקשות שנכשלו (נדחו), כמו בקשות עם חתימות שתוקפן פג או חתימות לא תקינות, עדיין מחויבות בחיפוש במטמון.
המאמרים הבאים
- מידע נוסף על שיטות מומלצות זמין במאמר שיטות מומלצות לאבטחת אתרים.