Your SlideShare is downloading. ×
Abf leccion 14
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Abf leccion 14

219
views

Published on


0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
219
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
10
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Jaime Amigo P. © 2006, Santiago - Chile Instituto Profesional DuocUC Escuela de Ingeniería Oracle Database Security
  • 2. 2 Instituto Profesional DuocUC Escuela de Ingeniería 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
  • 3. 3 Instituto Profesional DuocUC Escuela de Ingeniería 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”.
  • 4. 4 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.
  • 5. 5 Instituto Profesional DuocUC Escuela de Ingeniería 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.
  • 6. 6 Instituto Profesional DuocUC Escuela de Ingeniería Proteger el Diccionario de Datos • Proteger el diccionario de datos, para asegurarse este parámetro debe estar inicializado en 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. O7_DICTIONARY_ACCESSIBILITY = FALSE 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.
  • 7. 7 Instituto Profesional DuocUC Escuela de Ingeniería 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..
  • 8. 8 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>
  • 9. 9 Instituto Profesional DuocUC Escuela de Ingeniería 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.
  • 10. 10 Instituto Profesional DuocUC Escuela de Ingeniería 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.
  • 11. 11 Instituto Profesional DuocUC Escuela de Ingeniería 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.
  • 12. 12 Instituto Profesional DuocUC Escuela de Ingeniería 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.
  • 13. 13 Instituto Profesional DuocUC Escuela de Ingeniería Usuario Expiración y Envejecimiento de Password Verificación de Password Seteo de Perfiles Implementar Características Estandares de Seguridad de Password Historial de Password Cuentas Bloquedas 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.
  • 14. 14 Instituto Profesional DuocUC Escuela de Ingeniería Bloqueo de Cuentas Número de días que la cuenta esta bloqueda despues que el número de intentos fallidos se ha superado PASSWORD_LOCK_TIME Número de intents fallidos de conexión antes de bloquearse la cuenta FAILED_LOGIN_ATTEMPTS DescripciónParámetro 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.
  • 15. 15 Instituto Profesional DuocUC Escuela de Ingeniería Expiración y Envejecimiento de Password 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 PASSWORD_GRACE_TIME Tiempo de validez de la password en días después de ello, la password expira PASSWORD_LIFE_TIME DescripciónParámetero 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
  • 16. 16 Instituto Profesional DuocUC Escuela de Ingeniería Historial de Password Número de password modificadas requeridas antes que la actual password pueda ser reusada PASSWORD_REUSE_MAX Número de dias antes que la password pueda ser reusada PASSWORD_REUSE_TIME DescripciónParámetro 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).
  • 17. 17 Instituto Profesional DuocUC Escuela de Ingeniería Verificación de Password La funcion de verificación de password debe: • Ser propiedad del usuario SYS • Retornar un valor Boolean (true o false) Una función PL/SQL que asegura la complejidad de la password es chequeada antes de ser asignada PASSWORD_VERIFY_ FUNCTION DescripciónParámetro 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.
  • 18. 18 Instituto Profesional DuocUC Escuela de Ingeniería 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;
  • 19. 19 Instituto Profesional DuocUC Escuela de Ingeniería 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.
  • 20. 20 Instituto Profesional DuocUC Escuela de Ingeniería 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.
  • 21. 21 Instituto Profesional DuocUC Escuela de Ingeniería 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.
  • 22. 22 Instituto Profesional DuocUC Escuela de Ingeniería Comparación de Herramientas de Auditoria Conjunto fijo de Datos incluyendo sentencias SQL Sentencias SQL (insert, update, delete, y select) basadas sobre el contenido De Granja Fina Definidas por el Administrador Datos cambiados por sentencias DML Basada en valores Conjunto Fijo de Datos Uso de Privilegios incluyendo acceso a Objetos Estándar ¿Qué registra?¿Qué es auditado?Tipo de Auditoria
  • 23. 23 Instituto Profesional DuocUC Escuela de Ingeniería 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.
  • 24. 24 Instituto Profesional DuocUC Escuela de Ingeniería Opciones específicas auditables AUDIT select any table, create any trigger; AUDIT select any table BY hr BY SESSION; AUDIT table; AUDIT ALL on hr.employees; AUDIT UPDATE,DELETE on hr.employees BY ACCESS; AUDIT session whenever not successful; Auditando sentencias SQL Auditando privilegios de sistema (focalizado o no focalizado) Auditando privilegios de objetos (focalizado o no focalizado) Auditando sesiones 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.
  • 25. 25 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. Si la opción AUDIT ALL es usado con un username: SQL> AUDIT ALL BY hr; El usuario tendrá sentencias DDL auditables para los siguientes objetos: UpdateSelectRenameRead LockInsertIndexGrant DeleteCommentAuditAlter ViewUser TypeTriggerTablespaceTable System GrantSystem AuditSynonymSequence Rollback SegmentRolePublic SynonymPublic Database Link ProfileProcedureNot ExistsMaterialized View IndexDirectoryDimensionDatabase Link Create SessionContextClusterAlter System
  • 26. 26 Instituto Profesional DuocUC Escuela de Ingeniería Viendo Opciones de Auditoria Opciones Auditoria Objetos del Esquema DBA_OBJ_AUDIT_OPTS Opciones Auditoria de Privilegios DBA_PRIV_AUDIT_OPTS Opciones de auditoria de Sentencias DBA_STMT_AUDIT_OPTS Opciones por DefectoALL_DEF_AUDIT_OPTS DescripciónVista Diccionario de Datos Viendo Opciones de Auditoria Para ver que opciones de auditoria se han seleccionado, liste las vistas mencionadas a continuación. DBA_STMT_AUDIT_OPTS y DBA_PRIV_AUDIT_OPTS contienen solo registros de sentencias y opciones de auditoria de privilegios que se han especificado. DBA_OBJ_AUDIT_OPTS contiene un registro por objeto auditable sin importar que opciones se han. La vista muestra una columna para cada opción auditable. Por ejemplo, opciones de auditoria para INSERT son mostradas en la columna INS. Opciones de auditoria son desplegadas como SUCCESSFUL/NOT SUCCESSFUL con 3 posibles valores para cada estado: • - Not audited • S Collect audit records by session • A Collect audit records by access SQL> SELECT object_name, object_type, ins, upd FROM dba_obj_audit_opts WHERE object_name = 'EMPLOYEES‘ OBJECT_NAME OBJECT_TY INS UPD ------------ --------- --- --- EMPLOYEES TABLE A/S -/-
  • 27. 27 Instituto Profesional DuocUC Escuela de Ingeniería Registros Auditoria Archivo de Parámetros Especificar opciones auditoria Generar Registro Auditoria Revisar Información Auditoria Auditoria Estándar de Base de Datos DBA Usuario Habilitar Auditoria de Base de Datos Ejecutar Comandos Database Registrar Auditoria SO Opciones Auditoria Server process Auditoria Estándar de Base de Datos Después que el administrador a habilitado la auditoria (con el parámetro AUDIT_TRAIL) y especificado sus opciones (con sentencias SQL como se mostro en páginas previas), la base de datos comienza a recolectar información de auditoria. Si AUDIT_TRAIL esta setea al Sistema Operativo, los registros de auditoria serán registrados en el sistema operativo en archivos. En un ambiente Windows, esto es un evento de log. En ambientes UNIX, los registros son almacenados en un archivo. La localización de este archivo esta especificado con el parámetro AUDIT_FILE_DEST. Asumiendo que AUDIT_TRAIL está setea a DB, los registros auditables son almacenados en una tabla que es parte del esquema SYS. El mantenimiento de los registros de auditoria es una tarea administrativa importante que debe ejecutar el DBA. Dependiendo den la focalización de la auditoria, la cantidad de información a registrar podría crecer enormemente de forma muy rápida. Sino se mantiene adecuadamente el registro de auditorias, esto puedo consumir mucho espacio de almacenamiento y puede afectar el rendimiento del sistema.
  • 28. 28 Instituto Profesional DuocUC Escuela de Ingeniería Vistas Auditables DBA_AUDIT_TRAIL DBA_AUDIT_EXISTS DBA_AUDIT_OBJECT DBA_AUDIT_SESSION DBA_AUDIT_STATEMENT Descripción Audita todas las entradas Registros para AUDIT EXISTS/NOT EXISTS Registros objetos del esquema Conexiones y desconexiones Sentencias Auditables Viendo Resultados Auditables Viendo Resultados Auditables El acceso a los registros auditables debe ser controlado rigurosamente pues puede contener información sensitiva para el negocio de la empresa. Usualmente la tarea de administrar los registros auditables es llevada por el DBA pero si necesita ser delegada se deben otorgar grant a DELETE_CATALOG_ROLE para borrar información.
  • 29. 29 Instituto Profesional DuocUC Escuela de Ingeniería Auditoria basada en Valores Cambios de Usuario Confirmados Dispara Triggers Registro Auditoria es creado por Trigger E Insertado en una tabla de auditoria Cambios hechos por Usuario Auditoria Basada en Valores Los registros de auditoria de base de datos que hacen insert y delete sobre objetos auditables, no capturan los valores reales que fueron cambiados o insertados. La auditoria basada en valores es una extensión de la auditoria estándar y capturan los valores actuales que han sido modificados. Se activan disparadores (triggers) construidos en PL/SQL. Cuando un usuario inserta, modifica o elimina datos desde una tabla con el adecuado trigger asociado, el trigger trabaja en background y copia la información a una tabla diseñada para contener información de auditoria. La auditoria basada en valores, tiende a degradar más el rendimiento que la auditoria estándar, porque el código del trigger debe ejecutarse cada vez que ocurre una operación de insert, delete o update. La degradación dependerá mucho del la eficiencia del código PL/SQL del trigger. Este tipo de auditorias solo debe ser usada en situación donde la información capturada por la auditoria estándar de base de datos es insuficiente.
  • 30. 30 Auditoria basada en Valores (continuación) La clave de la auditoría basada en valores es el trigger auditable. A continuación un ejemplo: CREATE OR REPLACE TRIGGER system.hrsalary_audit AFTER UPDATE OF salary ON hr.employees REFERENCING NEW AS NEW OLD AS OLD FOR EACH ROW BEGIN IF :old.salary != :new.salary THEN INSERT INTO system.audit_employees VALUES (sys_context('userenv','os_user'), sysdate, sys_context('userenv','ip_address'), :new.employee_id ||' salary changed from '||:old.salary|| ' to '||:new.salary); END IF; END; / Este trigger se focaliza en auditar y capturar los cambios sobre la columna salary de la tabla hr.employees. Cuando una fila es modificada, el trigger verifica la columna salary. Si el salario anterior no es igual al nuevo valor, entonces el trigger inserta un registro de auditoria en la tabla audit_employees (tabla creada en el esquema SYSTEM). El regitro de auditoria incluirá username, IP address desde donde se hace el cambio, la clave primaria que identifica el registro modificado y el actual salario que se ha modificado. Los triggers de base de datos puede ser usados también para capturar información de conexiones de usuarios en casos donde la auditoria estándar no entrege los datos suficientes. Con trigger de logon, el DBA puede capturar: - IP address de la persona que se conecta - Los primeros 48 caracteres del programa usado para conectarse a la instancia - Nombre del terminal usado para conectarse a la instancia
  • 31. 31 Instituto Profesional DuocUC Escuela de Ingeniería 31 Auditoria Fina (FGA) • Monitoreo de acceso a datos sobre contexto • Audita SELECT or INSERT,UPDATE,DELETE • Puede ser linqueado a tabla o vista • Puede disparar un procedimiento • Es gestionado con el paquete DBMS_FGA employees Policy: AUDIT_EMPS_SALARY SELECT name, salary FROM employees WHERE department_id = 10; Auditoria Fina - Fine-Grained Auditing (FGA) Los registros de auditoria de base de datos registran que una operación ha sucedido pero no capturan la información de la sentencia SQL que genero la operación.. La auditoria fina es una extensión que tiene la capacidad de capturan la sentencia SQL que consulta o manipula datos. FGA permite también auditar mas detalladamente que la auditoria estándar o la auditoria basada en valores. Las opciones de auditoria fina puede focalizarse por columnas individuales dentr de una tabla o vista y a menudo puede ser condicionada a que los registros auditables sean capaturados solo si se reunen ciertas especificaciones indicadas por el administrador o DBA. A diferencia de la auditoria basada en valores, FGA no requiere del uso de triggers y el impacto en el rendimiento es similar a la auditoria estándar. El administrador usa el paquete DBMS_FGA PL/SQL para crear una política de auditoria sobre una tabla o vista. Si alguna de las filas retornadas de una consulta complete la condición establecida en la auditoria y afecta a la columna auditable, entonces se genera un registro y se almacena dicha información. Opcionalmente dicho evento puede ejecutar un procedimiento almacenado. FGA automáticamente focaliza la auditoria a sentencias SELECT, en aquellas que retornan cientos de filas se genera solo un registro auditable.
  • 32. 32 Instituto Profesional DuocUC Escuela de Ingeniería 32 Politica FGA dbms_fga.add_policy ( object_schema => 'hr', object_name => 'employees', policy_name => 'audit_emps_salary', audit_condition=> 'dept_id=10', audit_column => 'salary', handler_schema => 'secure', handler_module => 'log_emps_salary', enable => TRUE, statement_types=> 'select' ); SELECT name, job_id FROM employees; SELECT name, salary FROM employees WHERE department_id = 10; SECURE.LOG_ EMPS_SALARY employees • Define: – Criterio Auditoria – Acción Auditoria • Es creado con DBMS_FGA .ADD_POLICY Política FGA El ejemplo de la figura muestra una Política FGA creada con el procedimiento DBMS_FGA.ADD_POLICY. El procedimiento acepta los siguientes argumentos: Policy Name Usted asigna un nombre a cada vez que crea una Política FGA. El ejemplo muestra el nombre AUDIT_EMPS_SALARY, usando los siguientes argumentos: policy_name => 'audit_emps_salary' Audit Condition La condición de auditoria es el predicado de SQL que define cuando el evento de auditoria debe ser disparado o llamado. En el ejemplo, todas las filas en las ventas de departamentos están auditadas,usando el siguiente argumento en la condición: audit_condition => 'department_id = 10' Statement Type ¿Cuál tipo de sentencia será auditada? Se puede auditar sentencias SELECT y (todas en un solo string) INSERT,UPDATE,DELETE.
  • 33. 33 Política FGA (continuación) Audit Column La columna auditable define el dato que esta siendo auditado para dicha tabla. Un evento auditable ocurre solo si la columna es incluida en la cláusula SELECT. En el ejemplo es la columna SALARY, usando los siguientes argumentos: audit_column => 'salary' Este argumento es opcional. Sino se especifica, entonces el argumento AUDIT_CONDITION determina cuando ocurre un evento a auditar. Object El objeto es la tabla o vista que esta siendo auditada. Hay 2 argumentos passados: • El esquema que contiene el objeto • El nombre del objeto En el ejemplo la tabla auditable hr.employees usando los siguientes argumentos: object_schema => 'hr' object_name => 'employees' Handler Es opcional y determina el procedimiento PL/SQL a ejecutar si se requieren acciones adicionales a tomar cuando ocurra un evento auditable. Por ejemplo, el evento podría enviar una página de alerta al administrador. Sino se define el manejador de eventos, entonces la entrada del evento es insertada en el registro auditable. Si el manejador de eventos esta definido, entonces se inserta un registro en la bitacora de auditoria y se ejecuta el manejador de eventos. La entrada de auditoria incluye la política que causo el evento, el usuario que ejecuto la sentencia SQL y la sentencia SQL y sus variables o parámetros que la componen. El administrador de eventos es pasado como 2 argumentos: • El esquema que contiene el programa PL/SQL • El nomrbre del programa PL/SQL El ejemplo ejecuta el procedimiento SECURE.LOG_EMPS_SALARY usando los siguientes argumentos: handler_schema => 'secure' handler_module => 'log_emps_salary' Status El estado indica si la política FGA esta permitida o habilitada. En el ejemplo, los siguientes argumentos estan habilitados para la política: enable => TRUE
  • 34. 34 Instituto Profesional DuocUC Escuela de Ingeniería Paquete DBMS_FGA • Use DBMS_FGA to maintain FGA policies • Grant the execute privilege only to administrators • Includes the following subprograms: Deshabilita una políticaDISABLE_POLICY Habilita una politicaENABLE_POLICY Borra una políticaDROP_POLICY Crea politica usando el predicado como la condición de auditoria ADD_POLICY DescripciónSubprograma Paquete DBMS_FGA El paquete DBMS_FGA es la herramienta de administración para funciones de auditoria fina. Privilegios de Execute sobre DBMS_FGA son necesarios para administrar políticas de auditoria fina. Dado que este tipo de auditoria puede contener información sensible para el negocio. Esos privilegios de execute sobre este package deben estar reservados solo para el administrador o DBA.
  • 35. 35 Instituto Profesional DuocUC Escuela de Ingeniería Habilitando y Deshabilitando una Política FGA • Habilitando una Política: • Deshabilitando una Política: dbms_fga.enable_policy ( object_schema => 'hr', object_name => 'employees', policy_name => 'audit_emps_salary' ); dbms_fga.disable_policy ( object_schema => 'hr', object_name => 'employees', policy_name => 'audit_emps_salary' ); Habilitando y Deshabilitando una Política FGA Deshabilitar una política FGA significa que la política no generará eventos auditables. Si desea que la política comience a registrar eventos, ustede deberá habilitarla nuevamente. Por defecto la política queda habilitada al momento de la creación. En el ejemplo se muestra como habilitar y deshabilitar una política. Para ambos procedimientos, todos los argumentos son requeridos.
  • 36. 36 Instituto Profesional DuocUC Escuela de Ingeniería Borrando una Política FGA SQL> EXEC dbms_fga.drop_policy ( - > object_schema => 'hr', - > object_name => 'employees', - > policy_name => 'audit_emps_salary'); PL/SQL procedure successfully completed. SQL> Borrando una Política Sino se desea seguir con una política, usted puede removerla con DBMS_FGA.DROP_POLICY. Todos los argumentos son requeridos.
  • 37. 37 Instituto Profesional DuocUC Escuela de Ingeniería 37 Disparando Eventos Auditables • La siguiente sentencia SQL causa una auditoria: • La siguiente sentencia no causa una auditoria: SELECT count(*) FROM hr.employees WHERE department_id = 10 AND salary > v_salary; SELECT salary FROM hr.employees; SELECT last_name FROM hr.employees WHERE department_id = 10; Disparando Eventos Auditables En general, la política de auditoria fina esta basada en columnas auditables y simpre predicados SQL definidos por el usuario. Durante el análisis de las condiciones de la política reunidas para la condición, la sentencia es auditada y si hay un evento a manejar, éste es disparado. La función de auditoria es ejecutada como una transacción autónoma. Cada política de auditoria se aplica individualmente. Es decir, mientras las filas estan siendo devueltas o modificadas, un registro de auditoria será generado y habrá un registro de auditoria por cada política para sentencias SQL. Ejemplos Los dos primeros ejemplos de la figura, producen un evento auditable perque accesan la columna salary y filas con department_id = 10. En el segundo ejemplo, Oracle se da cuenta que hay una política asociada a la columna salary que accesan a las filas del departamento 10, a pesar que department_id no es referenciado en la cláusila WHERE. En el último ejemplo, no se produce una auditoria porque no se accesa la columna salary. Si la columna salary no ha sido especificada como AUDIT_COLUMN cuando la política es creada, entonces la sentencia SELECT produciría un evento auditable.
  • 38. 38 Instituto Profesional DuocUC Escuela de Ingeniería Vistas Diccionario de Datos Todas las politicas FGA para objetos en el esquema del usuario actual USER_AUDIT_POLICIES Todas las politicas en la base de datos DBA_AUDIT_POLICIES Todas las políticas FGA para objetos accesados por el usuario actual ALL_AUDIT_POLICIES Todos lso eventos FGADBA_FGA_AUDIT_TRAIL DescripciónNombre de Vista Vistas del Diccionario de datos Las entradas auditables de FGA se registran en una tabla separada de las auditorias de objetos y privilegios. Las entrada son registradas en la vista DBA_FGA_AUDIT_TRAIL. Hay otras 2 vistas que contienen definición de políticas: ALL_AUDIT_POLICIES, DBA_AUDIT_POLICIES, USER_AUDIT_POLICIES.
  • 39. 39 Instituto Profesional DuocUC Escuela de Ingeniería DBA_FGA_AUDIT_TRAIL SQL> SELECT to_char(timestamp, 'YYMMDDHH24MI') 2 AS timestamp, 3 db_user, 4 policy_name, 5 sql_bind, 6 sql_text 7 FROM dba_fga_audit_trail; TIMESTAMP DB_USER POLICY_NAME SQL_BIND ---------- ------- ----------------- ---------- SQL_TEXT ----------------------------------------------- 0201221740 SYSTEM AUDIT_EMPS_SALARY #1(4):1000 SELECT count(*) FROM hr.employees WHERE department_id = 10 AND salary > :b1 DBA_FGA_AUDIT_TRAIL Nombre Descripción TIMESTAMP Fecha y Hora de Ejecución DB_USER Nombre del usuario de la base de datos OS_USER Nombre del usuario del Sistema Operativo OBJECT_SCHEMA Propietario del objeto auditable OBJECT_NAME Nombre del objeto auditables POLICY_NAME Nombre de la política que causo el evento auditable SCN El SCN de la transacción SQL_TEXT Sentencia SQL que causo el evento auditable SQL_BIND Variable del evento auditable formateada como: #n(s):v: Donde n es el número de la variable en la sentencia s es el largo de la variabley v es el valor de la variable COMMENT$TEXT Un comentario
  • 40. 40 DBA_FGA_AUDIT_TRAIL (continuación) Seleccionando desde la Auditoria FGA El siguiente ejemplo despliega 2 files de auditoria creadas para ejemplos válidos de páginas anteriores. La columna sql_bind en la segunda fila tiene un valor de #1(4):1000, que incluye las siguientes componentes: #1 Indica que este es la primera variable de ambiente en la sentencia. (4) Indica que la variable de ambiente tiene largo 4. 1000 indica que la variable de ambiente tiene valor 1000. Ejemplo Este ejemplo es similar al visto en la figura, a menos que también incluya una política para fila sin un manejador de auditoria. SQL> COL timestamp FORMAT A10 SQL> COL db_user FORMAT A7 SQL> COL policy_name FORMAT A20 SQL> COL sql_bind FORMAT A20 SQL> COL sql_text FORMAT A60 SQL> SQL> SELECT to_char(timestamp, 'YYMMDDHH24MI') 2 AS timestamp, 3 db_user, 4 policy_name, 5 sql_bind, 6 sql_text 7 FROM dba_fga_audit_trail; TIMESTAMP DB_USER POLICY_NAME SQL_BIND ---------- ------- -------------------- ------------------ SQL_TEXT ---------------------------------------------------------- 0201221740 SYSTEM AUDIT_EMPS_SALARY #1(4):1000 SELECT count(*) FROM hr.employees WHERE department_id = 10 AND salary > :b1 0201221741 SYSTEM AUDIT_EMPS_SALARY SELECT salary FROM hr.employees SQL>
  • 41. 41 Instituto Profesional DuocUC Escuela de Ingeniería Pautas para FGA • Para auditar todas las sentencias, use la condición null. • Si intenta agregar una política que ya existe, aparecerá el error ORA-28101. • Cuando se crea una política, la tabla o vista debe existir. • Si la sintáxis de la condición de auditoria es inválida, un error ORA-28112 aparecerá cuando el objeto auditado sea accesado. • Si la columna auditable no existe en la tabla, las filas no serán auditadas. • Si el manejador de eventos no existe, no se devuelve ningún error y los registros auditables son creados. Pautas para FGA Condición de Auditoria Cuando se crea una nueva política FGA, la condición por defecto es null, lo que significa que todas las sentencias sera auditadas. Error en Nombre de Políticas El nombre de la política debe ser único dentro de la base de datos. Las políticas no tienen propietario. Si un nombre duplicado es usado, usted recibe un mensaje de error cuando esta creando la política: ORA-28101: policy already exists Errores de Objetos Auditados La tabla o vista auditada deben existir cuando se crea la política. Sino existe, usted recibe un error como el siguiente: ORA-00942: table or view does not exist
  • 42. 42 Pautas para FGA (continuación) Errores de Condiciones Auditables Si la sintáxis de la condición es inválida, la política se creará sin errores, pero el siguiente mensaje aparece cuando el objeto es accesado: ORA-28112: failed to execute policy function Si la sintáxis de la condición es válida, pero es incorrecta, entonces las filas incorrectas se auditan. Errores de Columnas Auditables Si la columna a auditar no existe en la tabla, entonces la política se creará, sin embargo, no hay filas que serán auditadas porque la columna nunca será accesada. Si la columna a auditar es válida, pero incorrecta, entonces las filas incorrectas serán auditadas. Errores de Manejador de Eventos (Event Handler) Cuando la política hace referencia a un manejador de eventos que no existe, la política se creará, sin embargo, no habrá filas retornadas cuando ocurra un evento auditable.
  • 43. 43 Instituto Profesional DuocUC Escuela de Ingeniería Auditando Usuarios SYSDBA y SYSOPER Usuarios con privilegios SYSDBA o SYSOPER privileges pueden conectarse a una base de datos cerrada. • El registro de auditoria debe ser almacenado fuera de la BD (es decir, SO). • Conexiones como SYSDBA o SYSOPER siempre deben ser auditadas. • Habilitar auditoria adicional de acciones de SYSDBA o SYSOPER con audit_sys_operations. • El control del registro de auditorias llevarlo con audit_file_dest. Default es: – $ORACLE_HOME/rdbms/audit (UNIX/Linux) – Windows Event Log (Windows) Auditando usuarios SYSDBA y SYSOPER Los usuarios con privilegios SYSDBA y SYSOPER pueden subir y bajar una base de datos. Debido a que pueden hacer cambios mientras una base de datos esta cerrada, el registro de auditorias (bitácora) debe ser almacenado fuera de la base de datos. Oracle captura los eventos de login automáticamente para usuarios SYSDBA y SYSOPER, pero no captura nada más que el login a menos que este habilitada una auditoria específica. Habilitar la auditoria para usuarios SYSDBA y SYSOPER, se hace seteando un parametro de inicialización: audit_sys_operations=TRUE (default es FALSE) Si las operaciones del usuario SYS son auditadas, el parámetro de inicialización audit_file_dest indica dónde los regitros de esta bitácora serán almacenados. En plataforma Windows quedan por defecto en el Windows Event Log. En plataformas UNIX, os registros son almacenados en $ORACLE_HOME/rdbms/audit.
  • 44. 44 Instituto Profesional DuocUC Escuela de Ingeniería Actualizaciones de Seguridad • Oracle coloca sus alertas de seguridad en su sitio web Oracle Technology Network Web: http://otn.oracle.com/deploy/security/alerts.htm • Los administradores y desarrolladores Oracle puede subscribirse para ser notificados sobre alertas críticas de seguridad a través de mail haciendo Click en el Link “Subscribe to Security Alerts Here”. Actualizaciones de Seguridad Las alertas de seguridad Oracle contienen una descripción de las vulnerabilidades, riesgos posibles y grado de exposición asociado a la vulnerabilidad, aplicaciones afectadas y los posibles parches de seguridad a aplicar. Las alertas de seguridad son colocadas en el Sitio Web Oracle Technology Network y en el sitio Web de OracleMetaLink (MetaLink). Aunque las alertas de seguridad son de público conocimiento, solo los clientes registrados (Customer Support Identification (CSI ))en Oracle puede accesar y bajar los parches de seguridad que corrigen las falencias de seguridad.
  • 45. Jaime Amigo P. © 2006, Santiago - Chile Instituto Profesional DuocUC Escuela de Ingeniería Fin de la Lección