Case Paper: Uma Arquitectura Nacional Resiliente para o Estado Digital

Resumo executivo

Este case paper propõe uma arquitectura nacional resiliente para os sistemas digitais críticos do Estado português. A solução baseia-se em dois data centers centrais, um em Lisboa e outro no Porto, ambos equipados com plataformas IBM mainframe/LinuxONE a correr Linux e virtualização empresarial, servindo como núcleo soberano dos serviços críticos nacionais.

Em complemento, são propostos nós distritais baseados em servidores x86, Linux, virtualização, PostgreSQL, caches locais, filas persistentes e API gateways regionais. Estes nós garantem operação local, menor latência, continuidade em modo degradado e sincronização controlada com os centros nacionais.

A arquitectura procura resolver um problema estrutural: a fragmentação tecnológica do Estado. Durante décadas, demasiados organismos públicos foram criando sistemas próprios, bases de dados isoladas, integrações frágeis, dependências de fornecedores, camadas aplicacionais sem arquitectura comum e mecanismos de continuidade insuficientes. O resultado é previsível: falhas, redundâncias inúteis, custos elevados, pouca interoperabilidade, segurança inconsistente e dificuldade de resposta em crise.

A proposta aqui descrita não pretende ser uma moda tecnológica. Pretende ser engenharia de Estado. E isso, num país onde muitas vezes se confunde transformação digital com compra de plataformas, já é quase um acto de insubordinação racional.

1. Problema a resolver

O Estado português depende hoje de sistemas digitais para quase todos os serviços essenciais: saúde, finanças, segurança social, justiça, identificação civil, administração interna, protecção civil, educação, registos, contratação pública e serviços municipais ou distritais.

Porém, uma grande parte da infra-estrutura pública evoluiu por acumulação, não por arquitectura. Cada ministério, instituto, direcção-geral ou entidade foi criando sistemas próprios, muitas vezes através de concursos isolados, fornecedores distintos e decisões tácticas de curto prazo.

O resultado é uma manta de retalhos digital:

• bases de dados dispersas;
• integrações ponto-a-ponto;
• ambientes tecnológicos heterogéneos sem governação comum;
• dependência excessiva de fornecedores;
• modelos de segurança inconsistentes;
• backups nem sempre imutáveis ou testados;
• continuidade de negócio insuficiente;
• falta de observabilidade transversal;
• ausência de uma verdadeira arquitectura nacional de dados.

Esta fragilidade manifesta-se sempre que há falhas em sistemas centrais, indisponibilidade de serviços públicos, ataques informáticos, degradação de plataformas ou dificuldade de integração entre organismos. E depois vêm os comunicados, os inquéritos, as promessas de modernização e a inevitável comissão de acompanhamento. A civilização administrativa a fazer o seu número habitual de sapateado em cima do servidor caído.

2. Princípio arquitectural

A proposta assenta num princípio simples:

Isto significa que os dados estruturantes do Estado devem residir em plataformas centrais robustas, replicadas, auditáveis e fortemente protegidas. Ao mesmo tempo, os serviços de atendimento e operação regional devem poder funcionar localmente, mesmo em caso de falha temporária de comunicação com o núcleo nacional.

A arquitectura não deve criar um Estado hipercentralizado, cego à realidade operacional do território. Também não deve criar pequenos feudos distritais com dados próprios e regras próprias. O equilíbrio está na combinação entre centralização estratégica e autonomia operacional controlada.

3. Desenho físico da solução

O desenho físico propõe dois data centers nacionais principais:

• Data Center Nacional A — Lisboa
• Data Center Nacional B — Porto

Ambos devem possuir capacidade para alojar cargas críticas, bases de dados nacionais, serviços aplicacionais, autenticação, integração, monitorização, segurança e continuidade de operação.

                           ┌──────────────────────────────────────┐
                           │       DATA CENTER NACIONAL A          │
                           │              LISBOA                  │
                           │                                      │
                           │  IBM Mainframe / LinuxONE             │
                           │  Linux / zVM / KVM                    │
                           │  PostgreSQL Central                   │
                           │  Serviços críticos nacionais          │
                           │  IAM / API Gateway / SIEM             │
                           │  Storage Enterprise                   │
                           │  Backups locais imutáveis             │
                           └──────────────────┬───────────────────┘
                                              │
                 Replicação síncrona para dados críticos
                 Replicação assíncrona para dados operacionais
                                              │
                           ┌──────────────────┴───────────────────┐
                           │       DATA CENTER NACIONAL B          │
                           │               PORTO                  │
                           │                                      │
                           │  IBM Mainframe / LinuxONE             │
                           │  Linux / zVM / KVM                    │
                           │  PostgreSQL Central Replicado         │
                           │  Serviços críticos nacionais          │
                           │  IAM / API Gateway / SIEM             │
                           │  Storage Enterprise                   │
                           │  Capacidade de takeover nacional      │
                           └──────────────────┬───────────────────┘
                                              │
                         Rede nacional segura do Estado
                 MPLS / SD-WAN / VPN cifrada / linhas dedicadas
                                              │
        ┌─────────────────────────────────────┼─────────────────────────────────────┐
        │                                     │                                     │
┌───────▼────────┐                    ┌───────▼────────┐                    ┌───────▼────────┐
│ Nó Distrital 1 │                    │ Nó Distrital 2 │                    │ Nó Distrital N │
│ Linux / x86    │                    │ Linux / x86    │                    │ Linux / x86    │
│ PostgreSQL     │                    │ PostgreSQL     │                    │ PostgreSQL     │
│ Serviços locais│                    │ Serviços locais│                    │ Serviços locais│
│ Cache local    │                    │ Cache local    │                    │ Cache local    │
│ Filas locais   │                    │ Filas locais   │                    │ Filas locais   │
│ API Gateway    │                    │ API Gateway    │                    │ API Gateway    │
└────────────────┘                    └────────────────┘                    └────────────────┘
  

Para além destes dois centros, recomenda-se uma terceira localização com função de cofre digital soberano. Este local não tem de operar serviços em tempo real. A sua missão é conservar cópias imutáveis, cifradas e testadas dos dados críticos do Estado.

                           ┌──────────────────────────────────────┐
                           │       COFRE DIGITAL SOBERANO          │
                           │   Interior / Ilhas / local separado   │
                           │                                      │
                           │  Backups imutáveis                    │
                           │  Snapshots cifrados                   │
                           │  Repositório air-gapped               │
                           │  Arquivo de logs críticos             │
                           │  Recuperação pós-ransomware           │
                           └──────────────────────────────────────┘
  

4. Núcleo central: IBM mainframe/LinuxONE

Os sistemas centrais devem assentar em plataformas IBM mainframe/LinuxONE, a correr Linux empresarial e mecanismos de virtualização como z/VM, KVM ou outro modelo adequado à plataforma.

A opção por uma plataforma desta natureza justifica-se por várias razões:

• elevada resiliência;
• consolidação de cargas críticas;
• forte capacidade de virtualização;
• segurança avançada;
• alta disponibilidade;
• capacidade para cargas transaccionais intensas;
• operação Linux em ambiente empresarial;
• redução de dispersão física de servidores críticos.

A ideia não é regressar ao passado. É recuperar uma virtude que o passado tecnológico conhecia bem: a centralidade robusta. O mainframe moderno não é museu. É uma plataforma de consolidação crítica, agora com Linux, virtualização, segurança e integração com arquitecturas contemporâneas.

Em linguagem menos cerimonial: é preferível ter uma coluna vertebral robusta do que uma coleção de vértebras soltas compradas por concurso público, cada uma com manual, fornecedor e desculpa própria.

5. Nós distritais Linux/x86

Os nós distritais devem garantir operação local de serviços públicos, proximidade ao cidadão, continuidade funcional em caso de falha de comunicação e redução da pressão directa sobre os data centers centrais.

Cada nó distrital pode ser composto por:

• servidores x86 redundantes;
• Linux empresarial;
• virtualização KVM, Proxmox Enterprise, OpenShift Virtualization ou solução equivalente;
• PostgreSQL local;
• cache local de dados autorizados;
• filas persistentes de eventos;
• API Gateway local;
• sistema local de logs;
• sincronização segura com Lisboa e Porto;
• capacidade de funcionamento em modo degradado.

Estes nós não devem ser mini-Estados informáticos. Devem seguir padrões nacionais obrigatórios, com imagens de sistema controladas, actualizações centralizadas, configuração por código, políticas de segurança uniformes e observabilidade integrada.

6. Arquitectura lógica

┌──────────────────────────────────────────────────────────────────────┐
│                       CAMADA NACIONAL CRÍTICA                         │
│                                                                      │
│  Identidade civil | Finanças | Segurança Social | Saúde               │
│  Justiça | Administração Interna | Protecção Civil | Registos          │
│                                                                      │
│  Executa nos Data Centers Centrais: Lisboa e Porto                    │
└──────────────────────────────────────────────────────────────────────┘
                                  │
                                  ▼
┌──────────────────────────────────────────────────────────────────────┐
│                     CAMADA DE INTEGRAÇÃO NACIONAL                     │
│                                                                      │
│  API Gateway nacional | Barramento de eventos | Filas                 │
│  IAM | Catálogo de serviços | Auditoria | Contratos de dados          │
└──────────────────────────────────────────────────────────────────────┘
                                  │
                                  ▼
┌──────────────────────────────────────────────────────────────────────┐
│                     CAMADA OPERACIONAL DISTRITAL                      │
│                                                                      │
│  Atendimento local | Serviços regionais | PostgreSQL local            │
│  Cache | Filas locais | Operação degradada | Sincronização             │
└──────────────────────────────────────────────────────────────────────┘
  

A camada nacional crítica deve alojar os serviços e dados estruturantes do Estado. A camada de integração deve impedir a velha praga das ligações ponto-a-ponto, onde cada aplicação fala com outra por atalhos obscuros, como se o Estado fosse um bairro tecnológico sem planta cadastral. A camada distrital deve permitir operação próxima, resiliente e controlada.

7. Modelo de dados

A arquitectura distingue três classes principais de dados.

7.1 Dados críticos nacionais

Incluem identidade civil, dados fiscais, segurança social, registos essenciais de saúde, justiça, propriedade, protecção civil e outros dados estruturantes.

Modelo recomendado:

• PostgreSQL central;
• replicação síncrona entre Lisboa e Porto quando a perda de dados não é aceitável;
• RPO próximo de zero;
• RTO muito baixo;
• arquivamento contínuo de WAL;
• backups imutáveis;
• auditoria transaccional completa.

7.2 Dados operacionais distritais

Incluem processos locais, atendimentos, dados temporários, documentos pendentes, caches autorizadas e filas de trabalho.

Modelo recomendado:

• PostgreSQL local;
• sincronização assíncrona com os centros nacionais;
• filas persistentes para eventos;
• confirmação posterior;
• reconciliação automática;
• resolução de conflitos por domínio funcional.

7.3 Dados analíticos

Incluem estatística, planeamento, BI, auditorias agregadas, modelos de IA e análise de políticas públicas.

Estes dados não devem sobrecarregar os sistemas transaccionais. Devem ser alimentados por CDC, eventos ou processos ETL controlados para uma camada separada de data lake e data warehouse.

Sistemas transaccionais PostgreSQL
        │
        ▼
CDC / Eventos / WAL controlado
        │
        ▼
Data Lake Nacional
        │
        ▼
Data Warehouse / BI / Estatística / IA
  

8. Replicação e continuidade

A replicação deve ser definida por criticidade. Nem tudo deve ser síncrono. Nem tudo deve ser assíncrono. Arquitectura séria é saber distinguir. A alternativa é replicar tudo para todo o lado e esperar que os conflitos se resolvam por inspiração divina, uma estratégia muito popular entre desastres anunciados.

Tipo de informação	Modelo de replicação	Objectivo
Dados vitais nacionais	Síncrona Lisboa-Porto	Perda zero ou quase zero
Dados administrativos	Assíncrona controlada	Escalabilidade e menor latência
Dados distritais	Local + sincronização posterior	Continuidade local
Logs de auditoria	Streaming contínuo	Rastreabilidade e investigação
Dados analíticos	CDC / eventos	Não afectar produção
Backups	Imutáveis, cifrados, testados	Recuperação garantida

9. Fluxo operacional típico

1. Cidadão ou funcionário acede a serviço público.
2. Pedido entra pelo API Gateway distrital ou nacional.
3. Autenticação é feita via identidade federada.
4. Serviço consulta dados locais em cache, se autorizado.
5. Se a operação for crítica, valida no centro nacional.
6. Transacção é registada em PostgreSQL.
7. Evento é gravado numa fila persistente.
8. Evento é sincronizado com Lisboa e Porto.
9. Logs seguem para SIEM nacional.
10. Dados analíticos seguem para Data Lake / BI.
  

Este fluxo permite desacoplar aplicações, preservar rastreabilidade, garantir continuidade e impedir a velha dependência de integrações frágeis onde cada sistema conhece demasiado sobre o outro. Sistemas demasiado íntimos acabam como certas relações humanas: cheios de dependências, ressentimentos e falhas difíceis de diagnosticar.

10. Segurança

A segurança deve ser transversal. Não pode ser uma camada final, colocada em cima da solução como quem põe verniz num móvel torto.

A arquitectura deve seguir princípios de Zero Trust:

• nenhum acesso deve ser implicitamente confiável;
• todos os acessos devem ser autenticados, autorizados e auditados;
• os privilégios devem ser mínimos e contextuais;
• os serviços devem comunicar com mTLS;
• os segredos devem ser geridos por cofre central;
• as chaves devem ser protegidas por HSM ou KMS soberano;
• os logs devem ser imutáveis;
• a segmentação deve impedir movimento lateral;
• os acessos administrativos devem passar por bastion hosts;
• as operações críticas devem exigir MFA e dupla validação quando aplicável.

Componentes recomendados:

• IAM nacional;
• PKI interna;
• mTLS entre serviços;
• HSM/KMS soberano;
• SIEM nacional;
• EDR/XDR nos servidores;
• WAF para serviços expostos;
• gestão central de segredos;
• scanning contínuo de vulnerabilidades;
• gestão disciplinada de patches;
• backups imutáveis;
• testes regulares de recuperação.

11. Observabilidade e operação

Um sistema nacional crítico tem de ser observado em tempo real. Não basta saber que "está em baixo" quando os cidadãos começam a telefonar e as televisões fazem rodapé vermelho.

A plataforma deve monitorizar:

• estado dos serviços;
• tempos de resposta;
• erros aplicacionais;
• estado da replicação;
• atrasos nas filas;
• CPU, memória, disco e rede;
• falhas de autenticação;
• tentativas de acesso anómalas;
• estado dos backups;
• capacidade disponível;
• eventos de segurança;
• SLA por serviço público.

A observabilidade deve incluir métricas, logs, traces, auditoria, alertas, dashboards nacionais, dashboards distritais e relatórios automáticos de desempenho.

12. Modos de falha e recuperação

12.1 Falha de Lisboa

O data center do Porto assume os serviços críticos, com activação de planos de failover, redireccionamento de tráfego, validação de integridade e monitorização reforçada.

12.2 Falha do Porto

Lisboa mantém operação plena, com degradação controlada apenas nos serviços cuja replicação ou distribuição dependia do centro secundário.

12.3 Falha de ligação distrital

O nó distrital entra em modo degradado. Operações locais autorizadas continuam. Eventos são guardados em fila local. Quando a comunicação regressa, os dados são sincronizados e reconciliados.

12.4 Ransomware ou corrupção lógica

Sistemas afectados são isolados, credenciais são rodadas, snapshots são validados, logs imutáveis são preservados e a recuperação é feita a partir de backups limpos armazenados no cofre digital soberano.

13. Governação técnica

A arquitectura só funciona se existir uma entidade técnica nacional com autoridade real. Não mais uma agência decorativa, não mais um observatório de observação, não mais uma comissão para acompanhar a comissão anterior. Uma entidade técnica, competente e vinculativa.

Essa entidade poderia chamar-se:

As suas funções seriam:

• definir normas técnicas vinculativas;
• aprovar arquitecturas dos organismos públicos;
• manter catálogo nacional de APIs;
• validar modelos de dados;
• definir padrões de segurança;
• auditar continuidade e recuperação;
• impedir feudos tecnológicos;
• reduzir dependência de fornecedores;
• garantir interoperabilidade;
• manter equipas internas altamente qualificadas;
• proteger a soberania tecnológica do Estado.

Sem governação, a melhor arquitectura será devorada pela velha máquina: cada organismo a comprar a sua plataforma, cada fornecedor a criar a sua dependência, cada ministério a reinventar autenticação, base de dados, integração e desastre. A tragédia nacional em modo distribuído.

14. Plano de implementação

Fase 1 — Inventário e classificação

• inventário de sistemas existentes;
• classificação de criticidade;
• levantamento de dependências;
• identificação de dados soberanos;
• mapeamento de contratos e fornecedores;
• avaliação de riscos e continuidade.

Fase 2 — Construção do núcleo nacional

• instalação dos data centers Lisboa e Porto;
• implementação da plataforma IBM/LinuxONE;
• criação do IAM nacional;
• definição da PKI interna;
• implementação do SIEM;
• plataforma PostgreSQL central;
• backup imutável e cofre digital soberano.

Fase 3 — Nós distritais piloto

• instalação de 2 ou 3 nós distritais piloto;
• testes de operação local;
• testes de falha de comunicação;
• sincronização de dados;
• validação de caches e filas;
• medição de latência e resiliência.

Fase 4 — Migração progressiva

• migração por domínio funcional;
• integração por APIs;
• replicação controlada;
• desactivação gradual de sistemas redundantes;
• normalização de dados;
• criação de equipas de operação nacionais e distritais.

Fase 5 — Exercícios de crise

• teste de falha total de Lisboa;
• teste de falha total do Porto;
• teste de ransomware;
• teste de corrupção lógica de base de dados;
• teste de operação distrital isolada;
• teste de recuperação a partir do cofre digital soberano.

15. Benefícios esperados

• maior resiliência dos serviços públicos;
• redução de indisponibilidades nacionais;
• continuidade em caso de catástrofe;
• maior soberania tecnológica;
• menor dependência de fornecedores proprietários;
• melhor governação de dados;
• maior segurança;
• melhor interoperabilidade entre organismos;
• menor duplicação de sistemas;
• melhor capacidade de auditoria;
• base sólida para estatística, planeamento e IA pública;
• operação local resiliente;
• redução de custos estruturais a médio prazo;
• melhor confiança dos cidadãos nos serviços digitais do Estado.

16. Riscos e mitigação

Risco	Mitigação
Centralização excessiva	Nós distritais com autonomia controlada e operação degradada.
Latência entre Lisboa e Porto	Replicação síncrona apenas para dados críticos; assíncrona para restantes domínios.
Dependência de fornecedor central	Linux, PostgreSQL, standards abertos, equipas internas e contratos reversíveis.
Resistência institucional	Autoridade técnica vinculativa e migração gradual por domínio.
Ransomware	Backups imutáveis, cofre digital soberano, segmentação e testes regulares de recuperação.
Caos de integrações	API Gateway, catálogo nacional de APIs, barramento de eventos e contratos de dados.

17. Síntese conceptual

A arquitectura pode ser resumida numa fórmula:

Ou, em linguagem ainda mais directa:

Conclusão

Uma arquitectura digital de Estado não deve ser desenhada a partir da moda tecnológica do momento. Deve ser desenhada a partir dos riscos, dos serviços críticos, dos cidadãos, da soberania, da continuidade e da capacidade de recuperação.

A proposta aqui apresentada assenta em princípios clássicos de engenharia: redundância, simplicidade, isolamento, replicação, governação, segurança, observabilidade e operação disciplinada. Não procura deslumbrar. Procura funcionar. O que, em matéria de Estado digital, já seria quase uma revolução silenciosa.

O Estado português não precisa de mais ilhas tecnológicas. Precisa de arquitectura. Não precisa de mais slogans sobre transformação digital. Precisa de plataformas resilientes, dados governados, equipas competentes, segurança real e continuidade testada. Não precisa de comprar futuro por catálogo. Precisa de o desenhar, operar e defender.

Esta solução permitiria ao Estado continuar a funcionar perante falhas regionais, ataques, catástrofes, indisponibilidades de rede ou degradação parcial de sistemas. Permitiria também criar uma base sólida para interoperabilidade, planeamento público, estatística, inteligência artificial, serviços digitais modernos e soberania tecnológica.

A diferença entre ter tecnologia e ter arquitectura é simples: a tecnologia existe quando tudo corre bem; a arquitectura revela-se quando algo falha.

E um Estado digno desse nome deve ser desenhado para continuar de pé precisamente quando algo falha.