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 | Habilitado por defecto usando claves gestionadas por AWS (AES-256) |
| Cifrado en tránsito | TLS requerido para 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 por defecto; recuperación punto en el tiempo (PITR) disponible dentro de la ventana de retención |
| Backup continuo | Aurora respalda continuamente los logs de transacciones en S3, permitiendo recuperación a cualquier segundo dentro de la ventana de retención |
Los objetivos específicos de Tiempo de Recuperación (RTO) y Punto de Recuperación (RPO) están en proceso de definición. El modelo de backup continuo de Aurora proporciona un RPO cercano a cero dentro de la ventana de retención. Los objetivos formales se publicarán en una actualización futura.
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.