Visão Geral da Arquitetura de Segurança Mandraki

Nota: Este artigo descreve a arquitetura e design de Mandraki. Algumas recursos discutidas estão sendo lançadas progressivamente e podem ainda não estar disponíveis em todos os planos.

A arquitetura de segurança não é uma lista de recursos. É o conjunto de decisões estruturais que determinam como um sistema se comporta quando as coisas correm mal — quando um atacante ganha acesso, quando um governo emite uma intimação, quando um funcionário comete um erro, quando um disco rígido é roubado. Este artigo fornece uma visão geral abrangente da arquitetura de segurança de Mandraki, incluindo os princípios que guiam o nosso design, os sistemas criptográficos que empregamos, e os controlos operacionais que unem tudo.

Princípios de design

Quatro princípios sustentam cada decisão de segurança em Mandraki.

Defesa em profundidade. Nenhum controlo único deve ser a diferença entre segurança e compromisso. Cifragem em repouso, cifragem em trânsito, cifragem de ponta a ponta, controlos de acesso, registo de auditoria, e segmentação de rede trabalham em concerto. Uma falha numa camada deve ser contida pelas outras.

Privilégio mínimo. Utilizadores, serviços, e componentes de infraestrutura têm o acesso mínimo necessário para a sua função. O servidor de base de dados não é acessível a partir da internet pública. O SFU trata mídia mas não tem acesso à base de dados da aplicação. Os pontos finais da API requerem autenticação e autorização ao nível da organização.

Transparência. As alegações de segurança devem ser verificáveis. Documentamos os nossos formatos de cifragem, práticas de gestão de chaves, e escolhas de protocolo em detalhe técnico. Não nos baseamos em obscuridade.

Soberania por design. Cada componente — infraestrutura, aplicação, entidade corporativa — está dentro da jurisdição da UE. Isto não é uma configuração de implementação; é uma propriedade estrutural do sistema.

A hierarquia de cifragem de três camadas

Mandraki utiliza cifragem de envelope com três camadas, um padrão comummente utilizado por fornecedores de nuvem e instituições financeiras pelo seu equilíbrio de segurança, desempenho, e flexibilidade de gestão de chaves.

Camada 1: Chave Mestre. A raiz da hierarquia de chaves. Em implementações padrão, isto é uma chave AES de 256-bit derivada da variável de ambiente MASTER_KEY. Em implementações BYOK, isto é substituído pelo material de chave do cliente (AWS KMS ARN, referência Azure Key Vault, ou chave importada manualmente). A Chave Mestre nunca cifra dados diretamente — envolve Chaves de Organização.

Camada 2: Chaves de Organização. Uma por organização. Cada Chave de Organização é uma chave AES de 256-bit gerada por Mandraki e armazenada na base de dados envolvida (cifrada) pela Chave Mestre. Para usar uma Chave de Organização, é desenvovida em memória, armazenada em cache numa cache LRU com TTL de cinco minutos, e descartada após uso. As chaves desenvovidas nunca são escritas em disco ou armazenadas em Redis. As Chaves de Organização envolvem Chaves de Cifragem de Dados.

Camada 3: Chaves de Cifragem de Dados (DEKs). Múltiplas por organização, uma por propósito: mensagens, ficheiros, gravações, transcrições. Cada DEK é envolvida pela Chave de Organização da sua organização. DEKs realizam a cifragem de dados real utilizando AES-256-GCM. O formato de saída cifrado é [version:1B][iv:12B][authTag:16B][ciphertext], empacotado num campo binário único.

Esta hierarquia permite rotação eficiente de chaves. Rodar uma Chave de Organização requer re-envolver as DEKs (uma operação de envolvimento de chaves) mas não re-cifrar todos os dados subjacentes. Rodar uma DEK significa que os novos dados usam a nova chave enquanto dados antigos permanecem legíveis através da DEK anterior mantida (marcada como ROTATED).

Cifragem de ponta a ponta

A hierarquia de três camadas descrita acima é cifragem do lado do servidor — protege dados em repouso na infraestrutura de Mandraki. A cifragem de ponta a ponta vai mais longe ao assegurar que o servidor nunca vê texto simples.

Mensagens (MLS). Utilizamos o protocolo Messaging Layer Security (MLS), padronizado como RFC 9420 pelo IETF. MLS foi desenhado especificamente para cenários de mensagens em grupo e oferece vários vantagens sobre abordagens mais antigas.

MLS utiliza uma estrutura de acordo de chave baseada em árvore chamada TreeKEM, que permite que um grupo de participantes estabeleça um segredo partilhado eficientemente. Quando um membro adere ou sai de um grupo, o material de chave é atualizado através de uma mensagem Commit que avança a época do grupo. Isto fornece sigilo prospetivo — comprometer as chaves de um membro num ponto no tempo não revela mensagens de épocas anteriores — e segurança pós-compromisso — o grupo recupera segurança após um compromisso assim que o material de chave do membro afetado é rodado.

Cada dispositivo de utilizador carrega pacotes de chaves MLS para o servidor. Estes são pacotes criptográficos de uso único que permitem que outros dispositivos os adicionem a um grupo sem necessitar do dispositivo estar online naquele momento. Quando um pacote de chaves é consumido, o dispositivo deve carregar frescos. O servidor armazena e distribui estes pacotes mas nunca tem acesso ao material de chave privada que contêm.

Os grupos MLS em Mandraki mapeiam para canais e fios de mensagens diretas. Quando envia uma mensagem num canal cifrado, o seu cliente cifra-a utilizando a chave de época atual do grupo. O servidor recebe texto cifrado, armazena-o, e distribui-o aos membros do grupo. Os seus clientes desencriptam-no localmente.

Cifragem SFrame para mídia

Cifrar mídia em tempo real — áudio e vídeo numa chamada em grupo — apresenta desafios diferentes dos de mensagens. A tolerância de latência é medida em milissegundos, não segundos. As taxas de dados são ordens de magnitude superiores. E a mídia passa através de uma Unidade de Encaminhamento Seletivo (SFU), que precisa de encaminhar pacotes para os participantes certos sem conseguir ver o conteúdo.

Utilizamos SFrame (RFC 9605) para cifragem de mídia, aplicado via WebRTC Encoded Transform API. Esta API permite que código JavaScript intercete frames de mídia codificados após codificação mas antes de pacotização, cifre-os, e passe o texto cifrado para a camada de transporte. Na extremidade recetora, os frames são desencriptados após reassembly mas antes de descodificação.

A vantagem chave do SFrame numa arquitetura SFU é que o SFU pode ainda realizar a sua função de encaminhamento — encaminhar pacotes de um participante para outros, tomar decisões adaptativas à largura de banda sobre quais camadas encaminhar — sem nunca ter acesso à mídia de texto simples. O SFU vê frames cifrados e encaminha-os como blobs opacos.

Autenticação e autorização

Mandraki utiliza autenticação baseada em JWT com tokens de acesso de vida curta (quinze minutos) e tokens de atualização de vida mais longa (sete dias). Os tokens de acesso contêm a identidade do utilizador, contexto de organização ativo, e papel.

A autorização é reforçada em múltiplos níveis. Os guardas ao nível de rota validam autenticação e verificam participação na organização. O org-access.guard verifica que o utilizador autenticado é um membro da organização especificada no pedido. Os guardas baseados em papéis (OWNER, ADMIN, MEMBER) restringem acesso a operações administrativas.

Para utilizadores de múltiplas organizações, o contexto da organização é definido no login ou através do ponto final de comutação de organização. Os tokens JWT são limitados a uma única organização, portanto comutar organizações emite um novo token.

Multi-tenancy e isolamento de dados

Mandraki é uma plataforma multi-tenant onde o isolamento de dados entre organizações é reforçado na camada da aplicação. Cada consulta de base de dados inclui um filtro de ID da organização. Os padrões de consulta ORM Prisma asseguram que o acesso a dados entre tenants é estruturalmente evitado.

A participação na organização é rastreada através da tabela OrgMembership, que regista a relação utilizador-organização juntamente com o papel do utilizador e a bandeira de organização primária. A auto-captura verificada por domínio automaticamente encaminha novos inscritos para a organização apropriada com base no seu domínio de correio.

Registo de auditoria

A segurança não é apenas sobre prevenção — é sobre detecção e responsabilização. Mandraki mantém registos de auditoria para operações relevantes de segurança: eventos de autenticação (login, logout, atualização de token, tentativas falhadas), mudanças de participação na organização (adesões, saídas, mudanças de papel), operações de cifragem (geração de chaves, rotação, importação BYOK, revogação), ações administrativas (mudanças de definições, verificação de domínio, pedidos de federação), e eventos de ciclo de vida de chamada (criação, adesão, saída, término, início e fim de gravação).

Os registos de auditoria são armazenados com timestamps, identidade do ator, tipo de ação, e metadados relevantes. Estão acessíveis aos administradores da organização através da interface de gestão e podem ser exportados para integração com sistemas SIEM externos.

Arquitetura de rede

A infraestrutura de produção é segmentada por função. Os servidores de base de dados e Redis residem numa rede privada sem acesso à internet pública. Os servidores de aplicação acdem ao tier de dados através de endereços IP privados. O SFU tem portas voltadas para o público para tráfego de mídia WebRTC (UDP 40000-49999) e retransmissão TURN (UDP/TCP 3478, TLS 5349). O tráfego HTTPS é terminado no proxy reverso nginx com certificados Let’s Encrypt.

O acesso SSH aos servidores utiliza autenticação de chave Ed25519 sem reversão de senha. O servidor de dados é acessível apenas via jump host a partir dos servidores de aplicação.

Considerações de resposta a incidentes

A nossa arquitetura é desenhada para suportar resposta rápida a incidentes. As organizações BYOK podem revogar a sua Chave Mestre para tornar imediatamente todos os dados inacessíveis. Os tokens de atualização podem ser revogados para forçar re-autenticação em todas as sessões. A participação na organização pode ser revogada para terminar imediatamente o acesso de um utilizador. As relações de federação podem ser cortadas para isolar uma organização de colaboradores externos.

Estes controlos fornecem os mecanismos que as equipas de segurança precisam para responder a cenários de compromisso decisivamente.

Melhoria contínua

A arquitetura de segurança nunca está terminada. Continuamente avaliamos o nosso design contra ameaças emergentes, novos padrões criptográficos, e requisitos regulatórios em evolução. O nosso compromisso é manter transparência sobre a nossa arquitetura, honestidade sobre as suas limitações, e diligência na sua melhoria.

Bem-vindas perguntas e feedback de equipas de segurança a avaliar Mandraki. Compreender a nossa arquitetura em detalhe não é apenas permitido — é encorajado.