¿Hay vida más allá de Oracle?, Hoy, Voldemort a.k.a Amazon Dynamo

 

Voldemort es un sistema de almacenamiento de valor clave distribuido

• Los datos se replican automáticamente en varios servidores.
• Los datos se particionan automáticamente para que cada servidor contenga solo un subconjunto de los datos totales
• Proporciona una consistencia ajustable (quórum estricto o consistencia eventual)
• La falla del servidor se maneja de manera transparente
• Motores de almacenamiento conectables: BDB-JE, MySQL, solo lectura
• Serialización conectable - Búferes de protocolo, Thrift, Avro y serialización de Java
• Los elementos de datos se versionan para maximizar la integridad de los datos en escenarios de falla sin comprometer la disponibilidad del sistema
• Cada nodo es independiente de otros nodos sin un punto central de falla o coordinación.
• Buen rendimiento de un solo nodo: puede esperar de 10 a 20.000 operaciones por segundo, según las máquinas, la red, el sistema de disco y el factor de replicación de datos
• Soporte para estrategias de colocación de datos conectables para respaldar cosas como la distribución entre centros de datos que están geográficamente alejados.

Es utilizado en LinkedIn por numerosos servicios críticos que impulsan una gran parte del sitio.

Comparación con bases de datos relacionales

Voldemort no es una base de datos relacional, no intenta satisfacer relaciones arbitrarias mientras satisface las propiedades ACID. Tampoco es una base de datos de objetos que intenta mapear de forma transparente gráficos de referencia de objetos. Tampoco introduce una nueva abstracción como la orientación al documento. Es básicamente una tabla hash grande, distribuida, persistente y tolerante a fallas. Para aplicaciones que pueden utilizar un mapeador O / R como registro activo o hibernación, esto proporcionará escalabilidad horizontal y una disponibilidad mucho mayor, pero con una gran pérdida de conveniencia. Para aplicaciones grandes bajo presión de escalabilidad del tipo de Internet, un sistema probablemente puede consistir en una serie de servicios o API funcionalmente particionados, que pueden administrar recursos de almacenamiento en múltiples centros de datos utilizando sistemas de almacenamiento que a su vez pueden estar divididos horizontalmente. Para las aplicaciones en este espacio, las uniones arbitrarias en la base de datos ya son imposibles ya que todos los datos no están disponibles en una sola base de datos. Un patrón típico es introducir una capa de almacenamiento en caché que de todos modos requerirá semántica de tabla hash. Para estas aplicaciones, Voldemort ofrece una serie de ventajas:

• Voldemort combina el almacenamiento en caché de la memoria con el sistema de almacenamiento para que no se requiera un nivel de almacenamiento en caché separado (en cambio, el sistema de almacenamiento en sí es simplemente rápido)
• A diferencia de la replicación de MySQL, tanto las lecturas como las escrituras escalan horizontalmente
• El reparto de datos es transparente y permite la expansión del clúster sin reequilibrar todos los datos.
• La replicación y ubicación de datos se decide mediante una API simple para poder adaptarse a una amplia gama de estrategias específicas de la aplicación
• La capa de almacenamiento es completamente simulada, por lo que el desarrollo y las pruebas unitarias se pueden realizar en un sistema de almacenamiento en memoria desechable sin necesidad de un clúster real (o incluso un sistema de almacenamiento real) para realizar pruebas simples.

Este software

Configuración

Hay tres archivos de configuración que controlan el funcionamiento del servidor:

• cluster.xml: contiene la información sobre todos los nodos (es decir, servidores) en el clúster, en qué nombre de host se encuentran, los puertos que usan, etc. Es exactamente lo mismo para todos los nodos de voldemort. No contiene parámetros de ajuste ni directorios de datos para esos nodos, ya que esa información no es pública para el clúster, sino que es específica de esa configuración de nodos en particular.
• stores.xml: contiene la información sobre todas las tiendas (es decir, tablas) en el clúster. Esto incluye información sobre el número necesario de lecturas correctas para mantener la coherencia, el número necesario de escrituras, así como cómo las claves y los valores se serializan en bytes. Es igual en todos los nodos del clúster.
• server.properties: contiene los parámetros de ajuste que controlan un nodo en particular. Esto incluye la identificación del nodo local para que sepa qué entrada en cluster.xml corresponde a sí mismo, también el tamaño de la agrupación de subprocesos, así como cualquier configuración necesaria para el motor de persistencia local como BDB o mysql. Este archivo es diferente en cada nodo. Finalmente, hay una variable de entorno, VOLDEMORT_HOME, que controla el directorio en el que residen los datos y la configuración. Puede ver un ejemplo de cómo se presenta la configuración en el subdirectorio config / del proyecto. Esto incluye configuraciones de muestra que puede modificar con sus propios detalles.

Configuración de clúster

A continuación, se muestra un cluster.xml de ejemplo para un clúster de 2 nodos con 8 particiones de datos. También tenemos campos de 'zona' opcionales que le permiten mapear nodos a ciertos clústeres lógicos (centro de datos, rack, etc.) llamados zonas:

<cluster>     <!-- The name is just to help users identify this cluster from the gui -->     <name>mycluster</name>     <zone>       <zone-id>0</zone-id>       <proximity-list>1</proximity-list>     <zone>     <zone>       <zone-id>1</zone-id>       <proximity-list>0</proximity-list>     <zone>     <server>   <! - La identificación del nodo es una identificación secuencial única que comienza con 0 que identifica a cada servidor en el clúster ->       <id>0</id>       <host>vldmt1.prod.linkedin.com</host>       <http-port>8081</http-port>       <socket-port>6666</socket-port>       <admin-port>6667</admin-port>       <! - Una lista de particiones de datos asignadas a este servidor ->       <partitions>0,1,2,3</partitions>       <zone-id>0</zone-id>     </server>     <server>       <id>1</id>       <host>vldmt2.prod.linkedin.com</host>       <http-port>8081</http-port>       <socket-port>6666</socket-port>       <admin-port>6667</admin-port>       <partitions>4,5,6,7</partitions>       <zone-id>1</zone-id>     </server>   </cluster>

Una cosa que es importante entender es que las particiones no son particiones estáticas de servidores, sino que son un mecanismo para particionar el espacio de claves de tal manera que cada clave se asigna estáticamente a una partición de datos en particular. Esto significa que un clúster en particular puede admitir muchas tiendas, cada una con diferentes factores de replicación; el factor de replicación no está codificado en el diseño del clúster. Esto es importante, ya que algunos datos son más importantes que otros, y la compensación correcta entre rendimiento y consistencia para una tienda puede ser diferente de otra.

Otro punto importante para recordar es que no se puede cambiar el número de particiones de datos. Apoyamos una redistribución en línea (reequilibrio) de particiones. En otras palabras, la inclusión de nuevos nodos da como resultado el traslado de la propiedad de las particiones, pero el número total de particiones siempre será el mismo, al igual que la asignación de clave a partición. Esto significa que es importante dar un buen número de particiones para empezar. El script aquí generará esta parte de la configuración por usted.

Gestión de BDB

El almacén de clave-valor subyacente también es importante para la configuración y la gestión de operaciones. Si se utiliza BDB, toda la configuración se realiza a través del archivo server.properties. Si se utiliza MySQL, se debe realizar la administración habitual de mysql.

Oracle tiene una reseña que brinda una buena descripción general del lado operativo de BDB.

Oracle NoSQL Database es una base de datos NoSQL tipo clave-valor (del estilo de Redis o Voldemort): Sus principales características son: Arquitectura · Está construida sobre Oracle Berkeley DB Java Edition sobre la que añade una capa de servicios para usarse en entornos distribuidos  Alta Disponibilidad y No-Single Point of Failure Provee replicación de base de datos 1 Master-Multi-Replica Las datos transaccionales se replican  Balanceo de carga transparente: · El Driver de Oracle NoSQL particiona los datos en tiempo real y los distribuye sobre los nodos de almacenaminto · Su topología rutea las operaciones de escritura y lectura al nodo de almacenamiento más adecuado para optimizar la distribución de carga y rendimiento Formato JSON · La version 2 añade sopote para serialización con Avro, lo que permite definer un schema en JSON para los datos almacenados Topologías configurables · Los administradores pueden indicar cuanta capacidad está disponible en un nodo de almacenamiento permitiendo a los nodos con más capacidad almacenar varios nodos de replicación Administación sencilla y Monitorización: · Oracle NoSQL suministra un servicio de administración, tanto por consola web

 

Algunas sugerencias adicionales

Configuración de JVM

En LinkedIn mantenemos dos conjuntos de clústeres, de solo lectura y de lectura y escritura. Los clústeres de lectura y escritura son clústeres que utilizan almacenes BDB y tienen características de JVM totalmente diferentes de los que utilizan almacenes de solo lectura. Esto es lo que usamos en LinkedIn para nuestras tiendas de lectura y escritura:

  # Tamaño mínimo, máximo y total de JVM

  JVM_SIZE = "- servidor -Xms32g -Xmx32g"

  # Tamaños de nueva generación

  JVM_SIZE_NEW = "- XX: NewSize = 2048m -XX: MaxNewSize = 2048m"

  # Tipo de recolector de basura a usar

  JVM_GC_TYPE = "- XX: + UseConcMarkSweepGC -XX: + UseParNewGC"

  # Opciones de ajuste para el recolector de basura anterior

  JVM_GC_OPTS = "- XX: CMSInitiatingOccupancyFraction = 70 -XX: SurvivorRatio = 2"

  # Configuración de registro de actividad de JVM GC

  JVM_GC_LOG = "- XX: + PrintTenuringDistribution -XX: + PrintGCDetails -XX: + PrintGCDateStamps -Xloggc: $ LOG_DIR / gc.log"

Tener en cuenta que debe usar la marca simultánea y el barrido gc o, de lo contrario, el GC se detiene para recolectar un montón tan grande que causará períodos que no responden (tampoco sucede al principio, se arrastra y luego finalmente entra en una espiral de gc pause death ).

Esta es la configuración en una caja de RAM de 48 GB con un tamaño de caché BDB de 20 GB y 1 hilo más limpio, en SSD. Puede encontrar la configuración completa en config / prod_single_node_cluster. Para abrir un servidor con esta configuración, use bin / voldemort-prod-server.sh

Prácticas recomendadas de copia de seguridad y recuperación de bases de datos

 

La capacidad de restaurar bases de datos a partir de copias de seguridad válidas es una parte vital para garantizar la continuidad del negocio. La integridad de la copia de seguridad y las restauraciones son una pieza importante de los objetivos de control de TI del IT Governance Institute para Sarbanes-Oxley, 2.ª edición. En muchos casos, los auditores de TI simplemente confirman si las copias de seguridad se están realizando en disco o en cinta, sin considerar la integridad o viabilidad de los medios de copia de seguridad.

Este artículo cubre los temas relacionados con la pérdida de datos y los tipos de respaldo y recuperación de bases de datos disponibles. También se proporcionan las mejores prácticas que pueden ayudar a un auditor a evaluar la efectividad de la copia de seguridad y recuperación de la base de datos. Este artículo se centra en las tecnologías y capacidades del sistema de administración de bases de datos relacionales (RDBMS) de Oracle y Microsoft (MS) SQL Server porque, en conjunto, cubren aproximadamente el 40 por ciento de todas las instalaciones de bases de datos. 

Una de las responsabilidades clave de un administrador de bases de datos (DBA) es prepararse para la posibilidad de fallas en los medios, hardware y software, así como recuperar bases de datos durante un desastre. En caso de que ocurra alguna de estas fallas, el objetivo principal es garantizar que la base de datos esté disponible para los usuarios dentro de un período de tiempo aceptable, al tiempo que se asegura que no haya pérdida de datos. Los administradores de bases de datos deben evaluar su preparación para responder eficazmente a tales situaciones respondiendo las siguientes preguntas:

• ¿Qué tan seguro está el DBA de que los datos de los que depende el negocio de la empresa se hayan respaldado correctamente y que los datos se pueden recuperar de estos respaldos dentro de los límites de tiempo permitidos, según un acuerdo de nivel de servicio (SLA) o el objetivo de tiempo de recuperación, como se especifica en el plan de recuperación ante desastres de la organización?
• ¿Ha tomado el DBA medidas para redactar y probar los procedimientos para proteger y recuperar las bases de datos de numerosos tipos de fallas?

La siguiente es una lista de verificación para los procedimientos de copia de seguridad y recuperación de la base de datos que se explican a lo largo de este artículo:

• Desarrolle un plan de respaldo integral.
• Realice una gestión de copias de seguridad eficaz.
• Realice pruebas periódicas de restauración de bases de datos.
• Tener SLA de respaldo y recuperación redactados y comunicados a todas las partes interesadas.
• Haga que se redacte y documente la parte de la base de datos del plan de recuperación ante desastres (DRP).
• Mantenga actualizados sus conocimientos y experiencia sobre las herramientas de copia de seguridad y recuperación de bases de datos y sistemas operativos.

Plan de respaldo integral

Los DBA son responsables de elaborar un plan de respaldo integral para las bases de datos de las que son responsables. El plan de respaldo debe incluir todos los tipos de RDBMS dentro de la empresa y debe cubrir las siguientes áreas:

• Decide qué necesitas respaldar. Es imperativo que el DBA esté al tanto de la base de datos y los componentes de aplicaciones y sistemas operativos relacionados que deben respaldarse, ya sea mediante una copia de seguridad en línea o una copia de seguridad en frío fuera de línea.

          Los siguientes son detalles de lo que se debe respaldar:            

• Software del sistema operativo: un evento como una falla de hardware requerirá una restauración completa del sistema, comenzando con el sistema operativo, por lo que es necesario realizar una copia de seguridad del sistema operativo del servidor de base de datos inicialmente y después de cualquier actualización del sistema o cambio de configuración.
• Software RDBMS: se debe realizar una copia de seguridad del software RDBMS inicialmente y después de cualquier parche / actualización.
• Software de aplicación (cuando corresponda): esto se aplica especialmente a Oracle E-Business Suite, Oracle Application Server y Oracle Enterprise Manager (OEM). El administrador de bases de datos de la aplicación debe completar una copia de seguridad completa inicial de las aplicaciones en el disco utilizando un comando del sistema operativo apropiado y, luego, programar futuras copias de seguridad incrementales, por ejemplo, después de cualquier parche / actualización. Estas copias de seguridad también deben transferirse a cinta.
• Contraseñas: se deben conservar todas las contraseñas de superusuario que puedan ser necesarias durante la recuperación. Es una buena idea asegurarse de que se cambien las contraseñas predeterminadas que vinieron con la instalación inicial del RDBMS.
• Todos los componentes de las bases de datos de Oracle:
• Archivo de parámetros de la base de datos: un archivo de parámetros o un archivo de parámetros del servidor (SPFILE) define los parámetros de inicialización persistentes de una base de datos, incluida la información sobre los archivos de control de la base de datos.
• Archivo (s) de control de la base de datos: el archivo de control almacena el estado de la estructura física de la base de datos. Si deja de estar disponible, la base de datos no puede funcionar. Es imperativo que se realice una copia de seguridad de estos archivos mientras se realiza una copia de seguridad de otros componentes de la base de datos. En versiones posteriores de Oracle (9i en adelante), el DBA puede configurar la copia de seguridad automática del archivo de parámetros, así como el archivo de control, para garantizar que se realice una copia de seguridad de estos después de cada copia de seguridad y después de cualquier cambio estructural en la base de datos.
• Archivos de datos de la base de datos: estos deben respaldarse durante la copia de seguridad en frío, así como durante la copia de seguridad en línea, utilizando el Administrador de recuperación de Oracle (RMAN) o, en las versiones de Oracle Database en las que no se introdujo RMAN, colocando los espacios de tabla en modo de copia de seguridad. El DBA debe intentar ejecutar todas las bases de datos de producción en el modo de registro de archivo para que sea posible la recuperación hasta el punto de falla.
• Rehacer los archivos de registro y los registros de rehacer archivados: mientras realiza una copia de seguridad en frío, el DBA necesita hacer una copia de seguridad de los registros de rehacer. Cuando la base de datos se ejecuta en modo de registro de archivo y realiza una copia de seguridad en línea, el DBA necesita archivar los registros de rehacer de forma manual o automática y luego hacer una copia de seguridad de todos los registros de rehacer del archivo.
• Archivos de red de Oracle: es importante realizar una copia de seguridad de todos los archivos de red de Oracle inicialmente y después de cualquier cambio.
• Archivos de contraseña: los archivos de contraseña, cuando se utilizan, deben respaldarse inicialmente y después de cualquier cambio. Wallets, por ejemplo.
• Bases de datos de MS SQL Server:
• Realice una copia de seguridad de las bases de datos del sistema y de los usuarios.
• Tenga un plan de mantenimiento separado para las bases de datos del sistema, es decir, maestro, modelo, msdb. Master solo admite copias de seguridad completas; La copia de seguridad de tempdb no es necesaria, ya que se reconstruye durante el inicio de SQL Server.
• Realice una copia de seguridad de todas las bases de datos de los usuarios. Configure todas las bases de datos de usuarios para el modelo de recuperación completo y realice una copia de seguridad de los registros de transacciones y de la base de datos.
• Determine el tipo de copia de seguridad apropiado para usar con sus datos.
• Bases de datos de Oracle
1. Copias de seguridad lógicas: este tipo de copia de seguridad se realiza mediante las utilidades de Oracle "exp." A partir de la versión 10g, también se puede utilizar Data Pump. Se puede realizar una copia de seguridad de toda la base de datos, esquemas individuales, tablas o espacios de tabla. La restauración se realiza mediante "imp" o Data Pump. Con tales copias de seguridad, la recuperación hasta el punto de falla no es posible.
1. Respaldos físicos fuera de línea o en frío: la base de datos se debe cerrar y se debe realizar una copia de todos los archivos de datos esenciales y otros componentes de la base de datos.
1. Copias de seguridad físicas en línea o en caliente: este método permite realizar copias de seguridad de la base de datos mientras la base de datos está en funcionamiento. Se deben tener en cuenta los siguientes puntos al realizar copias de seguridad en línea:
• Ponga los espacios de tabla en modo de copia de seguridad y haga una copia de seguridad de los archivos de datos asociados mediante un comando de copia del sistema operativo, o utilice RMAN, una herramienta sólida proporcionada por Oracle para la copia de seguridad y la recuperación con la versión 8.x en adelante. Oracle agrega nueva funcionalidad a esta herramienta con cada versión. RMAN puede usar el archivo de control de la base de datos para mantener su catálogo, o el DBA puede configurar el esquema para cada base de datos, en una base de datos separada para los catálogos de RMAN.
• El DBA debe revisar y tener en cuenta la matriz de compatibilidad de RMAN para la base de datos que se está respaldando / restaurando, así como el ejecutable de RMAN y la base de datos / esquema del catálogo de RMAN.
• Los administradores de bases de datos deben familiarizarse con las copias de seguridad completas, incrementales y diferenciales y configurarlas mediante scripts de RMAN. Los DBA deben revisar su edición RDBMS, por ejemplo, las copias de seguridad incrementales no son posibles en las ediciones estándar anteriores a Oracle 10g. Para restaurar / recuperar una base de datos hasta el punto de falla o un punto anterior en el tiempo, el DBA debe poner la base de datos en modo de registro de archivo y hacer una copia de seguridad de todos los registros de rehacer archivados.
• Es importante no olvidar realizar una copia de seguridad del catálogo de RMAN al final de cada copia de seguridad. Los administradores de bases de datos pueden realizar una copia de seguridad de exportación del esquema de catálogo de RMAN.
• Base de datos Microsoft SQL Server:
• Copias de seguridad lógicas: en SQL Server, se pueden realizar copias de seguridad de objetos de esquema individuales en archivos planos en cualquiera de los formatos de archivo admitidos. Luego, los archivos planos se pueden restaurar utilizando herramientas como la utilidad bcp, el Asistente de importación y exportación o las herramientas de SQL Server Integration Services.
• Copias de seguridad físicas: se recomienda que todas las bases de datos de los usuarios se configuren para el modelo de recuperación completa, y que tanto la base de datos como los registros de transacciones sean respaldados para restaurar / recuperar la base de datos hasta el punto de falla. Los administradores de bases de datos deben familiarizarse a fondo con los modelos de recuperación de bases de datos y las copias de seguridad completas, diferenciales y de registro de transacciones, y configurarlas en consecuencia. La estrategia de copia de seguridad de archivos o grupos de archivos se puede utilizar si las bases de datos de las que se realizará la copia de seguridad son bases de datos muy grandes (VLDB) que están particionadas entre varios archivos.

• Establezca una estrategia para manejar las copias de seguridad de VLDB: en Oracle, el DBA puede reducir la ventana de copia de seguridad para las VLDB asignando varios canales y ajustando las copias de seguridad, puede ahorrar espacio en disco mediante el uso de copias de seguridad comprimidas y puede bloquear el seguimiento con técnicas de copia de seguridad incrementales con lo último Versiones El DBA debe revisar la versión y edición de la base de datos para confirmar la disponibilidad de esta opción. Si esto no funciona, el DBA puede considerar configurar copias de seguridad de espejo dividido. Para SQL Server, el DBA puede dividir la base de datos entre varios archivos y utilizar la estrategia de copia de seguridad de archivos o grupos de archivos. Además, el uso de varios dispositivos de respaldo en SQL Server permite que los respaldos se escriban en todos los dispositivos en paralelo.
• Establezca una programación y una ventana de respaldo adecuadas: es una buena práctica seleccionar una ventana de respaldo en un punto en el que la menor cantidad de actividad afecte a la base de datos para que la copia de respaldo no reduzca los recursos disponibles del servidor de base de datos y ralentice la actividad del usuario de la base de datos. El DBA puede ajustar la ventana de respaldo al paralelizar los respaldos utilizando múltiples canales; sin embargo, el DBA debe revisar la versión y edición de la base de datos para confirmar la disponibilidad de esta opción. En la gran mayoría de los casos, es mejor configurar un ciclo de respaldo semanal comenzando con respaldos completos el viernes por la noche o el sábado por la mañana y respaldos incrementales / diferenciales durante los días de semana. Las copias de seguridad del registro de transacciones / archivos se pueden programar para cada pocas horas, dependiendo de la volatilidad de la base de datos.
• Decida dónde almacenar las copias de seguridad: se pueden realizar copias de seguridad de las bases de datos de Oracle y MS SQL Server directamente en cinta o disco (localmente o en la red), y luego las copias de seguridad se pueden archivar en cinta. Es una buena práctica realizar copias de seguridad en disco, transferirlas a cinta y almacenar cintas fuera del sitio para la recuperación de desastres (DR). Las copias de seguridad en disco son más rápidas; Los administradores de bases de datos tienen más control y pueden monitorearlos mejor y, con este método, los administradores de bases de datos mantienen dos conjuntos de copias de seguridad, una en disco y la otra en cinta. Durante la restauración, si las copias de seguridad aún están en el disco, será una restauración más rápida, reduciendo el tiempo medio de recuperación (MTTR).
• Desarrolle una política de retención de copias de seguridad: la política de retención de copias de seguridad se relaciona con el programa de rotación del disco y la cinta y debe decidirse según el SLA establecido con la comunidad de usuarios empresariales. El propietario de los datos debe especificar el período de conservación de los datos. El período de retención puede variar de meses a años, según las leyes locales. En consecuencia, el DBA debería eliminar las copias de seguridad antiguas para crear espacio para las copias de seguridad actuales. La política de retención de datos debe elegirse con cuidado, asegurándose de que complementa la política de retención del subsistema de medios de respaldo y los requisitos para la estrategia de recuperación de respaldo. Si no utiliza un catálogo, el DBA debe asegurarse de que el parámetro de instancia de tiempo de mantenimiento de registros del archivo de control coincida con la política de retención.

Gestión eficaz de copias de seguridad

Después de hacer un plan de respaldo sólido y completar el trabajo inicial, el DBA debe administrar adecuadamente los respaldos, teniendo en cuenta los siguientes puntos:

• Automatización de copias de seguridad: para Oracle, configure las copias de seguridad a través de OEM o utilice una herramienta de programación del sistema operativo, y envíe la salida a un archivo de registro que pueda revisarse en busca de errores. En SQL Server, use planes de mantenimiento para programar copias de seguridad.
• Supervisión de copias de seguridad: configure la supervisión con las herramientas adecuadas para que el administrador de bases de datos reciba un correo electrónico o una alerta a través de un buscapersonas o teléfono celular por cualquier copia de seguridad fallida, que debe volver a ejecutarse lo antes posible.
• Registros y catálogos de respaldo: revise los registros de respaldo y la información del catálogo de respaldo periódicamente para detectar cualquier problema. Utilice los informes de RMAN para mostrar el estado de la copia de seguridad. Para Oracle, realice una copia de seguridad de la base de datos del catálogo RMAN exportando todos los esquemas del catálogo periódicamente, así como realizando una copia de seguridad de exportación del esquema del catálogo RMAN al final de cada copia de seguridad. Para SQL Server, bases de datos del sistema de respaldo, especialmente master y msdb.
• Mantenimiento del catálogo de la base de datos: con las bases de datos de Oracle, utilice "eliminar obsoletos" para eliminar las copias de seguridad que están fuera de la política de retención de la organización. Si no se eliminan las copias de seguridad obsoletas, el catálogo seguirá creciendo y el rendimiento se convertirá en un problema. La verificación cruzada (copia de seguridad de verificación cruzada) comprobará que el archivo de catálogo / control coincide con las copias de seguridad físicas.
• Validación de copias de seguridad: valide y verifique las copias de seguridad sin realizar restauraciones reales.
• Configuración de dependencias: cuando realice una copia de seguridad en disco, archive estas copias de seguridad en cinta tan pronto como se complete la copia de seguridad en disco.

Configure un proceso para que las copias de seguridad del disco se transfieran a cinta sin pérdida de tiempo.

Prueba de restauración de respaldo

Imagine el siguiente escenario: una inundación ha azotado el área en la que reside la sede de una empresa y toda la infraestructura de TI se ha dañado, pero no se ha destruido. Antes del evento, los administradores de bases de datos realizaron copias de seguridad en los medios de copia de seguridad, siguiendo todos los procesos indicados anteriormente en este artículo, y los almacenaron fuera del sitio. En la auditoría de TI más reciente de la empresa, el auditor calificó el proceso de respaldo como "efectivo".

Se recuperan y cargan los medios de respaldo del almacenamiento externo. Aparece un mensaje en la pantalla que indica que los medios de respaldo son "ilegibles" debido a problemas de integridad. ¿Lo que podría haber ocurrido?  Pueden haber pasado muchas cosas. Sin embargo, está claro que no se dio un paso crítico. La restauración desde los medios de respaldo nunca se probó realmente. El control se marcó como efectivo porque se había implementado un proceso de respaldo y se estaba realizando. Además, nunca se recibieron errores cuando la empresa realizó una copia de seguridad en los medios de copia de seguridad.

Las copias de seguridad no sirven de nada si el equipo de TI no puede restaurar los datos en el sistema en el momento en que sea necesario. Un DBA debe formular una estrategia detallada para esta tarea:

1. Prueba de restauración de bases de datos: debe existir un requisito para probar las restauraciones de la base de datos desde el disco y desde las copias de seguridad en cinta.
2. Validación de restauraciones siempre que sea posible: el DBA puede validar y verificar las copias de seguridad sin realizar restauraciones reales. La validación de las copias de seguridad mediante el comando "restaurar y validar la base de datos" hará todo, excepto restaurar la base de datos. Este es el mejor método para determinar si la copia de seguridad es buena y utilizable antes de encontrarse en una situación en la que se vuelva crítica.
3. Actualización de bases de datos que no son de producción a partir de copias de seguridad de producción: es una buena práctica crear periódicamente bases de datos que no son de producción a partir de copias de seguridad de producción utilizando los comandos de la utilidad de copia de seguridad / restauración adecuados como práctica de restauración.
4. Realización de pruebas de restauración anuales / bianuales desde cinta como parte de la auditoría: el DBA tendrá que explicar el proceso a través de una narrativa, conservar registros y tomar capturas de pantalla para mostrar este tipo de pruebas de restauración.
5. Restauraciones reales: durante las restauraciones reales, el DBA debe realizar una copia de seguridad de la base de datos antes de realizar la restauración. Según el tipo de pérdida y las copias de seguridad disponibles, el DBA debe decidir si opta por una recuperación completa (en un momento determinado) o incompleta. La recuperación incompleta puede basarse en el tiempo, en la cancelación o en los cambios.
6. Estrategia para recuperarse de la corrupción de la base de datos: para las bases de datos Oracle, el DBA puede activar la verificación de bloques usando los parámetros apropiados para detectar la presencia de bloques corruptos en la base de datos. Esto tiene una ligera sobrecarga de rendimiento, pero permitirá la detección temprana de bloques corruptos causados ​​por problemas del sistema de entrada / salida (E / S), sistema de almacenamiento o disco subyacente. De forma predeterminada, RMAN también busca bloques corruptos durante la copia de seguridad. En versiones posteriores de Oracle, RMAN se puede utilizar para reparar bloques dañados en la base de datos.

SLA de respaldo y recuperación

El equipo de DBA debe redactar un SLA de respaldo y recuperación, que cubra los detalles de los procedimientos de respaldo e incluya un cronograma para la recuperación, y que la administración lo apruebe. El SLA no ayuda en el proceso de recuperación en sí, pero establece las expectativas de la comunidad de usuarios (y de la administración) para el proceso de recuperación, lo que puede proporcionar al equipo más tiempo para completar el proceso de restauración.

Plan de recuperación en un desastre

El DBA debe asegurarse de que las bases de datos se incluyan como un elemento clave en el DRP general de la empresa. Todas las partes interesadas deben comprender los elementos del plan de recuperación y en qué orden el equipo de TI restaurará las bases de datos. La empresa debe proporcionar su opinión en esta etapa para que las aplicaciones más críticas para la empresa estén disponibles lo antes posible.

Herramientas de respaldo y recuperación de bases de datos y sistemas operativos

Parece obvio, pero los administradores de bases de datos juegan el papel final y más importante en el proceso, ya que deben mantener actualizados sus conocimientos sobre las herramientas de copia de seguridad y recuperación para RDBMS. Durante el evento de restauración real, los administradores de bases de datos no tendrán tiempo para descubrir ningún avance en las herramientas de respaldo y recuperación.

Conclusión

La responsabilidad principal del equipo de administración de la base de datos es revisar todos los tipos de RDBMS en la empresa y desarrollar un plan de respaldo integral para llevar a cabo una administración de respaldo efectiva al monitorear de manera proactiva los respaldos, recibir alertas de respaldos fallidos y volver a ejecutarlos sin problemas, sin pérdida de tiempo. Es una buena práctica realizar una copia de seguridad de los datos en un disco físico y luego archivarlos en una cinta para fines de recuperación de desastres.

Una vez que se ha establecido un enfoque, es imperativo probar la restauración de datos periódicamente como parte de la estrategia de copia de seguridad y restauración, y revisar todas las opciones antes de ejecutar la restauración / recuperación real. Es importante confirmar que el equipo de DBA está al día con las últimas herramientas de respaldo y recuperación y asegurarse de que el equipo tenga un proceso claramente documentado con responsabilidades claras. Si los administradores de bases de datos mantienen copias de seguridad adecuadas, las supervisan de forma proactiva y pueden garantizar la recuperación de los datos hasta el punto requerido por la empresa, han realizado una gran parte del trabajo para el que fueron contratados.

Los auditores de TI pueden ayudar a los equipos de administración de datos a fortalecer sus controles y procesos de recuperación de datos validando las operaciones del DBA, incluida la prueba de la recuperación de datos. Este esfuerzo continuo, proactivo y cooperativo entre la auditoría interna y el equipo de DBA puede proporcionar seguridad a la gerencia de que, en caso de un desastre, los datos de la empresa se pueden recuperar.

Auditoría de la base de datos Oracle

 

La auditoría de la base de datos es la actividad de monitorear y registrar las acciones configuradas de la base de datos de los usuarios de la base de datos y los usuarios que no lo son, para garantizar la seguridad de las bases de datos.

Un administrador puede realizar auditorías en acciones individuales, como el tipo de declaración de lenguaje de consulta estructurado (SQL) ejecutada, o en combinaciones de datos que pueden incluir el nombre de usuario, la aplicación o la marca de tiempo, por ejemplo. Los auditores deben auditar tanto las actividades exitosas como las fallidas, e incluir o excluir a usuarios específicos de la auditoría:

La auditoría adecuada de una base de datos garantizará la protección de la base de datos, lo que significa que la instalación de la base de datos y sus funciones, la cuenta predeterminada, los parches, los servicios, la política de contraseñas, la política de bloqueo de cuentas y la política de auditoría han demostrado que la auditoría es un proceso continuo.

Los principales tipos de actividades de riesgo incluyen:

• Error: no mantener u operar la base de datos como se requiere conduce a la divulgación accidental de información, y los cambios no autorizados dan lugar a divulgaciones, inserciones, actualizaciones o eliminaciones accidentales y no autorizadas.
• Uso indebido: no mantener los derechos de acceso a la base de datos conduce al abuso del acceso privilegiado y la filtración de información.
• Acción maliciosa: si no se mantiene una configuración lógica y segura de la base de datos, se produce el robo de datos o un ataque de denegación de servicio (DoS).

Vulnerabilidades comunes encontradas en ataques a bases de datos

Muchos ataques comienzan con la ingeniería social:

• El phishing es un método de fraude por correo electrónico en el que el perpetrador envía correos electrónicos de apariencia legítima en un intento de recopilar información personal y financiera de los destinatarios. Por lo general, los mensajes parecen provenir de sitios web conocidos y confiables. Los sitios web que frecuentemente son falsificados por phishers incluyen PayPal, eBay, MSN, Yahoo y Best Buy, por ejemplo.

• La inyección SQL es una técnica que se utiliza para aprovechar las vulnerabilidades de entrada no validadas para pasar comandos SQL a través de una aplicación web para su ejecución por una base de datos back-end. Los atacantes aprovechan el hecho de que los programadores a menudo encadenan comandos SQL con parámetros proporcionados por el usuario y, por lo tanto, pueden incrustar comandos SQL dentro de estos parámetros. El resultado es que el atacante puede ejecutar consultas SQL arbitrarias y / o comandos en el servidor de base de datos back-end a través de la aplicación web.

• La exfiltración de datos es la copia, transferencia o recuperación no autorizada de datos de una computadora o servidor. La exfiltración de datos es una actividad maliciosa realizada a través de diversas técnicas, generalmente por ciberdelincuentes a través de Internet u otra red. La exfiltración de datos también se conoce como extrusión de datos, exportación de datos o robo de datos.
• El servidor de ensayo es un servidor que permite ensamblar, implementar y probar un software o un sitio web en una instancia de servidor, similar al servidor de producción. Normalmente, el software o un sitio web se implementa en el servidor de ensayo desde el servidor de desarrollo cuando se completa el desarrollo. Un servidor intermedio ayuda a identificar el comportamiento, la experiencia y el rendimiento del software o del sitio web, ya que será visible en el servidor de producción. Esto ayuda a los desarrolladores de software o al personal de control de calidad (QA) a identificar y resolver cualquier problema, error, problemas de rendimiento o usabilidad u otros problemas antes de que el software o el sitio web se implemente en el servidor de producción. El servidor intermedio puede ser un servidor de base de datos intermedio, un servidor de sitio web intermedio o un servidor de aplicaciones intermedias, por ejemplo.

El análisis de la configuración de la base de datos es fundamental para determinar las vulnerabilidades y garantizar la auditoría estándar. La auditoría de la base de datos incluye:

1. Encontrar privilegios y datos confidenciales
2. Impedir el acceso a los datos
3. Validar que los mecanismos de detección y alerta estén en su lugar
4. Hay varios mecanismos disponibles que deben estar en su lugar cuando se configuran las bases de datos, que incluyen:

• La redacción de datos proporciona una redacción selectiva y sobre la marcha de datos confidenciales en los resultados de las consultas SQL, antes de la visualización de la aplicación, para que los usuarios no autorizados no puedan ver los datos confidenciales. Permite la redacción coherente de las columnas de la base de datos en los módulos de la aplicación que acceden a la misma información de la base de datos. La redacción de datos minimiza los cambios en las aplicaciones porque no altera los datos reales en los búferes, cachés o almacenamiento de la base de datos internos, y conserva el tipo de datos y el formato originales cuando los datos transformados se devuelven a la aplicación. La redacción de datos no tiene ningún impacto en las actividades operativas de la base de datos, como copia de seguridad y restauración, actualización y parche, y en clústeres de alta disponibilidad.
• El enmascaramiento de datos confunde los datos confidenciales reemplazándolos con otros datos, generalmente caracteres que cumplirán los requisitos de un sistema diseñado para probar o seguir funcionando con los resultados enmascarados. El enmascaramiento garantiza que partes vitales de la información de identificación personal (PII), como los primeros cinco dígitos de un número de seguro social, se oculten o se desidentifiquen.
• El cifrado de datos implica convertir y transformar datos en texto cifrado codificado, a menudo ilegible, utilizando algoritmos y cálculos matemáticos no legibles. Restaurar el mensaje requiere un algoritmo de descifrado correspondiente y la clave de cifrado original.

Pasos de auditoría de la base de datos

Se deben seguir los siguientes pasos para la auditoría de la base de datos.

Paso 1: determinar si las cuentas predeterminadas se han modificado o desactivado

Las cuentas de Oracle privilegiadas predeterminadas siguen siendo el problema de mayor riesgo que se encuentra comúnmente. Es un problema fácil de solucionar y prevenir. Después de la instalación, Oracle tiene varias cuentas predeterminadas, cada una con un valor predeterminado predeterminado. Después de la instalación de la base de datos, el asistente de configuración de la base de datos de Oracle (DBCA) bloquea automáticamente y expira la mayoría de las cuentas de usuario predeterminadas de la base de datos. Además, DBCA cambia la cuenta SYSTEM al valor especificado durante la rutina de instalación.

Si una base de datos de Oracle se instala manualmente, el DBCA nunca se ejecuta y esas peligrosas cuentas con privilegios predeterminados nunca se bloquean ni caducan. Por defecto, su contraseña es la misma que su nombre de usuario. Estas serán las primeras credenciales que un hacker intentará utilizar para conectarse a la base de datos. Como práctica recomendada, cada una de estas cuentas debe configurarse con una contraseña única segura y, si no se requiere una cuenta, debe bloquearse y caducar.

Paso 2: auditar la solidez de Oracle Database SID

El ID del sistema de Oracle (SID) es un valor único que se requiere para que todos los clientes se conecten a la base de datos de Oracle. Debido a que debe ser única, no puede haber más de una base de datos con el mismo SID en el mismo servidor Oracle.

Si una conexión de cliente utiliza un SID incorrecto para conectarse a una base de datos de Oracle, recibirá el mensaje "ORA-12505: TNS: el oyente no conoce actualmente el SID proporcionado en el descriptor de conexión". Sin embargo, los SID pueden ser de fuerza bruta. Existen numerosas herramientas para forzar el SID de Oracle, incluidos los módulos Metasploit, las pruebas de aceptación operativa (OAT) y SIDGuess.

La clave para frustrar los ataques de fuerza bruta de SID es seleccionar un SID que sea fuerte. Al crear un SID de Oracle, la selección debe:

• No ser una palabra de diccionario
• Tener al menos 10 caracteres de longitud
• Incluya al menos un carácter especial

La incorporación de estos elementos asegura que el SID sea fuerte, es decir, difícil para un atacante utilizar la fuerza bruta.

¿Por qué es importante un SID fuerte cuando el SID se almacena como un valor de texto sin cifrar dentro del archivo de configuración del cliente de Oracle, TNSNAME.ora, en cada sistema que está configurado para conectarse a la base de datos? Es importante porque siempre que un atacante pueda comprometer al menos un sistema que está configurado para conectarse a la base de datos de Oracle, obtener el SID del archivo TNSNAMES.ORA es trivial. Sin embargo, es importante considerar los casos en los que el atacante es externo a la organización y ha comprometido un solo host que no tiene configurada una conexión de cliente de Oracle. Un SID sólido no impedirá por sí mismo que los piratas informáticos obtengan una conexión con la base de datos Oracle de una organización, pero es una buena práctica como parte de un enfoque de seguridad de defensa en profundidad.

Paso 3: auditar las actualizaciones de parches críticos de Oracle

Esta es una de esas recomendaciones de mejores prácticas de seguridad con las que la mayoría de las organizaciones luchan comúnmente. Dependiendo del esquema de la base de datos, las actualizaciones de parches críticos (CPU) de Oracle pueden tener un impacto significativo en la base de datos de Oracle, lo suficientemente significativo como para que la organización tenga que realizar pruebas de regresión exhaustivas para garantizar que la aplicación de las últimas CPU de Oracle no afecte la funcionalidad de la base de datos.

Oracle lanza CPU trimestralmente el martes más cercano al día 17 del mes. Oracle tiene una página de boletín especial que describe todas las actualizaciones y advertencias de parches críticos de Oracle más recientes.2 Afortunadamente, las CPU son de naturaleza acumulativa. Uno puede simplemente instalar la última CPU de Oracle para obtener todos los parches de seguridad desde el lanzamiento inicial del producto.

La clave para un proceso de parches de CPU eficaz es crear un proceso de prueba de regresión reglamentado que corresponda a los cuatro lanzamientos programados de Oracle cada año. Incluso en organizaciones con los procesos de prueba de regresión más estrictos, las CPU generalmente se pueden diseñar de tal manera que se puedan aplicar no más de tres meses después de la última versión de la CPU. Además, todos los administradores de bases de datos deben registrarse en el servicio de asesoramiento de alertas de seguridad por correo electrónico de Oracle3 para garantizar la notificación oportuna de los parches y alertas de seguridad de Oracle.

También existe un mecanismo que Oracle emplea si se descubre una vulnerabilidad crítica que justifica la publicación inmediata del parche. Oracle se refiere a los parches lanzados inmediatamente bajo este programa como "alertas de seguridad fuera de horario". Desde que comenzó el programa de CPU en 2005, solo ha habido unas pocas veces en las que Oracle lanzó parches bajo este proceso de emergencia. Las organizaciones deben desarrollar un método para aplicar estos parches lanzados de emergencia, pero dado su bajo volumen histórico, la atención debe centrarse en la aplicación rutinaria de parches de CPU cada trimestre.4

Paso 4: Auditar el rol PÚBLICO para la identificación de privilegios innecesarios

En Oracle, existen rutinas extendidas que permiten a los usuarios con privilegios mínimos ejecutar funciones que de otro modo no podrían ejecutar. Estas rutinas extendidas se denominan paquetes y son aproximadamente equivalentes a los procedimientos almacenados extendidos en Microsoft SQL Server. Un rol especial, llamado PUBLIC, actúa como un rol predeterminado asignado a cada usuario en la base de datos de Oracle. Cualquier usuario de la base de datos puede ejecutar los privilegios otorgados a PUBLIC. Esto se aprovecha comúnmente para la escalada de privilegios de la base de datos.

Estos paquetes y subtipos deben revocarse de PUBLIC y hacerse ejecutables para una aplicación solo cuando sea absolutamente necesario.

Paso 5: Verifique que la auditoría de la base de datos esté habilitada

Para identificar las actividades maliciosas o autorizadas en una base de datos, es importante verificar que las opciones de auditoría de la base de datos estén habilitadas. Para asegurarse de que la auditoría de la base de datos esté habilitada, es necesario realizar las siguientes actividades durante la auditoría de la base de datos:

• Auditoría de operaciones SYS: de forma predeterminada, las bases de datos de Oracle no auditan los comandos SQL ejecutados por el SYS privilegiado y los usuarios que se conectan con privilegios SYSDBA o SYSOPER. Si se piratea una base de datos, estos privilegios serán el primer objetivo del pirata informático. Afortunadamente, auditar los comandos SQL de estos usuarios privilegiados es muy simple: 

sqlplus> alter system set audit_sys_operations = true scope = spfile.

• Habilitar la auditoría de la base de datos: de nuevo, de forma predeterminada, la auditoría de Oracle de los comandos SQL no está habilitada. La auditoría debe estar activada para todos los comandos SQL. La auditoría de la base de datos se activa con el parámetro audit_trail: sqlplus> alter system set audit_trail = DB, EXTENDED scope = spfile. (Nota: El comando habilita la auditoría desde la base de datos, pero no la información de la bóveda de la base de datos, en la tabla SYS. AUD $.) En realidad, hay cuatro tipos de auditoría de bases de datos: OS, DB, EXTENDED y XML.
• Habilite la auditoría en objetos importantes de la base de datos: una vez que se ha habilitado la auditoría, se puede activar para los objetos en los que una pista de auditoría es importante.

Paso 6: Auditoría para garantizar que los activadores de la base de datos para la auditoría de esquemas y los eventos de inicio / cierre de sesión estén configurados

Para auditar eficazmente los cambios de esquema y los eventos de inicio y cierre de sesión, Oracle proporciona activadores de lenguaje de definición de datos (DDL) para auditar todos los cambios de esquema y puede informar el cambio exacto, cuándo se realizó y qué usuario.

• Activador de inicio de sesión: al usar un activador de inicio de sesión, se pueden enviar eventos de inicio y cierre de sesión en tiempo real a otro sistema. Piense en ello como un demonio syslog para los eventos de su base de datos. El siguiente ejemplo enviaría todos los eventos de inicio y cierre de sesión a un servidor web en tiempo real.

SQL> crear o reemplazar el disparador sec_logon después de iniciar sesión en la base de datos.

• Activador DDL: mediante los activadores DDL, un administrador de bases de datos de Oracle puede realizar un seguimiento automático de todos los cambios en la base de datos, incluidos los cambios en las tablas, los índices y las restricciones. Los datos de este activador son especialmente útiles para el control de cambios para Oracle DBA. El siguiente ejemplo envía eventos para GRANT, ALTER, CREATE, DROP.
• Disparador de error: los disparadores de error son mensajes de error de Oracle. Pueden ser útiles para detectar ataques de inyección SQL y otros métodos de ataque.

Paso 7: Auditoría para garantizar que se implemente una solución DAM

Si una organización puede permitirse el gasto adicional de un producto de software adicional, una solución de monitoreo de base de datos puede ser muy útil. Resuelve el problema de no poder monitorear la actividad del DBA a nivel organizacional. También proporciona información útil sobre consultas SQL peligrosas y modificaciones de roles que podrían indicar que un atacante ha comprometido una base de datos. La clave para todas las soluciones de monitoreo de actividad de bases de datos (DAM) es que operan dentro de la memoria del servidor Oracle y operan independientemente de las funciones nativas de auditoría y registro de la base de datos. Para cualquiera que esté familiarizado con los sistemas de detección de intrusiones en la red (IDS), los DAM tienen una función análoga: operan dentro de la capa de la base de datos en el servidor en lugar de en cualquiera de las capas de la red.

Paso 8: Auditoría para garantizar que la administración de contraseñas para todos los inicios de sesión de Oracle esté habilitada

Oracle proporciona una gestión de contraseñas bastante sólida para los inicios de sesión de Oracle. Desafortunadamente, ninguno de estos se aplica en el perfil de cuenta de Oracle predeterminado.

En Oracle, a los inicios de sesión se les asigna una política de cuenta a través de un perfil de Oracle. Cada inicio de sesión se puede aplicar a un solo perfil de Oracle. Si no se especifica ningún perfil de Oracle cuando se crea el inicio de sesión, se le asigna el perfil de Oracle predeterminado.

Paso 9: Verifique para asegurarse de que se realizan evaluaciones regulares de seguridad de la base de datos

Cada configuración segura que se ha discutido podría detectarse fácilmente con una herramienta de vulnerabilidad de base de datos automatizada. Las herramientas automatizadas de vulnerabilidad de bases de datos proporcionan una manera excelente de validar rápidamente las configuraciones seguras de Oracle de una organización. Obviamente, este tipo de herramientas solo son útiles si uno tiene privilegios. Están pensados ​​para que los administradores de bases de datos, auditores y profesionales de la seguridad realicen evaluaciones periódicas. Estas herramientas son propensas a generar falsos positivos y, desafortunadamente, falsos negativos, pero sus beneficios superan con creces el riesgo.

Paso 10: Determine que el tráfico de la base de datos está cifrado

Esta recomendación rara vez se implementa, excepto en las organizaciones más seguras. Oracle admite el cifrado a nivel de red mediante Secure Sockets Layer (SSL), utilizando certificados firmados X.509v3 y cifrado nativo sin certificados.

La conclusión con el cifrado a nivel de red no es solo que los datos confidenciales en tránsito están protegidos cuando se emplea el cifrado, sino también que el SID está protegido. Sin cifrado, el SID se puede enumerar fácilmente mediante ataques man-in-the-middle.

Paso 11: Audite las amenazas y contramedidas a la seguridad adecuadamente

Una organización debe crear una política de seguridad escrita para enumerar las amenazas de seguridad contra las que está tratando de protegerse y las medidas específicas que debe tomar la organización. Las amenazas a la seguridad se pueden abordar con diferentes tipos de medidas:

• Procedimientos, como exigir a los empleados del centro de datos que muestren credenciales de seguridad
• Físico, como asegurar computadoras en instalaciones de acceso restringido
• Técnico, como la implementación de requisitos de autenticación sólidos para sistemas comerciales críticos
• Relacionado con el personal, como la realización de verificaciones de antecedentes o la investigación de antecedentes de personal clave

Conclusión

Los datos son un recurso muy decisivo para cualquier negocio debido al blindaje; La auditoría periódica de la base de datos nunca debe dejarse al azar ni a soluciones de mosaico. Durante el período de auditoría, las partes interesadas deben identificar que un sistema está configurado según el estándar que garantiza la mitigación del riesgo de datos.

Se debe implementar una solución de auditoría completa e integral que pueda lograr fácilmente cada uno de los siguientes:

• Auditoría de acceso y autenticación
• Auditoría de usuarios y administradores
• Auditoría de actividades sospechosas
• Auditoría de vulnerabilidades y amenazas
• Auditoría de cambios

Sin una solución de auditoría que lo abarque todo, las organizaciones ponen en riesgo datos valiosos. Los datos corruptos, inexactos o comprometidos equivalen a pérdida de ingresos, tiempo perdido y relaciones comprometidas con clientes y empleados.

La auditoría es un proceso continuo y continuo sin importar qué sistema o proveedor esté en uso. Incluso los aspectos básicos deben revisarse periódicamente para evitar una falsa sensación de seguridad. La base de datos es un componente sensible en los negocios; por lo tanto, es importante asegurarse de que la base de datos esté configurada correctamente para garantizar la seguridad de los datos comerciales.

Oracle Database 12c R2 Nueva función: Cifrado de tablespaces en línea y automática

Transparent Data Encryption, en adelante TDE,  le permite cifrar datos confidenciales, como números de tarjetas de crédito o porcentaje de invalidez, dentro de la base de datos  Oracle 12C.

Oracle Database utiliza autenticación, autorización y mecanismos de auditoria para proteger los datos en la base de datos, pero no en los archivos de datos del sistema operativo donde se almacenan los datos. Para proteger estos archivos de datos, Oracle Database proporciona Transparent Data Encryption (TDE). TDE cifra los datos confidenciales almacenados en archivos de datos. Para evitar el descifrado no autorizado, TDE almacena las claves de cifrado en un módulo de seguridad externo a la base de datos, denominado almacén de claves.

El cifrado transparente de datos (TDE) permite cifrar datos confidenciales tales como números de tarjetas de crédito almacenados en tablas y espacios de tabla. Los datos cifrados se descifran de forma transparente para una aplicación o un usuario de base de datos que tenga acceso a los datos. TDE ayuda a proteger los datos almacenados en medios en caso de sustracción de los medios de almacenamiento o los archivos de datos. Oracle usa mecanismos de autenticación, autorización y auditoría para proteger los datos de la base de datos, pero no los archivos de datos del sistema operativo donde se almacenan datos. Para proteger estos archivos de datos, Oracle proporciona TDE. TDE cifra los datos confidenciales almacenados en los archivos de datos. Para evitar descifrados no autorizados, TDE almacena las claves de cifrado en un módulo de seguridad externo a la base de datos.

Estas son algunas de las ventajas del uso de TDE:

• Como administrador de seguridad tendrá la tranquilidad de que los datos confidenciales estén protegidos en caso de sustracción de los medios de almacenamiento o de los archivos de datos.
• La implementación de TDE ayuda a abordar los aspectos de cumplimiento reglamentario relacionados con la seguridad.
• No es necesario crear desencadenadores ni vistas para descifrar los datos para una aplicación o usuario autorizados. Los datos de las tablas se descifran de forma transparente para la aplicación y el usuario de la base de datos.
• No es necesario que las aplicaciones y usuarios de base de datos sepan que los datos a los que acceden están almacenados en modo cifrado. Los datos se descifran de forma transparente para las aplicaciones y usuarios de base de datos.
• No hace falta modificar las aplicaciones para controlar los datos cifrados. La base de datos administra el cifrado y descifrado de datos.
• Las operaciones de administración de claves están automatizadas. El usuario o la aplicación no necesitan administrar las claves de cifrado.

Oracle 12c

Para obtener más información sobre la configuración del cifrado de espacios de tablas de TDE, consulte la documentación de Oracle.

Configuración manual del TDE

El siguiente procedimiento muestra cómo configurar manualmente TDE.

• Cree el directorio keystore.

        mkdir $ORACLE_HOME/admin/$ORACLE_SID/wallet

• Modifique el archivo SQLNET.ORA si desea administrar la cartera de cifrado.

        La ubicación predeterminada de la cartera de cifrado es             $ORACLE_BASE/admin/<nombre_db_global>/wallet. Si desea permitir que Oracle administre una cartera en la ubicación predeterminada, no necesita establecer el parámetro ENCRYPTION_WALLET_LOCATION en el archivo sqlnet.ora.

Para Windows

ENCRYPTION_WALLET_LOCATION=

 (SOURCE=

  (METHOD=FILE)   (METHOD_DATA=

    (DIRECTORY=C:/oracle/admin/%ORACLE_SID%/wallet/)))

Para Linux

ENCRYPTION_WALLET_LOCATION=

 (SOURCE=

  (METHOD=FILE)   (METHOD_DATA=

    (DIRECTORY=/app/oracle/admin/$ORACLE_SID/wallet/)))

• Compruebe el parámetro de inicialización COMPATIBLE para el número correcto de versión. Debería ser 12.x.

Nota:

Utilice SQL*Plus. No utilice Oracle SQL Developer.

ORA> sqlplus /nolog SQL> connect /as sysdba Connected. SQL> select instance_name,status,database_status from v$instance;

INSTANCE_NAME    STATUS       DATABASE_STATUS

---------------- ------------ -----------------

mcs1              OPEN         ACTIVE

SQL> show parameter compatible NAME                                 TYPE        VALUE

------------------------------------ ----------- ------------------------------

compatible                           string      12.1.0.0.0

• Cree el keystore.

ADMINISTER KEY MANAGEMENT CREATE KEYSTORE 'C:\oracle\admin\mcs1\wallet' IDENTIFIED BY "mcs1$admin";

• Abra el keystore basado en contraseña.

ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY "mcs1$admin" CONTAINER=ALL;

• Comprueba el estado 

SELECT WRL_PARAMETER,STATUS,WALLET_TYPE FROM V$ENCRYPTION_WALLET;

• Haga una copia de seguridad de un software keystore basado en contraseña.

ADMINISTER KEY MANAGEMENT BACKUP KEYSTORE USING 'keystore_bkp' IDENTIFIED BY "mcs1$admin";

SELECT WRL_PARAMETER,STATUS,WALLET_TYPE FROM V$ENCRYPTION_WALLET;

• Cree la clave principal de cifrado.

Cree una clave principal para la CBD y todas las PDB.

ADMINISTER KEY MANAGEMENT SET KEY IDENTIFIED BY "mcs1$admin" WITH BACKUP USING 'masterkey_all_bkp' CONTAINER=ALL;

SELECT KEY_ID,KEYSTORE_TYPE,CREATOR,CREATOR_INSTANCE_NAME,CREATOR_PDBNAME FROM V$ENCRYPTION_KEYS;

Exporte la clave principal.

ADMINISTER KEY MANAGEMENT EXPORT ENCRYPTION KEYS WITH SECRET "mcs1.exp$admin" TO 'C:\oracle\admin\mcs1\wallet\masterkey_cdb_exp.bkp' IDENTIFIED BY "mcs1$admin";

• Si lo desea, cree la contraseña principal para el contenedor actual. Puede omitir este paso si ha completado el paso anterior.

Base de datos de contenedor (CDB):

ALTER SESSION SET CONTAINER = CDB$ROOT;

SHOW CON_NAME SELECT SYS_CONTEXT('USERENV', 'CON_NAME') FROM dual;

ADMINISTER KEY MANAGEMENT SET KEY IDENTIFIED BY "mcs1$admin" WITH BACKUP USING 'masterkey_cdb_backup' CONTAINER=CURRENT;

SELECT KEY_ID,KEYSTORE_TYPE,CREATOR,CREATOR_INSTANCE_NAME,CREATOR_PDBNAME FROM V$ENCRYPTION_KEYS;

--export master key

ADMINISTER KEY MANAGEMENT EXPORT ENCRYPTION KEYS WITH SECRET "mcs1.exp$admin" TO 'C:\oracle\admin\mcs1\wallet\masterkey_cdb_exp.bkp' IDENTIFIED BY "mcs1$admin";

Base de datos conectable (PDB): bathypdb

ALTER SESSION SET CONTAINER = bathypdb;

SHOW CON_NAME SELECT SYS_CONTEXT('USERENV', 'CON_NAME') FROM dual;

ADMINISTER KEY MANAGEMENT SET KEY IDENTIFIED BY "mcs1$admin" WITH BACKUP USING 'masterkey_bathypdb_backup' CONTAINER=CURRENT;

SELECT KEY_ID,KEYSTORE_TYPE,CREATOR,CREATOR_INSTANCE_NAME,CREATOR_PDBNAME FROM V$ENCRYPTION_KEYS;

--export master key

ADMINISTER KEY MANAGEMENT EXPORT ENCRYPTION KEYS WITH SECRET "mcs1.exp$admin" TO 'C:\oracle\admin\mcs1\wallet\masterkey_bathypdb_exp.bkp' IDENTIFIED BY "mcs1$admin";

• Comprobar estado

Select * from v$encryption_wallet;

select * from v$encryption_keys;

select wrl_parameter,status,wallet_type from v$encryption_wallet;

select key_id,keystore_type, creator,creator_instance_name, creator_pdbname from v$encryption_keys;

• Establezca el keystore local de inicio de sesión automático.

ADMINISTER KEY MANAGEMENT CREATE AUTO_LOGIN KEYSTORE FROM KEYSTORE 'C:\oracle\admin\mcs1\wallet' IDENTIFIED BY "mcs1$admin";

SELECT WRL_PARAMETER,STATUS,WALLET_TYPE FROM V$ENCRYPTION_WALLET;

--the cwallet.sso file appears in the keystore location. The ewallet.p12 file is the password-based wallet. --Note:

--Do not remove the PKCS#12 wallet (ewallet.p12 file) after you create the auto login keystore (.sso file). 

--You must have the PKCS#12 wallet to regenerate or rekey the TDE master encryption key in the future. 

--By default, this file is located in the $ORACLE_HOME/admin/ORACLE_SID/wallet directory.

• Abra el keystore de inicio de sesión automático.

ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN CONTAINER=ALL;

-- check the status

SELECT WRL_PARAMETER,STATUS,WALLET_TYPE FROM V$ENCRYPTION_WALLET;

Sugerencia:

Para cerrarlo, puede usar la siguiente instrucción.

ADMINISTER KEY MANAGEMENT SET KEYSTORE CLOSE IDENTIFIED BY "mcs1$admin" CONTAINER=ALL;

• Se recomienda que verifique el estado de la configuración TDE utilizando las instrucciones SQL siguientes.

Select * from v$encryption_wallet;

select * from v$encryption_keys;

select wrl_parameter,status,wallet_type from v$encryption_wallet;

select key_id,keystore_type from v$encryption_keys;

select key_id from v$encryption_keys;

select keystore_type from v$encryption_keys;

select wrl_parameter from v$encryption_wallet;

select status from v$encryption_wallet;

select * from v$encrypted_tablespaces;

select tablespace_name, encrypted from dba_tablespaces;

select * from dba_encrypted_columns;