طبقهبندی 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 ثبتنشده میتواند در عوض زیر پرچم میزبانی ظاهر شود. مسطح کردن آن در یک boolean تنها بخشی را دور میریزد که اپراتور بعداً میتوانست حسابرسی کند.
هیچیک از دو جهت استنتاج ایمن نیست. برچسب میزبانی ثابت نمیکند که تونلی استفاده شده است، و نبود پرچم VPN ثابت نمیکند که چیزی میان کلاینت و سرویس شما نبوده است. اینها دو ادعای متفاوتاند و یک boolean نمیتواند هیچیک را بیان کند.
ورودی را به نشانیای که تأیید کردهاید گره بزنید
در پشت یک پروکسی معکوس، برنامه باید از مدیریت نشانی کلاینت که استقرار تأیید کرده استفاده کند. سرصفحه ارجاعی که فراخواننده ارائه میدهد هرگز نباید بتواند اعتبار ذخیرهشده کس دیگری را انتخاب کند.
این شکست هم باگ درستی است و هم باگ امنیتی، زیرا مهاجمی که سرصفحه را کنترل میکند میتواند یک ورودی مورد اعتماد را به ارث ببرد یا قربانی را به ورودی بدی سنجاق کند. کلید را از اتصالی استخراج کنید که زیرساخت خودتان آن را پایان داده است، و ثبت کنید کدام استخراج استفاده شده. وقتی چند پروکسی جلو هستند، زنجیره را مستند کنید نه اینکه به اولین سرصفحه باورپذیر اعتماد کنید. اگر زنجیره مبهم است، کلید استخراجشده و سرصفحهای که رد کردهاید را ثبت کنید، چون بازبینی حادثه دومی را میپرسد.
نبود شواهد نتیجه پاک نیست
یک وقفه زمانی، یک پاسخ بدشکل و یک پایگاه داده در دسترس نبودن هر یک معنایی متفاوت از یک جستجوی موفق دارند که با چیزی مطابقت نداشته است. آنها را به عنوان پیامدهای جداگانه نمایش دهید و از پیش تصمیم بگیرید اقدام محافظتشده وقتی هیچ شاهدی نیست چه میکند. صفحهای فقط خواندنی و اقدامی در یک حساب واردشده میتوانند بهطور معقول قواعد متفاوتی را در آنجا دنبال کنند.
حفظ احراز هویت عادی، یا درخواست تأیید پشتیبانیشده، معمولاً پاسخ بهتری است از اینکه قطعی را اجازه عمومی یا ممنوعیت در کل سایت تلقی کنید. محدود کنید جستجو چقدر میتواند طول بکشد و طوفانهای تازهسازی را با هر سازوکاری که یکپارچهسازی پشتیبانی میکند متوقف کنید. وقتی در زمان قطعی از مقدار کهنه استفاده میشود، آن را در نقطه تصمیم کهنه برچسب بزنید و آخرین شکست تازهسازی را آشکار کنید تا یک نقص دیرپا بهعنوان ورودی سالم تلقی نشود. هر انتخابی که باشد، آن را جایی بنویسید که سیاست اجرا میشود نه در توضیحی کنار جستجو.
نگهداری بخشی از همان تصمیم است: فیلدهایی که این کارکرد لازم دارد و ردپای بازبینی پشت آنها را نگه دارید، نه بیشتر. حافظه پنهان IP لازم نیست تاریخچه مرور شود.
چهار حالت را بپذیرید، از جمله یک اصلاح
یک نتیجه تازه، یک نتیجه منقضی، یک جستجوی ناموفق و یک طبقهبندی را که بعداً اصلاح شده آزمون کنید. هر یک شاخهای متفاوت را میآزماید و تنها آخری نشان میدهد آیا محدودیت اشتباه قابل بازگردانی است.
سپس تأیید کنید که کاربر عادی راهی برای درخواست بازبینی پس از یک مسدودسازی نادرست دارد، زیرا خوراک گاهی اشتباه خواهد بود و صف بخشی از طراحی است. چهار حالت را همراه با نام مالک سیاست در runbook بنویسید. طراحی زمانی جای خود را مییابد که جستجوهای زائد را حذف میکند و در همان حال عدم قطعیت را دستنخورده نگه میدارد و تصمیم آشکارا در اختیار یک انسان میماند.