Desenvolver a estratégia de permissões de aplicação

À medida que aprende a desenvolver usando os princípios de Zero Trust, consulte este artigo após a sua revisão. Obtenha autorização para aceder a recursos e desenvolva uma estratégia de permissões delegadas. Defina a sua abordagem de permissões de aplicação para a gestão de credenciais quando utiliza a Microsoft Identity platform para autenticar e autorizar as suas aplicações, bem como gerir permissões e consentimentos.

Quando não há utilizador envolvido, não existe um modelo de permissões eficaz porque a sua aplicação recebe sempre as permissões pré-atribuídas.

• A aplicação comprova que é ela quem está a pedir permissão. A sua candidatura prova a sua própria identidade com um dos seguintes métodos:

  • Um certificado, que é a melhor opção.
  • Um segredo num sistema sofisticado de gestão secreta.
  • Quando desenvolver os seus serviços no Azure, use Identidades Geridas para recursos Azure, consulte a seguinte secção Gerir credenciais de aplicação.

• A aplicação requer sempre consentimento prévio do administrador. A sua aplicação solicita esta permissão no âmbito de .default. Solicita as permissões que o administrador atribui à aplicação.

• Funcionalidade para utilizadores transgénero. Por defeito, User.ReadWrite.All permite que a sua aplicação atualize o perfil de todos os utilizadores. Como permissão de aplicação, permite que a sua aplicação leia e atualize o perfil de todos os utilizadores no tenant.

• As permissões concedidas à aplicação são sempre as permissões usadas. Ao contrário de uma permissão delegada, as permissões de aplicação não são limitadas pelo que cada utilizador pode fazer.

Limitar permissões de aplicação

Existem três formas de limitar uma aplicação a menos do que o acesso global.

• As aplicações Microsoft Teams têm consentimento específico por recurso (RSC) que permite a uma aplicação aceder a uma equipa específica em vez de aceder a todas as equipas da empresa. O RSC é uma integração da Microsoft Teams e da Microsoft Graph API que permite à sua aplicação usar endpoints da API e gerir recursos específicos. O seu modelo de permissões permite que os proprietários do Teams e do Chat concedam consentimento para que a sua aplicação aceda e modifique os dados do Teams e do Chat.

• Para limitar o acesso de aplicações a caixas de correio específicas com um script PowerShell, os administradores do Microsoft Exchange podem criar políticas de aplicação Exchange. Podem limitar uma aplicação específica a caixas de correio específicas com Calendar.Read ou Mail.Read acesso. Isso permite, por exemplo, construir uma automação que só possa ler uma caixa de correio ou enviar correspondência apenas de uma caixa e não de toda a empresa.

• Para permitir permissões granulares para aceder ao SharePoint com uma aplicação, o SharePoint tem o Sites.Selected como um âmbito específico. Escolher Sites.Selected para a sua aplicação em vez de uma das outras permissões resulta, por defeito, em aplicações sem acesso a coleções de sites SharePoint. O administrador utiliza o endpoint de permissões do site para conceder permissões de leitura, escrita ou leitura e escrita à sua aplicação.

Gerir credenciais de aplicações

A higiene das credenciais pode garantir que a sua candidatura recupere rapidamente de uma possível violação. As seguintes melhores práticas orientam-no no desenvolvimento de aplicações que realizam deteção e remediação, evitando tempos de inatividade e afetando utilizadores legítimos. Estas recomendações apoiam o princípio de Zero Trust de assumir violação na preparação para responder a um incidente de segurança.

• Remove todos os segredos do código e da configuração. Quando usar a plataforma Azure, coloque segredos no Key Vault e acede-os através de Identidades Geridas para recursos Azure. Torne o seu código resiliente para lidar com rotações secretas caso ocorra uma violação. Os administradores de TI podem remover e rodar segredos e certificados sem derrubar a sua aplicação ou afetar utilizadores legítimos.

• Use certificados em vez de segredos do cliente, a menos que exista um processo seguro para gerir segredos. Os atacantes sabem que os segredos dos clientes tendem a ser tratados de forma menos segura e que o uso de segredos divulgados é difícil de rastrear. Os certificados podem ser melhor geridos e revogados se comprometidos. Quando utilizar segredos, construa ou use um processo seguro de implementação e atualização automatizada para eles. Use segredos com um prazo de expiração definido (por exemplo, um ano, dois anos) e evite que nunca expire.

• Renove regularmente certificados e segredos para aumentar a resiliência da sua aplicação e evitar falhas devido a um rollover de emergência.

Próximos passos

• Adquirir autorização para acessar recursos ajuda você a entender a melhor forma de garantir o Zero Trust ao adquirir permissões de acesso a recursos para seu aplicativo.
• Desenvolver a estratégia de permissões delegadas ajuda você a implementar a melhor abordagem para gerenciar permissões em seu aplicativo e desenvolver com princípios de Confiança Zero.
• As práticas recomendadas de autorização ajudam você a implementar os melhores modelos de autorização, permissão e consentimento para seus aplicativos.
• Pedir permissões que requerem consentimento administrativo descreve a experiência de permissão e consentimento quando as permissões de aplicação requerem consentimento administrativo.
• A Proteção de API 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 suas metas de Zero Trust.
• Forneça credenciais de identidade de aplicação quando não há utilizador que explique porque é que Identidades Geridas para recursos Azure é a melhor prática de credenciais de cliente para serviços (aplicações não utilizadoras) no Azure.