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 :

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 :

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 lancez dans le contrôle d'accès détaillé, tenez compte des concepts suivants :

À 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 :

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 :

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

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

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.

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 :

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.

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.

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 :

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

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.

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.

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.

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.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "*"
      },
      "Action": "es:ESHttp*",
      "Resource": "domain-arn/*"
    }
  ]
}

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "*"
      },
      "Action": "es:ESHttp*",
      "Resource": "domain-arn/*"
    }
  ]
}

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "*"
      },
      "Action": "es:ESHttp*",
      "Resource": "domain-arn/*"
    }
  ]
}

{
  "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 :

Modification de l'utilisateur maître

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

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.

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 OpenSearch Elasticsearch 7.x, 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é.

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'