Centralize o acesso VPN dos parceiros sem juntar os parceiros

A proposta é razoável: cinco túneis de parceiros espalhados por uma dúzia de portáteis, cinco conjuntos de versões de cliente, cinco scripts de help desk e um engenheiro que sabe como se encaixam. Passá-los para um nível de acesso controlado resolve a dispersão de endpoints. Ao mesmo tempo, cria um novo objeto na arquitetura — um serviço de acesso partilhado que agora precisa do seu próprio modelo de autorização; e a falha que todos subestimam é um equipamento central com todos os túneis ativos a tornar-se, em silêncio, numa rede de trânsito entre organizações que nunca concordaram em ser vizinhas. Esse risco é uma decisão de projeto, não algo que o hardware faça por si. O trabalho abaixo é a forma como mantenho a conveniência sem aceitar o efeito secundário acidental.

Comece pelo contrato que cada parceiro já assinou

Antes de qualquer configuração, confirme que o parceiro permite sequer uma gateway ou ligação de site partilhada. Uma conta pessoal de acesso remoto, um requisito de postura do dispositivo ou um fluxo MFA interativo podem não ser transferíveis para um túnel partilhado sem supervisão, e juntar colaboradores atrás de uma identidade de cliente copiada é o tipo de atalho que dura até o parceiro auditar os registos. Para cada ligação permitida, registe os intervalos de destino, os domínios DNS privados, as fontes internas autorizadas, o responsável pela autenticação e o que deve acontecer quando o túnel falha. Peça ao parceiro que confirme a ligação partilhada por escrito, incluindo os intervalos de origem que aceitará. A aprovação verbal tende a mudar de significado na semana em que a equipa de segurança deles muda.

Esse registo é o resultado. Se não conseguir escrevê-lo para um parceiro, esse parceiro não está pronto para ser centralizado.

Encaminhe por contexto, não apenas por destino

Dois parceiros acabarão por usar o mesmo intervalo privado, porque cada organização escolhe do mesmo espaço RFC 1918. Uma única tabela de encaminhamento comum não consegue escolher o parceiro correto apenas pelo endereço de destino, pelo que intervalos sobrepostos exigem contextos de encaminhamento separados ou outro desenho acordado. O modelo de domínio de encaminhamento em RFC 4364 descreve porque é que essa separação importa, e uma implementação não precisa de correr MPLS para exigir a mesma propriedade à sua plataforma de gateway.

Faça à plataforma uma pergunta direta: dois parceiros podem partilhar o mesmo prefixo de destino e ainda assim ser distinguidos pelo contexto de colaborador de onde veio a sessão? Se a resposta for não, essa restrição molda o desenho mais do que qualquer lista de funcionalidades de fornecedor.

Onde a resposta for sim, o contexto de encaminhamento passa a ser aquilo que documenta e testa, porque é invisível num traceroute.

Decida o que o colaborador escreve e o que o parceiro registra

Parte do trabalho do parceiro encaixa num proxy de aplicação ou num espaço de trabalho remoto aberto no contexto desse parceiro. Outro trabalho exige acesso de rede encaminhado a partir de um segmento de colaboradores aprovado, e os dois produzem endereços de origem e trilhas de auditoria diferentes do outro lado. Um endereço de origem traduzido e partilhado pode satisfazer uma lista de permissões ao mesmo tempo que esconde qual dispositivo fez o quê, por isso mantenha um registo fiável entre colaborador e sessão e mantenha a autenticação da aplicação, em vez de tratar um endereço de gateway como identidade — o que é conveniente até ao momento em que o parceiro pergunta quem o fez.

Depois percorra uma tarefa real do lado do colaborador: no que clica, o que lhe é pedido e o que o parceiro veria se pedisse uma entrada de registo. Se esse percurso não for reproduzível, o desenho não está terminado.

Negue explicitamente o trânsito entre parceiros

Hardware partilhado nunca deve implicar confiança partilhada. Acrescente a negação como uma regra deliberada com um responsável nomeado, não como um acidente de configuração em falta, e teste-a nos dois sentidos com um pedido que de outra forma teria sucesso. O teste importa porque uma permissão que apenas está ausente pode ser reposta pelo engenheiro seguinte que acrescenta uma rota para corrigir uma queixa não relacionada.

Escreva a negação no registo do parceiro ao lado das permissões, para que a intenção sobreviva às mudanças de pessoal.

Opere-o como um serviço partilhado, não como um portátil maior

A renovação de túneis, a rotação de credenciais, a capacidade e a substituição da gateway passam todas a ser alterações de serviço partilhado, o que significa que precisam de um calendário e de um caminho de comunicação que os portáteis individuais nunca exigiram. Um certificado de parceiro a expirar num sábado já não é a indisponibilidade de um utilizador; é a de todas as sessões desse parceiro ao mesmo tempo.

Aceite o nível apenas quando um pedido negado entre parceiros falhar exatamente como previsto e um pedido permitido de um colaborador chegar ao destino certo com a origem certa. Remover o conflito de portáteis mantendo intacta a fronteira de cada parceiro é o objetivo inteiro; um desenho em que cada prefixo remoto é alcançável de cada secretária apenas mudou o problema de sítio.

Mantenha uma pequena tabela de parceiro, contexto, intervalos permitidos e responsável. Será a primeira coisa que alguém pede durante um incidente.