Comprender la alta disponibilidad y la recuperación tras desastre para Secrets Manager
La alta disponibilidadCapacidad de un servicio o carga de trabajo para soportar fallos y seguir proporcionando capacidad de procesamiento de acuerdo con algún nivel de servicio predefinido. (HA) es la capacidad de un servicio de permanecer operativo y accesible ante fallos inesperados. La recuperación de desastresCapacidad de un servicio o carga de trabajo para recuperarse de incidentes graves poco frecuentes y fallos a gran escala, como la interrupción del servicio. Esto incluye un desastre físico que afecte a toda una región, la corrupción de una base de datos o la pérdida de un servicio que contribuya a una carga de trabajo. El impacto supera la capacidad del diseño de alta disponibilidad para gestionarlo. es el proceso de recuperación de la instancia de servicio a un estado de funcionamiento.
Secrets Manager es un servicio regional que cumple los Objetivos de Nivel de Servicio(SLO ) definidos con el plan Estándar. Para más información sobre las regiones de " IBM Cloud " disponibles y los centros de datos de " Secrets Manager" , consulte " Disponibilidad de servicios e infraestructuras por ubicación.
Arquitectura de alta disponibilidad
Una instancia de servicio Secrets Manager se aprovisiona en tres zonas de una región multizona sin un único punto de fallo. Las solicitudes de API se enrutan a través de un equilibrador de carga global a tres nodos de instancia de HA, cada uno en una zona de disponibilidad diferente.
Si una zona de disponibilidad experimenta fallos, el servicio continuará funcionando y las solicitudes de API se enrutarán a través de un equilibrador de carga global a los nodos de instancia de HA supervivientes. Puede haber un corto periodo de tiempo (segundos) entre la interrupción y que el balanceador de carga global reconozca el fallo, durante el cual, las peticiones pueden ser enviadas a la instancia que ha fallado. Las cargas de trabajo que acceden mediante programación a la instancia de servicio deben seguir la lógica de reintento de disponibilidad del cliente para mantener la disponibilidad. No hay degradación perceptible del servicio durante un fallo zonal.
las instancias IBM Cloud® Secrets Manager están altamente disponibles sin necesidad de configuración.
Arquitectura de recuperación en caso de catástrofe
Para recuperarse de una interrupción de una instancia de servicio, debe crearse una instancia de servicio de recuperación en una región de recuperación. En general, la instancia de servicio de recuperación debe configurarse con los mismos datos que la instancia de servicio de origen, pero hay excepciones a esta guía.
Algunos secretos deberán ajustarse para la región de recuperación, por ejemplo, las cadenas de conexión o las claves API pueden hacer referencia a instancias de servicio específicas de la región. Estos valores serán diferentes en la instancia del servicio de recuperación.
La instancia del servicio Secret Manager puede tener dependencias creadas por el cliente en estos servicios opcionales, asegúrese de que existen en la región recuperada.
Esta instancia debe crearse antes de que se produzca (antes de cualquier desastre potencial) y mantenerse sincronizada con la instancia de origen.
Funciones de recuperación en caso de catástrofe
Secrets Manager admite las siguientes funciones de recuperación ante desastres:
Planificar la recuperación en una región de recuperación. La instancia de recuperación debe alinearse con la carga de trabajo " enfoques de recuperación en caso de catástrofe dentro del " IBM Cloud. La instancia de recuperación debe realizar un seguimiento de los cambios de datos a la instancia de servicio primaria para datos que incluyan grupos, secretos, versiones secretas, certificados, notificaciones de eventos.
Si la catástrofe no afecta a la instancia de servicio de producción, por ejemplo la corrupción de datos, puede ser posible que un cliente repare los datos en la instancia de servicio in situ.
El servicio admite las siguientes opciones de recuperación en caso de catástrofe:
| Característica | Descripción | Consideración |
|---|---|---|
| Rotation | Restaurar la versión secreta anterior | La instancia del servicio de producción debe estar disponible. Hay un número limitado de versiones en el historial de versiones. Consulte los problemas y límites conocidos. |
Todas las demás opciones de recuperación en caso de catástrofe son creadas y respaldadas por el cliente.
| Característica | Descripción | Consideración |
|---|---|---|
| Fuente externa de la verdad | Todos los secretos creados a través de un script, descrito a continuación. | El cliente debe crear la secuencia de comandos y mantener la configuración en un lugar donde pueda utilizarse en caso de catástrofe |
| Copia de seguridad y restauración | Copia de seguridad de una instancia de servicio utilizando un script escrito por el cliente. | El cliente debe crear la secuencia de comandos y conservar la copia de seguridad en un lugar donde pueda utilizarse durante la recuperación |
| Sincronización en directo | Los cambios secretos en producción se observan automáticamente y se propagan para recuperar la instancia de servicio, véase la descripción a continuación | El cliente debe crear y mantener las herramientas. La corrupción de datos se sincronizará con la instancia de recuperación. |
Función de rotación
Los secretos del Gestor de Secretos se actualizan generalmente mediante "rotación", en la que la escritura de un valor da lugar a la creación de una nueva versión del secreto. Puede ser posible restaurar la corrupción de datos restaurando secretos de versiones anteriores en la instancia de producción. Sólo se conserva un número fijo de versiones. Véase la gestión de versiones secretas.
Fuente externa de verdad característica proporcionada por el cliente
El cliente debe crear y utilizar alguna combinación de terraforma, script o programa como fuente de verdad. Primero actualice la fuente de verdad y luego utilice la fuente de verdad para crear/actualizar la instancia de servicio primaria y la instancia de servicio de recuperación. La fuente debe estar disponible para la versión de restauración y es un único punto de fallo.
Si un cliente declara un desastre en la instancia primaria, se utilizará el servicio de la región de recuperación (Operación mínima) o el creado (Huella cero). Redirija sus componentes de carga de trabajo a la instancia recuperada u opcionalmente inserte en el código de reintento dentro de su aplicación para redirigir las peticiones a la segunda instancia (Operación Mínima).
El repositorio que contiene la fuente de la verdad debe tener una recuperación puntual, como los buckets de Object Storage con versionado, o los repositorios de Github.
Función de copia de seguridad y restauración proporcionada por el cliente
Para realizar una copia de seguridad manual de los secretos de las regiones, primero debe tener una instancia de Secrets Manager en otra región. Luego siga los pasos siguientes para garantizar la disponibilidad entre regiones.
Listar y descargar secretos de la instancia utilizando la CLI o la API de Secrets Manager.
Si tiene configuraciones existentes en motores de secretos en su instancia, también puede recuperar la información mediante programación para poder volver a crearla en una nueva instancia. Para más información, consulte la API Obtener la configuración de un tipo de secreto.
Añadir los secretos descargados a la instancia recién creada.
Se puede crear una copia de seguridad automática de los secretos mediante la automatización del flujo manual, lo que se puede hacer de varias maneras. Revise los siguientes ejemplos para ver si alguno de ellos puede servirle.
Sincronización en directo proporcionada por el cliente
El cliente puede crear un script o programa para descargar secretos de su instancia de servicio principal utilizando la API de Secrets Manager o y rellenar la instancia de servicio de recuperación con los datos. El script puede aprovechar IBM Cloud. Registra eventos de auditoría de la instancia principal para mantener sincronizada la instancia de recuperación junto con Code Engine. Deben conservarse copias de seguridad gestionadas por el cliente para restaurar desde el desastre.
Crea un script que descargue periódicamente tus secretos y luego los importe a tu instancia de copia de seguridad.
Cree un destino y una suscripción en Event Notifications que apunte a una acción de IBM Cloud Code Engine. Configure la acción para que escuche eventos del ciclo de vida como secret_created y secret_rotated. A continuación,
cuando la acción recibe el suceso, la acción descarga el secreto de una instancia y lo añade a la instancia de copia de seguridad.
Secrets Manager admite notificaciones para los distintos tipos de secreto que proporciona. Para obtener información sobre los distintos tipos de sucesos de ciclo de vida disponibles, consulte Habilitación de notificaciones de sucesos.
Planificación de la recuperación tras desastre
Las medidas de recuperación en caso de catástrofe deben practicarse con regularidad. Cuando elabore su plan, tenga en cuenta los siguientes escenarios de fracaso y resoluciones.
| Anomalía | Resolución |
|---|---|
| Fallo de hardware (punto único) | IBM proporciona una instancia resistente a fallos de hardware de un solo punto dentro de una zona, sin necesidad de configuración. |
| error de zona | IBM proporciona una instancia resistente a fallos de zona, sin necesidad de configuración. |
| Corrupción de datos | Utilice la rotación para restaurar la versión secreta anterior en una instancia de servicio disponible. |
| Corrupción de datos | Restaurar una versión no corrompida en un momento dado a partir de la fuente externa de verdad o de la copia de seguridad y restaurar. |
| Fracaso regional | Cambie las cargas de trabajo críticas para utilizar la versión restaurada en una región de recuperación. Restaurar la instancia utilizando una fuente externa de verdad, copia de seguridad y restauración, o sincronización en vivo. |
Sus responsabilidades en HA y DR
La siguiente lista de comprobación asociada a cada característica puede ayudarle a crear y poner en práctica su plan.
- Rotation
- Cree una instancia de recurso de prueba y practique la rotación de versiones secretas y la restauración de una versión secreta.
- Fuente externa de la verdad
- Compruebe que la fuente de verdad se encuentra en un repositorio disponible en la ubicación de restauración.
- Verifique que la fuente de verdad no dependa de la región del desastre para evitar la dependencia de una región fallida.
- Copia de seguridad y restauración
- Compruebe que la copia de seguridad se encuentra en un repositorio disponible en la ubicación de restauración.
- Compruebe que el script escrito por el cliente para restaurar los datos está disponible en la región de restauración.
- Verifique que el script y la copia de seguridad no dependan de la región de desastre para evitar la dependencia de una región fallida. Considere un Object Storage cubo regional cruzado.
- Sincronización en directo
- Compruebe que la instancia del servicio de recuperación está disponible en la región de restauración
- Tanto para la fuente externa de la verdad como para la sincronización en vivo:
- Verificar que las cargas de trabajo de recuperación en la región de recuperación están integradas con la instancia de servicio de recuperación
- Verifique que los secretos específicos de la región estén disponibles en la instancia del servicio de recuperación.
Para obtener más información sobre la propiedad de la responsabilidad entre el cliente y IBM Cloud por el uso de Secrets Manager, consulte Comprender sus responsabilidades al utilizar Secrets Manager.
Las medidas de recuperación en caso de catástrofe deben practicarse con regularidad. Cuando elabore su plan, tenga en cuenta los siguientes escenarios de fracaso y su resolución.
Recuperación del cliente tras la pérdida de BYOK
Si su instancia de servicio se aprovisionó utilizando la clave raíz de IBM® Key Protect for IBM Cloud® o Hyper Protect Crypto Services y borró accidentalmente la clave raíz, abra un caso de soporte para el servicio e incluya la siguiente información:
- CRN de su instancia de servicio
- El CRN de su copia de seguridad de Key Protect o instancia HPCS
- El nuevo Key Protect o ID de la clave raíz HPCS
- El CRN y el ID de clave de la instancia original de Key Protect o HPCS, si están disponibles
Consulte Recuperación de una pérdida de clave accidental para obtener autorización en los documentos de Key Protect y HPCS.
Objetivo de tiempo de recuperación (RTO) y objetivo de punto de recuperación (RPO)
| Característica | RTO y RPO |
|---|---|
| Restaurar la versión secreta anterior | RTO = minutos, la práctica y potencialmente los scripts mejorarán los tiempos RTO, RPO = 0. |
| Fuente externa de la verdad - huella cero | RTO = pocos minutos. Cantidad de tiempo para aprovisionar y rellenar con datos. Tenga en cuenta también el tiempo necesario para ajustar las cargas de trabajo recuperadas al nuevo punto final de la instancia de servicio. RPO = 0, se cambia la fuente de verdad antes de realizar cambios de producción. |
| Fuente externa de la verdad: copia de seguridad totalmente operativa | RTO = pocos segundos, RPO = 0. Mejore la descripción de la huella cero para mantener una instancia de servicio activa en la región de recuperación. |
| Copia de seguridad y restauración | RTO = pocos minutos. Cantidad de tiempo para aprovisionar y rellenar con datos. Tenga en cuenta también el tiempo necesario para ajustar las cargas de trabajo recuperadas al nuevo punto final de la instancia de servicio. RPO = hora de la última copia de seguridad. |
| Sincronización en directo | RTO = minutos, RPO = minutos si se basa en eventos o el periodo, por ejemplo diario, si se utilizan copias de seguridad periódicas. |
Al crear una nueva instancia de servicio, el RTO de la carga de trabajo mediante Secrets Manager incluirá el tiempo necesario para ajustar las cargas de trabajo recuperadas al nuevo punto final de la instancia de servicio.
Gestión de cambios
La gestión de cambios incluye tareas como actualizaciones, cambios de configuración y eliminaciones.
Se recomienda conceder a los usuarios y procesos las funciones y acciones de IAM con los menores privilegios necesarios para su trabajo.
Por ejemplo, limitar la capacidad de eliminar recursos de producción.
Cómo ayuda IBM® a garantizar la recuperación ante desastres
IBM® toma medidas específicas de recuperación en caso de desastre.
Cómo se recupera IBM® de los fallos de zona
En caso de fallo de una zona, IBM Cloud resolverá la interrupción de la zona y, cuando ésta vuelva a estar en línea, el equilibrador de carga global reanudará el envío de solicitudes de API al nodo de instancia restaurado sin necesidad de que intervenga el cliente.
Cómo se recupera IBM® de los fallos regionales
Cuando se restaura una región tras un fallo, IBM intentará restaurar la instancia de servicio desde el estado regional, con lo que no se perderán datos y la instancia de servicio se restaurará con las mismas cadenas de conexión.
- RTO = pocos minutos
- OPR = 0 minutos
Si el estado regional se corrompe, el servicio se restaurará al estado de la última copia de seguridad interna. El servicio realiza una copia de seguridad diaria de todos los datos asociados al servicio en un bucket de Cloud Object Storage interregional gestionado por el servicio. Existe la posibilidad de perder datos durante 24 horas. Estas copias de seguridad no están disponibles para la recuperación de desastres gestionada por el cliente. Cuando se recupere un servicio de las copias de seguridad, el ID de instancia también se restaurará, por lo que los clientes que utilicen el punto final no tendrán que actualizarse con nuevas cadenas de conexión.
- RTO = 2 horas
- OPR = 24 horas como máximo
En caso de que IBM no pueda restaurar la instancia de servicio, el cliente deberá restaurarla tal y como se describe en la sección de recuperación ante desastres.
Cómo IBM® mantiene los servicios
Todas las actualizaciones siguen las mejores prácticas del servicio IBM® y cuentan con un plan de recuperación y un proceso de reversión. Las actualizaciones periódicas para nuevas funciones y el mantenimiento forman parte de las operaciones normales. Este mantenimiento puede causar ocasionalmente breves intervalos de interrupción que son gestionados por la lógica de reintento de disponibilidad del cliente. Los cambios se introducen secuencialmente, región por región y zona por zona dentro de una misma región. Las actualizaciones se echan atrás a la primera señal de un defecto.
Los cambios complejos se activan y desactivan con banderas de función para controlar la exposición.
Los cambios que afectan a las cargas de trabajo de los clientes se detallan en las notificaciones. Para obtener más información, consulte las notificaciones de seguimiento y el estado del mantenimiento planificado, los anuncios y las notas de la versión que afectan a este servicio.