Protection des données et chiffrement

Chaque contrôle de protection des données a un coût, donc les appliquer tous partout est intenable et n'en appliquer aucun finit par coûter cher. Ce sujet construit la chaîne qui rend le choix possible : classer ce que vous stockez, chiffrer les données au repos avec des clés que vous contrôlez, les chiffrer pendant qu'elles circulent, et sortir du code les identifiants qui ouvrent l'ensemble. Il couvre la tâche 4.2 de l'examen SOA-C03, et chaque compétence y demande d'implémenter, de configurer, puis de dépanner.

Ce que couvre ce sujet

• Bâtir un schéma de classification à niveaux, avec des règles de traitement attachées à chacun, et les tags comme poignée de contrôle reliant l'étiquette à de vraies permissions
• Amazon Macie : inventaire des buckets, policy findings face aux sensitive data findings, découverte automatique face aux discovery jobs, identifiants managés et personnalisés, allow lists, et administration déléguée à l'échelle d'une organisation
• Le chiffrement par enveloppe et les data keys, les 3 types de clés KMS, et pourquoi une key policy n'accorde rien implicitement
• Les grants, l'encryption context, la rotation des clés et ce qu'elle ne fait pas, les états de clé et le délai d'attente de suppression
• Le chiffrement au repos tel qu'il se manifeste vraiment dans S3 (SSE-S3, SSE-KMS, DSSE-KMS, SSE-C, Bucket Keys) et dans EBS, avec leurs contraintes absolues
• AWS Certificate Manager : validation DNS, email et HTTP, éligibilité au renouvellement managé, comportement régional, security policies ELB, et imposition de HTTPS de bout en bout
• Parameter Store et Secrets Manager : tiers, SecureString, staging labels, les 4 étapes de rotation, rotation managée, accès inter-comptes et fenêtres de suppression

Pourquoi c'est important

Les questions de ce sujet se présentent rarement comme des questions de chiffrement. Elles ressemblent à un AccessDenied avec quatre causes plausibles, à un certificat qui a expiré alors que personne n'avait touché à rien, ou à une facture qui a doublé après l'activation d'une fonctionnalité. Y répondre suppose de tenir les frontières : une key policy KMS ne se comporte pas comme une bucket policy, un certificat importé ne se renouvelle jamais, et un SecureString exige une permission des deux côtés.

Sur le terrain, c'est le sujet où les erreurs sont silencieuses et durables. Un tag de classification faux ne casse rien aujourd'hui. Une clé supprimée par erreur rend des données irrécupérables pour toujours. Un mot de passe figé dans un artefact se retrouve dans un historique Git que personne ne relit. Chacune de ces situations se prévient avec un contrôle simple, à condition de savoir lequel et à quel moment.