Práticas recomendadas de segurança para propriedades de aplicativos no Microsoft Entra ID

A segurança é um conceito importante ao registrar um aplicativo no Microsoft Entra ID e é uma parte crítica de seu uso comercial na organização. Qualquer configuração incorreta de um aplicativo pode resultar em tempo de inatividade ou comprometimento. Dependendo das permissões adicionadas a um aplicativo, pode haver efeitos em toda a organização.

Como os aplicativos seguros são essenciais para a organização, qualquer tempo de inatividade devido a problemas de segurança pode afetar os negócios ou algum serviço crítico do qual os negócios dependam. Por isso, é importante alocar tempo e recursos para garantir que os aplicativos permaneçam sempre em um estado saudável e seguro. Realize uma avaliação periódica de segurança e integridade de aplicativos, de forma muito semelhante a uma avaliação de Modelo de Ameaça de Segurança para código. Para obter uma perspetiva mais ampla sobre segurança para organizações, consulte o ciclo de vida de desenvolvimento de segurança (SDL).

Este artigo descreve as práticas recomendadas de segurança para as seguintes propriedades e cenários de aplicativos:

• Tipo de identidade
• Credenciais
• URIs de Redirecionamento
• Configuração de fluxo implícito
• URI da ID do aplicativo (também conhecido como URI do identificador)
• Versão do token de acesso
• Bloqueio da instância do aplicativo
• Propriedade do aplicativo

Tipo de identidade

É provável que você esteja aqui para aprender sobre as práticas recomendadas de segurança para aplicativos Microsoft Entra - também conhecidos como registros de aplicativos ou objetos de aplicativos. No entanto, há outro tipo de identidade que pode ser usado para acessar recursos protegidos por Entra, chamados identidades gerenciadas para recursos do Azure.

As identidades gerenciadas do Azure são seguras por padrão e exigem pouca ou nenhuma manutenção contínua ou sobrecarga. Considere usar uma identidade gerenciada em vez de um aplicativo Microsoft Entra para sua identidade de aplicativo se todas as seguintes condições forem verdadeiras:

• O serviço é executado na nuvem do Azure
• A aplicação não precisa que os utilizadores iniciem sessão
• O aplicativo não precisa atuar como o recurso em um fluxo de token (não é uma API da Web)
• O aplicativo não precisa operar em vários locatários

O restante deste artigo aborda as práticas recomendadas de segurança para propriedades de registros de aplicativos do Entra.

Credenciais (incluindo certificados e segredos)

As credenciais são uma parte vital de um aplicativo quando ele é usado como um cliente confidencial. Na página Certificados e segredos do aplicativo no portal do Azure, as credenciais podem ser adicionadas ou removidas.

Considere as seguintes orientações relacionadas a certificados e segredos:

• Use uma identidade gerenciada como uma credencial sempre que possível. Isso é altamente recomendado, pois as identidades gerenciadas são a opção mais segura e não exigem nenhum gerenciamento contínuo de credenciais. Siga estas orientações para configurar uma identidade gerenciada como uma credencial. No entanto, essa opção só pode ser possível se o serviço no qual o aplicativo é usado for executado no Azure.
• Se o serviço no qual o aplicativo é usado não for executado no Azure, mas for executado em outra plataforma que ofereça gerenciamento automatizado de credenciais, considere usar uma identidade dessa plataforma como uma credencial. Por exemplo, um fluxo de trabalho de ações do GitHub pode ser configurado como uma credencial, eliminando a necessidade de gerenciar e proteger credenciais para o pipeline de ações do GitHub. Tenha cuidado com essa abordagem e configure apenas credenciais federadas de plataformas em que você confia. Um aplicativo é tão seguro quanto a plataforma de identidade que configurou como uma credencial.
• Se não for possível usar uma identidade gerenciada ou outro provedor de identidade externo seguro, use credenciais de certificado. Não use credenciais de senha, também conhecidas como segredos. Embora seja conveniente usar segredos de senha como credencial, as credenciais de senha geralmente são mal gerenciadas e podem ser facilmente comprometidas.
• Se for necessário usar um certificado em vez de uma identidade gerenciada, armazene esse certificado em um cofre de chaves seguro, como o Cofre de Chaves do Azure.
• Se for necessário usar um certificado em vez de uma identidade gerenciada, use um certificado de uma autoridade de certificação (CA) confiável em vez de um certificado autoassinado. Configure uma política para impor que os certificados vêm de emissores confiáveis. No entanto, se não for possível usar uma autoridade de certificação confiável, os certificados autoassinados ainda serão preferidos em relação às senhas.
• Configure políticas de gerenciamento de aplicativos para controlar o uso de segredos, limitando sua vida útil ou bloqueando completamente seu uso.
• Se um aplicativo for usado apenas como um cliente público ou instalado (por exemplo, aplicativos móveis ou de desktop instalados na máquina do usuário final), verifique se não há credenciais especificadas no objeto do aplicativo.
• Analise as credenciais usadas em aplicativos para verificar se há atualização de uso e sua validade. Uma credencial não utilizada em um aplicativo pode resultar em uma violação de segurança. Sobreponha credenciais com frequência e não compartilhe credenciais entre aplicativos. Não tenha muitas credenciais em um aplicativo.
• Monitore seus pipelines de produção para evitar que credenciais de qualquer tipo sejam confirmadas em repositórios de código. O Credential Scanner é uma ferramenta de análise estática que pode ser usada para detetar credenciais (e outros conteúdos confidenciais) no código-fonte e na saída da compilação.

URIs de Redirecionamento

É importante manter os URIs de redirecionamento do seu aplicativo atualizados. Em Autenticação para o aplicativo no portal do Azure, uma plataforma deve ser selecionada para o aplicativo e, em seguida, a propriedade URI de redirecionamento pode ser definida.

Considere as seguintes orientações para redirecionar URIs:

• Mantenha a propriedade de todos os URIs. Um lapso na propriedade de um dos URIs de redirecionamento pode levar ao comprometimento do aplicativo.
• Certifique-se de que todos os registos DNS são atualizados e monitorizados periodicamente em busca de alterações.
• Não use URLs de resposta curinga ou esquemas de URI inseguros, como http ou URN.
• Mantenha a lista pequena. Corte todos os URIs desnecessários. Se possível, atualize URLs de Http para Https.

Configuração de fluxo implícito

Os cenários que exigiam fluxo implícito agora podem usar o fluxo de código de autenticação para reduzir o risco de comprometimento associado ao uso indevido do fluxo implícito. Em Autenticação para o aplicativo no portal do Azure, uma plataforma deve ser selecionada para o aplicativo e, em seguida, a propriedade Tokens de acesso (usados para fluxos implícitos) pode ser definida.

URI da ID do aplicativo (também conhecido como URI do identificador)

A propriedade URI da ID do aplicativo especifica o URI globalmente exclusivo usado para identificar a API da Web. É o prefixo para o valor do escopo em solicitações ao Microsoft Entra. É também o valor da declaração de audiência (aud) em tokens de acesso v1.0. Para aplicações multilocatário, o valor também deve ser exclusivo a nível global. Também é conhecido como um URI de identificador de . Em Expor uma API para o aplicativo no portal do Azure, a propriedade URI da ID do Aplicativo pode ser definida.

As práticas recomendadas para definir a alteração do URI da ID do aplicativo, dependendo se o aplicativo recebe tokens de acesso v1.0 ou v2.0. Caso não tenhas a certeza se uma aplicação emite tokens de acesso v1.0, verifica o requestedAccessTokenVersion do manifesto da aplicação . Um valor de null ou 1 indica que o aplicativo recebe tokens de acesso v1.0. Um valor de 2 indica que o aplicativo recebe tokens de acesso v2.0.

Para aplicativos que são emitidos tokens de acesso v1.0, somente os URIs padrão devem ser usados. Os URIs padrão são api://<appId> e api://<tenantId>/<appId>. - Configure a nonDefaultUriAddition restrição nas políticas de gerenciamento de aplicativos para aplicar essa prática recomendada para futuras atualizações de aplicativos em sua organização.

Para aplicativos que são emitidos tokens de acesso v2.0, use as seguintes diretrizes ao definir o URI da ID do aplicativo:

• Os esquemas de URI api ou https são recomendados. Defina a propriedade nos formatos suportados para evitar colisões de URI em sua organização. Não use curingas.
• Use um domínio verificado da sua organização.
• Mantenha um inventário dos URIs em sua organização para ajudar a manter a segurança.

Os seguintes formatos de URI de ID de aplicativo baseados em esquema API e HTTP são suportados. Substitua os valores de espaço reservado conforme descrito na lista a seguir à tabela.

• <appId> - A propriedade application identifier (appId) do objeto do aplicativo.
• <string> - O valor da cadeia de caracteres para o host ou o segmento do caminho da api.
• <tenantId> - Um GUID gerado pelo Azure para representar o locatário no Azure.
• < > , onde - < é o nome de domínio inicial que o criador do locatário especificou na criação do locatário.
• <verifiedCustomDomain> - Um domínio personalizado verificado configurado para seu locatário do Microsoft Entra.

Versão do token de acesso

Esta seção só é aplicável a aplicativos de recursos - ou seja, aplicativos que atuam como o público em tokens de acesso. Os aplicativos de recursos geralmente são APIs da Web. Se um aplicativo atuar apenas como um cliente (o que significa que ele adquire tokens para enviar para recursos como o Microsoft Graph), esta seção não se aplica.

Os aplicativos de recursos que configuraram URIs de identificador personalizado devem usar o formato de token de acesso v2.0. Para verificar se uma aplicação deve usar tokens de acesso v2.0, examine a identifierUris propriedade na página de manifesto de registos de aplicações da aplicação.

Se houver algum valor configurado lá não no formato api://{appId} ou api://{tenantId}/{appId}, então o aplicativo deve usar tokens de acesso v2.0.

Para atualizar para tokens de acesso v2.0, primeiro verifique se o aplicativo pode lidar com declarações de token v2.0. Em seguida, atualize a versão do token de acesso emitido para a aplicação, usando o editor de manifesto.

Depois que a configuração do aplicativo tiver sido atualizada para usar tokens v2.0, verifique se a lógica de validação de audiência do aplicativo é modificada para aceitar apenas seu appId.

Bloqueio de propriedade da instância da aplicação

Quando um aplicativo tem uma entidade de serviço provisionada em um locatário, essa entidade de serviço pode ser personalizada por um administrador de locatário. Isto é verdade independentemente de esse inquilino ser o inquilino do aplicativo ou um inquilino estrangeiro. Essas habilidades de personalização podem permitir modificações que o proprietário do aplicativo não esperava, levando a riscos de segurança. Por exemplo, é possível adicionar credenciais ao principal de serviço, mesmo que geralmente as credenciais devam ser de propriedade e controladas pelo desenvolvedor e proprietário do aplicativo.

Para reduzir esse risco, os aplicativos devem configurar o bloqueio da instância do aplicativo. Ao configurar o bloqueio da instância do aplicativo, sempre bloqueie todas as propriedades confidenciais disponíveis. A configuração dessa propriedade é especialmente crítica para aplicativos multilocatários - ou seja, aplicativos usados em vários locatários ou organizações - mas pode e deve ser definida por todos os aplicativos.

Permissões

Seu aplicativo pode precisar receber permissões para acessar recursos protegidos ou APIs. Ao solicitar permissões, certifique-se sempre do seguinte:

• Siga os princípios de privilégios mínimos . Solicite apenas a permissão que concede o acesso menos permissivo necessário para executar a ação que o aplicativo precisa executar. Se estiver chamando o Microsoft Graph, use a documentação da API para identificar a permissão menos permissiva para uma determinada chamada de API. Reveja periodicamente as permissões da sua aplicação para verificar se está disponível uma opção menos privilegiada. Se um aplicativo não precisar mais de uma permissão, remova-o.
• Sempre que possível, use o acesso delegado em vez do acesso somente para aplicativos.
• Revise a documentação de permissões e consentimento para garantir que você entenda os fundamentos de permissão.

Configuração de propriedade do aplicativo

Os proprietários podem gerenciar todos os aspetos de um aplicativo registrado. É importante rever regularmente a propriedade de todos os aplicativos na organização. Para obter mais informações, consulte Revisões de acesso do Microsoft Entra. Em Proprietários do aplicativo no portal do Azure, os proprietários do aplicativo podem ser gerenciados.

Considere as seguintes orientações relacionadas à especificação de proprietários de aplicativos:

• A propriedade do aplicativo deve ser mantida para um conjunto mínimo de pessoas dentro da organização.
• Um administrador deve revisar a lista de proprietários uma vez a cada poucos meses para garantir que os proprietários ainda façam parte da organização e ainda devam possuir um aplicativo.

Verifique as recomendações do Entra

O recurso de recomendações do Microsoft Entra ajuda a monitorar o status do seu locatário para que você não precise fazê-lo. Essas recomendações ajudam a garantir que seu locatário esteja em um estado seguro e íntegro, ao mesmo tempo em que ajudam a maximizar o valor dos recursos disponíveis no Microsoft Entra ID. Revise periodicamente todas as recomendações ativas do Microsoft Entra que dizem respeito às propriedades ou à configuração do aplicativo para manter o ecossistema do aplicativo em um estado íntegro.