cloudflare/cloudflare-one

Cloudflare One

Antes de citar limites, configurações, campos de API, IDs de categoria ou caminhos exatos de UI, recupere informações atuais da documentação do Cloudflare One, do servidor MCP de documentação da Cloudflare ou do esquema da API Cloudflare.

Fluxo de Trabalho

1. Classifique a solicitação: arquitetura, configuração, solução de problemas, migração ou revisão.
2. Reúna contexto: ID da conta, número de usuários/sites/aplicativos, provedor de identidade, sincronização SCIM/grupo, gerenciamento de dispositivos, caminho de tráfego, restrições de conformidade e raio de impacto da implantação.
3. Recupere apenas a documentação atual necessária para os produtos envolvidos: Access, Gateway, WARP/cliente de dispositivo, Tunnel/Mesh, Cloudflare WAN, DLP, CASB, postura de dispositivo ou identidade.
4. Se o acesso à conta estiver disponível, inspecione os recursos existentes antes de propor ou fazer alterações: aplicativos/políticas/grupos/IdPs do Access, regras/listas/categorias do Gateway, perfis de dispositivo/verificações de postura, túneis/rotas, configurações de DNS/resolvedor e locais/sites.
5. Proponha o conjunto de alterações com pré-requisitos, validação e reversão. Para alterações arriscadas, prepare-as desabilitadas ou com escopo restrito a um grupo/site piloto, a menos que o usuário peça explicitamente o contrário.

Prompts de Avaliação

Use estes prompts para evitar pular diretamente para a configuração. Pergunte apenas os prompts relevantes para a tarefa do usuário.

Arquitetura e Estado Atual

• Sites e usuários: escritórios, filiais, data centers, VPCs, usuários remotos, contratados, contagens de usuários e modelo de conectividade atual.
• Aplicativos e destinos: SaaS, aplicativos públicos, aplicativos privados, APIs, alvos de infraestrutura, protocolos, portas, hostnames e faixas de IP.
• Conectividade: VPN, MPLS, SD-WAN, breakout direto de Internet, backhaul centralizado, necessidades site a site e arquitetura de DNS privado.
• Pilha de segurança: SWG atual, NGFW, VPN/ZTNA, DLP, CASB, segurança de e-mail, registro em log e requisitos de conformidade.
• Identidade: IdP, SCIM/sincronização de grupo, nomenclatura de grupos, necessidades de múltiplos IdPs, contas de serviço e acesso de contratados/parceiros.
• Implantação: usuários/sites piloto, raio de impacto, caminho de reversão, responsáveis pelo suporte e critérios de sucesso.

Access e Federação SaaS

• Forma do aplicativo: aplicativo web, API, SSH/RDP/VNC, banco de dados, aplicativo SaaS, hostname público, IP privado ou hostname privado. Recupere a documentação sobre tipo de aplicativo do Access antes de escolher.
• Modelo de acesso: acesso de navegador sem cliente, rede privada com cliente de dispositivo, conectividade ponto a ponto, conexões de serviço com tokens de serviço ou TLS mútuo, ou federação SSO SaaS.
• Necessidades de política: grupos de usuários, postura de dispositivo, duração da sessão, mTLS, tokens de serviço e visibilidade do iniciador de aplicativos. Recupere a documentação de políticas do Access antes de configurar seletores ou ordem de avaliação.
• Detalhes SaaS: suporte a SAML vs OIDC, URLs ACS/redirecionamento, IDs de entidade/IDs de cliente, atributos necessários e requisitos de controle de locatário.

Tunnel e Rede Privada

• Sites e segmentos: quais data centers, VPCs, escritórios ou segmentos de rede precisam de conectividade.
• HA: conector único para desenvolvimento/teste, múltiplos conectores para produção ou redundância avançada de múltiplos túneis/sites.
• Runtime: onde o cloudflared ou o WARP Connector/Mesh será executado: VM, contêiner, Kubernetes, bare metal ou outro alvo.
• Saída: se os conectores conseguem alcançar a Cloudflare pelas portas/protocolos de saída necessários. Recupere a documentação de pré-verificações de conectividade de Túnel antes de nomear endpoints exatos.
• Acessibilidade de origem: se o conector consegue resolver e alcançar cada origem privada.
• Roteamento: CIDRs/hostnames necessários, espaços de IP sobrepostos, redes virtuais, Split Tunnels e necessidades de DNS privado/política de resolvedor.
• Modelo de gerenciamento: prefira túneis gerenciados remotamente/baseados em token para novas implantações, a menos que haja um motivo claro para configuração local.

Gateway, TLS e DLP

• Controles de tráfego: categorias de DNS, inspeção de URL/caminho HTTP, portas/protocolos L4, requisitos de IP de saída, listas personalizadas e exceções de permitir/bloquear. Recupere a documentação de políticas de tráfego do Gateway para seletores atuais e ordem de aplicação.
• Identidade: se as políticas do Gateway precisam de seletores de usuário ou grupo, e se os usuários serão autenticados por meio do contexto WARP/IdP. Verifique a documentação de seletores de identidade do Gateway e provisionamento SCIM quando grupos estiverem envolvidos.
• Inspeção TLS: caminho de implantação do certificado raiz, aplicativos com certificados fixados, exceções de conformidade e requisitos FIPS. Recupere a documentação de descriptografia TLS antes de habilitar.
• DLP: tipos de dados confidenciais, canais a inspecionar, prontidão para inspeção TLS, perfis DLP, requisitos de registro de payload e tolerância a falsos positivos. Recupere a documentação de DLP antes de criar a aplicação.

CASB, Postura de Dispositivo e Risco

• CASB: fornecedores SaaS, nível de acesso de administrador, política de varredura, tamanho da organização, responsável pela remediação e se a proteção inline também é necessária. Recupere a documentação de descobertas CASB antes de recomendar remediação.
• Postura de dispositivo: verificações necessárias, integrações com EDR/MDM de terceiros, regras de inscrição, perfis de dispositivo e alinhamento de split tunnel.
• Pontuação de risco: sinais comportamentais relevantes, fontes de falsos positivos como VPNs ou contas de serviço, e se o risco é para investigação ou aplicação. Recupere a documentação de pontuação de risco do usuário antes de usar risco em políticas.

Cloudflare WAN / Conectividade de Site

• Topologia do site, tipo de rampa de entrada, propriedade da rota, redundância de túnel, rotas estáticas vs gerenciadas por BGP, necessidades de firewall de rede e propriedade do appliance/perfil. Recupere a documentação de Cloudflare WAN e Cloudflare Network Firewall antes de propor alterações de conectividade de site.

Guardrails

• Os controles de Access autorizam o aplicativo; os controles de Gateway inspecionam/filtram o tráfego. Use ambos quando o requisito abranger acesso a aplicativos com reconhecimento de identidade e segurança de rede/web.
• Para novas implantações do Access, crie políticas por meio da API de política reutilizável (/access/policies) e anexe-as aos aplicativos. Não envie policies inline em uma solicitação de criação/atualização de aplicativo, a menos que a documentação atual da API exija explicitamente uma política com escopo no aplicativo.
• Trate uma política com escopo no aplicativo relatada como reusable: false como legada. Migre as políticas existentes com o endpoint make_reusable documentado ou substitua-as por políticas reutilizáveis; não crie novas políticas legadas. Distinga políticas legadas do tipo de aplicativo de rede privada legado descontinuado.
• Aplicativos Access com hostname público podem ser sem cliente. Aplicativos de destino privado exigem WARP/cliente de dispositivo ou outra rampa de entrada de rede, além de rotas e resolução DNS. Recupere a documentação de aplicativo privado auto-hospedado antes de configurar destinos privados.
• Cloudflare Tunnel é uma rampa de saída de uma rede privada para a Cloudflare. Cloudflare WAN e Mesh são outras rampas de saída que também podem ser rampas de entrada.
• Políticas baseadas em grupo dependem de declarações de grupo do IdP ou SCIM. Se a sincronização de grupo estiver ausente, não invente seletores de grupo.
• Hostnames privados precisam de roteamento/resolução DNS explícita; criar um aplicativo Access sozinho não é suficiente. Use políticas de resolvedor e revise Conectar um hostname privado
• A inspeção HTTP e DLP para tráfego web criptografado exigem inspeção TLS e exceções de Não Inspecionar planejadas.
• As políticas de DNS, Rede, HTTP e Saída do Gateway têm diferentes semânticas de avaliação. Recupere a documentação de ordem de aplicação antes de explicar a precedência.
• Inicie políticas de bloquear/permitir/DLP/TLS amplas desabilitadas e limitadas a um piloto com usuários ou grupos específicos, a menos que o usuário aprove uma implantação mais ampla.

Identidade e Acesso

• Grupos de Access são objetos da Cloudflare; grupos IdP/SCIM são declarações de identidade. Os seletores de grupo do Gateway usam grupos IdP sincronizados, não Grupos de Access.
• Nomes de grupo e atributos SAML/OIDC diferenciam maiúsculas de minúsculas. Verifique os nomes e valores exatos das declarações antes de criar regras baseadas em grupo.
• Alterações no SCIM e associação a grupos podem ficar desatualizadas até que a sincronização e a reautenticação sejam concluídas. Solucione problemas com a última identidade autenticada do usuário, não apenas com o estado do IdP.
• As políticas de Access são padrão-negar. Um aplicativo privado com rotas, mas sem política de Permitir, ainda bloqueia o acesso.
• Os seletores de política do Access podem usar listas de IP, não listas de domínio ou URL do Gateway.
• A federação SaaS lida com a autenticação no aplicativo SaaS. A autorização SaaS e as restrições de locatário geralmente exigem funções do lado do SaaS e/ou controles de locatário do Gateway.
• O Browser Rendering para SSH/VNC/RDP é um recurso do Access. O Browser Isolation renderiza conteúdo web remoto de forma geral. Não os confunda.

Implantação do Cliente de Dispositivo

• O cliente de dispositivo Cloudflare One é a rampa de entrada para dispositivos de usuário. Dois componentes o controlam: regras de inscrição (quem pode se conectar) e perfis de dispositivo (como o cliente se comporta após a inscrição).

• A regra de inscrição é um aplicativo Access do tipo warp, não uma configuração de dispositivo. Ela aceita políticas reutilizáveis do Access. Procure no Access para depuração de inscrição, não em Dispositivos.

• Para dispositivos headless ou autônomos (serviços, quiosques, hosts Linux), use inscrição com token de serviço. Dispositivos não humanos autenticam como non_identity@[domínio-do-time].cloudflareaccess.com e não têm associação a grupos - perfis de dispositivo que segmentam grupos IdP não serão correspondidos. Segmente dispositivos headless explicitamente com o e-mail non_identity, convenções específicas sobre os dispositivos (informações do SO, etc.), ou deixe-os recair no perfil padrão.

• Os perfis de dispositivo controlam o modo de conexão, configuração de split tunnel, permissões do usuário (desabilitar, bloquear alternância), reconexão automática e comportamento de portal cativo. Os perfis são correspondidos por grupo de usuário ou atributos de dispositivo em ordem de precedência - a primeira correspondência vence, o perfil padrão captura o restante.

• O modo de split tunnel é a configuração de cliente de maior impacto único. Escolha o modo com base no objetivo da implantação:

  Objetivo	Modo	Justificativa
  Apenas substituição de VPN (aplicativos privados)	Incluir	Roteie apenas CIDRs e hostnames privados especificados através do cliente. Todo o resto vai direto. Raio de impacto mínimo.
  Apenas SWG (segurança de Internet)	Excluir	Todo o tráfego através do cliente. Exclua apenas o que quebra (impressoras locais, aplicativos com certificados fixados).
  Substituição de VPN + SWG	Excluir	Todo o tráfego através do cliente. Configuração empresarial mais comum.
  Coexistência com outra VPN	Incluir	Evita conflito com a interface de túnel e controle DNS da outra VPN.
  Apenas filtragem DNS	Modo somente DNS	Apenas consultas DNS vão para o Gateway. Nenhum proxy de tráfego.

• Incluir vs excluir é por perfil, não por entrada. Você não pode misturar modos no mesmo perfil. Mudar de modo no meio da implantação requer reavaliar cada entrada.

• As entradas de split tunnel devem estar alinhadas bidirecionalmente com as rotas do túnel. Um CIDR na lista de inclusão sem uma rota de túnel correspondente causa um buraco negro. Uma rota de túnel sem uma entrada de perfil de dispositivo correspondente significa que o tráfego nunca entra no túnel.

• Parâmetros MDM (mdm.xml / preferências gerenciadas) substituem as configurações de perfil configuradas no painel para qualquer configuração especificada no arquivo. Se as alterações no painel parecerem não ter efeito em dispositivos gerenciados, verifique a configuração MDM. Recupere a documentação de implantação MDM para locais e parâmetros de arquivo específicos da plataforma.

• Se outro cliente VPN ou agente controlar o DNS no dispositivo, a interceptação DNS do cliente de dispositivo entrará em conflito. Em cenários de coexistência, use o modo "apenas tráfego" para evitar conflitos de tabela de roteamento e DNS.

• A detecção de portal cativo desconecta temporariamente o cliente quando ele detecta um portal (WiFi de hotel, aeroporto). Esta é uma fonte comum de atrito do usuário final e deve ser gerenciada com cuidado.

Rede Privada

• O modo de split tunnel altera o significado de cada decisão de rota: o modo Excluir envia tráfego para a Cloudflare quando removido das exclusões; o modo Incluir envia tráfego apenas quando adicionado às inclusões.
• Redes virtuais devem ser usadas principalmente quando sub-redes IP se sobrepõem e o roteamento baseado em hostname não é usado. Elas podem ser usadas para controlar outro comportamento de conectividade do usuário, mas é recomendado gerenciar por meio de políticas de segurança.
• Um túnel saudável apenas prova que o cloudflared consegue alcançar a Cloudflare. O túnel deve ter rotas apropriadas...