Amazon SOA-C02: Sécurité, identité et conformité — Guide d'étude

By Laurynas Brazys · 2 August 2026 · #amazon #soa-c02 #certification #exam-prep #study-guide

Fait partie du AWS SysOps Administrator Associate SOA-C02 — Guide d’étude. Entraînez-vous avec des réponses vérifiées dans le centre d’examens Amazon, ou passez des tests chronométrés sur ExamRoll.io.

Ce domaine couvre les primitives d’identité, de chiffrement, de secrets et d’audit qui sous-tendent des opérations AWS sécurisées et conformes. Il se concentre sur l’octroi des bons accès (principe du moindre privilège), la protection des données grâce à la gestion des clés et au chiffrement, et la création de pistes d’audit immuables pour une conformité continue. Les responsabilités quotidiennes d’un SysOps incluent la conception de rôles IAM et de périmètres de confiance, l’exploitation des clés KMS et des secrets, et l’utilisation d’AWS Config et de CloudTrail pour détecter les dérives et les violations de politique.

IAM, rôles, politiques et fédération

La gouvernance IAM doit commencer par la séparation des rôles et le moindre privilège : utilisez des rôles distincts pour l’administration, la journalisation et les charges de travail applicatives ; évitez d’attacher des politiques larges comme AdministratorAccess à des principaux à longue durée de vie. Créez des rôles avec une politique de confiance (console ou CLI : aws iam create-role –role-name AppRole –assume-role-policy-document file://trust.json) et attachez des politiques de permission en utilisant aws iam put-role-policy ou des politiques gérées. Utilisez des périmètres de permission (permission boundaries) et des conditions IAM (aws:SourceIp, aws:RequestedRegion) pour limiter où et comment les privilèges peuvent être exercés.

Pour la fédération d’identité, préférez SAML/OIDC pour émettre des informations d’identification temporaires via STS. Pour SAML, configurez un fournisseur d’identité dans IAM et utilisez aws sts assume-role-with-saml –role-arn arn:aws:iam::123456789012:role/SAMLRole –principal-arn arn:aws:iam::123456789012:saml-provider/IdP. Pour OIDC (Cognito, Auth0 ou d’autres fournisseurs), créez un fournisseur OIDC IAM et mappez les revendications (claims) aux rôles ; la fédération d’identité web utilise aws sts assume-role-with-web-identity. Choisissez des rôles fédérés lorsque les utilisateurs sont externes ou lorsque des services d’annuaire centraux gèrent l’authentification ; utilisez AWS IAM Identity Center (SSO) pour un accès d’entreprise centralisé et la gestion des sessions.

KMS, gestion des clés et chiffrement

KMS est le service central pour le cycle de vie des clés et le contrôle d’accès. Choisissez entre les clés gérées par AWS (simplicité), les clés détenues par AWS et les clés gérées par le client (CMK) (contrôle affiné). Créez des CMK avec aws kms create-key –description “CMK for prod” et activez la rotation automatique avec aws kms enable-key-rotation –key-id alias/ProdKey. Utilisez les politiques de clé pour définir qui peut gérer les clés et utilisez des autorisations (grants) pour la délégation d’accès temporaire (aws kms create-grant) plutôt que des politiques IAM larges.

Critères de décision : utilisez les CMK lorsque l’audit et le contrôle du cycle de vie des clés (rotation, fenêtres de suppression) sont requis ; utilisez les clés gérées par AWS pour la commodité automatique dans de nombreux services gérés. Protégez les clés en appliquant des politiques IAM + des politiques de clé, restreignez l’utilisation via kms:ViaService ou des autorisations KMS (grants) pour une utilisation inter-comptes, et évitez de planifier une suppression immédiate — utilisez une période d’attente minimale. Surveillez l’utilisation de KMS avec les journaux CloudTrail pour les opérations Encrypt/Decrypt et GenerateDataKey afin de détecter une utilisation anormale.

Gestion des secrets et Parameter Store

Utilisez AWS Secrets Manager pour la rotation des informations d’identification et l’automatisation du cycle de vie, et Systems Manager Parameter Store (SecureString) pour les secrets plus simples où la rotation est manuelle. Créez des secrets via aws secretsmanager create-secret –name prod/db –secret-string ‘{“username”:“app”,“password”:"…"}’ et activez la rotation en spécifiant une fonction Lambda pour la rotation automatique. Pour Parameter Store, utilisez aws ssm put-parameter –name /prod/db/password –value “…” –type SecureString –key-id alias/ProdKey.

Points de décision :

Secrets Manager : rotation intégrée, versions des secrets, réplication et modèles de rotation intégrés à la console ; coût plus élevé mais mieux adapté pour les informations d’identification de base de données et les clés d’API.
Parameter Store SecureString : niveau gratuit pour le stockage de secrets de base, utilisez une CMK KMS pour le chiffrement et des politiques IAM pour l’accès. Restreignez toujours l’accès aux secrets via des politiques IAM de moindre privilège et préférez un accès basé sur les rôles (rôles d’exécution EC2/ECS/Lambda) plutôt que d’intégrer des informations d’identification à longue durée de vie dans le code ou les variables d’environnement.

AWS Config, audit et surveillance de la conformité

AWS Config fournit un enregistrement continu des ressources, un historique des modifications et une évaluation des règles. Activez un enregistreur et un canal de livraison (console ou aws configservice start-configuration-recorder) et créez des règles gérées ou personnalisées avec aws configservice put-config-rule. Combinez Config avec CloudTrail (aws cloudtrail create-trail –name audit –s3-bucket audit-bucket) et des alarmes CloudWatch pour une détection et une remédiation quasi en temps réel (utilisez les actions de remédiation de Config ou les documents Systems Manager Automation).

Décisions de conception : utilisez les règles gérées de Config pour les vérifications standard (lecture publique de compartiment S3, MFA sur le compte root) et des règles personnalisées (Lambda) pour les contrôles spécifiques au domaine. Assurez l’agrégation multi-régions des données Config dans un agrégateur et activez l’enregistrement multi-comptes via AWS Organizations. Conservez une piste d’audit immuable en envoyant les journaux CloudTrail vers un compartiment S3 centralisé et chiffré (SSE-KMS) et activez CloudTrail Insights pour détecter les activités d’API anormales.

Protection des données, chiffrement en transit et au repos

Le chiffrement doit être appliqué en couches : au repos en utilisant le chiffrement basé sur KMS pour EBS, RDS, S3 (SSE-S3, SSE-KMS ou SSE-C) et en transit en utilisant TLS pour le trafic applicatif (utilisez ACM pour les certificats publics/privés et attachez-les aux écouteurs (listeners) ALB/NLB : aws elbv2 create-listener –load-balancer-arn … –protocol HTTPS –port 443 –certificates CertificateArn=arn:aws:acm:…). Utilisez le chiffrement côté client lorsqu’un contrôle supplémentaire est requis et envisagez le chiffrement d’enveloppe avec GenerateDataKey lors du chiffrement de grandes quantités de données dépassant les quotas de KMS.

Appliquez ces critères de décision :

Utilisez SSE-KMS pour les objets S3 lorsque vous avez besoin d’un audit et de contrôles d’accès aux clés ; SSE-S3 convient pour un chiffrement de base côté serveur.
Utilisez les CMK KMS pour EBS et RDS lorsque vous avez besoin de la rotation des clés et d’un contrôle d’accès inter-comptes.
Appliquez toujours TLS pour les points de terminaison de service ; utilisez HSTS et des algorithmes de chiffrement forts dans les répartiteurs de charge. Utilisez des points de terminaison de VPC et des politiques IAM pour réduire l’exposition publique des API du plan de données.

Pièges courants et critères de décision

Utilisation excessive du compte root ou stockage des informations d’identification root : à la place, créez des rôles d’administrateur avec MFA et utilisez AWS SSO ou des rôles IAM pour les tâches quotidiennes ; verrouillez les informations d’identification root dans un coffre-fort sécurisé et activez MFA.
Dépendance vis-à-vis des clés d’accès à longue durée de vie : effectuez une rotation régulière des clés ou éliminez-les au profit d’informations d’identification temporaires via STS et le chaînage de rôles (rôles EC2/ECS/Lambda).
Absence de rotation ou protection incorrecte des clés KMS et des secrets : activez la rotation automatique pour les CMK lorsque cela est approprié, utilisez la rotation de Secrets Manager pour les informations d’identification de base de données, et surveillez l’utilisation des clés via CloudTrail.
Dépendance vis-à-vis des autorisations S3 par défaut ou des ACL : appliquez des politiques de compartiment, bloquez l’accès public et utilisez SSE-KMS pour les données sensibles ; validez avec les règles AWS Config.
Mauvaise utilisation des politiques de clé par rapport aux politiques IAM : gérez l’administration des clés dans la politique de clé KMS et accordez l’utilisation via des grants ou IAM lorsque cela est approprié ; évitez d’accorder largement l’autorisation Decrypt.
Oubli de la journalisation centralisée et de l’agrégation multi-régions : configurez des journaux de suivi multi-régions CloudTrail et des agrégateurs Config pour la conformité inter-comptes.

Problème pratique : Scénario d’utilisation

AcmeFin, une entreprise de la fintech, doit sécuriser ses bases de données et API de production tout en fournissant un accès temporaire à des sous-traitants et en maintenant une auditabilité pour les audits de conformité.

Créez des rôles IAM distincts pour l’accès administrateur, applicatif et sous-traitant ; imposez MFA et utilisez IAM Identity Center pour la fédération basée sur SAML pour les sous-traitants.
Chiffrez RDS et EBS avec une CMK gérée par le client (aws kms create-key), activez la rotation des clés et restreignez l’utilisation de la clé via une politique de clé stricte n’autorisant que les rôles de base de données et d’audit.
Stockez les informations d’identification de la base de données dans AWS Secrets Manager avec une rotation automatisée en utilisant le modèle de rotation Lambda fourni.
Activez CloudTrail (multi-régions) et l’enregistreur AWS Config, envoyez les journaux vers un compartiment S3 central chiffré avec SSE-KMS, et créez des règles Config pour les S3 publics et les ressources non chiffrées.
Utilisez un ALB avec des certificats émis par ACM pour le HTTPS, et placez les API derrière WAF et des points de terminaison VPC lorsque cela est approprié.

Cette approche applique le moindre privilège via la séparation des rôles, automatise la rotation des informations d’identification et des clés pour réduire le rayon d’impact, et centralise les journaux et les évaluations Config afin que les auditeurs puissent vérifier les contrôles tandis que les opérations conservent des modèles d’accès sécurisés et temporaires.

← Déploiement · Tous les domaines · Réseaux et diffusion de contenu →

Entraînez-vous sur ces questions → · Tests chronométrés sur ExamRoll.io →