Controle de acesso refinado no Amazon OpenSearch Service - Amazon OpenSearch Service

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:

  • Controle de acesso com base em função

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

  • Locação múltipla do OpenSearch Dashboards

  • Autenticação básica HTTP para o OpenSearch e o OpenSearch Dashboards.

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

A segurança do Amazon OpenSearch 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 do OpenSearch Service. Se você escolher Public access (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 VPC access (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 obter mais informações, consulte . Como iniciar seus domínios do Amazon OpenSearch 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. política de acesso aceita ou rejeita solicitações na "borda" do domínio, antes que elas cheguem ao OpenSearch em si.

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 usuários ou funções do IAM, os clientes deverão 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.


        Fluxo de autorização de controle de acesso refinado com um domínio da VPC

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.


        Fluxo de autorização de controle de acesso refinado com um domínio de acesso público

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 permissões para ver 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

Asfunções são a maneira principal 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.

Depois de configurar uma função, mapeie-a 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.

Os usuários são pessoas ou aplicações que fazem solicitações ao cluster do OpenSearch. 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. Com o controle de acesso refinado habilitado no Amazon OpenSearch Service, você escolhe uma opção ou outra para seu usuário primário ao configurar seu domínio. O usuário primário tem permissões completas para o cluster e gerencia funções e mapeamentos de função.

  • Se você escolher o IAM para o usuário primário, todas as solicitações para o cluster deverão ser assinadas usando o AWS Signature versão 4. Para obter o código de exemplo, consulte Assinatura de solicitações HTTP no Amazon OpenSearch Service.

    Recomendamos usar o IAM se desejar usar os mesmos usuários em vários clusters, se desejar usar o Amazon Cognito para acessar o Dashboards ou se você tiver clientes do OpenSearch que oferecem suporte à assinatura do Signature versão 4.

  • Se você escolher o banco de dados interno de usuários, poderá usar a autenticação básica HTTP (bem como as credenciais do IAM) para fazer solicitações ao cluster. A maioria dos clientes é compatível com a autenticação básica, incluindo curl, que também é compatível com o AWS Signature versão 4 com a opção --aws-sigv4. O banco de dados interno de usuários é armazenado em um índice do OpenSearch, portanto, você não poderá 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 de usuários é a maneira mais simples de começar a usar o OpenSearch Service.

Habilitar o controle de acesso refinado

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 do Amazon OpenSearch 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ó. 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.

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

  1. Selecione o seu domínio e escolha Actions (Ações) e, depois, Edit security configuration (Editar configurações de segurança).

  2. Selecione Enable fine-grained access control (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 Set IAM ARN as master user (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 interno de usuários, escolha Create master user (Criar usuário primário) e especifique um nome de usuário e uma senha.

  4. (Opcional) Selecione Enable migration period for open/IP-based access policy (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 usuários do IAM com controle de acesso refinado, deverá atualizar os seus clientes para iniciar a assinatura de solicitações com a versão 4 do AWS Signature. 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 acessam o endpoint do OpenSearch Dashboards para o domínio irão diretamente para a página Discover (Descobertas) 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

    O OpenSearch Service desabilitará o período de migração automaticamente 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. Selecione Save changes.

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 do IAM para uma nova função chamada 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:

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 do IAM que cumprem a política do IAM podem acessar o domínio.

Não é necessário habilitar o período de migração.

O OpenSearch Service mapeia automaticamente todos os usuários do IAM que cumprem a política do IAM para a default_role. Assim, eles podem continuar a acessar o domínio.

  1. Crie mapeamentos de função personalizados no domínio.

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

  1. Crie mapeamentos de função personalizados no domínio.

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

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

  1. Crie mapeamentos de função no domínio.

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

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

Acesso ao OpenSearch Dashboards como usuário primário

O controle de acesso refinado tem um plugin 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.


        Página inicial de segurança no Dashboards

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.

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 Cluster Permissions (Permissões do cluster) ao criar uma funçã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 Index Permissions (Permissões do índice) ao criar uma funçã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.

dica

Se você aplicar o mascaramento padrão a um campo, o OpenSearch Service usará um hash seguro e aleatório que poderá 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ê 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. Em vez disso, crie usuários do IAM e funções 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 backend oferecem outra maneira de mapear funções para usuários. Em vez de mapear a mesma função para dezenas de usuários diferentes, é possível mapear a função para uma única função de backend. Depois, certifique-se de que todos os usuários tenham essa função de backend. As funções de backend podem ser funções do IAM ou strings arbitrárias.

  • Especifique usuários, ARNs de usuário do IAM e strings de usuário do Amazon Cognito na seção Users (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 Backend roles (Funções de backend).


                    Tela de mapeamento de funções

É 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 do Dashboards permite que você compartilhe seu trabalho de forma segura com outros usuários do Dashboards (ou mantenha-o privado). É 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. Para saber mais, consulte Locação múltipla do OpenSearch Dashboards.

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

  1. Navegue até o OpenSearch Dashboards e faça login.

  2. Selecione o ícone de usuário no canto superior direito e escolha Switch tenants (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 Private (Privado).

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 credenciais do IAM para chamadas para as APIs do OpenSearch e use a Autenticação SAML para acessar o Dashboards. Gerencie funções de controle de acesso refinado usando o Dashboards ou a API REST.

Usuário ou função do IAM
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "*" }, "Action": "es:ESHttp*", "Resource": "domain-arn/*" } ] }

Use credenciais do IAM ou a autenticação básica para chamadas para as APIs do OpenSearch. Gerencie funções de controle de acesso refinado usando o Dashboards ou a API REST.

Essa configuração oferece muita flexibilidade, especialmente se você tiver clientes OpenSearch que oferecem suporte somente à 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 credenciais do IAM para chamadas para as APIs do OpenSearch e use o Amazon Cognito para acessar o Dashboards. Gerencie funções de controle de acesso refinado usando o Dashboards ou a API REST.

Usuário ou função do IAM
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "*" }, "Action": "es:ESHttp*", "Resource": "domain-arn/*" } ] }

Use credenciais do IAM para chamadas para as APIs do OpenSearch e bloqueie a maior parte do acesso ao Dashboards. Gerencie funções de controle de acesso refinado usando a API REST.

Usuário ou função 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" }

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.

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

  1. Vá para https://aws.amazon.com e escolha Sign In to the Console (Fazer login no console)

  2. Em Analytics (Análise), escolha Amazon OpenSearch Service.

  3. Escolha o seu domínio.

  4. Escolha Actions (Ações), Edit security configuration (Editar configuração de segurança).

  5. Escolha Set IAM ARN as master user (Definir ARN do IAM como usuário primário) ou Create new master user (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.

  6. Selecione Save changes.

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.

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

    
            Página Mapeamento de funções
  • 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 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 Kinesis Data 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 regra da AWS IoT ou função do AWS Lambda que indexa dados provavelmente precisará de permissões semelhantes ao Kinesis Data 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 plugin 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'