Concevoir et implémenter une infrastructure de sécurité de messagerie
Ce domaine porte sur la protection du flux de messagerie : authentification, autorisation, chiffrement TLS, certificats, filtrage anti-spam et anti-programme malveillant, ainsi que contrôle des relais. L’examen teste la capacité à appliquer le moindre privilège sans casser la remise légitime.
Règles de base
- Les groupes de rôles RBAC doivent être attribués selon les tâches ; un administrateur de destinataires n’a pas besoin des droits d’organisation complète.
- Un connecteur de réception partenaire doit être limité à une plage IP ou à une authentification, jamais laissé en relais anonyme général.
- TLS protège le transport de saut en saut ; il ne chiffre pas le message de bout en bout dans la boîte du destinataire.
- SPF, DKIM et DMARC améliorent l’authentification de l’expéditeur, mais SPF seul n’assure ni chiffrement ni signature du contenu.
- Les règles de transport, le filtrage de pièces jointes et la quarantaine doivent être testés en audit avant application large.
Exemple travaillé
Un partenaire doit envoyer du courrier vers une adresse précise chez contoso.fr depuis une IP fixe. On crée un connecteur de réception lié à cette IP, on exige TLS avec un certificat dont le nom correspond au nom DNS utilisé, puis on ajoute une règle de transport qui refuse les destinataires hors du domaine accepté. Raisonnement : le partenaire obtient un relais contrôlé, le chiffrement est vérifié et le connecteur ne devient pas une passerelle ouverte. On ne se contente pas d’un enregistrement SPF, car SPF ne restreint pas le relais SMTP.
Pièges à éviter
Autoriser le relais anonyme pour « simplifier » ; utiliser un certificat auto-signé non approuvé par le partenaire ; confondre TLS opportuniste et TLS obligatoire ; croire que DMARC bloque à lui seul tout courrier frauduleux ; appliquer une règle de transport sans tester l’ordre des priorités.