En esta página, se proporciona una descripción general de las consideraciones de seguridad de Google Cloud NetApp Volumes.
Consideraciones de seguridad para las redes
Google Cloud NetApp Volumes proporciona un framework arquitectónico seguro con las siguientes capas de seguridad aisladas:
Seguridad a nivel del proyecto: Es la capa de seguridad administrativa que los administradores usan para administrar los recursos de NetApp Volumes, como los grupos de almacenamiento o los volúmenes, con la consola de Google Cloud , el SDK de Google Cloud o las APIs. Los roles y permisos de IAM protegen esta capa. Para obtener más información sobre la seguridad a nivel del proyecto, consulta Configura los permisos de IAM.
Seguridad a nivel de la red: Es la capa de red que se usa para acceder a los volúmenes de datos con protocolos de almacenamiento conectado a la red (NAS) (bloque de mensajes del servidor [SMB] y sistema de archivos de red [NFS]).
Puedes acceder a los datos dentro de los volúmenes con protocolos NAS a través de una red de nube privada virtual. Solo se puede acceder a todos los datos de NetApp Volumes a través de tu VPC, a menos que uses explícitamente una solución de terceros para reemplazar el enrutamiento del peering de VPC a tus VPCs.
Dentro de la VPC, puedes limitar aún más el acceso con firewalls y a través de la configuración de mecanismos de control de acceso específicos del protocolo.
Reglas de firewall para el acceso a volúmenes
Las reglas de firewall protegen la Google Cloud VPC. Para habilitar el acceso de los clientes a NetApp Volumes, debes permitir el tráfico de red específico.
Reglas de firewall para el acceso a volúmenes NFS
NFS usa varios puertos para comunicarse entre el cliente y un servidor. Para garantizar una comunicación adecuada y el correcto montaje de volúmenes, debes habilitar puertos en tus firewalls.
NetApp Volumes actúa como un servidor NFS y expone los puertos de red necesarios para NFS. Asegúrate de que tus clientes de NFS tengan permiso para comunicarse con los siguientes puertos de NetApp Volumes:
111 TCP/UDP portmapper
635 TCP/UDP mountd
2049 TCP/UDP nfsd
4045 TCP/UDP nlockmgr
(solo para NFSv3)4046 TCP/UDP status
(solo para NFSv3)
Las direcciones IP de NetApp Volumes se asignan automáticamente desde el rango de CIDR que asignaste al servicio durante el intercambio de tráfico de red. Para obtener más información, consulta Elige un CIDR.
Uso del bloqueo asesor con NFSv3
Si usas bloqueos de asesoramiento con NFSv3, debes ejecutar el daemon rpc.statd
en tu cliente para admitir Network Lock Manager, que es una utilidad que funciona en cooperación con NFS para proporcionar un bloqueo de archivos y registros de asesoramiento de estilo rpc.statd
a través de la red.System V
Tu cliente de NFS debe abrir un puerto de entrada para que rpc.statd
reciba devoluciones de llamada del Administrador de bloqueo de red. En la mayoría de las distribuciones de Linux, rpc.statd
se inicia cuando activas el primer recurso compartido de NFS. Usa un puerto aleatorio que puedes identificar con el comando rpcinfo -p
. Para que rpc.statd
sea más compatible con el firewall, configúralo para que use un puerto estático.
Para configurar puertos estáticos para rpc.statd
, consulta los siguientes recursos:
Si no usas bloqueos de asesoramiento de NFSv3 ni Network Lock Manager, te recomendamos que actives tus recursos compartidos de NFSv3 con la opción de activación nolock
.
NFSv4.1 implementa la función de bloqueo dentro del protocolo NFSv4.1, que se ejecuta a través de la conexión TCP iniciada por el cliente al servidor NFSv4.1 en el puerto 2049. El cliente no necesita abrir puertos de firewall para el tráfico de entrada.
Reglas de firewall para el acceso a volúmenes de SMB
SMB usa varios puertos para comunicarse entre el cliente y un servidor. Para garantizar una comunicación adecuada, debes habilitar puertos en tus firewalls.
NetApp Volumes actúan como un servidor SMB y exponen los puertos de red que requiere SMB. Asegúrate de que tu cliente de SMB pueda comunicarse con los siguientes puertos de NetApp Volumes:
445 TCP SMB2/3
135 TCP msrpc
y40001 TCP SMB CA
: Se usan solo para los recursos compartidos disponibles de forma continua de SMB 3.x. Estos puertos no son necesarios para los recursos compartidos que no están disponibles de forma continua.
El servicio expone, pero no usa, el puerto 139/TCP
.
Las direcciones IP de NetApp Volumes se asignan automáticamente desde el rango de CIDR que asignaste al servicio durante el intercambio de tráfico de red. Para obtener más información, consulta Elige un CIDR.
Tus clientes de pymes no necesitan exponer puertos de entrada para que SMB funcione.
Reglas de firewall para el acceso a Active Directory
NetApp Volumes necesitan acceso a los siguientes puertos en los servidores DNS configurados en tu política de Active Directory para identificar los controladores de dominio de Active Directory. NetApp Volumes usan búsquedas de DNS para el descubrimiento de controladores de dominio de Active Directory.
ICMPV4
DNS 53 TCP
DNS 53 UDP
Abre los siguientes puertos en todos tus controladores de dominio de Active Directory para el tráfico que se origina en el rango de CIDR de NetApp Volumes:
ICMPV4
LDAP 389 TCP
SMB over IP 445 TCP
Secure LDAP 636 TCP
Kerberos 464 TCP
Kerberos 464 UDP
Kerberos 88 TCP
Kerberos 88 UDP
Adjunta la etiqueta de firewall a los servidores de Active Directory
Sigue estas instrucciones para adjuntar la etiqueta de firewall a tus servidores de Active Directory.
Adjunta la regla de firewall a tus servidores DNS de Active Directory:
gcloud compute firewall-rules create netappvolumes-to-dns \ --allow=icmp,TCP:53,UDP:53 \ --direction=ingress \ --target-tags=allow-netappvolumes-to-dns \ --source-ranges=NETAPP_VOLUMES_CIDR \ --network=VPC_NAME
Adjunta la regla de firewall a tus controladores de dominio de Active Directory:
gcloud compute firewall-rules create netappvolumes-to-activedirectory \ --allow=icmp,TCP:88,UDP:88,TCP:389,TCP:445,TCP:464,UDP:464,TCP:636 \ --direction=ingress \ --target-tags=allow-netappvolumes-to-activedirectory \ --source-ranges=NETAPP_VOLUMES_CIDR \ --network=VPC_NAME
Reemplaza la siguiente información:
NETAPP_VOLUMES_CIDR
: CIDR de NetApp VolumesVPC_NAME
: Es el nombre de la VPC.
Adjunta la siguiente etiqueta a tus servidores DNS:
allow-netappvolumes-to-dns
Adjunta la siguiente etiqueta a tus controladores de dominio:
allow-netappvolumes-to-activedirectory
Controles de acceso al volumen para protocolos NFS
NetApp Volumes protege el acceso con protocolos NFS con una sola política de exportación con hasta 20 reglas de exportación. Las reglas de exportación son listas separadas por comas de direcciones IPv4 y CIDR de IPv4 que especifican qué clientes tienen permiso para activar volúmenes. NetApp Volumes evalúa las reglas de exportación en orden secuencial y se detiene después de la primera coincidencia. Para obtener mejores resultados, te recomendamos que ordenes las reglas de exportación de la más específica a la más genérica.
Usa las siguientes pestañas para revisar las políticas según las versiones de NFS:
NFS sin Kerberos
Todas las versiones de NFS sin Kerberos usan el sabor de seguridad AUTH_SYS
. En este modo, debes administrar estrictamente las reglas de exportación para permitir solo los clientes en los que confías y que pueden garantizar la integridad del ID de usuario y el ID de grupo.
Como medida de seguridad, los servidores NFS asignan automáticamente las llamadas NFS con UID=0
(raíz) a UID=65535
(anónimo), que tiene permisos limitados en el sistema de archivos. Durante la creación del volumen, puedes habilitar la opción de acceso raíz para controlar este comportamiento. Si habilitas el acceso raíz, el ID de usuario 0
permanece como 0
. Como práctica recomendada, crea una regla de exportación dedicada que habilite el acceso raíz para tus hosts de administrador conocidos y deshabilite el acceso raíz para todos los demás clientes.
NFSv4.1 con Kerberos
NFSv4.1 con Kerberos usa políticas de exportación y autenticación adicional con Kerberos para acceder a los volúmenes. Puedes configurar reglas de exportación para aplicar lo siguiente:
Solo Kerberos (
krb5
)Firma de Kerberos (
krb5i
)Privacidad de Kerberos (
krb5p
)
Controles de acceso al volumen para el protocolo SMB
SMB usa permisos a nivel de recurso compartido para proteger el acceso al volumen y requiere autenticación en Active Directory. Estos permisos te permiten controlar quién tiene acceso a los recursos compartidos a través de la red.
Los volúmenes se crean con permisos de nivel de uso compartido de Todos y Control total. Puedes modificar los permisos a nivel del recurso compartido con la consola de Windows o la CLI de Windows.
Sigue estas instrucciones para modificar los permisos a nivel del recurso compartido de SMB con la consola de Windows o la CLI de Windows:
Consola de Windows
Haz clic con el botón derecho en el ícono de Inicio de Windows y selecciona Administración del equipo.
Después de que se abra la consola Administración de equipos, haz clic en Acción > Conectar a otro equipo.
En el diálogo Select Computer, ingresa el nombre de NetBIOS de tu recurso compartido de SMB y haz clic en OK.
Una vez que te conectes al recurso compartido de archivos, ve a Herramientas del sistema > Carpetas compartidas > Recursos compartidos para buscar tu recurso compartido.
Haz doble clic en Nombre del recurso compartido y selecciona la pestaña Permisos de uso compartido para controlar los permisos del recurso compartido.
CLI de Windows
Abre una línea de comandos de Windows.
Conéctate al recurso compartido de archivos.
fsmgmt.msc /computer=<netbios_name_of_share>
Una vez que te conectes al recurso compartido de archivos, ve a Herramientas del sistema > Carpetas compartidas > Recursos compartidos para buscar tu recurso compartido.
Haz doble clic en Nombre del recurso compartido y selecciona la pestaña Permisos de uso compartido para controlar los permisos del recurso compartido.
Control de acceso a archivos
En las siguientes secciones, se proporcionan detalles sobre el control de acceso a nivel de archivos de NetApp Volumes.
Estilo de seguridad del volumen
NetApp Volumes ofrece dos estilos de seguridad para los volúmenes, UNIX y NTFS, para adaptarse a los diferentes conjuntos de permisos de las plataformas Linux y Windows.
UNIX: Los volúmenes configurados con el estilo de seguridad UNIX usan bits de modo UNIX y LCA de NFSv4 para controlar el acceso a los archivos.
NTFS: Los volúmenes configurados con el estilo de seguridad NTFS usan LCA de NTFS para controlar el acceso a los archivos.
El estilo de seguridad del volumen depende del protocolo que elijas para el volumen:
Tipo de protocolo | Estilo de seguridad del volumen |
---|---|
NFSv3 | UNIX |
NFSv4.1 | UNIX |
Ambos (NFSv3 y NFSv4.1) | UNIX |
SMB | NTFS |
Dual (SMB y NFSv3) | UNIX o NTFS |
Dual (SMB y NFSv4.1) | UNIX o NTFS |
En el caso de los protocolos duales, solo puedes elegir el estilo de seguridad durante la creación del volumen.
Control de acceso a nivel de archivo de NFS para volúmenes de estilo UNIX
Después de que un cliente activa un volumen correctamente, NetApp Volumes verifica los permisos de acceso a archivos y directorios con el modelo de permisos estándar de UNIX llamado bits de modo. Puedes establecer y modificar permisos con chmod
.
Los volúmenes NFSv4.1 también pueden usar listas de control de acceso (LCA) de NFSv4. Si un archivo o directorio tiene bits de modo y una LCA de NFSv4, se usa la LCA para la verificación de permisos. Lo mismo se aplica a los volúmenes que usan ambos tipos de protocolos, NFSv3 y NFSv4.1. Puedes configurar y modificar las ACL de NFSv4 con nfs4_getfacl
y nfs4_setfacl
.
Cuando creas un volumen nuevo de estilo UNIX, el root:root
tiene la propiedad del inode raíz y los permisos de 0770
. Debido a esta configuración de propiedad y permisos, un usuario no raíz recibe un error permission denied
cuando accede al volumen después de que se lo haya activado. Para habilitar el acceso al volumen para usuarios que no son raíz, un usuario raíz debe cambiar la propiedad del inode raíz con chown
y modificar los permisos del archivo con chmod
.
Control de acceso a archivos SMB para volúmenes de estilo NTFS
Para los volúmenes de estilo NTFS, te recomendamos que uses un modelo de permisos NTFS.
Cada archivo y directorio tiene una ACL de NTFS que puedes modificar con el Explorador de archivos, la herramienta de línea de comandos icacls
o PowerShell. En el modelo de permisos de NTFS, los archivos y las carpetas nuevos heredan los permisos de su carpeta principal.
Asignación de usuarios de varios protocolos
En el caso de los volúmenes de protocolo doble, los clientes pueden usar NFS y SMB para acceder a los mismos datos. Para configurar un volumen, se debe establecer su estilo de seguridad de modo que tenga permisos de UNIX o NTFS.
Cuando creas un volumen de SMB y NFS de protocolo dual, te recomendamos que Active Directory contenga un usuario predeterminado. El usuario predeterminado se usa cuando un cliente de NFS envía una llamada de NFS con un ID de usuario que no está disponible en Active Directory.
Luego, NetApp Volumes intenta buscar un usuario llamado pcuser
, que actúa como usuario predeterminado de UNIX. Si no se encuentra ese usuario, se deniega el acceso a la llamada de NFS.
Te recomendamos que crees un usuario predeterminado en Active Directory con los siguientes atributos:
uid
=pcuser
uidnumber
=65534
cn
=pcuser
gidNumber
=65534
objectClass
=user
Según el protocolo que use el cliente (NFS o SMB) y el estilo de seguridad del volumen (UNIX o NTFS), NetApp Volumes puede verificar directamente los permisos de acceso del usuario o requiere que primero se asigne el usuario a la identidad de la otra plataforma.
Protocolo de acceso | Estilo de seguridad | Identidad que usa el protocolo | Asignación obligatoria |
---|---|---|---|
NFSv3 | UNIX | ID de usuario y de grupo | N/A |
NFSv3 | NTFS | ID de usuario y de grupo | ID de usuario, nombre de usuario y identificador de seguridad |
SMB | UNIX | Identificador de seguridad | Identificador de seguridad a nombre de usuario a ID de usuario |
SMB | NTFS | Identificador de seguridad | N/A |
Cuando se requiere la asignación, NetApp Volumes se basa en los datos almacenados en el LDAP de Active Directory. Para obtener más información, consulta Casos de uso de Active Directory.
Situación de asignación de usuarios con varios protocolos: acceso a SMB a un volumen de UNIX
Científico Charlie E. (charliee) quiere acceder a un volumen de NetApp Volumes con SMB desde un cliente de Windows. Dado que el volumen contiene resultados generados por una máquina proporcionada por un clúster de procesamiento de Linux, el volumen está configurado para almacenar permisos de UNIX.
El cliente de Windows envía una llamada SMB al volumen. La llamada a SMB contiene la identidad del usuario como un identificador de seguridad. El identificador de seguridad no se puede comparar con los permisos de archivo de ID de usuario y de ID de grupo, y requiere una asignación.
Para completar la asignación requerida, NetApp Volumes realiza los siguientes pasos:
NetApp Volumes le solicita a Active Directory que resuelva el identificador de seguridad en un nombre de usuario, por ejemplo,
S-1-5-21-2761044393-2226150802-3019316526-1224
encharliee
.NetApp Volumes le solicita a Active Directory que devuelva el ID de usuario y el ID de grupo para
charliee
.NetApp Volumes verifica el acceso en función del ID de usuario y el ID de grupo de propiedad del archivo con el ID de usuario y el ID de grupo devueltos.
Situación de asignación de usuarios de varios protocolos: acceso a NFS a un volumen NTFS
El ingeniero Amal L. necesita acceder a algunos datos de un volumen desde un cliente de Linux con NFS. Dado que el volumen se usa principalmente para almacenar datos de Windows, se configura con el estilo de seguridad NTFS.
El cliente de Linux envía una llamada de NFS a NetApp Volumes. La llamada a NFS contiene identificadores de ID de usuario y de ID de grupo que no se pueden asociar a un identificador de seguridad sin una asignación.
Para completar la asignación requerida, NetApp Volumes le solicita a Active Directory el nombre de usuario del ID de usuario y que devuelva el identificador de seguridad del nombre de usuario. Luego, verifica el acceso con el identificador de seguridad del propietario del archivo al que se accedió usando el identificador de seguridad devuelto.
Encriptación en tránsito
NFS
Para los volúmenes de NFS, usa NFSv4.1 con la encriptación krb5p de Kerberos habilitada para obtener la máxima seguridad.
SMB
En el caso de los volúmenes de SMB, habilita la encriptación AES en tu política de Active Directory y la encriptación de SMB en tu volumen para obtener la máxima seguridad.
Replicación de volumen
NetApp Volumes puede replicar volúmenes en Google Cloud regiones para proporcionar protección de datos. Dado que el tráfico reside en Google Cloud, el proceso de transferencia es seguro, ya que utiliza la infraestructura de red de Google, que tiene acceso limitado para evitar la interceptación no autorizada. Además, el tráfico de replicación se encripta con los estándares de TLS 1.2 que cumplen con FIPS 140-2.
Copia de seguridad integrada
Una copia de seguridad integrada crea copias de seguridad de NetApp Volumes dentro del servicio. El tráfico de copias de seguridad permanece dentro de la infraestructura de red segura de Google con la encriptación estándar TLS 1.2 que cumple con FIPS 140-2. Además, las backup vaults almacenan estas copias de seguridad con Google-owned and Google-managed encryption key para mayor seguridad.
Migración de volumen
La migración de volúmenes envía datos del sistema ONTAP o Cloud Volumes ONTAP de origen a NetApp Volumes. La comunicación entre el sistema fuente y NetApp Volumes se encripta con los estándares de TLS 1.2 que cumplen con FIPS 140-2.
NetApp Volumes inicia la migración y usa los siguientes protocolos y puertos:
ICMP
10000/TCP
11104/TCP
11105/TCP
Asegúrate de que cualquier firewall entre la interfaz lógica (LIF) interclúster de tu sistema ONTAP y la dirección IP de migración de NetApp Volumes permita estos puertos.
¿Qué sigue?
Protege volúmenes de NetApp con un perímetro de servicio.