Para activar la auditoría y que los datos se almacenen en la base de datos, ejecutamos el siguiente comando:
```sql
ALTER SYSTEM SET audit_trail=db scope=spfile;
```
Para comprobar que se ha activado correctamente, ejecutamos el siguiente comando:
```sql
SELECT name, value FROM v$parameter WHERE name like 'audit_trail';
```
![audit_trail](https://i.imgur.com/juhQKXU.png)
Para activar la auditoría de los intentos de acceso exitosos al sistema, ejecutamos el siguiente comando:
```sql
AUDIT CREATE SESSION WHENEVER SUCCESSFUL;
```
Ahora, tras acceder a la base de datos con el usuario restaurante (de una práctica anterior), haciendo la siguiente consulta, puedo ver que se ha almacenado la información del acceso:
```sql
SELECT OS_USERNAME, USERNAME, EXTENDED_TIMESTAMP, ACTION_NAME FROM DBA_AUDIT_SESSION;
## Realiza un procedimiento en PL/SQL que te muestre los accesos fallidos junto con el motivo de los mismos, transformando el código de error almacenado en un mensaje de texto comprensible. Contempla todos los motivos posibles para que un acceso sea fallido
La auditoría de grano fino (FGA) es como una versión extendida de la auditoría estándar. Registra los cambios en datos muy concretos a nivel de columna.
Para realizar la auditoría de grano fino, primero tengo que crear una política de auditoría:
Las operaciones by access se auditan por cada acceso a la base de datos, mientras que las operaciones by session se auditan por cada sesión de usuario. Por ejemplo, si un usuario realiza 10 accesos a la base de datos, se auditarán 10 operaciones by access, mientras que si realiza 10 accesos en una misma sesión, se auditarán 1 operación by session.
La sintaxis es la siguiente:
```sql
AUDIT [operación] [tabla] BY [usuario] BY {ACCESS | SESSION};
## Documenta las diferencias entre los valores db y db, extended del parámetro audit_trail de ORACLE. Demuéstralas poniendo un ejemplo de la información sobre una operación concreta recopilada con cada uno de ellos
Ambos parámetros indican que la auditoría está activada. La diferencia es que el parámetro db guarda la información en la tabla de auditoría, mientras que el parámetro db, extended guarda la información en la tabla de auditoría y en el archivo de alerta.
Para cambiar el parámetro, utilizo el siguiente comando:
```sql
ALTER SYSTEM SET audit_trail = db, extended SCOPE = SPFILE;
```
Reinicio la base de datos y compruebo que el parámetro se ha cambiado correctamente, con la consulta del ejercicio 1:
No se puede realizar un procedimiento ya que los accesos fallidos no está registrado en la base de datos, sino en el archivo de log, sin embargo, en el propio archivo de log, se encuentran explicados con palabras y en español, el objetivo final del procedimiento:
No puede realizar auditorías de todo lo que realiza un usuario, sino de tablas. Por lo que voy a especificar las tablas del usuario scott que quiero auditar:
Para realizar las auditorías, es necesario instalar la versión Enterprise. La documentación de instalación oficial se encuentra en el siguiente enlace [https://www.mongodb.com/docs/manual/tutorial/install-mongodb-enterprise-on-debian/](https://www.mongodb.com/docs/manual/tutorial/install-mongodb-enterprise-on-debian/). Una vez instalado podemos hacer lo siguiente:
- Habilitar las auditorías en el syslog desde la consola: