Gerenciamento de identidade e acesso no Amazon OpenSearch Service - Amazon OpenSearch Service

Gerenciamento de identidade e acesso no Amazon OpenSearch Service

O Amazon OpenSearch Service oferece várias formas de controlar o acesso aos seus domínios. Esta seção aborda os diversos tipos de políticas, como elass interagem entre si e como você pode criar suas próprias políticas personalizadas.

Importante

O suporte a VPC apresenta algumas considerações adicionais sobre o controle de acesso do OpenSearch Service. Para mais informações, consulte Sobre políticas de acesso em domínios da VPC.

Tipos de políticas

O OpenSearch Service oferece suporte a três tipos de políticas de acesso:

Políticas baseadas em recursos

Quando um domínio é criado, uma política baseada em recurso é adicionada, muitas vezes chamada de política de acesso ao domínio. Essas políticas especificam que ações uma entidade principal pode executar nos sub-recursos do domínio (com exceção da pesquisa entre clusters). Os sub-recursos incluem índices e APIs do OpenSearch. O elemento Principal especifica as contas, os usuários ou as funções com acesso permitido. O elemento Resource especifica quais sub-recursos essas entidades principais podem acessar.

A política baseada em recurso a seguir concede ao test-user (es:*) acesso total aos sub-recursos em test-domain:

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": [ "arn:aws:iam::123456789012:user/test-user" ] }, "Action": [ "es:*" ], "Resource": "arn:aws:es:us-west-1:987654321098:domain/test-domain/*" } ] }

Duas considerações importantes se aplicam a essa política:

  • Esses privilégios se aplicam apenas a esse domínio. A menos que você crie políticas semelhantes em outros domínios, test-user só poderá acessar test-domain.

  • O terminador /* no elemento Resource é significativo e indica que as políticas baseadas em recursos só se aplicam aos sub-recursos do domínio, e não ao próprio domínio. Em políticas baseadas em recursos, a ação es:* é equivalente a es:ESHttp*.

    Por exemplo, o test-user pode fazer solicitações em relação a um índice (GET https://search-test-domain.us-west-1.es.amazonaws.com/test-index), mas não pode atualizar a configuração do domínio (POST https://es.us-west-1.amazonaws.com/2021-01-01/opensearch/domain/test-domain/config). Observe a diferença entre os dois endpoints. O acesso à API de configuração requer uma política baseada em identidade.

Você pode especificar um nome de índice parcial adicionando um curinga. Este identifica todos os índices que começam com commerce:

arn:aws:es:us-west-1:987654321098:domain/test-domain/commerce*

Nesse caso, especificar o uso desse curinga significa que o test-user pode fazer solicitações para índices no domínio test-domain que têm nomes que começam com commerce.

Para restringir ainda mais o test-user, você pode aplicar a seguinte política:

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": [ "arn:aws:iam::123456789012:user/test-user" ] }, "Action": [ "es:ESHttpGet" ], "Resource": "arn:aws:es:us-west-1:987654321098:domain/test-domain/commerce-data/_search" } ] }

Agora, o test-user só pode executar uma operação: pesquisar no índice commerce-data. Todos os outros índices no domínio estão inacessíveis, e sem permissões para usar as ações es:ESHttpPut ou es:ESHttpPost, o test-user não pode adicionar ou modificar documentos.

Em seguida, você pode optar por configurar uma função para usuários avançados. Esta política oferece acesso power-user-role aos métodos HTTP GET e PUT para todos os URIs no índice:

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": [ "arn:aws:iam::123456789012:role/power-user-role" ] }, "Action": [ "es:ESHttpGet", "es:ESHttpPut" ], "Resource": "arn:aws:es:us-west-1:987654321098:domain/test-domain/commerce-data/*" } ] }

Se o seu domínio estiver em uma VPC ou usar controle de acesso refinado, você poderá usar uma política de acesso a domínios abertos. Caso contrário, sua diretiva de acesso ao domínio deverá conter alguma restrição, seja por endereço IP ou principal.

Para obter informações sobre todas as ações disponíveis, consulte Referência de elementos da política. Para obter um controle muito mais granular sobre seus dados, use uma política de acesso a domínio aberto com controle de acesso refinado.

Políticas baseadas em identidade

Ao contrário do que ocorre com as políticas baseadas em recursos, que são parte de cada domínio do OpenSearch Service, as políticas baseadas em identidade são associadas a usuários ou funções usando o serviço AWS Identity and Access Management (IAM). Assim como nas políticas baseadas em recursos, as políticas baseadas em identidade especificam quem pode acessar um serviço, quais ações podem ser executadas e, se aplicável, em quais recursos essas ações podem ser executadas.

As políticas baseadas em identidade tendem a ser mais genéricas, embora não exista essa exigência. Elas geralmente controlam somente as ações de API de configuração que um usuário pode realizar. Depois de estabelecer essas políticas, você poderá usar as políticas baseadas em recursos (ou o controle de acesso refinado) no OpenSearch Service para oferecer aos usuários acesso a índices e APIs do OpenSearch.

nota

Os usuários com a política AmazonOpenSearchServiceReadOnlyAccess gerenciada pela AWS não podem ver o status de integridade do cluster no console. Para permitir que eles vejam o status de integridade do cluster (e outros dados do OpenSearch), adicione a ação es:ESHttpGet a uma política de acesso e anexe-a às respectivas contas ou funções.

Como as políticas baseadas em identidade são anexadas a usuários ou funções (principais), o JSON não especifica um principal. A política a seguir concede acesso a ações que começam com Describe e List. Essa combinação de ações fornece acesso somente leitura a configurações de domínio, mas não aos dados armazenados no próprio domínio:

{ "Version": "2012-10-17", "Statement": [ { "Action": [ "es:Describe*", "es:List*" ], "Effect": "Allow", "Resource": "*" } ] }

Um administrador pode ter acesso total ao OpenSearch Service e a todos os dados armazenados em todos os domínios:

{ "Version": "2012-10-17", "Statement": [ { "Action": [ "es:*" ], "Effect": "Allow", "Resource": "*" } ] }

As políticas baseadas em identidade permitem que você use etiquetas para controlar o acesso à API de configuração. A seguinte política, por exemplo, permitirá que os principais anexados visualizem e atualizem a configuração de um domínio se o domínio tiver a tag team:devops:

{ "Version": "2012-10-17", "Statement": [{ "Action": [ "es:UpdateDomainConfig", "es:DescribeDomain", "es:DescribeDomainConfig" ], "Effect": "Allow", "Resource": "*", "Condition": { "ForAnyValue:StringEquals": { "aws:ResourceTag/team": [ "devops" ] } } }] }

Também é possível usar etiquetas para controlar o acesso às APIs do OpenSearch. As políticas baseadas em etiquetas para APIs do OpenSearch só se aplicam a métodos HTTP. Por exemplo, a política a seguir permitirá que as entidades principais anexadas enviem solicitações GET e PUT para a API do OpenSearch se o domínio tiver a etiqueta environment:production:

{ "Version": "2012-10-17", "Statement": [{ "Action": [ "es:ESHttpGet", "es:ESHttpPut" ], "Effect": "Allow", "Resource": "*", "Condition": { "ForAnyValue:StringEquals": { "aws:ResourceTag/environment": [ "production" ] } } }] }

Para um controle mais granular das APIs do OpenSearch, considere usar o controle de acesso refinado.

nota

Depois de adicionar uma ou mais APIs do OpenSearch a qualquer política baseada em etiqueta, você deverá executar uma única operação de etiqueta (como adicionar, remover ou modificar uma etiqueta) para que as alterações sejam aplicadas a um domínio. Para incluir operações de APIs do OpenSearch em políticas baseadas em etiquetas, é necessário estar no software de serviço R20211203 ou posterior.

O OpenSearch Service oferece suporte às chaves de condição globais RequestTag e TagKeys para a API de configuração, mas não para as APIs do OpenSearch. Essas condições aplicam-se somente a chamadas de API que incluem tags dentro da solicitação, como CreateDomain, AddTags e RemoveTags. A política a seguir permite que os principais anexados criem domínios, mas somente se incluírem a tag team:it na solicitação:

{ "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Action": [ "es:CreateDomain", "es:AddTags" ], "Resource": "*", "Condition": { "StringEquals": { "aws:RequestTag/team": [ "it" ] } } } }

Para obter mais detalhes sobre o uso de tags para controle de acesso e as diferenças entre as políticas baseadas em recursos e as baseadas em identidade, consulte o Manual do usuário do IAM.

Políticas baseadas em IP

As políticas baseadas em IP restringem o acesso a um domínio para um ou mais endereços IP ou blocos CIDR. Tecnicamente, as políticas baseadas em IP não são um tipo de política diferente. Na verdade, elas são apenas políticas baseadas em recursos que especificam uma entidade principal anônima e incluem um elemento Condition especial.

O apelo principal das políticas baseadas em IP é que elas permitem solicitações não assinadas a um domínio do OpenSearch, o que permite usar clientes como curl e OpenSearch Dashboards ou acessar o domínio por meio de um servidor de proxy. Para saber mais, consulte Uso de proxy para acessar o OpenSearch Service via Dashboards.

nota

Se você ativou o acesso à VPC para seu domínio, não poderá configurar uma política baseada em IP. Em vez disso, você poderá usar grupos de segurança para controlar quais endereços IP poderão acessar o domínio. Para mais informações, consulte Sobre políticas de acesso em domínios da VPC.

A política a seguir concede a todas as solicitações HTTP que se originam no intervalo de IP especificado acesso ao test-domain:

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "*" }, "Action": [ "es:ESHttp*" ], "Condition": { "IpAddress": { "aws:SourceIp": [ "192.0.2.0/24" ] } }, "Resource": "arn:aws:es:us-west-1:987654321098:domain/test-domain/*" } ] }

Se o seu domínio tiver um endpoint público e não usar controle de acesso refinado, recomendamos combinar principais do IAM e endereços IP. Esta política concederá acesso HTTP ao test-user somente se a solicitação se originar do intervalo de IP especificado:

{ "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Principal": { "AWS": [ "arn:aws:iam::987654321098:user/test-user" ] }, "Action": [ "es:ESHttp*" ], "Condition": { "IpAddress": { "aws:SourceIp": [ "192.0.2.0/24" ] } }, "Resource": "arn:aws:es:us-west-1:987654321098:domain/test-domain/*" }] }

Criação e assinatura de solicitações do OpenSearch Service

Mesmo que você configure uma política de acesso baseada em recursos completamente aberta, todas as solicitações para a API de configuração do OpenSearch Service devem ser assinadas. Se as suas políticas especificam usuários ou funções do IAM, as solicitações para as APIs do OpenSearch devem ser assinadas usando o AWS Signature versão 4. O método de assinatura é diferente dependendo da API:

  • Para fazer chamadas para a API de configuração do OpenSearch Service, recomendamos usar um dos AWS SDKs. Os SDKs simplificam muito o processo e podem economizar uma quantidade significativa de tempo em comparação com a criação e assinatura das suas próprias solicitações. Os endpoints da API de configuração usam o formato a seguir:

    es.region.amazonaws.com/2021-01-01/

    Por exemplo, a seguinte solicitação faz uma alteração de configuração no domínio movies, mas é necessário que você a assine (não recomendado):

    POST https://es.us-east-1.amazonaws.com/2021-01-01/opensearch/domain/movies/config { "ClusterConfig": { "InstanceType": "c5.xlarge.search" } }

    Se você usar um dos SDKs, como Boto 3, o SDK gerencia automaticamente a assinatura de solicitações:

    import boto3 client = boto3.client(es) response = client.update_domain_config( DomainName='movies', ClusterConfig={ 'InstanceType': 'c5.xlarge.search' } )

    Para obter um código de exemplo Java, consulte Uso de AWS SDKs para interagir com o Amazon OpenSearch Service.

  • Para fazer chamadas para as APIs do OpemSearch, você precisará assinar suas próprias solicitações. Para obter um código de exemplo em uma variedade de linguagens, consulte Assinatura de solicitações HTTP no Amazon OpenSearch Service. As APIs do OpenSearch usam o seguinte formato:

    domain-id.region.es.amazonaws.com

    Por exemplo, a seguinte solicitação procura o índice movies para thor:

    GET https://my-domain.us-east-1.es.amazonaws.com/movies/_search?q=thor
nota

O serviço ignora parâmetros passados em URLs para solicitações HTTP POST assinadas com o Signature versão 4.

Quando há colisão de políticas

Quando as políticas discordam entre si ou não fazem nenhuma referência explícita a um usuário, surgem complexidades. Como o IAM funciona no Manual do usuário do IAM fornece um breve resumo da lógica de avaliação de políticas:

  • Por padrão, todas as solicitações são negadas.

  • Uma permissão explícita substitui esse padrão.

  • Uma negação explícita substitui todas as permissões.

Por exemplo, se uma política baseada em recursos concede acesso a um sub-recurso de domínio (um índice ou API do OpenSearch), mas uma política baseada em identidade nega o acesso, esse acesso é negado. Se uma política baseada em identidade concede acesso e uma política baseada em recursos não especifica se você deve ou não ter acesso, esse acesso é concedido. Consulte a tabela a seguir com o cruzamento de políticas para obter um resumo completo dos resultados para sub-recursos de domínios.

Permitido na política baseada em recursos Negado na política baseada em recursos Nem permitido nem negado na política baseada em recursos
Allowed in identity-based policy

Permitir

Deny Allow
Denied in identity-based policy Deny Deny Deny
Neither allowed nor denied in identity-based policy Allow Deny Deny

Referência de elementos da política

O OpenSearch Service oferece suporte à maioria dos elementos de políticas em Referência de elementos de políticas do IAM, com exceção de NotPrincipal. A tabela a seguir mostra os elementos mais comuns.

Elemento da política de JSON Resumo
Version

Versão atual da linguagem de política é 2012-10-17. Todas as políticas de acesso devem especificar esse valor.

Effect

Esse elemento especifica se a declaração permite ou nega o acesso às ações especificadas. Os valores válidos são Allow ou Deny.

Principal

Esse elemento especifica a Conta da AWS ou o usuário ou a função do IAM que tem ou não permissão para acessar um recurso e pode apresentar várias formas:

  • Contas da AWS: "Principal":{"AWS": ["123456789012"]} ou "Principal":{"AWS": ["arn:aws:iam::123456789012:root"]}

  • Usuários do IAM: "Principal":{"AWS": ["arn:aws:iam::123456789012:user/test-user"]}

  • Funções do IAM: "Principal":{"AWS": ["arn:aws:iam::123456789012:role/test-role"]}

Especificar o curinga * permite o acesso anônimo ao domínio, o que não recomendamos, a menos que você adicione uma condição baseada em IP, use o suporte à VPC ou habilite o controle de acesso refinado.

Action

O OpenSearch Service usa as seguintes ações ESHttp* para os métodos OpenSearch HTTP. O resto das ações são para a API de configuração. Para ver a lista completa de ações, consulte Para obter informações de referência detalhadas, consulte Ações, recursos e chaves de condição do Amazon OpenSearch Service na Referência de autorização do serviço

Determinadas ações es: dão suporte a permissões no nível do recurso. Por exemplo, você pode conceder a um usuário permissões para excluir um determinado domínio sem conceder a esse usuário permissões para excluir qualquer domínio. Outras ações se aplicam apenas ao serviço em si. Por exemplo, es:ListDomainNames não faz sentido no contexto de um único domínio e, portanto, requer um curinga.

Importante

Políticas baseadas em recursos são diferentes das permissões no nível do recurso. As políticas baseadas em recursos são políticas JSON completas anexadas aos domínios. As permissões no nível do recurso tornam possível a restrição de ações em domínios específicos ou sub-recursos. Na prática, você pode pensar na permissão no nível do recurso como uma seção opcional de um recurso ou uma política baseada em identidade.

A seguinte política baseada em identidade lista todas as es: ações e as agrupa de acordo com sua aplicação, ou seja, se elas se aplicam aos sub-recursos do domínio (test-domain/*), à configuração do domínio (test-domain) ou apenas ao serviço (*):

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "es:ESHttpDelete", "es:ESHttpGet", "es:ESHttpHead", "es:ESHttpPost", "es:ESHttpPut", "es:ESHttpPatch" ], "Resource": "arn:aws:es:us-west-1:987654321098:domain/test-domain/*" }, { "Effect": "Allow", "Action": [ "es:AddTags", "es:AssociatePackage", "es:CreateDomain", "es:CreateOutboundConnection", "es:DeleteDomain", "es:DescribeDomain", "es:DescribeDomainAutoTunes", "es:DescribeDomainConfig", "es:DescribeDomains", "es:DissociatePackage", "es:ESCrossClusterGet", "es:GetCompatibleVersions", "es:GetUpgradeHistory", "es:GetUpgradeStatus", "es:ListPackagesForDomain", "es:ListTags", "es:RemoveTags", "es:StartServiceSoftwareUpdate", "es:UpdateDomainConfig", "es:UpdateNotificationStatus", "es:UpgradeDomain" ], "Resource": "arn:aws:es:us-west-1:987654321098:domain/test-domain" }, { "Effect": "Allow", "Action": [ "es:AcceptInboundConnection", "es:CancelServiceSoftwareUpdate", "es:CreatePackage", "es:CreateServiceRole", "es:DeletePackage", "es:DescribeInboundConnections", "es:DescribeInstanceTypeLimits", "es:DescribeOutboundConnections", "es:DescribePackages", "es:DescribeReservedInstanceOfferings", "es:DescribeReservedInstances", "es:GetPackageVersionHistory", "es:ListDomainNames", "es:ListDomainsForPackage", "es:ListInstanceTypeDetails", "es:ListInstanceTypes", "es:ListNotifications", "es:ListVersions", "es:PurchaseReservedInstanceOffering", "es:RejectInboundConnection", "es:UpdatePackage" ], "Resource": "*" } ] }
nota

Embora as permissões no nível de recurso para es:CreateDomain possam parecer não intuitivas — afinal de contas, por que conceder permissões a um usuário para criar um domínio que já existe? —, o uso de um curinga permite aplicar um esquema de nomenclatura simples aos seus domínios, como "Resource": "arn:aws:es:us-west-1:987654321098:domain/my-team-name-*".

Naturalmente, nada impede que você inclua ações juntamente com elementos de recursos menos restritivos, como estes:

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "es:ESHttpGet", "es:DescribeDomain" ], "Resource": "*" } ] }

Para saber mais sobre o emparelhamento de ações e recursos, consulte o elemento Resource nesta tabela.

Condition

O OpenSearch Service é compatível com a maioria das condições descritas em Chaves de contexto de condições globais da AWS no Manual do usuário do IAM. Exceções notáveis incluem as chaves aws:SecureTransport e aws:PrincipalTag, às quais o OpenSearch Service não oferece suporte.

Ao configurar uma política baseada em IP, você especifica os endereços IP ou bloco CIDR como uma condição, como esta:

"Condition": { "IpAddress": { "aws:SourceIp": [ "192.0.2.0/32" ] } }

Conforme observado em Políticas baseadas em identidade, as chaves de condição aws:ResourceTag, aws:RequestTag e aws:TagKeys se aplicam tanto à API de configuração como às APIs do OpenSearch.

Resource

O OpenSearch Service usa elementos Resource de três maneiras básicas:

  • Para ações que se aplicam ao OpenSearch Service em si, como es:ListDomainNames, ou que permitem acesso total, use a seguinte sintaxe:

    "Resource": "*"
  • Para as ações que envolvem uma configuração de domínio, como es:DescribeDomain, você pode usar a seguinte sintaxe:

    "Resource": "arn:aws:es:region:aws-account-id:domain/domain-name"
  • Para as ações que se aplicam a um sub-recurso de domínio, como es:ESHttpGet, você pode usar a seguinte sintaxe:

    "Resource": "arn:aws:es:region:aws-account-id:domain/domain-name/*"

    Não é necessário usar um curinga. O OpenSearch Service permite que você defina uma política de acesso diferente para cada índice do ou API do OpenSearch. Por exemplo, você pode limitar as permissões de um usuário para o índice test-index:

    "Resource": "arn:aws:es:region:aws-account-id:domain/domain-name/test-index"

    Em vez de acesso total ao test-index, você pode preferir limitar a política somente à API de pesquisa:

    "Resource": "arn:aws:es:region:aws-account-id:domain/domain-name/test-index/_search"

    Você pode até mesmo controlar o acesso a documentos individuais:

    "Resource": "arn:aws:es:region:aws-account-id:domain/domain-name/test-index/test-type/1"

    Essencialmente, se o OpenSearch expressar o sub-recurso como um URI, você poderá controlar o acesso a ele usando uma política de acesso. Para ter ainda mais controle sobre quais recursos um usuário pode acessar, consulte Controle de acesso refinado no Amazon OpenSearch Service.

Para obter detalhes sobre quais ações dão suporte a permissões no nível do recurso, consulte o elemento Action nesta tabela.

Opções avançadas e considerações sobre a API

O OpenSearch Service tem várias opções avançadas, uma das quais tem implicações para o controle de acesso: rest.action.multi.allow_explicit_index. Como sua configuração padrão é verdadeiro, ela permite que os usuários ignorem as permissões de sub-recursos em determinadas circunstâncias.

Por exemplo, considere a seguinte política baseada em recurso:

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": [ "arn:aws:iam::123456789012:user/test-user" ] }, "Action": [ "es:ESHttp*" ], "Resource": [ "arn:aws:es:us-west-1:987654321098:domain/test-domain/test-index/*", "arn:aws:es:us-west-1:987654321098:domain/test-domain/_bulk" ] }, { "Effect": "Allow", "Principal": { "AWS": [ "arn:aws:iam::123456789012:user/test-user" ] }, "Action": [ "es:ESHttpGet" ], "Resource": "arn:aws:es:us-west-1:987654321098:domain/test-domain/restricted-index/*" } ] }

Essa política concede ao test-user acesso total ao test-index e à API em massa do OpenSearch. Ela também permite solicitações GET ao restricted-index.

A seguinte solicitação de indexação, como você pode esperar, falha devido a um erro de permissão:

PUT https://search-test-domain.us-west-1.es.amazonaws.com/restricted-index/movie/1 { "title": "Your Name", "director": "Makoto Shinkai", "year": "2016" }

Ao contrário da API de índice, a API em massa permite criar, atualizar e excluir vários documentos em uma única chamada. Contudo, normalmente você especifica essas operações no corpo da solicitação, em vez de na URL da solicitação. Como o OpenSearch Service usa URLs para controlar o acesso a sub-recursos do domínio, o test-user pode, na verdade, usar a API em massa para fazer alterações no restricted-index. Embora o usuário não tenha permissões POST no índice, a seguinte solicitação é bem-sucedida:

POST https://search-test-domain.us-west-1.es.amazonaws.com/_bulk { "index" : { "_index": "restricted-index", "_type" : "movie", "_id" : "1" } } { "title": "Your Name", "director": "Makoto Shinkai", "year": "2016" }

Nesta situação, a política de acesso não consegue cumprir o que pretendia. Para evitar que os usuários ignorem esses tipos de restrições, você pode alterar o rest.action.multi.allow_explicit_index para o valor falso. Se esse valor for falso, todas as chamadas para as APIs em massa, mget e msearch, que especificam nomes de índice no corpo da solicitação irão parar de funcionar. Em outras palavras, as chamadas para _bulk não funcionam mais, mas as chamadas para o test-index/_bulk funcionam. Este segundo endpoint contém um nome de índice, portanto, você não precisa especificar um no corpo da solicitação.

O Open Search Dashboards depende muito de mget e do msearch e, portanto, provavelmente não funcionará corretamente após essa alteração. Para correção parcial, você pode deixar o rest.action.multi.allow_explicit_index como verdadeiro e negar o acesso a determinados usuários para uma ou mais dessas APIs.

Para obter informações sobre como alterar essa configuração, consulte Configurações avançadas do cluster.

Da mesma forma, a seguinte política baseada em recursos contém dois problemas sutis:

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::123456789012:user/test-user" }, "Action": "es:ESHttp*", "Resource": "arn:aws:es:us-west-1:987654321098:domain/test-domain/*" }, { "Effect": "Deny", "Principal": { "AWS": "arn:aws:iam::123456789012:user/test-user" }, "Action": "es:ESHttp*", "Resource": "arn:aws:es:us-west-1:987654321098:domain/test-domain/restricted-index/*" } ] }
  • Apesar da negação explícita, o test-user ainda pode fazer chamadas, como GET https://search-test-domain.us-west-1.es.amazonaws.com/_all/_search e GET https://search-test-domain.us-west-1.es.amazonaws.com/*/_search para acessar os documentos no restricted-index.

  • Como o elemento Resource faz referência ao restricted-index/*, o test-user não tem permissões para acessar diretamente os documentos do índice. O usuário, no entanto, tem permissões para excluir todo o índice. Para evitar o acesso e a exclusão, a política deve especificar restricted-index*.

Em vez de misturar permissões amplas e negações focadas, a abordagem mais segura é seguir o princípio do privilégio mínimo e conceder apenas as permissões necessárias para executar uma tarefa. Para obter mais informações sobre como controlar o acesso a índices ou operações individuais do OpenSearch, consulte Controle de acesso refinado no Amazon OpenSearch Service.

Configuração de políticas de acesso

  • Para obter instruções sobre a criação ou modificação de políticas baseadas em recursos e políticas baseadas em IP no OpenSearch Service, consulte Configuração de políticas de acesso.

  • Para obter instruções sobre como criar ou modificar políticas baseadas em identidade no IAM, consulte Criação de políticas do IAM no Manual do usuário do IAM.

Exemplos adicionais de políticas

Embora este capítulo inclua muitos exemplos de políticas, o controle de acesso da AWS é um tema complexo que pode ser entendido melhor por meio de exemplos. Para obter mais informações, consulte Exemplo de políticas baseadas em identidade do IAM noManual do usuário do IAM.