Alguns clientes precisam de usuários de marketing para acessar registros de dados, mas não desejam que eles vejam informações de identificação pessoal (PII), como nome, sobrenome ou endereço de email. A Adobe Campaign propõe uma maneira de proteger a privacidade e evitar que os dados sejam utilizados incorretamente pelos operadores de campanha regulares.
Implementação
Um novo atributo que pode ser aplicado a qualquer elemento ou atributo foi adicionado aos esquemas, complementa o atributo existente visibleIf . Este atributo é: accessibleIf . Ao conter uma expressão XTK relacionada ao contexto do usuário atual, ela pode aproveitar HasNamedRight ou $(login) , por exemplo.
Você pode encontrar uma amostra de uma extensão de schema de recipient que mostra este uso abaixo:
visibleIf : oculta os campos dos metadados, portanto, eles não podem ser acessados em uma visualização de esquema, ou seleção de coluna, ou em um construtor de expressões. Mas isso não oculta dados. Se o nome do campo for inserido manualmente em uma expressão, o valor será exibido.
accessibleIf : oculta os dados (substituindo-os por valores vazios) da consulta resultante. Se visibleIf estiver vazio, ele obterá a mesma expressão que accessibleIf .
Estas são as consequências do uso desse atributo no Campaign:
Os dados não serão mostrados usando o editor de query genérico no console,
Os dados não estarão visíveis nas listas de visão geral e de registro (console).
Os dados se tornarão somente leitura na exibição detalhada.
Os dados só serão utilizáveis em filtros (o que significa que, usando algumas estratégias de dicotomia, você ainda pode adivinhar valores).
Qualquer expressão que é criada usando um campo restrito é restrita a: lower(@email) torna-se acessível como @email.
Em um workflow, é possível adicionar a coluna restrita ao público alvo como uma coluna extra da transição, mas ela ainda fica inacessível aos usuários do Adobe Campaign.
Ao armazenar a população direcionada em um grupo (lista), as características dos campos armazenados são as mesmas da fonte de dados.
Por padrão, os dados não são acessíveis ao código JS.
Recomendações
Em cada delivery, os endereços de email são copiados para o broadLog e forecastLog tabelas: consequentemente, esses campos também precisam ser protegidos.
Abaixo está uma amostra da extensão da tabela de log para implementar isso:
Esta restrição aplica-se a utilizadores não técnicos: um usuário técnico, com permissões relacionadas, poderá recuperar dados. Portanto, esse método não é 100% seguro.
