איך להגדיר כללי מטמון ב-Cloudflare בלי לחשוף מידע פרטי

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

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

לסווג נתיבים לפי קהל ומצב

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

בודקים כיצד שרת המקור שולח את הכותרות Cache-Control, Set-Cookie ו-Vary. עמוד אנונימי עדיין יכול להגדיר עוגייה בלתי מזיקה, ועמוד מותאם אישית עלול שלא להגדיר כותרת מגינה. בדיקת התגובה האמיתית אמינה יותר מהנחה לגבי ההתנהגות על סמך נתיב הכתובת בלבד.

לבנות כללים מצומצמים לפני כללים רחבים

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

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

להיזהר בדריסות של TTL בקצה

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

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

להריץ בדיקה של מבקר אנונימי מול משתמש מחובר

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

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

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

נתיב יכול להיראות ציבורי ובכל זאת להשתנות באופן בלתי נראה לפי כותרות הבקשה, המדינה, המכשיר או ניסוי A/B. אם שומרים במטמון ייצוג אחד לכולם, השפה או הגרסה הלא נכונה עלולות להגיע לאדם הלא נכון. לפני שמתכננים מפתח מטמון מותאם, מזהים במדויק איזה קלט משנה את תגובת ה-HTML. Cloudflare מתעדת אפשרויות למחרוזות שאילתה, לכותרות ולעוגיות, אבל הוספה של כל כותרת למפתח עלולה להרוס את יעילות המטמון וליצור שילובים בלתי צפויים.

בודקים שלושה מצבים שונים לכל נתיב חשוב: ביקור ראשון ללא עוגיות, ביקור אנונימי חוזר וביקור של משתמש מחובר. רושמים את סטטוס התגובה, Cache-Control, Set-Cookie, CF-Cache-Status כשהוא זמין, וטביעת אצבע קצרה של התוכן הגלוי. חוזרים על הבדיקה אחרי תיקון מערכתי ואחרי ניקוי ממוקד. זוהי שיטת בקרת איכות היפותטית, לא טענה לגבי ההגדרות של אתר מסוים.

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

לשמור על מהירות בלי לאבד אמון

שמירה במטמון של נכסים סטטיים מניבה לעיתים קרובות שיפורים מועילים בלי לגעת ב-HTML מותאם אישית. מבצעים שינויים בסוג נתיב אחד בכל פעם, מתעדים את החריגים ובודקים שוב אחרי עדכונים של מערכת ניהול התוכן או של מנגנון ההתחברות. הכתבה שלנו על עדכון האבטחה של Cloudflare עוסקת בסוגיית הגנה נפרדת; המדריך לסביבת בדיקות ב-WordPress עוסק בבדיקת שינויים לפני סביבת הייצור. עמודים מהירים שווים משהו רק אם הם מציגים את התוכן הנכון.