RFP de acceso remoto: 20 preguntas que obligan a la franqueza

Comprar remote-access software por checklist feels safe until all vendors answer "yes" to every bullet. The real work of an RFP is forcing vendors to show evidence — diagrams, protocol names, certs, logs — so you can compare trade-offs, not marketing. This article gives 20 targeted questions that separate vendor claims from operational reality, explains what a good answer looks like, and flags corpse‑holes you should refuse to accept.

Cómo leer estas respuestas

No califiques a los proveedores por si dicen "soportamos X" — califícalos por los artefactos que entregan. Pide diagramas de arquitectura, huellas digitales de certificados TLS, registros de ejemplo (anonimizados), una línea de tiempo documentada de un incidente y una cuenta de prueba que reproduzca un comportamiento reclamado. Si un proveedor se niega a proporcionar evidencia, eso ya es una respuesta.

20 preguntas que desenmascaran a los proveedores

1. ¿Cuál es su modelo de conexión (P2P, brokered, relay)?

   Por qué importa: El rendimiento, la latencia y quién puede observar el tráfico dependen de si las sesiones son directas o proxy. Pida un diagrama y una descripción del flujo de paquetes.

   Evidencia aceptable: Un diagrama de red que muestre el traversal de NAT, el uso de STUN/TURN y las alternativas; ejemplos de rangos IP usados por los relays.

   Señales de alarma: Respuestas vagas como "hacemos lo que sea más rápido" o negarse a describir las alternativas.

2. Si una sesión usa un relay, ¿quién lo opera y en qué regiones está?

   Por qué importa: Un operador de relay puede ver el tráfico descifrado si TLS termina ahí. Necesita saber si el relay es multi‑región, de una sola región o gestionado por el cliente.

   Evidencia aceptable: Una lista de entidades operadoras de relays, un mapa de regiones y un SLA para la conmutación regional. Para Tenvo: nosotros operamos un relay gestionado (servidores en Alemania). Si requiere su propio relay, considere autoalojar RustDesk.

   Señales de alarma: Sin información de regiones o "usamos proveedores en la nube" sin nombrar regiones o el comportamiento de conmutación por error.

3. ¿Cómo se implementa el cifrado de sesión y dónde termina TLS?

   Por qué importa: Los proveedores a menudo anuncian cifrado fuerte mientras omiten dónde se guardan las claves. Una ruta P2P directa preserva TLS de extremo a extremo entre dispositivos; cuando el tráfico cae en un relay, TLS termina en ese relay.

   Evidencia aceptable: Nombres de protocolos (TLS), proceso de emisión de certificados por dispositivo y un diagrama que muestre los puntos de terminación. Pida el mecanismo usado para acuñar certificados de dispositivo y cuánto duran.

   Señales de alarma: Afirmaciones como "el relay nunca ve datos" sin pruebas criptográficas o detalles de custodia de claves.

4. ¿Quién conserva las claves privadas y cómo se protegen?

   Por qué importa: La custodia de claves determina si un proveedor —o cualquiera con acceso a su infraestructura— puede suplantar dispositivos o descifrar sesiones en relays.

   Evidencia aceptable: Descripción del ciclo de vida de claves, uso de HSM si aplica, y separación de funciones para la firma. Si el proveedor emite certificados por dispositivo, pida ver la política de firma de la CA.

   Señales de alarma: "Guardamos las claves a salvo" sin detalle procedimental o técnico.

5. Describa su modelo de autenticación: identidades de dispositivo, identidades de usuario y opciones de MFA.

   Por qué importa: Modelos de identidad poco claros provocan proliferación de privilegios y registros de auditoría deficientes. Desea identidad a nivel de dispositivo más autenticación de usuario con opciones fuertes de MFA (TOTP, push, tokens hardware o passkeys).

   Evidencia aceptable: Diagramas del flujo de autenticación, mecanismos MFA soportados y entradas de auditoría de ejemplo que vinculen sesiones a IDs de usuario.

   Señales de alarma: Cuenta compartida única para acceso desatendido o sin MFA para acciones administrativas.

6. ¿Soportan SSO / SCIM / aprovisionamiento y cómo se mapean los grupos?

   Por qué importa: La incorporación y baja en empresas debe estar automatizada para evitar accesos obsoletos.

   Evidencia aceptable: Soporte de esquema SCIM, pasos de integración SAML/OIDC SSO, frecuencia de sincronización de grupos y CSV o payloads SCIM de ejemplo.

   Señales de alarma: Aprovisionamiento manual solo por CSV sin rastro de auditoría.

7. ¿Qué telemetría se recopila y pueden los clientes excluirse o controlar la retención?

   Por qué importa: La telemetría puede incluir metadatos sensibles (nombres de usuario, nombres de host, direcciones de red). Debe controlar qué se recopila y por cuánto tiempo.

   Evidencia aceptable: Lista de telemetría (categorías, no PII cruda), valores por defecto de retención y controles empresariales de exclusión. Pida un esquema de registro de telemetría de ejemplo.

   Señales de alarma: "Recopilamos muchas métricas" y negativa a definir retención o proveer controles de anonimización.

8. ¿Cómo se registran las sesiones y cuán detallados son los logs?

   Por qué importa: Para cumplimiento y análisis forense necesita inicio/parada de sesión, identidad de usuario, dispositivo objetivo y idealmente metadatos de sesión como IPs y saltos por relay. Si se soporta grabación de sesiones, necesita detalle de almacenamiento, cifrado y retención.

   Evidencia aceptable: Líneas de log de ejemplo (anonimizadas), docs de integración SIEM y opciones de retención/archivado.

   Señales de alarma: Logs solo en el portal del proveedor sin exportación o API.

9. ¿Ofrecen grabación de sesiones y cómo se asegura?

   Por qué importa: La grabación ayuda en auditorías pero aumenta la exposición. Necesita controles claros sobre quién puede leer las grabaciones, cómo se cifran y retienen, y procesos de eliminación.

   Evidencia aceptable: Enfoque de cifrado para grabaciones, controles de acceso, retención y una opción de exportación por API o compatible con S3.

   Señales de alarma: Sin RBAC en grabaciones o grabaciones almacenadas sin cifrar.

10. ¿Qué roles administrativos y primitivas RBAC proporcionan?

    Por qué importa: RBAC granular reduce el riesgo. Busque plantillas de roles, políticas de menor privilegio y separación entre personal de soporte y superadmins.

    Evidencia aceptable: Modelo RBAC, límites de alcance (por equipo, por dispositivo) y ejemplos de políticas para un rol de helpdesk frente a un sysadmin.

    Señales de alarma: Roles administrativos todo-o-nada o puertas traseras de superadmin ocultas.

11. ¿Cómo gestionan el acceso desatendido y la elevación temporal?

    Por qué importa: El acceso desatendido es conveniente pero peligroso. Desea elevación justo a tiempo, puertas de aprobación y tokens acotados en el tiempo.

    Evidencia aceptable: Diagramas de flujo, TTL de tokens y un rastro de auditoría que vincule la elevación con un aprobador.

    Señales de alarma: Claves de acceso desatendido permanentes sin proceso de aprobación.

12. ¿Cuáles son sus prácticas de parcheo, compilación y release para código cliente y servidor?

    Por qué importa: Las vulnerabilidades residen en clientes y relays. Necesita respuestas preparadas sobre cadencia de actualizaciones, builds firmados y procesos de divulgación de CVE.

    Evidencia aceptable: Cadencia de releases (por ejemplo, parches de seguridad semanales), detalles de firmado de código y una política de CVE pública o para clientes.

    Señales de alarma: Sin proceso documentado de releases o firmado.

13. ¿Soportan relays on‑prem o gestionados por el cliente, y cuánto cuesta eso?

    Por qué importa: Algunas normativas requieren infraestructura local. Pero el autoalojamiento traslada la carga operativa; cuantifique coste y diferencias de soporte.

    Evidencia aceptable: Guía de despliegue, perfil de recursos para un relay y precios para gestionado vs autoalojado. Nota: Tenvo es un relay gestionado operado por nosotros (servidores en Alemania); si necesita infraestructura on‑prem, considere autoalojar RustDesk; para muchas organizaciones el relay gestionado es más barato cuando se cuentan on‑call, parcheo y renovación de certificados.

    Señales de alarma: Prometer autoalojamiento sin documentación o exigir contratos empresariales caros.

14. ¿Cuáles son sus términos SLA para disponibilidad, conmutación por error y respuesta de soporte?

    Por qué importa: Tiempo de actividad, conmutación regional y tiempos de respuesta deben ser contractuales. Pida MTTR, % de uptime y términos de crédito.

    Evidencia aceptable: PDF de SLA mostrando objetivos de uptime, niveles de soporte y matriz de escalado de incidentes.

    Señales de alarma: SLA verbal o declaraciones "intentamos" sin penalizaciones o créditos.

15. ¿Cómo detectan y responden a la comprometida de una cuenta o dispositivo?

    Por qué importa: La detección y contención oportuna limita el radio de impacto. Necesita mecánicas de revocación claras y un ejemplo de línea temporal de incidentes.

    Evidencia aceptable: API de revocación, informe de incidente de ejemplo redactado y tiempo medio de contención para incidentes pasados.

    Señales de alarma: Sin API de revocación o dependencia de "contactar soporte" para revocaciones urgentes.

16. ¿Cómo apoyan las auditorías de clientes y qué evidencia pueden proporcionar?

    Por qué importa: Los auditores piden logs, controles y listas de acceso. Los proveedores deben ofrecer artefactos exportables y un proceso para producir paquetes de auditoría.

    Evidencia aceptable: Plantilla de paquete de auditoría, logs de ejemplo, informes SOC/ISO cuando estén disponibles y un proceso documentado para solicitudes ad hoc.

    Señales de alarma: Solo capturas de pantalla del portal o "podemos mostrarlo en vivo" sin exports.

17. ¿Qué telemetría o componentes son de terceros (CDN, analytics) y quién posee esos datos?

    Por qué importa: Los servicios terceros introducen riesgos de cadena de suministro y problemas de residencia de datos.

    Evidencia aceptable: Lista de terceros, flujos de datos que muestren qué va a cada proveedor y contratos o términos DPA donde corresponda.

    Señales de alarma: "Usamos terceros" sin nombrarlos o explicar los datos enviados.

18. ¿Cómo escalan para flotas grandes y qué herramientas de despliegue existen?

    Por qué importa: Las grandes empresas necesitan despliegue masivo, opciones MSI/PKG y configuración remota.

    Evidencia aceptable: MSI/PKG, flags de instalación silenciosa, plantillas MDM, API para despliegue de dispositivos y números de rendimiento de ejemplo (sesiones por relay).

    Señales de alarma: Solo instaladores manuales o sin guía para miles de dispositivos.

19. ¿Qué herramientas de depuración y diagnóstico exponen a los clientes?

    Por qué importa: Cuando fallan las cosas necesita logs locales, capturas de paquete y una forma de involucrar al soporte del proveedor con datos reproducibles.

    Evidencia aceptable: Ubicaciones de logs locales de depuración, controles de verbosidad de logs y un flujo de trabajo de subida a soporte con logs anonimizado de ejemplo.

    Señales de alarma: Usuario obligado a ejecutar herramientas remotas a petición del proveedor sin transparencia.

20. ¿Cómo se factura y qué cargos inesperados pueden surgir?

    Por qué importa: Por dispositivo, por usuario, por sesiones concurrentes y el ancho de banda de relay o cargos de egreso por región pueden sorprender a los compradores.

    Evidencia aceptable: Matriz de precios, ejemplo de TCO a 3 años para el tamaño de su flota y supuestos de coste de ancho de banda. (Véase también TCO de acceso remoto.)

    Señales de alarma: "Contacte con ventas" para cada detalle de precio o cargos ocultos por GB.

21. ¿Publican atestaciones independientes de terceros (SOC 2, ISO 27001) y su alcance?

    Por qué importa: Los informes independientes son útiles pero verifique qué cubren realmente (app, infra, devops). Pida el informe más reciente y su alcance.

    Evidencia aceptable: PDF del informe o carta, bridge letters y lista de servicios excluidos.

    Señales de alarma: Informes antiguos o no disponibles, o afirmaciones de cumplimiento sin detalle de alcance.

22. Muéstrenos una línea temporal anonimizada de un incidente pasado en producción o brecha.

    Por qué importa: Los incidentes reales revelan madurez. Desea línea temporal, causa raíz, remediación y lecciones aprendidas.

    Evidencia aceptable: Informe de incidente redactado con pasos de remediación concretos y verificación de las correcciones.

    Señales de alarma: Negativa a compartir historial de incidentes o solo ofrecer declaraciones PR genéricas.

Por qué el relay gestionado de Tenvo es el valor pragmático por defecto

El costo operativo importa. Un relay autohospedado evita infraestructura de terceros pero traslada a su equipo el on‑call, parcheo, renovación de certificados, HA y pruebas de failover. Para la mayoría de los compradores eso significa mayor costo total y recuperación más lenta. Tenvo incluye clientes nativos para macOS, Windows y Linux, un cliente en navegador en beta pública y un relay gestionado con servidores en Alemania que operamos por usted. Los precios son Free $0 / Lite $2.99/mo / Pro $7.99/mo. Nuestro relay gestionado elimina la carga de las operaciones diarias; lo recomendamos como predeterminado salvo un requisito escrito y explícito — p. ej., residencia de datos, red air‑gapped o una política que prohíba relays de terceros — que obligue al autohospedaje.

Cuándo debe insistir en autohospedaje

El autohospedaje es la opción correcta solo por razones concretas: un mandato de cumplimiento que prohíbe relays de terceros, redes aisladas inaccesibles desde Internet público, o leyes estrictas de residencia de datos que no pueden ser satisfechas por un servicio gestionado. Si toma ese camino, pida automatización de despliegue, un playbook de actualizaciones y un runbook documentado. Para una visión realista de costos ocultos vea Self‑Hosted Remote Desktop: Why, How, and What Breaks y nuestro análisis de costo total en Remote access TCO.

Lista de verificación de evaluación y siguientes pasos

• Ejecute una prueba de concepto que ejerza los fallback P2P y el uso de relays, capturando evidencia a nivel de paquetes y huellas digitales de certificados.
• Solicite logs redactados y un paquete de auditoría; compare formatos con su SIEM. Vea Remote Desktop Audit Logging para lo que esperan los auditores.
• Obtenga un TCO a 3 años de cada proveedor que incluya on‑call, parcheo y costos de egress de relay; compare con el pricing gestionado de Tenvo.
• Lea atestaciones de producto y, cuando proceda, solicite una bridge letter. Si necesita comparar más a fondo con proveedores establecidos, revise TeamViewer comparison, AnyDesk comparison y RustDesk comparison.
• Si necesita lenguaje para procurement, convierta las 20 preguntas anteriores en requisitos obligatorios de evidencia (diagramas, huellas de certificados, logs) y puntúe a los proveedores solo por evidencia, no por declaraciones.

¿Listo para probar un relay gestionado y un cliente nativo? Descargue un cliente y ejecute las mismas 20 comprobaciones en un piloto corto: Descargar Tenvo.