Partager via

Contrôle de sécurité : Gestion des identités

Identité et accès couvre les contrôles destinés à établir des contrôles d’identité et d’accès à l’aide de systèmes d’administration des identités et accès, y compris l’utilisation de l’authentification unique, des authentifications renforcées, des identités managées (et principaux de service) pour les applications, l’accès conditionnel et le monitoring des anomalies de compte.

IM-1 : Utiliser le système centralisé d’identité et d’authentification

ID des contrôles CIS v8 ID NIST SP 800-53 r4 ID du PCI-DSS v3.2.1
6,7, 12,5 AC-2, AC-3, IA-2, IA-8 7.2, 8.3

Principe de sécurité : utilisez un système centralisé d’identité et d’authentification pour régir les identités et les authentifications de votre organisation pour les ressources cloud et non cloud.

Conseils Azure : Azure Active Directory (Azure AD) est le service de gestion des identités et des authentifications Azure. Vous devez normaliser azure AD pour régir l’identité et l’authentification de votre organisation dans :

  • Ressources cloud Microsoft, telles que stockage Azure, machines virtuelles Azure (Linux et Windows), Azure Key Vault, PaaS et applications SaaS.
  • Les ressources de votre organisation, telles que les applications sur Azure, les applications tierces s’exécutant sur vos ressources réseau d’entreprise et les applications SaaS tierces.
  • Vos identités d’entreprise dans Active Directory en synchronisation avec Azure AD pour garantir une stratégie d’identité managée cohérente et centralisée.

Pour les services Azure qui s’appliquent, évitez d’utiliser des méthodes d’authentification locales et utilisez plutôt Azure Active Directory pour centraliser vos authentifications de service.

Remarque : dès qu’il est techniquement possible, vous devez migrer des applications Active Directory locales vers Azure AD. Il peut s’agir d’une configuration Azure AD Enterprise Directory, Business to Business ou Business to Consumer.

Implémentation Azure et contexte supplémentaire :

Conseils AWS : AWS IAM (Identity and Access Management) est le service de gestion des identités et des authentifications par défaut d’AWS. Utilisez AWS IAM pour régir votre gestion des identités et des accès AWS. Vous pouvez également utiliser Azure AD pour gérer l’identité et le contrôle d’accès d’AWS et d’Azure Single Sign-On (SSO), afin d’éviter de gérer les comptes en double séparément dans deux plateformes cloud.

AWS prend en charge l'Sign-On unique qui vous permet de relier les identités tierces de votre entreprise (telles que Windows Active Directory ou d’autres magasins d’identités) avec les identités AWS pour éviter de créer des comptes en double pour accéder aux ressources AWS.

Implémentation AWS et contexte supplémentaire :

Conseils GCP : le système Gestion des identités et des accès (IAM) de Google Cloud est le service de gestion des identités et des authentifications par défaut de Google Cloud utilisé pour les comptes Google Cloud Identity. Utilisez Google Cloud IAM pour régir votre gestion des identités et des accès GCP. Via Google Cloud Identity et Azure Sigle Sign-On (SSO), vous pouvez également utiliser Azure AD pour gérer l’identité et le contrôle d’accès de GCP, afin d’éviter de gérer les comptes en double séparément dans un environnement multi-cloud.

Google Cloud Identity est le fournisseur d’identité pour tous les services Google. Il prend en charge l'Sign-On unique qui vous permet de ponter les identités tierces de votre entreprise (telles que Windows Active Directory ou d’autres magasins d’identités) avec des identités Google Cloud pour éviter de créer des comptes en double pour accéder aux ressources GCP.

Remarque : Utilisation de Google Cloud Directory Sync. Google fournit un outil de connecteur qui s’intègre à la plupart des systèmes de gestion LDAP d’entreprise et synchronise les identités selon une planification. En configurant un compte d’identité cloud et en chantant Google Cloud Directory Sync, vous pouvez configurer lequel de vos comptes d’utilisateur ( y compris les utilisateurs, les groupes et les profils utilisateur, les alias et bien plus encore) se synchroniseront selon une planification entre votre système de gestion des identités local et votre système GCP.

Implémentation GCP et contexte supplémentaire :

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

Messagerie instantanée 2 : Protéger les systèmes d’identité et d’authentification

ID des contrôles CIS v8 ID NIST SP 800-53 r4 ID du PCI-DSS v3.2.1
5.4, 6.5 AC-2, AC-3, IA-2, IA-8, SI-4 8.2, 8.3

Principe de sécurité : Sécurisez votre système d’identité et d’authentification comme une priorité élevée dans la pratique de sécurité cloud de votre organisation. Les contrôles de sécurité courants sont les suivants :

  • Restreindre les rôles et comptes privilégiés
  • Exiger une authentification forte pour tous les accès privilégiés
  • Surveiller et auditer les activités à haut risque

Conseils Azure : Utilisez la base de référence de sécurité Azure AD et le score de sécurité d’identité Azure AD pour évaluer votre posture de sécurité des identités Azure AD et corriger les lacunes de sécurité et de configuration. Azure AD Identity Secure Score évalue Azure AD pour les configurations suivantes :

  • Utiliser des rôles d’administration limités
  • Activer la stratégie de risque utilisateur
  • Désigner plusieurs administrateurs généraux
  • Activer la stratégie pour bloquer l’authentification héritée
  • Vérifier que tous les utilisateurs peuvent effectuer l’authentification multifacteur pour un accès sécurisé
  • Exiger l’authentification multifacteur pour les rôles d’administration
  • Activer la réinitialisation du mot de passe en libre-service
  • N’expirez pas les mots de passe
  • Activer la stratégie de risque de connexion
  • Ne pas autoriser les utilisateurs à accorder le consentement aux applications non managées

Utilisez Azure AD Identity Protection pour détecter, examiner et corriger les risques basés sur l’identité. Pour protéger de la même façon votre domaine Active Directory local, utilisez Defender pour Identity.

Remarque : Suivez les meilleures pratiques publiées pour tous les autres composants d’identité, y compris vos fonctionnalités Active Directory locales et toutes les fonctionnalités tierces, ainsi que les infrastructures (telles que les systèmes d’exploitation, les réseaux, les bases de données) qui les hébergent.

Implémentation Azure et contexte supplémentaire :

Conseils AWS : Utilisez les meilleures pratiques de sécurité suivantes pour sécuriser votre aws IAM :

  • Configurer les clés d’accès utilisateur racine du compte AWS pour l’accès d’urgence, comme décrit dans PA-5 (Configurer l’accès d’urgence)
  • Suivez les principes de moindre privilège concernant les attributions d’accès
  • Tirez parti des groupes IAM pour appliquer des stratégies plutôt que des utilisateurs individuels.
  • Suivez les instructions d’authentification forte dans IM-6 (Utiliser des contrôles d’authentification forts) pour tous les utilisateurs
  • Utiliser LE SCP (Stratégie de contrôle de service) et les limites d’autorisation d’AWS Organizations
  • Utiliser IAM Access Advisor pour auditer l’accès au service
  • Utiliser le rapport d’informations d’identification IAM pour suivre les comptes d’utilisateur et l’état des informations d’identification

Remarque : Suivez les meilleures pratiques publiées si vous avez d’autres systèmes d’identité et d’authentification, par exemple, suivez la base de référence de sécurité Azure AD si vous utilisez Azure AD pour gérer l’identité et l’accès AWS.

Implémentation AWS et contexte supplémentaire :

Conseils GCP : Utilisez les meilleures pratiques de sécurité suivantes pour sécuriser vos services Google Cloud IAM et Cloud Identity pour vos organisations :

  • Configurez un compte super administrateur pour l’accès d’urgence en suivant les recommandations de pa-5 (« Configurer l’accès d’urgence »).
  • Créez une adresse e-mail de super administrateur (en tant que compte Google Workspace ou Cloud Identity super administrateur) et ce compte ne doit pas être spécifique à un utilisateur particulier en cas de récupération d’urgence.
  • Suivez les principes de privilège minimum et de séparation des tâches
  • Éviter d’utiliser un compte super administrateur pour les activités quotidiennes
  • Tirez parti des groupes Google Cloud Identity pour appliquer des stratégies au lieu d’appliquer des stratégies à des utilisateurs individuels.
  • Suivez les instructions d’authentification forte, comme décrit dans IM-6 (« Utiliser des contrôles d’authentification forte ») pour tous les utilisateurs disposant de privilèges élevés.
  • Utiliser des stratégies IAM pour restreindre l’accès aux ressources
  • Utiliser le service de stratégie d’organisation pour contrôler et configurer des contraintes sur les ressources
  • Utiliser la journalisation d’audit IAM dans les journaux d’audit cloud pour passer en revue les activités privilégiées

Remarque : Suivez les meilleures pratiques publiées si vous avez d’autres systèmes d’identité et d’authentification, par exemple, suivez la base de référence de sécurité Azure AD si vous utilisez Azure AD pour gérer l’identité et l’accès GCP.

Implémentation GCP et contexte supplémentaire :

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

IM-3 : gérer les identités d’application de façon sécurisée et automatique

ID des contrôles CIS v8 ID NIST SP 800-53 r4 ID du PCI-DSS v3.2.1
N/A AC-2, AC-3, IA-4, IA-5, IA-9 N/A

Principe de sécurité : utilisez des identités d’application managée au lieu de créer des comptes humains pour que les applications accèdent aux ressources et exécutent du code. Les identités d’application managées offrent des avantages tels que la réduction de l’exposition des informations d’identification. Automatisez la rotation des informations d’identification pour garantir la sécurité des identités.

Conseils Azure : Utilisez des identités managées Azure, qui peuvent s’authentifier auprès des services et ressources Azure qui prennent en charge l’authentification Azure AD. Les identifiants d’identité gérés sont entièrement gérés, rotés et protégés par la plateforme, ce qui évite les identifiants codés en dur dans le code source ou les fichiers de configuration.

Pour les services qui ne prennent pas en charge les identités managées, utilisez Azure AD pour créer un principal de service avec des autorisations restreintes au niveau de la ressource. Il est recommandé de configurer des principaux de service avec des informations d’identification de certificat et de revenir aux secrets client pour l’authentification.

Implémentation Azure et contexte supplémentaire :

Conseils AWS : Utilisez des rôles AWS IAM au lieu de créer des comptes d’utilisateur pour les ressources qui prennent en charge cette fonctionnalité. Les rôles IAM sont gérés par la plateforme sur le serveur principal et les informations d’identification sont temporaires et pivotées automatiquement. Cela évite de créer des clés d’accès à long terme ou un nom d’utilisateur/mot de passe pour les applications et les informations d’identification codées en dur dans le code source ou les fichiers de configuration.

Vous pouvez utiliser des rôles liés au service qui sont attachés avec des stratégies d’autorisation prédéfinies pour l’accès entre les services AWS au lieu de personnaliser vos propres autorisations de rôle pour les rôles IAM.

Remarque : Pour les services qui ne prennent pas en charge les rôles IAM, utilisez des clés d’accès, mais suivez les meilleures pratiques de sécurité telles que la messagerie instantanée 8 restreindre l’exposition des informations d’identification et des secrets pour sécuriser vos clés.

Implémentation AWS et contexte supplémentaire :

Conseils GCP : Utilisez des comptes de service gérés par Google au lieu de créer des comptes gérés par l’utilisateur pour les ressources qui prennent en charge cette fonctionnalité. Les comptes de service gérés par Google sont gérés par la plateforme au niveau du back-end et les clés de compte de service sont temporaires et pivotées automatiquement. Cela évite de créer des clés d’accès à long terme ou un nom d’utilisateur/mot de passe pour les applications et les informations d’identification codées en dur dans le code source ou les fichiers de configuration.

Utilisez Policy Intelligence pour comprendre et reconnaître les activités suspectes pour les comptes de service.

Implémentation GCP et contexte supplémentaire :

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

Messagerie instantanée 4 : Authentifier le serveur et les services

ID des contrôles CIS v8 ID NIST SP 800-53 r4 ID du PCI-DSS v3.2.1
N/A IA-9 N/A

Principe de sécurité : authentifiez les serveurs et services distants côté client pour vous assurer que vous vous connectez à des services et serveurs approuvés. Le protocole d’authentification serveur le plus courant est TLS (Transport Layer Security), où le client (souvent un navigateur ou un appareil client) vérifie le serveur en vérifiant que le certificat du serveur a été émis par une autorité de certification approuvée.

Remarque : L’authentification mutuelle peut être utilisée lorsque le serveur et le client s’authentifient les uns les autres.

Conseils Azure : de nombreux services Azure prennent en charge l’authentification TLS par défaut. Pour les services qui ne prennent pas en charge l’authentification TLS par défaut ou prennent en charge la désactivation de TLS, assurez-vous qu’il est toujours activé pour prendre en charge l’authentification du serveur/du client. Votre application cliente doit également être conçue pour vérifier l’identité du serveur/du client (en vérifiant le certificat du serveur émis par une autorité de certification approuvée) à l’étape de négociation.

Remarque : Les services tels que Gestion des API et passerelle API prennent en charge l’authentification mutuelle TLS.

Implémentation Azure et contexte supplémentaire :

Conseils AWS : de nombreux services AWS prennent en charge l’authentification TLS par défaut. Pour les services qui ne prennent pas en charge l’authentification TLS par défaut ou prennent en charge la désactivation de TLS, assurez-vous qu’il est toujours activé pour prendre en charge l’authentification du serveur/du client. Votre application cliente doit également être conçue pour vérifier l’identité du serveur/du client (en vérifiant le certificat du serveur émis par une autorité de certification approuvée) à l’étape de négociation.

Remarque : Les services tels que la passerelle d’API prennent en charge l’authentification mutuelle TLS.

Implémentation AWS et contexte supplémentaire :

Conseils GCP : de nombreux services GCP prennent en charge l’authentification TLS par défaut. Pour les services qui ne prennent pas en charge cela par défaut ou prennent en charge la désactivation de TLS, assurez-vous qu’il est toujours activé pour prendre en charge l’authentification serveur/client. Votre application cliente doit également être conçue pour vérifier l’identité du serveur/du client (en vérifiant le certificat du serveur émis par une autorité de certification approuvée) à l’étape de négociation.

Remarque : Les services tels que l’équilibrage de charge cloud prennent en charge l’authentification mutuelle TLS.

Implémentation GCP et contexte supplémentaire :

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

MESSAGERIE INSTANTANÉE 5 : Utiliser l’authentification unique (SSO) pour l’accès aux applications

ID des contrôles CIS v8 ID NIST SP 800-53 r4 ID du PCI-DSS v3.2.1
12.5 IA-4, IA-2, IA-8 N/A

Principe de sécurité : utilisez l’authentification unique (SSO) pour simplifier l’expérience utilisateur pour l’authentification auprès des ressources, y compris les applications et les données entre les services cloud et les environnements locaux.

Conseils Azure : Utilisez Azure AD pour l’accès aux applications de charge de travail (côté client) via l’authentification unique Azure AD, ce qui réduit le besoin de comptes en double. Azure AD fournit la gestion des identités et des accès aux ressources Azure (dans le plan de gestion, notamment l’interface CLI, PowerShell, le portail), les applications cloud et les applications locales.

Azure AD prend également en charge l’authentification unique pour les identités d’entreprise, telles que les identités d’utilisateur d’entreprise, ainsi que les identités d’utilisateurs externes provenant d’utilisateurs tiers et publics approuvés.

Implémentation Azure et contexte supplémentaire :

Conseils AWS : Utilisez AWS Cognito pour gérer les accces à vos charges de travail d’applications orientées client via l’authentification unique (SSO) pour permettre aux clients de relier leurs identités tierces à partir de différents fournisseurs d’identité.

Pour l’accès à l’authentification unique aux ressources natives AWS (y compris l’accès à la console AWS ou à la gestion des services et l’accès au niveau du plan de données), utilisez AWS Sigle Sign-On pour réduire la nécessité de comptes en double.

L’authentification unique AWS vous permet également de ponter des identités d’entreprise (telles que des identités d’Azure Active Directory) avec des identités AWS, ainsi que des identités utilisateur externes provenant d’utilisateurs tiers et publics approuvés.

Implémentation AWS et contexte supplémentaire :

Conseils GCP : Utilisez Google Cloud Identity pour gérer l’accès à votre application de charge de travail orientée client via l’authentification unique Google Cloud Identity, ce qui réduit la nécessité de comptes en double. Google Cloud Identity fournit la gestion des identités et des accès au GCP (dans le plan de gestion, notamment Google Cloud CLI, accès à la console), aux applications cloud et aux applications locales.

Google Cloud Identity prend également en charge l’authentification unique pour les identités d’entreprise, telles que les identités d’utilisateur d’entreprise d’Azure AD ou Active Directory, ainsi que les identités d’utilisateurs externes provenant d’utilisateurs tiers et publics approuvés. Implémentation GCP et contexte supplémentaire :

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

Messagerie instantanée 6 : Utiliser des contrôles d’authentification forts

ID des contrôles CIS v8 ID NIST SP 800-53 r4 ID du PCI-DSS v3.2.1
6.3, 6.4 AC-2, AC-3, IA-2, IA-5, IA-8 7.2, 8.2, 8.3, 8.4

Principe de sécurité : appliquez des contrôles d’authentification forts (authentification sans mot de passe forte ou authentification multifacteur) avec votre système de gestion d’identité et d’authentification centralisé pour tous les accès aux ressources. L’authentification basée uniquement sur les informations d’identification de mot de passe est considérée comme héritée, car elle n’est pas sécurisée et ne tient pas compte des méthodes d’attaque populaires.

Lors du déploiement d’une authentification forte, configurez d’abord les administrateurs et les utilisateurs privilégiés pour garantir le niveau le plus élevé de la méthode d’authentification forte, puis déployez rapidement la stratégie d’authentification forte appropriée pour tous les utilisateurs.

Remarque : si l’authentification par mot de passe héritée est requise pour les applications et scénarios hérités, assurez-vous que les meilleures pratiques de sécurité de mot de passe, telles que les exigences de complexité, sont suivies.

Conseils Azure : Azure AD prend en charge des contrôles d’authentification forts via des méthodes sans mot de passe et l’authentification multifacteur (MFA).

  • Authentification sans mot de passe : utilisez l’authentification sans mot de passe comme méthode d’authentification par défaut. Il existe trois options disponibles dans l’authentification sans mot de passe : Windows Hello Entreprise, connexion par téléphone de l’application Microsoft Authenticator et clés de sécurité FIDO2. En outre, les clients peuvent utiliser des méthodes d’authentification locales telles que des cartes à puce.
  • Authentification multifacteur : Azure MFA peut être appliqué à tous les utilisateurs, sélectionner des utilisateurs ou au niveau de chaque utilisateur en fonction des conditions de connexion et des facteurs de risque. Activez Azure MFA et suivez les recommandations de gestion des identités et des accès Microsoft Defender pour cloud pour votre configuration de l’authentification multifacteur.

Si l’authentification par mot de passe héritée est toujours utilisée pour l’authentification Azure AD, sachez que les comptes cloud uniquement (comptes d’utilisateur créés directement dans Azure) ont une stratégie de mot de passe de base par défaut. Et les comptes hybrides (comptes d’utilisateur provenant d’Active Directory local) suivent les stratégies de mot de passe locales.

Pour les applications et services tiers qui peuvent avoir des ID et des mots de passe par défaut, vous devez les désactiver ou les modifier lors de la configuration initiale du service.

Implémentation Azure et contexte supplémentaire :

Conseils AWS : AWS IAM prend en charge des contrôles d’authentification forts via l’authentification multifacteur (MFA). L’authentification multifacteur peut être appliquée à tous les utilisateurs, sélectionner des utilisateurs ou au niveau par utilisateur en fonction des conditions définies.

Si vous utilisez des comptes d’entreprise à partir d’un annuaire tiers (tel que Windows Active Directory) avec des identités AWS, suivez les instructions de sécurité respectives pour appliquer l’authentification forte. Reportez-vous au guide Azure pour ce contrôle si vous utilisez Azure AD pour gérer l’accès AWS.

Remarque : Pour les applications tierces et les services AWS qui peuvent avoir des ID et des mots de passe par défaut, vous devez les désactiver ou les modifier lors de la configuration initiale du service.

Implémentation AWS et contexte supplémentaire :

Conseils GCP : Google Cloud Identity prend en charge des contrôles d’authentification forts via l’authentification multifacteur (MFA). L’authentification multifacteur peut être appliquée à tous les utilisateurs, sélectionner des utilisateurs ou au niveau par utilisateur en fonction des conditions définies. Pour protéger les comptes super administrateurs d’identité cloud (et d’espace de travail), envisagez d’utiliser des clés de sécurité et le programme Google Advanced Protection pour une sécurité maximale.

Si vous utilisez des comptes d’entreprise à partir d’un annuaire tiers (tel que Windows Active Directory) avec des identités Google Cloud, suivez les instructions de sécurité respectives pour appliquer une authentification forte. Reportez-vous aux conseils Azure pour ce contrôle si vous utilisez Azure AD pour gérer l’accès à Google Cloud.

Utilisez Identity-Aware proxy pour établir une couche d’autorisation centrale pour les applications accessibles par HTTPS. Vous pouvez donc utiliser un modèle de contrôle d’accès au niveau de l’application au lieu de s’appuyer sur des pare-feu au niveau du réseau.

Remarque : Pour les applications tierces et les services GCP qui peuvent avoir des ID et des mots de passe par défaut, vous devez les désactiver ou les modifier pendant la configuration initiale du service.

Implémentation GCP et contexte supplémentaire :

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

IM-7 : Restreindre l’accès aux ressources selon des critères spécifiques.

ID des contrôles CIS v8 ID NIST SP 800-53 r4 ID du PCI-DSS v3.2.1
3.3, 6.4, 13.5 AC-2, AC-3, AC-6 7.2

Principe de sécurité : validez explicitement les signaux approuvés pour autoriser ou refuser l’accès utilisateur aux ressources, dans le cadre d’un modèle d’accès de confiance zéro. Les signaux à valider doivent inclure une authentification forte du compte d’utilisateur, l’analyse comportementale du compte d’utilisateur, la fiabilité de l’appareil, l’appartenance à un utilisateur ou un groupe, des emplacements, et ainsi de suite.

Conseils Azure : Utilisez l’accès conditionnel Azure AD pour des contrôles d’accès plus granulaires basés sur des conditions définies par l’utilisateur, telles que la nécessité de connexions utilisateur à partir de certaines plages d’adresses IP (ou appareils) pour utiliser l’authentification multifacteur. L’accès conditionnel Azure AD vous permet d’appliquer des contrôles d’accès sur les applications de votre organisation en fonction de certaines conditions.

Définissez les conditions et critères applicables pour l’accès conditionnel Azure AD dans la charge de travail. Tenez compte des cas d’usage courants suivants :

  • Exiger l’authentification multifacteur pour les utilisateurs dotés de rôles d’administration
  • Exiger l’authentification multifacteur pour les tâches de gestion Azure
  • Blocage des connexions pour les utilisateurs qui tentent d’utiliser des protocoles d’authentification hérités
  • Exiger des emplacements approuvés pour l’inscription d’Azure AD Multi-Factor Authentication
  • Blocage ou octroi d’accès à partir d’emplacements spécifiques
  • Blocage des comportements de connexion à risque
  • Exiger des appareils gérés par l’organisation pour des applications spécifiques

Remarque : Les contrôles de gestion de session d’authentification granulaire peuvent également être implémentés via une stratégie d’accès conditionnel Azure AD, comme la fréquence de connexion et la session de navigateur persistante.

Implémentation Azure et contexte supplémentaire :

Conseils AWS : Créez une stratégie IAM et définissez des conditions pour des contrôles d’accès plus granulaires basés sur des conditions définies par l’utilisateur, telles que l’exigence de connexions utilisateur à partir de certaines plages d’adresses IP (ou appareils) pour utiliser l’authentification multifacteur. Les paramètres de condition peuvent inclure des conditions uniques ou multiples, ainsi que des logiques.

Les stratégies peuvent être définies à partir de six dimensions différentes : stratégies basées sur l’identité, stratégies basées sur les ressources, limites d’autorisations, stratégie de contrôle de service AWS Organizations (SCP), Listes de contrôle d’accès (ACL) et stratégies de session.

Implémentation AWS et contexte supplémentaire :

Conseils GCP : Créez et définissez des conditions IAM pour des contrôles d’accès basés sur des attributs plus granulaires basés sur des conditions définies par l’utilisateur, telles que la nécessité de connexions utilisateur à partir de certaines plages d’adresses IP (ou appareils) pour utiliser l’authentification multifacteur. Les paramètres de condition peuvent inclure des conditions uniques ou multiples, ainsi que la logique.

Les conditions sont spécifiées dans les liaisons de rôle de la stratégie d’autorisation d’une ressource. Les attributs de condition sont basés sur la ressource demandée( par exemple, son type ou son nom) ou sur des détails sur la demande, par exemple son horodatage ou son adresse IP de destination.

Implémentation GCP et contexte supplémentaire :

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

Messagerie instantanée 8 : Restreindre l’exposition des informations d’identification et des secrets

ID des contrôles CIS v8 ID NIST SP 800-53 r4 ID du PCI-DSS v3.2.1
16.9, 16.12 IA-5 3.5, 6.3, 8.2

Principe de sécurité : Assurez-vous que les développeurs d’applications gèrent en toute sécurité les informations d’identification et les secrets :

  • Évitez d’incorporer les informations d’identification et les secrets dans les fichiers de code et de configuration
  • Utiliser le coffre de clés ou un service de magasin de clés sécurisé pour stocker les informations d’identification et les secrets
  • Recherchez les informations d’identification dans le code source.

Remarque : Cela est souvent régi et appliqué par le biais d’un cycle de vie de développement logiciel sécurisé (SDLC) et d’un processus de sécurité DevOps.

Conseils Azure : lorsque vous utilisez une identité managée n’est pas une option, assurez-vous que les secrets et les informations d’identification sont stockés dans des emplacements sécurisés tels qu’Azure Key Vault, au lieu de les incorporer dans le code et les fichiers de configuration.

Si vous utilisez Azure DevOps et GitHub pour votre plateforme de gestion de code :

  • Implémentez Le scanneur d’informations d’identification Azure DevOps pour identifier les informations d’identification dans le code.
  • Pour GitHub, utilisez la fonctionnalité d’analyse des secrets native pour identifier les informations d’identification ou d’autres formes de secrets dans le code.

Les clients tels qu’Azure Functions, les services Azure Apps et les machines virtuelles peuvent utiliser des identités managées pour accéder en toute sécurité à Azure Key Vault. Consultez les contrôles de protection des données liés à l’utilisation d’Azure Key Vault pour la gestion des secrets.

Remarque : Azure Key Vault fournit une rotation automatique pour les services pris en charge. Pour les secrets qui ne peuvent pas être automatiquement pivotés, vérifiez qu’ils sont pivotés manuellement et vidés manuellement lorsqu’ils ne sont plus utilisés.

Implémentation Azure et contexte supplémentaire :

Conseils AWS : lorsque vous utilisez un rôle IAM pour l’accès aux applications n’est pas une option, assurez-vous que les secrets et les informations d’identification sont stockés dans des emplacements sécurisés tels que AWS Secret Manager ou Systems Manager Parameter Store, au lieu de les incorporer dans le code et les fichiers de configuration.

Utilisez CodeGuru Reviewer pour l’analyse statique du code, qui peut détecter les secrets codés en dur dans votre code source.

Si vous utilisez Azure DevOps et GitHub pour votre plateforme de gestion de code :

  • Implémentez Le scanneur d’informations d’identification Azure DevOps pour identifier les informations d’identification dans le code.
  • Pour GitHub, utilisez la fonctionnalité d’analyse des secrets native pour identifier les informations d’identification ou d’autres formes de secrets dans le code.

Remarque : Le Gestionnaire des secrets fournit une rotation automatique des secrets pour les services pris en charge. Pour les secrets qui ne peuvent pas être automatiquement pivotés, vérifiez qu’ils sont pivotés manuellement et vidés manuellement lorsqu’ils ne sont plus utilisés.

Implémentation AWS et contexte supplémentaire :

Conseils GCP : lorsqu'un compte de service géré par Google n'est pas une option pour l'accès aux applications, assurez-vous que les secrets et les identifiants sont stockés dans des emplacements sécurisés tels que le Gestionnaire de secrets de Google Cloud au lieu de les incorporer dans le code et les fichiers de configuration.

Utilisez l’extension Google Cloud Code sur l’environnement de développement intégré (IDE) telle que Visual Studio Code pour intégrer des secrets gérés par Secret Manager dans votre code.

Si vous utilisez Azure DevOps ou GitHub pour votre plateforme de gestion de code :

  • Implémentez Le scanneur d’informations d’identification Azure DevOps pour identifier les informations d’identification dans le code.
  • Pour GitHub, utilisez la fonctionnalité d’analyse des secrets native pour identifier les informations d’identification ou d’autres formes de secrets dans le code.

Remarque : Configurez les planifications de rotation pour les secrets stockés dans Secret Manager comme meilleure pratique.

Implémentation GCP et contexte supplémentaire :

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

Messagerie instantanée 9 : Sécuriser l’accès utilisateur aux applications existantes

ID des contrôles CIS v8 ID NIST SP 800-53 r4 ID du PCI-DSS v3.2.1
6,7, 12,5 AC-2, AC-3, SC-11 N/A

Principe de sécurité : dans un environnement hybride, où vous disposez d’applications locales ou d’applications cloud non natives à l’aide de l’authentification héritée, envisagez des solutions telles que le répartiteur de sécurité d’accès cloud (CASB), le proxy d’application, l’authentification unique (SSO) pour régir l’accès à ces applications pour les avantages suivants :

  • Appliquer une authentification forte centralisée
  • Surveiller et contrôler les activités des utilisateurs finaux risquées
  • Surveiller et corriger les activités d’applications héritées risquées
  • Détecter et empêcher la transmission de données sensibles

Conseils Azure : Protégez vos applications cloud locales et non natives à l’aide de l’authentification héritée en les connectant à :

  • Azure AD Application Proxy et configurez l'authentification basée sur l'en-tête pour permettre aux utilisateurs distants d'accéder aux applications, tout en validant explicitement la fiabilité des utilisateurs distants et des appareils avec l'accès conditionnel Azure AD. Si nécessaire, utilisez une solution Software-Defined de périmètre (SDP) tierce qui peut offrir des fonctionnalités similaires.
  • Microsoft Defender pour Cloud Apps, qui sert de courtier en sécurité d'accès au cloud (CASB) pour surveiller et bloquer l'accès des utilisateurs aux applications SaaS tierces non approuvées.
  • Vos contrôleurs et réseaux de remise d’applications tiers existants.

Remarque : les VPN sont couramment utilisés pour accéder aux applications héritées, et ont souvent uniquement un contrôle d’accès de base et une surveillance limitée des sessions.

Implémentation Azure et contexte supplémentaire :

Conseils AWS : Suivez les instructions d’Azure pour protéger vos applications cloud locales et non natives à l’aide de l’authentification héritée en les connectant à :

  • Le proxy d’application Azure AD, basé sur l'en-tête, est configuré pour autoriser l’authentification unique (SSO) et l'accès aux applications pour les utilisateurs distants, tout en validant explicitement la fiabilité des utilisateurs distants et des appareils via l'accès conditionnel Azure AD. Si nécessaire, utilisez une solution tierce Software-Defined de périmètre (SDP) qui peut offrir des fonctionnalités similaires.
  • Microsoft Defender pour Cloud Apps, qui sert de service d’accès au cloud (CASB) pour surveiller et bloquer l’accès utilisateur aux applications SaaS tierces non approuvées.
  • Vos contrôleurs et réseaux de remise d’applications tiers existants

Remarque : les VPN sont couramment utilisés pour accéder aux applications héritées, et ont souvent uniquement un contrôle d’accès de base et une surveillance limitée des sessions.

Implémentation AWS et contexte supplémentaire :

Conseils GCP : Utilisez Google Cloud Identity-Aware Proxy (IAP) pour gérer l’accès aux applications HTTP en dehors de Google Cloud, y compris les applications locales. IAP fonctionne à l’aide d’en-têtes signés ou de l’API Utilisateurs dans un environnement standard du moteur d’application. Si nécessaire, utilisez une solution tierce Software-Defined Perimeter (SDP) qui peut offrir des fonctionnalités similaires.

Vous avez également la possibilité d’utiliser Microsoft Defender pour Cloud Apps, qui sert de service de sécurité d’accès cloud (CASB) pour surveiller et bloquer l’accès utilisateur aux applications SaaS tierces non approuvées.

Remarque : les VPN sont couramment utilisés pour accéder aux applications héritées et ont souvent uniquement un contrôle d’accès de base et une surveillance limitée des sessions.

Implémentation GCP et contexte supplémentaire :

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