Emmagatzemeu la classificació de VPN i manteniu-ne l'edat visible
Una observació, la seva frescor i la resposta del vostre lloc envelleixen a ritmes diferents. Si es mantenen separades, una classificació emmagatzemada continua sent honesta sobre el que sap.
Una classificació emmagatzemada estalvia una consulta i congela l'opinió d'ahir dins la decisió d'avui. La comparació real no és memòria cau contra absència de memòria cau: és una observació, la seva frescor i la resposta que el vostre lloc ha triat. Perdeu la frontera entre aquestes tres i una optimització comença a fer política pel seu compte. La reparació és comptabilitat, no un feed millor.
Tres registres amb tres rellotges diferents
Una observació és el camp que heu rebut, el feed d'on ve i la versió del conjunt de dades que hi ha al darrere. La frescor és una propietat de l'entrada de memòria cau: quan es va executar la consulta, quan l'entrada deixa de ser de confiança i si l'última actualització ha retornat res. La resposta és el que fa el vostre lloc sobre això per a aquesta petició, aquest compte o aquesta acció. Les produeixen propietaris diferents i decauen a ritmes diferents, i per això una fila anomenada blocked destrueix la distinció.
| 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 |
Dos rellotges mereixen una cura especial. El moment en què es va executar la vostra consulta no és el moment en què el proveïdor va publicar el conjunt de dades, i un operador que llegeix la fila més tard ha de saber de quin dels dos ve cada valor. Fixeu la caducitat i l'actualització segons el model d'actualització documentat del feed i segons el cost d'equivocar-se, mai segons un número manllevat d'un altre lloc.
Guardeu el camp, no el veredicte
La documentació de MaxMind sobre IP anònimes és un exemple concret d'un feed que separa VPN anònima, proveïdor d'allotjament, proxy públic i sortida de Tor en camps diferents. També documenta que una subxarxa de VPN no registrada pot aparèixer en canvi sota la marca d'allotjament. Aplanar-ho en un sol booleà llença l'única part que un operador podria auditar més tard.
Cap de les dues direccions d'inferència és segura. Una etiqueta d'allotjament no estableix que s'hagi utilitzat un túnel, i l'absència d'una marca de VPN no estableix que no hi hagués res entre el client i el vostre servei. Són dues afirmacions diferents, i un sol booleà no pot expressar cap de les dues.
Lligueu l'entrada a l'adreça que heu verificat
Darrere d'un proxy invers, l'aplicació ha d'utilitzar el tractament d'adreces de client que el desplegament ha aprovat. Una capçalera de reenviament proporcionada pel cridador no ha de poder mai seleccionar la reputació emmagatzemada d'una altra persona.
Aquest fracàs és alhora un error de correcció i de seguretat, perquè un atacant que controla la capçalera pot heretar una entrada de confiança o fixar una víctima a una de dolenta. Deriveu la clau de la connexió que ha acabat la vostra pròpia infraestructura, i registreu quina derivació s'ha utilitzat. Quan hi ha diversos proxys al davant, documenteu la cadena en lloc de confiar en la primera capçalera que sembli plausible. Si la cadena és ambigua, registreu la clau derivada i la capçalera que heu rebutjat, perquè la segona és el que preguntarà una revisió d'incident.
Cap evidència no és un resultat net
Un temps d'espera, una resposta malformada i una base de dades no disponible signifiquen cadascun una cosa diferent d'una consulta reeixida que no ha coincidit amb res. Representeu-los com a resultats separats i decidiu per endavant què fa l'acció protegida quan no hi ha cap evidència. Una pàgina només de lectura i una acció en un compte autenticat poden raonablement seguir regles diferents.
Mantenir l'autenticació normal, o demanar una verificació admesa, sol ser una resposta millor que tractar una caiguda com un permís general o com una prohibició per a tot el lloc. Limiteu quant de temps pot durar una consulta i atureu les tempestes d'actualització amb el mecanisme que admeti la integració. Quan s'utilitza un valor obsolet durant una caiguda, etiqueteu-lo com a obsolet en el punt de decisió, i feu visible l'últim fracàs de l'actualització perquè una avaria llarga no pugui passar per una entrada saludable. Sigui quina sigui l'elecció, escriviu-la on s'aplica la política i no en un comentari al costat de la consulta.
La retenció pertany a la mateixa decisió: guardeu els camps que aquesta funció necessita i el rastre de revisió al darrere, res més. Una memòria cau d'IP no ha de convertir-se en un historial de navegació.
Accepteu quatre casos, inclosa una correcció
Proveu un resultat fresc, un resultat caducat, una consulta fallida i una classificació que després s'ha corregit. Cadascun exerceix una branca diferent, i només l'últim mostra si una restricció equivocada es pot desfer.
Després confirmeu que un usuari corrent té una via per demanar revisió després d'un bloqueig equivocat, perquè el feed de vegades s'equivocarà i la cua forma part del disseny. Escriviu els quatre casos al runbook amb el nom del propietari de la política al costat. El disseny guanya el seu lloc quan elimina consultes redundants tot mantenint la incertesa intacta i la decisió visiblement en mans d'una persona.