Em todos os sistemas de TI em que ocorrem tarefas de negócios importantes, é importante ter um conjunto explícito de políticas e práticas e garantir que elas sejam respeitadas e seguidas.
Introdução à auditoria
Uma auditoria de sistema de Tecnologia da Informação é o exame das políticas, processos, procedimentos e práticas de uma organização em relação à infraestrutura de TI em relação a um determinado conjunto de objetivos. Uma auditoria de TI pode ser de dois tipos genéricos:
- Verificação de um conjunto de padrões em um subconjunto limitado de dados
- Verificando todo o sistema
Uma auditoria de TI pode abranger certas partes críticas do sistema, como as relacionadas a dados financeiros, a fim de oferecer suporte a um conjunto específico de regulamentos (por exemplo, SOX), ou toda a infraestrutura de segurança contra regulamentos como o novo regulamento GDPR da UE, que atende à necessidade para proteger a privacidade e define as diretrizes para o gerenciamento de dados pessoais. O exemplo SOX é do primeiro tipo descrito acima, enquanto o GDPR é do último.
O ciclo de vida da auditoria
Planejamento
O escopo de uma auditoria depende do objetivo da auditoria. O escopo pode abranger uma aplicação especial identificada por uma atividade comercial específica, como uma atividade financeira, ou toda a infraestrutura de TI que abrange segurança de sistema, segurança de dados e assim por diante. O escopo deve ser corretamente identificado de antemão como um passo inicial na fase de planejamento inicial. A organização deve fornecer ao auditor todas as informações básicas necessárias para ajudar no planejamento da auditoria. Podem ser as especificações funcionais/técnicas, diagramas de arquitetura do sistema ou qualquer outra informação solicitada.
Objetivos de controle
Com base no escopo, o auditor forma um conjunto de objetivos de controle a serem testados pela auditoria. Esses objetivos de controle são implementados por meio de práticas de gerenciamento que deveriam estar em vigor para alcançar o controle na extensão descrita pelo escopo. Os objetivos de controle estão associados aos planos de teste e juntos constituem o programa de auditoria. Com base no programa de auditoria a organização sob auditoria aloca recursos para facilitar o auditor.
Descobertas
O auditor tenta obter evidências de que todos os objetivos de controle foram atendidos. Se para algum objetivo de controle não houver tal evidência, primeiro o auditor tenta ver se existe alguma forma alternativa de a empresa lidar com o objetivo de controle específico e, caso exista, esse objetivo de controle é marcado como compensador e o auditor considera que o objetivo foi alcançado. Se, no entanto, não houver nenhuma evidência de que um objetivo foi alcançado, isso será marcado como uma descoberta . Cada achado consiste na condição, critérios, causa, efeito e recomendação. O gerente de TI deve estar em contato próximo com o auditor para ser informado de todas as possíveis constatações e certificar-se de que todas as informações solicitadas sejam compartilhadas entre a administração e o auditor para garantir que o objetivo do controle seja alcançado (e, assim, evitar a achado).
O Relatório de Avaliação
No final do processo de auditoria, o auditor redigirá um relatório de avaliação como um resumo cobrindo todas as partes importantes da auditoria, incluindo quaisquer possíveis constatações seguidas de uma declaração sobre se o objetivo foi abordado adequadamente e recomendações para eliminar o impacto das constatações.
O que é registro de auditoria e por que você deve fazer isso?
O auditor deseja ter acesso total às mudanças no software, nos dados e no sistema de segurança. Ele/ela não apenas deseja rastrear qualquer alteração nos dados de negócios, mas também rastrear alterações no organograma, na política de segurança, na definição de funções/grupos e alterações na associação de função/grupo. A maneira mais comum de realizar uma auditoria é por meio de registro. Embora no passado fosse possível passar por uma auditoria de TI sem arquivos de log, hoje é a forma preferida (se não a única).
Normalmente, o sistema de TI médio é composto por pelo menos duas camadas:
- Banco de dados
- Aplicativo (possivelmente em cima de um servidor de aplicativos)
O aplicativo mantém seus próprios logs cobrindo acesso e ações do usuário, e o banco de dados e possivelmente os sistemas do servidor de aplicativos mantêm seus próprios logs. Informações limpas e prontamente utilizáveis em arquivos de log que tenham valor comercial real do ponto de vista do auditor são chamadas de trilha de auditoria . As trilhas de auditoria diferem dos arquivos de log comuns (às vezes chamados de logs nativos) porque:
- Os arquivos de log são dispensáveis
- As trilhas de auditoria devem ser mantidas por períodos mais longos
- Os arquivos de log adicionam sobrecarga aos recursos do sistema
- A finalidade dos arquivos de log é ajudar o administrador do sistema
- O objetivo das trilhas de auditoria é ajudar o auditor
Resumimos o que foi dito acima na tabela a seguir:
| Tipo de registro | Aplicativo/Sistema | Amigável para trilha de auditoria |
|---|---|---|
| Registros de aplicativos | Aplicativo | Sim |
| Registros do servidor de aplicativos | Sistema | Não |
| Registros do banco de dados | Sistema | Não |
Os logs de aplicativos podem ser facilmente adaptados para serem usados como trilhas de auditoria. Os logs do sistema não são tão fáceis porque:
- Eles são limitados em seu formato pelo software do sistema
- Eles atuam globalmente em todo o sistema
- Eles não têm conhecimento direto sobre o contexto de negócios específico
- Eles geralmente exigem software adicional para análise/processamento off-line posterior, a fim de produzir trilhas de auditoria úteis para auditoria.
No entanto, por outro lado, os logs de aplicativos colocam uma camada de software adicional sobre os dados reais, assim:
- Tornar o sistema de auditoria mais vulnerável a bugs/configurações incorretas de aplicativos
- Criar uma possível falha no processo de registro se alguém tentar acessar dados diretamente no banco de dados ignorando o sistema de registro do aplicativo, como um usuário privilegiado ou um DBA
- Tornar o sistema de auditoria mais complexo e difícil de gerenciar e manter caso tenhamos muitos aplicativos ou muitas equipes de software.
Então, idealmente, estaríamos procurando o melhor dos dois:Ter trilhas de auditoria utilizáveis com a maior cobertura em todo o sistema, incluindo a camada de banco de dados, e configuráveis em um só lugar, para que o próprio log possa ser facilmente auditado por meio de outros ( sistema) registros.
Registro de auditoria com PostgreSQL
As opções que temos no PostgreSQL em relação ao log de auditoria são as seguintes:
- Usando o registro exaustivo ( log_statement =all )
- Escrevendo uma solução de gatilho personalizada
- Usando ferramentas padrão do PostgreSQL fornecidas pela comunidade, como
- audit-trigger 91plus (https://github.com/2ndQuadrant/audit-trigger)
- extensão pgaudit (https://github.com/pgaudit/pgaudit)
O registro exaustivo pelo menos para uso padrão em cargas de trabalho OLTP ou OLAP deve ser evitado porque:
- Produz arquivos enormes, aumenta a carga
- Não tem conhecimento interno de tabelas sendo acessadas ou modificadas, apenas imprime a instrução que pode ser um bloco DO com uma instrução concatenada enigmática
- Precisa de software/recursos adicionais para análise e processamento offline (para produzir as trilhas de auditoria) que, por sua vez, devem ser incluídos no escopo da auditoria, para serem considerados confiáveis
No restante deste artigo, tentaremos as ferramentas fornecidas pela comunidade. Vamos supor que temos esta tabela simples que queremos auditar:
myshop=# \d orders
Table "public.orders"
Column | Type | Collation | Nullable | Default
------------+--------------------------+-----------+----------+------------------------------------
id | integer | | not null | nextval('orders_id_seq'::regclass)
customerid | integer | | not null |
customer | text | | not null |
xtime | timestamp with time zone | | not null | now()
productid | integer | | not null |
product | text | | not null |
quantity | integer | | not null |
unit_price | double precision | | not null |
cur | character varying(20) | | not null | 'EUR'::character varying
Indexes:
"orders_pkey" PRIMARY KEY, btree (id)acionador de auditoria 91plus
Os documentos sobre o uso do gatilho podem ser encontrados aqui:https://wiki.postgresql.org/wiki/Audit_trigger_91plus. Primeiro, baixamos e instalamos o DDL fornecido (funções, esquema):
$ wget https://raw.githubusercontent.com/2ndQuadrant/audit-trigger/master/audit.sql
$ psql myshop
psql (10.3 (Debian 10.3-1.pgdg80+1))
Type "help" for help.
myshop=# \i audit.sqlEm seguida, definimos os gatilhos para nossa tabela pedidos usando o uso básico:
myshop=# SELECT audit.audit_table('orders');Isso criará dois gatilhos em ordens de tabela:um gatilho de linha insert_update_delere e um gatilho de instrução truncate. Agora vamos ver o que o gatilho faz:
myshop=# insert into orders (customer,customerid,product,productid,unit_price,quantity) VALUES('magicbattler',1,'some fn skin 2',2,5,2);
INSERT 0 1
myshop=# update orders set quantity=3 where id=2;
UPDATE 1
myshop=# delete from orders where id=2;
DELETE 1
myshop=# select table_name, action, session_user_name, action_tstamp_clk, row_data, changed_fields from audit.logged_actions;
-[ RECORD 1 ]-----+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
table_name | orders
action | I
session_user_name | postgres
action_tstamp_clk | 2018-05-20 00:15:10.887268+03
row_data | "id"=>"2", "cur"=>"EUR", "xtime"=>"2018-05-20 00:15:10.883801+03", "product"=>"some fn skin 2", "customer"=>"magicbattler", "quantity"=>"2", "productid"=>"2", "customerid"=>"1", "unit_price"=>"5"
changed_fields |
-[ RECORD 2 ]-----+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
table_name | orders
action | U
session_user_name | postgres
action_tstamp_clk | 2018-05-20 00:16:12.829065+03
row_data | "id"=>"2", "cur"=>"EUR", "xtime"=>"2018-05-20 00:15:10.883801+03", "product"=>"some fn skin 2", "customer"=>"magicbattler", "quantity"=>"2", "productid"=>"2", "customerid"=>"1", "unit_price"=>"5"
changed_fields | "quantity"=>"3"
-[ RECORD 3 ]-----+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
table_name | orders
action | D
session_user_name | postgres
action_tstamp_clk | 2018-05-20 00:16:24.944117+03
row_data | "id"=>"2", "cur"=>"EUR", "xtime"=>"2018-05-20 00:15:10.883801+03", "product"=>"some fn skin 2", "customer"=>"magicbattler", "quantity"=>"3", "productid"=>"2", "customerid"=>"1", "unit_price"=>"5"
changed_fields |Observe o valor de campos alterados na atualização (REGISTO 2). Há usos mais avançados do gatilho de auditoria, como excluir colunas ou usar a cláusula WHEN, conforme mostrado no documento. O gatilho de auditoria com certeza parece fazer o trabalho de criar trilhas de auditoria úteis dentro da tabela audit.logged_actions. No entanto, há algumas ressalvas:
- Nenhum SELECT (gatilhos não disparam em SELECTs) ou DDL são rastreados
- As alterações feitas por proprietários de tabelas e superusuários podem ser facilmente adulteradas
- As práticas recomendadas devem ser seguidas em relação aos usuários do aplicativo e aos proprietários do esquema do aplicativo e das tabelas
Pgaudit
O Pgaudit é a mais nova adição ao PostgreSQL no que diz respeito à auditoria. O Pgaudit deve ser instalado como uma extensão, conforme mostrado na página do github do projeto:https://github.com/pgaudit/pgaudit. O Pgaudit registra no log padrão do PostgreSQL. O Pgaudit funciona registrando-se no carregamento do módulo e fornecendo ganchos para o executorStart, executorCheckPerms, processUtility e object_access. Portanto, o pgaudit (em contraste com as soluções baseadas em gatilho, como o gatilho de auditoria discutido nos parágrafos anteriores) suporta READs (SELECT, COPY). Geralmente com pgaudit podemos ter dois modos de operação ou usá-los combinados:
- Registro de auditoria de SESSÃO
- Registro de auditoria de OBJETO
O log de auditoria de sessão suporta a maioria dos comandos DML, DDL, privilégio e misc por meio de classes:
- LER (selecionar, copiar de)
- ESCREVA (inserir, atualizar, excluir, truncar, copiar para)
- FUNCTION (chamadas de função e blocos DO)
- ROLE (conceder, revogar, criar/alterar/descartar função)
- DDL (todos os DDL, exceto aqueles em ROLE)
- MISC (descartar, buscar, checkpoint, vácuo)
A metaclasse “all” inclui todas as classes. - exclui uma classe. Por exemplo, vamos configurar o log de auditoria de sessão para todos, exceto MISC, com os seguintes parâmetros GUC em postgresql.conf:
pgaudit.log_catalog = off
pgaudit.log = 'all, -misc'
pgaudit.log_relation = 'on'
pgaudit.log_parameter = 'on'Dando os seguintes comandos (os mesmos que no exemplo do gatilho)
myshop=# insert into orders (customer,customerid,product,productid,unit_price,quantity) VALUES('magicbattler',1,'some fn skin 2',2,5,2);
INSERT 0 1
myshop=# update orders set quantity=3 where id=2;
UPDATE 1
myshop=# delete from orders where id=2;
DELETE 1
myshop=#Obtemos as seguintes entradas no log do PostgreSQL:
% tail -f data/log/postgresql-22.log | grep AUDIT:
[local] [55035] 5b03e693.d6fb 2018-05-22 12:46:37.352 EEST psql [email protected] line:7 LOG: AUDIT: SESSION,5,1,WRITE,INSERT,TABLE,public.orders,"insert into orders (customer,customerid,product,productid,unit_price,quantity) VALUES('magicbattler',1,'some fn skin 2',2,5,2);",<none>
[local] [55035] 5b03e693.d6fb 2018-05-22 12:46:50.120 EEST psql [email protected] line:8 LOG: AUDIT: SESSION,6,1,WRITE,UPDATE,TABLE,public.orders,update orders set quantity=3 where id=2;,<none>
[local] [55035] 5b03e693.d6fb 2018-05-22 12:46:59.888 EEST psql [email protected] line:9 LOG: AUDIT: SESSION,7,1,WRITE,DELETE,TABLE,public.orders,delete from orders where id=2;,<none>Observe que o texto após AUDIT:compõe uma trilha de auditoria perfeita, quase pronta para ser enviada ao auditor em formato csv pronto para planilha. Usar o log de auditoria de sessão nos dará entradas de log de auditoria para todas as operações pertencentes às classes definidas pelo parâmetro pgaudit.log em all mesas. No entanto, há casos em que desejamos que apenas um pequeno subconjunto dos dados, ou seja, apenas algumas tabelas sejam auditadas. Nesses casos, podemos preferir o log de auditoria de objetos, que nos fornece critérios refinados para tabelas/colunas selecionadas por meio do sistema de privilégios do PostgreSQL. Para começar a usar o log de auditoria de objetos, devemos primeiro configurar o parâmetro pgaudit.role que define a função de mestre que o pgaudit usará. Faz sentido não conceder a esse usuário nenhum direito de login.
CREATE ROLE auditor;
ALTER ROLE auditor WITH NOSUPERUSER INHERIT NOCREATEROLE NOCREATEDB NOLOGIN NOREPLICATION NOBYPASSRLS CONNECTION LIMIT 0;Especificamos este valor para pgaudit.role em postgresql.conf:
pgaudit.log = none # no need for extensive SESSION logging
pgaudit.role = auditorO log do Pgaudit OBJECT funcionará descobrindo se o usuário auditor é concedido (diretamente ou herdado) o direito de executar a ação especificada executada nas relações/colunas usadas em uma instrução. Portanto, se precisarmos ignorar todas as tabelas, mas tivermos registro detalhado para pedidos de tabela, esta é a maneira de fazer isso:
grant ALL on orders to auditor ;Pela concessão acima, habilitamos o log completo de SELECT, INSERT, UPDATE e DELETE em pedidos de tabela. Vamos dar mais uma vez o INSERT, UPDATE, DELETE dos exemplos anteriores e observar o log do postgresql:
% tail -f data/log/postgresql-22.log | grep AUDIT:
[local] [60683] 5b040125.ed0b 2018-05-22 14:41:41.989 EEST psql [email protected] line:7 LOG: AUDIT: OBJECT,2,1,WRITE,INSERT,TABLE,public.orders,"insert into orders (customer,customerid,product,productid,unit_price,quantity) VALUES('magicbattler',1,'some fn skin 2',2,5,2);",<none>
[local] [60683] 5b040125.ed0b 2018-05-22 14:41:52.269 EEST psql [email protected] line:8 LOG: AUDIT: OBJECT,3,1,WRITE,UPDATE,TABLE,public.orders,update orders set quantity=3 where id=2;,<none>
[local] [60683] 5b040125.ed0b 2018-05-22 14:42:03.148 EEST psql [email protected] line:9 LOG: AUDIT: OBJECT,4,1,WRITE,DELETE,TABLE,public.orders,delete from orders where id=2;,<none>Observamos que a saída é idêntica ao log de SESSION discutido acima com a diferença de que em vez de SESSION como tipo de auditoria (a string próxima a AUDIT:) agora obtemos OBJECT.
Uma ressalva com o log OBJECT é que os TRUNCATEs não são registrados. Temos que recorrer ao SESSION logging para isso. Mas neste caso acabamos obtendo toda a atividade WRITE para todas as tabelas. Há conversas entre os hackers envolvidos para tornar cada comando uma classe separada.
Outra coisa a ter em mente é que, no caso de herança, se concedermos acesso ao auditor em alguma tabela filho, e não à pai, as ações na tabela pai que se traduzem em ações nas linhas da tabela filho não serão registradas.
Além do acima, o pessoal de TI responsável pela integridade dos logs deve documentar um procedimento rigoroso e bem definido que cobre a extração da trilha de auditoria dos arquivos de log do PostgreSQL. Esses logs podem ser transmitidos para um servidor syslog externo seguro para minimizar as chances de qualquer interferência ou adulteração.
Resumo
Esperamos que este blog tenha ajudado você a entender melhor as práticas recomendadas para registro de auditoria no PostgreSQL e por que criar uma trilha de auditoria é tão importante na preparação para uma auditoria de TI. Uma trilha de auditoria fornecerá um conjunto de informações limpas e úteis que ajudarão sua auditoria a ser realizada sem problemas.
O ClusterControl pode ajudar a automatizar e gerenciar a maioria das tarefas relacionadas ao banco de dados, garantindo segurança, disponibilidade e desempenho do banco de dados, independentemente do sistema escolhido. Faça o download de uma avaliação gratuita do ClusterControl hoje mesmo para ver como sua empresa pode se beneficiar da ferramenta e das operações que ela executa. Se você ainda não o fez, não deixe de nos seguir no Twitter e LinkedIn, e assine nosso feed, e nos vemos no próximo blog.
