Meu nome é Denis Rozhkov, sou o chefe de desenvolvimento de software na empresa 'Gazinformservice', na equipe de produto. Jatoba. A legislação e as normas corporativas impõem certas exigências à segurança do armazenamento de dados. Ninguém quer que terceiros tenham acesso a informações confidenciais, portanto, para qualquer projeto, são importantes as seguintes questões: identificação e autenticação, gerenciamento de acesso aos dados, garantia da integridade das informações no sistema, registro de eventos de segurança. Por isso, quero falar sobre alguns pontos interessantes relacionados à segurança dos SGBDs.

Este artigo foi preparado com base em uma apresentação na @Databases Meetup, organizado Soluções em Nuvem Mail.ru. Se você não quiser ler, pode assistir:

O artigo terá três partes:

• Como proteger as conexões.
• O que é auditoria de ações e como registrar o que está acontecendo do lado do banco de dados e da conexão com ele.
• Como proteger os dados dentro do próprio banco de dados e quais tecnologias existem para isso.

Três componentes da segurança dos SGBDs: proteção das conexões, auditoria de ações e proteção dos dados.

Proteção das conexões

As conexões com o banco de dados podem ser feitas diretamente ou indiretamente por meio de aplicações web. Normalmente, o usuário do lado dos negócios, ou seja, a pessoa que trabalha com o SGBD, não interage com ele diretamente.

Antes de falarmos sobre a proteção das conexões, precisamos responder a algumas perguntas importantes que determinarão como as medidas de segurança serão organizadas:

• um usuário empresarial equivale a um usuário do SGBD;
• o acesso aos dados do SGBD é fornecido apenas através da API que você controla, ou há acesso direto às tabelas;
• o SGBD está isolado em um segmento seguro, e quem e como interage com ele;
• é utilizado pooling/proxy e camadas intermediárias que podem alterar as informações sobre como a conexão está configurada e quem usa o banco de dados.

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

1. Utilize soluções de firewall para banco de dados. Uma camada adicional de proteção, no mínimo, aumentará a transparência do que está acontecendo no SGBD e, no máximo, você poderá garantir proteção adicional dos dados.
2. Utilize políticas de senha. A aplicação delas depende de como sua arquitetura está estruturada. De qualquer forma, uma única senha em um arquivo de configuração de um aplicativo web que se conecta a um SGBD não é suficiente para proteção. Existem várias ferramentas de SGBD que permitem controlar quando um usuário e uma senha precisam ser atualizados.

   Você pode ler mais sobre as funcionalidades de avaliação de usuários aqui, e também pode aprender sobre o MS SQL Vulnerability Assessment aqui. 

3. Enriqueça o contexto da sessão com informações necessárias. Se a sessão não for transparente, você não entende quem está operando dentro do SGBD; é possível complementar as informações na operação em execução, como quem está fazendo o que e por quê. Essas informações podem ser vistas na auditoria.
4. Configure SSL, se você não tiver uma separação de rede entre o SGBD e os usuários finais, ou se não estiver em uma VLAN separada. Nesses casos, é importante proteger o canal entre o consumidor e o próprio SGBD. Existem ferramentas de proteção, algumas até de código aberto.

Como isso afetará o desempenho do SGBD?

Vamos observar o exemplo do PostgreSQL para ver como o SSL impacta a carga do CPU, aumenta os tempos de resposta e reduz o TPS, e se muitos recursos serão consumidos ao habilitá-lo.

Vamos sobrecarregar o PostgreSQL usando o pgbench - um programa simples para executar testes de desempenho. Ele executa repetidamente uma sequência de comandos, possivelmente em sessões paralelas do banco de dados, e depois calcula a média de transações.

Teste 1 sem SSL e usando SSL — a conexão é estabelecida a 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 única 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"

Outras configurações:

fator de escalonamento: 1
modo da consulta: simples
número de clientes: 10
número de threads: 1
número de transações por cliente: 5000
número de transações realmente processadas: 50000/50000

Resultados do teste:

 
SEM SSL
SSL

A conexão é estabelecida a cada transação

latência média
171.915 ms
187.695 ms

tps incluindo o estabelecimento de conexões
58.168112
53.278062

tps excluindo o estabelecimento de conexões
64.084546
58.725846

CPU
24%
28%

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

latência média
6.722 ms
6.342 ms

tps incluindo o estabelecimento de conexões
1587.657278
1576.792883

tps excluindo o estabelecimento de conexões
1588.380574
1577.694766

CPU
17%
21%

Em cargas pequenas, o impacto do SSL é comparável ao erro de medição. Se o volume de dados transmitidos for muito grande, a situação pode ser diferente. Se estabelecermos uma conexão para cada transação (o que é raro, geralmente as conexões são compartilhadas entre os usuários), você terá um grande número de conexões/desconexões, e o impacto pode ser um pouco maior. Ou seja, há riscos de redução de desempenho, no entanto, a diferença não é tão grande a ponto de evitar o uso da proteção.

Observe que há uma grande diferença ao comparar os modos de operação: você trabalha dentro de uma sessão ou em sessões diferentes. Isso é claro: a criação de cada conexão consome recursos.

Tivemos um caso em que conectamos o Zabbix em modo de confiança, ou seja, não verificamos md5, e não havia necessidade de autenticação. Depois, o cliente pediu para ativar o modo de autenticação md5. Isso trouxe uma grande carga para a CPU e o desempenho caiu. Começamos a buscar caminhos para otimização. Uma das possíveis soluções para o problema é implementar a limitação de rede, criar VLANs separadas para o SGBD, adicionar configurações para que fique claro quem e de onde está se conectando e remover a autenticação. Também é possível otimizar as configurações de autenticação para reduzir os custos quando a autenticação está ativada, mas, no geral, a aplicação de diferentes métodos de autenticação impacta o desempenho e é necessário considerar esses fatores ao projetar a capacidade de computação dos servidores (hardware) para o SGBD.

Conclusão: em várias soluções, mesmo pequenos detalhes na autenticação podem impactar muito o projeto, e é ruim quando isso se torna claro apenas na implementação em produção.

Auditoria de ações

A auditoria pode não se restringir apenas ao SGBD. A auditoria é a obtenção de informações sobre o que acontece em diferentes segmentos. Pode incluir firewall de banco de dados e o sistema operacional que abriga o SGBD.

Em SGBDs empresariais de nível Enterprise, a auditoria funciona bem; em soluções open source, isso nem sempre ocorre. Veja o que existe no PostgreSQL:

• log padrão — registro de log integrado;
• extensões: pgaudit — se o registro padrão não for suficiente, você pode usar configurações separadas que atendem parte das demandas.

Complemento ao relatório no vídeo:

A registro básico de operadores pode ser garantido por meio da ferramenta padrão de logging com log_statement = all.

Isso é aceitável para monitoramento e outros usos, mas não oferece o nível de detalhamento normalmente necessário para auditoria.

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

Também deve haver a capacidade de encontrar declarações específicas que são de interesse para o auditor.

A ferramenta padrão de logging mostra o que foi solicitado pelo usuário, enquanto o pgAudit foca nos detalhes do que aconteceu quando o banco de dados executou a consulta.

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

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

DO $$
BEGIN
EXECUTE ‘CREATE TABLE import’ || ‘ant_table (id INT)’;
END $$;

O logging padrão lhe dará isso:

LOG: statement: DO $$
BEGIN
EXECUTE ‘CREATE TABLE import’ || ‘ant_table (id INT)’;
END $$;

Parece que para encontrar a tabela em questão pode ser necessário algum conhecimento de código, nos casos em que as tabelas são criadas dinamicamente.

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

É aqui que o pgAudit será útil.

Para a mesma entrada, ele gerará este output no log:

AUDIT: SESSION,33,1,FUNCTION,DO,,,«DO $$
BEGIN
EXECUTE ‘CREATE TABLE import’ || ‘ant_table (id INT)’;
END $$;"
AUDIT: SESSION,33,2,DDL,CREATE TABLE,TABLE,public.important_table,CREATE TABLE important_table (id INT)

O bloco DO é registrado, assim como o texto completo CREATE TABLE com o tipo de operador, tipo de objeto e nome completo, facilitando a busca.

Ao registrar operadores SELECT e DML, o pgAudit pode ser configurado para registrar uma entrada separada para cada relação referida no operador.

Não é necessário análise sintática para encontrar todos os operadores que se referem a uma tabela específica (*)».

Como isso afetará o desempenho do SGBD?

Vamos realizar testes com auditoria completa habilitada e ver como isso afeta o desempenho do PostgreSQL. Iremos ativar o log máximo do banco de dados em todos os parâmetros.

Na configuração, mudamos quase nada, mas, importante, ativamos o modo debug5 para obter o máximo de informações.

postgresql.conf

log_destination = ‘stderr’
logging_collector = on
log_truncate_on_rotation = on
log_rotation_age = 1d
log_rotation_size = 10MB
log_min_messages = debug5
log_min_error_statement = debug5
log_min_duration_statement = 0
debug_print_parse = on
debug_print_rewritten = on
debug_print_plan = on
debug_pretty_print = ativado
log_checkpoints = ativado
log_connections = ativado
log_disconnections = ativado
log_duration = ativado
log_hostname = ativado
log_lock_waits = ativado
log_replication_commands = ativado
log_temp_files = 0
log_timezone = ‘Europa/Moscovo’

No banco de dados PostgreSQL com os parâmetros 1 CPU, 2,8 GHz, 2 GB de RAM, 40 GB de HDD, realizamos três testes de carga, utilizando os seguintes 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

Resultados dos testes:

Sem registro
Com registro

Tempo total para preenchimento do BD
43,74 seg
53,23 seg

RAM
24%
40%

CPU
72%
91%

Teste 1 (50 conexões)

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

Transações/seg
123
54

Latência média
405 ms
925 ms

Teste 2 (150 conexões com 100 permitidas)

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

Transações/seg
136
52

Latência média
550 ms
1432 ms

Sobre os tamanhos

Tamanho do BD
2251 MB
2262 MB

Tamanho dos logs do BD
0 MB
4587 MB

Em suma: uma auditoria completa não é muito boa. A quantidade de dados gerada pela auditoria será igual ou até maior que a própria base de dados. Essa quantidade de registro gerada durante a operação do DBMS é um problema comum em produção.

Vamos observar outros parâmetros:

• A velocidade não muda muito: sem registro — 43,74 seg, com registro — 53,23 seg.
• O desempenho de RAM e CPU diminuirá, pois é necessário criar um arquivo de auditoria. Isso é evidente também em ambientes de produção.

Ao aumentar o número de conexões, naturalmente, os indicadores piorarão um pouco.

Nas corporações, a auditoria é ainda mais complexa:

• há muitos dados;
• a auditoria é necessária não apenas via syslog no SIEM, mas também em arquivos: caso algo aconteça com o syslog, deve haver um arquivo próximo à base que armazene os dados;
• para a auditoria, é necessário um espaço separado para não prejudicar a I/O dos discos, já que ocupa muito espaço;
• às vezes, funcionários de segurança da informação exigem normas estaduais, solicitando a identificação conforme essas normas.

Restrição de acesso aos dados

Vamos olhar para as tecnologias que são usadas para proteger dados e controlar o acesso a eles em bancos de dados comerciais e de código aberto.

O que pode ser usado em geral:

1. Criptografia e ofuscação de procedimentos e funções (Wrapping) — ou seja, ferramentas e utilitários que transformam código legível em ilegível. Contudo, depois não será possível alterar ou refatorar de volta. Essa abordagem é às vezes necessária, pelo menos no lado do DBMS — a lógica das restrições de licença ou a lógica de autorização é criptografada especificamente no nível de procedimentos e funções.
2. A limitação de visibilidade de dados por linha (RLS) é quando diferentes usuários veem uma tabela, mas com composições de linhas diferentes, ou seja, alguns dados não podem ser mostrados a certos usuários no nível das linhas.
3. A edição de dados exibidos (Masking) é quando os usuários em uma coluna de tabela veem os dados ou apenas asteriscos, ou seja, para alguns usuários a informação estará oculta. A tecnologia determina o que mostrar a cada usuário considerando seu nível de acesso.
4. A segmentação de acesso Security DBA/Application DBA/DBA refere-se, na verdade, à limitação de acesso ao próprio SGBD, o que significa que 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 open source, mas muitas em SGBDs comerciais. Elas são necessárias quando há muitos usuários com acesso aos próprios servidores.
5. Limitação de acesso a arquivos no nível do sistema de arquivos. É possível conceder permissões e privilégios de acesso a diretórios, de forma que cada administrador tenha acesso apenas aos dados necessários.
6. O acesso obrigatório e a limpeza de memória são tecnologias raramente utilizadas.
7. A criptografia de ponta a ponta diretamente no SGBD é a criptografia do lado do cliente com gerenciamento de chaves do lado do servidor.
8. Criptografia de dados. Por exemplo, a criptografia de colunas é quando você utiliza um mecanismo que criptografa uma coluna específica do banco de dados.

Como isso afeta o desempenho do SGBD?

Vamos analisar o exemplo de criptografia de colunas no PostgreSQL. Há um módulo pgcrypto que permite armazenar em formato criptografado campos selecionados. Isso é útil quando apenas alguns dados têm valor. Para ler os campos criptografados, o cliente envia a chave de descriptografia, o servidor descriptografa os dados e os fornece ao cliente. Sem a chave, ninguém conseguirá acessar seus dados.

Vamos realizar um teste com pgcrypto. Vamos criar uma tabela com dados criptografados e outra com dados comuns. Abaixo estão os comandos para criar as tabelas; na primeira linha, um comando útil – a criação da extensão com o registro do 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'));

Em seguida, tentaremos extrair dados de cada tabela e analisaremos os tempos de execução.

Extração da 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

Cronômetro ligado.

  id | text1 | text2
——+——-+——-
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,386 ms

Extração da 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

Cronômetro ligado.

  id | decrypt | decrypt
——+—————+————
1 | x31 | x31
2 | x32 | x32
3 | x33 | x33
…
999 | x393939 | x393939
1000 | x31303030 | x31303030
(1000 linhas)

Tempo: 50,203 ms

Resultados do teste:

 
Sem criptografia
Pgcrypto (decrypt)

Extração de 1000 linhas
1,386 ms
50,203 ms

CPU
15%
35%

RAM
 
+5%

A criptografia afeta drasticamente o desempenho. É visível que o tempo aumentou, pois as operações de descriptografia de dados criptografados (e a descriptografia geralmente está envolta na sua lógica) exigem recursos significativos. Portanto, a ideia de criptografar todas as colunas que contêm dados pode resultar em uma queda de desempenho.

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

Quando uma coluna inteira para todos os usuários tem uma única chave (mesmo que não para todos, mas para um conjunto limitado de clientes), isso nem sempre é uma boa prática. É exatamente por isso que se começou a implementar criptografia de ponta a ponta, e nos SGBDs começaram a ser considerados métodos de criptografia de dados tanto do lado do cliente quanto do servidor, surgiram os famosos armazéns de chaves — produtos separados que garantem o gerenciamento de chaves do lado do SGBD.

Exemplo de criptografia em MongoDB

Mecanismos de segurança em SGBDs comerciais e open source

Funções
Tipo
Política de Senhas
Auditoria
Proteção do código-fonte de procedimentos e funções
RLS
Criptografia

Oracle
Comercial
+
+
+
+
+

MsSql
Comercial
+
+
+
+
+

Jatoba
Comercial
+
+
+
+
extensões

PostgreSQL
Gratuito
extensões
extensões
—
+
extensões

MongoDb
Gratuito
—
+
—
—
Disponível apenas no MongoDB Enterprise

A tabela não é de forma alguma completa, mas a situação é a seguinte: em produtos comerciais, questões de segurança são abordadas há muito tempo, em open source, geralmente utilizam-se algumas extensões para segurança, muitas funções estão em falta, e às vezes é necessário adicionar algo. Por exemplo, as políticas de senhas — em PostgreSQL existem várias extensões.1, 2, 3, 4, 5), que implementam políticas de senha, mas, na minha opinião, nenhuma atende a todas as necessidades do segmento corporativo nacional.

O que fazer se não há nada do que você precisa?? Например, хочется использовать определенную СУБД, в которой нет функций, которые требует заказчик.

Nesse caso, você pode usar soluções de terceiros que funcionam com diferentes SGBDs, como 'Cripto DB' ou 'Garda DB'. Se estamos falando sobre soluções do segmento nacional, eles conhecem os padrões nacionais melhor do que no open source.

A segunda opção é desenvolver o que você precisa, implementando em nível de procedimentos o acesso aos dados e a criptografia no aplicativo. No entanto, a conformidade com os padrões nacionais será mais complexa. Mas, em geral, você pode ocultar os dados como necessário, armazená-los no SGBD e depois recuperá-los e descriptografá-los conforme necessário, diretamente no nível do aplicativo. Ao fazer isso, pense também em como proteger esses algoritmos no aplicativo. Na nossa opinião, isso deve ser feito no nível do SGBD, pois funcionará mais rápido dessa forma.

Esta apresentação foi feita pela primeira vez na @Databases Meetup by Mail.ru Cloud Solutions. Veja vídeo outras apresentações e inscreva-se para receber atualizações de eventos no Telegram Em torno do Kubernetes no Mail.ru Group.

O que mais ler sobre o assunto:

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

Fonte: habr.com