Games of Roles (Season 2): Controla a tus super usuarios

Si deseas ver la primera arte de este artículo sigue este enlace.

Realms (Reinos)

Los usuarios con el rol DBA tienen los privilegios SELECT (y UPDATE, DELETE, o INSERT) ANY  TABLE y, por lo tanto, todavía pueden manipular datos en la tabla AHORROS, observa Cersei, preguntándose si hay una manera de evitarlo. Hay, responde Tycho. Implica crear un "círculo de protección" especial conocido como un Realm en Oracle Database Vault y colocar la tabla dentro de él. Solo el usuario administrador de Oracle Database Vault creado anteriormente, DVADMIN, puede crear dominios. Tycho inicia sesión como DVADMIN y ejecuta el SQL que se muestra en el Listado 1 para crear un Realm denominado BRAAVOS Schema Realm. El parámetro AUDIT_OPTIONS muestra qué nivel de auditoría debe habilitarse para las operaciones en el ámbito. Tycho elige crear pistas de auditoría solo para intentos fallidos de controlar la cantidad de información de seguimiento de auditoría generada. Menciona que luego explicará los detalles de la auditoría.

-- Listado1: Como DVADMIN, Crear un Realm

begin

 dbms_macadm.create_realm(

  realm_name    => 'BRAAVOS Schema Realm',

  description   => 'Realm for entire BRAAVOS schema',

  enabled       => dbms_macutl.g_yes,

  audit_options => dbms_macutl.g_realm_audit_fail, 

                  

  realm_type    => 1

 ) ;

end;

/

-- Como DVADMIN, añadir un objeto al Realm 

begin

  dbms_macadm.add_object_to_realm (

    realm_name   => 'BRAAVOS Schema Realm',

    object_owner => 'BRAAVOS',

    object_name  => 'ACCOUNTS',

    object_type  => 'TABLE'

  );

end;

/

A continuación, Tycho agrega la tabla CUENTAS al reino que acaba de crear, usando el SQL que se muestra en el Listado 2, nuevamente como el usuario DVADMIN. Después de eso, inicia sesión como usuario de WEBAPP1 e intenta seleccionar de la tabla:

-- Listado2: Como WEBAPP1

SQL> select * from Braavos.accountss;

select * from Braavos.savings

                   *

ERROR at line 1:

ORA-01031: insufficient privileges

Petyr está perplejo. Refiriéndose a la secuencia de comandos setup.sql, ella señala que el usuario de WEBAPP1 sí tiene privilegios SELECT en la tabla, por lo que la instrucción SELECT no debería haber fallado. El motivo es simple, explica Tycho: la tabla está protegida por el reino, que tiene prioridad sobre los privilegios típicos de la base de datos de Oracle. Tycho luego agrega al usuario WEBAPP1 como un usuario autorizado del reino, usando el SQL, tal y como e muestra a continuación.

-- Listado3: Añadiendo un usuario autorizado

begin

  dbms_macadm.add_auth_to_realm(

    realm_name    => 'BRAAVOS Schema Realm',

    grantee       => 'WEBAPP1',

    auth_options  => dbms_macutl.g_realm_auth_participant

  );

end;

/

Con el usuario de WEBAPP1 permitido dentro del dominio, se respetarán los privilegios típicos de la base de datos Oracle del usuario, como SELECT en la tabla. Debido a que ni siquiera los privilegios SYSDBA están permitidos dentro del reino, el poderoso privilegio del sistema SELECT ANY TABLE no sirve para las tablas dentro de ese reino y, por lo tanto, su instrucción SELECT falla con un error de "privilegios insuficientes",  lo que Cersei, nuestra auditora IT, quería.

Vistas del diccionario de datos de Oracle.

Cersei y Petyr ahora son visiblemente felices; ambos obtuvieron lo que querían. Pero tienen más preguntas: ¿Cómo conocemos los distintos reinos, quiénes son los usuarios autorizados, etc.? Hay varias vistas de diccionario de datos, explica Tycho. Señala algunas importantes que son propiedad de un esquema llamado DVSYS, que se crea cuando Oracle Database Vault está activado:

• DVSYS.DBA_DV_REALM muestra todos los reinos creados.
• DVSYS.DBA_DV_REALM_OBJECT muestra los objetos dentro de un reino.
• DVSYS.DBA_DV_REALM_AUTH muestra a todos los usuarios autorizados para acceder a los objetos en los reinos.

Informes de auditoría

Cersei recuerda a todos que un requisito muy importante es capturar el historial de los cambios y las infracciones, los rastros de auditoría, de tal manera que el administrador de seguridad, pero no el usuario de DBA, pueda verlos. Es posible, continúa Tycho, a través de dos clases principales de pistas de auditoría (audit trails):

• Auditoría de configuración Esta ruta de auditoría registra los cambios en varios elementos de configuración, como los reinos creados, los usuarios autorizados y los objetos ubicados en los reinos. El recorrido está disponible como una vista DV $ CONFIGURATION_AUDIT en el esquema DVSYS. Esta política de auditoría no se puede desactivar. Todos los cambios a la configuración de Oracle Database Vault serán capturados.
• Auditoría de cumplimiento. Esta ruta de auditoría registra las actividades realizadas en la base de datos relacionadas con Oracle Database Vault. Está disponible a través de la vista DV $ ENFORCEMENT_AUDIT en el esquema DVSYS. El Listado 4 muestra la declaración de SQL que Tycho usa para ver las acciones que causaron una violación de dominio en esta pista de auditoría. Apuntando al primer registro en la salida, muestra que el usuario de WEBAPP1 emitió la declaración
• SELECT * FROM BRAAVOS.ACCOUNTS, el 17-DEC-15 a las 08.11.31.123646 PM y recibió un error ORA-1031 (privilegios insuficientes). Esto es cuando el usuario de WEBAPP1 aún no estaba autorizado para el reino y trató de seleccionar de la tabla AHORROS. Esta vista tiene varias columnas valiosas, incluidas OS_USERNAME, USERHOST e INSTANCE_NUMBER, que muestran el nombre de usuario del sistema operativo que emitió la instrucción, el nombre del sistema del cliente y la Id. De la instancia (para una base de datos Oracle Real Clusters de aplicaciones [Oracle RAC]) respectivamente .

Comprobación de un rastro de auditoría para las vulneraciones de dominio de la base de datos Oracle Vault

-- Listado4: Como DVADMIN

select extended_timestamp, username, action_command, returncode

from dvsys.dv$enforcement_audit

where action_name = 'Realm Violation Audit'

and action_object_name = 'BRAAVOS Schema Realm'

order by 1,2,3

/

Rules (Reglas) 

Una de las políticas permanentes de la operación de TI en Braavos es rechazar cualquier operación de lenguaje de definición de datos (DDL) durante la semana, para evitar problemas de rendimiento y posibles ataques contra la base de datos. Actualmente, esta política se aplica a través de disparadores de DDL después de nivel de esquema que simplemente generan una excepción cuando las sentencias DDL se ejecutan durante los días laborables. Pero estos disparadores son propiedad de SYS, observa Cersei, por lo que los DBA pueden potencialmente manipular el efecto de estos desencadenantes, incluso incluso suprimirlos. Para reducir la posibilidad de que una cuenta poderosa como el DBA provoque un ataque, y con un espíritu de segregación de deberes, Cersei se pregunta si sería posible hacer cumplir esta política, no a través de desencadenantes propios de SYS, y por lo tanto, imposibilitaría que el política a ser influenciada por los DBA.

-- Listado5:Como DVADMIN, Configuración de reglas en Oracle Database Vault

-- Primero crea una regla

begin

   dvsys.dbms_macadm.create_rule (

      rule_name => 'Weekday',

      rule_expr => 'to_char(sysdate,''DY'') not in

             (''MON'',''TUE'',''WED'',''THU'',''FRI'')'

          );

end;

/

-- Luego crea un conjunto de reglas

begin

   dvsys.dbms_macadm.create_rule_set(

      rule_set_name => 'WEEKDAY_RULE_SET',

      description   => 'Weekday',

      audit_options => dbms_macutl.g_ruleset_audit_fail +

                      

      enabled       => dbms_macutl.g_yes,

      eval_options  => dbms_macutl.g_ruleset_eval_any,

      fail_options  => dbms_macutl.g_ruleset_fail_silent,

      fail_message  => 'Security Doesn''t Allow This Operation on a Weekday',

      fail_code        => 20001,

      handler_options  => dbms_macutl.g_ruleset_handler_off,

      handler          => ''

   );

   dvsys.dbms_macadm.add_rule_to_rule_set(

      rule_set_name => 'WEEKDAY_RULE_SET',

      rule_name     => 'Weekday',

      rule_order    => 1

   );

end;

/

-- Cree una regla de comando que impida que la tabla truncar

begin

   dvsys.dbms_macadm.create_command_rule(

       command=> 'TRUNCATE TABLE',

       rule_set_name => 'WEEKDAY_RULE_SET',

       object_owner => 'BRAAVOS',

       object_name => '%',

       enabled => 'Y'

   );

end;   

/

Es, asegura Tycho, con reglas en Oracle Database Vault. Tycho configura la regla que se muestra en el Listado 5, utilizando los siguientes pasos:

• Cree una regla que muestre el período permitido. Para el ejemplo, Tycho especifica que el período no es un día laborable.
• Cree un conjunto de reglas. Tycho especifica que cuando se infringe la regla, el usuario debe obtener un error ORA-20001 con este mensaje personalizado: "La seguridad no permite esta operación en un día laborable".
• Agregue la regla al conjunto de reglas.
• Cree una "regla de comando" en Oracle Database Vault que impida una acción específica. Para el ejemplo, Tycho elige evitar TRUNCATE TABLE en todas las tablas del esquema de BRAAVOS.
• Después de configurar la regla, Tycho inicia sesión como el usuario WEBAPP1. La reunión de hoy es un día laborable, por lo que emite el siguiente SQL:

SQL> truncar la tabla Braavos.t1;
tabla truncada Braavos.t1
                    *
ERROR en la línea 1:
ORA-47306: 20001: la seguridad no permite esta operación en un día laborable


La operación falla y el mensaje de salida proporciona una explicación bastante clara. La aplicación de esta regla se realiza a través de Oracle Database Vault, no desencadenadores, por lo que los usuarios de DBA no pueden alterar la configuración o ignorar esta regla. Solo los administradores de Oracle Database Vault pueden cambiarlo. Las reglas se pueden definir para cualquier tipo de cheque, explica Tycho, como verificar una dirección IP específica. Cersei no podría estar más feliz.