מטמון את סיווג ה-VPN והשאר את גילו גלוי
תצפית, הטריות שלה והתגובה של האתר שלך מזדקנות בקצבים שונים. כשהן נשמרות בנפרד, סיווג שמור במטמון נשאר כן לגבי מה שהוא יודע.
סיווג השמור במטמון חוסך חיפוש אחד ומקפיא את דעת אתמול בתוך ההחלטה של היום. ההשוואה האמיתית אינה מטמון מול היעדר מטמון: היא תצפית, הטריות שלה והתגובה שהאתר שלך בחר. אם הגבול בין השלושה הולך לאיבוד, אופטימיזציה מתחילה לעשות מדיניות בעצמה. התיקון הוא הנהלת חשבונות, לא פיד טוב יותר.
שלושה רשומות עם שלושה שעונים שונים
תצפית היא השדה שקיבלת, הפיד שממנו הוא הגיע וגרסת מערך הנתונים שמאחוריו. טריות היא תכונה של רשומת המטמון: מתי רץ החיפוש, מתי מפסיקים לסמוך על הרשומה והאם הרענון האחרון החזיר משהו. התגובה היא מה שהאתר שלך עושה בקשר לזה עבור הבקשה הזאת, החשבון הזה או הפעולה הזאת. שונים הבעלים שמייצרים אותן והן מתכלות בקצבים שונים, ולכן שורה אחת בשם blocked הורסת את ההבחנה.
| Record | Who owns it | How long it should live | Damage when it is folded into another row |
|---|---|---|---|
| The observation | the feed's operator | until a newer dataset version replaces it | a stale lookup becomes indistinguishable from a fresh one |
| Its freshness | the application | one request's tolerance for age | a failed refresh hides behind a cache hit |
| The response | whoever owns the site policy | until that policy is reviewed | a feed outage turns into an indefinite block |
שני שעונים ראויים לתשומת לב מיוחדת. הרגע שבו רץ החיפוש שלך אינו הרגע שבו הספק פרסם את מערך הנתונים, ומי שקורא את השורה מאוחר יותר צריך לדעת מאיזה מן השניים הגיע כל ערך. קבע תפוגה ורענון לפי מודל העדכון המתועד של הפיד ולפי מחיר הטעות, ולעולם לא לפי מספר שהושאל מאתר אחר.
שמור את השדה, לא את הפסיקה
התיעוד של MaxMind על כתובות IP אנונימיות הוא דוגמה קונקרטית אחת לפיד שמפריד בין VPN אנונימי, ספק אחסון, פרוקסי ציבורי ויציאת Tor לשדות נפרדים. הוא גם מתעד שתת-רשת VPN לא רשומה יכולה להופיע במקום זאת תחת דגל האחסון. השטחת זה לבוליאני אחד זורק את החלק היחיד שמפעיל היה יכול לבקר אחר כך.
אף אחד משני כיווני ההסקה אינו בטוח. תווית אחסון אינה מוכיחה שהשתמשו במנהרה, והיעדר דגל VPN אינו מוכיח ששום דבר לא ישב בין הלקוח לשירות שלך. אלו שתי טענות שונות, ובוליאני אחד אינו יכול לבטא אף אחת מהן.
קשר את הרשומה לכתובת שאימתת
מאחורי פרוקסי הפוך, היישום חייב להשתמש בטיפול בכתובת הלקוח שהפריסה אישרה. כותרת העברה שסיפק הקורא לא תוכל לעולם לבחור את המוניטין השמור של מישהו אחר.
הכשל הזה הוא גם באג נכונות וגם באג אבטחה, משום שתוקף ששולט בכותרת יכול לרשת רשומה מהימנה או להצמיד קרבן לרשומה גרועה. גזור את המפתח מהחיבור שהתשתית שלך סיימה, ותעד איזו גזירה שימשה. כשיש כמה פרוקסים מלפנים, תעד את השרשרת במקום לסמוך על הכותרת הראשונה שנראית סבירה. אם השרשרת דו-משמעית, רשום את המפתח שנגזר ואת הכותרת שדחית, כי בשנייה תשאל סקירת תקרית.
היעדר ראיות אינו תוצאה נקייה
פסק זמן, תגובה פגומה ומסד נתונים לא זמין משמעותם כל אחד משהו אחר מחיפוש מוצלח שלא תאם דבר. הצג אותם כתוצאות נפרדות, והחלט מראש מה עושה הפעולה המוגנת כשאין ראיות כלל. דף לקריאה בלבד ופעולה בחשבון מחובר יכולים לנהוג בכללים שונים באופן סביר.
שמירה על אימות רגיל, או בקשה לאימות נתמך, היא בדרך כלל תשובה טובה יותר מאשר להתייחס לתקלה כהיתר גורפת או כחסימה לכל האתר. הגבל כמה זמן חיפוש רשאי לרוץ ועצור סערות רענון בכל מנגנון שהאינטגרציה תומכת בו. כשמשתמשים בערך מיושן בזמן תקלה, סמן אותו כמיושן בנקודת ההחלטה, והפוך את הכשל האחרון של הרענון לגלוי כדי שתקלה ממושכת לא תעבור כרשומה בריאה. יהיה הבחירה אשר תהיה, כתוב אותה במקום שבו המדיניות נאכפת ולא בהערה לצד החיפוש.
השמירה שייכת לאותה החלטה: החזק את השדות שהפונקציה הזאת צריכה ואת עקבות הביקורת שמאחוריהם, לא יותר. מטמון IP אינו חייב להפוך להיסטוריית גלישה.
קבל ארבעה מקרים, כולל תיקון
בדוק תוצאה טרייה, תוצאה שפגה, חיפוש שנכשל וסיווג שתוקן מאוחר יותר. כל אחד מתרגל ענף אחר, ורק האחרון מראה אם אפשר לבטל הגבלה מוטעית.
לאחר מכן ודא שלמשתמש רגיל יש מסלול לבקש סקירה אחרי חסימה שגויה, כי הפיד יפשל לפעמים והתור הוא חלק מהתכנון. כתוב את ארבעת המקרים ב-runbook עם שמו של בעל המדיניות לצידם. התכנון זוכה במקומו כשהוא מסיר חיפושים מיותרים תוך שמירה על אי-הוודאות ועל כך שההחלטה נמצאת באופן גלוי בידי אדם.