Arquitectura de Google Cloud NetApp Volumes
De forma similar a otros servicios nativos de Google Cloud, como CloudSQL, Google Cloud VMware Engine (GCVE) y el almacén de archivos, Google Cloud NetApp Volumes utiliza "Google PSA" para ofrecer el servicio. En PSA, los servicios se construyen dentro de un proyecto de productor de servicios, que utiliza "Agrupación de redes VPC" para conectarse con el consumidor de servicios. NetApp proporciona y opera el productor de servicios, y el consumidor de servicios es una VPC en un proyecto de cliente en el que se alojan los clientes que desean acceder a recursos compartidos de archivos de Google Cloud NetApp Volumes.
En la siguiente figura, a la que se hace referencia desde "sección de arquitectura" la documentación de Google Cloud NetApp Volumes, se muestra una vista de alto nivel.
La pieza situada encima de la línea de puntos muestra el plano de control del servicio, que controla el ciclo de vida del volumen. La pieza debajo de la línea de puntos muestra el plano de datos. El cuadro azul izquierdo muestra el VPC (consumidor de servicios) del usuario, el cuadro azul derecho es el productor de servicios que proporciona NetApp. Ambos se conectan mediante la agrupación de VPC.
Modelo de tenancy
En Google Cloud NetApp Volumes, los proyectos individuales se consideran inquilinos únicos. Esto significa que la manipulación de volúmenes, copias Snapshot, etc. se realiza por proyecto. En otras palabras, todos los volúmenes son propiedad del proyecto en el que se crearon y solo ese proyecto puede gestionar y acceder a los datos de su interior de forma predeterminada. Se considera la vista del plano de control del servicio.
VPC compartidos
En la vista de plano de datos, los volúmenes de Google Cloud NetApp se pueden conectar a un VPC compartido. Se pueden crear volúmenes en el proyecto de host o en uno de los proyectos de servicio conectados al VPC compartido. Todos los proyectos (host o servicio) conectados al VPC compartido pueden llegar a los volúmenes de la capa de red (TCP/IP). Debido a que todos los clientes con conectividad de red en el VPC compartido pueden acceder potencialmente a los datos mediante los protocolos NAS, se debe utilizar el control de acceso en el volumen individual (como las listas de control de acceso de usuarios/grupos (ACL) y los nombres de host/direcciones IP para las exportaciones de NFS para controlar quién puede acceder a los datos.
Puedes conectar volúmenes de NetApp de Google Cloud con hasta cinco VPC por proyecto de cliente. En el plano de control, el proyecto le permite gestionar todos los volúmenes creados, independientemente del VPC al que estén conectados. En el plano de datos, las PC están aisladas entre sí y cada volumen solo se puede conectar a un VPC.
El acceso a los volúmenes individuales está controlado por mecanismos de control de acceso específicos de los protocolos (NFS/SMB).
En otras palabras, en la capa de red, todos los proyectos conectados al VPC compartido pueden ver el volumen, mientras que, por el lado de la gestión, el plano de control solo permite que el proyecto del propietario vea el volumen.
Controles de servicio VPC
Los controles de servicio VPC establecen un perímetro de control de acceso alrededor de los servicios de Google Cloud que están conectados a Internet y son accesibles en todo el mundo. Estos servicios proporcionan control de acceso a través de identidades de usuario, pero no pueden restringir desde qué solicitudes de ubicación de red se originan. Los controles de servicio VPC cierran esa brecha introduciendo las funcionalidades para restringir el acceso a las redes definidas.
El plano de datos de Google Cloud NetApp Volumes no está conectado a Internet externo, sino a PC privados con límites de red (perímetros) bien definidos. Dentro de esa red, cada volumen utiliza un control de acceso específico del protocolo. Los administradores de proyectos de Google Cloud crean explícitamente cualquier conectividad de red externa. Sin embargo, el plano de control no proporciona las mismas protecciones que el plano de datos y cualquier persona puede acceder a él desde cualquier lugar con credenciales válidas ( "Fichas JWT").
En resumen, el plano de datos de NetApp Volumes de Google Cloud proporciona la capacidad de control de acceso a la red, sin necesidad de admitir los controles de servicio de VPC y no utiliza explícitamente los controles de servicio de VPC.
Consideraciones sobre rastreo y rastreo de paquetes
Las capturas de paquetes pueden ser útiles para solucionar problemas de red u otros problemas (como permisos NAS, conectividad LDAP, etc.), pero también se pueden usar de forma malintencionada para obtener información sobre direcciones IP de red, direcciones MAC, nombres de usuarios y grupos, y sobre qué nivel de seguridad se está utilizando en los extremos. Debido a la forma en que se configuran las reglas de red, VPC y firewall de Google Cloud, el acceso no deseado a los paquetes de red debería ser difícil de obtener sin credenciales de inicio de sesión del usuario o "Fichas JWT" a las instancias de cloud. Las capturas de paquetes solo son posibles en extremos (como máquinas virtuales (VM)) y solo en extremos internos en el VPC, a menos que se utilice un VPC compartido o un reenvío de túnel/IP de red externo para permitir de forma explícita el tráfico externo a los extremos. No hay forma de sniff el tráfico fuera de los clientes.
Cuando se utilizan VPC compartidos, el cifrado en tránsito con Kerberos NFS y/o "Cifrado SMB" puede enmascarar gran parte de la información obtenida de los seguimientos. Sin embargo, algo de tráfico todavía se envía en texto plano, como "DNS"y "Consultas LDAP". En la siguiente figura se muestra una captura de paquetes de una consulta LDAP de texto sin formato procedente de volúmenes de Google Cloud NetApp y la posible información de identificación que se expone. Las consultas de LDAP en volúmenes de Google Cloud NetApp no son compatibles actualmente con el cifrado o LDAP sobre SSL. El rendimiento de NetApp Volumes-Performance admite la firma LDAP, si lo solicita Active Directory. NetApp Volumes-SW no admite la firma LDAP.
UnixUserPassword es consultada por LDAP y no se envía en texto sin formato sino en un hash salado. De forma predeterminada, LDAP de Windows no rellena los campos unixUserPassword. Este campo sólo es necesario si necesita aprovechar LDAP de Windows para inicios de sesión interactivos a través de LDAP a clientes. Google Cloud NetApp Volumes no admite inicios de sesión LDAP interactivos en las instancias. |
En la siguiente figura se muestra una captura de paquetes desde una conversación Kerberos de NFS junto a una captura de NFS sobre AUTH_SYS. Tenga en cuenta que la información disponible en una traza difiere entre ambas y cómo habilitar el cifrado en tránsito ofrece una mayor seguridad general para el tráfico NAS.
Interfaces de red de equipos virtuales
Un truco que los atacantes podrían intentar es agregar una nueva tarjeta de interfaz de red (NIC) a una VM en "modo promiscuo" (Duplicación de puertos) o habilite el modo promiscuo en una NIC existente para sniff todo el tráfico. En Google Cloud, agregar una nueva NIC requiere que una máquina virtual se cierre por completo, lo que crea alertas, por lo que los atacantes no pueden pasar por alto.
Además, las NIC no se pueden establecer en modo promiscuo y activarán alertas en Google Cloud.