Suggestions en matière de sécurité réseau

Cet article répertorie toutes les recommandations de sécurité réseau que vous pouvez voir dans Microsoft Defender pour le cloud.

Les recommandations qui apparaissent dans votre environnement sont basées sur les ressources que vous protégez et sur votre configuration personnalisée. Vous pouvez voir les recommandations dans le portail qui s’appliquent à vos ressources.

Pour en savoir plus sur les actions que vous pouvez effectuer en réponse à ces recommandations, consultez Correction des recommandations dans Defender pour le cloud.

Conseil

Si une description de recommandation indique Aucune stratégie associée, cela est généralement dû au fait que cette recommandation dépend d’une autre recommandation.

Par exemple, les échecs d’intégrité Endpoint Protection doivent être corrigés en fonction de la recommandation qui vérifie si une solution endpoint protection est installée (la solution Endpoint Protection doit être installée). La recommandation sous-jacente est associée à une stratégie. La limitation des stratégies aux recommandations fondamentales simplifie la gestion des stratégies.

Recommandations en matière de mise en réseau Azure

L’accès aux comptes de stockage avec des configurations de pare-feu et de réseau virtuel doit être limité

Description : passez en revue les paramètres d’accès réseau dans les paramètres de pare-feu de votre compte de stockage. Nous avons recommandé de configurer des règles réseau de manière à ce que seules les applications des réseaux autorisés puissent accéder au compte de stockage. Pour autoriser les connexions de clients Internet ou locaux spécifiques, l’accès au trafic peut être autorisé à partir de réseaux virtuels Azure spécifiques ou vers des plages d’adresses IP Internet publiques. (Stratégie associée : Les comptes de stockage doivent restreindre l’accès réseau).

Gravité : faible

Les recommandations de renforcement de réseau adaptatif doivent être appliquées sur les machines virtuelles accessibles à partir d’Internet

Description : Defender pour le cloud a analysé les modèles de communication du trafic Internet des machines virtuelles répertoriées ci-dessous et déterminé que les règles existantes dans les NSG associées sont trop permissives, ce qui entraîne une surface d’attaque potentielle accrue. Cela se produit généralement lorsque cette adresse IP ne communique pas régulièrement avec cette ressource. Il est aussi possible que l’adresse IP ait été signalée comme malveillante par les sources de renseignement sur les menaces de Microsoft Defender pour le cloud. (Stratégie associée : Les recommandations de renforcement du réseau adaptatif doivent être appliquées sur les machines virtuelles accessibles sur Internet.

Gravité : élevée

Tous les ports réseau doivent être restreints sur les groupes de sécurité réseau associés à votre machine virtuelle

Description : Defender pour le cloud a identifié certaines des règles entrantes de vos groupes de sécurité réseau pour être trop permissives. Les règles de trafic entrant ne doivent pas autoriser l’accès à partir des plages « Tout » ou « Internet ». Cela peut permettre aux attaquants de cibler vos ressources. (Stratégie associée : Tous les ports réseau doivent être restreints sur les groupes de sécurité réseau associés à votre machine virtuelle.

Gravité : élevée

Azure DDoS Protection Standard doit être activé

Description : Defender pour le cloud a découvert des réseaux virtuels avec des ressources Application Gateway non protégées par le service de protection DDoS. Ces ressources contiennent des IP publiques. Activez l’atténuation des risques pour les attaques volumétriques et les attaques par protocole réseau. (Stratégie associée : Azure DDoS Protection Standard doit être activé).

Gravité : moyenne

Les machines virtuelles accessibles à partir d’Internet doivent être protégées avec des groupes de sécurité réseau

Description : Protégez votre machine virtuelle contre les menaces potentielles en limitant l’accès à celui-ci avec un groupe de sécurité réseau (NSG). Les groupes NSG contiennent des règles de liste de contrôle d’accès (ACL) qui autorisent ou rejettent le trafic réseau vers votre machine virtuelle à partir d’autres instances, qu’elles appartiennent ou non au même sous-réseau. Pour que votre machine soit aussi sécurisée que possible, vous devez restreindre l’accès des machines virtuelles à Internet et activer un groupe de sécurité réseau dans le sous-réseau. Les machines virtuelles accessibles via Internet sont associées à un niveau de gravité « Élevé ». (Stratégie associée : Les machines virtuelles accessibles sur Internet doivent être protégées avec des groupes de sécurité réseau.

Gravité : élevée

Le transfert IP doit être désactivé sur votre machine virtuelle

Description : Defender pour le cloud a découvert que le transfert IP est activé sur certaines de vos machines virtuelles. L’activation du transfert IP sur la carte réseau d’une machine virtuelle permet à cette dernière de recevoir du trafic adressé à d’autres destinations. Le transfert IP n'est que rarement nécessaire (par exemple, lors de l'utilisation de la machine virtuelle en tant qu'appliance virtuelle de réseau). Par conséquent, un examen par l'équipe de sécurité réseau est requis. (Stratégie associée : Le transfert IP sur votre machine virtuelle doit être désactivé).

Gravité : moyenne

Les ordinateurs doivent avoir des ports fermés susceptibles d’exposer des vecteurs d’attaque

Description : les conditions d’utilisation d’Azure interdisent l’utilisation de services Azure de manière à endommager, désactiver, surcharger ou endommager n’importe quel serveur Microsoft ou le réseau. Cette recommandation énumère les ports exposés qui doivent être fermés pour le maintien de votre sécurité. Elle illustre également la menace potentielle pour chaque port. (Aucune stratégie associée)

Gravité : élevée

Les ports de gestion des machines virtuelles doivent être protégés par un contrôle d’accès réseau juste-à-temps

Description : Defender pour le cloud a identifié certaines règles entrantes trop permissives pour les ports de gestion dans votre groupe de sécurité réseau. Activez le contrôle d’accès juste-à-temps pour protéger votre machine virtuelle contre les attaques en force brute provenant d’Internet. Pour en savoir plus, consultez Fonctionnement de l’accès aux machines virtuelles juste-à-temps (JAT). (Stratégie associée : Les ports de gestion des machines virtuelles doivent être protégés par le contrôle d’accès réseau juste-à-temps).

Gravité : élevée

Les ports de gestion doivent être fermés sur vos machines virtuelles

Description : Les ports de gestion à distance ouverts exposent votre machine virtuelle à un niveau élevé de risque des attaques basées sur Internet. Ces attaques tentent d’attaquer par force brute les informations d’identification afin d’obtenir un accès administrateur à l’ordinateur. (Stratégie associée : Les ports de gestion doivent être fermés sur vos machines virtuelles.

Gravité : moyenne

Les machines virtuelles non connectées à Internet doivent être protégées avec des groupes de sécurité réseau

Description : Protégez votre machine virtuelle non accessible sur Internet contre les menaces potentielles en limitant l’accès à celui-ci avec un groupe de sécurité réseau (NSG). Les groupes NSG contiennent des règles de liste de contrôle d’accès (ACL) qui autorisent ou rejettent le trafic réseau vers votre machine virtuelle à partir d’autres instances, qu’elles appartiennent ou non au même sous-réseau. Pour que votre machine soit aussi sécurisée que possible, vous devez restreindre l’accès de la machine virtuelle à Internet et activer un groupe de sécurité réseau sur le sous-réseau. (Stratégie associée : Les machines virtuelles non accessibles sur Internet doivent être protégées avec des groupes de sécurité réseau).

Gravité : faible

La sécurisation du transfert vers des comptes de stockage doit être activée

Description : Le transfert sécurisé est une option qui force votre compte de stockage à accepter les demandes uniquement à partir de connexions sécurisées (HTTPS). L'utilisation de HTTPS garantit l'authentification entre le serveur et le service et protège les données en transit contre les attaques de la couche réseau (attaque de l'intercepteur ou « man-in-the-middle », écoute clandestine, détournement de session). (Stratégie associée : Le transfert sécurisé vers les comptes de stockage doit être activé.

Gravité : élevée

(Activer si nécessaire) Les sous-réseaux doivent être associés à un groupe de sécurité réseau

Description : Protégez votre sous-réseau contre les menaces potentielles en limitant l’accès à celui-ci avec un groupe de sécurité réseau (NSG). Les NSG contiennent une liste de règles de liste de contrôle d’accès (ACL) qui autorisent ou refusent le trafic réseau vers votre sous-réseau. Lorsqu’un groupe de sécurité réseau est associé à un sous-réseau, les règles ACL s’appliquent à toutes les instances de machines virtuelles et à tous les services intégrés de ce sous-réseau, mais elles ne s’appliquent pas au trafic interne au sous-réseau. Pour sécuriser les ressources d’un même sous-réseau les unes par rapport aux autres, activez le groupe de sécurité réseau directement sur les ressources. Notez que les types de sous-réseaux suivants seront indiqués comme non applicables : GatewaySubnet, AzureFirewallSubnet, AzureBastionSubnet.

Pour activer cette recommandation, accédez à votre stratégie de sécurité pour l’étendue applicable et mettez à jour le paramètre Effect de la stratégie correspondante à auditer. Pour en savoir plus, consultez Gérer les stratégies de sécurité. (Stratégie associée : Les sous-réseaux doivent être associés à un groupe de sécurité réseau).

Gravité : faible

Les réseaux virtuels doivent être protégés par le pare-feu Azure

Description : Certains de vos réseaux virtuels ne sont pas protégés par un pare-feu. Utilisez Pare-feu Azure pour restreindre l’accès à vos réseaux virtuels et empêcher les menaces potentielles. (Stratégie associée : Tout le trafic Internet doit être routé via votre Pare-feu Azure déployé).

Recommandations de mise en réseau AWS

La défense active contre les menaces doit être activée sur aws Network Firewall

Description : Defender pour Cloud a identifié que la défense active contre les menaces n’est pas activée dans AWS Network Firewall. La défense active contre les menaces surveille en permanence le trafic réseau pour détecter les modèles suspects et les menaces potentielles. Sans cela, votre réseau peut être exposé à des attaques avancées qui contournent les mesures de sécurité standard, ce qui augmente le risque d’une violation de données ou d’autres activités malveillantes.

Gravité : moyenne

Les cibles d’alias doivent être configurées pour les enregistrements Hostedzone A Route53

Description : Defender pour Cloud a identifié un enregistrement Route 53 A qui n’utilise pas de cible d’alias. Les enregistrements Route 53 A doivent utiliser des cibles d’alias pour les attacher directement aux ressources managées AWS en référençant les noms de ressources AWS. L’utilisation d’adresses IP statiques dans les enregistrements A peut entraîner des entrées DNS obsolètes, une mauvaise circulation du trafic, une disponibilité réduite et un risque de sécurité accru lorsque les points de terminaison de ressources AWS sous-jacents changent.

Gravité : moyenne

Amazon EC2 doit être configuré pour utiliser des points de terminaison de VPC

Description : ce contrôle vérifie si un point de terminaison de service pour Amazon EC2 est créé pour chaque VPC. Le contrôle échoue si un VPC n’a pas de point de terminaison VPC créé pour le service Amazon EC2. Pour améliorer la posture de sécurité de votre VPC, vous pouvez configurer Amazon EC2 pour utiliser un point de terminaison de VPC d’interface. Les points de terminaison d’interface sont alimentés par AWS PrivateLink, une technologie qui vous permet d’accéder aux opérations de l’API Amazon EC2 de manière privée. Elle limite tout le trafic entre votre VPC et Amazon EC2 au réseau Amazon. Étant donné que les points de terminaison sont pris en charge uniquement dans la même région, vous ne pouvez pas créer de point de terminaison entre un VPC et un service dans une autre région. Cela permet d’éviter les appels involontaires de l’API Amazon EC2 vers d’autres régions. Pour en savoir plus sur la création de points de terminaison de VPC pour Amazon EC2, consultez Amazon EC2 et points de terminaison d’un VPC d’interface dans le guide de l’utilisateur d’Amazon EC2 pour les instances Linux.

Gravité : moyenne

Les services Amazon ECS ne doivent pas avoir d’IP publiques attribuées automatiquement

Description : une adresse IP publique est une adresse IP accessible à partir d’Internet. Si vous lancez vos instances Amazon ECS avec une IP publique, vos instances Amazon ECS sont accessibles depuis l’Internet. Les services Amazon ECS ne doivent pas être accessibles publiquement, car cela peut autoriser l’accès involontaire à vos serveurs d’applications conteneur.

Gravité : élevée

Les nœuds principaux de cluster Amazon EMR ne doivent pas avoir d’IP publiques

Description : ce contrôle vérifie si les nœuds principaux sur les clusters Amazon EMR ont des adresses IP publiques. Le contrôle échoue si le nœud principal a des IP publiques qui sont associées à l’une de ses instances. Les IP publiques sont désignées dans le champ PublicIp de la configuration NetworkInterfaces de l’instance. Ce contrôle vérifie uniquement les clusters Amazon EMR qui sont dans un état RUNNING ou WAITING.

Gravité : élevée

Les clusters Amazon Redshift doivent utiliser un routage VPC amélioré

Description : ce contrôle vérifie si un cluster Amazon Redshift est activé avec EnhancedVpcRouting. Le routage VPC amélioré oblige tout le trafic COPY et UNLOAD entre le cluster et les référentiels de données à passer par votre VPC. Vous pouvez ensuite utiliser des fonctionnalités VPC, telles que des groupes de sécurité et des listes de contrôle d’accès réseau, pour sécuriser le trafic. Vous pouvez également utiliser les journaux de flux VPC pour surveiller le trafic.

Gravité : élevée

Application Load Balancer doit être configuré pour rediriger toutes les requêtes HTTP vers HTTPS

Description : Pour appliquer le chiffrement en transit, vous devez utiliser des actions de redirection avec des équilibreurs de charge d’application pour rediriger les requêtes HTTP clientes vers une requête HTTPS sur le port 443.

Gravité : moyenne

Les Application Load Balancers doivent être configurés pour supprimer les en-têtes HTTP

Description : ce contrôle évalue les équilibreurs de charge d’application AWS (ALB) pour s’assurer qu’ils sont configurés pour supprimer les en-têtes HTTP non valides. Le contrôle échoue si la valeur de routing.http.drop_invalid_header_fields.enabled est définie sur false. Par défaut, les alb ne sont pas configurés pour supprimer les valeurs d’en-tête HTTP non valides. La suppression de ces valeurs d’en-tête empêche les attaques par désynchronisation HTTP.

Gravité : moyenne

L’acceptation automatique des pièces jointes partagées doit être désactivée pour les passerelles AWS Transit

Description : Defender pour Cloud a identifié que votre passerelle AWS Transit Gateway approuve automatiquement les pièces jointes VPC partagées. Cela pose un risque en autorisant potentiellement des connexions inter-comptes ou inter-COMPTES non autorisés, ce qui augmente les chances de déplacement latéral et d’exposition des réseaux internes. Corrigez ce risque en désactivant le partage entre comptes.

Gravité : moyenne

Générer le chiffrement d’artefact à l’aide de clés gérées par le client doit être configuré sur CodePipeline

Description : Defender pour Cloud a identifié que CodePipeline n’utilise pas de clé AWS KMS gérée par le client pour chiffrer les artefacts de build. Dans CodePipeline, une clé gérée par le client permet un contrôle granulaire sur le chiffrement, la rotation des clés et les autorisations d’accès. Cela pose un risque pour la confidentialité et l’intégrité de vos artefacts stockés, ce qui peut entraîner une compromission d’accès et de données non autorisés.

Gravité : faible

Configurer des fonctions Lambda sur un VPC

Description : ce contrôle vérifie si une fonction Lambda se trouve dans un VPC. Elle n’évalue pas la configuration de routage du sous-réseau DU VPC pour déterminer l’accessibilité publique. Notez que si Lambda@Edge est trouvé dans le compte, ce contrôle génère des résultats d’échec. Pour éviter ces résultats, vous pouvez désactiver ce contrôle.

Gravité : faible

Les instances EC2 ne doivent pas avoir d’IP publique

Description : ce contrôle vérifie si les instances EC2 ont une adresse IP publique. Le contrôle échoue si le champ « publicIp » est présent dans l’élément de configuration de l’instance EC2. Ce contrôle s’applique uniquement aux adresses IPv4. Une adresse IPv4 publique est une adresse IP accessible à partir d’Internet. Si vous lancez votre instance avec une IP publique, votre instance EC2 est accessible à partir d’Internet. Une adresse IPv4 privée est une adresse IP qui n’est pas accessible à partir d’Internet. Vous pouvez utiliser des adresses IPv4 privées pour la communication entre des instances EC2 dans le même VPC ou dans votre réseau privé connecté. Les adresses IPv6 sont uniques au monde, et sont donc accessibles depuis l’internet. Toutefois, par défaut, tous les sous-réseaux ont l’attribut d’adressage IPv6 défini sur false. Pour plus d’informations sur IPv6, consultez Adressage IP dans votre VPC dans le guide de l’utilisateur d’Amazon VPC. Si vous avez un cas d’usage légitime pour conserver des instances EC2 avec des IP publiques, vous pouvez supprimer les résultats de ce contrôle. Pour plus d’informations sur les options d’architecture frontale, consultez le blog sur l’architecture AWS ou la série This Is My Architecture.

Gravité : élevée

Les instances EC2 ne doivent pas utiliser plusieurs ENI

Description : ce contrôle vérifie si une instance EC2 utilise plusieurs interfaces réseau élastiques (ENIs) ou des adaptateurs d’infrastructure élastique (EFA). Ce contrôle passe si une seule carte réseau est utilisée. Le contrôle comprend une liste de paramètres facultatifs permettant d’identifier les ENI autorisées. Les ENI multiples peuvent provoquer des instances à double hébergement, c’est-à-dire des instances qui ont plusieurs sous-réseaux. Cela peut rendre la sécurité du réseau plus complexe et introduire des chemins et des accès réseau involontaires.

Gravité : faible

Les instances EC2 doivent utiliser IMDSv2

Description : ce contrôle vérifie si votre version de métadonnées d’instance EC2 est configurée avec instance Metadata Service Version 2 (IMDSv2). Le contrôle réussit si « HttpTokens » est défini sur « required » pour IMDSv2. Le contrôle échoue si « HttpTokens » est défini sur « optional ». Vous utilisez les métadonnées d’instance pour configurer ou gérer l’instance en cours d’exécution. L’IMDS donne accès à des informations d’identification temporaires et faisant l’objet d’une rotation fréquente. Ces informations d’identification suppriment la nécessité de coder en dur ou de distribuer manuellement ou par programme des informations d’identification sensibles aux instances. L’IMDS est attaché localement à chaque instance EC2. Il s’exécute sur une adresse IP spéciale « lien local » de 169.254.169.254. Cette adresse IP est accessible uniquement par les logiciels qui s’exécutent sur l’instance. La version 2 de l’IMDS ajoute de nouvelles protections contre les types de vulnérabilités suivants. Ces vulnérabilités peuvent être utilisées pour tenter d’accéder à l’IMDS.

• Ouvrir des pare-feu d’applications de site web
• Ouvrir des proxys inverses
• Vulnérabilités de falsification de requête côté serveur (SSRF)
• Open Layer 3 firewalls and network address translation (NAT) Security Hub recommande de configurer vos instances EC2 avec IMDSv2.

Gravité : élevée

Les sous-réseaux EC2 ne doivent pas attribuer automatiquement des IP publiques

Description : Ce contrôle vérifie si l’attribution d’adresses IP publiques dans les sous-réseaux Amazon Virtual Private Cloud (Amazon VPC) a la valeur « MapPublicIpOnLaunch » définie sur « FALSE ». Le contrôle réussit si l’indicateur est défini sur « FALSE ». Tous les sous-réseaux ont un attribut qui détermine si une interface réseau créée dans le sous-réseau reçoit automatiquement une adresse IPv4 publique. Les instances qui sont lancées dans des sous-réseaux pour lesquels cet attribut est activé ont une IP publique affectée à leur interface réseau principale.

Gravité : moyenne

L’association de table de routage par défaut doit être désactivée sur les passerelles AWS Transit

Description : Defender pour Cloud a identifié AWS Transit Gateway avec l’association de table de routage par défaut activée. L’activation de ce paramètre signifie que toute connexion DE VPN, VPN ou peering nouvellement attachée est automatiquement mappée à la table de routage de la passerelle de transit principale. Cela pose un risque de mouvement latéral involontaire, de propagation d’itinéraires non autorisés et d’exposition des réseaux internes.

Gravité : faible

La propagation de table de routage par défaut doit être désactivée sur les passerelles AWS Transit

Description : Defender pour Cloud a identifié AWS Transit Gateway avec propagation de table de routage par défaut activée. L’activation de cette fonctionnalité signifie que n’importe quelle pièce jointe VPN, VPN ou appairage peut propager automatiquement des itinéraires vers la table de routage principale de la passerelle de transit, ce qui autorise potentiellement des chemins d’accès de routage non autorisés.

Gravité : faible

La protection contre la suppression doit être activée pour AWS Network Firewall

Description : Defender pour Cloud a identifié que la protection de suppression n’est pas activée pour votre pare-feu réseau AWS. La protection contre la suppression est une protection qui empêche la suppression accidentelle ou non autorisée du pare-feu lorsqu’il est utilisé. Sans ce contrôle, une suppression par inadvertance peut entraîner des lacunes dans la détection des menaces réseau et entraîner une non-conformité avec les stratégies de sécurité, ce qui augmente votre exposition aux risques potentiels.

Gravité : moyenne

La signature DNSSEC doit être activée sur les zones hébergées route 53 publiques

Description : Defender pour Cloud a identifié les zones hébergées DNS publiques sans la signature DNSSEC activée. DNSSEC est un ensemble de protocoles qui utilisent des techniques de chiffrement pour valider les réponses DNS. Sans DNSSEC, vos domaines publics sont vulnérables à l’usurpation DNS, à l’empoisonnement du cache et à la falsification d’enregistrements non autorisées, ce qui augmente le risque de mauvaise direction du client et de compromettre l’intégrité des données.

Gravité : moyenne

La prise en charge ECMP doit être activée sur AWS Transit Gateway

Description : Defender pour Cloud a identifié que la prise en charge ECMP est désactivée sur votre passerelle AWS Transit. ECMP (Equal Cost Multi Path) permet à plusieurs tunnels VPN ou chemins BGP d’être utilisés simultanément, fournissant un débit amélioré, une redondance et une stabilité de basculement. Sans ECMP, le routage serait limité à un seul chemin actif, ce qui risquerait de réduire la résilience et les performances dans la gestion du trafic.

Gravité : faible

Garantir l’existence d’une alarme et d’un filtre de métrique de journal pour les changements de configuration d’AWS Config

Description : La surveillance en temps réel des appels d’API peut être effectuée en dirigeant les journaux CloudTrail vers les journaux CloudWatch et en établissant des filtres de métriques et des alarmes correspondants. Il est recommandé d’établir un filtre de métrique et une alarme pour détecter les modifications apportées aux configurations de CloudTrail. La surveillance des modifications apportées à la configuration AWS Config permet de garantir une visibilité soutenue des éléments de configuration dans le compte AWS.

Gravité : faible

Garantir l’existence d’une alarme et d’un filtre de métrique de journal pour les échecs d’authentification d’AWS Management Console

Description : La surveillance en temps réel des appels d’API peut être effectuée en dirigeant les journaux CloudTrail vers les journaux CloudWatch et en établissant des filtres de métriques et des alarmes correspondants. Il est recommandé d’établir un filtre de métrique et une alarme pour les tentatives d’authentification de console ayant échoué. La surveillance des connexions de console ayant échoué peut réduire le délai de détection d’une tentative de force brute d’informations d’identification, ce qui peut fournir un indicateur, tel que l’adresse IP source, qui peut être utilisé dans d’autres corrélations d’événements.

Gravité : faible

Vérifier l’existence d’une alarme et d’un filtre de métrique de journal pour les changements des listes de contrôle d’accès réseau (NACL)

Description : La surveillance en temps réel des appels d’API peut être effectuée en dirigeant les journaux CloudTrail vers les journaux CloudWatch et en établissant des filtres de métriques et des alarmes correspondants. Les NACL sont utilisées comme un filtre de paquets sans état pour contrôler le trafic d’entrée et de sortie pour les sous-réseaux au sein d’un VPC. Il est recommandé d’établir un filtre de métrique et une alarme pour les modifications apportées aux NACL. La surveillance des modifications apportées aux listes de contrôle d’accès réseau permet de s’assurer que les ressources et services AWS ne sont pas exposés involontairement.

Gravité : faible

Garantir l’existence d’une alarme et d’un filtre de métrique de journal pour les modifications apportées aux passerelles réseau

Description : La surveillance en temps réel des appels d’API peut être effectuée en dirigeant les journaux CloudTrail vers les journaux CloudWatch et en établissant des filtres de métriques et des alarmes correspondants. Les passerelles réseau sont nécessaires pour envoyer/recevoir le trafic vers une destination en dehors d’un VPC. Il est recommandé d’établir un filtre de métrique et une alarme pour les modifications apportées aux passerelles réseau. La surveillance des modifications apportées aux passerelles réseau permet de s’assurer que tout le trafic d’entrée/sortie traverse la frontière DU VPC via un chemin contrôlé.

Gravité : faible

Garantir l’existence d’une alarme et d’un filtre de métrique de journal pour les modifications de la configuration de CloudTrail

Description : La surveillance en temps réel des appels d’API peut être effectuée en dirigeant les journaux CloudTrail vers les journaux CloudWatch et en établissant des filtres de métriques et des alarmes correspondants. Il est recommandé d’établir un filtre de métrique et une alarme pour détecter les modifications apportées aux configurations de CloudTrail.

La surveillance des modifications apportées à la configuration de CloudTrail permet de garantir une visibilité soutenue des activités effectuées dans le compte AWS.

Gravité : faible

Garantir l’existence d’une alarme et d’un filtre de métrique de journal pour la désactivation ou la suppression planifiée des CMK créées par le client

Description : La surveillance en temps réel des appels d’API peut être effectuée en dirigeant les journaux CloudTrail vers les journaux CloudWatch et en établissant des filtres de métriques et des alarmes correspondants. Il est recommandé d’établir un filtre de métrique et une alarme pour les clés CMK créées par le client, qui ont changé d’état en suppression désactivée ou planifiée. Les données chiffrées avec des clés désactivées ou supprimées ne seront plus accessibles.

Gravité : faible

Garantir l’existence d’une alarme et d’un filtre de métrique de journal pour les modifications de stratégie IAM

Description : La surveillance en temps réel des appels d’API peut être effectuée en dirigeant les journaux CloudTrail vers les journaux CloudWatch et en établissant des filtres de métriques et des alarmes correspondants. Il est recommandé d’établir des modifications apportées aux stratégies IAM (Identity and Access Management) d’un filtre de métrique et d’une alarme. La surveillance des modifications apportées aux stratégies IAM permet de garantir que les contrôles d’authentification et d’autorisation restent intacts.

Gravité : faible

Garantir l’existence d’une alarme et d’un filtre de métrique de journal pour la connexion à Management Console sans authentification multifacteur

Description : La surveillance en temps réel des appels d’API peut être effectuée en dirigeant les journaux CloudTrail vers les journaux CloudWatch et en établissant des filtres de métriques et des alarmes correspondants. Il est recommandé d’établir un filtre de métrique et une alarme pour les connexions de console qui ne sont pas protégées par l’authentification multifacteur (MFA). La surveillance des connexions à une console à facteur unique augmente la visibilité des comptes qui ne sont pas protégés par l’authentification multifacteur.

Gravité : faible

Garantir l’existence d’une alarme et d’un filtre de métrique de journal pour les modifications de la table de routage

Description : La surveillance en temps réel des appels d’API peut être effectuée en dirigeant les journaux CloudTrail vers les journaux CloudWatch et en établissant des filtres de métriques et des alarmes correspondants. Les tables de routage sont utilisées pour acheminer le trafic entre les sous-réseaux et les passerelles réseau. Il est recommandé d’établir un filtre de métrique et une alarme pour les modifications apportées aux tables de routage. La surveillance des modifications apportées aux tables de routage permet de s’assurer que tout le trafic DU VPC transite par un chemin attendu.

Gravité : faible

Garantir l’existence d’une alarme et d’un filtre de métrique de journal pour les changements de stratégie des compartiments S3

Description : La surveillance en temps réel des appels d’API peut être effectuée en dirigeant les journaux CloudTrail vers les journaux CloudWatch et en établissant des filtres de métriques et des alarmes correspondants. Il est recommandé d’établir un filtre de métrique et une alarme pour les modifications apportées aux stratégies des compartiments S3. La surveillance des modifications apportées aux stratégies de compartiment S3 peut réduire le temps nécessaire pour détecter et corriger les stratégies permissives sur les compartiments S3 sensibles.

Gravité : faible

Garantir l’existence d’une alarme et d’un filtre de métrique de journal pour les modifications des groupes de sécurité

Description : La surveillance en temps réel des appels d’API peut être effectuée en dirigeant les journaux CloudTrail vers les journaux CloudWatch et en établissant des filtres de métriques et des alarmes correspondants. Les groupes de sécurité sont un filtre de paquets avec état qui contrôle le trafic d’entrée et de sortie au sein d’un VPC. Il est recommandé d’établir un filtre de métrique et une alarme pour les modifications apportées aux groupes de sécurité. La surveillance des modifications apportées au groupe de sécurité permet de s’assurer que les ressources et les services ne sont pas exposés involontairement.

Gravité : faible

Garantir l’existence d’une alarme et d’un filtre de métrique de journal pour les appels d’API non autorisés

Description : La surveillance en temps réel des appels d’API peut être effectuée en dirigeant les journaux CloudTrail vers les journaux CloudWatch et en établissant des filtres de métriques et des alarmes correspondants. Il est recommandé d’établir un filtre de métrique et une alarme pour les appels d’API non autorisés. La surveillance des appels d’API non autorisés permet de révéler des erreurs d’application et peut réduire le temps de détection d’activités malveillantes.

Gravité : faible

Garantir l’existence d’une alarme et d’un filtre de métrique de journal pour l’utilisation du compte « racine »

Description : La surveillance en temps réel des appels d’API peut être effectuée en dirigeant les journaux CloudTrail vers les journaux CloudWatch et en établissant des filtres de métriques et des alarmes correspondants. Il est recommandé d’établir un filtre de métrique et une alarme pour les tentatives de connexion racine.

La surveillance des connexions de compte racine offre une visibilité sur l’utilisation d’un compte entièrement privilégié et une opportunité de réduire l’utilisation de celui-ci.

Gravité : faible

Garantir l’existence d’une alarme et d’un filtre de métrique de journal pour les modifications apportées au VPC

Description : La surveillance en temps réel des appels d’API peut être effectuée en dirigeant les journaux CloudTrail vers les journaux CloudWatch et en établissant des filtres de métriques et des alarmes correspondants. Il est possible d’avoir plusieurs VPC au sein d’un compte, en outre, il est également possible de créer une connexion d’homologue entre 2 VPC, ce qui permet au trafic réseau d’acheminer entre les VPN. Il est recommandé d’établir un filtre de métrique et une alarme pour les modifications apportées aux VPC. La surveillance des modifications apportées aux stratégies IAM permet de garantir que les contrôles d’authentification et d’autorisation restent intacts.

Gravité : faible

Vérifier qu’aucun groupe de sécurité n’autorise l’entrée de 0.0.0.0/0 sur le port 3389

Description : les groupes de sécurité fournissent un filtrage avec état du trafic réseau d’entrée/sortie vers les ressources AWS. Il est recommandé qu’aucun groupe de sécurité n’autorise l’accès d’entrée illimité au port 3389. Lorsque vous supprimez une connectivité non réduite aux services de console distants, tels que RDP, cela réduit l’exposition d’un serveur au risque.

Gravité : élevée

Les bases de données et les clusters RDS ne doivent pas utiliser de port par défaut du moteur de base de données

Description : ce contrôle vérifie si le cluster ou l’instance RDS utilise un port autre que le port par défaut du moteur de base de données. Si vous utilisez un port connu pour déployer une instance ou un cluster RDS, un attaquant peut deviner des informations sur le cluster ou l’instance. L’attaquant peut utiliser ces informations conjointement avec d’autres informations pour se connecter à une instance ou un cluster RDS ou obtenir des informations supplémentaires sur votre application. Lorsque vous modifiez le port, vous devez également mettre à jour les chaînes de connexion existantes qui étaient utilisées pour se connecter à l’ancien port. Vous devez également vérifier le groupe de sécurité de l’instance de base de données pour vous assurer qu’il comprend une règle d’entrée qui autorise la connectivité sur le nouveau port.

Gravité : faible

Les instances RDS doivent être déployées dans un VPC

Description : les VPN fournissent un certain nombre de contrôles réseau pour sécuriser l’accès aux ressources RDS. Ces contrôles incluent des points de terminaison VPC, des listes de contrôle d’accès réseau et des groupes de sécurité. Pour tirer parti de ces contrôles, nous vous recommandons de déplacer les instances RDS EC2-Classic vers EC2-VPC.

Gravité : faible

Les compartiments S3 doivent exiger que les demandes utilisent le protocole SSL

Description : Nous vous recommandons d’exiger que les demandes utilisent SSL (Secure Socket Layer) sur tous les compartiments Amazon S3. Les compartiments S3 doivent avoir des stratégies qui exigent que toutes les demandes ('Action: S3:*') acceptent uniquement la transmission de données par HTTPS dans la stratégie de ressources S3, indiquée par la clé de condition « aws:SecureTransport ».

Gravité : moyenne

Les groupes de sécurité ne doivent pas autoriser l’entrée de 0.0.0.0/0 sur le port 22

Description : Pour réduire l’exposition du serveur, il est recommandé de ne pas autoriser l’accès illimité à l’entrée au port « 22 ».

Gravité : élevée

Les groupes de sécurité ne doivent pas autoriser un accès illimité aux ports présentant un risque élevé

Description : ce contrôle vérifie si le trafic entrant illimité pour les groupes de sécurité est accessible aux ports spécifiés qui présentent le risque le plus élevé. Ce contrôle réussit lorsqu’aucune des règles d’un groupe de sécurité n’autorise le trafic d’entrée de 0.0.0.0/0 pour ces ports. Un accès illimité (0.0.0.0/0) augmente les possibilités d’activités malveillantes, telles que le piratage, les attaques par déni de service et la perte de données. Les groupes de sécurité assurent un filtrage avec état du trafic d’entrée et de sortie vers les ressources AWS. Aucun groupe de sécurité ne doit autoriser un accès illimité aux ports suivants :

• 3389 (RDP)
• 20, 21 (FTP)
• 22 (SSH)
• 23 (Telnet)
• 110 (POP3)
• 143 (IMAP)
• 3306 (MySQL)
• 8080 (proxy)
• 1433, 1434 (MSSQL)
• 9200 ou 9300 (Elasticsearch)
• 5601 (Kibana)
• 25 (SMTP)
• 445 (CIFS)
• 135 (RPC)
• 4333 (ahsp)
• 5432 (postgresql)
• 5500 (fcp-addr-srvr1)

Gravité : moyenne

Les groupes de sécurité doivent uniquement autoriser le trafic entrant illimité pour les ports autorisés

Description : ce contrôle vérifie si les groupes de sécurité en cours d’utilisation autorisent le trafic entrant illimité. En option, la règle vérifie si les numéros de port sont répertoriés dans le paramètre « authorizedTcpPorts ».

• Si le numéro de port de règle de groupe de sécurité autorise le trafic entrant illimité, mais que le numéro de port est spécifié dans « authorizedTcpPorts », le contrôle passe. La valeur par défaut de « authorizedTcpPorts » est 80, 443.
• Si le numéro de port de règle de groupe de sécurité autorise le trafic entrant illimité, mais que le numéro de port n’est pas spécifié dans le paramètre d’entrée autoriséTcpPorts, le contrôle échoue.
• Si le paramètre n’est pas utilisé, le contrôle échoue pour tout groupe de sécurité disposant d’une règle entrante illimitée. Les groupes de sécurité assurent un filtrage avec état du trafic d’entrée et de sortie vers AWS. Les règles de groupe de sécurité doivent respecter le principe de l’accès au moins privilégié. Un accès illimité (adresse IP avec un suffixe /0) augmente les possibilités d’activités malveillantes telles que le piratage, les attaques par déni de service et la perte de données. À moins qu’un port ne soit spécifiquement autorisé, le port doit refuser l’accès illimité.

Gravité : élevée

Les EIP EC2 non utilisées doivent être supprimées

Description : Les adresses IP élastiques allouées à un VPC doivent être attachées à des instances Amazon EC2 ou à des interfaces réseau élastiques en cours d’utilisation.

Gravité : faible

Les vérifications d’intégrité doivent être activées pour les enregistrements principaux sur les zones hébergées Route53

Description : Defender pour Cloud a identifié un enregistrement PRIMARY de basculement Route 53 sans contrôle d’intégrité activé. Les vérifications d’intégrité sont requises pour valider la disponibilité des points de terminaison pendant le basculement. Sans ces vérifications, le trafic peut être acheminé par inadvertance vers des points de terminaison qui ne répondent pas ou sont compromis, ce qui augmente le risque d’interruption de service et de réduction de la fiabilité.

Gravité : moyenne

Les groupes de sécurité VPC manquants doivent être configurés sur les clusters Redshift

Description : Defender pour Cloud a identifié des groupes de sécurité VPC manquants dans les clusters Amazon Redshift. Les groupes de sécurité VPC sont des pare-feu virtuels utilisés pour contrôler le trafic réseau. Sans ces groupes, vos clusters sont exposés à des accès non autorisés et à des violations de données potentielles, à risque d’informations sensibles et d’intégrité des données. La configuration des groupes de sécurité appropriés est essentielle pour limiter l’accès uniquement aux adresses IP, instances ou ports approuvés.

Gravité : moyenne

L’isolation réseau doit être activée pour les modèles AWS SageMaker

Description : Defender pour Cloud a identifié que les modèles AWS SageMaker n’utilisent pas l’isolation réseau. L’isolation réseau limite les modèles à un environnement réseau privé, ce qui empêche la communication directe avec les ressources Internet publiques. Sans cette isolation, vos modèles risquent d’exposer l’accès non autorisé et l’interception potentielle des données pendant les activités d’apprentissage et d’inférence.

Gravité : moyenne

L’isolation réseau doit être activée sur les points de terminaison AWS SageMaker

Description : Defender pour Cloud a identifié l’isolation réseau désactivée dans les points de terminaison AWS SageMaker. L’isolation réseau limite les communications de point de terminaison aux canaux privés approuvés et non aux réseaux publics. Sans cela, les points de terminaison sont exposés à des risques d’accès et de fuite de données non autorisés, ce qui peut compromettre les opérations de Machine Learning sensibles. L’activation de l’isolation réseau permet de garantir que les communications restent sécurisées et réglementées.

Gravité : moyenne

Les passerelles VPN orphelines doivent être supprimées de AWS VPC

Description : Defender pour Cloud a identifié une passerelle VPN orpheline dans votre AWS VPC. Une passerelle VPN orpheline est une passerelle VPN AWS (VGW) qui n’est connectée à aucun VPC, ce qui signifie qu’elle ne sert pas d’objectif fonctionnel. Cela augmente la surface d’attaque et peut exposer involontairement les détails du routage. La suppression de VGW orphelins permet de garantir une posture réseau propre et sécurisée.

Gravité : faible

La configuration du VPC appropriée doit être activée sur les points de terminaison AWS SageMaker

Description : Defender pour Cloud a identifié un VpcConfig manquant sur votre point de terminaison AWS SageMaker. Un VpcConfig est utilisé pour restreindre l’accès aux réseaux internes, garantissant ainsi une communication sécurisée avec les ressources AWS. Sans cela, le point de terminaison peut être exposé à un accès public et risque d’accès non autorisé et de violations de données. Pour plus d’informations sur la sécurisation de votre point de terminaison, consultez nos conseils. En savoir plus.

Gravité : moyenne

L’accès restreint doit être configuré sur les groupes de sécurité VPC

Description : Defender pour Cloud a identifié des règles d’entrée excessivement permissives dans vos groupes de sécurité VPC. Les groupes de sécurité VPC sont des pare-feu virtuels qui contrôlent le trafic réseau en appliquant des règles pour les connexions entrantes. L’évaluation a détecté des règles autorisant le trafic à partir de 0.0.0.0/0, qui contourne le principe du privilège minimum. Cela pose un risque d’accès non autorisé et d’attaques par force brute pouvant entraîner l’exploitation des vulnérabilités.

Gravité : élevée

Le référencement de groupe de sécurité doit être activé sur AWS Transit Gateway

Description : Defender pour Cloud a identifié que la fonctionnalité de référencement du groupe de sécurité est désactivée sur une passerelle AWS Transit. Le référencement de groupes de sécurité permet aux VPN attachés de référencer des groupes de sécurité au-delà des limites du VPC, ce qui peut augmenter les relations d’approbation. Cette configuration présente un risque en augmentant la surface d’exposition pour les attaques latérales et les fuites d’autorisations accidentelles, ce qui compromet la segmentation du réseau dans les environnements multi-VPC.

Gravité : moyenne

L’indicateur de nom de serveur (SNI) doit être activé Route 53 Health Check

Description : Defender pour Cloud a identifié les contrôles d’intégrité HTTPS Route 53 sans prise en charge de l’indicateur de nom de serveur (SNI) dans AWS Route 53. Les vérifications d’intégrité HTTPS utilisent TLS pour vérifier le certificat d’un serveur en le correspondant au nom d’hôte attendu, et SNI est le mécanisme qui communique ce nom d’hôte pendant l’établissement d’une liaison TLS. Sans SNI, le contrôle d’intégrité peut cibler un hôte inattendu ou échouer la validation de certificat, ce qui entraîne des problèmes de surveillance incorrects et de basculement potentiels.

Gravité : moyenne

Les routes de passerelle Internet et de sortie non autorisées doivent être bloquées sur les tables de routage DU VPC

Description : Defender pour Cloud a identifié des itinéraires IGW (Internet Gateway) non autorisés et Egress-Only passerelle Internet (Egress-Only IGW) dans vos tables de routage VPC. Les tables de routage VPC déterminent le flux de trafic au sein de votre réseau, et ces itinéraires autorisent l’accès IPv6 public et sécurisé involontaire, ce qui peut exposer des ressources internes à des risques tels que l’exfiltration des données et l’accès non autorisé.

Gravité : élevée

Les listes de contrôle d’accès réseau inutilisées doivent être supprimées

Description : ce contrôle vérifie s’il existe des listes de contrôle d’accès réseau inutilisées (ACL). Le contrôle vérifie la configuration des éléments de la ressource « AWS::EC2::NetworkAcl » et détermine les relations de la liste de contrôle d’accès réseau. Si la seule relation est le VPC de la liste de contrôle d’accès réseau, le contrôle échoue. Si d’autres relations sont répertoriées, le contrôle réussit.

Gravité : faible

La destination valide doit être configurée sur les journaux de flux DU VPC

Description : Defender pour Cloud a identifié une configuration LogDestination valide manquante dans vos journaux de flux AWS VPC. Les journaux de flux VPC enregistrent les données de trafic réseau essentielles pour les enquêtes de sécurité et la détection des anomalies. Sans envoyer ces journaux à une destination désignée, comme CloudWatch Logs ou S3, votre environnement risque de ne pas détecter les activités malveillantes et peut rencontrer des problèmes de conformité.

Gravité : élevée

La configuration DU VPC doit être activée sur les points d’accès

Description : Defender pour cloud a identifié les points d’accès qui ne sont pas configurés avec un cloud privé virtuel (VPC) dans votre environnement. Un VPC fournit un réseau privé isolé qui restreint l’exposition à l’Internet public, ce qui garantit la sécurité des données sensibles. Sans cette configuration, vos points d’accès sont plus vulnérables aux violations d’accès et de données non autorisées, ce qui peut compromettre votre sécurité réseau globale.

Gravité : moyenne

L’accès réseau au VPC uniquement doit être configuré sur les domaines AWS SageMaker

Description : Defender pour Cloud a identifié que les domaines AWS SageMaker ne sont pas configurés pour l’accès réseau uniquement au VPC. Cette évaluation vérifie si les communications de domaine sont limitées à votre cloud privé virtuel (VPC), ce qui garantit qu’aucun accès internet public direct n’est autorisé. L’absence de cette configuration présente un risque en exposant les données sensibles aux menaces potentielles et en compromettant la conformité aux normes de sécurité strictes. En savoir plus.

Gravité : moyenne

VpcConfig doit être configuré pour les modèles AWS SageMaker

Description : Defender pour Cloud a identifié des modèles AWS SageMaker sans VpcConfig configuré. VpcConfig (configuration du cloud privé virtuel) garantit que le trafic réseau entre vos modèles SageMaker et d’autres ressources AWS est limité à un environnement privé et sécurisé. Sans cette isolation, vos modèles risquent d’être exposés à l’Internet public, ce qui augmente la probabilité d’accès non autorisé et de violations de données potentielles.

Gravité : moyenne

Le groupe de sécurité par défaut du VPC doit restreindre tout le trafic

Description : Le groupe de sécurité doit limiter tout le trafic pour réduire l’exposition des ressources.

Gravité : faible

Recommandations en matière de mise en réseau GCP

Les hôtes de cluster doivent être configurés pour utiliser uniquement des adresses IP internes privées pour accéder aux API Google

Description : cette recommandation évalue si la propriété privateIpGoogleAccess d’un sous-réseau a la valeur false.

Gravité : élevée

Les instances de calcul doivent utiliser un équilibreur de charge configuré pour utiliser un proxy HTTPS cible

Description : cette recommandation évalue si la propriété selfLink de la ressource targetHttpProxy correspond à l’attribut cible dans la règle de transfert et si la règle de transfert contient un champ loadBalancingScheme défini sur External.

Gravité : moyenne

Les réseaux autorisés du plan de contrôle doivent être activés sur les clusters GKE

Description : cette recommandation évalue la propriété masterAuthorizedNetworksConfig d’un cluster pour la paire clé-valeur « enabled » : false.

Gravité : élevée

La règle de refus de sortie doit être définie sur un pare-feu pour bloquer le trafic sortant indésirable

Description : cette recommandation évalue si la propriété destinationRanges dans le pare-feu est définie sur 0.0.0.0/0 et si la propriété refusée contient la paire clé-valeur, 'IPProtocol': 'all.'

Gravité : faible

Vérifier que les règles de pare-feu pour les instances derrière un proxy prenant en charge l’identité n’autorisent que le trafic en provenance de Google Cloud Loadbalancer (GCLB) Health Check et Proxy Addresses

Description : l’accès aux machines virtuelles doit être limité par des règles de pare-feu qui autorisent uniquement le trafic IAP en garantissant que seules les connexions proxiées par le fournisseur d’accès réseau sont autorisées. Pour vous assurer que l’équilibrage de charge fonctionne correctement, les contrôles d’intégrité doivent également être autorisés. L’IAP garantit que l’accès aux machines virtuelles est contrôlé par l’authentification des demandes entrantes. Toutefois, si la machine virtuelle est toujours accessible à partir d’adresses IP autres que l’IAP, il est possible d’envoyer des requêtes non authentifiées à l’instance. Veillez à ce que les contrôles d’intégrité loadblancer ne soient pas bloqués, car cela empêcherait l’équilibreur de charge de connaître correctement l’intégrité de la machine virtuelle et l’équilibrage de charge correctement.

Gravité : moyenne

Vérifier que les réseaux hérités ne sont pas disponibles pour un projet

Description : Pour empêcher l’utilisation de réseaux hérités, un projet ne doit pas avoir un réseau hérité configuré. Les réseaux hérités ont une plage de préfixes IPv4 réseau unique et une seule adresse IP de passerelle pour l’ensemble du réseau. L’étendue du réseau est globale et s’étend sur toutes les régions cloud. Les sous-réseaux ne peuvent pas être créés dans un réseau hérité et ne peuvent pas passer d’un réseau hérité à un réseau de sous-réseau automatique ou personnalisé. Les réseaux hérités peuvent avoir un impact sur les projets à trafic réseau élevé et sont soumis à un seul point de contention ou de défaillance.

Gravité : moyenne

Vérifiez que l’indicateur de base de données « log_hostname » pour l’instance PostgreSQL cloud est défini de manière appropriée

Description : PostgreSQL journalise uniquement l’adresse IP des hôtes de connexion. L’indicateur « log_hostname » contrôle la journalisation des « noms d’hôte » en plus des adresses IP enregistrées. L’impact sur les performances dépend de la configuration de l’environnement et de la configuration de la résolution de noms d’hôte. Ce paramètre peut être défini uniquement dans le fichier postgresql.conf ou sur la ligne de commande du serveur. La journalisation des noms d’hôte peut entraîner une surcharge sur les performances du serveur, car pour chaque instruction journalisée, la résolution DNS est nécessaire pour convertir l’adresse IP en nom d’hôte. Selon la configuration, cela peut être non négligeable. En outre, les adresses IP journalisées peuvent être résolues en noms DNS ultérieurement lors de l’examen des journaux, à l’exclusion des cas où des noms d’hôte dynamiques sont utilisés. Cette recommandation s’applique aux instances de base de données PostgreSQL.

Gravité : faible

Vérifier qu’aucun équilibreur de charge proxy HTTPS ou SSL n’autorise des stratégies SSL avec des suites de chiffrement faibles

Description : les stratégies SSL (Secure Sockets Layer) déterminent les fonctionnalités TLS (Transport Layer Security) des ports que les clients sont autorisés à utiliser lors de la connexion à des équilibreurs de charge. Pour empêcher l’utilisation des fonctionnalités non sécurisées, les stratégies SSL doivent utiliser (a) au moins TLS 1.2 avec le profil MODERNE ; ou (b) le profil RESTRICTED, car il nécessite effectivement que les clients utilisent TLS 1.2, quelle que soit la version minimale de TLS choisie ; ou (3) un profil PERSONNALISÉ qui ne prend pas en charge les fonctionnalités suivantes : TLS_RSA_WITH_AES_128_GCM_SHA256 TLS_RSA_WITH_AES_256_GCM_SHA384 TLS_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA

Les équilibreurs de charge sont utilisés pour distribuer efficacement le trafic sur plusieurs serveurs. Les équilibreurs de charge SSL et HTTPS sont tous deux des équilibreurs de charge externes, ce qui signifie qu’ils distribuent le trafic à partir d’Internet vers un réseau GCP. Les clients GCP peuvent configurer des stratégies SSL d’équilibreur de charge avec une version TLS minimale (1.0, 1.1 ou 1.2) que les clients peuvent utiliser pour établir une connexion, ainsi qu’un profil (Compatible, Moderne, Restreint ou Personnalisé) qui spécifie les suites de chiffrement autorisées. Pour se conformer aux utilisateurs avec des protocoles obsolètes, les équilibreurs de charge GCP peuvent être configurés pour autoriser des suites de chiffrement non sécurisées. En fait, la stratégie SSL par défaut de GCP utilise une version TLS minimale de 1.0 et un profil compatible, ce qui autorise la plus grande gamme de suites de chiffrement non sécurisées. Par conséquent, il est facile pour les clients de configurer un équilibreur de charge sans même savoir qu’ils autorisent des suites de chiffrement obsolètes.

Gravité : moyenne

Vérifiez que la journalisation DNS cloud est activée pour tous les réseaux VPC

Description : la journalisation DNS cloud enregistre les requêtes des serveurs de noms de votre VPC vers Stackdriver. Les requêtes journalisées peuvent provenir de machines virtuelles Compute Engine, de conteneurs GKE ou d’autres ressources GCP approvisionnées dans le VPC. La surveillance de la sécurité et les analyses de sécurité ne peuvent pas dépendre uniquement des adresses IP des journaux de flux DU VPC, en particulier lorsque vous envisagez l’utilisation dynamique des adresses IP des ressources cloud, le routage de l’hôte virtuel HTTP et d’autres technologies qui peuvent masquer le nom DNS utilisé par un client à partir de l’adresse IP. La surveillance des journaux DNS cloud fournit une visibilité sur les noms DNS demandés par les clients au sein du VPC. Ces journaux peuvent être surveillés pour détecter les noms de domaine anormaux, évalués par rapport au renseignement sur les menaces et

Pour obtenir une capture complète du DNS, le pare-feu doit bloquer les sorties UDP/53 (DNS) et TCP/443 (DNS sur HTTPS) pour empêcher le client d’utiliser le serveur de noms DNS externe pour la résolution.

Gravité : élevée

Vérifier que DNSSEC est activé pour le DNS cloud

Description : Le système DNS (Cloud Domain Name System) est un système de noms de domaine rapide, fiable et économique qui alimente des millions de domaines sur Internet. Les extensions DNSSEC (Domain Name System Security Extensions) dans Cloud DNS permettent aux propriétaires de domaine de prendre des mesures faciles pour protéger leurs domaines contre le détournement DNS, les attaques d’intercepteurs et d’autres attaques. Domain Name System Security Extensions (DNSSEC) ajoute une suite d’extensions qui renforce la sécurité du protocole DNS en permettant de valider les réponses DNS. Avoir un DNS fiable qui traduit un nom de domaine comme www.example.com dans son adresse IP associée est un bloc de construction de plus en plus important des applications web d’aujourd’hui. Les attaquants peuvent détourner ce processus de recherche de domaine/IP et rediriger les utilisateurs vers un site malveillant via le détournement DNS et les attaques d’intercepteurs. DNSSEC permet d’atténuer le risque de telles attaques en signant des enregistrements DNS par chiffrement. Par conséquent, il empêche les attaquants d’émettre de fausses réponses DNS susceptibles de faire passer des navigateurs malveillants à des sites web malveillants.

Gravité : moyenne

Vérifier que l’accès RDP à partir d’Internet est limité

Description : Les règles de pare-feu GCP sont spécifiques à un réseau VPC. Chaque règle autorise ou refuse le trafic lorsque ses conditions sont remplies. Ses conditions permettent aux utilisateurs de spécifier le type de trafic, comme les ports et les protocoles, ainsi que la source ou la destination du trafic, y compris les adresses IP, les sous-réseaux et les instances. Les règles de pare-feu sont définies au niveau du réseau VPC et sont spécifiques au réseau dans lequel elles sont définies. Les règles elles-mêmes ne peuvent pas être partagées entre les réseaux. Les règles de pare-feu prennent uniquement en charge le trafic IPv4. Lorsque vous spécifiez une source pour une règle d’entrée ou une destination pour une règle de sortie par adresse, un bloc IPv4 ou IPv4 en notation CIDR peut être utilisé. Le trafic entrant (0.0.0.0/0) générique de l’Internet vers une instance de VM ou DE VPC à l’aide du protocole RDP sur le port 3389 peut être évité. Règles de pare-feu GCP au sein d’un réseau VPC. Ces règles s’appliquent au trafic sortant des instances et au trafic entrant vers les instances du réseau. Les flux de trafic de sortie et d’entrée sont contrôlés même si le trafic reste dans le réseau (par exemple, la communication d’instance à instance). Pour qu’une instance dispose d’un accès Internet sortant, le réseau doit disposer d’un itinéraire de passerelle Internet valide ou d’un itinéraire personnalisé dont l’adresse IP de destination est spécifiée. Cet itinéraire définit simplement le chemin d’accès à Internet, pour éviter la plage d’adresses IP de destination la plus générale (0.0.0.0/0) spécifiée à partir d’Internet via RDP avec le port par défaut 3389. L’accès générique à partir d’Internet à une plage d’adresses IP spécifique doit être limité.

Gravité : élevée

Vérifier que RSASHA1 n’est pas utilisé pour la clé de signature de clé dans DNSSEC DNS cloud

Description : les numéros d’algorithme DNSSEC dans ce Registre peuvent être utilisés dans les RR CERT. La signature de zone (DNSSEC) et les mécanismes de sécurité des transactions (SIG(0) et TSIG) utilisent des sous-ensembles particuliers de ces algorithmes. L’algorithme utilisé pour la signature de clé doit être recommandé et fort. Les numéros d’algorithme DNSSEC (Domain Name System Security Extensions) de ce Registre peuvent être utilisés dans les RDR CERT. La signature de zone (DNSSEC) et les mécanismes de sécurité des transactions (SIG(0) et TSIG) utilisent des sous-ensembles particuliers de ces algorithmes. L’algorithme utilisé pour la signature de clé doit être recommandé et fort. Lorsque vous activez DNSSEC pour une zone managée ou créez une zone managée avec DNSSEC, l’utilisateur peut sélectionner les algorithmes de signature DNSSEC et le type de déni d’existence. La modification des paramètres DNSSEC n’est effective que pour une zone gérée si DNSSEC n’est pas déjà activé. S’il est nécessaire de modifier les paramètres d’une zone gérée où elle a été activée, désactivez DNSSEC, puis réactivez-le avec différents paramètres.

Gravité : moyenne

Vérifier que RSASHA1 n’est pas utilisé pour la clé de signature de zone dans DNSSEC DNS cloud

Description : les numéros d’algorithme DNSSEC dans ce Registre peuvent être utilisés dans les RR CERT. La signature de zone (DNSSEC) et les mécanismes de sécurité des transactions (SIG(0) et TSIG) utilisent des sous-ensembles particuliers de ces algorithmes. L’algorithme utilisé pour la signature de clé doit être recommandé et fort. Les numéros d’algorithme DNSSEC dans ce Registre peuvent être utilisés dans les RDR CERT. La signature de zone (DNSSEC) et les mécanismes de sécurité des transactions (SIG(0) et TSIG) utilisent des sous-ensembles particuliers de ces algorithmes. L’algorithme utilisé pour la signature de clé doit être recommandé et fort. Lorsque vous activez DNSSEC pour une zone managée ou créez une zone managée avec DNSSEC, les algorithmes de signature DNSSEC et le type de déni d’existence peut être sélectionné. La modification des paramètres DNSSEC n’est effective que pour une zone gérée si DNSSEC n’est pas déjà activé. Si le besoin existe de modifier les paramètres d’une zone managée où il a été activé, désactivez DNSSEC, puis réactivez-le avec différents paramètres.

Gravité : moyenne

Vérifier que l’accès SSH à partir d’Internet est restreint

Description : Les règles de pare-feu GCP sont spécifiques à un réseau VPC. Chaque règle autorise ou refuse le trafic lorsque ses conditions sont remplies. Ses conditions permettent à l’utilisateur de spécifier le type de trafic, comme les ports et les protocoles, ainsi que la source ou la destination du trafic, y compris les adresses IP, les sous-réseaux et les instances. Les règles de pare-feu sont définies au niveau du réseau VPC et sont spécifiques au réseau dans lequel elles sont définies. Les règles elles-mêmes ne peuvent pas être partagées entre les réseaux. Les règles de pare-feu prennent uniquement en charge le trafic IPv4. Lorsque vous spécifiez une source pour une règle d’entrée ou une destination pour une règle de sortie par adresse, seul un bloc IPv4 ou IPv4 dans la notation CIDR peut être utilisé. Le trafic entrant générique (0.0.0.0/0) provenant d’Internet vers une instance de VPC ou de machine virtuelle utilisant SSH sur le port 22 peut être évité. Les règles de pare-feu GCP au sein d’un réseau VPC s’appliquent au trafic sortant des instances et au trafic entrant vers les instances du réseau. Les flux de trafic de sortie et d’entrée sont contrôlés même si le trafic reste dans le réseau (par exemple, la communication d’instance à instance). Pour qu’une instance dispose d’un accès Internet sortant, le réseau doit disposer d’un itinéraire de passerelle Internet valide ou d’un itinéraire personnalisé dont l’adresse IP de destination est spécifiée. Cet itinéraire définit simplement le chemin d’accès à Internet, pour éviter la plage d’adresses IP de destination la plus générale (0.0.0.0/0) spécifiée à partir d’Internet via SSH avec le port par défaut « 22 ». L’accès générique à partir d’Internet à une plage d’adresses IP spécifique doit être limité.

Gravité : élevée

Vérifier que le réseau par défaut n’existe pas dans un projet

Description : Pour empêcher l’utilisation du réseau « par défaut », un projet ne doit pas avoir de réseau « par défaut ». Le réseau par défaut a une configuration réseau préconfigurée et génère automatiquement les règles de pare-feu non sécurisées suivantes :

• default-allow-internal : autorise les connexions d’entrée pour tous les protocoles et ports parmi les instances du réseau.
• default-allow-ssh : autorise les connexions d’entrée sur le port TCP 22 (SSH) de n’importe quelle source vers n’importe quelle instance du réseau.
• default-allow-rdp : autorise les connexions d’entrée sur le port TCP 3389 (RDP) de n’importe quelle source vers n’importe quelle instance du réseau.
• default-allow-icmp : autorise le trafic ICMP d’entrée de n’importe quelle source vers n’importe quelle instance du réseau.

Ces règles de pare-feu créées automatiquement n’obtiennent pas de journalisation d’audit et ne peuvent pas être configurées pour activer la journalisation des règles de pare-feu. En outre, le réseau par défaut est un réseau en mode automatique, ce qui signifie que ses sous-réseaux utilisent la même plage prédéfinie d’adresses IP. Par conséquent, il n’est pas possible d’utiliser le peering réseau VPN cloud ou VPC avec le réseau par défaut. En fonction des exigences de sécurité et de mise en réseau de l’organisation, l’organisation doit créer un réseau et supprimer le réseau par défaut.

Gravité : moyenne

Vérifier que les alertes et le filtre de métrique du journal existent pour les changements de réseau VPC

Description : il est recommandé d’établir un filtre de métrique et une alarme pour les modifications du réseau de cloud privé virtuel (VPC). Il est possible d’avoir plusieurs VPC au sein d’un projet. En outre, il est également possible de créer une connexion homologue entre deux VPN, ce qui permet au trafic réseau d’acheminer entre les VPN. La surveillance des modifications apportées à un VPC permet de s’assurer que le flux de trafic du VPC n’est pas affecté.

Gravité : faible

Vérifier que les alertes et le filtre de métrique du journal existent pour les changements de règle du pare-feu réseau VPC

Description : il est recommandé d’établir un filtre de métrique et une alarme pour les modifications apportées à la règle de pare-feu réseau du cloud privé virtuel (VPC). La surveillance des événements de règle de création ou de mise à jour de pare-feu donne des informations sur les modifications d’accès réseau et peut réduire le temps nécessaire pour détecter les activités suspectes.

Gravité : faible

Vérifier que les alertes et le filtre de métrique du journal existent pour les changements de route réseau VPC

Description : il est recommandé d’établir un filtre de métrique et une alarme pour les modifications d’itinéraire réseau du cloud privé virtuel (VPC). Les itinéraires Google Cloud Platform (GCP) définissent les chemins d’accès du trafic réseau d’une instance de machine virtuelle vers une autre destination. L’autre destination peut se trouver à l’intérieur du réseau VPC de l’organisation (par exemple, une autre machine virtuelle) ou en dehors de celui-ci. Chaque itinéraire se compose d’une destination et d’un tronçon suivant. Le trafic dont l’adresse IP de destination se trouve dans la plage de destination est envoyé au tronçon suivant pour remise. La supervision des modifications apportées aux tables de routage permet de s’assurer que tout le trafic du VPC emprunte le chemin attendu.

Gravité : faible

Vérifiez que l’indicateur de base de données « log_connections » pour l’instance Cloud SQL PostgreSQL est défini sur « activé »

Description : L’activation du paramètre log_connections entraîne la journalisation de chaque tentative de connexion au serveur, ainsi que la réussite de l’authentification du client. Ce paramètre ne peut pas être modifié après le démarrage de la session. PostgreSQL ne consigne pas les connexions tentées par défaut. L’activation du paramètre log_connections crée des entrées de journal pour chaque tentative de connexion, ainsi que la réussite de l’authentification du client, ce qui peut être utile pour résoudre les problèmes et déterminer les tentatives de connexion inhabituelles sur le serveur. Cette recommandation s’applique aux instances de base de données PostgreSQL.

Gravité : moyenne

Vérifiez que l’indicateur de base de données « log_disconnections » pour l’instance Cloud SQL PostgreSQL est défini sur « activé »

Description : Activation du paramètre log_disconnections journalise la fin de chaque session, y compris la durée de la session. PostgreSQL ne consigne pas les détails de session, tels que la durée et la fin de session par défaut. L’activation du paramètre log_disconnections crée des entrées de journal à la fin de chaque session, ce qui peut être utile pour résoudre les problèmes et déterminer toute activité inhabituelle sur une période donnée. log_disconnections et log_connections fonctionnent main dans la main et, en règle générale, la paire est activée/désactivée ensemble. Cette recommandation s’applique aux instances de base de données PostgreSQL.

Gravité : moyenne

Vérifier que les journaux de flux VPC sont activés pour chaque sous-réseau d’un réseau VPC

Description : Les journaux de flux sont une fonctionnalité qui permet aux utilisateurs de capturer des informations sur le trafic IP vers et à partir d’interfaces réseau dans les sous-réseaux VPC de l’organisation. Une fois qu’un journal de flux est créé, l’utilisateur peut afficher et récupérer ses données dans la journalisation Stackdriver. Il est recommandé d’activer les journaux de flux pour chaque sous-réseau VPC critique pour l’entreprise. Les réseaux et sous-réseaux VPC fournissent des partitions réseau logiquement isolées et sécurisées où les ressources GCP peuvent être lancées. Lorsque les journaux de flux sont activés pour un sous-réseau, les machines virtuelles de ce sous-réseau commencent à créer des rapports sur tous les flux TCP (Transmission Control Protocol) et UDP (User Datagram Protocol). Chaque machine virtuelle échantillonne les flux TCP et UDP qu’elle voit, entrants et sortants, que le flux soit à destination ou en provenance d’une autre machine virtuelle, d’un hôte dans le centre de données local, d’un service Google ou d’un hôte sur Internet. Si deux machines virtuelles GCP communiquent et qu’elles se trouvent toutes les deux dans des sous-réseaux où les journaux de flux VPC sont activés, les deux machines virtuelles signalent les flux. Les journaux de flux prennent en charge les cas d’utilisation suivants : 1. Surveillance du réseau. 2. Comprendre l’utilisation du réseau et optimiser les dépenses de trafic réseau. 3. Investigation du réseau. 4. Les journaux de flux d’analyse de sécurité en temps réel fournissent une visibilité du trafic réseau pour chaque machine virtuelle à l’intérieur du sous-réseau et peuvent être utilisés pour détecter le trafic ou les insights anormales pendant les workflows de sécurité.

Gravité : faible

La journalisation des règles de pare-feu doit être activée

Description : cette recommandation évalue la propriété logConfig dans les métadonnées de pare-feu pour voir s’il est vide ou contient la paire clé-valeur « enable » : false.

Gravité : moyenne

Le pare-feu ne doit pas être configuré pour être ouvert à l’accès public

Description : cette recommandation évalue les propriétés sourceRanges et autorisées pour l’une des deux configurations :

La propriété sourceRanges contient 0.0.0.0/0 et la propriété autorisée contient une combinaison de règles qui inclut tout protocole ou toute paire protocole:port, à l’exception de ce qui suit :

• icmp
• tcp : 22
• tcp : 443
• tcp : 3389
• udp : 3389
• sctp : 22

La propriété sourceRanges contient une combinaison de plages d’adresses IP qui inclut n’importe quelle adresse IP non privilégiée et la propriété autorisée contient une combinaison de règles qui autorisent tous les ports tcp ou tous les ports udp.

Gravité : élevée

Le pare-feu ne doit pas être configuré pour avoir un port CASSANDRA ouvert qui autorise l’accès générique

Description : Cette recommandation évalue la propriété autorisée dans les métadonnées de pare-feu pour les protocoles et ports suivants : TCP : 7000-7001, 7199, 8888, 9042, 9160, 61620-61621.

Gravité : faible

Le pare-feu ne doit pas être configuré pour avoir un port CISCOSECURE_WEBSM ouvert qui autorise un accès générique

Description : cette recommandation évalue la propriété autorisée dans les métadonnées de pare-feu pour le protocole et le port suivants : TCP : 9090.

Gravité : faible

Le pare-feu ne doit pas être configuré pour avoir un port de DIRECTORY_SERVICES ouvert qui autorise un accès générique

Description : Cette recommandation évalue la propriété autorisée dans les métadonnées de pare-feu pour les protocoles et ports suivants : TCP : 445 et UDP : 445.

Gravité : faible

Le pare-feu ne doit pas être configuré pour avoir un port DNS ouvert qui autorise l’accès générique

Description : cette recommandation évalue la propriété autorisée dans les métadonnées de pare-feu pour les protocoles et ports suivants : TCP : 53 et UDP : 53.

Gravité : faible

Le pare-feu ne doit pas être configuré pour avoir un port ELASTICSEARCH ouvert qui autorise l’accès générique

Description : cette recommandation évalue la propriété autorisée dans les métadonnées de pare-feu pour les protocoles et ports suivants : TCP : 9200, 9300.

Gravité : faible

Le pare-feu ne doit pas être configuré pour avoir un port FTP ouvert qui autorise l’accès générique

Description : cette recommandation évalue la propriété autorisée dans les métadonnées de pare-feu pour le protocole et le port suivants : TCP : 21.

Gravité : faible

Le pare-feu ne doit pas être configuré pour avoir un port HTTP ouvert qui autorise l’accès générique

Description : cette recommandation évalue la propriété autorisée dans les métadonnées de pare-feu pour les protocoles et ports suivants : TCP : 80.

Gravité : faible

Le pare-feu ne doit pas être configuré pour avoir un port LDAP ouvert qui autorise l’accès générique

Description : cette recommandation évalue la propriété autorisée dans les métadonnées de pare-feu pour les protocoles et ports suivants : TCP : 389, 636 et UDP : 389.

Gravité : faible

Le pare-feu ne doit pas être configuré pour avoir un port MEMCACHED ouvert qui autorise l’accès générique

Description : Cette recommandation évalue la propriété autorisée dans les métadonnées de pare-feu pour les protocoles et ports suivants : TCP : 11211, 11214-11215 et UDP : 11211, 11214-111215.

Gravité : faible

Le pare-feu ne doit pas être configuré pour avoir un port MONGODB ouvert qui autorise l’accès générique

Description : cette recommandation évalue la propriété autorisée dans les métadonnées de pare-feu pour les protocoles et ports suivants : TCP : 27017-27019.

Gravité : faible

Le pare-feu ne doit pas être configuré pour avoir un port MYSQL ouvert qui autorise l’accès générique

Description : cette recommandation évalue la propriété autorisée dans les métadonnées de pare-feu pour le protocole et le port suivants : TCP : 3306.

Gravité : faible

Le pare-feu ne doit pas être configuré pour avoir un port NETBIOS ouvert qui autorise l’accès générique

Description : Cette recommandation évalue la propriété autorisée dans les métadonnées de pare-feu pour les protocoles et ports suivants : TCP : 137-139 et UDP : 137-139.

Gravité : faible

Le pare-feu ne doit pas être configuré pour avoir un port ORACLEDB ouvert qui autorise l’accès générique

Description : cette recommandation évalue la propriété autorisée dans les métadonnées de pare-feu pour les protocoles et ports suivants : TCP : 1521, 2483-2484 et UDP : 2483-2484.

Gravité : faible

Le pare-feu ne doit pas être configuré pour avoir un port POP3 ouvert qui autorise l’accès générique

Description : cette recommandation évalue la propriété autorisée dans les métadonnées de pare-feu pour le protocole et le port suivants : TCP : 110.

Gravité : faible

Le pare-feu ne doit pas être configuré pour avoir un port PostgreSQL ouvert qui autorise l’accès générique

Description : cette recommandation évalue la propriété autorisée dans les métadonnées de pare-feu pour les protocoles et ports suivants : TCP : 5432 et UDP : 5432.

Gravité : faible

Le pare-feu ne doit pas être configuré pour avoir un port REDIS ouvert qui autorise l’accès générique

Description : cette recommandation évalue si la propriété autorisée dans les métadonnées de pare-feu contient le protocole et le port suivants : TCP : 6379.

Gravité : faible

Le pare-feu ne doit pas être configuré pour avoir un port SMTP ouvert qui autorise l’accès générique

Description : Cette recommandation évalue si la propriété autorisée dans les métadonnées de pare-feu contient le protocole et le port suivants : TCP : 25.

Gravité : faible

Le pare-feu ne doit pas être configuré pour avoir un port SSH ouvert qui autorise l’accès générique

Description : cette recommandation évalue si la propriété autorisée dans les métadonnées de pare-feu contient les protocoles et ports suivants : TCP : 22 et SCTP : 22.

Gravité : faible

Le pare-feu ne doit pas être configuré pour avoir un port TELNET ouvert qui autorise l’accès générique

Description : cette recommandation évalue si la propriété autorisée dans les métadonnées de pare-feu contient le protocole et le port suivants : TCP : 23.

Gravité : faible

Les plages d’adresses IP des alias doivent être activées pour les clusters GKE

Description : cette recommandation évalue si le champ useIPAliases de l’ipAllocationPolicy dans un cluster a la valeur false.

Gravité : faible

Le réseau VPC personnalisé doit être configuré pour Memorystore pour l’instance Memcached

Description : Defender pour Cloud a identifié l’utilisation d’un réseau VPC par défaut global comme réseau autorisé pour une instance Memorystore pour Memcached. Le réseau VPC par défaut, souvent largement configuré avec des règles de pare-feu permissives, augmente le risque d’accès interne involontaire et de mouvement latéral entre les systèmes. L’utilisation d’un réseau VPC dédié ou étroitement contrôlé garantit que seules les charges de travail explicitement autorisées peuvent accéder aux données mises en cache, ce qui réduit la surface d’attaque.

Gravité : moyenne

Le réseau VPC personnalisé doit être configuré pour les instances Memorystore pour Redis

Description : Defender pour Cloud a identifié l’utilisation du réseau VPC global par défaut pour memorystore pour les instances Redis. Le réseau VPC par défaut est largement étendu et a généralement des règles de pare-feu permissives, ce qui augmente le risque que les services internes non autorisés puissent accéder aux données mises en cache et se déplacer ultérieurement sur les systèmes. La configuration d’un réseau VPC dédié ou étroitement contrôlé peut restreindre l’accès aux charges de travail autorisées uniquement.

Gravité : moyenne

Le réseau VPC personnalisé doit être configuré sur les instances filestore

Description : Les instances de Magasin de fichiers identifiées defender pour cloud s’exécutant sur le réseau VPC par défaut. Le réseau par défaut est un environnement partagé qui manque généralement de segmentation stricte et de limites de pare-feu isolées requises pour le stockage de données sensibles. Cette configuration augmente le risque de mouvement latéral et d’accès non autorisé. Le déploiement d’un magasin de fichiers dans des réseaux VPC personnalisés peut fournir une isolation plus étroite et des contrôles réseau améliorés. En savoir plus.

Gravité : moyenne

L’exportation d’itinéraires personnalisés doit être désactivée sur les peerings de réseau VPC

Description : Defender pour Cloud a identifié l’exportation d’itinéraires personnalisés activée dans vos configurations de peering réseau VPC. L’exportation d’itinéraires personnalisés permet aux itinéraires non natifs d’être échangés entre des réseaux appairés, ce qui peut exposer des environnements isolés à un mouvement latéral non autorisé si un réseau est compromis.

Gravité : faible

La planification de sauvegarde par défaut pour les nouvelles bases de données doit être activée

Description : Defender pour Cloud a identifié que l’adresse IP publique est activée sur votre instance d’AlliageDB. L’activation de l’adresse IP publique permet à une instance de recevoir une adresse IP externe, qui l’expose directement à Internet. Cette exposition accrue peut entraîner des attaques par force brute et une exploitation des vulnérabilités. La désactivation d’adresses IP publiques et l’utilisation d’une connectivité privée permet de maintenir un environnement d’accès sécurisé et limité.

Gravité : élevée

Les ports autorisés excédentaires doivent être limités aux services essentiels sur les règles de transfert GCP

Description : Defender pour Cloud a identifié une exposition excessive des ports dans les règles de transfert GCP. L’évaluation a révélé que lorsque la propriété allPorts est activée sur des équilibreurs de charge TCP/UDP internes, elle autorise le trafic sur tous les ports (1-65535), en contournant les contrôles de sécurité de couche 4. Cela augmente le risque de mouvement latéral involontaire au sein du VPC. La restriction des ports aux ports requis pour les services essentiels réduit ce risque d’exploitation.

Gravité : moyenne

Les clusters GKE doivent avoir les clusters privés activés

Description : cette recommandation évalue si le champ enablePrivateNodes de la propriété privateClusterConfig a la valeur false.

Gravité : élevée

L’accès global doit être désactivé pour les points de terminaison GCP Private Service Connect

Description : Defender pour Cloud a identifié l’accès global activé sur vos points de terminaison GCP Private Service Connect. Dans ce contexte, la propriété allowPscGlobalAccess permet à un point de terminaison régional d’accepter les connexions d’autres régions, ce qui peut exposer par inadvertance des pièces jointes de service sensibles à une connectivité interrégion non autorisée. Cela peut augmenter le risque de violations de données et compromettre la séparation du trafic, de sorte que la restriction des points de terminaison à leur région locale est recommandée.

Gravité : moyenne

La journalisation cloud manquante doit être activée sur les services principaux Load Balancer

Description : Defender pour Cloud a identifié la journalisation désactivée dans les services principaux Load Balancer. Ces services distribuent le trafic réseau entre les serveurs principaux et s’appuient sur la journalisation détaillée pour capturer les métadonnées de demande et de connexion. Sans journalisation, il est plus difficile d’analyser les modèles de trafic et de détecter les incidents de sécurité potentiels, ce qui peut entraver les enquêtes judiciaires et les fonctionnalités globales de détection des menaces. Pour plus d’informations, visitez https://cloud.google.com/load-balancing/docs/https/https-logging-monitoring.

Gravité : faible

Liste de contrôle d’accès réseau sans refus sur LE VPC

Description : Defender pour Cloud a identifié que votre VPC utilise sa liste de contrôle d’accès réseau par défaut. Une liste de contrôle d’accès réseau est un pare-feu au niveau du sous-réseau qui contrôle le trafic entrant et sortant. L’utilisation de la configuration allow-all par défaut présente un risque pour vos ressources, car elle ne limite pas le trafic tant qu’elle n’est pas explicitement autorisée, ce qui peut permettre l’accès non autorisé et les violations de données.

Gravité : élevée

La stratégie réseau doit être activée sur les clusters GKE

Description : cette recommandation évalue le champ networkPolicy de la propriété addonsConfig pour la paire clé-valeur « disabled » : true.

Gravité : moyenne

Private Service Connect doit être activé sur les clusters AlloyDB

Description : Le cluster Defender pour Cloud identifié d’AlliageDB sans psc (Private Service Connect) est activé. PSC permet aux clusters d’être accessibles via des points de terminaison dédiés plutôt que par le peering VPC traditionnel. Sans PSC, les clusters restent exposés aux risques réseau tels que le chevauchement de l’adresse IP et l’augmentation des chances de déplacement latéral sur les réseaux appairés. L’activation de PSC améliore l’isolation et vous permet de mieux contrôler la gestion des points de terminaison, ce qui réduit ces risques.

Gravité : faible

Les restrictions d’accès public doivent être configurées pour les domaines CodeArtifact

Description : Defender pour Cloud a identifié des domaines AWS CodeArtifact avec des stratégies d’accès qui autorisent des principaux génériques. Ces stratégies permettent à n’importe quelle identité AWS, y compris celles provenant de comptes externes, d’interagir avec le domaine. Cela pose un risque d’émission de jeton d’autorisation non autorisé, de création de référentiel non approuvé et de modifications administratives. La limitation de l’accès aux principaux de confiance explicite est essentielle pour maintenir des limites sécurisées et réduire l’exposition.

Gravité : élevée

Les restrictions d’ingestion de package externe transitive doivent être activées sur les référentiels CodeArtifact

Description : Defender pour Cloud a identifié l’ingestion de package externe transitive dans les référentiels CodeArtifact. Référentiels avec indicateur d’évaluation qui héritent des connexions externes à partir de sources en amont plutôt que d’utiliser une configuration directe et explicite. Ce chemin d’approbation transitif permet aux packages provenant de sources publiques de circuler dans des systèmes internes sans vérification appropriée, ce qui augmente le risque d’introduire des packages vulnérables ou non vérifiés dans vos chaînes de dépendances et vos systèmes de build en aval.

Gravité : élevée

L’authentification forte doit être activée sur la configuration du webhook CodePipeline

Description : Defender pour Cloud a identifié une authentification faible sur votre configuration de webhook CodePipeline. Les webhooks CodePipeline sont conçus pour déclencher des actions uniquement à partir de sources approuvées et vérifiées. Sans authentification forte, un tiers non autorisé peut déclencher le webhook, entraînant des actions indésirables, une utilisation excessive des ressources ou même une condition de déni de service (DoS).

Gravité : élevée

Les groupes de sous-réseaux doivent être configurés sur des clusters DAX avec des sous-réseaux privés

Description : Defender pour Cloud a identifié que votre cluster DAX utilise le groupe de sous-réseaux par défaut ou n’a pas de groupe de sous-réseaux configuré. Les groupes de sous-réseaux par défaut contiennent des sous-réseaux publics avec routage Internet direct et affectation automatique d’adresses IP publiques, ce qui expose votre cluster à des risques de sécurité inutiles. Un groupe de sous-réseaux correctement configuré avec des sous-réseaux privés est essentiel pour isoler et protéger votre cluster DAX contre l’accès réseau non autorisé. Les sous-réseaux privés garantissent une sécurité de défense en profondeur en empêchant l’accès Internet direct à votre cache de base de données.

Gravité : moyenne

L’accès global illimité doit être désactivé pour les règles de transfert interne GCP

Description : Defender pour Cloud a identifié un accès global illimité dans vos règles de transfert interne GCP. L’indicateur allowGlobalAccess est activé, ce qui permet aux équilibreurs de charge internes d’accepter le trafic depuis n’importe quelle région du même VPC au lieu d’être limité à une région spécifique. Cela augmente le risque de violation des exigences de résidence des données régionales et étend le rayon d’explosion potentiel dans une violation de sécurité.

Gravité : faible

Contenu connexe

• Présentation des stratégies de sécurité, des initiatives et des recommandations.
• Consulter vos recommandations de sécurité