Oracle Database Security Jaime Amigo P. 2006, Santiago - Chile
Objetivos Después de completar esta lección, usted deberá saber lo siguiente: Aplicar El Principio del Menor Privilegio Administrar cuentas por defecto Implementar características de seguridad estandares Auditar la actividad de una base de datos 2
Seguridad de Base de Datos Un sistema seguro, garantiza la confidencialidad de los datos que contiene. Hay varios aspectos de seguridad a considerar: Acceso restringido a datos y servicios Autentificación de usuarios Monitoreo de actividades sospechosas Seguridad de Base de Datos Oracle Database 10g provee el mejor framework de la industria para un sistema seguro, pero para que ese framework sea efectivo, el administrador de base de datos debe seguir buenas prácticas y estar continuamente monitoreando la actividad de la base de datos. Restringiendo acceso a los Datos y Servicios Todos los usuarios no pueden tener acceso a todos los datos. Dependiendo que está almacenado en la base de datos, restringuir el acceso a ellos debe ser una regla inquebrantable. Estas restricciones pueden ser por requerimientos del negocio, por restricciones legales o espectativas del cliente. Información de tarjetas de crédito, datos de salud, información de identidad, etc, deben ser protegidas para acceso no autorizado. Oracle provee una gran gama de controles para limitar el acceso a una base de datos. Restricción de acceso debe aplicar el Principio del Menor Privilegio. 3
Seguridad de Base de Datos (continuación) Autentificación de usuarios Para hacer cumplir los controles de acceso el sistema debe primero saber quién esta tratando de accesar los datos. Una autentificación comprometida puede hacer el resto de las otras precauciones de seguridad, inútiles. La manera mas simple de autentificar un usuario es a través del método de que este provee una password. Es preciso asegurarse que las password sigan cientras reglas simples para incrementar el nivel de seguridad de un sistema. Existen métodos de autentificación más robusta que solicitan al usuario algo, por ejemplo un certificado PKI (Public Key Infrastructure). Otro método de autentificación fuerte es utilizar un dispositivo biométrico como huella digital (fingerprint), lector de iris o diafragma (iris scan), patrones de la estructura del hueso (bone structure pattern), otros. Oracle soporta técnicas avanzadas de autentificación tales como token, biometría, certificados digitales y certificados basados a través de la opción Advanced Security del RDBMS. Las cuentas de usuario que no están en uso, deben ser bloqueadas pues comprometen la seguridad del sistema. Monitoreo para actividades sospechosas Usuario debidamente autentificados y autorizados algunas veces pueden comprometer la seguridad del sistema. Identificar actividades irregulares como un empleado que repentinamente comience a consultar grandes cantidades de información de tarjetas de créditos u otra información sensible en una empresa, puede ser el primer paso para detectar el hurto de información. Oracle provee un rico juego de herramientas de auditoria para seguir la pista a usuarios e identificar actividades sospechosas. 4
Aplicando el Principio del Menor Privilegio Proteger el diccionario de datos Revocar privilegios PUBLIC innecesarios Restringir acceso a directorios a usuarios Limitar a los usuarios con privilegio de administrador Restringir autentificación de bases de datos remotas Aplicando el Principio del Menor Privilegio Oracle Database 10g es líder en la industria en seguridad. Sin embargo, para maximizar las características de seguridad ofrecidas en cualquier ambiente de negocios, es imperativo que Oracle Database 10g a si mismo sea protegido y adecuadamente configurado. El uso adecuado de las características de seguridad internas y buenas prácticas de seguridad ayudaran a proteger la base de datos de ataques y proveer un ambiente seguro para operar. Practica del Principio del Menor Privilegio Este principio indica que un usuario solo debe tener los privilegios mínimos que sea requeridos para completar una tareas eficientemente. Esto permite reducir la posibilidad que usuarios accidentalmente o maliciosamente pueden modificar o ver datos para los cuales ellos no tienen los privilegios respectivos. La mayoria de la organizaciones de IT desean para sus ambientes de producción una política cerrada o basada en la Política del Menor Privilegio. 5
Proteger el Diccionario de Datos Proteger el diccionario de datos, para asegurarse este parámetro debe estar inicializado en FALSE: O7_DICTIONARY_ACCESSIBILITY = FALSE Esto previene que usuarios con privilegio de sistemas ANY TABLE puedan accesar tablas del diccionario de datos. Un seteo a FALSE previene que el usuario SYS se logee de una manera difernte a SYSDBA El valor por defecto es FALSE. Si usted lo encuentra seteado a TRUE, asegurese de tener una buena razón de negocio para ello. Proteger el Diccionario de Datos Usuarios que no son administradores no necesitan tener acceso al diccionario de datos, pero pueden accederlo si se le otorgan privilegios de sistema * ANY TABLE tal como, SELECT ANY TABLE o UPDATE ANY TABLE. EL diccionario de datos contiene información con la que un usuario malicioso podría alterar o dañar el sistema. Para excluir las tables del diccionario de datos del privilegio * ANY TABLE, el parámetro de inicialización O7_DICTIONARY_ACCESSIBILITY debe estar en FALSE. Si existe un usuario no administrador que requiera por alguna razón, acceder al diccionario de datos, se le puede otrogar acceso: Usando el comando estándar GRANT para permitir el objetivo específico del diccionario de datos a accesar Otorgando un privilegio de sistema SELECT ANY DICTIONARY para dar acceso al diccionario de datos completo En Oracle 10g y Oracle 9i, el valor del parámetro O7_DICTIONARY_ACCESSIBILITY es FALSE; sin embargo, en Oracle 8i e inferior, era TRUE; por lo tanto, si dispone de una versión más vieja es preciso setear a FALSE dicho parámetro para habilitar la protección del diccionario de datos. Precacución: Si este parámetro esta en TRUE, cualquier usuario con privilegio de sistema DROP ANY TABLE podría maliciosamente o accidentalmente borrar parte del diccionario de datos de una base de datos. Algunas instalaciones tienen por defecto todo habilitado y solo cierran accesos en casos que se requieran. Esto es sencillamente una muy mala práctica que pone en riesgo la seguridad de la información. Típicamente nos encontramos con este tipo de configuraciones en ambientes de aprendizaje o académicos. 6
Revocar los Privilegios PUBLIC innecesarios Revocar todos los privilegios y roles innecesarios de la base de datos del grupo PUBLIC. Muchos packages construidos tienen otorgrados EXECUTE TO PUBLIC. Execute sobre los siguientes package pueden ser revocados desde PUBLIC: UTL_SMTP UTL_TCP UTL_HTTP UTL_FILE DBMS_OBFUSCATION_TOOLKIT Ejemplo: SQL> REVOKE execute ON utl_file FROM PUBLIC; Revocar los Privilegios PUBLIC innecesarios Revoque todos aquellos privilegios y roles innecesarios asociados a los usuarios que sean de acceso PUBLIC, ya que este tipo de grant son peligros. Privilegios como EXECUTE sobre package PL/SQL podrían habilitar a un usuario a ejecutar procedimientos que usted no desea realiza, por tanto, se deben otorgar los mínimos privilegios para la acción que ellos requieren sobre la base de datos. Muchos de los paquetes DBMS_* y UTL_* son instalados con el privilegio EXECUTE y grant PUBLIC. Siguiendo el principio del mínimo privilegio, debe revocar esos permisos para algunos paquetes mas sensitivos y otorgar permisos de ejecución individuales a usuarios que requieran de dichos paquetes. Restringir el acceso a privilegios públicos afecta a todos los usuarios.. Los paquetes mas poderosos que pueden ser mal utilizados son: UTL_SMTP: Permite enviar mensajes vía mail usando la base de datos como Servidor de Correo SMTP (Simple Mail Transfer Protocol). Dejar este procedimiento con grant PUBLIC permitiría a un usuario no autorizado intercambiar mensajes de mail. UTL_TCP: Permite establecer conexiones de red entre el servidor de base de datos y cualquier otro servicio de red. Asi, datos arbitrariamente pueden ser enviados entre el servidor de base de datos y cualquier servicio de red de espera.. 7
Revoke Unnecessary Privileges from PUBLIC (continued) UTL_HTTP: Permite que el servidor de base de datos solicite y recupere datos via HTTP (HyperText Transfer Protocol). Otorgando un gran PUBLIC a este paquete, permite enviar datos en formularios HTML (HyperText Markup Language) a sitios web maliciosos. UTL_FILE: Si esta configurado incorrectamente, permite acceso a nivel de texto a cualquier archivo del sistema operativo del servidor. A menudo, cuando esta correctamente configurado, este paquete no distingue entre llamadas de aplicaciones. Una aplicación con acceso a UTL_FILE puede escribir datos arbitrariamente dentro de la misma localización que es escrita por otra aplicación. DBMS_OBFUSCATION_TOOLKIT: Encripta datos. Generalmente, la mayoria de los usuarios no tiene privilegios para encriptar datos porque la encriptación de datos no es recuperable si los datos cifrados no son almacenados y administrados con seguridad. Este es un paquete muy útil para aplicaciones que lo utilizan, pero requiere una adecuada configuración para ser usado en forma segura. Por tanto, es absolutamente necesario revocar los grant PUBLIC y otorgarlo solo a aquellos usuarios o roles cuando lo requieran. Listando Objetos Ejecutables Públicos Use la siguiente consulta para listar los objetos propiedad del usuario SYS que tiene privilegio de EXECUTE con grant PUBLIC: SQL> SELECT table_name 2 FROM dba_tab_privs 3 WHERE owner='sys' 4 AND privilege = 'EXECUTE' 5 AND grantee='public' 6 / TABLE_NAME -------------------- AGGXMLIMP AGGXMLINPUTTYPE... XMLTYPEEXTRA XMLTYPEPI 437 rows selected. SQL> 8
Restringiendo Acceso a Directorios del Sistema Operativos a Usuarios Parámetro de configuración UTL_FILE_DIR: Indica cuáles directorios del SO estan disponibles para PL/SQL Habilita a usuarios de bases de datos a leer y escribir desde diretorios sobre el servidor de bases de datos Restringiendo Acceso a Directorios del Sistema Operativo a Usuarios El parámetro de configuración UTL_FILE_DIR indica en cual directorio del sistema operativo paquetes PL/SQL pueden leer o escribir. Por defecto, no hay directorios accesibles. Los privilegios del sistema operativo siguen aplicables. Los directorios que el usuario levanto en la base de datos solo pueden ser accesibles hasta que no se setee UTL_FILE_DIR. Para especificar múltiples directorios, el listado de directorios debe estar entre comillas y separado por comas (como se indica abajo). Este no es un parámetro dinámico y la instancia debe ser reiniciada para que los cambios tengan efecto. Recuerde no usar variables de ambiente en el path del directorio. La instancia no chequea que existan los directorios, por tanto, debe cambiar el parámetro o crear el directorio posteriormente. Todos los usuarios de PL/SQL pueden leer o escribir en los directorios especificados, todos los usuarios de PL/SQL deben confiar con la información en los directorios especificados por este parámtro. Los directorios listados deben también ser accesibles por la instancia Oracle. Precaución: Nunca setee UTL_FILE_DIR = *, porque esto habilita acceso a todos los directorios accesible por la instancia Oracle, incluyendo a los directorios de datos y redo log. 9
Limitar Usuarios con Privilegios Administrativos Restringir los siguientes tipos de privilegios: Grants de privilegios de sistema y objetos Conexiones privilegiadas, SYSDBA y SYSOPER Privilegios tipo DBA, tales como DROP ANY TABLE Permisos de tiempo de ejecución Ejemplo: Listar todos los usuarios con rol DBA: SQL> SELECT grantee FROM dba_role_privs 2 WHERE granted_role = 'DBA'; GRANTEE ------------------------------ SYS SYSTEM Limitar Usuarios con Privilegios Administrativos No otorge a usuarios de bases de datos mas privilegios que los necesarios. Al implementar el Principio del Mínimo Privilegio, restringir los siguientes tipos de privilegios: Gran a privilegios de Sistemas y Objetos Conexiones privilegiadas SYS, tales como SYSDBA y SYSOPER Otros privilegios de tipo DBA, tales como DROP ANY TABLE Es importante determinar muy bien qué privilegios necesita cada usuario o grupo de estos, para otorgar sólo aquellos que son necesarios a su función dentro de la base de datos. Ver los usuarios que les han sido otorgados los privilegios de SYSDBA o SYSOPER, use la siguiente consulta: SQL> SELECT * FROM V$PWFILE_USERS; USERNAME SYSDBA SYSOPER ------------------------------ ------ ------- SYS TRUE TRUE Hay muy pocas razones para que algún usuario que no sea SYS tenga privilegios de SYSDBA. 10
Deshabilitar Autentificación Remota de Sistema Operativo Autentificación remota debe ser solo usada cuando se confia en todos los clientes para autentificar a los usuarios Proceso de Autentificación Remota: El usuario de base de datos es autentificado externamente. El sistema remoto autentifica al usuario. El usuario ingresa a la base de datos sin autentificaciones adicionales. Para deshabilitar, asegurese que el siguiente parámetro de inicialización esta seteado por defecto como sigue: REMOTE_OS_AUTHENT = FALSE Deshabilitar Autentificación Remota de Sistema Operativo Esta característica esta deshabilitada por defecto. Cuando se habilita (TRUE), la autentificación externa de usuarios de base de datos, esta se delega al sistema remoto. Esto significa que la instancia confía implícitamente que los usuarios han sido autentificados adecuadamente en el cliente PC y no solicita una nueva credencial de autentificación. Los usuarios pueden conectarse a la base de datos sin proveer una password. El username del sistema operativo debe ser el mismo que el de la base de datos para poder ser autentificado externamente. La mayoría de los sistemas operativos remotos, especialmente las conexsiones de usuarios desde PC s, no debería ejecutar autentificación confiando en ellos. Estos es una pobre practica de seguridad que debería modificarse. 11
Administrar Cuentas de Usuarios por Defecto DBCA expira y bloquea todas las cuentes excepto: SYS SYSTEM SYSMAN DBSNMP Para una base de datos creada manualmente, bloquee y experire las cuentas no utilizadas. Administrar Cuentas de Usuario por Defecto Oracle Database 10g se instala con un número de cuentas de usuarios por defecto. Estas cuentas estan pensadas para almacenar datos, PL/SQL propio, Código de Objetos Java con el propósito de no permitir conexiones a la base de datos. Cuando el DBCA es usado para crear una base de datos, automáticamente bloquea y expira todas las cuentas por defecto de usuarios de la base de datos, excepto las siguientes: SYS SYSTEM DBSNMP SYSMAN Oracle soporta la creación de base de datos a través de scripts. Muchas aplicaciones esperan que la base de datos este configurada de cierta manera y se automatiza la creación a través de un script. Las bases de datos creadas de este forma, no bloquean las cuentas por defecto. Valide que las cuentas no bloqueadas estan siendo usadas por conexiones a la base de datos y no simplemente para almacenar datos. 12
Implementar Características Estandares de Seguridad de Password Historial de Password Cuentas Bloquedas Usuario Seteo de Perfiles Expiración y Envejecimiento de Password Verificación de Password Implementando Características Estandares de Seguridad de Password La administración de password Oracle esta implementada con perfiles de usuarios. Los perfiles proveen muchas características de seguridad incluyendo: Account locking: Habilita el bloqueo automático de cuentas cuando el usuario falla un número especificado de intentos al momento de logearse al sistema. Password aging and expiration: Habilita a la password de usuario a tener un tiempo de activación o duración, después de dicho periodo la password expira y debe ser cambiada. Password history: Chequea la nuevas nueva password y verifica que no sean reusadas en un periodo de tiempo o un número específico de password a retener. Password complexity verification: Hace un chequeo de la complejidad de la password y verifica que reuna ciertas características. El chequeo permite que las password sean lo suficientemente complejas para proveer protección de intrusos que puedan querer acceder al sistema. Recuerde que cuando se crea un nuevo usuario a ellos se les asigna el perfil DEFAULT a menos que otro perfil les sea asignado. 13
Bloqueo de Cuentas Parámetro FAILED_LOGIN_ATTEMPTS PASSWORD_LOCK_TIME Descripción Número de intents fallidos de conexión antes de bloquearse la cuenta Número de días que la cuenta esta bloqueda despues que el número de intentos fallidos se ha superado Bloqueo de Cuentas Oracle bloquea automáticamente cuentas después que el usuario ha fallado su logeo en el valor señalado en FAILED_LOGIN_ATTEMPTS. La cuenta es automáticamente desbloqueada después de un instante de tiempo señalado en el valor PASSWORD_LOCK_TIME o bien, desbloqueda por el Administrador usando el comando ALTER USER. La cuenta de usuario puede ser explícitamente bloqueada con el comando ALTER USER o con Enterprise Manager. Cuando esto sucede, la cuenta no es automáticamente desbloqueda despues del tiempo indicado en PASSWORD_LOCK_TIME, pero tanto, debe ser manual desbloqueda por el DBA. SQL> ALTER USER hr ACCOUNT LOCK; User altered. SQL> CONNECT hr/hr ERROR: ORA-28000: the account is locked Warning: You are no longer connected to ORACLE. SQL> CONNECT / as sysdba Connected. SQL> ALTER USER hr ACCOUNT UNLOCK; User altered. 14
Expiración y Envejecimiento de Password Parámetero PASSWORD_LIFE_TIME PASSWORD_GRACE_TIME Descripción Tiempo de validez de la password en días después de ello, la password expira Periodo de gracia en días para cambiar la password después del primer intento de sesión y después que la password ha expirado Expiración y Envejecimiento de Password El administrador de la base de datos puede especificar un periodo de gracia PASSWORD_GRACE_TIME, el que comienza después del primer intento de sesión después que la password a expirado. Se despliega un mensaje de advertencia cada vez que el usuario intenta logearse hasta que el periodo de gracia vence. Si un usuario no cambia la password dentro del periodo de gracia, su cuenta queda bloqueada. Nota: Si la cuenta es una cuenta de aplicación (no accesible a traves de SQL*Plus), vefrificar que la aplicación esta habilitada para cambiar password antes de habilitar expiración de password. Muchos DBAs asignan perfiles separados a cuentas de usuarios de aplicaciones. Una cuenta de usuario puede ser expirada manualmente seteando la password a expirada. SQL> ALTER USER hr PASSWORD EXPIRE; User altered. SQL> CONNECT hr/hr ERROR: ORA-28001: the password has expired Changing password for hr New password: ******** Retype new password: ******** Password changed 15
Historial de Password Parámetro PASSWORD_REUSE_TIME PASSWORD_REUSE_MAX Descripción Número de dias antes que la password pueda ser reusada Número de password modificadas requeridas antes que la actual password pueda ser reusada Historial de Password El Historial de Password se asegura que un usuario no pueda reusar una password después de un intervalo de tiempo. Estos chequeos pueden ser implementados usando uno de los siguientes valores: PASSWORD_REUSE_TIME: Especifica que el usuario no puede reusar una password hasta el número de días indicado. PASSWORD_REUSE_MAX: Específica el número de password modificadas antes que la password actual pueda ser reutilizada. Estos dos parámetros son mutuamente excluyentes, cuando un parámetro se setea a un valor el otro se setea a UNLIMITED (o DEFAULT si el perfil tiene seteado el valor UNLIMITED). 16
Verificación de Password Parámetro Descripción PASSWORD_VERIFY_ FUNCTION Una función PL/SQL que asegura la complejidad de la password es chequeada antes de ser asignada La funcion de verificación de password debe: Ser propiedad del usuario SYS Retornar un valor Boolean (true o false) Verificación de Password Antes de asignar una nueva password al usuario, una función PL/SQL puede ser invocada para verificar la validez de la password. Oracle provee una rutina de verificación por defecto que puede ser cargada ejecutando un script SQL localizado en $ORACLE_HOME/rdbms/admin/utlpwdmg.sql o el DBA puede escribir una función PL/SQL personalizada que reuna los requerimientos de seguridad necesarios. Además de las restricciones listadas en la diapositiva, funciones de verificación de password deben seguir las siguientes especificaciones para declarar variables de entrada: function_name(userid_parameter IN VARCHAR2, password_parameter IN VARCHAR2, old_password_parameter IN VARCHAR2) RETURN BOOLEAN Si la función de password levanta una excepción o llega a ser inválida, un mensaje de error es retornado cuando el comando ALTER USER o CREATE USER es finalizado. 17
Función Provista para Verificación de Password: VERIFY_FUNCTION La función provista para la verificación de password, fuerza restricciones donde el: Minimo largo es 4 caracteres Password no puede ser igual al nombre del usuario Password debe tener al menos un alfabético, un número y un caracter especial Password debe diferir de las 3 passsword previas en al menos 3 letras Función Provista para Verificación de Password: VERIFY_FUNCTION Oracle provee una función de verificación de complejidad de password llamada VERIFY_FUNCTION. Esta función es creada con el script $ORACLE_HOME/rdbms/admin/utlpwdmg.sql. Esta función debe ser creado con el esquema SYS. Además de crear VERIFY_FUNCTION, con el script utlpwdmg también debe cambiar el perfil DEFAULT con el siguiente comando ALTER PROFILE: ALTER PROFILE default LIMIT PASSWORD_LIFE_TIME 60 PASSWORD_GRACE_TIME 10 PASSWORD_REUSE_TIME 1800 PASSWORD_REUSE_MAX UNLIMITED FAILED_LOGIN_ATTEMPTS 3 PASSWORD_LOCK_TIME 1/1440 PASSWORD_VERIFY_FUNCTION verify_function; 18
Creando un Perfil de Password Creando un Perfil de Password Para crear un perfil de password, abra Enterprise Manager y navege hasta la página Administration. Seleccione Profile y haga click en el botón Create. Valores comúnes para cada configuración pueden seleccionarse desde un listado de valores (icono linterna) o bien se ingresa el valor deseado. Todos los períodos de tiempo están expresados en días, pero pueden ser expresados como fracciones. Hay 1440 minutos en un día, así 5/1440 son 5 minutos. Borrando Perfiles de Password Si desea eliminar un perfil, todos los usuarios asignados a ese perfil seran automáticamente asignados al perfil por defecto. 19
Asignando Usuarios a un Perfil de Password Asignando Usuarios a un Perfil de Password Para asignar un usuario a un perfile de password: 1. Abra Enterprise Manager y navege a la página Administration. 2. Seleccione Users. Seleccione el usuario que dese asignar a un perfil y haga click en el botón Edit. 3. Desde el listado drop-down en profile, seleccione el perfil que desea aplicar al usuario y haga click en el botón Apply. Recuerde que un usuario puede solo tener asignado un perfil a la vez. Si un usuario esta logeado cuando se realiza un cambio en su perfil, los cambios no tienen efecto en este usuario hasta la siguiente sesión. La cuenta de usuario puede también ser bloqueada o expirada desde la pagina Edit User. 20
Monitoreando Actividades Sospechosas Monitorear o auditar debe ser parte integral de los procedimientos de seguridad. Oracle incluye las siguientes herramientas para auditar: Auditoria estándar de base de datos Auditoria basada en valor Auditoria fina (Fine-grained auditing (FGA)) Monitoreo para actividades sospechosas Oracle Database 10g provee 3 tipos diferentes de auditoria. El administrador puede auditar todas las acciones que tienen lugar dentro de una base de datos. Es importante recordar que la captura y registro de información sobre que esta aconteciendo en el sistema puede aumentar la carga de trabajo sobre el servidor. La auditoria puede ser focalizada sólo en aquellos eventos que nos interesa capturar o monitorear. De modo que la auditoria tenga el mínimo impacto en la performance del sistema. De cualquier otro modo, el impacto sobre el rendimiento del sistema es muy significativo. La auditoria estándar captura varias piezas de información acerca de eventos auditables, cuándo ocurrio el evento, qué usuario lo causo y cuál en máquina cliente estaba el usuario cuando sucedio el evento. La auditoria basada en valor, audita los cambios sobre los datos (insert, delete, update). Es una extensión a la auditoria estándar de base de datos, capturando no solo los eventos auditables cuando ocurren, sino también los valores que fueron insertados, borrados o modificados. La auditoria basada en valor se implementa a traves de triggers de base de datos. Auditoria fina (Fine-Grained Auditing (FGA)), audita sentencias SQL. FGA es una extensión a la auditoria estándar de base de datos, capturando la sentencia SQL actual que ha sido ejecutada. 21
Comparación de Herramientas de Auditoria Tipo de Auditoria Estándar Basada en valores De Granja Fina Qué es auditado? Uso de Privilegios incluyendo acceso a Objetos Datos cambiados por sentencias DML Sentencias SQL (insert, update, delete, y select) basadas sobre el contenido Qué registra? Conjunto Fijo de Datos Definidas por el Administrador Conjunto fijo de Datos incluyendo sentencias SQL 22
Auditoria Estándar de Base de Datos Habilitada a través del parámetro AUDIT_TRAIL NONE: Deshabilita la recolección de registros auditables DB: Habilita la auditoria con registros almacenados en la base de datos OS: Habilita la auditoria con registros almacenados en el sistema operativo Se puede auditar: Eventos de Login Exercise of system privileges Exercise of object privileges Uso de sentencias SQL Auditoria Estándar de Base de Datos Antes de usar la auditoria es preciso setear primeramente el parámetro AUDIT_TRAIL que indica la localización en el sistema operativo donde se almacenaran los registros de auditoria. El seteo normal de este parámetro es DB, lo que indica que los registros auditables seran almacenados en la tabla DBA_AUDIT_TRIAL. La auditoria puede capturar información sobre eventos de logins, ejecución de privilegios de sistemas y ejecución de privilegios de objetos. La información de auditoria puede focalizarse en el evento generado por el usuario o en el estado del evento (exitóso o no). El siguiente comando genera información de auditoria pero esta mal focalizado. Esta opción captura cualquier operación que afecte a cualquier tabla: SQL> AUDIT TABLE; Audit succeeded. Un mejor ejemplo de un comando de auditoria es (ya esta mas focalizado) : SQL> AUDIT DELETE ON hr.employees WHENEVER SUCCESSFUL; Audit succeeded. 23
Opciones específicas auditables Auditando sentencias SQL AUDIT table; Auditando privilegios de sistema (focalizado o no focalizado) AUDIT select any table, create any trigger; AUDIT select any table BY hr BY SESSION; Auditando privilegios de objetos (focalizado o no focalizado) AUDIT ALL on hr.employees; AUDIT UPDATE,DELETE on hr.employees BY ACCESS; Auditando sesiones AUDIT session whenever not successful; Opciones específicas auditables Auditando sentencias SQL: La sentencia mostrada en la figura auditara cualquier sentencia que afecte a una tabla incluyendo CREATE TABLE, DROP TABLE, TRUNCATE TABLE, etc. Las auditorias sobre sentencias SQL pueden ser focalizadas al usuario o al estado (éxito o fracaso de la sentencia). SQL> AUDIT TABLE BY hr WHENEVER NOT SUCCESSFUL; Auditar el sistema de privilegios puede ser usado para chequear la ejecución de cualquier privilegio del sistema, por ejemplo, DROP ANY TABLE. La auditoria se puede focalizar por usuario o éxito o fracaso de la acción. Por defecto, cada vez que se ejecuta un privilegio de sistema un registro de auditoria es ejecutado. Es posible agrupar esos eventos para que solo se registre uno por sesión (de esta forma si hay 100,000 actualizaciones de registro en una tabla que realiza un usuario, por tanto solo se registra un evento de auditoria). Si la cláusula BY SESSION no especificada, el valor por defecto es BY ACCESS. Considere usar la cláusula BY SESSION para limitar el registro de eventos de auditoria y no afectar el rendimiento del sistema. Auditoria de objetos puede ser usada para auditar acciones sobre tablas, vistas, procedimientos, secuencias, directorios, etc. Este tipo de auditorias puede enfocarse por éxito o fracaso y agruparse por sesión o acceso. Semejante a la auditoria de privilegios de sistema, el valor por defecto de agrupamiento es por sesión, por tanto, implícitamente debe indicarse BY ACCESS si se desea separar el registro de auditoria generada por cada acción. 24
Especificando opciones de auditoria (Continuación) La opción AUDIT SESSION audita la creación de sesiones de usuario. Puede focalizarse la auditoria por usuario o éxito/fracaso. Esta opción es única ya que genera un registro de auditoria por cada sesión que se conecta a la base de datos. Un registro de auditoria es insertado en el registro de auditoria al momento de conexión y modificado al momento de desconectarse. La información acumulada sobre una sesión como el tiempo de conexión, tiempo de desconexión, I/O lógicos y físicos procesados y mucho mas, son almacenados en un simple registro de auditoria que corresponde a la sesión. En muchas bases de datos es común usar el comando AUDIT SESSION (no focalizado). En la mayoria de las bases de datos se debe configurar AUDIT SESSION WHENEVER NOT SUCCESSFUL porque permite detectar intentos indebidos de acceso a la base de datos. Nota: A menudo las opciones comienzan como no focalizadas porque no se tiene certeza que actividad debemos monitorear. La opción AUDIT ALL un atajo conveniente para auditar uma amplia gama de actividades en la base de datos. Alter Audit Comment Delete Si la opcióngrant AUDIT ALL es Index usado con un username: Insert Lock SQL> AUDIT ALL BY hr; Read Rename Select Update El usuario tendrá sentencias DDL auditables para los siguientes objetos: Alter System Cluster Context Create Session Database Link Dimension Directory Index Materialized View Not Exists Procedure Profile Public Database Link Public Synonym Role Rollback Segment Sequence Synonym System Audit System Grant Table Tablespace Trigger Type User View 25