Data Warehousing - Segurança

O objetivo de um data warehouse é tornar grandes quantidades de dados facilmente acessíveis aos usuários, permitindo que eles extraiam informações sobre o negócio como um todo. Mas sabemos que pode haver algumas restrições de segurança aplicadas aos dados que podem ser um obstáculo para o acesso às informações. Se o analista tiver uma visão restrita dos dados, será impossível capturar uma imagem completa das tendências dentro da empresa.

Os dados de cada analista podem ser resumidos e repassados à gerência, onde os diferentes resumos podem ser agregados. Como as agregações de resumos não podem ser iguais às da agregação como um todo, é possível perder algumas tendências de informação nos dados, a menos que alguém esteja analisando os dados como um todo.

Requisitos de Segurança

Adicionar recursos de segurança afetam o desempenho do data warehouse, portanto, é importante determinar os requisitos de segurança o mais cedo possível. É difícil adicionar recursos de segurança depois que o data warehouse foi ativado.

Durante a fase de design do data warehouse, devemos ter em mente quais fontes de dados podem ser adicionadas posteriormente e qual seria o impacto de adicionar essas fontes de dados. Devemos considerar as seguintes possibilidades durante a fase de design.

Se as novas fontes de dados exigirão a implementação de novas restrições de segurança e / ou auditoria?
Se os novos usuários adicionados que têm acesso restrito aos dados que já estão geralmente disponíveis?

Esta situação surge quando os futuros usuários e as fontes de dados não são bem conhecidos. Em tal situação, precisamos usar o conhecimento do negócio e o objetivo do data warehouse para saber os requisitos prováveis.

As seguintes atividades são afetadas por medidas de segurança -

Acesso do usuário
Carga de dados
Movimentação de dados
Geração de consulta

Acesso do usuário

Precisamos primeiro classificar os dados e, em seguida, classificar os usuários com base nos dados que eles podem acessar. Em outras palavras, os usuários são classificados de acordo com os dados que podem acessar.

Data Classification

As duas abordagens a seguir podem ser usadas para classificar os dados -

Os dados podem ser classificados de acordo com sua sensibilidade. Dados altamente confidenciais são classificados como altamente restritos e dados menos confidenciais são classificados como menos restritivos.
Os dados também podem ser classificados de acordo com a função do trabalho. Essa restrição permite que apenas usuários específicos visualizem dados específicos. Aqui, restringimos os usuários a visualizar apenas a parte dos dados nos quais estão interessados e pelos quais são responsáveis.

Existem alguns problemas na segunda abordagem. Para entender, vamos dar um exemplo. Suponha que você esteja construindo o data warehouse para um banco. Considere que os dados armazenados no data warehouse são os dados de transações de todas as contas. A questão aqui é quem tem permissão para ver os dados da transação. A solução está em classificar os dados de acordo com a função.

User classification

As seguintes abordagens podem ser usadas para classificar os usuários -

Os usuários podem ser classificados de acordo com a hierarquia de usuários em uma organização, ou seja, os usuários podem ser classificados por departamentos, seções, grupos e assim por diante.
Os usuários também podem ser classificados de acordo com sua função, com pessoas agrupadas nos departamentos com base em sua função.

Classification on basis of Department

Vejamos um exemplo de data warehouse em que os usuários são do departamento de vendas e marketing. Podemos ter segurança pela visão da empresa de cima para baixo, com acesso centrado nos diferentes departamentos. Mas pode haver algumas restrições aos usuários em diferentes níveis. Essa estrutura é mostrada no diagrama a seguir.

Mas se cada departamento acessa dados diferentes, devemos projetar o acesso de segurança para cada departamento separadamente. Isso pode ser alcançado por data marts departamentais. Como esses data marts são separados do data warehouse, podemos impor restrições de segurança separadas em cada data mart. Essa abordagem é mostrada na figura a seguir.

Classification Based on Role

Se os dados estiverem geralmente disponíveis para todos os departamentos, será útil seguir a hierarquia de acesso à função. Em outras palavras, se os dados são geralmente acessados por todos os departamentos, aplique restrições de segurança de acordo com a função do usuário. A hierarquia de acesso à função é mostrada na figura a seguir.

Requisitos de auditoria

A auditoria é um subconjunto da segurança, uma atividade cara. A auditoria pode causar sobrecargas pesadas no sistema. Para concluir uma auditoria a tempo, precisamos de mais hardware e, portanto, é recomendável que, sempre que possível, a auditoria seja desligada. Os requisitos de auditoria podem ser categorizados da seguinte forma -

Connections
Disconnections
Acesso de dados
Mudança de dados

Note- Para cada uma das categorias mencionadas acima, é necessário auditar o sucesso, o fracasso ou ambos. Do ponto de vista de razões de segurança, a auditoria de falhas é muito importante. A auditoria de falha é importante porque pode destacar o acesso não autorizado ou fraudulento.

Requisitos de rede

A segurança da rede é tão importante quanto outros títulos. Não podemos ignorar o requisito de segurança da rede. Precisamos considerar as seguintes questões -

É necessário criptografar os dados antes de transferi-los para o data warehouse?
Existem restrições nas rotas de rede que os dados podem seguir?

Essas restrições precisam ser consideradas com cuidado. A seguir estão os pontos a serem lembrados -

O processo de criptografia e descriptografia aumentará as despesas gerais. Isso exigiria mais poder de processamento e tempo de processamento.
O custo da criptografia pode ser alto se o sistema já for um sistema carregado, pois a criptografia é suportada pelo sistema de origem.

Movimento de Dados

Existem potenciais implicações de segurança ao mover os dados. Suponha que precisamos transferir alguns dados restritos como um arquivo simples a ser carregado. Quando os dados são carregados no armazém de dados, as seguintes questões são levantadas -

Onde o arquivo simples é armazenado?
Quem tem acesso a esse espaço em disco?

Se falamos sobre o backup desses arquivos simples, as seguintes questões são levantadas -

Você faz backup de versões criptografadas ou descriptografadas?
Esses backups precisam ser feitos em fitas especiais que são armazenadas separadamente?
Quem tem acesso a essas fitas?

Algumas outras formas de movimentação de dados, como conjuntos de resultados de consulta, também precisam ser consideradas. As questões levantadas durante a criação da mesa temporária são as seguintes -

Onde essa mesa temporária será mantida?
Como você torna essa mesa visível?

Devemos evitar o desprezo acidental das restrições de segurança. Se um usuário com acesso aos dados restritos pode gerar tabelas temporárias acessíveis, os dados podem ser visíveis para usuários não autorizados. Podemos superar esse problema tendo uma área temporária separada para usuários com acesso a dados restritos.

Documentação

Os requisitos de auditoria e segurança precisam ser devidamente documentados. Isso será tratado como parte da justificação. Este documento pode conter todas as informações coletadas de -

Classificação de dados
Classificação do usuário
Requisitos de rede
Requisitos de movimentação e armazenamento de dados
Todas as ações auditáveis

Impacto da segurança no design

A segurança afeta o código do aplicativo e os prazos de desenvolvimento. A segurança afeta a seguinte área -

Desenvolvimento de aplicações
Projeto de banco de dados
Testing

Desenvolvimento de aplicações

A segurança afeta o desenvolvimento geral do aplicativo e também afeta o design dos componentes importantes do data warehouse, como gerenciador de carga, gerenciador de warehouse e gerenciador de consultas. O gerenciador de carga pode exigir a verificação do código para filtrar o registro e colocá-lo em locais diferentes. Mais regras de transformação também podem ser necessárias para ocultar certos dados. Além disso, pode haver requisitos de metadados extras para lidar com quaisquer objetos extras.

Para criar e manter visualizações extras, o gerente do warehouse pode exigir códigos extras para reforçar a segurança. Pode ser necessário codificar verificações extras no data warehouse para evitar que sejam enganados e movam os dados para um local onde não deveriam estar disponíveis. O gerenciador de consultas requer mudanças para lidar com quaisquer restrições de acesso. O gerenciador de consultas precisará estar ciente de todas as visualizações e agregações extras.

Projeto de banco de dados

O layout do banco de dados também é afetado porque quando medidas de segurança são implementadas, há um aumento no número de visualizações e tabelas. Adicionar segurança aumenta o tamanho do banco de dados e, portanto, aumenta a complexidade do design e do gerenciamento do banco de dados. Isso também aumentará a complexidade do plano de gerenciamento e recuperação de backup.

Testando

Testar o data warehouse é um processo complexo e demorado. Adicionar segurança ao data warehouse também afeta a complexidade do tempo de teste. Isso afeta o teste das duas maneiras a seguir -

Isso aumentará o tempo necessário para integração e teste do sistema.
Há uma funcionalidade adicional a ser testada, que aumentará o tamanho do conjunto de testes.