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.
# Sécurité dans Amazon OpenSearch Service
La sécurité du cloud AWS est la priorité absolue. En tant que AWS client, vous bénéficiez d'un centre de données et d'une architecture réseau conçus pour répondre aux exigences des entreprises les plus sensibles en matière de sécurité.
La sécurité est une responsabilité partagée entre vous AWS et vous. Le [modèle de responsabilité partagée](https://aws.amazon.com/compliance/shared-responsibility-model/) décrit cette notion par les termes sécurité *du* cloud et sécurité *dans* le cloud :
+ **Sécurité du cloud** : AWS est chargée de protéger l'infrastructure qui exécute les AWS services dans le AWS cloud. AWS vous fournit également des services que vous pouvez utiliser en toute sécurité. Des auditeurs tiers testent et vérifient régulièrement l’efficacité de notre sécurité dans le cadre des [programmes de conformitéAWS](https://aws.amazon.com/compliance/programs/). Pour en savoir plus sur les programmes de conformité qui s'appliquent à Amazon OpenSearch Service, consultez la section [AWS Services concernés par programme de conformité](https://aws.amazon.com/compliance/services-in-scope/).
+ **Sécurité dans le cloud** — Votre responsabilité est déterminée par le AWS service que vous utilisez. Vous êtes également responsable d’autres facteurs, y compris de la sensibilité de vos données, des exigences de votre entreprise, ainsi que de la législation et de la réglementation applicables.
Cette documentation vous aide à comprendre comment appliquer le modèle de responsabilité partagée lors de l'utilisation OpenSearch du Service. Les rubriques suivantes expliquent comment configurer le OpenSearch service pour répondre à vos objectifs de sécurité et de conformité. Vous apprendrez également à utiliser d'autres AWS services qui vous aident à surveiller et à sécuriser les ressources OpenSearch de vos services.
**Topics**
+ [Protection des données dans Amazon OpenSearch Service](data-protection.md)
+ [Identity and Access Management dans Amazon OpenSearch Service](ac.md)
+ [Prévention du problème de l’adjoint confus entre services](cross-service-confused-deputy-prevention.md)
+ [Contrôle d'accès précis dans Amazon Service OpenSearch](fgac.md)
+ [Validation de conformité pour Amazon OpenSearch Service](compliance-validation.md)
+ [Résilience dans Amazon OpenSearch Service](disaster-recovery-resiliency.md)
+ [Authentification et autorisation JWT pour Amazon Service OpenSearch](JSON-Web-tokens.md)
+ [Sécurité de l'infrastructure dans Amazon OpenSearch Service](infrastructure-security.md)
+ [Authentification SAML pour les tableaux de bord OpenSearch](saml.md)
+ [Support de propagation d'identité fiable d'IAM Identity Center pour OpenSearch](idc-aos.md)
+ [Configuration de l'authentification Amazon Cognito pour les tableaux de bord OpenSearch](cognito-auth.md)
+ [Utilisation de rôles liés à un service pour Amazon Service OpenSearch](slr.md)
# Protection des données dans Amazon OpenSearch Service
Le [modèle de responsabilité AWS partagée](https://aws.amazon.com/compliance/shared-responsibility-model/) de s'applique à la protection des données dans Amazon OpenSearch Service. Comme décrit dans ce modèle, AWS est chargé de protéger l'infrastructure mondiale qui gère tous les AWS Cloud. La gestion du contrôle de votre contenu hébergé sur cette infrastructure relève de votre responsabilité. Vous êtes également responsable des tâches de configuration et de gestion de la sécurité des Services AWS que vous utilisez. Pour plus d’informations sur la confidentialité des données, consultez [Questions fréquentes (FAQ) sur la confidentialité des données](https://aws.amazon.com/compliance/data-privacy-faq/). Pour en savoir plus sur la protection des données en Europe, consultez le billet de blog [Modèle de responsabilité partagée d’AWS et RGPD (Règlement général sur la protection des données)](https://aws.amazon.com/blogs/security/the-aws-shared-responsibility-model-and-gdpr/) sur le *Blog de sécuritéAWS *.
À des fins de protection des données, nous vous recommandons de protéger les Compte AWS informations d'identification et de configurer les utilisateurs individuels avec AWS IAM Identity Center ou Gestion des identités et des accès AWS (IAM). Ainsi, chaque utilisateur se voit attribuer uniquement les autorisations nécessaires pour exécuter ses tâches. Nous vous recommandons également de sécuriser vos données comme indiqué ci-dessous :
+ Utilisez l’authentification multifactorielle (MFA) avec chaque compte.
+ SSL/TLS À utiliser pour communiquer avec AWS les ressources. Nous exigeons TLS 1.2 et recommandons TLS 1.3.
+ Configurez l'API et la journalisation de l'activité des utilisateurs avec AWS CloudTrail. Pour plus d'informations sur l'utilisation des CloudTrail sentiers pour capturer AWS des activités, consultez la section [Utilisation des CloudTrail sentiers](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-trails.html) dans le *guide de AWS CloudTrail l'utilisateur*.
+ Utilisez des solutions de AWS chiffrement, ainsi que tous les contrôles de sécurité par défaut qu'ils contiennent Services AWS.
+ Utilisez des services de sécurité gérés avancés tels qu’Amazon Macie, qui contribuent à la découverte et à la sécurisation des données sensibles stockées dans Amazon S3.
+ Si vous avez besoin de modules cryptographiques validés par la norme FIPS 140-3 pour accéder AWS via une interface de ligne de commande ou une API, utilisez un point de terminaison FIPS. Pour plus d’informations sur les points de terminaison FIPS disponibles, consultez [Norme FIPS (Federal Information Processing Standard) 140-3](https://aws.amazon.com/compliance/fips/).
Nous vous recommandons fortement de ne jamais placer d’informations confidentielles ou sensibles, telles que les adresses e-mail de vos clients, dans des balises ou des champs de texte libre tels que le champ **Nom**. Cela inclut lorsque vous travaillez avec le OpenSearch Service ou un autre Services AWS à l'aide de la console AWS CLI, de l'API ou AWS SDKs. Toutes les données que vous entrez dans des balises ou des champs de texte de forme libre utilisés pour les noms peuvent être utilisées à des fins de facturation ou dans les journaux de diagnostic. Si vous fournissez une adresse URL à un serveur externe, nous vous recommandons fortement de ne pas inclure d’informations d’identification dans l’adresse URL permettant de valider votre demande adressée à ce serveur.
# Chiffrement des données au repos pour Amazon OpenSearch Service
OpenSearch Les domaines de service offrent le chiffrement des données au repos, une fonctionnalité de sécurité qui permet d'empêcher tout accès non autorisé à vos données. La fonctionnalité utilise AWS Key Management Service (AWS KMS) pour stocker et gérer vos clés de chiffrement et l'algorithme Advanced Encryption Standard avec des clés de 256 bits (AES-256) pour effectuer le chiffrement. Si cette option est activée, elle chiffre les aspects suivants d'un domaine :
+ Tous les index (y compris ceux UltraWarm stockés)
+ OpenSearch journaux
+ Échangez les fichiers
+ Toutes les autres données dans le répertoire de l'application
+ Instantanés automatiques
Les services suivants *ne sont pas* chiffrées lorsque vous activez le chiffrement des données au repos, mais vous pouvez prendre des mesures supplémentaires afin de les protéger :
+ Instantanés manuels : vous ne pouvez actuellement pas utiliser de AWS KMS clés pour chiffrer les instantanés manuels. Toutefois, vous pouvez utiliser le chiffrement côté serveur avec des clés gérées par S3 ou des clés KMS pour chiffrer le compartiment que vous utilisez comme référentiel d'instantanés. Pour obtenir des instructions, veuillez consulter [Inscription d'un référentiel d'instantanés manuels](managedomains-snapshot-registerdirectory.md).
+ Journaux lents et journaux d'erreurs : si vous [publiez des journaux](createdomain-configure-slow-logs.md) et que vous souhaitez les chiffrer, vous pouvez chiffrer leur groupe de CloudWatch journaux à l'aide de la même AWS KMS clé que le domaine de OpenSearch service. Pour plus d'informations, consultez la section [Chiffrer les données des CloudWatch journaux dans les journaux à l'aide AWS Key Management Service](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/encrypt-log-data-kms.html) du *guide de l'utilisateur Amazon CloudWatch Logs*.
**Note**
Vous ne pouvez pas activer le chiffrement au repos sur un domaine existant si UltraWarm le stockage à froid est activé sur le domaine. Vous devez d'abord UltraWarm désactiver le stockage à froid, activer le chiffrement au repos, puis réactiver UltraWarm le stockage à froid. Si vous souhaitez conserver les index dans UltraWarm un stockage à froid, vous devez les déplacer vers un stockage à chaud avant de les désactiver UltraWarm ou de les stocker dans un stockage à froid.
OpenSearch Le service prend uniquement en charge les clés KMS de chiffrement symétriques, et non les clés asymétriques. Pour savoir comment créer des clés symétriques, consultez la section [Création d'une clé KMS](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html) dans le *guide du AWS Key Management Service développeur*.
Que le chiffrement au repos soit activé ou non, tous les domaines chiffrent automatiquement les [packages personnalisés](custom-packages.md) à l'aide de clés AES-256 et OpenSearch de clés gérées par le service.
## Permissions
Pour utiliser la console de OpenSearch service afin de configurer le chiffrement des données au repos, vous devez disposer d'autorisations de lecture AWS KMS, telles que la politique basée sur l'identité suivante :
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"kms:List*",
"kms:Describe*"
],
"Resource": "*"
}
]
}
```
------
Si vous souhaitez utiliser une clé autre que celle que vous AWS possédez, vous devez également être autorisé à créer des [autorisations](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html) pour la clé. Ces autorisations se présentent généralement sous la forme d'une politique basée sur les ressources que vous indiquez lorsque vous créez la clé.
Si vous souhaitez conserver votre clé exclusive au OpenSearch Service, vous pouvez ajouter la ViaService condition [kms :](https://docs.aws.amazon.com/kms/latest/developerguide/conditions-kms.html#conditions-kms-via-service) à cette politique clé :
```
"Condition": {
"StringEquals": {
"kms:ViaService": "es.us-west-1.amazonaws.com"
},
"Bool": {
"kms:GrantIsForAWSResource": "true"
}
}
```
Pour plus d’informations, consultez [Politiques de clé dans AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html) dans le *Guide du développeur AWS Key Management Service *.
## Activation du chiffrement de données au repos
Le chiffrement des données inactives sur les nouveaux domaines nécessite soit Elasticsearch 5.1, OpenSearch soit une version ultérieure. Son activation sur des domaines existants nécessite Elasticsearch 6.7 ou version ultérieure. OpenSearch
**Pour activer le chiffrement des données au repos (console)**
1. Ouvrez le domaine dans la AWS console, puis choisissez **Actions** et **Modifier la configuration de sécurité**.
1. Dans **Encryption (Chiffrement)**, sélectionnez **Enable encryption of data at rest (Activer le chiffrement des données au repos)**.
1. Choisissez la AWS KMS clé à utiliser, puis sélectionnez **Enregistrer les modifications**.
Vous pouvez également activer le chiffrement via l'API de configuration. La requête suivante permet le chiffrement des données au repos sur un domaine existant :
```
{
"ClusterConfig":{
"EncryptionAtRestOptions":{
"Enabled": true,
"KmsKeyId":"arn:aws:kms:us-east-1:123456789012:alias/my-key"
}
}
}
```
## Clé KMS désactivée ou supprimée
Si vous désactivez ou supprimez la clé que vous avez utilisée pour chiffrer un domaine, celui-ci devient inaccessible. OpenSearch Le service vous envoie une [notification](managedomains-notifications.md) vous informant qu'il ne peut pas accéder à la clé KMS. Réactivez immédiatement la clé pour accéder à votre domaine.
L'équipe du OpenSearch service ne peut pas vous aider à récupérer vos données si votre clé est supprimée. AWS KMS supprime les clés uniquement après une période d'attente d'au moins sept jours. Si votre clé est en attente de suppression, annulez la suppression ou effectuez un [instantané manuel](managedomains-snapshots.md) du domaine pour éviter toute perte de données.
## Désactivation du chiffrement de données au repos
Une fois que vous avez configuré un domaine pour chiffrer les données au repos, vous ne pouvez pas désactiver le paramètre. Au lieu de cela, vous pouvez prendre un [instantané manuel](managedomains-snapshots.md) du domaine existant, [créer un autre domaine](createupdatedomains.md#createdomains), migrer vos données et supprimer l'ancien domaine.
## Surveillance des domaines qui chiffrent les données au repos
Les domaines qui chiffrent des données au repos ont deux métriques supplémentaires : `KMSKeyError` et `KMSKeyInaccessible`. Ces métriques s'affichent uniquement si le domaine rencontre un problème avec votre clé de chiffrement. Pour une liste complète de ces métriques, consultez [Métriques du cluster](managedomains-cloudwatchmetrics.md#managedomains-cloudwatchmetrics-cluster-metrics). Vous pouvez les consulter à l'aide de la console OpenSearch Service ou de la CloudWatch console Amazon.
**Astuce**
Chaque métrique représente un problème important pour un domaine. Nous vous recommandons donc de créer des CloudWatch alarmes pour les deux. Pour de plus amples informations, veuillez consulter [CloudWatch Alarmes recommandées pour Amazon OpenSearch Service](cloudwatch-alarms.md).
## Autres considérations
+ La rotation automatique des touches préserve les propriétés de vos AWS KMS clés, de sorte que la rotation n'a aucun effet sur votre capacité à accéder à vos OpenSearch données. Les domaines OpenSearch de service chiffrés ne prennent pas en charge la rotation manuelle des clés, qui implique la création d'une nouvelle clé et la mise à jour des références à l'ancienne clé. Pour en savoir plus, consultez la section [Rotation AWS KMS des touches](https://docs.aws.amazon.com/kms/latest/developerguide/rotate-keys.html) dans le *guide du AWS Key Management Service développeur*.
+ Certains types d'instance ne prennent pas en charge le chiffrement des données au repos. Pour plus d'informations, consultez [Types d'instances pris en charge dans Amazon OpenSearch Service](supported-instance-types.md).
+ Les domaines qui chiffrent les données au repos utilisent un nom de référentiel différent pour leurs instantanés automatiques. Pour plus d'informations, consultez [Restauration des instantanés](managedomains-snapshot-restore.md).
+ Bien que nous vous recommandions d'activer le chiffrement au repos, celui-ci peut entraîner des charges supplémentaires de processeur et quelques millisecondes de latence. La plupart des cas d'utilisation ne sont toutefois pas sensibles à ces différences, cependant l'ampleur de l'impact dépend de la configuration du cluster, des clients et du profil d'utilisation.
# Node-to-node chiffrement pour Amazon OpenSearch Service
Node-to-node le chiffrement fournit un niveau de sécurité supplémentaire en plus des fonctionnalités par défaut d'Amazon OpenSearch Service.
Chaque domaine OpenSearch de service, qu'il utilise ou non un accès VPC, réside dans son propre VPC dédié. Cette architecture empêche les attaquants potentiels d'intercepter le trafic entre les OpenSearch nœuds et assure la sécurité du cluster. Par défaut, toutefois, le trafic au sein du VPC n'est pas chiffré. Node-to-nodele chiffrement permet le chiffrement TLS 1.2 pour toutes les communications au sein du VPC.
Si vous envoyez des données au OpenSearch Service via HTTPS, le node-to-node chiffrement permet de garantir que vos données restent cryptées lorsqu' OpenSearch elles sont distribuées (et redistribuées) dans le cluster. Si les données arrivent non chiffrées via HTTP, le OpenSearch service les chiffre une fois qu'elles ont atteint le cluster. Vous pouvez exiger que tout le trafic vers le domaine arrive via HTTPS à l'aide de la console ou de l'API de configuration. AWS CLI
Node-to-node le chiffrement est *nécessaire* si vous activez le [contrôle d'accès détaillé](fgac.md).
## Activation du node-to-node chiffrement
Node-to-node le chiffrement des nouveaux domaines nécessite n'importe quelle version d' OpenSearchElasticsearch 6.0 ou version ultérieure. L'activation du node-to-node chiffrement sur les domaines existants nécessite n'importe quelle version d' OpenSearchElasticsearch 6.7 ou version ultérieure. Choisissez le domaine existant dans la console AWS , **Actions**, et **Edit security configuration (Modifier la configuration de la sécurité)**.
Vous pouvez également utiliser l'API de configuration AWS CLI or. Pour plus d'informations, consultez la référence des [AWS CLI commandes et la référence OpenSearch ](https://docs.aws.amazon.com/cli/latest/reference/) [de l'API de service](https://docs.aws.amazon.com/opensearch-service/latest/APIReference/API_Welcome.html).
## Désactivation du chiffrement node-to-node
Une fois que vous avez configuré un domaine pour utiliser node-to-node le chiffrement, vous ne pouvez pas désactiver ce paramètre. Au lieu de cela, vous pouvez prendre un [instantané manuel](managedomains-snapshots.md) du domaine chiffré, [créer un autre domaine](createupdatedomains.md#createdomains), migrer vos données et supprimer l'ancien domaine.
# 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/*"
}]
}
```
------
# 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 à l'API de configuration du OpenSearch service doivent être signées. Si vos politiques spécifient des rôles ou des utilisateurs IAM, les demandes adressées doivent OpenSearch APIs également être signées à l'aide de AWS Signature Version 4. La méthode de signature varie en fonction de l'API :
+ Pour appeler l'API de configuration du OpenSearch service, nous vous recommandons d'utiliser l'un des [AWS SDKs](https://docs.aws.amazon.com/sdkref/latest/guide/overview.html). 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 points de terminaison de l'API 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 eux SDKs, comme [Boto 3](https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/opensearch.html#OpenSearchService.Client.update_domain_config), le SDK gère automatiquement la signature des demandes :
```
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 [Utilisation du AWS SDKs pour interagir avec Amazon OpenSearch Service](configuration-samples.md).
+ Pour passer des appels au OpenSearch APIs, vous devez signer vos propres demandes. OpenSearch APIs Utilisez 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 requêtes HTTP POST 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. [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*.
# Référence des autorisations OpenSearch de l'API Amazon Service
Lorsque vous configurez le [contrôle d'accès](ac.md), vous rédigez des politiques d'autorisation que vous pouvez associer à une identité IAM (politiques basées sur l'identité). Pour des informations de référence détaillées, consultez les rubriques suivantes dans la *Référence de l’autorisation de service* :
+ [Actions, ressources et clés de condition pour le OpenSearch service](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonopensearchservice.html).
+ [Actions, ressources et clés de condition pour OpenSearch l'ingestion](https://docs.aws.amazon.com/service-authorization/latest/reference/list_opensearchingestionservice.html).
Cette référence contient des informations sur les opérations d'API qui peuvent être utilisées dans une politique IAM. Il inclut également la AWS ressource pour laquelle vous pouvez accorder les autorisations, ainsi que les clés de condition que vous pouvez inclure pour un contrôle d'accès précis.
Vous spécifiez les actions dans le champ `Action` de la politique, la valeur de ressource dans le champ `Resource` de la politique, et les conditions dans le champ `Condition` de la politique. Pour spécifier une action pour OpenSearch Service, utilisez le `es:` préfixe suivi du nom de l'opération d'API (par exemple,`es:CreateDomain`). Pour spécifier une action pour OpenSearch Ingestion, utilisez le `osis:` préfixe suivi de l'opération d'API (par exemple,`osis:CreatePipeline`).
# AWS politiques gérées pour Amazon OpenSearch Service
Une politique AWS gérée est une politique autonome créée et administrée par AWS. AWS les politiques gérées sont conçues pour fournir des autorisations pour de nombreux cas d'utilisation courants afin que vous puissiez commencer à attribuer des autorisations aux utilisateurs, aux groupes et aux rôles.
N'oubliez pas que les politiques AWS gérées peuvent ne pas accorder d'autorisations de moindre privilège pour vos cas d'utilisation spécifiques, car elles sont accessibles à tous les AWS clients. Nous vous recommandons de réduire encore les autorisations en définissant des [politiques gérées par le client](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies) qui sont propres à vos cas d’utilisation.
Vous ne pouvez pas modifier les autorisations définies dans les politiques AWS gérées. Si les autorisations définies dans une politique AWS gérée sont AWS mises à jour, la mise à jour affecte toutes les identités principales (utilisateurs, groupes et rôles) auxquelles la politique est attachée. AWS est le plus susceptible de mettre à jour une politique AWS gérée lorsqu'une nouvelle Service AWS est lancée ou lorsque de nouvelles opérations d'API sont disponibles pour les services existants.
Pour plus d’informations, consultez [Politiques gérées par AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) dans le *Guide de l’utilisateur IAM*.
## AmazonOpenSearchDirectQueryGlueCreateAccess
Accorde à Amazon OpenSearch Service Direct Query Service l'accès aux `CreateDatabase``CreatePartition`,`CreateTable`, et `BatchCreatePartition` AWS Glue API.
Vous pouvez trouver la [AmazonOpenSearchDirectQueryGlueCreateAccess](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AmazonOpenSearchDirectQueryGlueCreateAccess)politique dans la console IAM.
## AmazonOpenSearchServiceFullAccess
Accorde un accès complet aux opérations et aux ressources de l'API de configuration du OpenSearch service pour un Compte AWS.
Vous pouvez trouver la [AmazonOpenSearchServiceFullAccess](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AmazonOpenSearchServiceFullAccess)politique dans la console IAM.
## AmazonOpenSearchServiceReadOnlyAccess
Accorde un accès en lecture seule à toutes les ressources OpenSearch du service pour un. Compte AWS
Vous pouvez trouver la [AmazonOpenSearchServiceReadOnlyAccess](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AmazonOpenSearchServiceReadOnlyAccess)politique dans la console IAM.
## AmazonOpenSearchServiceRolePolicy
Vous ne pouvez pas joindre de `AmazonOpenSearchServiceRolePolicy` à vos entités IAM. Cette politique est associée à un rôle lié au service qui permet au OpenSearch service d'accéder aux ressources du compte. Pour de plus amples informations, veuillez consulter [Permissions](slr-aos.md#slr-permissions).
Vous pouvez trouver la [AmazonOpenSearchServiceRolePolicy](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AmazonOpenSearchServiceRolePolicy)politique dans la console IAM.
## AmazonOpenSearchServiceCognitoAccess
Fournit les autorisations minimales Amazon Cognito nécessaires pour activer l'[authentification Cognito](cognito-auth.md).
Vous pouvez trouver la [AmazonOpenSearchServiceCognitoAccess](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AmazonOpenSearchServiceCognitoAccess)politique dans la console IAM.
## AmazonOpenSearchIngestionServiceRolePolicy
Vous ne pouvez pas joindre de `AmazonOpenSearchIngestionServiceRolePolicy` à vos entités IAM. Cette politique est associée à un rôle lié à un service qui permet à OpenSearch Ingestion d'activer l'accès VPC pour les pipelines d'ingestion, de créer des balises et de publier des statistiques relatives à l'ingestion sur votre compte CloudWatch . Pour de plus amples informations, veuillez consulter [Utilisation de rôles liés à un service pour Amazon Service OpenSearch](slr.md).
Vous pouvez trouver la [AmazonOpenSearchIngestionServiceRolePolicy](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AmazonOpenSearchIngestionServiceRolePolicy)politique dans la console IAM.
## OpenSearchIngestionSelfManagedVpcePolicy
Vous ne pouvez pas joindre de `OpenSearchIngestionSelfManagedVpcePolicy` à vos entités IAM. Cette politique est associée à un rôle lié à un service qui permet à OpenSearch Ingestion d'activer un accès VPC autogéré pour les pipelines d'ingestion, de créer des balises et de publier des statistiques relatives à l' CloudWatch ingestion sur votre compte. Pour de plus amples informations, veuillez consulter [Utilisation de rôles liés à un service pour Amazon Service OpenSearch](slr.md).
Vous pouvez trouver la [OpenSearchIngestionSelfManagedVpcePolicy](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/OpenSearchIngestionSelfManagedVpcePolicy)politique dans la console IAM.
## AmazonOpenSearchIngestionFullAccess
Accorde un accès complet aux opérations et aux ressources de OpenSearch l'API d'ingestion pour un Compte AWS.
Vous pouvez trouver la [AmazonOpenSearchIngestionFullAccess](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AmazonOpenSearchIngestionFullAccess)politique dans la console IAM.
## AmazonOpenSearchIngestionReadOnlyAccess
Accorde un accès en lecture seule à toutes les ressources OpenSearch d'ingestion pour un. Compte AWS
Vous pouvez trouver la [AmazonOpenSearchIngestionReadOnlyAccess](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AmazonOpenSearchIngestionReadOnlyAccess)politique dans la console IAM.
## AmazonOpenSearchServerlessServiceRolePolicy
Fournit les Amazon CloudWatch autorisations minimales nécessaires pour envoyer des données métriques OpenSearch sans serveur à CloudWatch.
Vous pouvez trouver la [AmazonOpenSearchServerlessServiceRolePolicy](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AmazonOpenSearchServerlessServiceRolePolicy)politique dans la console IAM.
## OpenSearch Mises à jour des services relatifs aux politiques AWS gérées
Consultez les détails des mises à jour des politiques AWS gérées pour le OpenSearch service depuis que ce service a commencé à suivre les modifications.
| Modifier | Description | Date |
| --- | --- | --- |
| A mis à jour le `AmazonOpenSearchIngestionServiceRolePolicy` | La mise à jour donne OpenSearch à Ingestion l'autorisation de modifier les points de terminaison VPC créés par OpenSearch afin de partager des pipelines entre eux. VPCs Pour connaître le JSON de la politique, consultez [Console IAM](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AmazonOpenSearchIngestionServiceRolePolicy). | 28 août 2025 |
| A mis à jour le `AmazonOpenSearchServiceRolePolicy` | La déclaration suivante a été ajoutée à la politique. Lorsqu'Amazon OpenSearch Service assume le rôle `AWSServiceRoleForAmazonOpenSearchService` lié au service, cette nouvelle déclaration de la politique permet de mettre OpenSearch à jour l'étendue d'accès de toute AWS IAM Identity Center application uniquement gérée par. OpenSearch {
"Effect": "Allow",
"Action": "sso:PutApplicationAccessScope",
"Resource": "arn:aws:sso::*:application/*/*",
"Condition": {
"StringEquals": {
"aws:ResourceOrgID": "${aws:PrincipalOrgID}"
}
}
} | 31 mars 2025 |
| Mise à jour d'`AmazonOpenSearchServerlessServiceRolePolicy` | Le Sid a été ajouté `AllowAOSSCloudwatchMetrics` à la politique`AmazonOpenSearchServerlessServiceRolePolicy`. Un Sid est un identifiant de déclaration qui sert d'identifiant facultatif pour la déclaration de politique. | 12 juillet 2024 |
| Ajout de `OpenSearchIngestionSelfManagedVpcePolicy`. | Une nouvelle politique qui permet à OpenSearch Ingestion d'activer un accès VPC autogéré aux pipelines d'ingestion, de créer des balises et de publier des statistiques relatives à l' CloudWatch ingestion sur votre compte. Pour connaître le JSON de la politique, consultez [Console IAM](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AmazonOpenSearchIngestionServiceRolePolicy). | 12 juin 2024 |
| Ajouté `AmazonOpenSearchDirectQueryGlueCreateAccess` | Accorde à Amazon OpenSearch Service Direct Query Service l'accès aux `CreateDatabase``CreatePartition`,`CreateTable`, et `BatchCreatePartition` AWS Glue API. | 6 mai 2024 |
| Mises à jour : `AmazonOpenSearchServiceRolePolicy` et `AmazonElasticsearchServiceRolePolicy` | Ajout des autorisations nécessaires pour que [le rôle lié au service puisse](slr-aos.md#slr-permissions) attribuer et annuler IPv6 l'attribution d'adresses. La politique Elasticsearch obsolète a également été mise à jour pour assurer une compatibilité descendante. | 18 octobre 2023 |
| Ajout de `AmazonOpenSearchIngestionServiceRolePolicy`. | Une nouvelle politique qui permet à OpenSearch Ingestion d'autoriser l'accès VPC aux pipelines d'ingestion, de créer des balises et de publier des statistiques relatives à l'ingestion sur votre compte CloudWatch . Pour connaître le JSON de la politique, consultez [Console IAM](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AmazonOpenSearchIngestionServiceRolePolicy). | 26 avril 2023 |
| Ajout de `AmazonOpenSearchIngestionFullAccess`. | Une nouvelle politique qui accorde un accès complet aux opérations et aux ressources de OpenSearch l'API d'ingestion pour un Compte AWS. Pour connaître le JSON de la politique, consultez [Console IAM](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AmazonOpenSearchIngestionFullAccess). | 26 avril 2023 |
| Ajout de `AmazonOpenSearchIngestionReadOnlyAccess`. | Une nouvelle politique qui accorde un accès en lecture seule à toutes les ressources d' OpenSearch ingestion pour un. Compte AWS Pour connaître le JSON de la politique, consultez [Console IAM](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AmazonOpenSearchIngestionReadOnlyAccess). | 26 avril 2023 |
| Ajout de `AmazonOpenSearchServerlessServiceRolePolicy`. | Une nouvelle politique qui fournit les autorisations minimales nécessaires pour envoyer des données métriques OpenSearch sans serveur à Amazon CloudWatch. Pour connaître le JSON de la politique, consultez [Console IAM](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AmazonOpenSearchServerlessServiceRolePolicy). | 29 novembre 2022 |
| Mises à jour : `AmazonOpenSearchServiceRolePolicy` et `AmazonElasticsearchServiceRolePolicy` | Ajout des autorisations nécessaires au [rôle lié au service](slr-aos.md#slr-permissions) pour créer des points de terminaison VPC [OpenSearch gérés par](slr-aos.md#slr-permissions) le service. Certaines actions ne peuvent être effectuées que lorsque la requête contient la balise `OpenSearchManaged=true`. La politique Elasticsearch obsolète a également été mise à jour pour assurer une compatibilité descendante. | 7 novembre 2022 |
| Mises à jour : `AmazonOpenSearchServiceRolePolicy` et `AmazonElasticsearchServiceRolePolicy` | Ajout de la prise en charge de l'`PutMetricData`action, qui est nécessaire pour publier les métriques OpenSearch du cluster sur Amazon CloudWatch. La politique Elasticsearch obsolète a également été mise à jour pour assurer une compatibilité descendante. Pour connaître le JSON de la politique, consultez [Console IAM](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AmazonOpenSearchServiceRolePolicy). | 12 septembre 2022 |
| Mises à jour : `AmazonOpenSearchServiceRolePolicy` et `AmazonElasticsearchServiceRolePolicy` | Ajout de la prise en charge du type de ressource `acm`. [La politique fournit l'autorisation minimale AWS Certificate Manager (ACM) en lecture seule nécessaire au [rôle lié au service](slr-aos.md#slr-permissions) pour vérifier et valider les ressources ACM afin de créer et de mettre à jour des domaines personnalisés activés pour les points de terminaison.](customendpoint.md) La politique Elasticsearch obsolète a également été mise à jour pour assurer une compatibilité descendante. | 28 juillet 2022 |
| Mises à jour : `AmazonOpenSearchServiceCognitoAccess` et `AmazonESCognitoAccess` | Ajout de la prise en charge de l'`UpdateUserPoolClient`action, qui est nécessaire pour définir la configuration du groupe d'utilisateurs de Cognito lors de la mise à niveau d'Elasticsearch vers. OpenSearch Autorisations corrigées pour l'action `SetIdentityPoolRoles` pour permettre l'accès à toutes les ressources. La politique Elasticsearch obsolète a également été mise à jour pour assurer une compatibilité descendante. | 20 décembre 2021 |
| Mise à jour d'`AmazonOpenSearchServiceRolePolicy` | Ajout de la prise en charge du type de ressource `security-group`. La politique fournit les autorisations minimales Amazon EC2 et Elastic Load Balancing nécessaires au [rôle lié à un service](slr-aos.md#slr-permissions) pour activer l'[accès au VPC](cognito-auth.md). | 9 septembre 2021 |
| [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/opensearch-service/latest/developerguide/ac-managed.html) | Cette nouvelle politique a pour but de remplacer la précédente. Les deux politiques fournissent un accès complet à l'API OpenSearch de configuration du service et à toutes les méthodes HTTP pour le OpenSearch APIs. Le [contrôle précis des accès](fgac.md) et les [stratégies basées sur les ressources](ac.md#ac-types-resource) peuvent cependant restreindre l'accès. | 7 septembre 2021 |
| [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/opensearch-service/latest/developerguide/ac-managed.html) | Cette nouvelle politique a pour but de remplacer la précédente. Les deux politiques fournissent un accès en lecture seule à l'API de configuration du OpenSearch service (`es:Describe*``es:List*`,, et`es:Get*`) et *aucun* accès aux méthodes HTTP pour le. OpenSearch APIs | 7 septembre 2021 |
| [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/opensearch-service/latest/developerguide/ac-managed.html) | Cette nouvelle politique a pour but de remplacer la précédente. Les deux politiques fournissent les autorisations Amazon Cognito minimales nécessaires pour activer l'[authentification Cognito](cognito-auth.md). | 7 septembre 2021 |
| [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/opensearch-service/latest/developerguide/ac-managed.html) | Cette nouvelle politique a pour but de remplacer la précédente. Ces deux politiques fournissent les autorisations minimales Amazon EC2 et Elastic Load Balancing nécessaires au [rôle lié à un service](slr-aos.md#slr-permissions) pour activer l'[accès au VPC](cognito-auth.md). | 7 septembre 2021 |
| Démarrage du suivi des modifications | Amazon OpenSearch Service suit désormais les modifications apportées aux politiques AWS gérées. | 7 septembre 2021 |
# Prévention du problème de l’adjoint confus entre services
Le problème de député confus est un problème de sécurité dans lequel une entité qui n’est pas autorisée à effectuer une action peut contraindre une entité plus privilégiée à le faire. En AWS, l'usurpation d'identité interservices peut entraîner la confusion des adjoints. L’usurpation d’identité entre services peut se produire lorsqu’un service (le *service appelant*) appelle un autre service (le *service appelé*). Le service appelant peut être manipulé et ses autorisations utilisées pour agir sur les ressources d’un autre client auxquelles on ne serait pas autorisé à accéder autrement. Pour éviter cela, AWS fournit des outils qui vous aident à protéger vos données pour tous les services avec des principaux de service qui ont eu accès aux ressources de votre compte.
Nous recommandons d'utiliser les clés contextuelles de condition [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount)globale [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn)et les clés contextuelles dans les politiques de ressources afin de limiter les autorisations qu'Amazon OpenSearch Service accorde à un autre service à la ressource. Si la valeur `aws:SourceArn` ne contient pas l'ID du compte, tel qu'un ARN de compartiment Amazon S3, vous devez utiliser les deux clés de contexte de condition globale pour limiter les autorisations. Si vous utilisez les deux clés de contexte de condition globale et que la valeur `aws:SourceArn` contient l'ID de compte, la valeur `aws:SourceAccount` et le compte dans la valeur `aws:SourceArn` doivent utiliser le même ID de compte lorsqu'ils sont utilisés dans la même instruction de politique. Utilisez `aws:SourceArn` si vous souhaitez qu'une seule ressource soit associée à l'accès entre services. Utilisez `aws:SourceAccount` si vous souhaitez autoriser l’association d’une ressource de ce compte à l’utilisation interservices.
La valeur de `aws:SourceArn` doit être l'ARN du domaine de OpenSearch service.
Le moyen le plus efficace de se protéger contre le problème de député confus consiste à utiliser la clé de contexte de condition globale `aws:SourceArn` avec l’ARN complet de la ressource. Si vous ne connaissez pas l’ARN complet de la ressource ou si vous spécifiez plusieurs ressources, utilisez la clé de contexte de condition globale `aws:SourceArn` avec des caractères génériques (`*`) pour les parties inconnues de l’ARN. Par exemple, `arn:aws:es:*:123456789012:*`.
L'exemple suivant montre comment utiliser les clés contextuelles de condition `aws:SourceAccount` globale `aws:SourceArn` et les clés de contexte dans OpenSearch Service pour éviter le problème de confusion des adjoints.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":{
"Sid":"ConfusedDeputyPreventionExamplePolicy",
"Effect":"Allow",
"Principal":{
"Service":"es.amazonaws.com"
},
"Action":"sts:AssumeRole",
"Condition":{
"StringEquals":{
"aws:SourceAccount":"111122223333"
},
"ArnLike":{
"aws:SourceArn":"arn:aws:es:us-east-1:111122223333:domain/my-domain"
}
}
}
}
```
------
# Contrôle d'accès précis dans Amazon Service OpenSearch
Le contrôle d'accès précis offre des moyens supplémentaires de contrôler l'accès à vos données sur Amazon OpenSearch Service. Par exemple, selon l'auteur de la demande, vous pouvez souhaiter qu'une recherche renvoie les résultats d'un seul index. Vous pouvez masquer certains champs dans vos documents ou exclure certains documents.
Le contrôle précis des accès offre les avantages suivants :
+ Contrôle d'accès basé sur les rôles
+ Sécurité au niveau de l'index, du document et du champ
+ OpenSearch Tableaux de bord mutualisés
+ Authentification de base HTTP pour OpenSearch les OpenSearch tableaux de bord
**Topics**
+ [Vue d'ensemble : contrôle d'accès précis et OpenSearch sécurité des services](#fgac-access-policies)
+ [Concepts clés](#fgac-concepts)
+ [À propos de l'utilisateur principal](#fgac-master-user)
+ [Activation du contrôle précis des accès](#fgac-enabling)
+ [Accès aux OpenSearch tableaux de bord en tant qu'utilisateur principal](#fgac-dashboards)
+ [Gestion des autorisations](#fgac-access-control)
+ [Configurations recommandées](#fgac-recommendations)
+ [Limitations](#fgac-limitations)
+ [Modification de l'utilisateur maître](#fgac-forget)
+ [Utilisateurs principaux supplémentaires](#fgac-more-masters)
+ [Instantanés manuels](#fgac-snapshots)
+ [Intégrations](#fgac-integrations)
+ [Différences d'API REST](#fgac-rest-api)
+ [Didacticiel : configurer un domaine avec un utilisateur principal IAM et l'authentification Amazon Cognito](fgac-iam.md)
+ [Didacticiel : configurer un domaine avec la base de données utilisateur interne et l'authentification de base HTTP](fgac-http-auth.md)
## Vue d'ensemble : contrôle d'accès précis et OpenSearch sécurité des services
La sécurité d'Amazon OpenSearch Service comporte trois niveaux principaux :
**Réseau**
La première couche de sécurité est le réseau, qui détermine si les demandes atteignent un domaine OpenSearch de service. Si vous choisissez **Public access (Accès public)** lorsque vous créez un domaine, les demandes de tout client connecté à Internet peuvent atteindre le point de terminaison du domaine. Si vous choisissez **VPC Access (Accès VPC)**, les clients doivent se connecter au VPC (et les groupes de sécurité associés doivent l'autoriser) pour qu'une demande atteigne le point de terminaison. Pour plus d'informations, consultez [Lancement de vos domaines Amazon OpenSearch Service au sein d'un VPC](vpc.md).
**Stratégie d'accès au domaine**
La deuxième couche de sécurité est la stratégie d'accès au domaine. Une fois qu'une requête atteint un point de terminaison de domaine, la [stratégie d'accès basée sur les ressources](ac.md#ac-types-resource) autorise ou refuse l'accès de la demande à un URI donné. La stratégie d'accès accepte ou rejette les demandes au « bord » du domaine, avant qu'elles n'atteignent OpenSearch.
**Contrôle précis des accès**
La troisième et dernière couche de sécurité est un contrôle précis des accès. Après qu'une stratégie d'accès basée sur les ressources autorise une demande à atteindre un point de terminaison de domaine, un contrôle précis des accès évalue les informations d'identification de l'utilisateur et authentifie l'utilisateur ou refuse la demande. Si le contrôle précis des accès authentifie l'utilisateur, il extrait tous les rôles mappés à cet utilisateur et utilise l'ensemble complet des autorisations pour déterminer comment traiter la demande.
**Note**
Si une politique d'accès basée sur les ressources contient des rôles ou des utilisateurs IAM, les clients doivent envoyer des demandes signées à l'aide de AWS Signature Version 4. Ainsi, les stratégies d'accès peuvent entrer en conflit avec le contrôle précis des accès, plus particulièrement si vous utilisez la base de données utilisateur interne et l'authentification de base HTTP. Vous ne pouvez pas signer une demande avec un nom d'utilisateur, un mot de passe *et des* informations d'identification IAM. En général, si vous activez le contrôle d'accès affiné, nous vous recommandons d'utiliser une stratégie d'accès au domaine qui ne nécessite pas de demandes signées.
Le diagramme suivant illustre une configuration courante : un domaine d'accès VPC avec contrôle précis des accès activé, une stratégie d'accès basée sur IAM et un utilisateur principal IAM.
![\[Flux d'autorisation du contrôle précis des accès avec un domaine VPC\]](http://docs.aws.amazon.com/fr_fr/opensearch-service/latest/developerguide/images/fgac-vpc-iam.png)
Le diagramme suivant illustre une autre configuration courante : un domaine d'accès public avec contrôle précis des accès activé, une stratégie d'accès qui n'utilise pas d'entités IAM et un utilisateur principal dans la base de données utilisateur interne.
![\[Flux d'autorisation du contrôle précis des accès avec un domaine d'accès public\]](http://docs.aws.amazon.com/fr_fr/opensearch-service/latest/developerguide/images/fgac-public-basic.png)
### Exemple
Considérez une demande `GET` adressée à `movies/_search?q=thor`. L'utilisateur dispose-t-il des autorisations pour effectuer une recherche dans l'index `movies` ? Si oui, l'utilisateur dispose-t-il des autorisations pour voir *tous* les documents qu'il contient ? La réponse devrait-elle omettre ou anonymiser des champs ? Pour l'utilisateur maître, la réponse peut se présenter comme suit :
```
{
"hits": {
"total": 7,
"max_score": 8.772789,
"hits": [{
"_index": "movies",
"_type": "_doc",
"_id": "tt0800369",
"_score": 8.772789,
"_source": {
"directors": [
"Kenneth Branagh",
"Joss Whedon"
],
"release_date": "2011-04-21T00:00:00Z",
"genres": [
"Action",
"Adventure",
"Fantasy"
],
"plot": "The powerful but arrogant god Thor is cast out of Asgard to live amongst humans in Midgard (Earth), where he soon becomes one of their finest defenders.",
"title": "Thor",
"actors": [
"Chris Hemsworth",
"Anthony Hopkins",
"Natalie Portman"
],
"year": 2011
}
},
...
]
}
}
```
Si un utilisateur disposant d'autorisations plus limitées émet exactement la même demande, la réponse peut ressembler à ceci :
```
{
"hits": {
"total": 2,
"max_score": 8.772789,
"hits": [{
"_index": "movies",
"_type": "_doc",
"_id": "tt0800369",
"_score": 8.772789,
"_source": {
"year": 2011,
"release_date": "3812a72c6dd23eef3c750c2d99e205cbd260389461e19d610406847397ecb357",
"plot": "The powerful but arrogant god Thor is cast out of Asgard to live amongst humans in Midgard (Earth), where he soon becomes one of their finest defenders.",
"title": "Thor"
}
},
...
]
}
}
```
La réponse a moins d'accès et moins de champs pour chaque accès. En outre, le champ `release_date` est anonymisé. Si un utilisateur sans autorisation effectue la même demande, le cluster renvoie une erreur :
```
{
"error": {
"root_cause": [{
"type": "security_exception",
"reason": "no permissions for [indices:data/read/search] and User [name=limited-user, roles=[], requestedTenant=null]"
}],
"type": "security_exception",
"reason": "no permissions for [indices:data/read/search] and User [name=limited-user, roles=[], requestedTenant=null]"
},
"status": 403
}
```
Si un utilisateur fournit des informations d'identification non valides, le cluster renvoie une exception `Unauthorized`.
## Concepts clés
Lorsque vous vous lancez dans le contrôle d'accès détaillé, tenez compte des concepts suivants :
+ **Rôles** : méthode de base pour utiliser un contrôle d'accès précis. Dans ce cas, les rôles sont distincts des rôles IAM. Les rôles contiennent n'importe quelle combinaison d'autorisations : à l'échelle du cluster, spécifique à l'index, au niveau du document et au niveau du champ.
+ **Cartographie** : après avoir configuré un rôle, vous le *mappez* à un ou plusieurs utilisateurs. Par exemple, vous pouvez mapper trois rôles à un seul utilisateur : un rôle qui donne accès aux tableaux de bord, un qui fournit un accès à `index1` en lecture seule et un autre qui fournit un accès en écriture à `index2`. Vous pouvez également inclure toutes ces autorisations dans un seul rôle.
+ **Utilisateurs** : personnes ou applications qui adressent des demandes au OpenSearch cluster. Les utilisateurs disposent d'informations d'identification, qu'il s'agisse de clés d'accès IAM ou d'un nom d'utilisateur et d'un mot de passe, qu'ils spécifient lorsqu'ils font des demandes.
## À propos de l'utilisateur principal
L'*utilisateur principal* dans OpenSearch Service est soit une combinaison de nom d'utilisateur et de mot de passe, soit un utilisateur principal IAM disposant des autorisations complètes sur le OpenSearch cluster sous-jacent. Un utilisateur est considéré comme un utilisateur principal s'il dispose de tous les accès au OpenSearch cluster et s'il a la possibilité de créer des utilisateurs internes, des rôles et des mappages de rôles dans les OpenSearch tableaux de bord.
Un utilisateur principal créé dans la console OpenSearch de service ou via la CLI est automatiquement mappé à deux rôles prédéfinis :
+ `all_access`— Fournit un accès complet à toutes les opérations à l'échelle du cluster, l'autorisation d'écrire dans tous les index du cluster et l'autorisation d'écrire à tous les locataires.
+ `security_manager`— Permet d'accéder au [plugin de sécurité](https://opensearch.org/docs/latest/security/) et de gérer les utilisateurs et les autorisations.
Ces deux rôles permettent à l'utilisateur d'accéder à l'onglet **Sécurité** des OpenSearch tableaux de bord, où il peut gérer les utilisateurs et les autorisations. Si vous créez un autre utilisateur interne et que vous le mappez uniquement au `all_access` rôle, l'utilisateur n'a pas accès à l'onglet **Sécurité**. Vous pouvez créer des utilisateurs principaux supplémentaires en les mappant explicitement aux `security_manager` rôles `all_access` et. Pour obtenir des instructions, veuillez consulter [Utilisateurs principaux supplémentaires](#fgac-more-masters).
Lorsque vous créez un utilisateur principal pour votre domaine, vous pouvez spécifier un utilisateur principal *IAM existant ou créer un utilisateur principal* dans la *base de données utilisateur interne*. Tenez compte des points suivants lorsque vous décidez lequel utiliser :
+ **Principal IAM** — Si vous choisissez un principal IAM pour votre utilisateur principal, toutes les demandes adressées au cluster doivent être signées à l'aide de AWS Signature Version 4.
OpenSearch Le service ne prend en compte aucune des autorisations du principal IAM. L'utilisateur ou le rôle IAM sert uniquement à l'*authentification*. Les politiques relatives à cet utilisateur ou à ce rôle n'ont aucune incidence sur l'*autorisation* de l'utilisateur principal. L'autorisation est gérée par le biais [des différentes autorisations](https://opensearch.org/docs/latest/security/access-control/permissions/) du plugin OpenSearch de sécurité.
Par exemple, vous pouvez n'attribuer aucune autorisation *IAM* à un principal IAM, et tant que la machine ou la personne peut s'authentifier auprès de cet utilisateur ou de ce rôle, elle dispose du pouvoir de l'utilisateur principal dans Service. OpenSearch
Nous recommandons IAM si vous souhaitez utiliser les mêmes utilisateurs sur plusieurs clusters, si vous souhaitez utiliser Amazon Cognito pour accéder aux tableaux de bord ou si vous OpenSearch avez des clients qui prennent en charge la signature Signature version 4.
+ **Base de données utilisateur interne** : si vous créez un maître dans la base de données utilisateur interne (avec une combinaison nom d'utilisateur et mot de passe), vous pouvez utiliser l'authentification HTTP de base (ainsi que les informations d'identification IAM) pour envoyer des demandes au cluster. La plupart des clients prennent en charge l'authentification de base, notamment [curl](https://curl.haxx.se/), qui prend également en charge la version 4 de AWS Signature avec l'[option --aws-sigv4](https://curl.se/docs/manpage.html). La base de données utilisateur interne est stockée dans un OpenSearch index, vous ne pouvez donc pas la partager avec d'autres clusters.
Nous recommandons la base de données utilisateur interne si vous n'avez pas besoin de réutiliser les utilisateurs sur plusieurs clusters, si vous souhaitez utiliser l'authentification de base HTTP pour accéder aux tableaux de bord (plutôt qu'Amazon Cognito), ou si vous avez des clients qui prennent uniquement en charge l'authentification de base. La base de données utilisateur interne est le moyen le plus simple de démarrer avec OpenSearch Service.
## Activation du contrôle précis des accès
Activez un contrôle d'accès précis à l'aide de la console ou de l' AWS CLI API de configuration. Pour les étapes, consultez [Création et gestion de domaines Amazon OpenSearch Service](createupdatedomains.md).
Le contrôle d'accès détaillé nécessite Elasticsearch OpenSearch 6.7 ou version ultérieure. Il nécessite également le protocole HTTPS pour tout le trafic vers le domaine, le [chiffrement des données au repos](encryption-at-rest.md) et le [node-to-node chiffrement](ntn.md). Selon la façon dont vous configurez les fonctionnalités avancées du contrôle d'accès détaillé, le traitement supplémentaire de vos demandes peut nécessiter des ressources de calcul et de mémoire sur des nœuds de données individuels. Après avoir activé le contrôle précis des accès, vous ne pourrez pas le désactiver.
### Activation du contrôle précis des accès sur des domaines existants
Vous pouvez activer un contrôle d'accès précis sur les domaines existants exécutant Elasticsearch OpenSearch 6.7 ou version ultérieure.
**Pour activer le contrôle précis des accès sur un domaine existant (console)**
1. Sélectionnez votre domaine et choisissez **Actions** et **Edit security configuration** (Modifier la configuration de sécurité).
1. Sélectionnez **Enable fine-grained access control** (Activer le contrôle précis des accès).
1. Choisissez comment créer l'utilisateur principal :
+ Si vous souhaitez utiliser IAM pour la gestion des utilisateurs, choisissez **Set IAM ARN as master user (Définir l'ARN IAM en tant qu'utilisateur principal)**, puis indiquez l'ARN d'un rôle IAM.
+ Si vous souhaitez utiliser la base de données utilisateur interne, choisissez **Create master user et spécifiez un nom d'utilisateur** et un mot de passe.
1. (Facultatif) Sélectionnez **Enable migration period for open/IP-based access policy** (Activer la période de migration pour la stratégie d'accès Open/basée sur l'IP). Ce paramètre permet une période de transition de 30 jours pendant laquelle vos utilisateurs actuels peuvent continuer à accéder au domaine sans interruption. Les [stratégies d'accès basées sur l'IP](ac.md#ac-types-ip) et Open existantes continueront à fonctionner avec votre domaine. Pendant cette période de migration, nous recommandons aux administrateurs de [créer les rôles nécessaires et de les mapper aux utilisateurs](#fgac-access-control) pour le domaine. Si vous utilisez des stratégies basées sur l'identité au lieu d'une stratégie d'accès Open ou basée sur l'IP, vous pouvez désactiver ce paramètre.
Vous devez également mettre à jour vos clients pour qu'ils utilisent un contrôle précis des accès pendant la période de migration. Par exemple, si vous associez des rôles IAM à un contrôle d'accès précis, vous devez mettre vos clients à jour pour qu'ils commencent à signer les demandes avec AWS Signature Version 4. Si vous configurez l'authentification de base HTTP avec un contrôle précis des accès, vous devez mettre à jour vos clients pour qu'ils fournissent les informations d'identification d'authentification de base appropriées dans les demandes.
Pendant la période de migration, les utilisateurs qui accèdent au point de terminaison OpenSearch Dashboards pour le domaine arriveront directement sur la page de **découverte** plutôt que sur la page de connexion. Les administrateurs et les utilisateurs principaux peuvent choisir **Login** (Connexion) pour se connecter avec les informations d'identification de l'administrateur et configurer les mappages de rôles.
**Important**
**OpenSearch Le service désactive automatiquement la période de migration après 30 jours.** Nous vous recommandons de la terminer dès que vous aurez créé les rôles nécessaires et que vous les aurez mappés aux utilisateurs. Une fois la période de migration terminée, vous ne pouvez pas la réactiver.
1. Sélectionnez **Enregistrer les modifications**.
Le changement déclenche un [déploiement bleu/vert](managedomains-configuration-changes.md#bg) pendant lequel l'état du cluster devient rouge, mais toutes les opérations du cluster ne sont pas affectées.
**Pour activer le contrôle précis des accès sur un domaine existant (CLI)**
Définissez `AnonymousAuthEnabled` sur `true` pour activer la période de migration avec un contrôle précis des accès :
```
aws opensearch update-domain-config --domain-name test-domain --region us-east-1 \
--advanced-security-options '{ "Enabled": true, "InternalUserDatabaseEnabled":true, "MasterUserOptions": {"MasterUserName":"master-username","MasterUserPassword":"master-password"},"AnonymousAuthEnabled": true}'
```
### À propos du rôle default\$1role
Le contrôle précis des accès nécessite un [mappage des rôles](#fgac-mapping). Si votre domaine utilise des [politiques d'accès basées sur l'identité](ac.md#ac-types-identity), OpenSearch Service associe automatiquement vos utilisateurs à un nouveau rôle appelé **default\$1role** afin de vous aider à migrer correctement les utilisateurs existants. Ce mappage temporaire garantit que vos utilisateurs peuvent toujours envoyer avec succès des demandes GET et PUT signées par IAM jusqu'à ce que vous créiez vos propres mappages de rôles.
Le rôle n'ajoute aucune vulnérabilité ou faille de sécurité à votre domaine OpenSearch de service. Nous vous recommandons de supprimer le rôle par défaut dès que vous aurez configuré vos propres rôles et que vous les aurez mappés en conséquence.
### Scénarios de migration
Le tableau suivant décrit le comportement de chaque méthode d'authentification avant et après l'activation du contrôle précis des accès sur un domaine existant, ainsi que les étapes que les administrateurs doivent suivre pour mapper correctement leurs utilisateurs aux rôles :
| Méthode d'authentification | Avant l'activation du contrôle précis des accès | Après l'activation du contrôle précis des accès | Tâches de l'administrateur |
| --- | --- | --- | --- |
| Politiques basées sur l’identité | Tous les utilisateurs respectant la politique IAM peuvent accéder au domaine. | Vous n'avez pas besoin d'activer la période de migration. OpenSearch Le service mappe automatiquement tous les utilisateurs qui satisfont à la politique IAM au rôle **[default\$1role](#fgac-enabling-defaultrole)** afin qu'ils puissent continuer à accéder au domaine. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/opensearch-service/latest/developerguide/fgac.html) |
| Stratégies basées sur l'IP | Tous les utilisateurs des adresses IP ou des blocs d'adresses CIDR autorisés peuvent accéder au domaine. | Pendant la période de migration de 30 jours, tous les utilisateurs des adresses IP ou des blocs d'adresses CIDR autorisés peuvent continuer à accéder au domaine. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/opensearch-service/latest/developerguide/fgac.html) |
| Stratégies d'accès Open | Tous les utilisateurs sur Internet peuvent accéder au domaine. | Pendant la période de migration de 30 jours, tous les utilisateurs sur Internet peuvent continuer à accéder au domaine. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/opensearch-service/latest/developerguide/fgac.html) |
## Accès aux OpenSearch tableaux de bord en tant qu'utilisateur principal
Le contrôle d'accès précis est doté d'un plugin OpenSearch Dashboards qui simplifie les tâches de gestion. Vous pouvez utiliser les tableaux de bord pour gérer les utilisateurs, les rôles, les mappages, les groupes d'actions et les locataires. La page de connexion OpenSearch aux tableaux de bord et la méthode d'authentification sous-jacente varient toutefois en fonction de la façon dont vous gérez les utilisateurs et configurez votre domaine.
+ Si vous souhaitez utiliser IAM pour la gestion des utilisateurs, utilisez [Configuration de l'authentification Amazon Cognito pour les tableaux de bord OpenSearch](cognito-auth.md) pour accéder aux tableaux de bord. Sinon, les tableaux de bord afficheront une page de connexion non fonctionnelle. Consultez [Limitations](#fgac-limitations).
Avec l'authentification Amazon Cognito, l'un des rôles assumés dans le pool d'identités doit correspondre au rôle IAM que vous avez spécifié pour l'utilisateur principal. Pour en savoir plus sur cette configuration, consultez [(Facultatif) Configuration du contrôle précis des accès](cognito-auth.md#cognito-auth-granular) et [Didacticiel : configurer un domaine avec un utilisateur principal IAM et l'authentification Amazon Cognito](fgac-iam.md).
![\[Page de connexion Cognito\]](http://docs.aws.amazon.com/fr_fr/opensearch-service/latest/developerguide/images/cognito-auth.png)
+ Si vous choisissez d'utiliser la base de données utilisateur interne, vous pouvez vous connecter à Dashboards avec votre nom d'utilisateur et votre mot de passe principaux. Vous devez accéder aux tableaux de bord via HTTPS. L'authentification Amazon Cognito et SAML pour les tableaux de bord remplacent tous les deux cet écran de connexion.
Pour en savoir plus sur cette configuration, consultez [Didacticiel : configurer un domaine avec la base de données utilisateur interne et l'authentification de base HTTP](fgac-http-auth.md).
![\[Page de connexion de l'authentification de base\]](http://docs.aws.amazon.com/fr_fr/opensearch-service/latest/developerguide/images/basic-auth-dashboards.png)
+ Si vous choisissez d'utiliser l'authentification SAML, vous pouvez vous connecter à l'aide des informations d'identification d'un fournisseur d'identité externe. Pour en savoir plus, consultez [Authentification SAML pour les tableaux de bord OpenSearch](saml.md).
## Gestion des autorisations
Comme indiqué dans [Concepts clés](#fgac-concepts), vous gérez les autorisations de contrôle précis des accès à l'aide de rôles, d'utilisateurs et de mappages. Cette section décrit comment créer et appliquer ces ressources. Nous vous recommandons de vous [connecter aux tableaux de bord en tant qu'utilisateur principal](#fgac-dashboards) pour exécuter ces opérations.
![\[Page d'accueil de la sécurité dans les tableaux de bord\]](http://docs.aws.amazon.com/fr_fr/opensearch-service/latest/developerguide/images/dashboards-fgac-home.png)
**Note**
Les autorisations que vous choisissez d'accorder aux utilisateurs varient considérablement en fonction du cas d'utilisation. Nous ne pouvons pas couvrir tous les scénarios de cette documentation. Lorsque vous déterminez les autorisations à accorder à vos utilisateurs, veillez à faire référence aux autorisations de OpenSearch cluster et d'index mentionnées dans les sections suivantes, et respectez toujours le [principe du moindre privilège](https://en.wikipedia.org/wiki/Principle_of_least_privilege).
### Créer des rôles
Vous pouvez créer de nouveaux rôles pour un contrôle d'accès précis à l'aide de OpenSearch tableaux de bord ou de l'`_plugins/_security`opération dans l'API REST. Pour en savoir plus, consultez [Créer des rôles](https://opensearch.org/docs/latest/security/access-control/users-roles/#create-roles).
Le contrôle précis des accès inclut également un certain nombre de [rôles prédéfinis](https://opensearch.org/docs/latest/security/access-control/users-roles/#predefined-roles). Les clients tels que OpenSearch Dashboards et Logstash envoient une grande variété de demandes OpenSearch, ce qui peut rendre difficile la création manuelle de rôles avec un minimum d'autorisations. Par exemple, le rôle `opensearch_dashboards_user` inclut les autorisations dont un utilisateur a besoin pour créer des modèles d'index, des visualisations, des tableaux de bord et des locataires. Nous vous recommandons de [le mapper](#fgac-mapping) à n'importe quel utilisateur ou rôle backend qui accède aux tableaux de bord, ainsi qu'aux rôles supplémentaires qui permettent d'accéder à d'autres index.
Amazon OpenSearch Service ne propose pas les OpenSearch rôles suivants :
+ `observability_full_access`
+ `observability_read_access`
+ `reports_read_access`
+ `reports_full_access`
Amazon OpenSearch Service propose plusieurs rôles qui ne sont pas disponibles avec OpenSearch :
+ `ultrawarm_manager`
+ `ml_full_access`
+ `cold_manager`
+ `notifications_full_access`
+ `notifications_read_access`
#### Sécurité au niveau du cluster
Les autorisations au niveau du cluster permettent de faire des demandes étendues telles que `_mget`, `_msearch`, et `_bulk`, de surveiller l'état, de prendre des instantanés, etc. Gérez ces autorisations à l'aide de la section **Autorisations de cluster** lors de la création d'un rôle. Pour obtenir la liste complète des autorisations au niveau du cluster, consultez [Autorisations de cluster](https://opensearch.org/docs/latest/security/access-control/permissions/#cluster-permissions).
Vous pouvez souvent atteindre la position de sécurité souhaitée à l'aide d'une combinaison des groupes d'actions par défaut, au lieu de le faire à l'aide d'autorisations individuelles. Pour obtenir la liste des groupes d'actions au niveau du cluster, consultez [Niveau du cluster](https://opensearch.org/docs/latest/security/access-control/default-action-groups/#cluster-level).
#### Sécurité au niveau de l'index
Les autorisations de niveau index incluent la possibilité de créer de nouveaux index, de rechercher des index, de lire et d'écrire des documents, de supprimer des documents, de gérer des alias, etc. Gérez ces autorisations à l'aide de la section **Autorisations d'index** lors de la création d'un rôle. Pour obtenir la liste complète des autorisations au niveau de l'indez, consultez [Autorisations d'index](https://opensearch.org/docs/latest/security/access-control/permissions/#index-permissions).
Vous pouvez souvent atteindre la position de sécurité souhaitée à l'aide d'une combinaison des groupes d'actions par défaut, au lieu de le faire à l'aide d'autorisations individuelles. Pour obtenir la liste des groupes d'actions au niveau de l'index, consultez [Niveau d'index](https://opensearch.org/docs/latest/security/access-control/default-action-groups/#index-level).
#### Sécurité au niveau du document
La sécurité au niveau du document vous permet de restreindre les documents d'un index qu'un utilisateur peut consulter. Lorsque vous créez un rôle, spécifiez un modèle d'index et une OpenSearch requête. Tous les utilisateurs que vous mappez à ce rôle ne peuvent voir que les documents correspondant à la requête. La sécurité au niveau du document affecte [le nombre d'accès que vous obtenez lorsque vous effectuez une recherche](#fgac-example).
Pour en savoir plus, consultez [Sécurité au niveau du document](https://opensearch.org/docs/latest/security/access-control/document-level-security/).
#### Sécurité au niveau du champ
La sécurité au niveau du champ vous permet de contrôler les champs de document qu'un utilisateur peut consulter. Lors de la création d'un rôle, ajoutez une liste de champs à inclure ou à exclure. Si vous incluez des champs, tous les utilisateurs que vous mappez à ce rôle ne peuvent voir que ces champs. Si vous excluez les champs, ils peuvent voir tous les champs *sauf* ceux exclus. La sécurité au niveau du champ affecte [le nombre de champs inclus dans les appels lorsque vous effectuez une recherche](#fgac-example).
Pour en savoir plus, consultez [Sécurité au niveau du champ](https://opensearch.org/docs/latest/security/access-control/field-level-security/).
#### Masquage des champs
Le masquage des champs est une alternative à la sécurité au niveau du champ qui vous permet d'anonymiser les données d'un champ plutôt que de les supprimer complètement. Lors de la création d'un rôle, ajoutez une liste de champs à masquer. Le masquage des champs détermine [si vous pouvez voir le contenu d'un champ lorsque vous effectuez une recherche](#fgac-example).
**Astuce**
Si vous appliquez le masquage standard à un champ, OpenSearch Service utilise un hachage aléatoire sécurisé qui peut entraîner des résultats d'agrégation inexacts. Pour effectuer des agrégations sur des champs masqués, utilisez plutôt un masquage basé sur un modèle.
### Créer des utilisateurs
Si vous avez activé la base de données utilisateur interne, vous pouvez créer des utilisateurs à l'aide OpenSearch des tableaux de bord ou de l'`_plugins/_security`opération de l'API REST. Pour en savoir plus, consultez [Créer des utilisateurs](https://opensearch.org/docs/latest/security/access-control/users-roles/#create-users).
Si vous avez choisi IAM pour votre utilisateur principal, ignorez cette partie des tableaux de bord. Créez des rôles IAM à la place. Pour plus d'informations, consultez le [Guide de l'utilisateur IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/).
### Mappage des rôles aux utilisateurs
Le mappage des rôles est l'aspect le plus critique du contrôle précis des accès. Le contrôle précis des accès dispose de rôles prédéfinis pour vous aider à démarrer, mais à moins que vous ne mappiez des rôles à des utilisateurs, chaque demande adressée au cluster se termine par une erreur d'autorisation.
*Les rôles principaux* peuvent contribuer à simplifier le processus de mappage des rôles. Plutôt que de mapper le même rôle à 100 utilisateurs individuels, vous pouvez associer le rôle à un rôle principal partagé par les 100 utilisateurs. Les rôles backend peuvent correspondre à des rôles IAM ou à des chaînes arbitraires.
+ Spécifiez les utilisateurs ARNs, les utilisateurs et les chaînes utilisateur Amazon Cognito dans la section **Utilisateurs**. Les chaînes utilisateur Cognito prennent la forme `Cognito/user-pool-id/username`.
+ Spécifiez les rôles principaux et le rôle IAM ARNs dans la section Rôles **principaux.**
![\[Écran de mappage des rôles\]](http://docs.aws.amazon.com/fr_fr/opensearch-service/latest/developerguide/images/role-mapping-edit.png)
Vous pouvez associer les rôles aux utilisateurs à l'aide de OpenSearch tableaux de bord ou de l'`_plugins/_security`opération de l'API REST. Pour en savoir plus, consultez [Mapper des utilisateurs à des rôles](https://opensearch.org/docs/latest/security/access-control/users-roles/#map-users-to-roles).
### Créer des groupes d'actions
Les groupes d'actions sont des ensembles d'autorisations que vous pouvez réutiliser sur différentes ressources. Vous pouvez créer de nouveaux groupes d'actions à l'aide de OpenSearch tableaux de bord ou de l'`_plugins/_security`opération de l'API REST, bien que les groupes d'actions par défaut soient suffisants dans la plupart des cas d'utilisation. Pour en savoir plus sur les groupes d'actions par défaut, consultez [Groupes d'actions par défaut](https://opensearch.org/docs/latest/security/access-control/default-action-groups/).
### OpenSearch Tableaux de bord mutualisés
Les locataires sont des espaces permettant d'enregistrer des modèles d'index, des visualisations, des tableaux de bord et d'autres objets des tableaux de bord. La mutualisation des tableaux de bord vous permet de partager en toute sécurité votre travail avec d'autres utilisateurs de Dashboards (ou de le garder privé) et de configurer les locataires de manière dynamique. Vous pouvez contrôler quels rôles ont accès à un locataire et si ces rôles ont un accès en lecture ou en écriture. Le locataire global est le client par défaut. Pour en savoir plus, consultez la section [OpenSearch Tableaux de bord mutualisés](https://opensearch.org/docs/latest/security/multi-tenancy/tenant-index/).
**Pour afficher votre locataire actuel ou changer de locataire**
1. Accédez aux OpenSearch tableaux de bord et connectez-vous.
1. Sélectionnez l'icône de votre utilisateur en haut à droite et choisissez **Switch tenants (Changer les locataires)**.
1. Vérifiez votre locataire avant de créer des visualisations ou des tableaux de bord. Si vous souhaitez partager votre travail avec tous les autres utilisateurs des tableaux de bord, choisissez **Global**. Pour partager votre travail avec un sous-ensemble d'utilisateurs des tableaux de bord, choisissez un autre locataire partagé. Sinon, choisissez **Private (Privé)**.
**Note**
OpenSearch Dashboards gère un index distinct pour chaque locataire et crée un modèle d'index appelé`tenant_template`. Ne supprimez ni ne modifiez l'`tenant_template`index, car cela pourrait entraîner un dysfonctionnement des OpenSearch tableaux de bord si le mappage de l'index des locataires est mal configuré.
## Configurations recommandées
En raison de la façon dont le contrôle d'accès affiné [interagit avec d'autres fonctionnalités de sécurité](#fgac-access-policies), nous recommandons plusieurs configurations de contrôle d'accès affiné qui fonctionnent bien dans la plupart des cas d'utilisation.
| Description | Utilisateur maître | Stratégie d'accès au domaine |
| --- | --- | --- |
| Utilisez les informations d'identification IAM pour les appels vers le OpenSearch APIs, et utilisez l'[authentification SAML pour accéder aux tableaux](saml.md) de bord. Gérer les rôles de contrôle précis des accès à l'aide de l'API REST. | Rôle ou utilisateur IAM | JSON
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "*"
},
"Action": "es:ESHttp*",
"Resource": "arn:aws:es:us-east-1:111122223333:domain/domain-name/*"
}
]
}
``` |
| Utilisez les informations d'identification IAM ou l'authentification de base pour les appels vers le OpenSearch APIs. Gérer les rôles de contrôle précis des accès à l'aide de l'API REST. Cette configuration offre une grande flexibilité, en particulier si vous avez des OpenSearch clients qui ne prennent en charge que l'authentification de base. Si vous disposez d'un fournisseur d'identité existant, utilisez l'[authentification SAML](saml.md) pour accéder aux tableaux de bord. Dans le cas contraire, gérez les utilisateurs des tableaux de bord dans la base de données utilisateur interne. | Nom d’utilisateur et mot de passe | JSON
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "*"
},
"Action": "es:ESHttp*",
"Resource": "arn:aws:es:us-east-1:111122223333:domain/domain-name/*"
}
]
}
``` |
| Utilisez les informations d'identification IAM pour les appels vers le OpenSearch APIs, et utilisez Amazon Cognito pour accéder aux tableaux de bord. Gérer les rôles de contrôle précis des accès à l'aide de l'API REST. | Rôle ou utilisateur IAM | JSON
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "*"
},
"Action": "es:ESHttp*",
"Resource": "arn:aws:es:us-east-1:111122223333:domain/domain-name/*"
}
]
}
``` |
| Utilisez les informations d'identification IAM pour les appels vers les OpenSearch APIs tableaux de bord et bloquez la plupart des accès à ceux-ci. Gérer les rôles de contrôle précis des accès à l'aide de l'API REST. | Rôle ou utilisateur IAM | JSON
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "*"
},
"Action": "es:ESHttp*",
"Resource": "arn:aws:es:us-east-1:111122223333:domain/domain-name/*"
},
{
"Effect": "Deny",
"Principal": {
"AWS": "*"
},
"Action": "es:ESHttp*",
"Resource": "arn:aws:es:us-east-1:111122223333:domain/domain-name/_dashboards*"
}
]
}
``` |
## Limitations
Le contrôle précis des accès présente plusieurs limites importantes :
+ L'aspect `hosts` des mappages de rôles, qui mappe les rôles aux noms d'hôte ou aux adresses IP, ne fonctionne pas si le domaine se trouve dans un VPC. Vous pouvez toujours mapper les rôles avec les utilisateurs et les rôles backend.
+ Si vous choisissez IAM pour l'utilisateur principal et que vous n'activez pas Amazon Cognito ou l'authentification SAML, les tableaux de bord afficheront une page de connexion non fonctionnelle.
+ Si vous choisissez IAM pour l'utilisateur principal, vous pouvez toujours créer des utilisateurs dans la base de données utilisateur interne. Étant donné que l'authentification de base HTTP n'est pas activée dans cette configuration, toutes les demandes signées avec ces informations d'identification utilisateur sont rejetées.
+ Si vous utilisez [SQL](sql-support.md) pour interroger un index auquel vous n'avez pas accès, vous recevez une erreur « aucune autorisation ». Si l'index n'existe pas, vous recevez une erreur « no such index » (L'index n'existe pas). Cette différence dans les messages d'erreur signifie que vous pouvez confirmer l'existence d'un index si vous devinez son nom.
Pour minimiser le problème, [n'incluez pas d'informations sensibles dans les noms d'index](indexing.md#indexing-naming). Pour refuser tout accès à SQL, ajoutez l'élément suivant à votre stratégie d'accès au domaine :
```
{
"Effect": "Deny",
"Principal": {
"AWS": [
"*"
]
},
"Action": [
"es:*"
],
"Resource": "arn:aws:es:us-east-1:123456789012:domain/my-domain/_plugins/_sql"
}
```
+ Si la version de votre domaine est 2.3 ou supérieure et que le contrôle d'accès détaillé est activé, le réglage sur 1 `max_clause_count` entraîne des problèmes avec votre domaine. Nous vous recommandons de définir un nombre plus élevé pour ce compte.
+ Si vous activez le contrôle d'accès détaillé dans un domaine où le contrôle d'accès détaillé n'est pas configuré, pour les sources de données créées pour une requête directe, vous devez configurer vous-même des rôles de contrôle d'accès précis. Pour plus d'informations sur la façon de configurer des rôles d'accès précis, consultez Création d'[intégrations de sources de données Amazon OpenSearch Service avec Amazon S3](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/direct-query-s3-creating.html#direct-query-s3-prereq).
## Modification de l'utilisateur maître
Si vous oubliez les détails de l'utilisateur principal, vous pouvez le reconfigurer à l'aide de la console, de l' AWS CLI ou de l'API de configuration.
**Pour modifier l'utilisateur maître (console)**
1. Accédez à la console Amazon OpenSearch Service à l'adresse [https://console.aws.amazon.com/aos/home/](https://console.aws.amazon.com/aos/home/).
1. Sélectionnez votre domaine et choisissez **Actions** et **Edit security configuration** (Modifier la configuration de sécurité).
1. Choisissez **Set IAM ARN as master user (Définir l'ARN IAM en tant qu'utilisateur principal)** ou **Create master user (Créer un nouvel utilisateur principal)**.
+ Si vous avez précédemment utilisé un utilisateur principal IAM, le contrôle précis des accès remappera le rôle `all_access` avec le nouvel ARN IAM que vous indiquerez.
+ Si vous avez précédemment utilisé la base de données utilisateur interne, le contrôle précis des accès créera un nouvel utilisateur principal. Vous pouvez utiliser le nouvel utilisateur principal pour supprimer l'ancien.
+ Le passage de la base de données utilisateur interne à un utilisateur principal IAM ne supprime *aucun* utilisateur de la base de données utilisateur interne. Cela permet simplement de désactiver l'authentification de base HTTP. Supprimez manuellement les utilisateurs de la base de données utilisateur interne ou conservez-les au cas où vous auriez besoin de réactiver l'authentification HTTP de base.
1. Sélectionnez **Enregistrer les modifications**.
## Utilisateurs principaux supplémentaires
Vous désignez un utilisateur principal lorsque vous créez un domaine, mais si vous le souhaitez, vous pouvez utiliser cet utilisateur principal pour créer d'autres utilisateurs principaux. Deux options s'offrent à vous : les OpenSearch tableaux de bord ou l'API REST.
+ Dans les tableaux de bord, choisissez **Security (Sécurité)**, **Roles (Rôles)**, puis mappez le nouvel utilisateur principal aux rôles `all_access` et `security_manager`.
![\[Page Mappage des rôles\]](http://docs.aws.amazon.com/fr_fr/opensearch-service/latest/developerguide/images/new-master-users.png)
+ Pour utiliser l'API REST, envoyez les requêtes suivantes :
```
PUT _plugins/_security/api/rolesmapping/all_access
{
"backend_roles": [
"arn:aws:iam::123456789012:role/fourth-master-user"
],
"hosts": [],
"users": [
"master-user",
"second-master-user",
"arn:aws:iam::123456789012:user/third-master-user"
]
}
```
```
PUT _plugins/_security/api/rolesmapping/security_manager
{
"backend_roles": [
"arn:aws:iam::123456789012:role/fourth-master-user"
],
"hosts": [],
"users": [
"master-user",
"second-master-user",
"arn:aws:iam::123456789012:user/third-master-user"
]
}
```
Comme ces demandes *remplacent* les mappages de rôles actuels, exécutez d'abord les demandes `GET` afin que vous puissiez inclure tous les rôles actuels dans les demandes `PUT`. L'API REST est particulièrement utile si vous ne pouvez pas accéder aux tableaux de bord et que vous souhaitez mapper un rôle IAM Amazon Cognito au rôle `all_access`.
## Instantanés manuels
Le contrôle précis des accès introduit quelques complications supplémentaires avec la prise des instantanés manuels. Pour enregistrer un référentiel d'instantanés, même si vous utilisez l'authentification de base HTTP à d'autres fins, vous devez mapper le rôle `manage_snapshots` à un rôle IAM disposant des autorisations `iam:PassRole` pour assumer `TheSnapshotRole`, comme défini dans [Conditions préalables](managedomains-snapshots.md#managedomains-snapshot-prerequisites).
Utilisez ensuite ce rôle IAM pour envoyer une demande signée au domaine, comme indiqué dans [Inscription d'un référentiel d'instantanés manuels](managedomains-snapshot-registerdirectory.md).
## Intégrations
Si vous utilisez [d'autres AWS services](integrations.md) avec OpenSearch Service, vous devez fournir les rôles IAM pour ces services avec les autorisations appropriées. Par exemple, les flux de diffusion Firehose utilisent souvent un rôle IAM appelé. `firehose_delivery_role` Dans Tableaux de bord, [créez un rôle pour le contrôle précis des accès](#fgac-roles), puis [mappez le rôle IAM à celui-ci](#fgac-mapping). Dans ce cas, le nouveau rôle nécessite les autorisations suivantes :
```
{
"cluster_permissions": [
"cluster_composite_ops",
"cluster_monitor"
],
"index_permissions": [{
"index_patterns": [
"firehose-index*"
],
"allowed_actions": [
"create_index",
"manage",
"crud"
]
}]
}
```
Les autorisations varient en fonction des actions effectuées par chaque service. Une AWS IoT règle ou une AWS Lambda fonction qui indexe des données nécessite probablement des autorisations similaires à celles de Firehose, tandis qu'une fonction Lambda qui effectue uniquement des recherches peut utiliser un ensemble plus limité.
## Différences d'API REST
L'API REST à contrôle d'accès affiné diffère légèrement en fonction de votre version OpenSearch/Elasticsearch . Avant d'adresser une demande `PUT`, effectuez une demande `GET` pour vérifier le corps de requête attendu. Par exemple, une demande `GET` adressée à `_plugins/_security/api/user` renvoie tous les utilisateurs, que vous pouvez ensuite modifier et utiliser pour effectuer des demandes `PUT` valides.
Sur Elasticsearch 6*x*, les demandes de création d'utilisateurs se présentent comme suit :
```
PUT _opendistro/_security/api/user/new-user
{
"password": "some-password",
"roles": ["new-backend-role"]
}
```
Sur Elasticsearch 7.x OpenSearch ou sur Elasticsearch, les requêtes se présentent comme suit (remplacez `_plugins` par Elasticsearch `_opendistro` si vous utilisez Elasticsearch) :
```
PUT _plugins/_security/api/user/new-user
{
"password": "some-password",
"backend_roles": ["new-backend-role"]
}
```
En outre, les locataires sont les propriétés des rôles dans Elasticsearch 6.*x* :
```
GET _opendistro/_security/api/roles/all_access
{
"all_access": {
"cluster": ["UNLIMITED"],
"tenants": {
"admin_tenant": "RW"
},
"indices": {
"*": {
"*": ["UNLIMITED"]
}
},
"readonly": "true"
}
}
```
Dans OpenSearch Elasticsearch 7.x, ce sont des objets dotés de leur propre URI (`_plugins`remplacez-le `_opendistro` si vous utilisez Elasticsearch) :
```
GET _plugins/_security/api/tenants
{
"global_tenant": {
"reserved": true,
"hidden": false,
"description": "Global tenant",
"static": false
}
}
```
Pour obtenir de la documentation sur l' OpenSearch API REST, consultez la [référence de l'API du plugin de sécurité](https://opensearch.org/docs/latest/security/access-control/api/).
**Astuce**
Si vous utilisez la base de données utilisateur interne, vous pouvez utiliser [curl](https://curl.haxx.se/) pour effectuer des demandes et tester votre domaine. Essayez les exemples de commande suivants :
```
curl -XGET -u 'master-user:master-user-password' 'domain-endpoint/_search'
curl -XGET -u 'master-user:master-user-password' 'domain-endpoint/_plugins/_security/api/user'
```
# Didacticiel : configurer un domaine avec un utilisateur principal IAM et l'authentification Amazon Cognito
Ce didacticiel couvre un cas d'utilisation courant d'Amazon OpenSearch Service pour le [contrôle d'accès détaillé](fgac.md) : un utilisateur principal IAM avec authentification Amazon Cognito pour les tableaux de bord. OpenSearch
Dans ce didacticiel, nous allons configurer un rôle IAM *principal* et un rôle IAM *limité*, que nous associerons ensuite aux utilisateurs dans Amazon Cognito. L'utilisateur principal peut ensuite se connecter aux OpenSearch tableaux de bord, associer l'utilisateur limité à un rôle et utiliser un contrôle d'accès précis pour limiter les autorisations de l'utilisateur.
![\[IAM roles and Amazon Cognito integration with OpenSearch Dashboards access control.\]](http://docs.aws.amazon.com/fr_fr/opensearch-service/latest/developerguide/images/fgac-cognito.png)
Bien que ces étapes utilisent le pool d'utilisateurs Amazon Cognito pour l'authentification, ce même processus de base fonctionne pour tout fournisseur d'authentification Cognito qui vous permet d'attribuer différents rôles IAM à différents utilisateurs.
Dans le cadre de ce didacticiel, vous suivrez les étapes suivantes :
1. [Créer les rôles IAM principal et limité](#fgac-iam-roles)
1. [Créer un domaine avec authentification Cognito](#fgac-iam-domain)
1. [Configuration d'un groupe d'utilisateurs et d'identités Cognito](#fgac-iam-cognito)
1. [Cartographier les rôles dans les OpenSearch tableaux de bord](#fgac-iam-dashboards)
1. [Tester les autorisations](#fgac-iam-test)
## Étape 1 : créer les rôles IAM principal et limité
Accédez à la console Gestion des identités et des accès AWS (IAM) et créez deux rôles distincts :
+ `MasterUserRole` : l'utilisateur principal, qui dispose des autorisations complètes sur le cluster et gère les rôles et les mappages de rôles.
+ `LimitedUserRole` : un rôle plus restreint, auquel vous accorderez un accès limité en tant qu'utilisateur principal.
Pour obtenir des instructions sur la création des rôles, consultez la section [Création d'un rôle à l'aide de politiques de confiance personnalisées](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-custom.html) dans le *guide de l'utilisateur IAM*.
Les deux rôles doivent disposer de la politique d'approbation suivante, qui permet à votre groupe d'identités Cognito d'endosser les rôles :
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Effect": "Allow",
"Principal": {
"Federated": "cognito-identity.amazonaws.com"
},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": {
"cognito-identity.amazonaws.com:aud": "{identity-pool-id}"
},
"ForAnyValue:StringLike": {
"cognito-identity.amazonaws.com:amr": "authenticated"
}
}
}]
}
```
------
**Note**
Remplacez `identity-pool-id` par l'identifiant unique de votre groupe d'identités Amazon Cognito. Par exemple, `us-east-1:0c6cdba7-3c3c-443b-a958-fb9feb207aa6`.
## Étape 2 : créer un domaine avec authentification Cognito
Accédez à la console Amazon OpenSearch Service à l'[https://console.aws.amazon.com/aos/adresse home/](https://console.aws.amazon.com/aos/home/) et [créez un domaine](createupdatedomains.md) avec les paramètres suivants :
+ OpenSearch 1.0 ou version ultérieure, ou Elasticsearch 7.8 ou version ultérieure
+ Accès public
+ Contrôle précis des accès activé avec `MasterUserRole` comme utilisateur principal (créé à l'étape précédente)
+ Authentification Amazon Cognito activée pour OpenSearch les tableaux de bord. Pour obtenir des instructions sur l'activation de l'authentification Cognito et choisir un groupe d'utilisateurs et d'identités, consultez [Configurer un domaine pour utiliser l'authentification Amazon Cognito](cognito-auth.md#cognito-auth-config).
+ La stratégie d'accès au domaine suivante :
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:root"
},
"Action": [
"es:ESHttp*"
],
"Resource": "arn:aws:es:us-east-1:111122223333:domain/{domain-name}/*"
}
]
}
```
------
+ HTTPS requis pour tout le trafic vers le domaine
+ Node-to-node chiffrement
+ Chiffrement de données au repos
## Étape 3 : Configuration des utilisateurs de Cognito
Lors de la création de votre domaine, configurez les utilisateurs principaux et limités dans Amazon Cognito en suivant la procédure [Créer un groupe d'utilisateurs dans le manuel](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pool-as-user-directory.html) *Amazon Cognito Developer Guide*. Enfin, configurez votre pool d'identités en suivant les étapes décrites dans [Créer un pool d'identités dans Amazon Cognito](https://docs.aws.amazon.com/cognito/latest/developerguide/getting-started-with-identity-pools.html#create-identity-pool). Le groupe d'utilisateurs et le groupe d'identités doivent se trouver dans la même Région AWS.
## Étape 4 : Cartographier les rôles dans les OpenSearch tableaux de bord
Maintenant que vos utilisateurs sont configurés, vous pouvez vous connecter à OpenSearch Dashboards en tant qu'utilisateur principal et associer les utilisateurs à des rôles.
1. Retournez à la console OpenSearch de service et accédez à l'URL OpenSearch des tableaux de bord du domaine que vous avez créé. Le format de l'URL est le suivant : `domain-endpoint/_dashboards/`.
1. Connectez-vous à l'aide des informations d'identification `master-user`.
1. Choisissez **Add sample data** (Ajouter des exemples de données), puis ajoutez les exemples de données de vol.
1. Dans le panneau de navigation de gauche, choisissez **Security** (Sécurité), **Roles** (Rôles), **Create role** (Créer un rôle).
1. Nommez le rôle `new-role`.
1. Pour **Index**, spécifiez `opensearch_dashboards_sample_data_fli*` (`kibana_sample_data_fli*` sur les domaines Elasticsearch).
1. Pour **Index permissions** (Autorisations d'index), choisissez **read** (lire).
1. Pour **Requête de sécurité au niveau du document**, indiquez la requête suivante :
```
{
"match": {
"FlightDelay": true
}
}
```
1. Pour la sécurité au niveau des champs, choisissez **Exclude (Exclure)** et indiquez `FlightNum`.
1. Pour **Anonymisation**, indiquez `Dest`.
1. Choisissez **Create (Créer)**.
1. Choisissez **Mapped users (Utilisateurs mappés)**, **Manage mapping (Gérer le mappage)**. Ajoutez l'Amazon Resource Name (ARN) pour `LimitedUserRole` en tant qu'identité externe et choisissez **Map** (Mapper).
1. Revenez à la liste des rôles et choisissez **opensearch\$1dashboards\$1user**. Choisissez **Mapped users (Utilisateurs mappés)**, **Manage mapping (Gérer le mappage)**. Ajoutez l'ARN pour `LimitedUserRole` en tant que rôle backend, puis choisissez **Map** (Mapper).
## Étape 5 : tester les autorisations
Lorsque vos rôles sont correctement mappés, vous pouvez vous connecter en tant qu'utilisateur limité et tester les autorisations.
1. Dans une nouvelle fenêtre de navigateur privée, accédez à l'URL OpenSearch des tableaux de bord du domaine, connectez-vous à l'aide des `limited-user` informations d'identification et choisissez **Explorer par moi-même**.
1. Accédez aux **Outils de développement**, puis exécutez la recherche par défaut :
```
GET _search
{
"query": {
"match_all": {}
}
}
```
Notez l'erreur d'autorisation. `limited-user` n'a pas les autorisations nécessaires pour exécuter des recherches à l'échelle du cluster.
1. Exécutez une autre recherche :
```
GET opensearch_dashboards_sample_data_flights/_search
{
"query": {
"match_all": {}
}
}
```
Notez que tous les documents correspondants ont un champ `FlightDelay` ayant pour valeur `true`, un champ anonymisé `Dest` et aucun champ `FlightNum`.
1. Dans la fenêtre de votre navigateur d'origine, connecté en tant que `master-user`, choisissez **Dev Tools (Outils de développement)**, puis effectuez les mêmes recherches. Notez la différence entre les autorisations, le nombre d'accès, les documents correspondants et les champs inclus.
# Didacticiel : configurer un domaine avec la base de données utilisateur interne et l'authentification de base HTTP
Ce didacticiel couvre un autre cas d'[utilisation courant du contrôle d'accès détaillé](fgac.md) : un utilisateur principal dans la base de données utilisateur interne et l'authentification de base HTTP pour les OpenSearch tableaux de bord. L'utilisateur principal peut ensuite se connecter aux OpenSearch tableaux de bord, créer un utilisateur interne, associer l'utilisateur à un rôle et utiliser un contrôle d'accès précis pour limiter les autorisations de l'utilisateur.
Dans le cadre de ce didacticiel, vous suivrez les étapes suivantes :
1. [Création d'un domaine avec un utilisateur principal](#fgac-http-auth-domain)
1. [Configuration d'un utilisateur interne dans les OpenSearch tableaux de bord](#fgac-http-auth-dashboards-user)
1. [Cartographier les rôles dans les OpenSearch tableaux de bord](#fgac-http-auth-dashboards-map)
1. [Tester les autorisations](#fgac-http-auth-test)
## Étape 1 : Créer un domaine
Accédez à la console Amazon OpenSearch Service à l'[https://console.aws.amazon.com/aos/adresse home/](https://console.aws.amazon.com/aos/home/) et [créez un domaine](createupdatedomains.md) avec les paramètres suivants :
+ OpenSearch 1.0 ou version ultérieure, ou Elasticsearch 7.9 ou version ultérieure
+ Accès public
+ Contrôle précis des accès avec un utilisateur principal dans la base de données utilisateur interne (`TheMasterUser` pour le reste du didacticiel)
+ Authentification Amazon Cognito pour les tableaux de bord *désactivés*
+ La stratégie d'accès suivante :
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:root"
},
"Action": [
"es:ESHttp*"
],
"Resource": "arn:aws:es:us-east-1:111122223333:domain/{domain-name}/*"
}
]
}
```
------
+ HTTPS requis pour tout le trafic vers le domaine
+ Node-to-node chiffrement
+ Chiffrement de données au repos
## Étape 2 : créer un utilisateur interne dans les OpenSearch tableaux de bord
Maintenant que vous avez un domaine, vous pouvez vous connecter à OpenSearch Dashboards et créer un utilisateur interne.
1. Retournez à la console OpenSearch de service et accédez à l'URL OpenSearch des tableaux de bord du domaine que vous avez créé. Le format de l'URL est le suivant : `domain-endpoint/_dashboards/`.
1. Connectez-vous avec le`TheMasterUser`.
1. Choisissez **Add sample data** (Ajouter des exemples de données), puis ajoutez les exemples de données de vol.
1. Dans le volet de navigation de gauche, choisissez **Sécurité**, **Utilisateurs internes**, **Créer un utilisateur interne**.
1. Nommez l'utilisateur `new-user` et spécifiez un mot de passe. Ensuite, choisissez **Create (Créer)**.
## Étape 3 : Cartographier les rôles dans les OpenSearch tableaux de bord
Maintenant que votre utilisateur est configuré, vous pouvez le mapper à un rôle.
1. Restez dans la section **Sécurité** des OpenSearch tableaux de bord et choisissez **Rôles**, **Créer un rôle**.
1. Nommez le rôle `new-role`.
1. Pour **Index**, spécifiez `opensearch_dashboards_sample_data_fli*` (`kibana_sample_data_fli*`sur les domaines Elasticsearch) le modèle d'index.
1. Pour le groupe d'actions, choisissez **read (lire)**.
1. Pour **Requête de sécurité au niveau du document**, indiquez la requête suivante :
```
{
"match": {
"FlightDelay": true
}
}
```
1. Pour la sécurité au niveau des champs, choisissez **Exclude (Exclure)** et indiquez `FlightNum`.
1. Pour **Anonymisation**, indiquez `Dest`.
1. Choisissez **Create (Créer)**.
1. Choisissez **Mapped users (Utilisateurs mappés)**, **Manage mapping (Gérer le mappage)**. Ensuite, ajoutez `new-user` à **Users (Utilisateurs)** et choisissez **Map (Mapper)**.
1. Revenez à la liste des rôles et choisissez **opensearch\$1dashboards\$1user**. Choisissez **Mapped users (Utilisateurs mappés)**, **Manage mapping (Gérer le mappage)**. Ensuite, ajoutez `new-user` à **Users (Utilisateurs)** et choisissez **Map (Mapper)**.
## Étape 4 : tester les autorisations
Lorsque vos rôles sont correctement mappés, vous pouvez vous connecter en tant qu'utilisateur limité et tester les autorisations.
1. Dans une nouvelle fenêtre de navigateur privée, accédez à l'URL OpenSearch des tableaux de bord du domaine, connectez-vous à l'aide des `new-user` informations d'identification et choisissez **Explorer par moi-même**.
1. Accédez aux **Outils de développement**, puis exécutez la recherche par défaut :
```
GET _search
{
"query": {
"match_all": {}
}
}
```
Notez l'erreur d'autorisation. `new-user` n'a pas les autorisations nécessaires pour exécuter des recherches à l'échelle du cluster.
1. Exécutez une autre recherche :
```
GET dashboards_sample_data_flights/_search
{
"query": {
"match_all": {}
}
}
```
Notez que tous les documents correspondants ont un champ `FlightDelay` ayant pour valeur `true`, un champ anonymisé `Dest` et aucun champ `FlightNum`.
1. Dans la fenêtre de votre navigateur d'origine, connecté en tant que `TheMasterUser`, choisissez **Dev Tools (Outils de développement)** et effectuez les mêmes recherches. Notez la différence entre les autorisations, le nombre d'accès, les documents correspondants et les champs inclus.
# Validation de conformité pour Amazon OpenSearch Service
Des auditeurs tiers évaluent la sécurité et la conformité d'Amazon OpenSearch Service dans le cadre de plusieurs programmes de AWS conformité. Il s'agit notamment des programmes SOC, PCI et HIPAA.
Si vous avez des exigences de conformité, envisagez d'utiliser n'importe quelle version d' OpenSearch Elasticsearch 6.0 ou version ultérieure. Les versions antérieures d'Elasticsearch ne proposent pas de combinaison de [chiffrement des données au repos et de node-to-node ](encryption-at-rest.md) [chiffrement](ntn.md) et il est peu probable qu'elles répondent à vos besoins. Vous pouvez également envisager d'utiliser n'importe quelle version d' OpenSearch Elasticsearch 6.7 ou version ultérieure si un [contrôle d'accès précis est](fgac.md) important pour votre cas d'utilisation. Quoi qu'il en soit, le choix d'une version particulière OpenSearch ou d'Elasticsearch lors de la création d'un domaine ne garantit pas la conformité.
Pour savoir si un [programme Services AWS de conformité Service AWS s'inscrit dans le champ d'application de programmes de conformité](https://aws.amazon.com/compliance/services-in-scope/) spécifiques, consultez Services AWS la section de conformité et sélectionnez le programme de conformité qui vous intéresse. Pour des informations générales, voir Programmes de [AWS conformité Programmes AWS](https://aws.amazon.com/compliance/programs/) de .
Vous pouvez télécharger des rapports d'audit tiers à l'aide de AWS Artifact. Pour plus d'informations, voir [Téléchargement de rapports dans AWS Artifact](https://docs.aws.amazon.com/artifact/latest/ug/downloading-documents.html) .
Votre responsabilité en matière de conformité lors de l'utilisation Services AWS est déterminée par la sensibilité de vos données, les objectifs de conformité de votre entreprise et les lois et réglementations applicables. Pour plus d'informations sur votre responsabilité en matière de conformité lors de l'utilisation Services AWS, consultez [AWS la documentation de sécurité](https://docs.aws.amazon.com/security/).
# Résilience dans Amazon OpenSearch Service
L'infrastructure AWS mondiale est construite autour Régions AWS de zones de disponibilité. Régions AWS fournissent plusieurs zones de disponibilité physiquement séparées et isolées, connectées par un réseau à faible latence, à haut débit et hautement redondant. Avec les zones de disponibilité, vous pouvez concevoir et exploiter des applications et des bases de données qui basculent automatiquement d’une zone de disponibilité à l’autre sans interruption. Les zones de disponibilité sont plus hautement disponibles, tolérantes aux pannes et évolutives que les infrastructures traditionnelles à un ou plusieurs centres de données.
Pour plus d'informations sur les zones de disponibilité Régions AWS et les zones de disponibilité, consultez la section [Infrastructure AWS globale](https://aws.amazon.com/about-aws/global-infrastructure/).
Outre l'infrastructure AWS mondiale, OpenSearch Service propose plusieurs fonctionnalités pour répondre à vos besoins en matière de résilience et de sauvegarde des données :
+ [Domaines multi-AZ et partitions de réplica](managedomains-multiaz.md)
+ [Instantanés manuels et automatiques](managedomains-snapshots.md)
# Authentification et autorisation JWT pour Amazon Service OpenSearch
Amazon OpenSearch Service vous permet désormais d'utiliser des jetons Web JSON (JWTs) pour l'authentification et l'autorisation. JWTs sont des jetons d'accès basés sur JSON utilisés pour accorder un accès par authentification unique (SSO). Vous pouvez utiliser JWTs in OpenSearch Service pour créer des jetons d'authentification unique afin de valider les demandes adressées à votre domaine OpenSearch de service. Pour l'utiliser JWTs, le contrôle d'accès détaillé doit être activé et vous devez fournir une clé publique valide au format RSA ou ECDSA PEM. Pour plus d'informations sur le contrôle d'accès détaillé, consultez la section Contrôle [d'accès détaillé dans Amazon Service](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/fgac.html). OpenSearch
Vous pouvez configurer les jetons Web JSON à l'aide de la console de OpenSearch service, du AWS Command Line Interface (AWS CLI) ou du AWS SDKs.
## Considérations
Avant de l'utiliser JWTs avec Amazon OpenSearch Service, vous devez prendre en compte les points suivants :
+ En raison de la taille des clés publiques RSA au format PEM, nous vous recommandons d'utiliser la AWS console pour configurer l'authentification et l'autorisation JWT.
+ Vous devez fournir des utilisateurs et des rôles valides lorsque vous spécifiez les champs de sujets et de rôles pour vous JWTs, sinon les demandes seront refusées.
+ OpenSearch 2.11 est la première version compatible pouvant être utilisée pour l'authentification JWT.
## Modification de la stratégie d'accès au domaine
Avant de configurer votre domaine pour utiliser l'authentification et l'autorisation JWT, vous devez mettre à jour votre politique d'accès au domaine afin de permettre aux utilisateurs JWT d'accéder au domaine. Dans le cas contraire, toutes les demandes autorisées entrantes de JWT sont refusées. La politique d'accès au domaine recommandée pour fournir un accès complet aux sous-ressources (/\$1) est la suivante :
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "*"
},
"Action": "es:ESHttp*",
"Resource": "arn:aws:es:us-east-1:111122223333:domain/domain-name/*"
}
]
}
```
------
## Configuration de l'authentification et de l'autorisation JWT
Vous pouvez activer l'authentification et l'autorisation JWT pendant le processus de création du domaine ou en mettant à jour un domaine existant. Les étapes de configuration varient légèrement en fonction de l'option choisie.
Les étapes suivantes expliquent comment configurer un domaine existant pour l'authentification et l'autorisation JWT dans la console de OpenSearch service :
1. Sous **Configuration du domaine**, accédez à **Authentification et autorisation JWT pour OpenSearch**, sélectionnez **Activer l'authentification et l'autorisation JWT**.
1. Configurez la clé publique à utiliser pour votre domaine. Pour ce faire, vous pouvez soit télécharger un fichier PEM contenant une clé publique, soit le saisir manuellement.
**Note**
Si la clé téléchargée ou saisie n'est pas valide, un avertissement apparaît au-dessus de la zone de texte indiquant le problème.
1. (Facultatif) Sous Paramètres supplémentaires, vous pouvez configurer les champs facultatifs suivants
+ **Clé d'objet** : vous pouvez laisser ce champ vide pour utiliser la `sub` clé par défaut pour votre JWTs.
+ **Clé des rôles** : vous pouvez laisser ce champ vide pour utiliser la `roles` clé par défaut pour votre JWTs.
Une fois que vous avez apporté vos modifications, enregistrez votre domaine.
## Utiliser un JWT pour envoyer une demande de test
Après avoir créé un nouveau JWT avec une paire sujet/rôle spécifiée, vous pouvez envoyer une demande de test. Pour ce faire, utilisez la clé privée pour signer votre demande via l'outil qui a créé le JWT. OpenSearch Le service est en mesure de valider la demande entrante en vérifiant cette signature.
**Note**
Si vous avez spécifié une clé de sujet ou une clé de rôle personnalisée pour votre JWT, vous devez utiliser les noms de réclamation corrects pour votre JWT.
Voici un exemple d'utilisation d'un jeton JWT pour accéder au OpenSearch service via le point de terminaison de recherche de votre domaine :
```
curl -XGET "$search_endpoint" -H "Authorization: Bearer "
```
### Configuration de l'authentification et de l'autorisation JWT ()AWS CLI
La AWS CLI commande suivante active l'authentification et l'autorisation JWT à OpenSearch condition que le domaine existe :
```
aws opensearch update-domain-config --domain-name --advanced-security-options '{"JWTOptions":{"Enabled":true, "PublicKey": "", "SubjectKey": "", "RolesKey": ""}}'
```
#### Configuration de l'authentification et de l'autorisation JWT (configuration via API)
La demande suivante adressée à l'API de configuration active l'authentification et l'autorisation JWT OpenSearch sur un domaine existant :
```
POST https://es.us-east-1.amazonaws.com/2021-01-01/opensearch/domain/my-domain/config
{
"AdvancedSecurityOptions": {
"JWTOptions": {
"Enabled": true,
"PublicKey": "public-key",
"RolesKey": "optional-roles-key",
"SubjectKey": "optional-subject-key"
}
}
}
```
##### Génération d'une paire de clés
JWTs Pour configurer votre OpenSearch domaine, vous devez fournir une clé publique au format PEM (Privacy-Enhanced Mail). Amazon OpenSearch Service prend actuellement en charge deux algorithmes de chiffrement asymétriques lors de l'utilisation JWTs : RSA et ECDSA.
Pour créer une paire de clés RSA à l'aide de la bibliothèque openssl commune, procédez comme suit :
1. `openssl genrsa -out privatekey.pem 2048`
1. `openssl rsa -in privatekey.pem -pubout -out publickey.pem`
Dans cet exemple, le `publickey.pem` fichier contient la clé publique à utiliser avec Amazon OpenSearch Service, tandis que `privatekey.pem` le fichier privé permet de signer la clé JWTs envoyée au service. De plus, vous avez la possibilité de convertir la clé privée dans le `pkcs8` format couramment utilisé si vous en avez besoin pour générer votre JWTs.
Si vous utilisez le bouton de téléchargement pour ajouter un fichier PEM directement à la console, le fichier doit avoir une `.pem` extension, d'autres extensions de fichier telles que `.crt``.cert`, ou ne `.key` sont pas prises en charge pour le moment.
# Sécurité de l'infrastructure dans Amazon OpenSearch Service
En tant que service géré, il est protégé par la sécurité du réseau AWS mondial. Pour plus d'informations sur les services AWS de sécurité et sur la manière dont AWS l'infrastructure est protégée, consultez la section [Sécurité du AWS cloud](https://aws.amazon.com/security/). Pour concevoir votre AWS environnement en utilisant les meilleures pratiques en matière de sécurité de l'infrastructure, consultez la section [Protection de l'infrastructure](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/infrastructure-protection.html) dans le cadre * AWS bien architecturé du pilier de sécurité*.
Vous utilisez des appels d'API AWS publiés pour accéder via le réseau. Les clients doivent prendre en charge les éléments suivants :
+ Protocole TLS (Transport Layer Security). Nous exigeons TLS 1.2 et recommandons TLS 1.3.
+ Ses suites de chiffrement PFS (Perfect Forward Secrecy) comme DHE (Ephemeral Diffie-Hellman) ou ECDHE (Elliptic Curve Ephemeral Diffie-Hellman). La plupart des systèmes modernes tels que Java 7 et les versions ultérieures prennent en charge ces modes.
Vous utilisez des appels d'API AWS publiés pour accéder à l'API de configuration du OpenSearch service via le réseau. Pour configurer la version TLS minimale requise à accepter, spécifiez la valeur `TLSSecurityPolicy` dans les options de point de terminaison de domaine :
```
aws opensearch update-domain-config --domain-name my-domain --domain-endpoint-options '{"TLSSecurityPolicy": "Policy-Min-TLS-1-2-2019-07"}'
```
Pour plus d'informations, veuillez consulter la [Référence des commandes de l'AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/opensearch/update-domain-config.html).
En fonction de la configuration de votre domaine, vous devrez peut-être également signer des demandes au OpenSearch APIs. Pour de plus amples informations, veuillez consulter [Formulation et signature de demandes OpenSearch de service](managedomains-signing-service-requests.md).
OpenSearch Le service prend en charge les domaines d'accès public, qui peuvent recevoir des demandes depuis n'importe quel appareil connecté à Internet, et les [domaines d'accès VPC](vpc.md), qui sont isolés de l'Internet public.
# Accédez à Amazon OpenSearch Service à l'aide d'un point de terminaison OpenSearch VPC géré par le service ()AWS PrivateLink
Vous pouvez accéder à un domaine Amazon OpenSearch Service en configurant un point de terminaison OpenSearch VPC géré par le service (alimenté par). AWS PrivateLink Ces points de terminaison créent une connexion privée entre votre VPC et Amazon OpenSearch Service. Vous pouvez accéder aux domaines OpenSearch Service VPC comme s'ils se trouvaient dans votre VPC, sans utiliser de passerelle Internet, de périphérique NAT, de connexion VPN ou de connexion. Direct Connect Les instances de votre VPC n'ont pas besoin d'adresses IP publiques pour accéder OpenSearch au service.
Vous pouvez configurer les domaines de OpenSearch service pour exposer des points de terminaison supplémentaires s'exécutant sur des sous-réseaux publics ou privés au sein d'un même VPC, d'un VPC différent ou d'un autre. Comptes AWS Cela vous permet d'ajouter une couche de sécurité supplémentaire pour accéder à vos domaines, quel que soit leur emplacement d'exécution, sans aucune infrastructure à gérer. Le schéma suivant illustre les points de terminaison OpenSearch VPC gérés par le service au sein d'un même VPC :
![\[VPC diagram showing Amazon PrivateLink in public subnet connecting to OpenSearch Service in private subnet.\]](http://docs.aws.amazon.com/fr_fr/opensearch-service/latest/developerguide/images/Privatelink-Diagram.png)
Vous établissez cette connexion privée en créant un point de *terminaison VPC OpenSearch * d'interface géré par le service, alimenté par. AWS PrivateLink Nous créons une interface réseau du point de terminaison dans chaque sous-réseau que vous activez pour le point de terminaison d'un VPC d'interface. Il s'agit d'interfaces réseau gérées par des services qui servent de point d'entrée pour le trafic destiné OpenSearch au service. La [tarification standard des points de terminaison d'AWS PrivateLink interface](https://aws.amazon.com/privatelink/pricing/) s'applique aux points de terminaison VPC gérés par le OpenSearch service facturés en vertu de. AWS PrivateLink
Vous pouvez créer des points de terminaison VPC pour les domaines exécutant toutes les versions d'Elasticsearch OpenSearch et les anciennes versions. Pour plus d’informations, consultez [Accès aux Services AWS via AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/privatelink-access-aws-services.html) dans le *Guide AWS PrivateLink *.
## Considérations et limites relatives au OpenSearch service
*Avant de configurer un point de terminaison VPC d'interface pour le OpenSearch service, consultez la section [Accès à un AWS service à l'aide d'un point de terminaison VPC d'](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html)interface dans le Guide.AWS PrivateLink *
Lorsque vous utilisez des points de OpenSearch terminaison VPC gérés par des services, tenez compte des points suivants :
+ Vous ne pouvez utiliser les points de terminaison d'un VPC d'interface que pour vous connecter à des [domaines VPC](vpc.md). Les domaines publics ne sont pas pris en charge.
+ Les points de terminaison d'un VPC ne peuvent se connecter qu'à des domaines au sein de la même Région AWS.
+ Le protocole HTTPS est le seul protocole pris en charge pour les points de terminaison d'un VPC. Le protocole HTTP n'est pas autorisé.
+ OpenSearch Le service permet d'appeler toutes les [opérations d' OpenSearch API prises en charge](supported-operations.md) via un point de terminaison VPC d'interface.
+ Vous pouvez configurer jusqu'à 50 points de terminaison par compte et jusqu'à 10 points de terminaison par domaine. Un seul domaine peut disposer de 10 [principaux autorisés](#vpc-endpoint-access) au maximum.
+ Vous ne pouvez actuellement pas l'utiliser AWS CloudFormation pour créer des points de terminaison VPC d'interface.
+ [Vous ne pouvez créer des points de terminaison VPC d'interface que via la console de OpenSearch service ou à l'aide de l'OpenSearch API de service.](https://docs.aws.amazon.com/opensearch-service/latest/APIReference/Welcome.html) Vous ne pouvez pas créer de points de terminaison VPC d'interface pour OpenSearch Service à l'aide de la console Amazon VPC.
+ OpenSearch Les points de terminaison VPC gérés par des services ne sont pas accessibles depuis Internet. Un point de OpenSearch terminaison VPC géré par un service n'est accessible que dans le VPC où le point de terminaison est provisionné ou dans tout autre VPC apparenté au VPC où le point de VPCs terminaison est provisionné, comme le permettent les tables de routage et les groupes de sécurité.
+ Les politiques de point de terminaison VPC ne sont pas prises en charge pour le service OpenSearch . Vous pouvez associer un groupe de sécurité aux interfaces réseau du point de terminaison pour contrôler le trafic vers le OpenSearch service via le point de terminaison VPC de l'interface.
+ Votre [rôle lié à un service doit figurer](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/slr.html) dans le même AWS compte que celui que vous utilisez pour créer le point de terminaison VPC.
+ Pour créer, mettre à jour et supprimer le point de terminaison OpenSearch Service VPC, vous devez disposer des autorisations Amazon EC2 suivantes en plus de vos autorisations Amazon OpenSearch Service :
+ `ec2:CreateVpcEndpoint`
+ `ec2:DescribeVpcEndpoints`
+ `ec2:ModifyVpcEndpoint`
+ `ec2:DeleteVpcEndpoints`
+ `ec2:CreateTags`
+ `ec2:DescribeTags`
+ `ec2:DescribeSubnets`
+ `ec2:DescribeSecurityGroups`
+ `ec2:DescribeVpcs`
**Note**
Actuellement, vous ne pouvez pas limiter la création de points de terminaison VPC au OpenSearch service. Nous nous efforçons de rendre cela possible dans une future mise à jour.
## Fournir un accès à un domaine
Si le VPC auquel vous souhaitez accéder à votre domaine se trouve dans un autre Compte AWS, vous devez l'autoriser depuis le compte du propriétaire avant de pouvoir créer un point de terminaison VPC d'interface.
**Pour autoriser un VPC d'un autre à accéder Compte AWS à votre domaine**
1. Ouvrez la console Amazon OpenSearch Service à l'adresse [https://console.aws.amazon.com/aos/home/](https://console.aws.amazon.com/aos/home/).
1. Dans le panneau de navigation, choisissez **Domains** (Domaines), puis ouvrez le domaine vers lequel vous souhaitez fournir un accès.
1. Accédez à l'onglet **Points de terminaison VPC**, qui affiche les comptes et les comptes correspondants VPCs ayant accès à votre domaine.
1. Choisissez **Authorize principal** (Autoriser le principal).
1. Entrez l' Compte AWS identifiant du compte qui accèdera à votre domaine. Cette étape autorise le compte spécifié à créer des points de terminaison d'un VPC sur le domaine.
1. Choisissez **Authorize** (Autoriser).
## Créer un point de terminaison d'un VPC d'interface pour un domaine VPC
Vous pouvez créer un point de terminaison VPC d'interface pour le OpenSearch service à l'aide de la console OpenSearch de service ou du AWS Command Line Interface ()AWS CLI.
**Pour créer un point de terminaison VPC d'interface pour un domaine de service OpenSearch**
1. Ouvrez la console Amazon OpenSearch Service à l'adresse [https://console.aws.amazon.com/aos/home/](https://console.aws.amazon.com/aos/home/).
1. Dans le panneau de navigation de gauche, sélectionnez **VPC endpoints** (Points de terminaison d'un VPC).
1. Choisissez **Créer un point de terminaison**.
1. Choisissez de connecter un domaine dans le domaine actuel Compte AWS ou dans un autre Compte AWS.
1. Sélectionnez le domaine auquel vous vous connectez à l'aide de ce point de terminaison. Si le domaine est dans le domaine actuel Compte AWS, utilisez le menu déroulant pour le choisir. Si le domaine se trouve sur un autre compte, saisissez l'Amazon Resource Name (ARN) du domaine auquel vous connecter. Pour choisir un domaine sur un autre compte, le propriétaire doit [vous donner accès](#vpc-endpoint-access) au domaine.
1. Pour le **VPC**, sélectionnez le VPC à partir duquel vous allez accéder au service. OpenSearch
1. Pour les **sous-réseaux**, sélectionnez un ou plusieurs sous-réseaux à partir desquels vous allez accéder au OpenSearch service.
1. Pour **Security groups** (Groupes de sécurité), sélectionnez les groupes de sécurité à associer aux interfaces réseau du point de terminaison. Il s'agit d'une étape essentielle au cours de laquelle vous devez limiter les ports, les protocoles et les sources de trafic entrant que vous autorisez dans votre point de terminaison. Les règles du groupe de sécurité doivent autoriser les ressources qui utiliseront le point de terminaison VPC pour communiquer avec le OpenSearch service à communiquer avec l'interface réseau du point de terminaison.
1. Choisissez **Créer un point de terminaison**. Le point de terminaison sera actif au bout de deux à cinq minutes.
## Utilisation de points de terminaison OpenSearch VPC gérés par des services à l'aide de l'API de configuration
Utilisez les opérations d'API suivantes pour créer et gérer des points de terminaison OpenSearch VPC gérés par le service.
+ [CreateVpcEndpoint](https://docs.aws.amazon.com/opensearch-service/latest/APIReference/API_CreateVpcEndpoint.html)
+ [ListVpcEndpoints](https://docs.aws.amazon.com/opensearch-service/latest/APIReference/API_ListVpcEndpoints.html)
+ [UpdateVpcEndpoint](https://docs.aws.amazon.com/opensearch-service/latest/APIReference/API_UpdateVpcEndpoint.html)
+ [DeleteVpcEndpoint](https://docs.aws.amazon.com/opensearch-service/latest/APIReference/API_DeleteVpcEndpoint.html)
Utilisez les opérations d'API suivantes pour gérer l'accès des points de terminaison aux domaines VPC :
+ [AuthorizeVpcEndpointAccess](https://docs.aws.amazon.com/opensearch-service/latest/APIReference/API_AuthorizeVpcEndpointAccess.html)
+ [ListVpcEndpointAccess](https://docs.aws.amazon.com/opensearch-service/latest/APIReference/API_ListVpcEndpointAccess.html)
+ [ListVpcEndpointsForDomain](https://docs.aws.amazon.com/opensearch-service/latest/APIReference/API_ListVpcEndpointsForDomain.html)
+ [RevokeVpcEndpointAccess](https://docs.aws.amazon.com/opensearch-service/latest/APIReference/API_RevokeVpcEndpointAccess.html)
# Authentification SAML pour les tableaux de bord OpenSearch
L'authentification SAML pour les OpenSearch tableaux de bord vous permet d'utiliser votre fournisseur d'identité existant pour proposer l'authentification unique (SSO) pour les tableaux de bord sur les domaines Amazon OpenSearch Service exécutant Elasticsearch 6.7 OpenSearch ou version ultérieure. Pour utiliser l'authentification SAML, vous devez activer le [contrôle précis des accès](fgac.md).
Plutôt que de vous authentifier via [Amazon](cognito-auth.md) Cognito ou [la base de données utilisateur interne](fgac.md#fgac-dashboards), l'authentification SAML OpenSearch pour les tableaux de bord vous permet de faire appel à des fournisseurs d'identité tiers pour vous connecter aux tableaux de bord, gérer un contrôle d'accès précis, effectuer des recherches dans vos données et créer des visualisations. OpenSearch Le service prend en charge les fournisseurs qui utilisent la norme SAML 2.0, tels qu'Okta, Keycloak, Active Directory Federation Services (ADFS), Auth0 et. AWS IAM Identity Center
L'authentification SAML pour les tableaux de bord permet uniquement d'accéder aux OpenSearch tableaux de bord via un navigateur Web. Vos informations d'identification SAML ne vous permettent *pas* de faire des requêtes HTTP directes vers les tableaux de bord OpenSearch ou les tableaux APIs de bord.
## Présentation de la configuration SAML
Cette documentation suppose que vous disposez d'un fournisseur d'identité existant avec lequel vous êtes familier. Nous ne pouvons pas fournir d'étapes de configuration détaillées pour votre fournisseur exact, uniquement pour votre domaine OpenSearch de service.
Le flux de connexion OpenSearch aux tableaux de bord peut prendre l'une des deux formes suivantes :
+ **Fournisseur de services initié** : vous accédez aux Tableaux de bord (par exemple, `https://my-domain.us-east-1.es.amazonaws.com/_dashboards`) , ce qui vous redirige vers l'écran de connexion. Une fois connecté, le fournisseur d'identité vous redirige vers Tableaux de bord.
+ **Initié par le fournisseur d'identité (IdP)** : vous accédez à votre fournisseur d'identité, vous vous connectez et choisissez OpenSearch Dashboards dans un répertoire d'applications.
OpenSearch Le service fournit deux connexions uniques URLs, initiées par le SP et initiées par l'IdP, mais vous n'avez besoin que de celle qui correspond au flux de connexion aux tableaux de bord que vous souhaitez. OpenSearch
Quel que soit le type d'authentification que vous utilisez, l'objectif consiste à vous connecter via votre fournisseur d'identité et à recevoir une assertion SAML contenant votre nom d'utilisateur (obligatoire) et un [rôle backend](fgac.md#fgac-concepts)(facultatif, mais recommandé). Cette information permet au [contrôle précis des accès](fgac.md)d'affecter des autorisations aux utilisateurs SAML. Dans les fournisseurs d'identité externes, les rôles backend sont généralement appelés « rôles » ou « groupes ».
## Considérations
Prenez en compte les éléments suivants lorsque vous configurez l'authentification SAML :
+ En raison de la taille du fichier de métadonnées IdP, nous vous recommandons vivement d'utiliser la AWS console pour configurer l'authentification SAML.
+ Les domaines ne prennent en charge qu'une seule méthode d'authentification Tableaux de bord à la fois. Si l'[authentification Amazon Cognito pour les OpenSearch tableaux](cognito-auth.md) de bord est activée, vous devez la désactiver avant de pouvoir activer l'authentification SAML.
+ Si vous utilisez un équilibreur de charge réseau avec SAML, vous devez d'abord créer un point de terminaison personnalisé. Pour de plus amples informations, veuillez consulter [Création d'un point de terminaison personnalisé pour Amazon OpenSearch Service](customendpoint.md).
+ Les politiques de contrôle des services (SCP) ne seront pas applicables ni évaluées dans le cas d'identités non IAM (comme le SAML dans OpenSearch Amazon Serverless et SAML et l'autorisation utilisateur interne de base pour Amazon Service). OpenSearch
## Authentification SAML pour les domaines VPC
SAML ne nécessite pas de communication directe entre votre fournisseur d'identité et votre fournisseur de services. Par conséquent, même si votre OpenSearch domaine est hébergé dans un VPC privé, vous pouvez toujours utiliser le protocole SAML tant que votre navigateur peut communiquer à la fois avec votre OpenSearch cluster et avec votre fournisseur d'identité. Votre navigateur joue essentiellement le rôle d'intermédiaire entre votre fournisseur d'identité et votre fournisseur de services. Pour un diagramme utile qui explique le flux d'authentification SAML, consultez la [documentation d'Okta](https://developer.okta.com/docs/concepts/saml/#planning-for-saml).
## Modification de la stratégie d'accès au domaine
Avant de configurer l'authentification SAML, vous devez mettre à jour la stratégie d'accès au domaine afin d'autoriser les utilisateurs SAML à y accéder. Sinon, vous recevrez des erreurs d'accès refusé.
Nous recommandons la [stratégie d'accès au domaine](ac.md#ac-types-resource) suivante, qui fournit un accès complet aux sous-ressources (`/*`) du domaine :
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "*"
},
"Action": "es:ESHttp*",
"Resource": "arn:aws:es:us-east-1:111122223333:domain/domain-name/*"
}
]
}
```
------
Pour rendre la politique plus restrictive, vous pouvez y ajouter une condition d'adresse IP. Cette condition limite l'accès uniquement à la plage d'adresses IP ou au sous-réseau spécifié. Par exemple, la politique suivante autorise l'accès uniquement depuis le sous-réseau 192.0.2.0/24 :
------
#### [ 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-east-1:111122223333:domain/domain-name/*"
}
]
}
```
------
**Note**
Une politique d'accès aux domaines ouverts nécessite l'activation d'un contrôle d'accès précis sur votre domaine. Dans le cas contraire, le message d'erreur suivant s'affiche :
`To protect domains with public access, a restrictive policy or fine-grained access control is required.`
Si vous avez un utilisateur principal ou un utilisateur interne configuré avec un mot de passe robuste, il peut être acceptable de maintenir la politique ouverte tout en utilisant un contrôle d'accès précis du point de vue de la sécurité. Pour de plus amples informations, veuillez consulter [Contrôle d'accès précis dans Amazon Service OpenSearch](fgac.md).
## Configuration de l'authentification initiée par le fournisseur de services ou le fournisseur d'identité
Ces étapes expliquent comment activer l'authentification SAML avec une authentification initiée par le SP *ou* par l'IdP pour les tableaux de bord. OpenSearch Pour l'étape supplémentaire nécessaire pour activer les deux, consultez [Activer l'authentification initiée par le SP et l'IdP](#saml-idp-with-sp).
### Étape 1 : activer l'authentification SAML
Vous pouvez activer l'authentification SAML soit lors de la création du domaine, soit en choisissant **Actions**, **Edit security configuration** (Modifier la configuration de sécurité) sur un domaine existant. Les étapes suivantes varient légèrement en fonction de celle que vous choisissez.
**Dans la configuration du domaine, sous Authentification **SAML pour les OpenSearch tableaux de bords/Kibana, sélectionnez Activer l'authentification** SAML.**
### Étape 2 : configurer votre fournisseur d'identité
Suivez les étapes suivantes en fonction du moment où vous configurez l'authentification SAML.
#### En cas de création d'un nouveau domaine
Si vous êtes en train de créer un nouveau domaine, OpenSearch Service ne peut pas encore générer d'identifiant d'entité ou de SSO URLs pour le fournisseur de services. Votre fournisseur d'identité a besoin de ces valeurs afin d'activer correctement l'authentification SAML, mais elles ne peuvent être générées qu'après la création du domaine. Pour contourner cette interdépendance lors de la création du domaine, vous pouvez fournir des valeurs temporaires dans votre configuration IdP afin de générer les métadonnées requises, puis les mettre à jour une fois que votre domaine est actif.
Si vous utilisez un point de [terminaison personnalisé](customendpoint.md), vous pouvez en déduire ce qu'il URLs sera. Par exemple, si votre point de terminaison personnalisé est `www.custom-endpoint.com`, l'ID d'entité du fournisseur de services sera `www.custom-endpoint.com`, l'adresse URL SSO initiée par l'IdP sera `www.custom-endpoint.com/_dashboards/_opendistro/_security/saml/acs/idpinitiated` et l'adresse URL SSO initiée par le SP sera `www.custom-endpoint.com/_dashboards/_opendistro/_security/saml/acs`. Vous pouvez utiliser ces valeurs pour configurer votre fournisseur d'identité avant la création du domaine. Consultez la section suivante pour examiner des exemples.
**Note**
Vous ne pouvez pas vous connecter avec un point de terminaison à double pile car le nom de domaine complet d'une requête HTTP est différent du nom de domaine complet d'une demande SAML. Un OpenSearch administrateur devra configurer un point de terminaison personnalisé et définir la valeur CNAME sur un point de terminaison à double pile si vous souhaitez vous connecter à l'aide d'un point de terminaison à double pile.
Si vous n'utilisez pas de point de terminaison personnalisé, vous pouvez saisir des valeurs *temporaires* dans votre IdP pour générer les métadonnées requises, puis les mettre à jour ultérieurement une fois le domaine actif.
Par exemple, dans Okta, vous pouvez saisir `https://temp-endpoint.amazonaws.com` dans les champs **Single sign on URL** (Adresse URL de l'authentification unique) et **Audience URI (SP Entity ID)** (URI de l'audience (ID d'entité du SP )), ce qui vous permet de générer les métadonnées. Ensuite, une fois le domaine actif, vous pouvez récupérer les valeurs correctes auprès de OpenSearch Service et les mettre à jour dans Okta. Pour obtenir des instructions, veuillez consulter [Étape 6 : mettez à jour votre IdP URLs](#saml-update-urls).
#### En cas de modification d'un domaine existant
Si vous activez l'authentification SAML sur un domaine existant, copiez l'ID d'entité du fournisseur de services et l'un des URLs SSO. Pour obtenir des conseils sur l'adresse URL à utiliser, consultez [Présentation de la configuration SAML](#saml-overview).
![\[Service provider entity ID and SSO URLs for SAML authentication configuration.\]](http://docs.aws.amazon.com/fr_fr/opensearch-service/latest/developerguide/images/SAML.png)
Utilisez les valeurs pour configurer votre fournisseur d'identité. Il s'agit-là de la partie la plus complexe du processus, et malheureusement, la terminologie de même que la procédure changent considérablement d'un fournisseur à l'autre. Consultez la documentation de votre fournisseur.
Dans Okta, par exemple, vous créez une application Web SAML 2.0. Pour **Single sign on URL** (Adresse URL de l'authentification unique), spécifiez l'adresse URL SSO. Pour**URI du public ciblé (ID d'entité du fournisseur de services)**, spécifiez l'ID d'entité du fournisseur de services.
Plutôt que d'utilisateurs et de rôles backend, Okta parle d'utilisateurs et de groupes. Pour **Group Attribute Statements** (Instructions d'attributs de groupe), nous vous recommandons d'ajouter `role` au champ **Name** (Nom) et l'expression régulière `.+` au champ **Filter** (Filtrer). Cette instruction indique au fournisseur d'identité Okta d'inclure tous les groupes d'utilisateurs sous le champ `role` de l'assertion SAML après l'authentification d'un utilisateur.
Dans IAM Identity Center, vous spécifiez l'ID de l'entité SP en tant qu'audience **SAML de l'application**. Vous devez également spécifier les [mappages d'attributs](https://docs.aws.amazon.com/singlesignon/latest/userguide/attributemappingsconcept.html) suivants : `Subject=${user:subject}:format=unspecified` et`Role=${user:groups}:format=uri`.
Dans Auth0, vous créez une application Web normale et activez le module complémentaire SAML 2.0. Dans Keycloak, vous créez un client.
### Étape 3 : importer les métadonnées IdP
Une fois votre fournisseur d'identité configuré, il génère un fichier de métadonnées de fournisseur d'identité. Ce fichier XML contient des informations sur le fournisseur, telles qu'un certificat TLS, des points de terminaison d'authentification unique et l'ID d'entité du fournisseur d'identité.
Copiez le contenu du fichier de métadonnées IdP et collez-le dans le champ **Métadonnées depuis l'IdP** de la console de service. OpenSearch Vous pouvez également choisir **Importer depuis un fichier XML**, puis charger le fichier. Le fichier de métadonnées doit se présenter comme suit :
```
tls-certificate
urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified
urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
```
### Étape 4 : configurer les champs SAML
Après avoir saisi les métadonnées de votre IdP, configurez les champs supplémentaires suivants dans la console de OpenSearch service :
+ **IdP entity ID** (Identifiant d'entité du IdP) : copiez la valeur de la propriété `entityID` depuis votre fichier de métadonnées et collez-la dans ce champ. De nombreux fournisseurs d'identité affichent également cette valeur dans le cadre d'un résumé post-configuration. Certains fournisseurs l'appellent « auteur ».
+ **Nom d'utilisateur principal SAML** **et rôle principal de backend SAML : le rôle** d'utilisateur and/or principal que vous spécifiez reçoit des autorisations complètes sur le cluster, équivalentes à celles d'un [nouvel utilisateur principal](fgac.md#fgac-more-masters), mais ne peut utiliser ces autorisations que dans les tableaux de bord. OpenSearch
Dans Okta, par exemple, il peut s'agir d'un utilisateur `jdoe`qui appartient au groupe`admins`. Si vous ajoutez `jdoe` au champ **Nom d'utilisateur principal SAML**, seul cet utilisateur reçoit des autorisations complètes. Si vous ajoutez `admins` au champ rôle backend principal SAML, tout utilisateur appartenant au groupe `admins` reçoit des autorisations complètes.
**Note**
Le contenu de l'assertion SAML doit correspondre exactement aux chaînes que vous utilisez pour le nom d'utilisateur principal SAML et le rôle principal SAML. Certains fournisseurs d'identité ajoutent un préfixe avant leur nom d'utilisateur, ce qui peut entraîner une hard-to-diagnose incompatibilité. Dans l'interface utilisateur du fournisseur d'identité, vous pouvez voir `jdoe`, mais l'assertion SAML peut contenir `auth0|jdoe`. Utilisez toujours la chaîne de l'assertion SAML.
De nombreux fournisseurs d'identité vous permettent d'afficher un exemple d'assertion lors du processus de configuration, et des outils tels que [SAML-tracer](https://addons.mozilla.org/en-US/firefox/addon/saml-tracer/) peuvent vous aider à examiner et à résoudre le contenu des assertions. Les assertions se présentent comme suit :
```
idp-issuer
username
domain-endpoint
urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
GroupName Match Matches regex ".+" (case-sensitive)
```
### Étape 5 : (Facultatif) configurer des paramètres supplémentaires
Sous **Additional settings** (Paramètres supplémentaires), configurez les champs facultatifs suivants :
+ **Subject key** (Clé d'objet) : vous pouvez laisser ce champ vide pour utiliser l'élément `NameID` de l'assertion SAML pour le nom d'utilisateur. Si votre assertion n'utilise pas cet élément standard et inclut plutôt le nom d'utilisateur comme attribut personnalisé, spécifiez cet attribut ici.
+ **Roles key** (Clé de rôles) : si vous voulez utiliser des rôles backend (recommandé), spécifiez un attribut de l'assertion dans ce champ, tel que `role` ou `group`. Là encore, un outil tel que [SAML-tracer](https://addons.mozilla.org/en-US/firefox/addon/saml-tracer/) peut vous être utile.
+ **Durée de vie de la session** : par défaut, OpenSearch Dashboards déconnecte les utilisateurs au bout de 24 heures. Vous pouvez configurer cette valeur sur n'importe quel nombre compris entre 60 et 1 440 (24 heures) en spécifiant une nouvelle valeur.
Une fois que la configuration vous convient, enregistrez le domaine.
### Étape 6 : mettez à jour votre IdP URLs
Si vous avez [activé l'authentification SAML lors de la création d'un domaine](#saml-configure-new), vous deviez spécifier une URLs valeur temporaire dans votre IdP afin de générer le fichier de métadonnées XML. Une fois que le statut du domaine est `Active` passé à, vous pouvez obtenir le bon URLs identifiant et modifier votre IdP.
Pour les récupérer URLs, sélectionnez le domaine et choisissez **Actions**, **Modifier la configuration de sécurité**. Dans le cadre de **l'authentification SAML pour OpenSearch Dashboards/Kibana**, vous pouvez trouver l'ID d'entité et le SSO du fournisseur de services corrects. URLs Copiez les valeurs et utilisez-les pour configurer votre fournisseur d'identité, en remplaçant le temporaire URLs que vous avez fourni à l'étape 2.
### Étape 7 : associer les utilisateurs SAML aux rôles
Une fois que le statut de votre domaine est actif et que votre IdP est correctement configuré, accédez à OpenSearch Tableaux de bord.
+ Si vous avez choisi l'URL initiée par le fournisseur de services, accédez à `domain-endpoint/_dashboards`. Pour vous connecter directement à un locataire spécifique, vous pouvez ajouter `?security_tenant=tenant-name` à l'adresse URL.
+ Si vous avez choisi l'URL initiée par le fournisseur d'identité, accédez au répertoire d'applications de votre fournisseur d'identité.
Dans les deux cas, connectez-vous en tant qu'utilisateur principal SAML ou en tant qu'utilisateur appartenant au rôle backend SAML. Pour continuer l'exemple de l'étape 7, connectez-vous en tant que `jdoe` ou un membre du groupe `admins`.
Une fois OpenSearch les tableaux de bord chargés, choisissez **Sécurité**, **Rôles**. [Mappez ensuite les rôles](fgac.md#fgac-mapping) pour permettre aux autres utilisateurs d'accéder aux OpenSearch tableaux de bord.
Par exemple, vous pouvez mapper un collègue de confiance `jroe` aux rôles `all_access` et `security_manager`. Vous pouvez également mapper le rôle backend `analysts` aux rôles `readall` et `opensearch_dashboards_user`.
Si vous préférez utiliser l'API plutôt que les OpenSearch tableaux de bord, consultez l'exemple de demande suivant :
```
PATCH _plugins/_security/api/rolesmapping
[
{
"op": "add", "path": "/security_manager", "value": { "users": ["master-user", "jdoe", "jroe"], "backend_roles": ["admins"] }
},
{
"op": "add", "path": "/all_access", "value": { "users": ["master-user", "jdoe", "jroe"], "backend_roles": ["admins"] }
},
{
"op": "add", "path": "/readall", "value": { "backend_roles": ["analysts"] }
},
{
"op": "add", "path": "/opensearch_dashboards_user", "value": { "backend_roles": ["analysts"] }
}
]
```
## Configuration de l'authentification initiée à la fois par le SP et l'IdP
Si vous souhaitez configurer l'authentification initiée par le fournisseur de services et le fournisseur d'identité, vous devez le faire via votre fournisseur d'identité. Par exemple, dans Okta, vous pouvez effectuer les étapes suivantes :
1. Dans votre application SAML, accédez à **General** (Général), **SAML settings** (Paramètres SAML).
1. Pour **Single sign on URL** (URL d'authentification unique), fournissez votre URL SSO initiée par l'*IdP*. Par exemple, `https://search-domain-hash/_dashboards/_opendistro/_security/saml/acs/idpinitiated`.
1. Activez **Autoriser cette application à demander un autre SSO URLs**.
1. Sous SSO **requestable URLs, ajoutez un ou plusieurs SSO** initiés par le *SP*. URLs Par exemple, `https://search-domain-hash/_dashboards/_opendistro/_security/saml/acs`.
## Configuration de l'authentification SAML (AWS CLI)
La AWS CLI commande suivante active l'authentification SAML pour les OpenSearch tableaux de bord sur un domaine existant :
```
aws opensearch update-domain-config \
--domain-name my-domain \
--advanced-security-options '{"SAMLOptions":{"Enabled":true,"MasterUserName":"my-idp-user","MasterBackendRole":"my-idp-group-or-role","Idp":{"EntityId":"entity-id","MetadataContent":"metadata-content-with-quotes-escaped"},"RolesKey":"optional-roles-key","SessionTimeoutMinutes":180,"SubjectKey":"optional-subject-key"}}'
```
Vous devez utiliser une séquence d'échappement sur tous les guillemets et caractères de nouvelle ligne dans le fichier XML des métadonnées. Par exemple, utilisez `\n` plutôt que `` et un saut de ligne. Pour plus d'informations sur l'utilisation de la AWS CLI, consultez[Référence des commandes AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/).
## Configuration de l'authentification SAML (API de configuration)
La demande suivante adressée à l'API de configuration active l'authentification SAML pour les OpenSearch tableaux de bord sur un domaine existant :
```
POST https://es.us-east-1.amazonaws.com/2021-01-01/opensearch/domain/my-domain/config
{
"AdvancedSecurityOptions": {
"SAMLOptions": {
"Enabled": true,
"MasterUserName": "my-idp-user",
"MasterBackendRole": "my-idp-group-or-role",
"Idp": {
"EntityId": "entity-id",
"MetadataContent": "metadata-content-with-quotes-escaped"
},
"RolesKey": "optional-roles-key",
"SessionTimeoutMinutes": 180,
"SubjectKey": "optional-subject-key"
}
}
}
```
Vous devez utiliser une séquence d'échappement sur tous les guillemets et caractères de nouvelle ligne dans le fichier XML des métadonnées. Par exemple, utilisez `\n` plutôt que `` et un saut de ligne. Pour obtenir des informations détaillées sur l'utilisation de l'API de configuration, consultez la [référence de l'API de OpenSearch service](https://docs.aws.amazon.com/opensearch-service/latest/APIReference/API_Welcome.html).
## Résolution des problèmes SAML
| Erreur | Détails |
| --- | --- |
| Votre demande : « */some/path* » n'est pas autorisée. | Vérifiez que vous avez fourni l'[URL d'authentification unique](#saml-enable) qui convient (étape 3) à votre fournisseur d'identité. |
| Fournissez un document de métadonnées de fournisseur d'identité valide pour activer SAML. | Le fichier de métadonnées de votre fournisseur d'identité n'est pas conforme à la norme SAML 2.0. Recherchez les erreurs à l'aide d'un outil de validation. |
| Les options de configuration SAML ne sont pas visibles dans la console. | Procédez à une mise à jour vers la dernière version du [logiciel de service](service-software.md). |
| Erreur de configuration SAML : un problème est survenu lors de la récupération de la configuration SAML, vérifiez vos paramètres. | Cette erreur générique peut se produire pour de nombreuses raisons. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/opensearch-service/latest/developerguide/saml.html) |
| Rôle manquant : aucun rôle n'est disponible pour cet utilisateur, contactez votre administrateur système. | Vous vous êtes authentifié avec succès, mais le nom d'utilisateur et les rôles backend de l'assertion SAML ne sont mappés à aucun rôle et ne disposent donc aucune autorisation. Ces mappages sont sensibles à la casse. Votre administrateur système peut vérifier le contenu de votre assertion SAML à l'aide d'un outil tel que [SAML-Tracer](https://addons.mozilla.org/en-US/firefox/addon/saml-tracer/), puis vérifier le mappage de vos rôles à l'aide de la requête suivante : GET _plugins/_security/api/rolesmapping
|
| Votre navigateur redirige ou reçoit en permanence des erreurs HTTP 500 lorsqu'il essaie d'accéder aux OpenSearch tableaux de bord. | Ces erreurs peuvent se produire si votre assertion SAML contient un grand nombre de rôles totalisant approximativement 1 500 caractères. Par exemple, si vous transmettez 80 rôles, dont la longueur moyenne est de 20 caractères, vous pouvez dépasser la limite de taille des cookies dans votre navigateur Web. À partir de OpenSearch la version 2.7, l'assertion SAML prend en charge les rôles de 5 000 caractères maximum. |
| Vous ne pouvez pas vous déconnecter d'ADFS. | ADFS exige que toutes les demandes de déconnexion soient signées, ce que le OpenSearch service ne prend pas en charge. ``Supprimez-le du fichier de métadonnées IdP pour obliger le OpenSearch service à utiliser son propre mécanisme de déconnexion interne. |
| `Could not find entity descriptor for __PATH__.` | L'ID d'entité de l'IdP fourni dans les métadonnées XML à OpenSearch Service est différent de celui indiqué dans la réponse SAML. Pour résoudre ce problème, assurez-vous qu'ils correspondent. Activez les **journaux d'erreurs d'application CW** sur votre domaine pour trouver le message d'erreur permettant de résoudre le problème d'intégration SAML. |
| `Signature validation failed. SAML response rejected.` | OpenSearch Le service n'est pas en mesure de vérifier la signature dans la réponse SAML à l'aide du certificat de l'IdP fourni dans les métadonnées XML. Il peut s'agir d'une erreur manuelle ou d'une rotation de certificat de votre IdP. Mettez à jour le dernier certificat de votre IdP dans les métadonnées XML fournies au OpenSearch Service via le. AWS Management Console |
| `__PATH__ is not a valid audience for this response.` | Le champ d'audience de la réponse SAML ne correspond pas au point de terminaison du domaine. Pour corriger cette erreur, mettez à jour le champ d'audience SP pour qu'il corresponde au point de terminaison de votre domaine. Si vous avez activé les points de terminaison personnalisés, le champ d'audience doit correspondre à votre point de terminaison personnalisé. Activez les **journaux d'erreurs d'application CW** sur votre domaine pour trouver le message d'erreur permettant de résoudre le problème d'intégration SAML. |
| Votre navigateur reçoit une erreur HTTP 400 `Invalid Request Id` dans la réponse. | Cette erreur se produit généralement si vous avez configuré l'URL initiée par l'IdP avec le format. `/_opendistro/_security/saml/acs` Configurez plutôt l'URL avec le format`/_opendistro/_security/saml/acs/idpinitiated`. |
| La réponse a été reçue à la `__PATH__` place de`__PATH__`. | Le champ de destination de la réponse SAML ne correspond à aucun des formats d'URL suivants : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/opensearch-service/latest/developerguide/saml.html) Selon le flux de connexion que vous utilisez (initié par le SP ou par l'IdP), entrez dans un champ de destination correspondant à l'un des. OpenSearch URLs |
| La réponse comporte un `InResponseTo` attribut, alors qu'aucun attribut n'`InResponseTo`était attendu. | Vous utilisez l'URL initiée par l'IdP pour un flux de connexion initié par le SP. Utilisez plutôt l'URL initiée par le SP. |
## Désactivation de l'authentification SAML
**Pour désactiver l'authentification SAML pour les OpenSearch tableaux de bord (console)**
1. Choisissez le domaine, **Actions**, et **Edit security configuration(Modifier la configuration de la sécurité)**.
1. Décochez **Activer l'authentification SAML**.
1. Sélectionnez **Enregistrer les modifications**.
1. Une fois le traitement terminé, vérifiez le mappage de rôles du contrôle précis des accès à l'aide de la demande suivante :
```
GET _plugins/_security/api/rolesmapping
```
La désactivation de l'authentification SAML pour les tableaux de bord ne supprime *pas* les mappages entre le nom d'utilisateur and/or principal SAML et le rôle principal principal SAML. Pour supprimer ces mappages, connectez-vous aux Tableaux de bord à l'aide de la base de données utilisateur interne (si elle est activée) ou utilisez l'API pour les supprimer :
```
PUT _plugins/_security/api/rolesmapping/all_access
{
"users": [
"master-user"
]
}
```
# Support de propagation d'identité fiable d'IAM Identity Center pour OpenSearch
Vous pouvez désormais utiliser les principaux de votre centre d'identité AWS IAM configuré de manière centralisée (utilisateurs et groupes) via [Trusted Identity Propagation pour accéder](https://docs.aws.amazon.com/singlesignon/latest/userguide/trustedidentitypropagation-overview.html) aux domaines Amazon OpenSearch Service via des applications de [ OpenSearch service](application.md). Pour activer la prise en charge d'IAM Identity Center OpenSearch, vous devez activer l'utilisation d'IAM Identity Center. Pour en savoir plus sur la procédure à suivre, voir [Qu'est-ce qu'IAM](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html) Identity Center ? . Voir [Comment associer un OpenSearch domaine en tant que source de données dans les OpenSearch applications ?](application.md) pour plus de détails.
Vous pouvez configurer IAM Identity Center à l'aide de la console de OpenSearch service, du AWS Command Line Interface (AWS CLI) ou du AWS SDKs.
**Note**
Les principaux centres d'identité IAM ne sont pas pris en charge par le biais de [tableaux de bord (situés au même endroit que le cluster)](dashboards.md). Ils ne sont pris en charge que via [une interface OpenSearch utilisateur centralisée (tableaux de bord).](application.md)
## Considérations
Avant d'utiliser IAM Identity Center avec Amazon OpenSearch Service, vous devez prendre en compte les points suivants :
+ Le centre d'identité IAM est activé dans le compte.
+ Le centre d'identité IAM est disponible dans votre [région.](opensearch-ui-endpoints-quotas.md)
+ La version du OpenSearch domaine est 1.3 ou ultérieure.
+ [Le contrôle d'accès détaillé](fgac.md) est activé sur le domaine.
+ Le domaine se trouve dans la même région que l'instance IAM Identity Center.
+ Le domaine et [OpenSearch l'application](application.md) appartiennent au même AWS compte.
## Modification de la stratégie d'accès au domaine
Avant de configurer IAM Identity Center, vous devez mettre à jour la politique d'accès au domaine ou les autorisations du rôle IAM configuré dans les OpenSearch applications pour la propagation d'identités fiables.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:role/OpenSearchRole"
},
"Action": "es:ESHttp*",
"Resource": "arn:aws:es:us-east-1:111122223333:domain/example-domain/*"
}
]
}
```
------
## Configuration de l'authentification et de l'autorisation IAM Identity Center (console)
Vous pouvez activer l'authentification et l'autorisation IAM Identity Center pendant le processus de création du domaine ou en mettant à jour un domaine existant. Les étapes de configuration varient légèrement en fonction de l'option choisie.
Les étapes suivantes expliquent comment configurer un domaine existant pour l'authentification et l'autorisation IAM Identity Center dans la console Amazon OpenSearch Service :
1. Sous **Configuration du domaine**, accédez à **Configuration de la sécurité**, choisissez Modifier, accédez à la section Authentification du centre d'identité IAM, puis sélectionnez **Activer l'accès à l'API authentifié auprès d'IAM** Identity Center.
1. Sélectionnez la touche SubjectKey et Rôles comme suit.
+ **Clé d'objet** : choisissez l'un des attributs suivants UserId (par défaut) UserName et E-mail pour utiliser l'attribut correspondant comme principal d'accès au domaine.
+ **Clé des rôles** : choisissez l'un des rôles GroupId (par défaut) et GroupName utilisez les valeurs d'attribut correspondantes comme rôle principal [fine-grained-access-control](fgac.md)pour tous les groupes associés au principal IAM Identity Center.
Une fois que vous avez apporté vos modifications, enregistrez votre domaine.
## Configuration d'un contrôle d'accès précis
**Une fois que vous avez activé l'option IAM Identity Center sur votre OpenSearch domaine, vous pouvez configurer l'accès aux principaux IAM Identity Center en [créant un mappage des rôles vers le rôle](fgac.md#fgac-mapping) principal.** La valeur du rôle principal pour le principal est basée sur l'appartenance au groupe du principal IAM Identity Center et sur la RolesKey configuration de GroupId ou. GroupName
**Note**
Amazon OpenSearch Service peut prendre en charge jusqu'à **100 groupes** pour un seul utilisateur. Si vous essayez d'utiliser un nombre d'instances supérieur au nombre autorisé, vous rencontrerez des incohérences dans le traitement de votre fine-grained-access-control autorisation et vous recevrez un message d'erreur 403.
## Configuration de l'authentification et de l'autorisation (CLI) d'IAM Identity Center
```
aws opensearch update-domain-config \
--domain-name my-domain \
--identity-center-options '{"EnabledAPIAccess": true, "IdentityCenterInstanceARN": "instance arn", "SubjectKey": "UserId/UserName/UserEmail" , "RolesKey": "GroupId/GroupName"}'
```
## Désactivation de l'authentification IAM Identity Center sur le domaine
Pour désactiver IAM Identity Center sur votre OpenSearch domaine :
1. Choisissez le domaine, **Actions**, et **Edit security configuration(Modifier la configuration de la sécurité)**.
1. Décochez **Activer l'accès à l'API authentifié auprès d'IAM** Identity Center.
1. Sélectionnez **Enregistrer les modifications**.
1. Une fois le traitement du domaine terminé, supprimez les [mappages de rôles](fgac.md) ajoutés pour les principaux IAM Identity Center
Pour désactiver IAM Identity Center via la CLI, vous pouvez utiliser ce qui suit
```
aws opensearch update-domain-config \
--domain-name my-domain \
--identity-center-options '{"EnabledAPIAccess": false}'
```
# Configuration de l'authentification Amazon Cognito pour les tableaux de bord OpenSearch
Vous pouvez authentifier et protéger votre installation par défaut des OpenSearch tableaux de bord Amazon OpenSearch Service à l'aide d'Amazon [Cognito](https://docs.aws.amazon.com/cognito/latest/developerguide/what-is-amazon-cognito.html). L'authentification Amazon Cognito est facultative et disponible uniquement pour les domaines utilisant Elasticsearch OpenSearch 5.1 ou version ultérieure. Si vous ne configurez pas l'authentification Amazon Cognito, vous pouvez malgré tout protéger Dashboards à l'aide d'une [stratégie d'accès basée sur l'adresse IP](ac.md#ac-types-ip), d'un [serveur proxy](dashboards.md#dashboards-proxy), de l'authentification HTTP de base ou de [SAML](saml.md).
La majeure partie du processus d'authentification se déroule dans Amazon Cognito, mais cette section fournit des directives et des exigences relatives à la configuration des ressources Amazon Cognito pour qu'elles fonctionnent OpenSearch avec les domaines de service. La [tarification standard](https://aws.amazon.com/cognito/pricing/) s'applique à toutes les ressources Amazon Cognito.
**Astuce**
La première fois que vous configurez un domaine pour utiliser l'authentification Amazon Cognito pour les OpenSearch tableaux de bord, nous vous recommandons d'utiliser la console. Les ressources Amazon Cognito sont extrêmement personnalisables, et la console peut vous aider à identifier et comprendre les fonctions qui vous concernent.
**Topics**
+ [Conditions préalables](#cognito-auth-prereq)
+ [Configurer un domaine pour utiliser l'authentification Amazon Cognito](#cognito-auth-config)
+ [Autorisation du rôle authentifié](#cognito-auth-config-ac)
+ [Configuration des fournisseurs d'identité](#cognito-auth-identity-providers)
+ [(Facultatif) Configuration du contrôle précis des accès](#cognito-auth-granular)
+ [(Facultatif) Personnalisation de la page de connexion](#cognito-auth-customize)
+ [(Facultatif) Configuration de la sécurité avancée](#cognito-auth-advanced)
+ [Test](#cognito-auth-testing)
+ [Quotas](#cognito-auth-limits)
+ [Problèmes de configuration courants](#cognito-auth-troubleshooting)
+ [Désactivation de l'authentification Amazon Cognito pour les tableaux de bord OpenSearch](#cognito-auth-disable)
+ [Suppression de domaines utilisant l'authentification Amazon Cognito pour les tableaux de bord OpenSearch](#cognito-auth-delete)
## Conditions préalables
Avant de pouvoir configurer l'authentification Amazon Cognito pour les OpenSearch tableaux de bord, vous devez remplir plusieurs conditions préalables. La console OpenSearch de service permet de rationaliser la création de ces ressources, mais la compréhension de l'objectif de chaque ressource facilite la configuration et le dépannage. L'authentification Amazon Cognito pour Dashboards nécessite les ressources suivantes :
+ [Groupe d'utilisateurs](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-identity-pools.html) Amazon Cognito
+ [Groupes d'identités](https://docs.aws.amazon.com/cognito/latest/developerguide/identity-pools.html) Amazon Cognito
+ Rôle IAM auquel est attachée la politique `AmazonOpenSearchServiceCognitoAccess` (`CognitoAccessForAmazonOpenSearch`)
**Note**
Le groupe d'utilisateurs et le groupe d'identités doivent se trouver dans la même Région AWS. Vous pouvez utiliser le même groupe d'utilisateurs, le même pool d'identités et le même rôle IAM pour ajouter l'authentification Amazon Cognito pour les tableaux de bord à OpenSearch plusieurs domaines de service. Pour en savoir plus, veuillez consulter la section [Quotas](#cognito-auth-limits).
### À propos du groupe d'utilisateurs
Les groupes d'utilisateurs ont deux fonctions principales : créer et gérer un annuaire d'utilisateurs et permettre l'inscription et la connexion des utilisateurs. Pour obtenir des instructions sur la création d'un groupe d'utilisateurs, consultez [Getting started with user pools](https://docs.aws.amazon.com/cognito/latest/developerguide/getting-started-user-pools.html) dans le manuel *Amazon Cognito Developer Guide*.
Lorsque vous créez un groupe d'utilisateurs à utiliser avec OpenSearch Service, tenez compte des points suivants :
+ Votre groupe d'utilisateurs Amazon Cognito doit avoir un [nom de domaine](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools-domain.html). OpenSearch Le service utilise ce nom de domaine pour rediriger les utilisateurs vers une page de connexion permettant d'accéder aux tableaux de bord. À part un nom de domaine, le groupe d'utilisateurs n'a pas besoin d'une configuration autre que celle par défaut.
+ Vous devez spécifier les [attributs standard](https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-settings-attributes.html#cognito-user-pools-standard-attributes) obligatoires du groupe d'utilisateurs (par exemple : nom, date de naissance, adresse e-mail et numéro de téléphone). Vous ne pouvez pas modifier ces attributs une fois que vous avez créé le groupe d'utilisateurs. Vous devez donc choisir ceux qui vous concernent en ce moment.
+ Lors de la création de votre groupe d'utilisateurs, choisissez si les utilisateurs peuvent créer leur propre compte, la fiabilité minimale des mots de passe des comptes et s'il convient d'activer l'authentification multi-facteurs. Si vous prévoyez d'utiliser un [fournisseur d'identité externe](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools-identity-federation.html), ces paramètres sont sans conséquence. Du point de vue technique, vous pouvez activer le groupe d'utilisateurs en tant que fournisseur d'identité *et* activer un fournisseur d'identité externe, mais la plupart des personnes préfèrent l'une ou l'autre méthode.
Le groupe d'utilisateurs IDs prend la forme de`region_ID`. Si vous prévoyez d'utiliser la AWS CLI ou un AWS SDK pour configurer le OpenSearch service, notez l'ID.
### À propos du groupe d'identités
Les groupes d'identités vous permettent d'attribuer des rôles temporaires dotés de privilèges limités aux utilisateurs une fois qu'ils se sont connectés. Pour obtenir des instructions sur la création d'un pool d'identités, consultez la section [Présentation de la console des pools d'identités](https://docs.aws.amazon.com/cognito/latest/developerguide/identity-pools.html) dans le manuel *Amazon Cognito Developer Guide*. Lorsque vous créez un pool d'identités à utiliser avec OpenSearch Service, tenez compte des points suivants :
+ Si vous utilisez la console Amazon Cognito, vous devez cocher la case **Activer l'accès aux identités non authentifiées** pour créer le groupe d'identités. Après avoir créé le pool d'identités et configuré le domaine de OpenSearch service, Amazon Cognito désactive ce paramètre.
+ Vous n'avez pas besoin d'ajouter de [fournisseurs d'identités externes](https://docs.aws.amazon.com/cognito/latest/developerguide/external-identity-providers.html) au groupe d'identités. Lorsque vous configurez le OpenSearch service pour utiliser l'authentification Amazon Cognito, il configure le groupe d'identités pour qu'il utilise le groupe d'utilisateurs que vous venez de créer.
+ Une fois que vous avez créé le groupe d'identités, vous devez choisir des rôles IAM non authentifiés et authentifiés. Ces rôles spécifient les stratégies d'accès des utilisateurs avant et après qu'ils se soient connectés. Si vous utilisez la console Amazon Cognito, elle peut créer ces rôles à votre place. Une fois que vous avez créé le rôle authentifié, notez l'ARN, qui se présente sous la forme `arn:aws:iam::123456789012:role/Cognito_identitypoolnameAuth_Role`.
Le pool d'identités IDs prend la forme de`region:ID-ID-ID-ID-ID`. Si vous prévoyez d'utiliser la AWS CLI ou un AWS SDK pour configurer le OpenSearch service, notez l'ID.
### À propos du CognitoAccessForAmazonOpenSearch rôle
OpenSearch Le service a besoin d'autorisations pour configurer les groupes d'utilisateurs et d'identités Amazon Cognito et les utiliser pour l'authentification. Vous pouvez utiliser`AmazonOpenSearchServiceCognitoAccess`, qui est une politique AWS gérée, à cette fin. `AmazonESCognitoAccess`est une ancienne politique qui a été remplacée `AmazonOpenSearchServiceCognitoAccess` lorsque le service a été renommé Amazon OpenSearch Service. Les deux politiques fournissent les autorisations Amazon Cognito minimales nécessaires pour activer l'authentification Amazon Cognito. Pour plus de détails sur les politiques, consultez [AmazonOpenSearchServiceCognitoAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonOpenSearchServiceCognitoAccess.html)le *Guide de référence des politiques AWS gérées*.
Si vous utilisez la console pour créer ou configurer votre domaine de OpenSearch service, elle crée un rôle IAM pour vous et associe la `AmazonOpenSearchServiceCognitoAccess` politique (ou la `AmazonESCognitoAccess` politique s'il s'agit d'un domaine Elasticsearch) au rôle. Le nom par défaut du rôle est `CognitoAccessForAmazonOpenSearch`.
Les politiques d'autorisation des rôles `AmazonOpenSearchServiceCognitoAccess` et `AmazonESCognitoAccess` les deux permettent au OpenSearch Service d'effectuer les actions suivantes sur tous les groupes d'identités et d'utilisateurs :
+ Action : `cognito-idp:DescribeUserPool`
+ Action : `cognito-idp:CreateUserPoolClient`
+ Action : `cognito-idp:DeleteUserPoolClient`
+ Action : `cognito-idp:UpdateUserPoolClient`
+ Action : `cognito-idp:DescribeUserPoolClient`
+ Action : `cognito-idp:AdminInitiateAuth`
+ Action : `cognito-idp:AdminUserGlobalSignOut`
+ Action : `cognito-idp:ListUserPoolClients`
+ Action : `cognito-identity:DescribeIdentityPool`
+ Action : `cognito-identity:SetIdentityPoolRoles`
+ Action : `cognito-identity:GetIdentityPoolRoles`
Si vous utilisez le AWS CLI ou l'un des AWS SDKs, vous devez créer votre propre rôle, associer la politique et spécifier l'ARN de ce rôle lorsque vous configurez votre domaine de OpenSearch service. Le rôle doit avoir la relation d'approbation suivante :
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "opensearchservice.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
------
Pour obtenir des instructions, voir [Créer un rôle pour déléguer des autorisations à un AWS service](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html) et [Ajouter et supprimer des autorisations d'identité IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html) dans le guide de l'*utilisateur IAM*.
## Configurer un domaine pour utiliser l'authentification Amazon Cognito
Une fois les conditions requises remplies, vous pouvez configurer un domaine de OpenSearch service pour utiliser Amazon Cognito pour les tableaux de bord.
**Note**
Amazon Cognito n'est pas disponible du tout. Régions AWS Pour obtenir la liste des régions prises en charge, consultez la section [Points de terminaison de service](https://docs.aws.amazon.com/general/latest/gr/cognito_identity.html#cognito_identity_region) pour Amazon Cognito. Il n'est pas nécessaire d'utiliser la même région pour Amazon Cognito que pour OpenSearch le service.
### Configuration de l'authentification Amazon Cognito (console)
Parce qu'elle crée le `CognitoAccessForAmazonOpenSearch` rôle qui vous convient, la console offre l'expérience de configuration la plus simple. Outre les autorisations de OpenSearch service standard, vous avez besoin de l'ensemble d'autorisations suivant pour utiliser la console afin de créer un domaine qui utilise l'authentification Amazon Cognito pour les OpenSearch tableaux de bord.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": [
"ec2:DescribeVpcs",
"cognito-identity:ListIdentityPools",
"cognito-idp:ListUserPools",
"iam:CreateRole",
"iam:AttachRolePolicy"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"iam:GetRole",
"iam:PassRole"
],
"Resource": "arn:aws:iam::123456789012:role/service-role/CognitoAccessForAmazonOpenSearch"
}
]
}
```
------
Pour obtenir des instructions sur l'ajout d'autorisations à une identité (utilisateur, groupe d'utilisateurs ou rôle), consultez la section [Ajout d'autorisations à une identité IAM (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html#add-policies-console).
Si `CognitoAccessForAmazonOpenSearch` existe déjà, vous avez besoin de moins d'autorisations :
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": [
"ec2:DescribeVpcs",
"cognito-identity:ListIdentityPools",
"cognito-idp:ListUserPools"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"iam:GetRole",
"iam:PassRole"
],
"Resource": "arn:aws:iam::123456789012:role/service-role/CognitoAccessForAmazonOpenSearch"
}
]
}
```
------
**Pour configurer l'authentification Amazon Cognito pour Dashboards (console)**
1. Ouvrez la console Amazon OpenSearch Service à l'adresse [https://console.aws.amazon.com/aos/home/](https://console.aws.amazon.com/aos/home/).
1. Sous **Domains (Domaines)**, sélectionnez le domaine que vous souhaitez configurer.
1. Choisissez **Actions**, **Edit security configuration (Modifier la configuration de sécurité)**.
1. Sélectionnez **Enable Amazon Cognito authentication (Activer l'authentification Amazon Cognito)**.
1. Pour **Région**, sélectionnez celle Région AWS qui contient votre groupe d'utilisateurs et votre groupe d'identités Amazon Cognito.
1. Pour **Cognito user pool (Groupe d'utilisateurs Cognito)**, sélectionnez un groupe d'utilisateurs ou créez-en un. Pour de plus amples informations, veuillez consulter [À propos du groupe d'utilisateurs](#cognito-auth-prereq-up).
1. Pour **Cognito identity pool (Groupe d'identités Cognito)**, sélectionnez un groupe d'identités ou créez-en un. Pour de plus amples informations, veuillez consulter [À propos du groupe d'identités](#cognito-auth-prereq-ip).
**Note**
Les liens **Créer un groupe d'utilisateurs** et **Créer un groupe d'identités** vous dirigent vers la console Amazon Cognito pour créer ces ressources manuellement. Le processus n'est pas automatique. Pour de plus amples informations, veuillez consulter [Conditions préalables](#cognito-auth-prereq).
1. Pour **nom de rôle IAM**, utilisez la valeur par défaut `CognitoAccessForAmazonOpenSearch` (recommandé) ou entrez un nouveau nom. Pour de plus amples informations, veuillez consulter [À propos du CognitoAccessForAmazonOpenSearch rôle](#cognito-auth-role).
1. Sélectionnez **Save Changes (Enregistrer les modifications)**.
Lorsque votre domaine a terminé le traitement, consultez les étapes de configuration supplémentaires dans [Autorisation du rôle authentifié](#cognito-auth-config-ac) et [Configuration des fournisseurs d'identité](#cognito-auth-identity-providers).
### Configuration de l'authentification Amazon Cognito (AWS CLI)
Utilisez le `--cognito-options` paramètre pour configurer votre domaine OpenSearch de service. La syntaxe suivante est utilisée par les commandes `create-domain` et `update-domain-config` :
```
--cognito-options Enabled=true,UserPoolId="user-pool-id",IdentityPoolId="identity-pool-id",RoleArn="arn:aws:iam::123456789012:role/CognitoAccessForAmazonOpenSearch"
```
**Exemple**
L'exemple suivant crée un domaine dans la région `us-east-1`, qui permet l'authentification Amazon Cognito pour Dashboards à l'aide du rôle `CognitoAccessForAmazonOpenSearch` et fournit un accès au domaine à `Cognito_Auth_Role` :
```
aws opensearch create-domain --domain-name my-domain --region us-east-1 --access-policies '{ "Version": "2012-10-17", "Statement":[{"Effect":"Allow","Principal":{"AWS": ["arn:aws:iam::123456789012:role/Cognito_Auth_Role"]},"Action":"es:ESHttp*","Resource":"arn:aws:es:us-east-1:123456789012:domain/*" }]}' --engine-version "OpenSearch_1.0" --cluster-config InstanceType=m4.xlarge.search,InstanceCount=1 --ebs-options EBSEnabled=true,VolumeSize=10 --cognito-options Enabled=true,UserPoolId="us-east-1_123456789",IdentityPoolId="us-east-1:12345678-1234-1234-1234-123456789012",RoleArn="arn:aws:iam::123456789012:role/CognitoAccessForAmazonOpenSearch"
```
Lorsque votre domaine a terminé le traitement, consultez les étapes de configuration supplémentaires dans [Autorisation du rôle authentifié](#cognito-auth-config-ac) et [Configuration des fournisseurs d'identité](#cognito-auth-identity-providers).
### Configuration de l'authentification Amazon Cognito ()AWS SDKs
AWS SDKs (sauf Android et iOS SDKs) prennent en charge toutes les opérations définies dans le [Amazon OpenSearch Service API Reference](https://docs.aws.amazon.com/opensearch-service/latest/APIReference/Welcome.html), y compris le `CognitoOptions` paramètre des `UpdateDomainConfig` opérations `CreateDomain` et. Pour plus d'informations sur l'installation et l'utilisation du AWS SDKs, consultez la section [Kits de développement AWS logiciel](https://aws.amazon.com/code).
Lorsque votre domaine a terminé le traitement, consultez les étapes de configuration supplémentaires dans [Autorisation du rôle authentifié](#cognito-auth-config-ac) et [Configuration des fournisseurs d'identité](#cognito-auth-identity-providers).
## Autorisation du rôle authentifié
Par défaut, le rôle IAM authentifié que vous avez configuré en suivant les instructions [À propos du groupe d'identités](#cognito-auth-prereq-ip) ne dispose pas des privilèges nécessaires pour accéder OpenSearch aux tableaux de bord. Vous devez lui apporter des autorisations supplémentaires.
**Note**
Si vous avez configuré un [contrôle d'accès détaillé](fgac.md) et que vous utilisez une politique d'accès ouverte ou basée sur IP, vous pouvez ignorer cette étape.
Vous pouvez inclure ces autorisations dans une politique [basée sur l'identité](ac.md#ac-types-identity), mais à moins que vous ne souhaitiez que les utilisateurs authentifiés aient accès à tous les domaines du OpenSearch service, une stratégie [basée sur les ressources](ac.md#ac-types-resource) attachée à un seul domaine est la meilleure approche.
Pour le `Principal`, spécifiez l'ARN du rôle authentifié Cognito que vous avez configuré conformément aux instructions figurant dans [À propos du groupe d'identités](#cognito-auth-prereq-ip).
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Effect":"Allow",
"Principal":{
"AWS":[
"arn:aws:iam::111122223333:role/Cognito_identitypoolname/Auth_Role"
]
},
"Action":[
"es:ESHttp*"
],
"Resource":"arn:aws:es:us-east-1:111122223333:domain/domain-name/*"
}
]
}
```
------
Pour obtenir des instructions sur l'ajout d'une politique basée sur les ressources à un domaine OpenSearch de service, consultez. [Configuration des politiques d'accès](createupdatedomains.md#createdomain-configure-access-policies)
## Configuration des fournisseurs d'identité
Lorsque vous configurez un domaine pour utiliser l'authentification Amazon Cognito pour les tableaux de bord, OpenSearch Service ajoute un [client d'application](https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-settings-client-apps.html) au groupe d'utilisateurs et ajoute le groupe d'utilisateurs au pool d'identités en tant que fournisseur d'authentification.
**Avertissement**
Ne renommez pas et ne supprimez pas le client d'application.
Selon la manière dont vous avez configuré votre groupe d'utilisateurs, vous pouvez avoir besoin de créer des comptes d'utilisateur manuellement, ou les utilisateurs peuvent créer leur propre compte. Si ces paramètres sont acceptables, aucune action n'est requise de votre part. Toutefois, de nombreuses personnes préfèrent utiliser des fournisseurs d'identité externes.
Pour activer un fournisseur d'identité SAML 2.0, vous devez fournir un document de métadonnées SAML. Pour activer des fournisseurs d'identité sociaux tels que Login with Amazon, Facebook et Google, vous devez vous procurer un ID d'application et une clé secrète d'application auprès de ces fournisseurs. Vous pouvez activer n'importe quelle combinaison de fournisseurs d'identité.
Le moyen le plus simple de configurer votre groupe d'utilisateurs est d'utiliser la console Amazon Cognito. Pour obtenir des instructions, consultez les sections [Connexion au groupe d'utilisateurs avec des fournisseurs d'identité tiers](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools-identity-federation.html) et [Paramètres spécifiques à l'application avec le client d'application dans le guide du](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools-app-idp-settings.html) développeur *Amazon* Cognito.
## (Facultatif) Configuration du contrôle précis des accès
Vous avez peut-être remarqué que les paramètres du pool d'identités par défaut attribuent à chaque utilisateur qui se connecte le même rôle IAM (`Cognito_identitypoolAuth_Role`), ce qui signifie que chaque utilisateur peut accéder aux mêmes AWS ressources. Si vous souhaitez utiliser un [contrôle précis des accès](fgac.md) avec Amazon Cognito (par exemple, si vous souhaitez que les analystes de votre organisation disposent d'un accès en lecture seule à plusieurs index, mais que les développeurs disposent d'un accès en écriture à tous les index), vous avez deux options :
+ Créez des groupes d'utilisateurs et configurez votre fournisseur d'identité pour choisir le rôle IAM en fonction du jeton d'authentification de l'utilisateur (recommandé).
+ Configurez votre fournisseur d'identité pour choisir le rôle IAM en fonction d'une ou de plusieurs règles.
Pour obtenir une procédure pas à pas qui inclut un contrôle d'accès affiné, veuillez consulter [Didacticiel : configurer un domaine avec un utilisateur principal IAM et l'authentification Amazon Cognito](fgac-iam.md).
**Important**
Tout comme le rôle par défaut, Amazon Cognito doit faire partie de la relation d'approbation de chaque rôle supplémentaire. Pour plus de détails, consultez la section [Création de rôles pour le mappage des rôles](https://docs.aws.amazon.com/cognito/latest/developerguide/role-based-access-control.html#creating-roles-for-role-mapping) dans le manuel *Amazon Cognito Developer Guide*.
### Groupes d'utilisateurs et jetons
Lorsque vous créez un groupe d'utilisateurs, vous choisissez un rôle IAM pour les membres du groupe. Pour plus d'informations sur la création de groupes, consultez la section [Ajouter des groupes à un groupe d'utilisateurs](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools-user-groups.html) dans le manuel *Amazon Cognito Developer Guide*.
Une fois que vous avez créé un ou plusieurs groupes d'utilisateurs, vous pouvez configurer votre fournisseur d'authentification pour affecter les utilisateurs aux rôles de leurs groupes et non au rôle par défaut du groupe d'identités. Choisissez **Choose role from token (Utiliser le rôle du jeton)**, puis **Utiliser le rôle authentifié par défaut** ou **DENY (REFUSER)** pour spécifier la façon dont le groupe d'identités doit gérer les utilisateurs qui ne font pas partie d'un groupe.
### Rules
Les règles correspondent essentiellement à une série d'instructions `if` qu'Amazon Cognito évalue de manière séquentielle. Par exemple, si l'adresse e-mail d'un utilisateur contient `@corporate`, Amazon Cognito attribue le `Role_A` à cet utilisateur. Si l'adresse e-mail d'un utilisateur contient `@subsidiary`, il attribue `Role_B` à cet utilisateur. Sinon, il attribue à l'utilisateur le rôle authentifié par défaut.
Pour en savoir plus, consultez la section [Utilisation du mappage basé sur des règles pour attribuer des rôles aux utilisateurs](https://docs.aws.amazon.com/cognito/latest/developerguide/role-based-access-control.html#using-rules-to-assign-roles-to-users) dans le manuel *Amazon Cognito Developer* Guide.
## (Facultatif) Personnalisation de la page de connexion
Vous pouvez utiliser la console Amazon Cognito pour télécharger un logo personnalisé et apporter des modifications CSS à la page de connexion. Pour obtenir des instructions et une liste complète des propriétés CSS, consultez la section [Personnalisation de l'image de marque (classique) de l'interface utilisateur hébergée](https://docs.aws.amazon.com/cognito/latest/developerguide/hosted-ui-classic-branding.html) dans le manuel *Amazon Cognito* Developer Guide.
## (Facultatif) Configuration de la sécurité avancée
Les groupes d'utilisateurs Amazon Cognito prennent en charge les fonctionnalités de sécurité avancée, telles que l'authentification multifacteur, la vérification des informations d'identification compromises et l'authentification adaptative. Pour en savoir plus, consultez la section [Utilisation des fonctionnalités de sécurité des groupes d'utilisateurs Amazon Cognito](https://docs.aws.amazon.com/cognito/latest/developerguide/managing-security.html) dans le manuel du développeur *Amazon Cognito*.
## Test
Une fois que vous êtes satisfait de votre configuration, vérifiez que l'expérience utilisateur répond à vos attentes.
**Pour accéder aux OpenSearch tableaux de bord**
1. Accédez à `https://opensearch-domain/_dashboards` dans un navigateur web. Pour vous connecter directement à un locataire spécifique, ajoutez `?security_tenant=tenant-name` à l'URL.
1. Connectez-vous à l'aide de vos informations d'identification préférées.
1. Une fois OpenSearch les tableaux de bord chargés, configurez au moins un modèle d'index. Dashboards utilise ces modèles pour identifier les index à analyser. Entrez `*`, choisissez **Next step (Étape suivante)**, puis **Create index pattern (Créer un modèle d'index)**.
1. Pour explorer vos données, choisissez **Discover (Découvrir)**.
Si une étape de ce processus échoue, consultez [Problèmes de configuration courants](#cognito-auth-troubleshooting) pour obtenir des informations de dépannage.
## Quotas
Amazon Cognito comporte des limites souples sur un grand nombre de ses ressources. Si vous souhaitez activer l'authentification par tableau de bord pour un grand nombre de domaines de OpenSearch service, consultez les [quotas dans Amazon](https://docs.aws.amazon.com/cognito/latest/developerguide/limits.html) Cognito [et demandez des augmentations de la limite](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) si nécessaire.
Chaque domaine OpenSearch de service ajoute un [client d'application](https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-settings-client-apps.html) au groupe d'utilisateurs, ce qui ajoute un [fournisseur d'authentification](https://docs.aws.amazon.com/cognito/latest/developerguide/external-identity-providers.html) au pool d'identités. Si vous activez l'authentification par tableau de OpenSearch bord pour plus de 10 domaines, vous risquez de rencontrer la limite du « nombre maximum de fournisseurs de pool d'utilisateurs Amazon Cognito par pool d'identités ». **Si vous dépassez une limite, tous les domaines de OpenSearch service que vous essayez de configurer pour utiliser l'authentification Amazon Cognito pour les tableaux de bord peuvent rester bloqués dans un état de configuration en cours de traitement.**
## Problèmes de configuration courants
Les tableaux suivants répertorient les problèmes de configuration courants et les solutions correspondantes.
**Configuration du OpenSearch service**
| Problème | Solution |
| --- | --- |
| `OpenSearch Service can't create the role` (console) | Vous ne disposez pas des autorisations IAM correctes. Ajoutez les autorisations spécifiées dans [Configuration de l'authentification Amazon Cognito (console)](#cognito-auth-config-console). |
| `User is not authorized to perform: iam:PassRole on resource CognitoAccessForAmazonOpenSearch` (console) | Vous n'avez pas iam:PassRole les autorisations nécessaires pour ce [CognitoAccessForAmazonOpenSearch](#cognito-auth-role)rôle. Attachez la politique suivante à votre compte : JSON
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"iam:PassRole"
],
"Resource": "arn:aws:iam::123456789012:role/service-role/CognitoAccessForAmazonOpenSearch"
}
]
}
``` Vous pouvez également attacher la politique `IAMFullAccess`. |
| `User is not authorized to perform: cognito-identity:ListIdentityPools on resource` | Vous ne disposez pas des autorisations en lecture pour Amazon Cognito. Attachez la politique `AmazonCognitoReadOnly` à votre compte. |
| `An error occurred (ValidationException) when calling the CreateDomain operation: OpenSearch Service must be allowed to use the passed role` | OpenSearch Le service n'est pas spécifié dans la relation de confiance du `CognitoAccessForAmazonOpenSearch` rôle. Vérifiez que votre rôle utilise la relation d'approbation qui est spécifiée dans [À propos du CognitoAccessForAmazonOpenSearch rôle](#cognito-auth-role). Vous pouvez aussi utiliser la console pour configurer l'authentification Amazon Cognito. La console crée un rôle pour vous. |
| `An error occurred (ValidationException) when calling the CreateDomain operation: User is not authorized to perform: cognito-idp:action on resource: user pool` | Le rôle spécifié dans --cognito-options n'est pas autorisé à accéder aux ressources Amazon Cognito. Vérifiez que la AmazonOpenSearchServiceCognitoAccess politique AWS gérée est attachée au rôle. Vous pouvez aussi utiliser la console pour configurer l'authentification Amazon Cognito. La console crée un rôle pour vous. |
| An error occurred (ValidationException) when calling the CreateDomain operation: User pool does not exist | OpenSearch Le service ne trouve pas le groupe d'utilisateurs. Vérifiez que vous en avez créé un et qu'il a l'ID correct. Pour trouver l'ID, vous pouvez utiliser la console Amazon Cognito ou la commande suivante : AWS CLI aws cognito-idp list-user-pools --max-results 60 --region region
|
| `An error occurred (ValidationException) when calling the CreateDomain operation: IdentityPool not found` | OpenSearch Le service ne trouve pas le pool d'identités. Vérifiez que vous en avez créé un et qu'il a l'ID correct. Pour trouver l'ID, vous pouvez utiliser la console Amazon Cognito ou la commande suivante : AWS CLI aws cognito-identity list-identity-pools --max-results 60 --region region
|
| `An error occurred (ValidationException) when calling the CreateDomain operation: Domain needs to be specified for user pool` | Le groupe d'utilisateurs n'a pas de nom de domaine. Vous pouvez en configurer un à l'aide de la console Amazon Cognito ou de la commande AWS CLI suivante :aws cognito-idp create-user-pool-domain --domain name --user-pool-id id
|
**Accès aux OpenSearch tableaux de bord**
| Problème | Solution |
| --- | --- |
| La page de connexion n'affiche pas mes fournisseurs d'identité préférés. | Vérifiez que vous avez activé le fournisseur d'identité pour le client OpenSearch Service app comme indiqué dans[Configuration des fournisseurs d'identité](#cognito-auth-identity-providers). |
| La page de connexion ne semble pas associée à mon organisation. | Consultez [(Facultatif) Personnalisation de la page de connexion](#cognito-auth-customize). |
| Mes informations d'identification de connexion ne fonctionnent pas. | Vérifiez que vous avez configuré le fournisseur d'identité de la façon spécifiée dans [Configuration des fournisseurs d'identité](#cognito-auth-identity-providers). Si vous utilisez le groupe d'utilisateurs comme fournisseur d'identité, vérifiez que le compte existe sur la console Amazon Cognito. |
| OpenSearch Les tableaux de bord ne se chargent pas du tout ou ne fonctionnent pas correctement. | Le rôle authentifié par Amazon Cognito nécessite les autorisations `es:ESHttp*` pour permettre au domaine (`/*`) d'accéder à Dashboards et de l'utiliser. Vérifiez que vous avez ajouté une stratégie d'accès, comme indiqué dans [Autorisation du rôle authentifié](#cognito-auth-config-ac). |
| Lorsque je me déconnecte des OpenSearch tableaux de bord depuis un onglet, les autres onglets affichent un message indiquant que le jeton d'actualisation a été révoqué. | Lorsque vous vous déconnectez d'une session de OpenSearch tableaux de bord en utilisant l'authentification Amazon Cognito OpenSearch , le service exécute [AdminUserGlobalSignOut](https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminUserGlobalSignOut.html)une opération qui vous déconnecte *de toutes les sessions de tableaux de* bord OpenSearch actives. |
| Invalid identity pool configuration. Check assigned IAM roles for this pool. | Amazon Cognito ne dispose pas des autorisations nécessaires pour assumer le rôle IAM au nom de l'utilisateur authentifié. Modifiez la relation d'approbation pour le rôle à inclure : JSON
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Effect": "Allow",
"Principal": {
"Federated": "cognito-identity.amazonaws.com"
},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": {
"cognito-identity.amazonaws.com:aud": "identity-pool-id"
},
"ForAnyValue:StringLike": {
"cognito-identity.amazonaws.com:amr": "authenticated"
}
}
}
]
}
``` |
| Token is not from a supported provider of this identity pool. | Cette rare erreur peut se produire lorsque vous supprimez le client d'application client du groupe d'utilisateurs. Essayez d'ouvrir Dashboards dans une nouvelle session de navigateur. |
## Désactivation de l'authentification Amazon Cognito pour les tableaux de bord OpenSearch
Utilisez la procédure suivante pour désactiver l'authentification Amazon Cognito pour Dashboards.
**Pour désactiver l'authentification Amazon Cognito pour Dashboards (console)**
1. Ouvrez la [console Amazon OpenSearch Service](https://console.aws.amazon.com/aos/home/).
1. Sous **Domains** (Domaines), sélectionnez le domaine que vous souhaitez configurer.
1. Choisissez **Actions**, **Edit security configuration (Modifier la configuration de sécurité)**.
1. Désélectionnez **Enable Amazon Cognito authentication (Activer l'authentification Amazon Cognito)**.
1. Sélectionnez **Enregistrer les modifications**.
**Important**
Si vous n'avez plus besoin du groupe d'utilisateurs et du groupe d'identités Amazon Cognito, supprimez-les. Sinon, les frais continuent de vous être facturés.
## Suppression de domaines utilisant l'authentification Amazon Cognito pour les tableaux de bord OpenSearch
Pour éviter que les domaines qui utilisent l'authentification Amazon Cognito pour les tableaux de bord ne restent bloqués dans un état de configuration de **traitement**, supprimez les domaines de OpenSearch service *avant* de supprimer les groupes d'utilisateurs et d'identités Amazon Cognito associés.
# Utilisation de rôles liés à un service pour Amazon Service OpenSearch
Amazon OpenSearch Service utilise des rôles Gestion des identités et des accès AWS liés à un [service](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role) (IAM). Un rôle lié à un service est un type unique de rôle IAM directement lié au service. OpenSearch Les rôles liés au service sont prédéfinis par le OpenSearch service et incluent toutes les autorisations dont le service a besoin pour appeler d'autres AWS services en votre nom.
Un rôle lié à un service facilite la configuration du OpenSearch service, car vous n'avez pas à ajouter manuellement les autorisations nécessaires. OpenSearch Le service définit les autorisations associées à ses rôles liés au service et, sauf indication contraire, seul le OpenSearch service peut assumer ses rôles. Les autorisations définies comprennent la politique de confiance et la politique d’autorisation. De plus, cette politique d’autorisation ne peut pas être attachée à une autre entité IAM. Pour les mises à jour des rôles liés aux services et des politiques d'autorisation, consultez [l'historique des documents pour Amazon OpenSearch ](release-notes.md) Service.
Pour plus d'informations sur les autres services qui prennent en charge les rôles liés à un service, consultez la section [AWS Services qui fonctionnent avec IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) et recherchez les services dont la valeur est **Oui** dans la colonne Rôles liés à un **service**. Sélectionnez un **Oui** ayant un lien pour consulter la documentation du rôle lié à un service, pour ce service.
**Topics**
+ [Utilisation de rôles liés à un service pour créer des domaines VPC et interroger directement les sources de données](slr-aos.md)
+ [Utilisation de rôles liés à un service pour créer OpenSearch des collections sans serveur](serverless-service-linked-roles.md)
+ [Utilisation de rôles liés à un service pour créer des pipelines d'ingestion OpenSearch](slr-osis.md)
# Utilisation de rôles liés à un service pour créer des domaines VPC et interroger directement les sources de données
Amazon OpenSearch Service utilise des rôles Gestion des identités et des accès AWS liés à un [service](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role) (IAM). Un rôle lié à un service est un type unique de rôle IAM directement lié au service. OpenSearch Les rôles liés au service sont prédéfinis par le OpenSearch service et incluent toutes les autorisations dont le service a besoin pour appeler d'autres AWS services en votre nom.
OpenSearch Le service utilise le rôle lié au service nommé **AWSServiceRoleForAmazonOpenSearchService**, qui fournit les autorisations minimales Amazon EC2 et Elastic Load Balancing nécessaires pour que le rôle autorise l'accès [VPC](cognito-auth.md) à un domaine ou à une source de données de requête directe.
## Rôle Elasticsearch hérité
Amazon OpenSearch Service utilise un rôle lié à un service appelé. `AWSServiceRoleForAmazonOpenSearchService` Vos comptes peuvent également contenir un rôle lié à un service hérité appelé `AWSServiceRoleForAmazonElasticsearchService`, qui fonctionne avec les points de terminaison obsolètes de l'API Elasticsearch.
Si l'ancien rôle Elasticsearch n'existe pas dans votre compte, OpenSearch Service crée automatiquement un nouveau rôle OpenSearch lié au service la première fois que vous créez un domaine. OpenSearch Dans le cas contraire, votre compte continue d'utiliser le rôle Elasticsearch. Pour que cette création automatique aboutisse, vous devez avoir les autorisations permettant d'effectuer l'action `iam:CreateServiceLinkedRole`.
## Permissions
Le rôle lié à un service `AWSServiceRoleForAmazonOpenSearchService` approuve les services suivants pour endosser le rôle :
+ `opensearchservice.amazonaws.com`
La politique d'autorisations de rôle nommée [https://docs.aws.amazon.com/opensearch-service/latest/developerguide/ac-managed.html#AmazonOpenSearchServiceRolePolicy](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/ac-managed.html#AmazonOpenSearchServiceRolePolicy)permet au OpenSearch Service d'effectuer les actions suivantes sur les ressources spécifiées :
+ Action : `acm:DescribeCertificate` sur `*`
+ Action : `cloudwatch:PutMetricData` sur `*`
+ Action : `ec2:CreateNetworkInterface` sur `*`
+ Action : `ec2:DeleteNetworkInterface` sur `*`
+ Action : `ec2:DescribeNetworkInterfaces` sur `*`
+ Action : `ec2:ModifyNetworkInterfaceAttribute` sur `*`
+ Action : `ec2:DescribeSecurityGroups` sur `*`
+ Action : `ec2:DescribeSubnets` sur `*`
+ Action : `ec2:DescribeVpcs` sur `*`
+ Action : `ec2:CreateTags` sur l'ensemble des interfaces réseau et des points de terminaison d'un VPC
+ Action : `ec2:DescribeTags` sur `*`
+ Action : `ec2:CreateVpcEndpoint` sur tous les groupes de sécurité VPCs, sous-réseaux et tables de routage, ainsi que sur tous les points de terminaison VPC lorsque la demande contient le tag `OpenSearchManaged=true`
+ Action : `ec2:ModifyVpcEndpoint` sur tous les groupes de sécurité VPCs, sous-réseaux et tables de routage, ainsi que sur tous les points de terminaison VPC lorsque la demande contient le tag `OpenSearchManaged=true`
+ Action : `ec2:DeleteVpcEndpoints` sur tous les points de terminaison lorsque la requête contient la balise `OpenSearchManaged=true`
+ Action : `ec2:AssignIpv6Addresses` sur `*`
+ Action : `ec2:UnAssignIpv6Addresses` sur `*`
+ Action : `elasticloadbalancing:AddListenerCertificates` sur `*`
+ Action : `elasticloadbalancing:RemoveListenerCertificates` sur `*`
Vous devez configurer les autorisations de manière à permettre à une entité IAM (comme un utilisateur, un groupe ou un rôle) de créer, modifier ou supprimer un rôle lié à un service. Pour plus d’informations, consultez [Autorisations de rôles liés à un service](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions) dans le *Guide de l’utilisateur IAM*.
## Création du rôle lié à un service
Vous n’avez pas besoin de créer manuellement un rôle lié à un service. Lorsque vous créez un domaine compatible VPC ou une source de données de requête directe à l'aide du AWS Management Console, le OpenSearch Service crée pour vous le rôle lié au service. Pour que cette création automatique aboutisse, vous devez avoir les autorisations permettant d'effectuer l'action `iam:CreateServiceLinkedRole`.
Vous pouvez également utiliser la console IAM, la CLI IAM ou l'API IAM pour créer manuellement un rôle lié à un service. Pour plus d’informations, consultez [Création d’un rôle lié à un service](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#create-service-linked-role) dans le *Guide de l’utilisateur IAM*.
## Modifier le rôle lié à un service
OpenSearch Le service ne vous permet pas de modifier le rôle `AWSServiceRoleForAmazonOpenSearchService` lié au service. Une fois que vous avez créé un rôle lié à un service, vous ne pouvez pas changer le nom du rôle, car plusieurs entités peuvent faire référence au rôle. Néanmoins, vous pouvez modifier la description du rôle à l’aide d’IAM. Pour plus d’informations, consultez [Modification d’un rôle lié à un service](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role) dans le *Guide de l’utilisateur IAM*.
## Suppression du rôle lié à un service
Si vous n’avez plus besoin d’utiliser une fonctionnalité ou un service qui nécessite un rôle lié à un service, nous vous recommandons de supprimer ce rôle. De cette façon, vous n'avez aucune entité inutilisée qui n'est pas surveillée ou gérée activement. Cependant, vous devez nettoyer votre rôle lié à un service avant de pouvoir le supprimer manuellement.
### Nettoyage du rôle lié au service
Avant de pouvoir utiliser IAM pour supprimer un rôle lié à un service, vous devez d’abord vérifier qu’aucune session n’est active pour le rôle et supprimer toutes les ressources utilisées par le rôle.
**Pour vérifier si une session est active pour le rôle lié à un service dans la console IAM**
1. Connectez-vous à la console IAM AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)l'adresse.
1. Dans le panneau de navigation de la console IAM, choisissez **Rôles**. Ensuite, sélectionnez le nom (et non la case à cocher) du rôle `AWSServiceRoleForAmazonOpenSearchService`.
1. Sur la page **Récapitulatif** du rôle sélectionné, choisissez l'onglet **Access Advisor**.
1. Dans l'onglet **Access Advisor**, consultez l'activité récente pour le rôle lié à un service.
**Note**
Si vous ne savez pas si OpenSearch Service utilise le `AWSServiceRoleForAmazonOpenSearchService` rôle, vous pouvez essayer de le supprimer. Si le service utilise le rôle, la suppression échoue et vous pouvez visualiser les ressources utilisant le rôle. Si le rôle est utilisé, vous devez attendre la fin de la session avant de pouvoir supprimer le rôle ou and/or les ressources utilisant le rôle. Vous ne pouvez pas révoquer la session d’un rôle lié à un service.
### Suppression manuelle d'un rôle lié à un service
Supprimez les rôles liés à un service de la console IAM, de l'API ou de la CLI. AWS Pour de plus amples informations, veuillez consulter [Suppression d'un rôle lié à un service](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role) dans le *Guide de l'utilisateur IAM*.
# Utilisation de rôles liés à un service pour créer OpenSearch des collections sans serveur
OpenSearch Serverless utilise des rôles Gestion des identités et des accès AWS liés à un [service](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role) (IAM). Un rôle lié à un service est un type unique de rôle IAM directement lié au service. OpenSearch Les rôles liés au service sont prédéfinis par le OpenSearch service et incluent toutes les autorisations dont le service a besoin pour appeler d'autres AWS services en votre nom.
OpenSearch Serverless utilise le rôle lié au service nommé **AWSServiceRoleForAmazonOpenSearchServerless**, qui fournit les autorisations nécessaires pour que le rôle publie des métriques liées au service sans serveur CloudWatch sur votre compte. La politique d'autorisations de rôle associée à AWSService RoleForAmazonOpenSearchServerless est nommée`AmazonOpenSearchServerlessServiceRolePolicy`. Pour plus d'informations sur la politique, consultez [AmazonOpenSearchServerlessServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonOpenSearchServerlessServiceRolePolicy.html)le *Guide de référence des politiques AWS gérées*.
## Autorisations de rôle liées au service pour Serverless OpenSearch
OpenSearch Serverless utilise le rôle lié au service nommé AWSServiceRoleForAmazonOpenSearchServerless, qui permet à OpenSearch Serverless d'appeler des AWS services en votre nom.
Le rôle AWSService RoleForAmazonOpenSearchServerless lié à un service fait confiance aux services suivants pour assumer le rôle :
+ `observability.aoss.amazonaws.com`
La politique d'autorisation de rôle nommée `AmazonOpenSearchServerlessServiceRolePolicy` permet à OpenSearch Serverless d'effectuer les actions suivantes sur les ressources spécifiées :
+ Action : `cloudwatch:PutMetricData` sur toutes les ressources AWS
**Note**
La politique inclut la clé de condition`{"StringEquals": {"cloudwatch:namespace": "AWS/AOSS"}}`, ce qui signifie que le rôle lié à un service peut uniquement envoyer des données métriques à l'`AWS/AOSS` CloudWatchespace de noms.
Vous devez configurer les autorisations de manière à permettre à une entité IAM (comme un utilisateur, un groupe ou un rôle) de créer, modifier ou supprimer un rôle lié à un service. Pour plus d’informations, consultez [Autorisations de rôles liés à un service](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions) dans le *Guide de l’utilisateur IAM*.
## Création du rôle lié à un service pour Serverless OpenSearch
Vous n’avez pas besoin de créer manuellement un rôle lié à un service. Lorsque vous créez une collection OpenSearch Serverless dans le AWS Management Console, le ou l' AWS API AWS CLI, OpenSearch Serverless crée le rôle lié au service pour vous.
**Note**
La première fois que vous créez une collection, le rôle `iam:CreateServiceLinkedRole` doit vous être attribué dans une politique basée sur l'identité.
Si vous supprimez ce rôle lié à un service et que vous avez ensuite besoin de le recréer, vous pouvez utiliser la même procédure pour recréer le rôle dans votre compte. Lorsque vous créez une collection OpenSearch Serverless, OpenSearch Serverless crée à nouveau le rôle lié au service pour vous.
Vous pouvez également utiliser la console IAM pour créer un rôle lié à un service avec le cas d'utilisation **Amazon OpenSearch Serverless**. Dans l'API AWS CLI ou dans l' AWS API, créez un rôle lié à un service avec le nom du `observability.aoss.amazonaws.com` service :
```
aws iam create-service-linked-role --aws-service-name "observability.aoss.amazonaws.com"
```
Pour plus d’informations, consultez [Création d’un rôle lié à un service](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#create-service-linked-role) dans le *Guide de l’utilisateur IAM*. Si vous supprimez ce rôle lié à un service, vous pouvez utiliser ce même processus pour créer le rôle à nouveau.
## Modification du rôle lié à un service pour Serverless OpenSearch
OpenSearch Serverless ne vous permet pas de modifier le rôle lié au AWSService RoleForAmazonOpenSearchServerless service. Une fois que vous avez créé un rôle lié à un service, vous ne pouvez pas changer le nom du rôle, car plusieurs entités peuvent faire référence au rôle. Néanmoins, vous pouvez modifier la description du rôle à l’aide d’IAM. Pour plus d’informations, consultez [Modification d’un rôle lié à un service](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role) dans le *Guide de l’utilisateur IAM*.
## Suppression du rôle lié à un service pour Serverless OpenSearch
Si vous n’avez plus besoin d’utiliser une fonction ou un service qui nécessite un rôle lié à un service, nous vous recommandons de supprimer ce rôle. Cela vous évite d'avoir une entité inutilisée non surveillée ou non gérée activement. Cependant, vous devez nettoyer les ressources de votre rôle lié à un service avant de pouvoir les supprimer manuellement.
Pour supprimer le AWSServiceRoleForAmazonOpenSearchServerless, vous devez d'abord [supprimer toutes les collections OpenSearch Serverless](serverless-delete.md) de votre Compte AWS.
**Note**
Si OpenSearch Serverless utilise le rôle lorsque vous essayez de supprimer les ressources, la suppression risque d'échouer. Si cela se produit, patientez quelques minutes et réessayez.
**Pour supprimer manuellement le rôle lié au service à l’aide d’IAM**
Utilisez la console IAM, le AWS CLI, ou l' AWS API pour supprimer le rôle lié au AWSService RoleForAmazonOpenSearchServerless service. Pour plus d’informations, consultez la section [Suppression d’un rôle lié à un service](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role) dans le *Guide de l’utilisateur IAM*.
## Régions prises en charge pour les rôles OpenSearch liés à un service sans serveur
OpenSearch Serverless prend en charge l'utilisation du rôle AWSService RoleForAmazonOpenSearchServerless lié au service dans toutes les régions où OpenSearch Serverless est disponible. Pour obtenir la liste des régions prises en charge, consultez la section [Points de terminaison et quotas Amazon OpenSearch Serverless](https://docs.aws.amazon.com/general/latest/gr/opensearch-service.html) dans le. *Références générales AWS*
# Utilisation de rôles liés à un service pour créer des pipelines d'ingestion OpenSearch
Amazon OpenSearch Ingestion utilise des Gestion des identités et des accès AWS rôles liés à un [service](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role) (IAM). Un rôle lié à un service est un type unique de rôle IAM directement lié à Ingestion. OpenSearch Les rôles liés au service sont prédéfinis par OpenSearch Ingestion et incluent toutes les autorisations dont le service a besoin pour appeler d'autres AWS services en votre nom.
OpenSearch L'ingestion utilise le rôle lié au service nommé **AWSServiceRoleForAmazonOpenSearchIngestionService**, sauf lorsque vous utilisez un VPC autogéré, auquel cas elle utilise le rôle lié au service nommé. **AWSServiceRoleForOpensearchIngestionSelfManagedVpce** La politique ci-jointe fournit les autorisations nécessaires au rôle pour créer un cloud privé virtuel (VPC) entre votre compte et OpenSearch Ingestion, et pour publier CloudWatch des métriques sur votre compte.
## Permissions
Le rôle lié à un service `AWSServiceRoleForAmazonOpenSearchIngestionService` approuve les services suivants pour endosser le rôle :
+ `osis.amazonaws.com`
La politique d'autorisation de rôle nommée `AmazonOpenSearchIngestionServiceRolePolicy` permet OpenSearch à Ingestion d'effectuer les actions suivantes sur les ressources spécifiées :
+ Action : `cloudwatch:PutMetricData` sur `cloudwatch:namespace": "AWS/OSIS"`
+ Action : `ec2:CreateTags` sur `arn:aws:ec2:*:*:network-interface/*`
+ Action : `ec2:CreateVpcEndpoint` sur `*`
+ Action : `ec2:DeleteVpcEndpoints` sur `*`
+ Action : `ec2:DescribeSecurityGroups` sur `*`
+ Action : `ec2:DescribeSubnets` sur `*`
+ Action : `ec2:DescribeVpcEndpoints` sur `*`
+ Action : `ec2:ModifyVpcEndpoint` sur `*`
Le rôle lié à un service `AWSServiceRoleForOpensearchIngestionSelfManagedVpce` approuve les services suivants pour endosser le rôle :
+ `self-managed-vpce.osis.amazonaws.com`
La politique d'autorisation de rôle nommée `OpenSearchIngestionSelfManagedVpcePolicy` permet OpenSearch à Ingestion d'effectuer les actions suivantes sur les ressources spécifiées :
+ Action : `ec2:DescribeSubnets` sur `*`
+ Action : `ec2:DescribeSecurityGroups` sur `*`
+ Action : `ec2:DescribeVpcEndpoints` sur `*`
+ Action : `cloudwatch:PutMetricData` sur `cloudwatch:namespace": "AWS/OSIS"`
Vous devez configurer les autorisations de manière à permettre à une entité IAM (comme un utilisateur, un groupe ou un rôle) de créer, modifier ou supprimer un rôle lié à un service. Pour plus d’informations, consultez [Autorisations de rôles liés à un service](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions) dans le *Guide de l’utilisateur IAM*.
## Création du rôle lié à un service pour Ingestion OpenSearch
Vous n’avez pas besoin de créer manuellement un rôle lié à un service. Lorsque vous [créez un pipeline d' OpenSearch ingestion](creating-pipeline.md#create-pipeline) dans l'API AWS Management Console AWS CLI, le ou l' AWS API, OpenSearch Ingestion crée le rôle lié au service pour vous.
Si vous supprimez ce rôle lié à un service et que vous avez ensuite besoin de le recréer, vous pouvez utiliser la même procédure pour recréer le rôle dans votre compte. Lorsque vous créez un pipeline d' OpenSearch OpenSearch ingestion, Ingestion crée à nouveau le rôle lié au service pour vous.
## Modification du rôle lié à un service pour Ingestion OpenSearch
OpenSearch L'ingestion ne vous permet pas de modifier le rôle `AWSServiceRoleForAmazonOpenSearchIngestionService` lié au service. Après avoir créé un rôle lié à un service, vous ne pouvez pas changer le nom du rôle, car plusieurs entités peuvent faire référence à ce rôle. Néanmoins, vous pouvez modifier la description du rôle à l’aide d’IAM. Pour plus d’informations, consultez [Modification d’un rôle lié à un service](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role) dans le *Guide de l’utilisateur IAM*.
## Suppression du rôle lié au service pour Ingestion OpenSearch
Si vous n’avez plus besoin d’utiliser une fonction ou un service qui nécessite un rôle lié à un service, nous vous recommandons de supprimer ce rôle. De cette façon, vous n’avez aucune entité inutilisée qui n’est pas surveillée ou gérée activement. Cependant, vous devez nettoyer les ressources de votre rôle lié à un service avant de pouvoir les supprimer manuellement.
### Nettoyage d’un rôle lié à un service
Avant de pouvoir utiliser IAM pour supprimer un rôle lié à un service, vous devez supprimer toutes les ressources utilisées par le rôle.
**Note**
Si OpenSearch Ingestion utilise le rôle lorsque vous essayez de supprimer les ressources, la suppression risque d'échouer. Si cela se produit, patientez quelques minutes et réessayez.
**Pour supprimer les ressources OpenSearch d'ingestion utilisées par le `AWSServiceRoleForOpensearchIngestionSelfManagedVpce` rôle `AWSServiceRoleForAmazonOpenSearchIngestionService` or**
1. Accédez à la console Amazon OpenSearch Service et choisissez **Ingestion**.
1. Supprimez tous les pipelines. Pour obtenir des instructions, veuillez consulter [Suppression des pipelines OpenSearch Amazon Ingestion](delete-pipeline.md).
### Supprimer le rôle lié au service pour Ingestion OpenSearch
Vous pouvez utiliser la console OpenSearch d'ingestion pour supprimer un rôle lié à un service.
**Pour supprimer un rôle lié à un service (console)**
1. Accédez à la Console IAM.
1. Choisissez **Rôles** et recherchez le **AWSServiceRoleForOpensearchIngestionSelfManagedVpce**rôle **AWSServiceRoleForAmazonOpenSearchIngestionService**ou.
1. Sélectionnez le rôle, puis cliquez **sur Supprimer**.