Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
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:
- Um certificado, que é a melhor opção.
- Um segredo em um sofisticado sistema de gerenciamento de segredos.
- Ao desenvolver seus serviços no Azure, use Identidades Gerenciadas para recursos do Azure, revise a seção Gerenciar credenciais do aplicativo a seguir.
O aplicativo sempre requer consentimento prévio do administrador. Seu aplicativo solicita essa permissão com o
.defaultescopo. Ele solicita as permissões que o administrador atribui ao aplicativo.Funcionalidade de usuário trans. Por padrão,
User.ReadWrite.Allpermite 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.ReadouMail.Readacesso. 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.Selectedpara 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
- 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 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.
- O artigo Práticas recomendadas de autorização ajuda você a implementar os melhores modelos de autorização, permissão e consentimento para aplicativos.
- As permissões de solicitação que exigem consentimento administrativo descrevem 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.
- Forneça credenciais de identidade do aplicativo quando não houver 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 nonuser) no Azure.