Seguridad

Cómo Neural Detective protege sus datos en cada capa — desde el perímetro de red hasta la fila de la base de datos.

Aislamiento de Datos

Arquitectura multi-tenant con límites impuestos a nivel de base de datos.

Seguridad a Nivel de Fila en PostgreSQL

Cada tabla con alcance de tenant tiene una política de seguridad a nivel de fila que filtra filas por organización. Impuesta por Postgres en sí — no por el código de la aplicación — de modo que incluso un error en nuestros controladores no puede filtrar datos entre tenants.

Contexto de Tenant por Solicitud

Cada solicitud establece una variable de sesión de Postgres (SET LOCAL) con el ID de la organización autenticada. Las políticas RLS hacen referencia a esta variable, asegurando que las consultas nunca devuelvan filas de otro tenant.

Claves Primarias UUID

Todos los registros utilizan identificadores UUIDv4 en lugar de enteros secuenciales. Los IDs de recursos no pueden adivinarse ni enumerarse.

Cifrado

Datos protegidos en tránsito y en reposo.

TLS en Todo Momento

Todo el tráfico está cifrado con TLS. HTTPS se impone en producción con cabeceras HSTS, y las solicitudes HTTP en texto plano se redirigen automáticamente.

Atributos Sensibles Cifrados

Los valores de atributos protegidos (género, grupo de edad, etc.) utilizados para la monitorización de sesgo se cifran en la capa de aplicación utilizando atributos cifrados de Rails antes de escribirse en la base de datos.

Claves API con Hash

Las claves API se procesan con hash SHA-256 antes de almacenarse. Nunca almacenamos el token en bruto — se muestra una vez al crearse y no puede recuperarse de nuevo.

Hash de Contraseñas con bcrypt

Las contraseñas de usuario se procesan con hash bcrypt usando un factor de coste de 12 en producción. Las contraseñas en bruto nunca se almacenan ni se registran en logs.

Seguridad de la API

Autenticación, firma y defensa en profundidad.

Autenticación con Token Bearer

Cada solicitud a la API requiere una clave API válida en la cabecera Authorization. Las claves tienen un prefijo (nd_live_) para facilitar su identificación y pueden revocarse instantáneamente desde el panel de control.

Webhooks Firmados con HMAC

Los payloads de webhooks salientes se firman con HMAC-SHA256 usando un secreto de firma por endpoint. La firma se entrega en la cabecera X-Signature-256 para que pueda verificar su autenticidad.

Lista Blanca de Parámetros Fuertes

Todas las acciones de controlador usan listas explícitas de parámetros permitidos. El permit general está prohibido por política del proyecto y se verifica en la revisión de código.

Seguridad de la Aplicación

Cabeceras, políticas y protecciones del navegador.

Política de Seguridad de Contenido

Una CSP estricta restringe las fuentes de scripts, estilos, imágenes y marcos. frame-ancestors se establece en 'none' para prevenir el clickjacking.

Filtrado de Parámetros Sensibles

Las contraseñas, tokens, claves API, SSNs y otros valores sensibles se eliminan automáticamente de los logs de la aplicación.

Autenticación de Administrador Independiente

El panel de administración interno utiliza un ámbito de autenticación aislado con sus propias credenciales, separado de las cuentas de clientes.

Pruebas de Seguridad Continuas

Comprobaciones automatizadas en cada commit.

Brakeman

Escáner de análisis estático que comprueba inyección SQL, XSS, asignación masiva y otras vulnerabilidades específicas de Rails en cada ejecución de CI.

bundler-audit

Comprueba todas las dependencias de gems de Ruby contra la Ruby Advisory Database en busca de CVEs conocidos antes de cada despliegue.

importmap:audit

Escanea las dependencias de JavaScript vendorizadas en busca de vulnerabilidades conocidas.

¿Tiene preguntas sobre nuestras prácticas de seguridad?

Estaremos encantados de discutir nuestra arquitectura, responder cuestionarios de seguridad o programar una llamada con nuestro equipo.