Descripción de los comportamientos de permisos y estilo de seguridad de protocolo dual en Azure NetApp Files
SMB y NFS usan diferentes modelos de permisos para el acceso de usuarios y grupos. Como resultado, se debe configurar un volumen de azure NetApp File para respetar el modelo de permisos deseado para el acceso al protocolo. En el caso de los entornos solo NFS, la decisión es sencilla: use estilos de seguridad de UNIX. Para entornos de solo SMB, use estilos de seguridad NTFS.
Si se requieren NFS y SMB en los mismos conjuntos de datos (protocolo dual), la decisión se debe tomar en función de dos preguntas:
- ¿Qué protocolo administrarán los usuarios más los permisos?
- ¿Cuál es el punto de conexión de administración de permisos deseado? En otras palabras, ¿los usuarios requieren la capacidad de administrar permisos de clientes NFS o clientes de Windows? ¿O en ambos entornos?
Los estilos de seguridad de volumen se pueden considerar realmente estilos de permisos, donde el estilo deseado de administración de ACL es el factor de decisión.
Nota:
Los estilos de seguridad se eligen en la creación del volumen. Una vez elegido el estilo de seguridad, no se puede cambiar.
Acerca de los estilos de seguridad de volumen de Azure NetApp Files
Hay dos opciones principales para los estilos de seguridad de volumen en Azure NetApp Files:
UNIX : el estilo de seguridad de UNIX proporciona permisos de estilo UNIX, como bits de modo POSIX básicos (acceso propietario/grupo/todos con permisos estándar de lectura, escritura y ejecución, como 0755) y ACL NFSv4.x. No se admiten las ACL POSIX.
NTFS : el estilo de seguridad NTFS proporciona una funcionalidad idéntica a los permisos NTFS estándar de Windows, con usuarios y grupos granulares en ACL y permisos detallados de seguridad/auditoría.
En un entorno NAS de protocolo dual, solo se puede activar un estilo de permiso de seguridad. Debe evaluar las consideraciones de cada estilo de seguridad antes de elegir uno.
| Estilo de seguridad | Consideraciones |
|---|---|
| UNIX | - Los clientes de Windows solo pueden establecer atributos de permiso de UNIX a través de SMB que se asignan a atributos UNIX (solo lectura, escritura y ejecución; sin permisos especiales). - Las ACL nfSv4.x no tienen administración de GUI. La administración solo se realiza a través de la CLI mediante comandos nfs4_getfacl y nfs4_setfacl. - Si un archivo o carpeta tiene ACL NFSv4.x, la pestaña propiedades de seguridad de Windows no puede mostrarlas. |
| NTFS | - Los clientes UNIX no pueden establecer atributos a través de NFS a través de comandos como chown/chmod. - Los clientes NFS solo muestran permisos NTFS aproximados al usar ls comandos. Por ejemplo, si un usuario tiene un permiso en una ACL de NTFS de Windows que no se puede traducir limpiamente en un bit de modo POSIX (como el directorio de recorrido), se traduce en el valor de modo POSIX más cercano (como 1 para ejecutar). |
La selección del estilo de seguridad de volumen determina cómo se realiza la asignación de nombres para un usuario. Esta operación es la parte principal de cómo los volúmenes de protocolo dual mantienen permisos predecibles independientemente del protocolo en uso.
Use la tabla siguiente como matriz de decisión para seleccionar los estilos de seguridad de volumen adecuados.
| Estilo de seguridad | Principalmente NFS | Principalmente SMB | Necesidad de seguridad pormenorizadas |
|---|---|---|---|
| UNIX | X | - | X (con ACL nfSv4.x) |
| NTFS | - | X | X |
Funcionamiento de la asignación de nombres en Azure NetApp Files
En Azure NetApp Files, solo los usuarios se autentican y asignan. Los grupos no están asignados. En su lugar, las pertenencias a grupos se determinan mediante la identidad del usuario.
Cuando un usuario intenta acceder a un volumen de Azure NetApp Files, ese intento pasa una identidad al servicio. Esa identidad incluye un nombre de usuario y un identificador numérico único (número UID para NFSv3, cadena de nombre para NFSv4.1, SID para SMB). Azure NetApp Files usa esa identidad para autenticarse en un servicio de nombres configurado para comprobar la identidad del usuario.
- La búsqueda LDAP de identificadores numéricos se usa para buscar un nombre de usuario en Active Directory.
- Las cadenas de nombre usan la búsqueda LDAP para buscar un nombre de usuario y el cliente y el servidor consultan el dominio de identificador configurado para NFSv4.1 para garantizar la coincidencia.
- Los usuarios de Windows se consultan mediante llamadas RPC estándar de Windows a Active Directory.
- También se consultan las pertenencias a grupos y todo se agrega a una caché de credenciales para un procesamiento más rápido en las solicitudes posteriores al volumen.
- Actualmente, los usuarios locales personalizados no se admiten para su uso con Azure NetApp Files. Solo los usuarios de Active Directory se pueden usar con protocolos duales.
- Actualmente, los únicos usuarios locales que se pueden usar con volúmenes de protocolo dual son raíz y el
nfsnobodyusuario.
Después de autenticar y validar un nombre de usuario mediante Azure NetApp Files, el siguiente paso para la autenticación de volumen de protocolo dual es la asignación de nombres de usuario para la interoperabilidad de UNIX y Windows.
El estilo de seguridad de un volumen determina cómo tiene lugar una asignación de nombres en Azure NetApp Files. La semántica de permisos de Windows y UNIX es diferente. Si no se puede realizar una asignación de nombres, se produce un error en la autenticación y se deniega el acceso a un volumen desde un cliente. Un escenario común en el que se produce esta situación es cuando se intenta acceder a NFSv3 a un volumen con estilo de seguridad NTFS. La solicitud de acceso inicial de NFSv3 llega a Azure NetApp Files como UID numérico. Si un usuario denominado user1 con un identificador numérico de 1001 intenta acceder al montaje NFSv3, la solicitud de autenticación llega como identificador 1001numérico. Después, Azure NetApp Files toma el identificador 1001 numérico e intenta resolverlo 1001 en un nombre de usuario. Este nombre de usuario es necesario para asignar a un usuario de Windows válido, ya que los permisos NTFS del volumen contendrán nombres de usuario de Windows en lugar de un identificador numérico. Azure NetApp Files usará el servidor de servicios de nombres configurado (LDAP) para buscar el nombre de usuario. Si no se encuentra el nombre de usuario, se produce un error en la autenticación y se deniega el acceso. Esta operación es por diseño para evitar el acceso no deseado a archivos y carpetas.
Asignación de nombres basada en el estilo de seguridad
La dirección en la que se produce la asignación de nombres en Azure NetApp Files (Windows a UNIX o UNIX a Windows) depende no solo del protocolo que se usa, sino también del estilo de seguridad de un volumen. Un cliente de Windows siempre requiere una asignación de nombres de Windows a UNIX para permitir el acceso, pero no siempre necesita un nombre de usuario de UNIX coincidente. Si no existe ningún nombre de usuario UNIX válido en el servidor de servicio de nombres configurado, Azure NetApp Files proporciona un usuario UNIX predeterminado de reserva con el UID numérico de 65534 para permitir la autenticación inicial para las conexiones SMB. Después, los permisos de archivo y carpeta controlarán el acceso. Dado que 65534 , por lo general, corresponde al usuario, el nfsnobody acceso se limita en la mayoría de los casos. Por el contrario, un cliente NFS solo necesita usar una asignación de nombres de UNIX a Windows si el estilo de seguridad NTFS está en uso. No hay ningún usuario de Windows predeterminado en Azure NetApp Files. Por lo tanto, si no se encuentra un usuario de Windows válido que coincida con el nombre de solicitud, se denegará el acceso.
En la tabla siguiente se desglosan las diferentes permutaciones de asignación de nombres y cómo se comportan en función del protocolo en uso.
| Protocolo | Estilo de seguridad | Dirección de asignación de nombres | Permisos aplicados |
|---|---|---|---|
| Pyme | UNIX | Windows a UNIX | UNIX (bits de modo o ACL NFSv4.x) |
| Pyme | NTFS | Windows a UNIX | ACL NTFS (basado en el SID de Windows que accede al recurso compartido) |
| NFSv3 | UNIX | None | UNIX (bits de modo o ACL NFSv4.x*) |
| NFSv4.x | UNIX | Identificador numérico para el nombre de usuario de UNIX | UNIX (bits de modo o ACL NFSv4.x) |
| NFS3/4.x | NTFS | UNIX a Windows | ACL NTFS (basado en el SID de usuario de Windows asignado) |
Nota:
Actualmente, las reglas de asignación de nombres en Azure NetApp Files solo se pueden controlar mediante LDAP. No hay ninguna opción para crear reglas de asignación de nombres explícitas dentro del servicio.
Asignar nombres a los servicios con volúmenes de protocolo dual
Independientemente del protocolo NAS que se use, los volúmenes de protocolo dual usan conceptos de asignación de nombres para controlar los permisos correctamente. Por lo tanto, los servicios de nombres desempeñan un papel fundamental en el mantenimiento de la funcionalidad en entornos que usan SMB y NFS para el acceso a los volúmenes.
Los servicios de nombre actúan como orígenes de identidad para usuarios y grupos que acceden a volúmenes NAS. Esta operación incluye Active Directory, que puede actuar como origen para usuarios y grupos de Windows y UNIX mediante servicios de dominio estándar y funcionalidad LDAP.
Los servicios de nombre no son un requisito estricto, pero se recomienda encarecidamente para volúmenes de protocolo dual de Azure NetApp Files. No hay ningún concepto de creación de usuarios y grupos locales personalizados dentro del servicio. Por lo tanto, para tener la autenticación adecuada y la información precisa del usuario y el propietario del grupo entre protocolos, LDAP es una necesidad. Si solo tiene unos pocos usuarios y no necesita rellenar información precisa de identidad de usuario y grupo, considere la posibilidad de usar la opción Permitir que los usuarios NFS locales con LDAP accedan a una funcionalidad de volumen de protocolo dual. Tenga en cuenta que habilitar esta funcionalidad deshabilita la funcionalidad de grupo extendida.
Cuando los clientes, los servicios de nombres y el almacenamiento residen en diferentes áreas
En algunos casos, los clientes NAS pueden residir en una red segmentada con varias interfaces que tienen conexiones aisladas a los servicios de almacenamiento y nombre.
Un ejemplo de este tipo es si el almacenamiento reside en Azure NetApp Files, mientras que los clientes NAS y los servicios de dominio residen en el entorno local (como una arquitectura en estrella tipo hub-spoke en Azure). En esos escenarios, tendría que proporcionar acceso de red tanto a los clientes NAS como a los servicios de nombre.
En la ilustración siguiente se muestra un ejemplo de ese tipo de configuración.
Pasos siguientes
Oharrak
Laster erabilgarri: 2024an, GitHub-eko arazoak edukiari buruzko oharrak bidaltzeko mekanismo gisa kenduko dugu apurka-apurka, eta oharrak bidaltzeko sistema berri batekin ordeztuko. Informazio gehiagorako, ikusi: https://aka.ms/ContentUserFeedback.
Bidali eta ikusi honi buruzko oharrak: