Nuvem Brasil · proposta ao setor público

Uma nuvem brasileira para o setor público, distribuída e soberana, feita de software livre.

A Nuvem Brasil é a proposta da pop.coop para que União, estados e municípios hospedem seus serviços em data centers espalhados pelo território nacional, sobre QEMU/KVM, Proxmox VE, VyOS, HAProxy e PowerDNS. O Rudder é o painel que já opera DNS, proxy, firewall, e-mail e certificados em produção, e está sendo estendido para comissionar capacidade, isolar dados por classe de nó e manter o serviço no ar mesmo quando uma região inteira cai.

Conhecer a proposta Modelo de segurança

Rudder em produção desde abril de 2026 · 100% software livre · IPv6 nativo · proposta independente, sem vínculo oficial com o gov.br

Abril/2026em produção na infraestrutura da pop.coop
3.000+testes automatizados a cada mudança, cobertura mínima de 95%
27decisões de arquitetura registradas (ADRs)
0nuvens estrangeiras hospedando ou processando dados

Em 1 minutogestão

O essencial da proposta, para quem decide.

Cada seção desta página indica a quem se destina: gestão ou técnico.

O que é
A proposta de uma nuvem para o setor público em data centers no Brasil, feita de software livre (Proxmox VE, VyOS, HAProxy, PowerDNS) e operada pelo Rudder, o painel da pop.coop, sob licença GNU AGPL-3.0-only. Hoje o Rudder opera a infraestrutura da própria pop.coop.
Problema que resolve
A dependência de nuvens e serviços estrangeiros: jurisdição de fora, custo em dólar, aprisionamento ao fornecedor e capacidade técnica que não fica no órgão.
O que já funciona
DNS, proxy, firewall e e-mail institucional em produção desde abril de 2026, e certificados automáticos desde agosto, com trilha de auditoria de cada mudança.
O que ainda vem
Criação automática de servidores, failover entre regiões e proteção de dados em disco e em memória com hardware novo. Cada item tem a situação declarada nesta página.
O que muda para o órgão
Dados no país, custo em reais, prova de cada mudança para o controle externo e equipe própria capacitada.
Como começa
Diagnóstico das dependências externas, piloto com um serviço de baixo risco e operação assistida até a equipe local assumir.

O problemagestão

Hoje, o caminho até um serviço público brasileiro passa por empresas de fora.

Portais, sistemas e e-mails de ministérios, estados, prefeituras e autarquias costumam depender de nuvens, CDNs e serviços de DNS estrangeiros. Funciona, mas cria seis riscos estruturais que nenhum órgão controla.

Jurisdição estrangeira

Dados de cidadãos ficam com provedores sujeitos a leis de outros países, inclusive leis de acesso extraterritorial a dados. Cláusulas contratuais atenuam o risco, mas não afastam essa jurisdição.

Custo em dólar

Faturas indexadas ao câmbio, com preços e planos que mudam sem negociação. O orçamento público não acompanha.

Aprisionamento tecnológico

Configurações, automações e integrações ficam presas ao fornecedor. Trocar custa mais do que ficar, mesmo quando o serviço piora.

Ponto único de falha

Quando um grande provedor global cai, caem juntos milhares de serviços que não têm relação entre si, inclusive os públicos.

O talento vai embora

A infraestrutura crítica fica fora do país, e com ela os empregos qualificados. Profissionais brasileiros acabam operando nuvens de outros países, e a capacidade técnica nacional não se acumula aqui.

Caixa-preta

Não há como auditar o que o provedor faz com o tráfego, nem provar para o controle externo como uma mudança foi feita e por quem.

A propostagestão

Nuvem Brasil: a infraestrutura do Estado em data centers do país, operada por quem é daqui.

Em vez de contratar capacidade em nuvens estrangeiras, o setor público passa a usar uma rede de clusters Proxmox VE distribuídos pelo território, com padrão técnico único e operação auditável. Cada região funciona sozinha; o Rudder é a camada de operação acima delas, que registra cada mudança e vai coordenar a alocação de cargas entre regiões.

Soberania da pilha

Do hipervisor ao DNS, cada componente é software livre consagrado no mundo inteiro. Todo o código pode ser auditado e compilado no Brasil, e nenhuma peça para de funcionar se uma assinatura estrangeira for cancelada.

Distribuída por região

Clusters autônomos em regiões diferentes, desenhados para que a queda de uma região, por fibra ou energia, não derrube o serviço: as cargas críticas passam a rodar em outra.

Segurança em camadas

Proteção do dado em trânsito (em produção), em disco e em memória (com a renovação do hardware), para que a confiança em cada nó venha de verificação criptográfica, e não de reputação.

Isolamento por classe de nó

Dados pessoais, bancos de ERP e cargas de setor público destinados a nós certificados; conteúdo público e dados já cifrados pelo órgão na capacidade comunitária.

Custo em reais

Hardware e operação no país, software sem licença obrigatória por núcleo ou por uso. O orçamento não depende do câmbio nem de mudança unilateral de plano.

Capacidade técnica nacional

Uma pilha aberta e documentada forma profissionais que operam a infraestrutura do próprio país, em vez de exportar horas de trabalho para nuvens de fora.

Sobre o nome. “Nuvem Brasil” é o nome desta proposta da pop.coop (PopSolutions Softwares & Comunicação) ao setor público. Não é um serviço oficial nem tem vínculo com o portal gov.br; a adoção por qualquer órgão depende dos instrumentos de contratação ou parceria cabíveis.

Soberania tecnológicagestão

Nada de caixa-preta: a nuvem é feita das mesmas peças que sustentam a infraestrutura do mundo.

A Nuvem Brasil não inventa um hipervisor nem um roteador próprio. Usa software livre com longo histórico em produção, comunidades globais e documentação pública. O que é original é a camada de operação, e ela também é software livre.

Virtualização

QEMU / KVM

Hipervisor integrado ao kernel Linux, a mesma base de virtualização usada por grandes nuvens públicas.

Plataforma

Proxmox VE

Gerência de clusters sobre Debian: máquinas virtuais, contêineres, alta disponibilidade, backup e armazenamento distribuído, com interface web e API.

Roteamento e firewall

VyOS

Roteamento aberto baseado em Linux: firewall com estado, NAT, BGP, VRRP e túneis. As versões rolling são gratuitas e o código compila localmente; as imagens LTS são por assinatura.

Proxy e balanceamento

HAProxy

Balanceador de carga e proxy reverso de referência, com roteamento por SNI e verificação de saúde dos servidores.

DNS

PowerDNS

Servidor DNS autoritativo com API, usado por provedores de hospedagem e operadores de rede.

Banco de dados

PostgreSQL

Banco relacional livre que guarda o estado do Rudder e sustenta as aplicações dos órgãos.

Rede de gestão

WireGuard + Headscale

Túneis cifrados com identidade por dispositivo para a rede de gestão e os serviços privados.

Identidade

Zitadel

Login único por OpenID Connect, com passkey obrigatória para administradores.

E-mail

Stalwart

Servidor de correio institucional com SMTP, IMAP, DKIM e DMARC.

Observabilidade

Prometheus + Grafana

Métricas, painéis e alertas de todos os equipamentos da rede.

Certificados

ACME

Emissão e renovação automáticas por protocolo aberto. Hoje a autoridade é a Let's Encrypt; qualquer autoridade compatível pode substituí-la.

Operação

Rudder

A camada que junta tudo: painel, API, validação, auditoria e política. Software livre sob a GNU AGPL-3.0-only.

Soberania é mais do que o endereço do servidor

É poder auditar o código, trocar de empresa de suporte sem migrar nada, formar a própria equipe e continuar operando se um contrato externo acabar. Com uma pilha livre, nenhuma dessas decisões fica fora do país.

Dependências externas, sem esconder. Hoje o Rudder usa quatro serviços de fora: a Let's Encrypt para certificados (substituível por qualquer autoridade ACME); a consulta a senhas vazadas do Have I Been Pwned, que recebe só os cinco primeiros caracteres do hash; alertas pelo Telegram; e um túnel IPv6 alternativo da Hurricane Electric, para redundância de trânsito. Nenhum deles hospeda ou processa dados dos serviços; o túnel apenas transporta pacotes, como qualquer operadora de trânsito.

O que é o Ruddertécnico

Um único painel sobre uma pilha inteira de software livre.

O Rudder não substitui os componentes de rede consagrados: ele os opera. Lê o estado vivo de cada um, compara com o que está registrado e deixa a equipe alterar por formulário, com validação antes de aplicar e registro depois.

  • Produção é a fonte da verdade. O painel importa o estado real dos servidores e mostra divergências, em vez de confiar em um arquivo que pode estar desatualizado.
  • Toda mudança passa por validação. Uma regra de firewall ou um backend novo é checado antes de ser aplicado; se o equipamento recusa, o Rudder desfaz.
  • Alta disponibilidade de fábrica. Duas bordas com failover automático e dois servidores DNS. Cada borda aplica a configuração em commit atômico, e qualquer divergência entre elas aparece no painel.
  • Multi-organização. Cada órgão ou secretaria enxerga e altera só o que é seu; a equipe operadora enxerga tudo, com registro.
  • IPv6 nativo. IPv4 e IPv6 chegam às bordas e passam pelo proxy em modo passthrough, sem abrir o TLS e sem NAT no IPv6. Expor um serviço em IPv6 direto ao servidor é opção por serviço.
Arquitetura de exposição: por padrão, o certificado TLS fica no servidor final do órgão e o proxy encaminha a conexão sem abri-la. A terminação na borda é opcional por domínio.

Comissionamento distribuídotécnico

Cada região é um cluster Proxmox VE: fácil de gerenciar, com curva de aprendizado curta.

Comissionar (ou provisionar) é colocar capacidade nova em serviço: receber o equipamento, instalar, verificar e liberar para cargas. Na Nuvem Brasil isso segue o mesmo padrão em qualquer lugar do país, e o Rudder conduz o processo, do cadastro do cluster, já em produção, à publicação do serviço, em construção.

  • Gerência em uma tela. Máquinas virtuais (KVM) e contêineres (LXC), alta disponibilidade, backup e armazenamento distribuído (Ceph) no mesmo painel web, com API completa.
  • Curva de aprendizado menor. É Debian por baixo. Quem administra servidores Linux já conhece a base, sem precisar formar uma equipe dedicada a dezenas de serviços, como exigem plataformas de nuvem mais complexas.
  • Padrão único, variação só no físico. A mesma instalação vale para um data center regional ou para um cluster de um nó. O que muda (energia redundante, gerador, solar, controle de acesso) vira atributo do cluster e pesa na alocação.
  • Clusters não atravessam a internet. Cada cluster Proxmox é local à sua região. A coordenação entre regiões fica numa camada acima, e uma região continua operando se perder contato com as outras.
  • Sem aprisionamento. Formatos abertos de disco e de configuração: uma máquina virtual sai de um cluster e entra em outro sem conversão proprietária.

  1. Cadastro do cluster

    em produção

    O Rudder registra a API do Proxmox VE com um token próprio, guardado cifrado, e verifica o certificado do cluster pela autoridade certificadora ou por impressão digital fixada.

  2. Sonda e prontidão

    em produção

    Versão, nós, armazenamento e zonas de rede são lidos ao vivo; o painel aponta o que falta antes de o cluster receber cargas.

  3. Classificação física

    em produção

    Região, data center, energia redundante, gerador, solar e controle de acesso ficam registrados, com trilha de auditoria de cada alteração.

  4. Comissionamento da carga

    em construção

    Uma solicitação cria a máquina virtual no cluster escolhido e já publica DNS, proxy e certificado.

  5. Alocação por classe

    planejado

    A escolha do cluster passa a considerar a classe exigida pela carga: dado sensível só em nó certificado.

Capacidadestécnico

O que a equipe opera pelo painel, hoje.

Tudo abaixo está em uso em produção. Cada item corresponde a uma área do painel, com formulários, validação e trilha de auditoria.

Proxy reverso e ingresso

Publicação de sites e sistemas por domínio, com roteamento por SNI e, por padrão, TLS terminando no servidor final. Implantação por GitOps ou correção imediata, sempre com verificação de configuração antes do reload.

HAProxy · PROXY protocol v2

DNS autoritativo

Zonas e registros em dois servidores DNS, com detecção de divergência entre eles, importação de zonas existentes no formato BIND e verificação de delegação ao vivo.

PowerDNS · ns1 + ns2

Certificados TLS automáticos

Emissão e renovação via ACME com validação por DNS, inclusive certificados curinga, sem expor porta nenhuma para isso. Inventário de certificados com validade e status.

ACME DNS-01 · renovação automática

Firewall, NAT e alta disponibilidade

Regras de filtro, grupos de endereços, DNAT e SNAT aplicados nas duas bordas, com commit atômico em cada uma e divergência exibida. Failover de gateway (VRRP) operado pelo painel, com estado ao vivo.

VyOS · VRRP · sync-group

E-mail institucional

Domínios, contas e grupos em servidor de e-mail próprio, com verificação ao vivo de SPF, DKIM, DMARC e MX, e ciclo de vida do certificado do servidor de correio.

Stalwart Mail Server

Defesa de borda

Análise de tráfego por IP, país e sistema autônomo, com pontuação de risco, limite de taxa e bloqueio por revisão humana. Página de contestação para bloqueios e canal LGPD de remoção de dados.

observar primeiro, bloquear depois

Observabilidade e alertas

Painel ao vivo de CPU, memória, conexões e banda de cada equipamento; maiores consumidores de tráfego em tempo real; alertas e verificação paralela de saúde de todos os subsistemas.

Prometheus · Alertmanager

Redes e endereçamento

Alocação de VLANs e sub-redes por organização, classificação de endereços IPv6 por provedor de trânsito e túneis IPv6 alternativos geridos pelo painel.

VLAN · IPv6 upstreams

Acesso com confiança zero

Rede de gestão e serviços privados atrás de túnel criptografado com identidade por dispositivo, políticas de acesso e rotas anunciadas geridas pelo painel.

WireGuard · Headscale

Por dentrotécnico

Simples de ler, difícil de errar.

Painéis ilustrativos, com dados fictícios, reproduzindo as telas de DNS e de firewall. O produto real usa o mesmo desenho.

API e automaçãotécnico

Uma API somente leitura em produção, e um caminho declarado até a escrita.

Tudo o que o painel faz, um órgão também deveria poder fazer por programa: integrar com seus próprios sistemas, versionar a infraestrutura, automatizar a rotina. Esse caminho está sendo construído em etapas, e esta seção diz em que etapa cada peça está, sem antecipar nada.

  • Leitura primeiro, escrita depois. A API que está no ar hoje só lê. Nenhuma operação de escrita é exposta por ela: criar, alterar e apagar continuam passando pelo painel, com validação e trilha de auditoria.
  • Cada token com seu limite. O acesso é por token Bearer, com escopo declarado no próprio token, isolamento por organização e orçamento de requisições por token e por organização.
  • A escrita exige fundação, não atalho. A regra de negócio de DNS nasceu dentro do código das telas. Antes de abrir escrita por API, essa regra precisa viver fora do HTTP, para que painel e API cheguem à mesma validação e à mesma auditoria.
  • Compatibilidade em vez de mais um dialeto. O plano é falar a língua de uma API que as ferramentas de mercado já conhecem, para que o órgão não precise escrever integração nova nem treinar equipe num padrão exclusivo desta rede.

  1. REST somente leitura, versionada

    em produção

    Autenticação por token Bearer, escopo por token, isolamento por organização e orçamento de requisições por token e por organização. Os recursos disponíveis são: listar zonas DNS, listar domínios, listar backends e consultar o detalhe de um backend.

  2. Regra de DNS fora do HTTP

    em revisão

    A criação, a alteração e a remoção de registro de DNS saem do código das rotas e passam a viver numa camada de serviço reutilizável. Mudança proposta, ainda não integrada.

  3. Escrita por API

    planejado

    Depende da camada de serviço acima estar integrada. Nenhum endpoint de escrita está publicado.

  4. Fachada compatível com a API do AWS Route 53

    planejado

    Decidida, com plano escrito em fatias. Nada implementado até aqui.

  5. Cofre de segredos em alta disponibilidade

    planejado

    Cluster de três nós com quórum. É pré-requisito da assinatura compatível com a AWS: essa assinatura exige um segredo recuperável, enquanto o modelo atual guarda apenas o hash do token.

Os números da mudança em revisão. O arquivo de rotas de DNS perdeu 205 linhas e ganhou 37. Os 351 testes de rota de DNS que já existiam passam sem nenhuma alteração, o que é a prova de que o comportamento visível não mudou. Onze testes novos exercitam a camada de serviço diretamente, sem passar por HTTP. A suíte completa fecha com 4.151 testes passando. A pull request está aberta e ainda não foi integrada; até que seja, nada disso está em produção.

A fachada compatível com o Route 53, e o que ela não vai ser

O que está no plano

Uma fachada que aceita a assinatura SigV4 e o formato XML da API do Route 53, para que ferramentas consagradas funcionem contra a infraestrutura da cooperativa trocando apenas o endereço do endpoint: a linha de comando da AWS e a biblioteca boto3, o cert-manager do Kubernetes, o external-dns e o provedor Terraform da AWS. O compromisso é com o subconjunto que essas quatro ferramentas realmente usam, e cada uma delas rodando contra a fachada é o teste que decide se a fatia está pronta, dentro da integração contínua.

planejado SigV4 · XML · verificado por ferramenta

O que não vai ser

Não será compatibilidade de 100% com o Route 53, e não adianta prometer isso. Boa parte daquela API descreve recursos que só existem dentro da AWS: registros ALIAS apontando para serviços da própria AWS, políticas de tráfego, roteamento por latência e por geolocalização, verificações de saúde feitas pela frota da AWS e DNSSEC assinado pelo serviço de chaves deles. Nada disso tem equivalente nesta rede, e tentar imitar geraria uma API que responde bonito e faz outra coisa.

compatível no que as ferramentas usam, explícito no resto

Por que compatibilidade importa mais do que elegância. Um órgão que hoje automatiza DNS com cert-manager ou external-dns não precisa reescrever nada para sair de um provedor estrangeiro: aponta a ferramenta para cá. O aprisionamento tecnológico não se desfaz só trocando o servidor de lugar, ele se desfaz quando a saída custa pouco, nos dois sentidos.

O plano está escrito em fatias, item a item, no rastreador de tarefas do projeto, no Forgejo da cooperativa. O acesso para auditoria pode ser combinado com a pop.coop, como o do código.

Para onde vamostécnico

A ambição: operar a nuvem inteira por API. Nada disto existe hoje.

Esta seção é sobre rumo, não sobre entrega. Ela declara onde a cooperativa quer chegar e qual regra vai governar as escolhas pelo caminho. Nenhum dos domínios descritos aqui está disponível por API, nem em parte: o que existe por API hoje é leitura, como a seção anterior detalha, e todo o resto passa pelo painel.

Leia esta seção como intenção, não como catálogo

Tudo abaixo está etiquetado como intenção. Não há data, não há compromisso de entrega e não há endpoint publicado para nenhum destes sete domínios. Se alguma frase aqui soar como oferta, é erro de redação: o que está no ar está descrito na seção API e automação e na tabela Estado do projeto, e só ali.

O rumo, em uma frase

Que o Rudder passe a operar por API a nuvem inteira da cooperativa, em sete domínios: DNS, VLAN, firewall, comissionamento de máquina, redimensionamento de CPU, memória e disco, billing, organizações e usuários.

Hoje o que existe por API é leitura. Criar, alterar e apagar, em qualquer um desses domínios, continua sendo trabalho de painel.

A regra que governa o rumo

Compatibilidade com a AWS onde ela destrava ferramenta real, não por marca

Imitar a API de um provedor estrangeiro só se justifica quando existe, do outro lado, uma ferramenta concreta que passa a funcionar sem reescrita. É o caso do Route 53: existem o external-dns, o cert-manager e o provider Terraform, e é por causa deles que a fachada compatível vale o esforço. Onde não há ferramenta que a compatibilidade destrave, a API é própria — e é melhor assim, porque um vocabulário emprestado descreveria mal a infraestrutura real daqui.

E uma promessa que não pretendemos fazer: “100% compatível” com um alvo que muda todo mês não é promessa cumprível. O que se cumpre é outra coisa, verificável: “a ferramenta X funciona, e há teste automatizado provando isso a cada mudança”.

Os sete domínios, agrupados por natureza

Declarativos — DNS, VLAN, firewall

O sistema já é uma máquina de estado desejado para estes três: descreve-se o estado, ele reconcilia. É a natureza que melhor se presta a uma API. O DNS segue a fachada compatível com o Route 53, pela razão acima. VLAN e firewall terão API própria: o vocabulário da AWS — VPC, security group — não descreve a rede real daqui, que é feita de trunk e VLAN, regras de borda e allowlist por serviço. Traduzir para um vocabulário que não serve produziria uma API que responde bonito e faz outra coisa.

intenção DNS compatível · VLAN e firewall próprios

Operacionais — criar máquina, redimensionar CPU, memória e disco

Estes agem sobre o virtualizador, e por isso o eixo mais útil provavelmente não é a AWS: é a API do próprio virtualizador somada aos padrões já consolidados no ecossistema Kubernetes, que é onde as equipes de fato automatizam ciclo de vida de carga. Compatibilidade no estilo EC2 entra se e quando o alvo for uma ferramenta concreta, pela mesma regra — nunca pela sigla.

intenção eixo a definir por ferramenta

Identidade — organizações e usuários

API própria, sem hesitação. O modelo de autorização já escolhido é de relações (ReBAC): quem pode o quê se deduz de vínculos entre sujeitos e recursos, não de documentos de política no estilo da AWS. São dois modelos mentais diferentes, e vestir um de outro só confundiria quem integra.

intenção ReBAC · API própria

Billing

API própria, e é o domínio em que a diferença é maior: o modelo de cobrança de uma cooperativa não é o de um provedor comercial, e copiar o desenho de fora traria junto pressupostos que contrariam o estatuto. Os pontos que sustentam essa escolha estão logo abaixo.

intenção desenho próprio

Billing: por que desenho próprio, e o que já está decidido

  • A unidade de cobrança é a organização. Não o projeto, não o recurso, não o usuário. É a organização que se associa, e é ela que recebe a conta.
  • Tier solidário é preço, não desconto. Modelar como abatimento sobre uma tabela cheia inverteria a relação: faria a tabela comercial ser a norma e a solidariedade parecer exceção concedida. O tier solidário é o preço daquele tier, ponto.
  • A medição sai do inventário que o sistema já mantém, em vez de um coletor novo. O que já é lido para operar a rede é o que alimenta a conta — menos peça para manter e menos oportunidade de as duas versões divergirem.
  • A fatura aponta para os fatos que a produziram. Toda mudança que afeta preço já deixa trilha de auditoria, e a fatura referencia as linhas dessa trilha. É isso que torna a conta contestável por quem paga — o que, numa cooperativa, é o ponto inteiro: o cliente é também o dono.
  • A fatura é documento imutável. Os números ficam congelados dentro dela. Recalcular o passado porque a tabela mudou não é cobrança, é reescrita de história.
  • Moeda, impostos e nota fiscal são problema brasileiro. Não há equivalente a copiar lá fora, então serão desenho próprio desde o começo, e não adaptação tardia de um modelo pensado para outra jurisdição.

O que ainda não está decidido. Se haverá pré-pago com crédito, ou apenas pós-pago. Se haverá limite de gasto com corte automático — e, se houver, o que fazer com o serviço de quem estourou o limite, que numa cooperativa não é pergunta óbvia: derrubar o serviço de um associado é diferente de suspender um cliente. E qual será o período de fechamento. Estas três continuam em aberto, e preferimos dizer isso a inventar resposta.

Por que publicar um rumo que ainda não é produto. Porque quem vai integrar precisa saber qual regra decide as escolhas antes de elas serem feitas, e porque um roteiro declarado é auditável: daqui a um ano dá para conferir o que virou código e o que não virou. O estado real, sempre, é o da tabela Estado do projeto.

Segurança de ponta a ponta em processamento distribuídotécnico

O paradoxo da confiança: verificação no lugar de fé.

O problema central de uma nuvem distribuída é que o dado sensível precisa rodar em equipamentos que ficam sob a guarda física de terceiros. O modelo da Nuvem Brasil não pede confiança cega: cada camada de proteção cobre um estado diferente do dado. A primeira já está em produção; as outras duas dependem de hardware recente.

Em trânsito

Cifrado do cidadão ao servidor

Por padrão, a borda encaminha a conexão TLS sem abri-la, e o certificado fica no servidor final; a terminação na borda existe como opção por domínio. O Rudder fala com cada sistema gerido (API do Proxmox VE, API do PowerDNS, bordas VyOS, proxies) com credencial própria guardada cifrada. O painel exige login único com passkey para administradores, e a rede de gestão fica atrás de túneis WireGuard com identidade por dispositivo.

TLS até o servidor final (padrão)em produção
Gestão por túnel com identidadeem produção
Passkey para administradoresem produção
Em repouso

Disco cifrado, chave condicionada ao boot

Os discos serão cifrados com chaves que o nó não guarda. A chave só é liberada depois que o equipamento prova, via TPM e registradores PCR, que inicializou exatamente o firmware, o kernel e o hipervisor esperados (boot medido). Se alguém altera o boot ou retira o disco, a chave não é entregue.

Segredos de integração cifradosem produção
Chave liberada por atestação TPMplanejado
Exige TPM 2.0 nos nós certificados.
Em uso

Memória cifrada durante o processamento

Com Intel TDX ou AMD SEV-SNP, o próprio processador cifra a memória da máquina virtual. Com atestação remota antes de a máquina receber dados, nem quem opera o hipervisor consegue ler o que está sendo processado.

Computação confidencialplanejado
Exige Intel TDX (Xeon de 5ª geração, ou modelos específicos da 4ª) ou AMD SEV-SNP (EPYC 7003 em diante), com suporte no hipervisor, que no Proxmox VE ainda é recente.

Com as três camadas, o dado fica protegido em trânsito, em disco e em memória, e a confiança no nó deixa de ser questão de reputação para virar verificação criptográfica. É isso que permite falar em ponta a ponta.

A relação é simétrica, não subordinada. O mesmo modelo que protege o órgão público protege quem hospeda o equipamento, porque o operador local também fica blindado contra acusação de vazamento.

O que já existe e o que vem. A proteção em trânsito está em produção. A liberação de chave por atestação e a memória cifrada dependem de hardware de geração recente e entram com a renovação do parque, começando pelos nós certificados. Até lá, a colocação de dados sensíveis é decidida caso a caso pela equipe operadora.

Controles de segurança já em produção

  • Trilha de auditoria completa. Cada ação registra autor, recurso, modo de aplicação, sucesso ou erro e o estado antes e depois, com filtros e link permanente por evento.
  • Papéis e isolamento por organização. Quatro papéis (administrador e usuário do órgão; operador e suporte da rede). Toda consulta passa por um filtro de escopo obrigatório.
  • Autenticação forte. Senhas com Argon2id e verificação contra vazamentos conhecidos; segundo fator TOTP com códigos de recuperação; login único via OpenID Connect com passkey obrigatória para administradores, mantendo senha + TOTP como acesso de emergência caso o provedor de identidade caia.
  • Reautenticação para ações sensíveis. Exclusões definitivas e mudanças de alto impacto exigem confirmar a identidade de novo, com janela curta.
  • Proteções de aplicação. Limite de taxa por usuário com bloqueio progressivo, verificação de origem em toda escrita (anti-CSRF), HSTS, política de conteúdo e cabeçalhos de segurança em todas as respostas.
  • Segredos cifrados. Credenciais de integração guardadas cifradas no banco; chaves SSH e de serviço fora do repositório, com permissões restritas.
  • LGPD na borda. Política de privacidade pública explicando o que a defesa de borda processa; canal formal de solicitação de remoção (art. 18), revisado por pessoa, sem apagamento automático que possa ser abusado.
  • Sem apagamento silencioso. Recursos são arquivados, não destruídos. A exclusão definitiva vive em uma única tela, restrita, com reautenticação e verificação de dependências.
  • Qualidade verificável. Mais de 3.000 testes automatizados contra banco PostgreSQL real, cobertura mínima de 95%, integração contínua obrigatória antes de qualquer publicação e verificação em produção após cada implantação.
  • Decisões documentadas. Vinte e sete registros de decisão de arquitetura (ADRs) explicam o porquê de cada escolha estrutural, do fluxo de trabalho ao modelo de confiança zero.

Isolamento por classe de nótécnico

Infraestrutura equivalente a Tier III, com controle de acesso, tem prioridade no isolamento.

Nem todo equipamento da rede oferece as mesmas garantias físicas, e fingir que oferece não protege ninguém. Por isso os nós são classificados, e a classe decide onde cada carga pode rodar.

Nós certificados

Para dados que exigem isolamento forte

Infraestrutura
Equivalente a Tier III do Uptime Institute (energia e refrigeração redundantes, com manutenção concorrente), com certificação ou auditoria independente.
Acesso físico
Controle de acesso auditável, com registro de quem entrou e quando.
Integridade
Atestação por TPM 2.0 funcionando.
Recebem
Dados pessoais sob a LGPD, bancos de dados de ERP e cargas de setor público.
Nós comunitários

Para cargas públicas ou opacas

Infraestrutura
Do rack corporativo ao equipamento reaproveitado, sempre no padrão único de instalação.
Recebem
Conteúdo público, cache e armazenamento de dados já cifrados pelo órgão (backups, objetos), cuja chave nunca chega ao nó.
Papel
Porta de entrada para instituições e parceiros participarem da rede com o que já têm.

Isso cria um incentivo claro: quem investe em infraestrutura equivalente a Tier III e em controle de acesso sobe de classe e passa a hospedar as cargas de maior valor.

O isolamento deixa de ser uma promessa genérica e vira critério de alocação, aplicado pelo Rudder quando a alocação por classe entrar em produção.

Os quatro perfis de infraestrutura da rede

PERFIL

Empresarial

Data center real: nobreak, gerador ou solar, múltiplos provedores e sistema autônomo próprio. Hospeda e-mail, DNS e o que não pode parar.

disponibilidade esperada: 99,9%+
PERFIL

Corporativo

Rack em escritório ou pequeno data center, servidores de linha, link empresarial com IP fixo. Produção estável.

disponibilidade esperada: 99,5%
PERFIL

Profissional

Equipamento reaproveitado em banda larga de qualidade. Homologação, réplicas de leitura e cargas tolerantes a reinício.

disponibilidade esperada: 99%
PERFIL

Solidário

Mini-PC em conexão residencial, com túnel IPv6 fornecido pela rede. Porta de entrada para quem quer participar sem grande investimento.

melhor esforço

em produção atributos físicos registrados por cluster (energia redundante, gerador, solar, controle de acesso) e perfil registrado por organização participante. planejado a alocação automática que usa essas informações.

A classe certificada está sendo estruturada: além do perfil físico, exige controle de acesso auditável e TPM 2.0, que entra com a renovação do parque. As disponibilidades acima são referências de projeto, não compromisso contratual.

Software livre sob a GNU AGPL-3.0-only

O Rudder é licenciado sob a GNU Affero General Public License v3.0, somente a versão 3: pode ser usado para qualquer fim, estudado, modificado e redistribuído. Quem distribui uma versão modificada, ou a oferece como serviço em rede, precisa publicar o código-fonte sob a mesma licença, o que impede que a operação da nuvem vire produto fechado de terceiros. É uma licença reconhecida pela Free Software Foundation e pela Open Source Initiative. Ela cobre o código; as marcas Rudder e pop.coop não são licenciadas.

Alta disponibilidade e failover distribuídotécnico

Desenhada para sobreviver à queda de uma região inteira.

O desenho tem dois níveis. Dentro de cada região, o próprio Proxmox VE mantém as cargas vivas. Entre regiões, o Rudder vai orquestrar o failover e mover o tráfego pela borda que ele já gerencia.

Dentro da região

Com HA configurado (três ou mais nós e armazenamento compartilhado ou replicado), o Proxmox VE isola o nó que falhou e reinicia máquinas virtuais e contêineres em outro nó, sem intervenção humana. Nas bordas, duas instâncias VyOS com VRRP e dois servidores DNS já operam em produção.

Proxmox VE HA · VRRP · ns1 + ns2

Entre regiões

Componentes sem estado, como os servidores web do Odoo, são recriados no destino. O PostgreSQL é replicado continuamente e, se uma região cai (por exemplo, com o rompimento dos dois links de fibra), a réplica é promovida e a borda (DNS e HAProxy) redireciona o tráfego.

planejado PostgreSQL · quórum com testemunha · DNS multi-região
Sem maioria, nenhuma região se promove sozinha. É isso que impede duas “primárias” ao mesmo tempo.

Replicação escolhida por carga, conforme a criticidade

ModoO que garanteO que custaIndicado para
SíncronaPerda zero enquanto a réplica síncrona está conectada: o commit só confirma depois que ela gravou.Commit mais lento, proporcional à distância. Se a réplica cai, escolhe-se entre pausar gravações ou seguir em modo assíncrono.Sistemas financeiros, tributários e registros oficiais.
AssíncronaGravação com latência baixa.Numa queda, pode perder os últimos segundos de gravação.Portais, conteúdo e cargas que toleram reprocessar.

Split-brain. Para evitar que duas regiões se declarem primárias ao mesmo tempo, a promoção exige quórum com uma testemunha em um terceiro local, que a topologia distribuída já oferece naturalmente.

em produção bordas com VRRP e DNS redundante dentro da região. planejado failover entre regiões. A arquitetura com testemunha de quórum e DNS que retira a região fora do ar está decidida para o banco do próprio Rudder, e a extensão às cargas dos órgãos segue o mesmo desenho.

Confiabilidade antes de latênciagestão

Por que “baixíssima latência” não responde ao problema.

Latência é quanto tempo uma requisição leva quando o sistema está no ar. Confiabilidade é se o sistema está no ar. São medidas diferentes, e para o serviço público é a segunda que decide.

Serviço A · origem única

Rápido, até cair

5 mslatência com o sistema no ar
4 hfora do ar na queda de fibra

Durante a interrupção de fibra, de região ou do fornecedor, a latência desse serviço é infinita.

Serviço B · distribuído

Um pouco mais longe, e continua no ar

30 mslatência com o sistema no ar
minutospara a réplica assumir

A região cai, a réplica assume e o serviço continua. Para quem opera um ERP, um banco comunitário ou um serviço público, 5 ms e 30 ms são imperceptíveis; estar ou não disponível é a própria operação.

Ilustração de um dia com incidente, não uma medição.

Cache rápido, origem única

A baixa latência de redes de borda centralizadas vale principalmente para conteúdo estático em cache. Aplicações dinâmicas continuam dependendo de uma origem única com banco de dados, e essa origem continua sendo o ponto único de falha.

Velocidade trocada por integridade

Latência mínima em banco de dados costuma vir justamente de replicação assíncrona, isto é, de aceitar perder as últimas gravações. A Nuvem Brasil inverte a prioridade: primeiro garante que o dado não se perde e que o serviço sobrevive à queda de uma região inteira, e só então otimiza latência onde ela realmente importa.

Em um país em que interrupções de fibra e de energia são eventos recorrentes, confiabilidade distribuída é o requisito. Latência é refinamento.

Vantagem educacional para o Brasilgestão

Formar no país quem opera a infraestrutura do país.

O Brasil forma bons profissionais de infraestrutura, e muitos deles acabam trabalhando para empresas e nuvens de fora, porque é lá que está a infraestrutura crítica. Uma nuvem nacional feita de software livre muda esse destino: o conhecimento vira patrimônio do país, e o trabalho qualificado fica aqui.

Conhecimento que não expira com o contrato

Linux, KVM, Proxmox VE, VyOS, HAProxy e PostgreSQL são competências universais e documentadas. Não dependem de certificação proprietária nem do console de um fornecedor.

Curva de aprendizado curta

O Proxmox VE roda sobre Debian e tem interface web completa. Quem vem de redes e Linux começa a operar logo e aprofunda com a prática, sem precisar dominar dezenas de serviços proprietários.

Laboratório real, não simulado

Institutos federais e universidades podem operar nós comunitários da rede e formar estudantes em infraestrutura de produção, no mesmo padrão de instalação de toda a rede.

Tudo documentado e auditável

Decisões de arquitetura registradas, trilha de auditoria de cada mudança e uma pilha de software livre com documentação pública. Quem estuda entende por que cada escolha foi feita, e não só onde clicar.

Emprego qualificado que fica aqui

Operação, suporte e evolução da nuvem pagos em reais, em cooperativas e empresas brasileiras. A renda circula no país e a experiência acumulada serve ao próximo projeto público.

Transferência, não dependência

O objetivo é que cada órgão possa assumir a própria operação. Uma equipe que domina a pilha livre não fica refém de nenhum fornecedor, inclusive da pop.coop.

Custosgestão

O que muda na estrutura do custo, antes do preço.

Preço depende do escopo de cada órgão e é definido no piloto. O que já dá para comparar é a estrutura: em que moeda se paga, o que é licença, quanto custa sair e para onde vai o dinheiro.

O tamanho da dependência

Um estudo acadêmico de grupos da USP e da UnB estimou em pelo menos R$ 23 bilhões, em valores nominais, os contratos do setor público brasileiro, nas três esferas, com licenças de software, nuvem e segurança de corporações estrangeiras entre 2014 e junho de 2025 (relatório “Contratos, Códigos e Controle”, noticiado pelo Jornal da USP em julho de 2025, com dados do Comprasnet e do PNCP). É valor contratado, não necessariamente pago, e inclui compras feitas por revendedores.

ComponenteNuvem estrangeira típicaNuvem Brasil
Moeda do contratoDólar, ou reais indexados ao câmbio.Reais.
Licença de softwareCobrada por núcleo, usuário ou consumo, com reajuste definido pelo fornecedor.Software livre, sem licença obrigatória. Suporte é serviço contratado, não licença.
Tráfego de saídaTarifa por gigabyte transferido para fora da nuvem é comum; desde 2024 os grandes provedores a dispensam, sob pedido, para quem está migrando.Definido no piloto.
PortabilidadeServiços proprietários precisam ser substituídos na saída.Discos de máquinas virtuais em formatos abertos (qcow2, raw), exportáveis com ferramentas livres.
Custo de trocar de fornecedorAlto: automações e serviços proprietários precisam ser refeitos.Menor: a pilha é livre. O Rudder poderá rodar com outra equipe ou em infraestrutura própria quando o código for publicado; até lá, o acesso ao código é combinado com a pop.coop.
Para onde vai o dinheiroEm grande parte, para fora do país.Operação e suporte contratáveis de cooperativas e empresas brasileiras. O hardware fica no país, mas a compra dele ainda sofre efeito do câmbio.
CapacitaçãoCertificações do próprio fornecedor.Competências universais em Linux, KVM e redes, que ficam com a equipe.

Quanto o câmbio pesa num contrato em dólar

Simulação só com os seus números: informe o valor anual de um contrato em dólar e veja o efeito de uma variação cambial no orçamento em reais.

Orçamento no câmbio de referência—
Com a variação—
Diferença em um ano—

Os valores iniciais são apenas um exemplo, não a cotação do dia. O simulador trata do contrato recorrente; equipamento importado, inclusive o da Nuvem Brasil, também sofre câmbio na compra. O cálculo roda no seu navegador e nada é enviado.

Conformidadegestão

O que as normas pedem e onde a proposta está, sem arredondar.

Leitura técnica da pop.coop sobre as normas mais citadas em contratações de nuvem, situação em 10 de setembro de 2026. Não é parecer jurídico: o enquadramento de cada contratação cabe ao jurídico do órgão.

NormaO que pedeComo a proposta respondeSituação
Portaria SGD/MGI nº 5.950/2023, item 5.4.5Dados armazenados em data centers localizados no Brasil.Todos os data centers da rede ficam no país.atende
LGPD, arts. 33 a 36Transferência internacional só nas hipóteses previstas em lei.Dados hospedados e processados no Brasil. Os serviços externos usados pelo Rudder (certificados, alertas) não recebem dados pessoais tratados pelos órgãos.atende
LGPD, arts. 6º, 46 e 49Segurança desde a concepção, prevenção e prestação de contas.TLS até o servidor final, segredos cifrados, trilha de auditoria e portões automáticos antes de cada deploy automático. Disco e memória cifrados dependem de hardware novo.parcial
LGPD, art. 48, e Res. CD/ANPD nº 15/2024Comunicar incidente relevante em até três dias úteis e registrar todo incidente por cinco anos.Monitoramento, alertas e trilha de auditoria em produção. O processo formal de resposta e comunicação de incidentes será estruturado com cada órgão.parcial
LGPD, art. 20Revisão de decisões tomadas só com base em tratamento automatizado.Na defesa de borda, bloqueio só depois de revisão humana, com página pública de contestação.atende
IN GSI/PR nº 5/2021, art. 25 (alterada pela IN nº 8/2025)Relatórios SOC 2 tipo I e tipo II como condição para licitar e renovar contratos de nuvem na administração federal.A pop.coop ainda não tem relatório SOC 2.pendente
IN GSI/PR nº 8/2025Informação classificada só em nuvem privada ou comunitária, em território nacional, com provedor habilitado como posto de controle.A infraestrutura fica no país, mas a pop.coop não é posto de controle habilitado. Informação classificada fica fora do escopo inicial.pendente
IN SGD/ME nº 94/2022, item 4.2.2, e Portaria nº 5.950/2023, item 8.5Portabilidade de dados e de software, sem custo adicional, e estratégia de saída.Software livre e formatos abertos tornam a saída tecnicamente simples. A cláusula contratual de portabilidade é definida no piloto.parcial
Lei nº 14.129/2021, art. 3º, XXVAdoção preferencial de tecnologias, padrões e formatos abertos e livres.Pilha de software livre e protocolos abertos: DNS, ACME, OpenID Connect e IPv6.atende
ePING (Portaria SLTI/MP nº 92/2014)IPv6 como padrão adotado de interconexão.IPv6 nativo em toda a rede, sem NAT.atende
Portaria STI/MP nº 46/2016 (Software Público Brasileiro)Licença compatível com a GNU GPL e versão estável publicada no repositório do Portal.A AGPL-3.0 é compatível com a GPLv3, mas o código ainda não foi publicado.pendente
Lei nº 13.146/2015, art. 63, e eMAG 3.1Acessibilidade de sítios e sistemas.Ainda sem auditoria formal de acessibilidade, do painel e desta página.pendente
Marco Civil da Internet, art. 15Guarda de registros de acesso a aplicações por seis meses, sob sigilo.A retenção de registros será definida em contrato com cada órgão, conforme o papel de cada parte.pendente

As duas pendências que mais pesam. Para contratos de nuvem na administração federal, a IN GSI/PR nº 5/2021 exige relatórios SOC 2, que a pop.coop ainda não tem, e a IN GSI/PR nº 8/2025 exige habilitação como posto de controle para informação classificada. As duas instruções se dirigem à administração pública federal; estados e municípios devem verificar as próprias regras.

Para governos e órgãos públicosgestão

O que muda para um ministério, um estado ou uma prefeitura.

O Rudder é a peça de operação da Nuvem Brasil e do programa de soberania digital da pop.coop. Na prática, um órgão passa a ter:

Dados e tráfego no Brasil

Portais e sistemas hospedados em nós da rede em território nacional. Por padrão, o certificado TLS fica no servidor do próprio órgão e ninguém no meio do caminho abre a conexão.

E-mail institucional próprio

Domínio do órgão em servidor de correio auditável, com SPF, DKIM e DMARC verificados pelo painel. Fim da dependência de suítes estrangeiras para a comunicação oficial.

DNS soberano

As zonas do órgão ficam em servidores autoritativos operados pela rede da Nuvem Brasil, com redundância e verificação de delegação, em vez de painéis de registradores de fora.

Prova para o controle externo

Cada mudança de configuração tem autor, data, motivo e resultado registrados. Tribunais de contas e controladorias recebem evidência, não relato.

Equipe local capacitada

O órgão opera pelo painel desde o primeiro dia e, se quiser, assume a operação completa. O objetivo é transferir capacidade, não criar um novo fornecedor indispensável.

Custo em reais, previsível

Infraestrutura no país e software sem licença obrigatória por uso. Sem surpresa cambial nem mudança unilateral de plano.

Como começa

Diagnóstico

Levantamento dos domínios, sistemas e e-mails do órgão e de onde cada um está hospedado hoje. Resultado: um mapa de dependências externas e um plano de migração por etapas.

Piloto

Um domínio e um serviço de baixo risco (o portal de transparência, por exemplo) migram para a rede. A equipe do órgão opera no painel com acompanhamento da pop.coop.

Operação assistida e transferência

Migração gradual do restante. A pop.coop opera junto até a equipe local estar confortável, com trilha de auditoria completa desde o primeiro dia.

Estado do projetogestão

Onde o Rudder está, sem exagero.

O software está em produção na infraestrutura da própria pop.coop, operando seus serviços e os de organizações associadas. Está em evolução ativa, e a tabela abaixo separa o que já é rotina do que ainda vem.

ÁreaSituaçãoDetalhe
Proxy, DNS, firewall, e-mailem produçãoOperação diária pelo painel, com importação do estado vivo e trilha de auditoria.
Certificados TLS automáticosem produçãoEmissão por ACME com validação DNS; modo de terminação na borda opcional por domínio.
Defesa de borda, observabilidade e alertasem produçãoAnálise de tráfego e pontuação de risco em modo de observação; bloqueio só após revisão humana.
IPv6 com múltiplos provedores de trânsitoem produçãoClassificação de endereços por provedor e túneis alternativos geridos pelo painel.
Login único e rede de gestão com confiança zeroem produçãoOpenID Connect com passkey para administradores e senha + TOTP como acesso de emergência; túneis WireGuard com identidade por dispositivo.
Cadastro e sonda de clusters Proxmox VEem produçãoRegistro por API com verificação do certificado do cluster, leitura ao vivo de nós, armazenamento e redes, e atributos físicos de cada cluster.
Comissionamento de cargasem construçãoCriação da máquina virtual com DNS, proxy e certificado publicados no mesmo fluxo.
API REST somente leituraem produçãoVersionada, com token Bearer, escopo por token, isolamento por organização e orçamento de requisições. Lista zonas DNS, domínios e backends, e o detalhe de um backend.
Regra de DNS em camada de serviçoem revisãoMudança proposta que tira criar, alterar e apagar registro de dentro das rotas HTTP. É a fundação da escrita por API. Ainda não integrada.
Escrita por APIplanejadoNenhum endpoint de escrita está publicado; depende da camada de serviço acima.
Fachada compatível com a API do AWS Route 53planejadoDecidida, com plano em fatias e nada implementado. Compatível com o subconjunto que a linha de comando da AWS, o boto3, o cert-manager, o external-dns e o provedor Terraform da AWS usam, não com a API inteira.
Cofre de segredos em alta disponibilidadeplanejadoPré-requisito da assinatura compatível com a AWS, que exige segredo recuperável; hoje o sistema guarda apenas o hash do token.
Alocação automática por classe de nóplanejadoO perfil por organização e os atributos físicos por cluster já existem; a alocação que os aplica está planejada.
Failover entre regiõesplanejadoArquitetura decidida para o banco do próprio Rudder (PostgreSQL com testemunha de quórum e DNS multi-região); a extensão às cargas dos órgãos segue o mesmo desenho.
Disco com chave liberada por atestaçãoplanejadoDepende de TPM 2.0 nos nós certificados.
Computação confidencialplanejadoIntel TDX ou AMD SEV-SNP, com a renovação do parque para processadores de geração recente.
Publicação do código-fonteplanejadoA licença já está definida (GNU AGPL-3.0-only); o repositório ainda é privado e a publicação está planejada. Acesso para auditoria por órgãos interessados pode ser combinado com a pop.coop.

Quem está por trásgestão

Quem propõe, como decide e como falar com a pop.coop.

A Nuvem Brasil é proposta pela pop.coop, iniciativa da PopSolutions Softwares & Comunicação em transição para o modelo cooperativo. A mesma equipe desenvolve o Rudder e opera a infraestrutura em que ele roda hoje.

Quem desenvolve é quem opera

A mesma equipe escreve o Rudder e o usa em produção todos os dias, na infraestrutura em que ele próprio roda.

Como as decisões são tomadas

Decisões estruturais ficam registradas em 27 ADRs, com contexto, decisão e consequências. O deploy automático para produção só roda depois que todos os portões de integração contínua passam.

Contato institucional

Pedidos de reunião, de diagnóstico ou de acesso ao código para auditoria: sysadmin@pop.coop.

Dados cadastrais

PopSolutions Softwares & Comunicação | Cooperação Digital. Razão social: PopSolutions.co Softwares e Comunicação Ltda. · CNPJ 55.087.795/0001-09 · sociedade empresária limitada, com sede em Barueri (SP). A pop.coop é a iniciativa da empresa em transição para o modelo cooperativo.

Glossário

Os termos técnicos desta página, em linguagem direta.

ACME
Protocolo aberto que emite e renova certificados TLS automaticamente.
ADR
Registro de decisão de arquitetura: documento curto com o contexto, a decisão tomada e suas consequências.
API REST e token Bearer
Interface para programas, no lugar de telas. O token Bearer é a credencial enviada em cada chamada, que diz quem chama e o que pode fazer.
Assinatura SigV4
Forma como a AWS autentica cada chamada à sua API: o cliente assina a requisição com um segredo compartilhado, em vez de só enviar o segredo.
Atestação (TPM)
Relatório assinado pelo chip TPM com as medições do que foi carregado no boot, que um verificador compara com os valores esperados.
Borda
Equipamento na entrada da rede, entre a internet e os servidores, que filtra e encaminha o tráfego.
Certificado TLS
Arquivo que prova a identidade de um site e permite a conexão cifrada, o cadeado do navegador.
Cluster
Conjunto de servidores que funcionam como um só e assumem o trabalho uns dos outros.
Comissionamento
Colocar capacidade nova em serviço: instalar, verificar e liberar para uso.
Computação confidencial (TDX, SEV-SNP)
Recurso do processador que cifra a memória de uma máquina virtual enquanto ela roda.
Confiança zero (zero trust)
Modelo em que nenhum acesso é confiável por estar dentro da rede: cada dispositivo prova quem é.
Copyleft (AGPL-3.0-only)
Cláusula de licença livre que obriga a oferecer o código-fonte, sob a mesma licença, a quem recebe cópias do programa e a quem usa pela rede uma versão modificada.
DNS autoritativo
Servidor que responde oficialmente qual endereço corresponde a cada domínio do órgão.
Failover
Troca automática para um equipamento ou uma região reserva quando o principal falha.
Infraestrutura como código
Descrever servidores, DNS e redes em arquivos versionados, aplicados por ferramenta, em vez de configurar à mão.
IPv6 e NAT
IPv6 é a versão mais recente do endereçamento da internet. NAT é a tradução de endereços que o IPv4 precisa por falta de números.
KVM e LXC
KVM roda máquinas virtuais completas; LXC roda contêineres, mais leves, que compartilham o sistema do servidor.
Latência
Tempo que uma requisição leva para ir e voltar.
OpenID Connect (login único)
Padrão em que uma única conta dá acesso a vários sistemas.
Passkey
Credencial sem senha, ligada ao aparelho ou ao gerenciador de senhas do usuário, resistente a phishing.
Passthrough
O proxy encaminha a conexão cifrada sem abri-la; só o servidor final lê o conteúdo.
Proxy reverso
Serviço na entrada que recebe as conexões e as entrega aos servidores certos.
Quórum e testemunha
Regra de maioria para decidir quem assume numa falha. A testemunha é o voto de desempate, num terceiro local.
Replicação síncrona e assíncrona
Cópia contínua de um banco de dados. Na síncrona, o banco só confirma a gravação depois que a cópia a recebeu; na assíncrona, confirma na hora e copia em seguida, podendo perder as últimas gravações numa queda.
SNI
Campo da conexão TLS que diz qual site o visitante quer, o que permite rotear sem abrir o conteúdo.
SPF, DKIM e DMARC
Registros de DNS que dizem quais servidores podem enviar e-mail pelo domínio e como tratar mensagens falsificadas.
Split-brain
Falha em que duas partes do sistema se declaram principais ao mesmo tempo e podem corromper os dados.
Tier III
Classificação de data center do Uptime Institute: energia e refrigeração redundantes, com manutenção sem desligar os serviços.
TOTP
Código temporário de seis dígitos, gerado por aplicativo, usado como segundo fator de login.
VRRP
Protocolo em que dois ou mais equipamentos compartilham um endereço, e outro assume se o principal cair.

Contato

Conversar com a pop.coop.

A pop.coop é a iniciativa da PopSolutions Softwares & Comunicação em transição para o modelo cooperativo. O diálogo institucional acontece por e-mail ou pelo formulário do programa, e o acesso ao código para auditoria é combinado por pedido.

Diálogo institucional

Formulário de contato da pop.coop para governos e organizações.

brasil.pages.pop.coop

E-mail institucional

Reuniões, diagnóstico e pedidos de acesso ao código para auditoria.

sysadmin@pop.coop

Programa de soberania digital

O PAC-ID, programa em que o Rudder se encaixa como infraestrutura de operação.

PROGRAMA-POP · Pilar 8