PostgreSQL
 sql >> Base de Dados >  >> RDS >> PostgreSQL

Auditoria do PostgreSQL usando pgAudit

A auditoria em tecnologia da informação (TI) é um processo de exame da infraestrutura de TI de uma organização para garantir a conformidade com os requisitos impostos por padrões reconhecidos ou políticas estabelecidas. As regras de proteção de dados, como as novas regulamentações do GDPR, estão se tornando cada vez mais rigorosas para proteger os dados do usuário, por isso é importante que suas auditorias de banco de dados sejam configuradas corretamente para garantir que tanto o aplicativo quanto os dados do usuário estejam protegidos contra vulnerabilidades. Nesta postagem do blog, discutiremos o pgAudit – uma ferramenta que gera os logs de auditoria necessários para facilitar a auditoria do PostgreSQL.

O que é pgAudit?

A Extensão de Auditoria do PostgreSQL, pgAudit, é uma extensão de código aberto que registra os eventos em um banco de dados PostgreSQL em um log de auditoria detalhado. Ele usa o recurso de log nativo do PostgreSQL, portanto, os logs de auditoria farão parte dos logs do PostgreSQL. A extensão é baseada no projeto 2ndQuadrant pgAudit, de autoria de Simon Riggs, Abhijit Menon-Sen e Ian Barwick, e inclui aprimoramentos de David Steele da Crunchy Data.

Por que pgAudit sobre log_statement=all?

Podemos registrar todas as instruções no PostgreSQL apenas configurando log_statement=all . Então, por que usar o pgAudit? O registro de instruções básico (usando log_statement ) listará apenas as operações executadas no banco de dados. Ele não fornecerá a capacidade de filtrar operações e os logs não estarão na formatação adequada necessária para auditoria. Além disso, o pgAudit fornece granularidade para registrar classes específicas de instruções como READ (SELECT e COPY ), WRITE (INSERT , UPDATE , DELETE , etc.), DDL etc. Além disso, ele fornece auditoria em nível de objeto onde somente as operações em relações específicas serão registradas.

Outra vantagem do pgAudit sobre o registro básico de instruções é que ele fornece os detalhes da operação executada em vez de apenas registrar a operação solicitada. Por exemplo, considere executar o bloco de código anônimo usando uma instrução DO.

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

O registro de instrução básico resultará em:

2020-12-20 23:40:11 UTC:157.230.232.139(53064):sgpostgres@test:[9091]: LOG:  statement: DO $$
        BEGIN
            EXECUTE 'CREATE TABLE import' || 'ant_table (id INT)';
        END $$;

pgAudit registrará a mesma operação que:

2020-12-20 23:40:11 UTC:157.230.232.139(53064):sgpostgres@test:[9091]: LOG:  AUDIT: SESSION,4,1,FUNCTION,DO,,,"DO $$
        BEGIN
            EXECUTE 'CREATE TABLE import' || 'ant_table (id INT)';
        END $$;",<not logged>
2020-12-20 23:40:11 UTC:157.230.232.139(53064):sgpostgres@test:[9091]: LOG:  AUDIT: SESSION,4,2,DDL,CREATE TABLE,TABLE,public.important_table,CREATE TABLE important_table (id INT),<not logged>

O acima indica claramente a funcionalidade pgAudit que registra a operação e seus internos com saída estruturada que facilita a pesquisa.
Como auditar o PostgreSQL usando pgAuditClick To Tweet

Como instalar o pgAudit?

pgAudit é uma extensão que está disponível para download no repositório PostgreSQL ou pode ser compilada e construída a partir do código-fonte. Como primeiro passo, o pacote precisa ser baixado e instalado na máquina que executa o PostgreSQL (este pacote de extensão é pré-instalado em todas as implementações do ScaleGrid PostgreSQL).

Uma vez instalado, ele precisa ser carregado no PostgreSQL. Isso é feito adicionando pgaudit para as shared_preload_libraries parâmetro de configuração. Uma reinicialização do PostgreSQL é necessária para que essa alteração de configuração seja efetivada. O próximo passo é habilitar a extensão no banco de dados executando CREATE EXTENSION pgaudit .

Agora que a extensão está pronta, precisamos ter certeza de definir os parâmetros de configuração da extensão para iniciar o registro. Isso pode ser tão simples quanto definir o parâmetro pgaudit.log para valorizar all e o pgAudit começará a fazer login em session modo.

Agora que sabemos como instalar e habilitar o pgAudit, vamos discutir os dois modos de log de auditoria que ele oferece, sessão e objeto.

Registro de auditoria de sessão

No modo de sessão, o pgAudit registrará todas as operações realizadas por um usuário. Configurando o pgaudit.log parâmetro para qualquer um dos valores definidos, exceto NONE , habilitará o log de auditoria de sessão. O pgaudit.log O parâmetro especifica as classes de instruções que serão registradas no modo de sessão. Os valores possíveis são:READ , WRITE , FUNCTION , ROLE , DDL , MISC , MISC_SET , ALL e NONE .

Definindo o pgaudit.log parâmetro para ALL registrará todas as declarações. O parâmetro pode aceitar várias classes usando uma lista separada por vírgulas e classes específicas podem ser excluídas com um sinal –. Por exemplo, se você deseja registrar todas as instruções, exceto MISC class, o valor de pgaudit.log será ALL, -MISC, -MISC_SET . Você também pode habilitar o pgAudit para criar uma entrada de log separada para cada referência de relação em uma instrução definindo pgaudit.log_relation para ligado.

Considere um exemplo de criação de uma tabela. A instrução SQL seria:

CREATE TABLE persons(ID SERIAL PRIMARY KEY, LNAME varchar(20), FNAME varchar(20));

As entradas de registro de auditoria correspondentes são:

2020-12-21 00:00:11 UTC:157.230.232.139(53178):sgpostgres@test:[11514]: LOG:  AUDIT: SESSION,5,1,DDL,CREATE SEQUENCE,SEQUENCE,public.persons_id_seq,"CREATE TABLE persons(ID SERIAL PRIMARY KEY, LNAME varchar(20), FNAME varchar(20));",<not logged>
2020-12-21 00:00:11 UTC:157.230.232.139(53178):sgpostgres@test:[11514]: LOG:  AUDIT: SESSION,5,1,DDL,CREATE TABLE,TABLE,public.persons,"CREATE TABLE persons(ID SERIAL PRIMARY KEY, LNAME varchar(20), FNAME varchar(20));",<not logged>
2020-12-21 00:00:11 UTC:157.230.232.139(53178):sgpostgres@test:[11514]: LOG:  AUDIT: SESSION,5,1,DDL,CREATE INDEX,INDEX,public.persons_pkey,"CREATE TABLE persons(ID SERIAL PRIMARY KEY, LNAME varchar(20), FNAME varchar(20));",<not logged>
2020-12-21 00:00:11 UTC:157.230.232.139(53178):sgpostgres@test:[11514]: LOG:  AUDIT: SESSION,5,1,DDL,ALTER SEQUENCE,SEQUENCE,public.persons_id_seq,"CREATE TABLE persons(ID SERIAL PRIMARY KEY, LNAME varchar(20), FNAME varchar(20));",<not logged>

Registro de auditoria de objeto

Em casos particulares, pode ser necessário auditar apenas um conjunto específico de relações. Nesses casos, usar o modo de sessão resultará apenas em um número desnecessariamente grande de logs de auditoria que não correspondem às relações necessárias. O modo de objeto é especialmente adequado para essa finalidade e pode auditar apenas um conjunto específico de relações.

O log de auditoria de objetos é obtido usando as funções do PostgreSQL. Uma função pode ser criada e atribuída as permissões para acessar apenas um conjunto específico de relações. Esta função deve ser especificada no parâmetro de configuração pgaudit.role . O modo de objeto suporta apenas SELECT , INSERT , UPDATE e DELETE declarações. As classes de instruções registradas dependem das permissões concedidas à função. Por exemplo, se a função tiver permissões para executar apenas SELECT , então somente SELECT declarações serão registradas.

Abaixo está um exemplo de log de auditoria de objeto:

Crie uma função e conceda apenas SELECT permissões. Defina o pgaudit.role para essa função e execute o SELECT Instrução SQL:

CREATE ROLE audit_person;
GRANT SELECT ON persons TO audit_person;
SET pgaudit.role = 'audit_person';
SELECT * FROM persons WHERE ID=404;

A instrução select acima será registrada como:

2020-12-21 00:27:09 UTC:157.230.232.139(54900):sgpostgres@test:[21835]: LOG:  AUDIT: OBJECT,10,1,READ,SELECT,TABLE,public.persons,select * from persons where ID=404;,<not logged>

Interessado em uma solução PostgreSQL totalmente gerenciada?


Para saber mais sobre como um provedor de DBaaS como o ScaleGrid pode ajudá-lo a gerenciar seus bancos de dados PostgreSQL, confira nossa página PostgreSQL. Veja como o ScaleGrid pode permitir que você se concentre mais no desenvolvimento de seu produto e menos no gerenciamento de bancos de dados.


Como interpretar a entrada do log de auditoria?

Até agora, fornecemos detalhes sobre a aparência da entrada do log de auditoria, agora vamos dar uma olhada no formato da entrada do log de auditoria. Cada entrada começa com o log_line_prefix mencionado para o registro do PostgreSQL e, em seguida, o restante da saída estará no formato CSV. Considere a seguinte entrada simples de log de auditoria:

2020-12-21 00:27:09 UTC:157.230.232.139(54900):sgpostgres@test:[21835]: LOG:  AUDIT: OBJECT,10,1,READ,SELECT,TABLE,public.persons,select * from persons where ID=404;,<not logged>

Na entrada acima, o valor

2020-12-21 00:27:09 UTC:157.230.232.139(54900):sgpostgres@test:[21835]: 

é do formato log_line_prefix %t:%r:%u@%d:[%p]: . O conteúdo da entrada de auditoria começa em LOG: AUDIT: valor e segue o formato CSV. O formato do valor é da forma:
AUDIT_TYPE,STATEMENT_ID,SUBSTATEMENT_ID,CLASS,COMMAND,OBJECT_TYPE,OBJECT_NAME,STATEMENT,PARAMETER

Vamos dar uma olhada em cada um dos campos um por um:

Campo Descrição Valor do exemplo de entrada de auditoria
AUDIT_TYPE Indica o modo de auditoria:SESSION ou OBJECT OBJETO
STATEMENT_ID Identificador de instrução exclusivo para cada sessão 10
SUBSTATEMENT_ID Um identificador para cada sub-instrução dentro da declaração principal 1
CLASSE Indica a classe de instruções como READ, WRITE etc que são valores definidos para o parâmetro pgaudit.log. LER
COMANDO O comando usado na instrução SQL SELECT
OBJECT_TYPE Pode ser TABLE, INDEX, VIEW, etc. TABELA
OBJECT_NAME O nome do objeto totalmente qualificado public.persons
DECLARAÇÃO A instrução real executada selecione * de pessoas onde ID=404;
PARÂMETRO Quando o pgaudit.log_parameter é definido como true, o CSV citado dos parâmetros é listado se estiver presente, ou “none” se não houver parâmetros. Quando o parâmetro pgaudit.log_parameter não estiver definido, o valor será “

Inferência

pgAudit, com todos os seus recursos, simplifica o processo de auditoria gerando o log da trilha de auditoria. Embora haja algumas ressalvas, como o registro de objetos renomeados com o mesmo nome, ainda é uma ferramenta robusta que fornece a funcionalidade necessária. No entanto, as informações de auditoria gravadas em logs podem não ser apenas ideais para o processo de auditoria – o processo de auditoria é ainda melhor quando esses logs podem ser convertidos em um esquema de banco de dados e os dados de auditoria podem ser carregados no banco de dados para que você possa consultar facilmente o em formação. É aqui que o Analisador de Log de Auditoria do PostgreSQL (pgAudit Analyze) é útil. Para obter mais informações, consulte as páginas do github do pgAudit e do pgAudit Analyze.