Cacheie a classificação de VPN e mantenha a idade visível

Uma classificação em cache economiza uma consulta e congela a opinião de ontem na decisão de hoje. A comparação real não é cache contra ausência de cache: é uma observação, sua frescura e a resposta que seu site escolheu. Perca a fronteira entre essas três e uma otimização começa a fazer política sozinha. O conserto é contabilidade, não um feed melhor.

Três registros com três relógios diferentes

Uma observação é o campo que você recebeu, o feed de onde ele veio e a versão do conjunto de dados por trás. A frescura é uma propriedade da entrada de cache: quando a consulta rodou, quando a entrada deixa de ser confiável e se a última atualização devolveu algo. A resposta é o que seu site faz a respeito para esta requisição, esta conta ou esta ação. Elas são produzidas por donos diferentes e decaem em ritmos diferentes, por isso uma linha chamada blocked destrói a distinção.

Dois relógios merecem cuidado especial. O momento em que sua consulta rodou não é o momento em que o provedor publicou o conjunto de dados, e quem lê a linha depois precisa saber de qual dos dois veio cada valor. Defina expiração e atualização segundo o modelo de atualização documentado do feed e segundo o custo de errar, nunca segundo um número emprestado de outro site.

Guarde o campo, não o veredito

A documentação da MaxMind sobre IPs anônimos é um exemplo concreto de um feed que separa VPN anônima, provedor de hospedagem, proxy público e saída Tor em campos distintos. Ela também documenta que uma sub-rede de VPN não registrada pode aparecer, em vez disso, sob a marca de hospedagem. Achatar isso em um único booleano joga fora a única parte que um operador poderia auditar depois.

Nenhuma das duas direções de inferência é segura. Um rótulo de hospedagem não estabelece que um túnel foi usado, e a ausência de uma marca de VPN não estabelece que nada estava entre o cliente e seu serviço. São duas afirmações diferentes, e um único booleano não pode expressar nenhuma delas.

Amarre a entrada ao endereço que você verificou

Atrás de um proxy reverso, a aplicação precisa usar o tratamento de endereços de cliente aprovado pela implantação. Um cabeçalho de encaminhamento fornecido pelo chamador nunca deve poder selecionar a reputação em cache de outra pessoa.

Essa falha é ao mesmo tempo um bug de correção e de segurança, porque um atacante que controla o cabeçalho pode herdar uma entrada confiável ou fixar uma vítima a uma ruim. Derive a chave da conexão que sua própria infraestrutura encerrou, e registre qual derivação foi usada. Quando há vários proxies à frente, documente a cadeia em vez de confiar no primeiro cabeçalho que pareça plausível. Se a cadeia é ambígua, registre a chave derivada e o cabeçalho que você rejeitou, porque o segundo é o que uma revisão de incidente vai perguntar.

Ausência de evidência não é resultado limpo

Um tempo limite, uma resposta malformada e um banco de dados indisponível significam cada um algo diferente de uma consulta bem-sucedida que não casou com nada. Represente-os como desfechos separados, e decida de antemão o que a ação protegida faz quando não há evidência alguma. Uma página somente leitura e uma ação em conta autenticada podem seguir regras diferentes de forma razoável.

Manter a autenticação normal, ou pedir uma verificação suportada, costuma ser uma resposta melhor do que tratar uma queda como permissão geral ou como proibição para todo o site. Limite quanto tempo uma consulta pode durar e pare tempestades de atualização com o mecanismo que a integração suportar. Quando um valor obsoleto é usado durante uma queda, rotule-o como obsoleto no ponto de decisão, e torne visível a última falha da atualização para que uma avaria longa não passe por entrada saudável. Qualquer que seja a escolha, escreva-a onde a política é aplicada, não em um comentário ao lado da consulta.

A retenção pertence à mesma decisão: guarde os campos de que esta função precisa e o rastro de revisão por trás deles, nada mais. Um cache de IP não precisa virar histórico de navegação.

Aceite quatro casos, incluindo uma correção

Teste um resultado fresco, um resultado expirado, uma consulta falha e uma classificação corrigida depois. Cada um exercita um ramo diferente, e só o último mostra se uma restrição equivocada pode ser desfeita.

Depois confirme que um usuário comum tem um caminho para pedir revisão após um bloqueio errado, porque o feed às vezes errará e a fila faz parte do desenho. Escreva os quatro casos no runbook com o nome do dono da política ao lado. O desenho ganha seu lugar quando remove consultas redundantes mantendo a incerteza intacta e a decisão visivelmente nas mãos de uma pessoa.