As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
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.
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 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 predefinidaskibana_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 |
|
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 |
|
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 |
|
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 |
|
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.
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
, escolhaIAMMasterUserRole
na lista suspensa IAM role (Função do IAM) e escolha Create group (Criar grupo). -
Crie outro grupo chamado
limited-user-group
que useIAMLimitedUserRole
. -
Escolha
master-user-group
, depois escolha Add users (Adicionar usuários) e então adicionemaster-user
. -
Escolha
limited-user-group
, depois escolha Add users (Adicionar usuários) e então adicionelimited-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
detrue
, um campo anônimoDest
e nenhum campoFlightNum
. -
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
detrue
, um campo anônimoDest
e nenhum campoFlightNum
. -
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
esecurity_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çõesPUT
. 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çãoall_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
Se usar o banco de dados de usuário interno, você poderá usar curl
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'