1.

Evitar borrar una tabla

CREATE OR REPLACE TRIGGER no_borrar
BEFORE DELETE
ON HR.employees
FOR EACH ROW
################################################################################
#########################
2. Ingreso desde ip's
################################################################################
#########################
AUDITORIA MANUAL:
#verificar que este activado:
select name, value
from v$parameter
where name like 'audit_trail'
#Para activar la auditora:
ALTER SYSTEM SET audit_trail = "DB" SCOPE=SPFILE;
#Para desactivar la auditora ejecutaremos el siguiente comando:
ALTER SYSTEM SET audit_trail = "NONE" SCOPE=SPFILE;
#Nota:
#En Oracle 11g la auditora viene activada por defecto, el valor del parmetro "audi
t_trail" est a "DB".
#comandos
#Para activar la auditora de las instrucciones SQL con el comando audit se necesi
ta el privilegio de sistema AUDIT SYSTEM.
audit session;
#El comando anterior auditar tanto los intentos fallidos como los aciertos.
#Para auditar slo los intentos fallidos utilizaremos el comando:
audit session whenever not successful;
#Para auditar slo las conexiones correctas utilizaremos el comando:
audit session whenever successful;
#Por ejemplo, para auditar los "insert" realizados sobre la tabla "facturacion"
por acceso, el comando ser:
audit insert on FACTURACION by access;
#Nota: al indicar "by access" hay que tener cuidado pues registrar un suceso de a
uditora por cada insert, esto puede afectar al rendimiento. De ser as siempre ser #
mejor optar por "by session" que slo registrar un suceso de auditora por sesin, aunq
ue es menos exaustivo.
#Otro ejemplo, para auditar todas las acciones realizadas en la tabla "contabili
dad" por sesin utilizaremos el siguiente comando:
audit all on CONTABILIDAD by session;
#El comando anterior auditar todas las acciones realizadas sobre la tabla FACTURA
CION (select, insert, update, delete), pero slo un registro de auditora por cada s

esin.
#Otro ejemplo, para auditar las eliminaciones de registros de la tabla "nminas":
audit delete NOMINAS by access;
################################################################################
########################
Oracle pone al alcance del DBA varios niveles de seguridad:
Seguridad de cuentas para la validacin de usuarios.
Seguridad en el acceso a los objetos de la base de datos.
Seguridad a nivel de sistema para la gestin de privilegios globales.
1.1 Seguridad de Cuentas
Para acceder a los datos en una BD Oracle, se debe tener acceso a una cuenta en
esa BD. Cada cuenta debe tener una palabra clave o password asociada. Una cuenta
en una BD puede estr ligada con una cuenta de sistema operativo. Los passwords s
on fijados cuando se crea un usuario y pueden ser alterados por el DBA o por el
usuario mismo. La BD almacena una versin encriptada del password en una tabla del
diccionario llamada dba_users. Si la cuenta en la BD est asociada a una cuenta d
el sistema operativo puede evitarse la comprobacin del password, dndose por vlida l
a comprobacin de la identidad del usuario realizada por el SO.
1.2 Seguridad de Objetos
El acceso a los objetos de la BD se realiza via privilegios. Estos permiten que
determinados comandos sean utilizados contra determinados objetos de la BD. Esto
se especifica con el comando GRANT, conceder. Los privilegios se pueden agrupar
formando lo que se conoce por roles. La utilizacin de los roles simplifica la ad
ministracin de los privilegios cuando tenemos muchos usuarios. Los roles pueden s
er protegidos con passwords, y pueden activarse y desactivarse dinmicamente, con
lo que constituyen una capa ms de seguridad en el sistema.
1.3 Roles del Sistema
Los roles se pueden utilizar para gestionar los comandos de sistema disponibles
para los usuarios. Estos incluyen comandos como CREATE TABLE o SELECT ANY TABLE.
Todos los usuarios que quieran acceder a la BD deben tener el rol CONNECT; aque
llos que necesiten crear segmentos necesitaran el rol RESOURCE. Un usuario con e
l rol DBA tiene derecho para ver y manejar todos los datos de la BD. En Oracle C
ONNECT, RESOURCE y DBA son roles de sistema. Las acciones contra cada tipo de ob
jeto son autorizadas por privilegios separados. As, un usuario puede tener conced
ido el privilegio CREATE TABLE, pero no el ALTER TABLE.