La seguridad de una red institucional depende de controles técnicos coordinados y responsabilidades operativas disciplinadas. La plataforma proporciona una red configurable y mecanismos admitidos de acceso, gobernanza y control administrativo. La institución sigue siendo responsable de su personal, política de identidad, compromisos sobre activos, datos privados, aprobaciones empresariales y entornos bajo su control. Los resultados de seguridad dependen de la arquitectura y la implementación acordadas, no solo del nombre del producto.
Un análisis de seguridad debe identificar activos, actores, límites de confianza y escenarios de fallo antes de elegir controles. Debe cubrir accesos privilegiados, autorización de transacciones, operaciones de validadores, custodia de claves, cambios de software, supervisión, respuesta a incidentes, copias de seguridad y dependencias de terceros. Las conexiones con HSM, IAM, SIEM y sistemas de cumplimiento se evalúan por separado; no se debe presuponer un conector integrado, certificación ni garantía independiente sin pruebas delimitadas.
Distribuir los controles entre personas, aplicaciones y red
Empiece por las identidades institucionales y los roles de mínimo privilegio para usuarios, operadores y administradores. Defina cómo se solicitan, aprueban, revisan, revocan y registran los accesos. La autorización de aplicaciones y la firma de transacciones deben seguir la política de riesgos del banco. La gobernanza de red añade vías de aprobación configuradas para cambios administrativos admitidos, pero no sustituye los controles de personal ni los procedimientos de autorización propios de la institución.
En la capa de red, los validadores procesan transacciones admisibles conforme al consenso y las políticas de red configurados. Las acciones administrativas y decisiones de gobernanza deben limitarse a las partes autorizadas y a la configuración admitida. La institución y el proveedor deben aclarar quién opera cada componente, protege credenciales, supervisa actividad, aplica cambios y responde a incidentes. Cada límite necesita un responsable, una vía de escalada y requisitos de pruebas.
Capas de responsabilidad de seguridad
- Política institucional
Ciclo de vida de identidades, aprobaciones empresariales, obligaciones con clientes y titularidad del riesgo.
- Controles de aplicación
Autorización, preparación de transacciones, límites de firma y tratamiento de datos privados.
- Gobernanza de red
Roles configurados, aprobaciones, acciones administrativas permitidas y registros de auditoría.
- Operaciones de infraestructura
Alojamiento, validadores, supervisión, mantenimiento e incidentes según el alcance acordado.
Definir expresamente las aprobaciones y la custodia de claves
La custodia de claves determina quién puede autorizar acciones que dependen de una clave criptográfica, cómo se protege esa autoridad y cómo se recupera o revoca el acceso. La institución debe documentar a los titulares de claves, firmantes, umbrales de aprobación, mecanismos de copia y recuperación, separación de funciones y procedimientos de emergencia. El diseño de firma técnica debe ajustarse a la política operativa y no basarse en una suposición genérica sobre la custodia.
La gobernanza puede exigir propuestas, votos, aprobaciones o demoras configurados para cambios admitidos. Estos controles estructuran la autorización, pero no demuestran que se haya cumplido el proceso de aprobación más amplio de la institución. Los requisitos o integraciones de HSM deben evaluarse técnicamente y acordarse; no se presupone ningún conector HSM ni producto de custodia concreto. Pruebe los procedimientos de aprobación y recuperación en un alcance autorizado fuera de producción.
Delimitar cuidadosamente las pruebas y revisiones independientes
Una solicitud de aseguramiento debe especificar los sistemas, los límites del despliegue, los controles, el periodo, las pruebas y el evaluador independiente involucrados. La coordinación de una evaluación de seguridad puede facilitar una revisión acordada, pero la descripción del producto no constituye una opinión de auditoría ni una certificación. Asimismo, la existencia de registros o trazas de gobernanza no demuestra su integridad, conservación ni idoneidad para una obligación regulatoria concreta sin una evaluación expresa.
Un entregable de seguridad práctico puede incluir la arquitectura y el registro de responsabilidades acordados, la revisión de amenazas y dependencias, el modelo de acceso, las hipótesis de custodia de claves, los controles de cambio, los procedimientos de incidentes y recuperación y los resultados de validación. Los riesgos abiertos deben tener responsables y decisiones de tratamiento. Cualquier certificación, conclusión de cumplimiento, compromiso de disponibilidad o aseguramiento externo debe basarse en las pruebas pertinentes acordadas por separado y no debe inferirse de esta guía.