3 Recuperación de datos

La recuperación ante desastres abarca el proceso, las políticas y los procedimientos relacionados con la preparación para la recuperación o la continuación de la información crítica comercial de una organización tras un desastre natural o provocado por una persona. Esto incluye:

  • Objetivo de punto de recuperación (RPO): el punto en el tiempo para recuperar los datos, según lo definido por un plan de continuidad del negocio. Por lo general, es una definición de lo que la empresa determina que es una "pérdida aceptable" en una situación de desastre. Puede estar definido en horas, días o incluso semanas.

  • Objetivo de tiempo de recuperación (RTO): el tiempo durante el cual debe "restaurarse" un proceso comercial tras un desastre (o interrupción) a fin de evitar consecuencias inaceptables asociadas con una interrupción de la continuidad del negocio. Este tiempo puede ser de algunos minutos al usar una red de servicio combinada. Consulte la figura Número 3-2.

OKM puede abarcar varios sitios separados geográficamente. Esto reduce en gran medida el riesgo de que un desastre destruya todo el cluster. La agrupación en clusters de los dispositivos de gestión de claves permite la replicación de entradas de la base de datos y el equilibro de la carga de trabajo. Aunque es poco probable que deba volver a crearse todo un cluster, la mayoría de los datos puedan recuperarse recreando el entorno de OKM desde una copia de seguridad de base de datos reciente.

Al diseñar una estrategia de cifrado/archivo, un elemento de diseño muy importante es que los datos críticos generados en cualquier sitio se replican y almacenan en un sitio de recuperación.

Si se pierde un sitio, esta copia de seguridad de datos puede transferirse a otro sitio operativo. Las unidades de datos y las claves asociadas con los volúmenes de cinta serán conocidas para los dispositivos de gestión de claves en el sitio hermano, y estarán disponibles los datos cifrados requeridos para continuar las operaciones comerciales.

La parte dañada del cluster se puede restaurar fácilmente en la misma ubicación o en una ubicación diferente una vez que se reanudan las operaciones del sitio.

Muchas empresas contratan los servicios de un sitio de terceros para la recuperación ante desastres (DR) que les permita reiniciar las operaciones comerciales lo antes posible. Las pruebas DR periódicas y no anunciadas demuestran si la empresa está preparada para recuperarse de un desastre natural o provocado por una persona. Existen varios escenarios posibles; algunos se describen aquí.

Recursos compartidos Proporcionan elementos rentables para la recuperación ante desastres
Replicación Restauración mediante la replicación desde dispositivos de gestión de claves intactos
Escenario 1 Preposicionamiento de dispositivos de gestión de claves
Escenario 2 Uso compartido de dispositivos de gestión de claves
Escenario 3 Transferencias de claves
Escenario 4 Restauración desde copia de seguridad
Metodología de copia de seguridad Algunas directrices que pueden ser útiles

Consideraciones de copias de seguridad e intercambio de claves

El intercambio de claves (importación/exportación) y las copias de seguridad de OKM implican el uso intensivo de la base de datos y reducen el tiempo de respuesta en el dispositivo de gestión de claves durante la operación de copia de seguridad o transferencia de claves.

Si es posible, reduzca las cargas de trabajo de las unidades de cinta durante el intervalo de transferencia y copia de seguridad de OKM.

Si no es posible, considere las siguientes opciones:

  • Las transferencias de claves y las copias de seguridad de OKM pueden realizarse en cualquier dispositivo de gestión de claves, pero es recomendable utilizar siempre el mismo dispositivo de gestión de claves. Es muy probable que los trabajos de cron que invocan la utilidad de copia de seguridad de OKM se configuren de esta manera.

  • Si el cluster es suficientemente grande, puede haber un dispositivo de gestión de claves dedicado como dispositivo de gestión de claves administrativo.

    • Este dispositivo de gestión de claves no debe tener una conexión de red de servicio, de modo que no tenga que soportar la carga de solicitudes de claves de unidades de cinta en cualquier momento, especialmente durante los intervalos de transferencia de claves o copia de seguridad.

    • Este dispositivo de gestión de claves también puede utilizarse para sesiones de GUI de OKM; de esta manera, se reduce la carga de manejo de solicitudes de gestión en otros dispositivos de gestión de claves.

  • Cuanto más rápida es la conectividad de red de gestión del dispositivo de gestión de claves de copia de seguridad y transferencia de claves, mejor podrá administrar la carga adicional durante los intervalos de transferencia de claves y copia de seguridad.

    Esto se aplica a todos los dispositivos de gestión de claves, especialmente al dispositivo de gestión de claves que realiza copias de seguridad, ya que se atrasará con las solicitudes de replicación durante el intervalo de copia de seguridad. Una conexión de red rápida ayudará a minimizar los retrasos de replicación, como un intervalo.

  • Coloque el dispositivo de gestión de claves de copia de seguridad y transferencia de claves en un sitio que no sea utilizado por las unidades de cinta. Las unidades de cinta prefieren otros dispositivos de gestión de claves dentro del sitio al que fueron asignadas y evitan usar el dispositivo de gestión de claves de copia de seguridad y transferencia de claves.

  • Agregue más dispositivos de gestión de claves a los sitios que contienen unidades de cinta, de modo que el equilibrio de carga de las solicitudes de claves ocurra en más dispositivos de gestión de claves. Esto reduce el número de solicitudes de claves que debe responder el dispositivo de gestión de claves de copia de seguridad y transferencia de claves.

Determinación del tamaño de una agrupación de claves

Los administradores de OKM deben conocer el peor número de claves que esperan crear por unidad de tiempo y la duración de los intervalos de trasferencia de claves o los intervalos de copia de seguridad de OKM.

En esta discusión, asumiremos que se calculó una frecuencia de consumo de claves por hora.

Nota:

Los dispositivos de gestión de claves generan claves previamente, de modo que una solicitud de creación de claves emitida por un agente no genera la creación de una clave en el dispositivo de gestión de claves hasta que el mantenedor de agrupaciones de claves se ejecuta en el servidor. Cuando el servidor está ocupado, pueden retrasarse las operaciones del mantenedor de agrupaciones de claves.

El tamaño total de la agrupación de claves del cluster debe ser suficientemente grande de modo que los dispositivos de gestión de claves puedan entregar claves pregeneradas desde la agrupación de claves durante los intervalos de copia de seguridad.

Cuando el tamaño de la agrupación de claves es demasiado pequeño, es posible que se agoten las claves pregeneradas en los dispositivos de gestión de claves y que estos últimos devuelvan errores que indiquen que no hay claves listas. Cuando esto sucede, las unidades de cinta realizan un failover a otros dispositivos de gestión de claves y se interrumpen aún más los desafíos de rendimiento del intervalo de copia de seguridad/transferencia de claves.

El tamaño predeterminado de la agrupación de claves de 1000 claves debería ser suficiente para la mayoría de los clientes, a menos que la peor frecuencia de creación de claves para el intervalo de copia de seguridad supere este número.

El intervalo de copia de seguridad de OKM debe revisarse periódicamente, ya que aumentará gradualmente a medida que crece la base de datos. Posiblemente sea necesario realizar ajustes al tamaño de la agrupación de claves cuando el intervalo de copia de seguridad supera un umbral. El tamaño de la agrupación de claves también debe ajustarse si la frecuencia de consumo de claves aumenta debido a cambios en la carga de trabajo general de la cinta.

Recursos compartidos

Los recursos compartidos proporcionan elementos rentables para la recuperación ante desastres.

Las empresas que se especializan en la gestión de registros, la destrucción de datos y la continuidad y recuperación de datos, adquieren equipos que varios clientes pueden utilizar por diversas razones, como la copia de seguridad y el archivo.

Para la recuperación ante desastres, el cliente puede usar unidades de cinta, bibliotecas y otros recursos de un sitio de recursos compartidos durante períodos cortos, ya sea para realizar una prueba de recuperación ante desastres o una recuperación real tras un desastre.

Existen dos enfoques para la recuperación ante desastres y la gestión de claves.

  • El cliente puede colocar los dispositivos de gestión de claves en el sitio DR y configurarlos en el cluster de producción mediante una conexión WAN. Estos dispositivos de gestión de claves están dedicados al cliente específico y permiten que las claves de los clientes siempre se encuentren en el sitio DR y estén listas para usar.

    Con este enfoque, puede iniciarse una recuperación una vez que el cliente inscribe las unidades de cinta en los dispositivos de gestión de claves en el sitio de recursos compartidos y se une al cluster de OKM.

    Esto puede realizarse mediante la conexión de la GUI de OKM a los dispositivos de gestión de claves en el sitio DR. En un escenario real de recuperación ante desastres, estos pueden ser los únicos dispositivos de gestión de claves restantes del cluster del cliente.

    La inscripción de unidades puede completarse en un transcurso de minutos. Una vez que se completa la inscripción y que se configuraron las unidades, puede comenzar la producción de las cintas.

  • Otro método es restaurar las copias de seguridad de OKM de producción del cliente en los dispositivos de gestión de claves proporcionados por el sitio de recursos compartidos. Esto evita la necesidad de contar con un enlace de red de área amplia (WAN) y dispositivos de gestión de claves dedicados en el sitio, pero requiere tiempo adicional para restaurar la base de datos.

    Con este enfoque, la operación de restauración requiere archivos de copia de seguridad de OKM normales y una copia de seguridad básica. Este enfoque de restauración requiere un quórum de los miembros de credenciales de división de claves para la copia de seguridad básica.

    Las operaciones de restauración demoran alrededor de 20 minutos cada 100.000 claves.

    Después de que se completa la restauración, se deben inscribir y configurar las unidades.

    Se necesitan tres archivos para un sitio DR:

    • Archivo de copia de seguridad básica

    • Archivo de copia de seguridad .xml

    • Archivo de copia de seguridad .dat

    Estos archivos son creados por un responsable de copias de seguridad.

Replicación desde otro sitio

En la figura Número 3-1 y la figura Número 3-2, se muestran ejemplos de dos sitios separados geográficamente, un cluster de OKM con cuatro dispositivos de gestión de claves, dos en cada sitio.

Durante la instalación inicial, después de configurar el primer dispositivo de gestión de claves, los dispositivos de gestión de claves adicionales (nuevos o de reemplazo) se autorreplican desde los otros dispositivos de gestión de claves del cluster.

La recuperación de un único dispositivo de gestión de claves se puede realizar sin que se vea afectado el resto del cluster, siempre que al menos un dispositivo de gestión de claves siga funcionando.

La figura Número 3-1 es un ejemplo de objetivo de punto de recuperación. En este ejemplo, un punto en el tiempo para recuperar la continuidad del negocio en un sitio completo puede llevar meses.

  • Si el sitio 1 se destruyera y el sitio 2 quedara intacto:

    El cliente debe reemplazar todo el equipo destruido para la infraestructura, incluidos los dispositivos de gestión de claves para el cluster y las unidades de cinta.

    Una vez que el sitio se restaura y está en funcionamiento:

    • Instale y cree los nuevos dispositivos de gestión de claves (requiere un responsable de la seguridad y quórum).

    • Una los nuevos dispositivos de gestión de claves al cluster existente, de a uno por vez.

    • Instale y active las nuevas unidades de cinta.

    • Inscriba las nuevas unidades de cinta, ahora denominadas agentes.

    El sitio 1 se autorreplica desde los dispositivos de gestión de claves supervivientes en el sitio 2 intacto.

La figura Número 3-2 es un ejemplo de objetivo de tiempo de recuperación. En este ejemplo, el tiempo para recuperar la continuidad del negocio es de algunos minutos.

  • Si se destruyeran los dispositivos de gestión de claves del sitio 1 y la infraestructura del sitio 2 quedara intacta:

    Una red de servicio de área amplia que conecta las unidades de cinta entre los dos sitios permite que los dispositivos de gestión de claves intactos del sitio 2 sigan realizando operaciones de cinta entre ambos sitios.

    Una vez que los dispositivos de gestión de claves se reemplazan en el sitio 1, se autorreplicarán desde los dispositivos de gestión de claves supervivientes en el sitio 2 intacto (similar a la descripción anterior).

    Durante el programa QuickStart el cliente selecciona:

    (2) Join Existing Cluster (Unirse al cluster existente)

    para cada uno de los dispositivos de gestión de claves nuevos.

Figura 3-1 Replicación desde otro sitio: objetivo de punto de recuperación

El texto alrededor describe Figura 3-1 .

Figura 3-2 Continuación de red de servicio: objetivo de tiempo de recuperación

El texto alrededor describe Figura 3-2 .

Escenario 1: dispositivos de gestión de claves preposicionados

En este escenario, el cliente tiene un entorno grande con varios sitios. Cada sitio usa:

  • Un par de dispositivos de gestión de claves y la infraestructura para admitir el cifrado automatizado de cintas

  • Un único cluster donde todos los dispositivos de gestión de claves comparten las claves

Junto con estos varios sitios, este cliente también mantiene y utiliza equipos en un sitio de recuperación ante desastres (DR) que es parte del cluster de OKM del cliente.

Consulte la figura Número 3-3 para conocer este escenario.

Este cliente usa un esquema de copia de seguridad simple que consta de lo siguiente:

  • Copias de seguridad incrementales diarias

  • Copias de seguridad diferenciales semanales

  • Copias de seguridad completas mensuales

Las copias de seguridad mensuales se duplican en el sitio DR y se envían a una instalación de almacenamiento fuera del sitio durante 90 días. Después del período de retención de 90 días, las cintas se reciclan.

Dado que el cliente es propietario del equipo en el sitio DR, este sitio es simplemente una extensión del cliente que se ocupa estrictamente de los procesos de copia de seguridad y archivo.

Figura 3-3 Equipo preposicionado

El texto alrededor describe Figura 3-3 .

Escenario 2: dispositivos de gestión de claves compartidos

Este escenario es muy similar al Escenario 1: dispositivos de gestión de claves preposicionados; sin embargo, el sitio de recuperación ante desastres es propietario del equipo y comparte los recursos con varios otros clientes.

Consulte la figura Número 3-4 para conocer este escenario.

Dado que el sitio de recuperación ante desastres admite otros clientes DR, no puede asumirse que el sitio siempre está configurado para procesos con capacidad de cifrado.

Nota:

Los dispositivos de gestión de claves deben restablecerse a los valores predeterminados de fábrica antes de crear una configuración para un cliente diferente.

En el sitio DR:

  • El cliente selecciona el equipo adecuado desde el inventario del sitio DR.

  • El sitio DR configura el equipo y la infraestructura en consecuencia.

Importante:

El cliente debe proporcionar al sitio DR los tres archivos de copia de seguridad de OKM:
  • Archivo de copia de seguridad básica

  • Archivo de copia de seguridad .xml

  • Archivo de copia de seguridad .dat

En los sitios DR, el cliente:

  • Configura un dispositivo de gestión de claves inicial con el asistente de QuickStart

  • Restaura el dispositivo de gestión de claves desde los archivos de copia de seguridad de OKM

  • Activate o conmuta las unidades para que tengan capacidad de cifrado (representantes DR)

  • Inscribe las unidades de cinta en el cluster del dispositivo de gestión de claves del sitio DR.

Una vez que se completa el trabajo, el sitio de recuperación ante desastres debe:

  • Desactivar el cifrado desde los agentes

  • Eliminar las unidades de cinta desde el cluster o restablecer la frase de contraseña de las unidades

  • Restablecer los dispositivos de gestión de claves a los valores predeterminados de fábrica

Desconectar la infraestructura y la red

Figura 3-4 Dispositivos de gestión de claves compartidos

El texto alrededor describe Figura 3-4 .

Escenario 3: socios de transferencia de claves

La transferencia de claves también se denomina intercambio de claves. Las transferencias permiten que las claves y las unidades de datos asociadas se intercambien de manera segura entre los socios o los clusters independientes y son necesarias para intercambiar medios cifrados.

Nota:

Un sitio DR también puede configurarse como socio de transferencia de claves.

Este proceso requiere que cada parte de la transferencia establezca un par de claves públicas/privadas. Una vez que se completa la configuración inicial:

  • La parte emisora usa Export Keys (Exportar claves) para generar un archivo de transferencia.

  • La parte receptora utiliza Import Keys (Importar claves) para recibir las claves y los datos asociados

No se recomienda usar socios de transferencia de claves para la recuperación ante desastres. Sin embargo, cuando los sitios DR crean claves durante el proceso de copia de seguridad, una transferencia de claves puede agregar de manera incremental las claves de los sitios DR a la base de datos ya existente.

El proceso de transferencia de claves requiere que cada usuario configure un socio de transferencia para cada cluster de OKM.

  • Un socio de transferencia exporta claves desde su cluster de OKM.

  • El otro socio de transferencia importa claves en su cluster de OKM.

Al configurar socios de transferencia de claves, los administradores deben llevar a cabo las tareas en un orden específico que requiere varios roles, entre los que se incluyen:

  • Rol de responsable de la seguridad

  • Rol de responsable del cumplimiento

  • Rol de operador

Para configurar socios de transferencia de claves, consulte la Guía de administración de OKM y:

  1. Configure un socio de transferencia de claves para ambos clusters de OKM que participan en el intercambio de claves.

  2. Establezca un intercambio de claves públicas/privadas para comunicarse con los clusters de OKM. Por ejemplo, si se envía un correo electrónico, dos sitios pueden usar un método de comunicación establecido para proteger el intercambio de correo electrónico y autenticar el origen y el destinatario.

    Hay mecanismos implementados, como las huellas digitales, para prevenir la modificación de esta información durante el tránsito.

  3. Reúna quórum para aprobar la creación del nuevo socio de transferencia.

  4. Asigne el socio de transferencia a uno o varios grupos de claves.

  5. Exporte claves desde un cluster de OKM e impórtelas en otro. Esto se puede realizar varias veces.

Figura 3-5 Socios de transferencia de claves

El texto alrededor describe Figura 3-5 .

Escenario 4: restauración desde copia de seguridad

Un proceso de copia de seguridad es la realización de copias de datos de modo que puedan usarse para restaurar el estado original tras un desastre u otro evento en el que se hayan perdido datos.

Estas copias, generalmente, se denominan "copias de seguridad" y sirven para:

  • Restaurar un sitio tras un desastre (recuperación ante desastres)

  • Restaurar archivos suprimidos o dañados accidentalmente

Es importante reconocer y usar un esquema de copia de seguridad que funcione para cada departamento, grupo, organización o negocio. También es importante tener la seguridad de que el proceso de copia de seguridad funciona de la manera esperada.

Para OKM, las siguientes opciones están disponibles para ayudar a crear y, si es necesario, restaurar OKM.

  • Copia de seguridad

    Un archivo creado durante el proceso de copia de seguridad que contiene toda la información necesaria para restaurar un dispositivo de gestión de claves. Este archivo está cifrado con una "clave" generada específicamente para la copia de seguridad. Esta clave está incluida en el archivo de clave de copia de seguridad correspondiente.

  • Archivo de clave de copia de seguridad

    Un archivo generado durante el proceso de copia de seguridad que contiene una clave utilizada para cifrar el archivo de copia de seguridad. Este archivo está cifrado con la "clave maestra" del sistema. La clave maestra se extrae del archivo de copia de seguridad básica utilizando un quórum para las credenciales de división de claves.

  • Operador de copias de seguridad

    Un rol de usuario que es responsable de proteger y almacenar datos y claves.

Nota:

Consulte "Metodología de copia de seguridad" para obtener más información.

Ubicaciones de las copias de seguridad:

Tenga en cuenta que la ubicación de las copias de seguridad de OKM debe estar en un sitio seguro que se encuentre a una distancia razonable, de modo que el incendio de un edificio no destruya todos los datos. La distancia también debe tener en cuenta desastres naturales.

Por ejemplo, si todos los sitios de copias de seguridad están ubicados en edificios en Nueva Orleans, la destrucción de los datos es inevitable en un desastre similar a Katrina.

Restauración:

Únicamente se requiere una restauración desde copia de seguridad si fallaron todos los dispositivos de gestión de claves del cluster, por ejemplo, en el caso de que un sitio sea destruido por un incendio.

Nota:

La restauración de OKM desde una copia de seguridad requiere un quórum. El operador de copias de seguridad crea y mantiene copias de seguridad, y el responsable de la seguridad las restaura. Asegúrese de que esté disponible el número requerido de usuarios del quórum.

Para restaurar el sistema desde una copia de seguridad, consulte la Guía de administración de OKM y:

  1. Seleccione Secure Information Management (Gestión segura de la información) > Backup List (Lista de copias de seguridad). Esto le permite visualizar el historial y los detalles de los archivos de copia de seguridad.

  2. En la pantalla Backup List (Lista de copias de seguridad), resalte la copia de seguridad que desea restaurar y haga doble clic en la entrada de la copia de seguridad. Se muestra el cuadro de diálogo Backup Details (Detalles de la copia de seguridad).

  3. Haga clic en el botón Restore (Restaurar). Se muestra el cuadro de diálogo Restore Backup (Restaurar copia de seguridad).

    Figura 3-6 Restauración desde copia de seguridad

    El texto alrededor describe Figura 3-6 .
  4. Haga clic en el botón Start (Iniciar).

    Cuando se completa la carga, aparece el cuadro de diálogo Key Split Quorum Authentication (Autenticación de quórum de división de claves).

    Los miembros del quórum de copia de seguridad básica deben escribir sus nombres de usuario y frases de contraseña para autenticar la operación.

  5. Haga clic en el botón OK (Aceptar). Se indica el progreso de la restauración.

Metodología de copia de seguridad

Recuerde que cada cliente y cada situación son diferentes. A continuación, presentamos algunas directrices de utilidad:

Frecuencia de copia de seguridad. Hay dos tipos de copias de seguridad que se tratan de forma distinta:

  • Copia de seguridad básica, que debe protegerse mediante tácticas especiales.

  • Copia de seguridad de base de datos de los datos claves, que debe estar protegida.

Copia de seguridad básica

La copia de seguridad básica contiene un componente principal para OKM, el material de claves root. Se trata de material de claves generado cuando se inicializa un cluster. El material de claves root protege la clave maestra, una clave simétrica que protege las claves de unidades de datos almacenadas en el dispositivo de gestión de claves.

La copia de seguridad básica está protegida con un esquema de división de claves que requiere un quórum de usuarios definidos en las credenciales de división de claves. Este quórum de usuarios debe proporcionar los nombres de usuario y las frases de contraseña para desencapsular el material de claves root.

Metodología:

La copia de seguridad básica debe preceder a la primera copia de seguridad de base de datos y, luego, esta copia de seguridad básica únicamente debe repetirse cuando cambian los miembros de la división de claves (quórum). Este es un elemento de seguridad que se trata y se protege de forma especial. Se requiere para restaurar cualquier copia de seguridad de OKM.

Se recomienda conservar dos copias de esta copia de seguridad en dos ubicaciones protegidas en el medio portátil que elijan los clientes, como CD, memorias extraíbles USB o discos duros externos.

Cuando se crea y se protege una nueva copia de seguridad básica, se deben destruir las anteriores.

Copia de seguridad de base de datos

Nota:

Los operadores de copias de seguridad son responsables de proteger y almacenar los datos y las claves.

Una copia de seguridad de base de datos está compuesta por dos archivos: un archivo de copia de seguridad y un archivo de clave de copia de seguridad. Estos nombres de archivo se generan automáticamente; sin embargo, puede editarlos.

Cuando se crea, cada dispositivo de gestión de claves crea 1000 claves (valor predeterminado). Esto puede variar durante la instalación. Cada dispositivo de gestión de claves controla y asigna sus propias claves. Después de emitir 10 claves, el dispositivo de gestión de claves crea 10 claves para reponerlas.

A continuación, las claves se replican a todos los dispositivos de gestión de claves en OKM.

Las copias de seguridad de base de datos se cifran con AES-256; por lo tanto, son seguras.

Metodología:

Ejemplo uno. Copia de seguridad de base de datos: varios sitios en el cluster de OKM

  • Las claves protegen las claves contra daño.

  • Las claves se protegen mediante replicación.

El cliente nunca necesitará una recuperación total ante desastres del cluster debido a los centros de datos geográficamente distribuidos. La creación de copias de seguridad para este cliente no es tan importante como en el Ejemplo dos; sin embargo, cree una copia de seguridad básica y, luego, copias de seguridad de base de datos antes de que se envíen a las unidades de datos todas las claves generadas desde un único dispositivo de gestión de claves.

Ejemplo dos. Copia de seguridad de base de datos: un sitio físico en un cluster de OKM

  • Un desastre localizado puede destruir todo el OKM.

  • Las copias de seguridad de base de datos constituyen la única protección para las claves.

Mantenga fuera del sitio copias de seguridad básicas y de base de datos. Para una protección mínima:

Tabla 3-1 Cálculos de copia de seguridad de base de datos

1.

Calcule cuántas cintas se cifrarán inicialmente usando una clave por cinta.

 

2.

¿Cuántas horas, días o semanas llevará enviar las claves creadas inicialmente? Nota: Cuando se crea, cada dispositivo de gestión de claves crea 1000 claves (valor predeterminado).

 

3.

Calcule cuántas cintas montadas tendrán un período de cifrado de claves caducado.

 

4.

Sume estos dos cálculos.

 

5.

Asuma que solamente un dispositivo de gestión de claves envía todas las claves y realice una copia de seguridad de la base de datos antes de que se envíen todas las claves iniciales. Esto otorga al cálculo un factor de seguridad del 50%.

 

6.

Repita este cálculo con la nueva cinta y vuelva a usar la caducidad del período de cifrado.

 

Cuestiones que se deben tener en cuenta:

  • Archive copias o no archive copias.

  • Recuerde que las copias de seguridad antiguas contienen usuarios, frases de contraseña y otros datos confidenciales que posiblemente no desee conservar.

  • Realice y archive dos copias de seguridad de base de datos actuales en caso de un error de medios de copia de seguridad.

  • Dado que calculó un factor de seguridad del 50% asumiendo que únicamente un dispositivo de gestión de claves envía claves, cualquiera de la copias de seguridad contiene todas las claves activas.

  • Nunca archive copias antiguas de la base de datos.

  • Si periódicamente suprime claves por cuestiones de cumplimiento o relacionadas con las políticas, las claves suprimidas se pueden recuperar a partir de copias de seguridad anteriores.

  • Conserve copias redundantes. No cree dos copias de seguridad.

  • Realice dos copias idénticas para ofrecer protección contra errores de medios de copia de seguridad. Este esquema también garantiza que no se haya enviado otra clave durante la copia de seguridad, lo cual crea dos copias diferentes.