Resource Access Management:Govern permissions with Access Analyzer

Investigue antes de agir

Algoritmos e dados de acesso geram as recomendações de correção, mas não compreendem totalmente o contexto do seu negócio. Antes de aplicar qualquer recomendação, confirme se a identidade ou recurso alvo realmente não precisa mais das permissões em questão.

• Para identidades críticas à produção (como funções de operações, funções de CI/CD ou funções RAM usadas por aplicativos principais), entre em contato com o responsável pelo negócio para confirmação.

• Nas recomendações de remoção de política, verifique os campos Accessed services, Granted services e Last accessed time na página de detalhes da descoberta para determinar se a permissão está realmente sem uso.

• Em descobertas de acesso externo, examine o principal externo específico na página de detalhes para confirmar se a relação de acesso é necessária para o seu negócio.

Escolha uma janela de mudança apropriada

A convergência de permissões pode afetar cargas de trabalho em execução. Recomendamos:

• Evite alterar permissões durante o horário comercial de pico ou janelas importantes de lançamento.

• Para identidades RAM usadas por aplicativos de produção online, verifique primeiro o impacto de mudanças equivalentes de permissão em um ambiente de teste.

• No caso de recursos entre contas (cenários de diretório de recursos), coordene a janela de mudança com o administrador da conta de destino antecipadamente.

Prepare procedimentos de reversão

Antes de executar qualquer operação de convergência de permissões, garanta a capacidade de reverter rapidamente. As medidas específicas incluem:

• Registre o estado anterior à mudança: Antes de remover uma política, registre todas as políticas atualmente anexadas à identidade alvo, incluindo nome e tipo da política (sistema ou personalizada).

• Mantenha uma cópia das políticas personalizadas: Antes de remover uma política personalizada, exporte e faça backup do conteúdo da política para evitar falhas na reautorização caso a definição da política seja excluída acidentalmente.

• Evite excluir identidades imediatamente: Para usuários RAM inativos, desative primeiro o logon no console e as AccessKeys. Observe por um período antes de decidir pela exclusão, permitindo restaurar o acesso rapidamente em caso de erros.

• Conheça os comandos de reversão: Para operações de desautorização realizadas no console, utilize a OpenAPI do RAM (AttachPolicyToUser, AttachPolicyToRole) para restaurar permissões rapidamente quando necessário. Para obter detalhes, consulte a seção Reversão e recuperação neste tópico.

Descoberta

Uma descoberta é um objeto de dados gerado pelo Access Analyzer que contém:

• Tipo de descoberta: A categoria da descoberta. Exemplos:

  • super user/role

  • privileged user/role

  • inactive user/role

  • over-privileged user/role

• Status: O status da descoberta. Valores válidos: Active, Resolved e Archived.

• Informações do recurso: Nome, tipo e proprietário do recurso alvo.

• Carimbos de data/hora: Created At, Analysis Time e Updated At.

• ID da descoberta: O identificador exclusivo da descoberta.

Recomendação de correção

A recomendação de correção é a solução que o Access Analyzer gera para uma descoberta:

• Substituição de permissão: Substitua uma política que concede permissões amplas por uma política mais restritiva. Por exemplo, substitua a permissão de superadministrador (AdministratorAccess) pela permissão de administrador de sistema (PowerUserAccess).

• Remoção de permissão: Remova uma política não utilizada.

• Gerenciamento de identidade: Desative ou exclua uma identidade inativa.

• Arquivamento de descoberta: Arquive descobertas associadas a comportamentos de autorização intencionais.

Lógica de decisão

O Access Analyzer classifica o acesso com privilégios excessivos pela seguinte prioridade. Se uma identidade RAM corresponder a várias condições, aplica-se o tipo de maior prioridade.

Pré-requisitos

Certifique-se de que os seguintes requisitos sejam atendidos:

• Existe um analisador do tipo Over-privileged Access no console do Access Analyzer.

• Você possui as permissões necessárias. Recomendamos conceder as políticas AliyunRAMAccessAnalyzerFullAccess e AliyunRAMFullAccess ao operador.

Procedimento

1. Localize uma descoberta

   1. Faça logon no console RAM.

   2. No painel de navegação à esquerda, escolha Access Analysis > Findings.

   3. Na barra de navegação superior, selecione a região onde o analisador está localizado.

   4. Na aba Findings > Overview, encontre uma descoberta Ativa do tipo Inactive User e clique em no número.

2. Visualize e aplique a recomendação de correção

   1. Na lista de Findings, selecione um usuário RAM que você confirmou não ser mais necessário e clique em no Finding ID correspondente.

   2. Na página de detalhes de Findings, clique em na aba Advices na coluna Actions. Após uma breve espera, o sistema exibe a sugestão Remove unused identities. Clique em Go for Governance.

4. Você será redirecionado para a página de detalhes do usuário no console RAM. Desative o logon no console, desative uma AccessKey ou exclua o usuário conforme as necessidades do seu negócio.

5. Verifique o resultado. Retorne ao console do Access Analyzer. Arquive a descoberta se desejar. Caso contrário, o status mudará automaticamente para Resolved após o próximo ciclo de análise.

Manuais de correção de acesso com privilégios excessivos

Use estes manuais para aplicar a correção correta para cada tipo de descoberta.

Nota

As descobertas do analisador de acesso com privilégios excessivos refletem o uso de permissões dentro do período de análise. Algumas permissões podem não ter sido usadas durante esse período, mas ainda serem necessárias em cenários específicos (como liquidações trimestrais, simulados de recuperação de desastres ou implantações de lançamento). Avalie com base nas necessidades reais do seu negócio antes de tomar medidas.

Corrigir super users/roles: Substituir por permissões de administrador de sistema

Identidades de superadministrador geralmente possuem a política AdministratorAccess, que concede permissões de gerenciamento em todos os recursos da conta. Essas identidades têm o nível de risco mais alto — um vazamento de credenciais teria impacto em toda a conta. Se a identidade realmente precisar de permissões de administrador (esperado), ative o MFA para o usuário RAM e arquive a descoberta. Se a identidade não precisar de permissões completas de administrador (inesperado), substitua por PowerUserAccess (mantém todas as permissões de gerenciamento, exceto permissões relacionadas a RAM e faturamento).

1. Na aba Findings > Overview ou Findings > Findings, localize uma entrada cujo Finding Type seja super user/role e clique em no Finding ID específico.

2. Na página de detalhes de Findings, clique em na aba Advices.

3. No painel Advices, encontre a recomendação para substituir as permissões por permissões de administrador de sistema (PowerUserAccess).

4. Execute a operação apropriada com base no proprietário do recurso:

   • Conta atual: Clique em Apply Recommendation. O sistema anexa automaticamente a política PowerUserAccess à identidade alvo e, em seguida, desanexa a política AdministratorAccess.

     

   • Entre contas: A aplicação automática não é suportada. Clique em Repeat para copiar a URL. Em seguida, faça logon na conta à qual o recurso alvo pertence, acesse a URL e substitua as permissões manualmente.

     

5. (Opcional) Se o analisador não fornecer recomendações de correção, consulte Por que não há recomendação de correção para minha descoberta?

Importante

Riscos e reversão: Esta operação altera permissões principais. Antes de prosseguir, certifique-se de que a política PowerUserAccess atenda aos requisitos diários de trabalho da identidade. Se ocorrer um problema após a operação, acesse o console RAM e reconceda imediatamente a permissão AdministratorAccess à identidade.

Corrigir super users/roles: Remover políticas não utilizadas

Se políticas de sistema ou personalizadas não utilizadas também estiverem anexadas à identidade de superusuário, o sistema recomenda removê-las. Uma recomendação separada é gerada para cada política.

1. Na aba Findings > Overview ou Findings > Findings, localize uma entrada cujo Finding Type seja super user/role e clique em no Finding ID específico.

2. Na página de detalhes de Findings, clique em na aba Advices na coluna Actions.

3. No painel Advices, encontre a recomendação para remover a política.

4. Execute a operação apropriada com base no proprietário do recurso:

   • Conta atual: Clique em Apply Recommendation. O sistema desanexa a política automaticamente.

     

   • Entre contas: Clique em Repeat para copiar a URL. Faça logon na conta de destino, acesse a URL e desanexe a política manualmente.

5. (Opcional) Se o analisador não fornecer recomendações de correção, consulte Por que não há recomendação de correção para minha descoberta?

Riscos e reversão: Confirme se a política não é mais necessária. Se você a remover acidentalmente, reconceda a política de permissão removida à identidade no console RAM.

Corrigir privileged users/roles: Remover políticas de alto risco não utilizadas

Para um privileged user/role, a recomendação de correção é remover políticas de permissão de alto risco não utilizadas. O procedimento é o mesmo descrito em Corrigir super users/roles: Remover políticas de permissão não utilizadas.

Corrigir inactive users/roles: Desativar ou excluir identidades

Identidades inativas não tiveram atividade de acesso dentro do período de acesso não utilizado especificado. Identidades ociosas por longo tempo com credenciais válidas representam um risco potencial de segurança.

Antes de tomar medidas, confirme: se a identidade é usada sazonalmente ou periodicamente (como para liquidações financeiras de fim de mês ou auditorias trimestrais); se é uma conta reserva ou de recuperação de desastres (que normalmente é inativa, mas crítica durante o failover); para funções RAM, se um serviço de backend invoca a função apenas sob condições excepcionais (como operações de emergência ou funções de tratamento de alertas). Se alguma dessas situações se aplicar, arquive a descoberta em vez de excluir a identidade.

Se você confirmar que a identidade não é mais necessária, a melhor prática é desativar primeiro, observar e depois excluir:

1. Na aba Findings > Overview ou Findings > Findings, localize uma entrada do tipo inactive user/role e clique em no Finding ID específico.

2. Na página de detalhes de Findings, clique em na aba Advices na coluna Actions.

3. No painel Advices, encontre a recomendação para Remove Unused Principals.

4. Execute a operação apropriada com base no proprietário do recurso:

   • Conta atual: Clique em Go for Governance. Você será redirecionado para a página de detalhes do usuário ou função no console RAM. Limpe as configurações de logon, desative ou exclua uma AccessKey, ou exclua a identidade.

     

   • Entre contas: Clique em Copy Resource URL. Faça logon na conta de destino e acesse a URL para processar a solicitação.

     

6. (Opcional) Se o analisador não fornecer recomendações de correção, consulte Por que não há recomendação de correção para minha descoberta?

Corrigir over-privileged users/roles: Remover políticas não utilizadas

Para um over-privileged user/role, a recomendação de correção é remover políticas de permissão não utilizadas. O procedimento é o mesmo descrito em Corrigir super users/roles: Remover políticas de permissão não utilizadas.

Arquivar descobertas

Se uma descoberta não exigir ação, arquive-a. Após o arquivamento, o Status da descoberta na lista de Findings mudará de Active para Archived.

• Arquivar uma única descoberta: Na coluna Actions da lista de Findings ou no painel Advices, clique em Archive.

• Para ignorar automaticamente tipos específicos de descoberta, clique em Save as Archive Rule. Defina as condições da regra para garantir que todas as futuras descobertas correspondentes sejam arquivadas automaticamente. Consulte Arquivar descobertas automaticamente.

• Visualizar e desarquivar descobertas: Por padrão, apenas descobertas Ativas são exibidas. Para visualizar ou desarquivar descobertas Arquivadas, defina o filtro Status como Archived na página de Findings. Para uma entrada que precise ser reprocessada, clique em Unarchive. O status da entrada voltará para Active.

  

Melhores práticas de governança de acesso externo

O analisador de acesso externo examina Bucket Policies do OSS, ACLs e políticas de confiança de funções RAM para identificar configurações de recursos que permitem acesso de identidades fora da sua zona de confiança. O objetivo central é o gerenciamento de limites de acesso — garantindo que apenas identidades externas intencionais possam acessar seus recursos.

Nota

Ao contrário do analisador de acesso com privilégios excessivos, o analisador de acesso externo realiza uma análise estática das configurações de política de recursos, em vez de estatísticas dinâmicas de comportamento de acesso. Portanto, "acessível externamente" significa apenas que a configuração da política permite acesso externo — não indica que o recurso foi realmente acessado ou que ocorreu um vazamento de dados.

Fluxo de trabalho de investigação

Antes de corrigir descobertas de acesso externo, siga estas etapas de investigação:

1. Identifique o principal externo: Na página de detalhes da descoberta, verifique o principal externo específico. Para Buckets OSS, verifique se inclui usuários anônimos (AllUsers) ou contas Alibaba Cloud específicas. Para funções RAM, revise as entidades confiáveis na política de confiança.

2. Determine se o acesso é necessário para o negócio: Verifique se o acesso externo faz parte de uma colaboração normal de negócios (como acesso de conta de parceiro, compartilhamento de recursos entre departamentos dentro de um grupo ou implantação entre contas em uma arquitetura multicloud).

3. Verifique se o escopo da permissão é apropriado: Mesmo que o acesso externo seja esperado, verifique se as permissões concedidas seguem o princípio do menor privilégio. Por exemplo, confirme se um parceiro não recebeu permissões de operação excessivamente amplas.

4. Coordene entre contas: Se o acesso externo envolver outras contas Alibaba Cloud, confirme a dependência de negócios tanto com a parte que acessa quanto com o proprietário do recurso antes de restringir as políticas, para evitar interromper os negócios do parceiro.

Corrigir acesso externo a Buckets OSS

O acesso externo a Buckets OSS geralmente resulta de Bucket Policy, configurações de ACL do Bucket ou da ausência da configuração "Block Public Access".

Se o acesso externo for esperado (por exemplo, um parceiro precisa ler um Bucket específico):

1. Verifique se a autorização atual segue o princípio do menor privilégio. Por exemplo, confirme se apenas operações necessárias no nível de Objeto (como GetObject) foram concedidas, em vez de permissões completas no nível de Bucket.

2. Restrinja o escopo de autorização na Bucket Policy de curingas (*) para IDs de conta específicos ou ARNs de funções RAM.

3. Arquive a descoberta para evitar alertas repetidos.

Se o acesso externo for inesperado (por exemplo, o Bucket está configurado para acesso público):

1. Acesse o console OSS e ative o recurso "Block Public Access" no nível do Bucket. Isso impede globalmente o acesso público ao Bucket e é a medida de correção mais rápida.

2. Revise a Bucket Policy e remova qualquer autorização entre contas não intencional ou configurações de acesso anônimo (Principal definido como *).

3. Verifique a ACL do Bucket para garantir que não esteja definida como "Public Read" ou "Public Read/Write".

4. Após fazer alterações, aguarde o analisador de acesso externo reanalisar (geralmente 3-5 minutos após uma mudança de política) e confirme se o status da descoberta mudou para "Resolved".

Corrigir confiança entre contas de funções RAM

A política de confiança de uma função RAM determina quais identidades externas podem assumir a função. Uma política de confiança excessivamente permissiva cria riscos de escalonamento de privilégios entre contas.

Se a confiança entre contas for esperada (como autorização entre contas em uma arquitetura multicloud):

1. Revise os elementos Condition na política de confiança. Adicione restrições sempre que possível (como especificar intervalos de IP de origem ou exigir MFA) para reduzir o raio de explosão de um vazamento de credenciais.

2. Revise as políticas de permissões anexadas à função e garanta que elas sigam o princípio do menor privilégio.

3. Arquive a descoberta.

Se a confiança entre contas for inesperada:

1. Acesse o console RAM, abra a página de detalhes da função e edite a política de confiança.

2. Restrinja o escopo do Principal na política de confiança para incluir apenas os IDs de conta ou identificadores de serviço necessários.

3. Remova quaisquer autorizações com curingas desnecessárias ou autorizações para contas expiradas.

4. Após fazer alterações, monitore os sistemas de negócios dependentes. Preste atenção especial aos aplicativos que assumem essa função de outras contas — se a política de confiança restrita causar falhas no STS AssumeRole, restaure a política imediatamente.

Reversão e recuperação

Se você descobrir um problema de negócios ou um erro operacional após realizar a convergência de permissões, use os métodos a seguir para recuperar rapidamente:

Restaurar políticas de permissão desanexadas

Se você desanexou uma política usando o console do Access Analyzer, use os seguintes comandos OpenAPI para anexá-la novamente:

• Usuário RAM: aliyun ram AttachPolicyToUser --PolicyType <System|Custom> --PolicyName <PolicyName> --UserName <UserName>

• Função RAM: aliyun ram AttachPolicyToRole --PolicyType <System|Custom> --PolicyName <PolicyName> --RoleName <RoleName>

• Grupo de usuários: aliyun ram AttachPolicyToGroup --PolicyType <System|Custom> --PolicyName <PolicyName> --GroupName <GroupName>

Importante

• Para políticas de sistema, basta anexar novamente a política com o mesmo nome.

• Para políticas personalizadas, se a própria definição da política tiver sido excluída, os comandos acima não poderão restaurá-la. Sempre faça backup do conteúdo da política personalizada na página Policies do console RAM antes de removê-las.

Restaurar identidades desativadas

• Usuário RAM: Se você apenas desativou o logon no console e as AccessKeys, crie novamente a configuração de logon (CreateLoginProfile) e reative as AccessKeys (UpdateAccessKey --Status Active).

• Função RAM: Se você excluiu a função sem fazer backup da política de confiança e das informações da política anexada, será necessário criá-la novamente e configurá-la manualmente.

Restaurar uma política de confiança de função RAM modificada

Se a modificação de uma política de confiança causou problemas de negócios entre contas, restaure a política de confiança original imediatamente:

1. Acesse o console RAM e abra a aba Trust Policy na página de detalhes da função.

2. Se você fez backup da política de confiança original, cole-a de volta diretamente.

3. Se não fez backup, readicione manualmente as entidades confiáveis removidas por engano. Para IDs de conta incertos, consulte registros recentes de chamadas AssumeRole no ActionTrail para identificar quais identidades externas assumiram legitimamente a função recentemente.

Restaurar descobertas arquivadas

Se uma descoberta foi arquivada por engano, filtre a lista de descobertas pelo status Archived, localize a entrada e clique em Unarchive. A descoberta retornará ao status Active.

Limitações

• Tipo de analisador: Este recurso suporta apenas analisadores do tipo Over-privileged Access e não suporta analisadores do tipo External Access.

• Granularidade suportada: O analisador de acesso com privilégios excessivos analisa as permissões de todas as identidades RAM, exceto funções vinculadas a serviços em um diretório de recursos ou na conta atual, com base em informações de auditoria de permissões. Os tipos de política, serviços em nuvem e granularidade suportados são os mesmos da auditoria de permissões, conforme listado em Serviços compatíveis com o recurso de auditoria de permissões. Se uma política contiver permissões para serviços não suportados, o analisador não poderá fornecer recomendações de correção para remover permissões.

• Tipo de política (apenas para substituição de superadministrador): A recomendação de correção para substituir permissões de superadministradores suporta apenas a política de sistema AdministratorAccess. Políticas personalizadas de administrador não são suportadas.

• Conteúdo da política: Se uma política contiver uma instrução Deny ou NotAction, o analisador não poderá fornecer recomendações de correção para remover permissões.

• Escopo de autorização: Se o escopo de autorização de uma permissão de administrador for um Resource Group em vez de uma Account, a identidade não será identificada como superadministrador.

• Método de autorização: As permissões podem ser concedidas diretamente a um usuário ou função, ou herdadas através de um grupo de usuários. O analisador pode identificar ambos os métodos de autorização, mas não fornece recomendações automáticas de correção para permissões herdadas de um grupo de usuários. Você deve corrigir essas descobertas manualmente.

• Latência de dados: As recomendações de correção são geradas a partir de descobertas, que podem ter uma latência de dados de até 24 horas. Se a atualidade da recomendação for crítica, acione manualmente uma nova varredura clicando em Rescan na página de detalhes da descoberta e verifique a recomendação novamente.

  

FAQ

Posso aplicar recomendações de correção em lote?

A aplicação em lote de Apply Recommendation não é suportada. No entanto, crie regras de arquivamento para ignorar automaticamente tipos de descoberta esperados.

Qual é a atualização dos dados de descoberta?

Visualize o campo Updated At para cada descoberta na lista de Findings, ou verifique os horários Analyzed At e Updated At na página de detalhes da descoberta para confirmar a atualidade dos dados. Todos os horários são exibidos no seu fuso horário local.



Por que a recomendação de correção está ausente?

Na página de detalhes da descoberta, se nenhuma recomendação for exibida ao clicar em na aba Advices, corrija a descoberta manualmente, por exemplo, removendo a permissão ou arquivando a descoberta.

Motivos comuns:

1. Substituição de permissão de superadministrador: Se a identidade usou uma permissão durante o período de inatividade que existe na política AdministratorAccess, mas não na política PowerUserAccess, o analisador não pode recomendar um downgrade.

2. Remoção de permissões não utilizadas: Se a identidade usou alguns serviços em uma política durante o período de inatividade, o analisador não recomenda removê-la.

3. O sistema não gera recomendações de correção para permissões herdadas através de grupos de usuários ou para serviços fora do escopo suportado. Consulte Limitações.

Por que "Accessed services" está vazio? Isso significa que a identidade nunca foi usada?

Não necessariamente. Os possíveis motivos incluem:

• A identidade foi criada e usada antes da data de início do rastreamento (1º de fevereiro de 2024), mas não teve atividade de acesso recentemente.

• O acesso da identidade envolve operações de plano de dados ou chamadas delegadas de serviço interno que estão fora do escopo de análise atual.

• A entrega de logs do ActionTrail tem um atraso (até 24 horas no máximo).

Recomendamos verificar os logs do ActionTrail diretamente para investigar mais a fundo o comportamento histórico de acesso da identidade.

"Acesso público" nas descobertas de acesso externo significa que meus dados vazaram?

Não necessariamente. O analisador de acesso externo determina se existe acesso público com base na análise estática das configurações de política. Ele não consegue determinar se os dados no bucket foram realmente baixados ou acessados. Mesmo que a política permita acesso público, o risco real pode ser baixo se o bucket não contiver dados sensíveis ou se o caminho de acesso não for publicamente conhecido. No entanto, qualquer configuração de acesso público não intencional deve ser corrigida o mais rápido possível.

Por que uma descoberta não desaparece imediatamente após eu aplicar a recomendação de correção?

Depois que o Access Analyzer detecta uma alteração de permissão, ele precisa de tempo (geralmente 3 a 5 minutos) para reanalisar a identidade afetada. Durante esse período, o status da descoberta original é atualizado para Resolved. Se a identidade ainda atender às condições de risco sob a nova configuração de permissão, uma nova descoberta será gerada. Se a identidade não atender mais a nenhuma condição de risco após a alteração, nenhuma nova descoberta será gerada.

Existem riscos na correção em lote?

Sim. Embora o Access Analyzer suporte correção com um clique para algumas descobertas, operações em lote alteram o estado de permissão de várias identidades simultaneamente. Se uma dessas identidades for crítica para o seu negócio, o impacto pode ser amplo. Recomendamos seguir uma abordagem incremental: confirme cada descoberta individualmente e processe-as uma a uma, especialmente quando usar o Access Analyzer para governança pela primeira vez.

Como lidar com descobertas de contas membro em um cenário de diretório de recursos?

Um analisador criado no escopo do diretório de recursos analisa identidades RAM em todas as contas membro. Para descobertas entre contas:

• Recomendações de correção para políticas de permissão não utilizadas não podem ser aplicadas diretamente da conta atual. O console fornece links de recursos para você entrar na conta de destino e lidar com a descoberta manualmente.

• A exclusão ou desativação de identidades inativas também exige entrar na conta de destino.

• A governança de acesso externo para buckets OSS e funções RAM pode analisar recursos em contas membro, mas as modificações de política ainda precisam ser realizadas na conta de destino ou no console do serviço em nuvem correspondente.

• Recomendamos sincronizar regularmente o progresso da governança com os administradores das contas membro ou usar regras de arquivamento para arquivar automaticamente descobertas conhecidas e esperadas, reduzindo o custo de coordenação entre contas.

Como determino se as permissões atendem aos requisitos?

Na página de detalhes de uma descoberta, verifique estes atributos para determinar se as permissões estão alinhadas com as necessidades de negócios. Se as permissões excederem os requisitos, aplique a recomendação de correção ou ajuste a configuração manualmente.

• Accessed Services/Authorized Services:

  • Authorized Services é o número de serviços suportados pelo analisador nas políticas da identidade. Visualize a lista de Access Records para obter detalhes.

  • Accessed Services é o número de serviços que a identidade usou durante o período de inatividade. Estes têm prioridade na lista de Access Records com os horários de último acesso. Filtre pelos serviços acessados durante o período.

• Performed Actions/Authorized Actions:

  • Authorized Actions é o número total de permissões operacionais sob cada serviço autorizado.

  • Performed Actions é o número de ações que a identidade executou durante o período de inatividade, conforme detectado pelo analisador.

    Nota

    Nota: A granularidade da auditoria de permissões suportada varia por serviço em nuvem. Alguns serviços não suportam estatísticas de acesso no nível de ação. Para esses serviços, a coluna Performed Actions/Authorized Actions fica vazia. Consulte Serviços compatíveis com o recurso de auditoria de permissões.

• Last Accessed At: A hora em que cada serviço foi acessado pela última vez.



Para serviços que suportam auditoria no nível de ação, clique em View Actions na coluna Actions para visualizar as ações que a identidade acessou e seus horários de último acesso. Ações com uma tag Privileged são de alto risco e exigem atenção.