Controle de acesso refinado no Amazon OpenSearch Service

O controle de acesso refinado oferece formas adicionais de controlar o acesso aos seus dados no Amazon OpenSearch Service. Por exemplo, dependendo de quem faz a solicitação, você pode querer que uma pesquisa retorne resultados de somente um índice. Talvez você queira ocultar determinados campos em seus documentos ou excluir determinados documentos completamente.

O controle de acesso refinado oferece os seguintes recursos:

O panorama: controle de acesso refinado e segurança do OpenSearch Service

A segurança do Amazon OpenSearch Service tem três camadas principais:

O diagrama a seguir ilustra uma configuração comum: um domínio de acesso da VPC com controle de acesso refinado habilitado, uma política de acesso baseada no IAM e um usuário primário do IAM.

O diagrama ilustra a seguir outra configuração comum: um domínio de acesso público com controle de acesso refinado habilitado, uma política de acesso que não usa os principais do IAM e um usuário primário no banco de dados de usuários interno.

Exemplo

Considere uma solicitação de GET para movies/_search?q=thor. O usuário tem permissões para pesquisar o índice movies? Em caso afirmativo, o usuário tem as permissões para exibir todos os documentos dentro dele? A resposta deve omitir ou tornar algum campo anônimo? Para o usuário primário, a resposta pode ser semelhante a esta:

{
  "hits": {
    "total": 7,
    "max_score": 8.772789,
    "hits": [{
        "_index": "movies",
        "_type": "_doc",
        "_id": "tt0800369",
        "_score": 8.772789,
        "_source": {
          "directors": [
            "Kenneth Branagh",
            "Joss Whedon"
          ],
          "release_date": "2011-04-21T00:00:00Z",
          "genres": [
            "Action",
            "Adventure",
            "Fantasy"
          ],
          "plot": "The powerful but arrogant god Thor is cast out of Asgard to live amongst humans in Midgard (Earth), where he soon becomes one of their finest defenders.",
          "title": "Thor",
          "actors": [
            "Chris Hemsworth",
            "Anthony Hopkins",
            "Natalie Portman"
          ],
          "year": 2011
        }
      },
      ...
    ]
  }
}

Se um usuário com permissões mais limitadas emitir exatamente a mesmo solicitação, a resposta pode ser semelhante a esta:

{
  "hits": {
    "total": 2,
    "max_score": 8.772789,
    "hits": [{
        "_index": "movies",
        "_type": "_doc",
        "_id": "tt0800369",
        "_score": 8.772789,
        "_source": {
          "year": 2011,
          "release_date": "3812a72c6dd23eef3c750c2d99e205cbd260389461e19d610406847397ecb357",
          "plot": "The powerful but arrogant god Thor is cast out of Asgard to live amongst humans in Midgard (Earth), where he soon becomes one of their finest defenders.",
          "title": "Thor"
        }
      },
      ...
    ]
  }
}

A resposta tem menos ocorrências e menos campos para cada ocorrência. Além disso, o campo release_date torna-se anônimo. Se um usuário sem permissões fizer a mesma solicitação, o cluster retornará um erro:

{
  "error": {
    "root_cause": [{
      "type": "security_exception",
      "reason": "no permissions for [indices:data/read/search] and User [name=limited-user, roles=[], requestedTenant=null]"
    }],
    "type": "security_exception",
    "reason": "no permissions for [indices:data/read/search] and User [name=limited-user, roles=[], requestedTenant=null]"
  },
  "status": 403
}

Se um usuário fornecer credenciais inválidas, o cluster retornará uma exceção Unauthorized.

Principais conceitos

Ao começar a usar controle de acesso refinado, considere os seguintes conceitos:

Sobre o usuário primário

O usuário principal no OpenSearch Service é uma combinação de nome de usuário e senha, ou uma entidade principal do IAM, que tem permissões completas para o cluster subjacente do OpenSearch. Um usuário é considerado usuário primário se tiver todo o acesso ao cluster do OpenSearch junto com a capacidade de criar usuários internos, funções e mapeamentos de funções no OpenSearch Dashboards.

Um usuário primário criado no console do OpenSearch Service ou por meio da CLI é automaticamente mapeado para duas funções predefinidas:

Com essas duas funções, o usuário obtém acesso à guia Segurança no OpenSearch Dashboards, onde pode gerenciar usuários e permissões. Se você criar outro usuário interno e mapeá-lo apenas para a função all_access, o usuário não terá acesso à guia Segurança. Você pode criar usuários primários adicionais mapeando-os explicitamente para as funções all_access e security_manager. Para obter instruções, consulte Usuários primários adicionais.

Ao criar um usuário primário para seu domínio, você pode especificar uma entidade principal do IAM existente ou criar um usuário primário no banco de dados interno do usuário. Considere o seguinte ao decidir qual usar:

Habilitar o controle de acesso detalhado

Habilite o controle de acesso refinado usando o console, a AWS CLI ou a API de configuração. Para obter as etapas, consulte Criação e gerenciamento de domínios OpenSearch do Amazon Service.

O controle de acesso refinado exige o OpenSearch ou a versão 6.7 ou superior do Elasticsearch. Isso também exige HTTPS para todo o tráfego direcionado ao domínio, criptografia de dados em repouso e criptografia de nó a nó. Dependendo de como você configura os atributos avançados do controle de acesso detalhado, o processamento adicional de suas solicitações pode exigir atributos de computação e memória em nós de dados individuais. Depois que habilitar o controle de acesso refinado, não será possível desabilitá-lo.

Habilitação do controle de acesso refinado em domínios existentes

Você pode habilitar o controle de acesso refinado nos domínios existentes que executam o OpenSearch ou a versão 6.7 ou superior do Elasticsearch.

A alteração aciona uma implantação azul-verde durante a qual a integridade do cluster fica vermelha, mas todas as operações do cluster permanecem inalteradas.

Para habilitar o controle de acesso refinado em um domínio existente (CLI)

Configure AnonymousAuthEnabled como true para habilitar o período de migração com controle de acesso refinado:

aws opensearch update-domain-config --domain-name test-domain --region us-east-1 \
      --advanced-security-options '{ "Enabled": true, "InternalUserDatabaseEnabled":true, "MasterUserOptions": {"MasterUserName":"master-username","MasterUserPassword":"master-password"},"AnonymousAuthEnabled": true}'

Sobre o default_role

O controle de acesso refinado exige o mapeamento de funções. Se o seu domínio usar políticas de acesso baseadas em identidade, o OpenSearch Service mapeará automaticamente os seus usuários para um novo perfil chamado default_role para ajudar a migrar corretamente os usuários existentes. Esse mapeamento temporário garante que os seus usuários ainda possam enviar com êxito solicitações GET e PUT assinadas pelo IAM até que você crie seus próprios mapeamentos de função.

A função não adiciona vulnerabilidades ou falhas de segurança ao seu domínio do OpenSearch Service. Recomendamos excluir a função padrão assim que você configurar suas próprias funções e mapeá-las adequadamente.

Cenários de migração

A tabela a seguir descreve o comportamento de cada método de autenticação antes e depois de habilitar o controle de acesso refinado em um domínio existente, assim como as etapas que os administradores devem seguir para mapear corretamente seus usuários para funções:

Acesso ao OpenSearch Dashboards como usuário primário

O controle de acesso refinado tem um plug-in do OpenSearch Dashboards que simplifica as tarefas de gerenciamento. Você pode usar o Dashboard para gerenciar usuários, funções, mapeamentos, grupos de ação e locatários. No entanto, a página de login do Dashboards e o método de autenticação subjacente diferem, dependendo de como você gerencia usuários e configurou seu domínio.

Gerenciar permissões

Conforme observado em Principais conceitos, você gerencia permissões de controle de acesso refinado usando funções, usuários e mapeamentos. Esta seção descreve como criar e aplicar esses recursos. Recomendamos fazer login no Dashboards como o usuário primário para executar essas operações.

Criar funções

É possível criar novas funções para controle de acesso refinado usando o OpenSearch Dashboards ou a operação _plugins/_security na API REST. Para obter mais informações, consulte Criar funções.

O controle de acesso refinado também inclui várias funções predefinidas. Clientes como OpenSearch Dashboards e Logstash realizam uma grande variedade de solicitações ao OpenSearch, o que pode dificultar a criação manual de funções com o conjunto mínimo de permissões. Por exemplo, a função opensearch_dashboards_user inclui as permissões de que um usuário precisa para criar padrões de índice, visualizações, painéis e locatários. Recomendamos mapeá-la em qualquer função de usuário ou de backend que acesse o Dashboards, juntamente com funções adicionais que permitam o acesso a outros índices.

O Amazon OpenSearch Service não oferece as seguintes funções para o OpenSearch:

O Amazon OpenSearch Service oferece várias funções que não estão disponíveis com o OpenSearch:

Segurança em nível de cluster

As permissões em nível de cluster incluem a capacidade de realizar solicitações amplas, como _mget, _msearch e _bulk, monitorar a integridade, obter snapshots e muito mais. Gerencie essas permissões usando a seção Permissões do cluster ao criar uma função. Para obter a lista completa das permissões no nível do cluster, consulte Permissões de cluster.

Em vez de usar permissões individuais, muitas vezes você pode alcançar a postura de segurança desejada usando uma combinação dos grupos de ação padrão. Para obter uma lista de grupos de ação no nível do cluster, consulte Nível do cluster.

Segurança em nível de índice

As permissões no nível do índice incluem a capacidade de criar novos índices, pesquisar índices, ler e escrever documentos, excluir documentos, gerenciar aliases e muito mais. Gerencie essas permissões usando a seção Permissões do índice ao criar uma função. Para obter a lista completa das permissões no nível do índice, consulte Permissões de índice.

Em vez de usar permissões individuais, muitas vezes você pode alcançar a postura de segurança desejada usando uma combinação dos grupos de ação padrão. Para obter uma lista de grupos de ação no nível do índice, consulte Nível do índice.

Segurança em nível de documento

A segurança no nível do documento permite restringir quais documentos em um índice um usuário pode ver. Ao criar uma função, especifique um padrão de índice e uma consulta do OpenSearch. Qualquer usuário mapeado para essa função poderá ver somente os documentos que correspondam à consulta. A segurança no nível do documento afeta o número de ocorrências que você recebe ao pesquisar.

Para obter mais informações, consulte Segurança em nível de documento.

Segurança em nível de campo

A segurança no nível do campo permite controlar quais campos de documento um usuário pode ver. Ao criar uma função, adicione uma lista de campos a serem incluídos ou excluídos. Se você incluir campos, os usuários que você mapear para essa função poderão ver somente esses campos. Se você excluir campos, eles poderão ver todos os campos exceto os excluídos. A segurança no nível do campo afeta o número de campos incluídos em ocorrências ao pesquisar.

Para obter mais informações, consulte Segurança em nível de campo.

Mascaramento de campo

O mascaramento de campo é uma alternativa à segurança no nível do campo que permite que você torne os dados anônimos em um campo em vez de removê-los completamente. Ao criar uma função, adicione uma lista de campos a serem mascarados. O mascaramento de campo afeta a possibilidade de ver o conteúdo de um campo ao pesquisar.

Criar usuários

Se você habilitou o banco de dados interno de usuários, poderá criar usuários usando o OpenSearch Dashboards ou a operação _plugins/_security na API REST. Para obter mais informações, consulte Criar usuários.

Se você escolheu o IAM para seu usuário primário, ignore esta parte do Dashboards. Crie perfis do IAM. Para obter mais informações, consulte o Manual do usuário do IAM.

Mapear funções em usuários

O mapeamento de função é o aspecto mais crítico do controle de acesso refinado. O controle de acesso refinado tem algumas funções predefinidas para ajudar a começar, mas a menos que você mapeie funções para os usuários, cada solicitação ao cluster terminará em um erro de permissões.

As funções de back-end podem ajudar a simplificar o processo de mapeamento de funções. Em vez de mapear a mesma perfil para 100 usuários individuais, é possível mapear a perfil para uma única perfil de backend. Todos os 100 usuários compartilham. As funções de backend podem ser funções do IAM ou strings arbitrárias.

É possível mapear funções em usuários usando o OpenSearch Dashboards ou a operação _plugins/_security na API REST. Para obter mais informações sobre as funções de usuário, consulte Mapear usuários em funções.

Criação de grupos de ação

Grupos de ação são conjuntos de permissões que podem ser reutilizados em diferentes recursos. É possível criar novos grupos de ação usando o OpenSearch Dashboards ou a operação _plugins/_security na API REST, embora os grupos de ação padrão sejam suficientes para a maioria dos casos de uso. Para obter mais informações sobre os grupos de ação padrão, consulte Grupos de ação padrão.

Locação múltipla do OpenSearch Dashboards

Locatários são espaços para salvar padrões de índice, visualizações, painéis e outros objetos do Dashboards. A locação múltipla dos Painéis permite que você compartilhe seu trabalho de forma segura com outros usuários dos Painéis (ou mantenha-o privado) e configure as locações dinamicamente. É possível controlar quais funções têm acesso a um locatário e se essas funções têm acesso de leitura ou gravação. O inquilino global é o padrão. Para saber mais, consulte Locação múltipla do OpenSearch Dashboards.

Configurações recomendadas

Devido à forma como o controle de acesso refinadointerage com outros recursos de segurança, recomendamos várias configurações de controle de acesso refinado que funcionam bem na maioria dos casos de uso.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "*"
      },
      "Action": "es:ESHttp*",
      "Resource": "domain-arn/*"
    }
  ]
}

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "*"
      },
      "Action": "es:ESHttp*",
      "Resource": "domain-arn/*"
    }
  ]
}

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "*"
      },
      "Action": "es:ESHttp*",
      "Resource": "domain-arn/*"
    }
  ]
}

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "*"
      },
      "Action": "es:ESHttp*",
      "Resource": "domain-arn/*"
    },
    {
      "Effect": "Deny",
      "Principal": {
        "AWS": "*"
      },
      "Action": "es:ESHttp*",
      "Resource": "domain-arn/_dashboards*"
    }
  ]
}

Limitações

O controle de acesso refinado tem várias limitações importantes:

Modificação do usuário primário

Se você esquecer os detalhes do usuário primário, poderá reconfigurá-lo usando o console, a AWS CLI ou a API de configuração.

Usuários primários adicionais

Você designa um usuário primário ao criar um domínio, mas, se desejar, pode usar esse usuário primário para criar usuários primários adicionais. Há duas opções: OpenSearch Dashboards ou API REST.

Snapshots manuais

O controle de acesso refinado apresenta algumas complicações adicionais quando são tirados snapshots manuais. Para registrar um repositório de snapshots, mesmo que use a autenticação básica HTTP para todos os outros fins, você deve mapear a função manage_snapshots em uma função do IAM que tenha permissões iam:PassRole para assumir TheSnapshotRole, conforme definido nos Pré-requisitos.

Depois, use essa função do IAM para enviar uma solicitação assinada ao domínio, conforme descrito em Registro de um repositório de snapshots manuais.

Integrações

Se usar outros serviços da AWS com o OpenSearch Service, você deverá fornecer as funções do IAM para esses serviços com as permissões apropriadas. Por exemplo, os fluxos de entrega do Firehose geralmente usam um perfil do IAM chamada firehose_delivery_role. No Dashboards, crie uma função para o controle de acesso refinado e mapeie a função do IAM nela. Nesse caso, a nova função precisará das seguintes permissões:

{
  "cluster_permissions": [
    "cluster_composite_ops",
    "cluster_monitor"
  ],
  "index_permissions": [{
    "index_patterns": [
      "firehose-index*"
    ],
    "allowed_actions": [
      "create_index",
      "manage",
      "crud"
    ]
  }]
}

As permissões variam de acordo com as ações que cada serviço executa. Uma regra da AWS IoT ou função do AWS Lambda que indexa dados provavelmente precisará de permissões semelhantes ao Firehose, enquanto uma função do Lambda que só executa pesquisas poderá usar um conjunto mais limitado.

Diferenças de API REST

A API REST do controle de acesso refinado difere ligeiramente dependendo da sua versão do OpenSearch/Elasticsearch. Antes de fazer uma solicitação PUT, faça uma solicitação GET para verificar o corpo da solicitação esperada. Por exemplo, uma solicitação GET para _plugins/_security/api/user retornar todos os usuários, que poderá ser modificada e usada para fazer solicitações PUT válidas.

No Elasticsearch 6.x, as solicitações para criar usuários são semelhantes a:

PUT _opendistro/_security/api/user/new-user
{
  "password": "some-password",
  "roles": ["new-backend-role"]
}

No OpenSearch ou no Elasticsearch 7.x, as solicitações são semelhantes a esta (altere _plugins para _opendistro se estiver usando o Elasticsearch):

PUT _plugins/_security/api/user/new-user
{
  "password": "some-password",
  "backend_roles": ["new-backend-role"]
}

Além disso, os locatários são propriedades de funções no Elasticsearch 6.x:

GET _opendistro/_security/api/roles/all_access

{
  "all_access": {
    "cluster": ["UNLIMITED"],
    "tenants": {
      "admin_tenant": "RW"
    },
    "indices": {
      "*": {
        "*": ["UNLIMITED"]
      }
    },
    "readonly": "true"
  }
}

No OpenSearch e no Elasticsearch 7.x, eles são objetos com seu próprio URI (alterar _plugins para _opendistro se estiver usando o Elasticsearch):

GET _plugins/_security/api/tenants

{
  "global_tenant": {
    "reserved": true,
    "hidden": false,
    "description": "Global tenant",
    "static": false
  }
}

Para obter documentação sobre a API REST do OpenSearch, consulte a Referência da API do plug-in de segurança.

curl -XGET -u 'master-user:master-user-password' 'domain-endpoint/_search'
curl -XGET -u 'master-user:master-user-password' 'domain-endpoint/_plugins/_security/api/user'