Benchmark microsoft Cloud Security : Protection des données, journalisation et détection des menaces et sécurité réseau

  • 15 minutes

Contrôle de sécurité : protection des données

La protection des données couvre le contrôle de la protection des données au repos, en transit et via des mécanismes d’accès autorisés, notamment la découverte, la classification, la protection et la surveillance des ressources de données sensibles à l’aide du contrôle d’accès, du chiffrement, de la gestion des clés et de la gestion des certificats.

DP-3 : Chiffrer les données sensibles en transit

ID des contrôles CIS v8 ID NIST SP 800-53 r4 ID PCI-DSS v3.2.1
3.10 SC-8 3.5, 3.6, 4.1

Principe de sécurité : Protégez les données en transit contre les attaques « hors bande » (telles que la capture de trafic) à l’aide du chiffrement pour vous assurer que les attaquants ne peuvent pas lire ou modifier facilement les données.

Définissez la limite réseau et l’étendue du service où les données du chiffrement de transit sont obligatoires à l’intérieur et à l’extérieur du réseau. Bien que cela soit facultatif pour le trafic sur des réseaux privés, il est essentiel pour le trafic sur des réseaux externes et publics.

Conseils Azure : Appliquez un transfert sécurisé dans des services tels que stockage Azure, où une fonctionnalité de chiffrement de données natives en transit est intégrée.

Appliquez HTTPS pour les charges de travail et services d’application web en veillant à ce que tous les clients qui se connectent à vos ressources Azure utilisent tls (Transport Layer Security) v1.2 ou version ultérieure. Pour la gestion à distance des machines virtuelles, utilisez SSH (pour Linux) ou RDP/TLS (pour Windows) au lieu d’un protocole non chiffré.

Pour la gestion à distance des machines virtuelles Azure, utilisez SSH (pour Linux) ou RDP/TLS (pour Windows) au lieu d’un protocole non chiffré. Pour un transfert de fichiers sécurisé, utilisez le service SFTP/FTPS dans Azure Storage Blob, les applications App Service et les applications de fonctions, au lieu d’utiliser le service FTP classique.

Remarque

Le chiffrement des données en transit est activé pour tout le trafic Azure qui transite entre les centres de données Azure. TLS v1.2 ou version ultérieure est activé sur la plupart des services Azure par défaut. Et certains services tels que Stockage Azure et Application Gateway peuvent appliquer TLS v1.2 ou version ultérieure côté serveur.

Implémentation Azure et contexte supplémentaire :

Conseils AWS : Appliquez un transfert sécurisé dans des services tels qu’Amazon S3, RDS et CloudFront, où une fonctionnalité de chiffrement native des données en transit est intégrée.

Appliquez HTTPS (par exemple, dans AWS Elastic Load Balancer) pour les services et applications web de charge de travail (côté serveur ou côté client, ou les deux) en vous assurant que tous les clients qui se connectent à vos ressources AWS utilisent TLS v1.2 ou version ultérieure.

Pour la gestion à distance des instances EC2, utilisez SSH (pour Linux) ou RDP/TLS (pour Windows) au lieu d’un protocole non chiffré. Pour un transfert de fichiers sécurisé, utilisez le service AWS Transfer SFTP ou FTPS au lieu d’un service FTP standard.

Remarque

Tout le trafic réseau entre les centres de données AWS est chiffré de manière transparente au niveau de la couche physique. Tout le trafic au sein d’un VPC et entre les VPC appairés entre les régions est chiffré de manière transparente au niveau de la couche réseau lors de l’utilisation des types d’instances Amazon EC2 pris en charge. TLS v1.2 ou version ultérieure est activé sur la plupart des services AWS par défaut. Et certains services tels que AWS Load Balancer peuvent appliquer TLS v1.2 ou version ultérieure côté serveur.

Implémentation AWS et contexte supplémentaire :

Conseils GCP : Appliquez un transfert sécurisé dans des services tels que Google Cloud Storage, où une fonctionnalité de chiffrement de données natives en transit est intégrée.

Appliquez le protocole HTTPS pour les charges de travail et services d’application web afin que tous les clients qui se connectent à vos ressources GCP utilisent tls (Transport Layer Security) v1.2 ou version ultérieure.

Pour la gestion à distance, Google Cloud Compute Engine utilise SSH (pour Linux) ou RDP/TLS (pour Windows) au lieu d’un protocole non chiffré. Pour un transfert de fichiers sécurisé, utilisez le service SFTP/FTPS dans des services tels que Google Cloud Big Query ou Cloud App Engine au lieu d’un service FTP standard.

Implémentation GCP et contexte supplémentaire :

Parties prenantes de la sécurité des clients (En savoir plus) :

Contrôle de sécurité : journalisation et détection des menaces

La journalisation et la détection des menaces couvrent les contrôles de détection des menaces sur le cloud et l’activation, la collecte et le stockage des journaux d’audit pour les services cloud, notamment l’activation des processus de détection, d’investigation et de correction avec des contrôles pour générer des alertes de haute qualité avec détection des menaces natives dans les services cloud ; il inclut également la collecte des journaux avec un service de supervision cloud, la centralisation de l’analyse de la sécurité avec un SIEM, une synchronisation de temps et une rétention des journaux.

LT-4 : Activer la journalisation réseau pour l’investigation de sécurité

ID des contrôles CIS v8 ID NIST SP 800-53 r4 ID PCI-DSS v3.2.1
8.2, 8.5, 8.6, 8.7, 13.6 AU-3, AU-6, AU-12, SI-4 10.8

Principe de sécurité : activez la journalisation pour vos services réseau afin de prendre en charge les enquêtes sur les incidents liés au réseau, la chasse aux menaces et la génération d’alertes de sécurité. Les journaux réseau peuvent inclure des journaux provenant de services réseau tels que le filtrage IP, le pare-feu réseau et d’application, le DNS, le monitoring des flux, etc.

Conseils Azure : Activez et collectez les journaux de ressources de groupe de sécurité réseau (NSG), les journaux de flux NSG, les journaux du Pare-feu Azure, les journaux WAF (Web Application Firewall), et les journaux des machines virtuelles via l’agent de collecte de données de trafic réseau pour l’analyse de sécurité, soutenir les enquêtes sur les incidents et la génération d’alertes de sécurité. Vous pouvez envoyer les journaux de flux à un espace de travail Log Analytics d'Azure Monitor, puis utiliser Traffic Analytics pour obtenir des analyses.

Collectez les journaux de requête DNS pour faciliter la corrélation d’autres données réseau.

Implémentation Azure et contexte supplémentaire :

Conseils AWS : activez et collectez des journaux réseau tels que les journaux de flux VPC, les journaux d'activité WAF et les journaux de requête du résolveur Route53 pour l'analyse de sécurité, le support des enquêtes sur les incidents, et la génération d'alertes de sécurité. Les journaux d’activité peuvent être exportés vers CloudWatch pour la surveillance, ou vers un compartiment de stockage S3 pour l’ingestion dans la solution Microsoft Sentinel pour analyse centralisée.

Implémentation AWS et contexte supplémentaire :

Conseils GCP : la plupart des journaux d’activité réseau sont disponibles via les journaux de flux DU VPC qui enregistrent un exemple de flux réseau envoyés et reçus par des ressources, y compris les instances utilisées comme machines virtuelles Google Compute, nœuds Kubernetes Engine. Ces journaux d’activité peuvent être utilisés pour la surveillance du réseau, l’analyse de la sécurité en temps réel et l’optimisation des dépenses.

Vous pouvez afficher les journaux de flux dans la journalisation cloud et exporter les journaux vers la destination prise en charge par l’exportation de journalisation cloud. Les journaux de flux sont agrégés par connexion à partir des machines virtuelles de Compute Engine et exportés en temps réel. En vous abonnant à Pub/Sub, vous pouvez analyser les logs de flux à l’aide des API de streaming en temps réel.

Remarque

Vous pouvez également utiliser la mise en miroir de paquets pour cloner le trafic des instances spécifiées dans votre réseau privé virtuel (VPC) et le transférer pour qu'il soit examiné. La mise en miroir de paquets capture toutes les données de trafic et de paquet, y compris les charges utiles et les en-têtes.

Implémentation GCP et contexte supplémentaire :

Parties prenantes de la sécurité des clients (En savoir plus) :

Contrôle de sécurité : sécurité réseau

La sécurité réseau couvre les contrôles permettant de sécuriser et de protéger les réseaux, notamment la sécurisation des réseaux virtuels, l’établissement de connexions privées, la prévention et l’atténuation des attaques externes et la sécurisation du DNS.

NS-1 : Établir des limites de segmentation du réseau

ID des contrôles CIS v8 ID NIST SP 800-53 r4 ID PCI-DSS v3.2.1
3.12, 13.4, 4.4 AC-4, SC-2, SC-7 1.1, 1.2, 1.3

Principe de sécurité : assurez-vous que votre déploiement de réseau virtuel s’aligne sur votre stratégie de segmentation d’entreprise définie dans le contrôle de sécurité GS-2. Toute charge de travail susceptible d’entraîner un risque plus élevé pour l’organisation doit être dans des réseaux virtuels isolés.

Exemples de charges de travail à haut risque :

  • Une application stockant ou traitant des données extrêmement sensibles.
  • Une application réseau externe accessible par le public ou les utilisateurs en dehors de votre organisation.
  • Une application utilisant une architecture non sécurisée ou contenant des vulnérabilités qui ne peuvent pas être facilement corrigées.

Pour améliorer votre stratégie de segmentation d’entreprise, limitez ou surveillez le trafic entre les ressources internes à l’aide de contrôles réseau. Pour des applications spécifiques bien définies (par exemple, une application à 3 niveaux), il peut s’agir d’une approche « refuser par défaut, autoriser par une exception » hautement sécurisée en restreignant les ports, les protocoles, la source et les adresses IP de destination du trafic réseau. Si vous avez de nombreux points de terminaison et applications qui interagissent les uns avec les autres, le blocage du trafic peut ne pas être adapté et vous ne pourrez peut-être surveiller que le trafic.

Conseils Azure : Créez un réseau virtuel (VNet) en tant qu’approche de segmentation fondamentale dans votre réseau Azure, afin que les ressources telles que les machines virtuelles puissent être déployées dans le réseau virtuel dans une limite de réseau. Pour segmenter davantage le réseau, vous pouvez créer des sous-réseaux au sein du réseau virtuel pour des sous-réseaux plus petits.

Utilisez des groupes de sécurité réseau (NSG) comme contrôle de couche réseau pour restreindre ou surveiller le trafic par port, protocole, adresse IP source ou adresse IP de destination. Reportez-vous à NS-7 : Simplifiez la configuration de la sécurité réseau pour utiliser le Renforcement adaptatif du réseau afin de recommander des règles de renforcement du groupe de sécurité réseau basées sur le renseignement sur les menaces et les résultats de l'analyse du trafic.

Vous pouvez également utiliser des groupes de sécurité d’application pour simplifier une configuration complexe. Au lieu de définir une stratégie en fonction d’adresses IP explicites dans des groupes de sécurité réseau, les groupes de sécurité d’application permettent de configurer la sécurité réseau comme un prolongement naturel de la structure d’une application, et donc de regrouper les machines virtuelles et définir des stratégies de sécurité réseau en fonction de ces groupes.

Implémentation Azure et contexte supplémentaire :

Conseils AWS : Créez un cloud privé virtuel (VPC) en tant qu’approche de segmentation fondamentale dans votre réseau AWS, afin que les ressources telles que les instances EC2 puissent être déployées dans le VPC au sein d’une limite de réseau. Pour segmenter davantage le réseau, vous pouvez créer des sous-réseaux à l’intérieur du VPC pour les sous-réseaux plus petits.

Pour les instances EC2, utilisez des groupes de sécurité comme pare-feu avec état pour restreindre le trafic par port, protocole, adresse IP source ou adresse IP de destination. Au niveau du sous-réseau DU VPC, utilisez la liste de contrôle d’accès réseau (NACL) comme pare-feu sans état pour avoir des règles explicites pour le trafic d’entrée et de sortie vers le sous-réseau.

Remarque

Pour contrôler le trafic du VPC, Internet et la passerelle NAT doivent être configurés pour garantir que le trafic depuis/vers Internet est restreint.

Implémentation AWS et contexte supplémentaire :

Conseils GCP : Créez un réseau de cloud privé virtuel (VPC) en tant qu’approche de segmentation fondamentale dans votre réseau GCP, de sorte que les ressources telles que les instances de machines virtuelles du moteur de calcul peuvent être déployées dans le réseau VPC au sein d’une limite réseau. Pour segmenter davantage le réseau, vous pouvez créer des sous-réseaux à l’intérieur du VPC pour les sous-réseaux plus petits.

Utilisez des règles de pare-feu VPC en tant que contrôle de couche réseau distribuée pour autoriser ou refuser les connexions à ou à partir de vos instances ciblées dans le réseau VPC, notamment les machines virtuelles, les clusters Google Kubernetes Engine (GKE) et les instances d’environnement flexibles du moteur d’application.

Vous pouvez également configurer des règles de pare-feu VPC pour cibler toutes les instances du réseau VPC, les instances avec une balise réseau correspondante ou les instances qui utilisent un compte de service spécifique, ce qui vous permet de regrouper des instances et de définir des stratégies de sécurité réseau basées sur ces groupes.

Implémentation GCP et contexte supplémentaire :

Parties prenantes de la sécurité des clients (En savoir plus) :

NS-2 : Sécuriser les services natifs cloud avec des contrôles réseau

ID des contrôles CIS v8 ID NIST SP 800-53 r4 ID PCI-DSS v3.2.1
3.12, 4.4 AC-4, SC-2, SC-7 1.1, 1.2, 1.3

Principe de sécurité : Sécuriser les services cloud en établissant un point d’accès privé pour les ressources. Vous devez également désactiver ou restreindre l’accès à partir de réseaux publics lorsque cela est possible.

Conseils Azure : Déployez des points de terminaison privés pour toutes les ressources Azure qui prennent en charge la fonctionnalité Private Link pour établir un point d’accès privé pour les ressources. L’utilisation de Private Link empêche le routage de la connexion privée via le réseau public.

Remarque

Certains services Azure peuvent également autoriser la communication privée via la fonctionnalité de point de terminaison de service, mais il est recommandé d’utiliser Azure Private Link pour un accès sécurisé et privé aux services hébergés sur la plateforme Azure.

Pour certains services, vous pouvez choisir de déployer l’intégration de réseau virtuel pour le service où vous pouvez restreindre le réseau virtuel pour établir un point d’accès privé pour le service.

Vous avez également la possibilité de configurer les règles de liste de contrôle d’accès réseau natives du service ou de désactiver simplement l’accès au réseau public pour bloquer l’accès à partir de réseaux publics.

Pour les machines virtuelles Azure, sauf s’il existe un cas d’usage fort, vous devez éviter d’affecter directement des adresses IP/sous-réseaux publiques à l’interface de machine virtuelle et utiliser plutôt des services de passerelle ou d’équilibreur de charge comme serveur frontal pour l’accès par le réseau public.

Implémentation Azure et contexte supplémentaire :

Conseils AWS : Déployer VPC PrivateLink pour toutes les ressources AWS qui prennent en charge la fonctionnalité PrivateLink, afin d’autoriser la connexion privée aux services ou services AWS pris en charge hébergés par d’autres comptes AWS (services de point de terminaison VPC). L’utilisation de PrivateLink empêche le routage de la connexion privée via le réseau public.

Pour certains services, vous pouvez choisir de déployer l’instance de service dans votre propre VPC pour isoler le trafic.

Vous avez également la possibilité de configurer les règles ACL natives du service pour bloquer l’accès à partir du réseau public. Par exemple, Amazon S3 vous permet de bloquer l’accès public au niveau du compartiment ou du compte.

Lorsque vous affectez des adresses IP à vos ressources de service dans votre VPC, sauf s’il existe un cas d’usage fort, vous devez éviter d’affecter directement des adresses IP/sous-réseaux publiques à vos ressources et utiliser plutôt des adresses IP/sous-réseaux privées.

Implémentation AWS et contexte supplémentaire :

Conseils GCP : Déployer les implémentations de VPC Private Google Access pour toutes les ressources GCP compatibles afin d'établir un point d'accès privé pour ces ressources. Ces options d’accès privé empêchent le routage de la connexion privée via le réseau public. Private Google Access a des instances de machine virtuelle qui ont uniquement des adresses IP internes (aucune adresse IP externe)

Pour certains services, vous pouvez choisir de déployer l’instance de service dans votre propre VPC pour isoler le trafic. Vous avez également la possibilité de configurer les règles ACL natives du service pour bloquer l’accès à partir du réseau public. Par exemple, le pare-feu du moteur d’application vous permet de contrôler le trafic réseau autorisé ou rejeté lors de la communication avec la ressource du moteur d’application. Le stockage cloud est une autre ressource dans laquelle vous pouvez appliquer la prévention de l’accès public sur des compartiments individuels ou au niveau de l’organisation.

Pour les machines virtuelles du moteur de calcul GCP, sauf s’il existe un cas d’usage fort, vous devez éviter d’affecter directement des adresses IP/sous-réseaux publics à l’interface de machine virtuelle et utiliser plutôt des services de passerelle ou d’équilibreur de charge comme serveur frontal pour l’accès par le réseau public.

Implémentation GCP et contexte supplémentaire :

Parties prenantes de la sécurité des clients (En savoir plus) :

NS-3 : Déployer le pare-feu à la périphérie du réseau d’entreprise

ID des contrôles CIS v8 ID NIST SP 800-53 r4 ID PCI-DSS v3.2.1
4.4, 4.8, 13.10 AC-4, SC-7, CM-7 1.1, 1.2, 1.3

Principe de sécurité : Déployez un pare-feu pour effectuer un filtrage avancé sur le trafic réseau vers et depuis des réseaux externes. Vous pouvez également utiliser des pare-feu entre les segments internes pour prendre en charge une stratégie de segmentation. Si nécessaire, utilisez des itinéraires personnalisés pour votre sous-réseau pour remplacer l’itinéraire système lorsque vous devez forcer le trafic réseau à passer par une appliance réseau à des fins de contrôle de sécurité.

Au minimum, bloquez les adresses IP incorrectes et les protocoles à haut risque connus, tels que la gestion à distance (par exemple, RDP et SSH) et les protocoles intranet (par exemple, SMB et Kerberos).
Conseils Azure : Utilisez le Pare-feu Azure pour fournir une restriction complète du trafic de couche application (par exemple, le filtrage d’URL) et/ou la gestion centralisée sur un grand nombre de segments d’entreprise ou de spokes (dans une topologie hub/spoke).

Si vous disposez d’une topologie de réseau complexe, telle qu’une configuration hub/spoke, vous devrez peut-être créer des itinéraires définis par l’utilisateur (UDR) pour vous assurer que le trafic suit l’itinéraire souhaité. Par exemple, vous avez la possibilité d’utiliser un UDR pour rediriger le trafic Internet de sortie via un pare-feu Azure spécifique ou une appliance virtuelle réseau.

Implémentation Azure et contexte supplémentaire :

Conseils AWS : Utilisez AWS Network Firewall pour fournir une restriction complète du trafic de couche application (comme le filtrage d’URL) et/ou la gestion centralisée sur un grand nombre de segments d’entreprise ou de spokes (dans une topologie hub/spoke).

Si vous disposez d’une topologie de réseau complexe, telle qu’une configuration hub/spoke, vous devrez peut-être créer des tables de routage VPC personnalisées pour vous assurer que le trafic passe par l’itinéraire souhaité. Par exemple, vous avez la possibilité d’utiliser un itinéraire personnalisé pour rediriger le trafic Internet de sortie via un pare-feu AWS spécifique ou une appliance virtuelle réseau.

Implémentation AWS et contexte supplémentaire :

Conseils GCP : Utilisez des stratégies de sécurité Google Cloud Armor pour fournir un filtrage et une protection de couche 7 des attaques web courantes. En outre, utilisez des règles de pare-feu VPC pour fournir des stratégies de trafic de couche réseau intégralement distribuées avec état et des stratégies de pare-feu pour la gestion centralisée sur un grand nombre de segments d’entreprise ou de spokes (dans une topologie hub/spoke).

Si vous avez une topologie de réseau complexe, telle qu’une configuration hub/spoke, créez des stratégies de pare-feu qui regroupent des règles de pare-feu et qui doivent être hiérarchiques afin qu’elles puissent être appliquées à plusieurs réseaux VPC.

Implémentation GCP et contexte supplémentaire :

Parties prenantes de la sécurité des clients (En savoir plus) :

NS-5 : Déployer la protection DDOS

ID des contrôles CIS v8 ID NIST SP 800-53 r4 ID PCI-DSS v3.2.1
13.10 SC-5, SC-7 1.1, 1.2, 1.3, 6.6

Principe de sécurité : Déployez une protection par déni de service distribué (DDoS) pour protéger votre réseau et vos applications contre les attaques.

Conseils Azure : DDoS Protection Basic est automatiquement activé pour protéger l’infrastructure de plateforme sous-jacente Azure (par exemple, Azure DNS) et ne nécessite aucune configuration des utilisateurs.

Pour des niveaux de protection plus élevés de vos attaques de couche application (couche 7), telles que les inondations HTTP et les inondations DNS, activez le plan de protection standard DDoS sur votre réseau virtuel pour protéger les ressources exposées aux réseaux publics.

Implémentation Azure et contexte supplémentaire :

Conseils AWS : AWS Shield Standard est automatiquement activé avec des atténuations standard pour protéger votre charge de travail contre les attaques DDoS (couche 3 et 4) courantes de réseau et de transport

Pour des niveaux de protection plus élevés de vos applications contre les attaques de couche application (couche 7) telles que les inondations HTTPS et les inondations DNS, activez aws Shield Advanced Protection sur Amazon EC2, Elastic Load Balancing (ELB), Amazon CloudFront, AWS Global Accelerator et Amazon Route 53.

Implémentation AWS et contexte supplémentaire :

Conseils GCP : Google Cloud Armor offre les options suivantes pour protéger les systèmes contre les attaques DDoS :

  • Protection DDoS réseau standard : protection de base permanente pour les équilibreurs de charge réseau, le transfert de protocole ou les machines virtuelles avec des adresses IP publiques.
  • Protection DDoS réseau avancée : protections supplémentaires pour les abonnés Managed Protection Plus qui utilisent des équilibreurs de charge réseau, un transfert de protocole ou des machines virtuelles avec des adresses IP publiques.
  • La protection DDoS réseau standard est toujours activée. Vous configurez une protection DDoS réseau avancée par région.

Implémentation GCP et contexte supplémentaire :

Parties prenantes de la sécurité des clients (En savoir plus) :

NS-6 : Déployer le pare-feu d’applications web

ID des contrôles CIS v8 ID NIST SP 800-53 r4 ID PCI-DSS v3.2.1
13.10 SC-7 1.1, 1.2, 1.3

Principe de sécurité : déployez un pare-feu d’applications web (WAF) et configurez les règles appropriées pour protéger vos applications et API web contre les attaques spécifiques à l’application.

Conseils Azure : Utilisez des fonctionnalités de pare-feu d’applications web (WAF) dans Azure Application Gateway, Azure Front Door et Azure Content Delivery Network (CDN) pour protéger vos applications, services et API contre les attaques de couche application à la périphérie de votre réseau.

Définissez votre WAF sur « détection » ou « mode de prévention », en fonction de vos besoins et du paysage des menaces.

Choisissez un ensemble de règles intégré, tel que les 10 principales vulnérabilités OWASP, et ajustez-le aux besoins de votre application.

Implémentation Azure et contexte supplémentaire :

Conseils AWS : Utilisez AWS Web Application Firewall (WAF) dans la distribution Amazon CloudFront, Amazon API Gateway, Application Load Balancer ou AWS AppSync pour protéger vos applications, services et API contre les attaques de couche application à la périphérie de votre réseau.

Utilisez AWS Managed Rules for WAF pour déployer des groupes de référence intégrés et le personnaliser en fonction des besoins de votre application pour les groupes de règles de cas utilisateur.

Pour simplifier le déploiement des règles WAF, vous pouvez également utiliser la solution AWS WAF Security Automations pour déployer automatiquement des règles AWS WAF prédéfinies qui filtrent les attaques web basées sur votre liste de contrôle d’accès web.

Implémentation AWS et contexte supplémentaire :

Conseils GCP : Utilisez Google Cloud Armor pour protéger vos applications et sites web contre les attaques par déni de service et web.

Utilisez des règles prêtes à l’emploi de Google Cloud Armor basées sur des normes du secteur pour atténuer les vulnérabilités courantes des applications web et fournir une protection contre OWASP Top 10.

Configurez vos règles WAF préconfigurées, chacune composée de plusieurs signatures provenant de ModSecurity Core Rules (CRS). Chaque signature correspond à une règle de détection d’attaque dans l’ensemble de règles.

Cloud Armor fonctionne conjointement avec des équilibreurs de charge externes et protège contre le déni de service distribué (DDoS) et d’autres attaques web, que les applications soient déployées sur Google Cloud, dans un déploiement hybride ou dans une architecture multicloud. Les stratégies de sécurité peuvent être configurées manuellement, avec des conditions de correspondance configurables et des actions dans une stratégie de sécurité. Cloud Armor propose également des stratégies de sécurité préconfigurées, qui couvrent divers cas d’usage.

La protection adaptative dans Cloud Armor vous permet d’empêcher, de détecter et de protéger vos applications et services contre les attaques distribuées L7 en analysant les modèles de trafic vers vos services principaux, en détectant et en alertant les attaques suspectes et en générant des règles WAF suggérées pour atténuer ces attaques. Ces règles peuvent être affinées pour répondre à vos besoins.

Implémentation GCP et contexte supplémentaire :

Parties prenantes de la sécurité des clients (En savoir plus) :

NS-8 : Détecter et désactiver les services et protocoles non sécurisés

ID des contrôles CIS v8 ID NIST SP 800-53 r4 ID PCI-DSS v3.2.1
4.4, 4.8 CM-2, CM-6, CM-7 4.1, A2.1, A2.2, A2.3

Principe de sécurité : détecter et désactiver les services et protocoles non sécurisés au niveau du système d’exploitation, de l’application ou de la couche de package logiciel. Déployez des contrôles de compensation si la désactivation des services et protocoles non sécurisés n’est pas possible.

Conseils Azure : Utilisez le classeur de protocole non sécurisé intégré de Microsoft Sentinel pour découvrir l’utilisation des services et protocoles non sécurisés tels que SSL/TLSv1, SSHv1, SMBv1, LM/NTLMv1, wDigest, les chiffrements faibles dans Kerberos et les liaisons LDAP non signées. Désactivez les services et protocoles non sécurisés qui ne répondent pas à la norme de sécurité appropriée.

Remarque

Si la désactivation des services ou protocoles non sécurisés n’est pas possible, utilisez des contrôles de compensation tels que le blocage de l’accès aux ressources via le groupe de sécurité réseau, le Pare-feu Azure ou le Pare-feu d’applications web Azure pour réduire la surface d’attaque.

Implémentation Azure et contexte supplémentaire :

Conseils AWS : activez les journaux de flux DE VPC et utilisez GuardDuty pour analyser les journaux de flux DE VPC pour identifier les services et protocoles non sécurisés possibles qui ne répondent pas à la norme de sécurité appropriée.

Si les journaux d’activité dans l’environnement AWS peuvent être transférés à Microsoft Sentinel, vous pouvez également utiliser le classeur de protocole non sécurisé intégré de Microsoft Sentinel pour découvrir l’utilisation des services et protocoles non sécurisés

Remarque

Si la désactivation des services ou protocoles non sécurisés n’est pas possible, utilisez des contrôles de compensation tels que le blocage de l’accès aux ressources via des groupes de sécurité, AWS Network Firewall, AWS Web Application Firewall pour réduire la surface d’attaque.

Implémentation AWS et contexte supplémentaire :

Conseils GCP : activez les journaux de flux DU VPC et utilisez BigQuery ou le Centre de commandes de sécurité pour analyser les journaux de flux DU VPC afin d’identifier les services et protocoles non sécurisés possibles qui ne répondent pas à la norme de sécurité appropriée.

Si les journaux d’activité dans l’environnement GCP peuvent être transférés à Microsoft Sentinel, vous pouvez également utiliser le classeur de protocole non sécurisé intégré de Microsoft Sentinel pour découvrir l’utilisation des services et protocoles non sécurisés. Vous pouvez également transférer des journaux d’activité vers Google Cloud Chronicle SIEM et SOAR et créer des règles personnalisées à la même fin.

Remarque

Si la désactivation des services ou protocoles non sécurisés n’est pas possible, utilisez des contrôles de compensation tels que le blocage de l’accès aux ressources via des règles et des stratégies de pare-feu VPC, ou Cloud Armor pour réduire la surface d’attaque.

Implémentation GCP et contexte supplémentaire :

Parties prenantes de la sécurité des clients (En savoir plus) :

NS-9 : Connecter le réseau local ou cloud de manière privée

ID des contrôles CIS v8 ID NIST SP 800-53 r4 ID PCI-DSS v3.2.1
12.7 CA-3, AC-17, AC-4 N/A

Principe de sécurité : utilisez des connexions privées pour sécuriser la communication entre différents réseaux, tels que les centres de données de fournisseurs de services cloud et l’infrastructure locale dans un environnement de colocalisation.

Conseils Azure : Pour une connectivité de site à site ou point à site légère, utilisez un réseau privé virtuel Azure (VPN) pour créer une connexion sécurisée entre votre site local ou votre appareil utilisateur final et le réseau virtuel Azure.

Pour les connexions hautes performances au niveau de l’entreprise, utilisez Azure ExpressRoute (ou Virtual WAN) pour connecter des centres de données Azure et une infrastructure locale dans un environnement de colocalisation.

Lors de la connexion de deux réseaux virtuels Azure ou plus ensemble, utilisez l’appairage de réseaux virtuels. Le trafic réseau entre les réseaux virtuels appairés est privé, et conservé sur le réseau principal Azure.

Implémentation Azure et contexte supplémentaire :

Conseils AWS : Pour la connectivité site à site ou point à site, utilisez le VPN AWS pour créer une connexion sécurisée (lorsque la surcharge IPsec n’est pas un problème) entre votre site local ou votre appareil utilisateur final sur le réseau AWS.

Pour les connexions hautes performances au niveau de l’entreprise, utilisez AWS Direct Connect pour connecter des VPC et des ressources AWS à votre infrastructure locale dans un environnement de colocalisation.

Vous avez la possibilité d'utiliser l'appairage VPC ou la passerelle de transit pour établir la connectivité entre deux ou plusieurs VPC, au sein d'une même région ou entre différentes régions. Le trafic réseau entre le VPC appairé est privé, et est conservé sur le réseau principal AWS. Lorsque vous devez joindre plusieurs VPN pour créer un sous-réseau plat volumineux, vous avez également la possibilité d’utiliser le partage VPC.

Implémentation AWS et contexte supplémentaire :

Conseils GCP : Pour une connectivité de site à site légère ou point à site, utilisez le VPN Google Cloud.

Pour les connexions hautes performances au niveau de l’entreprise, utilisez Google Cloud Interconnect ou Partner Interconnect pour vous connecter aux VPN et ressources Google Cloud avec votre infrastructure locale dans un environnement de colocalisation.

Vous avez la possibilité d’utiliser l’appairage de réseau VPC ou le Centre de connectivité réseau pour établir la connectivité avec deux ou plusieurs VPC, ou entre régions. Le trafic réseau entre les VPC appairés est privé, et est conservé sur le réseau principal GCP. Lorsque vous devez joindre plusieurs VPC pour créer un sous-réseau plat volumineux, vous avez également la possibilité d’utiliser le VPN partagé

Implémentation GCP et contexte supplémentaire :

Parties prenantes de la sécurité des clients (En savoir plus) :