Comment créer une politique sûre d’envoi de fichiers pour les chats du support client
Un cadre pratique pour ne demander que les fichiers clients nécessaires, gérer les pièces jointes imprévues et orienter les problèmes de sécurité, de confidentialité et d’accessibilité vers les bonnes personnes.
Un bouton d’envoi n’est pas une politique d’envoi de fichiers
Les captures d’écran, factures, photographies et documents peuvent aider à résoudre un dossier, mais chaque pièce jointe entraîne aussi une décision opérationnelle : ce qui est nécessaire, qui peut la voir, s’il est sûr de l’ouvrir, combien de temps elle est conservée et ce qui se passe lorsque le client envoie un élément inapproprié ou risqué.
Une politique d’envoi de fichiers pour le support client transforme ces décisions en instructions reproductibles pour les clients, les opérateurs de première ligne, les superviseurs, les parties prenantes de la confidentialité et les intervenants de sécurité. Elle doit s’appliquer de manière cohérente sur les canaux de conversation utilisés par votre équipe, tout en reconnaissant que le comportement des canaux et le traitement interne peuvent différer.
Adoptez une défense en profondeur. OWASP indique qu’aucune technique de validation unique n’est suffisante pour les fichiers fournis par les utilisateurs. Une politique solide combine donc la minimisation des données, des catégories autorisées restreintes, des contrôles techniques vérifiés par votre organisation, des procédures pour le personnel, des limites d’accès et des règles d’escalade.
- Responsable de la politique : désignez le responsable des opérations de support ainsi que les approbateurs chargés de la confidentialité, de la sécurité et de la gestion des archives.
- Périmètre : répertoriez chaque canal de support, file d’attente, service et type de dossier couvert.
- Règle de décision : demandez un fichier uniquement lorsqu’il est nécessaire pour résoudre, vérifier ou examiner le dossier indiqué.
- Orientation humaine : donnez à chaque client un moyen de poursuivre avec une personne s’il ne peut pas ou ne doit pas envoyer de fichier.
Classez la tâche de support avant de demander une pièce jointe
Le fichier le plus sûr est celui que vous ne collectez jamais. Avant qu’un agent ou un flux automatisé ne demande un envoi, classez la preuve dans l’un de trois groupes : requise, utile ou interdite.
Les preuves requises sont les informations sans lesquelles l’équipe ne peut raisonnablement effectuer une action de support précise. Les preuves utiles peuvent accélérer le diagnostic mais ne sont pas nécessaires ; proposez-les comme facultatives et expliquez l’alternative. Les informations interdites ne doivent pas être demandées ni acceptées via le chat de support ordinaire.
Cette approche soutient la limitation des finalités et la minimisation des données. Lorsque le RGPD s’applique, les données personnelles doivent être collectées pour une finalité déterminée et limitées à ce qui est nécessaire à cette finalité.
- Requise : une capture d’écran recadrée d’un message d’erreur affiché lorsque le texte ne peut pas être communiqué autrement.
- Utile : une photo montrant des dommages visibles lors de la livraison lorsque le client peut à la place décrire l’état et fournir une référence de commande.
- Ne pas collecter : mots de passe, codes à usage unique, codes de vérification de carte de paiement, codes PIN, données complètes de piste, clés privées ou documents d’identité sans lien avec le dossier.
- Examinez chaque demande d’envoi récurrente : la même décision peut-elle être prise à partir d’un numéro de commande, d’un numéro de dossier, d’une description textuelle ou d’un processus sécurisé conçu à cette fin ?
Définissez les catégories autorisées et rédigez les instructions destinées aux clients avant l’envoi
Définissez une courte liste d’autorisation pour chaque type de dossier plutôt que d’autoriser par défaut de vastes catégories de fichiers. OWASP recommande de n’autoriser que les extensions essentielles à l’activité et de choisir les types les moins dangereux et les moins risqués qui répondent au besoin métier. Évitez d’accepter des fichiers d’archive, sauf s’il existe une raison documentée et que vos responsables techniques ont approuvé un traitement sûr ; la gestion des archives introduit des risques liés à la taille après décompression et à l’extraction.
Rédigez la demande d’envoi dans un langage clair avant que le client agisse. L’instruction doit préciser la finalité du support, le contenu minimal requis, les formats acceptés et toute limite de taille pertinente qui a été vérifiée pour ce canal. Elle doit également indiquer ce qu’il faut retirer et ce qu’il ne faut pas envoyer.
Les instructions accessibles ne sont pas facultatives. Les WCAG 2.2 exigent des étiquettes ou instructions lorsqu’une saisie utilisateur est requise, et les contrôles d’envoi doivent avoir un nom textuel décrivant leur finalité. Ne vous appuyez pas uniquement sur une couleur, une icône ou une image.
- Finalité : « Pour vérifier le problème de livraison, veuillez envoyer une photo de l’extérieur du colis et de l’article endommagé. »
- Minimum : « Veuillez masquer votre adresse, votre numéro de téléphone, votre numéro de compte et toute information non nécessaire pour montrer le problème. »
- Format : indiquez uniquement les formats que votre équipe a approuvés pour cette tâche, par exemple une capture d’écran ou une photographie lorsque cela convient.
- Interdiction : « N’envoyez pas de mots de passe, codes de vérification, codes PIN de carte, codes de sécurité de carte ou informations complètes de carte de paiement. »
- Alternative : « Si vous ne pouvez pas envoyer de fichier, décrivez le texte de l’erreur, la date et l’heure, ainsi que ce que vous tentiez de faire. Un agent peut vous aider. »
Traitez les pièces jointes imprévues et sensibles sans demander de nouvel envoi
Les clients envoient parfois un fichier avant qu’il ne soit demandé, joignent le mauvais élément ou incluent du contenu sensible dans une capture d’écran. Les agents ne doivent pas leur demander de renvoyer le même contenu sensible par le même chat. La répétition accroît l’exposition sans résoudre le problème de traitement sous-jacent.
Créez un script et un circuit de confinement simples. L’agent doit accuser réception du dossier, arrêter toute collecte supplémentaire du contenu sensible, documenter uniquement les faits minimaux requis par la procédure interne et orienter le dossier vers l’équipe désignée chargée de la confidentialité, des paiements, de la sécurité des comptes ou de la sécurité.
Les environnements de paiement exigent des règles particulièrement claires. Les codes de vérification de carte, les codes PIN et les données complètes de piste sont des données d’authentification sensibles et ne conviennent pas aux pièces jointes de chat de support ordinaire. Si des informations de paiement arrivent, suivez la procédure approuvée par l’organisation en matière d’incident et de destruction des données de paiement, plutôt que de les copier dans des notes, modèles ou un autre chat.
- Identifiant ou code de vérification envoyé accidentellement : dites au client de ne rien envoyer de plus, conseillez-lui de modifier ou sécuriser l’identifiant via le circuit de compte approuvé et transmettez le cas à la sécurité des comptes.
- Données de paiement : interrompez toute discussion sur les données, ne les répétez pas et transmettez le cas selon le processus approuvé pour les paiements ou la confidentialité.
- Document d’identité ou information relevant de catégories particulières non nécessaire au dossier : accusez réception sans reformuler les détails et transmettez le cas au responsable de la confidentialité.
- Mauvais fichier ou fichier sans rapport : demandez une alternative plus sûre ou les informations pertinentes minimales, et non un nouvel envoi du document d’origine.
Donnez aux opérateurs des règles sûres pour ouvrir, décrire et partager les fichiers
Le personnel de support de première ligne ne doit pas prendre seul des décisions sur les logiciels malveillants ou la confidentialité. Le NIST conseille aux utilisateurs de ne pas ouvrir de pièces jointes suspectes simplement parce que l’expéditeur est connu. Un nom de client familier, un sujet de dossier attendu ou un nom de fichier plausible ne prouvent pas qu’un fichier est sûr.
Formez les opérateurs à examiner uniquement les informations nécessaires au dossier et seulement dans des outils approuvés. Ils ne doivent pas télécharger un fichier sur un appareil personnel, le transférer vers une messagerie personnelle, le charger dans un service non approuvé ou le partager dans un vaste groupe interne simplement pour obtenir de l’aide.
Une valeur Content-Type ou MIME fournie par un client ne constitue pas une preuve fiable du type réel d’un fichier. Les contrôles techniques peuvent utiliser des listes d’autorisation d’extensions, des signatures de fichiers attendues, des limites de taille et une analyse antimalware ou un sandboxing lorsqu’ils sont disponibles, mais OWASP avertit qu’il s’agit de protections complémentaires et non de garanties autonomes.
- N’ouvrez normalement le fichier que lorsqu’il est attendu, pertinent pour le dossier actif, autorisé par la politique et accessible via des procédures de traitement approuvées.
- Considérez une pièce jointe comme suspecte lorsqu’elle est imprévue, non pertinente, semble exécutable, est une archive non conforme à la politique, est anormalement volumineuse, porte un nom trompeur ou s’accompagne d’une pression pour l’ouvrir de toute urgence.
- Pour les fichiers suspects : ne les ouvrez pas, ne les prévisualisez pas, ne les exécutez pas et ne les examinez pas dans des outils bureautiques ordinaires ; conservez la référence du dossier et transmettez le cas à la sécurité.
- Lorsque vous décrivez un fichier en interne, consignez les faits utiles minimaux : identifiant du dossier, heure de réception, catégorie apparente, motif de l’escalade et mesures prises. Ne reproduisez pas les contenus sensibles dans les notes.
Vérifiez les limites entre les canaux, les boîtes de réception et vos propres protections
Ne rédigez pas une politique qui suppose qu’un canal de messagerie, un widget de chat ou une boîte de réception fournit une analyse antimalware, un contrôle du type de fichier, des contrôles de conservation, des flux de suppression ou des contrôles d’accès fondés sur les rôles, à moins que ces capacités aient été explicitement vérifiées pour la configuration exacte utilisée. L’analyse et le sandboxing sont des protections propres à une implémentation, et non des hypothèses par défaut.
webchat.vip fournit une boîte de réception partagée pour les conversations WebChat et WhatsApp. Les fichiers sont stockés dans un sous-compte Apification Cloud isolé pour chaque service omnicanal. Ces éléments décrivent l’architecture du produit, mais n’établissent pas à eux seuls les contrôles d’analyse, de conservation, de revue des accès ou de réponse aux incidents exigés par votre organisation.
Faites de la vérification technique une exigence formelle de mise en service, dont la responsabilité incombe aux parties prenantes appropriées en matière de sécurité, de confidentialité et de plateforme. Consignez la réponse, les éléments probants, le responsable, la date de revue et tout risque résiduel pour chaque contrôle.
- Quels formats de fichiers, tailles de fichiers et tailles de requêtes sont réellement acceptés dans chaque canal déployé ?
- Un fichier est-il analysé, mis en quarantaine ou exécuté dans un environnement isolé ? Si oui, qui opère ce contrôle, quelle est sa couverture et que se passe-t-il en cas de détection ?
- Qui peut consulter, télécharger, exporter, transférer et supprimer les pièces jointes client dans la boîte de réception configurée et les systèmes connectés ?
- Où les fichiers sont-ils stockés, comment obtenir les journaux d’accès et comment la suppression ou l’application de la conservation fonctionnent-elles concrètement ?
- L’équipe peut-elle empêcher les noms de fichiers ou chemins contrôlés par l’utilisateur, et les fichiers sont-ils séparés du contenu diffusé sur le web lorsque cela est pertinent ?
- Quel processus s’applique si un client demande l’accès, la suppression, la rectification ou des informations sur un fichier envoyé ?
Utilisez une escalade fondée sur les risques, avec un responsable humain nommé
Toute politique doit comporter un circuit d’escalade qui fonctionne en dehors des heures ouvrées et ne dépend pas de l’évaluation de la gravité par un agent. Définissez qui reçoit le dossier, comment prendre contact, quels faits conserver et ce que l’agent de première ligne peut dire au client pendant l’examen.
Les incidents potentiels de confidentialité nécessitent une évaluation rapide. Lorsque le RGPD s’applique, les sous-traitants doivent notifier les responsables du traitement dans les meilleurs délais après avoir pris connaissance d’une violation de données personnelles, tandis que les responsables du traitement doivent documenter les faits pertinents, les effets et les mesures correctives. Une notification admissible à une autorité de contrôle est généralement requise dans les 72 heures suivant la prise de connaissance, lorsque cela est possible, sauf si la violation est peu susceptible d’engendrer un risque pour les droits et libertés des personnes.
La mission de l’équipe de support est le confinement et une transmission exacte, non la qualification juridique. Les responsables de la confidentialité et de la sécurité doivent évaluer l’événement au regard des obligations applicables et orienter les communications.
- Pièce jointe suspecte : transmettez immédiatement au contact chargé des incidents de sécurité ; ne l’ouvrez pas dans les outils standards.
- Possible prise de contrôle de compte, exposition d’identifiants ou usurpation d’identité : transmettez à la sécurité des comptes et suivez le processus approuvé de protection du client.
- Données personnelles sensibles envoyées accidentellement ou fichier mal adressé : transmettez au responsable de la confidentialité ou au contact de protection des données.
- Demande légale, demande de conservation ou contact des forces de l’ordre : transmettez aux responsables juridiques et de gestion des archives ; les agents ne doivent pas promettre une suppression ni divulguer eux-mêmes des fichiers.
- Message immédiat au client : confirmez que le fichier sera examiné selon le processus approprié, demandez-lui de ne pas envoyer davantage d’informations sensibles et proposez un moyen de contacter une personne.
Définissez les attentes en matière de conservation, suppression, accès et audit
Les pièces jointes ne doivent pas être conservées indéfiniment par commodité. Établissez un calendrier de conservation par type de dossier et finalité, puis définissez l’événement qui démarre le délai, la méthode approuvée de suppression ou de destruction, les exceptions telles que les obligations de conservation légale et la personne qui autorise les exceptions.
La limitation de la conservation prévue par le RGPD exige que les données personnelles identifiables ne soient pas conservées plus longtemps que nécessaire pour leur finalité. Les orientations PCI appellent également à des politiques de conservation et de destruction qui limitent le stockage aux besoins juridiques, réglementaires ou opérationnels, et qui suppriment de manière sécurisée ou rendent irrécupérables les données qui ne sont plus nécessaires.
L’accès doit suivre la tâche de support, et non la simple curiosité. Limitez l’accès aux fichiers aux personnes agissant selon des instructions organisationnelles documentées, examinez les accès périodiquement et conservez suffisamment d’informations d’audit pour enquêter sur les traitements inappropriés et démontrer que la politique a été respectée.
- Tenez un calendrier de conservation pour chaque catégorie de pièce jointe, y compris le délai de suppression courante et le responsable des exceptions.
- Documentez la manière dont la suppression est demandée, effectuée et confirmée dans la boîte de réception, le stockage et tout système aval approuvé.
- Appliquez un accès limité au nécessaire selon le service et le rôle ; retirez les accès lorsque les fonctions changent.
- Consignez les événements importants liés aux pièces jointes : envoi, transfert interne le cas échéant, escalade, demande de suppression, action de suppression et exception à la politique.
- Réalisez des revues régulières de l’efficacité des protections techniques et organisationnelles, conformément à votre programme de gouvernance.
Questions fréquentes
Que doit inclure une politique d’envoi de fichiers pour le support client ?
Incluez les finalités de support qui justifient les envois, les catégories de fichiers autorisées et interdites, les instructions aux clients, le comportement sûr des opérateurs, la vérification des contrôles techniques, les contacts d’escalade, les règles de conservation et de suppression, les alternatives d’accessibilité, la formation, les tests et les indicateurs.
Les équipes de support doivent-elles accepter des documents d’identité dans le chat ?
Uniquement si un processus de vérification précis et approuvé les exige réellement. Le chat de support ordinaire ne doit pas collecter des documents d’identité par défaut. Prévoyez une alternative conçue à cette fin ou un circuit d’escalade humain lorsqu’une vérification d’identité est nécessaire.
Les agents peuvent-ils faire confiance à une extension de fichier ou à une valeur Content-Type ?
Non. Une valeur Content-Type fournie par l’utilisateur peut être usurpée, et une extension seule ne prouve pas qu’un fichier est sûr. Les équipes techniques doivent utiliser des contrôles complémentaires et les opérateurs doivent transmettre les fichiers suspects plutôt que de les ouvrir.
Que doit faire un agent si un client envoie un mot de passe ou un code de sécurité de carte ?
Ne répétez pas, ne copiez pas et ne redemandez pas l’information. Arrêtez toute collecte supplémentaire, suivez le script de confinement approuvé et transmettez le cas au responsable de la sécurité des comptes, des paiements ou de la confidentialité, selon le cas. Donnez au client un circuit plus sûr pour sécuriser son compte ou accomplir la tâche.
webchat.vip fournit-il automatiquement une analyse antimalware ou des contrôles de conservation pour les pièces jointes ?
Ne le supposez pas. webchat.vip fournit une boîte de réception partagée pour les conversations WebChat et WhatsApp, et les fichiers sont stockés dans un sous-compte Apification Cloud isolé pour chaque service omnicanal. Votre équipe doit vérifier le comportement de l’analyse, de la conservation, de l’accès, de l’exportation et de la suppression pour la configuration déployée avant de s’appuyer sur un contrôle.
Comment l’automatisation peut-elle demander des fichiers en toute sécurité ?
Utilisez l’automatisation uniquement pour des demandes étroitement définies et examinées par des humains. Indiquez la finalité et le contenu minimal requis, collectez des réponses validées lorsque cela est approprié, orientez vers des alternatives textuelles plus sûres et prévoyez toujours un transfert vers une personne. N’automatisez pas une demande de contenu sensible que le processus en aval ne peut pas traiter en toute sécurité.
Sources et lectures complémentaires
Références primaires et reconnues utilisées pour vérifier la base factuelle de ce guide.
- File Upload Cheat Sheet — OWASP Foundation
- Input Validation Cheat Sheet — OWASP Foundation
- Web Content Accessibility Guidelines (WCAG) 2.2 — W3C
- Forms Tutorial — W3C Web Accessibility Initiative
- Regulation (EU) 2016/679 (GDPR) — EUR-Lex / European Union
- NIST Privacy Framework 1.1: Using the Framework — National Institute of Standards and Technology
- Security and Privacy Controls for Information Systems and Organizations — National Institute of Standards and Technology
- Computer Security Incident Handling Guide — National Institute of Standards and Technology
- Can card verification codes be stored for card-on-file or recurring transactions? — PCI Security Standards Council
- What is the maximum period of time that cardholder data can be stored? — PCI Security Standards Council