Recommandations en matière de sécurité des données

Cet article répertorie toutes les recommandations de sécurité des données 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 relatives aux données Azure

Azure Cosmos DB doit désactiver l’accès au réseau public

Description : la désactivation de l’accès au réseau public améliore la sécurité en vous assurant que votre compte Cosmos DB n’est pas exposé sur l’Internet public. La création de points de terminaison privés peut limiter l’exposition de votre compte Cosmos DB. Plus d’informations (Stratégie associée : Azure Cosmos DB doit désactiver l’accès au réseau public).

Gravité : moyenne

(Activer si nécessaire) Les comptes Azure Cosmos DB doivent utiliser des clés gérées par le client pour chiffrer les données au repos

Description : Les recommandations d’utilisation des clés gérées par le client pour le chiffrement des données au repos ne sont pas évaluées par défaut, mais elles sont disponibles pour les scénarios applicables. Puisque les données sont chiffrées automatiquement à l’aide de clés gérées par la plateforme, l’utilisation de clés gérées par le client doit uniquement être appliquée lorsqu’elle est rendue obligatoire par des exigences de conformité ou de stratégie restrictive. Pour activer cette recommandation, accédez à votre Stratégie de sécurité pour l’étendue applicable et mettez à jour le paramètre Effet de la stratégie correspondante afin d’auditer ou d’appliquer l’utilisation des clés gérées par le client. Pour en savoir plus, consultez Gérer les stratégies de sécurité. Utilisez des clés gérées par le client pour gérer le chiffrement au repos de votre compte Azure Cosmos DB. Par défaut, les données sont chiffrées au repos avec des clés gérées par le service, mais des clés gérées par le client (CMK) sont généralement requises pour répondre aux normes de conformité réglementaire. Les CMK permettent de chiffrer les données avec une clé Azure Key Vault que vous avez créée et dont vous êtes le propriétaire. Vous avez le contrôle total et la responsabilité du cycle de vie des clés, notamment leur permutation et leur gestion. Pour en savoir plus sur le chiffrement par clés gérées par le client, consultez https://aka.ms/cosmosdb-cmk. (Stratégie associée : Les comptes Azure Cosmos DB doivent utiliser des clés gérées par le client pour chiffrer les données au repos.

Gravité : faible

(Activer si nécessaire) Les espaces de travail Azure Machine Learning doivent être chiffrés avec une clé gérée par le client (CMK)

Description : Les recommandations d’utilisation des clés gérées par le client pour le chiffrement des données au repos ne sont pas évaluées par défaut, mais elles sont disponibles pour les scénarios applicables. Puisque les données sont chiffrées automatiquement à l’aide de clés gérées par la plateforme, l’utilisation de clés gérées par le client doit uniquement être appliquée lorsqu’elle est rendue obligatoire par des exigences de conformité ou de stratégie restrictive. Pour activer cette recommandation, accédez à votre Stratégie de sécurité pour l’étendue applicable et mettez à jour le paramètre Effet de la stratégie correspondante afin d’auditer ou d’appliquer l’utilisation des clés gérées par le client. Pour en savoir plus, consultez Gérer les stratégies de sécurité. Gérez le chiffrement au repos des données de votre espace de travail Azure Machine Learning à l’aide de clés gérées par le client (CMK). Par défaut, les données client sont chiffrées avec des clés gérées par le service, mais des CMK sont généralement requises pour répondre aux normes de conformité réglementaire. Les CMK permettent de chiffrer les données avec une clé Azure Key Vault que vous avez créée et dont vous êtes le propriétaire. Vous avez le contrôle total et la responsabilité du cycle de vie des clés, notamment leur permutation et leur gestion. Pour en savoir plus sur le chiffrement par clés gérées par le client, consultez https://aka.ms/azureml-workspaces-cmk. (Stratégie associée : Les espaces de travail Azure Machine Learning doivent être chiffrés avec une clé gérée par le client (CMK)).

Gravité : faible

Azure SQL Database doit exécuter TLS version 1.2 ou ultérieure

Description : La définition de la version TLS sur la version 1.2 ou ultérieure améliore la sécurité en garantissant que votre base de données Azure SQL est accessible uniquement à partir de clients utilisant TLS 1.2 ou version ultérieure. L’utilisation de versions de TLS inférieures à 1.2 n’est pas recommandée, car elles ont des vulnérabilités de sécurité bien documentées. (Stratégie associée : Azure SQL Database doit exécuter TLS version 1.2 ou ultérieure).

Gravité : moyenne

Azure SQL Managed Instances doit désactiver l’accès au réseau public

Description : La désactivation de l’accès au réseau public (point de terminaison public) sur Azure SQL Managed Instances améliore la sécurité en garantissant qu’elles ne peuvent être accessibles qu’à partir de leurs réseaux virtuels ou via des points de terminaison privés. En savoir plus sur l’accès au réseau public. (Stratégie associée : Azure SQL Managed Instances doit désactiver l’accès au réseau public).

Gravité : moyenne

Les comptes Cosmos DB doivent utiliser une liaison privée

Description : Azure Private Link vous permet de connecter votre réseau virtuel aux services Azure sans adresse IP publique à la source ou à la destination. La plateforme Private Link gère la connectivité entre le consommateur et les services sur le réseau principal Azure. Lorsque les points de terminaison privés sont mappés à votre compte Cosmos DB, les risques de fuite de données sont réduits. En savoir plus sur les liaisons privées. (Stratégie associée : les comptes Cosmos DB doivent utiliser une liaison privée).

Gravité : moyenne

(Activer si nécessaire) Les serveurs MySQL doivent utiliser des clés gérées par le client pour chiffrer les données au repos

Description : Les recommandations d’utilisation des clés gérées par le client pour le chiffrement des données au repos ne sont pas évaluées par défaut, mais elles sont disponibles pour les scénarios applicables. Puisque les données sont chiffrées automatiquement à l’aide de clés gérées par la plateforme, l’utilisation de clés gérées par le client doit uniquement être appliquée lorsqu’elle est rendue obligatoire par des exigences de conformité ou de stratégie restrictive. Pour activer cette recommandation, accédez à votre Stratégie de sécurité pour l’étendue applicable et mettez à jour le paramètre Effet de la stratégie correspondante afin d’auditer ou d’appliquer l’utilisation des clés gérées par le client. Pour en savoir plus, consultez Gérer les stratégies de sécurité. Utilisez des clés gérées par le client pour gérer le chiffrement au repos de vos serveurs MySQL. Par défaut, les données sont chiffrées au repos avec des clés gérées par le service, mais des clés gérées par le client (CMK) sont généralement requises pour répondre aux normes de conformité réglementaire. Les CMK permettent de chiffrer les données avec une clé Azure Key Vault que vous avez créée et dont vous êtes le propriétaire. Vous avez le contrôle total et la responsabilité du cycle de vie des clés, notamment leur permutation et leur gestion. (Stratégie associée : La protection des données de votre propre clé doit être activée pour les serveurs MySQL.

Gravité : faible

(Activer si nécessaire) Les serveurs PostgreSQL doivent utiliser des clés gérées par le client pour chiffrer les données au repos

Description : Les recommandations d’utilisation des clés gérées par le client pour le chiffrement des données au repos ne sont pas évaluées par défaut, mais elles sont disponibles pour les scénarios applicables. Puisque les données sont chiffrées automatiquement à l’aide de clés gérées par la plateforme, l’utilisation de clés gérées par le client doit uniquement être appliquée lorsqu’elle est rendue obligatoire par des exigences de conformité ou de stratégie restrictive. Pour activer cette recommandation, accédez à votre Stratégie de sécurité pour l’étendue applicable et mettez à jour le paramètre Effet de la stratégie correspondante afin d’auditer ou d’appliquer l’utilisation des clés gérées par le client. Pour en savoir plus, consultez Gérer les stratégies de sécurité. Utilisez des clés gérées par le client pour gérer le chiffrement au repos de vos serveurs PostgreSQL. Par défaut, les données sont chiffrées au repos avec des clés gérées par le service, mais des clés gérées par le client (CMK) sont généralement requises pour répondre aux normes de conformité réglementaire. Les CMK permettent de chiffrer les données avec une clé Azure Key Vault que vous avez créée et dont vous êtes le propriétaire. Vous avez le contrôle total et la responsabilité du cycle de vie des clés, notamment leur permutation et leur gestion. (Stratégie associée : L’activation de votre propre protection des données clés doit être activée pour les serveurs PostgreSQL.

Gravité : faible

(Activer si nécessaire) Les instances managées SQL doivent utiliser des clés gérées par le client pour chiffrer les données au repos

Description : Les recommandations d’utilisation des clés gérées par le client pour le chiffrement des données au repos ne sont pas évaluées par défaut, mais elles sont disponibles pour les scénarios applicables. Puisque les données sont chiffrées automatiquement à l’aide de clés gérées par la plateforme, l’utilisation de clés gérées par le client doit uniquement être appliquée lorsqu’elle est rendue obligatoire par des exigences de conformité ou de stratégie restrictive. Pour activer cette recommandation, accédez à votre Stratégie de sécurité pour l’étendue applicable et mettez à jour le paramètre Effet de la stratégie correspondante afin d’auditer ou d’appliquer l’utilisation des clés gérées par le client. Pour en savoir plus, consultez Gérer les stratégies de sécurité. L’implémentation de TDE (Transparent Data Encryption) avec votre propre clé vous offre les avantages suivants : transparence et contrôle améliorés sur le protecteur TDE, sécurité renforcée avec un service externe HSM et promotion de la séparation des tâches. Cette recommandation s’applique aux organisations ayant une exigence de conformité associée. (Stratégie associée : Les instances managées SQL doivent utiliser des clés gérées par le client pour chiffrer les données au repos).

Gravité : faible

(Activer si nécessaire) Les serveurs SQL doivent utiliser des clés gérées par le client pour chiffrer les données au repos

Description : Les recommandations d’utilisation des clés gérées par le client pour le chiffrement des données au repos ne sont pas évaluées par défaut, mais elles sont disponibles pour les scénarios applicables. Puisque les données sont chiffrées automatiquement à l’aide de clés gérées par la plateforme, l’utilisation de clés gérées par le client doit uniquement être appliquée lorsqu’elle est rendue obligatoire par des exigences de conformité ou de stratégie restrictive. Pour activer cette recommandation, accédez à votre Stratégie de sécurité pour l’étendue applicable et mettez à jour le paramètre Effet de la stratégie correspondante afin d’auditer ou d’appliquer l’utilisation des clés gérées par le client. Pour en savoir plus, consultez Gérer les stratégies de sécurité. L’implémentation de TDE (Transparent Data Encryption) avec votre propre clé vous offre les avantages suivants : transparence et contrôle améliorés sur le protecteur TDE, sécurité renforcée avec un service externe HSM et promotion de la séparation des tâches. Cette recommandation s’applique aux organisations ayant une exigence de conformité associée. (Stratégie associée : Les serveurs SQL doivent utiliser des clés gérées par le client pour chiffrer les données au repos.

Gravité : faible

(Activer si nécessaire) Les comptes de stockage doivent utiliser la clé gérée par le client (CMK) pour le chiffrement

Description : Les recommandations d’utilisation des clés gérées par le client pour le chiffrement des données au repos ne sont pas évaluées par défaut, mais elles sont disponibles pour les scénarios applicables. Puisque les données sont chiffrées automatiquement à l’aide de clés gérées par la plateforme, l’utilisation de clés gérées par le client doit uniquement être appliquée lorsqu’elle est rendue obligatoire par des exigences de conformité ou de stratégie restrictive. Pour activer cette recommandation, accédez à votre Stratégie de sécurité pour l’étendue applicable et mettez à jour le paramètre Effet de la stratégie correspondante afin d’auditer ou d’appliquer l’utilisation des clés gérées par le client. Pour en savoir plus, consultez Gérer les stratégies de sécurité. Sécurisez votre compte de stockage avec une plus grande flexibilité en utilisant des clés gérées par le client (clés CMK). Quand vous spécifiez une clé CMK, cette clé est utilisée pour protéger et contrôler l’accès à la clé qui chiffre vos données. L’utilisation de clés CMK fournit des fonctionnalités supplémentaires permettant de contrôler la permutation de la clé de chiffrement de clé ou d’effacer des données par chiffrement. (Stratégie associée : Les comptes de stockage doivent utiliser la clé gérée par le client (CMK) pour le chiffrement).

Gravité : faible

Tous les types de protection des menaces avancées doivent être activés dans les paramètres de sécurité avancée des données de SQL Managed Instance

Description : il est recommandé d’activer tous les types de protection avancée contre les menaces sur vos instances managées SQL. L’activation de tous les types offre une protection contre l’injection SQL, les vulnérabilités de base de données et toute autre activité anormale. (Aucune stratégie associée)

Gravité : moyenne

Tous les types de protection des menaces avancée doivent être activés dans les paramètres de sécurité avancée des données du serveur SQL

Description : il est recommandé d’activer tous les types de protection avancée contre les menaces sur vos serveurs SQL. L’activation de tous les types offre une protection contre l’injection SQL, les vulnérabilités de base de données et toute autre activité anormale. (Aucune stratégie associée)

Gravité : moyenne

Les services Gestion des API doivent utiliser un réseau virtuel

Description : Le déploiement d’Azure Réseau virtuel offre une sécurité renforcée, une isolation et vous permet de placer votre service Gestion des API dans un réseau routable non Internet auquel vous contrôlez l’accès. Ces réseaux peuvent ensuite être connectés à vos réseaux locaux au moyen de différentes technologies VPN, ce qui permet d’accéder à vos services back-end au sein du réseau et/ou localement. Le portail des développeurs et la passerelle API peuvent être configurés pour être accessibles sur Internet ou uniquement au sein du réseau virtuel. (Stratégie associée : Gestion des API services doivent utiliser un réseau virtuel).

Gravité : moyenne

App Configuration doit utiliser une liaison privée

Description : Azure Private Link vous permet de connecter votre réseau virtuel aux services Azure sans adresse IP publique à la source ou à la destination. La plateforme de la liaison privée gère la connectivité entre le consommateur et les services sur le réseau principal Azure. En mappant des points de terminaison privés à vos instances de configuration d’application plutôt qu’à l’ensemble du service, vous êtes également protégé contre les risques de fuite de données. Pour en savoir plus, rendez-vous à l’adresse suivante : https://aka.ms/appconfig/private-endpoint. (Stratégie associée : App Configuration doit utiliser une liaison privée).

Gravité : moyenne

La conservation des audits pour les serveurs SQL Server doit être définie sur au moins 90 jours

Description : Auditer les serveurs SQL configurés avec une période de rétention d’audit inférieure à 90 jours. (Stratégie associée : Les serveurs SQL doivent être configurés avec une période de conservation d’audit de 90 jours au moins.)

Gravité : faible

L’audit sur SQL Server doit être activé

Description : activez l’audit sur votre serveur SQL Server pour suivre les activités de base de données sur toutes les bases de données sur le serveur et les enregistrer dans un journal d’audit. (Stratégie associée : L’audit sur SQL Server doit être activé).

Gravité : faible

L’approvisionnement automatique de l’agent Log Analytics doit être activé sur les abonnements

Description : Pour surveiller les vulnérabilités et menaces de sécurité, Microsoft Defender pour le cloud collecte des données à partir de vos machines virtuelles Azure. Les données sont collectées par l’agent Log Analytics, auparavant appelé Microsoft Monitoring Agent (MMA). Cet agent lit divers journaux d’événements et configurations liés à la sécurité de la machine, puis copie les données dans votre espace de travail Log Analytics à des fins d’analyse. Nous vous recommandons d’activer l’approvisionnement automatique pour déployer automatiquement l’agent sur toutes les machines virtuelles Azure prises en charge et sur toutes celles qui sont créées. (Stratégie associée : L’approvisionnement automatique de l’agent Log Analytics doit être activé sur votre abonnement.

Gravité : faible

Azure Cache pour Redis doit se trouver dans un réseau virtuel

Description : le déploiement d’Azure Réseau virtuel (VNet) offre une sécurité et une isolation améliorées pour vos Azure Cache pour Redis, ainsi que des sous-réseaux, des stratégies de contrôle d’accès et d’autres fonctionnalités pour restreindre davantage l’accès. Lorsqu’une instance de Cache Azure pour Redis est configurée avec un réseau virtuel, elle n’est pas adressable publiquement et est accessible uniquement à partir de machines virtuelles et d’applications sur le réseau virtuel. (Stratégie associée : Azure Cache pour Redis devez résider dans un réseau virtuel).

Gravité : moyenne

Un administrateur Azure Active Directory doit être approvisionné pour Azure Database pour MySQL

Description : Provisionnez un administrateur Azure AD pour votre Azure Database pour MySQL pour activer l’authentification Azure AD. L’authentification Azure AD permet la gestion simplifiée des autorisations et la gestion centralisée des identités des utilisateurs de base de données et d’autres services Microsoft (stratégie associée : un administrateur Azure Active Directory doit être approvisionné pour les serveurs MySQL).

Gravité : moyenne

Azure Database pour PostgreSQL doit avoir un administrateur Azure Active Directory approvisionné

Description : Provisionnez un administrateur Azure AD pour votre Azure Database pour PostgreSQL pour activer l’authentification Azure AD. L’authentification Azure AD permet une gestion simplifiée des autorisations et une gestion centralisée des utilisateurs de bases de données et d’autres services Microsoft
(Stratégie associée : Un administrateur Azure Active Directory doit être approvisionné pour les serveurs PostgreSQL.

Gravité : moyenne

Les comptes Azure Cosmos DB doivent avoir des règles de pare-feu

Description : Les règles de pare-feu doivent être définies sur vos comptes Azure Cosmos DB pour empêcher le trafic de sources non autorisées. Les comptes qui possèdent au moins une règle IP définie avec le filtre de réseau virtuel activé sont considérés comme conformes. Les comptes qui désactivent l’accès public sont également jugés conformes. (Stratégie associée : Les comptes Azure Cosmos DB doivent avoir des règles de pare-feu.

Gravité : moyenne

Les domaines Azure Event Grid doivent utiliser une liaison privée

Description : Azure Private Link vous permet de connecter votre réseau virtuel aux services Azure sans adresse IP publique à la source ou à la destination. La plateforme de la liaison privée gère la connectivité entre le consommateur et les services sur le réseau principal Azure. En mappant les points de terminaison privés à vos domaines Event Grid plutôt qu’à l’ensemble du service, vous êtes également protégé contre les risques de fuite de données. Pour en savoir plus, rendez-vous à l’adresse suivante : https://aka.ms/privateendpoints. (Stratégie associée : Les domaines Azure Event Grid doivent utiliser une liaison privée).

Gravité : moyenne

Les rubriques Azure Event Grid doivent utiliser une liaison privée

Description : Azure Private Link vous permet de connecter votre réseau virtuel aux services Azure sans adresse IP publique à la source ou à la destination. La plateforme de la liaison privée gère la connectivité entre le consommateur et les services sur le réseau principal Azure. En mappant des points de terminaison privés à vos rubriques plutôt qu’à l’ensemble du service, vous êtes également protégé contre les risques de fuite de données. Pour en savoir plus, rendez-vous à l’adresse suivante : https://aka.ms/privateendpoints. (Stratégie associée : Les rubriques Azure Event Grid doivent utiliser une liaison privée).

Gravité : moyenne

Les espaces de travail Azure Machine Learning doivent utiliser un lien privé

Description : Azure Private Link vous permet de connecter votre réseau virtuel aux services Azure sans adresse IP publique à la source ou à la destination. La plateforme de la liaison privée gère la connectivité entre le consommateur et les services sur le réseau principal Azure. En mappant des points de terminaison privés à vos espaces de travail Azure Machine Learning plutôt qu’à l’ensemble du service, vous êtes également protégé contre les risques de fuite de données. Pour en savoir plus, rendez-vous à l’adresse suivante : https://aka.ms/azureml-workspaces-privatelink. (Stratégie associée : Les espaces de travail Azure Machine Learning doivent utiliser une liaison privée).

Gravité : moyenne

Azure SignalR Service doit utiliser une liaison privée

Description : Azure Private Link vous permet de connecter votre réseau virtuel aux services Azure sans adresse IP publique à la source ou à la destination. La plateforme de la liaison privée gère la connectivité entre le consommateur et les services sur le réseau principal Azure. En mappant des points de terminaison privés à vos ressources SignalR plutôt qu’à l’ensemble du service, vous êtes également protégé contre les risques de fuite de données. Pour en savoir plus, rendez-vous à l’adresse suivante : https://aka.ms/asrs/privatelink. (Stratégie associée : Azure SignalR Service doit utiliser une liaison privée).

Gravité : moyenne

Azure Spring Cloud doit utiliser l’injection de réseau

Description : Les instances Azure Spring Cloud doivent utiliser l’injection de réseau virtuel à des fins suivantes : 1. Isoler Azure Spring Cloud d’Internet. 2. Permettre à Azure Spring Cloud d’interagir avec des systèmes de centres de données locaux ou des services Azure d’autres réseaux virtuels. 3. Permettre aux clients de contrôler les communications réseau entrantes et sortantes pour Azure Spring Cloud. (Stratégie associée : Azure Spring Cloud doit utiliser l’injection de réseau).

Gravité : moyenne

Un administrateur Azure Active Directory doit être configuré sur les serveurs SQL

Description : Provisionnez un administrateur Azure AD pour votre serveur SQL pour activer l’authentification Azure AD. L’authentification Azure AD permet une gestion simplifiée des autorisations et une gestion centralisée des utilisateurs de bases de données et d’autres services Microsoft. (Stratégie associée : Un administrateur Azure Active Directory doit être approvisionné pour les serveurs SQL).

Gravité : élevée

Le mode d’authentification de l’espace de travail Azure Synapse doit être Azure Active Directory uniquement

Description : le mode d’authentification de l’espace de travail Azure Synapse doit être uniquement azure Active Directory uniquement les méthodes d’authentification Azure Active Directory améliorent la sécurité en garantissant que les espaces de travail Synapse nécessitent exclusivement des identités Azure AD pour l’authentification. Plus d’informations (Stratégie associée : Les espaces de travail Synapse doivent utiliser uniquement les identités Azure Active Directory pour l’authentification.

Gravité : moyenne

Les dépôts de code doivent avoir les résultats de l’analyse du code résolus

Description : Defender pour DevOps a détecté des vulnérabilités dans les référentiels de code. Pour améliorer la posture de sécurité des dépôts, il est vivement recommandé de corriger ces vulnérabilités. (Aucune stratégie associée)

Gravité : moyenne

Les dépôts de code doivent avoir les résultats de l’analyse Dependabot résolus

Description : Defender pour DevOps a détecté des vulnérabilités dans les référentiels de code. Pour améliorer la posture de sécurité des dépôts, il est vivement recommandé de corriger ces vulnérabilités. (Aucune stratégie associée)

Gravité : moyenne

Les dépôts de code doivent avoir les résultats de l’analyse de l’infrastructure en tant que code résolus

Description : Defender pour DevOps a trouvé l’infrastructure en tant que problèmes de configuration de sécurité du code dans les référentiels. Les problèmes indiqués ci-dessous ont été détectés dans des fichiers de modèle. Pour améliorer la posture de sécurité des ressources cloud associées, il est vivement recommandé de corriger ces problèmes. (Aucune stratégie associée)

Gravité : moyenne

Les dépôts de code doivent avoir les résultats de l’analyse des secrets résolus

Description : Defender pour DevOps a trouvé un secret dans les référentiels de code. Cela doit être corrigé immédiatement pour éviter une violation de la sécurité. Les secrets détectés dans les dépôts peuvent être divulgués ou découverts par des adversaires, ce qui peut compromettre une application ou d’un service. Pour Azure DevOps, l’outil Microsoft Security DevOps CredScan analyse uniquement les builds sur lesquelles il a été configuré pour s’exécuter. Par conséquent, les résultats peuvent ne pas refléter l’état complet des secrets dans vos dépôts. (Aucune stratégie associée)

Gravité : élevée

Les comptes Cognitive Services doivent activer le chiffrement des données

Description : cette stratégie audite tous les comptes Cognitive Services qui n’utilisent pas le chiffrement des données. Pour chaque compte avec stockage, vous devez activer le chiffrement des données avec une clé gérée par le client ou une clé gérée par Microsoft. (Stratégie associée : Les comptes Cognitive Services doivent activer le chiffrement des données).

Gravité : faible

Les comptes Cognitive Services doivent utiliser le stockage appartenant au client ou activer le chiffrement des données

Description : cette stratégie audite tout compte Cognitive Services qui n’utilise pas le stockage appartenant au client ni le chiffrement des données. Pour chaque compte Cognitive Services avec stockage, utilisez le stockage appartenant au client ou activez le chiffrement des données. S’aligne sur microsoft Cloud Security Benchmark. (Stratégie associée : Les comptes Cognitive Services doivent utiliser le stockage appartenant au client ou activer le chiffrement des données)

Gravité : faible

Les services Cognitive Services doivent utiliser une liaison privée

Description : Azure Private Link vous permet de connecter vos réseaux virtuels aux services Azure sans adresse IP publique à la source ou à la destination. La plateforme Azure Private Link gère la connectivité entre le consommateur et les services via le réseau principal Azure. En mappant les points de terminaison privés à Cognitive Services, vous réduisez le risque de fuite de données. En savoir plus sur les liaisons privées. (Stratégie associée : Cognitive Services doit utiliser une liaison privée).

Gravité : moyenne

Les journaux de diagnostic dans Azure Data Lake Store doivent être activés

Description : activez les journaux et conservez-les pendant un an. Permet de recréer les pistes d’activité à des fins d’investigation en cas d’incident de sécurité ou de compromission du réseau. (Stratégie associée : Les journaux de diagnostic dans Azure Data Lake Store doivent être activés).

Gravité : faible

Les journaux de diagnostic dans Data Lake Analytics doivent être activés

Description : activez les journaux et conservez-les pendant un an. Permet de recréer les pistes d’activité à des fins d’investigation en cas d’incident de sécurité ou de compromission du réseau. (Stratégie associée : Les journaux de diagnostic dans Data Lake Analytics doivent être activés).

Gravité : faible

La notification par e-mail pour les alertes à gravité élevée doit être activée

Description : Pour vous assurer que les personnes pertinentes de votre organisation sont averties lorsqu’il existe une violation de sécurité potentielle dans l’un de vos abonnements, activez Notifications par e-mail pour les alertes de gravité élevée dans Defender pour le cloud. (Stratégie associée : La notification par e-mail pour les alertes de gravité élevée doit être activée).

Gravité : faible

La notification par e-mail au propriétaire de l’abonnement pour les alertes à gravité élevée doit être activée

Description : Pour vous assurer que vos propriétaires d’abonnements sont avertis lorsqu’il existe une violation de sécurité potentielle dans leur abonnement, définissez Notifications par e-mail aux propriétaires d’abonnements pour les alertes de gravité élevée dans Defender pour le cloud. (Stratégie associée : La notification par e-mail au propriétaire de l’abonnement pour les alertes de gravité élevée doit être activée).

Gravité : moyenne

L’application de la connexion SSL doit être activée pour les serveurs de base de données MySQL

Description : Azure Database pour MySQL prend en charge la connexion de votre serveur Azure Database pour MySQL aux applications clientes à l’aide du protocole SSL (Secure Sockets Layer). L’application de connexions SSL entre votre serveur de base de données et vos applications clientes vous protège contre les « attaques de l’intercepteur » en chiffrant le flux de données entre le serveur et votre application. Cette configuration garantit que le protocole SSL est toujours activé pour l’accès à votre serveur de base de données. (Stratégie associée : Appliquer la connexion SSL doit être activée pour les serveurs de base de données MySQL.

Gravité : moyenne

L’application de la connexion SSL doit être activée pour les serveurs de base de données PostgreSQL

Description : Azure Database pour PostgreSQL prend en charge la connexion de votre serveur Azure Database pour PostgreSQL aux applications clientes à l’aide du protocole SSL (Secure Sockets Layer). L’application de connexions SSL entre votre serveur de base de données et vos applications clientes vous protège contre les « attaques de l’intercepteur » en chiffrant le flux de données entre le serveur et votre application. Cette configuration garantit que le protocole SSL est toujours activé pour l’accès à votre serveur de base de données. (Stratégie associée : L’application de la connexion SSL doit être activée pour les serveurs de base de données PostgreSQL.

Gravité : moyenne

Les vulnérabilités des applications de fonction doivent être résolues

Description : l’analyse des vulnérabilités du runtime pour les fonctions analyse vos applications de fonction pour détecter les vulnérabilités de sécurité et expose des résultats détaillés. La résolution des vulnérabilités peut améliorer significativement la sécurité de vos applications sans serveur et les protéger contre les attaques. (Aucune stratégie associée)

Gravité : élevée

La sauvegarde géoredondante doit être activée pour Azure Database for MariaDB

Description : Azure Database for MariaDB vous permet de choisir l’option de redondance pour votre serveur de base de données. Vous pouvez choisir un stockage de sauvegarde géoredondant. Dans ce cas, les données sont non seulement stockées dans la région qui héberge votre serveur, mais elles sont aussi répliquées dans une région appairée afin de proposer plusieurs possibilités de récupération en cas de défaillance régionale. La configuration du stockage géoredondant pour la sauvegarde est uniquement possible lors de la création d’un serveur. (Stratégie associée : La sauvegarde géoredondante doit être activée pour Azure Database for MariaDB.

Gravité : faible

La sauvegarde géoredondante doit être activée pour Azure Database pour MySQL

Description : Azure Database pour MySQL vous permet de choisir l’option de redondance pour votre serveur de base de données. Vous pouvez choisir un stockage de sauvegarde géoredondant. Dans ce cas, les données sont non seulement stockées dans la région qui héberge votre serveur, mais elles sont aussi répliquées dans une région appairée afin de proposer plusieurs possibilités de récupération en cas de défaillance régionale. La configuration du stockage géoredondant pour la sauvegarde est uniquement possible lors de la création d’un serveur. (Stratégie associée : La sauvegarde géoredondante doit être activée pour Azure Database pour MySQL).

Gravité : faible

La sauvegarde géoredondante doit être activée pour Azure Database pour PostgreSQL

Description : Azure Database pour PostgreSQL vous permet de choisir l’option de redondance pour votre serveur de base de données. Vous pouvez choisir un stockage de sauvegarde géoredondant. Dans ce cas, les données sont non seulement stockées dans la région qui héberge votre serveur, mais elles sont aussi répliquées dans une région appairée afin de proposer plusieurs possibilités de récupération en cas de défaillance régionale. La configuration du stockage géoredondant pour la sauvegarde est uniquement possible lors de la création d’un serveur. (Stratégie associée : La sauvegarde géoredondante doit être activée pour Azure Database pour PostgreSQL).

Gravité : faible

L’analyse du code doit être activée dans les dépôts GitHub

Description : GitHub utilise l’analyse du code pour analyser le code afin de rechercher des vulnérabilités de sécurité et des erreurs dans le code. L’analyse du code peut être utilisée pour rechercher, trier et hiérarchiser les correctifs pour les problèmes existants dans votre code. L’analyse du code peut également empêcher les développeurs d’introduire de nouveaux problèmes. Des analyses peuvent être planifiées pour des jours et heures spécifiques, ou être déclenchées lorsqu’un événement spécifique se produit dans le dépôt, tel qu’un envoi (push). Si l’analyse du code détecte une vulnérabilité ou une erreur potentielle dans le code, GitHub affiche une alerte dans le dépôt. Une vulnérabilité est un problème dans le code d’un projet qui pourrait être exploité pour endommager la confidentialité, l’intégrité ou la disponibilité du projet. (Aucune stratégie associée)

Gravité : moyenne

L’analyse Dependabot doit être activée dans les dépôts GitHub

Description : GitHub envoie des alertes Dependabot lorsqu’il détecte les vulnérabilités dans les dépendances de code qui affectent les dépôts. Une vulnérabilité est un problème dans le code d’un projet qui pourrait être exploité pour altérer la confidentialité, l’intégrité ou la disponibilité du projet ou d’autres projets qui utilisent son code. Les vulnérabilités varient en fonction du type, de la gravité et de la méthode d’attaque. Quand le code dépend d’un package qui présente une faille de sécurité, cette dépendance vulnérable peut entraîner une série de problèmes. (Aucune stratégie associée)

Gravité : moyenne

L’analyse des secrets doit être activée dans les dépôts GitHub

Description : GitHub analyse les référentiels pour les types connus de secrets afin d’empêcher l’utilisation frauduleuse de secrets qui ont été accidentellement validés dans les référentiels. L’analyse des secrets analyse l’intégralité de l’historique Git sur toutes les branches présentes dans le dépôt GitHub à la recherche de secrets. Les jetons et les clés privées qu’un fournisseur de services peut émettre pour l’authentification sont des exemples de secrets. Si un secret est archivé dans un dépôt, toute personne disposant d’un accès en lecture au dépôt peut utiliser le secret pour accéder au service externe avec ces privilèges. Les secrets doivent être stockés dans un emplacement dédié et sécurisé en dehors du dépôt du projet. (Aucune stratégie associée)

Gravité : élevée

Microsoft Defender pour les serveurs Azure SQL Database doit être activé

Description : Microsoft Defender pour SQL est un package unifié qui fournit des fonctionnalités de sécurité SQL avancées. Il inclut des fonctionnalités permettant d’exposer et de corriger des vulnérabilités potentielles de votre base de données, de détecter des activités anormales susceptibles d’indiquer une menace pour votre base de données, et de découvrir et classer des données sensibles.

Les protections de ce plan sont facturées comme indiqué dans la page plans Defender. Si vous n’avez pas de serveur Azure SQL Database dans cet abonnement, vous ne serez pas facturé. Si vous créez par la suite des serveurs Azure SQL Database sur cet abonnement, ceux-ci seront automatiquement protégés et la facturation commencera. En savoir plus sur les détails de tarification par région.

Pour en savoir plus, consultez Présentation de Microsoft Defender pour SQL. (Stratégie associée : Les serveurs Azure Defender pour Azure SQL Database doivent être activés).

Gravité : élevée

Microsoft Defender pour DNS doit être activé

Description : Microsoft Defender pour DNS fournit une couche supplémentaire de protection pour vos ressources cloud en surveillant en continu toutes les requêtes DNS à partir de vos ressources Azure. Defender pour DNS vous avertit des activités suspectes au niveau de la couche DNS. Pour en savoir plus, consultez Présentation de Microsoft Defender pour DNS. L’activation de ce plan Defender entraîne des frais. En savoir plus sur les détails de tarification par région sur la page de tarification de Defender pour le cloud : Defender pour le cloud tarification. (Aucune stratégie associée)

Gravité : élevée

Microsoft Defender pour les bases de données relationnelles open source doit être activé

Description : Microsoft Defender pour les bases de données relationnelles open source détecte des activités anormales indiquant des tentatives inhabituelles et potentiellement dangereuses d’accès ou d’exploitation de bases de données. Pour en savoir plus, consultez Présentation de Microsoft Defender pour les bases de données relationnelles open source.

L’activation de ce plan entraîne des frais de protection de vos bases de données relationnelles open source. Si vous n’avez pas de bases de données relationnelles open source dans cet abonnement, aucuns frais ne seront encourus. Si vous créez par la suite des bases de données relationnelles open source sur cet abonnement, celles-ci seront automatiquement protégées et la facturation commencera à ce moment-là. (Aucune stratégie associée)

Gravité : élevée

Microsoft Defender pour Resource Manager doit être activé

Description : Microsoft Defender pour Resource Manager surveille automatiquement les opérations de gestion des ressources dans votre organisation. Defender pour le cloud détecte les menaces et vous alerte sur les activités suspectes. Pour en savoir plus, consultez Présentation de Microsoft Defender pour Resource Manager. L’activation de ce plan Defender entraîne des frais. En savoir plus sur les détails de tarification par région sur la page de tarification de Defender pour le cloud : Defender pour le cloud tarification. (Aucune stratégie associée)

Gravité : élevée

Microsoft Defender pour SQL sur les ordinateurs doit être activé sur les espaces de travail

Description : Microsoft Defender pour serveurs met en place la détection des menaces et les défenses avancées pour vos machines Windows et Linux. Si vous activez ce plan Defender sur vos abonnements, mais pas sur vos espaces de travail, vous ne profitez pas de certaines fonctionnalités de Microsoft Defender pour les serveurs qui sont incluses dans le prix. Quand vous activez Microsoft Defender pour les serveurs sur un espace de travail, toutes les machines relevant de cet espace de travail sont facturées pour ce service, même si elles se trouvent dans un abonnement sur lequel les plans Defender ne sont pas activés. Vous devez donc également activer Microsoft Defender pour les serveurs sur l’abonnement afin que ces machines puissent tirer parti de l’accès juste-à-temps aux machines virtuelles, des contrôles d’application adaptatifs et des détections de réseau pour les ressources Azure. Pour en savoir plus, consultez Présentation de Microsoft Defender pour les serveurs. (Aucune stratégie associée)

Gravité : moyenne

Microsoft Defender pour les serveurs SQL sur les machines doit être activé

Description : Microsoft Defender pour SQL est un package unifié qui fournit des fonctionnalités de sécurité SQL avancées. Il inclut des fonctionnalités permettant d’exposer et de corriger des vulnérabilités potentielles de votre base de données, de détecter des activités anormales susceptibles d’indiquer une menace pour votre base de données, et de découvrir et classer des données sensibles.

L’application de cette recommandation entraîne des frais pour la protection de vos serveurs SQL. Si vous n’avez pas serveur SQL dans cet abonnement, cela n’entraîne pas de frais. Si vous créez des serveurs SQL sur des machines de cet abonnement à l’avenir, ceux-ci seront automatiquement protégés et des frais seront facturés à ce moment-là. En savoir plus sur Microsoft Defender pour les serveurs SQL sur les machines. (Stratégie associée : Azure Defender pour les serveurs SQL sur les machines doit être activé).

Gravité : élevée

Microsoft Defender pour SQL doit être activé pour les serveurs Azure SQL non protégés

Description : Microsoft Defender pour SQL est un package unifié qui fournit des fonctionnalités de sécurité SQL avancées. Il présente et corrige les vulnérabilités de base de données, et détecte les activités anormales susceptibles d’indiquer une menace pesant sur votre base de données. Microsoft Defender pour SQL est facturé comme indiqué dans les détails de tarification par région. (Stratégie associée : La sécurité avancée des données doit être activée sur vos serveurs SQL).

Gravité : élevée

Microsoft Defender pour SQL doit être activé pour les instances gérées SQL non protégées

Description : Microsoft Defender pour SQL est un package unifié qui fournit des fonctionnalités de sécurité SQL avancées. Il présente et corrige les vulnérabilités de base de données, et détecte les activités anormales susceptibles d’indiquer une menace pesant sur votre base de données. Microsoft Defender pour SQL est facturé comme indiqué dans les détails de tarification par région. (Stratégie associée : La sécurité avancée des données doit être activée sur SQL Managed Instance).

Gravité : élevée

Microsoft Defender pour le stockage doit être activé

Description : Microsoft Defender pour le stockage détecte des tentatives inhabituelles et potentiellement dangereuses d’accès ou d’exploitation des comptes de stockage.

Les protections de ce plan sont facturées comme indiqué dans la page plans Defender. Si vous n’avez pas de compte Stockage Azure dans cet abonnement, vous ne serez pas facturé. Si vous créez par la suite des comptes Stockage Azure sur cet abonnement, ceux-ci seront automatiquement protégés et la facturation commencera. En savoir plus sur les détails de tarification par région. Pour en savoir plus, consultez Présentation de Microsoft Defender pour le stockage. (Stratégie associée : Azure Defender pour stockage doit être activé).

Gravité : élevée

Network Watcher doit être activé

Description : Network Watcher est un service régional qui vous permet de surveiller et de diagnostiquer les conditions au niveau d’un scénario réseau dans, vers et depuis Azure. La supervision au niveau du scénario vous permet de diagnostiquer les problèmes au niveau du réseau de bout en bout. Les outils de visualisation et de diagnostic réseau disponibles avec Network Watcher vous aident à comprendre, diagnostiquer et obtenir des informations sur votre réseau dans Azure. (Stratégie associée : Network Watcher doit être activé).

Gravité : faible

Les connexions des points de terminaison privés sur Azure SQL Database doivent être activées

Description : Les connexions de point de terminaison privé appliquent une communication sécurisée en activant la connectivité privée à Azure SQL Database. (Stratégie associée : Les connexions de point de terminaison privé sur Azure SQL Database doivent être activées).

Gravité : moyenne

Le point de terminaison privé doit être activé pour les serveurs MariaDB

Description : Les connexions de point de terminaison privé appliquent une communication sécurisée en activant la connectivité privée à Azure Database for MariaDB. Configurez une connexion de point de terminaison privé pour autoriser l’accès uniquement au trafic provenant de réseaux connus et empêcher l’accès à partir de toutes les autres adresses IP, y compris dans Azure. (Stratégie associée : Le point de terminaison privé doit être activé pour les serveurs MariaDB).

Gravité : moyenne

Le point de terminaison privé doit être activé pour les serveurs MySQL

Description : Les connexions de point de terminaison privé appliquent une communication sécurisée en activant la connectivité privée à Azure Database pour MySQL. Configurez une connexion de point de terminaison privé pour autoriser l’accès uniquement au trafic provenant de réseaux connus et empêcher l’accès à partir de toutes les autres adresses IP, y compris dans Azure. (Stratégie associée : Le point de terminaison privé doit être activé pour les serveurs MySQL.

Gravité : moyenne

Le point de terminaison privé doit être activé pour les serveurs PostgreSQL

Description : Les connexions de point de terminaison privé appliquent une communication sécurisée en activant la connectivité privée à Azure Database pour PostgreSQL. Configurez une connexion de point de terminaison privé pour autoriser l’accès uniquement au trafic provenant de réseaux connus et empêcher l’accès à partir de toutes les autres adresses IP, y compris dans Azure. (Stratégie associée : Le point de terminaison privé doit être activé pour les serveurs PostgreSQL.

Gravité : moyenne

L’accès au réseau public sur Azure SQL Database doit être désactivé

Description : La désactivation de la propriété d’accès au réseau public améliore la sécurité en veillant à ce que votre base de données Azure SQL ne soit accessible qu’à partir d’un point de terminaison privé. Cette configuration interdit toutes les connexions visées par des règles de pare-feu basées sur l’adresse IP ou le réseau virtuel. (Stratégie associée : L’accès au réseau public sur Azure SQL Database doit être désactivé.

Gravité : moyenne

L’accès au réseau public doit être désactivé pour les comptes Cognitive Services

Description : cette stratégie audite n’importe quel compte Cognitive Services dans votre environnement avec l’accès au réseau public activé. L’accès au réseau public doit être désactivé afin que seules les connexions à partir des points de terminaison privés soient autorisées. (Stratégie associée : L’accès au réseau public doit être désactivé pour les comptes Cognitive Services.

Gravité : moyenne

L’accès au réseau public doit être désactivé pour les serveurs MariaDB

Description : désactivez la propriété d’accès au réseau public pour améliorer la sécurité et assurez-vous que votre base de données Azure Database for MariaDB est accessible uniquement à partir d’un point de terminaison privé. Cette configuration désactive strictement l’accès à partir de tout espace d’adressage public en dehors de la plage d’adresses IP Azure, et refuse toutes les connexions visées par des règles de pare-feu basées sur l’adresse IP ou le réseau virtuel. (Stratégie associée : L’accès au réseau public doit être désactivé pour les serveurs MariaDB).

Gravité : moyenne

L’accès au réseau public doit être désactivé pour les serveurs MySQL

Description : désactivez la propriété d’accès au réseau public pour améliorer la sécurité et assurez-vous que votre Azure Database pour MySQL est accessible uniquement à partir d’un point de terminaison privé. Cette configuration désactive strictement l’accès à partir de tout espace d’adressage public en dehors de la plage d’adresses IP Azure, et refuse toutes les connexions visées par des règles de pare-feu basées sur l’adresse IP ou le réseau virtuel. (Stratégie associée : L’accès au réseau public doit être désactivé pour les serveurs MySQL.

Gravité : moyenne

L’accès au réseau public doit être désactivé pour les serveurs PostgreSQL

Description : désactivez la propriété d’accès au réseau public pour améliorer la sécurité et assurez-vous que votre Azure Database pour PostgreSQL est accessible uniquement à partir d’un point de terminaison privé. Cette configuration désactive l’accès à partir de tout espace d’adressage public en dehors de la plage d’adresses IP Azure, et refuse toutes les connexions visées par des règles de pare-feu basées sur l’adresse IP ou le réseau virtuel. (Stratégie associée : L’accès au réseau public doit être désactivé pour les serveurs PostgreSQL.

Gravité : moyenne

Le cache Redis doit autoriser l’accès uniquement via SSL

Description : activez uniquement les connexions via SSL vers le cache Redis. L'utilisation de connexions sécurisées 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 : Seules les connexions sécurisées à votre Azure Cache pour Redis doivent être activées).

Gravité : élevée

Les résultats des vulnérabilités des bases de données SQL doivent être résolus

Description : l’évaluation des vulnérabilités SQL analyse votre base de données pour détecter les vulnérabilités de sécurité et expose les écarts des meilleures pratiques telles que les mauvaises configurations, les autorisations excessives et les données sensibles non protégées. La résolution des vulnérabilités détectées peut améliorer considérablement la posture de sécurité de votre base de données. En savoir plus (Stratégie associée : Les vulnérabilités sur vos bases de données SQL doivent être corrigées).

Gravité : élevée

L’évaluation des vulnérabilités doit être configurée pour les instances gérées SQL

Description : l’évaluation des vulnérabilités peut découvrir, suivre et vous aider à corriger les vulnérabilités potentielles de la base de données. (Stratégie associée : L’évaluation des vulnérabilités doit être activée sur SQL Managed Instance).

Gravité : élevée

Les résultats des vulnérabilités des serveurs SQL Server sur les machines doivent être résolus

Description : l’évaluation des vulnérabilités SQL analyse votre base de données pour détecter les vulnérabilités de sécurité et expose les écarts des meilleures pratiques telles que les mauvaises configurations, les autorisations excessives et les données sensibles non protégées. La résolution des vulnérabilités détectées peut améliorer considérablement la posture de sécurité de votre base de données. En savoir plus (Stratégie associée : Les vulnérabilités sur vos serveurs SQL sur l’ordinateur doivent être corrigées).

Gravité : élevée

Un administrateur Azure Active Directory doit être configuré sur les serveurs SQL

Description : Provisionnez un administrateur Azure AD pour votre serveur SQL pour activer l’authentification Azure AD. L’authentification Azure AD permet une gestion simplifiée des autorisations et une gestion centralisée des utilisateurs de bases de données et d’autres services Microsoft. (Stratégie associée : Un administrateur Azure Active Directory doit être approvisionné pour les serveurs SQL).

Gravité : élevée

L’évaluation des vulnérabilités doit être configurée pour les serveurs SQL

Description : l’évaluation des vulnérabilités peut découvrir, suivre et vous aider à corriger les vulnérabilités potentielles de la base de données. (Stratégie associée : L’évaluation des vulnérabilités doit être activée sur vos serveurs SQL).

Gravité : élevée

Le compte de stockage doit utiliser une connexion de liaison privée

Description : Les liaisons privées appliquent une communication sécurisée, en fournissant une connectivité privée au compte de stockage (stratégie associée : le compte de stockage doit utiliser une connexion de liaison privée).

Gravité : moyenne

Les comptes de stockage doivent être migrés vers de nouvelles ressources Azure Resource Manager

Description : Pour bénéficier de nouvelles fonctionnalités dans Azure Resource Manager, vous pouvez migrer des déploiements existants à partir du modèle de déploiement Classique. Resource Manager permet des améliorations de sécurité telles que : contrôle d’accès plus fort (RBAC), un meilleur audit, un déploiement basé sur ARM et une gouvernance, l’accès aux identités managées, l’accès au coffre de clés pour les secrets, l’authentification basée sur Azure AD et la prise en charge des balises et des groupes de ressources pour faciliter la gestion de la sécurité. En savoir plus (Stratégie associée : Les comptes de stockage doivent être migrés vers de nouvelles ressources Azure Resource Manager).

Gravité : faible

Les comptes de stockage doivent empêcher l’accès à la clé partagée

Description : Auditer l’exigence d’Azure Active Directory (Azure AD) pour autoriser les demandes de votre compte de stockage. Par défaut, les requêtes peuvent être autorisées soit avec des informations d’identification Azure Active Directory, soit à l’aide de la clé d’accès au compte pour l’autorisation avec clé partagée. Entre ces deux types d’autorisation, Azure AD offre une sécurité et une facilité d’utilisation supérieures par rapport à une clé partagée, et est recommandé par Microsoft. (Stratégie associée : stratégie)

Gravité : moyenne

Les comptes de stockage doivent utiliser des règles de réseau virtuel pour restreindre l’accès au réseau

Description : Protégez vos comptes de stockage contre les menaces potentielles à l’aide de règles de réseau virtuel comme méthode préférée au lieu du filtrage basé sur IP. La désactivation du filtrage basé sur IP empêche les IP publiques d’accéder à vos comptes de stockage. (Stratégie associée : Les comptes de stockage doivent restreindre l’accès réseau à l’aide de règles de réseau virtuel).

Gravité : moyenne

Les abonnements doivent avoir l’adresse e-mail d’un contact pour le signalement des problèmes de sécurité

Description : Pour vous assurer que les personnes concernées de votre organisation sont averties lorsqu’il existe une violation de sécurité potentielle dans l’un de vos abonnements, définissez un contact de sécurité pour recevoir Notifications par e-mail de Defender pour le cloud. (Stratégie associée : Les abonnements doivent avoir l’adresse e-mail d’un contact pour le signalement des problèmes de sécurité)

Gravité : faible

Transparent Data Encryption sur les bases de données SQL doit être activé

Description : Activez le chiffrement transparent des données pour protéger les données au repos et répondre aux exigences de conformité (Stratégie associée : Transparent Data Encryption sur les bases de données SQL doit être activée).

Gravité : faible

Les modèles VM Image Builder doivent utiliser une liaison privée

Description : Auditez les modèles Image Builder de machine virtuelle qui n’ont pas de réseau virtuel configuré. Lorsqu’un réseau virtuel n’est pas configuré, une adresse IP publique est créée et utilisée à la place, ce qui peut exposer directement des ressources à Internet et augmenter la surface d’attaque potentielle. (Stratégie associée : Les modèles De générateur d’images de machine virtuelle doivent utiliser une liaison privée).

Gravité : moyenne

Le pare-feu d’applications web (WAF) doit être activé pour Application Gateway

Description : Déployez le pare-feu d’applications web Azure (WAF) devant les applications web publiques pour une inspection supplémentaire du trafic entrant. Web Application Firewall (WAF) offre une protection centralisée de vos applications web contre les codes malveillants exploitant une faille de sécurité et les vulnérabilités telles que les injections de code SQL, le scripting inter-site, les exécutions de fichiers locales et à distance. Vous pouvez également restreindre l’accès à vos applications Web par pays/régions, plages d’adresses IP et autres paramètres http(s) par le biais de règles personnalisées. (Stratégie associée : Le pare-feu d’applications web (WAF) doit être activé pour Application Gateway.

Gravité : faible

Web Application Firewall (WAF) doit être activé pour le service Azure Front Door Service

Description : Déployez le pare-feu d’applications web Azure (WAF) devant les applications web publiques pour une inspection supplémentaire du trafic entrant. Web Application Firewall (WAF) offre une protection centralisée de vos applications web contre les codes malveillants exploitant une faille de sécurité et les vulnérabilités telles que les injections de code SQL, le scripting inter-site, les exécutions de fichiers locales et à distance. Vous pouvez également restreindre l’accès à vos applications Web par pays/régions, plages d’adresses IP et autres paramètres http(s) par le biais de règles personnalisées. (Stratégie associée : Web Application Firewall (WAF) doit être activé pour le service Azure Front Door Service?)

Gravité : faible

Recommandations relatives aux données AWS

Le retour sur trace doit être activé pour les clusters Amazon Aurora

Description : ce contrôle vérifie si les clusters Amazon Aurora ont activé le retour arrière. Les sauvegardes vous aident à récupérer plus rapidement à la suite d’un incident de sécurité. Elles renforcent également la résilience de vos systèmes. Le retour sur trace d’Aurora réduit le temps nécessaire à la récupération d’une base de données à un instant dans le passé. Cela ne nécessite pas de restauration de base de données. Pour plus d’informations sur le retour sur trace dans Aurora, consultez Retour sur trace d’un cluster de base de données Aurora dans le guide de l’utilisateur d’Amazon Aurora.

Gravité : moyenne

Les instantanés Amazon EBS ne doivent pas pouvoir être restaurés publiquement

Description : Les instantanés Amazon EBS ne doivent pas être restaurés publiquement par tout le monde, sauf autorisation explicite, pour éviter une exposition accidentelle des données. En outre, l’autorisation de modifier les configurations Amazon EBS doit être limitée aux seuls comptes AWS autorisés.

Gravité : élevée

Les définitions de tâche Amazon ECS doivent avoir des modes de mise en réseau et des définitions utilisateur sécurisés

Description : ce contrôle vérifie si une définition de tâche Amazon ECS active qui a le mode réseau hôte a également des définitions de conteneur utilisateur ou privilégiées. Le contrôle échoue pour les définitions de tâche qui ont un mode réseau hôte et des définitions de conteneur où privileged=false ou est vide et user=root ou est vide. Si une définition de tâche a des privilèges élevés, c’est parce que le client a spécifiquement choisi cette configuration. Ce contrôle vérifie l’escalade inattendue des privilèges lorsqu’une définition de tâche a activé la mise en réseau hôte, mais que le client n’a pas choisi de privilèges élevés.

Gravité : élevée

Les domaines Amazon Elasticsearch Service doivent chiffrer les données envoyées entre les nœuds

Description : ce contrôle vérifie si les domaines Amazon ES ont activé le chiffrement de nœud à nœud. Le protocole HTTPS (TLS) peut être utilisé pour empêcher les attaquants potentiels d’espionner ou de manipuler le trafic au moyen d’attaques de l’intercepteur ou d’autres attaques similaires. Seules les connexions chiffrées via HTTPS (TLS) doivent être autorisées. L’activation du chiffrement nœud à nœud pour les domaines Amazon ES garantit que les communications intraclusters sont chiffrées en transit. Cette configuration peut avoir un impact négatif sur les performances. Vous devez être conscient du compromis de performance et le tester avant d’activer cette option.

Gravité : moyenne

Le chiffrement au repos doit être activé sur les domaines Amazon Elasticsearch Service

Description : Il est important d’activer les chiffrements au reste des domaines Amazon ES pour protéger les données sensibles

Gravité : moyenne

La base de données Amazon RDS doit être chiffrée à l’aide d’une clé gérée par le client

Description : Cette vérification identifie les bases de données RDS chiffrées avec des clés KMS par défaut et non avec les clés gérées par le client. En tant que pratique de référence, utilisez des clés gérées par le client pour chiffrer les données de vos bases de données RDS et garder le contrôle de vos clés et données sur les charges de travail sensibles.

Gravité : moyenne

L’instance Amazon RDS doit être configurée avec les paramètres de sauvegarde automatique

Description : Cette vérification identifie les instances RDS, qui ne sont pas définies avec le paramètre de sauvegarde automatique. Si la sauvegarde automatique est définie, RDS crée un instantané de volume de stockage de votre instance de base de données, en sauvegardant l’intégralité de l’instance de base de données et pas seulement les bases de données individuelles, qui permettent une récupération à un instant dans le temps. La sauvegarde automatique se produit pendant la durée de la fenêtre de sauvegarde spécifiée et conserve les sauvegardes pendant une période limitée telle que définie dans la période de rétention. Il est recommandé de définir des sauvegardes automatiques pour vos serveurs RDS critiques qui aident dans le processus de restauration des données.

Gravité : moyenne

La journalisation d’audit doit être activée sur les clusters Amazon Redshift

Description : ce contrôle vérifie si un cluster Amazon Redshift a activé la journalisation d’audit. La journalisation d’audit Amazon Redshift fournit des informations supplémentaires sur les connexions et les activités des utilisateurs dans votre cluster. Ces données peuvent être stockées et sécurisées dans Amazon S3 et peuvent être utiles dans des audits et des enquêtes de sécurité. Pour plus d’informations, consultez Journalisation des audits de base de données dans le guide de la gestion du cluster d’Amazon Redshift.

Gravité : moyenne

Les instantanés automatiques doivent être activés sur les clusters Amazon Redshift

Description : ce contrôle vérifie si les clusters Amazon Redshift ont des instantanés automatisés activés. Il vérifie également si la période de rétention des instantanés est supérieure ou égale à sept. Les sauvegardes vous aident à récupérer plus rapidement à la suite d’un incident de sécurité. Elles renforcent la résilience de vos systèmes. Amazon Redshift prend des instantanés périodiques par défaut. Ce contrôle vérifie si les instantanés automatiques sont activés et conservés pendant au moins sept jours. Pour plus d’informations sur les instantanés automatisés Amazon Redshift, consultez captures instantanées automatisées dans le Guide de gestion des clusters Amazon Redshift.

Gravité : moyenne

Les clusters Amazon Redshift doivent interdire l’accès public

Description : Nous vous recommandons d’éviter l’accessibilité publique des clusters Amazon Redshift en évaluant le champ « publicAccessible » dans l’élément de configuration du cluster.

Gravité : élevée

Les mises à niveau automatiques vers les versions principales doivent être activées sur Amazon Redshift

Description : ce contrôle vérifie si les mises à niveau automatiques des versions principales sont activées pour le cluster Amazon Redshift. L’activation des mises à niveau automatiques vers les versions principales garantit que les mises à jour de version principale les plus récentes des clusters Amazon Redshift sont installées pendant la fenêtre de maintenance. Ces mises à jour peuvent inclure des correctifs de sécurité et des correctifs de bogues. Rester à jour dans l’installation des correctifs est une étape importante de la sécurisation des systèmes.

Gravité : moyenne

Les files d’attente Amazon SQS doivent être chiffrées au repos

Description : ce contrôle vérifie si les files d’attente Amazon SQS sont chiffrées au repos. Le chiffrement côté serveur vous permet de transmettre des données sensibles dans des files d’attente chiffrées. Pour protéger le contenu des messages dans les files d’attente, le chiffrement côté serveur utilise des clés gérées dans AWS KMS. Pour plus d’informations, consultez Chiffrement au repos dans le guide du développeur d’Amazon Simple Queue Service.

Gravité : moyenne

Un abonnement aux notifications d’événements RDS doit être configuré pour les événements de cluster critiques

Description : Ce contrôle vérifie si un abonnement à un événement Amazon RDS existe qui a des notifications activées pour le type de source suivant : paires clé-valeur de catégorie d’événement. DBCluster : [Maintenance et échec]. Les notifications d’événements RDS utilisent Amazon SNS pour vous tenir informé des modifications apportées à la disponibilité ou à la configuration de vos ressources RDS. Ces notifications permettent de réagir rapidement. Pour plus d’informations sur les notifications d’événements RDS, consultez Utilisation de la notification d’évènement Amazon RDS dans le Guide de l’utilisateur d’Amazon RDS.

Gravité : faible

Un abonnement aux notifications d’événements RDS doit être configuré pour les événements d’instance de base de données critiques

Description : Ce contrôle vérifie si un abonnement à un événement Amazon RDS existe avec des notifications activées pour le type de source suivant : paires clé-valeur de catégorie d’événement. DBInstance: [Maintenance, modification de configuration et échec]. Les notifications d’événements RDS utilisent Amazon SNS pour vous tenir informé des modifications apportées à la disponibilité ou à la configuration de vos ressources RDS. Ces notifications permettent de réagir rapidement. Pour plus d’informations sur les notifications d’événements RDS, consultez Utilisation de la notification d’évènement Amazon RDS dans le Guide de l’utilisateur d’Amazon RDS.

Gravité : faible

Un abonnement aux notifications d’événements RDS doit être configuré pour les événements de groupe de paramètres de base de données critiques

Description : Ce contrôle vérifie si un abonnement à un événement Amazon RDS existe avec des notifications activées pour le type de source suivant : paires clé-valeur de catégorie d’événement. DBParameterGroup : [« configuration », « modification »]. Les notifications d’événements RDS utilisent Amazon SNS pour vous tenir informé des modifications apportées à la disponibilité ou à la configuration de vos ressources RDS. Ces notifications permettent de réagir rapidement. Pour plus d’informations sur les notifications d’événements RDS, consultez Utilisation de la notification d’évènement Amazon RDS dans le Guide de l’utilisateur d’Amazon RDS.

Gravité : faible

Un abonnement aux notifications d’événements RDS doit être configuré pour les événements du groupe de sécurité de base de données critiques

Description : Ce contrôle vérifie si un abonnement à un événement Amazon RDS existe avec des notifications activées pour le type de source suivant : paires clé-valeur de catégorie d’événement. DBSecurityGroup : [Configuration, modification, échec]. Les notifications d’événements RDS utilisent Amazon SNS pour vous tenir informé des modifications apportées à la disponibilité ou à la configuration de vos ressources RDS. Ces notifications permettent de réagir rapidement. Pour plus d’informations sur les notifications d’événements RDS, consultez Utilisation de la notification d’évènement Amazon RDS dans le Guide de l’utilisateur d’Amazon RDS.

Gravité : faible

La journalisation des API REST et WebSocket d’API Gateway doit être activée

Description : ce contrôle vérifie si toutes les étapes d’une API REST Amazon API Gateway ou de l’API WebSocket ont été activées. Le contrôle échoue si la journalisation n’est pas activée pour toutes les méthodes d’une étape ou si le niveau de journalisation n’est ni ERROR ni INFO. Les journaux pertinents doivent être activés pour les étapes de l’API REST ou WebSocket d’API Gateway. La journalisation de l’exécution des API REST et WebSocket d’API Gateway fournit des enregistrements détaillés des demandes effectuées aux étapes des API REST et WebSocket d’API Gateway. Les étapes comprennent les réponses du serveur principal d’intégration d’API, les réponses de l’agent d’autorisation Lambda et le requestId pour les points de terminaison d’intégration AWS.

Gravité : moyenne

Les données du cache de l’API REST d’API Gateway doivent être chiffrées au repos

Description : ce contrôle vérifie si toutes les méthodes des étapes de l’API REST de la passerelle API api activées sont chiffrées. Le contrôle échoue si l’une des méthodes d’une étape de l’API REST d’API Gateway est configurée pour être mise en cache et que le cache n’est pas chiffré. Le chiffrement des données au repos réduit le risque d’accès aux données stockées sur le disque par un utilisateur non authentifié auprès d’AWS. Il ajoute un autre ensemble de contrôles d’accès pour limiter la capacité des utilisateurs non autorisés à accéder aux données. Par exemple, des autorisations d’API sont nécessaires pour déchiffrer les données avant de pouvoir les lire. Les caches de l’API REST d’API Gateway doivent être chiffrés au repos pour une couche de sécurité supplémentaire.

Gravité : moyenne

Les étapes de l’API REST d’API Gateway doivent être configurées pour utiliser des certificats SSL pour l’authentification du serveur principal

Description : ce contrôle vérifie si les étapes de l’API REST Amazon API Gateway ont configuré des certificats SSL. Les systèmes principaux utilisent ces certificats pour authentifier que les demandes entrantes proviennent d’API Gateway. Les étapes de l’API REST d’API Gateway doivent être configurées avec des certificats SSL pour permettre aux systèmes principaux d’authentifier que les demandes proviennent d’API Gateway.

Gravité : moyenne

Le suivi AWS X-Ray doit être activé pour les étapes de l’API REST d’API Gateway

Description : ce contrôle vérifie si le suivi actif AWS X-Ray est activé pour les phases de votre API REST Amazon API Gateway. Le suivi actif X-Ray permet de réagir plus rapidement aux changements de niveau de performance dans l’infrastructure sous-jacente. Les changements de niveau de performance peuvent entraîner un manque de disponibilité de l’API. Le suivi actif X-Ray fournit des métriques en temps réel concernant les demandes des utilisateurs qui passent par les opérations de l’API REST d’API Gateway et les services connectés.

Gravité : faible

API Gateway doit être associé à une liste de contrôle d’accès web AWS WAF

Description : ce contrôle vérifie si une étape de passerelle API utilise une liste de contrôle d’accès web (ACL) AWS WAF. Ce contrôle échoue si une ACL web AWS WAF n’est pas attachée à une étape d’API REST d’API Gateway. AWS WAF est un pare-feu d’applications web qui permet de protéger les applications web et les API contre les attaques. Il vous permet de configurer une ACL, c’est-à-dire un ensemble de règles qui autorisent, bloquent ou dénombrent les requêtes web en fonction de règles et de conditions de sécurité web personnalisables que vous définissez. Assurez-vous que votre étape d’API Gateway est associée à une ACL web AWS WAF pour la protéger contre les attaques malveillantes.

Gravité : moyenne

La journalisation des Application Load Balancers et des Classic Load Balancers doit être activée

Description : ce contrôle vérifie si l’équilibreur de charge d’application et l’équilibreur de charge classique ont activé la journalisation. Le contrôle échoue si access_logs.s3.enabled la valeur est false. L’équilibrage de charge élastique fournit des journaux d’accès qui capturent des informations détaillées sur les demandes envoyées à votre équilibreur de charge. Chaque journal contient des informations telles que l’heure à laquelle la demande a été reçue, l’adresse IP du client, les latences, les chemins des demandes et les réponses du serveur. Vous pouvez utiliser les journaux d’accès pour analyser les modèles de trafic et résoudre les problèmes. Pour plus d’informations, consultez Journaux d’accès pour votre Classic Load Balancer dans le guide de l’utilisateur pour équilibreurs de charge classiques.

Gravité : moyenne

Les volumes EBS attachés doivent être chiffrés au repos

Description : ce contrôle vérifie si les volumes EBS dans un état attaché sont chiffrés. Pour réussir cette vérification, les volumes EBS doivent être en cours d’utilisation et chiffrés. Si le volume EBS n’est pas attaché, il n’est pas soumis à cette vérification. Pour ajouter une couche supplémentaire de sécurité sur vos données sensibles dans les volumes EBS, vous devez activer le chiffrement EBS au repos. Le chiffrement Amazon EBS offre une solution de chiffrement simple pour vos ressources EBS qui ne nécessite pas la création, la maintenance et la sécurisation de votre propre infrastructure de gestion des clés. Il utilise les clés principales client (CMK) d’AWS KMS lors de la création de volumes et d’instantanés chiffrés. Pour en savoir plus sur le chiffrement Amazon EBS, consultez la page Chiffrement Amazon EBS dans le guide de l’utilisateur d’Amazon EC2 pour les instances Linux.

Gravité : moyenne

Les instances de réplication AWS Database Migration Service ne doivent pas être publiques

Description : Pour protéger vos instances répliquées contre les menaces. Une instance de réplication privée doit avoir une adresse IP privée à laquelle vous ne pouvez pas accéder en dehors du réseau de réplication. Une instance de réplication doit avoir une adresse IP privée lorsque les bases de données source et cible se trouvent sur le même réseau, et que le réseau est connecté au VPC de l’instance de réplication à l’aide d’un VPN, d’AWS Direct Connect ou d’un Peering VPC. Vous devez également vous assurer que l’accès à votre configuration d’instance AWS DMS est limité aux seuls utilisateurs autorisés. Pour ce faire, limitez les autorisations IAM des utilisateurs pour modifier les paramètres et les ressources AWS DMS.

Gravité : élevée

Les écouteurs de Classic Load Balancer doivent être configurés avec la terminaison HTTPS ou TLS

Description : ce contrôle vérifie si vos écouteurs Load Balancer classiques sont configurés avec https ou protocole TLS pour les connexions frontales (client à équilibreur de charge). Le contrôle s’applique si un Classic Load Balancer a des écouteurs. Si votre Classic Load Balancer n’a pas d’écouteur configuré, le contrôle ne signale aucun résultat. Le contrôle réussit si les écouteurs de Classic Load Balancer sont configurés avec TLS ou HTTPS pour les connexions frontales. Le contrôle échoue si l’écouteur n’est pas configuré avec TLS ou HTTPS pour les connexions frontales. Avant de commencer à utiliser un équilibreur de charge, vous devez ajouter un ou plusieurs écouteurs. Un écouteur est un processus qui utilise le protocole et le port configurés pour vérifier les demandes de connexion. Les écouteurs peuvent prendre en charge les protocoles HTTP et HTTPS/TLS. Vous devez toujours utiliser un écouteur HTTPS ou TLS afin que l’équilibreur de charge effectue le travail de chiffrement et de déchiffrement en transit.

Gravité : moyenne

Le drainage de connexion doit être activé pour les Classic Load Balancers

Description : ce contrôle vérifie si les équilibreurs de charge classiques ont activé le drainage de connexion. L’activation du drainage de connexion sur les équilibreurs de charge classiques garantit que l’équilibreur de charge cesse d’envoyer des requêtes à des instances qui annulent l’inscription ou ne sont pas saines. Il maintient les connexions existantes ouvertes. Cela s’avère utile pour les instances de groupes Mise à l'échelle automatique afin de s’assurer que les connexions ne sont pas interrompues brusquement.

Gravité : moyenne

AWS WAF doit être activé pour les distributions CloudFront

Description : ce contrôle vérifie si les distributions CloudFront sont associées à des ACL web AWS WAF ou AWS WAFv2. Le contrôle échoue si la distribution n’est pas associée à une ACL web. AWS WAF est un pare-feu d’applications web qui permet de protéger les applications web et les API contre les attaques. Il vous permet de configurer un ensemble de règles, appelé liste de contrôle d’accès web (ACL web), qui autorisent, bloquent ou dénombrent les requêtes web en fonction des règles et des conditions de sécurité web personnalisables que vous définissez. Assurez-vous que votre distribution CloudFront est associée à une ACL web AWS WAF pour contribuer à la protéger contre les attaques malveillantes.

Gravité : moyenne

La journalisation doit être activée pour les distributions CloudFront

Description : ce contrôle vérifie si la journalisation de l’accès au serveur est activée sur les distributions CloudFront. Le contrôle échoue si la journalisation des accès n’est pas activée pour une distribution. Les journaux d’accès CloudFront fournissent des informations détaillées sur chaque demande d’utilisateur reçue par CloudFront. Chaque journal contient des informations telles que la date et l’heure de réception de la demande, l’adresse IP du visiteur qui a effectué la demande, la source de la demande et le numéro de port de la demande du visiteur. Ces journaux sont utiles pour des applications telles que les audits de sécurité et d’accès et les enquêtes de forensique. Pour plus d’informations sur l’analyse des journaux d’accès, consultez Interroger les journaux Amazon CloudFront dans le Guide de l’utilisateur AmazonThéna.

Gravité : moyenne

Les distributions CloudFront doivent exiger le chiffrement en transit

Description : ce contrôle vérifie si une distribution Amazon CloudFront exige que les visionneuses utilisent le protocole HTTPS directement ou s’il utilise la redirection. Le contrôle échoue si ViewerProtocolPolicy est défini sur allow-all pour defaultCacheBehavior ou pour cacheBehaviors. Le protocole HTTPS (TLS) peut être utilisé pour empêcher les attaquants potentiels d’utiliser des attaques de l’intercepteur ou d’autres attaques similaires pour espionner ou manipuler le trafic. Seules les connexions chiffrées via HTTPS (TLS) doivent être autorisées. Le chiffrement des données en transit peut avoir un impact sur le niveau de performance. Vous devez tester votre application avec cette fonctionnalité pour comprendre le profil de performance et l’impact du protocole TLS.

Gravité : moyenne

Les journaux CloudTrail doivent être chiffrés au repos à l’aide des clés gérées par le client KMS

Description : Nous vous recommandons de configurer CloudTrail pour utiliser SSE-KMS. La configuration de CloudTrail pour utiliser SSE-KMS fournit davantage de contrôles de confidentialité sur les données de journal, car un utilisateur donné doit disposer de l’autorisation de lecture S3 sur le compartiment de journal correspondant et doit recevoir l’autorisation de déchiffrement de la stratégie CMK.

Gravité : moyenne

Les connexions aux clusters Amazon Redshift doivent être chiffrées en transit

Description : ce contrôle vérifie si les connexions aux clusters Amazon Redshift sont requises pour utiliser le chiffrement en transit. La vérification échoue si le paramètre de cluster Amazon Redshift require_SSL n’est pas défini sur 1. Le protocole TLS peut être utilisé pour empêcher les attaquants potentiels d’utiliser des attaques de l’intercepteur ou d’autres attaques similaires pour espionner ou manipuler le trafic. Seules les connexions chiffrées via TLS doivent être autorisées. Le chiffrement des données en transit peut avoir un impact sur le niveau de performance. Vous devez tester votre application avec cette fonctionnalité pour comprendre le profil de performance et l’impact du protocole TLS.

Gravité : moyenne

Les connexions aux domaines Elasticsearch doivent être chiffrées à l’aide de TLS 1.2

Description : ce contrôle vérifie si les connexions aux domaines Elasticsearch sont requises pour utiliser TLS 1.2. La vérification échoue si le domaine Elasticsearch TLSSecurityPolicy n’est pas Policy-Min-TLS-1-2-2019-07. Le protocole HTTPS (TLS) peut être utilisé pour empêcher les attaquants potentiels d’utiliser des attaques de l’intercepteur ou d’autres attaques similaires pour espionner ou manipuler le trafic. Seules les connexions chiffrées via HTTPS (TLS) doivent être autorisées. Le chiffrement des données en transit peut avoir un impact sur le niveau de performance. Vous devez tester votre application avec cette fonctionnalité pour comprendre le profil de performance et l’impact du protocole TLS. TLS 1.2 offre plusieurs améliorations en matière de sécurité par rapport aux versions précédentes de TLS.

Gravité : moyenne

La restauration à un instant dans le passé doit être activée pour les tables DynamoDB

Description : ce contrôle vérifie si la récupération à un point dans le temps (PITR) est activée pour une table Amazon DynamoDB. Les sauvegardes vous aident à récupérer plus rapidement à la suite d’un incident de sécurité. Elles renforcent également la résilience de vos systèmes. La restauration à un instant dans le passé de DynamoDB automatise les sauvegardes des tables DynamoDB. Elle réduit le temps de récupération après des opérations de suppression ou d’écriture accidentelles. Les tables DynamoDB pour lesquelles la restauration à un instant dans le passé est activée peuvent être restaurées à n’importe quel moment au cours des 35 derniers jours.

Gravité : moyenne

Le chiffrement par défaut EBS doit être activé

Description : ce contrôle vérifie si le chiffrement au niveau du compte est activé par défaut pour Amazon Elastic Block Store (Amazon EBS). Le contrôle échoue si le chiffrement au niveau du compte n’est pas activé. Lorsque le chiffrement est activé pour votre compte, les volumes Amazon EBS et les copies d’instantanés sont chiffrés au repos. Cela ajoute une autre couche de protection pour vos données. Pour plus d’informations, consultez Chiffrement par défaut dans le guide de l’utilisateur d’Amazon EC2 pour les instances Linux.

Les types d’instances suivants ne prennent pas en charge le chiffrement : R1, C1 et M1.

Gravité : moyenne

Les rapports d’intégrité améliorés doivent être activés pour les environnements Elastic Beanstalk

Description : ce contrôle vérifie si les rapports d’intégrité améliorés sont activés pour vos environnements AWS Elastic Beanstalk. Les rapports d’intégrité améliorés d’Elastic Beanstalk permettent de réagir plus rapidement aux changements de l’intégrité de l’infrastructure sous-jacente. Ces changements peuvent entraîner un manque de disponibilité de l’application. Le rapport d’intégrité amélioré d’Elastic Beanstalk fournit un descripteur d’état pour évaluer la gravité des problèmes identifiés et identifier les causes possibles à examiner. L’agent d’intégrité Elastic Beanstalk, inclus dans les images de machine Amazon (AMI) prises en charge, évalue les journaux et les métriques des instances EC2 de l’environnement.

Gravité : faible

Les mises à jour de la plateforme managée Elastic Beanstalk doivent être activées

Description : ce contrôle vérifie si les mises à jour de plateforme managée sont activées pour l’environnement Elastic Beanstalk. L’activation des mises à jour de la plateforme managée garantit que les derniers correctifs, mises à jour et fonctionnalités de la plateforme disponibles pour l’environnement sont installés. Rester à jour dans l’installation des correctifs est une étape importante de la sécurisation des systèmes.

Gravité : élevée

Elastic Load Balancer ne doit pas avoir de certificat ACM expiré ou arrivant à expiration dans les 90 jours.

Description : Cette vérification identifie les équilibreurs de charge élastiques (ELB) qui utilisent des certificats ACM expirés ou arrivant à expiration dans 90 jours. AWS Certificate Manager (ACM) est l’outil préféré pour provisionner, gérer et déployer vos certificats de serveur. Avec ACM. Vous pouvez demander un certificat ou déployer un ACM existant ou un certificat externe sur des ressources AWS. En guise de meilleure pratique, il est recommandé de réimporter les certificats arrivant à expiration/arrivés à expiration tout en conservant les associations ELB du certificat d’origine.

Gravité : élevée

La journalisation des erreurs de domaine Elasticsearch doit être activée dans CloudWatch Logs

Description : ce contrôle vérifie si les domaines Elasticsearch sont configurés pour envoyer des journaux d’erreurs aux journaux CloudWatch. Vous devez activer les journaux d’erreurs pour les domaines Elasticsearch et envoyer ces journaux à CloudWatch Logs pour la rétention et la réponse. Les journaux d’erreurs de domaine peuvent faciliter les audits de sécurité et d’accès et peuvent aider à diagnostiquer les problèmes de disponibilité.

Gravité : moyenne

Les domaines Elasticsearch doivent être configurés avec au moins trois nœuds principaux dédiés

Description : ce contrôle vérifie si les domaines Elasticsearch sont configurés avec au moins trois nœuds principaux dédiés. Ce contrôle échoue si le domaine n’utilise pas de nœuds principaux dédiés. Ce contrôle réussit si les domaines Elasticsearch ont cinq nœuds principaux dédiés. Toutefois, l’utilisation de plus de trois nœuds principaux peut s’avérer inutile pour atténuer le risque lié à la disponibilité et entraînera un coût supplémentaire. Un domaine Elasticsearch nécessite au moins trois nœuds principaux dédiés pour la haute disponibilité et la tolérance aux pannes. Les ressources de nœud principal dédié peuvent être mises à rude épreuve lors des déploiements bleus/verts des nœuds de données, car il faut gérer des nœuds supplémentaires. Le déploiement d’un domaine Elasticsearch avec au moins trois nœuds principaux dédiés garantit un capacité suffisante de ressources de nœud principal et le fonctionnement du cluster en cas de défaillance d’un nœud.

Gravité : moyenne

Les domaines Elasticsearch doivent comporter au moins trois nœuds de données

Description : ce contrôle vérifie si les domaines Elasticsearch sont configurés avec au moins trois nœuds de données et zoneAwarenessEnabled est vrai. Un domaine Elasticsearch nécessite au moins trois nœuds de données pour la haute disponibilité et la tolérance aux pannes. Le déploiement d’un domaine Elasticsearch avec au moins trois nœuds de données garantit le fonctionnement du cluster en cas de défaillance d’un nœud.

Gravité : moyenne

La journalisation d’audit doit être activée pour les domaines Elasticsearch

Description : ce contrôle vérifie si les domaines Elasticsearch ont activé la journalisation d’audit. Ce contrôle échoue si la journalisation d’audit n’est pas activée pour un domaine Elasticsearch. Les journaux d’audit sont hautement personnalisables. Ils vous permettent de suivre l’activité des utilisateurs sur vos clusters Elasticsearch, notamment les réussites et les échecs d’authentification, les demandes adressées à OpenSearch, les modifications d’index et les requêtes de recherche entrantes.

Gravité : moyenne

La supervision améliorée doit être configurée pour les clusters et les instances de base de données RDS

Description : ce contrôle vérifie si la surveillance améliorée est activée pour vos instances de base de données RDS. Dans Amazon RDS, la surveillance améliorée permet une réponse plus rapide aux changements de niveau de performance dans l’infrastructure sous-jacente. Ces changements de niveau de performance peuvent entraîner un manque de disponibilité des données. La surveillance améliorée fournit des métriques en temps réel du système d’exploitation sur lequel s’exécute votre instance de base de données RDS. Un agent est installé sur l’instance. L’agent peut obtenir des métriques plus précisément que ce qui est possible à partir de la couche hyperviseur. Les métriques de surveillance améliorée sont utiles lorsque vous voulez voir la façon dont les différents processus ou threads d’une instance de base de données utilisent l’UC. Pour plus d’informations, consultez Surveillance améliorée dans le guide de l’utilisateur d’Amazon RDS.

Gravité : faible

Vérifier que la rotation des CMK créés par le client est activée

Description : AWS Service de gestion de clés (KMS) permet aux clients de faire pivoter la clé de stockage, qui est le matériau de clé stocké dans le service KMS lié à l’ID de clé de la clé principale créée par le client (CMK). Il s’agit de la clé de stockage utilisée pour effectuer des opérations de chiffrement, telles que le chiffrement et le déchiffrement. La rotation automatisée des clés conserve actuellement toutes les clés de stockage antérieures afin que le déchiffrement des données chiffrées puisse s’effectuer de manière transparente. Il est recommandé d’activer la rotation de clé CMK. La rotation des clés de chiffrement permet de réduire l’impact potentiel d’une clé compromise, car les données chiffrées avec une nouvelle clé ne sont pas accessibles avec une clé précédente qui a pu être exposée.

Gravité : moyenne

Vérifier que la journalisation des accès au compartiment S3 est activée sur le compartiment S3 CloudTrail

Description : la journalisation de l’accès au compartiment S3 génère un journal qui contient des enregistrements d’accès, vérifiez que la journalisation de l’accès au compartiment S3 S3 est activée sur le compartiment CloudTrail S3 pour chaque requête effectuée sur votre compartiment S3. Un enregistrement de journal d’accès contient des détails sur la demande, tels que le type de demande, les ressources spécifiées dans la demande effectuée et l’heure et la date de traitement de la demande. Il est recommandé d’activer la journalisation des accès au compartiment sur le compartiment S3 CloudTrail. En activant la journalisation de compartimentS S3 sur les compartiments S3 cibles, il est possible de capturer tous les événements, ce qui peut affecter les objets dans les compartiments cibles. La configuration des journaux pour qu’ils soient placés dans un compartiment distinct permet d’accéder aux informations des journaux, ce qui peut être utile dans les flux de travail de sécurité et de réponse aux incidents.

Gravité : faible

Vérifier que le compartiment S3 utilisé pour stocker les journaux CloudTrail n’est pas accessible publiquement

Description : CloudTrail enregistre un enregistrement de chaque appel d’API effectué dans votre compte AWS. Ces fichiers journaux sont stockés dans un compartiment S3. Il est recommandé que la stratégie de compartiment ou la liste de contrôle d’accès (ACL) soit appliquée au compartiment S3 que CloudTrail journalise pour empêcher l’accès public aux journaux CloudTrail. Autoriser l’accès public au contenu du journal CloudTrail peut aider un adversaire à identifier les faiblesses de l’utilisation ou de la configuration du compte concerné.

Gravité : élevée

IAM ne doit pas avoir expiré de certificats SSL/TLS

Description : Cette vérification identifie les certificats SSL/TLS expirés. Pour activer les connexions HTTPS à votre site web ou à votre application dans AWS, vous avez besoin d’un certificat de serveur SSL/TLS. Vous pouvez utiliser ACM ou IAM pour stocker et déployer des certificats de serveur. La suppression des certificats SSL/TLS expirés élimine le risque qu’un certificat non valide soit déployé accidentellement sur une ressource telle qu’AWS Elastic Load Balancer (ELB), ce qui peut nuire à la crédibilité de l’application/du site web derrière l’ELB. Cette vérification génère des alertes s’il existe des certificats SSL/TLS expirés stockés dans AWS IAM. En guise de meilleure pratique, il est recommandé de supprimer les certificats expirés.

Gravité : élevée

Les certificats ACM importés doivent être renouvelés après un laps de temps spécifié

Description : ce contrôle vérifie si les certificats ACM dans votre compte sont marqués pour expiration dans les 30 jours. Il vérifie à la fois les certificats importés et les certificats fournis par AWS Certificate Manager. ACM peut renouveler automatiquement les certificats qui utilisent la validation DNS. Pour les certificats qui utilisent la validation par e-mail, vous devez répondre à un e-mail de validation de domaine. ACM ne renouvelle pas non plus automatiquement les certificats que vous importez. Vous devez renouveler manuellement les certificats importés. Pour plus d’informations sur le renouvellement géré des certificats ACM, consultez Renouvellement géré des certificats ACM dans le guide de l’utilisateur d’AWS Certificate Manager.

Gravité : moyenne

Les identités surprovisionnées dans les comptes doivent être examinées pour réduire l’index d’analyse des autorisations (PCI)

Description : les identités surprovisionnée dans les comptes doivent être examinées pour réduire l’index pci (Permission Creep Index) et protéger votre infrastructure. Réduisez l’index PCI en supprimant les attributions d’autorisations à haut risque inutilisées. La norme PCI élevée reflète les risques associés aux identités disposant d’autorisations qui dépassent leur utilisation normale ou requise.

Gravité : moyenne

Les mises à niveau automatiques des versions mineures RDS doivent être activées

Description : ce contrôle vérifie si les mises à niveau automatiques des versions mineures sont activées pour l’instance de base de données RDS. L’activation des mises à niveau automatiques des versions mineures garantit que les dernières mises à jour des versions mineures du système de gestion de base de données relationnelle (SGBDR) sont installées. Ces mises à niveau peuvent inclure des correctifs de sécurité et des correctifs de bogues. Rester à jour dans l’installation des correctifs est une étape importante de la sécurisation des systèmes.

Gravité : élevée

Les instantanés de cluster RDS et les instantanés de base de données doivent être chiffrés au repos

Description : ce contrôle vérifie si les instantanés de base de données RDS sont chiffrés. Ce contrôle est destiné aux instances de base de données RDS. Toutefois, il peut également générer des résultats pour les instantanés des instances de base de données Aurora, les instances de base de données Neptune et les clusters Amazon DocumentDB. Si ces résultats ne sont pas utiles, vous pouvez les supprimer. Le chiffrement des données au repos réduit le risque qu’un utilisateur non authentifié ait accès aux données stockées sur le disque. Les données des instantanés RDS doivent être chiffrées au repos pour une couche de sécurité supplémentaire.

Gravité : moyenne

La protection contre la suppression doit être activée pour les clusters RDS

Description : ce contrôle vérifie si la protection de suppression est activée pour les clusters RDS. Ce contrôle est destiné aux instances de base de données RDS. Toutefois, il peut également générer des résultats pour les instances de base de données Aurora, les instances de base de données Neptune et les clusters Amazon DocumentDB. Si ces résultats ne sont pas utiles, vous pouvez les supprimer. L’activation de la protection contre la suppression de cluster est une autre couche de protection contre la suppression ou la suppression accidentelles d’une base de données par une entité non autorisée. Lorsque la protection contre la suppression est activée, un cluster RDS ne peut pas être supprimé. Pour qu’une demande de suppression aboutisse, la protection contre la suppression doit être désactivée.

Gravité : faible

Les clusters de base de données RDS doivent être configurés pour plusieurs zones de disponibilité

Description : les clusters de base de données RDS doivent être configurés pour plusieurs données stockées. Le déploiement sur plusieurs zones de disponibilité permet d’automatiser les zones de disponibilité afin de garantir la disponibilité du basculement en cas de problème de disponibilité de la zone de disponibilité et lors d’événements de maintenance réguliers de RDS.

Gravité : moyenne

Les clusters de base de données RDS doivent être configurés pour copier des balises vers des instantanés

Description : L’identification et l’inventaire de vos ressources informatiques constituent un aspect crucial de la gouvernance et de la sécurité. Vous devez avoir une visibilité de tous vos clusters de base de données RDS afin de pouvoir évaluer leur posture de sécurité et agir sur les éventuelles zones de faiblesse. Les instantanés doivent être marqués de la même façon que leurs clusters de base de données RDS parents. En activant ce paramètre, les instantanés héritent des balises de leurs clusters de bases de données parents.

Gravité : faible

Les instances de base de données RDS doivent être configurées pour copier des balises vers des instantanés

Description : ce contrôle vérifie si les instances de base de données RDS sont configurées pour copier toutes les balises dans des instantanés lorsque les instantanés sont créés. L’identification et l’inventaire de vos ressources informatiques constituent un aspect essentiel de la gouvernance et de la sécurité. Vous devez avoir une visibilité de toutes vos instances de base de données RDS afin de pouvoir évaluer leur posture de sécurité et agir sur les éventuelles zones de faiblesse. Les instantanés doivent être marqués de la même façon que leurs instances de base de données RDS parentes. En activant ce paramètre, les instantanés héritent des balises de leurs instances de bases de données parentes.

Gravité : faible

Les instances de base de données RDS doivent être configurées avec plusieurs zones de disponibilité

Description : ce contrôle vérifie si la haute disponibilité est activée pour vos instances de base de données RDS. Les instances de base de données RDS doivent être configurées pour plusieurs zones de disponibilité. Cela garantit la disponibilité des données stockées. Les déploiements sur plusieurs zones de disponibilité permettent un basculement automatique en cas de problème de disponibilité de la zone de disponibilité et pendant la maintenance régulière de RDS.

Gravité : moyenne

La protection contre la suppression doit être activée pour les instances de base de données RDS

Description : ce contrôle vérifie si vos instances de base de données RDS qui utilisent l’un des moteurs de base de données répertoriés sont activées. L’activation de la protection contre la suppression d’instance est une autre couche de protection contre la suppression ou la suppression accidentelles d’une base de données par une entité non autorisée. Lorsque la protection contre la suppression est activée, une instance de base de données RDS ne peut pas être supprimée. Pour qu’une demande de suppression aboutisse, la protection contre la suppression doit être désactivée.

Gravité : faible

Le chiffrement au repos doit être activé sur les instances de base de données RDS

Description : Ce contrôle vérifie si le chiffrement de stockage est activé pour vos instances de base de données Amazon RDS. Ce contrôle est destiné aux instances de base de données RDS. Toutefois, il peut également générer des résultats pour les instances de base de données Aurora, les instances de base de données Neptune et les clusters Amazon DocumentDB. Si ces résultats ne sont pas utiles, vous pouvez les supprimer. Pour obtenir une couche supplémentaire de sécurité pour vos données sensibles dans les instances de base de données RDS, vous devez configurer vos instances de base de données RDS pour qu’elles soient chiffrées au repos. Pour chiffrer vos instantanés et instances de base de données RDS au repos, activez l’option de chiffrement pour vos instances de base de données RDS. Les données chiffrées au repos incluent le stockage sous-jacent des instances de base de données, ses sauvegardes automatiques, ses réplicas de lecture et ses instantanés. Les instances de base de données chiffrées RDS utilisent l’algorithme de chiffrement AES-256 standard ouvert pour chiffrer vos données sur le serveur qui héberge vos instances de base de données RDS. Une fois vos données chiffrées, Amazon RDS gère l’authentification de l’accès et le déchiffrement de vos données de façon transparente avec un impact minimal sur le niveau de performance. Vous n’avez pas besoin de modifier vos applications clientes de base de données pour utiliser le chiffrement. Le chiffrement d’Amazon RDS est actuellement disponible pour tous les moteurs de base de données et tous les types de stockage. Le chiffrement d’Amazon RDS est disponible pour la plupart des classes d’instance de base de données. Pour en savoir plus sur les classes d’instances de base de données qui ne prennent pas en charge le chiffrement Amazon RDS, consultez Chiffrement des ressources Amazon RDS dans le Guide de l’utilisateur d’Amazon RDS.

Gravité : moyenne

Les instances de base de données RDS doivent interdire l’accès public

Description : Nous vous recommandons également de vous assurer que l’accès à la configuration de votre instance RDS est limité uniquement aux utilisateurs autorisés, en limitant les autorisations IAM des utilisateurs pour modifier les paramètres et les ressources des instances RDS.

Gravité : élevée

Les instantanés RDS doivent interdire l’accès public

Description : nous vous recommandons d’autoriser uniquement les principaux autorisés à accéder à l’instantané et à modifier la configuration Amazon RDS.

Gravité : élevée

Supprimer les secrets inutilisés de Secrets Manager

Description : ce contrôle vérifie si vos secrets ont été consultés dans un nombre spécifié de jours. La valeur par défaut est de 90 jours. Si un secret n’a pas été consulté dans le nombre de jours défini, ce contrôle échoue. La suppression des secrets inutilisés est aussi importante que la rotation des secrets. Les secrets inutilisés peuvent être utilisés abusivement par leurs anciens utilisateurs, qui n’ont plus besoin d’y accéder. En outre, lorsque de plus en plus d’utilisateurs ont accès à un secret, il devient possible que quelqu’un le manipule mal et le divulgue à une entité non autorisée, ce qui augmente le risque d’abus. La suppression des secrets inutilisés permet de révoquer l’accès aux secrets des utilisateurs qui n’en ont plus besoin. Elle permet également de réduire le coût d’utilisation du gestionnaire de secrets. Par conséquent, il est essentiel de supprimer régulièrement les secrets inutilisés.

Gravité : moyenne

La réplication interrégion doit être activée sur les compartiments S3

Description : L’activation de la réplication interrégion S3 garantit que plusieurs versions des données sont disponibles dans différentes régions distinctes. Cela vous permet de protéger votre compartiment S3 contre les attaques DDoS et les événements d’altération des données.

Gravité : faible

Le chiffrement côté serveur doit être activé sur les compartiments S3

Description : activez le chiffrement côté serveur pour protéger les données dans vos compartiments S3. Le chiffrement des données peut empêcher l’accès aux données sensibles en cas de violation des données.

Gravité : moyenne

Les secrets Secrets Manager configurés avec la rotation automatique doivent effectuer la rotation correctement

Description : ce contrôle vérifie si un secret AWS Secrets Manager a été pivoté correctement en fonction de la planification de rotation. Le contrôle échoue si RotationOccurringAsScheduled a la valeur false. Le contrôle n’évalue pas les secrets qui n’ont pas de rotation configurée. Secrets Manager vous aide à améliorer la posture de sécurité de votre organisation. Les secrets incluent des informations d’identification de base de données, des mots de passe et des clés API tierces. Vous pouvez utiliser Secrets Manager pour stocker des secrets de manière centralisée, chiffrer les secrets automatiquement, contrôler l’accès aux secrets et effectuer la rotation des secrets en toute sécurité et automatiquement. Secrets Manager peut effectuer la rotation des secrets. Vous pouvez utiliser la rotation pour remplacer des secrets à long terme par des secrets à court terme. La rotation de vos secrets limite la durée pendant laquelle un utilisateur non autorisé peut utiliser un secret compromis. C’est pourquoi vous devez fréquemment effectuer la rotation de vos secrets. En plus de configurer des secrets pour une rotation automatique, vous devez vous assurer que ces secrets effectuent correctement la rotation en fonction de la planification de cette dernière. Pour en savoir plus sur la rotation, consultez Rotation des secrets d’AWS Secrets Manager dans le guide de l’utilisateur d’AWS Secrets Manager.

Gravité : moyenne

Les secrets Secrets Manager doivent effectuer une rotation dans un délai de jours spécifié

Description : ce contrôle vérifie si vos secrets ont été pivotés au moins une fois dans les 90 jours. La rotation des secrets peut vous aider à réduire le risque d’une utilisation non autorisée de vos secrets dans votre compte AWS. Il peut s’agir, par exemple, d’informations d’identification de base de données, de mots de passe, de clés API tierces, voire de texte arbitraire. Si vous ne modifiez pas vos secrets pendant une longue période, les secrets sont plus susceptibles d’être compromis. Plus le nombre d’utilisateurs ayant accès à un secret est élevé, plus il est probable que quelqu’un le manipule mal et le transmette à une entité non autorisée. Les secrets peuvent être divulgués par le biais des journaux et des données de cache. Ils peuvent être partagés à des fins de débogage et ne pas être modifiés ou révoqués une fois le débogage terminé. Pour toutes ces raisons, il est important d’effectuer une rotation fréquente des secrets. Vous pouvez configurer une rotation automatique de vos secrets dans AWS Secrets Manager. Grâce à la rotation automatique, vous pouvez remplacer des secrets à long terme par des secrets à court terme, ce qui réduit considérablement les risques de compromission. Security Hub vous recommande d’activer la rotation pour vos secrets Secrets Manager. Pour en savoir plus sur la rotation, consultez Rotation des secrets d’AWS Secrets Manager dans le guide de l’utilisateur d’AWS Secrets Manager.

Gravité : moyenne

Les rubriques SNS doivent être chiffrées au repos à l’aide d’AWS KMS

Description : ce contrôle vérifie si une rubrique SNS est chiffrée au repos à l’aide d’AWS KMS. Le chiffrement des données au repos réduit le risque d’accès aux données stockées sur le disque par un utilisateur non authentifié auprès d’AWS. Il ajoute également un autre ensemble de contrôles d’accès pour limiter la capacité des utilisateurs non autorisés à accéder aux données. Par exemple, des autorisations d’API sont nécessaires pour déchiffrer les données avant de pouvoir les lire. Les rubriques SNS doivent être chiffrées au repos pour une couche de sécurité ajoutée. Pour plus d’informations, consultez Chiffrement au repos dans le guide du développeur d’Amazon Simple Notification Service.

Gravité : moyenne

La journalisation de flux VPC doit être activée dans tous les VPC

Description : les journaux de flux DU VPC fournissent une visibilité du trafic réseau qui transite par le VPC et peuvent être utilisés pour détecter le trafic ou les insights anormales pendant les événements de sécurité.

Gravité : moyenne

Recommandations en matière de données GCP

Vérifiez que l’indicateur de base de données « 3625 (indicateur de trace) » pour l’instance cloud SQL Server est défini sur « désactivé »

Description : il est recommandé de définir l’indicateur de base de données « 3625 (indicateur de trace) » pour l’instance cloud SQL Server sur « désactivé ». Les indicateurs de trace sont fréquemment utilisés pour diagnostiquer les problèmes de performances ou pour déboguer des procédures stockées ou des systèmes informatiques complexes, mais ils peuvent également être recommandés par Support Microsoft pour résoudre le comportement qui a un impact négatif sur une charge de travail spécifique. Tous les indicateurs de trace documentés et ceux qui sont recommandés par le Support Microsoft sont entièrement pris en charge dans un environnement de production quand ils sont utilisés comme indiqué. « 3625(journal de trace) » Limite la quantité d’informations retournées aux utilisateurs qui ne sont pas membres du rôle serveur fixe sysadmin, en masquant les paramètres de certains messages d’erreur à l’aide de « ****** ». Cela peut permettre d'éviter la divulgation d'informations sensibles. Par conséquent, il est recommandé de désactiver cet indicateur. Cette recommandation s’applique aux instances de base de données SQL Server.

Gravité : moyenne

Vérifiez que l’indicateur de base de données « Scripts externes activés » pour l’instance cloud SQL Server est défini sur « désactivé »

Description : il est recommandé de définir l’indicateur de base de données « Scripts externes activés » pour que l’instance SQL Server Cloud SQL Server soit désactivée. L’option « external scripts enabled » permet l’exécution de scripts avec certaines extensions de langage à distance. Cette propriété est désactivée par défaut. Quand Advanced Analytics Services est installé, le programme d’installation peut éventuellement définir cette propriété sur True. Étant donné que la fonctionnalité « Scripts externes activés » permet d’exécuter des scripts externes à SQL, comme des fichiers situés dans une bibliothèque R, ce qui peut nuire à la sécurité du système, elle doit être désactivée. Cette recommandation s’applique aux instances de base de données SQL Server.

Gravité : élevée

Vérifiez que l’indicateur de base de données « accès à distance » pour l’instance cloud SQL Server a la valeur « désactivé »

Description : il est recommandé de définir l’indicateur de base de données « accès à distance » pour l’instance SQL Server cloud sur « désactivé ». L’option « accès à distance » contrôle l’exécution des procédures stockées à partir de serveurs locaux ou distants sur lesquels s’exécutent les instances de SQL Server. La valeur par défaut de cette option est 1. Cette valeur autorise l'exécution des procédures stockées locales depuis des serveurs distants, ou des procédures stockées distantes depuis le serveur local. Pour empêcher l’exécution des procédures stockées locales depuis un serveur distant ou des procédures stockées distantes depuis le serveur local, désactivez option. L’option Remote Access contrôle l’exécution des procédures stockées locales sur les serveurs distants ou des procédures stockées distantes sur le serveur local. La fonctionnalité « Accès à distance » peut être abusée pour lancer une attaque par déni de service (DoS) sur des serveurs distants en désactivant le traitement des requêtes sur une cible. Cette recommandation s’applique aux instances de base de données SQL Server.

Gravité : élevée

Vérifiez que l’indicateur de base de données « skip_show_database » pour l’instance Mysql CLOUD SQL a la valeur « activé »

Description : il est recommandé de définir l’indicateur de base de données « skip_show_database » pour l’instance Sql Mysql cloud sur « on ». L’indicateur de base de données « skip_show_database » empêche les utilisateurs d’utiliser l’instruction SHOW DATABASES s’ils n’ont pas le privilège SHOW DATABASES. Cela peut améliorer la sécurité si vous avez des préoccupations concernant la possibilité pour les utilisateurs de voir des bases de données appartenant à d’autres utilisateurs. Son effet dépend du privilège SHOW DATABASES : si la valeur de la variable est ON, l’instruction SHOW DATABASES n’est autorisée qu’aux utilisateurs disposant du privilège SHOW DATABASES, et l’instruction affiche tous les noms de base de données. Si la valeur est OFF, SHOW DATABASES est autorisé pour tous les utilisateurs, mais affiche uniquement les noms des bases de données pour lesquelles l’utilisateur dispose du privilège SHOW DATABASES ou d’un autre privilège. Cette recommandation s’applique aux instances de base de données MySQL.

Gravité : faible

Vérifiez qu’une clé de chiffrement gérée par le client (CMEK) par défaut est spécifiée pour tous les jeux de données BigQuery

Description : BigQuery chiffre par défaut les données au repos en utilisant le chiffrement d’enveloppe à l’aide de clés de chiffrement gérées par Google. Les données sont chiffrées à l’aide des clés de chiffrement des données, et les clés de chiffrement de données elles-mêmes sont davantage chiffrées à l’aide de clés de chiffrement de clé. Cette opération est transparente et ne nécessite aucune entrée supplémentaire de la part de l’utilisateur. Toutefois, si vous souhaitez avoir un meilleur contrôle, des clés de chiffrement gérées par le client (CMEK) peuvent être utilisées comme solution de gestion des clés de chiffrement pour les jeux de données BigQuery. Par défaut, BigQuery chiffre les données au repos en utilisant le chiffrement d’enveloppe à l’aide de clés de chiffrement gérées par Google. Cela est transparent et ne nécessite aucune entrée supplémentaire de l’utilisateur. Pour mieux contrôler le chiffrement, des clés de chiffrement gérées par le client (CMEK) peuvent être utilisées comme solution de gestion des clés de chiffrement pour les jeux de données BigQuery. La définition d’une clé de chiffrement gérée par le client (CMEK) par défaut pour un jeu de données garantit que toutes les tables créées à l’avenir utiliseront la clé CMEK spécifiée si aucune autre table n’est fournie.

Google ne stocke pas vos clés sur ses serveurs et ne peut pas accéder à vos données protégées, sauf si vous fournissez la clé.

Cela signifie également que si vous oubliez ou perdez votre clé, il n’existe aucun moyen pour Google de récupérer la clé ou de récupérer les données chiffrées avec la clé perdue.

Gravité : moyenne

Vérifiez que toutes les tables BigQuery sont chiffrées avec une clé de chiffrement gérée par le client (CMEK)

Description : BigQuery chiffre par défaut les données au repos en utilisant le chiffrement d’enveloppe à l’aide de clés de chiffrement gérées par Google. Les données sont chiffrées à l’aide des clés de chiffrement des données, et les clés de chiffrement de données elles-mêmes sont davantage chiffrées à l’aide de clés de chiffrement de clé. Cette opération est transparente et ne nécessite aucune entrée supplémentaire de la part de l’utilisateur. Toutefois, si vous souhaitez avoir un meilleur contrôle, des clés de chiffrement gérées par le client (CMEK) peuvent être utilisées comme solution de gestion des clés de chiffrement pour les jeux de données BigQuery. Si CMEK est utilisé, la CMEK est utilisée pour chiffrer les clés de chiffrement de données au lieu des clés de chiffrement gérées par Google. Par défaut, BigQuery chiffre les données au repos en utilisant le chiffrement d’enveloppe à l’aide de clés de chiffrement gérées par Google. Cela est transparent et ne nécessite aucune entrée supplémentaire de l’utilisateur. Pour mieux contrôler le chiffrement, des clés de chiffrement gérées par le client (CMEK) peuvent être utilisées comme solution de gestion des clés de chiffrement pour les tables BigQuery. La CMEK est utilisée pour chiffrer les clés de chiffrement de données au lieu des clés de chiffrement gérées par Google. BigQuery stocke la table et l’association CMEK, et le chiffrement/déchiffrement est effectué automatiquement. L’application des clés gérées par le client par défaut sur les jeux de données BigQuery garantit que toutes les nouvelles tables créées à l’avenir seront chiffrées à l’aide de CMEK, mais les tables existantes doivent être mises à jour pour utiliser CMEK individuellement.

Google ne stocke pas vos clés sur ses serveurs et ne peut pas accéder à vos données protégées, sauf si vous fournissez la clé. Cela signifie également que si vous oubliez ou perdez votre clé, il n’existe aucun moyen pour Google de récupérer la clé ou de récupérer les données chiffrées avec la clé perdue.

Gravité : moyenne

Vérifier que les jeux de données BigQuery ne sont pas accessibles de manière anonyme ou publique

Description : il est recommandé que la stratégie IAM sur les jeux de données BigQuery n’autorise pas l’accès anonyme et/ou public. L’octroi d’autorisations à allUsers ou allAuthenticatedUsers permet à quiconque d’accéder au jeu de données. Cet accès peut ne pas être souhaitable si des données sensibles sont stockées dans le jeu de données. Par conséquent, assurez-vous que l’accès anonyme et/ou public à un jeu de données n’est pas autorisé.

Gravité : élevée

Vérifier que les instances de base de données SQL cloud sont configurées avec des sauvegardes automatisées

Description : il est recommandé de définir toutes les instances de base de données SQL pour activer les sauvegardes automatisées. Les sauvegardes fournissent un moyen de restaurer une instance SQL cloud pour récupérer des données perdues ou récupérer suite à un problème avec cette instance. Les sauvegardes automatisées doivent être définies pour toute instance qui contient des données qui doivent être protégées contre la perte ou les dommages. Cette recommandation s’applique aux instances SQL Server, PostgreSql, MySql génération 1 et MySql de génération 2.

Gravité : élevée

Vérifiez que les instances de base de données SQL Cloud ne sont pas ouvertes au monde

Description : Le serveur de base de données doit accepter les connexions uniquement à partir de réseaux/adresses IP approuvés et restreindre l’accès à partir du monde. Pour réduire la surface d’attaque sur une instance de serveur de base de données, seules les adresses IP approuvées/connues et requises doivent être approuvées pour la connexion. Un réseau autorisé ne doit pas avoir d’adresses IP/réseaux configurés sur 0.0.0.0/0, ce qui permettra d’accéder à l’instance depuis n’importe où dans le monde. Notez que les réseaux autorisés s’appliquent uniquement aux instances avec des adresses IP publiques.

Gravité : élevée

Vérifier que les instances de base de données SQL cloud ne disposent pas d’adresses IP publiques

Description : il est recommandé de configurer l’instance Sql de deuxième génération pour utiliser des adresses IP privées au lieu d’adresses IP publiques. Pour réduire la surface d’attaque de l’organisation, les bases de données CLOUD SQL ne doivent pas avoir d’adresses IP publiques. Les adresses IP privées offrent une sécurité réseau améliorée et une latence plus faible pour votre application.

Gravité : élevée

Vérifier que le compartiment de stockage cloud n’est pas accessible de manière anonyme ou publique

Description : il est recommandé que la stratégie IAM sur le compartiment Stockage cloud n’autorise pas l’accès anonyme ou public. Autoriser l’accès anonyme ou public accorde des autorisations à quiconque pour accéder au contenu du compartiment. Ce type d’accès peut ne pas être souhaité si vous stockez des données sensibles. Par conséquent, assurez-vous que l’accès anonyme ou public à un compartiment n’est pas autorisé.

Gravité : élevée

Vérifier que les compartiments de stockage cloud ont un accès au niveau du compartiment uniforme activé

Description : il est recommandé d’activer l’accès uniforme au niveau du compartiment sur les compartiments de stockage cloud. Il est recommandé d’utiliser un accès uniforme au niveau du compartiment pour unifier et simplifier la façon dont vous accordez l’accès à vos ressources de stockage cloud. Le stockage cloud offre deux systèmes pour accorder aux utilisateurs l’autorisation d’accéder à vos compartiments et objets : Gestion des identités et des accès sur cloud (CLOUD IAM) et Liste de contrôle d'accès (ACL).
Ces systèmes agissent en parallèle : pour qu’un utilisateur accède à une ressource Cloud Storage, un seul des systèmes doit accorder l’autorisation à l’utilisateur. Cloud IAM est utilisé dans Google Cloud et vous permet d’accorder diverses autorisations au niveau du compartiment et du projet. Les listes de contrôle d’accès sont utilisées uniquement par Cloud Storage et ont des options d’autorisation limitées, mais elles vous permettent d’accorder des autorisations par objet.

Pour prendre en charge un système d’autorisation uniforme, Cloud Storage dispose d’un accès uniforme au niveau du compartiment. L’utilisation de cette fonctionnalité désactive les listes de contrôle d’accès pour toutes les ressources de stockage cloud : l’accès aux ressources de stockage cloud est alors accordé exclusivement via Cloud IAM. L’activation de l’accès uniforme au niveau du compartiment garantit que si un compartiment de stockage n’est pas accessible publiquement, aucun objet du compartiment n’est accessible publiquement.

Gravité : moyenne

Vérifiez que le calcul confidentiel est activé pour les instances de calcul

Description : Google Cloud chiffre les données au repos et en transit, mais les données client doivent être déchiffrées pour traitement. L’informatique confidentielle est une technologie révolutionnaire qui chiffre les données en cours d’utilisation pendant qu’elles sont traitées. Les environnements d’informatique confidentielle conservent les données chiffrées en mémoire et ailleurs en dehors de l’unité centrale (UC). Les machines virtuelles confidentielles tirent parti de la fonctionnalité de virtualisation sécurisée (SEV) des processeurs AMD EPYC. Les données client restent chiffrées pendant qu’elles sont utilisées, indexées, interrogées ou entraînées. Les clés de chiffrement sont générées dans le matériel, pour chaque machine virtuelle, et ne peuvent pas être exportées. Grâce aux optimisations matérielles intégrées des performances et de la sécurité, il n’existe aucune pénalité significative en matière de performances pour les charges de travail d’informatique confidentielle. L’informatique confidentielle permet au code et d’autres données sensibles des clients d’être chiffrés en mémoire pendant le traitement. Google n’a pas accès aux clés de chiffrement. Les machines virtuelles confidentielles peuvent aider à atténuer les préoccupations relatives aux risques liés à la dépendance vis-à-vis de l’infrastructure Google ou à l’accès des éléments internes de Google aux données des clients en clair.

Gravité : élevée

Vérifiez que les stratégies de rétention sur les compartiments de journal sont configurées à l’aide du verrou de compartiment

Description : L’activation des stratégies de rétention sur les compartiments de journaux protégera les journaux stockés dans les compartiments de stockage cloud d’être remplacés ou supprimés accidentellement. Il est recommandé de configurer des stratégies de rétention et de configurer le verrou de compartiment sur tous les compartiments de stockage utilisés comme récepteurs de journaux. Les journaux peuvent être exportés en créant un ou plusieurs récepteurs qui incluent un filtre de journal et une destination. Comme Stackdriver Logging reçoit de nouvelles entrées de journal, elles sont comparées à chaque récepteur. Si une entrée de journal correspond au filtre d’un récepteur, une copie de l’entrée de journal est écrite dans la destination. Les récepteurs peuvent être configurés pour exporter des journaux dans des compartiments de stockage. Il est recommandé de configurer une stratégie de rétention des données pour ces compartiments de stockage cloud et de verrouiller la stratégie de rétention des données ; empêche ainsi définitivement la stratégie d’être réduite ou supprimée. De cette façon, si le système est compromis par un attaquant ou un élément interne malveillant qui souhaite couvrir ses traces, les journaux d’activité sont définitivement conservés pour les enquêtes de sécurité et d’investigation.

Gravité : faible

Vérifier que l’instance de base de données SQL cloud nécessite l’utilisation de SSL pour toutes les connexions entrantes

Description : il est recommandé d’appliquer toutes les connexions entrantes à l’instance de base de données SQL pour utiliser SSL. Connexions de base de données SQL si elles ont été interceptées avec succès (MITM) ; peut révéler des données sensibles telles que les informations d’identification, les requêtes de base de données, les sorties de requête, etc. Pour la sécurité, il est recommandé d’utiliser toujours le chiffrement SSL lors de la connexion à votre instance. Cette recommandation s’applique aux instances Postgresql, MySql génération 1 et MySql de génération 2.

Gravité : élevée

Vérifiez que l’indicateur de base de données « Authentification de base de données contenue » pour Cloud SQL sur l’instance SQL est défini sur « désactivé »

Description : il est recommandé de définir l’indicateur de base de données « authentification de base de données autonome » pour Cloud SQL sur l’instance SQL Server est défini sur « désactivé ». Une base de données autonome inclut tous les paramètres et métadonnées de base de données requis pour définir la base de données et n’a aucune dépendance de configuration sur l’instance du Moteur de base de données où la base de données est installée. Les utilisateurs peuvent se connecter à la base de données sans authentifier de connexion au niveau du Moteur de base de données. Isoler la base de données du Moteur de base de données permet de la déplacer facilement vers une autre instance de SQL Server. Les bases de données autonomes présentent quelques menaces originales que les administrateurs du Moteur de base de données SQL Server doivent connaître et limiter. La plupart de ces menaces sont liées au processus d’authentification USER WITH PASSWORD , qui déplace la limite de l’authentification du niveau du Moteur de base de données vers celui de la base de données, il est donc recommandé de désactiver cet indicateur. Cette recommandation s’applique aux instances de base de données SQL Server.

Gravité : moyenne

Vérifiez que l’indicateur de base de données « chaînage entre propriétés de base de données » pour l’instance Cloud SQL Server est défini sur « désactivé »

Description : il est recommandé de définir l’indicateur de base de données « chaînage de propriétés entre bases de données » pour que l’instance SQL Server Cloud SQL Server soit « désactivée ». Utilisez l’option « propriété cross db » pour l’option de chaînage de propriétés entre bases de données pour une instance de Microsoft SQL Server. Cette option de serveur vous permet de contrôler le chaînage des propriétés des bases de données croisées au niveau de la base de données ou d’autoriser le chaînage des propriétés des bases de données croisées pour toutes les bases de données. L’activation de la « propriété entre bases de données » n’est pas recommandée, sauf si toutes les bases de données hébergées par l’instance de SQL Server doivent participer au chaînage de propriétés inter-bases de données et que vous connaissez les implications de sécurité de ce paramètre. Cette recommandation s’applique aux instances de base de données SQL Server.

Gravité : moyenne

Vérifiez que l’indicateur de base de données « local_infile » pour une instance Cloud SQL Mysql est défini sur « désactivé »

Description : il est recommandé de définir l’indicateur de base de données local_infile pour qu’une instance Sql Sql Cloud soit désactivée. L’indicateur local_infile contrôle la fonctionnalité LOCAL côté serveur pour les instructions LOAD DATA. Selon le paramètre local_infile, le serveur refuse ou autorise le chargement de données locales par les clients pour lesquels LOCAL est activé. Pour que le serveur refuse explicitement les instructions LOAD DATA LOCAL (quelle que soit la façon dont les programmes et bibliothèques clients sont configurés au moment de la génération ou au moment de l’exécution), commencez mysqld par local_infile désactivé. local_infile peut également être défini au moment de l’exécution. En raison des problèmes de sécurité associés à l’indicateur de local_infile, il est recommandé de le désactiver. Cette recommandation s’applique aux instances de base de données MySQL.

Gravité : moyenne

Vérifier que les alertes et le filtre de métrique du journal existent pour les changements d’autorisations IAM du stockage cloud

Description : il est recommandé d’établir un filtre de métrique et une alarme pour les modifications IAM du compartiment de stockage cloud. La surveillance des modifications apportées aux autorisations de compartiment de stockage cloud peut réduire le temps nécessaire pour détecter et corriger les autorisations sur les compartiments et objets de stockage cloud sensibles à l’intérieur du compartiment.

Gravité : faible

Vérifier que les alertes et le filtre de métrique du journal existent pour les modifications de la configuration d’instance SQL

Description : il est recommandé d’établir un filtre de métrique et une alarme pour les modifications de configuration de l’instance SQL. La surveillance des modifications apportées aux modifications de configuration d’instance SQL peut réduire le temps nécessaire pour détecter et corriger les configurations incorrectes effectuées sur le serveur SQL. Voici quelques-unes des options configurables qui peuvent avoir un impact sur la posture de sécurité d’une instance SQL :

• Activer les sauvegardes automatiques et la haute disponibilité : une configuration incorrecte peut avoir un impact négatif sur la continuité d’activité, la récupération d’urgence et la haute disponibilité
• Autoriser les réseaux : la configuration incorrecte peut augmenter l’exposition aux réseaux non approuvés

Gravité : faible

Vérifiez qu’il n’y a que des clés de compte de service gérées par GCP pour chaque compte de service

Description : Les comptes de service gérés par l’utilisateur ne doivent pas avoir de clés gérées par l’utilisateur. Toute personne ayant accès aux clés peut accéder aux ressources via le compte de service. Les clés gérées par GCP sont utilisées par les services de plateforme cloud comme App Engine et Compute Engine. Ces clés ne peuvent pas être téléchargées. Google conservera les clés et les fera pivoter automatiquement sur une base hebdomadaire environ. Les clés gérées par l’utilisateur sont créées, téléchargeables et gérées par les utilisateurs. Elles expirent 10 ans après leur création. Pour les clés gérées par l’utilisateur, l’utilisateur doit prendre possession des activités de gestion des clés, notamment :

• Stockage des clés
• Distribution de clés
• Révocation de la clé
• Rotation des clés
• Protection par clé contre les utilisateurs non autorisés
• Récupération de clé

Même avec les précautions des propriétaires clés, les clés peuvent être facilement divulguées par des pratiques de développement moins qu’optimales, telles que la vérification des clés dans le code source ou leur laisser dans le répertoire Téléchargements, ou les laisser accidentellement sur les blogs/canaux de support. Il est recommandé d’empêcher les clés de compte de service gérés par l’utilisateur.

Gravité : faible

Vérifiez que l’indicateur de base de données « connexions utilisateur » pour l’instance cloud SQL Server est défini comme approprié

Description : il est recommandé de définir l’indicateur de base de données « connexions utilisateur » pour l’instance SQL Server Cloud SQL Server en fonction de la valeur définie par l’organisation. L’option « user connections » spécifie le nombre maximal de connexions utilisateur simultanées autorisées sur une instance de SQL Server. Le nombre réel de connexions utilisateur autorisées dépend également de la version de SQL Server que vous utilisez, ainsi que des limites de votre application ou applications et matériels. SQL Server autorise un maximum de 32 767 connexions utilisateurs. Étant donné que les connexions utilisateur sont une option dynamique (autoconfiguration), SQL Server ajuste automatiquement le nombre maximal de connexions utilisateur si nécessaire, jusqu’à la valeur maximale autorisée. Par exemple, si seuls 10 utilisateurs sont connectés, 10 objets connexion utilisateur sont alloués. Dans la plupart des cas, vous n’avez pas besoin de modifier la valeur de cette option. La valeur par défaut est zéro, ce qui signifie que le nombre maximal (32 767) de connexions utilisateur est autorisé. Cette recommandation s’applique aux instances de base de données SQL Server.

Gravité : faible

Vérifier que l’indicateur de base de données « options utilisateur » pour l’instance cloud SQL Server n’est pas configuré

Description : Il est recommandé de ne pas configurer l’indicateur de base de données « options utilisateur » pour l’instance SQL Server Cloud SQL Server. L’option « user options » spécifie des valeurs par défaut globales pour tous les utilisateurs. Une liste d'options de traitement des requêtes par défaut est générée pour la durée d'une session de travail d'un utilisateur. Le paramètre d’options utilisateur vous permet de modifier les valeurs par défaut des options SET (si les paramètres par défaut du serveur ne sont pas appropriés). L'utilisateur peut remplacer ces valeurs par défaut à l'aide de l'instruction SET. Pour les nouvelles connexions, vous pouvez configurer dynamiquement l'option user options . Après avoir modifié le paramètre des options utilisateur, les nouvelles sessions de connexion utilisent le nouveau paramètre ; Les sessions de connexion actuelles ne sont pas affectées. Cette recommandation s’applique aux instances de base de données SQL Server.

Gravité : faible

La journalisation pour les clusters GKE doit être activée

Description : cette recommandation évalue si la propriété loggingService d’un cluster contient l’emplacement que la journalisation cloud doit utiliser pour écrire des journaux.

Gravité : élevée

Le contrôle de version d’objet doit être activé sur les compartiments de stockage où les récepteurs sont configurés

Description : cette recommandation évalue si le champ activé dans la propriété de contrôle de version du compartiment a la valeur true.

Gravité : élevée

Les identités surprovisionnées dans les projets doivent être examinées pour réduire l’index d’analyse des autorisations

Description : les identités surprovisionnée dans les projets doivent être examinées pour réduire l’index PCI (Permission Creep Index) et protéger votre infrastructure. Réduisez l’index PCI en supprimant les attributions d’autorisations à haut risque inutilisées. La norme PCI élevée reflète les risques associés aux identités disposant d’autorisations qui dépassent leur utilisation normale ou requise.

Gravité : moyenne

Les projets qui ont des clés de chiffrement ne doivent pas avoir d’utilisateurs disposant d’autorisations de propriétaire

Description : cette recommandation évalue la stratégie d’autorisation IAM dans les métadonnées de projet pour les principaux affectés aux rôles/propriétaires.

Gravité : moyenne

Les compartiments de stockage utilisés comme récepteur de journaux ne doivent pas être accessibles publiquement

Description : cette recommandation évalue la stratégie IAM d’un compartiment pour les principaux allUsers ou allAuthenticatedUsers, qui accordent un accès public.

Gravité : élevée

Contenu connexe

• En savoir plus sur les recommandations de sécurité
• Passer en revue les recommandations de sécurité