Pourquoi une règle VPN ne peut pas empêcher l’envoi d’un fichier
Atteindre un service et contrôler quels fichiers en sortent sont deux exigences. Placez la règle là où le fichier est visible : courriel, application ou agent de poste.
Une petite équipe demande un accès à distance à ses systèmes de travail et, dans le même souffle, demande que certaines pièces jointes cessent de quitter l’entreprise. Les deux demandes ressemblent à un seul changement VPN. Ce sont deux exigences avec des points d’application différents, et une règle qui satisfait la première ne fait rien pour la seconde. Commencez par nommer l’action et les données, puis choisissez le composant qui peut réellement les voir.
Une demande, deux exigences
La première exigence concerne l’accessibilité : quels utilisateurs et appareils peuvent ouvrir une connexion vers quel service. La seconde concerne le comportement une fois cette connexion établie : quels documents peuvent être joints, collés ou téléversés. Un tunnel agit sur la première et est aveugle à la seconde par conception.
Un contrôle au niveau IP achemine des paquets. Il n’analyse pas un téléversement multipart, n’inspecte pas un PDF et ne décide pas si un tableur contient des numéros de compte. Attendre cela de lui n’est pas une erreur de configuration ; c’est une erreur de catégorie.
Dites l’exigence à voix haute sous cette forme avant de chercher un produit. « Les utilisateurs peuvent atteindre le portail de fichiers » et « les utilisateurs ne peuvent pas téléverser des listes de clients sur le portail de fichiers » sont deux phrases différentes, et seule la seconde décrit une politique de contenu.
Choisissez le composant qui peut voir le fichier
L’application doit avoir lieu là où le fichier est lisible. Pour le courriel, c’est généralement la plateforme ou la passerelle de messagerie, qui traite déjà les pièces jointes et peut les évaluer avant la remise. Pour les téléversements par navigateur vers un service autorisé, l’application elle-même peut être la seule partie qui voit le contenu. Pour un ordinateur portable géré qui copie des fichiers vers un support amovible, un agent de poste voit l’opération.
| Where the file moves | Component that can see it |
|---|---|
| Email attachment | Mail gateway or mail platform policy |
| Upload to a web application | The application, or an inspection proxy that terminates TLS |
| Copy to USB or local folder | Endpoint agent on the device |
| Anything inside the tunnel | Nothing, unless one of the above is present |
Certaines suites commerciales d’accès à distance regroupent un agent de poste, un contrôle web et un module de prévention des fuites de données. Ces composants peuvent bel et bien appliquer une politique de contenu, mais la capacité appartient au module et non au tunnel. Lisez ce que la suite contient réellement avant de promettre le résultat.
La présentation de la prévention des fuites de données de Purview par Microsoft est un modèle utile pour comparer : elle décrit les politiques en termes de types d’informations sensibles, d’emplacements et d’activités. Ce vocabulaire porte sur le contenu et les actions, non sur les préfixes IP.
TLS survit au tunnel, alors prévoyez-le
Le chiffrement de l’application est négocié entre le client et le service, et un tunnel VPN transporte ces octets sans les ouvrir. Une passerelle sur le chemin n’acquiert donc pas automatiquement la capacité de classer une pièce jointe, quelle que soit la part de la route qu’elle possède.
Pour inspecter le contenu en transit, il faut un composant qui termine TLS avec un certificat de confiance, ce qui est une décision d’architecture importante avec ses propres conséquences sur la vie privée et l’exploitation. Ce n’est pas une case à cocher du profil VPN. Les clients doivent faire confiance au certificat d’inspection, les applications qui épinglent des certificats casseront, et l’opérateur gagne la capacité de lire un trafic qu’il ne pouvait pas lire auparavant. Voilà pourquoi cette décision revient à un responsable de la sécurité plutôt qu’à celui qui exploite le tunnel.
C’est pourquoi la réponse honnête à « le VPN peut-il bloquer ce téléversement » est généralement non, suivie d’une alternative concrète. L’alternative peut être des restrictions au niveau de l’application, une règle de messagerie ou une politique de poste, et chacune a un responsable qui peut la modifier.
Écrivez le test d’acceptation avant la règle
Une règle de contenu a besoin de deux exemples, pas d’un seul : une action autorisée qui doit continuer de fonctionner et une action interdite qui doit être arrêtée. Testez les deux depuis les applications et les appareils concernés, car une politique qui ne fonctionne que dans un navigateur n’est pas la politique demandée.
curl -sS -o /dev/null -w '%{http_code}\n' -F '[email protected]' https://files.plant.example/upload
curl -sS -o /dev/null -w '%{http_code}\n' -F '[email protected]' https://files.plant.example/uploadLa première requête devrait être refusée par le composant qui possède la règle, et la seconde devrait réussir. Si les deux réussissent, le contrôle n’est pas sur le chemin. Si les deux échouent, vous avez cassé le service au lieu de le protéger, ce qui est le résultat le plus courant d’une règle écrite sans exemple autorisé.
Décidez à l’avance ce que l’utilisateur voit, qui peut accorder une exception et où un administrateur confirme la décision ensuite. Un téléversement bloqué sans message produit un ticket d’assistance, et une règle que personne ne peut auditer produit une dispute. Les deux s’évitent avec une phrase de documentation écrite avant la mise en service de la politique.
Enfin, gardez les deux exigences dans des tickets séparés avec des responsables séparés. Les regrouper sous « VPN » garantit que l’équipe réseau devra résoudre un problème de contenu et que le problème de contenu sera déclaré résolu quand le tunnel sera monté.