Você sabe que tem acesso aos seus dados?

Nem sempre é possível saber. Os riscos legais e financeiros de compartilhar dados sensitivos entre departamentos internos ou com consultores externos, contratos-offshore estão cada vez mais evidentes.  Qualquer dado que contenha identidade (nome do cliente & faturamento , nome/salário de empregado, cartão de crédito, etc)  ou propriedade intelectual  ou ainda contratos governamentais – carregam consigo o perigo de serem utilizados de forma indevida ou serem furtados ou simplesmente ser distribuído entre um grupo de pessoas que possam ter interesse excusos nessas informações.  Definida como uma solução simples, escalável e que atinge vários níveis corporativos, o DataVantage Global® mascara dados confidenciais a fim de atender leis regulatórias (governo & indústria) enquanto é preservada a integridade dos dados a serem usados em aplicações corporativas.

Visão Geral

A solução DataVantage Global®  protege informações financeiras, pessoais, as quais são consideradas confidenciais e sensitivas. É uma solução simples, baseada em Java, escalável e que atinge todos os níveis hierárquicos da corporação. O DataVantage Global promove de maneira efetiva e com baixo custo a migração, gerenciamento e obscuramento de dados entre múltiplas plataformas com objetivo de atender às rígidas leis de adequação de órgãos que regem os requerimentos de Privacidade de Dados. Pelo fato do DataVantage Global acessar mainframe, sistemas legados, client-server e desktop como uma solução única, é eliminada a necessidade para produtos de software adicionais ou programas de customização in-house.

DataVantage Global: Atende aos desafios de Privacidade de Dados

· Solução escalável na corporação - Uma solução simples, cross-platform abrange sistemas de várias plataformas;

· Múltiplos métodos - Componentes diferentes podem ser intercambiados dentro de campos e colunas para facilitar as mais extensas combinações;

·  Audite e Controle - Documenta o porquê um determinado método foi selecionado e pode ser usado para registrar controle de mudanças;

· Conjunto de regras customizáveis pelo usuário - O usuário determina como ofuscar o dado utilizando componentes de software fiexíveis  que  podem substituir métodos pré-definidos;

· Referencial e  Integração - Qualquer item de dados sendo ofuscado é mantido concorrentemente, não somente os items de dados em chaves referenciais. DVG também mantém a Integridade JOIN sobre todas chaves-candidatas do dado ofuscado;

· Tarefas Repetitivas - O trabalho pode ser salvo, compartilhado e planejado de forma repetitiva através da corporação a fim de simplificar a implementação de padrões corporativos e adequações de lei;

· Custo-Efetivo - Uma ÚNICA solução para adquirir, implementar, treinar e manter.

Mascaramento de Dados

Mascaramento de Dados começou a aparecer como um ´problema´ em 2004 e desde então tem crescido organicamente dentro das corporações.  Inicialmente, as questões relativas a privacidade de dados foram levantadas por auditorias relacionadas à GLBA (regulação em serviços financeiros nos USA) e agora vemos que trata-se de um requerimento mandatório do PCI (regulação em operadoras de processamento cartão-de-crédito).

Mascaramento de Dados não é o termo correto sobre o tema desse artigo. Tecnicamente, nós podemos mascarar dados em qualquer lugar, porém, quando usamos o termo Mascaramento do Dado  - estamos nos referindo a "geração de dados de teste" ou  "geração de dados analíticos". Trata-se da conversão de dados de produção seja para ambiente de testes e/ou desenvolvimento  ou ainda dados para geração de um data warehouse (OLAP). Tendo isso em mente, iremos focar o artigo na geração de dados de teste mas, as mesmas técnicas podem ser usados em OLAP onde você usa dados de produção , porém, com uma camada de proteção. E esse é exatamente o nosso objetivo – obter dados sensitivos de um sistema em produção e convertê-lo em dados não-sensitivos – e que sejam preparados para teste ou análise. Podemos fazer isso através  de substituição, transposição, obscuramento, embaralhamento, hashing ou mesmo encriptação. Iremos eliminar de nossa análise – os métodos de  hashing e encriptação. Essas técnicas são muito efetivas na proteção do dado, mas , os resultados quebram a  segunda regra de Mascaramento de Dado, que é, o dado encriptado ainda representa o dado fonte, sem se tornar  sensitivo. Várias corporações estão cientes de que a técnica de Mascaramento de Dados é mandatória para cumprir a aderência às leis de regulação (governo e indústria). É também um caminho extremamente efetivo para redução de riscos corporativos. Os ambientes de teste e desenvolvimento raramente são seguros como o ambiente de produção e não existem razões para permitir que desenvolvedores tenham acesso a dados sensitivos. Sistemas analitícos são frequentemente acessados por uma grande variedade de usuários e a grande parte   não deve ter acesso a dados sensitivos também. Somente parte dos  usuários podem ter acesso liberado e mesmo assim com controles de segurança extremamente rígidos.

Isto posto, segue abaixo as 5 leis que regem  o uso de  Mascaramento de Dados:

1 - Mascaramento não deve ser reversível -  Embora você mascare o dado, nunca deve ser possível de recuperá-lo ao estado original de dado sensitivo;

2 - Os resultados devem ser representativos do dado fonte - A razão para mascarar o dado ao invés  de somente gerar dados randômicos é que o mascaramento permite que voce proteja informação sensitiva que ainda  ´lembre´ o dado de produção para fins de desenvolvimento e testes. Isto poderia incluir distribuição geográfica , distribuição de cartões de crédito (por exemplo – deixar os 4 primeiros dígitos inalterados e embaralhar o restante ); ou manter a visualização em termos legíveis com nomes e endereços fictícios.

3 - A integridade referencial deve ser mantida - A solução de mascaramento que for adotada, deve manter a integridade referencial – se o número de cartão-de-crédito for a chave-primária e o embaralhamento for parte do mascaramento, então todas instancias daquele número ligados através de pares-de-chaves devem ser embaralhados de forma idêntica.

4 - Mascare dados não sensitivos somente se eles serão usados para recriar dados sensitivos - Não é necessário mascarar tudo no database – somente partes que voce julgar sensitiva. Mas , lembre-se que alguns dados não-sensitivos podem ser usados para recriar ou trazer de volta como dado sensitivo. Por exemplo : se você embaralhar uma identificação pessoal de saúde mas o código de tratamento para um registro poderia somente mapear de volta ao registro original, você também terá que embaralhar esse código. A esse processo damos o nome de análise de inferência e o processo de mascaramento que voce adotar deverá estar protegido para que isso não ocorra.  

5 - Mascaramento deve ser um processo repetitivo - Efetuar o processo de mascaramento somente uma vez é muito dificil de ser mantido e não é eficiente que seja assim. Os dados de desenvolvimento e teste devem representar as constantes variações do dado de produção – o mais próximo possível da realidade. Dados analíticos podem ser gerados diariamente ou mesmo de hora em hora. Se o mascaramento não for um processo automatizado – então resultará uma tarefa ineficiente, custosa e ineficaz.  Algumas corporações centralizam o processo de mascaramento em uma área e esta oferece como um serviço interno a vários departamentos. 

Solicite agora mesmo uma Versão Free Trial do Produto!