Quando o IPsec cai, uma rota de reserva não é uma política de reserva

Um local perde o seu túnel, e a tabela de rotas continua a mostrar um caminho perfeitamente utilizável até ao destino através da internet. Alguém propõe comutar para ele e chama à mudança uma correção de encaminhamento. O pacote poderia seguir por esse caminho; a pergunta que ninguém fez é se lhe é permitido chegar sem proteção. São respostas diferentes de tabelas diferentes, e confundi-las é a forma como uma falha se torna um incidente.

Dois resultados que parecem idênticos numa tabela de rotas

A alcançabilidade diz que um pacote tem para onde ir. Uma política de segurança diz o que deve acontecer a esse pacote no caminho, e ambas são aplicadas por mecanismos diferentes. Uma rota pode existir para um fluxo que a política é obrigada a descartar, e essa combinação não é uma configuração errada. Separar as duas perguntas é o que torna um plano de falha verificável.

Assim, um caminho de falha só é um desenho depois de alguém decidir qual dos resultados permitidos se aplica. Enquanto essa decisão não existir, a rota de reserva é uma tentação e não um plano.

O modelo de política tem três veredictos, não dois

A arquitetura IPsec separa o tráfego que tem de ser descartado, o tráfego a que é permitido contornar a proteção e o tráfego que tem de ser protegido. São três instruções distintas, e a do meio é uma isenção deliberada, não um modo de falha. Lê-las como um par é o que produz a falsa escolha entre um túnel e uma estrada aberta.

Uma associação ausente não promove silenciosamente uma regra de proteger a uma de contornar. A política continua a dizer protege, por isso o pacote espera ou morre, e esse comportamento é o controlo a funcionar como está escrito, não prova de que a política está quebrada.

Escreva o requisito do seu fluxo como uma de três frases: pare até existir um caminho protegido, mude para outro caminho protegido, ou use um caminho autorizado em separado a funcionar sem IPsec. Só a terceira altera o contrato de segurança, e precisa de um proprietário que o possa assinar. Essa frase vai para o registo de alterações, não para a memória de alguém. Os revisores aprovam a segunda frase e recusam a terceira, e ambas as decisões são razoáveis quando são visíveis.

Um contorno é um contrato que ambas as extremidades assinam

Um caminho alternativo precisa de endereços encaminháveis, admissão explícita onde chega e um caminho de resposta que funcione nos dois sentidos. Os endereços privados do local não se tornam alcançáveis porque uma rota predefinida aponta para algum lado.

A autenticação conta tanto como o endereçamento. O tráfego que salta o túnel e chega a uma fronteira que espera proteção é rejeitado mesmo quando aterra na interface correta, por isso a política de receção tem de aceitar essa forma de propósito. Uma isenção com que a extremidade remota nunca concordou é uma falha com passos extra.

Remover um seletor ou afrouxar um mapa para que a reserva funcione não é uma isenção controlada. Alarga o que está isento, deixa a extremidade remota a aplicar outra coisa e pode mudar qual regra de tradução corresponde ao fluxo.

A tradução e a admissão mudam a aritmética

A tradução pode apresentar outra vista de endereços, mas os mapeamentos direto e inverso têm de concordar com o caminho alternativo. Um mapeamento unidirecional produz uma ligação que abre e depois fica pendurada. Meio mapeamento é pior do que nenhum, porque parece progresso.

A admissão é a segunda metade. O lado recetor tem de ter uma regra explícita para este tráfego, o seu próprio registo e uma forma de distinguir às três da manhã uma isenção aprovada de um erro.

A restauração faz parte do desenho

Registe como a falha é detetada, que política escolhe a substituição e o que acontece às sessões que estavam a correr quando ocorreu. Uma ligação nova pode ter êxito após a comutação enquanto uma mais antiga mantém estado ligado a um endereço que já não se aplica.

Prefira outro caminho protegido sempre que o requisito for proteção contínua. Onde uma exceção sem proteção for realmente necessária, limite-a por origens, destinos, serviços e uma duração, e registe como é retirada.

Teste os dois estados, não apenas a falha

A aceitação cobre o caso do túnel falhado e o restaurado, com uma verificação de aplicação em cada um. O resultado interessante não é que os pacotes continuaram a mover-se, mas que só se moveram sob o contrato que a organização escolheu.

Acrescente também o teste de retirada. Uma exceção que ninguém consegue desativar tornou-se silenciosamente política permanente, e é exatamente contra isso que a regra original protegia. Ponha-lhe uma data de validade e um revisor nomeado, ou a isenção sobreviverá a todos os que a compreenderam.