Compartilhar via


Desenvolver estratégia de permissões de aplicativo

Conforme você aprende a desenvolver usando princípios de Confiança Zero, faça referência a este artigo após sua revisão Adquirir autorização para acessar recursos e desenvolver a estratégia de permissões delegadas. Defina sua abordagem de permissões de aplicativo para o gerenciamento de credenciais quando você usar a plataforma de identidade da Microsoft para autenticar e autorizar seus 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 suas permissões pré-atribuídas.

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

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

  • Funcionalidade de usuário trans. Por padrão, User.ReadWrite.All permite que seu aplicativo atualize o perfil de cada usuário. Como permissão de aplicativo, ele 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 permissões usadas. Ao contrário de uma permissão delegada, as permissões de aplicativo não são limitadas pelo que qualquer usuário específico pode fazer.

Limitar permissões de aplicativo

Há três maneiras de limitar um aplicativo a menos do que o acesso global.

  • Os aplicativos do Microsoft Teams têm RSC ( consentimento específico do recurso ) que permite que um aplicativo acesse uma equipe específica em vez de acessar todas as equipes na empresa. O RSC é uma integração da API do Microsoft Teams e do Microsoft Graph que permite que seu aplicativo use pontos de extremidade de API e gerencie recursos específicos. Seu modelo de permissões permite que os proprietários do Teams e do Chat concedam consentimento para que seu aplicativo acesse e modifique seus dados do Teams e do Chat.

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

  • Para permitir permissões granulares para acessar o SharePoint com um aplicativo, o SharePoint tem Sites.Selected como um escopo específico. Escolha Sites.Selected para seu aplicativo em vez de um dos outros resultados de permissões, o que por padrão resulta em aplicativos sem acesso aos conjuntos de sites do SharePoint. O administrador usa o endpoint 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 da credencial pode garantir que seu aplicativo se recupere rapidamente de uma possível violação. As práticas recomendadas a seguir orientam você no desenvolvimento de aplicativos que executam a detecção e a correção, evitando o tempo de inatividade e afetando usuários legítimos. Essas recomendações dão suporte ao princípio de Confiança Zero de assumir violação na preparação para responder a um incidente de segurança.

  • Remova todos os segredos do código e da configuração. Ao usar a plataforma do Azure, coloque segredos no cofre de chaves e acesse-os por meio de Identidades Gerenciadas para recursos do Azure. Torne seu código resiliente para lidar com rotações secretas se ocorrer um comprometimento. Os administradores de TI podem remover e alternar segredos e certificados sem interromper o funcionamento do seu aplicativo ou afetar usuários legítimos.

  • Use certificados em vez de segredos do cliente, a menos que um processo seguro esteja em vigor para gerenciar segredos. Os invasores sabem que os segredos dos clientes costumam ser tratados com menos segurança e o uso de segredos vazados é difícil de rastrear. Os certificados podem ser melhor gerenciados e revogados caso sejam comprometidos. Ao usar segredos, crie ou use um processo seguro de implantação e substituição sem toque para eles. Use segredos com um período de tempo de expiração definido (por exemplo, um ano, dois anos) e evite nunca expirar.

  • Substitua regularmente certificados e segredos para criar resiliência em sua aplicação e evitar interrupções devido a uma substituição de emergência.

Próximas etapas