Resource Access Management:Create a custom policy

Cenário 1: Conceder permissões de gerenciamento de usuários do RAM (nível de conta)

As APIs de gerenciamento de usuários do RAM (como ram:CreateUser, ram:CreateAccessKey e ram:ListUsers) são operações no nível da conta. O elemento Resource deve ser definido como "*" e, ao conceder a permissão, defina o escopo de autorização como Entire Alibaba Cloud Account. Não é possível restringir essas operações a um grupo de recursos.

Exemplo de política: permite criar usuários do RAM e AccessKeys.

{
  "Version": "1",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ram:CreateUser",
        "ram:CreateAccessKey",
        "ram:ListUsers"
      ],
      "Resource": ["*"]
    }
  ]
}

Cenário 2: Permitir que usuários do RAM alterem apenas suas próprias senhas

Para permitir que um usuário do RAM altere apenas sua própria senha de logon, conceda a permissão ram:ChangePassword. Não conceda AliyunRAMFullAccess (permissões de acesso total ao RAM), pois permissões excessivas representam riscos de segurança.

Exemplo de política: permite alterar apenas a própria senha.

{
  "Version": "1",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ram:ChangePassword"
      ],
      "Resource": ["*"]
    }
  ]
}

Cenário 3: Conceder acesso somente leitura a um recurso específico (usando uma instância ECS como exemplo)

Para permitir que um usuário do RAM visualize apenas uma instância ECS específica, especifique o ARN da instância no elemento Resource. O formato do ARN é acs:ecs:{region}:{account-id}:instance/{instance-id}. Observe que instance deve ser seguido por uma barra /.

Exemplo de política: permite visualizar apenas a instância ECS especificada.

{
  "Version": "1",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ecs:DescribeInstances",
        "ecs:DescribeInstanceAttribute",
        "ecs:DescribeInstanceStatus"
      ],
      "Resource": [
        "acs:ecs:*:*:instance/i-bp1xxxxxxxxxxxxxxxxx"
      ]
    }
  ]
}

Cenário 4: Autorização granular para Simple Log Service (SLS)

Operações de consulta no Simple Log Service exigem ARNs nos níveis de projeto e Logstore. Se chamadas via SDK ainda retornarem erros de permissão negada, adicione as permissões log:GetProject e log:GetLogStore.

Exemplo de política: permite consultar dados de log de um Logstore específico.

{
  "Version": "1",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "log:GetLogStoreLogs",
        "log:CreateStoreView",
        "log:GetProject",
        "log:GetLogStore"
      ],
      "Resource": [
        "acs:log:*:*:project/exampleproject",
        "acs:log:*:*:project/exampleproject/logstore/examplelogstore"
      ]
    }
  ]
}

Cenário 5: Configurar ações específicas não suportadas no editor visual

Ações de alguns products não podem ser selecionadas no modo Visual Editor e devem ser configuradas manualmente no modo JSON Editor. Ações comuns desse tipo incluem:

Cenário 6: Permissões mínimas para implantação de ECS

A criação de uma instância ECS envolve uma combinação de ações em vários services. A política de menor privilégio deve incluir tanto permissões de operação de instância quanto permissões de consulta para redes e grupos de segurança.

Exemplo de política: permissões mínimas necessárias para criar e implantar uma instância ECS.

{
  "Version": "1",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ecs:RunInstances",
        "ecs:DescribeInstances",
        "vpc:DescribeVpcs",
        "vpc:DescribeVSwitches",
        "ecs:DescribeSecurityGroups"
      ],
      "Resource": ["*"]
    }
  ]
}

Descrição das ações: ecs:RunInstances (cria e inicia uma instância), ecs:DescribeInstances (consulta informações da instância), vpc:DescribeVpcs e vpc:DescribeVSwitches (permitem selecionar a VPC e o vSwitch durante a criação da instância), ecs:DescribeSecurityGroups (seleciona o grupo de segurança).

Cenário 7: Permissões mínimas para configuração de rede VPC

A política de permissão mínima necessária para criar uma Virtual Private Cloud (VPC) e um vSwitch é apresentada abaixo.

Exemplo de política: permissões mínimas necessárias para criar uma VPC e um vSwitch.

{
  "Version": "1",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "vpc:CreateVpc",
        "vpc:CreateVSwitch",
        "vpc:CreateSecurityGroup",
        "vpc:DescribeVpcs",
        "vpc:DescribeVSwitches"
      ],
      "Resource": ["*"]
    }
  ]
}

Descrição das ações: vpc:CreateVpc (cria uma VPC), vpc:CreateVSwitch (cria um vSwitch), vpc:CreateSecurityGroup (cria um grupo de segurança), vpc:DescribeVpcs e vpc:DescribeVSwitches (consultam recursos de rede existentes).

Dividir uma política por função

Divida uma política grande que abrange múltiplas funções em políticas separadas e anexe cada uma a um usuário ou grupo de usuários do RAM diferente. Por exemplo, divida operações de leitura e gravação em duas políticas:

• Política somente leitura: {"Action": ["oss:Get*", "oss:List*"]}

• Política de gravação: {"Action": ["oss:Put*", "oss:Delete*"]}

Dividir uma política por recurso

Divida as políticas por recurso. Por exemplo, separe as permissões de diferentes buckets do OSS em políticas distintas, de modo que cada política conceda permissões apenas para um bucket específico. Isso evita que uma única política gerencie muitos recursos.

Notas de uso

• Ao configurar uma política no editor visual, evite selecionar todas as ações. Selecione primeiro o conjunto de ações com menor privilégio.

• Após dividir uma política, conceda cada política resultante aos usuários ou grupos de usuários do RAM separadamente, o que aumenta a complexidade do gerenciamento.

• Caracteres curinga podem causar autorização excessiva. Revise cuidadosamente o escopo de permissões antes de usá-los.

• Uma política entra em vigor imediatamente após ser concedida. Não é necessário aguardar.

Por que não encontro certas permissões no editor visual ou por que falha o salvamento de uma política?

Esse problema pode ocorrer pelos seguintes motivos:

• Algumas ações não estão atualizadas na lista visual: APIs recém-lançadas ou de baixo nível podem ainda não estar sincronizadas com a lista de ações no modo Visual Editor, ou um caractere curinga (como swas-open:*) pode apresentar conflitos de análise sob restrições específicas de recursos. Recomendamos alternar para o modo JSON Editor e inserir a ação manualmente.

• O nome da ação está incorreto: alguns nomes de ações de API têm diferenças entre singular e plural (por exemplo, a operação ECS para reinicializar um disco é ecs:ReInitDisks e não ecs:ReInitDisk). Verifique o nome exato da ação na documentação da API do service correspondente da Alibaba Cloud.

• A política de sistema não está sincronizada: se você não encontrar uma política de sistema específica (como AliyunAccountCenterFullAccess), visualize o conteúdo JSON oficial dessa política de sistema e crie uma política personalizada com o mesmo efeito no modo JSON Editor.

• Falha na validação do formato JSON: verifique se a sintaxe JSON está correta. Preste atenção especial aos seguintes erros comuns:

  • Resource não pode ser definido mais de uma vez. Para especificar vários recursos, liste-os em um único array, separados por vírgulas.

  • O formato do ARN deve seguir o seguinte padrão: acs:<service>:<region>:<account-id>:<resource-type>/<resource-id>.

Por que não consigo acessar o console ou realizar operações após conceder FullAccess ou uma política personalizada?

Esse problema pode ocorrer pelos seguintes motivos:

• O acesso ao console exige permissões básicas adicionais: além das permissões de negócio, alguns consoles de products (como services de valor agregado de registro ICP) também exigem permissões básicas de acesso ao console, como PowerUserAccess. Uma política FullAccess específica de negócio sozinha pode não ser suficiente para carregar a página do console. Consulte a documentação do product para confirmar a combinação completa de permissões necessárias para acessar o console.

• O escopo de autorização não corresponde ao Resource na política: o escopo de autorização selecionado ao conceder a permissão (Entire Alibaba Cloud Account ou um grupo de recursos específico) deve ser consistente com a definição de Resource na política. Por exemplo, operações no nível de instância, como as do OceanBase, exigem que o escopo de autorização seja Entire Alibaba Cloud Account, com o ARN da instância específica definido na política.

• Conflito de políticas ou substituição por Deny: verifique se uma declaração Deny está substituindo um Allow, ou se existe um conflito entre suas políticas personalizadas e as políticas de sistema. A lógica de avaliação de políticas do RAM é: Deny explícito > Allow > Deny padrão. Para cenários complexos (como acesso à rede pública MQTT), se uma política personalizada não entrar em vigor, recomendamos usar primeiro a política de sistema oficialmente recomendada (como AliyunMQFullAccess) para verificar a conectividade e, em seguida, refinar as permissões passo a passo.