Cifrado, aislamiento, alojamiento regional:
seguro desde el diseño.

El cifrado en SDEN es concreto. En tránsito, cada endpoint público termina TLS 1.3 con suites de cifrado modernas (ECDHE para el intercambio de claves, cifrados AEAD como AES-GCM y ChaCha20-Poly1305), con precarga HSTS solicitada donde la propiedad del dominio lo permite. El tráfico interno de servicio a servicio dentro de nuestra infraestructura gestionada también está cifrado por TLS; no presumimos que una red privada sea una red de confianza.

En reposo, los datos se cifran con AES-256 mediante los servicios de gestión de claves gestionados por el proveedor cloud (AWS KMS, GCP KMS o equivalente) por defecto, con claves gestionadas por el cliente (CMK / BYOK) ofrecidas bajo demanda para los proyectos donde el modelo de amenazas y el contexto regulatorio lo exigen. Las claves se rotan según un calendario documentado y bajo demanda tras cualquier cambio de acceso. No entregamos productos que almacenan secretos en variables de entorno sobre una sola máquina virtual llamando a eso «cifrado en reposo»: la distinción importa y la tratamos como un veto de revisión de código.

La autenticación del personal de SDEN se exige mediante un factor múltiple respaldado por hardware (WebAuthn / FIDO2) para cada cuenta con acceso a los sistemas de producción, a los datos de cliente o al código fuente. El aprovisionamiento de cuentas pasa por un proceso documentado de alta / cambio / baja con revisiones de acceso trimestrales. No hay ninguna credencial compartida hacia un sistema de producción; cada acción es atribuible a una persona nombrada.

Para las aplicaciones que entregamos, el single sign-on por OIDC (Google Workspace, Microsoft Entra ID, Okta, Auth0) es la opción por defecto ofrecida a los clientes de empresa. Donde el single sign-on no está disponible, la autenticación por contraseña se exige con el hash recomendado por OWASP (Argon2id o scrypt), una limitación de tasa en la capa de relleno de credenciales, y un factor múltiple obligatorio para toda cuenta con alcance administrativo. El control de acceso por roles funciona con mínimo privilegio; el permiso por defecto de todo rol nuevo es cero, y cada concesión está documentada.

Los registros de auditoría se conservan un mínimo de doce meses y son a prueba de manipulación: el flujo de logs mismo es de solo anexado y se exporta a un destino aislado, de modo que un compromiso de la aplicación no pueda reescribir retroactivamente el rastro de auditoría. PLACEHOLDER: confirmar la ventana de conservación configurada para cada entorno antes de publicar.

La multiinquilinería es donde ocurren la mayoría de las brechas de seguridad de los SaaS, y casi siempre porque el aislamiento se imponía en el código de aplicación en lugar de en la capa de datos. La arquitectura por defecto de SDEN lo impone en ambas. El identificador de inquilino se propaga por la aplicación como un tipo obligatorio (no un campo opcional), de modo que una consulta que olvida restringirse a un inquilino es un error de compilación de TypeScript en lugar de una fuga de datos en ejecución. En la base de datos, las políticas de seguridad a nivel de fila de PostgreSQL imponen la misma frontera: incluso una cuenta de servicio que se comporta mal no puede leer de un inquilino a otro sin una excepción explícita y auditada.

Donde el modelo de amenazas justifica el coste, entregamos claves de cifrado en reposo por inquilino, de modo que un compromiso a nivel de base de datos de los datos de un inquilino no pueda descifrar los de otro. Las copias de seguridad están igualmente restringidas por inquilino, con el procedimiento de restauración documentado y probado. La matriz de acceso entre inquilinos se prueba por integración antes de cada versión: cada endpoint se invoca con las credenciales de un inquilino contra los registros de otro, y los rechazos esperados se afirman automáticamente.

La jurisdicción de alojamiento es una decisión de protección de datos, no una decisión de aprovisionamiento. Cada producto que entregamos se despliega en la región que el cliente exige, porque la postura SOC 2 / RGPD y la ausencia de mecanismos de transferencia transfronteriza son todas más simples cuando los datos no salen de su región de origen en primer lugar. Los proveedores que usamos con más frecuencia (AWS (eu-west-1 / eu-west-3 (París)), GCP (europe-west1 / europe-west9 (París)) y Azure en las regiones de la UE, EE. UU. y Suiza) tienen todos firmados acuerdos de tratamiento de datos que podemos trasladar a los clientes sin renegociación.

Donde el modelo de amenazas o el contexto regulatorio de un cliente exige un despliegue bloqueado a una región (UE, EE. UU. o Suiza), lo configuramos para que se quede en esa región; donde se requiere una conmutación multirregión, la configuramos con fronteras de residencia documentadas. No cambiamos en silencio la región de alojamiento de una copia de seguridad o de un nodo periférico de CDN sin divulgación: el compromiso de residencia en el DPA es la residencia en producción.

Las copias de seguridad están cifradas (AES-256), se toman según un calendario adaptado al objetivo de punto de recuperación (RPO) de los datos, y se almacenan en una región distinta de la principal, de modo que un fallo regional no se lleve la recuperación con él. PLACEHOLDER: confirmar el RPO configurado y el objetivo de tiempo de recuperación (RTO) por producto antes de cualquier publicación externa: los valores por defecto típicos son un RPO ≤ 24 horas y un RTO ≤ 8 horas para los productos SaaS que SDEN opera.

Los procedimientos de restauración están probados. Una copia de seguridad que nunca se ha restaurado es una esperanza, no un plan de recuperación; realizamos ejercicios de restauración periódicos contra un entorno de preproducción y documentamos el resultado. Cuando entregamos un producto a un cliente, el runbook de restauración forma parte del entregable.

Seguro desde el diseño no es un eslogan en SDEN; es un conjunto de prácticas impuestas por el mismo pipeline de integración continua que ejecuta la suite de tests. En la fase de diseño de cada proyecto, el modelo de amenazas se pone por escrito: los activos que protegemos, los adversarios contra los que los protegemos, las fronteras de confianza por las que transitan los datos. El resultado orienta las decisiones de arquitectura, el modelo de control de acceso y las opciones de dependencias.

En el pipeline, cada pull request ejecuta un análisis de composición de software (SCA) contra el árbol de dependencias para detectar paquetes con vulnerabilidades conocidas, tests estáticos de seguridad de aplicaciones (SAST) contra el código para los patrones del OWASP Top 10, y una detección de secretos para asegurar que las credenciales nunca aterricen en el repositorio. La protección de ramas exige una compilación exitosa y la aprobación de un revisor antes del merge; los commits firmados se exigen en la rama principal; las imágenes de contenedor se analizan y las imágenes base se anclan a una etiqueta mantenida según una cadencia de refresco documentada.

Las vulnerabilidades de seguridad encontradas en software construido por SDEN pueden notificarse de forma confidencial a security@sden.ai (ver la sección de contacto más abajo). Nos comprometemos a una ventana de respuesta definida: un acuse de recibo en un día laborable, un primer triaje en tres días laborables, y un calendario de divulgación coordinada acordado con quien notifica antes de cualquier comunicación pública.

Internamente, los incidentes siguen un proceso de respuesta documentado: un solo comandante de incidente se nombra en la declaración, la comunicación pasa por un canal dedicado con actualizaciones con marca de tiempo, una actualización de estado destinada al cliente se publica cuando el impacto es visible para el cliente, y un post-mortem escrito se produce en los diez días laborables siguientes a la resolución. El post-mortem es sin culpa, nombra los factores contribuyentes, y llega con elementos de acción seguidos en el mismo backlog que el trabajo de funcionalidades. Los incidentes graves disparan una notificación a los clientes afectados con el calendario y la corrección, conforme a la ventana de notificación de brecha aplicable (RGPD, 72 horas a la autoridad de control) donde aplica.