Identity and Access Management dans Amazon OpenSearch Service

Amazon OpenSearch Service propose plusieurs méthodes pour contrôler l'accès à vos domaines. Cette rubrique présente différents types de stratégies, explique leurs interactions et indique comment créer vos propres stratégies personnalisées.

Important

VPCle support introduit des considérations supplémentaires concernant le contrôle d'accès aux OpenSearch services. Pour de plus amples informations, veuillez consulter À propos des stratégies d'accès pour les domaines de VPC.

Types de stratégies

OpenSearch Le service prend en charge trois types de politiques d'accès :

• Stratégies basées sur les ressources

• Politiques basées sur l’identité

• Stratégies basées sur l'IP

Stratégies basées sur les ressources

Vous ajoutez une stratégie basée sur les ressources, souvent appelée stratégie d'accès au domaine, lorsque vous créez un domaine. Ces politiques spécifient quelles actions un principal peut effectuer sur les sous-ressources du domaine (à l'exception de la recherche entre clusters). Les sous-ressources incluent les OpenSearch index et. APIs L'élément Principal spécifie les comptes, les utilisateurs ou les rôles qui sont autorisés à y accéder. L'élément Resource définit les sous-ressources qui sont accessibles à ces mandataires.

Par exemple, la politique suivante basée sur les ressources accorde à test-user l'accès total (es:*) aux sous-ressources de 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/*"
    }
  ]
}

Deux considérations importantes s'appliquent à cette stratégie :

• Ces privilèges s'appliquent uniquement à ce domaine. Sauf si vous créez des stratégies similaires sur d'autres domaines,test-user peut uniquement accéder à test-domain.

• La barre oblique /* de l'élément Resource indique que les stratégies basées sur les ressources s'appliquent uniquement aux sous-ressources du domaine, et non au domaine lui-même. Dans les stratégies basées sur les ressources, l'action es:* équivaut à es:ESHttp*.

  Par exemple, test-user peut envoyer des demandes concernant un index (GET https://search-test-domain.us-west-1.es.amazonaws.com/test-index), mais ne peut pas mettre à jour la configuration du domaine (POST https://es.us-west-1.amazonaws.com/2021-01-01/opensearch/domain/test-domain/config). Notez la différence entre les deux points de terminaison. L'accès à la configuration API nécessite une politique basée sur l'identité.

Vous pouvez spécifier un nom d'index partiel en ajoutant un caractère générique. Cet exemple identifie tous les index commençant par commerce :

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

Dans ce cas, le caractère générique signifie que test-user peut envoyer des requêtes aux index de test-domain dont le nom commence par commerce.

Pour restreindre davantage test-user, vous pouvez appliquer la stratégie suivante :

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

À présent, test-user ne peut effectuer qu'une seule opération : rechercher sur l'index commerce-data. Tous les autres index au sein du domaine sont inaccessibles et, sans autorisation d'utiliser les actions es:ESHttpPut ou es:ESHttpPost, test-user ne peut pas ajouter ou modifier des documents.

Ensuite, vous pouvez décider de configurer un rôle pour les utilisateurs avancés. Cette politique donne power-user-role accès aux PUT méthodes HTTP GET et pour tous les utilisateurs URIs de l'index :

{
  "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/*"
    }
  ]
}

Si votre domaine se trouve dans un VPC ou utilise un contrôle d'accès détaillé, vous pouvez utiliser une politique d'accès aux domaines ouverts. Sinon, votre stratégie d'accès au domaine doit contenir certaines restrictions, soit par le principal, soit par l'adresse IP.

Pour plus d'informations sur les différentes actions disponibles, consultez Références des éléments de stratégie. Pour un contrôle nettement plus précis de vos données, utilisez une stratégie d'accès ouverte au domaine avec contrôle précis des accès.

Politiques basées sur l’identité

Contrairement aux politiques basées sur les ressources, qui font partie de chaque domaine de OpenSearch service, vous associez des politiques basées sur l'identité aux utilisateurs ou aux rôles utilisant le AWS Identity and Access Management service (). IAM Tout comme les stratégies basées sur une ressource, celles basées sur une identité déterminent qui est autorisé à accéder à un service, quelles actions peuvent être exécutées et, le cas échéant, les ressources concernées.

Bien que ce ne soit certainement pas nécessaire, les stratégies basées sur une identité ont tendance à être plus génériques. Ils régissent souvent uniquement les API actions de configuration qu'un utilisateur peut effectuer. Une fois ces politiques en place, vous pouvez utiliser des politiques basées sur les ressources (ou un contrôle d'accès précis) dans OpenSearch Service pour permettre aux utilisateurs d'accéder aux index et. OpenSearch APIs

Note

Les utilisateurs dotés de la AmazonOpenSearchServiceReadOnlyAccess politique AWS gérée ne peuvent pas voir l'état de santé du cluster sur la console. Pour leur permettre de consulter l'état de santé du cluster (et d'autres OpenSearch données), ajoutez l'es:ESHttpGetaction à une politique d'accès et associez-la à leurs comptes ou rôles.

Les politiques basées sur l'identité étant associées à des utilisateurs ou à des rôles (principaux), elles JSON ne spécifient aucun principal. La stratégie suivante accorde l'accès à des actions commençant par Describe et List. Cette combinaison d'actions fournit un accès en lecture seule aux configurations de domaine, mais pas aux données stockées dans le domaine lui-même :

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

Un administrateur peut avoir un accès complet au OpenSearch service et à toutes les données stockées sur tous les domaines :

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

Les politiques basées sur l'identité vous permettent d'utiliser des balises pour contrôler l'accès à la configuration. API La stratégie suivante, par exemple, permet aux principaux attachés d'afficher et de mettre à jour la configuration d'un domaine si ce domaine dispose de la balise team:devops :

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

Vous pouvez également utiliser des balises pour contrôler l'accès au OpenSearch API. Les politiques basées sur des balises s'appliquent OpenSearch API uniquement aux HTTP méthodes. Par exemple, la politique suivante permet aux principaux rattachés d'envoyer GET des PUT demandes OpenSearch API si le domaine possède le environment:production tag :

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

Pour un contrôle plus précis de la OpenSearch API, pensez à utiliser un contrôle d'accès précis.

Note

Après avoir ajouté une ou plusieurs balises OpenSearch APIs à une politique basée sur des balises, vous devez effectuer une seule opération de balise (telle que l'ajout, la suppression ou la modification d'une balise) pour que les modifications prennent effet sur un domaine. Vous devez utiliser le logiciel de service R20211203 ou version ultérieure pour inclure les OpenSearch API opérations dans les politiques basées sur des balises.

OpenSearch Le service prend en charge les clés de condition TagKeys globales RequestTag et les clés de condition pour la configurationAPI, et non le OpenSearch API. Ces conditions s'appliquent uniquement aux API appels qui incluent des balises dans la demande, telles que CreateDomainAddTags, etRemoveTags. La stratégie suivante permet aux principaux attachés de créer des domaines, mais uniquement s'ils disposent de la balise team:it dans la requête :

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

Pour plus de détails sur l'utilisation des balises pour le contrôle d'accès et sur les différences entre les politiques basées sur les ressources et les politiques basées sur l'identité, consultez le guide de l'utilisateur. IAM

Stratégies basées sur l'IP

Les politiques basées sur l'IP limitent l'accès à un domaine à une ou plusieurs adresses IP ou CIDR blocs. Techniquement, les stratégies basées sur l'adresse IP ne sont pas un type de stratégie distincte. Elles sont simplement des stratégies basées sur une ressource qui spécifient un principal anonyme et incluent un élément Condition spécial.

Le principal avantage des politiques basées sur l'IP est qu'elles autorisent les requêtes non signées adressées à un domaine de OpenSearch service, ce qui vous permet d'utiliser des clients tels que curl et OpenSearch Dashboards ou d'accéder au domaine via un serveur proxy. Pour en savoir plus, consultez Utilisation d'un proxy pour accéder au OpenSearch service à partir de OpenSearch tableaux de bord.

Note

Si vous avez activé VPC l'accès à votre domaine, vous ne pouvez pas configurer de politique basée sur l'adresse IP. Vous devez plutôt utiliser des groupes de sécurité pour contrôler les adresses IP qui peuvent accéder au domaine. Pour de plus amples informations, veuillez consulter À propos des stratégies d'accès pour les domaines de VPC.

La politique suivante accorde à toutes les HTTP demandes provenant de la plage d'adresses IP spécifiée l'accès à 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/*"
    }
  ]
}

Si votre domaine possède un point de terminaison public et n'utilise pas de contrôle d'accès précis, nous vous recommandons de combiner IAM les principaux et les adresses IP. Cette politique n'accorde test-user HTTP l'accès que si la demande provient de la plage d'adresses IP spécifiée :

{
  "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/*"
  }]
}

Formulation et signature de demandes OpenSearch de service

Même si vous configurez une politique d'accès entièrement ouverte basée sur les ressources, toutes les demandes adressées à la configuration du OpenSearch service API doivent être signées. Si vos politiques spécifient IAM des rôles ou des utilisateurs, les demandes adressées doivent OpenSearch APIs également être signées à l'aide de AWS Signature Version 4. La méthode de signature diffère en ce qui concerne API :

• Pour appeler la configuration du OpenSearch serviceAPI, nous vous recommandons d'utiliser l'un des AWS SDKs. Cela simplifie SDKs considérablement le processus et peut vous faire gagner beaucoup de temps par rapport à la création et à la signature de vos propres demandes. Les API points de terminaison de configuration utilisent le format suivant :

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

  Par exemple, la demande suivante apporte une modification de configuration au domaine movies, mais vous devez la signer vous-même (non recommandé) :

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

  Si vous utilisez l'un d'entre euxSDKs, comme Boto 3, il gère SDK automatiquement la signature de la demande :

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

  Pour obtenir un exemple de code Java, consultez À l'aide duAWSSDK pour interagir avec AmazonOpenSearchService.

• Pour passer des appels au OpenSearch APIs, vous devez signer vos propres demandes. OpenSearch APIsUtilisez le format suivant :

  domain-id.region.es.amazonaws.com

  Par exemple, la demande suivante recherche l'index movies pour thor :

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

Note

Le service ignore les paramètres transmis URLs pour les HTTP POST demandes signées avec Signature Version 4.

En cas de conflit entre plusieurs stratégies

Si les stratégies sont en désaccord ou ne mentionnent explicitement un utilisateur, cela crée des situations complexes. Comprendre comment IAM fonctionne le guide de l'IAMutilisateur fournit un résumé concis de la logique d'évaluation des politiques :

• Par défaut, toutes les demandes sont refusées.

• Une autorisation explicite remplace ce fonctionnement par défaut.

• Un refus explicite remplace toute autorisation.

Par exemple, si une politique basée sur les ressources vous accorde l'accès à une sous-ressource de domaine (un OpenSearch index ouAPI), mais qu'une politique basée sur l'identité vous en refuse l'accès, l'accès vous est refusé. Si une stratégie basée sur une identité accorde l'accès et celle basée sur une ressource ne spécifie rien concernant votre accès, vous êtes autorisé à accéder. Pour un récapitulatif complet des issues possibles en matière de sous-ressources de domaine, consultez le tableau suivant des recoupements entre stratégies.

	Autorisé dans la stratégie basée sur une ressource	Refusé dans la stratégie basée sur une ressource	Ni autorisé ni refusé dans la stratégie basée sur une ressource
Allowed in identity-based policy	Autorisation	Refuser	Autorisation
Denied in identity-based policy	Refuser	Refuser	Refuser
Neither allowed nor denied in identity-based policy	Autorisation	Refuser	Refuser

Références des éléments de stratégie

OpenSearch Le service prend en charge la plupart des éléments de IAMpolitique figurant dans la référence des éléments de politique, à l'exception deNotPrincipal. Le tableau suivant indique les éléments les plus courants.

JSONélément de politique	Récapitulatif
Version	La version actuelle du langage de la stratégie est 2012-10-17. Toutes les stratégies d'accès doivent spécifier cette valeur.
Effect	Cet élément spécifie si la déclaration autorise ou refuse l'accès aux actions spécifiées. Les valeurs valides sont Allow ou Deny.
Principal	Cet élément indique le IAM rôle Compte AWS ou l'utilisateur autorisé ou refusé à une ressource et peut prendre plusieurs formes : AWS comptes : "Principal":{"AWS": ["123456789012"]} ou "Principal":{"AWS": ["arn:aws:iam::123456789012:root"]} IAMutilisateurs : "Principal":{"AWS": ["arn:aws:iam::123456789012:user/test-user"]} IAMrôles : "Principal":{"AWS": ["arn:aws:iam::123456789012:role/test-role"]} Important La spécification du * caractère générique permet un accès anonyme au domaine, ce que nous ne recommandons pas, sauf si vous ajoutez une condition basée sur l'adresse IP, utilisez le VPCsupport ou activez un contrôle d'accès précis. En outre, examinez attentivement les politiques suivantes pour vous assurer qu'elles n'accordent pas un accès étendu : Politiques basées sur l'identité associées aux AWS principaux associés (par exemple, les rôles) IAM Politiques basées sur les AWS ressources associées (par exemple, AWS Key Management Service KMS clés)
Action	OpenSearch Le service utilise ESHttp* des actions comme OpenSearch HTTP méthodes. Le reste des actions s'applique à la configurationAPI. Certaines actions es: acceptent des autorisations au niveau des ressources. Par exemple, vous pouvez accorder à un utilisateur l'autorisation de supprimer un domaine particulier sans l'autoriser à supprimer n'importe quel domaine. D'autres actions s'appliquent uniquement au service lui-même. Par exemple, es:ListDomainNames n'a aucun sens dans le contexte d'un domaine unique et, par conséquent, nécessite un caractère générique. Pour obtenir la liste de toutes les actions disponibles et savoir si elles s'appliquent aux sous-ressources du domaine (test-domain/*), à la configuration du domaine (test-domain) ou uniquement au service (*), consultez la section Actions, ressources et clés de condition pour Amazon OpenSearch Service dans le Service Authorization Reference Les politiques basées sur les ressources diffèrent des autorisations de niveau ressource. Les politiques basées sur les ressources sont des JSON politiques complètes associées aux domaines. Les autorisations au niveau des ressources vous permettent de limiter les actions à des domaines ou sous-ressources spécifiques. En pratique, vous pouvez envisager les autorisations au niveau des ressources comme une partie facultative d'une stratégie basée sur une ressource ou une identité. Bien que les autorisations au niveau des ressources pour es:CreateDomain peuvent sembler peu intuitives (pourquoi accorder à un utilisateur l'autorisation de créer un domaine qui existe déjà ?), l'utilisation d'un caractère générique vous permet d'appliquer une méthode simple de dénomination pour vos domaines telle que "Resource": "arn:aws:es:us-west-1:987654321098:domain/my-team-name-*". Bien entendu, rien ne vous empêche d'inclure des actions aux côtés d'éléments de ressources moins restrictifs, comme dans l'exemple suivant : { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "es:ESHttpGet", "es:DescribeDomain" ], "Resource": "*" } ] } Pour en savoir plus sur l'appairage d'actions et de ressources, référez-vous à l'élément Resource dans ce tableau.
Condition	OpenSearch Le service prend en charge la plupart des conditions décrites dans les clés contextuelles des conditions AWS globales du Guide de IAM l'utilisateur. Les exceptions notables incluent la aws:PrincipalTag clé, que le OpenSearch Service ne prend pas en charge. Lorsque vous configurez une politique basée sur l'adresse IP, vous spécifiez les adresses IP ou le CIDR blocage comme condition, par exemple : "Condition": { "IpAddress": { "aws:SourceIp": [ "192.0.2.0/32" ] } } Comme indiqué dansPolitiques basées sur l’identité, les touches aws:ResourceTagaws:RequestTag, et de aws:TagKeys condition s'appliquent à la configuration API ainsi qu'à OpenSearch APIs.
Resource	OpenSearch Le service utilise Resource les éléments de trois manières fondamentales : Pour les actions qui s'appliquent au OpenSearch Service lui-mêmees:ListDomainNames, comme ou pour autoriser un accès complet, utilisez la syntaxe suivante : "Resource": "*" Pour les actions qui impliquent la configuration d'un domaine, comme es:DescribeDomain, vous pouvez utiliser la syntaxe suivante : "Resource": "arn:aws:es:region:aws-account-id:domain/domain-name" Pour les actions concernant les sous-ressources d'un domaine, comme es:ESHttpGet, vous pouvez utiliser la syntaxe suivante : "Resource": "arn:aws:es:region:aws-account-id:domain/domain-name/*" Vous n'êtes pas obligé d'utiliser un joker. OpenSearch Le service vous permet de définir une politique d'accès différente pour chaque OpenSearch index ouAPI. Par exemple, vous pouvez limiter les autorisations d'un utilisateur à l'index test-index : "Resource": "arn:aws:es:region:aws-account-id:domain/domain-name/test-index" Au lieu d'un accès complet àtest-index, vous préférerez peut-être limiter la politique à la seule recherche API : "Resource": "arn:aws:es:region:aws-account-id:domain/domain-name/test-index/_search" Vous pouvez même contrôler l'accès à chaque document : "Resource": "arn:aws:es:region:aws-account-id:domain/domain-name/test-index/test-type/1" Essentiellement, s'il OpenSearch exprime la sous-ressource sous la forme d'unURI, vous pouvez contrôler l'accès à celle-ci à l'aide d'une politique d'accès. Pour plus de contrôle sur les ressources auxquelles un utilisateur peut accéder, veuillez consulter Contrôle d'accès précis dans Amazon Service OpenSearch . Pour plus d'informations sur les actions prenant en charge les autorisations au niveau des ressources, référez-vous à l'élément Action dans ce tableau.

Options avancées et API considérations

OpenSearch Le service comporte plusieurs options avancées, dont l'une a des implications en matière de contrôle d'accès :rest.action.multi.allow_explicit_index. Avec sa configuration par défaut sur true (vrai), elle permet aux utilisateurs de contourner les autorisations au niveau des sous-ressources dans certaines circonstances.

Prenons l'exemple suivant de stratégie basée sur une ressource :

{
  "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/*"
    }
  ]
}

Cette politique accorde un accès test-user complet test-index et OpenSearch globalAPI. Elle autorise également les demandes GET sur restricted-index.

L'exemple suivant de demande d'indexation échoue, comme vous pouviez vous y attendre, en raison d'une erreur d'autorisation :

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

Contrairement à l'indexAPI, le bloc vous API permet de créer, de mettre à jour et de supprimer de nombreux documents en un seul appel. Cependant, vous spécifiez souvent ces opérations dans le corps de la demande plutôt que dans la demandeURL. Étant donné que le OpenSearch service contrôle l'accès aux sous-ressources du domaine, il test-user peut en fait utiliser la masse API pour apporter restricted-index des modifications. URLs Même si l'utilisateur n'a pas les autorisations POST pour l'index, la demande suivante aboutit :

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

Dans ce cas, la stratégie d'accès ne parvient pas à remplir sa fonction. Pour empêcher les utilisateurs de passer outre ce type de restrictions, vous pouvez remplacer la valeur de rest.action.multi.allow_explicit_index par false (faux). Si cette valeur est fausse, tous les appels aux commandes bulk, mget et msearch APIs qui spécifient les noms d'index dans le corps de la requête cessent de fonctionner. En d'autres termes, les appels _bulk ne fonctionnent plus, mais les appels test-index/_bulk, oui. Ce deuxième point de terminaison contient un nom d'index, de sorte que vous n'avez pas besoin d'en spécifier un dans le corps de la demande.

OpenSearch Les tableaux de bord reposent largement sur mget et msearch, il est donc peu probable qu'ils fonctionnent correctement après cette modification. Pour une correction partielle, vous pouvez laisser rest.action.multi.allow_explicit_index la valeur true et refuser à certains utilisateurs l'accès à une ou plusieurs d'entre ellesAPIs.

Pour plus d'informations sur la modification de ce paramètre, consultez Paramètres avancés du cluster.

De même, la stratégie basée sur une ressource ci-après engendre deux problèmes subtils :

{
  "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/*"
    }
  ]
}

• Malgré le refus explicite, test-user peut continuer à effectuer des appels tels que GET https://search-test-domain.us-west-1.es.amazonaws.com/_all/_search et GET https://search-test-domain.us-west-1.es.amazonaws.com/*/_search pour accéder aux documents dans restricted-index.

• L'élément Resource référence restricted-index/*, si bien que test-user n'est pas autorisé à accéder directement aux documents de l'index. Toutefois, l'utilisateur a les autorisations requises pour supprimer l'ensemble de l'index. Pour empêcher l'accès et la suppression, la stratégie doit spécifier restricted-index*.

Plutôt que de combiner de vastes autorisations avec des refus ciblés, l'approche la plus sûre consiste à appliquer le principe du moindre privilège et à accorder uniquement les autorisations qui sont requises pour exécuter une tâche. Pour plus d'informations sur le contrôle de l'accès à des index ou à des OpenSearch opérations individuels, consultezContrôle d'accès précis dans Amazon Service OpenSearch .

Important

La spécification du caractère générique * permet un accès anonyme à votre domaine. Il n'est pas recommandé d'utiliser le caractère générique. En outre, examinez attentivement les politiques suivantes pour vous assurer qu'elles n'accordent pas un accès étendu :

• Politiques basées sur l'identité associées aux AWS principaux associés (par exemple, les rôles) IAM

• Politiques basées sur les AWS ressources associées (par exemple, AWS Key Management Service KMS clés)

Configuration des politiques d'accès

• Pour obtenir des instructions sur la création ou la modification de politiques basées sur les ressources et les adresses IP dans OpenSearch Service, consultezConfiguration des politiques d'accès.

• Pour obtenir des instructions sur la création ou la modification de politiques basées sur l'identité dansIAM, voir Création de IAM politiques dans le Guide de l'IAMutilisateur.

Exemples de stratégies supplémentaires

Bien que ce chapitre contienne de nombreux exemples de politiques, le contrôle d' AWS accès est un sujet complexe qu'il est préférable de comprendre à l'aide d'exemples. Pour en savoir plus, consultez la section Exemples de politiques IAM basées sur l'identité dans le Guide de l'IAMutilisateur.