Meu nome é Denis Rozhkov, sou chefe de desenvolvimento de software na empresa Gazinformservice, na equipe de produto Jatobá. A legislação e os regulamentos corporativos impõem certos requisitos para a segurança do armazenamento de dados. Ninguém quer que terceiros tenham acesso a informações confidenciais, por isso as seguintes questões são importantes para qualquer projeto: identificação e autenticação, gerenciamento de acesso aos dados, garantia da integridade das informações no sistema, registro de eventos de segurança. Portanto, quero falar sobre alguns pontos interessantes em relação à segurança do SGBD.

O artigo foi elaborado com base em palestra no @DatabasesMeetup, organizado Soluções em nuvem Mail.ru. Se não quiser ler, você pode assistir:

O artigo terá três partes:

• Como proteger conexões.
• O que é uma auditoria de ações e como registrar o que está acontecendo no banco de dados e se conectar a ele.
• Como proteger os dados do próprio banco de dados e quais tecnologias estão disponíveis para isso.

Três componentes da segurança do SGBD: proteção de conexão, auditoria de atividades e proteção de dados

Protegendo suas conexões

Você pode se conectar ao banco de dados direta ou indiretamente por meio de aplicativos da web. Via de regra, o usuário empresarial, ou seja, quem trabalha com o SGBD, interage com ele de forma indireta.

Antes de falar em proteção de conexões, é preciso responder questões importantes que determinam como as medidas de segurança serão estruturadas:

• Um usuário empresarial é equivalente a um usuário DBMS?
• se o acesso aos dados do DBMS é fornecido apenas por meio de uma API controlada por você ou se as tabelas são acessadas diretamente;
• se o SGBD está alocado em um segmento protegido separado, quem interage com ele e como;
• se são usadas camadas de pooling/proxy e intermediárias, o que pode alterar informações sobre como a conexão é construída e quem está usando o banco de dados.

Agora vamos ver quais ferramentas podem ser usadas para proteger conexões:

1. Use soluções de classe de firewall de banco de dados. Uma camada adicional de proteção aumentará, no mínimo, a transparência do que está acontecendo no SGBD e, no máximo, você poderá fornecer proteção adicional aos dados.
2. Use políticas de senha. Seu uso depende de como sua arquitetura é construída. De qualquer forma, uma senha no arquivo de configuração de uma aplicação web que se conecta ao SGBD não é suficiente para proteção. Existem várias ferramentas de DBMS que permitem controlar se o usuário e a senha requerem atualização.

   Você pode ler mais sobre as funções de classificação do usuário aqui, você também pode descobrir mais sobre Avaliação de vulnerabilidades do MS SQL aqui. 

3. Enriqueça o contexto da sessão com as informações necessárias. Se a sessão for opaca, você não entende quem está trabalhando no SGBD dentro de sua estrutura, você pode, dentro da estrutura da operação que está sendo executada, adicionar informações sobre quem está fazendo o quê e por quê. Essas informações podem ser visualizadas na auditoria.
4. Configure o SSL se você não tiver uma separação de rede entre o DBMS e os usuários finais; ele não está em uma VLAN separada. Nesses casos, é imprescindível proteger o canal entre o consumidor e o próprio SGBD. Ferramentas de segurança também estão disponíveis em código aberto.

Como isso afetará o desempenho do SGBD?

Vejamos o exemplo do PostgreSQL para ver como o SSL afeta a carga da CPU, aumenta os tempos e diminui o TPS e se consumirá muitos recursos se você ativá-lo.

Carregar PostgreSQL usando pgbench é um programa simples para executar testes de desempenho. Ele executa uma única sequência de comandos repetidamente, possivelmente em sessões paralelas de banco de dados, e então calcula a taxa média de transação.

Teste 1 sem SSL e usando SSL — a conexão é estabelecida para cada transação:

pgbench.exe --connect -c 10 -t 5000 "host=192.168.220.129 dbname=taskdb user=postgres sslmode=require 
sslrootcert=rootCA.crt sslcert=client.crt sslkey=client.key"

vs

pgbench.exe --connect -c 10 -t 5000 "host=192.168.220.129 dbname=taskdb user=postgres"

Teste 2 sem SSL e usando SSL — todas as transações são realizadas em uma conexão:

pgbench.exe -c 10 -t 5000 "host=192.168.220.129 dbname=taskdb user=postgres sslmode=require
sslrootcert=rootCA.crt sslcert=client.crt sslkey=client.key"

vs

pgbench.exe -c 10 -t 5000 "host=192.168.220.129 dbname=taskdb user=postgres"

Outros ajustes:

scaling factor: 1
query mode: simple
number of clients: 10
number of threads: 1
number of transactions per client: 5000
number of transactions actually processed: 50000/50000

Resultados do teste:

 
SEM SSL
SSL

Uma conexão é estabelecida para cada transação

média de latência
171.915 ms
187.695 ms

tps incluindo conexões estabelecendo
58.168112
53.278062

tps excluindo conexões estabelecendo
64.084546
58.725846

CPU
24%
28%

Todas as transações são realizadas em uma conexão

média de latência
6.722 ms
6.342 ms

tps incluindo conexões estabelecendo
1587.657278
1576.792883

tps excluindo conexões estabelecendo
1588.380574
1577.694766

CPU
17%
21%

Em cargas leves, a influência do SSL é comparável ao erro de medição. Se a quantidade de dados transferidos for muito grande, a situação pode ser diferente. Se estabelecermos uma conexão por transação (isso é raro, normalmente a conexão é compartilhada entre usuários), você tem um grande número de conexões/desconexões, o impacto pode ser um pouco maior. Ou seja, pode haver riscos de diminuição de desempenho, porém, a diferença não é tão grande a ponto de não utilizar proteção.

Observe que há uma grande diferença se você comparar os modos de operação: você está trabalhando na mesma sessão ou em sessões diferentes. Isso é compreensível: recursos são gastos na criação de cada conexão.

Tivemos um caso em que conectamos o Zabbix em modo confiável, ou seja, o md5 não foi verificado, não houve necessidade de autenticação. Em seguida, o cliente solicitou a ativação do modo de autenticação MD5. Isso sobrecarregou a CPU e o desempenho caiu. Começamos a procurar maneiras de otimizar. Uma das soluções possíveis para o problema é implementar restrições de rede, criar VLANs separadas para o SGBD, adicionar configurações para deixar claro quem está se conectando de onde e remover a autenticação. Você também pode otimizar as configurações de autenticação para reduzir custos ao habilitar a autenticação, mas em geral, o uso de diferentes métodos de autenticação afeta o desempenho e exige que esses fatores sejam levados em consideração ao projetar o poder computacional dos servidores (hardware) para o SGBD.

Conclusão: em várias soluções, mesmo pequenas nuances na autenticação podem afetar muito o projeto e é ruim quando isso fica claro apenas quando implementado em produção.

Auditoria de ação

A auditoria não pode ser apenas DBMS. Uma auditoria consiste em obter informações sobre o que está acontecendo em diferentes segmentos. Pode ser um firewall de banco de dados ou o sistema operacional no qual o SGBD é construído.

Em SGBDs comerciais de nível empresarial, tudo está bem com auditoria, mas em código aberto - nem sempre. Aqui está o que o PostgreSQL tem:

• log padrão - registro integrado;
• extensões: pgaudit - se o registro padrão não for suficiente para você, você pode usar configurações separadas que resolvem alguns problemas.

Adição ao relatório no vídeo:

"O registro de instruções básicas pode ser fornecido por um recurso de registro padrão com log_statement = all.

Isto é aceitável para monitoramento e outros usos, mas não fornece o nível de detalhe normalmente exigido para auditoria.

Não basta ter uma lista de todas as operações realizadas no banco de dados.

Também deverá ser possível encontrar declarações específicas que sejam de interesse do auditor.

O log padrão mostra o que o usuário solicitou, enquanto o pgAudit se concentra nos detalhes do que aconteceu quando o banco de dados executou a consulta.

Por exemplo, o auditor pode querer verificar se uma tabela específica foi criada dentro de uma janela de manutenção documentada.

Isso pode parecer uma tarefa simples com auditoria básica e grep, mas e se você fosse apresentado a algo como este exemplo (intencionalmente confuso):

FAZER$$
INÍCIO
EXECUTAR 'importação CREATE TABLE' || 'ant_table(idint)';
FIM$$;

O registro padrão fornecerá o seguinte:

LOG: instrução: DO $$
INÍCIO
EXECUTAR 'importação CREATE TABLE' || 'ant_table(idint)';
FIM$$;

Parece que encontrar a tabela de interesse pode exigir algum conhecimento de código nos casos em que as tabelas são criadas dinamicamente.

Isto não é o ideal, pois seria preferível simplesmente pesquisar pelo nome da tabela.

É aqui que o pgAudit se torna útil.

Para a mesma entrada, produzirá esta saída no log:

AUDITORIA: SESSÃO,33,1,FUNÇÃO,DO,,,"DO $$
INÍCIO
EXECUTAR 'importação CREATE TABLE' || 'ant_table(idint)';
FIM$$;"
AUDITORIA: SESSÃO,33,2,DDL,CREATE TABLE,TABLE,public.important_table,CREATE TABLE important_table (id INT)

Não apenas o bloco DO é registrado, mas também o texto completo do CREATE TABLE com tipo de instrução, tipo de objeto e nome completo, facilitando a busca.

Ao registrar instruções SELECT e DML, o pgAudit pode ser configurado para registrar uma entrada separada para cada relacionamento referenciado na instrução.

Nenhuma análise é necessária para encontrar todas as instruções que tocam uma tabela específica(*). "

Como isso afetará o desempenho do SGBD?

Vamos fazer testes com a auditoria completa habilitada e ver o que acontece com o desempenho do PostgreSQL. Vamos habilitar o registro máximo do banco de dados para todos os parâmetros.

Não alteramos quase nada no arquivo de configuração, o mais importante é ativar o modo debug5 para obter o máximo de informações.

postgresql.conf

log_destination = 'stderr'
logging_collector = ativado
log_truncate_on_rotation = ativado
log_rotation_age = 1d
log_rotation_size = 10 MB
log_min_messages= depurar5
log_min_error_statement= depurar5
log_min_duration_statement = 0
debug_print_parse = ativado
debug_print_rewrite = ativado
debug_print_plan = ativado
debug_pretty_print = ativado
log_checkpoints = ativado
log_connections = ativado
log_disconnections = ativado
duração_log = ativado
log_hostname = ativado
log_lock_waits = ativado
log_replication_commands = ativado
log_temp_files = 0
log_timezone = 'Europa/Moscou'

Em um SGBD PostgreSQL com parâmetros de 1 CPU, 2,8 GHz, 2 GB de RAM, 40 GB de HDD, realizamos três testes de carga usando os comandos:

$ pgbench -p 3389 -U postgres -i -s 150 benchmark
$ pgbench -p 3389 -U postgres -c 50 -j 2 -P 60 -T 600 benchmark
$ pgbench -p 3389 -U postgres -c 150 -j 2 -P 60 -T 600 benchmark

Resultado dos testes:

Sem registro
Com registro

Tempo total de preenchimento do banco de dados
43,74 seg
53,23 seg

roubo
24%
40%

CPU
72%
91%

Teste 1 (50 conexões)

Número de transações em 10 minutos
74169
32445

Transações/s
123
54

Latência Média
405 ms
925 ms

Teste 2 (150 conexões com 100 possíveis)

Número de transações em 10 minutos
81727
31429

Transações/s
136
52

Latência Média
550 ms
1432 ms

Sobre tamanhos

Tamanho do banco de dados
2251 MB
2262 MB

Tamanho do log do banco de dados
0 MB
4587 MB

Resumindo: uma auditoria completa não é muito boa. Os dados da auditoria serão tão grandes quanto os dados do próprio banco de dados, ou até mais. A quantidade de log gerada ao trabalhar com um SGBD é um problema comum na produção.

Vejamos outros parâmetros:

• A velocidade não muda muito: sem registro - 43,74 segundos, com registro - 53,23 segundos.
• O desempenho da RAM e da CPU será prejudicado, pois você precisa gerar um arquivo de auditoria. Isso também é perceptível na produtividade.

À medida que o número de conexões aumenta, naturalmente, o desempenho irá deteriorar-se ligeiramente.

Nas corporações com auditoria é ainda mais difícil:

• há muitos dados;
• a auditoria é necessária não só através do syslog no SIEM, mas também em arquivos: se algo acontecer com o syslog, deve haver um arquivo próximo ao banco de dados onde os dados são salvos;
• é necessária uma prateleira separada para auditoria para não desperdiçar discos de E/S, pois ocupa muito espaço;
• Acontece que os funcionários de segurança da informação precisam de padrões GOST em todos os lugares, exigem identificação estadual.

Restringindo o acesso aos dados

Vejamos as tecnologias usadas para proteger dados e acessá-los em SGBDs comerciais e de código aberto.

O que você geralmente pode usar:

1. Criptografia e ofuscação de procedimentos e funções (Wrapping) - isto é, ferramentas e utilitários separados que tornam o código legível ilegível. É verdade que ele não pode ser alterado nem refatorado novamente. Essa abordagem às vezes é necessária, pelo menos no lado do SGBD - a lógica das restrições de licença ou lógica de autorização é criptografada precisamente no nível do procedimento e da função.
2. Limitar a visibilidade dos dados por linhas (RLS) ocorre quando diferentes usuários veem uma tabela, mas nela há uma composição diferente de linhas, ou seja, algo não pode ser mostrado para alguém no nível da linha.
3. A edição dos dados exibidos (Mascaramento) é quando os usuários de uma coluna da tabela veem os dados ou apenas asteriscos, ou seja, para alguns usuários as informações serão fechadas. A tecnologia determina a qual usuário é mostrado o quê com base em seu nível de acesso.
4. Segurança DBA/Aplicação O controle de acesso DBA/DBA trata, antes, de restringir o acesso ao próprio SGBD, ou seja, os funcionários de segurança da informação podem ser separados dos administradores de banco de dados e administradores de aplicativos. Existem poucas tecnologias desse tipo em código aberto, mas existem muitas delas em SGBDs comerciais. Eles são necessários quando há muitos usuários com acesso aos próprios servidores.
5. Restringir o acesso aos arquivos no nível do sistema de arquivos. Você pode conceder direitos e privilégios de acesso aos diretórios para que cada administrador tenha acesso apenas aos dados necessários.
6. Acesso obrigatório e limpeza de memória - essas tecnologias raramente são usadas.
7. A criptografia ponta a ponta diretamente do SGBD é a criptografia do lado do cliente com gerenciamento de chaves no lado do servidor.
8. Criptografia de dados. Por exemplo, a criptografia colunar ocorre quando você usa um mecanismo que criptografa uma única coluna do banco de dados.

Como isso afeta o desempenho do SGBD?

Vejamos o exemplo de criptografia colunar no PostgreSQL. Existe um módulo pgcrypto que permite armazenar campos selecionados de forma criptografada. Isto é útil quando apenas alguns dados são valiosos. Para ler os campos criptografados, o cliente transmite uma chave de descriptografia, o servidor descriptografa os dados e os devolve ao cliente. Sem a chave, ninguém pode fazer nada com seus dados.

Vamos testar com pgcrypto. Vamos criar uma tabela com dados criptografados e dados regulares. Abaixo estão os comandos para criação de tabelas, logo na primeira linha há um comando útil - criando a própria extensão com registro de SGBD:

CREATE EXTENSION pgcrypto;
CREATE TABLE t1 (id integer, text1 text, text2 text);
CREATE TABLE t2 (id integer, text1 bytea, text2 bytea);
INSERT INTO t1 (id, text1, text2)
VALUES (generate_series(1,10000000), generate_series(1,10000000)::text, generate_series(1,10000000)::text);
INSERT INTO t2 (id, text1, text2) VALUES (
generate_series(1,10000000),
encrypt(cast(generate_series(1,10000000) AS text)::bytea, 'key'::bytea, 'bf'),
encrypt(cast(generate_series(1,10000000) AS text)::bytea, 'key'::bytea, 'bf'));

A seguir, vamos tentar fazer uma amostra de dados de cada tabela e observar os tempos de execução.

Selecionando de uma tabela sem função de criptografia:

psql -c "timing" -c "select * from t1 limit 1000;" "host=192.168.220.129 dbname=taskdb
user=postgres sslmode=disable" > 1.txt

O cronômetro está ativado.

  identificação | texto1 | texto2
——+——-+——-
1 | 1 | 1
2 | 2 | 2
3 | 3 | 3
...
997 | 997 | 997
998 | 998 | 998
999 | 999 | 999
1000 | 1000 | 1000
(1000 linhas)

Tempo: 1,386ms

Seleção de uma tabela com função de criptografia:

psql -c "timing" -c "select id, decrypt(text1, 'key'::bytea, 'bf'),
decrypt(text2, 'key'::bytea, 'bf') from t2 limit 1000;"
"host=192.168.220.129 dbname=taskdb user=postgres sslmode=disable" > 2.txt

O cronômetro está ativado.

  identificação | descriptografar | descriptografar
——+—————+————
1 | x31 | x31
2 | x32 | x32
3 | x33 | x33
...
999 | x393939 | x393939
1000 | x31303030 | x31303030
(1000 linhas)

Tempo: 50,203ms

Resultados do teste:

 
Sem criptografia
Pgcrypto (descriptografar)

Amostra de 1000 linhas
1,386 ms
50,203 ms

CPU
15%
35%

roubo
 
+ 5%

A criptografia tem um grande impacto no desempenho. Pode-se observar que o tempo aumentou, uma vez que as operações de descriptografia de dados criptografados (e a descriptografia geralmente ainda está envolvida em sua lógica) requerem recursos significativos. Ou seja, a ideia de criptografar todas as colunas que contêm alguns dados acarreta uma diminuição no desempenho.

No entanto, a criptografia não é uma solução mágica que resolve todos os problemas. Os dados descriptografados e a chave de descriptografia durante o processo de descriptografia e transmissão dos dados estão localizados no servidor. Portanto, as chaves podem ser interceptadas por alguém que tenha acesso total ao servidor de banco de dados, como um administrador do sistema.

Quando existe uma chave para toda a coluna para todos os usuários (mesmo que não para todos, mas para clientes de um conjunto limitado), isso nem sempre é bom e correto. É por isso que eles começaram a fazer criptografia ponta a ponta, no SGBD começaram a considerar opções para criptografar dados no lado do cliente e do servidor, e surgiram esses mesmos armazenamentos de cofre de chaves - produtos separados que fornecem gerenciamento de chaves no SGBD lado.

Um exemplo dessa criptografia no MongoDB

Recursos de segurança em DBMS comerciais e de código aberto

funções
tipo
Política de Senha
Auditoria
Protegendo o código-fonte de procedimentos e funções
RLS
Criptografia

Oracle
comercial
+
+
+
+
+

MSSql
comercial
+
+
+
+
+

Jatobá
comercial
+
+
+
+
extensões

PostgreSQL
Gratuito
extensões
extensões
-
+
extensões

MongoDbGenericName
Gratuito
-
+
-
-
Disponível apenas no MongoDB Enterprise

A tabela está longe de estar completa, mas a situação é a seguinte: nos produtos comerciais os problemas de segurança já foram resolvidos há muito tempo, no código aberto, via de regra, algum tipo de add-on é usado para segurança, faltam muitas funções , às vezes você precisa adicionar algo. Por exemplo, políticas de senha – o PostgreSQL tem muitas extensões diferentes (1, 2, 3, 4, 5), que implementam políticas de senhas, mas, na minha opinião, nenhuma delas cobre todas as necessidades do segmento corporativo nacional.

O que fazer se você não tiver o que precisa em lugar nenhum? Por exemplo, você deseja usar um SGBD específico que não possui as funções exigidas pelo cliente.

Então você pode usar soluções de terceiros que funcionam com diferentes SGBDs, por exemplo, Crypto DB ou Garda DB. Se estamos falando de soluções do segmento doméstico, então eles conhecem melhor os GOSTs do que o código aberto.

A segunda opção é escrever você mesmo o que você precisa, implementar o acesso aos dados e a criptografia no aplicativo no nível do procedimento. É verdade que será mais difícil com GOST. Mas, em geral, você pode ocultar os dados conforme necessário, colocá-los em um SGBD, recuperá-los e descriptografá-los conforme necessário, diretamente no nível do aplicativo. Ao mesmo tempo, pense imediatamente em como você protegerá esses algoritmos no aplicativo. Em nossa opinião, isso deve ser feito no nível do SGBD, pois funcionará mais rápido.

Este relatório foi apresentado pela primeira vez em Encontro @Databases por Mail.ru Cloud Solutions. Olhar vídeo outras apresentações e inscreva-se para anúncios de eventos no Telegram Sobre Kubernetes no Grupo Mail.ru.

O que mais ler sobre o assunto:

1. Mais que Ceph: armazenamento em bloco na nuvem MCS.
2. Como escolher um banco de dados para um projeto para não ter que escolher novamente.

Fonte: habr.com