El CAPTCHA debe detener bots, no trasladar datos de usuario fuera de su organización.
Muchas implementaciones de CAPTCHA comparten la IP del cliente, la huella del navegador, el conjunto de cabeceras y la telemetría de comportamiento con servicios de terceros en el momento de la verificación. Ese modelo es aceptable en algunos sectores, pero en entornos del sector público, financiero, sanitario y con air-gap crea una exposición seria en términos de residencia de datos y cumplimiento normativo.
Para organizaciones sensibles al cumplimiento, incluso una sola llamada CAPTCHA en una pantalla de inicio de sesión puede desencadenar un debate sobre transferencia de datos personales. Los requisitos de consentimiento explícito, las normas de transferencia transfronteriza, las salvaguardas contractuales y la dependencia del proveedor pueden convertir una simple decisión de protección anti-bots en un largo proyecto de cumplimiento.
Depender de servicios CAPTCHA externos también genera riesgo operacional. Cuando un servicio de verificación de terceros se ralentiza o queda inaccesible, el flujo de inicio de sesión, registro o pago de cada aplicación protegida se ve afectado. La protección anti-bots se convierte en una dependencia externa crítica para la aplicación.
El modelo correcto es realizar la generación, entrega y verificación del desafío dentro de la propia capa ADC de la organización. Los datos del cliente permanecen locales, el proceso de verificación es autocontenido, la dificultad escala con el riesgo del servicio y los intentos fallidos pueden alimentar la escalada a cuarentena.
TR7 CAPTCHA Auto-Alojado ofrece exactamente este modelo: hace que la verificación de bots sea auto-alojada, reduce el riesgo de residencia de datos y se integra directamente con el pipeline de decisiones WAAP.
Nuestro enfoque
TR7 implementa CAPTCHA mediante generación local, dificultad ajustable, modos de verificación visible e invisible, y escalada a cuarentena.
La generación, entrega y verificación ocurren dentro del ADC
La imagen CAPTCHA, el contenido HTML/JS, la firma del token y la verificación de la solución se ejecutan en TR7. No se realiza ninguna llamada HTTP saliente a un servicio externo durante el proceso de verificación.
Un único parámetro de dificultad gobierna múltiples parámetros de seguridad
La dificultad se evalúa junto con la longitud de caracteres, el ruido visual, la carga de trabajo PoW y el tiempo mínimo de resolución. El operador establece el equilibrio correcto entre experiencia de usuario y resistencia a bots con un único ajuste.
El CAPTCHA visible y el modo PoW invisible se soportan simultáneamente
La verificación visual puede mostrarse a clientes de alto riesgo. Para clientes de riesgo medio, la validación PoW puede ejecutarse silenciosamente en segundo plano sin presentar una pantalla adicional al usuario.
La puntuación de bots y las respuestas fallidas alimentan la escalada a cuarentena
El CAPTCHA se activa solo cuando se supera un umbral de riesgo. Las respuestas incorrectas se rastrean; una vez superado el umbral, se pueden aplicar acciones de cuarentena como denegar, redirigir, contenido personalizado o un código de estado personalizado.
Capacidades
El CAPTCHA Auto-Alojado combina la generación de desafíos auto-alojada con el scoring de bots, PoW, seguridad de cookies y flujos de cuarentena.
El proceso de desafío auto-alojado funciona sin ninguna llamada a servicios cloud externos
TR7 genera la imagen CAPTCHA internamente, sirve la página de desafío desde su propio servicio y verifica las soluciones mediante un proceso helper local. La IP del cliente, el agente de usuario y el resultado de la verificación nunca se envían a un servicio externo. Este modelo proporciona una ventaja crítica para organizaciones con requisitos de residencia de datos. La protección CAPTCHA se aplica sin ninguna dependencia de servicios externos.
Cinco niveles de dificultad ajustan PoW, longitud de caracteres y ruido visual de forma conjunta
En TR7, la dificultad se selecciona en una escala del 1 al 5. Este valor se corresponde con la profundidad de bits PoW (16–20 bits), la longitud de caracteres CAPTCHA (4–7 caracteres), la densidad de líneas y puntos visuales, y un tiempo mínimo de resolución aplicado por el servidor. El operador gestiona tanto la experiencia humana como el coste para bots con un único slider. Los servicios de mayor riesgo pueden configurarse con mayor dificultad.
Proof-of-Work elimina la ventaja de la respuesta instantánea que disfruta la automatización
La validación PoW se aplica como parte de la verificación CAPTCHA. El navegador debe completar un cálculo definido antes de que se acepte la solución. También se aplica un tiempo mínimo de resolución en el servidor — aunque un bot produzca la respuesta correcta al instante, una solución que llega demasiado rápido se trata como sospechosa. Este enfoque eleva el coste de la automatización mientras añade una carga mínima a los usuarios genuinos.
La cookie cifrada y el enlace IP+UA reducen el riesgo de replay de tokens
El token producido tras una verificación exitosa se transporta en una cookie cifrada. El token puede vincularse al contexto de la dirección IP y el agente de usuario del cliente, dificultando significativamente la reutilización de un token de verificación obtenido por un cliente en un contexto diferente. Durante la ventana verifiedTtl, el usuario genuino no tiene que resolver el CAPTCHA en cada solicitud.
Cada regla CAPTCHA puede ejecutarse con un proceso helper aislado
TR7 puede asignar un proceso helper dedicado y una ruta de socket dedicada a cada regla CAPTCHA. Este aislamiento reduce el impacto de un fallo o pico de carga en una regla sobre otras reglas. La separación basada en pool significa que los flujos CAPTCHA para distintos servicios se gestionan de forma independiente. scalingCount permite ejecutar múltiples procesos para la misma regla.
El CAPTCHA de texto visible y el PoW invisible se aplican a diferentes niveles de riesgo
Cuando el tipo se establece en text, el usuario se encuentra con un CAPTCHA visual. En el modo invisible, la verificación basada en PoW se ejecuta sin presentar una pantalla de desafío completa. Los clientes de riesgo medio se verifican con menos fricción, mientras que los de mayor riesgo reciben CAPTCHA visual para aumentar el coste para bots.
El tema, el color y el tamaño pueden personalizarse para alinearse con la marca
El color de fondo, el color del texto, el tema y el tamaño pueden definirse por servicio. Los tamaños de CAPTCHA pequeño, mediano y grande se adaptan a distintas interfaces de usuario. La pantalla de verificación no parece desconectada de la experiencia de marca de la organización. En escenarios B2B SaaS de marca blanca, cada tenant puede ofrecer una experiencia que se ajuste a su propia identidad visual.
Las pantallas de verificación multilingüe mejoran la experiencia de usuario
Los títulos de CAPTCHA, el texto descriptivo y los mensajes de error pueden vincularse a una estructura multilingüe. El idioma puede seleccionarse por servicio o según el contexto del cliente. Esto proporciona un flujo de verificación más claro en servicios del sector público, financiero y multirregionales. Añadir un nuevo idioma no requiere cambiar la lógica de verificación.
El scoring de bots garantiza que el CAPTCHA solo se muestre a clientes sospechosos
No es necesario mostrar el CAPTCHA a todos los usuarios por defecto. El scoring de bots, la reputación de IP, las señales de comportamiento y las condiciones DDoS de TR7 pueden restringir la presentación del desafío únicamente a clientes de riesgo. Esto reduce la fricción para los usuarios genuinos. El tráfico de confianza continúa por la ruta normal mientras el tráfico sospechoso se enruta hacia la verificación.
La cuarentena CAPTCHA convierte las respuestas incorrectas en una penalización
Las respuestas CAPTCHA incorrectas pueden rastrearse, y una vez superado el umbral definido el cliente queda en cuarentena. La acción de cuarentena puede configurarse como deny, redirect, customContent o customStatusCode. Esto evita que los bots consuman desafíos de forma continua para agotar el sistema. A medida que aumentan los fallos, una acción más contundente reemplaza al desafío.
Una cookie verificada reduce la carga de desafíos repetidos
Cuando un usuario supera el CAPTCHA con éxito, puede considerarse verificado durante un período configurado. Al mismo usuario no se le muestra CAPTCHA de nuevo hasta que expire verifiedTtl. Esto preserva la experiencia del usuario genuino mientras mantiene la barrera de verificación inicial contra los bots. El enlace IP+UA dificulta que el estado de verificación sea robado y reproducido en un contexto diferente.
Las políticas WAAP, DDoS, ATO y de reputación de IP activan CAPTCHA como acción integrada
El CAPTCHA no es una pantalla independiente — es una de las acciones en el pipeline de decisiones de TR7. La protección DDoS, la protección anti-bots, la reputación de IP y las políticas de account takeover pueden todas activar la acción showCaptcha. Cada módulo de seguridad puede conectar su propia señal de riesgo al flujo de verificación CAPTCHA. El operador utiliza una única infraestructura de desafío auto-alojada en diferentes escenarios de riesgo.
Profundidad operacional
El CAPTCHA auto-alojado se opera junto con procesos helper, gestión de secretos, enlace de tokens, una máquina de estados de cuarentena, soporte multilingüe y registros de auditoría.
Procesos helper aislados
Cada regla CAPTCHA puede ejecutarse con un proceso helper dedicado. Si el proceso termina inesperadamente, puede reiniciarse automáticamente. Un fallo en una regla no afecta a la verificación CAPTCHA en otros servicios.
Separación de sockets basada en pool
Puede crearse una ruta de socket dedicada para cada pool y regla CAPTCHA. Esta estructura separa el tráfico de verificación de desafíos entre servicios. Cuando la configuración se reproduce, se preserva la correspondencia entre la misma regla lógica y la misma estructura de socket físico.
Derivación determinista de secretos
Puede generarse un secreto distinto para cada regla, y los tokens de verificación se firman con ese secreto. Cuando se rota un secreto, los tokens verificados existentes pueden invalidarse. Este comportamiento puede aprovecharse para renovaciones de seguridad planificadas.
Compatibilidad con navegadores modernos y heredados
La resolución PoW puede utilizar APIs más eficientes en navegadores modernos. En entornos sin soporte, se aplica un fallback JavaScript más lento pero compatible. En clientes móviles, el proceso de resolución se ejecuta de forma asíncrona para que la interfaz de usuario no se bloquee.
Máquina de estados de cuarentena
Las respuestas fallidas a desafíos se rastrean por separado. Cuando se supera el umbral, el cliente se dirige a una acción de cuarentena durante un período configurado. Durante ese período, se aplica directamente deny, redirect o contenido personalizado en lugar de presentar otro CAPTCHA.
Registros de auditoría estructurados
Para cada desafío, pueden registrarse la marca de tiempo, la IP de origen, el agente de usuario, el ID de regla, el nivel de dificultad, el tipo de desafío y el resultado. El tiempo de resolución PoW también produce una señal valiosa para la investigación de incidentes. Estos registros apoyan los flujos de análisis de bots y forensia de fraude.
Cuándo utilizarlo
Portal de inicio de sesión bancario con requisitos de cumplimiento
Los bancos pueden verse obligados a evitar transmitir la IP del usuario o la información del navegador a servicios externos durante la verificación CAPTCHA. Con TR7 CAPTCHA Auto-Alojado, el proceso de desafío permanece dentro del ADC y la protección del inicio de sesión opera en línea con los requisitos de residencia de datos.
Aplicación del sector público en una red con air-gap
Los organismos gubernamentales que operan en entornos sin acceso a servicios de verificación externos pueden igualmente aplicar protección anti-bots. La generación y verificación de CAPTCHA de TR7 funcionan sin requerir resolución DNS externa ni llamadas HTTP salientes.
Barrera anti-bots en páginas de registro de e-commerce
Para fraude de cupones, creación de cuentas falsas o ataques de registro automatizado, el endpoint de registro puede colocarse tras CAPTCHA basándose en la puntuación de bots. Los intentos fallidos se vinculan a cuarentena, impidiendo que los bots consuman desafíos de forma continua.
Protección de portal sanitario sin dependencia de terceros
Los portales sanitarios pueden verificar a los usuarios en flujos de reserva de citas o acceso a pacientes que involucran datos sensibles sin depender de un servicio CAPTCHA externo. El proceso de verificación del usuario permanece bajo control organizacional.
Aplicar desafíos solo al tráfico de riesgo durante un evento DDoS
Durante una oleada DDoS o de bots, TR7 puede aplicar CAPTCHA o PoW invisible solo a los clientes con una puntuación de riesgo elevada. La mayoría de los usuarios genuinos continúan sin fricción adicional mientras se eleva el coste para los bots.
Pantalla de verificación con marca corporativa en un SaaS multi-tenant
Los proveedores B2B SaaS pueden configurar los ajustes de color, tema y tamaño por separado para cada tenant. La pantalla CAPTCHA no lleva ningún logotipo de terceros y se aproxima más a la experiencia del usuario propio del cliente.
Preguntas frecuentes
¿Salen datos del cliente de la organización durante el proceso CAPTCHA?
¿Cómo funciona el ajuste de dificultad?
¿Cuándo debe utilizarse el modo invisible?
¿Cómo funciona el mecanismo de cuarentena?
¿Tiene que resolver CAPTCHA un usuario verificado en cada solicitud?
¿Funciona en un entorno con air-gap o red cerrada?
Incorpore la verificación de bots a su propia infraestructura
CAPTCHA auto-alojado que mantiene los datos en local — integrado con los flujos WAAP, DDoS y ATO. Recorramos juntos una configuración en vivo en su propio entorno.