Controle de acesso minucioso no Amazon Elasticsearch Service

O controle de acesso minucioso oferece formas adicionais de controlar o acesso aos seus dados no Amazon Elasticsearch 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 minucioso 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 Kibana

• Autenticação básica HTTP para o Elasticsearch e o Kibana

A Imagem Maior: Controlo de Acesso de Grão Fino e Amazon ES Segurança

A segurança do Amazon Elasticsearch 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 Amazon ES. 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 Suporte a VPC para domínios do Amazon Elasticsearch Service.

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

Controle de acesso minucioso

A terceira e última camada de segurança é o controle de acesso minucioso. 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 minucioso avaliará as credenciais do usuário e autenticará o usuário ou negará a solicitação. Se o controle de acesso minucioso 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 minucioso, 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 minucioso, recomendamos usar uma política de acesso ao domínio que não exija solicitações assinadas.

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

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

Example

Considere uma GET pedido para movies/_search?q=thor. O utilizador tem permissões para pesquisar movies índice? 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 mestre, 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 minucioso. 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, pode mapear três funções para um único utilizador: uma função que fornece acesso a Kibana, uma que fornece acesso apenas de leitura a index1, e um que fornece acesso a index2. Ou pode incluir todas as permissões numa única função.

Os usuários são pessoas ou aplicativos que fazem solicitações ao cluster do Elasticsearch. Os usuários têm credenciais — 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 minucioso habilitado no Amazon Elasticsearch Service, você escolhe uma opção ou outra para seu usuário mestre ao configurar seu domínio. O usuário mestre 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 mestre, 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 Assinar solicitações de HTTP para o Amazon Elasticsearch Service.

  Recomendamos o IAM se você deseja usar os mesmos usuários em vários clusters, se quiser usar o Amazon Cognito para acessar o Kibana (com ou sem um provedor de identidade externo), ou se você tiver clientes do Elasticsearch que ofereçam 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 oferece suporte à autenticação básica, incluindo curl. O banco de dados interno de usuários é armazenado em um índice do Elasticsearch, 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 Kibana (em vez do Amazon Cognito) ou se você tiver clientes que ofereçam suporte somente à autenticação básica. O banco de dados interno de usuários é a maneira mais simples de começar a usar o Amazon ES.

Habilitar o controle de acesso minucioso

Habilite o controle de acesso minucioso usando o console, a AWS CLI ou a API de configuração. O console oferece a experiência mais simples. Para obter as etapas, consulte Criar e gerenciar domínios do Amazon Elasticsearch Service. Veja os requisitos para habilitar o controle de acesso minucioso:

• Elasticsearch 6.7 ou posterior

• Criptografia de dados em repouso e criptografia de nó a nó habilitadas

• Opção Require HTTPS for all traffic to the domain (Exigir HTTPS para todo o tráfego para o domínio) habilitada

Não é possível habilitar o controle de acesso minucioso em domínios existentes, somente em novos. Depois que habilitar o controle de acesso minucioso, não será possível desabilitá-lo.

Acessar o Kibana como o usuário mestre

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

• Se optar por usar o IAM para o gerenciamento de usuários, você deverá habilitar Autenticação do Amazon Cognito para o Kibana e fazer login usando credenciais do grupo de usuários para acessar o Kibana. Caso contrário, o Kibana exibirá uma página de início de sessão não funcional. Consulte Limitations.

  Uma das funções assumidas do grupo de identidades do Amazon Cognito deve corresponder à função do IAM especificada para o usuário mestre. Para obter mais informações sobre essa configuração, consulte (Opcional) Configuração de acesso granular e Tutorial Utilizador principal de IAM e Amazon Cognito.

  

• Se optar por usar o banco de dados interno de usuários, você poderá entrar no Kibana com seu nome de usuário mestre e senha. Acesse o Kibana por HTTPS. Para obter mais informações sobre essa configuração, consulte Tutorial Base de dados de utilizador interno e autenticação básica HTTP.

  

Gerenciamento de permissões

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

Criar funções

É possível criar novas funções para controle de acesso minucioso usando o Kibana ou a operação _opendistro/_security na API REST. Para obter mais informações, consulte a documentação do Open Distro for Elasticsearch.

O controle de acesso minucioso também inclui várias funções predefinidas. Clientes como Kibana e Logstash fazem uma grande variedade de solicitações ao Elasticsearch, o que pode dificultar a criação manual de funções com o conjunto mínimo de permissões. Por exemplo, a função kibana_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 para qualquer função de usuário ou de back-end que acesse o Kibana, juntamente com funções adicionais que permitam o acesso a outros índices.

Segurança no nível do cluster

As permissões ao nível do grupo incluem a capacidade de fazer pedidos abrangentes, tais como _mget, _msearch, e _bulk, monitorizar a saúde, tirar instantâneos e mais. Gerencie essas permissões usando a guia 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 a documentação do Open Distro for Elasticsearch.

Segurança no nível do í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 guia Index Permissions (Permissões do índice) ao criar uma função. Para obter uma lista de grupos de ações no nível do índice, consulte a documentação do Open Distro for Elasticsearch.

Segurança no nível do 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 Elasticsearch. 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 a documentação do Open Distro for Elasticsearch.

Segurança no nível do 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 a documentação do Open Distro for Elasticsearch.

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.

Criação de usuários do ()

Se habilitou o banco de dados interno de usuários, você poderá criar usuários usando o Kibana ou a operação _opendistro/_security na API REST. Para obter mais informações, consulte a documentação do Open Distro for Elasticsearch.

Se você escolheu o IAM para seu usuário mestre, ignore esta parte do Kibana. Em vez disso, crie usuários do IAM e funções do IAM. Para obter mais informações, consulte Guia do usuário do IAM.

Mapear funções para usuários

O mapeamento de função é o aspecto mais crítico do controle de acesso minucioso. O controle de acesso minucioso 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 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 back-end. Depois, certifique-se de que todos os usuários tenham essa função de back-end. As funções de back-end podem ser funções do IAM ou strings arbitrárias especificadas quando você cria usuários no banco de dados interno de usuários.

• 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 back-end e ARNs de função do IAM na seção Backend roles (Funções de backend).

É possível mapear funções para usuários usando o Kibana ou a operação _opendistro/_security na API REST. Para obter mais informações, consulte a documentação do Open Distro for Elasticsearch.

Criar 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 Kibana ou a operação _opendistro/_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 a documentação do Open Distro for Elasticsearch.

Locação múltipla do Kibana

Locatários são espaços para salvar padrões de índice, visualizações, painéis e outros objetos do Kibana. A locação múltipla do Kibana permite que você compartilhe seu trabalho de forma segura com outros usuários do Kibana (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 a documentação do Open Distro for Elasticsearch.

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

1. Navegue até o Kibana e faça login.

2. Escolha Tenants (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 Kibana, escolha Global. Para compartilhar seu trabalho com um subconjunto de usuários do Kibana, escolha um locatário compartilhado diferente. Caso contrário, escolha Private (Privado).

Configurações recomendadas

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

Description (Descrição)	Usuário mestre	Autenticação do Amazon Cognito para o Kibana	Política de acesso ao domínio
Use credenciais do IAM ou a autenticação básica para chamadas para as APIs do Elasticsearch e use a autenticação básica para acessar o Kibana. Gerencie funções de controle de acesso minucioso usando o Kibana ou a API REST.	Nome de usuário e senha	Desabilitado	{ "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 Elasticsearch e use o Amazon Cognito para acessar o Kibana. Gerencie funções de controle de acesso minucioso usando o Kibana ou a API REST.	Usuário ou função do IAM	Habilitado	{ "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 Elasticsearch e bloqueie a maioria do acesso ao Kibana. Gerencie funções de controle de acesso minucioso usando a API REST.	Usuário ou função do IAM	Desabilitado	{ "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/_plugin/kibana*" } ] }

Tutorial Utilizador principal de IAM e Amazon Cognito

Este tutorial aborda um caso de uso popular: um usuário mestre do IAM com autenticação do Amazon Cognito para o Kibana. Embora essas etapas usem o grupo de usuários do Amazon Cognito para a autenticação, esse mesmo processo básico funciona para qualquer provedor de autenticação do Cognito que permita atribuir diferentes funções do IAM a usuários diferentes (SAML, por exemplo).

nota

Este tutorial pressupõe que você tenha duas funções do IAM existentes, uma para o usuário mestre e outra para usuários mais limitados. Se você não tiver duas funções, crie-as.

Conceitos básicos do controle de acesso minucioso

1. Crie um domínio com as seguintes configurações:

   • Elasticsearch 7,7

   • Acesso público

   • Controle de acesso minucioso habilitado com uma função do IAM como usuário mestre (IAMMasterUserRole para o resto deste tutorial)

   • Autenticação do Amazon Cognito para o Kibana habilitada

   • A seguinte política de acesso:

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

   • HTTPS necessário para todo o tráfego para o domínio

   • Criptografia de nó a nó

   • Criptografia de dados em repouso

2. Navegue até o console do IAM e escolha Roles (Funções).

3. Escolha IAMMasterUserRole e depois escolha a guia Trust relationships (Relações de confiança).

4. Escolha Edit trust relationship (Editar relação de confiança) e certifique-se de que o grupo de identidades do Amazon Cognito possa assumir a função. Você deve ver a seguinte declaração:

   {
     "Version": "2012-10-17",
     "Statement": [{
       "Effect": "Allow",
       "Principal": {
         "Federated": "cognito-identity.amazonaws.com"
       },
       "Action": "sts:AssumeRoleWithWebIdentity",
       "Condition": {
         "StringEquals": {
           "cognito-identity.amazonaws.com:aud": "identity-pool-id"
         },
         "ForAnyValue:StringLike": {
           "cognito-identity.amazonaws.com:amr": "authenticated"
         }
       }
     }]
   }

5. Escolha Update Trust Policy.

6. Adicione a mesma política de confiança a uma segunda função do IAM (IAMLimitedUserRole para o restante deste tutorial).

7. Navegue até o console do Amazon Cognito e escolha Manage User Pools (Gerenciar grupos de usuários).

8. Escolha seu grupo de usuários e depois escolha Users and groups (Usuários e grupos).

9. Escolha Create user (Criar usuário), especifique um nome de usuário para master-user e uma senha e escolha Create user (Criar usuário).

10. Crie outro usuário chamado limited-user.

11. Escolha a guia Groups (Grupos) e escolha Create group (Criar grupo).

12. Nomeie o grupo como master-user-group, escolha IAMMasterUserRole na lista suspensa IAM role (Função do IAM) e escolha Create group (Criar grupo).

13. Crie outro grupo chamado limited-user-group que use IAMLimitedUserRole.

14. Escolha master-user-group, depois escolha Add users (Adicionar usuários) e então adicione master-user.

15. Escolha limited-user-group, depois escolha Add users (Adicionar usuários) e então adicione limited-user.

16. Escolha App client settings (Configurações do cliente do aplicativo) e anote o ID do cliente do seu domínio.

17. Escolha Federated Identities (Identidades federadas), depois escolha seu grupo de identidades e Edit identity pool (Editar grupo de identidades).

18. Expanda Authentication providers (Provedores de autenticação), localize o ID do grupo de usuários e o ID do cliente do aplicativo para seu domínio e altere Use default role (Usar função padrão) para Choose role from token (Escolher função a partir do token).

19. Em Role resolution (Resolução da função), escolha DENY (NEGAR). Com essa configuração, os usuários devem estar em um grupo para receber uma função do IAM após a autenticação.

20. Escolha Save Changes.

21. Navegue até o Kibana.

22. Faça login com master-user.

23. Escolha Try our sample data (Experimentar nossos dados de exemplo).

24. Adicione os dados de voo de exemplo.

25. Escolha Security (Segurança), Roles (Funções), Add a new role (Adicionar uma nova função).

26. Nomeie a função como new-role e escolha Index Permissions (Permissões de índice).

27. Escolha Add index permissions (Adicionar permissões de índice) e especifique kibana_sample_data_fli* para o padrão de índice.

28. Selecione Add Action (Adicionar ação), read (leitura).

29. Em Document Level Security Query (Consulta de segurança no nível do documento), especifique a seguinte consulta:

    {
      "match": {
        "FlightDelay": true
      }
    }

    Depois, escolha Test DLS query syntax (Testar sintaxe de consulta DLS).

30. Em Include or exclude fields (Incluir ou excluir campos), escolha Exclude fields (Excluir campos) e depois escolha Add Field (Adicionar campo). Especificar FlightNum.

31. Em Anonymize fields (Tornar campos anônimos), escolha Add Field (Adicionar campo). Especificar Dest.

32. Escolha Save Role Definition (Salvar definição da função).

33. Escolha Back (Voltar), Role Mappings (Mapeamentos de função), Add a new role mapping (Adicionar um novo mapeamento de função).

34. Em Role (Função), escolha new-role (nova função). Escolher Adicionar função Backend, e especificar o ARN para IAMLimitedUserRole. Depois escolha Enviar.

35. Escolha Add a new role mapping (Adicionar um novo mapeamento de função) novamente.

36. Em Role (Função), escolha kibana_user. Escolher Adicionar função Backend, e especificar o ARN para IAMLimitedUserRole. Depois escolha Enviar.

37. Em uma nova janela privada do navegador, navegue até o Kibana, faça login usando limited-user e escolha Explore on my own (Explorar por conta própria).

38. Escolha Dev Tools (Ferramentas de desenvolvimento) e execute a pesquisa padrão:

    GET _search
    {
      "query": {
        "match_all": {}
      }
    }

    Anote o erro de permissões. limited-user não tem permissões para executar pesquisas em todo o grupo.

39. Execute outra pesquisa:

    GET kibana_sample_data_flights/_search
    {
      "query": {
        "match_all": {}
      }
    }

    Observe que todos os documentos correspondentes têm um campo FlightDelay de true, um campo anônimo Dest e nenhum campo FlightNum.

40. Na janela original do navegador, conectado como master-user, escolha Dev Tools (Ferramentas de desenvolvimento) e execute as mesmas pesquisas. Observe a diferença nas permissões, número de ocorrências, documentos correspondentes e campos incluídos.

Tutorial Base de dados de utilizador interno e autenticação básica HTTP

Este tutorial aborda outro caso de uso popular: um usuário mestre no banco de dados interno de usuários e autenticação básica HTTP para o Kibana.

Conceitos básicos do controle de acesso minucioso

1. Crie um domínio com as seguintes configurações:

   • Elasticsearch 7,7

   • Acesso público

   • Controle de acesso minucioso com um usuário mestre no banco de dados interno de usuários (TheMasterUser para o restante deste tutorial)

   • Autenticação do Amazon Cognito para o Kibana desabilitada

   • A seguinte política de acesso:

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

   • HTTPS necessário para todo o tráfego para o domínio

   • Criptografia de nó a nó

   • Criptografia de dados em repouso

2. Navegue até o Kibana.

3. Faça login usando TheMasterUser.

4. Escolha Try our sample data (Experimentar nossos dados de exemplo).

5. Adicione os dados de voo de exemplo.

6. Escolha Security (Segurança), Internal User Database (Banco de dados interno de usuários), Add a new internal user (Adicionar um novo usuário interno).

7. Nome do utilizador new-user, especifique uma palavra-passe e dê ao utilizador a função de backend de new-backend-role. Depois escolha Enviar.

8. Escolha Back (Voltar), Roles (Funções), Add a new role (Adicionar uma nova função).

9. Nomeie a função como new-role e escolha Index Permissions (Permissões de índice).

10. Escolha Add index permissions (Adicionar permissões de índice) e especifique kibana_sample_data_fli* para o padrão de índice.

11. Escolha Add action group (Adicionar grupo de ação), read (leitura).

12. Em Document Level Security Query (Consulta de segurança no nível do documento), especifique a seguinte consulta:

    {
      "match": {
        "FlightDelay": true
      }
    }

    Depois, escolha Test DLS query syntax (Testar sintaxe de consulta DLS).

13. Em Include or exclude fields (Incluir ou excluir campos), escolha Exclude fields (Excluir campos) e depois escolha Add Field (Adicionar campo). Especificar FlightNum.

14. Em Anonymize fields (Tornar campos anônimos), escolha Add Field (Adicionar campo). Especificar Dest.

15. Escolha Save Role Definition (Salvar definição da função).

16. Escolha Back (Voltar), Role Mappings (Mapeamentos de função), Add a new role mapping (Adicionar um novo mapeamento de função).

17. Em Role (Função), escolha new-role (nova função). Escolher Adicionar função Backend, e depois especifique new-backend-role. Depois escolha Enviar.

18. Escolha Add a new role mapping (Adicionar um novo mapeamento de função) novamente.

19. Para Função, escolha kibana_user. Escolher Adicionar utilizador e especificar new-user. Depois escolha Enviar.

    Só new-user tem a função kibana_user, mas todos os usuários com a função de back-end new-backend-role têm a função new-role.

20. Em uma nova janela privada do navegador, navegue até o Kibana, faça login usando new-user e escolha Explore on my own (Explorar por conta própria).

21. Escolha Dev Tools (Ferramentas de desenvolvimento) e execute a pesquisa padrão:

    GET _search
    {
      "query": {
        "match_all": {}
      }
    }

    Anote o erro de permissões. new-user não tem permissões para executar pesquisas em todo o grupo.

22. Execute outra pesquisa:

    GET kibana_sample_data_flights/_search
    {
      "query": {
        "match_all": {}
      }
    }

    Observe que todos os documentos correspondentes têm um campo FlightDelay de true, um campo anônimo Dest e nenhum campo FlightNum.

23. Na janela original do navegador, conectado como TheMasterUser, escolha Dev Tools (Ferramentas de desenvolvimento) e execute as mesmas pesquisas. Observe a diferença nas permissões, número de ocorrências, documentos correspondentes e campos incluídos.

Limitations

O controle de acesso minucioso 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 back-end.

• Os usuários no banco de dados interno de usuários não podem alterar suas próprias senhas. Os usuários principais (ou usuários com permissões equivalentes) devem alterar as senhas para eles.

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

• Se você escolher o IAM para o usuário mestre, 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/_opendistro/_sql"
  }

Modificar o usuário mestre

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

Como modificar o usuário mestre (console)

1. Acesse https://aws.amazon.com e escolha Sign In to the Console (Faça login no console).

2. Em Analytics, escolha Elasticsearch Service.

3. Escolha o seu domínio.

4. Escolha Actions (Ações), Modify master user (Modificar usuário mestre).

5. Escolha Set IAM role as master user (Definir função do IAM como usuário mestre) ou Create new master user (Criar novo usuário mestre).

   • Se você usou anteriormente um usuário mestre do IAM, o controle de acesso minucioso 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 minucioso criará um novo usuário mestre. É possível usar o novo usuário mestre para excluir o antigo.

6. Selecione Submit (Enviar).

Usuários mestre adicionais

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

• No Kibana, escolha Security (Segurança), Role Mappings (Mapeamentos de função), e mapeie o novo usuário mestre para as funções all_access e security_manager.

  

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

  PUT _opendistro/_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 _opendistro/_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 é especialmente útil se você não conseguir acessar o Kibana e quiser mapear uma função do IAM do Amazon Cognito para a função all_access.

Snapshots manuais

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

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.

Integrations

Se usar outros serviços da AWS com o Amazon ES, você deverá fornecer as funções do IAM para esses serviços com as permissões apropriadas. Por exemplo, Kinesis Data Firehose os fluxos de entrega usam frequentemente uma função de IAM chamada firehose_delivery_role. Em Kibana, criar uma função para controlo de acesso fino, e mapear a função IAM. 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 minucioso difere ligeiramente dependendo da sua versão do 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 _opendistro/_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 Elasticsearch 7.x, as solicitações são semelhantes a:

PUT _opendistro/_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 Elasticsearch 7.x, eles são objetos com seu próprio URI:

GET _opendistro/_security/api/tenants

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

Para ver a documentação sobre a API REST do 7.x, consulte a documentação do Open Distro for Elasticsearch.

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/_opendistro/_security/api/user'