Puneți în cache clasificarea VPN și păstrați-i vârsta vizibilă
O observație, prospețimea ei și răspunsul site-ului dumneavoastră îmbătrânesc în ritmuri diferite. Ținute separat, o clasificare din cache rămâne onestă cu privire la ce știe.
O clasificare pusă în cache economisește o interogare și îngheață opinia de ieri în decizia de azi. Comparația reală nu este cache contra lipsă de cache: este o observație, prospețimea ei și răspunsul pe care l-a ales site-ul dumneavoastră. Pierdeți granița dintre aceste trei și o optimizare începe să facă politică de la sine. Reparația este contabilitate, nu un feed mai bun.
Trei înregistrări cu trei ceasuri diferite
O observație este câmpul pe care l-ați primit, feed-ul din care a venit și versiunea setului de date din spate. Prospețimea este o proprietate a intrării din cache: când a rulat interogarea, când intrarea nu mai este de încredere și dacă ultima reîmprospătare a returnat ceva. Răspunsul este ce face site-ul dumneavoastră în privința asta pentru această cerere, acest cont sau această acțiune. Sunt produse de proprietari diferiți și se degradează în ritmuri diferite, de aceea un singur rând numit blocked distruge distincția.
| 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 |
Două ceasuri merită o grijă deosebită. Momentul în care a rulat interogarea dumneavoastră nu este momentul în care furnizorul a publicat setul de date, iar un operator care citește rândul mai târziu trebuie să știe din care dintre cele două provine fiecare valoare. Stabiliți expirarea și reîmprospătarea după modelul de actualizare documentat al feed-ului și după costul unei greșeli, niciodată după un număr împrumutat de la alt site.
Păstrați câmpul, nu verdictul
Documentația MaxMind despre IP-uri anonime este un exemplu concret de feed care separă VPN anonim, furnizor de găzduire, proxy public și ieșire Tor în câmpuri distincte. Documentează și că o subrețea VPN neînregistrată poate apărea în schimb sub steagul de găzduire. Aplatizarea acestui lucru într-un singur boolean aruncă singura parte pe care un operator ar putea-o audita mai târziu.
Nicio direcție de inferență nu este sigură. O etichetă de găzduire nu stabilește că s-a folosit un tunel, iar absența unui steag VPN nu stabilește că nimic nu a stat între client și serviciul dumneavoastră. Sunt două afirmații diferite, iar un singur boolean nu poate exprima niciuna dintre ele.
Legați intrarea de adresa pe care ați verificat-o
În spatele unui proxy invers, aplicația trebuie să folosească tratarea adreselor de client aprobată de implementare. Un antet de redirecționare furnizat de apelant nu trebuie să poată selecta niciodată reputația din cache a altcuiva.
Acea defecțiune este atât o eroare de corectitudine, cât și de securitate, pentru că un atacator care controlează antetul poate moșteni o intrare de încredere sau poate fixa o victimă la una proastă. Derivați cheia din conexiunea încheiată de propria infrastructură și înregistrați ce derivare a fost folosită. Când în față stau mai multe proxy-uri, documentați lanțul în loc să vă încredeți în primul antet care pare plauzibil. Dacă lanțul este ambiguu, înregistrați cheia derivată și antetul pe care l-ați respins, pentru că al doilea este cel despre care va întreba o analiză de incident.
Absența dovezilor nu este un rezultat curat
Un timeout, un răspuns malformat și o bază de date indisponibilă înseamnă fiecare altceva decât o interogare reușită care nu s-a potrivit cu nimic. Reprezentați-le ca rezultate separate și decideți dinainte ce face acțiunea protejată când nu există nicio dovadă. O pagină doar pentru citire și o acțiune pe un cont autentificat pot urma în mod rezonabil reguli diferite.
Păstrarea autentificării normale, sau cererea unei verificări acceptate, este de obicei un răspuns mai bun decât tratarea unei căderi ca permisiune generală sau ca interdicție pentru tot site-ul. Limitați cât poate dura o interogare și opriți furtunile de reîmprospătare cu mecanismul pe care îl acceptă integrarea. Când în timpul unei căderi se folosește o valoare învechită, etichetați-o ca învechită în punctul de decizie și faceți vizibil ultimul eșec al reîmprospătării, ca o defecțiune lungă să nu treacă drept intrare sănătoasă. Orice alegere ar fi, scrieți-o acolo unde politica este aplicată, nu într-un comentariu de lângă interogare.
Retenția aparține aceleiași decizii: păstrați câmpurile de care are nevoie această funcție și urma de revizuire din spatele lor, nimic mai mult. Un cache de IP nu trebuie să devină istoric de navigare.
Acceptați patru cazuri, inclusiv o corectare
Testați un rezultat proaspăt, un rezultat expirat, o interogare eșuată și o clasificare corectată mai târziu. Fiecare exersează o ramură diferită, iar doar ultimul arată dacă o restricție greșită poate fi anulată.
Apoi confirmați că un utilizator obișnuit are o cale de a cere revizuire după o blocare greșită, pentru că feed-ul uneori va greși, iar coada face parte din design. Scrieți cele patru cazuri în runbook cu numele proprietarului politicii alături. Designul își câștigă locul când elimină interogările redundante păstrând incertitudinea intactă și decizia vizibil în mâna unei persoane.