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

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

Como as aplicações seguras são essenciais para a organização, qualquer indisponibilidade dessas aplicações devido a problemas de segurança pode afetar a empresa ou algum serviço crítico do qual a empresa dependa. Por isso, é importante alocar tempo e recursos para garantir que os aplicativos permaneçam sempre em um estado saudável e seguro. Efetue uma avaliação periódica de segurança e estado de funcionamento de aplicações, de forma muito semelhante a uma avaliação de modelo de ameaças 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 da aplicação

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 (secrets):

• 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 a recência de utilização e a sua validade. Uma credencial não utilizada numa aplicação pode resultar numa violação de segurança. Altere as credenciais com frequência e não partilhe credenciais entre aplicações. Não tenha muitas credenciais numa aplicação.
• Monitorize os seus pipelines de produção para evitar que credenciais de qualquer tipo sejam incluídas num commit 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 a aplicação no portal do Azure, uma plataforma deve ser selecionada para a aplicação e, em seguida, a propriedade URI de redirecionamento pode ser definida.

Considere as seguintes orientações para URIs de redirecionamento:

• 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 com caráteres universais ou esquemas de URI inseguros, como http ou URN.
• Mantenha a lista pequena. Remova 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 Auth code flow 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 de ID da Aplicação da aplicação especifica o URI globalmente exclusivo usado para identificar a API 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 a aplicação no portal do Azure, a propriedade URI de ID da Aplicação 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 aplicação baseados nos esquemas API e HTTP são suportados. Substitua os valores de espaço reservado conforme descrito na lista a seguir à tabela.

• <appId> - A propriedade identificador da aplicação (appId) do objeto de aplicação.
• <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 inquilino no Azure.
• <tenantInitialDomain> - <tenantInitialDomain.onmicrosoft.com, onde tenantInitialDomain é 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 o seu inquilino 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. Isto é especialmente crítico para aplicações multicliente, mas aplicações single-tenant também devem usar bloqueio de instância de aplicação para proteger as suas propriedades sensíveis.

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 da aplicação

Os proprietários podem gerir todos os aspetos de uma aplicação registada. É importante rever regularmente a titularidade de todas as aplicações na organização. Para obter mais informações, consulte revisões de acesso do Microsoft Entra. Em Owners da aplicação no portal do Azure, os proprietários da aplicação podem ser geridos.

Considere as seguintes orientações relacionadas com a especificação de proprietários de aplicações:

• 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 devam continuar a ser proprietários de uma aplicação.

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. Estas recomendações ajudam a garantir que o seu inquilino esteja num estado seguro e íntegro, ao mesmo tempo que ajudam a maximizar o valor das funcionalidades 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.