Seguridad

Esta página describe las medidas técnicas y organizativas que SocialMidea aplica para proteger tus datos.

1. Arquitectura

SocialMidea está construida sobre principios de mínimo privilegio, defensa en profundidad y aislamiento por tenant. La aplicación se despliega como contenedores Docker tras un reverse proxy con TLS.

• Aislamiento de tenants: todas las consultas filtran por organizationId. Cada server action verifica membership antes de operar.
• Roles granulares: Owner, Admin, Editor, Reviewer, Viewer. Acciones sensibles requieren rol explícito.
• Self-hosteable: los clientes empresariales pueden desplegar SocialMidea en su propia infraestructura. Tu DB y storage nunca dejan tu red.

2. Cifrado

2.1 En reposo

• API keys de usuario (OpenAI, Claude, Meta tokens): AES-256-GCM con sal por registro derivada con scrypt.
• Contraseñas: bcrypt con cost factor 12.
• Base de datos: volumen cifrado a nivel de disco (recomendado en el deploy del cliente self-hosted).

2.2 En tránsito

• TLS 1.2+ en todas las conexiones entrantes.
• HSTS habilitado.
• Conexiones internas a Postgres dentro de la red Docker.
• Webhooks de Stripe y QStash verificados por firma HMAC.

3. Autenticación

• Email + contraseña con política de mínimo 8 caracteres.
• OAuth opcional con Google y GitHub.
• Sesiones de 30 días con renovación deslizante, almacenadas como cookies httpOnly + secure + sameSite=lax.
• OAuth state firmado con HMAC-SHA256 y caducidad de 10 minutos para prevenir CSRF.

4. Datos sensibles

• Datos de pago: nunca tocan nuestros servidores. Stripe los procesa bajo PCI DSS Level 1.
• API keys de IA: cifradas, mostradas solo como •••••• últimos 4 dígitos. No hay endpoint que las devuelva en claro.
• Tokens OAuth de redes sociales: cifrados antes de almacenar. Cookies temporales de wizard de conexión también cifradas y con caducidad de 5 minutos.

5. Auditoría y observabilidad

• Ledger append-only de movimientos de créditos: cada fila incluye balance running para reconciliación.
• Logs de uso de IA con timestamps, modelo, tokens, coste y latencia.
• Logs de aprobación: quién aprobó/rechazó cada post y cuándo.
• Webhooks idempotentes usando IDs de Stripe como dedup keys.

6. Operaciones

• Backups diarios de Postgres con retención de 30 días (recomendación para deploys self-hosted: configurar pg_dump cron + storage off-site).
• Mínimo privilegio: el contenedor de la app corre como usuario no-root.
• Dependencias auditadas con npm audit y actualizadas regularmente.
• Secretos nunca commitados al repo. Gestionados por variables de entorno o secret manager.

7. Cumplimiento

• RGPD y LOPDGDD — ver Política de privacidad.
• DPA disponible para clientes empresariales — ver DPA.
• Notificación de brechas en máximo 72h conforme al artículo 33 RGPD.

8. Reporta una vulnerabilidad

Si descubres una vulnerabilidad de seguridad, te pedimos que la reportes de forma responsable:

• Email: security@[DOMINIO]
• Cifra el reporte con nuestra clave PGP si es sensible: Clave pública PGP

Compromiso de respuesta: 48 horas. No tomamos acciones legales contra investigadores que sigan estas prácticas:

• No accedan ni alteren datos de otros usuarios.
• No interrumpan el servicio.
• No divulguen la vulnerabilidad antes del parche.
• Den tiempo razonable para la corrección.

9. Estado del servicio

Página pública de estado e historial de incidentes: status.[DOMINIO]

Esta página describe medidas a nivel arquitectónico. Antes de publicarla, ajusta los detalles a tu implementación real y completa los placeholders.