Share via


Reduza permissões e aplicativos com privilégios excessivos

Como desenvolvedor com o objetivo de projetar e implementar aplicativos que seguem os princípios orientadores do Zero Trust, você deseja aumentar a segurança do aplicativo com o mínimo de privilégio. É imperativo que você reduza a superfície de ataque do seu aplicativo e o efeito de uma violação de segurança.

Neste artigo, você aprenderá por que os aplicativos não devem solicitar mais permissões do que precisam. Você entende o termo superprivilegiado e descobre recomendações e práticas recomendadas para limitar o privilégio em seus aplicativos para gerenciar o acesso e melhorar a segurança.

O que é superprivilegiado?

Overprivileged ocorre quando um aplicativo solicita ou recebe mais permissões do que precisa para funcionar corretamente. Melhore sua compreensão de privilégios excessivos com exemplos de permissões não utilizadas e reduzíveis no restante deste artigo.

Permissões não utilizadas

Para este exemplo de chave não utilizado, imagine que há três portas trancadas (azul, amarelo e verde), conforme mostrado no diagrama a seguir.

O diagrama mostra três portas com as teclas correspondentes para ilustrar as permissões não utilizadas.

Os seus bens estão atrás das portas. Você tem três chaves (azul, amarelo e verde) que permitem que você abra a porta correspondente. Por exemplo, a chave azul pode abrir a porta azul. Quando você só precisa de acesso à porta amarela, você só carrega a chave amarela.

Para melhor proteger os seus bens, só carrega as chaves de que precisa quando precisa delas e guarda as chaves não utilizadas num local seguro.

Permissões redutíveis

O exemplo de chaves redutíveis é mais complicado do que o exemplo de chave não utilizado ao qual agora adicionamos duas chaves especiais, conforme mostrado no diagrama a seguir.

O diagrama mostra três portas com teclas correspondentes para ilustrar as permissões redutíveis.

A primeira chave preta é uma chave de passagem que pode abrir todas as portas. A segunda chave preta pode abrir as portas amarela e verde. Quando você só precisa de acesso às portas amarelas e verdes, você só carrega a segunda chave preta. Você mantém sua chave de acesso em um local seguro com a chave verde redundante.

No mundo da identidade da Microsoft, as chaves são permissões de acesso. Os seus recursos e você, o detentor da chave, são aplicações. Se você entende o risco de carregar chaves desnecessárias, está ciente do risco de seus aplicativos terem permissões desnecessárias.

Lacuna de permissão e risco

Como portas e chaves podem ajudar a entender como ocorre o excesso de privilégios? Por que seu aplicativo pode ter as permissões certas para executar uma tarefa, mas ainda estar com privilégios excessivos? Vamos examinar a lacuna de permissão que pode causar a discrepância no diagrama a seguir.

Gráfico à direita: eixo Y - Permissões, eixo X - Tempo; Curva Superior - Permissões Concedidas, Curva Inferior - Permissões Usadas; Estatísticas sobre o direito descrito no conteúdo do artigo.

O eixo X representa Tempo e o eixo Y representa Permissões. No início do tempo medido, você solicita e recebe permissão para sua inscrição. À medida que a empresa cresce e muda ao longo do tempo, você adiciona novas permissões para dar suporte às suas necessidades e a inclinação das Permissões Concedidas aumenta. As Permissões Usadas podem ser menores do que as Permissões Concedidas quando você se esquece de remover permissões desnecessárias (por exemplo, se o aplicativo não quebrar), resultando em uma Lacuna de Permissão.

Aqui estão observações interessantes na plataforma de identidade da Microsoft.

  • Temos mais de 4.000 APIs no Microsoft Graph.
  • Mais de 200 permissões do Microsoft Graph estão disponíveis na plataforma de identidade da Microsoft.
  • Os desenvolvedores têm acesso a uma ampla gama de dados e a capacidade de aplicar granularidade às permissões solicitadas por seus aplicativos.
  • Em nossas investigações, descobrimos que os aplicativos têm apenas 10% de permissões totalmente utilizadas para seus cenários.

Pense cuidadosamente sobre quais permissões seu aplicativo realmente exige. Cuidado com a lacuna de permissão e verifique regularmente as permissões do seu aplicativo.

Segurança comprometida por superprivilegiados

Vamos nos aprofundar nos riscos resultantes das lacunas de permissão com um exemplo. Esse cenário comprometedor compreende duas funções: administrador de TI e desenvolvedor.

  • Administrador de TI: Jeff é um administrador de locatário que garante que os aplicativos no Microsoft Entra ID sejam confiáveis e seguros. Parte do trabalho de Jeff é conceder consentimento às permissões que os desenvolvedores de aplicativos exigem.
  • Desenvolvedor: Kelly é um desenvolvedor de aplicativos que usa a plataforma de identidade da Microsoft e possui aplicativos. O trabalho de Kelly é garantir que os aplicativos tenham as permissões certas para executar as tarefas necessárias.

O seguinte cenário comum de comprometimento de segurança para superprivilegiados normalmente tem quatro estágios.

Diagrama descrito no conteúdo do artigo - quatro estágios de um cenário de comprometimento de segurança.

  1. Primeiro, o desenvolvedor começa a configurar o aplicativo e adicionar as permissões necessárias.
  2. Em segundo lugar, o administrador de TI analisa as permissões necessárias e concede consentimento.
  3. Em terceiro lugar, o agente mal-intencionado começa a quebrar as credenciais do usuário e hackeia com sucesso a identidade do usuário.
  4. Se o usuário possui vários aplicativos, ele também é superprivilegiado. O agente mal-intencionado pode usar rapidamente o token da permissão concedida para recuperar dados confidenciais.

Aplicações superprivilegiadas

Uma entidade é superprivilegiada quando solicita ou recebe mais permissões do que precisa. A definição de aplicativo com privilégios excessivos na plataforma de identidade da Microsoft é "qualquer aplicativo com permissões não utilizadas ou reduzíveis".

Vamos usar o Microsoft Graph como parte da plataforma de identidade da Microsoft em um exemplo do mundo real para entender melhor a permissão não utilizada e a permissão reduzível.

Coluna da esquerda: Não utilizado - Receber uma ou mais permissões que não são necessárias para a chamada de API que está sendo feita. Coluna da direita: Redutível - Permissão que tem uma alternativa menos privilegiada que ainda forneceria o acesso para as tarefas necessárias.

A permissão não utilizada ocorre quando seu aplicativo recebe permissões que não são necessárias para as tarefas desejadas. Por exemplo, está a criar uma aplicação de calendário. Seu aplicativo de calendário solicita e recebe Files.ReadWrite.All permissão. Seu aplicativo não se integra a APIs de nenhum arquivo. Portanto, seu aplicativo tem uma permissão não utilizada Files.ReadWrite.All .

A permissão redutível é mais difícil de descobrir. Ocorre quando seu aplicativo recebe poucas permissões, mas tem uma alternativa com privilégios mais baixos que forneceria acesso suficiente para as tarefas necessárias. No exemplo de aplicativo de calendário, seu aplicativo solicita e recebe Files.ReadWrite.All permissão. No entanto, ele só precisa ler arquivos do OneDrive do usuário conectado e nunca precisa criar novos arquivos ou modificar os existentes. Nesse caso, seu aplicativo utiliza Files.ReadWrite.All apenas parcialmente, então você precisa fazer o downgrade para Files.Read.All.

Recomendações para reduzir cenários com privilégios excessivos

A segurança é uma viagem, não um destino. Existem três fases distintas no ciclo de vida da segurança:

  • Prevenção
  • Auditoria
  • Remediação

O diagrama a seguir ilustra as recomendações para reduzir cenários com privilégios excessivos.

Diagrama descrito no conteúdo do artigo - recomendações para prevenir, auditar e corrigir cenários com privilégios excessivos.

  • Prevenir: ao criar um aplicativo, você deve entender completamente a permissão necessária para as chamadas de API que seu aplicativo precisa fazer e solicitar apenas o que é necessário para habilitar seu cenário. A documentação do Microsoft Graph tem referências claras para permissões de privilégios mínimos para permissões de privilégios mais privilegiados para todos os pontos de extremidade. Esteja atento a cenários superprivilegiados ao determinar quais permissões você precisa.
  • Auditoria: Você e os administradores de TI devem revisar regularmente os privilégios concedidos anteriormente pelos aplicativos existentes.
  • Corrigir: se você ou os administradores de TI perceberem um aplicativo com privilégios excessivos no ecossistema, você deve parar de solicitar tokens para a permissão com privilégios excessivos. Os administradores de TI devem revogar os consentimentos concedidos. Esta etapa geralmente requer uma alteração de código.

Práticas recomendadas para manter a permissão de privilégios mínimos

Dois grandes incentivos para manter a permissão de privilégios mínimos com seus aplicativos estão impulsionando a adoção de aplicativos e interrompendo a propagação.

Coluna da esquerda: Impulsione a adoção - Crie um aplicativo confiável para os clientes, evitando solicitações de permissão excessivas. Coluna da direita: Parar a propagação - Os atacantes não conseguem usar privilégios excessivos para obter mais acesso.

  • Impulsione a adoção criando um aplicativo confiável para os clientes que evite solicitações de permissão excessivas. Limite as permissões do seu aplicativo apenas ao que ele precisa para concluir sua tarefa. Essa prática reduz o potencial raio de explosão de ataques e aumenta a adoção de seus aplicativos pelos clientes. Aplique mais escrutínio ao analisar as permissões solicitadas pelos aplicativos e decidir se deseja conceder permissões ao aplicativo.
  • Impeça a propagação garantindo que os atacantes não possam usar privilégios excessivos para obter mais acesso. Quando você cria um aplicativo que solicita permissões desnecessárias, é menos provável que ele receba aprovação ou seja negado completamente. A melhor maneira de controlar o dano é impedir que os invasores ganhem privilégios elevados que aumentem o escopo do compromisso. Por exemplo, se o seu aplicativo só precisa User.ReadBasic.All ler informações básicas do usuário, seu OneDrive, Outlook, Teams e quaisquer dados confidenciais estarão seguros se um aplicativo for comprometido.

Próximos passos