Segurança e dados de cartão
Receber pagamentos dentro do Salesforce levanta as perguntas que todo administrador e todo auditor fazem: para onde vão os números de cartão, o que é armazenado, quem pode ver o quê e o que nós mesmos precisamos fazer? Este artigo responde a elas para o REDA Pay 1.56 tal como ele é construído e lista as responsabilidades que continuam com você.
O que nunca é armazenado no Salesforce
| Dado | Tratamento |
|---|---|
| Número completo do cartão (PAN) | Nunca é gravado em nenhum registro do Salesforce. Depois do registro, só a bandeira, o tipo, o mês e o ano de validade, o nome do titular e o código postal do cartão são mantidos, e o nome do método mostra os quatro últimos dígitos |
| Código de segurança do cartão (CVV/CVC) | Nunca é armazenado |
| Número completo da conta bancária | Nunca é armazenado. O routing number, o tipo, a classe, a moeda, o nome do titular e os últimos dígitos (no nome) são mantidos |
O que é armazenado criptografado
O REDA Pay criptografa estes dados com uma chave que é gerada uma vez na sua organização e nunca é exibida; consulte Gerar a chave de criptografia:
- o token de API da Payload no Pay Profile;
- os identificadores da Payload para a sua organização (Profile Id), para cada conta de estabelecimento, para cada cliente e para cada método de pagamento salvo (o token que a Payload usa no lugar do cartão ou da conta);
- o identificador dentro de cada link de pagamento.
Quem consegue ler esses registros vê texto cifrado. O identificador de transação da Payload é armazenado em claro, porque é um número de referência usado em conversas com o suporte e não contém nenhum segredo.
Como os dados de cartão e de banco trafegam
Nas telas de pagamento e de salvar método, o pagador digita os dados do cartão ou do banco no formulário do REDA Pay. O REDA Pay os envia à Payload por uma conexão criptografada, a Payload devolve um token e o REDA Pay guarda o token e os dados descritivos listados acima. Os dados passam pela sua organização do Salesforce a caminho da Payload; eles não são gravados em um registro, em um log nem em um arquivo.
O que isso significa para você:
- Trate a sua organização do Salesforce como parte do ambiente que trata dados de cartão e mantenha-a segura: autenticação forte para todos os usuários, acesso com o mínimo de privilégios, nada de logs de depuração das telas de pagamento em produção.
- Converse com a Payload e com o seu avaliador sobre o que essa arquitetura significa para o seu escopo de PCI DSS e para o questionário que você preenche. O projeto do REDA Pay mantém os dados de cartão fora do seu banco de dados; ele não deixa você, por si só, "fora do escopo".
- Também é possível manter os pagadores totalmente longe da sua equipe usando links de pagamento e o portal, para que a equipe nunca veja nem digite números de cartão.
Sessões, links e convidados
| Mecanismo | O que protege |
|---|---|
| Sessão de pagamento criptografada | Cada tela de pagamento funciona a partir de um token criptografado criado quando ela abre, levando quem paga, qual perfil e qual conta. Ele expira depois da duração de sessão da conta (15 minutos por padrão), então um endereço copiado ou salvo nos favoritos não pode ser reutilizado depois |
| Identificador de link criptografado | Um link de pagamento leva o identificador da ordem criptografado; o endereço não revela nada sobre o valor ou o cliente |
| Acesso de convidados por regra | O usuário convidado do site público só pode ler uma Pay Order enquanto o Has Active Link for verdadeiro, e um Pay Customer só enquanto ele tiver um link ativo, por meio das regras de compartilhamento que você cria. Quando um link é pago, expira ou é revogado, os registros saem da visão do convidado |
| Métodos de convidado de uso único | Um cartão ou uma conta informados em um link são salvos com Keep Active desmarcado |
| Proteção contra duplicidade | Um segundo clique no botão de pagar na mesma sessão é recusado |
| Captura de geolocalização e de IP | Registro opcional, e exigência, de onde um pagamento foi feito; consulte Controles |
Atualizações de status vindas da Payload
A Payload informa eventos a um endereço público na sua organização. A mensagem é usada só para saber qual transação mudou; o REDA Pay então lê a transação na Payload pela API autenticada e guarda isso. Nada de uma mensagem recebida é gravado diretamente em um registro. Consulte Configurar webhooks.
Quem pode fazer o quê
O acesso é concedido por sete conjuntos de permissões, de somente leitura a administrador, e por duas chaves no registro de usuário para recebimentos e desembolsos; consulte Quem pode fazer o quê. Dentro da organização, a maioria dos objetos do REDA Pay é Public Read Only, então qualquer usuário licenciado com acesso ao objeto consegue ler os registros de pagamento; restrinja com as suas próprias configurações de compartilhamento, se a sua política exigir. O acompanhamento do histórico de campos está ativado para a maioria dos campos, o que dá uma trilha de auditoria das alterações.
A sua lista de verificação antes de entrar em produção
| Item | Por quê |
|---|---|
| ERROR_STACK_TRACE definido como FALSE | O detalhe técnico não deve chegar aos pagadores; consulte Chaves da organização |
| Conjuntos de permissões atribuídos por função, Enable Disbursements só onde for preciso | Mínimo de privilégios |
| Conjunto de compartilhamento do portal e regras de compartilhamento para convidados exatamente como documentado | Os clientes veem só os próprios registros; os convidados, só os links ativos |
Logotipo e rodapé servidos por https | Nada de conteúdo misto na página de pagamento |
| Autenticação multifator para a equipe que recebe pagamentos | Boa prática do Salesforce |
| Logs de depuração desativados para os usuários de pagamento em produção | Os logs podem capturar dados das solicitações |
| Um responsável nomeado pelo modo de exibição Attention Needed dos REDA Pay Logs | As falhas são vistas |
| Chaves de API da Payload guardadas só por meio do Update API Token, nunca em campos, documentos ou chats | A chave é a conta |
| Cartões de teste e o ambiente de teste da Payload usados nos sandboxes | Cartões reais nunca em teste |
Perguntas frequentes
O REDA Pay é um aplicativo que roda na sua organização do Salesforce; o processador de pagamentos é a Payload. Peça à Payload o atestado dela e pergunte ao seu avaliador como uma integração que faz os dados de cartão passarem pela sua organização afeta o seu próprio escopo. Este artigo diz exatamente o que o aplicativo faz, para que essa conversa seja bem informada.
Sim: o proprietário e o criador da Pay Order, o Processed User Type e, quando capturados, o IP Address, o Geo Latitude e o Geo Longitude.
Ela não pode ser exportada nem gerada de novo, e fica na sua organização. Os sandboxes têm a própria; a da produção fica com a produção.