TLS nativo, encaminhamento SSH ou VPN para um serviço na nuvem

A pergunta raramente é se algo entre duas máquinas na nuvem deve ser cifrado; é qual interface está a cifrar e quem verifica a identidade de quem. Começo estas conversas pelo serviço e não pelo diagrama de rede, porque o serviço já sabe de que precisa. Três limites cobrem a maioria dos casos: o TLS da própria aplicação, uma única porta TCP encaminhada por SSH e uma sobreposição encaminhada que dá um endereço a cada participante. Não são ordenados por força, mas por quanto do problema cobrem.

Comece pelo serviço, não pela rede

Avance do processo para fora. Que protocolo fala, que nome o cliente vai verificar e quem pode abrir uma ligação? Essas três respostas eliminam opções mais depressa do que qualquer tabela comparativa, e a configuração do próprio serviço costuma respondê-las em poucos minutos.

Pegue numa API interna pequena que já serve HTTPS na porta 8443 com um certificado para api.internal.example. ss -ltnp no anfitrião mostra a que se liga, e openssl s_client -connect 127.0.0.1:8443 -verify_hostname api.internal.example mostra se o certificado é válido para o nome que o cliente vai realmente usar. Se ambos estiverem saudáveis, o serviço pode proteger o seu próprio fluxo e resta apenas a acessibilidade. É um problema muito menor do que construir uma rede.

Passo 1: o serviço protege-se a si mesmo?

Esta é a opção a tomar quando encaixa, e encaixa mais vezes do que as equipas assumem. A cifra do serviço cobre todo o caminho entre cliente e servidor, incluindo cada salto pelo meio, o que nenhum túnel em torno do centro melhora. Configure o nome esperado e a confiança explicitamente em vez de confiar no que o armazenamento predefinido do cliente contém por acaso.

A cifra e a acessibilidade continuam a ser controlos separados, e é a fusão deles que faz esta opção falhar. Um serviço TLS num ouvinte público sem restrições continua a aceitar tentativas de ligação de qualquer pessoa, por isso o ouvinte e as regras de rede têm de ser delimitados independentemente de a carga estar protegida. Depois verifique as dependências, porque uma API sobre TLS não diz nada sobre o ponto de descoberta, a porta de administração ou o canal de transferência em massa ao lado. Cada um precisa da sua própria resposta, e um irmão desprotegido basta para tornar todo o limite uma ficção.

Passo 2: uma única porta TCP é todo o requisito?

Quando o requisito é mesmo uma única porta TCP, um encaminhamento é a coisa mais pequena que funciona. Um encaminhamento local SSH transporta essa porta através de uma ligação autenticada que já existe.

A forma é ssh -N -L 8443:127.0.0.1:8443 [email protected], e o detalhe que importa é o endereço de destino: 127.0.0.1 é resolvido do lado remoto, por isso a ligação ao serviço é aberta a partir do bastião e não do seu portátil. Ligue o ouvinte local de forma estreita como -L 127.0.0.1:8443:... para não publicar o serviço na sua própria rede local por acidente. Do lado do servidor, limite o que a conta pode encaminhar em vez de confiar no bom comportamento do cliente. PermitOpen, AllowTcpForwarding local e um GatewayPorts no predefinido são as três definições que transformam um relé genérico num canal concreto.

O contrato é estreito nos dois sentidos. O SSH protege o seu próprio canal, e um salto adicional do bastião para outra aplicação precisa da sua própria proteção. Um serviço que só escuta no loopback do bastião tem uma exposição muito diferente de um alcançado por outra rede, e o encaminhamento não muda isso. Mantenha a autenticação e as verificações TLS da aplicação em vez de tratar o túnel como substituto delas.

Isto funciona bem para uma ligação com um proprietário. Em escala torna-se um sistema: conflitos de portas locais, supervisão, rotação de chaves e a pergunta sobre quem reinicia o encaminhamento após um reinício.

Passo 3: o encaminhamento de rotas é o requisito real?

Essa lista é o custo honesto da opção mais pequena, e é por isso que as equipas acabam por substituir um punhado de comandos de fundo esquecidos por algo gerido. A substituição não é automaticamente uma VPN. Se o requisito continuar a ser uma única porta TCP, um encaminhamento supervisionado com um proprietário documentado é mais barato de operar do que uma sobreposição e falha de formas que pode ver. Meça a propriedade operacional antes de medir a elegância.

O encaminhamento de rotas torna-se a resposta certa quando é o requisito. Várias aplicações que precisam de conectividade IP comum, protocolos que um encaminhamento TCP não consegue transportar ou serviços que se movem entre anfitriões apontam todos na mesma direção.

Uma sobreposição dá aos participantes um endereço e uma rota, e depois começa o trabalho real: intervalos que não se sobrepõem, propriedade de rotas, DNS, inscrição, revogação e o que acontece quando um par desaparece. Nada disso vem com o endereço. Um par admitido na sobreposição também não fica automaticamente autorizado para cada operação no destino, por isso a autenticação ao nível do serviço mantém-se.

O que possui depois

Duas coisas pertencem ao registo que deixa. A primeira é a identidade que o cliente deve verificar, porque cada um destes limites degrada-se em silêncio assim que uma verificação de nome é relaxada para fazer algo funcionar. A segunda é o passo de remoção: que chave, que regra ou que rota desaparece quando o acesso termina, e quem o executa.

O percurso termina onde começou, no serviço. Escolha o limite que cobre o tráfego real e verifica os pares que pretendia verificar, e depois anote como o acesso é atualizado, monitorizado e removido. A referência do OpenSSH é o local para confirmar as opções de encaminhamento antes de prometer um contrato estreito. Se não conseguir descrever o passo de remoção numa frase, o limite é maior do que o problema.