A segurança de uma rede institucional depende de controlos técnicos coordenados e de responsabilidades operacionais disciplinadas. A plataforma fornece uma rede configurável e mecanismos suportados de acesso, governação e controlo administrativo. A instituição continua responsável pelas suas pessoas, políticas de identidade, compromissos relativos a ativos, registos privados, aprovações de negócio e ambientes que controla. Os resultados de segurança dependem da arquitetura e da implementação acordadas, não apenas do nome de um produto.
Uma análise de segurança deve mapear ativos, intervenientes, limites de confiança e cenários de falha antes de escolher controlos. Deve abranger acessos privilegiados, autorização de transações, operações dos validadores, custódia de chaves, alterações de software, monitorização, resposta a incidentes, cópias de segurança e dependências de terceiros. As ligações a HSM, IAM, SIEM e sistemas de conformidade são integrações avaliadas separadamente; sem evidência delimitada, não se deve presumir um conector integrado, uma certificação ou uma garantia independente.
Aplicar controlos a pessoas, aplicações e rede
Comece pelas identidades institucionais e por funções com o mínimo de privilégios para utilizadores, operadores e administradores. Defina como os acessos são pedidos, aprovados, revistos, revogados e registados. A autorização das aplicações e a assinatura de transações devem seguir a política de risco do banco. A governação da rede acrescenta percursos de aprovação configurados para alterações administrativas suportadas, mas não substitui os controlos sobre colaboradores nem os procedimentos de autorização próprios da instituição.
Na camada da rede, os validadores processam transações elegíveis segundo o consenso e as políticas de rede configurados. As ações administrativas e as decisões de governação devem limitar-se a partes autorizadas e à configuração suportada. A instituição e o fornecedor de serviços têm de clarificar quem opera cada componente, protege credenciais, monitoriza atividade, aplica alterações e responde a incidentes. Cada limite precisa de um responsável, um percurso de escalonamento e expectativas de evidência.
Camadas de responsabilidade pela segurança
- Política institucional
Ciclo de vida das identidades, aprovações de negócio, compromissos com clientes e responsabilidade pelo risco.
- Controlos das aplicações
Autorização, preparação de transações, limites de assinatura e tratamento de dados privados.
- Governação da rede
Funções configuradas, aprovações, ações administrativas permitidas e registos de auditoria.
- Operações de infraestrutura
Responsabilidades acordadas de alojamento, validadores, monitorização, manutenção e incidentes.
Definir expressamente as aprovações e a custódia de chaves
A custódia de chaves determina quem pode autorizar ações que dependem de uma chave criptográfica, como essa autoridade é protegida e como os acessos são recuperados ou revogados. A instituição deve documentar os responsáveis pelas chaves, os signatários, os limiares de aprovação, os mecanismos de cópia de segurança e recuperação, a segregação de funções e os procedimentos de emergência. O desenho técnico da assinatura tem de corresponder à política operacional, não a um pressuposto genérico sobre custódia.
A governação pode exigir propostas, votações, aprovações ou períodos de espera configurados para alterações suportadas. Estes controlos ajudam a estruturar a autorização, mas não demonstram que o processo de aprovação mais amplo da instituição foi cumprido. Os requisitos ou integrações de HSM têm de ser avaliados e acordados tecnicamente; não está implicitamente incluído um conector HSM ou produto de custódia específico. Teste os procedimentos de aprovação e recuperação num âmbito não produtivo autorizado.
Delimitar cuidadosamente a evidência e as revisões independentes
Um pedido de garantia deve especificar os sistemas, o limite da implementação, os controlos, o período, a evidência e o avaliador independente envolvidos. A coordenação de uma avaliação de segurança pode apoiar uma revisão acordada, mas a descrição de um produto não é uma opinião de auditoria nem uma certificação. Do mesmo modo, a existência de registos ou de histórico de governação não demonstra, sem avaliação explícita, a respetiva integridade, conservação ou adequação a uma obrigação regulamentar específica.
Um resultado prático de segurança pode incluir a arquitetura e o registo de responsabilidades acordados, uma análise de ameaças e dependências, o modelo de acesso, os pressupostos de custódia de chaves, os controlos de alteração, os procedimentos de resposta a incidentes e recuperação e as conclusões da validação. Os riscos em aberto devem ter responsáveis e decisões de tratamento. Qualquer certificação, conclusão de conformidade, compromisso de disponibilidade ou garantia externa requer evidência própria acordada separadamente e não deve ser inferida deste guia.