Como criar uma política segura de upload de ficheiros para conversas de apoio ao cliente
Um enquadramento prático para pedir apenas os ficheiros necessários aos clientes, lidar com anexos inesperados e encaminhar questões de segurança, privacidade e acessibilidade para as pessoas certas.
Um botão de upload não é uma política de upload de ficheiros
Capturas de ecrã, faturas, fotografias e documentos podem ajudar a resolver um caso, mas cada anexo também cria uma decisão operacional: o que é necessário, quem o pode ver, se é seguro abri-lo, durante quanto tempo é retido e o que acontece quando o cliente envia algo inadequado ou arriscado.
Uma política de upload de ficheiros para o apoio ao cliente transforma essas decisões em instruções repetíveis para clientes, operadores da linha da frente, supervisores, partes interessadas de privacidade e responsáveis pela resposta a incidentes de segurança. Deve aplicar-se de forma consistente aos canais de conversa utilizados pela sua equipa, reconhecendo simultaneamente que o comportamento dos canais e o tratamento interno podem diferir.
Utilize defesa em profundidade. A OWASP aconselha que nenhuma técnica isolada de validação é suficiente para ficheiros fornecidos por utilizadores. Por isso, uma política sólida combina minimização de dados, categorias permitidas restritas, controlos técnicos verificados pela sua organização, procedimentos para a equipa, limites de acesso e regras de escalonamento.
- Responsável pela política: indique o responsável pelas operações de apoio e os aprovadores de privacidade, segurança e gestão de registos.
- Âmbito: enumere cada canal de apoio, fila, departamento e tipo de caso abrangidos.
- Regra de decisão: peça um ficheiro apenas quando for necessário para resolver, verificar ou investigar o caso indicado.
- Encaminhamento humano: disponibilize a todos os clientes uma forma de continuar com uma pessoa se não puderem ou não deverem carregar um ficheiro.
Classifique a tarefa de apoio antes de pedir um anexo
O ficheiro mais seguro é aquele que nunca recolhe. Antes de um agente ou fluxo automatizado pedir um upload, classifique a evidência num de três grupos: obrigatória, útil ou proibida.
A evidência obrigatória é a informação sem a qual a equipa não pode razoavelmente executar uma ação de apoio específica. A evidência útil pode acelerar o diagnóstico, mas não é necessária; apresente-a como opcional e explique a alternativa. A informação proibida não deve ser pedida nem aceite através de um chat de apoio comum.
Esta abordagem apoia a limitação da finalidade e a minimização de dados. Quando o RGPD se aplica, os dados pessoais devem ser recolhidos para uma finalidade especificada e limitados ao necessário para essa finalidade.
- Obrigatória: uma captura de ecrã recortada de uma mensagem de erro apresentada, quando o texto não possa ser fornecido de outra forma.
- Útil: uma fotografia que mostre danos visíveis no envio, quando o cliente puder alternativamente descrever o estado e fornecer uma referência da encomenda.
- Não recolher: palavras-passe, códigos de utilização única, códigos de verificação de cartões de pagamento, PIN, dados completos da banda magnética, chaves privadas ou documentos de identificação não relacionados.
- Reveja cada pedido de upload recorrente: é possível tomar a mesma decisão com um número de encomenda, número de caso, descrição textual ou processo seguro concebido para esse fim?
Defina as categorias permitidas e escreva as instruções ao cliente antes do upload
Defina uma lista curta de elementos permitidos para cada tipo de caso, em vez de permitir por predefinição categorias de ficheiros abrangentes. A OWASP recomenda permitir apenas extensões essenciais para a atividade e escolher os tipos menos nocivos e de menor risco que satisfaçam a necessidade de negócio. Evite aceitar ficheiros comprimidos, salvo se houver um motivo documentado e os responsáveis técnicos tiverem aprovado um tratamento seguro; o tratamento de arquivos introduz riscos de tamanho descomprimido e extração.
Escreva o pedido de upload em linguagem simples antes de o cliente agir. A instrução deve identificar a finalidade de apoio, o conteúdo mínimo necessário, os formatos aceites e qualquer limite de tamanho relevante que tenha sido verificado para esse canal. Deve também indicar o que remover e o que não enviar.
As instruções acessíveis não são opcionais. As WCAG 2.2 exigem etiquetas ou instruções quando é necessária introdução de dados pelo utilizador, e os controlos de upload precisam de um nome textual que descreva a respetiva finalidade. Não se baseie apenas na cor, num ícone ou numa imagem.
- Finalidade: “Para verificar o problema de entrega, envie uma fotografia do exterior da encomenda e do artigo danificado.”
- Mínimo: “Oculte a sua morada, número de telefone, número de conta e qualquer informação que não seja necessária para mostrar o problema.”
- Formato: indique apenas formatos que a sua equipa tenha aprovado para essa tarefa, como uma captura de ecrã ou fotografia, quando adequado.
- Proibição: “Não envie palavras-passe, códigos de verificação, PIN de cartões, códigos de segurança de cartões ou dados completos de cartões de pagamento.”
- Alternativa: “Se não puder carregar um ficheiro, descreva o texto do erro, a data e hora e o que estava a tentar fazer. Um agente pode ajudar.”
Trate anexos inesperados e sensíveis sem pedir reenvios
Por vezes, os clientes enviam um ficheiro antes de este ser pedido, anexam o item errado ou incluem material sensível numa captura de ecrã. Os agentes não devem pedir que reenviem o mesmo conteúdo sensível pelo mesmo chat. A repetição aumenta a exposição sem resolver o problema subjacente de tratamento.
Crie um procedimento e encaminhamento simples de contenção. O agente deve confirmar o caso, interromper a recolha adicional de material sensível, documentar apenas os factos mínimos exigidos pelo procedimento interno e encaminhar o caso para a equipa designada de privacidade, pagamentos, segurança de contas ou segurança.
Os ambientes de pagamento exigem regras especialmente claras. Os códigos de verificação de cartões, PIN e dados completos da banda magnética são dados de autenticação sensíveis e não são apropriados para anexos em chats de apoio comuns. Se chegarem informações de pagamento, siga o procedimento aprovado pela organização para incidentes e eliminação de dados de pagamento, em vez de as copiar para notas, modelos ou outro chat.
- Credencial ou código de verificação enviado acidentalmente: diga ao cliente para não enviar mais informações, aconselhe-o a alterar ou proteger a credencial através do canal aprovado da conta e escale para a segurança de contas.
- Dados de pagamento: interrompa a discussão sobre os dados, não os repita e escale através do processo aprovado de pagamentos/privacidade.
- Documento de identificação ou informação de categoria especial que não seja necessária para o caso: confirme a receção sem repetir detalhes e escale para o responsável pela privacidade.
- Ficheiro errado ou não relacionado: peça uma alternativa mais segura ou a informação relevante mínima, não o reenvio do material original.
Dê aos operadores regras seguras para abrir, descrever e partilhar ficheiros
Os profissionais de apoio na linha da frente não devem tomar sozinhos decisões sobre malware ou privacidade. O NIST aconselha os utilizadores a não abrirem anexos suspeitos apenas porque conhecem o remetente. Um nome de cliente familiar, um tema de caso esperado ou um nome de ficheiro plausível não provam que o ficheiro é seguro.
Forme os operadores para inspecionarem apenas a informação necessária para o caso e apenas em ferramentas aprovadas. Não devem descarregar um ficheiro para um dispositivo pessoal, encaminhá-lo para e-mail pessoal, carregá-lo para um serviço não aprovado nem partilhá-lo num grupo interno alargado apenas para obter ajuda.
Um valor Content-Type ou MIME fornecido pelo cliente não é prova fiável do verdadeiro tipo de ficheiro. Os controlos técnicos podem utilizar listas de extensões permitidas, assinaturas de ficheiro esperadas, limites de tamanho e análise antimalware ou sandboxing quando disponíveis, mas a OWASP alerta que são salvaguardas complementares, não garantias autónomas.
- Abra normalmente apenas quando o ficheiro for esperado, relevante para o caso ativo, permitido pela política e acessível através de procedimentos de tratamento aprovados.
- Trate como suspeito quando o anexo for inesperado, irrelevante, parecer executável, for um arquivo fora da política, for invulgarmente grande, tiver um nome enganador ou vier acompanhado de pressão para o abrir com urgência.
- Para ficheiros suspeitos: não abra, pré-visualize, execute nem investigue em ferramentas comuns de desktop; preserve a referência do caso e escale para a segurança.
- Ao descrever internamente um ficheiro, registe os factos úteis mínimos: ID do caso, hora de receção, categoria aparente, motivo do escalonamento e ações tomadas. Não reproduza conteúdos sensíveis nas notas.
Verifique a fronteira entre canais, caixas de entrada e as suas próprias salvaguardas
Não escreva uma política que presuma que um canal de mensagens, widget de chat ou caixa de entrada fornece análise de malware, imposição do tipo de ficheiro, controlos de retenção, fluxos de eliminação ou controlos de acesso baseados em funções, a menos que essas capacidades tenham sido explicitamente verificadas para a configuração exata em utilização. A análise e o sandboxing são salvaguardas específicas da implementação, não pressupostos predefinidos.
A webchat.vip disponibiliza uma caixa de entrada partilhada para conversas no WebChat e WhatsApp. Os ficheiros são armazenados numa subconta isolada da Apification Cloud para cada serviço omnicanal. Estes factos descrevem a arquitetura do produto, mas não estabelecem, por si só, os controlos de análise, retenção, revisão de acessos ou resposta a incidentes exigidos pela sua organização.
Faça da verificação técnica um requisito formal de lançamento, sob responsabilidade das partes interessadas apropriadas de segurança, privacidade e plataforma. Registe a resposta, evidência, responsável, data de revisão e qualquer risco residual para cada controlo.
- Que formatos de ficheiro, tamanhos de ficheiro e tamanhos de pedido são efetivamente aceites em cada canal implementado?
- Um ficheiro é analisado, colocado em quarentena ou executado numa sandbox? Se sim, quem opera o controlo, qual é a sua cobertura e o que acontece perante uma deteção?
- Quem pode ver, descarregar, exportar, encaminhar e eliminar anexos de clientes na caixa de entrada configurada e nos sistemas ligados?
- Onde são armazenados os ficheiros, como são obtidos os registos de acesso e como funciona, na prática, a aplicação da eliminação ou retenção?
- A equipa consegue impedir nomes de ficheiros ou caminhos controlados pelo utilizador e os ficheiros são separados do conteúdo servido na web, quando relevante?
- Que processo se aplica se um cliente pedir acesso, eliminação, retificação ou informação sobre um ficheiro carregado?
Utilize escalonamento baseado no risco, com um responsável humano identificado
Todas as políticas precisam de uma via de escalonamento que funcione fora do horário de expediente e não dependa de um agente adivinhar a gravidade. Defina quem recebe o caso, como efetuar o contacto, que factos preservar e o que o agente da linha da frente pode dizer ao cliente enquanto a análise está em curso.
Os potenciais incidentes de privacidade exigem avaliação rápida. Quando o RGPD se aplica, os subcontratantes devem notificar os responsáveis pelo tratamento sem demora injustificada após tomarem conhecimento de uma violação de dados pessoais, enquanto os responsáveis pelo tratamento devem documentar os factos relevantes, efeitos e medidas corretivas. Uma notificação aplicável à autoridade de controlo é geralmente exigida no prazo de 72 horas após o conhecimento, quando possível, salvo se for improvável que a violação crie risco para os direitos e liberdades das pessoas.
A função da equipa de apoio é conter e encaminhar com precisão, não fazer uma classificação jurídica. Os responsáveis pela privacidade e segurança devem avaliar o evento face às obrigações aplicáveis e orientar as comunicações.
- Anexo suspeito: encaminhe imediatamente para o contacto de incidentes de segurança; não o abra em ferramentas padrão.
- Possível tomada de controlo da conta, exposição de credenciais ou falsificação de identidade: encaminhe para a segurança de contas e siga o processo aprovado de proteção do cliente.
- Dados pessoais sensíveis enviados acidentalmente ou ficheiro enviado para o destinatário errado: encaminhe para o responsável pela privacidade ou contacto de proteção de dados.
- Exigência legal, pedido de preservação ou contacto das autoridades policiais: encaminhe para os responsáveis jurídicos e de gestão de registos; os agentes não devem prometer eliminação nem divulgar ficheiros por iniciativa própria.
- Mensagem imediata ao cliente: confirme que o ficheiro será analisado através do processo adequado, peça que não envie mais informação sensível e ofereça uma via de contacto humano.
Defina expectativas de retenção, eliminação, acesso e auditoria
Os anexos não devem ser guardados indefinidamente por conveniência. Defina um calendário de retenção por tipo de caso e finalidade e estabeleça depois o evento que inicia a contagem, o método aprovado de eliminação ou destruição, as exceções como retenções legais e quem autoriza as exceções.
A limitação de conservação prevista no RGPD exige que os dados pessoais identificáveis sejam retidos apenas durante o tempo necessário para a sua finalidade. As orientações PCI também exigem políticas de retenção e eliminação que limitem o armazenamento às necessidades legais, regulamentares ou de negócio e eliminem de forma segura ou tornem irrecuperáveis os dados que já não são necessários.
O acesso deve seguir a tarefa de apoio, e não a curiosidade geral. Limite o acesso aos ficheiros a pessoas que atuem segundo instruções organizacionais documentadas, reveja os acessos periodicamente e retenha informação de auditoria suficiente para investigar tratamento inadequado e demonstrar que a política foi cumprida.
- Mantenha um calendário de retenção para cada categoria de anexo, incluindo o momento de eliminação de rotina e o responsável pelas exceções.
- Documente como a eliminação é solicitada, executada e confirmada na caixa de entrada, armazenamento e em qualquer sistema posterior aprovado.
- Aplique acesso mínimo necessário por departamento e função; remova o acesso quando as responsabilidades mudarem.
- Registe eventos significativos de anexos: upload, transferência interna quando aplicável, escalonamento, pedido de eliminação, ação de eliminação e exceção à política.
- Efetue avaliações regulares da eficácia das salvaguardas técnicas e organizacionais, conforme exigido pelo seu programa de governação.
Perguntas frequentes
O que deve incluir uma política de upload de ficheiros para o apoio ao cliente?
Inclua as finalidades de apoio que justificam uploads, categorias de ficheiros permitidas e proibidas, instruções ao cliente, comportamento seguro do operador, verificação de controlos técnicos, contactos de escalonamento, regras de retenção e eliminação, alternativas de acessibilidade, formação, testes e métricas.
As equipas de apoio devem aceitar documentos de identificação no chat?
Apenas se um processo de verificação específico e aprovado realmente os exigir. Um chat de apoio comum não deve recolher documentos de identificação por predefinição. Disponibilize uma alternativa concebida para essa finalidade ou uma via de escalonamento humano quando for necessária verificação de identidade.
Os agentes podem confiar numa extensão de ficheiro ou num valor Content-Type?
Não. Um Content-Type fornecido pelo utilizador pode ser falsificado, e uma extensão, por si só, não prova que um ficheiro é seguro. As equipas técnicas devem utilizar controlos complementares e os operadores devem escalar ficheiros suspeitos em vez de os abrir.
O que deve fazer um agente se um cliente enviar uma palavra-passe ou código de segurança do cartão?
Não repita, copie nem peça novamente a informação. Interrompa a recolha adicional, siga o procedimento de contenção aprovado e escale para o responsável pela segurança de contas, pagamentos ou privacidade, conforme aplicável. Dê ao cliente uma via mais segura para proteger a conta ou concluir a tarefa.
A webchat.vip disponibiliza automaticamente análise de malware ou controlos de retenção para anexos?
Não presuma que sim. A webchat.vip disponibiliza uma caixa de entrada partilhada para conversas no WebChat e WhatsApp, e os ficheiros são armazenados numa subconta isolada da Apification Cloud para cada serviço omnicanal. A sua equipa deve verificar o comportamento de análise, retenção, acesso, exportação e eliminação na configuração implementada antes de depender de qualquer controlo.
Como pode a automação pedir ficheiros de forma segura?
Utilize a automação apenas para pedidos estritamente definidos e revistos por humanos. Indique a finalidade e o conteúdo mínimo necessário, recolha respostas validadas quando adequado, encaminhe para alternativas mais seguras em texto e disponibilize sempre transferência ou encaminhamento para uma pessoa. Não automatize um pedido de material sensível que o processo posterior não consiga tratar de forma segura.
Fontes e leituras adicionais
Referências primárias e autorizadas usadas para verificar a base factual deste guia.
- 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