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.
# 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'
```