Cachee la clasificación de VPN y mantenga visible su antigüedad

Una clasificación en caché ahorra una consulta y congela la opinión de ayer en la decisión de hoy. La comparación real no es caché frente a ausencia de caché: es una observación, su frescura y la respuesta que eligió su sitio. Pierda la frontera entre esas tres y una optimización empieza a dictar política por su cuenta. La reparación es contabilidad, no un mejor feed.

Tres registros con tres relojes distintos

Una observación es el campo que recibió, el feed del que vino y la versión del conjunto de datos que hay detrás. La frescura es una propiedad de la entrada de caché: cuándo se ejecutó la consulta, cuándo la entrada deja de ser fiable y si la última actualización devolvió algo. La respuesta es lo que su sitio hace al respecto para esta petición, esta cuenta o esta acción. Las producen propietarios distintos y decaen a ritmos distintos, y por eso una fila llamada blocked destruye la distinción.

Dos relojes merecen especial cuidado. El momento en que se ejecutó su consulta no es el momento en que el proveedor publicó el conjunto de datos, y quien lea la fila después necesita saber de cuál de los dos vino cada valor. Fije la caducidad y la actualización según el modelo de actualización documentado del feed y según el coste de equivocarse, nunca según un número tomado de otro sitio.

Conserve el campo, no el veredicto

La documentación de MaxMind sobre IP anónimas es un ejemplo concreto de un feed que separa VPN anónima, proveedor de alojamiento, proxy público y salida de Tor en campos distintos. También documenta que una subred de VPN no registrada puede aparecer en cambio bajo la marca de alojamiento. Aplanar eso en un solo booleano tira la única parte que un operador podría auditar después.

Ninguna de las dos direcciones de inferencia es segura. Una etiqueta de alojamiento no establece que se haya usado un túnel, y la ausencia de una marca de VPN no establece que no hubiera nada entre el cliente y su servicio. Son dos afirmaciones distintas, y un solo booleano no puede expresar ninguna de las dos.

Ate la entrada a la dirección que verificó

Detrás de un proxy inverso, la aplicación tiene que usar el tratamiento de direcciones de cliente que aprobó el despliegue. Una cabecera de reenvío proporcionada por el llamador nunca debe poder seleccionar la reputación en caché de otra persona.

Ese fallo es a la vez un error de corrección y de seguridad, porque un atacante que controla la cabecera puede heredar una entrada de confianza o fijar a una víctima a una mala. Derive la clave de la conexión que terminó su propia infraestructura y registre qué derivación se usó. Cuando hay varios proxies delante, documente la cadena en lugar de confiar en la primera cabecera que parezca plausible. Si la cadena es ambigua, registre la clave derivada y la cabecera que rechazó, porque la segunda es lo que preguntará una revisión de incidente.

Ninguna evidencia no es un resultado limpio

Un tiempo de espera, una respuesta malformada y una base de datos no disponible significan cada uno algo distinto de una consulta exitosa que no coincidió con nada. Represéntelos como resultados separados y decida de antemano qué hace la acción protegida cuando no hay evidencia alguna. Una página de solo lectura y una acción en una cuenta con sesión iniciada pueden seguir razonablemente reglas distintas ahí.

Mantener la autenticación normal, o pedir una verificación admitida, suele ser una respuesta mejor que tratar una caída como permiso general o como prohibición para todo el sitio. Limite cuánto puede durar una consulta y detenga las tormentas de actualización con el mecanismo que admita la integración. Cuando se use un valor obsoleto durante una caída, etiquételo como obsoleto en el punto de decisión y haga visible el último fallo de la actualización, para que una avería prolongada no pase por una entrada sana. Sea cual sea la elección, escríbala donde se aplica la política y no en un comentario junto a la consulta.

La retención pertenece a la misma decisión: conserve los campos que esta función necesita y el rastro de revisión detrás de ellos, nada más. Una caché de IP no tiene por qué convertirse en un historial de navegación.

Acepte cuatro casos, incluida una corrección

Pruebe un resultado fresco, un resultado caducado, una consulta fallida y una clasificación que después se corrigió. Cada uno ejercita una rama distinta, y solo el último muestra si una restricción equivocada se puede deshacer.

Después confirme que un usuario corriente tiene una vía para pedir revisión tras un bloqueo erróneo, porque el feed se equivocará a veces y la cola forma parte del diseño. Escriba los cuatro casos en el runbook con el nombre del propietario de la política al lado. El diseño se gana su sitio cuando elimina consultas redundantes manteniendo intacta la incertidumbre y la decisión visiblemente en manos de una persona.