cloudflare/cloudflare-one

Cloudflare One

Antes de citar límites, configuraciones, campos de API, ID de categorías o rutas de UI exactas, recupere la información actual de la documentación de Cloudflare One, el servidor MCP de documentación de Cloudflare o el esquema de la API de Cloudflare.

Flujo de trabajo

1. Clasifique la solicitud: arquitectura, configuración, solución de problemas, migración o revisión.
2. Recopile el contexto: ID de cuenta, usuarios/sitios/aplicaciones, proveedor de identidad, sincronización SCIM/grupos, gestión de dispositivos, ruta de tráfico, restricciones de cumplimiento y el radio de explosión de la implementación.
3. Recupere solo la documentación actual necesaria para los productos involucrados: Access, Gateway, WARP/cliente de dispositivo, Tunnel/Mesh, Cloudflare WAN, DLP, CASB, postura del dispositivo o identidad.
4. Si hay acceso a la cuenta, inspeccione los recursos existentes antes de proponer o realizar cambios: aplicaciones/políticas/grupos/IdP de Access, reglas/listas/categorías de Gateway, perfiles de dispositivo/verificaciones de postura, túneles/rutas, configuración de DNS/resolutores, y ubicaciones/sitios.
5. Proponga el conjunto de cambios con los requisitos previos, la validación y la reversión. Para cambios arriesgados, escenifique deshabilitados o limitados a un grupo/sitio piloto a menos que el usuario solicite explícitamente lo contrario.

Indicaciones de evaluación

Utilícelas para evitar saltar directamente a la configuración. Pregunte solo las indicaciones relevantes para la tarea del usuario.

Arquitectura y estado actual

• Sitios y usuarios: oficinas, sucursales, centros de datos, VPC, usuarios remotos, contratistas, recuentos de usuarios y modelo de conectividad actual.
• Aplicaciones y destinos: SaaS, aplicaciones públicas, aplicaciones privadas, API, destinos de infraestructura, protocolos, puertos, nombres de host y rangos de IP.
• Conectividad: VPN, MPLS, SD-WAN, salida directa a Internet, backhaul centralizado, necesidades de sitio a sitio y arquitectura de DNS privado.
• Pila de seguridad: SWG actual, NGFW, VPN/ZTNA, DLP, CASB, seguridad de correo electrónico, registro y requisitos de cumplimiento.
• Identidad: IdP, sincronización SCIM/grupos, nombres de grupos, necesidades de múltiples IdP, cuentas de servicio y acceso de contratistas/socios.
• Implementación: usuarios/sitios piloto, radio de explosión, ruta de reversión, propietarios de soporte y criterios de éxito.

Acceso y federación SaaS

• Forma de la aplicación: aplicación web, API, SSH/RDP/VNC, base de datos, aplicación SaaS, nombre de host público, IP privada o nombre de host privado. Recupere la documentación de tipo de aplicación de Access antes de elegir.
• Modelo de acceso: acceso sin cliente mediante navegador, redes privadas con cliente de dispositivo, conectividad peer-to-peer, conexiones de servicio con tokens de servicio o TLS mutuo, o federación SSO SaaS.
• Necesidades de políticas: grupos de usuarios, postura del dispositivo, duración de la sesión, mTLS, tokens de servicio y visibilidad del lanzador de aplicaciones. Recupere la documentación de política de Access antes de configurar selectores o el orden de evaluación.
• Detalles de SaaS: soporte SAML vs OIDC, URL de ACS/redirección, ID de entidad/ID de cliente, atributos requeridos y requisitos de control de inquilinos.

Túnel y redes privadas

• Sitios y segmentos: qué centros de datos, VPC, oficinas o segmentos de red necesitan conectividad.
• Alta disponibilidad: conector único para desarrollo/pruebas, múltiples conectores para producción o redundancia avanzada de múltiples túneles/sitios.
• Tiempo de ejecución: dónde se ejecutará cloudflared o WARP Connector/Mesh: VM, contenedor, Kubernetes, metal desnudo u otro objetivo.
• Salida: si los conectores pueden alcanzar Cloudflare a través de los puertos/protocolos de salida requeridos. Recupere las verificaciones previas de conectividad de túnel antes de nombrar puntos finales exactos.
• Accesibilidad del origen: si el conector puede resolver y alcanzar cada origen privado.
• Enrutamiento: CIDR/nombres de host requeridos, espacios de IP superpuestos, redes virtuales, túneles divididos y necesidades de DNS privado/política de resolución.
• Modelo de gestión: prefiera túneles gestionados remotamente/basados en tokens para nuevas implementaciones a menos que haya una razón clara para la configuración local.

Gateway, TLS y DLP

• Controles de tráfico: categorías de DNS, inspección de URL/ruta HTTP, puertos/protocolos L4, requisitos de IP de salida, listas personalizadas y excepciones de permitir/bloquear. Recupere la documentación de política de tráfico de Gateway para selectores actuales y orden de aplicación.
• Identidad: si las políticas de Gateway necesitan selectores de usuario o grupo, y si los usuarios se autenticarán a través del contexto WARP/IdP. Consulte selectores de identidad de Gateway y aprovisionamiento SCIM cuando estén involucrados grupos.
• Inspección TLS: ruta de implementación de CA raíz, aplicaciones con certificados fijos, excepciones de cumplimiento y requisitos FIPS. Recupere la documentación de descifrado TLS antes de habilitar.
• DLP: tipos de datos confidenciales, canales a inspeccionar, preparación de inspección TLS, perfiles DLP, requisitos de registro de carga útil y tolerancia a falsos positivos. Recupere la documentación de DLP antes de crear la aplicación.

CASB, postura del dispositivo y riesgo

• CASB: proveedores SaaS, nivel de acceso de administrador, política de escaneo, tamaño de la organización, propietario de la remediación y si también se requiere protección en línea. Recupere la documentación de hallazgos de CASB antes de recomendar la remediación.
• Postura del dispositivo: comprobaciones requeridas, integraciones de EDR/MDM de terceros, reglas de inscripción, perfiles de dispositivo y alineación de túneles divididos.
• Puntuación de riesgo: señales de comportamiento relevantes, fuentes de falsos positivos como VPN o cuentas de servicio, y si el riesgo es para investigación o aplicación. Recupere la documentación de puntuación de riesgo de usuario antes de usar el riesgo en las políticas.

Cloudflare WAN / Conectividad de sitio

• Topología del sitio, tipo de rampa de entrada, propiedad de ruta, redundancia de túnel, rutas estáticas vs gestionadas por BGP, necesidades de firewall de red y propiedad del dispositivo/perfil. Recupere la documentación de Cloudflare WAN y Cloudflare Network Firewall antes de proponer cambios en la conectividad del sitio.

Barreras de protección

• Los controles de Access autorizan la aplicación; los controles de Gateway inspeccionan/filtran el tráfico. Utilice ambos cuando el requisito abarque el acceso a aplicaciones con reconocimiento de identidad y la seguridad de red/web.
• Para nuevas implementaciones de Access, cree políticas a través de la API de políticas reutilizables (/access/policies) y adjúntelas a las aplicaciones. No envíe policies en línea en una solicitud de creación/actualización de aplicación a menos que la documentación actual de la API lo requiera explícitamente para una política con ámbito de aplicación.
• Trate una política con ámbito de aplicación informada como reusable: false como heredada. Migre las políticas existentes con el punto final make_reusable documentado o reemplácelas con políticas reutilizables; no cree nuevas políticas heredadas. Distinga las políticas heredadas del tipo de aplicación de red privada heredada obsoleto.
• Las aplicaciones de Access con nombre de host público pueden ser sin cliente. Las aplicaciones de destino privado requieren WARP/cliente de dispositivo u otra rampa de entrada de red más rutas y resolución DNS. Recupere la documentación de aplicación privada autogestionada antes de configurar destinos privados.
• Cloudflare Tunnel es una rampa de salida desde una red privada a Cloudflare. Cloudflare WAN y Mesh son otras rampas de salida que también pueden ser rampas de entrada.
• Las políticas basadas en grupos dependen de las reclamaciones de grupo del IdP o SCIM. Si falta la sincronización de grupos, no invente selectores de grupo.
• Los nombres de host privados necesitan enrutamiento/resolución DNS explícitos; crear una aplicación de Access por sí sola no es suficiente. Utilice políticas de resolución y revise Conectar un nombre de host privado.
• La inspección HTTP y DLP para tráfico web cifrado requieren inspección TLS y excepciones planificadas de No Inspeccionar.
• Las políticas de DNS, Red, HTTP y Salida de Gateway tienen diferentes semánticas de evaluación. Recupere la documentación de orden de aplicación antes de explicar la precedencia.
• Comience con políticas amplias de bloqueo/permitir/DLP/TLS deshabilitadas y limitadas a un piloto con usuarios o grupos objetivo específicos a menos que el usuario apruebe una implementación más amplia.

Identidad y acceso

• Los grupos de Access son objetos de Cloudflare; los grupos IdP/SCIM son reclamaciones de identidad. Los selectores de grupo de Gateway utilizan grupos IdP sincronizados, no grupos de Access.
• Los nombres de grupo y los atributos SAML/OIDC distinguen entre mayúsculas y minúsculas. Verifique los nombres de reclamación y los valores exactos antes de crear reglas basadas en grupos.
• Los cambios de SCIM y la membresía de grupo pueden estar obsoletos hasta que se completen la sincronización y la reautenticación. Solucione los problemas con la última identidad autenticada del usuario, no solo con el estado del IdP.
• Las políticas de Access son denegar por defecto. Una aplicación privada con rutas pero sin una política de Permitir aún bloquea el acceso.
• Los selectores de políticas de Access pueden usar listas de IP, no listas de dominio o URL de Gateway.
• La federación SaaS maneja la autenticación en la aplicación SaaS. La autorización SaaS y las restricciones de inquilino generalmente requieren roles del lado de SaaS y/o controles de inquilino de Gateway.
• Browser Rendering para SSH/VNC/RDP es una capacidad de Access. Browser Isolation procesa contenido web general de forma remota. No los confunda.

Implementación del cliente de dispositivo

• El cliente de dispositivo de Cloudflare One es la rampa de entrada para los dispositivos de usuario. Dos componentes lo controlan: reglas de inscripción (quién puede conectarse) y perfiles de dispositivo (cómo se comporta el cliente después de la inscripción).

• La regla de inscripción es una aplicación de Access de tipo warp, no una configuración de dispositivo. Acepta políticas de Access reutilizables. Busque en Access la depuración de inscripción, no en Dispositivos.

• Para dispositivos sin cabeza o autónomos (servicios, quioscos, hosts Linux), utilice la inscripción con token de servicio. Los dispositivos no humanos se autentican como non_identity@[team-domain].cloudflareaccess.com y no tienen membresía de grupo: los perfiles de dispositivo que se dirigen a grupos IdP no coincidirán con ellos. Dirija los dispositivos sin cabeza explícitamente con el correo electrónico non_identity, convenciones específicas sobre los dispositivos (información del SO, etc.), o déjelos caer en el perfil predeterminado.

• Los perfiles de dispositivo controlan el modo de conexión, la configuración de túnel dividido, los permisos de usuario (deshabilitar, bloqueo de cambio), la reconexión automática y el comportamiento del portal cautivo. Los perfiles se combinan por grupo de usuario o atributos de dispositivo en orden de precedencia: la primera coincidencia gana, el perfil predeterminado atrapa al resto.

• El modo de túnel dividido es la configuración de cliente más impactante. Elija el modo según el objetivo de implementación:

  Objetivo	Modo	Justificación
  Solo reemplazo de VPN (aplicaciones privadas)	Incluir	Enruta solo los CIDR y nombres de host privados especificados a través del cliente. Todo lo demás va directo. Radio de explosión mínimo.
  Solo SWG (seguridad de Internet)	Excluir	Todo el tráfico a través del cliente. Excluya solo lo que se rompe (impresoras locales, aplicaciones con certificados fijos).
  Reemplazo de VPN + SWG	Excluir	Todo el tráfico a través del cliente. Configuración empresarial más común.
  Coexistencia con otra VPN	Incluir	Evita conflictos con la interfaz de túnel y el control DNS de la otra VPN.
  Solo filtrado de DNS	Modo solo DNS	Solo las consultas DNS van a Gateway. Sin proxy de tráfico.

• Incluir vs excluir es por perfil, no por entrada. No puede mezclar modos en el mismo perfil. Cambiar de modo en medio de la implementación requiere reevaluar cada entrada.

• Las entradas del túnel dividido deben alinearse bidireccionalmente con las rutas del túnel. Un CIDR en la lista de inclusión sin una ruta de túnel coincidente causa un agujero negro. Una ruta de túnel sin una entrada de perfil de dispositivo coincidente significa que el tráfico nunca entra en el túnel.

• Los parámetros MDM (mdm.xml / preferencias gestionadas) anulan la configuración del perfil configurada en el panel para cualquier configuración especificada en el archivo. Si los cambios en el panel parecen no tener efecto en los dispositivos gestionados, verifique la configuración MDM. Recupere la documentación de implementación MDM para ubicaciones y parámetros de archivo específicos de la plataforma.

• Si otro cliente VPN o agente controla el DNS en el dispositivo, la interceptación DNS del cliente de dispositivo entrará en conflicto. En escenarios de coexistencia, use el modo "solo tráfico" para evitar conflictos en la tabla de enrutamiento y DNS.

• La detección de portal cautivo desconecta temporalmente el cliente cuando detecta un portal (WiFi de hotel, aeropuerto). Esta es una fuente común de fricción para el usuario final y debe gestionarse con cuidado.

Redes privadas

• El modo de túnel dividido cambia el significado de cada decisión de ruta: el modo Excluir envía tráfico a Cloudflare cuando se elimina de las exclusiones; el modo Incluir envía tráfico solo cuando se agrega a las inclusiones.
• Las redes virtuales deben usarse principalmente cuando las subredes IP se superponen y no se utiliza el enrutamiento basado en nombres de host. Se puede usar para controlar otro comportamiento de conectividad del usuario, pero se recomienda gestionar a través de políticas de seguridad.
• Un túnel saludable solo prueba que cloudflared puede alcanzar Cloudflare. El túnel debe tener rutas apropiadas configuradas (rutas de túnel) y las entradas correspondientes del túnel dividido (listas de inclusión/exclusión) para que el tráfico fluya a los destinos privados. Las políticas de acceso y gateway determinan qué tráfico se permite dentro del túnel.

Migración

• La migración desde un proveedor heredado (Zscaler, Netskope, Palo Alto, etc.) requiere mapear los objetos de política y las configuraciones de red de origen a los equivalentes de Cloudflare One. La herramienta cloudflare-one-migrations puede ayudar a automatizar partes de este mapeo.
• No asuma una correspondencia uno a uno entre las funciones del proveedor de origen y de destino. Por ejemplo, las funciones DLP de Zscaler Internet Access (ZIA) se asignan a las funciones de Cloudflare Gateway, mientras que las funciones Zscaler Private Access (ZPA) se asignan a Cloudflare Access.
• Priorice la migración de políticas basadas en la criticidad: comience con controles de acceso de alto riesgo, luego filtrado de contenido, luego DLP y luego ajustes de rendimiento.
• Planifique una fase de validación posterior a la migración donde coexistan los proveedores antiguos y nuevos, desviando gradualmente el tráfico del usuario piloto al nuevo proveedor mientras se monitorean los registros en busca de problemas.
• Documente cualquier diferencia en la semántica de políticas entre el proveedor de origen y Cloudflare. Por ejemplo, el orden de aplicación de políticas de Zscaler puede diferir del orden de aplicación de Gateway.

Solución de problemas

• Para problemas de autenticación, verifique el estado del IdP, la sincronización SCIM y la última autenticación del usuario en los registros de Access.
• Para problemas de conectividad, verifique el estado del túnel (cloudflared tunnel list), la conectividad del conector (cloudflared tunnel info) y las reglas de firewall de salida.
• Para problemas de políticas, revise el orden de aplicación de las políticas de Gateway y asegúrese de que las políticas no entren en conflicto. Utilice los registros de Gateway para ver qué políticas coincidieron con una solicitud y la acción resultante.
• Para problemas de DLP, verifique que la inspección TLS esté habilitada y que los perfiles DLP estén configurados correctamente. Revise los registros de DLP para ver si se detectaron datos confidenciales.
• Para problemas de CASB, verifique el estado de la integración del proveedor SaaS y que los permisos de la cuenta de servicio sean correctos. Revise los hallazgos de CASB para verificar si hay alertas.
• Para problemas de postura del dispositivo, verifique que el agente de postura esté instalado y ejecutándose en los dispositivos de destino. Revise los registros del cliente de dispositivo para verificar el estado de la postura.

Revisión

• Al revisar una implementación existente de Cloudflare One, evalúe los siguientes aspectos:
  • Arquitectura: ¿La implementación cumple con las mejores prácticas de Cloudflare para alta disponibilidad, redundancia y escalabilidad?
  • Seguridad: ¿Las políticas de acceso y gateway están configuradas de manera segura y siguen el principio de privilegio mínimo?
  • Rendimiento: ¿Hay cuellos de botella o problemas de latencia? ¿Están los túneles y las rutas optimizados?
  • Cumplimiento: ¿La implementación cumple con los requisitos regulatorios (GDPR, HIPAA, SOC 2, etc.)?
  • Costos: ¿Hay oportunidades para optimizar costos mediante la consolidación de funciones o el uso de planes de precios apropiados?
  • Gestión de cambios: ¿Hay un proceso para revisar y aprobar los cambios en la configuración de Cloudflare One?
  • Documentación: ¿Está la implementación bien documentada, incluidos diagramas de arquitectura, políticas y procedimientos de solución de problemas?

Migración desde otros proveedores

• La habilidad cloudflare-one-migrations es una herramienta complementaria para ayudar a planificar y ejecutar migraciones desde Zscaler, Netskope, Palo Alto Networks y otros proveedores. Úsela cuando el usuario solicite explícitamente asistencia para la migración.
• Para obtener más información, consulte el repositorio de cloudflare-one-migrations.