D1 · Política de seguridad de la información

Esta política fija las reglas de seguridad que se aplican a la plataforma Bolívar Connect y a todo el personal que la opera. Los demás documentos (D2 a D7) la desarrollan.

1. Objeto

Proteger la confidencialidad, integridad y disponibilidad de la información que la plataforma trata. En particular, las instrucciones de pago de los clientes y los datos personales de los beneficiarios.

2. Alcance

Aplica a la API, la base de datos, la infraestructura en AWS, el repositorio de código, las credenciales y todo el personal con acceso a cualquiera de ellos.

3. Principios

1. Mínimo privilegio: cada persona, servicio y API key tiene solo el acceso que necesita para su función.
2. Defensa en profundidad: ningún control depende de uno solo; red, aplicación y datos tienen protecciones propias.
3. Seguro por defecto: la plataforma se niega a arrancar en producción con configuración insegura.
4. Minimización de datos: solo se trata el dato personal imprescindible para ejecutar el pago.
5. Trazabilidad: toda acción relevante queda registrada y es atribuible a un actor.

4. Roles y responsabilidades

Rol	Responsabilidad
Dirección	Aprueba esta política, asigna recursos y acepta los riesgos residuales
Responsable de seguridad (Líder técnico)	Mantiene la política, aprueba accesos, coordina incidentes y evaluaciones de riesgo
Personal técnico	Cumple la política, protege sus credenciales y reporta cualquier incidente o debilidad
Terceros	Cumplen los requisitos de seguridad del documento D7

5. Controles

5.1 Clasificación de la información

Nivel	Ejemplos	Tratamiento
Restringida	Secretos, API keys, credenciales de terceros, datos personales	Cifrada, acceso mínimo, nunca en logs ni en el repositorio
Confidencial	Hallazgos de seguridad, detalles de infraestructura, contratos	Solo personal autorizado; fuera del repositorio de código
Interna	Código fuente, documentación técnica	Personal de la organización
Pública	Documentación de la API, políticas de seguridad, política de privacidad	Sin restricción

5.2 Control de accesos

Autenticación por API key con scopes para los clientes. MFA para el acceso a la infraestructura. Administración de servidores solo por AWS SSM Session Manager, sin SSH. El detalle está en D2.

5.3 Criptografía

• TLS 1.2 o 1.3 en toda comunicación externa; TLS 1.0 y 1.1 deshabilitados; HSTS activo.
• Cifrado en reposo AES-256 con AWS KMS para volúmenes y backups.
• Las API keys y los tokens de acceso se almacenan solo como hash SHA-256.
• Los webhooks se firman con HMAC-SHA256, con un secreto por cliente.

5.4 Gestión de secretos

Los secretos se guardan en AWS Secrets Manager y se leen mediante un rol IAM limitado a los secretos concretos. Está prohibido incluir secretos en el código, en el repositorio, en los logs o en canales de mensajería. Un secreto expuesto se rota de inmediato.

5.5 Seguridad de red

Cada servicio tiene su propio grupo de seguridad, con solo los puertos necesarios. La base de datos no es accesible desde internet.

5.6 Desarrollo seguro

Todo cambio pasa la suite de pruebas automatizadas, incluidas las de seguridad, antes de desplegarse. Los cambios que tocan autenticación, instrucciones de pago o datos personales tienen revisión de seguridad. La infraestructura se define como código.

5.7 Registro y monitoreo

Cada petición lleva un request_id. Las acciones administrativas quedan en un registro de auditoría de solo inserción. Los logs no contienen datos personales en claro. Los plazos están en D6.

5.8 Vulnerabilidades, incidentes, continuidad y terceros

Se rigen por D3, D4, D5 y D7 respectivamente.

5.9 Personal

Todo el personal firma un acuerdo de confidencialidad al incorporarse y recibe formación en manejo de credenciales, phishing y desarrollo seguro. Al salir, sus accesos se revocan el mismo día.

6. Gestión de riesgos

Los riesgos tecnológicos se evalúan ante cada cambio relevante de arquitectura, antes de incorporar un cliente o tercero nuevo, y al menos una vez al año. Cada riesgo se valora por probabilidad e impacto (alto, medio o bajo) y se registra con su tratamiento:

Tratamiento	Cuándo
Mitigar	El riesgo es alto o medio y existe un control razonable
Aceptar	El riesgo residual es bajo; lo acepta la Dirección por escrito
Transferir	Mediante contrato o seguro
Evitar	Se elimina la actividad que lo origina

7. Marcos de referencia

Los controles se alinean con el Anexo A de ISO/IEC 27001, el OWASP Top 10 y el OWASP API Security Top 10. La organización no declara certificación formal.

8. Cumplimiento y excepciones

El incumplimiento de esta política puede dar lugar a la retirada de accesos y a medidas disciplinarias o contractuales. Toda excepción se solicita al Responsable de seguridad, se aprueba por escrito, tiene fecha de caducidad y queda registrada.

9. Revisión

Esta política se revisa una vez al año, o antes si cambian la arquitectura, los terceros o la regulación aplicable.