Oracle y Principales Regulaciones de datos en España (Parte 2)

En nuestra primera parte hablamos de las regulaciones ENS y LOPD y como abordarlas usando los productos de Oracle. Veamos ahora otras regulaciones y como Oracle nos puede ayudar.

Esquema Nacional de Interoperabilidad (España)

Considerando que las recientes leyes 39/2015 (Procedimiento Administrativo Común de las Administraciones Públicas), del 2 de octubre pasado y 40/2015 (Régimen Jurídico del sector Público) consagran definitivamente el uso de los medios electrónicos en las relaciones entre los ciudadanos y sus Administraciones Públicas, y de estas entre sí, varias entidades públicas vienen exigiendo que las soluciones y servicios prestados por terceros sean evidenciadas a través de una auditoría independiente.

General Data Protection Regulation (Europa)

Con toda la actividad en torno al nuevo Reglamento General de Protección de Datos (GDPR) de la Unión Europea, algunas organizaciones se esfuerzan por comprender el impacto que tendrá, incluidas, entre otras, las siguientes:

• Multas potenciales hasta el 4% de la facturación anual de ingresos y costos legales y recursos.
• Revisión y modificación de procesos, aplicaciones y sistemas de la organización.
• Nuevos y más estrictos requisitos de privacidad y seguridad que deben abordarse.

Abordar el cumplimiento de la GDPR requiere una estrategia coordinada que involucre a diferentes entidades de la organización, incluidas las legales, los recursos humanos, el marketing, la seguridad, la informática y otros. El tema puede involucrar información recopilada de varias entidades (clientes y empleados), así como también comunicaciones coordinadas y tecnología utilizada.

Por lo tanto, las organizaciones deben tener una estrategia y un plan de acción claros para abordar los requisitos del GDPR con miras a la fecha de vencimiento del 25 de mayo de 2018.

Aprovechando nuestra experiencia acumulada a lo largo de los años y nuestras capacidades tecnológicas, Oracle se compromete a ayudar a los clientes a implementar una estrategia diseñada para abordar el cumplimiento de la seguridad GDPR. Este artículo explica cómo se pueden utilizar las soluciones de Oracle Security para ayudar a implementar un marco de seguridad que se dirija a GDPR.

Definir una estrategia de seguridad para enfrentar amenazas, reducir el riesgo y mantener el cumplimiento continuo

Es importante tener una estrategia global que se adapte fácilmente a este panorama regulatorio en constante cambio.

El hecho de que existan más y más regulaciones de seguridad se puede explicar, en parte, por el aumento en las brechas de datos y los incidentes de seguridad cibernética. Ya sea que impliquen espionaje, crimen organizado o delitos relacionados con información privilegiada, los cibercriminales están obteniendo beneficios ilícitos de los mal diseñados sistemas de tecnología de la información. Esto finalmente pone en peligro el libre flujo de información, que es una de las claves para una economía y una sociedad prósperas.

GDPR promueve el uso de mejores prácticas y conceptos de seguridad bien establecidos. GDPR requiere "controladores" (como un cliente contratando servicios) y "procesadores" (como proveedores de servicios en la nube) para adoptar medidas de seguridad adecuadas diseñadas para garantizar un nivel de seguridad apropiado al nivel de riesgo que pueda afectar los derechos y libertades de los individuos cuyos datos está siendo recopilados y utilizados por el controlador ("sujetos de datos"). La ley entonces insiste en el análisis de riesgos y la implementación de medidas de seguridad (también conocidas como controles de seguridad) para abordar esos riesgos.

En general, GDPR aborda los principios clave:

• Seguridad
• Confidencialidad
• Integridad
• Disponibilidad de sistemas y datos. 

Oracle tiene una larga historia y un historial comprobado de seguridad de datos y sistemas. La seguridad de Oracle incluye un conjunto completo de soluciones híbridas en la nube, desde el chip hasta las aplicaciones, que ayudan a prevenir, detectar, responder y predecir amenazas de seguridad; también puede ayudar a abordar regulaciones como el GDPR.

Los beneficios de implementar estratégicamente la tecnología correcta, con controles de seguridad efectivos, pueden ayudar:

• Tratar los requisitos reglamentarios
• Reducir el riesgo (ya sea impulsado por el cumplimiento normativo u otras necesidades)
• Mejorar la ventaja competitiva al permitir una mayor flexibilidad y un tiempo de comercialización más rápido
• Habilitar transformaciones digitales.

En última instancia, la implementación de una seguridad efectiva ofrecerá a las organizaciones la oportunidad de mejorar su seguridad de TI y su organización de seguridad de TI.

Artículos clave que afectan la seguridad de TI

Con 99 artículos y 173 considerandos, GDPR incluye algunos requisitos clave que afectan directamente la forma en que las organizaciones implementan la seguridad de TI.

La protección de las personas cuyos datos personales se recopilan y procesan es un derecho fundamental que necesariamente incorpora la seguridad de TI. En la sociedad moderna, los sistemas de TI son omnipresentes y los requisitos de GDPR requieren una buena seguridad de TI.

En particular, para proteger los datos personales, es necesario, lo siguiente:

• Sepa dónde residen los datos (inventario de datos)
• Revise y, cuando sea necesario, modifique las aplicaciones existentes (modificación de la aplicación)
• Integrar la seguridad en la arquitectura de TI (integración de arquitectura)
• Comprender la exposición al riesgo (conciencia del riesgo)

En la siguiente tabla destaca los artículos de GDPR más relevantes que hablan sobre seguridad de TI:

Categoría Seguridad	Referencia a artículo del la GDPR
Conciencia del riesgo	Art. 35 Evaluación de impacto de la protección de datos Solicitud
Inventario de datos	Art. 30 Registros de procesamiento
Modificación de la aplicación	Art. 15 Derecho de acceso del interesado Art. 16 Derecho a la rectificación Art. 17 Derecho a borrado ('derecho al olvido') Art. 18 Derecho a la restricción del procesamiento Art. 19 Obligación de notificación con respecto a la rectificación o borrado de datos personales o restricción del procesamiento Art. 20 Derecho a la portabilidad de datos
Arquitectura de integración	Art. 5  Principios relacionados con el procesamiento de datos personales Art. 24 Responsabilidad del controlador Art. 25 Protección de datos por diseño y por defecto Art. 28 Procesador Art. 32 Seguridad del procesamiento Art. 34 Comunicación de una violación de datos personales al sujeto de los datos

La creación y mantenimiento de un inventario de datos es un requisito en virtud del artículo 30 (registros de procesamiento) del GDPR, y más generalmente, también el punto de partida de cualquier actividad relacionada con la recopilación y el manejo de datos personales.

La mitigación de riesgos es una parte importante de la buena seguridad de TI. Las organizaciones deben mitigar los riesgos que pueden conducir a una violación de datos personales y deben considerar ejecutar una evaluación de seguridad y riesgo. 

Para ciertos derechos del sujeto de los datos (artículos 15 a 20), es posible que deba implementar cambios que habiliten estos derechos (por ejemplo, "derecho al olvido"). Debido a que los cambios se implementan dentro de aplicaciones específicas que pueden contener información de los sujetos de datos, es necesario conocer el modelo de datos específico y la lógica de negocios para ejecutar la función solicitada.

Se pueden implementar medidas adicionales dentro de la arquitectura. Por ejemplo, este es el caso del cifrado de red o cifrado base de datos. Las medidas que es posible implementar en la arquitectura son normalmente más sencillas y menos costosas que las modificaciones de la aplicación, y en general son más sólidas porque no están limitadas por la necesidad de conocer los modelos de datos de la aplicación y la lógica empresarial. En las multinacionales (si, las que estamos pensando todos), donde a menudo ocurre una "profunda" estratificación del sistema de TI y falta de conocimiento de la aplicación, este puede ser un enfoque más fácil para ayudar a proteger los datos personales.

Oracle Security Solutions y GDPR

El siguiente diagrama proporciona una representación de alto nivel del marco de soluciones de seguridad de Oracle, que incluye una amplia gama de productos y servicios en la nube.

Descubrimiento. Productos locales y servicios en la nube que pueden ayudar a descubrir datos personales y flujos de datos de mapas. Esta la tecnología incluye la disciplina del gobierno de datos y proporciona capacidades tales como el linaje de datos, el activo

inventario y descubrimiento de datos.

Enriquecimiento. El enriquecimiento incluye modificaciones de la aplicación que pueden ser necesarias para cumplir con los derechos de los datos

sujeto (Art. 15-20). Además, puede ser necesario consolidar los datos del cliente para obtener una vista única de los datos sujetos en toda la organización.

Fundamento. El conjunto completo de tecnologías operacionales maduras que forman parte del ADN de Oracle para habilitar buena seguridad de TI con énfasis en la disponibilidad y el rendimiento de los servicios. Esto incluye la nube híbrida soluciones desde arquitectura de máxima disponibilidad y sistemas diseñados hasta sistemas operativos y procesadores. Estas soluciones pueden ayudar a abordar la "disponibilidad y resistencia de los sistemas y servicios de procesamiento; y la capacidad de

restablecer la disponibilidad y el acceso a los datos personales de manera oportuna en el caso de una falla física o técnica incidente "(Art. 32).

Realización. Las tecnologías en la nube híbrida de Oracle que imponen políticas de seguridad y controles que protegen a las personas, software y sistemas. Esto abarca productos y servicios que brindan información predictiva, preventiva, detectivesca y controles de seguridad receptivos a través de la seguridad de la base de datos, gestión de identidad y acceso, monitoreo, administración, y análisis de comportamiento del usuario.

Soluciones de seguridad (aplicación)

Los controladores y procesadores de datos deben implementar medidas de seguridad adecuadas diseñadas para garantizar que el nivel de seguridad sea apropiado para los riesgos asociados con los datos que se procesan, como se describe en el artículo 32 GDPR ("seguridad del procesamiento").

El artículo 32 hace referencia a la seudonimización y al cifrado como ejemplos de posibles medidas de seguridad apropiadas. El GDPR finalmente deja la decisión y la responsabilidad a las organizaciones responsables de implementar un marco de seguridad para elegir las medidas apropiadas que garanticen la confidencialidad, la integridad, la disponibilidad y la capacidad de recuperación de datos y sistemas. Una idea errónea común, a menudo dispersada por los proveedores de seguridad, es que el GDPR enumera las tecnologías específicas que se aplicarán. En realidad, el GDPR responsabiliza al controlador y al controlador y requiere que consideren los riesgos asociados con los datos que manejan y adopten los controles de seguridad adecuados para mitigar estos riesgos. Las organizaciones no necesariamente abordan incluso los controles de seguridad más básicos que incluyen, por ejemplo:

• Cifrar datos confidenciales en reposo y en tránsito
• Sistemas de parches dentro de un marco de tiempo razonable
• Recoge los registros del sistema para encontrar actividad anómala
• Mantener el "privilegio mínimo" o "separación de deberes" para cuentas privilegiadas
• Controlar el acceso a, o la distribución de, credenciales de usuario de producción
• Máscaras de datos de producción que se copian en entornos de desarrollo

La sección de aplicación del marco de soluciones de Oracle incluye cuatro grupos que abarcan medidas de seguridad básicas que las organizaciones deberían considerar implementar.

Protege los datos. La implementación del cifrado para datos en reposo y en movimiento es uno de los primeros pasos más comunes para la protección de datos, ya que es relativamente simple y eficaz. La encriptación a menudo se implementa porque está diseñada para evitar el acceso no autorizado, es transparente para las aplicaciones y los usuarios, proporciona un fuerte control preventivo y las soluciones modernas suelen experimentar un impacto de bajo rendimiento. Las tecnologías adicionales de protección de datos incluyen la gestión de claves de cifrado, la redacción de datos de capa de aplicación y el enmascaramiento de datos de producción sensibles para su uso en entornos no productivos con fines de prueba y desarrollo.

Controles de acceso. El cifrado de datos sin controles de seguridad que determinan quién tiene acceso autorizado no tiene sentido. Por lo tanto, es necesario implementar tecnología de acceso y gestión de identidades tanto para los usuarios de la aplicación como para el personal de TI, incluidos los administradores del sistema.

Monitorear, bloquear y auditar. Con las amenazas de seguridad innovadoras de hoy en día, es fundamental implementar una supervisión inteligente y automatizada de incidentes de seguridad y rendimiento. Los componentes y aplicaciones de software producen registros y pistas de auditoría. Para mitigar las infracciones de datos, es fundamental recopilar y analizar feeds y registros de amenazas internas y externas para detectar y mitigar las amenazas.

Configuraciones seguras. Para una seguridad de seguridad adecuada, el software debe actualizarse, configurarse correctamente y parchearse regularmente. La gestión de configuración segura se requiere cada vez más como parte de las mejores prácticas internacionales porque los ciberdelincuentes a menudo aprovechan las vulnerabilidades del software no parcheado para robar datos confidenciales

.

Estos cuatro requisitos de seguridad forman parte de muchos requisitos normativos globales y de las mejores prácticas de seguridad conocidas:

• ISO 27000
• NIST 800-53
• PCI-DSS 3.2
• OWASP 

Productos de seguridad de Oracle que pueden ayudar a la dirección GDPR

Oracle ofrece productos de seguridad en las instalaciones y en la nube para entornos de nube híbrida que están diseñados para ayudar a proteger los datos, administrar las identidades de los usuarios y supervisar y auditar los entornos de TI. La siguiente tabla proporciona una descripción breve del producto organizada por el tipo de medida de seguridad. Cada producto ofrece más funcionalidades que las descritas, por lo que debe consultar con su representante de ventas de Oracle para obtener más detalles.

¿Hay vida más allá de Oracle? GDPR:

Los contratos de servicios gestionados por terceros y de alojamiento, se han de reescribir.

Este mismo artículo, lo puedes encontrar en Linkedin

Poco a poco se acerca el año 2018, dado el grado de tercerización de servicios que actualmente tenemos en España, este efecto secundario, dentro de la aplicación de la GDPR, lo encuentro interesante y digno de ampliar.

Si bien las multas principales bajo GDPR de hasta 4% de la facturación global llaman la atención, la industria de servicios administrados enfrentará algunas obligaciones costosas y disposiciones contractuales detalladas a partir del próximo año. En muchos sentidos, los proveedores de servicios administrados entran en el proceso de cumplimiento por primera vez.

En cuanto a la industria europea de TI, dice que los contratos para los proveedores de servicios administrados actualmente son muy leves en cuanto a las provisiones. Los clientes importantes pueden tener sus propios corredores en sus tratos con proveedores, pero en la práctica, todo lo que exige la directiva actual es que los proveedores de servicios tomen "medidas apropiadas". GDPR cambiará el panorama para los contratos de servicios gestionados y habrá muchas nuevas cláusulas que deberán incluirse.

Por ejemplo: las cláusulas requeridas ahora están en las disposiciones para tomar "medidas de seguridad apropiadas" y actuar solo según las instrucciones del controlador.

En el futuro las cláusulas adicionales bajo GDPR significarán:

• Control sobre la subcontratación (subproceso).
• Notificación de infracciones de datos y de los servicios de asistencia que responde a ellas.
• Derechos de auditoría.
• Asistencia para responder a los datos que ejercen sus derechos.
• Eliminación / devolución de datos personales en la terminación.

Los clientes insistirán en tener derechos de auditoría, control sobre los subcontratistas, incluso sobre qué proveedores de soluciones son aceptables. Tienen derecho a oponerse a determinados proveedores y todo esto debe estar cubierto en el contrato, y la lista de disposiciones se ampliará.

¿Cuándo estás sujeto a las reglas de protección de datos? 

Si solo proporciona un centro de datos físico, probablemente no sea parte de él.  Ya no debería existir solamente el cumplimiento como tal - la organización en este momento puede necesitar solo mostrar conformidad y hacer presentaciones ante el regulador. GDPR sugiere que estas presentaciones serán reemplazadas por registros internos. Las nuevas reglas de GDPR pueden cambiar esto, pero todavía no está claro si los países y regiones individuales dejarán de tener que presentar solicitudes.

Se necesitarán oficiales de protección de datos (auditores) para demostrar que las organizaciones están cumpliendo e incorporando una cultura de privacidad. La privacidad por diseño se debe ver como una buena práctica e incorporada en los proyectos desde el principio, por lo que los desarrolladores se verán afectados. De acuerdo con GDPR, habrá una obligación de incluir esto por primera vez, con privacidad por defecto. Tendrán que mostrar por qué se recopilan los datos, el alcance de los datos y qué se excluye.

Hay mucho trabajo adicional: si una empresa enfrenta un alto riesgo de impacto en la pérdida de datos, deberá consultar al regulador. Y surgirá un nuevo grupo de personas, los oficiales de protección de datos, pero es probable que se convierta en un requisito formal si se cumplen ciertos criterios. Estos incluyen autoridades públicas o cualquier persona que realice un monitoreo a gran escala de individuos, como publicidad, rastreo de imágenes CCTV o el uso de datos confidenciales, como datos de salud o políticos.

Las reglas especiales de recursos humanos se aplican a aquellos oficiales de protección de datos que no pueden ser despedidos por dar consejos que no le agradan al propietario de la empresa. Se supone que el DPO debe ser imparcial, una tarea compleja, preveo para las personas que ocupen estos puestos.

En resumen:

Bajo el régimen actual (ENS y LOPD, principalmente):

• Los controladores de datos son responsables de los requisitos.
• Multa máxima por incumplimiento, sobre el medio millón de euros.
• No hay responsabilidad para los procesadores, excepto en virtud de sus acuerdos contractuales con un controlador de datos.

Bajo el GDPR:

• Los procesadores tienen responsabilidad legal; no sola bajo contratos.
• El artículo 28 establece una larga lista de requisitos que deben incluirse en los contratos entre controladores y procesadores, y los procesadores tienen aún menos discreción sobre cómo pueden llevar a cabo actividades de procesamiento.
• La mayoría de los operadores de centros de datos actúan como controladores de datos con respecto a los datos personales que realmente procesan.
• Las personas tienen derechos mejorados, incluida la portabilidad de datos y el derecho al olvido.

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.