Mettez en cache la classification VPN et gardez son âge visible

Une classification mise en cache économise une requête et fige l'opinion d'hier dans la décision d'aujourd'hui. La vraie comparaison n'oppose pas le cache à l'absence de cache : c'est une observation, sa fraîcheur et la réponse que votre site a choisie. Perdez la frontière entre ces trois et une optimisation se met à faire de la politique toute seule. La réparation est de la comptabilité, pas un meilleur flux.

Trois enregistrements avec trois horloges différentes

Une observation, c'est le champ que vous avez reçu, le flux d'où il vient et la version du jeu de données derrière. La fraîcheur est une propriété de l'entrée de cache : quand la requête a tourné, quand l'entrée cesse d'être fiable et si le dernier rafraîchissement a renvoyé quelque chose. La réponse, c'est ce que votre site en fait pour cette requête, ce compte ou cette action. Elles sont produites par des propriétaires différents et se dégradent à des rythmes différents, c'est pourquoi une seule ligne nommée blocked détruit la distinction.

Deux horloges méritent une attention particulière. L'instant où votre requête a tourné n'est pas celui où le fournisseur a publié le jeu de données, et un opérateur qui lit la ligne plus tard doit savoir de laquelle des deux chaque valeur provient. Réglez l'expiration et le rafraîchissement sur le modèle de mise à jour documenté du flux et sur le coût de l'erreur, jamais sur un nombre emprunté à un autre site.

Gardez le champ, pas le verdict

La documentation MaxMind sur les IP anonymes est un exemple concret d'un flux qui sépare le VPN anonyme, l'hébergeur, le proxy public et la sortie Tor en champs distincts. Elle documente aussi qu'un sous-réseau VPN non déclaré peut apparaître à la place sous l'indicateur d'hébergement. Aplatir cela en un seul booléen jette la seule partie qu'un opérateur pourrait auditer plus tard.

Aucune des deux directions d'inférence n'est sûre. Une étiquette d'hébergement n'établit pas qu'un tunnel a été utilisé, et l'absence d'indicateur VPN n'établit pas que rien ne s'est intercalé entre le client et votre service. Ce sont deux affirmations différentes, et un seul booléen ne peut exprimer ni l'une ni l'autre.

Liez l'entrée à l'adresse que vous avez vérifiée

Derrière un proxy inverse, l'application doit utiliser le traitement des adresses client approuvé par le déploiement. Un en-tête de transfert fourni par l'appelant ne doit jamais pouvoir sélectionner la réputation en cache de quelqu'un d'autre.

Cette défaillance est à la fois un bug de correction et de sécurité, car un attaquant qui contrôle l'en-tête peut hériter d'une entrée de confiance ou épingler une victime sur une mauvaise. Dérivez la clé de la connexion terminée par votre propre infrastructure, et notez quelle dérivation a été utilisée. Quand plusieurs proxys se trouvent devant, documentez la chaîne au lieu de faire confiance au premier en-tête qui paraît plausible. Si la chaîne est ambiguë, journalisez la clé dérivée et l'en-tête que vous avez rejeté, car c'est le second qu'une revue d'incident demandera.

L'absence de preuve n'est pas un résultat propre

Un délai dépassé, une réponse malformée et une base de données indisponible signifient chacun autre chose qu'une requête réussie qui n'a correspondu à rien. Représentez-les comme des issues distinctes et décidez à l'avance ce que fait l'action protégée quand il n'y a aucune preuve du tout. Une page en lecture seule et une action sur un compte connecté peuvent raisonnablement suivre des règles différentes.

Conserver l'authentification normale, ou demander une vérification prise en charge, est généralement une meilleure réponse que de traiter une panne comme une autorisation générale ou comme une interdiction à l'échelle du site. Bornez la durée d'une requête et arrêtez les tempêtes de rafraîchissement avec le mécanisme que l'intégration prend en charge. Quand une valeur périmée est utilisée pendant une panne, étiquetez-la comme périmée au point de décision et rendez visible le dernier échec du rafraîchissement, pour qu'une panne longue ne passe pas pour une entrée saine. Quel que soit le choix, écrivez-le là où la politique est appliquée, pas dans un commentaire à côté de la requête.

La rétention relève de la même décision : gardez les champs dont cette fonction a besoin et la trace de revue derrière eux, rien de plus. Un cache d'IP n'a pas à devenir un historique de navigation.

Acceptez quatre cas, dont une correction

Testez un résultat frais, un résultat expiré, une requête en échec et une classification corrigée plus tard. Chacun exerce une branche différente, et seul le dernier montre si une restriction erronée peut être annulée.

Vérifiez ensuite qu'un utilisateur ordinaire dispose d'un chemin pour demander une revue après un blocage erroné, car le flux se trompera parfois et la file fait partie de la conception. Écrivez les quatre cas dans le runbook avec le nom du propriétaire de la politique à côté. La conception gagne sa place lorsqu'elle supprime les requêtes redondantes tout en gardant l'incertitude intacte et la décision visiblement portée par une personne.