# Evidências PCI - 2021

## Sistema: Card Manager
As evidências levantadas neste documento pertencem ao sistema de Card Manager.

# Arquitetura do sistema Card Manager:


### 1 - Inventário de dados de cartão (evidenciar quais dados estão armazenados, por qual justificativa e de que forma).

#### Tipo de local de armazenamento:
- Banco de dados RDS local Físico (Revisitar esta informação)

#### Tipo de tecnologia / serviço:
- Para persistência: Baseada no framework Hibernate em banco de dados postgre e mongodb.
- Para armazenamento: Levantar essa informação com a equipe de banco de dados.

#### Tempo de armazenamento:
- Indefinido

- **Número do Cartão(PAN)**
- **Processo de negócio:** Cadastro / Lógica
- **Justificativa:** dado usado na lógica de negócio:

        fun isIssued() = this.partnerCardId != null &&
        !this.pan.isNullOrEmpty() && 
        this.expirationDate != null

Ele verifica se o cartão já está emitido, pela composição id do cartão, data de expiração e o próprio pan, porem o dado (PAN) é retornado pelo parceiro de forma truncada não sendo nunca persistido o número real do cartão.

- **Data de Validade do Cartão**
- **Processo de negócio:** Cadastro / Lógica
- **Justificativa:** Dado usado na lógica de negócio:

        fun isIssued() = this.partnerCardId != null &&
        !this.pan.isNullOrEmpty() &&
        this.expirationDate != null

Verifica se o cartão já está emitido onde compõem com o id do cartão mais o pan do cartão.

- **Nome Impresso:**
- **Processo de negócio:** Cadastro / Lógica
- **Justificativa:** Double check com o parceiro.

- **Senha**
- **Processo de negócio:** Cadastro / Lógica
- **Justificativa:** O processo de solicitação do cartão é assíncrono e tem como um dos critérios de aceite que seja informada a senha de quatro dígitos, que se não for informada, será gerada randomicamente pela aplicação e armazenada temporariamente criptografada em banco de dados que após a confirmação do cartão ser criado e posterior ativação é inutilizada.

- **Número do cartão (PAN)**
- Processo de negócio: Transacional / Lógica
Justificativa: Dado enviado para identificar o cartão associado ao número de seu pan e que tem a característica de no lugar da parte truncada com asteriscos na forma tradicional estar embutido em seu lugar o id do cartão do lado do parceiro para atender sua regra de negócio identificando assim a transação associada ao cartão.

### Evidencias:



- Query:

    select * from card where external_key = '5e67b462-3c7f-4d40-8232-6366f4ef466d';

- Base de Dados:
zoop-prd-banking.db.zoop.tech / schema: card_manager

### Descrição de campos da tabela usada no armazenamento - card:

| Campo | Descrição |
| -------- | -------- |
| card | Tabela que armazena cartões credito/debito associados a contas digitais|
| id | Chave primária artificial|
| external_key| Define a identificação do cartão no sistema externo utilizado pela criação do cartão|
| printed_card_name | Nome a ser impresso no cartão|
| card_holder_id| Portador do cartão|
| delivery| Dados sobre entrega do cartão|
| source_id| Cartão origem desta segunda via de cartão|
| status | Define o estado atual do cartão|
| partner_card_id |Define o id do cartão|
| pan | Define o pan do cartão. PAN é um acrônimo de primary account number e basicamente é uma truncagem do número do cartão para limitar fraudes|
| expiration_date |Define a data de vencimento do cartão|
| issuer |Define o emissor do cartão|
| created_at |Define o momento de criação do cartão|
| updated_at | Define o momento da última alteração de qualquer informação do cartão|
| version | Versão usada pela estratégia de persistencia do Hibernate|
| embossing_policy_id|Define a politica de embossamento usada no cartão em questão|
|card_type | Define o tipo do cartão se e fisico(PHYSICAL) ou virtual(VIRTUAL)|

___
**Base de dados:** banking-cardmanager-mongodb-0.zoop.tech
**Query:**

db.transaction.find({})
    .projection({})
    .sort({"createdAt": -1 })
    .limit(100)*

### 2 - Processos e documentações evidenciando o não armazenamento dos dados de autenticação confidencias após a autorização.

#### Tipo de local de armazenamento:
- PostgresSQL

#### Tipo de tecnologia / serviço:
- Para persistência: Baseada no framework Hibernate em banco de dados postgre e mongodb.
- Para armazenamento: Levantar essa informação com a equipe de banco de dados.

#### Tempo de armazenamento:
- Indefinido

#### Processo:

- Processos e documentações evidenciando o não armazenamento dos dados completos de rastreamentos (Tarja magnética), após a autorização.
- Não armazenamos a tarja magnética, pois não trabalhamos com o produto de cartão físico.

- Processo ou documentação evidenciando o não armazenamento do código, ou valor de verificação do cartão.
- O CVV em momento algum é armazenado no sistema, ele apenas trafega pela aplicação.

- Processo ou documentação evidenciando o não armazenamento do número de identificação pessoal (PIN).
Não armazenamos o PIN do cartão no processo de armazenamento de BD conforme evidencia abaixo:

O PIN no momento de criação do cartão é armazenado de forma criptografada na tabela CardRequest com o valor gerado, após alterado pelo cliente, as informações do cartão vão para a tabela Card e o PIN deixa de ser persistido.

Evidência de que a tabela de card não possui um campo para armazenar CVV e PIN


### 3 - Processos para realizar o mascaramento dos dados de cartão em tela.

#### Tipo de local de armazenamento:
- LOG de Sistema
(Datadog)

#### Tipo de tecnologia / serviço:
- Apache LOG

#### Tempo de armazenamento:
- 3 dias

#### Processo:
- Lógica de Sistema

#### Data class que recebe as informações

- **Justificativa**:
A lógica implementada visa a retirada de dados sensíveis relacionados ao cartão na exibição de logs do sistema. Observação: Os logs são necessários para realizar atendimentos/sustentação aos marktplaces.

### Evidencias:

| Data Class Nome | Dados | Dados retirados da exibição dos logs|
|-----------------|-------|-------------------------------------|
| MailingAddressTO | `postalCode`, `street`, `number`, `complement`, `reference Point`, `neighborhood`, `city`, `state`, `country`.|`number`, `complement`, `reference Point`.|
Phone |`area`, `number`, `type`, `countryCode`.| `area`, `number`, `countryCode`.
| CardTO | `externalKey`, `accountId`, `holderId`, `marketplaceId`, `pan`, `expirationDate`, `status`, `createdAt`, `updatedAt`.|`externalKey`, `accountId`, `holderId`, `marketplaceId`, `expirationDate`, `createdAt`, `updatedAt`.
|VisualizationVirtualCardTO |`externalKey`, `accountId`, `holderId`, `marketplaceId`, `pan`, `status`, `createdAt`, `updatedAt`, `uri`, `resource`, `reason`, `embossingPolicyId`, `cardType`, `expirationDate`, `cvv`, `cardNumber`, `plasticName`.| `reason`, `embossingPolicyId`, `expirationDate`, `cvv`, `cardNumber`, `plasticName`.
| CardRequestTO |`accountId`, `mailingAddress`, `phone`, `printedCardName`, `password`, `embossingPolicyId`, `cardType`. | `phone`, `password`, `embossingPolicyId`, `cardType`.
| ConductorIndividualRequest | `name`, `motherName`, `birthDate`, `document`, `printedName`, `branchNumber`, `accountNumber`, `e-mail`, `idBusinessSource`, `idProduct`, `dueDate`, `isPep`, `address`, `phone`, `termsAndConditionsTokens`, `deviceIdentification`.| `motherName`, `birthDate`, `document`, `printedName`, `branchNumber`, `accountNumber`, `e-mail`, `idBusinessSource`, `idProduct`, `dueDate`, `isPep`, `address`, `phone`, `termsAndConditionsTokens`, `deviceIdentification`.
| ConductorCompany |`idCompany`, `idAccount`, `nationalRegistration`,`legalName`, `legalStatus`, `tradeName`, `dateEstablishment`,`legalNature`, `establishmentFormat`, `e-mail`, `revenue`, `partnerChanged`, `mainCnae`, `mainAddress`,`mainPhone`, `partners`.|`idCompany`, `idAccount`, `nationalRegistration`, `legalStatus`, `tradeName`, `dateEstablishment`, `legalNature`,`establishmentFormat`, `e-mail`, `revenue`, `partnerChanged`, `mainCnae`, `mainAddress`, `mainPhone`, `partners`.

- **Lógica aplicada para ofuscar os dados:**

**Exemplo:**

override fun toString(): String = "CardTO(externalKey=$externalKey, accountId=$accountId, holderId=$holderId,
marketplaceId=$marketplaceId, pan=$pan, expirationDate=$expirationDate, status='$status',
createdAt=$createdAt, updatedAt=$updatedAt, uri='$uri', resource='$resource', cardType='$cardType')"

**LOGS**

{
   "id":"6788bacc45e147568ef501fabbf511d8",
   "name":"Alexander Ribeiro",
   "mothers_name":"mama mia",
   "birthday":"1986-11-07",
   "cpf":"46436158421",
   "address":{
      "line1":"5643 H St NW",
      "line2":"543",
      "neighborhood":"Jacarepagua",
      "city":"Washington",
      "state":"DC",
      "postal_code":"22745270",
      "country_code":"US"
   },
   "phone":"21999885643",
   "cnpj":"97993527000104",
   "corporate_name":"Wisozk, Corwin and O'Hara",
   "customer":"6788bacc45e147568ef501fabbf511d8",
   "email":"[e-mail]",
   "status":"enabled",
   "marketplace_id":"ceaeaa4a-f6d6-4d2d-a22a-da2944ceead6",
   "metadata":{
      
   },
   "created_at":"2020-01-06T22:48:49.365111",
   "updated_at":"2020-01-06T22:48:49.967931",
   "delinquent":false,
   "data_validation":"valid",
   "accounts":[
    {
         "id":"2fa8fc6c923549d3915969fb937dfc1f",
         "holder":"6788bacc45e147568ef501fabbf511d8",
         "holder_name":"Alexander Ribeiro",
         "holder_corporate_name":"Wisozk, Corwin and O'Hara",
         "holder_cpf":"46436158421",
         "holder_cnpj":"87127420175507",
         "balance":49800000,
         "blocked_balance":0,
         "currency":"BRL",
         "routing_number":"001",
         "number":"948517500",
         "status":"active",
         "metadata":{
            
         },
         "created_at":"2020-01-06T18:40:17.372961",
         "updated_at":"2020-01-06T19:20:53.576999",
         "primary":true,
         "receiving_policy":{
            "payout_interval":"NONE",
            "minimum_amount":"0.00"
         },
         "uri":"/v2/marketplaces/ceaeaa4a-f6d6-4d2d-a22a-da2944ceead6/accounts/b78c7e7780f34c92b449730bef106733",
         "resource":"payment_account"
      },
      {
         "id":"26a87737ee3941b1a1ea0dd096def7b5",
         "holder":"6788bacc45e147568ef501fabbf511d8",
         "holder_name":"Alexander Ribeiro",
         "holder_corporate_name":"Umbrella Corp",
         "holder_cpf":"46436158421",
         "holder_cnpj":"87127420175507",
         "balance":49800000,
         "blocked_balance":0,
         "currency":"BRL",
         "routing_number":"001",
         "number":"948517500",
         "status":"active",
         "metadata":{
            
         },
         "created_at":"2020-01-06T18:40:17.372961",
         "updated_at":"2020-01-06T19:20:53.576999",
         "primary":true,
         "receiving_policy":{
            "payout_interval":"NONE",
            "minimum_amount":"0.00"
         },
         "uri":"/v2/marketplaces/ceaeaa4a-f6d6-4d2d-a22a-da2944ceead6/accounts/b78c7e7780f34c92b449730bef106733",
         "resource":"payment_account"
      }
   ],
   "uri":"/v2/marketplaces/ceaeaa4a-f6d6-4d2d-a22a-da2944ceead6/holders/6788bacc45e147568ef501fabbf511d8",
   "resource":"payment_account.holder"
}

Submitting webhook event 
{
   "object":{
      "external_key":"a42e1c85561647e990fa0cfd97f6693f",
      "account_id":"2fa8fc6c923549d3915969fb937dfc1f",
      "holder_id":"6788bacc45e147568ef501fabbf511d8",
      "marketplace_id":"ceaeaa4af6d64d2da22ada2944ceead6",
      "pan":"4261********7917",
      "expiration_date":"2026-12-31",
      "status":"PENDING",
      "created_at":"2021-09-17T10:22:00.081438",
      "updated_at":"2021-09-17T10:22:01.298218",
      "uri":"/marketplaces/ceaeaa4a-f6d6-4d2d-a22a-da2944ceead6/holders/6788bacc-45e1-4756-8ef5-01fabbf511d8/cards/a42e1c85-5616-47e9-90fa-0cfd97f6693f",
      "embossing_policy_id":"b627b5a2470248de8be8e4715f603de4",
      "card_type":"PHYSICAL"
   },
   "type":"pre_paid_card.updated",
   "resource":"pre_paid_card",
   "description":"A pre_paid_card was updated"
}


### 4 - Evidenciar implementações de processos seguros de armazenamento em locais onde os dados de cartão são armazenados. Ex. Criptografia, HASH, tokenização, truncamento.

Os dados são acessados pela política de acessos as bases de dados da empresa Zoop documentadas e aprovadas por formulário submetidos a aprovação dos gestores responsáveis.
Dos dados do cartão considerados sensíveis armazenados na base de Card Manager apenas o PAN é salvo no formato truncado (Tabela card) e a senha salva no formato criptografado (Tabela CardRequest) como já explicado no item 1 - Inventário de dados de cartão.

Evidências de truncamento:


**Query:**

select * 
from card 
where external_key = '5e67b462-3c7f-4d40-8232-6366f4ef466d';

**Base de dados:** zoop-prd-banking.db.zoop.tech / schema: card_manager

Evidências de criptografia:


**Query:**

select * 
from card_request 
where request_id = '8668f0cbf36005db';

**Base de dados:** zoop-prd-banking.db.zoop.tech / schema: card_manager

Observação: O arquivo é criptografado (ansible vault), mas a chave de criptografia não tem armazenamento seguro.

- Processo de criptografia de disco (Caso Aplicável).
Não há

### 5 - Processo/Política de gestão de chaves criptográficas.

As descrições abaixo referem-se a forma genérica de implementação das chaves criptografadas da empresa zoop.

Informações sobre a implementação específica verificar junto a equipe **SRE**.

- **Processo/Política de gestão de chaves criptográficas contendo a descrição da arquitetura da chave criptográfica.**

- **Gerenciamento de Chaves**
Chaves de criptografia de dados e chaves de criptografia de chaves (chaves que são utilizadas para criptografar as chaves de criptografia de dados) devem ser geradas, acessadas, distribuídas e armazenadas de forma segura e controlada.

- **Geração de Chaves**
Somente chaves de criptografia forte podem ser utilizadas. A criação de chaves criptográficas deve utilizar um algoritmo aleatório ou pseudo-aleatório para geração de números. Dependendo do esquema de criptografia em questão, seguem abaixo as exigências mínimas de comprimento das chaves de criptografia:

- AES (128 bits ou mais)
- RSA (2048 bits ou mais)
- Melhores práticas da indústria para outras metodologias de criptografia testadas e aceitas como NIST Special Publication 800-57 (http://csrc.nist.gov/publications).

A geração de chaves criptográficas deve ser feita pelo menos por dois responsáveis autorizados pela equipe de segurança da informação. Cada custodiante irá gerar uma parte aleatória de texto claro (componente da chave) que será utilizada para criar a chave criptográfica.
Para evitar a substituição não autorizada das chaves, o acesso físico e lógico aos procedimentos de geração de procedimentos e mecanismos deve ser protegido.

- **Configurações de restrição de acesso às chaves criptográficas.**
- **Acesso às Chaves**
Chaves criptográficas devem ser protegidas contra acesso geral. Somente os responsáveis autorizados devem ter acesso a componentes das chaves.

O acesso à chave de criptografia será concedido somente aqueles que necessitarem especificamente de ter acesso em decorrência de sua função.

O acesso só pode ser concedido pelo responsável por segurança da informação e a chave de acesso deve ser descrita no respectivo Formulário de Solicitação de Autorização.

Adicionalmente, estes usuários devem assinar o Termo de Responsabilidade pela Chave de Criptografia confirmando seu entendimento das obrigações de responsável pela chave. Estes formulários serão mantidos pelo departamento de recursos humanos no arquivo do funcionário.

- **Distribuição de Chves**
Apenas responsáveis autorizados pelo responsável pela área de segurança da informação estão autorizados a resgatar componentes da chave de locais de armazenamento seguros ou distribuir chaves.

Os responsáveis devem documentar todas as ações no Registro de Gerenciamento de Chaves de Criptografia. As chaves criptografadas jamais devem ser distribuídas em plain text.

- **Processo/Configuração de armazenamento das chaves privadas e secretas usadas para criptografar/descodificar os dados do titular do cartão.**

- **Armazenamento**
Todas as chaves de criptografia de dados devem ser armazenadas criptografadas em local seguro e no menor número possível de locais e formatos. As chaves de criptografia de chaves devem ser armazenadas separadamente das chaves de criptografia de dados. Em outras palavras, apesar de haver aplicações que necessitem de acesso a ambas as chaves, um nível apropriado de controle deve ser implementado de modo que um usuário não tenha acesso a ambas as chaves.

Backups de texto claro dos componentes de chaves criptográficas devem ser armazenados separadamente, de uma maneira que indique qualquer sinal de violação e em local seguro.

- **Configurações de restrição de acesso às chaves criptográficas.**

O Arquivo é criptografado (ansible vault), mas a chave de criptografia não tem o armazenamento seguro.*

- **Locais de armazenamentos das chaves criptográficas.**
- AWS Secrets Manager > Secrets:
Caminho para acessar as chaves salvas no ambiente da aws banking-card-manager-ENV:
Nome de secret manager / Prod ou Staging

### 6 - Política de Gestão de Chaves Criptográficas.

- **Política de Gestão de Chaves Criptográficas contendo o processo de geração de chaves criptográficas fortes.**

- **Processo de negócio:** Gestão / Segurança
- **Justificativa:** Banco de dados → Chave criptográfica do banco de dados são geradas e armazenadas em ambiente de nuvem (AWS), mas sem rotacionamento: Equipe de DBA's e SI.
Aplicação → Chave criptográfica gerada para cada aplicação individual.

- **Política de Gestão de Chaves Criptográficas contendo o processo de distribuição segura das chaves criptográficas.**

- **Processo de negócio:** Gestão / Segurança
- **Justificativa:** Política interna na responsabilidade do time de Cloud Engineer e SI em ambiente de nuvem (AWS) liberadas mediante conexão das aplicações.

- **Armazenamento das chaves criptográficas de modo seguro.**
- **Processo de negócio:** Gestão / Segurança
- **Justificativa:** Responsabilidade exclusiva do time de Cloud Engineer e SI em ambiente de nuvem (AWS).

**AWS Secrets Manager > Secrets:**
- Caminho para acessar as chaves salvas no ambiente da aws
banking-card-manager-ENV:

- Nome de secret manager / Prod ou Staging
O Arquivo é criptografado (ansible vault), mas a chave de criptografia não tem o armazenamento seguro.*

- **Exemplos:**

- https://github.com/getzoop/banking-card-manager/blob/master/deployment/inventory/group_vars/tag_environment_production.yml

- https://docs.ansible.com/ansible/latest/user_guide/vault.html

- **Configuração de criptoperiodo das chaves criptográficas.**
- Não há

- **Processo de Inutilização ou substituição das chaves criptográficas (por exemplo, arquivamento, destruição e/ou revogação).**
- Não há

- **Processo de gerenciamento manual de chaves criptográficas (Se aplicável).**
- Não há

- **Processo de prevenção contra a substituição não autorizada das chaves criptográficas.**

- **Processo de negócio:** Gestão / Segurança
- **Justificativa:** Política interna na responsabilidade do time de Cloud Engineer e SI em ambiente de nuvem (AWS) liberadas mediante conexão das aplicações.

- **Formulário onde os responsáveis pela proteção das chaves criptográficas declarem que eles compreendem e aceitam suas responsabilidades pela proteção das chaves.**
- Não há

### 7 - Política de Retenção e Descarte de Dados de Cartão

Na base de dados do CardManager conforme informado acima os dados considerados sensíveis tem um período indefinido de armazenamento e não existe uma política de descarte de dados.

### 8 - Evidenciar método de transmissão dos dados de cartão criptografado por redes públicas ou abertas/Evidenciar qual o algoritmo utilizado para criptografar os dados de cartão via redes públicas.

- **Evidenciar criptografia robusta na autenticação e transmissão das redes sem fio que estejam transmitindo dados do titular do cartão ou estejam conectadas ao ambiente de dados do titular do cartão.**

---
*Observação Importante:
As informações detalhadas neste tópico atendem ao que é solicitado no tópico 10 deste mesmo documento.*

---

Não transmitimos dados criptografados mas, submetemos o envio dos dados mediante acesso baseado em criptografia conforme informações abaixo.

### **Para cartões do tipo virtual**

- **O que é o API-Gateway-V3**
O API-Gateway-V3 é o responsável por validar a chave api-key (ZPK) que é enviada ao cliente (marketplace) no ato do seu cadastro na Zoop, o mesmo responsável por fazer a chamada ao método de multi fator de autenticação 2FA.

#### API-Gateway-V3


- **O que é o Zoop-2FA**

A solução Zoop-2FA é uma API que provê um sistema de autenticação de múltiplos fatores que pode ser utilizado em apps (IOS, Android) ou sistemas para aumentar o nível de segurança, seja para acesso/login ou a execução de determinadas tarefas/operações, fazendo uma autenticação cruzada por token por email previamente cadastrado ou SMS para um telefone celular também previamente cadastrado.

## **Utilização:**
Para poder utilizar o 2FA o acesso deve ser requerido junto a Zoop em [e-mail].
Serão previamente cadastrados na API o nome da sua empresa(Company) e o nome da(s) sua(s) aplicação(ões), e informações como as mensagens a serem enviadas por SMS e/ou email.
Serão enviados dois pares de credenciais:
- Sandbox(desenvolvimento e testes)
- Produção

Cada par é composto por duas chaves:
- CompanyToken
- SecretKey

A utilização de um desses pares lhe dará acesso ao respectivo ambiente e chamadas da API após o login. Um par de chaves é como isso:
`CompanyToken=75WmEprYx8kS3XDnkyOlVOqjBLZ693GvGGhkG1TUjrKcFlNPNC`
`CompanySecretKey=klu3UWMcR89Kl9mcixyzyNzA89ZD8UL5ZoCnDg0hbRqcNSrs9c`

**Fase 1 - Registro do dispositivo (E-mail ou telefone celular)**

Realizar o login;
A application (sistema cliente) precisa fazer o login no Zoop-2FA para poder iniciar a sequência de chamadas do 2FA;
Cadastro de usuário email/telefone;
Primeira solicitação de envio para email ou telefone, em uma application da company, é necessário fazer o registro deste "dispositivo". Para isso, ao receber a solicitação, o Zoop-2FA envia um código para o dispositivo para ser validado.
Validação/confirmação do email e/ou telefone do usuário;

O código enviado no item 2 precisa ser validado para efetivar o registro do dispositivo (email ou telefone celular).

**Fase 2 - Autenticação 2FA no dia-a-dia**
Criação de sessão de usuário email e/ou telefone;

Quando a application solicitar o envio de um código do 2FA para um dispositivo, solicita a criação da sessão;

Envio de sms ou email com token para usuário;

O Zoop-2FA envia para o dispositivo um código (código 2FA) gerado por ele.

Confirmação "código 2FA" pelo usuário no app ou sistema cliente;

A application precisa solicitar ao usuário que informe este "código 2FA" que o usuário recebeu no dispositivo solicitado e enviar para o Zoop-2FA;

Verificação do sistema cliente da validade do token;

O Zoop-2FA valida este "código 2FA" recebido, retornando se é um código válido para o dispostivo ou não.

### Chamadas da API

Em todas as chamadas deve ser passado no header a chave **`“x-api-key”`** em caixa baixa.

**Realizar login no Zoop-2FA**

Faz o login por companhia. Enviando o CompanyToken e a SecretKey fornecidos pela Zoop após o cadastro. Retornando o **X-Auth-Token** e o **X-Auth-Token-Reading**.
Todas as outras chamadas precisam receber um X-Auth-Token válido e a chamada */api/user/session/validate* precisa receber um **X-Auth-Token-Reading** válido.

**ACTION**
`POST`

**PATH**
`/api/company/login `

**HEADER**
`KEY: x-api-key`
`VALUE: My X-Api-Key`

**BODY**

 { 
 "CompanyToken": "My Company Token ",
 "SecretKey": "P@ssword!"
 }

Caso CompanyToken e SecretKey estejam corretos retorna o Status `200`, o **X-Auth-Token** e o **X-Auth-Token-Reading**, além da data e hora de expiração dos tokens em Token-Expiration conforme está abaixo. O X-Auth-Token deve ser passado no cabeçalho em todas as chamadas da API exceto em /api/user/session/validate – GET onde deve ser usado o X-Auth-Token-Reading. Não sendo válido retorna um erro Status 4XX, exemplos 400,401,412.

**RESPONSE**

{
"X-Auth-Token": "My X-Auth-Token",
"X-Auth-Token-Reading": "Partner X-Auth-Token-Reading",
"Token-Expiration": "2020-02-12T02:53:58.781091Z"
}

### **Para Cartões do tipo physical**


#### API Gateway V2


#### O que é o API-Gateway-V2
Para a API Gateway V2 é criada um API-key de nome ZPK e enviada ao marketplace para ter acesso à rota disponibilizada nesta aplicação.
O zoop-heidall-autorizer tem o papel de verificar se a API-key passada confere para o marketplace que está tentando acessar a aplicação e se o recurso solicitado pode ser acessado.

Após a autenticação pelo API-key ou API-key mais 2FA o cliente acessa os endpoints da aplicação Card Manager onde os dados do cartão são trafegados entre o parceiro Dock Systems e Zoop também protegidos nesta situação por tokens salvos em cloud:

- **AWS Secrets Manager > Secrets**
- Caminho para acessar as chaves salvas no ambiente da AWS
- **banking-card-manager-ENV:**
- Nome de secrect manager / Prod ou Staging

### 9 - Evidencia de processos que demandam o envio de dados de cartão através de mensagens de usuário final (Chat, SMS, WhatsApp etc.).

O CardManager não recebe nem envia dados de cartão pelos meios a seguir: Chat, SMS, WhatsApp.
O único tráfego de dados de cartão está no processo descrito no ponto: evidenciar o método de transmissão dos dados de cartão criptografado por redes públicas ou abertas.
Contudo, para acessar a API de cartão virtual é necessária a autenticação multi-fator onde existe interação com o usuário da aplicação pelo sistema 2FA que usa envio de confirmação por SMS / Email conforme abaixo:

**Registrar um email e um telefone celular para um usuário**
- Insere os dados do telefone celular e do email do cliente a ser autenticado.

**ACTION**
`POST`

**PATH**
`/api/user`

**HEADER**

`KEY: x-api-key`
`VALUE: My X-Api-Key`
`KEY:X-Auth-Token`
`VALUE: My X-Auth-Token`

**BODY**

{
"ApplicationToken": "AAAAAAA-BBBB-CCCC-DDDD-EEEEEEEEEEEE",
"CellPhone": “5521987654321”,
"Email": “[e-mail]”,
"UniqueIdentifier": “12345678910”
}

**Retorna os dados gravados**

**RESPONSE**

{
"UserToken": "AAAAAAA-BBBB-CCCC-DDDD-EEEEEEEEEEEE",
"UniqueIdentifier": “12345678910”,
"CellPhone": “5521987654321”,
"CellPhoneValidated": false
"Email": "[e-mail]",
"EmailValidated": false,
"CreationDate": "2020-01-01T12:00:00.000000Z"
}

**Registrar um telefone celular para um usuário**

- Insere os dados do telefone celular do cliente a ser autenticado.

**ACTION**
`POST`

**PATH**
`/api/user/cellphone`

**HEADER**
`KEY: x-api-key`
`VALUE: My X-Api-Key`
`KEY: X-Auth-Token`
`VALUE: My X-Auth-Token`

**BODY**

 { 
"ApplicationToken": "AAAAAAA-BBBB-CCCC-DDDD-EEEEEEEEEEEE",
"CellPhone": “5521987654321”,
"UniqueIdentifier": “12345678910”
 }

**Retorna os dados gravados**

**RESPONSE**

{
"UserToken": "AAAAAAA-BBBB-CCCC-DDDD-EEEEEEEEEEEE",
"UniqueIdentifier": “12345678910”,
"CellPhone": “5521987654321”,
"CellPhoneValidated": false,
"CreationDate": "2020-01-01T12:00:00.000000Z"
}

**Validar um código enviado por SMS para um telefone celular**

- Valida o usuário inserido anteriormente. O UserToken e o Password (enviado por SMS para o telefone cadastrado) devem ser fornecidos. Em caso de sucesso também retorna uma sessão UserSessionToken válida que pode ser utilizada em outras chamadas como, por exemplo, criação de Seed TOTP, evitando assim a necessidade de gerar uma nova sessão e o disparo de um novo SMS.

**ACTION**
`POST`

**PATH**
`/api/user/cellphone/validate`

**HEADER**
`KEY: x-api-key`
`VALUE: My X-Api-Key`
`KEY: X-Auth-Token`
`VALUE: My X-Auth-Token`

**BODY**

 { 
"UserToken": "AAAAAAA-BBBB-CCCC-DDDD-EEEEEEEEEEEE",
"UserPassword": “123456”
 }

As possíveis respostas são:

| ResponseCode | Message |
| -------- | -------- |
| 0 | CELULAR VALIDADO COM SUCESSO.|
| 0 | CELULAR JÁ VALIDADO.|
| -1 | SENHA INVÁLIDA OU TOKEN DO USUÁRIO.|
| -2 | SESSÃO EXPIRADA. |

**RESPONSE**

{
"UserSessionToken": "AAAAAAA-BBBB-CCCC-DDDD-EEEEEEEEEEEE",
"Validated": true,
"OneTimePassword": 0,

"ExpirationDate": "2020-01-01T12:00:00.000000Z",
"CreationDate": "2020-01-01T12:00:00.000000Z",
"ResponseCode": 0,
"Message": "CELLPHONE VALIDATED SUCCESSFULLY."
}

**Inserir os dados de um usuário para autenticação por email.**
- Inserir os dados de email do usuário a ser autenticado.

**ACTION**
`POST`

**PATH**
`/api/user/email`

**HEADER**
`KEY: x-api-key`
`VALUE: My X-Api-Key`
`KEY: X-Auth-Token`
`VALUE: My X-Auth-Token`

**BODY**

 { 
"ApplicationToken": "AAAAAAA-BBBB-CCCC-DDDD-EEEEEEEEEEEE",
"Email": “[e-mail]”,
"UniqueIdentifier": “12345678910”
 }

Retorna os dados gravados

**RESPONSE**

{
"UserToken": "AAAAAAA-BBBB-CCCC-DDDD-EEEEEEEEEEEE",
"UniqueIdentifier": “12345678910”,
"Email": “[e-mail]”,
"EmailValidated": false,
"CreationDate": "2020-01-01T12:00:00.000000Z"
}

**Validar o código enviado para o email do usuário**

- Valida o usuário inserido anteriormente. O UserToken e a Password (enviado para o E-mail cadastrado) devem ser fornecidos.
Em caso de sucesso também retorna uma sessão UserSessionToken válida que pode ser utilizada em outras chamadas, como, por exemplo, criação de Seed TOTP, evitando assim a necessidade de gerar uma nova sessão e o disparo de
um novo SMS.

**ACTION**
`POST`

**PATH**
`/api/user/email/validate`

**HEADER**
`KEY: x-api-key`
`VALUE: My X-Api-Key`
`KEY: X-Auth-Token`
`VALUE: My X-Auth-Token`

**BODY**

 { 
"UserToken": "AAAAAAA-BBBB-CCCC-DDDD-EEEEEEEEEEEE",
"UserPassword": “123456”
 }

As possíveis respostas são:

| ResponseCode | Message |
| -------- | -------- |
| 0 | EMAIL VALIDADO COM SUCESSO.|
| 0 | EMAIL JÁ VALIDADO.|
| -1 | SENHA INVÁLIDA OU TOKEN DO USUÁRIO.|
| -2 | SESSÃO EXPIRADA. |

**RESPONSE**

{
"UserSessionToken": "AAAAAAA-BBBB-CCCC-DDDD-EEEEEEEEEEEE",
"Validated": true,

"OneTimePassword": 0,
"CreationDate": "2020-01-01T12:00:00.000Z",
"ExpirationDate": "2020-01-01T12:10:00.000Z"
"ResponseCode": 0,
"Message": "EMAIL VALIDATED SUCCESSFULLY."
}

**Solicitar sessão de usuário com envio de SMS**

- Solicita uma nova sessão de usuário com o envio de SMS, OneTimePassword pode ser configurado do seguinte modo:

| OneTimePassword | |
| -------- | -------- |
| False | a autenticação fica válida durante todo o período da sessão|
| True | a autenticação é válida para uma única operação|

**ACTION**
`POST`

**PATH**
`/api/user/cellphone/session`

**HEADER**
`KEY: x-api-key`
`VALUE: My X-Api-Key`
`KEY: X-Auth-Token`
`VALUE: My X-Auth-Token`

**BODY**

 { 
"UserToken": "AAAAAAA-BBBB-CCCC-DDDD-EEEEEEEEEEEE",
"OneTimePassword": False
 }

**Retorna dados da sessão do usuário**

**RESPONSE**

{
"UserSessionToken": "AAAAAAA-BBBB-CCCC-DDDD-EEEEEEEEEEEE",
"OneTimePassword": False,
"ExpirationDate": "2020-01-01T12:00:00.000000Z",
"CreationDate": "2020-01-01T12:00:00.000000Z"
}

**Solicita sessão de usuário com envio de email**

- Solicita uma nova sessão de usuário com o envio de email, OneTimePassword pode ser configurado do seguinte modo:

| OneTimePassword | |
| -------- | -------- |
| False | a autenticação fica válida durante todo o período da sessão|
| True | a autenticação é válida para uma única operação|

**ACTION**
`POST`

**PATH**
`/api/user/email/session`

**HEADER**
`KEY: x-api-key`
`VALUE: My X-Api-Key`
`KEY: X-Auth-Token`
`VALUE: My X-Auth-Token`

**BODY**

{
"UserToken": "AAAAAAA-BBBB-CCCC-DDDD-EEEEEEEEEEEE",
"OneTimePassword": False
}

### 10 - Política ou procedimento informando que os dados de cartão são transmitidos de maneira segura

As informações referentes a este procedimento estão detalhadas no tópico **8 (oito)** deste mesmo documento.