O que há de novo na API7 Enterprise: IAM para Controle de Acesso Granular

Introdução

Versões anteriores do API7 Enterprise ofereciam um mecanismo de gerenciamento de RBAC (Controle de Acesso Baseado em Funções) simples, amigável e abrangente. Esse mecanismo garantia a segurança do sistema enquanto concedia aos usuários uma configuração flexível de permissões de funções. À medida que os tipos de recursos e funcionalidades do API7 Enterprise aumentaram, o gerenciamento tradicional de RBAC gradualmente revelou suas limitações no controle granular de permissões. Além disso, mais empresas estão buscando estratégias de gerenciamento de permissões mais refinadas para atender às suas necessidades de negócios complexas e em constante mudança.

Para aprimorar ainda mais os recursos de gerenciamento de permissões do API7 Enterprise, realizamos uma atualização abrangente no sistema de permissões de funções existente, introduzindo um modelo de política de IAM (Gerenciamento de Identidade e Acesso) mais flexível e poderoso. Esse modelo oferece aos usuários um controle de permissões mais granular e maior flexibilidade, atendendo melhor às necessidades complexas e variáveis de gerenciamento de permissões das empresas modernas.

O que é o Modelo de Política IAM?

O modelo de política IAM (Gerenciamento de Identidade e Acesso) representa um método mais detalhado e eficiente de gerenciamento de permissões. Ele permite que os administradores definam políticas específicas, cada uma contendo um conjunto de regras (Declarações). Essas regras especificam detalhadamente quais usuários ou funções podem realizar quais ações em quais recursos. Comparado ao mecanismo tradicional de RBAC, esse modelo oferece maior flexibilidade e granularidade.

Vantagens do IAM sobre o RBAC:

• Controle Granular: O IAM pode controlar permissões no nível de recursos e até mesmo para atributos ou operações específicas dentro dos recursos, enquanto o RBAC frequentemente atribui permissões com base em funções, com granularidade relativamente grossa.

• Flexibilidade: O IAM permite que os administradores gerenciem políticas e permissões diretamente, sem a necessidade de criar e gerenciar inúmeras funções para atribuição indireta de permissões, tornando a configuração mais direta e flexível.

• Escalabilidade: À medida que as funcionalidades do sistema aumentam e os tipos de recursos se diversificam, o IAM pode se adaptar mais facilmente às mudanças, adicionando novas políticas para atender a novas necessidades de permissões, enquanto o RBAC pode exigir o ajuste ou a adição de inúmeras funções para acomodar mudanças.

Como Usar Políticas IAM no API7 Enterprise?

1. Criar Políticas de Permissão

Após fazer login no API7 Enterprise, clique no botão "Organização" no canto superior direito e selecione o item de menu "Políticas de Permissão" no menu suspenso.

Na seção Políticas de Permissão, você pode gerenciar todas as políticas. Por padrão, há uma super-admin-permission-policy para o administrador inicial.

Clique no botão "Adicionar Política" no canto superior direito para entrar no formulário de criação de política. Aqui, você precisa preencher as informações básicas das Políticas e configurar as permissões no Editor de Políticas, referidas como Declarações.

As Declarações são os componentes principais de uma política, consistindo em uma ou mais declarações. Cada declaração define uma regra de acesso específica.

• Efeito: Especifica o efeito da declaração, geralmente "Permitir" ou "Negar". Um recurso pode ser afetado por várias políticas, e o sistema IAM determina as permissões de acesso finais com base na ordem e lógica das declarações.

• Ação: Define uma série de ações permitidas ou negadas, como "gateway:DeleteGatewayGroup" ou "iam:GetUser". Essas ações devem ser usadas em conjunto com recursos (Recurso) para terem significado.

• Recurso: Especifica os recursos aos quais a declaração se aplica, como um grupo de gateway específico ou serviço. Curingas (por exemplo, <.*>) podem ser usados para corresponder a vários recursos.

• Condição (opcional): Define as condições sob as quais a declaração será efetiva. Por exemplo,

  "conditions": {
        "gateway_group_label": {
          "type": "MatchLabel",
          "options": {
            "key": "type",
            "operator": "exact_match",
            "value": "production"
          }
        }
      },
  

  Isso representa que as operações definidas na declaração são permitidas apenas quando o rótulo do grupo de gateway é definido como "production".

Por exemplo, para criar uma política que restrinja um usuário a editar apenas todos os serviços publicados dentro de um grupo de gateway específico, você pode escrevê-la da seguinte forma:

{
  "statement": [
    {
      "resources": [
        "arn:api7:gateway:gatewaygroup/{gateway group id}"
      ],
      "actions": [
        "<.*>Get<.*>" // Permitir executar todas as operações que começam com 'Get', que representam a permissão de 'leitura' para o grupo de gateway especificado
      ],
      "effect": "allow" // Permitir executar as operações definidas acima
      // Nota: Esta declaração de política permite realizar todas as operações 'Get' no grupo de gateway especificado, como recuperar informações do grupo de gateway, listar serviços dentro do grupo de gateway, etc.
    },
    {
      "resources": [
        "arn:api7:gateway:gatewaygroup/{gateway group id}/publishedservice/<.*>",
      ],
      "actions": [
        "<.*>" // Permitir executar todas as operações
      ],
      "effect": "allow" // Permitir executar as operações definidas acima
      // Esta declaração de política permite realizar todas as operações (criar, ler, atualizar, excluir, etc.) nos serviços publicados dentro do grupo de gateway especificado.
    }
  ]
}

Neste exemplo, definimos dois conjuntos de recursos (grupo de gateway e serviços publicados dentro do grupo de gateway) e definimos as ações permitidas para cada um. Alguns exemplos comuns de configuração de política podem ser encontrados no documento Exemplos de Políticas de Permissão. Para os valores disponíveis de recursos e ações e as APIs correspondentes, consulte o documento Ações e Recursos de Políticas de Permissão.

Após criar uma política, ela não pode ser diretamente atribuída a usuários; precisamos primeiro atribuir a política a funções específicas.

2. Criar Funções e Associar Políticas

Após fazer login no API7 Enterprise, clique no botão "Organização" no canto superior direito e selecione o item de menu "Funções" no menu suspenso.

Na seção Funções, você pode gerenciar todas as funções. Por padrão, há uma função de Super Admin como a função de administrador integrada.

Clique no botão "Adicionar Função Personalizada" no canto superior direito para entrar no formulário de criação de função. Aqui, você precisa preencher as informações básicas da função. Após a criação, entraremos na página de detalhes da função.

Na página de detalhes da função, clique no botão "Associar Política" para atribuir as políticas de permissão criadas anteriormente à função.

As políticas criadas podem ser reutilizadas em várias funções. Quando uma função está associada a várias políticas, essas políticas são combinadas por padrão. Ou seja, as permissões de uma função são a soma das permissões declaradas em todas as políticas associadas. Após criar uma função e associar políticas, podemos atribuir a função a usuários específicos.

3. Atribuir Funções a Usuários

Após fazer login no API7 Enterprise, clique no botão "Organização" no canto superior direito e selecione o item de menu "Usuários" no menu suspenso.

Na seção Usuários, você pode gerenciar todos os usuários. Por padrão, há uma função de admin como o administrador integrado.

Na coluna de ações à direita da lista de funções, clique em "Atualizar Funções" para abrir o painel de formulário para atualizar a função de um usuário específico.

Um usuário pode ter várias funções. Quando um usuário recebe várias funções, as permissões são combinadas. Ou seja, o usuário tem a soma das permissões de todas as funções.

Mapeamento Simplificado de Funções

Com a otimização e atualização do modelo de função de usuário, o processo de mapeamento de funções SSO foi simplificado. Agora, ao configurar o mapeamento de funções para opções de login, não é necessário definir regras de correspondência no nível de recurso para cada função individualmente. As permissões de recursos e operações são herdadas diretamente das funções integradas selecionadas, tornando a configuração de permissões mais intuitiva e simplificando a complexidade do gerenciamento de permissões.

Resumo

A introdução de políticas IAM permitiu uma configuração e gerenciamento de permissões mais flexíveis. Esse ajuste não apenas aprimorou a segurança do sistema, mas também proporcionou aos usuários uma maior possibilidade de personalização.

No futuro, continuaremos a expandir os tipos de recursos suportados pelas políticas IAM, garantindo que todos os recursos do sistema possam ser incluídos no gerenciamento granular de permissões, e continuaremos a otimizar a interface de edição e gerenciamento de políticas, trazendo aos usuários uma experiência de gerenciamento de permissões mais abrangente e eficiente.