Classification des données et Amazon Macie

Votre organisation possède 3 200 buckets S3. Quelqu'un à la conformité pose une question raisonnable : lesquels contiennent des données personnelles de clients ? Dans la plupart des comptes, la réponse honnête est que personne ne le sait.

Cet écart n'est pas qu'un problème d'audit. Chaque contrôle que vous pourriez appliquer a un coût. Chiffrer avec une clé customer managed, activer les data events CloudTrail au niveau objet, restreindre le partage inter-comptes, épingler les données à des Regions approuvées : appliquez tout partout et la facture comme la friction deviennent insoutenables. N'appliquez rien et un bucket finira par gâcher la semaine de l'entreprise.

La classification des données est la sortie de ce piège. La compétence d'examen 4.2.1 demande d'implémenter et d'appliquer un schéma de classification, et ce sont 2 métiers différents. L'implémenter, c'est définir des niveaux et étiqueter les données. L'appliquer, c'est que l'étiquette change vraiment ce qu'AWS autorise.

Un niveau est un jeu de règles de traitement, pas un autocollant

Un schéma de classification, c'est un petit nombre de niveaux, chacun lié à une base de contrôles. Une forme courante ressemble à ceci :

Les noms des niveaux comptent moins que la deuxième et la troisième colonne. Une étiquette sans règle de traitement attachée est de la décoration. Une règle de traitement sans étiquette à laquelle s'accrocher ne s'applique à rien.

C'est là que les équipes se trompent de façon prévisible. La tentation est de tout classer au niveau le plus haut, en partant du principe qu'un excès de protection n'a jamais nui. AWS dit exactement l'inverse : la surclassification engendre une dépense injustifiée par des contrôles coûteux, perturbe les opérations métier, et détourne l'attention des jeux de données qui en ont vraiment besoin. Les organismes de normalisation, dont ISO et NIST, recommandent des schémas à niveaux pour cette raison précise et déconseillent les pratiques qui traitent toutes les données de la même façon. Si votre schéma range 90 % du parc dans le niveau supérieur, le schéma a échoué même si chaque jeu de données est « protégé ».

Les 5 étapes, et où les services AWS s'accrochent

AWS décrit la classification comme un processus répétable plutôt que comme un projet ponctuel. Chaque étape a un service qui la porte :

1. Établir un catalogue de données. Inventoriez les types de données que vous détenez, leurs usages, et ceux qui tombent sous une réglementation. AWS Glue Data Catalog stocke et partage ces métadonnées avec suivi des changements de schéma.
2. Évaluer la criticité métier et l'impact. Pour chaque type de données, qu'arrive-t-il à l'activité en cas de divulgation, d'altération ou de perte ? C'est l'étape qui décide du niveau, et ce n'est pas une étape technique.
3. Étiqueter l'information. Attachez le niveau aux ressources réelles. Sur AWS, cela veut dire taguer, et la section suivante s'y consacre.
4. Traiter les actifs selon leur niveau. Les contrôles de la troisième colonne deviennent de vraies politiques, de vraies clés, de vrais réglages.
5. Surveiller en continu. Vérifiez que les étiquettes correspondent toujours à la réalité et que le traitement est toujours appliqué. C'est là que vivent Macie et AWS Config.

Les étapes 3 et 5 forment le couple que la plupart des schémas ratent. L'étiquetage est une déclaration faite par celui qui a créé la ressource. La surveillance est la vérification de cette déclaration face aux octets réellement stockés. Un schéma avec étiquetage et sans vérification est un schéma bâti sur l'espoir.

Les tags sont la poignée que le schéma attrape

Sur AWS, l'étiquette pratique est un tag, et une seule clé de tag utilisée avec constance vaut mieux qu'une taxonomie élaborée que personne n'applique. Quelque chose comme DataClassification avec les valeurs public, internal, confidential et restricted.

La raison de se standardiser sur une seule clé, c'est que le tag devient une condition de politique. Une bucket policy peut exiger un tag de principal correspondant :

{
  "Sid": "RestrictedDataNeedsMatchingClearance",
  "Effect": "Deny",
  "Principal": "*",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::example-data-lake/*",
  "Condition": {
    "StringNotEquals": {
      "aws:PrincipalTag/DataClearance": "restricted"
    }
  }
}

La même idée marche sur une key policy KMS, donc la clé du niveau confidential ne sert qu'aux principals portant le tag d'habilitation correspondant. C'est de l'attribute-based access control appliqué à un schéma de classification, et c'est toute la différence entre une étiquette et un contrôle.

Deux mécanismes gardent les tags honnêtes :

• Prévention. Un SCP avec une condition aws:RequestTag refuse la création de ressource quand le tag de classification manque, pour les services qui prennent en charge le tagging à la création. Cela empêche l'apparition de ressources non taguées.
• Détection. La règle managée AWS Config required-tags signale les ressources dépourvues du tag, et elle peut porter une action de remédiation automatique. Cela rattrape tout ce que la prévention a laissé passer.

Ni l'un ni l'autre ne sait vous dire si le tag est juste. Un bucket tagué internal qui accumule discrètement des numéros de passeport passe les deux contrôles. C'est précisément cet angle mort que Macie existe pour fermer.

Macie commence par un inventaire, pas par un scan

Activez Amazon Macie dans un compte et la première chose qu'il fait est de générer et de tenir à jour un inventaire de vos buckets S3 general purpose, puis de les évaluer et de les surveiller sur la sécurité et le contrôle d'accès. Aucun contenu d'objet n'est encore lu. Cette phase porte sur les métadonnées : réglages d'accès public, réglages de chiffrement, partage, réplication, nombre d'objets, et quelle part du bucket Macie pourrait analyser si on le lui demandait.

Quand les réglages d'un bucket changent d'une façon qui réduit sa sécurité ou sa confidentialité, Macie écrit un policy finding :

Une propriété des policy findings piège constamment, donc nommons-la avant qu'elle ne morde : Macie génère un policy finding uniquement si le changement survient après l'activation de Macie pour le compte. Un bucket dont les réglages block public access étaient déjà désactivés au moment de l'activation, et qui l'est resté, ne produit aucun finding. Macie guette des changements, il n'audite pas un état de départ. Pour voir l'état préexistant, vous lisez l'inventaire des buckets et sa répartition d'accès public, et c'est pour cela que l'inventaire est une fonctionnalité à part entière et pas un effet de bord.

Les policy findings sont conservés 90 jours. Si un policy finding se reproduit, Macie met à jour le finding existant et incrémente le compteur d'occurrences au lieu d'en créer un nouveau.

Deux façons de regarder à l'intérieur des objets

Lire le contenu des objets est une activité distincte et facturée, et Macie vous donne 2 méthodes aux métiers vraiment différents.

La découverte automatique des données sensibles est l'option largeur. Macie évalue en continu votre inventaire de buckets, utilise l'échantillonnage pour choisir des objets représentatifs, et les analyse, à raison d'un cycle par jour. Par défaut elle couvre tous les buckets S3 general purpose, et pour un administrateur Macie cela inclut les buckets appartenant aux comptes membres. Vous la resserrez en excluant des buckets, ce qui vaut le coup pour ceux qui ne contiennent que des logs. Par défaut elle utilise le jeu de managed data identifiers qu'AWS recommande pour la découverte automatique, et vous pouvez y substituer des identifiants managés précis, vos propres identifiants personnalisés, ou les deux. La sortie, ce sont des sensitive data findings, des scores de sensibilité par bucket, et une heat map interactive du parc.

Les sensitive data discovery jobs sont l'option profondeur. Vous définissez les buckets, la profondeur d'échantillonnage et des critères tirés des propriétés d'objets, puis vous lancez le job une fois pour une évaluation à la demande ou selon une planification récurrente.

La frontière de coût mérite d'être mémorisée parce qu'elle décide la réponse aux questions de scénario. À la première activation de Macie, le compte entre dans un essai gratuit de 30 jours couvrant l'évaluation des buckets et, selon les réglages du compte, la découverte automatique. Les discovery jobs ne sont pas inclus dans l'essai gratuit. Si une question évoque une équipe qui a activé Macie, n'a vu aucun frais, puis a reçu une facture surprise, un discovery job est le coupable habituel.

Ce que Macie cherche, et ce qu'il ignore

Trois composants décident de la surface de détection :

• Les managed data identifiers sont les critères intégrés d'AWS, à base de machine learning et de correspondance de motifs. Ils couvrent une liste large et croissante de types de données sensibles pour de nombreux pays et régions : plusieurs sortes de PII, des informations financières, et des identifiants.
• Les custom data identifiers sont les vôtres. Une expression régulière qui définit un motif de texte, affinée si besoin par des séquences de caractères et une règle de proximité. C'est ainsi que vous détectez des identifiants propriétaires, des noms de code internes, ou un format de numéro de compte maison.
• Les allow lists définissent le texte et les motifs que Macie doit ignorer. L'usage canonique, ce sont les numéros de téléphone publics de votre organisation et les noms de ses représentants, ou les jeux de données de test qui déclenchent les détecteurs de PII à chaque exécution.

Les allow lists sont le bouton de réglage qu'on oublie. Si un type de finding se déclenche à répétition sur des données délibérément publiques, le correctif est une allow list, pas une pile de règles de suppression posées sur un détecteur bruyant.

Quand Macie trouve quelque chose, il écrit un sensitive data finding qui nomme la catégorie :

Contrairement aux policy findings, chaque sensitive data finding est traité comme nouveau et unique, même pour le même objet d'une exécution à l'autre. Ils sont eux aussi conservés 90 jours, et c'est un plafond de rétention à anticiper : si la preuve doit survivre au-delà de 90 jours, exportez-la via EventBridge ou Security Hub CSPM vers un stockage que vous contrôlez.

Macie à l'échelle d'une organisation

Macie s'intègre à AWS Organizations, et les règles sont assez précises pour être de la matière d'examen.

Le compte de gestion Organizations désigne un administrateur Macie délégué, et seul le compte de gestion peut créer, changer ou retirer cette désignation. Une organisation a exactement un administrateur Macie, et un compte ne peut pas être administrateur et membre en même temps.

Vient ensuite la propriété qui fait trébucher les montages multi-Regions : Macie est un service régional, alors qu'AWS Organizations est global. La désignation de l'administrateur est par Region. Si le compte de gestion désigne un administrateur dans us-east-1, cet administrateur ne gère les comptes membres que dans us-east-1. Couvrir 4 Regions veut dire se connecter à chacune et désigner l'administrateur 4 fois. Le compte désigné doit être le même partout, mais la désignation, elle, se répète.

Trois règles de plus valent d'être retenues :

• Un administrateur Macie peut être associé à au maximum 10 000 comptes membres dans chaque Region.
• L'administrateur ne peut pas activer Macie pour le compte de gestion Organizations. Si vous voulez ce compte comme membre, un utilisateur de ce compte doit d'abord y activer Macie.
• Un compte membre ne peut pas se dissocier lui-même. Seul l'administrateur peut le retirer, et le retrait laisse Macie activé dans le compte comme compte autonome au lieu de le désactiver.

Refermer la boucle du finding au contrôle

Un finding sur lequel personne n'agit est une version plus lente du fait de ne pas regarder. Macie publie ses findings sur Amazon EventBridge sous forme d'événements, ce qui les route vers des cibles comme des fonctions Lambda et des topics SNS pour un traitement quasiment en temps réel. Vous pouvez aussi configurer Macie pour publier ses findings dans AWS Security Hub CSPM, qui les agrège aux côtés de ceux de GuardDuty, d'Inspector et des autres, avec agrégation multi-Regions vers une Region unique.

Le schéma d'application qui satisfait la compétence 4.2.1 ressemble à ceci de bout en bout :

1. La découverte automatique de Macie trouve SensitiveData:S3Object/Financial dans un bucket tagué DataClassification=internal.
2. Le finding arrive sur EventBridge, capté par une règle filtrant sur le type de finding et la sévérité.
3. Une cible Lambda retague le bucket en confidential et ouvre un ticket nommant le propriétaire lu dans le tag owner du bucket.
4. Comme la bucket policy et la key policy KMS sont déjà indexées sur DataClassification, les règles de traitement du niveau prennent effet à la seconde où le tag change.

L'étape 4 est tout l'enjeu. Si le tag n'est branché à rien, l'automatisation vient juste de renommer un problème.

Conseils pour l'examen

• La compétence 4.2.1 dit implémenter et appliquer. Une réponse qui se contente de détecter et de signaler est incomplète quand une autre option relie l'étiquette à une permission.
• La surclassification est une mauvaise réponse, pas une réponse prudente. Méfiez-vous des options qui proposent le contrôle le plus strict pour toutes les données.
• Macie analyse les buckets Amazon S3 general purpose. Si une question porte sur du contenu RDS, EBS ou DynamoDB, Macie n'est pas la réponse.
• Les policy findings ne se déclenchent que pour des changements postérieurs à l'activation de Macie. Les faiblesses préexistantes apparaissent dans l'inventaire des buckets, pas dans les findings.
• Découverte automatique = large, continue, échantillonnée, tous les buckets par défaut, incluse dans l'essai gratuit de 30 jours. Discovery job = ciblé, à la demande ou planifié, profondeur configurée, hors essai gratuit.
• Custom data identifier = une regex pour ce qu'AWS ne connaît pas. Allow list = du texte à ignorer. Les deux pointent dans des directions opposées.
• Les deux catégories de findings sont conservées 90 jours. Les policy findings se mettent à jour sur place à la récurrence ; les sensitive data findings sont toujours nouveaux.
• Macie est régional. Désignation de l'administrateur délégué, associations de membres et quota de 10 000 membres sont tous par Region, et seul le compte de gestion Organizations peut désigner l'administrateur.
• Les findings atteignent l'automatisation par EventBridge, et une vue de posture consolidée par Security Hub CSPM.

Ce qu'il faut emporter : la classification est ce qui rend abordable chaque contrôle suivant de ce sujet. Chiffrement, key policies, portée des certificats et rotation des secrets deviennent tous moins chers et plus nets quand ils s'appliquent au bon sous-ensemble plutôt qu'à tout. La leçon suivante prend la règle de traitement du niveau confidential au pied de la lettre et la construit avec KMS.