Desenvolva uma estratégia de permissões de aplicativos

À medida que você aprende a desenvolver usando princípios de Zero Trust, consulte este artigo depois de revisar Adquirir autorização para acessar recursos e Desenvolver estratégia de permissões delegadas. Defina uma abordagem de permissões de aplicativo para o gerenciamento de credenciais ao usar a plataforma de identidade da Microsoft para autenticar e autorizar aplicativos e gerenciar permissões e consentimento.

Quando nenhum usuário está envolvido, você não tem um modelo de permissão efetivo porque seu aplicativo sempre recebe as permissões pré-atribuídas.

• O aplicativo prova que está solicitando permissão. Seu aplicativo comprova sua própria identidade com um dos seguintes métodos:

  • um certificado, a melhor opção, ou
  • um segredo em um sistema de gerenciamento de segredos sofisticado, ou
  • quando estiver desenvolvendo seus serviços no Azure, use Identidades Gerenciadas para recursos do Azure, revise a seguinte seção Gerenciar credenciais de aplicativo.

• O aplicativo sempre requer o prévio consentimento do administrador. Seu aplicativo solicita essa permissão com o escopo .default. Ele solicita as permissões que o administrador atribui ao aplicativo.

• Funcionalidade entre usuários. Por padrão, User.ReadWrite.All permite que seu aplicativo atualize o perfil de cada usuário. Como uma permissão de aplicativo, ela permite que seu aplicativo leia e atualize o perfil de cada usuário no locatário.

• As permissões concedidas ao aplicativo são sempre as usadas. Ao contrário de uma permissão delegada, permissões de aplicativo não são limitadas pelo que qualquer usuário específico pode fazer.

Limitar permissões de aplicativos

Existem três maneiras de limitar um aplicativo a um acesso inferior ao global.

• Aplicativos do Microsoft Teams têm consentimento específico de recurso (RSC), que permite a um aplicativo acessar uma equipe específica em vez de acessar todas as equipes da empresa. O RSC é uma integração do Microsoft Teams e da API do Microsoft Graph que permite ao aplicativo usar pontos de extremidade de API e gerenciar recursos específicos. Seu modelo de permissões permite que os proprietários do Teams e do Chat forneçam consentimento para seu aplicativo acessar e modificar dados do Teams e do Chat.

• Os administradores do Microsoft Exchange podem criar políticas de aplicativo do Exchange para limitar o acesso do aplicativo a caixas de correio específicas com um script do PowerShell. Eles podem limitar um aplicativo específico a caixas de correio específicas com acesso Calendar.Read ou Mail.Read. Como exemplo, isso permite criar uma automação que só pode ler uma caixa de correio ou enviar apenas emails de uma caixa de correio e não de todos na empresa.

• O SharePoint tem Sites.Selected como um escopo específico para dar permissões granulares de acesso ao SharePoint com um aplicativo. Escolher Sites.Selected para seu aplicativo em vez de uma das outras permissões resulta, por padrão, em seu aplicativo não ter acesso a nenhum conjunto de sites do SharePoint. O administrador utiliza o ponto de extremidade de permissões do site para conceder permissões de Leitura, Gravação ou Leitura e Gravação ao seu aplicativo.

Gerenciar credenciais de aplicativos

A higiene das credenciais pode garantir que os aplicativos se recuperem rapidamente de uma possível violação. As práticas recomendadas a seguir orientam você no desenvolvimento de aplicativos que realizam detecção e correção, evitando tempo de inatividade e afetando usuários legítimos. Essas recomendações apoiam o princípio de Confiança Zero de suposta violação, preparando você para responder a um incidente de segurança.

• Remova todos os segredos do código e da configuração. Quando estiver usando a plataforma do Azure, coloque segredos no Cofre de chaves e acesse-os com o uso de Identidades gerenciadas para recursos do Azure. Torne seu código resiliente para lidar com rotações de segredos se houver comprometimento. Administradores de TI podem remover e girar segredos e certificados sem removerem seu aplicativo ou afetar usuários legítimos.

• Utilize certificados no lugar de segredos de clientes, a menos que um processo seguro esteja em vigor para gerenciar segredos. Os invasores sabem que segredos de clientes tendem a ser manipulados com menos segurança, e é difícil de rastrear o uso de segredos vazados. Certificados podem ser mais bem gerenciados e podem ser revogados se forem comprometidos. Quando utilizar segredos, crie ou utilize um processo seguro de implantação e sobreposição sem toque para eles. Utilize segredos com um período de expiração definido (por exemplo, um ano, dois anos) e evite a opão de nunca expirar.

• Regularmente implementar certificados e segredos para criar resiliência no seu aplicativo e evitar paralisações devido a uma implementação de emergência.

Próximas etapas

• Adquirir autorização para acessar recursos ajuda você a entender a melhor forma de garantir Zero Trust ao adquirir permissões de acesso a recursos para seu aplicativo.
• Desenvolver estratégia de permissões delegadas ajuda você a implementar a melhor abordagem para gerenciar permissões em seu aplicativo e desenvolver usando princípios de Zero Trust.
• O artigo Práticas recomendadas de autorização ajuda você a implementar os melhores modelos de autorização, permissão e consentimento para aplicativos.
• Solicitar permissões que exigem consentimento administrativo descreve a experiência de permissão e consentimento quando as permissões de aplicativo exigem consentimento administrativo.
• O artigo Proteção de APIs descreve as práticas recomendadas para proteger sua API por meio de registro, definição de permissões e consentimento e imposição de acesso para atingir as metas de Confiança Zero.
• Fornecer credenciais de identidade de aplicativo quando não há usuário explica por que Identidades Gerenciadas para recursos do Azure são a melhor prática de credenciais de cliente para serviços (aplicativos que não são de usuário) no Azure.