Como documentar uma exceção ao bloqueio de VPN para que possa ser removida

Os desvios cujo propósito partiu com o seu autor são os que sobrevivem à sua utilidade, e as políticas de bloqueio acumulam-nos mais depressa do que qualquer outro tipo de configuração. Uma exceção escrita como «permitir a rede local» é uma regra que ninguém consegue defender e ninguém consegue retirar, porque o requisito por trás dela partiu com a pessoa que a acrescentou. Essas políticas falham por arrastarem isenções cuja razão se evaporou enquanto o risco ficou. O momento de escrever o âmbito, o comportamento em caso de falha e o passo de remoção é o momento em que acrescenta a exceção, enquanto alguém ainda se lembra porquê.

Isto é uma decisão sobre o que a nota deve conter, não um modelo para preencher. Os quatro campos abaixo são os que decidem se um revisor pode remover a regra um ano depois sem uma reunião. Cada um existe porque a sua ausência tem um custo previsível.

Porque é que um desvio não documentado nunca é retirado

Um desvio sem descrição não pode ser testado e, por isso, não pode ser removido em segurança. Sobrevive a cada revisão porque apagar parece arriscado enquanto manter parece inofensivo, e cada revisão que o deixa passar torna a seguinte também mais fácil de deixar passar. O custo é invisível até uma auditoria perguntar porque é que um intervalo privado está isento, e nessa altura a resposta é um encolher de ombros.

O registo tem de ser suficientemente curto para que as pessoas o escrevam realmente na janela de mudança. Uma linha para o tráfego, uma para o requisito que serve.

Escrever o âmbito como tráfego

Enumere a aplicação ou o intervalo de destino, as famílias de endereços envolvidas, o serviço e a porta, e o contexto de rede em que a regra se aplica; depois indique o aprovador e a configuração exata do cliente ou da plataforma que a transporta. «Impressora» é uma intenção; «TCP 631 para 192.168.1.50, apenas rede doméstica» é um âmbito que alguém consegue verificar. Se a resposta a «onde é que isto vive» for «algures no perfil MDM», o registo não está terminado. Um caminho de ficheiro, um nome de perfil ou uma chave de registo vale mais do que uma descrição de onde a configuração poderá estar.

Onde a plataforma suporta regras por aplicação, prefira-as aos intervalos de endereços, porque permitir que uma aplicação contorne o túnel é mais estreito do que isentar toda uma sub-rede privada e sobrevive à mudança do dispositivo para um novo endereço. O guia do VpnService do Android descreve esse modelo por aplicação; os clientes de ambiente de trabalho exprimem a mesma ideia através das suas próprias definições de perfil. As isenções baseadas em endereços são o recurso quando a plataforma não oferece nada mais estreito, e é por isso que precisam de uma linha de âmbito mais precisa.

Quatro tipos de exceção, quatro riscos de remoção

As exceções não são uma única categoria, e removê-las acarreta consequências diferentes. Partilhar uma única linha entre dois tipos é a forma como retirar uma impressora também retira a capacidade de ligar.

Mantenha as exceções de arranque, portal, dispositivo e aplicação em linhas separadas mesmo quando na prática se sobrepõem. Uma isenção de intervalo privado concede silenciosamente acesso a cada vizinho nessa sub-rede em vez do único dispositivo que queria alcançar, e essa é a diferença entre um âmbito que consegue defender e outro em que apenas espera.

O que o desvio faz quando o túnel cai

Faça três perguntas e escreva as respostas, porque são elas que decidem se o bloqueio é real. A exceção continua utilizável quando o túnel cai: num portal cativo tem de ser, ou ninguém conseguirá iniciar sessão, enquanto num recurso privado normalmente não deve ser, ou a política é decorativa. Aplica-se em todas as redes ou apenas no ambiente previsto, uma vez que uma regra limitada à sub-rede doméstica comporta-se de forma muito diferente numa rede pública que por acaso usa o mesmo intervalo. Cada resposta altera tanto a regra como a nota, por isso uma pergunta deixada sem resposta é uma decisão que outra pessoa tomará mal mais tarde.

A terceira pergunta é o que acontece quando o destino muda de endereço, onde as isenções baseadas em domínio e em endereço divergem. As regras baseadas em domínio dependem de quando ocorre a resolução e de como o cliente aplica o resultado, pelo que podem deixar de corresponder silenciosamente após uma alteração que parece não ter relação, e a falha parece um VPN avariado e não uma isenção desatualizada.

Teste, volte a testar e escreva o passo de remoção

Escreva um teste inofensivo para o caminho permitido e um caso negado próximo: a página da impressora carrega e a partilha de ficheiros na mesma sub-rede não. Esse par prova que a exceção é estreita, e é o par que um revisor consegue repetir sem compreender o pedido original. Depois defina os acionadores de novo teste, porque uma exceção que nunca é retestada afasta-se do requisito para o qual foi escrita, e esse afastamento permanece invisível até algo se partir.

Por fim, registe como remover a regra através do componente que a possui, e mantenha os segredos fora da nota. Descrever um serviço e uma rota nunca exige uma chave privada, uma palavra-passe ou o histórico de navegação de alguém, e uma lista curta e mantida vale mais do que uma regra temporária que sobreviveu à pessoa que a escreveu.