Seguridad

Última actualización: 4 de septiembre de 2026

1. Alcance

Esta página describe los controles que protegen el servicio de administración de almacenes AirHive (el “Servicio”) y los datos que su organización guarda en él. Está escrita para quien realiza una evaluación previa antes de confiarnos su operación, por lo que indica lo que existe hoy y no lo que está planeado.

2. Cifrado

  • En tránsito. Toda conexión al Servicio usa TLS. Las cookies de sesión se marcan como secure en producción, por lo que el navegador no las envía por una conexión sin cifrar.
  • En reposo. La base de datos y el almacenamiento de archivos están cifrados con AES-256 por nuestro proveedor de infraestructura.

3. Autenticación

  • Las contraseñas se almacenan como hashes bcrypt. Nunca conservamos, registramos ni transmitimos una contraseña en forma legible, y por eso tampoco podemos decirle cuál es la suya.
  • La autenticación de dos factores (TOTP) está disponible para todos los usuarios y funciona con cualquier aplicación autenticadora estándar. Se ofrece, no se impone: cada usuario decide si la activa.
  • Una cuenta suspendida se rechaza en cada solicitud, no solo al iniciar sesión, por lo que revocar el acceso surte efecto de inmediato y no hasta que expire la sesión actual.

4. Sesiones

  • Las cookies de sesión son httpOnly: el JavaScript que se ejecuta en la página no puede leerlas, así que un script inyectado en el navegador no puede llevarse su sesión.
  • La falsificación de solicitudes entre sitios se bloquea con un token de doble envío, aplicado de forma global y no ruta por ruta.
  • Las sesiones están ligadas al navegador que las creó. Si un token de sesión aparece desde otra familia de navegador, se rechaza; un cambio de dirección IP se permite pero se registra. Por lo tanto, una cookie robada no basta por sí sola.

5. Control de acceso

Los permisos se resuelven mediante guardas compartidas por las que pasa cada endpoint, no con verificaciones escritas caso por caso: el patrón que permite que una línea olvidada se convierta en una puerta abierta.

  • Los usuarios tienen roles, y los roles otorgan acceso de lectura o escritura por módulo.
  • Qué módulos tiene una organización se define al crearla y solo nosotros podemos cambiarlo; no es de autoservicio.
  • Las superficies administrativas están detrás de su propia guarda, separada de la autenticación ordinaria, y las operaciones sensibles requieren un paso de reautenticación.

6. Separación entre organizaciones

Cada registro de negocio lleva el identificador de la organización a la que pertenece, y el límite se aplica en la capa de servicios por la que pasa todo acceso a datos: un solo lugar que auditar en lugar de uno por consulta. Los registros se indexan por ese identificador para que el filtro se aplique en cada lectura y no después.

7. Registro y trazabilidad

El Servicio mantiene bitácoras de auditoría separadas para la actividad general, las acciones administrativas, los cambios a artículos del catálogo y los cambios a proveedores. Cada intercambio con el asistente de IA también se registra; consulte la Política de Privacidad. Las entradas de auditoría se escriben fuera de la transacción que describen, de modo que el registro de una operación fallida sobrevive a la falla en lugar de revertirse con ella.

8. Protección de la aplicación

  • Se aplican límites de solicitudes por organización, con límites más estrictos en el inicio de sesión y en los endpoints administrativos.
  • Los intentos automatizados de inicio de sesión se filtran con un desafío de protección contra bots.
  • Los archivos cargados tienen límite de tamaño y se validan por tipo en el servidor. La validación en el cliente se trata como una comodidad, nunca como un control.

9. Cómo construimos

Las revisiones de seguridad se ejecutan en cada cambio propuesto, antes de que pueda integrarse: un análisis de credenciales confirmadas por accidente, análisis estático de defectos de seguridad, además de compilación, lint, verificación de tipos y la suite de pruebas. Las migraciones de base de datos siguen una disciplina de expandir y luego contraer —una columna nunca se elimina en el mismo cambio que introduce su reemplazo— para que un despliegue pueda revertirse sin perder datos.

10. Proveedores

La infraestructura y los servicios de terceros que procesan datos por nuestra cuenta se listan por nombre, con los datos que maneja cada uno, en la tabla de subencargados de nuestra Política de Privacidad. Actualizamos esa lista cada vez que se agrega o reemplaza un proveedor.

11. Certificaciones

AirHive no cuenta actualmente con un informe SOC 2 ni con la certificación ISO 27001, y preferimos decirlo claramente a dejar que una página de seguridad lo sugiera. Los controles anteriores se sostienen por sí mismos y pueden verificarse usando el Servicio. Si su proceso de compras requiere una auditoría formal, contáctenos y le diremos con honestidad en qué punto estamos.

12. Reporte de vulnerabilidades

Si cree haber encontrado una falla de seguridad, escriba a security@airhivemx.com con el detalle suficiente para reproducirla. Acusaremos recibo de su reporte y lo mantendremos informado mientras trabajamos en ella. Le pedimos darnos un plazo razonable para corregir el problema antes de divulgarlo públicamente. No emprenderemos acciones legales contra quien reporte una falla de buena fe y no acceda, altere ni destruya datos de otras personas al encontrarla.

13. Cambios a esta página

Revisamos estos controles periódicamente y actualizamos esta página cuando cambian. La fecha de “Última actualización” de arriba refleja la revisión más reciente. Las dudas sobre cualquier punto se dirigen a security@airhivemx.com.