sql >> Base de Datos >  >> RDS >> PostgreSQL

Mejores prácticas de registro de auditoría de PostgreSQL

En todos los sistemas de TI donde se llevan a cabo tareas comerciales importantes, es importante tener un conjunto explícito de políticas y prácticas, y asegurarse de que se respeten y sigan.

Introducción a la Auditoría

Una auditoría del sistema de tecnología de la información es el examen de las políticas, los procesos, los procedimientos y las prácticas de una organización con respecto a la infraestructura de TI frente a un determinado conjunto de objetivos. Una auditoría de TI puede ser de dos tipos genéricos:

  • Comprobación con un conjunto de estándares en un subconjunto limitado de datos
  • Comprobando todo el sistema

Una auditoría de TI puede cubrir ciertas partes críticas del sistema, como las relacionadas con los datos financieros para respaldar un conjunto específico de regulaciones (por ejemplo, SOX), o toda la infraestructura de seguridad contra regulaciones como la nueva regulación GDPR de la UE que aborda la necesidad. para la protección de la privacidad y establece las pautas para la gestión de datos personales. El ejemplo SOX es del primer tipo descrito anteriormente, mientras que GDPR es del segundo.

El ciclo de vida de la auditoría

Planificación

El alcance de una auditoría depende del objetivo de la auditoría. El alcance puede cubrir una aplicación especial identificada por una actividad comercial específica, como una actividad financiera, o toda la infraestructura de TI que cubre la seguridad del sistema, la seguridad de los datos, etc. El alcance debe identificarse correctamente de antemano como un paso temprano en la fase de planificación inicial. Se supone que la organización debe proporcionar al auditor toda la información de antecedentes necesaria para ayudar con la planificación de la auditoría. Estas pueden ser las especificaciones funcionales/técnicas, los diagramas de arquitectura del sistema o cualquier otra información solicitada.

Objetivos de control

Basado en el alcance, el auditor forma un conjunto de objetivos de control para ser probados por la auditoría. Esos objetivos de control se implementan a través de prácticas de gestión que se supone que deben implementarse para lograr el control en la medida descrita por el alcance. Los objetivos de control están asociados con los planes de prueba y juntos constituyen el programa de auditoría. Basado en el programa de auditoría la organización bajo auditoría asigna recursos para facilitar el auditor.

Hallazgos

El auditor trata de obtener evidencia de que se cumplen todos los objetivos de control. Si para algún objetivo de control no existe tal evidencia, primero el auditor trata de ver si hay alguna forma alternativa en que la empresa maneje el objetivo de control específico, y en caso de que exista tal forma, entonces este objetivo de control se marca como compensador y el auditor considera que se cumple el objetivo. Sin embargo, si no hay evidencia alguna de que se haya cumplido un objetivo, entonces esto se marca como un hallazgo. . Cada hallazgo consta de la condición, criterio, causa, efecto y recomendación. El gerente de TI debe estar en estrecho contacto con el auditor para estar informado de todos los hallazgos potenciales y asegurarse de que toda la información solicitada sea compartida entre la gerencia y el auditor para asegurar que se cumpla el objetivo de control (y así evitar la hallazgo).

El informe de evaluación

Al final del proceso de auditoría, el auditor escribirá un informe de evaluación como un resumen que cubre todas las partes importantes de la auditoría, incluidos los hallazgos potenciales seguidos de una declaración sobre si el objetivo se aborda adecuadamente y recomendaciones para eliminar el impacto de los hallazgos.

¿Qué es el registro de auditoría y por qué debería hacerlo?

El auditor quiere tener pleno acceso a los cambios en el software, los datos y el sistema de seguridad. Él/ella no solo quiere poder rastrear cualquier cambio en los datos comerciales, sino también rastrear los cambios en el organigrama, la política de seguridad, la definición de roles/grupos y los cambios en la membresía del rol/grupo. La forma más común de realizar una auditoría es a través del registro. Aunque en el pasado era posible pasar una auditoría de TI sin archivos de registro, hoy es la forma preferida (si no la única).

Por lo general, el sistema de TI promedio se compone de al menos dos capas:

  • Base de datos
  • Aplicación (posiblemente encima de un servidor de aplicaciones)

La aplicación mantiene sus propios registros que cubren el acceso y las acciones de los usuarios, y la base de datos y posiblemente los sistemas del servidor de aplicaciones mantienen sus propios registros. La información limpia y fácil de usar en los archivos de registro que tiene un valor comercial real desde la perspectiva del auditor se denomina pista de auditoría. . Los registros de auditoría se diferencian de los archivos de registro ordinarios (a veces llamados registros nativos) en que:

  • Los archivos de registro son prescindibles
  • Los registros de auditoría deben mantenerse durante períodos más largos
  • Los archivos de registro agregan sobrecarga a los recursos del sistema
  • El propósito de los archivos de registro es ayudar al administrador del sistema
  • El propósito de los registros de auditoría es ayudar al auditor

Resumimos lo anterior en la siguiente tabla:

Tipo de registro Aplicación/Sistema Apto para seguimiento de auditoría
Registros de aplicaciones Aplicación Sí
Registros del servidor de aplicaciones Sistema No
Registros de la base de datos Sistema No

Los registros de la aplicación se pueden adaptar fácilmente para usarlos como registros de auditoría. Los registros del sistema no son tan fáciles porque:

  • Están limitados en su formato por el software del sistema
  • Actúan globalmente sobre todo el sistema
  • No tienen conocimiento directo sobre el contexto empresarial específico
  • Por lo general, requieren software adicional para el posterior análisis/procesamiento fuera de línea con el fin de producir registros de auditoría fáciles de usar.

Sin embargo, por otro lado, los registros de la aplicación colocan una capa de software adicional sobre los datos reales, por lo tanto:

  • Hacer que el sistema de auditoría sea más vulnerable a errores de aplicación/configuración incorrecta
  • Crear un agujero potencial en el proceso de registro si alguien intenta acceder a los datos directamente en la base de datos sin pasar por el sistema de registro de la aplicación, como un usuario privilegiado o un DBA
  • Hacer que el sistema de auditoría sea más complejo y más difícil de administrar y mantener en caso de que tengamos muchas aplicaciones o muchos equipos de software.

Por lo tanto, idealmente estaríamos buscando lo mejor de los dos:tener pistas de auditoría utilizables con la mayor cobertura en todo el sistema, incluida la capa de la base de datos, y configurables en un solo lugar, de modo que el registro en sí pueda auditarse fácilmente por medio de otros ( sistema) registros.

Registro de auditoría con PostgreSQL

Las opciones que tenemos en PostgreSQL con respecto al registro de auditoría son las siguientes:

  • Utilizando un registro exhaustivo ( log_statement =all )
  • Escribiendo una solución desencadenante personalizada
  • Mediante el uso de herramientas estándar de PostgreSQL proporcionadas por la comunidad, como
    • activador de auditoría 91plus (https://github.com/2ndQuadrant/audit-trigger)
    • extensión pgaudit (https://github.com/pgaudit/pgaudit)

Debe evitarse el registro exhaustivo, al menos para el uso estándar en cargas de trabajo OLTP u OLAP, porque:

  • Produce archivos enormes, aumenta la carga
  • No tiene conocimiento interno de las tablas a las que se accede o modifica, solo imprime la declaración que podría ser un bloque DO con una declaración concatenada críptica
  • Necesita software/recursos adicionales para el análisis y procesamiento fuera de línea (para producir los registros de auditoría) que, a su vez, deben incluirse en el alcance de la auditoría, para que se considere confiable

En el resto de este artículo, probaremos las herramientas proporcionadas por la comunidad. Supongamos que tenemos esta tabla simple 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)

activador de auditoría 91plus

Los documentos sobre el uso del disparador se pueden encontrar aquí:https://wiki.postgresql.org/wiki/Audit_trigger_91plus. Primero descargamos e instalamos el DDL provisto (funciones, 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.sql

Luego definimos los disparadores para nuestra tabla pedidos usando el uso básico:

myshop=# SELECT audit.audit_table('orders');

Esto creará dos disparadores en los pedidos de tablas:un disparador de fila insert_update_delere y un disparador de instrucción truncada. Ahora veamos qué hace el disparador:

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    |

Tenga en cuenta el valor de los campos cambiados en la actualización (REGISTRO 2). Hay usos más avanzados del disparador de auditoría, como excluir columnas o usar la cláusula WHEN como se muestra en el documento. El activador de auditoría parece hacer el trabajo de crear pistas de auditoría útiles dentro de la tabla audit.logged_actions. Sin embargo, hay algunas advertencias:

  • No se rastrean SELECT (los disparadores no se activan en SELECT) o DDL
  • Los cambios realizados por los propietarios de las tablas y los superusuarios se pueden manipular fácilmente
  • Se deben seguir las prácticas recomendadas con respecto a los usuarios de la aplicación y los propietarios del esquema y las tablas de la aplicación
Descargue el documento técnico hoy Gestión y automatización de PostgreSQL con ClusterControl Obtenga información sobre lo que necesita saber para implementar, monitorear, administrar y escalar PostgreSQLDescargar el documento técnico

Pgauditoría

Pgaudit es la última incorporación a PostgreSQL en lo que respecta a la auditoría. Pgaudit debe instalarse como una extensión, como se muestra en la página de github del proyecto:https://github.com/pgaudit/pgaudit. Pgaudit inicia sesión en el registro estándar de PostgreSQL. Pgaudit funciona registrándose al cargar el módulo y proporcionando ganchos para executorStart, executorCheckPerms, processUtility y object_access. Por lo tanto, pgaudit (a diferencia de las soluciones basadas en disparadores, como audit-trigger discutida en los párrafos anteriores) admite LECTURAS (SELECCIONAR, COPIAR). Generalmente con pgaudit podemos tener dos modos de funcionamiento o usarlos combinados:

  • Registro de auditoría de SESSION
  • Registro de auditoría de OBJECT

El registro de auditoría de sesión admite la mayoría de los comandos DML, DDL, privilegios y misceláneos a través de clases:

  • LEER (seleccionar, copiar de)
  • ESCRIBIR (insertar, actualizar, borrar, truncar, copiar a)
  • FUNCTION (llamadas a funciones y bloques DO)
  • FUNCIÓN (otorgar, revocar, crear/modificar/cancelar función)
  • DDL (todos los DDL excepto los que están en ROLE)
  • MISC (desechar, buscar, punto de control, aspirar)

La metaclase “all” incluye todas las clases. - excluye una clase. Por ejemplo, configuremos el registro de auditoría de sesión para todos excepto MISC, con los siguientes parámetros GUC en postgresql.conf:

pgaudit.log_catalog = off
pgaudit.log = 'all, -misc'
pgaudit.log_relation = 'on'
pgaudit.log_parameter = 'on'

Al dar los siguientes comandos (los mismos que en el ejemplo del gatillo)

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=#

Obtenemos las siguientes entradas en el registro de 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>

Tenga en cuenta que el texto después de AUDITORÍA:constituye una pista de auditoría perfecta, casi lista para enviarse al auditor en formato csv listo para una hoja de cálculo. El uso del registro de auditoría de sesión nos dará entradas de registro de auditoría para todas las operaciones que pertenecen a las clases definidas por el parámetro pgaudit.log en all mesas. Sin embargo, hay casos en los que solo deseamos auditar un pequeño subconjunto de los datos, es decir, solo unas pocas tablas. En tales casos, podemos preferir el registro de auditoría de objetos que nos brinda criterios detallados para las tablas/columnas seleccionadas a través del sistema de privilegios de PostgreSQL. Para comenzar a usar el registro de auditoría de objetos, primero debemos configurar el parámetro pgaudit.role que define el rol maestro que usará pgaudit. Tiene sentido no otorgar a este usuario ningún derecho de inicio de sesión.

CREATE ROLE auditor;
ALTER ROLE auditor WITH NOSUPERUSER INHERIT NOCREATEROLE NOCREATEDB NOLOGIN NOREPLICATION NOBYPASSRLS CONNECTION LIMIT 0;

Luego especificamos este valor para pgaudit.role en postgresql.conf:

pgaudit.log = none # no need for extensive SESSION logging
pgaudit.role = auditor

El registro de OBJECT de Pgaudit funcionará al encontrar si el usuario auditor se otorga (directamente o heredado) el derecho de ejecutar la acción especificada realizada en las relaciones/columnas utilizadas en una declaración. Entonces, si necesitamos ignorar todas las tablas, pero tenemos un registro detallado de los pedidos de las tablas, esta es la forma de hacerlo:

grant ALL on orders to auditor ;

Mediante la subvención anterior, habilitamos el registro completo SELECCIONAR, INSERTAR, ACTUALIZAR y ELIMINAR en los pedidos de la mesa. Demos una vez más el INSERTAR, ACTUALIZAR, ELIMINAR de los ejemplos anteriores y observemos el registro de 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 la salida es idéntica al registro de SESSION discutido anteriormente con la diferencia de que en lugar de SESSION como tipo de auditoría (la cadena al lado de AUDIT:) ahora obtenemos OBJECT.

Una advertencia con el registro de OBJECT es que los TRUNCATE no se registran. Tenemos que recurrir al registro de SESSION para esto. Pero en este caso, obtenemos toda la actividad de ESCRITURA para todas las tablas. Hay conversaciones entre los hackers involucrados para hacer de cada comando una clase separada.

Otra cosa a tener en cuenta es que, en el caso de la herencia, si OTORGAMOS acceso al auditor en alguna tabla secundaria, y no en la principal, las acciones en la tabla principal que se traducen en acciones en las filas de la tabla secundaria no se registrarán.

Además de lo anterior, las personas de TI a cargo de la integridad de los registros deben documentar un procedimiento estricto y bien definido que cubra la extracción de la pista de auditoría de los archivos de registro de PostgreSQL. Esos registros pueden transmitirse a un servidor syslog seguro externo para minimizar las posibilidades de interferencia o manipulación.

Resumen

Esperamos que este blog lo haya ayudado a comprender mejor las mejores prácticas para el registro de auditoría en PostgreSQL y por qué es tan importante crear un registro de auditoría para prepararse para una auditoría de TI. Una pista de auditoría proporcionará un conjunto de información limpia y utilizable que ayudará a que su auditoría se realice sin problemas.

ClusterControl puede ayudar a automatizar y administrar la mayoría de las tareas relacionadas con la base de datos al tiempo que garantiza la seguridad, la disponibilidad y el rendimiento de la base de datos, independientemente del sistema elegido. Descargue una versión de prueba gratuita de ClusterControl hoy mismo para ver cómo su negocio puede beneficiarse de la herramienta y las operaciones que realiza. Si aún no lo ha hecho, asegúrese de seguirnos en Twitter y LinkedIn, y suscríbase a nuestro feed, y nos vemos en el próximo blog.