Lei Geral de Proteção de Dados Pessoais (LGPDP ou LGPD) aplicada a bancos de dados SQL Server

É a sigla para Lei Geral de Proteção de Dados, cujo objetivo é aumentar a privacidade de dados pessoais e evitar casos como os grandes vazamentos de informações e escândalos que envolvem justamente o uso indevido de informações pessoais que temos acompanhado nos últimos anos.

A criação dessa lei, coloca o Brasil no rol de mais de 100 países que, hoje, podem ser considerados adequados para proteger a privacidade e o uso de dados no cenário global.

O tema mobilizou o Congresso principalmente depois do vazamento de dados dos usuários do Facebook, uma das maiores redes sociais, coletados pela empresa Cambrigde Analytica e usados nas últimas eleições nos Estados Unidos.

O que são dados pessoais?
Segundo a lei, dado pessoal é “informação relacionada a pessoa natural identificada ou identificável” e dado pessoal sensível é “dado pessoal sobre origem racial ou étnica, convicção religiosa, opinião política, filiação a sindicato ou a organização de caráter religioso, filosófico ou político, dado referente à saúde ou à vida sexual, dado genético ou biométrico, quando vinculado a uma pessoa natural”.

Entretanto, esse conceito ainda é muito amplo. Dado pessoal pode ser qualquer informação que identifique uma pessoa, como por exemplo, nome e sobrenome, nome da mãe, CPF, RG, E-mail dentre outros. Além disso, também é considerado dado pessoal se uma informação, quando cruzada com outro dado, permita identificar uma pessoa. Ou seja, o ID da conta de uma rede social, como o Facebook, por exemplo, pode ser considerado um dado pessoal também.

Qual o objetivo da LGDP?
A principal meta da LGPD é garantir a privacidade dos dados pessoais (especialmente, os dados sensíveis) e forçar as empresas a utilizarem mais controles para proteger essas informações contra invasões, acessos indevidos e vazamentos de dados pessoais sensíveis.

Além disso, a lei cria regras claras sobre os processos de coleta (usuário deve concordar com isso), armazenamento (em locais seguros e criptografados) e compartilhamento dessas informações (apenas com autorização do usuário). Esse consentimento deverá ser fornecido por escrito ou por outro meio que demonstre a manifestação de vontade do titular e poderá ser revogado a qualquer momento.

Dentre seus princípios, tem especial relevância o da transparência para o uso de dados pessoais e a respectiva responsabilização, o da adequação, ou seja, a compatibilização do uso dos dados pessoais com as finalidades informadas, da proteção do usuário em toda arquitetura do negócio (privacy by design), da finalidade, segundo o qual os dados só devem ser utilizados para as finalidades específicas para as quais foram coletados e previamente informados aos seus titulares, e também do princípio da necessidade, que significa limitar o uso dos dados ao mínimo necessário para que se possa atingir a finalidade pretendida, do qual surge ainda a indispensável exclusão imediata de dados, após atingida tal finalidade.

Data Protection Officer
Com a LGDP, as organizações devem estabelecer um Comitê de Segurança da Informação, a fim de analisar os procedimentos internos e como os dados estão sendo armazenados, coletados, protegidos e compartilhados. Dentro deste órgão sugere-se que haja um profissional exclusivo para a proteção dos dados (Data Protection Officer), ficando assim, responsável pelo cumprimento dessa nova lei, atender reclamações dos titulares e lider com quaisquer problemas referentes à proteção de dados.

Controlador, Operador e Encarregado
A lei criou os chamados Agentes de Tratamento de dados pessoais – nas figuras do Controlador e do Operador – que podem ser uma pessoa natural ou jurídica, de direito público ou privado. Ao primeiro (controlador) competem as decisões referentes ao tratamento de dados pessoais, enquanto ao segundo (operador), a realização do tratamento em nome do primeiro.

Foi definida também a figura do Encarregado, que também na condição de pessoa natural ou jurídica, de direito público ou privado, atuará como canal de comunicação entre o Controlador e os titulares de dados pessoais e a Autoridade Nacional de Proteção de Dados (ANPD).

E o que muda para os usuários com essa nova lei?
Para os usuários de serviços, tanto online ou offline, a maior mudança é no acesso às informações sobre os seus dados. Quando a lei já estiver em vigor, os cidadãos poderão saber como as empresas, públicas ou privadas, tratam os dados pessoais:

• como os dados foram coletados
• por quê coletam seus dados
• como armazenam os dados coletados
• por quanto tempo guardam seus dados
• com quem compartilham

O que muda para as empresas com essa nova lei?
Com a nova Lei Geral de Proteção de Dados brasileira, todas as empresas de pequeno, médio e grande porte terão que investir em cibersegurança e implementar sistemas de compliance efetivos para prevenir, detectar e remediar violações de dados pessoais, notadamente porque a lei prevê que a adoção de política de boas práticas será considerada como critério atenuante das penas.
Também lhes é garantido o direito à revogação, à portabilidade e à retificação dos dados.

Além disso, as empresas deverão fornecer as informações dos usuários para os mesmos de forma clara e simples, onde muitas já adotam essa prática em seus sites, mas a partir da LGDP, isso será obrigatório e não mais uma opção.

Exceções na LGDP
As únicas exceções à aplicação da LGDP são o tratamento de dados pessoais realizado por pessoa natural para fins exclusivamente particulares e não econômicos, além daqueles realizados exclusivamente para fins (i) jornalístico, artístico ou acadêmico (neste caso, não se dispensa o consentimento), (ii) de segurança pública, defesa nacional, segurança do Estado ou atividades de investigação e repressão de infrações penais ou (iii) dados em trânsito, ou seja, aqueles que não tem como destino Agentes de Tratamento no Brasil.

Informações de menores de idade
Quando se tratar de um serviço ou produto destinado a crianças, a linguagem deverá ser adequada para a faixa etária, sendo ainda mais clara e compreensível, mas se dirigindo também aos pais ou responsáveis – inclusive porque é exigido no artigo 20 inciso 2, o consentimento pelo menos um dos pais ou pelo responsável legal para o tratamento dos dados de crianças e adolescentes.

Publicidade direcionada
Com a LGDP, os modelos de negócios digitais baseados em publicidade direcionada precisarão ser auditados. Por exemplo, se uma pessoa compra uma pulseira inteligente que mede batimentos cardíacos, a finalidade é obter informações sobre sua saúde. Se a empresa da pulseira decide compartilhar os dados com uma marca de seguro, a finalidade do consentimento entra em conflito com o interesse empresarial.

Nas normas de hoje, o seguro de saúde poderia oferecer um plano mais caro a um cliente por saber que ele tem problemas cardíacos, por exemplo, e com a LGDP isso não poderá mais ocorrer sem o explícito consentimento do usuário.

Subcontratados (empresas ou pessoas terceirizadas)
A LGPD se aplica também a estes profissionais, como fornecedores e parceiros de tecnologia. Eles também ficam sujeitos às obrigações e podem realizar pagamentos de indenização, por exemplo.

E se a minha empresa não se adequar? O que acontece ?
A LGDP prevê sanções para quem não tiver em conformidade com as boas práticas. Elas englobam advertências, multas e, no pior dos casos, a proibição total ou parcial de atividades relacionadas ao tratamento de dados. As multas podem variar de 2% do faturamento do ano anterior da empresa, até a R$ 50 milhões, passando por penalidades diárias.

E se mesmo com todas as proteções, houverem vazamentos de dados na empresa?
A LGPD determina que as empresas coletem apenas os dados necessários aos serviços que prestam. No casos de vazamentos de dados, o encarregado deverá informar ao órgão competente e aos titulares (donos dos dados vazados), o que já é uma prática recomendada nessa situação (mesmo antes da lei), embora muitas vezes, as empresas tentem omitir o vazamento, agravando ainda mais a situação.

Quando essa lei começa a vigorar??
A partir da data de publicação da lei (14 de agosto de 2018), as empresas têm 24 meses para se adaptarem à lei, que será em Agosto de 2020.

Serão 24 meses para adequação das empresas e os principais desafios que já surgem são:

• nomeação de um encarregado
• realização de uma auditoria de dados
• elaboração de mapa de dados
• revisão das políticas de segurança
• revisão de contratos
• elaboração de Relatório de Impacto de Privacidade

Um resumo da LGPD

Firewall

Recurso importantíssimo para evitar ataques e acessos indevidos, o Firewall está disponível nos ambientes On-Premises (Windows Firewall e Firewall de terceiros) quanto em ambientes de Cloud e ele serve para impedir acessos não autorizados ao seu banco de dados.

A ideia do Firewall é bloquear acessos de IP’s que não estejam na lista de IP’s permitidos, fazendo com que atacantes não consigam nenhum tipo de acesso, independente da técnica utilizada por estes, o que na prática é uma segurança muito eficaz contra vários tipos de ataques.

Embora não seja uma atividade especificamente do DBA (é mais de infra), o DBA deve sim, ter conhecimentos sobre como funciona um Firewall, como configurá-lo e analisar os logs. Especialmente em ambientes de Cloud, são comuns os cenários em que o DBA acaba “herdando” essa responsabidade de gerenciar as regras de Firewall dos bancos de dados.

Cuidados com ataques de força bruta

Por armazenar praticamente todos os dados de clientes e da empresa como um todo, os bancos de dados são potencialmente, um dos alvos mais buscados por invasores que tentam roubar informações ou simplesmente obter acesso privilegiado à esse banco para outro fim qualquer.

Falando especificamente sobre SQL Server, existem algumas formas de identificar a ocorrência desse tipo de ataque e se proteger para que não seja possível ficar tentando logar no banco utilizando senhas incorretas sucessivas vezes sem uma penalidade por isso. Uma dessas formas é ativar o log do SQL Server para registrar todas as tentativas de falha de login por senha incorreta. Fique de olho no log do SQL e sempre busque por cenários onde há muita ocorrência de falhas de login!

Para saber mais sobre ataques de força bruta no SQL Server e evitar esse tipo de ataque, não deixe de conferir o meu artigo SQL Server – Como evitar ataques de força bruta no seu banco de dados.

Cuidados com as permissões

Outro ponto muito importante é com relação às permissões no banco de dados. Você, como DBA, deve prezar sempre pela regra do menor acesso possível para todos os usuários. Esqueça sysadmin e db_owner, reforçe sempre a segurança do seu ambiente concedendo a permissão específica que um usuário precisa para realizar a sua tarefa (e revise as permissões de forma periódica). Se um sistema precisa de acesso de leitura em 10 tabelas e escrita em 5, esse é o acesso que você deve liberar, especialmente para usuários de integração.

Um cenário que facilita muito o vazamento de informações são aplicações que compartilham um mesmo servidor de banco de dados e todas elas possuem acesso total aos dados. Em caso de qualquer brecha de segurança em uma dessas aplicações, o invasor terá acesso a todos os dados, de todas as aplicações desse servidor de banco de dados, aumentando exponencialmente o dano causado por essa invasão.

Alguns artigos que podem te ajudar a aumentar a segurança do seu ambiente:

• Verificando as permissões de um usuário no SQL Server
• SQL Server – Entendendo os riscos da propriedade TRUSTWORTHY habilitada em um database
• SQL Server – Como utilizar auditoria para mapear permissões necessárias reais em um usuário
• SQL Server – Como desativar o login “sa” minimizando impactos
• SQL Server – Como ocultar os databases para usuários não autorizados

Cuidados com as senhas dos usuários

Outro tópico de extrema importância para evitar vazamentos de dados na sua empresa é garantir a segurança das senhas dos usuários de bancos de dados. Embora isso seja óbvio na teoria, na prática vemos um grande descaso quanto à este tema.

Embora a Microsoft recomende como boa prática o uso de autenticação Windows, pois todo o controle de senha fica por conta do Active Directory (AD) ou o sistema operacional (SO), na prática os usuários de sistema quase sempre utilizam autenticação SQL Server.

Durante os atendimentos na consultoria em que trabalho, é muito comum ver usuários de banco há mais de 5 anos sem trocar a senha. Ou seja, todo mundo que já teve acesso à essa senha durante esse tempo, mesmo que já tenham saído da empresa, AINDA SABEM A SENHA. Já vi casos em que a empresa ficou mais de 10 anos sem trocar a senha do usuário principal, utilizado por TODAS as aplicações e até mesmo usuários de negócio tinham planilhas com Excel com esse usuário e senha fixos lá.. rs

Para resolver esse problema de senhas antigas, recomendo ativar a propriedade de Expiração de todos os logins, para que o próprio SQL Server se encarregue de atribuir uma validade para a senha dos usuários e os forçem a trocar a senha de forma períodica (padrão é a cada 180 dias).

Para evitar que a senha de usuários de aplicação sejam expiradas no meio do dia e impactem o ambiente, o DBA deve criar um cronograma e planejamento para trocar essas senhas de forma periódica.

Além de senhas antigas, devemos nos atentar à complexidade das senhas. Nada de 123456 em senhas de usuários do banco de dados. As senhas devem ser grandes, complexas e difíceis de serem quebradas por ataques de força bruta. Preferencialmente, utilize geradores de senhas, incluindo letras (maiúsculas e minúsculas), números, símbolos e tamanho acima de 50 caracteres.

Precisa de ajuda para identificar possíveis senhas frágeis em seu SQL Server? Veja como posso te ajudar no artigo SQL Server – Como identificar senhas frágeis, vazias ou iguais ao nome do usuário.

Criptografia de colunas com Always Encrypted

Recurso presente desde o SQL Server 2016 nas edições Express, Standard, Enterprise e Developer (Express e Standard a partir do 2016 SP1), o Always Encrypted permite criptografar determinadas colunas que possuem dados sensíveis e pessoas de clientes fisicamente. Diferente do Dynamic Data Masking, essa solução não é um simples mascaramento de dados e sim uma solução de criptografia aplicada nos dados originais, permanecendo criptografados em memória, nos arquivos físicos (MDF, LDF e NDF) e arquivos de backup.

Uma vez aplicado o Always Encrypted, apenas os usuários que possuem a chave de criptografia conseguem visualizar os dados originais. Essa é a única proteção que impede até mesmo usuários administradores do banco de dados (sysadmin) visualizem os dados originais.

Por conta de todos os ítens de segurança, essa solução é ideal para garantir a privacidade dos dados dos seus usuários, já que os dados estão sempre criptografados e nunca são trafegados de forma não-segura (plain-text), ou seja, mesmo que uma pessoa que consiga acesso aos seus arquivos de dados (MDF), log (LDF) ou backup (BAK), ela não conseguirá acessar os dados que foram criptografos por essa tecnologia, mesmo se tentar restaurar os arquivos para utilizá-los em outro ambiente.

Isso evita um cenário de vazamento de informações por acesso físico aos arquivos do banco de dados. Outro fator importante que é evitado, são vazamentos de dados internos, onde próprios colaboradores disponibilizam informações. Utilizando o Always Encrypted, eles não conseguirão acessar esses dados sensíveis mesmo com acesso completo ao banco de dados.

E por fim, esse recurso vai garantir que uma outra aplicação que esteja utilizando o mesmo servidor não consiga visualizar os dados originais.

Exemplo do Always Encrypted

Para saber mais sobre Always Encrypted, não deixe de conferir o meu artigo SQL Server 2016 – Como criptografar seus dados utilizando Always Encrypted.

Mascaramento de dados (Dynamic Data Masking)

Recurso presente a partir do SQL Server 2016, o Dynamic Data Masking permite mascarar dados de determinadas colunas do banco de dados e evitar que aplicações e usuários tenham acesso a dados sensíveis e pessoais de usuários.

Embora a melhor opção seja mascarar isso na aplicação (até porque o Dynamic Data Masking não é tão seguro assim), mascarar os dados no banco de dados é algo bem rápido de ser implementado e certamente irá dificultar acessos indevidos aos dados pessoais, tanto através de uma aplicação quanto acessos internos feitos por outros usuários, rotinas ou ferramentas.

Ao aplicar o mascaramento desses dados, estamos evitando que essa informação circule tanto para fora da empresa (numa aplicação, por exemplo) tanto dentro da empresa (uma área de BI criando um relatório, por exemplo), já que esses usuários não terão a permissão de UNMASK.

Observação: Esse mascaramento de dados não altera os dados originais, apenas mascara na exibição (SELECT).

Exemplo do Dynamic Data Masking

Para saber mais sobre Dynamic Data Masking, não deixe de conferir o meu artigo SQL Server 2016 – Mascaramento de dados com o Dynamic Data Masking (DDM).

Segurança a nível de linha – Row Level Security (RLS)

Outra feature importante do SQL Server que pode nos ajudar a diminuir a probabilidade de vazamento de informações é o Row Level Security (RLS), disponível desde o SQL Server 2016, que permite limitar os registros que serão retornados de acordo com cada usuário. Isso faz com que um gerente, por exemplo, só tenha acesso aos dados do clientes que compram naquela filial.

Esse tipo de restrição é descrita na LGPD como princípio da necessidade, que significa limitar o uso dos dados ao mínimo necessário para que se possa atingir a finalidade pretendida. Caso outra pessoa consiga acesso às credenciais do gerente desse exemplo, o escopo de clientes que ele terá acesso é muito menor do que se ele tivesse acesso à toda a base.

Resultado:

Cuidados com o SQL Injection

Não é de hoje que ataques de SQL Injection preocupam empresas em todo o mundo. Desde os anos 90 essa técnica é utilizada por atacantes para invadir sistemas, alterar e acessar dados de clientes, pedidos, etc, utilizando brechas de programação em sistemas para forçar comandos maliciosos e obter acesso direto ao banco de dados.

Essa técnica bem antiga e simples (tanto na execução quanto na correção) até hoje ainda causa muitos problemas até em grandes empresas e com a LGPD isso tende a ser um risco à privacidade dos dados de usuários, uma vez que ao utilizar o SQL Injection, um invasor pode ter acesso aos dados pessoais de todos os clientes da base, caso estes não estejam devidamente mascarados/criptografados.

Caso você queira estar em conformidade com auditorias e evitar que a sua empresa sofra com vazamentos de dados e invasões a sistemas, esse é um ponto muito crítico que deve ser verificado com urgência em todos os seus sistemas (especialmente se o sistema monta as consultas dinamicamente em uma string, sem validação de inputs e envia a string direto para o banco), uma vez que os efeitos desse tipo de ataque podem ser devastadores.

Após conversas com o especialista em segurança e também MVP, Alberto Oliveira, ele me alertou que para evitar ataques de SQL Injection do lado da aplicação, não basta apenas validação de entrada de dados e, portanto, é preciso um critério mais acurado na construção de código, podendo contar, inclusive, com um WAF para garantir proteção além do codigo.

Resultado:

Para saber mais sobre SQL Injection e saber como identificar possíveis brechas e evitar esse tipo de ataque, não deixe de conferir o meu artigo SQL Server – Como evitar SQL Injection? Pare de utilizar Query Dinâmica como EXEC(@Query). Agora..

Descoberta e classificação dos dados

Recurso muito interessante que foi disponibilizado no SQL Server Management Studio (SSMS) a partir da versão 17.5, o recurso de Descoberta e classificação dos dados (SQL Data Discovery and Classification) permite gerar um relatório com possíveis dados sensíveis identificados utilizando um algoritmo interno do SSMS, onde você define o nível de criticidade dessa informação e a que essa informação se refere, para que você pudesse identificar colunas que pudessem conter informações confidenciais ou interferir na conformidade com vários padrões (HIPAA, SOX, PCI e, é claro, GDPR).

O assistente usa um algoritmo para sugerir colunas que provavelmente causarão problemas de conformidade, mas você pode adicionar suas próprias, ajustar suas sugestões e eliminar quaisquer colunas da lista. Ele armazena essas classiciations usando propriedades estendidas; um relatório baseado em SSMS usa essa mesma informação para exibir as colunas que foram identificadas. Fora do relatório, essas propriedades não são altamente visíveis.

No SQL Server 2019, há um novo comando para esses metadados, já disponível no Banco de Dados SQL do Azure, chamado ADD SENSITIVITY CLASSIFICATION. Isso permite que você faça o mesmo tipo de assistente do SSMS, mas as informações não são mais armazenadas como extended property, e qualquer acesso a esses dados é exibido automaticamente em auditorias em uma nova coluna XML chamada data_sensitivity_information. Contém todos os tipos de informações que foram acessadas durante o evento auditado.

Criptografia na conexão (TLS)

Uma outra forma de se proteger contra eventuais vazamentos de informação é utilizando criptografia na conexão com o banco de dados e, para isso, podemos utilizar o recurso de TLS para que os dados trafegados entre o banco e o cliente não sejam disponibilizados na forma de texto simples (plain-text).

Particularmente, as empresas envolvidas no processamento de pagamentos de clientes, especialmente, devem aderir ao PCI DSS (Padrão de segurança de dados do setor de cartões de pagamento). Para o cumprimento do PCI, aplicativo corporativo precisa para começar a usar o protocolo TLS 1.2 (Transport Layer Security) antes de 30 de junho de 2018.

Antes do TLS 1.2, havia duas outras versões 1.1 e 1.0, também conhecidas como SSL (Secured Socket Layer), desenvolvidas pela Netscape. Particularmente o TLS 1.1 foi referido por muitos como SSL V3. A necessidade de mudar para o novo TLS 1.2 é abordar as vulnerabilidades colocadas pelos protocolos anteriores.

Para mover os aplicativos usando o SQL Server para o novo protocolo, precisaríamos envolver os desenvolvedores de aplicativos junto com os DBAs para fazer a transição.

Existem 2 métodos de criptografar as conexões:

• Uso de autocertificação: propenso a ataques MIM (Man-In-Middle) e deve ser usado apenas em cenários em que todos os clientes residem com o mesmo domínio.
• Certificados de autoridade de certificação: são certificados emitidos pela autoridade de certificação e devem sempre ser o método preferencial

Para saber mais sobre como configurar o TLS no seu SQL Server, recomendo a leitura deste artigo.

Azure Advanced Threat Protection

Um recurso bem legal do Azure, que se enquadra no requisito de notificar aos envolvidos e órfãos reguladores sobre vazamentos de dados, é o Azure Advanced Threat Protection, que além de possuir uma série de defesas contra potenciais ataques, te permite monitorar usuários e comportamentos destes.

O Azure ATP (Proteção Avançada contra Ameaças) é uma solução de segurança baseado em nuvem que identifica, detecta e ajuda você a investigar ameaças avançadas, identidades comprometidas e ações com informações privilegiadas mal-intencionadas direcionadas à sua organização. O Azure ATP permite aos analistas de SecOp e profissionais de segurança que lutam para detectar ataques avançados em ambientes híbridos:

• Monitorar usuários, comportamento de entidade e atividades com a análise baseada em aprendizado
• Proteger as identidades do usuário e as credenciais armazenadas no Active Directory
• Identificar e investigar atividades de usuário suspeitas e ataques avançados em toda a cadeia do ataque cibernético
• Fornecer informações claras sobre incidentes em uma linha do tempo simples para triagem rápida

Interface do Azure ATP:

Master Data Services (MDS)

Mantém dados pessoais completos e garante que as solicitações para editar, excluir, ou descontinuar o processamento de dados sejam propagadas em todo o sistema, utilizando os Master Data Services com o Microsoft SQL Server.

Utilizando o conceito de “golden record”, a ideia desse serviço é garantir uma base única de clientes e seus dados pessoais, de forma que todos os sistemas utilizem e mantenham sempre essa base atualizada. Em caso de solicitação de retificações ou exclusão dos dados por solicitação do cliente, basta aplicar essa alteração em apenas um lugar para que seja aplicadas a todos os sistemas e rotinas da empresa.

Auditoria de dados

Um dos pilares da LGPD é que toda atividade que manipule dados pessoais deve ser logada e sua empresa precisa responder à pergunta de como os dados do usuário foram coletados. Pois bem, para responder a essa questão, podemos utilizar recursos de Auditoria ou Triggers para identificar alterações de dados em tabelas e assim rastrear quando os dados de um determinado cliente foram cadastrados/alterados/excluídos na base de dados, bem como as alterações realizadas, sistema que cadastrou, hostname, IP e outras informações referentes à alteração realizada nos dados deste cliente.

Alguns artigos que podem ajudar vocês a utilizarem esses recursos:

• SQL Server – Como criar um histórico de alterações de dados para suas tabelas (logs para auditoria)
• Auditoria no SQL Server (Server Audit)
• SQL Server – Como monitorar e auditar alterações de dados em tabelas utilizando Change Data Capture (CDC)
• SQL Server 2016 – Como “viajar no tempo” utilizando o recurso Temporal Tables

Auditoria de dados no Azure SQL Database

Disponível tanto para o Azure SQL Database quanto para o Azure SQL Data Warehouse, a auditoria de banco de dados é um recurso do Portal do Azure que permite definir filtros e métricas para auditar várias informações em seus dados e os agrupa em categorias de auditoria (LoginFailed, LoginSucess, DataChanges, etc).

Mais informações nesse link.

Criptografia de arquivos com Transparent Data Encryption (TDE)

Outra solução de criptografia, esta disponível desde o SQL Server 2008 nas edições Enterprise e Developer, o Transparent Data Encryption (TDE) é um recurso que criptografa os arquivos de dados SQL Server, o que é conhecido como criptografia de dados em repouso (at rest).

Em um cenário no qual a mídia física (como unidades ou fitas de backup) é roubada, um terceiro mal-intencionado pode restaurar ou anexar o banco de dados e navegar pelos dados. Uma solução para isso é criptografar dados confidenciais no banco de dados e proteger as chaves usadas para criptografar os dados com um certificado. Isso impede que alguém sem as chaves use os dados.

Com essencialmente “um toque de mágica”, todo o conteúdo de arquivos MDF, arquivos LDF, snapshots, tempdb e backups são criptografados. A criptografia ocorre em tempo real, pois os dados são gravados da memória para o disco, e a descriptografia ocorre quando os dados são lidos do disco e movidos para a memória. A criptografia é feita no nível do banco de dados, portanto, você pode optar por criptografar o número de bancos de dados que desejar.

Always Encrypted	Transparent Data Encryption (TDE)
Nível de coluna	Nível de database
Criptografia no cliente (utilizando um driver)	Criptografia no servidor (Database Engine)
Servidor não conhece as chaves de criptografia	Servidor conhece as chaves de criptografia
Dados na memória são criptografados	Dados na memória são desprotegidos (plain-text)
Dados na rede são criptografados	Dados na rede são desprotegidos (plain-text)
Apenas os usuários com acesso à chave podem visualizar os dados originais. Nem mesmo o DBA pode visualizar os dados originais sem a chave.	O DBA pode visualizar os dados originais sem a chave
Backups e arquivos de log são criptografados	Backups e arquivos de log são criptografados
Exige alterações na aplicação (podem ser pequenas ou grandes, de acordo com o algoritmo de criptografia escolhido)	Não exige alterações na aplicação
Disponível a partir do SQL Server 2016 - Todas as edições, até Express (Express e Standard a partir do 2016 SP1)	Disponível a partir do SQL Server 2008 - Apenas Enterprise e Developer

Para saber mais sobre Transparent Data Encryption, não deixe de conferir o meu artigo SQL Server 2008 – Como criptografar seus dados utilizando Transparent Data Encryption (TDE).

Backups criptografados

Ainda falando em como armazenar os dados dos clientes, não podemos deixar de mencionar o recurso de Criptografia de backup, que, como o próprio nome sugere, aplica um algoritmo de criptografia no arquivo de backup gerado, impedindo que pessoas não autorizadas restaurem os arquivos de backup em instâncias que não possuem um certificado válido e tenham acesso aos dados originais.

Backup para Nuvem

Uma outra solução que pode melhorar a segurança da sua empresa, é utilizar o recurso de BACKUP TO URL, fazendo com que os seus backups do banco de dados sejam criados direto na nuvem da Microsoft (Azure).

Isso melhora a segurança dos seus dados ao evitar que terceiros possam ter acesso aos arquivos de backup do banco de dados, uma vez que os arquivos são gravados na nuvem e podem nem ser armazenados na rede da sua empresa, que pode estar sucetível a invasões por ataques à rede, acesso físico, vazamento de dados por parte de funcionários, etc.

Enquanto isso, a Azure possui uma equipe de segurança especializada para tratar dessa questão, inclusive com redundância de dados e barrando qualquer tipo de tentativa de ataque, além de permitir autenticação sem senha através do Azure Active Directory.

Banco na Nuvem

Um tema que é alvo de constante discussões entre profissionais de TI é com relação ao Cloud Computing, mas as pessoas estão começando a acordar sobre o quão eficiente e prático é migrar e armazenar os bancos de dados na nuvem, e com o SQL Server isso não é diferente.

O Azure oferece uma gama de recursos de segurança para evitar qualquer tipo de ataque (até mesmo de força bruta) aos seus dados, que estarão sendo protegidos por uma equipe de especialistas em Segurança da Microsoft, atuando tanto na parte física, redes, firewall e também mitigando possíveis tentativas de invasão de storages, sistema operacional e outros.

Tudo isso nos permite atender às boas práticas da LGPD, ao manter nossos dados mais difíceis de serem vazados e acessos por pessoas não autorizadas, que acabam sendo barradas por conta dos vários níveis de segurança do Azure.