Cache de VPN-classificatie en houd de leeftijd zichtbaar
Een observatie, de versheid ervan en de reactie van uw site verouderen in verschillend tempo. Apart gehouden blijft een gecachte classificatie eerlijk over wat ze weet.
Een gecachte classificatie bespaart een lookup en bevriest het oordeel van gisteren in de beslissing van vandaag. De echte vergelijking is niet cache tegen geen cache: het is een observatie, de versheid ervan en de reactie die uw site koos. Verliest u de grens tussen die drie, dan gaat een optimalisatie zelf beleid maken. De reparatie is boekhouding, niet een betere feed.
Drie records met drie verschillende klokken
Een observatie is het veld dat u ontving, de feed waar het vandaan kwam en de datasetversie erachter. Versheid is een eigenschap van het cache-item: wanneer de lookup liep, wanneer het item niet meer wordt vertrouwd en of de laatste vernieuwing iets teruggaf. De reactie is wat uw site erover doet voor dit verzoek, dit account of deze actie. Ze worden door verschillende eigenaren geproduceerd en ze vervallen in verschillend tempo, daarom vernietigt één rij met de naam blocked het onderscheid.
| 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 |
Twee klokken verdienen bijzondere zorg. Het moment waarop uw lookup liep is niet het moment waarop de provider de dataset publiceerde, en een operator die de rij later leest moet weten van welke van de twee elke waarde kwam. Stel verval en vernieuwing in volgens het gedocumenteerde updatemodel van de feed en volgens de kosten van een fout, nooit volgens een getal dat van een andere site is geleend.
Bewaar het veld, niet het vonnis
De documentatie van MaxMind over anonieme IP's is een concreet voorbeeld van een feed die anonieme VPN, hostingprovider, openbare proxy en Tor-uitgang in aparte velden scheidt. Ze documenteert ook dat een niet-geregistreerd VPN-subnet in plaats daarvan onder de hostingvlag kan opduiken. Dat plat slaan tot één boolean gooit het enige deel weg dat een operator later zou kunnen auditen.
Geen van beide afleidingsrichtingen is veilig. Een hostinglabel bewijst niet dat een tunnel werd gebruikt, en het ontbreken van een VPN-vlag bewijst niet dat er niets tussen de client en uw dienst zat. Dat zijn twee verschillende beweringen, en één boolean kan geen van beide uitdrukken.
Koppel het item aan het adres dat u heeft geverifieerd
Achter een reverse proxy moet de applicatie de clientadresafhandeling gebruiken die de uitrol heeft goedgekeurd. Een door de aanroeper geleverde forwarding-header mag nooit de gecachte reputatie van iemand anders kunnen selecteren.
Die fout is zowel een correctheids- als een beveiligingsfout, want een aanvaller die de header beheerst kan een vertrouwd item erven of een slachtoffer aan een slecht item vastpinnen. Leid de sleutel af uit de verbinding die uw eigen infrastructuur beëindigde, en leg vast welke afleiding is gebruikt. Als er meerdere proxy's voor staan, documenteer dan de keten in plaats van de eerste plausibel lijkende header te vertrouwen. Is de keten dubbelzinnig, log dan de afgeleide sleutel en de header die u verwierp, want naar het tweede vraagt een incidentreview.
Geen bewijs is geen schoon resultaat
Een timeout, een misvormd antwoord en een niet-beschikbare database betekenen elk iets anders dan een geslaagde lookup die niets trof. Presenteer ze als afzonderlijke uitkomsten, en beslis vooraf wat de beschermde actie doet als er helemaal geen bewijs is. Een alleen-lezen pagina en een actie op een ingelogd account kunnen daar redelijkerwijs verschillende regels volgen.
Normale authenticatie aanhouden, of om een ondersteunde verificatie vragen, is meestal een beter antwoord dan een storing als algemene toestemming of als sitebrede blokkade te behandelen. Begrens hoe lang een lookup mag lopen en stop vernieuwingsstormen met het mechanisme dat de integratie ondersteunt. Wordt tijdens een storing een verouderde waarde gebruikt, label die dan als verouderd op het beslispunt, en maak de laatste mislukking van de vernieuwing zichtbaar zodat een langdurig defect niet als gezond item doorgaat. Wat de keuze ook is, schrijf die waar het beleid wordt afgedwongen, niet in een opmerking naast de lookup.
Bewaring hoort bij dezelfde beslissing: houd de velden die deze functie nodig heeft en het controlespoor erachter, niet meer. Een IP-cache hoeft geen browsergeschiedenis te worden.
Accepteer vier gevallen, inclusief een correctie
Test een vers resultaat, een verlopen resultaat, een mislukte lookup en een classificatie die later is gecorrigeerd. Elk geval oefent een andere tak, en alleen het laatste laat zien of een onjuiste beperking kan worden teruggedraaid.
Bevestig daarna dat een gewone gebruiker een route heeft om na een onterechte blokkade om herziening te vragen, want de feed zal soms fout zijn en de wachtrij hoort bij het ontwerp. Schrijf de vier gevallen in de runbook met de naam van de beleidseigenaar ernaast. Het ontwerp verdient zijn plaats wanneer het overbodige lookups verwijdert, de onzekerheid intact laat en de beslissing zichtbaar bij een mens ligt.