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

Article
07/08/2024

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.

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. Pour en savoir plus, consultez Améliorer votre posture de sécurité réseau avec le durcissement de réseau adaptatif. (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

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. (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

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

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

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

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 »

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

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

Partager via

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

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

Recommandations de mise en réseau AWS

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

Contenu connexe

Commentaires

Commentaires

Ressources supplémentaires