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.
Security Hub pour Elasticsearch
Ces AWS Security Hub contrôles évaluent le service et les ressources Elasticsearch.
Il est possible que ces commandes ne soient pas toutes disponibles Régions AWS. Pour de plus amples informations, veuillez consulter Disponibilité des contrôles par région.
[ES.1] Le chiffrement au repos doit être activé sur les domaines Elasticsearch
Exigences associées : PCI DSS v3.2.1/3.4, NIST.800-53.r5 CA-9 (1), NIST.800-53.r5 CM-3(6), NIST.800-53.r5 SC-1 3, 8, NIST.800-53.r5 SC-2 8 (1), (10), NIST .800-53.r5 NIST.800-53.r5 SC-2 SI-7 NIST.800-53.r5 SC-7 (6)
Catégorie : Protéger > Protection des données > Chiffrement de data-at-rest
Gravité : Moyenne
Type de ressource : AWS::Elasticsearch::Domain
Règle AWS Config : elasticsearch-encrypted-at-rest
Type de calendrier : Périodique
Paramètres : Aucun
Ce contrôle vérifie si la configuration du chiffrement au repos est activée dans les domaines Elasticsearch. La vérification échoue si le chiffrement au repos n'est pas activé.
Pour renforcer la sécurité de vos données sensibles OpenSearch, vous devez les configurer pour qu'elles soient chiffrées au repos. OpenSearch Les domaines Elasticsearch permettent de chiffrer les données au repos. Cette fonctionnalité permet AWS KMS de stocker et de gérer vos clés de chiffrement. Pour effectuer le chiffrement, il utilise l'algorithme Advanced Encryption Standard avec des clés de 256 bits (AES-256).
Pour en savoir plus sur le OpenSearch chiffrement au repos, consultez la section Chiffrement des données au repos pour Amazon OpenSearch Service dans le manuel Amazon OpenSearch Service Developer Guide.
Certains types d'instances, tels que t.small
ett.medium
, ne prennent pas en charge le chiffrement des données au repos. Pour plus de détails, consultez la section Types d'instances pris en charge dans le manuel Amazon OpenSearch Service Developer Guide.
Correction
Pour activer le chiffrement au repos pour les domaines Elasticsearch nouveaux et existants, consultez la section Activation du chiffrement des données au repos dans le manuel Amazon OpenSearch Service Developer Guide.
[ES.2] Les domaines Elasticsearch ne doivent pas être accessibles au public
Exigences connexes : PCI DSS v3.2.1/1.2.1, PCI DSS v3.2.1/1.3.1, PCI DSS v3.2.1/1.3.2, PCI DSS v3.2.1/1.3.4, PCI DSS v3.2.1/1.3.6, NIST.800-53.r5 AC-2 1, NIST.800-53.r5 AC-3 (7), (21),,,, (11), (16) NIST.800-53.r5 AC-3, (20), (21) NIST.800-53.r5 AC-4, NIST.800-53.r5 AC-4 (3), (4) NIST.800-53.r5 AC-6 NIST.800-53.r5 SC-7, NIST.800-53.r5 SC-7 (9) NIST.800-53.r5 SC-7 NIST.800-53.r5 SC-7 NIST.800-53.r5 SC-7 NIST.800-53.r5 SC-7 NIST.800-53.r5 SC-7 NIST.800-53.r5 SC-7
Catégorie : Protection > Configuration réseau sécurisée > Ressources contenues dans VPC
Gravité : Critique
Type de ressource : AWS::Elasticsearch::Domain
Règle AWS Config : elasticsearch-in-vpc-only
Type de calendrier : Périodique
Paramètres : Aucun
Ce contrôle vérifie si les domaines Elasticsearch se trouvent dans un. VPC Il n'évalue pas la configuration de routage du VPC sous-réseau pour déterminer l'accès public. Vous devez vous assurer que les domaines Elasticsearch ne sont pas attachés à des sous-réseaux publics. Consultez les politiques basées sur les ressources dans le manuel Amazon OpenSearch Service Developer Guide. Vous devez également vous assurer que votre configuration VPC est conforme aux meilleures pratiques recommandées. Consultez les meilleures pratiques de sécurité pour vous VPC dans le guide de VPC l'utilisateur Amazon.
Les domaines Elasticsearch déployés au sein d'un même réseau VPC peuvent communiquer avec les VPC ressources via le AWS réseau privé, sans qu'il soit nécessaire de passer par l'Internet public. Cette configuration augmente le niveau de sécurité en limitant l'accès aux données en transit. VPCsfournissent un certain nombre de contrôles réseau pour sécuriser l'accès aux domaines Elasticsearch, notamment aux groupes de réseau ACL et de sécurité. Security Hub vous recommande de migrer les domaines Elasticsearch publics VPCs pour tirer parti de ces contrôles.
Correction
Si vous créez un domaine avec un point de terminaison public, vous ne pouvez pas le placer ultérieurement dans unVPC. Au lieu de cela, vous devez créer un nouveau domaine et migrer vos données. L’inverse est également vrai. Si vous créez un domaine au sein d'unVPC, il ne peut pas avoir de point de terminaison public. Au lieu de cela, vous devez créer un autre domaine ou désactiver ce contrôle.
Consultez la section Lancement de vos domaines Amazon OpenSearch Service au sein d'un VPC dans le manuel Amazon OpenSearch Service Developer Guide.
[ES.3] Les domaines Elasticsearch doivent chiffrer les données envoyées entre les nœuds
Exigences connexes : NIST.800-53.r5 AC-4, NIST.800-53.r5 SC-1 3, NIST.800-53.r5 SC-2 NIST.800-53.r5 SC-2 3 (3), NIST.800-53.r5 SC-7 (4) NIST.800-53.r5 SC-8, NIST.800-53.r5 SC-8 (1), NIST.800-53.r5 SC-8 (2)
Catégorie : Protéger > Protection des données > Chiffrement de data-in-transit
Gravité : Moyenne
Type de ressource : AWS::Elasticsearch::Domain
Règle AWS Config : elasticsearch-node-to-node-encryption-check
Type de calendrier : changement déclenché
Paramètres : Aucun
Ce contrôle vérifie si le node-to-node chiffrement est activé dans un domaine Elasticsearch. Le contrôle échoue si le node-to-node chiffrement n'est pas activé dans le domaine Elasticsearch. Le contrôle produit également des résultats erronés si une version d'Elasticsearch ne prend pas en charge les contrôles de node-to-node chiffrement.
HTTPS(TLS) peut être utilisé pour empêcher les attaquants potentiels d'espionner ou de manipuler le trafic réseau en utilisant person-in-the-middle des attaques similaires. Seules les connexions chiffrées via HTTPS (TLS) doivent être autorisées. L'activation du node-to-node chiffrement pour les domaines Elasticsearch garantit que les communications intra-cluster sont chiffrées en transit.
Cette configuration peut entraîner une baisse des performances. Vous devez connaître le compromis entre les performances et le tester avant d'activer cette option.
Correction
Pour plus d'informations sur l'activation du node-to-node chiffrement sur les domaines nouveaux et existants, consultez la section Activation du node-to-node chiffrement dans le manuel Amazon OpenSearch Service Developer Guide.
[ES.4] La journalisation des erreurs du domaine Elasticsearch dans les CloudWatch journaux doit être activée
Exigences connexes : NIST.800-53.r5 AC-2 (4), (26), NIST.800-53.r5 AC-4 (9), NIST.800-53.r5 AC-6 (9) NIST.800-53.r5 AU-10, NIST.800-53.r5 AU-12, NIST.800-53.r5 AU-2, NIST.800-53.r5 AU-3, NIST.800-53.r5 AU-6(3), NIST.800-53.r5 AU-6(4), NIST.800-53.r5 CA-7, NIST .800-53.r5 SI-3 NIST.800-53.r5 SC-7 (8), .800-53.r5 SI-4 (20), NIST .800-53.r5 SI-7 (8) NIST
Catégorie : Identifier - Journalisation
Gravité : Moyenne
Type de ressource : AWS::Elasticsearch::Domain
Règle AWS Config : elasticsearch-logs-to-cloudwatch
Type de calendrier : changement déclenché
Paramètres :
-
logtype = 'error'
(non personnalisable)
Ce contrôle vérifie si les domaines Elasticsearch sont configurés pour envoyer des journaux d'erreurs à CloudWatch Logs.
Vous devez activer les journaux d'erreurs pour les domaines Elasticsearch et les envoyer à CloudWatch Logs pour qu'ils soient conservés et répondus. Les journaux d'erreurs de domaine peuvent faciliter les audits de sécurité et d'accès, ainsi que le diagnostic des problèmes de disponibilité.
Correction
Pour plus d'informations sur la façon d'activer la publication de journaux, consultez la section Activation de la publication de journaux (console) dans le manuel Amazon OpenSearch Service Developer Guide.
[ES.5] La journalisation des audits doit être activée dans les domaines Elasticsearch
Exigences connexes : NIST.800-53.r5 AC-2 (4), (26), NIST.800-53.r5 AC-4 (9), NIST.800-53.r5 AC-6 (9) NIST.800-53.r5 AU-10, NIST.800-53.r5 AU-12, NIST.800-53.r5 AU-2, NIST.800-53.r5 AU-3, NIST.800-53.r5 AU-6(3), NIST.800-53.r5 AU-6(4), NIST.800-53.r5 CA-7, NIST .800-53.r5 SI-3 NIST.800-53.r5 SC-7 (8), .800-53.r5 SI-4 (20), NIST .800-53.r5 SI-7 (8) NIST
Catégorie : Identifier - Journalisation
Gravité : Moyenne
Type de ressource : AWS::Elasticsearch::Domain
AWS Config règle : elasticsearch-audit-logging-enabled
(règle Security Hub personnalisée)
Type de calendrier : changement déclenché
Paramètres :
-
cloudWatchLogsLogGroupArnList
(non personnalisable). Security Hub ne renseigne pas ce paramètre. Liste séparée par des CloudWatch virgules des groupes de journaux qui doivent être configurés pour les journaux d'audit.Cette règle s'applique
NON_COMPLIANT
si le groupe de CloudWatch journaux du domaine Elasticsearch n'est pas spécifié dans cette liste de paramètres.
Ce contrôle vérifie si la journalisation des audits est activée dans les domaines Elasticsearch. Ce contrôle échoue si la journalisation des audits n'est pas activée dans un domaine Elasticsearch.
Les journaux d'audit sont hautement personnalisables. Ils vous permettent de suivre l'activité des utilisateurs sur vos clusters Elasticsearch, notamment les réussites et les échecs d'authentification, les demandes, les modifications d' OpenSearchindex et les requêtes de recherche entrantes.
Correction
Pour obtenir des instructions détaillées sur l'activation des journaux d'audit, consultez la section Activation des journaux d'audit dans le manuel Amazon OpenSearch Service Developer Guide.
[ES.6] Les domaines Elasticsearch doivent comporter au moins trois nœuds de données
Exigences connexes : NIST.800-53.r5 CP-10, NIST.800-53.r5 CP-6(2), NIST.800-53.r5 SC-3 6, NIST.800-53.r5 SC-5 (2), NIST .800-53.r5 SI-13 (5)
Catégorie : Restauration > Résilience > Haute disponibilité
Gravité : Moyenne
Type de ressource : AWS::Elasticsearch::Domain
AWS Config règle : elasticsearch-data-node-fault-tolerance
(règle Security Hub personnalisée)
Type de calendrier : changement déclenché
Paramètres : Aucun
Ce contrôle vérifie si les domaines Elasticsearch sont configurés avec au moins trois nœuds de données et zoneAwarenessEnabled
s'ils le sont. true
Un domaine Elasticsearch nécessite au moins trois nœuds de données pour garantir une haute disponibilité et une tolérance aux pannes. Le déploiement d'un domaine Elasticsearch avec au moins trois nœuds de données garantit les opérations du cluster en cas de défaillance d'un nœud.
Correction
Pour modifier le nombre de nœuds de données dans un domaine Elasticsearch
Ouvrez la console Amazon OpenSearch Service à l'adresse https://console.aws.amazon.com/aos/
. -
Sous Domaines, choisissez le nom du domaine que vous souhaitez modifier.
-
Choisissez Edit domain (Modifier le domaine).
-
Sous Nœuds de données, définissez Nombre de nœuds sur un nombre supérieur ou égal à
3
.Pour trois déploiements de zones de disponibilité, définissez un multiple de trois pour garantir une distribution égale entre les zones de disponibilité.
-
Sélectionnez Envoyer.
[ES.7] Les domaines Elasticsearch doivent être configurés avec au moins trois nœuds maîtres dédiés
Exigences connexes : NIST.800-53.r5 CP-10, NIST.800-53.r5 CP-6(2), NIST.800-53.r5 SC-3 6, NIST.800-53.r5 SC-5 (2), NIST .800-53.r5 SI-13 (5)
Catégorie : Restauration > Résilience > Haute disponibilité
Gravité : Moyenne
Type de ressource : AWS::Elasticsearch::Domain
AWS Config règle : elasticsearch-primary-node-fault-tolerance
(règle Security Hub personnalisée)
Type de calendrier : changement déclenché
Paramètres : Aucun
Ce contrôle vérifie si les domaines Elasticsearch sont configurés avec au moins trois nœuds principaux dédiés. Ce contrôle échoue si le domaine n'utilise pas de nœuds principaux dédiés. Ce contrôle est effectué si les domaines Elasticsearch disposent de cinq nœuds principaux dédiés. Cependant, l'utilisation de plus de trois nœuds principaux peut s'avérer inutile pour atténuer le risque de disponibilité, ce qui entraînera des coûts supplémentaires.
Un domaine Elasticsearch nécessite au moins trois nœuds principaux dédiés pour garantir une haute disponibilité et une tolérance aux pannes. Les ressources du nœud principal dédié peuvent être mises à rude épreuve lors des déploiements de nœuds de données bleu/vert, car il existe des nœuds supplémentaires à gérer. Le déploiement d'un domaine Elasticsearch avec au moins trois nœuds principaux dédiés garantit une capacité de ressources de nœud principal suffisante et des opérations de cluster suffisantes en cas de défaillance d'un nœud.
Correction
Pour modifier le nombre de nœuds principaux dédiés dans un OpenSearch domaine
Ouvrez la console Amazon OpenSearch Service à l'adresse https://console.aws.amazon.com/aos/
. -
Sous Domaines, choisissez le nom du domaine que vous souhaitez modifier.
-
Choisissez Edit domain (Modifier le domaine).
-
Sous Nœuds maîtres dédiés, définissez le type d'instance sur le type d'instance souhaité.
-
Définissez le nombre de nœuds maîtres égal ou supérieur à trois.
-
Sélectionnez Envoyer.
[ES.8] Les connexions aux domaines Elasticsearch doivent être chiffrées conformément à la dernière politique de sécurité TLS
Exigences connexes : NIST.800-53.r5 AC-1 7 (2) NIST.800-53.r5 AC-4, NIST.800-53.r5 IA-5 (1), NIST.800-53.r5 SC-1 2 (3), 3, NIST.800-53.r5 SC-1 3, NIST.800-53.r5 SC-2 3 ( NIST.800-53.r5 SC-23), (4), NIST.800-53.r5 SC-7 (1) NIST.800-53.r5 SC-8, NIST.800-53.r5 SC-8 NIST.800-53.r5 SC-8 (2), NIST .800-53.r5 SI-7 (6)
Catégorie : Protéger > Protection des données > Chiffrement de data-in-transit
Gravité : Moyenne
Type de ressource : AWS::Elasticsearch::Domain
AWS Config règle : elasticsearch-https-required
(règle Security Hub personnalisée)
Type de calendrier : changement déclenché
Paramètres : Aucun
Cela permet de vérifier si un point de terminaison de domaine Elasticsearch est configuré pour utiliser la dernière politique TLS de sécurité. Le contrôle échoue si le point de terminaison du domaine Elasticsearch n'est pas configuré pour utiliser la dernière politique prise en charge ou s'il HTTPs n'est pas activé. La dernière politique de TLS sécurité actuellement prise en charge estPolicy-Min-TLS-1-2-PFS-2023-10
.
HTTPS(TLS) peut être utilisé pour empêcher les attaquants potentiels d'utiliser des attaques person-in-the-middle ou des attaques similaires pour espionner ou manipuler le trafic réseau. Seules les connexions chiffrées via HTTPS (TLS) doivent être autorisées. Le chiffrement des données en transit peut affecter les performances. Vous devez tester votre application avec cette fonctionnalité pour comprendre le profil de performance et l'impact deTLS. TLS1.2 apporte plusieurs améliorations de sécurité par rapport aux versions précédentes deTLS.
Correction
Pour activer TLS le chiffrement, utilisez UpdateDomainConfigAPIopération pour configurer le DomainEndpointOptionsobjet. Cela définit leTLSSecurityPolicy
.
[ES.9] Les domaines Elasticsearch doivent être balisés
Catégorie : Identifier > Inventaire > Étiquetage
Gravité : Faible
Type de ressource : AWS::Elasticsearch::Domain
AWS Config règle : tagged-elasticsearch-domain
(règle Security Hub personnalisée)
Type de calendrier : changement déclenché
Paramètres :
Paramètre | Description | Type | Valeurs personnalisées autorisées | Valeur par défaut de Security Hub |
---|---|---|---|---|
requiredTagKeys
|
Liste des clés de balise de la ressource évaluée que doit contenir la ressource évaluée. Les clés de balises sont sensibles à la casse. | StringList | Liste des tags répondant aux AWS exigences |
No default value
|
Ce contrôle vérifie si un domaine Elasticsearch possède des balises avec les clés spécifiques définies dans le paramètre. requiredTagKeys
Le contrôle échoue si le domaine ne possède aucune clé de balise ou s'il ne possède pas toutes les clés spécifiées dans le paramètrerequiredTagKeys
. Si le paramètre requiredTagKeys
n'est pas fourni, le contrôle vérifie uniquement l'existence d'une clé de balise et échoue si le domaine n'est étiqueté avec aucune clé. Les balises système, qui sont automatiquement appliquées et commencent paraws:
, sont ignorées.
Une balise est une étiquette que vous attribuez à une AWS ressource. Elle se compose d'une clé et d'une valeur facultative. Vous pouvez créer des balises pour classer vos ressources par objectif, propriétaire, environnement ou selon d'autres critères. Les balises peuvent vous aider à identifier, organiser, rechercher et filtrer les ressources. Le balisage vous permet également de suivre les propriétaires de ressources responsables en ce qui concerne les actions et les notifications. Lorsque vous utilisez le balisage, vous pouvez implémenter le contrôle d'accès basé sur les attributs (ABAC) en tant que stratégie d'autorisation, qui définit les autorisations en fonction des balises. Vous pouvez associer des balises à IAM des entités (utilisateurs ou rôles) et à AWS des ressources. Vous pouvez créer une ABAC politique unique ou un ensemble de politiques distinct pour vos IAM mandants. Vous pouvez concevoir ces ABAC politiques pour autoriser les opérations lorsque la balise du principal correspond à la balise de ressource. Pour plus d'informations, voir À quoi ça ABAC sert AWS ? dans le guide de IAM l'utilisateur.
Note
N'ajoutez pas d'informations personnellement identifiables (PII) ou d'autres informations confidentielles ou sensibles dans les balises. Les tags sont accessibles à de nombreuses personnes Services AWS, notamment AWS Billing. Pour en savoir plus sur les meilleures pratiques en matière de balisage, consultez la section Marquage de vos AWS ressources dans le. Références générales AWS
Correction
Pour ajouter des balises à un domaine Elasticsearch, consultez la section Utilisation des balises dans le manuel Amazon OpenSearch Service Developer Guide.