Arquitetura Imutável: Verificação Prática com Código e Autenticação
Este artigo explora a implementação de autenticação em uma arquitetura imutável, utilizando certificados digitais para garantir a segurança e integridade dos dados. O autor detalha o processo de criação e uso de certificados, destacando os desafios e soluções encontradas, além de discutir as vantagens e limitações dessa abordagem.
MundiX News·10 de maio de 2026·7 min de leitura·👁 2 views
Arquitetura Imutável: Verificação Prática com Código e Autenticação
Este artigo é a segunda parte de uma série que explora a construção de aplicações utilizando os princípios da arquitetura imutável, conforme descritos no livro "A Arte da Arquitetura Imutável: Teoria e Prática da Gestão de Dados em Sistemas Distribuídos".
Nesta seção, o foco é a implementação da autenticação de clientes/serviços externos usando certificados e os conceitos de "arquitetura imutável". A autenticação, neste contexto, visa garantir que apenas sistemas autorizados possam acessar o serviço, rejeitando solicitações de fontes não confiáveis.
Por que Certificados?
A escolha de certificados para a autenticação está alinhada com a filosofia da imutabilidade. Uma vez criado, um certificado não deve ser alterado. Os certificados permitem a criação de assinaturas digitais em documentos, que podem ser armazenadas com "registros imutáveis" e verificadas posteriormente para garantir a integridade dos dados. Um certificado, uma vez emitido, não é modificado, o que está em conformidade com os princípios do livro.
A tecnologia de certificados é amplamente utilizada há décadas, bem documentada e amplamente suportada. As implementações de bibliotecas estão disponíveis para quase todas as linguagens de programação e se integram bem entre diferentes linguagens.
Arquitetura de Autenticação
Criação de Certificados
O livro sugere que a criação de certificados é simples, e a experiência prática confirma isso, embora com algumas nuances. A criação de um certificado no Windows usando o Putty foi direta. No entanto, o Putty gera certificados em um formato não suportado por Java e Python. Felizmente, foi possível exportar os certificados do Putty no formato OpenSSH. A biblioteca cryptography do Python funcionou sem problemas com certificados OpenSSH.
Java, por outro lado, não conseguiu trabalhar com certificados OpenSSH, ou pelo menos não foi possível configurar. Java pode trabalhar com certificados X.509. No entanto, foi fácil converter certificados OpenSSH para um formato suportado pelo Java. Os passos para essa conversão estão descritos em [este arquivo](link para o arquivo).
O resultado é uma chave privada para assinar documentos e uma chave pública para verificar documentos.
Serviço de Envio de Solicitações
As solicitações para o serviço de processamento são criadas em uma aplicação separada, escrita em Python. O serviço primeiro envia sua chave pública para o servidor de processamento de dados. Isso é descrito na próxima seção.
Ao enviar solicitações, cada solicitação é assinada com a chave privada, e a assinatura digital é inserida no cabeçalho. A chave pública também é inserida no cabeçalho para verificação da assinatura. Este é o ponto central desta etapa. É essencialmente a autenticação. Ou seja, nos apresentamos ao sistema externo usando uma chave pública, que só podemos gerar com base em nossa chave privada. Portanto, o sistema de processamento de solicitações deve conhecer nossa chave pública ANTES de enviarmos mensagens. Nesta solução técnica, isso é resolvido enviando a chave pública através de um serviço REST. Em soluções de produção, diferentes métodos são possíveis. No entanto, a principal vantagem aqui é que essa chave pública pode ser transmitida por qualquer canal de comunicação. É uma chave pública. É impossível falsificá-la sem a chave privada. Não há necessidade de "transmissões secretas" da primeira senha.
Serviço de Processamento de Documentos
Para autenticar mensagens, o serviço de verificação deve ter a chave pública. Nesta solução, isso é feito através de um serviço REST.
Cada solicitação recebida, além do corpo da solicitação, possui dois cabeçalhos:
Certificado público para verificação da assinatura
Assinatura eletrônica para verificação
E chegamos novamente ao ponto principal. Verificamos o usuário por sua chave pública. Ou seja, devemos ter a chave pública ANTES de começar a verificar a assinatura com essa chave pública, que o usuário nos enviará novamente.
Se a chave pública recebida já estiver no banco de dados, a solicitação é verificada/aprovada/processada.
Surge imediatamente a questão de como lidar com a situação em que queremos negar o acesso a um usuário. Não podemos excluir o registro com sua chave pública. Estamos trabalhando em uma arquitetura "imutável" sem atualizações e exclusões. Para resolver esse problema, uma segunda entidade, "certificados revogados", foi criada.
Cada chave pública recebida é verificada tanto em relação às chaves públicas permitidas quanto aos certificados revogados. Ou seja, para desativar um usuário, você precisa adicionar o certificado à lista de certificados revogados. Graças à pesquisa por campos indexados, todas as solicitações são executadas rapidamente.
Conclusão
Os certificados permitiram resolver o problema de forma simples e confiável? Em geral, sim. Nesta etapa, foi possível criar certificados no Putty sem grandes problemas. Assinar um documento com Python. Verificar a assinatura em Java. A solução foi simples, rápida e com grande potencial de expansão.
Mesmo na implementação atual, esta solução está pronta para uso em redes corporativas. Ao acessar esta solução de redes externas, haverá um problema, descrito no parágrafo seguinte.
Esta solução específica tem uma limitação na resistência a ataques DDoS. Para verificar o remetente, é necessário ler a mensagem completa dele. Ou seja, muitos remetentes "falsos" podem sobrecarregar o sistema. Neste caso específico, esta é uma suposição aceita. Ao implantar soluções de produção semelhantes, existem muitas maneiras de resolver esse problema. A discussão dessas soluções está além do escopo deste ciclo.
O resultado desta etapa mostrou que a autenticação via certificados pode ser conectada sem criar uma infraestrutura complexa de gerenciamento de certificados, simplesmente criando-os manualmente.
Um problema foi a duplicação do tamanho das mensagens, pois o certificado, que o servidor JÁ possui, é constantemente duplicado nelas. Mas esta é uma "desvantagem" da arquitetura imutável. No entanto, a chave pública em si tem 451 bytes.
Os Certificados se Encaixam na Arquitetura Imutável?
Com certeza! 100%!
Arquitetura Imutável: Verificação Prática com Código e Autenticação
Este artigo é a segunda parte de uma série que explora a construção de aplicações utilizando os princípios da arquitetura imutável, conforme descritos no livro "A Arte da Arquitetura Imutável: Teoria e Prática da Gestão de Dados em Sistemas Distribuídos".
Nesta seção, o foco é a implementação da autenticação de clientes/serviços externos usando certificados e os conceitos de "arquitetura imutável". A autenticação, neste contexto, visa garantir que apenas sistemas autorizados possam acessar o serviço, rejeitando solicitações de fontes não confiáveis.
Por que Certificados?
A escolha de certificados para a autenticação está alinhada com a filosofia da imutabilidade. Uma vez criado, um certificado não deve ser alterado. Os certificados permitem a criação de assinaturas digitais em documentos, que podem ser armazenadas com "registros imutáveis" e verificadas posteriormente para garantir a integridade dos dados. Um certificado, uma vez emitido, não é modificado, o que está em conformidade com os princípios do livro.
A tecnologia de certificados é amplamente utilizada há décadas, bem documentada e amplamente suportada. As implementações de bibliotecas estão disponíveis para quase todas as linguagens de programação e se integram bem entre diferentes linguagens.
Arquitetura de Autenticação
Criação de Certificados
O livro sugere que a criação de certificados é simples, e a experiência prática confirma isso, embora com algumas nuances. A criação de um certificado no Windows usando o Putty foi direta. No entanto, o Putty gera certificados em um formato não suportado por Java e Python. Felizmente, foi possível exportar os certificados do Putty no formato OpenSSH. A biblioteca cryptography do Python funcionou sem problemas com certificados OpenSSH.
Java, por outro lado, não conseguiu trabalhar com certificados OpenSSH, ou pelo menos não foi possível configurar. Java pode trabalhar com certificados X.509. No entanto, foi fácil converter certificados OpenSSH para um formato suportado pelo Java. Os passos para essa conversão estão descritos em [este arquivo](link para o arquivo).
O resultado é uma chave privada para assinar documentos e uma chave pública para verificar documentos.
Serviço de Envio de Solicitações
As solicitações para o serviço de processamento são criadas em uma aplicação separada, escrita em Python. O serviço primeiro envia sua chave pública para o servidor de processamento de dados. Isso é descrito na próxima seção.
Ao enviar solicitações, cada solicitação é assinada com a chave privada, e a assinatura digital é inserida no cabeçalho. A chave pública também é inserida no cabeçalho para verificação da assinatura. Este é o ponto central desta etapa. É essencialmente a autenticação. Ou seja, nos apresentamos ao sistema externo usando uma chave pública, que só podemos gerar com base em nossa chave privada. Portanto, o sistema de processamento de solicitações deve conhecer nossa chave pública ANTES de enviarmos mensagens. Nesta solução técnica, isso é resolvido enviando a chave pública através de um serviço REST. Em soluções de produção, diferentes métodos são possíveis. No entanto, a principal vantagem aqui é que essa chave pública pode ser transmitida por qualquer canal de comunicação. É uma chave pública. É impossível falsificá-la sem a chave privada. Não há necessidade de "transmissões secretas" da primeira senha.
Serviço de Processamento de Documentos
Para autenticar mensagens, o serviço de verificação deve ter a chave pública. Nesta solução, isso é feito através de um serviço REST.
Cada solicitação recebida, além do corpo da solicitação, possui dois cabeçalhos:
Certificado público para verificação da assinatura
Assinatura eletrônica para verificação
E chegamos novamente ao ponto principal. Verificamos o usuário por sua chave pública. Ou seja, devemos ter a chave pública ANTES de começar a verificar a assinatura com essa chave pública, que o usuário nos enviará novamente.
Se a chave pública recebida já estiver no banco de dados, a solicitação é verificada/aprovada/processada.
Surge imediatamente a questão de como lidar com a situação em que queremos negar o acesso a um usuário. Não podemos excluir o registro com sua chave pública. Estamos trabalhando em uma arquitetura "imutável" sem atualizações e exclusões. Para resolver esse problema, uma segunda entidade, "certificados revogados", foi criada.
Cada chave pública recebida é verificada tanto em relação às chaves públicas permitidas quanto aos certificados revogados. Ou seja, para desativar um usuário, você precisa adicionar o certificado à lista de certificados revogados. Graças à pesquisa por campos indexados, todas as solicitações são executadas rapidamente.
Conclusão
Os certificados permitiram resolver o problema de forma simples e confiável? Em geral, sim. Nesta etapa, foi possível criar certificados no Putty sem grandes problemas. Assinar um documento com Python. Verificar a assinatura em Java. A solução foi simples, rápida e com grande potencial de expansão.
Mesmo na implementação atual, esta solução está pronta para uso em redes corporativas. Ao acessar esta solução de redes externas, haverá um problema, descrito no parágrafo seguinte.
Esta solução específica tem uma limitação na resistência a ataques DDoS. Para verificar o remetente, é necessário ler a mensagem completa dele. Ou seja, muitos remetentes "falsos" podem sobrecarregar o sistema. Neste caso específico, esta é uma suposição aceita. Ao implantar soluções de produção semelhantes, existem muitas maneiras de resolver esse problema. A discussão dessas soluções está além do escopo deste ciclo.
O resultado desta etapa mostrou que a autenticação via certificados pode ser conectada sem criar uma infraestrutura complexa de gerenciamento de certificados, simplesmente criando-os manualmente.
Um problema foi a duplicação do tamanho das mensagens, pois o certificado, que o servidor JÁ possui, é constantemente duplicado nelas. Mas esta é uma "desvantagem" da arquitetura imutável. No entanto, a chave pública em si tem 451 bytes.
Os Certificados se Encaixam na Arquitetura Imutável?
