Sécurité des mails
Le SPF est un protocole d’authentification des e-mails qui permet aux serveurs de messagerie de vérifier si un serveur est aurtorisé à envoyer des e-mails pour un domaine donné, afin de lutter contre le spam et l’usurpation d’adresse.
-> Par exemple, pour deuzk.com qui serait sur Microsoft365, votre spf doit être : v=spf1 include:spf.protection.outlook.com -all
Le DKIM permet de signer un message par cryptographie, ce qui permet de s’assurer que le message envoyé n’a pas subit d’altération durant sa livraison.
-> Plusieurs type d’entrées DNS pour vérifier ça, entrée TXT ou CNAME, à voir avec le prestataire
Le DMARC vient s’appuyer sur le principe de « l’alignement », ce qui permet d’agir sur les messages où les protocoles SPF et DKIM ont échoué, en venant appliquer des instructions supplémentaires.
-> Un enregistrement TXT avec la valeur : v=DMARC1; p=reject; ruf=mailto:dmarcreport@deuzk.com; pct=100
SPF / DKIM / DMARC
Le SPF (Sender Policy Framework) est un processus d’authentification qui assure la conformité de l’expéditeur d’un email. Il permet d’indiquer qui est autorisé à utiliser votre nom de domaine en déclarant les adresses IP autorisées à envoyer des mails.
Le DKIM (DomainKeys Identified Mail) permet de signer un message par cryptographie, ce qui permet de s’assurer que le message envoyé n’a pas subit d’altération durant sa livraison.
Le DMARC (Domaine-based Message Authentication , Reporting and Conformance) vient s’appuyer sur le principe de « l’alignement », ce qui permet d’agir sur les messages où les protocoles SPF et DKIM ont échoué, en venant appliquer des instructions supplémentaires
Plus en détail : L’authentification SPF commence par l’identification de toutes les adresses IP légitimes qui doivent envoyer des courriers éléctroniques à partir d’un domaine donné, puis publie cette liste dans le DNS. Avant de délivrer un message, les fournisseurs d’accès au courrier électronique vérifient l’enregistrement SPF en recherchant le domaine inclus dans l’adresse « enveloppe from » dans l’en-tête technique caché du courrier électronique. Si l’adresse IP qui envoie un courrier électronique au nom de ce domaine n’est pas répertoriée dans l’enregistrement SPF du domaine, le message échoue à l’authentification SPF.
Pour l’authentification DKIM, l’expéditeur identifie d’abord les champs qu’il souhaite inclure dans sa signature DKIM. Ces champs peuvent inclure l’adresse “de”, le corps du courriel, l’objet et plus encore. Ces champs doivent rester inchangés pendant le transit, sinon le message échouera l’authentification DKIM. Deuxièmement, la plate-forme de messagerie de l’expéditeur créera un hachage des champs de texte inclus dans la signature DKIM. Une fois que la chaîne de hachage est générée, elle est cryptée avec une clé privée, à laquelle seul l’expéditeur peut accéder. Après l’envoi du courriel, c’est à la passerelle de messagerie ou au fournisseur de boîte aux lettres du consommateur de valider la signature DKIM. Cela se fait en localisant une clé publique qui correspond exactement à la clé privée. Ensuite, la signature DKIM est décryptée pour retrouver sa chaîne de hachage d’origine.
Détail du SPF
Il est possible d’appliquer une politique plus ou moins restrictive à l’aide des signes Tilde et Tiret dans les expressions suivantes :
–all et ~all
La tilde et le tiret identifient 2 types d’échecs différents.
Considérant un message qui ne correspond pas aux paramètres spécifiés dans l’enregistrement SPF :
– Le Tilde provoque un “softfail”, le message sera accepté et marqué comme ne correspondant pas aux paramètres spécifiés ;
– Le Tiret provoque un “hardfail”, le message sera rejeté.
Le problème que l’on peut rencontrer est donc qu’un fournisseur de mails, que l’on aurait autorisé dans notre enregistrement SPF, ajoute un « ~all » ce qui vient annuler notre « -all » que nous avons configuré.
Exemple :
« v=spf1 ip4:xxx.xx.xx.0/24 include:spf.protection.outlook.com include:mktomail.com -all »
Dans cette entrée, notre SPF est bien configuré car le « -all » rejete tous les mails dont le serveur n’est pas spécifié dans l’entrée, SAUF que le serveur « mktomail.com » contient « v=spf1 […] ip4:130.248.173.0/24 ~all » ce qui vient contre-carrer notre « -all » et donc les mails ne seront pas rejetés même si ils ne correspondent pas aux serveurs que l’on a spécifiés.
Nous allons donc mettre en place du DMARC pour contrôler les usages.
DMARC
Pour qu’un message passe l’authentification DMARC, il doit passer l’authentification SPF et l’alignement SPF et/ou passer l’authentification DKIM et l’alignement DKIM. Si un message ne passe pas l’authentification DMARC, les expéditeurs peuvent indiquer aux destinataires ce qu’ils doivent faire de ce message par le biais d’une politique DMARC.
Le propriétaire du domaine peut appliquer trois politiques :
– Aucune (le message est remis au destinataire et le rapport DMARC est envoyé au propriétaire du domaine)
– Quarantaine (le message est déplacé dans un dossier de quarantaine)
– Rejet (le message n’est pas du tout remis).
La politique DMARC de “none” est un bon premier pas. De cette façon, le propriétaire du domaine peut s’assurer que tous les courriels légitimes s’authentifient correctement. Le propriétaire du domaine reçoit des rapports DMARC pour l’aider à s’assurer que tous les courriels légitimes sont identifiés et passent l’authentification. Une fois que le propriétaire du domaine est sûr d’avoir identifié tous les expéditeurs légitimes et d’avoir résolu les problèmes d’authentification, il peut passer à une politique de “rejet” et bloquer les attaques de phishing, de compromission des courriers électroniques d’entreprise et autres fraudes par courrier électronique. En tant que destinataire de courrier électronique, une organisation peut s’assurer que sa passerelle de courrier électronique sécurisée applique la politique DMARC mise en œuvre au propriétaire du domaine. Cela permettra de protéger les employés contre les menaces liées au courrier électronique entrant.
Pour vérifier la configuration de votre DMARC, vous pouvez utiliser ce site : https://powerdmarc.com/analyzer
Sécurité Azure
MIP
Service utilisé pour chiffrer les données et restreindre des fonctionnalités via un système d’étiquetage de contenu. Ces labels restreignent certaines actions comme l’impression, le visionnage, la copie ou encore le téléchargement via des règles d’organisation.
AIP supporte un grand nombre de type de contenu, comme les mails, les fichiers textes, les images, les fichiers Office ou encore les PDF. AIP protège les fichiers sur les serveurs de fichiers locaux mais également sur la plateforme cloud comme sur SharePoint Online ou OneDrive for Business.
Ces niveaux premium incluent toutes les fonctionnalités du plan Azure Information Protection pour Office365 et l’accès à des fonctionnalités supplémentaires telles que le scanner AIP pour trouver des données sensibles dans les plateformes locales, le contrôle et le suivi pour révoquer des accès à des documents et la protection des documents au delà des formats de fichiers Microsoft Office.
Fonctionnalités supplémentaires de MIP P2 :
- Classification automatique et recommandée de documents pour certains types de données qui correspondent à des conditions pour appliquer de la protection autre que manuelle.
- Utilisation automatique de S/MIME pour signer et chiffrer les mails dans Outlook.
- Ajout d’Information Protection dans Outlook pour détecter les potentiels partages d’informations sensibles. L’entreprise peut modifier la réponse en utilisant une pop-up pour avertir l’utilisateur de vérifier son mail, demander une explication sur l’envoi ou encore bloquer l’envoi.
- Mis à disposition de la fonctionnalité HYOK (Hold You Own Key) qui permet de restreindre la diffusion des documents au réseau interne.
- Protection automatique, classification et label sur les fichiers on-prem.
Informations supp. https://www.techtarget.com/searchwindowsserver/tip/Azure-Information-Protection-P1-vs-P2-Whats-the-difference
MIP – Suppression
Créer et publier des étiquettes de sensibilité est simple. Mais que se passe-t-il si vous faites une erreur et souhaitez supprimer une étiquette ? Vous pouvez supprimer l’étiquette d’Office 365. La suppression supprime l’étiquette des stratégies d’étiquette et les clients ne sauront pas que l’étiquette existe. Il s’agit d’une action acceptable lorsque le label n’a pas été appliqué pour protéger les documents, mais problématique pour le contenu protégé. Les métadonnées de l’étiquette restent dans le document. Vous le savez, car si vous définissez une autre étiquette, il vous sera peut-être demandé de fournir une justification si la nouvelle étiquette a une priorité inférieure. Cependant, comme les politiques publiées ne contiennent aucune trace de l’étiquette, les applications ne savent pas comment gérer l’étiquette et la protection du fichier revient à « Non défini » (Figure 2).
En comparaison, si vous supprimez l’étiquette des stratégies, Office 365 inclut toujours les informations d’étiquette dans les stratégies et les clients pourront toujours résoudre l’étiquette. Cependant, les utilisateurs ne verront pas l’étiquette dans la liste des étiquettes qu’ils peuvent appliquer. Il s’agit d’une bien meilleure situation car vous pouvez toujours restaurer l’utilisation complète de l’étiquette si vous le souhaitez ou la conserver dans un état visible mais désactivé par non-publication.
Source : https://office365itpros.com/2019/08/07/dont-delete-office-365-sensitivity-labels/
DLP
Conception d’une règle
Détail des règles de DLP : https://learn.microsoft.com/en-us/microsoft-365/compliance/sensitive-information-type-entity-definitions?view=o365-worldwide
Recherche
$res = Export-ContentExplorerData -TagType SensitiveInformationType -TagName « Credit Card Number » -Workload EXO -UserPrincipalName « xxx@xxx.com »
$res[1..10000] | Export-Csv C:\temp\xxx_odb.csv -NTI
Sécurité Office365
Messagerie Exchange
Les spam sont des messages non sollicités à un grand nombre de destinataires à des fins de publicité commerciale.
Le phishing est une tentative fraudulause d’obtenir des informations ou des données sensibles, telles que des noms d’utilisateur, des mots de passe et des informations de carte de crédit, en se faisant passer pour une entité digne de confiance dans une communication électronique.
Généralement réalisée par usurpation d’adresse e-mail, messagerie instantanée et SMS, le phishing incite souvent les utilisateurs à saisir des informations personnelles sur un faux site Web qui correspond à l’apparence du site légitime.
SharePoint – Label MIP
Il est possible d’appliquer des labels de confidentialité sur des SharePoint, permettant ainsi de forcer le MFA sur ces SharePoint.
Pour cela, on va tout d’abord créer un « Authentication context ». Aller sur le Portail Azure > Conditional Access > Authentication context puis l’onglet « Authentication context (Preview) ». Cliquer sur « New authentication context » et cocher la case « Publish to apps ».
Créer ensuite une règle d’accès conditionnel
A déplacer sur un article spécifique : https://office365itpros.com/2021/06/10/azure-ad-authentication-context-sensitivity-labels/
Accès conditionnel
CA applicatives :
https://www.christianfrohn.dk/2024/04/22/securing-service-principals-in-microsoft-entra-id-with-conditional-access-policies/