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 herramientas de redes
Google Cloud NetApp Volumes proporcionan un framework de arquitectura 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 recursos de NetApp Volumes, como grupos de almacenamiento o 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 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 de NAS a través de una red de nube privada virtual. Todo el acceso a los datos a NetApp Volumes solo es posible a través de tu VPC, a menos que uses de forma explícita una solución de terceros para reemplazar el enrutamiento de intercambio de tráfico entre VPC a tus VPC.
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 VPC de Google Cloud . Para habilitar el acceso de los clientes a NetApp Volumes, debes permitir 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 activaciones de volumen correctas, debes habilitar los 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 de advertencia con NFSv3
Si usas bloqueos de asesoramiento con NFSv3, debes ejecutar el daemon rpc.statd
en tu cliente para admitir el Administrador de bloqueos de red, que es una función que funciona en conjunto con NFS para proporcionar un estilo System V
de bloqueo de archivos y registros de asesoramiento a través de la red. 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 informativos de NFSv3 ni el Administrador de bloqueos de red, 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 propio protocolo NFSv4.1, que se ejecuta a través de la conexión TCP que inicia 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 SMB
SMB usa varios puertos para comunicarse entre el cliente y un servidor. Para asegurarte de que la comunicación sea adecuada, debes habilitar los 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 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 archivos compartidos de SMB 3.x disponibles de forma continua. Estos puertos no son obligatorios para los archivos compartidos que no están disponibles de forma continua.
El servicio expone el puerto 139/TCP
, pero no lo usa.
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 funcionen.
Reglas de firewall para el acceso a Active Directory
Abre los siguientes puertos en todos tus controladores de dominio de Active Directory para el tráfico que provenga del rango de CIDR de NetApp Volumes:
ICMPV4
DNS 53 TCP
DNS 53 UDP
LDAP 389 TCP
LDAP 389 UDP
LDAP (GC) 3268 TCP
SAM/LSA 445 TCP
SAM/LSA 445 UDP
Secure LDAP 636 TCP
Secure LDAP 3269 TCP
W32Time 123 UDP
AD Web Svc 9389 TCP
Kerberos 464 TCP
Kerberos 464 UDP
Kerberos 88 TCP
Kerberos 88 UDP
Cómo adjuntar una etiqueta de firewall a los servidores de Active Directory
Usa las siguientes instrucciones para adjuntar la etiqueta de firewall a tus servidores de Active Directory.
Adjunta la etiqueta de firewall a tus servidores de Active Directory:
gcloud compute firewall-rules create netappvolumes-to-activedirectory \ --allow=icmp,TCP:53,UDP:53,TCP:88,UDP:88,UDP:123,TCP:389,UDP:389,TCP:445,UDP:445,TCP:464,UDP:464,TCP:636,TCP:3268,TCP:3269,TCP:9389 \ --direction=ingress \ --target-tags=allow-netappvolumes-to-activedirectory \ --source-ranges=NETAPP_VOLUMES_CIDR \ --network=VPC_NAME
Reemplaza la siguiente información:
NETAPP_VOLUMES_CIDR
: El CIDR de NetApp VolumesVPC_NAME
: Es el nombre de la VPC.
Adjunta la siguiente etiqueta a tus controladores de dominio:
allow-netappvolumes-to-activedirectory
Controles de acceso de volumen para protocolos NFS
NetApp Volumes protege el acceso por 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 tipo de seguridad AUTH_SYS
. En
este modo, debes administrar de forma estricta las reglas de exportación para permitir solo a los clientes
en los que confías y que puedan garantizar la integridad de los IDs de usuario y de grupo.
Como medida de seguridad, los servidores NFS asignan automáticamente las llamadas NFS con UID=0
(root) a UID=65535
(anónima), 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
seguirá siendo 0
. Como práctica recomendada, crea una regla de exportación dedicada que habilite el acceso de raíz para tus hosts de administrador conocidos y, luego, inhabilita el acceso de 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 aplicarlas a lo siguiente:
Solo Kerberos (
krb5
)Firma de Kerberos (
krb5i
)Privacidad de Kerberos (
krb5p
)
Controles de acceso de volumen para el protocolo SMB
SMB usa permisos a nivel de la unidad compartida para proteger el acceso al volumen y requiere la autenticación en Active Directory. Estos permisos te permiten controlar quién tiene acceso a los archivos compartidos a través de la red.
Los volúmenes se crean con los permisos Todos y Control total a nivel de la acción de compartir. Puedes modificar los permisos a nivel de la acción de compartir con la consola de Windows o la CLI de Windows.
Sigue estas instrucciones para modificar los permisos a nivel de la carpeta compartida de SMB con la consola 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 de equipos.
Después de que se abra la consola Administración de computadoras, haz clic en Acción > Conectarse a otra computadora.
En el diálogo Select Computer, ingresa el nombre NetBIOS de tu recurso compartido SMB y haz clic en Aceptar.
Una vez que te conectes al uso compartido de archivos, ve a Herramientas del sistema > Carpetas compartidas > Usos compartidos para buscar tu uso compartido.
Haz doble clic en Nombre del uso compartido y selecciona la pestaña Permisos de uso compartido para controlar los permisos del uso 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 uso compartido de archivos, ve a Herramientas del sistema > Carpetas compartidas > Usos compartidos para buscar tu uso compartido.
Haz doble clic en Nombre del uso compartido y selecciona la pestaña Permisos de uso compartido para controlar los permisos del uso compartido.
Control de acceso a archivos
En las siguientes secciones, se proporcionan detalles sobre el control de acceso a nivel de archivo de NetApp Volumes.
Estilo de seguridad del volumen
NetApp Volumes ofrece dos estilos de seguridad para los volúmenes, UNIX y NTFS, para admitir los diferentes conjuntos de permisos de las plataformas de Linux y Windows.
UNIX: Los volúmenes configurados con el estilo de seguridad de UNIX usan bits de modo de UNIX y LCA de NFSv4 para controlar el acceso a los archivos.
NTFS: Los volúmenes configurados con el estilo de seguridad de NTFS usan LCA de NTFS para controlar el acceso a los archivos.
El estilo de seguridad del volumen depende del protocolo que elijas para él:
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 dobles, 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 de forma correcta, NetApp Volumes verifica los permisos de acceso a los archivos y directorios con el modelo de permisos estándar de UNIX, llamado bits de modo. Puedes configurar y modificar los 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, la LCA se usa para la verificación de permisos. Lo mismo se aplica a los volúmenes que usan tipos de protocolo 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, root:root
tiene la propiedad del inodo raíz y los permisos 0770
. Debido a esta configuración de propiedad y permisos, un usuario que no es raíz recibe un error permission denied
cuando accede al volumen después de activarlo. Para habilitar el acceso al volumen para usuarios que no sean raíz, un usuario raíz debe cambiar la propiedad del inodo 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 superior.
Asignación de usuarios de varios protocolos
En el caso de los volúmenes de doble protocolo, los clientes pueden usar NFS y SMB para acceder a los mismos datos. Para configurar un volumen, se establece el estilo de seguridad del volumen para que tenga permisos de UNIX o NTFS.
Cuando creas un volumen SMB y NFS de doble protocolo, 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 un usuario UNIX predeterminado. 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 pueden verificar directamente los permisos de acceso del usuario o requieren asignarlo primero 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 ID de grupo | N/A |
NFSv3 | NTFS | ID de usuario y ID de grupo | ID de usuario a nombre de usuario a 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 de varios protocolos: Acceso SMB a un volumen UNIX
Científico Charlie E. (charliee) quiere acceder a un volumen de NetApp Volumes con SMB desde un cliente de Windows. Debido a que el volumen contiene resultados generados por máquinas que proporciona un clúster de procesamiento de Linux, el volumen se configura 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 identificador de seguridad. El identificador de seguridad no es comparable con los permisos de archivos de ID de usuario y de ID de grupo, y requiere asignación.
Para completar la asignación requerida, NetApp Volumes realiza los siguientes pasos:
NetApp Volumes le piden a Active Directory que resuelva el identificador de seguridad en un nombre de usuario, por ejemplo, de
S-1-5-21-2761044393-2226150802-3019316526-1224
acharliee
.NetApp Volumes le solicita a Active Directory que muestre el ID de usuario y el ID de grupo de
charliee
.NetApp Volumes verifica el acceso en función del ID de usuario y el ID de grupo de propiedad del archivo con los IDs de usuario y grupo que se muestran.
Situación de asignación de usuarios de varios protocolos: Acceso de NFS a un volumen NTFS
El ingeniero Amal L. necesita acceder a algunos datos en un volumen desde un cliente Linux con NFS. Debido a que el volumen se usa principalmente para almacenar datos de Windows, se configura con el estilo de seguridad de 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 hacer coincidir con un identificador de seguridad sin 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ó con el identificador de seguridad que se devolvió.
Encriptación en tránsito
NFS
Para los volúmenes NFS, usa NFSv4.1 con la encriptación krb5p de Kerberos habilitada para obtener la máxima seguridad.
SMB
Para los volúmenes SMB, habilita la encriptación AES en tu política de Active Directory y la encriptación SMB en tu volumen para obtener la máxima seguridad.
Replicación de volumen
NetApp Volumes pueden replicar volúmenes en las regiones de Google Cloud para proporcionar protección de datos. Dado que el tráfico reside en Google Cloud, el proceso de transferencia es seguro, ya que usa la infraestructura de red de Google, que tiene acceso limitado para evitar intercepciones no autorizadas. Además, el tráfico de replicación se encripta con estándares TLS 1.2 que cumplen con el 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 las copias de seguridad permanece dentro de la infraestructura de red segura de Google con encriptación estándar TLS 1.2 que cumple con FIPS 140-2. Además, las bóvedas de copia de seguridad almacenan estas copias de seguridad con una clave de encriptación propiedad de Google y administrada por Google para brindar mayor seguridad.
¿Qué sigue?
Protege los volúmenes de NetApp con un perímetro de servicio.