Seguridad

Cómo se protegen sus datos

• Cifrado en tránsito y en reposo. TLS 1.2+ en todas partes; almacenamiento cifrado en la capa de la plataforma.
• Aislamiento por espacio de trabajo. Cada registro lleva un identificador de espacio de trabajo y cada consulta se limita a él, incluidos los endpoints que actúan sobre un solo registro; así, un identificador adivinado desde una cuenta no puede llegar a los datos de otra.
• Gestión de contraseñas. Las contraseñas se procesan con scryptcon los parámetros recomendados por OWASP — — cada una con su propia sal aleatoria, y nunca se guardan ni se registran de forma recuperable. La verificación es de tiempo constante, exigimos un mínimo de 10 caracteres y rechazamos contraseñas que aparecen en filtraciones conocidas. scrypt esintensivo en memoria: cada intento necesita 128 MB de memoria además de tiempo, lo que lo encarece frente a las tarjetas gráficas que abaratan el descifrado habitual de contraseñas. Las cuentas creadas con nuestro esquema anterior se actualizan automáticamente la próxima vez que su titular inicia sesión.
• Su cuenta no existe hasta que demuestre que la dirección es suya. Registrarse deja un registro pendiente y le envía un enlace por correo; la cuenta, el espacio de trabajo y la sesión se crean cuando hace clic en él. Eso elimina toda una clase de ataque en lugar de defenderse de él: nadie puede registrar una cuenta con su correo, ponerle una contraseña y esperar a que usted se registre y la adopte.
• Los intentos automatizados de inicio de sesión se someten a un desafío. El inicio de sesión, el registro, el restablecimiento de contraseña y el formulario de contacto están protegidos por un desafío antibots que respeta la privacidad, además de límites de frecuencia, así que recorrer una lista de contraseñas filtradas cuesta más de lo que rinde. Los límites cuentan contra la cuenta que se intenta además de la dirección desde la que se intenta, porque un atacante con un conjunto de direcciones burla un límite solo por dirección cambiando de dirección; y los fallos repetidos para una cuenta se ralentizan progresivamente en lugar de bloquearse, durante minutos, nunca de forma permanente. El restablecimiento de contraseña se cuenta aparte del inicio de sesión, así que quien agote a propósito sus intentos de inicio de sesión no puede cerrar también la vía que usaría para volver a entrar.
• Verificación en dos pasos. Tres opciones: llaves de acceso (Face ID, Touch ID, Windows Hello o una llave física), una app de autenticación o un código enviado por correo. Las llaves de acceso son las más seguras y las únicas resistentes al phishing, porque la firma está ligada a closerev.com. Los códigos por correo son los más débiles (quien llega a su buzón llega al código) y así lo decimos donde se activan. Los códigos de recuperación de un solo uso cubren la pérdida de un dispositivo. En cuanto activa cualquier factor, se aplica a todas las formas de entrar en la cuenta, incluido «Iniciar sesión con Google»: una segunda vía de acceso no es una forma de esquivarlo. El propietario de un espacio de trabajo también puede exigir la verificación en dos pasos a todo el mundo en él, para que nadie llegue a sus datos solo con una contraseña. Para añadir un método hace falta uno que ya tenga, y le enviamos un correo cuando se añade uno. De lo contrario, alguien que se hiciera con un dispositivo en el que usted tenía la sesión iniciada podría añadir su propio autenticador y conservar el acceso incluso después de que usted cambiara su contraseña. El aviso va a su dirección, no a la pantalla de quien lo hizo, e incluye un enlace que cierra la sesión en todos los dispositivos, incluido el suyo. Los métodos se pueden añadir, pero no quitar. De lo contrario, alguien que se hiciera con un dispositivo en el que usted tenía la sesión iniciada quitaría los métodos que no tiene y conservaría el que sí, dejando su cuenta protegida justo por lo que robó. ¿Perdió un dispositivo? Cambie su contraseña, lo que cierra al instante todas las demás sesiones, y escríbanos: verificamos su identidad y quitamos el método, y ese restablecimiento queda registrado en el registro a prueba de manipulaciones descrito abajo.
• Las acciones más arriesgadas vuelven a preguntar. Cerrar su cuenta, cambiar su contraseña, exportarlo todo o cambiar un ajuste de seguridad de todo el espacio de trabajo le exigen demostrar que sigue siendo usted: el código de su app de autenticación si la tiene y, si no, su contraseña. Una cookie de sesión dice que alguien inició sesión; no dice que quien está al teclado siga siendo usted, y para estas pocas acciones esa diferencia es toda la cuestión. Para la mayoría, la prueba dura 30 minutos, así que una tanda de tareas de administración pregunta una sola vez. Activar o desactivar un requisito de todo el espacio de trabajo (verificación en dos pasos, inicio de sesión único) pregunta siempre, en ambos sentidos: un ajuste que rebaja lo que hace falta para llegar a sus datos nunca debe apoyarse en una prueba dada para otra cosa.
• Inicio de sesión único. Los espacios de trabajo Enterprise y Agency pueden exigir que todo el mundo inicie sesión a través de su propio proveedor de identidad mediante OpenID Connect. Un dominio tiene que demostrarse en el DNS antes de poder usarse, así que nadie puede configurar el inicio de sesión único para un dominio que no controla. Una vez exigido, las contraseñas y el inicio de sesión con Google dejan de funcionar para ese dominio, con una excepción deliberada, el propietario del espacio de trabajo, para que un proveedor mal configurado no pueda dejar a una empresa fuera de sus propios datos. Las sesiones creadas así duran una semana en lugar de un mes, porque el inicio de sesión único por sí solo no revoca el acceso cuando alguien se va. El client secret que nos da se cifra antes de guardarse.
• Sesiones.Tokens opacos que caducan, en cookies httpOnly, Secure y SameSite con el prefijo, que impide que cualquier otro sitio de un dominio vecino escriba una cookie que nuestros servidores leerían como suya. Se pueden revocar en el servidor, y cambiar su contraseña invalida al instante todas las demás sesiones. Las solicitudes que cambian algo deben originarse en el propio CloseRev; un formulario en el sitio de otra persona que envíe datos al nuestro se rechaza antes de llegar a sus datos. Los tokens de sesión se guardan solo como hash, así que una copia de nuestra base de datos no serviría para iniciar sesión como nadie. Una sesión termina a los 30 días, o a los 7 días sin uso. Y cuando se inicia sesión en su cuenta desde un navegador que no hemos visto antes, le enviamos un correo, con un enlace que cierra la sesión en todos los dispositivos si no fue usted.
• Enlaces por correo. Los enlaces de verificación y restablecimiento son de un solo uso y caducan, y solo guardamos un hash SHA-256 de cada token: una filtración de la base de datos no daría enlaces que funcionen. El uso único lo impone la base de datos en un solo paso, así que dos clics que lleguen en el mismo instante no pueden tener éxito ambos.
• Pagos. Los datos de la tarjeta van directamente a Stripe y nunca llegan a nuestros servidores, lo que nos deja fuera del ámbito del manejo de datos de tarjetas.
• Registro de auditoría. Las subidas, coincidencias, cambios en revisión, exportaciones y eliminaciones se registran por espacio de trabajo. Aparte, cada vez que alguien de CloseRev abre una consola interna que puede ver su cuenta, también queda registrado: quién, qué consultó y cuándo. Conservamos ese registro durante 24 meses, que es el periodo más largo durante el que cualquier plan conserva sus datos, así que la pregunta «¿alguien miró esto?» sigue teniendo respuesta mientras existan los propios datos. Esas entradas están encadenadas: cada una se sella con un hash que cubre la anterior, y la base de datos se niega a cambiar o volver a sellar una entrada sellada. Quitar o editar una entrada a posteriori rompe la cadena en ese punto, y una comprobación que se ejecuta cada noche indica dónde. Además, cada noche se escribe una copia del sello más reciente de la cadena en un almacén con credenciales distintas, para que el registro y su propia constancia no puedan reescribirse a la vez.
• Eliminación real. Eliminar una importación borra sus registros, sus resultados de coincidencia y el archivo original subido del almacenamiento, no solo una marca en una fila.
• Las exportaciones son seguras de abrir.Una hoja de cálculo trata una celda que empieza por , , o como una fórmula que ejecutar, así que un valor que alguien metiera en un CSV que usted subió podría convertirse en un comando en el equipo de quien abra su exportación. Neutralizamos esas celdas de forma que resiste guardar y volver a abrir el archivo, y dejamos intactos los números normales y los importes negativos.

Minimización de datos

La conciliación necesita un teléfono o una dirección de correo, y un importe. Usted elige qué columnas asignar, y preferimos que suba menos. Los datos de categorías especiales quedan totalmente fuera: consulte la Política de uso aceptable.

Lo que aún no hemos hecho

Preferimos decir esto con claridad antes que dejar que una página de confianza sugiera más de lo que es cierto:

• Sin certificación SOC 2 ni ISO 27001. Somos un producto en una etapa temprana y no hemos pasado una auditoría.
• Aún no hay prueba de penetración de terceros. Aún no se ha encargado. Esta línea cambiará cuando se haya hecho, no antes.
• Sin residencia de datos configurable por el cliente. La región de almacenamiento es actualmente la predeterminada de la plataforma.

Si alguno de estos puntos bloquea su proceso de compra, díganoslo: nos sirve saber cuál abordar primero.

Quién en CloseRev puede ver sus datos

• Nadie, en condiciones normales. El producto es de autoservicio y el soporte no requiere leer sus registros. No existe la función «iniciar sesión como este cliente» ni suplantación de identidad, a propósito: en cuanto existe una, se convierte en el camino más corto hacia los datos de todos los clientes.
• La consola interna no puede leer en absoluto sus registros subidos. Muestra información de la cuenta y de facturación, y recuentos de lo que ha procesado. No tiene acceso a los registros de ventas ni de leads.
• Se registran las lecturas, no solo las escrituras. Todo lo que consulta un administrador queda registrado con quién, qué, cuándo y desde dónde. Si alguna vez pregunta quién de CloseRev miró su cuenta, la respuesta sale de un registro y no de la memoria.
• El acceso exige inicio de sesión único con varios factores. La consola está detrás de Cloudflare Access y además comprueba la identidad verificada contra una lista de permitidos, así que no existe ninguna contraseña nuestra que se pueda obtener mediante phishing para entrar.

Cómo probamos lo que publicamos

Con cada cambio se ejecutan dos comprobaciones sobre el código, porque razonar sobre el aislamiento no es lo mismo que verificarlo:

• Cada consulta que toca datos de clientes se enumera y se revisa. Una comprobación extrae cada sentencia y mantiene una línea base revisada, así que una consulta nueva o reescrita que no esté limitada a un espacio de trabajo tiene que revisarse en lugar de pasar desapercibida.
• El aislamiento se prueba con HTTP real, no se razona. Se crean tres espacios de trabajo separados en una copia real de nuestro entorno de ejecución, y a cada endpoint que acepta un identificador se le piden los datos de otro espacio de trabajo, a través del mismo código que ejecuta el sitio, con la misma base de datos, almacenamiento y sesiones. Una prueba que no puede fallar no vale nada, así que cada una se ejecuta junto a un control que demuestra que el propietario legítimo sigue obteniendo sus datos.
• Las páginas se miden en un navegador, no a ojo : cada página, en claro y oscuro, en anchos de escritorio y de móvil, para detectar desbordamientos, recortes y contraste.
• Los cambios en la base de datos los aplica un ejecutor que lleva un registro, que se niega a aplicar nada dos veces, fuera de orden o cuando el historial registrado y el código ya no coinciden.

Una revisión de seguridad por escrito que cubre el aislamiento entre clientes, la autenticación, las subidas, la facturación, los tokens públicos y el ciclo de vida de los datos es condición para la disponibilidad general. Se ha realizado repetidamente, la más reciente en dos pasadas específicas antes del lanzamiento, contra la configuración de pagos en producción y dentro de una copia real del entorno en el que desplegamos. Ambos informes recogen lo que no se demostró con la misma claridad que lo que sí.

Copias de seguridad, conservación y eliminación

• Usted fija el periodo de conservación por espacio de trabajo, dentro de lo que conserva su plan. Un proceso nocturno elimina las importaciones que lo superan (los registros, los resultados de coincidencia y los CSV originales en el almacenamiento de objetos) y anota lo que hizo en el registro de actividad de su propio espacio de trabajo.
• Eliminar es eliminar. Quitar una importación borra sus registros y archivos. Cerrar su cuenta borra la cuenta y, si usted es su propietario, el espacio de trabajo y todos los archivos que le pertenecen. Las facturas se conservan solo donde lo exige la ley fiscal.
• Las copias de seguridad son las de la plataforma, con recuperación a un momento dado que cubre los últimos 30 días de la base de datos. Sirven para recuperarnos de un fallo nuestro, no son una segunda copia que pueda consultar.
• Una restauración no puede deshacer una eliminación en silencio. Este es el único lugar donde «eliminar es eliminar» necesitaba más que un borrado: rebobinar la base de datos para recuperarse de algún fallo ajeno devolvería de otro modo todo lo eliminado desde entonces, y nadie lo sabría. Por eso cada eliminación se registra (qué se quitó, de qué espacio de trabajo, cuándo y por qué, sin ninguno de los datos) y volver a aplicar esos registros es un paso de nuestro procedimiento de restauración, no algo que recordar. Los archivos subidos no están cubiertos por ese rebobinado: una vez eliminado del almacenamiento de objetos, un archivo desaparece.

Si algo sale mal

• Violaciones de datos personales: notificamos a los clientes afectados sin demora indebida y en un plazo de 72 horas desde que tenemos conocimiento, con lo que sabemos y lo que estamos haciendo. Ese compromiso es contractual: está en el DPA, no solo aquí.
• Interrupciones que afectan a la integridad de los datos o al acceso: enviamos un correo a los propietarios de los espacios de trabajo en lugar de esperar a que alguien consulte una página, y otra vez cuando se resuelve. El estado de cada componente se publica en nuestra página de estado, que mide en lugar de actualizarse a mano.

Por qué esta página es tan concreta

Nombrar el algoritmo y sus parámetros de coste es deliberado, y es lo que piden las normas de seguridad, no algo que nos permitimos. Un sistema debe ser seguro aunque todo sobre él salvo las claves sea público; ese principio es más antiguo que el sector, y por eso el NIST publica abiertamente sus estándares criptográficos en lugar de describirlos de forma vaga. Un diseño que solo resiste mientras nadie sabe cómo funciona no es un diseño que resista.

Lo que no encontrará aquí es nada que sea realmente secreto: ni versiones de software ni niveles de parches, ni nombres de host internos ni topología de red, ni material de claves, ni umbrales que un atacante pudiera ajustar: cuántos intentos provocan un bloqueo o cuánto dura un límite de frecuencia. Las cifras de esta página son compromisos que asumimos con usted, no ajustes a los que apuntar.

Si nos está evaluando y algo de aquí no es lo bastante concreto para responder a su pregunta, pregunte. Preferimos ponerlo por escrito a que tenga que adivinarlo.

Informar de una vulnerabilidad

Correo security@closerev.com, o lea la versión legible por máquina en /.well-known/security.txt. Acusamos recibo en un plazo de 2 días hábiles, le decimos si lo hemos reproducido en un plazo de 10 días hábiles y le mantenemos informado hasta que se cierre. Pedimos 90 días antes de la divulgación pública, y menos si la corrección sale antes.

No acceda, modifique ni conserve datos que no sean suyos, no ejecute escaneos automatizados que degraden el servicio para los clientes y no aplique ingeniería social a nuestro personal ni a nuestros proveedores. Dentro de esos límites, no emprenderemos acciones contra investigadores que actúen de buena fe, y le daremos el crédito si lo desea.

Relacionado

Política de privacidad · Acuerdo de tratamiento de datos · Subencargados