Un fournisseur de plateforme de stockage cloud avait déployé des politiques d’accès aux comptes de stockage Azure au lancement du service, des politiques qui reflétaient la classification des données et le modèle d’accès prévus au lancement. Le compte de stockage analytique avait été configuré avec l’accès public aux blobs désactivé, mais avec un accès authentifié accordé à tous les membres du locataire Azure AD de l’entreprise, une configuration raisonnable lorsque le stockage contenait des indicateurs analytiques agrégés auxquels tous les employés pouvaient légitimement accéder. Au cours des quatorze mois suivants, le contenu du compte de stockage a beaucoup évolué : des analyses au niveau individuel ont été ajoutées, des données attribuées à des clients y ont été stockées à des fins de reporting, et le compte est finalement devenu le dépôt principal d’un extrait d’analyses clients contenant des données personnelles au niveau de l’enregistrement individuel. La classification des données était de fait passée d’agrégat interne à PII client confidentielles, mais personne n’avait mis à jour la politique d’accès du compte de stockage. La politique accordait toujours un accès en lecture à tous les utilisateurs Azure AD authentifiés. Lorsque ce changement a été repéré lors d’une revue de conformité au GDPR, la politique d’accès était trop permissive pour des données personnelles confidentielles depuis onze mois. Trois mille employés avaient un accès en lecture. La politique était techniquement correcte pour un compte de stockage contenant des indicateurs agrégés. Elle était gravement inadaptée pour un compte de stockage contenant des PII clients.
Que sont réellement les mauvaises configurations des politiques d’accès ?
Les mauvaises configurations des politiques d’accès sont des paramètres de contrôle d’accès qui ne reflètent pas correctement le modèle d’accès prévu pour un système, une ressource ou des données à un instant donné. Elles peuvent avoir trois origines distinctes : une configuration initiale incorrecte, une dérive de configuration due à des changements non autorisés ou non revus, et l’obsolescence de configuration, c’est-à-dire une configuration initiale correcte devenue incorrecte parce que le système, les données ou le contexte organisationnel qu’elle régit ont changé sans mise à jour correspondante de la politique.
L’obsolescence de configuration est la catégorie de mauvaise configuration la plus courante sur le plan opérationnel et la moins souvent évaluée. La mauvaise configuration initiale est traitée par les listes de contrôle de déploiement et les référentiels de sécurité. La dérive non autorisée est traitée par l’infrastructure en tant que code et les contrôles de gestion des changements. L’obsolescence est traitée par la revue périodique des politiques, qui confirme que les politiques d’accès restent appropriées compte tenu des changements survenus depuis la dernière revue dans la classification des données, les populations d’utilisateurs, la fonction des systèmes et la structure organisationnelle. Les organisations dotées de contrôles de déploiement et d’une gestion des changements matures présentent souvent une obsolescence importante de leurs politiques, faute d’avoir maintenu la cadence de revue des politiques existantes.
Le scénario de reclassification des données est le schéma d’obsolescence aux conséquences les plus lourdes. Lorsque des données stockées dans un système sont reclassées à un niveau supérieur (d’interne à confidentiel, de confidentiel à restreint), la politique d’accès appropriée à la classification d’origine peut être nettement trop permissive pour la nouvelle. Dans la plupart des organisations, les événements de reclassification des données ne déclenchent pas automatiquement de revue des politiques d’accès. La reclassification a lieu dans le système de gouvernance des données. La politique d’accès du compte de stockage cloud, de la base de données ou du serveur d’applications reste inchangée, sauf si quelqu’un relie expressément l’événement de reclassification à une obligation de revue des politiques.
- Obsolescence de configuration due à la reclassification des données : politiques d’accès restées au niveau d’autorisation de la classification d’origine après le reclassement des données à un niveau supérieur
- Extension du périmètre sans mise à jour des politiques : systèmes dont le périmètre de données dépasse le modèle d’accès initial sans révision des politiques d’accès
- Changements de population d’utilisateurs non répercutés dans les politiques : politiques configurées pour la population d’utilisateurs initiale, qui s’est depuis élargie ou a changé
- Persistance de paramètres par défaut permissifs hérités : configuration trop permissive définie lors du déploiement, acceptable à un niveau de sensibilité plus faible et jamais resserrée à mesure que la sensibilité augmentait
- Aucune cadence de revue des politiques : politiques d’accès revues lors du déploiement et plus jamais de façon périodique ensuite
Pourquoi c’est important
Les mauvaises configurations des politiques d’accès sont importantes pour le TPRM, car les fournisseurs qui détiennent des données clients peuvent avoir des politiques d’accès au stockage, aux bases de données et aux applications correctement configurées pour la sensibilité initiale de ces données, mais non mises à jour à mesure que les données ont évolué. Un fournisseur dont le volume, la sensibilité et la classification réglementaire des données clients ont fortement augmenté depuis le déploiement du système peut avoir des politiques d’accès qui étaient appropriées lors du déploiement et qui sont aujourd’hui beaucoup trop permissives.
La dimension des environnements cloud est particulièrement pertinente. Les comptes de stockage cloud, les conteneurs blob, les serveurs de bases de données et les politiques d’accès API sont configurés lors de la création des ressources avec des paramètres qui reflètent le modèle d’accès prévu à ce moment-là. À mesure que les environnements cloud évoluent (nouvelles données ajoutées, nouvelles intégrations connectées, nouvelles équipes accédant aux ressources), les politiques d’accès correctes à leur création ont de plus en plus de chances d’être mal configurées par rapport à l’état actuel. Les outils de gestion de la posture de sécurité du cloud traitent précisément ce problème en comparant en continu les configurations actuelles des politiques d’accès aux exigences de sécurité actuelles.
Là où la plupart des équipes se trompent
La défaillance la plus constante consiste à traiter la revue des politiques d’accès comme une activité de déploiement plutôt que comme une obligation de gouvernance périodique. Les revues du processus de déploiement confirment que les politiques sont correctes à leur création. Les revues périodiques confirment que les politiques restent correctes à mesure que les systèmes et les données qu’elles régissent évoluent. La plupart des organisations disposent des premières, mais pas des secondes à une cadence suffisante.
- Traiter la revue des politiques comme une activité de déploiement plutôt que comme une obligation périodique
- Reclassification des données ne déclenchant pas de revue des politiques
- Aucun CSPM pour la surveillance continue de la conformité des politiques
- Cadence de revue des politiques non définie ou non maintenue
- Surveillance de la dérive de configuration limitée aux changements non autorisés, sans l’obsolescence
À quoi ressemblent les bonnes pratiques
Les programmes matures de gouvernance des politiques d’accès relient les obligations de revue des politiques aux événements qui créent l’obsolescence (reclassification des données, extension du périmètre, changements de population d’utilisateurs) et mettent en place une surveillance continue au moyen d’outils CSPM qui détectent les configurations de politiques incompatibles avec les exigences de sécurité actuelles.
- Revue des politiques déclenchée par des événements : reclassification des données, changements de périmètre et changements de population d’utilisateurs déclenchant une revue des politiques d’accès
- Surveillance CSPM continue : les politiques d’accès cloud sont évaluées en continu au regard des exigences de sécurité actuelles
- Cadence de revue périodique des politiques : toutes les politiques d’accès sont revues selon un calendrier défini, indépendamment des événements déclencheurs
- Classification des données liée aux exigences des politiques d’accès : les changements de classification sont automatiquement signalés pour revue des politiques
- Politique en tant que code : politiques d’accès définies dans du code sous contrôle de version soumis à une revue des changements
Outils
Gestion de la posture de sécurité du cloud : Wiz, Orca, Prisma Cloud
Les plateformes CSPM évaluent en continu les politiques d’accès aux ressources cloud au regard des bonnes pratiques de sécurité et des exigences des politiques organisationnelles : elles identifient les comptes de stockage dotés d’accès trop permissifs, les politiques d’accès aux bases de données incompatibles avec la classification des données et les politiques de passerelle API qui ont dérivé par rapport aux référentiels de sécurité. Pour les professionnels du TPRM, demander si le fournisseur utilise un CSPM avec surveillance continue de la conformité des politiques constitue une question précise sur la détection de l’obsolescence.
Infrastructure en tant que code : Terraform, AWS CloudFormation, Azure Bicep
Les outils d’IaC définissent la configuration de l’infrastructure dans du code sous contrôle de version, ce qui permet une revue des changements pour les modifications des politiques d’accès et fournit un registre à jour de la configuration prévue des politiques, comparable à la configuration réellement déployée. Pour les professionnels du TPRM, demander si les politiques d’accès sont définies en IaC sous contrôle de version avec revue des changements constitue une question précise sur la prévention de la dérive et de l’obsolescence.
Enjeux de gouvernance
La difficulté de gouvernance liée aux mauvaises configurations des politiques d’accès tient au cloisonnement entre les événements qui créent l’obsolescence et les processus de gouvernance qui permettraient d’y remédier. Les systèmes de classification des données, les plateformes de gouvernance des données et les équipes de sécurité relèvent de domaines organisationnels distincts. Lorsqu’une équipe de gouvernance des données reclasse un jeu de données, il n’existe généralement aucune notification automatique à l’équipe d’infrastructure responsable des politiques d’accès qui régissent ce jeu de données. Combler cet écart exige soit une intégration des processus entre la gouvernance des données et la gouvernance des politiques d’accès, soit une surveillance continue par CSPM qui détecte l’incohérence sans nécessiter de notification.
- Mettre en œuvre un CSPM pour la surveillance continue de la conformité des politiques d’accès
- Relier la reclassification des données à l’obligation de revue des politiques d’accès
- Définir une cadence de revue périodique des politiques : la fréquence à laquelle toutes les politiques d’accès sont revues, indépendamment des événements
- Inclure l’obsolescence des politiques dans l’évaluation de la gouvernance des accès
- Interroger les fournisseurs sur leur couverture CSPM et les derniers constats d’analyse de conformité des politiques
Si vous êtes une petite équipe
Demandez à vos fournisseurs hébergés dans le cloud les derniers constats d’analyse CSPM relatifs aux mauvaises configurations des politiques d’accès : plus précisément, des comptes de stockage, des bases de données ou des ressources API ont-ils été identifiés avec des politiques d’accès incompatibles avec la classification de leurs données ? Cette question révèle à la fois si un CSPM est utilisé et s’il a détecté des mauvaises configurations dues à l’obsolescence. Pour les fournisseurs sans CSPM, demandez quand les politiques d’accès ont été revues pour la dernière fois pour les systèmes contenant vos données et si des événements de reclassification des données au cours des douze derniers mois ont déclenché une revue des politiques d’accès.
- Demander les derniers constats CSPM relatifs aux mauvaises configurations des politiques d’accès
- Demander si les événements de reclassification des données déclenchent des revues des politiques d’accès
- Demander quand les politiques d’accès ont été revues pour la dernière fois pour les systèmes contenant des données clients
- Demander si les politiques d’accès sont définies en IaC sous contrôle de version
Ce qu’il faut exiger
Demandez directement :
« Utilisez-vous un outil de gestion de la posture de sécurité du cloud qui surveille en continu les politiques d’accès pour détecter les mauvaises configurations, et qu’a révélé la dernière analyse concernant les politiques d’accès des systèmes contenant nos données ? »
« Lorsque des données stockées dans vos systèmes sont reclassées à un niveau de sensibilité supérieur, cette reclassification déclenche-t-elle automatiquement une revue des politiques d’accès qui régissent ces données, ou les politiques d’accès sont-elles revues indépendamment des changements de classification des données ? »
Preuves attendues
- Outil CSPM et derniers constats d’analyse
- Processus reliant la reclassification des données à la revue des politiques
- Documentation de la cadence de revue des politiques d’accès
- Mise en œuvre de la politique en tant que code pour la gestion des changements des politiques d’accès
Il faut demander à un fournisseur qui confirme que les politiques d’accès sont correctement configurées lors du déploiement quand ces politiques ont été revues pour la dernière fois et si des changements de données ou de systèmes depuis le déploiement ont déclenché une revue des politiques. Être correct au déploiement décrit un seul instant. La question est de savoir si cette exactitude a été maintenue.
Comment le prouver
- Registres d’analyse CSPM pour la conformité des politiques d’accès
- Lien entre reclassification des données et revue des politiques
- Registres de la cadence de revue des politiques d’accès
- Processus de revue des changements IaC pour les politiques d’accès
À retenir
La politique était correcte lorsqu’elle a été rédigée, pour les données pour lesquelles elle avait été rédigée. Les données ont changé. La politique, non. Onze mois d’accès trop permissif à des PII clients dans un compte de stockage dont la classification était passée d’indicateurs agrégés à des enregistrements individuels : la politique n’a jamais été erronée par conception, seulement par obsolescence. Les mauvaises configurations des politiques d’accès ne sont pas toujours des erreurs. Ce sont souvent des configurations correctes que le temps a rendues incorrectes. L’exigence de gouvernance ne consiste pas seulement à bien configurer lors du déploiement, mais à maintenir une configuration correcte à mesure que les systèmes et les données régis par les politiques évoluent. Le CSPM surveille les incohérences en continu. La revue périodique détecte ce qui échappe aux seuils du CSPM. La revue déclenchée par des événements détecte ce que la cadence périodique atteindrait trop tard.