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**
La prise en charge du VPC introduit des considérations supplémentaires en matière de contrôle d'accès aux OpenSearch services. Pour plus d’informations, consultez [À 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 :
+ [Resource-based politiques](#ac-types-resource)
+ [Identity-based politiques](#ac-types-identity)
+ [IP-based politiques](#ac-types-ip)
### Resource-based politiques
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 les API. 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 auxquels l'accès est autorisé. 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 stratégie accorde à `power-user-role` l'accès aux méthodes HTTP GET et PUT pour tous les URI dans 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).
### Identity-based politiques
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 aux OpenSearch API.
**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": "*"
}
]
}
```
------
Identity-based les politiques 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. Tag-basedles politiques de 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 OpenSearch API à 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.*
### IP-based politiques
IP-based les politiques limitent l'accès à un domaine à une ou plusieurs adresses IP ou blocs CIDR. Techniquement, les IP-based politiques ne constituent pas un type de politique distinct. 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 IP-based politiques 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, consultez [Utilisation d'un proxy pour accéder au OpenSearch service à partir de tableaux de bord](dashboards.md#dashboards-proxy).
**Note**
Si vous avez activé l'accès VPC pour votre domaine, vous ne pouvez pas configurer de politique. IP-based 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*
Si vous utilisez une politique d'accès ouvert sur un domaine VPC sans spécifier de AWS principal, le domaine accepte les requêtes HTTP non signées provenant de tout trafic autorisé par le groupe de sécurité. Pour plus d'informations, consultez [À propos des politiques d'accès sur les domaines VPC.](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/vpc.html#vpc-security)
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 :+ **AWS comptes** : `"Principal":{"AWS": ["123456789012"]}` ou `"Principal":{"AWS": ["arn:aws:iam::123456789012:root"]}`
+ **Utilisateurs IAM** : `"Principal":{"AWS": ["arn:aws:iam::123456789012:user/test-user"]}`
+ **Rôles IAM** : `"Principal":{"AWS": ["arn:aws:iam::123456789012:role/test-role"]}` 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 [IP-based condition](#ac-types-ip), utilisez le support [VPC](vpc.md) ou [activez un contrôle d'accès précis](fgac.md). En outre, examinez attentivement les politiques suivantes pour vous assurer qu'elles n'accordent pas un accès étendu : Identity-based politiques associées aux AWS principaux associés (par exemple, rôles IAM) Resource-based politiques 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*Resource-basedles politiques diffèrent des autorisations au niveau des ressources. [Resource-based les politiques](#ac-types-resource) sont des politiques JSON complètes associées à des domaines. Resource-level les autorisations 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 [IP-basedpolitique](#ac-types-ip), vous spécifiez les adresses IP ou le bloc CIDR comme condition, par exemple :"Condition": {
"IpAddress": {
"aws:SourceIp": [
"192.0.2.0/32"
]
}
}
Comme indiqué dans[Identity-based politiques](#ac-types-identity), les clés `aws:ResourceTag``aws:RequestTag`, et de `aws:TagKeys` condition s'appliquent à l'API de configuration ainsi qu'aux OpenSearch API.
Amazon OpenSearch Service prend également en charge la clé de condition `aws:SecureTransport` globale dans les politiques d'accès basées sur les ressources. Vous pouvez l'utiliser `aws:SecureTransport` pour exiger que les demandes adressées à votre domaine soient effectuées via HTTPS. Par exemple :"Condition": { "Bool": { "aws:SecureTransport": "true" } }
Pour plus d'informations sur les clés de condition, consultez la section [clés contextuelles de condition AWS globales](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) dans le *guide de l'utilisateur IAM*. |
| 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ême`es: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 ou API. 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 total à `test-index`, vous préférerez peut-être limiter la stratégie à l'API de recherche : "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 forme d'URI, 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 [Fine-grained contrôle d'accès dans Amazon OpenSearch Service](fgac.md).
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 service utilise des URL pour contrôler 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 la valeur est false (faux), tous les appels aux API bulk, mget et msearch qui spécifient les noms d'index dans le corps de la demande 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 s'appuient largement sur les API bulk, mget et msearch. Par conséquent, le fait de définir cette option pour `false` l'annuler. Attendez-vous à ce qui suit :
+ Les tableaux de bord ne peuvent pas lire leurs propres objets enregistrés, car ils les récupèrent avec mget et msearch. Les modèles d'index, les recherches enregistrées, les visualisations et les tableaux de bord apparaissent tous vides ou ne se chargent pas, même lorsque Dashboards lui-même indique qu'ils sont sains.
+ Les tableaux de bord peuvent ne pas démarrer du tout. Les tableaux de bord stockent leur propre état (modèles d'index, visualisations et tableaux de bord) dans l' OpenSearch index des tableaux de bord. Chaque fois que le format de l'objet enregistré change (par exemple, après une mise à niveau de la version du moteur), Dashboards migre cet état vers un nouvel index au démarrage. La migration écrit des documents avec l'API en bloc et nomme l'index dans le corps de la requête. Elle échoue donc tant que cette option est activée`false`. Les tableaux de bord ne s'en remettent pas tout seuls et fournissent des rapports `OpenSearch Dashboards server is not ready yet` plutôt qu'un message indiquant le nom de cette option. Pour plus d’informations, consultez [Les tableaux de bord sont bloqués sur « le serveur n'est pas encore prêt » (erreur HTTP 503 non prêt)](dashboards-troubleshooting.md#dashboards-troubleshooting-not-ready).
+ La mise à niveau de la version du moteur risque de ne pas être terminée. Chaque mise à niveau vérifie que les tableaux de bord sont sains avant d'être terminée, et un tableau de bord qui ne peut pas démarrer bloque cette vérification. Vous ne pouvez pas non plus modifier les options avancées pendant qu'une mise à niveau est en cours. Par conséquent, si vous avez l'intention de rétablir cette option`true`, faites-le **avant** de commencer une mise à niveau. Si une mise à niveau est déjà bloquée, contactez le [AWS Support](https://aws.amazon.com/premiumsupport/).
Les tableaux de bord ne sont pas pris en charge sur les domaines où cette option est définie sur. `false` Les deux fonctionnalités s'excluent mutuellement, et le seul moyen de restaurer les tableaux de bord `true` est de rétablir l'option sur. Si vous devez restreindre l'accès aux sous-ressources de cette façon, prévoyez de ne pas utiliser les tableaux de bord sur ce domaine. Pour une correction partielle qui permet aux tableaux de bord de continuer à fonctionner, vous pouvez laisser `rest.action.multi.allow_explicit_index` la valeur true et refuser à certains utilisateurs l'accès à une ou plusieurs de ces API.
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[Fine-grained contrôle d'accès dans Amazon OpenSearch Service](fgac.md).
**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 :
Identity-based politiques associées aux AWS principaux associés (par exemple, rôles IAM)
Resource-based politiques 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 des ressources et IP-based des politiques 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*.