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

  • Article

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 d’identité et d’authentification centralisé pour régir les identités et les authentifications de votre organization 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 d’Azure. Vous devez normaliser Azure AD pour régir la gestion des identités et des accès de votre organisation dans :

  • Ressources cloud Microsoft, telles que Stockage Azure, Azure Machines Virtuelles (Linux et Windows), Azure Key Vault, PaaS et applications SaaS.
  • Les ressources de votre organisation, telles que les applications sur Azure, les applications tierces qui s’exécutent sur les ressources réseau de votre entreprise et les applications SaaS tierces.
  • Les identités de votre entreprise dans Active Directory par la synchronisation sur Azure AD pour garantir une stratégie d’identité gérée régulièrement de manière 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 : migrez les applications locales Active Directory vers Azure AD, dès que cela est techniquement possible. Il peut s’agir d’un annuaire d’entreprise Azure AD , d’une configuration interentreprises ou d’une configuration entreprise-client.

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. Par ailleurs, via AWS et Azure Single Sign-On (SSO), vous pouvez également utiliser Azure AD pour gérer l’identité et le contrôle d’accès d’AWS afin d’éviter de gérer les comptes en double séparément dans deux plateformes cloud.

AWS prend en charge les Sign-On uniques, ce 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 de 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. Par le biais de Google Cloud Identity et d’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 mutli-cloud.

Google Cloud Identity est le fournisseur d’identité pour tous les services Google. Il prend en charge la 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 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 Cloud Identity et en chantant Google Cloud Directory Sync, vous pouvez configurer lequel de vos comptes d’utilisateur (y compris les utilisateurs, les groupes, les profils utilisateur, les alias, etc.) se synchronisera 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) :

IM-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 en tant que priorité élevée dans la pratique de sécurité cloud de votre organization. Les contrôles de sécurité communs incluent :

  • Limitation des rôles et des comptes privilégiés
  • Demande d’une authentification renforcée pour tous les accès privilégiés
  • Surveiller et auditer les activités à risque élevé

Conseils Azure : Utilisez la base de référence de sécurité Azure AD et le score de sécurisation des identités Azure AD pour évaluer votre posture de sécurité des identités Azure AD et corriger les lacunes en matière de sécurité et de configuration. Le score de sécurisation des identités Azure AD évalue Azure AD pour les configurations suivantes :

  • Utiliser des rôles d’administration limités
  • Activer la stratégie de risque utilisateur
  • Désigner plus d’un administrateur général
  • Activer une stratégie pour bloquer l’authentification héritée
  • Vérifier que tous les utilisateurs peuvent utiliser une authentification multifacteur pour un accès sécurisé
  • Exiger l'authentification multifacteur pour les rôles administratifs
  • Activer la réinitialisation du mot de passe libre-service
  • Ne pas faire expirer les mots de passe
  • Activer la stratégie de connexion à risque
  • Ne pas autoriser les utilisateurs à donner leur consentement aux applications non managées

Utilisez Azure AD Identity Protection pour détecter, examiner et corriger les risques liés à 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 votre Active Directory local 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)
  • Suivre les principes des privilèges minimum pour les attributions d’accès
  • Tirez parti des groupes IAM pour appliquer des stratégies au lieu d’utilisateurs individuels.
  • Suivez les conseils d’authentification forte dans IM-6 (Utiliser des contrôles d’authentification forte) pour tous les utilisateurs
  • Utiliser la stratégie de contrôle de service (SCP) aws Organizations et les limites d’autorisation
  • 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 les informations d’identification status

Remarque : suivez les meilleures pratiques publiées si vous disposez 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 (comme le compte Google Workspace ou Cloud Identity super administrateur) et ce compte ne doit pas être spécifique à un utilisateur particulier si une récupération d’urgence est nécessaire.
  • Respecter 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 forts ») 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 les 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 disposez 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 PCI-DSS ID(s) 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ées au lieu de créer des comptes humains pour que les applications accèdent aux ressources et exécutent du code. Les identités des applications 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. La plateforme assure entièrement la gestion, la rotation et la protection des informations d’identification d’identité managée, ce qui évite les informations d’identification codées 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 se replier sur les secrets des clients 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 au niveau du 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 des informations d’identification codées en dur dans des fichiers de code source ou 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 IM-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 des informations d’identification codées en dur dans des fichiers de code source ou 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) :

IM-4 : authentifier le serveur et les services

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

Principe de sécurité : Authentifiez les serveurs et services distants du côté client pour vous assurer que vous vous connectez au serveur et aux services approuvés. Le protocole d’authentification de serveur le plus courant est le protocole TLS (Transport Layer Security), où le côté client (souvent un navigateur ou un périphérique client) vérifie le serveur en par une vérification de l’émission par une autorité de certification approuvée du certificat du serveur.

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

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 qui 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/client (en vérifiant le certificat du serveur émis par une autorité de certification approuvée) au cours de la phase de négociation.

Remarque : des services tels que Gestion des API et API Gateway 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 qui 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/client (en vérifiant le certificat du serveur émis par une autorité de certification approuvée) au cours de la phase de négociation.

Remarque : des services tels que API Gateway 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 le prennent pas en charge par défaut ou qui 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/client (en vérifiant le certificat du serveur émis par une autorité de certification approuvée) au cours de la phase de négociation.

Remarque : des 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) :

IM-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 dans les services cloud et les environnements locaux.

Conseils Azure : Utilisez Azure AD pour l’accès aux applications de charge de travail (accessible au client) via l’authentification unique (SSO) 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, y compris l’interface CLI, PowerShell, le portail), aux applications cloud et aux 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 de confiance.

Implémentation Azure et contexte supplémentaire :

Conseils AWS : Utilisez AWS Cognito pour gérer l’accès à 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 SSO 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 le besoin de comptes en double.

L’authentification unique AWS vous permet également de relier des identités d’entreprise (telles que des identités d’Azure Active Directory) avec des identités AWS, ainsi que des identités d’utilisateurs 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 le besoin de comptes en double. Google Cloud Identity fournit une gestion des identités et des accès à GCP (dans le plan de gestion, y compris l’interface CLI Google Cloud, l’accès à la console), les applications cloud et les 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 à partir 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) :

IM-6 : Utiliser des contrôles d’authentification renforcés

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 centralisé de gestion des identités et de l’authentification pour tous les accès aux ressources. La seule authentification basée 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 résiste pas aux méthodes d’attaque populaires.

Lors du déploiement d’une authentification forte, configurez d’abord les administrateurs et les utilisateurs privilégiés, afin de garantir le niveau le plus élevé de méthode d’authentification forte, et ensuite, déployez 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 les scénarios hérités, assurez-vous que les bonnes pratiques en matière de sécurité de mot de passe, telles que les exigences de complexité, sont respectées.

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 par mot de passe : utilisez l’authentification par mot de passe comme méthode d’authentification par défaut. Trois options sont 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 les cartes à puce.
  • L’authentification multifacteur : Azure MFA peut être appliquée à tous les utilisateurs, à certains d’entre eux ou au niveau de chaque utilisateur en fonction des conditions de connexion et des facteurs de risque. Activez Azure MFA et suivez Microsoft Defender recommandations relatives à la gestion des identités et des accès 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, soyez conscient 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 locaux) suivent les stratégies de mot de passe locales.

Pour les applications tierces et les services qui peuvent avoir des mots de passe et ID par défaut, désactivez-les ou modifiez-les 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, à certains utilisateurs ou au niveau par utilisateur en fonction de 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 aux Conseils 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, à certains utilisateurs ou au niveau par utilisateur en fonction de 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 l’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, afin de pouvoir utiliser un modèle de contrôle d’accès au niveau de l’application au lieu de vous 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 lors de 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 en fonction des conditions

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 confiance zéro. Les signaux à valider doivent inclure une forte authentification 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, etc.

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 l’exigence 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 aux applications de votre organisation en fonction de certaines conditions.

Définissez les conditions et les critères applicables à l’accès conditionnel Azure AD dans la charge de travail. Examinez les scénarios courants suivants :

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

Remarque : les contrôles granulaires de gestion des sessions d’authentification peuvent également être implémentés via la 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 en fonction de 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 : les stratégies basées sur les identités, les stratégies basées sur les ressources, les limites d’autorisations, la stratégie de contrôle de service (SCP) aws Organizations, les listes Access Control (ACL) et les 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 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 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) :

IM-8 : Limiter 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
  • Utilisez 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 : cette opération est souvent régie et appliquée par un cycle de vie du développement logiciel sécurisé et 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 les fichiers de code et de configuration.

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

  • Implémenter le moteur d’analyse des informations d’identification Azure DevOps pour identifier les informations d’identification dans le code.
  • Pour GitHub, vous pouvez utiliser la fonctionnalité d’analyse de secret en mode natif 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 à Azure Key Vault en toute sécurité. 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, assurez-vous qu’ils sont pivotés manuellement régulièrement et vidés 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 à l’application 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’AWS Secret Manager ou Systems Manager Parameter Store, au lieu de les incorporer dans les fichiers de code et de configuration.

Utilisez CodeGuru Reviewer pour l’analyse du code statique 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émenter le moteur d’analyse des informations d’identification Azure DevOps pour identifier les informations d’identification dans le code.
  • Pour GitHub, vous pouvez utiliser la fonctionnalité d’analyse de secret en mode natif pour identifier les informations d’identification ou d’autres formes de secrets dans le code.

Remarque : Le Gestionnaire de secrets fournit une rotation automatique des secrets pour les services pris en charge. Pour les secrets qui ne peuvent pas être automatiquement pivotés, assurez-vous qu’ils sont pivotés manuellement régulièrement et vidés lorsqu’ils ne sont plus utilisés.

Implémentation AWS et contexte supplémentaire :

Conseils GCP : Lorsque vous utilisez un compte de service géré par Google pour l’accès à l’application, assurez-vous que les secrets et les informations d’identification sont stockés dans des emplacements sécurisés tels que le Gestionnaire de secrets de Google Cloud au lieu de les incorporer dans les fichiers de code et de configuration.

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

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

  • Implémenter le moteur d’analyse des informations d’identification Azure DevOps pour identifier les informations d’identification dans le code.
  • Pour GitHub, vous pouvez utiliser la fonctionnalité d’analyse de secret en mode natif pour identifier les informations d’identification ou d’autres formes de secrets dans le code.

Remarque : Configurez des planifications de rotation pour les secrets stockés dans Secret Manager en tant que meilleure pratique.

Implémentation GCP et contexte supplémentaire :

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

IM-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 avez des applications locales ou des applications cloud non natives utilisant 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 et l’authentification unique (SSO) pour régir l’accès à ces applications pour les avantages suivants :

  • Appliquer une authentification centralisée renforcée
  • Surveiller et contrôler les activités à risque pour les utilisateurs finaux
  • Surveiller et corriger les activités risquées des applications hérité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 Proxy d'application et configurer l’authentification basée sur l’en-tête pour autoriser l’accès de l’authentification unique (SSO) aux applications pour les utilisateurs distants, 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 Périmètre (SDP) tierce qui peut offrir des fonctionnalités similaires.
  • Microsoft Defender for Cloud Apps, qui sert un service CASB (Cloud Access Security Broker) pour surveiller et bloquer l’accès utilisateur aux applications SaaS tierces non approuvées.
  • Vos réseaux et contrôleurs 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 de session limitée.

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

  • Azure AD Proxy d'application et configurez en fonction de l’en-tête pour autoriser l’accès de l’authentification unique (SSO) aux applications pour les utilisateurs distants, tout en validant explicitement la fiabilité des utilisateurs et des appareils distants avec l’accès conditionnel Azure AD. Si nécessaire, utilisez une solution de périmètre de Software-Defined (SDP) tierce qui peut offrir des fonctionnalités similaires.
  • Microsoft Defender for Cloud Apps, qui sert de service CASB (Cloud Access Security Broker) pour surveiller et bloquer l’accès utilisateur aux applications SaaS tierces non approuvées.
  • Vos contrôleurs et réseaux de remise d’application 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 de session limitée.

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 de périmètre défini par logiciel qui peut offrir des fonctionnalités similaires.

Vous avez également la possibilité d’utiliser Microsoft Defender for Cloud Apps qui sert de service CASB (Cloud Access Security Broker) 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 de session limitée.

Implémentation GCP et contexte supplémentaire :

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