Práticas recomendadas de segurança das propriedades dos aplicativos na ID do Microsoft Entra

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

Como aplicativos seguros são essenciais para a organização, qualquer tempo de inatividade para eles devido a problemas de segurança pode afetar a empresa ou algum serviço crítico do qual a empresa depende. Portanto, é importante separar tempo e recursos para garantir que os aplicativos permaneçam sempre em um estado íntegro e seguro. Realize uma avaliação periódica de segurança e de integridade dos seus aplicativos, assim como uma avaliação do Modelo de ameaça de segurança para o código. Para ter uma perspectiva mais ampla sobre a segurança para organizações, confira o SDL (ciclo de vida de desenvolvimento de segurança).

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

• 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 de Instância do aplicativo
• Propriedade do aplicativo

Tipo de identidade

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

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

• O serviço é executado na nuvem do Azure
• O aplicativo não precisa conectar usuários
• O aplicativo não precisa atuar como o recurso em um fluxo de token (não é uma API 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 aplicativo 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 diretrizes 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 diretrizes para configurar uma identidade gerenciada como uma credencial. No entanto, essa opção só poderá ser possível se o serviço em que o aplicativo for 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 configurada como uma credencial.
• Se não for possível usar uma identidade gerenciada ou outro provedor de identidade externo seguro, use as credenciais de certificado. Não use credenciais de senha, também conhecidas como segredos. Embora seja conveniente usar segredos de senha como uma credencial, as credenciais de senha geralmente são mal gerenciadas e podem ser facilmente comprometidas.
• Se um certificado precisar ser usado em vez de uma identidade gerenciada, armazene esse certificado em um cofre de chaves seguro, como o Azure Key Vault.
• Se um certificado precisar ser usado em vez de uma identidade gerenciada, use um certificado de uma AC (autoridade de certificação) confiável em vez de um certificado autoassinado. Configure uma política para impor que os certificados venham de emissores confiáveis. No entanto, se o uso de uma AC confiável não for possível, os certificados autoassinados ainda serão preferenciais em vez de senhas.
• Configure políticas de gerenciamento de aplicativos para controlar o uso de segredos, limitando seu período de validade ou bloqueando totalmente seu uso.
• Se um aplicativo for usado apenas como um cliente público ou instalado (por exemplo, aplicativos móveis ou da área de trabalho instalados no computador do usuário final), verifique se não há credenciais especificadas no objeto do aplicativo.
• Revise as credenciais usadas nos aplicativos quanto à atualização de uso e ao vencimento. Uma credencial não usada em um aplicativo pode resultar em violação de segurança. Substitua as credenciais com frequência e não as compartilhe entre aplicativos. Não tenha muitas credenciais em um só aplicativo.
• Monitore seus pipelines de produção para impedir o commit de credenciais de qualquer tipo em repositórios de códigos. O Verificador de Credenciais é uma ferramenta de análise estática que pode ser usado para detectar credenciais (e outros tipos de conteúdo confidenciais) no código-fonte e na saída do build.

URIs de redirecionamento

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

Considere as seguintes diretrizes para URIs de redirecionamento:

• Mantenha a propriedade de todos os URIs. Uma falha na propriedade de um dos URIs de redirecionamento pode levar ao comprometimento do aplicativo.
• Verifique se todos os registros DNS são atualizados e monitorados periodicamente quanto às alterações.
• Não use URLs de resposta curinga ou esquemas de URI não seguros, como HTTP ou URN.
• Mantenha a lista pequena. Corte os URIs desnecessários. Se possível, atualize as URLs de HTTP para HTTPS.

Configuração de fluxo implícito

Os cenários que exigem o fluxo implícito já 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, no aplicativo no portal do Azure, uma plataforma precisa ser selecionada para o aplicativo e a propriedade Tokens de acesso (usada para fluxos implícitos) pode ser definida.

Considere as seguintes diretrizes relacionadas ao fluxo implícito:

• Entenda se o fluxo implícito é necessário. Não use o fluxo implícito, a menos que explicitamente necessário.
• Se o aplicativo foi configurado para receber tokens de acesso usando o fluxo implícito, mas não os usa ativamente, desative a configuração para protegê-lo contra uso indevido.
• Use aplicativos separados para cenários de fluxo implícito válidos.

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 Web. É o prefixo do valor do escopo em solicitações para o Microsoft Entra. Também é o valor da declaração de público-alvo (aud) em tokens de acesso v1.0. Para aplicativos multilocatários, o valor também precisa ser globalmente exclusivo. Ele também é chamado de URI de Identificador. Em Expor uma API, no aplicativo no portal do Azure, a propriedade URI da ID do Aplicativo pode ser definida.

As práticas recomendadas para definir o URI da ID do Aplicativo serão alteradas dependendo se o aplicativo for emitido com tokens de acesso v1.0 ou v2.0. Se você não tem certeza se um aplicativo recebe tokens de acesso v1.0, verifique o requestedAccessTokenVersion do manifesto do aplicativo. 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 as URIs padrão devem ser usadas. 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 impor essa prática recomendada para atualizações futuras para 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 com suporte para evitar colisões de URI na organização. Não use curingas.
• Use um domínio verificado da sua organização.
• Mantenha um inventário das URIs na organização para ajudar a manter a segurança.

Há suporte para os seguintes formatos de URI de ID de aplicativo baseados em esquema HTTP e API. Substitua os valores nos espaços reservados conforme descrito na lista após a tabela.

• <appId> - a propriedade do identificador de aplicativo (appId) do objeto de aplicativo.
• <string> - o valor da cadeia de caracteres do host ou do segmento de linha da AP.
• <tenantId> - um GUID gerado pelo Azure para representar o locatário no Azure.
• <tenantInitialDomain> - <tenantInitialDomain>.onmicrosoft.com, where <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 que foi 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-alvo em tokens de acesso. Os aplicativos de recurso normalmente são APIs Web. Se um aplicativo atua apenas como um cliente (o que significa que ele adquire tokens para enviar para recursos como o Microsoft Graph), essa seção não se aplica.

Os aplicativos de recursos que configuraram URIs de identificador personalizado devem usar o formato v2.0 de token de acesso. Para verificar se um aplicativo deve usar tokens de acesso v2.0, examine a propriedade identifierUris na página de manifesto de registros do aplicativo.

Se houver algum valor configurado lá não no formato api://{appId} ou api://{tenantId}/{appId}, em seguida, o aplicativo deverá 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 recebida pelo aplicativo 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 sua appId.

Bloqueio de propriedade da instância do aplicativo

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. Isso é verdadeiro, independentemente de esse locatário ser o locatário residencial do aplicativo ou um locatário 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, as credenciais podem ser adicionadas ao principal de serviço, embora normalmente sejam 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. Configurar essa propriedade é especialmente essencial para aplicativos multilocatários - ou seja, aplicativos usados em vários locatários ou organizações - mas pode e deve ser definido por todos os aplicativos.

Permissões

Talvez seu aplicativo precise receber permissões para acessar recursos protegidos ou APIs. Ao solicitar permissões, sempre verifique o seguinte:

• Siga os princípios de privilégio mínimo . Solicite apenas a permissão que concede o acesso menos permissivo necessário para executar a ação que o aplicativo precisa executar. Se você estiver chamando o Microsoft Graph, use a documentação da API para identificar a permissão com menos permissões para uma determinada chamada à API. Examine periodicamente as permissões do aplicativo para verificar se uma opção menos privilegiada está disponível. 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 ao aplicativo.
• 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 aspectos de um aplicativo registrado. É importante revisar 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, no aplicativo no portal do Azure, os proprietários do aplicativo podem ser gerenciados.

Considere as seguintes diretrizes relacionadas à especificação de proprietários de aplicativos:

• A propriedade do aplicativo deve ser mantida com um conjunto mínimo de pessoas na organização.
• Um administrador deve revisar a lista de proprietários em intervalos de alguns meses para verificar se os proprietários ainda fazem parte da organização e ainda devem ser proprietários de um aplicativo.

Verificar 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. Estas recomendações ajudam a garantir a segurança e integridade do locatário enquanto também ajudam a maximizar o valor dos recursos disponíveis no Microsoft Entra ID. Examine periodicamente as recomendações ativas do Microsoft Entra que pertencem às propriedades do aplicativo ou à configuração do aplicativo para manter o ecossistema do aplicativo em um estado íntegro.