Partager via


Exiger le chiffrement TLS pour la transmission d’e-mails sensibles pour la conformité du gouvernement australien avec PSPF

Cet article fournit des conseils aux organisations gouvernementales australiennes sur l’utilisation du protocole TLS (Transport Layer Security) pour protéger les informations classifiées de sécurité. Son objectif est d’aider les organisations gouvernementales à comprendre leurs exigences en matière de chiffrement, ainsi que la façon dont Microsoft 365 peut être configuré pour y remédier. Les conseils de cet article ont été rédigés pour s’aligner au mieux sur les exigences décrites dans la Politique 8 du Framework de stratégie de sécurité de protection (PSPF) : Informations sensibles et classifiées et le Manuel de sécurité des informations (ISM).

TLS est un type de chiffrement qui peut être utilisé pour garantir que les données ne peuvent pas être interceptées pendant la transmission. Par défaut, Exchange Online utilise toujours le protocole TLS opportuniste. Tls opportuniste signifie Exchange Online essaie toujours de chiffrer les connexions avec la version la plus sécurisée de TLS, puis de descendre dans la liste des chiffrements TLS jusqu’à ce qu’il en trouve un sur lequel les deux parties peuvent s’entendre. Il est important de noter que TLS est appliqué au serveur de messagerie et s’applique à tous les e-mails envoyés à partir du serveur, plutôt qu’au niveau de l’utilisateur ou du client. Pour plus d’informations sur TLS dans Microsoft 365, consultez comment Exchange Online utilise TLS pour sécuriser les connexions de messagerie.

Le paramètre tls par défaut dans Exchange Online répond aux exigences du Manuel de sécurité des informations (ISM).

Conditions requises Détails
ISM-0572 (juin 2024) Le chiffrement TLS opportuniste est activé sur les serveurs de messagerie qui effectuent des connexions de messagerie entrantes ou sortantes sur une infrastructure réseau publique.

La configuration TLS opportuniste est également abordée dans Blueprint for Secure Cloud d’ASD.

Le fait de conserver le chiffrement des e-mails facultatif pour les informations hautement sensibles augmente les risques de perte d’informations. Un environnement compromis ou mal géré au sein d’un cluster de partenaires gouvernementaux ou externes peut entraîner l’envoi d’informations sensibles sur l’Internet public en texte brut. Tls opportuniste garantit que les messages sont chiffrés au niveau le plus élevé possible afin que le destinataire prévu puisse recevoir les informations, comme prévu. Les organisations gouvernementales disposent d’une topologie de transport qui utilise des connecteurs qui nécessitent TLS pour la transmission de tous les éléments entre les organisations gouvernementales.

Ces configurations permettent de garantir que toutes les communications par e-mail entre une liste fixe d’organisations sont chiffrées. Toutefois, il ne permet pas que le chiffrement TLS soit requis pour les destinataires en dehors de la liste prédéfinie des organisations. Prenons l’exemple d’un cabinet sous contrat, tel qu’un avocat, qui exige que des informations sensibles lui soient envoyées. Le fait d’être en dehors de la liste fixe des domaines qui nécessitent TLS peut entraîner l’envoi d’éléments de manière non sécurisée.

Le rapport de messages sortants Exchange Online fournit des rapports sur le pourcentage d’e-mails envoyés avec et sans chiffrement TLS. Pour plus d’informations sur les rapports de messages sortants, consultez rapports de messages dans Exchange Online.

Les organisations avec un faible pourcentage d’e-mails non chiffrés peuvent envisager une approche TLS forcée pour tous les messages sortants. Cette configuration peut empêcher un e-mail non sensible d’atteindre sa destination prévue lorsqu’un e-mail est envoyé en dehors de la liste fixe de domaines (par exemple, des e-mails NON OFFICIELs). Pour s’aligner sur la stratégie PSPF (Protection Security Policy Framework) 8 Annexe A (résumé dans exigences de chiffrement), le chiffrement est requis pour la transmission d’e-mails « OFFICIAL : Sensible » et « PROTECTED ». TLS est requis à ces niveaux.

Remarque

Pour de nombreuses organisations gouvernementales, en particulier les agences basées sur les services, la majeure partie de leurs informations appartient à la catégorie OFFICIAL et l’exigence de TLS pour ce volume de courrier peut avoir des répercussions significatives sur les affaires avec les individus et les organisations qui n’ont pas tls. Une approche basée sur les risques, tempérée aux besoins de l’entreprise, est recommandée pour le protocole TLS forcé à ce niveau plutôt que pour le protocole TLS opportuniste.

Pour exiger le chiffrement TLS pour les e-mails plus sensibles, une règle de flux de messagerie Exchange Online peut être utilisée. Cette règle inspecte les en-têtes x des éléments envoyés. Lorsque certaines étiquettes de confidentialité sont appliquées aux éléments, applique une action qui nécessite le chiffrement TLS pour la transmission de l’élément.

Pour construire ces règles de flux de courrier, nous devons comprendre comment les étiquettes sont appliquées aux e-mails. Lorsqu’une étiquette est appliquée, elle est visible dans les en-têtes x de l’e-mail. L’en-tête contenant les informations d’étiquette est nommé msip_labels et inclut un ID d’étiquette, qui correspond à l’étiquette appliquée à un élément.

Les règles de flux de messagerie peuvent case activée l’en-tête msip_labels pour voir si des étiquettes pertinentes sont appliquées via leur ID d’étiquette, ou GUID.

Pour obtenir l’étiquette Identificateurs globaux uniques (GUID) pour un environnement, la sécurité et la conformité, PowerShell peut être utilisé. La commande requise pour afficher les étiquettes d’un environnement et les GUID associés est la suivante :

Get-label | select displayname,guid

La commande PowerShell retourne une liste d’étiquettes de confidentialité avec leurs GUID d’étiquette.

Remarque

Les GUID d’étiquette sont spécifiques à un seul locataire Microsoft 365. Deux locataires avec le même nom d’étiquette ne partageront pas le même GUID.

Une fois obtenus, ces noms d’étiquettes et GUID doivent être enregistrés afin que vous puissiez les utiliser pour la configuration des règles de flux de messagerie Exchange.

Les administrateurs doivent utiliser le centre Exchange Online Administration pour créer des règles qui recherchent l’en-têtemsip_labels. Une règle de flux de messagerie unique peut être utilisée pour case activée pour plusieurs GUID d’étiquette. Veillez à inclure Enabled=True après le GUID d’étiquette lors de la création de la règle. L’exemple suivant vérifie les six variantes d’étiquettes PROTECTED (y compris les marqueurs de gestion des informations et les avertissements) au sein d’un environnement.

Exemple de règle de flux de messagerie pour exiger TLS

Cette règle de flux de courrier est destinée à empêcher la transmission d’e-mails sensibles ou classifiés de sécurité sur Internet sans chiffrement TLS.

Nom de la règle Appliquer cette règle si Procédez comme suit :
Exiger TLS pour l’e-mail PROTECTED Appliquez cette règle si le destinataire est interne/externe :
- En dehors du organization
AND
En-têtes de message...
Incluez l’un des mots suivants :

En-tête:msip_labels
Mots:
- PROTECTED GUID
- PROTECTED Personal Privacy GUID
- PROTECTED Legal Privilege GUID
- PROTECTED Legislative Secrecy GUID
- PROTECTED CABINET GUID
- PROTECTED NATIONAL CABINET GUID
- Modifier la sécurité des messages
- Exiger le chiffrement TLS

Remarque

Avant d’implémenter ces règles, envisagez également votre stratégie de surveillance de l’impact des règles et d’action des éléments qui sont retardés ou bloqués en raison de la réception organization ne prenant pas en charge TLS.