Transparent Data Encryption – Creación de wallets

Cuando se desea cifrar la información dentro de una base de datos Oracle, se recomienda usar el producto Transparent Data Encryption (TDE) que forma parte de Advanced Security Option (ASO). Esta opción de la BBDD, como su nombre indica, permite cifrar los datos de manera “trasparente” para las aplicaciones, esto es, que las aplicaciones sigan accediendo a los datos normalmente (como lo hacían antes del cifrado): no es necesario modificarlas ni adaptarlas, pero a nivel de sistema operativo/backups los datos quedan almacenados en forma cifrada, evitando que si alguien tienen acceso a ellos pueda extraer la información. ASO es una opción disponible en Oracle Database Enterprise Edition.

Arquitectura TDE

TDE es capaz de utilizar diferentes algoritmos al cifrar la información y todos ellos hacen uso de una clave de cifrado maestra (Master Encryption Key). Esta clave se guarda en un almacén externo de claves (keystore) que puede ser hardware o software. En sqlnet.ora se indica dónde está el almacén de claves y de qué tipo es. Es altamente recomendable hacer backup del almacén de claves al mismo tiempo que se hace backup de la base de datos.

A continuación vamos a hablar de las opciones existentes para crear un almacén de claves software en nuestro entorno, consistentes en hacer uso de wallets de Oracle. Existen 3 tipos de wallets (Password-based, Auto-login y Local auto-login) y se deberá escoger dependiendo de las necesidades de cada entorno. El siguiente paso sería cifrar la información de nuestra base de datos, pero eso ya cae fuera del alcance de este post.

Nota: Todos los ejemplos se han realizado en una base de datos 11gR2 Enterprise Edition.

1) Password-based
Los wallets basados en password o password-based necesitan de su apertura explícita con una contraseña antes de poder ser usados. Si no se hace así, al intentar acceder a los datos cifrados la base de datos da el error ‘ORA-28365: wallet is not open’.

Hay que diferenciar entre la contraseña para abrir el wallet y la Master Encryption Key. La primera es la que nos permite acceder al contenido del wallet y hacerlo disponible a la base de datos. La segunda es la que se utiliza para cifrar los datos de la base de datos. Pueden ser iguales, aunque se recomienda que ambas sean contraseñas complejas y diferentes.

Para crear un wallet de este tipo se puede hacer de dos formas. La primera ejecutando desde sqlplus:

ALTER SYSTEM SET ENCRYPTION KEY IDENTIFIED BY "password";

Lo que esta sentencia hace realmente es asignar la Master Encryption Key al wallet. Dado que no tenemos un wallet definido en nuestro entorno, lo crea con la Master Encryption Key especificada en una ruta por defecto (ORACLE_BASE/admin/DB_UNIQUE_NAME/wallet o también ORACLE_HOME/admin/DB_UNIQUE_NAME/wallet) que no es necesario registrar en el fichero sqlnet.ora. El password para abrir el wallet y la Master Encryption Key serán idénticos.

Si cuando se crea el wallet de esta manera da el error ‘ORA-28368: cannot auto-create wallet’, suele ser porque no existen los directorios y es necesario crearlos manualmente. Una vez creado, se puede consultar información del wallet en la vista V$ENCRYPTION_WALLET:

SQL> select * from V$ENCRYPTION_WALLET;

WRL_TYPE             WRL_PARAMETER                                                STATUS
-------------------- ------------------------------------------------------------ ------------------
file                 /u01/app/oracle/product/11.2.0/dbhome_2/admin/orcl/wallet    OPEN

Si se renicia la base de datos se puede abrir el wallet ejecutando:

SQL> ALTER SYSTEM SET ENCRYPTION WALLET OPEN IDENTIFIED BY "welcome1";

System altered.

Leer más…

La arquitectura non-CDB de Oracle Database tiene los días contados

Oracle recomienda el uso de la arquitectura CDBA estas alturas, 2 años después del anuncio de la versión 12c, todos sabemos que el acrónimo CDB se refiere (en el mundo Oracle) al Multitenant Container Database.

En Database Upgrade Guide de la versión 12.1.0.2 podemos leer que la arquitectura non-CDB ya está obsoleta (deprecated) y podría dejar de estar soportada y disponible en las siguientes versiones de 12c y posteriores.

¿Qué implicación para nosotros, los clientes y profesionales que trabajamos con las bases de datos Oracle, tiene esta noticia? A mi parecer está claro que es a donde quiere dirigirse Oracle con las próximas versiones, lo que significa que en el futuro toda la base instalada será del tipo CDB. Eso obliga a tomar una decisión para los upgrades de las instalaciones existentes o para las instalaciones nuevas: ¿instalamos siguiendo ya la arquitectura CDB o elegimos usar la 12c como non-CDB?

Es un tema importante ya que es muy fácil decidirse por la arquitectura non-CDB, por lo conocida que es o por el desconocimiento de que, aunque la opción multitenant tiene que ser licenciada aparte, se puede usar la arquitectura CDB como singletenant sin coste adicional. No obstante, más tarde o más temprano tocará “abrazar” estas nuevas funcionalidades y familiarizarse con nuevas opciones, comandos, etc., y creo que, cuanto antes se haga esta transición más tiempo habrá hasta el momento inevitable, cuando ya no habrá la opción de elegir entre CDB y non-CDB.

Dicho esto, no todas las instalaciones se pueden migrar ya a CDB; hay una lista de características no soportadas o restringidas para esta arquitectura (la podemos encontrar en Readme Information for Oracle Database 12c Release 1 (12.1.0.2) sección 2.2.1):

  • DBVERIFY
  • Data Recovery Advisor
  • Flashback Pluggable Database
  • Flashback Transaction Backout
  • Database Change Notification
  • Continuous Query Notification (CQN)
  • Client Side Cache
  • Heat map
  • Automatic Data Optimization
  • Oracle Streams

If you need these features, then continue to use the non-CDB architecture until your required feature works with the CDB architecture.

En la lista de arriba hay una cosa curiosa: en la tercera línea pone que no puede usarse Flashback Pluggable Database, pero Pluggable solo tiene sentido en el contexto de CDB. Creo que debe ser un error en la documentación y debe referirse a Flashback Database o tal vez no está bien expresado ya que no se puede hacer flashback de una base de datos pluggable.

Categorías:Sistemas Etiquetas: , , ,

ADF Tips: Asignar un valor por defecto a un campo al editar un registro


Recientemente uno de nuestros clientes tenía la necesidad de asignar un valor por defecto a un campo solamente cuando se disponían a editar una fila. En este tip mostraremos cómo conseguir este comportamiento.

Vamos a suponer que disponemos de un task flow sencillo, como el que mostramos a continuación: un fragmento de origen y un fragmento de destino.

1

En el fragmento de origen tenemos una af:table basada en la vista de empleados del schema hr.

2

Y en el fragmento destino tenemos un formulario basado en la misma vista.

3

El objetivo es modificar el valor del campo Email para asignar un valor diferente cuando se navega al formulario. Para ello debemos generar la View Row Client Interface de la vista de empleados.

Leer más…

Categorías:ADF Etiquetas: ,

Crónica de Oracle Day 2015 (Barcelona, 17 Marzo)

marzo 18, 2015 Deja un comentario

El pasado 17 de Marzo se celebró en el Auditori Axa de Barcelona una nueva edición de Oracle Dayen la que avanttic colaboró como Patrocinador Gold, con un stand en la zona preferente y participando en la mesa redonda de partners del track de Cloud y Movilidad.

20150317 avanttic Oracle Day

Más de 200 personas se acercaron al Auditori para conocer las novedades que presentaba Oracle y algunos proyectos de clientes significativos. El evento empezó con  la bienvenida de Victoriano Martín (Director Barcelona & Mediterranean Area, Oracle), y continuó con la charla “Digital Transformation” que impartió Neil Sholay (Head of Oracle Digital, Oracle EMEA). A continuación un partner explicó un caso de cliente de Digital Business. Tras un break los asistentes se repartieron entre 2 sesiones paralelas:

  • Big Data & Business Analytics e IoT
  • Cloud y Movilidad: Preventas y BDM’s de Oracle explicaron la estrategia de Oracle en cuanto a Cloud Público y a Cloud Privado (sobre todo DBaaS) y presentaron los productos más importantes relacionados con la movilidad: Oracle Application Framework, Oracle Mobile Security Suite y Oracle Mobile Cloud Service. A continuación nuestro cliente Würth, de la mano de Sergi Crespo (Director Multicanal, Würth España), cogió el protagonismo explicando los beneficios que aporta a su fuerza de ventas la aplicación para tablet Würth Appli, desarrollada por avanttic. Después fue Desigual quien explicó cómo habían conseguido elevar al 100% los ratios de satisfacción en su Customer Service, gracias al uso de tecnología Oracle SaaS. Finalmente, en la mesa redonda de partnersJesús García (CEO&CTO, avanttic), presentó la apuesta de avanttic por la movilidad y por el cloud (en especial el PaaS de Oracle Cloud), explicando y mostrando algunos de nuestros desarrollos más recientes de movilidad.

Lea los detalles del proyecto Würth Appli en el caso de éxito publicado con avanttic y Oracle.

Contacta con nosotros si deseas más información sobre los temas tratados en estas sesiones.

Categorías:Eventos Etiquetas: , , , ,

Oracle Big Data Appliance: introducción y características

Big Data ApplianceSiguiendo el hilo del post publicado en este mismo blog por January Tabaka hace unos días, sobre los Oracle Engineered System en su versión X5-2, vamos a aprovechar para entrar un poco más en detalle en el Oracle Big Data Appliance (BDA), diseñado para ofrecer un óptimo rendimiento en proyectos Big Data.

Big Data Appliance es un sistema abierto pero con el soporte empresarial de Oracle, que puede ser ampliado con software de terceros que añadan nuevas funcionalidades (con el soporte específico de sus respectivos fabricantes). Orientado al proceso de datos con Hadoop y NoSQL, es capaz de realizar diversos tipos de trabajo, desde los típicos procesos Hadoop (MapReduce 2, Spark, Hive etc.) hasta consultas interactivas SQL con Oracle Big Data SQL. Big Data Appliance es multitenant, es decir, puede ser configurado como un cluster único, o como varios clusters, ofreciendo la flexibilidad necesaria para por ejemplo, disponer de entornos de desarrollo, test y producción.

Desde el punto de vista de mantenimiento del sistema, éste ha sido simplificado incorporando la utilidad (de línea de comandos) para la instalación, actualización, parcheado y expansión Mammoth, que permite desplegar rápidamente las frecuentes actualizaciones del sistema Hadoop sin incurrir en interrupciones de servicio significativas además de crear y/o extender clusters en un rack o entre racks diferentes.

El hardware se ofrece con un mínimo de 6 nodos (starter pack) ampliable de 6 en 6 (in-rack expansion) hasta un máximo de 18 (full rack). Cada nodo ofrece notables capacidades tanto de cálculo como de almacenamiento, siendo sus principales características:

  • 2 Procesadores x 18 Cores Intel ® Xeon ® E5-2699 V3 a 2.3 GHz
  • 128 GB de RAM (4 * 16 DDR4) ampliables a 768 GB por nodo
  • Controlador de disco HBA con 512MB cache de escritura (respaldada con batería)
  • 12 discos SAS de alta capacidad (4TB)  a 7,200 RPM
  • 2 Puertos Infiniband QDR (40Gb/s)
  • 4 Puertos Ethernet a  10 Gb
  • 1 Puerto ILOM Ethernet

con lo que un full rack podría alcanzar unas prestaciones de hasta

  • 288 Cores
  • 2.304 Gb de RAM (o 13.824 con todos los nodos ampliados a 768 Gb de RAM)
  • 864 Tb de disco

Además, los racks de Big Data appliance pueden conectarse entre ellos hasta un total de 18 sin necesidad de switches infiniband adicionales.

Leer más…

Webinar: Caminos de migración a Oracle Database 12c (24-03-2015)

marzo 10, 2015 Deja un comentario

20150324 avanttic Webinar BBDD 12c-c

 Descubra las ventajas de migrar a la versión 12c sus BBDD Oracle

Hace ya más de 2 años que se presentó Oracle Database 12c, en eventos multitudinarios en los que se presentaban sus bondades y se mostraba que la “c” era indicativa de su clara vocación de Cloud (privado, público o híbrido), por ser una versión que facilita la consolidación (curiosamente comienza también por “c”) y el traslado de instancias entre diferentes entornos o sistemas.

En la actualidad hay muchas BBBD Oracle que todavía se encuentran en versiones 11g y bastantes aún en 10g o incluso algunas en 9i. No migrar puede suponer en algunos casos un riesgo importante para la organización puesto que Oracle deja de desarrollar parches cuando una versión pasa a Sustaining Support (lea este post sobre Oracle Lifetime Support Policy en avanttic blog).

Migrar sus BBBD Oracle a la versión 12c le aportará estas ventajas:

  • Disponer de BBDD más manejables
  • Facilidad para consolidar sus entornos
  • Incrementar la seguridad de los datos
  • Poder ofrecer el acceso a sus BBDD como un servicio interno (DBaaS, facturación interna)
  • Facilitar la migración de la capa de datos hacia el Cloud
  • Mejorar su disponibilidad y continuidad del acceso a la información
  • Optimizar el almacenamiento
  • Poder desplegar sus instancias sobre cualquiera de los Oracle Engineered Systems (Oracle Exadata, Oracle Database Appliance y Oracle SuperCluster), para poder abordar grandes proyectos de consolidación, Big Data y Business Analytics
Le recordamos que:

  • Las versiones hasta la 10.2 se encuentran todas en Sustaining Support
  • Para la versión 11.1 finalizará el Extended Support en Agosto-2015 (pasando a Sustaining Support)
  • La versión 11.2 entró en Extended Support en Febrero-2015. No se aplica el sobrecoste durante 1 año si se está en la versión 11.2.0.4
  • Para la versión 11.2 finalizará el Extended Support en Enero-2018 (pasando a Sustaining Support)

Para no incurrir en riesgos innecesarios, le recomendamos que migre sus bases de datos a Oracle Database 12c.

Reserve su plaza y no pierda la oportunidad de asistir a este seminario Web organizado por Oracle y avanttic, que le permitirá conocer de manera cómoda, ágil e interactiva, las ventajas que le aportará migrar su base de datos a la versión 12c y las posibilidades de futuro que generará a su empresa. Conocerá cuál es el mejor camino de migración en función de la versión en que se encuentre actualmente su BD Oracle.

Martes 24 de marzo de 2015, 10:00 am – 11:00 am

Webinar: Caminos de migración Oracle Database 12c

Rafael Planella – Arquitecto de Soluciones de avanttic

Presentación técnica (41 slides)

Webinar grabado (80 minutos)

 

Cómo configurar OBI MUDE con AdminTool – Permisos Desarrolladores Repositorio Común

marzo 6, 2015 3 comentarios

Este post muestra cómo crear y probar un entorno de desarrollo multiusuario (MUDE) utilizando la Herramienta de Administración de OBI. En concreto, detallamos cómo configurar el entorno para que diferentes grupos de desarrolladores puedan trabajar simultáneamente en el repositorio de BI, cada uno con permisos distintos, a nivel de proyecto y de acceso según su área de responsabilidad.

Escenario

Los proyectos consisten en áreas temáticas de la capa de presentación y sus datos asociados de modelo de negocio lógico, hechos y dimensiones, grupos, usuarios, variables y bloques de inicialización.

A continuación veremos cómo configurar el acceso para que RAÚL y NOEL, dos desarrolladores que están trabajando en el mismo proyecto, puedan seguir el siguiente flujo de trabajo:

  1. RAÚL accede al repositorio y hace las modificaciones necesarias.
  2. NOEL también realiza modificaciones.
  3. RAÚL confirmar los cambios, fusiona el repositorio principal con todos los cambios, y publica en el repositorio actualizado.
  4. A continuación, NOEL tratará de publicar su repositorio, encontrando conflictos, por lo que hará una resolución de problemas y toma de decisiones.

EssbaseCube

  Para este ejemplo necesitaremos Oracle BI EE 11G y la aplicación de ejemplo (BISAMPLE) que le acompaña. Así mismo, crearemos primero en el dominio de WLS (a través de la consola weblogic de OBI) y después, en el repositorio de OBI, los usuarios  RAÚL y NOEL como desarrolladores del entorno multiusuario.

 

El proceso de configuración consta de los siguientes pasos:

  1. Verificación de las funciones y privilegios de usuario
  2. Crear un proyecto de trabajo
  3. Configuración del Directorio de MUDE
  4. Configuración de usuarios que apunta al directorio multiusuario
  5. Control de salida de un proyecto
  6. Realizar cambios en el repositorio por el desarrollador
  7. Revisión de las opciones multi-usuario durante el desarrollo
  8. Registro de publicación de un Proyecto MUDE
  9. Resolución de problemas de una actualización de Repositorio
  10. Revisión de la Historia y verificación de un nuevo repositorio

1. Verificación de las funciones y privilegios de usuario

Los cambios en el repositorio de OBI se gestionan mediante la Herramienta de administración. Los desarrolladores desprotegen el archivo y realizan los cambios a nivel local, después, estos cambios se reconcilian y se fusionan en el repositorio principal en el recurso compartido.

Para ello, debemos crear dos usuarios en la consola Weblogic y asignarlos al grupo BIConsumers. A continuación, los verificamos desde el .RPD.

1

2. Crear un proyecto de trabajo

Los administradores pueden crear proyectos para que cada grupo de desarrolladores trabaje en proyectos dentro de su área de responsabilidad.

Para crear un proyecto es necesario editar el .RPD en modo fuera de línea. Desde la Herramienta de administración, haga clic en Archivo> Abrir> Fuera de línea.

1. Haga clic en Administrar Proyectos> para abrir el Administrador de proyectos.

2

2. Dos proyectos se incluyen en el panel de la derecha: Samp Essbase y relacional Samp. Estos proyectos se definen como objetos de metadatos en el repositorio de aplicación de ejemplo que se incluye con la aplicación de ejemplo.

3

3.  Haga clic en Acción> Nuevo proyecto.

Leer más…

Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.

Únete a otros 164 seguidores