Partilhar via

Desenvolver estratégia de permissões de aplicativos

  • Artigo

À medida que você aprende a desenvolver usando os princípios Zero Trust, consulte este artigo depois de revisar Adquirir autorização para acessar recursos e Desenvolver estratégia de permissões delegadas. Defina sua abordagem de permissões de aplicativo para gerenciamento de credenciais ao 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 solicita permissão. A sua candidatura prova a sua própria identidade através de um dos seguintes métodos:

    • um certificado, que é a melhor opção, ou
    • um segredo num sofisticado sistema de gestão secreta, ou
    • quando estiver a desenvolver os seus serviços no Azure, utilize Identidades Geridas para recursos do Azure, reveja a seguinte secção Gerir credenciais de aplicação.

  • A aplicação requer sempre o 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 uma 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 do aplicativo não são limitadas pelo que qualquer usuário específico pode fazer.

Limitar permissões de aplicativos

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

  • Os aplicativos do Microsoft Teams têm consentimento específico de recursos (RSC) que permite que um aplicativo acesse uma equipe específica em vez de acessar todas as equipes da empresa. O RSC é uma integração de 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.

  • 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 Calendar.Read ou Mail.Read acesso. Isso permite que você, por exemplo, crie uma automação que só pode ler uma caixa de correio ou enviar e-mails apenas de uma caixa de correio e não de todos na empresa.

  • O SharePoint tem Sites.Selected como um escopo específico para permitir permissões granulares para acessar o 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 usa 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 de credenciais 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 realizam deteção e correção, evitando tempo de inatividade e afetando usuários legítimos. Essas recomendações apoiam o princípio Zero Trust de assumir violação ao prepará-lo para responder a um incidente de segurança.

  • Remova todos os segredos do código e da configuração. Quando estiver a utilizar a plataforma Azure, coloque segredos no Cofre da Chave e aceda aos mesmos através das Identidades Geridas 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 girar segredos e certificados sem remover seu aplicativo ou afetar usuários legítimos.

  • Use certificados em vez de segredos de cliente, a menos que um processo seguro esteja em vigor para gerenciar segredos. Os atacantes sabem que os segredos dos clientes tendem a ser tratados de forma menos segura e que o uso de segredos vazados é difícil de rastrear. Os certificados podem ser melhor gerenciados e revogados se comprometidos. Quando você usa 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.

  • Revise regularmente certificados e segredos para criar resiliência em seu aplicativo e evite interrupções devido a uma sobreposição 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 usando os princípios Zero Trust.
  • As práticas recomendadas de autorização ajudam você a implementar os melhores modelos de autorização, permissão e consentimento para seus aplicativos.
  • Solicitar permissões que exigem consentimento administrativo descreve a experiência de permissão e consentimento quando as permissões do aplicativo exigem 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.
  • Fornecer credenciais de identidade de aplicativo quando não há nenhum usuário explica por que as Identidades Gerenciadas para recursos do Azure são a melhor prática de credenciais de cliente para serviços (aplicativos não usuários) no Azure.