Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra. # 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** Le support VPC introduit des considérations supplémentaires en matière de 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](vpc.md#vpc-security). ## Types de stratégies OpenSearch Le service prend en charge trois types de politiques d'accès : + [Stratégies basées sur les ressources](#ac-types-resource) + [Politiques basées sur l’identité](#ac-types-identity) + [Stratégies basées sur l'IP](#ac-types-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](cross-cluster-search.md#cross-cluster-search-walkthrough)). Les sous-ressources incluent les OpenSearch index et. APIs L'élément de politique JSON [principal](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html) dans IAM spécifie les comptes, les utilisateurs ou les rôles autorisés à accéder. L'élément de politique [Resource](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_resource.html) JSON indique à quelles sous-ressources ces principaux peuvent accéder. Par exemple, la politique suivante basée sur les ressources accorde à `test-user` l'accès total (`es:*`) aux sous-ressources de `test-domain` : ------ #### [ JSON ] **** ``` { "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 à l'API de configuration nécessite une politique [basée sur l'identité](#ac-types-identity). 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 : ------ #### [ JSON ] **** ``` { "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 méthodes HTTP GET et PUT pour tous les éléments URIs de l'index : ------ #### [ JSON ] **** ``` { "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 précis des accès, vous pouvez utiliser une stratégie d'accès ouverte au domaine. 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](#ac-reference). 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](fgac.md). ### 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 à l'aide du service Gestion des identités et des accès AWS (IAM). Tout comme les [stratégies basées sur une ressource](#ac-types-resource), 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. Bien souvent, elles ne régissent que les actions de l'API 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](fgac.md) 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:ESHttpGet`action à une politique d'accès et associez-la à leurs comptes ou rôles. Étant donné que les stratégies basées sur l'identité sont attachées à des utilisateurs ou des rôles (principaux), le JSON ne spécifie pas de 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 : ------ #### [ JSON ] **** ``` { "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 : ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Action": [ "es:*" ], "Effect": "Allow", "Resource": "*" } ] } ``` ------ Les stratégies basées sur l'identité vous permettent d'utiliser des balises pour contrôler l'accès à l'API de configuration. 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` : ------ #### [ JSON ] **** ``` { "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 à l' OpenSearch API. Les politiques basées sur des balises pour l' OpenSearch API ne s'appliquent qu'aux méthodes HTTP. Par exemple, la politique suivante permet aux entités associées d'envoyer des requêtes GET et PUT à l' OpenSearch API si le domaine possède la `environment:production` balise : ------ #### [ JSON ] **** ``` { "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 l' OpenSearch API, pensez à utiliser un contrôle d'[accès précis.](fgac.md) **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](managedomains-awsresourcetagging.md) (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 opérations d' OpenSearch API 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 l'API de configuration, et non pour l' OpenSearch API. Ces conditions s'appliquent uniquement aux appels d'API incluant des balises dans la demande, comme `CreateDomain`, `AddTags` et `RemoveTags`. 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 : ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": { "Effect": "Allow", "Action": [ "es:CreateDomain", "es:AddTags" ], "Resource": "*", "Condition": { "StringEquals": { "aws:RequestTag/team": [ "it" ] } } } } ``` ------ *Pour plus d'informations sur l'utilisation de 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 la section [Définir les autorisations en fonction des attributs avec autorisation ABAC](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) dans le guide de l'utilisateur IAM.* ### Stratégies basées sur l'IP Les stratégies basées sur l'IP limitent l'accès à un domaine à une ou plusieurs adresses IP ou à des blocs CIDR spécifiques. Techniquement, les stratégies basées sur l'adresse IP ne sont pas un type de stratégie distincte. Il s'agit plutôt de politiques basées sur les ressources qui spécifient un principal anonyme et incluent une condition spéciale. Pour plus d'informations, voir [Éléments de politique IAM JSON : Condition](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) dans le guide de l'*utilisateur IAM*. 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](https://curl.haxx.se/) et [OpenSearch Dashboards](dashboards.md) ou d'accéder au domaine via un serveur proxy. Pour en savoir plus, veuillez consulter la section [Utilisation d'un proxy pour accéder au OpenSearch service à partir de tableaux de bord](dashboards.md#dashboards-proxy). **Note** Si vous avez activé un accès VPC pour votre domaine, vous ne pouvez pas configurer une stratégie basée sur l'IP. Vous pouvez plutôt l'utiliser `security groups` pour contrôler les adresses IP autorisées à accéder au domaine. Pour plus d’informations, consultez les rubriques suivantes : [À propos des stratégies d'accès pour les domaines de VPC](vpc.md#vpc-security) [Contrôlez le trafic vers vos AWS ressources à l'aide des groupes de sécurité](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-groups.html) décrits dans le guide de l'*utilisateur Amazon VPC* La stratégie suivante permet à toutes les demandes en provenance de la plage d'adresses IP spécifiée d'accéder à   `test-domain`: ------ #### [ JSON ] **** ``` { "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 dispose d'un point de terminaison public et n'utilise pas le [contrôle d'accès affiné](fgac.md), nous vous recommandons de combiner les entités IAM et les adresses IP. Cette stratégie n'accorde à `test-user` l'accès HTTP que si la demande provient de la plage IP spécifiée : ------ #### [ JSON ] **** ``` { "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/*" }] } ``` ------ ## 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. [Comment fonctionne l'IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/intro-structure.html) dans le *guide de l'utilisateur de l'IAM* 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 ou une API), 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** | Allow | Refuser | Allow | | --- |--- |--- |--- | | **Denied in identity-based policy** | Refuser | Refuser | Refuser | | --- |--- |--- |--- | | **Neither allowed nor denied in identity-based policy** | Allow | Refuser | Refuser | | --- |--- |--- |--- | ## Références des éléments de stratégie OpenSearch Le service prend en charge la plupart des éléments de [politique de la référence des éléments de stratégie IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/AccessPolicyLanguage_ElementDescriptions.html), à l'exception de`NotPrincipal`. Le tableau suivant indique les éléments les plus courants. **** | Élément de stratégie JSON | Résumé | | --- | --- | | 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 rôle Compte AWS ou l'utilisateur IAM autorisé ou refusé à une ressource et peut prendre plusieurs formes : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/opensearch-service/latest/developerguide/ac.html) L'indication du caractère générique `*` permet l'accès anonyme au domaine, ce que nous ne recommandons pas, sauf si vous ajoutez une [condition basée sur IP](#ac-types-ip), si vous utilisez [la prise en charge du VPC](vpc.md) ou si vous activez un [contrôle d'accès affiné](fgac.md). 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 principaux AWS correspondants (par exemple, rôles IAM) Politiques basées sur les ressources associées aux AWS ressources associées (par exemple, clés AWS Key Management Service KMS) | | Action | OpenSearch Le service utilise `ESHttp*` des actions pour les méthodes OpenSearch HTTP. Les autres actions s'appliquent à l'API de configuration.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](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonopensearchservice.html) *Authorization Reference*Les politiques basées sur les ressources diffèrent des autorisations de niveau ressource. Les [stratégies basées sur une ressource](#ac-types-resource) sont des stratégies JSON complètes attachées à des 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 : JSON **** ``` { "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](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#AvailableKeys) du *guide de l'utilisateur IAM*. Les exceptions notables incluent la `aws:PrincipalTag` clé, que le OpenSearch Service ne prend pas en charge. Lorsque vous configurez une [stratégie basée sur l'IP](#ac-types-ip), vous spécifiez les adresses IP ou blocs d'adresse CIDR en tant que condition comme suit : 
"Condition": {
  "IpAddress": {
    "aws:SourceIp": [
      "192.0.2.0/32"
    ]
  }
}
Comme indiqué dans[Politiques basées sur l’identité](#ac-types-identity), les clés `aws:ResourceTag``aws:RequestTag`, et de `aws:TagKeys` condition s'appliquent à l'API de configuration ainsi qu'à OpenSearch APIs. | | Resource | OpenSearch Le service utilise `Resource` les éléments de trois manières fondamentales : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/opensearch-service/latest/developerguide/ac.html) 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 considérations relatives aux API 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 : ------ #### [ JSON ] **** ``` { "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 `test-user` un accès complet à l'API OpenSearch en bloc `test-index` et à celle-ci. 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'API index, l'API bulk vous permet de créer, mettre à jour et supprimer un grand nombre de documents en un seul appel. Toutefois, ces opérations sont généralement définies dans le corps de la demande, plutôt que dans l'URL de la demande. Étant donné que le OpenSearch URLs service contrôle l'accès aux sous-ressources du domaine, il `test-user` peut en fait utiliser l'API en bloc pour apporter des modifications à`restricted-index`. 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](dashboards.md) 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 elles APIs. Pour plus d'informations sur la modification de ce paramètre, consultez [Paramètres avancés du cluster](createupdatedomains.md#createdomain-configure-advanced-options). De même, la stratégie basée sur une ressource ci-après engendre deux problèmes subtils : ------ #### [ JSON ] **** ``` { "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](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege) 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, consultez[Contrôle d'accès précis dans Amazon Service OpenSearch](fgac.md). **Important** La spécification du caractère générique \$1 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 ressources associées aux AWS ressources associées (par exemple, clés AWS Key Management Service KMS) ## 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, consultez[Configuration des politiques d'accès](createupdatedomains.md#createdomain-configure-access-policies). + *Pour obtenir des instructions sur la création ou la modification de politiques basées sur l'identité dans IAM, voir [Définir des autorisations IAM personnalisées avec des politiques gérées par le client](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) dans le guide de l'utilisateur IAM.* ## 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 plus d'informations, consultez [Exemples de politiques basées sur l'identité IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_examples.html) dans le *Guide de l'utilisateur IAM*.