Cache VPN-klassifiseringen og hold alderen synlig
En observasjon, friskheten dens og svaret fra nettstedet ditt eldes i ulikt tempo. Holdt atskilt forblir en bufret klassifisering ærlig om det den vet.
En bufret klassifisering sparer ett oppslag og fryser gårsdagens mening inn i dagens beslutning. Den virkelige sammenligningen er ikke buffer mot ingen buffer: den er en observasjon, friskheten dens og svaret nettstedet ditt valgte. Mister du grensen mellom de tre, begynner en optimalisering å lage policy på egen hånd. Reparasjonen er bokføring, ikke et bedre feed.
Tre poster med tre ulike klokker
En observasjon er feltet du mottok, feeden den kom fra og datasettversjonen bak. Friskhet er en egenskap ved bufferposten: når oppslaget kjørte, når posten ikke lenger stoles på, og om den siste oppdateringen returnerte noe. Svaret er hva nettstedet ditt gjør med det for denne forespørselen, denne kontoen eller denne handlingen. De produseres av ulike eiere og forfaller i ulikt tempo, og derfor ødelegger én rad kalt blocked forskjellen.
| 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 |
To klokker fortjener særlig omhu. Øyeblikket oppslaget ditt kjørte er ikke øyeblikket leverandøren publiserte datasettet, og en operatør som leser raden senere må vite hvilken av de to hver verdi kom fra. Sett utløp og oppdatering etter feedens dokumenterte oppdateringsmodell og etter kostnaden ved å ta feil, aldri etter et tall lånt fra et annet nettsted.
Behold feltet, ikke dommen
MaxMinds dokumentasjon om anonyme IP-adresser er ett konkret eksempel på en feed som skiller anonym VPN, hostingleverandør, offentlig proxy og Tor-utgang i separate felt. Den dokumenterer også at et uregistrert VPN-subnett i stedet kan dukke opp under hostingflagget. Å flate det ut til én boolean kaster bort den eneste delen en operatør senere kunne revidere.
Ingen av slutningsretningene er trygge. En hostingetikett beviser ikke at en tunnel ble brukt, og fraværet av et VPN-flagg beviser ikke at ingenting satt mellom klienten og tjenesten din. Det er to forskjellige påstander, og én boolean kan ikke uttrykke noen av dem.
Knytt posten til adressen du verifiserte
Bak en omvendt proxy må applikasjonen bruke klientadressehåndteringen som utrullingen godkjente. En videresendingsheader levert av den som kaller, må aldri kunne velge noen andres bufrede omdømme.
Den feilen er både en korrekthetsfeil og en sikkerhetsfeil, fordi en angriper som kontrollerer headeren, kan arve en klarert post eller feste et offer til en dårlig. Utled nøkkelen fra forbindelsen din egen infrastruktur avsluttet, og registrer hvilken utledning som ble brukt. Når flere proxyer står foran, dokumenter kjeden i stedet for å stole på den første headeren som virker plausibel. Er kjeden tvetydig, logg den utledede nøkkelen og headeren du avviste, fordi det andre er det en hendelsesgjennomgang vil spørre om.
Ingen bevis er ikke et rent resultat
En timeout, et feilformet svar og en utilgjengelig database betyr hver noe annet enn et vellykket oppslag som ikke matchet noe. Representer dem som separate utfall, og avgjør på forhånd hva den beskyttede handlingen gjør når det ikke finnes bevis i det hele tatt. En skrivebeskyttet side og en handling på en innlogget konto kan med rimelighet følge ulike regler der.
Å beholde normal autentisering, eller be om en støttet verifisering, er vanligvis et bedre svar enn å behandle et avbrudd som generell tillatelse eller som en nettstedsvid utestengelse. Begrens hvor lenge et oppslag kan kjøre, og stopp oppdateringsstormer med den mekanismen integrasjonen støtter. Når en utdatert verdi brukes under et avbrudd, merk den som utdatert på beslutningspunktet, og gjør oppdateringens siste feil synlig, så en langvarig feil ikke kan gå for en sunn post. Uansett valget, skriv det der policyen håndheves, ikke i en kommentar ved oppslaget.
Oppbevaring hører til samme beslutning: behold feltene denne funksjonen trenger og revisjonssporet bak dem, ikke mer. En IP-buffer må ikke bli en nettleserhistorikk.
Godta fire tilfeller, inkludert en retting
Test et friskt resultat, et utløpt resultat, et mislykket oppslag og en klassifisering som senere ble rettet. Hvert tilfelle øver en annen gren, og bare det siste viser om en feilaktig begrensning kan oppheves.
Bekreft deretter at en vanlig bruker har en vei til å be om gjennomgang etter en feil blokkering, fordi feeden noen ganger vil ta feil og køen er en del av designet. Skriv de fire tilfellene inn i runbooken med navnet til policyeieren ved siden av. Designet fortjener plassen sin når det fjerner overflødige oppslag, holder usikkerheten intakt og beslutningen synlig eid av et menneske.