Resumo Técnico · Documento de Demonstração

CipherTrust Data Security Platform

Plataforma de demonstração interativa dos módulos Thales CipherTrust, desenvolvida para pré-vendas e capacitação técnica.
Autor: Caio AlbertoEmpresa: TD SYNNEXFabricante: ThalesVersão: 1.0

1. Visão geral

O CipherTrust Data Security Platform é a plataforma unificada de segurança de dados da Thales. Em uma única console (CipherTrust Manager), reúne descoberta, classificação, criptografia, tokenização, mascaramento e controle de acesso — protegendo dados em repouso, em uso e na nuvem.

Esta plataforma de demonstração (site web estático) apresenta cada módulo com showcases dedicados, diagramas conceituais, demonstrações interativas em JavaScript e tutoriais de implantação fiéis aos guias oficiais TD SYNNEX.

1 · DESCOBRIRDDC identifica dados sensíveis
→
2 · PROTEGERCTE (repouso) ou CT-VL (uso)
→
3 · CONTROLARAccess Policies por identidade
→
4 · CUMPRIRAuditoria LGPD/PCI/GDPR
↑ Topo

2. Módulos da plataforma

🔐 Tokenization Server (CT-VL)

Proteção de dados em uso: substitui CPF, cartões e e-mails por tokens irreversíveis, preservando o formato (FPE/FF1).

VaultlessFPE/FF1Masking

🛡️ Transparent Encryption (CTE)

Proteção de dados em repouso: criptografia transparente a nível de arquivo/volume, com GuardPoints, políticas e proteção anti-ransomware.

Data-at-restGuardPointAnti-Ransomware

🔎 Data Discovery & Classification (DDC)

Descobre e classifica dados sensíveis em bancos, arquivos e nuvem, por nível de risco — base para conformidade.

DiscoveryClassificationCompliance

☁️ Cloud Key Management (CCKM)

Gestão centralizada do ciclo de vida de chaves em AWS e Azure, com BYOK/HYOK e rotação automática.

AWS/AzureBYOKRotation
↑ Topo

3. Demonstrações interativas (showcase de Tokenização)

O showcase de Tokenização inclui três demonstrações em JavaScript puro (sem back-end), com dados fictícios:

3.1 · Tokenizar / Detokenizar

Anima a substituição do dado real pelo token (FPE) e permite reverter. Tokens válidos recuperam o valor original; tokens adulterados resultam em 403 ACCESS DENIED.

3.2 · Controle de acesso por perfil

O mesmo dado é exibido de forma diferente conforme o perfil do usuário e a política do CT-VL:

PerfilPolíticaResultado (ex.: CPF)
👔 Diretordetokenize + view clear123.456.789-09 (claro)
🎧 Call Centerapenas mask***.***.789-09 (mascarado)
💻 Desenvolvedorsem detokenize111.444.777-06 (tokenizado)

3.3 · Token fora do CT-VL (sem valor)

Demonstra que um token roubado, usado fora do Tokenization Server (banco de terceiros, planilha, API externa), é apenas um valor sem significado: 0 rows, #N/D, 402 recusado.

🔐 A detokenização só ocorre dentro do CT-VL, com a política e a chave corretas, e apenas para usuários autorizados. Fora dele, o token é inútil.
↑ Topo

4. Função de tokenização unificada

A demonstração usa uma função FPE didática (Format-Preserving Encryption) que preserva o tipo de cada caractere: número vira número, letra minúscula vira minúscula, letra maiúscula vira maiúscula, e a pontuação (. - @ espaço) é mantida. Assim o token tem o mesmo formato e tamanho do dado original, sem quebrar sistemas.

// Tokenização FPE didática — preserva o tipo do caractere (mesma função nas 3 demos)
function tokenizeStr(s){
  var out = "", digits = "0123456789";
  for(var i = 0; i < s.length; i++){
    var c = s[i];
    if(c >= '0' && c <= '9')                       // dígito → dígito
      out += digits[(parseInt(c)*7 + i*3 + 4) % 10];
    else if(c >= 'a' && c <= 'z')                  // minúscula → minúscula
      out += String.fromCharCode(((c.charCodeAt(0)-97 + 7 + i) % 26) + 97);
    else if(c >= 'A' && c <= 'Z')                  // maiúscula → maiúscula
      out += String.fromCharCode(((c.charCodeAt(0)-65 + 7 + i) % 26) + 65);
    else
      out += c;                                    // pontuação preservada
  }
  return out;
}

Exemplos de saída

Dado realToken (FPE)Formato preservado
123.456.789-09111.444.777-06✔ só dígitos
4111 5643 8890 12342470 4439 0333 6666✔ formato de cartão
cliente@empresa.comjtroyfr@tcgjxmv.zml✔ só letras (sem números)
Caio AlbertoJiry Mypthkg✔ maiúsculas preservadas
⚠️ Nota didática: esta é uma cifra reversível simplificada, apenas para a demonstração visual. O CT-VL real utiliza os algoritmos FF1/FF3 (NIST) baseados em AES, com chaves gerenciadas no CipherTrust Manager (FIPS 140-3).
↑ Topo

5. Tutoriais de implantação

A seção de Tutoriais reproduz fielmente os Guias de Implantação TD SYNNEX, com 100 capturas de tela reais distribuídas em 37 seções, cobrindo:

↑ Topo

6. Diagrama de arquitetura

A plataforma opera em quatro camadas: as fontes de dados são descobertas e protegidas pelos módulos (DDC, CTE, CT-VL, CCKM); todas as chaves, políticas e logs são centralizados no CipherTrust Manager; e as evidências alimentam a governança e conformidade.

Diagrama de arquitetura da plataforma CipherTrust
🗝️ O CipherTrust Manager é o ponto único de gestão: um mesmo painel controla chaves (KMIP), domínios (multitenancy), políticas de acesso por identidade e auditoria — para todos os módulos.
↑ Topo

7. FAQs técnicas

Qual a diferença entre tokenização (CT-VL) e criptografia (CTE)?

A criptografia (CTE) protege dados em repouso — arquivos e volumes ficam cifrados no disco, de forma transparente para as aplicações. A tokenização (CT-VL) protege dados em uso — substitui o valor sensível por um token de mesmo formato, usado no lugar do dado em bancos e aplicações. Use CTE para proteger o armazenamento; CT-VL para reduzir a exposição do dado nos sistemas e no escopo de conformidade.

O que significa "vaultless" no CT-VL?

Significa que não há um cofre (banco de tokens) armazenando os pares dado↔token. O token é derivado criptograficamente (FPE/FF1), o que elimina o gargalo e o risco de um repositório central, tornando a solução altamente escalável.

O que é FPE / FF1 e por que preserva o formato?

FPE (Format-Preserving Encryption) é uma cifra que produz uma saída no mesmo formato e tamanho da entrada. O FF1 é o modo aprovado pelo NIST (SP 800-38G), baseado em AES. Assim, um CPF continua com cara de CPF e um cartão passa na validação de formato — sem quebrar sistemas legados nem exigir mudança de schema.

A tokenização é reversível? Como funciona a detokenização?

Depende do template: pode ser reversível (permite detokenizar) ou irreversível (ideal para LGPD/anonimização). Quando reversível, a detokenização só ocorre dentro do CT-VL, mediante a política e a chave corretas, e apenas para usuários autorizados — com auditoria de cada acesso.

Se um token vazar, o dado real fica exposto?

Não. Fora do CT-VL, o token é apenas um valor sem significado: não corresponde a nenhum registro em bancos de terceiros, não é um cartão válido em APIs de pagamento e não abre nada em planilhas. Só o CT-VL, com política e chave, consegue reverter — e ainda assim apenas para quem tem permissão.

Como funciona o mascaramento por perfil?

As políticas do CT-VL definem o que cada perfil vê do mesmo dado: um diretor pode ver em claro (detokenize), o call center vê mascarado (ex.: ***.***.789-09) e o desenvolvedor recebe apenas o token. A máscara mostra só os caracteres necessários para a operação, sem expor o valor completo.

O que é BYOK/HYOK no CCKM?

BYOK (Bring Your Own Key) permite gerar a chave no CipherTrust e importá-la para a nuvem (AWS/Azure), mantendo o controle da origem. HYOK (Hold Your Own Key) mantém a chave sempre sob seu controle on-premises. Em ambos, o CCKM centraliza o ciclo de vida (criação, rotação, expiração, revogação) num único painel.

O que é um GuardPoint no CTE?

Um GuardPoint é um diretório/volume colocado sob proteção do CTE. Cada GuardPoint tem exatamente uma Policy associada, que define a chave, quais usuários/processos acessam, a ação permitida e o efeito (permit, deny, apply key, audit). É o que torna a criptografia transparente e controlada por identidade.

A plataforma atende quais requisitos de conformidade?

Com criptografia validada em FIPS 140-3, gestão central de chaves e auditoria, a plataforma apoia LGPD, PCI-DSS, GDPR e HIPAA — reduzindo o escopo de conformidade (ex.: dados tokenizados saem do escopo de dados sensíveis) e fornecendo evidências para auditoria.

As demonstrações do site usam dados reais?

Não. Todas as demos usam dados fictícios e rodam inteiramente no navegador (JavaScript, sem back-end). A função de tokenização das demos é uma cifra didática reversível — o CT-VL real utiliza FF1/FF3 (NIST) com AES e chaves no CipherTrust Manager.

↑ Topo

8. Glossário técnico

Principais termos usados na plataforma e nesta documentação.

🎬 Glossário em vídeo

Uma passagem animada pelos 12 termos-chave, com definição e exemplo prático de cada um (~34s):

🔊 Trilha ambiente suave · 💬 Legendas em português (ative o botão CC do player). Baixar o vídeo (MP4)

Tabela de termos

TermoDefiniçãoExemplo prático
TokenizaçãoSubstituição de um dado sensível por um token — valor substituto sem significado fora do sistema. Reduz a exposição e o escopo de conformidade.Um e-commerce guarda token=2470... no lugar do cartão real. Se o banco vazar, o cartão não é exposto.
TokenValor substituto gerado pela tokenização. Preserva o formato do dado original, mas não carrega o valor real.123.456.789-09 → 111.444.777-06 (mesmo formato de CPF).
VaultlessTokenização sem cofre (sem banco de tokens). O token é derivado criptograficamente, ganhando escalabilidade.Milhões de tokens/seg sem um banco central virar gargalo ou alvo único de ataque.
FPE
Format-Preserving Encryption
Criptografia que preserva o formato e tamanho da entrada — não quebra schemas nem validações legadas.Campo VARCHAR(14) de CPF continua válido: o token também tem 14 caracteres com pontos e traço.
FF1 / FF3Modos de FPE aprovados pelo NIST (SP 800-38G), baseados em AES. FF1 é o mais recomendado.No template do CT-VL, escolhe-se FF1 para tokenizar cartões mantendo o dígito de Luhn.
Mascaramento
masking
Exibição parcial do dado, mostrando só o necessário conforme o perfil.Atendente vê 4111 **** **** 1234 — suficiente para confirmar o cartão, sem expor o número.
DetokenizaçãoReverter o token ao valor original. Só ocorre dentro do CT-VL, com política e chave, para usuários autorizados.O setor financeiro, autorizado, detokeniza para emitir a nota fiscal com o CPF real.
CT-VLCipherTrust Vaultless Tokenization — servidor de tokenização (dados em uso).Proteger CPF/cartão num CRM sem alterar a estrutura do banco.
CTECipherTrust Transparent Encryption — criptografia transparente de dados em repouso.Cifrar a pasta D:\dados_sql\ de um SQL Server sem mudar a aplicação.
GuardPointDiretório/volume protegido pelo CTE. Cada um tem exatamente uma Policy./dados/financeiro vira um GuardPoint com a policy “só o grupo Finanças lê”.
Policy
Política
Regras (chave, quem acessa, ação e efeito) que governam o acesso e a criptografia.Regra: usuário backup → ação read → efeito Deny (recebe cifrado).
LDT
Live Data Transformation
Recurso do CTE que cifra pastas que já contêm dados, sem downtime.Cifrar 2 TB de arquivos em produção enquanto os usuários seguem trabalhando.
DDCCipherTrust Data Discovery & Classification — descobre e classifica dados sensíveis por risco.Um scan encontra 12.400 CPFs numa planilha esquecida e marca como “Risco: alto”.
TDPMáquina/appliance que executa os scans de descoberta do DDC.O TDP varre file servers e bancos toda madrugada, gerando o relatório de sensíveis.
CCKMCipherTrust Cloud Key Management — gestão centralizada de chaves de nuvem.Rotacionar todas as chaves do Azure Key Vault e do AWS KMS de um só painel.
BYOK
Bring Your Own Key
Gerar a chave no CipherTrust e importá-la para a nuvem, mantendo o controle da origem.A chave nasce on-premises (FIPS 140-3) e é enviada ao AWS KMS como material BYOK.
HYOK
Hold Your Own Key
Manter a chave sempre sob controle próprio (on-premises), sem entregá-la à nuvem.Dado na nuvem só é decifrado se o serviço consultar a chave que nunca sai do seu data center.
KMIPKey Management Interoperability Protocol — padrão para gestão de chaves.Um storage NetApp pede a chave ao CipherTrust Manager via KMIP.
CipherTrust ManagerConsole central: chaves, políticas, domínios e auditoria de todos os módulos (FIPS 140-3).Um único login administra chaves do CTE, CT-VL e CCKM ao mesmo tempo.
Domínio
multitenancy
Segmentação lógica que isola recursos, chaves e políticas por setor/projeto/cliente.Domínio “RH” e domínio “Finanças” não enxergam as chaves um do outro.
NAEInterface do CipherTrust usada pelo CT-VL para as operações de tokenização via rede.A DemoApp chama a interface NAE (TLS) para tokenizar/detokenizar.
FIPS 140-3Padrão do governo dos EUA que valida módulos criptográficos.Exigência comum em edital de banco/governo: “criptografia validada FIPS 140-3”.
LGPD / PCI-DSS
GDPR / HIPAA
Regulações de proteção de dados (Brasil, cartões, Europa e saúde nos EUA).Tokenizar o PAN do cartão tira o sistema do escopo pesado do PCI-DSS.
↑ Topo

9. Arquitetura técnica do site

CamadaTecnologia / abordagem
Front-endHTML5 + CSS3 (design system com variáveis) + JavaScript vanilla (sem frameworks)
EstruturaHub central + 4 showcases + tutoriais + resumo técnico (páginas estáticas)
IdiomasBilíngue PT-BR / ES (i18n via data-i18n)
TemasClaro e escuro (dark mode) com persistência em localStorage
AcessibilidadeSkip-link, foco visível, no-js fallback, ARIA no dropdown
PerformanceImagens otimizadas, lazy-loading, barra de progresso, scroll-spy
Conformidade visualPaleta oficial Thales (navy #0c2340 · ciano #00b0b9)
↑ Topo

10. Ambientes de demonstração

O acesso à demonstração é feito pelo próprio site, publicado sob o domínio corporativo e protegido por Cloudflare Access — apenas usuários previamente autorizados conseguem acessar.

Os botões de acesso usam caminhos internos relativos (âncoras da própria página), sem URL absoluta fixa — assim o domínio pode mudar (ou migrar de/para a Cloudflare) sem quebrar os links.

BotãoCaminho interno
Acessar demo (topo)#cta
Acessar demonstração (Hub)#modulos
Acessar demonstração (Tokenization)#demo
Acessar demonstração (CTE / DDC / CCKM)#how
🔒 Cloudflare Access: a autenticação (e a lista de e-mails/domínios liberados) é gerenciada no painel da Cloudflare, na frente do site. Usuários não autorizados são bloqueados antes de a página carregar — sem depender de nenhum link fixo no HTML.
© 2026 TD SYNNEX · Thales CipherTrust — material de demonstração desenvolvido por Caio Alberto.