Infraestructura
Percus corre completamente en AWS. La elección de servicios gestionados de AWS es una decisión deliberada de seguridad: transfiere el parcheo de infraestructura, la seguridad física y la gestión de disponibilidad a AWS, mientras Percus se enfoca en la seguridad a nivel de aplicación.
Servicios y sus propiedades de seguridad
AWS Lambda
La lógica de aplicación corre como funciones serverless. No hay instancias EC2 de larga duración que parchear ni endurecer a nivel de sistema operativo. Cada invocación corre en un entorno de ejecución aislado y efímero. AWS gestiona la infraestructura de cómputo subyacente, incluyendo actualizaciones del sistema operativo y seguridad del hipervisor.
Amazon Aurora Serverless v2
El Identity Service y el Campaign Service utilizan cada uno un cluster dedicado de Aurora Serverless v2 (compatible con PostgreSQL).
| Propiedad | Detalle |
|---|---|
| Cifrado en reposo | En proceso de habilitación (AES-256 con AWS KMS). Los datos de personalización entregados vía API nunca se almacenan en estas bases de datos |
| Cifrado en tránsito | TLS soportado; se está habilitando la exigencia de TLS en todas las conexiones a la base de datos |
| Parcheo | Gestionado por AWS; parches de versión menor aplicados automáticamente |
| Acceso | Las bases de datos no son accesibles públicamente — solo accesibles desde dentro de la VPC |
| Backups automáticos | Habilitados, con una ventana de retención de 30 días en producción. Recuperación punto en el tiempo a cualquier segundo dentro de esa ventana |
| Backup continuo | Aurora respalda continuamente los logs de transacciones en S3, permitiendo recuperación a cualquier segundo dentro de la ventana de retención |
| Protección contra borrado | Habilitada en los clusters de producción — la base no puede eliminarse sin desactivar antes la protección |
Los objetivos publicados son RPO 30 días y RTO 4 horas. La cifra de RPO es la ventana de retención, no la granularidad de recuperación: el PITR puede restaurar a cualquier segundo, pero sólo dentro de esa ventana, así que la ventana es lo que el cliente realmente enfrenta.
Ver Niveles de servicio para el compromiso completo y el rendimiento medido que lo respalda.
Amazon DynamoDB
El Render Data Service almacena los datos de personalización por destinatario en DynamoDB, para clientes que usan el modelo de personalización alojado en Percus (ver Manejo de datos).
| Propiedad | Detalle |
|---|---|
| Cifrado en reposo | Habilitado por defecto (AES-256) |
| Cifrado en tránsito | TLS obligatorio |
| Recuperación punto en el tiempo | Habilitada — backup continuo con ventana de 35 días |
| Acceso | Sólo a través de las Lambdas del propio servicio; la tabla no es direccionable públicamente |
| Retención | Los datos por destinatario se eliminan cuando se archiva el proyecto que los posee |
Amazon S3
Los archivos de template y assets se almacenan en S3.
| Propiedad | Detalle |
|---|---|
| Cifrado en reposo | Cifrado del lado del servidor habilitado en todos los buckets (SSE-S3) |
| Control de acceso | Los buckets son privados; el acceso se otorga mediante roles IAM con alcance a la aplicación |
| Versionado de objetos | Habilitado — eliminaciones o sobreescrituras accidentales pueden recuperarse |
Amazon CloudFront
CloudFront está frente a todos los endpoints públicos.
| Propiedad | Detalle |
|---|---|
| Terminación TLS | Todo el tráfico servido sobre HTTPS; HTTP redirigido a HTTPS |
| Protección DDoS | AWS Shield Standard está incluido con CloudFront sin costo adicional — proporciona protección permanente contra ataques comunes de red y capa de transporte |
| Caché en el borde | Assets estáticos (templates, runtime del player) cacheados en el edge — reduce la carga al origen y mejora la disponibilidad |
AWS Secrets Manager
Todas las credenciales sensibles de runtime se almacenan en AWS Secrets Manager — nunca están hardcodeadas en el código de la aplicación ni en variables de entorno.
| Secreto | Usado por |
|---|---|
| Credenciales de base de datos (usuario + contraseña) | Identity Service y Campaign Service — recuperados al inicio mediante DATABASE_SECRET_ARN |
| Clave de firma JWT | Campaign Service — usada para firmar y verificar tokens de sesión, recuperada mediante JWT_SECRET_ARN |
| Clave de firma de sesión embed | Campaign Service — usada para firmar tokens de sesión de public video shares |
Los secretos se obtienen en el cold start de Lambda mediante el AWS SDK. Los roles IAM otorgan a cada servicio acceso solo a sus propios secretos — el Identity Service no puede leer los secretos del Campaign Service y viceversa.
Amazon CloudWatch Logs
Los logs de aplicación se recopilan en CloudWatch Logs.
| Propiedad | Detalle |
|---|---|
| Retención de logs | Por defecto de AWS (los logs no expiran — retención indefinida) |
| Eventos de auditoría | Los eventos de auditoría a nivel de negocio (quién hizo qué y cuándo) son registrados por el Campaign Service y almacenados en la base de datos |
| Acceso | El acceso a logs está restringido a roles IAM con permisos explícitos de CloudWatch |
Aislamiento de red
Los servicios de aplicación corren dentro de una Amazon VPC. Las bases de datos y los servicios internos no están expuestos a internet público. Solo los endpoints de CloudFront y API Gateway son accesibles públicamente, y todo el tráfico a través de ellos está autenticado en la capa de aplicación.
Gestión de vulnerabilidades
Trivy realiza escaneos del filesystem automáticamente en cada pull request dirigido a main o develop. Los resultados del escaneo cubren vulnerabilidades de severidad CRITICAL y HIGH y se cargan en la pestaña de Seguridad de GitHub en formato SARIF para revisión.
| Propiedad | Detalle |
|---|---|
| Herramienta | Trivy (aquasecurity/trivy-action) |
| Disparador | Cada PR hacia main o develop |
| Alcance | Escaneo completo del filesystem del repositorio |
| Umbral de severidad | CRITICAL y HIGH |
| Vulnerabilidades sin parche | Ignoradas (solo se reportan hallazgos accionables) |
| Resultados | Cargados en la pestaña de Seguridad de GitHub en formato SARIF |
Modelo de responsabilidad compartida de AWS
AWS y Percus comparten la responsabilidad de seguridad bajo el modelo de responsabilidad compartida de AWS:
| Capa | Quién es responsable |
|---|---|
| Centros de datos físicos | AWS |
| Infraestructura de red | AWS |
| Hipervisor y sistema operativo del host | AWS |
| Parcheo de servicios gestionados (Aurora, runtime de Lambda) | AWS |
| Código de aplicación | Percus |
| Políticas y permisos IAM | Percus |
| Configuración de cifrado de datos | Percus (usando herramientas provistas por AWS) |
| Control de acceso y autenticación | Percus |
| Datos del cliente dentro de la aplicación | El cliente |
Despliegue
La infraestructura se define y despliega usando AWS CDK a través de pipelines de CI/CD en GitHub Actions. Los cambios en la infraestructura pasan por el mismo proceso de revisión de código que el código de aplicación.