Skip to contentNuevoPresentamos el Ranking de Candidatos con IA
Confianza

Seguridad

Cómo está construido Artifind para proteger los datos de cada organización. Describimos controles que existen hoy en el código, y cerramos con lo que todavía no implementamos.

Última actualización: [COMPLETAR: fecha de vigencia]

Borrador en revisión legal. Este documento describe cómo funciona Artifind hoy, pero todavía no fue validado por un abogado y contiene campos por completar. No lo tomes como texto definitivo.

Aislamiento entre organizaciones

Artifind es multi-inquilino: varias organizaciones comparten la misma base de datos. La separación no depende de que el código recuerde filtrar por empresa en cada consulta — eso es exactamente el tipo de control que falla el día que alguien olvida una cláusula.

La separación se aplica en la base de datos, con políticas de seguridad a nivel de fila. Cada petición abre una transacción vinculada a una organización, y las políticas filtran por ese valor. La aplicación se conecta con un rol que no puede saltear esas políticas.

Además, el acceso a una búsqueda puede restringirse por departamento o por permiso explícito, de modo que un reclutador vea únicamente las vacantes que le corresponden.

Autenticación y sesiones

  • Las contraseñas se almacenan con Argon2id, con parámetros de costo configurables. Nunca se guardan en texto plano ni de forma reversible.
  • El acceso usa tokens de vida corta; la renovación se hace con tokens rotativos agrupados en familias, lo que permite revocar todas las sesiones de una persona de una sola vez.
  • El token de renovación viaja en una cookie no accesible por JavaScript.
  • Cambiar el email de acceso requiere confirmación desde la casilla nueva, y revoca las sesiones activas.
  • Los enlaces de invitación, verificación y recuperación son de un solo uso, con vencimiento, y se guardan como hash.

Cifrado

  • El tráfico viaja sobre TLS.
  • Las credenciales de integraciones que guardamos por cuenta del usuario — tokens de Microsoft y Google, contraseñas SMTP — se cifran con ChaCha20-Poly1305 antes de tocar la base de datos.
  • Ese cifrado usa un llavero versionado: se puede rotar la clave sin descifrar y volver a cifrar todo de golpe, porque cada registro recuerda con qué versión fue sellado.
  • Los respaldos se cifran antes de salir del servidor.

Archivos y adjuntos

Los CVs y los adjuntos de email se guardan en almacenamiento privado, nunca en un bucket público, y se acceden por URLs firmadas de vigencia acotada. Los logotipos de empresa son lo único que vive en almacenamiento público, porque están pensados para mostrarse en avisos.

Las subidas se validan por tipo de archivo contra una lista permitida y tienen un límite de tamaño. El nombre del archivo se normaliza para que no pueda contener rutas.

Un proceso diario recorre el almacenamiento y elimina los archivos que ya no tienen un registro asociado. Cuando se elimina un candidato — por decisión de la empresa, a pedido del candidato o porque venció el plazo de conservación que la empresa fijó — el CV y los adjuntos se van con el registro.

Registros y auditoría

Las acciones relevantes sobre datos — creación, cambio de etapa, eliminación de un candidato — quedan registradas con quién las hizo y cuándo.

Los registros técnicos son estructurados y están diseñados para no contener datos personales: las direcciones de email aparecen como un hash truncado, no en claro. No registramos contraseñas, contenido de CVs ni cuerpos de mensajes.

Protección contra abuso

  • Límites de tasa por dirección IP y por usuario autenticado.
  • Protección antibots en los formularios públicos: postulación, registro y solicitud de demo.
  • Política de seguridad de contenido activa en producción.
  • Las operaciones que modifican datos aceptan una clave de idempotencia para que un reintento no duplique el efecto.

Respaldos y continuidad

Se hacen respaldos periódicos de la base de datos, cifrados antes de subirse a un destino externo al servidor. El objetivo de punto de recuperación en la etapa actual es de hasta 24 horas.

El procedimiento de restauración está documentado. [COMPLETAR: confirmar frecuencia de la prueba de restauración — un respaldo que nunca se restauró no es un respaldo verificado.]

Desarrollo y pruebas

Cada cambio pasa por una batería automática antes de integrarse: análisis estático, linters, pruebas unitarias y una suite de integración que levanta una base de datos real y verifica, entre otras cosas, que el aislamiento entre organizaciones se sostenga.

Hay pruebas estructurales que fallan si alguien introduce un patrón riesgoso: una política de base de datos que no filtre por organización, o una llamada a un tercero dentro de una transacción abierta.

Las dependencias están fijadas y las credenciales nunca se versionan en el repositorio.

Proveedores

Parte del servicio se apoya en terceros — infraestructura, envío de email, procesamiento con IA. Están enumerados con su finalidad en la política de privacidad, y el listado completo se entrega como anexo del contrato de tratamiento de datos.

Lo que todavía no tenemos

Preferimos que esto lo leas acá y no que lo descubras después.

  • No tenemos certificación SOC 2, ISO 27001 ni equivalente.
  • No hicimos una prueba de intrusión por un tercero independiente.
  • No hay segundo factor de autenticación ni inicio de sesión federado (SSO/SAML). Están en el plan de producto, pero hoy no existen.
  • No publicamos aún un compromiso formal de disponibilidad.

Si alguno de estos puntos es un requisito para tu organización, escribinos antes de contratar y te contamos con qué plazos estamos trabajando.

Reportar una vulnerabilidad

Si encontraste un problema de seguridad, escribinos a [COMPLETAR: email de seguridad] con los pasos para reproducirlo. Nos comprometemos a acusar recibo y a no iniciar acciones contra quien investigue de buena fe, sin acceder a datos de terceros ni degradar el servicio. Pedimos no divulgarlo públicamente hasta que haya una corrección disponible.