La auditoría es el seguimiento y registro de las acciones de la base de datos de usuarios seleccionados. Por lo general, se usa para investigar actividades sospechosas o monitorear y recopilar datos sobre actividades específicas de la base de datos. Por ejemplo, el administrador de la base de datos puede recopilar estadísticas sobre qué tablas se actualizan, cuántas operaciones se realizan o cuántos usuarios simultáneos se conectan en momentos determinados.
En esta publicación de blog, cubriremos los aspectos fundamentales de la auditoría de nuestros sistemas de bases de datos de código abierto, especialmente MySQL, MariaDB, PostgreSQL y MongoDB. Este artículo está dirigido a los ingenieros de DevOps que comúnmente tienen menos experiencia o exposición en las mejores prácticas de cumplimiento de auditoría y buen gobierno de datos cuando administran la infraestructura principalmente para los sistemas de bases de datos.
Auditoria de estados de cuenta
Auditoría de sentencias MySQL
MySQL tiene el registro general de consultas (o general_log), que básicamente registra lo que está haciendo mysqld. El servidor escribe información en este registro cuando los clientes se conectan o desconectan y registra cada instrucción SQL recibida de los clientes. El registro general de consultas puede ser muy útil para la resolución de problemas, pero en realidad no está diseñado para una auditoría continua. Tiene un gran impacto en el rendimiento y solo debe habilitarse durante intervalos de tiempo cortos. Hay otras opciones para usar las tablas performance_schema.events_statements* o el complemento de auditoría en su lugar.
Auditoría de declaraciones de PostgreSQL
Para PostgreSQL, puede habilitar log_statment en "todos". Los valores admitidos para este parámetro son none (off), ddl, mod y all (todas las declaraciones). Para "ddl", registra todas las declaraciones de definición de datos, como las declaraciones CREATE, ALTER y DROP. Para "mod", registra todas las declaraciones DDL, además de declaraciones de modificación de datos como INSERT, UPDATE, DELETE, TRUNCATE y COPY FROM.
Probablemente necesite configurar los parámetros relacionados como log_directory, log_filename, logging_collector y log_rotation_age, como se muestra en el siguiente ejemplo:
log_directory = 'pg_log'
log_filename = 'postgresql-%Y-%m-%d_%H%M%S.log'
log_statement = 'all'
logging_collector = on
log_rotation_age = 10080 # 1 week in minutes Los cambios anteriores requieren un reinicio de PostgreSQL, así que planee cuidadosamente antes de aplicarlos a su entorno de producción. A continuación, puede encontrar los registros actuales en el directorio pg_log. Para PostgreSQL 12, la ubicación es /var/lib/pgsql/12/data/pg_log/ . Tenga en cuenta que los archivos de registro tienden a crecer mucho con el tiempo y pueden ocupar mucho espacio en el disco. También puede usar log_rotation_size en su lugar si tiene espacio de almacenamiento limitado.
Auditoría de extractos de MongoDB
Para MongoDB, hay 3 niveles de registro que pueden ayudarnos a auditar las declaraciones (operaciones u operaciones en términos de MongoDB):
-
Nivel 0:este es el nivel predeterminado del generador de perfiles donde el generador de perfiles no recopila ningún dato. Mongod siempre escribe operaciones más largas que el umbral slowOpThresholdMs en su registro.
-
Nivel 1:recopila datos de perfiles solo para operaciones lentas. Por defecto, las operaciones lentas son aquellas de menos de 100 milisegundos. Puede modificar el umbral para operaciones "lentas" con la opción de tiempo de ejecución slowOpThresholdMs o el comando setParameter.
-
Nivel 2:recopila datos de perfiles para todas las operaciones de la base de datos.
Para registrar todas las operaciones, configure db.setProfilingLevel(2, 1000), donde debe perfilar todas las operaciones con operaciones que toman más de los milisegundos definidos, en este caso, es 1 segundo (1000 ms) . La consulta para buscar en la colección de perfiles del sistema todas las consultas que demoraron más de un segundo, ordenadas por marca de tiempo descendente será. Para leer las operaciones, podemos usar la siguiente consulta:
mongodb> db.system.profile.find( { millis : { $gt:1000 } } ).sort( { ts : -1 } )Además, existe el proyecto Mongotail, que simplifica el proceso de creación de perfiles de operaciones con una herramienta externa en lugar de consultar directamente la colección de perfiles.
Tenga en cuenta que no se recomienda ejecutar una auditoría completa de estados de cuenta en los servidores de bases de datos de producción porque normalmente presenta un impacto significativo en el servicio de la base de datos con un enorme volumen de registro. La forma recomendada es usar un complemento de auditoría de base de datos (como se muestra más abajo), que proporciona una forma estándar de producir registros de auditoría que a menudo se requieren para cumplir con las certificaciones gubernamentales, financieras o ISO.
Auditoría de privilegios para MySQL, MariaDB y PostgreSQL
La auditoría de privilegios audita los privilegios y el control de acceso a los objetos de la base de datos. El control de acceso garantiza que los usuarios que acceden a la base de datos estén positivamente identificados y puedan acceder, actualizar o eliminar los datos a los que tienen derecho. El ingeniero de DevOps suele pasar por alto esta área, lo que hace que el privilegio excesivo sea un error común al crear y otorgar un usuario de base de datos.
Ejemplos de privilegios excesivos son:
-
Los hosts de acceso del usuario están permitidos desde un rango muy amplio, por ejemplo, otorgando host de usuario [email protected]' %', en lugar de una dirección IP individual.
-
Privilegios administrativos que se asignan a usuarios de base de datos no administrativos, por ejemplo, se asigna un usuario de base de datos para la aplicación con privilegio SUPER o RELOAD.
-
Falta de control de recursos contra cualquier tipo de uso excesivo como Conexiones máximas de usuario, Consultas máximas por hora o Conexiones por hora.
-
Permite que usuarios específicos de la base de datos también accedan a otros esquemas.
Para MySQL, MariaDB y PostgreSQL, puede realizar una auditoría de privilegios a través del esquema de información consultando las tablas relacionadas con la concesión, el rol y los privilegios. Para MongoDB, use la siguiente consulta (requiere la acción viewUser para otras bases de datos):
mongodb> db.getUsers( { usersInfo: { forAllDBs: true } } )ClusterControl proporciona un buen resumen de los privilegios asignados a un usuario de la base de datos. Vaya a Administrar -> Esquemas y usuarios -> Usuarios y obtendrá un informe de los privilegios de los usuarios, junto con opciones avanzadas como Requiere SSL, Conexiones máximas por hora, etc.
ClusterControl admite la auditoría de privilegios para MySQL, MariaDB y PostgreSQL bajo el mismo usuario interfaz.
Auditoría de objetos de esquema
Los objetos de esquema son estructuras lógicas creadas por los usuarios. Ejemplos de objetos de esquema son tablas, índices, vistas, rutinas, eventos, procedimientos, funciones, activadores y otros. Básicamente, los objetos que contienen datos o pueden consistir solo en una definición. Por lo general, uno auditaría los permisos asociados con los objetos del esquema para detectar configuraciones de seguridad deficientes y comprender la relación y las dependencias entre los objetos.
Para MySQL y MariaDB, hay information_schema y performance_schema que podemos usar para auditar básicamente los objetos del esquema. Performance_schema tiene un poco de profundidad en la instrumentación como sugiere su nombre. Sin embargo, MySQL también incluye un esquema sys desde la versión 5.7.7, que es una versión fácil de usar de performance_schema. Todas estas bases de datos son directamente accesibles y consultables por los clientes.
Extensiones/complementos de auditoría de base de datos
La forma más recomendada de realizar una auditoría de declaraciones es mediante el uso de un complemento o extensión de auditoría, creado específicamente para la tecnología de base de datos en uso. MariaDB y Percona tienen su propia implementación de complemento de auditoría, que es un poco diferente del complemento de auditoría de MySQL disponible en MySQL Enterprise. Los registros de auditoría incluyen información sobre la operación auditada, el usuario que realiza la operación y la fecha y hora de la operación. Los registros se pueden almacenar en una tabla de diccionario de datos, denominada seguimiento de auditoría de la base de datos, o en archivos del sistema operativo, denominado seguimiento de auditoría del sistema operativo.
Para PostgreSQL, existe pgAudit, una extensión de PostgreSQL que proporciona un registro detallado de sesión y/o auditoría de objetos a través de la función de registro estándar de PostgreSQL. Es básicamente una versión mejorada de la función log_statement de PostgreSQL con la capacidad de buscar y consultar fácilmente los datos capturados para su auditoría siguiendo el registro de auditoría estándar.
MongoDB Enterprise (de pago) y Percona Server para MongoDB (gratis) incluyen una función de auditoría para instancias de mongod y mongos. Con la auditoría habilitada, el servidor generará mensajes de auditoría que se pueden registrar en syslog, consola o archivo (formato JSON o BSON). En la mayoría de los casos, es preferible iniciar sesión en el archivo en formato BSON, donde el impacto en el rendimiento es menor que en JSON. Este archivo contiene información sobre diferentes eventos de usuario, incluida la autenticación, fallas de autorización, etc. Consulte la documentación de Auditoría para obtener más detalles.
Registros de auditoría del sistema operativo
También es importante configurar los registros de auditoría del sistema operativo. Para Linux, la gente comúnmente usaría auditd. Auditd es el componente de espacio de usuario del sistema de auditoría de Linux y es responsable de escribir registros de auditoría en el disco. La visualización de los registros se realiza con las utilidades ausearch o aureport. La configuración de las reglas de auditoría se realiza con la utilidad auditctl o modificando los archivos de reglas directamente.
Los siguientes pasos de instalación son nuestra práctica común al configurar cualquier tipo de servidor para uso de producción:
$ yum -y install audit # apt install auditd python
$ mv /etc/audit/rules.d/audit.rules /etc/audit/rules.d/audit.rules.ori
$ cd /etc/audit/rules.d/
$ wget https://gist.githubusercontent.com/ashraf-s9s/fb1b674e15a5a5b41504faf76a08b4ae/raw/2764bf0e9bf25418bb86e33c13fb80356999d220/audit.rules
$ chmod 640 audit.rules
$ systemctl daemon-reload
$ systemctl start auditd
$ systemctl enable auditd
$ service auditd restartTenga en cuenta que el reinicio de la última línea del servicio auditd es obligatorio porque audit no funciona muy bien al cargar reglas con systemd. Sin embargo, aún se requiere systemd para monitorear el servicio auditd. Durante el inicio, auditctl lee las reglas en /etc/audit/audit.rules. El propio demonio de auditoría tiene algunas opciones de configuración que el administrador puede desear personalizar. Se encuentran en el archivo auditd.conf.
La siguiente línea es un resultado tomado de un registro de auditoría configurado:
$ ausearch -m EXECVE | grep -i 'password' | head -1
type=EXECVE msg=audit(1615377099.934:11838148): argc=7 a0="mysql" a1="-NAB" a2="--user=appdb1" a3="--password=S3cr3tPassw0rdKP" a4="-h127.0.0.1" a5="-P3306" a6=2D6553484F5720474C4F42414C205641524941424C4553205748455245205641524941424C455F4E414D4520494E20282776657273696F6E272C202776657273696F6E5F636F6D6D656E74272C2027646174616469722729Como puede ver en lo anterior, es fácil detectar una contraseña de texto claro para MySQL ("--password=S3cr3tPassw0rdKP") usando la utilidad ausearch capturada por auditd. Este tipo de descubrimiento y auditoría es vital para proteger nuestra infraestructura de base de datos, donde una contraseña de texto no cifrado es inaceptable en un entorno seguro.
Reflexiones finales
El registro o seguimiento de auditoría es un aspecto vital que los ingenieros de DevOps suelen pasar por alto cuando administran infraestructuras y sistemas, y mucho menos el sistema de base de datos, que es un sistema muy crítico para almacenar datos sensibles y confidenciales. Cualquier exposición o violación de sus datos privados puede ser extremadamente dañina para el negocio y nadie querría que eso sucediera en la era actual de la tecnología de la información.
