CA partilhada, portas separadas: um serviço por ficheiro de admissão

Um certificado que se valida contra uma autoridade partilhada passou um teste de confiança, não um teste de pertença. Estas duas decisões são frequentemente confundidas porque ambas ocorrem no momento da ligação, e a confusão permanece invisível até que seja admitida num serviço uma pessoa que lá não devia estar. A solução não é uma segunda autoridade; é uma segunda decisão, tomada por serviço e registada onde o daemon a lê. Mantenha as duas separadas e a maior parte da confusão nesta área desaparece.

Uma cadeia de confiança não diz nada sobre a pertença ao serviço

Dois serviços podem aceitar a mesma hierarquia emissora e ainda assim ter populações diferentes. Um portátil pertence ao primeiro e não deve alcançar o segundo, enquanto outros clientes da mesma hierarquia pertencem de facto lá. Retirar a autoridade desse serviço excluiria todos os que o usam legitimamente, pelo que o trabalho é de admissão, não de confiança.

Ajuda imaginar duas fechaduras numa porta. O certificado abre a fechadura exterior, e uma decisão por serviço abre a interior; nenhuma substitui a outra. Um serviço só com a fechadura exterior não aplica pertença alguma, apenas autentica. Escreva as duas decisões antes de alterar o que quer que seja, porque uma política que só existe na forma de uma ligação funcional não pode ser auditada. O que se segue diz respeito à fechadura interior.

Converta as substituições opcionais numa porta de admissão

Um diretório de configuração de clientes é normalmente uma conveniência: os ficheiros nele substituem as definições dos clientes que nomeiam, e um cliente sem ficheiro corre simplesmente com os valores predefinidos do servidor. Uma diretiva converte essa conveniência numa porta, de modo que um ficheiro em falta significa que a ligação é recusada.

client-config-dir /etc/openvpn/service-a/clients
ccd-exclusive

A edição comunitária do OpenVPN 2.6 ccd-exclusive documenta, em a sua página de manual, exatamente esta condição, e a procura do ficheiro nomeado depende da identidade efetiva do cliente. Outras compilações e servidores geridos por produtos podem diferir, por isso confirme a versão instalada antes de confiar na mesma semântica noutro lugar.

Trate o caminho acima como um exemplo e verifique a disposição realmente implementada em vez de criar um diretório inventado por um guia. Deixe as verificações de certificados, as verificações de identidade do servidor e a autenticação de contas exatamente como estavam, porque o fragmento acrescenta uma condição e não remove nada. Prepare a alteração antes da produção, já que uma recusa levantada no ponto errado parece uma falha de certificado e envia a investigação para a autoridade. Depois confirme que a linha de registo de um cliente recusado nomeia o ficheiro de configuração em falta e não a cadeia.

Um diretório por serviço, não uma lista partilhada

A pertença pertence ao serviço que a aplica, por isso cada serviço mantém o seu próprio diretório e os seus próprios ficheiros. Apontar dois serviços para uma lista faz com que partilhem a pertença quer alguém o pretendesse quer não, e a alteração resultante é difícil de rastrear até uma decisão. A autoridade partilhada pode continuar partilhada; os ficheiros de admissão não podem. Mantê-los separados significa também que um erro num serviço não pode alargar outro em silêncio.

Uma entrada DEFAULT é o caso que engana as pessoas. Fornece definições de recurso quando não é encontrado nenhum ficheiro nomeado, mas não é o ficheiro nomeado que a porta exige, pelo que não pode admitir um cliente sozinha. Teste um cliente que não tenha qualquer entrada e confirme a recusa; se esse cliente for admitido, o valor de recurso está a ser aplicado e ccd-exclusive não está em vigor nessa instância.

A identidade efetiva decide qual ficheiro é lido

A procura utiliza a identidade com que o cliente se autenticou realmente, que normalmente é o nome comum do certificado. Quando o servidor também verifica um nome de utilizador e uma palavra-passe e mapeia esse nome para o nome comum, o ficheiro deve corresponder ao nome de utilizador autenticado. Uma divergência deixa um diretório cheio de nomes de ficheiro plausíveis que nunca são selecionados.

A leitura é a outra metade. O daemon normalmente abandona privilégios após o arranque, pelo que a conta reduzida precisa de acesso de leitura ao diretório e a cada entrada nele contida. Os clientes não devem poder criar a sua própria entrada através de qualquer caminho onde se possa escrever, porque a admissão em autosserviço anula completamente o mecanismo. Verifique as permissões de montagem e de partilha e não apenas o modo do ficheiro, já que um diretório que parece fechado para uma conta pode estar aberto para outra. Depois confirme qual conta o processo em execução usa realmente, e não qual conta o ficheiro de unidade menciona. As duas coincidem apenas quando nada mais as alterou.

Observe a recusa, a admissão e a revogação separadamente

Experimente uma identidade que pertence ao serviço e confirme que se liga. Experimente um certificado válido sem entrada e confirme que é recusado. Experimente uma identidade admitida no outro serviço e confirme que aqui não é admitida. Anote a instância do serviço e a identidade efetiva junto a cada resultado, porque um resultado sem esse contexto ninguém mais o consegue reproduzir.

A retirada é uma operação distinta da revogação. Editar um ficheiro de admissão remove um direito de um serviço enquanto a identidade continua válida em todo o resto, ao passo que uma chave comprometida exige a resposta de revogação da organização. Decida antecipadamente o que acontece às sessões já estabelecidas, porque nem a edição do diretório nem a lista de revogação as terminam por si mesmas.

A admissão é também apenas a primeira porta. Aderir a um serviço não diz nada sobre as sub-redes, as bases de dados ou as interfaces de gestão por trás dele, e essa política de recursos tem de ser escrita e testada à parte.