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. # Présentation de la sécurité dans Amazon OpenSearch Serverless Sécurité en mode OpenSearch Serverless La sécurité dans Amazon OpenSearch Serverless diffère fondamentalement de la sécurité dans Amazon OpenSearch Service pour les raisons suivantes : | Fonctionnalité | OpenSearch Service | OpenSearch Sans serveur | | --- | --- | --- | | Contrôle d'accès aux données | L'accès aux données est déterminé par des politiques IAM et un contrôle d'accès précis. | L'accès aux données est déterminé par des stratégies d'accès aux données. | | Chiffrement au repos | Le chiffrement au repos est facultatif pour les domaines. | Le chiffrement au repos est requis pour les collections. | | Configuration et administration de la sécurité | Vous devez configurer le réseau, le chiffrement et l'accès aux données individuellement pour chaque domaine. | Vous pouvez utiliser des stratégies de sécurité pour gérer les paramètres de sécurité de plusieurs collections à grande échelle. | Le schéma suivant illustre les composants de sécurité qui constituent une collection fonctionnelle. Une collection doit être associée à une clé de chiffrement, des paramètres d'accès réseau et une stratégie d'accès aux données accordant l'accès à ses ressources. ![\[Diagram showing encryption, network, data access, and authentication policies for a collection.\]](http://docs.aws.amazon.com/fr_fr/opensearch-service/latest/developerguide/images/serverless-security.png) **Topics** + [ ## Stratégies de chiffrement ](#serverless-security-encryption) + [ ## Stratégies réseau ](#serverless-security-network) + [ ## Stratégies d'accès aux données ](#serverless-security-data-access) + [ ## Authentification IAM et SAML ](#serverless-security-authentication) + [ ## Sécurité de l’infrastructure ](#serverless-infrastructure-security) + [ # Commencer à utiliser la sécurité dans Amazon OpenSearch Serverless ](serverless-tutorials.md) + [ # Identity and Access Management pour Amazon OpenSearch Serverless ](security-iam-serverless.md) + [ # Chiffrement dans Amazon OpenSearch Serverless ](serverless-encryption.md) + [ # Accès au réseau pour Amazon OpenSearch Serverless ](serverless-network.md) + [ # Conformité à la norme FIPS dans Amazon Serverless OpenSearch ](fips-compliance-opensearch-serverless.md) + [ # Contrôle d'accès aux données pour Amazon OpenSearch Serverless ](serverless-data-access.md) + [ # Accès au plan de données via AWS PrivateLink ](serverless-vpc.md) + [ # Accès au plan de contrôle via AWS PrivateLink ](serverless-vpc-cp.md) + [ # Authentification SAML pour Amazon Serverless OpenSearch ](serverless-saml.md) + [ # Validation de conformité pour Amazon OpenSearch Serverless ](serverless-compliance-validation.md) ## Stratégies de chiffrement Les [politiques de chiffrement](serverless-encryption.md) définissent si vos collections sont chiffrées à l'aide d'une clé gérée par le client Clé détenue par AWS ou d'une clé gérée par le client. Les stratégies de chiffrement sont constituées de deux composants : un **modèle de ressource** et une **clé de chiffrement**. Le modèle de ressource définit la ou les collections auxquelles la stratégie s'applique. La clé de chiffrement détermine la manière dont les collections associées seront sécurisées. Pour appliquer une stratégie à plusieurs collections, vous devez inclure un caractère générique (\$1) dans la règle de stratégie. Par exemple, la stratégie suivante s'appliquera à toutes les collections dont le nom commence par « logs ». ![\[Input field for specifying a prefix term or collection name, with "logs*" entered.\]](http://docs.aws.amazon.com/fr_fr/opensearch-service/latest/developerguide/images/serverless-security-encryption.png) Les stratégies de chiffrement simplifient le processus de création et de gestion des collections, en particulier lorsque vous procédez par programmation. Vous pouvez créer une collection en spécifiant un nom, et une clé de chiffrement lui est automatiquement attribuée lors de sa création. ## Stratégies réseau Les [politiques réseau](serverless-network.md) définissent si vos collections sont accessibles en privé ou via Internet à partir de réseaux publics. *Les collections privées sont accessibles via des points de terminaison OpenSearch VPC gérés sans serveur, ou par des utilisateurs spécifiques Services AWS tels qu'Amazon Bedrock utilisant un accès privé.Service AWS * Tout comme les stratégies de chiffrement, les stratégies réseau peuvent s'appliquer à plusieurs collections, ce qui vous permet de gérer l'accès réseau à de nombreuses collections à grande échelle. Les stratégies réseau sont constituées de deux composants : un **type d'accès** et un **type de ressource**. Le type d'accès peut être public ou privé. Le type de ressource détermine si l'accès que vous choisissez s'applique au point de terminaison de collecte, au point de terminaison OpenSearch des tableaux de bord ou aux deux. ![\[Access type and resource type options for configuring network policies in OpenSearch.\]](http://docs.aws.amazon.com/fr_fr/opensearch-service/latest/developerguide/images/serverless-security-network.png) Si vous envisagez de configurer l'accès VPC dans le cadre d'une politique réseau, vous devez d'abord créer un ou plusieurs points de terminaison VPC gérés [OpenSearch sans serveur](serverless-vpc.md). Ces points de terminaison vous permettent d'accéder à OpenSearch Serverless comme s'il se trouvait dans votre VPC, sans utiliser de passerelle Internet, de périphérique NAT, de connexion VPN ou de connexion. Direct Connect L'accès privé à ne Services AWS peut s'appliquer qu'au point de OpenSearch terminaison de la collection, et non au point de terminaison OpenSearch des tableaux de bord. Services AWS ne peut pas être autorisé à accéder aux OpenSearch tableaux de bord. ## Stratégies d'accès aux données Les [stratégies d'accès aux données](serverless-data-access.md) définissent la manière dont vos utilisateurs accèdent aux données de vos collections. 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 peuvent s'appliquer à une seule ressource. Les stratégies d'accès aux données se composent d'un ensemble de règles, chacune comportant trois éléments : un **type de ressource**, des **ressources octroyées** et un ensemble d'**autorisations**. Le type de ressource peut être une collection ou un index. Les ressources accordées peuvent être collection/index des noms ou des modèles avec un caractère générique (\$1). La liste des autorisations indique les [opérations OpenSearch d'API](serverless-genref.md#serverless-operations) auxquelles la politique accorde l'accès. En outre, la stratégie contient une liste de **principaux** qui spécifient les rôles IAM, les utilisateurs et les identités SAML auxquels accorder l'accès. ![\[Selected principals and granted resources with permissions for collection and index access.\]](http://docs.aws.amazon.com/fr_fr/opensearch-service/latest/developerguide/images/serverless-data-access.png) Pour plus d'informations sur le format d'une stratégie d'accès aux données, veuillez consulter la rubrique relative à la [syntaxe de la stratégie](serverless-data-access.md#serverless-data-access-syntax). Avant de créer une stratégie d'accès aux données, vous devez disposer d'un ou de plusieurs rôles ou utilisateurs IAM ou d'identités SAML, à qui accorder l'accès dans la stratégie. Pour plus de détails, veuillez consulter la section suivante. **Note** Le passage de l'accès public à l'accès privé pour votre collection supprimera l'onglet Indexes de la console de collecte OpenSearch sans serveur. ## Authentification IAM et SAML Les principaux IAM et les identités SAML constituent les éléments de base d'une stratégie d'accès aux données. Dans l'instruction `principal` d'une stratégie d'accès, vous pouvez inclure des rôles IAM, des utilisateurs et des identités SAML. Ces principaux se voient ensuite octroyer les autorisations que vous spécifiez dans les règles de stratégie associées. ``` [ { "Rules":[ { "ResourceType":"index", "Resource":[ "index/marketing/orders*" ], "Permission":[ "aoss:*" ] } ], "Principal":[ "arn:aws:iam::123456789012:user/Dale", "arn:aws:iam::123456789012:role/RegulatoryCompliance", "saml/123456789012/myprovider/user/Annie" ] } ] ``` Vous configurez l'authentification SAML directement dans OpenSearch Serverless. Pour de plus amples informations, veuillez consulter [Authentification SAML pour Amazon Serverless OpenSearch](serverless-saml.md). ## Sécurité de l’infrastructure Amazon OpenSearch Serverless 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 à Amazon OpenSearch Serverless via le réseau. Les clients doivent prendre en charge le protocole TLS (Transport Layer Security). Nous exigeons TLS 1.2 et recommandons TLS 1.3. Pour obtenir la liste des chiffrements pris en charge pour TLS 1.3, consultez la section [Protocoles et chiffrements TLS dans la documentation Elastic Load Balancing](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/create-tls-listener.html#tls-protocols-ciphers). En outre, vous devez signer les demandes à l'aide d'un identifiant de clé d'accès et d'une clé d'accès secrète associés à un principal IAM. Vous pouvez également utiliser [AWS Security Token Service](https://docs.aws.amazon.com/STS/latest/APIReference/Welcome.html) (AWS STS) pour générer des informations d’identification de sécurité temporaires et signer les demandes. # Commencer à utiliser la sécurité dans Amazon OpenSearch Serverless Démarrer avec la sécurité Les didacticiels suivants vous aideront à commencer à utiliser Amazon OpenSearch Serverless. Les deux didacticiels suivent les mêmes étapes de base, mais l'un utilise la console tandis que l'autre utilise l' AWS CLI. Veuillez noter que les cas d'utilisation présentés dans ces didacticiels sont simplifiés. Les stratégies réseau et de sécurité sont assez légères. Pour les charges de travail de production, nous vous recommandons de configurer des fonctionnalités de sécurité plus robustes telles que l'authentification SAML, l'accès au VPC et des stratégies d'accès aux données restrictives. **Topics** + [ # Tutoriel : prise en main de la sécurité dans Amazon OpenSearch Serverless (console) ](gsg-serverless.md) + [ # Tutoriel : prise en main de la sécurité dans Amazon OpenSearch Serverless (CLI) ](gsg-serverless-cli.md) # Tutoriel : prise en main de la sécurité dans Amazon OpenSearch Serverless (console) Didacticiel : démarrer avec la sécurité (console) Ce didacticiel explique les étapes de base pour créer et gérer des politiques de sécurité à l'aide de la console Amazon OpenSearch Serverless. Dans le cadre de ce didacticiel, vous suivrez les étapes suivantes : 1. [Configurer des autorisations](#gsgpermissions) 1. [Créer une stratégie de chiffrement](#gsg-encryption) 1. [Création d'une stratégie réseau](#gsg-network) 1. [Configuration d'une stratégie d'accès aux données](#gsg-data-access) 1. [Créer une collection](#gsgcreate-collection) 1. [Charger et rechercher des données](#gsgindex-collection) Ce didacticiel vous explique comment configurer une collection à l'aide du AWS Management Console. Pour les mêmes étapes à suivre lors de l'utilisation du AWS CLI, voir[Tutoriel : prise en main de la sécurité dans Amazon OpenSearch Serverless (CLI)](gsg-serverless-cli.md). ## Étape 1 : configurer des autorisations **Note** Vous pouvez ignorer cette étape si vous utilisez déjà une politique basée sur l'identité plus large, telle que `Action":"aoss:*"` ou `Action":"*"`. Toutefois, dans les environnements de production, nous vous recommandons de suivre le principe du moindre privilège et de n'attribuer que les autorisations minimales nécessaires pour effectuer une tâche. Afin de suivre ce didacticiel, vous devez disposer des autorisations IAM appropriées. Votre utilisateur ou votre rôle doit être associé à une [politique basée sur l'identité](security-iam-serverless.md#security-iam-serverless-id-based-policies) avec les autorisations minimales suivantes : ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Action": [ "aoss:ListCollections", "aoss:BatchGetCollection", "aoss:CreateCollection", "aoss:CreateSecurityPolicy", "aoss:GetSecurityPolicy", "aoss:ListSecurityPolicies", "aoss:CreateAccessPolicy", "aoss:GetAccessPolicy", "aoss:ListAccessPolicies" ], "Effect": "Allow", "Resource": "*" } ] } ``` ------ Pour obtenir la liste complète des autorisations OpenSearch sans serveur, consultez[Identity and Access Management pour Amazon OpenSearch Serverless](security-iam-serverless.md). ## Étape 2 : créer une stratégie de chiffrement Les [politiques de chiffrement](serverless-encryption.md) spécifient la AWS KMS clé que OpenSearch Serverless utilisera pour chiffrer la collection. Vous pouvez chiffrer des collections à l'aide d'une clé Clé gérée par AWS ou d'une autre clé. Par souci de simplicité, dans le cadre de ce didacticiel, nous allons chiffrer notre collection à l'aide d'une Clé gérée par AWS. **Créer une stratégie de chiffrement** 1. Ouvrez la console Amazon OpenSearch Service à la [https://console.aws.amazon.com/aos/maison](https://console.aws.amazon.com/aos/home ). 1. Développez **Serverless** (Sans serveur) dans le panneau de navigation de gauche et choisissez **Encryption policies** (Stratégies de chiffrement). 1. Choisissez **Create encryption policy** (Créer une stratégie de chiffrement). 1. Nommez la stratégie **books-policy**. Pour la description, saisissez **Encryption policy for books collection** (Stratégie de chiffrement pour la collection books). 1. Dans **Resources** (Ressources), saisissez **books** (livres), le nom que vous donnerez à votre collection. Si vous souhaitez être plus large, vous pouvez inclure un astérisque (`books*`) pour que la stratégie s'applique à toutes les collections commençant par le mot « books ». 1. Pour **le chiffrement**, maintenez **l'option Utiliser la clé AWS détenue** sélectionnée. 1. Choisissez **Créer**. ## Étape 3 : créer une politique réseau [Les politiques réseau](serverless-network.md) déterminent si votre collection est accessible via Internet à partir de réseaux publics ou si elle doit être accessible via des points de terminaison OpenSearch VPC gérés sans serveur. Dans le cadre de ce didacticiel, nous allons configurer l'accès public. **Créer une stratégie réseau** 1. Choisissez **Network policies** (Stratégies réseau) dans le panneau de navigation de gauche, puis **Create network policy** (Créer une stratégie réseau). 1. Nommez la stratégie **books-policy**. Pour la description, saisissez **Network policy for books collection** (Stratégie réseau pour la collection books). 1. Sous **Rule 1** (Règle 1), nommez la règle **Public access for books collection** (Accès public à la collection books). 1. Par souci de simplicité, dans le cadre de ce didacticiel, nous allons configurer l'accès public à la collection *books*. Pour le type d'accès, sélectionnez **Public**. 1. Nous allons accéder à la collection depuis les OpenSearch tableaux de bord. Pour ce faire, vous devez configurer l'accès réseau pour les tableaux de bord *et* le OpenSearch point de terminaison, sinon les tableaux de bord ne fonctionneront pas. Pour le type de ressource, activez à la fois **l'accès aux OpenSearch points de terminaison** et **l'accès aux OpenSearch tableaux de bord**. 1. Dans les deux zones de saisie, saisissez **Collection Name = books** (Nom de la collection = books). Ce paramètre réduit la portée de la stratégie afin qu'elle ne s'applique qu'à une seule collection (`books`). Votre règle devrait ressembler à ceci : ![\[Search interface showing two input fields for collection or prefix term selection, both set to "books".\]](http://docs.aws.amazon.com/fr_fr/opensearch-service/latest/developerguide/images/serverless-tutorial-network.png) 1. Choisissez **Créer**. ## Étape 4 : Création d'une politique d'accès aux données Les données de votre collection ne seront pas accessibles tant que vous n'aurez pas configuré l'accès aux données. Les [stratégies d'accès aux données](serverless-data-access.md) sont distinctes de la politique IAM basée sur l'identité que vous avez configurée à l'étape 1. Elles permettent aux utilisateurs d'accéder aux données réelles d'une collection. Dans le cadre de ce didacticiel, nous allons fournir à un seul utilisateur les autorisations requises pour indexer des données dans la collection *books*. **Créer une stratégie d'accès aux données** 1. Dans le panneau de navigation de gauche, choisissez **Data access policies** (Stratégies d'accès aux données), puis **Create access policy** (Créer une stratégie d'accès). 1. Nommez la stratégie **books-policy**. Pour la description, saisissez **Data access policy for books collection** (Stratégie d'accès aux données pour la collection books). 1. Sélectionnez **JSON** comme méthode de définition de stratégie et collez la stratégie suivante dans l'éditeur JSON. Remplacez l'ARN principal par l'ARN du compte que vous utiliserez pour vous connecter aux OpenSearch tableaux de bord et indexer les données. ``` [ { "Rules":[ { "ResourceType":"index", "Resource":[ "index/books/*" ], "Permission":[ "aoss:CreateIndex", "aoss:DescribeIndex", "aoss:ReadDocument", "aoss:WriteDocument", "aoss:UpdateIndex", "aoss:DeleteIndex" ] } ], "Principal":[ "arn:aws:iam::123456789012:user/my-user" ] } ] ``` Cette stratégie fournit à un seul utilisateur les autorisations minimales requises pour créer un index dans la collection *books*, indexer certaines données et les rechercher. 1. Choisissez **Créer**. ## Étape 5 : Création d'une collection Maintenant que vous avez configuré les stratégies de chiffrement et réseau, vous pouvez créer une collection correspondante et les paramètres de sécurité lui seront automatiquement appliqués. **Pour créer une collection OpenSearch sans serveur** 1. Choisissez **Collections** dans le panneau de navigation de gauche, puis choisissez **Create collection** (Créer une collection). 1. Nommez la collection **books**. 1. Pour le type de collection, choisissez **Search** (Rechercher). 1. Sous **Chiffrement**, OpenSearch Serverless vous informe que le nom de la collection correspond à la politique de `books-policy` chiffrement. 1. Dans **les paramètres d'accès au réseau**, OpenSearch Serverless vous informe que le nom de la collection correspond à la politique du `books-policy` réseau. 1. Choisissez **Suivant**. 1. Sous **Options de politique d'accès aux données**, OpenSearch Serverless vous informe que le nom de la collection correspond à la politique d'accès aux `books-policy` données. 1. Choisissez **Suivant**. 1. Vérifiez la configuration de la collection et choisissez **Submit** (Soumettre). L'initialisation des collections prend généralement moins d'une minute. ## Étape 6 : charger et rechercher des données Vous pouvez télécharger des données dans une collection OpenSearch sans serveur à l'aide de Postman ou de curl. Par souci de concision, ces exemples utilisent les **outils de développement** de la console OpenSearch Dashboards. **Indexer et rechercher des données dans une collection** 1. Choisissez **Collections** dans le panneau de navigation de gauche, puis choisissez la collection **books** pour afficher sa page des détails. 1. Choisissez l'URL OpenSearch des tableaux de bord pour la collection. L'URL est au format `https://collection-id.us-east-1.aoss.amazonaws.com/_dashboards`. 1. Connectez-vous aux OpenSearch tableaux de bord à l'aide des [clés AWS d'accès et secrètes](https://docs.aws.amazon.com/powershell/latest/userguide/pstools-appendix-sign-up.html) du principal que vous avez spécifiées dans votre politique d'accès aux données. 1. Dans OpenSearch Dashboards, ouvrez le menu de navigation de gauche et choisissez **Dev Tools**. 1. Pour créer un index unique appelé *books-index*, exécutez la commande suivante : ``` PUT books-index ``` ![\[OpenSearch Dashboards console showing PUT request for books-index with JSON response.\]](http://docs.aws.amazon.com/fr_fr/opensearch-service/latest/developerguide/images/serverless-createindex.png) 1. Pour indexer un seul document dans *books-index*, exécutez la commande suivante : ``` PUT books-index/_doc/1 { "title": "The Shining", "author": "Stephen King", "year": 1977 } ``` 1. Pour rechercher des données dans OpenSearch les tableaux de bord, vous devez configurer au moins un modèle d'index. OpenSearch utilise ces modèles pour identifier les index que vous souhaitez analyser. Ouvrez le menu principal Tableaux de bord et choisissez **Stack Management (Gestion de la pile)**, **Index Patterns (Modèles d'index)**, puis **Create index pattern (Créer un modèle d'index)**. Pour ce didacticiel, saisissez *books-index*. 1. Choisissez **Next step (Étape suivante)**, puis **Create index pattern (Créer un modèle d'index)**. Une fois le modèle créé, vous pouvez consulter les différents champs du document, comme `author` et `title`. 1. Pour commencer à effectuer des recherches sur vos données, ouvrez à nouveau le menu principal et choisissez **Discover** (Découvrir) ou utilisez l'[API de recherche](https://opensearch.org/docs/latest/opensearch/rest-api/search/). # Tutoriel : prise en main de la sécurité dans Amazon OpenSearch Serverless (CLI) Didacticiel : démarrer avec la sécurité (CLI) Ce didacticiel explique les étapes décrites dans le [didacticiel de démarrage de la console](gsg-serverless.md) pour la sécurité, mais utilise la console AWS CLI plutôt que la console OpenSearch de service. Dans le cadre de ce didacticiel, vous suivrez les étapes suivantes : 1. Création d'une politique d'autorisations IAM 1. Associer la politique IAM à un rôle IAM 1. Créer une politique de chiffrement 1. Création d'une stratégie réseau 1. Créer une collection 1. Configuration d'une stratégie d'accès aux données 1. Récupérer le point de terminaison de collecte 1. Téléchargez des données sur votre connexion 1. Rechercher des données dans votre collection L'objectif de ce didacticiel est de configurer une collection unique OpenSearch sans serveur avec des paramètres de chiffrement, de réseau et d'accès aux données assez simples. Par exemple, nous allons configurer l'accès au réseau public, un Clé gérée par AWS système de chiffrement et une politique d'accès aux données simplifiée qui accorde des autorisations minimales à un seul utilisateur. Dans un scénario de production, envisagez de mettre en œuvre une configuration plus robuste, notamment une authentification SAML, une clé de chiffrement personnalisée et un accès VPC. **Pour commencer à utiliser les politiques de sécurité dans OpenSearch Serverless** 1. **Note** Vous pouvez ignorer cette étape si vous utilisez déjà une politique basée sur l'identité plus large, telle que `Action":"aoss:*"` ou `Action":"*"`. Toutefois, dans les environnements de production, nous vous recommandons de suivre le principe du moindre privilège et de n'attribuer que les autorisations minimales nécessaires pour effectuer une tâche. Pour commencer, créez une Gestion des identités et des accès AWS politique avec les autorisations minimales requises pour effectuer les étapes de ce didacticiel. Nous nommerons la politique `TutorialPolicy` : ``` aws iam create-policy \ --policy-name TutorialPolicy \ --policy-document "{\"Version\": \"2012-10-17\",\"Statement\": [{\"Action\": [\"aoss:ListCollections\",\"aoss:BatchGetCollection\",\"aoss:CreateCollection\",\"aoss:CreateSecurityPolicy\",\"aoss:GetSecurityPolicy\",\"aoss:ListSecurityPolicies\",\"aoss:CreateAccessPolicy\",\"aoss:GetAccessPolicy\",\"aoss:ListAccessPolicies\"],\"Effect\": \"Allow\",\"Resource\": \"*\"}]}" ``` **Exemple de réponse** ``` { "Policy": { "PolicyName": "TutorialPolicy", "PolicyId": "ANPAW6WRAECKG6QJWUV7U", "Arn": "arn:aws:iam::123456789012:policy/TutorialPolicy", "Path": "/", "DefaultVersionId": "v1", "AttachmentCount": 0, "PermissionsBoundaryUsageCount": 0, "IsAttachable": true, "CreateDate": "2022-10-16T20:57:18+00:00", "UpdateDate": "2022-10-16T20:57:18+00:00" } } ``` 1. Attachez `TutorialPolicy` au rôle IAM qui indexera et recherchera les données dans la collection. Nous nommerons l'utilisateur `TutorialRole` : ``` aws iam attach-role-policy \ --role-name TutorialRole \ --policy-arn arn:aws:iam::123456789012:policy/TutorialPolicy ``` 1. Avant de créer une collection, vous devez créer une [stratégie de chiffrement](serverless-encryption.md) qui attribue une Clé détenue par AWS à la collection *books* que vous créerez ultérieurement. Envoyez la requête suivante afin de créer une stratégie de chiffrement pour la collection *books* : ``` aws opensearchserverless create-security-policy \ --name books-policy \ --type encryption --policy "{\"Rules\":[{\"ResourceType\":\"collection\",\"Resource\":[\"collection\/books\"]}],\"AWSOwnedKey\":true}" ``` **Exemple de réponse** ``` { "securityPolicyDetail": { "type": "encryption", "name": "books-policy", "policyVersion": "MTY2OTI0MDAwNTk5MF8x", "policy": { "Rules": [ { "Resource": [ "collection/books" ], "ResourceType": "collection" } ], "AWSOwnedKey": true }, "createdDate": 1669240005990, "lastModifiedDate": 1669240005990 } } ``` 1. Créez une [stratégie réseau](serverless-network.md) qui fournit un accès public à la collection *books* : ``` aws opensearchserverless create-security-policy --name books-policy --type network \ --policy "[{\"Description\":\"Public access for books collection\",\"Rules\":[{\"ResourceType\":\"dashboard\",\"Resource\":[\"collection\/books\"]},{\"ResourceType\":\"collection\",\"Resource\":[\"collection\/books\"]}],\"AllowFromPublic\":true}]" ``` **Exemple de réponse** ``` { "securityPolicyDetail": { "type": "network", "name": "books-policy", "policyVersion": "MTY2OTI0MDI1Njk1NV8x", "policy": [ { "Rules": [ { "Resource": [ "collection/books" ], "ResourceType": "dashboard" }, { "Resource": [ "collection/books" ], "ResourceType": "collection" } ], "AllowFromPublic": true, "Description": "Public access for books collection" } ], "createdDate": 1669240256955, "lastModifiedDate": 1669240256955 } } ``` 1. Créez la collection *books* : ``` aws opensearchserverless create-collection --name books --type SEARCH ``` **Exemple de réponse** ``` { "createCollectionDetail": { "id": "8kw362bpwg4gx9b2f6e0", "name": "books", "status": "CREATING", "type": "SEARCH", "arn": "arn:aws:aoss:us-east-1:123456789012:collection/8kw362bpwg4gx9b2f6e0", "kmsKeyArn": "auto", "createdDate": 1669240325037, "lastModifiedDate": 1669240325037 } } ``` 1. Créez une [stratégie d'accès aux données](serverless-data-access.md) qui fournit les autorisations minimales nécessaires pour indexer et rechercher des données dans la collection *books*. Remplacez l'ARN du principal par l'ARN du `TutorialRole` de l'étape 1 : ``` aws opensearchserverless create-access-policy \ --name books-policy \ --type data \ --policy "[{\"Rules\":[{\"ResourceType\":\"index\",\"Resource\":[\"index\/books\/books-index\"],\"Permission\":[\"aoss:CreateIndex\",\"aoss:DescribeIndex\",\"aoss:ReadDocument\",\"aoss:WriteDocument\",\"aoss:UpdateIndex\",\"aoss:DeleteIndex\"]}],\"Principal\":[\"arn:aws:iam::123456789012:role\/TutorialRole\"]}]" ``` **Exemple de réponse** ``` { "accessPolicyDetail": { "type": "data", "name": "books-policy", "policyVersion": "MTY2OTI0MDM5NDY1M18x", "policy": [ { "Rules": [ { "Resource": [ "index/books/books-index" ], "Permission": [ "aoss:CreateIndex", "aoss:DescribeIndex", "aoss:ReadDocument", "aoss:WriteDocument", "aoss:UpdateDocument", "aoss:DeleteDocument" ], "ResourceType": "index" } ], "Principal": [ "arn:aws:iam::123456789012:role/TutorialRole" ] } ], "createdDate": 1669240394653, "lastModifiedDate": 1669240394653 } } ``` `TutorialRole` devrait désormais pouvoir indexer et rechercher des documents dans la collection *books*. 1. Pour appeler l' OpenSearch API, vous avez besoin du point de terminaison de collecte. Envoyez la requête suivante pour récupérer le paramètre `collectionEndpoint` : ``` aws opensearchserverless batch-get-collection --names books ``` **Exemple de réponse** ``` { "collectionDetails": [ { "id": "8kw362bpwg4gx9b2f6e0", "name": "books", "status": "ACTIVE", "type": "SEARCH", "description": "", "arn": "arn:aws:aoss:us-east-1:123456789012:collection/8kw362bpwg4gx9b2f6e0", "createdDate": 1665765327107, "collectionEndpoint": "https://8kw362bpwg4gx9b2f6e0.us-east-1.aoss.amazonaws.com", "dashboardEndpoint": "https://8kw362bpwg4gx9b2f6e0.us-east-1.aoss.amazonaws.com/_dashboards" } ], "collectionErrorDetails": [] } ``` **Note** Vous ne pourrez pas voir le point de terminaison de la collection tant que le statut de la collection ne sera pas passé à `ACTIVE`. Vous devrez peut-être effectuer plusieurs appels pour vérifier le statut jusqu'à ce que la collection soit correctement créée. 1. Utilisez un outil HTTP tel que [Postman](https://www.getpostman.com/) ou curl pour indexer les données dans la collection *books*. Nous allons créer un index appelé *books-index* et ajouter un seul document. Envoyez la requête suivante au point de terminaison de collection que vous avez récupéré à l'étape précédente, à l'aide des informations d'identification de `TutorialRole`. ``` PUT https://8kw362bpwg4gx9b2f6e0.us-east-1.aoss.amazonaws.com/books-index/_doc/1 { "title": "The Shining", "author": "Stephen King", "year": 1977 } ``` **Exemple de réponse** ``` { "_index" : "books-index", "_id" : "1", "_version" : 1, "result" : "created", "_shards" : { "total" : 0, "successful" : 0, "failed" : 0 }, "_seq_no" : 0, "_primary_term" : 0 } ``` 1. Pour commencer à rechercher des données dans votre collection, utilisez l'[API de recherche](https://opensearch.org/docs/latest/opensearch/rest-api/search/). La requête suivante permet d'effectuer une recherche de base : ``` GET https://8kw362bpwg4gx9b2f6e0.us-east-1.aoss.amazonaws.com/books-index/_search ``` **Exemple de réponse** ``` { "took": 405, "timed_out": false, "_shards": { "total": 6, "successful": 6, "skipped": 0, "failed": 0 }, "hits": { "total": { "value": 2, "relation": "eq" }, "max_score": 1.0, "hits": [ { "_index": "books-index:0::3xJq14MBUaOS0wL26UU9:0", "_id": "F_bt4oMBLle5pYmm5q4T", "_score": 1.0, "_source": { "title": "The Shining", "author": "Stephen King", "year": 1977 } } ] } } ``` # Identity and Access Management pour Amazon OpenSearch Serverless Gestion de l’identité et des accès Gestion des identités et des accès AWS (IAM) est un outil Service AWS qui permet à un administrateur de contrôler en toute sécurité l'accès aux AWS ressources. Les administrateurs IAM contrôlent qui peut être *authentifié* (connecté) et *autorisé (autorisé*) à utiliser les ressources OpenSearch sans serveur. IAM est un Service AWS outil que vous pouvez utiliser sans frais supplémentaires. **Topics** + [ ## Politiques basées sur l'identité pour Serverless OpenSearch ](#security-iam-serverless-id-based-policies) + [ ## Actions stratégiques pour le mode OpenSearch Serverless ](#security-iam-serverless-id-based-policies-actions) + [ ## Ressources relatives aux politiques pour le mode OpenSearch Serverless ](#security-iam-serverless-id-based-policies-resources) + [ ## Clés de conditions de politique pour Amazon OpenSearch Serverless ](#security_iam_serverless-conditionkeys) + [ ## ABAC avec Serverless OpenSearch ](#security_iam_serverless-with-iam-tags) + [ ## Utilisation d'informations d'identification temporaires avec OpenSearch Serverless ](#security_iam_serverless-tempcreds) + [ ## Rôles liés à un service pour Serverless OpenSearch ](#security_iam_serverless-slr) + [ ## Autres types de politique ](#security_iam_access-manage-other-policies) + [ ## Exemples de politiques basées sur l'identité pour Serverless OpenSearch ](#security_iam_serverless_id-based-policy-examples) + [ # Support d'IAM Identity Center pour Amazon Serverless OpenSearch ](serverless-iam-identity-center.md) ## Politiques basées sur l'identité pour Serverless OpenSearch Politiques basées sur l’identité **Prend en charge les politiques basées sur l’identité :** oui Les politiques basées sur l’identité sont des documents de politique d’autorisations JSON que vous pouvez attacher à une identité telle qu’un utilisateur, un groupe d’utilisateurs ou un rôle IAM. Ces politiques contrôlent quel type d’actions des utilisateurs et des rôles peuvent exécuter, sur quelles ressources et dans quelles conditions. Pour découvrir comment créer une politique basée sur l’identité, consultez [Définition d’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*. Avec les politiques IAM basées sur l’identité, vous pouvez spécifier des actions et ressources autorisées ou refusées, ainsi que les conditions dans lesquelles les actions sont autorisées ou refusées. Pour découvrir tous les éléments que vous utilisez dans une politique JSON, consultez [Références des éléments de politique JSON IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html) dans le *Guide de l’utilisateur IAM*. ### Exemples de politiques basées sur l'identité pour Serverless OpenSearch Pour consulter des exemples de politiques basées sur l'identité OpenSearch sans serveur, consultez. [Exemples de politiques basées sur l'identité pour Serverless OpenSearch](#security_iam_serverless_id-based-policy-examples) ## Actions stratégiques pour le mode OpenSearch Serverless Actions de politique **Prend en charge les actions de politique :** oui L’élément `Action` d’une politique JSON décrit les actions que vous pouvez utiliser pour autoriser ou refuser l’accès à une politique. Les actions de stratégie portent généralement le même nom que l'opération AWS d'API associée. Il existe quelques exceptions, telles que les *actions avec autorisations uniquement* qui n’ont pas d’opération API correspondante. Certaines opérations nécessitent également plusieurs actions dans une politique. Ces actions supplémentaires sont nommées *actions dépendantes*. Intégration d’actions dans une politique afin d’accorder l’autorisation d’exécuter les opérations associées. Les actions de stratégie dans OpenSearch Serverless utilisent le préfixe suivant avant l'action : ``` aoss ``` Pour indiquer plusieurs actions dans une seule déclaration, séparez-les par des virgules. ``` "Action": [ "aoss:action1", "aoss:action2" ] ``` Vous pouvez préciser plusieurs actions à l'aide de caractères génériques (\$1). Par exemple, pour spécifier toutes les actions qui commencent par le mot `Describe`, incluez l’action suivante : ``` "Action": "aoss:List*" ``` Pour consulter des exemples de politiques basées sur l'identité OpenSearch sans serveur, consultez. [Exemples de politiques basées sur l'identité pour Serverless OpenSearch](#security_iam_id-based-policy-examples) ## Ressources relatives aux politiques pour le mode OpenSearch Serverless Ressources de politique **Prend en charge les ressources de politique :** oui Les administrateurs peuvent utiliser les politiques AWS JSON pour spécifier qui a accès à quoi. C’est-à-dire, quel **principal** peut effectuer **des actions** sur quelles **ressources** et dans quelles **conditions**. L’élément de politique JSON `Resource` indique le ou les objets auxquels l’action s’applique. Il est recommandé de définir une ressource à l’aide de son [Amazon Resource Name (ARN)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html). Pour les actions qui ne sont pas compatibles avec les autorisations de niveau ressource, utilisez un caractère générique (\$1) afin d’indiquer que l’instruction s’applique à toutes les ressources. ``` "Resource": "*" ``` ## Clés de conditions de politique pour Amazon OpenSearch Serverless Clés de condition de politique **Prend en charge les clés de condition de politique spécifiques au service :** oui Les administrateurs peuvent utiliser les politiques AWS JSON pour spécifier qui a accès à quoi. C’est-à-dire, quel **principal** peut effectuer **des actions** sur quelles **ressources** et dans quelles **conditions**. L’élément `Condition` indique à quel moment les instructions s’exécutent en fonction de critères définis. Vous pouvez créer des expressions conditionnelles qui utilisent des [opérateurs de condition](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html), tels que les signes égal ou inférieur à, pour faire correspondre la condition de la politique aux valeurs de la demande. Pour voir toutes les clés de condition AWS globales, voir les clés de [contexte de condition AWS globales](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) dans le *guide de l'utilisateur IAM*. Outre le contrôle d'accès basé sur les attributs (ABAC), OpenSearch Serverless prend en charge les clés de condition suivantes : + `aoss:collection` + `aoss:CollectionId` + `aoss:index` Vous pouvez même utiliser ces clés de condition afin de fournir des autorisations relatives aux stratégies d'accès et de sécurité. Par exemple : ``` [ { "Effect":"Allow", "Action":[ "aoss:CreateAccessPolicy", "aoss:CreateSecurityPolicy" ], "Resource":"*", "Condition":{ "StringLike":{ "aoss:collection":"log" } } } ] ``` Dans cet exemple, la condition s'applique aux stratégies qui contiennent des *règles* correspondant au nom ou au modèle d'une collection. Les conditions adoptent le comportement suivant : + `StringEquals` : s'applique aux stratégies dont les règles contiennent la chaîne de ressource *exacte* « log » (c'est-à-dire `collection/log`). + `StringLike` : s'applique aux stratégies dont les règles contiennent une chaîne de ressource qui *contient* la chaîne « log » (c'est-à-dire `collection/log`, mais également `collection/logs-application` ou `collection/applogs123`). **Note** Les clés de condition de *collection* ne s'appliquent pas au niveau de l'index. Par exemple, dans la stratégie ci-dessus, la condition ne s'appliquerait pas à une stratégie d'accès ou de sécurité contenant la chaîne de ressource `index/logs-application/*`. Pour consulter la liste des clés de condition OpenSearch sans serveur, consultez la section [Clés de condition pour Amazon OpenSearch Serverless](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonopensearchserverless.html#amazonopensearchserverless-policy-keys) dans la référence *d'autorisation de service*. Pour savoir avec quelles actions et ressources vous pouvez utiliser une clé de condition, consultez [Actions définies par Amazon OpenSearch Serverless](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonopensearchserverless.html#amazonopensearchserverless-actions-as-permissions). ## ABAC avec Serverless OpenSearch ABAC **Prise en charge d’ABAC (balises dans les politiques) :** Oui Le contrôle d’accès par attributs (ABAC) est une stratégie d’autorisation qui définit les autorisations en fonction des attributs appelés balises. Vous pouvez associer des balises aux entités et aux AWS ressources IAM, puis concevoir des politiques ABAC pour autoriser les opérations lorsque la balise du principal correspond à la balise de la ressource. Pour contrôler l’accès basé sur des étiquettes, vous devez fournir les informations d’étiquette dans l’[élément de condition](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) d’une politique utilisant les clés de condition `aws:ResourceTag/key-name`, `aws:RequestTag/key-name` ou `aws:TagKeys`. Si un service prend en charge les trois clés de condition pour tous les types de ressources, alors la valeur pour ce service est **Oui**. Si un service prend en charge les trois clés de condition pour certains types de ressources uniquement, la valeur est **Partielle**. Pour plus d’informations sur ABAC, consultez [Définition d’autorisations avec l’autorisation ABAC](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) dans le *Guide de l’utilisateur IAM*. Pour accéder à un didacticiel décrivant les étapes de configuration de l’ABAC, consultez [Utilisation du contrôle d’accès par attributs (ABAC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html) dans le *Guide de l’utilisateur IAM*. Pour plus d'informations sur le balisage des ressources OpenSearch sans serveur, consultez. [Marquage des collections Amazon OpenSearch Serverless](tag-collection.md) ## Utilisation d'informations d'identification temporaires avec OpenSearch Serverless Informations d’identification temporaires **Prend en charge les informations d’identification temporaires :** oui Les informations d'identification temporaires fournissent un accès à court terme aux AWS ressources et sont automatiquement créées lorsque vous utilisez la fédération ou que vous changez de rôle. AWS recommande de générer dynamiquement des informations d'identification temporaires au lieu d'utiliser des clés d'accès à long terme. Pour plus d’informations, consultez [Informations d’identification de sécurité temporaires dans IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) et [Services AWS compatibles avec IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) dans le *Guide de l’utilisateur IAM*. ## Rôles liés à un service pour Serverless OpenSearch Rôles liés à un service **Prend en charge les rôles liés à un service :** oui Un rôle lié à un service est un type de rôle de service lié à un. Service AWS Le service peut endosser le rôle afin d’effectuer une action en votre nom. Les rôles liés à un service apparaissent dans votre Compte AWS répertoire et appartiennent au service. Un administrateur IAM peut consulter, mais ne peut pas modifier, les autorisations concernant les rôles liés à un service. Pour plus de détails sur la création et la gestion des rôles liés à un service OpenSearch sans serveur, consultez. [Utilisation de rôles liés à un service pour créer OpenSearch des collections sans serveur](serverless-service-linked-roles.md) ## Autres types de politique AWS prend en charge d'autres types de politiques moins courants. Ces types de politiques peuvent définir le nombre maximum d’autorisations qui vous sont accordées par des types de politiques plus courants. + **Politiques de contrôle des services (SCPs)** : SCPs politiques JSON qui spécifient les autorisations maximales pour une organisation ou une unité organisationnelle (UO) dans AWS Organizations. AWS Organizations est un service permettant de regrouper et de gérer de manière centralisée plusieurs AWS comptes détenus par votre entreprise. Si vous activez toutes les fonctionnalités d'une organisation, vous pouvez appliquer des politiques de contrôle des services (SCPs) à l'un ou à l'ensemble de vos comptes. Le SCP limite les autorisations pour les entités des comptes membres, y compris pour chaque utilisateur root AWS du compte. Pour plus d'informations sur les Organizations et consultez SCPs les [politiques de contrôle des services](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) dans le *Guide de AWS Organizations l'utilisateur*. + **Politiques de contrôle des ressources (RCPs)** : RCPs politiques JSON que vous pouvez utiliser pour définir le maximum d'autorisations disponibles pour les ressources de vos comptes sans mettre à jour les politiques IAM associées à chaque ressource que vous possédez. Le RCP limite les autorisations pour les ressources des comptes membres et peut avoir un impact sur les autorisations effectives pour les identités, y compris l'utilisateur root du AWS compte, qu'il appartienne ou non à votre organisation. Pour plus d'informations sur les Organizations RCPs, y compris une liste des AWS services compatibles RCPs, voir [Politiques de contrôle des ressources (RCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html) dans le *guide de AWS Organizations l'utilisateur*. ## Exemples de politiques basées sur l'identité pour Serverless OpenSearch Exemples de politiques basées sur l’identité Par défaut, les utilisateurs et les rôles ne sont pas autorisés à créer ou à modifier des ressources OpenSearch sans serveur. Pour octroyer aux utilisateurs des autorisations d’effectuer des actions sur les ressources dont ils ont besoin, un administrateur IAM peut créer des politiques IAM. Pour apprendre à créer une politique basée sur l’identité IAM à l’aide de ces exemples de documents de politique JSON, consultez [Création de politiques IAM (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html) dans le *Guide de l’utilisateur IAM*. Pour plus de détails sur les actions et les types de ressources définis par Amazon OpenSearch Serverless, y compris le format du ARNs pour chacun des types de ressources, consultez la section [Actions, ressources et clés de condition pour Amazon OpenSearch Serverless](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonopensearchserverless.html) dans le *Service Authorization Reference*. **Topics** + [ ### Bonnes pratiques en matière de stratégies ](#security_iam_serverless-policy-best-practices) + [ ### Utilisation de OpenSearch Serverless dans la console ](#security_iam_serverless_id-based-policy-examples-console) + [ ### Administration des OpenSearch collections sans serveur ](#security_iam_id-based-policy-examples-collection-admin) + [ ### Affichage de OpenSearch collections sans serveur ](#security_iam_id-based-policy-examples-view-collections) + [ ### Utilisation des opérations OpenSearch d'API ](#security_iam_id-based-policy-examples-data-plane) + [ ### ABAC pour les opérations d' OpenSearch API ](#security_iam_id-based-policy-examples-data-plane-abac) ### Bonnes pratiques en matière de stratégies Les politiques basées sur l'identité sont très puissantes. Ils déterminent si quelqu'un peut créer, accéder ou supprimer des ressources OpenSearch sans serveur dans votre compte. Ces actions peuvent entraîner des frais pour votre Compte AWS. Lorsque vous créez ou modifiez des politiques basées sur l’identité, suivez ces instructions et recommandations : Les politiques basées sur l'identité déterminent si quelqu'un peut créer, accéder ou supprimer des ressources OpenSearch sans serveur dans votre compte. Ces actions peuvent entraîner des frais pour votre Compte AWS. Lorsque vous créez ou modifiez des politiques basées sur l’identité, suivez ces instructions et recommandations : + **Commencez AWS par les politiques gérées et passez aux autorisations du moindre privilège : pour commencer à accorder des autorisations** à vos utilisateurs et à vos charges de travail, utilisez les *politiques AWS gérées* qui accordent des autorisations pour de nombreux cas d'utilisation courants. Ils sont disponibles dans votre Compte AWS. Nous vous recommandons de réduire davantage les autorisations en définissant des politiques gérées par les AWS clients spécifiques à vos cas d'utilisation. 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) ou [politiques gérées par AWS pour les activités professionnelles](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) dans le *Guide de l’utilisateur IAM*. + **Accordez les autorisations de moindre privilège** : lorsque vous définissez des autorisations avec des politiques IAM, accordez uniquement les autorisations nécessaires à l’exécution d’une seule tâche. Pour ce faire, vous définissez les actions qui peuvent être entreprises sur des ressources spécifiques dans des conditions spécifiques, également appelées *autorisations de moindre privilège*. Pour plus d’informations sur l’utilisation d’IAM pour appliquer des autorisations, consultez [politiques et autorisations dans IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) dans le *Guide de l’utilisateur IAM*. + **Utilisez des conditions dans les politiques IAM pour restreindre davantage l’accès** : vous pouvez ajouter une condition à vos politiques afin de limiter l’accès aux actions et aux ressources. Par exemple, vous pouvez écrire une condition de politique pour spécifier que toutes les demandes doivent être envoyées via SSL. Vous pouvez également utiliser des conditions pour accorder l'accès aux actions de service si elles sont utilisées par le biais d'un service spécifique Service AWS, tel que CloudFormation. Pour plus d’informations, consultez [Conditions pour éléments de politique JSON IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) dans le *Guide de l’utilisateur IAM*. + **Utilisez l’Analyseur d’accès IAM pour valider vos politiques IAM afin de garantir des autorisations sécurisées et fonctionnelles** : l’Analyseur d’accès IAM valide les politiques nouvelles et existantes de manière à ce que les politiques IAM respectent le langage de politique IAM (JSON) et les bonnes pratiques IAM. IAM Access Analyzer fournit plus de 100 vérifications de politiques et des recommandations exploitables pour vous aider à créer des politiques sécurisées et fonctionnelles. Pour plus d’informations, consultez [Validation de politiques avec IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html) dans le *Guide de l’utilisateur IAM*. + **Exiger l'authentification multifactorielle (MFA**) : si vous avez un scénario qui nécessite des utilisateurs IAM ou un utilisateur root, activez l'authentification MFA pour une sécurité accrue. Compte AWS Pour exiger la MFA lorsque des opérations d’API sont appelées, ajoutez des conditions MFA à vos politiques. Pour plus d’informations, consultez [Sécurisation de l’accès aux API avec MFA](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html) dans le *Guide de l’utilisateur IAM*. Pour plus d’informations sur les bonnes pratiques dans IAM, consultez [Bonnes pratiques de sécurité dans IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) dans le *Guide de l’utilisateur IAM*. ### Utilisation de OpenSearch Serverless dans la console Utilisation de la console Pour accéder à OpenSearch Serverless depuis la console de OpenSearch service, vous devez disposer d'un ensemble minimal d'autorisations. Ces autorisations doivent vous permettre de répertorier et d'afficher les informations relatives aux ressources OpenSearch Serverless de votre AWS compte. Si vous créez une stratégie basée sur l'identité qui est plus restrictive que les autorisations minimales requises, la console ne fonctionnera pas comme prévu pour les entités (telles que les rôles IAM) de cette stratégie. Il n'est pas nécessaire d'accorder des autorisations de console minimales aux utilisateurs qui appellent uniquement l'API AWS CLI ou l' AWS API. Autorisez plutôt l’accès à uniquement aux actions qui correspondent à l’opération d’API que vous tentez d’effectuer. La politique suivante permet à un utilisateur d'accéder à OpenSearch Serverless dans la console OpenSearch de service : ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Resource": "*", "Effect": "Allow", "Action": [ "aoss:ListCollections", "aoss:BatchGetCollection", "aoss:ListAccessPolicies", "aoss:ListSecurityConfigs", "aoss:ListSecurityPolicies", "aoss:ListTagsForResource", "aoss:ListVpcEndpoints", "aoss:GetAccessPolicy", "aoss:GetAccountSettings", "aoss:GetSecurityConfig", "aoss:GetSecurityPolicy" ] } ] } ``` ------ ### Administration des OpenSearch collections sans serveur Cette politique est un exemple de politique « d'administration des collections » qui permet à un utilisateur de gérer et d'administrer des collections Amazon OpenSearch Serverless. L'utilisateur peut créer, consulter et supprimer des collections. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Resource": "arn:aws:aoss:us-east-1:111122223333:collection/*", "Action": [ "aoss:CreateCollection", "aoss:DeleteCollection", "aoss:UpdateCollection" ], "Effect": "Allow" }, { "Resource": "*", "Action": [ "aoss:BatchGetCollection", "aoss:ListCollections", "aoss:CreateAccessPolicy", "aoss:CreateSecurityPolicy" ], "Effect": "Allow" } ] } ``` ------ ### Affichage de OpenSearch collections sans serveur Cet exemple de politique permet à un utilisateur de consulter les détails de toutes les collections Amazon OpenSearch Serverless de son compte. L'utilisateur ne peut pas modifier les collections ni les stratégies de sécurité associées. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Resource": "*", "Action": [ "aoss:ListAccessPolicies", "aoss:ListCollections", "aoss:ListSecurityPolicies", "aoss:ListTagsForResource", "aoss:BatchGetCollection" ], "Effect": "Allow" } ] } ``` ------ ### Utilisation des opérations OpenSearch d'API Les opérations d'API du plan de données comprennent les fonctions que vous utilisez dans OpenSearch Serverless pour obtenir de la valeur en temps réel du service. Les opérations de l'API du plan de contrôle comprennent les fonctions que vous utilisez pour configurer l'environnement. Pour accéder au plan de données APIs et aux OpenSearch tableaux de bord Amazon OpenSearch Serverless depuis le navigateur, vous devez ajouter deux autorisations IAM pour les ressources de collecte. Ces autorisations sont `aoss:APIAccessAll` et`aoss:DashboardsAccessAll`. **Note** À compter du 10 mai 2023, OpenSearch Serverless aura besoin de ces deux nouvelles autorisations IAM pour les ressources de collecte. L'`aoss:APIAccessAll`autorisation autorise l'accès au plan de données et l'`aoss:DashboardsAccessAll`autorisation autorise les OpenSearch tableaux de bord depuis le navigateur. L'échec de l'ajout des deux nouvelles autorisations IAM entraîne une erreur 403. Cet exemple de politique permet à un utilisateur d'accéder au plan de données APIs pour une collection spécifiée dans son compte et d'accéder aux OpenSearch tableaux de bord pour toutes les collections de son compte. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "aoss:APIAccessAll", "Resource": "arn:aws:aoss:us-east-1:111122223333:collection/collection-id" }, { "Effect": "Allow", "Action": "aoss:DashboardsAccessAll", "Resource": "arn:aws:aoss:us-east-1:111122223333:dashboards/default" } ] } ``` ------ Dans `aoss:APIAccessAll` les deux cas, `aoss:DashboardsAccessAll` accordez une autorisation IAM complète aux ressources de collection, tandis que l'autorisation Dashboards fournit également un accès aux OpenSearch Dashboards. Chaque autorisation fonctionne indépendamment, de sorte qu'un refus explicite `aoss:APIAccessAll` ne bloque pas l'`aoss:DashboardsAccessAll`accès aux ressources, y compris aux outils de développement. Il en va de même pour le démenti`aoss:DashboardsAccessAll`. OpenSearch Serverless prend en charge les clés de condition globales suivantes : + `aws:CalledVia` + `aws:CalledViaAWSService` + `aws:CalledViaFirst` + `aws:CalledViaLast` + `aws:CurrentTime` + `aws:EpochTime` + `aws:PrincipalAccount` + `aws:PrincipalArn` + `aws:PrincipallsAWSService` + `aws:PrincipalOrgID` + `aws:PrincipalOrgPaths` + `aws:PrincipalType` + `aws:PrincipalServiceName` + `aws:PrincipalServiceNamesList` + `aws:ResourceAccount` + `aws:ResourceOrgID` + `aws:ResourceOrgPaths` + `aws:RequestedRegion` + `aws:ResourceTag` + `aws:SourceIp` + `aws:SourceVpce` + `aws:SourceVpc` + `aws:userid` + `aws:username` + `aws:VpcSourceIp` Voici un exemple d'utilisation du bloc `aws:SourceIp` conditionnel de la politique IAM de votre principal pour les appels du plan de données : ``` "Condition": { "IpAddress": { "aws:SourceIp": "203.0.113.0" } } ``` Voici un exemple d'utilisation du bloc `aws:SourceVpc` conditionnel de la politique IAM de votre principal pour les appels du plan de données : ``` "Condition": { "StringEquals": { "aws:SourceVpc": "vpc-0fdd2445d8EXAMPLE" } } ``` En outre, un support est proposé pour les clés spécifiques à OpenSearch Serverless suivantes : + `aoss:CollectionId` + `aoss:collection` Voici un exemple d'utilisation du bloc `aoss:collection` conditionnel de la politique IAM de votre principal pour les appels du plan de données : ``` "Condition": { "StringLike": { "aoss:collection": "log-*" } } ``` ### ABAC pour les opérations d' OpenSearch API Les politiques basées sur l'identité vous permettent d'utiliser des balises pour contrôler l'accès au plan de données Amazon OpenSearch Serverless. APIs La politique suivante est un exemple permettant aux principaux attachés d'accéder au plan de données APIs si la collection possède la `team:devops` balise : ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "aoss:APIAccessAll", "Resource": "arn:aws:aoss:us-east-1:111122223333:collection/collection-id", "Condition": { "StringEquals": { "aws:ResourceTag/team": "devops" } } } ] } ``` ------ La politique suivante est un exemple de refus aux principaux attachés d'accéder au plan de données APIs et aux tableaux de bord si la collection possède le `environment:production` tag : ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Deny", "Action": [ "aoss:APIAccessAll", "aoss:DashboardsAccessAll" ], "Resource": "arn:aws:aoss:us-east-1:111122223333:collection/collection-id" } ] } ``` ------ Amazon OpenSearch Serverless ne prend pas en charge `RequestTag` les clés de condition `TagKeys` globales pour le plan APIs de données. # Support d'IAM Identity Center pour Amazon Serverless OpenSearch Support d'IAM Identity Center pour Amazon Serverless OpenSearch ## Support d'IAM Identity Center pour Amazon Serverless OpenSearch Vous pouvez utiliser les principes du centre d'identité IAM (utilisateurs et groupes) pour accéder aux données Amazon OpenSearch Serverless via Amazon Applications. OpenSearch Pour activer la prise en charge d'IAM Identity Center pour Amazon OpenSearch Serverless, vous devez activer l'utilisation d'IAM Identity Center. Pour en savoir plus sur la procédure à suivre, consultez [Qu'est-ce qu'IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html) ? **Note** Pour accéder aux collections Amazon OpenSearch Serverless à l'aide d'utilisateurs ou de groupes IAM Identity Center, vous devez utiliser la fonctionnalité OpenSearch UI (Applications). L'accès direct aux tableaux de bord OpenSearch sans serveur à l'aide des informations d'identification IAM Identity Center n'est pas pris en charge. Pour plus d'informations, consultez la section [Prise en main de l'interface OpenSearch utilisateur](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/application.html). Une fois l'instance IAM Identity Center créée, l'administrateur du compte client doit créer une application IAM Identity Center pour le service Amazon OpenSearch Serverless. Cela peut être fait en appelant le [CreateSecurityConfig:](https://docs.aws.amazon.com/opensearch-service/latest/ServerlessAPIReference/API_CreateSecurityConfig.html). L'administrateur du compte client peut spécifier les attributs qui seront utilisés pour autoriser la demande. Les attributs par défaut utilisés sont `UserId` et `GroupId.` L'intégration du centre d'identité IAM pour Amazon OpenSearch Serverless utilise les autorisations AWS IAM Identity Center (IAM) suivantes : + `aoss:CreateSecurityConfig`— Créez un fournisseur de centre d'identité IAM + `aoss:ListSecurityConfig`— Répertoriez tous les fournisseurs IAM Identity Center du compte courant. + `aoss:GetSecurityConfig`— Afficher les informations du fournisseur IAM Identity Center. + `aoss:UpdateSecurityConfig`— Modifie une configuration IAM Identity Center donnée + `aoss:DeleteSecurityConfig`— Supprimez un fournisseur de centre d'identité IAM. La politique d'accès basée sur l'identité suivante peut être utilisée pour gérer toutes les configurations d'IAM Identity Center : ------ #### [ JSON ] **** ``` { "Version": "2012-10-17", "Statement": [ { "Action": [ "aoss:CreateSecurityConfig", "aoss:DeleteSecurityConfig", "aoss:GetSecurityConfig", "aoss:UpdateSecurityConfig", "aoss:ListSecurityConfigs" ], "Effect": "Allow", "Resource": "*" } ] } ``` ------ **Note** L'`Resource`élément doit être un caractère générique. ## Création d'un fournisseur de centre d'identité IAM (console) Vous pouvez créer un fournisseur de centre d'identité IAM pour activer l'authentification avec l' OpenSearchapplication. Pour activer l'authentification IAM Identity Center pour les OpenSearch tableaux de bord, effectuez les opérations suivantes : 1. Connectez-vous à la [console Amazon OpenSearch Service](https://console.aws.amazon.com/aos/home.). 1. Dans le panneau de navigation de gauche, développez **Serverless** et choisissez **Authentication**. 1. Choisissez **l'authentification IAM Identity Center**. 1. Sélectionnez **Modifier** 1. Cochez la case à côté de Authentifier auprès d'IAM Identity Center. 1. Sélectionnez la clé d'attribut de l'**utilisateur et du groupe** dans le menu déroulant. Les attributs utilisateur seront utilisés pour autoriser les utilisateurs en fonction de `UserName``UserId`, et`Email`. Les attributs de groupe seront utilisés pour authentifier les utilisateurs en fonction de `GroupName` et`GroupId`. 1. Sélectionnez l'instance **IAM Identity Center**. 1. Sélectionnez **Enregistrer** ## Création d'un fournisseur de centre d'identité IAM ()AWS CLI Pour créer un fournisseur de centre d'identité IAM à l'aide de AWS Command Line Interface (AWS CLI), utilisez la commande suivante : ``` aws opensearchserverless create-security-config \ --region us-east-2 \ --name "iamidentitycenter-config" \ --description "description" \ --type "iamidentitycenter" \ --iam-identity-center-options '{ "instanceArn": "arn:aws:sso:::instance/ssoins-99199c99e99ee999", "userAttribute": "UserName", "groupAttribute": "GroupId" }' ``` Une fois qu'un centre d'identité IAM est activé, les clients peuvent uniquement modifier les attributs des **utilisateurs et des groupes**. ``` aws opensearchserverless update-security-config \ --region us-east-1 \ --id \ --config-version \ --iam-identity-center-options-updates '{ "userAttribute": "UserId", "groupAttribute": "GroupId" }' ``` Pour afficher le fournisseur du centre d'identité IAM à l'aide de AWS Command Line Interface, utilisez la commande suivante : ``` aws opensearchserverless list-security-configs --type iamidentitycenter ``` ## Supprimer un fournisseur de centre d'identité IAM IAM Identity Center propose deux instances de fournisseurs, l'une pour le compte de votre organisation et l'autre pour votre compte de membre. Si vous devez modifier votre instance IAM Identity Center, vous devez supprimer votre configuration de sécurité via l'`DeleteSecurityConfig`API et créer une nouvelle configuration de sécurité à l'aide de la nouvelle instance IAM Identity Center. La commande suivante peut être utilisée pour supprimer un fournisseur IAM Identity Center : ``` aws opensearchserverless delete-security-config \ --region us-east-1 \ --id ``` ## Accorder à IAM Identity Center l'accès aux données de collecte Une fois que votre fournisseur de centre d'identité IAM est activé, vous pouvez mettre à jour la politique d'accès aux données de collecte afin d'inclure les principes du centre d'identité IAM. Les principes du IAM Identity Center doivent être mis à jour dans le format suivant : ``` [ { "Rules":[ ... ], "Principal":[ "iamidentitycenter//user/", "iamidentitycenter//group/" ] } ] ``` **Note** Amazon OpenSearch Serverless ne prend en charge qu'une seule instance IAM Identity Center pour toutes les collections de clients et 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 une incohérence dans le traitement des autorisations de votre politique d'accès aux données et vous recevrez un message `403` d'erreur. Vous pouvez octroyer l'accès aux collections, aux index ou aux deux. Si vous souhaitez que différents utilisateurs disposent d'autorisations différentes, vous devez créer plusieurs règles. Pour obtenir la liste des autorisations disponibles, consultez [Identity and Access Management in Amazon OpenSearch Service](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/ac.html). Pour plus d'informations sur le formatage d'une politique d'accès, consultez la section [Accorder aux identités SAML l'accès aux données de collecte](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/serverless-saml.html#serverless-saml-policies). # Chiffrement dans Amazon OpenSearch Serverless Chiffrement ## Chiffrement au repos Chaque collection Amazon OpenSearch Serverless que vous créez est protégée par 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. Encryption at rest utilise AWS Key Management Service (AWS KMS) pour stocker et gérer vos clés de chiffrement. Il utilise l'algorithme Advanced Encryption Standard avec des clés 256 bits (AES-256) afin de procéder au chiffrement. **Topics** + [ ### Stratégies de chiffrement ](#serverless-encryption-policies) + [ ### Considérations ](#serverless-encryption-considerations) + [ ### Autorisations nécessaires ](#serverless-encryption-permissions) + [ ### Politique de clé pour une clé gérée par le client ](#serverless-customer-cmk-policy) + [ ### Comment OpenSearch Serverless utilise les subventions dans AWS KMS ](#serverless-encryption-grants) + [ ### Créer des stratégies de chiffrement (console) ](#serverless-encryption-console) + [ ### Créer des stratégies de chiffrement (AWS CLI) ](#serverless-encryption-cli) + [ ### Affichage des stratégies de chiffrement ](#serverless-encryption-list) + [ ### Mise à jour des stratégies de chiffrement ](#serverless-encryption-update) + [ ### Supprimer des stratégies de chiffrement ](#serverless-encryption-delete) ### Stratégies de chiffrement Les stratégies de chiffrement vous permettent de gérer de nombreuses collections à grande échelle en attribuant automatiquement une clé de chiffrement aux collections nouvellement créées qui correspondent à un nom ou à un modèle spécifique. Lorsque vous créez une stratégie de chiffrement, vous pouvez soit spécifier un *préfixe*, qui est une règle de correspondance basée sur des caractères génériques, par exemple `MyCollection*`, soit saisir un nom de collection unique. Ensuite, lorsque vous créez une collection correspondant à ce nom ou à ce modèle de préfixe, la stratégie et la clé KMS correspondante lui sont automatiquement attribuées. Lorsque vous créez une collection, vous pouvez spécifier une AWS KMS clé de deux manières : par le biais de politiques de sécurité ou directement dans la `CreateCollection` demande. Si vous fournissez une AWS KMS clé dans le cadre de la `CreateCollection` demande, elle a priorité sur les politiques de sécurité correspondantes. Grâce à cette approche, vous avez la possibilité de remplacer les paramètres de chiffrement basés sur des politiques pour des collections spécifiques en cas de besoin. ![\[Encryption policy creation process with rules and collection matching to KMS key.\]](http://docs.aws.amazon.com/fr_fr/opensearch-service/latest/developerguide/images/serverless-encryption.png) Les stratégies de chiffrement comportent les éléments suivants : + `Rules` : une ou plusieurs règles de correspondance des collections, chacune comportant les sous-éléments suivants : + `ResourceType` : à l'heure actuelle, la seule option est « collection ». Les stratégies de chiffrement s'appliquent uniquement aux ressources de collection. + `Resource` : un ou plusieurs noms ou modèles de collection auxquels la stratégie s'appliquera, au format `collection/`. + `AWSOwnedKey` : si une Clé détenue par AWS doit être utilisée. + `KmsARN` : si vous définissez `AWSOwnedKey` sur false (faux), spécifiez l'Amazon Resource Name (ARN) de la clé KMS avec laquelle chiffrer les collections associées. Si vous incluez ce paramètre, OpenSearch Serverless l'`AWSOwnedKey`ignore. L'exemple de stratégie suivant attribuera une clé gérée par le client à toute collection future nommée `autopartsinventory`, ainsi qu'aux collections commençant par le terme « sales » (ventes) : ``` { "Rules":[ { "ResourceType":"collection", "Resource":[ "collection/autopartsinventory", "collection/sales*" ] } ], "AWSOwnedKey":false, "KmsARN":"arn:aws:kms:us-east-1:123456789012:key/93fd6da4-a317-4c17-bfe9-382b5d988b36" } ``` Même si une stratégie correspond au nom d'une collection, vous pouvez choisir de remplacer cette attribution automatique lors de la création de la collection si le modèle de ressource contient un caractère générique (\$1). Si vous choisissez de remplacer l'attribution automatique des clés, OpenSearch Serverless crée pour vous une politique de chiffrement nommée **auto-< *collection-name* >** et l'attache à la collection. La stratégie ne s'applique initialement qu'à une seule collection, mais vous pouvez la modifier pour inclure des collections supplémentaires. Si vous modifiez les règles de stratégie pour qu'elles ne correspondent plus à une collection, la clé KMS associée ne sera pas dissociée de cette collection. La collection reste toujours chiffrée à l'aide de sa clé de chiffrement initiale. Si vous souhaitez modifier la clé de chiffrement d'une collection, vous devez recréer la collection. Si les règles de plusieurs stratégies correspondent à une collection, la règle la plus spécifique est utilisée. Par exemple, si une stratégie contient une règle pour `collection/log*` et une autre pour `collection/logSpecial`, la clé de chiffrement de la seconde stratégie est utilisée, car elle est plus spécifique. Vous ne pouvez pas utiliser de nom ou de préfixe dans une politique s'il existe déjà dans une autre stratégie. OpenSearch Serverless affiche une erreur si vous essayez de configurer des modèles de ressources identiques dans différentes politiques de chiffrement. ### Considérations Tenez compte des éléments suivants lorsque vous configurez le chiffrement de vos collections : + Le chiffrement au repos est *requis* pour toutes les collections sans serveur. + Vous avez la possibilité d'utiliser une clé gérée par le client ou une Clé détenue par AWS. Si vous choisissez une clé gérée par le client, nous vous recommandons d'activer la [rotation automatique des clés](https://docs.aws.amazon.com/kms/latest/developerguide/rotate-keys.html). + Vous ne pouvez pas modifier la clé de chiffrement d'une collection après la création de la collection. Choisissez soigneusement celle que vous AWS KMS souhaitez utiliser la première fois que vous configurez une collection. + Une collection ne peut correspondre qu'à une seule stratégie de chiffrement. + Les collections dotées de clés KMS uniques ne peuvent pas partager d'unités de OpenSearch calcul (OCUs) avec d'autres collections. Chaque collection avec une clé unique nécessite ses propres 4 clés OCUs. + Si vous mettez à jour la clé KMS dans une stratégie de chiffrement, la modification n'affecte pas les collections correspondantes existantes auxquelles des clés KMS ont déjà été attribuées. + OpenSearch Serverless ne vérifie pas explicitement les autorisations des utilisateurs sur les clés gérées par le client. Si un utilisateur est autorisé à accéder à une collection par le biais d'une stratégie d'accès aux données, il pourra ingérer et interroger les données chiffrées à l'aide de la clé associée. ### Autorisations nécessaires Le chiffrement au repos pour OpenSearch Serverless utilise les autorisations Gestion des identités et des accès AWS (IAM) suivantes. Vous pouvez spécifier des conditions IAM pour restreindre les utilisateurs à des collections spécifiques. + `aoss:CreateSecurityPolicy` : créer une stratégie de chiffrement. + `aoss:ListSecurityPolicies` : répertorier toutes les stratégies de chiffrements et collections auxquelles elles sont associées. + `aoss:GetSecurityPolicy` : consulter les détails d'une stratégie de chiffrement spécifique. + `aoss:UpdateSecurityPolicy` : modifier une stratégie de chiffrement. + `aoss:DeleteSecurityPolicy` : supprimer une stratégie de chiffrement. L'exemple de stratégie d'accès basée sur l'identité suivant fournit les autorisations minimales nécessaires à un utilisateur pour gérer les stratégies de chiffrement à l'aide du modèle de ressource `collection/application-logs`. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement":[ { "Effect":"Allow", "Action":[ "aoss:CreateSecurityPolicy", "aoss:UpdateSecurityPolicy", "aoss:DeleteSecurityPolicy", "aoss:GetSecurityPolicy" ], "Resource":"*", "Condition":{ "StringEquals":{ "aoss:collection":"application-logs" } } }, { "Effect":"Allow", "Action":[ "aoss:ListSecurityPolicies" ], "Resource":"*" } ] } ``` ------ ### Politique de clé pour une clé gérée par le client Si vous sélectionnez une [clé gérée par le client](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk) pour protéger une collection, OpenSearch Serverless obtient l'autorisation d'utiliser la clé KMS au nom du principal qui effectue la sélection. Ce principal, un utilisateur ou un rôle, doit disposer des autorisations sur la clé KMS requises par OpenSearch Serverless. Vous pouvez fournir ces autorisations dans une [stratégie de clé](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html) ou une [politique IAM](https://docs.aws.amazon.com/kms/latest/developerguide/iam-policies.html). OpenSearch Serverless effectue `GenerateDataKey` des appels d'API `Decrypt` KMS lors d'opérations de maintenance telles que le dimensionnement automatique et les mises à jour logicielles. Il se peut que vous observiez ces appels en dehors de vos habitudes de trafic habituelles. Ces appels font partie du fonctionnement normal du service et n'indiquent pas un trafic utilisateur actif. OpenSearch Serverless lance un message `KMSKeyInaccessibleException` lorsqu'il ne peut pas accéder à la clé KMS qui chiffre vos données au repos. Cela se produit lorsque vous désactivez ou supprimez la clé KMS, ou lorsque vous révoquez les autorisations permettant à OpenSearch Serverless d'utiliser la clé. OpenSearch Serverless nécessite au minimum les autorisations suivantes sur une clé gérée par le client : + [km : DescribeKey](https://docs.aws.amazon.com/kms/latest/APIReference/API_DescribeKey.html) + [km : CreateGrant](https://docs.aws.amazon.com/kms/latest/APIReference/API_CreateGrant.html) Par exemple : ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Action": "kms:DescribeKey", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::123456789012:user/Dale" }, "Resource": "*", "Condition": { "StringEquals": { "kms:ViaService": "aoss.us-east-1.amazonaws.com" } } }, { "Action": "kms:CreateGrant", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::123456789012:user/Dale" }, "Resource": "*", "Condition": { "StringEquals": { "kms:ViaService": "aoss.us-east-1.amazonaws.com" }, "ForAllValues:StringEquals": { "kms:GrantOperations": [ "Decrypt", "GenerateDataKey" ] }, "Bool": { "kms:GrantIsForAWSResource": "true" } } } ] } ``` ------ OpenSearch Serverless crée une subvention avec les autorisations [kms : GenerateDataKey](https://docs.aws.amazon.com/kms/latest/APIReference/API_GenerateDataKey.html) et [KMS:Decrypt](https://docs.aws.amazon.com/kms/latest/APIReference/API_Decrypt.html). Pour de plus amples informations, veuillez consulter [Utilisation des politiques de clé AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html) dans le *AWS Key Management Service Guide du développeur*. ### Comment OpenSearch Serverless utilise les subventions dans AWS KMS Autorisations OpenSearch Serverless nécessite une [autorisation](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html) pour utiliser une clé gérée par le client. Lorsque vous créez une politique de chiffrement dans votre compte avec une nouvelle clé, OpenSearch Serverless crée une subvention en votre nom en envoyant une [CreateGrant](https://docs.aws.amazon.com/kms/latest/APIReference/API_CreateGrant.html)demande à AWS KMS. AWS KMS Les autorisations sont utilisées pour donner un accès OpenSearch sans serveur à une clé KMS dans un compte client. OpenSearch Serverless nécessite l'autorisation d'utiliser votre clé gérée par le client pour les opérations internes suivantes : + Envoyez [DescribeKey](https://docs.aws.amazon.com/kms/latest/APIReference/API_DescribeKey.html)des demandes AWS KMS à pour vérifier que l'ID de clé symétrique géré par le client fourni est valide. + Envoyez [GenerateDataKey](https://docs.aws.amazon.com/kms/latest/APIReference/API_GenerateDataKey.html)des demandes à KMS Key pour créer des clés de données avec lesquelles chiffrer des objets. + Envoyez des demandes de [déchiffrement](https://docs.aws.amazon.com/kms/latest/APIReference/API_Decrypt.html) AWS KMS à pour déchiffrer les clés de données chiffrées afin qu'elles puissent être utilisées pour chiffrer vos données. Vous pouvez révoquer l’accès à l’octroi ou supprimer l’accès du service à la clé gérée par le client à tout moment. Si vous le faites, OpenSearch Serverless ne pourra accéder à aucune des données chiffrées par la clé gérée par le client, ce qui affectera toutes les opérations qui dépendent de ces données, entraînant des `AccessDeniedException` erreurs et des échecs dans les flux de travail asynchrones. OpenSearch Serverless retire les autorisations dans un flux de travail asynchrone lorsqu'une clé gérée par le client n'est associée à aucune politique de sécurité ou à aucune collection. ### Créer des stratégies de chiffrement (console) Dans une stratégie de chiffrement, vous spécifiez une clé KMS et une série de modèles de collection auxquels la stratégie s'appliquera. Toutes les nouvelles collections correspondant à l'un des modèles définis dans la stratégie se verront attribuer les clés KMS correspondantes lors de la création de la collection. Nous vous recommandons de créer des stratégies de chiffrement *avant* de commencer à créer des collections. **Pour créer une politique de chiffrement 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 panneau de navigation de gauche, développez **Serverless** (Sans serveur) et choisissez **Encryption policies** (Stratégies de chiffrement). 1. Choisissez **Create encryption policy** (Créer une stratégie de chiffrement). 1. Saisissez un nom et une description pour la stratégie. 1. Sous **Resources** (Ressources), saisissez un ou plusieurs modèles de ressources pour cette stratégie de chiffrement. Toutes les collections nouvellement créées sur le Compte AWS et dans la région actuels qui correspondent à l'un des modèles sont automatiquement attribuées à cette stratégie. Par exemple, si vous saisissez `ApplicationLogs` (sans caractère générique) et que vous créez ultérieurement une collection portant ce nom, la stratégie et la clé KMS correspondante sont attribuées à cette collection. Vous pouvez également fournir un préfixe tel que `Logs*`, qui attribue la stratégie à toute nouvelle collection dont le nom commence par `Logs`. En utilisant des caractères génériques, vous pouvez gérer les paramètres de chiffrement de plusieurs collections à grande échelle. 1. Sous **Encryption** (Chiffrement), choisissez une clé KMS à utiliser. 1. Choisissez **Créer**. #### Étape suivante : créer des collections Après avoir configuré une ou plusieurs stratégies de chiffrement, vous pouvez commencer à créer des collections qui correspondent aux règles définies dans ces stratégies. Pour obtenir des instructions, veuillez consulter [Créer des collections](serverless-create.md). À l'étape **Chiffrements** de la création de la collection, OpenSearch Serverless vous informe que le nom que vous avez saisi correspond au modèle défini dans une politique de chiffrement et attribue automatiquement la clé KMS correspondante à la collection. Si le modèle de ressource contient un caractère générique (\$1), vous pouvez choisir de remplacer la correspondance et de sélectionner votre propre clé. ### Créer des stratégies de chiffrement (AWS CLI) Pour créer une politique de chiffrement à l'aide des opérations de l'API OpenSearch Serverless, vous devez spécifier des modèles de ressources et une clé de chiffrement au format JSON. La [CreateSecurityPolicy](https://docs.aws.amazon.com/opensearch-service/latest/ServerlessAPIReference/API_CreateSecurityPolicy.html)demande accepte à la fois les politiques intégrées et les fichiers .json. Les stratégies de chiffrement prennent le format suivant. Cet exemple de fichier `my-policy.json` correspond à toute future collection nommée `autopartsinventory`, ainsi qu'à toutes les collections dont le nom commence par `sales`. ``` { "Rules":[ { "ResourceType":"collection", "Resource":[ "collection/autopartsinventory", "collection/sales*" ] } ], "AWSOwnedKey":false, "KmsARN":"arn:aws:kms:us-east-1:123456789012:key/93fd6da4-a317-4c17-bfe9-382b5d988b36" } ``` Pour utiliser une clé appartenant au service, définissez `AWSOwnedKey` sur `true` : ``` { "Rules":[ { "ResourceType":"collection", "Resource":[ "collection/autopartsinventory", "collection/sales*" ] } ], "AWSOwnedKey":true } ``` La requête suivante crée la stratégie de chiffrement : ``` aws opensearchserverless create-security-policy \ --name sales-inventory \ --type encryption \ --policy file://my-policy.json ``` Utilisez ensuite l'opération [CreateCollection](https://docs.aws.amazon.com/opensearch-service/latest/ServerlessAPIReference/API_CreateCollection.html)API pour créer une ou plusieurs collections correspondant à l'un des modèles de ressources. ### Affichage des stratégies de chiffrement Avant de créer une collection, vous souhaiterez peut-être prévisualiser les stratégies de chiffrement existantes dans votre compte pour voir laquelle possède un modèle de ressource correspondant au nom de votre collection. La [ListSecurityPolicies](https://docs.aws.amazon.com/opensearch-service/latest/ServerlessAPIReference/API_ListSecurityPolicies.html)demande suivante répertorie toutes les politiques de chiffrement de votre compte : ``` aws opensearchserverless list-security-policies --type encryption ``` La requête renvoie des informations sur toutes les stratégies de chiffrement configurées. Utilisez le contenu de l'élément `policy` pour consulter les règles de modèle définies dans la stratégie : ``` { "securityPolicyDetails": [ { "createdDate": 1663693217826, "description": "Sample encryption policy", "lastModifiedDate": 1663693217826, "name": "my-policy", "policy": "{\"Rules\":[{\"ResourceType\":\"collection\",\"Resource\":[\"collection/autopartsinventory\",\"collection/sales*\"]}],\"AWSOwnedKey\":true}", "policyVersion": "MTY2MzY5MzIxNzgyNl8x", "type": "encryption" } ] } ``` Pour afficher des informations détaillées sur une politique spécifique, y compris la clé KMS, utilisez la [GetSecurityPolicy](https://docs.aws.amazon.com/opensearch-service/latest/ServerlessAPIReference/API_GetSecurityPolicy.html)commande. ### Mise à jour des stratégies de chiffrement Si vous mettez à jour la clé KMS dans une stratégie de chiffrement, la modification s'applique uniquement aux collections nouvellement créées qui correspondent au nom ou au modèle configuré. Cela n'affecte pas les collections existantes auxquelles des clés KMS ont déjà été attribuées. Il en va de même des règles de correspondance de stratégie. Si vous ajoutez, modifiez ou supprimez une règle, la modification ne s'applique qu'aux collections nouvellement créées. Les collections existantes ne perdent pas la clé KMS qui leur est attribuée si vous modifiez les règles d'une stratégie afin qu'elle ne corresponde plus au nom d'une collection. Pour mettre à jour une politique de chiffrement dans la console OpenSearch Serverless, choisissez **Politiques de chiffrement**, sélectionnez la politique à modifier, puis choisissez **Modifier**. Effectuez vos modifications, puis cliquez sur **Enregistrer**. Pour mettre à jour une politique de chiffrement à l'aide de l'API OpenSearch Serverless, utilisez l'[UpdateSecurityPolicy](https://docs.aws.amazon.com/opensearch-service/latest/ServerlessAPIReference/API_UpdateSecurityPolicy.html)opération. La requête suivante met à jour une stratégie de chiffrement avec un nouveau document JSON de stratégie : ``` aws opensearchserverless update-security-policy \ --name sales-inventory \ --type encryption \ --policy-version 2 \ --policy file://my-new-policy.json ``` ### Supprimer des stratégies de chiffrement Lorsque vous supprimez une stratégie de chiffrement, toutes les collections qui utilisent actuellement la clé KMS définie dans la stratégie ne sont pas affectées. Pour supprimer une politique dans la console OpenSearch Serverless, sélectionnez-la, puis choisissez **Supprimer**. Vous pouvez également utiliser l'[DeleteSecurityPolicy](https://docs.aws.amazon.com/opensearch-service/latest/ServerlessAPIReference/API_DeleteSecurityPolicy.html)opération : ``` aws opensearchserverless delete-security-policy --name my-policy --type encryption ``` ## Chiffrement en transit Dans OpenSearch Serverless, tous les chemins d'une collection sont chiffrés en transit à l'aide du protocole TLS (Transport Layer Security) avec un algorithme de chiffrement AES-256 conforme aux normes du secteur. L'accès à tous APIs et aux tableaux de bord pour Opensearch se fait également via TLS 1.2. Le protocole TLS est un ensemble de protocoles cryptographiques conformes aux normes de l'industrie utilisés pour chiffrer les informations échangées sur le réseau. # Accès au réseau pour Amazon OpenSearch Serverless Accès réseau Les paramètres réseau d'une collection Amazon OpenSearch Serverless déterminent si la collection est accessible via Internet à partir de réseaux publics ou si elle doit être accessible de manière privée. L'accès privé peut s'appliquer à l'un des éléments suivants ou aux deux : + OpenSearch Points de terminaison VPC gérés sans serveur + Supportés Services AWS , tels qu'Amazon Bedrock Vous pouvez configurer l'accès au réseau séparément pour le point de *OpenSearch*terminaison d'une collection et pour le point de terminaison *OpenSearch Dashboards* correspondant. L'accès réseau est le mécanisme d'isolation permettant l'accès à partir de différents réseaux source. Par exemple, si le point de terminaison OpenSearch des tableaux de bord d'une collection est accessible au public mais que le point de terminaison de l' OpenSearch API ne l'est pas, un utilisateur peut accéder aux données de la collection uniquement via les tableaux de bord lorsqu'il se connecte depuis un réseau public. S'ils essaient de les appeler OpenSearch APIs directement depuis un réseau public, ils seront bloqués. Les paramètres réseau peuvent être utilisés pour de telles permutations de la source au type de ressource. Amazon OpenSearch Serverless prend en charge les deux, IPv4 ainsi que la IPv6 connectivité. **Topics** + [ ## Stratégies réseau ](#serverless-network-policies) + [ ## Considérations ](#serverless-network-considerations) + [ ## Autorisations requises pour configurer les politiques réseau ](#serverless-network-permissions) + [ ## Priorité des stratégies ](#serverless-network-precedence) + [ ## Créer des stratégies réseau (console) ](#serverless-network-console) + [ ## Création de stratégies réseau (AWS CLI) ](#serverless-network-cli) + [ ## Affichage des stratégies réseau ](#serverless-network-list) + [ ## Mettre à jour des stratégies réseau ](#serverless-network-update) + [ ## Supprimer des stratégies réseau ](#serverless-network-delete) ## Stratégies réseau Les stratégies réseau vous permettent de gérer de nombreuses collections à grande échelle en attribuant automatiquement des paramètres d'accès réseau aux collections qui correspondent aux règles définies dans la stratégie. Dans une stratégie réseau, vous spécifiez une série de *règles*. Ces règles définissent les autorisations d'accès aux points de terminaison de collecte et aux points de terminaison des OpenSearch tableaux de bord. Chaque règle comprend un type d'accès (public ou privé) et un type de ressource (collection et/ou point de terminaison OpenSearch Dashboards). Pour chaque type de ressource (`collection` et `dashboard`), vous spécifiez une série de règles qui définissent à quelles collections la stratégie s'appliquera. Dans cet exemple de politique, la première règle spécifie l'accès du point de terminaison VPC à la fois au point de terminaison de collecte et au point de terminaison du tableau de bord pour toutes les collections commençant par le terme. `marketing*` Il spécifie également l'accès à Amazon Bedrock. **Note** L'accès privé à Services AWS Amazon Bedrock *ne s'applique qu'*au point de terminaison de la collection, et non au OpenSearch point de terminaison OpenSearch des tableaux de bord. Même si `ResourceType` c'est le cas`dashboard`, l'accès aux OpenSearch tableaux de bord Services AWS ne peut pas être accordé. La deuxième règle spécifie l'accès public à la collection `finance`, mais uniquement pour le point de terminaison de la collection (aucun accès aux tableaux de bord). ``` [ { "Description":"Marketing access", "Rules":[ { "ResourceType":"collection", "Resource":[ "collection/marketing*" ] }, { "ResourceType":"dashboard", "Resource":[ "collection/marketing*" ] } ], "AllowFromPublic":false, "SourceVPCEs":[ "vpce-050f79086ee71ac05" ], "SourceServices":[ "bedrock.amazonaws.com" ], }, { "Description":"Sales access", "Rules":[ { "ResourceType":"collection", "Resource":[ "collection/finance" ] } ], "AllowFromPublic":true } ] ``` Cette politique fournit un accès public uniquement aux OpenSearch tableaux de bord pour les collections commençant par « finance ». Toute tentative d'accès direct à l' OpenSearch API échouera. ``` [ { "Description": "Dashboards access", "Rules": [ { "ResourceType": "dashboard", "Resource": [ "collection/finance*" ] } ], "AllowFromPublic": true } ] ``` Les stratégies réseau peuvent s'appliquer aux collections existantes ainsi qu'aux collections futures. Par exemple, vous pouvez créer une collection, puis créer une stratégie réseau avec une règle correspondant au nom de la collection. Vous n'avez pas besoin de créer des stratégies réseau avant de créer des collections. ## Considérations Tenez compte des éléments suivants lorsque vous configurez l'accès réseau de vos collections : + Si vous envisagez de configurer l'accès au point de terminaison VPC pour une collection, vous devez d'abord créer au [OpenSearch moins un point de terminaison VPC géré sans serveur](serverless-vpc.md). + L'accès privé à Services AWS ne s'applique qu'au point de OpenSearch terminaison de la collection, et non au point de terminaison OpenSearch des tableaux de bord. Même si `ResourceType` c'est le cas`dashboard`, l'accès aux OpenSearch tableaux de bord Services AWS ne peut pas être accordé. + Si une collection est accessible depuis les réseaux publics, elle est également accessible depuis tous les points de terminaison VPC OpenSearch gérés sans serveur et depuis tous. Services AWS + Plusieurs stratégies réseau peuvent s'appliquer à une seule collection. Pour de plus amples informations, veuillez consulter [Priorité des stratégies](#serverless-network-precedence). ## Autorisations requises pour configurer les politiques réseau L'accès réseau pour OpenSearch Serverless utilise les autorisations Gestion des identités et des accès AWS (IAM) suivantes. Vous pouvez spécifier des conditions IAM pour restreindre les utilisateurs à des stratégies réseau associées à des collections spécifiques. + `aoss:CreateSecurityPolicy` : créer une stratégie d'accès au réseau. + `aoss:ListSecurityPolicies` : répertorier toutes les stratégies réseau du compte actuel. + `aoss:GetSecurityPolicy` : afficher une spécification de stratégie d'accès au réseau. + `aoss:UpdateSecurityPolicy` : modifier une stratégie d'accès réseau donnée et modifier l'ID du VPC ou la désignation d'accès public. + `aoss:DeleteSecurityPolicy` : supprimer une stratégie d'accès au réseau (après l'avoir détachée de toutes les collections). La stratégie d'accès basée sur l'identité suivante permet à un utilisateur de consulter toutes les stratégies réseau et de mettre à jour les stratégies qui contiennent le modèle de ressource `collection/application-logs` : ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "aoss:UpdateSecurityPolicy" ], "Resource": "*", "Condition": { "StringEquals": { "aoss:collection": "application-logs" } } }, { "Effect": "Allow", "Action": [ "aoss:ListSecurityPolicies", "aoss:GetSecurityPolicy" ], "Resource": "*" } ] } ``` ------ **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). ## Priorité des stratégies Dans certains cas, les règles de stratégie réseau se chevauchent, au sein des stratégies ou entre elles. Dans ce cas, une règle qui spécifie l'accès public remplace une règle qui spécifie l'accès privé pour toutes les collections communes aux *deux* règles. Par exemple, dans la stratégie suivante, les deux règles attribuent un accès réseau à la collection `finance`, mais une règle spécifie l'accès VPC tandis que l'autre spécifie l'accès public. Dans ce cas, l'accès public outrepasse l'accès VPC *uniquement pour la collection finance* (car il existe dans les deux règles), de sorte que la collection finance sera accessible depuis les réseaux publics. La collection sales (ventes) bénéficiera d'un accès VPC à partir du point de terminaison spécifié. ``` [ { "Description":"Rule 1", "Rules":[ { "ResourceType":"collection", "Resource":[ "collection/sales", "collection/finance" ] } ], "AllowFromPublic":false, "SourceVPCEs":[ "vpce-050f79086ee71ac05" ] }, { "Description":"Rule 2", "Rules":[ { "ResourceType":"collection", "Resource":[ "collection/finance" ] } ], "AllowFromPublic":true } ] ``` Si plusieurs points de terminaison d'un VPC issus de règles différentes s'appliquent à une collection, les règles s'additionnent et la collection sera accessible depuis tous les points de terminaison spécifiés. Si vous définissez `AllowFromPublic` `true` mais que vous fournissez également un ou plusieurs `SourceVPCEs` ou`SourceServices`, OpenSearch Serverless ignore les points de terminaison et les identifiants de service VPC, et les collections associées seront accessibles au public. ## Créer des stratégies réseau (console) Les stratégies réseau peuvent s'appliquer aux collections existantes ainsi qu'aux collections futures. Nous vous recommandons de créer des stratégies réseau avant de commencer à créer des collections. **Pour créer une politique réseau 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 panneau de navigation de gauche, développez **Serverless** (Sans serveur) et choisissez **Network policies** (Stratégies réseau). 1. Choisissez **Create network policy** (Créer une stratégie réseau). 1. Saisissez un nom et une description pour la stratégie. 1. Fournissez une ou plusieurs *règles*. Ces règles définissent les autorisations d'accès pour vos collections OpenSearch Serverless et leurs points de terminaison de OpenSearch Dashboards. Chaque règle contient les éléments suivants : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/opensearch-service/latest/developerguide/serverless-network.html) Pour chaque type de ressource que vous sélectionnez, vous pouvez choisir des collections existantes auxquelles appliquer les paramètres de politique, and/or créer un ou plusieurs modèles de ressources. Les modèles de ressources se composent d'un préfixe et d'un caractère générique (\$1) et définissent les collections auxquelles les paramètres de stratégie s'appliqueront. Par exemple, si vous incluez un modèle appelé `Marketing*`, les paramètres réseau de cette stratégie seront automatiquement appliqués à toutes les collections nouvelles ou existantes dont le nom commence par « Marketing ». Un seul caractère générique (`*`) applique la stratégie à toutes les collections actuelles et futures. En outre, vous pouvez spécifier le nom d'une *future* collection sans caractère générique, par exemple`Finance`. OpenSearch Serverless appliquera les paramètres de politique à toute collection nouvellement créée portant le même nom exact. 1. Lorsque la configuration de votre stratégie vous satisfait, choisissez **Create** (Créer). ## Création de stratégies réseau (AWS CLI) Pour créer une politique réseau à l'aide des opérations de l'API OpenSearch Serverless, vous devez spécifier des règles au format JSON. La [CreateSecurityPolicy](https://docs.aws.amazon.com/opensearch-service/latest/ServerlessAPIReference/API_CreateSecurityPolicy.html)demande accepte à la fois les politiques intégrées et les fichiers .json. Toutes les collections et tous les modèles doivent être sous la forme `collection/`. **Note** Le type de ressource autorise `dashboards` uniquement l'accès aux OpenSearch tableaux de bord, mais pour que les OpenSearch tableaux de bord fonctionnent, vous devez également autoriser l'accès aux collections à partir des mêmes sources. La deuxième stratégie ci-dessous sert d'exemple. Pour spécifier un accès privé, incluez l'un des éléments suivants ou les deux : + `SourceVPCEs`— Spécifiez un ou plusieurs points de OpenSearch terminaison VPC gérés sans serveur. + `SourceServices`— Spécifiez l'identifiant d'un ou de plusieurs appareils pris en charge Services AWS. Actuellement, les identifiants de service suivants sont pris en charge : + `bedrock.amazonaws.com`— Amazon Bedrock L'exemple de politique réseau suivant fournit un accès privé, à un point de terminaison VPC et à Amazon Bedrock, aux points de terminaison de collecte uniquement pour les collections commençant par le préfixe. `log*` Les utilisateurs authentifiés ne peuvent pas se connecter aux OpenSearch tableaux de bord ; ils ne peuvent accéder au point de terminaison de collecte que par programmation. ``` [ { "Description":"Private access for log collections", "Rules":[ { "ResourceType":"collection", "Resource":[ "collection/log*" ] } ], "AllowFromPublic":false, "SourceVPCEs":[ "vpce-050f79086ee71ac05" ], "SourceServices":[ "bedrock.amazonaws.com" ], } ] ``` La politique suivante fournit un accès public au OpenSearch point de terminaison *et* aux OpenSearch tableaux de bord pour une seule collection nommée`finance`. Si la collection n'existe pas, les paramètres réseau seront appliqués à la collection si et quand elle sera créée. ``` [ { "Description":"Public access for finance collection", "Rules":[ { "ResourceType":"dashboard", "Resource":[ "collection/finance" ] }, { "ResourceType":"collection", "Resource":[ "collection/finance" ] } ], "AllowFromPublic":true } ] ``` La requête suivante crée la stratégie réseau ci-dessus : ``` aws opensearchserverless create-security-policy \ --name sales-inventory \ --type network \ --policy "[{\"Description\":\"Public access for finance collection\",\"Rules\":[{\"ResourceType\":\"dashboard\",\"Resource\":[\"collection\/finance\"]},{\"ResourceType\":\"collection\",\"Resource\":[\"collection\/finance\"]}],\"AllowFromPublic\":true}]" ``` Pour fournir la stratégie dans un fichier JSON, utilisez le format `--policy file://my-policy.json`. ## Affichage des stratégies réseau Avant de créer une collection, vous souhaiterez peut-être prévisualiser les stratégies réseau existantes dans votre compte pour voir laquelle possède un modèle de ressource correspondant au nom de votre collection. La [ListSecurityPolicies](https://docs.aws.amazon.com/opensearch-service/latest/ServerlessAPIReference/API_ListSecurityPolicies.html)demande suivante répertorie toutes les politiques réseau de votre compte : ``` aws opensearchserverless list-security-policies --type network ``` La requête renvoie des informations sur toutes les stratégies réseau 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'`securityPolicySummaries`élément de la réponse. Notez la `name` fin `type` de cette politique et utilisez ces propriétés dans une [GetSecurityPolicy](https://docs.aws.amazon.com/opensearch-service/latest/ServerlessAPIReference/API_GetSecurityPolicy.html)demande pour recevoir une réponse contenant les détails de politique suivants : ``` { "securityPolicyDetail": [ { "type": "network", "name": "my-policy", "policyVersion": "MTY2MzY5MTY1MDA3Ml8x", "policy": "[{\"Description\":\"My network policy rule\",\"Rules\":[{\"ResourceType\":\"dashboard\",\"Resource\":[\"collection/*\"]}],\"AllowFromPublic\":true}]", "createdDate": 1663691650072, "lastModifiedDate": 1663691650072 } ] } ``` Pour afficher des informations détaillées sur une politique spécifique, utilisez la [GetSecurityPolicy](https://docs.aws.amazon.com/opensearch-service/latest/ServerlessAPIReference/API_GetSecurityPolicy.html)commande. ## Mettre à jour des stratégies réseau Lorsque vous modifiez les points de terminaison d'un VPC ou la désignation d'accès public pour un réseau, toutes les collections associées sont affectées. Pour mettre à jour une politique réseau dans la console OpenSearch Serverless, développez **les politiques réseau**, sélectionnez la politique à modifier, puis choisissez **Modifier**. Effectuez vos modifications, puis cliquez sur **Enregistrer**. Pour mettre à jour une politique réseau à l'aide de l'API OpenSearch Serverless, utilisez la [UpdateSecurityPolicy](https://docs.aws.amazon.com/opensearch-service/latest/ServerlessAPIReference/API_UpdateSecurityPolicy.html)commande. Vous devez inclure une version de stratégie dans la requête. Vous pouvez récupérer la version de stratégie à l'aide des commandes `ListSecurityPolicies` ou `GetSecurityPolicy`. 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 requête suivante met à jour une stratégie réseau avec un nouveau document JSON de stratégie : ``` aws opensearchserverless update-security-policy \ --name sales-inventory \ --type network \ --policy-version MTY2MzY5MTY1MDA3Ml8x \ --policy file://my-new-policy.json ``` ## Supprimer des stratégies réseau Avant de supprimer une stratégie réseau, vous devez la détacher de toutes les collections. Pour supprimer une politique dans la console OpenSearch Serverless, sélectionnez-la, puis choisissez **Supprimer**. Vous pouvez également utiliser la [DeleteSecurityPolicy](https://docs.aws.amazon.com/opensearch-service/latest/ServerlessAPIReference/API_DeleteSecurityPolicy.html)commande : ``` aws opensearchserverless delete-security-policy --name my-policy --type network ``` # Conformité à la norme FIPS dans Amazon Serverless OpenSearch Conformité FIPS Amazon OpenSearch Serverless prend en charge les normes fédérales de traitement de l'information (FIPS) 140-2, une norme gouvernementale américaine et canadienne qui spécifie les exigences de sécurité pour les modules cryptographiques qui protègent les informations sensibles. Lorsque vous vous connectez à des points de terminaison compatibles FIPS avec OpenSearch Serverless, les opérations cryptographiques sont effectuées à l'aide de bibliothèques cryptographiques validées par FIPS. OpenSearch Les points de terminaison FIPS sans serveur sont disponibles Régions AWS là où le protocole FIPS est pris en charge. Ces points de terminaison utilisent le protocole TLS 1.2 ou version ultérieure et des algorithmes cryptographiques validés par le protocole FIPS pour toutes les communications. Pour plus d'informations, consultez la section [Conformité à la norme FIPS](https://docs.aws.amazon.com/verified-access/latest/ug/fips-compliance.html) dans le *Guide de l'utilisateur de l'accès AWS vérifié*. **Topics** + [ ## Utilisation de points de terminaison FIPS avec Serverless OpenSearch ](#using-fips-endpoints-opensearch-serverless) + [ ## Utilisez les points de terminaison FIPS avec AWS SDKs ](#using-fips-endpoints-aws-sdks) + [ ## Configuration des groupes de sécurité pour les points de terminaison VPC ](#configuring-security-groups-vpc-endpoints) + [ ## Utiliser le point de terminaison VPC FIPS ](#using-fips-vpc-endpoint) + [ ## Vérifiez la conformité à la norme FIPS ](#verifying-fips-compliance) + [ # Résoudre les problèmes de connectivité des terminaux FIPS dans les zones hébergées privées ](serverless-fips-endpoint-issues.md) ## Utilisation de points de terminaison FIPS avec Serverless OpenSearch Régions AWS Lorsque la norme FIPS est prise en charge, les collections OpenSearch sans serveur sont accessibles via des points de terminaison standard et conformes à la norme FIPS. Pour plus d'informations, consultez la section [Conformité à la norme FIPS](https://docs.aws.amazon.com/verified-access/latest/ug/fips-compliance.html) dans le *Guide de l'utilisateur de l'accès AWS vérifié*. Dans les exemples suivants, remplacez *collection\$1id* et *Région AWS* par votre identifiant de collection et son Région AWS. + **Point de terminaison standard** —**https://*collection\$1id*.*Région AWS*.aoss.amazonaws.com**. + Point de terminaison **conforme à la norme FIPS —**. **https://*collection\$1id*.*Région AWS*.aoss-fips.amazonaws.com** De même, les OpenSearch tableaux de bord sont accessibles via des points de terminaison standard et conformes à la norme FIPS : + Point de **terminaison standard des tableaux** de bord —**https://*collection\$1id*.*Région AWS*.aoss.amazonaws.com/\$1dashboards**. + Point de terminaison de **tableaux de bord conforme à la norme FIPS —**. **https://*collection\$1id*.*Région AWS*.aoss-fips.amazonaws.com/\$1dashboards** **Note** Dans les régions compatibles FIPS, les points de terminaison standard et conformes à la norme FIPS fournissent une cryptographie conforme à la norme FIPS. **Les points de terminaison spécifiques à FIPS vous aident à répondre aux exigences de conformité qui imposent spécifiquement l'utilisation de points de terminaison dont le nom est FIPS.** ## Utilisez les points de terminaison FIPS avec AWS SDKs Lors de l'utilisation AWS SDKs, vous pouvez spécifier le point de terminaison FIPS lors de la création du client. Dans l'exemple suivant, remplacez *collection\$1id* et *Région AWS* par votre identifiant de collection et son Région AWS. ``` # Python SDK example from opensearchpy import OpenSearch, RequestsHttpConnection, AWSV4SignerAuth import boto3 host = '"https://collection_id.Région AWS.aoss-fips.amazonaws.com" region = 'us-west-2' service = 'aoss' credentials = boto3.Session().get_credentials() auth = AWSV4SignerAuth(credentials, region, service) client = OpenSearch( hosts = [{'host': host, 'port': 443}], http_auth = auth, use_ssl = True, verify_certs = True, connection_class = RequestsHttpConnection, pool_maxsize = 20 ) ``` ## Configuration des groupes de sécurité pour les points de terminaison VPC Pour garantir une communication correcte avec votre point de terminaison Amazon VPC (VPC) conforme à la norme FIPS, créez ou modifiez un groupe de sécurité afin d'autoriser le trafic HTTPS entrant (port TCP 443) en provenance des ressources de votre VPC qui doivent accéder à Serverless. OpenSearch Associez ensuite ce groupe de sécurité à votre point de terminaison VPC lors de la création ou en modifiant le point de terminaison après sa création. Pour plus d'informations, veuillez consulter [Création d'un groupe de sécurité](https://docs.aws.amazon.com/vpc/latest/userguide/creating-security-groups.html) dans le *Guide de l'utilisateur Amazon VPC*. ## Utiliser le point de terminaison VPC FIPS Après avoir créé le point de terminaison VPC conforme à la norme FIPS, vous pouvez l'utiliser pour OpenSearch accéder à Serverless à partir des ressources de votre VPC. Pour utiliser le point de terminaison pour les opérations d'API, configurez votre SDK pour utiliser le point de terminaison FIPS régional, comme décrit dans la [Utilisation de points de terminaison FIPS avec Serverless OpenSearch](#using-fips-endpoints-opensearch-serverless) section. Pour accéder aux OpenSearch tableaux de bord, utilisez l'URL des tableaux de bord spécifique à la collection, qui sera automatiquement acheminée via le point de terminaison VPC conforme à la norme FIPS lors de l'accès depuis votre VPC. Pour de plus amples informations, veuillez consulter [Utilisation de OpenSearch tableaux de bord avec Amazon Service OpenSearch](dashboards.md). ## Vérifiez la conformité à la norme FIPS Pour vérifier que vos connexions à OpenSearch Serverless utilisent une cryptographie conforme à la norme FIPS, utilisez-la AWS CloudTrail pour surveiller les appels d'API effectués vers Serverless. OpenSearch Vérifiez que le `eventSource` champ dans les CloudTrail journaux s'affiche `aoss-fips.amazonaws.com` pour les appels d'API. Pour accéder aux OpenSearch tableaux de bord, vous pouvez utiliser les outils de développement du navigateur pour inspecter les détails de connexion TLS et vérifier que des suites de chiffrement conformes à la norme FIPS sont utilisées. # Résoudre les problèmes de connectivité des terminaux FIPS dans les zones hébergées privées Résolution des problèmes liés aux zones hébergées privées FIPS Les points de terminaison FIPS fonctionnent avec les collections Amazon OpenSearch Serverless accessibles au public. Pour les collections VPC nouvellement créées qui utilisent des points de terminaison VPC nouvellement créés, les points de terminaison FIPS fonctionnent comme prévu. Pour les autres collections VPC, vous devrez peut-être effectuer une configuration manuelle pour garantir le bon fonctionnement des points de terminaison FIPS. **Pour configurer les zones hébergées privées FIPS dans Amazon Route 53** 1. Ouvrez la console Route 53 à l'adresse [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/). 1. Passez en revue vos zones hébergées : 1. Localisez les zones hébergées dans lesquelles se trouvent Régions AWS vos collections. 1. Vérifiez les modèles de dénomination des zones hébergées : + Format non FIPS :. `region.aoss.amazonaws.com` + Format FIPS :`region.aoss-fips.amazonaws.com`. 1. Vérifiez que le **type** de toutes vos zones hébergées est défini sur **Zone hébergée privée**. 1. Si la zone hébergée privée FIPS est absente : 1. Sélectionnez la zone hébergée privée non FIPS correspondante. 1. Copiez les VPCs informations **associées**. Par exemple : `vpc-1234567890abcdef0 | us-east-2`. 1. Trouvez l'enregistrement de domaine générique. Par exemple : `*.us-east-2.aoss.amazonaws.com`. 1. Copiez le **trafic Value/Route dans les** informations. Par exemple :`uoc1c1qsw7poexampleewjeno1pte3rw.3ym756xh7yj.aoss.searchservices.aws`. 1. Créez la zone hébergée privée FIPS : 1. Créez une nouvelle zone hébergée privée au format FIPS. Par exemple : `us-east-2.aoss-fips.amazonaws.com`. 1. Dans **Associated VPCs**, entrez les informations VPC que vous avez copiées depuis la zone hébergée privée non FIPS. 1. Ajoutez un nouvel enregistrement avec les paramètres suivants : 1. Nom de l'enregistrement : \$1 1. Type d'enregistrement : CNAME 1. Valeur : Entrez la **valeur/l'itinéraire du trafic vers** les informations que vous avez copiées précédemment. ## Problèmes courants Si vous rencontrez des problèmes de connectivité avec vos points de terminaison VPC conformes à la norme FIPS, utilisez les informations suivantes pour résoudre le problème. + Défaillances de résolution DNS : vous ne pouvez pas résoudre le nom de domaine du point de terminaison FIPS au sein de votre VPC + Expiration des délais de connexion : le délai d'expiration de vos demandes adressées au point de terminaison FIPS + Erreurs d'accès refusé - L'authentification ou l'autorisation échoue lors de l'utilisation de points de terminaison FIPS + Enregistrements de zone hébergée privée manquants pour les collections réservées aux VPN **Pour résoudre les problèmes de connectivité des terminaux FIPS** 1. Vérifiez la configuration de votre zone hébergée privée : 1. Vérifiez qu'une zone hébergée privée existe pour le domaine de point de terminaison FIPS (`*.region.aoss-fips.amazonaws.com`. 1. Vérifiez que la zone hébergée privée est associée au VPC approprié. Pour plus d'informations, consultez les [sections Zones hébergées privées](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/hosted- zones-private.html) dans le *guide du développeur Amazon Route 53* et [Gérer les noms DNS](https://docs.aws.amazon.com/vpc/latest/privatelink/manage-dns-names.html) dans le *AWS PrivateLink guide*. 1. Testez la résolution DNS : 1. Connectez-vous à une instance EC2 de votre VPC. 1. Exécutez la commande suivante : ``` nslookup collection-id.region.aoss-fips.amazonaws.com ``` 1. Vérifiez que la réponse inclut l'adresse IP privée de votre point de terminaison VPC. Pour plus d'informations, consultez les [politiques relatives aux points de terminaison](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints- access.html#endpoint-dns-verification) et [les attributs DNS](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc- dns-troubleshooting) dans le guide de l'*utilisateur Amazon VPC*. 1. Vérifiez les paramètres de votre groupe de sécurité : 1. Vérifiez que le groupe de sécurité attaché au point de terminaison VPC autorise le trafic HTTPS (port 443) provenant de vos ressources. 1. Vérifiez que les groupes de sécurité de vos ressources autorisent le trafic sortant vers le point de terminaison VPC. Pour plus d'informations, consultez [les politiques relatives aux terminaux](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-access.html#vpc-endpoint-security-groups) dans le *AWS PrivateLink guide* et les [groupes de sécurité](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-groups.html#SecurityGroupRules) dans le guide de l'*utilisateur Amazon VPC*. 1. Vérifiez la configuration de votre ACL réseau : 1. Vérifiez que le réseau ACLs autorise le trafic entre vos ressources et le point de terminaison VPC. Pour plus d'informations, consultez la section [Réseau ACLs](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network- acls.html#nacl-troubleshooting) dans le guide de l'*utilisateur Amazon VPC*. 1. Passez en revue votre politique en matière de terminaux : 1. Vérifiez que la politique de point de terminaison VPC autorise les actions requises sur vos ressources OpenSearch sans serveur. *Pour plus d'informations, consultez les sections [Autorisations de point de terminaison VPC requises](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/serverless-vpc.html#serverless-vpc-permissions) et [Politiques relatives aux points de terminaison dans le Guide](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints- access.html#vpc-endpoint-policies).AWS PrivateLink * **Astuce** Si vous utilisez des résolveurs DNS personnalisés dans votre VPC, configurez-les `*.amazonaws.com` pour transmettre les demandes de domaines aux AWS serveurs. # Contrôle d'accès aux données pour Amazon OpenSearch Serverless Contrôle d'accès aux données 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) Créer des stratégies d'accès aux données (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`. # Accès au plan de données via AWS PrivateLink Point de terminaison VPC du plan de données Amazon OpenSearch Serverless prend en charge deux types de AWS PrivateLink connexions pour les opérations du plan de contrôle et du plan de données. Les opérations du plan de contrôle incluent la création et la suppression de collections ainsi que la gestion des politiques d'accès. Les opérations du plan de données servent à indexer et à interroger des données au sein d'une collection. Cette page couvre les points de terminaison VPC du plan de données. Pour plus d'informations sur les AWS PrivateLink extrémités du plan de contrôle, consultez[Accès au plan de contrôle via AWS PrivateLink](serverless-vpc-cp.md). Vous pouvez l'utiliser AWS PrivateLink pour créer une connexion privée entre votre VPC et Amazon OpenSearch Serverless. Vous pouvez accéder à OpenSearch Serverless comme s'il se trouvait 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 à Serverless. Pour plus d'informations sur l'accès au réseau VPC, consultez [Modèles de connectivité réseau pour Amazon OpenSearch Serverless](https://aws.amazon.com/blogs/big-data/network-connectivity-patterns-for-amazon-opensearch-serverless/). Vous établissez cette connexion privée en créant un *point de terminaison d'interface* à technologie AWS PrivateLink. Nous créons une interface réseau du point de terminaison dans chaque sous-réseau que vous spécifiez pour le point de terminaison d'interface. Il s'agit d'interfaces réseau gérées par les demandeurs qui servent de point d'entrée pour le trafic destiné OpenSearch à Serverless. 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 *. **Topics** + [ ## Résolution DNS des points de terminaison de collecte ](#vpc-endpoint-dnc) + [ ## VPCs et politiques d'accès au réseau ](#vpc-endpoint-network) + [ ## VPCs et politiques relatives aux terminaux ](#vpc-endpoint-policy) + [ ## Considérations ](#vpc-endpoint-considerations) + [ ## Autorisations nécessaires ](#serverless-vpc-permissions) + [ ## Création d'un point de terminaison d'interface pour OpenSearch Serverless ](#serverless-vpc-create) + [ ## Configuration d'un VPC partagé pour Amazon Serverless OpenSearch ](#shared-vpc-setup) ## Résolution DNS des points de terminaison de collecte Lorsque vous créez un point de terminaison VPC de plan de données via la console OpenSearch Serverless, le service crée une nouvelle [zone hébergée Amazon Route 53 privée](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/hosted-zones-private.html) et l'attache au VPC. Cette zone hébergée privée consiste en un enregistrement permettant de résoudre l'enregistrement DNS générique pour les collections OpenSearch sans serveur (`*.us-east-1.aoss.amazonaws.com`) aux adresses d'interface utilisées pour le point de terminaison. Vous n'avez besoin que d'un point de terminaison VPC OpenSearch sans serveur dans un VPC pour accéder à toutes les collections et à tous les tableaux de bord de chaque VPC. Région AWS Chaque VPC doté d'un point de terminaison pour OpenSearch Serverless possède sa propre zone hébergée privée attachée. Le point de terminaison de l'interface OpenSearch sans serveur crée également un enregistrement DNS générique Route 53 public pour toutes les collections de la région. Le nom DNS correspond aux adresses IP publiques OpenSearch sans serveur. Les clients VPCs qui ne disposent pas d'un point de terminaison VPC OpenSearch sans serveur ou les clients des réseaux publics peuvent utiliser le résolveur Route 53 public et accéder aux collections et aux tableaux de bord avec ces adresses IP. Le type d'adresse IP (IPv4 IPv6, ou Dualstack) du point de terminaison VPC est déterminé en fonction des sous-réseaux fournis lorsque vous [créez un](#serverless-vpc-create) point de terminaison d'interface pour Serverless. OpenSearch **Note** OpenSearch Serverless crée une zone hébergée privée Amazon Route 53 supplémentaire ``.opensearch.amazonaws.com` (`) pour la résolution OpenSearch d'un domaine de service. Vous pouvez mettre à jour votre point de terminaison IPv4 VPC existant vers Dualstack en utilisant la commande du [update-vpc-endpoint](https://docs.aws.amazon.com/cli/latest/reference/opensearchserverless/update-vpc-endpoint.html). AWS CLI L'adresse du résolveur DNS pour un VPC donné est la deuxième adresse IP du CIDR du VPC. Tout client du VPC doit utiliser ce résolveur pour obtenir l'adresse du point de terminaison du VPC pour toute collection. Le résolveur utilise une zone hébergée privée créée par OpenSearch Serverless. Il suffit d'utiliser ce résolveur pour toutes les collections, quel que soit le compte. Il est également possible d'utiliser le résolveur VPC pour certains points de terminaison de collection et le résolveur public pour d'autres, bien que cela ne soit généralement pas nécessaire. ## VPCs et politiques d'accès au réseau Pour accorder des autorisations réseau OpenSearch APIs et des tableaux de bord pour vos collections, vous pouvez utiliser des politiques d'[accès réseau OpenSearch ](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/serverless-network.html) sans serveur. Vous pouvez contrôler cet accès réseau à partir de vos points de terminaison VPC ou de l'Internet public. Étant donné que votre politique réseau ne contrôle que les autorisations de trafic, vous devez également définir une [politique d'accès aux données](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/serverless-data-access.html) qui spécifie l'autorisation d'opérer sur les données d'une collection et de ses index. Imaginez un point de terminaison VPC OpenSearch sans serveur comme un point d'accès au service, une politique d'accès réseau comme le point d'accès au niveau du réseau aux collections et aux tableaux de bord, et une politique d'accès aux données comme le point d'accès permettant un contrôle d'accès précis pour toute opération sur les données de la collection. Comme vous pouvez spécifier plusieurs points de terminaison VPC IDs dans une politique réseau, nous vous recommandons de créer un point de terminaison VPC pour chaque VPC devant accéder à une collection. Ils VPCs peuvent appartenir à des AWS comptes différents de ceux du compte propriétaire de la collection OpenSearch Serverless et de la politique réseau. Nous vous déconseillons de créer une solution de VPC-to-VPC peering ou autre solution de proxy entre deux comptes afin que le VPC d'un compte puisse utiliser le point de terminaison VPC d'un autre compte. Cela est moins sûr et moins rentable que le fait que chaque VPC possède son propre point de terminaison. Le premier VPC ne sera pas facilement visible pour l'administrateur de l'autre VPC, qui a configuré l'accès au point de terminaison de ce VPC dans la politique réseau. ## VPCs et politiques relatives aux terminaux Amazon OpenSearch Serverless prend en charge les politiques relatives aux terminaux pour VPCs. Une politique de point de terminaison est une politique basée sur les ressources IAM que vous attachez à un point de terminaison VPC pour contrôler quels AWS principaux peuvent utiliser le point de terminaison pour accéder à votre service. AWS Pour plus d'informations, consultez [Contrôler l'accès aux points de terminaison VPC à l'aide de politiques de point de terminaison](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-access.html). Pour utiliser une politique de point de terminaison, vous devez d'abord créer un point de terminaison d'interface. Vous pouvez créer un point de terminaison d'interface à l'aide de la console OpenSearch Serverless ou de l'API OpenSearch Serverless. Après avoir créé le point de terminaison de votre interface, vous devez ajouter la politique du point de terminaison au point de terminaison. Pour de plus amples informations, veuillez consulter [Création d'un point de terminaison d'interface pour OpenSearch Serverless](#serverless-vpc-create). **Note** Vous ne pouvez pas définir une politique de point de terminaison directement dans la console OpenSearch de service. Une politique de point de terminaison ne remplace ni ne remplace les autres politiques basées sur l'identité, les politiques basées sur les ressources, les politiques réseau ou les politiques d'accès aux données que vous avez éventuellement configurées. Pour plus d'informations sur la mise à jour des politiques de point de terminaison, consultez [Contrôler l'accès aux points de terminaison VPC à l'aide de politiques de point de terminaison](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-access.html). Par défaut, une politique de point de terminaison accorde un accès complet à votre point de terminaison VPC. ``` { "Statement": [ { "Effect": "Allow", "Principal": "*", "Action": "*", "Resource": "*" } ] } ``` Bien que la politique de point de terminaison VPC par défaut accorde un accès complet au point de terminaison, vous pouvez configurer une politique de point de terminaison VPC pour autoriser l'accès à des rôles et à des utilisateurs spécifiques. Pour ce faire, consultez l'exemple suivant : ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": [ "123456789012", "987654321098" ] }, "Action": "*", "Resource": "*" } ] } ``` ------ Vous pouvez spécifier une collection OpenSearch sans serveur à inclure en tant qu'élément conditionnel dans votre politique de point de terminaison VPC. Pour ce faire, consultez l'exemple suivant : ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": "*", "Action": "*", "Resource": "*", "Condition": { "StringEquals": { "aoss:collection": [ "coll-abc" ] } } } ] } ``` ------ Support pour `aoss:CollectionId` est pris en charge. ``` Condition": { "StringEquals": { "aoss:CollectionId": "collection-id" } } ``` Vous pouvez utiliser les identités SAML dans votre politique de point de terminaison VPC pour déterminer l'accès aux points de terminaison VPC. Vous devez utiliser un caractère générique `(*)` dans la section principale de votre politique de point de terminaison VPC. Pour ce faire, consultez l'exemple suivant : ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": "*", "Action": "*", "Resource": "*", "Condition": { "ForAnyValue:StringEquals": { "saml:cn": [ "saml/111122223333/idp123/group/football", "saml/111122223333/idp123/group/soccer", "saml/111122223333/idp123/group/cricket" ] } } } ] } ``` ------ En outre, vous pouvez configurer votre politique de point de terminaison pour inclure une politique principale SAML spécifique. Pour ce faire, consultez les informations suivantes : ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": "*", "Action": "*", "Resource": "*", "Condition": { "StringEquals": { "aws:PrincipalTag/Department": [ "Engineering"] } } } ] } ``` ------ Pour plus d'informations sur l'utilisation de l'authentification SAML avec Amazon OpenSearch Serverless, consultez Authentification [SAML pour Amazon](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/serverless-saml.html) Serverless. OpenSearch Vous pouvez également inclure les utilisateurs IAM et SAML dans la même politique de point de terminaison VPC. Pour ce faire, consultez l'exemple suivant : ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": "*", "Action": "*", "Resource": "*", "Condition": { "ForAnyValue:StringEquals": { "saml:cn": [ "saml/111122223333/idp123/group/football", "saml/111122223333/idp123/group/soccer", "saml/111122223333/idp123/group/cricket" ] } } }, { "Effect": "Allow", "Principal": { "AWS": [ "111122223333" ] }, "Action": "*", "Resource": "*" } ] } ``` ------ Vous pouvez également accéder à une collection Amazon OpenSearch Serverless depuis Amazon EC2 via des points de terminaison VPC d'interface. Pour plus d'informations, consultez [Accéder à une collection OpenSearch sans serveur depuis Amazon EC2 (via des points de terminaison VPC d'interface)](https://aws.amazon.com/blogs/big-data/network-connectivity-patterns-for-amazon-opensearch-serverless/). ## Considérations Avant de configurer un point de terminaison d'interface pour OpenSearch Serverless, tenez compte des points suivants : + OpenSearch Serverless permet d'appeler toutes les opérations d'[OpenSearch API prises en charge (et non les opérations](serverless-genref.md#serverless-operations) d'API de configuration) via le point de terminaison de l'interface. + Après avoir créé un point de terminaison d'interface pour OpenSearch Serverless, vous devez toujours l'inclure dans [les politiques d'accès au réseau](serverless-network.md) afin qu'il puisse accéder aux collections sans serveur. + Par défaut, l'accès complet à OpenSearch Serverless est autorisé via le point de terminaison de l'interface. Vous pouvez associer un groupe de sécurité aux interfaces réseau du point de terminaison pour contrôler le trafic vers OpenSearch Serverless via le point de terminaison de l'interface. + Un seul Compte AWS peut avoir un maximum de 50 points de terminaison VPC OpenSearch sans serveur. + Si vous activez l'accès Internet public à l'API ou aux tableaux de bord de votre collection dans le cadre d'une politique réseau, votre collection est accessible par n'importe quel VPC et par Internet public. + Si vous êtes sur site et en dehors du VPC, vous ne pouvez pas utiliser directement un résolveur DNS pour la résolution des points de terminaison du VPC OpenSearch sans serveur. Si vous avez besoin d'un accès VPN, le VPC a besoin d'un résolveur de proxy DNS que les clients externes peuvent utiliser. Route 53 fournit une option de point de terminaison entrant que vous pouvez utiliser pour résoudre les requêtes DNS adressées à votre VPC à partir de votre réseau local ou d'un autre VPC. + La zone hébergée privée que OpenSearch Serverless crée et attache au VPC est gérée par le service, mais elle apparaît dans Amazon Route 53 vos ressources et est facturée à votre compte. + Pour d'autres considérations, veuillez consulter les [Considérations](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#considerations-interface-endpoints) dans le *Guide AWS PrivateLink *. ## Autorisations nécessaires L'accès VPC pour OpenSearch Serverless utilise les autorisations Gestion des identités et des accès AWS (IAM) suivantes. Vous pouvez spécifier des conditions IAM pour restreindre les utilisateurs à des collections spécifiques. + `aoss:CreateVpcEndpoint` : créer un point de terminaison d'un VPC. + `aoss:ListVpcEndpoints` : répertorier tous les points de terminaison d'un VPC. + `aoss:BatchGetVpcEndpoint` : consulter les détails d'un sous-ensemble de points de terminaison d'un VPC. + `aoss:UpdateVpcEndpoint` : modifier un point de terminaison d'un VPC. + `aoss:DeleteVpcEndpoint` : supprimer un point de terminaison d'un VPC. En outre, vous devez disposer des autorisations Amazon EC2 et Route 53 suivantes pour créer un point de terminaison d'un VPC. + `ec2:CreateTags` + `ec2:CreateVpcEndpoint` + `ec2:DeleteVpcEndPoints` + `ec2:DescribeSecurityGroups` + `ec2:DescribeSubnets` + `ec2:DescribeVpcEndpoints` + `ec2:DescribeVpcs` + `ec2:ModifyVpcEndPoint` + `route53:AssociateVPCWithHostedZone` + `route53:ChangeResourceRecordSets` + `route53:CreateHostedZone` + `route53:DeleteHostedZone` + `route53:GetChange` + `route53:GetHostedZone` + `route53:ListHostedZonesByName` + `route53:ListHostedZonesByVPC` + `route53:ListResourceRecordSets` ## Création d'un point de terminaison d'interface pour OpenSearch Serverless Création d’un point de terminaison d’interface Vous pouvez créer un point de terminaison d'interface pour OpenSearch Serverless à l'aide de la console ou de l'API OpenSearch Serverless. **Pour créer un point de terminaison d'interface pour une OpenSearch collection 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 panneau de navigation de gauche, développez **Serverless** (Sans serveur) et choisissez **VPC endpoints** (Points de terminaison d'un VPC). 1. Choisissez **Create VPC endpoint** (Créer un point de terminaison d'un VPC). 1. Saisissez un nom pour le point de terminaison. 1. Pour le **VPC**, sélectionnez le VPC à partir duquel vous allez accéder sans serveur. OpenSearch 1. Pour les **sous-réseaux**, sélectionnez un sous-réseau à partir duquel vous accéderez OpenSearch sans serveur. + L'adresse IP et le type DNS du point de terminaison sont basés sur le type de sous-réseau + Dualstack : si tous les sous-réseaux ont à la fois IPv4 des plages d'adresses IPv6 + IPv6: si tous les sous-réseaux IPv6 ne sont que des sous-réseaux + IPv4: si tous les sous-réseaux ont des plages d' IPv4 adresses 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 critique qui vous permet de limiter les ports, les protocoles et les sources de trafic entrant que vous autorisez sur votre terminal. Assurez-vous que les règles du groupe de sécurité autorisent les ressources qui utiliseront le point de terminaison VPC pour communiquer avec OpenSearch Serverless à communiquer avec l'interface réseau du point de terminaison. 1. Choisissez **Créer un point de terminaison**. Pour créer un point de terminaison VPC à l'aide de l'API OpenSearch Serverless, utilisez la commande. `CreateVpcEndpoint` **Note** Après avoir créé un point de terminaison, prenez note de son ID (par exemple, `vpce-abc123def4EXAMPLE`). Afin de fournir au point de terminaison un accès à vos collections, vous devez inclure cet ID dans une ou plusieurs stratégies d'accès réseau. Après avoir créé un point de terminaison d'interface, vous devez lui donner accès aux collections par le biais de stratégies d'accès réseau. Pour de plus amples informations, veuillez consulter [Accès au réseau pour Amazon OpenSearch Serverless](serverless-network.md). ## Configuration d'un VPC partagé pour Amazon Serverless OpenSearch Vous pouvez utiliser Amazon Virtual Private Cloud (VPC) pour partager des sous-réseaux VPC avec d'autres Comptes AWS membres de votre organisation, ainsi que pour partager une infrastructure réseau telle qu'un VPN entre plusieurs ressources. Comptes AWS Actuellement, Amazon OpenSearch Serverless ne prend pas en charge la création d'une AWS PrivateLink connexion à un VPC partagé, sauf si vous êtes propriétaire de ce VPC. AWS PrivateLink ne prend pas non plus en charge le partage de connexions entre Comptes AWS. Cependant, sur la base de l'architecture flexible et modulaire de OpenSearch Serverless, vous pouvez toujours configurer un VPC partagé. Cela est dû au fait que l'infrastructure réseau OpenSearch sans serveur est distincte de celle de l'infrastructure de collecte individuelle (OpenSearch service). Vous pouvez donc créer un AWS PrivateLink VPCe point de terminaison pour un compte sur lequel se trouve un VPC, puis utiliser un VPCe ID dans la politique réseau des autres comptes afin de limiter le trafic provenant uniquement de ce VPC partagé. Les procédures suivantes font référence à un *compte propriétaire* et à un *compte client*. Un compte propriétaire agit comme un compte réseau commun dans lequel vous configurez un VPC et le partagez avec d'autres comptes. Les comptes clients sont les comptes qui créent et gèrent leurs collections OpenSearch sans serveur dans le VPC partagé avec eux par le compte propriétaire. **Conditions préalables** Assurez-vous que les conditions suivantes sont remplies avant de configurer le VPC partagé : + Le compte du propriétaire prévu doit déjà avoir configuré un VPC, des sous-réseaux, une table de routage et les autres ressources requises dans Amazon Virtual Private Cloud. Pour de plus amples informations, consultez le *[Guide de l’utilisateur Amazon VPC](https://docs.aws.amazon.com/vpc/latest/userguide/)*. + Le compte du propriétaire prévu et les comptes du consommateur doivent appartenir à la même organisation dans AWS Organizations. Pour plus d’informations, consultez le *Guide de l’utilisateur [AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/)*. **Pour configurer un VPC partagé dans un compte account/common réseau propriétaire.** 1. Connectez-vous à la console Amazon OpenSearch Service à la [https://console.aws.amazon.com/aos/maison](https://console.aws.amazon.com/aos/home). 1. Suivez les étapes de [Création d'un point de terminaison d'interface pour OpenSearch Serverless](#serverless-vpc-create). Au fur et à mesure, effectuez les sélections suivantes : + Sélectionnez un VPC et des sous-réseaux partagés avec les comptes clients de votre organisation. 1. Après avoir créé le point de terminaison, notez l' VPCe identifiant généré et fournissez-le aux administrateurs chargés d'effectuer la tâche de configuration dans les comptes clients. VPCe IDs sont au format`vpce-abc123def4EXAMPLE`. **Pour configurer un VPC partagé dans un compte client** 1. Connectez-vous à la console Amazon OpenSearch Service à la [https://console.aws.amazon.com/aos/maison](https://console.aws.amazon.com/aos/home). 1. Utilisez les informations [Gestion des collections Amazon OpenSearch Serverless](serverless-manage.md) pour créer une collection, si vous n'en avez pas déjà une. 1. Utilisez les informations contenues [Créer des stratégies réseau (console)](serverless-network.md#serverless-network-console) pour créer une politique réseau. Au fur et à mesure, effectuez les sélections suivantes. **Note** Vous pouvez également mettre à jour une politique réseau existante à cette fin. 1. Pour le **type d'accès**, sélectionnez **VPC (recommandé)**. 1. Pour les **points de terminaison VPC auxquels vous pouvez accéder**, choisissez l' VPCe ID qui vous a été fourni par le compte propriétaire, au format. `vpce-abc123def4EXAMPLE` 1. Dans la zone **Type de ressource**, procédez comme suit : + Cochez la case **Activer l'accès au OpenSearch point de terminaison**, puis sélectionnez le nom ou le modèle de collection à utiliser pour activer l'accès depuis ce VPC partagé. + Sélectionnez la case **Activer l'accès au OpenSearch tableau de bord**, puis sélectionnez le nom ou le modèle de collection à utiliser pour autoriser l'accès depuis ce VPC partagé. 1. Pour une nouvelle politique, choisissez **Create**. Pour une politique existante, choisissez **Mettre à jour**. # Accès au plan de contrôle via AWS PrivateLink Point de terminaison VPC du plan de contrôle Amazon OpenSearch Serverless prend en charge deux types de AWS PrivateLink connexions pour les opérations du plan de contrôle et du plan de données. Les opérations du plan de contrôle incluent la création et la suppression de collections ainsi que la gestion des politiques d'accès. Les opérations du plan de données servent à indexer et à interroger des données au sein d'une collection. Cette page couvre le point de AWS PrivateLink terminaison du plan de contrôle. Pour plus d'informations sur les points de terminaison VPC du plan de données, consultez. [Accès au plan de données via AWS PrivateLink](serverless-vpc.md) ## Création d'un point de AWS PrivateLink terminaison du plan de contrôle Vous pouvez améliorer le niveau de sécurité de votre VPC en configurant OpenSearch Serverless pour utiliser un point de terminaison VPC d'interface. Les points de terminaison de l'interface sont alimentés par AWS PrivateLink. Cette technologie vous permet d'accéder en privé OpenSearch sans serveur APIs sans passerelle Internet, appareil NAT, connexion VPN ou connexion AWS Direct Connect. Pour plus d'informations sur AWS PrivateLink les points de terminaison VPC, consultez la section Points de terminaison [VPC dans le guide de l'utilisateur](https://docs.aws.amazon.com/vpc/latest/privatelink/concepts.html#concepts-vpc-endpoints) Amazon VPC. ### Considérations + Les points de terminaison VPC ne sont pris en charge que dans la même région. + Les points de terminaison d'un VPC prennent uniquement en charge le DNS fourni par Amazon via Amazon Route 53. + Les points de terminaison VPC prennent en charge les politiques des points de terminaison pour contrôler l'accès aux collections OpenSearch sans serveur, aux politiques et. VpcEndpoints + OpenSearch Serverless ne prend en charge que les points de terminaison d'interface. Les points de terminaison de passerelle ne sont pas pris en charge. ### Création du point de terminaison VPC *Pour créer le point de terminaison VPC du plan de contrôle pour Amazon OpenSearch Serverless, utilisez la [procédure Access an AWS service using an interface VPC endpoint du manuel Amazon VPC Developer](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#create-interface-endpoint) Guide.* Créez le point de terminaison suivant : + `com.amazonaws.region.aoss` **Pour créer un point de terminaison VPC du plan de contrôle à l'aide de la console** 1. Ouvrez la console Amazon VPC à l’adresse [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/). 1. Dans le panneau de navigation, choisissez **Points de terminaison**. 1. Choisissez **Create Endpoint** (Créer un point de terminaison). 1. Pour **Service category** (Catégorie de service), choisissez **Services AWS**. 1. Pour **Services**, choisissez`com.amazonaws.region.aoss`. Par exemple, `com.amazonaws.us-east-1.aoss`. 1. Pour **VPC**, choisissez le VPC dans lequel créer le point de terminaison. 1. Pour **Sous-réseaux**, choisissez les sous-réseaux (zones de disponibilité) dans lesquels créer les interfaces réseau du point de terminaison. 1. Pour les **groupes de sécurité**, choisissez les groupes de sécurité à associer aux interfaces réseau des terminaux. Assurez-vous que le protocole HTTPS (port 443) est autorisé. 1. Pour **la stratégie**, choisissez **Accès complet** pour autoriser toutes les opérations, ou choisissez **Personnalisé** pour joindre une politique personnalisée. 1. Choisissez **Créer un point de terminaison**. ### Création d'une politique de point de terminaison Vous pouvez associer une politique de point de terminaison à votre point de terminaison VPC qui contrôle l'accès à Amazon OpenSearch Serverless. La politique spécifie les informations suivantes : + Le principal qui peut exécuter des actions. + Les actions qui peuvent être effectuées. + Les ressources sur lesquelles les actions peuvent être exécutées. Pour plus d’informations, consultez [Contrôle de l’accès aux services avec points de terminaison d’un VPC](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-access.html) dans le *Guide de l’utilisateur Amazon VPC*. **Example Politique de point de terminaison VPC pour Serverless OpenSearch** ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": "*", "Action": [ "aoss:ListCollections", "aoss:BatchGetCollection" ], "Resource": "*" } ] } ``` **Example Politique restrictive autorisant uniquement les opérations de liste** ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": "*", "Action": "aoss:ListCollections", "Resource": "*" } ] } ``` # Authentification SAML pour Amazon Serverless OpenSearch Authentification SAML Avec l'authentification SAML pour Amazon OpenSearch Serverless, vous pouvez utiliser votre fournisseur d'identité existant pour proposer l'authentification unique (SSO) pour les points de terminaison des OpenSearch tableaux de bord des collections sans serveur. L'authentification SAML vous permet d'utiliser des fournisseurs d'identité tiers pour vous connecter aux OpenSearch tableaux de bord afin d'indexer et de rechercher des données. OpenSearch Serverless prend en charge les fournisseurs qui utilisent la norme SAML 2.0, tels que IAM Identity Center, Okta, Keycloak, Active Directory Federation Services (AD FS) et Auth0. Vous pouvez configurer IAM Identity Center pour synchroniser les utilisateurs et les groupes provenant d'autres sources d'identité telles qu'Okta et Microsoft Entra ID. OneLogin Pour obtenir la liste des sources d'identité prises en charge par IAM Identity Center et les étapes à suivre pour les configurer, consultez les [didacticiels de mise en route](https://docs.aws.amazon.com/singlesignon/latest/userguide/tutorials.html) du guide de l'*utilisateur d'IAM Identity Center*. **Note** L'authentification SAML permet uniquement d'accéder aux OpenSearch tableaux de bord via un navigateur Web. Les utilisateurs authentifiés peuvent uniquement envoyer des demandes aux opérations de l' OpenSearch API via les **outils de développement dans les** OpenSearch tableaux de bord. Vos informations d'identification SAML ne vous permettent *pas* d'envoyer des requêtes HTTP directes aux opérations de l' OpenSearch API. Pour configurer l'authentification SAML, vous devez d'abord configurer un fournisseur d'identité (IdP) SAML. Vous incluez ensuite un ou plusieurs utilisateurs de cet IdP dans une [stratégie d'accès aux données](serverless-data-access.md). Cette politique lui accorde certaines autorisations sur les and/or index de collections. Un utilisateur peut ensuite se connecter aux OpenSearch tableaux de bord et effectuer les actions autorisées dans la politique d'accès aux données. ![\[SAML authentication flow with data access policy, OpenSearch interface, and JSON configuration.\]](http://docs.aws.amazon.com/fr_fr/opensearch-service/latest/developerguide/images/serverless-saml-flow.png) **Topics** + [ ## Considérations ](#serverless-saml-considerations) + [ ## Autorisations nécessaires ](#serverless-saml-permissions) + [ ## Créer des fournisseurs SAML (console) ](#serverless-saml-creating) + [ ## Accès aux OpenSearch tableaux de bord ](#serverless-saml-dashboards) + [ ## Octroyer aux identités SAML l'accès aux données de collection ](#serverless-saml-policies) + [ ## Créer des fournisseurs SAML (AWS CLI) ](#serverless-saml-creating-api) + [ ## Consulter des fournisseurs SAML ](#serverless-saml-viewing) + [ ## Mettre à jour des fournisseurs SAML ](#serverless-saml-updating) + [ ## Supprimer des fournisseurs SAML ](#serverless-saml-deleting) ## Considérations Tenez compte des éléments suivants lors de la configuration de l'authentification SAML : + Les requêtes signées et chiffrées ne sont pas prises en charge. + Les assertions chiffrées ne sont pas prises en charge. + L'authentification et la déconnexion initiées par l'IdP ne sont pas prises en charge. + 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 ## Autorisations nécessaires L'authentification SAML pour OpenSearch Serverless utilise les autorisations Gestion des identités et des accès AWS (IAM) suivantes : + `aoss:CreateSecurityConfig` : créer un fournisseur SAML. + `aoss:ListSecurityConfig` : répertorier tous les fournisseurs SAML du compte actuel. + `aoss:GetSecurityConfig` : afficher les informations du fournisseur SAML. + `aoss:UpdateSecurityConfig` : modifier la configuration d'un fournisseur SAML donné, y compris les métadonnées XML. + `aoss:DeleteSecurityConfig` : supprimer un fournisseur SAML. La stratégie d'accès basée sur l'identité suivante permet à un utilisateur de gérer toutes les configurations IdP : ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Action": [ "aoss:CreateSecurityConfig", "aoss:DeleteSecurityConfig", "aoss:GetSecurityConfig", "aoss:UpdateSecurityConfig", "aoss:ListSecurityConfigs" ], "Effect": "Allow", "Resource": "*" } ] } ``` ------ Veuillez noter que l'élément `Resource` doit être un caractère générique. ## Créer des fournisseurs SAML (console) Ces étapes expliquent comment créer des fournisseurs SAML. Cela permet l'authentification SAML avec l'authentification initiée par le fournisseur de services (SP) pour les OpenSearch tableaux de bord. L'authentification initiée par l'IdP n'est pas prise en charge. **Pour activer l'authentification SAML pour les tableaux de bord OpenSearch** 1. Connectez-vous à la console Amazon OpenSearch Service à la [https://console.aws.amazon.com/aos/maison](https://console.aws.amazon.com/aos/home ). 1. Dans le panneau de navigation de gauche, développez **Serverless** (Sans serveur) et sélectionnez **SAML authentication** (Authentification SAML). 1. Choisissez **Add SAML provider** (Ajouter un fournisseur SAML). 1. Saisissez un nom et une description pour le fournisseur. **Note** Le nom que vous spécifiez est accessible au public et apparaît dans un menu déroulant lorsque les utilisateurs se connectent à OpenSearch Dashboards. Assurez-vous que le nom est facilement reconnaissable et qu'il ne révèle pas d'informations sensibles sur votre fournisseur d'identité. 1. Sous **Configure your IdP** (Configurer votre IdP), copiez l'URL Assertion Consumer Service (ACS). 1. Utilisez l'URL ACS que vous venez de copier pour configurer votre fournisseur d'identité. La terminologie et les étapes varient selon le fournisseur. Consultez la documentation de votre fournisseur. Dans Okta, par exemple, vous créez une « application web SAML 2.0 » et vous spécifiez l'URL ACS comme **URL d'authentification unique**, **URL du destinataire** et **URL de destination**. Pour Auth0, vous le spécifiez dans **Allowed URLs Callback**. 1. Indiquez la restriction d'audience si votre IdP dispose d'un champ à cet effet. La restriction d'audience est une valeur de l'assertion SAML qui indique à qui l'assertion est destinée. Avec OpenSearch Serverless, vous pouvez effectuer les opérations suivantes. Assurez-vous de remplacer le code indiqué *content* dans l'exemple de code suivant par votre propre Compte AWS identifiant : 1. Utilisez la restriction d'audience par défaut`:opensearch:111122223333`. 1. (Facultatif) configurez une restriction d'audience personnalisée à l'aide du AWS CLI. Pour de plus amples informations, veuillez consulter [Créer des fournisseurs SAML (AWS CLI)](#serverless-saml-creating-api). Le nom du champ de restriction d'audience varie selon le fournisseur. Pour Okta, il s'agit d'**URI d'audience (ID d'entité du fournisseur de services)**. Pour IAM Identity Center, il s'agit de **l'audience SAML des applications**. 1. Si vous utilisez IAM Identity Center, vous devez également spécifier le [mappage d'attributs](https://docs.aws.amazon.com/singlesignon/latest/userguide/attributemappingsconcept.html) suivant : `Subject=${user:name}`, au format `unspecified`. 1. 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 texte dans le fichier de métadonnées IdP et collez-le sous le champ **Provide metadata from your IdP** (Fournir les métadonnées de votre IdP). 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 s urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress ``` 1. Laissez le champ d'**attribut Custom user ID** vide pour utiliser l'`NameID`élément de l'assertion SAML comme 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. Les attributs sont sensibles à la casse. Seul un attribut d'utilisateur unique est pris en charge. L'exemple suivant montre un attribut de remplacement pour `NameID` dans l'assertion SAML : ``` annie ``` 1. (Facultatif) Spécifiez un attribut personnalisé dans le champ **Group attribute** (Attribut de groupe), tel que `role` ou `group`. Seul un attribut de groupe unique est pris en charge. Il n'existe aucun attribut de groupe par défaut. Si vous n'en spécifiez pas, vos stratégies d'accès aux données ne peuvent contenir que des principaux d'utilisateur. L'exemple suivant montre un attribut de groupe dans l'assertion SAML : ``` finance ``` 1. Par défaut, OpenSearch Dashboards déconnecte les utilisateurs au bout de 24 heures. Vous pouvez configurer cette valeur sur un nombre compris entre 1 et 12 heures (15 et 720 minutes) en spécifiant le **délai d'expiration OpenSearch des tableaux** de bord. Si vous essayez de régler le délai d'attente égal ou inférieur à 15 minutes, votre session sera réinitialisée à une heure. 1. Choisissez **Create SAML provider** (Créer un fournisseur SAML). ## Accès aux OpenSearch tableaux de bord Après avoir configuré un fournisseur SAML, tous les utilisateurs et groupes associés à ce fournisseur peuvent accéder au point de terminaison OpenSearch Dashboards. Le format de l'URL des tableaux de bord correspond à celui `collection-endpoint/_dashboards/` *de toutes les collections*. Si le protocole SAML est activé, vous êtes AWS Management Console redirigé vers la page de sélection de l'IdP, où vous pouvez vous connecter à l'aide de vos informations d'identification SAML. Tout d'abord, utilisez la liste déroulante pour sélectionner un fournisseur d'identité : ![\[OpenSearch login page with dropdown menu for selecting SAML Identity Provider options.\]](http://docs.aws.amazon.com/fr_fr/opensearch-service/latest/developerguide/images/idpList.png) Connectez-vous ensuite à l'aide de vos informations d'identification d'IdP. Si le protocole SAML n'est pas activé, vous pouvez cliquer sur le lien dans le pour AWS Management Console vous connecter en tant qu'utilisateur ou en tant que rôle IAM, sans aucune option pour le protocole SAML. ## Octroyer aux identités SAML l'accès aux données de collection Après avoir créé un fournisseur SAML, vous devez toujours octroyer aux utilisateurs et aux groupes sous-jacents l'accès aux données de vos collections. Vous octroyez l'accès par le biais de [stratégies d'accès aux données](serverless-data-access.md). Tant que vous n'aurez pas octroyé l'accès aux utilisateurs, ils ne pourront pas lire, écrire ou supprimer les données de vos collections. Pour accorder l'accès, créez une politique d'accès aux données et spécifiez votre and/or groupe d'utilisateurs SAML IDs dans la `Principal` déclaration suivante : ``` [ { "Rules":[ ... ], "Principal":[ "saml/987654321098/myprovider/user/Shaheen", "saml/987654321098/myprovider/group/finance" ] } ] ``` Vous pouvez octroyer l'accès aux collections, aux index ou aux deux. Si vous souhaitez que différents utilisateurs aient des autorisations différentes, créez plusieurs règles. Pour obtenir la liste des autorisations disponibles, veuillez consulter la rubrique [Autorisations de stratégie prises en charge](serverless-data-access.md#serverless-data-supported-permissions). Pour plus d'informations sur le formatage d'une stratégie d'accès, veuillez consulter la rubrique [Policy syntax](serverless-data-access.md) (Syntaxe de stratégie). ## Créer des fournisseurs SAML (AWS CLI) Pour créer un fournisseur SAML à l'aide de l'API OpenSearch Serverless, envoyez une [CreateSecurityConfig](https://docs.aws.amazon.com/opensearch-service/latest/ServerlessAPIReference/API_CreateSecurityConfig.html)demande : ``` aws opensearchserverless create-security-config \ --name myprovider \ --type saml \ --saml-options file://saml-auth0.json ``` Spécifiez `saml-options`, y compris le fichier XML des métadonnées, sous la forme d'un mappage clé-valeur dans un fichier .json. Le fichier XML des métadonnées doit être codé sous la forme d'une [chaîne d'échappement JSON](https://www.freeformatter.com/json-escape.html). ``` { "sessionTimeout": 70, "groupAttribute": "department", "userAttribute": "userid", "openSearchServerlessEntityId": "aws:opensearch:111122223333:app1", "metadata": "EntityDescriptor xmlns=\"urn:oasis:names:tc:SAML:2.0:metadata\" ... ... ... IDPSSODescriptor\r\n\/EntityDescriptor" } ``` **Note** (Facultatif) configurez une restriction d'audience personnalisée à l'aide du AWS CLI. Pour de plus amples informations, veuillez consulter [Créer des fournisseurs SAML (AWS CLI)](#serverless-saml-creating-api). ## Consulter des fournisseurs SAML La [ListSecurityConfigs](https://docs.aws.amazon.com/opensearch-service/latest/ServerlessAPIReference/API_ListSecurityConfigs.html)demande suivante répertorie tous les fournisseurs SAML de votre compte : ``` aws opensearchserverless list-security-configs --type saml ``` La requête renvoie des informations sur tous les fournisseurs SAML existants, y compris les métadonnées IdP complètes générées par votre fournisseur d'identité : ``` { "securityConfigDetails": [ { "configVersion": "MTY2NDA1MjY4NDQ5M18x", "createdDate": 1664054180858, "description": "Example SAML provider", "id": "saml/111122223333/myprovider", "lastModifiedDate": 1664054180858, "samlOptions": { "groupAttribute": "department", "metadata": "EntityDescriptorxmlns=\"urn:oasis:names:tc:SAML:2.0:metadata\" ...... ...IDPSSODescriptor\r\n/EntityDescriptor", "sessionTimeout": 120, "openSearchServerlessEntityId": "aws:opensearch:111122223333:app1", "userAttribute": "userid" } } ] } ``` Pour consulter les détails d'un fournisseur spécifique, y compris la `configVersion` des mises à jour futures, envoyez une requête `GetSecurityConfig`. ## Mettre à jour des fournisseurs SAML **Pour mettre à jour un fournisseur SAML à l'aide de la console OpenSearch Serverless, choisissez **l'authentification SAML**, sélectionnez votre fournisseur d'identité, puis choisissez Modifier.** Vous pouvez modifier tous les champs, y compris les métadonnées et les attributs personnalisés. Pour mettre à jour un fournisseur via l'API OpenSearch Serverless, envoyez une [UpdateSecurityConfig](https://docs.aws.amazon.com/opensearch-service/latest/ServerlessAPIReference/API_UpdateSecurityConfig.html)demande et incluez l'identifiant de la politique à mettre à jour. Vous devez également inclure une version de configuration, que vous pouvez récupérer à l'aide des commandes `ListSecurityConfigs` ou `GetSecurityConfig`. En incluant la version la plus récente, vous vous assurez de ne pas annuler par inadvertance une modification apportée par quelqu'un d'autre. La requête suivante met à jour les options SAML d'un fournisseur : ``` aws opensearchserverless update-security-config \ --id saml/123456789012/myprovider \ --type saml \ --saml-options file://saml-auth0.json \ --config-version MTY2NDA1MjY4NDQ5M18x ``` Spécifiez vos options de configuration SAML sous la forme d'un mappage clé-valeur dans un fichier .json. **Important** Les **mises à jour des options SAML ne sont *pas* progressives**. Si vous ne spécifiez aucune valeur pour un paramètre de l'objet `SAMLOptions` lorsque vous effectuez une mise à jour, les valeurs existantes seront remplacées par des valeurs vides. Par exemple, si la configuration actuelle contient une valeur pour `userAttribute`, puis que vous effectuez une mise à jour sans inclure cette valeur, la valeur est supprimée de la configuration. Assurez-vous de connaître les valeurs existantes avant de procéder à une mise à jour en appelant l'opération `GetSecurityConfig`. ## Supprimer des fournisseurs SAML Lorsque vous supprimez un fournisseur SAML, les références aux utilisateurs et aux groupes associés dans vos stratégies d'accès aux données ne sont plus fonctionnelles. Pour éviter toute confusion, nous vous suggérons de supprimer toutes les références au point de terminaison dans vos stratégies d'accès avant de supprimer le point de terminaison. **Pour supprimer un fournisseur SAML à l'aide de la console OpenSearch Serverless, choisissez **Authentification**, sélectionnez le fournisseur, puis choisissez Supprimer.** Pour supprimer un fournisseur via l'API OpenSearch Serverless, envoyez une [DeleteSecurityConfig](https://docs.aws.amazon.com/opensearch-service/latest/ServerlessAPIReference/API_DeleteSecurityConfig.html)demande : ``` aws opensearchserverless delete-security-config --id saml/123456789012/myprovider ``` # Validation de conformité pour Amazon OpenSearch Serverless Validation de conformité Des auditeurs tiers évaluent la sécurité et la conformité d'Amazon OpenSearch Serverless dans le cadre de plusieurs programmes de AWS conformité. Il s'agit notamment des programmes SOC, PCI et HIPAA. 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/).