O panorama: Controle de acesso minucioso e segurança doAmazon ES Principais conceitos Habilitar o controle de acesso minucioso Acessar o Kibana como o usuário mestre Gerenciamento de permissões Configurações recomendadas Tutorial: Usuário mestre do IAM e Amazon Cognito Tutorial: Autenticação básica HTTP e banco de dados interno de usuários do Limitations Modificar o usuário mestre Usuários mestre adicionais Snapshots manuais Integrations Diferenças de API REST

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

Tópicos

O panorama: Controle de acesso minucioso e segurança doAmazon ES
Principais conceitos
Habilitar o controle de acesso minucioso
Acessar o Kibana como o usuário mestre
Gerenciamento de permissões
Configurações recomendadas
Tutorial: Usuário mestre do IAM e Amazon Cognito
Tutorial: Autenticação básica HTTP e banco de dados interno de usuários do
Limitations
Modificar o usuário mestre
Usuários mestre adicionais
Snapshots manuais
Integrations
Diferenças de API REST

O panorama: Controle de acesso minucioso e segurança doAmazon ES

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.

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

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.

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

Example

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 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, você pode mapear três funções para um único usuário: uma função que fornece acesso ao Kibana, uma que fornece acesso somente leitura ao index1 e uma que fornece acesso de gravação ao index2. Ou você pode incluir todas essas permissões em uma ú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ê quiser usar os mesmos usuários em vários clusters, se quiser usar o Amazon Cognito para acessar o Kibana ou se tiver clientes do Elasticsearch 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 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ê gerencia usuários e configurou seu domínio.

Se você quiser usar o IAM para gerenciamento de usuários, use o Autenticação do Amazon Cognito para o Kibana para acessar o Kibana. Caso contrário, o Kibana exibirá uma página de início de sessão não funcional. Consulte Limitations.

Com a autenticação do Amazon Cognito, uma das funções assumidas no grupo de identidades 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: Usuário mestre do 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. Você deve acessar o Kibana por HTTPS. O Amazon Cognito e a autenticação SAML para o Kibana substituem essa tela de login.

Para obter mais informações sobre essa configuração, consulte Tutorial: Autenticação básica HTTP e banco de dados interno de usuários do.
Se você optar por usar a autenticação SAML, poderá fazer login usando credenciais de um provedor de identidade externo. Para obter mais informações, consulte Autenticação SAML para o Kibana.

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.

Criação de funções do

É 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 no nível do cluster incluem a capacidade de fazer solicitações amplas, como _mget, _msearch e _bulk, monitorar a integridade, tirar 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 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 seção 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

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 o 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 do , também chamadas de identidades externas, 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.

Especifique usuários, usuários do IAM ARNs 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 as funções de back-end e a função do IAM ARNs na seção External identities (Identidades externas).

É 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

Navegue até o Kibana e faça login.
No canto superior direito, escolha o ícone de usuário.
Escolha Switch tenants (Alternar locatários).
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.

Descrição	Usuário mestre	Política de acesso ao domínio
Use credenciais do IAM para chamadas para o Elasticsearch APIs e use a autenticação SAML 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	`{ "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 ao Elasticsearch APIs 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	`{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "" }, "Action": "es:ESHttp", "Resource": "domain-arn/*" } ] }`
Use credenciais do IAM para chamadas para o Elasticsearch APIs 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	`{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "" }, "Action": "es:ESHttp", "Resource": "domain-arn/*" } ] }`
Use credenciais do IAM para chamadas para o Elasticsearch APIs 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	`{ "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: Usuário mestre do 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 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 diferentes usuários.

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

Crie um domínio com as seguintes configurações:
- Elasticsearch7.8
- 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
Navegue até o console do IAM e escolha Roles (Funções).
Escolha IAMMasterUserRole e depois escolha a guia Trust relationships (Relações de confiança).

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"
      }
    }
  }]
}

Escolha Update Trust Policy.
Adicione a mesma política de confiança a uma segunda função do IAM (IAMLimitedUserRole para o restante deste tutorial).
Navegue até o console do Amazon Cognito e escolha Manage User Pools (Gerenciar grupos de usuários).
Escolha seu grupo de usuários e depois escolha Users and groups (Usuários e grupos).
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).
Crie outro usuário chamado limited-user.
Escolha a guia Groups (Grupos) e escolha Create group (Criar grupo).
Nomeie o grupo como master-user-group, escolha IAMMasterUserRole na lista suspensa IAM role (Função do IAM) e escolha Create group (Criar grupo).
Crie outro grupo chamado limited-user-group que use IAMLimitedUserRole.
Escolha master-user-group, depois escolha Add users (Adicionar usuários) e então adicione master-user.
Escolha limited-user-group, depois escolha Add users (Adicionar usuários) e então adicione limited-user.
Escolha App client settings (Configurações do cliente do aplicativo) e anote o ID do cliente do seu domínio.
Escolha Federated Identities (Identidades federadas), depois escolha seu grupo de identidades e Edit identity pool (Editar grupo de identidades).
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).
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.
Escolha Save Changes (Salvar alterações).
Navegue até o Kibana.
Faça login com master-user.
Escolha Try our sample data (Experimentar nossos dados de exemplo).
Adicione os dados de voo de exemplo.
Escolha Security (Segurança), Roles (Funções), Create role (Criar função).
Nomeie a função new-role.
Em permissões de índice, especifique kibana_sample_data_fli* para o padrão de índice.
Para o grupo de ações, escolha read (leitura).
Em Document Level Security Query (Consulta de segurança no nível do documento), especifique a seguinte consulta:
```
{
  "match": {
    "FlightDelay": true
  }
}
```
Para segurança no nível de campo, escolha Exclude fields (Excluir campos) e especifique FlightNum.
Em Anonymize fields, especifique Dest.
Escolha Create (Criar).
Escolha Mapped users (Usuários mapeados), Manage mapping (Gerenciar mapeamento). Em seguida, adicione o ARN para IAMLimitedUserRole como uma identidade externa e escolha Map (Mapa).
Volte para a lista de funções e escolha kibana_user. Escolha Mapped users (Usuários mapeados), Manage mapping (Gerenciar mapeamento). Em seguida, adicione o ARN para IAMLimitedUserRole como uma identidade externa e escolha Map (Mapa).
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).
Escolha Dev Tools (Ferramentas de desenvolvimento) e execute a pesquisa padrão:
```
GET _search
{
  "query": {
    "match_all": {}
  }
}
```
Observe o erro de permissões. O limited-user não tem permissões para executar pesquisas no âmbito do cluster.
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.
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: Autenticação básica HTTP e banco de dados interno de usuários do

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

Crie um domínio com as seguintes configurações:
- Elasticsearch7.9
- 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
Navegue até o Kibana.
Faça login usando TheMasterUser.
Escolha Try our sample data (Experimentar nossos dados de exemplo).
Adicione os dados de voo de exemplo.
Escolha Security (Segurança), Internal users (Usuários internos), Create internal user (Criar usuário interno).
Nomeie o usuário new-user e especifique uma senha. Em seguida, selecione Criar.
Selecione Roles (Funções), Create role (Criar função).
Nomeie a função new-role.
Em permissões de índice, especifique kibana_sample_data_fli* para o padrão de índice.
Para o grupo de ações, escolha read (leitura).
Em Document Level Security Query (Consulta de segurança no nível do documento), especifique a seguinte consulta:
```
{
  "match": {
    "FlightDelay": true
  }
}
```
Para segurança no nível de campo, escolha Exclude fields (Excluir campos) e especifique FlightNum.
Em Anonymize fields, especifique Dest.
Escolha Create (Criar).
Escolha Mapped users (Usuários mapeados), Manage mapping (Gerenciar mapeamento). Em seguida, adicione new-user a Users (Usuários) e escolha Map (Mapa).
Volte para a lista de funções e escolha kibana_user. Escolha Mapped users (Usuários mapeados), Manage mapping (Gerenciar mapeamento). Em seguida, adicione new-user a Users (Usuários) e escolha Map (Mapa).
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).
Escolha Dev Tools (Ferramentas de desenvolvimento) e execute a pesquisa padrão:
```
GET _search
{
  "query": {
    "match_all": {}
  }
}
```
Observe o erro de permissões. O new-user não tem permissões para executar pesquisas no âmbito do cluster.
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.
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 ou SAML, 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)

Acesse https://aws.amazon.com e escolha Sign In to the Console.
Em Analytics, escolha Elasticsearch Service.
Escolha o seu domínio.
Escolha Actions (Ações), Modify authentication (Modificar autenticação).
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.
Selecione 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: o Kibana ou a API REST.

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, fluxos de entrega do Kinesis Data Firehose geralmente usam uma função do IAM chamada firehose_delivery_role. No Kibana, crie uma função para controle de acesso minucioso e mapeie a função do IAM para ela. 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'

Atenção O Javascript está desativado ou não está disponível no seu navegador.

Para usar a documentação da AWS, o Javascript deve estar ativado. Consulte as páginas de Ajuda do navegador para obter instruções.

Convenções do documento

Identity and Access Management

Logs de auditoria