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

 

Limita la autorización solo a aquellos que lo necesiten y elimina los roles de superusuario de gran alcance con Oracle Database Vault.

Tycho, es el responsable de arquitectura de bases de datos en el banco de Braavos, hoy es día de reuniones “tensas”. En vista de varias leyes, reglamentos y mandatos como:

•         LOPD
•         ENS
•         GDPR
•         PCI/DSS

Y en menor medida:

•         Sarbanes-Oxley
•         HIPAA
•         GLBA

Cersei, el auditor de TI del banco, quiere asegurarse de que los privilegios asignados a las personas se limiten a lo que realmente necesitan: nada más. Por ejemplo, los DBA de soporte de producción que administran la infraestructura de la base de datos, toman copias de seguridad, etc., deberían tener privilegios para hacer todo eso pero no tener acceso a datos como la información de la cuenta.

El rol de la base de datos "DBA", que se otorga a los DBA de Braavos para administrar la infraestructura de la base de datos, también incluye otros privilegios poderosos como la capacidad de seleccionar y eliminar de cualquier esquema cualquier esquema, incluidos los rastros de auditoría de estas actividades. Esos privilegios no pueden despojarse de ese rol; son partes integrales de la misma. Cersei quiere que los DBA pierdan esos privilegios, pero los DBA no pueden hacer su trabajo sin el rol de DBA, explica Petyr, gerente de DBA. No es que los DBA realmente usen esos privilegios para seleccionar de tablas sensibles o eliminarlos de los rastros de auditoría, por lo que tener esos privilegios no hace ninguna diferencia, argumenta Petyr.

Ha habido muchas instancias de un atacante malintencionado que usa privilegios de DBA para robar datos confidenciales e incluso de DBA falsos que roban datos y borran los rastros de auditoría, usando los privilegios de rol de DBA todopoderosos. ¿Y no suelen ser los DBA los que tienen más probabilidades de ser investigados cuando ocurre una violación de datos? le pregunta a Cersei. Sin esos privilegios, explica, su responsabilidad se reducirá drásticamente. Petyr considera esta lógica y ve de inmediato el valor de la solicitud de Cersei, pero explica que sin el rol de DBA, los DBA no pueden hacer su trabajo. Así que aquí están, preguntándose si el sabio Tycho tiene una solución.

Sí, asegura Tycho, las necesidades de Petyr y Cersei se pueden cumplir con una opción de costo adicional llamada Oracle Database Vault en Oracle Database 12c.

Separación de tareas

Es necesario abordar varios tipos de usuarios y actividades. Nuestra auditora de TI identifica cinco tipos distintos de usuarios de bases de datos y sus actividades:

• DBA. Usuario que realiza la gestión de la infraestructura de la base de datos, como inicio / apagado, copia de seguridad, etc.
• Gestor de seguridad: Usuario que realiza actividades como crear usuarios y cambiar contraseñas. Actualmente, los DBA realizan la administración de cuentas, y Cersei desea que alguien en seguridad de TI, no un DBA, la administre.
• Auditor: Usuario que establece la separación de funciones y controles de las actividades realizadas por varios usuarios. Esto debería ser realizado por el departamento de cumplimiento de TI, insiste Cersei.
• Usuario del esquema empresarial. Cuenta de usuario que contiene tablas de datos reales y otros objetos que son compatibles con la empresa.
• Usuario regular Cuenta de usuario conectada a la base de datos desde aplicaciones o un usuario humano especificado que permite ver y manipular datos en esquemas, pero no los posee.

Es vital, insiste Cersei, que los privilegios que disfrutan estos usuarios no se solapan. Por ejemplo, el usuario de DBA debería poder iniciar y detener la base de datos, pero no crear usuarios ni seleccionarlos de ninguna tabla en los esquemas comerciales. De manera similar, el usuario del administrador de la cuenta debería poder crear usuarios, pero no iniciar y detener la base de datos y no seleccionar ningún dato de una tabla (a menos que, por supuesto, se lo autorice explícitamente). El usuario del auditor debe ser el único que vea los datos de auditoría pero no pueda crear usuarios. En otras palabras, a todos se les deben otorgar precisamente los privilegios que necesitan para hacer su trabajo y no un poco más, sea o no sea su intención usar los privilegios.

Configuración

Es muy fácil separar los usuarios y las actividades con Oracle Database Vault, asegura Tycho, mientras comienza a configurar una demostración para los visitantes de su oficina. Primero, elige a los usuarios para diversos tipos de actividades. Para la primera categoría, los usuarios de DBA como SYS, SYSTEM y otros DBA nombrados ya están presentes. Para crear los tipos de usuario 4 y 5, el esquema empresarial y los usuarios normales, ejecuta el script en setup.sql. El esquema que contiene todos los datos de usuario del banco se denomina BRAAVOS. El usuario que se conecta a la base de datos para realizar transacciones es WEBAPP1. La tabla CUENTAS en el esquema BRAAVOS almacena los datos en las cuentas de ahorro. Tycho rompe la configuración restante en nueve pasos, para cubrir situaciones en las que Oracle Database Vault puede o no estar actualmente instalado o configurado y donde puede usarse en bases de datos convencionales y conectables.

• Paso 1. Para las otras dos categorías de usuarios, administrador de cuentas y auditor, Tycho crea dos usuarios especiales para su uso por Oracle Database Vault, denominados DVACCMGR y DVADMIN, respectivamente. El usuario de DVADMIN administrará la instalación completa de Oracle Database Vault.

-- Como SYSDBA
create user dvadmin identified by dvadmin; 
create user dvaccmgr identified by dvaccmgr; 
grant create session to dvaccmgr, dvadmin;

• Paso 2 En caso de que Oracle Database Vault no se haya configurado, Tycho comprueba mediante el siguiente SQL:

-- Como SYSDBA
SQL> select * from dba_dv_status; 

• Paso 3. La salida confirma que la opción no se ha configurado. Durante la instalación de algunas bases de datos, es posible que los DBA hayan instalado la opción Oracle Database Vault pero nunca la hayan configurado. Para aquellas bases de datos en las que Oracle Database Vault nunca estuvo instalado, Tycho usa el siguiente comando para instalar no solo la opción Oracle Database Vault sino también para configurarla en un solo paso.

dbca -silent -configureDatabase -sourceDB ACMEDB -addDBOption OMS,DV -olsConfiguration true -dvConfiguration true -dvUserName dvadmin -dvUserPassword dvadmin -dvAccountManagerName dvaccmgr -dvAccountManagerPassword dvaccmgr

Tycho realiza los cambios apropiados a las opciones, como el nombre de la base de datos en las bases de datos en las que ejecuta este comando. Aquí está el resultado: 

Preparing to Configure Database
1% complete
3% complete
18% complete
Adding Oracle Label Security
19% complete
20% complete
21% complete
54% complete
Adding Oracle Database Vault
90% complete Completing Database Configuration
100% complete
Look at the log file "C:\app\oracle\cfgtoollogs\dbca\ACMEDB\ ACMEDB.log" for further details. 

La última línea muestra la ubicación del archivo donde se registrarán los detalles de la salida. Si la opción ya estaba instalada en la base de datos, explica Tycho, el comando habría salido sin hacer nada y la salida lo habría hecho referencia. 

•  Paso 4. Algunas bases de datos ya tenían Oracle Database Vault instalado pero no configurado. Para ellos, Tycho configura los dos usuarios especiales para administrar Oracle Database Vault y las cuentas de usuario DVADMIN y DVACCMGR, ejecutando el siguiente SQL como usuario de SYS:

begin dvsys.configure_dv ( dvowner_uname => 'dvadmin', dvacctmgr_uname => 'dvaccmgr' ); end; /

• Paso 5. A continuación, Tycho ejecuta el script utlrp.sql en el directorio rdbms / admin bajo Oracle Home como SYS.

SQL> @ utlrp.sql

• Paso 6. Para aquellas bases de datos en las que Oracle Database Vault se instaló pero no se configuró, Tycho se conecta como usuario de DVADMIN y habilita Oracle Database Vault.

SQL> exec dbms_macadm.enable_dv

• Paso 7. Tycho reinicia cada base de datos. 
• Paso 8. Confirma que la opción Oracle Database Vault está configurada y habilitada, ejecutando el siguiente SQL:

SQL> select * from dba_dv_status;

• Paso 9. Para las bases de datos multitenant, Tycho ejecuta todos los pasos anteriores en el contenedor raíz (la base de datos del contenedor). Ejecuta los pasos 4, 5 y 6 en cada base de datos conectable donde se necesita Oracle Database Vault, y cierra y vuelve a abrir todas las bases de datos conectables habilitadas para Oracle Database Vault.

Gestión de usuarios

Con Oracle Database Vault habilitado, Tycho demuestra el primer efecto para Cersei y Petyr. Como el usuario SYS (Tycho enfatiza que SYS debe usarse solo cuando se demuestran los controles, no en el día a día), intenta crear un usuario llamado TEST:

create user test identified by test;

                              *

ERROR at line 1:

ORA-01031: insufficient privileges

El usuario SYS, que tenía todos los privilegios para crear un nuevo usuario antes, falla con un error ORA-1031. SYS ahora puede realizar actividades típicas de administración de bases de datos pero no administrar ningún usuario. Para administrar a los usuarios, Tycho inicia sesión como el usuario de Oracle Database Vault para la gestión de cuentas-DVACCMGR-y ejecuta este SQL:

SQL> conn dvaccmgr/dvaccmgr

SQL> create user test identified by test;

User created.

Además, el usuario de DVACCMGR puede realizar otras funciones de administración de usuarios, como cambiar contraseñas y otorgar privilegios de CREATE SESSION. Sin embargo, DVACCMGR no puede seleccionar de ninguna tabla ni cerrar la base de datos. Este usuario de DVACCMGR debe ser controlado por el equipo del administrador de cuentas y no por el equipo de DBA, por lo que los DBA no pueden administrar a los usuarios, exactamente lo que Cersei quería. Un requisito satisfecho, quedan más por abordar, en nuestra segunda parte del artículo:

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

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

Ley Orgánica de Protección de Datos (España)

Tiene por objeto garantizar y proteger, en lo concerniente al tratamiento de los datos personales, las libertades públicas y los derechos fundamentales de las personas físicas, y especialmente su honor e intimidad personal y familiar. (Art. 1 LOPD).
Existen leyes similares en otros países, a los que se pueden aplicar estas políticas:

• México: LFPDPPP
• Colombia: Ley estatutaria 1581

Esquema Nacional de Seguridad (España)

Su finalidad es la creación de las condiciones necesarias de confianza en el uso de los medios electrónicos, a través de medidas para garantizar la seguridad de los sistemas, los datos, las comunicaciones, y los servicios electrónicos.

Los sistemas de información prestarán sus servicios y custodiarán la información de acuerdo con sus especificaciones funcionales,sin interrupciones o modificaciones fuera de control, y sin que la información pueda llegar al conocimiento de personas no autorizadas.

Nivel básico

Artículo 91. Control de acceso. (Nivel básico)

• Los usuarios tendrán acceso únicamente a aquellos recursos que necesiten para el desarrollo de sus funciones.
• El responsable del fichero establecerá mecanismos para evitar que un usuario pueda acceder a recursos con derechos distintos de los autorizados.

Artículo 93. Identificación y autenticación. (Nivel básico)

• …adoptar las medidas que garanticen la correcta identificación y autenticación de los usuarios.
• …establecerá un mecanismo que permita la identificación de forma inequívoca y personalizada de todo aquel usuario que intente acceder al sistema de información y la verificación de que está autorizado.
• …establecerá la periodicidad, que en ningún caso será superior a un año, con la que tienen que ser cambiadas las contraseñas…

Artículo 94. Copias de respaldo y recuperación. (Nivel básico)

• Las pruebas anteriores a la implantación o modificación de los sistemas de información que traten ficheros reales no se realizará con datos reales, …

Nivel Alto

Artículo 101. Gestión y distribución de soportes. (Nivel alto)

• La distribución de los soportes que contengan datos de carácter personal se realizará cifrando dichos datos…

Artículo 103. Registro de accesos (Nivel alto)

• De cada intento de acceso se guardarán, como mínimo, la identificación del usuario, la fecha y hora en que se realizó, el fichero accedido, el tipo de acceso y si ha sido autorizado o denegado.
• En el caso de que el acceso haya sido autorizado, será preciso guardar la información que permita identificar el registro accedido.

Artículo 104. Telecomunicaciones. (Nivel alto)

•  …la transmisión de datos de carácter personal a través de redes públicas o redes inalámbricas de comunicaciones electrónicas se realizará cifrando dichos datoso utilizando cualquier otro mecanismo que garantice que la información no sea inteligible ni manipulada por terceros.

Ley Orgánica de Protección de Datos

Requerimientos vs Oracle

Esquema Nacional de Seguridad

Requerimientos vs Oracle

Securización de BBDD Remotas

Principales problemáticas de seguridad en las Sedes Remotas

• Acceso a dispositivos físicos
• Evitar posibles robos de información
• Acceso a los datos
• Evitar fugas/robos
• Segregar funciones de los Usuarios Privilegiados
• Registro y control
• Todo lo que pasan en las BBDD quedará registrado
• Cumplimiento LOPD-ENS
• Escenarios similares a los productivos

Soluciones seleccionadas e implantadas

• Oracle Data Masking and Subsetting Pack
• Reemplazo de la información sensible de los entornos productivos, de forma que datos similares a los que se manejan por el usuario final, puedan ser utilizados de forma segura en otros entornos.
• Oracle Advance Security
• Cifrado de datos, gestión de claves multinivel, autenticación fuerte contra la BBDD.

• Oracle Database Vault
• Separación de funciones y dominios de seguridad; Establecimiento de controles robustos sobre qué puede hacer quién dentro de la base de datos.
• Oracle Audit Vault and Database Firewall
• Recopilación de datos de actividad en las BBDD, firewall de BBDD para monitorear y bloquear sentencias SQL.

Continua en la segunda parte de este artículo, aquí.

Qué hacer cuando tenemos una alerta de aumento de registros espectacular en el tablespace SYSAUX

Este artículo vamos a mostrar diferentes casuísticas que puedes tener cuando tienes un aumento espectacular de ocupación de tablespace SYSAUX.

A partir de Oracle 10g en adelante, hay lo que Yo llamaría un error grave (para Oracle, es una característica 💀), debido a que el tablespace SYSAUX crecerá continuamente. Sólo hay forma de limitar este crecimiento y no está claramente documentado en ninguna parte

¿Para que demonios vale ese tablespace?

El espacio de tablas SYSAUX se instaló como un tablespace auxiliar en el tablespace SYSTEM cuando creó la base de datos, apareció a partir de la versión 10g. Algunos componentes de base de datos que anteriormente creaban y utilizaban espacios de tabla independientes ahora ocupan el espacio de tablas SYSAUX.

Si el espacio de tablas de SYSAUX no está disponible, la funcionalidad de la base de datos central permanecerá operativa. Las funciones de base de datos que utilizan el espacio de tablas SYSAUX podrían fallar o funcionar con capacidad limitada.

Estos componentes pueden utilizar el espacio de tablas SYSAUX y su instalación proporciona los medios para establecer su ocupación del espacio de tablas SYSAUX. Puede controlar los ocupantes del espacio de tablas SYSAUX mediante la vista V $ SYSAUX_OCCUPANTS. Esta vista enumera la siguiente información sobre los ocupantes del espacio de tablas SYSAUX:

• Nombre del ocupante
• Descripción del ocupante
• Nombre del esquema

Configuración básica del tablespace SYSAUX

CASO #1: Uno de los ocupantes de SYSAUX, el optimizador de estadísticas, crece exponencialmente.

Tengo una base de datos de Oracle 11g R2 (11.2.0.1) donde advertí que el tablespace de SYSAUX crecía cada día más y más grande. Busqué en Metalink (perdón, Oracle My Support) y encuentro dos notas:

• Doc ID 1292724.1
• Doc ID 552880.1 

que fueron útiles.

Después de ejecutar el script awrinfo.sql, localizado en $ORACLE_HOME/rdbms/admin/, encontré que el consumidor más grande era SM / OPTSTAT en 3 GB que es más grande y no típico en comparación con mis otras bases de datos Oracle 10g R2 y Oracle 11g R1.

Investigando por la documentación encuentro lo siguiente:

"Siempre que se modifiquen las estadísticas del diccionario, las versiones antiguas de estadísticas se guardan automáticamente para futuras restauraciones. Las estadísticas antiguas se depuran automáticamente a intervalos regulares en función de la configuración de retención de historial de estadísticas y de la hora de la recopilación de estadísticas recientes realizada en el sistema. La retención se puede configurar mediante el procedimiento ALTER_STATS_HISTORY_RETENTION. El valor predeterminado es 31 días."

Para ayudar a reducir la cantidad de espacio causada por datos históricos, fijé la retención de las viejas estadísticas a 14 días.

exec dbms_stats.alter_stats_history_retention (14);

Para verificar la nueva configuración, ejecuté la siguiente declaración.

select dbms_stats.get_stats_history_retention from dual;

Procedí a depurar incrementalmente las estadísticas de 31 días a 14 días. Comenzó con 28 días, luego se trasladó a 21 días.

exec dbms_stats.purge_stats (sysdate-28);

Entonces intenté 14 días, sin embargo encontré un error del espacio de la UNDO que requiere que cambie mis incrementos usando 18, 16, y finalmente 14 para terminar la tarea de la purga.

Ahora, para recuperar el espacio utilizado por los objetos mostrados en la sección 4 del informe AWRINFO, usé el comando ALTER TABLE MOVE.

CASO #2: Otra forma de resolver el crecimiento desmesurado del optimizador de estadísticas.

A partir de 10gR1 en adelante, Oracle mantendrá la copia de seguridad de las estadísticas del optimizador automáticamente, incluso si no le pide que lo haga.

Esta información de copia de seguridad se almacena en el tablespace SYSAUX y las tablas implicadas en esto son las siguientes:

• WRI$_OPTSTAT_OPR                         
• WRI$_OPTSTAT_AUX_HISTORY                 
• WRI$_OPTSTAT_TAB_HISTORY                 
• WRI$_OPTSTAT_IND_HISTORY                 
• WRI$_OPTSTAT_HISTGRM_HISTORY             
• WRI$_OPTSTAT_HISTHEAD_HISTORY  

La retención predeterminada de esta información se obtiene con el siguiente comando:

NO se escribirá ningún mensaje en el registro de alertas ni en ningún otro lugar para indicar que no se ha producido la purga. Con cada día que pasa, la probabilidad de falla aumenta y alcanzará una etapa, donde la purga automática nunca será completada por MMON con éxito.

Alternate proporcionado por Oracle para esto es ejecutar, programa DBMS_STATS.PURGE_STATS para purgar esta información de estadísticas. Esto se puede hacer manualmente y es seguro. No hay tiempos muertos involucrados aquí. sólo una terminación manual o un fallo anormal detendrá la purga.

¿Qué más me falta aquí?

A pesar de que publicamos la retención, puede suceder que debido a la falta de purga, vamos a acumular gran cantidad de historial de estadísticas en SYSAUX, haciendo que crezca continuamente.

Como el fallo de purga no está escrito en ninguna parte, podemos perder el hecho de que hay un proceso que consume el espacio con regularidad.

El proceso PURGE_STATS suprimirá estas tablas. Por lo tanto, el espacio libre no se devuelve al espacio de tablas, lo que resulta en una fragmentación de espacio libre dentro de esta tabla.

¿Cómo sé que tengo este problema?

Compruebe su valor de retención actual utilizando la siguiente sentencia

select dbms_stats.get_stats_history_retention from dual;

Vea el historial de estadísticas más antiguo usando la siguiente declaración:

select dbms_stats.get_stats_history_available from dual;

Comparar los dos anteriores y y deberías saber qué hacer

¿Qué debería hacer ahora?

Identifique la retención del sistema tan pronto como sea posible y cambie a un valor apropiado. 30 días es el valor predeterminado. Sin embargo, los valores más pequeños no harían mucho daño.

Deshabilite el Autoextend en SYSAUX tan pronto como sea posible para asegurarse de que el espacio de tablas no crece fuera de límites y, finalmente, se convierte en inmanejable.

Comience a programar el PURGE_STATS tan pronto como sea posible y mantenga el tamaño del espacio de tablas SYSAUX en control.

Realice la reorganización de tablas relacionadas para recuperar el espacio.

¿Por qué debería importarme?

Con cada día que pasa, el tamaño de la tabla crece más grande y más grande, finalmente convirtiéndose en un consumidor superior del espacio. Los esfuerzos que se harán para la limpieza aumentará exponencialmente. HACERLO diariamente en 1hr o hacerlo en 5hr mañana.

El procedimiento PURGE_STATS realiza una supresión de comando simple con una cláusula where específica. Esto deja mucho desorden a medida que el proceso se completa completamente o no hace nada en absoluto. No se engancha a intervalos regulares en este código.

Para una base de datos promedio de 150G, en 6 meses, puede terminar con 100M filas en esta tabla. La limpieza de estos datos es siempre un dolor.

¿Algún consejo?

Identifique la información más antigua que tenga en el historial de estadísticas usando el siguiente comando.

select dbms_stats.get_stats_history_availability from dual;

Si la información es demasiado antigua, comience a purgar la información en trozos más pequeños. recuerde que si cancela el proceso en el medio, usted hará una reversión completa antes de salir.

Utilice el siguiente comando para saber en qué fechas había generación de estadísticas enormes.

select trunc(SAVTIME),count(1) from WRI$_OPTSTAT_HISTHEAD_HISTORY group by  trunc(SAVTIME) order by 1;

Comienza con la fecha más antigua y se invoca bajo el comando

exec dbms_stats.purge_stats (to_date ('01 -JAN-2010 ',' DD-MON-YYYY '));

Una vez que la cantidad de datos se reduce a un límite de tiempo razonable en las horas punta, como una actividad de mantenimiento regular.

NOTA: Tenga en cuenta que este proceso requiere muchos recursos. No lo hagas durante horas de oficina.

¿Hay vida más allá de Oracle? Riak KV:

Una base de datos de valor-clave NoSQL distribuida

Las empresas confían en los datos para alimentar sus operaciones del día a día. Cuando es imperativo que estos datos estén siempre disponibles. Incluso unos minutos de  inactividad en tus aplicativos pueden significar perdidas en los beneficios de una empresa, un usuario pobre experiencia, y una marca magullada. 

Necesitas una base de datos diferente. Basho Riak® KV Enterprise es una base de datos NoSQL distribuida diseñada para satisfacer sus necesidades de aplicación.
Riak KV ofrece alta disponibilidad y escalabilidad. Riak KV puede ser operacionalizado a que las bases de datos relacionales tradicionales y se fácil de manejar a escala.
Riak KV se integra con Apache Spark, Redis Caching, Apache Solr y Apache Mesos reducir la complejidad de la integración y desplegando otras tecnologías de Big Data.

Beneficios de RIAK KV

Una base de datos distribuida con avanzado local y multi-cluster la replicación significa que sus datos siempre están disponibles.

ESCALABILIDAD MASIVA
Distribución automática de datos en el clúster y la facilidad de añadir nodos significan un aumento de rendimiento casi lineal a medida que sus datos crecen.

SIMPLICIDAD OPERACIONAL
Fácil de ejecutar, fácil de agregar nodos al clúster. Las operaciones son potente y simple. Asegúrese de que su equipo de operaciones duerma mejor.

TOLERANCIA POR FALLO
Una arquitectura multi-nodo sin maestro asegura la pérdida de datos en el evento de fallos de red o de hardware.

ACCESO RÁPIDO DE DATOS
Sus usuarios esperan que su aplicación sea rápida. Baja latencia significa que su las solicitudes de datos se prestan de manera predecible incluso durante las horas punta.

MODELO FLEXIBLE DE DATOS
El modelo de datos NoSQL de clave / valor proporciona flexibilidad sin esquema predefinido. Llegar a la nube para la continuidad del negocio o para satisfacer su demanda máxima, Riak KV sobresale en las implementaciones privadas, públicas e híbridas de la nube.

ALMACENAMIENTO DE OBJETOS
Soporte de múltiples modelos desde una sola plataforma a través de la integración con Riak S2 para almacenamiento de objetos grandes.

DESARROLLO SIMPLIFICADO
Una amplia documentación y herramientas de embalaje funcionando en minutos, y las APIs de gran alcance son fáciles de utilizar.

Escenarios válidos para implementar RIAK

DATOS DE LA SESIÓN
Los datos de usuario incluyen información sobre los usuarios y los clientes, como nombre, dirección, datos demográficos, preferencias, los detalles de la tarjeta de crédito, la dirección de correo electrónico y los detalles históricos de las compras y las tasas de los juegos. Los datos de usuario son fundamentales para garantizar el compromiso del usuario y para completar transacciones o compras.

Los datos de la sesión de información sobre la conexión de la aplicación con el usuario y el cliente pasar de un cliente de usuario final (navegador, teléfono, etc) y luego almacenar en el servidor esperando la devolución de nuevos datos de la sesión con cambios de usuario Los datos de sesión se utilizan para las comunicaciones entre la aplicación y el usuario.

Riak KV está diseñado de manera única para manejar datos de usuario y sesión. Originalmente fue desarrollado para servir como un almacén de escenarios escalable. Dado que los ID de usuario y de la sesión se almacenan normalmente en las galletas o se conocen en el momento de la búsqueda, Riak KV puede atender estas solicitudes con una latencia predeciblemente baja.


Riak KV está diseñado para no imponer restricciones sobre el valor, por lo que los datos de sesión pueden codificarse de muchas maneras y pueden evolucionar sin cambios administrativos en los esquemas. Riak KV está diseñado para nunca perder una escritura y escalar horizontalmente de modo que, incluso en días pico, todas las acciones de su usuario se completan sin problemas.

CONTENIDO Y DOCUMENTOS
El contenido es el rey. Pero hoy en día más y más de ese contenido no está estructurado. Se trata de imágenes, documentos, archivos pdf, archivos de registro, correos electrónicos, historial de chat, libros, artículos y videos. Los días de intentar calzar este contenido en una estructura de base de datos relacional han pasado mucho tiempo.

Los problemas de la sobrecarga de la tabla de base de datos relacional (cuántos BLOBs pueden encajar en una sola tabla) se resuelven con una base de datos NoSQL distribuida. El contenido no sólo toma muchas formas tal como está escrito, sino que permite muchos casos de uso diferentes que requieren experiencias de baja latencia. El despliegue de contenido a escala requiere una plataforma distribuida que se adapte a las necesidades de sus clientes.

Riak KV es una base de datos fundamentalmente de contenido agnóstico. Puede usarlo para almacenar cualquier cosa que desee, desde JSON a XML a HTML, binarios a imágenes y más allá. Riak S2 es para almacenamiento de objetos grandes cuando necesita almacenar archivos de tamaño terabyte o escala a petabytes de almacenamiento de objetos.


En sistemas heredados, los datos están organizados por tablas que son estructuras separadas y únicas. Dentro de estas tablas existen filas de datos organizados en columnas. Por el contrario, Riak tiene un modelo de datos mucho más simple. Un objeto es el elemento más grande y más pequeño de los datos. Como tal, la interacción con la base de datos se realiza recuperando o modificando todo el objeto.

MENSAJERÍA Y CHAT
Las bases de datos relacionales tradicionales no fueron diseñadas para manejar la variedad de datos no estructurados y la velocidad requerida para aplicaciones de mensajería y chat. Riak KV cumple estos retos y es fácil de operar a escala.


Riak KV proporciona la arquitectura de datos de alta latencia, altamente disponible, requerida por las modernas aplicaciones de mensajería y chat. El diseño sin maestro de Riak KV asegura que la escalabilidad de la base de datos esté diseñada desde el inicio del diseño.

CONTINUIDAD DEL NEGOCIO
La mayoría de las bases de datos funcionan a pequeña escala, pero ¿cómo se puede escalar, subir y bajar predecible y linealmente a medida que crecen los datos? Uno de los patrones de arquitectura más comunes para la replicación de clústeres múltiples es el mantenimiento de un clúster principal que proporciona tráfico y un clúster de copia de seguridad para la conmutación por error de emergencia. El mantenimiento de un clúster de copia de seguridad también puede ser un componente importante del cumplimiento normativo y / o asegurar la continuidad del negocio durante un evento adverso.


Riak KV Enterprise con Multi-Cluster Replication asegura la continuidad del negocio en caso de una interrupción. Riak KV tiene una innovadora arquitectura de base de datos que proporciona una funcionalidad de lectura y escritura rápida para los datos distribuidos a nivel mundial. Riak KV está diseñado para una configuración sin máster. Esto significa que los administradores pueden implementar varios clústeres de Riak KV y luego replicarlos para mantenerlos sincronizados. Si el Clúster A recibe una escritura, el Clúster A asegurará a su vez que la escritura se reproduzca en los Clústeres B - Z. Y lo hace rápidamente.

IoT / SENSOR / DATOS DEL DISPOSITIVO

Las aplicaciones empresariales recopilan datos de series temporales, lo que requiere que la agregación y el análisis sean útiles. Pero no es posible almacenar y analizar de manera óptima datos de series de tiempo con bases de datos tradicionales.


Los datos del sensor y del dispositivo entran en alta velocidad con una variedad de formatos de datos y en volumen masivo. Esto requiere una base de datos que pueda leer y escribir datos de series temporales rápidamente. Riak TS es una base de datos NoSQL altamente elástica y de alto rendimiento optimizada para datos de series de tiempo. 

Colocando los datos basados en el intervalo de tiempo, es más fácil ingerir, transformar, almacenar y analizar datos de sensores y dispositivos. Riak TS escala horizontalmente con hardware de productos para satisfacer volúmenes crecientes de datos. No hay necesidad de fragmentación de datos complejos.

METRICS / LOG ANALYTICS

Todo el mundo tiene una opinión, pero las mejores decisiones se basan en los datos. ¿Cómo puede utilizar registros y datos de métricas para tomar mejores decisiones de negocio? Los sistemas siempre han incluido datos de registro, pero el volumen, la velocidad y la complejidad de estos registros ha crecido exponencialmente a medida que los sensores y dispositivos IoT han proliferado. Ahora también estamos viendo un amplio crecimiento en el análisis de métricas. Estas métricas y archivos de registro requieren lecturas y escrituras rápidas, junto con la capacidad de recuperar datos mediante consultas de rango, todo ello al mismo tiempo que se mantiene rápido, fiable y escalable. Esto no es posible con las bases de datos relacionales tradicionales.


Las métricas y registros pueden llegar a una velocidad alta y una variedad de longitudes. Algunos son informativos y otros requieren acción inmediata. A menudo, se necesita un análisis complejo para determinar si se requiere acción. Algo que inicialmente parece ser informativo puede resultar ser un problema grave cuando los datos se agregan y analizan con el tiempo. Riak TS proporciona el alto rendimiento y la resiliencia necesarios para el análisis rápido de métricas y datos de registro. La co-localización de datos hace que sea rápido almacenar y analizar estos datos de series de tiempo semiestructuradas. Con Riak TS, puede ejecutar consultas de rango para enfocar su análisis en bloques de tiempo específicos a través de sistemas o dispositivos. Las consultas SQL hacen más rápido y fácil analizar sus datos.

ANÁLISIS DE DISPOSITIVOS

Datos, datos en todas partes! ¿Cómo habilitar ideas valiosas cuando y donde las necesita y detener el flujo de datos irrelevantes? Tradicionalmente, los datos se analizan en el núcleo de su red, pero con el crecimiento de los sensores y dispositivos IoT, los datos deben ser analizados más cerca de su fuente y agregados para el análisis de núcleo. Desde los cruceros hasta el monitoreo de la salud y la utilización del sistema, los análisis de punta crean una mejor experiencia de usuario y tiempos de respuesta más rápidos.

El análisis de dispositivos de borde debe ser rápido y fiable utilizando recursos mínimos. Esto requiere una base de datos altamente resiliente y fácil de operar a escala. Riak TS es una base de datos NoSQL de alto rendimiento y altamente elástica optimizada para el análisis en tiempo real de datos de series de tiempo. Agregue fácilmente capacidad a la demanda utilizando hardware de productos. Responder a lecturas y escrituras incluso en caso de fallas de hardware o cortes de red. Riak TS requiere menos recursos de hardware para la misma potencia computacional, por lo que es una opción ideal para el análisis de bordes. Con Riak TS, es fácil hacer análisis usando consultas de rango de SQL.

Optimización de los Parámetros de UNDO

A Partir de Oracle 9i, los segmentos de rollback pasan a llamarse Undo Logs. Tradicionalmente, la información de transacciones (UNDO) se almacenaba en Rollback segments hasta el COMMIT o ROLLBACK. Oracle9i permite la gestión automática de UNDO. El DBA para especificar cuánto tiempo debe mantenerse la información de UNDO, para prevenir los errores "snapshot too old" en consultas largas. Esto se hace mediante el parámetro UNDO_RETENTION. 
El valor por defecto es de 900 segundos (15 minutos), Y puedes cambiar este parámetro para garantizar que Oracle mantiene los registros de UNDO largos períodos de tiempo. En lugar de tener que definir y gestionar los segmentos de rollback, puedes simplemente definir un tablespace UNDO y dejar que se ORACLE se encargue de lo demás. En cuanto a la gestión automática de Undo es fácil. Todo lo que necesitas es crear un Tbs UNDO y poner el UNDO_MANAGEMENT = AUTO. Sin embargo vale la pena para ajustar los siguientes parámetros: 

• El tamaño del Tbs UNDO. 
• El Parámetro UNDO_RETENTION. 
• Calcular el UNDO_RETENTION para el Undo Tablespace. 

Puedes optar por asignar un determinado tamaño del tablespace UNDO y, a continuación, establecer el UNDO_RETENTION a un valor óptimo de acuerdo con el tamaño de UNDO y la actividad de la base de datos. Si su espacio en el disco es limitado y no quiere asignar más espacio del necesario para el Tbs Undo, esta es la forma de proceder. 
 La siguiente consulta le ayudará a optimizar el 
UNDO_RETENTION (Optimo) = UNDO SIZE Actual / DB_BLOCK_SIZE * UNDO_BLOCK_PER_SEQ 

Dado que estas consultas usan las estadísticas V$UNDOSTAT, ejecute las consultas sólo después de que la Base de datos lleve funcionando con UNDO para un importante y representativo periodo de tiempo.

Actual Undo Size

SELECT SUM(a.bytes) "UNDO_SIZE"
  FROM v$datafile a,
       v$tablespace b,
       dba_tablespaces c
 WHERE c.contents = 'UNDO'
   AND c.STATUS = 'ONLINE'
   AND b.name = c.tablespace_name
   AND a.ts# = b.ts#; 

Undo Blocks per Second

SELECT MAX(undoblks/((end_time-begin_time)*3600*24))
      "UNDO_BLOCK_PER_SEC"
  FROM v$undostat; 

DB Block Size

SELECT TO_NUMBER(value) "DB_BLOCK_SIZE [KByte]"
 FROM v$parameter
WHERE name = 'db_block_size'; 

Optimal Undo Retention

SELECT d.undo_size/(1024*1024) "ACTUAL UNDO SIZE [MByte]",
       SUBSTR(e.value,1,25) "UNDO RETENTION [Sec]",
       ROUND((d.undo_size / (to_number(f.value) *
       g.undo_block_per_sec))) "OPTIMAL UNDO RETENTION [Sec]"
  FROM (
       SELECT SUM(a.bytes) undo_size
          FROM v$datafile a,
               v$tablespace b,
               dba_tablespaces c
         WHERE c.contents = 'UNDO'
           AND c.STATUS = 'ONLINE'
           AND b.name = c.tablespace_name
           AND a.ts# = b.ts#
       ) d,
       v$parameter e,
       v$parameter f,
       (
       SELECT MAX(undoblks/((end_time-begin_time)*3600*24))
              undo_block_per_sec
         FROM v$undostat
       ) g
WHERE e.name = 'undo_retention'
  AND f.name = 'db_block_size'
/ 

Calcular el UNDO necesario para la actividad de la BBDD

SELECT d.undo_size/(1024*1024) "ACTUAL UNDO SIZE [MByte]",
       SUBSTR(e.value,1,25) "UNDO RETENTION [Sec]",
       (TO_NUMBER(e.value) * TO_NUMBER(f.value) *
       g.undo_block_per_sec) / (1024*1024) 
      "NEEDED UNDO SIZE [MByte]"
  FROM (
       SELECT SUM(a.bytes) undo_size
         FROM v$datafile a,
              v$tablespace b,
              dba_tablespaces c
        WHERE c.contents = 'UNDO'
          AND c.STATUS = 'ONLINE'
          AND b.name = c.tablespace_name
          AND a.ts# = b.ts#
       ) d,
      v$parameter e,
       v$parameter f,
       (
       SELECT MAX(undoblks/((end_time-begin_time)*3600*24))
         undo_block_per_sec
         FROM v$undostat
       ) g
 WHERE e.name = 'undo_retention'
  AND f.name = 'db_block_size'
/

¿Sabías que existía la herramienta ORAchk?

La herramienta de Oracle ORAchk incluye funciones EXAchks y RACcheck y reemplaza las herramientas más antiguas. Ya no es sólo una herramienta de base de datos, sino que también realiza comprobaciones sobre E-Business Suite Financials, el repositorio de Cloud Management para Enterprise Manager, GoldenGate y Sun Systems.

La utilidad ORAchk (Oracle Check) se conocía anteriormente como RACchk. En su encarnación más antigua, RACchk examinó la configuración del sistema Oracle RAC buscando las áreas que necesitaban mejoras. Oracle Corporation decidió extender la utilidad para incluir algo más que una base de datos Oracle y centrarse en toda la pila de software de Oracle. ORAchk ahora examina las siguientes áreas.

• Oracle Database (tanto RAC como de instancia única)
• Control de la nube de Enterprise Manager 12c
• Servidores Oracle Sun
• Oracle E-Business Suite

Independientemente del componente de software de Oracle que se esté examinando, ORAchk está analizando la configuración buscando problemas. Puede proporcionar un informe que muestre riesgos para la salud. Se recomienda que el administrador de la base de datos ejecute un informe antes y después de los cambios de configuración del software para comprender si esos cambios pueden causar problemas futuros. Dado que este libro es para el rendimiento de la base de datos Oracle RAC, sólo se discutirá el primer componente de Oracle en la lista anterior. Los otros 3 componentes de software están fuera del alcance de este libro.


La utilidad ORAchk se puede descargar de la Nota 1268927.1 de Oracle My Support. La descarga es un simple archivo zip. Después de descargar el archivo, utilice la utilidad OS unzip para extraer su contenido. La instalación se completa después de descomprimir el archivo. Ejecute el ejecutable orachk para iniciar el análisis. De forma predeterminada, orachk le pedirá que verifique la ubicación actual de Grid Infrastructure. A continuación, orachk verifica la equivalencia de usuario ssh.

Características de ORAchk:

• Escanea de forma proactiva los problemas conocidos más impactantes a través de todo su sistema, así como varias capas de su apilar Simplifica y optimiza la forma de investigar y analizar qué problemas conocidos presentan un riesgo para usted.
• La herramienta ligera funciona dentro de nuestro entorno; no se enviarán datos a Oracle..
• Los informes de alto nivel muestran los riesgos para la salud del sistema con la capacidad de profundizar en problemas específicos y entender sus resoluciones.
• Se puede configurar para enviar notificaciones por correo electrónico cuando detecta problemas.
• Administrador de recopilación, una aplicación complementaria Application Express proporciona una vista única de las colecciones en toda la empresa.
• ORAchk se expandirá en el futuro con un mayor impacto; controles en áreas de productos existentes y adicionales. 

Para obtener más información sobre la herramienta ORAchk, cómo descargarlo, qué hay de nuevo en ORAchk, lea MOS Nota 1268927.2. Si no tienes acceso a MOS, aquí hay una entrada de blog que describen bastante bien la herramienta:

•  ORAchk Health Checks For The Oracle Stack by Levi Pereira

Mejores prácticas de enmascaramiento de datos

Muchas organizaciones arriesgan inadvertidamente la información cuando rutinariamente copian datos de producción sensibles o regulados en entornos que no son de producción. Como resultado, los datos en el entorno de no producción se han convertido cada vez más en el blanco de los delincuentes y pueden ser robados. Al igual que las brechas de datos en entornos de producción, las violaciones de datos en entornos no productivos pueden causar millones de euros en sanciones y causar daños irreparables a la reputación y la marca.

Con Oracle Data Masking, la información sensible y valiosa puede ser reemplazada por valores realistas. Esto permite que los datos se utilicen con seguridad en no producción e incumplimiento con requisitos regulatorios como Sarbanes-Oxley, PCI DSS, HIPAA y en breve la GDPR.

Este artículo describe las mejores prácticas para implementar Oracle Data Masking para proteger la información confidencial en bases de datos Oracle y otras bases de datos heterogéneas como IBM DB2, Microsoft SQL Server.

Las empresas comparten datos de sus aplicaciones de producción con otros usuarios para una variedad de necesidades empresariales.

• Las empresas minoristas comparten datos de puntos de venta con los investigadores de mercado para analizar los patrones de compra de los clientes.
• Las organizaciones farmacéuticas o de salud comparten los datos de los pacientes con los investigadores médicos para evaluar la eficacia de los ensayos clínicos o los tratamientos médicos.
• Las empresas para mantenerse competitivas requieren una funcionalidad nueva y mejorada en las aplicaciones de producción existentes. Como resultado, los desarrolladores de aplicaciones requieren un entorno que imita cerca de la producción para crear y probar la nueva funcionalidad asegurando que la funcionalidad existente no se rompa.

Como resultado de lo anterior, las organizaciones copian datos confidenciales de clientes y consumidores en entornos que no son de producción y muy pocas compañías hacen algo para proteger estos datos, incluso cuando comparten con terceros.

Enmascarar datos en entornos no productivos.

Las organizaciones han tomado estas amenazas en serio y se han propuesto abordar estas cuestiones tan pronto como sea posible conocer las ramificaciones. A pesar de esto, la idea de eliminar información sensible del entorno de no producción parece ser sencilla, pero puede plantear serios desafíos en varios aspectos.

Identificación de información confidencial.

• ¿Qué define la información sensible?
• ¿Dónde reside?
• ¿Cómo se hace referencia?

El desafío también se convierte en mantener el conocimiento de metadatos de la arquitectura de la aplicación a lo largo de su ciclo de vida.

El proceso de enmascaramiento ha de ser tal que la integridad de la aplicación se vuelve primordial. Como ejemplo, enmascarar una parte de la dirección de un cliente, como zip sin considerar la ciudad y el estado, puede hacer que la aplicación sea inutilizable. Por lo tanto el desarrollo o la prueba se vuelven si no imposible, no confiable.La auditoría es otro desafío que se considera seriamente. Saber quién cambió qué y cuándo se convierte en un importante requisito de control de negocios para demostrar el cumplimiento de las regulaciones y leyes.

Para implementar estos controles, se ha de instaurar:

El desafío se convierte en separaciones de deberes, permisos basados en roles y la capacidad de reportar sobre estas actividades.

Las bases de datos se están volviendo muy grandes y la frecuencia de solicitudes para un entorno seguro no relacionado con la producción ha aumentado drásticamente a lo largo de los años. La razón de este aumento es que las empresas desarrollen aplicaciones nuevas y mejores que presten servicios a sus clientes a un ritmo más rápido para mantenerse competitivas. Un proceso de enmascaramiento debe tener un rendimiento aceptable y confiabilidad.

Y, finalmente, tener una solución flexible que puede evolucionar con la aplicación y extenderse a otras aplicaciones dentro de una empresa se convierte en un reto importante para abordar.

La solución más común: scripts de base de datos. A primera vista, una ventaja del enfoque de scripts de base de datos parecería que se refieren específicamente a las necesidades de privacidad de una base de datos específica para la que fueron diseñados. Pueden incluso haber sido ajustados por un DBA para correr en su más rápido

Veamos los problemas con este enfoque.

• Reutilización: No hay capacidades comunes en un script que pueden ser fácilmente apalancadas en otras bases de datos.
• Transparencia: Como los scripts tienden a ser programas monolíticos, los auditores no tienen transparencia en los procedimientos de enmascaramiento utilizados en los scripts. Los auditores encontrarían extremadamente difícil ofrecer cualquier recomendación sobre si el proceso de enmascaramiento incorporado en un guión es seguro y ofrece a la empresa el grado apropiado de protección.
• Mantenimiento: cuando se actualizan estas aplicaciones empresariales, se pueden agregar nuevas tablas y columnas que contienen datos confidenciales como parte del proceso de actualización. Con un enfoque basado en secuencias de comandos, todo el guión tiene que ser revisado y actualizado para acomodar nuevas tablas y columnas agregadas como parte de un parche de aplicación o una actualización.

Implementación de la máscara de datos

Con estos desafíos empresariales en mente, Oracle ha desarrollado un enfoque integral de 4 pasos para implementar el enmascaramiento de datos a través de Oracle Data Masking Pack llamado: Find, Assess, Secure y Test (F.A.S.T). Estos pasos son:

• Buscar: Esta fase implica la identificación y catalogación de datos sensibles o regulados en toda la empresa. Normalmente llevado a cabo por analistas de negocios o de seguridad, el objetivo de este ejercicio es crear una lista exhaustiva de elementos de datos confidenciales específicos de la organización y descubrir las tablas, columnas y relaciones asociadas a las bases de datos empresariales que contienen los datos confidenciales.

• Evaluar: En esta fase, los desarrolladores o DBAs en conjunto con los analistas de negocios o de seguridad identifican los algoritmos de enmascaramiento que representan las técnicas óptimas para reemplazar los datos sensibles originales. Los desarrolladores pueden aprovechar la biblioteca de enmascaramiento existente o ampliarla con sus propias rutinas de enmascaramiento.

• Seguro: Este y el siguiente paso pueden ser iterativos. El administrador de seguridad ejecuta el proceso de enmascaramiento para proteger los datos confidenciales durante las pruebas de enmascaramiento. Una vez que el proceso de enmascaramiento ha finalizado y se ha verificado, el DBA entrega el entorno a los probadores de aplicaciones.

• Prueba: En el paso final, los usuarios de producción ejecutan procesos de aplicación para probar si los datos enmascarados resultantes pueden ser entregados a otros usuarios que no producen. Si las rutinas de enmascaramiento necesitan ser ajustadas aún más, el DBA restaura la base de datos al estado pre-enmascarado, corrige los algoritmos de enmascaramiento y vuelve a ejecutar el proceso de enmascaramiento.