Histórico do X-Road

O X-Road é uma solução de ecossistema e software de código aberto concebida para fornecer troca de dados segura e unificada entre organizações. Foi desenvolvido originalmente na Estônia por volta do ano 2000, como um meio para digitalizar serviços públicos e aumentar o alcance de políticas públicas. Sua arquitetura é um ponto de partida para a criação de barramentos de integração de acordo com os requisitos apresentados na Introdução.

1. Arquitetura e Componentes Principais

O X-Road (ou X-Valid, a implementação no Brasil) atua como uma camada de comunicação segura na Internet através da qual os membros participantes podem publicar e consumir serviços.

A arquitetura se baseia nos seguintes componentes-chave:

Security Servers (Servidores de Segurança - SS): São pontos de acesso pelos quais os membros de um ecossistema trocam dados. Cada organização participante deve configurar um SS em sua infraestrutura.
- Os SS são responsáveis por garantir o sigilo, a autenticação e o não repúdio das mensagens trocadas entre si pela Internet pública.
- O SS local de um Consumidor de Serviço encaminha a mensagem para o SS do Provedor, e a resposta faz o caminho inverso, usando sempre o canal seguro.
Central Services (Serviços Centrais / Registro - Registry): Um órgão governamental estabelece um provedor de Serviços Centrais que hospeda serviços gerais para cadastro e autenticação. O componente Registry (Registro) controla qualquer novo membro ou subsistema e mantém as identidades de forma centralizada.
Trust Services (Serviços de Confiança / Verifier): Fornece serviços de confiança, incluindo a Autoridade Certificadora (CA) e o serviço de marcação de tempo (time-stamping).
- O Verifier (Verificador) é um componente que realiza a auditoria jurídica das transações, validando-as por meio de certificados digitais e carimbo de tempo.
Directory (Diretório): Componente que facilita a descoberta e o acesso aos serviços. Ele lista o catálogo de serviços, organizações e subsistemas.
Link (específico a X-Valid): Um componente que permite criar serviços/APIs de forma Low-Code, consultando ou alterando dados diretamente no banco de dados da organização (usando scripts SQL).

Neste contexto, os Security Servers (SS) atuam como uma camada fundamental de comunicação (middleware), funcionando como servidores proxy especializados na troca de informações seguras entre os membros do ecossistema X-Road. O processo de troca de dados ocorre em etapas bem definidas, garantindo o sigilo e a autenticação:

Iniciação: Um cliente (ou subsistema) pertencente a uma organização que deseja consumir um serviço envia a requisição ao Security Server local (SS do Consumidor).
Encaminhamento Seguro: O SS do Consumidor é responsável por encaminhar a mensagem — de forma sigilosa e autenticada — para o Security Server da organização Provedora de Serviço através de um canal seguro suportado pela Internet pública.
Roteamento Interno: Ao receber a mensagem, o SS do Provedor de Serviço a roteia para o servidor interno que de fato implementa o serviço solicitado. É importante notar que o serviço real é hospedado na infraestrutura do provedor e não precisa ser exposto diretamente à Internet pública, bastando ser acessível pelo Security Server.
Resposta: A resposta do serviço segue o caminho inverso, trafegando novamente pelo canal seguro entre os Security Servers.

A principal característica arquitetônica é que a troca de dados em si ocorre par a par (peer-to-peer), diretamente entre o Security Server do Consumidor e o Security Server do Provedor. Como os dados são trocados diretamente entre o produtor e o consumidor do serviço, não há um ponto central que atue como um gargalo limitador no maior volume de troca de dados, garantindo que a comunicação entre os membros seja distribuída. O SS garante o sigilo, a autenticação e o não repúdio das mensagens.

Podemos entender o Security Server (SS) como o porteiro digital altamente seguro de cada organização. Para que o Carteiro (a requisição) entregue uma carta confidencial de uma Empresa A para o Departamento Interno de uma Empresa B, a comunicação não passa por um Correio Central de triagem de dados; ela vai diretamente do Porteiro da Empresa A (SS Consumidor) para o Porteiro da Empresa B (SS Provedor), que autentica a origem e só então permite que a carta chegue ao destinatário final (o Serviço interno). Isso garante que, mesmo com milhões de cartas sendo trocadas, o sistema não trave em um ponto central único.

2. Fluxo de Dados e Segurança

Troca de Dados

A troca de dados ocorre diretamente entre o produtor (Provedor de Serviços) e o consumidor (Consumidor de Serviços) através de seus respectivos Security Servers.

Cadastro de Membros: O ingresso em um ecossistema X-Road envolve um processo de cadastro. A identidade de cada organização e ponto de acesso técnico é verificada usando certificados emitidos por uma CA confiável.
Publicação de Serviço: O Provedor de Serviço cadastra o serviço em seu Security Server. Como explicado na seção anterior, o serviço em si é hospedado na infraestrutura do provedor, precisando apenas ser acessível pelo Security Server, e não necessariamente exposto à Internet pública.
Invocação: O Consumidor de Serviço realiza a invocação do serviço no seu Security Server local, que encaminha a mensagem para o Provedor.

Mecanismos de Segurança

A segurança é central no X-Road, garantindo a integridade, confidencialidade e não repúdio dos dados.

Certificados: As organizações recebem certificados emitidos pela Autoridade Certificadora (CA) durante o cadastro.
Canal Seguro: Os Security Servers trocam mensagens entre si com sigilo e autenticação através de um canal seguro.
Autenticação (TLS e Header): A autenticação do serviço combina dois meios: um Certificado para fechar o canal TLS mútuo e a Identificação no Header da requisição.
- Os Headers obrigatórios incluem UXP-Client (identificando o Proprietário e o Subsistema Consumidor) e UXP-Service (identificando o Proprietário, o Subsistema Provedor, e a informação e versão do serviço).
Não Repúdio e Auditoria: O time-stamping (marcação de tempo) e as assinaturas digitais são usados em conjunto para garantir o não repúdio dos dados enviados. Todos os registros de troca de dados podem ser usados como evidência em procedimentos legais.
Registro de Auditoria: Toda evidência sobre a troca de dados é armazenada localmente pelos atores (Provedor e Consumidor), e nenhum terceiro tem acesso aos dados. Toda requisição entre Security Servers gera um registro no Verifier e no Directory.

Os serviços centrais são responsáveis pelos registros de entidades e também da criação e validação de certificados, através de um serviço OCSP. Como já mencionado, eles não atuam como intermediário na invocação de um serviço.

3. Serviços e Desempenho

Protocolos Suportados: O X-Road foi originalmente criado usando a pilha de web services SOAP/WSDL. Ao longo do tempo, ganhou suporte para a publicação de APIs REST pelas entidades participantes. Internamente, entretanto, seus serviços internos são implementados usando SOAP.
Extensibilidade e Gestão: O X-Road oferece uma interface gráfica em cada Security Server para a gestão de APIs. Ele possui funcionalidades de monitoramento e criação de relatórios operacionais e técnicos.
Desempenho: Em comparação com arquiteturas modernas baseadas em API Gateway como o Kong, o X-Road pode apresentar um desempenho inferior no tempo de resposta das invocações de serviços, o que pode ser atribuído à sobrecarga gerada por funcionalidades como a geração e armazenamento de registros de time-stamping. A arquitetura interna monolítica do X-Road, apesar das extensões adicionadas, também é citada como um fator limitante em comparação com soluções nativas de nuvem e microsserviços.