Partilhar via

Investigação de concessão de consentimento do aplicativo

  • Artigo

Este artigo fornece orientações sobre como identificar e investigar ataques de consentimento de aplicativos, proteger informações e minimizar riscos adicionais.

Este artigo contém as seguintes seções:

  • Pré-requisitos: Abrange os requisitos específicos que você precisa preencher antes de iniciar a investigação. Por exemplo, registro em log que deve ser ativado, funções e permissões necessárias, entre outros.
  • Fluxo de trabalho: mostra o fluxo lógico que você deve seguir para executar esta investigação.
  • Lista de verificação: contém uma lista de tarefas para cada uma das etapas do fluxograma. Esta lista de verificação pode ser útil em ambientes altamente regulamentados para verificar as medidas tomadas ou simplesmente como uma porta de qualidade para si mesmo.
  • Etapas da investigação: Inclui orientações detalhadas passo a passo para esta investigação específica.
  • Recuperação: contém etapas de alto nível sobre como recuperar/mitigar de um ataque de concessão de consentimento de aplicativo ilícito.
  • Referências: Contém mais materiais de leitura e de referência.

Pré-requisitos

Aqui estão as configurações gerais e configurações que você deve concluir ao executar uma investigação para Concessões de Consentimento de Aplicativo. Antes de iniciar a investigação, leia sobre os tipos de permissões de consentimento explicados em Tipos de permissão de consentimento.

Dados do cliente

Para iniciar o processo de investigação, você precisa dos seguintes dados:

  • Detalhe dos indicadores de compromisso (IoCs)
  • A data e a hora em que reparou no incidente
  • Intervalo de datas
  • Número de contas comprometidas
  • Nome das contas comprometidas
  • Funções da conta comprometida
  • As contas são altamente privilegiadas (GA, Microsoft Exchange, SharePoint)?
  • Existem Aplicações Empresariais relacionadas com o incidente?
  • Os usuários relataram algum aplicativo que estava solicitando permissões para dados em seu nome?

Requisitos de sistema

Certifique-se de concluir as seguintes instalações e requisitos de configuração:

  • O módulo AzureAD PowerShell está instalado.
  • Você tem direitos de Administrador Global no locatário contra o qual o script é executado.
  • Você recebe a função de administrador local no computador que você usa para executar os scripts.

Nota

Os módulos Azure AD e MSOnline PowerShell foram preteridos a partir de 30 de março de 2024. Para saber mais, leia a atualização de descontinuação. Após essa data, o suporte para esses módulos é limitado à assistência de migração para o SDK do Microsoft Graph PowerShell e correções de segurança. Os módulos preteridos continuarão a funcionar até 30 de março de 2025.

Recomendamos migrar para o Microsoft Graph PowerShell para interagir com o Microsoft Entra ID (anteriormente Azure AD). Para perguntas comuns sobre migração, consulte as Perguntas frequentes sobre migração. Nota: As versões 1.0.x do MSOnline podem sofrer interrupções após 30 de junho de 2024.

Instalar o módulo AzureAD

Use este comando para instalar o módulo AzureAD.

Install-Module -Name AzureAD -Verbose

Nota

Se lhe for pedido para instalar os módulos a partir de um repositório não fidedigno, escreva Y e prima Enter.

Instalar o módulo MSOnline PowerShell

  1. Execute o aplicativo Windows PowerShell com privilégios elevados (execute como administrador).

  2. Execute este comando para permitir que o PowerShell execute scripts assinados.

    Set-ExecutionPolicy RemoteSigned

  3. Instale o módulo MSOnline com este comando.

    Install-Module -Name MSOnline -Verbose

    Nota

    Se lhe for pedido para instalar os módulos a partir de um repositório não fidedigno, escreva Y e prima Enter.

Baixe o script AzureADPSPermissions do GitHub

  1. Baixe o script Get-AzureADPSPermissions.ps1 do GitHub para uma pasta a partir da qual você executa o script. O arquivo de saída "permissions.csv" também é gravado nesta mesma pasta.

  2. Abra uma instância do PowerShell como administrador e abra a pasta na qual você salvou o script.

  3. Conecte-se ao seu diretório usando o Connect-AzureAD cmdlet. Eis um exemplo.

    Connect-AzureAD -tenantid "2b1a14ac-2956-442f-9577-1234567890ab" -AccountId "user1@contoso.onmicrosoft.com"

  4. Execute este comando do PowerShell.

    Get-AzureADPSPermissions.ps1 | Export-csv -Path "Permissions.csv" -NoTypeInformation

    Desconecte sua sessão do AzureAD com este comando.

    Disconnect-AzureAD

O consentimento é o processo de concessão de autorização a uma aplicação para aceder a recursos protegidos em nome dos utilizadores. Pode ser solicitado consentimento a um administrador ou utilizador para permitir o acesso aos seus dados organizacionais/individuais.

Um aplicativo recebe acesso a dados com base em um usuário específico ou para toda a organização. Os invasores podem usar indevidamente esses consentimentos para obter persistência no ambiente e acessar dados confidenciais. Esses tipos de ataques são chamados de Concessões de Consentimento Ilícito, que podem acontecer por meio de um e-mail de phishing, comprometimento de uma conta de usuário por meio de spray de senha ou quando um invasor registra um aplicativo como um usuário legítimo. Em cenários em que uma conta de administrador é comprometida, a concessão de registro e consentimento é para todo o locatário e não apenas para um usuário.

Para uma aplicação poder aceder aos dados da organização, o utilizador terá de conceder as permissões de aplicação necessárias para o fazer. Diferentes permissões permitem diferentes níveis de acesso. Por predefinição, todos os utilizadores estão autorizados a consentir às aplicações permissões que não requerem consentimento do administrador. Por exemplo, por padrão, um usuário pode consentir em permitir que um aplicativo acesse sua caixa de correio, mas não pode consentir em permitir que um aplicativo tenha acesso irrestrito para ler e gravar em todos os arquivos em sua organização.

Nota

Ao permitir que os usuários concedam aos aplicativos acesso aos dados, os usuários podem facilmente adquirir aplicativos úteis e ser produtivos. No entanto, em algumas situações, essa configuração pode representar um risco se não for monitorada e controlada cuidadosamente.

Para poder conceder o consentimento de administrador de todo o locatário, você deve entrar com pelo menos uma das seguintes funções:

  • Administrador da Aplicação
  • Administrador de Aplicações na Cloud
  • Administrador - Indica que o consentimento foi fornecido pelo administrador (em nome da organização)
  • Usuário individual - Indica que o consentimento foi dado pelo usuário e só tem acesso às informações desse usuário
  • Valores aceites
    • AllPrincipals - Consentido por um administrador para todo o arrendamento
    • Principal – Consentimento do utilizador individual para dados apenas relacionados com essa conta

A experiência real do usuário de conceder consentimento difere dependendo das políticas definidas no locatário do usuário, do escopo de autoridade (ou função) do usuário e do tipo de permissões solicitadas pelo aplicativo cliente. Isso significa que os desenvolvedores de aplicativos e administradores de locatários têm algum controle sobre a experiência de consentimento. Os administradores têm a flexibilidade de definir e desativar políticas em um locatário ou aplicativo para controlar a experiência de consentimento em seu locatário. Os desenvolvedores de aplicativos podem ditar quais tipos de permissões são solicitados e se desejam orientar os usuários pelo fluxo de consentimento do usuário ou pelo fluxo de consentimento do administrador.

  • Fluxo de consentimento do usuário - Quando um desenvolvedor de aplicativos direciona os usuários para o ponto de extremidade de autorização com a intenção de registrar o consentimento apenas para o usuário atual.

  • Fluxo de consentimento do administrador - Quando um desenvolvedor de aplicativos direciona os usuários para o ponto de extremidade de consentimento do administrador com a intenção de registrar o consentimento para todo o locatário. Para garantir que o fluxo de consentimento de administrador funcione corretamente, os desenvolvedores de aplicativos devem listar todas as permissões na propriedade RequiredResourceAccess no manifesto do aplicativo.

Permissões delegadas vs. permissões de aplicativos

As permissões delegadas são usadas por aplicativos que têm um usuário conectado presente e podem ter consentimentos aplicados pelo administrador ou usuário.

As permissões de aplicação são utilizadas por aplicações que funcionam sem um utilizador com sessão iniciada presente. Por exemplo, aplicações que são executadas como serviços em segundo plano ou daemons. As permissões do aplicativo só podem ser consentidas por um administrador.

Para obter mais informações, consulte:

Classificando permissões de risco

Existem milhares (pelo menos) de permissões no sistema, e não é viável listar ou analisar todas elas. A lista a seguir aborda permissões comumente usadas indevidamente e outras que criariam um impacto catastrófico se usadas indevidamente.

Em um alto nível, a Microsoft observou as seguintes permissões delegadas "raiz" (Aplicativo + Usuário) sendo usadas indevidamente em ataques de phishing de consentimento. Root equivale ao nível superior. Por exemplo, Contacts.* significa incluir todas as permutações delegadas de permissões de Contatos: Contacts.Read, Contacts.ReadWrite, Contacts.Read.Shared e Contacts.ReadWrite.Shared.

  1. Mail.* (incluindo Mail.Send*, mas não Mail.ReadBasic*)
  2. Contatos. *
  3. MailboxSettings.*
  4. Pessoas.*
  5. Ficheiros.*
  6. Observações.*
  7. Directory.AccessAsUser.All
  8. User_Impersonation

As primeiras sete permissões na lista anterior são para o Microsoft Graph e os equivalentes de API "legados", como o Azure Ative Directory (Azure AD) Graph e o Outlook REST. A oitava permissão é para o Azure Resource Manager (ARM) e também pode ser perigosa em qualquer API que exponha dados confidenciais com esse escopo de representação geral.

Com base nas observações da equipe de resposta a incidentes da Microsoft, os invasores usam uma combinação das seis primeiras permissões em 99% dos ataques de phishing de consentimento. A maioria das pessoas não pensa na versão delegada do Mail.Read ou Files.Read como uma permissão de alto risco, no entanto, os ataques geralmente são generalizados e visam os usuários finais, em vez de spear phishing contra administradores que podem realmente consentir com as permissões perigosas. Recomenda-se criar bolhas em aplicativos com essas permissões de impacto de nível "crítico". Mesmo que os aplicativos não tenham intenção maliciosa e se um agente mal-intencionado comprometer a identidade do aplicativo, toda a sua organização pode estar em risco.

Para obter as permissões de maior impacto de risco, comece aqui:

  • Versões de permissão de aplicativo (AppOnly/AppRole) de todas as permissões acima, quando aplicável

Versões delegadas e AppOnly das seguintes permissões:

  • Application.ReadWrite.All
  • Directory.ReadWrite.All
  • Domínio.ReadWrite.All*
  • EduRoster.ReadWrite.All*
  • Grupo.ReadWrite.All
  • Membro.Read.Hidden*
  • RoleManagement.ReadWrite.Directory
  • Usuário.ReadWrite.All*
  • Usuário.ManageCreds.All
  • Todas as outras permissões AppOnly que permitem acesso de gravação

Para obter a lista de permissões de menor impacto de risco, comece aqui:

  • Usuário.Read
  • Usuário.ReadBasic.All
  • Open_id
  • E-mail
  • Perfil
  • Offline_access (apenas se emparelhado com outras permissões nesta lista de "menor risco")

Permissões de visualização

  1. Para exibir as permissões, navegue até a tela Registro no aplicativo empresarial.

    Captura de ecrã de como visualizar diferentes permissões.

  2. Selecione Exibir permissões da API.

    Captura de tela de como exibir e adicionar permissões de API.

  3. Selecione Adicionar uma permissão e a tela a seguir será exibida.

    Captura de tela de como solicitar permissões de API.

  4. Selecione Microsoft Graph para exibir os diferentes tipos de permissões.

    Captura de tela de diferentes tipos de permissões de API.

  5. Selecione o tipo de permissões que o aplicativo registrado está usando: Permissões delegadas ou Permissões de aplicativo. Na imagem acima, Permissões de aplicativo é selecionado.

  6. Você pode pesquisar uma das permissões de impacto de alto risco, como o EduRoster.

    Captura de tela de um exemplo de solicitação de permissão de API.

  7. Selecione EduRoster e expanda as permissões.

    Captura de tela de um item de permissão de API com uma dica de ferramenta.

  8. Agora você pode atribuir ou revisar essas permissões.

    Para obter mais informações, Permissões de gráfico.

Fluxo de Trabalho

[Fluxograma de um fluxo de trabalho de investigação de concessão de consentimento de aplicativo.]

Também pode:

  • Baixe a concessão de consentimento do aplicativo e outros fluxos de trabalho do manual de resposta a incidentes como um PDF.
  • Baixe a concessão de consentimento do aplicativo e outros fluxos de trabalho do manual de resposta a incidentes como um arquivo do Visio.

Lista de Verificação

Use esta lista de verificação para executar a validação de concessão de consentimento do aplicativo.

  • Indicadores de compromisso (IoC)

    Verifique os seguintes indicadores de compromisso (IoC):

    • Quando reparou no incidente?
    • Intervalo de datas do incidente (quão à esquerda está o poste da baliza?)
    • Número de contas comprometidas
    • Nomes de contas comprometidas
    • Funções das contas comprometidas
    • As contas comprometidas são altamente privilegiadas, um usuário padrão ou uma combinação

  • Funções

    Você deve ser atribuído com estas funções:

    • Função de Administrador Local no computador a partir do qual executa o script

  • Configuração do PowerShell

    Configure seu ambiente do PowerShell com estas etapas:

    1. Instale o módulo Azure AD PowerShell.
    2. Execute o aplicativo Windows PowerShell com privilégios elevados. (Executar como administrador).
    3. Configure o PowerShell para executar scripts assinados.
    4. Baixe o script Get-AzureADPSPermissions.ps1 .

  • Gatilhos da investigação

    • Comprometimento da conta
    • Configurações de Consentimento do Aplicativo modificadas no locatário
    • Motivo do status do evento de alerta/auditoria "aplicativo de risco" detetado
    • Notou aplicações de aparência estranha

Você também pode baixar a concessão de consentimento do aplicativo e outras listas de verificação do manual de incidentes como um arquivo do Excel.

Passos de investigação

Você pode usar os dois métodos a seguir para investigar concessões de consentimento de aplicativo:

  • Portal do Azure
  • Script do PowerShell

Nota

Usar o portal do Azure só permite que você veja as Concessões de Consentimento de Administrador dos últimos 90 dias e, com base nisso, recomendamos usar o método de script do PowerShell apenas para reduzir as etapas de investigação de registros de invasores.

Método 1 – Usando o portal do Azure

Você pode usar o Centro de administração do Microsoft Entra para localizar aplicativos aos quais usuários individuais concederam permissões.

  1. Inicie sessão no portal do Azure como administrador.
  2. Selecione o ícone ID do Microsoft Entra .
  3. Selecione Utilizadores.
  4. Selecione o usuário que você deseja revisar.
  5. Selecione Aplicativos.
  6. Você pode ver a lista de aplicativos atribuídos ao usuário e quais permissões esses aplicativos têm.

Método 2 - Usando o PowerShell

Há várias ferramentas do PowerShell que você pode usar para investigar concessões de consentimento ilícitas, como:

O PowerShell é a ferramenta mais fácil e não exige que você modifique nada na locação. Vamos basear nossa investigação na documentação pública do ataque de Concessão de Consentimento Ilícito.

Execute Get-AzureADPSPermissions.ps1, para exportar todas as concessões de consentimento OAuth e aplicativos OAuth para todos os usuários em sua locação para um arquivo .csv . Consulte a seção Pré-requisitos para baixar e executar o Get-AzureADPSPermissions script.

  1. Abra uma instância do PowerShell como administrador e abra a pasta onde você salvou o script.

  2. Conecte-se ao seu diretório usando o seguinte comando Connect-AzureAD . Eis um exemplo.

    Connect-AzureAD -tenantid "2b1a14ac-2956-442f-9577-1234567890ab" -AccountId "user1@contoso.onmicrosoft.com"

  3. Execute este comando do PowerShell.

    Get-AzureADPSPermissions.ps1 | Export-csv c:\temp\consentgrants\Permissions.csv -NoTypeInformation

  4. Quando o script for concluído, é recomendável desconectar a sessão do Microsoft Entra com este comando.

     Disconnect-AzureAD

    Nota

    O script pode levar horas para ser concluído, dependendo do tamanho e das permissões configuradas, bem como da sua conexão.

  5. O script cria um arquivo chamado Permissions.csv.

  6. Abra o arquivo, filtre ou formate os dados em uma tabela e salve como um .xlxs arquivo.

    Os cabeçalhos de coluna para saída são mostrados nesta imagem.

    Captura de ecrã dos cabeçalhos das colunas do Excel.

  7. Na coluna ConsentType (G), procure o valor AllPrinciples. A permissão AllPrincipals permite que o aplicativo cliente acesse o conteúdo de todos na locação. Os aplicativos nativos do Microsoft 365 precisam dessa permissão para funcionar corretamente. Todos os aplicativos que não sejam da Microsoft com essa permissão devem ser analisados cuidadosamente.

  8. Na coluna Permissão (F), revise as permissões que cada aplicativo delegado tem. Procure a permissão de Leitura e Escrita ou *. Todas as permissões e revise essas permissões cuidadosamente porque elas podem não ser apropriadas. Captura de ecrã das permissões da aplicação na coluna F.

    Nota

    Analise os usuários específicos que têm consentimentos concedidos. Se usuários de alto perfil ou alto impacto tiverem consentimentos inadequados concedidos, você deve investigar mais.

  9. Na coluna ClientDisplayName (C), procure aplicativos que pareçam suspeitos, como:

    • Aplicações com nomes com erros ortográficos Exemplo de captura de ecrã de um nome com erros ortográficos.

    • Nomes incomuns ou sem graça Exemplo de captura de tela de um nome incomum.

    • Nomes que soam a hackers. Você deve revisar esses nomes cuidadosamente. Exemplo de captura de ecrã do nome de um hacker.

Exemplo de saída: AllPrincipals e ler escrever tudo. Os aplicativos podem não ter nada suspeito como nomes sem graça e estão usando o MS graph. No entanto, realize pesquisas e determine a finalidade dos aplicativos e as permissões reais que os aplicativos têm no locatário, conforme mostrado neste exemplo.

Exemplo de captura de tela de aplicativos com o AllPrincipals ConsentType.

Aqui estão algumas dicas úteis para revisar investigações de política de segurança da informação (ISP):

  • ReplyURL/RedirectURL
    • Procure URLs suspeitos
  • O URL está alojado num domínio suspeito?
    • Está comprometido?
    • O domínio foi registado recentemente?
    • É um domínio temporário?
  • Há um link de termos de serviço/contrato de serviço no registro do aplicativo?
  • Os conteúdos são únicos e específicos da aplicação/editora?
  • O locatário que registrou o aplicativo é recém-criado ou comprometido (por exemplo, o aplicativo é registrado por um usuário em risco)?

Técnicas de ataque

Embora cada ataque tenda a variar, as principais técnicas de ataque são:

  • Um invasor registra um aplicativo com um provedor OAuth 2.0, como o Microsoft Entra ID.

  • As aplicações são configuradas de forma a parecerem legítimas. Por exemplo, os atacantes podem usar o nome de um produto popular disponível no mesmo ecossistema.

  • O invasor recebe um link diretamente dos usuários, o que pode ser feito por meio de phishing convencional baseado em e-mail, comprometendo um site não mal-intencionado ou por meio de outras técnicas.

  • O usuário seleciona o link e é mostrado um prompt de consentimento autêntico solicitando que ele conceda permissões ao aplicativo mal-intencionado para os dados.

  • Se um usuário selecionar 'Aceitar', ele concederá permissões ao aplicativo para acessar dados confidenciais.

  • O aplicativo recebe um código de autorização, que ele resgata para um token de acesso e, potencialmente, um token de atualização.

  • O token de acesso é usado para fazer chamadas de API em nome do usuário.

  • Se o usuário aceitar, o invasor poderá obter acesso aos e-mails, regras de encaminhamento, arquivos, contatos, notas, perfil e outros dados e recursos confidenciais do usuário.

    Exemplo de captura de tela da solicitação de permissões.

Encontrar sinais de um ataque

  1. No portal do Microsoft 365 Defender em https://security.microsoft.com, vá para Auditoria. Ou para ir diretamente para a página Auditoria , use https://security.microsoft.com/auditlogsearch.

  2. Na página Auditoria, pesquise todas as atividades e todos os usuários, insira a data de início e a data de término, se necessário, e selecione Pesquisar.

    Exemplo de captura de tela de uma pesquisa de log de auditoria.

  3. Selecione Filtrar resultados e, no campo Atividade , insira Consentimento para o aplicativo.

    Exemplo de captura de tela de filtragem de uma pesquisa de log de auditoria.

  4. Se você tiver atividade sob consentimento para conceder, continue para a próxima etapa.

  5. Selecione o resultado para ver os detalhes da atividade. Selecione Mais informações para obter detalhes da atividade.

  6. Verifique se IsAdminContent está definido como 'True'.

    Nota

    Esse processo pode levar de 30 minutos até 24 horas para que a entrada de log de auditoria correspondente seja exibida nos resultados da pesquisa após a ocorrência de um evento.

    A extensão do tempo em que um registro de auditoria é retido e pode ser pesquisado no log de auditoria depende da sua assinatura do Microsoft 365 e, especificamente, do tipo de licença atribuída a um usuário específico. Se esse valor for verdadeiro, ele indica que alguém pode ter concedido amplo acesso aos dados. Se isso for inesperado, tome medidas imediatas para confirmar um ataque.

Como confirmar um ataque?

Se você tiver uma ou mais instâncias dos IoCs listados anteriormente, precisará fazer uma investigação adicional para confirmar positivamente que o ataque ocorreu.

Inventariar aplicações com acesso na sua organização

Você pode inventariar aplicativos para seus usuários usando o centro de administração do Microsoft Entra, PowerShell, ou fazer com que seus usuários enumerem individualmente seu acesso ao aplicativo.

  • Use o centro de administração do Microsoft Entra para inventariar aplicativos e suas permissões. Este método é completo, mas você só pode verificar um usuário de cada vez, o que pode ser demorado se você tiver que verificar as permissões de vários usuários.
  • Use o PowerShell para inventariar aplicativos e suas permissões. Este método é o mais rápido e completo, com a menor quantidade de sobrecarga.
  • Incentive seus usuários a verificar individualmente seus aplicativos e permissões e relatar os resultados aos administradores para correção.

Inventariar aplicativos atribuídos aos usuários

Pode utilizar o centro de administração do Microsoft Entra para ver a lista de aplicações às quais os utilizadores individuais concederam permissões.

  1. Entre no Portal do Azure com direitos administrativos.
  2. Selecione o ícone ID do Microsoft Entra .
  3. Selecione Utilizadores.
  4. Selecione o usuário que você deseja revisar.
  5. Selecione Aplicativos.

Você pode ver a lista de aplicativos atribuídos ao usuário e as permissões concedidas a esses aplicativos.

Determinar o escopo do ataque

Depois de concluir o inventário do acesso ao aplicativo, revise o log de auditoria para determinar o escopo completo da violação. Pesquise sobre os usuários afetados, os períodos de tempo em que o aplicativo ilícito teve acesso à sua organização e as permissões que o aplicativo tinha. Você pode pesquisar o log de auditoria nos portais de conformidade do Microsoft 365 Security & Microsoft Purview.

Importante

Se a auditoria não estava habilitada antes do possível ataque, você não poderá investigar porque os dados de auditoria não estão disponíveis.

Como prevenir ataques e mitigar riscos?

Se a sua organização tiver a licença apropriada:

  • Use mais recursos de auditoria de aplicativos OAuth no Microsoft Defender for Cloud Apps.
  • Use as Pastas de Trabalho do Azure Monitor para monitorar permissões e atividades relacionadas ao consentimento. A pasta de trabalho do Consent Insights fornece uma exibição de aplicativos por número de solicitações de consentimento com falha. Isso pode ser útil para priorizar aplicativos para que os administradores analisem e decidam se concedem o consentimento de administrador.

Depois de identificar um aplicativo com permissões ilícitas, desative imediatamente o aplicativo seguindo as instruções em Desativar um aplicativo. Em seguida, contate o Suporte da Microsoft para denunciar o aplicativo mal-intencionado.

Depois que um aplicativo é desabilitado no Microsoft Entra, ele não pode obter novos tokens para acessar dados e outros usuários não podem entrar ou conceder consentimento para o aplicativo.

Nota

Se suspeitar que encontrou uma aplicação maliciosa na sua organização, é melhor desativá-la do que eliminá-la. Se você excluir apenas o aplicativo, ele poderá retornar mais tarde se outro usuário conceder consentimento. Em vez disso, desative o aplicativo para garantir que ele não possa voltar mais tarde.

Passos para proteger a sua organização

Existem vários tipos de ataques de consentimento, essas defesas recomendadas mitigam todos os tipos de ataques, especialmente o phishing de consentimento, em que os invasores enganam os usuários para que concedam a um aplicativo mal-intencionado acesso a dados confidenciais ou outros recursos. Em vez de tentar roubar a senha do usuário, um invasor está buscando permissão para que um aplicativo controlado pelo invasor acesse dados valiosos.

Para ajudar a evitar que ataques de consentimento afetem o Microsoft Entra ID e o Office 365, consulte as seguintes recomendações:

Definir políticas

  • Essa configuração tem implicações para o usuário e pode não ser aplicável a um ambiente. Se você vai permitir algum consentimento, certifique-se de que os administradores aprovem as solicitações.

  • Permita consentimentos apenas para aplicativos de editores verificados e tipos específicos de permissões classificadas como de baixo impacto.

    Nota

    As recomendações acima são sugeridas com base nas configurações mais ideais e seguras. No entanto, como a segurança é um bom equilíbrio entre funcionalidades e operações, as configurações mais seguras podem causar mais sobrecarga aos administradores. É uma decisão que deve ser tomada depois de consultar os administradores.

    Configurar o consentimento step-up baseado em risco - Ativado por padrão se o consentimento do usuário para concessões estiver habilitado

  • O consentimento intensificado baseado no risco ajuda a reduzir a exposição do utilizador a aplicações maliciosas que fazem pedidos de consentimento ilícitos. Se a Microsoft detetar uma solicitação de consentimento do usuário final arriscada, a solicitação exigirá um "passo" para o consentimento do administrador. Esse recurso é habilitado por padrão, mas só resulta em uma alteração de comportamento quando o consentimento do usuário final é habilitado.

  • Quando uma solicitação de consentimento arriscada é detetada, o prompt de consentimento exibe uma mensagem indicando que a aprovação do administrador é necessária. Se o fluxo de trabalho de solicitação de consentimento do administrador estiver habilitado, o usuário poderá enviar a solicitação ao administrador para revisão adicional diretamente do prompt de consentimento. Se habilitado, a seguinte mensagem é exibida:

    AADSTS90094: <clientAppDisplayName> precisa de permissão para acessar recursos em sua organização que somente um administrador pode conceder. Por favor, peça a um administrador para conceder permissão a este aplicativo antes de poder usá-lo. Nesse caso, um evento de auditoria também será registrado com uma categoria de "ApplicationManagement" Tipo de atividade "Consentimento para aplicativo" e Status Motivo de "Aplicativo arriscado detetado".

Nota

Todas as tarefas que exigem a aprovação do administrador têm sobrecarga operacional. A opção "Consentimento e permissões, configurações de consentimento do usuário" está na visualização atualmente. Quando estiver pronto para disponibilidade geral (GA), o recurso "Permitir o consentimento do usuário de editores verificados, para permissões selecionadas" deve reduzir a sobrecarga dos administradores e é recomendado para a maioria das organizações.

Exemplo de captura de tela de permissões de consentimento.

Eduque seus desenvolvedores de aplicativos a seguir o ecossistema de aplicativos confiáveis. Para ajudar os desenvolvedores a criar integrações seguras e de alta qualidade, também estamos anunciando a visualização pública do Assistente de Integração nos registros de aplicativos do Microsoft Entra.

  • O Assistente de Integração analisa o registo da sua aplicação e compara-a com um conjunto de práticas recomendadas de segurança.
  • O Assistente de Integração destaca as práticas recomendadas que são relevantes durante cada fase do ciclo de vida da integração, desde o desenvolvimento até o monitoramento, e garante que cada estágio seja configurado corretamente.
  • Torna o seu trabalho mais fácil, quer esteja a integrar a sua primeira aplicação ou seja um especialista à procura de melhorar as suas competências.

Eduque sua organização sobre táticas de consentimento (táticas de phishing, consentimento de administradores e usuários):

  • Verifique se há erros ortográficos e gramaticais. Se uma mensagem de e-mail ou a tela de consentimento do aplicativo tiver erros ortográficos e gramaticais, é provável que seja um aplicativo suspeito.
  • Fique atento aos nomes de aplicativos e URLs de domínio. Os atacantes gostam de falsificar nomes de aplicativos que fazem parecer que vêm de aplicativos ou empresas legítimas, mas levam você a consentir com um aplicativo mal-intencionado.
  • Certifique-se de reconhecer o nome do aplicativo e a URL do domínio antes de consentir com um aplicativo.

Promova e permita o acesso a aplicações em que confia

  • Promova o uso de aplicativos que são verificados pelo editor. A verificação do editor ajuda os administradores e os usuários finais a entender a autenticidade dos desenvolvedores de aplicativos. Até à data, foram verificadas mais de 660 candidaturas de 390 editores.
  • Configure políticas de consentimento de aplicativos permitindo que os usuários consintam apenas com aplicativos específicos em que você confia, como aplicativos desenvolvidos por sua organização ou de editores verificados.
  • Eduque a sua organização sobre como funciona a nossa estrutura de permissões e consentimento.
  • Entenda os dados e permissões que um aplicativo está solicitando e entenda como as permissões e o consentimento funcionam em nossa plataforma.
  • Garantir que os administradores saibam como gerenciar e avaliar solicitações de consentimento.

Audite aplicativos e permissões consentidas em sua organização para garantir que os aplicativos que estão sendo usados estejam acessando apenas os dados de que precisam e aderindo aos princípios de menor privilégio.

Mitigações

  • Educar o cliente e fornecer conscientização e treinamento sobre como garantir concessões de consentimento de aplicativo
  • Apertar o processo de concessão de consentimento de aplicativo com política organizacional e controles técnicos
  • Configurar Criar agendamento para rever Aplicações autorizadas
  • Você pode usar o PowerShell para desabilitar aplicativos suspeitos ou mal-intencionados desativando o aplicativo

Conteúdos relacionados

Manuais adicionais de resposta a incidentes

Examine as orientações para identificar e investigar esses tipos adicionais de ataques:

Recursos de resposta a incidentes