Planear uma implementação do Proxy de Aplicações do Microsoft Entra

Artigo
02/23/2024

O proxy de aplicativo Microsoft Entra é uma solução de acesso remoto segura e econômica para aplicativos locais. Ele fornece um caminho de transição imediato para as organizações "Cloud First" gerenciarem o acesso a aplicativos locais herdados que ainda não são capazes de usar protocolos modernos. Para obter informações introdutórias adicionais, consulte O que é proxy de aplicativo.

O proxy de aplicativo é recomendado para dar aos usuários remotos acesso a recursos internos. O proxy de aplicativo substitui a necessidade de uma VPN ou proxy reverso para esses casos de uso de acesso remoto. Não se destina a utilizadores que estejam na rede empresarial. Esses usuários que usam o proxy de aplicativo para acesso à intranet podem enfrentar problemas de desempenho indesejáveis.

Este artigo inclui os recursos necessários para planejar, operar e gerenciar o proxy de aplicativo Microsoft Entra.

Planear a implementação

A secção seguinte apresenta uma visão ampla dos principais elementos de planeamento para uma experiência de implementação eficiente.

Pré-requisitos

Tem de cumprir os seguintes pré-requisitos antes de iniciar a implementação. Pode ver mais informações sobre a configuração do ambiente, incluindo estes pré-requisitos, neste tutorial.

Conectores: Os conectores são agentes leves nos quais você pode implantar:
- Hardware físico local
- Uma VM hospedada em qualquer solução de hipervisor
- Uma VM hospedada no Azure para habilitar a conexão de saída com o serviço de proxy de aplicativo.
Consulte Compreender os conectores de rede privada do Microsoft Entra para obter uma visão geral mais detalhada.
- As máquinas conectoras devem estar habilitadas para TLS 1.2 antes de instalar os conectores.
- Se possível, implante conectores na mesma rede e segmento que os servidores de aplicativos Web back-end. É melhor implantar conectores depois de concluir uma descoberta de aplicativos.
- Recomendamos que cada grupo de conectores tenha pelo menos dois conectores para fornecer alta disponibilidade e escala. Ter três conectores é ideal para o caso de você precisar fazer a manutenção de uma máquina a qualquer momento. Analise a tabela de capacidade do conector para ajudar a decidir em que tipo de máquina instalar conectores. Quanto maior a máquina, mais buffer e desempenho será o conector.
Configurações de acesso à rede: os conectores de rede privada do Microsoft Entra se conectam ao Azure via HTTPS (Porta TCP 443) e HTTP (Porta TCP 80).
- O tráfego TLS do conector de terminação não é suportado e impedirá que os conectores estabeleçam um canal seguro com seus respetivos pontos de extremidade de proxy de aplicativo Microsoft Entra.
- Evite todas as formas de inspeção em linha nas comunicações TLS de saída entre conectores e o Azure. A inspeção interna entre um conector e aplicativos de back-end é possível, mas pode degradar a experiência do usuário e, como tal, não é recomendada.
- O balanceamento de carga dos próprios conectores também não é suportado, ou mesmo necessário.

Considerações importantes antes de configurar o proxy de aplicativo Microsoft Entra

Os seguintes requisitos principais devem ser atendidos para configurar e implementar o proxy de aplicativo Microsoft Entra.

Integração do Azure: antes de implantar o proxy de aplicativo, as identidades de usuário devem ser sincronizadas a partir de um diretório local ou criadas diretamente em seus locatários do Microsoft Entra. A sincronização de identidade permite que o Microsoft Entra ID pré-autentique os usuários antes de conceder-lhes acesso a aplicativos publicados por proxy de aplicativo e tenha as informações de identificador de usuário necessárias para executar o logon único (SSO).
Requisitos de acesso condicional: não recomendamos o uso de proxy de aplicativo para acesso à intranet porque isso adiciona latência que afetará os usuários. Recomendamos o uso de proxy de aplicativo com pré-autenticação e políticas de Acesso Condicional para acesso remoto da Internet. Uma abordagem para fornecer Acesso Condicional para uso na intranet é modernizar os aplicativos para que eles possam se autenticar diretamente com o Microsoft Entra ID. Consulte Recursos para migrar aplicativos para o Microsoft Entra ID para obter mais informações.
Limites de serviço: para proteger contra o consumo excessivo de recursos por locatários individuais, há limites de limitação definidos por aplicativo e locatário. Para ver esses limites, consulte Limites e restrições de serviço do Microsoft Entra. Esses limites de limitação são baseados em uma referência muito acima do volume de uso típico e fornecem um buffer amplo para a maioria das implantações.
Certificado público: Se você estiver usando nomes de domínio personalizados, deverá adquirir um certificado TLS/SSL. Dependendo dos seus requisitos organizacionais, obter um certificado pode levar algum tempo e recomendamos iniciar o processo o mais cedo possível. O proxy de aplicativo do Azure dá suporte a certificados padrão, curinga ou baseados em SAN. Para obter mais detalhes, consulte Configurar domínios personalizados com o proxy de aplicativo Microsoft Entra.
Requisitos de domínio: O logon único para seus aplicativos publicados usando a Delegação Restrita de Kerberos (KCD) requer que o servidor que executa o Conector e o servidor que executa o aplicativo sejam associados ao domínio e façam parte do mesmo domínio ou domínios confiáveis. Para obter informações detalhadas sobre o tópico, consulte KCD para logon único com proxy de aplicativo. O serviço de conector é executado no contexto do sistema local e não deve ser configurado para usar uma identidade personalizada.
Registos DNS para URLs
- Antes de usar domínios personalizados no proxy de aplicativo, você deve criar um registro CNAME no DNS público, permitindo que os clientes resolvam a URL externa definida personalizada para o endereço de proxy de aplicativo predefinido. A falha ao criar um registro CNAME para um aplicativo que usa um domínio personalizado impedirá que usuários remotos se conectem ao aplicativo. As etapas necessárias para adicionar registros CNAME podem variar de provedor DNS para provedor, portanto, saiba como gerenciar registros DNS e conjuntos de registros usando o centro de administração do Microsoft Entra.
- Da mesma forma, os hosts de conector devem ser capazes de resolver a URL interna dos aplicativos que estão sendo publicados.
Direitos e funções administrativas
- A instalação do conector requer direitos de administrador local para o servidor Windows no qual está sendo instalado. Também requer um mínimo de uma função de Administrador de Aplicativos para autenticar e registrar a instância do conector no locatário do Microsoft Entra.
- A publicação e a administração de aplicativos exigem a função de Administrador de Aplicativos . Os administradores de aplicativos podem gerenciar todos os aplicativos no diretório, incluindo registros, configurações de SSO, atribuições e licenciamento de usuários e grupos, configurações de proxy de aplicativo e consentimento. Ele não concede a capacidade de gerenciar o Acesso Condicional. A função Cloud Application Administrator tem todas as habilidades do Application Administrator, exceto que não permite o gerenciamento de configurações de proxy de aplicativo.
Licenciamento: o proxy de aplicativo está disponível por meio de uma assinatura do Microsoft Entra ID P1 ou P2. Consulte a página de preços do Microsoft Entra para obter uma lista completa de opções e recursos de licenciamento.

Descoberta de aplicativos

Compile um inventário de todos os aplicativos no escopo que estão sendo publicados por meio do proxy do aplicativo coletando as seguintes informações:

Tipo de Informação	Informações a recolher
Tipo de Serviço	Por exemplo: SharePoint, SAP, CRM, Aplicativo Web Personalizado, API
Plataforma de aplicação	Por exemplo: Windows IIS, Apache no Linux, Tomcat, NGINX
Associação ao domínio	FQDN (nome de domínio totalmente qualificado) do servidor Web
Localização da aplicação	Onde o servidor Web ou farm está localizado em sua infraestrutura
Acesso interno	A URL exata usada ao acessar o aplicativo internamente. Se um farm, que tipo de balanceamento de carga está em uso? Se o aplicativo extrai conteúdo de outras fontes que não ele mesmo. Determine se o aplicativo opera sobre WebSockets.
Acesso externo	A solução do fornecedor através da qual o aplicativo já pode estar exposto, externamente. O URL que pretende utilizar para acesso externo. Se SharePoint, verifique se os Mapeamentos de Acesso Alternativo estão configurados de acordo com esta diretriz. Caso contrário, você precisará definir URLs externas.
Certidão pública	Se estiver usando um domínio personalizado, obtenha um certificado com um nome de assunto correspondente. Se existir um certificado, anote o número de série e o local de onde pode ser obtido.
Authentication type	O tipo de autenticação suportado pelo suporte ao aplicativo, como Básico, Autenticação de Integração do Windows, baseada em formulários, baseada em cabeçalho e declarações. Se o aplicativo estiver configurado para ser executado em uma conta de domínio específica, observe o FQDN (nome de domínio totalmente qualificado) da conta de serviço. Se baseado em SAML, o identificador e as URLs de resposta. Se baseado em cabeçalho, a solução do fornecedor e o requisito específico para lidar com o tipo de autenticação.
Nome do grupo de conectores	O nome lógico para o grupo de conectores que serão designados para fornecer o canal e o SSO para este aplicativo de back-end.
Acesso a Utilizadores/Grupos	Os usuários ou grupos de usuários que receberão acesso externo ao aplicativo.
Requisitos adicionais	Observe quaisquer requisitos adicionais de acesso remoto ou segurança que devam ser levados em conta na publicação do aplicativo.

Você pode baixar esta planilha de inventário de aplicativos para inventariar seus aplicativos.

Definir requisitos organizacionais

A seguir estão as áreas para as quais você deve definir os requisitos de negócios da sua organização. Cada área contém exemplos de requisitos

Acesso

Os usuários remotos com dispositivos associados ao domínio ou ao Microsoft Entra podem acessar aplicativos publicados com segurança com logon único (SSO) contínuo.
Os utilizadores remotos com dispositivos pessoais aprovados podem aceder com segurança a aplicações publicadas, desde que estejam inscritos no MFA e tenham registado a aplicação Microsoft Authenticator no seu telemóvel como método de autenticação.

Governação

Os administradores podem definir e monitorar o ciclo de vida das atribuições de usuários para aplicativos publicados por meio do proxy de aplicativo.

Segurança

Apenas os utilizadores atribuídos a aplicações através da adesão a grupos ou individualmente podem aceder a essas aplicações.

Desempenho

Não há degradação do desempenho do aplicativo em comparação com o acesso ao aplicativo da rede interna.

Experiência do usuário

Os usuários estão cientes de como acessar seus aplicativos usando URLs familiares da empresa em qualquer plataforma de dispositivo.

Auditoria

Os administradores podem auditar a atividade de acesso do usuário.

Melhores práticas para um piloto

Determine a quantidade de tempo e esforço necessários para comissionar totalmente um único aplicativo para acesso remoto com logon único (SSO). Faça isso executando um piloto que considere sua descoberta inicial, publicação e testes gerais. Usar um aplicativo Web simples baseado em IIS que já esteja pré-configurado para autenticação integrada do Windows (IWA) ajudaria a estabelecer uma linha de base, pois essa configuração requer um esforço mínimo para pilotar com êxito o acesso remoto e o SSO.

Os seguintes elementos de design devem aumentar o sucesso de sua implementação piloto diretamente em um locatário de produção.

Gestão de conectores:

Os conectores desempenham um papel fundamental no fornecimento do canal local para seus aplicativos. O uso do grupo de conectores padrão é adequado para testes piloto iniciais de aplicativos publicados antes de comissioná-los em produção. Os aplicativos testados com êxito podem ser movidos para grupos de conectores de produção.

Gestão de aplicações:

É mais provável que sua força de trabalho se lembre de que um URL externo é familiar e relevante. Evite publicar seu aplicativo usando nossos sufixos msappproxy.net ou onmicrosoft.com predefinidos. Em vez disso, forneça um domínio verificado de nível superior familiar, prefixado com um nome de host lógico, como intranet.<customers_domain>.com.
Restrinja a visibilidade do ícone do aplicativo piloto a um grupo piloto ocultando seu ícone de inicialização do portal MyApps do Azure. Quando estiver pronto para produção, você pode definir o escopo do aplicativo para seu respetivo público-alvo, seja no mesmo locatário de pré-produção ou também publicando o aplicativo em seu locatário de produção.

Configurações de logon único: algumas configurações de SSO têm dependências específicas que podem levar tempo para serem configuradas, portanto, evite atrasos no controle de alterações garantindo que as dependências sejam resolvidas com antecedência. Isso inclui hosts de conector de ingresso de domínio para executar SSO usando a Delegação Restrita de Kerberos (KCD) e cuidando de outras atividades demoradas.

TLS entre o host do conector e o aplicativo de destino: a segurança é fundamental, portanto, o TLS entre o host do conector e os aplicativos de destino deve sempre ser usado. Particularmente se o aplicativo Web estiver configurado para autenticação baseada em formulários (FBA), pois as credenciais do usuário serão efetivamente transmitidas em texto não criptografado.

Implemente incrementalmente e teste cada etapa. Realize testes funcionais básicos após a publicação de um aplicativo para garantir que todos os requisitos de usuário e de negócios sejam atendidos, seguindo as instruções abaixo:

Teste e valide o acesso geral ao aplicativo Web com a pré-autenticação desabilitada.
Se for bem-sucedida, habilite a pré-autenticação e atribua usuários e grupos. Teste e valide o acesso.
Em seguida, adicione o método SSO para seu aplicativo e teste novamente para validar o acesso.
Aplique políticas de Acesso Condicional e MFA conforme necessário. Teste e valide o acesso.

Ferramentas de solução de problemas: Ao solucionar problemas, sempre comece validando o acesso ao aplicativo publicado a partir do navegador no host do conector e confirme se o aplicativo funciona conforme o esperado. Quanto mais simples for a configuração, mais fácil será determinar a causa raiz, portanto, considere tentar reproduzir problemas com uma configuração mínima, como usar apenas um único conector e nenhum SSO. Em alguns casos, ferramentas de depuração da web, como o Fiddler da Telerik, podem ser indispensáveis para solucionar problemas de acesso ou conteúdo em aplicativos acessados por meio de um proxy. O Fiddler também pode atuar como um proxy para ajudar a rastrear e depurar o tráfego para plataformas móveis, como iOS e Android, e praticamente qualquer coisa que possa ser configurada para rotear por meio de um proxy. Consulte o guia de solução de problemas para obter mais informações.

Implemente a sua solução

Implantar proxy de aplicativo

As etapas para implantar seu proxy de aplicativo são abordadas neste tutorial para adicionar um aplicativo local para acesso remoto. Se a instalação não for bem-sucedida, selecione Solucionar problemas de proxy de aplicativo no portal ou use o guia de solução de problemas para Problemas com a instalação do conector do agente de proxy de aplicativo.

Publicar aplicativos via proxy de aplicativo

A publicação de aplicativos pressupõe que você tenha satisfeito todos os pré-requisitos e que tenha vários conectores mostrados como registrados e ativos na página de proxy do aplicativo.

Também pode publicar aplicações com o PowerShell.

Abaixo estão algumas práticas recomendadas a serem seguidas ao publicar um aplicativo:

Usar grupos de conectores: atribua um grupo de conectores que tenha sido designado para publicar cada aplicativo respetivo. Recomendamos que cada grupo de conectores tenha pelo menos dois conectores para fornecer alta disponibilidade e escala. Ter três conectores é ideal para o caso de você precisar fazer a manutenção de uma máquina a qualquer momento. Além disso, consulte Compreender os grupos de conectores de rede privada do Microsoft Entra para ver como você também pode usar grupos de conectores para segmentar seus conectores por rede ou local.
Definir tempo limite do aplicativo de back-end: essa configuração é útil em cenários em que o aplicativo pode exigir mais de 75 segundos para processar uma transação de cliente. Por exemplo, quando um cliente envia uma consulta para um aplicativo Web que atua como um front-end para um banco de dados. O front-end envia essa consulta para seu servidor de banco de dados back-end e aguarda uma resposta, mas quando recebe uma resposta, o lado cliente da conversa expira. Definir o tempo limite como Longo fornece 180 segundos para que transações mais longas sejam concluídas.
Usar tipos de cookies apropriados
- Cookie somente HTTP: fornece segurança adicional ao fazer com que o proxy do aplicativo inclua o sinalizador HTTPOnly em cabeçalhos de resposta HTTP set-cookie. Essa configuração ajuda a mitigar explorações como scripts entre sites (XSS). Deixe esta definição como Não para clientes/agentes de utilizador que necessitem de acesso ao cookie de sessão. Por exemplo, cliente RDP/MTSC conectando-se a um gateway de área de trabalho remota publicado via proxy de aplicativo.
- Cookie seguro: Quando um cookie é definido com o atributo Secure, o agente do usuário (aplicativo do lado do cliente) só incluirá o cookie em solicitações HTTP se a solicitação for transmitida por um canal seguro TLS. Isso ajuda a mitigar o risco de um cookie ser comprometido em canais de texto não criptografado, portanto, deve ser ativado.
- Cookie persistente: Permite que o cookie de sessão do proxy de aplicativo persista entre os fechamentos do navegador, permanecendo válido até expirar ou ser excluído. Usado para cenários em que um aplicativo avançado, como o Office, acessa um documento dentro de um aplicativo Web publicado, sem que o usuário seja solicitado novamente para autenticação. No entanto, ative com cuidado, pois os cookies persistentes podem, em última análise, deixar um serviço em risco de acesso não autorizado, se não forem usados em conjunto com outros controles de compensação. Essa configuração só deve ser usada para aplicativos mais antigos que não podem compartilhar cookies entre processos. É melhor atualizar seu aplicativo para lidar com o compartilhamento de cookies entre processos em vez de usar essa configuração.
Traduzir URLs em cabeçalhos: você habilita isso para cenários em que o DNS interno não pode ser configurado para corresponder ao namespace público da organização (também conhecido como DNS dividido). A menos que seu aplicativo exija o cabeçalho de host original na solicitação do cliente, deixe esse valor definido como Sim. A alternativa é fazer com que o conector use o FQDN na URL interna para roteamento do tráfego real, e o FQDN na URL externa, como o cabeçalho do host. Na maioria dos casos, essa alternativa deve permitir que o aplicativo funcione normalmente, quando acessado remotamente, mas seus usuários perdem os benefícios de ter uma correspondência dentro de & fora da URL.
Traduzir URLs no Corpo do Aplicativo: ative a tradução de links do Corpo do Aplicativo para um aplicativo quando quiser que os links desse aplicativo sejam traduzidos em respostas para o cliente. Se habilitada, essa função fornece uma tentativa de melhor esforço para traduzir todos os links internos que o proxy do aplicativo encontra nas respostas HTML e CSS que estão sendo retornadas aos clientes. É útil ao publicar aplicativos que contêm links absolutos codificados ou links de nome curto NetBIOS no conteúdo, ou aplicativos com conteúdo que se vincula a outros aplicativos locais.

Para cenários em que um aplicativo publicado é vinculado a outros aplicativos publicados, habilite a tradução de links para cada aplicativo para que você tenha controle sobre a experiência do usuário no nível por aplicativo.

Por exemplo, suponha que você tenha três aplicativos publicados por meio do proxy do aplicativo que se vinculam uns aos outros: Benefícios, Despesas e Viagens, além de um quarto aplicativo, Comentários que não são publicados por meio do proxy do aplicativo.

Imagem 1

Quando você habilita a tradução de links para o aplicativo Benefícios, os links para Despesas e Viagens são redirecionados para as URLs externas desses aplicativos, para que os usuários que acessam os aplicativos de fora da rede corporativa possam acessá-los. Os links de Despesas e Viagem de volta para Benefícios não funcionam porque a tradução de links não foi habilitada para esses dois aplicativos. O link para Comentários não é redirecionado porque não há URL externo, portanto, os usuários que usam o aplicativo Benefícios não poderão acessar o aplicativo de comentários de fora da rede corporativa. Veja informações detalhadas sobre tradução de links e outras opções de redirecionamento.

Aceda à sua candidatura

Existem várias opções para gerenciar o acesso aos recursos publicados do proxy de aplicativo, portanto, escolha a mais apropriada para seu cenário específico e necessidades de escalabilidade. As abordagens comuns incluem: usar grupos locais que estão sendo sincronizados por meio do Microsoft Entra Connect, criar grupos dinâmicos no Microsoft Entra ID com base em atributos de usuário, usar grupos de autoatendimento gerenciados por um proprietário de recurso ou uma combinação de todos eles. Veja os recursos vinculados para os benefícios de cada um.

A maneira mais direta de atribuir acesso de usuários a um aplicativo é entrar nas opções Usuários e Grupos no painel esquerdo do seu aplicativo publicado e atribuir diretamente grupos ou indivíduos.

Imagem 24

Você também pode permitir que os usuários acessem seu aplicativo de autoatendimento atribuindo um grupo do qual eles não são membros no momento e configurando as opções de autoatendimento.

Imagem 25

Se habilitado, os usuários poderão fazer login no portal MyApps e solicitar acesso, além de serem aprovados automaticamente e adicionados ao grupo de autoatendimento já permitido ou precisarem da aprovação de um aprovador designado.

Os usuários convidados também podem ser convidados a acessar aplicativos internos publicados via proxy de aplicativo através do Microsoft Entra B2B.

Para aplicativos locais que normalmente são acessíveis anonimamente, não exigindo autenticação, você pode preferir desativar a opção localizada nas Propriedades do aplicativo.

Imagem 26

Deixar essa opção definida como Não permite que os usuários acessem o aplicativo local por meio do proxy de aplicativo Microsoft Entra sem permissões, portanto, use com cuidado.

Uma vez que seu aplicativo é publicado, ele deve ser acessível digitando seu URL externo em um navegador ou por seu ícone em https://myapps.microsoft.com.

Ativar pré-autenticação

Verifique se seu aplicativo está acessível por meio do proxy do aplicativo acessando-o por meio da URL externa.

Navegue até Aplicativos de identidade>>Aplicativos>corporativos Todos os aplicativos e escolha o aplicativo que deseja gerenciar.
Selecione o proxy do aplicativo.
No campo Pré-autenticação, use a lista suspensa para selecionar Microsoft Entra ID e selecione Salvar.

Com a pré-autenticação habilitada, o Microsoft Entra ID desafiará os usuários primeiro para autenticação e, se o logon único estiver configurado, o aplicativo back-end também verificará o usuário antes que o acesso ao aplicativo seja concedido. Alterar o modo de pré-autenticação de Passthrough para Microsoft Entra ID também configura a URL externa com HTTPS, portanto, qualquer aplicativo inicialmente configurado para HTTP agora será protegido com HTTPS.

Ativar o início de sessão único

O SSO oferece a melhor experiência de usuário e segurança possíveis, pois os usuários só precisam entrar uma vez ao acessar o Microsoft Entra ID. Depois que um usuário é pré-autenticado, o SSO é executado pelo conector de rede privada que se autentica no aplicativo local, em nome do usuário. O aplicativo de back-end processa o login como se fosse o próprio usuário.

Escolher a opção Passthrough permite que os usuários acessem o aplicativo publicado sem precisar se autenticar no Microsoft Entra ID.

A execução do SSO só é possível se o Microsoft Entra ID puder identificar o usuário que solicita acesso a um recurso, portanto, seu aplicativo deve ser configurado para pré-autenticar usuários com ID do Microsoft Entra após o acesso para que o SSO funcione, caso contrário, as opções de SSO serão desabilitadas.

Leia Logon único para aplicativos no Microsoft Entra ID para ajudá-lo a escolher o método SSO mais apropriado ao configurar seus aplicativos.

Trabalhar com outros tipos de aplicações

O proxy de aplicativo Microsoft Entra também pode oferecer suporte a aplicativos que foram desenvolvidos para usar a Microsoft Authentication Library (MSAL). Ele suporta aplicativos cliente nativos consumindo tokens emitidos pelo Microsoft Entra ID recebidos nas informações de cabeçalho da solicitação do cliente para executar a pré-autenticação em nome dos usuários.

Leia a publicação de aplicativos cliente nativos e móveis e aplicativos baseados em declarações para saber mais sobre as configurações disponíveis de proxy de aplicativo.

Usar o Acesso Condicional para fortalecer a segurança

A segurança de aplicativos requer um conjunto avançado de recursos de segurança que possam proteger e responder a ameaças complexas no local e na nuvem. Use políticas de Acesso Condicional para controlar o acesso aos seus aplicativos com base em várias condições, como localização, risco, tipo de dispositivo, conformidade do dispositivo e muito mais. Para obter exemplos de políticas que você pode implantar, consulte o artigo Modelos de acesso condicional.

Os seguintes recursos podem ser usados para oferecer suporte ao proxy de aplicativo Microsoft Entra:

Acesso condicional baseado no usuário e na localização: mantenha os dados confidenciais protegidos limitando o acesso do usuário com base na localização geográfica ou em um endereço IP com políticas de acesso condicional baseadas em localização.
Acesso condicional baseado em dispositivo: certifique-se de que apenas dispositivos registrados, aprovados e compatíveis possam acessar dados corporativos com acesso condicional baseado em dispositivo.
Acesso condicional baseado em aplicativo: o trabalho não precisa parar quando um usuário não está na rede corporativa. Proteja o acesso à nuvem corporativa e aos aplicativos locais e mantenha o controle com o Acesso Condicional.
Acesso condicional baseado em risco: proteja seus dados contra hackers mal-intencionados com uma política de acesso condicional baseada em risco que pode ser aplicada a todos os aplicativos e todos os usuários, seja no local ou na nuvem.
Microsoft Entra My Apps: Com seu serviço de proxy de aplicativo implantado e aplicativos publicados com segurança, ofereça aos usuários um hub simples para descobrir e acessar todos os seus aplicativos. Aumente a produtividade com recursos de autoatendimento, como a capacidade de solicitar acesso a novos aplicativos e grupos ou gerenciar o acesso a esses recursos em nome de outras pessoas, por meio de Meus Aplicativos.

Gerencie sua implementação

Funções necessárias

A Microsoft defende o princípio de conceder o menor privilégio possível para executar as tarefas necessárias com o Microsoft Entra ID. Analise as diferentes funções do Azure disponíveis e escolha a certa para atender às necessidades de cada persona. Algumas funções podem precisar ser aplicadas temporariamente e removidas após a conclusão da implantação.

Função comercial	Tarefas empresariais	Funções do Microsoft Entra
Administrador do Help Desk	Normalmente limitado à qualificação de problemas relatados pelo usuário final e à execução de tarefas limitadas, como alterar as senhas dos usuários, invalidar tokens de atualização e monitorar a integridade do serviço.	Administrador do Helpdesk
Administrador de identidade	Leia os relatórios de entrada e os logs de auditoria do Microsoft Entra para depurar problemas relacionados ao proxy do aplicativo.	Leitor de segurança
Proprietário do aplicativo	Crie e gerencie todos os aspetos de aplicativos corporativos, registros de aplicativos e configurações de proxy de aplicativos.	Administrador da Aplicação
Administração de infraestrutura	Proprietário da Substituição de Certificados	Administrador da Aplicação

Minimizar o número de pessoas que têm acesso a informações ou recursos seguros ajudará a reduzir a chance de um ator mal-intencionado obter acesso não autorizado ou um usuário autorizado afetar inadvertidamente um recurso sensível.

No entanto, os usuários ainda precisam realizar operações privilegiadas diárias, portanto, aplicar políticas de Gerenciamento de Identidade Privilegiadas baseadas em just-in-time (JIT) para fornecer acesso privilegiado sob demanda aos recursos do Azure e ao Microsoft Entra ID é nossa abordagem recomendada para gerenciar efetivamente o acesso administrativo e a auditoria.

Relatórios e monitorização

O Microsoft Entra ID fornece informações adicionais sobre o uso do aplicativo e a integridade operacional da sua organização por meio de logs e relatórios de auditoria. O proxy de aplicativo também facilita muito o monitoramento de conectores do centro de administração do Microsoft Entra e dos Logs de Eventos do Windows.

Registos de auditoria de aplicação

Esses logs fornecem informações detalhadas sobre logins em aplicativos configurados com proxy de aplicativo e o dispositivo e o usuário que acessa o aplicativo. Os logs de auditoria estão localizados no centro de administração do Microsoft Entra e na API de auditoria para exportação. Além disso, relatórios de uso e insights também estão disponíveis para seu aplicativo.

Monitorização de Conectores de Rede Privada

Os conectores e o serviço cuidam de todas as tarefas de alta disponibilidade. Você pode monitorar o status de seus conectores na página de proxy do aplicativo no centro de administração do Microsoft Entra. Para obter mais informações sobre a manutenção do conector, consulte Compreender os conectores de rede privada do Microsoft Entra.

Logs de eventos e contadores de desempenho do Windows

Os conectores têm logs de administração e de sessão. Os logs de administração incluem eventos-chave e seus erros. Os logs de sessão incluem todas as transações e seus detalhes de processamento. Os logs e contadores estão localizados nos Logs de Eventos do Windows para obter mais informações, consulte Compreender os conectores de rede privada do Microsoft Entra. Siga este tutorial para configurar fontes de dados do log de eventos no Azure Monitor.

Guia e etapas de solução de problemas

Saiba mais sobre problemas comuns e como resolvê-los com nosso guia para solucionar problemas de mensagens de erro.

Os artigos a seguir abordam cenários comuns que também podem ser usados para criar guias de solução de problemas para sua organização de suporte.