Reduzindo permissões e aplicativos com privilégios excessivos

Como desenvolvedor cujo objetivo é projetar e implementar aplicativos que seguem os princípios orientadores da Confiança Zero , você quer reforçar a segurança do aplicativo com o mínimo de privilégio. É imprescindível 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ê entenderá o termo superprivilegiado e descobrirá recomendações e práticas recomendadas para limitar privilégios nos aplicativos para gerenciar o acesso e melhorar a segurança.

O que é superprivilegiado?

O status Superprivilegiado ocorre quando um aplicativo solicita ou recebe mais permissões do que o necessário para operar corretamente. Os exemplos a seguir de permissões não utilizadas e redutíveis melhorarão sua compreensão de privilégios excessivos.

Permissões não utilizadas

Para este exemplo-chave não utilizado, imagine que existem três portas trancadas (azul, amarela e verde), como mostrado no diagrama abaixo.

Diagrama descrito no conteúdo do artigo – três portas abaixo de cada uma das quais é uma chave da mesma cor que sua porta correspondente.

Seus ativos estão atrás das portas. Você tem três chaves (azul, amarela 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 seus ativos, você só carrega as chaves de que precisa quando precisa delas e mantém as chaves não utilizadas em um local seguro.

Permissões reduzíveis

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

Diagrama descrito no conteúdo do artigo – três portas abaixo de cada uma das quais é uma chave.

A primeira chave preta é uma chave de passe que pode abrir todas as portas. A segunda chave preta pode abrir as portas amarelas e verdes. Quando você só precisa acessar as portas amarela e verde, 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. Seus recursos e você, o detentor da chave, são aplicativos. 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 superprivilégio? Por que seu aplicativo pode ter as permissões certas para executar uma tarefa, mas ainda assim ser superprivilegiado? Vejamos a lacuna de permissão que pode cautilizar a discrepância no diagrama abaixo.

Grafo à direita: eixo Y – Permissões, eixo X – Tempo; Curva superior – Permissões concedidas, Curva inferior – Permissões usadas; Estatísticas à direita descritas no conteúdo do artigo.

O eixo X representa Tempo e o eixo Y, as Permissões. No início da medida Tempo, você solicita e recebe permissão para o aplicativo. À medida que os negócios crescem e mudam com o passar do tempo, você adiciona novas permissões para atender às suas necessidades e à inclinação de Permissões concedidas aumenta. As Permissões usadas podem ser menores 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ões.

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 aplicativo.

Segurança comprometida por excesso de privilégios

Vamos nos aprofundar nos riscos que resultam de 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 utiliza 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.

Um cenário comum de comprometimento de segurança para privilégios excessivos normalmente tem quatro estágios, conforme mostrado e descrito abaixo.

Diagrama descrito no conteúdo do artigo – fases de um a quatro 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. Terceiro, o ator 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, eles também são superprivilegiados. O agente mal-intencionado pode utilizar rapidamente o token da permissão concedida para recuperar dados confidenciais.

Aplicativos com excesso de privilégios

Quando uma entidade solicita ou recebe mais permissões do que precisa, ela é superprivilegiada. A definição para aplicativo superprivilegiado na plataforma de identidade da Microsoft é "qualquer aplicativo ao qual foi concedida permissão não utilizada ou redutível".

Vamos utilizar 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 redutível.

Coluna à esquerda: não usada – recebendo uma ou mais permissões que não são necessárias para a chamada à API que está sendo feita. Coluna direita: Redutível – permissão que tem uma alternativa com privilégios inferiores que ainda forneceria o acesso para tarefas necessárias.

A permissão não utilizada ocorre quando o aplicativo recebe permissões que não são necessárias para as tarefas desejadas. Por exemplo, você está criando um aplicativo de calendário. Seu aplicativo de calendário solicita e recebe a permissão Files.ReadWrite.All. Seu aplicativo não se integra às APIs de nenhum arquivo. Portanto, ele possui uma permissão Files.ReadWrite.All não utilizada.

A permissão redutível é mais difícil de descobrir. Isso 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 do aplicativo de calendário, seu aplicativo solicita e recebe a permissão Files.ReadWrite.All. 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, ele utiliza apenas parcialmente a permissão Files.ReadWrite.All, então você precisa fazer downgrade para Files.Read.All.

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

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

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

O diagrama abaixo ilustra as recomendações para reduzir cenários com excesso de privilégio.

Diagrama descrito no conteúdo do artigo – recomendações para evitar, auditar e corrigir cenários superprivilegiados.

  • Evitar: ao criar um aplicativo, compreenda totalmente a permissão necessária para as chamadas de API que ele precisa fazer e solicite apenas o que for necessário para habilitar o cenário. A documentação do Microsoft Graph tem referências claras para permissões de privilégios mínimos para permissões mais privilegiadas para todos os pontos de extremidade. Esteja atento a cenários com privilégios excessivos ao determinar quais permissões você precisa.
  • Auditar: você e os administradores de TI devem revisar regularmente os privilégios concedidos anteriormente aos aplicativos existentes.
  • Remediar: se você ou os administradores de TI perceberem um aplicativo com privilégios excessivos no ecossistema, será necessário interromper a solicitação de tokens para a permissão com privilégios excessivos. Os administradores de TI devem revogar os consentimentos concedidos. Essa etapa geralmente requer uma alteração de código.

Práticas recomendadas para manter a permissão de privilégio mínimo

Dois grandes incentivos para manter a permissão de privilégios mínimos com seus aplicativos são impulsionar a adoção de aplicativos e interromper a propagação, conforme resumido abaixo.

Coluna à esquerda: impulsionar a adoção – criar um aplicativo de terceiros confiável para os clientes, evitando solicitações de permissão excessivas. Coluna direita: parar a propagação – os invasores não podem usar privilégios excessivos para obter mais acesso.

  • Impulsione a adoção criando um aplicativo de terceiros confiável para os clientes que evite solicitações de permissão excessivas. Limite as permissões do aplicativo apenas ao que ele precisa para concluir sua tarefa. Essa prática reduz o raio de explosão potencial de ataques e aumenta a adoção de seus aplicativos pelos clientes. Aplique mais escrutínio ao revisar as permissões solicitadas pelos aplicativos e decidir se deseja conceder permissões ao aplicativo.
  • Pare a propagação garantindo que os invasores não possam utilizar privilégios excessivos para obter mais acesso. Quando você cria um aplicativo que solicita permissões desnecessárias, ele terá menos probabilidade de receber aprovação ou negação total. A melhor maneira de controlar o dano é evitar que os invasores obtenham privilégios elevados, o que aumenta o escopo do comprometimento. Por exemplo, se um aplicativo tiver apenas User.ReadBasic.All para ler informações básicas do usuário, os dados do OneDrive, Outlook, Teams e quaisquer dados confidenciais estarão seguros se um aplicativo for comprometido.

Próximas etapas