Cachee a clasificación de VPN e manteña visible a súa antigüidade

Unha clasificación en caché aforra unha consulta e conxela a opinión de onte na decisión de hoxe. A comparación real non é caché fronte a ausencia de caché: é unha observación, a súa frescura e a resposta que escolleu o seu sitio. Perda a fronteira entre esas tres e unha optimización comeza a facer política pola súa conta. A reparación é contabilidade, non un feed mellor.

Tres rexistros con tres reloxos distintos

Unha observación é o campo que recibiu, o feed do que veu e a versión do conxunto de datos que hai detrás. A frescura é unha propiedade da entrada de caché: cando se executou a consulta, cando a entrada deixa de ser fiable e se a última actualización devolveu algo. A resposta é o que fai o seu sitio ao respecto para esta petición, esta conta ou esta acción. Prodúceas propietarios distintos e decaen a ritmos distintos, por iso unha fila chamada blocked destrúe a distinción.

Dous reloxos merecen un coidado especial. O momento en que se executou a súa consulta non é o momento en que o provedor publicou o conxunto de datos, e quen lea a fila despois necesita saber de cal dos dous veu cada valor. Fixe a caducidade e a actualización segundo o modelo de actualización documentado do feed e segundo o custo de equivocarse, nunca segundo un número tomado doutro sitio.

Garde o campo, non o veredicto

A documentación de MaxMind sobre IP anónimas é un exemplo concreto dun feed que separa VPN anónima, provedor de aloxamento, proxy público e saída de Tor en campos distintos. Tamén documenta que unha subrede de VPN non rexistrada pode aparecer no seu lugar baixo a marca de aloxamento. Aplanar iso nun só booleano bota a única parte que un operador podería auditar despois.

Ningunha das dúas direccións de inferencia é segura. Unha etiqueta de aloxamento non establece que se usase un túnel, e a ausencia dunha marca de VPN non establece que non houbese nada entre o cliente e o seu servizo. Son dúas afirmacións distintas, e un só booleano non pode expresar ningunha das dúas.

Ate a entrada á dirección que verificou

Detrás dun proxy inverso, a aplicación ten que usar o tratamento de enderezos de cliente que aprobou o despregamento. Unha cabeceira de reenvío proporcionada por quen chama nunca debe poder seleccionar a reputación en caché doutra persoa.

Ese fallo é á vez un erro de corrección e de seguridade, porque un atacante que controla a cabeceira pode herdar unha entrada de confianza ou fixar unha vítima a unha mala. Derive a clave da conexión que rematou a súa propia infraestrutura e rexistre que derivación se usou. Cando hai varios proxies diante, documente a cadea en lugar de confiar na primeira cabeceira que pareza plausible. Se a cadea é ambigua, rexistre a clave derivada e a cabeceira que rexeitou, porque a segunda é o que preguntará unha revisión de incidente.

A ausencia de evidencia non é un resultado limpo

Un tempo de espera, unha resposta malformada e unha base de datos non dispoñible significan cada un algo distinto dunha consulta exitosa que non coincidiu con nada. Represénteos como resultados separados e decida de antemán que fai a acción protexida cando non hai evidencia ningunha. Unha páxina de só lectura e unha acción nunha conta con sesión iniciada poden seguir razoablemente regras distintas.

Manter a autenticación normal, ou pedir unha verificación admitida, adoita ser unha resposta mellor que tratar unha caída como permiso xeral ou como prohibición para todo o sitio. Limite canto pode durar unha consulta e deteña as tormentas de actualización co mecanismo que admita a integración. Cando se use un valor obsoleto durante unha caída, etiquéteo como obsoleto no punto de decisión e faga visible o último fallo da actualización, para que unha avaría prolongada non pase por unha entrada sa. Calquera que sexa a elección, escríbaa onde se aplica a política e non nun comentario xunto á consulta.

A retención pertence á mesma decisión: garde os campos que esta función necesita e o rastro de revisión detrás deles, nada máis. Unha caché de IP non ten por que converterse nun historial de navegación.

Acepte catro casos, incluída unha corrección

Probe un resultado fresco, un resultado caducado, unha consulta fallida e unha clasificación que despois se corrixiu. Cada un exercita unha rama distinta, e só o último mostra se unha restrición equivocada se pode desfacer.

Despois confirme que un usuario corrente ten unha vía para pedir revisión tras un bloqueo erróneo, porque o feed ás veces equivocarase e a cola forma parte do deseño. Escriba os catro casos no runbook co nome do propietario da política ao lado. O deseño gaña o seu sitio cando elimina consultas redundantes mantendo intacta a incerteza e a decisión visiblemente en mans dunha persoa.