Segurança e Integridade

Segurança e integridade das nossas transações financeiras

Bancos como o nosso utilizam infraestruturas de servidores especializadas para tratar domínios operacionais distintos. Com base em requisitos arquitetónicos e na regulamentação financeira, os principais tipos de servidores incluem:

1. Servidores do Sistema Core Banking

Estes servidores constituem a espinha dorsal operacional central, assegurando a gestão das contas de clientes, das transações e da conformidade:

• Servidores de Processamento de Transações: Executam, em tempo real, a autorização de pagamentos, os controlos antifraude e as liquidações (por exemplo, SWIFT, SEPA).
• Servidores de Gestão de Contas: tratam os eventos do ciclo de vida das contas (abertura/encerramento), o cálculo de juros e a monitorização da liquidez.
• Servidores de Conformidade Regulamentar: automatizam as verificações AML (Prevenção do Branqueamento de Capitais), as pistas de auditoria e a elaboração de relatórios (por exemplo, IFRS, RGPD).

2. Servidores de Registo (Ledger)

Responsável pela manutenção de registos financeiros imutáveis:

• Servidores do Razão Geral: Registam a contabilidade por partidas dobradas nas várias contas, assegurando a conformidade com normas contabilísticas como as IFRS.
• Servidores de Tecnologia de Registo Distribuído (DLT): Sistemas baseados em blockchain para pagamentos transfronteiriços, verificação KYC e registos de transações à prova de adulteração.

3. Servidores de Comunicação Externa
Permitem interações seguras com entidades externas:

• Servidores EBICS: gerem o Electronic Banking Internet Communication Standard para pagamentos SEPA, amplamente utilizado na Alemanha, em França e na Suíça.
• Servidores Host-to-Host (H2H): Ligações SFTP/FTPS diretas para transações empresariais de elevado volume (por exemplo, processamento de salários em lote).
• Servidores de Gateway de API: Disponibilizam interfaces RESTful para a iniciação de pagamentos em tempo real e a agregação de contas (protegidas por OAuth2/mTLS).
• Servidores de interface Swift: Ligam o banco à rede Swift para a troca de mensagens interbancárias (o SCORE é o grupo fechado de utilizadores da Swift destinado ao acesso por parte de empresas, não um tipo de servidor).

4. Servidores de Bases de Dados
Repositórios centrais de dados financeiros estruturados:

• Servidores de Dados de Clientes: Armazenam documentos KYC, históricos de transações e análises comportamentais.
• Servidores de Catálogo de Produtos: Gerem a oferta, como empréstimos, créditos à habitação e taxas de depósito.

5. Servidores de Segurança e Infraestrutura
Garantir a integridade do sistema e o cumprimento da regulamentação:

• Servidores com Módulo de Segurança de Hardware (HSM): Protegem as chaves criptográficas utilizadas em assinaturas digitais e na cifragem SSL/TLS.
• Servidores de firewall/VPN: impõem a segmentação da rede e o acesso remoto seguro por parte dos colaboradores.
• Servidores de Recuperação em Caso de Desastre: Alojam sistemas de reserva para garantir a continuidade da atividade durante interrupções.

Os bancos modernos recorrem frequentemente a arquiteturas híbridas, combinando servidores centrais locais com nós de DLT na nuvem para efeitos de escalabilidade. Por exemplo, um banco pode utilizar servidores de core banking da IBM alojados localmente em conjunto com servidores de registo alojados na AWS para reconciliação em tempo real. Esta abordagem modular equilibra conformidade, desempenho e inovação.

Os bancos devem equilibrar a consolidação de servidores, por razões de eficiência, com a manutenção do isolamento, por razões de segurança e conformidade. Segue-se uma descrição dos servidores passíveis e não passíveis de combinação, com base em restrições técnicas e em práticas do setor:
Servidores que podem ser combinados
1. Servidores Web/de Aplicações

• Método combinado: virtualização (VMware, KVM) ou contentorização (Docker/Kubernetes)
• Exemplo: Alojamento de vários portais bancários (particulares, empresas, móvel) num cluster de hipervisores com balanceamento de carga.

2. Servidores de Bases de Dados

• Método de combinação: bases de dados multi-inquilino na nuvem (AWS RDS, Azure SQL)
• As bases de dados de core banking em Oracle/MS SQL podem coexistir com sistemas de análise em PostgreSQL/MongoDB em configurações de nuvem híbrida.

3. Gateways de comunicação externa

• Método de combinação: gateways de API unificados (Apigee, MuleSoft)
• Os serviços EBICS, SWIFT e SFTP podem funcionar numa infraestrutura partilhada, com microsserviços específicos de cada protocolo.

4. Servidores de Recuperação de Desastres

• Método de combinação: georredundância ativa-ativa
• As réplicas do sistema bancário central e os servidores de registo de reserva podem partilhar clusters de recuperação de desastres.

5. Servidores de Middleware

• Método de combinação: Enterprise Service Bus (ESB)
• Encaminhamento de pagamentos, verificações de conformidade e serviços de conversão cambial consolidados em IBM Integration Bus/SAP PI.

Servidores que Devem Permanecer Isolados
1. Servidores Centrais de Processamento de Transações

• Razão: A separação (física ou por segmentação estrita) reduz o âmbito dos controlos PCI DSS e SOC 2
• Exemplo: os sistemas IBM zSystems que executam monitores de transações CICS não podem partilhar o hardware com outras cargas de trabalho.

2. Servidores de Módulo de Segurança de Hardware (HSM)

• Motivo: a norma FIPS 140-2/140-3 de Nível 3 exige hardware dedicado e resistente a manipulação
• Implementação: HSM da Thales/Gemalto para a gestão de assinaturas digitais e chaves de cifragem.

3. Sistemas de Registo em Tempo Real

• Motivo: a contabilidade por partidas dobradas exige atomicidade
• Exemplo: servidores de livro-razão Oracle Financial Services com armazenamento NVMe de ligação direta.

4. Servidores de Reporte Regulamentar

• Motivo: Os registos de auditoria têm de ser protegidos contra alterações e conservados pelos períodos exigidos pelo RGPD e pela legislação em matéria de AML; a separação facilita a demonstração desse cumprimento
• Configuração: Instâncias SQL Server isoladas para os reportes MiFID II/FATCA.

5. Sistemas de Autorização de ATM/POS

• Motivo: SLA de disponibilidade de 99,999% e requisitos de segmentação de rede
• Arquitetura: IBM Power Systems com SAN Fibre Channel redundantes.

Restrições técnicas:

• Os sistemas bancários centrais de elevado volume exigem ligações de rede dedicadas e de grande largura de banda
• A norma PCI DSS exige que os números de cartão armazenados (PAN) sejam tornados ilegíveis e que o ambiente de dados dos titulares de cartões seja segmentado
• O Swift Customer Security Programme (CSP) exige que a infraestrutura Swift se situe numa zona segura protegida

Consolidámos com êxito 80% dos servidores não críticos (web/aplicações/middleware), mantendo totalmente isolados os sistemas centrais, HSM e de registo contabilístico (ledger).

A proteção de servidores de registos contabilísticos na nuvem exige salvaguardas em várias camadas, adequadas à sensibilidade dos dados financeiros. Com base nas melhores práticas de segurança da AWS e em implementações específicas do setor bancário, apresenta-se uma abordagem estruturada:

1. Tecnologia de Registo Imutável
Utilização de bases de dados de registo concebidas para o efeito, com verificação criptográfica de cada transação:

• Encadeamento criptográfico: cada transação é objeto de hash e ligada ao registo anterior, criando uma pista de auditoria imutável.
• Controlos de integridade incorporados: a base de dados verifica automaticamente o seu próprio historial, impedindo qualquer adulteração.
• Consultas do tipo SQL: Mantém a compatibilidade com os sistemas financeiros existentes, acrescentando uma segurança semelhante à da blockchain.

2. Isolamento de Rede

• Arquitetura VPC: implemente os servidores de registo contabilístico em sub-redes privadas, sem acesso à Internet pública.
• Grupos de segurança: restrinja o tráfego de entrada a portas específicas (por exemplo, PostgreSQL/Aurora) a partir de intervalos de IP previamente aprovados.
• Endpoints de VPC: Utilizar o AWS PrivateLink para a comunicação segura entre os servidores do registo (ledger) e serviços como o S3/KMS, sem expor os dados à Internet pública.

3. Encriptação

• Em repouso: chaves geridas pelo AWS KMS cifram os dados do livro-razão no Amazon Aurora, com rotação automática de chaves.
• Em trânsito: Impor TLS 1.3 em todas as comunicações cliente-servidor e entre serviços.
• Cifragem do lado do cliente: cifrar previamente os campos sensíveis (por exemplo, saldos de contas) antes do armazenamento, utilizando o AWS Encryption SDK.

4. Controlo de Acessos

• Funções IAM: atribuição de permissões granulares (por exemplo, funções apenas de inserção) para prevenir a eliminação acidental ou maliciosa de dados.
• Credenciais temporárias: utilizar o AWS STS para acesso limitado no tempo durante operações de manutenção.
• Aplicação de MFA: exigir tokens de hardware (YubiKey) para as contas root/administrador.

5. Monitorização e Auditoria

• Alertas em tempo real: Configure o AWS CloudWatch para acionar alertas perante padrões de transação invulgares (por exemplo, transferências superiores a 1 M€).
• Registos de atividade: Acompanhamento de todas as alterações ao registo contabilístico através do AWS CloudTrail, integrado com ferramentas SIEM.
• Auditorias automatizadas: Execução semanal de regras AWS Config para verificar o estado de encriptação e as políticas de rede.

6. Conformidade e Governação

• Segmentação por zonas: ambientes de livro-razão DEV/TEST/PROD separados, através do AWS Organizations.
• Relatórios automatizados: Gere relatórios de conformidade com o PCI DSS/RGPD através do AWS Audit Manager.
• Auditorias de terceiros: Agende testes de intrusão anuais com parceiros aprovados pela AWS.

7. Recuperação em Caso de Desastre

• Replicação inter-regional: manter réplicas cifradas do registo nas regiões AWS de Frankfurt e Estocolmo.
• Recuperação a um ponto no tempo: ative cópias de segurança contínuas para restaurar os dados para qualquer segundo dentro do período de retenção (até 35 dias).
• Cópias de segurança isoladas da rede (air-gapped): armazenar instantâneos trimestrais do livro-razão no AWS Backup Vault, com um período de retenção de 7 anos.

Para evitar que entradas maliciosas se propaguem aos servidores de recuperação de desastres (DR), os bancos aplicam estratégias de segurança em camadas que isolam as cópias de segurança, impõem controlos de acesso rigorosos e validam a integridade dos dados. Segue-se uma descrição técnica das principais medidas:
1. Cópias de segurança imutáveis com configurações Write-Once-Read-Many (WORM)

• Finalidade: impedir que o ransomware altere ou cifre os dados de cópia de segurança.

Implementação: Utilize o AWS S3 Object Lock ou o Azure Blob Immutable Storage para impedir a eliminação ou modificação durante um período de retenção definido. Aplique hash criptográfico (SHA-256) aos ficheiros de cópia de segurança; qualquer adulteração invalida o hash e aciona alertas.
2. Replicação Isolada da Rede (Air-Gapped) e Offline

• Isolamento de rede: Alojar os servidores de recuperação de desastres (DR) numa VPC/VLAN separada, sem acesso de entrada pela internet. Utilizar replicação unidirecional (primário → DR) através de ferramentas como o AWS Storage Gateway ou o Azure Site Recovery, bloqueando a sincronização inversa.
• Isolamento Físico (Air-Gapping): Para os sistemas críticos, manter cópias de segurança em fita ou armazenamento offline que apenas se ligam durante as janelas de replicação programadas.

3. Controlos de Acesso de Confiança Zero

• Autenticação: Impor a autenticação multifator a todas as interfaces de gestão de recuperação de desastres (por exemplo, AWS SSO, Azure AD Conditional Access). Atribuir funções IAM com permissões de privilégio mínimo (por exemplo, apenas `s3:GetObject`).
• Segurança da Rede: Restrinja o tráfego de replicação a túneis VPN IPsec ou a AWS Direct Connect/Azure ExpressRoute. Implemente sistemas de deteção de intrusões (IDS), como Snort ou Suricata, para monitorizar os canais de replicação.

4. Validação da Integridade dos Dados

• Verificações Prévias à Replicação: Analisar os dados de origem quanto a software malicioso, com ferramentas como ClamAV ou CrowdStrike Falcon, antes da replicação. Comparar as somas de verificação antes e depois da transferência para detetar adulterações.
• Auditorias pós-replicação: Utilize o AWS Config ou o Azure Policy para impor políticas de cifragem e de acesso nos servidores de recuperação de desastres. Programe verificações diárias de integridade através de scripts (por exemplo, validação com `sha256sum`).

5. Ambientes Logicamente Segmentados

6. Testes Automatizados de Comutação por Falha

• Ataques simulados: utilização de ferramentas como o Chaos Monkey para simular infeções por ransomware e validar a resiliência dos servidores de recuperação de desastres (DR). Medição dos objetivos de tempo de recuperação (RTO) e dos objetivos de ponto de recuperação (RPO) durante os exercícios.
• Análise forense: conservar 90 dias de VPC Flow Logs e de eventos CloudTrail para rastrear anomalias de replicação.

A implementação de cópias de segurança imutáveis é essencial para proteger os dados contra ransomware, eliminações acidentais e violações de conformidade. Com base em normas do setor e em ferramentas como AWS, Veeam e Azure, apresentam-se as melhores práticas:
1. Impor a Imutabilidade na Camada de Armazenamento

• Utilize configurações WORM (Write-Once-Read-Many) através de armazenamento de objetos com S3 Object Lock (AWS), Azure Immutable Blob Storage ou Veeam Hardened Repositories.
• Ative bloqueios de retenção para impedir a eliminação ou a modificação prematura, mesmo por parte de administradores.

2. Adotar uma Estratégia de Cópias de Segurança 3-2-1-1

• 3 cópias dos dados (principal + duas cópias de segurança)
• 2 tipos de suporte de armazenamento (por exemplo, disco + nuvem)
• 1 cópia externa (geograficamente isolada)
• 1 cópia imutável (isolada da rede ou com WORM ativado).

3. Implementar Controlos de Acesso Rigorosos

• Acesso baseado em funções (RBAC): restringir as permissões através de funções IAM (por exemplo, políticas de acesso a cofres do AWS Backup).
• Autenticação multifator (MFA): Impor nas interfaces de gestão de cópias de segurança (por exemplo, Azure AD Conditional Access).
• Isolamento de rede: armazenar as cópias de segurança em sub-redes/VPC privadas, sem acesso à Internet pública.

4. Encriptar os Dados de Ponta a Ponta

• Em repouso: Utilizar AES-256 ou chaves geridas por KMS (AWS, Azure).
• Em trânsito: TLS 1.3 nos canais de replicação.
• Cifragem do lado do cliente: cifrar previamente os campos sensíveis antes da cópia de segurança (por exemplo, a cifragem AES-256 da Veeam com chaves geridas pelo utilizador).

5. Automatizar a Conservação e a Validação

• Políticas de retenção: Definir o RPO/RTO e automatizar as regras de ciclo de vida (por exemplo, a retenção de 7 anos do AWS Backup Vault).
• Validação de checksum: Verificar a integridade antes e depois da replicação (por exemplo, hashing SHA-256).
• Auditorias regulares: Utilize ferramentas como o AWS Config ou o Veeam SureBackup para testar as restaurações.

6. Segurança em Camadas para Ambientes Híbridos

7. Assegurar a conformidade e a irreversibilidade

• Bloquear as definições de imutabilidade após os testes (por exemplo, o estado «Ativado e bloqueado» do Azure).
• Cumprir a regulamentação: alinhar-se com o RGPD, a HIPAA ou a SOX recorrendo a ferramentas como o AWS Audit Manager.
• Auditorias de terceiros: Agende testes de intrusão anuais (por exemplo, com parceiros aprovados pela AWS).

Exemplo de Fluxo de Trabalho com AWS e Veeam
1. Cópia de segurança principal: Veeam Backup & Replication para um bucket S3 com Object Lock.
2. Replicação: AWS DataSync para uma região secundária (Frankfurt → Estocolmo).
3. Validação: registos diários do CloudTrail + testes de recuperação trimestrais.
4. Retenção: período imutável de 90 dias com encriptação KMS.

Ao combinar caraterísticas de imutabilidade, controlos de acesso e redundância híbrida, as organizações podem obter cópias de segurança resistentes a ransomware, cumprindo simultaneamente as exigências de conformidade.