Estamos implementando o SQL Server Always Encrypted em nosso ambiente de 2019. Fizemos vários POCs bem-sucedidos nos últimos meses, mas ao migrar a solução para Prod, eu esperava usar uma CA confiável pública para os certificados. Mas agora, revisando aproximadamente 10 tutoriais de AE na web, incluindo as instruções oficiais da Microsoft, percebi que o uso de uma CA confiável pública nunca é mencionado... nunca... de forma alguma. Há até um artigo aqui perguntando se o uso de um certificado CA confiável adiciona algum benefício, e é sugerido que isso não aconteça.
Estou tentando satisfazer todas as nossas iniciativas de segurança que estão sendo implementadas em toda a empresa, então acho que estou tentando encontrar algum tipo de resposta padrão que possa apontar.
Tenho falado sobre como os certificados autoassinados estão sujeitos a ataques man-in-the-middle, mas acho que estou começando a perceber que isso se aplica apenas às conexões SQL que estão sendo feitas e a quaisquer dados que fluam por meio dessa conexão (porque nas tabelas os dados não são criptografados e o SSL os criptografa). Mas com o AE, os dados no banco de dados já são simplesmente uma string criptografada.
O mesmo acontece com a natureza de uma solução Always Encrypted, se feita onde os certificados autoassinados nunca são feitos ou residem no mesmo servidor que contém os dados, impede quaisquer ataques MIM? O simples uso de certificados autoassinados é a maneira "padrão" aceita de fazer isso? Pensando bem, acredito que a resposta seja sim, mas gostaria apenas de algum tipo de resposta "oficial" haha.
Always Encrypted (AE) tem duas partes principais: o mecanismo de banco de dados e o driver cliente. O mecanismo de banco de dados sempre* funciona com dados criptografados e os dados nunca estão em estado descriptografado. Assim, os dados enviados de e para o cliente ou servidor, através da rede, também estão em estado criptografado. Na verdade, o único lugar onde não está em estado criptografado é em qualquer endpoint que tenha um driver apropriado e acesso ao certificado correto para descriptografar os dados.
Dado o exposto, a menos que o MiM tenha uma cópia do certificado (e quaisquer outros certificados necessários para TLS), não deve haver uma maneira (sem contar a força bruta ridícula) para que isso ocorra. Isso, no entanto, empurra o ônus da segurança para os endpoints, que têm um histórico bastante terrível de serem protegidos adequadamente.
Para responder à sua pergunta, sim, dada a natureza, normalmente não haverá um ataque MiM disponível. Além disso, não vi nenhum lugar no driver mais comum onde os certificados fossem verificados quanto à confiança, nem as CRLs verificadas ... desde que eu pudesse facilmente ter perdido alguma coisa, pois não fiz do estudo do código minha tese.
Basicamente, é por isso que você não vê nenhuma referência real a isso. A maioria dos locais possui configuração de PKI e aqueles que não possuem podem usar facilmente ferramentas integradas para criar certificados.
A Microsoft é o único lugar (acho que tecnicamente as empresas também são pessoas, então a única pessoa?) Que pode lhe dar uma resposta "oficial".
* This does not include secure enclaves
Os certificados autoassinados não estão mais sujeitos a ataques MitM do que qualquer outro tipo. A única coisa especial sobre eles é que eles não são automaticamente confiáveis (porque não são assinados por uma autoridade confiável), portanto, configurar a confiança é problema seu.
Além disso, observe que o principal benefício das autoridades certificadoras é quando os clientes conectados não estão sob seu controle... por exemplo, quando um milhão de usuários anônimos acessam seu site, você não pode estabelecer manualmente a confiança com todos eles, um por um.
Isso é menos relevante para algo como um servidor de banco de dados, que normalmente será acessado por um conjunto muito menor de clientes e não será acessado anonimamente. Nesse ambiente, cada cliente precisará ser configurado para se autenticar no servidor de qualquer maneira, garantindo que eles confiem no certificado do servidor se torne parte desse processo.