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 aux données pour Amazon OpenSearch Serverless Grâce au contrôle d'accès aux données dans Amazon OpenSearch Serverless, vous pouvez autoriser les utilisateurs à accéder aux collections et aux index, quel que soit leur mécanisme d'accès ou leur source réseau. Vous pouvez accorder l'accès aux rôles IAM et aux [identités SAML](serverless-saml.md). Vous gérez les autorisations d'accès par le biais de *stratégies d'accès aux données*, qui s'appliquent aux collections et aux ressources d'index. Les stratégies d'accès aux données vous permettent de gérer les collections à grande échelle en attribuant automatiquement des autorisations d'accès aux collections et aux index qui correspondent à un modèle spécifique. Plusieurs stratégies d'accès aux données peuvent s'appliquer à une seule ressource. Notez que vous devez disposer d'une politique d'accès aux données pour votre collection afin d'accéder à l'URL de vos OpenSearch tableaux de bord. **Topics** + [Stratégies d'accès aux données ou politiques IAM](#serverless-data-access-vs-iam) + [Autorisations IAM requises pour configurer les politiques d'accès aux données](#serverless-data-access-permissions) + [Syntaxe d’une politique](#serverless-data-access-syntax) + [Autorisations de stratégies prises en charge](#serverless-data-supported-permissions) + [Exemples de jeux de données sur les tableaux de bord OpenSearch](#serverless-data-sample-index) + [Création de stratégies d'accès aux données (console)](#serverless-data-access-console) + [Créer des stratégies d'accès aux données (AWS CLI)](#serverless-data-access-cli) + [Afficher les stratégies d'accès aux données](#serverless-data-access-list) + [Mettre à jour les stratégies d'accès aux données](#serverless-data-access-update) + [Supprimer des stratégies d'accès aux données](#serverless-data-access-delete) + [Accès aux données entre comptes](#serverless-data-access-cross) ## Stratégies d'accès aux données ou politiques IAM Les politiques d'accès aux données sont logiquement distinctes des politiques Gestion des identités et des accès AWS (IAM). Les autorisations IAM contrôlent l'accès aux [opérations d'API sans serveur](https://docs.aws.amazon.com/opensearch-service/latest/ServerlessAPIReference/Welcome.html), telles que `CreateCollection` et `ListAccessPolicies`. Les politiques d'accès aux données contrôlent l'accès aux [OpenSearch opérations prises](#serverless-data-supported-permissions) en charge par OpenSearch Serverless, telles que `PUT ` ou`GET _cat/indices`. Les autorisations IAM qui contrôlent l'accès aux opérations d'API de stratégie d'accès aux données, telles que `aoss:CreateAccessPolicy` et `aoss:GetAccessPolicy` (décrites dans la section suivante), n'affectent pas l'autorisation spécifiée dans une stratégie d'accès aux données. Supposons, par exemple, qu'une politique IAM empêche un utilisateur de créer des stratégies d'accès aux données pour `collection-a`, mais lui permette de créer des stratégies d'accès aux données pour toutes les collections (`*`) : ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Deny", "Action": [ "aoss:CreateAccessPolicy" ], "Resource": "*", "Condition": { "StringLike": { "aoss:collection": "collection-a" } } }, { "Effect": "Allow", "Action": [ "aoss:CreateAccessPolicy" ], "Resource": "*" } ] } ``` ------ Si l'utilisateur crée une stratégie d'accès aux données qui autorise certaines autorisations pour *toutes* les collections (`collection/*` ou `index/*/*`), la stratégie s'appliquera à toutes les collections, y compris la collection A. **Important** L'octroi d'autorisations dans le cadre d'une politique d'accès aux données n'est pas suffisant pour accéder aux données de votre collection OpenSearch Serverless. Un principal associé doit *également* avoir accès aux autorisations IAM `aoss:APIAccessAll` et`aoss:DashboardsAccessAll`. Les deux autorisations accordent un accès complet aux ressources de collection, tandis que l'autorisation Dashboards donne également accès aux OpenSearch Dashboards. Si un principal ne dispose pas de ces deux autorisations IAM, il recevra 403 erreurs lorsqu'il tentera d'envoyer des demandes à la collection. Pour de plus amples informations, veuillez consulter [Utilisation des opérations OpenSearch d'API](security-iam-serverless.md#security_iam_id-based-policy-examples-data-plane). ## Autorisations IAM requises pour configurer les politiques d'accès aux données Le contrôle d'accès aux données pour OpenSearch Serverless utilise les autorisations IAM suivantes. Vous pouvez spécifier des conditions IAM pour restreindre les utilisateurs à des noms de stratégie d'accès spécifiques. + `aoss:CreateAccessPolicy` : créer une stratégie d'accès. + `aoss:ListAccessPolicies` : répertorier toutes les stratégies d'accès. + `aoss:GetAccessPolicy` : afficher les informations relatives à une stratégie d'accès spécifique. + `aoss:UpdateAccessPolicy` : modifier une stratégie d'accès. + `aoss:DeleteAccessPolicy` : supprimer une stratégie d'accès. La stratégie d'accès basée sur l'identité suivante permet à un utilisateur de consulter toutes les stratégies d'accès et de mettre à jour les stratégies qui contiennent le modèle de ressource `collection/logs`. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Action": [ "aoss:ListAccessPolicies", "aoss:GetAccessPolicy" ], "Effect": "Allow", "Resource": "*" }, { "Action": [ "aoss:UpdateAccessPolicy" ], "Effect": "Allow", "Resource": "*", "Condition": { "StringEquals": { "aoss:collection": [ "logs" ] } } } ] } ``` ------ **Note** En outre, OpenSearch Serverless nécessite les `aoss:DashboardsAccessAll` autorisations `aoss:APIAccessAll` et pour les ressources de collecte. Pour de plus amples informations, veuillez consulter [Utilisation des opérations OpenSearch d'API](security-iam-serverless.md#security_iam_id-based-policy-examples-data-plane). ## Syntaxe d’une politique Une stratégie d'accès aux données inclut un jeu de règles, chacune avec les éléments suivants : | Element | Description | | --- | --- | | ResourceType | Type de ressource (collection ou index) auquel les autorisations s'appliquent. Les autorisations relatives aux alias et aux modèles se situent au niveau de la collection, tandis que les autorisations de création, de modification et de recherche de données se situent au niveau de l'index. Pour plus d'informations, veuillez consulter la rubrique [Autorisations de stratégie prises en charge](#serverless-data-supported-permissions). | | Resource | Liste de and/or modèles de noms de ressources. Les modèles sont des préfixes suivis d'un caractère générique (\$1), qui permettent aux autorisations associées de s'appliquer à plusieurs ressources.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/opensearch-service/latest/developerguide/serverless-data-access.html) | | Permission | Liste d'autorisations à accorder pour les ressources spécifiées. Pour obtenir une liste complète des autorisations et des opérations d'API qu'elles autorisent, veuillez consulter la rubrique [Opérations et autorisations d' OpenSearch API prises en charge](serverless-genref.md#serverless-operations). | | Principal | Liste d'un ou de plusieurs principaux auxquels accorder l'accès. Les principaux peuvent être un rôle IAM ARNs ou des identités SAML. Ces principaux doivent se trouver au sein du Compte AWS actuel. Les politiques d'accès aux données ne prennent pas directement en charge l'accès entre comptes, mais vous pouvez inclure dans votre politique un rôle qu'un utilisateur d'un autre compte Compte AWS peut assumer dans le compte propriétaire de la collection. Pour de plus amples informations, veuillez consulter [Accès aux données entre comptes](#serverless-data-access-cross). | L'exemple de stratégie suivant accorde des autorisations d'alias et de modèle à la collection nommée `autopartsinventory`, ainsi qu'à toutes les collections commençant par le préfixe `sales*`. Il accorde également des autorisations de lecture et d'écriture à tous les index de la collection `autopartsinventory`, ainsi qu'à tous les index de la collection `salesorders` commençant par le préfixe `orders*`. ``` [ { "Description": "Rule 1", "Rules":[ { "ResourceType":"collection", "Resource":[ "collection/autopartsinventory", "collection/sales*" ], "Permission":[ "aoss:CreateCollectionItems", "aoss:UpdateCollectionItems", "aoss:DescribeCollectionItems" ] }, { "ResourceType":"index", "Resource":[ "index/autopartsinventory/*", "index/salesorders/orders*" ], "Permission":[ "aoss:*" ] } ], "Principal":[ "arn:aws:iam::123456789012:user/Dale", "arn:aws:iam::123456789012:role/RegulatoryCompliance", "saml/123456789012/myprovider/user/Annie", "saml/123456789012/anotherprovider/group/Accounting" ] } ] ``` Vous ne pouvez pas refuser explicitement l'accès dans le cadre d'une stratégie. Par conséquent, toutes les autorisations de stratégies sont cumulatives. Par exemple, si une stratégie accorde à un utilisateur `aoss:ReadDocument` et qu'une autre stratégie accorde `aoss:WriteDocument`, l'utilisateur disposera des *deux* autorisations. Si une troisième stratégie accorde au même utilisateur `aoss:*`, celui-ci peut effectuer *toutes* les actions sur l'index associé. Les autorisations plus restrictives ne remplacent pas les autorisations moins restrictives. ## Autorisations de stratégies prises en charge Les autorisations suivantes sont prises en charge dans les stratégies d'accès aux données. Pour les opérations OpenSearch d'API autorisées par chaque autorisation, consultez[Opérations et autorisations d' OpenSearch API prises en charge](serverless-genref.md#serverless-operations). **Autorisations de collection** + `aoss:CreateCollectionItems` + `aoss:DeleteCollectionItems` + `aoss:UpdateCollectionItems` + `aoss:DescribeCollectionItems` + `aoss:*` **Autorisations d'index** + `aoss:ReadDocument` + `aoss:WriteDocument` + `aoss:CreateIndex` + `aoss:DeleteIndex` + `aoss:UpdateIndex` + `aoss:DescribeIndex` + `aoss:*` ## Exemples de jeux de données sur les tableaux de bord OpenSearch OpenSearch Les tableaux de bord fournissent des [exemples de jeux](https://opensearch.org/docs/latest/dashboards/quickstart-dashboards/#adding-sample-data) de données accompagnés de visualisations, de tableaux de bord et d'autres outils pour vous aider à explorer les tableaux de bord avant d'ajouter vos propres données. Pour créer des index à partir de ces exemples de données, vous avez besoin d'une politique d'accès aux données qui fournit des autorisations pour l'ensemble de données avec lequel vous souhaitez travailler. La politique suivante utilise un caractère générique (`*`) pour fournir des autorisations aux trois exemples de jeux de données. ``` [ { "Rules": [ { "Resource": [ "index//opensearch_dashboards_sample_data_*" ], "Permission": [ "aoss:CreateIndex", "aoss:DescribeIndex", "aoss:ReadDocument" ], "ResourceType": "index" } ], "Principal": [ "arn:aws:iam:::user/" ] } ] ``` ## Création de stratégies d'accès aux données (console) Vous pouvez créer une stratégie d'accès aux données à l'aide de l'éditeur visuel ou au format JSON. Toutes les nouvelles collections correspondant à l'un des modèles définis dans la stratégie se verront attribuer les autorisations correspondantes lors de la création de la collection. **Pour créer une politique d'accès aux données OpenSearch sans serveur** 1. Ouvrez la console Amazon OpenSearch Service à la [https://console.aws.amazon.com/aos/maison](https://console.aws.amazon.com/aos/home ). 1. Dans le volet de navigation de gauche, développez **Serverless** et sous **Sécurité**, choisissez **Politiques d'accès aux données**. 1. Choisissez **Create access policy** (Créer une stratégie d'accès). 1. Saisissez un nom et une description pour la stratégie. 1. Saisissez un nom pour la première règle de votre stratégie. Par exemple, « Accès à la collection de journaux ». 1. Choisissez **Add principals** (Ajouter des principaux) et sélectionnez un ou plusieurs rôles IAM ou [utilisateurs et groupes SAML](serverless-saml.md) pour accorder l'accès aux données. **Note** Pour sélectionner des principaux dans les menus déroulants, vous devez disposer des autorisations `iam:ListUsers` et `iam:ListRoles` (pour les principaux IAM) et de l'autorisation `aoss:ListSecurityConfigs` (pour les identités SAML). 1. Choisissez **Grant** (Accorder) et sélectionnez les autorisations d'alias, de modèle et d'index à accorder aux principaux associés. Pour obtenir la liste complète des autorisations et des accès qu'elles octroient, veuillez consulter la rubrique [Opérations et autorisations d' OpenSearch API prises en charge](serverless-genref.md#serverless-operations). 1. (Facultatif) Configurez des règles supplémentaires pour la stratégie. 1. Choisissez **Créer**. Il peut s'écouler environ une minute entre le moment où vous créez la stratégie et le moment où les autorisations sont appliquées. Si cela prend plus de 5 minutes, contactez [Support](https://console.aws.amazon.com/support/home). **Important** Si votre stratégie ne comprend que des autorisations d'index (et aucune autorisation de collection), vous pouvez toujours recevoir un message pour les collections correspondantes indiquant `Collection cannot be accessed yet. Configure data access policies so that users can access the data within this collection`. Vous pouvez ignorer cet avertissement. Les principaux autorisés peuvent toujours effectuer les opérations liées à l'index qui leur sont attribuées sur la collection. ## Créer des stratégies d'accès aux données (AWS CLI) Pour créer une politique d'accès aux données à l'aide de l'API OpenSearch Serverless, utilisez la `CreateAccessPolicy` commande. La commande accepte à la fois les stratégies en ligne et les fichiers .json. Les stratégies en ligne doivent être codées sous la forme d'une [chaîne d'échappement JSON](https://www.freeformatter.com/json-escape.html). La requête suivante crée une stratégie d'accès aux données : ``` aws opensearchserverless create-access-policy \ --name marketing \ --type data \ --policy "[{\"Rules\":[{\"ResourceType\":\"collection\",\"Resource\":[\"collection/autopartsinventory\",\"collection/sales*\"],\"Permission\":[\"aoss:UpdateCollectionItems\"]},{\"ResourceType\":\"index\",\"Resource\":[\"index/autopartsinventory/*\",\"index/salesorders/orders*\"],\"Permission\":[\"aoss:ReadDocument\",\"aoss:DescribeIndex\"]}],\"Principal\":[\"arn:aws:iam::123456789012:user/Shaheen\"]}]" ``` Pour fournir la stratégie dans un fichier .json, utilisez le format `--policy file://my-policy.json`. Les principaux inclus dans la politique peuvent désormais utiliser les [OpenSearch opérations](#serverless-data-supported-permissions) auxquelles ils ont été autorisés à accéder. ## Afficher les stratégies d'accès aux données Avant de créer une collection, vous souhaiterez peut-être prévisualiser les stratégies d'accès aux données existantes dans votre compte pour voir laquelle possède un modèle de ressource correspondant au nom de votre collection. La [ListAccessPolicies](https://docs.aws.amazon.com/opensearch-service/latest/ServerlessAPIReference/API_ListAccessPolicies.html)demande suivante répertorie toutes les politiques d'accès aux données de votre compte : ``` aws opensearchserverless list-access-policies --type data ``` La requête renvoie des informations sur toutes les stratégies d'accès aux données configurées. Pour consulter les règles de modèle définies dans une politique spécifique, recherchez les informations de stratégie dans le contenu de l'`accessPolicySummaries`élément de la réponse. Notez la `name` fin `type` de cette politique et utilisez ces propriétés dans une [GetAccessPolicy](https://docs.aws.amazon.com/opensearch-service/latest/ServerlessAPIReference/API_GetAccessPolicy.html)demande pour recevoir une réponse contenant les détails de politique suivants : ``` { "accessPolicyDetails": [ { "type": "data", "name": "my-policy", "policyVersion": "MTY2NDA1NDE4MDg1OF8x", "description": "My policy", "policy": "[{\"Rules\":[{\"ResourceType\":\"collection\",\"Resource\":[\"collection/autopartsinventory\",\"collection/sales*\"],\"Permission\":[\"aoss:UpdateCollectionItems\"]},{\"ResourceType\":\"index\",\"Resource\":[\"index/autopartsinventory/*\",\"index/salesorders/orders*\"],\"Permission\":[\"aoss:ReadDocument\",\"aoss:DescribeIndex\"]}],\"Principal\":[\"arn:aws:iam::123456789012:user/Shaheen\"]}]", "createdDate": 1664054180858, "lastModifiedDate": 1664054180858 } ] } ``` Vous pouvez inclure des filtres de ressources pour limiter les résultats aux stratégies contenant des collections ou des index spécifiques : ``` aws opensearchserverless list-access-policies --type data --resource "index/autopartsinventory/*" ``` Pour afficher les détails d'une politique spécifique, utilisez la [GetAccessPolicy](https://docs.aws.amazon.com/opensearch-service/latest/ServerlessAPIReference/API_GetAccessPolicy.html)commande. ## Mettre à jour les stratégies d'accès aux données Lorsque vous mettez à jour une stratégie d'accès aux données, toutes les collections associées sont affectées. Pour mettre à jour une politique d'accès aux données dans la console OpenSearch Serverless, choisissez **Contrôle d'accès aux données**, sélectionnez la politique à modifier, puis choisissez **Modifier**. Effectuez vos modifications, puis cliquez sur **Enregistrer**. Pour mettre à jour une politique d'accès aux données à l'aide de l'API OpenSearch Serverless, envoyez une `UpdateAccessPolicy` demande. Vous devez inclure une version de la stratégie, que vous pouvez récupérer à l'aide des commandes `ListAccessPolicies` ou `GetAccessPolicy`. En incluant la version la plus récente de la stratégie, vous vous assurez de ne pas annuler par inadvertance une modification apportée par quelqu'un d'autre. La [UpdateAccessPolicy](https://docs.aws.amazon.com/opensearch-service/latest/ServerlessAPIReference/API_UpdateAccessPolicy.html)demande suivante met à jour une politique d'accès aux données avec un nouveau document JSON de politique : ``` aws opensearchserverless update-access-policy \ --name sales-inventory \ --type data \ --policy-version MTY2NDA1NDE4MDg1OF8x \ --policy file://my-new-policy.json ``` Il peut s'écouler quelques minutes entre le moment où vous mettez à jour la stratégie et le moment où les nouvelles autorisations sont appliquées. ## Supprimer des stratégies d'accès aux données Lorsque vous supprimez une stratégie d'accès aux données, toutes les collections associées perdent l'accès défini dans la stratégie. Assurez-vous que vos utilisateurs IAM et SAML disposent de l'accès approprié à la collection avant de supprimer une stratégie. Pour supprimer une politique dans la console OpenSearch Serverless, sélectionnez-la, puis choisissez **Supprimer**. Vous pouvez également utiliser la [DeleteAccessPolicy](https://docs.aws.amazon.com/opensearch-service/latest/ServerlessAPIReference/API_DeleteAccessPolicy.html)commande : ``` aws opensearchserverless delete-access-policy --name my-policy --type data ``` ## Accès aux données entre comptes Bien que vous ne puissiez pas créer de politique d'accès aux données avec une identité entre comptes ou des collections entre comptes, vous pouvez toujours configurer un accès entre comptes avec l'option assumer un rôle. Par exemple, s'il `account-a` possède une collection à laquelle il `account-b` faut accéder, l'utilisateur de `account-b` peut jouer un rôle dans`account-a`. Le rôle doit disposer des autorisations IAM `aoss:APIAccessAll` et `aoss:DashboardsAccessAll` être inclus dans la politique d'accès aux données sur`account-a`.