Planejar uma implantação de proxy de aplicativo do Microsoft Entra

Artigo
02/22/2024

O proxy de aplicativo do Microsoft Entra é uma solução de acesso remoto simples, segura e econômica para aplicativos locais. Ele fornece um caminho de transição imediato para as organizações com "Prioridade na Nuvem" para gerenciar o acesso a aplicativos locais herdados que ainda não são capazes de usar protocolos modernos. Para saber mais informações introdutórias, consulte O que é o proxy de aplicativo.

O proxy de aplicativo é recomendado para conceder aos usuários remotos o 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 é destinado a usuários que estão na rede corporativa. Esses usuários que usam o proxy de aplicativo para acesso à intranet pode enfrentar problemas de desempenho indesejáveis.

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

Planejar sua implementação

A seção a seguir fornece uma visão geral dos principais elementos de planejamento que irão configurar para uma experiência de implantação eficiente.

Pré-requisitos

Você precisa atender aos seguintes pré-requisitos antes de iniciar a implementação. Você pode ver mais informações sobre como configurar seu ambiente, incluindo esses pré-requisitos, neste tutorial.

Conectores: conectores são agentes leves que você pode implantar em:
- 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 do proxy de aplicativo.
Confira o artigo Entenda o que são conectores de rede privada do Microsoft Entra para obter uma visão geral mais detalhada.
- Os computadores do conector devem ser habilitados para o TLS 1.2 antes da instalação dos conectores.
- Se possível, implante os conectores na mesma rede e segmento que os servidores de aplicativos Web de 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 caso você precise fazer a manutenção de um computador a qualquer momento. Examine a tabela de capacidade do conector para ajudar a decidir em que tipo de computador instalar conectores. Quanto maior a máquina, maior buffer e desempenho do conector ela terá.
Configurações de acesso à rede: os conectores de rede privada do Microsoft Entra se conectam ao Azure por meio de HTTPS (Porta TCP 443) e HTTP (Porta TCP 80).
- O tráfego de TLS do conector de terminação não tem suporte e impedirá que os conectores estabeleçam um canal seguro com seus respectivos pontos de extremidade de proxy do aplicativo Microsoft Entra.
- Evite todas as formas de inspeção embutida em 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, por isso, não é recomendada.
- O balanceamento de carga dos conectores em si também não tem suporte ou nem mesmo é necessário.

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

Os requisitos principais a seguir devem ser atendidos para configurar e implementar o proxy de aplicativo do 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 nos locatários do Microsoft Entra. A Sincronização de Identidades permite que o Microsoft Entra ID pré-autentique os usuários antes de conceder-lhes acesso aos aplicativos publicados pelo proxy de aplicativo e tenha as informações de identificação do usuário necessárias para executar o SSO (logon único).
Requisitos de acesso condicional: não recomendamos o uso do proxy de aplicativo para acesso à intranet porque isso adiciona latência que afetará os usuários. É recomendável usar o proxy de aplicativo com políticas de acesso condicional e pré-autenticação 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 de migração de aplicativos para o Microsoft Entra ID para saber mais informações.
Limites de serviço: para se 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 Restrições e limites de serviço Microsoft Entra. Essas limitações são baseadas em um parâmetro de comparação 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 requisitos organizacionais, obter um certificado pode levar algum tempo e recomendamos que inicie o processo o quanto antes. O proxy de aplicativo do Azure dá suporte a certificados padrão, curingas ou baseados em SAN. Para saber mais, confira Configurar domínios personalizados com o proxy de aplicativo do Microsoft Entra.
Requisitos de domínio: o logon único para seus aplicativos publicados usando a KCD (Delegação Restrita de Kerberos) requer que o servidor que executa o conector e o servidor que executa o aplicativo estejam ingressados no domínio e façam parte do mesmo domínio ou domínios confiantes. Para obter informações detalhadas sobre o tópico, consulte KCS para logon único com proxy de aplicativo. O serviço do conector é executado no contexto do sistema local e não deve ser configurado para usar uma identidade personalizada.
Registros 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 os 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 do 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 exige direitos de administrador local ao servidor Windows no qual ele está sendo instalado. Ele também exige no mínimo uma função de Administrador de Aplicativos para autenticar e registrar a instância do conector em seu locatário do Microsoft Entra.
- A publicação e a administração de aplicativos exigem a função de Administrador de Aplicativos. O Administrador de Aplicativos pode gerenciar todos os aplicativos no diretório, incluindo registros, configurações de SSO, licenciamento e atribuições de usuários e grupos, configurações do proxy de aplicativo e o consentimento. Ela não concede a capacidade de gerenciar o Acesso Condicional. A função de Administrador de Aplicativos de Nuvem tem todas as habilidades do Administrador de Aplicativo, exceto pelo fato de que ela não permite o gerenciamento de configurações do 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 Aplicativo

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

Tipo de informação	Informações a serem coletadas
Tipo de serviço	Por exemplo: SharePoint, SAP, CRM, Aplicativo Web personalizado, API
Plataforma de aplicativos	Por exemplo: IIS do Windows, Apache no Linux, Tomcat, NGINX
Associação do domínio	FQDN (nome de domínio totalmente qualificado) do servidor Web
Local de aplicativo	Onde o servidor Web ou o farm está localizado em sua infraestrutura
Acesso interno	A URL exata usada ao acessar o aplicativo internamente. Se for um farm, que tipo de balanceamento de carga está em uso? Se o aplicativo desenha conteúdo de outras fontes diferentes das próprias. Determine se o aplicativo opera sobre WebSockets.
Acesso externo	A solução do fornecedor que o aplicativo pode já estar exposto, externamente. A URL que você deseja usar para acesso externo. Se estiver no SharePoint, verifique se os mapeamentos de acesso alternativo estão configurados de acordo com estas diretrizes. Caso contrário, será necessário definir URLs externas.
Certificado público	Se estiver usando um domínio personalizado, adquira um certificado com um nome de entidade correspondente. se houver um certificado, anote o número de série e o local de onde ele pode ser obtido.
Tipo de autenticação	O tipo de autenticação compatível com o suporte do aplicativo, como Básica, Autenticação de Integração do Windows, baseada em formulários, 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 de fornecedor e o requisito específico para tratar do tipo de autenticação.
Nome do grupo de conectores	O nome lógico do grupo de conectores que será designado para fornecer o canal e o SSO para este aplicativo de back-end.
Acesso de Usuários/Grupos	Os usuários ou grupos de usuários aos quais será concedido acesso externo ao aplicativo.
Requisitos adicionais	Observe quaisquer requisitos adicionais de acesso remoto ou de segurança que devem ser fatorados na publicação do aplicativo.

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

Definir requisitos organizacionais

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

Acesso

Usuários remotos com dispositivos conectados ao domínio ou ao Microsoft Entra podem acessar aplicativos publicados com segurança com o SSO (logon único) contínuo.
Os usuários remotos com dispositivos pessoais aprovados podem acessar com segurança os aplicativos publicados, desde que eles estejam registrados no MFA e tenham registrado o aplicativo Microsoft Authenticator em seu celular como um método de autenticação.

Governança

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

Segurança

Somente os usuários atribuídos a aplicativos por meio da associação de grupo ou individualmente podem acessar esses aplicativos.

Desempenho

Não há degradação do desempenho do aplicativo em comparação ao 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 obter um piloto

Determine a quantidade de tempo e esforço necessários para encerrar completamente um único aplicativo para acesso remoto com SSO (logon único). Faça isso executando um piloto que considere sua descoberta inicial, publicação e teste geral. O uso de um aplicativo Web baseado no IIS simples já pré-configurado para a IWA (autenticação integrada do Windows) ajudaria a estabelecer uma linha de base, pois essa configuração requer um esforço mínimo para o acesso remoto e o SSO do piloto bem-sucedido.

Os elementos de design a seguir devem aumentar o sucesso da implementação do piloto diretamente em um locatário de produção.

Gerenciamento de conector:

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

Gerenciamento de aplicativos:

É mais provável que sua força de trabalho lembre se uma URL externa é 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 que seja 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 no portal do Azure MyApps. Quando estiver pronto para produção, defina o escopo do aplicativo para seu respectivo público-alvo, seja no mesmo locatário de pré-produção ou também publicando o aplicativo no 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 de controle de alterações, garantindo que as dependências sejam resolvidas antes do tempo. Isso inclui os hosts do conector de ingressando no domínio para executar o SSO usando a KCD (Delegação Restrita do Kerberos) 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 sempre deve ser usado. Particularmente, se o aplicativo Web for configurado para autenticação baseada em formulários (FBA), como as credenciais do usuário, serão transmitidas efetivamente em texto não criptografado.

Implemente de forma incremental e teste cada etapa. Realize testes funcionais básicos depois de publicar 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 pré-autenticação desabilitada.
Se houver êxito, habilite a pré-autenticação e atribua usuários e grupos. Testar e validar acessos.
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. Testar e validar acessos.

Ferramentas de Solução de Problemas: ao solucionar problemas, comece sempre validando o acesso ao aplicativo publicado do navegador no host do conector e confirme se o aplicativo funciona conforme o esperado. Quanto mais simples a sua configuração, mais fácil será determinar a causa raiz, considere a possibilidade de tentar reproduzir problemas com uma configuração mínima, como usar apenas um único conector e nenhum SSO. Em alguns casos, as ferramentas de depuração da Web, como o Fiddler da Telerik, podem se tornar indispensáveis na solução de problemas de acesso ou de 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 de plataformas móveis, como iOS e Android, e praticamente tudo que pode ser configurado para rotear por meio de um proxy. Confira o Guia de Solução de Problemas para saber mais.

Implementar Sua Solução

Implantar proxy de aplicativo

As etapas para implantar o 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 do proxy de rede no portal ou use o guia de solução de problemas para problemas ao instalar o Conector de Agente do proxy de aplicativo.

Publicar aplicativos por meio do proxy de aplicativo

A publicação de aplicativos considere que você atendeu todos os pré-requisitos e que tem vários conectores aparecendo como registrados e ativos na página do proxy de aplicativo.

Você também pode publicar aplicativos usando o PowerShell.

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

Usar grupos de conectores: atribua um grupo de conectores designado para publicar cada aplicativo respectivo. Recomendamos que cada grupo de conectores tenha pelo menos dois conectores para fornecer alta disponibilidade e escala. Ter três conectores é ideal caso você precise fazer a manutenção de um computador a qualquer momento. Além disso, veja 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 Back-end: essa configuração é útil em cenários em que o aplicativo pode exigir mais de 75 segundos para processar uma transação do cliente. Por exemplo, quando um cliente envia uma consulta a 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 do cliente da conversa atinge o tempo limite. Definir o tempo limite como longo fornece de 180 segundos para que as transações mais longas sejam concluídas.
Usar tipos de cookie apropriados
- Cookie somente HTTP: fornece segurança adicional ao fazer com que o proxy de aplicativo inclua o sinalizador HTTPOnly nos cabeçalhos de resposta HTTP set-cookie. Essa configuração ajuda a reduzir as explorações, como XSS (script entre sites). Manter essa configuração como Não para agentes de clientes ou usuário que exigem acesso ao cookie de sessão. Por exemplo, o cliente RDP/MTSC conectando-se a um Gateway de Área de Trabalho Remota publicado por meio do proxy de aplicativo.
- Cookie seguro: quando um cookie é definido com o atributo Seguro, o agente do usuário (aplicativo do lado do cliente) incluirá apenas o cookie em solicitações HTTP se a solicitação for transmitida por um canal protegido por TLS. Isso ajuda a reduzir o risco de um cookie ser comprometido em canais de texto não desmarcados, portanto, deve ser habilitado.
- Cookie persistente: permite que o cookie de sessão do proxy de aplicativo persista entre os fechamentos do navegador ao permanecer válido até sua expiração ou exclusão. Usado para cenários em que um aplicativo avançado, como o Office, acessa um documento em um aplicativo Web publicado, sem que seja solicitada nova autenticação do usuário. No entanto, habilite com cuidado, pois os cookies persistentes podem deixar um serviço em risco de acesso não autorizado, se não forem usados com outros controles de compensação. Essa configuração deve ser usada somente para aplicativos mais antigos que não conseguem compartilhar cookies entre processos. É melhor atualizar seu aplicativo para lidar com o compartilhamento de cookies entre processos em vez de usar essa configuração.
Converter URLs em cabeçalhos: habilite isso para cenários em que o DNS interno não pode ser configurado para corresponder ao namespace público da organização (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 para Sim. A alternativa é fazer com que o conector use o FQDN na URL interna para o 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 URL interna e externa correspondentes.
Converter URLs no Corpo do Aplicativo: ative a conversão do link do Corpo do Aplicativo para um aplicativo quando desejar que os links desse aplicativo sejam convertidos em respostas de volta ao cliente. Se habilitada, essa função fornece uma tentativa de maior esforço na conversão de todos os links internos que o proxy de aplicativo encontra nas respostas HTML e CSS devolvidas aos clientes. Ela é útil ao publicar aplicativos que contêm links NetBIOS de nome curto ou embutidos em código absolutos no conteúdo, ou aplicativos com conteúdo vinculados a outros aplicativos locais.

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

Por exemplo, imagine que você tem três aplicativos publicados por meio do proxy de aplicativo, todos vinculados entre si: Benefícios, Despesas e Viagem, além de um quarto aplicativo, Comentários, que não é publicado por meio do proxy de aplicativo.

Figura 1

Quando você habilita a conversão de link 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 para Benefícios não funcionam, pois a conversão de link não foi habilitada para esses dois aplicativos. O link para Comentários não é redirecionado porque não há nenhuma URL externa, portanto os usuários que usam o aplicativo de Benefícios não conseguirão acessar o aplicativo de comentários de fora da rede corporativa. Consulte informações detalhadas em Conversão de link e outras opções de redirecionamento.

Acesse seu aplicativo

Existem várias opções para gerenciar o acesso aos recursos publicados do proxy de aplicativo, portanto, escolha o mais apropriado para o cenário e as necessidades de escalabilidade em questão. 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. Consulte os recursos vinculados para obter os benefícios de cada um.

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

Figura 24

Você também pode permitir que os usuários acessem por autoatendimento em seu aplicativo atribuindo um grupo que atualmente não é membro e configurando as opções de autoatendimento.

Figura 25

Se habilitada, os usuários poderão fazer logon no portal do MyApps, solicitarem acesso e serem aprovados automaticamente e adicionados ao grupo de autoatendimento já permitido ou precisar de aprovação de um aprovador designado.

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

Para aplicativos locais que normalmente são acessíveis anonimamente e não exigem nenhuma autenticação, você pode preferir desabilitar a opção localizada nas Propriedadesdo aplicativo.

Figura 26

Deixar esta opção definida como “Não” permite que os usuários acessem o aplicativo local via proxy de aplicativo do Microsoft Entra sem permissões, portanto, use com cautela.

Depois que seu aplicativo for publicado, ele deverá ser acessível digitando sua URL externa em um navegador ou por seu ícone em https://myapps.microsoft.com.

Habilitar pré-autenticação

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

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

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

Habilitar logon único

O SSO fornece 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. Assim 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 logon como se ele fosse o próprio usuário.

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

A execução de SSO só será possível se o Microsoft Entra ID puder identificar o usuário solicitando acesso a um recurso, de modo que o aplicativo deve ser configurado para autenticar previamente os usuários com o Microsoft Entra ID no 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 ajudar você a escolher o método de SSO mais apropriado ao configurar aplicativos.

Trabalhando com outros tipos de aplicativos

O proxy de aplicativo do Microsoft Entra também pode dar suporte a aplicativos que foram desenvolvidos para usar a MSAL (Biblioteca de Autenticação da Microsoft). Ele dá suporte a aplicativos clientes 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 Publicar aplicativos cliente móveis e nativos e aplicativos baseados em declarações para saber mais sobre configurações disponíveis do proxy de aplicativo.

Usar o acesso condicional para reforçar a segurança

A segurança do aplicativo requer um conjunto avançado de recursos de segurança que podem proteger e responder a ameaças complexas locais e na nuvem. Use as políticas de acesso condicional para controlar o acesso aos seus aplicativos com base em várias condições, como local, 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 recursos a seguir podem ser usados para dar suporte ao proxy de aplicativo do Microsoft Entra:

Acesso condicional com base em usuário e 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 com base em localização.
Acesso condicional com base no dispositivo: garanta que somente os dispositivos registrados, aprovados e em conformidade 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 acesso condicional.
Acesso condicional com base 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 usuários, seja localmente ou na nuvem.
Meus Aplicativos do Microsoft Entra: com o serviço do proxy de aplicativo implantado e os aplicativos publicados com segurança, ofereça aos usuários um hub simples para descobrir e acessar todos os seus aplicativos. Aumenta 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 do Meus Aplicativos.

Gerenciar sua implementação

Funções necessárias

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

Função de negócios	Tarefas de negócios	Funções do Microsoft Entra
Administrador de assistência técnica	Normalmente limitado à qualificar problemas relatados pelo usuário final e executar tarefas limitadas, como alterar senhas de usuários, invalidar tokens de atualização e monitorar a integridade do serviço.	Administrador de assistência técnica
Administrador de identidade	Leia os relatórios de credenciais e os logs de auditoria do Microsoft Entra para depurar problemas relacionados ao proxy de aplicativo.	Leitor de segurança
Proprietário do aplicativo	Criar e gerenciar todos os aspectos de aplicativos empresariais, registros dos aplicativos e configurações de Proxy de Aplicativos.	Administrador de Aplicativo
Administrador de infraestrutura	Proprietário de Sobreposição de certificados	Administrador de Aplicativo

Minimizar o número de pessoas que têm acesso a informações seguras ou recursos, ajudará a reduzir a chance de um ator mal-intencionado acessar sem autorização ou um usuário autorizado afetar acidentalmente um recurso confidencial.

No entanto, os usuários ainda precisam executar operações privilegiadas diariamente, portanto, a aplicação de políticas do Privileged Identity Management baseadas em just-in-time (JIT) para fornecer acesso privilegiado sob demanda aos recursos do Azure e ao Microsoft Entra ID é a abordagem recomendada para o gerenciamento eficaz do acesso administrativo e da auditoria.

Relatórios e monitoramento

O Microsoft Entra ID fornece insights adicionais sobre o uso de aplicativos e a integridade operacional de sua organização por meio de relatórios e logs 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.

Logs de auditoria de aplicativo

Esses logs fornecem informações detalhadas sobre logons para aplicativos configurados com o 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, os relatórios de uso e insights também estão disponíveis para seu aplicativo.

monitoramento do conector de rede privada

Os conectores e o serviço cuidam de todas as tarefas de alta disponibilidade. Você pode monitorar o status dos conectores na página do proxy de aplicativo no centro de administração do Microsoft Entra. Para saber mais sobre a manutenção de conectores, confira Entenda o que são conectores de rede privada do Microsoft Entra.

Logs de eventos do Windows e contadores de desempenho

Os conectores têm logs de administrador e sessão. Os logs de administrador incluem eventos de chave e seus erros. Os logs de sessão incluem todas as transações e seus detalhes de processamento. Os logs e os contadores estão localizados nos Logs de Eventos do Windows. Para obter mais informações, confira Entenda o que são conectores de rede privada do Microsoft Entra. Siga este tutorial para configurar fontes de dados de 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 a organização do seu suporte.

Share via