Compartilhar via

Investigação de fornecimento de consentimento do aplicativo

  • Artigo

Este artigo fornece diretrizes de como identificar e investigar ataques de consentimento de aplicativo, proteger informações e minimizar outros riscos.

Este artigo inclui as seções a seguir:

  • Pré-requisitos: esta seção cobre os requisitos específicos que você precisa concluir para iniciar a investigação. Por exemplo, os registros em log que devem ser ativados, as funções e as 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 no fluxograma. Essa lista de verificação pode ser útil em ambientes altamente regulamentados para verificar as etapas adotadas ou simplesmente como um controle de qualidade do seu trabalho.
  • Etapas de investigação: esta seção inclui diretrizes passo a passo detalhadas desta investigação específica.
  • Recuperação: contém etapas gerais sobre a recuperação e a mitigação após um ataque de fornecimento de consentimento de aplicativo ilícito.
  • Referências: contém mais materiais de leitura e referência.

Pré-requisitos

Aqui estão as definições e configurações gerais que você deve concluir ao executar uma investigação de fornecimentos de consentimento de aplicativo. Antes de iniciar a investigação, certifique-se de ler 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:

  • Detalhes dos IoCs (indicadores de comprometimento)
  • A data e a hora em que você percebeu o incidente
  • Intervalo de datas
  • Número de contas comprometidas
  • Nome das contas comprometidas
  • Funções da conta comprometida
  • As contas são altamente privilegiadas (Microsoft Exchange e SharePoint em GA)?
  • Há algum aplicativo empresarial relacionado ao incidente?
  • Algum usuário relatou que algum aplicativo solicitou permissões para dados em nome dele?

Requisitos do sistema

Conclua as seguintes instalações e requisitos de configuração verificando se:

  1. O módulo do AzureAD PowerShell está instalado.
  2. Você tem direitos de Administrador Global no locatário em que o script é executado.
  3. Você recebeu a função de administrador local no computador que você usa para executar os scripts.

Observação

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

Recomendamos migrar para o Microsoft Graph PowerShell para interagir com o Microsoft Entra ID (antigo Azure AD). Para perguntas comuns sobre migração, consulte as Perguntas Frequentes sobre Migração. Observação: as versões 1.0.x do MSOnline poderão 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

Observação

Se for solicitado que você instale os módulos de um repositório não confiável, digite Y e pressione Enter.

Instalar o módulo MSOnline do PowerShell

  1. Execute o aplicativo Windows PowerShell com privilégios elevados (execute-o 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

    Observação

    Se for solicitado que você instale os módulos de um repositório não confiável, digite Y e pressione Enter.

Baixar o script AzureADPSPermissions do GitHub

  1. Baixar o script Get-AzureADPSPermissions.ps1 do GitHub em uma pasta que você usa para executar o script. O arquivo de saída "permissions.csv" também fica gravado nessa mesma pasta.

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

  3. Conecte-se com o diretório usando o cmdlet Connect-AzureAD. Veja 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 a sessão do AzureAD com este comando.

    Disconnect-AzureAD

Consentimento é o processo de conceder autorização a um aplicativo para acessar recursos protegidos em nome dos usuários. Um administrador ou usuário pode ser solicitado a dar consentimento para permitir acesso aos dados dele ou da organização.

Um aplicativo recebe acesso a dados de um usuário específico ou de 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 fornecimentos de consentimento ilícitos, que podem ocorrer por um email de phishing, uma conta de usuário comprometida por pulverização de senha ou quando um invasor registra um aplicativo como um usuário legítimo. Nos cenários em que uma conta do administrador é comprometida, o registro e o fornecimento de consentimento ocorrem para todo o locatário e não apenas para um usuário.

Antes que um aplicativo possa acessar os dados da sua organização, um usuário precisa conceder permissões ao aplicativo para isso. Permissões diferentes permitem diferentes níveis de acesso. Por padrão, todos os usuários têm permissão para consentir nos aplicativos em relação a permissões que não exijam o consentimento do administrador. Por exemplo, por padrão, um usuário pode permitir que um aplicativo acesse a caixa de correio dele, mas não pode permitir que um aplicativo tenha acesso irrestrito de leitura e gravação em todos os arquivos da organização.

Observação

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

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

  • Administrador de Aplicativos
  • Administrador de Aplicativos de Nuvem
  • Administrador – Indica que o consentimento foi fornecido pelo administrador (em nome da organização)
  • Usuário individual: indica que o consentimento foi fornecido pelo usuário e só permite o acesso às informações desse usuário
  • Valores aceitos
    • AllPrincipals – Fornecido por um administrador para toda a locação
    • Principal – Fornecido pelo usuário individual somente para dados relacionados a essa conta

Na realidade, a experiência do usuário de dar consentimento varia de acordo com as políticas definidas no locatário do usuário, o escopo (ou a função) do usuário da autoridade e o tipo de permissões solicitado 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 no locatário. Os desenvolvedores de aplicativos podem determinar que tipos de permissões são solicitados e se querem orientar os usuários por meio do fluxo de consentimento do usuário ou do 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 da autorização com a intenção de registrar o consentimento somente 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 registrar o consentimento para o locatário inteiro. Para garantir que o fluxo de consentimento do administrador funcione corretamente, os desenvolvedores de aplicativos precisam listar todas as permissões na propriedade RequiredResourceAccess no manifesto do aplicativo.

Permissões delegadas versus permissões de aplicativo

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 aplicativo são usadas por aplicativos que são executados sem um usuário conectado presente. Por exemplo, aplicativos executados como serviços ou daemons em segundo plano. As permissões de aplicativo só podem ser concedidas por um administrador.

Para saber mais, veja:

Como classificar permissões suspeitas

Há no mínimo milhares de permissões no sistema e não é possível listar ou analisar todas elas. A lista a seguir demonstra as permissões que geralmente são usadas indevidamente e outras que podem causar um impacto catastrófico quando isso ocorre.

Em geral, a Microsoft observou que as permissões “raiz” delegadas a seguir (aplicativo + usuário) são usadas indevidamente em ataques de phishing de consentimento. A raiz é igual ao nível máximo. Por exemplo, Contacts.* significa incluir todas as permutações delegadas das permissões de Contatos: Contacts.Read, Contacts.ReadWrite, Contacts.Read.Shared e Contacts.ReadWrite.Shared.

  1. Mail.* (inclui Mail.Send*, mas não Mail.ReadBasic*)
  2. Contatos. *
  3. MailboxSettings.*
  4. People.*
  5. Files.*
  6. Notes.*
  7. Directory.AccessAsUser.All
  8. User_Impersonation

As sete primeiras permissões na lista acima são para o Microsoft Graph e os equivalentes da API “herdada”, como a API do Graph do Azure AD (Azure Active Directory) e a API REST do Outlook. A oitava permissão é para o ARM (Azure Resource Manager) e também pode ser perigosa em qualquer API que exponha dados confidenciais com esse escopo amplo de representação.

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 acha que a versão delegada de Mail.Read ou Files.Read é uma permissão de alto risco. No entanto, os ataques geralmente são generalizados direcionados aos usuários finais, em vez de ataques de spear phishing contra administradores que realmente podem dar consentimento para permissões perigosas. É recomendado restringir os aplicativos com essas permissões de impacto de nível “crítico”. Mesmo que o aplicativo não tenha má intenção, se um ator mal-intencionado quiser comprometer a identidade do aplicativo, toda a organização poderá estar em risco.

Para as permissões de impacto de risco mais alto, 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
  • Domain.ReadWrite.All*
  • EduRoster.ReadWrite.All*
  • Group.ReadWrite.All
  • Member.Read.Hidden*
  • RoleManagement.ReadWrite.Directory
  • User.ReadWrite.All*
  • User.ManageCreds.All
  • Todas as outras permissões AppOnly que permitem acesso de gravação

Para a lista de permissões de impacto de risco mais baixo, comece aqui:

  • User.Read
  • User.ReadBasic.All
  • Open_id
  • Email
  • Perfil
  • Offline_access (somente se emparelhada com outras permissões nessa lista de “riscos mais baixos”)

Como ver as permissões

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

    ver as permissões

  2. Selecione Ver as permissões da API.

    apipermissions

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

    api

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

    tipos de permissões

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

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

    examplepermission

  7. Selecione EduRoster e expanda as permissões.

    eduroster

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

    Para obter mais informações, Permissões do Graph.

Workflow

[Fluxo de trabalho de investigação de fornecimento de consentimento do aplicativo]

Também é possível:

  • Baixe os fluxos de trabalho de guia estratégico de resposta a concessão de consentimento de aplicativo e outros incidentes no formato PDF.
  • Baixe os fluxos de trabalho de guia estratégico de resposta a concessão de consentimento de aplicativo e outros incidentes no formato Visio.

Lista de Verificação

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

  • IoC (indicadores de comprometimento)

    Verifique os seguintes IoC (indicadores de comprometimento):

    • Quando você percebeu o incidente?
    • Intervalo de datas do incidente (há quanto tempo ele começou?)
    • Número de contas comprometidas
    • Nomes das 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ê precisa receber estas funções:

    • Direitos de administrador global no locatário para executar o script
    • Função Administrador local no computador que executa o script

  • Configuração do PowerShell

    Configure o ambiente do PowerShell com as etapas a seguir:

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

  • Gatilhos de investigação

    • Comprometimento da conta
    • Configurações de consentimento do aplicativo modificadas no locatário
    • Motivo do status do evento de alerta/auditoria "aplicativo suspeito" detectado
    • Aplicativos de aparência ímpar observados

Você também pode baixar as listas de verificação do guia estratégico de concessão de consentimento de aplicativo e outros incidentes no formato Excel.

Etapas de investigação

Você pode usar os dois métodos seguintes para investigar os fornecimentos de consentimento de aplicativo:

  • Portal do Azure
  • Script do PowerShell

Observação

O uso do portal do Azure, só permite que você veja os fornecimentos de consentimento do administrador dos últimos 90 dias. Por isso, é recomendado usar o método de script do PowerShell somente para reduzir as etapas de investigação de registros de invasor.

Método 1 – Usando o portal do Azure

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

  1. Entre no Portal do Azure como administrador.
  2. Selecione o ícone Microsoft Entra ID.
  3. Selecione Usuários.
  4. Selecione o usuário que você deseja examinar.
  5. Selecione Aplicativos.
  6. Veja 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 os fornecimentos de consentimento ilícitos, como:

O PowerShell é a ferramenta mais fácil e não exige nenhuma modificação na locação. Vamos basear nossa investigação na documentação pública do ataque de fornecimento de consentimento ilícito.

Execute Get-AzureADPSPermissions.ps1, para exportar todos os fornecimentos de consentimento do OAuth e os aplicativos OAuth de todos os usuários na locação para um arquivo .csv. Confira a seção Pré-requisitos para baixar e executar o script Get-AzureADPSPermissions.

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

  2. Conecte-se com o diretório usando o comando Connect-AzureAD a seguir. Veja 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, desconecte a sessão do Microsoft Entra com este comando.

     Disconnect-AzureAD

    Observação

    O script pode levar horas para ser concluído, dependendo do tamanho e das permissões configuradas, bem como da 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-os como um arquivo .xlxs.

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

    Exemplo de cabeçalhos de coluna

  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 são da Microsoft com essa permissão devem ser examinados com atenção.

  8. Na coluna Permission(F), examine as permissões que cada aplicativo delegado tem. Procure a permissão de leitura e gravação ou permissão *. Todos, e revise essas permissões cuidadosamente porque elas podem não ser apropriadas. Exemplo da coluna Permission F

    Observação

    Examine os usuários específicos que receberam consentimentos. Se há usuários de perfil superior ou de alto impacto com consentimentos inadequados, investigue mais.

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

    • Aplicativos com nomes incorretos Exemplo de um nome escrito incorretamente

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

    • Nomes que parecem de hacker. Você precisa examinar esses nomes com atenção. Exemplo de um nome de hacker

Saída de exemplo: AllPrincipals e ler e gravar tudo. Os aplicativos podem não ter nada suspeito como nomes combinados e estão usando o Microsoft Graph. No entanto, execute a pesquisa e determine a finalidade dos aplicativos e as permissões reais que eles têm no locatário, como é mostrado neste exemplo.

Exemplo de aplicativos com o ConsentType AllPrincipals

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

  1. ReplyURL/RedirectURL
    • Procurar URLs suspeitas
  2. A URL está hospedada em um domínio suspeito?
    • Ela está comprometida?
    • O domínio foi registrado recentemente?
    • É um domínio temporário?
  3. Há um link dos termos de serviço ou do contrato de serviço no registro de aplicativo?
  4. O conteúdo é exclusivo e específico do aplicativo/editor?
  5. O locatário que registrou o aplicativo foi criado recentemente ou está comprometido (por exemplo, o aplicativo foi registrado por um usuário em risco)?

Técnicas de ataque

Embora os ataques possam variar, as principais técnicas de ataque são:

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

  • Os aplicativos são configurados de maneira que os faz parecer legítimos. Por exemplo, os invasores 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 phishing baseado em email convencional, pelo comprometimento de um site que não é mal-intencionado ou com outras técnicas.

  • O usuário seleciona o link e recebe uma solicitação de consentimento autêntico solicitando que ele conceda permissões a dados ao aplicativo mal-intencionado.

  • Se o usuário selecionar ‘Aceitar’, ele concede permissões ao aplicativo para acessar dados confidenciais.

  • O aplicativo obtém um código de autorização, com o qual resgata um token de acesso e, possivelmente, um token de atualização.

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

  • Quando o usuário aceita isso, o invasor pode obter acesso aos emails do usuário, às regras de encaminhamento, aos arquivos, aos contatos, às anotações, ao perfil e a outros dados e recursos confidenciais.

    Exemplo de solicitação de permissões

Como encontrar sinais de um ataque

  1. No portal do Microsoft 365 Defender, em https://security.microsoft.com, acesse Auditar. Ou vá diretamente para a página Auditoria e 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 uma pesquisa de logs de auditoria

  3. Selecione Filtrar os resultados e, no campo Atividade, insira Consentir para aplicativo.

    Exemplo de filtragem de uma pesquisa de logs de auditoria

  4. Se você tem alguma atividade em consentir com o fornecimento, 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’.

    Observação

    Esse processo pode levar de 30 minutos a 24 horas para que a entrada de log de auditoria correspondente seja exibida nos resultados da pesquisa depois que um evento ocorre.

    O período em que um registro de auditoria fica retido e pesquisável no log de auditoria depende da sua assinatura do Microsoft 365 e, especificamente, do tipo da licença atribuída a um usuário específico. Se esse valor for verdadeiro, ele indicará que alguém com acesso de Administrador Global pode ter concedido amplo acesso aos dados. Se isso for inesperado, tome medidas imediatas para confirmar um ataque.

Como confirmar um ataque?

Se você tem uma ou mais instâncias dos IoCs listados anteriormente, continue a investigação para confirmar se o ataque realmente ocorreu.

Inventariar os aplicativos com acesso na organização

Você pode inventariar os aplicativos dos usuários usando o centrode administração do Microsoft Entra, o PowerShell ou solicitar que os usuários enumerem individualmente o acesso a aplicativos.

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

Inventariar os aplicativos atribuídos aos usuários

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

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

Veja 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 de aplicativos, examine o log de auditoria para determinar o escopo completo da violação. Pesquise os usuários afetados, os períodos em que o aplicativo ilícito teve acesso à 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 e Microsoft Purview.

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

Como evitar ataques e mitigar riscos?

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

  • Use outros mais recursos de auditoria do aplicativo OAuth no Microsoft Defender para Aplicativos de Nuvem.
  • Use as Pastas de Trabalho do Azure Monitor para monitorar as permissões e as atividades relacionadas a consentimento. A pasta de trabalho Insights de Consentimento oferece uma exibição de aplicativos por número de solicitações de consentimento com falha. Essa exibição pode ser útil para priorizar os aplicativos a serem examinados pelos administradores para que eles decidam se o consentimento do administrador deve ser fornecido.

Depois de identificar um aplicativo com permissões ilícitas, desabilite imediatamente o aplicativo seguindo as instruções em Desabilitar um aplicativo. Em seguida, contate o Suporte da Microsoft para relatar 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 ao aplicativo.

Observação

Se você suspeitar que encontrou um aplicativo mal-intencionado em sua organização, é melhor desabilitá-lo do que excluí-lo. Se você excluir apenas o aplicativo, ele poderá retornar mais tarde se outro usuário fornecer consentimento. Em vez disso, desabilite o aplicativo para garantir que ele não possa voltar mais tarde.

Etapas para proteger a organização

Há vários tipos de ataque de consentimento; estas defesas recomendadas mitigam todos os tipos de ataques, principalmente o phishing de consentimento, no qual os invasores enganam os usuários para que eles permitam que um aplicativo mal-intencionado acesse dados confidenciais ou outros recursos. Em vez de tentar roubar a senha do usuário, o invasor tenta obter permissão para que um aplicativo controlado por ele acesse dados importantes.

Como uma ajuda para evitar que ataques de consentimento afetem o Microsoft Entra ID e o Office 365, confira as seguintes recomendações:

Definir políticas

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

  • Permita o consentimento para aplicativos somente de editores verificados e tipos específicos de permissões classificados como baixo impacto.

    Observação

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

    Configurar o consentimento de step-up com base em risco – Opção habilitada por padrão quando o consentimento do usuário com o fornecimento está habilitado

  • O consentimento de step-up baseado em risco ajuda a reduzir a exposição do usuário a aplicativos mal-intencionados que fazem solicitações de consentimento ilícitas. Se a Microsoft detectar uma solicitação arriscada de consentimento ao usuário final, a solicitação exige um "step-up" para o consentimento do administrador. Essa capacidade é habilitada por padrão, mas só resulta em uma alteração de comportamento quando o consentimento do usuário final estiver habilitado.

  • Quando uma solicitação de consentimento arriscado for detectada, a solicitação de consentimento exibe uma mensagem indicando que a aprovação do administrador é necessária. Quando o fluxo de trabalho de solicitação de consentimento do administrador está habilitado, o usuário pode enviar a solicitação ao administrador para exame adicional diretamente da solicitação de consentimento. Quando habilitado, a seguinte mensagem é exibida:

    AADSTS90094: <clientAppDisplayName> precisa de permissão para acessar recursos em sua organização que somente um administrador pode conceder. Peça a um administrador para conceder permissão ao aplicativo antes de poder usá-lo. Nesse caso, um evento de auditoria também será registrado com a categoria "ApplicationManagement" Tipo de atividade "Consentimento para aplicativo" e a razão do status "Aplicativo arriscado detectado".

Observação

Todas as tarefas que exigem aprovação do administrador têm uma sobrecarga operacional. As "configurações Consentimento e permissões, Consentimento do usuário" estão em Versão prévia no momento. Quando estiver pronto para GA (disponibilidade geral), o recurso "Permitir o consentimento do usuário de editores verificados, para permissões selecionadas" deverá reduzir a sobrecarga dos administradores e será recomendado para a maioria das organizações.

consentimento

Instrua os desenvolvedores de aplicativos a seguir o ecossistema de aplicativos confiável. Para ajudar os desenvolvedores a criar integrações seguras e de alta qualidade, também estamos anunciando a versão prévia pública do Assistente de Integração nos registros de aplicativo do Microsoft Entra.

  • O Assistente de Integração analisa o registro de aplicativo e avalia-o em relação a um conjunto de práticas recomendadas de segurança.
  • O Assistente de Integração realça 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 esteja configurado corretamente.
  • Ele facilita seu trabalho, esteja você integrando seu primeiro aplicativo ou buscando aprimorar suas habilidades de especialista.

Instrua sua organização sobre táticas de consentimento (táticas de phishing, consentimentos do administrador e do usuário):

  • Verifique se há erros ortográficos e gramaticais. Se uma mensagem de email ou a tela de consentimento do aplicativo tem erros ortográficos e gramaticais, provavelmente se trata de um aplicativo suspeito.
  • Fique atento a nomes de aplicativos e URLs de domínio. Os invasores gostam de falsificar nomes de aplicativos para parecer que o aplicativo ou a empresa é legítima, fazendo com que você dê consentimento a um aplicativo mal-intencionado.
  • Faça um reconhecimento do nome do aplicativo e da URL do domínio antes de consentir com um aplicativo.

Promover e permitir acesso a aplicativos confiáveis

  • Promova o uso de aplicativos cujos editores já foram verificados. A verificação do editor ajuda os administradores e os usuários finais a entender a autenticidade dos desenvolvedores de aplicativos. Mais de 660 aplicativos de 390 editores já foram verificados até o momento.
  • Configure políticas de consentimento de aplicativo permitindo que os usuários consintam apenas com aplicativos específicos nos quais você confia, como aplicativos desenvolvidos pela sua organização ou de editores verificados.
  • Instrua sua organização sobre como nossa estrutura de permissões e consentimento funciona.
  • Entenda os dados e as permissões que um aplicativo está solicitando e como as permissões e o consentimento funcionam na nossa plataforma.
  • Verifique se os administradores sabem como gerenciar e avaliar as solicitações de consentimento.

Audite os aplicativos e as permissões consentidas na organização para garantir que os aplicativos usados acessem apenas os dados necessários e sigam os princípios de privilégios mínimos.

Mitigações

  • Instruir o cliente e oferecer treinamento sobre como reconhecer e proteger os fornecimentos de consentimento de aplicativo
  • Reforçar o processo de fornecimento de consentimento de aplicativo com uma política organizacional e controles técnicos
  • Configurar a opção Criar agendamento para examinar os aplicativos Consentidos
  • Você pode usar o PowerShell para desabilitar aplicativos suspeitos ou mal-intencionados desabilitando o aplicativo

Conteúdo relacionado

Mais guias estratégicos de resposta a incidente

Examine as diretrizes para identificar e investigar esses tipos adicionais de ataques:

Recursos de resposta a incidentes