Por qué las empresas deberían alojar Odoo en la nube y sacar provecho de Google Cloud Platform

Cada vez más empresas recurren a plataformas en la nube porque ofrecen una solución de alojamiento más rentable, segura y escalable que los centros de datos tradicionales. En este artículo, el director de tecnología de Port Cities, Denis Guillot, profundiza en por qué las empresas deberían adoptar Google Cloud Platform.

¿Por qué Google Cloud Compute?

La mayoría de las empresas utilizan centros de datos porque ofrecen predictibilidad de costos, certeza de hardware y control. Sin embargo, ejecutar y mantener los recursos en un centro de datos también requiere una gran cantidad de gastos generales, que incluyen:

  • Capacidad: suficientes recursos para escalar según sea necesario y uso eficiente de esos recursos.

  • Seguridad: seguridad física para proteger los activos, así como seguridad a nivel de la red y del sistema operativo.

  • Infraestructura de red: componentes como cableado, conmutadores, enrutadores, firewalls y equilibradores de carga.

  • Soporte: empleados capacitados para realizar la instalación y el mantenimiento y para abordar los problemas.

  • Ancho de banda: ancho de banda adecuado para la carga máxima.

  • Instalaciones: infraestructura física, incluidos equipos y energía.

Las plataformas en la nube con funcionalidad total, como Cloud Platform, ayudan a eliminar gran parte de los gastos generales que rodean estas preocupaciones físicas, logísticas y relacionadas con los recursos humanos, y pueden ayudar a reducir muchos de los costos comerciales relacionados en el proceso. Debido a que Cloud Platform se basa en la infraestructura de Google, también ofrece beneficios adicionales que normalmente serían prohibitivos en costos en un centro de datos tradicional, que incluyen:

Una red global

Google tiene una de las redes informáticas más grandes y avanzadas. La red troncal o fundamental de Google utiliza servicios avanzados de almacenamiento en caché y redes definidas por software para brindar un rendimiento rápido, consistente y escalable.

Redundancia multirregional incorporada

Varias regiones y zonas de centros de datos en todo el mundo ayudan a garantizar una fuerte redundancia y disponibilidad. Esto es especialmente crucial cuando existe una necesidad específica de expansión / desarrollo internacional y en múltiples zonas geográficas.

Escalado rápido y confiable

Cloud Platform está diseñado para escalar como los propios productos de Google, incluso cuando experimentas un gran aumento de tráfico. Los servicios administrados como Google App Engine, el escalador automático de Google Compute Engine y Google Cloud Datastore te brindan un escalado automático que ayuda a que tu aplicación crezca y reduzca su capacidad según sea necesario.

Capacidad y ancho de banda

En un centro de datos tradicional, debes planificar tus necesidades de recursos, adquirir suficientes recursos por adelantado para escalar según sea necesario, y administrar cuidadosamente tu capacidad y distribuciones de cargas de trabajo dentro de esos límites de recursos. Debido a la naturaleza de los recursos aprovisionados previamente, no importa qué tan cuidadosamente administres tu capacidad, puedes terminar con una utilización subóptima:


                         Figura 1: Utilizacíon de recursos provisionados previamenta a lo largo del tiempo

Además, este aprovisionamiento previo de recursos significa que tienes un límite máximo de los mismos. Si necesitas escalar más allá de dicho límite, se te acabó la suerte.

Cloud Platform ayuda a resolver muchos de estos problemas de utilización y umbrales de escalabilidad. Puedes ampliar y reducir la escala de tus instancias de VM según sea necesario. Debido a que pagas lo que usas por segundo, puedes optimizar tus costos sin tener que pagar un exceso de capacidad que no necesitas todo el tiempo, o que sólo necesitas en las horas pico de tráfico.

Seguridad

El modelo de seguridad de Google es un proceso de principio a fin, basado en más de 18 años de experiencia centrada en mantener la seguridad de los clientes en las aplicaciones de Google, como Gmail y Google Apps. Además, los equipos de ingeniería de confiabilidad del sitio de Google supervisan las operaciones de los sistemas de la plataforma para ayudar a garantizar una alta disponibilidad y evitar el abuso de los recursos de la plataforma.

Infraestructura de red

En un centro de datos tradicional, administras una configuración de red compleja, que incluye racks de servidores, almacenamiento, múltiples capas de conmutadores, balanceadores de carga, enrutadores y dispositivos de firewall. Debes configurar, mantener y supervisar el software y las configuraciones detalladas del dispositivo. Además, debes preocuparte por la seguridad y la disponibilidad de tu red, y debes agregar y actualizar equipos a medida que aumentan tus necesidades de red.

Por el contrario, Cloud Platform utiliza un modelo de  redes definidas por software (SDN por sus siglas en íngles) , lo que te permite configurar tu red por completo a través de las APIs de servicio y las interfaces de usuario de Cloud Platform. No tienes que pagar ni administrar el hardware de red del centro de datos. Para obtener más detalles sobre Andromeda, que es el grupo de SDN de Google, consulta la publicación del blog
Enter the Andromeda zone .

Instalaciones y soporte

Cuando usas Cloud Platform, ya no necesitas preocuparte por instalar o mantener el hardware físico del centro de datos, ni debes preocuparte por tener técnicos capacitados para hacerlo. Google se encarga tanto de la capa de hardware como de los técnicos, lo que te permite concentrarte en ejecutar tu aplicación.

Cumplimiento

Google se somete a auditorías externas independientes periódicas para verificar que Cloud Platform esté alineada con los controles de seguridad, privacidad y cumplimiento. Cloud Platform realiza auditorías periódicas para estándares como ISO 27001, ISO 27017, ISO 27018, SOC 2, SOC 3 y PCI DSS.

Centrándose en los beneficios de seguridad 

La economía mundial sufre miles de millones de dólares en pérdidas por violación, robo o destrucción de datos cada año. Por esta razón, los principales actores de la industria de la Nube y GCP se han esforzado por lograr el cumplimiento de estándares tan prestigiosos como:

  • FIPS 140-2

  • ISO/IEC 27001

  • PCI DSS

  • ISO 27017

  • ISO 27018, SOC 2, SOC 3

Cifrado de todos los datos en reposo y en tránsito

Google Cloud Computing ha invertido millones de dólares en los últimos años para poder cumplir con FIPS de nivel 1, como puedes comprobarlo aquí y aquí.


Como recordatorio, FIPS es el Estasndar Federal de Procesamiento de Informacíon, que se encuentra entre los más exigentes del mundo, inicialmente establecido por la administración estadounidense para mantener seguros sus secretos e infraestructuras.


Lo siguiente es implementado por GCP y probablemente NO implementado en el nivel de red local de una "instalación en sitio":

TecnologíaGoogle Cloud ComputeImplementación local estándar
El producto de almacenamiento SSD local se cifra automáticamente con cifrados aprobados por NIST.
Se aplica en todo el almacenamiento
RARAMENTE implementado
Cifrado automático del tráfico entre ubicaciones de datos internos y externos, mediante algoritmos de cifrado aprobados por NIST.
Se aplica a todas las transferencias de datos
RARAMENTE implementado
Cuando los clientes se conectan a la infraestructura, sus “Clientes TLS” deben configurarse para requerir el uso de algoritmos seguros compatibles con FIPS. Si los servicios TLS del “Cliente TLS” y el  propietario de la infraestructura acuerdan un método de cifrado que es incompatible con FIPS, se utilizará una implementación de cifrado no validada.Las aplicaciones que creas y operas en la infraestructura de producción pueden incluir sus propias implementaciones criptográficas; Para que los datos que procesan estén protegidos con un módulo criptográfico validado por FIPS, debes integrar dicha implementación tú mismo.Se aplica en todas las conexiones
MUY RARAMENTE implementado
Las aplicaciones que creas y operas en la infraestructura de producción pueden incluir sus propias implementaciones criptográficas; Para que los datos que procesan estén protegidos con un módulo criptográfico validado por FIPS, debes integrar dicha implementación tú mismo.
Listo para usar
MUY RARAMENTE implementado


Entorno de Google Cloud y cifrado en reposo


Nivel CIO

TecnologíaGoogle Cloud ComputeImplementación local estándar
Google utiliza varias capas de cifrado para proteger los datos de los clientes en reposo en los productos de Google Cloud Platform.
Aplicado como estándar


RARAMENTE implementado
Google Cloud Platform encripta el contenido del cliente almacenado en reposo, sin que se requiera ninguna acción por parte del cliente, utilizando uno o más mecanismos de encriptación. Hay algunas excepciones menores, que se indican más adelante en este documento.
Aplicado como estándar
RARAMENTE implementado
Los datos para el almacenamiento se dividen en fragmentos y cada fragmento se cifra con una clave de cifrado de datos única. Estas claves de cifrado de datos se almacenan con los datos, cifrados con ("envueltas" por) claves de cifrado de claves  que se almacenan y utilizan exclusivamente dentro del servicio de administración de claves central de Google. El servicio de administración de claves de Google es redundante y está distribuido globalmente.
Realizado como estándar
MUY RARAMENTE implementado
Los datos almacenados en Google Cloud Platform se cifran en el nivel de almacenamiento mediante AES256 o AES128.
Realizado como estándar
MUY RARAMENTE implementado
Google usa una biblioteca criptográfica común, Tink, para implementar el cifrado de manera consistente en casi todos los productos de Google Cloud Platform. Debido a que esta biblioteca común es ampliamente accesible, solo un pequeño equipo de criptógrafos necesita implementar y mantener adecuadamente este código estrictamente controlado y revisado.
Realizado como estándar
MUY RARAMENTE implementado

Capas de cifrado

Google utiliza varias capas de cifrado para proteger los datos. El uso de múltiples capas de cifrado agrega protección de datos redundante y nos permite seleccionar el enfoque óptimo en función de los requisitos de la aplicación.


Cada fragmento se distribuye en los sistemas de almacenamiento de Google y se replica de forma cifrada para realizar copias de seguridad y recuperación ante desastres. Una persona malintencionada que quisiera acceder a los datos del cliente necesitaría saber y poder acceder 1) a todos los fragmentos de almacenamiento correspondientes a los datos que desea, y 2) las claves de cifrado correspondientes a los fragmentos.


Google utiliza el algoritmo Advanced Encryption Standard (AES) para cifrar los datos en reposo. AES se usa ampliamente porque 1) tanto AES256 como AES128 son recomendados por el Instituto Nacional de Estándares y Tecnología (NIST) para uso de almacenamiento a largo plazo (a partir de marzo de 2019), y 2) AES a menudo se incluye como parte de los requisitos de cumplimiento del cliente.

Los datos almacenados en Google Cloud Storage se cifran en el nivel de almacenamiento mediante AES, en Galois / Counter Mode (GCM) en casi todos los casos. Esto se implementa en la biblioteca BoringSSL que mantiene Google. Esta biblioteca se bifurcó de OpenSSL para uso interno, después de que se expusieran muchas fallas en OpenSSL. En casos seleccionados, AES se utiliza en el modo Cipher Block Chaining (CBC) con un código de autenticación de mensajes hash (HMAC) para la autenticación; y para algunos archivos replicados, AES se usa en modo Contador (CTR) con HMAC. (Más adelante en este documento se proporcionan más detalles sobre los algoritmos). En otros productos de Google Cloud Platform, AES se usa en una variedad de modos.

TecnologíaGoogle Cloud Compute
Implementación local estándar
Cifrado nativo de varias capas
Aplicado como estándar
MUY RARAMENTE realizado
Cifrado AES nativo con modo CTRAplicado como estándar
MUY RARAMENTE realizado
GCM nativo Aplicado como estándar
MUY RARAMENTE realizado
Cifrado en la capa del dispositivo de almacenamiento
Además del cifrado a nivel del sistema de almacenamiento descrito anteriormente, en la mayoría de los casos los datos también se cifran al nivel del dispositivo de almacenamiento, con al menos AES128 para discos duros (HDD) y AES256 para nuevas unidades de estado sólido (SSD), utilizando un dispositivo separado -clave de nivel (que es diferente a la clave utilizada para cifrar los datos en el nivel de almacenamiento). A medida que se reemplacen los dispositivos más antiguos, sólo se utilizará AES256 para el cifrado a nivel de dispositivo.

Cifrado de respaldo
El sistema de respaldo de Google asegura que los datos permanezcan encriptados durante todo el proceso de respaldo. Este enfoque evita exponer innecesariamente datos de texto sin formato.

Además, el sistema de respaldo encripta aún más cada archivo de respaldo de forma independiente con su propia clave de encriptación de datos (DEK), derivada de una clave almacenada en el Servicio de administración de claves (KMS) de Google más una semilla por archivo generada aleatoriamente en el momento del respaldo. Otro DEK se utiliza para todos los metadatos en las copias de seguridad, que también se almacena en el KMS de Google.

TecnologíaGoogle Cloud ComputeImplementación local estándar
Cifrado de flujo de respaldo sobre la marcha
Realizado como estándar
MUY RARAMENTE implementado
Cifrado de copia de seguridad del almacenamiento
Realizado como estándar
MUY RARAMENTE implementado
Gestión de claves por GCP

La clave utilizada para cifrar los datos en un fragmento se denomina clave de cifrado de datos (DEK). Debido al alto volumen de claves en Google y la necesidad de baja latencia y alta disponibilidad, estas claves se almacenan cerca de los datos que cifran. Las DEK se cifran con (o "envuelven") una clave de cifrado de claves (KEK). Existen una o más KEK para cada servicio de Google Cloud Platform. Estas KEK se almacenan de forma centralizada en el Servicio de administración de claves (KMS) de Google, un repositorio creado específicamente para almacenar claves. Tener un número menor de KEK que DEK y usar un servicio de administración de claves central hace que el almacenamiento y el cifrado de datos a escala de Google sea manejable, y nos permite rastrear y controlar el acceso a los datos desde un punto central.

Para cada cliente de Google Cloud Platform, los recursos no compartidos se dividen en fragmentos de datos y se cifran con claves independientes de las que se utilizan para otros clientes. Estas DEK están incluso separadas de las que protegen otras partes de los mismos datos que pertenecen al mismo cliente.

Los DEK son generados por el sistema de almacenamiento utilizando la biblioteca criptográfica común de Google. Luego se envían a KMS para que se envuelvan con la KEK de ese sistema de almacenamiento, y las DEK envueltas se devuelven al sistema de almacenamiento para guardarlas con los fragmentos de datos. Cuando un sistema de almacenamiento necesita recuperar datos cifrados, recupera el DEK empaquetado y lo pasa a KMS. Luego, KMS verifica que este servicio esté autorizado para usar la KEK y, de ser así, desenvuelve y devuelve la DEK en texto sin formato al servicio. Luego, el servicio usa la DEK para descifrar el fragmento de datos en texto sin formato y verificar su integridad.

La mayoría de las KEK para cifrar fragmentos de datos se generan dentro de KMS y el resto se genera dentro de los servicios de almacenamiento. Para mantener la coherencia, todas las KEK se generan utilizando la biblioteca criptográfica común de Google, utilizando un generador de números aleatorios (RNG) creado por Google. Este RNG se basa en NIST 800-90Ar1 CTR-DRBG y genera un KEK AES256. Este RNG proviene del RNG del kernel de Linux, que a su vez proviene de múltiples fuentes de entropía independientes. Esto incluye eventos entrópicos del entorno del centro de datos, como mediciones detalladas de búsquedas de disco y tiempos de llegada entre paquetes, y la instrucción RDRAND de Intel donde está disponible (en Ivy Bridge y CPU más nuevas).

os datos almacenados en Google Cloud Platform se cifran con DEK mediante AES256 o AES128, como se describe anteriormente; y todos los datos nuevos cifrados en discos persistentes en Google Compute Engine se cifran con AES256. Los DEK se envuelven con KEK mediante AES256 o AES128, según el servicio de Google Cloud Platform. Actualmente se está trabajando en actualizar todas las KEK para servicios en la nube a AES256.

El KMS de Google gestiona las KEK y se creó únicamente para este propósito. Fue diseñado pensando en la seguridad. Las KEK no se pueden exportar desde el KMS de Google por diseño; Todo el cifrado y descifrado con estas claves debe realizarse dentro de KMS. Esto ayuda a prevenir fugas y uso indebido, y permite que KMS emita una pista de auditoría cuando se utilizan claves.

TecnologíaGoogle Cloud ComputeImplementación local estándar
Integración KMSAplicado como estándar
MUY RARAMENTE implementado
AES256 KEK
Aplicado como estándar
MUY RARAMENTE realizado


Red y comunicación  

Beneficios del nivel premium

La propiedad total de la red de una ubicación a otra es algo que la mayoría de las empresas no pueden permitirse. Sin embargo, Google Cloud Compute es capaz de lograr la propiedad y el control completos de un extremo a otro.


TecnologíaGoogle Cloud ComputeImplementación local estándar
Propiedad completa de la red de extremo a extremo
Realizado como estándar
MUY RARAMENTE implementado
Más de 100 PoP en todo el mundo para ofrecer una amplia cobertura y redundancia / resiliencia de la redRealizado como estándar
MUY RARAMENTE implementado


Estabilidad operativa / serenidad / SLA   

Altos estándares a nivel de SLA

Google Cloud Compute se encuentra entre los pocos proveedores de Cloud capaces de  presumir de un SLA verificado superior al 99% en todos sus servicios
.

Servicio cubierto
Porcentaje de tiempo de actividad mensual
Instancias en varias zonas>= 99.99%
Una sola instancia
>= 99.5%
Balanceo de carga
>= 99.99%

Si Google no cumple con el Objetivo de nivel de servicio (SLO), y si el Cliente cumple con sus obligaciones en virtud de este SLA, el Cliente será elegible para recibir los Créditos financieros que se describen a continuación. Este SLA establece el recurso único y exclusivo del Cliente en caso de que Google no cumpla con el SLO. Los términos en mayúscula utilizados en este SLA, pero no definidos en este SLA, tienen el significado establecido en el Acuerdo. Si el Acuerdo autoriza la reventa o el suministro de Google Cloud Platform en virtud de un programa de revendedor o socio de Google Cloud, todas las referencias al Cliente en este SLA significan Socio o Revendedor (según corresponda), y cualquier Crédito financiero solo se aplicará a los afectados. Pedido (s) de socio o revendedor en virtud del Acuerdo.

Tecnología
Google Cloud Compute
Implementación local estándar
Implementación de instancia única / servidor 99.5% SLA (lo que significa 354,5 días de tiempo de actividad por año)
Realizado como estándar
RARAMENTE realizado
Implementación de múltiples instancias (balanceado de carga redundante) / servidor 99.5% SLA (lo que significa 364,96 días de tiempo de actividad por año)
Realizado como estándar
MUY RARAMENTE realizado
SLA de por vida
Realizado como estándar
MUY RARAMENTE realizado

Estándares de alta disponibilidad

Alcanzar los objetivos del 100% de disponibilidad implica que tu infraestructura sea capaz de alcanzar los siguientes estándares:

TecnologíaGoogle Cloud Compute
Implementación local estándar
Capacidad de hardware autogestionada
Realizado como estándar
RARAMENTE realizado
Escalabilidad automática
Realizado como estándar
MUY RARAMENTE realizado
Aprovisionamiento automatizado de recursosRealizado como estándar
MUY RARAMENTE realizado
Redundancia múltiple (almacenamiento)Realizado como estándar
MUY RARAMENTE realizado
Redundancia múltiple (instancias informáticas / servidores)
Realizado como estándar
MUY RARAMENTE realizado
Redundancia múltiple (fuentes de energía)Realizado como estándar
MUY RARAMENTE realizado
Redundancia múltiple (fuentes de energía)Realizado como estándar
MUY RARAMENTE realizado
Redundancia múltiple (almacenamiento)Realizado como estándar
MUY RARAMENTE realizado
Tecnología de equilibrio de carga
Realizado como estándar
MUY RARAMENTE realizado
Replicación de datos en tiempo real en almacenamiento pasivo (datos / archivos)
Realizado como estándar
MUY RARAMENTE realizado
Replicación de datos en tiempo real en almacenamiento dinámico (bases de datos)
Realizado como estándar
MUY RARAMENTE realizado


Port Cities - te ayudamos a seleccionar la solución de alojamiento más adecuada para tu negocio

Port Cities cooperates with the best cloud service providers in the world, including Google Cloud Platform, to make sure your ERP is accessible anytime, from anywhere. We also ensure our hosting solutions meet the most demanding criteria of your ERP system, in terms of security, capacity or operational stability. In any case,
En Port Cities cooperamos con los mejores proveedores de servicios en la nube del mundo, incluida Google Cloud Platform, para asegurarnos de que tu ERP sea accesible en cualquier momento y desde cualquier lugar. También nos aseguramos de que nuestras soluciones de hosting cumplan con los criterios más exigentes de tu sistema ERP, en términos de seguridad, capacidad o estabilidad operativa. En cualquier caso, nuestro equipo de servidores está listo para discutir contigo la solución de alojamiento de servidores más adecuada para tu negocio.
nuestro equipo de servidores está listo para discutir contigo the most suitable server hosting solution for your business. 

.

24 marzo, 2021
AUTOR
Por qué las empresas deberían alojar Odoo en la nube y sacar provecho de Google Cloud Platform
Denis Guillot
Group Technical Director
Denis is a technical expert with over 20 years of experience with ERP implementations. His specializations are in IT infrastructure, API integrations and high-volume transactions. He is the Director of Technology and oversees the Research & Development function at Port Cities.
Compartir

Want more free tips with Odoo?

Join our newsletter to stay updated!