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 refinado no Amazon Service OpenSearch
O controle de acesso refinado oferece formas adicionais de controlar o acesso aos seus dados no Amazon Service. OpenSearch Por exemplo, dependendo de quem faz a solicitação, você pode querer que uma pesquisa retorne resultados de somente um índice. Talvez você queira ocultar determinados campos em seus documentos ou excluir determinados documentos completamente.
O controle de acesso refinado oferece os seguintes recursos:
+ Controle de acesso com base em função
+ Segurança no nível de índice, documento e campo
+ OpenSearch Multilocação de painéis
+ Autenticação básica HTTP para OpenSearch OpenSearch painéis
**Topics**
+ [Visão geral: controle de acesso refinado e segurança de serviços OpenSearch](#fgac-access-policies)
+ [Principais conceitos](#fgac-concepts)
+ [Sobre o usuário-mestre](#fgac-master-user)
+ [Habilitar o controle de acesso detalhado](#fgac-enabling)
+ [Acessando OpenSearch painéis como usuário principal](#fgac-dashboards)
+ [Gerenciar permissões](#fgac-access-control)
+ [Configurações recomendadas](#fgac-recommendations)
+ [Limitações](#fgac-limitations)
+ [Modificação do usuário primário](#fgac-forget)
+ [Usuários primários adicionais](#fgac-more-masters)
+ [Snapshots manuais](#fgac-snapshots)
+ [Integrações](#fgac-integrations)
+ [Diferenças de API REST](#fgac-rest-api)
+ [Tutorial: Configuração de um domínio com um usuário primário do IAM e autenticação do Amazon Cognito](fgac-iam.md)
+ [Tutorial: Configuração de um domínio com o banco de dados interno do usuário e a autenticação básica HTTP](fgac-http-auth.md)
## Visão geral: controle de acesso refinado e segurança de serviços OpenSearch
A segurança OpenSearch do Amazon Service tem três camadas principais:
**Rede**
A primeira camada de segurança é a rede, que determina se as solicitações chegam a um domínio OpenSearch de serviço. Se você escolher **Acesso público** ao criar um domínio, as solicitações de qualquer cliente conectado à Internet poderão chegar ao endpoint do domínio. Se você escolher o **Acesso à VPC**, os clientes devem se conectar à VPC (e os grupos de segurança associados devem permitir) para que uma solicitação chegue ao endpoint. Para saber mais, consulte [Lançamento de seus domínios OpenSearch do Amazon Service em uma VPC](vpc.md).
**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](ac.md#ac-types-resource) permite ou nega o acesso da solicitação a um determinado URI. A política de acesso aceita ou rejeita solicitações na "borda" do domínio, antes que elas cheguem ao OpenSearch.
**Controle de acesso refinado**
A terceira e última camada de segurança é o controle de acesso refinado. Depois que uma política de acesso baseada em recursos permitir que uma solicitação chegue a um endpoint do domínio, o controle de acesso refinado avaliará as credenciais do usuário e autenticará o usuário ou negará a solicitação. Se o controle de acesso refinado autenticar o usuário, ele obterá todas as funções mapeadas para esse usuário e usará o conjunto completo de permissões para determinar como lidar com a solicitação.
**nota**
Se uma política de acesso baseada em recursos contiver funções ou usuários do IAM, os clientes devem enviar solicitações assinadas usando o AWS Signature versão 4. Como tal, as políticas de acesso podem entrar em conflito com o controle de acesso refinado, especialmente se você usar o banco de dados interno de usuários e a autenticação básica HTTP. Não é possível assinar uma solicitação com um nome de usuário e senha *e* credenciais do IAM. Em geral, se você habilitar o controle de acesso refinado, recomendamos usar uma política de acesso ao domínio que não exija solicitações assinadas.
O diagrama a seguir ilustra uma configuração comum: um domínio de acesso da VPC com controle de acesso refinado habilitado, uma política de acesso baseada no IAM e um usuário primário do IAM.
![\[Fluxo de autorização de controle de acesso refinado com um domínio da VPC\]](http://docs.aws.amazon.com/pt_br/opensearch-service/latest/developerguide/images/fgac-vpc-iam.png)
O diagrama ilustra a seguir outra configuração comum: um domínio de acesso público com controle de acesso refinado habilitado, uma política de acesso que não usa os principais do IAM e um usuário primário no banco de dados de usuários interno.
![\[Fluxo de autorização de controle de acesso refinado com um domínio de acesso público\]](http://docs.aws.amazon.com/pt_br/opensearch-service/latest/developerguide/images/fgac-public-basic.png)
### Exemplo
Considere uma solicitação de `GET` para `movies/_search?q=thor`. O usuário tem permissões para pesquisar o índice `movies`? Em caso afirmativo, o usuário tem as permissões para exibir *todos* os documentos dentro dele? A resposta deve omitir ou tornar algum campo anônimo? Para o usuário primário, a resposta pode ser semelhante a esta:
```
{
"hits": {
"total": 7,
"max_score": 8.772789,
"hits": [{
"_index": "movies",
"_type": "_doc",
"_id": "tt0800369",
"_score": 8.772789,
"_source": {
"directors": [
"Kenneth Branagh",
"Joss Whedon"
],
"release_date": "2011-04-21T00:00:00Z",
"genres": [
"Action",
"Adventure",
"Fantasy"
],
"plot": "The powerful but arrogant god Thor is cast out of Asgard to live amongst humans in Midgard (Earth), where he soon becomes one of their finest defenders.",
"title": "Thor",
"actors": [
"Chris Hemsworth",
"Anthony Hopkins",
"Natalie Portman"
],
"year": 2011
}
},
...
]
}
}
```
Se um usuário com permissões mais limitadas emitir exatamente a mesmo solicitação, a resposta pode ser semelhante a esta:
```
{
"hits": {
"total": 2,
"max_score": 8.772789,
"hits": [{
"_index": "movies",
"_type": "_doc",
"_id": "tt0800369",
"_score": 8.772789,
"_source": {
"year": 2011,
"release_date": "3812a72c6dd23eef3c750c2d99e205cbd260389461e19d610406847397ecb357",
"plot": "The powerful but arrogant god Thor is cast out of Asgard to live amongst humans in Midgard (Earth), where he soon becomes one of their finest defenders.",
"title": "Thor"
}
},
...
]
}
}
```
A resposta tem menos ocorrências e menos campos para cada ocorrência. Além disso, o campo `release_date` torna-se anônimo. Se um usuário sem permissões fizer a mesma solicitação, o cluster retornará um erro:
```
{
"error": {
"root_cause": [{
"type": "security_exception",
"reason": "no permissions for [indices:data/read/search] and User [name=limited-user, roles=[], requestedTenant=null]"
}],
"type": "security_exception",
"reason": "no permissions for [indices:data/read/search] and User [name=limited-user, roles=[], requestedTenant=null]"
},
"status": 403
}
```
Se um usuário fornecer credenciais inválidas, o cluster retornará uma exceção `Unauthorized`.
## Principais conceitos
Ao começar a usar o controle de acesso refinado, considere os seguintes conceitos:
+ **Perfis**: a principal maneira de usar o controle de acesso refinado. Nesse caso, as funções são distintas das funções do IAM. As funções contêm qualquer combinação de permissões: nível de cluster, específica de índice, nível de documento e nível de campo.
+ **Mapeamento**: depois de configurar um perfil, você o *mapeia* para um ou mais usuários. Por exemplo, é possível mapear três funções para um único usuário: uma função que fornece acesso ao Dashboards, uma que fornece acesso somente leitura ao `index1` e uma que fornece acesso de gravação ao `index2`. Ou, é possível incluir todas essas permissões em uma única função.
+ **Usuários** — Pessoas ou aplicativos que fazem solicitações ao OpenSearch cluster. Os usuários têm credenciais, sejam chaves de acesso do IAM ou um nome de usuário e senha, que eles especificam quando fazem solicitações.
## Sobre o usuário-mestre
O *usuário principal* no OpenSearch Service é uma combinação de nome de usuário e senha, ou um principal do IAM, que tem permissões completas para o OpenSearch cluster subjacente. Um usuário é considerado usuário principal se tiver todo o acesso ao OpenSearch cluster junto com a capacidade de criar usuários internos, funções e mapeamentos de funções nos OpenSearch painéis.
Um usuário mestre criado no console de OpenSearch serviço ou por meio da CLI é mapeado automaticamente para duas funções predefinidas:
+ `all_access`: fornece total acesso a todas as operações em todo o cluster, permissão para gravar em todos os índices do cluster e permissão para gravar em todos os locatários.
+ `security_manager`: fornece acesso ao [plug-in de segurança](https://opensearch.org/docs/latest/security/) e ao gerenciamento de usuários e permissões.
Com essas duas funções, o usuário obtém acesso à guia **Segurança** nos OpenSearch painéis, onde pode gerenciar usuários e permissões. Se você criar outro usuário interno e mapeá-lo apenas para o perfil `all_access`, esse usuário não terá acesso à guia **Segurança**. Você pode criar usuários-mestres adicionais mapeando-os explicitamente para os perfis `all_access` e `security_manager`. Para instruções, consulte [Usuários primários adicionais](#fgac-more-masters).
Ao criar um usuário-mestre para o domínio, você pode especificar uma *entidade principal do IAM* existente ou criar um usuário-mestre no *banco de dados de usuários internos*. Considere o seguinte ao decidir qual deles usar:
+ **IAM principal** — Se você escolher um IAM principal para seu usuário principal, todas as solicitações para o cluster devem ser assinadas usando o AWS Signature Version 4.
OpenSearch O serviço não leva em consideração nenhuma das permissões do diretor do IAM. O usuário ou perfil do IAM serve apenas para *autenticação*. As políticas sobre esse usuário ou perfil não têm nenhuma relação com a *autorização* do usuário-mestre. A autorização é feita por meio de várias [permissões](https://opensearch.org/docs/latest/security/access-control/permissions/) no plug-in de OpenSearch segurança.
Por exemplo, você pode atribuir zero permissões *do* IAM a um principal do IAM e, desde que a máquina ou pessoa possa se autenticar para esse usuário ou função, ela terá o poder do usuário mestre no OpenSearch Serviço.
Recomendamos o IAM se você quiser usar os mesmos usuários em vários clusters, se quiser usar o Amazon Cognito para acessar painéis ou se tiver OpenSearch clientes que ofereçam suporte à assinatura do Signature versão 4.
+ **Banco de dados de usuários interno**: se você criar um mestre no banco de dados de usuários interno (com uma combinação de nome de usuário e senha), poderá usar a autenticação HTTP básica (bem como as credenciais do IAM) para fazer solicitações ao cluster. A maioria dos clientes oferece suporte à autenticação básica, incluindo [curl](https://curl.haxx.se/), que também oferece suporte à AWS Signature versão 4 com a [opção --aws-sigv4](https://curl.se/docs/manpage.html). O banco de dados interno do usuário é armazenado em um OpenSearch índice, então você não pode compartilhá-lo com outros clusters.
Recomendamos o banco de dados interno de usuários se você não precisar reutilizar usuários em vários clusters, se quiser usar a autenticação básica HTTP para acessar o Dashboards (em vez do Amazon Cognito) ou se você tiver clientes que sejam compatíveis somente com a autenticação básica. O banco de dados interno do usuário é a maneira mais simples de começar a usar o OpenSearch Service.
## Habilitar o controle de acesso detalhado
Ative o controle de acesso refinado usando o console ou a API de AWS CLI configuração. Para obter as etapas, consulte [Criação e gerenciamento de domínios OpenSearch do Amazon Service](createupdatedomains.md).
O controle de acesso refinado requer o Elasticsearch OpenSearch 6.7 ou posterior. Também requer HTTPS para todo o tráfego para o domínio, [criptografia de dados em repouso](encryption-at-rest.md) e [node-to-node criptografia](ntn.md). Dependendo de como você configura os atributos avançados do controle de acesso detalhado, o processamento adicional de suas solicitações pode exigir atributos de computação e memória em nós de dados individuais. Depois que habilitar o controle de acesso refinado, não será possível desabilitá-lo.
### Habilitação do controle de acesso refinado em domínios existentes
Você pode habilitar um controle de acesso refinado em domínios existentes em execução no Elasticsearch 6.7 OpenSearch ou posterior.
**Para habilitar o controle de acesso refinado em um domínio existente (console)**
1. Selecione o seu domínio e escolha **Ações** e, depois, **Editar configurações de segurança**.
1. Selecione **Habilitar o controle de acesso refinado**.
1. Escolha como criar o usuário primário:
+ Se você quiser usar o IAM para o gerenciamento de usuários, escolha **Definir ARN do IAM como usuário primário** e especifique o ARN para uma função do IAM.
+ Se quiser usar o banco de dados de usuário interno, escolha **Criar usuário primário** e especifique um nome de usuário e senha.
1. (Opcional) Selecione **Habilitar o período de migração para política de acesso aberto/baseado em IP**. Essa configuração viabiliza um período de transição de 30 dias durante o qual os usuários existentes podem continuar acessando o domínio sem interrupções e as [políticas de acesso baseado em IP](ac.md#ac-types-ip) e aberto existentes continuarão funcionando com o seu domínio. Durante esse período de migração, recomendamos que os administradores [criem as funções necessárias e as mapeiem para os usuários](#fgac-access-control) para o domínio. Se você usar políticas baseadas em identidade, em vez de uma política de acesso aberto ou baseado em IP, será possível desabilitar essa configuração.
Você também precisa atualizar os seus clientes para trabalhar com controle de acesso refinado durante o período de migração. Por exemplo, se você mapear funções do IAM com controle de acesso refinado, você deve atualizar seus clientes para começar a assinar solicitações com o AWS Signature versão 4. Se você configurar a autenticação básica de HTTP com controle de acesso refinado, deverá atualizar os seus clientes para fornecer as credenciais de autenticação básicas apropriadas nas solicitações.
Durante o período de migração, os usuários que acessarem o endpoint do OpenSearch Dashboards do domínio acessarão diretamente a página **Discover** em vez da página de login. Os administradores e usuários primários podem escolher **Login** para fazer login com credenciais de administrador e configurar mapeamentos de funções.
**Importante**
**OpenSearch O serviço desativa automaticamente o período de migração após 30 dias.** Recomendamos encerrá-lo assim que você criar as funções necessárias e mapeá-las para os usuários. Após o término do período de migração, não será possível habilitá-lo novamente.
1. Escolha **Salvar alterações**.
A alteração aciona uma [implantação azul-verde](managedomains-configuration-changes.md#bg) durante a qual a integridade do cluster fica vermelha, mas todas as operações do cluster permanecem inalteradas.
**Para habilitar o controle de acesso refinado em um domínio existente (CLI)**
Configure `AnonymousAuthEnabled` como `true` para habilitar o período de migração com controle de acesso refinado:
```
aws opensearch update-domain-config --domain-name test-domain --region us-east-1 \
--advanced-security-options '{ "Enabled": true, "InternalUserDatabaseEnabled":true, "MasterUserOptions": {"MasterUserName":"master-username","MasterUserPassword":"master-password"},"AnonymousAuthEnabled": true}'
```
### Sobre o default\$1role
O controle de acesso refinado exige o [mapeamento de funções](#fgac-mapping). Se seu domínio usa [políticas de acesso baseadas em identidade](ac.md#ac-types-identity), o OpenSearch Service mapeia automaticamente seus usuários para uma nova função chamada **default\$1role** para ajudá-lo a migrar adequadamente os usuários existentes. Esse mapeamento temporário garante que os seus usuários ainda possam enviar com êxito solicitações GET e PUT assinadas pelo IAM até que você crie seus próprios mapeamentos de função.
A função não adiciona nenhuma vulnerabilidade ou falha de segurança ao seu domínio do OpenSearch Serviço. Recomendamos excluir a função padrão assim que você configurar suas próprias funções e mapeá-las adequadamente.
### Cenários de migração
A tabela a seguir descreve o comportamento de cada método de autenticação antes e depois de habilitar o controle de acesso refinado em um domínio existente, assim como as etapas que os administradores devem seguir para mapear corretamente seus usuários para funções:
| Método de autenticação | Antes de habilitar o controle de acesso refinado | Depois de habilitar o controle de acesso refinado | Tarefas do administrador |
| --- | --- | --- | --- |
| Políticas baseadas em identidade | Todos os usuários que cumprem a política do IAM podem acessar o domínio. | Não é necessário habilitar o período de migração. OpenSearch O serviço mapeia automaticamente todos os usuários que atendem à política do IAM para o **[default\$1role](#fgac-enabling-defaultrole)** para que eles possam continuar acessando o domínio. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/opensearch-service/latest/developerguide/fgac.html) |
| Políticas baseadas em IP | Todos os usuários dos endereços IP ou blocos CIDR permitidos podem acessar o domínio. | Durante o período de migração de 30 dias, todos os usuários dos endereços IP ou blocos CIDR permitidos poderão continuar acessando o domínio. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/opensearch-service/latest/developerguide/fgac.html) |
| Políticas de acesso aberto | Todos os usuários na Internet podem acessar o domínio. | Durante o período de migração de 30 dias, todos os usuários na Internet podem continuar acessando o domínio. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/opensearch-service/latest/developerguide/fgac.html) |
## Acessando OpenSearch painéis como usuário principal
O controle de acesso refinado tem um plug-in de OpenSearch painéis que simplifica as tarefas de gerenciamento. Você pode usar o Dashboard para gerenciar usuários, funções, mapeamentos, grupos de ação e locatários. No entanto, a página de login do OpenSearch Dashboards e o método de autenticação subjacente diferem, dependendo de como você gerencia os usuários e configura seu domínio.
+ Se desejar usar o IAM para o gerenciamento de usuários, use [Configurando a autenticação do Amazon Cognito para painéis OpenSearch](cognito-auth.md) para acessar o Dashboards. Caso contrário, o Dashboards exibirá uma página de login não funcional. Consulte [Limitações](#fgac-limitations).
Com a autenticação do Amazon Cognito, uma das funções assumidas do grupo de identidades deve corresponder à função do IAM especificada para o usuário primário. Para saber mais sobre essa configuração, consulte [(Opcional) Configuração de acesso granular](cognito-auth.md#cognito-auth-granular) e [Tutorial: Configuração de um domínio com um usuário primário do IAM e autenticação do Amazon Cognito](fgac-iam.md).
![\[Página de login do Cognito\]](http://docs.aws.amazon.com/pt_br/opensearch-service/latest/developerguide/images/cognito-auth.png)
+ Se você escolher usar o banco de dados de usuário interno, você pode fazer login no Painéis com seu nome de usuário primário e senha. Você deverá acessar o Dashboards via HTTPS. O Amazon Cognito e a autenticação SAML para Dashboards substituem essa tela de login.
Para saber mais sobre essa configuração, consulte [Tutorial: Configuração de um domínio com o banco de dados interno do usuário e a autenticação básica HTTP](fgac-http-auth.md).
![\[Página de login de autenticação básica\]](http://docs.aws.amazon.com/pt_br/opensearch-service/latest/developerguide/images/basic-auth-dashboards.png)
+ Se você optar por usar a autenticação SAML, poderá fazer login usando credenciais de um provedor de identidade externo. Para saber mais, consulte [Autenticação SAML para painéis OpenSearch](saml.md).
## Gerenciar permissões
Conforme observado em [Principais conceitos](#fgac-concepts), você gerencia permissões de controle de acesso refinado usando funções, usuários e mapeamentos. Esta seção descreve como criar e aplicar esses recursos. Recomendamos [fazer login no Dashboards como o usuário primário](#fgac-dashboards) para executar essas operações.
![\[Página inicial de segurança no Dashboards\]](http://docs.aws.amazon.com/pt_br/opensearch-service/latest/developerguide/images/dashboards-fgac-home.png)
**nota**
As permissões que você escolhe conceder aos usuários variam amplamente com base no caso de uso. Não podemos cobrir todos os cenários nesta documentação. Ao determinar quais permissões conceder aos seus usuários, faça referência às permissões de OpenSearch cluster e índice mencionadas nas seções a seguir e sempre siga o [princípio do privilégio mínimo](https://en.wikipedia.org/wiki/Principle_of_least_privilege).
### Criar funções
Você pode criar novas funções para um controle de acesso refinado usando OpenSearch painéis ou a `_plugins/_security` operação na API REST. Para saber mais, consulte [Criar funções](https://opensearch.org/docs/latest/security/access-control/users-roles/#create-roles).
O controle de acesso refinado também inclui várias [funções predefinidas](https://opensearch.org/docs/latest/security/access-control/users-roles/#predefined-roles). Clientes como OpenSearch Dashboards e Logstash fazem uma grande variedade de solicitações OpenSearch, o que pode dificultar a criação manual de funções com o conjunto mínimo de permissões. Por exemplo, a função `opensearch_dashboards_user` inclui as permissões de que um usuário precisa para criar padrões de índice, visualizações, painéis e locatários. Recomendamos [mapeá-la](#fgac-mapping) em qualquer função de usuário ou de backend que acesse o Dashboards, juntamente com funções adicionais que permitam o acesso a outros índices.
O Amazon OpenSearch Service não oferece as seguintes OpenSearch funções:
+ `observability_full_access`
+ `observability_read_access`
+ `reports_read_access`
+ `reports_full_access`
O Amazon OpenSearch Service oferece várias funções que não estão disponíveis com OpenSearch:
+ `ultrawarm_manager`
+ `ml_full_access`
+ `cold_manager`
+ `notifications_full_access`
+ `notifications_read_access`
#### Segurança em nível de cluster
As permissões em nível de cluster incluem a capacidade de realizar solicitações amplas, como `_mget`, `_msearch` e `_bulk`, monitorar a integridade, obter snapshots e muito mais. Gerencie essas permissões usando a seção **Permissões do cluster** ao criar uma função. Para obter a lista completa das permissões no nível do cluster, consulte [Permissões de cluster](https://opensearch.org/docs/latest/security/access-control/permissions/#cluster-permissions).
Em vez de usar permissões individuais, muitas vezes você pode alcançar a postura de segurança desejada usando uma combinação dos grupos de ação padrão. Para obter uma lista de grupos de ação no nível do cluster, consulte [Nível do cluster](https://opensearch.org/docs/latest/security/access-control/default-action-groups/#cluster-level).
#### Segurança em nível de índice
As permissões no nível do índice incluem a capacidade de criar novos índices, pesquisar índices, ler e escrever documentos, excluir documentos, gerenciar aliases e muito mais. Gerencie essas permissões usando a seção **Permissões do índice** ao criar uma função. Para obter a lista completa das permissões no nível do índice, consulte [Permissões de índice](https://opensearch.org/docs/latest/security/access-control/permissions/#index-permissions).
Em vez de usar permissões individuais, muitas vezes você pode alcançar a postura de segurança desejada usando uma combinação dos grupos de ação padrão. Para obter uma lista de grupos de ação no nível do índice, consulte [Nível do índice](https://opensearch.org/docs/latest/security/access-control/default-action-groups/#index-level).
#### Segurança em nível de documento
A segurança no nível do documento permite restringir quais documentos em um índice um usuário pode ver. Ao criar uma função, especifique um padrão de índice e uma OpenSearch consulta. Qualquer usuário mapeado para essa função poderá ver somente os documentos que correspondam à consulta. A segurança no nível do documento afeta [o número de ocorrências que você recebe ao pesquisar](#fgac-example).
Para saber mais, consulte [Segurança em nível de documento](https://opensearch.org/docs/latest/security/access-control/document-level-security/).
#### Segurança em nível de campo
A segurança no nível do campo permite controlar quais campos de documento um usuário pode ver. Ao criar uma função, adicione uma lista de campos a serem incluídos ou excluídos. Se você incluir campos, os usuários que você mapear para essa função poderão ver somente esses campos. Se você excluir campos, eles poderão ver todos os campos *exceto* os excluídos. A segurança no nível do campo afeta [o número de campos incluídos em ocorrências ao pesquisar](#fgac-example).
Para saber mais, consulte [Segurança em nível de campo](https://opensearch.org/docs/latest/security/access-control/field-level-security/).
#### 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](#fgac-example).
**dica**
Se você aplicar o mascaramento padrão a um campo, o OpenSearch Service usará um hash seguro e aleatório que pode causar resultados de agregação imprecisos. Para executar agregações em campos mascarados, use o mascaramento baseado em padrões.
### Criação de usuários do
Se você ativou o banco de dados interno do usuário, poderá criar usuários usando OpenSearch painéis ou a `_plugins/_security` operação na API REST. Para saber mais, consulte [Criar usuários](https://opensearch.org/docs/latest/security/access-control/users-roles/#create-users).
Se você escolheu o IAM para seu usuário primário, ignore esta parte do Dashboards. Crie perfis do IAM. Para saber mais, consulte o [Manual do usuário do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/).
### Mapear funções em usuários
O mapeamento de função é o aspecto mais crítico do controle de acesso refinado. O controle de acesso refinado tem algumas funções predefinidas para ajudar a começar, mas a menos que você mapeie funções para os usuários, cada solicitação ao cluster terminará em um erro de permissões.
*As funções de backend* podem ajudar a simplificar o processo de mapeamento de funções. Em vez de mapear a mesma perfil para 100 usuários individuais, é possível mapear a perfil para uma única perfil de backend. Todos os 100 usuários compartilham. As funções de backend podem ser funções do IAM ou strings arbitrárias.
+ **Especifique usuários ARNs, usuários e cadeias de caracteres de usuário do Amazon Cognito na seção Usuários.** As strings de usuário do Cognito assumem a forma de `Cognito/user-pool-id/username`.
+ Especifique as funções de back-end e a função do IAM ARNs na seção **Funções de back-end**.
![\[Tela de mapeamento de funções\]](http://docs.aws.amazon.com/pt_br/opensearch-service/latest/developerguide/images/role-mapping-edit.png)
Você pode mapear funções para usuários usando OpenSearch painéis ou a `_plugins/_security` operação na API REST. Para saber mais sobre as funções de usuário, consulte [Mapear usuários em funções](https://opensearch.org/docs/latest/security/access-control/users-roles/#map-users-to-roles).
### Criação de grupos de ação
Grupos de ação são conjuntos de permissões que podem ser reutilizados em diferentes recursos. Você pode criar novos grupos de ação usando OpenSearch painéis ou a `_plugins/_security` operação na API REST, embora os grupos de ação padrão sejam suficientes para a maioria dos casos de uso. Para saber mais sobre os grupos de ação padrão, consulte [Grupos de ação padrão](https://opensearch.org/docs/latest/security/access-control/default-action-groups/).
### OpenSearch Multilocação de painéis
Locatários são espaços para salvar padrões de índice, visualizações, painéis e outros objetos do Dashboards. A locação múltipla dos Painéis permite que você compartilhe seu trabalho de forma segura com outros usuários dos Painéis (ou mantenha-o privado) e configure as locações dinamicamente. É possível controlar quais funções têm acesso a um locatário e se essas funções têm acesso de leitura ou gravação. O inquilino global é o padrão. Para saber mais, consulte [Multilocação de OpenSearch painéis](https://opensearch.org/docs/latest/security/multi-tenancy/tenant-index/).
**Como visualizar o locatário atual ou alterar locatários**
1. Navegue até OpenSearch Painéis e faça login.
1. Selecione o ícone de usuário no canto superior direito e escolha **Alternar locatários**.
1. Verifique seu locatário antes de criar visualizações ou painéis. Se você deseja compartilhar seu trabalho com todos os outros usuários do Dashboards, escolha **Global**. Para compartilhar seu trabalho com um subconjunto de usuários do Dashboards, escolha um locatário compartilhado diferente. Caso contrário, escolha **Privado**.
**nota**
OpenSearch Os painéis mantêm um índice separado para cada inquilino e criam um modelo de índice chamado. `tenant_template` Não exclua nem modifique o `tenant_template` índice, pois isso pode causar mau funcionamento dos OpenSearch painéis se o mapeamento do índice do inquilino estiver configurado incorretamente.
## Configurações recomendadas
Devido à forma como o controle de acesso refinado[interage com outros recursos de segurança](#fgac-access-policies), recomendamos várias configurações de controle de acesso refinado que funcionam bem na maioria dos casos de uso.
| Description | Usuário primário | Política de acesso ao domínio |
| --- | --- | --- |
| Use as credenciais do IAM para chamadas para o OpenSearch APIs e use a [autenticação SAML](saml.md) para acessar os painéis. Gerencie funções de controle de acesso detalhado usando o Dashboards ou a API REST. | Usuário ou perfil do IAM | JSON
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "*"
},
"Action": "es:ESHttp*",
"Resource": "arn:aws:es:us-east-1:111122223333:domain/domain-name/*"
}
]
}
``` |
| Use credenciais do IAM ou autenticação básica para chamadas para o. OpenSearch APIs Gerencie funções de controle de acesso detalhado usando o Dashboards ou a API REST. Essa configuração oferece muita flexibilidade, especialmente se você tiver OpenSearch clientes que oferecem suporte apenas à autenticação básica. Se você tiver um provedor de identidade existente, use a [Autenticação do SAML](saml.md) para acessar o Dashboards. Caso contrário, gerencie usuários do Dashboards no banco de dados interno de usuários. | Nome de usuário e senha | JSON
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "*"
},
"Action": "es:ESHttp*",
"Resource": "arn:aws:es:us-east-1:111122223333:domain/domain-name/*"
}
]
}
``` |
| Use as credenciais do IAM para chamadas para o OpenSearch APIs e use o Amazon Cognito para acessar painéis. Gerencie funções de controle de acesso detalhado usando o Dashboards ou a API REST. | Usuário ou perfil do IAM | JSON
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "*"
},
"Action": "es:ESHttp*",
"Resource": "arn:aws:es:us-east-1:111122223333:domain/domain-name/*"
}
]
}
``` |
| Use as credenciais do IAM para chamadas para o OpenSearch APIs e bloqueie a maior parte do acesso aos painéis. Gerencie funções de controle de acesso refinado usando a API REST. | Usuário ou perfil do IAM | JSON
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "*"
},
"Action": "es:ESHttp*",
"Resource": "arn:aws:es:us-east-1:111122223333:domain/domain-name/*"
},
{
"Effect": "Deny",
"Principal": {
"AWS": "*"
},
"Action": "es:ESHttp*",
"Resource": "arn:aws:es:us-east-1:111122223333:domain/domain-name/_dashboards*"
}
]
}
``` |
## Limitações
O controle de acesso refinado tem várias limitações importantes:
+ O aspecto `hosts` dos mapeamentos de função, que mapeia funções para os nomes de host ou endereços IP, não funcionará se o domínio estiver dentro de uma VPC. Ainda assim, é possível mapear funções para usuários e funções de backend.
+ Se você escolher o IAM para o usuário primário e não habilitar a autenticação do Amazon Cognito ou SAML, o Dashboards exibirá uma página de login não funcional.
+ Se você escolher o IAM para o usuário primário, ainda poderá criar usuários no banco de dados interno de usuários. No entanto, como a autenticação básica HTTP não está habilitada nesta configuração, quaisquer pedidos assinados com essas credenciais de utilizador serão rejeitados.
+ Se utilizar o [SQL](sql-support.md) 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](indexing.md#indexing-naming). Para negar todo o acesso ao SQL, adicione o seguinte elemento à sua política de acesso ao domínio:
```
{
"Effect": "Deny",
"Principal": {
"AWS": [
"*"
]
},
"Action": [
"es:*"
],
"Resource": "arn:aws:es:us-east-1:123456789012:domain/my-domain/_plugins/_sql"
}
```
+ Se a versão do seu domínio for 2.3 ou superior e você tiver um controle de acesso detalhado ativado, `max_clause_count` a configuração como 1 causará problemas com seu domínio. Recomendamos definir essa conta para um número maior.
+ Se estiver habilitando o controle de acesso refinado em um domínio no qual o controle de acesso refinado não está configurado, para fontes de dados criadas para consulta direta, você mesmo precisará configurar os perfis de controle de acesso refinado. Para obter mais informações sobre como configurar funções de acesso refinadas, consulte Criação de [integrações de fontes de dados do Amazon OpenSearch Service com o Amazon](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/direct-query-s3-creating.html#direct-query-s3-prereq) S3.
## Modificação do usuário primário
Se você esquecer os detalhes do usuário primário, poderá reconfigurá-lo usando o console, a AWS CLI ou a API de configuração.
**Como modificar o usuário primário (console)**
1. Navegue até o console do Amazon OpenSearch Service em [https://console.aws.amazon.com/aos/home/](https://console.aws.amazon.com/aos/home/).
1. Escolha o seu domínio e escolha **Ações**, **Editar configurações de segurança**.
1. Escolha **Definir ARN do IAM como usuário primário** ou **Criar novo usuário primário**.
+ Se você usou anteriormente um usuário primário do IAM, o controle de acesso refinado mapeará novamente a função `all_access` para o novo ARN do IAM especificado.
+ Se você usou anteriormente o banco de dados interno de usuários, o controle de acesso refinado criará um novo usuário primário. É possível usar o novo usuário primário para excluir o antigo.
+ A mudança do banco de dados de usuário interno para um usuário primário do IAM *não* exclui os usuários do banco de dados interno de usuários. Em vez disso, ela apenas desabilita a autenticação básica HTTP. Exclua manualmente os usuários do banco de dados interno do usuário ou mantenha-os para o caso de precisar reativar a autenticação básica HTTP.
1. Escolha **Salvar alterações**.
## Usuários primários adicionais
Você designa um usuário primário ao criar um domínio, mas, se desejar, pode usar esse usuário primário para criar usuários primários adicionais. Você tem duas opções: OpenSearch painéis ou a API REST.
+ No Dashboards, escolha **Segurança**, **Funções** e mapeie o novo usuário primário nas funções `all_access` e `security_manager`.
![\[Página Mapeamento de funções\]](http://docs.aws.amazon.com/pt_br/opensearch-service/latest/developerguide/images/new-master-users.png)
+ Para usar a API REST, envie as seguintes solicitações:
```
PUT _plugins/_security/api/rolesmapping/all_access
{
"backend_roles": [
"arn:aws:iam::123456789012:role/fourth-master-user"
],
"hosts": [],
"users": [
"master-user",
"second-master-user",
"arn:aws:iam::123456789012:user/third-master-user"
]
}
```
```
PUT _plugins/_security/api/rolesmapping/security_manager
{
"backend_roles": [
"arn:aws:iam::123456789012:role/fourth-master-user"
],
"hosts": [],
"users": [
"master-user",
"second-master-user",
"arn:aws:iam::123456789012:user/third-master-user"
]
}
```
Essas solicitações *substituem* os mapeamentos de função atuais, portanto, execute as solicitações `GET` primeiro para que você possa incluir todas as funções atuais nas solicitações `PUT`. A API REST será especialmente útil se você não conseguir acessar o Dashboards e quiser mapear uma função do IAM do Amazon Cognito na função `all_access`.
## Snapshots manuais
O controle de acesso refinado apresenta algumas complicações adicionais quando são tirados snapshots manuais. Para registrar um repositório de snapshots, mesmo que use a autenticação básica HTTP para todos os outros fins, você deve mapear a função `manage_snapshots` em uma função do IAM que tenha permissões `iam:PassRole` para assumir `TheSnapshotRole`, conforme definido nos [Pré-requisitos](managedomains-snapshots.md#managedomains-snapshot-prerequisites).
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](managedomains-snapshot-registerdirectory.md).
## Integrações
Se você usa [outros AWS serviços](integrations.md) com o OpenSearch Service, deve fornecer as funções do IAM para esses serviços com as permissões apropriadas. Por exemplo, os fluxos de entrega do Firehose frequentemente usam um perfil do IAM denominado `firehose_delivery_role`. No Dashboards, [crie uma função para o controle de acesso refinado](#fgac-roles) e [mapeie a função do IAM nela](#fgac-mapping). Nesse caso, a nova função precisará das seguintes permissões:
```
{
"cluster_permissions": [
"cluster_composite_ops",
"cluster_monitor"
],
"index_permissions": [{
"index_patterns": [
"firehose-index*"
],
"allowed_actions": [
"create_index",
"manage",
"crud"
]
}]
}
```
As permissões variam de acordo com as ações que cada serviço executa. Uma AWS IoT regra ou AWS Lambda função que indexa dados provavelmente precisa de permissões semelhantes às do Firehose, enquanto uma função Lambda que só realiza pesquisas pode usar um conjunto mais limitado.
## Diferenças de API REST
A API REST do controle de acesso minucioso difere ligeiramente dependendo da sua versão do OpenSearch/Elasticsearch . Antes de fazer uma solicitação `PUT`, faça uma solicitação `GET` para verificar o corpo da solicitação esperada. Por exemplo, uma solicitação `GET` para `_plugins/_security/api/user` retornar todos os usuários, que poderá ser modificada e usada para fazer solicitações `PUT` válidas.
No Elasticsearch 6.*x*, as solicitações para criar usuários são semelhantes a:
```
PUT _opendistro/_security/api/user/new-user
{
"password": "some-password",
"roles": ["new-backend-role"]
}
```
No OpenSearch Elasticsearch 7.x, as solicitações têm a seguinte aparência (altere `_plugins` para `_opendistro` se estiver usando o Elasticsearch):
```
PUT _plugins/_security/api/user/new-user
{
"password": "some-password",
"backend_roles": ["new-backend-role"]
}
```
Além disso, os locatários são propriedades de funções no Elasticsearch 6.*x*:
```
GET _opendistro/_security/api/roles/all_access
{
"all_access": {
"cluster": ["UNLIMITED"],
"tenants": {
"admin_tenant": "RW"
},
"indices": {
"*": {
"*": ["UNLIMITED"]
}
},
"readonly": "true"
}
}
```
No OpenSearch Elasticsearch 7.x, eles são objetos com seu próprio URI (altere `_plugins` para `_opendistro` se estiver usando o Elasticsearch):
```
GET _plugins/_security/api/tenants
{
"global_tenant": {
"reserved": true,
"hidden": false,
"description": "Global tenant",
"static": false
}
}
```
Para obter a documentação sobre a API OpenSearch REST, consulte a [referência da API do plug-in de segurança](https://opensearch.org/docs/latest/security/access-control/api/).
**dica**
Se usar o banco de dados de usuário interno, você poderá usar [curl](https://curl.haxx.se/) para fazer solicitações e testar seu domínio. Teste os seguintes comandos de exemplo:
```
curl -XGET -u 'master-user:master-user-password' 'domain-endpoint/_search'
curl -XGET -u 'master-user:master-user-password' 'domain-endpoint/_plugins/_security/api/user'
```
# Tutorial: Configuração de um domínio com um usuário primário do IAM e autenticação do Amazon Cognito
Este tutorial aborda um caso de uso popular do Amazon OpenSearch Service para [controle de acesso refinado](fgac.md): um usuário mestre do IAM com autenticação do Amazon Cognito para painéis. OpenSearch
No tutorial, configuraremos um perfil do IAM *principal* e um perfil do IAM *limitado*, que depois associaremos aos usuários no Amazon Cognito. O usuário principal pode então entrar nos OpenSearch painéis, mapear o usuário limitado para uma função e usar um controle de acesso refinado para limitar as permissões do usuário.
![\[IAM roles and Amazon Cognito integration with OpenSearch Dashboards access control.\]](http://docs.aws.amazon.com/pt_br/opensearch-service/latest/developerguide/images/fgac-cognito.png)
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.
Você concluirá as seguintes etapas neste tutorial:
1. [Criar perfis do IAM principais e limitado](#fgac-iam-roles)
1. [Criar um domínio com a autenticação Cognito](#fgac-iam-domain)
1. [Configurar um grupo de usuários e um banco de identidades do Cognito](#fgac-iam-cognito)
1. [Mapeie funções em OpenSearch painéis](#fgac-iam-dashboards)
1. [Testas as permissões](#fgac-iam-test)
## Etapa 1: Criar perfis do IAM principal e limitado
Navegue até o console AWS Identity and Access Management (IAM) e crie duas funções separadas:
+ `MasterUserRole`: o usuário primário, que terá permissões completas para o cluster e gerencia funções e mapeamentos de função.
+ `LimitedUserRole`: um perfil mais restrito, à qual você concederá acesso limitado como usuário primário.
Para receber instruções passo a passo para criar perfis, consulte [Criar um perfil usando políticas de confiança personalizadas](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-custom.html) no *Guia do usuário do IAM*.
Ambos os perfis devem ter a política de confiança a seguir, que permite que seu grupo de identidades do Cognito assuma os perfis:
------
#### [ JSON ]
****
```
{
"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"
}
}
}]
}
```
------
**nota**
Substitua `identity-pool-id` pelo identificador exclusivo do seu grupo de identidades do Amazon Cognito. Por exemplo, .`us-east-1:0c6cdba7-3c3c-443b-a958-fb9feb207aa6`
## Etapa 2: Criar um domínio com a autenticação Cognito
Navegue até o console do Amazon OpenSearch Service em [https://console.aws.amazon.com/aos/casa/](https://console.aws.amazon.com/aos/home/) e [crie um domínio](createupdatedomains.md) com as seguintes configurações:
+ OpenSearch 1.0 ou posterior, ou Elasticsearch 7.8 ou posterior
+ Acesso público
+ Controle de acesso minucioso habilitado com `MasterUserRole` como usuário primário (criado na etapa anterior)
+ Autenticação do Amazon Cognito habilitada para painéis OpenSearch . Para obter instruções para habilitar a autenticação do Cognito e selecionar um usuário e um grupo de identidades, consulte [Configuração de um domínio para uso da autenticação do Amazon Cognito](cognito-auth.md#cognito-auth-config).
+ A seguinte política de acesso ao domínio:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:root"
},
"Action": [
"es:ESHttp*"
],
"Resource": "arn:aws:es:us-east-1:111122223333:domain/{domain-name}/*"
}
]
}
```
------
+ HTTPS necessário para todo o tráfego para o domínio
+ Node-to-node criptografia
+ Criptografia de dados em repouso
## Etapa 3: Configurar usuários do Cognito
Enquanto seu domínio estiver sendo criado, configure os usuários principal e limitado no Amazon Cognito seguindo [Criar um grupo de usuários](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pool-as-user-directory.html) no *Guia do desenvolvedor do Amazon Cognito*. Por fim, configure seu banco de identidades seguindo as etapas em [Criar um grupo de identidades no Amazon Cognito](https://docs.aws.amazon.com/cognito/latest/developerguide/getting-started-with-identity-pools.html#create-identity-pool). Os grupos de usuários e identidades devem estar na mesma Região da AWS.
## Etapa 4: mapear funções em OpenSearch painéis
Agora que seus usuários estão configurados, você pode entrar no OpenSearch Dashboards como usuário principal e mapear usuários para funções.
1. Volte para o console OpenSearch de serviços e navegue até a URL dos OpenSearch painéis do domínio que você criou. O URL segue este formato: `domain-endpoint/_dashboards/`.
1. Faça login com as credenciais `master-user`.
1. Escolha **Adicionar dados de amostras** e adicione os dados de voo de amostra.
1. No painel de navegação à esquerda, escolha **Segurança**, **Funções**, **Criar função**.
1. Nomeie a função `new-role`.
1. Em **Índice**, especifique `opensearch_dashboards_sample_data_fli*` (`kibana_sample_data_fli*` nos domínios do Elasticsearch).
1. Em **Permissões de índice**, escolha **ler**.
1. Em **Segurança em nível de documento**, especifique a seguinte consulta:
```
{
"match": {
"FlightDelay": true
}
}
```
1. Para segurança em nível de campo, escolha **Excluir** e especifique `FlightNum`.
1. Em **Anonimização**, especifique `Dest`.
1. Escolha **Criar**.
1. Escolha **Usuários mapeados** e **Gerenciar mapeamento**. Adicione o nome do recurso da Amazon (ARN) para `LimitedUserRole` como uma identidade externa e escolha **Mapa**.
1. Retorne à lista de funções e escolha **opensearch\$1dashboards\$1user**. Escolha **Usuários mapeados** e **Gerenciar mapeamento**. Adicione o ARN para `LimitedUserRole` como uma função de backend e escolha **Mapa**.
## Etapa 5: Testar as permissões
Quando suas funções estiverem mapeadas corretamente, é possível fazer login como o usuário limitado e testá-las.
1. Em uma nova janela privada do navegador, navegue até o URL dos OpenSearch painéis do domínio, faça login usando `limited-user` as credenciais e escolha **Explorar sozinho**.
1. Escolha **Ferramentas de desenvolvimento** e execute a pesquisa padrão:
```
GET _search
{
"query": {
"match_all": {}
}
}
```
Observe o erro de permissões. `limited-user` não tem permissões para executar pesquisas em todo o cluster.
1. Execute outra pesquisa:
```
GET opensearch_dashboards_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`.
1. Na janela original do navegador, conectado como `master-user`, escolha **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: Configuração de um domínio com o banco de dados interno do usuário e a autenticação básica HTTP
Este tutorial aborda outro caso de uso de [controle de acesso refinado](fgac.md) e popular: um usuário principal no banco de dados de usuários interno e autenticação básica HTTP para painéis. OpenSearch O usuário principal pode então entrar nos OpenSearch painéis, criar um usuário interno, mapear o usuário para uma função e usar um controle de acesso refinado para limitar as permissões do usuário.
Você concluirá as seguintes etapas neste tutorial:
1. [Crie um domínio com um usuário primário](#fgac-http-auth-domain)
1. [Configurar um usuário interno nos OpenSearch painéis](#fgac-http-auth-dashboards-user)
1. [Mapeie funções em OpenSearch painéis](#fgac-http-auth-dashboards-map)
1. [Testas as permissões](#fgac-http-auth-test)
## Etapa 1: Criar um domínio
Navegue até o console do Amazon OpenSearch Service em [https://console.aws.amazon.com/aos/casa/](https://console.aws.amazon.com/aos/home/) e [crie um domínio](createupdatedomains.md) com as seguintes configurações:
+ OpenSearch 1.0 ou posterior, ou Elasticsearch 7.9 ou posterior
+ Acesso público
+ Controle de acesso refinado com um usuário primário no banco de dados interno de usuários (`TheMasterUser` para o restante deste tutorial)
+ Autenticação do Amazon Cognito para Dashboards *desabilitada*
+ A seguinte política de acesso:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:root"
},
"Action": [
"es:ESHttp*"
],
"Resource": "arn:aws:es:us-east-1:111122223333:domain/{domain-name}/*"
}
]
}
```
------
+ HTTPS necessário para todo o tráfego para o domínio
+ Node-to-node criptografia
+ Criptografia de dados em repouso
## Etapa 2: criar um usuário interno nos OpenSearch painéis
Agora que você tem um domínio, pode entrar no OpenSearch Dashboards e criar um usuário interno.
1. Volte para o console OpenSearch de serviços e navegue até a URL dos OpenSearch painéis do domínio que você criou. O URL segue este formato: `domain-endpoint/_dashboards/`.
1. Faça login com o `TheMasterUser`.
1. Escolha **Adicionar dados de amostras** e adicione os dados de voo de amostra.
1. No painel de navegação à esquerda, escolha **Segurança**, **Usuários internos**, **Criar usuário interno**.
1. Nomeie o usuário `new-user` e especifique uma senha. Em seguida, escolha **Criar**.
## Etapa 3: mapear funções em OpenSearch painéis
Agora que seu usuário está configurado, você pode mapeá-lo para uma perfil.
1. Fique na seção **Segurança** dos OpenSearch Painéis e escolha **Funções**, **Criar função**.
1. Nomeie a função `new-role`.
1. Em **Índice**, especifique `opensearch_dashboards_sample_data_fli*`(`kibana_sample_data_fli*` nos domínios do Elasticsearch) para o padrão de índice.
1. Para o grupo de ações, escolha **leitura**.
1. Em **Segurança em nível de documento**, especifique a seguinte consulta:
```
{
"match": {
"FlightDelay": true
}
}
```
1. Para segurança em nível de campo, escolha **Excluir** e especifique `FlightNum`.
1. Em **Anonimização**, especifique `Dest`.
1. Escolha **Criar**.
1. Escolha **Usuários mapeados** e **Gerenciar mapeamento**. Em seguida, adicione `new-user` a **Usuários** e escolha **Mapa**.
1. Retorne à lista de funções e escolha **opensearch\$1dashboards\$1user**. Escolha **Usuários mapeados** e **Gerenciar mapeamento**. Em seguida, adicione `new-user` a **Usuários** e escolha **Mapa**.
## Etapa 4: Testar as permissões
Quando suas funções estiverem mapeadas corretamente, é possível fazer login como o usuário limitado e testá-las.
1. Em uma nova janela privada do navegador, navegue até o URL dos OpenSearch painéis do domínio, faça login usando `new-user` as credenciais e escolha **Explorar sozinho**.
1. Escolha **Ferramentas de desenvolvimento** e execute a pesquisa padrão:
```
GET _search
{
"query": {
"match_all": {}
}
}
```
Observe o erro de permissões. `new-user` não tem permissões para executar pesquisas em todo o cluster.
1. Execute outra pesquisa:
```
GET dashboards_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`.
1. Na janela original do navegador, conectado como `TheMasterUser`, escolha **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.