Propuesta de valor
A raíz del reciente incendio del data center OVH de Estrasburgo del proveedor de hosting y servicios cloud OVH (uno de los más importantes de Europa), me gustaría trasladaros algunas reflexiones que hacemos desde Neteris en relación a la seguridad de las plataformas y servicios cloud que gestionamos a diario.
Las últimas actualizaciones que recibo a través de los feeds tecnológicos a los que estoy suscrito apuntan a que ya se ha determinado el origen del incendio y, aunque afortunadamente no hay que lamentar daños personales, lo que aún no se ha aclarado es por qué razón los planes de contingencia de OVH no fueron capaces de restablecer la totalidad del servicio en sus datacenters de Disaster Recovery (DR) en un tiempo aceptable.
Cuando hablamos de planes de DR, generalmente distinguimos tres tipologías de eventos/contingencias:
- Fallos operacionales: flujo de corriente, fallos hardware, fallos de red, fallos de software, etc.
- Desastres naturales: incendios, huracanes, terremotos, inundaciones, etc.
- Fallos humanos: error humano, ataques maliciosos contra la seguridad, terrorismo, etc.
En el modelo de seguridad compartida que propone Oracle Cloud, la distribución de responsabilidades que el fabricante presenta es la siguiente:
Generalmente, en lo que a nuestros clientes concierne (IaaS + PaaS en OCI), Oracle nos proporciona las siguientes “herramientas”:
CAPA FÍSICA E INFRAESTRUCTURA
Una región es un área geográfica localizada, independiente de otras regiones y separada por grandes distancias (entre países e incluso continentes):
- Para mitigar el riesgo de los eventos que afecten a toda la región, como grandes borrascas o terremotos.
- Para cumplir con requisitos variables de jurisdicciones legales, dominios fiscales y otros criterios sociales o de negocio.
Un dominio de disponibilidad (availability domain = AD) es uno o más centros de datos que se encuentran en una región. Una región está formada por uno o varios dominios de disponibilidad. Los dominios de disponibilidad están aislados entre sí, son tolerantes a fallos y es muy poco probable que fallen simultáneamente. Dado que los dominios de disponibilidad no comparten infraestructura, como alimentación o refrigeración, o la red interna del dominio de disponibilidad, es poco probable que un fallo en un dominio de disponibilidad dentro de una región afecte a la disponibilidad de los demás en la misma región.
Los dominios de disponibilidad dentro de la misma región se conectan entre sí mediante una red de ancho de banda alto y de baja latencia, lo que hace posible que ofrezcan conectividad de alta disponibilidad a Internet y redes locales, y que creen sistemas replicados en varios dominios de disponibilidad para una recuperación ante desastres y de alta disponibilidad. El tráfico entre dominios de disponibilidad y entre regiones está cifrado.
Un dominio de errores (fault domain = FD) es una agrupación de hardware e infraestructura dentro de un dominio de disponibilidad. Cada dominio de disponibilidad contiene tres dominios de errores. Los dominios de errores proporcionan anti afinidad: permiten distribuir las instancias de forma que no estén en el mismo hardware físico dentro de un único dominio de disponibilidad.
Por esto, un evento de mantenimiento de hardware informático o error de hardware que afecta a un dominio de errores no afecta a las instancias de otros dominios de errores. Además, el hardware físico en un dominio de errores tiene fuentes de alimentación independientes y redundantes, lo que evita que un error en el hardware de la fuente de alimentación dentro de un dominio de errores afecte a otros dominios de errores.
CAPA NETWORK Y VIRTUALIZACIÓN
Oracle Cloud es la única nube pública, a día de hoy, que elimina la sobresuscripción de los recursos de virtualización y networking, proporcionando máximo aislamiento del tenant, protección y rendimiento.
CAPA DE APLICACIÓN
Neteris despliega los aplicativos y servicios empresariales en base a las best-practices propuestas en las arquitecturas de referencia del fabricante (diseño multi-subred —control de red vía Security Lists y Network Security Groups— multi-fault domain, multi-AD, balanceadores de carga, etc).
Y además, Neteris propone una estrategia de Disaster Recovery para los aplicativos IaaS basada en una Pilot light (Activo/Pasivo); duplicando los recursos de Compute y Block Storage de los diferentes componentes del aplicativo (EnterpriseOne Enterprise Servers, HTML Servers, AIS Servers, etc.) en diferentes ADs y FDs del tenant OCI, manteniéndolos (pasivos) detenidos para evitar un sobre coste en la facturación UCs de los servicios de Compute, pero con un tiempo de respuesta mínimo para estar totalmente disponibles en caso de desastre.
Por último, Neteris, como continuación natural a sus Proyectos “llave en mano” con entregables IaaS/PaaS en OCI, trabaja desde el área de DevOps de AMS en la configuración de las políticas de backup recurrente de todos los volúmenes de bloque de la infraestructura, de modo que, si fuera necesario, en caso de desastre total en una región, pudiésemos replicar una infraestructura idéntica en otra región.
CAPA DE DATA
En este aspecto, Neteris configura las herramientas de backup propias de Oracle Database: Recovery Manager (RMAN) –a Block Volume y/o a Objects Storage—y Export Datapump diario, en base a las necesidades de RTO del cliente y monitoriza su correcta ejecución recurrente desde la práctica de AMS.
En otro orden de cosas, por supuesto, tenemos clientes que, dentro de sus planes de contingencia, definen parámetros de RTO y RPO sumamente exigentes (especialmente en lo referente a la información y el dato), para los que montamos soluciones de alta disponibilidad basadas en diferente escenarios MAA de Oracle Database que incluyen tecnologías de replicación near-zero-downtime del tipo Oracle Dataguard o Oracle Golden Gate que replican la información a diferentes dominios de disponibilidad e incluso diferentes regiones OCI; que requieren features de alta disponibilidad tipo RAC o que apuestan por sistemas autogestionados: Autonomous Database o Exadata (sabor cloud o cloud at customer).
Oracle Cloud Maximum Availability Architecture
https://www.oracle.com/a/tech/docs/cloud-maa-overview.pdf
Si en algún momento consideras que por grado de madurez, requerimiento de auditoría o necesidad del Negocio, necesitáis comenzar conversaciones al respecto, estaremos encantados de comentar con vosotros posibles aproximaciones que se adapten a vuestras necesidades, daros nuestra visión al respecto en base a nuestra experiencia, aconsejaros en la mejor estrategia de implantación y recorrer este camino juntos.
La seguridad nos preocupa y nos ocupa mucho tiempo en Neteris y siempre proponemos implementar las best-practices del fabricante que, en este caso, se han convertido en el estándar del mercado de cloud pública.
La finalidad de este artículo era trasladaros un grado de tranquilidad y confianza en el producto (Oracle Cloud Infrastructure) y en Neteris como partner destacado que muchos clientes han escogido para acompañarles en el paso a la nube y para la gestión de sus aplicativos en OCI.
¿Qué opinión os merece mi análisis?
Blogs relacionados:
>> Oracle GoldenGate. Sincronización y Migraciones en Tiempo Real
>> Oracle GoldenGate: Innovación líder en la Gestion de Base de Datos
