Contrôle d'accès précis dans Amazon Service OpenSearch

Le contrôle d'accès précis offre des moyens supplémentaires de contrôler l'accès à vos données sur Amazon OpenSearch Service. Par exemple, selon l'auteur de la demande, vous pouvez souhaiter qu'une recherche renvoie les résultats d'un seul index. Vous pouvez masquer certains champs dans vos documents ou exclure certains documents.

Le contrôle précis des accès offre les avantages suivants :

• Contrôle d'accès basé sur les rôles

• Sécurité au niveau de l'index, du document et du champ

• OpenSearch Tableaux de bord mutualisés

• Authentification de base HTTP pour OpenSearch les OpenSearch tableaux de bord

Rubriques

• Vue d'ensemble : contrôle d'accès précis et OpenSearch sécurité des services
• Concepts clés
• À propos de l'utilisateur principal
• Activation du contrôle précis des accès
• Accès aux OpenSearch tableaux de bord en tant qu'utilisateur principal
• Gestion des autorisations
• Configurations recommandées
• Limites
• Modification de l'utilisateur maître
• Utilisateurs principaux supplémentaires
• Instantanés manuels
• Intégrations
• Différences d'API REST
• Didacticiel : configurer un domaine avec un utilisateur principal IAM et l'authentification Amazon Cognito
• Didacticiel : configurer un domaine avec la base de données utilisateur interne et l'authentification de base HTTP

Vue d'ensemble : contrôle d'accès précis et OpenSearch sécurité des services

La sécurité d'Amazon OpenSearch Service comporte trois niveaux principaux :

Réseau

La première couche de sécurité est le réseau, qui détermine si les demandes atteignent un domaine OpenSearch de service. Si vous choisissez Public access (Accès public) lorsque vous créez un domaine, les demandes de tout client connecté à Internet peuvent atteindre le point de terminaison du domaine. Si vous choisissez VPC Access (Accès VPC), les clients doivent se connecter au VPC (et les groupes de sécurité associés doivent l'autoriser) pour qu'une demande atteigne le point de terminaison. Pour plus d'informations, consultez Lancement de vos domaines Amazon OpenSearch Service au sein d'un VPC.

Stratégie d'accès au domaine

La deuxième couche de sécurité est la stratégie d'accès au domaine. Une fois qu'une requête atteint un point de terminaison de domaine, la stratégie d'accès basée sur les ressources autorise ou refuse l'accès de la demande à un URI donné. La stratégie d'accès accepte ou rejette les demandes au « bord » du domaine, avant qu'elles n'atteignent OpenSearch.

Contrôle précis des accès

La troisième et dernière couche de sécurité est un contrôle précis des accès. Après qu'une stratégie d'accès basée sur les ressources autorise une demande à atteindre un point de terminaison de domaine, un contrôle précis des accès évalue les informations d'identification de l'utilisateur et authentifie l'utilisateur ou refuse la demande. Si le contrôle précis des accès authentifie l'utilisateur, il extrait tous les rôles mappés à cet utilisateur et utilise l'ensemble complet des autorisations pour déterminer comment traiter la demande.

Note

Si une politique d'accès basée sur les ressources contient des rôles ou des utilisateurs IAM, les clients doivent envoyer des demandes signées à l'aide de AWS Signature Version 4. Ainsi, les stratégies d'accès peuvent entrer en conflit avec le contrôle précis des accès, plus particulièrement si vous utilisez la base de données utilisateur interne et l'authentification de base HTTP. Vous ne pouvez pas signer une demande avec un nom d'utilisateur, un mot de passe et des informations d'identification IAM. En général, si vous activez le contrôle d'accès affiné, nous vous recommandons d'utiliser une stratégie d'accès au domaine qui ne nécessite pas de demandes signées.

Le diagramme suivant illustre une configuration courante : un domaine d'accès VPC avec contrôle précis des accès activé, une stratégie d'accès basée sur IAM et un utilisateur principal IAM.

Le diagramme suivant illustre une autre configuration courante : un domaine d'accès public avec contrôle précis des accès activé, une stratégie d'accès qui n'utilise pas d'entités IAM et un utilisateur principal dans la base de données utilisateur interne.

Exemple

Considérez une demande GET adressée à movies/_search?q=thor. L'utilisateur dispose-t-il des autorisations pour effectuer une recherche dans l'index movies ? Si oui, l'utilisateur dispose-t-il des autorisations pour voir tous les documents qu'il contient ? La réponse devrait-elle omettre ou anonymiser des champs ? Pour l'utilisateur maître, la réponse peut se présenter comme suit :

{
  "hits": {
    "total": 7,
    "max_score": 8.772789,
    "hits": [{
        "_index": "movies",
        "_type": "_doc",
        "_id": "tt0800369",
        "_score": 8.772789,
        "_source": {
          "directors": [
            "Kenneth Branagh",
            "Joss Whedon"
          ],
          "release_date": "2011-04-21T00:00:00Z",
          "genres": [
            "Action",
            "Adventure",
            "Fantasy"
          ],
          "plot": "The powerful but arrogant god Thor is cast out of Asgard to live amongst humans in Midgard (Earth), where he soon becomes one of their finest defenders.",
          "title": "Thor",
          "actors": [
            "Chris Hemsworth",
            "Anthony Hopkins",
            "Natalie Portman"
          ],
          "year": 2011
        }
      },
      ...
    ]
  }
}

Si un utilisateur disposant d'autorisations plus limitées émet exactement la même demande, la réponse peut ressembler à ceci :

{
  "hits": {
    "total": 2,
    "max_score": 8.772789,
    "hits": [{
        "_index": "movies",
        "_type": "_doc",
        "_id": "tt0800369",
        "_score": 8.772789,
        "_source": {
          "year": 2011,
          "release_date": "3812a72c6dd23eef3c750c2d99e205cbd260389461e19d610406847397ecb357",
          "plot": "The powerful but arrogant god Thor is cast out of Asgard to live amongst humans in Midgard (Earth), where he soon becomes one of their finest defenders.",
          "title": "Thor"
        }
      },
      ...
    ]
  }
}

La réponse a moins d'accès et moins de champs pour chaque accès. En outre, le champ release_date est anonymisé. Si un utilisateur sans autorisation effectue la même demande, le cluster renvoie une erreur :

{
  "error": {
    "root_cause": [{
      "type": "security_exception",
      "reason": "no permissions for [indices:data/read/search] and User [name=limited-user, roles=[], requestedTenant=null]"
    }],
    "type": "security_exception",
    "reason": "no permissions for [indices:data/read/search] and User [name=limited-user, roles=[], requestedTenant=null]"
  },
  "status": 403
}

Si un utilisateur fournit des informations d'identification non valides, le cluster renvoie une exception Unauthorized.

Concepts clés

Lorsque vous vous lancez dans le contrôle d'accès détaillé, tenez compte des concepts suivants :

• Rôles : méthode de base pour utiliser un contrôle d'accès précis. Dans ce cas, les rôles sont distincts des rôles IAM. Les rôles contiennent n'importe quelle combinaison d'autorisations : à l'échelle du cluster, spécifique à l'index, au niveau du document et au niveau du champ.

• Cartographie : après avoir configuré un rôle, vous le mappez à un ou plusieurs utilisateurs. Par exemple, vous pouvez mapper trois rôles à un seul utilisateur : un rôle qui donne accès aux tableaux de bord, un qui fournit un accès à index1 en lecture seule et un autre qui fournit un accès en écriture à index2. Vous pouvez également inclure toutes ces autorisations dans un seul rôle.

• Utilisateurs : personnes ou applications qui adressent des demandes au OpenSearch cluster. Les utilisateurs disposent d'informations d'identification, qu'il s'agisse de clés d'accès IAM ou d'un nom d'utilisateur et d'un mot de passe, qu'ils spécifient lorsqu'ils font des demandes.

À propos de l'utilisateur principal

L'utilisateur principal dans OpenSearch Service est soit une combinaison de nom d'utilisateur et de mot de passe, soit un utilisateur principal IAM disposant des autorisations complètes sur le OpenSearch cluster sous-jacent. Un utilisateur est considéré comme un utilisateur principal s'il dispose de tous les accès au OpenSearch cluster et s'il a la possibilité de créer des utilisateurs internes, des rôles et des mappages de rôles dans les OpenSearch tableaux de bord.

Un utilisateur principal créé dans la console OpenSearch de service ou via la CLI est automatiquement mappé à deux rôles prédéfinis :

• all_access— Fournit un accès complet à toutes les opérations à l'échelle du cluster, l'autorisation d'écrire dans tous les index du cluster et l'autorisation d'écrire à tous les locataires.

• security_manager— Permet d'accéder au plugin de sécurité et de gérer les utilisateurs et les autorisations.

Ces deux rôles permettent à l'utilisateur d'accéder à l'onglet Sécurité des OpenSearch tableaux de bord, où il peut gérer les utilisateurs et les autorisations. Si vous créez un autre utilisateur interne et que vous le mappez uniquement au all_access rôle, l'utilisateur n'a pas accès à l'onglet Sécurité. Vous pouvez créer des utilisateurs principaux supplémentaires en les mappant explicitement aux security_manager rôles all_access et. Pour obtenir des instructions, veuillez consulter Utilisateurs principaux supplémentaires.

Lorsque vous créez un utilisateur principal pour votre domaine, vous pouvez spécifier un utilisateur principal IAM existant ou créer un utilisateur principal dans la base de données utilisateur interne. Tenez compte des points suivants lorsque vous décidez lequel utiliser :

• Principal IAM — Si vous choisissez un principal IAM pour votre utilisateur principal, toutes les demandes adressées au cluster doivent être signées à l'aide de AWS Signature Version 4.

  OpenSearch Le service ne prend en compte aucune des autorisations du principal IAM. L'utilisateur ou le rôle IAM sert uniquement à l'authentification. Les politiques relatives à cet utilisateur ou à ce rôle n'ont aucune incidence sur l'autorisation de l'utilisateur principal. L'autorisation est gérée par le biais des différentes autorisations du plugin OpenSearch de sécurité.

  Par exemple, vous pouvez n'attribuer aucune autorisation IAM à un principal IAM, et tant que la machine ou la personne peut s'authentifier auprès de cet utilisateur ou de ce rôle, elle dispose du pouvoir de l'utilisateur principal dans Service. OpenSearch

  Nous recommandons IAM si vous souhaitez utiliser les mêmes utilisateurs sur plusieurs clusters, si vous souhaitez utiliser Amazon Cognito pour accéder aux tableaux de bord ou si vous OpenSearch avez des clients qui prennent en charge la signature Signature version 4.

• Base de données utilisateur interne : si vous créez un maître dans la base de données utilisateur interne (avec une combinaison nom d'utilisateur et mot de passe), vous pouvez utiliser l'authentification HTTP de base (ainsi que les informations d'identification IAM) pour envoyer des demandes au cluster. La plupart des clients prennent en charge l'authentification de base, notamment curl, qui prend également en charge la version 4 de AWS Signature avec l'option --aws-sigv4. La base de données utilisateur interne est stockée dans un OpenSearch index, vous ne pouvez donc pas la partager avec d'autres clusters.

  Nous recommandons la base de données utilisateur interne si vous n'avez pas besoin de réutiliser les utilisateurs sur plusieurs clusters, si vous souhaitez utiliser l'authentification de base HTTP pour accéder aux tableaux de bord (plutôt qu'Amazon Cognito), ou si vous avez des clients qui prennent uniquement en charge l'authentification de base. La base de données utilisateur interne est le moyen le plus simple de démarrer avec OpenSearch Service.

Activation du contrôle précis des accès

Activez un contrôle d'accès précis à l'aide de la console ou de l' AWS CLIAPI de configuration. Pour les étapes, consultez Création et gestion de domaines Amazon OpenSearch Service.

Le contrôle d'accès détaillé nécessite Elasticsearch OpenSearch 6.7 ou version ultérieure. Il nécessite également le protocole HTTPS pour tout le trafic vers le domaine, le chiffrement des données au repos et le node-to-node chiffrement. Selon la façon dont vous configurez les fonctionnalités avancées du contrôle d'accès détaillé, le traitement supplémentaire de vos demandes peut nécessiter des ressources de calcul et de mémoire sur des nœuds de données individuels. Après avoir activé le contrôle précis des accès, vous ne pourrez pas le désactiver.

Activation du contrôle précis des accès sur des domaines existants

Vous pouvez activer un contrôle d'accès précis sur les domaines existants exécutant Elasticsearch OpenSearch 6.7 ou version ultérieure.

Pour activer le contrôle précis des accès sur un domaine existant (console)

1. Sélectionnez votre domaine et choisissez Actions et Edit security configuration (Modifier la configuration de sécurité).

2. Sélectionnez Enable fine-grained access control (Activer le contrôle précis des accès).

3. Choisissez comment créer l'utilisateur principal :

   • Si vous souhaitez utiliser IAM pour la gestion des utilisateurs, choisissez Set IAM ARN as master user (Définir l'ARN IAM en tant qu'utilisateur principal), puis indiquez l'ARN d'un rôle IAM.

   • Si vous souhaitez utiliser la base de données utilisateur interne, choisissez Create master user et spécifiez un nom d'utilisateur et un mot de passe.

4. (Facultatif) Sélectionnez Enable migration period for open/IP-based access policy (Activer la période de migration pour la stratégie d'accès Open/basée sur l'IP). Ce paramètre permet une période de transition de 30 jours pendant laquelle vos utilisateurs actuels peuvent continuer à accéder au domaine sans interruption. Les stratégies d'accès basées sur l'IP et Open existantes continueront à fonctionner avec votre domaine. Pendant cette période de migration, nous recommandons aux administrateurs de créer les rôles nécessaires et de les mapper aux utilisateurs pour le domaine. Si vous utilisez des stratégies basées sur l'identité au lieu d'une stratégie d'accès Open ou basée sur l'IP, vous pouvez désactiver ce paramètre.

   Vous devez également mettre à jour vos clients pour qu'ils utilisent un contrôle précis des accès pendant la période de migration. Par exemple, si vous associez des rôles IAM à un contrôle d'accès précis, vous devez mettre vos clients à jour pour qu'ils commencent à signer les demandes avec AWS Signature Version 4. Si vous configurez l'authentification de base HTTP avec un contrôle précis des accès, vous devez mettre à jour vos clients pour qu'ils fournissent les informations d'identification d'authentification de base appropriées dans les demandes.

   Pendant la période de migration, les utilisateurs qui accèdent au point de terminaison OpenSearch Dashboards pour le domaine arriveront directement sur la page de découverte plutôt que sur la page de connexion. Les administrateurs et les utilisateurs principaux peuvent choisir Login (Connexion) pour se connecter avec les informations d'identification de l'administrateur et configurer les mappages de rôles.

   Important

   OpenSearch Le service désactive automatiquement la période de migration après 30 jours. Nous vous recommandons de la terminer dès que vous aurez créé les rôles nécessaires et que vous les aurez mappés aux utilisateurs. Une fois la période de migration terminée, vous ne pouvez pas la réactiver.

5. Sélectionnez Enregistrer les modifications.

Le changement déclenche un déploiement bleu/vert pendant lequel l'état du cluster devient rouge, mais toutes les opérations du cluster ne sont pas affectées.

Pour activer le contrôle précis des accès sur un domaine existant (CLI)

Définissez AnonymousAuthEnabled sur true pour activer la période de migration avec un contrôle précis des accès :

aws opensearch update-domain-config --domain-name test-domain --region us-east-1 \
      --advanced-security-options '{ "Enabled": true, "InternalUserDatabaseEnabled":true, "MasterUserOptions": {"MasterUserName":"master-username","MasterUserPassword":"master-password"},"AnonymousAuthEnabled": true}'

À propos du rôle default_role

Le contrôle précis des accès nécessite un mappage des rôles. Si votre domaine utilise des politiques d'accès basées sur l'identité, OpenSearch Service associe automatiquement vos utilisateurs à un nouveau rôle appelé default_role afin de vous aider à migrer correctement les utilisateurs existants. Ce mappage temporaire garantit que vos utilisateurs peuvent toujours envoyer avec succès des demandes GET et PUT signées par IAM jusqu'à ce que vous créiez vos propres mappages de rôles.

Le rôle n'ajoute aucune vulnérabilité ou faille de sécurité à votre domaine OpenSearch de service. Nous vous recommandons de supprimer le rôle par défaut dès que vous aurez configuré vos propres rôles et que vous les aurez mappés en conséquence.

Scénarios de migration

Le tableau suivant décrit le comportement de chaque méthode d'authentification avant et après l'activation du contrôle précis des accès sur un domaine existant, ainsi que les étapes que les administrateurs doivent suivre pour mapper correctement leurs utilisateurs aux rôles :

Méthode d'authentification	Avant l'activation du contrôle précis des accès	Après l'activation du contrôle précis des accès	Tâches de l'administrateur
Politiques basées sur l’identité	Tous les utilisateurs respectant la politique IAM peuvent accéder au domaine.	Vous n'avez pas besoin d'activer la période de migration. OpenSearch Le service mappe automatiquement tous les utilisateurs qui satisfont à la politique IAM au rôle default_role afin qu'ils puissent continuer à accéder au domaine.	Créez des mappages de rôles personnalisés sur le domaine. Supprimez le rôle default_role.
Stratégies basées sur l'IP	Tous les utilisateurs des adresses IP ou des blocs d'adresses CIDR autorisés peuvent accéder au domaine.	Pendant la période de migration de 30 jours, tous les utilisateurs des adresses IP ou des blocs d'adresses CIDR autorisés peuvent continuer à accéder au domaine.	Créez des mappages de rôles personnalisés sur le domaine. Mettez à jour vos clients pour qu'ils fournissent des informations d'identification d'authentification de base ou des informations d'identification IAM, selon la configuration de votre mappage de rôles. Désactivez la période de migration. Les utilisateurs des adresses IP ou blocs d'adresses CIDR autorisés qui envoient des demandes sans authentification de base ou informations d'identification IAM perdront l'accès au domaine.
Stratégies d'accès Open	Tous les utilisateurs sur Internet peuvent accéder au domaine.	Pendant la période de migration de 30 jours, tous les utilisateurs sur Internet peuvent continuer à accéder au domaine.	Créez des mappages de rôles sur le domaine. Mettez à jour vos clients pour qu'ils fournissent des informations d'identification d'authentification de base ou des informations d'identification IAM, selon la configuration de votre mappage de rôles. Désactivez la période de migration. Les utilisateurs qui envoient des demandes sans authentification de base ou informations d'identification IAM perdront l'accès au domaine.

Accès aux OpenSearch tableaux de bord en tant qu'utilisateur principal

Le contrôle d'accès précis est doté d'un plugin OpenSearch Dashboards qui simplifie les tâches de gestion. Vous pouvez utiliser les tableaux de bord pour gérer les utilisateurs, les rôles, les mappages, les groupes d'actions et les locataires. La page de connexion OpenSearch aux tableaux de bord et la méthode d'authentification sous-jacente varient toutefois en fonction de la façon dont vous gérez les utilisateurs et configurez votre domaine.

• Si vous souhaitez utiliser IAM pour la gestion des utilisateurs, utilisez Configuration de l'authentification Amazon Cognito pour les tableaux de bord OpenSearch pour accéder aux tableaux de bord. Sinon, les tableaux de bord afficheront une page de connexion non fonctionnelle. Consultez Limites.

  Avec l'authentification Amazon Cognito, l'un des rôles assumés dans le pool d'identités doit correspondre au rôle IAM que vous avez spécifié pour l'utilisateur principal. Pour en savoir plus sur cette configuration, consultez (Facultatif) Configuration du contrôle précis des accès et Didacticiel : configurer un domaine avec un utilisateur principal IAM et l'authentification Amazon Cognito.

  

• Si vous choisissez d'utiliser la base de données utilisateur interne, vous pouvez vous connecter à Dashboards avec votre nom d'utilisateur et votre mot de passe principaux. Vous devez accéder aux tableaux de bord via HTTPS. L'authentification Amazon Cognito et SAML pour les tableaux de bord remplacent tous les deux cet écran de connexion.

  Pour en savoir plus sur cette configuration, consultez Didacticiel : configurer un domaine avec la base de données utilisateur interne et l'authentification de base HTTP.

  

• Si vous choisissez d'utiliser l'authentification SAML, vous pouvez vous connecter à l'aide des informations d'identification d'un fournisseur d'identité externe. Pour en savoir plus, consultez Authentification SAML pour les tableaux de bord OpenSearch .

Gestion des autorisations

Comme indiqué dans Concepts clés, vous gérez les autorisations de contrôle précis des accès à l'aide de rôles, d'utilisateurs et de mappages. Cette section décrit comment créer et appliquer ces ressources. Nous vous recommandons de vous connecter aux tableaux de bord en tant qu'utilisateur principal pour exécuter ces opérations.

Note

Les autorisations que vous choisissez d'accorder aux utilisateurs varient considérablement en fonction du cas d'utilisation. Nous ne pouvons pas couvrir tous les scénarios de cette documentation. Lorsque vous déterminez les autorisations à accorder à vos utilisateurs, veillez à faire référence aux autorisations de OpenSearch cluster et d'index mentionnées dans les sections suivantes, et respectez toujours le principe du moindre privilège.

Créer des rôles

Vous pouvez créer de nouveaux rôles pour un contrôle d'accès précis à l'aide de OpenSearch tableaux de bord ou de l'_plugins/_securityopération dans l'API REST. Pour en savoir plus, consultez Créer des rôles.

Le contrôle précis des accès inclut également un certain nombre de rôles prédéfinis. Les clients tels que OpenSearch Dashboards et Logstash envoient une grande variété de demandes OpenSearch, ce qui peut rendre difficile la création manuelle de rôles avec un minimum d'autorisations. Par exemple, le rôle opensearch_dashboards_user inclut les autorisations dont un utilisateur a besoin pour créer des modèles d'index, des visualisations, des tableaux de bord et des locataires. Nous vous recommandons de le mapper à n'importe quel utilisateur ou rôle backend qui accède aux tableaux de bord, ainsi qu'aux rôles supplémentaires qui permettent d'accéder à d'autres index.

Amazon OpenSearch Service ne propose pas les OpenSearch rôles suivants :

• observability_full_access

• observability_read_access

• reports_read_access

• reports_full_access

Amazon OpenSearch Service propose plusieurs rôles qui ne sont pas disponibles avec OpenSearch :

• ultrawarm_manager

• ml_full_access

• cold_manager

• notifications_full_access

• notifications_read_access

Sécurité au niveau du cluster

Les autorisations au niveau du cluster permettent de faire des demandes étendues telles que _mget, _msearch, et _bulk, de surveiller l'état, de prendre des instantanés, etc. Gérez ces autorisations à l'aide de la section Autorisations de cluster lors de la création d'un rôle. Pour obtenir la liste complète des autorisations au niveau du cluster, consultez Autorisations de cluster.

Vous pouvez souvent atteindre la position de sécurité souhaitée à l'aide d'une combinaison des groupes d'actions par défaut, au lieu de le faire à l'aide d'autorisations individuelles. Pour obtenir la liste des groupes d'actions au niveau du cluster, consultez Niveau du cluster.

Sécurité au niveau de l'index

Les autorisations de niveau index incluent la possibilité de créer de nouveaux index, de rechercher des index, de lire et d'écrire des documents, de supprimer des documents, de gérer des alias, etc. Gérez ces autorisations à l'aide de la section Autorisations d'index lors de la création d'un rôle. Pour obtenir la liste complète des autorisations au niveau de l'indez, consultez Autorisations d'index.

Vous pouvez souvent atteindre la position de sécurité souhaitée à l'aide d'une combinaison des groupes d'actions par défaut, au lieu de le faire à l'aide d'autorisations individuelles. Pour obtenir la liste des groupes d'actions au niveau de l'index, consultez Niveau d'index.

Sécurité au niveau du document

La sécurité au niveau du document vous permet de restreindre les documents d'un index qu'un utilisateur peut consulter. Lorsque vous créez un rôle, spécifiez un modèle d'index et une OpenSearch requête. Tous les utilisateurs que vous mappez à ce rôle ne peuvent voir que les documents correspondant à la requête. La sécurité au niveau du document affecte le nombre d'accès que vous obtenez lorsque vous effectuez une recherche.

Pour en savoir plus, consultez Sécurité au niveau du document.

Sécurité au niveau du champ

La sécurité au niveau du champ vous permet de contrôler les champs de document qu'un utilisateur peut consulter. Lors de la création d'un rôle, ajoutez une liste de champs à inclure ou à exclure. Si vous incluez des champs, tous les utilisateurs que vous mappez à ce rôle ne peuvent voir que ces champs. Si vous excluez les champs, ils peuvent voir tous les champs sauf ceux exclus. La sécurité au niveau du champ affecte le nombre de champs inclus dans les appels lorsque vous effectuez une recherche.

Pour en savoir plus, consultez Sécurité au niveau du champ.

Masquage des champs

Le masquage des champs est une alternative à la sécurité au niveau du champ qui vous permet d'anonymiser les données d'un champ plutôt que de les supprimer complètement. Lors de la création d'un rôle, ajoutez une liste de champs à masquer. Le masquage des champs détermine si vous pouvez voir le contenu d'un champ lorsque vous effectuez une recherche.

Astuce

Si vous appliquez le masquage standard à un champ, OpenSearch Service utilise un hachage aléatoire sécurisé qui peut entraîner des résultats d'agrégation inexacts. Pour effectuer des agrégations sur des champs masqués, utilisez plutôt un masquage basé sur un modèle.

Créer des utilisateurs

Si vous avez activé la base de données utilisateur interne, vous pouvez créer des utilisateurs à l'aide OpenSearch des tableaux de bord ou de l'_plugins/_securityopération de l'API REST. Pour en savoir plus, consultez Créer des utilisateurs.

Si vous avez choisi IAM pour votre utilisateur principal, ignorez cette partie des tableaux de bord. Créez des rôles IAM à la place. Pour plus d'informations, consultez le Guide de l'utilisateur IAM.

Mappage des rôles aux utilisateurs

Le mappage des rôles est l'aspect le plus critique du contrôle précis des accès. Le contrôle précis des accès dispose de rôles prédéfinis pour vous aider à démarrer, mais à moins que vous ne mappiez des rôles à des utilisateurs, chaque demande adressée au cluster se termine par une erreur d'autorisation.

Les rôles principaux peuvent contribuer à simplifier le processus de mappage des rôles. Plutôt que de mapper le même rôle à 100 utilisateurs individuels, vous pouvez associer le rôle à un rôle principal partagé par les 100 utilisateurs. Les rôles backend peuvent correspondre à des rôles IAM ou à des chaînes arbitraires.

• Spécifiez les utilisateurs, les ARN utilisateur et les chaînes utilisateur Amazon Cognito dans la section Users (Utilisateurs). Les chaînes utilisateur Cognito prennent la forme Cognito/user-pool-id/username.

• Spécifiez les rôles backend et les ARN de rôle IAM dans la section Rôles backend.

Vous pouvez associer les rôles aux utilisateurs à l'aide de OpenSearch tableaux de bord ou de l'_plugins/_securityopération de l'API REST. Pour en savoir plus, consultez Mapper des utilisateurs à des rôles.

Créer des groupes d'actions

Les groupes d'actions sont des ensembles d'autorisations que vous pouvez réutiliser sur différentes ressources. Vous pouvez créer de nouveaux groupes d'actions à l'aide de OpenSearch tableaux de bord ou de l'_plugins/_securityopération de l'API REST, bien que les groupes d'actions par défaut soient suffisants dans la plupart des cas d'utilisation. Pour en savoir plus sur les groupes d'actions par défaut, consultez Groupes d'actions par défaut.

OpenSearch Tableaux de bord mutualisés

Les locataires sont des espaces permettant d'enregistrer des modèles d'index, des visualisations, des tableaux de bord et d'autres objets des tableaux de bord. La mutualisation des tableaux de bord vous permet de partager en toute sécurité votre travail avec d'autres utilisateurs de Dashboards (ou de le garder privé) et de configurer les locataires de manière dynamique. Vous pouvez contrôler quels rôles ont accès à un locataire et si ces rôles ont un accès en lecture ou en écriture. Le locataire global est le client par défaut. Pour en savoir plus, consultez la section OpenSearch Tableaux de bord mutualisés.

Pour afficher votre locataire actuel ou changer de locataire

1. Accédez aux OpenSearch tableaux de bord et connectez-vous.

2. Sélectionnez l'icône de votre utilisateur en haut à droite et choisissez Switch tenants (Changer les locataires).

3. Vérifiez votre locataire avant de créer des visualisations ou des tableaux de bord. Si vous souhaitez partager votre travail avec tous les autres utilisateurs des tableaux de bord, choisissez Global. Pour partager votre travail avec un sous-ensemble d'utilisateurs des tableaux de bord, choisissez un autre locataire partagé. Sinon, choisissez Private (Privé).

Note

OpenSearch Dashboards gère un index distinct pour chaque locataire et crée un modèle d'index appelétenant_template. Ne supprimez ni ne modifiez l'tenant_templateindex, car cela pourrait entraîner un dysfonctionnement des OpenSearch tableaux de bord si le mappage de l'index des locataires est mal configuré.

Configurations recommandées

En raison de la façon dont le contrôle d'accès affiné interagit avec d'autres fonctionnalités de sécurité, nous recommandons plusieurs configurations de contrôle d'accès affiné qui fonctionnent bien dans la plupart des cas d'utilisation.

Description	Utilisateur maître	Stratégie d'accès au domaine
Utilisez les informations d'identification IAM pour les appels aux OpenSearch API et utilisez l'authentification SAML pour accéder aux tableaux de bord. Gérer les rôles de contrôle précis des accès à l'aide de l'API REST.	Rôle ou utilisateur IAM	{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "*" }, "Action": "es:ESHttp*", "Resource": "domain-arn/*" } ] }
Utilisez les informations d'identification IAM ou l'authentification de base pour les appels aux OpenSearch API. Gérer les rôles de contrôle précis des accès à l'aide de l'API REST. Cette configuration offre une grande flexibilité, en particulier si vous avez des OpenSearch clients qui ne prennent en charge que l'authentification de base. Si vous disposez d'un fournisseur d'identité existant, utilisez l'authentification SAML pour accéder aux tableaux de bord. Dans le cas contraire, gérez les utilisateurs des tableaux de bord dans la base de données utilisateur interne.	Nom d'utilisateur et mot de passe	{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "*" }, "Action": "es:ESHttp*", "Resource": "domain-arn/*" } ] }
Utilisez les informations d'identification IAM pour les appels aux OpenSearch API et utilisez Amazon Cognito pour accéder aux tableaux de bord. Gérer les rôles de contrôle précis des accès à l'aide de l'API REST.	Rôle ou utilisateur IAM	{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "*" }, "Action": "es:ESHttp*", "Resource": "domain-arn/*" } ] }
Utilisez les informations d'identification IAM pour les appels aux OpenSearch API et bloquez la plupart des accès aux tableaux de bord. Gérer les rôles de contrôle précis des accès à l'aide de l'API REST.	Rôle ou utilisateur IAM	{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "*" }, "Action": "es:ESHttp*", "Resource": "domain-arn/*" }, { "Effect": "Deny", "Principal": { "AWS": "*" }, "Action": "es:ESHttp*", "Resource": "domain-arn/_dashboards*" } ] }

Limites

Le contrôle précis des accès présente plusieurs limites importantes :

• L'aspect hosts des mappages de rôles, qui mappe les rôles aux noms d'hôte ou aux adresses IP, ne fonctionne pas si le domaine se trouve dans un VPC. Vous pouvez toujours mapper les rôles avec les utilisateurs et les rôles backend.

• Si vous choisissez IAM pour l'utilisateur principal et que vous n'activez pas Amazon Cognito ou l'authentification SAML, les tableaux de bord afficheront une page de connexion non fonctionnelle.

• Si vous choisissez IAM pour l'utilisateur principal, vous pouvez toujours créer des utilisateurs dans la base de données utilisateur interne. Étant donné que l'authentification de base HTTP n'est pas activée dans cette configuration, toutes les demandes signées avec ces informations d'identification utilisateur sont rejetées.

• Si vous utilisez SQL pour interroger un index auquel vous n'avez pas accès, vous recevez une erreur « aucune autorisation ». Si l'index n'existe pas, vous recevez une erreur « no such index » (L'index n'existe pas). Cette différence dans les messages d'erreur signifie que vous pouvez confirmer l'existence d'un index si vous devinez son nom.

  Pour minimiser le problème, n'incluez pas d'informations sensibles dans les noms d'index. Pour refuser tout accès à SQL, ajoutez l'élément suivant à votre stratégie d'accès au domaine :

  {
    "Effect": "Deny",
    "Principal": {
      "AWS": [
        "*"
      ]
    },
    "Action": [
      "es:*"
    ],
    "Resource": "arn:aws:es:us-east-1:123456789012:domain/my-domain/_plugins/_sql"
  }

• Si la version de votre domaine est 2.3 ou supérieure et que le contrôle d'accès détaillé est activé, le réglage sur 1 max_clause_count entraîne des problèmes avec votre domaine. Nous vous recommandons de définir un nombre plus élevé pour ce compte.

• Si vous activez le contrôle d'accès détaillé dans un domaine où le contrôle d'accès détaillé n'est pas configuré, pour les sources de données créées pour une requête directe, vous devez configurer vous-même des rôles de contrôle d'accès précis. Pour plus d'informations sur la façon de configurer des rôles d'accès précis, consultez Création d'intégrations de sources de données Amazon OpenSearch Service avec Amazon S3.

Modification de l'utilisateur maître

Si vous oubliez les détails de l'utilisateur principal, vous pouvez le reconfigurer à l'aide de la console, de l' AWS CLIou de l'API de configuration.

Pour modifier l'utilisateur maître (console)

1. Accédez à la console Amazon OpenSearch Service à l'adresse https://console.aws.amazon.com/aos/home/.

2. Sélectionnez votre domaine et choisissez Actions et Edit security configuration (Modifier la configuration de sécurité).

3. Choisissez Set IAM ARN as master user (Définir l'ARN IAM en tant qu'utilisateur principal) ou Create master user (Créer un nouvel utilisateur principal).

   • Si vous avez précédemment utilisé un utilisateur principal IAM, le contrôle précis des accès remappera le rôle all_access avec le nouvel ARN IAM que vous indiquerez.

   • Si vous avez précédemment utilisé la base de données utilisateur interne, le contrôle précis des accès créera un nouvel utilisateur principal. Vous pouvez utiliser le nouvel utilisateur principal pour supprimer l'ancien.

   • Le passage de la base de données utilisateur interne à un utilisateur principal IAM ne supprime aucun utilisateur de la base de données utilisateur interne. Cela permet simplement de désactiver l'authentification de base HTTP. Supprimez manuellement les utilisateurs de la base de données utilisateur interne ou conservez-les au cas où vous auriez besoin de réactiver l'authentification HTTP de base.

4. Sélectionnez Enregistrer les modifications.

Utilisateurs principaux supplémentaires

Vous désignez un utilisateur principal lorsque vous créez un domaine, mais si vous le souhaitez, vous pouvez utiliser cet utilisateur principal pour créer d'autres utilisateurs principaux. Deux options s'offrent à vous : les OpenSearch tableaux de bord ou l'API REST.

• Dans les tableaux de bord, choisissez Security (Sécurité), Roles (Rôles), puis mappez le nouvel utilisateur principal aux rôles all_access et security_manager.

  

• Pour utiliser l'API REST, envoyez les requêtes suivantes :

  PUT _plugins/_security/api/rolesmapping/all_access
  {
    "backend_roles": [
      "arn:aws:iam::123456789012:role/fourth-master-user"
    ],
    "hosts": [],
    "users": [
      "master-user",
      "second-master-user",
      "arn:aws:iam::123456789012:user/third-master-user"
    ]
  }

  PUT _plugins/_security/api/rolesmapping/security_manager
  {
    "backend_roles": [
      "arn:aws:iam::123456789012:role/fourth-master-user"
    ],
    "hosts": [],
    "users": [
      "master-user",
      "second-master-user",
      "arn:aws:iam::123456789012:user/third-master-user"
    ]
  }

  Comme ces demandes remplacent les mappages de rôles actuels, exécutez d'abord les demandes GET afin que vous puissiez inclure tous les rôles actuels dans les demandes PUT. L'API REST est particulièrement utile si vous ne pouvez pas accéder aux tableaux de bord et que vous souhaitez mapper un rôle IAM Amazon Cognito au rôle all_access.

Instantanés manuels

Le contrôle précis des accès introduit quelques complications supplémentaires avec la prise des instantanés manuels. Pour enregistrer un référentiel d'instantanés, même si vous utilisez l'authentification de base HTTP à d'autres fins, vous devez mapper le rôle manage_snapshots à un rôle IAM disposant des autorisations iam:PassRole pour assumer TheSnapshotRole, comme défini dans Prérequis.

Utilisez ensuite ce rôle IAM pour envoyer une demande signée au domaine, comme indiqué dans Inscription d'un référentiel d'instantanés manuels.

Intégrations

Si vous utilisez d'autres AWS services avec OpenSearch Service, vous devez fournir les rôles IAM pour ces services avec les autorisations appropriées. Par exemple, les flux de diffusion Firehose utilisent souvent un rôle IAM appelé. firehose_delivery_role Dans Tableaux de bord, créez un rôle pour le contrôle précis des accès, puis mappez le rôle IAM à celui-ci. Dans ce cas, le nouveau rôle nécessite les autorisations suivantes :

{
  "cluster_permissions": [
    "cluster_composite_ops",
    "cluster_monitor"
  ],
  "index_permissions": [{
    "index_patterns": [
      "firehose-index*"
    ],
    "allowed_actions": [
      "create_index",
      "manage",
      "crud"
    ]
  }]
}

Les autorisations varient en fonction des actions effectuées par chaque service. Une AWS IoT règle ou une AWS Lambda fonction qui indexe des données nécessite probablement des autorisations similaires à celles de Firehose, tandis qu'une fonction Lambda qui effectue uniquement des recherches peut utiliser un ensemble plus limité.

Différences d'API REST

L'API REST de contrôle d'accès précise varie légèrement en fonction de votre version de OpenSearch /Elasticsearch. Avant d'adresser une demande PUT, effectuez une demande GET pour vérifier le corps de requête attendu. Par exemple, une demande GET adressée à _plugins/_security/api/user renvoie tous les utilisateurs, que vous pouvez ensuite modifier et utiliser pour effectuer des demandes PUT valides.

Sur Elasticsearch 6x, les demandes de création d'utilisateurs se présentent comme suit :

PUT _opendistro/_security/api/user/new-user
{
  "password": "some-password",
  "roles": ["new-backend-role"]
}

Sur Elasticsearch 7.x OpenSearch ou sur Elasticsearch, les requêtes se présentent comme suit (remplacez _plugins par Elasticsearch _opendistro si vous utilisez Elasticsearch) :

PUT _plugins/_security/api/user/new-user
{
  "password": "some-password",
  "backend_roles": ["new-backend-role"]
}

En outre, les locataires sont les propriétés des rôles dans Elasticsearch 6.x :

GET _opendistro/_security/api/roles/all_access

{
  "all_access": {
    "cluster": ["UNLIMITED"],
    "tenants": {
      "admin_tenant": "RW"
    },
    "indices": {
      "*": {
        "*": ["UNLIMITED"]
      }
    },
    "readonly": "true"
  }
}

Dans OpenSearch Elasticsearch 7.x, ce sont des objets dotés de leur propre URI (_pluginsremplacez-le _opendistro si vous utilisez Elasticsearch) :

GET _plugins/_security/api/tenants

{
  "global_tenant": {
    "reserved": true,
    "hidden": false,
    "description": "Global tenant",
    "static": false
  }
}

Pour obtenir de la documentation sur l' OpenSearch API REST, consultez la référence de l'API du plugin de sécurité.

Astuce

Si vous utilisez la base de données utilisateur interne, vous pouvez utiliser curl pour effectuer des demandes et tester votre domaine. Essayez les exemples de commande suivants :

curl -XGET -u 'master-user:master-user-password' 'domain-endpoint/_search'
curl -XGET -u 'master-user:master-user-password' 'domain-endpoint/_plugins/_security/api/user'