Controle de acesso refinado no Amazon Service OpenSearch

O controle de acesso refinado oferece formas adicionais de controlar o acesso aos seus dados no Amazon Service. OpenSearch 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:

• Controle de acesso com base em função

• Segurança no nível de índice, documento e campo

• OpenSearch Multilocação de painéis

• Autenticação básica HTTP para OpenSearch OpenSearch painéis

Tópicos

• Visão geral: controle de acesso refinado e segurança de serviços OpenSearch
• Principais conceitos
• Sobre o usuário principal
• Habilitar o controle de acesso detalhado
• Acessando OpenSearch painéis como usuário principal
• Gerenciar permissões
• Configurações recomendadas
• Limitações
• Modificação do usuário primário
• Usuários primários adicionais
• Snapshots manuais
• Integrações
• Diferenças de API REST
• Tutorial: Configuração de um domínio com um usuário primário do IAM e autenticação do Amazon Cognito
• Tutorial: Configuração de um domínio com o banco de dados interno do usuário e a autenticação básica HTTP

Visão geral: controle de acesso refinado e segurança de serviços OpenSearch

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

Rede

A primeira camada de segurança é a rede, que determina se as solicitações chegam a um domínio OpenSearch de serviço. Se você escolher Acesso público ao criar um domínio, as solicitações de qualquer cliente conectado à Internet poderão chegar ao endpoint do domínio. Se você escolher o Acesso à VPC, os clientes devem se conectar à VPC (e os grupos de segurança associados devem permitir) para que uma solicitação chegue ao endpoint. Para ter mais informações, consulte Lançamento de seus domínios OpenSearch do Amazon Service em uma VPC.

Política de acesso ao domínio

A segunda camada de segurança é a política de acesso ao domínio. Depois que uma solicitação chega a um endpoint do domínio, a política de acesso baseada em recursos permite ou nega o acesso da solicitação a um determinado URI. A política de acesso aceita ou rejeita solicitações na "borda" do domínio, antes que elas cheguem ao OpenSearch.

Controle de acesso refinado

A terceira e última camada de segurança é o controle de acesso refinado. Depois que uma política de acesso baseada em recursos permitir que uma solicitação chegue a um endpoint do domínio, o controle de acesso refinado avaliará as credenciais do usuário e autenticará o usuário ou negará a solicitação. Se o controle de acesso refinado autenticar o usuário, ele obterá todas as funções mapeadas para esse usuário e usará o conjunto completo de permissões para determinar como lidar com a solicitação.

nota

Se uma política de acesso baseada em recursos contiver funções ou usuários do IAM, os clientes devem enviar solicitações assinadas usando o AWS Signature versão 4. Como tal, as políticas de acesso podem entrar em conflito com o controle de acesso refinado, especialmente se você usar o banco de dados interno de usuários e a autenticação básica HTTP. Não é possível assinar uma solicitação com um nome de usuário e senha e credenciais do IAM. Em geral, se você habilitar o controle de acesso refinado, recomendamos usar uma política de acesso ao domínio que não exija solicitações assinadas.

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 o controle de acesso refinado, considere os seguintes conceitos:

• Funções — A principal forma de usar o controle de acesso refinado. Nesse caso, as funções são distintas das funções do IAM. As funções contêm qualquer combinação de permissões: nível de cluster, específica de índice, nível de documento e nível de campo.

• Mapeamento — Depois de configurar uma função, você a mapeia para um ou mais usuários. Por exemplo, é possível mapear três funções para um único usuário: uma função que fornece acesso ao Dashboards, uma que fornece acesso somente leitura ao index1 e uma que fornece acesso de gravação ao index2. Ou, é possível incluir todas essas permissões em uma única função.

• Usuários — Pessoas ou aplicativos que fazem solicitações ao OpenSearch cluster. Os usuários têm credenciais, sejam chaves de acesso do IAM ou um nome de usuário e senha, que eles especificam quando fazem solicitações.

Sobre o usuário principal

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

Um usuário mestre criado no console de OpenSearch serviço ou por meio da CLI é mapeado automaticamente para duas funções predefinidas:

• all_access— fornece acesso total a todas as operações em todo o cluster, permissão para gravar em todos os índices do cluster e permissão para gravar em todos os locatários.

• security_manager— Fornece acesso ao plug-in de segurança e gerenciamento de usuários e permissões.

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

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

• IAM principal — Se você escolher um IAM principal para seu usuário principal, todas as solicitações para o cluster devem ser assinadas usando o AWS Signature Version 4.

  OpenSearch O serviço não leva em consideração nenhuma das permissões do diretor do IAM. O usuário ou a função do IAM serve apenas para autenticação. As políticas desse usuário ou função não têm relação com a autorização do usuário principal. A autorização é feita por meio de várias permissões no plug-in de OpenSearch segurança.

  Por exemplo, você pode atribuir zero permissões do IAM a um principal do IAM e, desde que a máquina ou pessoa possa se autenticar para esse usuário ou função, ela terá o poder do usuário mestre no OpenSearch Serviço.

  Recomendamos o IAM se você quiser usar os mesmos usuários em vários clusters, se quiser usar o Amazon Cognito para acessar painéis ou se tiver OpenSearch clientes que ofereçam suporte à assinatura do Signature versão 4.

• Banco de dados interno do usuário — Se você criar um mestre no banco de dados interno do usuário (com uma combinação de nome de usuário e senha), poderá usar a autenticação básica HTTP (bem como as credenciais do IAM) para fazer solicitações ao cluster. A maioria dos clientes oferece suporte à autenticação básica, incluindo curl, que também oferece suporte à AWS Signature versão 4 com a opção --aws-sigv4. O banco de dados interno do usuário é armazenado em um OpenSearch índice, então você não pode compartilhá-lo com outros clusters.

  Recomendamos o banco de dados interno de usuários se você não precisar reutilizar usuários em vários clusters, se quiser usar a autenticação básica HTTP para acessar o Dashboards (em vez do Amazon Cognito) ou se você tiver clientes que oferecem suporte somente à autenticação básica. O banco de dados interno do usuário é a maneira mais simples de começar a usar o OpenSearch Service.

Habilitar o controle de acesso detalhado

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

O controle de acesso refinado requer o Elasticsearch OpenSearch 6.7 ou posterior. Também requer HTTPS para todo o tráfego para o domínio, criptografia de dados em repouso e node-to-node criptografia. 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 um controle de acesso refinado em domínios existentes em execução no Elasticsearch 6.7 OpenSearch ou posterior.

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

1. Selecione o seu domínio e escolha Ações e, depois, Editar configurações de segurança.

2. Selecione Habilitar o controle de acesso refinado.

3. Escolha como criar o usuário primário:

   • Se você quiser usar o IAM para o gerenciamento de usuários, escolha Definir ARN do IAM como usuário primário e especifique o ARN para uma função do IAM.

   • Se quiser usar o banco de dados de usuário interno, escolha Criar usuário primário e especifique um nome de usuário e senha.

4. (Opcional) Selecione Habilitar o período de migração para política de acesso aberto/baseado em IP. Essa configuração viabiliza um período de transição de 30 dias durante o qual os usuários existentes podem continuar acessando o domínio sem interrupções e as políticas de acesso baseado em IP e aberto existentes continuarão funcionando com o seu domínio. Durante esse período de migração, recomendamos que os administradores criem as funções necessárias e as mapeiem para os usuários para o domínio. Se você usar políticas baseadas em identidade, em vez de uma política de acesso aberto ou baseado em IP, será possível desabilitar essa configuração.

   Você também precisa atualizar os seus clientes para trabalhar com controle de acesso refinado durante o período de migração. Por exemplo, se você mapear funções do IAM com controle de acesso refinado, você deve atualizar seus clientes para começar a assinar solicitações com o AWS Signature versão 4. Se você configurar a autenticação básica de HTTP com controle de acesso refinado, deverá atualizar os seus clientes para fornecer as credenciais de autenticação básicas apropriadas nas solicitações.

   Durante o período de migração, os usuários que acessarem o endpoint do OpenSearch Dashboards do domínio acessarão diretamente a página Discover em vez da página de login. Os administradores e usuários primários podem escolher Login para fazer login com credenciais de administrador e configurar mapeamentos de funções.

   Importante

   OpenSearch O serviço desativa automaticamente o período de migração após 30 dias. Recomendamos encerrá-lo assim que você criar as funções necessárias e mapeá-las para os usuários. Após o término do período de migração, não será possível habilitá-lo novamente.

5. Escolha Salvar alterações.

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 seu domínio usa políticas de acesso baseadas em identidade, o OpenSearch Service mapeia automaticamente seus usuários para uma nova função chamada default_role para ajudá-lo a migrar adequadamente 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 nenhuma vulnerabilidade ou falha de segurança ao seu domínio do OpenSearch Serviço. 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:

Método de autenticação	Antes de habilitar o controle de acesso refinado	Depois de habilitar o controle de acesso refinado	Tarefas do administrador
Políticas baseadas em identidade	Todos os usuários que cumprem a política do IAM podem acessar o domínio.	Não é necessário habilitar o período de migração. OpenSearch O serviço mapeia automaticamente todos os usuários que atendem à política do IAM para o default_role para que eles possam continuar acessando o domínio.	Crie mapeamentos de função personalizados no domínio. Exclua a default_role.
Políticas baseadas em IP	Todos os usuários dos endereços IP ou blocos CIDR permitidos podem acessar o domínio.	Durante o período de migração de 30 dias, todos os usuários dos endereços IP ou blocos CIDR permitidos poderão continuar acessando o domínio.	Crie mapeamentos de função personalizados no domínio. Atualize os seus clientes para fornecer credenciais de autenticação básicas ou credenciais do IAM, dependendo da sua configuração de mapeamento de função. Encerre o período de migração. Os usuários dos endereços IP ou blocos CIDR permitidos enviando solicitações sem autenticação básica ou credenciais do IAM perderão o acesso ao domínio.
Políticas de acesso aberto	Todos os usuários na Internet podem acessar o domínio.	Durante o período de migração de 30 dias, todos os usuários na Internet podem continuar acessando o domínio.	Crie mapeamentos de função no domínio. Atualize os seus clientes para fornecer credenciais de autenticação básicas ou credenciais do IAM, dependendo da sua configuração de mapeamento de função. Encerre o período de migração. Os usuários que enviarem solicitações sem autenticação básica ou credenciais do IAM perderão o acesso ao domínio.

Acessando OpenSearch painéis como usuário principal

O controle de acesso refinado tem um plug-in de OpenSearch painéis 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 OpenSearch Dashboards e o método de autenticação subjacente diferem, dependendo de como você gerencia os usuários e configura seu domínio.

• Se desejar usar o IAM para o gerenciamento de usuários, use Configuração da autenticação do Amazon Cognito para OpenSearch Dashboards para acessar o Dashboards. Caso contrário, o Dashboards exibirá uma página de login não funcional. Consulte Limitações.

  Com a autenticação do Amazon Cognito, uma das funções assumidas do grupo de identidades deve corresponder à função do IAM especificada para o usuário primário. Para obter mais informações sobre essa configuração, consulte (Opcional) Configuração de acesso granular e Tutorial: Configuração de um domínio com um usuário primário do IAM e autenticação do Amazon Cognito.

  

• Se você escolher usar o banco de dados de usuário interno, você pode fazer login no Painéis com seu nome de usuário principal e senha. Você deverá acessar o Dashboards via HTTPS. O Amazon Cognito e a autenticação SAML para Dashboards substituem essa tela de login.

  Para obter mais informações sobre essa configuração, consulte Tutorial: Configuração de um domínio com o banco de dados interno do usuário e a autenticação básica HTTP.

  

• Se você optar por usar a autenticação SAML, poderá entrar usando credenciais de um provedor de identidade externo. Para ter mais informações, consulte Autenticação SAML para painéis OpenSearch .

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.

nota

As permissões que você escolhe conceder aos usuários variam amplamente com base no caso de uso. Não podemos cobrir todos os cenários nesta documentação. Ao determinar quais permissões conceder aos seus usuários, faça referência às permissões de OpenSearch cluster e índice mencionadas nas seções a seguir e sempre siga o princípio do privilégio mínimo.

Criar funções

Você pode criar novas funções para um controle de acesso refinado usando OpenSearch painéis ou a _plugins/_security operação 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 fazem uma grande variedade de solicitações 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 OpenSearch funções:

• observability_full_access

• observability_read_access

• reports_read_access

• reports_full_access

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

• ultrawarm_manager

• ml_full_access

• cold_manager

• notifications_full_access

• notifications_read_access

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 OpenSearch consulta. 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.

dica

Se você aplicar o mascaramento padrão a um campo, o OpenSearch Service usará um hash seguro e aleatório que pode causar resultados de agregação imprecisos. Para executar agregações em campos mascarados, use o mascaramento baseado em padrões.

Criar usuários

Se você ativou o banco de dados interno do usuário, poderá criar usuários usando OpenSearch painéis ou a _plugins/_security operação 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.

• Especifique usuários, ARNs de usuário e strings de usuário do Amazon Cognito na seção Usuários. As strings de usuário do Cognito assumem a forma de Cognito/user-pool-id/username.

• Especifique funções de backend e ARNs de função do IAM na seção Funções de backend.

Você pode mapear funções para usuários usando OpenSearch painéis ou a _plugins/_security operação 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. Você pode criar novos grupos de ação usando OpenSearch painéis ou a _plugins/_security operação 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.

OpenSearch Multilocação de painéis

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 Multilocação de OpenSearch painéis.

Como visualizar o locatário atual ou alterar locatários

1. Navegue até OpenSearch Painéis e faça login.

2. Selecione o ícone de usuário no canto superior direito e escolha Alternar locatários.

3. Verifique seu locatário antes de criar visualizações ou painéis. Se você deseja compartilhar seu trabalho com todos os outros usuários do Dashboards, escolha Global. Para compartilhar seu trabalho com um subconjunto de usuários do Dashboards, escolha um locatário compartilhado diferente. Caso contrário, escolha Privado.

nota

OpenSearch Os painéis mantêm um índice separado para cada inquilino e criam um modelo de índice chamado. tenant_template Não exclua nem modifique o tenant_template índice, pois isso pode causar mau funcionamento dos OpenSearch painéis se o mapeamento do índice do inquilino estiver configurado incorretamente.

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.

Descrição	Usuário primário	Política de acesso ao domínio
Use as credenciais do IAM para chamadas para as OpenSearch APIs e use a autenticação SAML para acessar os painéis. Gerencie funções de controle de acesso detalhado usando o Dashboards ou a API REST.	Usuário ou perfil do IAM	{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "*" }, "Action": "es:ESHttp*", "Resource": "domain-arn/*" } ] }
Use credenciais do IAM ou autenticação básica para chamadas para as OpenSearch APIs. Gerencie funções de controle de acesso detalhado usando o Dashboards ou a API REST. Essa configuração oferece muita flexibilidade, especialmente se você tiver OpenSearch clientes que oferecem suporte apenas à autenticação básica. Se você tiver um provedor de identidade existente, use a Autenticação do SAML para acessar o Dashboards. Caso contrário, gerencie usuários do Dashboards no banco de dados interno de usuários.	Nome de usuário e senha	{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "*" }, "Action": "es:ESHttp*", "Resource": "domain-arn/*" } ] }
Use as credenciais do IAM para chamadas para as OpenSearch APIs e use o Amazon Cognito para acessar painéis. Gerencie funções de controle de acesso detalhado usando o Dashboards ou a API REST.	Usuário ou perfil do IAM	{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "*" }, "Action": "es:ESHttp*", "Resource": "domain-arn/*" } ] }
Use as credenciais do IAM para chamadas para as OpenSearch APIs e bloqueie a maior parte do acesso aos painéis. Gerencie funções de controle de acesso refinado usando a API REST.	Usuário ou perfil do IAM	{ "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:

• O aspecto hosts dos mapeamentos de função, que mapeia funções para os nomes de host ou endereços IP, não funcionará se o domínio estiver dentro de uma VPC. Ainda assim, é possível mapear funções para usuários e funções de backend.

• Se você escolher o IAM para o usuário primário e não habilitar a autenticação do Amazon Cognito ou SAML, o Dashboards exibirá uma página de login não funcional.

• Se você escolher o IAM para o usuário primário, ainda poderá criar usuários no banco de dados interno de usuários. No entanto, como a autenticação básica HTTP não está habilitada nesta configuração, quaisquer pedidos assinados com essas credenciais de utilizador serão rejeitados.

• Se utilizar o SQL para consultar um índice ao qual você não tenha acesso, receberá um erro "sem permissões". Se o índice não existir, você receberá um erro "Índice não existe". Essa diferença nas mensagens de erro significa que você pode confirmar a existência de um índice se adivinhar seu nome.

  Para minimizar o problema, não inclua informações confidenciais em nomes de índice. Para negar todo o acesso ao SQL, adicione o seguinte elemento à sua política de acesso ao domínio:

  {
    "Effect": "Deny",
    "Principal": {
      "AWS": [
        "*"
      ]
    },
    "Action": [
      "es:*"
    ],
    "Resource": "arn:aws:es:us-east-1:123456789012:domain/my-domain/_plugins/_sql"
  }

• Se a versão do seu domínio for 2.3 ou superior e você tiver um controle de acesso detalhado ativado, max_clause_count a configuração como 1 causará problemas com seu domínio. Recomendamos definir essa conta para um número maior.

• Se você estiver habilitando o controle de acesso refinado em um domínio em que o controle de acesso refinado não está configurado, para fontes de dados criadas para consulta direta, você mesmo precisará configurar funções de controle de acesso refinadas. Para obter mais informações sobre como configurar funções de acesso refinadas, consulte Criação de integrações de fontes de dados do Amazon OpenSearch Service com o Amazon S3.

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 CLIou a API de configuração.

Como modificar o usuário primário (console)

1. Navegue até o console do Amazon OpenSearch Service em https://console.aws.amazon.com/aos/home/.

2. Escolha o seu domínio e escolha Ações, Editar configurações de segurança.

3. Escolha Definir ARN do IAM como usuário primário ou Criar novo usuário primário.

   • Se você usou anteriormente um usuário primário do IAM, o controle de acesso refinado mapeará novamente a função all_access para o novo ARN do IAM especificado.

   • Se você usou anteriormente o banco de dados interno de usuários, o controle de acesso refinado criará um novo usuário primário. É possível usar o novo usuário primário para excluir o antigo.

   • A mudança do banco de dados de usuário interno para um usuário primário do IAM não exclui os usuários do banco de dados interno de usuários. Em vez disso, ela apenas desabilita a autenticação básica HTTP. Exclua manualmente os usuários do banco de dados interno do usuário ou mantenha-os para o caso de precisar reativar a autenticação básica HTTP.

4. Escolha Salvar alterações.

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. Você tem duas opções: OpenSearch painéis ou a API REST.

• No Dashboards, escolha Segurança, Funções e mapeie o novo usuário primário nas funções all_access e security_manager.

  

• Para usar a API REST, envie as seguintes solicitações:

  PUT _plugins/_security/api/rolesmapping/all_access
  {
    "backend_roles": [
      "arn:aws:iam::123456789012:role/fourth-master-user"
    ],
    "hosts": [],
    "users": [
      "master-user",
      "second-master-user",
      "arn:aws:iam::123456789012:user/third-master-user"
    ]
  }

  PUT _plugins/_security/api/rolesmapping/security_manager
  {
    "backend_roles": [
      "arn:aws:iam::123456789012:role/fourth-master-user"
    ],
    "hosts": [],
    "users": [
      "master-user",
      "second-master-user",
      "arn:aws:iam::123456789012:user/third-master-user"
    ]
  }

  Essas solicitações substituem os mapeamentos de função atuais, portanto, execute as solicitações GET primeiro para que você possa incluir todas as funções atuais nas solicitações PUT. A API REST será especialmente útil se você não conseguir acessar o Dashboards e quiser mapear uma função do IAM do Amazon Cognito na função all_access.

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 você usa outros AWS serviços com o OpenSearch Service, deve fornecer as funções do IAM para esses serviços com as permissões apropriadas. Por exemplo, os streams de entrega do Firehose geralmente usam uma função 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 AWS IoT regra ou AWS Lambda função que indexa dados provavelmente precisa de permissões semelhantes às do Firehose, enquanto uma função Lambda que só realiza pesquisas pode usar um conjunto mais limitado.

Diferenças de API REST

A API REST de controle de acesso refinada difere um pouco dependendo da sua OpenSearch versão /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 Elasticsearch 7.x, as solicitações têm a seguinte aparência (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 Elasticsearch 7.x, eles são objetos com seu próprio URI (altere _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 a documentação sobre a API OpenSearch REST, consulte a referência da API do plug-in de segurança.

dica

Se usar o banco de dados de usuário interno, você poderá usar curl para fazer solicitações e testar seu domínio. Teste os seguintes comandos de exemplo:

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'