29 septiembre 2017

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.


27 septiembre 2017

La base de datos Oracle y GDPR, una introducción


El Reglamento General de Protección de Datos (Reglamento de la UE 2016/679) es el nuevo marco jurídico de la UE que rige el uso de los datos personales. Este texto deroga la actual Directiva 95/46/CE de protección de datos y sustituye a las leyes de protección de datos nacionales existente (En España, la Ley 15/1999 de Protección de Datos). El texto será aplicable en todos los estados de la Unión Europea de desde 25 de mayo de 2018.

La Unión Europea (UE) introdujo su norma de protección de datos hace 20 años a través de la Directiva 95/46 / CE sobre protección de datos. Debido a que una Directiva permite a los Estados miembros un cierto margen de maniobra al aplicarla en el Derecho nacional, Europa ha terminado con un mosaico de diferentes leyes de privacidad. Además, el aumento de las brechas de seguridad, los rápidos avances tecnológicos y la globalización en los últimos 20 años ha traído nuevos retos para la protección de los datos personales. En un esfuerzo por abordar esta situación, la UE desarrolló el Reglamento General de Protección de Datos (GDPR).

¿Qué debemos hacer ahora para prepararnos para el GDPR?
  • Implementar medidas de seguridad desde el diseño y por defecto en todos los procesos del tratamiento mediante procedimientos y sistemas que garanticen la protección de datos y el ejercicio de los derechos de los interesados.
  • Realizar un análisis de los riesgos que atañen al tratamiento y prevenir su impacto para garantizar los derechos y las libertades de las personas que puedan ser afectadas, asumiendo que la protección de datos es mucho más que un cumplimiento formal y documental.
¿Qué puede hacer Oracle para prepararnos para el GDPR?

El GDPR es aproximadamente de tres a cuatro veces la longitud de la Ley de Protección de Datos (LOPD) de  1998 que está reemplazando.

Los requisitos para las bases de datos son:
  • Descubrimiento
  • Clasificación
  • Enmascaramiento
  • Supervisión
  • Informes de auditoría
  • Respuesta y notificación de incidentes

La sanción máxima por incumplimiento es del 4% del ingreso anual o de 20 millones de euros, el que sea mayor. Pueden aplicarse multas inferiores al 2% para las infracciones administrativas, como no realizar evaluaciones de impacto o notificar a las autoridades o particulares en caso de incumplimiento de los datos. Esto pone las penas de protección de datos en la misma categoría que la anticorrupción o el cumplimiento de la competencia.

Lo que los DBA deben comenzar ahora es cuenta e identificar el 100% de los datos privados ubicados en todas las bases de datos.

Hay cuatro categorías principales en las que participará DBA. 

  1. Evaluar
  2. Evitar
  3. Detectar
  4. Maximizar la protección

Las principales bases legales para el procesamiento de datos son el consentimiento y la necesidad. Los datos pueden ser reconocidos como una necesidad si:
  • Se relaciona con la ejecución de un contrato
  • Ilustra el cumplimiento de una obligación legal
  • Protege los intereses vitales del titular de los datos u otra persona
  • Se relaciona con una tarea que es de interés público
  • Se utiliza para fines de interés legítimo perseguido por el responsable del tratamiento o por un tercero (en caso de que los derechos de la persona afectada lo anulen)

Las solicitudes de acceso de los sujetos de los datos deben ser respondidas dentro de un mes y sin cargo alguno. Esta es una nueva legislación dentro del GDPR y el mismo plazo de un mes se aplica a la rectificación de datos inexactos.

Las notificaciones de infracción deben hacerse dentro de las 72 horas siguientes a la toma de conciencia. Si no se cumple este plazo, se puede imponer una multa de 10 millones de euros, o el 2% del volumen de negocios global. Un incumplimiento es cualquier falla de seguridad que conduzca a la destrucción, pérdida, alteración, divulgación no autorizada o acceso a datos personales. Las autoridades supervisoras deben ser notificadas si una violación resulta en un riesgo para los derechos y libertades de las personas.

Los datos almacenados de forma encriptada o seudónima no se consideran datos personales y quedan fuera del ámbito de aplicación de estas nuevas normas. A pesar de esto, los datos cifrados y considerados seguros utilizando la tecnología de hoy en día pueden volverse legibles en el futuro. Por lo tanto vale la pena considerar el formato que preserva la encriptación / o usar pseudónimos que los hacen anónimos, pero permite al procesamiento seleccionado de esos datos.

11 septiembre 2017

¿Qué es CPU, PSU, SPU?



Esta es una pequeña entrada para explicar ciertos conceptos y terminologia de la herramienta de actualización de las bases de datos, Oracle Critical Patch.

Todo comenzó en enero de 2005 con Actualizaciones críticas de parches, CPU. A continuación, las Actualizaciones de conjuntos de parches (PSU) se agregaron como parches acumulativos que incluían correcciones de prioridad y arreglos de seguridad. A partir de la actualización de revisión crítica de octubre de 2012, Oracle ha cambiado la terminología para diferenciar mejor los tipos de parches. Esta terminología se utilizará para la base de datos Oracle, Enterprise Manager, Fusion Middleware y WebLogic.

Actualización de revisión crítica (CPU) ahora se refiere a la liberación general de revisiones de seguridad cada trimestre en lugar de la revisión de seguridad de base de datos acumulativa para el trimestre. Piense en la CPU como la versión trimestral general y no como un solo parche.

Patch Set Updates (PSU) son los mismos parches acumulativos que incluyen las correcciones de seguridad y las correcciones de prioridad. La clave con las PSU es que son actualizaciones menores de la versión (por ejemplo, 11.2.0.1.1 a 11.2.0.1.2). Una vez que se aplique una PSU, sólo se pueden aplicar PSU en trimestres futuros hasta que la base de datos se actualice a una nueva versión base.

La terminología de Actualización de revisión de seguridad (SPU) se presenta en la actualización de revisión crítica de octubre de 2012 como el término para el parche de seguridad trimestral. Los parches SPU son los mismos que los parches anteriores de la CPU, sólo un nuevo nombre. Para la base de datos, las SPU no se pueden aplicar una vez que se hayan aplicado PSU hasta que la base de datos se actualice a una nueva versión base.

Bundle Patches son los parches trimestrales para Windows y Exadata que incluyen tanto los parches de seguridad trimestrales como las revisiones recomendadas.

Etiqueta:
El nombre de un conjunto de cambios (por ejemplo, la fijación de un error) en el código fuente; la salida de una etiqueta es un conjunto de archivos C (* .c, * .h etc)

Conflicto. Dos o más correcciones de errores que modifican los mismos archivos de código fuente; si este es el caso, sólo se puede aplicar uno, de lo contrario el código de las correcciones tendrá que ser "fusionado" para producir una nueva etiqueta

Interim Patch. Este es el nombre oficial para un parche único. Solución de errores única.

Merge Patch:Esta es una combinación de etiquetas; si por ejemplo tiene dos correcciones de errores que tocan los mismos archivos, entonces tendría que tener esas revisiones fusionadas, produciendo un nuevo parche con una nueva etiqueta

Overlay Patch: Cuando un parche interino de una sola vez entre en conflicto con una PSU, se requiere un parche de superposición. Esto es básicamente una fusión del parche que desea y la PSU.

Overlay PSU: Durante el ciclo de vida de un patchset, las PSU normalmente se publicarán cada trimestre. A medida que el patchset alcanza su madurez, se podría esperar que haya errores menos críticos que puedan ser considerados como candidatos para su inclusión en PSU.
En algún momento el número de correcciones de errores incluidas en cada PSU alcanzará un número suficientemente bajo que ya no se considera que vale la pena hacer la PSU acumulativa.
En este punto, la PSU anterior se convierte en una línea de base y todas las futuras PSU se liberan como "superposición de PSU".

Si quieres ahondar mas en esta nomenclatura consulta la siguiente nota del Oracle Metalink, sí lo sigo llamando ¡así! : Nueva Nomenclatura de Patches para Productos Oracle [ID 1430923.1]

Usar Ansible para realizar tareas de administrador de bases de datos.


La orquestación de las tecnologías de la información se ha vuelto importante con el aumento de la escala web (ampliación y descenso de aplicaciones mediante la adición de máquinas virtuales a tareas de uso intensivo de recursos de escala horizontal), para configurar las máquinas recién agregadas sin intervención manual y la gente empieza a usarlo para usarlo para algo más que tareas de aprovisionamiento de máquinas virtuales para aplicaciones web.

El proyecto Ansible decidió hacerlo radicalmente diferente a todos los demás motores. Es diferente en el sentido de que se anuncia como simple, sin agente y poderoso.

Sencillo.

La sencillez es un gran objetivo. Para aquellos de vosotros que habéis trabajado con la configuración / motores de orquestación, hay una curva de aprendizaje pronunciada. Es difícil obtener los principios básicos en la cabeza. Para ser honesto, Ansible también me tomó un tiempo demasiado, para comprender los principios básicos, y obtener la imagen correctamente en mi cabeza. Sin embargo, después de haber trabajado con cfengine comparándolo con los libros de juicio de Ansible, que son los guiones para hacer las cosas en los objetivos, es un soplo de aire fresco. Playbooks son tan limpias que (casi) se puede leer y entender como Inglés simple.

Sin agente

Aquí es donde Ansible es verdaderamente diferente a cualquiera de las otras herramientas de configuración / orquestación. Ansible no requiere ninguna instalación de agente en los objetivos. La siguiente pregunta obvia entonces es: ¿cómo puede esto funcionar? Bueno, muy sencillo: Ansible utiliza ssh para conectarse al host y ejecuta comandos a través del shell. Dicho esto, requiere un poco más de detalle; Ansible utiliza python en el host remoto para su ejecución normal. Sin embargo, puede utilizarlo sin python, por ejemplo para configurar el host para el modo de uso normal Ansible que requiere python y el módulo simple-json.

Esto es realmente importante, y lo convierte en un excelente ajuste para mi trabajo diario como consultor de TI.

Poderoso.

Ansible es poderoso en la forma en que usted puede hacer las tareas de configuración y orquestación de una manera sencilla y limpia.

En resumen, creo que ser sin agente es la verdadera característica asesina aquí. Todos los otros motores de configuración / orquestación requieren que configure y configure una conexión cliente-servidor fija e instale un proceso (demonio) y un servidor central. La autenticación de contraseña ssh o infraestructura de clave pública se puede utilizar.

Debido a que no hay ningún daemon para instalar, puede ejecutar sus playbooks creados en todas partes. Así que en lugar de una configuración fija de cliente, puede crear libros de juego para realizar tareas de rutina y repetirla en varios sitios.

Instalación: añadir EPEL e instalar ansible.

Si usas uno de los clones de RedHat Enterprise Linux (yo uso Oracle Linux), simplemente tiene que agregar el repositorio EPEL (Extra Packages for Enterprise Linux) a su lista de fuentes yum y ejecutar:

 # yum install ansible

Primeros pasos.

Una de las primeras cosas que hago, es crear un directorio para un típico 'proyecto' ansible. Proyecto significa un conjunto de tareas que desea hacer a un conjunto de hosts aquí. A continuación, creo un archivo llamado 'hosts' que es la lista de hosts que desea utilizar para ejecutar tareas en. De forma predeterminada, Ansible busca en / etc / ansible / hosts. En este caso, pongo una sola máquina en ella (una VM de prueba), pero puede ser una lista de máquinas (direcciones IP o nombres de host).

$ cat hosts
192.168.101.2

De hecho, puede crear grupos en el archivo hosts en el "estilo ini". Pero acabo de poner un anfitrión en este ejemplo.
Lo siguiente es comprobar si Ansible lee el archivo correctamente. Esto se hace de la siguiente manera:

$ ansible todos los hosts -i --list-hosts
    192.168.101.2

Bueno, esto significa que Ansible funcionará en este host si se invoca. La siguiente cosa lógica (normalmente cuando está en un nuevo entorno de cliente para comprobar si puede llegar a los hosts):

$ ansible all -i hosts -m ping
192.168.101.2 | FALLA => FALLA: Error en la autenticación.

Ping puede ser un poco engañoso para algunas personas. Lo que ping hace aquí (-m significa módulo), está tratando de conectarse al host sobre ssh, e iniciar sesión. Como no especificó un usuario, utilizó el nombre de usuario del usuario actual en la máquina, que es 'ansible '. Un usuario 'ansible' normalmente no existe en un servidor normal (y no es necesario o debe ser creado), y tampoco en mi servidor de prueba. Así que falló, como decía el mensaje, en la autenticación.

La máquina virtual de prueba es un servidor Linux 6 instalado (OL) básico. Esto significa que sólo hay un usuario: root.
Por lo tanto, vamos a especificar la raíz del usuario como usuario:

$ ansible all -i hosts -m ping -u raíz
192.168.101.2 | FALLA => FALLA: Error en la autenticación.

La autenticación falló de nuevo. Y debería! Qué está haciendo, está intentando abrir una sesión como raíz, y no hemos dado ninguna contraseña, ni he puesto la llave pública de mi usuario local en el archivo authorised_keys alejado. Así que no hay manera de que esto podría funcionar. Esto también suele ser el estado cuando desea hacer cosas con un sistema de cliente "fresco". Vamos a agregar la opción '-k' (preguntar contraseña ssh), y ejecutar de nuevo:

$ ansible all -i hosts -m ping -u root -k
SSH password:
192.168.101.2 | success >> {
    "changed": false,
    "ping": "pong"
}

Para continar: Ahora pide una contraseña, que he llenado, a continuación, lista el anfitrión y el estado: el éxito. Durante esta ejecución, no hubo cambios en el host remoto, y el comando ping dio como resultado un pong (al igual que la respuesta de ping ICMP).
Con lo que hemos aprendido ahora, podemos hacer cosas como esta:

$ ansible all -i hosts -u root -k -a "ifconfig"
SSH password:
192.168.101.2 | success | rc=0 >>
eth0      Link encap:Ethernet  HWaddr 00:0C:29:14:65:ED
          inet addr:192.168.39.145  Bcast:192.168.39.255  Mask:255.255.255.0
          inet6 addr: fe80::20c:29ff:fe14:65ed/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:47 errors:0 dropped:0 overruns:0 frame:0
          TX packets:25 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:6293 (6.1 KiB)  TX bytes:2594 (2.5 KiB)

eth1      Link encap:Ethernet  HWaddr 00:0C:29:14:65:F7
          inet addr:192.168.101.2  Bcast:192.168.101.255  Mask:255.255.255.0
          inet6 addr: fe80::20c:29ff:fe14:65f7/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:188 errors:0 dropped:0 overruns:0 frame:0
          TX packets:112 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:142146 (138.8 KiB)  TX bytes:15545 (15.1 KiB)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

¿Te resulta familiar? Si eres DBA de Exadata claro que sí, esto reproduce parte de la funcionalidad de dcli (aunque dcli está dirigido a ejecutar tareas simples a un grupo de hosts, mientras que Ansible está dirigido a la configuración y orquestación de la empresa).


Playbooks


Ahora vamos a progresar con los Playbooks. Estos Playbooks de Ansible es donde reside la verdadera fuerza de esta tecnología. Permite especificar las tareas que se deben ejecutar en los hosts remotos y crear secuencias de tareas y tomar decisiones basadas en el resultado de las tareas para una ejecución posterior. Permítanme mostrarles un simple libro de jugadas, y guiarlo a través de él:

- hosts: all
  gather_facts: no
  remote_user: root
  tasks:

  - name: upgrade all packages
    yum: name=* state=latest

  - name: install python-selinux
    yum: name=libselinux-python state=installed

  - name: add public key to authorized_key file of root
    authorized_key: user=root state=present key="{{ lookup('file','/home/ansible/.ssh/id_rsa.pub') }}"

Como se puede ver, este es un playbook con tres tareas:

  • Actualizar todos los paquetes
  • Instalar libselinux-python
  • Agregar mi clave pública (local) al archivo de clave autorizado de root (para permitir el acceso sin contraseña).


La línea 1 muestra tres guiones, lo que significa el inicio de un documento YAML.
La línea 2 comienza con un solo guión, que indica una lista. Hay un guión en este nivel de indentación, por lo que es una lista de uno. Los campos de este miembro son hosts, gather_facts y tasks. Tareas tiene su propia lista (la mente del nivel de indención, que es importante). Los campos son pares clave / valor, con la separación indicada por los dos puntos (:). El primer campo es 'hosts', con el valor 'all'. Esto significa que todos los hosts en el archivo de hosts se utilizan para este libro de jugadas. No creo que sea difícil imaginar lo útil que puede ser especificar un grupo / clase de servidores en los que el libro de jugadas puede funcionar. El siguiente es 'gather_facts'. Una ejecución de libro de jugadas normal reúne primero una gran cantidad de información de todos los hosts que va a ejecutar antes de la ejecución. Éstos se pueden utilizar durante la ejecución del libro de jugadas. Siguiente 'remote_user'. Esto indica con qué usuario ansible va a iniciar sesión, por lo que no tenemos que especificarlo en la línea de comandos. Luego vemos 'tareas' para indicar la lista de tareas que se deben ejecutar en los hosts.


Es fácil ver que tenemos tres tareas. Lo que es extremadamente importante, es la identación de esta lista. El nombre no es obligatorio, pero facilita la lectura si se asignan nombres útiles a las tareas y se mostrarán cuando se ejecute el libro de jugadas. La primera tarea tiene el nombre 'actualizar todos los paquetes'. El siguiente campo muestra que la clave es 'yum' indicando que está haciendo uso del módulo yum. Esta clave tiene dos valores: name = *, que significa todos los 'todos los paquetes', y state = latest, lo que significa que queremos que todos los paquetes estén en la última versión. Esto significa que este comando es el equivalente de 'yum update'.

La segunda tarea se llama 'install python-selinux'. Hace uso del módulo del yum otra vez, y se explica por sí mismo, instala el paquete libselinux-python. Estos paquetes son necesarios para trabajar en un host que tiene selinux habilitado en cosas que están protegidas por selinux.

La siguiente tarea se llama 'agregar clave pública al archivo de raíz autorizada'. Se está utilizando el módulo authorized_key. Este módulo requiere un parámetro 'clave', para el cual usamos la función de búsqueda para buscar la clave pública local (!), Del usuario con el que ejecuto ansible, que es 'ansible'. 'Estado = presente' significa que queremos que esta clave esté presente; 'Presente' es el valor por defecto, por lo que no fue necesario ponerlo. Siguiente 'usuario = root': queremos que la clave pública se agregue al archivo authorized_keys de la raíz del usuario.


Por supuesto, estas tareas se pueden ejecutar utilizando el ejecutable 'ansible' como tareas individuales. Para mostrar la importancia de la instalación del módulo libselinux-python en un host con selinux habilitado (que es el estado de selinux en una nueva máquina Oracle Linux instalada), ejecute la tarea usando el módulo authorized_key:

$ ansible all -i hosts -k -u root -m authorized_key -a "user=root state=present key=\"{{ lookup('file','/home/ansible/.ssh/id_rsa.pub') }}\""
SSH password:
192.168.101.2 | FAILED >> {
    "failed": true,
    "msg": "Aborting, target uses selinux but python bindings (libselinux-python) aren't installed!"
}

Claro, ¿no? El anfitrión es selinux protegido. Ahora, vamos a ejecutar la instalación del paquete libselinux como una sola tarea, y luego agregamos nuestra clave pública al archivo authorized_key de root:

$ ansible all -i hosts -k -u root -m yum -a "name=libselinux-python state=installed"
SSH password:
192.168.101.2 | success >> {
    "changed": true,
    "msg": "",
    "rc": 0,
    "results": [
        "Loaded plugins: security\nSetting up Install Process\nResolving Dependencies\n--> Running transaction check\n---> Package libselinux-python.x86_64 0:2.0.94-5.3.el6_4.1 will be installed\n--> Finished Dependency Resolution\n\nDependencies Resolved\n\\n Package             Arch     Version     Repository Size\n\nInstalling:\n libselinux-python   x86_64   2.0.94-5.3.el6_4.1      public_ol6_latest   201 k\n\nTransaction Summary\n\nInstall       1 Package(s)\n\nTotal download size: 201 k\nInstalled size: 653 k\nDownloading Packages:\nRunning rpm_check_debug\nRunning Transaction Test\nTransaction Test Succeeded\nRunning Transaction\n\r  Installing : libselinux-python-2.0.94-5.3.el6_4.1.x86_64  1/1 \n\r  Verifying  : libselinux-python-2.0.94-5.3.el6_4.1.x86_64   1/1 \n\nInstalled:\n  libselinux-python.x86_64 0:2.0.94-5.3.el6_4.1\n\nComplete!\n"
    ]
}
$ ansible all -i hosts -k -u root -m authorized_key -a "user=root state=present key=\"{{ lookup('file','/home/ansible/.ssh/id_rsa.pub') }}\""
SSH password:
192.168.101.2 | success >> {
    "changed": true,
    "key": "ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAliR905hxLnsOCRlOGnmN0H9dGH4NPV88ySC6GMv0KNnU7FfCXYE51Bkk97p2IWFsPhYO9qJDyAFxRm/lia1IZRDpCFcKKKMh5eXmEJC5XSrHWFdmGZRlFcS3VQ3rpCIyU3qFM6xMazh3JHKKEtE1J6nvw/hW3slY9G/6VoJ8CzpfeQMLDOdVXUIcZXqtCPuIEDBQ7yjfMzTGz+hEmz7ImbLaUyB4MDGrDnl33L8mkBEVYu8RrwgBcagDQSiQKnIca/EL45eX/74NG1e/6vxZkHZJz/W0ak4KD+o9vF4ikz0bdrGPMZ5gRYXWoSSHrVA+Rqk8A93qBXNKUUkzGoQYTQ== ansible@ansiblevm.local",
    "key_options": null,
    "keyfile": "/root/.ssh/authorized_keys",
    "manage_dir": true,
    "path": null,
    "state": "present",
    "unique": false,
    "user": "root"
}

Tal vez su cliente no quiere que almacene sus llaves en sus servidores. Es fácil hacer lo contrario y quitar la llave del archivo authorized_key:

$ ansible all -i hosts -u root -m authorized_key -a "user=root state=absent key=\"{{ lookup('file','/home/ansible/.ssh/id_rsa.pub') }}\""
192.168.101.2 | success >> {
    "changed": true,
    "key": "ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAliR905hxLnsOCRlOGnmN0H9dGH4NPV88ySC6GMv0KNnU7FfCXYE51Bkk97p2IWFsPhYO9qJDyAFxRm/lia1IZRDpCFcKKKMh5eXmEJC5XSrHWFdmGZRlFcS3VQ3rpCIyU3qFM6xMazh3JHKKEtE1J6nvw/hW3slY9G/6VoJ8CzpfeQMLDOdVXUIcZXqtCPuIEDBQ7yjfMzTGz+hEmz7ImbLaUyB4MDGrDnl33L8mkBEVYu8RrwgBcagDQSiQKnIca/EL45eX/74NG1e/6vxZkHZJz/W0ak4KD+o9vF4ikz0bdrGPMZ5gRYXWoSSHrVA+Rqk8A93qBXNKUUkzGoQYTQ== ansible@ansiblevm.local",
    "key_options": null,
    "keyfile": "/root/.ssh/authorized_keys",
    "manage_dir": true,
    "path": null,
    "state": "absent",
    "unique": false,
    "user": "root"
}

Por favor, no especificé '-k' en la línea de comandos para enviar una contraseña: en el paso anterior añadimos nuestra clave, para que podamos acceder a nuestro host usando nuestra clave pública. Otra cosa extremadamente importante es 'cambiado'. 'Changed' indica si la tarea realmente cambió algo en el servidor de destino.

He corrido sola tarea hasta ahora, he cambiado el estado de mi VM de prueba de nuevo a su estado antes de empezar a cambiar con ansible (mediante la eliminación del paquete libselinux utilizando 'ansible todo-i hosts -k -u root -m yum -a "Nombre = libselinux-python state = ausente" '


Vamos a ejecutar la playbook descrita anteriormente, el resultado es:

$ ansible-playbook -i hosts -k linux_setup_example.yml
 [WARNING]: The version of gmp you have installed has a known issue regarding
timing vulnerabilities when used with pycrypto. If possible, you should update
it (ie. yum update gmp).

SSH password:

PLAY [all] ********************************************************************

TASK: [upgrade all packages] **************************************************
changed: [192.168.101.2]

TASK: [install python-selinux] ************************************************
changed: [192.168.101.2]

TASK: [add public key to authorized_key file of root] *************************
changed: [192.168.101.2]

PLAY RECAP ********************************************************************
192.168.101.2              : ok=3    changed=3    unreachable=0    failed=0


Ahora en este punto puede ser que pienses: Lo consigo, pero éstas son todas las tareas bastante simples, no es especial en absoluto. Bueno, ahora vamos a describir un caso real que muestra totalmente lo que la importancia de usar esto es, incluso en una sola máquina, pero aún más cuando tienes un gran grupo de servidores que tienes que administrar.

El siguiente ejemplo es una playbook creada para aplicar PSU (Actualizaciones del conjunto de parches) a una Oracle 11.2.0.4. Todavía es bastante simple, sólo se aplica PSU3 al home de Oracle, totalmente automático, ya es bueno tener automatizado mucho trabajo para una sola home, y ahorra un montón de horas (osea: mucho dinero), y te ahorra de error humano.

---
- hosts: all
  vars:
    u01_size_gb: 1
    tmp_size_gb: 1
    oracle_base: /u01/app/oracle
    oracle_home: /u01/app/oracle/product/11.2.0.4/dbhome_1
    patch_dir: /u01/install
  remote_user: oracle
  tasks:

  - name: check u01 free disk space
    action: shell df -P /u01 | awk 'END { print $4 }'
    register: u01size
    failed_when: u01size.stdout|int < {{ u01_size_gb }} * 1024 * 1024

  - name: check tmp free disk space
    action: shell df -P /tmp | awk 'END { print $4 }'
    register: tmpsize
    failed_when: tmpsize.stdout|int < {{ tmp_size_gb }} * 1024 * 1024

  - name: create directory for installation files
    action: file dest={{ patch_dir }} state=directory owner=oracle group=oinstall

  - name: copy opatch and psu
    copy: src=files/{{ item }} dest={{ patch_dir }} owner=oracle group=oinstall mode=0644
    with_items:
     - p6880880_112000_Linux-x86-64.zip
     - p18522509_112040_Linux-x86-64.zip
     - ocm.rsp

  - name: install opatch in database home
    action: shell unzip -oq {{ patch_dir }}/p6880880_112000_Linux-x86-64.zip -d {{ oracle_home }}

  - name: unzip psu patch
    action: shell unzip -oq {{ patch_dir }}/p18522509_112040_Linux-x86-64.zip -d {{ patch_dir }}

  - name: patch conflict detection
    action: shell export ORACLE_HOME={{ oracle_home }}; cd {{ patch_dir }}/18522509; $ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -ph ./
    register: conflict_detection
    failed_when: "'Prereq \"checkConflictAgainstOHWithDetail\" passed.' not in conflict_detection.stdout"

  - name: apply psu
    action: shell export ORACLE_HOME={{ oracle_home}}; cd {{ patch_dir }}/18522509; $ORACLE_HOME/OPatch/opatch apply -silent -ocmrf {{ patch_dir }}/ocm.rsp
    register: apply_psu
    failed_when: "'Composite patch 18522509 successfully applied.' not in apply_psu.stdout"

  - name: clean up install directory
    file: path={{ patch_dir }} state=absent

Espero que esto demuestre lo que Ansible puede ser para un consultor. Este tipo de herramienta es simplemente obligatorio si tienes un entorno con más de aproximadamente diez a veinte servidores para administrar. Ansible puede utilizarse incluso si la organización no quiere dedicar tiempo a la implementación de una herramienta de configuración.




10 septiembre 2017

Royale Rumble: Oracle VS Redis


Comparación extraída de la página DB-Engines 


Nombre
Oracle
Redis
Descripción
Ampliamente usadaSGBD relacional
Almacén de estructura de datos en memoria, utilizado como base de datos, caché y agente de mensajes
Primary database model
SGBD relacional
Almacén de clave-valor
Score
1359.09
Rank
#1
  Overall
#1
Score
120.41
Rank
#9
  Overall
#1
Website
www.oracle.com/­database/­index.html
Documentación Técnica
Desarrollado por
Oracle
Salvatore Sanfilippo 
Entrega inicial
1980
2009
Versión actual
12 Release 2 (12.2.0.1), March 2017
4.0.1, July 2017
Licencia
comercial 
Open Source 
Basado en la nube 
no
no
Lenguaje de implementación
C and C++
C
S.O.
AIX
HP-UX
Linux
OS X
Solaris
Windows
z/OS
BSD
Linux
OS X
Windows 
Esquema de datos
schema-free
Soporte de escritura
parcial 
XML
no
Índices secundarios
no
SQL 
no
APIs y otros métodos de acceso
ODP.NET
Oracle Call Interface (OCI)
JDBC
ODBC
Protocolo propietario
Lenguajes de programación compatibles
C
C#
C++
Clojure
Cobol
Delphi
Eiffel
Erlang
Fortran
Groovy
Haskell
Java
JavaScript
Lisp
Objective C
OCaml
Perl
PHP
Python
R
Ruby
Scala
Tcl
Visual Basic
C
C#
C++
Clojure
Crystal
D
Dart
Elixir
Erlang
Fancy
Go
Haskell
Haxe
Java
JavaScript (Node.js)
Lisp
Lua
MatLab
Objective-C
OCaml
Perl
PHP
Prolog
Pure Data
Python
R
Rebol
Ruby
Rust
Scala
Scheme
Smalltalk
Tcl
Server-side scripts 
PL / SQL
Lua
Disparadores de bases de datos
si
no
Métodos de particionamiento
división horizontal
Sharding
Métodos de replicación
Replicación maestro-maestro
Replicación maestro-esclavo
Mapareduce
Replicación maestro-esclavo
no
Conceptos de consistencia
no
Consistencia eventual
Llaves extranjeras
Consistencia inmediata
no
Conceptos de transacción
si
Bloqueo optimista, ejecución atómica de bloques de comandos y scripts
Concurrencia
ACID
si
Durabilidad
si
si
Capacidades en memoria
si
si
Conceptos de usuario
si
Control de acceso simple basado en contraseña