Planear uma implementação do Proxy de Aplicações do Azure AD

Azure Ative Directory (Azure AD) Proxy de Aplicações é uma solução de acesso remoto segura e rentável para aplicações no local. Fornece um caminho de transição imediato para as organizações "Cloud First" gerirem o acesso a aplicações antigas no local que ainda não são capazes de usar protocolos modernos. Para obter informações introdutórias adicionais, consulte o que está Proxy de Aplicações.

Proxy de Aplicações é recomendado para dar aos utilizadores remotos acesso a recursos internos. Proxy de Aplicações substitui a necessidade de um VPN ou procuração inversa para estes casos de utilização de acesso remoto. Não se destina a utilizadores que estejam na rede corporativa. Estes utilizadores que usam Proxy de Aplicações para acesso intranet podem ter problemas de desempenho indesejáveis.

Este artigo inclui os recursos necessários para planear, operar e gerir o Azure AD Proxy de Aplicações.

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 que pode utilizar:

    • Hardware físico no local
    • Um VM hospedado dentro de qualquer solução de hipervisor
    • Um VM hospedado em Azure para permitir a ligação de saída ao serviço Proxy de Aplicações.
  • Consulte os Conectores Proxy Proxy da App AD Azure para obter uma visão geral mais detalhada.

    • As máquinas de conector devem ser ativadas para o TLS 1.2 antes de instalar os conectores.

    • Se possível, implemente os conectores na mesma rede e segmento que os servidores de aplicações web de back-end. É melhor implantar conectores depois de completar uma descoberta de aplicações.

    • Recomendamos que cada grupo de conector tenha pelo menos dois conectores para fornecer alta disponibilidade e escala. Ter três conectores é ótimo no caso de precisar de servir uma máquina em qualquer ponto. Reveja a tabela de capacidade do conector para ajudar a decidir que tipo de máquina instalar conectores ligados. Quanto maior for a máquina, mais tampão e executante será o conector.

  • Definições de acesso à rede: Azure AD Proxy de Aplicações conectores ligam-se ao Azure via HTTPS (Porta TCP 443) e HTTP (Porta TCP 80).

    • O tráfego de ligação de terminação TLS não é suportado e impedirá que os conectores estabeleçam um canal seguro com os respetivos pontos finais Aplicação Azure AD Proxy.

    • Evite todas as formas de inspeção em linha nas comunicações TLS de saída entre conectores e Azure. A inspeção interna entre um conector e aplicações de backend é possível, mas pode degradar a experiência do utilizador, e como tal, não é recomendado.

    • O equilíbrio de carga dos próprios conectores também não é suportado, nem sequer necessário.

Considerações importantes antes de configurar a Azure AD Proxy de Aplicações

Devem ser cumpridos os seguintes requisitos fundamentais para configurar e implementar Proxy de Aplicações Azure AD.

  • Azure onboarding: Antes de implementar o proxy de aplicações, as identidades do utilizador devem ser sincronizadas a partir de um diretório no local ou criadas diretamente dentro dos seus inquilinos AD Azure. A sincronização de identidade permite que a Azure AD pré-autenticar os utilizadores antes de lhes conceder acesso às aplicações publicadas pela App Proxy e ter as informações necessárias do identificador do utilizador para realizar um único sinal de acesso (SSO).

  • Requisitos de acesso condicional: Não recomendamos a utilização de Proxy de Aplicações para acesso intranet, porque isso adiciona latência que irá afetar os utilizadores. Recomendamos a utilização de Proxy de Aplicações com pré-autenticação e políticas de acesso condicional para acesso remoto a partir da internet. Uma abordagem para fornecer acesso condicional para uso intranet é modernizar aplicações para que possam autenticar diretamente com AAD. Consulte os Recursos para aplicações migratórias para AAD para obter mais informações.

  • Limites de serviço: Para proteger contra o consumo excessivo de recursos por inquilinos individuais, existem limites de estrangulamento estabelecidos por pedido e inquilino. Para ver estes limites, consulte os limites e restrições de serviço Azure AD. Estes limites de estrangulamento baseiam-se num benchmark muito acima do volume de utilização típico e fornecem um tampão amplo para a maioria das implementações.

  • Certificado público: Se estiver a utilizar nomes de domínio personalizados, tem de adquirir um certificado TLS/SSL. Dependendo dos seus requisitos organizacionais, obter um certificado pode demorar algum tempo e recomendamos que comece o processo o mais cedo possível. Aplicação Azure Proxy suporta certificados standard, wildcard ou SAN. Para mais detalhes consulte Configure domínios personalizados com Proxy de Aplicações AD AZure.

  • Requisitos de domínio: O único sinal de inscrição nas suas aplicações publicadas utilizando a Delegação Restrita Kerberos (KCD) requer que o servidor que executa o Conector e o servidor que executa a aplicação sejam unidos de domínio e parte do mesmo domínio ou domínio de confiança. Para obter informações detalhadas sobre o tópico, consulte kCD para obter um único sinal de Proxy de Aplicações. O serviço de conector funciona no contexto do sistema local e não deve ser configurado para utilizar uma identidade personalizada.

  • Registos dns para URLs

    • Antes de utilizar domínios personalizados em Proxy de Aplicações deve criar um registo CNAME em DNS público, permitindo que os clientes resolvam o URL externo definido personalizado para o endereço de Proxy de Aplicações pré-definido. Não criar um registo CNAME para uma aplicação que utilize um domínio personalizado impedirá os utilizadores remotos de se ligarem à aplicação. As medidas necessárias para adicionar registos CNAME podem variar de fornecedor de DNS para fornecedor, por isso aprenda a gerir registos de DNS e recordes utilizando o portal do Azure.

    • Da mesma forma, os anfitriões de conector devem ser capazes de resolver o URL interno das aplicações que estão a ser publicadas.

  • Direitos e funções administrativas

    • A instalação do conector requer direitos de administração locais para o servidor Windows em que está a ser instalado. Também requer um mínimo de uma função de Administrador de Aplicação para autenticar e registar a instância do conector para o seu inquilino AZure AD.

    • A publicação e administração de aplicações requerem a função de Administrador de Aplicação . Os Administradores de Aplicações podem gerir todas as aplicações no diretório, incluindo registos, definições de SSO, atribuições de utilizador e grupo e licenciamento, Proxy de Aplicações definições e consentimento. Não dá a capacidade de gerir o Acesso Condicional. A função de Administrador de Aplicação cloud tem todas as capacidades do Administrador de Aplicação, exceto que não permite a gestão de Proxy de Aplicações configurações.

  • Licenciamento: Proxy de Aplicações está disponível através de uma subscrição Azure AD Premium. Consulte a página de preços Azure Ative Directory para obter uma lista completa de opções e funcionalidades de licenciamento.

Descoberta de Aplicações

Compilar um inventário de todas as aplicações em âmbito que estão a ser publicadas através de Proxy de Aplicações através da recolha das seguintes informações:

Tipo de Informação Informação para recolher
Tipo de Serviço Por exemplo: SharePoint, SAP, CRM, Custom Web Application, API
Plataforma de aplicação Por exemplo: Windows IIS, Apache em Linux, Tomcat, NGINX
Associação ao domínio O nome de domínio totalmente qualificado do servidor web (FQDN)
Localização da aplicação Onde o servidor web ou a quinta estão localizados na sua infraestrutura
Acesso interno O URL exato utilizado ao aceder à aplicação internamente.
Se uma fazenda, que tipo de equilíbrio de carga está em uso?
Se a aplicação extrai conteúdo de outras fontes que não a própria.
Determine se a aplicação funciona através de WebSockets.
Acesso externo A solução do fornecedor que a aplicação pode já estar exposta através do throught, externamente.
O URL que pretende utilizar para acesso externo. Se o SharePoint, certifique-se de que os Mapeamentos de Acesso Alternativo estão configurados por esta orientação. Caso contrário, terá de definir URLs externos.
Certificado público Se utilizar um domínio personalizado, obtenha um certificado com um nome de sujeito correspondente. se existir um certificado, note-se o número de série e a localização a partir do local onde pode ser obtido.
Tipo de autenticação O tipo de autenticação suportado pelo suporte de aplicação, como a Autenticação Básica, Windows Integração, baseada em formulários, baseada em cabeçalhos e reclamações.
Se a aplicação estiver configurada para ser executada numa conta de domínio específica, note o Nome de Domínio Totalmente Qualificado (FQDN) da conta de serviço.
Se saml-based, o identificador e urLs de resposta.
Se estiver à base de cabeçalho, a solução do fornecedor e o requisito específico para o manuseamento do tipo de autenticação.
Nome do grupo do conector O nome lógico para o grupo de conectores que serão designados para fornecer o canal e SSO a esta aplicação de backend.
Acesso de utilizadores/grupos Os utilizadores ou grupos de utilizadores que terão acesso externo à aplicação.
Requisitos adicionais Note quaisquer requisitos adicionais de acesso remoto ou segurança que devem ser considerados para a publicação da aplicação.

Pode descarregar esta folha de cálculo de inventário de aplicações para inventariar as suas aplicações.

Definir requisitos organizacionais

Seguem-se áreas para as quais deve definir os requisitos de negócio da sua organização. Cada área contém exemplos de requisitos

Acesso

  • Os utilizadores remotos com dispositivos ligados ao domínio ou a Azure AD podem aceder de forma segura às aplicações publicadas com um único sign-on sem emenda (SSO).

  • Os utilizadores remotos com dispositivos pessoais aprovados podem aceder de forma segura às aplicações publicadas desde que estejam inscritos no MFA e tenham registado a aplicação Microsoft Authenticator no seu telemóvel como um método de autenticação.

Governação

  • Os administradores podem definir e monitorizar o ciclo de vida das atribuições dos utilizadores às aplicações publicadas através Proxy de Aplicações.

Segurança

  • Apenas os utilizadores atribuídos a aplicações através de membros do grupo ou individualmente podem aceder a essas aplicações.

Desempenho

  • Não existe uma degradação do desempenho da aplicação em comparação com o acesso à aplicação da rede interna.

Experiência do Utilizador

  • Os utilizadores estão cientes de como aceder às suas aplicações utilizando URLs familiares da empresa em qualquer plataforma do dispositivo.

Auditoria

  • Os administradores são capazes de auditar a atividade de acesso ao utilizador.

Melhores práticas para um piloto

Determine o tempo e esforço necessários para encomendar plenamente um único pedido de acesso remoto com um único sign-on (SSO). Faça-o executando um piloto que considere a sua descoberta inicial, publicação e testes gerais. A utilização de uma simples aplicação web baseada no IIS que já está pré-configurada para a autenticação integrada Windows (IWA) ajudaria a estabelecer uma linha de base, uma vez que esta configuração requer o mínimo esforço para pilotar com sucesso o acesso remoto e sSO.

Os seguintes elementos de design devem aumentar o sucesso da sua implementação piloto diretamente num inquilino de produção.

Gestão do conector:

  • Os conectores desempenham um papel fundamental no fornecimento do canal no local para as suas aplicações. A utilização do grupo de conector Padrão é adequada para os testes piloto iniciais das aplicações publicadas antes de as encomendarem para a produção. As aplicações testadas com sucesso podem ser transferidas para grupos de conectores de produção.

Gestão de aplicações:

  • A sua força de trabalho é mais provável que se lembre de que uma URL externa é familiar e relevante. Evite publicar a sua aplicação utilizando os nossos msappproxy.net ou sufixos de onmicrosoft.com pré-definidos. Em vez disso, forneça um domínio verificado de nível superior familiar, prefixado com um nome de hospedeiro lógico, como intranet.<>customers_domain.com.

  • Restringir a visibilidade do ícone da aplicação piloto a um grupo piloto escondendo o seu ícone de lançamento forma o portal Azure MyApps. Quando estiver pronto para a produção, pode estender a app ao seu respetivo público-alvo, quer no mesmo inquilino de pré-produção, quer publicando também a aplicação no seu arrendatário de produção.

Definições únicas de sinal de inscrição: Algumas definições de SSO têm dependências específicas que podem levar tempo a configurar, por isso evitem os atrasos de controlo de alterações, garantindo que as dependências são abordadas com antecedência. Isto inclui anfitriões de conector de ligação de domínio para executar SSO usando Kerberos Constrained Delegação (KCD) e cuidar de outras atividades demoradas. Por exemplo, configurar uma instância de acesso ping, se precisar de SSO baseado em cabeçalho.

TLS Entre o anfitrião do conector e a aplicação do alvo: A segurança é fundamental, pelo que o TLS entre o anfitrião do conector e as aplicações-alvo devem ser sempre utilizados. Especialmente se a aplicação web for configurada para a autenticação baseada em formulários (FBA), uma vez que as credenciais de utilizador são efetivamente transmitidas em texto claro.

Implemente incrementalmente e teste cada passo. Realizar testes funcionais básicos após a publicação de uma aplicação para garantir que todos os requisitos de utilizador e negócio são cumpridos seguindo as instruções abaixo:

  1. Teste e valide o acesso geral à aplicação web com pré-autenticação desativada.
  2. Se for bem sucedido, ative a pré-autenticação e atribua utilizadores e grupos. Teste e valida o acesso.
  3. Em seguida, adicione o método SSO para a sua aplicação e teste novamente para validar o acesso.
  4. Aplicar as políticas de Acesso Condicional e MFA conforme necessário. Teste e valida o acesso.

Ferramentas de resolução de problemas: Quando resolver problemas, comece sempre por validar o acesso à aplicação publicada do navegador no anfitrião do conector e confirme que a aplicação funciona como esperado. Quanto mais simples for a sua configuração, mais fácil de determinar a causa raiz, por isso considere tentar reproduzir problemas com uma configuração mínima, como usar apenas um conector e nenhum SSO. Em alguns casos, ferramentas de depuração web como o Fiddler de Telerik podem revelar-se indispensáveis para resolver problemas de acesso ou problemas de conteúdo em aplicações acedidas através de um proxy. O Fiddler também pode atuar como um proxy para ajudar a rastrear e depurar tráfego para plataformas móveis como iOS e Android, e praticamente qualquer coisa que possa ser configurada para ser encaminhado através de um proxy. Consulte o guia de resolução de problemas para obter mais informações.

Implementar a sua solução

Implementar Proxy de Aplicações

As etapas para implantar o seu Proxy de Aplicações estão abrangidas por este tutorial para adicionar uma aplicação no local para acesso remoto. Se a instalação não for bem sucedida, selecione a Resolução de Problemas Proxy de Aplicações no portal ou utilize o guia de resolução de problemas para problemas com a instalação do conector Proxy de Aplicações agente.

Publicar aplicações através do Proxy de Aplicações

As aplicações de publicação assumem que satisfez todos os requisitos prévios e que tem vários conectores que aparecem como registados e ativos na página Proxy de Aplicações.

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

Abaixo estão algumas das melhores práticas a seguir ao publicar uma aplicação:

  • Utilizar grupos de conector: Atribuir um grupo de conector que tenha sido designado para a publicação de cada aplicação. Recomendamos que cada grupo de conector tenha pelo menos dois conectores para fornecer alta disponibilidade e escala. Ter três conectores é ótimo no caso de precisar de servir uma máquina em qualquer ponto. Além disso, consulte publicar aplicações em redes e locais separados utilizando grupos de conector para ver como também pode utilizar grupos de conector para segmentar os seus conectores por rede ou localização.

  • Definir tempo de aplicação backend: Esta definição é útil em cenários onde a aplicação pode exigir mais de 75 segundos para processar uma transação de cliente. Por exemplo, quando um cliente envia uma consulta para uma aplicação web que funciona como uma extremidade frontal para uma base de dados. A frontal parte envia esta consulta para o seu servidor de base de dados de back-end e aguarda uma resposta, mas quando recebe uma resposta, o lado cliente do tempo de conversação acaba. Definir o tempo limite para Long fornece 180 segundos para que as transações mais longas completem.

  • Utilize tipos de cookies apropriados

    • Cookie HTTP-Only: Fornece segurança adicional ao ter Proxy de Aplicações incluir a bandeira HTTPOnly em cabeçalhos de resposta HTTP set-cookie. Esta definição ajuda a mitigar explorações como scripts cross-site (XSS). Deixe este conjunto para O para clientes/agentes do utilizador que requerem acesso ao cookie da sessão. Por exemplo, o cliente RDP/MTSC conecta-se a um Gateway de Desktop Remoto publicado via App Proxy.

    • Cookie Seguro: Quando um cookie é definido com o atributo Secure, o agente do utilizador (app do lado do cliente) só incluirá o cookie em pedidos HTTP se o pedido for transmitido através de um canal protegido TLS. Isto ajuda a mitigar o risco de um cookie ser comprometido através de canais de texto claros, pelo que deve ser ativado.

    • Cookie Persistente: Permite que o cookie de sessão Proxy de Aplicações permaneça entre os fechos do navegador permanecendo válido até que expire ou seja eliminado. Utilizado para cenários em que uma aplicação rica como o office acede a um documento dentro de uma aplicação web publicada, sem que o utilizador seja re-solicitado para a autenticação. No entanto, permita com cuidado, uma vez que os cookies persistentes podem, em última análise, deixar um serviço em risco de acesso não autorizado, se não forem utilizados em conjunto com outros controlos compensatórios. Esta definição só deve ser usada para aplicações mais antigas que não possam partilhar cookies entre processos. É melhor atualizar a sua aplicação para lidar com cookies de partilha entre processos em vez de usar esta definição.

  • Traduzir URLs em Cabeçalhos: Você permite isto para cenários onde DNS interno não pode ser configurado para combinar com o espaço de nome público da organização (também conhecido como DNS Split). A menos que a sua aplicação exija o cabeçalho de anfitrião original no pedido do cliente, deixe este valor definido para Sim. A alternativa é fazer com que o conector utilize o FQDN no URL interno para encaminhamento do tráfego real, e o FQDN no URL externo, como cabeçalho do hospedeiro. Na maioria dos casos, esta alternativa deve permitir que a aplicação funcione normalmente, quando acedida remotamente, mas os seus utilizadores perdem os benefícios de ter um URL externo & correspondente.

  • Traduzir URLs no Corpo de Aplicação: Ligue a tradução do link do Corpo de Aplicação para uma aplicação quando pretender que os links dessa aplicação sejam traduzidos em respostas ao cliente. Se ativada, esta função proporciona uma melhor tentativa de esforço para traduzir todas as ligações internas que a App Proxy encontra nas respostas HTML e CSS sendo devolvidas aos clientes. É útil na publicação de apps que contenham ligações de nome absoluto ou NetBIOS codificadas no conteúdo, ou aplicações com conteúdo que se liga a outras aplicações no local.

Para cenários em que uma aplicação publicada se ligue a outras aplicações publicadas, permita a tradução de links para cada aplicação para que tenha controlo sobre a experiência do utilizador ao nível das aplicações.

Por exemplo, suponha que tem três aplicações publicadas através de Proxy de Aplicações que todas se ligam entre si: Benefícios, Despesas e Viagem, além de uma quarta aplicação, Feedback, que não é publicada através de Proxy de Aplicações.

Picture 1

Quando permite a tradução de links para a aplicação Benefits, as ligações a Despesas e Viagens são redirecionadas para os URLs externos para essas aplicações, para que os utilizadores que acedam às aplicações de fora da rede corporativa possam aceder às suas aplicações. As ligações entre despesas e viagens de volta a Benefícios não funcionam porque a tradução de links não foi ativada para essas duas aplicações. O link para feedback não é redirecionado porque não existe URL externo, pelo que os utilizadores que usam a aplicação Benefits não poderão aceder à aplicação de feedback de fora da rede corporativa. Consulte informações detalhadas sobre a tradução de ligações e outras opções de redirecionamento.

Aceda à sua aplicação

Existem várias opções para gerir o acesso aos recursos publicados do Proxy de Aplicações, portanto deve escolher o mais adequado para as necessidades de escalabilidade e do cenário. As abordagens comuns incluem: usar grupos no local que estão a ser sincronizados através do Azure AD Ligação, criar Grupos Dinâmicos em AZure AD com base em atributos do utilizador, utilizando grupos de self-service que são geridos por um proprietário de recursos, ou uma combinação de todos eles. Consulte os recursos ligados para os benefícios de cada um.

A forma mais direta de atribuir aos utilizadores o acesso a uma aplicação está a ir para as opções de Utilizadores e Grupos a partir do painel esquerdo da sua aplicação publicada e atribuir diretamente grupos ou indivíduos.

Picture 24

Também pode permitir que os utilizadores tenham acesso ao seu serviço de autosserviço à sua aplicação, atribuindo um grupo do qual não são atualmente membros e configurando as opções de autosserviço.

Picture 25

Se estiverem ativados, os utilizadores poderão então entrar no portal myApps e solicitar acesso, e ser automaticamente aprovado e adicionado ao grupo de self-service já autorizado, ou precisar da aprovação de um aprovador designado.

Os utilizadores convidados também podem ser convidados a aceder a aplicações internas publicadas através de Proxy de Aplicações através do Azure AD B2B.

Para aplicações que normalmente são acessíveis de forma anónima, não requerendo nenhuma autenticação, pode preferir desativar a opção localizada nas Propriedades da aplicação.

Picture 26

Deixar esta opção definida para Não permite que os utilizadores acedam à aplicação no local através da App AD App Proxy Azure sem permissões, por isso use com cuidado.

Uma vez publicada a sua aplicação, deve ser acessível digitando o seu URL externo num browser ou pelo seu ícone em https://myapps.microsoft.com.

Ativar a pré-autenticação

Verifique se a sua aplicação está acessível através Proxy de Aplicações aceder-lhe através do URL externo.

  1. Navegue para Azure Ative Directory>Enterprise aplicações>Todas as aplicações e escolha a app que pretende gerir.

  2. Selecione Proxy de Aplicações.

  3. No campo pré-autenticação, utilize a lista de dropdown para selecionar Azure Ative Directory e selecione Guardar.

Com a pré-autenticação ativada, o Azure AD irá desafiar os utilizadores primeiro para a autenticação e se a única súbton estiver configurada, a aplicação back-end também verificará o utilizador antes de o acesso à aplicação ser concedido. A alteração do modo de pré-autenticação de Passthrough para AZure AD também configura o URL externo com HTTPS, pelo que qualquer aplicação inicialmente configurada para HTTPS será agora assegurada com HTTPS.

Ativar Sign-On individuais

O SSO fornece a melhor experiência e segurança possível do utilizador, porque os utilizadores só precisam de iniciar sação uma vez ao aceder ao Azure AD. Uma vez que um utilizador tenha pré-autenticado, o SSO é realizado pelo conector Proxy de Aplicações autenticando a aplicação no local, em nome do utilizador. A aplicação backend processa o login como se fosse o próprio utilizador.

A escolha da opção Passthrough permite que os utilizadores acedam à aplicação publicada sem nunca terem de autenticar a AZure AD.

A realização de SSO só é possível se o Azure AD conseguir identificar o utilizador que solicita o acesso a um recurso, pelo que a sua aplicação deve ser configurada para pré-autenticar os utilizadores com Azure AD no acesso ao SSO para funcionar, caso contrário as opções SSO serão desativadas.

Leia o único sinal de inscrição nas aplicações em Azure AD para ajudá-lo a escolher o método SSO mais adequado ao configurar as suas aplicações.

Trabalhar com outros tipos de aplicações

O Azure AD Proxy de Aplicações também pode suportar aplicações que tenham sido desenvolvidas para utilizar a Biblioteca de Autenticação do Microsoft (MSAL). Suporta aplicações de clientes nativos consumindo fichas emitidas pela Azure AD recebidas na informação de cabeçalho do pedido do cliente para realizar a pré-autenticação em nome dos utilizadores.

Leia a publicação de aplicações de clientes nativos e móveis e aplicações baseadas em sinistros para saber sobre as configurações disponíveis de Proxy de Aplicações.

Utilizar acesso condicional para reforçar a segurança

A segurança da aplicação requer um conjunto avançado de capacidades de segurança que podem proteger e responder a ameaças complexas no local e na nuvem. Os atacantes obtêm mais frequentemente acesso à rede corporativa através de credenciais de utilizador fracas, padrão ou roubadas. A segurança baseada na identidade da Microsoft reduz o uso de credenciais roubadas gerindo e protegendo identidades privilegiadas e não privilegiadas.

As seguintes capacidades podem ser usadas para suportar Proxy de Aplicações AZure AD:

  • Acesso Condicional baseado no utilizador e na localização: Mantenha dados sensíveis protegidos limitando o acesso do utilizador com base na geolocalização ou num endereço IP com políticas de Acesso Condicional baseadas na localização.

  • Acesso Condicional baseado no dispositivo: Garantir que apenas dispositivos matriculados, aprovados e compatíveis podem aceder a dados corporativos com acesso condicional baseado no dispositivo.

  • Acesso Condicional baseado em aplicações: O trabalho não tem de parar quando um utilizador não está na rede corporativa. Acesso seguro a aplicativos de nuvem corporativa e no local e manter o controlo com acesso condicional.

  • Acesso Condicional baseado em risco: Proteja os seus dados de hackers maliciosos com uma política de acesso condicional baseada no risco que pode ser aplicada a todas as aplicações e a todos os utilizadores, seja no local ou na nuvem.

  • Azure AD As Minhas Aplicações: Com o seu serviço Proxy de Aplicações implementado, e aplicações publicadas de forma segura, oferecem aos seus utilizadores um simples hub para descobrir e aceder a todas as suas aplicações. Aumentar a produtividade com capacidades de self-service, como a capacidade de solicitar o acesso a novas apps e grupos ou gerir o acesso a esses recursos em nome de outras pessoas, através de As Minhas Aplicações.

Gerir a sua implementação

Funções necessárias

A Microsoft defende o princípio de conceder o mínimo privilégio possível para executar as tarefas necessárias com a Azure AD. Reveja as diferentes funções do Azure que estão disponíveis e escolha a certa para responder às necessidades de cada persona. Algumas funções podem ter de ser aplicadas temporariamente e removidas após a colocação concluída.

Papel de negócio Tarefas empresariais Funções do Azure AD
Administração de mesa de ajuda Normalmente limitado a problemas de desempenho qualificados do utilizador final e executando tarefas limitadas, como alterar as palavras-passe dos utilizadores, invalidar tokens de atualização e monitorizar a saúde do serviço. Administrador helpdesk
Administrador de identidade Leia o sinal de Azure AD em relatórios e registos de auditoria para depurar problemas relacionados com a App Proxy. Leitor de segurança
Proprietário de aplicação Criar e gerir todos os aspetos das aplicações empresariais, registos de candidaturas e configurações de procuração de aplicações. Administrador de Aplicação
Administração de infraestruturas Proprietário de capotamento de certificado Administrador de 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 malicioso obter acesso não autorizado, ou um utilizador autorizado a afetar inadvertidamente um recurso sensível.

No entanto, os utilizadores ainda precisam de realizar operações privilegiadas diárias, pelo que a aplicação de políticas de Privileged Identity Management baseadas no tempo (JIT) para proporcionar acesso privilegiado a pedido aos recursos Azure e a Azure AD é a nossa abordagem recomendada para gerir eficazmente o acesso administrativo e a auditoria.

Relatórios e monitorização

A Azure AD fornece informações adicionais sobre o uso da aplicação da sua organização e saúde operacional através de registos e relatórios de auditoria. Proxy de Aplicações também facilita o controlo dos conectores a partir do portal AD AD E Windows registos de eventos.

Registos de auditoria de aplicação

Estes registos fornecem informações detalhadas sobre logins a aplicações configuradas com Proxy de Aplicações e o dispositivo e o utilizador que acede à aplicação. Os registos de auditoria estão localizados no portal do Azure e na API de Auditoria para exportação. Além disso, os relatórios de utilização e insights também estão disponíveis para a sua aplicação.

Proxy de Aplicações monitorização do conector

Os conectores e o serviço cuidam de todas as tarefas de alta disponibilidade. Pode monitorizar o estado dos seus conectores a partir da página Proxy de Aplicações no Portal AD Azure. Para obter mais informações sobre a manutenção do conector consulte Understand Azure AD Proxy de Aplicações Connectors.

Example: Azure AD Application Proxy connectors

Windows registos de eventos e contadores de desempenho

Os conectores têm registos de administração e de sessão. Os registos de administração incluem eventos-chave e os seus erros. Os registos da sessão incluem todas as transações e os seus dados de processamento. Os registos e balcões estão localizados em Windows Registos de Eventos para obter mais informações consulte Understand Azure AD Proxy de Aplicações Connectors. Siga este tutorial para configurar fontes de dados de registo de eventos no Azure Monitor.

Guia e passos de resolução de problemas

Saiba mais sobre questões comuns e como resolvê-las com o nosso guia para resolver mensagens de erro.

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