Más información sobre el pilar de resiliencia cibernética en OCI

La resiliencia cibernética es la evolución y extensión de la copia de seguridad y la recuperación tradicionales. En caso de un ataque cibernético, la resiliencia cibernética anticipa que el entorno de copia de seguridad y recuperación también será atacado. La integridad de la copia de seguridad de los datos es sospechosa y se debe validar antes de restaurar los datos en un entorno de producción.

Puede utilizar las funciones de control nativas de OCI para proteger su arrendamiento. También puede utilizar proveedores de copia de seguridad y recuperación de terceros. Oracle recomienda que tenga tanto copias de seguridad operativas como copias de seguridad inmutables para complementar los libros de ejecución de copia de seguridad y recuperación estándar.

Utilizar la arquitectura de referencia de resiliencia cibernética de OCI como plantilla para garantizar la continuidad del negocio durante las amenazas e infracciones de integridad de datos, y para complementar y mejorar las arquitecturas de recuperación ante desastres existentes o estándar.

A continuación se muestra la arquitectura de referencia para implementar la resiliencia cibernética en OCI:

Descripción de la ilustración cyber-resilience-mandatory-arch.png

ciber-resiliencia-obligatorio-arch-oracle.zip

Esta arquitectura muestra un enclave de producción que consta de compartimentos de red, aplicación y base de datos. El enclave de Vault contiene un único compartimento que aloja las copias de seguridad inmutables para datos no estructurados. Dentro del enclave de Vault, tenemos un cubo de Object Storage inmutable, un servidor de orquestación y nodos de trabajador. El servidor de orquestación coordina el proceso de copia de seguridad buscando todos los recursos de los que se debe realizar una copia de seguridad y, a continuación, solicitando a los nodos de trabajador que realicen las operaciones de copia de seguridad reales. Los datos se pueden copiar de varios compartimentos de aplicación en el cubo del compartimento Vault.

El enclave de OCI Vault se utiliza para almacenar datos no estructurados, que incluye datos de aplicaciones locales en máquinas virtuales y/o datos almacenados en un recurso compartido de NFS mediante OCI File Storage.

Para datos estructurados que incluyen bases de datos Oracle, Oracle Database Zero Data Loss Autonomous Recovery Service proporciona copias de seguridad inmutables y protección contra ransomware.

Acerca de Enclaves

Las arquitecturas modernas en la nube resilientes utilizan un concepto llamado Enclaves.

Un enclave es un área lógicamente aislada y con espacio en el aire dentro de su arrendamiento de Oracle Cloud Infrastructure (OCI). Los enclaves se separan mediante compartimentos, redes virtuales en la nube, políticas de OCI IAM y Oracle Services Network, lo que crea límites lógicos para la seguridad y la gestión. Un espacio aéreo administrativo entre enclaves le permite utilizar dominios de identidad independientes, aislar redes virtuales en la nube o arrendamientos independientes.

Descripción de la ilustración prod-vault-safe-restore-enclaves.png

Hay tres tipos de enclaves comúnmente utilizados:

1. Enclave de producción: el compartimento enclave de producción consta de uno o más compartimentos que alojan las cargas de trabajo de producción. La estructura se basa en la arquitectura de referencia Desplegar una zona de llegada segura que cumpla con la referencia de Fundamentos de OCI de CIS enlazada en la sección Antes de empezar. Se debe poder acceder fácilmente a las copias de seguridad operativas en el enclave de producción. Para las operaciones normales de copia de seguridad y recuperación, esto debe cumplir con la mayoría de los requisitos de baja latencia y recuperación rápida mediante funciones nativas. Los datos canarios podrían ser monitoreados para la observación en el enclave de producción también. Utilice el enclave de producción para:
   • Almacenamiento y acceso a copias de seguridad operativas
   • Implementación en profundidad de la defensa
   • (Opcional) Observación de conjuntos de datos canarios
2. Esclavo de OCI Vault: el compartimento esclavo de OCI Vault almacena todas las copias de seguridad no estructuradas de Object, Block y File Storage en un estado "inmutable" para evitar que se modifiquen o supriman. La red del enclave Vault está aislada y no tiene conectividad directa con el enclave Production. Está protegido con políticas de OCI IAM muy restrictivas derivadas de un dominio de identidad independiente que proporciona una brecha administrativa de las identidades de producción.

   Todas las pruebas de automatización de copias de seguridad y la inspección de malware o corrupción para estas copias de seguridad se realizan aquí. Las copias conocidas de todas las copias de seguridad no estructuradas de Object, Block y File Storage se almacenan en este enclave a la espera de un evento de recuperación. La integridad de los datos y la detección de malware para las bases de datos están integradas en Oracle Database Zero Data Loss Autonomous Recovery Service.

   Las copias de seguridad de bases de datos se almacenan de forma inmutable en un arrendamiento independiente controlado por OCI sin acceso directo desde el enclave de producción, excepto para las operaciones de restauración. Las copias de seguridad de la base de datos se pueden montar y probar para comprobar la integridad final de los datos y la preparación operativa. Utilice el enclave de OCI Vault para:

   • Almacenamiento de copias de seguridad periódicas
   • Almacenamiento inmutable
   • Automatización de pruebas de copia de seguridad
   • Detección de corrupción de datos en copias de seguridad
   • Detección de malware en datos de copia de seguridad
3. Enclave de restauración segura (opcional): el enclave de restauración segura también está separado del enclave de OCI Vault con otro espacio aéreo administrativo que utiliza un dominio de identidad y un arrendamiento independientes que el enclave de producción. Los enclaves de Safe Restore se pueden crear mediante herramientas de infraestructura como código como Terraform para desplegar rápidamente un entorno de producción equivalente. Aquí, restaura continuamente copias de seguridad conocidas para verificar la preparación operativa, guiadas por los valores de Objetivo de tiempo de recuperación (RTO) y Objetivo de punto de recuperación (RPO).

   En caso de un incidente grave, puede utilizar temporalmente el enclave de restauración segura como su nuevo entorno de producción hasta que se eliminen las amenazas de su espacio de producción original. Utilice el enclave de restauración segura para:

   • Restauraciones incrementales continuas de datos de copia de seguridad
   • Prueba de copias de seguridad para cumplir los objetivos de RTO y RPO
   • Cambio rápido a un nuevo entorno de producción si es necesario
   • Escalado del entorno de producción mínima a completa mediante Terraform
   • Reducción del entorno de producción original después del análisis forense y la recuperación

   Atención:

   El enclave de Restauración Segura no está diseñado como un sitio tradicional de recuperación ante desastres en frío. En su lugar, permite la prueba continua de su estrategia de recuperación y proporciona la capacidad de crear instantáneamente un nuevo entorno de producción si el principal se ve comprometido. Si su enclave de producción es atacado por ransomware, la policía puede necesitar investigar y recopilar información forense que conduzca a un tiempo de inactividad inesperado y, por lo tanto, retrasar sus esfuerzos de recuperación. Si su organización no puede permitirse el tiempo de inactividad para aplicaciones críticas, considere la posibilidad de implementar un enclave de restauración segura.

Recomendaciones para operaciones de copia de seguridad y recuperación

Al planificar el despliegue de soluciones tecnológicas, tenga en cuenta que hay varios equipos que deben colaborar para coordinar el proceso de copia de seguridad y recuperación. Aunque la mayoría de las acciones de copia de seguridad suelen estar automatizadas, la recuperación puede ser más tediosa y requerir intervención humana. Las organizaciones pueden desarrollar un runbook que contenga procedimientos operativos estándar (SOP) a seguir cuando se necesiten acciones específicas. En este manual de soluciones, el ámbito de la copia de seguridad y la recuperación se limita a la región actual en la que existe la carga de trabajo principal. La recuperación ante desastres resuelve la disponibilidad y se centra en recuperar una copia de seguridad de un bien conocido o una copia prístina sin escalas.

En el caso de las máquinas virtuales nativas de OCI, Oracle recomienda crear imágenes personalizadas periódicamente y exportarlas a un cubo inmutable de Object Storage. Esto le permite reconstruir y restaurar el volumen de inicio. Considere la posibilidad de desarrollar un runbook en caso de un fallo total de la máquina virtual. Si las copias de seguridad operativas no logran restaurar la máquina virtual, debe probar el proceso de reconstrucción de una imagen personalizada desde el cubo inmutable. Revise la página Importación y exportación de imágenes personalizadas en la documentación de OCI.

Con las copias de seguridad operativas, normalmente puede restaurar de forma segura en producción. Si sospecha un incidente de ciberseguridad, deberá restaurar el compartimento de OCI Vault o el área Safe Restore, donde ha implantado controles en el dominio de confianza cero. Después de inspeccionar los datos restaurados, debe analizar y mitigar los riesgos de seguridad restantes en la máquina virtual o los datos sin procesar (como malware, virus, etc.).

Después de verificar que no quedan riesgos de ciberseguridad, restaure la copia prístina sin alterar a la producción. Documente, pruebe y valide este proceso al menos dos veces al año. En OCI, tendrás muchos datos de inicio, bloque, archivo y otros datos no estructurados. Cataloga todas las asignaciones de recursos asociadas, como asignaciones de unidades, puntos de montaje, instancias informáticas y otros objetos raw en OCI. Utilice productos de copia de seguridad de terceros, herramientas de código abierto y/o la CLI de OCI para realizar instantáneas de las asociaciones en un momento y hora determinados. El registro de estos datos puede ayudarle a responder preguntas críticas y determinar un curso de acción. Por ejemplo, si se produce un fallo en la restauración de un volumen en bloque, identifique las máquinas virtuales que se encuentran en estado degradado.

Resumen de controles de operaciones de copia de seguridad y recuperación

• BR-1: copia de seguridad de imagen personalizada de OCI en un cubo inmutable.
• BR-2: Implantación de operaciones de copia de seguridad y restauración en el área OCI Vault o Safe Restore.
• BR-3: Asignaciones de recursos asociadas al catálogo (como asignaciones de unidades, montajes, instancias informáticas, etc.).
• BR-4: cree un enclave de OCI Vault y/o un entorno de área de restauración segura.

Recomendaciones para la inmutabilidad

Los datos de copia de seguridad inmutables no se pueden modificar ni suprimir durante el período de retención definido por el cliente. Para implementar la arquitectura de resiliencia cibernética, Oracle recomienda que tenga copias de seguridad operativas y copias de seguridad inmutables. Utilizar copias de seguridad operativas para operaciones normales de copia de seguridad y recuperación. En caso de corrupción de datos, malware u otros riesgos cibernéticos, la copia de seguridad inmutable es su copia inmaculada, que está libre de corrupción o manipulación de datos.

Incluso cuando sus copias de seguridad son inmutables, es posible que los datos de origen de copia de seguridad contengan código malicioso o malware. Al restaurar datos a partir de copias de seguridad operativas o inmutables, considere el uso de un entorno de OCI Vault o Safe Restore para validar que la copia de seguridad esté libre de cualquier amenaza cibernética y para evitar cualquier daño adicional a sus entornos de producción.

Para la mayoría de las bases de datos de OCI, como Oracle Base Database Service, Oracle Exadata Database Service on Dedicated Infrastructure y Oracle Autonomous Database on Dedicated Exadata Infrastructure, Oracle recomienda utilizar el Oracle Database Zero Data Loss Autonomous Recovery Service, que ofrece una protección de datos totalmente gestionada que se ejecuta en OCI. Recovery Service cuenta con capacidades automatizadas para proteger los cambios de Oracle Database en tiempo real, validar copias de seguridad sin sobrecarga de la base de datos de producción y permitir una recuperación rápida y predecible en cualquier momento. Al activar la protección de datos en tiempo real, puede recuperar una base de datos protegida en menos de un segundo de cuando se produjo una interrupción o un ataque de ransomware. El servicio de recuperación incluye la inmutabilidad y la detección de anomalías integradas en la plataforma, lo que le brinda visibilidad del estado de sus copias de seguridad y se puede configurar para enviarle alertas para notificarle sobre problemas que puedan afectar su capacidad de recuperación.

También puede utilizar Oracle Autonomous Database Serverless, que admite de forma nativa la retención de copias de seguridad inmutables. Asegúrese de activar la función.

OCI Object Storage puede implantar controles de inmutabilidad compatibles con WORM (una sola escritura y varias lecturas) que impiden que los datos se modifiquen o supriman. Funciones como las reglas de retención de Object Storage definen cuánto tiempo se deben retener los datos antes de poder suprimirlos. Después del período de retención, puede utilizar políticas de ciclo de vida de Object Storage para archivar o suprimir los datos. Oracle recomienda probar el proceso de copia de seguridad. Una vez que esté convencido de que el período de retención cumple los requisitos de negocio, debe bloquear la regla de retención para evitar que los administradores del arrendamiento realicen más modificaciones. Existe un retraso obligatorio de 14 días para que se bloquee una regla. Este retraso permite probar, modificar o suprimir minuciosamente la regla o el bloqueo de la regla antes del bloqueo de forma permanente.

Atención:

El bloqueo de una regla de retención es una operación irreversible. Ni siquiera un administrador de arrendamiento ni los Servicios de Soporte Oracle pueden suprimir una regla bloqueada.

Las máquinas virtuales son una combinación de volúmenes de inicio y volúmenes en bloque en OCI. Para proteger el volumen de inicio de OCI, cree una imagen personalizada de la máquina virtual y, a continuación, exporte la imagen personalizada (.oci es el formato por defecto, pero .qcow2 u otros formatos están soportados) en un cubo de OCI Object Storage.

Se debe realizar una copia de seguridad de cualquier dato crítico que se encuentre en un volumen de bloques mediante un script personalizado en el bloque de Object Storage inmutable.

OCI File Storage permite a los usuarios crear instantáneas, pero estas no son inmutables por defecto, ya que cualquier administrador de OCI con los privilegios de IAM adecuados puede suprimir una instantánea. Para proteger OCI File Storage, Oracle recomienda copiar los datos directamente en un cubo inmutable de forma periódica.

Resumen de controles de inmutabilidad

• IM-1: configure un cubo inmutable para datos no estructurados.
• IM-2: Protege tus datos con Oracle Database Zero Data Loss Autonomous Recovery Service para bases de datos de OCI.
• IM-3: si utiliza OCI File Storage, copie OCI File Storage en un cubo inmutable de Object Storage.

Recomendaciones para controles de seguridad de confianza cero

Para implantar la seguridad de confianza cero, Oracle recomienda evaluar los controles de arrendamiento que:

• Restricción de identidades y permisos: limite las identidades (dominios, grupos, usuarios y políticas de IAM) que pueden acceder a sus copias de seguridad y sus permisos
• Fortalecer la segmentación de red: vuelva a evaluar la segmentación de red junto con la implementación de brechas de aire virtuales para copias de seguridad inmutables.

Combine estos dos conceptos para que sea mucho más difícil para los actores de amenazas acceder a sus datos.

El diseño de compartimentos es fundamental para implementar la seguridad de confianza cero en la arquitectura de resiliencia cibernética. Cree una arquitectura de compartimento anidada con el compartimento de copia de seguridad en el nivel superior e incluya al menos dos compartimentos secundarios, por ejemplo, uno para copias de seguridad de almacén inmutables y otro para restauración segura. Esta configuración le permite aplicar políticas de IAM más cerca de los recursos individuales y aplicar la separación de funciones.

Para un control de acceso más estricto, cree usuarios y grupos específicos para acceder a sus cubos de Object Storage inmutables. En función de sus requisitos de seguridad, puede separar aún más el acceso por dominio de identidad, compartimento, usuarios, grupos y políticas de IAM para restringir quién puede acceder a un cubo específico. En los arrendamientos existentes en los que pueden tener acceso varios grupos a un bloque, revise y reduzca el acceso para que solo los administradores del almacenamiento de copia de seguridad puedan gestionar las copias de seguridad.

Oracle Access Governance proporciona una página Quién tiene acceso a qué - Explorador de toda la empresa que realiza un seguimiento y supervisa a los usuarios que tienen acceso a diferentes sistemas, datos y aplicaciones, sus niveles de permiso y la finalidad del acceso, para tomar decisiones informadas y detectar posibles riesgos de seguridad para una gobernanza eficaz. Utilice esta información para asegurarse de que sus políticas de IAM se alinean con los principios de separación de funciones y privilegio mínimo.

Si utiliza máquinas virtuales u otra infraestructura IaaS esencial para realizar copias de seguridad, considere agregarlas a un grupo dinámico de OCI. Esto permite dirigir estos nodos a políticas de IAM que otorguen el acceso necesario al nivel de almacenamiento de copia de seguridad.

Refuerce el acceso a la red en su entorno de confianza cero. Siga estas recomendaciones para evitar que una máquina virtual restaurada reinfecte la producción, vuelva a abrir una puerta trasera de seguridad o un punto de acceso de comando y control para los atacantes:

• En su entorno de confianza cero, restrinja el acceso a la red siempre que sea posible. Por ejemplo, en un enclave de OCI Vault o Safe Restore, evite utilizar un DRG que pueda permitir que el malware se filtre al resto de su entorno de OCI. En su lugar, considere el uso del servicio Bastion gestionado por OCI (o hosts de salto gestionados por el cliente), el punto final privado o un gateway de servicio para permitir el acceso al plano de control de OCI.
• No permita el enrutamiento entre las distintas redes de copia de seguridad. Si necesita conectividad de red entre la infraestructura de copia de seguridad, implante OCI Network Firewall y los NSG para permitir solo patrones de tráfico estrechamente controlados. Esto crea una brecha de aire de red virtual entre las redes de producción y los compartimentos de copia de seguridad, y evita que las máquinas virtuales restauradas reinfecten los entornos de producción o reabran las vulnerabilidades en el entorno.

Resumen de controles de seguridad de confianza cero

• ZT-1: configure cubos de almacenamiento de objetos privados y seguros con permisos de IAM limitados a cuentas de recuperación especializadas. Opcionalmente, aproveche Oracle Access Governance para determinar permisos efectivos en cubos inmutables.
• ZT-2: aplica una segmentación de red sólida. Utilice bastiones, puntos finales privados, gateways de servicio, NSG y firewalls de red.
• ZT-3: mejore IAM mediante el uso de afiliaciones a grupos dinámicos y políticas de IAM para actividades de almacenamiento inmutables con scripts.
• ZT-4: diseña estructuras de compartimentos como se describe en la arquitectura de referencia de resiliencia cibernética de OCI. Utilice compartimentos anidados para aplicar políticas de IAM cercanas a los recursos y aplicar la separación de funciones.

Recomendaciones para los controles de detección de amenazas

Uno de los mayores desafíos en ciberseguridad es detectar cuándo un actor de amenazas se ha infiltrado en su entorno. Incluso si ha implementado controles de seguridad básicos, como el registro de eventos y el análisis forense, aún puede ser difícil determinar si sus recursos en la nube ya se han visto comprometidos.

Considere el uso de las herramientas de gestión de la estrategia de seguridad en la nube (CSPM) para mejorar la protección en la nube. Oracle Cloud Guard es una herramienta de CSPM integrada en OCI que puede utilizar para implantar su arquitectura de resiliencia cibernética. También hay soluciones de terceros disponibles que ofrecen funciones como detección de intrusiones, detección de anomalías y alertas. Por ejemplo, con OCI Cloud Guard, puede configurar políticas para evitar que OCI Object Storage se exponga como un cubo público en Internet. Además, la herramienta CSPM debe supervisar los servicios esenciales, como Oracle Database Zero Data Loss Autonomous Recovery Service, y asegurarse de que no esté desactivada y de que las copias de seguridad y las políticas de copia de seguridad sigan siendo seguras. Configure la herramienta de CSPM para verificar si se han desactivado servicios como Oracle Database Zero Data Loss Autonomous Recovery Service o si se han producido intentos de desactivar copias de seguridad, modificar políticas de copia de seguridad, etc.

Combine CSPM con soluciones de seguridad de punto final para abordar tanto las políticas de seguridad IaaS como las vulnerabilidades de punto final. Cuando envía logs de auditoría, logs de eventos, logs de flujo de VCN y otros datos a una plataforma SIEM o XDR (detección y respuesta ampliadas) de terceros, los administradores de la nube obtienen información valiosa para la correlación de eventos y la información forense avanzada.

Para obtener más información, consulte la sección Guía de diseño para la integración de SIEM en OCI enlazada en la sección Explorar más y el blog Visión general de las mejores prácticas de seguridad en el arrendamiento de OCI enlazado en la sección Antes de empezar.

Honeypots internos

Otra táctica valiosa de detección de amenazas es el despliegue de "centros de miel internos", instancias informáticas diseñadas para atraer a actores maliciosos. Estos honeypots suelen ejecutar servicios que son intencionalmente fáciles de detectar o explotar, haciéndolos visibles utilizando herramientas comunes de exploración de red como NMAP. En una red privada, nadie debe acceder a estos señuelos, por lo que cualquier interacción es un fuerte indicador de comportamiento sospechoso, como los actores de amenazas que buscan "servidores de archivos" u otros objetivos. Tanto las soluciones comerciales como las de código abierto están disponibles. En entornos bien seguros, debe haber una actividad sospechosa mínima detectada por los centros de miel, lo que los convierte en un sistema de alerta temprana confiable y una forma de validar sus controles existentes.

Note:

No despliegue puntos de miel en instancias con direcciones IP pública. Los puntos de miel expuestos a Internet son propensos a ser atacados, lo que podría suponer un riesgo adicional.

Datos de canario

Técnica de detección de amenazas, aplicable tanto a datos estructurados (como tablas de base de datos) como a datos no estructurados (como servidores de archivos). Al igual que los centros de miel, los datos canarios actúan como una trampa dirigida. Por ejemplo, puede crear una tabla dedicada o inyectar registros canarios específicos en una base de datos de producción. Si se produce un acceso, modificación o eliminación inesperados de estos registros, puede indicar una actividad no autorizada o maliciosa, como un actor de amenazas que intenta acceder a datos confidenciales o manipularlos, como la información del cliente o los detalles de la orden.

Para los sistemas de archivos, los datos canarios pueden incluir archivos o carpetas supervisados dentro de los recursos compartidos de NFS. Cualquier cambio no autorizado podría indicar un compromiso de seguridad. El uso de datos canarios normalmente requiere herramientas comerciales o de código abierto de terceros.

Resumen de controles de detección de amenazas

• TD-1: utilice políticas de cubo de Oracle Cloud Guard para controlar el acceso público y privado, activar el registro de cubo y activar las reglas de detección de amenazas.
• TD-2: implemente datos canarios dentro de conjuntos de datos estructurados (como bases de datos) y no estructurados (como almacenamiento de archivos) para detectar accesos no autorizados o alteraciones.
• TD-3: despliegue centros de miel internos con sensores de supervisión cercanos a los sistemas de copia de seguridad y producción para atraer e identificar posibles amenazas.
• TD-4: integre los datos de telemetría de su entorno con XDR/SIEM para permitir un análisis forense completo y un análisis avanzado de amenazas.