Como funciona um ambiente híbrido com Azure?

Um ambiente híbrido com Azure combina recursos em nuvem pública da Microsoft com infraestrutura local (on-premises), permitindo que as empresas aproveitem o melhor dos dois mundos. Essa abordagem oferece flexibilidade para manter aplicações críticas no datacenter próprio enquanto migra gradualmente workloads para a nuvem, sem interrupções operacionais ou investimentos massivos em infraestrutura.

Na prática, o Azure funciona como uma extensão segura do seu ambiente interno através de conexões dedicadas e sincronização de dados em tempo real. Você consegue gerenciar máquinas virtuais, bancos de dados e serviços tanto localmente quanto na nuvem a partir de um único painel, mantendo consistência de políticas de segurança e conformidade regulatória. Isso é especialmente importante para empresas que precisam cumprir exigências como LGPD ou que trabalham com dados sensíveis.

A configuração híbrida também é estratégica para otimizar custos: você dimensiona a infraestrutura conforme a demanda, evitando gastos desnecessários com servidores subutilizados. Essa flexibilidade torna a transformação digital menos disruptiva e mais alinhada com a realidade de cada negócio.

O que é um ambiente híbrido com Azure e por que ele importa?

A maioria das empresas não migra para a nuvem do dia para a noite. Sistemas legados, contratos de datacenter vigentes, requisitos regulatórios e workloads altamente sensíveis criam barreiras reais para uma transição 100% cloud. É exatamente nesse cenário que o modelo híbrido com Azure se torna não apenas viável, mas estrategicamente superior às alternativas de tudo ou nada. Compreender como esse modelo opera é o ponto de partida para extrair o melhor dos dois mundos sem abrir mão de controle, segurança ou desempenho.

Definição de nuvem híbrida: combinando infraestrutura local e Azure

Um ambiente híbrido com Azure é uma arquitetura de TI que integra, de forma coesa e gerenciada, recursos de infraestrutura local — servidores físicos, switches, storage, VMs em Hyper-V ou VMware — com serviços hospedados na nuvem pública da Microsoft. Essa integração vai além de uma simples conexão de rede entre dois pontos: ela pressupõe identidade unificada, políticas de segurança consistentes, gerenciamento centralizado e fluxos de dados bidirecionais com baixa latência e alta confiabilidade.

O termo “híbrido” carrega peso técnico real. Não basta ter um servidor local e uma conta no Azure para caracterizar um ambiente híbrido maduro. É necessário que os dois ambientes compartilhem plano de controle, autenticação e visibilidade operacional. Ferramentas como o Azure Arc, o Microsoft Entra Connect e o Azure Monitor são os pilares que tornam essa coexistência gerenciável em escala.

Diferenças entre nuvem pública, privada e híbrida no contexto Azure

Na nuvem pública, todos os recursos — VMs, bancos de dados, redes virtuais — são provisionados e operados pela Microsoft em seus datacenters globais. O cliente paga pelo consumo e não gerencia hardware físico. Para saber mais sobre o que essa plataforma oferece, consulte o que é o Microsoft Azure e para que serve.

Na nuvem privada, a infraestrutura é dedicada a uma única organização, seja em datacenter próprio ou colocado. Tecnologias como Azure Stack HCI permitem executar serviços Azure em hardware local, mantendo isolamento total do ambiente.

A nuvem híbrida combina os dois modelos com integração real de plano de controle. No contexto Azure, isso significa que recursos on-premises podem ser administrados via portal Azure, submetidos às mesmas políticas aplicadas a VMs na nuvem e autenticados pela mesma identidade corporativa. A diferença crítica em relação a uma simples coexistência é a orquestração unificada: o Azure enxerga os servidores locais como extensões do seu próprio fabric, não como entidades externas desconhecidas.

Como funciona a arquitetura de um ambiente híbrido com Azure

A arquitetura híbrida com Azure não segue um template único. Ela varia conforme o tamanho da organização, o número de sites físicos, os requisitos de latência e os workloads envolvidos. Ainda assim, existe um conjunto de camadas e componentes que aparece em praticamente toda implementação madura desse modelo.

Componentes essenciais: on-premises, Azure e camada de integração

A camada on-premises engloba servidores físicos ou virtualizados (Hyper-V, VMware), controladores de domínio Active Directory, file servers, bancos de dados locais e dispositivos de rede como firewalls e switches gerenciados. Essa camada continua existindo e sustentando workloads que, por razões de latência, compliance ou custo, não devem ou não podem ser migrados imediatamente.

A camada Azure abrange Virtual Networks (VNets), VMs, serviços PaaS como Azure SQL Managed Instance, Azure Files e Azure Kubernetes Service, além dos serviços de gerenciamento como Azure Monitor, Microsoft Defender for Cloud e Azure Automation.

A camada de integração é o que distingue um ambiente híbrido de dois ambientes isolados. Ela é composta por:

• Conectividade de rede: VPN Gateway ou ExpressRoute para comunicação segura entre redes locais e VNets Azure.
• Identidade unificada: Microsoft Entra Connect sincronizando o Active Directory local com o Microsoft Entra ID (antigo Azure AD).
• Gerenciamento centralizado: Azure Arc projetando servidores e clusters locais como recursos administráveis dentro do portal Azure.
• Automação: Azure Automation com Hybrid Runbook Workers executando tarefas em máquinas locais a partir da nuvem.
• Monitoramento unificado: Azure Monitor e Log Analytics coletando métricas e logs de ambos os ambientes em um único workspace.

Fluxo de dados e comunicação entre ambiente local e Azure

O tráfego entre o datacenter local e o Azure percorre o túnel de conectividade estabelecido (VPN ou ExpressRoute). Dentro desse túnel, os dados são roteados conforme tabelas configuradas nas VNets e nos dispositivos de rede locais. O DNS desempenha papel crítico nesse fluxo: a resolução de nomes de recursos Azure a partir do ambiente local — e vice-versa — exige configuração cuidadosa de zonas DNS privadas e forwarders condicionais.

Aplicações locais que precisam consumir APIs ou serviços PaaS no Azure fazem isso via endpoints privados, que projetam o serviço Azure dentro da VNet com um IP privado, eliminando a dependência de tráfego pela internet pública. Dados de telemetria, logs e métricas de servidores on-premises são transmitidos ao Azure Monitor via agente Azure Monitor Agent (AMA), instalado localmente e configurado para enviar informações ao workspace Log Analytics na nuvem.

Conectividade de rede híbrida no Azure: VPN Gateway e ExpressRoute

A conectividade de rede é a espinha dorsal de qualquer ambiente híbrido. Sem ela, não há integração real — apenas dois ambientes paralelos. O Azure oferece duas tecnologias principais para estabelecer essa ponte: o VPN Gateway e o ExpressRoute. A escolha entre elas depende de requisitos de largura de banda, latência, custo e criticidade dos workloads.

Azure VPN Gateway: quando usar e como configurar

O Azure VPN Gateway estabelece conexões IPsec/IKE entre a rede local e a VNet Azure através da internet pública, com criptografia ponta a ponta. É a alternativa mais acessível e de implantação mais rápida, indicada para organizações com requisitos de largura de banda moderados (até alguns Gbps dependendo do SKU) e tolerância a variações de latência.

Para configurar, os passos fundamentais são:

1. Criar uma Gateway Subnet dedicada na VNet Azure (recomendado /27 ou maior).
2. Provisionar o recurso Virtual Network Gateway com tipo VPN e SKU adequado ao throughput necessário (Basic, VpnGw1 até VpnGw5).
3. Criar um Local Network Gateway representando o dispositivo VPN local, com o IP público do firewall/roteador e os prefixos de endereço da rede on-premises.
4. Estabelecer a Connection entre o VPN Gateway e o Local Network Gateway, definindo a chave compartilhada (PSK) e o protocolo IKE.
5. Configurar o dispositivo VPN local (Cisco, Fortinet, pfSense, Windows RRAS) com os parâmetros correspondentes.

Para alta disponibilidade, o VPN Gateway suporta configuração active-active com dois túneis simultâneos. Para múltiplos sites, o recurso VPN Gateway Transit via Virtual WAN simplifica o gerenciamento em escala.

ExpressRoute: conexão privada dedicada entre datacenter e Azure

O ExpressRoute é uma conexão privada e dedicada entre o datacenter corporativo e a infraestrutura Azure, estabelecida via um provedor de conectividade parceiro da Microsoft — operadoras de telecomunicações ou provedores de colocation. O tráfego não passa pela internet pública em nenhum momento, o que garante latência previsível, SLA de disponibilidade de 99,95% e largura de banda de até 100 Gbps.

É a escolha obrigatória para workloads que exigem transferência massiva de dados (backup, replicação de bancos de dados de grande porte), aplicações financeiras com requisitos rígidos de latência ou ambientes regulados onde o tráfego pela internet pública é vedado por política de segurança. O custo é significativamente superior ao do VPN Gateway, mas para cenários críticos o investimento se justifica pelo SLA e pela previsibilidade de desempenho.

O ExpressRoute suporta dois modelos de peering: Microsoft Peering (para serviços públicos Azure como Office 365 e Dynamics) e Private Peering (para recursos dentro de VNets). Em ambientes híbridos maduros, é comum utilizar ambos simultaneamente.

Roteamento e DNS em ambientes híbridos com Windows Server

O roteamento híbrido exige que as tabelas em ambos os lados — Azure e on-premises — conheçam os prefixos de endereço do outro ambiente. No Azure, as User Defined Routes (UDR) permitem direcionar tráfego específico através de appliances de rede virtual (NVAs) ou do VPN Gateway. No lado local, o roteador de borda precisa ter rotas estáticas ou dinâmicas (BGP) apontando os prefixos Azure para o gateway VPN.

O DNS em ambientes híbridos é frequentemente subestimado e origina a maioria dos problemas de conectividade. A arquitetura recomendada pela Microsoft envolve:

• Servidores DNS locais — geralmente os próprios controladores de domínio Windows Server — configurados com forwarders condicionais para zonas DNS privadas do Azure (ex.: privatelink.blob.core.windows.net).
• Zonas DNS Privadas do Azure vinculadas às VNets, com auto-registration habilitada para VMs Azure.
• Uso do serviço Azure DNS Private Resolver como ponto central de resolução bidirecional, eliminando a necessidade de VMs DNS dedicadas no Azure.

Identidade híbrida com Microsoft Entra (Azure AD): Hybrid Join

Identidade é o novo perímetro de segurança. Em ambientes híbridos, garantir que usuários e dispositivos sejam autenticados de forma consistente — independentemente de estarem na rede local ou acessando recursos na nuvem — é fundamental. O Microsoft Entra ID (anteriormente Azure Active Directory) é o serviço de identidade que une esses dois mundos. Para entender mais sobre essa plataforma, veja o que é Azure Active Directory e para que serve.

O que é o Hybrid Azure AD Join e como ele funciona

O Hybrid Azure AD Join é o processo pelo qual dispositivos Windows já membros de um domínio Active Directory local passam a ser registrados também no Microsoft Entra ID. O resultado é um dispositivo com dupla identidade: reconhecido tanto pelo AD local quanto pelo Entra ID na nuvem.

Na prática, o processo ocorre da seguinte forma: o dispositivo ingressado no domínio local executa uma tarefa agendada que detecta a configuração de Hybrid Join, gera um certificado de dispositivo e o registra no Microsoft Entra ID via o serviço de registro de dispositivos (DRS). Após o registro, o dispositivo recebe um Primary Refresh Token (PRT), que permite ao usuário autenticar-se em aplicações Azure AD sem inserir credenciais repetidamente — o chamado Single Sign-On (SSO) sem fricção.

Isso habilita cenários críticos como acesso condicional baseado em conformidade do dispositivo, autenticação moderna em aplicativos Microsoft 365 e integração com o Microsoft Intune para gerenciamento de endpoint.

Passo a passo para configurar o ingresso híbrido no Microsoft Entra

A configuração do Hybrid Azure AD Join envolve os seguintes passos principais:

1. Instalar e configurar o Microsoft Entra Connect no servidor local, habilitando a sincronização de diretório entre o AD DS e o Microsoft Entra ID. A conta de serviço precisa de permissões adequadas em ambos os diretórios.
2. Habilitar o Hybrid Azure AD Join no assistente do Entra Connect, selecionando as florestas e domínios AD que participarão do processo. O assistente cria automaticamente os objetos de Service Connection Point (SCP) no AD local.
3. Verificar o SCP: o Service Connection Point é um objeto no AD que informa aos dispositivos qual tenant Azure AD devem usar para registro. Pode ser configurado via Entra Connect ou manualmente via PowerShell.
4. Configurar a política de registro via Group Policy Object (GPO) ou MDM, habilitando o registro automático de dispositivos Windows 10/11 e Windows Server no Entra ID.
5. Validar o ingresso nos dispositivos usando o comando dsregcmd /status, verificando os campos AzureAdJoined e DomainJoined como YES.

Armazenamento híbrido: compartilhamentos de arquivos do Azure em ambientes mistos

File servers locais estão entre os workloads mais comuns em ambientes corporativos e, frequentemente, entre os mais problemáticos: hardware envelhecendo, capacidade limitada, backup complexo e acesso remoto precário. O Azure oferece soluções nativas para modernizar esse cenário sem impor uma ruptura imediata com a infraestrutura existente.

Azure Files como substituto ou extensão de file servers locais

O Azure Files é um serviço de compartilhamento de arquivos totalmente gerenciado na nuvem, acessível via protocolo SMB (2.1, 3.0 e 3.1.1) e NFS 4.1. Pode ser montado diretamente em máquinas Windows, Linux e macOS — tanto em VMs Azure quanto em servidores on-premises — da mesma forma que um compartilhamento de rede tradicional.

Para ambientes híbridos, o Azure Files oferece vantagens concretas:

• Eliminação de hardware: sem servidor físico para manter, atualizar ou substituir.
• Escalabilidade automática: compartilhamentos Premium (SSD) chegam a 100 TiB por share; compartilhamentos Standard (HDD) suportam até 100 TiB com capacidade provisionada flexível.
• Autenticação integrada: suporte a autenticação Kerberos via Active Directory local (AD DS Kerberos Authentication) ou Microsoft Entra Kerberos, preservando as permissões NTFS existentes.
• Snapshots e backup: integração nativa com Azure Backup para proteção de dados sem agentes adicionais.

Azure File Sync: sincronização entre servidores on-premises e nuvem

O Azure File Sync é o serviço que permite transformar um servidor Windows local em um cache de alto desempenho para um compartilhamento Azure Files. O agente instalado no servidor sincroniza os arquivos com a nuvem e, opcionalmente, habilita o Cloud Tiering: arquivos acessados com menos frequência são automaticamente movidos para o Azure, mantendo apenas um stub local que ocupa poucos kilobytes. Quando o usuário acessa o arquivo, o download ocorre de forma transparente em segundos.

Esse modelo é especialmente valioso em cenários de migração gradual: o servidor local continua operando normalmente para os usuários, enquanto o Azure Files passa a ser a fonte de verdade dos dados. Múltiplos servidores em sites distintos podem sincronizar com o mesmo compartilhamento Azure Files, substituindo soluções complexas de DFS-R por uma topologia hub-and-spoke gerenciada na nuvem.

Automação e gerenciamento híbrido com Azure Automation e Hybrid Runbook Worker

Administrar infraestrutura híbrida manualmente é inviável em escala. Cada servidor local que precisa de patch, cada script de manutenção agendado, cada processo de onboarding de VM — tudo isso precisa ser automatizado de forma consistente entre nuvem e on-premises. O Azure Automation com Hybrid Runbook Workers é a resposta da Microsoft para esse desafio.

O que é o Hybrid Runbook Worker e como ele estende a automação ao ambiente local

O Hybrid Runbook Worker é um agente instalado em servidores locais (físicos ou virtuais) que permite ao Azure Automation executar runbooks PowerShell e Python diretamente nessas máquinas, sem que o tráfego de execução precise transitar pela internet. O servidor local estabelece uma conexão de saída com o serviço Azure Automation (via HTTPS na porta 443), recebe os jobs agendados, executa-os localmente e reporta os resultados de volta ao workspace de automação na nuvem.

Essa arquitetura resolve um problema fundamental: runbooks que precisam interagir com recursos existentes apenas na rede local — bancos de dados internos, APIs de sistemas legados, Active Directory, storage local — não conseguem ser executados nos Runbook Workers gerenciados pelo Azure, que operam em sandbox isolado na nuvem. O Hybrid Worker elimina essa barreira ao trazer a capacidade de execução para dentro do perímetro local.

Casos de uso: executar runbooks em máquinas físicas e VMs on-premises

Os cenários mais frequentes do Hybrid Runbook Worker em ambientes corporativos incluem:

• Gerenciamento de patches: o Azure Update Manager usa Hybrid Workers para orquestrar a instalação de atualizações em servidores Windows e Linux on-premises, com janelas de manutenção configuráveis e relatórios centralizados no portal Azure.
• Inventário e conformidade: runbooks que coletam configurações de servidores locais e as enviam ao Log Analytics, alimentando dashboards de conformidade.
• Automação de Active Directory: scripts de criação e desativação de contas, gerenciamento de grupos e auditoria de permissões executados diretamente nos controladores de domínio.
• Backup e manutenção de bancos de dados: scripts de backup, verificação de integridade e rotação de logs em instâncias SQL Server locais.
• Integração com sistemas legados: automações que consomem APIs REST de ERPs ou CRMs hospedados internamente, sem exposição à internet.

Governança e conformidade em ambientes híbridos com Azure Policy

Um dos maiores desafios em ambientes híbridos é manter consistência de configuração e conformidade entre recursos distribuídos em locais distintos. Uma VM no Azure e um servidor físico no datacenter local podem executar cargas similares, mas sem uma camada de governança unificada, cada um acaba sendo administrado de forma diferente, criando lacunas de segurança e compliance. O Azure Arc e o Azure Policy endereçam esse problema de forma elegante.

Azure Arc: gerenciando servidores fora do Azure como recursos nativos

O Azure Arc é o serviço que projeta servidores on-premises, VMs em outros clouds e clusters Kubernetes como recursos de primeira classe no Azure Resource Manager (ARM). Após instalar o agente Arc em um servidor local, ele aparece no portal Azure como um recurso do tipo Microsoft.HybridCompute/machines, com Resource ID completo, suporte a tags, RBAC e integração com Azure Policy.

Isso significa que um servidor físico rodando Windows Server 2019 no datacenter local pode ser gerenciado, monitorado e auditado exatamente da mesma forma que uma VM Azure. O Arc habilita:

• Aplicação de Azure Policy e iniciativas de conformidade em servidores locais.
• Instalação automática de extensões como o Azure Monitor Agent, Microsoft Defender for Endpoint e o agente de Dependency Map.
• Acesso seguro via Azure Bastion sem exposição de portas RDP/SSH.
• Integração com Microsoft Defender for Cloud para avaliação de postura de segurança.

Azure Policy Guest Configuration: aplicando baselines em servidores híbridos

O Azure Policy Guest Configuration (atualmente parte do serviço Machine Configuration) permite auditar e aplicar configurações dentro do sistema operacional de VMs Azure e servidores Arc-enabled. Diferentemente das políticas ARM, que atuam no plano de controle do Azure, as políticas de Guest Configuration operam dentro da máquina e verificam — ou corrigem — configurações como:

• Políticas de senha e bloqueio de conta.
• Configurações de auditoria e log do Windows.
• Presença e configuração de softwares específicos.
• Configurações de firewall local e serviços habilitados.
• Conformidade com baselines do CIS Benchmark ou STIG.

As políticas podem operar em modo Audit (apenas reporta desvios) ou DeployIfNotExists (corrige automaticamente). Para ambientes que precisam demonstrar aderência a normas como LGPD, ISO 27001 ou PCI-DSS, essa capacidade de auditoria contínua e automatizada representa um diferencial relevante.

Acesso remoto seguro em ambientes híbridos: Azure Bastion

Acesso administrativo a servidores — seja para gerenciamento de emergência, troubleshooting ou manutenção rotineira — é uma necessidade operacional que, mal gerenciada, se torna um vetor de ataque crítico. Expor portas RDP (3389) ou SSH (22) diretamente à internet é uma prática que qualquer análise de pentest apontará como vulnerabilidade grave. O Azure Bastion resolve esse problema de forma nativa e sem agentes.

Como o Azure Bastion elimina a exposição de RDP/SSH à internet pública

O Azure Bastion é um serviço PaaS totalmente gerenciado que atua como jump server inteligente dentro da própria infraestrutura Azure. Provisionado em uma subnet dedicada (AzureBastionSubnet) na VNet, ele expõe apenas uma interface HTTPS (porta 443) ao usuário. A partir do portal Azure, o administrador inicia uma sessão RDP ou SSH tunelada via TLS diretamente no browser — sem necessidade de cliente RDP instalado, sem IP público na VM de destino e sem abertura de portas no firewall.

O resultado prático é expressivo: as VMs Azure dispensam IPs públicos, as regras de NSG não precisam permitir RDP/SSH de qualquer origem, e o acesso administrativo fica sujeito às políticas de acesso condicional do Microsoft Entra ID — incluindo MFA obrigatório e verificação de conformidade do dispositivo do administrador.

Configurando o Bastion RDP Connector para máquinas híbridas

A funcionalidade Bastion RDP Connector para servidores híbridos (disponível nos SKUs Standard e Premium do Azure Bastion) estende essa proteção para servidores on-premises conectados via VPN Gateway ou ExpressRoute. O fluxo opera da seguinte forma:

1. O servidor local é registrado no Azure Arc, recebendo um Resource ID no Azure.
2. O administrador acessa o recurso Arc no portal Azure e inicia uma sessão RDP via Bastion.
3. O Bastion roteia a sessão pelo túnel VPN/ExpressRoute até o servidor local, usando o IP privado da máquina.
4. A autenticação é validada pelo Microsoft Entra ID antes de estabelecer a sessão, aplicando todas as políticas de acesso condicional configuradas.

Isso elimina completamente a necessidade de VPNs client-to-site para acesso administrativo, simplifica o onboarding de novos administradores e cria um registro de auditoria centralizado de todas as sessões — tanto em recursos Azure quanto on-premises.

Benefício Híbrido do Azure: reduzindo custos com licenças existentes

Além dos ganhos técnicos e operacionais, o modelo híbrido com Azure oferece uma vantagem financeira concreta para empresas que já possuem licenças Microsoft ativas: o Azure Hybrid Benefit. Esse programa permite reutilizar licenças existentes de Windows Server e SQL Server para reduzir de forma significativa o custo de VMs e serviços gerenciados no Azure.

Como o Azure Hybrid Benefit funciona para Windows Server e SQL Server

Para Windows Server, o Azure Hybrid Benefit permite usar licenças com Software Assurance (SA) ativo para eliminar a cobrança da licença do sistema operacional em VMs Azure. Uma licença de Windows Server Standard com SA cobre até 2 VMs Azure com até 8 vCores cada. Uma licença Datacenter cobre VMs ilimitadas com até 8 vCores por licença. Na prática, isso reduz o custo de uma VM Windows em até 40% comparado ao preço pay-as-you-go padrão.

Para SQL Server, o benefício é ainda mais expressivo. Licenças SQL Server Enterprise com SA aplicadas a VMs Azure cobrem a edição Enterprise completa, cujo custo de licenciamento no modelo pay-as-you-go é bastante elevado. A economia pode chegar a 85% em relação ao preço padrão de uma VM com SQL Server Enterprise licenciado pelo Azure.

O benefício também se aplica ao Azure SQL Managed Instance, Azure SQL Database e Azure Dedicated Host, ampliando as possibilidades de otimização de custos em diferentes arquiteturas.

Calculando a economia real com o Benefício Híbrido do Azure

A forma mais precisa de mensurar a economia é usando a Azure Hybrid Benefit Savings Calculator disponível no site da Microsoft. Os dados necessários são: número de licenças disponíveis (cores ou processadores), edição (Standard ou Datacenter para Windows; Standard, Enterprise ou Developer para SQL), cobertura de SA e a região Azure onde os recursos serão provisionados.

Um exemplo prático: uma empresa com 20 licenças de Windows Server Datacenter com SA ativo pode cobrir até 160 vCores de VMs Windows no Azure sem custo adicional de licença. Se o ambiente Azure dessa empresa tiver 50 VMs com 4 vCores cada (200 vCores no total), 160 vCores serão cobertos pelo Hybrid Benefit e apenas 40 vCores pagarão a taxa de licença Azure — uma economia mensal que pode representar dezenas de milhares de reais dependendo do porte do ambiente.

Vale combinar o Azure Hybrid Benefit com Azure Reservations (compromisso de 1 ou 3 anos) para maximizar a redução de custos. A combinação das duas estratégias pode diminuir o custo de VMs Windows em até 80% comparado ao preço on-demand padrão.

Casos de uso reais de ambientes híbridos com Azure

A teoria sobre arquitetura híbrida ganha sentido real quando aplicada a cenários concretos de negócio. Dois casos de uso se destacam pela frequência com que apare