Resource Access Management:Govern permissions with Access Analyzer

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 do 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 ao RAM e faturamento).

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

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

3. No painel de Advices, localize 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?

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, encontre uma entrada cujo Finding Type seja super user/role e clique no Finding ID específico.

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

3. No painel de Advices, localize 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.

     Na página de detalhes do resultado da análise, acesse a aba Governance Suggestions e a área Optimize Authorization. Encontre a linha onde a política de permissão recomendada é None (Remove Policy), como AliyunRAMFullAccess, e execute a ação na coluna Action dessa linha.

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

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?

Riscos e reversão: Confirme que a política não é mais necessária. Se você a remover acidentalmente, reconceda a política de permissão removida à identidade no console do 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 que para 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 do RAM, se um service 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 condições se aplicar, arquive a descoberta em vez de excluir a identidade.

Se você confirmar que a identidade não é mais necessária, desative primeiro, observe e depois exclua:

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

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

3. No painel de Advices, localize 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 do 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.

     O botão Copy Resource URL está localizado abaixo da aba Governance Suggestions na página de detalhes do resultado da análise.

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 que para 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 Findings da descoberta mudará de Status para Active.

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

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

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

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 do RAM para identificar configurações de recursos que permitem acesso de identidades fora da sua zona de confiança. O objetivo principal é o gerenciamento de limites de acesso: garantir que apenas identidades externas intencionais possam acessar seus recursos.

Nota

Diferentemente 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 significa 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 do OSS, verifique se inclui usuários anônimos (AllUsers) ou contas específicas da Alibaba Cloud. Para funções do 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 de 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, se um parceiro recebeu permissões de operação excessivamente amplas.

4. Coordene entre contas: Se o acesso externo envolver outras contas da 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 do OSS

O acesso externo a Buckets do 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 que 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ção do 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 do 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 alteração de política) e confirme se o status da descoberta mudou para "Resolved".

Corrigir confiança entre contas de função do RAM

A política de confiança de uma função do 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 source ou exigir MFA) para reduzir o raio de impacto 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 do RAM, abra a página de detalhes da função e edite a política de confiança.

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

3. Remova quaisquer autorizações de curinga 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 surgir um problema de negócios após a convergência de permissões, use os métodos a seguir para recuperar.

Restaurar políticas de permissão desanexadas

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

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

• Função do 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 reanexar 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 do RAM antes de removê-las.

Restaurar identidades desativadas

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

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

Restaurar uma política de confiança de função do 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 do 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 você 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 retorna 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 do RAM, exceto funções vinculadas a service em um diretório de recursos ou na conta atual, com base nas informações de auditoria de permissões. Os tipos de política, serviços de cloud 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 de administrador personalizadas 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 Active em vez de uma Resource Group, 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 por meio 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 Account 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 Rescan não é suportada. No entanto, crie regras de arquivamento para ignorar automaticamente tipos de descoberta esperados.

Quão atuais são os dados das descobertas?

Visualize o campo Apply Recommendation para cada descoberta na lista de Updated At, ou verifique os horários Findings e Analyzed 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 na aba Updated At, 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 por meio de grupos de usuários ou para serviços fora do escopo suportado. 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 service 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 melhor o comportamento histórico de acesso da identidade.

"Public access" 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 pode 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, as 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 lido 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 do RAM em todas as contas membro. Para descobertas entre contas:

• As 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ê fazer logon na conta de destino e lidar com a descoberta manualmente.

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

• A governança de acesso externo para buckets do OSS e funções do 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 service de cloud 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 do negócio. Se as permissões excederem os requisitos, aplique a recomendação de correção ou ajuste a configuração manualmente.

• Accessed Services/Authorized Services: O número de serviços realmente acessados versus aqueles autorizados nas políticas da identidade.

  • Authorized Services é o número de serviços suportados pelo analisador nas políticas da identidade. Visualize a lista de Advices 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: O número de ações realmente executadas versus aquelas autorizadas sob cada service.

  • Authorized Actions é o número total de permissões operacionais sob cada service 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 service de cloud. 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 está vazia. Serviços compatíveis com o recurso de auditoria de permissões.

• Last Accessed At: O horário em que cada service foi acessado pela última vez.

Para serviços que suportam auditoria no nível de ação, clique em Access Records 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.