D2 · Gestión de accesos

Este procedimiento define cómo se conceden, usan, revisan y revocan los accesos a Bolívar Connect. Aplica a dos tipos de acceso: el del personal a la infraestructura y el código, y el de los clientes a la API y al portal web.

1. Sistemas cubiertos

Sistema	Quién accede	Autenticación
Consola y API de AWS	Personal técnico autorizado	Usuario nominal + MFA obligatorio
Servidores	Personal técnico autorizado	AWS SSM Session Manager (hereda IAM y MFA); sin SSH ni llaves
Repositorio de código	Personal técnico	Cuenta nominal + MFA
Base de datos	Solo la aplicación	Credencial de servicio; sin acceso desde internet
Operaciones de plataforma	Responsable de seguridad	API key con scope admin, guardada en AWS Secrets Manager
Consola de operaciones	Personal autorizado	Acceso limitado a los dominios de la organización; roles, cierre por inactividad y nueva autenticación para acciones sensibles
Portal web de clientes	Usuarios de cada cliente	Enlace de un solo uso por correo (vence en 15 minutos) o Google; roles por empresa (lector, operador, administrador), cierre por inactividad y nueva autenticación para acciones sensibles
API de clientes	Sistemas de cada cliente	API key con scopes, por tenant
Despliegue	El servidor	Deploy key de solo lectura, revocable

2. Principios

• Cuentas nominales: no se comparten cuentas ni credenciales de personas.
• Mínimo privilegio: el acceso se concede por función y solo al sistema necesario.
• Segregación de funciones: la key que envía instrucciones de pago es distinta de las keys de solo lectura, y las operaciones de plataforma exigen un scope que ninguna key de cliente tiene.
• MFA en todo acceso a infraestructura y código.

3. Alta de personal

1. El responsable del área solicita el acceso indicando la persona, el sistema y la función.
2. El Responsable de seguridad aprueba el acceso y el rol mínimo necesario.
3. Antes de recibir el acceso, la persona firma el acuerdo de confidencialidad y acepta la política D1.
4. Se crea la cuenta nominal, se activa el MFA y se registra el alta con la fecha, el sistema, el rol y quién la aprobó.

4. Cambios de rol

Un cambio de función se trata como una baja de los accesos que ya no corresponden más un alta de los nuevos, con la misma aprobación.

5. Baja de personal

El mismo día de la salida se hace lo siguiente:

1. Se desactivan sus cuentas en AWS y en el repositorio de código, y se revocan sus sesiones activas.
2. Se rotan las credenciales compartidas a las que tuvo acceso, si las hubiera.
3. Se registra la baja con la fecha y quien la ejecutó.

6. Accesos de clientes a la API

• Cada cliente recibe su primera API key al darse de alta y puede emitir keys adicionales con scopes limitados, por ejemplo de solo lectura.
• Las keys se muestran una sola vez y se guardan solo como hash SHA-256.
• El cliente puede rotar su key y su secreto de webhooks en cualquier momento; la key anterior queda revocada al instante.
• Cada key está sujeta a rate limiting y cada tenant solo accede a sus propios datos.

7. Revisión de accesos

• Por evento: en cada alta, baja o cambio de rol, como se describe arriba.
• Periódica: cada trimestre, el Responsable de seguridad compara los usuarios de AWS y del repositorio y las credenciales de plataforma con la lista de personal activo. Se retira todo acceso que no se justifique y se deja registro de la revisión.

8. Registros

Las altas, bajas, cambios y revisiones se conservan como evidencia al menos durante la vigencia de la relación con cada persona, más un año. La emisión y revocación de API keys queda en el registro de auditoría de la plataforma.