Cacha VPN-klassificeringen och håll dess ålder synlig
En observation, dess färskhet och din webbplats svar åldras i olika takt. Hållna åtskilda förblir en cachad klassificering ärlig om vad den vet.
En cachad klassificering sparar ett uppslag och fryser gårdagens omdöme i dagens beslut. Den verkliga jämförelsen är inte cache mot ingen cache: den är en observation, dess färskhet och det svar din webbplats valde. Tappar du gränsen mellan de tre börjar en optimering göra policy på egen hand. Reparationen är bokföring, inte ett bättre flöde.
Tre poster med tre olika klockor
En observation är fältet du fick, flödet den kom från och datasetversionen bakom. Färskhet är en egenskap hos cacheposten: när uppslaget kördes, när posten slutar betros och om den senaste uppdateringen returnerade något. Svaret är vad din webbplats gör åt det för den här förfrågan, det här kontot eller den här åtgärden. De produceras av olika ägare och de förfaller i olika takt, och därför förstör en rad som heter blocked skillnaden.
| 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 |
Två klockor förtjänar särskild omsorg. Ögonblicket då ditt uppslag kördes är inte ögonblicket då leverantören publicerade datasetet, och en operatör som läser raden senare måste veta vilken av de två varje värde kom från. Sätt utgång och uppdatering efter flödets dokumenterade uppdateringsmodell och efter kostnaden för att ha fel, aldrig efter en siffra lånad från en annan webbplats.
Behåll fältet, inte domen
MaxMinds dokumentation om anonyma IP-adresser är ett konkret exempel på ett flöde som skiljer anonym VPN, hostingleverantör, offentlig proxy och Tor-utgång i separata fält. Den dokumenterar också att ett oregistrerat VPN-subnät i stället kan dyka upp under hostingflaggan. Att platta till det till en enda boolean kastar bort den enda del en operatör senare skulle kunna granska.
Ingen av slutsatsriktningarna är säker. En hostingetikett bevisar inte att en tunnel användes, och avsaknaden av en VPN-flagga bevisar inte att inget satt mellan klienten och din tjänst. Det är två olika påståenden, och en enda boolean kan inte uttrycka något av dem.
Bind posten till adressen du verifierade
Bakom en omvänd proxy måste programmet använda den klientadresshantering som driftsättningen godkände. En vidarebefordringsheader som anroparen tillhandahåller får aldrig kunna välja någon annans cachade anseende.
Det felet är både ett korrekthetsfel och ett säkerhetsfel, eftersom en angripare som kontrollerar headern kan ärva en betrodd post eller fästa ett offer vid en dålig. Härled nyckeln från anslutningen som din egen infrastruktur avslutade, och registrera vilken härledning som användes. När flera proxys står framför, dokumentera kedjan i stället för att lita på den första header som verkar rimlig. Om kedjan är tvetydig, logga den härledda nyckeln och headern du avvisade, för det är den andra en incidentgenomgång kommer att fråga om.
Inga bevis är inte ett rent resultat
En timeout, ett felformat svar och en otillgänglig databas betyder var och en något annat än ett lyckat uppslag som inte matchade något. Representera dem som separata utfall, och bestäm i förväg vad den skyddade åtgärden gör när det inte finns några bevis alls. En skrivskyddad sida och en åtgärd på ett inloggat konto kan rimligen följa olika regler där.
Att behålla normal autentisering, eller be om en verifiering som stöds, är oftast ett bättre svar än att behandla ett avbrott som generellt tillstånd eller som en webbplatsövergripande blockering. Begränsa hur länge ett uppslag får köra och stoppa uppdateringsstormar med den mekanism integrationen stöder. När ett inaktuellt värde används under ett avbrott, märk det som inaktuellt vid beslutspunkten, och gör uppdateringens senaste misslyckande synligt så att ett långvarigt fel inte kan passera som en frisk post. Vilket valet än är, skriv det där policyn verkställs, inte i en kommentar bredvid uppslaget.
Lagring hör till samma beslut: behåll fälten den här funktionen behöver och granskningsspåret bakom dem, inte mer. En IP-cache behöver inte bli en webbläsarhistorik.
Acceptera fyra fall, inklusive en rättelse
Testa ett färskt resultat, ett utgånget resultat, ett misslyckat uppslag och en klassificering som rättades senare. Varje fall övar en annan gren, och bara det sista visar om en felaktig begränsning kan hävas.
Bekräfta sedan att en vanlig användare har en väg att begära granskning efter en felaktig blockering, eftersom flödet ibland kommer att ha fel och kön är en del av designen. Skriv de fyra fallen i runbooken med policyägarens namn bredvid. Designen förtjänar sin plats när den tar bort överflödiga uppslag, håller osäkerheten intakt och beslutet synligt ägt av en människa.