Netskope SMTP Proxy - Portail de connaissances de Netskope

This workflow is intended for user-initiated outbound email that leaves the organization. Machine-generated email (for example automated systems, applications, or service accounts) and internal-to-internal mail flows are not supported use cases and should not be enabled for inspection.

Le proxy SMTP Netskope peut être utilisé comme service pour analyser les courriels sortants via SMTP afin de détecter les violations DLP (Prévention des pertes de données). Dans cette solution, un courriel initié par l'utilisateur est reçu par un service de messagerie en nuage tel que MS O365 Exchange ou Gmail. Le courrier électronique passe ensuite par le proxy SMTP Netskope intégré dans votre SMTP workflow. Netskope SMTP Proxy vérifie le contenu de l'e-mail par rapport aux politiques de protection en temps réel et agit sur les violations DLP (Prévention des pertes de données) en fonction de la configuration de la politique. Le courriel est ensuite transmis à un MTA en amont qui recherche le DNS du service de messagerie de destination et envoie le courriel au serveur du destinataire.

SMTP Proxy peut traiter plusieurs messages électroniques au cours d'une seule session SMTP. Cela permet de réduire la charge sur les serveurs de messagerie et de diminuer la latence du courrier électronique pour les messages à fort volume.

Note

Le proxy SMTP n'est pas proposé pour les applications auxquelles on accède par des points de contact en Chine.

Le mandataire SMTP veille à ce qu'un expéditeur valide et autorisé soit spécifié dans l'enveloppe SMTP. Cela permet d'éviter que le service ne soit utilisé comme un proxy ouvert. Dans le cas des courriels "hors du bureau", l'expéditeur sera vide. Ces courriels peuvent être relayés par le service, mais deux paramètres doivent être respectés :

SNI
Un attribut facultatif doit être configuré dans les paramètres SMTP.

Les serveurs de messagerie tels que Google et O-365 envoient le site SNI, mais le client doit configurer un attribut facultatif dans les paramètres SMTP MSA. Si cet attribut correspond à ce qui figure dans le courrier électronique, ce dernier est autorisé. De plus, tous les courriels doivent correspondre à cet attribut, et pas seulement celui sans l'expéditeur.

L'organigramme suivant donne une vue d'ensemble de la solution.

Conditions préalables

Exchange doit être fonctionnel et connecté à un MTA en amont tel que Mimecast ou Proofpoint. Si vous n'utilisez pas de MTA en amont dans votre environnement, vous pouvez faire boucler le trafic de Netskope vers Exchange ou Gmail. Pour plus d'informations, consultez : Envoyer le trafic de Netskope vers Exchange ou Envoyer le trafic de Netskope vers Gmail
Votre configuration SMTP doit utiliser un MTA en amont qui ne nécessite pas d'authentification.
Netskope requiert TLS sur le port 25.
Seuls les protocoles TLS 1.2 et 1.3 sont pris en charge.

Limites

Les courriers électroniques de toute taille peuvent être transférés vers un MTA. La taille par défaut que le moteur DLP (Prévention des pertes de données) traitera est de 64 Mo avec un délai d'attente de 120 secondes.
Le proxy SMTP impose une limite d’implémentation sur le nombre de commandes RCPT. Cela provoquera une réponse par une erreur douce 452 au serveur de messagerie en amont pour toute commande RCPT TO restante. Cela forcera le périphérique en amont à diviser l’e-mail en plusieurs copies après avoir réessayé pour les destinataires restants. Pour plus d’informations, voir le SMTP RFC.
Lors de la création d'une politique de protection en temps réel de Netskope, vous pouvez spécifier un en-tête SMTP. Netskope SMTP Proxy ajoute cet en-tête personnalisé à l'e-mail lorsque le contenu de l'e-mail correspond à la définition de la politique.
Si l'en-tête personnalisé spécifié dans la politique de Netskope est le même que l'en-tête standard du courriel, Netskope SMTP Proxy remplace la valeur de l'en-tête standard par la valeur de l'en-tête personnalisé.
Par exemple, si l'en-tête standard du courriel est X-ns-Exchange-CrossTenant-Network-Message-Id : "1234ABC" et que l'en-tête personnalisé spécifié dans votre politique Netskope est X-NS-Exchange-CrossTenant-Network-Message-Id: "5678DEF", la valeur de l'ID du message dans l'en-tête standard est remplacée par la valeur de l'ID du message dans l'en-tête personnalisé. Ainsi, la valeur finale de l'en-tête envoyé au MTA du prochain saut serait "5678DEF".
Note
- Netskope vous recommande d'utiliser la convention d'appellation X-NETSKOPE-<custom-header-name> lorsque vous spécifiez un en-tête personnalisé dans la politique Netskope DLP (Prévention des pertes de données).
- Netskope SMTP Proxy ajoute l'en-tête x-netskope-inspected: true à chaque e-mail. Cet en-tête ne doit pas non plus être fourni en tant qu'en-tête personnalisé dans une action de politique.
- Les en-têtes sont insensibles à la casse, x-netskope-inspected est identique à X-NETSKOPE-Inspected.
Si une politique contient plusieurs profils DLP (Prévention des pertes de données), chacun avec un en-tête SMTP personnalisé et que plusieurs profils correspondent, seule l'action du premier profil s'appliquera. Il en résultera qu'un seul en-tête personnalisé sera ajouté.
Dans l'interface utilisateur Netskope, sous Paramètres > Security Cloud Platform > Configuration, aucune des options de cette page ne s'applique au proxy SMTP, y compris le Dynamic Trust Store.

Vérification des locataires pour Microsoft Office 365 et Gmail

Un en-tête personnalisé peut être utilisé lors de l'identification du locataire. Cela peut être utile lorsque le SNI n'est pas disponible et que le même domaine est configuré dans plus d'un locataire.

Accédez à Settings > Security Cloud Platform > SMTP et cochez Use Tenant Verification fields for Netskope Tenant Identification.

En cochant la case, une infobox apparaîtra dans l’interface. Expliquant que les paires clé-valeur requises doivent être configurées dans le Email Server Settings.

Vous verrez apparaître le site Tenant Verification field.

Microsoft O365:

Gmail: