Recommandations relatives à la sécurité des identités et des accès

Cet article répertorie toutes les recommandations de sécurité d’identité et d’accès 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.

Recommandations relatives aux identités et aux accès Azure

Un maximum de trois propriétaires doit être désigné pour les abonnements

Description : Pour réduire le risque de violations par les comptes propriétaire compromis, nous vous recommandons de limiter le nombre de comptes propriétaires à un maximum de 3 (stratégie associée : un maximum de 3 propriétaires doit être désigné pour votre abonnement).

Gravité : élevée

Les comptes disposant d’autorisations de propriétaire sur les ressources Azure doivent être compatibles avec l’authentification multifacteur

Description : Si vous utilisez uniquement des mots de passe pour authentifier vos utilisateurs, vous laissez un vecteur d’attaque ouvert. Les utilisateurs utilisent souvent des mots de passe faibles pour plusieurs services. En activant l’authentification multifacteur (MFA), vous fournissez une meilleure sécurité pour vos comptes, tout en permettant à vos utilisateurs de s’authentifier auprès de presque n’importe quelle application avec l’authentification unique (SSO). L’authentification multifacteur est un processus par lequel les utilisateurs sont invités, pendant le processus de connexion, pour une autre forme d’identification. Par exemple, un code peut être envoyé à son téléphone portable, ou il peut être demandé une analyse d’empreinte digitale. Nous vous recommandons d’activer MFA pour tous les comptes disposant d’autorisations de propriétaire sur les ressources Azure, afin d’éviter toute violation et les attaques. Vous trouverez plus de détails et de questions fréquemment posées ici : Gérez l’application de l’authentification multifacteur (MFA) sur vos abonnements (aucune stratégie associée).

Gravité : élevée

Les comptes disposant d’autorisations en lecture sur les ressources Azure doivent être compatibles avec l’authentification multifacteur

Description : Si vous utilisez uniquement des mots de passe pour authentifier vos utilisateurs, vous laissez un vecteur d’attaque ouvert. Les utilisateurs utilisent souvent des mots de passe faibles pour plusieurs services. En activant l’authentification multifacteur (MFA), vous fournissez une meilleure sécurité pour vos comptes, tout en permettant à vos utilisateurs de s’authentifier auprès de presque n’importe quelle application avec l’authentification unique (SSO). L’authentification multifacteur est un processus par lequel les utilisateurs sont invités, pendant le processus de connexion, pour une forme supplémentaire d’identification. Par exemple, un code peut être envoyé à son téléphone portable, ou il peut être demandé une analyse d’empreinte digitale. Nous vous recommandons d’activer MFA pour tous les comptes disposant d’autorisations de lecture sur les ressources Azure, afin d’éviter toute violation et les attaques. Vous trouverez ici plus de détails et de questions fréquemment posées. (Aucune stratégie associée)

Gravité : élevée

Les comptes disposant d’autorisations en écriture sur les ressources Azure doivent être compatibles avec l’authentification multifacteur

Description : Si vous utilisez uniquement des mots de passe pour authentifier vos utilisateurs, vous laissez un vecteur d’attaque ouvert. Les utilisateurs utilisent souvent des mots de passe faibles pour plusieurs services. En activant l’authentification multifacteur (MFA), vous fournissez une meilleure sécurité pour vos comptes, tout en permettant à vos utilisateurs de s’authentifier auprès de presque n’importe quelle application avec l’authentification unique (SSO). L’authentification multifacteur est un processus par lequel les utilisateurs sont invités, pendant le processus de connexion, pour une forme supplémentaire d’identification. Par exemple, un code peut être envoyé à son téléphone portable, ou il peut être demandé une analyse d’empreinte digitale. Nous vous recommandons d’activer MFA pour tous les comptes disposant d’autorisations d’écriture sur les ressources Azure, afin d’éviter toute violation et les attaques. Vous trouverez plus de détails et de questions fréquemment posées ici : Gérez l’application de l’authentification multifacteur (MFA) sur vos abonnements (aucune stratégie associée).

Gravité : élevée

Les comptes Azure Cosmos DB doivent utiliser Azure Active Directory comme seule méthode d’authentification

Description : La meilleure façon de s’authentifier auprès des services Azure consiste à utiliser le contrôle d’accès en fonction du rôle (RBAC). RBAC vous permet de conserver le principe de privilège minimal et prend en charge la possibilité de révoquer des autorisations comme méthode de réponse efficace en cas de compromission. Vous pouvez configurer votre compte Azure Cosmos DB pour appliquer le contrôle RBAC comme seule méthode d’authentification. Lorsque l’application est configurée, toutes les autres méthodes d’accès sont refusées (clés primaires/secondaires et jetons d’accès). (Aucune stratégie associée)

Gravité : moyenne

Les comptes bloqués disposant d’autorisations de propriétaire sur les ressources Azure doivent être supprimés

Description : Les comptes qui ont été bloqués de se connecter à Active Directory doivent être supprimés de vos ressources Azure. Ces comptes peuvent être des cibles pour les attaquants qui cherchent des moyens d’accéder à vos données sans être remarqués. (Aucune stratégie associée)

Gravité : élevée

Les comptes bloqués disposant d’autorisations en lecture et en écriture sur les ressources Azure doivent être supprimés

Description : Les comptes qui ont été bloqués de se connecter à Active Directory doivent être supprimés de vos ressources Azure. Ces comptes peuvent être des cibles pour les attaquants qui cherchent des moyens d’accéder à vos données sans être remarqués. (Aucune stratégie associée)

Gravité : élevée

Les comptes déconseillés doivent être supprimés des abonnements

Description : Les comptes d’utilisateur qui ont été bloqués de se connecter doivent être supprimés de vos abonnements. Ces comptes peuvent être des cibles pour les attaquants qui cherchent des moyens d’accéder à vos données sans être remarqués. (Stratégie associée : Les comptes déconseillés doivent être supprimés de votre abonnement.

Gravité : élevée

Les comptes déconseillés disposant d’autorisations de propriétaire doivent être supprimés des abonnements

Description : Les comptes d’utilisateur qui ont été bloqués de se connecter doivent être supprimés de vos abonnements. Ces comptes peuvent être des cibles pour les attaquants qui cherchent des moyens d’accéder à vos données sans être remarqués. (Stratégie associée : Les comptes déconseillés disposant d’autorisations de propriétaire doivent être supprimés de votre abonnement.

Gravité : élevée

Les journaux de diagnostic dans Key Vault 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 Key Vault doivent être activés).

Gravité : faible

Les comptes externes disposant d’autorisations de propriétaire doivent être supprimés des abonnements

Description : Les comptes disposant d’autorisations de propriétaire qui ont différents noms de domaine (comptes externes) doivent être supprimés de votre abonnement. Cela empêche tout accès non supervisé. Ces comptes peuvent être des cibles pour les attaquants qui cherchent des moyens d’accéder à vos données sans être remarqués. (Stratégie associée : Les comptes externes disposant d’autorisations de propriétaire doivent être supprimés de votre abonnement.

Gravité : élevée

Les comptes externes disposant d’autorisations d’accès en lecture doivent être supprimés des abonnements

Description : Les comptes disposant d’autorisations de lecture qui ont différents noms de domaine (comptes externes) doivent être supprimés de votre abonnement. Cela empêche tout accès non supervisé. Ces comptes peuvent être des cibles pour les attaquants qui cherchent des moyens d’accéder à vos données sans être remarqués. (Stratégie associée : Les comptes externes disposant d’autorisations de lecture doivent être supprimés de votre abonnement.

Gravité : élevée

Les comptes externes disposant d’autorisations d’accès en écriture doivent être supprimés des abonnements

Description : Les comptes disposant d’autorisations d’écriture qui ont différents noms de domaine (comptes externes) doivent être supprimés de votre abonnement. Cela empêche tout accès non supervisé. Ces comptes peuvent être des cibles pour les attaquants qui cherchent des moyens d’accéder à vos données sans être remarqués. (Stratégie associée : Les comptes externes disposant d’autorisations d’écriture doivent être supprimés de votre abonnement.

Gravité : élevée

Le pare-feu doit être activé sur Key Vault

Description : le pare-feu du coffre de clés empêche tout trafic non autorisé d’atteindre votre coffre de clés et fournit une couche supplémentaire de protection pour vos secrets. Activez le pare-feu pour que seul le trafic provenant des réseaux autorisés puisse accéder à votre coffre de clés. (Stratégie associée : Le pare-feu doit être activé sur Key Vault).

Gravité : moyenne

Les comptes invités disposant d’autorisations de propriétaire sur les ressources Azure doivent être supprimés

Description : Les comptes disposant d’autorisations de propriétaire qui ont été provisionnés en dehors du locataire Azure Active Directory (noms de domaine différents) doivent être supprimés de vos ressources Azure. Les comptes invités ne sont pas gérés selon les mêmes normes que les identités de locataire d’entreprise. Ces comptes peuvent être des cibles pour les attaquants qui cherchent des moyens d’accéder à vos données sans être remarqués. (Aucune stratégie associée)

Gravité : élevée

Les comptes invités disposant d’autorisations en lecture sur les ressources Azure doivent être supprimés

Description : Les comptes disposant d’autorisations de lecture qui ont été provisionnés en dehors du locataire Azure Active Directory (différents noms de domaine) doivent être supprimés de vos ressources Azure. Les comptes invités ne sont pas gérés selon les mêmes normes que les identités de locataire d’entreprise. Ces comptes peuvent être des cibles pour les attaquants qui cherchent des moyens d’accéder à vos données sans être remarqués. (Aucune stratégie associée)

Gravité : élevée

Les comptes invités disposant d’autorisations en écriture sur les ressources Azure doivent être supprimés

Description : Les comptes disposant d’autorisations d’écriture qui ont été provisionnés en dehors du locataire Azure Active Directory (différents noms de domaine) doivent être supprimés de vos ressources Azure. Les comptes invités ne sont pas gérés selon les mêmes normes que les identités de locataire d’entreprise. Ces comptes peuvent être des cibles pour les attaquants qui cherchent des moyens d’accéder à vos données sans être remarqués. (Aucune stratégie associée)

Gravité : élevée

Les clés Key Vault doivent avoir une date d’expiration

Description : Les clés de chiffrement doivent avoir une date d’expiration définie et ne pas être permanentes. Les clés valides indéfiniment offrent à un intrus potentiel plus de temps pour compromettre la clé. Il est recommandé de définir des dates d’expiration sur les clés de chiffrement. (Stratégie associée : Les clés Key Vault doivent avoir une date d’expiration).

Gravité : élevée

Les secrets Key Vault doivent avoir une date d’expiration

Description : Les secrets doivent avoir une date d’expiration définie et ne pas être permanents. Les secrets valides indéfiniment offrent à un attaquant potentiel plus de temps pour les compromettre. Il est recommandé de définir les dates d’expiration sur les secrets. (Stratégie associée : Les secrets Key Vault doivent avoir une date d’expiration).

Gravité : élevée

La protection contre la suppression définitive doit être activée sur les coffres de clés

Description : La suppression malveillante d’un coffre de clés peut entraîner une perte de données permanente. Une personne malveillante interne à votre organisation peut potentiellement supprimer et vider des coffres de clés. La protection contre la suppression définitive vous protège des attaques internes en appliquant une période de conservation obligatoire pour les coffres de clés supprimés de manière réversible. Personne au sein de votre organisation ni chez Microsoft ne pourra supprimer définitivement vos coffres de clés pendant la période de conservation de la suppression réversible. (Stratégie associée : Les coffres de clés doivent avoir activé la protection contre le vidage.

Gravité : moyenne

La suppression réversible doit être activée sur les coffres de clés

Description : la suppression d’un coffre de clés sans suppression réversible activée supprime définitivement tous les secrets, clés et certificats stockés dans le coffre de clés. La suppression accidentelle d’un coffre de clés peut entraîner la perte définitive des données. La suppression réversible vous permet de récupérer un coffre de clés supprimé accidentellement, pendant une période de conservation configurable. (Stratégie associée : Les coffres de clés doivent avoir la suppression réversible activée).

Gravité : élevée

L’authentification multifacteur doit être activée sur les comptes disposant d’autorisations de propriétaire sur les abonnements

Description : L’authentification multifacteur (MFA) doit être activée pour tous les comptes d’abonnement disposant d’autorisations de propriétaire pour empêcher une violation de comptes ou de ressources. (Stratégie associée : L’authentification multifacteur doit être activée sur les comptes disposant d’autorisations de propriétaire sur votre abonnement.

Gravité : élevée

L’authentification multifacteur doit être activée sur les comptes disposant d’autorisations d’accès en lecture les abonnements

Description : L’authentification multifacteur (MFA) doit être activée pour tous les comptes d’abonnement disposant de privilèges de lecture pour empêcher une violation de comptes ou de ressources. (Stratégie associée : L’authentification multifacteur doit être activée sur les comptes disposant d’autorisations de lecture sur votre abonnement.

Gravité : élevée

L’authentification multifacteur doit être activée sur les comptes disposant d’autorisations d’accès en écriture sur les abonnements

Description : L’authentification multifacteur (MFA) doit être activée pour tous les comptes d’abonnement disposant de privilèges d’écriture pour empêcher une violation de comptes ou de ressources. (Stratégie associée : L’authentification multifacteur doit être activée pour les comptes disposant d’autorisations d’écriture sur votre abonnement.

Gravité : élevée

Microsoft Defender pour Key Vault doit être activé

Description : Microsoft Defender pour le cloud inclut Microsoft Defender pour Key Vault, fournissant une couche supplémentaire d’intelligence de sécurité. Microsoft Defender pour Key Vault détecte les tentatives inhabituelles et potentiellement dangereuses d’accès ou d’exploitation des comptes Key Vault.

Les protections de ce plan sont facturées comme indiqué dans la page plans Defender. Si vous n’avez aucun coffre de clés dans cet abonnement, vous ne serez pas facturé. Si vous créez par la suite des coffres de clés 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 Key Vault. (Stratégie associée : Azure Defender pour Key Vault doit être activé).

Gravité : élevée

Les autorisations des identités inactives dans votre abonnement Azure doivent être révoquées

Description : Microsoft Defender pour le cloud découvert une identité qui n’a effectué aucune action sur une ressource dans votre abonnement Azure au cours des 45 derniers jours. Il est recommandé de révoquer les autorisations des identités inactives afin de réduire la surface d’attaque de votre environnement cloud.

Gravité : moyenne

Le point de terminaison privé doit être configuré pour Key Vault

Description : Une liaison privée permet de connecter Key Vault à vos ressources Azure sans envoyer de trafic via l’Internet public. Un lien privé assure une protection en profondeur contre l’exfiltration des données. (Stratégie associée : Le point de terminaison privé doit être configuré pour Key Vault).

Gravité : moyenne

L’accès public au compte de stockage doit être interdit

Description : L’accès en lecture publique anonyme aux conteneurs et aux objets blob dans Stockage Azure est un moyen pratique de partager des données, mais peut présenter des risques de sécurité. Pour éviter les violations de données provoquées par un accès anonyme non souhaité, Microsoft recommande d’empêcher l’accès public à un compte de stockage, sauf si votre scénario l’exige. (Stratégie associée : L’accès public du compte de stockage doit être interdit).

Gravité : moyenne

Il doit y avoir plus d’un propriétaire attribué aux abonnements

Description : désignez plusieurs propriétaires d’abonnement afin d’avoir une redondance d’accès administrateur. (Stratégie associée : Plusieurs propriétaires doivent être affectés à votre abonnement.

Gravité : élevée

La période de validité des certificats stockés dans Azure Key Vault ne doit pas dépasser 12 mois

Description : Vérifiez que vos certificats n’ont pas de période de validité supérieure à 12 mois. (Stratégie associée : Les certificats doivent avoir la période de validité maximale spécifiée.

Gravité : moyenne

Les identités surprovisionnés Azure doivent disposer uniquement des autorisations nécessaires (préversion)

Description : les identités surprovisionnée ou les identités sur-autorisées n’utilisent pas beaucoup de leurs autorisations accordées. Autorisations de taille régulière de ces identités pour réduire le risque d’utilisation incorrecte des autorisations, accidentelles ou malveillantes. Cette action réduit le rayon d’explosion potentiel pendant un incident de sécurité.

Gravité : moyenne

Les rôles privilégiés ne doivent pas avoir d’accès permanent au niveau de l’abonnement et du groupe de ressources

Description : Microsoft Defender pour le cloud découvert une identité qui n’a effectué aucune action sur une ressource dans votre abonnement Azure au cours des 45 derniers jours. Il est recommandé de révoquer les autorisations des identités inactives afin de réduire la surface d’attaque de votre environnement cloud.

Gravité : élevée

Des rôles d’administration ne doivent pas être affectés aux principaux de service au niveau de l’abonnement et du groupe de ressources

Description : Defender pour le cloud principaux de service identifiés qui sont affectés avec des rôles privilégiés au niveau du groupe de ressources ou de l’abonnement. Les rôles d’administrateur privilégié sont des rôles qui peuvent effectuer des opérations sensibles sur la ressource, telles que propriétaire, contributeur ou administrateur de l’accès utilisateur. Les principaux de service jouent un rôle crucial dans la gestion efficace et sécurisée des ressources Azure, ce qui élimine la nécessité d’une intervention humaine. Il est important de suivre le principe du privilège minimum, d’accorder uniquement le niveau minimal d’accès nécessaire pour qu’un principal de service donné effectue ses tâches. Les administrateurs et l’accès privilégié sont la cible principale des pirates informatiques. Pour connaître les meilleures pratiques lors de l’utilisation des attributions de rôles d’administrateur privilégiés, consultez Meilleures pratiques pour Azure RBAC. Bonnes pratiques pour Azure RBAC. Pour obtenir la liste des rôles disponibles dans Azure RBAC, consultez les rôles intégrés d’Azure.

Gravité : élevée

Recommandations d’identité et d’accès AWS

Les domaines Amazon Elasticsearch Service doivent se trouver dans un VPC

Description : LE VPC ne peut pas contenir de domaines avec un point de terminaison public. Cela n’évalue pas la configuration de routage du sous-réseau DU VPC pour déterminer l’accessibilité publique.

Gravité : élevée

Les autorisations Amazon S3 accordées à d’autres comptes AWS dans les stratégies de compartiment doivent être restreintes

Description : L’implémentation de l’accès au privilège minimum est fondamentale pour réduire les risques de sécurité et l’impact des erreurs ou des intentions malveillantes. Si une stratégie de compartiment S3 autorise l’accès à partir de comptes externes, cela pourrait entraîner l’exfiltration de données par une menace interne ou un attaquant. Le paramètre « blacklistedactionpatterns » permet une évaluation réussie de la règle pour les compartiments S3. Le paramètre accorde l’accès aux comptes externes pour les modèles d’action qui ne sont pas inclus dans la liste « blacklistedactionpatterns ».

Gravité : élevée

Éviter d’utiliser le compte « racine »

Description : Le compte « racine » a un accès illimité à toutes les ressources du compte AWS. Il est vivement recommandé d’éviter l’utilisation de ce compte. Le compte « racine » est le compte AWS le plus privilégié. En limitant l’utilisation de ce compte et en adoptant le principe du moindre privilège pour la gestion des accès, vous réduirez le risque de modifications accidentelles et de divulgation involontaire d’informations d’identification à privilèges élevés.

Gravité : élevée

Les clés AWS KMS ne doivent pas être supprimées involontairement

Description : ce contrôle vérifie si les clés KMS sont planifiées pour suppression. Le contrôle échoue si la suppression d’une clé KMS est planifiée. Les clés KMS ne peuvent pas être récupérées une fois supprimées. Les données chiffrées sous une clé KMS sont également irrémédiablement irrécupérables si la clé KMS est supprimée. Si des données significatives ont été chiffrées sous une clé KMS planifiée pour suppression, envisagez de déchiffrer les données ou de rechiffrer les données sous une nouvelle clé KMS, sauf si vous effectuez intentionnellement un effacement de chiffrement. Lorsque la suppression d’une clé KMS est planifiée, un délai d’attente obligatoire est appliqué pour permettre d’annuler la suppression, si elle a été planifiée par erreur. La période d’attente par défaut est de 30 jours, mais elle peut être réduite à moins de sept jours lorsque la clé KMS est planifiée pour suppression. Pendant la période d’attente, la suppression planifiée peut être annulée et la clé KMS ne sera pas supprimée. Pour plus d’informations sur la suppression de clés KMS, consultez le Guide de suppression des clés KMS dans aws Service de gestion de clés Developer Guide.

Gravité : élevée

Les identités surprovisionnés AWS doivent disposer uniquement des autorisations nécessaires (préversion)

Description : une identité active sur provisionnée est une identité qui a accès aux privilèges qu’ils n’ont pas utilisés. Les identités actives sur provisionnée, en particulier pour les comptes non humains qui ont défini des actions et des responsabilités, peuvent augmenter le rayon d’explosion en cas de compromission d’un utilisateur, d’une clé ou d’une ressource. Supprimez les autorisations inutiles et établissez des processus de révision pour obtenir les autorisations les moins privilégiées.

Gravité : moyenne

La journalisation d’une ACL web mondiale d’AWS WAF classique doit être activée

Description : ce contrôle vérifie si la journalisation est activée pour une ACL web globale AWS WAF. Ce contrôle échoue si la journalisation n’est pas activée pour la liste de contrôle d’accès web. La journalisation est un élément important du maintien de la fiabilité, de la disponibilité et du niveau de performance d’AWS WAF dans le monde entier. Il s’agit d’une exigence métier et de conformité dans de nombreuses organisations et vous permet de résoudre les problèmes de comportement de l’application. Elle fournit également des informations détaillées sur le trafic analysé par l’ACL web qui est attachée à AWS WAF.

Gravité : moyenne

Les distributions CloudFront doivent avoir un objet racine par défaut configuré

Description : ce contrôle vérifie si une distribution Amazon CloudFront est configurée pour retourner un objet spécifique qui est l’objet racine par défaut. Le contrôle échoue si la distribution CloudFront n’a pas d’objet racine par défaut configuré. Un utilisateur peut parfois demander l’URL racine de la distribution au lieu d’un objet dans la distribution. Dans ce cas, la spécification d’un objet racine par défaut peut vous aider à éviter d’exposer le contenu de votre distribution web.

Gravité : élevée

Les distributions CloudFront doivent avoir une identité d’accès à l’origine activée

Description : ce contrôle vérifie si une distribution Amazon CloudFront avec le type d’origine Amazon S3 a l’identité d’accès d’origine (OAI) configurée. Le contrôle échoue si OAI n’est pas configuré. L’OAI CloudFront empêche les utilisateurs d’accéder directement au contenu d’un compartiment S3. Lorsque les utilisateurs accèdent directement à un compartiment S3, ils contournent efficacement la distribution CloudFront et toutes les autorisations qui sont appliquées au contenu du compartiment S3 sous-jacent.

Gravité : moyenne

La validation du fichier journal CloudTrail doit être activée

Description : Pour vérifier l’intégrité supplémentaire des journaux CloudTrail, nous vous recommandons d’activer la validation des fichiers sur tous les CloudTrails.

Gravité : faible

CloudTrail doit être activé

Description : AWS CloudTrail est un service web qui enregistre les appels d’API AWS pour votre compte et vous remet les fichiers journaux. Tous les services n’activent pas la journalisation par défaut pour toutes les API et tous les événements. Vous devez implémenter des pistes d’audit supplémentaires autres que CloudTrail et consulter la documentation de chaque service dans Services et intégrations pris en charge par CloudTrail.

Gravité : élevée

Les pistes CloudTrail doivent être intégrées à CloudWatch Logs

Description : Outre la capture des journaux CloudTrail dans un compartiment S3 spécifié pour l’analyse à long terme, l’analyse en temps réel peut être effectuée en configurant CloudTrail pour envoyer des journaux à CloudWatch Logs. Pour qu’une piste soit activée dans toutes les régions d’un compte, CloudTrail envoie les fichiers journaux de toutes ces régions à un groupe de journaux CloudWatch Logs. Nous vous recommandons d’envoyer les journaux CloudTrail à CloudWatch Logs pour garantir que l’activité du compte AWS est capturée, surveillée et fait l’objet des alarmes appropriées. L’envoi de journaux CloudTrail à CloudWatch Logs facilite la journalisation des activités en temps réel et historique en fonction de l’utilisateur, de l’API, de la ressource et de l’adresse IP et permet d’établir des alarmes et des notifications pour l’activité anormale ou sensible du compte.

Gravité : faible

La journalisation de la base de données doit être activée

Description : Ce contrôle vérifie si les journaux d’activité suivants d’Amazon RDS sont activés et envoyés aux journaux CloudWatch :

• Oracle : (Alerte, Audit, Trace, Écouteur)
• PostgreSQL : (Postgresql, mise à niveau)
• MySQL : (Audit, Erreur, Général, SlowQuery)
• MariaDB : (Audit, Erreur, Général, SlowQuery)
• SQL Server : (Erreur, Agent)
• Aurora : (Audit, Erreur, Général, SlowQuery)
• Aurora-MySQL : (Audit, Erreur, Général, SlowQuery)
• Aurora-PostgreSQL : (Postgresql, Mise à niveau). Les journaux appropriés doivent être activés dans les bases de données RDS. La journalisation de base de données fournit des enregistrements détaillés des requêtes adressées à RDS. Les journaux de base de données peuvent faciliter les audits de sécurité et d’accès et peuvent aider à diagnostiquer les problèmes de disponibilité.

Gravité : moyenne

Désactiver l’accès Internet direct pour les instances de notebook Amazon Sage Maker

Description : L’accès Direct à Internet doit être désactivé pour une instance de notebook Sage Maker. Cette opération vérifie si le champ « DirectInternetAccess » est désactivé pour l’instance de notebook. Votre instance doit être configurée avec un VPC, et le paramètre par défaut doit être Désactiver : Accéder à Internet via un VPC. Pour permettre l’accès à Internet pour l’apprentissage ou l’hébergement de modèles à partir d’un notebook, assurez-vous que votre VPC dispose d’une passerelle NAT et que votre groupe de sécurité autorise les connexions sortantes. Vérifiez que l’accès à votre configuration Sage Maker est limité uniquement aux utilisateurs autorisés et limitez les autorisations IAM des utilisateurs pour modifier les paramètres et les ressources Sage Maker.

Gravité : élevée

Ne pas configurer de clés d’accès lors de la configuration initiale de l’utilisateur pour tous les utilisateurs IAM qui ont un mot de passe de console

Description : la console AWS cochée par défaut la case à cocher permettant de créer des clés d’accès activées. En conséquence, de nombreuses clés d’accès sont générées inutilement. Outre les informations d’identification inutiles, cela génère également un travail de gestion inutile pour l’audit et la rotation de ces clés. Exiger que des mesures supplémentaires soient prises par l’utilisateur une fois son profil créé donnera une indication plus forte de l’intention que les clés d’accès sont [a] nécessaires pour leur travail et [b] une fois que la clé d’accès est établie sur un compte que les clés peuvent être utilisées quelque part dans l’organisation.

Gravité : moyenne

Vérifier qu’un rôle de support a été créé pour gérer les incidents avec le support AWS

Description : AWS fournit un centre de support qui peut être utilisé pour la notification et la réponse aux incidents, ainsi que le support technique et les services clients. Créez un rôle IAM pour permettre aux utilisateurs autorisés de gérer les incidents avec le support AWS. Lorsque vous implémentez le privilège minimum pour le contrôle d’accès, un rôle IAM nécessite une stratégie IAM appropriée pour autoriser l’accès au Centre d’aide et de support pour gérer les incidents avec aws Support.

Gravité : faible

Vérifier que les clés d’accès font l’objet d’une rotation tous les 90 jours ou moins

Description : les clés d’accès se composent d’un ID de clé d’accès et d’une clé d’accès secrète, qui sont utilisées pour signer des demandes programmatiques que vous effectuez dans AWS. Les utilisateurs d’AWS ont besoin de leurs propres clés d’accès pour adresser des appels programmatiques à AWS à partir de l’interface de ligne de commande AWS (AWS CLI), des outils pour Windows PowerShell, des Kits de développement logiciel (SDK) AWS ou des appels HTTP directs utilisant les API pour les services AWS individuels. Il est recommandé que toutes les clés d’accès soient régulièrement pivotées. La rotation des clés d’accès réduit la fenêtre d’opportunité d’une clé d’accès associée à un compte compromis ou arrêté à utiliser. Les clés d’accès doivent être pivotées pour s’assurer que les données ne sont pas accessibles avec une ancienne clé, qui a peut-être été perdue, craquelée ou volée.

Gravité : moyenne

Vérifier qu’AWS Config est activé dans toutes les régions

Description : AWS Config est un service web qui effectue la gestion de la configuration des ressources AWS prises en charge au sein de votre compte et vous remet les fichiers journaux. Les informations enregistrées incluent l’élément de configuration (ressource AWS), les relations entre les éléments de configuration (ressources AWS) et toute modification de configuration entre les ressources. Il est recommandé d’activer AWS Config dans toutes les régions.

L’historique des éléments de configuration AWS capturé par AWS Config permet l’analyse de la sécurité, le suivi des modifications des ressources et l’audit de la conformité.

Gravité : moyenne

Vérifier que CloudTrail est activé dans toutes les régions

Description : AWS CloudTrail est un service web qui enregistre les appels d’API AWS pour votre compte et vous remet les fichiers journaux. Les informations enregistrées incluent l’identité de l’appelant de l’API, l’heure de l’appel d’API, l’adresse IP source de l’appelant de l’API, les paramètres de la requête et les éléments de réponse renvoyés par le service AWS. CloudTrail fournit un historique des appels d’API AWS pour un compte, y compris les appels d’API effectués via la console de gestion, les Kits de développement logiciel (SDK), les outils de ligne de commande et les services AWS de niveau supérieur (tels que CloudFormation). L’historique des appels de l’API AWS produit par CloudTrail permet l’analyse de la sécurité, le suivi des modifications des ressources et l’audit de la conformité. Voici quelques ajustements supplémentaires :

• La vérification qu’une piste multirégion existe garantit que l’activité inattendue qui se produit dans d’autres régions inutilisées est détectée.
• La vérification qu’une piste multirégion existe garantit que la « journalisation des services globaux » est activée pour une piste par défaut pour capturer l’enregistrement des événements générés sur les services globaux AWS.
• Pour une piste multirégion, la vérification que les événements de gestion sont configurés pour tous les types de lectures/écritures garantit l’enregistrement des opérations de gestion effectuées sur toutes les ressources d’un compte AWS.

Gravité : élevée

Vérifier que les informations d’identification inutilisées pendant 90 jours ou plus sont désactivées

Description : les utilisateurs AWS IAM peuvent accéder aux ressources AWS à l’aide de différents types d’informations d’identification, tels que les mots de passe ou les clés d’accès. Il est recommandé que toutes les informations d’identification qui n’ont pas été utilisées dans 90 jours ou plus soient supprimées ou désactivées. La désactivation ou la suppression d’informations d’identification inutiles réduisent la fenêtre d’opportunité des informations d’identification associées à un compte compromis ou abandonné à utiliser.

Gravité : moyenne

Veiller à ce que la stratégie de mot de passe IAM fasse expirer les mots de passe dans un délai de 90 jours ou moins

Description : les stratégies de mot de passe IAM peuvent exiger que les mots de passe soient pivotés ou expirés après un nombre donné de jours. Il est recommandé que la stratégie de mot de passe expire les mots de passe après 90 jours ou moins. La réduction de la durée de vie des mots de passe augmente la résilience des comptes contre les tentatives de connexion par force brute. De plus, le fait d’exiger des changements réguliers de mot de passe aide dans les scénarios suivants :

• Les mots de passe peuvent être volés ou compromis parfois sans vos connaissances. Cela peut se produire par le biais d’une compromission du système, d’une vulnérabilité du logiciel ou d’une menace interne.
• Certains filtres web d’entreprise et de gouvernement ou serveurs proxy ont la possibilité d’intercepter et d’enregistrer le trafic même s’il est chiffré.
• De nombreuses personnes utilisent le même mot de passe pour de nombreux systèmes tels que le travail, l’e-mail et le personnel.
• Les stations de travail des utilisateurs finaux compromises peuvent avoir un enregistreur d’événements de séquence de touches.

Gravité : faible

Vérifier que la stratégie de mot de passe IAM empêche la réutilisation du mot de passe

Description : les stratégies de mot de passe IAM peuvent empêcher la réutilisation d’un mot de passe donné par le même utilisateur. Il est recommandé que la stratégie de mot de passe empêche la réutilisation des mots de passe. Empêcher la réutilisation des mots de passe augmente la résilience des comptes contre les tentatives de connexion par force brute.

Gravité : faible

Vérifier que la stratégie de mot de passe IAM requiert au moins une lettre minuscule

Description : Les stratégies de mot de passe sont, en partie, utilisées pour appliquer les exigences de complexité du mot de passe. Les stratégies de mot de passe IAM peuvent être utilisées pour garantir que le mot de passe est composé de jeux de caractères différents. Il est recommandé que la stratégie de mot de passe nécessite au moins une lettre minuscule. La mise en place d’une stratégie de complexité des mots de passe augmente la résilience des comptes contre les tentatives de connexion par force brute.

Gravité : moyenne

Vérifier que la stratégie de mot de passe IAM requiert au moins un chiffre

Description : Les stratégies de mot de passe sont, en partie, utilisées pour appliquer les exigences de complexité du mot de passe. Les stratégies de mot de passe IAM peuvent être utilisées pour garantir que le mot de passe est composé de jeux de caractères différents. Il est recommandé que la stratégie de mot de passe nécessite au moins un nombre. La mise en place d’une stratégie de complexité des mots de passe augmente la résilience des comptes contre les tentatives de connexion par force brute.

Gravité : moyenne

Vérifier que la stratégie de mot de passe IAM requiert au moins un symbole

Description : Les stratégies de mot de passe sont, en partie, utilisées pour appliquer les exigences de complexité du mot de passe. Les stratégies de mot de passe IAM peuvent être utilisées pour garantir que le mot de passe est composé de jeux de caractères différents. Il est recommandé que la stratégie de mot de passe nécessite au moins un symbole. La mise en place d’une stratégie de complexité des mots de passe augmente la résilience des comptes contre les tentatives de connexion par force brute.

Gravité : moyenne

Vérifier que la stratégie de mot de passe IAM requiert au moins une lettre majuscule

Description : Les stratégies de mot de passe sont, en partie, utilisées pour appliquer les exigences de complexité du mot de passe. Les stratégies de mot de passe IAM peuvent être utilisées pour garantir que le mot de passe est composé de jeux de caractères différents. Il est recommandé que la stratégie de mot de passe nécessite au moins une lettre majuscule. La mise en place d’une stratégie de complexité des mots de passe augmente la résilience des comptes contre les tentatives de connexion par force brute.

Gravité : moyenne

Vérifier que la stratégie de mot de passe IAM requiert une longueur minimale de 14 caractères ou plus

Description : Les stratégies de mot de passe sont, en partie, utilisées pour appliquer les exigences de complexité du mot de passe. Les stratégies de mot de passe IAM peuvent être utilisées pour s’assurer que les mots de passe ont au moins une longueur donnée. Il est recommandé que la stratégie de mot de passe nécessite une longueur minimale de mot de passe « 14 ». La mise en place d’une stratégie de complexité des mots de passe augmente la résilience des comptes contre les tentatives de connexion par force brute.

Gravité : moyenne

Vérifiez que l’authentification multifacteur (MFA) est activée pour tous les utilisateurs IAM disposant d’un mot de passe de console

Description : L’authentification multifacteur (MFA) ajoute une couche supplémentaire de protection en plus d’un nom d’utilisateur et d’un mot de passe. Une fois l’authentification multifacteur activée, lorsqu’un utilisateur se connecte à un site web AWS, il est invité à entrer son nom d’utilisateur et son mot de passe, ainsi qu’un code d’authentification à partir de son appareil AWS MFA. Il est recommandé d’activer l’authentification multifacteur pour tous les comptes qui ont un mot de passe de console. L’activation de l’authentification multifacteur offre une sécurité accrue pour l’accès à la console, car elle nécessite que le principal d’authentification possède un appareil qui émet une clé temporaire et ait connaissance des informations d’identification.

Gravité : moyenne

GuardDuty doit être activé

Description : Pour fournir une protection supplémentaire contre les intrusions, GuardDuty doit être activé sur votre compte et région AWS.

GuardDuty peut ne pas être une solution complète pour chaque environnement.

Gravité : moyenne

L’authentification multifacteur matérielle doit être activée pour le compte « racine »

Description : le compte racine est l’utilisateur le plus privilégié d’un compte. L’authentification multifacteur ajoute une couche supplémentaire de protection en plus du nom d’utilisateur et du mot de passe. Quand l’authentification multifacteur est activée, lorsqu’un utilisateur se connecte à un site web AWS, il est invité à entrer son nom d’utilisateur et son mot de passe, ainsi qu’un code d’authentification provenant de son appareil d’authentification multifacteur AWS. Pour le niveau 2, il est recommandé de protéger le compte racine avec une authentification multifacteur matérielle. Une authentification multifacteur matérielle a une surface d’attaque plus petite qu’une authentification multifacteur virtuelle. Par exemple, une authentification multifacteur matérielle ne souffre pas de la surface d’attaque introduite par le smartphone sur lequel réside une authentification multifacteur virtuelle. Lorsque vous utilisez du matériel pour l’authentification multifacteur pour de nombreux comptes, il peut créer un problème de gestion des appareils logistique. Si tel est le cas, envisagez d’implémenter cette recommandation de niveau 2 de manière sélective pour les comptes les plus sécurisés. Vous pouvez ensuite appliquer la recommandation de niveau 1 aux autres comptes.

Gravité : faible

L’authentification IAM doit être configurée pour les clusters RDS

Description : ce contrôle vérifie si un cluster de base de données RDS a activé l’authentification de base de données IAM. L’authentification de base de données IAM permet d’authentifier les instances de base de données sans mot de passe. L’authentification utilise un jeton d’authentification. Le trafic vers et depuis la base de données est chiffré à l’aide du protocole SSL. Pour plus d’informations, consultez Authentification de base de données IAM dans le guide de l’utilisateur d’Amazon Aurora.

Gravité : moyenne

L’authentification IAM doit être configurée pour les instances RDS

Description : ce contrôle vérifie si une instance de base de données RDS a activé l’authentification de base de données IAM. L’authentification de base de données IAM permet d’authentifier les instances de base de données avec un jeton d’authentification au lieu d’un mot de passe. Le trafic vers et depuis la base de données est chiffré à l’aide du protocole SSL. Pour plus d’informations, consultez Authentification de base de données IAM dans le guide de l’utilisateur d’Amazon Aurora.

Gravité : moyenne

Les stratégies gérées par le client IAM ne doivent pas autoriser les actions de déchiffrement sur toutes les clés KMS

Description : vérifie si la version par défaut des stratégies gérées par le client IAM autorise les principaux à utiliser les actions de déchiffrement AWS KMS sur toutes les ressources. Ce contrôle utilise Zelkova, un moteur de raisonnement automatisé, pour valider et vous avertir des stratégies susceptibles d’accorder un accès étendu à vos secrets dans les comptes AWS. Ce contrôle échoue si les actions « kms : Déchiffrer » ou « kms : ReEncryptFrom » sont autorisées sur toutes les clés KMS. Le contrôle évalue les stratégies gérées par le client, qu’elles soient attachées ou non. Il ne vérifie pas les stratégies inline ni les stratégies gérées par AWS. Grâce à AWS KMS, vous contrôlez qui peut utiliser vos clés KMS et accéder à vos données chiffrées. Les stratégies IAM définissent les actions qu’une identité (utilisateur, groupe ou rôle) peut effectuer sur les ressources. Conformément aux meilleures pratiques en matière de sécurité, AWS recommande d’accorder le moindre privilège. En d’autres termes, vous devez accorder aux identités uniquement les autorisations « kms:Decrypt » ou « kms:ReEncryptFrom » et uniquement pour les clés nécessaires à l’exécution d’une tâche. Sinon, l’utilisateur peut utiliser des clés qui ne conviennent pas à vos données. Au lieu d’accorder des autorisations pour toutes les clés, déterminez le jeu minimal de clés dont les utilisateurs ont besoin pour accéder aux données chiffrées. Concevez ensuite des stratégies qui permettent aux utilisateurs d’utiliser uniquement ces clés. Par exemple, n’autorisez pas l’autorisation « kms : Déchiffrer » sur toutes les clés KMS. Au lieu de cela, autorisez « kms : Déchiffrer » uniquement sur les clés d’une région particulière pour votre compte. En adoptant le principe du moindre privilège, vous pouvez réduire le risque de divulgation involontaire de vos données.

Gravité : moyenne

Les stratégies gérées par le client IAM que vous créez ne doivent pas autoriser les actions génériques pour les services

Description : ce contrôle vérifie si les stratégies basées sur les identités IAM que vous créez ont des instructions Allow qui utilisent le caractère générique * pour accorder des autorisations pour toutes les actions sur n’importe quel service. Le contrôle échoue si une instruction de stratégie inclut « Effect » : « Allow » avec « Action » : « Service :* ». Par exemple, l’instruction suivante dans une stratégie entraîne un résultat d’échec.

'Statement': [
{
  'Sid': 'EC2-Wildcard',
  'Effect': 'Allow',
  'Action': 'ec2:*',
  'Resource': '*'
}

Le contrôle échoue également si vous utilisez « Effet » : « Autoriser » avec « NotAction » : « service : ». Dans ce cas, l’élément NotAction fournit l’accès à toutes les actions d’un service AWS, à l’exception des actions spécifiées dans NotAction. Ce contrôle s’applique uniquement aux stratégies IAM gérées par le client. Elle ne s’applique pas aux stratégies IAM gérées par AWS. Lorsque vous attribuez des autorisations aux services AWS, il est important d’étendre les actions IAM autorisées dans vos stratégies IAM. Vous devez limiter les actions IAM uniquement aux actions nécessaires. Cela vous aide à provisionner des autorisations de privilège minimum. Les stratégies trop permissives peuvent entraîner une escalade de privilèges si les stratégies sont attachées à un principal IAM qui peut ne pas nécessiter l’autorisation. Dans certains cas, vous pouvez autoriser les actions IAM qui ont un préfixe similaire, tel que DescribeFlowLogs et DescribeAvailabilityZones. Dans ces cas autorisés, vous pouvez ajouter un caractère générique suffixe au préfixe commun. Par exemple, ec2 :Describe.

Ce contrôle réussit si vous utilisez un préfixe d’action IAM avec un caractère générique en suffixe. Par exemple, l’instruction suivante dans une stratégie entraîne un résultat de réussite.

 'Statement': [
{
  'Sid': 'EC2-Wildcard',
  'Effect': 'Allow',
  'Action': 'ec2:Describe*',
  'Resource': '*'
}

Lorsque vous regroupez des actions IAM connexes de cette manière, vous pouvez également éviter de dépasser les limites de taille des stratégies IAM.

Gravité : faible

Les stratégies IAM doivent être attachées uniquement aux groupes ou aux rôles

Description : Par défaut, les utilisateurs, les groupes et les rôles IAM n’ont pas accès aux ressources AWS. Les stratégies IAM sont la méthode par laquelle les privilèges sont accordés aux utilisateurs, aux groupes ou aux rôles. Il est recommandé que les stratégies IAM soient appliquées directement aux groupes et aux rôles, mais pas aux utilisateurs. L’attribution de privilèges au niveau du groupe ou du rôle réduit la complexité de la gestion des accès à mesure que le nombre d’utilisateurs augmente. La réduction de la complexité de la gestion des accès peut également réduire l’opportunité pour un principal de recevoir ou de conserver par inadvertance des privilèges excessifs.

Gravité : faible

Les stratégies IAM qui autorisent des privilèges administratifs complets « : » ne doivent pas être créées

Description : les stratégies IAM sont les moyens par lesquels les privilèges sont accordés aux utilisateurs, groupes ou rôles. Il est recommandé et considéré comme un conseil de sécurité standard pour accorder des privilèges minimum, c’est-à-dire accorder uniquement les autorisations requises pour effectuer une tâche. Déterminez ce que les utilisateurs doivent faire, puis élaborez des stratégies qui leur permettent d’effectuer uniquement ces tâches, au lieu de leur accorder tous les privilèges administratifs. Il est plus sûr de commencer avec un ensemble minimal d’autorisations et d’accorder des autorisations supplémentaires si nécessaire, plutôt que de commencer avec des autorisations trop souples et d’essayer de les renforcer par la suite. Fournir des privilèges administratifs complets au lieu de se limiter à l’ensemble minimal d’autorisations dont l’utilisateur a besoin expose les ressources à des actions potentiellement indésirables. Les stratégies IAM ayant une instruction avec 'Effect': 'Allow' avec 'Action': '' sur 'Resource': '' doivent être supprimées.

Gravité : élevée

Les principaux IAM ne doivent pas avoir de stratégies IAM en ligne qui autorisent les actions de déchiffrement sur toutes les clés KMS

Description : Vérifie si les stratégies incorporées dans vos identités IAM (rôle, utilisateur ou groupe) autorisent les actions de déchiffrement AWS KMS sur toutes les clés KMS. Ce contrôle utilise Zelkova, un moteur de raisonnement automatisé, pour valider et vous avertir des stratégies susceptibles d’accorder un accès étendu à vos secrets dans les comptes AWS. Ce contrôle échoue si kms:Decrypt les kms:ReEncryptFrom actions sont autorisées sur toutes les clés KMS d’une stratégie inline. Grâce à AWS KMS, vous contrôlez qui peut utiliser vos clés KMS et accéder à vos données chiffrées. Les stratégies IAM définissent les actions qu’une identité (utilisateur, groupe ou rôle) peut effectuer sur les ressources. Conformément aux meilleures pratiques en matière de sécurité, AWS recommande d’accorder le moindre privilège. En d’autres termes, vous devez accorder aux identités uniquement les autorisations dont elles ont besoin et uniquement pour les clés nécessaires à l’exécution d’une tâche. Sinon, l’utilisateur peut utiliser des clés qui ne conviennent pas à vos données. Au lieu d’accorder une autorisation pour toutes les clés, déterminez le jeu minimal de clés dont les utilisateurs ont besoin pour accéder aux données chiffrées. Concevez ensuite des stratégies qui permettent aux utilisateurs d’utiliser uniquement ces clés. Par exemple, n’autorisez kms:Decrypt pas l’autorisation sur toutes les clés KMS. Au lieu de cela, ne les autorisez que sur les clés d’une région particulière de votre compte. En adoptant le principe du moindre privilège, vous pouvez réduire le risque de divulgation involontaire de vos données.

Gravité : moyenne

Les fonctions Lambda doivent restreindre l’accès public

Description : La stratégie basée sur les ressources de fonction lambda doit restreindre l’accès public. Cette recommandation ne vérifie pas l’accès par les principaux internes. Assurez-vous que l’accès à la fonction est restreint aux seuls principaux autorisés à l’aide de stratégies basées sur les ressources de moindre privilège.

Gravité : élevée

L’authentification multifacteur doit être activée pour tous les utilisateurs IAM

Description : Tous les utilisateurs IAM doivent avoir activé l’authentification multifacteur (MFA).

Gravité : moyenne

L’authentification multifacteur doit être activée pour le compte « racine »

Description : le compte racine est l’utilisateur le plus privilégié d’un compte. L’authentification multifacteur ajoute une couche supplémentaire de protection en plus du nom d’utilisateur et du mot de passe. Quand l’authentification multifacteur est activée, lorsqu’un utilisateur se connecte à un site web AWS, il est invité à entrer son nom d’utilisateur et son mot de passe, ainsi qu’un code d’authentification provenant de son appareil d’authentification multifacteur AWS. Lorsque vous utilisez l’authentification multifacteur virtuelle pour les comptes racines, il est recommandé que l’appareil utilisé n’est pas un appareil personnel. Utilisez plutôt un appareil mobile dédié (tablette ou téléphone) que vous gardez chargé et sécurisé indépendamment de tout appareil personnel individuel. Cela réduit les risques de perdre l’accès à l’authentification multifacteur en cas de perte ou d’échange de l’appareil ou si la personne possédant l’appareil n’est plus employée par l’entreprise.

Gravité : faible

Les stratégies de mot de passe pour les utilisateurs IAM doivent avoir des configurations fortes

Description : vérifie si la stratégie de mot de passe de compte pour les utilisateurs IAM utilise les configurations minimales suivantes.

• RequireUppercaseCharacters - Exiger au moins un caractère majuscule dans le mot de passe. (Valeur par défaut = true)
• RequireLowercaseCharacters - Exiger au moins un caractère minuscule dans le mot de passe. (Valeur par défaut = true)
• RequireNumbers - Exiger au moins un numéro dans le mot de passe. (Valeur par défaut = true)
• MinimumPasswordLength - Longueur minimale du mot de passe. (Valeur par défaut = 7 ou plus)
• PasswordReusePrevention - Nombre de mots de passe avant d’autoriser la réutilisation. (Valeur par défaut = 4)
• MaxPasswordAge : nombre de jours avant l’expiration du mot de passe. (Valeur par défaut = 90)

Gravité : moyenne

Les autorisations des identités inactives dans votre compte AWS doivent être révoquées

Description : Microsoft Defender pour le cloud découvert une identité qui n’a effectué aucune action sur une ressource au sein de votre compte AWS au cours des 45 derniers jours. Il est recommandé de révoquer les autorisations des identités inactives afin de réduire la surface d’attaque de votre environnement cloud.

Gravité : moyenne

La clé d’accès du compte racine ne doit pas exister

Description : Le compte racine est l’utilisateur le plus privilégié d’un compte AWS. Les clés d’accès AWS fournissent un accès programmatique à un compte AWS donné. Il est recommandé de supprimer toutes les clés d’accès associées au compte racine. La suppression des clés d’accès associées au compte racine limite les vecteurs par lesquels le compte peut être compromis. En outre, la suppression des clés d’accès racine encourage la création et l’utilisation de comptes basés sur des rôles qui ont moins de privilèges.

Gravité : élevée

Le paramètre Bloquer l’accès public S3 doit être activé

Description : L’activation du paramètre Bloquer l’accès public pour votre compartiment S3 peut aider à empêcher les fuites de données sensibles et à protéger votre compartiment contre les actions malveillantes.

Gravité : moyenne

Le paramètre Bloquer l’accès public S3 doit être activé au niveau du compartiment

Description : ce contrôle vérifie si les compartiments S3 ont des blocs d’accès public au niveau du compartiment appliqués. Ce contrôle échoue si l’un des paramètres suivants a la valeur false :

• ignorePublicAcls
• blockPublicPolicy
• blockPublicAcls
• restrictPublicBuckets Bloquer l’accès public au niveau du compartiment S3 fournit des contrôles pour s’assurer que les objets n’ont jamais accès public. L’accès public est accordé aux compartiments et aux objets via des listes de contrôle d’accès (ACL), des stratégies de compartiments ou les deux. À moins que vous ne souhaitiez que vos compartiments S3 soient accessibles publiquement, vous devez configurer la fonctionnalité Bloquer l’accès public d’Amazon S3 au niveau du compartiment.

Gravité : élevée

L’accès public en lecture des compartiments S3 doit être supprimé

Description : la suppression de l’accès en lecture public à votre compartiment S3 peut aider à protéger vos données et à empêcher une violation des données.

Gravité : élevée

L’accès public en écriture des compartiments S3 doit être supprimé

Description : Autoriser l’accès en écriture publique à votre compartiment S3 peut vous laisser vulnérable à des actions malveillantes telles que le stockage de données à vos frais, le chiffrement de vos fichiers pour rançon ou l’utilisation de votre compartiment pour exploiter des programmes malveillants.

Gravité : élevée

La rotation automatique doit être activée pour les secrets Secrets Manager

Description : ce contrôle vérifie si un secret stocké dans AWS Secrets Manager est configuré avec une rotation automatique. 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. 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 instances EC2 arrêtées doivent être supprimées après un laps de temps spécifique

Description : ce contrôle vérifie si des instances EC2 ont été arrêtées pendant plus que le nombre de jours autorisé. Une instance EC2 échoue à cette vérification si elle est arrêtée pendant plus longtemps que la période maximale autorisée, qui est par défaut de 30 jours. Un résultat d’échec indique qu’une instance EC2 n’a pas été exécutée pendant un laps de temps considérable. Cela crée un risque de sécurité, car l’instance EC2 n’est pas gérée activement (analysée, corrigée, mise à jour). S’il est lancé ultérieurement, l’absence de maintenance appropriée peut entraîner des problèmes inattendus dans votre environnement AWS. Pour maintenir en toute sécurité une instance EC2 dans un état de non-fonctionnement au fil du temps, démarrez-la périodiquement pour la maintenance, puis arrêtez-la après la maintenance. Dans l’idéal, il s’agit d’un processus automatisé.

Gravité : moyenne

Les identités inutilisées dans votre environnement AWS doivent être supprimées (préversion)

Description : les identités inactives sont des entités humaines et non humaines qui n’ont effectué aucune action sur une ressource au cours des 90 derniers jours. Les identités IAM inactives disposant d’autorisations à haut risque dans votre compte AWS peuvent être sujettes à une attaque si elles sont laissées comme c’est le cas et laisser les organisations ouvertes aux informations d’identification malveillantes ou à l’exploitation. La détection et la réponse proactives aux identités inutilisées vous aident à empêcher les entités non autorisées d’accéder à vos ressources AWS.

Gravité : moyenne

Recommandations d’identité et d’accès GCP

Les clés de chiffrement ne doivent pas avoir plus de trois utilisateurs

Description : cette recommandation évalue les stratégies IAM pour les anneaux de clés, les projets et les organisations, et récupère les principaux avec des rôles qui leur permettent de chiffrer, déchiffrer ou signer des données à l’aide de clés KMS cloud : rôles/propriétaires, rôles/cloudkms.cryptoKeyEncrypterDecrypter, rôles/cloudkms.signerVerifier.

Gravité : moyenne

Vérifier que les clés d’API ne sont pas créées pour un projet

Description : les clés sont non sécurisées, car elles peuvent être consultées publiquement, comme à partir d’un navigateur, ou elles sont accessibles sur un appareil où réside la clé. Il est recommandé d’utiliser plutôt le flux d’authentification standard.

Les risques de sécurité impliqués dans l’utilisation de clés API apparaissent ci-dessous :

• Les clés API sont des chaînes chiffrées simples
• Les clés API n’identifient pas l’utilisateur ou l’application qui effectue la demande d’API
• Les clés API sont généralement accessibles aux clients, ce qui facilite la découverte et le vol d’une clé API

Pour éviter les risques de sécurité liés à l’utilisation de clés API, il est recommandé d’utiliser plutôt le flux d’authentification standard.

Gravité : élevée

Vérifiez que les clés API sont limitées aux API auxquelles l’application a besoin d’accéder

Description : les clés API ne sont pas sécurisées, car elles peuvent être consultées publiquement, comme à partir d’un navigateur, ou sont accessibles sur un appareil où réside la clé. Il est recommandé de restreindre les clés API à utiliser (appeler) uniquement les API requises par une application.

Les risques de sécurité impliqués dans l’utilisation de clés API sont les suivants :

• Les clés API sont des chaînes chiffrées simples
• Les clés API n’identifient pas l’utilisateur ou l’application qui effectue la demande d’API
• Les clés API sont généralement accessibles aux clients, ce qui facilite la découverte et le vol d’une clé API

Compte tenu de ces risques potentiels, Google recommande d’utiliser le flux d’authentification standard au lieu des clés API. Toutefois, il existe des cas limités où les clés API sont plus appropriées. Par exemple, s’il existe une application mobile qui doit utiliser l’API Google Cloud Translation, mais n’a pas besoin d’un serveur principal, les clés API sont la façon la plus simple de s’authentifier auprès de cette API.

Afin de réduire les surfaces d’attaque en fournissant des privilèges minimaux, les clés API peuvent être limitées à utiliser (appeler) uniquement les API requises par une application.

Gravité : élevée

Vérifier que l’utilisation des clés d’API est limitée uniquement aux hôtes et applications spécifiés

Description : Les clés illimitées sont non sécurisées, car elles peuvent être consultées publiquement, comme à partir d’un navigateur, ou elles sont accessibles sur un appareil où réside la clé. Il est recommandé de limiter l’utilisation des clés API aux hôtes approuvés, aux références HTTP et aux applications.

Les risques de sécurité impliqués dans l’utilisation de clés API apparaissent ci-dessous :

• Les clés API sont des chaînes chiffrées simples
• Les clés API n’identifient pas l’utilisateur ou l’application qui effectue la demande d’API
• Les clés API sont généralement accessibles aux clients, ce qui facilite la découverte et le vol d’une clé API

Compte tenu de ces risques potentiels, Google recommande d’utiliser le flux d’authentification standard au lieu de clés API. Toutefois, il existe des cas limités où les clés API sont plus appropriées. Par exemple, s’il existe une application mobile qui doit utiliser l’API Google Cloud Translation, mais n’a pas besoin d’un serveur principal, les clés API sont la façon la plus simple de s’authentifier auprès de cette API.

Pour réduire les vecteurs d’attaque, les clés API peuvent être limitées uniquement aux hôtes approuvés, aux référents HTTP et aux applications.

Gravité : élevée

Vérifier que les clés d’API font l’objet d’une rotation tous les 90 jours

Description : il est recommandé de faire pivoter les clés API toutes les 90 jours.

Les risques de sécurité impliqués dans l’utilisation de clés API sont répertoriés ci-dessous :

• Les clés API sont des chaînes chiffrées simples
• Les clés API n’identifient pas l’utilisateur ou l’application qui effectue la demande d’API
• Les clés API sont généralement accessibles aux clients, ce qui facilite la découverte et le vol d’une clé API

En raison de ces risques potentiels, Google recommande d’utiliser le flux d’authentification standard au lieu de clés API. Toutefois, il existe des cas limités où les clés API sont plus appropriées. Par exemple, s’il existe une application mobile qui doit utiliser l’API Google Cloud Translation, mais n’a pas besoin d’un serveur principal, les clés API sont la façon la plus simple de s’authentifier auprès de cette API.

Une fois qu’une clé est volée, elle n’a pas d’expiration, ce qui signifie qu’elle peut être utilisée indéfiniment, sauf si le propriétaire du projet révoque ou régénère la clé. La rotation des clés d’API réduira la fenêtre de possibilité d’utilisation d’une clé d’accès associée à un compte compromis ou résilié.

Les clés API doivent être pivotées pour s’assurer que les données ne sont pas accessibles avec une ancienne clé susceptible d’avoir été perdue, craquelée ou volée.

Gravité : élevée

Vérifier que les clés de chiffrement KMS font l’objet d’une rotation dans une période de 90 jours

Description : Google Cloud Service de gestion de clés stocke les clés de chiffrement dans une structure hiérarchique conçue pour une gestion utile et élégante du contrôle d’accès. Le format de la planification de rotation dépend de la bibliothèque cliente utilisée. Pour l’outil en ligne de commande gcloud, l’heure de rotation suivante doit être au format « ISO » ou « RFC3339 », et la période de rotation doit être au format « INTEGER[UNIT], où les unités peuvent être une des secondes (s), minutes (m), heures (h) ou jours (d). Définissez une période de rotation des clés et une heure de début. Une clé peut être créée avec une « période de rotation » spécifiée, c’est-à-dire le moment entre lequel les nouvelles versions de clé sont générées automatiquement. Une clé peut également être créée avec une heure de rotation suivante spécifiée. Une clé est un objet nommé représentant une « clé de chiffrement » utilisée dans un but spécifique. Le matériau de clé, les bits réels utilisés pour le « chiffrement », peuvent changer au fil du temps à mesure que de nouvelles versions de clé sont créées. Une clé est utilisée pour protéger certains « corpus de données ». Une collection de fichiers peut être chiffrée avec la même clé et les personnes disposant d’autorisations « déchiffrer » sur cette clé peuvent déchiffrer ces fichiers. Par conséquent, il est nécessaire de s’assurer que la « période de rotation » est définie sur un temps spécifique.

Gravité : moyenne

Vérifier que des alertes et un filtre de métrique de journal existent pour les changements d’attributions de propriété du projet

Description : afin d’empêcher les affectations inutiles de propriété de projet aux utilisateurs/comptes de service et autres mauvaises utilisations des projets et des ressources, toutes les affectations de « rôles/propriétaire » doivent être surveillées. Les membres (utilisateurs/comptes de service) disposant d’une attribution de rôle à un rôle primitif « rôles/propriétaire » sont des propriétaires de projet. Le propriétaire du projet dispose de tous les privilèges sur le projet auquel appartient le rôle. Ils sont résumés ci-dessous :

• Toutes les autorisations de visionneuse sur tous les services GCP au sein du projet
• Autorisations pour les actions qui modifient l’état de tous les services GCP dans le projet
• Gérer les rôles et autorisations d’un projet et de toutes les ressources du projet
• Configurer la facturation d’un projet Accordant le rôle propriétaire à un membre (utilisateur/compte de service) permet à ce membre de modifier la stratégie Gestion des identités et des accès (IAM). Par conséquent, accordez le rôle propriétaire uniquement si le membre a un objectif légitime pour gérer la stratégie IAM. En effet, la stratégie IAM du projet contient des données de contrôle d’accès sensibles. Le fait d’avoir un ensemble minimal d’utilisateurs autorisés à gérer la stratégie IAM simplifie tous les audits qui peuvent être nécessaires. La propriété du projet a le niveau de privilèges le plus élevé sur un projet. Pour éviter toute utilisation incorrecte des ressources du projet, les actions d’affectation/modification de propriété du projet mentionnées ci-dessus doivent être surveillées et faire l’objet d’alertes pour les destinataires concernés.
• Envoi d’invitations à la propriété du projet
• Acceptation/Rejet de la propriété du projet invité par l’utilisateur
• Ajout role\Owner à un compte d’utilisateur/de service
• Suppression d’un compte d’utilisateur/de service role\Owner

Gravité : faible

Vérifier qu’oslogin est activé pour un projet

Description : L’activation de la connexion du système d’exploitation lie des certificats SSH aux utilisateurs IAM et facilite la gestion efficace des certificats SSH. L’activation d’osLogin garantit que les clés SSH utilisées pour se connecter aux instances sont mappées aux utilisateurs IAM. La révocation de l’accès à l’utilisateur IAM révoque toutes les clés SSH associées à cet utilisateur particulier. Il facilite la gestion centralisée et automatisée des paires de clés SSH, ce qui est utile dans les cas de gestion tels que la réponse aux paires de clés SSH compromises et/ou la révocation d’utilisateurs externes/tiers/fournisseurs. Pour savoir quelle instance entraîne l’indisponibilité du projet, consultez la recommandation « Vérifier que oslogin est activé pour toutes les instances ».

Gravité : moyenne

Vérifier que la connexion du système d’exploitation est activée pour toutes les instances

Description : L’activation de la connexion du système d’exploitation lie des certificats SSH aux utilisateurs IAM et facilite la gestion efficace des certificats SSH. L’activation d’osLogin garantit que les clés SSH utilisées pour se connecter aux instances sont mappées aux utilisateurs IAM. La révocation de l’accès à l’utilisateur IAM révoque toutes les clés SSH associées à cet utilisateur particulier. Il facilite la gestion centralisée et automatisée des paires de clés SSH, ce qui est utile dans les cas de gestion tels que la réponse aux paires de clés SSH compromises et/ou la révocation d’utilisateurs externes/tiers/fournisseurs.

Gravité : moyenne

Vérifier que la journalisation de l’audit cloud est correctement configurée pour tous les services et tous les utilisateurs d’un projet

Description : il est recommandé de configurer la journalisation d’audit cloud pour suivre toutes les activités d’administration et lire, écrire l’accès aux données utilisateur.

La journalisation d’audit cloud gère deux journaux d’audit pour chaque projet, dossier et organisation : Activités d’administration et Accès aux données.

• Les journaux d’activités d’administration contiennent des entrées de journal pour les appels d’API ou d’autres actions administratives qui modifient la configuration ou les métadonnées des ressources.
• Les journaux d’audit de l’activité d’administration sont activés pour tous les services et ne peuvent pas être configurés.
• Les journaux d’audit d’accès aux données enregistrent les appels d’API qui créent, modifient ou lisent des données fournies par l’utilisateur. Ils sont désactivés par défaut et doivent être activés.

Il existe trois types d’informations de journal d’audit d’accès aux données :

• Lecture administrative : enregistre les opérations qui lisent des métadonnées ou des informations de configuration. Les journaux d’audit de l’activité d’administration enregistrent les écritures de métadonnées et d’informations de configuration qui ne peuvent pas être désactivées.
• Lecture de données : enregistre les opérations qui lisent des données fournies par l’utilisateur.
• Écriture de données : enregistre les opérations qui écrivent des données fournies par l’utilisateur.

Il est recommandé d’avoir une configuration d’audit par défaut efficace configurée de telle sorte que :

• Le type de journal est défini sur DATA_READ (pour journaliser le suivi des activités utilisateur) et DATA_WRITES (pour enregistrer les modifications/falsifications des données utilisateur).
• La configuration d’audit est activée pour tous les services pris en charge par la fonctionnalité des journaux d’audit d’accès aux données.
• Les journaux doivent être capturés pour tous les utilisateurs, c’est-à-dire qu’il n’existe aucun utilisateur exempté dans les sections de configuration d’audit. Cela garantit que le remplacement de la configuration d’audit ne contredit pas l’exigence.

Gravité : moyenne

Vérifiez que les clés de chiffrement KMS cloud ne sont pas accessibles anonymement ou publiquement

Description : il est recommandé que la stratégie IAM sur les clés de chiffrement KMS cloud limite l’accès anonyme et/ou public. L’octroi d’autorisations à « allUsers » ou « allAuthenticatedUsers » permet à quiconque d’accéder au jeu de données. Un tel accès peut ne pas être souhaitable si des données sensibles sont stockées à l’emplacement. Dans ce cas, assurez-vous que l’accès anonyme et/ou public à une clé de chiffrement KMS cloud n’est pas autorisé.

Gravité : élevée

Vérifier que les informations d’identification de connexion d’entreprise sont utilisées

Description : Utilisez les informations d’identification de connexion d’entreprise au lieu de compte personnel, telles que les comptes Gmail. Il est recommandé d’utiliser des comptes Google d’entreprise complètement gérés pour améliorer la visibilité, l’audit et le contrôle de l’accès aux ressources cloud Platform. Les comptes Gmail basés en dehors de l’organisation de l’utilisateur, tels que les compte personnel, ne doivent pas être utilisés à des fins professionnelles.

Gravité : élevée

Vérifier que les rôles Utilisateur du compte de service ou Créateur du jeton du compte de service ne sont pas attribués aux utilisateurs IAM au niveau du projet

Description : il est recommandé d’affecter les rôles « Utilisateur de compte de service (iam.serviceAccountUser) » et « Créateur de jeton de compte de service (iam.serviceAccountTokenCreator) » à un utilisateur pour un compte de service spécifique plutôt que d’attribuer le rôle à un utilisateur au niveau du projet. Un compte de service est un compte Google spécial qui appartient à une application ou à une machine virtuelle, au lieu d’un utilisateur final individuel. Application/instance de machine virtuelle utilise le compte de service pour appeler l’API Google du service afin que les utilisateurs ne soient pas directement impliqués. En plus d’être une identité, un compte de service est une ressource à laquelle des stratégies IAM sont attachées. Ces stratégies déterminent qui peut utiliser le compte de service. Les utilisateurs disposant de rôles IAM pour mettre à jour les instances App Engine et Compute Engine (par exemple, App Engine Deployer ou Compute Instance Administration) peuvent exécuter du code en tant que comptes de service utilisés pour exécuter ces instances et accéder indirectement à toutes les ressources auxquelles les comptes de service ont accès. De même, l’accès SSH à une instance du moteur de calcul peut également fournir la possibilité d’exécuter du code en tant qu’instance/compte de service. En fonction des besoins de l’entreprise, plusieurs comptes de service gérés par l’utilisateur peuvent être configurés pour un projet. L’octroi des rôles « iam.serviceAccountUser » ou « iam.serviceAserviceAccountTokenCreatorccountUser » à un utilisateur pour un projet permet à l’utilisateur d’accéder à tous les comptes de service du projet, y compris les comptes de service qui peuvent être créés ultérieurement. Cela peut entraîner une élévation de privilèges à l’aide de comptes de service et d’instances de moteur de calcul correspondantes. Pour implémenter les meilleures pratiques de « privilèges minimum », les utilisateurs IAM ne doivent pas être affectés aux rôles « Utilisateur du compte de service » ou « Créateur de jeton de compte de service » au niveau du projet. Au lieu de cela, ces rôles doivent être attribués à un utilisateur pour un compte de service spécifique, ce qui lui donne accès au compte de service. Le rôle « Utilisateur du compte de service » permet à un utilisateur de lier un compte de service à un service de travail de longue durée, tandis que le rôle « Créateur de jeton de compte de service » permet à un utilisateur d’emprunter directement l’identité d’un compte de service (ou d’affirmer) l’identité d’un compte de service.

Gravité : moyenne

Vérifier que la séparation des tâches est appliquée lors de l’affectation des rôles KMS aux utilisateurs

Description : il est recommandé d’appliquer le principe de « séparation des tâches » lors de l’attribution de rôles liés à KMS aux utilisateurs. Le rôle IAM intégré/prédéfini « Administration de KMS cloud » permet à l’utilisateur/l’identité de créer, supprimer et gérer des comptes de service. Le rôle Cloud KMS CryptoKey Encrypter/Decrypter IAM intégré/prédéfini permet à l’utilisateur/identité (avec des privilèges adéquats sur les ressources concernées) de chiffrer et de déchiffrer des données au repos à l’aide d’une ou plusieurs clés de chiffrement. Le rôle Cloud KMS CryptoKey Encrypter IAM intégré/prédéfini permet à l’utilisateur/identité (avec des privilèges adéquats sur les ressources concernées) de chiffrer les données au repos à l’aide d’une ou plusieurs clés de chiffrement. Le rôle Cloud KMS Crypto Key Decrypter IAM intégré/prédéfini permet à l’utilisateur/identité (avec des privilèges adéquats sur les ressources concernées) de déchiffrer les données au repos à l’aide d’une ou plusieurs clés de chiffrement. La séparation des tâches est le concept de s’assurer qu’un individu n’a pas toutes les autorisations nécessaires pour pouvoir effectuer une action malveillante. Dans le service KMS cloud, il peut s’agir d’une action telle que l’utilisation d’une clé pour accéder aux données et les déchiffrer qu’un utilisateur ne doit normalement pas avoir accès. La séparation des tâches est un contrôle métier généralement utilisé dans les grandes organisations, destiné à éviter les incidents et les erreurs de sécurité ou de confidentialité. Il est considéré comme une bonne pratique. Aucun utilisateur ne doit disposer de l’administrateur KMS cloud et de l’un Cloud KMS CryptoKey Encrypter/Decrypterdes rôles affectés Cloud KMS CryptoKey EncrypterCloud KMS CryptoKey Decrypter en même temps.

Gravité : élevée

Vérifier que la séparation des tâches est appliquée lors de l’attribution des rôles associés au compte de service aux utilisateurs

Description : il est recommandé d’appliquer le principe « Séparation des tâches » lors de l’attribution de rôles liés au compte de service aux utilisateurs. Le rôle IAM intégré/prédéfini « Administration de compte de service » permet à l’utilisateur/l’identité de créer, supprimer et gérer des comptes de service. Le rôle IAM intégré/prédéfini « Utilisateur du compte de service » permet à l’utilisateur/à l’identité (avec des privilèges adéquats sur le moteur de calcul et d’application) d’attribuer des comptes de service aux applications/instances de calcul. La séparation des tâches est le concept de s’assurer qu’un individu n’a pas toutes les autorisations nécessaires pour pouvoir effectuer une action malveillante. Dans Cloud IAM - Comptes de service, il peut s’agir d’une action telle que l’utilisation d’un compte de service pour accéder aux ressources auxquelles l’utilisateur ne doit normalement pas avoir accès. La séparation des tâches est un contrôle métier généralement utilisé dans les grandes organisations, destiné à éviter les incidents et les erreurs de sécurité ou de confidentialité. Il est considéré comme une bonne pratique. Aucun utilisateur ne doit avoir de rôles « Administrateur de comptes de service » et « Utilisateur de compte de service » attribués en même temps.

Gravité : moyenne

Vérifier que le compte de service n’a pas de privilèges d’administrateur

Description : un compte de service est un compte Google spécial qui appartient à une application ou à une machine virtuelle, au lieu d’un utilisateur final individuel. L’application utilise le compte de service pour appeler l’API Google du service afin que les utilisateurs ne soient pas directement impliqués. Il est recommandé de ne pas utiliser l’accès administrateur pour le compte de service. Les comptes de service représentent la sécurité au niveau du service des ressources (application ou machine virtuelle), qui peut être déterminée par les rôles attribués. L’inscription de ServiceAccount avec des droits Administration donne un accès complet à une application ou à une machine virtuelle affectée. Un détenteur d’accès ServiceAccount peut effectuer des actions critiques, comme la suppression, la mise à jour des paramètres modifiés, etc. sans l’intervention de l’utilisateur. Pour cette raison, il est recommandé que les comptes de service ne disposent pas de droits d’administration.

Gravité : moyenne

Vérifier que les récepteurs sont configurés pour toutes les entrées de journal

Description : il est recommandé de créer un récepteur qui exportera les copies de toutes les entrées du journal. Cela peut aider à agréger les journaux de plusieurs projets et à les exporter vers une solution SIEM (gestion des informations et des événements de sécurité). Les entrées de journal sont conservées dans la journalisation Stackdriver. Pour agréger les journaux, exportez-les vers un SIEM. Pour les conserver plus longtemps, il est recommandé de configurer un récepteur de journaux. L’exportation implique l’écriture d’un filtre qui sélectionne les entrées de journal à exporter et le choix d’une destination dans Cloud Storage, BigQuery ou Cloud Pub/Sub. Le filtre et la destination sont conservés dans un objet appelé récepteur. Pour vous assurer que toutes les entrées de journal sont exportées vers des récepteurs, assurez-vous qu’aucun filtre n’est configuré pour un récepteur. Les récepteurs peuvent être créés dans des projets, des organisations, des dossiers et des comptes de facturation.

Gravité : faible

Vérifier que les alertes et le filtre de métrique du journal existent pour les changements de configuration de l’audit

Description : les services Google Cloud Platform (GCP) écrivent des entrées de journal d’audit dans les journaux d’activité administrateur et d’accès aux données. Les entrées permettent de répondre aux questions de « qui a fait quoi, où et quand ? » dans les projets GCP. Les informations enregistrées par le journal d’audit cloud incluent l’identité de l’appelant de l’API, l’heure de l’appel d’API, l’adresse IP source de l’appelant de l’API, les paramètres de la requête et les éléments de réponse renvoyés par les services GCP. La journalisation d’audit cloud fournit un historique des appels d’API GCP pour un compte, y compris les appels d’API effectués via la console, les kits SDK, les outils en ligne de commande et d’autres services GCP. Les journaux d’activité d’administrateur et d’accès aux données générés par la journalisation d’audit cloud permettent l’analyse de la sécurité, le suivi des modifications des ressources et l’audit de conformité. La configuration du filtre de métriques et des alertes pour les modifications de configuration d’audit garantit que l’état recommandé de la configuration d’audit est conservé afin que toutes les activités du projet puissent être auditées à tout moment.

Gravité : faible

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

Description : il est recommandé d’établir un filtre de métrique et une alarme pour les modifications apportées à la création, à la suppression et à la mise à jour des activités de rôle Identity and Access Management (IAM). Google Cloud IAM fournit des rôles prédéfinis qui donnent un accès granulaire à des ressources Google Cloud Platform spécifiques et empêchent les accès indésirables à d’autres ressources. Toutefois, pour répondre aux besoins spécifiques de l’organisation, Cloud IAM offre également la possibilité de créer des rôles personnalisés. Les propriétaires et administrateurs de projets avec le rôle Administrateur de rôles d’organisation ou Administrateur de rôles IAM peuvent créer des rôles personnalisés. La surveillance des activités de création, de suppression et de mise à jour des rôles permet d’identifier les rôles à privilèges excessifs dès les premiers stades.

Gravité : faible

Vérifier la rotation des clés externes/gérées par l’utilisateur pour les comptes de service tous les 90 jours ou moins

Description : Les clés de compte de service se composent d’un ID de clé (Private_key_Id) et d’une clé privée, qui sont utilisées pour signer les demandes programmatiques que les utilisateurs effectuent aux services cloud Google accessibles à ce compte de service particulier. Il est recommandé que toutes les clés de compte de service soient régulièrement pivotées. La rotation des clés de compte de service réduira la fenêtre de possibilité d’utilisation d’une clé d’accès associée à un compte compromis ou résilié. Les clés de compte de service doivent être pivotées pour s’assurer que les données ne sont pas accessibles avec une ancienne clé qui a peut-être été perdue, craquelée ou volée. Chaque compte de service est associé à une paire de clés gérée par Google Cloud Platform (GCP). Il est utilisé pour l’authentification de service à service dans GCP. Google fait pivoter les clés quotidiennement. GCP offre la possibilité de créer une ou plusieurs paires de clés gérées par l’utilisateur (également appelées paires de clés externes) à utiliser en dehors de GCP (par exemple, pour une utilisation avec les informations d’identification par défaut de l’application). Lorsqu’une nouvelle paire de clés est créée, l’utilisateur doit télécharger la clé privée (qui n’est pas conservée par Google).

Avec des clés externes, les utilisateurs sont responsables de la sécurisation de la clé privée et d’autres opérations de gestion telles que la rotation des clés. Les clés externes peuvent être gérées par l’API IAM, l’outil en ligne de commande gcloud ou la page Comptes de service dans la console Google Cloud Platform.

GCP facilite jusqu’à 10 clés de compte de service externes par compte de service pour faciliter la rotation des clés.

Gravité : moyenne

Les identités surprovisionnés GCP doivent avoir uniquement les autorisations nécessaires (préversion)

Description : une identité active sur provisionnée est une identité qui a accès aux privilèges qu’ils n’ont pas utilisés. Les identités actives surprovisionnée, en particulier pour les comptes non humains qui ont des actions et responsabilités très définies, peuvent augmenter le rayon d’explosion en cas d’utilisateur, de clé ou de compromission des ressources Le principe des états de privilège minimum qu’une ressource ne doit avoir accès qu’aux ressources exactes dont elle a besoin pour fonctionner. Ce principe a été développé pour résoudre le risque de compromission des identités accordant à un attaquant l’accès à un large éventail de ressources.

Le tableau de bord web GKE doit être désactivé

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

Gravité : élevée

L’autorisation héritée doit être désactivée sur les clusters GKE

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

Gravité : élevée

Les autorisations des identités inactives dans votre projet GCP doivent être révoquées

Description : Microsoft Defender pour le cloud découvert une identité qui n’a effectué aucune action sur une ressource au sein de votre projet GCP au cours des 45 derniers jours. Il est recommandé de révoquer les autorisations des identités inactives afin de réduire la surface d’attaque de votre environnement cloud.

Gravité : moyenne

Le rôle IAM Redis ne doit pas être attribué au niveau de l’organisation ou du dossier

Description : cette recommandation évalue la stratégie d’autorisation IAM dans les métadonnées de ressource pour les principaux affectés aux rôles/redis.admin, rôles/redis.editor, rôles/redis.viewer au niveau de l’organisation ou du dossier.

Gravité : élevée

Les comptes de service doivent avoir un accès restreint au projet dans un cluster

Description : cette recommandation évalue la propriété de configuration d’un pool de nœuds pour vérifier si aucun compte de service n’est spécifié ou si le compte de service par défaut est utilisé.

Gravité : élevée

Les utilisateurs doivent disposer d’un accès au moins privilégié avec des rôles IAM granulaires

Description : cette recommandation évalue la stratégie IAM dans les métadonnées de ressource pour tous les principaux affectés aux rôles/propriétaires, rôles/enregistreur ou rôles/lecteur.

Gravité : élevée

Contenu connexe

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