Protege las cargas de trabajo de procesamiento

En este artículo, se explica cómo puedes tomar medidas para proteger tu canalización de procesamiento en Google Cloud. Puedes aprovechar las características de seguridad de Google Cloud, como los proyectos y la administración de identidades y accesos (IAM) para el control de acceso, la verificación automática de políticas, la encriptación, las subredes y las reglas de firewall. En este artículo, se explica cómo cumplir con el protocolo de seguridad que exigen los grandes estudios cinematográficos.

En la siguiente imagen, se muestra una arquitectura de procesamiento híbrida a modo de referencia:

Diagrama de una arquitectura de procesamiento híbrida

Haz clic para obtener una versión más grande.

Proyectos y acceso

Los proyectos son un componente organizativo principal de Google Cloud. Los proyectos proporcionan una agrupación abstracta que puedes usar para asociar recursos con un departamento, una aplicación o un equipo funcional en particular. Todos los recursos de Google Cloud, como las instancias de Compute Engine y los depósitos de Cloud Storage, pertenecen a un proyecto. Puedes administrar proyectos mediante Google Cloud Console y la API de Resource Manager. La API de IAM incluye un conjunto de métodos para administrar los permisos de un proyecto a través de la API de Resource Manager.

Usa los proyectos para controlar el acceso a recursos

Los proyectos proporcionan un límite de aislamiento para los datos de red y la administración del proyecto. Sin embargo, puedes otorgar interconexiones de forma explícita entre los recursos de Google Cloud que usa tu organización o entre otros proyectos dentro de esta. Puedes otorgar distintas funciones a los usuarios y los grupos, como viewer, editor y owner, para distintos proyectos. Para asignar funciones, puedes usar la página de IAM y la de administrador en Cloud Console o la API de IAM.

Además, puedes delegar el control a alguien que tenga acceso a un proyecto en particular. Los usuarios con la función owner pueden otorgar y revocar el acceso a usuarios, grupos y cuentas de servicio.

En la siguiente imagen, se muestra un ejemplo de una jerarquía de recursos de Google Cloud:

diagrama de la estructura de un proyecto

Otorga acceso

Si tu organización implementó Google Workspace, puedes otorgar acceso a un proyecto de Google Cloud a cualquier usuario o grupo en tu organización. Si administras tus identidades fuera de Google Workspace, también puedes establecer credenciales de usuario basadas en tu propio servidor LDAP, incluso Microsoft Active Directory, mediante Google Cloud Directory Sync.

También puedes conceder a cualquier usuario de una organización acceso a un proyecto o recurso si lo agregas a un Grupo de Google que tenga acceso a ese proyecto o recurso. Los grupos te permiten otorgar rápidamente acceso a terceros, como contratistas o trabajadores autónomos. Tal vez tu organización no quiera permitir este grado de flexibilidad, lo que dependerá de tus políticas de seguridad. Puedes usar la API de Cloud para compilar una funcionalidad de supervisión que verifique que no haya asignaciones contrarias a la política y que active alertas o las revoque de manera automática.

Accede a través del SDK y la API

Si accedes a Google Cloud a través del SDK de gcloud o gsutil, debes autenticarte cuando te conectes a la API de Google Cloud. Solo debes hacerlo una vez por entorno de usuario local.

Si tus aplicaciones o secuencias de comandos acceden a Google Cloud mediante bibliotecas cliente de la API, primero debes autenticarte a través del SDK. Luego, las bibliotecas cliente de la API detectan las credenciales creadas.

Identifica proyectos

Cada proyecto tiene un ID del proyecto universalmente único, que es una string breve de letras minúsculas, dígitos y guiones. Cuando creas un proyecto, especificas tu propio nombre del proyecto. El ID del proyecto se basa en este nombre, al que se le agregan números para que sea único a nivel global. Puedes anular el ID del proyecto asignado, pero el nombre debe ser único a nivel global.

A tu proyecto también se le asigna un número de proyecto aleatorio largo y único a nivel global, que se genera automáticamente. Los ID de proyectos pueden tener entre 6 y 30 caracteres, mientras que los nombres de proyectos puede tener entre 4 y 30.

Después de la creación del proyecto, el ID y el número del proyecto no cambian, aunque se cambie el nombre del proyecto.

Te recomendamos dedicar un tiempo a la planificación de los nombres de tus proyectos, para garantizar que puedan administrarse mejor. Los proyectos nombrados de forma adecuada pueden ordenarse correctamente y reducen la confusión.

En una convención típica de asignación de nombres de proyectos, se podría seguir este patrón:

[studio]-[project]-[role (rnd, dev, prod)]

Un nombre de archivo resultante podría ser, por ejemplo, mystudio-myproject-rnd.

Automatiza los controles de seguridad

Policy Scanner proporciona un marco de trabajo para llevar a cabo controles de seguridad automatizados en tu proyecto, lo que contribuye a garantizar que las políticas estén configuradas de forma correcta. Los proyectos analizados que se desvíen de una política identificada como buena se etiquetan, y recibes una alerta sobre los problemas. Puedes ejecutar Policy Scanner a pedido o configurarlo de modo que se ejecute según un programa diario o semanal.

Controlar el acceso de los usuarios

No todos los miembros de un proyecto deberían tener acceso libre a todas las instancias en ejecución, los servicios y los datos almacenados. En una canalización de procesamiento, los permisos de usuario se suelen controlar de forma local mediante una configuración de permisos a nivel del SO, en conjunto con un servicio de directorio, como LDAP o Active Directory.

A diferencia de una canalización de procesamiento típica, la mayor parte de los artistas no necesitan ningún acceso al proyecto, pues la mayoría de las tareas basadas en la nube, como la sincronización de activos, el procesamiento y la escritura o copia de datos, se realizan mediante el software de administración de colas que opera en una Cuenta de servicio.

Si implementas el principio del menor privilegio tanto localmente como en la nube, puedes limitar el acceso de los usuarios solo a las áreas del proyecto o a la información que sean necesarias para realizar tareas específicas según su función.

A diferencia de las cargas de trabajo basadas en la Web, las canalizaciones de procesamiento suelen requerir acceso directo a las instancias en ejecución, por ejemplo, para solucionar un problema de procesamiento en un tipo de instancia determinado. Puedes acceder a una instancia mediante una API, como el comando de gcloud, o bien puedes acceder mediante SSH si estableciste pares de llaves SSH para conectarte directamente a una instancia.

Otorga acceso directo solo a los administradores del sistema y a otras funciones responsables de administrar procesamientos o solucionar problemas en ellos. El acceso directo es indispensable para las siguientes tareas:

  • Depurar trabajos o solucionar errores en estos
  • Procesar el control del administrador de colas en el inicio y cierre de instancias
  • Otorgar acceso mediante un mecanismo de registros o un software que realice un seguimiento del uso de memoria o de CPU
  • Realizar tareas que se ejecutan durante el trabajo en sí

Es importante distinguir entre los permisos del usuario en IAM y los que se configuran a nivel del SO en una instancia en ejecución. Aunque trabajan en conjunto para proporcionar un perfil de usuario completo, los dos sistemas tienen finalidades diferentes, y se crean y modifican mediante mecanismos distintos.

IAM no administra SSH o el acceso de usuarios a instancias individuales. El acceso se controla mediante los permisos del usuario a nivel del SO, que pueden sincronizarse con IAM. Otorgar permisos de IAM a un usuario o una cuenta de servicio no cambia la forma en que los usuarios acceden a instancias o sus permisos una vez que han accedido. Los dos sistemas están diseñados para ser complementarios: IAM se usa para otorgar acceso a los recursos de Google Cloud, como la consola o la API, y el acceso directo se aprovisiona solo para los usuarios que lo necesitan.

Si compilas una imagen personalizada, puedes habilitar o inhabilitar el acceso SSH; para ello, modifica el ssh y los daemons de cuentas de Google en el disco de arranque. A modo de guía, investiga las características de seguridad que ya están incorporadas a tus imágenes públicas.

IAM

Para administrar los recursos de Google Cloud, IAM te permite crear y administrar permisos a nivel de la organización, del proyecto y de los recursos. IAM unifica el control de acceso para los servicios de Google Cloud en un solo sistema y presenta un conjunto de operaciones coherente.

Funciones de IAM y grupos

Hay tres funciones básicas de IAM: owner, editor y viewer.

Propietario: Solo un grupo reducido de personas de confianza en una instalación o proyecto debería tener privilegios de nivel de propietario del proyecto, como los miembros del departamento de TI, los administradores del sistema o los administradores de producción. Los propietarios del proyecto pueden cambiar todo, desde las cuentas de facturación hasta el nivel de acceso de otros usuarios, por lo que esta función debe asignarse con sumo cuidado.

Puedes crear un proyecto con uno o más propietarios. La función de Administrador de la organización puede mantener estos propietarios a nivel de la organización. Esta función de administrador puede crear proyectos, modificar la facturación del proyecto y asignar roles, todo esto sin dar acceso de nivel de propietario a ningún proyecto individual.

Los administradores de la organización reciben la mayor parte de las notificaciones de todos los proyectos de la organización, aunque, de forma intencional, algunas notificaciones solo se envían a los propietarios del proyecto.

Editor: Un editor del proyecto puede realizar acciones que modifican el estado, como leer y escribir datos del proyecto, iniciar y cerrar instancias, o leer y escribir metadatos del proyecto en todos los recursos del proyecto.

Lector: Esta función de solo lectura puede no ser útil en todas las canalizaciones, pero tal vez quieras asignarla a algunas cuentas de servicio que supervisan y acceden a sistemas externos. Por ejemplo, los sistemas de revisión diaria que leen imágenes o videos, o las API que se comunican con los sistemas de administración de proyectos, como Shotgun.

Funciones predefinidas: Hay varias funciones predefinidas que limitan el acceso de los usuarios o las cuentas de servicio a ciertas tareas específicas. Estas funciones, por ejemplo, contribuyen a garantizar que un artista no tenga acceso a los datos de facturación de una producción, o que un asistente de producción no pueda borrar una instancia en ejecución.

Usar la jerarquía de recursos para el control de acceso

Puedes configurar políticas de IAM en distintos niveles de la jerarquía de recursos. Los recursos heredan las políticas del recurso superior. Esto te permite reflejar la estructura de la jerarquía de tus políticas de IAM en la estructura de la organización. Te aconsejamos seguir este conjunto de prácticas recomendadas para implementar jerarquías de recursos.

Inhabilita las funciones sin uso

Existen ciertas funciones que se habilitan de forma predeterminada y están disponibles para su asignación por parte de los creadores/propietarios del proyecto. A fin de reducir la confusión, tal vez quieras inhabilitar las funciones que no resulten aplicables a tu flujo de trabajo puntual. No puedes hacerlo por proyecto, sino que debe establecerse en la configuración de tu organización.

Controlar el acceso SSH a las instancias

Para garantizar que las personas indicadas tengan acceso a los recursos, se requiere lo siguiente:

  • La sincronización entre IAM y tu servicio de directorio mediante Google Cloud Directory Sync. Esto contribuye a garantizar que tengas una lista idéntica de usuarios con sus respectivos permisos almacenada localmente y en la nube
  • Mecanismos de autenticación de usuarios para el acceso SSH a las instancias, por ejemplo, el módulo de Linux PAM vinculado con LDAP

En el caso de las cargas de trabajo de procesamiento, te recomendamos limitar el acceso SSH a un grupo selecto de usuarios, como los miembros del departamento de TI, los administradores del sistema o los administradores de procesamiento.

Los trabajos que un administrador de colas envía a la nube suelen ser propiedad de un usuario de procesamiento dedicado o un daemon. Por ejemplo, de forma predeterminada, los trabajos de procesamiento de Qube! se ejecutan como un usuario “qubeproxy”. Te recomendamos cambiar esta configuración de Qube para que se ejecuten como el usuario que inició el trabajo, que Qube llama “modo de usuario”. De esta forma, se ejecutan todos los procesos del usuario que inició el trabajo. Los procesamientos completados mantienen esta propiedad.

Deberías configurar tu imagen de inicio de la misma forma en que configurarías cualquier trabajador de procesamiento local, de modo que la autenticación se realice mediante los mismos protocolos que para tus trabajadores de procesamiento locales.

Cuentas de servicio

Una cuenta de servicio es una Cuenta de Google especial que puede usarse para acceder a servicios de Google y a recursos de manera programática.

En el caso de las canalizaciones de procesamiento, las cuentas de servicio son útiles para controlar cómo se implementan o se cierran las instancias, y cómo se asignan y ejecutan los trabajos en las instancias. Tu software de procesamiento en cola iniciará instancias en Google Cloud mediante el uso de credenciales de cuentas de servicio, lo que permite que los trabajos se inicien en la instancia nueva.

Cuando se crea un proyecto nuevo, se crean varias cuentas de servicio predeterminadas. Te recomendamos mantener solo la cuenta de servicio llamada Compute Engine default service account, así como cualquier cuenta de servicio que use tu software de cola para iniciar instancias. Ten cuidado cuando borres cuentas de servicio, pues esto puede quitar el acceso a algunos recursos del proyecto.

También puedes optar por tener cuentas de servicio separadas para las tareas de canalización individuales destinadas a ejecutar eventos basados en programas. A estas cuentas de servicio se les asignaría una función de IAM según el alcance necesario. Por ejemplo:

  • Implementación de instancias por parte del administrador de colas de procesamiento: La cuenta de servicio principal para ejecutar trabajos de procesamiento en Google Cloud. A esta cuenta de servicio se le asignarían las funciones compute.instanceAdmin y iam.serviceAccountActor.
  • Administrador de recursos: Una cuenta de servicio destinada a publicar y recuperar recursos, o a administrar bases de datos. Si usas Cloud Storage, se asignará la función storage.admin a esta cuenta de servicio.
  • Agente de Logging: Una cuenta de servicio que usa específicamente el mecanismo de registro de proyecto, como Cloud Logging. A esta cuenta de servicio se le asignaría la función logging.logWriter.

Permisos de acceso

Los alcances del acceso son el método heredado de especificar permisos para una instancia. Estos permisos se aplican a cualquier usuario en la instancia. A su vez, estos otorgan permisos predeterminados de una instancia a las API de Google. Se accede a recursos como Compute Engine y Cloud Storage a través de estas API.

En lugar de otorgar permisos predeterminados a todos los usuarios de una instancia, puedes usar las funciones de IAM en conjunto con permisos de acceso para otorgar permiso a un usuario o cuenta de servicio.

Especifica la marca --no-scopes para evitar que se apliquen los permisos predeterminados cuando se crea una instancia. Si no se especifica --no-scopes ni tampoco permisos con la marca --scope, se aplicará un conjunto de permisos predeterminado a tu instancia.

De forma predeterminada, las instancias comienzan con un conjunto de permisos, la mayoría de los cuales son necesarios para acceder a las cuentas de usuario de IAM, leer desde los depósitos de Cloud Storage y escribir registros con la API de Cloud Logging.

Cuando creas una instancia nueva, se otorgan los siguientes permisos a la instancia:

Alcance

Tarea de API

read only

Este permiso impide que los usuarios de la instancia escriban en un depósito de Cloud Storage mediante la API de Compute Engine.

logging.write

Permite el acceso de escritura de la instancia a los registros de Compute Engine con la API de Cloud Logging (v2).

monitoring.write

Permite que la instancia publique datos de métricas en tus proyectos de Google Cloud con la API de Cloud Monitoring (v3).

servicecontrol

Permite que la instancia administre tus datos de Control de servicios de Google mediante la API de Control de servicios.

service.management.readonly

Permite que la instancia publique datos de métricas en tus proyectos de Google Cloud con la API de Cloud Monitoring (v3).

trace.append

Permite que la instancia recopile y escriba datos de latencia de un proyecto o aplicación mediante la API de Stackdriver Trace.

El conjunto predeterminado de permisos, por ejemplo, no permite que las instancias escriban en depósitos de Cloud Storage. Si tu canalización de procesamiento requiere que las instancias escriban procesamientos terminados en Cloud Storage, agrega el permiso storage-rw antes de iniciar instancias de trabajador de solo procesamiento. Sin embargo, ten en cuenta que esta acción permite que los usuarios copien los datos de la instancia, así que no agregues este permiso en instancias con acceso a datos sensibles.

Administración de claves de encriptación

Cloud Storage

Todos los datos del proyecto (así como todos los datos en Google Cloud) se encriptan en reposo mediante la encriptación AES128 o AES256. También puedes optar por proporcionar tus propias claves de encriptación para Cloud Storage y los discos de Compute Engine.

Cloud Storage siempre encripta tus datos del lado del servidor antes de escribirlos en el disco. De forma predeterminada, Cloud Storage usa sus propias claves del lado del servidor para encriptar datos. Los datos se encriptan con un alto nivel de detalle y mediante una clave de encriptación de datos (DEK), la cual también se encripta mediante una clave de encriptación de claves (KEK). Las KEK se administran en un servicio de administración de claves central y se comparten con otros servicios de Google, como Gmail.

Para desencriptar un fragmento de datos, el servicio de almacenamiento llama al servicio de administración de claves interno de Google a fin de recuperar la clave de encriptación de datos (DEK) separada que le corresponde a ese fragmento de datos:

image

Ten en cuenta que también puedes elegir que Cloud KMS administre tus claves de encriptación de claves.

Si bien a menudo nos referimos a una sola clave, en realidad significa que los datos están protegidos con un conjunto de claves: una clave activa para la encriptación y un conjunto de claves históricas para la desencriptación, cuya cantidad depende del programa de rotación de claves.

De forma alternativa, puedes proporcionar tus propias claves de encriptación y usarlas en Cloud Storage y en discos persistentes de Compute Engine, pero, a no ser que ya tengas un servicio de administración de claves local, recomendamos que permitas que Google administre y rote tus claves de datos de almacenamiento, las que Google rota cada 90 días.

Cloud KMS es un servicio de Google Cloud que te permite mantener las claves de encriptación de forma centralizada en la nube para su uso directo por parte de los servicios en la nube. Por el momento, no hay integraciones de capas de almacenamiento para encriptar los datos almacenados en otros servicios de Google Cloud.

Te recomendamos configurar un proyecto centralizado separado para ejecutar Cloud KMS en todos tus proyectos.

Cuentas de servicio

Cuando creas una cuenta de servicio, se genera automáticamente un par de claves públicas/privadas específico de esa cuenta. Google mantiene la clave pública, pero deberás administrar la clave privada. Esta clave privada es necesaria para autenticar la cuenta de servicio cuando ejecuta tareas en Google Cloud.

Seguridad de red

Todas las instancias de procesamiento se crean como miembros de Cloud Virtual Network. De forma predeterminada, todas las redes son redes de subred automática en las que las subredes regionales se crean automáticamente. Cada red está limitada a un único proyecto; no puede existir más de un proyecto en la misma red. Solo los usuarios con las funciones específicas de Propietarios del proyecto, Administradores de la organización o Administradores de redes de Compute pueden cambiar las propiedades de la red.

Redes y subredes

Puedes aislar los recursos en redes separadas para agregar un nivel de seguridad adicional. Por ejemplo, una secuencia de tomas de contenido altamente confidencial puede procesarse solo dentro de una red separada, de forma aislada del resto de los datos del proyecto. Los proyectos individuales pueden ser una forma aún más efectiva de separar los datos.

Cuando creas un proyecto nuevo, debido a la característica de subred automática, se crean múltiples subredes, una para cada región de Compute Engine. Cuando inicias una instancia nueva en una región específica, se coloca en la subred de esa región y se le asigna una IP interna dentro de esa subred.

Reglas de firewall

Cada red tiene un firewall que bloquea todo el tráfico a las instancias. Para permitir el tráfico entrante, debes crear reglas de firewall del tipo “allow”.

La red etiquetada como default en cada proyecto tiene reglas de firewall predeterminadas, como se muestra a continuación. Ningún tipo de red creada de forma manual tiene reglas de firewall. Para todas las redes, excepto la predeterminada, debes crear las reglas de firewall que necesites.

No todas estas reglas predeterminadas son necesarias para una canalización de procesamiento:

Regla

Nota

Recomendación

default-allow-internal

Necesaria para permitir la comunicación entre las instancias. Si tu administrador de colas es local, es probable que las instancias no necesiten comunicarse entre sí.

Borra esta regla si tus instancias no necesitan comunicarse con otras.

default-allow-ssh

Utilizada para permitir el acceso a través de SSH por el puerto 22.

Borra esta regla y crea una similar que solo permita SSH a través de una VPN o una IP conocida.

default-allow-rdp

Solo es necesaria si quieres acceder a las instancias con el Protocolo de escritorio remoto (RDP) por el puerto 3389. En la mayor parte de los casos, el acceso SSH es suficiente, por lo que puedes borrar esta regla.

Borra esta regla, a menos que uses máquinas que ejecutan Windows.

default-allow-icmp

Permite la comunicación de información operativa o de errores en toda la red. Esta regla permite el acceso a través de cualquier IP.

Borra esta regla y crea una similar que solo permita ICMP de direcciones IP conocidas.

Las reglas de firewall, de forma predeterminada, se aplican a toda la red. Si deseas que dos subredes intercambien tráfico, debes configurar los permisos allow en ambas direcciones.

Tal vez quieras incorporar etiquetas de instancia en la canalización para permitir el acceso a tipos de instancias específicos con una regla de firewall. Por ejemplo, puedes etiquetar todas las instancias de procesamiento para permitir el acceso SSH a fin de solucionar problemas por parte de determinadas funciones. Las instancias que no tengan esta etiqueta impiden de forma automática el acceso SSH, como a tu servidor de licencias.

Si no se especifican sourceRanges ni sourceTags cuando se crea una regla de firewall, el sourceRange predeterminado será 0.0.0.0/0, por lo que la regla se aplicará a todo el tráfico entrante dentro y fuera de la red.

Si no se especifica ningún puerto cuando se crea una regla de firewall de TCP o UDP, se permitirán las conexiones de todos los puertos.

Rutas de redes

Todas las redes tienen rutas creadas de forma automática hacia la Internet pública y hacia los rangos de IP de la red. El tráfico saliente no se bloquea de forma predeterminada. Solo las instancias con una dirección IP externa y una ruta de puerta de enlace de Internet predeterminada pueden enviar paquetes fuera de la red.

Solo se puede acceder a las API de Google Cloud (por ejemplo, gcloud y gsutil) a través de IP públicas, por lo que debes conservar la ruta de puerta de enlace de Internet predeterminada en Herramientas de redes > Rutas.

Inhabilita direcciones IP externas

Por motivos de seguridad, recomendamos que las instancias no tengan una dirección IP externa. De forma predeterminada, se asigna una dirección IP externa a todas las instancias cuando se inician. Para evitar esto, puedes iniciar las instancias con la marca --no-address.

Para que el administrador de colas de procesamiento controle tus instancias sin una dirección IP externa, debes implementar una Cloud VPN. La puerta de enlace de VPN es el único recurso en tu red con una dirección IP externa, a menos que agregues un Cloud Router, que usa el protocolo de puerta de enlace fronteriza (BGP) para transmitir rangos de IP privados entre tu red local y tus redes de Google Cloud.

Imágenes de disco

En una canalización de efectos visuales, te recomendamos usar un proyecto separado a nivel de la organización para la administración de imágenes. De este modo, se evita la modificación de plantillas de imágenes predeterminadas de toda la instalación, que pueden estar en uso activo en todos los proyectos. También se contribuye a la organización de imágenes de inicio en una ubicación centralizada, accesible desde todos los otros proyectos, si hay una asignación de funciones adecuada.

Puedes usar las funciones de IAM para compartir imágenes entre distintos proyectos. Consulta Compartir imágenes entre proyectos para obtener más información.

Imágenes públicas

Compute Engine ofrece numerosas imágenes públicas preconfiguradas compatibles con los sistemas operativos Linux y Windows. Cada imagen de SO se configura para que incluya ciertos paquetes, como el SDK de Cloud, o que tenga ciertos servicios habilitados, como SSH.

Estas imágenes también incluyen una colección de paquetes que configuran y administran las cuentas de usuario, además de habilitar la autenticación basada en las llaves SSH.

Imágenes personalizadas

Puedes crear tu propia imagen de disco personalizada a partir de una imagen existente. Aconsejamos que las imágenes cumplan con estas prácticas recomendadas de seguridad.

Te recomendamos instalar el Entorno invitado de Linux para Google Compute Engine a fin de acceder a la funcionalidad disponible de forma predeterminada en las imágenes públicas. Si instalas el entorno invitado, podrás realizar tareas con los mismos controles de seguridad de las imágenes públicas en tu imagen personalizada, como el acceso a metadatos, la configuración del sistema y la optimización del SO para su uso en Google Cloud.

Conectividad

Hay varias maneras de conectarte a Google desde tus instalaciones. En todos los casos, debes implementar una red privada virtual (VPN). Algunos métodos requieren configuración adicional, como se describe a continuación, a fin de contribuir a garantizar la transmisión segura de tus datos.

Algunos de los métodos de seguridad que se aplican a tus datos son los siguientes:

  • Encriptación de los vínculos de datos a Google mediante TLS con un certificado de 2048 bits generado por la autoridad certificada de Google
  • Encriptación de los datos cuando se trasladan entre nuestros centros de datos, en nuestra red privada
  • Actualización de todos los certificados RSA a claves de 2048 bits, lo que refuerza aún más nuestra encriptación en tránsito para Google Cloud y todos los demás servicios de Google
  • Uso de la confidencialidad directa total (PFS), lo que contribuye a minimizar el efecto de una clave comprometida o de una ruptura criptográfica

Conéctate a través de Internet

Puedes conectarte a la red de Google y aprovechar nuestro modelo de seguridad de extremo a extremo con solo acceder a los servicios de Google Cloud a través de Internet. Cuando se trasladan a través de túneles VPN, los datos están protegidos mediante protocolos autenticados y encriptados.

Intercambio de tráfico directo

Google aloja una infraestructura de redes perimetrales en más de 100 instalaciones de puntos de presencia en todo el mundo, a los que los clientes de Google Cloud pueden conectarse directamente. Todos los clientes de Google Cloud que tengan un ASN público y un prefijo de IP enrutable de forma pública pueden intercambiar el tráfico con Google. Para esta opción, se usa el mismo modelo de interconexión que la Internet pública.

Cloud Interconnect

En el caso de los clientes que no tengan ASN públicos, o que quieran conectarse a Google mediante un proveedor de servicios, el servicio de Cloud Interconnect puede ser una opción. Cloud Interconnect está destinado a clientes que quieran conectividad de calidad empresarial con la red perimetral de Google. Los proveedores de servicios asociados con Cloud Interconnect contribuyen a entregar conectividad de calidad empresarial en una de las dos maneras siguientes:

  • En conexiones de intercambio de tráfico existentes, cuya capacidad se administra de forma conjunta para garantizar un rendimiento alto y una latencia baja
  • En interconexiones dedicadas que tienen como objetivo llevar solo el tráfico de clientes de Google Cloud (aunque Google anuncia rutas para todos los servicios a través de estos vínculos)

Cloud VPN

Las canalizaciones de procesamiento locales no siempre encriptan los datos en tránsito. Sin embargo, en el caso de una canalización de procesamiento de nube híbrida, recomendamos que se encripten todos los datos en tránsito.

Sin importar cómo te conectes a Google, debes proteger tu conexión con una VPN. Cloud VPN conecta tu puerta de enlace de VPN de intercambio de tráfico con tu red de Google Cloud mediante una conexión de VPN IPsec. Una puerta de enlace de VPN encripta el tráfico que se traslada entre las dos redes; luego, la otra puerta de enlace de VPN lo desencripta. Esto contribuye a proteger tus datos cuando se trasladan por Internet, y no requiere que se implemente la encriptación de datos como parte de la canalización de procesamiento.

Si tu instalación tiene varias ubicaciones o redes, puedes mantener las rutas sincronizadas entre estas ubicaciones y tu Cloud VPN mediante un Cloud Router.

VPN proporcionada por el cliente

Puedes configurar tu propia puerta de enlace de VPN en Google Cloud, pero es mejor usar Cloud VPN para obtener una mayor flexibilidad y una mejor integración con Google Cloud.

Sistemas de archivos

Hay varias opciones de servidores de archivos disponibles para administrar tus datos. Según tu metodología de canalización, tal vez quieras implementar más de una.

Servidores basados en el objeto

Cloud Storage es un almacenamiento de objetos unificado. Es adecuado para almacenar todos los datos generados o consumidos en la canalización de procesamiento. Debido a que es parte de Google Cloud, Cloud Storage puede aprovechar las características de seguridad de Google Cloud, como el control de acceso, la IAM y la encriptación.

Cuando la ubicación en la que creas un depósito es una región, los principales con los permisos adecuados pueden acceder a los datos dentro del depósito, pero los datos se almacenan dentro de un centro de datos específico. Desde el punto de vista del rendimiento, es mejor conservar el almacenamiento y el procesamiento en la misma región para obtener una capacidad de procesamiento más alta y una latencia más baja.

Los datos en Cloud Storage están disponibles a nivel global, por lo que puedes compartir datos con otra instalación en otra parte del mundo sin requerir replicación. Esto podría representar cargos de salida adicionales. Debido a que estos datos son accesibles a nivel mundial, es esencial que administres los permisos de VM, los usuarios y las claves de acceso de forma adecuada a fin de evitar que los datos se escapen de la canalización de procesamiento.

Tal vez necesites adaptar tu canalización de administración de recursos para que se conecte con la arquitectura basada en objetos de Cloud Storage.

Servidores que cumplen con POSIX

Los datos de producción en vivo suelen almacenarse en un servidor de archivos que cumple con POSIX, lo que puede ser adecuado para las canalizaciones de procesamiento que requieran acceso a metadatos de archivos, como la fecha y hora de modificación, o que se basen en rutas de acceso de archivos para los recursos de escena.

Según las necesidades y la carga de trabajo de tu instalación, tienes varias opciones cuando implementas un sistema de archivos NFS.

Servidor de archivos de nodo único

Un servidor NFS que cumple con POSIX está disponible como una solución de implementación en un clic. Puedes ejecutar varios servidores de archivos de nodo único y activarlos en tu instancia. Esto significa que puedes aislar almacenamiento para cada parte de tu canalización, y de este modo restringir el acceso a nivel del usuario del sistema operativo y del grupo de la misma forma que con los sistemas de archivos locales.

También puedes contribuir a proteger los datos en servidores de archivos de nodo único si los activas como solo lectura en tus instancias de procesamiento. El software, las herramientas de canalización y las bibliotecas de elementos nunca deberían modificarse desde una instancia de procesamiento, por lo que activarlos como solo lectura es una forma sencilla de aplicar esta restricción.

Para contribuir a proteger tu proyecto aún más, también puedes implementar un sistema de archivos de nodo único por red, debido a que las instancias solo pueden activar servidores de archivos en la misma red.

También puedes crear instantáneas de tu software o disco de canalización de modo que la reversión a versiones anteriores se realice con rapidez y con un impacto mínimo en la producción.

Otros sistemas de archivos

Hay otros sistemas de archivos de terceros disponibles para usar con Google Cloud, como los sistemas de archivos de almacenamiento en caché y en clústeres. Consulta la documentación de cumplimiento de cada proveedor individual con respecto a la seguridad en sistemas de archivos de almacenamiento en caché de terceros.

Seguridad de almacenamiento

De forma predeterminada, Cloud Storage administra las claves de encriptación del servidor por ti mediante los mismos sistemas de administración de claves endurecidos que usamos para nuestros datos encriptados, que incluyen controles estrictos de acceso a claves y auditorías. Cloud Storage encripta el contenido de los usuarios en reposo, y cada clave de encriptación está encriptada con un conjunto de claves raíz que se rotan con regularidad.

Todas las clases de almacenamiento son compatibles con los mismos controles de acceso detallados y OAuth para proteger tus datos.

Te recomendamos usar IAM para restringir quién tiene acceso a los datos dentro de los depósitos de Cloud Storage o un proyecto. También puedes aprovechar las listas de control de acceso si necesitas administrar solo una cantidad pequeña de objetos.

Opciones de transferencia

La seguridad de los datos en tránsito se refiere a la seguridad de tus datos cuando entran y salen de tu almacenamiento local hacia la nube. Hay muchas metodologías de canalización que contribuyen a administrar el movimiento de datos entre el sistema local y la nube, cuyo diseño y cuya implementación están fuera del alcance de este documento. Todos los métodos de transferencia que se describen a continuación (excepto los métodos de transferencia de terceros) se ejecutan dentro del paquete de seguridad completo de Google para la autenticación y la autorización.

Línea de comandos

Para transferir datos hacia Cloud Storage o desde este, recomendamos usar el comando de gsutil a fin de copiar, mover o sincronizar datos con un tamaño inferior a 10 TB. Con el comando de gsutil, se usan las mismas características de seguridad y autenticación que en Google Cloud, se respetan las funciones de IAM y se realizan todas las operaciones mediante el uso de la encriptación de la capa de transporte (HTTPS). gsutil también admite cargas paralelas.

Para transferir desde sistemas de archivos que cumplen con POSIX o hacia ellos, como es el caso de los servidores de archivos de nodo único y Persistent Disk, te recomendamos usar scp o rsync en una conexión de VPN.

UDP

Si eliges usar a un tercero, haz lo siguiente:Protocolo de transferencia de datos basado en UDP para subir datos directamente a un bucket de Cloud Storage, como Aspera, Cloud FastPath, BitSpeed o FDT, consulta la documentación del tercero para obtener información sobre su modelo de seguridad y prácticas recomendadas. Estos servicios de terceros no están administrados por Google.

Cloud Logging

Cloud Logging te permite supervisar y registrar una variedad de actividades dentro de la organización o el proyecto. Originalmente, Cloud Logging se escribió para aplicaciones y servicios web, pero se puede usar como un servidor de registro para una canalización de procesamiento, lo que proporciona un punto de recopilación para la gran cantidad de datos que generan los procesamientos de la línea de comandos.

La API de Cloud Logging no está habilitada de forma predeterminada en los proyectos nuevos de Google Cloud. Recomendamos habilitar la API de Cloud Logging, a fin de que este pueda actuar como un servidor de registro para aplicaciones externas.

El registro de auditoría te permite realizar un seguimiento de la actividad administrativa mediante la consola o la API para modificar la configuración o los metadatos de un servicio o un proyecto. No puedes modificar o borrar los registros de auditoría.

Todos los registros se conservan por un período determinado y, luego, se borran. En la política de cuotas de Cloud Logging se explica por cuánto tiempo se conservan las entradas de registro. Para conservar registros una vez vencido el período de retención, puedes exportarlos a un depósito de Cloud Storage, un conjunto de datos de BigQuery, un tema de Cloud Pub/Sub o una combinación de los tres.

Los registros se recopilan de instancias individuales mediante el agente de Logging, que no se instala de forma predeterminada. Puedes encontrar las instrucciones de instalación aquí.

Otras consideraciones

En esta sección, se tratan temas que no están dentro de la línea de productos de Google, pero que suelen formar parte de una canalización de procesamiento híbrida.

Administración de colas

En muchos estudios se usa un administrador de colas para controlar la implementación, el seguimiento y las tareas implementadas en una granja de procesamiento local. A veces, puedes usar el mismo administrador de colas para implementar trabajos en Google Cloud. El enfoque específico puede variar según el software.

Algunos administradores de colas proporcionan complementos de software para permitir que los servidores y los clientes se conecten a Google Cloud. Consulta la documentación de terceros para revisar sus prácticas de seguridad.

Las instrucciones que envía el administrador de colas a Google Cloud deben emitirse con el comando de gcloud. Si necesitas enviar comandos mediante ssh,, debes generar una llave SSH para la comunicación. A fin de evitar esto, considera ejecutar tu servidor de administración de colas en Google Cloud, en lugar de hacerlo de forma local.

Automatiza la creación y la finalización de instancias

En algunos casos, querrás automatizar la creación de instancias cuando se inicia un trabajo y la terminación de la instancia cuando el trabajo finaliza correctamente. Deberías evitar mantener instancias en ejecución mientras no se ejecuta un trabajo por razones de costo y de seguridad.

Software personalizado

Las canalizaciones de procesamiento suelen incluir software de terceros y software personalizado. Este último puede ser de todo tipo, desde secuencias de comando simples hasta objetos binarios compilados de gran complejidad y con múltiples dependencias.

A fin de manipular las instancias de Google Cloud dentro de las secuencias de comandos o de los programas, usa las bibliotecas cliente disponibles. Cada versión provee métodos para la autorización de OAuth 2.0.

Licencias

Servidor de licencias local

Si usas tu propio servidor de licencias local, puedes contribuir a proporcionar un entorno más seguro si estás ejecutando en una VPN. De todos modos, el nivel de seguridad estará sujeto a las limitaciones de la tecnología de licencias en cuestión.

Servidor de licencias en la nube

Si ejecutas tu propio servidor de licencias en Google Cloud, te recomendamos ejecutarlo en una red independiente para permitir que se lleven a cabo un control y una supervisión adicionales.

Qué sigue