Oracle Live

12/04/2016

CAP 4.- Security New Features

Filed under: 1z0-060,Certificaciones — mogukiller @ 6:25 pm

Este capítulo muestra las mejoras en aspecto de seguridad que ha sufrido esta nueva version. Con la intruduccion de nuevos roles, con una auditoria unificada, auditoria de la utilización de privilegios, etc.

1.- Habilitar Unified Audit Data Trail

Unified Audit Data Trail unifica todas las fuentes de auditorias presentes en versiones anteriores. Presentando mejoras en:

  • Consolidacion
  • Seguridad. Ya no se pueden modificar los registros.
  • Performance. Al extraer la informacion de la SGA no penaliza la performance de la base de datos.

Con UADT se registran actividades no solo de la base de datos, sino tambien de operaciones de RMAN, Datapump, Data Mining y ademas esta activado por defecto.

Al crear una base de datos en 12c se encuentra activado el modo mixto, soportando UADT y el metodo tradicional.

Por defecto los registros de la auditoria se almacenan en el tablespace de SYSAUX. Para poder asignarlo a un TS a parte utilizaremos el procedimiento DBMS_AUDIT_MGMT.SET_AUDIT_TRAIL_LOCATION.

Con el nuevo procedimiento, en vez de escribir los trails, estos se van almacenado en unas colas en la SGA. Cuando las colas se llenan el nuevo procedimiento GEN0 se encarga de bajarlas a disco. Existen dos colas, mientras una hace el flush a disco la otra sigue almacenando datos. El tamaño por defecto de las colas es de 1MB pudiendo subir hasta 32MB, configurando el parametro de inicio UNIFIED_AUDIT_SGA_QUEUE_SIZE

Podemos forzar el flush de una cola haciendo:


exec DBMS_AUDIT_MGMT.flush_unified_audit_trail;

Los registros se almacenan en la vista SYS.UNIFIED_AUDIT_TRAIL es una vista basada en la tabla propietaria de AUDSYS. Para consultar esta vista se necesitan los roles de AUDIT_ADMIN y AUDIT_VIEWER.

En Oracle 11g el formato de los trail era Basic Audit Information (BAI). En Oracle 12c el formato es mucho mas extensible Extended Audit Information (EAI) donde cada aplicacion que se audita tiene sus propias columanas.

Para poder capturar trails de una determinada aplicacion es necesario crear una policy. Para otras aplicaciones como por ejemplo RMAN se auditan automaticamente.

2.- Crear y habilitar policies

Se considera una policy un conjunto de audit options. Y se puede evaluar a nivel de sesion o a nivel de instancia.

El modo mixto de auditoria esta habilitado gracias a la policy ORA_SECURECONFIG.

En un entorno multitenant las policies que creemos en CDB$ROOT se consideraran common policies y con la clausula CONTAINER=ALL

Para crear una policy haremos:


-- Audita acciones de un usuario sobre una tabla

CREATE AUDIT POLICY dml_pol
ACTIONS DELETE on MOGU.PRUEBAS,
INSERT on MOGU.PRUEBAS,
UPDATE on MOGU.PRUEBAS;

-- Podemos auditoar todas las acciones sobre una tabla

CREATE AUDIT POLICY dml_pol
ACTIONS ALL ON MOGU.PRUEBAS;

-- Creamos policy condicionales a un usuario

CREATE AUDIT POLICY dml_pol
ACTIONS ALL ON MOGU.PRUEBAS
WHEN 'SYS_CONTEXT(''USERENV'', ''CLIENT_IDENTIFIER'') = ''LUIS''';

-- Audita la utilizacion del privilegio de sistema SELECT ANY TABLE

CREATE AUDIT POLICY audit_select_any_table PRIVILEGES select any table;

-- Audita la utilizacion de un role

CREATE AUDIT POLICY audit_role ROLES admin_app;

Se puede validar las policies configuradas en la vista AUDIT_UNIFIED_POLICIES y la vista AUDIT_UNIFIED_ENABLED_POLICIES para saber cuales estan habilitadas.

Una vez creada una policy es necesario habilitarla:

-- Habilita la policy para todos los usuarios
AUDIT POLICY dml_pol;
-- Habilita la policy solo para MOGU
AUDIT POLICY dml_pol by MOGU;
-- Saca a usuarios de la auditoria
AUDIT POLICY dml_pol except MOGU;
-- Habilitamos una policy para cuando las operaciones son OK | NOK
AUDIT POLICY dml_pol WHENEVER [SUCCESSFUL|NOT SUCCESSFUL]

-- Para deshabilitar una policy hacemos
NOAUDIT POLICY dml_pol;
-- Para borrarla
DROP AUDIT POLICY dml_pol;

3.- Gestion de privilegios

Oracle 12c intenta hacer una segregación de privielgios para evitar dar mas privilegios a un usuaro de lo que necesita. Para ello se generan nuevos roles SYSBACKUP, SYSDB y SYSKM

SYSBACKUP esta pensado para utilizarlo en labores de backup permitiendo:

  • Crear y borrar la base de datos.
  • Crear un control file
  • Flashback database.
  • Create spfile
  • Manage restore point.
  • Startup / Shutdown.

Para conectar seria:

RMAN> connect target “/ as sysbackup”

SYSDB esta pensado para que se utilice con Dataguard Broker. Permite:

  • Startup / Shutdown
  • Manage restore points
  • Flashback Database
  • Enable Fast-Start Failover

SYSKM para utilizar TDE (Transparent Data Encription).

En el proceso de instalacion de 12c se nos da la opcion de crear los grupos de sistema operativo OSBACKUP, OSDG y OSKM con la idea de habilitar la autenticación por sistema operativo.

4.- Auditoria de privilegios

Oracle 12c permite auditar que privilegios asignado a un usuario se estan utilizando y cuales no. Para ello se utilizara la funcion DBMS_PRIVILEGE_CAPTURE.

Existen varios tipos de analisis de privilegios:

  • Para toda la base de datos.
  • Para un role.
  • Privilegios en un determinado contexto.
  • Combinacion de role y contexto.

Una vez elegido el tipo de analisis tenemos que crear una policy. Unicamente puede haber una policy habilitada a la vez.

No se pueden analizar los privilegios de SYS.

Para crear policies utilizaremos la funcion CREATE_CAPTURE del paquete DBMS_PRIVILEGE_CAPTURE. En el parametro type indicamos el tipo de analisis, pudiendo ser:

  • DBMS_PRIVILEGE_CAPTURE.G_DATABASE
  • DBMS_PRIVILEGE_CAPTURE.G_ROLE
  • DBMS_PRIVILEGE_CAPTURE.G_CONTEXT
  • DBMS_PRIVILEGE_CAPTURE.G_ROLE_AND_CONTEXT

-- Analisis de todos los privilegios de la base de datos
 
BEGIN
DBMS_PRIVILEGE_CAPTURE.CREATE_CAPTURE(
        name         => 'all_priv_analysis_pol',
        description  => 'database-wide policy to analyze all privileges',
        type         => DBMS_PRIVILEGE_CAPTURE.G_DATABASE);
END;
 
-- Analisis de los privilegios asignados a PUBLIC
 
BEGIN
DBMS_PRIVILEGE_CAPTURE.CREATE_CAPTURE(
       name         => 'pub_analysis_pol',
       description  => 'Policy to record privilege use by PUBLIC',
       type         => DBMS_PRIVILEGE_CAPTURE.G_ROLE,
       roles        => role_name_list('PUBLIC'));
END;
 
-- Analiza los privilegios  que utiliza el usuario MOGU
BEGIN
DBMS_PRIVILEGE_CAPTURE.CREATE_CAPTURE(
  name         => 'acc_pay_analysis_pol',
  type         => DBMS_PRIVILEGE_CAPTURE.G_CONTEXT,
  condition    => 'SYS_CONTEXT(''USERENV'', ''SESSION_USER'') = ''MOGU''');              <<<<-- con G_CONTEXT es mandatory una condicion
END;

Una vez creada la policy es necesario habilitarla.

EXEC DBMS_PRIVILEGE_CAPTURE.ENABLE_CAPTURE ('all_priv_analysis_pol');

Una vez terminado el periodo de análisis paramos la captura.

EXEC DBMS_PRIVILEGE_CAPTURE.DISABLE_CAPTURE ('all_priv_analysis_pol');

Generamos el informe para analizar la captura.

EXEC DBMS_PRIVILEGE_CAPTURE.GENERATE_RESULT ('all_priv_analysis_pol');

Para visualizar los resultados existen dos vistas: DBA_USED_SYSPRIVS y DBA_USED_OBJPRIVS o se puede utilizar la vista DBA_USED_PRIVS donde esta todo recogido.

Para ver que privilegios no se han utilizado tenemos la vista DBA_UNUSED_PRIVS

Para borrar una policy haremos.

EXEC DBMS_PRIVILEGE_CAPTURE.DROP_CAPTURE ('all_priv_analysis_pol');

5.- Privilegios en llamadas PLSQL.

En Oracle 12c, cuando se realiza una llamada a un procedimiento Oracle evalua si el que llama al procedimiento tiene los privilegios suficientes o si tiene INHERIT PRIVILEGES sobre los objetos del usuario o si tiene INHERIT ANY PRIVILEGES.


GRANT INHERIT PRIVILEGES ON USER MOGU TO EMOGU;

6. Enmascaramiento de datos

Oracle 12c introduce Data Redaction para enmascarar los datos sensibles de una base de datos. Data Redaction no enmascara los datos en disco sino a la hora de devolver los datos al cliente.

El Data Redaction creado sobre una tabla se extrapola a todas sus vistas.

En las sentencias no se enmascara nunca el WHERE, unicamente la parte del SELECT.

No se aplicara Data Redaction en las siguientes operaciones:

  • RMAN
  • Datapump
  • Replication Data.
  • Patching.

Tampoco se aplicara DR sobre los usuarios de SYS y SYSTEM.

Tipos de DR:

  • Full
  • Partial
  • Random
  • Regular Expresion

Full Data Redaction afecta a todo el contenido de la columna y depende del tipo de columna.

Partial Data Redaction se aplica unicamente a parte de la columna delimitada por una posicion inicial y un offset.

Para DR utilizamos el paquete DBMS_REDACT.

Antes de aplicar DR necesitamos crear una policy para indicar el tipo que vamos a elegir. La funcion es ADD_POLICY y el parametro donde se indica el tipo es function_type.

BEGIN
   DBMS_REDACT.ADD_POLICY(
     object_schema        => 'MOGU',
     object_name          => 'PRUEBAS',
     column_name          => 'ID_PRUEBA',
     policy_name          => 'mask_id_prueba',
     function_type        => DBMS_REDACT.FULL,
     expression           => 'SYS_CONTEXT(''USERENV'', ''SESSION_USER'') = ''TEST_USER''');
END;

Random DR en el parametro function_type especificamos DBMS_REDACT.RANDOM.

Regular Expression DR. Sustituye el valor de la columna por una determinada expresion.

BEGIN
 DBMS_REDACT.ADD_POLICY(
   object_schema          => 'mavis', 
   object_name            => 'cust_info', 
   column_name            => 'cc_num',
   policy_name            => 'redact_cust_cc_nums', 
   function_type          => DBMS_REDACT.REGEXP,
   function_parameters    => NULL,
   expression             => '1=1',
   regexp_pattern         => DBMS_REDACT.RE_PATTERN_CC_L6_T4,
   regexp_replace_string  => DBMS_REDACT.RE_REDACT_CC_MIDDLE_DIGITS,
   regexp_position        => DBMS_REDACT.RE_BEGINNING,
   regexp_occurrence      => DBMS_REDACT.RE_FIRST,
   regexp_match_parameter => DBMS_REDACT.RE_MATCH_CASE_INSENSITIVE,
   policy_description     => 'Regular expressions to redact credit card numbers',
   column_description     => 'cc_num contains customer credit card numbers');
END;
/

Se puede dar la situacion que tengamos una vista basada en una tabla a la que le estamos aplicando DR y queremos que esa vista muestre los datos originales. Pues tendriamos que hacer una policy sobre esa vista y en function_type poner DBMS_REDACT.NONE.

Para hacer que a un usuario no se le aplice DR le damos el privilegio de EXEMPT REDACTION.

Una vez creada la polycy la tenemos que habilitar.

 
BEGIN
   DBMS_REDACT.ENABLE_POLICY (
      object_schema    =>  'MOGU',
      object_name      =>  'PRUEBAS',
      policy_name      =>  'mask_id_prueba');
END;
/
 
BEGIN
   DBMS_REDACT.DISABLE_POLICY (
      object_schema    =>  'MOGU',
      object_name      =>  'payment_details',
      policy_name      =>  'redact_card_info');
END;
/

Podemos saber las policies definidas en la vista REDACTION_POLICIES y las columnas implicadas en la vista REDACTION_COLUMNS.

Se puede acceder al laboratorio de Data Redaction aqui

Dejar un comentario »

Aún no hay comentarios.

RSS feed for comments on this post. TrackBack URI

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

Blog de WordPress.com.

A %d blogueros les gusta esto: