Surveillance des journaux d'audit dans Amazon OpenSearch Service

Si votre domaine Amazon OpenSearch Service utilise un contrôle d'accès précis, vous pouvez activer les journaux d'audit pour vos données. Les journaux d'audit sont hautement personnalisables et vous permettent de suivre l'activité des utilisateurs sur vos OpenSearch clusters, notamment les réussites et les échecs d'authentification, les demandes OpenSearch, les modifications d'index et les requêtes de recherche entrantes. La configuration par défaut permet de suivre un ensemble d'actions utilisateur courantes. Nous vous recommandons toutefois d'adapter les paramètres à vos besoins précis.

Tout comme les journaux OpenSearch d'application et les journaux lents, le OpenSearch service publie les journaux d'audit dans CloudWatch Logs. Si cette option est activée, la CloudWatch tarification standard s'applique.

Note

Pour activer les journaux d'audit, votre rôle d'utilisateur doit être mappé au security_manager rôle, ce qui vous donne accès à l' OpenSearch plugins/_securityAPI REST. Pour en savoir plus, veuillez consulter la section Modification de l'utilisateur maître.

Limites

Les journaux d'audit présentent les limitations suivantes :

• Les journaux d'audit n'incluent pas les requêtes de recherche inter-clusters qui ont été rejetées par la politique d'accès au domaine de la destination.

• La longueur maximale de chaque message de journal d'audit est de 10 000 caractères. Si un message du journal d'audit dépasse cette limite, il est tronqué.

Activation des journaux d'audit

L'activation des journaux d'audit est un processus en deux étapes. Vous devez d'abord configurer votre domaine pour publier les journaux d'audit dans CloudWatch Logs. Vous activez ensuite les journaux d'audit dans les OpenSearch tableaux de bord et vous les configurez pour répondre à vos besoins.

Important

En cas d'erreur au cours de cette procédure, consultez Impossible d'activer les journaux d'audit pour obtenir des informations de dépannage.

Étape 1 : activer les journaux d'audit et configurer une stratégie d'accès

Ces étapes décrivent comment activer les journaux d'audit à l'aide de la console. Vous pouvez également les activer à l'aide AWS CLI de l'API ou du OpenSearch service.

Pour activer les journaux d'audit pour un domaine de OpenSearch service (console)

1. Choisissez le domaine pour ouvrir sa configuration, puis allez à l'onglet Logs (Journaux).

2. Sélectionnez Audit logs (Journaux d'audit) et ensuite Enable (Activer).

3. Créez un groupe de CloudWatch journaux ou choisissez-en un existant.

4. Choisissez une stratégie d'accès qui contient les autorisations appropriées ou créez une stratégie à l'aide du code JSON que la console fournit :

   {
     "Version": "2012-10-17",
     "Statement": [
       {
         "Effect": "Allow",
         "Principal": {
           "Service": "es.amazonaws.com"
         },
         "Action": [
           "logs:PutLogEvents",
           "logs:CreateLogStream"
         ],
         "Resource": "cw_log_group_arn"
       }
     ]
   }

   Nous vous recommandons d'ajouter les clés de condition aws:SourceAccount et aws:SourceArn à la stratégie pour vous protéger contre le problème du député confus. Le compte source est le propriétaire du domaine et l'ARN source est l'ARN du domaine. Votre domaine doit être sur le logiciel de service R20211203 ou plus récent afin d'ajouter ces clés de condition.

   Par exemple, vous pouvez ajouter la clé de condition suivante à la stratégie :

   "Condition": {
       "StringEquals": {
           "aws:SourceAccount": "account-id"
       },
       "ArnLike": {
           "aws:SourceArn": "arn:aws:es:region:account-id:domain/domain-name"
       }
   }

5. Sélectionnez Activer.

Étape 2 : activer les journaux d'audit dans les OpenSearch tableaux de bord

Après avoir activé les journaux d'audit dans la console de OpenSearch service, vous devez également les activer dans les OpenSearch tableaux de bord et les configurer en fonction de vos besoins.

1. Ouvrez OpenSearch les tableaux de bord et choisissez Sécurité dans le menu de gauche.

2. Choisissez Journaux d'audit.

3. Choisissez Activer la journalisation d'audit.

L'interface utilisateur de Dashboards offre un contrôle total sur les paramètres des journaux d'audit sous General settings (Paramètres généraux) et Compliance settings (Paramètres de conformité). Pour obtenir une description de toutes les options de configuration, consultez Paramètres des journaux d'audit.

Activez la journalisation des audits à l'aide du AWS CLI

La AWS CLI commande suivante active les journaux d'audit sur un domaine existant :

aws opensearch update-domain-config --domain-name my-domain --log-publishing-options "AUDIT_LOGS={CloudWatchLogsLogGroupArn=arn:aws:logs:us-east-1:123456789012:log-group:my-log-group,Enabled=true}"

Vous pouvez également activer les journaux d'audit lorsque vous créez un domaine. Pour plus d'informations, consultez le Guide de référence des commandes AWS CLI.

Activation du journal d'audit à l'aide de l'API de configuration

Cette demande adressée à l'API de configuration active les journaux d'audit sur un domaine existant :

POST https://es.us-east-1.amazonaws.com/2021-01-01/opensearch/domain/my-domain/config
{
  "LogPublishingOptions": {
    "AUDIT_LOGS": {
      "CloudWatchLogsLogGroupArn":"arn:aws:logs:us-east-1:123456789012:log-group1:sample-domain",
      "Enabled":true
    }
  }
}

Pour plus d'informations, consultez la référence de l'API Amazon OpenSearch Service.

Couches et catégories de journaux d'audit

La communication dans les clusters s'effectue sur deux couches distinctes : la couche REST et la couche de transport.

• La couche REST couvre la communication avec les clients HTTP tels que curl, Logstash, OpenSearch Dashboards, le client REST de haut niveau Java, la bibliothèque de requêtes Python, c'est-à-dire toutes les requêtes HTTP qui arrivent au cluster.

• La couche de transport couvre la communication entre les nœuds. Par exemple, une fois qu'une requête de recherche arrive au cluster (sur la couche REST), le nœud de coordination qui répond à la requête envoie la requête aux autres nœuds, reçoit leurs réponses, réunit les documents nécessaires et les rassemble dans la réponse finale. Les opérations telles que l'allocation de partitions et le rééquilibrage se font également sur la couche de transport.

Vous pouvez activer ou désactiver les journaux d'audit pour des couches entières, ainsi que pour des catégories d'audit individuelles relatives à une couche. Le tableau suivant contient un récapitulatif des catégories d'audit et des couches pour lesquelles elles sont disponibles.

Catégorie	Description	Disponible pour la couche REST	Disponible pour la couche de transport
FAILED_LOGIN	Une demande contenait des informations d'identification valides et l'authentification a abouti.	Oui	Oui
MISSING_PRIVILEGES	Un utilisateur ne disposait pas des privilèges nécessaires pour effectuer la demande.	Oui	Oui
GRANTED_PRIVILEGES	Un utilisateur disposait des privilèges pour effectuer la demande.	Oui	Oui
OPENSEARCH_SECURITY_INDEX_ATTEMPT	Une demande a tenté de modifier l'index .opendistro_security.	Non	Oui
AUTHENTICATED	Une demande contenait des informations d'identification valides et l'authentification a abouti.	Oui	Oui
INDEX_EVENT	Une demande a effectué une opération administrative sur un index, comme la création d'un index, la définition d'un alias ou l'exécution d'une fusion forcée. La liste complète des indices:admin/ actions incluses dans cette catégorie est disponible dans la OpenSearch documentation.	Non	Oui

Outre ces catégories standard, le contrôle précis des accès offre plusieurs catégories supplémentaires conçues pour répondre aux exigences de conformité des données.

Catégorie	Description
COMPLIANCE_DOC_READ	Une demande a exécuté un événement de lecture sur un document dans un index.
COMPLIANCE_DOC_WRITE	Une demande a exécuté un événement d'écriture sur un document dans un index.
COMPLIANCE_INTERNAL_CONFIG_READ	Une demande a exécuté un événement de lecture sur l'index .opendistro_security.
COMPLIANCE_INTERNAL_CONFIG_WRITE	Une demande a exécuté un événement d'écriture sur l'index .opendistro_security.

Vous pouvez avoir n'importe quelle combinaison de catégories et d'attributs de message. Par exemple, si vous envoyez une demande REST pour indexer un document, les lignes suivantes peuvent apparaître dans les journaux d'audit :

• AUTHENTICATED sur la couche REST (authentification)

• GRANDED_PRIVILEGE sur la couche de transport (autorisation)

• COMPLIANCE_DOC_WRITE (document écrit dans un index)

Paramètres des journaux d'audit

Les journaux d'audit disposent de nombreuses options de configuration.

Paramètres généraux

Les paramètres généraux vous permettent d'activer ou de désactiver des catégories individuelles ou des couches entières. Nous vous recommandons vivement de maintenir GRANTED_PRIVILEGES et AUTHENTICATED comme catégories exclues. À défaut, ces catégories sont journalisées pour chaque demande valide adressée au cluster.

Nom	Paramètres backend	Description
Couche REST	enable_rest	Permet d'activer ou de désactiver les événements qui se produisent sur la couche REST.
Catégories désactivées sur la couche REST	disabled_rest_categories	Permet de spécifier les catégories d'audit à ignorer sur la couche REST. La modification de ces catégories peut considérablement augmenter la taille des journaux d'audit.
Couche de transport	enable_transport	Permet d'activer ou de désactiver les événements qui se produisent sur la couche de transport.
Catégories désactivées sur la couche de transport	disabled_transport_categories	Permet de spécifier les catégories d'audit à ignorer sur la couche de transport. La modification de ces catégories peut considérablement augmenter la taille des journaux d'audit.

Les paramètres d'attribut vous permettent de personnaliser le niveau de détail de chaque ligne de journal.

Nom	Paramètres backend	Description
Demandes groupées	resolve_bulk_requests	L'activation de ce paramètre génère un journal pour chacun des documents associés à une demande groupée, ce qui peut considérablement augmenter la taille des journaux d'audit.
Corps de la demande	log_request_body	Permet d'inclure le corps des requêtes.
Résolution des index	resolve_indices	Permet de résoudre les alias en index.

Utilisez les paramètres d'exclusion pour exclure un ensemble d'utilisateurs ou de chemins d'API :

Nom	Paramètres backend	Description
Utilisateurs ignorés	ignore_users	Permet de spécifier les utilisateurs à exclure.
Demandes ignorées	ignore_requests	Permet de spécifier les modèles de demande à exclure.

Paramètres de conformité

Les paramètres de conformité vous permettent de définir l'accès au niveau de l'index, du document ou du champ.

Nom	Paramètres backend	Description
Journalisation de la conformité	enable_compliance	Permet d'activer ou de désactiver la journalisation de la conformité.

Vous pouvez spécifier les paramètres suivants pour la journalisation des événements de lecture et d'écriture.

Nom	Paramètres backend	Description
Journalisation de la configuration interne	internal_config	Activer ou désactiver la journalisation des événements sur l'index .opendistro_security.

Vous pouvez spécifier les paramètres suivants pour les événements de lecture.

Nom	Paramètres backend	Description
Métadonnées de lecture	read_metadata_only	Permet de n'inclure que les métadonnées des événements de lecture. Aucun champ de document n'est inclus.
Utilisateurs ignorés	read_ignore_users	Permet de ne pas inclure certains utilisateurs pour les événements de lecture.
Champs surveillés	read_watched_fields	Permet de spécifier les index et les champs à surveiller pour les événements de lecture. L'ajout de champs surveillés génère un journal par accès au document, ce qui peut considérablement augmenter la taille des journaux d'audit. Les champs surveillés prennent en charge les modèles d'index et les modèles de champ : { "index-name-pattern": [ "field-name-pattern" ], "logs*": [ "message" ], "twitter": [ "id", "user*" ] }

Vous pouvez spécifier les paramètres suivants pour les événements d'écriture.

Nom	Paramètres backend	Description
Métadonnées d'écriture	write_metadata_only	Permet de n'inclure que les métadonnées des événements d'écriture. Aucun champ de document n'est inclus.
Journalisation des différences	write_log_diffs	Si write_metadata_only est défini sur la valeur false, cela permet de n'inclure que les différences entre les événements d'écriture.
Utilisateurs ignorés	write_ignore_users	Permet de ne pas inclure certains utilisateurs pour les événements d'écriture.
Index surveillés	write_watched_indices	Permet de spécifier les index ou les modèles d'index à surveiller pour les événements d'écriture. L'ajout de champs surveillés génère un journal par accès au document, ce qui peut considérablement augmenter la taille des journaux d'audit.

Exemples de journaux d'audit

Cette section comprend un exemple de configuration, de requête de recherche et le journal d'audit correspondant pour tous les événements de lecture et d'écriture d'un index.

Étape 1 : Configurer des journaux d'audit

Après avoir activé la publication des journaux d'audit dans un groupe de CloudWatch journaux, accédez à la page de journalisation OpenSearch des audits des tableaux de bord et choisissez Activer la journalisation des audits.

1. Dans Paramètres généraux, choisissez Configurer et vérifiez que la couche REST est activée.

2. Dans Paramètres de conformité, choisissez Configurer.

3. Sous Écriture, accédez à Champs surveillés et ajoutez à cet index le champ accounts de tous les événements d'écriture.

4. Sous Read (Lecture), accédez à Watched Fields (Champs surveillés) et ajoutez les champs ssn et id- à l'index accounts :

   {
     "accounts-": [
       "ssn",
       "id-"
     ]
   }

Étape 2 : Exécuter des événements de lecture et d'écriture

1. Accédez à OpenSearch Tableaux de bord, choisissez Outils de développement et indexez un exemple de document :

   PUT accounts/_doc/0
   {
     "ssn": "123",
     "id-": "456"
   }

2. Pour tester un événement de lecture, envoyez la demande suivante :

   GET accounts/_search
   {
     "query": {
       "match_all": {}
     }
   }

Étape 3 : Observer les journaux

1. Ouvrez la CloudWatch console à l'adresse https://console.aws.amazon.com/cloudwatch/.

2. Dans le panneau de navigation, choisissez Groupes de journaux.

3. Choisissez le groupe de journaux que vous avez spécifié lors de l'activation des journaux d'audit. Au sein du groupe de journaux, OpenSearch Service crée un flux de journal pour chaque nœud de votre domaine.

4. Dans Flux de journaux, choisissez Rechercher partout.

5. Pour les événements de lecture et d'écriture, consultez les journaux correspondants. Cinq secondes peuvent s'écouler avant l'apparition du journal.

   Exemple de journal d'audit d'écriture

   {
     "audit_compliance_operation": "CREATE",
     "audit_cluster_name": "824471164578:audit-test",
     "audit_node_name": "be217225a0b77c2bd76147d3ed3ff83c",
     "audit_category": "COMPLIANCE_DOC_WRITE",
     "audit_request_origin": "REST",
     "audit_compliance_doc_version": 1,
     "audit_node_id": "3xNJhm4XS_yTzEgDWcGRjA",
     "@timestamp": "2020-08-23T05:28:02.285+00:00",
     "audit_format_version": 4,
     "audit_request_remote_address": "3.236.145.227",
     "audit_trace_doc_id": "lxnJGXQBqZSlDB91r_uZ",
     "audit_request_effective_user": "admin",
     "audit_trace_shard_id": 8,
     "audit_trace_indices": [
       "accounts"
     ],
     "audit_trace_resolved_indices": [
       "accounts"
     ]
   }

   Exemple de journal d'audit de lecture

   {
     "audit_cluster_name": "824471164578:audit-docs",
     "audit_node_name": "806f6050cb45437e2401b07534a1452f",
     "audit_category": "COMPLIANCE_DOC_READ",
     "audit_request_origin": "REST",
     "audit_node_id": "saSevm9ASte0-pjAtYi2UA",
     "@timestamp": "2020-08-31T17:57:05.015+00:00",
     "audit_format_version": 4,
     "audit_request_remote_address": "54.240.197.228",
     "audit_trace_doc_id": "config:7.7.0",
     "audit_request_effective_user": "admin",
     "audit_trace_shard_id": 0,
     "audit_trace_indices": [
       "accounts"
     ],
     "audit_trace_resolved_indices": [
       "accounts"
     ]
   }

Pour inclure le corps de la demande, revenez aux paramètres de conformité dans les OpenSearch tableaux de bord et désactivez Écrire les métadonnées. Pour exclure les événements d'un utilisateur spécifique, ajoutez-le à Utilisateurs ignorés.

Pour obtenir une description de chacun des champs de journal d'audit, consultez Guide de référence des champs de journal d'audit. Pour plus d'informations sur la recherche et l'analyse des données de vos journaux d'audit, consultez Analyzing Log Data with CloudWatch Logs Insights dans le guide de l'utilisateur Amazon CloudWatch Logs.

Configuration des journaux d'audit à l'aide de l'API REST

Nous vous recommandons d'utiliser OpenSearch des tableaux de bord pour configurer les journaux d'audit, mais vous pouvez également utiliser l'API REST de contrôle d'accès précise. Cette section contient un exemple de requête. La documentation complète sur l'API REST est disponible dans la OpenSearchdocumentation.

PUT _opendistro/_security/api/audit/config
{
  "enabled": true,
  "audit": {
    "enable_rest": true,
    "disabled_rest_categories": [
      "GRANTED_PRIVILEGES",
      "AUTHENTICATED"
    ],
    "enable_transport": true,
    "disabled_transport_categories": [
      "GRANTED_PRIVILEGES",
      "AUTHENTICATED"
    ],
    "resolve_bulk_requests": true,
    "log_request_body": true,
    "resolve_indices": true,
    "exclude_sensitive_headers": true,
    "ignore_users": [
      "kibanaserver"
    ],
    "ignore_requests": [
      "SearchRequest",
      "indices:data/read/*",
      "/_cluster/health"
    ]
  },
  "compliance": {
    "enabled": true,
    "internal_config": true,
    "external_config": false,
    "read_metadata_only": true,
    "read_watched_fields": {
      "read-index-1": [
        "field-1",
        "field-2"
      ],
      "read-index-2": [
        "field-3"
      ]
    },
    "read_ignore_users": [
      "read-ignore-1"
    ],
    "write_metadata_only": true,
    "write_log_diffs": false,
    "write_watched_indices": [
      "write-index-1",
      "write-index-2",
      "log-*",
      "*"
    ],
    "write_ignore_users": [
      "write-ignore-1"
    ]
  }
}