Abf leccion 14

Jaime Amigo P. © 2006, Santiago - Chile

Instituto Profesional DuocUCEscuela de Ingeniería

Oracle Database Security

2


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


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 DatosOracle Database 10g provee el mejor framework de la industria para un sistemaseguro, pero para que ese framework sea efectivo, el administrador de base de datosdebe seguir buenas prácticas y estar continuamente monitoreando la actividad de la base de datos.Restringiendo acceso a los Datos y ServiciosTodos 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 reglainquebrantable. Estas restricciones pueden ser por requerimientos del negocio, porrestricciones 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 unabase de datos. Restricción de acceso debe aplicar el “Principio del Menor Privilegio”.

4

Seguridad de Base de Datos (continuación)Autentificación de usuariosPara hacer cumplir los controles de acceso el sistema debe primero saber quién estatratando 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 incrementarel nivel de seguridad de un sistema. Existen métodos de autentificación más robustaque solicitan al usuario algo, por ejemplo un certificado PKI (Public Key Infrastructure). Otro método de autentificación fuerte es utilizar un dispositivobiométrico como huella digital (fingerprint), lector de iris o diafragma (iris scan), patrones de la estructura del hueso (bone structure pattern), otros. Oracle soportatécnicas avanzadas de autentificación tales como token, biometría, certificadosdigitales 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 puescomprometen la seguridad del sistema.Monitoreo para actividades sospechosasUsuario debidamente autentificados y autorizados algunas veces puedencomprometer 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 ricojuego de herramientas de auditoria para seguir la pista a usuarios e identificaractividades sospechosas.

5


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 PrivilegioOracle Database 10g es líder en la industria en seguridad. Sin embargo, para maximizar lascaracterísticas de seguridad ofrecidas en cualquier ambiente de negocios, es imperativo queOracle 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 seguropara operar.Practica del Principio del Menor PrivilegioEste 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 queusuarios accidentalmente o maliciosamente pueden modificar o ver datos para los cualesellos no tienen los privilegios respectivos.La mayoria de la organizaciones de IT desean para sus ambientes de producción unapolítica cerrada o basada en la Política del Menor Privilegio.

6


Proteger el Diccionario de Datos

• Proteger el diccionario de datos, para asegurarse esteparámetro debe estar inicializado en FALSE:

• Esto previene que usuarios con privilegio de sistemasANY 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 encuentraseteado a TRUE, asegurese de tener una buena razónde negocio para ello.

O7_DICTIONARY_ACCESSIBILITY = FALSE

Proteger el Diccionario de DatosUsuarios que no son administradores no necesitan tener acceso al diccionario de datos, pero puedenaccederlo 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 maliciosopodrí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 diccionariode 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 espreciso 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 unabase 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


Revocar los Privilegios PUBLIC innecesarios

• Revocar todos los privilegios y roles innecesarios de la base de datos del grupo PUBLIC.

• Muchos packages construidos tienen otorgradosEXECUTE 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 innecesariosRevoque todos aquellos privilegios y roles innecesarios asociados a los usuarios que seande acceso PUBLIC, ya que este tipo de grant son peligros.Privilegios como EXECUTE sobre package PL/SQL podrían habilitar a un usuario a ejecutarprocedimientos que usted no desea realiza, por tanto, se deben otorgar los mínimosprivilegios 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 algunospaquetes mas sensitivos y otorgar permisos de ejecución individuales a usuarios querequieran 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 Servidorde 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

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 estepaquete, permite enviar datos en formularios HTML (HyperText Markup Language) a sitios web maliciosos.

• UTL_FILE: Si esta configurado incorrectamente, permite acceso a nivel de textoa cualquier archivo del sistema operativo del servidor. A menudo, cuando estacorrectamente configurado, este paquete no distingue entre llamadas de aplicaciones. Una aplicación con acceso a UTL_FILE puede escribir datosarbitrariamente dentro de la misma localización que es escrita por otraaplicación.

• DBMS_OBFUSCATION_TOOLKIT: Encripta datos. Generalmente, la mayoriade los usuarios no tiene privilegios para encriptar datos porque la encriptaciónde 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 unaadecuada configuración para ser usado en forma segura. Por tanto, esabsolutamente necesario revocar los grant PUBLIC y otorgarlo solo a aquellosusuarios o roles cuando lo requieran.Listando Objetos Ejecutables PúblicosUse la siguiente consulta para listar los objetos propiedad del usuario SYS que tieneprivilegio de EXECUTE con grant PUBLIC:

SQL> SELECT table_name2 FROM dba_tab_privs3 WHERE owner='SYS'4 AND privilege = 'EXECUTE'5 AND grantee='PUBLIC'6 /

TABLE_NAME--------------------AGGXMLIMPAGGXMLINPUTTYPE...XMLTYPEEXTRAXMLTYPEPI

437 rows selected.

SQL>

9


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 UsuariosEl parámetro de configuración UTL_FILE_DIR indica en cual directorio del sistema operativopaquetes PL/SQL pueden leer o escribir. Por defecto, no hay directorios accesibles. Los privilegios del sistema operativo siguen aplicables. Los directorios que el usuario levantoen 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 instanciadebe 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, portanto, debe cambiar el parámetro o crear el directorio posteriormente.Todos los usuarios de PL/SQL pueden leer o escribir en los directorios especificados, todoslos usuarios de PL/SQL deben confiar con la información en los directorios especificados poreste 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


Limitar Usuarios con PrivilegiosAdministrativos

• 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_privs2 WHERE granted_role = 'DBA';

GRANTEE------------------------------SYSSYSTEM

Limitar Usuarios con Privilegios AdministrativosNo 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


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 defectocomo sigue:

REMOTE_OS_AUTHENT = FALSE

Deshabilitar Autentificación Remota de Sistema OperativoEsta característica esta deshabilitada por defecto. Cuando se habilita (TRUE), la autentificación externa de usuarios de base de datos, esta se delega al sistemaremoto. Esto significa que la instancia confía implícitamente que los usuarios hansido autentificados adecuadamente en el cliente PC y no solicita una nuevacredencial 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 usuariosdesde PC’s, no debería ejecutar autentificación confiando en ellos. Estos es una pobre practicade seguridad que debería modificarse.

12


Administrar Cuentas de Usuarios porDefecto

• DBCA expira y bloquea todas lascuentes excepto:– SYS– SYSTEM– SYSMAN– DBSNMP

• Para una base de datos creadamanualmente, bloquee y experirelas cuentas no utilizadas.

Administrar Cuentas de Usuario por DefectoOracle Database 10g se instala con un número de cuentas de usuarios por defecto. Estascuentas 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 paracrear 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 aplicacionesesperan que la base de datos este configurada de cierta manera y se automatiza la creacióna través de un script. Las bases de datos creadas de este forma, no bloquean las cuentaspor defecto. Valide que las cuentas no bloqueadas estan siendo usadas por conexiones a la base de datos y no simplemente para almacenar datos.

13


Usuario

Expiración y Envejecimiento de

Password

Verificaciónde

Password

Seteo de Perfiles

Implementar Características Estandaresde Seguridad de Password

Historialde

Password

CuentasBloquedas

Implementando Características Estandares de Seguridad de PasswordLa 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úmeroespecificado 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 verificaque reuna ciertas características. El chequeo permite que las password sean lo suficientementecomplejas 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 queotro perfil les sea asignado.

14


Bloqueo de Cuentas

Número de días que la cuenta establoqueda despues que el númerode 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 CuentasOracle 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 lockedWarning: You are no longer connected to ORACLE.SQL> CONNECT / as sysdbaConnected.SQL> ALTER USER hr ACCOUNT UNLOCK;User altered.

15


Expiración y Envejecimiento de Password

Periodo de gracia en días paracambiar la password después del primer intento de sesión y despuésque 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 PasswordEl administrador de la base de datos puede especificar un periodo de graciaPASSWORD_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 intentalogearse hasta que el periodo de gracia vence. Si un usuario no cambia la password dentro del periodode 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. MuchosDBAs 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/hrERROR: ORA-28001: the password has expiredChanging password for hrNew password: ********Retype new password: ********Password changed

16


Historial de Password

Número de password modificadasrequeridas 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


Historial de PasswordEl Historial de Password se asegura que un usuario no pueda reusar una password después de un intervalo de tiempo. Estos chequeos pueden ser implementadosusando uno de los siguientes valores:

• PASSWORD_REUSE_TIME: Especifica que el usuario no puede reusar unapassword hasta el número de días indicado.

• PASSWORD_REUSE_MAX: Específica el número de password modificadasantes 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


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 asegurala complejidad de la password eschequeada antes de ser asignada

PASSWORD_VERIFY_ FUNCTION


Verificación de PasswordAntes 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 cargadaejecutando un script SQL localizado en $ORACLE_HOME/rdbms/admin/utlpwdmg.sqlo 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 BOOLEANSi la función de password levanta una excepción o llega a ser inválida, un mensajede error es retornado cuando el comando ALTER USER o CREATE USER esfinalizado.

18


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_FUNCTIONOracle provee una función de verificación de complejidad de password llamadaVERIFY_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 debecambiar el perfil DEFAULT con el siguiente comando ALTER PROFILE:

ALTER PROFILE default LIMITPASSWORD_LIFE_TIME 60PASSWORD_GRACE_TIME 10PASSWORD_REUSE_TIME 1800PASSWORD_REUSE_MAX UNLIMITEDFAILED_LOGIN_ATTEMPTS 3PASSWORD_LOCK_TIME 1/1440PASSWORD_VERIFY_FUNCTION verify_function;

19


Creando un Perfil de Password

Creando un Perfil de PasswordPara crear un perfil de password, abra Enterprise Manager y navege hasta la páginaAdministration. 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 PasswordSi desea eliminar un perfil, todos los usuarios asignados a ese perfil seranautomáticamente asignados al perfil por defecto.

20


Asignando Usuarios a un Perfil de Password

Asignando Usuarios a un Perfil de PasswordPara 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 usuarioesta logeado cuando se realiza un cambio en su perfil, los cambios no tienen efectoen este usuario hasta la siguiente sesión.La cuenta de usuario puede también ser bloqueada o expirada desde la pagina Edit User.

21


Monitoreando Actividades Sospechosas

Monitorear o auditar debe ser parte integral de los procedimientos de seguridad.Oracle incluye las siguientes herramientas paraauditar:• Auditoria estándar de base de datos• Auditoria basada en valor• Auditoria fina (Fine-grained auditing (FGA))

Monitoreo para actividades sospechosasOracle Database 10g provee 3 tipos diferentes de auditoria. El administrador puede auditar todas lasacciones 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 trabajosobre el servidor. La auditoria puede ser focalizada sólo en aquellos eventos que nos interesa capturaro 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ándoocurrio 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 unaextensión a la auditoria estándar de base de datos, capturando no solo los eventos auditables cuandoocurren, sino también los valores que fueron insertados, borrados o modificados. La auditoria basadaen 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


Comparación de Herramientas de Auditoria

Conjunto fijo de Datos incluyendosentencias SQL

Sentencias SQL (insert, update, delete, y select) basadas sobre el contenido

De Granja Fina

Definidas por el Administrador

Datos cambiados porsentencias DML

Basada en valores

Conjunto Fijo de Datos

Uso de Privilegiosincluyendo acceso a Objetos

Estándar

¿Qué registra?¿Qué es auditado?Tipo de Auditoria

23


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 operativoSe puede auditar:• Eventos de Login• Exercise of system privileges• Exercise of object privileges• Uso de sentencias SQL

Auditoria Estándar de Base de DatosAntes de usar la auditoria es preciso setear primeramente el parámetroAUDIT_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 tablaDBA_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 peroesta mal focalizado. Esta opción captura cualquier operación que afecte a cualquiertabla:

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


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 auditablesAuditando sentencias SQL: La sentencia mostrada en la figura auditara cualquier sentencia queafecte 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 fracasode la acción. Por defecto, cada vez que se ejecuta un privilegio de sistema un registro de auditoria esejecutado. Es posible agrupar esos eventos para que solo se registre uno por sesión (de esta forma sihay 100,000 actualizaciones de registro en una tabla que realiza un usuario, por tanto solo se registraun 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 agruparsepor 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 separarel registro de auditoria generada por cada acción.

25

Especificando opciones de auditoria (Continuación)La opción AUDIT SESSION audita la creación de sesiones de usuario. Puedefocalizarse la auditoria por usuario o éxito/fracaso. Esta opción es única ya quegenera 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 acumuladasobre 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 comandoAUDIT SESSION (no focalizado). En la mayoria de las bases de datos se debeconfigurar AUDIT SESSION WHENEVER NOT SUCCESSFUL porque permitedetectar intentos indebidos de acceso a la base de datos.Nota: A menudo las opciones comienzan como no focalizadas porque no se tienecerteza 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


Viendo Opciones de Auditoria

Opciones Auditoria Objetosdel 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 AuditoriaPara 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 opcionesse 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, updFROM dba_obj_audit_opts WHERE object_name = 'EMPLOYEES‘OBJECT_NAME OBJECT_TY INS UPD------------ --------- --- ---EMPLOYEES TABLE A/S -/-

27


RegistrosAuditoria

Archivo de Parámetros

Especificar opciones auditoria

GenerarRegistro Auditoria

Revisar Información Auditoria

Auditoria Estándar de Base de Datos

DBA Usuario

Habilitar Auditoria de Base de Datos

EjecutarComandos

Database

RegistrarAuditoria

SO

OpcionesAuditoria

Serverprocess

Auditoria Estándar de Base de DatosDespué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ánregistrados en el sistema operativo en archivos. En un ambiente Windows, esto es un eventode 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 queAUDIT_TRAIL está setea a DB, los registros auditables son almacenados en una tabla quees parte del esquema SYS.El mantenimiento de los registros de auditoria es una tarea administrativa importante quedebe 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 mantieneadecuadamente el registro de auditorias, esto puedo consumir mucho espacio de almacenamiento y puede afectar el rendimiento del sistema.

28


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 AuditablesEl acceso a los registros auditables debe ser controlado rigurosamente pues puedecontener información sensitiva para el negocio de la empresa. Usualmente la tareade administrar los registros auditables es llevada por el DBA pero si necesita ser delegada se deben otorgar grant a DELETE_CATALOG_ROLE para borrarinformación.

29


Auditoria basada en Valores

Cambios de Usuario

Confirmados

Dispara Triggers Registro Auditoria escreado por Trigger

E Insertado en una tabla de

auditoria

Cambios hechospor Usuario

Auditoria Basada en ValoresLos 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

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_auditAFTER UPDATE OF salaryON hr.employees REFERENCING NEW AS NEW OLD AS OLD FOR EACH ROW

BEGINIF :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 columnasalary. 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 esquemaSYSTEM). El regitro de auditoria incluirá username, IP address desde donde se haceel cambio, la clave primaria que identifica el registro modificado y el actual salario quese ha modificado.Los triggers de base de datos puede ser usados también para capturar informaciónde conexiones de usuarios en casos donde la auditoria estándar no entrege los datossuficientes. 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

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, salaryFROM employeesWHEREdepartment_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 capturanla información de la sentencia SQL que genero la operación.. La auditoria fina es una extensión quetiene la capacidad de capturan la sentencia SQL que consulta o manipula datos. FGA permite tambiénauditar 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 reunenciertas 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 unatabla 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 dichainformación. Opcionalmente dicho evento puede ejecutar un procedimiento almacenado. FGA automáticamente focaliza la auditoria a sentencias SELECT, en aquellas que retornan cientos de filasse genera solo un registro auditable.

32


32

Politica FGAdbms_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_idFROM employees;

SELECT name, salaryFROM employeesWHERE

department_id = 10;

SECURE.LOG_ EMPS_SALARY

employees

• Define:– Criterio Auditoria– Acción Auditoria

• Es creado con DBMS_FGA .ADD_POLICY

Política FGAEl ejemplo de la figura muestra una Política FGA creada con el procedimientoDBMS_FGA.ADD_POLICY. El procedimiento acepta los siguientes argumentos:Policy NameUsted asigna un nombre a cada vez que crea una Política FGA. El ejemplo muestrael nombre AUDIT_EMPS_SALARY, usando los siguientes argumentos:

policy_name => 'audit_emps_salary'Audit ConditionLa 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 ventasde 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

Política FGA (continuación)Audit ColumnLa 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.ObjectEl 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'

HandlerEs 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 siguientesargumentos:

handler_schema => 'secure'handler_module => 'log_emps_salary'

StatusEl estado indica si la política FGA esta permitida o habilitada. En el ejemplo, los siguientes argumentosestan habilitados para la política:

enable => TRUE

34


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 comola condición de auditoria

ADD_POLICY

DescripciónSubprograma

Paquete DBMS_FGAEl paquete DBMS_FGA es la herramienta de administración para funciones de auditoria fina. Privilegios de Execute sobre DBMS_FGA son necesarios paraadministrar políticas de auditoria fina. Dado que este tipo de auditoria puede contenerinformación sensible para el negocio. Esos privilegios de execute sobre este package deben estar reservados solo para el administrador o DBA.

35


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 FGADeshabilitar 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á habilitarlanuevamente. 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


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íticaSino se desea seguir con una política, usted puede removerla con DBMS_FGA.DROP_POLICY. Todos los argumentos son requeridos.

37


37

Disparando Eventos Auditables

• La siguiente sentencia SQL causa una auditoria:

• La siguiente sentencia no causa una auditoria:

SELECT count(*)FROM hr.employeesWHERE department_id = 10AND salary > v_salary;

SELECT salaryFROM hr.employees;

SELECT last_nameFROM hr.employeesWHERE department_id = 10;

Disparando Eventos AuditablesEn 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.EjemplosLos dos primeros ejemplos de la figura, producen un evento auditable perque accesan la columnasalary y filas con department_id = 10. En el segundo ejemplo, Oracle se da cuenta que hay una políticaasociada a la columna salary que accesan a las filas del departamento 10, a pesar que department_idno 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, entoncesla sentencia SELECT produciría un evento auditable.

38


Vistas Diccionario de Datos

Todas las politicas FGA paraobjetos en el esquema del usuarioactual

USER_AUDIT_POLICIES

Todas las politicas en la base de datos

DBA_AUDIT_POLICIES

Todas las políticas FGA paraobjetos accesados por el usuarioactual

ALL_AUDIT_POLICIES

Todos lso eventos FGADBA_FGA_AUDIT_TRAIL

DescripciónNombre de Vista

Vistas del Diccionario de datosLas entradas auditables de FGA se registran en una tabla separada de las auditoriasde 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


DBA_FGA_AUDIT_TRAIL

SQL> SELECT to_char(timestamp, 'YYMMDDHH24MI')2 AS timestamp,3 db_user,4 policy_name,5 sql_bind,6 sql_text7 FROM dba_fga_audit_trail;

TIMESTAMP DB_USER POLICY_NAME SQL_BIND---------- ------- ----------------- ----------SQL_TEXT-----------------------------------------------0201221740 SYSTEM AUDIT_EMPS_SALARY #1(4):1000SELECT count(*)

FROM hr.employeesWHERE department_id = 10AND salary > :b1

DBA_FGA_AUDIT_TRAILNombre DescripciónTIMESTAMP Fecha y Hora de EjecuciónDB_USER Nombre del usuario de la base de datosOS_USER Nombre del usuario del Sistema OperativoOBJECT_SCHEMA Propietario del objeto auditableOBJECT_NAME Nombre del objeto auditablesPOLICY_NAME Nombre de la política que causo el evento auditableSCN El SCN de la transacciónSQL_TEXT Sentencia SQL que causo el evento auditableSQL_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

DBA_FGA_AUDIT_TRAIL (continuación)Seleccionando desde la Auditoria FGAEl siguiente ejemplo despliega 2 files de auditoria creadas para ejemplos válidos de páginasanteriores. La columna sql_bind en la segunda fila tiene un valor de #1(4):1000, que incluye lassiguientes 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.

EjemploEste 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 A10SQL> COL db_user FORMAT A7SQL> COL policy_name FORMAT A20SQL> COL sql_bind FORMAT A20SQL> COL sql_text FORMAT A60SQL> SQL> SELECT to_char(timestamp, 'YYMMDDHH24MI')2 AS timestamp,3 db_user,4 policy_name,5 sql_bind,6 sql_text7 FROM dba_fga_audit_trail;

TIMESTAMP DB_USER POLICY_NAME SQL_BIND---------- ------- -------------------- ------------------SQL_TEXT----------------------------------------------------------0201221740 SYSTEM AUDIT_EMPS_SALARY #1(4):1000SELECT count(*)

FROM hr.employeesWHERE department_id = 10AND salary > :b1

0201221741 SYSTEM AUDIT_EMPS_SALARYSELECT salaryFROM hr.employees

SQL>

41


Pautas para FGA

• Para auditar todas las sentencias, use la condiciónnull.

• Si intenta agregar una política que ya existe, aparecerá el error ORA-28101.

• Cuando se crea una política, la tabla o vista debeexistir.

• Si la sintáxis de la condición de auditoria es inválida, un error ORA-28112 aparecerá cuando el objetoauditado sea accesado.

• Si la columna auditable no existe en la tabla, las filasno serán auditadas.

• Si el manejador de eventos no existe, no se devuelveningún error y los registros auditables son creados.

Pautas para FGA Condición de AuditoriaCuando se crea una nueva política FGA, la condición por defecto es null, lo quesignifica que todas las sentencias sera auditadas. Error en Nombre de PolíticasEl 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 existsErrores de Objetos AuditadosLa tabla o vista auditada deben existir cuando se crea la política. Sino existe, ustedrecibe un error como el siguiente:

ORA-00942: table or view does not exist

42

Pautas para FGA (continuación)Errores de Condiciones AuditablesSi 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 functionSi la sintáxis de la condición es válida, pero es incorrecta, entonces las filasincorrectas se auditan.Errores de Columnas AuditablesSi 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ánauditadas.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 eventoauditable.

43


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 SYSOPERLos 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 estacerrada, 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 SYSDBAy SYSOPER, pero no captura nada más que el login a menos que este habilitada unaauditoria 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ónaudit_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 plataformasUNIX, os registros son almacenados en $ORACLE_HOME/rdbms/audit.

44


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íticasde seguridad a través de mail haciendo Click en el Link “Subscribe to Security Alerts Here”.

Actualizaciones de SeguridadLas alertas de seguridad Oracle contienen una descripción de las vulnerabilidades, riesgos posibles y grado de exposición asociado a la vulnerabilidad, aplicacionesafectadas 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 quecorrigen las falencias de seguridad.

Jaime Amigo P. © 2006, Santiago - Chile


Fin de la Lección

Documents

Abf leccion 14